一、先说一个反常识的现象
大多数人用 AI 编程时，最大的痛点往往不是模型不够聪明——而是任务跑到一半，Agent 就开始“迷路”了。
你给 Claude 或 GPT-4o 一个复杂需求，开头几步还算顺畅，可没多久它就开始自我矛盾，最后草草收场，扔给你一堆残缺的代码说“需要你来完成剩余部分”。换一个更大的模型？情况可能会好一点，但问题的本质没变。
Anthropic 的工程师最近发表了一篇内部研究——《Harness Design for Long-Running Application Development》，算是把这个问题说透了：当模型能力达到一定水平，瓶颈就不再是模型本身，而是底层架构。
这篇文章想和你聊聊这份研究背后的工程逻辑，以及它能给我们日常用 AI 写代码带来什么启示。
二、两个让 Agent 失败的“死亡模式”
Anthropic 团队在研究里识别出 Agent 在执行长任务时的两种关键失效模式，可以说相当准：
失效模式一：上下文焦虑（Context Anxiety）
这个说法非常传神。当模型感知到上下文窗口快满了，它会开始“着急”——虽然没有真正的情绪，但行为会明显退化：开始走捷径、提前收尾、用“以下留给用户完成”来敷衍你。
这本质上不是一个 bug，而是特性。模型在训练过程中见过大量“上下文结尾处收敛”的示例，于是它学到的模式就成了：“快到结尾了，那就收尾吧。”
很多人直觉上会想到“压缩上下文”——让模型总结之前的内容，腾出空间来。但 Anthropic 的实验表明，上下文重置（Context Reset）效果远优于压缩：直接把窗口清空，将关键状态以结构化的 Artifact 形式传给新 Agent 实例，相当于给它一块干净的白板，让它重新出发。
失效模式二：自我评估偏差（Self-evaluation Bias）
让模型评估自己写的代码，结果几乎永远是“不错”。这不是因为它谦虚，而是训练数据里“确认偏见”的必然产物。
更麻烦的是，在涉及 UI 设计这类主观任务时，模型对“好不好看”根本没有可靠的判断力。你问它“这个界面够不够好”，它会告诉你“看起来很不错，符合现代设计趋势”——因为它根本不知道“不好”的判据是什么。
解决思路是：把“执行者”和“评估者”分离开，并且对评估者做专项调优。让它学会怀疑，学会挑剔，学会给出 1 到 10 分的量化评分，而不是模糊的正面反馈。
三、GAN 思路移植到 Agent 架构
Anthropic 的解决方案，本质上把生成对抗网络（GAN）的思路搬到了 Agent 编排层面。
| 用户需求产品规格 | → | 规划者 Planner扩展为完整规格书 | → | 生成者 Generator按 Sprint 实现功能 |
|---|---|---|---|---|
| ↓ 初步自评通过 | ||||
| 交付 / 下一 Sprint | ← | 达标？未达标则返回 Generator | ← | 评估者 EvaluatorPlaywright QA + 打分批评 |
这个架构里有几个关键设计决策值得拆开来看：
规划者不过度规定细节。规格书只写“是什么”和高层技术方向，不写“怎么做”的具体步骤。过度规定会导致错误级联——一旦某个底层实现有偏差，整份规格书就废了。
冲刺合同（Sprint Contract）机制。每个 Sprint 开始前，生成者和评估者先“谈判”：生成者提出本次 Sprint 要做什么、用什么标准来验证，评估者审核并确认。这个机制确保双方对“完成”的定义一致，避免后期扯皮。
评估者用工具验证，而不是靠“感觉”。用 Playwright 模拟用户操作、验证 API endpoint、检查数据库状态——这才是可信的评估，而不是让另一个模型看一眼代码就说“好的”。
四、前端设计的量化难题
最有意思的部分，是它们如何解决前端 UI 设计中的主观质量问题。
他们把“好设计”拆解成四个可以打分的维度，把主观审美翻译成了评估者能操作的量化准则。评估者使用 Playwright 实际截图，分析视觉层级和交互逻辑，而不是仅靠 HTML 代码去推断效果。
结果相当有趣。在一个博物馆网站案例里，模型在第 10 次迭代时做出了一个出人意料的选择：没有继续优化常规布局，而是把整个页面重构成了一种带 CSS 透视感的 3D 空间交互体验。这不是被指定的，而是迭代反馈自然引出的。
这说明什么？当评估准则足够清晰，模型会朝着高分方向自主探索，而不是沿着“最安全”的路径前进。给 AI 明确的标准，它会超出你的预期。
五、两个真实项目的对比数据
数据最能说明问题。研究里给出了两个案例，很有参考价值：
案例一：2D 复古游戏制作器（Claude 4.5 时代）
| 模式 | 用时 | 成本 | 结果质量 |
|---|---|---|---|
| Solo（直接让模型完成） | 20 分钟 | $9 | 布局粗糙，工作流僵硬，游戏逻辑断裂 |
| Harness 架构 | 6 小时 | $200 | 功能完整（含 AI 生成关卡工具），经过 27 项细粒度测试 |
案例二：数字音乐工作站 DAW（Claude 4.6 时代）
| 指标 | 数值 |
|---|---|
| 用时 | 约 4 小时 |
| 成本 | $124.70 |
| 交付内容 | 编排视图 + 混音器 + 自主 AI 编曲 Agent，核心功能可用 |
| 存在问题 | 音频捕获等底层硬件交互仍有 stub 代码 |
六、模型升级如何改变架构复杂度
研究里还有一个很有价值的观察：架构不是一成不变的，模型能力的提升会直接简化架构需求。
在 Claude 4.5 时代，上下文焦虑问题严重，必须强制使用 Sprint 分解 + 上下文重置。到了 4.6，模型改进了长上下文检索和代码连续性，于是：
• 删除了强制性的上下文重置，改用 SDK 的自动压缩
• 取消了强制 Sprint 分解，模型可以连续运行数小时
• 评估者从“每个 Sprint 都检查”变为“任务末尾做最终质量检查”
这给了我们一个启示：如果你正在设计一个 Agent 系统，不要过度工程化。先把架构做到刚好够用，随着模型迭代及时精简。过早的复杂度，最后都是维护负担。
七、这对日常开发者意味着什么
读完这份研究，有几条原则可以直接落地：
原则一：给 AI 任务切片，不要一次性扔进去
Sprint 模式的核心不在于架构复杂度，而在于把“一个大任务”变成“一系列有明确验收标准的小任务”。即便你没有三 Agent 系统，用 Claude Code 或 Cursor 时，手动切 Sprint、每次只推进一个功能点，效果也会好很多。
# 不好的做法：扔一个大需求prompt = """帮我实现一个完整的用户管理系统，包括注册、登录、权限控制、用户列表、搜索、导出 CSV、发送邮件通知、操作日志…"""# 好的做法：明确的 Sprint 定义sprint_1 = """本次 Sprint 目标：实现用户注册 API验收标准：1. POST /api/register 接受 {email, password}2. 密码 bcrypt 加密存储3. 邮箱唯一性校验，重复返回 4094. 成功返回 201 + userId5. 有对应的单元测试，覆盖正常路径和边界情况"""
原则二：不要让 AI 自己评估自己的输出
如果你用 Claude 写了一段代码，不要直接问它“这段代码有问题吗”——它大概率会告诉你没问题。换一种方式：
# 不好：让模型自评"你刚才写的这段代码有没有问题？"# 好：给评估者角色 + 具体维度"""你是一位严苛的 code reviewer，专门找问题。请从以下维度评估这段代码：1. 是否有潜在的竞态条件2. 错误处理是否完整3. 是否有 N+1 查询问题4. 有没有安全漏洞（SQL 注入、XSS 等）每个维度给出 1-5 分，分数越低越好（1=没问题，5=严重问题），并列出具体的问题行号。"""
原则三：用工具验证，不用模型“感觉”验证
Anthropic 用 Playwright 做 UI 验证，这个思路可以推广：能运行的测试，远胜于模型的文字确认。
Claude Code 现在已经支持在本地跑测试、读错误日志、自动修复。把测试写好，让 Agent 跑完之后看测试结果，而不是看它自己的描述。这才是可信的验证闭环。
# 在 Claude Code / Cursor 里，明确要求验证闭环"""实现完成后，请：1. 运行 `npm test` 查看测试结果2. 如果有失败的用例，先修复再告诉我3. 最后给我看测试通过的截图（或命令输出）不要只告诉我"已完成"，要有可验证的证据"""
原则四：重置上下文，不要无限续写
一个 session 跑了很久开始漂移？别硬撑，直接开新对话。把当前状态用结构化的 Artifact 总结出来，传给新 session：
上下文重置 Artifact 模板状态快照（交接给新 Session）：# 项目：[项目名称]# 当前阶段：Sprint 3 / 共 5 个 Sprint# 已完成- [x] 用户注册 API（tests passing）- [x] 用户登录 API + JWT 签发（tests passing）# 当前 Sprint 目标实现权限中间件（RBAC），支持 admin / editor / viewer 三种角色# 关键约定- 数据库：PostgreSQL，ORM 用 Drizzle- 认证：JWT，secret 在 env.JWT_SECRET- 测试框架：Vitest# 遗留问题- 登录 API 的 refresh token 逻辑 stub 了，后续 Sprint 补# 下一步实现 `authMiddleware(requiredRole)` 函数，挂到需要权限的路由上
八、一个更大的问题：架构师的角色在变
Harness 研究的深层含义，远不止于“怎么写 prompt”。它在告诉我们：当 Agent 的执行能力越来越强，软件开发的核心竞争力正在向“能不能设计出好的 Agent 协作架构”转移。
以前写代码，架构师设计模块边界，程序员填充实现。现在这个分工在变：架构师设计 Agent 协作边界，AI 填充实现。技能树在迁移，但“系统思维”这条根始终没变。
这句话值得记住。别迷信架构，但也别轻视架构。知道什么时候该加、什么时候该减，才是真正的工程判断力。
九、值得继续探索的方向
如果你对这个方向感兴趣，接下来有几个问题值得深挖：
• Sprint Contract 的最优粒度是多少？太细了 overhead 太大，太粗了失控风险高。可能跟行业或项目类型有关，值得系统地收集最佳实践。
• 评估者的提示词该怎么设计，才能让它真正“怀疑”？Anthropic 提到对评估者做了“怀疑论调优”，但细节没有完全公开。这完全可以自己动手实验。
• 成本控制和质量之间的 Pareto 前沿在哪里？200 是两个极端，中间有没有一个“性价比最优点”？答案可能跟任务类型高度相关。
• 开源的 Harness 框架会不会出现？目前 LangGraph、CrewAI、AutoGen 都在做类似的事，但 Anthropic 这套思路还没有完整的开源对应物。如果有人做出来，值得重点关注。
Agent 编程还在非常早期的阶段。今天的最佳实践，六个月后可能就已经过时。但理解“为什么这么设计”，远比记住“怎么做”更重要。模型会变，但架构思维的底层逻辑不会变。
— 完 —
