欢迎收听跨国串门计划，这是一档专注于让中文听众无障碍欣赏全球优质外语播客的节目。通过先进的 AI 声纹克隆技术，我们不仅将内容翻译成中文，还完美保留了原主持人和嘉宾的独特声音，为您呈现全球顶尖的 AI 财经、健康与科技领域精品内容。我是主播伊凯，一位热衷于 AI 领域的产品经理，很荣幸能为您搭建这座跨越语言障碍的桥梁。
接下来，让我为您简单介绍本期我们克隆的这档节目，并分享几句非常精彩的原话。本期我们克隆的是 AI Engineer Conference 的一场技术分享，题目是 Build Agents That Run for Hours Without Losing the Plot。两位讲者 Ashpreet
Baker 和 Andrew Wilson 都来自 Anthropic 应用 AI 团队，一位做工程，一位做解决方案架构。
他们聊的是如何让 Agent 在几个小时甚至更久的任务里保持清醒，持续推进。里面有几句原话，很值得先听一听。能以可预测的方式失败，比以不可预测的方式成功更好。前沿并不会真的缩小，它只是会移动。标准模糊，批评就会模糊。只有这样，你才真正知道 scaffold 里哪些部分该删，哪些部分该留。这些话背后是一整套关于长时间运行 Agent 的实践经验。
那我们就一起来听听这期完整分享。很高兴见到大家，我是 Ash，这位是 Andrew，我们都在 Anthropic 的应用 AI 团队做工程师。这场分享的主题来自我们几周前发的一篇播客，那篇文章讲的是怎么构建真正能长时间运行的 Agent。这里说的长时间是五六个小时以上的运行，我想大家都看过这类演示，比如有公司说我们一次性做出了一个浏览器，但他们不一定会分享 Harness 里面到底做了哪些细节。
这就是我们今天想聊的内容。前半部分，我非常优秀的同事 Andrew 会讲讲我们是怎么走到今天的，讲讲我们在 Cloud Code 里发布过的一些基础能力，以及我们现在处在什么位置。后面我会再上台讲一些我们在 Harness 上尝试的更实验性的东西，也会讲几个我们看到的例子。接下来交给 Andrew，好，谢谢 Ash，也谢谢大家来参加 AI Engineer Conference 的第一场分享。
很高兴你们把这段时间留给我们。我叫 Andrew，在伦敦的应用 AI 团队做解决方案架构师，主要和很多数字原生客户以及行业客户一起工作。我会先带大家简单回顾一下历史。像是一次记忆之旅，但重点会放在我们发布过的那些东西上。正是这些东西让 Agent 能够连续运行好几个小时，甚至一次运行好几天。然后我会把时间交给 Ash，让他来讲更前沿的部分。
先看一段 Boris 在 Twitter 上的话，Boris 是 Cloud Code 的创造者，这是在 Cloud Code 一周年的时候发的大意是，一年前 Cloud 连写 Bash 命令和处理字符串转义都还很吃力，它一次大概只能跑二十分钟。现在我们已经到了这样一个阶段，几乎所有 Cloud Code。
都是由 Cloud Code 自己写出来的，而且它实际上可以一次跑好几天，所以只用一年时间变化非常大。接下来我会稍微讲一下这段历史。我先放大这里，先把问题框起来。为什么这些 Agent 很难长时间运行？我觉得大体上有三类原因。有些很直观，有些没那么直观。第一是上下文，大家都知道 context window 是有限的。
你开启一个新绘画，就像失忆一样，agent 必须从头开始，所以你需要某种记忆组件。而且在一个 context window 里推进工作时，还会出现所谓的 context rot，也就是越到绘画后面，整体一致性越差。还有一种情况是模型会表现出所谓的 context window anxiety。它快到 context window 末尾时，会变得有点紧张，然后急着把手头的事做完，这就引出了规划问题。
一般来说，模型开箱即用时并不太擅长规划，它可能想一次性把所有事都做完，比如它可能只做了半个功能就停下，也可能上下文直接用完，最后留下一个半成品应用。另一个没那么直观的问题是，模型非常不擅长判断自己的输出。我们都知道，模型可能会迎合你说你想听的话，但这件事在编程任务里同样会发生。它可能看着一个功能，明明只是半成品，或者只是实现了一点点，却说好看起来完成了，然后继续做下一件事，或者它可能做了一个按钮之类的功能，但后端其实不存在。
也就是说，按钮背后什么都没有，只是看起来像功能已经完成了。Ash，啊，后面会比较详细的讲一些新技术，专门用来帮助解决这个问题，让模型更擅长判断自己的输出。所以我们大致有两种办法来修这些问题。第一种当然是模型本身，也就是把这些能力直接轰进模型权重里。我相信大家都见过这张 meteor 图，它衡量的是在只有最小脚手架的情况下，agent 能连续跑多久，并且完成百分之五十的任务。
你会看到从 op3.7 开始，大概是一小时到一年后的 op4，已经到了十二小时，也就是整整一天。当然，我们已经让它跑得更久了，其他人也做到了。但这张图展示的是一个非常小的脚手架。第二种办法就是改 harness 本身，也就是模型外面那层脚手架。我们有 agent SDK，里面带着我们过去一直在构建的所有基础能力，核心就是 agent 循环本身。
里面有 Cloud 模型来判断该做什么，该运行哪些工具。它可能会从 MCP 服务器拉一些工具进来，也可能把一些任务委派给 Sub Agent。它还会把 C L D . M D 已加载的 Skills 斜杠命令这些上下文都带进来。这里还有一整套权限系统。随着模型变得更强，这些东西也会继续变化。但这些就是我们现在使用的核心基础能力。
然后你可以用这个框架为自己要做的事情搭建 harness，比如后面 Ash 会展示的一些内容，我们会讲到运行时间更长的 agent。还有一点很有意思，回看过去一年的发布节奏，每次我们发布一个模型，基本也都会同时发布很多 harness
方面的改动，所以这些东西其实是在一起演进。我们先回头看一下，先说更早一点的阶段，也就是一年多以前，我想大家都还记得那个时期，Cloud 在 Cloud AI 里有 artifacts 区域。
Sunny 3.5 是第一个在编程上真正显示出潜力的模型，它已经能检查自己构建出来的东西，并在这个基础上继续迭代。那是在 Claude Code 之前一个很让人眼前一亮的时刻。后来我们也发布了 Computer Use，它可以开始到处点击截图，也能测试自己的代码。同时还有 MCP 规范，让它可以使用工具。
接下来进入 Cloud Code，时间是二零二五年二月，也就是一年多以前，三点三点七发布了，在 Kubernetes 上达到了当时的领先水平。Cloud Code 也以研究预览版发布。我从那次发布里摘了一句话，我觉得很有意思。Cloud Code 的目标是更好地理解开发者如何用 Cloud 编程，从而指导未来的模型改进。
所以本质上，我们发布 Cloud Code 的时候，它带有一定实验性质，目的就是反过来帮助我们改进基础模型本身。你会看到这个趋势。随着时间推移，模型会变得更强，Harness 的某些部分可能会变得没那么必要，或者会继续演化。另外说一下这些幻灯片，左下角列的是每次发布关注的一些重点，比如上下文规划、验证，还有一些数据。
不过我不会逐项读完。接下来大概是去年五月左右。OpenS 和 Sonnet 发布了。总体来说，这些工具在管理自身上下文、把任务做到完成这两件事上变得强了很多，而且不需要 reward hacking 之类的做法。Cloud Code 也正式可用了。我们还发布了 Cloud Code SDK，也就是支撑 Cloud Code 的那套 harness。
这里从时间线里稍微插一段。我想现在大家都知道 Ralph Wiegum 技术了，你们可能不知道，它其实是去年七月出现的。当时 Jeffrey Huntley 最早发布的那篇文章，他真正开始受到很多关注，大概是在去年十二月左右。比如那时候，很多人开始自己尝试。Claude 在 Claude Code the Harness 里发布了我们自己的 Ralph Loop，但本质上这是一个相当简单的技术。
你拿一个 prompt 把它喂给 Claude Code CLI，然后循环运行，直到所有任务都完成。当然，它比这稍微复杂一点。我觉得大家经常会把它讲的太简单，实际上它有几个阶段。首先，他会做某种规划，把这个 prompt 拆成几个不同的功能，然后他会从里面选一个任务，开启一个新会话，用一个全新的 context window 来做。
所以很多这样的概念都被用在 rough looply。但我觉得它之所以吸引这么多注意，是因为它看起来特别简单。而且他的说法是在一个非确定性的世界里，要做一个确定性低差的东西。换句话说，能以可预测的方式失败，比以不可预测的方式成功更好。我们在 Cloud Code 里为这个做自己的插件时，你会看到一个主要区别。
我不知道大家能不能看出来，有些人会说这不是真正的 Ralph Loop。原因是它只是在单个 Cloud Code 绘画里运行，它不会创建新的 context window，而是依赖随着时间推移发生的压缩，所以它也许不能算真正的 real loop。但你可以设置最大迭代次数，也可以设置一个安全词，然后本质上一个 stop hook 会在 Cloud 通常要停止的时候拦截它。
如果任务还没完成，它就会继续运行，直到触发其中一个退出条件。接下来讲 Sonnet 4.5，这个时候模型整体开始变得更强，它又开始能自己处理上下文了。也就是说，这时候模型更有上下文意识。能跟踪已经消耗了多少 token，当它快到 context window 末尾时，它能理解这一点，并且自己管理上下文。
Claude Code 二点零也发布了，我们在这个版本里引入了检查点，也就是持续跟踪代码的变化，必要时可以回退到绘画前面的某个状态。然后我们把 Claude Code SDK 改名成了 Agent SDK。因为它的用途其实更通用，不只是用来编程。现在我们聊了很多编程，但我觉得很有意思的是把这些长时间运行的 harness 用到其他领域。
到这个阶段，Cloud Sonnet 4.5 大概能跑三十小时左右。后来 Haiku 4.5 和 Opus 4.5 补齐了整个系列，这时候事情就变得很有意思，因为突然之间同时运行很多个 Agent 变得很划算。Opus 4.5 在规划方面也变得很强，所以我们可以开始做这样的事：用 Opus 4.5 来做规划，再用 Sonnet 4.5 作为主力，真正执行所有代码。
接下来几个月也很关键，因为我们发布了技能，技能也很适合高效使用上下文。它用的是一种逐步展开的思路，一开始只加载技能的头部元信息，而不是把所有工具描述都塞进去。那些工具描述一上来就可能占掉很多 context window。如果这个技能被实例化，才会加载技能正文的其余部分。后面还可能跟着一些参考内容，甚至是能更确定性运行的代码。
之后还有更多上下文方面的改进，比如程序化工具调用，也就是说，不是运行一堆工具，把所有结果都拉进上下文里再处理。而是现场写代码，运行一系列工具调用，最后只把最终结果拿回来。这些做法本质上都是为了更好的使用 context window。这一页内容很多，到这个阶段大概是在十一月左右，我们发布了第一篇关于长时间运行 agent 的博客。
讲怎么构建这类 agent，我前面已经讲过很多概念，所以这里应该不难理解。比如一个人可能会写一句很模糊的需求，帮我写一个浏览器，或者做一个 Slack 克隆版，或者做一个 Salesforce 克隆版。在我们构建的这个 harness 里，第一步会有一个初始化 agent，拿到这条简单 prompt，然后把它拆成一系列持久化产物。
第一个产物是功能列表，比如 x 个功能文件叫 feature list json，因为我们发现模型有时可能会覆盖导尔文件，但不太会直接覆盖 json 文件。这还挺有意思，他还会写一个进度文件，当然也会初始化 Git 仓库，写好 init 脚本，然后他会有一个标志用来记录这些功能是否已经完成，也就是是否通过了所有测试。
接下来会进入这个 Harness 循环，里面有多个步骤。第一步还是在一个新的 context window 里，先搞清楚状况，当前工作目录是什么，进度文件里写了什么，然后做一次冒烟测试或者运行 any 脚本。这样他就不用每次都重新想该怎么做，可以直接把服务器跑起来等等。接着他会选择一个功能，只选一个还没有通过所有测试的功能，然后实现这个功能做一些真实测试。
这里的验证循环很像人会做的方式，我们用的是 Puppeteer。如果一切都通过，它就会写 git commit，并且修改这个功能的状态标记为已通过。如果还有未完成的功能，它就会在新的 context window 里继续这个循环。所以，这里我们开始叠加很多概念：新的 context window、这些持久化产物、验证循环，以及一开始就做好的规划。
你会看到，这基本上就是这些长时间运行 harness 的第一版。继续我们的历史回顾，接下来是 Opus 4.6、 Sonnet 4.6，这些模型很厉害，因为 Sonnet 4.6 基本上用 Sonnet 的价格提供了接近 Opus 级别的智能，它又一次成了很多 cloud code 场景里的主力。Opus 4.6 则在规划方面变得非常强。
我们当时会说它是一个非常 agentic 的模型。Opus 4.6 很擅长决定该用哪些工具，也能运行更长时间。如果你还记得那个仪表图，会看到在一个很简单的 harness 下，它从大约四小时跃升到了十二小时。所以这个模型非常非常 agentic。伴随这些模型以及我们之前做的一些研究，我们发布了
Agent Teams，它的想法是在 Cloud Code 里给你一种更通用的方式，让你可以搭出自己的一组自定义 Agent。
Agent Teams 的创新点在于，不再是所有东西都汇报给主 Agent，而是这些子 Agent 之间也可以互相通信。他们有自己的协调方式，只有在需要的时候才汇报给主 agent。我们还引入了服务端压缩，也就是说，这些模型现在可以一直跑下去，压缩可以在服务端自动发生，还有一百万的 context window。
所以现在我们有了一个很大的 context window。你会看到模型本身在变强，也许很多任务只放在一个 context window 里就能跑完，不一定总是需要不断开新会话。你也能看到很多做法会随着时间慢慢变化，这差不多就是整体概览。你可以在这张表里看到我刚才分享的所有不同版本，也能看到它们是怎么变化的。
比如从 Sunet 三点七的一小时到 Opus 四点六的十二小时，我们自己也有一些例子。以前用 Opus
三点五时，有些任务可能要二十分钟。现在我们会构建很完整的应用，不是说必须跑三十个小时才行。通常我们看到的是三到五个小时就能做出一个功能非常完整、开箱就能跑的应用。真正有意思的是，模型变强之后，har ness 并不会消失，它会随着模型变化而不断演进，找到模型里的短板，再用 harness 把它补上。
这件事非常有意思。然后你再用 harness 的这一部分去训练模型，到了某个时候，也许你就可以把那部分完全拿掉。这种迭代循环会随着时间不断发生，伴随着我们越来越多的联合发布。希望刚才这段回顾 Cloud 近近的小旅程还算有意思，也能说明它和长时间运行的 Agent 有什么关系。接下来我交给 Ash，让他继续讲讲今天的最新状态。
我先问一个小问题：现在在座有没有人有 Agent 正在后台跑任务？趁你们在这里的时候帮你们干活，只有一二三个人，好吧？人数可能应该更多一点，希望到这一段结束的时候，你们能带走一些想法，并且真的拿去实践。刚才讲的是历史。我很喜欢 Andrew 提到的那句话：前沿并不会真的缩小，它只是会移动。所以我想稍微讲讲一些很简单的 harness 模式。
我们内部一直在玩这些模式，用它们来构建那些很酷的一次性演示应用。同时，我们也在后训练里实验这些东西。在强化学习里，我们想让模型以及他们的整体行为更擅长自主工作。如果你试过让一个 agent 去审查他自己的 PR，你大概就会明白我接下来要讲什么。这个总体思路基本上是很不客气的，从 GAN，也就是生成对抗网络里借来的。
你有一个生成器模型，然后有某种判别器，它们之间存在某种对抗压力。生成器负责构建，评估器负责打分。这里的核心想法啥是？我们把 context window system prompt。还有任务本身都完全拆开，这里的评估器不是只读 diff，它会真的用 playwright
打开实时页面，到处点击试各种东西，最后它会把定下来的批评意见交回给真正的生成器，然后你继续跑这个循环，这和现在大多数人的做法形成对比，很多人是用一个核心的 cloud code 绘画，让它检查自己的工作，然后这样循环下去。
至少对我来说，一个显而易见的问题是，如果评估器也只是一个 L M，为什么它不会也直接盖章？通过我们在这里利用的关键点是，没错，评估器仍然是一个大语言模型，没错，它仍然会偏向于喜欢大语言模型风格的输出，但是把一个独立的批评者调得更严格，其实是很可行的。可是把一个构建者调成有一定自我批评能力，我觉得就没那么容易。
一个很好的类比就是人类自己，让我去评价一件漂亮的艺术品或者一顿精致的饭，这很容易；但要让我自己真的去画那幅画或者做出那顿饭，就难多了。所以我们在这里做的就是利用 L M 作为批评者和作为生成器之间的能力差距。接下来我想讲的是，你到底应该怎么设计这些批评者？这和创建好的 eval 的过程很像，但在全站应用的语境里，一个东西好不好会涉及很多模糊的方面，不只是它能不能用，还包括它好不好看、感觉好不好。
这些产品里是不是也有品味的成分？这就是我们一直在做大量实验的地方，尤其是当我们试图在后训练里给 Claude 注入设计和品味的时候，同时我们也在创建这类前端设计技能，把它们发布出去，并且总体上提升我们模型的前端设计能力。我们是这么想的。大多数人会说品味没法打分，但我们觉得只要你的判断足够明确，再把它写下来，其实就能打分。
至少我们现在的做法是做一个评分标准，里面有四项设计、原创性、工艺感和功能性。我们会把权重更多放在设计和原创性上，根据当时用的是哪个模型，这四项的权重也会调整。但目前 Opus 4.6 在功能性上已经做得不错了，所以我们真正想解决的问题是怎么避免紫色渐变，还有那种很典型的 AI 垃圾美学。然后我们会用参考网站上的 few shot 事例去校准这个评分标准。
这样，evaluator 的品味就会慢慢向我们的品味收敛。我给你看一个例子，看看它在实际里大概是什么样。这里就是一个模型跑类似循环的例子：generator 生成，evaluator 启动 playwright，打开页面截图，然后按那四个标准打分，写批评意见，再教会给 generator。这些例子都只是 HTML 和 CSS。
我大概跑了四个小时，五到十五轮。我觉得这里有意思的地方也是比较独特的地方，是它会转向。如果你只用单个 agent 循环，不一定能得到这种效果。你可以想象 generator 卡在四个标准里的某一项上，比如它在原创性上一直很挣扎，分数一直很低。我们用的这种 GAN 风格的 harness。就会把整个东西丢掉，从头再试。
但如果是单次生成或者 Ralph Loop，它会一直试着在同一个东西上打补丁。这种能力，也就是在很长时间跨度里不断纠正方向，我觉得是很独特的。它来自把构建一个东西所需要的不同角色拆开。刚才讲的算是我们怎么看前端这一部分。但如果要从好看的页面走到真正能用的完整应用，我们又加了一个角色，也就是 Planner。
这听起来也很简单，他最终只是拿到一行 prompt，然后把它拆成一个非常刻意保持高层的规格，说明他做的事情其实是把整体工作流拆成一系列 sprint。他不做的事情，也是今天大多数 harness 会做的事情，是一开始就试图规划产品里很细的技术细节。原因是第一，他还是很可能出错，一旦他出错，这个错误就会贯穿后面每一个 sprint，在好几个小时的时间跨度里被不断放大。
如果你眯着眼看这个结构，它其实就是一个很简单的 PMIC 和 QA 组织结构。这不是我们发明的，我们只是给每个角色都分配了自己的 context window。我觉得真正值得讲的是，在这种设置里，generator 和 evaluator 之间的胶水。在 Generator 真正写下第一行代码之前，我们会让两个 Agent 先协商什么才叫做完成。
比如 Generator 提议说：“我要构建 X 功能，你应该通过测试 Y 来验证它。” Evaulator 可能会反驳说：“其实范围太大了，而且你提的测试有点太弱，你还漏掉了 X、Y、Z 这些边界情况。”于是他们基本上会通过磁盘上的文件来来回回沟通，一个写一些 Markdown，另一个读它，然后反复迭代，直到双方都同意。
到了这个条件满足之后，才真正开始构建。然后 evaluator 会按照这两个 agent 自己定下来的契约来评分，而不是按照 planner 一开始一次性生成的原始规格说明来评分。这件事重要，是因为它把用户故事，也就是规格说明，转换成了更具体、更可测试的断言。某种意义上，就是一份契约。这样，Planner 就不用在一开始把所有东西都规定的过细。
我觉得这就是 Ralph Loop 一直没有的关键创新。它有一个类似固定的 Plan .md，但另一边并没有谁一定会跟主循环争论。这又回到了前面说的独立的 Context Window 以及对抗性的压力。我给你看一个很简单的 Prompt 对比一下，单独循环和我们刚才讲的 Harness Prompt，基本上就是做一个复古游戏制作器，就这一句。
我不是要说服你认为这一定是构建应用最划算、最高效的方式。你可以看到，第一，它目前耗时极长；第二，它非常贵。但我们马上也会看到很多东西在单独循环里跑不起来，只有用了这个 harness，才真正开始工作。这里就是没有 harness 的时候，它大概的样子，至少这是开场界面。这个版本很简单，有点无聊，但看起来还不错，对吧？
如果整个应用就这样，你可能也能发布，但我觉得这更像是个诱饵。这是 Sprite 编辑器。看起来也还行，画布在，调色板在，针时间线和实时预览也在，可能有点挤。颜色选择器只是一些黑色色块，但基本能用。很明显，Agent 确实理解自己想做什么。可是真正必须做的那件事，也就是游戏模式里的实体渲染、分数、生命值，还有一个真实游戏需要的所有东西就不行了。
按方向键没反应，按空格键也没反应。Agent 其实完全不知道该怎么测试自己，也不知道玩一个游戏并且成功到底意味着什么。这是同一个 prompt，同一个模型，这里就是断点。表面上看还可以，但你真的把它推到极限，它就失败了。如果我们用同一个 prompt，同一个模型，但跑 harness，结果就变成了这样。
大概花了两百美元，跑了六个小时。首先，他决定给自己起名叫 Retro Forge，他决定做一个新项目对话框，还做了一个很漂亮的画布，这些都不在我们的 Prompt 里，所以这些都是 Planner 自己决定的。好，产品决策应该长这样。然后另外两个 agent 再决定，那我要怎么测试它？如果看 sprite 编辑器，我们有一个完整的五十四色调色板。
项目对话框里那个巴比特的设定也贯穿了下来。你能按真实游戏尺寸看到 sprite。整体上，它作为一个产品完整的多。我们还有一个全新的 AI 关卡助手，这里开始有点递归了。Planner 决定说好，我们应该有一些 AI 功能。规格里其实只有这么一句很模糊的话，Harness 把这句话变成了应用内部一个完整的 AI 关卡助手，而且这个助手还是它正在构建的应用的一部分。
所以有人可以进来说，嘿，创建一座城堡，旁边有 Sprite 守着它之类的。如果没有 planner，单 agent 跑法甚至根本不会尝试看这件事。那句话根本不会变成一个需要处理的工作项，最后实际结果也真的落地了。比如游戏模式左上角有一整套 debug head，你一眼就能看出来，这是为了让 evaluator 更容易测试。
那些数字是实时的，物理循环也真的在跑，方向键能用，玩家会移动，也会和城堡墙发生碰撞，因为 evaluator
真的启动了游戏，真的尝试玩。他知道，为了让这个游戏变得真实可用，哪些功能必须被测试。这个输出和前一个输出之间的差别完全来自脚手架。归根结底，它只是一个很简单的循环，但结果至少非常不一样。如果你好奇 evaluator 抓到的是什么，其实都是很基础的东西，比如 fast A P I 路由顺序的问题。
它能通过所有单元测试，但到了生产环境可能真的会坏。evaluator 能抓到，还有 delete 键里某种布尔逻辑 bug。这些问题之所以能被抓到，只是因为 evaluator 真的在用这个应用，在 RL looply 这类问题可能会通过 CI，但这种具体程度不是偶然出现的。这就是这些模型现在能做到的细节层级。
我们前面说过， generator 和 evaluator 会为这个应用彼此写 contract。他最后决定有二十七条 contract 标准。我们发现，只有这种颗粒度才能让发现的问题变得可执行。标准模糊，批评就会模糊。generator 只会耸耸肩，然后随便改点东西。但如果标准足够细，agent 就知道，好，我需要修的就是这一行。
我觉得有意思的是，我也想诚实说这一点：开箱即用的 Claude 作为通用 QA Agent，其实非常非常糟糕。Andrew 在他那部分也稍微讲过，大家在一般的 LLM Judge 系统里遇到的那种迎合倾向和宽容偏差，在这里同样会出现。早期运行时，大多数时候 Q Agent 会找到一个 bug，然后说以后再修吧，可能要两周，接着就算结束了。
所以我们实际上花了非常多时间，一点点检查，尝试调 prompt，把小的布局 bug 边界情况这些都喂回 promptly。我也希望这里面有什么秘诀，但现实是要把这个系统搭好，做得好。核心手艺其实就是读运行轨迹。我们主要的调试循环就是这个不一定是跑更多实验，而是看 agent 实际做了什么。找出它的判断和我们人类判断不一致的地方，然后针对那里调 prompt，这和读调用栈用的是同一种能力。
我们有一个工具上的小技巧，就是把 agent 的对话记录导进文件里，再用另一个 agent 去 grab，或者让另一个 agent。通读这些记录，然后让它自己更新 prompt，这样哪怕是在搭这个 harness 的过程中，也能形成某种闭环。最后我想讲的是，随着模型不断变强，应该怎么调整你的 harness？
现在有很多讨论在说 harness 设计是不是已经没用了，尤其是有了这些模型之后，我写这部分的时候还只是 Opus 4.6。但就算是更高一档的模型，也会有这个问题。我觉得关键在于你要摸清每个模型各自那些很突出的行为特点，然后调整你的 harness 去补它的短板。Andrew 前面也讲过一点，比如不同绘画之间重置上下文这件事，我们后来完全去掉了。
Open 4.5 以前有很严重的上下文焦虑，但 Open 4.6 就没有这个问题了。这也是后训练带来的变化之一。所以一个连续绘画再加上压缩，就已经足够处理很长的绘画了。至于把任务拆成一个个 sprint，我们没有特别强的执念，但它对让 Opus 4.5 跑起来非常关键。可是 Opus 4.6 已经能连着做两小时的构建，并且保持连贯，不一定非得一次只喂给它一个功能。
Evaluator 应该多久跑一次？这个节奏也变了。以前我们基本每个 Sprint 都跑一次，现在我们是在模型一次性生成结束后再跑，然后把结果传回去。所以 Harness 还是同一个 Harness，我们只是把里面具体的循环和流程配方简化了。这里的教训不是说我们的 Harness 错了，而是它对 4.5 来说是对的。
前沿模型往前走了，所以我们跑了一个简化版，看看效果怎么样。这就是我们现在最终设置的大概样子：planner、generator、evaluator。这一套循环仍然是系统的核心，但你可以看到，我们砍掉了很多其他组件，那些组件让系统比实际需要的更复杂。另外，就像前面提到的，我们也非常喜欢直接用文件系统来保存共享状态。
对于长时间运行的 agent，我们一般不会太依赖 context window。这里是一个例子，展示的是简化版 harness 跑在我们最新模型之一上的效果，还是一样。非常非常贵，但你可以看到它的成本大概只有之前那些运行的一半儿。原因只是我们把做法稍微简化了一些，但它依然能跑很长时间。这个例子是一个 DAW，基本上就是一个音乐创作应用。
Agent 会设置速度和调性，写下旋律，搭出鼓组轨道。这里是 evaluator 真正在进入应用本身做测试。我们确实听了里面的音乐，很明显，Claude 现在还听不见，所以音乐相当糟糕。但总体来说，这个应用做得很好，也相当完整。放在上一个模型版本，这种东西根本跑不起来，但现在只用几轮就能做到，这就是 Andrew 前面讲的那条曲线，真正落到实践里的样子。
最后，我想说，你不一定需要我们这一整套 harness 才开始思考这些问题。我们一直在努力把这些元语的一部分直接发到 cloud codeley，但你也完全可以自己动手搭一个类似的东西。我们刚发布的 Auto Mode 可能是我最喜欢的东西之一，它有点像更安全的 ViLo 模式，也就是说不用一直开
Dangerously Skip Permission，我们已经有 Custom Sub Agent 这个元语了，对吧？
它可以承担你的 evaluator 或者 QA 角色，给它一个严格的 system prompt，再配一份非常详细的评分标准。Playwright MCP 或者 Cloud for Chrome MCP，现在做 web 应用相关的事儿已经非常非常好。如果你在做原生应用，也可以直接用 Computer Use，还有 Skills 也是一种很好的方式，可以把你的评分标准打包进日常开发流程里。
如果你要拍一张照片，我会说这页幻灯片最值得记住。这里有五件事：第一，自我评估很容易踩坑，直接用一个对抗式的评估器；第二，压缩不等于连贯，带损耗的总结真的很容易漂移；第三，结构化交接和干净的上下文是一个非常好的模式；第四，不要觉得主观质量没法打分。如果你对东西应该长什么样有明确看法，那就逼自己把它写下来。
我们发现这对模型生成应用的质量有非常大的影响。最后真的就是坐在模型旁边读它的 traces，只有这样你才真正知道 scaffoldly 哪些部分该删，哪些部分该留。尤其是在前沿模型不断变化的时候，我这边就这些。非常感谢大家来听，也欢迎去看我们的博客文章。不过现在想直接进入问答，因为我们已经讲了快一个小时了。
如果大家有问题想问我和 Andrew，直接提就好，我们会尽力回答。谢谢，我是 Johan，来自 Paulside，我有一个问题想问。你们通过读日志来改进评估器的时候，这更像是每个项目单独做一套，还是更像一种可以跨项目复用的 secret sauce？我们的目标非常明确，就是尽量把它做成可复用的方式。
我觉得任何人都可以把它调到只生成某一种非常具体的应用，那当然也可以。但到了那个程度，它其实和你自己去提示 Claude Code
自己做这件事没有太大区别。我觉得关键在于能不能找出一些通用模式，覆盖模型共同的弱点。比如前面说到前端设计那一块，我们知道自己认为好的设计应该是什么样，你可以给他例子，比如一个真正漂亮的产品长什么样，AI slop 又长什么样，这类东西泛化的相当好，所以这套东西当时主要围绕 Web
应用，但也很容易应用到其他类型的事情上。
谢谢你们的分享，非常有意思。我想问问你们怎么看模型里的 dumb zone 和 smart zone 这个概念？我的理解是，以前大概是百分之四十，现在有了一百万上下文，大概就是十万 token 左右。我对 rough loop 的理解是，它就是为了处理这个问题设计的。基本上我们让模型一直待在 smart zone 里，也就是说把任务切到十万 token 以下，让它在这个十万上下文区域内执行任务。
但我从你们的分享里听起来，你们好像在建议现在不要再这么做了，因为我们现在可以依赖压缩交接等等。这是你们建议的方向吗？还是说在 smart zone 和 dumb zone 这个概念下，relf loop 这种模型仍然有自己的位置？从 Ash 的分享和我的分享里，你可以看到一百万 context
window 现在已经 GA 了，所以你能用的上下文更大，模型也更 agentic 了，所以他们能在这个 context window 里更长时间保持连贯。
而且在四点六发布的时候，我们决定从多个新的 context window 转向一个持续运行的长会话，再配合压缩。所以我觉得要用多个全新的绘画，还是用一个长时间运行的绘画，可能仍然取决于你的使用场景和你的评估结果，要看你观察到哪种方式效果最好。但至少在这种通用的生成器加评估器模式里，配合 Opus 4.6，我们看到单一绘画是可行的。
不知道你要不要补充一下？我觉得这也只是一个暂时性问题。Context rot 在某种程度上是今天模型的一个缺陷，而且相比仅仅上一代模型已经轻很多了。所以你说的那类做法有没有位置？我觉得有，要看使用场景。但我会把它看成这样一类东西。我会一直等着某个模型版本发布，等到可以把它删掉。可以这么说。我一直对 playwright 有很强的 formo。
你刚才提到 Playwright MCP 也有 Playwright Skills，你能不能讲讲怎么改进 Playwright？因为我想象中我会希望浏览器开着，然后我能看到模型在里面工作，甚至可能还能引导它，比如开几个标签页之类的。所以这里是不是有什么我错过的创新，还是说 Playwright MCP 真的已经够好？
你会建议大家用它吗？Playwright MCP 或者直接用 Cloud for Chrome MCP，后者在浏览器控制这件事上算是稍微更稳一点。我不太明白你为什么想看着它一步步操作。你当然可以看，但我觉得这其实是信任缺口。我们想做到的是，你把任务交给他，信任他去做、去测试，而且你有信心他做得对，然后你再回来检查。
结果一开始肯定会有一些迭代，你会盯着看、读 trace，直到你觉得可以信任他。但至少在我们内部，我做全站应用开发的时候，现在已经到这个程度了。用 Opus 4.6，我可以比较稳定的信任模型，它会自己去读网络错误、控制台错误，真的会在应用里导航，该放大的地方会放大。现在这些模型的视觉能力已经足够好，能识别元素上的文字重叠之类的问题。
现实一点说，上一代模型之前还做不到，所以我会推荐试试。我有点好奇，关于 Generate Evaluate 这种模式会发生什么。你能往里面无限 stock 吗？还是说它会停下来，因为 evaluator 不够好？能不能多讲讲？不好意思，你能再说明一下吗？我刚才有点没听清。比如说，我让它创建一个很酷的游戏，带一些功能。
如果 generator evaluator 模式会创建。Contract 构建应用，那他最后会给我一个结果，对吧？那我能不能再启动一次，说好把它做得更好？我还不满意。然后 Generator Valuator 这个模式会接着处理，把它变得更好吗？还是说到某个点 Valuator 就不行了？然后只会说就这样吧。
首先，如果你希望这个过程里有某种程度的人在回路中，那就在这个循环里的某个位置实现 hook 就行。让我有点意外的是，这种通用模式，尤其是 4.6 这一代模型，包括 Sonnet 和 Opus，都非常愿意把所有东西推倒重来。哪怕他已经对某个东西做了十轮，如果他发现没法沿着 evaluator 的 rubric 有效往上爬，他也很愿意全部扔掉，从头开始。
所以，我们玩这类东西的时候，并没有自然的倾向于加某种恢复机制，或者人在回路中的干预系统。我们本来以为会看到，但其实没有怎么观察到你说的那种行为。evaluator说算了，我放弃了，我们就把它交出去吧。他更愿意把所有东西都扔掉，然后重新开始。这种行为我们以前没见过。以前 generator 自己会有点像是为自己的作品感到自豪，会说：“我才不要把整个东西重做。
” 我也见过一些例子，evaluator 会有点受够了，然后说：“好，你现在这个做法明显行不通。”能不能把所有东西删掉，重新开始？不知道你们怎么样，但我做 vibe coding 的时候也经常这么干。作为人类，我也会想利用一个新的 context window，不用再面对一个已经很乱的代码库等等。所以现在看到 motion 也能到这个点，其实挺有意思。
我也简单补一句：显然你也可以把那个代码库用 cloud code 打开，然后从你停下的地方继续。这点应该不用多说。我觉得我们总体上也在思考。如果工作流变成更多来回反馈会是什么样？因为有一种极端情况是，你让他给你做一个很复杂的游戏应用，但你不知道他要花三小时还是二十小时，这就有点不清楚。所以中间也许会有某种形态，更像一个反馈循环。
我很喜欢你们这个想法。这里有一个人的元素，比如 P M 工程师 evaluator，P M 这个角色，很多时候要处理范围蔓延，要控制时间之类的。但你们现在就是把它放出去，让工程师在沙箱里玩很久。这里是不是需要一个 harness 循环？最后回到 planner 那里，他是不是还需要再动一次？我感觉可能因为我们都是工程师，所以就决定管他呢。
先把 PM 放一边，你们需要一个 PM。这里其实就是评估器和构建器之间那种契约关系发挥作用的地方。为了保留上下文，我们通常会把产品经理生成的主规格说明定期插入到这些绘画里，这样它始终有一个参考点，知道我们实际还在尝试构建的是什么。然后构建器和生成器不对，是构建器和评估器的主要功能就是弄清楚到底哪些功能测试和契约才能真正满足这份规格说明。
但我们不这么做的原因是我们不希望规划器成为这个循环里的核心部分，它应该保持在很高层，它真正的作用是画出这个产品大概可能是什么样子的硬边界，但它的工作不一定是进来干预，说其实这个功能不可能做，然后我们不该做这个功能，也不该让它自己去改自己，我们想把这种上下文关系尽量只保留在构建器和生成器之间。话虽如此，这个循环我已经用在很多不同方式里了。
它不一定只能是一个生成器加一个构建器这种对抗式的权衡，也可以用在一个由多个独立 Agent 组成的工作流里。比如说，如果你想生成评测，也可以用类似的 Harness，你可以让它像这样运行。先有一个规划器，再有一个合成数据集生成器，配一个 QA agent，然后交给一个集成器，由它真正把东西接起来。它也可以有一个 QA agent，最后再有一个最终环节。
基本上你可以把这种生成器加评估器的结构放进一个多步骤工作流里，每个构建器可能都有稍微不同的功能，作为一个更长工作流的一部分。所以要让事情不跑偏，可以有不同做法，具体取决于任务，也取决于你怎么拆分。你可以把这个通用模式拆成更具体的任务或者工作流，大概就是这个意思。你好，你刚才提到有些后期任务不可能由更早的模型完成，能不能讲讲你们是怎么比较不同模型上的这些任务的？
比如你们会不会把同一个任务分别丢给 Opus 4.6、Opus 4.5，还是说这更像是一种手工打磨的 harness 和模型一起演化出来的设置？我想我们可以稍微回顾一下历史。如果你看第一篇关于长时间运行 Agent 的博客，再看最近那篇，会发现差异相当大。其中一个差异就是我们刚才讨论的 Initialize Agent 会先构建一份非常完整的规格说明。
比如包含两百个不同功能，然后循环就必须真的去执行这两百个功能里的每一个，这可能会导致一些错误的设计决策，但它又被迫按这种方式行动。而现在，我觉得你可以用 Open 4.6 设定一个更通用、更偏创意方向的指引，然后再让生成器和评估器这个循环去运转。但确实，模型选择会非常影响你的 harness 设计。
当然，在理想世界里，你可以把所有东西都丢给 Open 4.6。但如果你有成本上的考虑，比如你可能会用 Open 4.6 做规划，再用 Sonnet 4.6 做编程或者执行，这是我们经常看到的一种做法。但还是那句话，如果你要为每个环节构建特定的 sub agent，最好有一些评测，这样你才能理解在那个模型和那个 prompt 下，它面对这个任务表现怎么样，然后再去优化。
对于从这种一次性应用走向长期存在的产品，你们有什么建议吗？比如几天几周之后还要继续改东西，那你需要把哪些产物保存给未来的实例，让他知道之前发生过什么，我能改什么，我应该改什么？这是我们现在正在做的事情。我们内部会把类似的模式用在一堆比较零散的事情上，可以这么说。所以现在的流程大概是把这个东西启动起来，让它在某个远程服务器上跑。
然后我可能在这场分享之后再回来检查一下，接着我会在 Code Codely 直接手动迭代打磨一些粗糙的地方，类似这样。至于你实际怎么设置这个 Harness，我们默认会在这种循环里使用文件系统状态。原因之一就是它很简单，另一个模型可以直接进来用 grep
搜一遍，然后接上前面已经发生的事情。但有一件事我喜欢做，就是在这个循环里塞一点 prompt，基本上是让它把学到的东西和状态写到某个 JSON 文件里，因为模型通常不会太频繁地覆盖那个文件。
这样做的好处是，你等于给另一个模型留下了一串面包屑，让它之后能接着往下看。所以说实话，对我来说，关键是我要怎么指示这个 harness，让它给之后接手的人留下线索，然后这个人可以再用 cloud code 继续往上做。一般来说，那个文件的结构可能就是试过这个 evaluator，发现了这个 bug，实现了这个修复，这个修复有效，打勾，然后继续。
这样你就有一个带时间戳的日志，可以看到模型试过的所有东西，做过的修复以及最后的状态。另外还可以有一组实时更新的文档，很高层的写一下，这是文件结构。说实话，有这两个文件，对 Cloud Code 和一个人来说，基本就足够接手，然后开始继续迭代这个应用了。我们现在就是这么做的。很好，听你们讲这些很有意思。
首先，恭喜你们这次分享讲得很好。我想问的是，这里好像有两种做法，一种是 agent team 多个 agent 互相协作。另一种是明确的 generator critic 设置，不过某种意义上 agent team 也是类似的结构，主 agent 只是别人做事，然后也可以充当子 agent 的 critic。
那现在还有哪些失败模式，让我们仍然需要专门的 generated critic harness，而不是只靠 agent team 本身？另外，你们估计还需要多少代模型，我们才能完全依赖 Agent Team？我可以先回答这个问题的第一部分。首先，Cloud Code 的一个限制是它用的是同一个
Harness，也就是 Agent SDK，所以从技术上说，你应该可以把这种模式做进 Cloud Code 里。
Agent Team 是一个可能有用的框架，可以用来做这件事。比如你可以让 generator evaluator 互相通信，或者让 generator 作为主 agent，evaluator 作为 agent team 里的一个成员。但我觉得它更多是从我刚才分享的第一篇博客文章演化出来的。某种程度上，那些结果推动我们把它做得更通用，更容易被大家使用。
不过，一个明显限制是 Cloud Code 必须在你的机器上运行。用 Agent SDK 的话，你也可以把它放在更像云端的环境里，放在沙箱环境里长时间运行，而且不会失败，也不需要你在自己的机器上跑 Cafe。不过，我觉得 Cloud Code 是一个很好的试验场。你可以先用它搭这些 harness 做实验，探索什么有效。
之后你也许再把它做进 agent SDK，然后真正部署成一个独立应用。我的建议还是多实验，看看 agent teams 对你来说是不是合适，或者普通的 sub agent 又或者其他组织方式是不是效果更好。我觉得现在大家用 agent teams 用的很多，关键就在这里，我们其实没有一个特别强的立场，说在任何一个时刻哪种设置一定是最好的。
Boris 经常会更新他的推文，说这是我现在的做法。Agent Teams 是内部很多人很喜欢的东西，所以我们就想，好，那就发布出去，看看真实使用场景里大家怎么想。我不是说我们一定会这样做，但我们也经常会把一些东西下架。我确实把 Generator-Evaluator 这种模式看成 Teams 这种思路里的一个子集，用来思考 Sub-Agent 设计。
它们本身不一定是互相矛盾的。你可以想象 Teams 经典的拆分方式可能是前端、后端，再加一个在它们之间做整合的角色。这些 Subagent 里每一个可能都值得配一个自己的 Critic，也就是跟它搭配的一个 Agent。所以你能看到这两个概念其实是有重叠的。这里背后的总体想法是，现在大多数人在跑
Claude Code 的时候，目标并不是让它用六个小时一次性生成一个应用，所以这不一定是我们 Moren 要在那里发布的基础能力。
我还想问一件事：你们有没有试过让 Critic 拿到 Generator 的上下文？如果他对 Agent 的轨迹，或者说 External 的执行过程有一些了解，会不会更有用？现在 critic 是这样的吗？我们用的是交接计划。对于你说的那种做法，我会非常谨慎。我们试过，但这会把两个模型流之间的思路搅在一起。
我觉得更有效的做法是只让它判断输出，不要让他说你在构建这个东西时，因为做了 x 走错了一步，所以导致了这个问题。更有效的是让 evaluator 只说这里有个问题，然后让 generator 单纯反思自己的工作，再自己想办法修这个问题。否则你会看到，我们发现模型很容易说服自己某个东西能不能跑，而这种判断也会影响到 evaluator。
关于这一点，我最后补一句，我觉得如果是训练团队，也许可以训练 generator 去预测。Critic 现在会说什么？也就是让他更诚实的面对自己做过什么之类的。也许我们会做这个。Yes，我想多问一点可追踪性。比如我会用 super powers 或者我自己的 prompt 生成多个子任务来实现我的软件或者应用，但问题是我其实不知道怎么回头看它到底在哪里出错了。
即使我想回去看，也不知道怎么找到那些痕迹。所以我的问题是，你们用什么来做可追踪性？Yes，当后代有五六个 agent 同时跑的时候，你们怎么处理？老实说，很多时候就是手动读 trace。我们经常这么做。Anthropic 总体上也是经常手动读 trace。我们也拼过各种临时工具，比如把 Claude 指向一堆 trace，再配上自定义 prompt，试着找出循环里的问题，比如它是从哪里开始跑偏的。
我会说，我们把这当成第一遍筛查，用来大概看看哪里可能出问题。但老实说，到目前为止，我们内部最好用的方法还是手动读 trace，只有这样，你才真正能理解模型到底想做什么。谢谢你的分享，我有几个问题。首先，你们怎么衡量一个 harness 和 agent 组合的质量？这听起来像是凭感觉判断，比如从零开始做一个应用，但假设你进入一个新项目，也可能是既有项目，这感觉还是像凭感觉，或者像某种艺术。
能不能把它做得更科学？还是说这本来就不可行？至少我们的思路是在 generator 和 evaluator 两个层面，把评分标准写得非常细。比如前面讲到的那四类标准，那还是很高层的。我们会用一套评分标准来判断设计品位。然后我们会给这个应用的不同部分都设这样的标准，比如一部分只看设计元素，另一部分看 API 设计，再比如代码质量之类。
我们把这些作为不同的评分标准，让系统围绕它们做 hill climbing。evaluator 的任务就是鼓励 generator 朝这些标准爬坡优化。所以对任何一个应用或者输出，我们都有一个信号，能看到模型一开始在这些标准上的位置。然后也能看到我们最后到达了哪里。像你说的，如果是在新的代码库里做，这个信号没那么有用，但它仍然适用，只是你要用不同方式启动这个循环。
你可以把 evaluator 指向某个代码库，然后告诉他这是我们现在的状态，再给他你想达成的规格说明。让这个循环围绕这些标准迭代，所以它不一定是在最后只跑一套评测，更像是先定义好我们认为什么叫好，然后让 evaluator 和 generator 一起提出一组需要满足的测试或者契约，再让 harness 围绕这些东西做 hill climbing。
这种方式不太适合跨不同产品、不同运行来比较，但在同一个产品或者同一次运行里非常有用。另外，这个模式就像你说的，很适合从零开始做项目，但它也很有倾向性。比如，它可能用 React 数据库，用 Postgres 后端，用 Node，但你的既有应用可能用的是完全不同的东西，或者我们定义的那些好设计模式评分标准。
放到你的项目里可能完全不一样，所以我觉得我们更想把它作为一种模式提出来，然后你再针对自己的应用去调整。它能用吗？你们会不会分别指挥 Harness？你们作为一个团队怎么协作？我发现当我共享屏幕用对话方式工作的时候，别人很难跟上。反过来，我也觉得要口述该写什么 Prompt 很麻烦。你们团队怎么协作？
会有团队共同拥有的 Harness 吗？这会不会是 Cloud Code 的一个好功能？我觉得可能确实还需要继续做这方面的工作。我们内部经常会出现这种情况：有人先想出一些点子，然后不同团队从下往上开始采用。接下来，最早提出这个想法的人就需要继续维护它，让它能组合、能泛化、适配不同团队。不同团队也会再改一改，让它对自己负责的那一段代码库有用。
但从这个意义上说，我们还没有特别成熟的东西。就算只是可观测性，前面也有人提到过。总体来说，对于这种超长时间运行的 Agent，这件事还没有完全解决，所以这确实是一个很有意思的 Greenfield 软件方向，值得继续探索。这个点确实挺有意思，它到底应该是在 cloud codly 或者甚至在
cloud day AI 里做成一种协作体验，还是更多利用软件工程里的最佳实践，比如版本控制、提交 commit、发 pull request，我觉得都说得通。
如果你是自己一个人在做，也可以用 git work tree 之类的东西，避免多个不同功能同时改文件系统时互相覆盖。不过说到协作，我觉得这件事可能还没有那么常发生，因为就像 Ash 说的，大家往往是从零开始把这些项目做出来，然后再展示给公司里的其他人。我是 Jose，来自 Mercedes-Benz Research and Development。
谢谢你们的分享。我刚才看的时候就在想，这看起来很像一个 Scrum 团队或者一个 Feature Team 在一个产品上持续工作更长时间。所以我在想，在这种场景里，Human in the Loop 会是什么样子？因为你们这里有点像一个 Sprint。你们有没有想过类似 Sprint Review 的时刻？
比如过一段时间之后，系统来问你这个人类。嘿，这是我们过去两个小时做出来的东西，你觉得怎么样？我们是不是也要让 agent 经历工程师在 scrum review 里经历的那种创伤？这次分享背后的总体想法，以及我们想做的事情，其实是尽量 A G I pilled，也就是说，我们怎么构建 harness，让里面不需要 human in the loop，这会是什么样子？
我们今天是不是已经把它用在所有事情上？当然不是，但目标是这种技术或者模式应该能很好的扩展。理想情况下，大多数事情都不需要 human in the loop。如果确实需要人类介入，最主要的 primitive 可能就是 hook。也就是在某种特定停止条件下，比如配合一个 evaluator，把控制权交还给人，然后允许人输入某种开发者消息，再继续这个循环。
这大概是最简单的实现方式。但说实话，我们现在更多是从哪些事情可以完全自主完成这个角度来探索，而不是先拿着 code code，再去想怎么让它本身变得更强。这更像是一次偏 greenfield 的 agent 设计探索。当然，我明白，我只是说。如果我有机会在几个小时后 review 一下，也许我就能用更好的方式引导它，这样八个小时之后。
它产出的结果会更接近我真正想要的那个项目。我明白你的意思，但问题是，这应该成为 Harness 的一个永久功能吗？还是说它只是你在构建 Harness 的时候就应该通过 Prompt 设计进去的一件事？我们会这么做，我们会让这个 harness 循环运行，比如我们可能会同时启动十个不同结果的生成，其中三个成功，七个以各种随机方式失败，然后我们会坐下来看那七个。
失败案例读完，他们接着调整主 harness 的 prompt，再试一次，一直重复，直到我们觉得可以放心，让它完全自主运行。所以最终目标对我们来说仍然是让它自主跑起来，而不是相当于放弃 harness，然后说好吧，我们就在这里放一个人，帮他兜住各种可靠性问题。我们更希望一开始就把这些东西嵌进 harness。
本身做尽 honestly，你们有没有用它构建过什么非 greenfield 的东西，或者说生产级的东西，比如 cloud code 本身里的某些东西？你们有没有用它做过真实功能，并且一路做到最后？我觉得这套方法主要还是适合全新项目，已有项目可能需要更多控制，尤其是你开始搭建自己的评估标准和模式的时候。
在已有项目里，我们看到的情况是，如果你看整个软件开发生命周期，而不只是大家开始用 Cloudy Code 做的编程部分，会有一些新的自动化方式。比如，现有自主监控在运行，然后它生成某种 issue 或功能请求，这个请求再交给一个 agent，让它一路完成 pull request。接着已经有某种 PR review 在发生，最后可能只是由你在真正合并之前再看一遍。
所以在已有项目里，确实还有别的方式可以自动化整个软件开发生命周期。但这个特定模式，如果你的项目里没有大量测试，也没有为项目做定制，我觉得它可能更适合全新的应用。你们有没有真的做过什么全新应用？比如内部工具或者别的你们一直在用的东西，不只是 demo
那种。坦白说，内部工具我不太方便讲太多，但有个不错的例子是，你在 Claude Code 里看到的很多新东西、有意思的东西，我们和团队交流一起做这些东西的时候，其实都用了不少这里面的经验，哪怕只是一般的上手使用 Claude Code，比如他们怎么 prompt 主模型，让它启动一个 sub
agent 去处理某件事。
或者像 Andrew 刚才说的，在监控和修 bug 的循环里，生成修复的时候，要不要让一个单独的评估器和一个生成器同时去处理同一件事？所以很多原则都能用上。至于是不是一比一照搬，可能不是，更像是把这里面有用的部分，或者你觉得适合某个场景、某个领域的部分拿出来，然后用你自己的方式做下去。谢谢。你说读 trace 的时候，真的是直接读原始输出吗？
还是说你会更具体的 prompt？他比如把这些写到文件里，我关心这些内容，我想看到这些东西。不是，你得把整个东西都读完，全部读完。我觉得做 agent 的时候，一个很重要的能力就是，尽量站在模型的角度去理解它。我们之前在做 Cloud for Chrome 的 Agent Harness 时，有个挺有意思的例子。
Cloud for Chrome 是我们做的浏览器使用相关的东西。我们会做一个实验，想象一下，你要浏览一个网页，到处点击，但你基本上是闭着眼睛在做。每隔十秒，你睁开眼看一眼静态页面，然后又闭上眼，接着还得继续操作。真正把自己放到模型的位置上，这其实是一种需要培养的共情能力。真正做到这一点，唯一的办法就是尽可能多地和这些模型相处，同时也要一行一行读它的输出，想为什么它会这么判断。
哦，我大概能理解它为什么会这么做，然后你再调整下一次给它的指令。让它做得更好，所以我觉得这种文化很有用。我们作为一个团队，会花很多时间闭上眼睛，尝试去浏览网页，就是类似这样的练习。然后要把这些学到的东西真正放进你的 prompt 模板里，或者放进 Claude1. dot md，或者做成一个 skill，也可以只是更普遍的理解未来怎么避免同类行为。
我知道 Claude Code 现在也有绘画的自动记忆，所以它会在运行过程中持续记住一些小东西。不过，做一些 traces 以后，你通常能很快看出问题可能出在哪里。好，我们就到这里吧。我觉得还剩几分钟，不过我们之后也会在现场。如果大家想问问题，或者只是聊聊，都可以来找我们。不管怎样，感谢大家今天来参加这个 session。