为什么 Agent 接到任务后，第一步不该是动手
任务完成路径是 Agent 从需求到产出的拆解与推进能力，PM 要把它设计成可观测、可埋点的维度。
立靶：路径不清晰的 Agent，会用三种方式让你失望
先看一个场景。你给一个编码 Agent 派活：「把这份原始日志清洗一下，统计出每天的有效通话率，画个趋势图。」
一个路径不清晰的 Agent，往往这样开场：直接打开一个文件，把读数据、清洗、统计、画图全塞进一个脚本里，一口气写完。表面上它「完成」了——跑出了一张图。但你接手时会发现：数据清洗和分析糊在一起，想换个统计口径得重写半个脚本；中间某一步出错，它没意识到，继续往下算，最后那张图是错的，它却报告「已完成」。
这就是任务路径不清晰的第一种失败：跑偏。Agent 在没有把需求拆成有序步骤之前就动手，于是它对「自己现在在整条路径的哪一步」没有概念，错了也不知道错在哪。
第二种是半途而废。任务被它当成一个不可分的黑块，执行到一半遇到一个卡点（比如某个依赖不存在），它要么停下来反问你「怎么办」，要么干脆放弃，留下一个残缺的中间态。因为它从没规划过「这条路有几个台阶」，自然也不知道卡在第几阶、还差几阶。
第三种是越界。它确实完成了你要的统计，但顺手把你整个项目的代码重构了一遍，加了三个你没要求的功能。它把「路径」无限延长，分不清「任务边界在哪里」。
这三种失败有一个共同根因：Agent 没有一条显式的、可被自己和你共同观察的任务完成路径。 它把「接到需求」直接短路到「产出结果」，中间那段本该被规划、被分段、被检查的过程是黑的。
所以「任务完成路径」作为一个能力维度，要测量的不是「它最后做完了没」，而是：从需求到产出，这个 Agent 是怎么分解和推进任务的——它有没有把一个模糊请求，变成一串有序、可验证、有边界的动作。
框架：把任务完成路径拆成四个阶段
要评估一个看不见的过程，先得给它一个结构。我把任务完成路径拆成四个阶段：理解、规划、执行、收敛。每个阶段都有它该做的关键动作、对应的失败风险，以及——对 PM 最重要的——可以埋点观测的指标。
| 阶段 | 关键动作 | 失败风险 | 可埋点指标 |
|---|---|---|---|
| 1. 理解需求 | 复述任务、识别隐含约束、确认验收标准、判断边界 | 把模糊请求当成精确请求直接执行；漏掉隐含约束 | 是否产出任务复述/计划；澄清提问率 |
| 2. 规划拆解 | 把任务拆成有序子步骤、分离关注点、排出依赖顺序 | 不拆解直接动手；步骤糊成一团无法单独验证 | 子步骤数量；是否生成显式 plan/todo；步骤是否带验收点 |
| 3. 执行推进 | 逐步执行、每步自检、维护进度状态、遇阻调整 | 错了不自知继续往下；卡住即停或放弃 | 每步是否有结果校验；中途放弃率；卡点反问 vs 自主推进比 |
| 4. 收敛交付 | 对照验收标准自检、汇报路径与结果、停在边界内 | 越界做无关的事；声称完成但未自检 | 交付是否对齐初始验收标准；越界动作数；完成自检覆盖率 |
这张表的用法不是逐格打钩，而是帮你定位「这个 Agent 在哪一阶段最弱」。一个常见的诊断：很多 Agent 的执行能力（阶段 3）很强，单步工具调用又快又准，但理解与规划（阶段 1、2）几乎是空的——它跳过了「先想清楚」，直接进入「埋头干」。结果就是上一节那三种失败。
好的 Agent 会在动手前主动做出合理的工程决策——比如把数据生成和数据分析拆成两个文件，即使你没明确要求。这种「分离关注点」本身就是规划阶段质量高的信号，它说明 Agent 在脑子里先走了一遍路径，而不是边写边想。
这里要特别区分两种「超出预期」，因为它直接关系到阶段 4 的评分。有价值的超出预期，是在任务路径内做得更完备：提前处理了边界情况、同时给出两个有用的统计口径。无价值的超出预期，是把路径延伸到任务边界之外：加你没要的功能、重构无关代码。前者该加分，后者该扣分。一个路径清晰的 Agent，知道自己的路通向哪里，也知道路在哪里到头。
case：两个 Agent 跑同一个清洗任务
回到开头那个清洗日志、算有效通话率、画趋势图的任务（场景脱敏自一次真实的内部数据分析委托）。我用两个 Agent 跑，对照它们的任务路径。
Agent A（路径黑块型）：收到需求，立即新建一个脚本，从读 CSV 到画图全写在一个文件里。运行时报错 python: command not found，它停下来问「环境里好像没有 python，我该怎么办？」——这是阶段 3 的卡点放弃。修好环境后它跑出一张图，报告「已完成」。但它用的是全量通话做分母，没区分有效通话，而需求里的「有效通话率」隐含了这个约束。它在阶段 1 漏了隐含约束，又在阶段 4 没对照验收自检，于是交付了一个看起来完整、实则口径错误的结果。
Agent B（路径清晰型）：收到需求，先复述了一句「我理解是要清洗原始日志、按天统计有效通话占比、再画趋势」，并主动确认了「有效通话」的口径。然后它把任务拆成两个文件：一个负责数据清洗与口径计算，一个负责统计与画图——分离关注点，方便后续换口径。执行中同样遇到 python: command not found，但它没有停下来反问，而是自动判断「macOS 默认没有 python，改用 python3」，重试成功——这是「工具失败→自主调整→成功」的标准恢复。最后它对照初始口径自检，并额外给出了「全量通话率」和「有效通话率」两版数据，标注清楚区别。
两个 Agent 都「完成」了任务。但 A 的路径是黑的，所以它的错误对你不可见，它的卡点要你来兜底；B 的路径是亮的，每一阶段都留下了可观察的痕迹。差距不在于谁更聪明，而在于谁把任务当成一条需要规划和验证的路径，而不是一个一步到位的黑块。
可操作做法：怎么把任务路径设计成可观测的能力
设计层面——让路径变得可观测：
- 强制 Agent 在执行前产出一份显式的 plan 或 todo 列表，哪怕任务很小。这把阶段 1、2 的内部思考外化成你能看见、能埋点的产物。
- 让每个子步骤自带一个验收点（这一步做完，怎么算对）。没有验收点的步骤，等于阶段 3 没有自检的接口。
- 在 prompt / 系统设计里显式写明任务边界：哪些算分内、哪些算越界。给阶段 4 一条明确的「到此为止」线。
- 区分「该问」和「不该问」。理解阶段缺关键约束时应该澄清；执行阶段遇到能自己 debug 的卡点不该反问。
度量层面——怎么定 KPI：
- 不要只用「任务完成率」这一个指标，它会奖励「跑偏但交付了」的 Agent。至少拆出「完成率」和「完成质量（对照验收标准的自检通过率）」两个口径。
- 埋点「显式 plan 产出率」：有多大比例的任务，Agent 在动手前给出了拆解。这是规划能力最直接的代理指标。
- 埋点「中途放弃率」和「卡点反问率」：高放弃率指向阶段 3 推进能力弱；反问率要分场景看。
- 埋点「越界动作数」并人工标注有价值 vs 无价值的比例，用来调阶段 4 的边界。
- 所有指标的阈值必须用真实任务数据校准，不要拍脑袋设。
一个提醒：这些指标之间不是简单相加的关系。完成率高但越界多、自检覆盖低，整体路径质量未必好。评估时按维度看强弱，而不是合成一个总分掩盖掉具体短板。
收口
评估一个 Agent，别只问「它做完了吗」，要问「从需求到产出，这条路它是怎么走的，每一步你都看得见吗」。