最近，AI 编程圈流传着一句扎心的话：Prompt 工程过时了，Context 工程也过时了，现在学好 Harness 工程才是王道。
短短一个月，Harness Engineering 从一篇博客文章里的概念，迅速成为开发者社区的高频词，甚至有人说，它正在重塑 AI 智能体编程的底层逻辑。
其实核心真相很简单：在 AI 智能体编程领域，决定结果好坏的最大变量，从来不是模型有多聪明，而是模型之外那一整套状态、工具、环境、反馈回路与约束系统。
如果 AI 终将成为软件开发流程中的长期参与者，那么软件工程系统本身，也需要一场对应的进化。
LangChain 作者 Vivek Trivedy 在《The Anatomy of an Agent Harness》中，就试图回答这个越来越关键，但行业内总说不清楚的词：Harness。
一、核心定义：Agent = Model + Harness
有一句很绝对，但直击本质的话：如果你不是模型，那就是 Harness。
Harness 本质上就是模型之外的一切——代码、配置，以及各种执行逻辑。模型本身只是能力的来源，就像一把锋利的刀，而 Harness 就是握住刀的手、使用刀的方法，只有通过它把状态、工具调用、反馈循环和约束机制串起来，模型才真正变成一个能自主工作的 Agent。
具体来说，Harness 通常包含这 5 个核心部分：
-
系统提示词：定义模型的角色和核心目标，相当于给 Agent 定好“岗位职责”；
-
工具、技能、MCP：模型可以调用的外部能力，是 Agent 完成任务的“工具箱”；
-
基础设施：文件系统、沙箱、浏览器等运行环境，是 Agent 工作的“办公场地”；
-
编排逻辑：子 Agent、任务拆分、模型路由等，相当于 Agent 的“工作流程指南”；
-
钩子/中间件：压缩、续写、代码检查等确定性流程，是 Agent 工作的“质量把关人”。
为什么要用「模型 vs Harness」来划分系统？因为这是最清晰的边界。很多关于 Agent 的定义都很模糊，但用这个方式去看，会逼你明确两件事：模型负责什么？剩下的系统要补什么？
二、关键问题：为什么一定要有 Harness？
答案很朴素，却戳中核心：有些事我们希望 Agent 能做，但模型本身做不到。
先搞清楚模型的边界，就懂了 Harness 的价值。大多数模型的输入是文本、图像、音频，输出也只是文本——它本质上就是一个“输入→输出”的函数，本身并不会做这些事：
-
在多轮交互中记住状态（比如聊天时记得上一轮的对话）；
-
执行代码、运行程序；
-
获取实时信息（比如最新的 API 变化、新发布的库版本）；
-
操作环境（比如装依赖、修改本地文件）。
这些能力，都不在模型里，而是靠 Harness 补回来的。
举个最常见的例子：聊天。我们觉得和 AI 聊天很自然，但其实模型本身并不会“聊天”。要实现这个体验，至少需要做 3 件事：
-
维护一段对话历史；
-
每次请求时把历史拼进上下文；
-
不断循环接收用户输入和模型输出。
本质上，就是用一个简单的循环，把模型“包起来”用——而这个循环，就是 Harness 的一部分。
这也是 Harness Engineering 的核心思路：不纠结于“调教模型能不能做到”，而是先想清楚“要它做到什么”，再把这些能力一个个补到 Harness 里。
三、拆解 Harness 核心组件：每一部分都在解决模型的“短板”
Harness 的每一个组件，都是为了弥补模型的不足，让 Agent 能真正自主、高效、安全地工作。我们逐一拆解最关键的几个核心模块。
1. 文件系统：Agent 的“工作笔记本”
我们希望 Agent 能用真实数据、能保存工作成果、能处理超出上下文窗口的内容，但模型只能处理当前上下文里的信息——没有文件系统，用户只能反复复制粘贴，Agent 根本无法自主工作。
所以 Harness 必须提供文件系统抽象和对应的读写操作，有了它，Agent 才算有了“工作空间”：
-
可以自由读写数据、代码和文档；
-
信息按需加载，不用一股脑塞进上下文（避免占用有限资源）；
-
中间结果可以保存，状态能跨会话保留（比如这次没做完，下次可以继续）；
-
文件本身就是协作接口：人和多个 Agent 可以围绕同一份文件协同工作。
如果再加上 Git 版本控制，就更完善了：可以记录每一步改动、出问题能回滚、还能开分支做不同尝试。
其实文件系统不是“附加功能”，而是最基础的 Harness 组件——后面的状态管理、协作、任务拆分，都要依赖它。
2. Bash + 代码执行：Agent 的“万能工具箱”
我们真正想要的，是让 Agent 能自己解决问题，而不是每一步都要我们提前设计好工具。但现在大多数 Agent 都有一个局限：只能用我们提前给好的工具，而我们不可能穷举所有工具。
更高效的做法是：不给一堆固定工具，直接给它一台“能干活的机器”——在 Harness 里提供 Bash + 代码执行能力。
一旦有了这个能力，Agent 的灵活性会瞬间提升：
-
可以自己写脚本解决问题，不用依赖预定义接口；
-
可以临时“造工具”，应对突发需求；
-
可以组合已有能力，拼出新的工作流。
本质上，我们不再是“设计工具列表”，而是给 Agent 提供一个通用执行环境——这才是让 Agent 真正“自主解决问题”的关键。
3. 沙箱环境和工具：Agent 的“安全工作间”
给了 Agent“能存”（文件系统）和“能执行”（Bash + 代码）的能力，还不够——它还需要一个能放心干活的地方。
如果直接在本地执行模型生成的代码，风险很高（比如误删文件、触发恶意代码）；而且本地环境也很难支撑多任务、并发的 Agent 工作。所以更合理的做法是：把执行放进沙箱里。
沙箱主要解决两个核心问题：
① 安全性
-
隔离执行环境，避免影响本地系统；
-
可以限制命令、禁用网络、控制权限；
-
即使出错，也被限制在沙箱内部，不会造成全局损失。
② 可扩展性
-
可以按需创建环境，适配不同任务；
-
多个任务可以并行执行，互不干扰；
-
用完就销毁，不留下状态污染。
但光有沙箱还不够，还要让它“开箱能用”——Harness 会提前准备一套默认工具，比如语言运行时、常用依赖、Git、测试工具、浏览器等。
这些工具的价值，不只是“能用”，更是让 Agent 能观察自己的工作结果：看日志、跑测试、截图页面、检查输出，从而形成一个“写代码→运行→观察→修复→再运行”的自我验证循环——而这，正是 Harness 的核心职责之一。
4. 记忆与搜索：Agent 的“学习能力”
我们希望 Agent 不只是“当下聪明”，还要能记住东西、查到新信息，但模型本身没有“记忆”，也不能主动更新知识——它的知识只来自训练时的权重，和当前上下文里的信息。
要解决这个问题，关键只有一个：通过上下文注入，把新知识、新信息喂给模型。
这里，文件系统又成了基础设施。一种常见的做法是，让 Harness 维护一份“记忆文件”（比如 AGENTS.md）：
-
Agent 运行时可以往里面写信息（比如学到的经验、遇到的问题）；
-
下次启动时，这些内容会重新加载进上下文；
-
文件更新了，Agent 的“记忆”也会随之更新。
这是一种很朴素的“学习方式”——虽然没有修改模型权重，但已经能实现跨会话积累经验。
而针对“模型不知道现在发生了什么”的问题（比如最新的 API 变化、实时数据），Harness 会提供搜索和外部知识获取能力（比如 Web Search、Context7 等工具），把模型“看不到”的信息，拉进上下文里。
5. 对抗上下文衰减：让 Agent 不“越用越笨”
上下文是有限资源，一旦内容越来越长，模型的表现就会变差——这就是“上下文衰减”：有效信息比例下降、关键线索被淹没、推理能力不稳定。
而 Harness 的核心作用之一，就是把“上下文管理”工程化，让 Agent 在长时间工作中，始终用“干净”的上下文。主要有 3 种核心手段：
-
压缩（Compaction）：上下文快满时，对已有内容做总结、保留关键信息，把细节移出上下文，避免信息冗余；
-
工具调用卸载：工具输出往往又长又杂，只保留开头和结尾的关键信号，完整内容写入文件系统，需要时再读取，避免“噪音”占据上下文；
-
技能延迟加载：不一开始就把所有工具说明、MCP 描述塞进上下文，而是按需加载——先给最小必要信息，需要某个能力时，再引入相关内容，相当于工具的“懒加载机制”。
6. 长期自主执行：让 Agent 能“从头做到尾”
我们真正想要的，是让 Agent 能把一件复杂的事从头做到尾，但现在的模型常常出现“提前结束”“任务拆解不清晰”“跨上下文工作不连贯”的问题——问题不在模型会不会写代码，而在能不能持续推进工作。
这需要多组能力叠加，而核心还是离不开 Harness：
-
文件系统 + Git：把工作过程“记下来”，中间结果落盘、历史变化可追溯，新的 Agent 能快速接手进度，多 Agent 协作也有了“共享笔记本”；
-
Ralph 循环：拦截模型“我要结束”的信号，给它一个干净的上下文，让它继续朝目标推进——关键是，上下文可以重置，但状态不能丢（这也是文件系统的重要性）；
-
规划 + 自我验证：先把目标拆成步骤写进文件，持续更新，避免跑偏；每做完一步，通过跑测试、看日志、检查输出来验证，失败了就把错误信息喂回模型，继续修正，形成“执行→检查→反馈→修正”的闭环。
四、Harness 与模型：共同进化，而非相互替代
今天的 Agent 产品（比如 Claude Code、Codex），都是模型和 Harness 同时演化的结果——模型不仅学习生成文本，还被训练去更好地使用 Harness 提供的工具和流程（比如文件系统操作、Bash 执行、任务规划）。
这形成了一个良性反馈循环：
-
Harness 提供原语和操作能力；
-
模型学习如何使用这些原语；
-
训练结果反馈回下一代模型；
-
模型在相同 Harness 环境中表现越来越好。
但这种共同进化也有副作用：模型可能对特定工具或逻辑“过拟合”，换个 Harness 环境，性能就会下降。
比如 Codex-5.3 中，用于编辑文件的 apply_patch 工具，如果模型训练时只接触一种逻辑，切换补丁方法就可能出问题；Terminal Bench 2.0 测试也显示，Claude Code 中的 Opus 4.6，在不同 Harness 中的得分差距很大。
这也说明：最适合你任务的 Harness，不一定是模型训练时使用的那个。LangChain 的编码 Agent 就是最好的例子——通过优化 Harness（文档结构、验证回路、追踪系统），它在同一基准下的排名从全球第 30 位升到第 5 位，得分从 52.8% 提升到 66.5%。
五、结语：Harness 是舞台，模型是演员
有人说，随着模型越来越强大，Harness 会变得不那么重要——毕竟模型未来可能会吸收 Harness 的部分功能，在规划、自我验证、长时程任务连贯性上更可靠，对上下文注入的依赖也会减少。
但就像 Prompt 工程今天依然有价值一样，Harness Engineering 未来依然是构建高效 Agent 的关键——因为它不只是弥补模型的不足，更是一种“设计系统的方式”：
-
配置良好的环境，让模型不用“束手束脚”；
-
合适的工具，让模型能“大展拳脚”；
-
持久的状态和验证循环，让模型能“稳定输出”。
用一个很贴切的比喻来说：
Harness 是舞台和幕后控制系统，Agent 是舞台上的演员。无论演员多么出色，没有舞台、没有灯光、没有规则，也难以发挥全部能力。
在 AI 智能体时代，真正的核心竞争力，从来不是“选对模型”，而是“驾驭模型”——而 Harness Engineering，就是那套最关键的“驾驭之道”。
欢迎关注一步API（yibuapi.com） ，我们还会持续分享更多AI咨询、AI工具、实战经验、踩坑记录，助力你高效玩转AI开发、避开行业弯路。
想了解更多细节、获取专属支持，可添加客服微信：xuexiv5876 \ YibuDev，随时咨询交流～
