LangChain 揭示：Agent 效果不佳时换模型是误区，换 Harness 才是关键

一次没有帮助的模型换装

我写了一个编码 Agent，在小型任务上表现尚可，在长任务上表现平平。我的第一反应和所有人一样：换模型。换一个更强的模型，或者从更便宜的换成更贵的。几天后，Agent 的表现和之前差不多。也许好了一点点，但远不是我为更多 token 付费所期待的那种飞跃。

我完全没有动的东西，是模型周围的一切：调用模型的循环、工具结果如何反馈回去、当一个工具返回 40KB 垃圾时发生了什么、进行到第 30 轮时上下文开始滑动后又发生了什么。所有这些代码，都是我一个周末写出来的。

然后，LangChain 的 "Anatomy of an Agent Harness" 文章上线了，文中有一个说法，恰好戳中了我一直在忽视的问题。

重新定义问题的那句话

LangChain 的表述很简短：

Agent = Model + Harness。模型包含智能，Harness 让智能变得有用。

这句话附带的数据让我停止了滑动。Terminal-Bench 2.0 上，他们只重建了 harness——同样的模型，没有触碰任何权重——从 52.8% 跃升到 66.5%。这是从 30 名开外跃升到第 5 名。不是因为更大的模型，而是因为同一个模型套上了更好的 harness。

如果用卧推图表的方式来写，这个差距相当刺眼。我花了一周做模型选择，却没有在 harness 上花一天。

LangChain 所说的 "the harness" 是什么意思

第一次听到这个词时可能会觉得模糊。LangChain 将其拆解成了具体的部分，大致如下：

循环——模型、工具和观察结果如何逐轮串联、何时停止，由谁决定。

工具——Agent 实际能调用的有哪些、它们的 schema、结果如何返回。

上下文管理——哪些内容跨轮次保留、哪些被压缩、哪些被丢弃。

状态与记忆——跨轮次或跨会话持久化的任何东西。

恢复与护栏——工具超时时怎么办、模型输出了畸形 JSON 怎么办、模型跑偏了怎么办。

如果你不是模型，那你就是 harness。这是思维方式的转换。模型是六个组件中的一个，而且可能是你唯一改不了的；其他五个都是你的。

为什么换模型没有效果

重新读一遍这个列表，我自己那个 Agent 的答案就很明显了。在 Agent 失败的那些运行中，模型从来都不是瓶颈。出问题的地方在这个清单的其他地方。

我真正失败的三件事，逐一审视后如下：

1. 循环没有验证步骤。Agent 产生输出，我的循环就相信它。如果工具返回了错误，我把错误文本反馈回去，指望下一轮能修复它。没有任何"这真的成功了吗"的检查。在短任务上这没问题，因为你用眼睛就能发现。但在长任务上，错误会累积。第 4 轮的一个坏输出会毒害第 12 轮的计划。

2. 工具结果把上下文淹没了。我的一个工具返回了完整的 HTTP 响应，50KB，每次都是。模型花了越来越多的上下文空间反复重读它已经知道的响应头。到第 20 轮时，真正的任务几乎没有空间了。我没有设置任何工具输出的预算——没有截断、没有摘要、没有单独的草稿区。上下文在自我消耗。

3. 没有恢复机制。当工具超时时，整个运行就死了。没有带退避的重试、没有备用工具、没有"记录这个然后继续"。一个不稳定的端点就能在第 4 分钟结束一个 30 分钟的运行。模型不是脆弱的部分，我的 harness 才是。

同样的模型、同样的任务形态。运行失败的原因与智能无关，而是与我一直当作一个组件来看待的那个六组件清单有关。

"加上一个 harness" 与两个同类框架的对比

harness 这种表述方式有用的原因在于，它能干净地映射到人们实际使用的三大框架。名字不同，框子类似，默认值不同。

这里没有唯一的正确答案。关键不是"LangGraph 赢了"。关键是你如果完全跳过 harness、自己写一个周末循环，你不会继承任何框架的默认值。你得到的是原型开发时"不小心发生"的一切。那就是我的状态。这是反模式。

2026 年的独立比较显示，复杂任务完成率 LangGraph 约 62%，AutoGen 约 58%，CrewAI 约 54%，并且值得注意的是，在简单任务上的差距几乎为零——四种框架都在 79%–88% 区间内。这与 model-vs-harness 的论点完美吻合。任务短时，harness 几乎无关紧要。任务越长，harness 的声音越大。

测量问题

LangChain 不只是说"harness 很关键"。他们给出了一个数字：52.8 → 66.5，同一个模型。这是我一直回味的文章部分。如果你无法测量 harness，你就无法论证去改进它。Harness 工作的默认失败模式是：它在老板眼里看起来像管道工程。

有些值得统计的东西，按成本从低到高排列：

任务成功率——以你期望的形态结束的运行数，除以总运行数。无聊，但很难作弊。

返工率——人类需要在交付前介入修复输出的运行次数。如果这个比率高而成功率高，那你的指标在骗你。

每个已完成任务的 token 数——不是每轮 token 数，是每个已完成任务。这惩罚的是那些靠跑 40 轮才勉强成功的运行。

一次通过率——输出在第一次尝试就通过测试、lint 和 schema 检查的频率，没有重试循环。

这些是换了名词的 RAG 指标。检索评估早在几年前就弄清了这个形态——精确率、召回率、每次查询成本——harness 评估就是在更大表面上的同类思路。如果你已经信任 RAG 仪表盘来指导搜索管道，你也可以信任同类仪表盘来指导 Agent 循环。

我实际做了哪些改动

不是重写。三个按杠杆效应排序的小改动：

在循环中加入了一个验证步骤。在 Agent 宣布完成之前，运行一个独立的检查——测试、schema、"文件是否真的被写入了"这个问题。如果失败，循环将失败信息连同具体原因一起反馈回去。仅此一条就消灭了"Agent 说成功了但实际没有"这类 bug。

给每个工具结果加了一个带 token 预算的摘要器。完整响应进入一个 Agent 可以 grep 的草稿文件；只有一段短摘要进入模型的上下文。上下文在第 15 轮左右就不再溺水的。

给每个外部工具包上了一层轻量的重试 + 备用。超时后一次带 jitter 的重试，然后一个优雅的"跳过，原因是"的记录，Agent 可以看到并绕过去。

以上都没有动模型。没有换提供商，没有调 prompt。长任务上的成功率提升比之前换模型那次大得多。不是 52.8 → 66.5 那种数字，因为我并没有搭起 Terminal-Bench，但形态是一样的：同样的模型，更好的 harness，更好的输出。

如果你的 Agent 感觉很弱，模型是最容易甩锅的，也是最难真正成为原因的那个。在换模型之前，检查一下你周围那五样东西——那些你大概花了一个周末写的东西。13 个百分点的跃升就在那里。

如果你想要完整的思维模型——五个组件如何组合、如何对它们插桩、如何向想听模型升级的老板论证 harness 工作——我在 Harness Engineering: The Real Layer Where Your Agent Wins or Loses 里写了完整版。