主讲：Ash Prabaker、Andrew Wilson（Anthropic Applied AI Team）
原视频：https://www.youtube.com/watch?v=mR-WAvEPRwE
概括
这场 workshop 讲的是：长时间运行的 Agent 不是只靠更强模型实现的，而是模型能力与外部 harness（脚手架、调度、记忆、评估、工具、权限、状态管理）共同演化的结果。
讲者以 Claude Code / Agent SDK 的演进为主线，解释了为什么 Agent 过去只能稳定工作十几分钟，而现在可以通过更好的模型、上下文管理、子 Agent、检查点、文件状态、评估器和自动化测试，持续完成数小时级复杂任务，例如从一句话 prompt 构建一个完整 Web App。
这场分享要解决的问题
长期运行 Agent 的难点主要集中在三个方面：
1. 上下文问题
Agent 的上下文窗口有限。随着任务变长，会出现：
- 上下文遗忘：新会话像失忆一样，需要重新建立任务状态。
- 上下文腐化：会话越长，模型对早期目标和约束的把握越容易漂移。
- 上下文焦虑：接近上下文窗口末尾时，模型可能急于“收尾”，导致半成品被误判为完成。
2. 规划问题
模型默认并不总是擅长长期规划。它可能：
- 试图一次性完成所有事情；
- 做到一半就停下；
- 只实现看起来显眼的部分；
- 在没有明确验收标准的情况下提前宣布完成。
3. 自我评估问题
讲者反复强调：让同一个 Agent 自己构建、自己检查，通常是不可靠的。
模型容易对自己的输出过于宽容。一个按钮可能看起来存在，但后端没有接好；一个页面可能视觉上完整，但交互完全不可用。长期 Agent 需要更强的外部评估与验证机制。
核心观点：模型和 Harness 会共同演化
分享中把能力提升分为两条线：
| 方向 | 说明 |
|---|---|
| 模型更新 | 模型本身更会规划、使用工具、管理上下文、保持长期目标一致性。 |
| Harness 演进 | 外部系统提供循环、记忆、检查点、权限、工具调用、子 Agent、评估器、状态文件等能力。 |
重点不是“模型变强后 harness 就没用了”，而是：
模型越强，harness 的设计越需要调整。旧模型需要复杂脚手架，新模型可能只需要更简化但更关键的结构。
Claude / Agent 能力演进脉络
| 阶段 | 关键变化 | 对长期 Agent 的意义 |
|---|---|---|
| Sonnet 3.5 / Computer Use / MCP | 模型开始能写代码、看截图、点击页面、调用工具 | Agent 不再只生成文本，而能观察和操作环境 |
| Claude Code 研究预览 | 用真实开发场景反过来改进模型 | Code Agent 成为模型改进和 harness 实验场 |
| Ralph Loop | 把任务拆解成循环执行，失败可预测 | 提供了早期“长期任务分段执行”的思路 |
| Sonnet 4.5 / Agent SDK / Checkpoints | 更好的上下文感知、检查点、回滚能力 | Agent 可以更安全地执行较长任务 |
| Opus 4.5 / Sub-agents / Skills | 更经济地运行多个子 Agent，技能按需加载 | 复杂任务可以拆分给不同角色 |
| Opus 4.6 / Agent Teams / Server-side Compaction | 更强规划、更长时间运行、服务端压缩 | 更接近连续多小时自主执行 |
关键模式一：不要依赖自我评价，使用对抗式 Evaluator
最重要的设计模式是：
Planner → Generator ↔ Evaluator
Planner：规划者
Planner 不负责写具体技术细节，而是把一句话需求拆成高层产品方向和 sprint。它的作用更像 PM：
- 明确产品边界；
- 生成高层功能结构；
- 避免一开始把技术细节规划得过死。
Generator：构建者
Generator 负责真正实现功能，例如写前端、后端、交互、测试等。
Evaluator：评估者 / QA
Evaluator 不只是读 diff，而是实际运行应用，使用 Playwright、浏览器或 Computer Use：
- 打开页面；
- 点击按钮；
- 检查控制台错误；
- 测试交互；
- 截图观察 UI；
- 按照 rubric 打分；
- 给 Generator 提供具体 critique。
核心原因是：
调教一个“严厉的评估者”比调教一个“既会构建又会严格批判自己”的构建者更可行。
关键模式二：Generator 和 Evaluator 先协商“完成”的定义
在真正写代码前，Generator 和 Evaluator 会先通过文件系统协商一个 contract：
Generator：我准备实现 X，测试方式是 Y。
Evaluator：范围太大，测试太弱，还漏了 Z 边界情况。
Generator：调整实现范围和测试标准。
Evaluator：同意，形成验收 contract。
然后再开始构建。
这一步非常重要，因为它把模糊的用户需求转化为具体、可验证的断言：
- 哪些功能必须存在；
- 哪些边界情况必须通过；
- 哪些交互必须可用；
- 哪些测试才算真正完成。
分享中的一个案例里，应用最终形成了 27 条 contract criteria。讲者认为，粒度越具体，Evaluator 的反馈越可执行，Generator 越容易修复。
关键模式三：用文件系统保存共享状态
长时间运行时，不应只依赖上下文窗口。讲者推荐使用文件系统作为状态载体，例如：
featurelist.json
progress.json
run-log.json
contract.md
evaluator-report.md
implementation-notes.md
文件系统的好处是：
- 不容易因为上下文压缩而完全丢失；
- 后续 Agent 可以 grep、读取、接续；
- 人类也能快速理解执行历史；
- JSON 文件相对不容易被模型随意覆盖。
推荐记录的内容包括：
- 尝试了什么；
- 发现了什么 bug；
- 做了什么修复；
- 修复是否有效；
- 当前还剩哪些未完成项；
- 文件结构和关键设计决策。
案例：Retro Game Maker
分享中展示了一个 prompt：
Build a retro game maker.
单 Agent / 普通循环的结果
普通单 Agent 输出看起来还不错：
- 有首页；
- 有 sprite editor；
- 有画布、调色板、预览区。
但实际进入 play mode 后：
- 方向键无效；
- 空格键无效；
- 游戏实体没有真实交互；
- 看似完成，实际核心功能不可用。
Planner + Generator + Evaluator Harness 的结果
使用长期 harness 后，同样的 prompt 得到更完整的产品：
- 自动命名为 Retro Forge；
- 有新建项目对话框；
- 有完整 sprite 编辑器；
- 有 54 色调色板；
- 有 AI level assistant；
- play mode 中物理循环真实运行；
- 方向键可移动角色；
- 能与墙体碰撞；
- debug HUD 显示实时状态。
差异不在于 prompt 更复杂，而在于 harness 迫使 Agent 规划、验证、修正、重试，甚至在方向错误时推倒重来。
评价主观质量：Taste 也可以写成 Rubric
讲者特别讨论了前端和设计质量。
很多人认为“审美不可评估”，但他们的观点是：
如果你有足够明确的品味，就可以把它写成 rubric。
他们使用类似下面的维度：
| 维度 | 含义 |
|---|---|
| Design | 是否有清晰视觉层级、布局、空间感和一致性 |
| Originality | 是否避免模板化、AI slop、紫色渐变滥用 |
| Craft | 细节是否精致，是否有完成度 |
| Functionality | 功能是否真正可用 |
Evaluator 会根据这些维度打分、截图、反馈，再推动 Generator 迭代。
随模型变强，Harness 应该删减而不是堆叠
一个重要经验是：不要把 harness 当成永远固定的架构。
讲者提到，某些在 Opus 4.5 上必要的复杂结构，在 Opus 4.6 上可以简化。例如：
| Harness 组件 | 旧模型中的作用 | 新模型中可能的变化 |
|---|---|---|
| 频繁重置上下文 | 避免上下文腐化 | 更强模型可能能用单长会话 + compaction |
| 每个 sprint 强制评估 | 防止偏航 | 新模型可能只需阶段性评估 |
| 细粒度功能拆分 | 帮助模型保持方向 | 更强模型能连续完成更长 build |
| 复杂状态同步 | 弥补模型记忆不足 | 可保留关键状态文件，删掉冗余流程 |
结论是：
Harness 的目标不是越复杂越好，而是刚好补齐当前模型的短板。
如何自己搭一个简化版长期 Agent Harness
可以从下面这个最小结构开始：
/project
/state
spec.md
contract.md
progress.json
run-log.json
evaluator-report.md
/app
...
Step 1：Planner 生成高层规格
输入一句话需求，让 Planner 输出：
- 产品目标；
- 用户画像；
- 核心 workflow；
- 功能边界；
- 不做什么。
Step 2：Generator 与 Evaluator 协商 contract
在写代码前，双方先确定：
- 本轮实现范围；
- 验收标准；
- 必须测试的交互；
- 失败条件；
- 哪些问题不能忽略。
Step 3：Generator 实现
Generator 读取：
- spec.md；
- contract.md；
- progress.json；
- 现有代码。
然后只做本轮 contract 对应的实现。
Step 4：Evaluator 独立验证
Evaluator 使用浏览器、Playwright、单元测试、日志、截图等方式验证。
不要只让它“读代码觉得是否正确”，要让它实际运行产品。
Step 5：写回状态并循环
如果失败：
- 写入 evaluator-report.md；
- 标记失败原因；
- Generator 修复；
- 必要时推倒重来。
如果成功：
- 更新 progress.json；
- 记录关键决策；
- 提交或保存检查点；
- 进入下一轮。
最重要的五条 takeaway
-
自我评估是陷阱
构建者很容易高估自己的输出。使用独立、严厉、对抗式 Evaluator。 -
Compaction 不等于 coherence
上下文压缩能让会话延续，但 lossy summary 仍可能漂移。需要结构化 handoff。 -
用干净上下文和结构化交接
分角色、分文件、分状态，避免所有信息混在一个长上下文里。 -
主观质量也能被评估
只要你能定义好品味，就能把 design taste 写成 rubric。 -
读 traces 是构建 Agent 的核心技能
不要只看最终结果，要读 Agent 的完整执行轨迹，理解它为什么偏航、为什么误判、为什么停止。
对开发者的启发
这场分享真正有价值的地方不只是“Anthropic 的模型能跑更久”，而是给出了一个更通用的 Agent 工程方法论：
- 把长期任务拆成角色；
- 把模糊目标变成可验证 contract；
- 把状态写到文件，而不是只塞进上下文；
- 用真实环境验证，而不是只读代码；
- 把评估器训练得更严格；
- 随模型能力变化持续删减 harness。
如果要构建真正可用的长期 Agent，重点不是写一个无限循环，而是设计一个能 规划、执行、检查、记忆、纠错、重试、交接 的系统。