AI Agent 的可靠性陷阱：为什么 Demo 惊艳，上线就崩？

你见过那种让人倒吸一口凉气的 agent 演示吗——自主编码、跨工具协作、几小时不用管。演示结束，全场鼓掌。然后问一句："能用到生产吗？"全场沉默。

这不是个别现象。2025 年到 2026 年，AI Agent 领域正在经历一场集体幻灭：Demo 效果和生产线效果之间，隔着一道大多数团队还没意识到的鸿沟。

问题不在模型不够强。

一场关于"谁该负责"的认知错位

先问一个看似简单的问题：当一个 AI Agent 给你返回一个错误结果时，是谁的错？

大多数人第一反应是模型不行。Claude 3.7 不够聪明，GPT-4o 推理能力有限，DeepSeek 泛化性差。下一代模型出来就好了。

这个判断在 2024 年之前还算成立。现在，越来越站不住脚了。

Anthropic 去年底发了一篇重磅文章《Demystifying evals for AI agents》，里面有一个反直觉但极其重要的论断：当你评估一个 Agent 的效果时，你评估的不是模型本身，而是 model + harness 的组合。

Harness，这个词翻译过来是"挽具"——骑马时套在马身上的那套控制系统。它不是模型的一部分，但它决定了模型的力量能不能被正确地传导到目标上。

这个区分，才是理解当下 Agent 失败模式的钥匙。

Demo 为什么看起来那么美

让我们拆解一下一个惊艳 Demo 的诞生过程：

工程师精挑细选一个最适合模型能力的任务。任务足够独立，边界足够清晰，验证足够简单。给模型喂饱了上下文——项目的完整背景、代码结构、依赖关系，全部塞进去。靠人盯着，随时介入纠正偏差。任务中途遇到困难？手动重启，换个方式。

换句话说，Demo 的成功，靠的是一个人肉 harness 在背后撑着。

生产线上的 Agent 呢？没有人在旁边盯着。任务可能横跨几天。上下文窗口不够用，模型中途失忆。工具返回了错误，模型假装没看见。做到了 70% 宣布"已完成"然后停下来。

这不是模型变弱了，而是环境变真实了。真实环境里没有人在 loop 里给它兜底。

Agent 的五个结构性脆弱点

从 2025 年到现在的行业观察，Agent 在生产环境中暴露出的问题，有五个是结构性的——不是靠调参能解决的。

第一，上下文续航问题。

Context window 再长，也是有限的。一个需要工作三天的开发任务，模型在第二天中午就会"失忆"——它不再记得第一天做了什么决定、为什么选了这条路、哪些设计决策是被明确拒绝过的。

这不是压缩上下文能解决的。摘要压缩会丢失细节，更糟糕的是，压缩后的上下文会让模型产生虚假的自信——它以为自己看过了全貌，实际上关键决策链条已经被抹掉了。

真正的解法是把状态外化：每一步决策写入文件，每个里程碑记入结构化日志，模型下次启动时从这些持久化工件里恢复，而不是从压缩后的对话历史里猜。

第二，行动可验证性问题。

你让 Agent 写了一段代码，怎么知道写得对？

最常见的做法：让模型自己检查自己。Anthropic 的工程师在实践中发现了一个令人尴尬的事实——当被要求评价自己的作品时，Agent 的自我评分系统性地偏高，即使在人类看来质量明显平庸。

这是模型的结构性缺陷，不是 bug。你永远不能把验证工作完全交给执行者自己。

正确的做法是：验证门必须独立于生成器运行。代码写完了，测试必须跑。不是让模型说"我觉得写对了"，而是让测试套件说"这个用例通过了"。

第三，目标漂移问题。

长任务做到一半，Agent 突然宣布"已完成"。你一看，还差 60%。

这不是模型在撒谎——至少不是有意的。模型对"完成"的理解，是在给定上下文里最合理的估计。但当上下文在变化、目标在中途被部分满足时，模型会误以为整个任务都完成了。

解法是把"完成"外部化。不是模型自己判断完成了没有，而是有一份结构化的检查清单，模型每完成一项就标记一项。完成不完成，看清单，不看感觉。

第四，熵增累积问题。

Agent 持续工作几天之后，代码库里会出现奇怪的模式：过时的文档描述着不存在的功能，测试用例验证的是早已改变的行为，函数命名和实际逻辑完全对不上。

这不是某一次失误造成的，而是无数次微小漂移累积的结果。Agent 倾向于沿用现有的代码模式，哪怕这些模式本身是有问题的。更糟糕的是，Agent 还会把这种低质量模式复制扩散。

抑制熵增需要主动的"垃圾回收"机制：定期的文档一致性检查、结构化的技术债清理、CI 层面的架构边界强制执行。

第五，人机边界模糊问题。

Agent 在什么情况下应该自主行动，在什么情况下应该停下来等人确认？

大多数团队的答案是"看情况"——然后在实际运行时发现，这个"看情况"变成了"要么过度自主、要么过度依赖人"两个极端。

工程化的人机边界需要提前定义清楚：涉及外部 API 写操作需要确认，涉及费用支出需要确认，涉及不可逆操作需要确认。把这些规则写进 harness，而不是放在 system prompt 里等模型自己推断。

为什么框架解决不了这个问题

很多团队遇到 Agent 可靠性问题，第一反应是换一个框架。LangChain 不好用换 CrewAI，CrewAI 太薄换 AutoGen。

结果呢？框架换来换去，问题还是那些问题。

原因很简单：框架解决的是编排问题，不是治理问题。

编排是让 Agent 能跑起来——怎么串起工具，怎么管理对话历史，怎么做多步推理。治理是让 Agent 跑得对——怎么验证输出，怎么控制漂移，怎么在出错时有序回退。

目前市面上几乎所有框架都把精力放在前者，因为编排是可见的、有噱头的、可以拿来写 Demo 的。治理是枯燥的、需要工程定力的、短期看不到效果的。

所以大多数团队的 Agent 系统实际上是：用一个花哨的编排框架，套一个人肉 harness 在背后当救火队员。

同一模型，截然不同的表现

最能说明问题的证据来自数字。

LangChain 去年发过一个数据：他们在保持底层模型不变的情况下，仅通过修改 harness 配置，让同一个模型在 Terminal Bench 2.0 上从 52.8% 提升到 66.5%——增加了 13.7 分，排名从 Top 30 边缘拉到 Top 5。

这个数字不能被解读为"模型不重要了"。但它足够说明：在模型能力边界内，harness 的质量可以直接决定一个产品在实际场景中的可用还是不可用。

现在想象一下，有多少团队在用着最前沿的模型，却用着一套临时拼凑的 harness，然后抱怨"AI 怎么还是不行"。

从 In the Loop 到 On the Loop

工程师在 Agent 时代有一个核心能力升级：从不满意 Agent 输出时手改产物，进化到修改 harness，让系统下次自动产出更好的结果。

第一个层次是 in the loop——人在循环里，发现错误，手动修复。这一层次在学习和调试阶段是必要的，但不能永远停留在这里。

第二个层次是 on the loop——人在回路之外，但通过修改控制回路本身来提升系统表现。发现验证总漏报？改 harness 的 evaluator 逻辑。发现目标漂移频繁？加强 harness 的检查清单机制。

从 in the loop 到 on the loop，本质上是从"解决具体问题"到"解决产生问题的系统结构"。这个转变的难度被严重低估了。

三个自检问题

在抱怨模型之前，先问自己三个问题：

你的 Agent 有没有持久化的状态工件？它下次启动时，是从结构化日志里恢复上下文，还是从一段压缩过的对话历史里瞎猜？

你的系统有没有机器可读的验收标准？"完成"的定义是一个 Feature List 上打勾，还是模型自己感觉"差不多了"？

你的代码库、工具定义、日志和指标，对 Agent 来说是可读可执行的吗？还是只有人类能看懂，Agent 只能靠猜？

如果这三个问题都没有笃定的答案，你拥有的可能不是一个 AI Agent 系统，而是一个会跑命令的聊天机器人。

模型会越来越强，然后呢

有一个流行的论调：等下一代模型出来，现在这些 harness 问题就都不重要了。

这个判断低估了一件事：模型能力的边界在往外推，但被 harness 管理的任务复杂度也在同步增长。

今天 Agent 能自主完成两小时的任务，模型变强后，你会把它用在两天甚至两周的任务上。任务规模扩大后，harness 的必要性不会降低，只会更突出。

Anthropic 自己的判断是：harness 的价值会随着模型能力的外扩而重新分配，而不是消失。某些简单检查会变得冗余，但对更难任务的规划、验证、交接和状态治理，会变得更关键。

模型越强，把更长、更贵、更危险的任务放进受控外循环的需求就越强烈。

写在最后

2026 年，AI Agent 领域的竞争正在悄悄换战场。

从"谁的模型更强"到"谁的 harness 更合理"。模型能力的差距在缩小，但 harness 设计的差距才刚刚拉开。

对于正在搭建 Agent 系统的团队，这是一个好消息：harness 的优化不需要等待下一代模型，不需要等 OpenAI 发新版，今天就可以开始。从状态外化开始，从独立的验证门开始，从定义清楚的人机边界开始。

Demo 的掌声很响，但只有生产线上的稳定输出，才是真正的壁垒。