Agent Harness ：2026年AI工程的核心范式

顶级模型在静态榜单上的差距正在缩小——但这可能是一种幻觉。模型之间真正的差距，在任务越复杂、越长期时才会显现出来，核心指标是耐久性（durability）：模型在执行了几十甚至上百次工具调用之后，还能不能持续遵循最初的指令？排行榜上1%的差异，根本捕捉不到这种长流程下的可靠性。

Martin Fowler——软件工程领域最受尊重的声音之一——在2026年2月专门撰文提出了"Harness Engineering（线束工程）"这个术语。Anthropic发布了《长时运行Agent的有效线束》。OpenAI的Codex团队用这套方法生成了超过100万行生产代码，零手动输入。他们都在说同一件事：决定AI能否可靠完成工作的，不是模型本身——而是包裹在模型外面的系统。这个系统，就叫做 Agent Harness。

Harness 是什么？一个定义，一个比喻

核心定义

Agent = Model + Harness。如果你不是模型，你就是 Harness。

Harness 是所有不属于模型本身的代码、配置和执行逻辑。一个裸模型不是 Agent，但当 Harness 给它提供状态、工具执行、反馈循环和可执行约束之后，它就变成了一个 Agent。

具体来说，Harness 包括：系统提示词、工具/技能/MCP及其描述、基础设施（文件系统、沙箱、浏览器）、编排逻辑（子 Agent 调度、交接、模型路由）、以及用于确定性执行的钩子/中间件（上下文压缩、延续、语法检查）。

最清晰的比喻：计算机类比

我们可以把它理解为：

• 模型是 CPU：提供原始处理能力
• 上下文窗口是内存（RAM）：有限的、易失的工作记忆
• Agent Harness 是操作系统：负责整理上下文、处理"启动"序列（提示词、钩子），并提供标准驱动（工具调用）
• Agent 是应用程序：运行在操作系统之上的具体用户逻辑

Harness 实现"上下文工程"策略——通过压缩减少上下文、将状态卸载到存储、或将任务隔离到子 Agent 中。对开发者而言，这意味着你可以跳过构建操作系统，直接聚焦在应用层，即定义 Agent 的独特逻辑。

Harness vs Framework vs Agent 的三层区别

Framework（如 LangChain、LangGraph）是基础层，提供构建块：链式组件、工具调用、记忆、编排原语。框架基本不在乎你怎么组装这些原语，这意味着灵活性，但同时意味着你要自己解决所有生产环境问题。

Harness 建立在 Framework 之上，或者完全替代它，提供一个有主观立场的基础设施层。像 Claude Code 或 LangChain DeepAgents 这样的 Harness，内置了上下文管理、工具执行、状态持久化和验证的默认架构。你不需要从零组装，只需定制和扩展 Harness 提供的能力。

Agent 运行在 Harness 之上，是定义"做什么"的具体逻辑：目标、决策模式、领域工具和提示词。Agent 关注"是什么"，而 Harness 处理可靠执行的"怎么做"。

核心组件解剖：Harness 由哪些层构成？

一个完整的 Agent Harness 包含以下核心模块：

1. 执行循环

基本 Agent 执行模式是 ReAct 循环：模型推理 → 通过工具调用执行动作 → 观察结果 → 重复，直到完成任务。但 Harness 只能执行它有逻辑支持的工具。与其强迫用户为每一个可能的动作构建工具，更好的解决方案是给 Agent 一个通用工具，比如 bash。

Ralph Loop 是一种 Harness 模式：它通过钩子拦截模型的退出尝试，在一个干净的上下文窗口中重新注入原始提示词，强迫 Agent 继续围绕完成目标工作。文件系统使这成为可能，因为每次迭代都从新鲜的上下文开始，但从上次迭代读取状态。

2. 工具执行层

Harness 负责 Agent 与外部世界之间的每一次交互，包括 shell 命令、API 调用、数据库查询、网络搜索和文件操作。Harness 在沙箱环境中执行这些操作，强制执行超时和权限限制，并将结果格式化为模型可以有效推理的结构。

工具执行的典型流程是：拦截请求 → 验证权限 → 在隔离环境执行 → 净化输出 → 反馈给模型。

3. 文件系统与持久化存储

文件系统是最基础的 Harness 原语，它解锁了：Agent 拥有读写数据、代码和文档的工作空间；工作可以增量添加和卸载，而不是把所有东西都保存在上下文里；Agent 可以存储中间输出，维持跨会话的状态。文件系统是天然的协作面——多个 Agent 和人类可以通过共享文件协调工作，Agent Teams 架构正是依赖这一点。Git 则在文件系统之上增加版本控制，让 Agent 能追踪工作、回滚错误、分支实验。

4. 上下文管理与 Context Rot 对抗

Context Rot（上下文腐烂）描述的是随着上下文窗口填满，模型的推理和任务完成能力会逐渐变差的现象。上下文是稀缺资源，Harness 需要管理它的策略：

压缩（Compaction）：当上下文窗口快要填满时，智能卸载和总结现有上下文，让 Agent 能继续工作。

工具调用输出卸载（Tool call offloading）：当工具输出过大时，Harness 保留输出的头尾 token，将完整输出卸载到文件系统，模型需要时可以访问。

技能（Skills）：解决在 Agent 启动时把太多工具或 MCP Server 加载进上下文的问题——通过渐进式披露（progressive disclosure），只在需要时加载相关工具的元信息。

5. 记忆与持续学习

对于记忆，文件系统再次成为核心原语。Harness 支持像 AGENTS.md 这样的记忆文件标准，在 Agent 启动时注入上下文。当 Agent 添加和编辑这个文件时，Harness 在未来的会话中加载更新后的版本注入上下文。这是一种持续学习的形式：Agent 从一次会话中持久存储知识，并将其注入到未来的会话中。

6. 沙箱与验证循环

沙箱给 Agent 提供安全的运行环境：在隔离环境中执行代码，预装语言运行时和包、git 命令行工具、用于 Web 交互的浏览器等。浏览器、日志、截图和测试运行器让 Agent 能够观察和分析自己的工作，创建自我验证循环：编写应用代码 → 运行测试 → 检查日志 → 修复错误。

7. 中间件与生命周期钩子

这些是 Harness 工程师注入自定义逻辑的执行节点：工具调用前的输入验证、工具调用后的输出验证、针对任务规范的预完成检查、结构化错误格式化。这些钩子让 Harness 工程师对 Agent 行为有精确控制，而无需修改模型或 Agent 的核心逻辑。

8. 护栏与约束

Harness 负责在基础设施层强制执行公司的安全策略——确保敏感数据不会离开你的环境，Agent 的每一次行动都被记录以供审计。对于敏感动作（如删除客户数据或批准大额交易），Harness 会自动暂停 Agent 执行，提醒人类用户审查，这就是 Human-in-the-Loop（HITL） 控制。

实验证据

LangChain 的基准测试跳跃

LangChain 在 Terminal Bench 2.0 上测试他们的编程 Agent，得分52.8%，排名在前30之外。然后，他们不改动模型——同一个模型，同一个 API——只修改了 Harness。结果：66.5%，排名跃升至前5。

具体改动：① 添加自我验证循环（强制执行检查清单后才能说"完成"）；② 注入环境上下文（启动前扫描目录结构并喂给 AI）；③ 反漂移检测（发现 AI 在重复编辑同一个文件时发出警报）；④ 调整推理预算（规划和验证时多想，实现时少想）；⑤ 失败分析（自动分析多次运行中的失败模式）。

Vercel 的减法实验

Vercel 把 AI Agent 的可用工具数量从15个削减到仅剩2个。结果：准确率从80%跳到100%，Token 消耗下降37%，速度提升3.5倍。少即是多，约束本身就是 Harness 设计。

The Bitter Lesson 的 Agent 版本

Harness Engineering 有一个深层教训值得单独强调。

Rich Sutton 写过一篇《苦涩的教训》：利用计算能力的通用方法，每次都会击败手工编码的人类知识。这一教训正在 Agent 开发中再次上演：Manus 在六个月内重构了五次 Harness 以移除硬编码假设；LangChain 在一年内对他们的 "Open Deep Research" Agent 做了三次架构重设计；Vercel 移除了80%的 Agent 工具。

为了从苦涩教训中存活下来，基础设施（Harness）必须是轻量的。每次新模型发布，都会有不同的最佳 Agent 结构方式。2024年需要复杂手工管道才能做到的事，2026年一个单一上下文窗口的提示词就够了。

开发者必须构建允许他们随时丢弃昨天写的"聪明"逻辑的 Harness。如果过度工程化控制流，下次模型更新就会破坏你的系统。

模型训练与 Harness 设计的共同演化

这是2026年最前沿的视角，值得深入。

今天的 Agent 产品，如 Claude Code 和 Codex，已经在训练时把模型和 Harness 放在一起进行后训练（post-training）。这帮助模型在 Harness 设计者认为它们应该原生擅长的动作上有所改进——文件系统操作、bash 执行、规划、或通过子 Agent 并行工作。

这创造了一个反馈循环：发现有用的原语 → 加入 Harness → 在训练下一代模型时使用。这个循环重复，模型在其训练所在的 Harness 中变得更有能力。

但这种共同进化有一个有趣的副作用：改变工具逻辑会导致模型性能变差——因为模型已经过度拟合到特定的 Harness 结构上了。这也意味着，适合你任务的最佳 Harness，不一定是模型被后训练时使用的那个 Harness，仍然有很多空间去针对你的具体任务优化 Harness。

Harness 的未来走向

随着模型越来越强，今天 Harness 里的一些东西会被模型吸收。模型会在规划、自我验证、长期连贯性上原生变强，因此需要的上下文注入越来越少。这意味着 Harness 随时间会变得不那么重要——但就像提示工程今天依然有价值一样，Harness 工程也可能继续发挥作用。

目前 LangChain 正在探索的开放性前沿问题包括：在共享代码库上并行运行数百个 Agent；让 Agent 分析自己的追踪记录来识别和修复 Harness 层面的故障；Harness 能够动态组装恰好合适的工具和上下文，而不是预先配置好一切。

未来 Harness 将成为解决"模型漂移"的主要工具——各大实验室会用 Harness 来精确检测模型在第100步之后是何时停止遵循指令或推理出错的。这些数据将直接反馈给训练，来创造不会在长任务中"疲惫"的模型。Harness 就是数据集：你 Harness 捕获的 trajectory（轨迹），才是竞争优势所在，而不再是提示词本身。

总结：一张思维框架图

基于以上所有内容，可以提炼出一个核心认知框架：

核心结论： 模型是智能的载体，Harness 是让智能变得有用的系统。在2026年，各大模型的基础能力已经趋于接近，真正决定 AI 产品质量的分水岭是 Harness 的设计质量——这正是从"提示工程时代"迈入"Harness 工程时代"的本质转变。