同一个模型，换个Harness排名跳了25位：智能体基础设施完全解剖

同一个模型，换个Harness，排名能跳25位——这不是空话，是TerminalBench 2.0上实打实的数据。

LangChain团队就干了这么一件事：模型没动，权重没动，单纯换了模型外面的基础设施，结果排名从30名开外直接冲到第5。另一个独立项目更激进，让大模型自己来优化这层基础设施，结果通过率达到了76.4%，超过了所有人类手工设计的方案。

模型没变。变的是外面那层东西。

Akshay Pachaar最近发了篇很扎实的文章，把Anthropic、OpenAI、LangChain、CrewAI这些头部玩家正在构建的智能体基础设施，做了一次完整的解剖。这层基础设施有了一个正式的名字：Agent Harness（智能体线束）。

一句话概括：你的智能体表现差，大概率不是模型问题，是Harness问题。你搭了个Chatbot，接了几个工具，跑通了Demo，然后试着做一个生产级产品——结果模型忘了三步前做过什么，工具调用悄无声息地失败，上下文窗口里塞满了垃圾。这不是模型笨，是包裹模型的那层基础设施没到位。

01 什么是Harness

这个概念在2026年初被正式命名，但思路早就有了。Harness指的是包裹在大模型外部的全部软件基础设施：编排循环、工具调用、记忆系统、上下文管理、状态持久化、错误处理、安全护栏。Anthropic在Claude Code的文档里直截了当地说，他们的SDK就是“驱动Claude Code的Agent Harness”。OpenAI的Codex团队，用的也是同样的说法。

这个定义很重要，因为它意味着Harness不是一层薄的封装，而是一个完整的软件系统——有可能比你的业务逻辑还复杂。LangChain的Vivek Trivedy有句话我特别认可：

如果你不是模型，你就是Harness。

这里需要区分一个容易混淆的概念。“智能体”是一种涌现行为——有目标、会用工具、能自我纠正的那个你看到的东西。而Harness，是产生这种行为的机器。当有人说“我做了一个智能体”时，他实际做的是搭了一个Harness，然后把它指向一个模型。

Beren Millidge在2023年的论文里用了很精妙的类比：裸模型就是一颗没有操作系统的CPU——没有RAM、没有硬盘、没有I/O。上下文窗口是内存（快但小），外部数据库是磁盘（大但慢），工具集成是设备驱动，而Harness就是操作系统。他的原话是：“我们重新发明了冯·诺依曼架构。”

02 三层工程

围绕模型的工程有三个同心层次：

——设计模型接收到的指令。
——管理模型看到什么，以及什么时候看到。
——包含前两者，再加上整个应用基础设施：工具编排、状态持久化、错误恢复、验证循环、安全执行、生命周期管理。

很多人把“做智能体”等同于“写好提示词”，这就像把“做操作系统”等同于“写好启动脚本”——只碰到了冰山一角。

03 十二个组件

综合Anthropic、OpenAI、LangChain和社区开发者的实践，一个生产级的Harness有12个独立组件。我们挑几个最关键的展开看。

是心跳。它执行Thought-Action-Observation循环（也叫ReAct循环）：组装提示 → 调用模型 → 解析输出 → 执行工具调用 → 把结果喂回去 → 重复直到完成。从机械层面看，就是一个while循环。Anthropic自己都说，他们的运行时就是一个“傻循环”——所有智能都在模型里，Harness只管理轮次。

但这个“傻循环”管理的东西一点都不傻。简单问题可能只要1-2个循环，一次复杂的代码重构可能链式调用几十次工具，横跨多个循环。循环的终止条件是分层的：模型产生了不含工具调用的响应、达到最大轮数上限、Token预算耗尽、安全护栏触发、用户中断、或模型返回安全拒绝。每一层都是一道防线。

对于跨越多个上下文窗口的长任务，Anthropic开发了一种“Ralph循环”模式：一个初始化智能体搭建环境（初始化脚本、进度文件、功能列表、初始Git提交），然后后续每个会话的编码智能体读取Git日志和进度文件来定位自己，选择最高优先级的未完成功能，完成后提交并写摘要。文件系统提供了跨上下文窗口的连续性。

是智能体的手。工具以Schema（名称、描述、参数类型）的形式注入上下文。Claude Code提供了六类工具：文件操作、搜索、执行、网络访问、代码分析、子智能体生成。OpenAI的SDK支持函数工具（@function_tool）、托管工具（WebSearch、CodeInterpreter）和MCP服务器工具。

04 记忆系统

记忆在多个时间尺度上运作。

是单次会话内的对话历史。跨会话持久化。各家实现不同：

Anthropic用CLAUDE.md项目文件和自动生成的MEMORY.md文件。LangGraph用命名空间组织的JSON存储。OpenAI支持基于SQLite或Redis的Sessions。

Claude Code的记忆系统尤其值得一说。它实现了三层层级结构：一个轻量级索引（每条约150字符，永远加载）、按需拉取的详细主题文件、以及只通过搜索访问的原始对话记录。关键设计原则是：智能体把自己的记忆当成“提示”，

，不盲信自己记住的东西。

这让我想到一个现实中的类比：人类工程师调试问题的时候，也不会完全依赖记忆——他们会打开之前的笔记、翻Git Log、看看上次怎么处理的。好的智能体也应该这样。“我记得这件事”和“让我确认一下这件事”之间，差的是可靠性。

05 上下文管理

这是很多智能体悄无声息失败的地方。核心问题叫上下文腐烂：当关键内容落在上下文窗口的中间位置时，模型性能下降超过30%（Chroma研究数据，斯坦福的“Lost in the Middle”论文佐证）。即使百万Token窗口，也会随着上下文增长而出现指令遵循能力退化。

生产环境的应对策略包括：

——接近上下文上限时总结对话历史。Claude Code会保留架构决策和未解决的Bug，丢弃冗余的工具输出。
——JetBrains的Junie隐藏旧的工具输出结果，但保留工具调用记录可见。
——只维护轻量标识符，动态加载数据。Claude Code用grep、glob等搜索工具而不是把整个文件加载进来。
——每个子智能体可以大量探索，但只返回1000-2000 Token的精炼摘要。

Anthropic的上下文工程指南把目标说得很清楚：找到最小的高信号Token集合，最大化期望输出的可能性。ACON研究展示了26-54%的Token缩减，同时保持95%+的准确率——通过优先保留推理轨迹而非原始工具输出。

06 错误处理

简单的数学：一个10步流程，如果每步成功率是99%，端到端成功率只有约90.4%。错误的复合效应极其残酷。

LangGraph把错误分成四种：

（退避重试）、（把错误当ToolMessage返回，让模型自己调整）、（中断等人介入）、（上报调试）。Anthropic在工具处理器内部捕获失败并作为错误结果返回，保持循环不断运行。Stripe的生产Harness把重试上限设为2次。

这让我想起分布式系统的一个老原则：不要假设任何一次调用会成功。区别在于，传统分布式系统的错误是确定性的（超时、网络断开），而智能体的错误是概率性的——模型可能给出语法正确但语义错误的结果。这更难捕捉，也更需要验证循环。

OpenAI的安全护栏设计也值得一提。它分三层：

（在第一个智能体上运行）、（在最终输出上运行）、（在每次工具调用时运行）。还有一个“绊线”机制——一旦触发立即停止智能体。Anthropic则在架构上把权限执行和模型推理分离：模型决定尝试什么，工具系统决定允许什么。Claude Code独立控制约40个离散的工具能力，经过三个阶段：项目加载时建立信任、每次工具调用前权限检查、高风险操作需要用户明确确认。

07 验证循环

这是把玩具Demo和生产级智能体区分开来的关键。Anthropic推荐三种验证方式：

（测试、代码检查工具、类型检查器）、（通过Playwright截屏验证UI任务）、（单独的子智能体来评估输出质量）。

Claude Code的子智能体编排也很有代表性。它支持三种执行模式：

（父上下文的完整复制）、（独立终端窗格，通过文件邮箱通信）、（自己的Git工作树，每个智能体一个隔离分支）。OpenAI的SDK支持“智能体即工具”（专家处理有边界的子任务）和“交接”（专家接管全部控制）。LangGraph则把子智能体实现为嵌套状态图。

Claude Code的创造者Boris Cherny说过：

给模型一种验证自己工作的方式，可以将质量提升2到3倍。

是2到3倍。不是10%的边际改善，是翻倍。

08 七个设计抉择

每个Harness架构师都要面对七个关键选择。挑几个最有争议的说：

。Anthropic和OpenAI的建议一致：先把单智能体做到极致。多智能体系统会增加额外的大模型调用开销（路由）和上下文丢失（交接）。只有当工具过载超过约10个重叠工具，或者任务领域确实互不相干时，才应该拆分。很多团队一上来就搞“多智能体协作”，其实是在用架构的复杂度掩盖单智能体能力的不足。先让一个智能体真正好用，再考虑分裂。

。这一条反直觉：工具越多，表现往往越差。Vercel把v0的80%的工具都砍掉了，结果反而更好。Claude Code通过延迟加载实现了95%的上下文缩减。原则是：只暴露当前步骤需要的最小工具集。

。多少逻辑放在Harness里，多少留给模型？Anthropic押注薄Harness + 模型改进——他们会定期从Claude Code的Harness里删除规划步骤，因为新版模型已经内化了这个能力。图结构框架（如LangGraph）则押注显式控制。

09 各家怎么做的

Akshay把四大框架的实现方式做了横向对比：

框架	核心理念	特点
Claude Agent SDK	“傻循环”	单个 query() 函数，智能全在模型端
OpenAI Agents SDK	代码优先	原生Python表达逻辑，三层架构（Core/Server/Client）
LangGraph	显式状态图	两个节点 + 条件边，从AgentExecutor演进
CrewAI	角色分工	Agent/Task/Crew 三层，Flows层做确定性路由

有意思的是Codex团队说的一句话：“Codex模型在Codex的界面上感觉比在通用聊天窗口好用。”因为模型是和这个特定的Harness一起后训练的。换一个Harness，性能就会下降。这暗示了一个深层趋势——

。

还有一个很重要的观察。LangChain从AgentExecutor进化到LangGraph，是因为AgentExecutor在v0.2被弃用了——原因很简单：难以扩展，不支持多智能体。LangChain的Deep Agents明确使用了“Agent Harness”这个术语：内置工具、规划（write_todos工具）、文件系统做上下文管理、子智能体生成、持久化记忆。这说明行业正在趋向统一的Harness概念，尽管实现路径不同。

AutoGen（正在演变为Microsoft Agent Framework）则开创了对话驱动的编排。它的三层架构（Core、AgentChat、Extensions）支持五种编排模式：顺序、并发（扇出/扇入）、群聊、交接和Magentic（管理者智能体维护动态任务台账，协调专家）。五种模式覆盖了几乎所有的多智能体协作场景。

10 脚手架隐喻

文章里有一个特别精妙的隐喻：Harness就像建筑工地的脚手架。脚手架不负责施工，但没有它，工人够不到高楼层。关键洞察是：

。

这在智能体领域的意思是：随着模型变强，Harness的复杂度应该降低。Manus在六个月内重建了五次，每次重写都在删减复杂度——复杂的工具定义变成了通用Shell执行，“管理智能体”变成了简单的结构化交接。这个节奏本身就说明问题：不是“设计一次，用十年”，而是“模型每升级一代，Harness就要瘦身一轮”。

这背后存在一个“共同进化原则”：模型现在会带着特定Harness做后训练。Claude Code的模型学会了使用它训练时的特定Harness。更换工具实现可能会降低性能，因为这种紧密耦合。对开发者来说意味着什么？选择Harness，就是选择了生态。

这里有一个“未来验证测试”：如果换上更强的模型后，性能自动提升，而不需要增加Harness复杂度——那你的Harness设计就是好的。

11 对我们意味着什么

我自己这段时间也在密集使用各种智能体编程工具，体感和这篇文章的结论完全一致。模型能力已经够用了——Claude Opus、GPT-4.1、Gemini Pro，在模型层面差距越来越小。真正拉开体验差距的，就是Harness。同一个模型，放在不同的Harness里，表现可以天差地别。

几个关键启示：

1.

。两个用相同模型的产品，可以因为Harness设计不同而表现天差地别。TerminalBench的数据很说明问题：仅靠Harness优化就能跳20+名。对于做AI产品的团队来说，把80%的精力放在Harness上，可能比换模型更有效。

2.

。Vercel砍掉80%工具反而更好。Manus每次重建都在删减。这和软件工程的直觉一致——最好的代码是你不需要写的代码。最好的Harness，是让模型自己解决问题的Harness。

3.

。Claude的模型是和Claude Code的Harness一起训练的。换Harness等于换了模型的运行环境。这意味着未来的竞争不只是模型之战，也不只是应用之战，而是“模型 + Harness”组合的系统之战。

原文最后一句说得好：下次你的智能体失败了，别怪模型。看看Harness。

可以补充一句：如果你做的AI产品还在比谁调的模型更贵、更强，方向可能已经偏了。真正的差距，在模型外面。

行业正在走向更薄的Harness。但Harness本身不会消失。即使最强的模型，也需要有东西来管理它的上下文窗口、执行它的工具调用、持久化它的状态、验证它的工作。这些不是“暂时需要”的功能，而是智能体系统的结构性需求。就像操作系统不会因为CPU变快而消失一样。