这个方法要解决什么

多数 Agent 在演示里工作良好, 在生产里不可靠。原因通常不是模型选错了, 而是这个 Agent 从来没有被当作系统组件来设计: 它没有明确的成败判据, 没有权限边界, 没有输入契约, 推理过程不可追溯, 失败时的行为未定义。

本方法用五个步骤把这些补齐。它的目标不是让 Agent 更聪明, 而是让它可评测、可归因、可被信任地嵌入流程。

目标

做什么。 写下要达成什么, 同样重要的是写下不达成什么。

产出。 一句可判定的目标陈述, 加一份非目标清单。

完成判据。 拿一次真实运行的记录, 能据此判定成功或失败。判定不了, 目标就还没写完。

特征性失败: 把能力当目标。 "帮助用户分析数据"是能力描述, 不是目标——它永远不会失败, 因此也永远无法改进。可判定的写法是: "给定一份销售明细, 输出环比异常的品类清单, 每条附异常幅度与判定依据; 若数据不足以判定则明确说明缺什么。"

角色

做什么。 界定职责边界与权限: 能调用哪些工具、能改动哪些数据、遇到边界外的请求怎么办。

产出。 一份权限清单与一份拒绝清单。

完成判据。 每一项外部动作都被明确允许或明确禁止, 没有留白。

特征性失败: 权限默认开放。 只写了"可以做什么", 没写"不可以做什么", 于是所有没想到的情况都落在允许区。★ 越是能力强的模型, 越会主动做超出预期的事——它会认为那是在帮你。

输入

做什么。 规定它需要什么信息、从哪里获得、缺失时如何处置。

产出。 输入契约: 必填项、可选项、每个必填项缺失时的行为。

完成判据。 对每个必填项都定义了缺失时的动作 (报错 / 询问 / 降级)。

特征性失败: 默许补全。 这是本方法最强调的一条。模型遇到信息缺口时倾向于填上一个合理值, 而合理的填充与真实的信息在文本上不可区分。下游看到的是一个完整、自洽、部分虚构的输入。对策是在契约里显式要求: 缺失即标注缺失, 不得推断。

推理

做什么。 确定从输入到输出的路径: 分几步、每步依据什么、哪些中间结果需要留痕。

产出。 一个可复核的推理结构, 而不是一段祈使句。

完成判据。 任取一次输出, 能还原到它所依据的输入片段与中间判断。

特征性失败: 单步黑箱。 把整个任务塞进一次调用, 输出正确时无从知道为什么对, 错误时无从知道哪里错。拆成有留痕的多步会更慢也更贵, 换来的是可归因——这是能否把 Agent 放进关键流程的前提。

输出

做什么。 规定产出的结构、置信的表达方式, 以及失败时的形态。

产出。 输出契约, 含正常结构与失败结构。

完成判据。 下游能用程序判断"这次结果是否可用", 而不需要人读一遍。

特征性失败: 只定义成功路径。 失败时返回一段自然语言道歉, 下游只能靠关键词猜测出了什么事。正确做法是让失败也结构化: 失败类型、缺什么、建议的下一步。

什么时候适用

• Agent 的输出会进入后续自动流程, 而非直接给人看
• 同一任务高频重复, 因此值得为可评测性付出设计成本
• 错误的代价不对称, 需要能归因

什么时候不适用

• 探索阶段。还没想清楚要它做什么时, 先用对话摸索比先写契约快得多。
• 一次性任务。契约的价值来自复用。
• 本质上需要人判断的环节。如果成败取决于对处境的理解, 那么该设计的是人机协作流程, 不是 Agent。

代价

1. 契约的编写与维护成本, 通常与实现本身相当。
2. 多步留痕带来的延迟与费用, 相对单步调用有数倍差距。
3. 需要评测集。没有评测集, 五步都写了也无法知道改动是变好还是变坏——而评测集的构建往往比 Agent 本身更费时。