文章摘要版：
上下文窗口是核心瓶颈。Agent 在长任务中容易因上下文塞满后性能急剧下降，需要通过 Harness 工程来管理。
Anthropic 在Harness工程实践中多次迭代了智能体架构：第一代双 Agent（初始化 + 编码）解决了"一次做太多"和"过早完成"的问题；第二代三 Agent（Planner + Generator + Evaluator）引入独立评估者对抗自我评估偏差，并用上下文重置根治上下文焦虑；第三代则随模型能力增强审查Harness设计，裁撤已被模型原生覆盖的 Harness 设计。
核心结论：模型能力边界持续外推，而 Harness 工程是当下决定 Agent 实际效果的关键变量。
01
—
上下文窗口的"轮班困境"
随着 AI Agent 发展，开发者使用它们处理需要跨越数小时甚至数天这样长时间运行才能解决的复杂任务，这不可避免需要 Agent 使用多个上下文窗口去处理。然而，如何让 Agent 在多个上下文窗口之间保持连贯进展，依然是个难题。
Anthropic 的工程师用了一个贴切的比喻来描述这一困境：想象一个由工程师轮班工作的软件项目，每位新工程师上班时，对前一班发生的事情毫无记忆。这就是长时 Agent 的根本挑战——它们只能在离散的会话中工作，每次重启都是一张白纸。
Claude Agent SDK 虽然具备上下文压缩（compaction）等管理能力，理论上可以让 Agent 无限期工作，但实践证明仅压缩是并不足够的。即使是 Opus 4.5 这样的前沿模型，仅凭一条简单提示如"构建一个 claude.ai 的克隆应用"，在多轮上下文窗口中也是无法创建出生产级质量的 Web 应用。
Anthropic 分享的两篇工程博客中记录了他们在实践过程中遇到的问题，以及对这些问题的系统性解法演进。
02
—
第一代 Harness：双 Agent 架构
首先提出了一个双 Agent 架构，用于解决Agent 试图一次性完成整个任务以及过早宣告任务完成的问题。
两类失败原因
早期发现 Agent 失败主要是因为两个原因。第一，Agent 倾向于一次性执行过多操作——本质上是试图一次性完成整个任务，结果往往在实现到一半时耗尽上下文，留给下一个 Agent 的是个没有文档的半成品。
第二种失败常出现在项目后期，新 Agent 接手任务后查看执行状态并看到有了一些任务进展，然后未做任务完整性检查就过早宣告任务完成。
双 Agent 架构解决方案
针对上述发现的失败原因，工程师建立了“初始化 Agent + 编码 Agent”的双 Agent 架构解决方案：
- 初始化 Agent（Initializer Agent）：作为第一个会话，然后专门负责搭建环境；
- 编码 Agent（Coding Agent）：在后续每个会话中作出增量进展，并为下一个会话留下清晰的交接物。
初始化 Agent 的关键产出包括：一个 init.sh 脚本（定义如何启动开发服务器）、一个 claude-progress.txt 进度文件（记录已完成工作的日志）、一次初始 git commit（显示已添加的文件），以及一个功能列表文件（feature list）——将用户输入的任务处理为具体的、可测试的功能需求，初始状态全部标记为"未完成"。
编码 Agent 的工作模式的典型开场是：运行 pwd 确定目录，读取 git 日志和进度文件掌握现状，读取功能列表并选择优先级最高的未完成功能开始工作。
结束时，编码 Agent 提交 git 和更新任务进度，保证代码处于可合并状态，让下一个 Agent 接手后可以直接处理任务，无需清理烂摊子。
还有一个问题是：编码 Agent 修改代码后仅用单元测试或 curl 命令验证，这样无法测试到功能是否真的能正常运行如交互功能。因此，要求编码 Agent 使用浏览器自动化工具如 Playwright MCP 像真实用户一样进行端到端测试，这样可以显著提升性能。
双 Agent 结构有效地解决了一次性执行过多操作与过早宣告任务完成的问题。编码 Agent 被要求每次按优先级只在功能列表中选择一个功能去完成，这样就能按功能列表逐步推进任务执行。通过任务进度文件和 git 记录， Agent 间跨会话状态交接清晰。添加外部工具让端到端测试覆盖率显著提升，整体能够构建出可运行的多会话应用。
03
—
第二代 Harness：规划Agent-生成Agent-评估Agent
第二代Harness中，在第一代基础上针对新的问题挑战做了架构升级。
新的问题挑战
第一，自我评估偏差（Self-Evaluation Bias），实践发现生成 Agent 有“自卖自夸”的倾向。当被要求评估自己生成的作品时，Agent 倾向于自信地称赞自己的作品质量然后通过验证——即便在人类观察者眼里质量明显平庸。这个问题在界面设计等主观任务上尤为突出，因为缺少手段进行判断量化。
第二，在 Claude Sonnet 4.5 测试中，模型表现出了强烈的"上下文焦虑（Context Anxiety）"——当它们认为自己快要达到上下文窗口极限时，开始提前收尾结束工作。
三 Agent 架构解决方案
针对新的问题，工程师提出了“Planner + Generator + Evaluator”的三 Agent 架构解决方案：
- Planner（规划 Agent）： 接收用户的 1~4 句话提示，将其扩展为完整的产品规格。规划时刻意停留在高层设计，避免指定实现细节——避免 Planner 在细节上出错，错误级联传导到下游实现。目标是约束交付物，让 Agent 自己找到路径。
- Generator（生成 Agent）：继承第一代的"每次只做一个功能"原则，以迭代冲刺（Sprint）的方式工作。每个迭代冲刺结束后，Generator 先进行自评，再移交结果给 Evaluator。
- Evaluator（评估 Agent）： 有一套包括产品深度、功能性、视觉设计、代码质量的评分标准。每个标准都有一个硬性阈值，如果任何一项低于该阈值则该迭代失败，生成 Agent 收到来自评估 Agent 关于出错原因的详细反馈。
将生成 Agent 与评估 Agent 分离的设计灵感来自生成式对抗网络。让一个独立的Evaluator 保持怀疑态度去判断生成结果，比让 Generator 自我批判生成结果效果更好。有了 Evaluator 的外部反馈，Generator 也就可以根据具体反馈去进行修改。
通过上下文重置（Context Reset）——完全清除上下文窗口并启动一个新 Agent 并配合结构化的交接机制（该机制会传递前一个 Agent 的状态和后续步骤）——可以给 Agent 提供了全新的上下文状态，就像一张完全干净的白板。这样能让 Agent 上下文窗口从头开始，清除上下文焦虑。它与上下文压缩的区别在于：压缩是将更早的对话就地压缩后同一 Agent 在缩短的会话上继续工作，而上下文焦虑依然存在。
这个架构还有一个关键机制是 Sprint Contract（冲刺契约）：在每个 sprint 开始前，Generator 和 Evaluator 协商好"完成"的定义——Generator 提出要构建什么以及如何验证成功，Evaluator 审查这份提案，确认方向正确后双方达成共识，再开始编码。通过这种机制来解决用户故事与可测试实现之间的落差问题。
这些 Agent 间通信通过文件进行保存，这样保证了 Agent 工作时目标始终向协商的冲刺契约靠拢，同时也避免过早约束实现细节。
为了验证三 Agent 架构效果，Anthropic 团队进行了一项构建“2D 复古游戏引擎”的对比实验：如果仅使用单 Agent 运行，耗时 20 分钟、花费 $9，但产出的应用存在严重缺陷，游戏根本无法运行。使用完整的三 Agent 架构运行，虽然耗时 6 小时、花费 $200，但最终产出了一个包含关卡编辑器、精灵编辑器、实体行为系统且完全可玩的复杂应用。这直观地展示了 Harness 工程在补齐模型无法为 Agent 处理复杂任务所需能力中发挥的重要作用。
还有一个有意思的发现是随着 Opus 4.5、Opus 4.6 相继发布，模型本身已能覆盖部分过去需要 Harness 补齐的能力，如 Context reset 的 token 开销、Sprint 结构的协调成本在更强的模型上成了新的摩擦。这可能会是未来架构演进的一个关注点。
04
—
实践参考
两篇文章的实践参考可归纳为以下几点：
- 区分 compaction 与 context reset 的适用场景： compaction 保持连续性，适合上下文焦虑不严重的模型；reset 提供干净白板，适合任务极长或模型焦虑明显的情况。
- 端到端测试不可省略： 在 web 应用中仅靠单元测试或 curl 命令无法验证集成方面的问题，Playwright 等浏览器自动化工具应当纳入 Harness 的标准配置。
- Sprint Contract 是防止规范漂移的机制： 在开始编码前让 Generator 和 Evaluator 对"完成"定义达成一致，避免用户故事与实现细节之间的落差积累成 bug。
Anthropic 的 Harness 实践分享了构建持续稳定运行 Agent 的一套可行的解法，当然开放问题也依然存在：这些经验能否推广到科学研究或金融建模等其他长周期任务？虽然答案尚在摸索中，但两篇博客清晰表明：模型的能力边界正在外推，而 Harness 工程是当下决定 Agent 实际效果的关键。
(如果这篇文章对您所有帮助，请帮忙 关注 并 转发，谢谢！)
参考链接
[1] Effective Harnesses for Long-Running Agents.
https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents
[2] Harness Design for Long-Running Apps.
https://www.anthropic.com/engineering/harness-design-long-running-apps
