这篇 Anthropic 工程文章最核心的启发是：当任务从“写一段代码”升级到“持续几小时构建完整应用”时，真正拉开差距的，往往不只是模型本身，而是你给模型搭的“协作组织”——也就是 harness（执行框架）。
想象你要在一天内做出一款能玩的小游戏编辑器。你请了一个非常厉害的全栈工程师，让他一个人从产品定义、界面设计、代码实现、测试验收到最后发布，全包。这个人确实强，20 分钟就能做出一个看起来像样的 demo。
问题是，越往后越容易出事：界面看着像能用，但流程不顺；功能按钮都在，关键交互却有坑；最尴尬的是，“最核心的功能”可能压根没真正跑通。你问他质量如何，他还会自信地说“已经挺好了”。这不是态度问题，而是单兵模式天然有盲区：做的人很难同时当一个足够苛刻的审稿人。
Anthropic 这篇文章做的，就是把这个“单兵困境”系统化拆开：既然一个 AI 容易“边做边自我感动”，那就别让它一个人闭环。给它配上“策划”和“质检”，让它变成项目小组。
文章里最关键的结构是三类角色：
这套分工听起来朴素，但特别像真实团队：产品给方向，开发做实现，测试挑毛病。真正有效的点不在“角色名字”，而在“权力分离”：做事的人不能自己给自己打满分，必须接受外部审视。
作者先在前端设计场景里验证了一个很有意思的做法：把“这页面好不好看”这种主观问题，拆成可讨论、可评分的维度，比如设计整体性、原创性、工艺细节、可用性。然后让生成者和评估者都围绕这套标准迭代。
这一步非常关键。因为很多团队做 AI 生成时，反馈只有“再高级一点”“再好看一点”，这种反馈很难执行。你换成“原创性不够，像模板拼装；视觉层级没拉开；交互主路径不明确”，模型就有了可操作的改进方向。换句话说，不是把审美变成数学，而是把模糊抱怨变成结构化批评。
文章还点了两个长任务常见问题。第一是上下文越来越长后，模型容易失去一致性，甚至出现“快到上限了赶紧收尾”的焦虑行为。第二是自我评估偏乐观，尤其在主观任务里更明显。
早期模型里，他们用过“上下文重置 + 交接文档”来维持稳定；到了更强新模型，很多情况下可以减少这类复杂操作。这背后传达的不是“某种架构永远正确”，而是：harness 不是一劳永逸的制度，它会随模型能力变化而变化。以前必须加的脚手架，未来可能是负担；以前做不到的自治流程，未来可能变成默认能力。
文中有组很直白的数据：单智能体跑 20 分钟，成本约 9 美元；完整 harness 跑 6 小时，成本约 200 美元。贵了二十多倍。看上去像“杀鸡用牛刀”。
但如果你把目标定义成“做个能截图的演示页”，单智能体当然划算；如果目标是“做个能让用户真用起来、核心交互不崩的应用原型”，那多出来的评估和返工闭环就有意义。说白了，这不是绝对更好，而是你愿不愿意为“可靠交付”付钱。
| 目标类型 | 更适合的方式 | 理由 |
|---|---|---|
| 快速灵感验证、内部演示 | 单智能体 | 速度快、成本低、够看即可 |
| 可交互原型、对外试用 | 多角色 harness | 能压住关键 bug，提升可用性 |
| 复杂产品雏形、长链路任务 | 规划 + 执行 + 评估闭环 | 降低“看着很强、实则半成品”风险 |
你不需要今天就上三代理、Playwright 全自动、数小时迭代。更实用的做法是从轻量版开始：
这四步看着不酷，但非常实战。AI 工程里最容易犯的错，就是迷恋花哨架构，却没建立最低限度的质量约束。
如果说第一阶段大家比的是“谁 prompt 写得妙”，那现在正在发生的变化是：谁更会设计一个让模型持续产出、持续纠错、持续收敛的工作系统。Anthropic 这篇文章的价值，不在于告诉你“唯一正确答案”，而在于示范了一种工程思路：把模型当作团队成员，而不是万能个体。
未来模型会越来越强，这几乎是确定的。但也正因为模型更强，任务边界会继续外扩，新的复杂性会不断出现。你可以等模型变好，也可以主动设计更好的协作框架。真正的分水岭，往往在后者。