人在回路中的悄然退化
人在回路常被描述为一项安全功能。实际上它是一条回退路径，而回退路径会悄然退化。这种退化很少以失败的形式宣告自己；它表现为延迟上升、决策不一致，以及未解决的边缘案例积压不断增加。其机制在各种部署中是一致的：升级发生时没有状态移交，因此操作员必须从对话记录中重建上下文。这种重建是有损的。操作员做出一个局部合理的判断，请求继续推进，而根本原因依然未被触及。
一个具体的机制可以说明这个问题。一个 agent 被要求将一条货运记录与一张发票进行核对。它调用一个检索工具，收到两个候选匹配项，却无法消歧。对话记录显示了两个候选项以及向用户提出的最后一个问题。阅读该对话记录的人类操作员看到了候选项，却看不到 agent 的内部置信度、检索分数、工具参数，或阻止自动选择的策略规则。操作员挑选了其中一个候选项。任务完成。agent 的记忆中没有任何改变，因此下一个具有相同歧义的货运记录会走到同一个死胡同。人类吸收了失败，而非修复了它。
这是第一种失败模式：没有状态移交的升级迫使人们进行重建。第二种是人类所做的修正没有作为策略或记忆更新写回，因此同样的失败会反复出现。第三种是数量压力。当升级到达的速度快于操作员能够调查的速度时，批准就成了阻力最小的路径。橡皮图章式审批将监督变成了一种延迟税：组织为人类的注意力付出了代价，却没有获得额外的安全性，因为人类不再是在评估决策，只是在放行它。
升级契约
一份升级契约包含三个部分：触发器、载荷和返回。每个部分都必须是明确且机器可读的，而不是靠惯例隐含。
触发器
触发器定义了 agent 何时停止并移交。有用的类别包括：
- 置信度阈值：agent 对其下一步动作的校准置信度低于配置的界限。
- 工具错误：某个工具返回错误、空结果或 schema 违规，而 agent 无法在其重试预算内解决。
- 不可逆操作：下一步将删除、发布、转移或以其他方式提交一个无法回滚的状态变更。
- 策略拒绝：某个 guardrail 阻止了某个动作，而 agent 没有获准的替代路径。
触发器应与 agent 的工具定义一起声明，而不是散落在 prompt 文本中。只存在于 prompt 中的触发器是一种建议；存在于代码中的触发器才是一份契约。
载荷
载荷是操作员所收到的内容。对话记录不是载荷。载荷包含：
- agent 所理解的目标，包括原始请求以及已经应用的任何澄清。
- 到目前为止的计划：执行了哪些步骤、哪些成功、哪些被跳过，以及原因。
- agent 考虑过的候选动作，以及它将使用的参数。
- 每个候选动作的证据：检索分数、工具输出、策略引用，以及触发升级的具体不确定性。
对载荷的检验标准是：一个从未见过该任务的操作员能否在不打开另一个系统的情况下做出决定。如果他们必须查询 CRM、重新运行检索，或询问请求者是什么意思，那么载荷就是不完整的。
返回
返回定义了操作员可以做什么，以及该决定产生什么产物。三种结果覆盖了大多数情况：
- 批准：操作员确认 agent 提议的动作。产物是一份签署的批准记录，绑定到动作参数和证据快照。
- 修正：操作员更改动作、参数或目标。产物是 agent 提议与操作员决定之间的 diff，外加一个原因代码。
- 中止：操作员停止任务。产物是一个带有原因代码的终态，以及一个标志，指示该任务应重新规划还是返回给请求者。
每种结果都必须产生一个持久产物。仅作为队列中一次点击而存在的批准不是持久的；它无法被审计、重放，也无法用作训练信号。产物是契约的输出，正是它使这个循环变得可学习。
闭环
升级契约的价值不在于它产生更好的单次决策。而在于它产生数据。每一次人类修正都是 eval 套件中一个回归测试的候选。该修正编码了一个 agent 做错的案例，以及一个人类认可的更正。这一对恰好就是一个测试用例的形态：输入、预期动作和理由。
这条流水线是机械式的。当操作员修正某个动作时，diff 和原因代码被写入一个存储。一个审查步骤将选定的修正提升到 eval 套件中，在那里它们会在每次变更时针对当前 agent 运行。如果 agent 现在对该输入产生操作员修正后的动作，该用例通过。如果它出现回归，该用例会在部署前失败。
这正是这个循环要么学习、要么不学习的地方。按任务类别跟踪升级率。随时间推移保持平稳的比率表明循环没有在学习：同样的类别不断到达人类那里，而修正没有改变 agent 的行为。某个类别的比率下降且质量稳定，表明修正正在被吸收。比率上升则表明该任务类别正在漂移，或者 agent 的范围扩大了，而其策略却没有相应更新。
同一任务类别上的反复升级是规格缺陷，而不是操作员的问题。如果操作员不断修正同样的歧义，那么 agent 的指令、工具或 g
诚实的权衡
升级契约在节省任何时间之前，先要花费工程时间。触发器、载荷和返回都必须被设计、埋点和维护。载荷尤其昂贵：组装目标、计划、候选动作和证据，要求 agent 暴露许多框架保持隐式的内部状态。跳过这项工作的团队会得到一个能用的演示和一个脆弱的生产系统。
第二个权衡是，严格的契约会减少操作员的自由。一个能看到整个系统的操作员往往能以契约未预料到的方式修复问题。将他们限制为批准、修正或中止，可能显得不自然。这种限制是刻意的：不受约束的修正不会产生持久产物，而没有产物，循环就无法学习。契约以操作员的短期灵活性换取系统的长期改进。
第三个权衡是延迟。升级在关键路径上增加了一次人类往返。契约并不会消除这种延迟；它使延迟变得可问责。一次产生回归测试的升级是一项投资。一次只产生一次点击的升级是一项成本。区别就在于返回路径是否被定义。
需要埋点什么
升级契约的最小埋点集合：
- 按任务类别的升级率，带滚动窗口。
- 每次升级的决策耗时，按触发器类型细分。
- 修正率与批准率的对比，按操作员和任务类别细分。
- 从修正中提升的回归测试，及其随时间推移的通过率。
- 复发率：在已被提升测试覆盖的任务类别上发生的升级。
复发率是最敏锐的信号。如果某个类别已有提升的回归测试却仍然升级，那么要么是该测试没有捕捉到失败，要么是 agent 没有使用该修正。两者都是工程问题，都有工程上的解决办法。
结论
人工客服不是一项可供营销的功能。它是一条回退路径，必须像任何其他接口一样被工程化：有明确的触发器、完整的载荷，以及产生持久产物的返回。没有这份契约，升级就变成一种延迟税，监督就变成橡皮图章式审批。有了它，每一次人类干预都是 eval 套件的一个候选，循环才有机会学习。衡量一条好的升级路径的标准，不是它被使用的频率，而是同一类失败需要它两次的频率。
封面照片：Nic Wood / Pexels。