解读《Harness design for long-running application development》：当模型越来越强，Harness 设计的重点正在发生变化
原文：Harness design for long-running application development
Anthropic 这篇文章表面上讨论的是 long-running application development，涉及多 agent、评估器、任务分阶段推进与长时间 autonomous coding。 但如果仅将其理解为一篇“多 agent 工程实践总结”，就会低估其真正的方法论价值。
更准确地说，它讨论的重点并不是“如何把流程做得更复杂”，而是：
当模型能力持续增强之后，工程系统里哪些结构仍然有价值，哪些结构需要重新评估，甚至被删除。
这正是全文最值得关注的部分。
一、文章真正关心的，不是“怎么加流程”，而是“什么流程还值得保留”
在今天的 agent engineering 讨论中，常见的一种直觉是： 任务复杂了，就增加更多 prompt； 流程不稳了，就增加更多角色； 结果不理想，就补充更多规则和文档。
但最重要的一点在于，它并没有把复杂度本身当成答案。恰恰相反，Anthropic 反复强调的是一种成熟的工程判断：
任何 harness 组件，都只是为了弥补模型某一类现实缺陷。既然如此，这些组件就不应该被神圣化，而应该被持续验证。
这种判断意味着：没有哪种复杂结构天然正确，它们只是特定阶段的临时补偿机制。 一旦模型能力发生变化，旧的补偿机制就必须被重新审视。
二、长任务里的真正问题，不只是不会做，而是会逐渐失真
它并没有停留在“多 agent 能提升效果”这种笼统结论，而是明确拆出了长任务里的几个核心失真来源。
第一类失真：长时间工作中的连贯性衰减
模型在短任务里常常显得很强，但一旦任务拉长、阶段增多、上下文变厚，就会出现一种非常典型的问题： 它并不是突然崩掉，而是开始慢慢偏离。
这种偏离往往不是显式失败，而是逐步失真：
- 开始忘记最初目标
- 开始对中间状态产生误判
- 开始过度乐观地判断完成度
- 开始用“已经差不多了”的语气掩盖尚未完成的工作
也就是说，长任务最难的部分，并不只是执行力，而是保持判断力。
第二类失真：自我评估的宽松化
Anthropic 对这一点的识别也非常准确： 让模型评价自己，几乎天然会出现偏宽松的问题。
这并不只是主观任务里的问题。 即便在那些表面上可验证的任务中，模型也很容易对自己的中间产物产生一种“解释性满足”——它能够解释为什么自己好像做对了，于是更容易接受一个并不真正稳固的结果。
这说明：
很多系统失败，并不是因为没有生成能力，而是因为缺少一个足够独立、足够严格的纠偏视角。
也正因为如此，Anthropic 提出的 generator / evaluator 分离，真正补的不是“执行能力”，而是“判断结构”。
三、最重要的贡献，是把“评估”从附属动作变成了系统核心
如果从全文中抽出最关键的一根主线，可以概括为：
在复杂任务中，评估不是收尾动作，而是系统主干。
过去很多工程流程默认一种结构： 先生成，再看结果。 评估更像最后一步的检查。
但 Anthropic 隐含提出的是另一种理解：
- 生成只是提出候选结果
- 评估决定系统朝哪个方向继续优化
- 真正限制系统上限的，往往不是不会生成，而是不会严格判断
换句话说，在复杂任务里，评估质量本身就是生产力。
因此，这篇文章不能简单看作“多 agent 成功案例”。 它更像是在说明：
对于长程任务，系统设计的重心，应该从“怎么把东西产出来”，转向“怎么建立一个能持续纠偏的结构”。
这是一个非常本质的重心转移。
四、它没有把“规划”理解成写更多东西，而是理解成降低偏差
文中另一个关键角色是 planner。 但 planner 的意义，绝不是多生成一层材料，更不是为了让流程显得完备。
planner 真正解决的问题只有一个： 在执行开始前，先降低任务理解层面的偏差。
这一点非常值得区分。
很多系统一谈规划，就容易不自觉地滑向“写更多、更完整、更细致的说明”。 但它给出的方向不是“规划文档最大化”，而是“目标理解误差最小化”。
这里的关键不在于写了多少，而在于是否完成了几件真正有价值的事：
- 把模糊需求转成明确目标
- 把范围定义清楚
- 把阶段性目标组织出来
- 把后续执行不该过早锁死的部分留出弹性
这说明 Anthropic 对“规划”的理解其实是相当克制的。 它不是把前置产物当成价值本身，而是把前置产物看作一种降低偏差的工具。
五、真正成熟的地方，不在于构建了复杂系统，而在于后面开始主动做减法
如果只看文章前半部分，很容易觉得它是在展示一套强大的复杂架构。 但后半部分才真正体现出它的方法论成熟度。
原因在于，它没有停留在“已经做出了一套复杂系统，所以这套系统很先进”的满足感里，而是继续追问：
现在模型更强了，那么之前这些组件还有多少是真正承重的？
这个问题极其关键。
工程里最危险的，不是简单，而是过时的复杂性。 一种结构一旦被证明有效，就很容易变成惯性； 而惯性一旦形成，人们就会下意识地把它当作“必要条件”。
它的价值，恰恰在于它没有把旧成功经验制度化，而是主动怀疑：
- 这个分阶段结构现在还必要吗？
- 这个中间层现在还承重吗？
- 这个评估频率还值这个成本吗？
- 这部分复杂度是为了质量，还是只是历史遗留？
这其实是在提醒所有做 agent system 的人：
好的 harness，不是不断长出来的，而是不断被重测、被修剪出来的。
六、最值得吸收的，不是它的流程形状，而是它的判断原则
阅读这类文章时，最容易出现的误区是模仿“外形”：
- 看到三 agent，就也搭三 agent
- 看到 planner，就也加 planner
- 看到 evaluator，就也补 evaluator
- 看到多轮迭代，就也做多轮循环
但如果只模仿结构，而不吸收判断原则，最终往往会把一篇很成熟的工程文章，学成一套僵硬模板。
这篇文章真正值得迁移出去的，不是具体编排，而是几条底层判断。
1. 复杂任务的首要敌人不是不会生成，而是逐步跑偏
因此系统必须有纠偏机制，而不是只堆生成能力。
2. 自评天然不可靠
因此高价值的不是“让模型更自信”，而是给它一个足够独立的判断视角。
3. 规划的意义是降低偏差，而不是堆厚中间产物
因此前置结构应该服务于清晰度，而不是服务于形式完整。
4. 长程系统不能只依赖对话连续性
它必须依赖更稳固的结构化中间状态，来承接工作进展与判断依据。
5. 每个结构都必须被重新验证
模型变了，边界就变了；边界变了，旧结构的性价比也就变了。
七、未来的工程重点会从“生成组织”转向“反馈组织”
过去谈 AI coding，最关心的是“怎么让它写”。 但随着模型本身越来越会写，真正的瓶颈开始转移了。
未来更难的，可能不再是“怎么组织生成”，而是：
- 怎么组织反馈
- 怎么组织验收
- 怎么组织纠偏
- 怎么组织判断
- 怎么组织长时间运行中的状态稳定
换句话说，未来系统设计真正要优化的，未必是“如何让模型多产出一点”，而是：
如何让模型更早发现自己哪里还不对，如何让系统更低成本地把这种偏差持续暴露出来。
Anthropic 把焦点从“生成链路”挪到了“反馈闭环”。
这一点，比表面上的多 agent 架构更重要。
八、不要迷信复杂，但也不要误解简单
随着模型变强，系统设计的目标不再是不断往外搭脚手架，而是保留那些真正能减少偏差、提升判断质量、维持长程稳定性的少数关键结构。
这句话里有两个容易被忽略的部分。
第一，不要迷信复杂
复杂结构不是能力本身。 它只是某个阶段对模型短板的临时外置补偿。
第二，也不要误解简单
“做减法”不等于“不要结构”。 真正成熟的减法，是删掉不再承重的部分，把系统压缩到高信息密度、高反馈质量、高判断强度的状态。
这和偷懒式的简单不是一回事。 前者是提纯，后者是放弃。
九、最后总结：最重要的不是它做了什么，而是它如何判断“什么还值得做”
用一句话概括最深层的价值，可以这样表述：
它不是在教人如何把 agent 流程做得更重，而是在示范一种更成熟的工程判断：随着模型能力变化，持续识别系统中真正承重的结构，并把复杂度收缩到仍然有实际收益的那部分。
这也是为什么，这篇文章真正值得反复阅读的，不是它的架构图，而是它背后的立场：
- 不把流程神圣化
- 不把复杂等同于高级
- 不把旧经验误认成永久真理
- 关注长任务里的失真来源
- 把评估和反馈当成核心能力
- 用持续删减来逼近更高性价比的系统形态