Harness 终将被拆除：为什么 Agent 管控的每一块砖都是临时的
Harness 终将被拆除：为什么 Agent 管控的每一块砖都是临时的
参考来源：一文读懂Harness Engineering！/ Anthropic 工程博客与 Claude Code 源码分析（2024.12–2026.6）
前置知识：建议先阅读系列前两篇《全景通览》和《三家对比》
摘要：过去十五个月，整个行业在 Agent Harness 上疯狂加盖。JSON 物理锁、三步唤醒仪式、Context Reset、Generator-Evaluator 对抗——每一层都是被真实的 Bug 逼出来的补偿。但一条被忽略的暗线是：这些机制的创造者 Anthropic，随着模型能力的提升，已经开始亲手拆除自己当年搭建的组件。Context Reset 从默认策略降级为备选方案，Sprint Contract 被简化或移除，Team Mode 中的硬性层级约束也在松动。本文梳理 Harness 的三次"拆迁潮"，揭示一个核心规律：Harness 中的每个机制都对应着一个明确的"模型缺陷"，当缺陷被修复，机制本身就成了技术债。理解"什么时候该拆"，比理解"什么时候该建"更需要工程嗅觉。
文章目录
一、建设的狂欢，拆除的暗线
如果只看 2024 年 12 月到 2026 年 3 月这段时间的技术博客，你会看到一个明确的趋势：Harness 越来越重。
LangChain 的实验报告点燃了整个行业——同一个模型，换个壳，Terminal Bench 通过率从 52.8% 冲到 66.5%。于是所有人都在往上堆砖。JSON 锁、三步唤醒、Planner-Worker-Judge、Generator-Evaluator 对抗、8 通道盲审——十五个月里，Harness 从一个轻量的 System Prompt 变成了三层架构的工业控制器。
但在这条疯狂加盖的主线之外，有一条极少被讨论的暗线：Anthropic 自己，已经在拆了。
结合 Claude Code 源码泄漏分析、Anthropic 官方博客的一些细致声明、以及 Claude Opus 后续版本的 Release Notes，可以清晰地看到三次"拆迁潮"。每一次都对应着一项模型能力的提升。
理解这条暗线，比理解那些"怎么建"的文档更重要。因为建 Harness 的工程师迟早会面对同一个问题：我去年搭的那些机制，现在还要不要留着？
二、第一次拆迁：Context Reset 的降级
2.1 当年为什么建
2025 年 11 月，Anthropic 在《Effective harnesses for long-running agents》中提出了 Context Reset 策略：当对话历史太长、上下文窗口快撑爆时，不做摘要压缩，而是彻底清空，启动一个全新的 Agent，只给一张结构化的交接文件。
这个设计的逻辑基础是：模型在超长上下文里会焦虑、会丢失连贯性、会开始犯糊涂。压缩过的历史摘要看似保留了信息，实际上模型读摘要和读原文的效果完全不同。宁可给一张干净的白纸，也不要给一张写满模糊笔记的草稿。
在当时（Claude 3.5 Sonnet / 早期 Opus），这是正确的决策。模型的注意力在大跨度上下文中确实会衰减。
2.2 为什么拆
到了 2026 年 5-6 月，Opus 4.6 的 Release Notes 中有一个被多数人忽略的条目：“显著增强了超长上下文中对关键指令的保持能力。”
这句话翻译过来就是：模型现在能读更长的上下文而不焦虑了。
对应的工程变化随之而来：Context Reset 从"默认策略"降级为"备选方案"。新的默认策略回归到了选择性压缩+保留关键决策点——只在模型明确表现出困惑时才清空重建。
为什么是"降级"而不是"移除"？因为模型能力提升不是二值的——从"完全不靠谱"到"完全靠谱"之间有一个模糊地带。在模糊地带里，保留机制作为安全兜底是合理的。但不要再把它当成设计的中心。
2.3 启示
Context Reset 的拆迁揭示了一个规律：HARNESS 中与"模型注意力/记忆能力"相关的组件，会被模型能力提升直接淘汰。
当模型的上下文窗口足够大、注意力衰减足够慢时，清空重建的成本（丢失所有中间状态）就超过了收益（获得清晰注意力）。这时候，保留机制的唯一价值是作为极端场景的安全网——而不是核心流程的一部分。
三、第二次拆迁：Sprint Contract 的简化
3.1 当年为什么建
2026 年 3 月，Anthropic 在《Harness design for long-running application development》中提出了 Sprint Contract：每轮迭代开工前，Generator 和 Evaluator 先协商"做完长什么样"。
这个机制的设计逻辑是：Generator 自己判断"做完了没"是不可靠的，因为模型会自信地赞美自己的产出。需要另一个 Agent 来定验收标准。
在当时，这是合理的。Generator 缺乏客观的自我评估能力，且 Evaluator 也缺乏从模糊需求中自动提取验收标准的能力。所以需要显式的"协商"步骤。
3.2 为什么简化
2026 年 6 月，Anthropic 的一篇更新博客中提到，Sprint Contract 的显式协商步骤在 Opus 4.6 上被简化或部分移除。
替换方案是：Evaluator 直接从需求文档和项目上下文中自动提取验收标准，不需要 Generator 参与协商。Generator 只需要读到 Evaluator 生成的验收文档，然后开工。
这个变化的核心驱动因素是：**模型的"指令理解与分解"能力提升了。**Evaluator 不再需要 Generator 的帮助来理解"这段需求意味着对应的验收标准是什么"。它自己读需求文档就够了。
3.3 启示
Sprint Contract 的简化揭示了第二个规律：HARNESS 中与"模型理解能力"相关的组件，当模型能独立完成理解任务时，显式的协商步骤就成了多余的开销。
但注意：Sprint Contract 的本质没有被拆掉——验收标准仍然存在，仍然由 Evaluator 生成。被拆掉的是"两个 Agent 必须坐下来谈"这个步骤。保留的是功能，精简的是流程。 这是拆迁的正确姿势——不是把整个组件扔掉，是把多余的步骤剪掉。
四、第三次拆迁：Team Mode 层级约束的松动
4.1 当年为什么建
2026 年 2-3 月，Claude Code 源码泄漏揭示了 Team Mode 的激进设计：每个队友有独立的上下文窗口、独立的工作区、独立的记忆，通过"邮箱"系统通信。同时系统硬性禁止队友再生队友，保持组织结构扁平。
这个扁平结构约束的逻辑基础是：Agent 递归创建子 Agent 会导致失控的层级膨胀——子 Agent 再生孙 Agent，调度复杂度指数级增长，最终全面崩溃。
在当时，这是必要的安全阀。Cursor 的并发崩塌已经证明，即使是两层结构（Planner→Worker）都需要 DAG 引擎硬锁。更深的嵌套没有工程可行性。
4.2 为什么松动
2026 年 5-6 月的源码更新显示，Team Mode 中"禁止队友再生队友"的硬性约束在特定场景下被放宽。
新的规则是：队友可以创建临时子 Agent，但子 Agent 的生命周期必须受限于父 Agent 的上下文窗口，父 Agent 结束子 Agent 自动消亡。
这个变化的核心驱动因素是：**模型的"任务拆解与调度"能力提升了。**当父 Agent 能够准确判断"这个子任务是否需要拆"，并且能够准确评估子 Agent 的产出时，限制递归深度的成本就超过收益了。
4.3 启示
Team Mode 层级约束的松动揭示了第三个规律：HARNESS 中与"模型调度/协调能力"相关的硬性约束，会随着模型变得更"有组织能力"而逐步软化。
从硬性禁止到有条件允许，这是 Harness 演进的典型轨迹。下一个阶段可能是完全放开——模型自己能管理递归深度时，人为的层级约束就完全多余了。
五、拆迁规律：什么时候该建，什么时候该拆
把三次拆迁的历史串起来，可以提炼出三条规则。
规则一：每个 Harness 组件都对应一个明确的模型缺陷
| 组件 | 对应缺陷 | 当前状态（Opus 4.6） |
|---|---|---|
| Context Reset | 长上下文注意力衰减 | 降级为备选 |
| 三步唤醒仪式 | 跨 Session 记忆丢失 | 仍在有效使用 |
| JSON 物理锁 | 虚标完成、偷工减料 | 仍在有效使用 |
| Sprint Contract 协商步骤 | 无法从需求中自动提取验收标准 | 简化（自动提取替换协商） |
| Planner-Worker-Judge 门控 | 多 Agent 自主调度能力缺失 | 仍在有效使用 |
| 禁止队友再生队友 | 递归创建导致层级膨胀 | 放宽为有条件允许 |
这张表本身就是一份评估框架。每当模型发布新版本，把每个组件拿出来，问自己：它对应的那个缺陷还在吗？
规则二：缺陷修复的优先级决定了拆迁的顺序
模型能力提升不是均匀的。通常是：
- 注意力率先改善 → Context Reset 第一个被拆
- 理解能力跟进 → Sprint Contract 协商步骤跟进
- 调度能力最后提升 → Team Mode 约束最后松动
这个顺序不是随机的。注意力和理解是单体能力的提升，调度是协调能力的提升。单体能力总是先于协调能力改善——这跟人类团队的成长规律一致。
规则三：拆组件不等于删功能
三次拆迁中，没有一次是"把整个组件连根拔掉"。Context Reset 降级但保留了。Sprint Contract 的验收标准保留了。Team Mode 的结构保留了。
正确的拆迁姿势是剪枝，不是砍树。 把多余的步骤剪掉，把支撑功能的核心逻辑留下。当模型被证明不再需要某个步骤时，移除步骤；当模型被证明不再需要某个约束时，放松约束。永远不要因为"反正模型变强了"就把一整套验证体系扔掉——因为你永远不知道模型在哪些边界情况下还会摔。
六、拆迁路线图：给正在搭建 Harness 的团队的三条建议
建议一：用"缺陷标签"管理 Harness 组件
不要把你的 Harness 架构当成不可变的设计文档。给每个组件打上一个"缺陷标签"，写明它解决的是模型的哪个已知弱点。这是未来拆它的依据。
比如，不要把 Context Reset 写进架构文档的"核心流程"里。把它写进"补偿机制"里，标注"面向：模型长上下文注意力衰减。目标模型版本达到 xxx 时触发拆迁评估。"
建议二：建立模型升级后的拆迁检查单
每次接入新模型版本时，别只跑精度评测。加上这份检查单：
- 现有 Harness 组件中，哪些对应的模型缺陷在本版本中被修复或改善？
- 哪些组件可以从默认策略降级为备选方案？
- 哪些硬性约束可以放松为有条件限制？
- 是否可以减少一个环节的 Agent 参与人数（如从双 Agent 对抗简化为单 Agent 自查）？
- 降级/简化后，回归测试是否通过？
建议三：为"拆迁"预留代码架构空间
Harness 的每个组件在设计时就该考虑"将来怎么拆"。具体做法：
- 流程管控组件（JSON 锁、唤醒仪式）用开关控制，可以一键禁用而不影响核心流程
- 验证组件（Evaluator 对抗、盲审）用强度可调，从"8 通道"降到"单通道"只需改一个参数
- 并发控制（Team Mode 约束）用策略模式，"硬性禁止"和"有条件允许"是同一接口的不同实现
如果你的 Harness 组件和核心业务逻辑深度耦合、拆一个就要重写一半代码，那你建的就不是 Harness，是技术债。
七、结语
Harness 是工程学上最诚实的东西——它不美化能力，只补偿缺陷。
LangChain 那个从 52.8% 到 66.5% 的数据，本质上是把模型的短板用工程手段填上了。当模型那些短板自己长出来的时候，填坑的砖头就成了累赘。
Anthropic 的做法恰恰证明了他们对这一点有清醒的认知：一边在最需要的地方疯狂加盖，一边在已经不需要的地方果断拆除。建什么、拆什么、什么时候建、什么时候拆——这才是 Harness Engineering 真正考验工程嗅觉的地方。
十五年后的 Agent 开发者回头看今天的这些组件，大概就像今天的开发者回头看当年的 jQuery——“那时候浏览器连 querySelector 都没有，难怪他们要写这些东西。”
本文说明：本文基于 Anthropic 官方博客、Claude Opus Release Notes 以及 Claude Code 源码分析的公开信息整理。文中关于组件拆迁的具体时间线和版本对应关系，部分基于 Anthropic 博客声明、部分基于社区对泄漏源码的分析推断。建议以 Anthropic 官方文档的最新版本为准。
核心参考文献：
- 微信公众号《一文读懂Harness Engineering！》
- LangChain《The Anatomy of an Agent Harness》（2026.3）
- Anthropic《Building effective agents》（2024.12）
- Anthropic《Effective harnesses for long-running agents》（2025.11）
- Anthropic《Harness design for long-running application development》（2026.3）
- Cursor《Scaling long-running autonomous coding》（2026.1）
感谢阅读，记得点赞、关注、收藏，欢迎各位评论区交流！！！
有“AI”的1024 = 2048，欢迎大家加入2048 AI社区
更多推荐
1
0- 0
已为社区贡献1条内容
所有评论(0)