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 中的每个机制都对应着一个明确的模型缺陷当缺陷被修复机制本身就成了技术债。理解什么时候该拆比理解什么时候该建更需要工程嗅觉。文章目录Harness 终将被拆除为什么 Agent 管控的每一块砖都是临时的一、建设的狂欢拆除的暗线二、第一次拆迁Context Reset 的降级2.1 当年为什么建2.2 为什么拆2.3 启示三、第二次拆迁Sprint Contract 的简化3.1 当年为什么建3.2 为什么简化3.3 启示四、第三次拆迁Team Mode 层级约束的松动4.1 当年为什么建4.2 为什么松动4.3 启示五、拆迁规律什么时候该建什么时候该拆规则一每个 Harness 组件都对应一个明确的模型缺陷规则二缺陷修复的优先级决定了拆迁的顺序规则三拆组件不等于删功能六、拆迁路线图给正在搭建 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.6Context 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.3Anthropic《Building effective agents》2024.12Anthropic《Effective harnesses for long-running agents》2025.11Anthropic《Harness design for long-running application development》2026.3Cursor《Scaling long-running autonomous coding》2026.1感谢阅读记得点赞、关注、收藏欢迎各位评论区交流