Agent任务分解评测专题

版本：v1.1
最后更新：2026-07-07
适用对象：需要评估 Agent planner、工作流编排器、多 Agent 路由器、复杂任务计划质量和计划可执行性的产品、算法、平台与评测同学

很多 Agent 表面上看是“最后没把事做成”，但真正的根因常常更早：

任务拆错了
步骤边界不清
顺序依赖没理顺
高风险步骤没有单独暴露
计划文本看起来合理，但根本不适合后续工具执行

这也是为什么任务分解不能只当成中间产物，而要把它作为一个独立能力来评测。

Anthropic 在 Building effective agents 里强调，很多场景先用 workflow pattern 比直接放任 Agent 自由行动更稳；OpenAI 在 Agents guide 与 orchestration 文档里也把 handoff、tool use、structured state、trace 视为可观测的系统部件。这些官方思路都指向同一个结论：

计划质量会直接决定后续执行质量、成本、延迟和安全边界

1. 什么是任务分解评测

更实用的定义不是“看计划写得漂不漂亮”，而是：

判断 Agent 是否把复杂任务拆成了一组合理、完整、可执行、可监控、可交接的子任务

评测对象可以是：

单 Agent planner 生成的步骤列表
plan-and-execute 框架里的 planning node
orchestrator-workers 架构里的任务切分器
supervisor 多 Agent 系统里的 handoff 决策
工作流引擎里由模型生成的 DAG 或状态机

所以任务分解评测的核心不是语言质量，而是工程效用。

2. 为什么只看最终成功率不够

如果只看“任务有没有完成”，很多问题会被淹没：

分解本身差，但 executor 靠重试碰巧补救成功
计划遗漏关键步骤，但人工中途接管把结果拉回来了
分解过细，导致 token 成本和回合数暴涨
分解顺序不合理，造成无意义等待和工具反复调用
高风险步骤没有单独拆出，结果执行链路缺少审批点

OpenAI 的 evaluation best practices 明确反对只凭感觉做评测，也强调要把评测目标和可测指标前置定义好。

对应到 Agent 场景里，至少要分开观察：

层次	要回答的问题
最终结果	任务最后有没有完成
分解质量	计划是否完整、结构合理、可执行
过程代价	为了完成任务走了多少步、花了多少钱、用了多少时间
风险治理	是否把审批、确认、人工接管、权限边界正确暴露

如果没有第二层和第三层，团队很容易误判问题位置。

3. 哪些场景最需要单独评测任务分解

越复杂、越多阶段、越依赖外部系统的任务，越要单独做任务分解评测。

典型场景包括：

多工具协作任务
长任务工作流
多文档综合分析
含审批、人工接管和回退的业务流程
多 Agent 协同执行
需要先规划后执行的代码、运营和交付任务

这些场景里，前面的计划质量往往决定：

后面是否会绕圈
是否会反复调同一工具
是否能正确保留中间状态
是否能在恰当时机转人工
是否能在预算内收敛

4. 评测对象到底是什么

不要把“任务分解评测”理解成只评一个计划文本。

更完整的评测对象通常包括：

对象	示例
任务输入	用户原始需求、上下文、约束条件
计划结构	step 列表、树状计划、DAG、状态机
步骤元数据	owner、tool、risk、依赖、输入输出
执行轨迹	trace、tool calls、handoff、重试、回退
最终结果	完成情况、质量、成本、时延

OpenAI tracing 与 trace grading 的意义就在这里：

计划不是孤立文本，必须和真实执行轨迹一起评

LangGraph 官方文档也反复强调 state、node、edge、subgraph 是一等公民。换句话说，计划的“结构信息”应该进入评测，而不是只留一段自然语言。

5. 一个更实用的计划数据模型

如果计划没有结构化格式，评测就会非常痛苦。

建议至少把计划落成类似下面的 schema：

json

{
  "task_id": "case_001",
  "goal": "处理企业客户退款申请并同步 CRM",
  "constraints": [
    "金额超过 5000 需要审批",
    "禁止直接写入财务系统"
  ],
  "steps": [
    {
      "step_id": "s1",
      "name": "读取退款政策与订单状态",
      "type": "read",
      "owner": "retrieval_agent",
      "tools": ["search_policy", "query_order"],
      "depends_on": [],
      "risk": "low",
      "expected_output": "订单是否符合退款条件"
    },
    {
      "step_id": "s2",
      "name": "判断是否需要人工审批",
      "type": "decision",
      "owner": "planner",
      "tools": [],
      "depends_on": ["s1"],
      "risk": "medium",
      "expected_output": "审批或直通结论"
    },
    {
      "step_id": "s3",
      "name": "生成审批摘要并转人工",
      "type": "handoff",
      "owner": "human_review",
      "tools": ["create_approval_ticket"],
      "depends_on": ["s2"],
      "risk": "high",
      "expected_output": "审批工单"
    }
  ]
}

结构化计划带来的好处是：

可以检查步骤是否缺失
可以检查依赖是否成环
可以统计高风险步骤是否被单独暴露
可以把计划和 trace 自动对齐
可以做 step-level 的离线评测和线上监控

如果模型支持 structured outputs，就尽量让 planner 直接输出 schema，而不是先输出散文计划再靠正则清洗。

6. 任务分解评测通常看什么

更有价值的维度不是“步骤多不多”，而是以下六类。

6.1 完整性

是否覆盖完成任务必需的关键步骤
是否识别出必要前置条件
是否包含异常分支、失败分支和审批分支

6.2 结构性

步骤顺序是否合理
依赖关系是否正确
是否存在重复步骤、无关步骤或环形依赖

6.3 可执行性

后续工具或人工是否真的能按该计划执行
每一步是否有明确 owner、工具和输入输出
是否把抽象表述落到了可操作动作

6.4 风险暴露

高风险步骤是否被显式拆出
是否为审批、确认、人工接管留出挂点
是否避免把高风险写操作和普通读操作混在一步里

6.5 预算意识

计划是否考虑成本、回合数和时延约束
是否把能并行的步骤识别出来
是否避免无意义拆分导致链路变长

6.6 可观测性

计划是否能和 trace 对齐
是否能回放每个步骤
是否能把失败定位到具体 step 或 edge

7. 一个更实用的三层评测框架

很多团队会把任务分解评测拆成三层，这种做法最容易落地。

7.1 计划文本层

只看计划本身：

步骤是否齐全
顺序是否合理
是否输出了结构化字段

这一层便宜，但容易高估质量。

7.2 计划执行层

把计划喂给 executor 或 workflow engine：

看是否能顺利执行
看是否频繁重试、跳步、卡死、超回合

这一层能暴露“看着合理但用不了”的计划。

7.3 结果联动层

把计划质量和最终业务结果挂钩：

好计划是否显著提升成功率
好计划是否减少超时和人工接管
好计划是否降低 token 和工具成本

真正有价值的分解评测，必须至少覆盖后两层。

8. 如何构建任务分解评测集

8.1 样例不要只收成功任务

评测集要覆盖：

正常任务
信息不足任务
高风险任务
多分支任务
会失败的任务
需要人工接管的任务
工具部分不可用的任务

否则 planner 很容易在测试集上表现很好，但一上线就失稳。

8.2 每条样例建议包含这些字段

json

{
  "id": "plan_case_014",
  "task": "给企业客户办理退款并通知 CRM",
  "context": {
    "refund_policy": "金额大于 5000 需要审批",
    "available_tools": [
      "query_order",
      "search_policy",
      "create_approval_ticket",
      "draft_crm_note"
    ]
  },
  "must_have_steps": [
    "读取订单状态",
    "校验退款政策",
    "判断是否需要审批"
  ],
  "must_not_have_steps": [
    "直接调用财务打款"
  ],
  "critical_dependencies": [
    ["读取订单状态", "判断是否需要审批"]
  ],
  "risk_checkpoints": [
    "高金额审批"
  ],
  "difficulty": "medium"
}

8.3 标注重点不是写一份唯一标准答案

复杂任务通常不存在唯一计划。

更可行的标注方式是：

必须包含什么
绝不能做什么
哪些步骤可以顺序互换
哪些步骤一定要先后依赖
哪些高风险环节必须显式暴露

这比要求“一字不差复现黄金计划”更符合真实业务。

9. 评测指标怎么设计

9.1 离线指标

指标	说明
must_have_coverage	必要步骤覆盖率
extra_step_rate	无关步骤比例
dependency_accuracy	依赖关系正确率
risk_checkpoint_recall	风险节点召回率
executable_step_rate	可直接执行步骤比例
schema_valid_rate	计划 JSON / schema 合法率

9.2 联动指标

指标	说明
plan_to_success_lift	高质量计划对最终成功率的提升
replan_rate	执行中被迫重规划的比例
overrun_turn_rate	超回合比例
tool_retry_rate	因计划问题引起的工具重试比例
human_handoff_rate	需要人工介入的比例
cost_per_completed_task	完成任务的平均成本

9.3 长尾指标

尤其要看：

高风险任务的计划质量
长上下文任务的计划质量
多工具任务的计划质量
多租户和权限敏感任务的计划质量

平均值很容易掩盖真正有害的 planner 失败样例。

10. 如何把计划和 trace 对齐

OpenAI trace grading 的一个关键启发是：

很多中间能力要通过 trace 才能稳定评测

在任务分解场景里，建议记录：

json

{
  "task_id": "plan_case_014",
  "plan_id": "plan_001",
  "step_id": "s2",
  "trace_span_id": "span_9342",
  "event": "decision",
  "tool_calls": [],
  "status": "completed",
  "latency_ms": 420,
  "tokens": 560,
  "replan": false
}

这样我们就能回答：

哪个计划步骤最容易失败
哪类步骤最容易触发重规划
哪类计划虽然正确，但执行代价极高
哪些风险节点总被 planner 漏掉

如果没有 step_id 到 trace span 的映射，任务分解评测就很难自动化。

11. 为什么要把任务分解和执行结果联动

只看计划文本，容易出现两种错觉：

计划看起来完整，但 executor 根本用不好
计划表述简洁，却能明显提高执行成功率

更稳妥的做法是做 A/B 或离线回放对比：

计划 A 对比计划 B
旧 planner prompt 对比新 planner prompt
纯自由规划对比固定计划骨架
单 Agent planner 对比 orchestrator-workers 模式

最终关心的是：

哪种分解方式让成功率更高
哪种分解方式让成本更低
哪种分解方式让高风险场景更安全

12. 常见失败模式

12.1 漏步骤

表现：

计划没考虑审批、验证、引用校验、写前确认

后果：

最终结果表面完成，但合规或质量不达标

12.2 过度拆分

表现：

一个简单任务被拆成十几个微步骤

后果：

token 成本高
回合变长
executor 上下文切换增加

12.3 步骤过粗

表现：

一个步骤同时包含检索、判断、写入、通知

后果：

无法评测
无法审计
无法做审批挂点

12.4 顺序错误

表现：

先写后查
先执行后审批
先通知后验证

后果：

引发不可逆业务动作或重复返工

12.5 工具与 owner 不清

表现：

步骤只是自然语言，没说谁来做、用什么做

后果：

执行链路无法稳定复现

12.6 缺少失败分支

表现：

计划只写成功路径

后果：

工具报错、信息不足、权限不足时马上失控

13. 优化任务分解的常见手段

13.1 给 planner 强制结构化输出

不要让 planner 自由写散文计划。

而是要求输出：

step_id
name
depends_on
owner
tools
risk
expected_output

13.2 给复杂任务固定骨架

例如高风险业务统一要求出现：

text

读取事实
 -> 校验规则
 -> 风险判断
 -> 审批或确认
 -> 执行动作
 -> 记录与通知

这比让模型每次从零发明流程要稳。

13.3 按任务类型使用不同 planner

不是所有任务都该走同一套任务分解策略。

可以按：

RAG 问答
客服流程
代码任务
审批流程
数据处理流程

分别准备 plan schema 和 few-shot。

13.4 对高风险任务引入人工审计划

尤其是：

大额资金
权限变更
对外发送
批量修改
法务与合规动作

这些任务的重点不是 planner 能不能写出计划，而是计划是否值得信任。

13.5 用历史失败样例做回归

把失败计划沉淀成评测集，比不停换 prompt 更有用。

OpenAI evaluation best practices 也强调，评测要持续跑、持续对比，而不是一次性验收。

14. Planner 设计上的几个现实建议

14.1 能工作流解决的，不一定要上自由 Agent

Anthropic Building effective agents 的一个重要原则是：

先从最简单可行方案开始，只在需要时增加复杂度

这对任务分解尤其重要。

如果任务本来是固定流程：

不如直接用工作流
或给 planner 很强的骨架约束

而不是追求“万能自主规划”。

14.2 计划不是越长越好

长计划不等于好计划。

更好的计划应该是：

包含关键步骤
暴露关键风险
对 executor 可执行
在预算内收敛

14.3 计划和状态设计要一起做

LangGraph 官方文档里，state 设计和 graph 设计是紧耦合的。

如果状态模型过乱，planner 很难知道：

当前已经完成到哪一步
哪些事实已经确认
哪些工具结果可以复用
何时需要 replan

所以任务分解评测也应覆盖状态读写质量。

15. 线上应该监控哪些信号

建议对 planner 记录以下字段：

json

{
  "task_type": "refund_workflow",
  "plan_steps": 6,
  "must_have_missing": 1,
  "high_risk_steps": 1,
  "replan_count": 2,
  "tool_retry_count": 3,
  "total_turns": 9,
  "human_handoff": true,
  "task_success": false,
  "estimated_cost_usd": 0.043,
  "total_latency_ms": 12600
}

重点监控：

指标	用途
avg_plan_steps	计划是否越来越膨胀
replan_rate	计划稳定性
missing_must_have_rate	漏关键步骤情况
over_budget_plan_rate	计划是否超预算
human_handoff_after_bad_plan	差计划是否推高人工负担
task_success_by_plan_quality	计划质量与结果的相关性
cost_by_plan_pattern	哪类分解最烧钱

16. 一个可执行的评测流程

16.1 先定义任务类型

把 planner 面对的任务先分桶：

固定流程
半结构化流程
开放式复杂任务
高风险审批任务

16.2 为每类任务准备评测样例

至少覆盖：

成功路径
失败路径
信息不足
工具不可用
需要人工接管

16.3 要求 planner 输出结构化计划

优先 JSON / schema。

16.4 跑离线评测

检查：

must-have 覆盖
dependency 正确率
风险节点召回
schema 合法率

16.5 跑执行回放

检查：

是否频繁 replan
是否超回合
是否触发多次无效工具重试

16.6 关联业务指标

最终看：

成功率
成本
时延
人工负担
安全事件

如果任务分解评测不能落到这些结果指标上，就还不算闭环。

17. 常见反模式

只评测最终答案，不评测计划
计划没有结构化格式
用一个黄金计划要求所有样例逐字匹配
只看平均步骤数，不看关键步骤缺失
只限制最大回合，不分析为什么会 replan
高风险任务没有单独的计划骨架和审批节点
计划和 trace 断开，无法回放
Planner 优化只看 prompt，不看工具、状态和执行器约束

18. 推荐搭配阅读

19. 落地检查清单

是否把任务分解当成独立能力评测，而不是只看最终成功率？
是否要求 planner 输出结构化计划，而不是散文式说明？
是否定义 must-have、must-not-have、依赖关系和风险节点？
是否把计划和 trace step_id 对齐，支持回放？
是否能衡量计划质量对成功率、成本和时延的影响？
是否沉淀失败计划样例做回归？
是否为高风险任务引入固定骨架、审批节点或人工审计划？
是否区分固定流程和开放式复杂任务，避免一套 planner 通吃？

20. 推荐资源

以下资源在 2026-07-07 检查时可访问。部分页面内容会持续演进，上线前建议再次核查。

21. 最后总结

任务分解评测不是在评“计划写作能力”，而是在评：

这个计划能不能让系统更稳地完成任务
能不能把风险、成本和人工接管点提前暴露出来
能不能和工具、状态、trace、评测体系真正接起来

如果团队还只看最终成功率，就很容易把 planner 的问题误判成工具问题、模型问题或数据问题。

更成熟的做法，是把计划结构、执行轨迹和业务结果连起来，持续比较：

哪类计划真的提高了成功率
哪类计划只是让链路更长更贵
哪类任务根本不该交给自由规划

这样任务分解评测才会从“看起来合理”进化到“可以生产落地”。

Agent任务分解评测专题 ​

1. 什么是任务分解评测 ​

2. 为什么只看最终成功率不够 ​

3. 哪些场景最需要单独评测任务分解 ​

4. 评测对象到底是什么 ​

5. 一个更实用的计划数据模型 ​

6. 任务分解评测通常看什么 ​

6.1 完整性 ​

6.2 结构性 ​

6.3 可执行性 ​

6.4 风险暴露 ​

6.5 预算意识 ​

6.6 可观测性 ​

7. 一个更实用的三层评测框架 ​

7.1 计划文本层 ​

7.2 计划执行层 ​

7.3 结果联动层 ​

8. 如何构建任务分解评测集 ​

8.1 样例不要只收成功任务 ​

8.2 每条样例建议包含这些字段 ​

8.3 标注重点不是写一份唯一标准答案 ​

9. 评测指标怎么设计 ​

9.1 离线指标 ​

9.2 联动指标 ​

9.3 长尾指标 ​

10. 如何把计划和 trace 对齐 ​

11. 为什么要把任务分解和执行结果联动 ​

12. 常见失败模式 ​

12.1 漏步骤 ​

12.2 过度拆分 ​

12.3 步骤过粗 ​

12.4 顺序错误 ​

12.5 工具与 owner 不清 ​

12.6 缺少失败分支 ​

13. 优化任务分解的常见手段 ​

13.1 给 planner 强制结构化输出 ​

13.2 给复杂任务固定骨架 ​

13.3 按任务类型使用不同 planner ​

13.4 对高风险任务引入人工审计划 ​

13.5 用历史失败样例做回归 ​

14. Planner 设计上的几个现实建议 ​

14.1 能工作流解决的，不一定要上自由 Agent ​

14.2 计划不是越长越好 ​

14.3 计划和状态设计要一起做 ​

15. 线上应该监控哪些信号 ​

16. 一个可执行的评测流程 ​

16.1 先定义任务类型 ​

16.2 为每类任务准备评测样例 ​

16.3 要求 planner 输出结构化计划 ​

16.4 跑离线评测 ​

16.5 跑执行回放 ​

16.6 关联业务指标 ​

17. 常见反模式 ​

18. 推荐搭配阅读 ​

19. 落地检查清单 ​

20. 推荐资源 ​

OpenAI ​

Anthropic ​

LangGraph / LangChain ​

21. 最后总结 ​

Agent任务分解评测专题

1. 什么是任务分解评测

2. 为什么只看最终成功率不够

3. 哪些场景最需要单独评测任务分解

4. 评测对象到底是什么

5. 一个更实用的计划数据模型

6. 任务分解评测通常看什么

6.1 完整性

6.2 结构性

6.3 可执行性

6.4 风险暴露

6.5 预算意识

6.6 可观测性

7. 一个更实用的三层评测框架

7.1 计划文本层

7.2 计划执行层

7.3 结果联动层

8. 如何构建任务分解评测集

8.1 样例不要只收成功任务

8.2 每条样例建议包含这些字段

8.3 标注重点不是写一份唯一标准答案

9. 评测指标怎么设计

9.1 离线指标

9.2 联动指标

9.3 长尾指标

10. 如何把计划和 trace 对齐

11. 为什么要把任务分解和执行结果联动

12. 常见失败模式

12.1 漏步骤

12.2 过度拆分

12.3 步骤过粗

12.4 顺序错误

12.5 工具与 owner 不清

12.6 缺少失败分支

13. 优化任务分解的常见手段

13.1 给 planner 强制结构化输出

13.2 给复杂任务固定骨架

13.3 按任务类型使用不同 planner

13.4 对高风险任务引入人工审计划

13.5 用历史失败样例做回归

14. Planner 设计上的几个现实建议

14.1 能工作流解决的，不一定要上自由 Agent

14.2 计划不是越长越好

14.3 计划和状态设计要一起做

15. 线上应该监控哪些信号

16. 一个可执行的评测流程

16.1 先定义任务类型

16.2 为每类任务准备评测样例

16.3 要求 planner 输出结构化计划

16.4 跑离线评测

16.5 跑执行回放

16.6 关联业务指标

17. 常见反模式

18. 推荐搭配阅读

19. 落地检查清单

20. 推荐资源

OpenAI

Anthropic

LangGraph / LangChain

21. 最后总结