一、先说一个反常识的现象
大多数人在用 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 编排层面。
这个架构有几个关键设计决策值得拆解：
规划者不过度规定细节。规格书只写"是什么"和高层技术方向，不写"怎么做"的具体步骤。过度规定会导致错误级联------一旦某个底层实现有偏差，整个规格书就废了。
冲刺合同（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 代码 |
📌 ⚠️ 成本警示：$200 的任务在个人学习场景尚可接受，但如果你在生产环境里用 Agent 大量运行，需要非常仔细地设计 Sprint 粒度和终止条件，否则成本会失控。架构带来质量，但也带来账单。
六、模型升级如何改变架构复杂度
研究里另一个有价值的观察是：架构不是一成不变的，模型能力的提升会直接简化架构需求。
Claude 4.5 时代，上下文焦虑严重，必须强制使用 Sprint 分解 + 上下文重置。到了 4.6，模型改进了长上下文检索和代码连续性，于是：
• 删除了强制性的上下文重置，改用 SDK 的自动压缩
• 取消了强制 Sprint 分解，模型可以连续运行数小时
• 评估者从"每个 Sprint 都检查"变为"任务末尾做最终质量检查"
这给我们一个启示：如果你正在设计一个 Agent 系统，不要过度工程化。先把架构做到刚好够用，随着模型迭代及时精简。过早的复杂度是维护负担。
七、这对日常开发者意味着什么
读完这份研究，我觉得有几条可以直接落地的实践原则：
原则一：给 AI 任务切片，不要一次性扔进去
Sprint 模式的核心不是架构复杂度，而是把"一个大任务"变成"一系列有明确验收标准的小任务"。即便你没有三 Agent 系统，用 Claude Code 或 Cursor 时，手动切 Sprint、每次只推进一个功能点，效果也会好很多。
ini
# 不好的做法：扔一个大需求
prompt = """
帮我实现一个完整的用户管理系统，包括注册、登录、权限控制、
用户列表、搜索、导出 CSV、发送邮件通知、操作日志...
"""
# 好的做法：明确的 Sprint 定义
sprint_1 = """
本次 Sprint 目标：实现用户注册 API
验收标准：
1. POST /api/register 接受 {email, password}
2. 密码 bcrypt 加密存储
3. 邮箱唯一性校验，重复返回 409
4. 成功返回 201 + userId
5. 有对应的单元测试，覆盖正常路径和边界情况
"""原则二：不要让 AI 自己评估自己的输出
如果你用 Claude 写了一段代码，不要直接问它"这段代码有问题吗"------它大概率会说没问题。换一种方式：
python
# 不好：让模型自评
"你刚才写的这段代码有没有问题？"
# 好：给评估者角色 + 具体维度
"""
你是一位严苛的 code reviewer，专门找问题。
请从以下维度评估这段代码：
1. 是否有潜在的竞态条件
2. 错误处理是否完整
3. 是否有 N+1 查询问题
4. 有没有安全漏洞（SQL 注入、XSS 等）
每个维度给出 1-5 分，分数越低越好（1=没问题，5=严重问题），
并列出具体的问题行号。
"""原则三：用工具验证，不用模型"感觉"验证
Anthropic 用 Playwright 做 UI 验证，这个思路可以推广：能运行的测试 > 模型的文字确认。
Claude Code 现在已经支持在本地跑测试、读错误日志、自动修复。把测试写好，让 Agent 跑完之后看测试结果，而不是看它自己的描述。这才是可信的验证闭环。
python
# 在 Claude Code / Cursor 里，明确要求验证闭环
"""
实现完成后，请：
1. 运行 `npm test` 查看测试结果
2. 如果有失败的用例，先修复再告诉我
3. 最后给我看测试通过的截图（或命令输出）
不要只告诉我"已完成"，要有可验证的证据
"""原则四：重置上下文，不要无限续写
一个 session 跑了很久开始漂移？别硬撑，直接开新对话。把当前状态用结构化的 Artifact 总结出来传给新 session：
shell
# 上下文重置 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 填充实现。技能树在迁移，但"系统思维"这条根没变。
Harness Design 的价值并非恒定------它是突破模型原生能力边界的手段。当模型进化，架构应当精简；当任务超出模型边界，架构应当介入。 ------ Anthropic 研究团队
这句话值得记住。别迷信架构，也别轻视架构。知道什么时候该加、什么时候该减，才是真正的工程判断力。
九、值得继续探索的方向
如果你对这个方向感兴趣，我觉得接下来有几个问题值得深挖：
• Sprint Contract 的最优粒度是多少？太细了 overhead 大，太粗了失控风险高。这可能有行业或项目类型的最佳实践，值得系统性收集。
• 评估者的提示词怎么设计才能真正"怀疑"？Anthropic 提到对评估者做"怀疑论调优"，但细节没有完全公开。这块是可以自己实验的。
• 成本控制和质量之间的 Pareto 前沿在哪 ？ <math xmlns="http://www.w3.org/1998/Math/MathML"> 9 v s 9 vs </math>9vs200 是两个极端，中间有没有一个"性价比最优点"？答案可能跟任务类型强相关。
• 开源的 Harness 框架会不会出现？目前 LangGraph、CrewAI、AutoGen 都在做类似的事，但 Anthropic 的这套思路还没有完整的开源对应物。如果有人做出来，值得关注。
Agent 编程还在早期。今天的最佳实践，六个月后可能就是过时的做法。但理解"为什么这么设计"，比记住"怎么做"更重要。模型会变，但架构思维的底层逻辑不会。
--- 完 ---