原文信息
- 标题：Harness design for long-running application development
- 来源：Anthropic Engineering Blog
- 作者：Prithvi Rajasekaran（Anthropic Labs 团队）
- 发布时间：2026 年 3 月 24 日
- 原文链接：www.anthropic.com/engineering…
第一章：为什么 AI 需要"工地脚手架"？
假设你招了一个员工，他绝顶聪明，读过的书比图书馆还多，你给他一道题他能秒出答案。但有一个致命弱点：让他独立完成一个需要几天的大型项目，他会出各种幺蛾子。
比如你让他盖一栋房子：
- 干到一半，他觉得自己"脑子快装满了"，开始草率收尾
- 你让他检查自己的活，他永远说"挺好的"，哪怕墙是歪的
- 设计稿做得平庸乏味，他还自我感觉良好
Anthropic 的这篇文章，研究的就是这个问题：怎么给这个聪明的员工搭一套"工地工作流程"，让他能靠谱地完成长时间的复杂项目。
他们把这套工作流程叫做 Harness（脚手架/调度框架）。这个词很形象——就像建筑工地上的脚手架，它本身不是房子，但没有它，工人没法安全高效地把楼盖起来。
原文怎么说
"We've previously shown that harness design has a substantial impact on the effectiveness of long running agentic coding." （我们之前已经证明，脚手架设计对长时间自主编码的效果有着重大影响。）
"Over the past several months I've been working on two interconnected problems: getting Claude to produce high-quality frontend designs, and getting it to build complete applications without human intervention." （过去几个月，我一直在研究两个相互关联的问题：让 Claude 产出高质量的前端设计，以及让它在无人工干预的情况下构建完整应用。）
第二章：AI 的"加班恐慌症"
文章发现的第一个核心毛病，Anthropic 给它起了个名字，叫 Context Anxiety（上下文焦虑）。
什么意思？
AI 干活的时候，它的"脑子"有一个容量上限，这个容量叫做上下文窗口。你可以把它理解为员工的短期记忆——能同时记住多少事。 Anthropic 发现，当 AI 感觉自己"脑子里的东西快满了"时，会出现一种焦虑行为：即使活根本没干完，它也会开始草草收尾，对你说"差不多了""今天就到这吧"。
这就好比一个设计师画海报，画到一半发现自己笔记本快写满了，不是去换本新本子继续画，而是把剩下的部分随便涂两笔，跟你说"完成了"。
文章特别提到，Claude Sonnet 4.5 这个版本的"加班恐慌症"特别严重。他们试过一种办法：压缩记忆——把前面做过的事写成摘要，让同一个 AI 继续干。但发现行不通。因为问题的关键不是"记不记得住"，而是同一个 AI 实例的心态没变——它还是那个干累了、想赶紧交差的人。给它一份摘要，它还是恐慌。
原文怎么说
"Some models also exhibit 'context anxiety,' in which they begin wrapping up work prematurely as they approach what they believe is their context limit." （一些模型还会表现出"上下文焦虑"——当它们接近自己认为的上下文限制时，会过早地收尾工作。）
"In our earlier testing, we found Claude Sonnet 4.5 exhibited context anxiety strongly enough that compaction alone wasn't sufficient to enable strong long task performance." （在早期的测试中，我们发现 Claude Sonnet 4.5 表现出的上下文焦虑非常严重，仅靠压缩记忆根本不足以支撑长任务的良好表现。）
第三章：AI 的自我评分像"王婆卖瓜"
文章发现的第二个核心毛病：让 AI 检查自己的工作，它永远给自己打高分。
作者的原话很直白：即使一个人类一眼就能看出质量很一般，AI 还是会自信满满地夸赞自己的工作。这种偏差在主观性强的任务上尤其严重——比如"这个设计好不好看""这个布局顺不顺手"，没有明确的"对或错"标准，AI 就会倾向于给自己放水。
作者举了个例子：让 Claude 做前端设计，默认情况下它会偏向安全、保守、可预测的布局——技术上没问题，但视觉上平淡无奇。你让它评价自己的设计，它会说"布局合理、功能完整"，完全不会意识到自己做出的东西有多乏味。
解决办法是：把"干活的人"和"挑毛病的人"彻底分开。
就像工地上不能自己砌墙自己验收，AI 也不能自己写代码自己当质检员。让两个独立的 AI 实例分别担任这两个角色，质检员专门负责找茬、挑刺、打低分。虽然质检员本身也是 Claude，一开始也会嘴下留情，但经过反复调校（给质检员明确的评分标准、正反例训练），它可以被训练成一个严格的"黑脸"。
原文怎么说
"When asked to evaluate work they've produced, agents tend to respond by confidently praising the work—even when, to a human observer, the quality is obviously mediocre." （当被要求评价自己产出的工作时，智能体倾向于自信地夸赞自己的工作——即使对人类观察者来说，质量显然很平庸。）
"Whether a layout feels polished or generic is a judgment call, and agents reliably skew positive when grading their own work." （一个布局是精致还是平庸，是一个主观判断，而智能体在给自己打分时一贯会偏向正面。）
"Separating the agent doing the work from the agent judging it proves to be a strong lever to address this issue." （将执行工作的智能体和评判工作的智能体分开，被证明是解决这个问题的有力手段。）
第四章：三个岗位的"工地管理模式"
基于前两个问题的洞察，Anthropic 设计了一套三智能体协作架构。用工地来打比方，就是设立了三个明确的岗位：
岗位一：设计师（Planner）
你跟他说"我要一个游戏制作工具"，他不会直接搬砖砌墙。他会先坐下来，把这句模糊的需求扩展成一份详细的施工图纸——包括有哪些功能模块、每个模块干什么、用户怎么使用。
一个关键的细节：设计师只管"做什么"，不管"怎么做"。具体的代码怎么写、数据库怎么设计，让下面的人自己决定。因为如果设计师瞎指挥技术细节，一旦错了，错误会一路传下去，像多米诺骨牌一样连锁崩塌。
岗位二：施工队（Generator）
拿着设计师的图纸，一块一块地施工。不是一股脑全盖，而是分阶段——今天打地基（实现功能 A），明天砌墙（实现功能 B），后天装修（完善 UI）。每个阶段干完，自己先检查一遍，然后把成果和下一阶段的计划写成一份"交接单"。
岗位三：质检员（Evaluator）
这是整套流程里最关键的变化。质检员不是施工队自己，而是另一个人。质检员会真的去现场测试——打开网页、点击按钮、填写表单，像真实用户一样操作。发现问题就写详细的测试报告，施工队拿着报告返工。
质检员的评分标准非常具体，不是模糊的"好不好"，而是：
- 这个功能按钮点下去有没有反应？
- 这个 API 接口返回的数据对不对？
- 删除实体时，代码里的判断条件是不是写错了？
原文怎么说
"The final result was a three-agent architecture—planner, generator, and evaluator—that produced rich full-stack applications over multi-hour autonomous coding sessions." （最终形成了一个三智能体架构——规划器、生成器和评估器——能在数小时的自主编码会话中产出丰富的全栈应用。）
"Planner: took a simple 1-4 sentence prompt and expanded it into a full product spec." （规划器：将 1-4 句的简单提示扩展为完整的产品规格书。）
"Generator: work in sprints, picking up one feature at a time from the spec." （生成器：按冲刺（sprint）工作，每次从产品规格书中选取一个功能来实现。）
"Evaluator: used the Playwright MCP to click through the running application the way a user would... graded each sprint against both the bugs it had found and a set of criteria." （评估器：使用 Playwright MCP 像用户一样点击测试运行中的应用……根据发现的 bug 和一组评分标准对每个冲刺进行评分。）
第五章：关键机制 —— "换班交接"与"质检合约"
三岗位分工定好了，还有两个关键的"工作流程机制"让这套体系真正跑起来。
机制一：换班交接（Context Reset）
前面说过，AI 有"加班恐慌症"——干久了就开始草率收尾。那怎么办？
答案是：别让他加班。干一段，换一个人。
具体做法是：施工队 A 干完第一阶段，写一份详细的交接文档——目前的进度、已完成的内容、下一步要干什么、已知的问题和注意事项。然后施工队 A"下班"。施工队 B"来接班"，它拿到这份交接文档，从零开始继续干第二阶段。
这里的关键是：施工队 B 是全新的人，脑子里没有任何历史包袱。 它不知道自己已经工作了多久，也没有任何"累了想赶紧结束"的心理负担。它只知道"今天的任务是……"，然后专心干完。
文章特别强调，这跟"让他自己记笔记"不一样。记笔记还是同一个人，他的疲惫感和焦虑感不会因为"看了摘要"就消失。换班则是彻底换人，新来的人状态是全新的。
机制二：Sprint 质检合约
在施工队开始干活之前，施工队和质检员会先签一份"合约"——不是法律文件，而是一份明确的约定：这个阶段要做什么、做到什么程度算"完成"、用什么标准来验收。
为什么要先签合约？
因为设计师的图纸是高层级的（比如"做一个关卡编辑器"），但"关卡编辑器"具体要包含哪些按钮、哪些交互、怎么算"能用"，需要在动工前就约定清楚。否则施工队可能认为自己"做完了"，质检员一看说"这根本不能用"，双方扯皮。
合约的内容非常具体。举个例子，一个 Sprint 的合约可能包含 27 条验收标准：
- 矩形填充工具必须支持拖拽填充整个区域
- 用户可以选中并删除已放置的实体生成点
- 用户可以通过 API 重新排序动画帧
原文怎么说
"Context resets—clearing the context window entirely and starting a fresh agent, combined with a structured handoff that carries the previous agent's state and the next steps—addresses both these issues." （上下文重置——完全清空上下文窗口并启动一个全新的智能体，同时配合一个结构化的交接产物来传递前一个智能体的状态和下一步计划——解决了这两个问题。）
"This differs from compaction, where earlier parts of the conversation are summarized in place so the same agent can keep going on a shortened history. While compaction preserves continuity, it doesn't give the agent a clean slate, which means context anxiety can still persist." （这与压缩不同——压缩是把对话的前面部分原地摘要，让同一个智能体在缩短的历史记录上继续工作。虽然压缩保留了连续性，但它没有给智能体一个干净的起点，这意味着上下文焦虑仍然可能持续。）
"Before each sprint, the generator and evaluator negotiated a sprint contract: agreeing on what 'done' looked like for that chunk of work before any code was written." （在每个冲刺开始前，生成器和评估器会协商一份冲刺合约：在任何代码被编写之前，就约定好那一块工作的"完成"标准是什么。）
第六章：单干 20 分钟 vs 团队 6 小时
理论说了一大堆，实际效果怎么样？Anthropic 做了一个非常具体的对比实验，用的任务是同一个：
提示词："做一个 2D 复古游戏制作工具，包含关卡编辑器、精灵编辑器、实体行为系统和可玩的测试模式。"
然后用两种方式执行：
方式
用时
花费
成果
单智能体单干
20 分钟
9 美元
界面看着还行，但核心功能坏的。玩家角色在屏幕上不会动，实体定义和游戏运行时的连接是断的
三智能体团队
6 小时
200 美元
16 个功能、10 个 Sprint，包含动画系统、音效、AI 辅助精灵生成器、关卡设计师、游戏导出分享链接
作者的原话：贵了 20 多倍，但质量差距一目了然。
单干版本的问题：
- 布局浪费空间，大面积空白
- 操作流程僵硬，没有任何引导告诉用户"应该先创建精灵再放置"
- 最核心的功能——"玩游戏"——根本用不了
团队版本的亮点：
- 使用了完整的视口，面板布局合理
- 有一致的视觉风格和身份感
- 精灵编辑器功能更丰富、工具面板更干净
- 游戏真的能玩了——角色能移动、能跳跃（虽然物理有点粗糙）
- 还内置了 Claude AI 助手，用户可以用自然语言让 AI 帮忙生成游戏素材
质检员抓到的真实 Bug 示例
文章列了几个质检员在测试中抓到的具体问题，非常细节：
合约标准
质检员发现的问题
矩形填充工具支持拖拽填充整个区域
失败——工具只在拖拽的起点和终点放置瓦片，没有填充整个区域。fillRectangle 函数存在但 mouseUp 时没有正确触发。
用户可以选中并删除已放置的实体生成点
失败——LevelEditor.tsx 第 892 行的删除键处理需要同时满足 selection 和 selectedEntityId，但点击实体只设置了 selectedEntityId。条件应该改成 "或" 而不是 "且"。
用户可以通过 API 重新排序动画帧
失败——PUT /frames/reorder 路由定义在 /{frame_id} 路由之后，FastAPI 把 "reorder" 当成 frame_id 去解析整数，返回 422 错误。
原文怎么说
"The harness was over 20x more expensive, but the difference in output quality was immediately apparent." （这个脚手架贵了 20 多倍，但产出质量的差距一目了然。）
"I started by opening the solo run's output, and the initial application seemed in line with those expectations. As I clicked through, however, issues started to emerge... the actual game was broken." （我一开始打开单干版本的输出，初始界面看起来符合预期。但当我点击测试时，问题开始浮现……实际游戏是坏的。）
"In addition to the core editors and play mode, the spec called for a sprite animation system, behavior templates, sound effects and music, an AI-assisted sprite generator and level designer, and game export with shareable links." （除了核心编辑器和游玩模式外，规格书还要求有精灵动画系统、行为模板、音效和音乐、AI 辅助精灵生成器和关卡设计师，以及带分享链接的游戏导出功能。）
第七章：进化 —— 员工变强了，流程该做减法
文章写到这里，有意思的事情发生了：AI 自己变强了。
Claude 发布了新版本 Opus 4.6，官方说它：
- 计划更周密
- 能在更长的任务中保持稳定
- 在更大的代码库中更可靠地工作
- 自我检查和调试能力更好
这意味着之前设计的很多"保护措施"可能不再必要了。就像员工从实习生成长为了资深工程师，你不需要再每一步都盯着他了。
于是作者开始做减法：
去掉的：Sprint 分阶段
原来必须把一个项目切成 10 个阶段，一段一段干，是因为 AI 干长了就会糊涂。现在 Opus 4.6 可以一口气干完，不需要显式切分了。
去掉的：每阶段都质检
原来每个 Sprint 结束后都要质检员检查一遍，现在改成只在最后统一检查一次。因为很多任务已经在新模型的"可靠能力范围"内了，质检员成了不必要的开销。
保留的：设计师（Planner）
没有设计师，AI 拿到一个模糊的需求就开始瞎干，最后做出来的东西功能简陋、范围缩水。设计师负责"先把需求想清楚了再动工"。
保留的：质检员（Evaluator）
虽然模型变强了，但当它处理超出自己舒适区的复杂任务时，仍然会犯错。质检员的价值不在于"有没有它"，而在于"任务是否超出了模型的 solo 可靠边界"。在边界内，它是多余的；超出边界，它是必需的。
文章说了一句很深刻的话：
框架里的每一条规矩，都基于一个假设——"这个员工现在做不到什么"。但员工会成长，这些假设会过时，所以规矩要定期审视、该扔的扔。
原文怎么说
"As I was going through these iteration cycles, we also released Opus 4.6, which provided further motivation to reduce harness complexity." （在我进行这些迭代循环时，我们还发布了 Opus 4.6，这进一步促使我简化脚手架的复杂度。）
"I started by removing the sprint construct entirely... I kept both the planner and evaluator, as each continued to add obvious value." （我首先完全移除了冲刺结构……但我保留了规划器和评估器，因为它们各自都持续提供了明显的价值。）
"Every component in a harness encodes an assumption about what the model can't do on its own, and those assumptions are worth stress testing, both because they may be incorrect, and because they can quickly go stale as models improve." （脚手架中的每个组件都编码了一个假设——关于模型自身做不到什么。这些假设值得被压力测试，既因为它们可能是错误的，也因为它们会随着模型的进步而迅速过时。）
第八章：成品展示 —— 一个网页音乐工作站（DAW）的诞生
文章最后展示了一个用简化版框架做出的实际产品：一个网页版数字音频工作站（DAW）。
提示词只有一句话："用 Web Audio API 在浏览器里做一个功能完整的音乐制作软件。"
实际产出：
- 用时：约 4 小时
- 花费：约 125 美元
- 技术栈：React + Vite + FastAPI + Web Audio API
这个网页应用包含了：
- 多轨时间轴编辑界面
- 混音台（带推子和音量控制）
- 播放/暂停/录制控制条
- 内置的 AI 助手——用户可以用自然语言跟它对话，比如"给我加一段鼓点""把贝斯调大声一点"，AI 会自己操作软件完成
作者亲自测试了这个应用，他用对话让 AI 助手完成了一整首歌的片段：
- "设好速度和调性"
- "铺一段旋律"
- "加个鼓点"
- "调一下混音"
- "加点混响"
AI 助手自己操作软件，把这些都完成了。
当然，作者也坦诚地说：这离专业音乐软件还差得远。 Claude 听不见声音，所以质检员在音乐品味上帮不了忙。AI 助手做的歌也不怎么样。但核心功能都在，而且能跑通一个完整的制作流程。
各阶段的时间与成本明细
阶段
时长
成本
设计师出图纸
4.7 分钟
0.46 美元
施工队第一轮
2 小时 7 分钟
71.08 美元
质检员第一轮
8.8 分钟
3.24 美元
施工队第二轮
1 小时 2 分钟
36.89 美元
质检员第二轮
6.8 分钟
3.09 美元
施工队第三轮
10.9 分钟
5.88 美元
质检员第三轮
9.6 分钟
4.06 美元
总计
约 4 小时
约 125 美元
质检员每一轮都抓到了真实的遗漏：
- 第一轮："看起来不错，但核心功能只是展示性的——音轨不能拖拽移动，没有乐器 UI 面板，没有效果器可视化编辑器。"
- 第二轮："音频录制还是 stub（空壳），音轨边缘拖拽调整大小和分割功能没实现，效果器可视化还是数字滑块而不是图形界面（没有 EQ 曲线）。"
原文怎么说
"Build a fully featured DAW in the browser using the Web Audio API." （用 Web Audio API 在浏览器中构建一个功能完整的数字音频工作站。）
"The run was still lengthy and expensive, at about 4 hours and $124 in token costs." （这次运行仍然耗时且昂贵，大约 4 小时，token 成本约 124 美元。）
"The final app had all the core pieces of a functional music production program: a working arrangement view, mixer, and transport running in the browser. Beyond that, I was able to put together a short song snippet entirely through prompting." （最终应用拥有了一个功能性音乐制作程序的所有核心组件：一个可工作的编曲视图、混音台和运行在浏览器中的播放控制器。除此之外，我能够完全通过提示来拼凑出一小段歌曲。）
第九章：核心启示
文章最后总结了几个值得记住的核心观点：
1. 找到最简单的方案，只在必要时增加复杂度
Anthropic 另一篇博客《Building Effective Agents》的核心原则。不要一开始就把脚手架搭得无比复杂，先试试最简单的方式，发现不够用了再加。
2. 框架里的每条规矩都会过时
框架里的每个组件都基于一个假设——"模型现在做不到这个"。但模型在飞速进步，今天的瓶颈明天可能就消失了。所以框架不是设计好了就一劳永逸，而是要定期审视、该扔的扔、该加的加。
3. 质检员不是"有或没有"，而是"值不值得"
质检员要不要用，取决于任务难度。如果任务在模型的舒适区内，质检员是浪费钱的 overhead；如果任务超出了模型的可靠边界，质检员的投资回报率很高。
4. 有趣的组合不会消失，只会转移
模型变强了，不代表"搭脚手架"这件事没意义了。恰恰相反，模型越强，你能尝试的复杂组合就越多。AI 工程师的有趣工作不是"等模型来解决一切"，而是"不断发现下一个最佳组合"。
原文怎么说
"Our blog post Building Effective Agents frames the underlying idea as 'find the simplest solution possible, and only increase complexity when needed.'" （我们的博客文章《构建有效的智能体》将底层思想概括为"找到最简单的解决方案，只在需要时增加复杂度"。）
"The practical implication is that the evaluator is not a fixed yes-or-no decision. It is worth the cost when the task sits beyond what the current model does reliably solo." （实际含义是，评估器不是一个固定的"是或否"决策。当任务超出了当前模型独立可靠完成的范围时，它才值得投入成本。）
"My conviction is that the space of interesting harness combinations doesn't shrink as models improve. Instead, it moves, and the interesting work for AI engineers is to keep finding the next novel combination." （我坚信，随着模型改进，有趣的脚手架组合空间不会缩小。相反，它会转移，而 AI 工程师的有趣工作就是不断发现下一个新颖的组合。）
