精读《Harness design for long-running application development》真正拉开差距的不是模型本身而是你怎么给它搭脚手架原文Harness design for long-running application developmentAnthropic 这篇文章最值得读的地方不是它又做出了一个“多 agent 系统”而是它把一个经常被说得很玄的命题讲清楚了当模型开始承担数小时、跨阶段、带主观判断的软件构建任务时决定上限的往往不只是模型能力而是 harness也就是你为模型设计的工作流、角色分工、反馈机制和上下文管理方式。如果把全文压缩成一句话就是不要把模型当成一个会自动完成复杂任务的万能体而要把它当成一个需要被拆分、被校准、被监督、被持续重构的生产系统。这篇文章到底解决了什么问题作者一开始面对的是两个看似不同、其实很像的问题怎样让 Claude 产出更有审美质量的前端设计。怎样让 Claude 在几小时内自主做出一个完整应用而不是半路跑偏。这两个问题的共同难点在于单个 agent 很容易在长任务里出现两类失败第一类是“长程失稳”。上下文变长后模型会逐渐失去连贯性甚至出现作者说的“context anxiety”也就是还没到极限就开始草草收尾。第二类是“自我评价失真”。模型做完一个东西后往往会高估自己的产出尤其是在设计这种没有标准答案的任务上。前者是记忆与执行控制问题后者是评价机制问题。文章的核心贡献就是分别给这两个问题配上了工程化解法。最关键的洞察把“主观好坏”改写成可评分标准作者先从前端设计入手因为这里最容易暴露模型“自卖自夸”的问题。默认情况下模型很容易做出“能用但普通”的界面安全、规整、功能没问题但没有明确气质也缺少真正的设计判断。于是作者没有直接问模型“这个设计美不美”而是把评价标准拆成四项设计质量整体是否统一是否形成明确气质。原创性有没有真实的设计决策而不是模板味和 AI 味。工艺排版、间距、配色、对比度这些基本功是否扎实。功能性用户能不能顺畅理解和使用界面。这一步非常关键。因为它说明了一个常被忽略的事实主观任务不是不能评估而是要先把“感觉”翻译成“准则”。也就是说harness 的工作不只是分配 agent更重要的是把模糊目标转成模型可以反复对齐的评分坐标系。你一旦把“好设计”从抽象审美改写成“设计质量 原创性 工艺 功能性”的组合模型就不再只是在瞎猜人类偏好而是在一个可迭代的评价空间里优化。从 GAN 得到启发但真正落地的是工程闭环文章借用了 GAN 的思路一个 generator 负责生成一个 evaluator 负责打分和批评。这个类比很好懂但更重要的是它在工程上的具体实现优化重构/转向用户目标Planner 规划需求与设计方向Generator 生成实现Evaluator 评估体验、功能与缺陷继续当前方向还是调整方向这里真正有效的不是“多 agent”这三个字而是闭环的设计generator 不负责给自己打分。evaluator 不直接写代码而是保持外部审视视角。planner 负责把一句模糊需求扩展成更完整的规格和设计语言。这相当于把人类团队里“产品规划 - 开发实现 - QA/评审”这套结构压进了模型工作流里。作者的发现也很直接让一个 agent 自我反思很难让另一个 agent 专门怀疑它反而更可控。为什么这套方法对长任务有效文章里还有一个容易被忽视但非常重要的点长时任务不是简单地“把调用时间拉长”而是要解决任务分段、状态传递和稳定性问题。Anthropic 之前的做法是通过 context reset 加结构化 handoff 来缓解上下文过长导致的失稳。这里的思想很值得记住不是一味保留更多上下文。而是敢于清空上下文再用结构化工件把必要状态交给下一个 agent。这个思路和很多人的直觉相反。很多人以为“上下文越完整越好”但作者指出压缩历史并不能完全解决模型的“上下文焦虑”。有时真正有效的不是带着旧包袱继续跑而是让新 agent 带着清晰交接重新开始。到了 Opus 4.6作者又重新评估这套 harness发现一些原本必要的结构已经不再承重于是去掉 sprint 拆分保留 planner 和 evaluator并把 QA 改为构建末尾的集中评审。这个变化背后其实是全文最成熟的工程观点harness 不是固定模板而是一个要随着模型能力变化不断删改的系统。最值得借鉴的不是“三代理架构”而是这三个工程原则读完整篇文章我觉得最值得带走的不是具体 prompt也不是 agent 数量而是三条更普适的原则。1. 先承认模型有盲区再用结构把盲区包起来作者并没有假设模型会天然擅长长任务、自评、审美判断或 QA。相反他先承认模型在哪些地方不可靠再为这些薄弱点设计专门结构。这是一种非常成熟的 AI 工程思路不是要求模型“变完美”而是让系统对模型的不完美有弹性。2. 评价标准本身就是产品能力的一部分文章里 evaluator 的价值不只是“检查 bug”而是把“什么叫好结果”明确写进系统。对设计来说这叫评分标准对编码来说这叫 sprint contract、验收条件和 Playwright 测试。换句话说模型产出的上限部分取决于你能否把验收标准写得足够清楚。很多 agent 项目做不起来不是生成能力太弱而是没有把“什么算完成、什么算优秀、什么算失败”表达清楚。3. 每个脚手架组件都应该被持续怀疑这是我最喜欢的一点。作者没有把早期成功经验神化而是主动去测试sprint 还必要吗context reset 还必要吗evaluator 的收益是否还覆盖它的成本这意味着 harness 设计不是“越复杂越强”而是“复杂度必须证明自己仍然值得存在”。模型一升级旧脚手架就可能从增益变成负担。真正好的工程团队会不断重跑这个判断。这篇文章对我们今天做 agent 有什么现实启发如果你正在做 coding agent、设计 agent、工作流 agentAnthropic 这篇文章至少给了三个非常实用的提醒。第一先别急着追求全自动。把任务拆成规划、执行、评估三个层次通常比让一个 agent 从头包到尾更稳。第二主观任务也可以做只要你愿意花力气把“感觉”变成“准则”。第三新模型出现后不只是换模型参数更要回头检查老 harness 里哪些还承重哪些已经是历史包袱。从这个角度看所谓 agent engineering核心并不是“怎么多调几个 API”而是如何把模型能力、任务结构、评价标准和运行成本一起设计成一个可持续迭代的系统。我的结论这篇文章最有价值的地方在于它把一个正在形成中的行业共识讲得很具体未来 AI 应用的竞争力很大程度上会来自 harness design而不仅仅来自模型选型。模型当然会持续变强但随着模型变强harness 并不会消失。它只会迁移到新的边界上去解决那些“模型单独还做不好但加上结构就能明显变好”的问题。所以这篇文章真正想告诉我们的也许不是“Anthropic 又做出了一个三 agent 系统”而是有趣的工程空间并不会因为模型变强而缩小。真正的机会在于持续找到下一个仍然值得加脚手架的组合点。