agent 界面的演化——Gagan Bhat 与 Isabella Kai He(Anthropic)

▲ 图注：开场标题页：Anthropic Applied AI 团队的 Gagan Bhat 与 Isabella He，主题「Agentic 界面的演化」。

• 双讲者：Gagan Bhat 和 Isabella Kai He，都是 Anthropic 的技术团队成员，隶属 Applied AI（应用 AI）团队。他们自我介绍这个团队「处在产品、研究和 go-to-market（市场落地）三者的交叉点上」，日常大量时间花在三件事：造 agent、评测 Claude、想办法让它在各种具体场景下表现更好。→ 详细
• 全场路线图：agentic surfaces（构建 agent 的那层界面/接口）的演化史 → 托管 agent 的工程原则与底层实现 → 现场 demo → 带到客户现场学到的四条教训 → 前沿功能与收尾论断。→ 详细

• AI 进展在加速：从 transformer 架构被定义，到创始人们发现的 scaling laws（规模定律：投入的模型规模、数据、算力越大，能力越强的经验规律），到今天的模型——「每一次模型发布，都会带来上一代模型不具备的能力。」→ 详细
• 这直接体现在我们交给模型的任务上，三级跳很清楚：最开始只是简单一问一答 → 后来把任务委派出去 → 现在让 agent 去承担一整个结果（own entire outcomes）。任务复杂度和模型能力一起上升，所以那层界面也必须跟着演化。→ 详细

• 任务变长以后，模型需要自己取信息、自己管上下文，于是 agentic loop（agent 循环） 被发明出来——但它「是每一个客户都得从零手工搭起来的东西」：调用 Claude、执行工具、管理上下文，「过程非常折磨人」。产品在它之上，AI 功能去调这个 loop 干活。→ 详细
• 而要上生产还有一大堆基础设施要处理：会话管理、可观测性、凭据、托管、沙箱隔离。这些活「既琐碎又烦人，而且让团队没法把精力放在最要紧的地方——他们自己的产品」。→ 详细
• Gagan 把这些挑战列成六个思考题，值得当清单用：① 托管与扩缩容——agent 跑在哪儿、进程活多久？→ 详细 ② 会话管理——历史和进度存哪儿、怎么让多 agent 并发上规模？③ 文件系统——Claude 靠什么创建/编辑文件？→ 详细 ④ 执行隔离——它写的代码在哪儿跑、怎么保证安全？⑤ 凭据——怎么让它伸手进敏感系统却碰不到安全令牌？→ 详细 ⑥ 可观测性——编排这么复杂，怎么知道底下在发生什么？→ 详细

• 第二次演化是 Claude Agent SDK：本质上是把「我们熟悉也喜爱的那个 harness」——也就是 Claude Code——打包发布，自带 agentic loop、文件系统访问、工具和一套沙箱机制。→ 详细
• 但它只解决了一半：会话管理、可观测性有了些现成原语，凭据和托管基础设施仍然要你自己手搓——「你得想清楚怎么把这套东西装进一个盒子里，还要为客户做到可扩展」。→ 详细

▲ 图注：三代界面对比：Messages API → Claude Agent SDK → Claude Managed Agents，红色为 Anthropic 接管的层——托管 agent 把生产基础设施和 harness 全部收走，你只留产品层。

• 想法一句话说完：产品是你的、任务是你的、上下文是你的；你调用托管 agent，拿到生产级基础设施。→ 详细
• 你拿到的是一个「大脑」（agentic loop + Claude 本身 + 内部所有定制过的 harness 及其演进成果）和一双「手」（一个按需即时拉起的沙箱，用来读写文件、执行代码）。凭据、会话管理、可观测性、托管——全部由 Anthropic 跑。留给你建和运营的，是你的任务、你的上下文、你的领域知识。→ 详细
• 三代对照：Messages API 给的是 token 进 token 出；Agent SDK 给的是内置的、面向任务的 harness；托管 agent 覆盖的是从你的产品往下这一整个技术栈。→ 详细

▲ 图注：Sonnet 4.5 的「context anxiety」：一感知到上下文快到上限就抢跑收尾（跳步骤、提前 wrap up），即便实际余量还很足——当时不得不在 harness 里做补偿。

• Isabella 接手后先给出催生托管 agent 的那条核心原则，原话是：「harness 里编码（encode）的，是一系列关于『Claude 自己做不到什么』的假设。」 这些假设长什么样？就是那些看着理所当然的原语——重置上下文（context reset）、管理压缩（compaction，把长会话折叠成更短的摘要），等等。→ 详细
• 而这些假设的要命之处在于：「必须被频繁地质疑，因为随着模型变强，它们会过期。」→ 详细
• 具体案例（这场演讲最值钱的一段）：Sonnet 4.5 刚出来时表现出一种叫 context anxiety（上下文焦虑） 的行为——「这个 agent 在快撞上自己上下文窗口上限的时候，真的会焦虑起来」：它开始提前收尾任务、中止工作，哪怕上下文窗口其实还有余量。团队的应对是往 harness 本身打补丁，加进上下文重置，好让 Sonnet 4.5 能重置上下文、接着往下干。→ 详细
• 然后 Opus 4.5 出来了，这个行为完全消失。 于是那个补丁「变成了纯粹的累赘。事实上它成了纯开销：增加了延迟，还时不时导致缓存被错误地丢弃」。结论句：「我们发现这些 harness 补丁不但不再需要，反而在 Opus 4.5 上拖了模型表现的后腿。」→ 详细
• 注意这一段的隐含前提，比案例本身更重要：补丁的成本不是零。 一层为旧模型缺陷而加的脚手架，即使「留着不碍事」，也在持续收取延迟税和缓存税——它不是中性的。

▲ 图注：全场论点金句：「模型往前走了、harness 没跟着走，agent 就会变差。」

▲ 图注：同一段 harness 补丁的两种命运：在 Sonnet 4.5 上是必要品（保持 agent 连贯），在 Opus 4.5 上变成纯开销（行为已消失，补丁只剩丢缓存、加延迟）。

• 这句是原话，值得记住：「模型往前走了、harness 没跟上，结果就是 agent 变差。」→ 详细
• 他们在企业客户身上看到的分布很直白：「有些客户的 harness 比较敏捷，另一些则比较僵化——因为它们是围着更老的 Claude 模型建起来的。」 而「你最不想要的，就是一个陈旧的 harness，迁到新模型要花上几周甚至几个月」——尤其在模型发布周期越来越短的今天。→ 详细
• 于是「高效 harness」被重新定义成两条：① 为明天的模型能力做设计——预判未来模型能做到什么，照着那个能力去建；② 必须敏捷——新能力一就绪就能立刻吃进来。托管 agent 因此被设计成围绕一小组彼此解耦的原语，「让你可以很容易地把某个组件换掉、把它当成单独一块去迭代，同时整体架构保持稳定」。→ 详细

• Isabella 说她在 Claude Code、Claude Tag（Anthropic 那个进 Slack 的 Claude）以及外部企业团队身上看到同一个模式：「这些 agent 正变得越来越异步，处理的任务也越来越复杂。」→ 详细
• 承接这种量级的 harness 需要四样：擅长上下文工程（长周期作业里上下文会不断累积）、给 agent 一个安全沙箱（让它真能动手）、足够可靠（能连跑几小时甚至几天）、能做并行化工作流（同时啃一个复杂问题的多个部分）。→ 详细

▲ 图注：解耦前后对比：大脑（agent loop）与手（sandbox 里的工具执行）拆进不同进程——手死了大脑还在，容器启动不再阻塞推理。

• 最初的做法是耦合的：agent 循环和工具执行放在同一个盒子、同一个容器里。好处很直观——调工具、读结果都在本地。→ 详细
• 然后撞上两个限制：① 容器成了阻塞项——agent 必须等容器完全搭好才能开始推理；② 可靠性差——只要这个组合里有一个部件挂了，整个 agent 的盒子就一起挂。→ 详细
• 解法是分离：「大脑」= agent 循环，「手」= 工具执行环境。直接收益：可靠性提升，并且大脑可以只在真正需要的时候才按需拉起会话。→ 详细
• 容错怎么走：沙箱（手）死了 → 大脑直接拉起一个新沙箱、重试、从断点继续；大脑死了 → 因为 agent 做的每件事都写进了持久化的 session log（会话日志），大脑可以从日志里读回来、恢复上下文、精确接着干。→ 详细

• agent：定义「这个 agent 是干什么的」——模型、prompt、工具、skills（技能），所有让它适配你场景的东西。→ 详细
• environment：agent 实际运行的容器。多个会话可以跑在同一份环境定义上，甚至同时挂在同一个环境上，但每个会话有自己隔离的容器实例。→ 详细
• session：agent + environment 组合出来的东西，是一份持久化在云上的资源，记录你和这个 agent 的每一次交互——可观测性、长时运行实例、可靠性都由它解锁。→ 详细
• 四种会话状态：idle（等用户输入）、running（执行中）、rescheduling（遇错准备重试）、terminated（不可恢复）。她特别点出原型和生产的差距：「做一个跑在你自己笔记本上、只服务你一个用户的 agent，和真的把它部署到生产、给成千上万甚至上百万用户跑，完全是两回事。」→ 详细

• 上下文工程是「把高效的 agent 和陷进 context rot（上下文腐烂：上下文塞得太多太杂，模型反而变糊涂）的 agent 区分开来的关键之一」，Anthropic 在这上面做了大量研究。→ 详细
• 传统 harness 的结构缺陷：上下文窗口和会话是同一个东西——「如果 Claude 想丢掉当前这轮会话里的一部分上下文，一旦丢了，它就没有机制能把那部分内容再捞回窗口里。」 丢弃是不可逆的，所以模型不敢丢，也丢不起。→ 详细
• 托管 agent 的解法：因为一切都记进了持久化会话日志，harness 可以直接从日志里把某几片上下文重新读回当前窗口。丢弃变成可逆操作——「它可以直接从会话日志里重新读一遍就恢复了」。这是「会话日志」这个看似朴素的设计带来的最深一层收益。→ 详细

• 平台负责的：agent 循环、记忆（memory）、可观测性——「用 Claude 托管 agent 构建时这些都是附送的」。→ 详细
• 留给开发者定制的只有两块：上下文管理 + 领域专长。 原话：「这正是一个写代码的 agent 和一个法务 agent、或者一个 go-to-market agent 之间的差别所在。」 例子很具体：Claude Code 用 Bash、grep，就像开发者打开终端那样；但法务 agent 或市场 agent 需要的工具组合完全不同。→ 详细
• 落点：把 harness 那半交给 Anthropic，开发者就能把时间集中在设计正确的系统提示词、正确的 skills、正确的工具上。→ 详细

• Gagan 接回话筒，主题只有一句：「真正用它来构建是什么感觉？从零做出一个属于你自己的、生产级的 agent，体验到底是怎样的？」→ 详细
• 场景：你负责一个叫 Atlas 的指标仪表盘，某天 P99 延迟（最慢的那 1% 请求的耗时）飙到基线的 10 倍，你手上有个线上事故；日志一大堆文本。设想：有没有一个 SRE（站点可靠性工程）agent，能在你打开 dashboard 之前就把根因（root cause）查出来送到你面前？→ 详细
• 第一步 agent 定义：命名 SRE Investigator；模型给的是 Claude Opus 4.8（⚠️ ASR 存疑，见文末）；一段系统提示词定义行为；工具分两组——标准 agent 工具集（Bash、grep、glob）+ 一个连到 dashboard 的 MCP 工具集（拉发布记录和指标）。→ 详细
• 第二步 environment：建一个 SRE Sandbox，跑在 Anthropic 云上，网络受限，允许访问的主机只有那台 MCP 服务器——「这个环境实际上就是在阻止 Claude 去做你并不打算让它做的事」。→ 详细
• 第三步 session：上传文件和 skills（这里是应用日志），把日志文件指定为一个资源，组合成一个新会话并启动。「你在这里定义出来的东西，现在就活在 Anthropic 的云上了」，并且在你的应用里可以按需动态生成。→ 详细
• 跑起来的样子：大脑在云端拉起 → 用「手」grep 应用日志找线索 → 用 MCP 工具查指标、找到最近的发布记录、圈定事故起点 → 深挖找到那次代码 diff → 综合推断出根因。他强调这只是一个会话，而这一切都是生产基础设施，可以想象所有用户同时开出无数会话。控制台上的可观测性面板能看到确切的事件轨迹（event trace）、会话日志、用了哪些工具、返回了什么结果、以及所有 agent 消息。→ 详细

• 客户最常问的问题：「我怎么才能确保我的 agent 读不到那个装着我所有安全令牌的环境变量文件？」→ 详细
• 一半保障来自架构（大脑和手已经分开，跑循环的地方 ≠ 执行工具的地方）；另一半是引入 vault（保险库）：凭据安全存放，只在工具执行运行时真正需要的那一刻才解密，「模型永远看不到你的安全令牌」。（⚠️ 转写为 "walls"，按上下文取 vault，见文末。）→ 详细

• 耦合设计下，模型在容器完全搭好之前根本没法开始推理、也吐不出第一个 token，直接拖长 time to first token（首 token 时间，即你按下回车到看见第一个字之间的等待）。→ 详细
• 解耦之后：推理立刻开始，容器搭建并行去跑；等大脑需要「手」的时候手已经在了；如果这个任务压根不需要容器，可以完全跳过容器搭建。实测结果：首 token 时间在 P50（中位数）场景下快 60%，在 P95（最慢的 5%）场景下延迟改善超过 90%。→ 详细

▲ 图注：同一份会话日志喂两件事：左边是可观测性（逐步回放），右边是记忆与自我改进（沉淀 user_preferences、驱动 dreaming）。

• 客户问的是两个问题：「我怎么搞清楚我的 agent 底下到底在干什么？」 和 「我怎么让我的 agent 随时间越变越好？」——答案是同一个东西：session log（会话日志），或者叫 traces（轨迹）。→ 详细
• 会话日志记录一次执行里的所有事件：用户消息、模型回复、工具执行、执行结果——一五一十全写下来。→ 详细
• 三种用途叠在同一份数据上：把它呈现在用户能看到的界面上 = 可观测性；它提供了过去执行的历史 = 记忆的原料；再叠上 dreaming = 自我改进——「记忆就能随时间被更新和改进，这样你的 agent 下一次跑的时候就更强了」。→ 详细

• 安全意识强的企业团队要求工具执行完全在自己的 virtual private cloud（VPC，虚拟私有云）里。因为「大脑和手解耦」这个决定，「手」可以跑在任何地方，包括跑在你自己的 VPC 里——于是有了 self-hosted sandboxes（自托管沙箱）：客户自己控制沙箱的控制平面，工具完全按自己的策略运行。→ 详细
• 另一个客户驱动的功能是 MCP tunnels（MCP 隧道）：想把 MCP 服务器给 agent 用、但不愿意让它跑在公网上的团队，可以让服务器只跑在私有网络里，只对云上的 agent 循环发起出站调用。→ 详细

• 四条教训过完后，Isabella 把它们收成一句：托管 agent 是在帮你「为『能力持续迭代』这个现实去构建，帮你跟上模型的演进」；而今天讲的「只触到了冰山一角」。→ 详细
• 在试验中的功能清单：定时部署（scheduled deployments）、自托管沙箱、多 agent 编排、dreaming、outcomes、memory 等等；时间只够讲两个最喜欢的。→ 详细
• dreaming 的机制：拿 agent 每天那些会话的转写记录（会话日志）+ agent 当前的记忆状态，喂进一个周期性的批处理过程，它「能提炼出新的洞察、新的组织结构，反过来按需修改记忆，从而让第二天的 agent 会话自动变得聪明得多」。这就是他们看到的「agent 在不断执行中自我改进」。→ 详细
• 再往上一层：dreaming 和 memory 只是「一套全新的统一记忆系统的两块基石」——他们看到一种组织级别的记忆正在浮现，把团队的 runbook（应急操作手册）和各种细节沉淀下来。→ 详细

▲ 图注：outcomes 闭环：agent 干活 → 产出交给独立 grader 按你写的 rubric 打分 → 不及格就带着「差在哪」的定位回炉重试，直到过线。

• 机制：用户为自己的 agent 定义成功标准——写一份 rubric（评分标准）说清楚什么才算真正完成任务，同时也定义失败情形。然后 outcomes 启动一个独立的 grader agent（打分 agent），跟你的 agent 循环并行跑，去判断任务是否达标。→ 详细
• 闭环在这里：agent 执行任务 → 打分器对着 rubric 逐条检查 → 如果判定没完成，就一直重试，直到达到你定义的成功标准为止。→ 详细
• 为什么这件事重要：「我们正在走向这样一个世界——agent 能理解一个任务的『成功』到底意味着什么，并且有一套机制持续迭代。」 由此可以解锁一批几个月前还做不到的任务。→ 详细

▲ 图注：收尾图：「模型能做到的」和「你产品让用户拿到的」之间的缺口在拉大——托管 agent 的定位就是把这道缺口关上。

• 全场落点：托管 agent 要做的是「弥合『产品今天在各种界面上、靠静态 harness 能提供的能力』和『模型实际上做得到的能力』之间的那道差距」。→ 详细
• 最后一句最狠：「当 Claude 模型和其他模型沿着这条指数曲线不断演进，harness 已经变成了限制模型能力发挥的那个瓶颈。」→ 详细

• 闪电问答：（本期无）——31 分钟的双人大会演讲，没有问答环节。
• 收尾：希望听众带走两件事——Anthropic 团队是怎么造出托管 agent 的，以及它是怎么被设计成「能承接前沿智能、能跟上模型演进、能撑住真实生产负载」的 harness。→ 详细

广告口播段：（本期无）——大会演讲，全程无赞助口播。