#577.长时运行 Agent：开发者如何让 AI 连续干活不跑偏，模型前沿快速迁移下的工程取舍

episode

跨国串门儿计划 not yet transcribed

▲ 0

Transcript

This episode hasn't been transcribed yet Upvotes decide what gets transcribed next — 0 so far. Sign in to upvote

More from 跨国串门儿计划

#365.风险共担与非对称性：塔勒布对话纳瓦尔，拆解真实世界的运行逻辑 1h 9m · 20 Dec 2025

All episodes from 跨国串门儿计划 →

Report any issue

Source

Recorded09 Jun 2026

Publisherfeed.xyzfm.space ↗

Handlerec:18782851

Show notes

📝 本期播客简介本期我们克隆了：AI Engineer Conference 的技术分享《Build Agents That Run for Hours (Without Losing the Plot)》— Ash Prabaker & Andrew Wilson, Anthropic本期节目是一场非常硬核但极具实践价值的 Agent 工程分享。来自 Anthropic 应用 AI 团队的 Ash Prabaker 和 Andrew Wilson，系统拆解了一个关键问题：如果我们希望 AI Agent 不只是完成几分钟的小任务，而是能连续运行数小时、甚至几天，构建完整应用、调试复杂系统、持续自我推进，工程上到底需要做什么？Andrew 先回顾了 Claude Code 和 Agent SDK 在过去一年中的演进：从早期模型只能跑二十分钟，到如今可以在合适的 harness 下运行数小时甚至更久；从 Computer Use、MCP、skills、检查点、Agent teams，到服务端压缩和百万上下文窗口，模型能力和脚手架设计一直在彼此塑造。Ash 则进一步分享 Anthropic 内部正在实验的长时运行 harness：将 planner、generator、evaluator 拆成独立角色，用对抗式评估器替代自我评估，让 Agent 真的打开网页、点击、测试、写批评意见，并通过一份具体的 contract 来判断“什么叫完成”。他强调，很多时候提升 Agent 能力的关键不是再加一层复杂架构，而是认真读 traces，理解模型为什么跑偏，再决定 scaffold 里哪些该保留，哪些该删掉。这期适合所有正在做 Agent、AI 编程工具、Claude Code 工作流、自动化测试、AI 产品原型和长任务自动化的开发者、产品经理和技术创业者收听。👨‍💻 本期讲者Ash Prabaker，Anthropic 应用 AI 团队工程师，关注长时间运行 Agent、前端生成、对抗式评估器、Agent harness 和后训练实验。Andrew Wilson，Anthropic 应用 AI 团队解决方案架构师，常驻伦敦，主要与数字原生客户和行业客户合作，关注 Claude Code、Agent SDK、企业级 AI 工作流和长时运行 Agent 的实际落地。⏱️ 时间戳00:00 开场 & 本期简介问题的提出：为什么 Agent 跑久了会失控01:29 分享开始：Anthropic 应用 AI 团队要解决什么问题02:17 Claude Code 的一年变化：从跑二十分钟到跑好几天03:20 长时运行 Agent 的三大难题：上下文、规划、自我判断04:44 两条解决路径：把能力训练进模型，或用 harness 补齐短板Claude Code 与 Agent SDK 的演进史05:11 Agent SDK 的核心循环：模型、工具、MCP、subagent 与权限系统06:10 Claude 早期编程能力：Artifacts、Computer Use 与 MCP06:56 Claude Code 的研究预览：用真实开发反馈改进模型07:27 Opus 4 / Sonnet 4：上下文管理和任务完成能力提升08:00 Ralph loop：在非确定世界里构建“确定性地差”的循环09:20 Claude Code 2.0：检查点、压缩和更强的上下文意识10:04 Haiku / Opus 4.5：子 Agent 变便宜，规划与执行可以拆分10:27 Skills 与程序化工具调用：更高效地使用 context window第一代长时运行 harness11:17 从一句模糊 prompt 到持久化产物：feature list、progress、git repo12:01 每轮只做一个功能：新上下文、冒烟测试、实现、验证、提交12:53 Opus 4.6 / Sonnet 4.6：更 agentic 的模型与 Agent teams14:21 模型变强后，harness 不会消失，而是会移动前沿新的 harness 思路：把角色拆开15:16 Ash 接棒：前沿不会缩小，只会移动16:00 借鉴 GAN：generator 负责构建，evaluator 负责批评16:47 为什么不要让 Agent 自己审查自己17:30 如何设计“严格的批评者”：把品味变成可评分标准18:45 设计、原创性、工艺感、功能性：前端质量如何量化19:40 加入 planner：从好看的页面走向完整可用的应用20:33 先协商“什么叫完成”：generator 与 evaluator 的 contract21:13 为什么 contract 是 Ralph loop 缺少的关键创新案例：同一句 prompt，结果为何天差地别21:38 复古游戏制作器：没有 harness 时，看起来能用但实际玩不了23:02 加上 harness 后：Retro Forge、项目对话框、Sprite 编辑器与 AI 关卡助手24:04 evaluator 真正玩游戏：方向键、碰撞、HUD、物理循环都被测试24:32 真实测试能抓到什么：路由顺序、删除逻辑、生产环境 bug25:12 二十七条 contract 标准：标准模糊，批评就会模糊调试 Agent 的真正手艺25:44 开箱即用的 Claude 并不是好 QA：宽容偏差与迎合倾向26:02 如何调 evaluator：读运行轨迹，找模型判断与人类判断的偏差26:18 用 Agent 读 Agent traces：让另一个 Agent grep 日志、更新 prompt模型变强后，harness 应该怎么变26:39 harness 设计不是一劳永逸：要随着模型行为调整27:05 为什么某些 context reset 可以删掉27:47 evaluator 运行节奏的变化：从每个 sprint 跑一次，到生成后再跑28:21 最终简化版：planner、generator、evaluator 仍是核心28:52 DAW 音乐应用案例：更少轮次、更低成本、更完整应用给开发者的落地建议29:17 不必照搬 Anthropic 全套 harness：Claude Code 里的可用原语29:40 auto mode、custom subagent、Playwright MCP、Claude for Chrome MCP、skills30:02 五个关键 takeaway：不要自评、压缩不等于连贯、结构化交接、主观质量可评分、读 tracesQ&A：可复用性、上下文与工具选择30:51 这套 evaluator 调优是项目专属，还是可复用 secret sauce？31:52 smart zone / dumb zone：Ralph loop 在百万上下文时代还有用吗？33:40 Playwright MCP 与 Claude for Chrome MCP：是否应该看着模型操作浏览器？35:00 generator-evaluator 能否无限迭代，让应用越来越好？37:24 PM 角色是否应该回到循环中，控制范围蔓延？Q&A：模型比较、长期维护与团队协作39:37 如何比较不同模型：Opus 4.5、Opus 4.6 与 harness 一起演化41:06 从一次性 demo 到长期产品：留下 JSON 状态、时间戳日志和文档面包屑42:51 Agent teams vs generator-critic：两者是竞争关系还是组合关系？45:42 critic 应不应该看到 generator 的执行轨迹？46:45 可追踪性怎么做：为什么 Anthropic 仍然大量手动读 trace47:42 如何衡量 harness 质量：用细评分标准做 hill climbing49:54 团队如何协作：共享 harness、版本控制、worktree 与未解决的可观测性问题Q&A：human-in-the-loop 与真实生产51:21 human-in-the-loop 应该像 sprint review 一样存在吗？54:01 这套模式更适合 greenfield，还是已有生产项目？55:52 读 traces 到底怎么读：为什么要完整读原始输出57:20 结束：继续在现场交流🌟 精彩内容💡 能可预测地失败，比不可预测地成功更好Andrew 在讲 Ralph loop 时提到，一个简单但重要的工程原则是：在非确定性的模型世界里，尽量构建可预测的失败模式。Ralph loop 的价值不只是“循环调用 Claude Code”，而是把任务拆开、开新上下文、持续推进，并用确定的退出条件控制风险。“能以可预测的方式失败，比以不可预测的方式成功更好。”🧠 模型前沿不会缩小，只会移动Andrew 和 Ash 都强调，随着模型越来越强，harness 不会消失，而是不断演化。过去必须用多个新 context window 解决的问题，可能在新模型上通过单一长会话加压缩就能解决；过去必须拆成 sprint 的任务，新模型可能可以连续构建两小时仍保持连贯。“前沿并不会真的缩小，它只是会移动。”⚔️ generator-evaluator：不要让模型自己给自己打分Ash 认为，长时间运行 Agent 的一个关键改进，是把生成器和评估器拆成独立角色。评估器不只是读 diff，而是用 Playwright 打开真实页面、点击、截图、测试，并把具体批评交回给生成器。这样可以避免模型自我评估时过于宽容、过早宣布完成。“把一个独立的批评者调得更严格，其实是很可行的；但把一个构建者调成有自我批评能力，就没那么容易。”📋 标准模糊，批评就会模糊在 Retro Forge 案例中，generator 和 evaluator 最后形成了二十七条 contract 标准。Ash 强调，只有标准足够细，evaluator 的反馈才会变成可执行的问题，而不是“感觉还不够好”这种泛泛批评。“标准模糊，批评就会模糊。generator 只会耸耸肩，然后随便改点东西。”🎨 主观质量也可以评分很多人认为“品味”无法评估，但 Anthropic 的做法是把它拆成设计、原创性、工艺感、功能性等维度，并用 few-shot 示例校准 evaluator 的审美。这样可以避免典型的 AI slop，比如紫色渐变、模板化布局和缺乏产品感的界面。“如果你对东西应该长什么样有明确看法，那就逼自己把它写下来。”🕵️ 做 Agent 的核心手艺：读 tracesAsh 多次强调，调试 Agent harness 没有太多神秘秘诀，关键就是读运行轨迹。要一行一行看模型为什么这么判断，哪里和人类预期不一致，然后把这些发现写回 prompt、CLAUDE.md 或 skill。“只有这样，你才真正知道 scaffold 里哪些部分该删，哪些部分该留。”🧩 长期应用需要留下“面包屑”如果一个 Agent 生成的应用未来还要继续维护，Ash 建议让 harness 把状态写入文件系统，例如 JSON 状态文件、时间戳日志、bug 记录、修复记录和文件结构说明。这样下一个 Claude Code 实例或人类开发者就能接手。“你等于给另一个模型留下了一串面包屑，让它之后能接着往下看。”🌐 播客信息补充本播客采用原有人声声线进行播客音频制作，也可能会有一些地方听起来怪怪的使用 AI 进行翻译，因此可能会有一些地方不通顺；如果有后续想要听中文版的其他外文播客，也欢迎联系微信：iEvenight在小宇宙查看该单集文稿

Ask this episode

“What did the council decide on item 42?” — answered with the speaker and the moment.