人工审核的双重职责HERMES & AGENT ENGINEERING · 课时 09

9.1 自动处理必须保留退出路径

传统软件遇到没有处理过的输入，通常会报错或者停止运行。Agent 系统更麻烦一些。它即使没有足够依据，也可能继续生成一个看起来完整的结果。如果这个结果随后进入证据层，或者被融合进知识页，用户看到的已经不是一次明显失败，而是一条很难察觉的错误判断。

所以，一个正常的 Agent 系统需要有 Human in the Loop，也就是让人在必要的时候进入自动流程并作出决定。它不是附加在系统外面的客服入口，而是主流程本身的一种合法状态：系统知道自己不能安全继续时，应当停在当前位置，整理已有信息，然后把决定交给用户。

胶囊系统已经有一个审核队列，用来处理流程中断、知识冲突和不可逆操作。现在还需要补上一条更通用的兜底规则：没有匹配的处理规则、必要信息缺失、结果检查失败，或者经过安全重试仍然无法继续，都归入“处理中断”。这样不必再增加一个含义重叠的处理入口，但原来没有预料到的问题也有地方可以进入。

当系统无法按照现有规则作出可靠决定，并且继续处理可能改变证据、知识页或造成不可逆后果时，必须暂停受影响的流程并进入人工审核。

这句话比“不确定时交给用户”更严格，因为它同时规定了触发条件和影响范围。系统不能只凭模型自己报告的信心高低来决定是否审核，还要检查结果是否缺少必填信息、是否违反已有约束、是否出现互相冲突的判断，以及当前状态有没有可执行的下一步。

9.2 不是所有不确定都需要人工处理

如果把所有不确定情况都送入人工审核，审核队列很快就会堆满价值很低的问题。用户每提交一份资料，都要替系统决定几个无关紧要的细节，自动化也就失去了意义。

更合适的做法是根据后果分流：

网页装饰图就是一个可以自动处理的例子。系统即使不能确认这张图的每个细节，只要它不影响正文理解，就可以记录省略结果并继续处理。相反，如果网页的核心结论只存在于一张无法可靠转换的图里，继续生成衍生证据就可能遗漏关键事实，这时必须进入人工审核。

因此，人工审核不是所有不确定性的统一出口，而是重要不确定性的最终出口。判断“重要”的标准不是系统觉得任务难不难，而是继续处理会不会改变用户保存的证据、知识判断或不可逆状态。

9.3 审核项必须支持继续处理

把问题送进审核队列还不够。如果审核项只有一句“处理失败，请人工确认”，用户仍然不知道该确认什么，也无法判断不同选择会产生什么后果。

一条完整的审核记录至少要回答下面这些问题：

这套记录仍然要遵守前面确定的纯文本规则。系统不能因为需要人工审核，就额外保存一份 PDF、图片、音频或视频。没有来源 URL，而且继续判断又需要原始内容时，审核项只能要求用户重新提交资料。

有了恢复位置和最终结果，人工审核才真正属于主流程。用户不是只给出一个孤立意见，而是在帮助系统完成一次被暂停的状态转换。决定作出以后，系统要么从中断处继续，要么留下终止结果，不能重新从头猜测用户当时遇到了什么问题。

9.4 审核案例也是规则缺口的来源

人工审核更重要的意义，是把设计阶段没有想到的情况留下来。需求简报和 SPEC 无论写得多详细，都只可能覆盖当前能够预见的问题。系统真正开始处理资料以后，一定还会遇到没有匹配规则的新输入。

这时，一条审核记录同时产生两种结果。第一种结果解决当前资料：用户作出决定，系统继续或终止处理。第二种结果保留系统为什么需要人工介入，为以后检查需求和规则留下一个案例。

系统遇到无法安全处理的情况
              ↓
       生成审核项
              ↓
       用户作出决定
          ↙       ↘
继续或终止当前流程   保留触发原因、决定和结果
                          ↓
                   归类相似审核案例
                          ↓
                   形成规则改进候选
                          ↓
              更新 Backlog / SPEC / 验收样例

拿独立图片来说，系统第一次遇到一张没有文字、但能够完整表达步骤关系的流程图时，可能不知道它是否满足“能够独立表达知识”的条件，于是生成审核项。用户确认它有知识价值，并补充了必要说明，这只解决了当前图片。

如果以后连续出现多张同类流程图，而且用户每次都作出相近决定，我们就能看见一个规则缺口：现有 SPEC 对纯图形流程图的判断还不够明确。此时可以把这些案例整理成一项需求变更，补充新的验收样例和功能需求。下一次系统再遇到同类输入，就有可能根据新规则自动处理。

但一次人工决定不能自动变成全局规则。用户可能只是在特定上下文中接受了一个例外。如果系统看到一次选择就自行学习，以后的资料反而会被错误套用。审核案例只能形成规则改进候选；是否更新需求简报、SPEC 和系统行为，仍然需要用户明确批准。

9.5 可以泛化到其他 Agent 系统

这套设计不只适用于胶囊系统。只要 Agent 会读取外部输入、生成判断并改变持久状态，就应该考虑同样的问题：哪些情况可以自动重试，哪些情况应该保守跳过，哪些情况必须暂停并交给人。

因此，可以为 Agent 项目保留一条通用原则：

Agent 在没有适用规则、结果未通过检查或多个判断互相冲突时，如果继续执行可能造成重要内容变化或不可逆后果，必须停止受影响的操作，生成可继续处理的审核项。审核记录还应支持发现重复出现的规则缺口，但不得未经批准自动修改全局规则。

这条原则同时约束运行时和后续开发。运行时，它防止 Agent 在不知道怎样处理时继续猜测；开发时，它把真实出现的未知情况变成下一轮需求、SPEC 和测试样例。系统不再要求第一版把所有问题一次想完，但每一个没有想完的问题都能被看见、处理和积累。

因为这条原则会约束资料处理、知识冲突、证据删除和以后的其他 Agent 功能，我们把它加入了胶囊系统宪章。宪章版本因此从 1.0.0 升到 1.1.0。至于哪些情况进入审核队列、审核项展示什么，以及用户决定后怎样恢复，仍然由当前 SPEC 规定。