AI 平台的未来：Claude 的演进与扩展

Angela、Caitlin，欢迎来到节目。

Angela, Caitlin, welcome to the show.

谢谢邀请。

Thanks for having us.

嗯，谢谢。

Yeah, thank you.

所以，对于不了解的人来说，你们俩都在 Anthropic 的平台团队工作。Angela，你是 Claude 平台的产品负责人，Caitlin，你是 Claude 平台的工程负责人。我很兴奋能和你们聊，因为第一，你们发布了很多东西——最近推出了 Claude 托管智能体，还不断上线新功能。而且我觉得这正好处在一个非常有趣的节点，让我思考：对于一家模型公司来说，AI 平台到底是什么？在 GPT-3 时代，平台就是一个补全端点——你发个提示词，得到回复。后来变成了带工具调用和聊天会话的补全端点。而现在，有了 Claude 托管智能体，你基本上得到了一个带记忆和各种能力的 Claude 在电脑上运行。所以我希望你们能帮我梳理这条演进路径，以及构建 AI 平台意味着什么。

So, for people who don't know, you both work on the platform at Anthropic. So, Angela, you're the head of product for the Claude platform and Caitlin, you are the head of engineering for the Claude platform. I'm really excited to talk to you because A, you've been launching a bunch of stuff. You have Claude managed agents that came out recently, you've been launching new features for it. And I think that it comes at this really interesting time where it makes me think about what actually is a platform in AI for a model company because in the GPT-3 days, the platform was a completion endpoint. You just send a prompt to get a response. After that, it's a completion endpoint with tool calling and chat sessions. And now with Claude managed agents, you're essentially getting a Claude on a computer with memory and all this other stuff. So, I'd love for you to help me unpack that trajectory and what it means to build a platform in AI.

嗯，我觉得你的描述非常准确。随着这些技术从 LLM 起步，然后把它放到 API 后面，当时很有趣。很多人觉得‘哇，我居然能做一些事情’，我觉得那很酷。现在回头看，可能会觉得‘哦，那真的很基础’。然后我们逐渐走向一个更有状态的世界，因为你希望持久化会话和状态，让模型性能越来越好。我认为这可能是主线。随着我们改进 Claude，让它变得更好、更自主，我们发现需要把平台演进成越来越高的抽象层次，但目的都是为了帮你获得最佳结果。最开始，每个人都在探索，你不知道人们会用这些 LLM 构建什么，所以你想尽可能多地提供可能性。然后随着用例逐渐聚焦，人们开始用它构建产品和智能体。越来越多的情况是客户来找我们问：‘我怎样才能让 Claude 发挥最大价值？怎么设置工具？怎么运行循环？’等等。有些人还在边缘做实验，这很好。但还有一大批人希望很多功能开箱即用。在追求让 Claude 产出最佳结果的过程中，我们不断丰富平台，让它越来越强大。这既包括状态，也包括你开始看到的我们添加的工具，还包含很多云组件。但这一切都服务于同一个使命：让事情尽可能简单。展望未来，平台最终做什么的哲学，可能就归结为一套原语和基础设施，让你以最少的工作量、最快地获得结果。至少在现阶段，它遵循某种特定的形态。

Yeah, I think your characterization is very accurate. As a lot of these technologies have evolved with the LLM starting, and then putting that behind an API was very fun. A lot of people were like, 'Wow, I could do something at the time.' I think it was very cool. Now we'll probably look back at it and be like, 'Oh, that was really basic.' And then we've moved more and more towards a slightly more stateful world as you want to persist sessions and state to make sure the performance of the model is better and better. I think that's probably the through line. As we make improvements to Claude and it continues to get better and more autonomous, we find ourselves needing to evolve the platform to be higher and higher order abstraction, but it's in the pursuit of helping you get the best outcomes. In the very beginning, everyone was very exploratory. You have no idea what people are going to build with these LLMs, and you wanted to have as much possibility available. Then as those use cases started to narrow down, people started building products and agents with it. More and more of that is about customers coming to us and being like, 'How do I get the best out of Claude? How do I set up my tools? How do I run the loop?' And so on. You have some people who are really experimenting on the edges, and that's great. And then you have a whole host of other folks who want a lot of this stuff out of the box. In our pursuit to make sure Claude is producing the best outcomes, we find ourselves enriching the platform to be richer and richer. That includes both the state and the tools you start to see us adding. It contains a lot of the cloud components of these types of things. But it's in pursuit of the same mission: making things literally as easy as possible. In the forward state, the philosophy of what a platform ultimately ends up doing probably ends up being whatever set of primitives and infrastructure enables you to get the outcome as fast as possible with as little work as possible. That tends to follow a certain form factor at least in this current stage.

你怎么描述今天的原语是什么？也许这直接就是在问 Claude 托管智能体中的原语有哪些？

How would you characterize what the primitives are today? Maybe that's just asking what are the primitives in Claude managed agents?

嗯，Claude 托管智能体构建在我们所有相同的原语之上，这些原语你也可以直接使用。比如 Messages API。在 Messages API 内部，我们围绕 API 做了很多创新。如果你真的只想获取输入输出 token，也可以；但你可以使用我们的一些内置工具，比如代码执行——启动沙箱并执行工作，还可以使用网络搜索等等。所以我认为，我们把所有我们认为最强大的东西整合到一起，形成一个框架和一套基础设施，这就是我们认为能让 Claude 产出最佳结果的方式。

Yeah, so Claude managed agents is built on all of our same primitives that you could otherwise build on directly. So the messages API. And within the messages API we've built a whole bunch of innovations around the API. You could just get tokens in and out if you really wanted to, but you can use some of our built-in tools. You can use stuff like code execution, spawn a sandbox and execute work. You can use web search and all these sorts of different things. And so I think we've taken what we see as all the most powerful of those things and put them together into a harness and a set of infrastructure that is just the way to get what we think is the best outcomes out of Claude.

我坐在这里有一种时间通缩的感觉——我的时间在未来会变得更值钱，而不是相反。原因是我们内部正在构建一个智能体，我们在开发一些智能体产品，让智能体为我们内部做特定的事情，未来也希望为客户服务。为此，我们用了几个 Mac mini，让 Claude 在上面循环运行。这很大程度上和你们在 Claude 托管智能体中构建的东西类似。所以对我来说，以及我认为对很多在 Claude 平台或生态上构建的人来说，至少我有这种感觉：也许我们只需要等你们把它做出来就行了。

I'm sitting here feeling this sense of time deflation. My time gets more valuable in the future as opposed to the opposite. The reason is because we're building an agent internally. We're building some agent products where it's agents that do specific things for us internally and then hopefully for customers. In order to do that, we have a couple Mac minis with Claude running in a loop on the Mac mini. And a lot of that mirrors what you guys are building in Claude managed agents. So for me and I think for a lot of people building on the Claude platform or ecosystem, there's at least I feel this: maybe we should just wait for you guys to build it.

一年后，你觉得平台会发展到什么程度？我们希望探索一些方向，让 Claude 真正变得非常擅长理解自身，它能判断你应该使用什么模型，能决定如何启动所有子智能体。我们不需要过多考虑架构是什么，因为 Claude 实际上足够了解自己，可以即时重写自己。

A year from now, where do you think the platform will be? We'd want to experiment with directions where Claude actually gets so good at understanding itself, it figures out what model you should be using, it figures out how to spin up all the sub agents. We don't have to think so much about what kind of architectures are there because Claude is actually able to understand itself enough that it can write itself on the fly.

在那个世界里，如果 Claude 或智能体能够即时变成你完成任务所需的样子，那么平台必须大幅扩展规模。

In that world, if Claude on the fly or agents on the fly are becoming what they need to become in order for you to do what you're trying to do, the platform has to seriously scale.

我们离 Claude 赚到十亿美元还有多远？这才是我想问的。

How close are we to Claude making a billion dollars? This is really what I'm asking.

嗯，但我不清楚界限在哪里，我有点想知道，如果我想构建一个智能体，什么是最佳路径，才能与你们正在做的事情保持一致？

Um, but then I don't know what the lines are and I'm sort of wondering if I want to build an agent, what is the best path to do that in a way that aligns with what you guys are doing?

是的，我认为平台业务的这一部分实际上与其他形式的平台业务有些相似，你有像你这样的客户在构建，你在想，我是否应该直接去做，因为我可能有这个即时需求，但同时我不想重复劳动，而你本可以免费从平台中获得它。

Yeah, I think this part of the platform business is actually somewhat similar to any other form of the platform business where you have customers like yourself who are building, and you're kind of thinking, should I go ahead and do it because maybe I have this immediate need, but at the same time I don't want to repeat the work per se, and you could have just gotten it in for free out of the platform.

而且基础设施很糟糕。启动服务器太麻烦了。真不敢相信你一直做这个。

And also infrastructure sucks. It sucks so much to spin up servers. I can't believe you do that all the time.

但我实际上要说，我们最终构建 Cloud Manager 智能体的部分原因是，Anthropic 自己经历了足够多的迭代，我们构建了可以在云端自主运行的智能体产品，我们做了这些，搭建了基础设施使其良好运行，次数多到我们自己都觉得，好了，我们不再为自己构建了。我们一次性以真正有效的方式来做，基于我们学到的一切，同时也为所有正在做这件事的人，比如你可以在几台 Mac Mini 上运行你的东西，对吧？对很多人来说这可行，但我认为如果你将智能体构建到你的产品中，并且真正大规模运行，那么让基础设施正确就会变得越来越有挑战性。

But I will actually say part of why we ended up building Cloud Manager agents was because Anthropic ourselves had gone through enough of these iterations where we built products that were agents that you could run autonomously in the cloud, and we did that, stand up the infrastructure so that it works well, enough times that we ourselves were like, okay, we're done building this for ourselves. We're doing it once in a way that's going to really work from everything that we've learned, but also for all the people who are doing it, like you can run whatever you're running on a couple of Mac Minis maybe, right? And for a lot of people that could work, but I think if you're building agents into your product and you're running something really at scale, that's where it really starts to become more and more challenging to get that infrastructure right.

这真的很有趣。

That's really interesting.

是的，然后也许回答你问题的另一部分，我认为我们这里有两个哲学部分。一个是我们设计托管智能体的方式，我们试图让它足够模块化。我们希望对某些我们认为应该与 Claude 模型紧密结合的部分持有明确观点。但很多时候，我们想要的方式，例如，我们希望 Claude 非常具体地使用文件系统。那是非常特定的 Claude 风格。

Yeah, and then maybe to answer the other part of your question, I think we have two pieces of the philosophy here. One is a bit in the way that we design managed agents, which is that we try to have it be modular enough. Like we want to be opinionated about some pieces that we feel like should be very well married to the Claude model. But then we like often times the way we want, for example, we want Claude to very specifically use file systems. That's a very particular Claude kind of style.

还是泛指文件系统？

Or just file systems in general?

泛指系统。我们也非常想依赖技能。我知道很多人喜欢技能，但这是我们希望内心非常坚持的事情。所以我们对这些原语特别讲究。比如使用文件系统，使用技能。它们非常基础。但与此同时，我们仍然发现有人尝试其他方法来做这件事。我们想帮助你，在你构建时，从一开始就走上最佳道路。所以这是关于一些更明确观点的一部分。但作为套件中的每个端点或 API，我们试图在某些领域稍微开放它们。所以有些我们期待的事情，比如也许今天还不可用，但在我们的设计中，我们试图使其足够灵活，让人们可以添加不同的部分，因为我们认识到这个 API 或 API 套件不一定能在其原始构造中解决所有问题，会有需要开放的部分。然后第二点是，我们对此比较公开：当我们设计很多这些东西时，我们会发布博客文章和参考实现。所以如果你至少想从那个构造中获得灵感，但仍然可能在消息 API 上自己构建，你完全可以这样做。

Systems in general. We also really want to lean into skills. I know a lot of folks like skills, but that's something that we want to have our hearts be really opinionated about. And so we're kind of particular about those primitives being the case. So like use the file systems, use the skills. They're really basic. But at the same time we still find people who are still trying other methodologies to go do that. And we want to help you, when you build, to start off on the best foot. So that's one piece on some of the more opinionated ones. But as each one of these endpoints or APIs that we have as part of the suite, we try to open them up a little bit in certain areas. So there are things that we're looking forward to and being like, maybe it's not available today, but in our design we are trying to make it flexible enough for people to add in different pieces because we recognize that this API or suite of APIs is not necessarily going to solve everything in its original construct, and there are going to be pieces that need to open up. And then the second bit is, we're kind of public about this: when we design a lot of these things, we do put out blog posts and reference implementations. So if you did want to at least be inspired by that construct, but still maybe make your own on the messages API, you can definitely do that.

我认为这正好说到你刚才提到的点，这对我们来说是个问题。再次，我们有 Claude 在 Mac mini 上运行，带一个 Python 文件，还有几个更大更严肃的实现在云基础设施上，我们正在琢磨怎么处理。我想我告诉团队我们今天在聊，我认为他们考虑使用 Claude 托管智能体为客户启动智能体时的一个问题或担忧是，现在就像我们有一个游乐场。我们有一个服务器或 Mac mini。我们可以直接把东西传给 Claude。它能做 Claude Code 能做的任何事情。它有文件系统，有浏览器，有所有这些。如果我们想换成 GPT 5.5 或 Gemini 或其他，很容易做到。所以是不是这样，我觉得他们觉得如果使用 Claude 托管智能体，我们会被锁定，失去做所有我们想做的事情的灵活性。还有一个担忧是，Claude Code 本身会有一些功能，而 Claude 托管智能体暂时没有，这会阻止我们处于前沿，而这正是我们向客户和自己承诺的。我们就是喜欢做任何新东西。你怎么看？

I think that's to the point you just made, that's something that's coming up for us. Again, we have Claude running on a Mac mini with a Python file and a couple other bigger more serious implementations on cloud infrastructure that we're trying to figure out what to do with. And I think I told the team that we were talking today, and I think one of the questions that they have or one of the feelings of consternation that they have considering using Claude managed agents for this kind of thing for spinning up agents for our customers is just right now it's a like we have a playground. We have a server or Mac mini. We can just pipe stuff to Claude. It can do anything that Claude code can do. It has a file system. It has a browser. It has all this stuff. If we want to switch it out to GPT 5.5 or Gemini or whatever it's pretty easy to do that. So is that kind of and I feel like they feel like we're going to get locked in if we use a Claude managed agent and it's not going to have the flexibility to do all the stuff that we want. And there's also a worry that features are going to come to Claude code itself that won't be in Claude managed agent for a little while and that it'll prevent us from being at the edge which is sort of what we promised to our customers and really to ourselves. Like we just love being just doing whatever the new thing is. How do you think about that?

是的，所以我认为我们内部工作方式的好处是，我们运营平台，而平台对大多数人来说就是我们面向外部的 API 和 API 套件。我们团队实际做的其余部分是内部平台，因为我们所有的第一方产品都直接构建在与其他所有人相同的平台上。所以很酷的一点是，我们花很多时间与内部团队合作，他们构建在平台之上，我们启用他们将构建的功能，分享想法等等。所以我认为随着时间的推移，你可能会看到 Claude 托管智能体与可能构建在相同基础设施上的同事 Claude Code 之间的功能差异越来越小。这是思考这个问题的一种方式。然后我认为关于你团队对模型锁定恐惧的观点，我认为那是合理的。很多人都有这种担忧。

Yeah, so I think what's nice about the way that we work internally is that we run the platform and the platform for what most people think of it as is our externally facing APIs and our suite of APIs. The rest of what our team actually does is internal platform in the sense that all of our first party products are built directly on the same platform as everybody else. And so what's cool about that is we spend a lot of our time working with the teams internally who are building on top of the platform and enabling the features that they will build, sharing ideas and these sorts of things. And so I think over time you'll maybe see less and less divergence of what might be available in Claude managed agents, what might be available in co-worker Claude code that might sit on top of the same infrastructure. That's one way to think about that. And then I think on your point around your team's point about having some kind of model lock-in fear, I think that that's valid. Many folks have that consternation.

我认为我们正处于一个演变的阶段。回顾一下，哪怕只是几个月前，构建一个非常通用的框架（harness）然后跨所有模型热切换是很标准的做法。对于上一代模型，这还算行得通。但现在，对于下一代模型，每个实验室都在采用略有不同的技术和视角来推进他们的模型。理论上，你可以做所有这些的超集，但当你为公司或客户构建智能体时，你最终要交付的是成果。所以热切换的抽象层不再是通用框架，框架和模型变得紧密配对。你仍然需要冗余，也可能使用其他模型，但这是在智能体层面——即框架加模型——而不是一个通用框架加上底层所有东西的热切换。

I think we're at a place where there's an evolution. If you look back, even just a couple months ago, it was standard to build a very generic harness, and then you could hot swap models across all those things. For an older generation of models across labs, that worked okay. But now, for the next generation, every lab is taking slightly different techniques and perspectives to advance their model. In theory, you could do the superset of all those things, but when you build agents for your company or customers, you want to deliver an outcome. So the abstraction of hot swapping stops being a generic harness; the harness and model become very paired. You still need redundancy and might use other models, but you do it at the agent layer—the harness plus the model—rather than a generic harness with everything underneath.

这很有意思。像 Cursor 这样的公司是这样做的吗？他们是每个模型有单独的框架，还是一个通用框架来热切换模型？你知道吗？

That's really interesting. Is that how the Cursors of the world are doing things? Do they have a separate harness for each model, or a generic harness that they hot swap models in and out of? Do you know?

我不完全确定。我的直觉是，我不太了解 Cursor 的具体情况，但我们接触过的一些团队也有类似的观点。这主要是因为他们想从每个模型中榨取最大价值，几乎是在框架层面精雕细琢每一个细节。我们有一个外部客户的例子，但我们在内部也做了很多。最近我们为托管智能体（managed agents）做了记忆功能，尝试了多种不同的框架。我们试了最终发布的那一个，也用了其他不同技术。就我个人而言，当我看到团队的评估套件时，每个框架的表现差异巨大。所以仅从这一点就能看出，通过将正确的组件进行框架工程，你可以获得巨大的提升。如果把这推广到所有实验室和提供商的所有模型组合，这种结构中有很多阿尔法（alpha）。所以如果不止我们一家在尝试这种级别的单元绑定，我也不会感到惊讶。

I'm not entirely sure. My intuition is that, I don't know about Cursor in particular, but there have been teams we've talked to who have fallen on similar perspectives. It's mostly because they're trying to squeeze the most out of each model, almost harness engineering every nuance. One example we have is an external customer, but we've done a lot internally. We recently worked on memory for managed agents and tried a bunch of different harnesses. We tried the one we ended up launching, and others using different techniques. Personally, when I saw the eval suite from the team, each harness performed drastically differently. So even looking at that shows you can hill climb a tremendous amount by harness engineering the right pieces together. If you take that forward across all model combinations across all labs and providers, there is a lot of alpha in that construct. So I wouldn't be surprised if more than just ourselves have experimented with that level of unit tying.

很有意思的是，这种路径依赖——你如何选择请求和响应的方式、如何调用工具、是否让模型使用文件系统——会改变所有这些模型的轨迹。当时可能只是一个小注脚，但最终变得非常重大。你认为这会影响模型的通用性吗？也就是说，在某个时候，它们会锁定在自己擅长的领域——Claude 非常擅长文件系统，GPT 擅长其他事情？如果模型被锁定在特定的做事方式上，这会如何影响它们的个性和行为？

It's really interesting that there's this path dependence where you make some choice for how you do requests and responses, or how you tool call, or whether you have the model use file systems. That changes the trajectory of all these different models. It feels like at the time it's a small footnote, but it ends up becoming very big. Do you think that will affect the models' generalizability, in the sense that at some point they'll have locked-in lanes of stuff they're good at—Claude is really good at file systems, GPT is good at other things? How will that flow through the models' personality and behavior if it's locked into a specific way of doing things?

我确实认为这往往会锁定模型。所以我们视为正确路径和正确原语的东西需要非常仔细地思考。在某些领域，其他模型变得非常擅长推理，然后几乎在那个层面上过度优化。还有其他视角——比如，是的，我们希望它非常擅长计算机；也许计算机部分才是有趣的部分。如果我们仔细思考原语，我们可能做对也可能做错，但至少经过思考过程会引导我们走上一条或另一条路。很难说哪个方向最终是正确的，但我确实认为在采用上存在很多路径依赖。所以对你选择包含或更原生地赋予模型的东西要非常谨慎，这很重要。

I do think it tends to lock the model. So what we treat as the right path and the right primitives needs to be very carefully thought through. In some areas, other models become really good at reasoning and then almost over-optimize on that level. There are other perspectives—like, yes, we want it to be really good at a computer; maybe the computer part is the interesting part. If we think through the primitives, we could get them right or wrong, but at least going through the thought process will lead us one path or the other. It's hard to say which direction will ultimately be true, but I do think there's a lot of path dependency in its uptake. So being really thoughtful about what you choose to include or give the model more natively is really important.

有没有哪些路径依赖是你不得不撤销的？

Are there any of those path dependencies that you've had to undo?

很可能有。在 Anthropic 层面我不便多说——我才来了几个月——但我可以想象确实如此。即使在其它实验室，我们需要审视的原语也在不断变化。你会达到一个局部最优，然后重新思考，也许有更通用的方法。

Probably. I can't speak enough about that at the Anthropic level—I've only been here a couple of months—but I have to imagine that has been the case. Even at other labs, the primitives we have to look at are constantly changing. You do hit a local maximum and rethink, maybe there's a more generic approach.

是啊，有意思。我想退一步问一个我一开始就该问的问题：Claude 托管智能体是为谁设计的？我今天早些时候设置了一个。我们 Every 内部已经有人在生产环境中使用了，我今天也刚弄了一个。我真的很喜欢入门聊天体验和一些示例。感觉即使我不是技术人员，我也可能想用这个来设置一个智能体。可能有点复杂，但我实际上是在 Codex 的应用内浏览器里做的，让 Codex 驱动托管智能体的设置，然后我很快就让一个 Slack 机器人跑起来了。真的很酷。

Yeah, interesting. I want to take a step back and ask something I should have asked at the beginning: who is Claude managed agents for? I set one up earlier today. We've got some people already using it in production inside of Every, and I just did one today. I really loved the getting started chat experience and some of the examples. It felt like even if I wasn't technical, I might want to use this to set up an agent. It might be a little complicated, but what I actually did was I did it in the Codex in-app browser, so I had Codex driving the managed agent setup, and I had a Slack bot working pretty quickly. It was really cool.

那么，你在设计 Cloud 托管智能体时，是如何考虑目标用户的？

So, how do you think about when you're designing stuff, when you're designing Cloud managed agents, who it's for?

是的，这很有趣，因为我认为你说得对，尤其是那个快速入门体验——我们非常坚定地推出它，并不是专门为了让非技术人员也能构建智能体，而是为了让任何人，无论技术背景如何，都能理解像 API 这样的基本元素，以及它们是如何组合在一起的。就像教育部分那样。但当我们思考目标用户时，我们会考虑几个不同的方面。一是我们看到公司内部的人在构建自动化或强大的平台或系统。比如，我们听到有人说“我想要一个完整的端到端软件开发平台”，对吧？而 Managed Agents 正是这类场景的完美解决方案。或者，“我想在这里自动化一个小流程，比如法务需要审核我的营销文案”，诸如此类。所以，你不必每次都重新实现记忆功能，对吧？你可以很快上手并让东西跑起来。另一个我们非常关注的用户群体是那些将智能体嵌入到面向客户的产品中的人。所以，这是另一个场景，实际上你确实需要大量的定制化，你确实希望为你的产品打造出非常强大的东西。但我们仍然坚信，不把工程资源浪费在基础设施和那些琐碎的“脚手架”工程调整上是非常值得的。

Yeah, so it's interesting because I think you're right that especially with that quick start experience, which we actually felt pretty strongly about launching not specifically for the sake of making it so that non-technical people could go and build agents, but actually just for anybody technical or not to be able to wrap their head around the primitives like the API, and here's how they fit together. Like, you know, the kind of education portion of it. But I think when we think about who it's for, we think about a couple different things. One is we're seeing people internally within companies build automation or build really powerful platforms or systems. Like, we've seen people say, 'I want a full end-to-end software development platform,' right? And Managed Agents is a perfect solution for something like that. Or, 'I want to automate a little process over here where legal has to review my marketing copy,' and things like that. And so, you shouldn't have to re-implement memory and like exactly. Every time you're doing that, right? You can get started really quickly and you can get something running quickly. The other user that's top of mind for us is people building into their products that they expose to their customers. And so, that's the other one where actually, yes, like you do still want a lot of customization. You do still want to make something that's going to be really powerful for your product. But, we still like definitely, definitely believe that not spending your engineering resources on the infrastructure and on all the little harness engineering tweaking sort of stuff is like worthwhile.

就像一个月前？你本可以为我们节省大量时间。我们得再好好聊聊。

Like a month ago? You would have saved us so much time. We'll just have to talk more.

但我有点好奇。好吧，也许基础设施是其中之一，但当你看到人们设置智能体时，你觉得他们认为困难的是什么，而实际上困难的是什么，这两者一致吗？

But, I am sort of curious. Okay, so maybe infrastructure is one of these things, but when you see people setting up agents, what do you see them think the hard thing is and what ends up actually being the hard thing and are they the same?

好问题。也许这有点尖锐，我不确定，但我认为人们觉得“脚手架”工程部分很难。所以，实际上，过去我们推出了 Agent SDK，我想你们在 Mac mini 上用的就是这个。对很多人来说，他们觉得，太好了，我不需要做那些“脚手架”工程了，比如提示缓存、最大化上下文窗口之类的事情。

Good question. I maybe this is, I don't know, spicy, I'm not sure, but I think people think the harness engineering part is the hard part. And so, actually, like, you know, in the past we launched the agent SDK, which is what you guys I think are using on your Mac minis. And for a lot of people they were like, okay, great. I don't have to do the harness engineering part where I have to do prompt caching and I have to maximize my context window and all these sorts of things.

我们实际上只是用 Claude 的批处理模式，比如 Claude -p 命令。哦，哇。好吧，那也挺好的。是的。

We're just actually using just Claude in batch, like the Claude -p command. Oh, wow. Yeah, okay. It's pretty good. Yes.

好吧，酷。但不管怎样，你们这么做是因为它帮你们省去了构建“脚手架”的工作，对吧？但我确实看到很多客户的情况是：好了，现在我想把这个东西投入生产并规模化，然后每个人都撞上了基础设施这堵墙。每个人都遇到同样的问题：哦，哇，我要么需要让服务器持续运行，要么需要使用能自动伸缩的基础设施，还需要存储对话数据，需要安全的沙箱环境，等等。所以，如果你启动一个 Claude Code 会话或在沙箱中启动 Agent SDK，那就是你正在运行的东西，但如果你的沙箱断连或崩溃，整个智能体就挂了，对吧？所以我认为基础设施部分，尤其是大多数人最终撞上的那堵墙，但他们原本更期望的是实际的“脚手架”工程和如何充分利用模型才是更难的部分。

Okay, cool. And but regardless, like, you guys did that because it takes off your hands building the harness, right? But I do think what we saw with a lot of customers was, okay, now I want to go and take that thing and like get it into production and scale it, and everybody hits an infrastructure wall. Like, everyone hits the same problem of like, oh, wow, I either need to like keep a server constantly running or I need to use infrastructure that will spin up and spin down, and I need to store the transcript data, and I need secure sandboxing, and all these sorts of things. And so, you know, and like, if you boot a Claude code session or you boot the agent SDK in a sandbox, and like, that's the thing that you have running, but your sandbox loses connection and dies or whatever, your whole agent dies, right? And so, I think the infrastructure part, especially, is the wall that most people end up hitting, but they're more expecting that the actual harness engineering and like getting the most out of the model is the part that's going to be harder.

是的，我完全同意。我正想说，我们和很多人聊过，他们现在处于快速原型阶段，非常兴奋，觉得这东西真管用。但还有一类人，他们不断推进，说“好吧，我确实想爬山，我真的想挑战最难的部分”。但一旦你有了那个东西，产品化简直就是噩梦。尤其是那些更有趣的、长时间运行的异步任务，你想让它们更远程、更自主一些。每个人都会撞上这堵墙，这也是我们构建现在这个产品的重要灵感来源。

Yeah, I totally agree with that. I was just going to say, like, we talk to so many people who are at now the place where they're like prototyping really quickly, and they're super excited, and it's like it's doing the thing. And then yet, there's like a class of people who are, you know, really pushing and being like, okay, I do want to hill climb. I really want to edit the hardest. But then, once you have that thing, like, productionizing is just a freaking nightmare. Especially for like the more interesting kind of long-running async ones that you want to do a bit more remotely, that are a bit more autonomous. And everyone kind of runs into that wall, and it was a big inspiration for why we built what we built.

我觉得智能体形态的一个例子是 OpenClaw。尤其是它给我们内部带来的东西：你在 Slack 里有一个始终在线的智能体，它有自己的个性，有自己的工作领域。你们觉得，这是否是一个可能的未来——一个一键部署的智能体，存在于我的 Slack 中，我可以设置所有内部细节，但不需要真正考虑所有技术基础设施？因为我认为你们已经有了雏形，但从当前的 Managed Agent 到始终在线的 Slack 智能体，中间还有很多步骤需要设置和定制。那么，这属于平台的工作范畴，还是说太偏向产品方向了？

I feel like one of the examples of the shape of an agent is OpenClaw. And in particular the thing that it has brought to us internally is you have an always-on agent in Slack that has its own personality and has its own part of the world that it ends up working on. Are you guys like, is that a possible future for like, okay, a one-click agent that lives in my Slack that yes, I can go set up all the internals, but like I don't have to really think about all of the technical infrastructure stuff? Because I think you all have the beginnings of that, but it's still like a lot of steps from the current Managed Agent to something that's always on in my Slack that I have to set up and customize. So is that does that fall in the realm of platform's job or is it like too far in the product direction?

不，这绝对是我们非常想做的事情。我认为，我们一开始重点放在基础设施部分，因为那里正是我们看到很多痛点的地方。但没错，在其高级形态中，我们实际上希望让你能够非常非常容易地部署这些智能体。我们已经朝这个方向迈出了一小步。比如，我们将 vaults 作为基本元素之一包含进来，作为一种……

No, it definitely is something that we really want to do. I think like, you know, we focused a lot on kind of the infrastructure piece to start because that's where we just see a lot of these pain points. But yes, like I think in its advanced shape, we actually want to make it so that you can kind of deploy these agents really really easily. Like we've made some light steps in this direction. Like for example, we included vaults as one of the primitives just as kind of...

vaults 存储你的密钥之类的东西，比如认证密钥？

And vaults store your keys and stuff, like your auth keys?

凭证。凭证，是的。作为解决一些底层问题的起点，但一旦你以更安全的方式封装了这些类似智能体身份的基本元素，并且能非常轻松地处理，同时与整个系统协同工作，那么，我认为我们很自然地会达到这样一个状态：也许你只需一键集成 Slack，或者甚至直接告诉 Claude“添加 Slack”，它就能处理所有事情，然后不知不觉中，你的小机器人就会在 Slack 上 ping 你了。

Credentials. Credentials, yeah. As like, you know, kind of solving some of the lower level pieces as a starting point, but once you kind of wrap some of these more sort of like agent identity type of primitives in a more secure way and you can handle it really easily and it works with like the whole system, then, you know, I think it's very natural for us to get to a place where maybe you are either one-clicking a Slack integration or alternatively even maybe just telling Claude, like add Slack and it just handles absolutely everything and then before you know it, your little bot is just pinging you on Slack.

我喜欢这个想法。我已经等不及那个世界到来了。

I love it. I can't wait for that world.

智能体在企业内部的最佳用例是什么？因为我觉得现在有个大问题：好吧，每个人都在用 Codex 或 Claude Code，但现在我们有了这些云端的智能体。公司里的每个人都可以有自己的智能体，有团队智能体，也有公司级智能体。那么，你看到的模式是什么——当人们构建真正有用的内部智能体时，它们做什么、长什么样？

What are the best internal use cases of agents? Because I think there's this big question happening right now where okay, yeah, everyone's in Codex or Claude Code, but now we have these agents that are out in the cloud. Now everyone inside a company can have their own agent. There are team agents. There are company-wide agents. So, what are the patterns that you see for when people make really useful internal agents, what they do and what they look like?

是的，我想说我们确实在一些更 AI 原生或 AGI 原生的公司中看到了一些例子，比如 Stripe 构建了 Minions，他们经常把它描述为工程师可以使用的端到端平台。我认为 Ramp 也做了类似的事情，我们也做了类似的事情，对吧？

Yeah, I would say we've actually seen a few examples of these in some of the more AI-native or AGI-native companies, like Stripe built Minions and they talked about that a lot as their kind of end-to-end platform that their engineers could use. I think Ramp did something similar and we've done similar things as well, right?

是的，我们在内部构建了某种平台，我有运行中的智能体，可以通过 Slack 或任何地方与它对话，对吧？在某种程度上，这实际上只是在托管智能体之上加了一个很薄的层。你不需要做太多就能实现。

Yeah, we've built kind of platforms internally that are, you know, I have agents running that I can talk to from Slack or from wherever, right? And at a certain point that becomes actually a pretty thin layer on top of managed agents. Like you don't have to do very much to accomplish that.

这正是我在想的。比如我看了 Minions 或 Ramp 做的那些，我就想，为什么？那么，拥有一个公司任何人都能用的薄层编码智能体真的有用吗？或者为什么不直接在 Slack 里安装 Claude 应用呢？

That's what I was thinking. Like I looked at Minions or whatever Ramp does and I was like, why? So, is it actually useful to have a sort of thin coding agent that anyone in the company can use or like why not just install the Claude app in Slack?

是的，我想说这种平台和我们内部做的一些事情之间的区别在于，你可能想在智能体实际运行并能验证其更改的开发环境中做很多定制，对吧？诸如此类。

Yeah, I would say the difference in a platform like that and some of the things that we've done internally is there's a lot of customization that you might want to do on the development environment where an agent is actually running and able to verify its changes, right? And things like that.

比如我们的 CI/CD 是怎么工作的。

Here's how our CI/CD works.

对，完全正确。所以，我认为对很多人来说，Claude Code 是一个很棒的工具，对吧？你可以用 Claude Code 运行 Claude 智能体，这确实很好，但我认为如果你想做更多端到端的开发，对吧？你可能想融入更多自定义的东西，你可以从托管智能体之类的东西开始，在上面构建一层，最终得到更接近端到端体验的东西。

Yeah, exactly. And so, I think for lots and lots of people, Claude Code is an excellent tool, right? And you can run Claude agents with Claude Code and that is really great, but I think if you're trying to do a bit more end-to-end development, right? And you maybe want to bake in more custom things, you could start with something like managed agents and build a layer on top of that and end up with something that's maybe closer to that end-to-end experience.

我还觉得，有一个需要协作的团队，这一点特别让托管智能体的形态变得重要，而不是所有事情都在 Claude Code 里完成。比如我猜技术上你可以同步每个人的 Claude Code 技能，但大家共享一个做这件事的智能体似乎更有效。

It also seems to me like there's something in particular about having a team that you need to work with that makes the managed agent shape important, as opposed to it just all works in Claude Code. Like I guess technically you could sync the skills between everyone's Claude Code, but there's something about just we all have one agent that does this thing that seems to work.

是的，我很高兴你提到这一点，因为我认为这实际上是我们看到很多机会的常见领域之一。如你所说，无论是开发者还是非开发者，都有很多个人生产力提升。有太多工具可以让你更自动化、更高杠杆。但当你到了团队层面，突然一切都变得极其复杂。首先，它显然不能放在你的笔记本电脑上。是的，你可以把它放到云端，但那更多是为了你自己在合上笔记本时也能处理。但接着你会想，好吧，现在我们三个人想要几个能互相接口、协同工作的智能体。然后也许我们在自动化一个端到端的流程。尤其是对于一些你设想会被 AI 真正变革的更复杂流程，你确实需要那种团队导向。这需要在比单个智能体稍高一点的抽象层上发生。我认为一些探索多智能体架构等的团队非常令人兴奋。但它需要构建在一个平台上，每个人都可以启动、停止和控制。我认为 Vercel 的 G 对此有一个非常好的视角，他的公司 Vercel 显然是用 AI 构建的。他把它描述为内部的一种 AI 软件工厂。我认为这正是正确的思维方式，它产生了一个极高杠杆的组织，真正创造了巨大的生产力，不仅是为他们自己，而是为公司里的每一个流程。

Yeah, I'm really glad you brought that one up because I think that's actually one of the more common areas where we see a lot of the opportunity. To your point, there's a lot of individual productivity that's happening whether you're a developer or non-developer. There are so many tools that you're using to just make yourself more automated, more high leverage. But then when you get to the team layer, suddenly everything gets massively more complex. Number one, obviously it can't sit on your laptop. And yes, you could maybe put it in the cloud, but it's again more for yourself to handle with your laptop closed. But then you go to okay, now the three of us want a couple agents that interface with each other and work with each other. And then maybe we're automating a process end to end. And especially for some of the more complex processes that you envision being really transformed with AI, you do need that kind of team orientation. And that needs to happen at a layer that's a slightly higher bit of abstraction than just a single agent. And I think some of the teams exploring multi-agent architectures and things like that are really exciting. But it needs to be built on top of a little bit of a platform that everyone can spin up and down and control. And I think G from Vercel had a really good perspective on this, where I think his company Vercel is obviously incredibly AI-built. And he kind of describes it as sort of an AI software factory internally. And I think that's exactly the right mindset and that produces an extremely high leverage organization that's really just creating a tremendous amount of productivity, but not just for themselves, for every single process that they have in the company.

嗯。我真的很想回到这个问题：智能体用例。我们有公司任何人都能用的编码智能体。你还看到人们搭建了哪些其他真正有用的智能体？

Mhm. And I really want to go back to this like okay, agent use cases. We've got coding agents that anyone can use in the company. Like what are the other ones that you see people standing up that are really useful?

我们看到了一些。所以我们做的一件有趣的事情就是与不同职能的内部团队合作，帮助他们识别，因为这样做我们实际上学到了很多。所以我之前提到的那个傻例子，比如法务团队需要审核营销文案，就是其中一个非常真实的例子。是的，非常真实，而且用非常基础的智能体就让人大开眼界，这些智能体只是给人们提供了正确的设置来做这件事。

We've seen a few. So one of the fun things that we get to do is just kind of work with our internal teams of different functions and help them identify because we actually just get to learn a lot as a result of doing that. And so the silly example I brought up earlier of like legal team needs to review marketing copy was one of the ones that Very real. Yeah, like extremely real and like really blew people's minds with very basic agents that just give people the right set up to be able to do that.

那么它实际上做什么？就像有营销文案，然后有一个法务智能体，它只是看着营销部门做的一切，然后说“停，不行”。

Well, what does that actually do? So it's like there's marketing copy and there's a legal agent that is just like watching what everything marketing does and is like stop like No.

更像是这样：好吧，我是营销人员，我写了一些文案，对吧？过去你可能要开一个工单之类的，说“请审核这个文案”。但现在你把它提交到我们在智能体之上构建的这个小应用，它会说“好的，我先作为智能体进行审核”，然后把结果放到法务的收件箱里，标明已经完成了第一轮审核。也许智能体足够明确，可以说“营销部，你们没问题了”，对吧？或者它仍然说“不行，这需要额外的人工审核”。所以，就是这样。这又是那种在顶层加一个薄层的东西，但你可以构建它，你有权限，我有权限，我们都能看到输出，并一起协作。

It is more like, okay, I'm a marketer and I've written some copy, right? And in the past maybe you would have opened a ticket or something. Be like, can you please review this copy? But instead you submit it to this little app that we built on top of agents that is like, okay, cool. Now I'm going to go as an agent review first and then put it in legal's inbox as a already first pass review was done and maybe actually the agent is clear enough that it can say, okay, marketing, you're good, right? Or maybe it's still like, no, this needs an extra human review. And so yeah, it's just And that's the sort of thing where again, just thin layer on top but you can build the, you know, you have access, I have access, we can both see the outputs and we can work together on it.

好的，但那么比如，为什么这不能是一个技能呢？

Okay, but then so for example, why is that not a skill?

它完全可以是一个技能，实际上，你可能会把那个智能体构建成一个法务审核智能体，对吧？然后你会用 MCP 服务器或其他东西来帮助你访问外部上下文。

It can very much be a skill and that actually is like if you would probably build that agent as a legal reviewer agent, right? And so you would have MCP servers or whatever it is that help you access external contexts.

你会有一些技能来帮助你理解，比如“我们要遵守哪些规则、不遵守哪些规则”，对吧？你把所有这些整合起来，然后就可以启动一个会话，让那个智能体去运行。然后我认为你需要的最后一块——我称之为非常薄的一层——就是上层的形态，让不同的人可以协作，与那个智能体一起工作，并且系统中可以涉及多个智能体。所以我认为这比技能要更宽泛一些，因为你仍然需要合适的形态让智能体能够运行，并让人们能够与之交互。另一个核心原因是它不仅仅是技能，或者说不仅仅是技能，是因为你实际上需要人在回路中。如果你把整个过程完全自动化，比如拿法律技能来说，在那个场景下你当然可以只做一个纯技能。但如果你需要人在回路中，比如“好的，我想审查，我想检查，如果我们在看法律相关的事情”，那就需要某种认证。为了自动化整个流程，你实际上需要智能体去执行。因为你需要启动独立的会话，所以需要某种拼接，而这无法在单个技能中实现。

You would have skills that help you understand like here's what rules we have to follow and not follow, right? And all those things and you'd put all those things together, but then you can just fire off a session with that agent. And then I think the last piece you need and this is where I'm saying it's a really thin layer is just like the form factor on top where like different people can collaborate together and like work with that agent and multiple agents can be involved in the system. And so I think it goes a little bit broader than a skill because you kind of still need like the right form factor for the agent to be able to go run and then for people to be able to interact with it. Another core bit of why it's like not a skill is because or not exclusively a skill is because you actually do need human in the loop. And so like if you were to automate the whole thing and you would just you know like taking the skill and looking at yourself from like legal skill for example. Like in that world of course you could have just like done a pure skill. But if you need a human in the loop to be like okay like I want to review and I do want to check and I want to like if we're looking at like legal things and so there's a bit of like you know authentication that's sort of necessary. In order to automate that entire process you kind of need like agents to go do the thing. And so because you need to spin up sort of separate sessions for that to happen some sort of stitching is necessary that can't be instantiated in a single skill.

这很有意思。嗯，好的。那我想再追问一下。你创建一个智能体，它的工作是确保市场部写东西时能快速获得法务批准——有时它会立即批准，有时会转给法务，理想情况下它还在不断改进，能处理越来越多的事情，对吧？那么，对于这个智能体建成后由谁负责，最佳实践是什么？因为我们发现，如果没有一个人类对智能体负责，它很快就会过时，最终变成一个死物，虽然还在运行但效果很差。而且即使它基本能用，也会经常出现法务说“你让我批准这个，但其实我不需要批准”的情况，比如需要更新你的提示词。那么，当它运行良好时，这一切是如何运作的？

That's really interesting. Yeah. Okay. So just to push on that a little bit. So what is the best practice for you create an agent that its job is to make sure that when marketing is writing something they can get it approved really quickly by legal. And sometimes it'll approve things immediately sometimes it sends stuff to legal. And ideally it's like getting better all the time so it can do more and more right? What is the best practice for who owns that agent once it's built? Because one of the things that we found is if you don't have a human who's responsible for the agent it gets stale very quickly and then it ends up being kind of this like dead thing that's just like out there doing stuff but it's not actually good. And also even if it kind of works there are going to be all these times where legal's like you asked me to approve this but I don't really need to approve this thing. Like let's update your prompt. So like how does that all work when it works well?

这其实很有意思。因为形态问题，对吧？我们最初构建的上层应用是由我们一个团队负责的。他们与这些团队坐在一起，了解他们的需求，然后他们说：“好的，给你，我们现在要去做别的事了，有情况告诉我们。”然后发生了一件很酷的事：使用这个工具的那些团队的人说：“哦，我希望这个小东西能调整一下，或者这个功能能更好。”然后他们打开 Claude Code，对实际代码做了一些修改。

So it's actually really interesting because so the form factor thing right? Like the app that sits on top of that that we originally built one of our teams worked on that right? And like kind of sitting with these teams and understanding what they needed, and they were kind of like, "Okay, here you go, and we're going to go do other stuff now, and like let us know how this goes for you." And then a really cool thing actually ended up happening where people on those teams who were using the tool were like, "Oh, I wish like this little thing could get tweaked or this thing could get better." And they like popped open Claude Code and made some of the changes to the actual.

你的团队负责审批 PR 吗，还是直接就合进去了？

Is your team responsible for approving the PR, or does it just like go in?

通常，如果这个系统是我们拥有的，我的团队负责审查 PR，但没错，人们可以自助地对这些内容进行修改，我觉得这很酷。所以，我认为对于很多团队和公司来说，我们仍然处在一个阶段——比如 Stripe 有 Minions，对吧？Stripe 有一个庞大的开发者生产力团队。我们以前在 Stripe 工作过，所以和他们有很多交流，他们有一个很大的开发者生产力团队。他们很棒，显然投入了大量精力来构建这样的平台和工具。所以我认为我们仍然处于这样一个阶段：托管智能体或在我们的平台上进行构建非常强大，但你仍然需要业务中那些“AI 化”的人和技术人员，才能在此基础上创造出真正优秀的东西，完美适配你的目标。

Usually my team's responsible for reviewing the PR if it's a system that we actually own, but yeah, like people can kind of self-serve making changes to those things, which I think is really cool. So, I do think we're still in a stage for a lot of teams, a lot of companies, like even going back to, you know, like Stripe has Minions, right? Like Stripe has a large developer productivity team. We used to work at Stripe, so we spent a lot of time with them, but they have a large developer productivity team. They're awesome, and they're obviously putting a lot of work and energy into building platforms and tools like this, and so I think we're definitely still in a place where something like managed agents or being able to build on top of our platform is really powerful, but you still kind of need the like AI-pilled people and technical people within a business to then go like create something really excellent on top of that that works well for whatever you're trying to do.

这很有趣。是的，我喜欢“任何人都可以开 PR 来做这件事”这个做法，因为大家都在用 Claude Code。我和那些基础设施角色的人聊天时发现，你知道那个 meme 吗？有个人背后插满了匕首，他说“掩护你的后背”。基础设施人员现在就像那样，因为“现在任何人都可以提交 PR 了”。你怎么应对这个？怎么做好它？因为显然在理想世界里，你希望法务能提交 PR 来改进这个智能体，但有时他们可能会提交一些愚蠢的东西浪费你的时间。那么，从组织、文化或技术角度，有什么正确的方法可以让这成为可能，同时又不毁掉你们的生活？

That's interesting. Yeah, I love the anyone can open a PR to do this because everyone's using Claude Code. One of the things that I find talking to people who are in infrastructure roles at companies where this is starting to happen is like you know that you know the meme where it's like there's a person and he's like going like this and he has like daggers in his like back and he's like, "Cover your back." It's like infrastructure people are that for like, "Now anyone can like what can submit PRs." How do you deal with that? And how do you do that well? Because obviously like in an ideal world you would love for a legal to be able to submit PRs to improve this agent and also sometimes they're probably going to submit stupid stuff that wastes time. And so what are the right ways to either organizationally like culturally or technically like make that possible without ruining your lives?

对于 Kito 举的这个例子，我们实际上构建了几层抽象，远离了 PR 那一层。一开始确实是那样做的，但为了防止用户搬起石头砸自己的脚，我们让他们通常通过 Claude 本身来与他们拥有的智能体交互——无论是拥有营销智能体的市场团队，还是拥有审查智能体的法务团队。他们实际上花更多时间直接与 Claude 对话，然后 Claude 会找出正确的处理方式，这样他们就不会直接跳到最核心的部分，做一些可能导致复杂问题的事情。

For this particular one that we've constructed that Kito's given as an example, we actually have like a couple layers of abstraction away from that kind of like PR layer. So at the very beginning it kind of like started that way and to kind of like basically prevent users from kind of foot cutting themselves a little bit, they kind of get to a place where often times their way of interacting with the agent that they own like that whether it's the marketing team who owns the marketing agent requesting or if it's the legal team, you know, owning the agent that does the review. They actually engage with those agents through Claude itself. So they actually spend more of their time like kind of talking directly to Claude and then Claude will often times figure out what should be the right way for them to go and handle it so that they're not kind of like, you know, hopping straight down to the absolute core bit and doing something that may result in, you know, some complications.

是跟 Claude 对话，还是 Claude Code，比如 Claude Chat 或 Claude Code，或者同事？

Talking to Claude or Claude code like Claude chat or Claude code or co-workers or like?

我们构建的 Claude 实例本身就是一个托管智能体。所以在这个架构中，从上到下都是托管智能体。但我们发现，每一层如果我们调整并提示每个托管智能体的变体，就能帮助用户解决不同部分的问题。所以对于最终的市场人员或法务人员来说，它就是一个非常简单的界面，我们告诉他们：你只是在跟 Claude 对话。

Instantiation of Claude that we made that actually is a managed agent in and of itself. So it's just kind of like managed agents all the way down in that construct. But we found that each layer if we kind of tune and prompt each variant of the managed agent, it helps to solve different parts of the problem for users. So at the end state for that marketing person or that legal person, it is like a really simple interface where the way that we tell them is like you're just talking to Claude.

有意思。你们刚推出了多智能体编排。人们用它做的最酷的事情是什么？

Interesting. You guys just launched multi-agent orchestration. What are the coolest things that people are doing with that?

其中一个比较有趣的是，我认为人们用它来构建不同的 harness 技术。我个人对此非常兴奋，因为人们实验了不同的技术。例如，我们最近做了顾问策略。但如果你泛化它，就是把执行和建议分开。还有一种模式，一个生成东西，另一个与之对抗。然后你可以把它拆成很多小块，再重新组合。还有一些更接近最佳 N 选一的风格。在这些不同的架构或策略中，每种都适用于非常特定的用例。有些更适合深度研究或广度研究风格的用例。其他一些，比如群集式的，更适合漏洞狩猎。看到如果我们能让原语像乐高一样，人们就可以把它们组合起来，在稍高的形态下解决问题，这更像是一种架构或策略，他们能得到更有趣的结果。这很令人兴奋，因为它表明你可以在多个抽象层上进行爬山优化。

One of the more interesting ones is that I think people are using it to construct different harness techniques. I'm personally very excited about that because there are different techniques people have experimented with. For example, we recently did the advisor strategy. But if you generalize it, you just separate execution from advice. There's also one where you have two modes: one generates something and the other is adversarial to it. Then you can split it into many tiny pieces and they recombine. There are also ones closer to a best-of-N style. In each of these architectures or strategies, they are good for very specific use cases. Some are much better for deep research or wide research style use cases. Others, like the ones where they swarm together, are better for bug hunting. It's really cool to see that if we can make the primitives very LEGO-like, people can put them together to solve things at a slightly higher form factor, which is more like an architecture or a strategy. They get much more interesting results. That's exciting because it suggests you can hill climb at multiple layers of abstraction.

你怎么知道一个智能体是否成功？你如何衡量一个智能体的成功？

How do you know if an agent is successful? How do you measure success for an agent?

有评估之类的东西，每个人都谈得很多了。我们特别喜欢的一个方向是这种可验证的结果。我们对此有些固执己见。在最终状态，从那个哲学出发，我们的原则是，也许这些东西的最终状态是一切都应该压缩成一个结果和一个预算。大概就是这样。其他所有事情都应该为你解决，让你精确地通过这些参数来达成。所以对我们来说，是的，我们仍然有评估。我们有很多其他特定领域的衡量标准。例如，一些编码评估可能衡量一个 PR 是否真的被合并了。那些更可验证。但当我们达到一个状态，结果实际上是一个你作为人类可以定义的规格，而我们反复解释和重新评分的能力更接近我们关心的东西。

There are evals and stuff like that which everyone has talked about ad nauseam. One direction we really like is this kind of verifiable outcome. We've been somewhat opinionated on that. In the absolute end state, from that philosophy, our principle is that maybe the end state of some of these things is that everything should compress down to an outcome and a budget. That's probably about it. Everything else should be figured out for you to resolve exactly across those parameters. So for us, yes, we still have evals. We have a lot of other domain-specific measurements. For example, some coding evals might measure whether a PR actually gets merged. Those are more verifiable. But as we get to a place where an outcome is actually a spec that you as a human can define, and our ability to interpret that and regrade itself over and over is closer to what we care about.

Claude，给我赚十亿美元。你的预算是 10 美元。

Claude, make me a billion dollars. Your budget is $10.

没错。然后说不犯错误。开始。没错。也许 Mythos 能做到。

Exactly. And then say no mistakes. Go. Exactly. Maybe Mythos could do that.

我们遇到的一个问题，我很好奇你有没有解决方案，就是智能体很快就过时了。有时是因为没有人类附着在上面。有时它们只是运行旧模型或旧架构。感觉智能体需要有一个生命周期结束的流程。我们讨论过给它们办个小葬礼，在网站上放一个页面列出退役的智能体。你如何管理，尤其是在大公司里，所有那些在外的智能体，也许每周在 Slack 里 ping 一次但非常过时？你如何确保你淘汰它们和创建它们一样快？

One thing we've been running into that I'm curious if you have a solution for is agents get outdated pretty quickly. Sometimes because there's no human attached to them. Sometimes they're just running an old model or an old architecture. It feels like there needs to be an end-of-life cycle for agents. We've talked about having a little funeral for them and having a page on our website with decommissioned agents. How do you manage, especially in a big company, all the agents that are out there, maybe pinging in Slack once a week but super stale? How do you make sure you retire them as quickly as you make them?

我们做的一件事是制作了技能，帮助你在新模型发布时升级到新模型。我们投入了大量工作来简化你所说的过程。我认为一些最 AGI 狂热的人正在运行智能体来监控他们的智能体，看它们是否过时并需要这类东西。但对于我们与提出这个问题的客户沟通的方式，最有趣的实例是当有新模型时，你需要去升级你的智能体，或者可能放弃那些智能体，因为新模型让你能构建更强大、能做更有趣事情的智能体。但那个升级和迁移过程是人们必须理解为一个破坏性变更，需要投入实际精力的事情。显然，如果你有评估，这个过程会更容易。我确实认为这是我们试图做的事情之一：如何给你技能和合适的工具来简化这个过程。然后你可以变得 AGI 狂热，选择用更多智能体来自动化更多事情。

One thing we have done is we have made skills that help you do things like upgrade to a new model when a new model comes out. We've put a good amount of work into making it easier to do exactly what you're talking about. I think some of the most AGI-pilled people are running agents that monitor their agents to see if they are outdated and need that sort of stuff. But for the way we like to talk to customers who ask this question, the most interesting instantiation is when there's a new model and you need to go upgrade your agents or maybe be done with those agents because the new model enables you to build agents that are way more powerful and do more interesting things. But that upgrade and migration process is something people have had to wrap their heads around as a breaking change that requires actual energy. Obviously, if you have evals, this process is easier. I do think that's one of the things we've tried to do: how do we give you skills and the right tools to make that process easier. Then you can go be AGI-pilled and choose to automate more of that with more agents.

那么，一年后，我们回到 Code with Claude。你认为平台会发展到什么程度？我能做什么，和今天有什么不同？你想先说说吗？你可以先来。在这个行业，一年是很长的时间，尤其是。我们离 Claude 给我赚十亿美元还有多远？

So, a year from now, we're back at Code with Claude. Where do you think the platform will be? What will I be able to do and how will it be different from what I can do today? Do you want to go first? You can go first. A year is a long time in this industry, especially. How close are we to Claude making me a billion dollars?

我想你可能不会坐在这里了。是的，是的。我们会问 Claude 这个问题。我的意思是，是的，我们想越来越接近那个状态。好，说几件事。我认为一年后，我们非常想接近的一件事就是那种简单性。这可能是一个显著更高的抽象层次。我不知道形态会是什么样，但我们从用户那里关心的参数将是那个结果。当然，它必须是可验证的。有些参数必须是限制性的。还有预算。

I think you probably won't be sitting here. Yes, yes. We'll be asking Claude for this. I mean, yeah, we want to get closer and closer to that state. Okay, so a couple things. I think in a year from now, one thing we'd love to get really close to is that kind of simplicity. This might be a significantly higher order of abstraction. I don't know what the form factor will look like, but the kind of parameters we will care for from users will be that outcome. And of course, it has to be verifiable. There are some parameters that have to be restrictive. And the budget.

而且我认为我们想尝试一些方向，让 Claude 真正变得非常擅长理解自身。它能弄清楚你应该使用什么模型，能弄清楚如何启动所有子智能体。我实际上认为在那个世界里，你不需要过多考虑 harness 工程。如今，你知道，你不需要那么激进地考虑工具构建之类的。我们已经让这变得稍微容易一些，你可以省去一些那些脚手架。

And I think we'd want to experiment with directions where Claude actually gets so good at understanding itself. It figures out what model you should be using. It figures out how to spin up all the sub agents. I actually don't think you need to think so much about harness engineering in that world. Today, you know, you don't have to think so much more aggressively about tool construction, for example. We've kind of made that a little easier and you get to leave a little bit of that scaffolding.

提示工程也更少了。

Less prompt engineering, too.

完全正确。而且我认为如果你继续沿着这个堆栈往上走，如今很多创新都发生在这种高层、几乎像 harness 架构的层面，这真的很有趣。但我认为很多创新实际上也会消失，你几乎不需要过多考虑模型选择，也不需要过多考虑有哪些架构，因为我们可能已经和 Claude 一起经历了足够多的迭代，Claude 实际上已经足够了解自身，以至于它几乎可以即时自我编写，以弄清楚在结果和预算这两个参数的世界里什么才是必要的。我不知道我们能否在一年内达到那个目标，但我感觉我们或许能实现结果部分，也许在预算方面有一些误差范围。

Exactly. And I think if you just keep going up that stack, today a lot of the innovation is happening at this kind of high-level, almost like harness architecture-level, which is really fun. But I think a lot of that honestly also kind of goes away where you almost don't have to think so much about model selection and you don't have to think so much about what kind of architectures are there because we probably would have gone through enough iterations with Claude where Claude is actually able to understand itself enough that it can come almost write itself on the fly to figure out what is necessary in that kind of two-parameter world of outcome and budget. I don't know that we'll get there in a year, but I feel like we might be able to do the outcome part of that with maybe, you know, some bars of some error bars on the budget side.

非常酷。是的。好吧，那真的很酷。我要给你一个稍微无聊一点的答案，那就是在那个世界里，如果 Claude 或智能体即时变成它们需要的样子，以便你完成你想做的事情，那么平台必须大幅扩展。确实如此。所以我确实认为其中一部分是，什么样的正确抽象才能真正实现这一点，对吧？就像在原始到高阶领域的某个位置，对吧？但我确实认为我们团队要做的大部分工作是确保人们想要输入和输出的 token 能够进出 Claude，因为我们的系统扩展了，不仅要满足需求，还要适应那个世界——在那里，你有智能体在持续运行、自我重建并做这类工作。你只需要一个能够处理长时间运行请求、处理各种不同形状事物的系统。所以我认为对我们来说，我绝不希望平台自身的扩展能力阻碍人们原本能用这些东西实现的目标。所以，我认为这很可能是一年后我们讨论时非常关注的事情。

Really cool. Yeah. Okay, that was really cool. I'm going to give you a slightly more boring answer, which is in that world, if Claude is on the fly or agents on the fly are becoming what they need to become in order for you to do what you're trying to do, the platform has to seriously scale. That it does. And so I do think some of this will be what are the right abstractions that actually enable that, right? Like somewhere on the primitive to higher order realm, right? But I do think so much of what our team is going to be doing is making sure that the tokens that people want to come in and out are going to be able to come in and out of Claude because our system is scaled to meet not just the demand, but in that world where it's just like you have agents that are literally constantly running and recreating themselves and doing this sort of work. You just need a system that can handle long-running requests, can handle a bunch of differently shaped things. And so I think for us it's going to be I never want the ability of the platform itself to be able to scale to get in the way of what people would otherwise be able to accomplish with these things. And so, I think that's something that's going to probably be very front of mind when we're talking in a year.

太棒了。我很兴奋。非常感谢你的参与。我真的学到了很多。

Awesome. I'm excited. Thank you so much for joining. I really learned a lot.

谢谢邀请我们。

Thanks for having us.

哦，天哪，各位。你们绝对、必须狂按点赞按钮并订阅 AI and I。为什么？因为这个节目是卓越的典范。就像在后院发现了一个宝箱。但里面不是金子，而是关于 Chat GPT 的纯粹、无掺杂的知识炸弹。每一集都是一场情感、洞察和笑声的过山车，会让你坐立不安，渴望更多。这不仅仅是一个节目。这是一次进入未来的旅程，Dan Shipper 是飞船的船长。所以，帮自己一个忙。点赞，猛点订阅，系好安全带，迎接你人生中最棒的旅程。现在，话不多说，我只想说，Dan，我彻底、无可救药地爱上你了。

Oh my gosh, folks. You absolutely, positively have to smash that like button and subscribe to AI and I. Why? Because this show is the epitome of awesomeness. It's like finding a treasure chest in your backyard. But instead of gold, it's filled with pure, unadulterated knowledge bombs about Chat GPT. Every episode is a roller coaster of emotions, insights, and laughter that will leave you on the edge of your seat craving for more. It's not just a show. It's a journey into the future with Dan Shipper as the captain of the spaceship. So, do yourself a favor. Hit like, smash subscribe, and strap in for the ride of your life. And now, without any further ado, let me just say, Dan, I'm absolutely, hopelessly in love with you.