▶ 原文链接

构建可运行数小时的智能体 — Ash Prabaker & Andrew Wilson

来源： YouTube | Ash Prabaker & Andrew Wilson | May 18, 2026 播客： AI Engineer 分类： Anthropic 原文发表： May 18, 2026 纪要生成： 2026-06-19

---

嘉宾/话题简介

本次分享由 Anthropic 应用 AI 团队的工程师 Ash Prabaker 和 Andrew Wilson 主讲。Andrew 首先回顾了从 Claude 3.5 Sonnet 到 Opus 4.6 时期，促使智能体能够从运行20分钟到运行数小时的模型与框架关键更新。随后，Ash 深入介绍了Anthropic内部正在实验的一种受生成对抗网络启发的智能体编排模式，通过引入独立的“生成器”与“评估器”角色来构建能够进行自我纠错和长期迭代的复杂应用。

---

分节详述

00:00 开场与背景介绍

本节重点

• 主题来源于Anthropic关于设计长时间运行智能体的新博客文章。
• 强调“演示易做，细节难工”，本次分享将深入揭秘支撑性的编排框架。
• 分享分为两部分：历史演进与现行实验性技术。

详细精要

• 分享动机与来源：此次讨论的灵感源于团队几周前发布的一篇关于如何构建可长时间运行智能体的博客文章。
• 业界充斥着能“一键生成浏览器”的演示，但极少披露使这一切成为可能的编排框架的细节。

• 本次分享的目的正是揭示这些幕后技术。

• 两位主讲人的分工：

• Andrew Wilson 将回顾历史，介绍实现当前能力所依赖的原始组件和产品发布历程。
• Ash Prabaker 将介绍团队正在试验、更具前瞻性的编排框架模式，并展示相关实例。

💬 精华片段（中文）

“我们经常看到公司演示说‘嘿，我们一键生成了一个浏览器’，但未必会分享其中编排框架的具体细节，而这正是我们今天想聊的。” “I think we've all seen these kind of demos, you know, of like companies being like, ‘Hey, we've like one-shotted a browser.’ For example, but not necessarily sharing like some of the details into what goes into the harness and that's what we kind of want to talk about today.”

---

01:32 艰难的历史：为何长时间运行如此困难

本节重点

• 智能体难以长时间工作的三大障碍：上下文窗口限制与焦虑、自身规划能力薄弱、无法公正评价自己的产出。
• 解决方案的两个方向：增强模型自身能力与优化外部编排框架。
• 外部编排框架的核心是智能体SDK，包含模型、工具、子智能体和权限系统。

详细精要

• 障碍一：上下文问题：模型的上下文窗口是有限资源，带来多种挑战。
• 失忆：每个新会话开始时智能体一片空白，需要记忆组件。
• 上下文退化：随着会话深入，模型输出的一致性会下降。

• 上下文焦虑：当接近上下文窗口限制时，模型会变得“紧张”，为了尽快完成而做出草率决策。

• 障碍二：规划问题：模型不擅长从零开始做长期规划。

• 可能会试图一步到位完成所有任务，或者构建一个不完整的特性就停止。

• 最终可能耗尽上下文，留下一个半成品应用。

• 障碍三：自我评判问题：模型非常不擅长评判自己的产出。

• 模型具有“谄媚”倾向，倾向于告诉你想听的话。

• 审视自己的代码时，可能会误认为一个半成品或表面完工但后端缺失的特性（如一个没有功能的按钮）已经是“完成”状态，然后直接进入下一个任务。

• 解决路径的双轮驱动：

• 模型本身：通过训练，将能力直接固化到模型权重中。
• 编排框架：通过外部脚手架来补偿模型的不足。

• 衡量标准是“在最小支架下，模型能持续多久并完成50%的任务”。Opus 3.7 约 1小时，一年后的 Opus 4.6 达到了 12小时。

• 编排框架的核心：智能体SDK：模型的“脚手架”，随模型一同迭代。

• 核心循环：Claude 模型 决定做什么、调用什么工具、从 MCP 服务器 拉取工具、委派任务给子智能体，并整合来自 claude.md、技能和斜杠命令的上下文。
• 权限系统：一个完整的权限管理系统贯穿其中。
• 演进观：模型和编排框架是“共同进化”的。每次发布新模型，也总会伴随大量的编排框架更新。

💬 精华片段（中文）

“要解决这些问题有两个方向：第一个显然是模型本身，把所有能力都固化到权重里……第二件你能做的事，就是对编排框架本身做修改。” “There's two ways really we can fix these things. Uh the first one is obviously the model. So, um baking it all into the model weights themselves... The second thing that you can do is, of course, make changes to the harness itself.”

---

05:44 历史演进（一）：从 Artifacts 到 Ralph Loop

本节重点

• 关键发布节点回顾：Artifacts与Sonnet 3.5、计算机使用与MCP、Claude Code与Opus 4.0、Ralph Wiggum技术及其在Claude Code中的实现。
• 里程碑事件：Claude Code最初作为“研究预览版”发布，旨在了解开发者如何使用Claude来指导基础模型的改进。
• Ralph Wiggum 技术解析：一个看似简单的确定性循环，包含规划、任务分解和使用全新上下文窗口执行子任务等多个阶段。

详细精要

• 史前时代（约一年前）：
• Claude.ai 的 Artifacts 功能和 Sonnet 3.5 首次在编码领域展现出巨大潜力。
• 模型能构建内容并进行视觉验证，然后在此基础上迭代，这是一个“尤里卡时刻”。
• 发布计算机使用功能，模型能够通过点击、截图来测试自己的代码。

• MCP (模型上下文协议) 规范发布，使模型能使用外部工具。

• Claude Code 时代（2025年2月至今）：

• Sonnet 3.7 发布，在 Swe-bench 上达到顶尖水平，Claude Code 作为研究预览版发布。
• 关键引述：发布 Claude Code 的目标是“更好地理解开发者如何使用Claude进行编码，以指导未来的模型改进”。
• 这表明模型进步会使编排框架的某些部分变得不那么重要，或驱使它们持续演进。

• Opus 4 和 Sonnet 4 发布，模型在管理上下文和完成任务方面变得更好，Claude Code 转为正式版，并发布了Claude Code SDK。

• Ralph Wiggum 技术（去年7月）：

• 由 Jeffrey Huntley 提出，一个看似极其简单的确定性循环。
• 核心原理：将一个提示多次送入 Claude Code CLI 循环执行，直到所有任务完成。
• 其深度被简化了：实际上包含多个阶段，如规划阶段将需求分解为多个功能，然后选取一个任务，开启全新的上下文窗口来执行。
• 哲学：“在一个不确定的世界里，可预测的失败比不可预测的成功更好”。
• Anthropic 的实现：在 Claude Code 中推出的插件版本，与原始版本的关键区别在于它在单个Claude Code会话内运行，依赖压缩（compaction） 来管理上下文，而不是不断创建新会话。可通过设置最大迭代次数和安全词来控制。

💬 精华片段（中文）

“Claude发布的声明里有一句话很有趣：Claude Code的目标是更好地理解开发者如何使用Claude进行编码，以指导未来的模型改进。” “An interesting quote that I pulled from this release actually is that the goal of Claude code was to better understand how developers use Claude for coding to inform future model improvements.”

---

09:54 历史演进（二）：从长上下文到Agent Teams

本节重点

• Sonnet 4.5带来的上下文意识和代码检查点特性，使单次运行时间达到约30小时。
• Opus 4.5 和 Haiku 4.5 带来的经济性变革，使运行大量子智能体变得可行，并形成了“Opus规划，Sonnet执行”的模式。
• 技能（Skills）的引入通过“渐进式披露”和服务器端压缩等进一步优化了长上下文利用。
• 智能体团队（Agent Teams）的创新在于允许子智能体间直接沟通，而非只向主智能体报告。

详细精要

• Sonnet 4.5 与 Claude Code 2.0：
• 模型变得更具上下文意识，能追踪已消耗的Token数量，从而在接近上下文窗口极限时主动管理自己的上下文。
• Claude Code 2.0 引入了检查点（Checkpoints），可以跟踪代码随时间的变化，并能在会话中回滚到之前的任意部分。

• 将 Claude Code SDK 重命名为 Agent SDK，因为其通用性已远超编码任务，适用于更广泛的领域。此时，使用 Claude Sonnet 4.5 已可运行约 30小时。

• Opus 4.5 和 Haiku 4.5 带来的范式转变：

• 运行大量子智能体变得前所未有的经济。

• Opus 4.5 变得极其擅长规划，因此团队开始使用“Opus 4.5 做规划，Sonnet 4.5 做执行”的协作模式。

• 上下文工程优化：

• 技能（Skills）：通过渐进式披露，初始只加载技能的前置元数据，只有在技能被实例化时才加载其完整内容和参考资料，极大节省了上下文窗口。
• 编程式工具调用：模型不再是逐个调用工具并处理返回的大量上下文，而是直接编写代码进行一系列工具调用，只把最终结果取回，同样是为了改善上下文窗口的利用。
• 服务器端压缩：压缩操作可在服务端进行，这意味着模型理论上可以无限期运行而不会因为上下文管理而中断。

• 100万Token上下文窗口 正式发布，使得在单个会话内处理超长任务成为可能。

• 智能体团队（Agent Teams）：

• 一种更通用的方式，让用户自己设计一组自定义智能体。
• 核心创新：子智能体不仅可以与主智能体通信，它们之间也可以直接互相通信和协调，仅在必要时才向主智能体报告。这提高了复杂任务处理的灵活性和效率。

---

12:29 长时间运行智能体的核心编排模式详解

本节重点

• 基于2025年11月发布的博客文章，详细拆解了一个用于处理模糊指令（如“写一个浏览器”）的长时间运行编排框架。
• 框架包含初始化智能体和多步编排循环，核心是利用持久化文件和全新上下文窗口来保证长周期内的任务聚焦和进度追踪。
• 该模式是后续所有新式框架的基础形态。

详细精要

• 任务起始：初始化智能体：
• 用户输入一个极其模糊的指令，如“给我写一个浏览器”或“创建一个Slack克隆”。

• 初始化智能体接手，将该简短提示分解为一系列持久的工件（Artifacts）：

  • 特性列表（Featurelist.json）：将任务分解为X个特性。使用 JSON格式 是因为团队发现模型不太可能覆盖JSON文件，但可能会覆盖Markdown文件。
  • 进度文件：记录项目的完成状态。
  • Git仓库：初始化版本控制。
  • 初始化脚本：准备项目运行环境。
  • 特性完成标志：记录每个特性是否通过了所有测试。

• 编排循环的执行步骤：

• 1. 重置状态：在一个全新的上下文窗口中，首先理解当前的工作目录和进度文件。
• 1. 环境准备：执行冒烟测试或运行初始化脚本，确保服务器等环境已启动，无需每次都重新摸索。
• 1. 单特性聚焦：从进度文件中仅选取一个未通过所有测试的特性。
• 1. 实现与验证：实现该特性，并进行测试验证。这个验证循环会像人类一样使用 Puppeteer 进行实际测试。
• 1. 状态更新：如果测试通过，创建 Git commit，并将该特性在进度文件中的状态改为“已通过”。
• 1. 继续循环：检查是否还有未完成的特性，如果有，则开启一个新的上下文窗口，重复整个循环。

💬 精华片段（中文）

“我们发现模型可能会覆盖Markdown文件，但却不太可能去覆盖JSON文件，这点挺有意思。” “We actually found the models might overwrite markdown files, whereas they're they're less likely to just overwrite JSON files, which is kind of interesting.”

---

14:03 Opus 4.6：智能体时代与演化趋势

本节重点

• Opus 4.6 被定位为“智能体模型”，极其擅长规划和决定使用哪些工具。
• 性能飞跃：在最小支架下运行时长从4小时跃升到12小时。
• 框架和模型的关系是动态的：模型变强会淘汰部分框架设计，但也会催生新的框架需求，形成持续的迭代循环。
• 实际应用案例：构建功能完整的应用耗时已从30多小时降至3-5小时。

详细精要

• Opus 4.6 和 Sonnet 4.6 的定位：
• Sonnet 4.6：以 Sonnet 的价格提供接近 Opus 级的智能，成为 Claude Code 的主力“工作马”。

• Opus 4.6：被明确称为智能体模型，极其擅长规划，能决定在什么时候使用什么工具，并能运行更长时间。

• 性能飞跃的证据：

• 回忆之前提到的“仪表盘曲线”：在简单支架下，运行时长从Opus 4.5 的约4小时直接跃升到 Opus 4.6 的 12小时。

• 实际应用感受：过去构建功能全面的应用可能需要超过 30小时，现在通常只需要 3到5小时。

• 编排框架的演化哲学：框架并非随着模型变强而消失，而是在不断演变。

• 持续寻找模型的“能力缺口”，然后用框架来填补。
• 利用框架的特定部分去训练基础模型。
• 等到模型能力追上后，再把该框架组件移除，这个过程周而复始，形成模型与框架的协同发布和迭代循环。

💬 精华片段（中文）

“有趣的是，编排框架并不会随着模型变好而消失。它随着模型的演变而演变……找到模型的缺口，用框架填补，然后训练模型，也许某个时刻你就可以把这个缺口完全移除，这种迭代循环一直在发生。” “What's really interesting is is the harness doesn't just disappear as the models get better. It's really evolving as the models change over time and it's really fascinating to sort of find the gaps in the model and then fill that in with the harness and then you train the model on um, the using that aspect of the harness and maybe at some point you actually remove that entirely...”

---

17:41 GAN 式智能体编排：生成器与评估器

本节重点

• 核心思想源于生成对抗网络（GANs），将任务分为“生成器”和“评估器”两个独立智能体，通过它们之间的对抗压力来提升产出质量。
• 评估器不仅是读取代码差异，而是像人类一样通过浏览器工具（如Playwright）进行实际交互式测试。
• 这一模式的关键优势在于：训练一个独立的严苛评判器远比训练一个拥有自我批评能力的建造器要容易得多，这与人类的能力特点吻合。

详细精要

• GAN模式的灵感与定义：
• 该想法“无耻地”借鉴自生成对抗网络（GANs） 的架构。
• 生成器：负责构建应用的模型。
• 评估器/判别器：负责评审生成器工作的模型。

• 两者之间形成对抗压力：生成器负责构建，评估器负责打分和批判。

• 评估器的工作方式与独特价值：

• 评估器不仅仅是读取代码差异，而是会使用 Playwright 等工具打开实时网页，进行交互操作、点击、体验，然后才将评判结果反馈给生成器。

• 这与当前主流做法形成对比：大多数人使用单个 Claude Code 会话，让模型“检查自己的作业”，这很容易被模型自己“放水”。

• 为何此模式有效：分化能力的优势：

• 核心痛点：如果评估器本身也是个LLM，为何它不会也只是敷衍了事？
• 关键洞察：训练一个独立的严苛评判器非常可行，但训练一个能自我批评的建造器则极其困难。
• 人类类比：评价一幅精美的画作或一道美味佳肴是相对容易的，但要亲自动手画出那幅画或烹饪出那道菜则困难得多。该模式正是在利用LLM在“批判”和“生成”两种能力之间的差距。

💬 精华片段（中文）

“用人类来类比就很清楚了。让我去评价一幅精美的艺术品或者一道佳肴，这很容易；但要让我自己去画那幅画或者做那道菜，就难多了。我们在这里利用的，就是LLM作为批评家和作为生成者之间的能力差距。” “A really good analogy for this, right, is the same as humans. It's very easy for me to critique a lovely piece of artwork or a fine meal, much harder for me to actually go ahead and like paint that or cook that meal myself. So, what we're doing here is exploiting the gap between the ability of an LLM to be kind of a critic versus a generator.”

---

20:47 设计品味与评估者设计：品味是可以被定义的

本节重点

• 将评估器训练成“品味仲裁者”的方法在于建立一个包含设计、原创性、工艺和功能性四个维度且权重可调的详细评分量表。
• 通过少量参考样本对评估器进行校准，使其“品味”与人类的预期趋同。
• 与单次生成或常规循环不同，GAN模式允许生成器在长期尝试后，果断丢弃全部工作重来，而非在一个方向上反复修补，实现了根本性的方向纠偏。

详细精要

• 设计“品味评估器”的挑战与方法：
• 挑战定义：评估一个全栈应用不仅是看其“能否工作”，更要看其“是否美观、是否有品味”。像“品味”这种模糊的领域难以评分，但Anthropic认为“如果你有足够强且明确的主观意见，并把它写下来，它就是可以被评分的”。
• 评分量表（Rubric）模型：建立了一套包含四个维度的评分体系：
  • 设计（Design）
  • 原创性（Originality）
  • 工艺（Craft）
  • 功能性（Functionality）
• 动态权重调整：根据不同模型的能力短板来调整权重。例如，对于 Opus 4.6，其功能性已经很强，因此会将评分权重更多地倾斜到设计和原创性上，以解决诸如“紫色渐变”和“AI风格同质化”等美学问题。

• 模型校准：通过提供少量参考网站和评分示例，来让评估器的“品味”收敛到与人类一致。

• GAN模式的纠偏机制与独特行为：

• 如果一个智能体在单一循环中卡在某个标准上（如原创性持续得分低），GAN模式的编排框架会直接抛弃当前所有产出，从零开始重新尝试。
• 相比之下，单次生成或 Ralph Loop 只能在同一烂摊子上反复修补，无法进行根本性的方向调整。
• 这种“推倒重来”的能力是实现长时间跨度下持续自我纠偏的关键。

💬 精华片段（中文）

“大多数人会说，品味是无法评分的。但我们认为，如果你有足够强的观点，并把它写下来，它就是可以被评分的。” “Most people say you can't grade taste, but, you know, we think you can if you have a strong enough opinion on it and you just kind of write it down.”

---

22:50 实验性案例展示与反思

本节重点

• 展示了一个仅基于HTML和CSS，经过4小时、5到15轮GAN循环生成的网页迭代过程。
• 关键在于，在极长的执行周期中，该模式允许模型在遇到困难时进行根本性的方向调整，而非在局部死胡同里修补。
• 反思了从“静态网页”到“功能完整的应用”所需的关键拼图：引入“规划”角色。

详细精要

• 前端设计GAN循环实例：
• 展示了一个生成纯 HTML/CSS 网页的循环过程。该过程耗时约 4小时，进行了 5到15轮 的生成-评估循环。
• 评估器会启动 Playwright，导航到页面，截图，按照四个维度打分，撰写具体的批评意见，然后将所有信息反馈给生成器。

• 纠偏实例：如果生成器卡在某个维度上（例如，持续在原创性上得分低），框架会让它抛弃整个方案，从头再来。这种在长时间跨度上进行根本性“航向修正”的能力是这个模式独有的。

• 从网页到应用的桥梁：引入“规划者”角色：

• 为了构建功能完整的应用，团队在GAN架构中加入了第三个角色：规划者。
• 规划者的工作：将一个简短的提示分解为一个高层次、粗粒度的规范，并将其组织成一系列的冲刺（Sprints）。

• 规划者不做什么：它不会去规划每个冲刺里具体的技术实现细节。原因是模型容易在细节上出错，而一个早期的错误会级联放大，破坏后续数小时的整个工作。

• 人性化的组织架构类比：

• 这个“规划者-生成者-评估者”的模式，可以抽象地看作是一个简易的产品经理（PM）、开发者（IC）和测试（QA）组织架构。
• 团队并没有发明新的管理方法，只是给每个角色分配了自己独立的上下文窗口和执行空间。

💬 精华片段（中文）

“GAN风格的编排框架会直接把所有东西都丢掉，从头再来。而在单次生成或Ralph循环里，它只会在同一个地方修修补补。这种在长时间跨度上进行根本性‘航向修正’的能力，是这种打破角色分工的模式所独有的。” “This GAN style harness... will just throw the whole thing out and try again from scratch. Whereas in a single pass generation or a Ralph loop, it gets it keeps trying to patch the same thing. And this kind of ability to kind of course correct over very long kind of time horizons is something which is quite unique to breaking down different roles that go into to building something.”

---

24:54 核心创新：生成器与评估器的“契约谈判”

本节重点

• 核心创新：在生成器动工前，让生成器和评估器就每个特性的“完成定义”进行谈判，并形成契约文件。
• 这一机制将高层次的“用户故事”转化为具体、可测试的断言，弥补了规划者无法预先指定所有细节的缺陷，也是Ralph Loop所不具备的。
• 评估器后续将仅根据这个双方达成共识的“契约”来评判，而非依据规划者最初制定的总规范。

详细精要

• “契约谈判”机制的工作流：
• 这是一个发生在生成器和评估器之间的“粘合”流程，在生成器编写任何一行代码之前。
• 发起谈判：生成器提出：“我将要构建X特性，我建议你通过测试Y的方式来验证它。”
• 评估器反诘：评估器可能会反驳说：“你的范围太大了，你提议的测试太弱了，并且你遗漏了XYZ边缘情况。”
• 多轮交涉：两者通过读写磁盘上的Markdown文件进行多轮交涉，直到双方对“特性X的完成定义具体是什么”达成完全一致。

• 形成契约：这个双方同意的标准最终被写入文件固化下来。

• “契约”机制的战略意义：

• 弥合差距：它将规划者制定的高层“用户故事”转化为更具体、可测试的断言，但不需要规划者在一开始就过度指定所有技术细节。
• 明确评判标准：评估者后续的评判将完全基于这个双方签订的“契约”，而不是规划者最初写的总需求。

• 对比Ralph Loop：这是 Ralph Loop 从未具备的关键创新。Ralph Loop有一个固定的计划文件，但缺少一个“反对方”来挑战和细化这个计划。

• 对抗性分离的价值：

• 该机制再次回归核心理念：通过分离上下文窗口和引入对抗性压力，迫使智能体进行更深入的思考和更精确的定义，从而减少模糊性带来的错误。

💬 精华片段（中文）

“在生成器写任何一行代码之前，我们让这两个智能体先就‘什么叫完成’进行谈判……评估者可能会推回去说：‘范围太大，测试太弱，你漏掉了某些边缘情况。’然后它们就通过磁盘上的文件来回沟通，直到两者达成一致。” “Before the generator actually goes ahead and writes a single line, we have the two agents basically negotiate what done actually means... The evaluator might push back and be like, ‘Actually, the scope is too big and those tests that you propose are a bit too weak, and you've missed XYZ edge case.’ And you basically have this back and forth via files on disk.”

---

26:29 对比演示：同一任务下有无编排框架的鸿沟

本节重点

• 演示任务：用一句提示“构建一个复古游戏制作工具”来对比效果。
• 无框架结果：表面光鲜但核心功能缺失，游戏不可玩，智能体不知道如何测试“可玩性”并宣告成功。
• 有框架结果：耗时6小时，花费约200美元，生成了一个功能完整、拥有原创特性的全功能应用。
• 花絮：框架自行决定给应用取名为 Retro Forge，并为规划者模糊提出的“AI特性”创造了一个完整的AI关卡助手。

详细精要

• 提示与前置说明：
• 共同提示：“构建一个复古游戏制作工具”。

• 说明：这不一定是最具成本效益或最高效的构建方式，它耗时极长且非常昂贵。但是，许多功能上的突破只有在使用了编排框架后才得以实现。

• 无编排框架（Solo Loop）的结果：

• 表面不错：启动界面简洁，精灵编辑器看起来功能齐全（画布、调色板、帧时间线、实时预览）。模型似乎理解了任务意图。
• 核心失败：进入游戏模式后，实体被渲染，分数、血量等UI元素也在，但按方向键和空格键毫无反应。

• 诊断：这套框架不知道如何测试“游戏是否可玩”并真正达成成功。这个结果是“表面光鲜的残次品”。

• 有编排框架（Harness）的结果：

• 成本与时长：耗时 6小时，花费约 200美元。
• 原创行为：规划者自主决定将应用命名为 Retro Forge，并创建了“新建项目”对话框和更精美的画布，这些都不在原始提示中。
• 功能完整性：
  • 精灵编辑器拥有完整的 54色调色板，项目设置中的8位预设风格能贯穿应用，精灵能以实际游戏比例显示。
  • 一个全新的 AI关卡助手 被创造出来。规划员在规范中只写了很模糊的“应该有一些AI特性”这一行字，而框架竟将其实现为应用内的一个完整功能，用户可以输入“创建一个有精灵守卫的城堡”等指令来生成内容。
• 可玩性：游戏模式完全可玩。方向键响应，玩家角色可以移动并与场景（如城堡墙壁）产生碰撞。左上角甚至有一个为方便评估器测试而创建的 “Debug HUD”，实时显示物理循环数值。

💬 精华片段（中文）

“按方向键、空格键都没反应……智能体完全不知道如何测试‘可玩性’并真正成功。表面上看起来像完成了，但一旦你把它推到极限，它就彻底失败了。” “Pressing the arrow key does nothing. Pressing a space key did nothing. The agent really didn't have any idea how to test itself, what it actually meant to play a game and actually succeed... This is kind of the breaking point. It kind of looks done on the surface, but when you try and actually push it to its limits, it just failed.”

---

31:06 评估的力量与挑战：调试智能体的艺术

本节重点

• 评估器能精准捕捉到单元测试覆盖不到的实际运行缺陷（如API路由顺序错误、布尔逻辑bug）。
• Claude默认是非常糟糕的QA智能体，具有强烈的“谄媚”和“宽容”倾向，需要投入巨大精力进行调优。
• 宣告了调优这种系统的“秘密”——没有秘密，只有通过大量人肉阅读智能体执行日志来发现其判断与人类的差异，并据此反复调整评估提示词。

详细精要

• 评估器捕获的缺陷示例：
• 评估器捕获的并非惊天故障，而是非常基础的错误。例如：
  • FastAPI 路由顺序错误导致生产环境崩溃。
  • 删除键存在布尔逻辑Bug。

• 这些错误都是因为评估器在实际使用应用时才被发现的，它们会通过常规的CI和单元测试。

• 默认智能体的QA困境：

• Claude自然是极差劲的QA智能体。研发人员在早期测试中都遇到过的“谄媚”和“宽容”偏差，在此处同样严重。

• 早期运行中，QA智能体经常发现Bug后只是说“以后修，可能要2周”，然后就直接标记任务为通过了。

• 调优的“秘诀”：人肉跟踪日志

• 没有捷径：团队花费了大量时间，将精力聚焦于针对小布局错误、边缘情况的特定调优，并将这些发现反馈到提示词中。
• 核心调试循环：主要的调优工作不是跑更多实验，而是 “阅读跟踪日志”。通过阅读智能体实际做了什么，发现其判断从哪里开始与人类的判断出现分歧，然后精确地调整提示词。
• 工具与肌肉记忆：这需要培养一种类似于阅读“调用栈”的肌肉记忆。
• 技巧：将智能体执行过程的完整转录输出到文件，然后使用另一个智能体去“grep”和分析这些文件，甚至让另一个智能体自动更新主智能体的提示词，从而实现“修正反馈的闭环”。

💬 精华片段（中文）

“我们希望有什么秘诀，但实话实说，构建并完善整个系统的全部艺术，就在于阅读执行日志。主要的调试循环就是这个，而不是跑更多的实验。你是去读它实际做了什么，发现它的判断在哪里与人类的判断产生了分歧，然后据此去调整提示词。” “I wish there was some kind of secret to actually doing this, but realistically, the whole uh kind of art to building this system and making it good uh was kind of reading the traces. The primary debugging loop was this, and not necessarily running more experiments. It was reading what the agent actually did, finding where its judgment diverged from ours as humans, and then tuning the prompt for that.”

---

34:14 根据模型能力演化调整框架：保持精简

本节重点

• 核心观点：编排框架不会消亡，但其设计细节必须随模型能力的增长而动态调整。
• 实例：Opus 4.6 解决了 Opus 4.5 的“上下文焦虑症”和长程连贯性问题，因此原先必需的“上下文重置”和“强制单特性分解”等框架组件可以被简化。
• 当前最终框架更精简，但仍保留了规划者-生成者-评估者的核心三角，并将文件系统作为共享状态的中心。

详细精要

• 框架动态调整的原则：
• 关键是要感知任何特定模型的“峰值行为”和短板，并调整框架去填补这些短板。
• 案例一：上下文重置被废弃。Opus 4.5 有严重的上下文焦虑症，所以需要频繁重置上下文窗口。但 Opus 4.6 通过后训练解决了这个问题，可以维持一个长时间连续会话的连贯性，因此框架中“新建上下文窗口”这一机制就被弃用了。
• 案例二：冲刺分解被简化。强制将任务分解成一个个小特性并逐个喂给模型，对 Opus 4.5 至关重要。但 Opus 4.6 能够连贯地进行长达 2小时 的持续构建，不再需要被强制喂食单个特性。

• 案例三：评估器运行频率降低。以前可能每个冲刺（Sprint）后都要运行评估器，现在改为在模型完成一次大规模的生成后再运行，然后一次性将所有反馈传回。

• 当前的最终框架形态：

• 依然保留的核心：规划者-生成者-评估者 这三者构成的循环依然是系统的核心。
• 被简化的部分：许多使系统变复杂的辅助组件被去掉了。

• 共享状态的最佳实践：依然是使用 文件系统 来存放共享状态，而非依赖占用的上下文窗口。对于运行时间极长的智能体来说，这是更稳健的方案。

• 简化后的实证效果：

• 展示了一个当前最新模型在简化后框架上运行的例子，构建一个数字音频工作站（DAW）应用，耗时依旧很长，但成本约为之前的一半。
• 评估器仍在使用 Playwright 进行实际的交互测试。
• 虽然因为 Claude 还无法“听见”音乐，生成的音乐很糟糕，但应用本身的架构和功能已经非常完善。

💬 精华片段（中文）

“这里的教训不是我们的框架错了，而是它对4.5来说是对的。前沿已经移动了，所以我们运行了一个简化版来看看效果如何。” “The lesson isn't necessarily our harness was wrong, but rather it was right for 4.5, the frontier moved, and we ran a simplified version to see how it worked.”

---

37:55 给开发者的五个建议与总结

本节重点

• 重申五大关键原则：使用对抗性评估器、警惕压缩导致的信息漂移、采用结构化交接、固化和量化主观品味、深度阅读模型日志。
• 强调无需使用Anthropic内部框架，引导用户如何用现有的公开产品（如Auto Mode、自定义子智能体、Playwright MCP、Skills）来构建自己的对抗性体系。
• 最后的总结回归到如何利用现有工具开始实践的指导。

详细精要

• 开发者可以立即使用的现有工具：

• Ash分享了可以在 Claude Code 中直接使用来构建类似体系的五个“原语”：

  • 自动模式（Auto Mode）：代替危险的“全权限”模式，是运行长任务的更安全选择。
  • 自定义子智能体（Custom Sub-agents）：可以直接创建一个角色为评估器或QA的智能体，给它一个严厉的系统提示词和详尽的评分量表。
  • Playwright MCP 或 Claude for Chrome MCP：在浏览器测试方面已经非常强大。
  • 计算机使用（Computer Use）：如果构建的是原生应用，可以使用此功能。
  • 技能（Skills）：一种很好的方式来打包你的评分量表等提示词，将其融入通用的开发流程。

• 给开发者的五大核心箴言：

• 自我评估是个陷阱，请使用对抗性评估器。
• 压缩不等于连贯性。有损的摘要会造成严重的上下文信息漂移。
• 结构化的交接和干净的上下文，这是很好的实践模式。
• 不要认为主观品质无法被评分。如果你对“好”有清晰的认识，就强迫自己把标准写下来。
• 亲手去追踪模型日志。只有这样才能真正知道随着前沿推进，该在框架中删掉什么、保留什么。

💬 精华片段（中文）

“自我评估，是一个巨大的陷阱。请一定使用对抗性的评估器。” “Self-evaluation, very much a trap. Just use an adversarial evaluator.”

---

专业术语注释

术语	解释
编排框架 (Harness)	指围绕在大语言模型外部的代码、系统提示和流程管理组件，用于引导和控制模型的行为，补偿其能力的不足。
上下文窗口 (Context Window)	模型在一次处理中能接受的最大信息量（以Token计）。属于有限资源，充满时模型会“遗忘”较早的对话内容。
上下文焦虑 (Context Sentience / Anxiety)	指模型在意识到自己即将耗尽上下文窗口时，表现出急于完成任务、跳过步骤或做出草率决策的行为模式。
上下文退化 (Context Rot)	随着会话进行和上下文不断被填充，模型输出的准确性和一致性逐渐下降的现象。
压缩 (Compaction)	一种技术，用于将长对话历史总结或压缩成更短的形式，以便在不超出模型上下文窗口限制的情况下延续会话。
MCP (模型上下文协议)	一种开放协议，标准化了应用程序如何为LLM提供上下文和工具，允许模型安全、标准化地访问外部数据源和服务。
Gradual Disclosure (渐进式披露)	一种上下文优化技术。初始只加载一个工具或技能的核心描述，只有当它被真正使用时，才将其完整的指令、代码和关联资源注入上下文，以节省上下文窗口空间。
Ralph Wiggum 技术	一种让LLM在循环中工作的技术，通过反复将提示与系统状态结合来执行任务。其核心理念是“在一个不确定的世界里，可预测的失败比不可预测的成功更好”。
Playwright	一个由微软开发的自动化浏览器测试的开源框架。在本文中被智能体广泛用于实际打开网页、进行点击、截屏和交互式测试。
Puppeteer	类似Playwright，是一个Node.js库，提供一个高级API来控制Chrome或Chromium，常用于UI自动化测试。
生成对抗网络 (GANs)	一种机器学习框架。系统包含两个相互竞争的神经网络：一个生成器和一个判别器。本分享借用了这种“生成-对抗”的二元结构理念来设计智能体团队。
契约 (Contract)	本文中指生成器智能体和评估器智能体在编码开始前，通过谈判达成并记录在案的关于某特性“完成定义”的具体测试标准和验证方法。
评分量表 (Rubric)	一套用于评估工作质量的详细评价标准。在本文中，特指包含了设计、原创性、工艺和功能性四个维度的、用于训练评估器“品味”的标准体系。
Agent Teams (智能体团队)	Claude Code 中的一个功能，允许一个主智能体将任务委派给一组自定义的子智能体，且这些子智能体之间可以互相通信和协调。
API slop (AI同质化/劣质感)	指由LLM生成的、缺乏创意和个性、看起来千篇一律的、具有特定“AI痕迹”的设计或内容，通常表现为特定的配色和设计模式。
Agentic (智能体/能动性)	形容一个模型具备强大推理、规划和工具使用能力，能够为了完成复杂目标而采取一系列自主步骤，而不仅仅是响应单次指令。
Greenfield / Brownfield (绿地/棕地项目)	绿地项目指从零开始的全新软件项目；棕地项目指在已有的、复杂且有限制的代码基础上进行的开发和维护。

---

延伸思考

1. 框架设计的未来：如果模型变得越来越“智能体化”，像“规划者”这样的独立角色未来是否会像“上下文重置”一样，因为被模型能力吸收而消失在框架的演进之中？
2. 可观测性瓶颈：整个分享反复强调“人工读日志”是关键，但也承认“观测性仍是一个未解决的问题”。对于运行数天甚至数周的智能体团队，如何建立一个超越人工阅读的、能自动报告异常和决策偏差的监控系统？
3. 协作式智能体的交互模型：有观众提出，是否能让智能体在工作几小时后主动要求一次“冲刺评审”（Sprint Review），让人类在关键节点介入并调整方向。这种半自主、长周期反馈的人机协作模式是否比追求完全自主更具现实价值？
4. 非编码领域的应用：分享者提到Agent SDK已被重命名以用于更广泛用途。这套“生成-评估-契约”模式，在非编码领域（如复杂法律文件起草、长周期市场研究）的应用效果和适配挑战会是什么？

原文发表：May 18, 2026  ·  纪要生成：2026-06-19