从 Anthropic 两篇实战文章中提炼：如何用"框架 + 约束"解决 AI Agent 长时运行的核心难题，以及 GAN 启发的三段式 Agent 架构如何将复杂任务从失败推向完成。
2025 年是 AI Agent 的元年。但随着任务复杂度提升，一个根本性问题浮出水面：Agent 在跨多个上下文窗口工作时，如何保持一致、持续地推进？
Anthropic 工程团队面对的是一个现实挑战——让 Claude 构建一个完整的 Web 应用（如 claude.ai 克隆版）。即便是最先进的 Opus 4.5 模型，如果只给一句话提示"构建 claude.ai 的克隆"，也无法生产出生产级质量的成果。
"想象一个软件项目，工程师分班工作，每个新工程师来接班时对上一班发生的事情毫无记忆。这就是 AI Agent 在多上下文窗口工作时面临的根本挑战。"
— Justin Young，Anthropic（2025.11.26）这个比喻精准地揭示了问题本质：上下文窗口是有限的，绝大多数复杂项目无法在单一窗口内完成，Agent 需要跨会话"桥接"进度。
Harness（约束框架） = 围绕 AI Agent 构建的完整运行环境与制度系统，包括工具接口、沙盒环境、架构约束、自动测试、反馈循环与监控机制，目标是引导并约束 Agent 自主、可靠地完成复杂长周期任务，而无需人类实时介入。
公式：Agent = Model + Harness
模型负责原始推理能力，Harness 负责其他一切。
Anthropic 的两篇工程博客（Nov 2025 & Mar 2026）从不同角度系统性地回答了这个问题。本报告将两篇文章的核心内容完整提炼，并配以分析与实践建议。
在系统性实验中，Anthropic 工程师识别出长时运行 Agent 的五大失败模式：
Agent 试图一次性完成整个应用，导致在实现过程中耗尽上下文窗口，留下半成品且无文档的功能。下一个 Agent 会话不得不从混乱状态开始猜测发生了什么，浪费大量时间重建基础状态。即使有 Compaction（上下文压缩）功能，也无法完全解决这个问题。
项目后期，Agent 看到已经取得了一些进展，便"宣布工作已完成"。这种失败模式在功能已部分实现后尤为常见，Agent 满足于现状而不继续推进。
部分模型（特别是 Claude Sonnet 4.5）会在接近其感知的上下文限制时，开始过早地"收尾"工作。这与 Compaction 不同——Compaction 保持连续性，而上下文焦虑会导致 Agent 在实际限制到来之前就停止有效工作。
当被要求评估自己产出的工作时，Agent 倾向于自信地称赞工作——即使对人类观察者来说，质量明显低劣。这在主观任务（如设计）中尤为突出，Agent 缺乏"批判自己作品"的能力。
Agent 倾向于在没有适当测试的情况下将功能标记为"完成"。它会做代码变更，甚至用单元测试或 curl 命令测试，但往往无法识别端到端功能是否真正正常工作。
这五个失败模式共同构成了"为什么单纯给 Agent 一个高层提示无法产出高质量结果"的根本原因。Harness 工程的核心目的就是系统性地解决这些问题。
针对长时运行的多上下文窗口问题，Justin Young 和 Anthropic 工程团队设计了双层 Agent 架构：
第一个会话使用专门的 Prompt，要求模型建立初始环境基础设施：
可重复运行开发环境的脚本，让后续每个 Coding Agent 无需重新摸索如何启动应用。
记录每个 Agent 所做工作的日志文件，作为会话间的"接班记录"，让新 Agent 快速上手。
基于用户提示生成的 200+ 功能需求列表（claude.ai 克隆案例），每个功能初始标记为"failing"。
建立基线状态，为后续代码变更提供可回滚的起点，支持从错误中恢复。
每个后续会话遵循标准化启动协议：
[Assistant] 我将先定位方向，了解项目当前状态。 [Tool Use] <bash - pwd> # 确认工作目录 [Tool Use] <read - claude-progress.txt> # 读取进度日志 [Tool Use] <read - feature_list.json> # 读取功能列表 [Assistant] 让我查看最近的 git 历史。 [Tool Use] <bash - git log --oneline -20> [Assistant] 运行 init.sh 重启开发服务器。 <启动开发服务器> [Assistant] 现在验证基础功能是否仍然正常。 <测试基础功能> [Assistant] 当前状态良好。选择优先级最高的未完成功能开始开发。 <开始单个功能的实现>
"关键洞察是找到一种方式，让 Agent 在新的上下文窗口启动时能快速理解工作状态——这通过 claude-progress.txt 文件和 git 历史共同实现。这些实践的灵感来自高效软件工程师每天的日常工作。"
— Justin Young，Anthropic每个 Coding Agent 会话结束时，必须将环境留在"干净状态"——即适合合并到主分支的代码状态：无重大 Bug、代码整洁且文档完善、开发者可以立即开始开发新功能而无需清理其他遗留问题。
Harness 中的环境管理是让多会话 Agent 协调工作的核心机制。以下是四个关键组件及其设计逻辑：
为解决 Agent "一次性完成"或"过早宣布完成"的问题，Initializer Agent 被要求生成一份结构化 JSON 功能需求文件。在 claude.ai 克隆案例中，这意味着 200+ 个功能点，例如：
{
"category": "functional",
"description": "新建对话按钮创建一个全新会话",
"steps": [
"导航到主界面",
"点击'新建对话'按钮",
"验证新对话已创建",
"检查对话区域显示欢迎状态",
"验证对话出现在侧边栏中"
],
"passes": false
}
所有功能初始标记为 passes: false，Coding Agent 被明确指示只能通过改变 passes 字段来更新文件。Anthropic 使用了强措辞的指令：
"删除或编辑测试是不可接受的，因为这可能导致功能缺失或存在 Bug。"
— Anthropic Harness Prompt 中的强约束指令使用 JSON 而非 Markdown 的原因：模型相比 Markdown 文件，不太可能对 JSON 文件进行不当修改或覆盖。
Coding Agent 每次只处理一个功能。这种增量方式对于解决"一次性完成"的倾向至关重要。工作流程如下：
从功能列表中选择优先级最高的未完成功能，专注于此。
实现功能并端到端测试验证，确认真正可用。
用描述性提交信息提交代码，支持回滚错误变更，恢复工作状态。
将本次工作摘要写入 claude-progress.txt，为下一个 Agent 接班。
这是解决"测试不足"失败模式的关键。实验发现，最有效的方式是明确提示 Claude 使用浏览器自动化工具，像真实用户一样进行测试：
测试结果：
性能显著提升。Agent 能够识别并修复从代码层面无法明显发现的 Bug，特别是涉及用户交互的端到端功能验证。
Claude 的视觉识别存在限制，例如无法通过 Puppeteer MCP 看到浏览器原生的 alert 弹窗，依赖这类弹窗的功能往往仍有 Bug。
| 问题 | Initializer Agent 行为 | Coding Agent 行为 |
|---|---|---|
| Agent 过早宣布整个项目完成 | 建立功能列表文件：基于规格生成包含端到端功能描述的结构化 JSON | 会话开始时读取功能列表，选择单一功能开始工作 |
| Agent 留下存在 Bug 或未记录进度的环境 | 创建初始 Git 仓库和进度记录文件 | 读取进度文件和 git 日志；对开发服务器运行基础测试；会话结束时提交 git 并更新进度 |
| Agent 过早将功能标记为完成 | 建立功能列表文件 | 自验证所有功能，仅在仔细测试后将功能标记为"通过" |
| Agent 需要花时间弄清楚如何运行应用 | 编写可运行开发服务器的 init.sh 脚本 | 会话开始时读取 init.sh |
Prithvi Rajasekaran（Anthropic Labs 团队成员）在解决前端设计质量问题时，从生成对抗网络（GAN）中获得灵感，设计了一套突破性的多 Agent 结构。
"我设计了一个包含生成器和评估器 Agent 的多 Agent 结构，灵感来自生成对抗网络（GAN）。构建一个能可靠地、有品味地给输出打分的评估器，意味着首先要开发一套能将'这个设计好吗？'等主观判断转化为具体可评分条件的标准。"
— Prithvi Rajasekaran，Anthropic Labs（2026.03.24）负责生成输出——前端设计、代码实现。专注于"创作"而非评判。
负责评估输出质量，提供具体、可操作的改进反馈。设计为"怀疑论者"。
核心问题：LLM 天生对 LLM 生成的内容持宽容态度。让同一个 Agent 评判自己的工作，结果往往是自我称赞。
将执行工作的 Agent 与评判它的 Agent 分离，是解决自我评估偏差的强力杠杆。分离本身不能立即消除宽容性——评估器也是 LLM，天生倾向于对 LLM 输出宽松。但将一个独立的评估器调整为"持怀疑态度"，比让生成器批评自己的工作要可行得多。
Rajasekaran 为前端生成器和评估器设计了四个评分维度：
设计是否感觉像一个整体，而非各部分的堆砌？强烈的色彩、字体、布局、图像组合是否创造了独特的气质和身份认同？
是否有自定义决策的痕迹，还是模板布局、库默认值和 AI 生成的通用模式？是否存在"AI 糟粕"（紫色渐变配白色卡片等典型模式）？
技术执行：字体层级、间距一致性、色彩和谐、对比度。这是能力检验而非创意检验，大多数实现默认就做得不错。
独立于美学的可用性。用户能理解界面的功能、找到主要操作、在不猜测的情况下完成任务吗？
设计质量和独创性权重更高，因为 Claude 在工艺和功能上默认表现良好，而在设计品味和创意上最薄弱。
Rajasekaran 使用少样本（few-shot）示例配合详细评分分解来校准评估器，确保其判断与自己的偏好对齐，并减少跨迭代的评分漂移。
"在一个值得注意的例子中，我提示模型为一家荷兰艺术博物馆创建网站。到第九次迭代时，它产出了一个干净的深色主题着陆页。页面视觉精良，但基本符合预期。然后，在第十次循环时，它彻底推翻了思路，将网站重新想象为一种空间体验：一个用 CSS 透视渲染的 3D 房间，带有棋盘格地板，艺术品自由挂在墙上，用门道式导航代替滚动或点击在展厅之间切换。这是我以前从未见过的、来自单次生成的创意飞跃。"
— Prithvi Rajasekaran，Anthropic Labs这个案例揭示了迭代循环的涌现效应：经过足够多轮的生成-评估-反馈，模型会突破常规，产生意想不到的创意解决方案。
即使在第一次迭代中，输出也明显优于没有任何 Prompt 的基线，这表明标准和相关语言本身就在引导模型远离通用默认值，甚至在评估器反馈导致进一步改进之前。标准措辞中包含"最好的设计具有博物馆级品质"这样的短语，会将设计推向特定的视觉收敛方向。
将 GAN 启发的方法应用到全栈开发后，Rajasekaran 构建了三段式 Agent 架构，每个 Agent 解决前一代 Harness 中观察到的特定缺口：
解决了之前 Harness 要求用户提供详细规格的问题。Planner 接收一个简短的 1-4 句话提示，将其扩展为完整的产品规格。
着重产品背景和高层技术设计，而非详细技术实现——避免过早规格化导致的错误级联。
被提示寻找将 AI 功能编织进产品规格的机会，让每个应用都自带智能交互能力。
沿用"一次一功能"的方法，以 Sprint 为单位工作，每个 Sprint 实现一个功能特性。
解决了之前 Harness 中"应用看起来不错但实际有真实 Bug"的问题。
使用 Playwright MCP 像真实用户一样点击运行中的应用，测试 UI 功能、API 端点和数据库状态，然后根据发现的 Bug 和多维度标准对每个 Sprint 打分。每个标准都有硬性门槛，任何一项低于门槛，Sprint 就判定失败，生成器会收到关于出错原因的详细反馈。
每个 Sprint 开始前，Generator 和 Evaluator 先协商一份"Sprint 合同"——在任何代码编写之前，先就"什么叫做完成"达成共识。
1. Generator 提议将要构建什么，以及如何验证成功 2. Evaluator 审查提议，确保 Generator 要构建正确的东西 3. 双方迭代直到达成协议 4. Generator 基于商定的合同进行构建 5. Evaluator 用 Playwright 测试是否符合合同 6. 通过 → 进入下一 Sprint；失败 → Generator 获得详细反馈并修复
"通信通过文件处理：一个 Agent 写入文件，另一个读取并在同一文件中响应，或用新文件回复，前一个 Agent 再读取。这保持了工作与规格的一致性，同时不会过早过度规格化实现细节。"
— Prithvi Rajasekaran，Anthropic Labs为验证 Harness 的实际价值，Rajasekaran 用以下提示同时运行了单 Agent 和完整 Harness：
创建一个 2D 复古游戏制作器，功能包括关卡编辑器、精灵编辑器、实体行为和可玩的测试模式。
| 合同标准 | 评估器发现 |
|---|---|
| 矩形填充工具允许点击拖动填充瓦片区域 | FAIL 工具仅在拖动起点/终点放置瓦片，而非填充区域。fillRectangle 函数存在但在 mouseUp 时未被正确触发。 |
| 用户可选择并删除已放置的实体生成点 | FAIL LevelEditor.tsx:892 的删除键处理程序要求同时设置 selection 和 selectedEntityId，但点击实体只设置 selectedEntityId。条件应改为 selection || (selectedEntityId && activeLayer === 'entity')。 |
| 用户可通过 API 重新排序动画帧 | FAIL PUT /frames/reorder 路由在 /{frame_id} 路由后定义。FastAPI 将 'reorder' 作为整数 frame_id 匹配，返回 422："无法将字符串解析为整数"。 |
这些评估器发现的 Bug 极为具体且可操作，体现了结构化评估标准的真实价值——不是模糊的"看起来有问题"，而是精确定位到文件、行号和错误原因。
"Harness 中的每个组件都编码了关于模型无法独立完成某事的假设，这些假设值得压力测试——既因为它们可能是错误的，也因为随着模型改进，这些假设会迅速过时。《构建有效 Agent》将其底层思路框架为'找到最简单的解决方案，只在需要时增加复杂性'——这是一个在任何维护 Agent Harness 的人身上都持续出现的模式。"
— Prithvi Rajasekaran，Anthropic Labs随着 Opus 4.6 的发布，Rajasekaran 对 Harness 进行了系统性精简实验：
Sprint 结构帮助将工作分解为模型可以连贯工作的块。鉴于 Opus 4.6 的改进，有充分理由相信模型可以原生处理这项工作。
"[Opus 4.6] 规划更仔细，能长时间持续进行代理任务，在更大的代码库中更可靠地运行，并且有更好的代码审查和调试技能来捕捉自己的错误。它在长上下文检索方面也大幅改进。这些都是 Harness 一直在补充的能力。"
— Anthropic Opus 4.6 发布博客没有 Planner，生成器的规模明显偏小：给定原始提示，它会直接开始构建而不先规格化工作，最终创建的应用比 Planner 的功能更少。
每个 Sprint 结束时的评估改为整个运行结束后的单次评估。在模型能力边界内的任务，评估器持续提供价值。
评估器的价值不是固定的"是/否"决策。当任务超出当前模型可靠独立完成的范围时，它才值得付出代价。
在 Opus 4.5 中，构建任务处于生成器能力的边界——评估器在整个构建过程中捕捉了有意义的问题。在 Opus 4.6 中，模型的原始能力提升了，边界外移。曾经需要评估器检查才能连贯实现的任务，现在往往在生成器能力范围内，评估器对这些任务变成了不必要的开销。但对于仍处于能力边界的部分，评估器继续带来真实提升。
始终对正在构建的模型进行实验，读取其在实际问题上的追踪记录，调整性能以达到期望结果。
新模型发布时，重新审查 Harness，剥离不再对性能起关键作用的部分，添加新的部分以实现之前不可能的更强能力。
用精简后的 Harness（移除 Sprint 构造，保留 Planner + Evaluator）测试数字音频工作站（DAW）生成：
使用 Web Audio API 在浏览器中构建一个功能完整的 DAW。
| Agent & 阶段 | 时长 | 费用 |
|---|---|---|
| Planner | 4.7 分钟 | $0.46 |
| Build（第1轮） | 2小时7分钟 | $71.08 |
| QA（第1轮） | 8.8 分钟 | $3.24 |
| Build（第2轮） | 1小时2分钟 | $36.89 |
| QA（第2轮） | 6.8 分钟 | $3.09 |
| Build（第3轮） | 10.9 分钟 | $5.88 |
| QA（第3轮） | 9.6 分钟 | $4.06 |
生成器在没有 Sprint 分解的情况下连贯运行了超过 2 小时，这展示了 Opus 4.6 的长时连贯能力。
"这是一款设计保真度优秀、AI 代理扎实、后端良好的强力应用。主要失分点是功能完整性——虽然应用看起来令人印象深刻，且 AI 集成工作良好，但几个核心 DAW 功能只有展示性界面，缺乏交互深度：时间轴上的片段无法拖动/移动、没有乐器 UI 面板（合成器旋钮、鼓垫），也没有可视化效果编辑器（EQ 曲线、压缩表）。这些不是边缘情况——它们是使 DAW 可用的核心交互，规格明确要求了这些功能。"
— Evaluator Agent 第1轮反馈"剩余差距：- 音频录制仍只是存根（按钮切换但无麦克风捕获）- 未实现边缘拖动调整片段大小和片段分割 - 效果可视化是数字滑块，不是图形化的（无 EQ 曲线）"
— Evaluator Agent 第2轮反馈最终结果：一个包含完整核心功能的可用音乐制作程序——工作中的编排视图、调音台和传输控制在浏览器中运行。AI Agent 能够设置节奏和调性、铺设旋律、构建鼓点、调整调音台电平、添加混响，并生成一个简短的歌曲片段。
对正在构建的模型进行实验，读取其在真实问题上的运行追踪，调整性能以达到期望结果。勿假设某个组件是否有效——要验证。
任何需要质量判断的任务，都应将执行者与评判者分离。调整独立评估器为"怀疑论者"，比让生成器批评自身更可行。
使用文件系统作为 Agent 间的通信媒介，通过 JSON 功能列表、进度文件、Git 历史共同维护可追踪的状态，支持中断恢复。
"这个设计好吗？"难以回答，"这个设计是否遵循了以下原则？"则可以评分。将主观判断转化为具体可评分的标准，是提升质量的关键。
从最简单的解决方案开始，只在需要时增加复杂性。每个 Harness 组件都应有明确存在理由——它解决了模型不能独立完成的什么问题？
新模型发布时重新审视 Harness 的每个组件。移除不再负载关键性能的部分，添加新部分以实现之前模型能力边界之外的目标。
增量提交、进度日志、测试驱动——人类软件工程师的日常实践，同样适用于 AI Agent 的 Harness 设计。"向人类工程师学习"是核心思路。
明确提示 Agent 使用浏览器自动化工具做端到端测试，效果远优于仅用 curl 或单元测试。像真实用户一样使用产品，才能发现真正的问题。
1. 单 Agent vs 多 Agent 架构：目前仍不清楚在多个上下文中，单一通用编码 Agent 还是多 Agent 架构（专门的测试 Agent、QA Agent、代码清理 Agent）的表现更好。
2. 领域泛化：当前实验主要针对全栈 Web 应用开发。这些发现能否应用于科学研究、金融建模等其他需要长时代理任务的领域？
3. Harness 空间不会收缩：随着模型改进，有趣的 Harness 组合空间不会缩小——它会移动。AI 工程师的有趣工作是不断找到下一个新颖组合。
Anthropic 这两篇工程博客共同描绘了一幅清晰的 Harness 工程图景：
Agent = Model + Harness
模型提供推理能力，Harness 提供一切其他：状态管理、进度追踪、质量保证、错误恢复。
第一代：初始化 + 编码双层架构，解决多上下文窗口的状态延续问题。第二代：GAN 启发的三段式（Planner + Generator + Evaluator），解决质量判断和规格扩展问题。
从这两篇文章中可以看到，AI 工程的核心挑战已经从"如何让模型更聪明"转向"如何设计更好的约束框架"。即便是最强的模型，在没有适当 Harness 的情况下，也无法可靠地完成真正复杂的长时任务。
对于想在实践中应用 Harness 工程的团队，核心建议是：先明确失败模式，再设计最简解法，然后随模型迭代不断精简。不要为了复杂而复杂，但也不要低估结构对 Agent 行为的塑造力。
"从这项工作中，我的信念是，有趣的 Harness 组合空间不会随着模型改进而收缩。相反，它会移动，AI 工程师的有趣工作就是不断找到下一个新颖组合。"
— Prithvi Rajasekaran，Anthropic Labs（2026.03.24）