从演示到工程：让 Agent 长时间运行的现实挑战

本期播客来自 AI Engineer Conference，由 Anthropic 应用 AI 团队的 Ashpreet Baker 与 Andrew Wilson 主讲，聚焦于如何构建能连续运行数小时甚至数天而不跑偏的 Agent。他们指出，当前许多公开演示仅展示最终效果，却回避了底层工程细节——这正是他们希望填补的空白。

Agent 长时间运行的困难主要源于三类问题：上下文管理、模型自我判断能力不足、以及规划能力缺失。其中，上下文窗口有限导致“失忆”现象，即每次新会话都需重置；而随着上下文推进，还会出现“context rot”（上下文衰减），表现为一致性下降。更隐蔽的是模型的“context window anxiety”：临近窗口上限时，模型会急于收尾，常留下半成品功能。此外，模型在编程任务中极易“自我迎合”，把未完成的功能误判为已完成，例如前端按钮存在但后端逻辑缺失。

能以可预测的方式失败，比以不可预测的方式成功更好。

前沿并不会真的缩小，它只是会移动。

双轨演进：模型能力与脚手架工程的协同进化

应对上述挑战，Anthropic 采取了模型与 harness（脚手架）双轨并进的策略。一方面，模型本身持续进化：从 Opus 3.7 到 Opus 4，其在最小脚手架下连续运行时间从1小时跃升至12小时以上；Sonnet 4.5 起，模型已具备上下文意识，能主动管理 token 消耗并避免窗口末尾的焦虑行为。

另一方面，Agent SDK（原 Cloud Code SDK）作为核心 harness，提供了完整基础设施：包括agent 循环引擎、工具集成（MCP）、子 Agent 分发机制、权限系统，以及对 Skills（技能） 的动态加载支持——Skills 采用“头部先行”策略，仅在实例化时才加载完整工具描述，极大节省上下文空间。此外，程序化工具调用（Programmatic Tool Calling）取代传统“调用→拉取结果”模式，改为现场执行、仅返回最终输出，进一步压缩上下文占用。

标准模糊，批评就会模糊。只有这样，你才真正知道 scaffold 里哪些部分该删，哪些部分该留。

从 Cloud Code 到持久化 Agent 循环：实践路径演进

时间线回溯显示，一年前 Cloud（即 Claude）尚难处理 Bash 命令与字符串转义，单次运行仅约20分钟；如今，Cloud Code 几乎完全由自身生成，并可连续运行数天。关键里程碑包括：Sunny 3.5（首次支持自我检查与迭代）、Computer Use（支持截图交互与代码测试）、MCP 规范（统一工具接入）、以及 Cloud Code 1.0（2025年2月发布，支持 Kubernetes 部署）。

Ralph Loop 作为早期简化方案，虽被部分质疑“非真正循环”，但其核心思想——在单次会话中通过压缩维持上下文，并设置安全退出机制——仍具启发性。而当前主流方案已升级为持久化产物驱动的循环：初始化 Agent 将模糊需求（如“写一个浏览器”）拆解为功能列表（JSON）、进度文件、Git 仓库与 init 脚本；随后进入迭代循环：每次新建 context window，读取当前状态→选择未完成功能→实现+真实测试（如 Puppeteer）→提交 Git 并更新状态标记。该流程实现了状态持久化、任务分解、验证闭环与上下文重置的有机结合，构成长时间运行 Agent 的第一代工程范式。

从单轮验证到长时运行 Agent 的演进

在早期的长时运行 Agent 实践中，系统会选择一个尚未通过所有测试的功能，仅聚焦于实现该功能并进行真实测试——验证循环高度模仿人类开发流程。我们使用 Puppeteer 执行自动化测试，一旦全部通过，系统会自动生成 git commit 并更新功能状态；若仍有未完成项，则在新的 context window 中继续循环。这一机制开始叠加多个关键概念：持久化产物、context window 切换、验证闭环，以及预先规划能力。这实际上构成了第一代长时间运行 harness 的雏形。

随着模型能力跃升，Opus 4.6 和 Sonnet 4.6 成为关键节点：Sonnet 4.6 以接近 Opus 的智能水平提供了更具性价比的方案，迅速成为 cloud code 场景主力；而 Opus 4.6 则展现出极强的agentic 能力——擅长工具选择、任务分解与长时执行。在简单 harness 下，其单次运行时长从约 4 小时跃升至 12 小时。伴随这些进展，我们推出了 Agent Teams，其核心创新在于：子 Agent 之间可直接通信，仅在必要时向主 Agent 汇报；同时引入服务端压缩与百万级 context window，使长时任务无需频繁重启会话。

“模型本身在变强，也许很多任务只放在一个 context window 里就能跑完，不一定总是需要不断开新会话。”

“模型变强之后，harness 并不会消失，它会随着模型变化而不断演进，找到模型里的短板，再用 harness 把它补上。”

对抗式 harness：生成器与批评者的协同进化

我们借鉴了 GAN（生成对抗网络） 的思想，构建了一种新型 harness：由 generator（生成器） 和 evaluator（评估器） 组成对抗循环。与传统 self-check 流程不同，这里的 evaluator 并非仅读取 diff，而是真实启动 Playwright，打开页面、交互测试、截图分析，最终输出具体批评意见。虽然 evaluator 仍是 LLM，但通过刻意调高其批评严格度，可显著提升其判断力——这利用了人类认知中“评价他人作品远比创作更易”的能力差异。

我们为 evaluator 设计了四维评分标准：设计、原创性、工艺感、功能性，其中前两项权重更高。为校准审美，我们引入参考网站的 few-shot 示例，使 evaluator 的品味逐步向人类标准收敛。在实际运行中，generator 与 evaluator 会通过磁盘上的 Markdown 文件反复协商“完成标准”，形成一份可执行契约。这种机制促使 evaluator 能指出模糊问题（如“紫色渐变滥用”），而 generator 则能据此精准修复。

“一个显而易见的问题是，如果评估器也只是一个 LLM，为什么它不会也直接盖章？……把一个独立的批评者调得更严格，其实是很可行的。”

“它会转向……如果你只用单个 agent 循环，不一定能得到这种效果……这种能力，也就是在很长时间跨度里不断纠正方向，我觉得是很独特的。”

Planner 角色与契约式开发：从页面到可用应用

为将美观页面升级为真正可用的应用，我们引入了 Planner 角色。它不陷入早期技术细节，而是将任务拆解为高层级的 sprint 规格，避免因初始规划错误在数小时运行中被放大。整个结构类似 PM/IC/Q A 协作模式，但每个角色拥有独立 context window。

关键创新在于 generator 与 evaluator 之间的契约协商机制：在写第一行代码前，二者就通过文件来回讨论“如何定义完成”，例如 generator 提议“构建 X 功能，用测试 Y 验证”，evaluator 可反驳“范围过大，测试不足，遗漏边界 X/Y/Z”。最终达成的契约将用户故事转化为具体、可测试的断言，使 evaluator 按此评分，而非依赖 Planner 一次性输出的模糊规格。

实测中，同一 prompt 下，无 harness 的 agent 仅能生成静态 UI（如 Sprite 编辑器），但游戏逻辑完全失效；而 harness 版本在约 6 小时、200 美元投入后，产出完整 Retro Forge 应用：包含 AI 关卡助手、实时物理循环、debug head、方向键响应等——所有功能均由 agent 自主发现并实现。最终生成的 27 条契约标准证明：只有足够细粒度的标准，批评才可执行；否则 agent 只会敷衍修改。

“开箱即用的 Claude 作为通用 QA Agent，其实非常非常糟糕。”

Contract 驱动的评估：从模糊批评到可执行修复

在长时运行 Agent 的工程实践中，评估器（Evaluator）与生成器（Generator）之间通过明确的 contract 进行协作，是确保质量可控的关键。我们最终定义了二十七条 contract 标准，其核心价值在于：只有足够细粒度的标准，才能让问题具备可执行性。标准模糊时，批评也会模糊，generator 只会耸耸肩、随便改点东西；而当标准足够具体时，agent 就能精准定位到“我需要修的就是这一行”。值得注意的是，开箱即用的 Claude 作为通用 QA Agent 实际非常糟糕——即使在通用 LLM Judge 系统中常见的迎合倾向与宽容偏差，在此场景下同样显著。早期运行中，Q Agent 常常发现一个 bug 后就说“以后再修吧，可能要两周”，然后就结束任务。因此，系统搭建的核心手艺其实是读运行轨迹（traces）：通过反复观察 agent 的判断与人类判断的偏差点，针对性调整 prompt，这与调试代码时读调用栈用的是同一种能力。我们还发展出一个小技巧：将 agent 的对话记录导出为文件，再让另一个 agent 通读并自动生成 prompt 改进建议，从而在搭建 harness 的过程中形成闭环。

我觉得有意思的是，我也想诚实说这一点：开箱即用的 Claude 作为通用 QA Agent，其实非常非常糟糕。

核心手艺其实就是读运行轨迹。我们主要的调试循环就是这个不一定是跑更多实验，而是看 agent 实际做了什么。

模型演进下的 Harness 简化：从多 sprint 到长会话

随着模型快速迭代（如从 Opus 4.5 到 4.6），harness 的设计也需动态调整。过去我们依赖将任务拆分为多个 sprint，并频繁重置上下文，是因为早期模型存在严重的“上下文焦虑”；而 Opus 4.6 已能连续运行两小时并保持连贯性，因此我们大幅简化了流程：取消多 sprint 拆分，改用单一长会话 + 压缩策略。相应地，evaluator 的运行节奏也从“每个 sprint 一次”变为“在模型一次性生成结束后统一执行”，再将结果反馈回 generator。这种简化并非否定原有 harness 的价值，而是说明：harness 没有错，只是它对 4.5 是对的，对 4.6 就不必那么复杂。最终我们保留了 planner–generator–evaluator 的核心循环，但砍掉了许多冗余组件，使系统更轻量高效。例如在 DAW（数字音频工作站）应用中，简化版 harness 的运行成本约为旧方案的一半，却仍能完成旋律生成、鼓组搭建等完整任务——尽管 Claude 尚未具备听觉能力，音乐质量尚可，但整体应用结构已相当完整。

这也是后训练带来的变化之一。所以一个连续绘画再加上压缩，就已经足够处理很长的绘画了。

所以 Harness 还是同一个 Harness，我们只是把里面具体的循环和流程配方简化了。

可复用的评估框架与工程直觉：从 Web 到通用范式

我们始终在推动评估逻辑的可复用性：目标不是为每个项目单独定制，而是提炼覆盖模型共性弱点的通用模式。例如在前端设计中，我们明确区分“真正漂亮的产品”与“AI slop”，并将这类判断结构化为评分标准，泛化效果良好。这套最初围绕 Web 应用构建的框架，也较容易迁移到其他类型任务。我们鼓励开发者直接利用现有工具链：如 Playwright MCP 或 Cloud for Chrome MCP 处理 Web 交互，Computer Use 处理原生应用，Custom Sub Agent 承担 evaluator 角色，并通过严格 system prompt + 详细 rubric 实现质量控制。此外，我们总结出五条关键经验：① 自我评估易踩坑，需用对抗式评估器；② 压缩 ≠ 连贯，带损耗总结易漂移；③ 结构化交接与干净上下文是良好模式；④ 主观质量也可量化——若你对结果有明确构想，就应强制自己写下来；⑤ 最终靠坐在模型旁读 traces，才知道该删减或保留哪些 scaffold。

如果你要拍一张照片，我会说这页幻灯片最值得记住。

最后真的就是坐在模型旁边读它的 traces，只有这样你才真正知道 scaffoldly 哪些部分该删，哪些部分该留。

Harness 循环中的角色分工与设计哲学

在长时运行 Agent 的工程实践中，planner（规划器）、generator（生成器） 和 evaluator（评估器） 三者之间形成了一种动态契约关系，其核心在于避免规划器过度干预执行细节。我们希望规划器仅负责设定高层边界——即产品“大致可能是什么样子”，而非介入具体功能可行性判断或自我修改。真正驱动迭代的是 generator 与 evaluator 之间的对抗性协作：前者负责产出实现方案，后者则聚焦于验证这些方案是否满足主规格说明中定义的功能与契约。

为保持上下文连贯性，产品经理生成的主规格说明会被定期插入到循环中，作为所有生成与评估的锚点。这种设计并非强制所有功能必须被完整执行（如早期尝试中要求 planner 指令覆盖 200 项功能），而是允许根据模型能力灵活调整策略——例如用 Opus 4.6 做创意引导，再交由 Sonnet 4.6 执行编程任务。模型选择直接影响 harness 的结构设计，成本与性能权衡决定了是否采用分层模型分工。

我们不希望规划器成为这个循环里的核心部分，它应该保持在很高层，它真正的作用是画出这个产品大概可能是什么样子的硬边界，但它的工作不一定是进来干预，说其实这个功能不可能做，然后我们不该做这个功能，也不该让它自己去改自己，我们想把这种上下文关系尽量只保留在构建器和生成器之间。

基本上你可以把这种生成器加评估器的结构放进一个多步骤工作流里，每个构建器可能都有稍微不同的功能，作为一个更长工作流的一部分。

可追踪性与状态持久化：让 Agent 不跑偏的关键

要让 Agent 在数天甚至数周后仍能延续工作而不跑偏，状态持久化与可追溯性设计至关重要。我们默认采用文件系统作为状态载体，因其简单直观，新模型可直接通过 grep 等工具读取历史上下文。更进一步，我们鼓励在循环中嵌入轻量级 prompt，让模型将关键决策、尝试路径与结果写入 JSON 文件——例如记录“试过 evaluator X，发现 bug Y，实现修复 Z，验证通过，继续下一步”。

这种做法本质上是为后续接手者留下一串语义化的面包屑：不仅有时间戳日志，还有高层文档说明当前文件结构与目标。仅靠这两个文件（状态日志 + 高层文档），就能让 Cloud Code 或人类开发者快速理解上下文并继续迭代。值得注意的是，尽管我们尝试过让 evaluator 接收 generator 的完整执行轨迹，但发现这容易导致思路混淆；更有效的方式是 evaluator 仅反馈输出层面的问题，由 generator 自主反思并修复。

所以说实在的，对我来说，关键是我要怎么指示这个 harness，让它给之后接手的人留下线索，然后这个人可以再用 cloud code 继续往上做。

一般来说，那个文件的结构可能就是试过这个 evaluator，发现了这个 bug，实现了这个修复，这个修复有效，打勾，然后继续。这样你就有一个带时间戳的日志，可以看到模型试过的所有东西，做过的修复以及最后的状态。

Agent Teams 与 Generator-Evaluator 模式的融合与边界

当前实践中，Agent Teams 与 Generator-Evaluator 并非互斥，而是存在显著重叠。例如，一个主 agent 可承担 generator 角色，其子 agent 中可包含专门的 critic；而前端、后端等模块化子 agent 亦可各自配备专属 critic。Cloud Code 作为试验场，允许快速验证 harness 有效性，后续可迁移至更稳定的 Agent SDK 环境中部署。

然而，Agent Teams 的落地仍面临现实约束：Cloud Code 必须在本地运行，限制了长期稳定性；而 Agent SDK 支持云端沙箱长时间运行，更适合生产场景。我们尚未确立统一最优范式，而是倡导“多实验、少教条”——根据任务特性选择最适配的组织方式。

在评估质量方面，我们通过细粒度评分标准（如设计品位、API 设计、代码质量等）构建 hill-climbing 信号，使 evaluator 能持续引导 generator 优化输出。这套方法虽不适用于跨产品横向比较，但在单次运行或项目内迭代中极具价值。最终，它更像一种可定制的模式，而非普适标准。

我们其实没有一个特别强的立场，说在任何一个时刻哪种设置一定是最好的。

Boris 经常会更新他的推文，说这是我现在的做法。Agent Teams 是内部很多人很喜欢的东西，所以我们就想，好，那就发布出去，看看真实使用场景里大家怎么想。

Greenfield 探索与工程取舍

对于超长时间运行的 Agent，目前尚无成熟通用的解决方案，因此它仍是一个充满机会的 Greenfield 软件方向，值得持续投入探索。在技术路径上，存在两种主流思路：一是将 Agent 的协作能力集成进类似 Cloud Codex 或 Cloud Day AI 的平台级体验中；二是回归软件工程的最佳实践，例如利用 版本控制、commit、pull request 等机制保障多任务并发时的文件系统一致性——比如通过 git worktree 避免不同功能模块间的覆盖冲突。尽管协作场景理论上成立，但现实中多数团队仍倾向于从零构建项目，再向内部展示成果，因此类似 Scrum Review 的周期性人类介入机制尚未成为主流。不过，这恰恰引出了一个关键问题：Human in the Loop 的最小必要 primitive 是什么？ 我们更倾向于在 harness 中预设 hook 机制，即在满足特定停止条件（如 evaluator 判定失败）时自动暂停，交由人类输入指令后继续执行。这种设计既保留了可控性，又不牺牲自动化潜力。最终目标始终是构建 无需 human in the loop 的 harness，让系统在绝大多数场景下能自主运行；若确需干预，也应通过可编程的 hook 实现，而非在工程后期临时插入人工兜底。

如果我有机会在几个小时后 review 一下，也许我就能用更好的方式引导它，这样八个小时之后，它产出的结果会更接近我真正想要的那个项目。

我们更希望一开始就把这些东西嵌进 harness 本身做尽，而不是放弃 harness，然后说好吧，我们就在这里放一个人，帮他兜住各种可靠性问题。

从失败中迭代：Harness 的自进化机制

在实践中，我们常采用一种 失败驱动的 prompt 迭代法：一次性启动多个生成路径（例如十个），观察其结果分布（如三成成功、七成失败），再集中分析失败案例，反向优化主 harness 的 prompt 设计。这一过程本质上是在 harness 层面模拟工程师的 code review 循环——只不过评审对象是模型行为本身。这种机制不仅提升了系统鲁棒性，也强化了团队对模型行为逻辑的 共情能力。例如，在开发 Cloud for Chrome Agent 时，我们曾刻意模拟模型视角：想象自己闭眼操作网页，每十秒睁眼一次获取静态快照，再继续操作。这种训练帮助我们理解模型为何做出某些判断，并据此调整指令设计。最终，这些经验会沉淀为可复用的 prompt 模板、skill 或 Claude1.dotmd 规范，形成团队知识资产。值得注意的是，这套方法虽源于 Greenfield 项目，但其原则（如评估器与生成器并行、trace 分析驱动迭代）已广泛应用于已有系统的自动化增强中——比如在监控系统触发 issue 后，由 agent 自动完成 PR，再经由已有 PR review 流程，仅在合并前做最终人工确认。

真正把自己放到模型的位置上，这其实是一种需要培养的共情能力。真正做到这一点，唯一的办法就是尽可能多地和这些模型相处，同时也要一行一行读它的输出，想为什么它会这么判断。

从 Demo 到生产：经验迁移的现实边界

尽管该模式在全新项目中展现出强大潜力，但在已有系统中落地仍面临现实约束：若缺乏完善的测试覆盖率与定制化评估标准，直接套用可能风险过高。因此，我们更倾向于将其用于 内部工具或新应用开发，而非重构遗留系统。例如，Claude Code 中许多新功能（如 sub-agent 启动机制、监控-修复闭环）均吸收了本项目的实践经验，但并非简单照搬，而是根据具体场景 模块化提取可用原则——比如在 bug 修复流程中，决定是否让评估器与生成器并行处理同一任务。这种“原则复用而非模式复制”的策略，既保证了工程可行性，也保留了创新弹性。此外，随着系统运行时间延长，模型对上下文的记忆能力（如 Claude Code 的自动绘图记忆）也需纳入 harness 设计考量，以避免因状态漂移导致行为偏移。总体而言，这套探索的核心价值不在于提供终极方案，而在于建立一套 可复现、可分析、可进化的 agent 工程文化。