Agent Harness：为什么你的模型不是问题所在
- William Jacob
- Agent , 架构
- 11 May, 2026
LangChain 在 TerminalBench 2.0 上从 30 名开外飙到了第 5 名。他们没有换模型。同一个 LLM。同样的参数。唯一改变的是包裹在模型外面的那层软件——Harness。
另一个团队更进一步：让 LLM 自己去优化 Harness，拿到了 76.4% 的通过率，超过了人类工程师设计的系统。模式是一致的。模型很少是你的瓶颈。它周围的基础设施几乎总是。
Anthropic、OpenAI、Perplexity 和 LangChain 都在造同一个东西——各有各的叫法，各有各的取舍。2026 年初，行业终于给了一个正式名称：AI Agent Harness。
Harness 到底是什么
Harness 是模型之外让 Agent 运转的一切。不停运转直到任务完成的编排循环。给模型双手的工具定义。跨 session 记住事情的记忆系统。决定模型在什么时间看到什么内容的上下文管理。在失败滚雪球之前捕获它的错误恢复。在模型想做危险操作时说不的护栏。
LangChain 的 Vivek Trivedy 说得很直白：“如果你不是模型本身，那你就是 Harness。”
Beren Millidge 的比喻更精准。原生 LLM 就像一个没有内存、没有硬盘、没有输入输出设备的 CPU。上下文窗口是内存——快但容量有限。外部数据库是硬盘——大但速度慢。工具是设备驱动程序。Harness 是操作系统。我们重新发明了冯·诺依曼架构，不是因为它聪明，而是因为它对任何计算系统来说都是最自然的抽象。
Anthropic 把他们的运行时描述为一个”笨循环”。所有智慧都在模型里。Harness 只管理回合切换、工具执行和状态。循环很简单。复杂的是循环要处理的所有状态。
Agent 工程的三个层次
围绕模型的工程化工作分三个同心圆：
提示词工程——精心设计模型收到的指令。这是最内层，也是大多数人开始的地方。
上下文工程——管理模型在什么时间点看到什么内容。窗口里现在有什么？什么被总结了？什么被丢弃了？斯坦福的”迷失在中间”现象就在这一层吃掉你的性能。
Harness 工程——涵盖以上两者，再加上完整的应用架构：工具编排、状态持久化、错误恢复、验证循环、安全执行和生命周期管理。这是决定生产级 Agent 成败的一层。
大多数团队在提示词工程上过度投资，在 Harness 工程上投资不足。TerminalBench 的结果表明，这个比例搞反了。
12 个组件，按最先出问题的顺序排列
一个生产级的 Harness 有十二个独立组件。你不需要第一天就全部到位。但你需要知道把系统推到生产时，哪一个会先崩。
心脏：编排循环
这就是那个 while 循环，执行 思考→行动→观察 直到任务完成。组装提示词，调用模型，解析输出，执行工具调用，喂回结果，重复。描述起来简单，实现好很难——因为这个循环要处理模型可能产生的每一种状态，包括你没预料到的那些。
双手：工具
工具是注入到模型上下文中的结构化模式，让模型知道它能做什么。Harness 负责注册、参数提取、沙箱执行和结果格式化。Claude Code 提供六大类工具：文件、搜索、执行、网页访问、代码分析和子 Agent 生成。OpenAI SDK 支持函数工具、托管工具（网页搜索、代码解释器）和 MCP 服务器工具。
关键洞察：工具应该按当前步骤限缩范围，而不是暴露给整个 Agent。超过大约十二个同时可见的工具，模型就开始选错了。
记忆：短期、长期和索引
记忆在不同时间尺度上运作。短期记忆是单次 session 内的对话历史。长期记忆跨 session 持久存在——磁盘上的文件、按命名空间组织的 JSON 存储、SQLite 驱动的会话。
Claude Code 实现了三层架构：一个约 150 字符的轻量级索引始终加载；详细的主题文件按需调用；原始对话记录仅通过搜索访问。设计原则是：Agent 把自己的记忆视为提示，而非真理。每条回忆在行动前必须根据当前状态验证。
上下文窗口：模型真正看到的东西
上下文管理是大多数 Agent 悄悄翻车的地方。窗口中间的关键信息会使模型表现下降超过 30%——这就是斯坦福的”迷失在中间”发现。即使是百万 token 的窗口，指令遵循能力也随上下文增长而退化。
生产策略：压缩——总结对话历史，同时保留架构决策和未修复的 bug；观察掩码——隐藏旧工具输出但保留调用记录；即时检索——按需加载而非预加载一切；子 Agent 委托——每个子 Agent 深度探索，但只返回 1000-2000 token 的浓缩摘要。
目标，正如 Anthropic 的上下文工程指南所说：找到信号最强的最小 token 集合，最大化达成目标的概率。
胶水：提示词构建、输出解析、状态
提示词构建是层级化的：系统提示词在最上面，然后是工具定义、记忆文件、对话历史，最后是当前用户消息。OpenAI Codex 使用严格优先级栈，服务端控制的系统消息覆盖它下面的一切。
输出解析依赖原生工具调用——模型返回结构化的 tool_call 对象，而不是需要你写正则解析的自由文本。Harness 检查：有工具调用吗？执行它，继续循环。没有？这就是最终答案。
状态管理因框架而异。LangGraph 把状态建模为在图中节点间流动的类型化字典，在关键步骤存档——支持中断恢复，甚至时间旅行式调试。Claude Code 用 git commit 做存档点，用进度文件做结构化草稿纸。
安全网：错误处理、护栏、验证
错误处理重要是因为失败会累积。一个 10 步流程，每步 99% 成功率，端到端可靠性只有大约 90%。LangGraph 把错误分为四类：临时性的（延迟重试）、模型可恢复的（把错误作为工具消息返回，让模型自己调整）、人类可修复的（暂停等待）、异常错误（上报调试）。
护栏分多层运作：输入护栏在第一个 Agent 运行前检查；输出护栏检查最终结果；工具护栏在每次工具调用前检查。触发绊网，Agent 立即停止。
验证循环是区分玩具 demo 和生产系统的那个东西。Anthropic 推荐三种方法：基于规则的反馈（测试、代码检查）、视觉反馈（通过 Playwright 截 UI 图）、LLM 当裁判（另一个子 Agent 评估输出）。Claude Code 的创建者 Boris Cherny 指出，让模型能够验证自己的工作，能把产出质量提升 2-3 倍。
舰队：子 Agent 编排
Claude Code 支持三种子 Agent 模式：fork（克隆父级上下文）、teammate（独立窗口，通过文件邮箱通信）、worktree（独立 git 分支）。OpenAI 支持 Agent 作为工具（专家处理特定子任务）和移交（专家接管后续控制权）。模式是一样的：子 Agent 做深度探索，摘要回到编排器。
Harness 设计常犯的错误
过早构建太多 Harness。脚手架这个比喻不是装饰——建筑脚手架是临时的。它让工人够到本够不到的高度，但房子盖好后要拆掉。随着模型能力提升，你的 Harness 应该越来越薄，而不是越来越厚。如果你每次升级模型都要加复杂度，你就是做反了。
过度设计编排循环。Anthropic 的”笨循环”哲学对大多数场景是正确的。模型比你手写的路由逻辑聪明。给它好工具、好上下文、清晰目标，然后让路。
把记忆当作真理。Claude Code 的架构明确将存储的记忆视为需要验证的提示。把它们当作基础事实，会产生自信地基于过时信息行动的 Agent。
跳过验证。从 demo 到生产的跳跃，是从”模型说它对”到”系统证明它对”的跳跃。如果你的 Agent 不验证自己的输出，你交付的就是一个 demo。
现在如何思考 Harness 设计
从简单开始。一个 Agent。一个循环。几个精准限缩的工具。在加任何东西之前先把验证循环做对。TerminalBench 的证据是清晰的：一个好模型上的薄 Harness，好过一个顶级模型上的复杂 Harness。
每个 Harness 架构师要面对的七个选择：
- 单 Agent 还是多 Agent——先穷尽单 Agent 能力
- ReAct 还是先规划后执行——ReAct 灵活但贵；先规划更快
- 压缩还是检索——总结对话还是按需加载
- 规则打分还是 LLM 当裁判——硬测试还是另一个模型打分
- 自动批准还是逐步确认——工具执行上的速度与安全
- 工具范围——暴露比拥有更少的工具；按当前步骤限缩
- Harness 厚度——多少逻辑写在代码里，多少留给模型发挥
协同进化原则：现在的模型在训练时就考虑了 Harness 的存在。如果你的 Harness 设计得好，模型升级时你不需要增加复杂度，性能就会自动提升。Harness 随时间变薄，而不是变厚。
两个使用完全相同模型的 Agent，性能可以天差地别。差距永远是 Harness。TerminalBench 用 25 个名次的跃升证明了这一点。你的生产日志正在证明这一点。
下次你的 Agent 表现不佳，别急着找更好的模型。先找更好的 Harness。从循环开始。然后是记忆。然后是验证。当系统证明它对的时候再发布——而非模型说它对的时候。
