播客听见世界的声音，看见思想的刻度

来自 Google Chrome DevRel 团队的 Tara Agyemang 介绍了 WebMCP——一项拟议中的网络标准，旨在取代当今 AI 智能体所依赖的脆弱屏幕抓取循环（DOM 解析、无障碍树分析、截图像素计算、坐标点击），转而由浏览器直接暴露一套具名、类型化、附有描述的工具菜单。WebMCP 提供两条实现路径：声明式 API 可从 HTML 表单属性自动生成 JSON schema，命令式 API 则支持注册带有显式 execute 块的自定义 JavaScript 工具。演示中，Gemini 2.0 仅用三次工具调用便完成了演唱会购票，相关规范已可在 Chrome 146 的侧边栏检查器扩展中试用。 ## [00:15] DOM 抓取之痛：今天的 AI 智能体是怎么工作的 买两张 Afro Beats 音乐节的门票听起来很简单。但对当前的 AI 智能体而言，这意味着：解析完整的 HTML DOM、遍历无障碍树、截图、做像素坐标运算找到按钮、点击——然后发现广告加载完毕，整个页面向下移位了 200 像素。Agyemang 现场演示了全过程：用嵌入 Chrome 侧边栏的 Gemini 对着一个演示购票网站操作，让人一眼看清楚，一句自然语言请求和最终提交表单之间，究竟藏着多少 token 消耗和脆弱的推断。 > *"这真的很脆弱，光是做这么点事就不知道烧掉了多少 token，我都不敢猜，肯定不少。"* ## [03:02] 无障碍先行：WebMCP 之前的必答题 在介绍 WebMCP 之前，Agyemang 先点出一个前提条件：语义化 HTML 和扎实的无障碍标准并非可有可无的地基，而是让网站在默认情况下对智能体可读的关键。正确的 ARIA 角色、有意义的标签和清晰的 DOM 结构，即使不引入任何新 API，也能大幅减少智能体的理解成本。 > *"让你的网站对所有人都无障碍，它自然也就对 AI 智能体无障碍了。"* ## [03:53] WebMCP 是什么：给智能体的结构化工具菜单 WebMCP 是一项尚未最终确定的拟议网络标准，核心思路是翻转信息不对称：不再让每个智能体自行逆向推断网站能做什么，而是由网站作者主动声明一份工具菜单，列出具名、类型化、有描述的工具供智能体直接调用。Agyemang 借用了 USB-C 的比喻：任何符合规范的智能体都能说同一套协议，任何符合规范的网站都能响应。 > *"不用再让每个智能体去猜你的网站能做什么，你直接给它们一份工具菜单，告诉它们怎么跟你的网站交互。"* ## [04:43] 演示：用 WebMCP 工具走出迷宫 第一个演示使用了 Chrome DevRel 团队自制的迷宫逃脱游戏，旁边显示着 Model Context Tool Inspector——一个列出当前页面所有已暴露工具的 Chrome 扩展。页面加载时只有一个工具：`start_maze_game`。调用后，工具列表扩展为方向移动工具（`north`、`south`、`east`、`west`）、查看工具以及道具管理工具。随后 Agyemang 输入自由文本提示（"向右，向上，再向右"；"走完迷宫"），Gemini 1.5 智能体将每条指令映射到正确的工具调用，自主迭代推进。迷宫被刻意设计成只能通过智能体接口通关——页面上没有任何可点击的按钮——工具调用循环是唯一的通路。 > *"AI 智能体拿到我的提示，把它匹配到具体工具——比如移动工具。它解读了我说的'向下向右'，把它转成了 north、south、east 方向，然后发出去了。"* ## [09:58] WebMCP 与 MCP 之别：客户端与服务端 Agyemang 预料到最常被问到的问题：这不就是 MCP 吗？区别在于作用范围。MCP 把智能体连接到服务端应用和数据源；WebMCP 实现了 MCP 的工具部分，但完全运行在浏览器中——浏览器窗口必须保持打开，所有工具执行都在页面的 JavaScript 上下文里发生。她把两者的关系类比为 JavaScript 和 Java：有所借鉴，但不可互换。实际意义在于，WebMCP 覆盖的是那些天然与用户当前视图绑定的智能体工作场景：填写复杂的多步表单、浏览有状态的 UI 流程、根据屏幕上可见内容个性化购物体验。 > *"WebMCP 让工程师能够为浏览器内的 AI 智能体提供工具，它专门针对客户端功能。"* ## [12:35] 两种 API：声明式与命令式 WebMCP 提供两条实现路径。**声明式 API** 只需在现有表单元素上添加少量新的 HTML 属性（`tool-name`、`tool-description`），浏览器会自动生成完整的 JSON schema。`agent-invoked` 布尔属性让服务端能区分智能体提交与人工提交。**命令式 API** 适用于更复杂的场景：开发者手动构建 schema 对象并调用 `registerTool()`，附上足以让智能体正确选用的描述，再编写包含普通 DOM JavaScript 的 `execute` 块（验证输入、调用现有函数、操作状态），最后返回结果对象告知智能体执行结果。命令式路径目前更为普遍，因为现实中大多数流程超出了单个表单的范围。 > *"execute 块本质上就是写普通 JavaScript——你也许已经有现成的函数，直接在这里调用就好。"* ## [15:16] 演示：三次工具调用买到演唱会门票 回到最初的购票场景，这次在已接入 WebMCP 的演示网站上操作。Agyemang 输入："帮我买两张 Summer Vibes Festival 的 VIP 票。"Gemini 2.0（演示从 1.5 升级到 2.0）恰好发出三次工具调用：`search_concerts` 按名称找到活动，`open_concert_page` 用返回的演唱会 ID 跳转到对应页面，`purchase_ticket` 传入数量和区域参数完成购买。每一步 UI 都同步更新，包括区域选择器和数量选择器。智能体在最终结账前主动暂停，把总价（356 英镑）呈现给用户确认。Agyemang 特别说明，这个手动确认步骤是有意为之：涉及真实金额的操作，人类应该始终在智能体提交前看到将要发生的事情。 > *"您消费了 356 英镑，好的，我来刷谷歌的信用卡。"* ## [17:46] 上手指南：Chrome 146、检查器与反馈方式 WebMCP 目前在 Chrome 146 及以上版本处于早期预览阶段。Agyemang 推荐使用 Chrome Canary，将实验性 flag 与日常使用的浏览器配置隔离开来。上手需要先在 `chrome://flags/#web-mcp` 启用测试 flag，再从 Chrome 应用商店安装 Model Context Tool Inspector。其余内容可参考两份资源：早期预览项目的注册博客文章（含初始文档、最佳实践和示例实现），以及包含所有演示（含迷宫）的 GitHub 仓库，其中还有一个用于对网站已声明工具进行自动化测试的 eval CLI。API 仍在每周迭代；在规范稳定之前，Google 正在积极征集摩擦点反馈和 bug 报告。 > *"我们不必再将就今天这种脆弱的屏幕抓取方式，而是可以用 WebMCP 工具把每个网站都变成智能体的高性能 API。"* ## 实体 - **Tara Agyemang**（人物）：Google Chrome 团队开发者关系工程师，本次演讲者兼 WebMCP 倡导者；GitHub/X 账号 @taraojo。 - **WebMCP**（概念）：拟议中的网络标准，让网页向浏览器内 AI 智能体暴露结构化、类型化的工具，从而消除 DOM 抓取；截至 Chrome 146 仍处于实验阶段。 - **MCP（Model Context Protocol）**（概念）：WebMCP 所参照的父协议；MCP 将智能体连接到服务端应用，WebMCP 则负责客户端浏览器工具的暴露。 - **声明式 API**（概念）：WebMCP 实现路径之一，通过在现有表单元素上添加 HTML 属性实现；浏览器自动生成 JSON schema。 - **命令式 API**（概念）：WebMCP 实现路径之一，通过 JavaScript 中的 `registerTool()` 实现；支持在 `execute` 块中编写任意 DOM 逻辑。 - **Model Context Tool Inspector**（软件）：Chrome DevRel 团队开发的 Chrome 侧边栏扩展，列出当前 WebMCP 页面暴露的所有工具；可在 Chrome 应用商店获取。 - **Google Chrome DevRel**（机构）：负责开发 WebMCP、迷宫演示、检查器扩展及 eval CLI 的 Google 团队，同时管理早期预览项目。 - **Gemini**（软件）：Google 的 AI 模型，在两个演示中均作为浏览器内智能体使用；购票演示从 Gemini 1.5 升级到了 Gemini 2.0。

WorkOS 产品负责人 Garrett Galow 开发了 Studio，专门打破每家公司都深陷其中的那个循环——解释问题、等工程师、拿到答案、发现还差一个关联查询、在 Slack 里收到一张马上过时的临时表。Studio 让任何人都能用自然语言查询 Snowflake、Linear 和 Notion，拿到实时答案，还能把这个答案固化成可复用的确定性 Widget，Widget 的代码直接对接数据源执行，无需再经过 LLM。可靠性来自三个工程决策：预检序列在工具真正被调用时才注入 schema 上下文；分层规则显式告诉模型不要相信自己对 WorkOS 产品的既有知识，必须拉取一手来源；验证步骤在将 Snowflake 查询固化进 Widget 之前先跑一遍确认结果。 ## [00:14] WorkOS 与今日主题 Galow 用 10 秒介绍公司背景——WorkOS 是为 Cursor、Anthropic 和 OpenAI 提供 SSO 等开发者层功能的企业平台——随即表明这不是他今天的重点。本次分享聚焦于 WorkOS 如何在内部运转，以及他们造了什么工具，让整个团队而不只是工程师都能更快回答业务问题。 > *"只要你登录过 Cursor，你就用过 WorkOS——不管是用户名密码，还是走企业 IDP。"* ## [01:02] 业务问题的漫长等待循环 Galow 描述的问题人人熟悉：一个市场或客服同事有个问题，自己不会写 SQL，只能向工程师解释需求，等待，拿到半个答案，再追加一个关联查询，再等，最后在 Slack 收到一张立刻过时的临时表。就连 Retool 或内部看板也帮不上忙，因为它们只能回答固定问题——一旦需要多一个筛选条件或多一列，整个请求流程就得重来。 > *"有人对业务有个问题，但自己可能没有技术能力去找答案。他们得解释问题，解释为什么要问、怎么理解，然后等。"* ## [02:33] Studio 演示：从问题到实时看板 Studio 是一个内部工作台，包含网页看板和 Slack 机器人，底层是接入了 Snowflake、Linear 和 Notion 集成代理的 LangGraph Agent，运行 Claude Opus。Galow 现场提问：WorkOS 营销网站上哪些内容带来了最多新团队注册？Agent 跑完预检，判断需要查 Snowflake，在调用时刻拉取 schema 上下文，执行若干查询，约 90 秒后返回一张排名表。 更有意思的是接下来：他让 Studio 把这个答案封装成带时间切片筛选器的可复用 Widget。Widget 是声明式 JavaScript，直接调用底层 API。此后每次运行，LLM 完全不再参与，只是代码重新对 Snowflake 执行查询。屏幕上显示的结果是博客、更新日志和文档按注册转化率排名，并支持按内容分类筛选。 > *"Widget 就像一段沙箱代码，它本身就是 UI、API 调用和查询的集合，能驱动一个完整可用的工具。"* ## [07:34] Radar 客服 Widget：客服团队的自助工具 Galow 演示了第二个 Widget，专为 WorkOS 客服团队围绕 Radar（其反机器人安全产品）构建。以往客户问"这个用户为什么被拦截"时，客服要互传临时 SQL 或等数据工程工单。Radar Widget 让任何客服输入客户邮箱，Widget 在线重跑其固化的查询，返回完整的登录尝试记录以及每次是否被标记。 客服人员可以自己搭这些 Widget：一次性问题直接拿到答案；如果同一个问题反复出现，就做成 Widget 在内部共享。全程不需要平台团队介入。 > *"我们的客服团队，如果只是一次性问题，完全可以自己拿到答案；如果发现同一个问题问得很频繁，他们可以把它做成 Widget，然后分享给其他同事。"* ## [09:55] 三大支柱：预检序列、分层上下文、结果验证 可靠性这一节是整场分享的技术核心。Galow 列出让 Studio 能真正交给非工程师使用的三个设计决策。 **预检序列**——在做任何事之前，Agent 先跑预检：所有集成是否已连接？上下文是否足够回答这个问题？如果不够，先追问。每个数据源的 schema 上下文只在具体工具被调用的那一刻才注入，而不是提前全部塞进去，这样可以保持 context window 干净，留给真正的推理。 **分层上下文**——提示词栈分三层：基础层（Studio 默认配置）、组织层（共享规则）和工具编辑层（会话级上下文）。关键一点是，模型被明确告知不要相信自己对 WorkOS 产品的既有知识，因为训练数据会过时而产品迭代很快。它被要求去内部文档和实时数据源拉取信息。 **结果验证**——Agent 生成的每一条 Snowflake 查询，都要先执行一遍再固化进 Widget。一条语法合法的 SQL 可能返回零行；如果 Agent 没发现这一点，Widget 就会带着错误结果上线。先跑一遍，可以在变成用户看到的"真相"之前就捕获这类问题。 > *"我们告诉 LLM 专门不要相信它对我们产品的既有知识——有时模型的训练数据是过时的。我们的产品变化很快。所以我们明确告诉它：去一手来源，从我们的文档里查。"* ## [12:54] Q&A：Schema、治理、跨工具查询与权限控制 问答环节涉及三个实际设计问题。 **脏 schema**：有人问 Galow 在用 Studio 之前是否清洗了 Snowflake。他没有。复杂的关联——客户实体到用户，深达四层——只需在 Snowflake 上下文块里编码一次，LLM 从这段描述里学习数据库的"怪癖"，不需要整洁的 schema，也不需要 RAG 数据库或 schema 重写。但上下文块需要明确写入筛选字段的规范（例如"只拉未删除的实体"），因为模型会默默忽略这类条件。 **Widget 治理**：有观众提到信任问题——一个生成查询有偏差的 Widget 会成为没人质疑的"真相"。Galow 承认问题存在，但表示实际命中率足够高。把数据质量规则直接嵌入上下文块（活跃状态筛选、软删除保护）能消除大多数静默错误，剩余的偏差通常明显到足以被发现。 **跨工具 Widget 与架构**：被问到 Widget 是否能同时从多个工具取数，Galow 确认可以——一个 Widget 可以在同一界面同时调用 Snowflake 和 Linear。Widget 是 JavaScript，底层 API 调用各自独立，数据合并就是写代码。Widget 一旦生成就完全确定：刷新时不再调用 LLM，没有推理成本，没有结果波动。 **权限控制**：目前采用每人自己 OAuth 的模式（每位员工自行连接自己的 Snowflake 和 Linear 凭证），比较繁琐。WorkOS 正在通过自家的 Pipes 产品构建"组织连接器"——管理员统一配置连接，再由基于角色的规则管理每个用户的读写权限。 > *"最终产物在这方面非常可靠。Widget 生成之后，LLM 就不再参与了——除非我再回来说：'帮我改一下这个 Widget。'"* ## 实体 - **Garrett Galow**（人物）：WorkOS 产品负责人，Studio 的构建者和本次演讲者。 - **WorkOS**（组织）：面向开发者的企业平台，为 Cursor、Anthropic 和 OpenAI 等公司提供企业 SSO、反机器人（Radar）和第三方集成（Pipes）。 - **Studio**（软件）：WorkOS 内部自然语言工作台，允许任意员工查询 Snowflake、Linear 和 Notion 并构建可复用 Widget。 - **Snowflake**（软件）：WorkOS 内部主要分析数据仓库，云端数据仓库服务。 - **Linear**（软件）：问题追踪工具，作为 Studio 的数据源之一接入。 - **Notion**（软件）：知识管理工具，作为 Studio 的数据源之一接入。 - **LangGraph**（软件）：驱动 Studio LLM-工具交互循环的 Agent 编排框架。 - **Claude Opus**（软件）：Studio 内部使用的 Anthropic LLM，因其在查询编写和推理任务上的质量而被选用。 - **Radar**（软件）：WorkOS 的反机器人与欺诈检测产品，Radar 客服 Widget 是本次演示的核心案例。 - **Pipes**（软件）：WorkOS 的第三方集成产品，正在扩展以支持 Studio 内的组织级连接器。 - **Convex**（软件）：Studio 的会话状态存储，用于跨会话保留 Widget 和对话历史。 - **Widget**（概念）：Studio 的核心输出产物——声明式 JavaScript，直接调用数据源 API，每次刷新确定性执行，不再调用 LLM。 - **预检序列**（概念）：Studio 在回答查询前先运行工具连通性和上下文完备性检查，并在工具调用时按需注入 schema 上下文的做法。 - **分层上下文**（概念）：Studio 的提示词架构，叠加基础默认层、组织规则层和会话上下文层，并明确指示模型不要依赖其对 WorkOS 的过时知识。

Anthropic Applied AI 团队的两位工程师 Ash Prabaker 和 Andrew Wilson 拆解了让编码 Agent 持续高效工作五小时以上的真正门道：一年间模型与 harness 共同演进，把运行时长从 20 分钟推到 12 小时以上；他们一次性生成完整应用的内部 harness 配方包括，写"刻意模糊"规格的 planner、把"完成"谈判成可测试契约的 generator 与对抗式 evaluator、让设计品味变得可打分的评分准则，以及一个基本靠人工逐行读 trace 的调试循环。最后 35 分钟的现场问答覆盖 Ralph loop、agent teams、可追溯性和人工介入的取舍。 ## [00:00] 开场与讲者介绍 Ash Prabaker 开场自我介绍：他和 Andrew Wilson 都是 Anthropic Applied AI 团队的工程师，这场分享源自团队几周前发布的一篇博客，主题是让 Agent 持续工作很长时间。他指出，各家公司都爱秀"一把梭生成浏览器"式的演示，却很少公开 harness 里的细节，这个空白正是今天的议题。Andrew 负责讲历史和已发布的原语，Ash 之后回来讲实验性的那一半。 > *我们说的是 5、6 个小时以上的运行。* ## [01:21] 长时运行 Agent 概览 Andrew 是常驻伦敦的解决方案架构师。他用 Claude Code 创造者 Boris 在产品一周年时的一段话给这一年定调：一年前 Claude 连写 bash 命令、转义字符串都很吃力；如今 Claude Code 几乎全部由 Claude Code 自己编写，一次能跑上好几天。 > *它一次大概只能跑 20 分钟。* ## [02:29] 三大挑战：上下文、规划与判断力 长时运行难在三个方面。上下文：窗口有限，新会话像失忆一样从零开始，窗口越满连贯性越差，接近上限时模型还会出现"上下文焦虑"，慌慌张张赶工收尾。规划：模型想一口气做完所有事，常常做到一半就停，或者上下文耗尽留下半成品。判断力最反直觉：模型很不擅长评判自己的产出，会把半生不熟的功能宣布完工，或者做了个按钮但后端根本不存在。 > *模型非常不擅长评判自己的产出* ## [04:14] 两条路线：模型升级 vs. harness 演进 解法来自两个方向。其一是把能力炼进模型权重，METER 曲线（衡量 Agent 在极简脚手架上完成 50% 任务能跑多久）从 Opus 3.7 的约 1 小时涨到一年后 Opus 4.6 的 12 小时。其二是改 harness：Agent SDK 提供了全部核心原语，包括 agent 循环、MCP 工具、sub-agent 委派、claude.md、skills、斜杠命令和权限系统。Andrew 反复强调的观察是：每次发模型，都同时发了一大批 harness 改动。 > *我们每次发布模型时，总会同时发布大量与之配套的 harness 改动* ## [05:58] 史前时代：Sonnet 3.5、Computer Use 与 MCP 在 Claude Code 出现之前，Claude.ai 上有 artifacts，而 Sonnet 3.5 是第一个真正展现编码潜力的模型，它能看到自己写出的东西并在此基础上迭代。Computer use 让它学会点击、截图、自测代码，MCP 规范则给了它使用工具的能力。 > *那是 Claude Code 诞生前的一个顿悟时刻。* ## [06:34] Claude Code 的演进 2025 年 2 月，Sonnet 3.7 登顶 SWE-bench，Claude Code 以研究预览版发布，目的写得很明白：更好地理解开发者如何用 Claude 写代码，反哺未来的模型改进。由此形成一条反复出现的规律：模型变强后，harness 的某些部件会变得不再必要，或者随之演化。到 5 月，Opus 4 和 Sonnet 4 已能更好地管理自身上下文、不靠投机取巧也能完成任务，Claude Code 正式 GA 并发布了 SDK。 > *Claude Code 的目标是更好地理解开发者如何用 Claude 写代码，以反哺未来的模型改进* ## [07:55] Ralph loop 技术 插播 Ralph Wiggum 技术：Jeffrey Huntley 去年 7 月就发表了它，12 月前后才真正走红。简化版的说法是把一个 prompt 喂给 CLI 循环跑，直到所有任务完成；真实版本分好几个阶段，先做规划把 prompt 拆成若干 feature，每次挑一个任务、开一个全新会话、用干净的上下文窗口去做。它的魅力浓缩在 Huntley 那句"在不确定的世界里做到确定性地差"。Anthropic 自己的插件版本则在单个会话内运行，靠压缩机制续命，配上最大迭代数、安全词和 stop hook。 > *可预测地失败，好过不可预测地成功* ## [09:49] Sonnet 4.5、Agent SDK 与检查点 Sonnet 4.5 开始追踪自己消耗了多少 token，对上下文有了感知，能从容管理窗口的尾声而不是慌乱赶工。Claude Code 2.0 引入检查点，可以回退到会话中之前的状态。Claude Code SDK 改名为 Agent SDK，因为团队意识到这套 harness 的用途远不止写代码。此时运行时长达到约 30 小时。 > *我们意识到它的通用性远远超出了写代码这一件事* ## [10:49] Opus 4.5 与 sub-agent 的角色 Haiku 4.5 和 Opus 4.5 补齐了模型家族，经济账随之改变：同时跑很多 sub-agent 变得划算，而 Opus 4.5 擅长规划，于是形成 Opus 负责规划、Sonnet 负责执行的分工。Skills 随之发布，靠渐进式披露省上下文，默认只加载 skill 的开头元信息；programmatic tool calling 则让模型现场写代码串联一连串工具调用，只把最终结果带回上下文。 > *一下子，同时运行许多 sub-agent 变得真正划算了* ## [12:05] 首个长时运行 Agent 模式 11 月前后，团队发表了第一篇长时运行 Agent 的博客。人类只写一句模糊需求，比如"做一个 Slack 克隆"，initializer agent 把它拆成一组持久化产物：用 featurelist.json 存功能清单（模型更容易乱改 markdown，对 JSON 文件反而手下留情）、进度文件、git 仓库、初始化脚本。harness 循环随后在全新上下文窗口里运转：先认清环境，跑初始化脚本做冒烟测试，挑出恰好一个未完成的功能，实现它，用 Puppeteer 验证，提交 commit，再循环。 > *模型可能会改写 markdown 文件，但它们不太会去改写 JSON 文件* ## [14:20] Opus 4.6、Agent Teams 与服务端压缩 Sonnet 4.6 用 Sonnet 的价格给出接近 Opus 的智能，成为主力执行模型；Opus 4.6 则被称为"非常 agentic 的模型"，METER 指标在极简脚手架上从约 4 小时跳到 12 小时。Agent teams 发布：sub-agent 之间可以直接互相协调，只在必要时才向主 agent 汇报。服务端压缩让会话实际上可以无限跑下去，1M 上下文窗口正式 GA，设计的天平开始偏向少开新会话、在一个大窗口里做更多事。Andrew 收尾的观点：模型变强，harness 并不会消失，而是先填补模型的短板，模型再针对这些用法训练，然后某些部件被整体删掉，循环往复。 > *harness 并不会随着模型变强而直接消失* ## [17:28] 最前沿的 harness 模式 Ash 上台先做了个现场调查，此刻有 Agent 在后台干活的只有两三个人。随后他抛出核心模式，毫不避讳地说灵感来自 GAN：一个 generator 负责构建，一个独立的 evaluator 负责打分，两者在彻底分离的上下文窗口、系统提示词和职责之间形成对抗压力。evaluator 不是读 diff，而是用 Playwright 打开真实页面点来点去，再把批评意见交还给 generator。既然 evaluator 也是 LLM，为什么不会照样盖章放行？他们利用的正是这道缝隙：把一个独立的批评者调得苛刻很容易做到，把一个构建者调得有自我批判精神却办不到，就像人类评价一幅画、一道菜很容易，自己画出来、做出来难得多。 > *这里的 evaluator 不只是读 diff，它实际上在用 Playwright 打开线上页面，到处点击、试用功能* ## [21:30] 用评分准则评估主观产出 大多数人说品味没法打分，这个团队不同意：只要你对好坏有足够强的主见，把它写下来就行。他们的评分准则有四项，设计、原创性、工艺和功能性，权重偏向前两项，因为 Opus 4.6 的功能性已经够强，真正要对抗的是紫色渐变和 AI 味审美。再用参考网站做 few-shot 示例，把 evaluator 的品味校准到自己的标准上。这套机制解锁了一种独特行为：generator 在原创性上反复拿低分时，GAN 式 harness 会把整个方案推倒重来，而单一循环或 Ralph loop 只会在原地缝缝补补。 > *大多数人说品味没法打分，但我们认为可以，只要你对它有足够强的主见，并且把它写下来* ## [23:44] 引入 'Planner' 角色 要从漂亮页面走向能用的应用，他们只加了一个角色。Planner 把一行 prompt 变成一份刻意保持高层级的规格，划分成一系列 sprint，并且刻意不规划细粒度的技术细节，因为细节出错会层层级联到每个 sprint，在数小时的时间跨度上不断放大。眯起眼看，这就是一套 PM、IC、QA 的组织结构。 > *我们只是给每个角色配了它自己的上下文窗口。* ## [25:04] generator 与 evaluator 之间的契约 这套体系真正的粘合剂在于：generator 动笔写第一行代码之前，两个 agent 要先谈判"完成"到底意味着什么。generator 提议"我做 X 功能，你用 Y 测试来验证"，evaluator 反驳"范围太大、测试太弱、漏了某某边界情况"，双方通过磁盘上的 markdown 文件你来我往，直到达成一致。之后的评分对照的是这份双方议定的契约，而不是 planner 开头一把梭写下的规格。Ash 称这是 Ralph loop 始终缺失的关键创新：从来没有人站在循环的对面跟它争论。证据是同一个"做一个复古游戏制作器"的 prompt 跑出的两种结果。无 harness 的版本界面光鲜，但进入试玩模式后方向键和空格键毫无反应；harness 版本花了约 200 美元、6 个小时，自己给应用起名 Retro Forge，做出 54 色调色板的精灵编辑器，把规格里一句含糊的"AI 功能"变成完整的 AI 关卡助手，试玩模式里调试 HUD 实时跳动、物理循环真实运转、碰撞检测正常，差距完全来自脚手架。 > *我们让这两个 agent 实实在在地谈判"完成"到底意味着什么* ## [31:28] 契约的颗粒度与 trace 调试 evaluator 抓到的问题都不花哨：一个 FastAPI 路由顺序 bug，单元测试全过但上了生产就崩；删除键上的一个布尔逻辑 bug，只有真正使用这个应用才会发现。游戏制作器那次，两个 agent 议定了 27 条契约标准，这种颗粒度才能让发现可执行；标准含糊，批评就含糊，generator 耸耸肩就糊弄过去了。Ash 也坦白，Claude 出厂时是个很糟糕的 QA agent，LLM 当裁判时的那种谄媚和宽容在这里照样发作，早期的 evaluator 发现 bug 后会写一句"以后再修，大概要两周"就接着往下走。没有什么秘诀能绕过去：构建这套系统的核心功夫就是读 trace，找出模型判断和人类判断分歧的地方，再去调提示词；一个实用技巧是把 agent 的记录导出到文件，让另一个 agent 去 grep 和复盘，连改提示词这件事本身也形成闭环。 > *标准含糊，批评就含糊* ## [34:14] 随模型演进调整 harness harness 设计是不是已经过时？Ash 的回答是：摸清每个模型各自的尖刺行为，再用 harness 去填缝。从 Opus 4.5 换到 4.6，他们彻底放弃了会话间的上下文重置，因为 4.6 没有上下文焦虑，单个连续会话加压缩就够了；放弃了强制的 sprint 拆解，4.6 能连贯地撑起 2 小时的连续构建，不需要一次只喂一个功能；evaluator 的运行频率也从每个 sprint 一次改成每轮一次性生成结束后一次。教训不是 harness 设计错了，而是它适配的是 4.5，前沿移动了。今天的形态保留了 planner、generator、evaluator 这个核心，用文件系统共享状态，成本约为之前的一半。新演示是 harness 构建的一个 DAW 音乐应用，Ash 承认它做出来的音乐很烂，但应用本身相当完整，放在一代模型之前根本不可能跑通。 > *它适配的是 4.5，前沿移动了* ## [37:56] 如何构建你自己的 Agent harness 这一切并不需要 Anthropic 的内部 harness。auto mode 提供了比一路放行权限更安全的折中；custom sub-agent 已经是现成原语，给你的 evaluator 一个苛刻的系统提示词和一份详尽的评分准则；网页应用用 Playwright MCP 或 Claude for Chrome，原生应用用 computer use；skills 则是把评分准则打包进日常开发流程的顺手方式。 > *没有什么能阻止你直接动手，自己搭一套类似的东西* ## [39:01] 长时运行 Agent 的关键要点 值得拍照的那页总结：自我评估是个陷阱，用对抗式 evaluator；压缩不等于连贯，有损摘要会漂移，结构化交接和干净上下文才是好模式；别以为主观质量不可打分，对好坏有主见就逼自己写下来；和模型坐在一起读 trace，只有这样才知道前沿移动时该删掉脚手架的哪些部分。 > *自我评估，十足是个陷阱* ## [40:05] 现场问答 11 位现场观众轮流提问，持续了 35 分钟。要点：evaluator 的调优经验在瞄准模型共性弱点时可以跨项目复用，用"这就是 AI 味"的示例来校准；关于 Ralph loop 和模型的"聪明区间"，1M 上下文 GA 加上 4.6 的连贯性让团队转向单个连续会话加压缩，但还是要以你自己的评测为准；关于盯着 Agent 干活，Ash 认为想盯着看本质上是信任差距，如今模型自己就能读控制台报错、发现文字重叠；4.6 这一代模型在评分爬不上去时出奇地愿意把十轮成果整个扔掉重来，有一次 evaluator 干脆发火让 generator 全部删掉重写；planner 被刻意挡在内循环之外，靠定期把规格重新注入会话来保持方向；对于要活过这次运行的产品，harness 会留下面包屑，一份"试了什么、发现什么 bug、修复是否生效"的 learnings JSON 加一份高层文档，足够人类带着 Claude Code 接力；把 generator 的上下文喂给批评者这条路试过又放弃了，只评产出比搅浑两条思路流更有效；可追溯性至今主要靠人工逐行读 trace，Claude 扫一遍 trace 只能当第一道筛子；至于人工介入的 sprint 评审，hooks 可以注入一个，但团队的优化方向是完全自治：跑十代，读完七个失败案例，调 harness 提示词，再来。 > *你得把整个东西读完* ## 实体 - **Ash Prabaker**（人物）：Anthropic Applied AI 团队工程师，主讲最前沿 harness 模式与问答环节。 - **Andrew Wilson**（人物）：Anthropic Applied AI 团队解决方案架构师，常驻伦敦，主讲模型与 harness 演进史。 - **Anthropic**（组织）：两位讲者所在的公司，出品 Claude 系列模型、Claude Code 和 Agent SDK。 - **Claude Code**（软件）：Anthropic 的编码 Agent CLI，其一年演进史是本场分享的主线。 - **Agent SDK**（软件）：由 Claude Code SDK 更名而来，提供 harness 构建所依赖的 agent 循环原语。 - **Generator-evaluator 模式**（概念）：受 GAN 启发，把构建者与对抗式批评者拆分到独立上下文中，是这套 harness 的核心。 - **Ralph loop**（概念）：Jeffrey Huntley 提出的循环执行 prompt 直到完成的技术，缺少对面争论方的前身方案。 - **Playwright MCP**（软件）：evaluator 用来实测线上应用的浏览器自动化工具。