面向谁

已有可用原型、但不敢接入正式流程的技术团队; 以及需要把某个高频判断环节自动化、且该环节出错代价明显的业务方。

解决什么问题

原型与生产之间的差距很少是模型能力造成的, 而是这四件事没做:

• 成败无法判定。没有评测集, 每次改动是变好还是变坏只能靠感觉。
• 失败无法归因。整个任务在一次调用里完成, 出错时不知道是输入、推理还是输出的问题。
• 边界未定义。没写明禁止什么, 于是模型在没预料到的情况下自行发挥。
• 缺失被悄悄补全。信息不全时给出一个合理的填充, 而合理与真实在文本上无法区分。

我们怎么做

按 Agent 设计方法 的五步推进, 每一步都产出可检查的契约:

1. 目标——写成可判定的形式, 并列出非目标。
2. 角色——权限清单与拒绝清单, 没写允许即为禁止。
3. 输入——输入契约, 明确规定缺失时的行为 (报错 / 询问 / 降级), 禁止推断补全。
4. 推理——拆成有留痕的多步, 使任一输出可还原到依据。
5. 输出——结构化的成功与失败两种形态, 下游可用程序判定。

同时建立评测集: 没有它, 上述契约写得再全也无法知道改动的方向。我们自己实现、自己部署——一个没有被实现过的设计不该被交付。

交付什么

• Agent 契约文档: 目标 / 角色 / 输入 / 推理 / 输出 五份
• 可运行的实现, 部署在客户环境中
• 评测集与基线成绩, 含典型失败样例
• 可观测接口: 每次运行的输入、中间判断、输出可被检索
• 交接说明: 如何新增评测用例、如何判断一次改动是否可以上线

什么情况下不适合

★ 以下情况不适合:

• 还没想清楚要它做什么。 探索阶段用对话摸索更快, 过早写契约会把没想清的东西固定下来。
• 一次性任务。 契约与评测的成本只有靠复用才能摊平。
• 成败取决于对具体处境的理解。 这类环节应当设计人机协作流程, 而不是 Agent。
• 不接受多步留痕带来的延迟与成本。 可归因不是免费的, 与单步调用有数倍差距; 不能接受这个代价时, 就不该把它放进关键流程。