Harness Engineering（AI Agent）：不是搭好就不动的OS，而是持续的拆建循环
一、主流叙事漏掉了什么
2026年初，"Harness Engineering"成为AI工程领域的核心概念。Phil Schmid把它比作操作系统——模型是CPU，harness是OS；Aakash Gupta说模型是引擎，harness是整辆车。这些类比方向对了，但都少了一个关键维度：时间。
它们把harness画成一个搭好就能用的静态架构层。但实践中发生的事情完全不是这样。
真正的harness不是"围绕模型搭建一套固定系统"，而是一个持续的拆建循环：
模型变强 → harness中补偿弱点的部分变冗余 → 拆掉冗余 → 模型获得更干净的上下文 → 表现进一步提升 → 腾出空间探索新能力边界上的新harness设计 → 模型再变强 → 再拆... 这不是架构设计，这是共演化。
二、一个真实案例：从Opus 4.5到4.6的harness蜕变
Anthropic Labs的Prithvi Rajasekaran在2026年3月24日发表的工程博客，用一个完整案例展示了这个过程。
2.1 起点：为Opus 4.5搭建的完整harness
初始问题很明确：让Claude自主构建完整的全栈应用。单agent跑不好，所以团队搭了一套三agent架构：
| Agent | 职责 | 存在理由 |
|---|---|---|
| Planner | 将1-4句话的用户需求展开为完整产品规格 | 模型独自面对模糊需求时会欠规划 |
| Generator | 按sprint逐个实现功能 | 模型在长任务中容易跑偏 |
| Evaluator | 用Playwright实际操作应用、打分、写bug报告 | 模型自评时倾向于自我表扬 |
harness还包含两个关键的结构性补偿：
- Sprint分解：把整个构建拆成小块，每个sprint只做一个功能。因为Sonnet 4.5在长上下文中容易失去连贯性。
- Context reset：每个sprint之间完全清空上下文窗口、启动新agent，通过结构化的handoff artifact传递状态。因为Sonnet 4.5有"上下文焦虑"——当它感知到上下文窗口快满时，会过早地开始收尾工作。仅靠compaction（压缩历史）不够，必须给它一张"白纸"。
这套harness有效。用同一个prompt（“做一个2D复古游戏编辑器”），solo agent用20分钟/$9生成了一个核心功能损坏的半成品；完整harness用6小时/$200生成了一个功能齐全、可实际游玩的应用。
但这里的关键不是"harness有多好"，而是harness中的每一个组件都编码了一个假设——关于模型当前做不到什么。
2.2 Opus 4.6发布：假设失效，开始拆
Opus 4.6带来了更强的长任务持续能力、更好的自我纠错、更可靠的大代码库操作。这意味着harness中的某些补偿逻辑不再承重了。
作者的第一反应是激进地一次砍掉所有复杂结构。失败了——无法判断哪些是真正冗余的、哪些仍在起作用。
于是改为逐个组件移除，观察对结果的影响：
拆掉sprint分解 ✅
Opus 4.6能连续编码两个多小时不跑偏。sprint结构从"必要的补偿"变成了"不必要的开销"。拆掉。
拆掉context reset ✅
Opus 4.6的上下文焦虑基本消失。不再需要完全清空重启，SDK的自动compaction就够了。拆掉。
重新定位evaluator ⚠️ 部分保留
这个最微妙。evaluator不是简单的"需要/不需要"，而是取决于任务相对于模型当前能力的位置：
- 模型已经能独立做好的任务 → evaluator变成了冗余开销
- 仍处于模型能力边界的任务 → evaluator继续提供实质性提升
所以evaluator从"每个sprint后必检"变成了"最后统一检查一次"，其价值变成了动态的、随模型能力边界移动的。
2.3 拆完之后：不是更简单了，而是移动了
拆掉sprint和context reset之后，harness变轻了。但作者没有就此止步——他把腾出来的空间用于探索新的harness设计：
- 给planner加入了前端设计skill的读取能力，让规划输出包含视觉设计语言
- 给generator加入了在应用中构建AI agent的能力（用工具驱动应用自身功能）
- 让generator和evaluator在每次构建前协商sprint合约——在写代码前先就"什么算完成"达成共识
最终结果：用一句话prompt（“在浏览器中构建一个全功能的DAW”），harness在约4小时内生成了一个可工作的数字音频工作站——有编曲视图、混音器、播放控制，甚至可以通过内置的AI agent用自然语言来作曲。
三、为什么"静态OS"类比会误导你
3.1 它暗示了一个错误的稳态
"模型是CPU，harness是OS"暗示一旦OS设计好了，CPU在里面跑就行。但实际上：
- CPU每几个月换一代
- 每换一代，OS中一些驱动/补丁就变得多余
- 如果不拆，旧的补偿逻辑反而会降低新CPU的性能（多余的context、冗余的约束、不必要的分解步骤）
- 同时，新CPU的能力又打开了OS之前不可能实现的新功能空间
3.2 它掩盖了"拆"的重要性
harness工程一半的工作不是搭建，而是识别和移除不再承重的组件。Vercel的案例是另一个证据——他们砍掉了agent 80%的工具，结果性能反而更好。工具更少 = 决策更少 = token更少 = 成功率更高。
搭建需要工程能力，拆除需要判断力——判断哪些假设已经被模型能力的增长所淘汰。
3.3 它把harness设计变成了一次性工作
如果harness是OS，那设计好就交付了。但真实的harness是一个需要持续维护的活系统——每次模型更新都是一个信号，提示你回去检查哪些组件还在承重。
Anthropic文章中的做法是：每次新模型发布后，逐个组件移除并观察影响，这本身就是一套工程方法论。
四、更准确的心智模型：共演化的适应层
与其说harness是OS，不如说它是一个不断被模型能力吃掉、又不断在新边界上重新生长的适应层。
模型能力边界 ←──────────────────────────────→ ████████████████░░░░░░░░░░░░░░░ 时间点 T1 ↑ 模型能力 ↑ harness补偿 ████████████████████████░░░░░░░ 时间点 T2 (新模型) ↑ 模型吃掉了旧harness ↑ 新harness在新边界上生长 ████████████████████████████░░░ 时间点 T3 (更新模型) ↑ 又吃掉一层 ↑ 又在更远的边界上生长 每一轮：
- 模型能力向右扩展，吞噬掉之前需要harness补偿的区域
- 旧harness组件变成冗余，需要被识别和拆除
- 新的能力边界暴露出新的gap，需要新的harness设计来填补
- 拆掉冗余本身也改善了模型表现（更干净的上下文、更少的干扰）
这个过程没有终点。它会持续下去，直到模型能力覆盖了你关心的整个任务空间——而以目前的发展速度，那个边界一直在外移。
五、下一步：从共演化到共训练
上面描述的拆建循环，harness和模型仍然是两个独立演化的东西——模型发布了，工程师再去调harness。但现在正在发生的趋势更激进：harness正在被折叠进模型的训练过程本身。
5.1 已经在发生的事
前沿模型已经在对自己的harness做post-training（后训练微调）。模型不仅在通用语料上训练，还在它将要被部署的那套harness环境中做强化学习和对齐。
这意味着模型的行为已经为特定harness做了适配：
- Claude在Claude Code的harness中被后训练，它"知道"Claude Code的工具调用协议、文件操作模式、compaction机制
- OpenAI的Codex模型与Codex harness的
apply_patch工具紧密耦合——耦合到什么程度？开源替代品OpenCode专门为Codex模型加了一个模仿Codex harness的apply_patch工具，因为用标准的edit/write工具时Codex模型表现会变差
这不再是"模型 + 外部OS"的关系。这更像是模型和harness在训练阶段就已经长在了一起。
5.2 这意味着什么：框架+模型的捆绑发布
顺着这个趋势往前看，未来的发布形态可能不再是"新模型"，而是 “新模型 + 与之共训练的harness版本” 。比如：
Claude Code 2.0 + Claude 5.0 ← 共训练、深度适配 Claude Code 2.0 + GPT-5.4 ← 能跑，但效果差一截 Claude Code 2.0 + Gemini 3 ← 能跑，但效果差更多 就像iPhone的芯片和iOS是协同设计的——A系列芯片在别的OS上跑不出同样的性能，iOS在别的芯片上也跑不出同样的体验。模型和harness的关系正在走向同样的垂直整合。
5.3 对拆建循环的影响
这给前面描述的共演化过程加了一个新维度：
| 阶段 | harness与模型的关系 | 拆建循环的性质 |
|---|---|---|
| 早期（2024-2025） | 完全独立。harness是外部脚手架 | 工程师手动调整，模型无感知 |
| 当前（2026） | 开始耦合。模型在特定harness中后训练 | 拆建时需考虑模型的训练偏好 |
| 趋势 | 深度共训练。框架+模型捆绑发布 | harness的设计选择反向影响下一轮模型训练 |
在早期阶段，你可以自由地给任何模型套任何harness。在当前阶段，最优harness已经不是模型无关的了——同一个harness在不同模型上的效果差异越来越大，因为模型的后训练已经对特定harness做了隐式优化。
5.4 这不是锁定，是分层
需要区分两件事：
- 产品层的垂直整合：Claude Code + Claude模型的深度适配，这是各厂商的竞争壁垒
- 协议层的开放标准：MCP（Model Context Protocol）、Agent SDK这样的接口规范，让不同的harness和模型之间仍然可以互操作
现在的格局是：底层协议开放（你可以用MCP接任何模型），但最优性能路径是垂直整合的（Claude Code + Claude模型 > Claude Code + 其他模型）。这跟Android生态类似——任何厂商都能做Android手机，但Pixel + 原生Android的体验往往最流畅。
5.5 对工程师意味着什么
- 选harness越来越等于选模型。当你决定用Claude Code作为你的开发harness，你实质上也在选择Claude作为你的主力模型——因为它们是共训练的，分开用会损失性能。
- 拆建循环不再是单边的。以前是"新模型来了，调harness"；未来可能是"新的harness设计被验证有效 → 反馈到下一轮模型训练 → 新模型发布时自带对这种harness模式的原生支持"。
- "模型无关"的harness仍有价值，但它的定位会从"最优性能"转向"灵活性和避免锁定"。这是一个需要主动做的权衡选择。
六、实践指南：如何做拆建循环
6.1 新模型发布时的检查清单
对harness中的每个组件，问三个问题：
| 问题 | 如果答案是"是" |
|---|---|
| 这个组件补偿的是模型的哪个弱点？ | 去测试新模型是否仍有这个弱点 |
| 去掉它后，输出质量下降了吗？ | 保留，它仍在承重 |
| 去掉它后，输出质量不变或变好了？ | 拆掉，它已是冗余开销 |
关键方法：不要一次性砍掉所有组件（Anthropic团队试过，失败了），而是逐个移除并观察影响。
6.2 什么时候加新组件
当你观察到模型在某个新的能力边界上反复失败时：
- 模型能生成完整应用但UI缺乏设计感 → 加入evaluator + 设计评分标准
- 模型能写代码但不会自主测试 → 加入Playwright驱动的QA agent
- 模型能规划但规划过于保守 → 加入planner并提示它追求更大scope
6.3 如何判断harness是否过重
三个信号：
- 模型表现不升反降：过多约束反而限制了模型发挥——Vercel砍工具后性能变好就是典型案例
- token成本异常高：大量token花在了harness的编排开销上，而非实际任务
- 新模型发布后性能没有预期的提升：旧harness可能在"锁住"新模型的能力
6.4 一条核心原则
来自Anthropic的"Building Effective Agents"：
找到最简单的可行方案，只在必要时增加复杂度。
这不仅适用于初始设计，更适用于持续维护。harness的默认状态应该是"尽可能轻"，每个组件都需要持续证明自己的存在价值。
七、结语
Prithvi Rajasekaran在文章末尾的判断值得记住：
有趣的harness组合空间不会随着模型改进而缩小——它会移动。AI工程师的工作在于不断找到下一个新颖的组合。
这才是harness engineering的真正含义：不是搭建一个固定的基础设施，而是在模型能力的移动边界上持续做适应性设计。搭建是一半，拆除是另一半。识别什么该拆，跟知道什么该建一样重要——甚至更重要。
参考来源：
- Prithvi Rajasekaran, “Harness design for long-running application development”, Anthropic Engineering, 2026-03-24
- Philipp Schmid, “The importance of Agent Harness in 2026”, 2026-01-05
- Martin Fowler, “Harness Engineering”, 2026-02-17
- OpenAI, “Harness engineering: leveraging Codex in an agent-first world”, 2026
