代理合约问题：当你的代理承诺了它无法交付的东西
Source: Dev.to
代理合同问题：当你的代理承诺了它无法交付的事
每个自主代理最终都会做出一个它无法兑现的承诺。这并非出于恶意，而是因为代理在同意时的理解与实际执行时任务的需求之间存在差距。这就是 agent contract problem，它是代理可靠性的隐形杀手。
协议差距
当你将任务委派给代理时，你实际上是在达成一个隐含的合同。代理会说“我会处理”，往往比实际应有的信心更高。代理会处理你的请求，评估自己完成任务的能力，并在对实际涉及的内容没有完全了解的情况下就承诺执行该任务。
这并非 AI 所独有。人类承包商也面临同样的问题。一个为了赢得工作而出低价的承包商，随后在项目进行中发现材料成本超出预期，其失败模式与一个承诺了自己无法恰当执行的任务的代理是相同的。
关键的区别在于，人类拥有重新协商合同的社会机制。我们可以说“这比我想的更复杂，我需要更多时间或资源”。而代理通常没有这种灵活性。承诺一旦做出，代理就会继续推进，导致质量下降。
三种失败模式
范围蔓延崩溃
代理接受了一个隐含范围与现实不符的任务。看似“清理数据库”的工作却演变成涉及十七个相互依赖系统的迁移。代理继续工作，但现在它在为原始目标的影子进行优化。
能力错位
代理真诚地认为自己能够处理该任务。它拥有工具和上下文，但具体的需求组合超出了其当前能力的实际覆盖范围。它产生的输出看似成功，却未满足真实需求。
资源耗尽
代理承诺执行一个需要比其可获取的上下文、计算或时间更多的任务。它没有明显失败，而是生成了截断的输出。代理认为任务已完成，操作员认为任务未完成，且没有人注意到交接问题。
为什么标准验证会失败
大多数运营者会添加验证层来捕捉合约失效：让代理检查自己的工作、加入人工审查、构建输出验证器。这有帮助，但仍不足。
验证能捕捉实现层面的错误，却抓不住合约层面的错误。如果你的代理承诺了错误的内容，即使验证它正确地完成了错误的事情，也帮不上忙。
真正的解决方案是 在执行前确保合约清晰。在代理正式执行之前：
- 明确陈述接受标准 — 不是“清理数据库”，而是“删除所有电子邮件相同的重复用户记录，保留
created_at时间戳最新的那条，并生成一份被删除记录的日志”。 - 要求代理口头复述其承诺 — 让它用自己的话重新表述任务。重新表述的过程常常会暴露隐藏的假设。
- 设定明确的中止条件 — 在什么情况下代理应当停止并重新咨询而不是继续执行。“如果你发现任务涉及超过 X 个不同的操作，请暂停并报告”。
静默合同失效的代价
合同失效之所以代价高昂，正是因为它们看起来像是成功。代理在工作，进展在进行，运营者检查进度，看到活动，便认为一切都在正轨上。代理完成了任务——但却是错误的任务——而失效只有在下游有人尝试使用输出时才会显现。
这就是为什么自主代理需要明确的合同协议，不仅用于多代理交接，也用于每一次人‑代理交互。合同是“我理解了你的需求”与“我按你的要求执行”之间的界限。
运营者最信任的代理并不是功能最强大的那些，而是合同最清晰的那些——任务边界明确、终止条件已定义，且代理清楚自己可以假设什么、必须验证什么。
为合同清晰度而构建。 你将在上游捕获更多失效，而不是依赖任何下游的验证层来捕获。