腾讯生态 Agent RL Environment 构建蓝图

目标：参照 APEX-Agents / Archipelago 的设计范式，结合腾讯公司内部平台生态，设计一套可落地的 Agent RL Environment 体系
范围：14 大领域（8 内部工具链 + 6 ToB 行业）· 腾讯生态 40+ 平台/API（含微信/QQ/视频号全生态） · 外部参考框架 15+ · 30+ MCP Server
2026.04.15

---

一、背景与动机

1.1 为什么要自建 RL Environment

当前 Agent 评测和训练的核心瓶颈不是模型能力，而是环境。模型能力的天花板取决于它能在什么样的环境中练习、犯错、迭代。

维度	纯文本 Benchmark	RL Environment
反馈形式	单次打分	多轮交互 + 状态变化
环境复杂度	固定 prompt	真实文件系统 + 应用 + API
可训练性	仅评测	可产出训练轨迹
业务贴合度	通用学术场景	可定制为企业内部场景

腾讯的独特优势：拥有从 C 端超级入口（微信/QQ/视频号）、文档协作（腾讯文档）、项目管理（TAPD/CODING）、数据库（TDSQL）、云基础设施（CloudBase/COS/SCF）到企业通讯（企业微信）的完整闭环。这意味着可以构建覆盖 C 端用户触达到 B 端企业管理的全链路 Agent 环境——而不只是学术 benchmark。

1.2 参照系：APEX-Agents 做了什么

Mercor 的 APEX-Agents 是当前最成熟的专业服务领域 Agent 评测框架：

World（工作环境快照）
  ├── 100-600+ 文件的真实文件系统
  ├── 应用数据（.apps_data/）
  └── MCP Server 配置
        ↓
Task（具体任务）
  ├── Prompt + 输入文件
  ├── 评分 Rubric（Verifiers）
  └── Golden Response（标准答案）
        ↓
Eval（评测）
  ├── Agent 执行轨迹（Trajectory）
  ├── 环境快照对比（Snapshot Diff）
  └── 双轨评分（Judge + GT）

Archipelago（开源评测框架）的核心架构：

• Environment：Docker 容器化沙箱，通过 MCP Gateway 暴露工具
• Agents Runner：编排 Agent 生命周期，管理沙箱生成与销毁
• Grading：快照对比 → 差异提取 → 多维度验证 → 评分

关键设计决策：Agent 通过 MCP 协议与环境交互（而非直接操作文件系统），实现操作的精确记录和权限控制。

---

二、外部参考框架全景

在设计我们自己的环境之前，先梳理外部已有的成熟方案。

2.1 评测导向框架

框架	领域	环境形态	MCP 支持	适合做 RL 训练	关键特点
APEX-Agents	投行/咨询/法律	Docker + MCP Gateway	✅ 原生	✅ 轨迹数据	专业服务场景，400 Task
SWE-bench	代码修复	Git Repo + 测试用例	❌	✅ 大量用	GitHub Issue → PR，500 实例
WebArena	Web 操作	真实网站容器	❌	⚠️ 需适配	电商/论坛/CMS/地图 4 类网站
OSWorld	桌面操作	VM（Ubuntu/Windows/macOS）	❌	⚠️ 重量级	真实 OS 环境，支持 GUI 交互
AgentBench	多领域综合	8 类环境	❌	⚠️	DB/OS/知识图谱/Web 等
Terminal-Bench	终端操作	Docker + Terminal	❌	✅	编译/部署/训练模型等终端任务
τ-bench	工具调用	模拟 API + 数据库	❌	✅	零售/航空客服场景
MCP-AgentBench	MCP 工具调用	MCP Server Testbed	✅ 原生	✅	专门评测 MCP 工具使用能力
InfiAgent-DABench	数据分析	Python + 数据集	❌	⚠️	端到端数据分析任务

2.2 训练导向框架

框架	核心方法	环境对接方式	关键能力
ART (OpenPipe)	GRPO + RULER 自动评分	MCP Server 原生集成	无需标注数据，自动生成场景
AgentGym-RL	PPO/GRPO + 多环境并行	统一 AgentGym 接口	14 类环境，支持 RL 训练
RAGEN	多轮 RL + 自进化	自定义环境接口	研究 reasoning collapse 问题
verl	异步 Agentic RL	Server-based 环境	字节开源，工业级训练框架

2.3 关键洞察

1. MCP 正在成为 Agent-Environment 接口标准——APEX-Agents、ART/MCP-RL、MCP-AgentBench 都选择了 MCP
2. Docker 容器化是环境隔离的事实标准——几乎所有框架都用 Docker
3. 快照对比是最可靠的评测方式——不依赖中间过程，只看最终状态变化
4. 训练和评测的环境可以复用——好的评测环境稍加改造就是训练环境

---

三、腾讯生态可用资源盘点

这是构建环境的”原材料清单”。

3.1 开放平台与 API

平台/产品	API 类型	可构建的 Agent 场景	MCP Server 可行性
腾讯文档	Open API (HTTPS)	文档创建/编辑/协作/数据读取	✅ 已有官方 MCP
TAPD	Open API	需求/缺陷/任务/迭代管理	✅ 可封装
CODING DevOps	Open API	代码仓库/CI-CD/制品库/项目管理	✅ 可封装
企业微信	Open API + Webhook	消息推送/审批/日程/通讯录	✅ 可封装
腾讯会议	Open API	会议创建/管理/录制	✅ 已有 MCP
腾讯云 API	HTTPS (300+ API)	云资源管理/运维自动化	✅ 已有 SDK
微信公众平台	Open API	内容管理/用户管理/消息推送/模板消息	✅ 已有社区 MCP
微信视频号	视频号助手 API	直播管理/橱窗管理/数据分析/留资组件	✅ 可封装
微信开放平台	Open API	第三方应用授权/小程序管理/开放能力代调用	✅ 可封装
QQ 开放平台	QQ Bot API v2	QQ 机器人（群聊/频道/消息/日程/表情回应）	✅ 可封装
腾讯位置服务	Open API	地理编码/路线规划/POI 搜索	✅ 已有官方 MCP
腾讯广告	Marketing API	广告投放/数据分析/报表	⚠️ 需授权

3.2 云基础设施

产品	能力	Agent 环境用途
CloudBase 云开发	云函数 + 数据库 + 存储 + MCP	一站式后端环境，天然支持 MCP Server 部署
COS 对象存储	文件存储 + CDN	环境快照存储、任务文件分发
SCF 云函数	Serverless 函数	Agent 工具的轻量级运行时
TDSQL / 云数据库	MySQL / PostgreSQL / Redis	数据库操作类 Task 的底层支撑
Agent 沙箱 (AgentSandbox)	安全代码执行环境	Agent 代码执行的隔离沙箱
Code-MCP Server	基于 AgentSandbox 的 MCP	代码执行 + 沙箱管理，原生 MCP 协议
CVM 云服务器 + TAT 自动化助手	服务器管理 + 命令执行	云运维环境的基础计算资源（已有 MCP）
CLS 日志服务	日志采集/检索/分析	运维日志查询类 Task 的数据源（已有官方 MCP）
TCA 代码分析	代码质量/安全/规范扫描	软件工程 Code Review 类 Task（已有官方 MCP）
EdgeOne Pages	静态站点一键部署	前端/小程序部署环节（已有官方 MCP）
HAI 高性能应用	GPU 实例管理	AI 模型训练/推理类 Task 的算力资源（已有 MCP）
TKE 容器服务	Kubernetes	环境容器编排和调度
混元大模型	LLM API	Agent 的推理后端 / 评分 Judge

3.3 内部工具链

工具	能力	环境构建价值
CodeBuddy	AI 编程助手	Agent 编码能力的载体和测试平台
乐享知识库	企业知识管理	知识检索类 Task 的数据源
腾讯 iOA	终端管理	企业终端环境快照的来源
腾讯翻译君	翻译 API	多语言任务环境的组件

---

四、分领域 RL Environment 设计（Part A：内部工具链）

核心思路：每个领域定义 World（环境）→ Task（任务）→ Verifier（验证器）三层结构，复用 Archipelago 的 Docker + MCP 架构。

Part A 覆盖 8 个基于腾讯内部工具链的领域，Part B（4B 节）覆盖 6 个 ToB 行业垂直领域。

4.1 领域一：软件工程（DevOps）

对标：SWE-bench + Terminal-Bench
腾讯生态依赖：CODING DevOps + TAPD + Code-MCP Server + AgentSandbox

World 定义

{
  "domain": "software_engineering",
  "description": "模拟腾讯内部研发流程的完整开发环境",
  "services": [
    {
      "name": "coding-mcp",
      "type": "mcp",
      "description": "CODING 代码仓库和 CI/CD 操作"
    },
    {
      "name": "tapd-mcp",
      "type": "mcp",
      "description": "TAPD 项目管理和需求跟踪"
    },
    {
      "name": "code-executor",
      "type": "mcp",
      "description": "基于 AgentSandbox 的代码执行环境"
    },
    {
      "name": "tca-mcp",
      "type": "mcp",
      "description": "腾讯云 TCA 代码质量分析（缺陷/安全/规范/复杂度）"
    }
  ],
  "world_files": {
    "filesystem": "典型 Python/Go/Node 项目结构 + 测试用例",
    "apps_data": "TAPD 需求列表 + CODING 仓库状态 + CI 流水线配置"
  }
}

Task 示例

Task ID	难度	描述	预计时长	验证方式
se-001	L1	根据 TAPD 需求描述，在 CODING 仓库中修复指定 Bug	15min	测试用例全通过 + CI 绿
se-002	L2	阅读 PR Review 评论，重构代码并回复 Review 意见	30min	代码质量评分 + Review 回复质量
se-003	L3	分析 CI 流水线失败日志，定位根因并修复	45min	CI 重跑成功 + 根因分析准确性
se-004	L4	根据产品需求文档，完成功能开发 + 测试 + MR 提交	2h	端到端功能验证 + 代码规范
se-005	L2	使用 TCA 扫描代码仓库，分析质量报告并修复 Top-5 高危问题	30min	TCA 复扫零高危 + 修复合理性

Verifier 设计

verifiers = [
    {
        "type": "output",
        "criteria": "所有单元测试通过",
        "method": "运行 pytest/go test，检查 exit code"
    },
    {
        "type": "output",
        "criteria": "CI 流水线状态为 success",
        "method": "查询 CODING CI API 获取最新构建状态"
    },
    {
        "type": "trajectory",
        "criteria": "Agent 没有暴力搜索或无效循环",
        "method": "分析 tool_call 序列的效率"
    }
]

---

4.2 领域二：办公协作（Office Automation）

对标：APEX-Agents（咨询/法律场景）
腾讯生态依赖：腾讯文档 + 企业微信 + 腾讯会议

World 定义

{
  "domain": "office_automation",
  "description": "模拟企业日常办公流程",
  "services": [
    {
      "name": "tencent-docs-mcp",
      "type": "mcp",
      "description": "腾讯文档的创建/编辑/协作"
    },
    {
      "name": "wecom-mcp",
      "type": "mcp",
      "description": "企业微信消息/审批/日程"
    },
    {
      "name": "meeting-mcp",
      "type": "mcp",
      "description": "腾讯会议的创建/管理"
    },
    {
      "name": "filesystem",
      "type": "mcp",
      "description": "本地文件系统操作"
    }
  ],
  "world_files": {
    "filesystem": "项目计划书/周报模板/会议纪要/合同草稿",
    "apps_data": "企微通讯录 + 日程数据 + 文档共享列表"
  }
}

Task 示例

Task ID	难度	描述	验证方式
oa-001	L1	根据会议纪要整理 Action Items 并在企微通知相关人	消息发送成功 + 内容准确性
oa-002	L2	基于多份数据报表，生成周报并发布到腾讯文档	文档格式 + 数据准确性 + 分析深度
oa-003	L3	协调多方日程，安排跨部门评审会并准备议程文档	时间冲突检测 + 议程完整性
oa-004	L4	根据客户需求邮件，完成方案撰写 + 内部审批 + 会议安排	端到端流程完成度

---

4.3 领域三：数据工程（Data Engineering）

对标：InfiAgent-DABench + τ-bench
腾讯生态依赖：TDSQL + COS + CloudBase + 云函数

World 定义

{
  "domain": "data_engineering",
  "description": "模拟数据开发和治理场景",
  "services": [
    {
      "name": "database-mcp",
      "type": "mcp",
      "description": "TDSQL/MySQL 数据库操作"
    },
    {
      "name": "cos-mcp",
      "type": "mcp",
      "description": "COS 对象存储文件操作"
    },
    {
      "name": "code-executor",
      "type": "mcp",
      "description": "Python/SQL 代码执行"
    },
    {
      "name": "scheduler-mcp",
      "type": "mcp",
      "description": "调度系统模拟"
    }
  ],
  "world_files": {
    "filesystem": "ETL 脚本 + dbt 项目 + 数据字典 + 质量规则",
    "apps_data": "数据库 Schema + 采样数据 + 调度 DAG 配置"
  }
}

Task 示例

Task ID	难度	描述	验证方式
de-001	L1	编写 SQL 查询满足业务分析需求	查询结果正确性 + 性能
de-002	L2	诊断数据管道失败并修复 ETL 脚本	管道重跑成功 + 数据一致性
de-003	L3	设计数据仓库分层架构（ODS→DWD→DWS→ADS）	Schema 合理性 + 文档质量
de-004	L4	端到端数据迁移：评估 → 方案设计 → 执行 → 验证	数据完整性 + 零丢失

---

4.4 领域四：云运维（Cloud Operations）

对标：Terminal-Bench + AgentBench(OS)
腾讯生态依赖：腾讯云 API + TKE + CVM + CLB + 云监控

World 定义

{
  "domain": "cloud_operations",
  "description": "模拟腾讯云资源管理和运维场景",
  "services": [
    {
      "name": "tencent-cloud-mcp",
      "type": "mcp",
      "description": "腾讯云 API（CVM/TKE/CLB/COS 等）"
    },
    {
      "name": "terminal",
      "type": "mcp",
      "description": "服务器终端操作"
    },
    {
      "name": "monitoring-mcp",
      "type": "mcp",
      "description": "云监控告警数据"
    },
    {
      "name": "cls-mcp",
      "type": "mcp",
      "description": "腾讯云 CLS 日志检索与分析"
    },
    {
      "name": "cvm-mcp",
      "type": "mcp",
      "description": "CVM 实例管理 + TAT 自动化命令执行"
    }
  ],
  "world_files": {
    "filesystem": "运维脚本 + Terraform 配置 + K8s YAML",
    "apps_data": "CVM 实例列表 + 监控指标 + 告警规则 + 日志"
  }
}

Task 示例

Task ID	难度	描述	验证方式
co-001	L1	根据告警信息定位异常实例并重启服务	服务恢复 + 告警清除
co-002	L2	分析监控指标，优化 K8s 资源配置（HPA/资源配额）	资源利用率提升 + 无服务中断
co-003	L3	故障演练：模拟节点宕机，完成故障转移和恢复	RTO 达标 + 数据无损
co-004	L4	从零搭建高可用架构：多 AZ 部署 + CLB + 自动伸缩	架构评审 + 压测通过
co-005	L2	通过 CLS 日志检索定位线上报错根因，并编写修复脚本执行	根因准确 + 报错消失 + 脚本可复用

---

4.5 领域五：产品运营（Product Operations）

对标：APEX-Agents（咨询场景）
腾讯生态依赖：腾讯广告 API + 微信公众平台 + 微信视频号助手 API + 腾讯文档 + 数据分析

Task 示例

Task ID	难度	描述	验证方式
po-001	L1	根据广告投放数据生成周报	数据准确性 + 分析深度
po-002	L2	设计 A/B 测试方案并配置投放计划	方案合理性 + 配置正确性
po-003	L3	分析用户画像数据，制定精准营销策略	策略可执行性 + ROI 预估合理性
po-004	L4	端到端运营活动：策划 → 素材准备 → 投放配置 → 效果分析	全流程完成度
po-005	L2	分析视频号直播数据（观看/互动/转化），生成场次复盘报告	数据准确性 + 优化建议可行性
po-006	L3	制定视频号 + 公众号 + 小程序联动的内容运营方案	策略完整性 + 平台间串联逻辑

---

4.6 领域六：客户服务（Customer Service）

对标：τ-bench（零售/航空客服）
腾讯生态依赖：企业微信客服 API + 知识库 + 工单系统

Task 示例

Task ID	难度	描述	验证方式
cs-001	L1	根据用户问题查询知识库并回复	回答准确性 + 响应速度
cs-002	L2	处理退款申请：查单 → 判断政策 → 执行退款	政策遵循 + 操作正确
cs-003	L3	处理升级投诉：安抚用户 + 多系统协调 + 方案制定	用户满意度 + 合规性
cs-004	L4	疑难问题处理：跨部门协调 + 工单流转 + 根因分析	问题解决率 + 处理时效

---

4.7 领域七：安全合规（Security & Compliance）

腾讯生态依赖：主机安全 API + WAF + 安全运营中心

Task 示例

Task ID	难度	描述	验证方式
sc-001	L1	分析安全告警日志，判断是否误报	判断准确率
sc-002	L2	漏洞扫描结果分析 + 修复方案制定	修复有效性
sc-003	L3	安全事件应急响应：溯源 → 止损 → 修复 → 报告	全流程时效 + 报告质量

---

4.8 领域八：小程序开发（Mini-Program Dev）

腾讯生态依赖：微信小程序 API + QQ 小程序 API + 云开发 + CloudBase MCP + EdgeOne Pages

Task 示例

Task ID	难度	描述	验证方式
mp-001	L1	根据设计稿实现小程序页面	UI 还原度 + 功能正确性
mp-002	L2	接入云开发数据库，实现增删改查	数据操作正确性 + 性能
mp-003	L3	集成微信支付 + 订单系统	支付流程完整 + 异常处理
mp-004	L4	完整小程序开发：需求分析 → 开发 → 测试 → 发布	端到端可用性
mp-005	L2	使用 EdgeOne Pages 一键部署 H5 页面并配置自定义域名	部署成功 + 页面可访问 + HTTPS 正常

---

4B. ToB 行业领域 RL Environment 设计

以上 8 个领域偏向腾讯内部工具链和通用能力。但腾讯 ToB 业务覆盖了金融、医疗、教育、零售、政务、出行等多个垂直行业，这些行业恰恰是 Agent 价值最高的场景——专业门槛高、流程复杂、合规要求严格、评测难度大。

4.9 领域九：金融服务（Financial Services）

对标：Finance Agent Benchmark (Vals AI / Stanford) + InvestorBench + FinRL + τ-bench
腾讯生态依赖：天御风控 API + 微信支付 API + 腾讯云 OCR（票据/合同）+ TDSQL 金融版 + 金融云合规基座

外部参考框架

框架	发布方	核心能力	环境形态
Finance Agent Benchmark	Vals AI / Stanford	SEC 文档分析 + 时间敏感金融研究	真实 SEC EDGAR 数据 + 工具链
InvestorBench	ACL 2025	多 Agent 投资决策评测	市场数据 + 多信号源
FinRL	AI4Finance	量化交易 RL 训练	模拟市场环境
TradingAgents	多 Agent 交易框架	基金经理/分析师/风控角色协作	LLM 多 Agent

World 定义

{
  "domain": "financial_services",
  "description": "模拟金融机构的核心业务场景",
  "services": [
    {
      "name": "risk-control-mcp",
      "type": "mcp",
      "description": "基于天御的风控决策引擎（反欺诈/信用评估/交易风控）"
    },
    {
      "name": "payment-mcp",
      "type": "mcp",
      "description": "微信支付 API 封装（交易查询/退款/对账）"
    },
    {
      "name": "ocr-mcp",
      "type": "mcp",
      "description": "腾讯云 OCR 票据/合同/财报识别"
    },
    {
      "name": "database-mcp",
      "type": "mcp",
      "description": "TDSQL 金融版数据库操作"
    },
    {
      "name": "compliance-checker",
      "type": "mcp",
      "description": "金融合规规则引擎"
    },
    {
      "name": "market-data-mcp",
      "type": "mcp",
      "description": "行情数据 + 财务指标查询"
    }
  ],
  "world_files": {
    "filesystem": "财报 PDF / 合同扫描件 / 交易流水 / 审计底稿 / 政策法规文本",
    "apps_data": "客户画像数据 + 风控规则库 + 交易历史 + 持仓数据"
  }
}

Task 示例

Task ID	子领域	难度	描述	验证方式
fin-001	风控	L1	根据交易流水 + 用户画像，判断一笔交易是否存在欺诈风险	判断准确率 + 合规性
fin-002	信贷	L2	完成一笔贷款申请的全流程审核（征信查询 → 风险评估 → 额度计算 → 审批建议）	评估合理性 + 政策合规
fin-003	投研	L3	基于 10-K/10-Q 财报和行情数据，撰写一家公司的投资分析报告	数据准确性 + 分析深度 + 结论合理性
fin-004	合规	L3	审查一份金融合同，识别风险条款并出具合规审查意见	条款识别召回率 + 意见专业性
fin-005	对账	L2	对照支付流水和财务账本，完成日终对账并生成差异报告	差异发现率 + 报告准确性
fin-006	理赔	L4	保险理赔全流程：受理 → 单证审核（OCR 提取 + 交叉验证）→ 定损 → 赔付建议	端到端准确率 + 时效

Verifier 设计

verifiers = [
    {
        "type": "output",
        "criteria": "风控决策与标准答案一致",
        "method": "对比 golden_response 中的决策结果"
    },
    {
        "type": "compliance",
        "criteria": "所有操作符合金融监管要求",
        "method": "规则引擎校验操作序列合规性"
    },
    {
        "type": "llm_judge",
        "criteria": "分析报告的专业性和可操作性",
        "method": "金融领域 Judge 评分"
    },
    {
        "type": "numerical",
        "criteria": "财务数字计算正确",
        "method": "关键数值误差 < 0.01%"
    }
]

特殊考量：

• 数据脱敏：所有金融数据必须经过脱敏处理（姓名/身份证/卡号替换）
• 合规约束：Agent 操作序列必须符合金融行业操作规范，违反合规直接扣分
• 时间敏感性：部分任务要求在模拟的市场时间窗口内完成（如盘中风控决策）

---

4.10 领域十：医疗健康（Healthcare）

对标：MedAgentBench (Stanford ML Group) + AgentClinic
腾讯生态依赖：腾讯觅影（AI 影像）+ 腾讯医典 API + 腾讯云 OCR（医疗报告）+ 腾讯健康数据算法

外部参考框架

框架	发布方	核心能力	环境形态
MedAgentBench	Stanford ML Group	虚拟 EHR 环境下的医疗 Agent 评测	FHIR 标准 EHR 系统 + 100+ 临床任务
AgentClinic	多模态临床环境模拟	患者交互 + 多模态数据采集 + 诊断	模拟诊室（对话 + 影像 + 检验）

World 定义

{
  "domain": "healthcare",
  "description": "模拟医疗机构的临床和管理场景",
  "services": [
    {
      "name": "ehr-mcp",
      "type": "mcp",
      "description": "电子病历系统操作（基于 FHIR 标准模拟）"
    },
    {
      "name": "medical-image-mcp",
      "type": "mcp",
      "description": "基于腾讯觅影的医学影像 AI 辅助分析"
    },
    {
      "name": "medical-ocr-mcp",
      "type": "mcp",
      "description": "医疗报告/处方/检验单 OCR 识别"
    },
    {
      "name": "medical-knowledge-mcp",
      "type": "mcp",
      "description": "基于腾讯医典的医学知识库检索"
    },
    {
      "name": "pharmacy-mcp",
      "type": "mcp",
      "description": "药品数据库 + 药物相互作用检查"
    }
  ],
  "world_files": {
    "filesystem": "患者病历 / 检验报告 / 影像图片 / 用药记录 / 诊疗指南",
    "apps_data": "患者档案 + 排班数据 + 药品库存 + 医保目录"
  }
}

Task 示例

Task ID	子领域	难度	描述	验证方式
med-001	分诊	L1	根据患者主诉和症状描述，给出分诊建议（科室 + 紧急程度）	分诊准确率 + 紧急程度判断
med-002	诊断辅助	L2	综合检验报告 + 影像结果 + 病史，生成鉴别诊断列表	诊断覆盖率 + 排序合理性
med-003	用药审查	L2	审查住院患者的用药医嘱，识别潜在药物相互作用和禁忌	危险交互识别召回率
med-004	病历书写	L3	根据门诊对话记录，生成结构化电子病历（主诉/现病史/诊断/处置）	病历规范性 + 信息完整性
med-005	质控	L3	审查出院病历质量，识别缺陷项并出具质控报告	缺陷识别率 + 报告专业性
med-006	临床决策	L4	复杂病例讨论：多系统疾病患者的诊疗方案制定	方案合理性 + 循证依据 + 多学科协调

特殊考量：

• 患者隐私：所有数据必须使用合成数据或深度脱敏数据
• 安全红线：Agent 不能直接下达医嘱，仅提供辅助建议（模拟中标注为”AI 建议”）
• 循证要求：诊断和用药建议必须引用证据来源（指南/文献），可评分

---

4.11 领域十一：教育（Education）

对标：LLM Agents for Education (EMNLP 2025 Survey) + 教育 Multi-Agent 评估
腾讯生态依赖：腾讯教育 AI 平台 + 腾讯文档 + 腾讯会议 + 混元大模型

外部参考

教育领域尚无成熟的 Agent RL Environment（推测这是蓝海），但有几个方向已有研究基础：

• ACL/EMNLP 2025 多篇综述梳理了 LLM Agent 在教育中的应用（智能辅导/自动出题/作业批改/学情分析）
• Multi-Agent 模拟教室环境（学生 Agent + 教师 Agent 交互）
• 腾讯教育 AI 已落地 AI 作业批改、动态测评、学情分析等功能

World 定义

{
  "domain": "education",
  "description": "模拟教育教学的全流程场景",
  "services": [
    {
      "name": "learning-platform-mcp",
      "type": "mcp",
      "description": "在线学习平台操作（课程/作业/考试管理）"
    },
    {
      "name": "tencent-docs-mcp",
      "type": "mcp",
      "description": "腾讯文档（试卷/教案/学情报告编辑）"
    },
    {
      "name": "student-simulator",
      "type": "mcp",
      "description": "模拟不同水平的学生 Agent（用于辅导场景）"
    },
    {
      "name": "knowledge-graph-mcp",
      "type": "mcp",
      "description": "学科知识图谱查询（知识点关联/前置依赖）"
    },
    {
      "name": "assessment-engine",
      "type": "mcp",
      "description": "自动评测引擎（客观题自动批改 + 主观题评分）"
    }
  ],
  "world_files": {
    "filesystem": "教案 / 试卷库 / 学生作业 / 课程大纲 / 知识点图谱",
    "apps_data": "学生画像 + 学习记录 + 成绩数据 + 错题本"
  }
}

Task 示例

Task ID	子领域	难度	描述	验证方式
edu-001	出题	L1	根据知识点和难度要求，生成一套数学测试卷	知识点覆盖率 + 难度分布合理性
edu-002	批改	L2	批改一组学生的主观题作业（含解题过程评价 + 个性化反馈）	评分一致性 + 反馈质量
edu-003	辅导	L3	与模拟学生 Agent 进行一对一辅导对话（引导式教学，不直接给答案）	教学策略合理性 + 学生理解提升度
edu-004	学情分析	L3	分析一个班级的考试数据，生成学情报告和个性化教学建议	数据分析准确性 + 建议可操作性
edu-005	课程设计	L4	根据课程标准设计完整的教学方案（知识点拆解 → 课时安排 → 教学活动 → 评估方式）	方案完整性 + 教育理论合规

特殊考量：

• 学生模拟器是核心难点——需要模拟不同水平/性格/学习风格的学生，这本身就是一个有趣的 RL 问题
• 评估的”软”指标：教育效果评估比工程领域更模糊，需要更多依赖 LLM Judge
• 腾讯教育 AI 的”因材施教”能力可以直接作为 baseline

---

4.12 领域十二：智慧零售（Smart Retail）

对标：τ-bench（零售客服）+ WebArena（电商网站操作）
腾讯生态依赖：微信小程序 + 微信支付 + 微信视频号 + 腾讯广告 API + 企业微信（导购）+ 腾讯云商付

World 定义

{
  "domain": "smart_retail",
  "description": "模拟零售/电商业务全链路",
  "services": [
    {
      "name": "ecommerce-mcp",
      "type": "mcp",
      "description": "电商平台操作（商品/订单/库存/物流）"
    },
    {
      "name": "payment-mcp",
      "type": "mcp",
      "description": "微信支付（交易/退款/对账/分账）"
    },
    {
      "name": "ads-mcp",
      "type": "mcp",
      "description": "腾讯广告投放（创建/优化/数据分析）"
    },
    {
      "name": "wecom-mcp",
      "type": "mcp",
      "description": "企业微信导购（客户管理/消息触达/社群运营）"
    },
    {
      "name": "miniprogram-mcp",
      "type": "mcp",
      "description": "小程序商城管理"
    },
    {
      "name": "channels-mcp",
      "type": "mcp",
      "description": "视频号直播电商（直播管理/橱窗/数据分析/留资）"
    },
    {
      "name": "analytics-mcp",
      "type": "mcp",
      "description": "销售数据分析 + 用户行为分析"
    }
  ],
  "world_files": {
    "filesystem": "商品目录 / 促销规则 / 供应商合同 / 运营 SOP",
    "apps_data": "订单数据 + 库存状态 + 会员画像 + 广告投放记录"
  }
}

Task 示例

Task ID	子领域	难度	描述	验证方式
ret-001	客服	L1	处理客户的退换货咨询（查单 → 判断政策 → 执行操作）	政策遵循 + 操作正确 + 响应质量
ret-002	选品	L2	根据销售数据和市场趋势，推荐下季度选品方案	数据分析深度 + 推荐合理性
ret-003	营销	L3	策划一场大促活动：选品 → 定价 → 广告投放 → 社群推送 → 效果预估	方案可执行性 + ROI 合理性
ret-004	供应链	L3	根据销售预测和库存状况，生成补货计划并协调供应商	预测准确性 + 库存周转优化
ret-005	全域运营	L4	从零搭建私域运营体系：企微导购 → 社群分层 → 内容策略 → 转化漏斗	端到端完成度 + 数据闭环
ret-006	直播电商	L3	策划视频号直播带货：选品上架 → 直播脚本 → 橱窗配置 → 实时数据监控 → 场次复盘	橱窗配置正确 + 数据分析深度

---

4.13 领域十三：数字政务（Digital Government）

对标：τ-bench（服务场景）+ APEX-Agents（文档分析）
腾讯生态依赖：政务微信 + 腾讯电子签 + 腾讯问卷 + 腾讯云 OCR + 数字人 + 腾讯云大数据平台

World 定义

{
  "domain": "digital_government",
  "description": "模拟政务服务和公共管理场景",
  "services": [
    {
      "name": "gov-service-mcp",
      "type": "mcp",
      "description": "政务服务平台操作（事项办理/材料审核/进度查询）"
    },
    {
      "name": "ocr-mcp",
      "type": "mcp",
      "description": "证照识别 + 表单识别"
    },
    {
      "name": "esign-mcp",
      "type": "mcp",
      "description": "腾讯电子签（合同签署/模板管理）"
    },
    {
      "name": "data-platform-mcp",
      "type": "mcp",
      "description": "政务数据平台（跨部门数据查询/统计分析）"
    },
    {
      "name": "citizen-simulator",
      "type": "mcp",
      "description": "模拟不同类型的办事市民"
    }
  ],
  "world_files": {
    "filesystem": "政策法规文本 / 审批流程图 / 申请材料模板 / 统计报表",
    "apps_data": "办事指南库 + 政策知识库 + 模拟人口数据 + 审批记录"
  }
}

Task 示例

Task ID	子领域	难度	描述	验证方式
gov-001	咨询	L1	解答市民关于社保/公积金/户口等政策咨询	回答准确性 + 政策引用正确
gov-002	材料审核	L2	审核企业营业执照申请材料的完整性和合规性	缺陷识别率 + 审核结论准确
gov-003	政策解读	L3	针对新出台的政策文件，生成面向不同受众的解读材料	解读准确性 + 受众适配度
gov-004	跨部门协调	L4	处理需多部门协同的复杂审批事项（如建设工程许可）	流程正确性 + 协调效率 + 合规性

---

4.14 领域十四：智慧出行 / 汽车（Smart Mobility）

对标：OSWorld（桌面操作）+ WebArena（多系统交互）
腾讯生态依赖：腾讯智慧出行（车联网 TSP + 智能座舱）+ 腾讯位置服务 + 腾讯云地图 + 企业微信（车企 CRM）

World 定义

{
  "domain": "smart_mobility",
  "description": "模拟车企和出行平台的业务场景",
  "services": [
    {
      "name": "vehicle-mcp",
      "type": "mcp",
      "description": "车联网数据查询（车辆状态/行驶数据/OTA 状态）"
    },
    {
      "name": "lbs-mcp",
      "type": "mcp",
      "description": "腾讯位置服务（路线规划/POI/交通状况）"
    },
    {
      "name": "crm-mcp",
      "type": "mcp",
      "description": "车企 CRM 系统（客户管理/线索跟进/保客运营）"
    },
    {
      "name": "analytics-mcp",
      "type": "mcp",
      "description": "出行数据分析 + 用户行为洞察"
    },
    {
      "name": "after-sales-mcp",
      "type": "mcp",
      "description": "售后服务系统（工单/保养提醒/故障诊断）"
    }
  ],
  "world_files": {
    "filesystem": "车辆配置表 / 用户手册 / 服务政策 / 营销方案模板",
    "apps_data": "车辆遥测数据 + 客户档案 + 维保记录 + 销售线索池"
  }
}

Task 示例

Task ID	子领域	难度	描述	验证方式
mob-001	客服	L1	处理车主关于充电桩故障/导航异常/车辆功能的咨询	回答准确性 + 问题解决率
mob-002	故障诊断	L2	根据车辆遥测数据和故障码，判断故障原因并推荐处理方案	诊断准确率 + 推荐合理性
mob-003	保客运营	L3	分析客户流失风险，制定个性化保客策略（保养提醒 + 增值服务推荐）	策略可执行性 + ROI 预估
mob-004	出行规划	L3	综合实时路况/充电桩分布/用户偏好，规划多日自驾出行方案	路线合理性 + 充电规划可行性
mob-005	OTA 策略	L4	制定车型 OTA 升级策略：功能分析 → 灰度计划 → 回滚预案 → 用户通知	方案完整性 + 风险控制

---

4B.1 ToB 行业领域的腾讯生态资源盘点

行业	腾讯核心产品/API	MCP Server 可行性	数据获取难度
金融	天御风控 RCP · 微信支付 V3 · OCR 票据识别 · TDSQL 金融版 · 腾讯电子签	✅ API 完备	🟡 需脱敏处理
医疗	腾讯觅影 · 腾讯医典 API · 医疗 OCR · 健康算法服务	⚠️ 部分需授权	🔴 隐私要求高，建议合成数据
教育	腾讯教育 AI · 教学管理平台 · 腾讯文档 · 混元大模型	✅ 可封装	🟢 较易获取
零售	微信支付 · 微信小程序 · 微信视频号 · 腾讯广告 Marketing API · 企业微信 · 云商付	✅ API 丰富	🟢 可用模拟数据
政务	政务微信 · 腾讯电子签 · OCR 证照识别 · 腾讯问卷 · 数字人	⚠️ 需政务云环境	🟡 需合规审批
出行	智慧出行 TSP · 位置服务 · 地图 API · 企业微信 CRM	✅ 可封装	🟡 遥测数据需车企合作

4B.2 ToB 行业领域与外部 Benchmark 的映射

行业	已有外部 Benchmark	腾讯方案差异化
金融	Finance Agent Bench · InvestorBench · FinRL	中国金融市场 + 腾讯支付生态 + 风控大模型
医疗	MedAgentBench · AgentClinic	中国诊疗规范 + 腾讯觅影影像能力
教育	暂无成熟 Agent Benchmark（蓝海）	腾讯教育 AI 因材施教能力 + 学生模拟器
零售	τ-bench (零售客服) · WebArena (电商)	微信生态全域运营（小程序+企微+支付+广告+视频号直播电商闭环）
政务	暂无（蓝海）	腾讯已落地 1000+ 政务项目的经验壁垒
出行	暂无（蓝海）	车云一体 + 位置服务 + 座舱交互的端到端场景

---

五、技术架构设计

5.1 整体架构

采用 Archipelago 验证过的 Docker + MCP 架构，适配腾讯生态：

┌─────────────────────────────────────────────────────────────┐
│                    Orchestrator（编排层）                      │
│  调度 World → 分配 Task → 管理 Agent 生命周期 → 收集轨迹      │
└────────────────────────┬────────────────────────────────────┘
                         │
         ┌───────────────┼───────────────┐
         ▼               ▼               ▼
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│  Sandbox 1  │ │  Sandbox 2  │ │  Sandbox N  │
│ (Docker)    │ │ (Docker)    │ │ (Docker)    │
│             │ │             │ │             │
│ MCP Gateway │ │ MCP Gateway │ │ MCP Gateway │
│  ├ docs-mcp │ │  ├ db-mcp   │ │  ├ cloud-mcp│
│  ├ tapd-mcp │ │  ├ cos-mcp  │ │  ├ term-mcp │
│  └ wecom-mcp│ │  └ code-mcp │ │  └ k8s-mcp  │
│             │ │             │ │             │
│ Filesystem  │ │ Filesystem  │ │ Filesystem  │
│ Apps Data   │ │ Apps Data   │ │ Apps Data   │
└─────────────┘ └─────────────┘ └─────────────┘
         │               │               │
         └───────────────┼───────────────┘
                         ▼
┌─────────────────────────────────────────────────────────────┐
│                    Grading（评分层）                          │
│  Snapshot Diff → Verifier 执行 → 多维度评分 → 轨迹归档       │
└─────────────────────────────────────────────────────────────┘
         │
         ▼
┌─────────────────────────────────────────────────────────────┐
│                    Storage（存储层）                          │
│  COS: 快照/轨迹/评分    TDSQL: 元数据    混元: Judge LLM     │
└─────────────────────────────────────────────────────────────┘

5.2 MCP Server 开发规范

每个腾讯平台封装为一个 MCP Server，遵循统一接口规范：

# 示例：TAPD MCP Server 的工具定义
@server.tool("tapd_get_stories")
async def get_stories(workspace_id: str, status: str = "open"):
    """获取 TAPD 需求列表"""
    # 调用 TAPD Open API
    ...

@server.tool("tapd_create_bug")
async def create_bug(workspace_id: str, title: str, description: str):
    """创建 TAPD 缺陷"""
    ...

@server.tool("tapd_update_task")
async def update_task(task_id: str, status: str, comment: str = ""):
    """更新 TAPD 任务状态"""
    ...

MCP Server 目录结构：

mcp_servers/
├── wechat-mp/             # 微信公众平台
├── wechat-miniprogram/    # 微信小程序
├── wechat-open/           # 微信开放平台（第三方）
├── wechat-channels/       # 微信视频号
├── qq-bot/                # QQ 机器人
├── qq-miniprogram/        # QQ 小程序
├── tencent-docs/          # 腾讯文档
├── tapd/                  # TAPD 项目管理
├── coding/                # CODING DevOps
├── wecom/                 # 企业微信
├── tencent-cloud/         # 腾讯云 API
├── cvm/                   # CVM + TAT 自动化
├── cls/                   # CLS 日志服务
├── tca/                   # TCA 代码分析
├── tdsql/                 # 数据库操作
├── cos/                   # 对象存储
├── cloudbase/             # 云开发
├── edgeone-pages/         # EdgeOne Pages 部署
├── hai/                   # 高性能 AI 应用
├── meeting/               # 腾讯会议
├── lbs/                   # 腾讯位置服务
├── payment/               # 微信支付
├── ads/                   # 腾讯广告
├── esign/                 # 腾讯电子签
├── risk-control/          # 天御风控
├── medical-knowledge/     # 腾讯医典
├── medical-image/         # 腾讯觅影
├── vehicle/               # 车联网 TSP
├── crm/                   # 企业微信 CRM
└── filesystem/            # 通用文件系统

5.3 World 快照机制

复用 Archipelago 的快照设计，适配腾讯存储：

1. 初始化：从 COS 下载 World 快照 → 解压到容器
2. 执行：Agent 通过 MCP 操作环境
3. 快照：打包容器状态 → 上传 COS
4. 评分：对比初始快照和结束快照的 diff

快照存储结构：

cos://agent-rl-snapshots/
├── worlds/
│   ├── {world_slug}/
│   │   ├── initial.tar.gz      # 初始状态
│   │   └── metadata.json       # World 元数据
├── trajectories/
│   ├── {trajectory_id}/
│   │   ├── final.tar.gz        # Agent 执行后状态
│   │   ├── messages.jsonl       # Agent 消息历史
│   │   └── tool_calls.jsonl     # 工具调用记录
└── grades/
    └── {trajectory_id}.json    # 评分结果

5.4 评分体系

三级评分架构：

层级	评分方式	评估内容
自动验证	程序化检查	测试用例/API 返回值/文件存在性
快照对比	Diff 分析	文件变更的正确性和完整性
LLM Judge	混元/GPT-4o 评分	开放式任务的质量、效率、创造性

scoring_config = {
    "scoring_method": "weighted_multi_criteria",
    "criteria": [
        {"name": "task_completion", "weight": 0.4, "type": "auto"},
        {"name": "output_quality", "weight": 0.3, "type": "llm_judge"},
        {"name": "efficiency", "weight": 0.2, "type": "trajectory"},
        {"name": "no_side_effects", "weight": 0.1, "type": "snapshot_diff"}
    ]
}

---

六、从评测到训练：RL 训练对接

环境不仅用于评测，更重要的是产出训练数据。

6.1 训练数据产出

每次 Agent 执行产出的轨迹数据结构：

{
  "trajectory_id": "traj-001",
  "world": "software_engineering_v1",
  "task": "se-002",
  "model": "hunyuan-turbo",
  "messages": [
    {"role": "system", "content": "..."},
    {"role": "user", "content": "..."},
    {"role": "assistant", "content": "...", "tool_calls": [...]},
    {"role": "tool", "content": "..."}
  ],
  "grade": {
    "overall_score": 0.82,
    "criteria_scores": {...}
  },
  "metadata": {
    "total_steps": 15,
    "total_time_seconds": 342,
    "tokens_used": 28500
  }
}

6.2 与训练框架对接

训练框架	对接方式	适用场景
ART (MCP-RL)	直接复用 MCP Server，场景自动生成	单工具 / 多工具调用训练
AgentGym-RL	封装为 AgentGym 环境接口	多环境并行训练
verl	封装为 Server-based 环境	大规模 Agentic RL
自研	直接使用 GRPO + 轨迹数据	深度定制

6.3 推荐的训练流水线

Phase 1: 数据积累
  → 多模型在环境中执行 Task
  → 收集大量轨迹 + 评分

Phase 2: 筛选与标注
  → 按评分筛选高质量轨迹作为正例
  → 低分轨迹作为负例
  → 构建 preference pair

Phase 3: 训练
  → SFT：用高分轨迹做 fine-tuning
  → RLHF/GRPO：用评分作为 reward signal
  → DPO：用 preference pair 做直接偏好优化

Phase 4: 迭代
  → 训练后的模型重新执行 Task
  → 新轨迹再次评分
  → 循环迭代

---

七、实施路线图

Phase 0：基础设施（2 周）

• 基于 Archipelago 搭建 Docker + MCP Gateway 基座
• 部署腾讯云存储后端（COS + TDSQL）
• 实现快照管理和轨迹存储

Phase 1：核心 MCP Server（4 周）

按优先级开发：

优先级	MCP Server	依赖	解锁的领域
P0	filesystem	无	所有领域
P0	code-executor	AgentSandbox	软件工程/数据工程
P1	tencent-docs	腾讯文档 Open API	办公协作
P1	tapd	TAPD Open API	软件工程
P1	database	TDSQL API	数据工程
P1	wechat-mp	微信公众平台 API	产品运营/客户服务
P1	wechat-miniprogram	微信小程序 API	小程序开发/零售
P2	coding	CODING Open API	软件工程
P2	wecom	企业微信 API	办公协作/客户服务/零售
P2	tencent-cloud + cvm	腾讯云 API + TAT	云运维
P2	cls	CLS 日志服务 API	云运维
P2	tca	TCA 代码分析 API	软件工程
P2	wechat-channels	视频号助手 API	产品运营/零售
P2	qq-bot	QQ Bot API v2	客户服务/社群运营
P2	risk-control	天御风控 API	金融服务
P2	payment	微信支付 V3 API	金融服务/零售
P2	medical-knowledge	腾讯医典 API	医疗健康
P3	meeting	腾讯会议 API	办公协作
P3	lbs	位置服务 API	小程序开发/出行
P3	ads	腾讯广告 Marketing API	零售/产品运营
P3	esign	腾讯电子签 API	政务/金融
P3	vehicle	车联网 TSP API	出行
P3	cloudbase	CloudBase API	小程序开发
P3	edgeone-pages	EdgeOne Pages API	前端部署
P3	hai	HAI API	AI 训练/推理
P3	wechat-open	微信开放平台 API	第三方服务商场景
P3	qq-miniprogram	QQ 小程序 API	小程序开发

Phase 2：World 和 Task 构建（6 周）

• 每个领域构建 2-3 个 World（14 领域，预计 30-40 个 World）
• 每个 World 设计 10-20 个 Task（L1-L4）
• 编写 Golden Response
• 实现 Verifier
• ToB 行业领域需额外处理数据脱敏和合规审批

Phase 3：评测验证（2 周）

• 多模型评测（混元 / GPT-4o / Claude）
• 评分体系校准
• 建立 Leaderboard

Phase 4：训练闭环（4 周）

• 接入 ART/verl 训练框架
• 构建 SFT + RL 训练流水线
• 验证训练效果

---

八、环境依赖总览

8.1 基础依赖

组件	版本要求	用途
Docker Desktop	24.0+	环境容器化
Python	3.11+	MCP Server + Agent Runner
UV	0.4+	Python 依赖管理
Node.js	20+	部分 MCP Server

8.2 腾讯云依赖

服务	必需 / 可选	用途
COS	必需	快照存储
TDSQL	必需	元数据存储 + 数据工程环境
TKE	可选（规模化时需要）	容器编排
SCF	可选	轻量级工具运行时
混元 API	推荐	Judge LLM
AgentSandbox	推荐	安全代码执行

8.3 外部依赖

服务	用途	可替代方案
LLM API (OpenAI/Anthropic)	Agent 推理 + Judge	混元 API
S3 兼容存储	快照管理（Archipelago 原生）	腾讯云 COS（S3 兼容）

---

九、风险与缓解

风险	影响	缓解措施
腾讯内部 API 变更	MCP Server 失效	MCP Server 加版本管理 + 健康检查
API 调用频率限制	大规模训练受限	申请提升配额 + 本地 Mock 模式
环境隔离不完全	Agent 操作影响生产环境	全部使用沙箱/测试账号 + 网络隔离
Golden Response 质量	评分不准	多人交叉验证 + LLM 辅助生成初稿
快照体积过大	存储成本高	增量快照 + 过期清理策略

---

十、与外部方案的对比

维度	APEX-Agents	本方案
领域覆盖	投行/咨询/法律	14 大领域：8 内部工具链 + 6 ToB 行业垂直
环境真实度	通用文件 + 自建 App	腾讯真实产品 API，业务贴合度更高
MCP Server	自建	复用腾讯已有 MCP + 自建补充
可训练性	主要做评测	评测 + RL 训练双用途
部署方式	Docker	Docker + 可选 TKE 规模化
评分体系	快照对比 + Judge	三级评分（自动 + 快照 + LLM）
数据敏感性	开放	内部数据需脱敏处理

---

附录 A：MCP Server 接口速查

A.1 协作与办公

MCP Server	核心 Tools	对应 API	官方 MCP
tencent-docs	create_doc, edit_doc, list_docs, share_doc	腾讯文档 Open API	✅ 已有
tapd	get_stories, create_bug, update_task, list_iterations	TAPD Open API	✅ 已有
coding	list_repos, create_mr, get_ci_status, review_mr	CODING Open API	—
wecom	send_message, create_approval, list_contacts, create_schedule	企业微信 API	✅ 社区
meeting	create_meeting, list_meetings, get_recording	腾讯会议 API	✅ 已有
esign	create_contract, sign_contract, manage_templates	腾讯电子签 API	—

A.2 微信生态

MCP Server	核心 Tools	对应 API	官方 MCP
wechat-mp	manage_articles, send_template_msg, manage_users, get_analytics, manage_menu	微信公众平台 API	✅ 社区
wechat-miniprogram	manage_pages, manage_cloud_db, manage_cloud_functions, submit_review, get_analytics	微信小程序 API	—
wechat-open	manage_authorizer, proxy_api_call, get_component_token	微信开放平台 API（第三方平台）	—
wechat-channels	manage_live, manage_showcase, get_live_data, manage_leads, get_dashboard	视频号助手 API	—
payment	query_transaction, create_refund, reconcile, download_bill	微信支付 V3 API	—

A.3 QQ 生态

MCP Server	核心 Tools	对应 API	官方 MCP
qq-bot	send_message, manage_groups, manage_channels, add_reaction, create_schedule, manage_threads	QQ Bot API v2	—
qq-miniprogram	manage_pages, manage_data, submit_review	QQ 小程序 API	—

A.4 云基础设施

MCP Server	核心 Tools	对应 API	官方 MCP
tencent-cloud	describe_instances, run_instances, create_cluster	腾讯云 API	—
cvm	describe_instances, start_instances, run_command (TAT)	CVM + TAT API	✅ 已有
cos	upload_file, download_file, list_objects, generate_presigned_url	COS API	✅ 已有
cloudbase	deploy_function, manage_database, manage_hosting	云开发 CloudBase API	✅ 已有
cls	search_log, create_alarm, get_dashboard, analyze_log	CLS 日志服务 API	✅ 已有
edgeone-pages	deploy_site, manage_domains, get_deploy_status	EdgeOne Pages API	✅ 已有
hai	manage_instances, get_gpu_status	HAI 高性能应用 API	✅ 已有
database	execute_sql, describe_tables, explain_query	TDSQL API + 直连	—
lbs	geocode, route_plan, search_poi, traffic_status	位置服务 API	✅ 已有

A.5 开发工具

MCP Server	核心 Tools	对应 API	官方 MCP
code-executor	execute_python, execute_shell, execute_sql	AgentSandbox	—
tca	scan_project, get_issues, get_metrics, get_duplicates	TCA 代码分析 API	✅ 已有
filesystem	read_file, write_file, list_dir, search	本地文件系统	—

A.6 行业垂直

MCP Server	核心 Tools	对应 API	官方 MCP
risk-control	check_fraud, assess_credit, check_compliance	天御风控 RCP API	—
medical-knowledge	search_disease, check_drug_interaction, get_guideline	腾讯医典 API	—
medical-image	analyze_xray, analyze_ct, get_report	腾讯觅影 API	—
ecommerce	manage_products, process_orders, check_inventory	小程序商城 API	—
ads	create_campaign, optimize_bid, get_analytics	腾讯广告 Marketing API	—
gov-service	submit_application, review_materials, query_status	政务服务平台 API	—
vehicle	get_vehicle_status, get_telemetry, manage_ota	车联网 TSP API	—
crm	manage_leads, track_customers, create_campaigns	企业微信 CRM API	—

---

附录 B：参考资源

论文

• APEX-Agents: Evaluating AI on Professional Tasks - Mercor, 2026
• Finance Agent Benchmark: Benchmarking LLMs on Real-world Financial Research Tasks - Vals AI / Stanford, 2025
• InvestorBench: A Benchmark for Financial LLM-based Agents - ACL 2025
• MedAgentBench: A Realistic Virtual EHR Environment to Benchmark Medical LLM Agents - Stanford ML Group, 2025
• AgentClinic: A Multimodal Agent Benchmark for Simulated Clinical Environments - 2024
• LLM Agents for Education: Advances and Applications - EMNLP 2025
• AgentGym-RL: Training LLM Agents for Long-Horizon Decision Making - ICLR 2026 Oral
• RAGEN: Self-Evolution in LLM Agents via Multi-Turn RL - 2025
• MCP-AgentBench: Evaluating Real-World Language Agent Capabilities - 2025
• Survey on Evaluation of LLM-based Agents - 2025
• TradingAgents: Multi-Agents LLM Financial Trading Framework - 2024

开源框架

• Archipelago - Docker + MCP 评测框架
• ART (Agent Reinforcement Trainer) - MCP-RL 训练
• SWE-bench - 代码修复评测
• WebArena - Web Agent 评测
• OSWorld - 桌面 Agent 评测
• verl - 工业级 Agentic RL 框架

腾讯开放平台

• 微信公众平台 API
• 微信小程序 API
• 微信开放平台（第三方平台）
• 视频号助手 API
• QQ 开放平台（QQ Bot API v2）
• 腾讯文档 Open API
• TAPD Open API
• CODING Open API
• 企业微信 API
• 微信支付 V3 API
• 腾讯云 API
• CloudBase MCP
• 腾讯位置服务 MCP
• 腾讯云 MCP 广场（1055+ MCP 服务汇总）
• 腾讯广告 Marketing API
• 腾讯电子签 API

---

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

目标：用 50 个精选 Task 构建 PoC，覆盖核心能力维度，验证 Docker + MCP 架构的可行性
设计原则：可验证性优先 · 领域均衡 · 难度递进 · 落地门槛可控

C.1 总览

领域分布

领域	Task 数	占比	选择理由
软件工程	10	20%	最成熟、MCP Server 就绪、可自动验证
办公协作	7	14%	腾讯文档/企微/会议 MCP 已有，场景普适
数据工程	8	16%	核心能力方向，SQL/ETL 可精确验证
云运维	5	10%	终端操作 + 日志分析，可容器化验证
客户服务	5	10%	τ-bench 模式成熟，对话式任务
产品运营	4	8%	数据分析 + 策略生成，半结构化
小程序开发	4	8%	前端 + 云开发，腾讯特色场景
金融服务	4	8%	高价值垂直场景，合规约束丰富
零售	3	6%	微信生态全域运营，多工具协调
合计	50	100%

注：首批 PoC 聚焦 9 个 MCP Server 就绪度最高、可验证性最强的领域。蓝图中的安全合规、医疗健康、教育、数字政务、智慧出行 5 个领域留待第二批扩展——这些领域的数据获取门槛高（医疗隐私/政务合规）或 MCP Server 需要额外授权。

难度分布

难度	数量	定义	预计 Agent 步数
L1	14	单工具 / 单步骤，主要考查工具调用准确性	3-8 步
L2	18	多工具串联，需理解中间结果并决定下一步	8-20 步
L3	13	复杂推理 + 多轮交互，需要规划和回退	15-40 步
L4	5	端到端完整流程，跨多个子系统	30-80 步

能力维度覆盖

能力维度	覆盖 Task 数	说明
工具调用 (Tool Use)	50	全部 Task 都通过 MCP 操作
信息检索 (Retrieval)	22	从文档/数据库/日志中提取关键信息
代码生成 (Code Gen)	18	编写/修改 Python/SQL/JS 代码
数据分析 (Analysis)	15	分析数据并产出结论
多步规划 (Planning)	18	L3/L4 任务需要拆解计划
跨系统协调 (Coordination)	12	同时操作多个平台/系统
文档生成 (Doc Gen)	11	产出报告/方案/文档
对话交互 (Dialogue)	5	客户服务场景的多轮对话

---

C.2 50 Task 总览表

软件工程（10 个）

#	Task ID	难度	任务描述	考查能力	MCP Server	验证方式	设计方法
1	SE-001	L1	根据 TAPD Bug 描述，在仓库中定位并修复单个函数 Bug	代码修复 + 工具调用	tapd, code-executor, filesystem	单元测试全通过	从真实 Bug 回退制造
2	SE-002	L1	阅读 TAPD 需求，编写对应的单元测试	测试生成 + 需求理解	tapd, code-executor, filesystem	测试覆盖目标函数 + 测试可运行	给定函数，期望测试
3	SE-003	L2	阅读 PR Review 评论，按评审意见重构代码	代码重构 + 上下文理解	coding, filesystem, code-executor	代码质量评分 + Review 点逐条满足	准备 Review 评论 + 初始代码
4	SE-004	L2	分析 CI 失败日志，定位根因并修复	日志分析 + 调试	coding, code-executor, filesystem	CI 重跑成功	注入特定编译/测试错误
5	SE-005	L2	使用 TCA 扫描仓库，修复 Top-5 高危代码质量问题	代码质量 + 批量修复	tca, filesystem, code-executor	TCA 复扫零高危	注入已知 CWE 漏洞
6	SE-006	L2	给遗留代码添加类型注解和文档字符串	代码理解 + 文档化	filesystem, code-executor	mypy 检查通过 + docstring 覆盖率	去除现有注解
7	SE-007	L3	根据产品需求文档实现一个新 API 端点 (Flask/FastAPI)	需求分析 + 全栈开发	tapd, filesystem, code-executor	API 测试用例通过 + 路由正确	提供需求文档 + 项目骨架
8	SE-008	L3	将同步代码重构为异步（sync → async），保持行为一致	深度重构 + 回归验证	filesystem, code-executor	原有测试全通过 + 异步调用验证	提供同步版本 + 测试
9	SE-009	L3	跨文件 Bug 修复：追踪错误传播链，修复根因而非症状	复杂调试 + 代码导航	filesystem, code-executor, tapd	集成测试通过 + 根因定位准确	注入跨模块级联 Bug
10	SE-010	L4	端到端：TAPD 需求 → 分支创建 → 开发 → 测试 → MR 提交	完整研发流程	tapd, coding, filesystem, code-executor, tca	MR 可合入 + CI 绿 + 需求关联正确	完整需求卡 + 项目环境

办公协作（7 个）

#	Task ID	难度	任务描述	考查能力	MCP Server	验证方式	设计方法
11	OA-001	L1	根据会议录音转写文本，提取 Action Items 列表	信息提取	filesystem, tencent-docs	Action Items 与 Golden 对比 (F1)	提供真实会议文本
12	OA-002	L1	在腾讯文档中创建指定格式的周报模板并填入数据	工具调用 + 格式化	tencent-docs, filesystem	文档存在 + 格式正确 + 数据准确	提供数据源 + 模板规范
13	OA-003	L2	汇总 3 份数据报表，生成周报并发布到腾讯文档	数据分析 + 文档生成	filesystem, tencent-docs	数据准确性 + 分析深度 (LLM Judge)	提供 CSV 数据文件
14	OA-004	L2	协调多人日程，找到共同空闲时段并创建会议	约束求解 + 工具协调	wecom, meeting	会议创建成功 + 时间无冲突	提供日程数据 + 冲突约束
15	OA-005	L3	阅读合同草稿，标注风险条款并生成修改建议文档	文档理解 + 风险识别	filesystem, tencent-docs	风险条款召回率 + 建议合理性	注入已知风险条款
16	OA-006	L3	根据多份项目周报，生成团队月度汇报 PPT 大纲	信息综合 + 文档生成	filesystem, tencent-docs	信息覆盖度 + 结构合理性	提供多份周报原文
17	OA-007	L4	端到端：收到客户需求邮件 → 方案撰写 → 内部审批 → 会议安排	全流程协作	filesystem, tencent-docs, wecom, meeting	全流程完成度	提供邮件 + 审批规则

数据工程（8 个）

#	Task ID	难度	任务描述	考查能力	MCP Server	验证方式	设计方法
18	DE-001	L1	根据自然语言需求编写 SQL 查询	NL2SQL	database, filesystem	查询结果与 Golden 一致	预建 Schema + 测试数据
19	DE-002	L1	检查数据表质量（空值率/唯一性/分布异常）	数据质量	database, code-executor	质量报告与预期一致	注入质量问题
20	DE-003	L2	编写 Python ETL 脚本：CSV → 清洗 → 入库	ETL 开发	filesystem, code-executor, database	数据正确入库 + 行数一致	提供脏数据 CSV
21	DE-004	L2	诊断 ETL 管道失败，修复脚本并重跑	管道调试	filesystem, code-executor, database	管道重跑成功 + 数据一致	注入特定失败
22	DE-005	L2	编写复杂分析 SQL（窗口函数/CTE/子查询）	高级 SQL	database	结果正确 + 执行计划合理	复杂业务分析需求
23	DE-006	L3	设计星型模型：分析需求 → ODS→DWD→DWS 建表	数据建模	database, filesystem	Schema 评审评分 + 可查询性	给定业务场景 + 源表
24	DE-007	L3	数据异常排查：发现指标异常 → 追溯到源头 → 修复	根因分析	database, code-executor, filesystem	根因定位准确 + 修复后指标恢复	注入数据异常
25	DE-008	L4	端到端数据迁移：评估 → Schema 映射 → 脚本 → 执行 → 验证	全流程迁移	database, cos, code-executor, filesystem	数据完整性 100% + 零丢失	源/目标两套库

云运维（5 个）

#	Task ID	难度	任务描述	考查能力	MCP Server	验证方式	设计方法
26	CO-001	L1	根据告警信息定位异常容器并重启服务	告警响应	tencent-cloud, terminal	服务恢复 + 告警清除	模拟容器故障
27	CO-002	L2	分析 CLS 日志定位线上 5xx 报错根因	日志分析	cls, terminal, filesystem	根因定位准确	注入特定错误模式
28	CO-003	L2	编写 Terraform 配置创建标准三层架构资源	IaC 编写	filesystem, code-executor	terraform plan 成功 + 资源配置正确	给定架构需求
29	CO-004	L3	K8s 集群故障排查：Pod CrashLoop → 定位 → 修复	容器调试	terminal, tencent-cloud, cls	Pod Running + 无 restart	注入配置/镜像错误
30	CO-005	L3	编写自动伸缩策略：分析监控指标 → HPA 配置 → 压测验证	资源优化	tencent-cloud, terminal, filesystem	HPA 生效 + 压测通过	提供监控数据 + 基线

客户服务（5 个）

#	Task ID	难度	任务描述	考查能力	MCP Server	验证方式	设计方法
31	CS-001	L1	根据用户问题检索知识库并生成回复	检索 + 回答	wecom, filesystem	回答准确性 + 知识库引用正确	预建 FAQ 知识库
32	CS-002	L2	处理退款申请：查订单 → 判断政策 → 执行操作 → 回复用户	流程遵循 + 多步操作	wecom, database, filesystem	政策合规 + 操作正确 + 回复质量	设定退款政策 + 订单数据
33	CS-003	L2	多轮对话澄清用户模糊问题，逐步缩小范围并解决	对话策略 + 信息收集	wecom, filesystem	问题解决率 + 对话轮数效率	模拟用户 Agent
34	CS-004	L3	处理升级投诉：安抚 → 跨系统查证 → 制定补偿方案	复杂协调 + 情绪管理	wecom, database, filesystem	问题解决 + 合规 + 用户满意度 (Judge)	设定投诉场景 + 规则
35	CS-005	L3	批量处理工单：分类 → 优先级排序 → 分配 → 跟进	批量处理 + 优先级判断	wecom, database, filesystem	分类准确率 + 优先级合理性	提供混合工单池

产品运营（4 个）

#	Task ID	难度	任务描述	考查能力	MCP Server	验证方式	设计方法
36	PO-001	L1	根据广告投放数据生成日报（关键指标 + 趋势）	数据提取 + 报表	database, tencent-docs	数据准确性 + 格式规范	提供投放数据表
37	PO-002	L2	分析用户漏斗数据，识别转化瓶颈并给出优化建议	漏斗分析 + 洞察	database, code-executor, tencent-docs	瓶颈定位准确 + 建议可执行	提供埋点数据
38	PO-003	L3	设计 A/B 测试方案：确定指标 → 样本量计算 → 分组 → 结果分析	实验设计 + 统计	database, code-executor, filesystem	统计方法正确 + 结论合理	提供实验需求 + 历史数据
39	PO-004	L3	分析视频号直播数据，生成场次复盘报告含改进建议	多维分析 + 洞察	database, tencent-docs, filesystem	指标计算准确 + 洞察深度 (Judge)	提供直播数据

小程序开发（4 个）

#	Task ID	难度	任务描述	考查能力	MCP Server	验证方式	设计方法
40	MP-001	L1	根据设计稿还原小程序页面结构（WXML + WXSS）	前端开发	filesystem, code-executor	页面结构匹配 + 样式得分	提供设计稿 JSON
41	MP-002	L2	实现云函数 + 云数据库 CRUD 接口	后端开发	cloudbase, code-executor, filesystem	接口测试全通过	给定数据模型
42	MP-003	L2	修复小程序性能问题（setData 优化、图片懒加载）	性能优化	filesystem, code-executor	性能指标改善 + 功能不退化	注入性能问题
43	MP-004	L3	实现完整登录流程：wx.login → 后端校验 → token 管理	全栈安全	filesystem, code-executor, cloudbase	登录流程正确 + 安全检查通过	给定项目骨架

金融服务（4 个）

#	Task ID	难度	任务描述	考查能力	MCP Server	验证方式	设计方法
44	FIN-001	L1	根据交易流水判断一笔交易是否存在欺诈风险	风控判断	risk-control, database	判断准确率 (F1)	合成交易 + 标注
45	FIN-002	L2	对照支付流水和财务账本，完成对账并生成差异报告	对账逻辑 + 精度	payment, database, filesystem	差异发现率 + 金额零误差	注入对账差异
46	FIN-003	L3	审查金融合同，识别 5 类风险条款并出具合规意见	合规审查	filesystem, database	条款识别召回率 + 意见质量	注入已知风险条款
47	FIN-004	L3	基于财报数据撰写公司投资分析报告	财务分析 + 文档	database, code-executor, filesystem	数据准确 + 分析深度 (Judge)	提供结构化财报

智慧零售（3 个）

#	Task ID	难度	任务描述	考查能力	MCP Server	验证方式	设计方法
48	RET-001	L2	处理退换货：查订单 → 判断政策 → 物流安排 → 退款	多步骤流程	database, payment, wecom	操作正确 + 政策合规	设定退换货政策
49	RET-002	L3	根据销售数据和库存状况，生成下周补货计划	预测 + 优化	database, code-executor, filesystem	补货量合理 + 无断货风险	历史销售 + 库存数据
50	RET-003	L4	策划大促活动：选品 → 定价 → 投放配置 → 效果预估	端到端运营	database, ads, tencent-docs, filesystem	方案完整性 + ROI 合理性 (Judge)	提供品类 + 历史活动数据

---

C.3 能力覆盖矩阵

Task	工具调用	信息检索	代码生成	数据分析	多步规划	跨系统	文档生成	对话
SE-001	●	●	●
SE-002	●	●	●
SE-003	●	●	●
SE-004	●	●	●
SE-005	●		●			●
SE-006	●	●	●
SE-007	●	●	●		●
SE-008	●		●		●
SE-009	●	●	●		●
SE-010	●	●	●		●	●
OA-001	●	●					●
OA-002	●						●
OA-003	●	●		●			●
OA-004	●	●			●	●
OA-005	●	●		●			●
OA-006	●	●		●			●
OA-007	●	●			●	●	●
DE-001	●		●
DE-002	●		●	●
DE-003	●		●
DE-004	●	●	●
DE-005	●		●	●
DE-006	●	●	●	●	●		●
DE-007	●	●	●	●	●
DE-008	●	●	●		●	●	●
CO-001	●	●
CO-002	●	●		●
CO-003	●		●
CO-004	●	●	●		●
CO-005	●	●	●	●	●
CS-001	●	●						●
CS-002	●	●			●	●		●
CS-003	●	●						●
CS-004	●	●			●	●		●
CS-005	●	●		●	●			●
PO-001	●	●		●			●
PO-002	●	●	●	●			●
PO-003	●		●	●	●		●
PO-004	●	●		●			●
MP-001	●		●
MP-002	●		●			●
MP-003	●	●	●
MP-004	●		●		●	●
FIN-001	●	●		●
FIN-002	●	●		●		●	●
FIN-003	●	●			●		●
FIN-004	●	●	●	●			●
RET-001	●	●			●	●
RET-002	●	●	●	●	●		●
RET-003	●	●		●	●	●	●

---

C.4 详细设计

SE-001：单函数 Bug 修复

难度：L1 | 预计步数：5-8 | 预计时长：10min

场景：Agent 收到一个 TAPD Bug 单，描述了一个 Python 函数的错误行为。需要定位函数、理解根因、修复代码、确保测试通过。

环境配置

world: python-project-v1
services:
  - tapd-mcp          # 读取 Bug 描述
  - filesystem         # 浏览和编辑代码
  - code-executor      # 运行测试
world_files:
  - src/              # Python 项目（~20 个文件，utils/models/services 三层）
  - tests/            # 对应测试文件
  - .tapd/bugs.json   # 模拟 TAPD Bug 数据

输入示例

TAPD Bug #12345: 函数 calculate_discount() 在会员等级为 "gold" 时返回错误的折扣率。
预期：gold 会员享受 8 折（0.8），实际返回 0.85。
复现步骤：调用 calculate_discount(user_level="gold", amount=100)，期望返回 80，实际返回 85。

验证器

verifiers = [
    {"type": "test_pass", "command": "pytest tests/test_discount.py -v", "criteria": "exit_code == 0"},
    {"type": "snapshot_diff", "criteria": "仅修改 src/services/pricing.py", "penalty": "修改无关文件扣 0.2 分"}
]

Golden Response 生成：先编写正确版本，注入 off-by-one 错误（gold 折扣值写错），正确版本即为 Golden。

---

SE-002：根据需求编写单元测试

难度：L1 | 预计步数：4-6 | 预计时长：10min

场景：Agent 收到 TAPD 需求，描述了一个已实现函数的预期行为，需编写覆盖该函数的单元测试。

验证器

verifiers = [
    {"type": "test_pass", "command": "pytest tests/test_order.py -v", "criteria": "所有用例通过"},
    {"type": "coverage", "command": "pytest --cov=src/services/order tests/", "criteria": "覆盖率 >= 85%"},
    {"type": "test_quality", "criteria": "包含正向/边界/异常三类用例"}
]

Golden Response 生成：人工编写标准测试套件（10+ 用例），Agent 不需要完全一致，但必须覆盖同等场景。

---

SE-003：按 PR Review 意见重构代码

难度：L2 | 预计步数：10-15 | 预计时长：20min

场景：收到 CODING PR 的 Review 评论（4-6 条），需逐条理解并修改代码。

输入示例

PR #42 Review 评论：
1. [L15] 函数太长（50行），拆成 3 个子函数
2. [L28] 硬编码 magic number 3600 应提取为常量
3. [L35] bare except 改为 except SpecificError
4. [L42] 缺少输入参数校验
5. [L50] 日志信息不够详细

验证器

verifiers = [
    {"type": "review_checklist", "criteria": "每条 Review 意见都被处理"},
    {"type": "test_pass", "command": "pytest tests/ -v", "criteria": "原有测试不退化"},
    {"type": "code_quality", "command": "flake8 src/", "criteria": "无新增 lint 警告"}
]

---

SE-004：CI 失败日志分析与修复

难度：L2 | 预计步数：8-12 | 预计时长：20min

注入的错误类型（随机选一种）

类型	具体问题	日志特征
依赖冲突	requirements.txt 版本不兼容	ERROR: pip's dependency resolver
导入错误	缺少 __init__.py	ModuleNotFoundError
测试失败	数据变更导致断言失败	FAILED tests/test_x.py::test_y
类型错误	参数类型不匹配	TypeError: expected str, got int

验证器：CI 重跑成功 + LLM Judge 验证根因分析准确性。

---

SE-005：TCA 代码质量扫描与修复

难度：L2 | 预计步数：10-15 | 预计时长：25min

注入的代码质量问题

CWE	问题	严重级别
CWE-89	SQL 注入（字符串拼接）	高危
CWE-78	命令注入（os.system）	高危
CWE-22	路径遍历（未校验路径）	高危
CWE-502	不安全反序列化（pickle）	高危
CWE-798	硬编码密钥	高危

验证器：TCA 复扫零高危 + 原有测试不退化 + LLM Judge 评估修复方案合理性。

---

SE-006：遗留代码添加类型注解和文档

难度：L2 | 预计步数：8-12 | 预计时长：20min

验证器：mypy —strict 零 error + interrogate 覆盖率 ≥ 95% + 原有测试不退化。

Golden Response 生成：从有完整注解的代码库出发，strip 掉类型注解和 docstring 作为输入。

---

SE-007：根据需求实现新 API 端点

难度：L3 | 预计步数：15-25 | 预计时长：40min

场景：在现有 FastAPI 项目中实现 POST /api/v1/orders，包括路由、业务逻辑、数据库操作和输入校验。

验证器：8 个 API 测试用例全通过 + 响应体符合 Schema + 数据库状态正确。

---

SE-008：同步代码重构为异步

难度：L3 | 预计步数：15-20 | 预计时长：35min

验证器：全部测试通过 + AST 分析确认所有 I/O 函数为 async def + 无阻塞调用残留（grep 检查）。

---

SE-009：跨文件级联 Bug 修复

难度：L3 | 预计步数：15-25 | 预计时长：40min

场景：Bug 症状在模块 A（handler），根因在模块 C（calculator）。A 调用 B（processor），B 调用 C。

注入：calculator.py 日期范围计算 off-by-one → processor.py 聚合偏小 → handler.py 统计偏低。

验证器：集成测试通过 + snapshot_diff 确认修改文件为 utils/calculator.py（仅修 handler → 0 分）+ 修改行数 < 5。

---

SE-010：端到端研发流程

难度：L4 | 预计步数：30-50 | 预计时长：90min

全流程：TAPD 需求 → 创建 feature/ 分支 → 功能开发 → 单元测试 + 集成测试 → TCA 扫描 → 提交 MR。

验证器：分支已创建 + 测试全通过 + CI 绿 + MR 已创建关联 TAPD + TCA 零高危 + 代码质量 (LLM Judge)。

---

OA-001：会议纪要提取 Action Items

难度：L1 | 预计步数：3-5 | 预计时长：5min

Golden Response 生成：人工编写 2000 字会议转写文本（8 条 Action Items + 2-3 条模糊表述 + 干扰信息）。

验证器：Action Items F1 ≥ 0.8 + 腾讯文档已创建且含表格。

---

OA-002：创建格式化周报

难度：L1 | 预计步数：3-5 | 预计时长：8min

验证器：文档存在 + 包含指定章节（概述/关键指标/进展/风险/下周计划）+ 数据与源 JSON 一致。

---

OA-003：多报表汇总生成周报

难度：L2 | 预计步数：8-12 | 预计时长：20min

环境：3 份 CSV（销售/运营/研发数据），汇总后发布到腾讯文档。

验证器：关键数字计算正确（独立计算对比）+ 包含同比环比分析（LLM Judge）。

---

OA-004：多人日程协调安排会议

难度：L2 | 预计步数：8-12 | 预计时长：15min

输入：5 人日程（含冲突），2 人必须参加，安排 60 分钟评审会。

验证器：会议已创建 + 必参人无冲突 + 其他 3 人中 ≥2 可参加。

---

OA-005：合同风险条款审查

难度：L3 | 预计步数：12-18 | 预计时长：30min

注入 5 类风险条款：无限连带责任 / 解约权不对等 / 知识产权过度转让 / 竞业限制过宽 / 争议解决缺失。

验证器：召回率 ≥ 80%（至少 4/5）+ LLM Judge 评估修改建议法律合理性。

---

OA-006：多份周报综合为月报大纲

难度：L3 | 验证器：4 份周报中的 12 个关键事项覆盖度 + 大纲结构合理性（LLM Judge）。

---

OA-007：端到端办公流程

难度：L4 | 预计步数：25-40 | 预计时长：60min

全流程：客户需求邮件 → 方案撰写 → 内部审批 → 安排会议。

验证器：方案已创建且符合模板 + 审批已发起 + 会议已创建 + 方案回应所有需求点（LLM Judge）。

---

DE-001：自然语言转 SQL

难度：L1 | 预计步数：3-5 | 预计时长：5min

输入（5 道递增）：过去 7 天日订单量 → 复购率 Top 10 → 品类客单价和退款率 → 月度 GMV 增长率 → 连续 3 天活跃用户。

验证器：执行 Golden SQL 和 Agent SQL，对比结果集一致 + 无危险 SQL 操作。

---

DE-002：数据质量检查

难度：L1 | 注入 5 类问题：空值（3.2%）/ 重复（150 条）/ 格式异常（23 条 email）/ 分布异常（5 条 >3σ）/ 时间异常（12 条未来日期）。

验证器：发现 ≥ 4/5 种问题 + 统计数字误差 < 1%。

---

DE-003：CSV 清洗入库

难度：L2 | 脏数据：日期格式混乱 / 千分位逗号 / 前后空格和特殊字符 / 空行和重复表头 / 编码问题。

验证器：目标表行数正确 + 金额总和精确到分 + 日期格式统一。

---

DE-004：ETL 管道故障修复

难度：L2 | 注入：transform.py 的 merge_tables() 用错 join key（product_id vs sku_id），导致 NULL 膨胀。

验证器：管道重跑成功 + 数据行数和金额与预期一致。

---

DE-005：复杂分析 SQL（留存矩阵）

难度：L2 | 验证器：留存率数值与 Golden 一致（误差 < 0.1%）+ SQL 使用了 CTE + 窗口函数（AST 分析）。

---

DE-006：数据仓库分层建模

难度：L3 | 预计步数：15-25 | 预计时长：40min

产出：ODS → DWD → DWS → ADS 四层 DDL + 数据流图 + 文档。

验证器：DDL 可执行 + 层间依赖正确 + ADS 层可查出日报 + 建模质量（LLM Judge）。

---

DE-007：数据异常根因追溯

难度：L3 | 注入：marketing_campaigns 表主力活动 status 被误改为 paused → GMV 下降 35%。

验证器：定位到正确根因 + 修复后 GMV 恢复 + 分析路径合理（Trajectory 分析）。

---

DE-008：端到端数据迁移

难度：L4 | 预计步数：30-50 | 预计时长：90min

迁移：MySQL 5.7（legacy）→ PostgreSQL 14（new），5 张核心表，5 万行。

验证器：行数一致 + checksum 匹配 + 外键完整 + 产出 schema 映射文档。

---

CO-001：告警响应与服务恢复

难度：L1 | 输入：Pod OOMKilled 告警。验证器：所有 Pod Running + 告警清除。

---

CO-002：CLS 日志根因分析

难度：L2 | 注入：Redis 连接池耗尽导致 5xx。验证器：定位到 Redis 连接池 + 修复建议合理。

---

CO-003：Terraform 配置编写

难度：L2 | 输入：VPC + 子网 + CVM + CLB + 安全组。验证器：terraform validate 通过 + 资源配置正确。

---

CO-004：K8s Pod CrashLoop 排查

难度：L3 | 随机注入：ConfigMap 错误 / 镜像 tag 错 / OOM / 探针路径错。验证器：Pod Running + Ready + 无新 restart。

---

CO-005：自动伸缩策略设计

难度：L3 | 输入：7 天监控数据（日间 CPU 60-80%，夜间 10-20%）。

验证器：HPA YAML 可 apply + 夜间缩容/日间扩容逻辑正确 + 节省 ≥ 30% 资源。

---

CS-001 至 CS-005：客户服务

通用环境

world: customer-service-env
services: [wecom-mcp, filesystem, database-mcp]
world_files: [knowledge-base/（200+ FAQ）, policies/（退款/投诉/升级处理）]

客户模拟器：预编写对话脚本 + 条件分支（正确回答→满意，不准确→追问，澄清问题→补充信息），支持 patient/impatient/confused 三种人格。

---

PO-001 至 PO-004：产品运营

PO-003 A/B 测试额外说明：Agent 需基于历史数据计算样本量（α=0.05, β=0.2），设计分组，分析结果判断统计显著性。验证器独立计算统计检验结果对比。

---

MP-001 至 MP-004：小程序开发

MP-003 注入的性能问题：setData 全量更新（列表卡顿）/ 未使用图片懒加载（首屏慢）/ 循环中 setData（CPU 峰值）/ 未分包（主包超限）。

---

FIN-001 至 FIN-004：金融服务

FIN-001 数据设计：合成 1000 笔交易，50 笔欺诈（5 种 pattern × 10 笔），验证用 F1-score 偏重召回率。

FIN-002 数据设计：500 条支付流水 + 500 条财务账本，注入 8 处差异（金额不一致×3 / 单方有×4 / 日期偏差×1）。

---

RET-001 至 RET-003：智慧零售

RET-002 补货计划数据：30 天 × 200 SKU 日销量（含季节性）+ 当前库存 + 20 供应商交期 + 促销日历，Agent 需综合安全库存、在途、促销拉升、交期约束。

---

C.5 Task 构建优先级

建议按以下顺序构建（依赖关系 + 验证难度递进）：

第一批（Week 1-2）：15 个基础 Task

批次	Task IDs	理由
1.1	SE-001, SE-002, DE-001, DE-002, OA-001	最简单，验证架构可行性
1.2	SE-004, DE-003, CO-001, CS-001, OA-002	L1/L2，扩展领域覆盖
1.3	SE-003, DE-004, CO-002, PO-001, MP-001	L2，巩固多工具串联

第二批（Week 3-4）：20 个进阶 Task

批次	Task IDs	理由
2.1	SE-005, SE-006, DE-005, OA-003, OA-004	L2，引入更多 MCP Server
2.2	CS-002, CS-003, PO-002, MP-002, MP-003	L2，对话和前端场景
2.3	CO-003, CO-004, FIN-001, FIN-002, RET-001	L2/L3，垂直领域
2.4	SE-007, SE-008, DE-006, CS-004, PO-003	L3，复杂推理

第三批（Week 5-6）：15 个高难度 Task

批次	Task IDs	理由
3.1	SE-009, DE-007, CO-005, OA-005, OA-006	L3，深度推理
3.2	CS-005, PO-004, MP-004, FIN-003, FIN-004	L3，垂直专业
3.3	SE-010, OA-007, DE-008, RET-002, RET-003	L4，端到端

---

C.6 环境数据生成方法

所有 Task 的环境数据需要「可重复生成 + 可参数化变体」：

代码项目：模板 + 注入策略。正确版本作为 Golden，注入脚本制造 Bug。

数据库数据：Faker + 业务逻辑约束。参数化欺诈率、异常率等，确保可重复。

对话场景：对话树 + 条件分支。客户模拟器根据 Agent 回复质量动态调整后续对话。

文档：模板 + 参数替换。在正常合同/报告中注入指定问题。

---

C.7 评分权重建议

难度	task_completion	output_quality	efficiency	no_side_effects
L1	0.6	0.1	0.2	0.1
L2	0.5	0.2	0.2	0.1
L3	0.4	0.3	0.2	0.1
L4	0.3	0.3	0.2	0.2

• L1 重点看「做没做对」，效率和质量权重低
• L4 各维度均衡，side effects 权重提高（端到端任务更容易造成意外影响）
• output_quality 在 L3/L4 权重提高，因为涉及开放式产出