Evolution of agentic surfaces — Gagan Bhat & Isabella Kai He, Anthropic

频道: AI Engineer
视频: https://www.youtube.com/watch?v=K0X9QDRkIdg
原文语言: en
统计: 共 32 轮 · Gagan Bhat 12 · Isabella Kai He 13

[0:00]

Gagan ReviewerAll right.Hi, everyone.Thank you for joining us today.I'm Gagan.And I'm Isabella.We're both members of technical staff here at Anthropicat the Applied AI team.Our team sits at the intersection of product, research,and go-to-market,and we spend a lot of our day time building agents,evaluating Claude,and finding ways to make it better in different use cases.We're here today to talk about how the surfaces for building agentshas evolved in the last three years,and what our teams have learned building agentsboth internally at Anthropicand externally with our enterprise customers along the way.I'll hand it off to Gagan to kick us off.So, here's the plan.We'll first start off by talking about how we've seen agentic surfacesevolve all the way from the Messages APIto Claude-managed agents.Isabella will then cover the engineering principlesbehind Claude-managed agentsand how it works under the hood.We'll share a demo that kind of showswhat it feels like to build with this latest surface,and then we'll talk about lessons that we've learnedfrom the field by taking this to customers,and finally we'll close with what it feels like to buildat the frontier as model capabilities evolve dramatically.

好，大家好，感谢各位今天来听我们分享。我是 Gagan。我是 Isabella。我们两个都是 Anthropic 的技术团队成员，在 Applied AI（应用 AI）团队。我们这个团队处在产品、研究和 go-to-market（市场落地）三者的交叉点上，日常大量时间都花在造 agent、评测 Claude，以及想办法让它在各种不同场景下表现得更好。今天我们要讲的是：过去三年里，构建 agent 的那层「界面」（agentic surfaces）是怎么一步步演化的，以及我们团队一路上学到了什么——既包括在 Anthropic 内部造 agent 的经验，也包括和企业客户一起在外部落地的经验。下面交给 Gagan 开场。好，这是今天的安排。我们先讲 agentic surfaces 是怎么从 Messages API 一路演化到 Claude 托管 agent（Claude-managed agents）的。然后 Isabella 会讲 Claude 托管 agent 背后的工程原则，以及它在底层是怎么跑起来的。接着我们会放一个 demo，让大家感受一下用这套最新的界面来构建是什么体验。之后我们讲把它带到客户现场之后学到的东西。最后我们聊聊：当模型能力在剧烈演进的时候，在前沿构建是一种什么感觉。

[1:22] Gagan Bhat

Okay, with that, let's talk about how agentic surfaces have evolved.To set the stage, it's important to realize that AI progress is accelerating.From back in the days when the transformer architecture was first definedto the scaling laws discovered by our foundersto the models that have been released today,every model release, and we all feel it,every model release improves capabilities that the previous model did not have.And we see this translate over to the tasks that we give models as well.The complexity of these have grown dramatically.Initially, we used to only give them questions, simple Q&A.We then started delegating tasks to them,and now we let agents own entire outcomes.What this means is that as task complexity and model capability has improved,the agentic surfaces has to evolve with them,and we're going to talk about that in this section.So go back in time to when we first launched Cloud3.We launched it alongside the first agentic surface called the Messages API.This Messages API was simply tokens in and tokens out.You gave information in, and you got information in,and text completions out.As I mentioned earlier, task complexity grew over time,and there was a need for the model to fetch information and manage its context

好，那我们就来说说 agentic surfaces 是怎么演化的。先把背景铺一下：很重要的一点是要意识到，AI 的进展正在加速。从当年 transformer 架构第一次被定义，到我们几位创始人发现的 scaling laws（规模定律：投入的模型规模、数据和算力越大，能力越强的经验规律），再到今天已经发布的这些模型——每一次模型发布，我们都能亲身感受到，每一次发布都会带来上一代模型不具备的能力。而这一点也直接体现在我们交给模型的任务上：任务的复杂度增长得非常快。最开始我们只给它们提问题，简单的一问一答；后来我们开始把任务委派给它们；而现在，我们让 agent 去承担一整个结果（own entire outcomes）。这意味着：随着任务复杂度和模型能力一起上升，agentic surfaces 也必须跟着演化——这就是这一节要讲的。那我们把时间拨回到 Claude 3 刚发布的时候。当时我们同时推出了第一个 agentic surface，叫 Messages API。这个 Messages API 很简单，就是 token 进、token 出：你把信息给进去，拿到文本补全的结果出来。前面提到，任务复杂度随时间上升，于是模型就需要能自己去取信息，并且在越跑越长的过程中管理自己的 context（上下文）……

[2:46] Gagan Bhat

as it runs for longer and longer.And so we saw the invention of the agentic loop.This loop is something that every customer started building manually from scratchthat calls Cloud, you know, runs the tools, and manages its context.And it was painstaking.And on top of that lived their product, where it had the AI feature,and it would call the agentic loop to accomplish some sort of task.But this was not all.In order to take this to production,there was a whole slew of production infrastructure challengeslike session management, observability, credentials,hosting infrastructure, sandboxing, and more.These challenges were tedious to deal with,and it didn't allow teams to focus on building what mattered most, their product.One of the core challenges here was the agentic loop.It was surprisingly complex to maintain.Which brings me to the second part.The second evolution of the agentic surface was the Cloud Agent SDK.This Agent SDK essentially packaged the harness that we know and love,which is Cloud Code, and it shipped with a built-in agentic loop,along with file system access, tools, and a system for doing sandboxing.Your product would then embed the SDK,and there are some primitives already provided for session management,

……因为它一次要跑的时间越来越长。于是就有了 agentic loop（agent 循环）的发明。这个循环是每一个客户都得从零手工搭起来的东西——它负责调用 Claude、执行工具、管理上下文，过程非常折磨人。而在这之上才是他们真正的产品：产品里有个 AI 功能，这个功能会去调用那个 agentic loop 来完成某类任务。但这还不是全部。要把这套东西推上生产环境，还有一大堆生产基础设施上的挑战：会话管理、可观测性（observability）、凭据（credentials）、托管基础设施、沙箱隔离（sandboxing），等等。这些事情既琐碎又烦人，而且让团队没法把精力放在最要紧的地方——他们自己的产品。这里面一个核心难点就是 agentic loop，它维护起来的复杂程度超出想象。这就带到第二部分了。agentic surface 的第二次演化是 Claude Agent SDK。这个 Agent SDK 本质上是把我们熟悉也喜爱的那个 harness（外壳/脚手架，即包住模型、替它跑循环和工具的那层程序）打包了出来——也就是 Claude Code——并且自带一个内置的 agentic loop，还配上了文件系统访问、工具，以及一套做沙箱隔离的机制。你的产品把这个 SDK 嵌进去，会话管理、可观测性方面也已经有一些现成的原语（primitives）……

[4:09] Gagan Bhat

observability, but you still had to hand roll things like credentials,and hosting infrastructure, and much more.You had to figure out how to put this in a box and scale it for your customers.And I want to double tap on these production infrastructure challenges.And I'm going to enumerate some of these as questions to thought provoke.First, hosting and scaling.Where does the agent run, and how long does the process live for?

……但凭据、托管基础设施这些东西你还是得自己手搓，还有更多。你得想清楚怎么把这套东西装进一个盒子里，还要为你的客户做到可扩展。我想再多花点时间讲讲这些生产基础设施上的挑战。我把它们列成一系列问题，供大家思考。第一，托管与扩缩容。agent 到底跑在哪儿？这个进程要活多久？

[4:37] Gagan Bhat

What scales under load and what doesn't?Session management.Where does the history and progress of sessions live?How can you have multiple concurrent agents running at scale?File system.How does Cloud actually have access to create files and edit files?

负载上来的时候，哪些东西能扛住、哪些扛不住？第二，会话管理。会话的历史记录和进度存在哪里？你怎么做到多个 agent 并发、而且能上规模地跑？第三，文件系统。Claude 到底靠什么去创建文件、编辑文件？

[4:54] Gagan Bhat

Fourth, execution isolation.Where does Cloud actually run the code that it writes,and how do you keep it secure?Fifth, credentials.How does Cloud reach into your sensitive systemswithout actually getting exposed to the security tokens that you want to protect?

第四，执行隔离。Claude 写出来的代码到底在哪儿运行？你怎么保证它是安全的？第五，凭据。Claude 怎么才能伸手进你那些敏感系统，同时又不会真的接触到你想保护的那些安全令牌（token）？

[5:11] Gagan Bhat

And finally, observability.With all the complex agent orchestration going on,how do you figure out what's actually happening under the hood?These are production infrastructure challenges that most teamsspend significant portions of their time doing,instead of being able to focus on just their product, their task, and their context.Which is why we built Cloud managed agents.The idea of Cloud managed agents is simple.You own the product.You own the task.You own your context.And you call Cloud managed agents to get production-grade infrastructure for your agents.So your product would call Cloud managed agents and get a brain,which is the agentic loop and Cloud itself,and all the custom harnesses and evolutions built inside of it,along with the hands, which is a sandbox that spins up just in timefor things like file system access and code execution.And of course, all the bells and whistles that were difficult to maintain beforewith production infrastructure, like credentials, session management, observability,hosting infrastructure, all of this is run by Anthropic.And what's yours to build and run is your task, your context, and your domain knowledge.So if you step back and look at how this has evolved, we can kind of see the evolution over time.

最后，可观测性。agent 的编排这么复杂，你怎么搞清楚底下到底在发生什么？这些生产基础设施上的挑战，占掉了大多数团队相当大一部分时间——而这些时间本该花在他们自己的产品、任务和上下文上。这正是我们做 Claude 托管 agent（Claude managed agents）的原因。托管 agent 的想法很简单：产品是你的，任务是你的，上下文是你的；你去调用 Claude 托管 agent，就能拿到生产级的 agent 基础设施。所以你的产品调用 Claude 托管 agent，拿到一个「大脑」——也就是 agentic loop 和 Claude 本身，以及内部所有定制过的 harness 和它们的演进成果；同时拿到一双「手」——一个按需即时（just in time）拉起来的沙箱，用来做文件系统访问、代码执行这类事情。当然还有此前很难维护的那些配套：凭据、会话管理、可观测性、托管基础设施——全部由 Anthropic 来跑。而留给你去建、去运营的，是你的任务、你的上下文、你的领域知识。所以退一步看，就能看清这条演化路径是怎么走过来的。

[6:30]

The messages API introduced the ability for the model,for you to interact with the model with tokens in and tokens out.The Cloud agent SDK brought in a built-in agent harness for tasks.And Cloud managed agents covers everything that you need from your product and everything under that stack.So now I will hand it over to Isabella to talk a bit more about the engineering principlesthat drove how we built Cloud managed agents.Over to you.Perfect. Thank you.And as Goggin walked through, a takeaway from that entire last section is that models evolve quickly.And so when our team set out to build managed agents, we drew inspiration from the lessons that our teams learnedbuilding effective agents and harnesses for these models to capture that evolution as it rapidly advances alongside us.So for the next few minutes here, I want to talk you through some of the fundamentals that underpin the design of Cloud managed agentsand the lessons that our team learned along the way as we went about engineering this harness built for model evolution.Let's start with one of the very core principles that inspired our team to build managed agents.And that is that harnesses and code assumptions about what Cloud cannot do on its own.

Messages API 带来的是：你可以用 token 进、token 出的方式和模型交互。Claude Agent SDK 带来的是：一个内置的、面向任务的 agent harness。而 Claude 托管 agent 覆盖的是：从你的产品往下，这一整个技术栈里你需要的所有东西。那接下来我把话筒交给 Isabella，请她多讲讲我们构建 Claude 托管 agent 背后的工程原则。交给你。好的，谢谢。正如 Gagan 刚才讲的，上一节最重要的一个结论是：模型演进得非常快。所以当我们团队着手做托管 agent 时，我们从内部团队「怎么为这些模型构建高效 agent 和 harness」的经验里汲取了很多，目标是让这套东西能一边跟着模型飞速演进、一边把这种演进吃进来。接下来几分钟，我想带大家过一遍支撑 Claude 托管 agent 设计的一些基本原则，以及我们把这个「为模型演进而生的 harness」工程化的过程中学到的教训。先从最核心的一条原则说起，正是它催生了我们做托管 agent 的念头：harness 里编码（encode）的，是一系列关于「Claude 自己做不到什么」的假设。

[7:41] Isabella Kai He

This is things like resetting context and managing compaction and some of the other core primitives that you see here on the screen.The thing about these assumptions is that they have to be questioned frequently because they go stale as models improve.Let's dive into one concrete example.Back when Sonnet 4.5 came out, it exhibited an interesting behavior that came to be known as context anxiety.What this is is that the agent literally got anxious at his approach to its context window limit.It started to wrap up tasks early, it started to terminate work, even when it actually had room left to spare in its context window.In order to accommodate for this behavior, what our team did is built in fixes into the harness itself,adding in context resets so that Sonnet 4.5 would be able to reset its context and continue working.But when Opus 4.5 came out, the interesting thing here was that this behavior went away entirely.Opus 4.5 no longer exhibited context anxiety, which means that the fixes that we had added into the harness itself became dead weight.In fact, it became pure overhead, adding things like latency and causing issues with the cache being discarded incorrectly at times.The takeaway here is that we saw that the harness fixes were no longer needed and were actually detracting from model performance with Opus 4.5.

这些假设包括：重置上下文（resetting context）、管理压缩（compaction，把长会话折叠成更短的摘要），以及大家在屏幕上看到的其他几个核心原语。这些假设有个特点：必须被频繁地质疑，因为随着模型变强，它们会过期。我们看一个具体例子。Sonnet 4.5 刚出来的时候，它表现出一种很有意思的行为，后来被叫作 context anxiety（上下文焦虑）。意思是：这个 agent 在快撞上自己上下文窗口上限的时候，真的会焦虑起来。它会开始提前收尾任务、开始中止工作，哪怕它的上下文窗口其实还有余量。为了兼容这个行为，我们团队的做法是在 harness 本身里打补丁，加入了上下文重置（context reset），好让 Sonnet 4.5 能重置上下文、接着往下干。但 Opus 4.5 出来之后，有意思的事情发生了：这个行为完全消失了。Opus 4.5 不再有上下文焦虑——这意味着我们当初加进 harness 里的那些修补，变成了纯粹的累赘。事实上它成了纯开销：增加了延迟，还时不时导致缓存被错误地丢弃。这里的结论是：我们发现这些 harness 补丁不但不再需要，反而在 Opus 4.5 上拖了模型表现的后腿。

[8:57] Isabella Kai He

So when the model moves and the harness doesn't, it degrades the agent.What we've seen across these last couple of examples is that there's significant maintenance burden that comes with maintaining a harness that can keep up with Claude's rapid evolution.As we work with a range of enterprise teams that are building on top of Claude, we also see a range in the harnesses that are ready for this level of adaptation.Some of the harnesses that we see from customers are more agile and others are more rigid because they were built around older Claude models.What you don't want to do is have a stale harness that takes weeks or even months to migrate to a new model, especially with how model release cycles have been coming out shorter and shorter.Now, to build an effective harness, what this means is that you have to be designing for the model capabilities of tomorrow, anticipating what the future Claude models will be able to accomplish and building your harnesses for that capability.It also means that your harnesses have to be agile, making it easy to iterate for the model capabilities to capture them quickly as soon as they're ready.That brings me to Claude Manage Agents, which is a harness designed around a small set of primitives with individual components that you see here on the screen that are independent.

所以说，模型往前走了、harness 没跟上，结果就是 agent 变差。从刚才这几个例子里我们看到的是：要维护一个能跟上 Claude 快速演进的 harness，维护负担相当可观。在我们和一批批基于 Claude 构建的企业团队合作的过程中，也看到各家 harness 对这种适应能力的准备程度差别很大。有些客户的 harness 比较敏捷，另一些则比较僵化——因为它们是围着更老的 Claude 模型建起来的。你最不想要的，就是一个陈旧的 harness，迁到新模型要花上几周甚至几个月，尤其是在模型发布周期越来越短的今天。那么，要造一个高效的 harness，这意味着：你得为明天的模型能力做设计，去预判未来的 Claude 模型将能做到什么，然后照着那个能力去建你的 harness。同时也意味着，你的 harness 必须敏捷，让你能快速迭代，新能力一就绪就能立刻把它吃进来。这就带到了 Claude 托管 agent：它是一个围绕一小组原语设计的 harness，屏幕上这些独立的组件彼此解耦……

[10:06] Isabella Kai He

Making it easy to swap them out and iterate upon them as individual pieces while keeping the overall architecture stable.Another key thing that Claude Manage Agents is designed around is long running agents.Now, when I look to internal products that are exciting and anthropic like Claude Code and Claude Tag, which our team is really excited about, and as I work with other enterprise teams who are also building exciting, truly agentic products,and the products that are building blocks.A common pattern that I see is that these agents are becoming increasingly asynchronous and are tackling tasks that are increasingly complex and challenging.In order to design a harness that's actually able to capture those levels of work, it needs to have a couple of things.It needs to be good at context engineering, as the context will accumulate over those long horizon and bodies of work.It needs to be good at giving the agent a sandbox that's secure so the agent can actually take action within an environment.It has to be reliable so the agent can run on hours or even days at a time.And it also has to be able to do things like parallelized workflows so the agent can tackle multiple parts of a complex problem at once, and many, many more.

……这让你可以很容易地把某个组件换掉、把它当成单独一块去迭代，同时整体架构保持稳定。Claude 托管 agent 围绕设计的另一个关键点是长时运行的 agent（long running agents）。当我看 Anthropic 内部那些让人兴奋的产品——比如 Claude Code 和我们团队非常期待的 Claude Tag——以及我在和其他同样在做真正 agent 化产品的企业团队合作时，我看到一个共同的模式：这些 agent 正变得越来越异步，处理的任务也越来越复杂、越来越有挑战。要设计一个真能承接这种量级工作的 harness，它需要具备几样东西：它得擅长 context engineering（上下文工程），因为在这种长周期、大体量的工作里，上下文会不断累积；它得能给 agent 一个安全的沙箱，让 agent 真的能在环境里动手做事；它得足够可靠，让 agent 能连跑几个小时甚至几天；它还得能做并行化的工作流，让 agent 可以同时啃一个复杂问题的多个部分——诸如此类，还有很多。

[11:06] Isabella Kai He

So now what I want to do is dive into some of the engineering fundamentals that go into Manage Agents to make it possible to tackle some of those challenges.One of the core architectural decisions that went into Manage Agents that sets the foundation for the rest of the slides that we're going to walk through is the decision to decouple the brain from the hands of the agent.When our team first set out to build Manage Agents, we started by putting the agent loop and the tool execution in the same box in the same environment.What this meant was that the agent loop would be able to easily able to call tools and read in tool results because it had it right there in the same container.But then we ran into a series of limitations.This being that the container was blocking the agent being able to start its model reasoning so the agent would be able to kick off until the container was fully set up.It also meant challenges for reliability because if one part of this component went down, the entire box of the agent would go down.Our solution to this was to decouple the two elements, separating the brain or the agent loop from the hands or the tool execution environment of the agent.This meant several things. It meant improved reliability and it also meant that the brain could only spin up sessions when it actually needed it on demand.

接下来我想深入讲讲托管 agent 里的一些工程基础，正是它们让上面这些挑战变得可解。托管 agent 里有一个核心架构决策，它是后面这几页幻灯片的地基，那就是：把 agent 的「大脑」和「手」解耦。我们团队最早做托管 agent 时，是把 agent 循环和工具执行放在同一个盒子、同一个环境里的。这样做的好处是 agent 循环能非常方便地调用工具、读取工具结果，因为东西就在同一个容器里。但随后我们撞上了一连串限制。第一，容器成了阻塞项——agent 必须等容器完全搭好才能开始模型推理、才能起步。第二，可靠性也有问题：只要这个组合里有一个部件挂了，整个 agent 的盒子就一起挂。我们的解法是把这两块拆开：把「大脑」（也就是 agent 循环）和「手」（也就是 agent 的工具执行环境）分离。这带来了几件事：可靠性提升了；而且大脑可以只在真正需要的时候，才按需拉起会话。

[12:15] Isabella Kai He

And now let's dive into how some of these replaceable components meant keeping long running agents safe.First of all, if the sandbox or the hands of the agent died, because the brain was in a separate component, the brain could just spin up a new sandbox and retry and then continue as it left off.If the brain of the agent dies, we're actually going to walk through something in just a moment here about how everything that the agent does is logged into a durable session resource in a session log.Which means that the brain of the agent can actually just read from that session log, go back into context and resume exactly where it left off as well.This means that manage agents is designed around three core primitives.And that is the agent. And that is what your agent is especially defining what your agent does for your use case.This is a thing like the model that goes into your agent, the prompts, the tools, the skills, everything that makes your agent work for your particular use case.Next up is the environment. And this is the container that the agent actually runs in.You can actually have multiple sessions run on the same environment definition.And you can even attach multiple sessions to run the same environment at once, but each with its own isolated container instance.

接下来我们看看，这些可替换的组件是怎么让长时运行的 agent 保持安全稳妥的。首先，如果沙箱、也就是 agent 的「手」死了，因为大脑在另一个独立组件里，大脑可以直接拉起一个新沙箱、重试，然后从断点继续。如果 agent 的「大脑」死了呢？我们马上会讲到一件事：agent 做的每一件事，都会被记录进一个持久化的会话资源里，也就是 session log（会话日志）。这意味着 agent 的大脑可以直接从这份会话日志里读回来、把上下文恢复，然后同样从断点精确地接着干。这也意味着托管 agent 是围绕三个核心原语设计的。第一是 agent，也就是定义你的 agent 具体是干什么的——比如用哪个模型、prompt、工具、skills（技能），所有让这个 agent 适配你自己场景的东西。第二是 environment（环境），也就是 agent 实际运行的那个容器。多个会话可以跑在同一份环境定义上；你甚至可以让多个会话同时挂在同一个环境上，但每个会话有自己隔离的容器实例。

[13:28] Isabella Kai He

When you combine an agent with an environment, you get a session.What a session is, is it's a durable resource persisted in the cloud of every single interaction that you have with the agent,which unlocks several things like observability, a long running instance, reliability, all through this core architectural decisions.Now, when I work with many teams that are bringing an agent from a prototyping phase all the way to a production phase,one of the main challenges that we see is that reliability is a core concern.It's a different story to build an agent that runs on your laptop and serves you as a single user compared to when you actually want to deploy it in productionand run it at scale for hundreds of thousands or even millions of users.You need to make sure, especially if your agent is going to run for long hours at a time, that it's going to be reliable and can actually recover from tool failures.Manage agents, because of the way it's designed around those three primitives that we just walked over,is able to have four distinct session states.And that is idle, when your agent is waiting on user input, running when it's actually executing,rescheduling when it encounters an error and it's going to retry, or terminated if it's unrecoverable.

当你把一个 agent 和一个 environment 组合起来，你就得到一个 session（会话）。session 是什么？它是一份持久化在云上的资源，记录了你和这个 agent 的每一次交互。正是这个核心架构决策解锁了好几样东西：可观测性、长时运行的实例、可靠性。我在和很多把 agent 从原型阶段推到生产阶段的团队合作时，看到的一个主要挑战就是：可靠性是核心顾虑。做一个跑在你自己笔记本上、只服务你一个用户的 agent，和真的把它部署到生产、给成千上万甚至上百万用户跑，完全是两回事。你必须确保它可靠、能从工具失败里恢复过来——尤其当你的 agent 要一次连跑好几个小时的时候。托管 agent 因为是围绕刚才那三个原语设计的，所以能有四种明确的会话状态：idle（空闲，agent 在等用户输入）、running（运行中，正在执行）、rescheduling（重排中，遇到错误准备重试）、terminated（终止，不可恢复）。

[14:35] Isabella Kai He

This means that the agent can always go back to an existing session and resume where it left off,and it also has a mechanism for it to recover from those failures in production.Another common theme that we see with designing effective agents, especially as model capabilities evolve, is context engineering.Now, context engineering is something that our team has done a ton of research into,because it is one of the things that separates an effective agent from an agent that gets lost in context rot.Context engineering is also difficult, and with many traditional harness implementations,the context window in the session are one and the same, which means that Claude,if it wants to come in and discard portions of the context that it's in current session run,it doesn't have a mechanism to be able to recover pieces of that context back into its windowif it loses it at one point in its current session run.However, because everything in manage agents is logged to a durable, persisted session log resource,what this unlocks is that the harness can actually just read in slices of that context from the session log into its current window.If it then has Claude coming in and editing or discarding portions of that run,

这意味着 agent 永远可以回到一个已存在的会话、从断点继续，同时它也有一套机制能在生产环境里从失败中恢复。另一个在设计高效 agent 时反复出现的主题，尤其是在模型能力不断演进的背景下，是 context engineering（上下文工程）。上下文工程是我们团队做了大量研究的一件事，因为它正是把「高效的 agent」和「陷进 context rot（上下文腐烂：上下文塞得太多太杂，模型反而变糊涂）的 agent」区分开来的关键之一。上下文工程也很难。在很多传统的 harness 实现里，上下文窗口（context window）和会话是同一个东西——这意味着如果 Claude 想丢掉当前这轮会话里的一部分上下文，一旦丢了，它就没有机制能把那部分内容再捞回窗口里。但在托管 agent 里，因为所有东西都被记进了那份持久化的会话日志资源，这就解锁了一件事：harness 可以直接从会话日志里，把某几片上下文重新读回当前窗口。如果 Claude 在这轮运行里编辑或丢弃了某些部分……

[15:42] Isabella Kai He

it can simply recover it by just rereading it from the session log,because everything is persisted in that log resource.What this means is that what we see is increasingly developers are able to rely on portions of the manage agent harness

……它可以直接从会话日志里重新读一遍就恢复了，因为一切都持久化在那份日志资源里。这意味着我们看到的是：开发者越来越可以直接依赖托管 agent 这个 harness 自带的那几块能力……

[15:56] Isabella Kai He

that come with the harness itself.This is things like the agent loop, memory, observability,all that comes alongside building with Claude manage agents.It also exposes key areas for the developer to be able to customize,and this is context management and domain expertise.This is what separates a coding agent from a legal agent or a go-to-market agent,and again, is what makes your agent truly ready for your users.For instance, with Claude Code, Claude Code uses a set of tools like Bash and grep on your laptop,just like how developers do when they open up their terminal,but a go-to-market agent or a legal agent would need a vastly different set of tools.So by having this part of the manage agent harness managed by Anthropic,what that means is that developers can focus on their time designing the right system prompts,the right skills, and the right tools to make their agent truly work for their users.Now what I want to do is hand it over back to Goggin to walk you through one example in a live demowhere you can see a customized agent for a production use caseand how simple it is to build a production-ready agent with managed agents.All right. Thank you, Isabella.Let's switch over.All right.

……也就是 harness 本身自带的东西，比如 agent 循环、记忆（memory）、可观测性——用 Claude 托管 agent 构建时这些都是附送的。同时它也把几个关键位置暴露出来让开发者自己定制，那就是上下文管理和领域专长。这正是一个写代码的 agent 和一个法务 agent、或者一个 go-to-market（市场推广）agent 之间的差别所在，也是让你的 agent 真正能服务你自己用户的关键。举个例子，Claude Code 在你的笔记本上会用 Bash、grep 这类工具，就像开发者打开终端时做的那样；但一个 go-to-market agent 或者法务 agent 需要的工具组合会完全不同。所以把 harness 里这部分交给 Anthropic 托管，意味着开发者可以把时间集中在设计正确的系统提示词、正确的 skills、正确的工具上，让 agent 真正为他们的用户干活。接下来我把话筒交回给 Gagan，他会带大家看一个现场 demo，看看一个为生产场景定制的 agent 长什么样，以及用托管 agent 造一个生产就绪的 agent 有多简单。好，谢谢你，Isabella。我们切一下画面。好的。

[17:05] Gagan Bhat

So now that you heard from Isabella how managed agents works under the hood,let's look at what it feels like to actually build with it.What does it feel like to actually create your own production-grade agent from scratch?

刚才 Isabella 讲了托管 agent 在底层是怎么工作的，那我们现在来看看，真正用它来构建是什么感觉。从零做出一个属于你自己的、生产级的 agent，体验到底是怎样的？

[17:19] Gagan Bhat

This is a semi-interactive demo, so please bear with me here and follow along.Imagine that you're an engineer and you own a dashboardthat basically contains all the key metrics for the services that you own.It's called Atlas.And one day you're just enjoying life and you start to see that the P99 latencysuddenly starts spiking.It's 10x over baseline.So you have an incident on your hands.You see your logs, you see a bunch of text,and you have to figure out like what exactly is going wrong.Wouldn't it be nice if there was a site-reliability engineering agentthat could investigate all these tedious data pointsand come back to you with the root cause before even you open your dashboard?

这是一个半互动的 demo，请大家配合我一下、跟着走。想象你是一个工程师，你负责一个 dashboard（仪表盘），上面是你所负责的那些服务的所有关键指标，这个盘叫 Atlas。某天你正岁月静好，突然发现 P99 延迟（最慢的那 1% 请求的耗时）开始飙升，比基线高了 10 倍。你手上有个线上事故了。你去看日志，看到一大堆文本，然后你得从里面搞清楚到底哪儿出了问题。那如果有一个 SRE（site reliability engineering，站点可靠性工程）agent，能替你把这些琐碎的数据点全部查一遍，在你打开 dashboard 之前就把根因（root cause）带回来给你——那该多好？

[18:03] Gagan Bhat

Well, that's what we're going to implement today.We're going to build this from scratch using cloud-managed agentsand it'll walk you through the steps using the primitivesthat Isabella shared earlier.Okay.So let's build it.The first primitive, as mentioned earlier, is the agent definition.You define what the agent does and everything that it needs to accomplish that task.So in this case, I define the name as the SRE investigator.I give a model as Cloud Opus 4.8.I have a system prompt that kind of defines the instructions for the agenton how to behave and tools.The agent tool set gives it a standard set of tools like Bash,grep, and blob, et cetera.And there's an MCP tool set that connects to my dashboardand allows it to pull specific things like deploysand the metrics that I showed earlier.That's step one, agent definition.Step number two.Let's now define where does it run.This is the environment that we were mentioning before.Here we create an environment that is SRE Sandboxand I configure it to run on the Anthropic Cloudwith the networking limitedand allow those hosts only being the MCP serverthat I wanted to communicate to.This environment effectively stops Cloudfrom doing things that you didn't intend.

这正是我们今天要实现的东西。我们要用 Claude 托管 agent 从零把它造出来，并且会用到 Isabella 刚才讲的那几个原语，一步步走一遍。好，那我们开始造。第一个原语，前面说过，是 agent 定义。你定义这个 agent 干什么，以及它完成这个任务所需要的一切。这个例子里我把它命名为 SRE Investigator（SRE 调查员）；模型我给的是 Claude Opus 4.8；我写了一段系统提示词，定义这个 agent 该怎么行事的指令；然后是工具。agent 工具集给了它一套标准工具，比如 Bash、grep、glob 等等；另外还有一个 MCP 工具集，连到我的 dashboard，让它能拉到具体的东西，比如前面看到的发布记录（deploys）和各项指标。这是第一步，agent 定义。第二步：我们来定义它在哪儿跑，也就是前面提到的 environment（环境）。这里我们建了一个叫 SRE Sandbox 的环境，配置它跑在 Anthropic 的云上，网络是受限的，允许访问的主机只有我想让它通信的那台 MCP 服务器。这个环境实际上就是在阻止 Claude 去做你并不打算让它做的事。

[19:20] Gagan Bhat

We can control boundaries here.Next, let's give it the logisticsand the details that it needs to solve this task.And one of the key things is the application logs I showed earlier.You can upload files and skills just like thisand you can set it up so that it reads from those.So now we have the agent definition,so what it is.We have the environment, which is where it runs.We have relevant evidence.And so now we set it up so we can kickstart a session.The session combines these durable resources into a new sessionand it specifies the log point as a resourceand it allows the agent to kick off.That's it.What you have defined here is now living in the Anthropic Cloud.And this can be dynamic as needed in your application.So once we do this, we kickstarted the sessionand let's go back to the investigator agent earlierand say, hey, I have an incident.My checkout is like super high.Can you please investigate?

我们在这里可以控制边界。接下来，给它解决这个任务所需要的资料和细节。其中一个关键的东西就是我前面展示的应用日志。你可以像这样把文件和 skills 上传上去，并配置成让它去读这些内容。所以现在我们有了 agent 定义（它是什么）、有了环境（它在哪儿跑）、有了相关的证据材料。那现在我们可以启动一个 session（会话）了。session 把这些持久化的资源组合成一个新的会话，并把日志文件指定为一个资源，然后就让 agent 跑起来。就这样。你在这里定义出来的东西，现在就活在 Anthropic 的云上了。而且在你的应用里，它可以按需动态生成。搞定之后我们启动会话，回到刚才那个调查员 agent，跟它说：嘿，我这儿有个事故，我的结账（checkout）延迟高得离谱，你能帮我查一下吗？

[20:17] Gagan Bhat

Cloud immediately spins up.The brain spins up in Cloud Managed Agents in the Cloud.It uses the hands, which is a sandbox,to grep and find specific details in the application logs.It uses relevant metrics using MCP toolsand finds the recent deploysand isolates where the incident started.It does further investigation,finds the code diff,and synthesizes this informationto figure out a final root cause.Just like that, Cloud Managed Agents was able to run in the cloud,we were able to define it in code,and have everything running end-to-end.And to clarify, this is just one session.All of this is production infrastructure.So you can imagine multiple sessions kicked offby all of your users, ready to go immediately.And we have a beautiful observability dashboardthat allows you to see all of these sessions on demand.If I click into one of the observability dashboardson the Cloud console,you will find the different exact event trace,the session logs for that event,including the tools that are used, the results of it,and any other agent messagesthat came into picture.With that, we were able to walk throughwhat it feels like to build a Cloud Managed Agentfrom scratch with just a few lines of code.

Claude 立刻就起来了。大脑在云端的 Claude 托管 agent 里拉起来；它用「手」——也就是沙箱——去 grep、在应用日志里找具体线索；它通过 MCP 工具去查相关指标，找到最近的发布记录，把事故的起始点圈定出来；然后继续深挖，找到那次代码 diff（改动差异），把这些信息综合起来，推断出最终的根因。就这样，Claude 托管 agent 在云上跑完了这一趟，我们用代码把它定义出来，整条链路端到端跑通。另外澄清一下：这只是一个会话。而这一切都是生产基础设施。所以你可以想象，你的所有用户同时开出无数个会话，随时都能跑。我们还有一个很好看的可观测性仪表盘，能让你随时看到所有这些会话。如果我点进 Claude Console（Claude 控制台）上的某个可观测性面板，你会看到那次运行确切的事件轨迹（event trace）、那个事件的会话日志，包括用了哪些工具、工具返回了什么结果，以及其他所有出现过的 agent 消息。到这里，我们就走完了「用几行代码从零造一个 Claude 托管 agent」是什么体验。

[21:35] Gagan Bhat

All right.Perfect.So with that, let's go into the next section.We've learned now how Cloud Managed Agents works under the hood.We've learned what it feels like to build a production-grade agentat scale using it.Now let's talk about what we've learned from taking this to the field,what we've heard from customers,and what we've learned generally building production-scale agents.There's four lessons here,and I'll start off with the first one.The first lesson is to keep the credentials away from your agent.A lot of customers ask me,how do I make sure my agent doesn't read or see the environment filethat contains all my security tokens?

好的，很好。那我们进入下一节。我们已经知道了 Claude 托管 agent 在底层是怎么工作的，也知道了用它造一个生产级、可上规模的 agent 是什么感觉。那现在我们来聊聊：把这套东西带到客户现场之后我们学到了什么、客户告诉了我们什么，以及我们在构建生产规模的 agent 这件事上普遍学到了什么。这里有四条教训，我先讲第一条。第一条教训是：把凭据挡在 agent 之外。很多客户问我：我怎么才能确保我的 agent 读不到、也看不到那个装着我所有安全令牌的环境变量文件？

[22:15]

This is a very important aspect.We already get some of this because we,as I mentioned earlier,we separated the brain from the hands.So where the agentic loop runs is separatefrom where the tool execution happens.We took it a step further by introducing the concept of walls,where you can store security credentials in a secure way,and they're decrypted only when needed at tool execution runtime.This way, you can effectively keep credentials away from your agent,and the model never sees your security tokens.Perfect.Now time for lesson two.And I'm sure if any of you in this roomhave built a production-ready agent,latency has been one of the things that's top of mind for you.What we realized when we decoupled the brain from the hands of the agent,as we talked about,is that this actually unlocked a key benefitthat really mattered for a lot of our customersbuilding on managed agents out in the wild.And that is that it improved latency significantlybecause the agent was no longer blocked on reasoningbased on container setup.So we go back to the first version with the coupled designwhere we had the harness in the same container in one single box.Essentially, the model wouldn't be able to start reasoning

这是非常重要的一个点。我们其实已经天然拿到了一部分保障，因为像前面说的，我们把「大脑」和「手」分开了——agentic loop 跑的地方，和工具执行的地方是分离的。我们又往前走了一步，引入了 vault（保险库）的概念：你可以把安全凭据以安全的方式存起来，只有在工具执行运行时真正需要的那一刻才解密。这样你就能有效地把凭据挡在 agent 之外，模型永远看不到你的安全令牌。好。现在是第二条教训。我相信在座只要造过生产就绪的 agent，延迟（latency）一定是你最挂心的事情之一。我们把 agent 的「大脑」和「手」解耦之后发现，这件事还顺带解锁了一个对很多在外面用托管 agent 构建的客户来说非常关键的好处：延迟大幅改善，因为 agent 不再被容器搭建卡着才能开始推理。我们回到最早那个耦合设计的版本——harness 和一切都在同一个容器、同一个盒子里。那种情况下，模型在容器完全搭好之前根本没法开始推理……

[23:25]

or outputting its first token until that container setup was fully complete,which meant that it had delays in the latency,especially for time to first token.When we then decoupled the brain from the hands of the agent,this is what we get.Now we can have model reasons start immediatelyand we can run container setup in parallel.What this means is that the model can then run container setupso that the brain of the agent actually has the hands when it needs it,or we can actually skip the container setup entirelyif for this particular taskwe actually don't need the container setup in the first place.What we then saw when we tested this is that we saw 60% faster time to first tokenfor P50 use cases or median use cases,and over 90% improvements in latency for time to first token in P95 use cases.Lesson three is about session logs.A lot of customers asked us the question,how can I figure out what's actually going on in my agent under the hood,and how can I make my agent better over time?

……也没法吐出第一个 token，这就导致延迟被拖长，尤其是 time to first token（首 token 时间，即你按下回车到看见第一个字之间的等待）。把大脑和手解耦之后，我们得到的是：模型推理可以立刻开始，容器搭建并行去跑。这意味着我们可以一边让模型推理、一边把容器搭好，等 agent 的大脑需要「手」的时候手已经在了；甚至如果这个任务压根不需要容器，我们可以完全跳过容器搭建这一步。我们实测之后看到的结果是：首 token 时间在 P50（中位数）场景下快了 60%，在 P95（最慢的 5%）场景下延迟改善超过 90%。第三条教训是关于 session log（会话日志）的。很多客户问我们两个问题：我怎么才能搞清楚我的 agent 底下到底在干什么？以及，我怎么才能让我的 agent 随时间越变越好？

[24:29]

Turns out the answer to both of these questions lies in something that we call the session log, or traces.The session log essentially contains events of everything that happened during an agent execution.So the user message, the model response, the tool executions, the results,everything is written play by play.Now if you surface the session log in a UI that users can see, it provides observability.It turns out that the same session log also improves memoryand provides self-improvement for the agent.Memory essentially allows the agent to remember things about the user.And session logs gives a history of past executions.And if you combine that with something that we call dreaming,it allows memory to be updated and improved over time.So the next time your agent runs, it gets better.We'll talk a bit more about this later.And now for the last lesson that we have for you today,that is security for tool execution.And this is something that we heard from a lot of enterprise teamsthat were wanting to build on manage agents,is that it really mattered to them how they were able to control the environmentwhere they ran tool execution.For a lot of teams that were very security conscious,they wanted to be able to have everything controlled

结果发现，这两个问题的答案都落在我们叫做 session log（会话日志）、或者叫 traces（轨迹）的东西上。会话日志本质上记录了 agent 一次执行过程中发生的所有事件：用户消息、模型回复、工具执行、执行结果——一五一十全写下来。那么，如果你把这份会话日志呈现在一个用户能看到的界面上，它提供的就是可观测性。而事实证明，同一份会话日志还能改进记忆（memory），并让 agent 具备自我改进能力。记忆让 agent 能记住关于用户的一些事；会话日志则提供了过去执行的历史。如果你再把它和我们叫做 dreaming（做梦）的东西结合起来，记忆就能随时间被更新和改进——这样你的 agent 下一次跑的时候就更强了。这个我们待会儿再多讲一点。现在是今天的最后一条教训，那就是工具执行的安全性。这是我们从很多想在托管 agent 上构建的企业团队那里听到的：他们非常在意自己能不能控制工具执行所在的那个环境。对很多安全意识很强的团队来说，他们希望一切都被控制在……

[25:44] Isabella Kai He

in their own virtual private cloud.And because of the key decision that we made,decoupling the brain from the hands of the agent,what we actually get is that the hands can run anywhere,including in your virtual private cloud.So the feature that we released called self-hosted sandboxes,we built this from an engineering perspective because of the feedback that we heardand essentially made it available to have customers control their sandbox control planexactly for their own execution environmentsand to have tools run exactly under their own policies.Another feature that we unblocked is MCP tunnels.And this is from teams that were saying that they wanted to expose MCP servers to their agent,but didn't want to have their MCP servers running over the public internet.For those teams, essentially with MCP tunnels,they can have their MCP servers run only within their private networkand only making outbound calls to the cloud agent loop.And so with everything that we've talked through

……他们自己的 virtual private cloud（VPC，虚拟私有云）里。而正因为我们做了「把大脑和手解耦」这个关键决定，我们实际得到的结果是：「手」可以跑在任何地方，包括跑在你自己的 VPC 里。所以我们发布了一个叫 self-hosted sandboxes（自托管沙箱）的功能。我们是听到这些反馈之后从工程角度把它做出来的，本质上就是让客户能自己控制沙箱的控制平面（control plane），完全按他们自己的执行环境来，让工具完全按他们自己的策略运行。我们解锁的另一个功能叫 MCP tunnels（MCP 隧道）。这来自一些团队的诉求：他们想把 MCP 服务器暴露给自己的 agent，但不希望 MCP 服务器跑在公网上。对这些团队来说，有了 MCP 隧道，他们的 MCP 服务器就可以只跑在自己的私有网络里，只对云上的 agent 循环发起出站调用。那么，把我们讲过的这些……

[26:36] Isabella Kai He

and those four lessons that Gagan and I just walked over,we talked about how manage agents is helping you build for this iterative capabilityand helping you follow along with model evolution.What I now also want to talk you through is how those fundamentals are builtand expanded upon with some of our most exciting frontier featuresto show you how cloud manage agents will continue to evolveand capture the model capabilities of tomorrow.Cloud manage agents, we touched on just the tip of the iceberg

……以及 Gagan 和我刚刚过完的那四条教训放在一起，我们讲的是：托管 agent 怎么帮你为「能力持续迭代」这个现实去构建，帮你跟上模型的演进。接下来我还想带大家看看，这些基础是怎么被一些我们最兴奋的前沿功能进一步扩展的，让大家看到 Claude 托管 agent 会怎么继续演化、怎么把明天的模型能力吃进来。关于 Claude 托管 agent，我们今天只触到了冰山一角……

[27:04] Isabella Kai He

of the features that are available today, and these cover the fundamentals.But we're also excited to see how the harness evolves as model capabilities evolve.And I'm excited for some of the new features that we've been experimenting with,like scheduled deployments, self-hosted sandboxes,multi-agent orchestration, dreaming, outcomes, memory, and more.We won't have time to cover all of them,so I'm going to talk about two of our favorites,which is dreaming and outcomes.Let's start with dreaming.As I mentioned before, we have access to the transcripts or the session logsfrom the agent's daily sessions,and the agent also has a current memory state.What we found is that as models have evolved and become more capable,if you feed the transcripts and the memory state as a periodic batch processwith what we call dreaming,it allows us to extract new insights and new organized structuresthat essentially feed back and edit the memory as neededto make the next day's agent sessions automatically much more intelligent.This is how we're seeing self-improving agents as they execute more and more over time.Dreaming and memory, we feel, are just two cornerstones of a new frontier unified memory system.

……我们讲的只是今天已经可用的一小部分功能，而且都是基础层面的。但我们也很期待看到 harness 随着模型能力演进而演进。我很期待我们正在试验的一些新功能，比如：定时部署（scheduled deployments）、自托管沙箱、多 agent 编排（multi-agent orchestration）、dreaming（做梦）、outcomes（成果判定）、memory（记忆）等等。时间不够全讲，所以我挑我们最喜欢的两个说：dreaming 和 outcomes。先说 dreaming。前面提过，我们能拿到 agent 每天那些会话的转写记录、也就是会话日志，同时 agent 还有一个当前的记忆状态。我们发现，随着模型变得越来越强，如果你把这些转写记录和记忆状态喂进一个周期性的批处理过程——也就是我们说的 dreaming——它能提炼出新的洞察、新的组织结构，反过来按需修改记忆，从而让第二天的 agent 会话自动变得聪明得多。这就是我们看到的「agent 在不断执行中自我改进」的方式。我们觉得，dreaming 和 memory 只是一套全新的、前沿的统一记忆系统的两块基石。

[28:24]

Memory gives the agent the ability to remember things across the user that's specific to its use case.Dreaming allows agents to self-improve.But we see a new form of memory emerge that is organizational scale,and that kind of illustrates and stores the team's runbooks and details.And we believe that this is just the initial areas in which we can see harnesses evolve towardsas models become more capable.I also love dreaming, but one of my other favorite features is something called outcomes.What you get with an outcome is that what we allow users to essentially defineis success criteria for their agents.You define a rubric.You say what means that the agent is actually able to complete the task successfully.You define failure cases.And then outcomes essentially starts a separate grader agent that runs alongside your agentloop and looks at whether that agent was actually able to accomplish the task based on your definedsuccess criteria.What this then does is that the agent will execute the task at hand.It will then look at that grader and check across the rubric that you defined.If the grader determines that the agent was not able to complete the task, it will keep tryinguntil it reaches that success criteria that you have defined for your agent.

记忆让 agent 能跨会话记住那些针对它自己使用场景、针对用户的东西；dreaming 让 agent 能自我改进。但我们还看到一种新形态的记忆正在浮现，那是组织级别的记忆——它把团队的 runbook（应急操作手册）和各种细节呈现出来、沉淀下来。我们相信，这只是 harness 在模型变强的过程中可以演化的最初几个方向而已。我也很喜欢 dreaming，不过我另一个特别喜欢的功能叫 outcomes（成果判定）。outcomes 让用户能为自己的 agent 定义成功标准：你写一份 rubric（评分标准），说清楚什么才算这个 agent 真正把任务完成了；你也定义失败的情形。然后 outcomes 会启动一个独立的 grader agent（打分 agent），跟你的 agent 循环并行跑，去判断这个 agent 是否真的按你定义的成功标准完成了任务。接下来会发生的是：agent 执行手上的任务，然后去看那个打分器、对着你定义的评分标准逐条检查。如果打分器判定 agent 没能完成任务，它就会一直重试，直到达到你为这个 agent 定义的成功标准为止。

[29:38]

What really excites me about outcomes is that we're moving more towards a world where we can have an agentunderstand what success actually means for a task and have a mechanism to keep iterating it,which gives us more reliability that the agent can actually complete the outcomes.And we can start to unlock a new set of tasks that were not possible just a couple of months agoas models continue to evolve and can accomplish outcomes or tasks that are increasingly complex,especially as Claude achieves new levels of intelligence.So across everything that Goggin and I have talked about today, what Manage Agents is trying to do is to close the gap between what products offer today on many surfaces with static harnesses and what models can actually do.

outcomes 真正让我兴奋的地方在于：我们正在走向这样一个世界——agent 能理解一个任务的「成功」到底意味着什么，并且有一套机制持续迭代，这让我们对「agent 真能把结果做出来」这件事更有把握。而且我们能开始解锁一批几个月前还做不到的任务——随着模型持续演进，它们能完成的成果和任务会越来越复杂，尤其是当 Claude 达到新的智能水平之后。所以，把 Gagan 和我今天讲的所有内容合起来看，托管 agent 想做的事情是：弥合「产品今天在各种界面上、靠静态 harness 能提供的能力」和「模型实际上做得到的能力」之间的那道差距。

[30:21] Isabella Kai He

What we see as Claude models and other models essentially evolve alongside this exponential trajectory is that harnesses have become the limiting factor to what models can achieve.And so with Manage Agents, with the core architectural foundation that we offer to developers, as long as with all of these new exciting features that we're continuing to build,what we're trying to do is to close that gap so that products can get closer to what models can actually achieve today.And so with that, I hope all of you walk out of this room learning something new about how our team went about building Manage Agentsand how Claude Manage Agents is structured to capture frontier intelligence as models continue to evolve and be a harness that's production-ready for real workloads.Thank you all so much today for being here and for listening to our talk.Thank you.

我们看到的是：当 Claude 模型和其他模型沿着这条指数曲线不断演进，harness 已经变成了限制模型能力发挥的那个瓶颈。所以托管 agent 想做的，就是靠我们提供给开发者的这套核心架构基础，加上我们还在持续构建的这些令人兴奋的新功能，把那道差距缩小，让产品能更接近模型今天真正能达到的水平。最后，希望在座各位走出这个房间时，都能对我们团队是怎么造出托管 agent 的、以及 Claude 托管 agent 是怎么被设计成「能承接前沿智能、能跟上模型演进、能撑住真实生产负载」的 harness，有一些新的收获。非常感谢大家今天来听我们的分享。谢谢。