Agent 的验收样本要按失败分支覆盖，不是按成功次数累计

2026-08-25

站内工具 AI 编程工具报错分诊器 → 把报错原文贴进去，先分清是网络、额度、配置还是上游故障，再决定往哪个方向查。

那阵子我在给自己搭的一个 Agent 补文档。它的岗位是写公众号文章：我把链接或主题丢给它，它分析素材、给我几个写作方向让我选、出提纲让我确认、核验资料、写正文、生成封面，最后把成果结构化地存下来。这套流程是我自己一步步拆出来的，也是我自己在用，下面写的是这条流水线上发生的一件具体的事。

问题出在验收环节。我当时以为验收这件事已经算做完了——它跑通过完整的链路，产物齐全，我看了正文也基本满意。直到我坐下来准备写「还有什么没做」的时候才发现，我手上根本没有验收样本，我攒下的全是「它顺利的时候长什么样」的记录。

现象：样例目录之间，只有主题不一样

这个 Agent 的交付物不是一份终稿，而是一整个目录。每次任务落盘一个目录，里面按确认顺序摆着几份文件：原始链接和素材、备选方向以及最终选了哪个、确认后的提纲、补充资料与引用来源、文章正文、封面图。设计这套结构的初衷是把每个人工确认节点的输入输出都固化成文件，不留在对话记录里。

也正因为它们是文件，摊开一看就很刺眼：这些目录彼此之间，除了主题不同，文件清单一样、段落骨架一样、连哪一步花了几个来回都一样。没有一个目录里躺着一份「这次没成」的记录，因为确实没出过错。

这不是好消息。它意味着我攒下来的不是一批样本，而是同一条路径的若干份副本。

我是怎么发现的：不是跑出来的，是列清单列出来的

这一段我觉得比问题本身更值得写。

我不是通过增加运行次数发现覆盖不足的——多跑几次，只会让副本更多。我是在写这个岗位的「已知问题与待补」那一节时发现的。当时我给自己列了一份还没试过的场景清单，逐条写下来：

纯文字主题（不给链接，只给一个题目）
链接不可读（要登录、付费或干脆打不开）
高风险主题（投资、医疗、法律、政治这类）
资料冲突（几份来源互相打架）
封面失败
草稿接口失败

列到一半我就停住了。这几条没有一条是「另一种成功」，全都是岔口——是流程在某个判断点上转向的那些方向。而我手上的样例，一条都没落在这些方向上。

发现方式之所以关键，是因为它换了个维度提问。「我跑通了没有」问的是成功与否，答案是有的；「我还有哪些走法没走过」问的是覆盖，答案是几乎全没走过。这两个问题都指向验收，但只有后一个能把缺口暴露出来。

顺带说一句，这几条待补场景的成因并不是一回事。链接不可读、封面生成失败、接口授权异常属于外部能力或技术异常，是环境把流程顶到别的分支上；高风险主题不一样，它不是技术出错，而是流程走到「人工不放行」这条边上，停下来等我表态。这两类节点在流程图上有个共同点：都不在正常路径上，只有出岔口的时候才会亮。但成因是两种，一种是环境把流程顶偏了，一种是人没放行。成因不同，构造这类场景的方式也不同，混在一张清单上按同样办法去补，会补不到点上。

为什么会这样：节点覆盖会伪装成分支覆盖

我事后想明白的是，成功路径有一个迷惑性很强的特点——它是全量经过的。

一次顺利的运行，会依次经过解析输入、评估选题价值、生成写作方向、确认提纲、检索核验资料、撰写正文、优化标题、生成封面、最终质量与风险检查、结构化落盘。工序表上的格子几乎被全部走过一遍。看着像是覆盖得很充分。

但工序被走到，和工序的每种走法被走到，是两码事。

我把流程图翻出来对着看，上面画着若干条回退边：正文没达到真人感的要求，退回撰写正文；核心依据核验不过，退回评估选题价值这一步重新判断这个题还值不值得写；提纲没通过删除测试，退回重新生成提纲；标题给出的承诺正文兜不住，退回优化标题。这几条边，我手上没有任何一份记录能证明它们被走过。它们是我画上去的，而画上去的东西能不能真的跑起来，我拿不出验证的凭据。

还有一层是心理上的。每多跑通一次，我对这套流程的信心是实打实在涨的，但涨的是熟悉感，不是覆盖率。用成功次数累计出来的信心，恰好会掩盖「这些次其实是同一次」这个事实。

改成了什么：把验收问题从「通了吗」换成「哪条还没走过」

我做了三件事。

第一，场景按岔口列，不按功能列。 每一条待补场景都要能指回流程图上具体的一条边或一个闸门，指不回去的就说明我描述的是功能而不是分支。「测一下封面」不算，「封面生成失败之后流程怎么走」才算。

第二，先判断这个场景能不能构造出来。 有些构造起来很直接：纯文字主题，不给链接只给题目就是；链接不可读，找一个要登录才能看的链接丢过去即可；资料冲突，给两份说法相左的素材，看它是照单全收还是停下来找我。这几条不缺条件，缺的只是我把它们跑一遍。

第三，造不出来的如实标成未覆盖，不许含糊过去。 清单最后一条「草稿接口失败」，我到现在也没法真跑——因为那条链路本身就还没接通。这个 Agent 的交付终点，目前是「文章和封面已生成并保存」，不是「已进入草稿箱」。所以这一条只能等链路接通之后再补。

但没接通不等于什么都不做。我把这个动作的验收标准先写死在说明书里了：以拿到返回值后再次查询列表、确认草稿真的在那儿为准，不以调用没报错为准；并且明文禁止把「接口已提交」当成「草稿已创建」。这是在功能还没开始做的时候先写好的一条验收标准，不是一次已经发生过的事故——我特意说清楚，是因为这两者的性质完全不同。先定标准的好处在于，等这条链路真接上的那天，我不用再回头判断怎么算成功。

清单本身我也按同样的方式处理了：落成文件，跟其它环节的产物摆在一起，而不是记在脑子里。这套流程的规矩就是每个确认节点的输入输出都单独落盘，一份「还有什么没验过」的清单没有理由例外。

可迁移的判断

跑通十次同一条路，不如跑一次没走过的分支。

如果要一个当场能用的自查动作，我会这么问自己：把最近几次运行摆开，第一处走法不同的地方在哪里？如果找了半天只找到主题不同，那这几次就是同一次的复印件，别把它们当成样本量。

再往前一步的问法是：我画在流程图上的每一条边，有没有哪一条是我从来没让它亮起来过的？没亮过的边，等于没写。它在图上，不在流程里。

这篇写的是我自己那套流程里的一次实际情况，不是通行做法。你的场景、工具和团队规模不同，结论未必适用，判断方式可能比结论更值得拿走。