2025 年初 Manus 突然爆火，邀请码一码难求，二手市场标价甚至上万。它的演示视频展示了，AI 像真人一样操作电脑，独立完成筛选简历、房产调研、金融分析这类复杂任务，首次让人感受到“Agent 时代”的来临。 当知道它使用的是第三方模型时，被一些人嘲讽：“套壳，没技术含量”。而这个“壳”，现在值20亿美金（25年底被 Meta 收购），也有个正式的名字——Harness。
Harness 这个单词本身的主要意思是马具、挽具，让马载人或拉车时给它配的那一套绳索系统。在 AI 领域，原始模型就很像那匹马，比人跑得又快又远，但没法直接应用到生产，所以需要用 Harness 把它包起来，让它完成具体的生产任务。
LangChain（开源 Agent 开发框架）在《The Anatomy of an Agent Harness》里给出了一个公式：
Agent = Model + Harness
If you're not the model, you're the harness.
如果你不是模型本身，那你就是 harness 。Harness 是除了模型之外一切代码、配置、执行逻辑的总和，具体赋予模型四样东西：
- 状态：让模型记得自己上一步做了什么、还有什么没干完；
- 循环：让模型可以反复“想—做—验证—再想”，而不是一锤子买卖；
- 工具：让模型能伸手到文件系统、浏览器、外部 API、代码解释器等；
- 约束：用确定性的代码硬性规定“什么能做、什么不能做、什么必须先通过校验”。
模型大多数情况下只是接收一段文字，输出一段文字，真正干活时会遇到以下问题：
- 在哪里执行？
- 有哪些工具可用？
- 能访问什么？
- 如何验证结果？
- 能记住什么？
这些问题靠“更强的模型”、“更长的上下文”没法解决，它们是工程问题，不是智能问题。
Harness 的解决方案：
- 在哪里执行？ ——提供受控的执行环境：沙盒、工作目录、虚拟机
- 有哪些工具可用？ ——提供内置工具，添加 Skill，连接 MCP
- 能访问什么？ ——设置操作权限、网络白名单、文件边界
- 如何验证结果？ ——强制执行 linter、单测、关键节点人工审核
- 能记住什么？——上下文与记忆管理
本质上是用确定性的工程，给 AI 配上手脚，并约束其行为，使它能在真实业务场景可靠地干活。 从工程角度说来说，是把任务从“做对一次”变成“次次做对”、“换模型也能做对”。
Harness 全貌 Harness 概念已经流行了大半年，以下是 AI 帮我搜索的一些了解 Harness 的优质文章：
- LangChain 《The Anatomy of an Agent Harness》——凡是不属于模型本身的代码、配置和执行逻辑，都是 Harness
- Anthropic 《Harness Design for Long-Running Apps》 和 《Effective Harnesses for Long-Running Agents》——侧重多 Agent 架构和长任务的状态外部化
- OpenAI 《工程技术：在智能体优先的世界中利用 Codex》——讲他们怎么靠 Harness 让 Codex 写了 100 万行代码
- Birgitta Böckeler 《Harness engineering for coding agent users》——好的 Harness 不一定要消除人的参与，而是把人的参与导向最需要它的地方
- Addy Osmani 《Agent Harness Engineering》——一个平庸模型 + 优秀 Harness，会跑赢一个优秀模型 + 糟糕 Harness
综合这些文章，一个完整的 Harness 可以分成六个部分：
- 控制循环 / 编排逻辑 Harness 的执行中枢，让 AI 反复想、反复做、并知道什么时候停。
- 核心循环：
while (true) {
response = 调模型(消息历史) // 模型思考
if (response 不含工具调用) {
return response // 纯文本 = 干完了，结束
}
results = 执行工具(response.工具调用) // 模型伸手做事
消息历史.push(results) // 把结果回灌，进入下一轮
}- 任务分解与子 Agent 调度：
- Anthropic 在 《Harness Design for Long-Running Apps》 里提出，把工作拆给三个子 Agent：
- 规划者（Planner） 负责”想清楚要做什么”；
- 执行者（Generator） 负责”埋头干活”；
- 评审者（Evaluator） 负责”挑毛病”，独立第三方，不合格就打回返工。
- Anthropic 在 《Harness Design for Long-Running Apps》 里提出，把工作拆给三个子 Agent：
- 生命周期 Hooks：在关键节点插入确定性逻辑；
- 执行边界：步数、成本、时间的硬上限；
- 错误处理：重试、回退策略。
- 上下文与记忆管理 上下文窗口是 RAM——快、强、但有限，外部记忆是硬盘——便宜、海量、但要主动调取。 上下文种类：
- 系统提示词：规则文件，Agent 的宪法；
- 短期记忆：消息历史；
- 长期记忆：spec 文件、知识库；
- 工作台：临时文件、草稿、中间产物。 自动压缩机制：模型的注意力是稀缺资源，上下文越长，模型的能力反而可能下降，所以要管理好模型“能看到什么，以及忘掉什么”。
- 工具与环境 让 AI 接触真实的世界——读写文件、跑代码、调工具等。
- 在哪里执行：
- 沙盒、终端、浏览器等环境；
- 能用哪些工具：
- 内置工具：bash（跑命令）、read（读）、write（写）、grep（本地搜）、web search（联网搜）等；
- Skill：封装好的技能包，按需加载；
- MCP：标准化连接外部服务。
- 权限与约束 划清“什么该做，什么不该做”红线。
- 限制模型可视范围：限定文件可访问目录，防止数据外泄；设置网络请求白名单，防止恶意网站攻击；
- 物理隔离：使用沙盒独立执行环境；
- 敏感行为唤起审批；
- 危险操作拦截。
- 验证与评估（evals） 模型本质是概率模型，结果不能保证百分百正确，而长任务里，小错会累积成大错，所以”做对”靠的不是模型自己，而是一层持续的验证与评估。 Anthropic 的 《Demystifying evals for AI agents》 讲到：没有 evals，你就是在 “flying blind（盲目飞行）”。 三级验证方案：
- 代码级：Linter、单测——便宜，稳定但能力有限；
- 模型级：自评估，或让另一个Agent 评估——相对便宜强大，但仍难逃幻觉存在，需要写好评估规则；
- 人工级：真人验收——保真度高，但贵、慢，理想情况是任务的最终验收，一次通过。 代码级高频跑，模型级部分跑，人工级关键时刻跑。
- 可观测性与恢复 Agent 执行任务出了问题，能复盘，能优化，Agent 用于生产的最后一公里。
- 全链路 tracing：记录每一次工具调用、模型回复、错误的完整日志；
- **成本与性能指标：**记录耗时、Token、金额，让“烧钱”看得见，可管理；
- 故障恢复：断点续跑、工具失败重连、环境崩溃恢复，不用从头再来；
- 跨会话生命周期：长任务能暂停、迁移、人工接管，增加灵活性。
Agent + Harness = 更好用的 Agent Birgitta Böckeler 在 《Harness Engineering for Coding Agent Users》 对 harness 有个划分：
- 内层（Inner harness）：Cursor、Claude Code、Codex 等 Agent 产品已经做好的部分——系统提示词、上下文管理、子 Agent 编排等；
- 外层（Outer harness）：根据团队规范、具体业务、个人习惯等，在代码库或本地自己配的部分。 代码库和本地的 .claude/.cursor/.codex/.kiro 这些文件就是外层 Harness 配置的地方。 每次 Agent 犯错时，都可以问一下 AI：这个错误能不能沉淀成规则、hook、测试、文档或工具？让 AI 记录下来，修改外层 Harness 文件，可以避免 AI 遇到类似问题时再犯。
代码工程师 → Harness 工程师 Harness 有部分功能是为了弥补当前模型的不足，随着模型能力的提升，可能原生就更擅长规划、自我验证、长时间推理等，上下文注入需求也会减少。 这时部分 Harness 设计可能成为冗余，需要及时清理；当遇到新的业务场景，又需要更新 Harness 进行适配。 因此，日常维护 Harness 成为一项主要工作：在已有模型或 Agent 产品的基础上，打造适合当前工作环境的 Harness。