Anthropic 平台：从知识到执行再到协调

最上层的抽象层大概是协调层。所以你有知识层、执行层，还有协调层。在协调层，我们开始思考一些类似策略的东西，基本上它就像一个元框架。真正的底层框架是为执行而设计的。但下一层是关于：如果 token 不是完全可互换的，你需要给它们不同的任务，比如有些 token 负责建议，有些负责执行，那么你就需要开始组合这些编排好的策略，它们应该位于所有这些层之上，因为归根结底你仍然需要执行，而执行也需要知道该做什么。所以理论上，所有东西都应该像梯子一样连接起来。因此，我认为，如果你看看我们的路线图，并稍微展望一下我们预期的发展方向，你会看到我们越来越多地从知识层转向执行层，再从执行层转向协调层，体现在我们推出的抽象层上。Katelyn 和 Angela，非常感谢你们今天加入我们。Lauren 和我非常高兴能请到你们。你们负责构建 Anthropic 的平台，我认为这是世界上最重要的开发者平台之一，甚至可能是最重要的。我们非常兴奋今天能采访你们，了解更多关于未来的方向。那么，首先能给我们介绍一下 Anthropic 平台是什么，以及你们在 Anthropic 中的角色吗？

The last layer of abstraction on top of this is probably the coordination layer. So you have knowledge and you have execution, you have coordination. And at the coordination layer, we're beginning to think of these things called like strategies where basically it's almost like a meta harness. The true low-level harness is designed for execution. But the next one is about okay if tokens aren't really fungible and you need to give them different jobs like maybe some this token is advising versus this token is executing you want to start composing these like these kind of orchestrated strategies that go together and they should sit on top of all these things because at the end of the day you still need to execute and the execution still needs to know what to do. So everything in theory should kind of like ladder together. And so I think you know if you were to look at our road map and the maybe kind of project forward a little bit where you kind of expect us to go. We'll move more and more from the knowledge layer to the execution layer and from the execution layer to the kind of coordination layer in terms of the abstractions that you can see us put out. Katelyn and Angela, thank you so much for joining us today. Lauren and I are thrilled to have you here. You are responsible for building Anthropics platform and so you are responsible for building what I think is one of the most important if not the most important developer platform in the world and we are really excited to interview you today to understand more about what's ahead and so maybe just to get started can you give us the context of you know what is anthropic platform and where do you sit within anthropic?

是的。平台既包括我们面向外部的 API，即开发者平台，人们可以在其上构建应用和系统来访问 Claude 的智能；也包括内部，我们运行产品基础设施，基本上我们的内部应用也是构建在这一层之上的。

Yeah. So platform is both our externally facing APIs, our developer platform that people build on top of when they want to build applications and systems that access Claude's intelligence, as well as internally we run our product infrastructure and basically we're the layer that our apps build on top of internally as well.

太棒了。你们团队的目标是什么？

Awesome. What's your northstar as a team?

好问题。实际上，因为我们同时服务内部和外部，所以我们有两个目标，你可能会问为什么只有一个目标，但……

It's a great question. We actually because we have both internal and external. We actually kind of have like two north stars which is probably like you know you'd be like why there should only be one north star but um no we

不同的行星系统。

different planetary system.

是的，它们是不同的太阳系，所以没问题。嗯，在内部方面，我们真正想要的是为内部团队提供尽可能多的杠杆，让他们能够交付 AGI 级别的产品。我们希望他们能够快速行动，拥有可靠、出色的平台来构建。但速度这个关键点对我们来说是非常刻意的，我们内部非常重视这一点。外部方面，我们实际上有更复杂的事情。但其中一个真正的目标是，基本上给任何开发者提供工具，让他们能够与 Claude 合作，构建他们想构建的任何东西。这是一个比较宽泛的说法，但最终归结为：无论业务在哪里，我们都希望把平台带到离业务非常近的地方。这就是为什么我们花大量时间与超大规模云提供商紧密集成，比如 AWS、Google 等等。我们最终创建了很多原语。我们希望人们能够表达他们认为自己的产品应该是什么样子。我们希望他们能够几乎以他们自己的方式做定制软件。你知道，在这个 AI 的新世界里，过去在经济上可能不可能的定制软件的最后一英里，现在理论上应该变得非常可行。我们想给他们所有的工具和能力去做这件事。有时这以原语、API 和更高层次的抽象形式出现。有时这以标准的形式出现，比如 skills 和 MCP。这些是 Claude 需要的东西才能有用，我们可以把它们提供给整个生态系统，与每个人合作，帮助你们创建这些东西，并从 Claude 中获得最大收益。所以，外部方面，我们确实专注于帮助你构建；但内部方面，虽然这个方向仍然存在，但可能更侧重于速度和快速行动的能力。

Yes exactly they're separate solar system so it's fine. Um but uh on the internal side like we really want to provide is like literally as much leverage as possible for our internal teams to be able to ship like AGI pill products. Um and we want them to be able to move fast, be able to have reliable like great like uh platform uh to be able to build on top of. But I think that key bit about speed is like really intentional for us and we really really care about that internally. Externally um we actually have a lot more like complicated set of things. Um but one of the true norths that we have there is to be able to basically give any builder the tools to be able to work with claude to build whatever they want to build. And so it's a bit of a broad statement but as a result that uh boils it itself down into you know being wherever that business is. Like we really care about like bringing our platform really really close to that business. This is why we spend a lot of time with the hyperscalers integrating really closely uh directly with them like AWS, Google, so on and so forth. Um and it is a lot of like primitives that we end up creating. We want people to be able to express what they think their product should be. We want them to be able to almost do like custom software in their own way. You know, like in this new world with AI, uh what used to be probably economically impossible was that last mile of of custom software now in theory should be like very very achievable. Um, and we want to give them all the tools and all the capabilities to go and do that. And so sometimes that comes in the form of primitives and APIs and higher order abstractions. And sometimes that comes in the form of just like standards. Uh, so for example like skills and MCP. Um, those are things just like cloud needs them to be useful and we can just give them out to the rest of the ecosystem, work with everyone to help you create those things and get the best out of cloud. So um I would say externally you know we really are oriented around just helping you just be able to build but internally that orientation while still existing is probably more you know specified towards speed and being able to move really quickly.

你们如何决定哪些内容进入平台，哪些对外发布，哪些不发布，从而决定哪些产品应该可用？

How do you decide what goes into the platform what gets externalized and what doesn't to decide what products should be available?

是的，我们通常尝试保持一种一致的哲学。这实际上是我们同时做内部和外部的原因之一。有很多其他的平台业务和架构会分化这两者。对我们来说，我们刻意保持它们平等，并尽可能坚持这样的理念：对于任何开发者，无论是内部还是外部，即使内部开发者可能有略微不同的需求，就像任何用户都有略微不同的需求一样，我们希望所有人都能使用相同的原语。其中一个总体论点是，我们看到这些模型的能力呈指数级增长，很难找到一个持久的形态。两年前，我们都认为一切都是聊天，现在大家都忘了聊天，只谈智能体，未来还会有另一种形态，再另一种形态。我们想象它会不断演变。因此，为所有人以及我们自己实现这一点的最佳方式，是构建一个真正强大的平台，给人们提供工具来找出这些形态是什么。我们绝不认为自己是唯一能找出这种形态的人，完全不是。事实上，我们在这方面做得越民主，帮助人们并允许他们实验，我认为这些形态就越会自然地从市场中涌现出来。

Yeah I mean we generally try to have a philosophy that we try to be consistent across the board. It's actually one of the reasons uh why we do internal and external. Um there's plenty of other you know platform businesses and constructs where you actually like bifrocate these two things. Um for us we kind of try to intentionally keep it equal and then as a result we try to hold this philosophy as much as we can around like you know for any builder internal or external even though if our internal builders might have some slightly different requirements in the same way any user would have slightly different requirements. Uh we want to have the same primitives that are available to everyone. And one of the maybe the overarching thesis for that is that we've just seen like the capabilities of these models just grow and such just exponential and it's really hard to figure out like a longlasting form factor. I think two years ago we were all like everything's chat and now everyone's like forget chat and just like agents and like there's going to be another form factor, another form factor. Um and we kind of imagine that like constantly evolving. And so the best way for us to kind of enable that for everyone and also ourselves is to actually build a really robust platform that gives people those kinds of like tools to figure out what those form factors are. And I don't think we by any means feel like we're the only ones capable of figuring out that form factor like not at all. In fact, the more democratization we can do on that and help people and allow people to experiment, I think the the more those form factors will actually kind of naturally come out of the market.

是的。是的。我认为在我们团队内部，我们有过这样的时刻：我们尝试以不同的、更高层次的方式打包我们的原语。我们想过，好的，我们已经用这个产品解决了这类问题，并将其推向世界。所以我们可以自己先试用，但我们绝不想陷入这样的陷阱：过度关注内部用户需要解决的问题。

Yeah. Yeah. And I think within our team, we've we've had moments where we're experimenting even with just like a packaging up of our primitives in a different sort of higher order way. And we've thought about, okay, cool. We've solved this exact type of problem with this product that we've built into the world. And so we can go and dog food it for ourselves, but we'd never want to fall into this trap of like we're overindexed on the problem as it needs to be solved for an internal user.

就像 Angela 说的，内部用户有非常具体的要求，外部用户也有非常具体的要求。如果你过度偏向其中一方，就会陷入陷阱。所以很多时候，我们会在内部试用某个功能的同时，也向外部客户开放某种早期访问，这样我们就能获得广泛的反馈，并将这些反馈带回平台。

Like because exactly what Angela said, internal users have very specific requirements. External users have very specific requirements and so if you overindex on one or the other, you fall into a trap. So a lot of the time what we'll do is dog food something internally at the same time that we open up early access of some sort with external customers so that we can kind of get a range of feedback and bring those things back into the platform.

我很想聊聊你提到的更高层次的抽象。我猜最底层就是直接访问 Claude Opus 或其他模型的 token。那么，你如何看待之上的抽象层次结构？

I'd love to talk about the higher levels of abstraction that you discussed. So I guess at the base level this is just you know raw access to Claude Opus or whatever tokens. How do you think about the I guess the layer cake of abstractions above that?

嗯，回顾一下，大约一年前我加入 Anthropic 时，平台基本上只有 messages API。我们推出了像 MCP 这样的标准，当然还有围绕 SDK、文档、控制台等的开发者工具。但大部分情况下，它是一个无状态 API。有趣的是，正如 Angela 提到的，随着模型在长时间运行和处理更多上下文方面变得更好，我们发现很多客户在反复解决同样的问题，而我们内部也在反复解决这些问题。你想构建能够在长时间运行甚至远程上下文中成功运行的智能体，而这些场景不一定有人类参与。所以我们发现，我们可以将我们的原语组合起来，搭建起我们内部用于支持自己产品的相同基础设施，从而得出一些更高级的抽象，让你能够开箱即用地完成更多智能体式工作。我们为你解决的问题包括：基础设施是一个很难处理的事情。比如，如何生成具有适当治理和安全性的沙箱，并在需要时启动和关闭它们？或者关于会话记录的存储，以便你可以暂停会话并在之后恢复。所以基础设施是我们希望提供更多开箱即用支持的重要部分，我们现在也确实在这样做。第二件事是 harness 和 harness 工程。很多思考和精力都花在如何做提示缓存、如何管理上下文窗口、如何从模型中获得更多智能，以及如何管理成本等方面。所以我们根据自己遇到的问题，将原语打包得更贴合实际，以便为人们提供更多开箱即用的功能。这样，如果他们为自己内部构建系统或构建产品，就可以更专注于他们想要解决的问题，如果他们想将某些方面的问题交给我们处理，也可以。这就是我们的理念。

Yeah, if you look back um so when I joined Anthropic around a year ago um the platform was basically just the messages API. It was a messages API. Um you know we had come out with standards like MCP. We obviously have developer tooling around our SDKs and our docs and our console and things like this. But for the most part it was a stateless API. Um, and what's interesting to Angela's point on form factors evolving over time is we found a lot of our customers solving the same problems over and over again that we also were solving over and over again around as the models got better at running for longer and working with more contexts at a given time. You want to build agents that can succeed in a kind of long-running context and even a remote context that doesn't necessarily have a human in the loop. And so we found that we could piece together our primitives and stand up all the same infrastructure that we're finding ourselves standing up internally to power our own products and arrive at some higher order abstractions that let you do more agentic work out of the box. And the problems that we're solving for you are, you know, infrastructure being kind of a hard thing to deal with. like how do you figure out spawning sandboxes that are going to have the right governance and security and like you know spin them up and spin them down when you need to or the storage around transcript sessions so that you can resume a session if you stop it and pick it back up later. Um so that infrastructure is a big thing that we wanted to be able to provide more of out of the box and we do more of that today. Um, and then the second thing just being harnesses and harness engineering. There's a lot of thought and energy going into how do I do my prompt caching and how do I manage my context window as well as how do I actually just get more intelligence out of the model um, and how do I manage my costs and things like that. So we've kind of packaged up our primitives a bit more in tune with the problems that we found ourselves solving to provide more of these things out of the box for people so that they can if they're building systems for themselves internally, if they're building products, they can just be more focused on the problems that they want to be solving and if they want to offload some aspects of those problems to us, they can. Um, and that's kind of the ethos.

那么你的客户通常是从你提供的各种功能中选择，还是他们更倾向于选择托管智能体服务？我的意思是，让他们全权处理一切。

And are your customers generally choosing to opt from the grab bag of stuff that you offer or are they like how how often are they opting into the just the the managed agents offering? I guess just take care of it all for me.

嗯，这因用户群体而异。比如，真正 AI 原生的初创公司，那些喜欢在底层摆弄和实验的，他们只会选择原语。而对于其他所有人，比如典型的企业，或者那些初创公司的目的或理念不在于优化某个爬山问题，而是更倾向于串联一系列工作流程，为用户提供独特的价值。对于这些人来说，这并非他们的核心竞争力，也不是他们想要投入时间和资源的地方，所以他们更倾向于选择这些更高级的打包服务。

Um it varies by like the the user group. So like for I would say you know like really AI native startups like the ones who are like tinkering and like experimenting at a really low layer they're just going to go for the primitives. Um and then for everyone else and these are kind of classic like more like enterprises or areas where it's like the purpose of the startup or the philosophy behind the startup isn't necessarily to optimize on um some kind of hill climbing piece. It's more like stringing together a bunch of workflows and you know providing unique user value at uh to that user. For those people um you know it's just kind of not their core competency. It's not where they want to focus their time and resources and they reach much more for these kind of like higher order like package offerings.

过去几个月你们在不同层次发布了哪些原语的例子？我们看到了一些，很想听听。

What are some examples of the primitives you've released at different layers in the last few months? We've seen a few of them. Would love to hear.

嗯。我想给 Caitlin 提到的一些概念提供一个框架，虽然有点过于简化，但实际上大致有三层。最底层是知识。在这一层，很多方面是关于模型的知识，关于模型需要的东西的知识。用 Claude 实际做事情的能力，也许是我会用的说法。所以在这一层，我们花越来越多时间的原语实际上是过去的东西，因为我们仍在进化它们，但它们往往更成熟。比如，我们在 messages API 上设置了非常具体的形状和参数，更像是明确展示 Claude 的设计——模型的实际设计，它的思考方式，它如何尊重某些参数，它如何进行工具调用等等。然后我们开始标准化工具。接着我们开始标准化上下文的不同部分，你可以在不同时间点放入，具体来说就是技能和记忆。这些就是我们过去一年多来推出的知识层抽象。下一层抽象，我们开始投入越来越多时间的是，一旦你知道了东西，你就需要执行。在执行层，这个抽象层次就是 Caitlin 提到的我们正在做的更高级的部分。为什么我们要在那里放更高级的东西？实际上是因为你让 Claude 执行工作，而不仅仅是知道一些东西。我可以问它一个问题，它给我一个答案。你可以把很多东西串起来。但现在如果你需要执行工作，给我输出，编辑不同系统中的文件，这就变得复杂得多，需要基础设施来处理。所以这一层基本上是一个低级 harness 加上管理基础设施，作为一组抽象。今天我们为此推出的高级产品叫做 Cloud Managed Agents。这是一个部分，但我们开始在其中包裹越来越多的东西。我认为在这之上还有一层，我们有一些初步的想法并开始构建，但最上面的抽象层可能是协调层。

Yeah. I think maybe one framing I would give um for some of the constructs that Caitlin was talking about is like and this is a bit of an oversimplification, but effectively there's approximately like three like layers of this cake. At the very bottom is just kind of like like knowledge. And so at this layer like in many ways it's it's knowledge about the model. It's knowledge about the things that the model needs. And it's just like the ability to know how to actually do something with claude is maybe the way I'd phrase that. And so there the primitives that we have spent more and more time on uh have been actually things of the past because like we still evolve them but they tend to be a little bit more baked. Like for example there's very specific shapes and parameters we put on the messages API and it's more like trying to expressly like uh showcase Claude's like design like Claude the model's uh actual design the way it thinks the way it respects certain parameters the way it kind of like um will do tool calls like all of those different pieces. And then we started standardizing like tools. And then we started standardizing bits and pieces of like context that you could put in at different moments in time which is concretely like skills and like memory. And so those are like the kind of like knowledge layer type of abstractions that we've put out over the past um I guess like year plus plus a bit. Um the next layer of abstraction that we've actually started to spend more and more of our time on is like once you kind of know stuff you then need to like execute. And so at the execution layer, that level of abstraction is the part that Caitlin was talking about around like we're doing these like higher order pieces, but like what are we putting higher order there? It really is because you're now getting Claude to execute work. It's not just to know something, right? I can give it a question and give me an answer. You can put string a lot of that stuff together. Uh but now if you need to execute like do work, give me the output, edit files in a bunch of different systems, that becomes a lot more complicated and requires infrastructure to handle. And so that layer is basically I would say a low-level harness plus manage infrastructure as like the set of abstractions. Today we just like our highle product for that is called cloud manage agents. Um and so that's like a piece but we started to wrap more and more pieces in that. Um I think there's going to be a layer like on top of that we have like some inklings of it we started to build towards but the last layer of abstraction on top of this is probably the coordination layer.

所以你有知识、执行和协调。在协调层，我们已经开始以一些不太明显的方式暴露这些，但我们开始把它们视为策略。基本上，这就像一个元框架。真正的底层框架是为执行设计的。但下一层是关于：如果 token 不是完全可互换的，你需要给它们不同的任务——也许有些 token 在建议，有些在执行，有些在构想，有些在执行，等等——你希望组合这些编排好的策略，它们应该位于所有这些之上。归根结底，你仍然需要执行，执行仍然需要知道该做什么。所以理论上，一切应该像梯子一样连接起来。如果你看看我们的路线图并稍微展望一下，你会看到我们从知识层转向执行层，再从执行层转向协调层，就我们发布的抽象层而言。

So you have knowledge, execution, and coordination. At the coordination layer, we've started to expose some of these in ways that aren't very obvious, but we're beginning to think of them as strategies. Basically, it's almost like a meta harness. The true low-level harness is designed for execution. But the next one is about: if tokens aren't really fungible and you need to give them different jobs—maybe some tokens are advising versus executing, some are dreaming versus executing, and so on—you want to compose these orchestrated strategies that sit on top of all these things. At the end of the day, you still need to execute, and the execution still needs to know what to do. So everything in theory should ladder together. If you look at our roadmap and project forward a bit, you'll see us move more from the knowledge layer to the execution layer, and from the execution layer to the coordination layer, in terms of the abstractions we put out.

这真的很酷。你认为这一切如何整合成一个更广泛的生态系统，而不仅仅是你们正在构建的东西？你们如何支持人们在其上构建产品，并帮助他们充分利用所有这些组件？

That's really cool. How do you think this all comes together into a broader ecosystem beyond just the things that you guys are building? How do you help support people building products on top of it and help them get the most out of all these pieces?

是的，这是我们最关心的问题。我们真的想找到一种方法来支持尽可能多的人。我们仍在学习，因为行业已经发生了变化。我们看到很多不同的组件被创建和关闭。对于 Katelyn 和我来说，关键部分是在基础层确保我们尽可能多地提供跨领域的原语。所以，对于知识、执行和协调层，我们希望把这些都提供给每个人，这样人们就可以在其上组合和创造。这是从纯粹构建者的角度出发的。然后还有关于如何与我们对接的角度。我们也在构建自己的第一方产品。我们创建了原生嵌入的方式，比如基于 MCP 规范的连接器。我们试图在这些方面更加开放。我们开始弄清楚正确的组件，但我们真正想做的是达到一个状态，让公司可以在我们之上创建和构建，他们可以构建任何他们想要的产品。如果需要，他们可以构建智能体。这些智能体和产品可以接入其他智能体。其中一些智能体可能是云端智能体，一些可能是其他人的智能体。我们希望实现这种跨领域的可交易性。为了实现这一切，还需要一些标准设定。有传统的标准设定，关于系统如何互操作，你们已经看到我们在构建者层通过技能和 MCP 做到了。在更高层次上，还有关于我们如何共同处理安全问题的互操作性和标准设定。我们与许多公司谈过，撇开哲学不谈，没有人真的希望技术在他们的服务上做负面的事情。网络安全是一个很好的例子：你想保护自己的系统免受恶意行为者的侵害。所以标准设定是关于我们如何与更多人合作，确保关键基础设施良好，防止欺诈，并与每个成员更好地合作。在最后一层，我们仍在进化，并试图找到更好的方式与行业其他部分合作，带动大家。这些是我们希望到位的高阶原语，以便与大家合作最终解决这个问题。如果我退一步看，归根结底，这项技术具有如此大的变革性。它有点像电力：在电力出现之前，你只有蜡烛，只能做有限的事情。但电力之所以具有变革性，是因为你可以把它接入一切。每个人都能使用它。我们有标准和接入方式，来完成所有需要的部分。这不是任何人能独自完成的；他们总是需要与生态系统和合作伙伴合作，找到前进的道路。

Yeah, this is super top of mind for us. We really want to find a way to support as many people as we can. We're still learning, as the industry has evolved. We've seen a lot of different pieces get spun up and spun down. The operative part for Katelyn and me has been to make sure that at the base layer, we provide as many primitives across the board as possible. So, for the knowledge, execution, and coordination layers, we want to give all of that out to everyone so people can compose and create on top of it. That's from a pure builder point of view. Then there's the point of view around how to plug in with us. We're also building first-party products of our own. We've created ways to embed natively with us, like connectors built on top of the MCP spec. We try to be more open about those things. We're starting to figure out the right bits and pieces, but what we're really trying to do is get to a place where a company can be created and built on us, and they can build whatever products they want. They can build agents if they need to. Those agents and products could plug into other agents. Some of those agents could be cloud agents, some could be other people's agents. We want to enable that kind of transactability across the board. For all of that to be true, there is a bit around standard setting. There's traditional standard setting around how systems interoperate, which you've seen us do with skills and MCP at the builder layer. At a higher order layer, there's also interoperability and standard setting around how we all treat safety together. We've talked to a lot of companies, and aside from philosophies, no one really wants technology that does negative things on their service. Cyber is a great example: you want to protect your own systems from bad actors. So standard settings around how we partner with more people to ensure critical infrastructure is good, prevent fraud, and work better with each member. On the last layer, we're still evolving and trying to find ways to be better and work with the rest of the industry to bring people along. Those are the higher-order primitives we wish to be in place so we can work with folks to ultimately solve this. If I take a step back, at the end of the day, this technology is so transformative. It's a bit like electricity: before electricity, you had a candle and could only do so many things. But electricity is transformative because you can wire it into everything. Everyone can access it. We have standards and ways to plug in and do all the pieces we need. That's not something anybody can do by themselves; they always have to work with the ecosystem and partners to figure out a path forward.

你如何看待构建开放生态系统与围墙花园的理念？你认为哪些产品对你来说真正重要，需要自己拥有第一方产品，而在哪些方面你完全乐意接入生态系统的其他组件？

How do you think about the philosophy of building an open ecosystem versus a walled garden? How do you think about what products are really important for you to own first party versus where you're perfectly happy to plug into other components of the ecosystem?

是的，用我们之前讨论过的 Angela 的层叠蛋糕来看，你会发现在某些部分，比如执行，我们在云端托管智能体等产品中做了一些工作，随着时间的推移，你会看到我们试图让这变得更加模块化。我们其实并不执着于让你在我们的基础设施上运行这些；它应该是我们控制的沙盒或存储层。例如，我们推出了自托管沙盒，并与 Modal、Vercel、Cloudflare 以及许多其他公司合作，甚至包括亚马逊的新 microVM，以提供一流的服务，你可以接入其中任何一个。我们推出了 MCP 隧道，这样你可以调用防火墙后面的 MCP 服务器，并穿透过去。

Yeah, using Angela's layered cake that we talked about earlier, you'll see that on some pieces like execution, for example, what we've done within something like cloud managed agents, and over time you'll see us try to make this more modular. We actually aren't precious about you running these things on our infrastructure; it should be sandboxes we control or a storage layer we control. For example, we launched self-hosted sandboxes and partnered with Modal, Vercel, Cloudflare, and a bunch of other folks, even Amazon's new microVMs, to have a first-class offering where you can plug any of those things in. We launched MCP tunnels so you can call out to your MCP servers behind your firewall and punch through there.

因此，对于某些事情，它运行在我们的基础设施上还是别人的基础设施上，对我们来说其实并不重要。重要的是你如何将这些智能体组合起来，使其强大、可靠且可扩展的架构。我们对此有坚定的看法，你只需遵循我们提供的接口，接入即可。我们认为这通常效果很好。

And so for some of these things, whether it runs on our infrastructure versus somebody else's infrastructure is actually not important to us. What's important is the architecture of how you put together these agents in a way that will be powerful, reliable, and scalable. We have strong opinions on that, and you can just conform to the interfaces we put out there and plug those things in. We think that generally works really well.

是的，关于我们可能构建产品的垂直领域，我们有两个框架。第一个是我们始终在寻找一种不断演进的产品形态。我们不认为产品形态是静态的，它是动态的。某一年对 AI 开发来说很棒的东西，下一年可能就不那么棒了。我们告诉 Anthropic 的团队要始终问自己：“这够 AGI 吗？” 我们有一种心态：我们构建了某样东西，它有效，流行了一年，但可能不是下一个正确的东西，那就扔掉再试一次。我们也对平台用户这么说。我认为这和技术本身是紧密相连的。所以一个原则就是不断寻找新的产品形态。有时我们在某些领域推出产品，是为了展示一种新的产品形态。这不一定是因为我们认为这是最大的锤子或最重要的事情，而是有时你会想：“这一直是一件非常困难的事情，人们一直以这种方式沟通。我们能不能展示一种稍微不同的方式？” 而且由于模型能力现在如此先进，我们能否以不同的方式表达它？

Yeah, I think on the verticals where we might build products, we have two frames. The first is we are always trying to figure out an evolving form factor. We don't think form factors are static; it's dynamic. What might be awesome for one year's worth of AI development will probably not be awesome for the next. We tell the team at Anthropic to always ask, 'Is this AGI enough?' And we have this mentality: we built something, it worked, it was cool for a year, and maybe it's not the right next thing, so throw it away and try again. We tell platform users the same thing. I think that's attached to the technology. So one principle is constantly finding this new form factor. Sometimes we launch products in certain areas to showcase a new type of form factor. It's not necessarily because we think it's the biggest hammer or the most important thing, but sometimes you think, 'This has always been a really difficult thing, and people have always communicated this way. Can we show a slightly different way?' And because model capabilities are so advanced now, can we express it differently?

能举个例子吗？

What's an example of that?

是的，比如 Claude Design 就有点像这样。看你从哪个角度看，你可能会认为这是我们进入设计这个垂直领域的一种方式。但更常见的是，如果你看看我们试图用那个产品做什么，有几个决策。首先，你可以将越来越多的工作卸载给 Claude。它试图变得有主见：直接和它对话，让它真正去弄清楚。是的，你仍然可以编辑和做那些事情，但它会稍微不鼓励那样做，而是鼓励直接和 Claude 对话来解决问题。其次，它试图表达代码是一种解决你通常不会想到的问题的方式。很多构建生成式幻灯片或设计的人会选择一种设计系统来集成——传统的所见即所得风格。对于 Claude Design，我们想：“我们能不能纯粹使用代码，让 Claude 生成代码，它能做好吗？” 我们通过早期实验发现，它似乎能做到，我们想向世界展示这一点。这就是一个例子。我们还有很多其他内部项目属于这种表达产品形态的类别。我们在内部试用，它们非常酷，持续两周，然后我们就继续前进。坦率地说，我们甚至从未发布过这些东西。我们实际上在那个领域做了很多产品实验，那是我们的实验室团队。

Yeah, like Claude Design is a bit like that. Depending on how you squint, you might see it as a way we go into design as one of the verticals. But more often, if you look at what we're trying to do with that product, there are a couple of decisions. First, you can actually offload more and more to Claude. It tries to be opinionated: just talk to it and let it really try to figure things out. Yes, you can still edit and do those things, but it discourages that a little and encourages just talking to Claude to figure it out. Second, it was really trying to express that code is a way to solve for things you wouldn't normally think would be the way. A lot of people who built generative slide decks or designs pick a design system to integrate against—the traditional WYSIWYG style. With Claude Design, we thought, 'Can we try to just use code purely, have Claude generate that code, and would it do a good job?' We found through early experiments that it looks like it can do that, and we wanted to showcase that to the world. So that's an example. We have a lot of other internal projects in this category of expressing form factor. We try them internally, they're super cool for two weeks, and then we move on. We never even ship the thing frankly. We actually do a lot of product experimentation in that area, and that's our labs team.

然后是第二个类别：我们确实会看 TAM（总可寻址市场）。我们是一家企业。我们会看 TAM。我们会看那些我们认为会有合理智能体式操作的领域。我们倾向于更偏向于那些 token 密集型的领域。所谓 token 密集型或 token 饥渴，我的意思是：当你完成一轮交互时，在那一轮结束时你会问：“我完成了吗，还是我太高兴了以至于想继续做更多？” 我们喜欢答案是“我想做更多”的行业。编程显然是我们都知道的一个。编程的好处在于，一旦你完成一轮，你看着它就会想：“太棒了，我解锁了，我要构建更多，我能做更多。” 还有其他服务，当你完成那一轮时，你就完成了工作，然后继续前进。所以我们倾向于进入那些具有迭代流程的领域，在那里你可以一起构建更多、生成更多。最后一个角度是，某些业务职能是我们喜欢接触的买家。我们想帮助他们优化工作流程，创造更好的产品。我们在一些垂直领域已经相当透明，比如金融和法律。我们试图缩小到特定领域，在这些领域拥有正确的上下文、工具和产品形态对我们来说是有用的。

Then there's the second category: we actually look at TAM. We're a business. We look at TAM. We look at areas where we think there will be reasonable agentic operations. We tend to have an orientation towards things that are more token-heavy. By token-heavy or token-hungry, I mean: when you spend one turn, at the end of that turn you ask, 'Am I done, or am I so glad I did that thing that I want to do more?' We like industries where the answer is 'I want to do more.' Coding is obviously the one we all know. The great thing about coding is that once you finish a turn, you look at it and think, 'That was incredible, I'm unlocked, I'm going to build more, I can do more.' There are other services where when you finish that turn, you completed the job and just move on. So we tend to go into ones with an iterative flow where you build more, generate more together. The last angle is that there are certain business functions where they are the buyer we like to go to. We want to help them optimize workflows and create better products. We've been pretty transparent with some verticalization, like finance and legal. We've tried to narrow into specific areas where having the right context, tools, and form factor is useful for us to be able to do.

在每个领域，我们都试图展示实现这些成果的所有不同方式的可能性艺术。以金融为例，你可以是一家解决金融问题的公司，直接基于 Messages API 构建，只需获取一些 token，然后在上面构建其他一切。或者你可以基于 Claude 管理的智能体构建，获得更多开箱即用的功能。或者你可以构建一个插件或连接器，放在我们的产品及其产品形态中。当我们最近推出 Claude for Financial Services 时，就像是：“好的，我们有一系列技能包之类的东西，你可以选择在我们的产品中、在其他人的产品中使用。”

And in each of those areas, we try to show the art of the possible across all the different ways you would accomplish those outcomes. For finance, for example, you could be a company that solves problems in finance and build directly on the Messages API, just get some tokens and build everything else on top. Or you could build on Claude-managed agents and get a lot more out of the box. Or you could build a plugin or connector that sits within one of our products and those form factors. When we recently launched Claude for Financial Services, it was like, 'Okay, we've got packages of skills and things like this that you can choose to use within our product, within other people's products.'

我们甚至发布了类似 cookbook 的东西，介绍如何使用云托管智能体来完成这些任务。所以，对我们来说，这更像是一种实验——我们提供所有这些不同的组件，看看人们会怎么用。然后有时我们会把所有这些打包成产品，比如 Claude Tag 就是一个很好的例子。我们看到行业里有人在做类似的事情，比如 Shopify 用 River 做了这个，Square Block 最近用 Builderbot 做了这个。有几个这样的例子，人们说：“我要在公司内部构建一个智能体式平台，给它所有正确的上下文，并让它可以从 Slack 或其他你希望它能访问的平台使用。”我认为 Claude Tag 很大程度上就是这些相同东西的打包，任何人都可以选择构建类似的东西，但这就是我们内部的做法，如果你只是想即插即用，这就是它的样子。

We even launch like cookbooks on here's how you would use cloud managed agents to go and do these things. And so, I think for us, it's all kind of an experimentation around like, you know, we provide people all these different pieces and see kind of where they run with it. And then sometimes we put together products that are just packaging of all of these things like Claude Tag I think is a really good example like we had been seeing people in the industry go and say like Shopify did this with River, Square Block recently did this with Builderbot. There's like a few of these examples where people said, "I'm going to build like an agentic platform internal to my company and I'm going to try to give it all the right context and I'm going to make it accessible from Slack or from various other platforms that you'd want it to be accessible at." And I think Claude Tag was very much a packaging of all those same things that anybody could choose to build something similar but this is how we're kind of like well this is how we're doing it internally and if you would like to just kind of plug in and go here's what that looks like.

你认为人们对 Claude Tag 有什么误解？因为当时有很多争议，比如“天哪，它只是个 Slack 机器人”，告诉我们 Tag 的魔力到底是什么。

What do you think people misunderstood about Claude Tag? Because there was all this like ruckus about oh my gosh it's just a Slackbot like tell us what the magic of Tag is.

不，我认为这是个好问题。我确实认为它展示了未来可能的发展方向。我认为如果你看过去的产品，人们会说：“哦，你真的很在意形式或 UI，对吧？它看起来像这样。”所以，这很酷。但当你看到 Tag 时，你与它互动的方式就是你在 Slack 中 @ 它。所以，是的，那是界面，但那不是真正重要的部分。重要的部分是我们放在引擎盖下的所有上下文工程和架构。这样 Tag 就能正常工作。它真的应该感觉像一个同事。如果你加入一家公司，一个同事进入你的频道，然后你可以和它聊天。它是主动的。它找出什么对你有用，然后帮你把事情搞定。所以，如果你想想，尤其是非技术用户，这是一个巨大的解锁。你只需创建一个频道，然后 @ 它，有时甚至不用 @，你就说“嘿，我想做这个做那个，我搞不懂这个，我该怎么提交费用报告？”传统上，你要解决这个工作流，你得四处找人，和你的经理谈，和你的搭档谈，非常复杂。而今天，你只需去和 Claude Tag 说，我们做了很多艰苦的工作，包括上下文工程、主动性和许多 harness 组件。我认为 Andrej Karpathy 说得很好：它就像一个组织级别的 harness。其中包含了很多复杂性。就像 Katelyn 提到的，你可以使用我们的 API 来构建它。你显然需要自己做很多实验，但这是 Anthropic 的一个有主见的做法，告诉你如何为整个公司拥有一个非常棒的、始终在线的智能体。我觉得未来的一点是，很多复杂性实际上就像一座冰山。下面所有的东西实际上变得越来越难、越来越有用，我们正试图推动它。我认为我们会看到越来越多的冰山尖露出水面。界面实际上可以不断切换。今天，Slack 是很多人协作的地方，很多企业协作，但也有很多人用 Teams 协作，有些人用 WhatsApp 群组，或者发短信，有些人还在用电子邮件，这些都可以成为形式因素。你可以想象智能体直接去那里，它们几乎占据了人类使用的相同形式因素。这听起来可能很无聊，但我认为这是最前沿的，因为你希望智能体和 AI 基本上像另一个人一样帮助你，但它非常智能，能弄清楚所有上下文，你总能拥有一个非常有用的助手。

No I think it's a great question. I do think it actually showcases a little bit of where maybe the future could be going. I think if you look at products in the past, people are like, "Oh, you really attach to like the form or the UI almost, right? It looks like this." So, it's like super cool. And I think when you look at Tag, like the way you interact with it is that you literally tag it in Slack. And so yeah, that is like the interface, but that's not really the important part. The important part is all the kind of like context engineering and architecture that we put underneath the hood. So that Tag just works. It really should just feel like a co-worker. If you go to a company and you onboard and a co-worker comes into your channel and then you can chat with it. It's proactive. It figured out what's useful for you and it just gets stuff done for you. And so if you think about, especially like nontechnical audiences, this is like a huge unlock. You just literally create a channel and then you atclude or sometimes you don't even atclude and you're like "hey I want to be able to do this and do that and I can't figure out this and how do I actually like submit an expense report again" and traditionally you think about how to solve that workflow you are going all over the place and you're talking to your manager you're talking to your spin buddy and it's really really complicated and today now you just go talk to Claude Tag and we do a lot of the hard work on doing the context engineering the proactivity a lot of the harness pieces. I think Andrej Karpathy said it really well: it's like an org level harness. There's a lot of complexity baked into that. Like Katelyn mentioned, you can use our APIs to go and construct that. You have to do a lot of the experimentation yourself obviously but this is an opinionated take from Anthropic on how you can have this really awesome always-on kind of agent for your entire company. And the bit that's like futuristic I guess is that a lot of that complexity is actually like an iceberg. All the stuff underneath it is actually becoming the harder and harder and useful part that we're trying to push through. And I think we'll see more and more that kind of tip bit that's outside in the water. It's just like the interface can actually constantly swap. Today, Slack is a place where a lot of people collaborate, a lot of business collaborate, but also a lot of people collaborate in Teams and some people collaborate by a WhatsApp group or they text each other or some people still email each other and those could be the form factors that actually you can imagine agents just going there and they're almost taking up the same form factors as humans have taken up. It was almost like a very boring take, but it's actually I feel like the most forward one because you want the agent and you want AI to basically be like another person and it's helping you, but it's very intelligent can figure out all the context and you can always have it to be a really helpful assistant.

完全同意。你谈了很多关于上下文和 harness 的内容，所以你的团队对于构建一个出色的智能体需要什么有着非常明确的观点。我想这很大程度上归结于上下文工程和 harness。

Totally. You talked about context and then harnesses quite a bit and so your team is just, you know, has such an opinionated point of view on like what it takes to build an exceptional agent. I imagine a lot of that comes down to the context engineering and the harnesses.

完全同意。

Totally.

也许你可以分享一些最佳实践或建议，关于在 harness 和上下文方面需要做对什么。

Maybe like what best practices or advice would you share with people about what you need to get right on the harness and what you need to get right on the context.

是的，我想是的。这很有趣，因为我们讨论过，我们推出了云托管智能体，作为一个非常通用但高性能的 harness，因为我们做了所有琐碎的工作，这些工作实际上很无聊，也不那么有趣，比如如何处理提示缓存？如何处理上下文管理？清除窗口中的旧内容。有时你以编程方式调用工具，这样就不会把所有内容都拉进上下文窗口，从而保持干净。在较低层的 harness 层有很多这样的细节。我认为诚实地说，最佳实践就是像提示缓存这样的东西。去做吧。你会节省很多钱和 token 成本。显然，尽量保持上下文窗口干净，然后将这些内容组合成一个高性能的 harness，有时这取决于你要完成的任务，对吧？然后当然还有评估。我很惊讶我们聊了这么久才有人提到“评估”这个词，但你需要评估来确保你要完成的任务是高性能的。但我认为我们开始走向的方向，Angela 之前也提到过一点，是策略或元 harness 的概念。因为我确实认为，是的，你可以再次让这个较低层的 harness 变得高性能，也许你自己做很有趣，或者也许不，你把它外包给我们。

Yeah, I think so. It's interesting because we've kind of talked about, you know, we launched cloud managed agents as this very generic but high performing harness because we've done all the nitty-gritty work that's actually like really boring and not super interesting around how do you deal with prompt caching? How do you deal with context management? You clear old stuff out of the window. Sometimes you call tools programmatically so you don't pull everything into the context window and you can keep it clean. There's a lot of those sort of details on the lower level harness layer. And I think honestly like best practices are just stuff like prompt caching. Do it. You're going to save a lot of money and token costs. Obviously, like try to keep your context window clear and then putting those things together in a harness that will be performant is sometimes specific to the task that you're trying to accomplish, right? And then of course evals. I'm surprised we got this far into this thing before one of us said the word evals, but like you need evals to make sure that what you're trying to accomplish is performant. But I think where we're starting to go, and Angela mentioned this a little bit earlier, is more of a concept of strategies or meta-harnesses because I do think that yes, you can again make this lower level harness is going to be performant and maybe that's interesting for you to do yourself or maybe not and you offload it to us.

但关键在于，你可以把任何一个 token 用于执行，或者用同一个 token 来反思过去的智能体会话，把学到的经验写入记忆，让下一个智能体做得更好；你也可以用这个 token 向更大的模型咨询，让较小的模型执行并做得更好。或者你可以说“执行、执行”，然后一个评分器过来问：“你做得好吗？不，你没做好，再试一次。”对吧？所以我认为有趣的创新将更多出现在更高层面，也就是元层面。我们团队对在这些策略中进行优化感到非常兴奋，并且已经开始在这方面做大量工作。我认为很多其他人也开始对这个策略概念以及你赋予 token 的任务感到兴奋，因为确实，在提示缓存、如何清理上下文窗口、如何编写评估等方面都有最佳实践，但我不认为在很多情况下，从那个层面能榨出多少油水，相比更高一层而言。

But this concept that you can take any given token and spend that token on just executing, or you could take that same token and choose to actually reflect on your past agentic sessions and write learnings to memory so that the next agent does a good job, or you could take that token and advise with a bigger model so that a smaller model can execute and do a better job. Or you can say execute, execute, and then a grader comes in and says, 'Did you do a good job? No, you didn't. Try again.' Right? And so I think the interesting innovation is going to come more at that higher level, on the meta level. And I think optimizing within those strategies is something that our team is really excited about, and we're starting to do a lot of work there. And I think a lot of other people are starting to feel really excited about this concept of strategies and the jobs you give to tokens, because again, yes, there are best practices on stuff like prompt caching and exactly how you clear stuff out of your context window and how you write your evals and a lot of things like this, but I don't know that there's necessarily so much juice to squeeze in a lot of cases out of that layer as compared to a layer higher than that.

是的。我认为其中一个原因与模型的代际有关。如果你看两年前，很多 harness 就像脚手架，告诉模型从 A 点到 B 点。你必须构建很多东西，你几乎在这里建一堵墙，在那里建一堵墙，这样模型才能直线前进。而现在模型实际上非常、非常可引导。所以很多引导你只需放在提示里，对吧？比如“从 A 点到 B 点”，模型就会从 A 点到 B 点。所以很多设计来做这种引导的 harness，你可以删除那部分。我们实际上经常鼓励删除那些 harness 的部分。我想很多人都说过类似的话。这就是人们常说的模型会消耗一些脚手架的意思。从这个意义上说，当然，如果你的脚手架告诉它去一个它能智能地找到的方向，这种情况会越来越普遍。但结果是，harness 需要开始做的是让它运行更长时间。所以这就是执行部分所在。我觉得这听起来可能有点傻，但我确实认为它会导致很多差异，因为你可以让它朝你告诉它的方向走。你显然不希望它停在 B 点。你会说，“好了，现在从 B 点到 C 点，然后到 F 点，然后到 Z 点，然后回到 A 点。”你知道，类似这样奇怪的事情。为了能够做这些事情，你使用的 harness 不再是引导型 harness，而是更像 Katelyn 提到的这种策略型 harness，它允许你在稍高的思维层面操作，这与我们试图从模型中获得的大量智能提升相匹配。

Yeah. And one of the reasons for that, I think, has to do with the generations of the models. If you look two years ago, a lot of the harness was like a scaffold to kind of tell the model to go from point A to point B. And you had to build in a lot. You practically built one wall here and one wall here so the thing would go in a straight line. And now the models are actually very, very steerable. So a lot of that steering you could just put in the prompt, right? Like 'Go from point A to point B' and the model will go from point A to point B. So a lot of harnesses that are designed to do that kind of steering, you can delete that part. We actually frequently encourage that you can delete part of those harnesses. I think various people have said things along those lines. And that's what people often mean when they say the model will consume some of the scaffolding. In that sense, for sure, if your scaffolding is telling it to go in a direction that it can just intelligently figure out, that will increasingly continue to be so. But as a result, what the harness needs to start doing is more allow it to run longer. And so that's where that execution bit tends to be. I think it sounds like a maybe somewhat silly point, but I do think it results in a lot of differences because you can go in the direction that you tell it to go. You obviously don't want it to stop at B. You're going to be like, 'Okay, now go from B to C and then go to F and then go to Z and then come back to me on A.' You know, something funky like that. In order to be able to do a lot of those things, the kinds of harnesses that you do are less the steering harness and more these kind of strategy harnesses that Katelyn's mentioning, which allows you to operate at a slightly higher level of thinking, which matches a lot of the intelligence gains that we're trying to see with the model.

你认为任务特定的 harness 有意义吗？还是垂直领域特定或任务特定的 harness？

Do you think task-specific harnesses make sense, or a vertical-specific or task-specific harnesses?

我认为人们对此有不同的看法。我们的观点是肯定的。我不认为存在一个通用的 harness。我认为有些能力显然非常通用，而且非常有用。比如编码是一种非常有用的能力，因为你可以在很多事情上使用它，软件已经吞噬了太多可能的事情。所以我们编写软件的能力因此很有用。我认为当你考虑非常具体的领域时，它们需要 harness 的某些部分进行定制。其中之一，我确实认为，是你如何处理在执行某些操作和将任务交给模型之间的错误。在需要极端验证水平的领域，处理验证的逻辑——再次强调，这听起来很小，但我完全理解为什么有些人觉得他们真的想拥有 harness，因为调整最后那一点会带来巨大的收益，尤其是在法律和金融等领域，如果不能完全正确，后果很严重。这真的很重要，这将是你的产品和其他人的产品之间用户最终使用哪个的区别。然后还有其他领域，我认为这没那么重要，因为你可以将其压缩成通用模型能力。所以，我们认为领域特异性真正重要的调整是模型和执行之间的特定验证逻辑。然后我认为还涉及一些更高层次的策略，关于你如何实际分配 token 预算。我认为上下文部分实际上有点被过度强调了。是的，你会放入上下文，但任何 harness 实际上都能处理大量上下文，所以这更像是你拥有数据，如果你有数据，那么显然你就有独特的资格去做一些有用的事情。

I think people have different opinions on this. Our opinion is yes. I don't think there's like a general harness. I think there are some capabilities that are obviously very general and they tend to be very useful. Like coding is a capability that is very useful because you can use it across so many things, and software has eaten so much of what is capable. So our ability to write software is therefore useful. I think when you think about very, very specific types of domains, they're going to require a couple of pieces of the harness to be sort of customized. One of those, I do think, is how you choose to handle errors between when you do something and you hand something off to the model. So in domains where you require an extreme level of verification, that logic of how you handle that verification—again, I think it sounds small, but I totally understand why some people feel like they really want to own the harness because tweaking that last bit will give you a ton of juice, especially in domains like legal and finance where there are a lot of consequences to not getting it perfectly correct. That's really going to matter, and that's going to be the difference between your product and someone else's product being the thing that the user ultimately uses. And then there are other domains for which I would say it's not going to matter as much because you're able to compress it into a general model capability. So the tweaks that we feel like the domain specificity is really going to matter are the specific verification logic between the model and your execution. And then I think it's going to be about some of these kind of higher-order strategies on how well you're able to actually allocate your token budget. I think the context bit is actually a little overdone. Like yes, you're going to throw in context, but any harness can actually handle a lot of context, so that's just more like you have the data, and if you have the data, then obviously you're uniquely qualified to do something useful.

是的。我认为当人们说 harness 时，他们通常指的是很多不同的东西，我认为这也是为什么对此有这么多不同意见的部分原因。比如，你可以把 harness 仅仅看作一个循环，比如“好的，用户模型，用户模型，工具”，你知道，诸如此类。然后你也可以把 harness 看作所有与 harness 打包在一起的工具，对吧？这些东西有很多不同的定义。我认为那些相当通用、拥有和处理起来不那么有趣的东西，就是我之前说的：把提示缓存弄对——也许这不是世界上最有趣的事情。选择从上下文窗口中清除旧的工具调用之类的事情——也许有点不那么有趣。然后你往上一层，进入 Angela 谈到的一些东西，然后你就会说，“好吧，是的，这些是我可能想要拥有和控制的东西。”

Yeah. And I think when people say harnesses, they often mean a lot of different things, and I think this is why in part there are so many different opinions on this. Like you can think of a harness as literally just a loop that's like 'okay cool, user model, user model, tool,' you know, that sort of thing. Then you could think of the harness as also all of the tools that are packaged up with the harness, right? And there's just a lot of different definitions of these things. And I think the stuff that can be pretty generic and less interesting to own and deal with is what I was kind of saying earlier: getting your prompt caching right—maybe that is not the world's most interesting thing. Choosing to clear out old tool calls from the context window and things like that—maybe a little bit less interesting. And you go a layer higher into some of the stuff Angela's talking about, and then you get into 'okay, yeah, these are things that I might want to own and control.'

所以，关于云管理智能体，我们今天构建的东西很有意思，我们称之为高阶，但它其实并没有那么高阶，因为你可以选择用 harness 把你想要的所有工具都作为自定义工具引入，对吧？我们给了你很多控制旋钮，你可以定义技能，设置系统提示，做很多不同的事情，比如 MCP 服务器等等。我认为我们想要达到的目标是，你可以直接告诉智能体：这是我想要的结果，这是我想花费的预算，准备就绪，开始执行，你甚至不需要考虑底层的那些东西。所以我认为这有几个不同的层次，对吧？对于某些事情，你可能想停留在不同的控制层次上。嗯，在某些层次上，通过多做一点优化工作，你可能会得到更好的结果。

And so it's interesting with cloud manage agents like the thing that we built today, we call it higher order, but it's not really like that high order in the sense that you can choose to define all of the tools that you want to bring in as custom tools with the harness, right? And like we give you a lot of knobs to control, you can define skills, you can do your system prompts, you can do a whole bunch of different things, MCP servers and things like this. And I think where you know we want to get to is a point where you can literally just tell an agent here's the outcome I want and here's the budget that I want to spend like ready set go and you may be like don't think about any of those things underneath. And so I think there's just a few different layers of this right that for certain things like you might want to sit at a different layer of what you actually go and control. Um and you can probably get better outcomes within some of those layers by doing a little bit more optimization work.

非常酷。我好奇的一件事，也是我喜欢基础设施和平台团队的一点是，你能看到世界上最先进的用户在使用什么，并向他们学习。我很好奇，你在你的平台上看到并学到了哪些东西？

Very cool. One of the things I'm curious about and one that I love about infrastructure and platform teams is that you get to see what the most advanced users in the world are using and learn from them. I'm curious what are some things that you're seeing and learning from from the people building on your platform.

有些人一直在用一些非常奇特的方式来处理上下文。嗯，我们自己在这方面也探索了很多。这实际上是 TAG 成为如此优秀产品的原因之一，因为有很多非常棒的上下文工程正在发生。嗯，我们看到一些团队在处理上下文方面非常聪明，他们能够思考：如果我在很多不同的地方有这些联系人，我如何主动联系他们？我如何为每个联系人生成足够的权限？然后把这些都输入到一个智能体中。有趣的是，嗯，我想这就是我们真正感到兴奋的那种创新水平。它并没有表现为一个完全不同的产品形态。嗯，但它实际上表现为对用户的最大化有用，我们越来越多地看到这一点，尤其是在内部用例中，而不是外部用例。所以，那些变得更 AI 原生的公司，基本上是我们看到越来越多创新的来源。比如，我们有客户尝试用非常创新的方式构建他们自己的自定义 SDLC 设置。我们有客户为整个后台做这件事，他们如何流式传输上下文的细微差别，实际上非常有趣，因为他们把各个部分组合在一起。所以这是一个非常迷人的类别。另一个非常有趣的类别是那些处理非常老式软件的公司。有很多医疗保健公司，我们与他们接触，他们说：我正在使用的系统甚至没有 API。那简直是梦想。嗯，所以他们如何使用计算机使用等功能来开始自动化并创建与系统的更多连接。嗯，我认为那个创新领域非常令人兴奋。看到人们尝试各种疯狂的事情，比如用笔记本电脑运行一堆东西来自动生成一堆东西，然后他们的智能体可以使用这些，这真的很有趣。嗯，这实际上可能是一个领域，我认为很多创新来自我们的客户，我们希望找到更好的方式来支持他们，看看如何让事情变得更容易，如何帮助他们实现一些标准化，如何让你只需要一个规范，然后 Claude 就能遵守它，这样你就能更容易地有机连接很多这些东西。但总的来说，我想给你的主题是，有趣的是，目前最令人兴奋的很多创新都集中在上下文和连接层，这真的很迷人。

There's some people that have been doing some really funky ways of like handling context. Um we ourselves explore this a lot. That's actually like one of the reasons why TAG is like uh such a great product is like there's a lot of really awesome like context kind of engineering that that's happening. Um, we've seen some teams be really clever about like how they do that and they are able to kind of think through like, okay, if I have all these contacts in a bunch of different places, how can I proactively go reach out to them? How can I try to generate enough like um permissions across each of them? So, and then feed that all into like an agent. And it's interesting that like um I guess like this is kind of the level of innovation that like we're actually like very excited by. It doesn't express itself as like a completely different product form factor. Um, but what it actually does express itself as is like maximally useful to users and we've been seeing this more and more with like inter actually like internal use cases instead of like external ones. So like companies who are becoming more AI native basically they're the ones we're seeing increasingly more and more innovation out of and so you know we've had like customers try to do this for their like they've built their own like custom SDLC kind of setup in very very innovative ways. We've had uh ones who do that for like their entire back office and just like the kind of nuances of how they like stream in context I think has been like actually really interesting in terms of like how they've been putting together the pieces. So that's been like one category that's been like really really like fascinating. Uh another category that's been like really interesting has actually been with companies that are dealing with like really old school software. And so there's a lot of like healthcare companies um that we kind of engage with and you know like they're like the the systems I'm working with they don't even have APIs. like that's that's a a dream. Um and so you know how can they use computer use uh and things like this to be able to start to kind of automate and create more connectivity with our systems. Um and that area of innovation I think has been really exciting. It's been really interesting to see people try all sorts of crazy stuff from like taking a laptop and trying to like run a bunch of things on it to autogenerate a bunch of things that then their agents can go and use. Um, and this has actually been probably like an area of um, I think a lot of innovation coming from a lot of our customers that we want to find ways to like support better and see like okay maybe there are like how can we make this easier for you? How can we help you with some standardization? How can we get it so that you know like you can just have a spec and then claude can then respect it and so it's much easier for you to organically connect a lot of these things. But yeah, maybe the the general theme I would just give you is like interestingly a lot of the innovation that's most exciting out there right now has been uh this kind of like context and connectivity layer which has been really fascinating.

是的。比如一个很好的例子，我们和一个客户合作，他们在云管理智能体上构建了一些智能体。他们也在其他模型和平台上构建了一些智能体，并且他们优化了每个智能体，使其擅长他们想要的事情。他们希望所有这些智能体能够很好地协同工作。嗯，他们想：“哇，天才想法。如果我在这个智能体上暴露一个 MCP 服务器，这样另一个智能体就可以调用那个智能体上的工具，对吧？让这些东西更加模块化，能够协同工作。”我们说：“是的，完全正确。”我们和他们坐下来一起解决，结果完美运行，非常酷。所以我们再次看到了很多连接层，我认为这是人们创新的一个很酷的领域。但除此之外，一件很酷的事情是看到行业趋势的转变，我们看到很多使用来自编码领域，编码作为一个类别当然爆炸式增长。那里有很多事情发生，我们最近开始看到一些新兴趋势。嗯，我们开始看到制造业作为一个类别真正兴起，人们在那里用 AI 构建，比如我们的一个产品经理飞往底特律去了解这些客户的需求和情况。所以我认为我们会开始看到更多超出人们今天想象的用例，我们对此非常兴奋。

Yeah. Like a good one in that um we were working with a customer who they've built some agents on cloud manage agents. They also have some agents they built on other models and other platforms and they've kind of optimized each of these agents to be good at the things that they want. They want these agents to all be able to work well together. Um, and they kind of were like, "Wow, Galaxy brain. Like, what if I expose an MCP server on top of this agent so that it can then go and like have this other agent call a tool on that agent, right? And and have these things just be more modular and be able to work together." And we were like, "Yeah, totally." And we sat down with them and worked through it and and it worked perfectly and it was pretty cool. And so, we're seeing a lot of again that connectivity layer that I think is one of the cooler areas where people are innovating. But outside of that, one thing that has been cool is just seeing the shift in I guess like industry trends of where we're seeing a lot of our usage come from like talked a lot about coding like coding as a category like of course absolutely explode in. There's so much going on there and we're starting to see some of these emerging trends like more recently. Um, we're starting to see manufacturing really pick up as just a category where people are building with AI and like one of our PMs like getting on a flight to Detroit to go like figure out what these customers like what they need and what's going on. And so I think we're going to start to see a lot more just kind of like outside of the box of what people think about today sort of use cases which we're really excited about.

似乎我们经历了一个 token 最大化的历史时刻，现在又到了 token 合理化的历史时刻。你对此有什么看法？公司应该怎么做？平台团队如何考虑支持这一点？

It seems like there's now there's a we went through a token maxing moment of history and now there's like the token rationalization moments of history. What are your thoughts on that and like what what should companies be doing and then how how does the platform team think about uh enabling that?

是的，我的意思是，这很有道理。嗯，从高层次来看，你开始合理化。我真的很喜欢这个框架，我认为在这方面我们有几个优先考虑的事情。

Yeah, I mean it it makes sense. Uh it it makes sense from the high you start to rationalize. I I really like that framing and I think there's like a couple things that that are like top of mind for us on this front.

我认为这说得通。随着这些模型越来越强大，你会达到智能最大化的水平。然后你想进入下一个维度，智能之后的下一个维度要么是成本，要么是速度。你只需在所有可能的任务复杂度分布中经历这个过程。当我们看到这种情况发生时，我们非常关注的一点是，我们试图与用户探讨的是，你不应该做的是停止使用 AI。那是个错误的举动。我们确实看到一些客户这样做。通常，AI 支出在公司内部爆发的方式是通过影子 IT。员工想用，他们找到办法，最终自己采购，不知不觉中，你一半的组织都找到了安装 Claude Code 的方法。在这种情况下，很难管理，因为这些模型非常消耗 Token。所以我们试图鼓励客户：你不想停止创新。如果你获得了回报，比以往更快地交付产品，运营效率更高，这些都是收益。我们鼓励人们构建一个策略，让你设计一个架构，根据任务评估其复杂度。我实际上是在描述一个路由器，但现在有更好的方法。这个任务进来，有一定复杂度。对于那个复杂度，你可以定义一些规则，但大多数情况下，如果是一个困难任务，你应该路由到一个大型超级智能模型。如果不是困难任务，你可以路由到更便宜的模型。设计这个有技术复杂度，但非常可行。我们鼓励人们尝试这些事情。

I think again it makes sense. As these models get more and more capable, you're going to hit levels of intelligence max-maxing. Then you want to do the next dimension, and the next dimension after intelligence will either be cost or speed. You just go through that across all possible task complexities in the distribution. As we see that happen, something top of mind for us that we try to spend time with users on is what you don't want to do is stop AI usage. That's the wrong move. We do see some of our customers do that. Often the way AI spend has erupted inside their company has been through shadow IT. Employees want to use it, they find a way, they end up procuring it themselves, and before you know it, half your org has found some way to have installed Claude Code. In that world, it's hard to manage because these things are very token hungry. So we try to encourage our customers: you don't want to stop the innovation. If you are getting returns, shipping faster than ever, running more operationally efficient, those are gains. The area we encourage people is to construct a strategy that allows you to design an architecture that says, given a task, assess its level of complexity. I'm effectively describing a router, but there are ways to do this better now. This task comes in with a certain level of complexity. For that level, you can define some rules, but for the most part, if it's a hard task, you should route it to a big super smart model. If it's not hard, you can route it to cheaper models. Designing that has technical complexity, but it's very doable. We encourage people to try those things.

有道理。

Makes sense.

我认为在 Claude 的领域内，这是有意义的。这是我们设想设计的策略之一，因为我们思考这些事情的方式是，几乎每个月都会有一个新时代。退一步看，这似乎非常快。那么有哪些不同的方式是可重新组合的，以便我们可以快速重新设计，应对当月任何新的酷东西？这属于我们可以重新组合许多原语然后进行设计的类别。我们对模型路由有强烈的信念：我们正在为 Claude 设计平台，我们希望确保 Claude 擅长解决所有这些问题。所以我们会限制在那个领域，而不是路由到不同的模型。

I think within the Claude space it will make sense. It's one of the strategies we imagine designing because the way we think about these things is it almost feels like every month there is a new era of something. If we take a step back, this seems really fast. So what are the different ways that are recomposable so we can redesign very quickly for any new cool thing that month? This is in that category where we feel we can recompose a lot of our primitives and then design it. We feel strongly about model routing: we are designing our platform for Claude, and we want to make sure Claude is great at solving all these things. So we'll restrict to that space rather than routing to a different model.

有道理。

Makes sense.

是的。其中一部分也是因为我们坚信，工具链和智能体层应该与你使用的模型家族相匹配。曾经有一段时间，人们认为他们可以构建一个工具链和一个智能体，然后在下面插入不同的模型，他们从那个角度对路由器感到兴奋。我们开始看到 Vercel 用工具链智能体做了这个，例如。该领域的一些参与者提出了一个抽象层，说实际上插入整个工具链和整个与模型家族绑定的智能体，这很有道理。所以我们能提供的是更好、更智能：如何在那个东西下面的模型家族中混合搭配正确的模型？关于 Token 最大化、成本这类问题，我们正在经历一个公司如何最好地利用这项技术并有效运营业务的正常自然周期。在 Anthropic 工作之前，我在 Stripe，我们处于非常理性的时代，非常关注我们的 AWS 账单。如果有人构建了一个后台任务但没有正确配置，消耗 CPU 并导致支出大幅增加而不值得，我们会设置防护栏来发现它，并请那位工程师友好地关闭他们的后台任务。这些是人们将开始用 AI 解决的事情。正如 Angela 所说，危险的事情是当你只是被给定一个上限并被困在其中。但鼓励创新，鼓励人们创造优秀成果，然后从侧面观察并说，好吧，有几种不同的方式可以实现那个结果。一种是使用 Opus 并让它运行一整夜，做一些疯狂的事情。另一种是更聪明地使用策略，以更低的成本创造相同的结果。这是每个人都将开始思考的下一个层次。

Yeah. Some of that too is just that we have a strong belief that harnesses and the agentic layer should be tuned to the model family you use it with. There was a period where people thought they could build a harness and an agent and just plug in a different model underneath, and they were excited about routers from that perspective. We started to see Vercel did this with harness agent, for example. Some players in the space come up with a layer of abstraction and say, actually plug in the whole harness and the whole agent that's tied to a model family, which makes a lot of sense. So what we could provide is a little better, smarter: how do you mix and match the right models within the model family underneath that thing? On the general question of token maxing, costs, and these sorts of things, we're just going through what feels like a normal natural cycle for companies figuring out how to make the best use of this technology and run their businesses really well. Before working at Anthropic, I was at Stripe, and we were in the very reasonable era of paying a lot of attention to our AWS bill. If someone built a background job and didn't configure it correctly, burning through CPU and causing a big increase in spend that's not worth it, we put in place guardrails to find that and ask that engineer nicely to turn off their background job. Those are the things with AI that people are going to start to figure out. To Angela's point, a thing that gets dangerous is when you're just given a cap and stuck within it. But encouraging innovation, encouraging people to create excellent outcomes, and then coming in from the side and looking and saying, okay, there are a few different ways we could have accomplished that outcome. One is you take Opus and run it all night and do something crazy. Another is to get a little smarter with strategies to create that same outcome at lower cost. That's the next layer of thinking everyone's going to start to do.

非常酷。你们对未来几个月要构建的东西有什么兴奋的吗？能透露一下接下来可能会有什么吗？

Very cool. Is there anything that you guys are excited about building over the next few months that you can share a hint at what might come next?

是的。我知道我们说了这个词大概两千万次，抱歉，但我们真的在努力构建让你组合策略的方法。这是我们试图进入的领域，即抽象的协调层。我们想从这个前沿开始，因为我们看到人们构建的问题类型处于一个层面，为了获得最大回报，你必须对正在解决的问题的本质有点聪明。

Yeah. I know we said this word like 20 million times, I apologize, but we really are trying to build ways for you to compose strategies. That is an area we're trying to move into, that coordination layer of the abstraction. We want to start at this front because the types of problems we see people building are at a layer where, in order to get the most return, you have to be a little clever about the nature of the problem you're solving.

给你一个具体的例子：当你尝试构建一个用于漏洞狩猎的智能体时，你可以直接派一个出去执行任务，它会给你一定程度的回报。人们往往卡在这里，认为唯一的选择就是换一个更大的模型，或者让它运行更长时间。根据大量实验，这两个选项确实有效，但实际上你还有第三个杠杆，效果往往超乎想象：最佳 N 选一（best-of-n）。说起来容易，也有相关论文发表，但真正构建出来并投入生产，让用户测试，这非常困难。你最终需要构建各种定制化的工具等等。但我们看到这正是价值所在，而且很难。所以，遵循我们一开始谈到的简单理念：如果它能带来你想要的回报，但实现起来很难，我们就会努力让它变得简单，这样你就能运行你真正需要的实验。

So to give you something concrete: when you try to build an agent for bug hunting, you could just send one off to do that, and it will give you a certain level of return. People get stuck there and think their only options are to swap the model for a bigger one or let it run longer. From a lot of experimentation, those two things are still true, but you actually have a third lever that tends to do a lot more than you think: best-of-n. Saying those words is fine, and there are papers published on it, but actually building that thing and putting it into production so you can test it on users is really hard. You end up building custom harnesses and so on. But we see this is where the alpha is, and it's hard. So in the same simple philosophy we talked about at the beginning: if it gives you the return you want and it's hard, we'll try to make it easy for you so you can run the experiments you need.

这让我想起一年前人们讨论智能体集群（agent swarms）时的情景。这算是某种变体。

Reminds me of when people were talking about agent swarms a year ago. It's some version of that.

已经整整一年了吗？

Has it been a whole year?

是的。

Yeah.

天哪。

Oh my god.

我知道。我们终于做到了。

I know. We're finally there.

是的。我认为这是一种策略。就像你有一个大的智能体，然后拆分成多个，这是另一种策略。人们可能从人类组织的角度思考过这个问题。我想这可能是类似的，但如果深入思考，其实更像是每个词元（token）都有一个任务。正是这个任务点，我们非常关注，并且也看到了很多回报。我们想花时间与用户和生态系统中的其他人一起探讨：如何让实验变得更简单？我们随口就能给出五个任务，这也是我们内部在做的。如果我们把这些开放给生态系统，可能会有 10 万、20 万甚至更多不同的组合。我们希望继续这种爬山式优化（hill climbing），追求每美元能获得的最大价值和最高智能，并将这种能力交到人们手中。

Yes. I think that's a type of strategy. In the same way that you have one big one that separates a bunch as another type of strategy. People have thought about this maybe in terms of human organization. I guess it could be similar, but if you take it to its ends, it's actually more just like the token has a job. And it's this job piece that we're really indexed on, and we see a lot of returns too. That's the thing we want to spend time with users and the rest of the ecosystem on: how can we just make that easier for folks to experiment? We can give you five jobs off the top of our head, and that's what we have internally. If we give this out to the rest of the ecosystem, there will probably be 100,000 or 200,000 other combinations people could put together. We want to keep doing this hill climbing on how to get the most value, the most intelligence per dollar, and put that power in people's hands.

除此之外，我们还有一些用户角色，他们需要解决一系列问题才能在公司或产品中部署 AI。这包括企业级的安全和合规控制，但也包括以正确的方式让平台更加模块化，比如能够插入我们构建的不同解决方案组件，例如在这里使用记忆功能，并提供真正卓越的开发者体验。我们花了很多时间与那些拥有封闭环境的企业合作，他们需要弄清楚如何接入这些解决方案。因此，我们团队中有一部分人专注于策略和任务的创新，以帮助最大化智能，但企业表示这很酷，但由于各种原因无法使用。解决这些问题对我们来说非常重要。另一个用户角色是周末开发者，他们想为自己构建有用的东西，通常基于我们的平台和其他开发者平台。对于这些人，我们可以提供更开放或更易定制的解决方案，让他们尽情发挥，并获得出色的开发者体验。我认为有很多基础性工作让我感到兴奋，因为这些工作能解锁用户的认可，他们会说：‘好吧，这对我有用，现在我可以接入你们正在做的一些创新的爬山式优化，以获得更多智能并节省成本。’

Around the edges of that, we have these personas that have things they have to work through to deploy AI within their companies or products. That includes enterprise-ready security and compliance controls, but also making the platform more modular in the right ways, like being able to plug in different pieces of the solutions we're building, such as using memory for this thing over there, and having a truly excellent developer experience. We spend a lot of time with enterprises who have a walled garden and need to figure out how to plug these solutions in. So we have a part of our team innovating on strategies and jobs to help maximize intelligence, but enterprises say that's cool but they can't use it for XYZ reasons. Solving those problems is really important to us. The other persona is the weekend developer who wants to build something useful for themselves, often on top of our platform and other developer platforms. For those folks, we can provide solutions that are more open or hackable, so they can go wild with what we offer and have an excellent developer experience. I think there's a lot of table stakes stuff that I'm excited about because those things unlock people saying, 'Okay, this works for me, and now I can plug into some of the innovative hill climbing stuff you guys are doing to get more intelligence and save costs.'

太棒了。Katelyn、Angela，我觉得你们正在构建世界上最重要的开发者平台之一。与你们两位的多次交流让我感到非常乐观，这个平台掌握在非常深思熟虑、关心生态系统的人手中。所以，感谢你们今天抽出时间分享你们的工作，我们期待未来的发展。

Wonderful. Katelyn, Angela, I feel you are building one of the most important developer platforms in the world. Talking to the two of you over time, I just feel really optimistic that that platform is in very thoughtful hands that care about the ecosystem. So, thank you for taking the time today to share what you're up to, and we look forward to what's ahead.

感谢邀请我们。

Thanks for having us.

谢谢你们。

Thank you guys.