主题
《一文看懂 Harness Engineering：智能体时代的 AI 编程驾驭之道》内容总结
来源：技术极简主义公众号 | 作者：兔兔AGI | 日期：2026年3月21日
原文基础：LangChain 作者 Vivek Trivedy 的文章《The Anatomy of an Agent Harness》
核心公式：Agent = Model + Harness。如果你不是模型，那就是 Harness。
一、什么是 Harness？
Harness 本质上就是模型之外的一切：代码、配置以及各种执行逻辑。模型本身只是能力的来源，只有通过 Harness 把状态、工具调用、反馈循环和约束机制串起来，它才真正变成一个 Agent。
Harness 的组成部分
| 组件 | 说明 |
|---|---|
| 系统提示词 | 定义模型的角色和目标 |
| 工具、技能、MCP | 模型可以调用的外部能力 |
| 基础设施 | 文件系统、沙箱、浏览器等运行环境 |
| 编排逻辑 | 子 Agent、任务拆分、模型路由等 |
| 钩子/中间件 | 压缩、续写、代码检查等确定性流程 |
为什么用「模型 vs Harness」来划分？
因为这是一个更清晰的边界，会逼你回答：模型负责什么？剩下的系统要补什么？
二、为什么需要 Harness？
模型的输入是文本/图像/音频，输出是文本。仅此而已。它本身并不会：
- ❌ 在多轮交互中记住状态
- ❌ 执行代码
- ❌ 获取实时信息
- ❌ 操作环境（装依赖、跑程序）
核心思路：不是去"调教模型能不能做到"，而是先想清楚你要它做到什么，再把这些能力一个个补到 Harness 里。
三、Harness 的六大核心组件
1. 文件系统：持久化存储和上下文管理
解决的问题：模型只能处理当前上下文窗口里的内容，没有持久化能力。
有了文件系统后：
- Agent 有了自己的工作空间，可以读写数据、代码和文档
- 信息可以按需加载，而不是一股脑塞进上下文
- 中间结果可以落盘，状态可以跨会话保留
- 文件本身就是协作接口：人和多个 Agent 可以围绕同一份内容协同工作
加上版本控制（Git）：
- 记录每一步改动，出问题可以回滚，可以开分支做不同尝试
文件系统不是"附加能力"，而是最基础的 Harness 原语，后面很多能力（状态管理、协作、任务拆分）都依赖它。
2. Bash + 代码执行：通用问题解决工具
解决的问题：Agent 只能用预定义工具，无法穷举所有工具。
更好的做法：别给一堆工具，直接给它一台"能干活的机器"——提供 Bash + 代码执行能力。
有了这个能力后：
- 模型可以自己写脚本解决问题
- 可以临时"造工具"，而不依赖预定义接口
- 可以组合已有能力，拼出新的工作流
本质上，你不再是在"设计工具列表"，而是在提供一个通用执行环境。
3. 沙箱环境和工具：安全执行与工作验证
解决两个核心问题：
| 问题 | 方案 |
|---|---|
| 安全性 | 隔离执行环境，限制命令、禁用网络、控制权限，出错被限制在沙箱内部 |
| 可扩展性 | 按需创建环境，多任务并行，用完销毁，不留状态污染 |
默认工具集：
- 语言运行时和常用依赖
- Git、测试工具等 CLI
- 浏览器（用于页面交互和验证）
关键闭环：写代码 → 运行 → 观察 → 修复 → 再运行（自我验证循环）
重点不是"提供一个运行环境"，而是：决定 Agent 在什么环境里工作、能用什么工具、能看到什么结果、如何判断自己做对了没有。
4. 记忆与搜索：持续学习能力
模型的知识只来自两部分：训练时学到的内容（权重）+ 当前上下文里提供的信息。
记忆文件机制（如 AGENTS.md）：
- Agent 运行中往里面写信息
- 下次启动时重新加载进上下文
- 一种朴素的"学习方式"：写下来 → 保存 → 下次继续用
搜索与外部知识获取：
- Web Search
- Context7 等上下文查询工具（MCP）
- 把模型"看不到"的信息拉进上下文
5. 对抗上下文衰减：智能压缩策略
Context Rot（上下文衰减）问题：
- 信息变多，有效信息比例下降
- 关键线索被淹没
- 推理能力不稳定
三大核心手段：
| 手段 | 做法 |
|---|---|
| 压缩（Compaction） | 对已有对话做总结，保留关键信息，细节移出上下文 |
| 工具调用卸载（Tool Output Offloading） | 只保留开头+结尾（关键信号），完整内容写入文件系统，需要时再读取 |
| 技能延迟加载（Skills Lazy Loading） | 按需加载工具说明，先给最小必要信息，需要某能力时再引入 |
核心原则：不要让"噪音"占据上下文。把"上下文管理"这件事工程化。
6. 长期自主执行：让 Agent 从头做到尾
现在模型的常见问题：容易提前结束、不擅长拆解复杂任务、跨上下文窗口工作不连贯。
三组能力叠加：
① 文件系统 + Git：把过程"记下来"
- 文件系统记录当前状态，Git 记录历史变化
- 新的 Agent 可以快速接手已有进度
- 多 Agent 协作时本质就是一个共享笔记本
② Ralph 循环：防止"做一半就停"
- 拦截"我要结束"的信号
- 重新给一个干净的上下文
- 让它继续朝目标推进
- 关键：上下文可以重置，但状态不能丢
③ 规划 + 自我验证：让过程不跑偏
- 规划（Planning）：把目标拆成步骤，写进文件，持续更新
- 自我验证（Self-Verification）：每做完一步就检查（跑测试、看日志、检查输出）
- 形成稳定闭环：执行 → 检查 → 反馈 → 修正
四、Harness 与模型的共同进化
模型在训练过程中不仅学习生成文本，还被训练去更好地使用 Harness 提供的工具和流程。
进化反馈循环
Harness 提供原语和操作能力
↓
模型学习如何使用这些原语
↓
训练结果反馈回下一代模型
↓
模型在相同 Harness 环境中表现越来越好副作用
- 模型可能对特定工具或逻辑"过拟合"
- 换了不同的 Harness 环境，性能可能下降
- 最适合你任务的 Harness 不一定是训练时使用的那个
实证数据
Terminal Bench 2.0 测试：Claude Code 中的 Opus 4.6 得分远低于其他 Harness 中的 Opus 4.6。LangChain 通过优化 Agent 运行环境（文档结构、验证回路、追踪系统），排名从全球第30位升到第5位，得分从 52.8% → 66.5%。
五、结语：Harness 的未来
随着模型越来越强大，今天 Harness 中的一些功能可能会被模型自身吸收。但 Harness Engineering 仍将对构建高效 Agent 起关键作用。
原因：
- Harness 不仅弥补模型的不足
- 它还是设计系统的方式，让模型能更有效地完成任务
- 配置良好的环境、合适的工具、持久状态和验证循环，让任何模型都能发挥最大效率
比喻：Harness 是舞台和幕后控制系统，Agent 是舞台上的演员。无论演员多么出色，没有舞台和规则，他们也难以发挥全部能力。