研究提案

Engineering World：工程开发 RL Environment 构建蓝图

基于 MCP 协议的工程全链路 RL 训练环境设计——覆盖代码管理、k8s 运维、监控告警、数据库、Wiki、即时通信六大子系统，40 个分级任务，三层 Reward 架构

2026年4月17日 RL Environment Agent Training MCP Engineering DevOps

总体判断

资源覆盖了工程开发的六个核心子系统，每个子系统对应 RL 环境的一个 MCP Server，组合起来就是一个完整的 Engineering World。这比只做 SWE-bench 式的代码修复要有意义得多——它模拟的是工程师日常工作的全链路，而不是某个孤立的编码任务。

分两期构建：一期用开源方案快速搭出可跑的 MVP，二期接入企业微信/k8s/Prometheus 等需要权限的系统。

一、环境架构

1.1 整体拓扑

┌─────────────────────────────────────────────────────────┐
│                  Engineering World                        │
│                                                          │
│   ┌──────────────────────────────────────────────────┐   │
│   │              MCP Gateway (路由层)                  │   │
│   └────┬──────┬──────┬──────┬──────┬──────┬─────────┘   │
│        │      │      │      │      │      │              │
│    ┌───┴──┐┌──┴──┐┌──┴──┐┌──┴──┐┌──┴──┐┌──┴───┐        │
│    │IM/CMS││Code ││FS+DB││Wiki ││ K8s ││Monitor│        │
│    │Server││Mgmt ││     ││     ││     ││       │        │
│    └──────┘└─────┘└─────┘└─────┘└─────┘└───────┘        │
│                                                          │
│   ┌──────────────────────────────────────────────────┐   │
│   │           Docker 沙箱 (每个 episode 一个)          │   │
│   │   文件系统快照 + Git 仓库 + 数据库 + 应用进程       │   │
│   └──────────────────────────────────────────────────┘   │
│                                                          │
│   ┌──────────────────────────────────────────────────┐   │
│   │           Verifier (评分层)                        │   │
│   │   快照对比 + 测试用例 + 状态断言 + LLM Judge        │   │
│   └──────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────┘

1.2 资源映射表

资源	负责人	环境角色	MCP Server 实现方式	优先级
企业微信	bertguan	IM 通信 + 审批 + 通知	封装企微 Open API → MCP Server	P1
k8s	timhyzhang	部署 + 扩缩容 + 故障注入	封装 kubectl API → MCP Server	P1
Prometheus/Grafana	xiaochencai	监控告警 + 指标查询	封装 PromQL API → MCP Server	P1
GitHub/GitLab	yuanjuncai	代码仓库 + PR + CI/CD	封装 GitLab API → MCP Server（开源直接用）	P0
文件系统 + DB	hirojiang	数据存储 + 查询 + 迁移	文件系统直接挂载 + DB MCP（PostgreSQL/MySQL）	P0
Wiki	dingxin	知识库 + 文档 + 搜索	iwiki OpenAPI 封装 / Notion MCP（官方已有）	P1
IM/CMS (开源)	timhyzhang	替代企微的开源通信层	Mattermost/Rocket.Chat API → MCP	P2

1.3 开源替代方案（用于快速 MVP）

内部系统	开源替代	说明
企业微信	Mattermost / Rocket.Chat	REST API 完善，可自部署，已有社区 MCP
GitLab 内网	GitLab CE (Docker)	一行命令起，API 与内网版一致
iwiki	Notion (API) / Outline (开源)	Notion 已有官方 MCP；Outline 自部署 + API
k8s	kind / k3s	本地轻量 k8s，够用于 RL 场景
Prometheus/Grafana	直接用（本身开源）	Docker Compose 一键部署
TDSQL	PostgreSQL	最通用，MCP 生态最成熟

二、六个 MCP Server 详细设计

2.1 Code Management Server（代码管理）

负责人：yuanjuncai

工具集（Tools）:
├── repo_clone          # 克隆仓库
├── repo_list_files     # 列出文件树
├── file_read           # 读取文件内容
├── file_write          # 写入/修改文件
├── git_diff            # 查看变更差异
├── git_commit          # 提交变更
├── git_create_branch   # 创建分支
├── pr_create           # 创建 Pull Request
├── pr_review           # 查看 Review 评论
├── pr_merge            # 合并 PR
├── ci_status           # 查询 CI 流水线状态
├── ci_trigger          # 触发 CI 构建
└── ci_logs             # 获取 CI 构建日志

实现：GitLab CE API 封装，每个 episode 创建临时 project。

2.2 Infrastructure Server（基础设施 / k8s）

负责人：timhyzhang

工具集（Tools）:
├── k8s_get_pods         # 获取 Pod 列表和状态
├── k8s_get_deployments  # 获取 Deployment 列表
├── k8s_get_services     # 获取 Service 列表
├── k8s_apply            # 应用 YAML 配置
├── k8s_delete           # 删除资源
├── k8s_scale            # 扩缩容
├── k8s_logs             # 获取 Pod 日志
├── k8s_exec             # 在 Pod 内执行命令
├── k8s_describe         # 详细描述资源
├── k8s_get_events       # 获取集群事件
├── k8s_port_forward     # 端口转发
└── k8s_rollout_status   # 查看发布状态

实现：kind/k3s 本地集群 + kubectl Python client 封装。

2.3 Monitoring Server（监控告警）

负责人：xiaochencai

工具集（Tools）:
├── prom_query           # 即时查询（PromQL）
├── prom_query_range     # 范围查询（时间序列）
├── prom_alerts          # 获取当前告警
├── prom_targets         # 获取监控目标
├── grafana_dashboards   # 列出仪表盘
├── grafana_snapshot     # 获取仪表盘截图/数据
└── alert_acknowledge    # 确认告警

实现：Prometheus + Grafana Docker 部署，注入模拟指标。

2.4 Storage Server（文件系统 + 数据库）

负责人：hirojiang

工具集（Tools）:
├── fs_list              # 列目录
├── fs_read              # 读文件
├── fs_write             # 写文件
├── fs_mkdir             # 创建目录
├── fs_delete            # 删除
├── fs_search            # 文件搜索（by name/content）
├── db_query             # 执行 SQL 查询
├── db_execute           # 执行 SQL 修改
├── db_schema            # 获取表结构
├── db_tables            # 列出所有表
└── db_explain           # 查询执行计划

实现：沙箱内挂载文件系统 + PostgreSQL Docker 实例。

2.5 Wiki / Knowledge Server（知识库）

负责人：dingxin

工具集（Tools）:
├── wiki_search          # 全文搜索
├── wiki_get_page        # 获取页面内容
├── wiki_create_page     # 创建页面
├── wiki_update_page     # 更新页面
├── wiki_list_children   # 列出子页面
├── wiki_get_comments    # 获取评论
└── wiki_add_comment     # 添加评论

实现：Outline（开源 Wiki）Docker 部署，预灌内部文档模拟数据。或直接用 Notion API + MCP。

2.6 Communication Server（即时通信）

负责人：bertguan

工具集（Tools）:
├── im_send_message      # 发送消息（指定频道/人）
├── im_read_messages     # 读取消息历史
├── im_create_channel    # 创建频道
├── im_list_channels     # 列出频道
├── im_search            # 搜索消息
├── im_reply_thread      # 回复消息线程
├── im_upload_file       # 上传文件
└── im_get_user_info     # 获取用户信息

实现：Mattermost Docker 部署，预创建模拟团队和历史消息。

三、Task 设计（40 个任务，4 个难度等级）

3.1 难度分级标准

等级	描述	涉及子系统数	预期步骤	对标
L1	单工具操作	1	3-5 步	入门级
L2	跨 2 系统协作	2	5-15 步	SWE-bench Easy
L3	多系统联动 + 推理	3-4	15-30 步	SWE-bench Medium
L4	全链路工程任务	4-6	30-60 步	APEX-Agents Hard

3.2 Category A：代码开发任务（10 个）

ID	难度	描述	涉及子系统	Reward 信号
`code-001`	L1	修复一个函数的 bug（有测试用例）	Code	测试通过
`code-002`	L1	给现有函数添加参数校验和错误处理	Code	测试通过 + 静态分析
`code-003`	L2	根据 Wiki 上的 API 文档，实现一个新的 REST 接口	Code + Wiki	集成测试通过
`code-004`	L2	阅读 PR Review 评论，修改代码并回复	Code + IM	Review 通过 + 回复质量
`code-005`	L3	分析 CI 失败日志，定位问题并修复	Code + Monitoring	CI 绿 + 根因准确
`code-006`	L3	重构一个模块：拆文件 + 更新引用 + 保持测试通过	Code + FS	测试通过 + 代码质量评分
`code-007`	L3	数据库 migration：添加新表 + 更新 ORM + 写迁移脚本	Code + DB	迁移成功 + schema 正确
`code-008`	L4	从需求文档到 PR 合并的完整开发流程	Code + Wiki + IM	端到端功能验证
`code-009`	L4	修复生产环境告警：查日志→定位→修复→部署→验证	Code + Monitoring + k8s	告警消除 + 回归测试
`code-010`	L4	基于设计文档实现微服务，含 API + DB + 测试 + 部署配置	全部	集成测试 + 部署验证

3.3 Category B：运维部署任务（10 个）

ID	难度	描述	涉及子系统	Reward 信号
`ops-001`	L1	查看 Pod 状态，找到 CrashLoopBackOff 的 Pod	k8s	正确识别
`ops-002`	L1	读取 Prometheus 指标，判断 CPU 使用率最高的服务	Monitoring	答案正确
`ops-003`	L2	扩容服务到指定副本数，验证扩容成功	k8s + Monitoring	Pod Ready + 指标正常
`ops-004`	L2	分析 Grafana 仪表盘，发现异常服务并通知团队	Monitoring + IM	正确定位 + 通知发出
`ops-005`	L3	数据库慢查询排查：找到慢 SQL → 优化 → 验证	DB + Monitoring	查询时间降低
`ops-006`	L3	服务发布：更新镜像版本 → 灰度发布 → 监控验证	k8s + Code + Monitoring	新版本运行 + 无告警
`ops-007`	L3	磁盘空间告警处理：定位大文件 → 清理/归档 → 确认恢复	k8s + FS + Monitoring	磁盘使用率恢复
`ops-008`	L4	完整的事故响应：告警→排查→修复→复盘→文档	全部	服务恢复 + 复盘文档
`ops-009`	L4	跨服务链路排查：A→B→C 调用链中定位故障节点	k8s + Monitoring + Code	根因定位准确
`ops-010`	L4	容量规划：基于历史指标预测资源需求，输出扩容方案	Monitoring + k8s + Wiki	方案合理性评分

3.4 Category C：协作沟通任务（10 个）

ID	难度	描述	涉及子系统	Reward 信号
`comm-001`	L1	搜索 Wiki 找到某个 API 的调用方式	Wiki	答案正确
`comm-002`	L1	在 IM 中搜索历史消息找到某次讨论的结论	IM	内容匹配
`comm-003`	L2	整理 IM 讨论+会议纪要，输出 Action Items 文档	IM + Wiki	完整性 + 准确性
`comm-004`	L2	根据 Code Review 评论汇总，撰写技术改进提案	Code + Wiki	提案质量评分
`comm-005`	L3	调研 Wiki 上多篇文档，输出技术选型对比报告	Wiki + IM	覆盖度 + 分析深度
`comm-006`	L3	从告警日志+代码变更+IM 记录，还原事故时间线	Monitoring + Code + IM	时间线准确性
`comm-007`	L3	新员工 onboarding：根据 Wiki 文档配置开发环境	Wiki + Code + k8s	环境可用
`comm-008`	L4	跨团队需求评审：收集需求→整理→安排会议→输出结论	IM + Wiki + Code	流程完整性
`comm-009`	L4	技术方案设计：调研→对比→写文档→发起 Review→迭代	Wiki + Code + IM	方案质量 + 迭代次数
`comm-010`	L4	Sprint 回顾：收集完成项+metrics+问题，输出改进计划	全部	报告完整性

3.5 Category D：数据与安全任务（10 个）

ID	难度	描述	涉及子系统	Reward 信号
`data-001`	L1	执行 SQL 查询获取指定数据	DB	结果正确
`data-002`	L1	导出数据库表为 CSV 并上传到指定目录	DB + FS	文件正确
`data-003`	L2	根据需求设计新表的 schema 并创建	DB + Wiki	schema 合理性
`data-004`	L2	数据清洗：找到异常记录并修复/标记	DB + Code	数据质量提升
`data-005`	L3	写数据迁移脚本：旧表→新表，保证数据完整性	DB + Code + FS	数据一致性
`data-006`	L3	分析数据库性能：慢查询 → 加索引 → 验证效果	DB + Monitoring	查询性能提升
`data-007`	L3	从日志中提取指标，写入数据库并创建 Grafana Dashboard	FS + DB + Monitoring	Dashboard 可用
`data-008`	L4	数据管道搭建：采集→清洗→存储→可视化	全部	端到端验证
`data-009`	L4	安全审计：检查代码中的敏感信息泄露 + 修复	Code + DB + FS	扫描通过
`data-010`	L4	数据恢复演练：模拟数据丢失 → 备份恢复 → 验证	DB + k8s + IM	数据完整恢复

四、Reward 设计

4.1 三层 Reward 架构

Layer 1: Outcome Reward（结果奖励，主信号）
├── 二值判断：测试通过？部署成功？告警消除？
├── 快照对比：episode 前后的文件系统 / DB / k8s 状态差异
└── 程序化验证：SQL 结果匹配、API 响应校验

Layer 2: Quality Reward（质量奖励，辅助信号）
├── 代码质量：lint score / 复杂度 / 测试覆盖率
├── 文档质量：LLM Judge 评分
└── 通信质量：消息的准确性和专业度

Layer 3: Efficiency Reward（效率奖励，衰减项）
├── 步数惩罚：鼓励用更少步骤完成
├── 工具滥用惩罚：重复调用同一工具
└── 回退惩罚：反复修改同一文件

4.2 Reward 函数

def compute_reward(episode):
    # Layer 1: 结果 (权重 0.6)
    outcome = verify_outcome(episode.final_state, episode.task.expected_state)
    
    # Layer 2: 质量 (权重 0.3)
    quality = (
        code_quality_score(episode) * 0.4 +
        doc_quality_score(episode) * 0.3 +
        comm_quality_score(episode) * 0.3
    )
    
    # Layer 3: 效率 (权重 0.1)
    step_penalty = max(0, 1 - episode.steps / episode.task.max_steps)
    
    reward = 0.6 * outcome + 0.3 * quality + 0.1 * step_penalty
    return reward

五、故障注入机制

RL 环境的核心优势是可以程序化注入故障，让 Agent 在可控的混乱中学习。

故障类型	注入方式	训练目标
代码 Bug	向 codebase 注入已知 bug	调试能力
CI 失败	修改 CI 配置或依赖版本	CI/CD 排查能力
Pod Crash	Kill 容器 / OOM / 配置错误	k8s 故障排查
数据库异常	慢查询 / 锁 / 磁盘满 / 数据损坏	DBA 能力
监控告警	注入异常指标到 Prometheus	告警响应能力
信息缺失	Wiki 文档不完整 / IM 消息模糊	信息搜集能力
权限不足	部分操作返回 403	权限申请流程认知
环境漂移	运行中修改环境配置	适应性

六、实施路线

Phase 1：MVP（2 周）

目标：在单机 Docker Compose 上跑通 L1-L2 任务

# docker-compose.yml 核心服务
services:
  gitlab:        # GitLab CE
  postgres:      # PostgreSQL 15
  mattermost:    # IM
  outline:       # Wiki
  prometheus:    # 监控
  grafana:       # 可视化
  kind-cluster:  # k8s (kind-in-docker)
  mcp-gateway:   # MCP 路由
  sandbox:       # Agent 执行沙箱

交付物：

6 个 MCP Server 的基础版本
10 个 L1-L2 任务 + verifier
单个 episode 的录制和回放

Phase 2：规模化（4 周）

目标：支持 L3-L4 任务 + 并行 rollout

完整 40 个任务
故障注入系统
Verifier 全部自动化
并行 rollout：Kubernetes 调度 N 个独立沙箱
轨迹数据格式标准化

Phase 3：训练接入（4 周）

目标：接入 RL 训练框架

对接 verl / ROLL / AReaL 训练框架
Reward 函数调优
轨迹质量分析工具
接入内部系统（企微、k8s 集群等）

七、关键设计决策

7.1 为什么用 MCP 而不是直接操作？

维度	直接操作（bash/API）	MCP 协议
操作记录	需额外 hook	协议层自动记录
权限控制	需自己实现	MCP Server 内置
工具替换	改代码	换 Server，协议不变
多模型兼容	每个模型适配	统一 MCP 接口
评分集成	需额外采集	直接从 tool_call 日志分析

7.2 与 APEX-Agents / SWE-bench 的差异

维度	SWE-bench	APEX-Agents	Engineering World
领域	代码修复	投行/咨询/法律	工程全链路
工具	Git + Shell	9 类办公工具	6 类工程系统
环境	Git Repo	文件系统 + MCP	k8s + 监控 + DB + IM + Wiki + Git
真实度	GitHub Issue	专业工作任务	企业内部工作流
可训练性	广泛用于 RL	偏评测	原生为 RL 设计

7.3 Episode 生命周期

1. 环境初始化
   ├── 从模板创建 Docker 沙箱
   ├── 加载 World 快照（文件/DB/k8s 状态）
   ├── 注入故障（如果有）
   └── 启动 MCP Server

2. Agent 交互（rollout）
   ├── Agent 接收 Task prompt
   ├── Agent ↔ MCP Gateway 多轮交互
   ├── 完整记录 tool_call 序列
   └── 超时或 Agent 提交结束

3. 评分
   ├── 快照对比（当前 vs 期望）
   ├── 程序化验证（测试/断言）
   ├── LLM Judge（文档/沟通质量）
   └── 效率计算

4. 清理
   ├── 保存轨迹数据
   ├── 销毁沙箱
   └── 返回 reward

八、成本估算

项目	规格	月成本估算
GPU 服务器（训练）	4×A100 80G	~¥80k/月
沙箱集群	32 核 128G × 4 台	~¥20k/月
存储（轨迹数据）	2TB SSD	~¥2k/月
开源软件许可	全部 MIT/Apache	¥0

MVP 阶段单台 64G 内存的开发机即可跑通。

附录 A：首批 50 Task 详细设计

目标：基于 Engineering World 的 6 个 MCP Server，设计 50 个可直接实现的 Task，含详细的环境配置、输入、验证器和 Golden Response 生成方法。
与正文第三节的关系：正文 40 个 Task 是方向级概要，本附录是可执行级详设——对正文 Task 做细化拆解和扩充。

A.1 总览

MCP Server 使用频次

MCP Server	简称	被引用次数	说明
Code Management	Code	28	核心，几乎所有开发类任务
Storage (FS+DB)	Storage	24	文件操作 + 数据库，基础设施
Infrastructure (k8s)	Infra	18	运维部署类核心
Monitoring	Monitor	16	告警、指标、排查类
Communication (IM)	IM	12	协作沟通、通知
Wiki/Knowledge	Wiki	11	文档检索、知识管理

难度分布

难度	数量	Agent 步数	涉及子系统
L1	12	3-8 步	1 个
L2	16	8-20 步	2 个
L3	14	15-35 步	3-4 个
L4	8	30-60 步	4-6 个

分类分布

分类	数量	对应正文
A：代码开发	14	Category A（扩充 4 个）
B：运维部署	12	Category B（扩充 2 个）
C：协作沟通	10	Category C（持平）
D：数据工程	8	Category D 的数据部分
E：安全与质量	6	Category D 的安全部分（独立出来）

A.2 50 Task 总览表

Category A：代码开发（14 个）

#	Task ID	难度	任务描述	MCP Server	验证方式	设计方法
1	code-001	L1	修复单个函数 Bug（有失败的测试用例指引）	Code	pytest 全通过	正确代码注入 off-by-one
2	code-002	L1	为现有函数添加参数校验和错误处理	Code	测试通过 + mypy 检查	strip 掉校验代码
3	code-003	L1	阅读代码，编写缺失的单元测试	Code, Storage	测试通过 + 覆盖率 ≥ 85%	给定函数，删除测试
4	code-004	L2	根据 Wiki 上的 API 文档实现一个 REST 接口	Code, Wiki	API 集成测试通过	提供 API spec + 项目骨架
5	code-005	L2	阅读 PR Review 评论，修改代码并在 IM 回复 Reviewer	Code, IM	Review 点逐条满足 + 回复质量	准备 Review 评论
6	code-006	L2	修复 3 个 lint/type 错误并提交规范的 commit	Code	flake8/mypy 零 error + commit 格式	注入已知 lint 问题
7	code-007	L2	将一段重复代码提取为公共函数，更新所有调用点	Code, Storage	测试通过 + 代码重复率下降	人工复制代码到多处
8	code-008	L3	分析 CI 失败日志，定位依赖/编译/测试问题并修复	Code, Monitor	CI 重跑绿 + 根因描述准确	注入 4 类 CI 错误之一
9	code-009	L3	数据库 migration：新增表 + 更新 ORM + 写迁移脚本	Code, Storage	迁移成功 + schema 正确 + 数据完整	给定需求 + 现有 schema
10	code-010	L3	跨文件级联 Bug：追踪 A→B→C 调用链，修复根因	Code, Storage	集成测试通过 + 修改根因文件	注入跨模块 off-by-one
11	code-011	L3	重构模块：拆大文件为 3+ 小文件，保持测试通过	Code, Storage	测试通过 + 文件数增加 + 代码质量评分	提供巨型文件
12	code-012	L4	从 Wiki 需求文档到 PR 合并的完整开发流程	Code, Wiki, IM, Storage	PR merged + CI 绿 + 需求关联	完整需求文档
13	code-013	L4	修复生产告警：查监控→查日志→定位→修复→部署→验证	Code, Monitor, Infra, IM	告警消除 + 回归测试通过	注入运行时错误
14	code-014	L4	实现微服务：API + DB + 测试 + Dockerfile + K8s YAML	Code, Storage, Infra, Wiki	集成测试 + 部署成功 + API 可达	给定设计文档

Category B：运维部署（12 个）

#	Task ID	难度	任务描述	MCP Server	验证方式	设计方法
15	ops-001	L1	查找 CrashLoopBackOff 的 Pod 并报告原因	Infra	正确识别 Pod + 原因	Kill 容器制造 Crash
16	ops-002	L1	读 Prometheus 指标，找出 CPU 最高的服务	Monitor	答案正确	注入高 CPU 指标
17	ops-003	L1	查看 K8s Service 列表，找到无后端 Pod 的 Service	Infra	正确识别空 Service	删除后端 Deployment
18	ops-004	L2	扩容服务到 N 副本，验证 Pod Ready + 监控指标正常	Infra, Monitor	Pod 数量正确 + 指标稳定	设定初始副本 + 目标
19	ops-005	L2	分析 Grafana Dashboard，发现异常服务并 IM 通知团队	Monitor, IM	正确识别 + 消息发出	注入指标异常
20	ops-006	L2	更新 Deployment 镜像版本并等待 rollout 完成	Infra, Code	新版本 Running + 无 restart	准备新镜像 tag
21	ops-007	L3	Pod OOM 排查：看 events→查 limits→调整资源→验证	Infra, Monitor, Storage	Pod 稳定 + 无 OOMKilled	设置过小 memory limit
22	ops-008	L3	灰度发布：更新镜像 → 金丝雀 10% → 监控验证 → 全量	Infra, Monitor, Code	全量发布成功 + 无告警	准备发布流程
23	ops-009	L3	磁盘告警：定位大文件/日志 → 清理 → 验证磁盘恢复	Infra, Storage, Monitor	磁盘使用率下降	填充大文件制造告警
24	ops-010	L3	跨服务链路排查：A→B→C 调用中定位超时环节	Infra, Monitor, Code	根因定位准确	注入 B 服务延迟
25	ops-011	L4	完整事故响应：告警→排查→修复→恢复→复盘文档	全部 6 个	服务恢复 + 复盘文档质量	注入级联故障
26	ops-012	L4	容量规划：分析历史指标 → 预测趋势 → 输出扩容方案	Monitor, Infra, Wiki, Storage	方案合理性 (LLM Judge)	提供 30 天监控数据

Category C：协作沟通（10 个）

#	Task ID	难度	任务描述	MCP Server	验证方式	设计方法
27	comm-001	L1	搜索 Wiki 找到某 API 的调用方式并回答问题	Wiki	答案正确性	预建 API 文档
28	comm-002	L1	搜索 IM 历史消息，找到某次讨论的结论	IM	内容匹配	预灌对话历史
29	comm-003	L2	整理 IM 讨论记录，输出结构化 Action Items 到 Wiki	IM, Wiki	Action Items F1 ≥ 0.8	预灌讨论 + 标注
30	comm-004	L2	汇总 Code Review 评论，撰写技术改进提案发到 Wiki	Code, Wiki	提案覆盖所有 Review 点 + 质量	准备多条 Review
31	comm-005	L2	阅读 Wiki 变更日志，撰写面向团队的版本更新通知	Wiki, IM	通知发出 + 内容准确	提供 CHANGELOG
32	comm-006	L3	调研 Wiki 上 3+ 篇文档，输出技术选型对比报告	Wiki, Code, IM	覆盖度 + 分析深度 (Judge)	预建技术文档集
33	comm-007	L3	从告警+代码变更+IM 记录还原事故时间线	Monitor, Code, IM	时间线准确性 + 完整性	注入事故 + 历史记录
34	comm-008	L3	新员工 onboarding：按 Wiki 文档配置开发环境	Wiki, Code, Infra	环境可用（编译通过 + 服务跑通）	准备 onboarding 文档
35	comm-009	L4	跨团队需求评审：收集需求→整理→安排→输出结论	IM, Wiki, Code	流程完整 + 结论文档质量	模拟多方消息
36	comm-010	L4	Sprint 回顾：收集指标+完成项+问题，输出改进计划	全部 6 个	报告完整性 + 数据准确性	提供 Sprint 数据

Category D：数据工程（8 个）

#	Task ID	难度	任务描述	MCP Server	验证方式	设计方法
37	data-001	L1	编写 SQL 查询获取指定数据（NL2SQL）	Storage	结果集与 Golden 一致	预建 schema + 数据
38	data-002	L1	导出数据库表为 CSV 并保存到指定目录	Storage	文件存在 + 行数正确 + 格式正确	给定表 + 目标路径
39	data-003	L2	根据 Wiki 需求文档设计新表 Schema 并创建	Storage, Wiki	DDL 可执行 + 字段合理	提供需求文档
40	data-004	L2	数据质量检查：找到异常记录并修复/标记	Storage, Code	异常发现率 + 修复正确	注入 5 类异常数据
41	data-005	L3	写数据迁移脚本：旧表→新表，保证完整性	Storage, Code	行数一致 + checksum 匹配	提供新旧 schema
42	data-006	L3	慢查询排查：找慢 SQL → 加索引 → 验证	Storage, Monitor	查询耗时降低 ≥ 50%	注入无索引大表
43	data-007	L3	从日志文件提取指标，写入 DB，创建 Grafana Dashboard	Storage, Monitor, Code	Dashboard 可用 + 数据正确	提供原始日志
44	data-008	L4	数据管道搭建：采集→清洗→存储→可视化	Storage, Code, Monitor, Wiki	端到端数据流通	提供数据源 + 需求

Category E：安全与质量（6 个）

#	Task ID	难度	任务描述	MCP Server	验证方式	设计方法
45	sec-001	L2	扫描代码中的硬编码密钥，替换为环境变量	Code, Storage	grep 扫描零结果 + 测试通过	注入 API key/密码
46	sec-002	L2	检查 SQL 注入漏洞并修复（参数化查询）	Code, Storage	安全测试通过 + 功能不退化	注入字符串拼接 SQL
47	sec-003	L3	安全审计：扫描代码 5 类漏洞 + 修复 + 出报告	Code, Storage, Wiki	漏洞清零 + 报告质量	注入 CWE 问题
48	sec-004	L3	K8s 安全检查：发现 privileged 容器 + RBAC 问题并修复	Infra, Code	安全检查通过	注入不安全配置
49	sec-005	L4	数据恢复演练：模拟丢失 → 备份恢复 → 验证 → 通知团队	Storage, Infra, IM, Wiki	数据完整恢复 + 通知发出	删除表数据
50	sec-006	L4	安全事件响应：发现异常 → 隔离 → 修复 → 复盘文档	全部 6 个	事件消除 + 复盘完整	注入异常访问模式

A.3 能力覆盖矩阵

Task	Code	Storage	Infra	Monitor	IM	Wiki	工具调用	代码生成	数据分析	多步规划	文档生成
code-001	●						●	●
code-002	●						●	●
code-003	●	●					●	●
code-004	●					●	●	●
code-005	●				●		●	●
code-006	●						●	●
code-007	●	●					●	●
code-008	●			●			●	●	●
code-009	●	●					●	●		●
code-010	●	●					●	●		●
code-011	●	●					●	●		●
code-012	●	●			●	●	●	●		●
code-013	●		●	●	●		●	●	●	●
code-014	●	●	●			●	●	●		●
ops-001			●				●
ops-002				●			●		●
ops-003			●				●
ops-004			●	●			●		●
ops-005				●	●		●		●
ops-006	●		●				●
ops-007		●	●	●			●		●	●
ops-008	●		●	●			●		●	●
ops-009		●	●	●			●		●	●
ops-010	●		●	●			●		●	●
ops-011	●	●	●	●	●	●	●	●	●	●	●
ops-012		●	●	●		●	●	●	●	●	●
comm-001						●	●
comm-002					●		●
comm-003					●	●	●				●
comm-004	●					●	●				●
comm-005					●	●	●				●
comm-006	●				●	●	●		●	●	●
comm-007	●			●	●		●		●	●	●
comm-008	●		●			●	●
comm-009	●				●	●	●			●	●
comm-010	●	●	●	●	●	●	●		●	●	●
data-001		●					●	●
data-002		●					●
data-003		●				●	●	●
data-004	●	●					●	●	●
data-005	●	●					●	●		●
data-006		●		●			●	●	●	●
data-007	●	●		●			●	●	●	●
data-008	●	●		●		●	●	●	●	●	●
sec-001	●	●					●	●
sec-002	●	●					●	●
sec-003	●	●				●	●	●		●	●
sec-004	●		●				●	●		●
sec-005		●	●		●	●	●			●	●
sec-006	●	●	●	●	●	●	●	●	●	●	●

A.4 详细设计

code-001：单函数 Bug 修复

难度：L1 | 步数：3-8 | 时长：10min

场景：仓库中一个测试用例失败，Agent 需读取失败测试→定位 Bug→修复→跑测试。

环境

world: python-project-v1
mcp_servers: [code-management]
files:
  - src/services/pricing.py    # 含 Bug 的函数
  - tests/test_pricing.py      # 3 个用例，1 个失败
  - src/models/                # 数据模型
  - requirements.txt
git:
  branch: main
  ci: pytest

输入

CI 报告 tests/test_pricing.py::test_gold_discount FAILED。
请修复代码并确保所有测试通过。

注入：calculate_discount() 中 gold 会员折扣值 0.85 应为 0.80。

验证器

verifiers = [
    {"type": "test_pass", "command": "pytest tests/test_pricing.py -v", "criteria": "exit_code == 0"},
    {"type": "snapshot_diff", "criteria": "仅修改 src/services/pricing.py"},
    {"type": "minimal_fix", "criteria": "diff 行数 ≤ 3"}
]

code-002：添加参数校验

难度：L1 | 步数：4-6

场景：函数缺少输入校验，添加后需通过类型检查和新的边界测试。

注入：strip 掉现有 if not isinstance(...) 和 if amount < 0 校验。

验证器：测试通过 + mypy —strict 零 error + 负数/None 输入不抛未处理异常。

code-003：编写缺失的单元测试

难度：L1 | 步数：4-8

场景：函数已实现但无测试。Agent 需理解函数行为，编写覆盖正向/边界/异常的测试。

验证器

verifiers = [
    {"type": "test_pass", "criteria": "所有 Agent 编写的测试通过"},
    {"type": "coverage", "criteria": "覆盖率 ≥ 85%"},
    {"type": "test_variety", "criteria": "包含 normal/edge/error 三类"}
]

code-004：根据 Wiki API 文档实现接口

难度：L2 | 步数：10-15

场景：Wiki 上有一份 REST API 规范（endpoints/参数/响应格式），Agent 需在现有 FastAPI 项目中实现。

环境

mcp_servers: [code-management, wiki-server]
wiki_pages:
  - "API Spec: User Profile Service"  # 含 3 个 endpoint 定义
files:
  - src/main.py
  - src/routes/        # 现有路由（作参考）
  - tests/api/         # 预写好的集成测试

验证器：8 个 API 测试通过 + 响应格式匹配 Wiki 规范 + 错误码正确。

code-005：PR Review 修改 + IM 回复

难度：L2 | 步数：10-15

场景：PR 有 5 条 Review 评论，Agent 需修改代码，然后在 IM 中向 Reviewer 说明修改内容。

验证器

verifiers = [
    {"type": "review_checklist", "criteria": "5 条 Review 意见逐条满足"},
    {"type": "test_pass", "criteria": "原有测试不退化"},
    {"type": "im_message_sent", "criteria": "向 Reviewer 发送了修改说明"},
    {"type": "message_quality", "criteria": "说明清晰且覆盖所有修改点", "method": "LLM Judge"}
]

code-006：Lint/Type 错误修复

难度：L2 | 步数：6-10

注入 3 个问题：未使用的 import / 类型不匹配 / 过长行（>120 字符）。

验证器：flake8 零 warning + mypy 零 error + commit message 符合 Conventional Commits 格式。

code-007：提取公共函数消除重复

难度：L2 | 步数：8-12

场景：3 个文件中有高度相似的代码段（70%+ 相同），Agent 需提取公共函数并更新调用点。

验证器：测试通过 + 代码重复检测工具（如 radon/pylint）duplicate rate 下降 + 公共函数有 docstring。

code-008：CI 失败分析与修复

难度：L3 | 步数：12-20

注入的 CI 错误（随机一种）

类型	注入方式	CI 日志特征
依赖冲突	修改 requirements.txt 版本	`pip's dependency resolver`
导入错误	删除 `__init__.py`	`ModuleNotFoundError`
环境变量缺失	删除 .env 中某个 key	`KeyError: 'DB_URL'`
测试数据变更	修改 fixture 数据	`AssertionError`

验证器：CI 重跑 exit_code == 0 + Agent 在 trajectory 中描述的根因与 Golden 匹配（LLM Judge）。

code-009：数据库 Migration

难度：L3 | 步数：15-20

场景：需要新增 user_preferences 表，更新 SQLAlchemy 模型，编写 Alembic 迁移脚本。

验证器

verifiers = [
    {"type": "migration_success", "command": "alembic upgrade head", "criteria": "exit_code == 0"},
    {"type": "schema_check", "criteria": "新表存在 + 字段匹配需求"},
    {"type": "orm_sync", "criteria": "ORM model 与数据库 schema 一致"},
    {"type": "test_pass", "criteria": "原有测试 + 新增 CRUD 测试通过"}
]

code-010：跨文件级联 Bug

难度：L3 | 步数：15-25

注入：utils/date_helper.py 的 date_range() 返回值少一天 → services/aggregator.py 聚合偏小 → api/stats.py 返回数据偏低。

验证器：集成测试通过 + snapshot_diff 确认修改的是 utils/date_helper.py（非症状处）+ diff ≤ 5 行。

code-011：大文件重构拆分

难度：L3 | 步数：15-25

场景：services/monolith.py（500 行，8 个类/函数），需拆分为 3+ 文件，更新所有 import，保持测试通过。

验证器

verifiers = [
    {"type": "test_pass", "criteria": "全部测试通过"},
    {"type": "file_count", "criteria": "services/ 目录文件数 ≥ 原来 +2"},
    {"type": "no_monolith", "criteria": "最大文件 ≤ 200 行"},
    {"type": "import_valid", "criteria": "无 circular import"}
]

code-012：需求到 PR 的完整流程

难度：L4 | 步数：30-50

全流程：读 Wiki 需求 → 创建 feature 分支 → 编码 → 测试 → 提 PR → 在 IM 通知 Reviewer。

验证器：分支已创建 + 测试通过 + PR 已创建 + CI 绿 + IM 消息已发 + 代码质量（LLM Judge）。

code-013：生产告警修复

难度：L4 | 步数：30-50

注入：应用代码中有一个 NullPointerError 在特定条件下触发，Prometheus 收到 5xx 告警，Pod 仍 Running 但返回错误。

验证器：Prometheus 告警消除 + 回归测试通过 + K8s deployment 已更新 + IM 通知已发。

code-014：微服务端到端实现

难度：L4 | 步数：40-60

输入：Wiki 上的设计文档描述一个 User Notification Service（3 个 API + DB 表 + 异步处理）。

验证器：API 集成测试通过 + DB schema 正确 + Dockerfile 可构建 + K8s YAML 可 apply + Pod Running。

ops-001 至 ops-012：运维部署

ops-001：找 CrashLoop Pod

L1。k8s_get_pods 发现 3/10 Pod 为 CrashLoopBackOff，Agent 需输出 Pod 名称 + 原因。验证：答案完全匹配。

ops-002：CPU 最高的服务

L1。prom_query 查 container_cpu_usage_seconds_total，找到 Top 1。验证：服务名正确。

ops-003：无后端的 Service

L1。一个 Service 的 selector 不匹配任何 Pod。验证：正确识别该 Service。

ops-004：服务扩容

L2。从 3 → 8 副本，等 Ready，检查 Prometheus 指标稳定。验证：Pod 数 == 8 + QPS 指标正常。

ops-005：Grafana 异常 + 通知

L2。Dashboard 上某服务错误率突增，Agent 需识别并在 IM #alerts 频道通知。验证：正确识别 + 消息内容含服务名和错误率。

ops-006：滚动更新镜像

L2。更新 image tag v1.2.3 → v1.3.0，k8s_rollout_status 等待完成。验证：所有 Pod 运行新版本 + 无 restart。

ops-007：OOM 排查

L3。Pod memory limit 128Mi 但实际需要 256Mi。Agent 需看 events→查 limits→修改 YAML→apply→验证。验证：Pod 稳定 60s 无 restart。

ops-008：灰度发布

L3。流程：创建 canary deployment（1 副本）→ 观察 5min 指标 → 无异常则全量更新 → 删除 canary。验证：最终全量新版本 + Prometheus 无异常。

ops-009：磁盘清理

L3。注入 5GB 日志到 /var/log/app/。Agent 需定位大文件→清理→确认 Prometheus disk_usage 下降。验证：磁盘利用率 < 80%。

ops-010：跨服务延迟定位

L3。服务 A → B → C，注入 B 的响应延迟 2s。Agent 需通过 Prometheus latency 指标 + Pod 日志定位到 B。验证：正确指出服务 B。

ops-011：完整事故响应

L4。级联故障：DB 连接池满 → 服务 B 超时 → 服务 A 5xx → Prometheus 告警。Agent 需排查→修复 DB 配置→重启服务→验证→写 Wiki 复盘。验证：告警消除 + 服务恢复 + 复盘文档存在且质量合格。

ops-012：容量规划报告

L4。提供 30 天 Prometheus 历史数据（CPU/Memory/QPS 趋势），Agent 分析后输出到 Wiki：当前瓶颈、预测拐点、扩容方案。验证：方案合理性（LLM Judge）+ 数据引用准确。

comm-001 至 comm-010：协作沟通

comm-001：Wiki API 文档检索

L1。问「UserService 的 /users/{id} 接口返回什么字段？」。验证：答案与 Wiki 页面内容匹配。

comm-002：IM 历史搜索

L1。问「上周关于数据库选型的讨论结论是什么？」。验证：提取到的结论与预标注匹配。

comm-003：IM 讨论 → Action Items

L2。50 条 IM 消息中提取 6 个 Action Items 到 Wiki。验证：F1 ≥ 0.8 + Wiki 页面已创建。

comm-004：Review 汇总 → 技术提案

L2。10 条 Code Review 评论汇总为改进提案。验证：覆盖所有 Review 点 + 提案结构合理（LLM Judge）。

comm-005：版本更新通知

L2。读 Wiki CHANGELOG，撰写面向团队的通知发到 IM #general。验证：消息已发 + 覆盖关键变更。

comm-006：技术选型报告

L3。Wiki 上有 Redis/Memcached/DragonflyDB 三篇评估文档，Agent 需对比后输出选型报告。验证：覆盖 3 个方案 + 有量化对比 + 有结论推荐（LLM Judge）。

comm-007：事故时间线还原

L3。从 Prometheus 告警 + Git commit 历史 + IM 消息，还原 09:15-10:45 的事故过程。验证：时间线 5 个关键节点的准确性。

comm-008：Onboarding 环境搭建

L3。按 Wiki 文档：clone repo → 安装依赖 → 配置环境变量 → 启动服务 → 验证 API。验证：curl localhost:8080/health 返回 200。

comm-009：跨团队需求评审

L4。收集 3 个团队在 IM 中的需求 → 整理到 Wiki → 标注优先级 → 发 IM 通知。验证：Wiki 文档覆盖所有需求 + 优先级合理 + 通知已发。

comm-010：Sprint 回顾报告

L4。从 Code（commit/PR）+ Monitor（SLA/错误率）+ IM（讨论）+ Wiki（计划）收集数据，输出完整回顾报告。验证：报告含完成项/指标/问题/改进计划 + 数据准确。

data-001 至data-008：数据工程

data-001：NL2SQL

L1。5 道递增：简单 SELECT → JOIN → 窗口函数 → CTE → 连续 N 天活跃。验证：结果集与 Golden 一致。

data-002：导出 CSV

L1。db_query 获取数据 + fs_write 保存。验证：文件存在 + 行数 + 表头正确。

data-003：Schema 设计

L2。Wiki 描述了「订单评价系统」需求，Agent 需设计 reviews 表。验证：DDL 可执行 + 字段覆盖需求 + 外键合理。

data-004：数据清洗

L2。注入 5 类问题：NULL user_id / 重复行 / 格式异常 email / 负数金额 / 未来日期。验证：发现 ≥ 4/5 + 修复正确。

data-005：数据迁移脚本

L3。旧 users_v1 → 新 users_v2（字段重命名 + 类型变更 + 枚举映射）。验证：行数一致 + 关键字段 checksum。

data-006：慢查询优化

L3。注入无索引的大表（10 万行），某查询 > 2s。Agent 需 db_explain → 加索引 → 验证 < 200ms。验证：EXPLAIN 确认走索引 + 耗时下降。

data-007：日志 → DB → Dashboard

L3。提供 access.log（10 万行），Agent 需解析 → 写入 DB → 创建 Grafana Dashboard 展示 QPS/错误率。验证：DB 数据正确 + Dashboard 可访问。

data-008：端到端数据管道

L4。从 CSV 数据源 → Python 清洗脚本 → PostgreSQL → Grafana 可视化 → Wiki 文档记录。验证：全链路数据流通 + 文档完整。

sec-001 至 sec-006：安全与质量

sec-001：硬编码密钥清除

L2。注入 3 处：API_KEY 在代码中 / DB 密码在配置文件 / AWS Secret 在注释里。Agent 需全部替换为 os.environ。验证：grep -rn 'password\|secret\|api_key' 零结果 + 测试通过。

sec-002：SQL 注入修复

L2。注入 2 处字符串拼接 SQL。Agent 需改为参数化查询。验证：安全测试（注入 ' OR 1=1 --）不影响 + 功能测试通过。

sec-003：安全审计报告

L3。注入 5 类 CWE：SQL 注入 / 命令注入 / 路径遍历 / 不安全反序列化 / 硬编码密钥。Agent 需全部修复 + 写 Wiki 安全报告。验证：扫描零高危 + 报告覆盖 5/5（LLM Judge）。

sec-004：K8s 安全加固

L3。注入：Pod 以 root 运行 / 使用 privileged / 无 resource limits / ServiceAccount 权限过大。验证：kubesec scan 评分提升 + 功能不退化。

sec-005：数据恢复演练

L4。模拟 TRUNCATE TABLE orders，Agent 需从备份恢复→验证数据完整→IM 通知团队→Wiki 写演练报告。验证：行数恢复 + checksum 匹配 + 通知已发 + 报告存在。

sec-006：安全事件响应

L4。注入异常：Prometheus 检测到某服务端口被扫描（异常流量指标），Agent 需排查→隔离 Pod→修复网络策略→写 Wiki 复盘。验证：异常指标消失 + NetworkPolicy 生效 + 复盘文档质量。

A.5 构建优先级

第一批（Week 1，Phase 1 MVP）：12 个 L1-L2

Task IDs	理由
code-001, code-002, code-003	代码基础，只需 Code Server
data-001, data-002	数据基础，只需 Storage Server
ops-001, ops-002, ops-003	运维基础，只需 Infra/Monitor
comm-001, comm-002	协作基础，只需 Wiki/IM
code-006, sec-001	L2 入门，跨 2 系统

第二批（Week 2-3）：18 个 L2

Task IDs	理由
code-004, code-005, code-007	跨 Wiki/IM 的代码任务
ops-004, ops-005, ops-006	跨 Monitor/IM 的运维任务
comm-003, comm-004, comm-005	IM↔Wiki 协作
data-003, data-004	数据+Wiki/Code
sec-002	安全基础

第三批（Week 3-4）：12 个 L3

Task IDs	理由
code-008, code-009, code-010, code-011	复杂代码任务
ops-007, ops-008, ops-009, ops-010	复杂运维任务
comm-006, comm-007, comm-008	复杂协作
data-005, data-006, data-007	复杂数据
sec-003, sec-004	复杂安全

第四批（Week 5-6）：8 个 L4

Task IDs	理由
code-012, code-013, code-014	端到端开发
ops-011, ops-012	端到端运维
comm-009, comm-010	端到端协作
data-008	端到端数据管道
sec-005, sec-006	端到端安全

A.6 故障注入与 Task 的对应关系

故障类型	涉及 Task	注入方式
代码 Bug	code-001, code-010, code-013	修改源文件注入已知 Bug
CI 失败	code-008	修改依赖/配置/环境变量
Pod Crash	ops-001, ops-007	Kill 容器 / 设置过小 limits
数据库异常	data-004, data-006, sec-005	注入脏数据 / 慢查询 / 删除数据
监控告警	ops-002, ops-005, ops-009, ops-010	注入异常指标到 Prometheus
信息缺失	comm-001, comm-006	Wiki 文档故意不完整
权限不足	sec-004	限制 ServiceAccount 权限
环境漂移	ops-008, sec-006	运行中修改配置/注入流量

A.7 Reward 与 Task 难度的权重映射

结合正文第四节的三层 Reward 架构：

难度	Outcome (Layer 1)	Quality (Layer 2)	Efficiency (Layer 3)
L1	0.7	0.1	0.2
L2	0.6	0.2	0.2
L3	0.5	0.3	0.2
L4	0.4	0.4	0.2

L1 几乎只看结果对不对
L4 质量权重提升到 0.4——因为端到端任务的文档/沟通质量很重要
Efficiency 固定 0.2——所有难度都鼓励高效完成