智能体规范差距：为什么你的智能体忽略你写的内容

你写了一份详尽的规范。你描述了任务，列出了约束条件，并给出了示例。Agent 运行了——但做了一些与你预期完全不同的事情。

这就是规范差距 (specification gap)：你写的指令与 Agent 理解的任务之间的距离。这不是模型能力的问题，而是规范的问题。2025 年发布的关于多 Agent 系统失败的研究发现，与规范相关的议题占所有失败的 41.77%，而 79% 的生产环境故障可以追溯到任务是如何规范化的，而不是模型能做什么。

大多数编写 Agent 规范的团队都在犯同一类错误：像给一个称职的同事写邮件一样写指令，然后期望一个没有任何共享上下文的自主系统在数千次运行中正确执行这些指令。

为什么“清晰”的指令在实践中会失败

当工程师编写 Agent 规范时，他们是为那个已经知道他们意思的读者版本编写的。规范说“清理数据库条目”，作者脑子里有一个具体的画面：归档超过 90 天的软删除行，跳过任何标记为待处理的内容，保持其他内容不动。Agent 读到同样的四个字，却完全没有那个画面。

自然语言在设计上就是描述不足的。人类交流之所以有效，是因为我们携带了大量的隐式共享上下文——领域知识、机构记忆、对话规范。除非你在规范中明确说明，否则 Agent 不具备这些上下文。最近对前沿模型在 Agent 指令遵循方面的基准测试发现，即使是性能最好的模型，在需要将字面指令与上下文推理结合的任务中，成功率也仅为 48.3%。另一半任务失败并不是因为模型无法执行机械操作，而是因为规范留下了太多未说明的内容。

这种失败在多步工作流中会产生复合效应。一个每步准确率为 85% 的 Agent 在运行 10 步工作流时，正确完成的概率仅为 20%。如果每一步都有描述不足的前置条件或模糊的成功标准，错误不仅会累积，还会产生级联反应。第 3 步误解了第 2 步产出的结果。第 6 步在陈旧的状态下执行。第 9 步定义的“完成”与规范预期的不同。

破坏规范的三种反模式

大多数规范失败可以分为三类，理解它们是修复它们的前提。

描述不足的前置条件 (Underspecified preconditions)。规范描述了 Agent 应该做什么，但没有说明在开始之前必须满足什么条件。指令“更新用户偏好”并没有告诉 Agent 用户记录是否必须先存在，如果不存在是否应该创建记录，或者如果偏好模式 (schema) 发生了变化该怎么办。在测试环境中执行此操作的 Agent 可能会成功，因为记录总是存在的。同样的 Agent 在生产环境中遇到一个新用户，要么报错，要么创建一个损坏的记录，或者默默跳过操作——这些行为一直都是可能的，但从未被规范化。

模糊的成功标准 (Ambiguous success criteria)。规范没有定义“完成”是什么样的。“分析文档并提取关键洞察”听起来像是一个完整的指令。其实不然。什么算作关键洞察？应该有多少个？它们应该采用什么格式？如果文档太短无法产生有意义的洞察，或者文档语言是 Agent 处理不佳的语言，Agent 应该怎么办？如果没有明确的成功条件，Agent 就会发明自己的标准——并且它的定义会在不同的输入中以不可预测的方式与你的定义发生分歧。

隐式的世界状态假设 (Implicit world-state assumptions)。编写规范时假设环境是某种特定样式的：特定服务可用、特定模式已就绪、之前的步骤已成功完成。Agent 看不到这些假设；它只能根据其上下文窗口中的内容采取行动。关于所谓的“隐性智能” (implicit intelligence) —— 即用户表达的内容与真实意图之间的差距 —— 的研究发现，环境因素（外部系统的状态、权限、资源可用性）几乎从未在 Agent 规范中明确说明，然而它们决定了 Agent 的行为是否正确。

最糟糕的规范包含了这三者。“删除过时条目”具有描述不足的前置条件（哪个数据库？哪个表？）、模糊的成功标准（什么使条目过时？）以及隐式假设（这些条目可以安全删除且未被其他地方引用）。一个 Agent 成功删除了所有早于它从上下文中推断出的日期的条目，从技术上讲是在执行规范的要求。随之而来的生产事故是完全可以预见的。

结构化修复：将规范视为行为契约

使规范变得可靠的思维转变是将其视为软件契约 (software contracts) 而不是任务描述。任务描述告诉 Agent 你想要什么。行为契约告诉 Agent 在开始之前必须满足什么条件，结束时必须满足什么条件，以及在此期间不能违反哪些不变式 —— 无论它使用哪些具体操作来达成目标。

这并不是一个新想法。契约式设计 (Design-by-Contract, DbC) 自 20 世纪 80 年代以来一直是软件工程的一个原则。它只是还没有被系统地应用于 Agent 规范，尽管 Agent 正是那种契约执行最为关键的自主组件。

结构化为行为契约的规范有四个要素：

前置条件 (Preconditions) —— 明确说明 Agent 执行前必须为真的陈述。不是“数据库应该是可用的”，而是“users 表必须存在并包含与提供的 ID 匹配的记录。如果记录不存在，则终止并返回错误代码 USER_NOT_FOUND”。前置条件为 Agent 提供了在采取任何行动之前的明确停机条件，这防止了 Agent 在错误的假设下继续执行的那类失败。

后置条件 (Postconditions) —— 明确说明任务完成时必须为真的陈述。不是“报告应该生成”，而是“输出必须是一个符合 ReportSchema 的 JSON 对象，status 字段设置为 complete，且在 findings 中至少包含一个条目”。后置条件为 Agent 提供了一个可测试的成功定义。如果没有它们，Agent 就必须发明自己的退出条件 —— 而且它一定会这么做。

不变式 (Invariants) —— 在整个执行过程中必须保持为真的约束，无论中间步骤如何。“不要删除标记为 protected: true 的记录。”“不要向不在批准列表中的外部服务发起 API 调用。”“不要修改当前任务范围之外的记录。”不变式编码了规范作者持有但从未写下的“显然你不会那样做”的知识。

世界状态上下文 (World-state context) —— 关于 Agent 运行环境的明确陈述。适用哪个版本的数据库模式？Agent 拥有什么权限？是否有其他进程可能同时修改相同的资源？世界状态上下文是最难写的部分，因为它要求规范作者将隐性知识显性化 —— 但这也是大多数生产失败的源头。

构建可靠执行的规范结构

除了合约要素之外，规范的物理结构也会影响智能体遵循它的可靠程度。对大语言模型指令遵循能力的调研显示，随着指令复杂度的增加，合规性会出现非线性退化。那些能可靠遵循 5 个约束的模型，在约束数量达到 15 个时，就开始漏掉某些约束。在你的测试提示词中运行良好的规范——干净、聚焦——随着你不断添加边缘情况，性能会随之下降。

加载中…