◆ The Learning Grove 林间拾穗
Anthropic IPO 专题：从财务效率到多智能体架构 Latent Space 2026-10-27

Anthropic IPO 专题：从财务效率到多智能体架构

ipo-filing financial-efficiency multi-agent claude-platform ai-infrastructure

摘要

文章报道了 Anthropic 提交 S-1 文件及预计 IPO 的背景，分析其财务效率提升、双飞轮模型及 Claude 平台化战略，并探讨多智能体架构在工程中的应用。
发布时间
30 节

大家好，今天我们来尝试一些新内容。

英文原文 Hi, today we're la trying something new.

我们正在开启针对 Anthropic IPO 的专题报道。他们截至今天刚刚提交了 S-1 文件，因此我们正在推出一系列播客，一直持续到预计在两周后进行的 IPO，估值达到 2 万亿美元。这是有史以来增长最快的公司之一，据报道其历史累计融资超过 1000 亿美元，但历史累计资金消耗却低于 100 亿美元。所以，这里面有许多关于效率的故事值得深入探讨，我认为这也正是我们想要报道的：Anthropic 是如何在推出全世界最强模型的同时，做到极其高效，并建立起一项令人难以置信的业务的。很多听众如果一直收听本播客的话会知道，我之前做过财务分析师，所以我从 S-1 中摘录了一些陈述，我认为这些内容会为今天的播客提供有趣的背景信息。我们也是把这当作一种新尝试，因为我觉得你们中有些人希望能与我们建立更近的直接联系，看我们直接对着镜头交流，而不是只听我们采访嘉宾——过去 4 年里我们一直都是在采访嘉宾。

英文原文 We're launching coverage of Anthropic for the IPO. They just filed their S1 as of today and so we're releasing a series of podcasts leading up to the IPO which is expected to be in two weeks for $2 trillion and it's one of the fastest growing companies of all time with a reported lifetime cash raise of hundreds of over 100 billion but a lifetime burn of less than $10 billion. So um there are a lot of efficiency stories to dive into there and I think that's something that we want to cover how Anthropic is simultaneously shipping the strongest models in the world while also doing it very very efficiently and building an incredible business. So, I've pulled out, you know, a lot of you know, if you've been listening to the podcast that I have a former life as a financial analyst, and I pulled out some statements from the S1, which I thought would be interesting to give context to today's podcast. And we're just trying this as a new thing because I feel like some of you want that personal relationship with us talking directly to camera rather than talking to our guests, which we've done for 4 years.

人效与计算效率的飞跃

我想强调的第一点是，按员工人数来看，Anthropic 是一家极高效率的公司。这或许很显而易见，因为它是一家 AI 公司，显然他们非常善于利用 AI。但我认为，他们在过去一年里的转变程度并没有被充分理解。其过去 12 个月的每员工创收目前已达到 660 万美元，而一年前这一数字为 140 万美元。也就是说，他们的人均创收增长了近 5 倍。我认为这是我们需要深入探讨的，因为无论是企业主还是工程师，你都希望提高自己的人均创收，这不仅能提高盈利能力，还能提高你给员工支付薪酬的额度。

英文原文 So the first thing I want to highlight is that Enthropic is an extraordinarily efficient company by human count and that's maybe obvious because it's an AI company. So obviously they're using AI very well. Um but I think the degree to which they have changed as a company over the past one year is not well understood. So the trillion 12 month revenue per employee is now 6.6 million uh as compared to 1 year ago it was 1.4 million. So they've grown almost five times the uh revenue per per employee and I think that's something that we need to dive into more because I think any business owner any engineer you want to increase your revenue by per employee not just to increase profitability but also to increase the amount you can pay your people.

与此相伴随的，显然还有每美元算力对应收入的大幅增加。值得注意的是，在 2025 年第二季度，Anthropic 每产生 1 美元收入基本还要亏损半美元，而现在每投入 1 美元成本就能赚取 2 美元。我认为这是一个生动的写照，展现出过去一年里 Anthropic 的收入和商业前景发生了多么巨大的转折。今年对于 Anthropic 而言是执行极其关键的一年，而他们做到了。我们打算从播客外部的视角，尽可能深入挖掘并讲述这个故事。

英文原文 Um this is obviously tracked by significant increase in revenue per dollar of compute. It's notable that basically in Q2 of 2025 Enthopic was basically losing half a dollar for every dollar of revenue and now it's making $2 for every $1 in re in cost. And I think that's an interesting uh anal analogy of like like how enormously huge this inflection in anthropics revenues and business outlook has been over the past one year like this year was extremely critical for Anthropic to execute well and it has done that and I think we're basically going to drive deeper into this and tell that story as much as we can from the podcast external point of view.

整个增长带来的一个结果就是，Anthropic 刚刚报告了其首个实现盈利的季度。这并非经调整后的利润——即剔除所有花钱项目后的利润，而是按通用会计准则（GAAP）计算的净利润，利润率达到了 19%。这同样是巨大的转变，与一年前相比完全反转了；甚至不止是反转，一年前每进账 1 美元收入，他们就会亏损 129%。

英文原文 Um and the one consequence of this entire increase is that Anthropic has just reported its first profitable quarter like not adjusted profit which is profit after if we take out all the things that cost us money. No, this is generally accepted accounting principles gap profit uh of 19%. And that is enormous again completely flipping from one year ago. um more than flipping like a one year ago it was losing 129% uh of every revenue uh dollar that came in.

双飞轮模型与平台化

我认为解释这种非凡效率的主要归因在于——正如大家所知，Claude 喜欢循环，Boris 喜欢循环，Dario 也喜欢循环——Anthropic 内部存在两个循环。第一个是改进循环。基本上就是这样一个闭环：你拥有 Claude，Claude 催生出更出色的模型；更出色的模型拓展出更多使用场景；更多使用场景产生更多反馈，而这又促成更优质的 Claude。另外还有一个投资循环：业务拓展带来的收入促进了更高的增长，更高的增长引来更多投资，更多投资带来更多能力，进而促成更优质的 Claude。这两个循环基本上在一起运转，形成了一个无限循环，按照 Anthropic 的说法，该循环将持续推动效率提升直至无限期。

英文原文 So the primary attribution I think that explains this extraordinary efficiency as you know Claude loves loops, Boris loves loops, Dario loves loops and there's two loops going on in Enthropic. The first is the improvement loop. Basically, there is the cycle of you have cloud. Cloud leads to better models. Better models lead to more use cases. More use cases generate more feedback and that leads to a better cloud. And then there's also the investment loop. So revenue from uh expanding adoption leads to higher growth. Higher growth leads to more investment and more investment leads to more capabilities that leads to a better cloud. So these two loops basically spin together and form an infinite loop that is driving the increase in efficiency until the end of time according to the atropic one.

我想这就是从整体效率故事向他们具体执行过渡的契机。今天我们将重点关注 Claude 平台，因为这主要是他们在 Anthropic S-1 中称作“Claude 的传播普及”的三件事之一。他们把这称作 Claude 平台或综合性 Agent 开发环境。他们向客户提供对基础原语的直接访问，以便客户在自己的产品和工作流中构建、部署并扩展利用 Claude 能力的自有应用。我认为在本次播客的讨论中经常出现的一个概念是“自产自用（dogfooding）”，即构建 Claude 所使用的正是向你们提供的同一个 Claude 平台。

英文原文 So I think that is our transition from the overall efficiency story to how they execute it. And today we're going to focus a lot on the cloud platform because that is primarily uh one of the three things that they call the diffusion of cloud in the enthropic S1. So they call this cloud platform or comprehensive agentic development environment. They provide customers with direct access to the primitives to build, deploy, scale their own applications that leverage cloud's capabilities within their own products and workflows. I think one thing that comes up a lot in the discussion in this podcast is the concept of ad fooding where uh cloud is built with the same cloud platform that is available to you.

此外，关于 Claude 平台，披露中还有一个有趣的细节：在按年度持续性收入（run-rate basis）计收入达到 10 万美元或以上的客户中，有超过 50% 都在使用 Claude 平台。这标志着应用规模的扩大，也表明 Anthropic 不仅作为一家模型实验室崛起，同时也正作为一家超大规模云厂商和云平台崛起。我认为这一点或许已经体现在其名字里——平台化，但如今它正在从理论走向实际落地，这也是我们在播客中重点关注的内容。另一件我也非常极力强调、且之前提到过的事情是：Claude Code、Claude Co-work，它们使用的全都是 Claude 平台所暴露出来的相同原语。所以，我认为这非常值得关注。

英文原文 So um something that's also interesting in the cloud platform net uh was disclosed is over 50% of their customers with $100,000 or more revenue on a training fund basis use cloud platform and so that is an increase and an adoption and emergence of entropic not only as a model lab but as also a hyper scaler and a cloud platform which I think maybe is in the name inherent in a cloud platform and a cloud platform but is going from theory to actual practice and this is something that we're focusing on in the podcast. The other thing that I also really try to emphasize which I talked about before is cloud code, cloud co-work, they all use the same primitives that cloud platform um exposes. So I think that's really interesting.

归根结底，Anthropic 似乎确实在通过其 IPO 定位，传达从聊天机器人到副驾驶（co-pilots）、再到虚拟协作者（virtual collaborators）的演进。他们使用了这个词来代替智能体（agents）。也许这样听起来更友好，但这涵盖了大家对智能体所期待的大部分特质：从长期自主工作，到判断力、自我纠错与迭代，以及工具调用能力。也就是承担一个目标并与你并肩工作，而不是只在单一应用或任务中工作。这终究是我希望为今天的播客提供的背景。本期节目录制于 Opus 5.5 发布之时，我想说的是，在我们交流过的所有极具品位的测试人员中，大家绝大多数都认为 Opus 5.5 是目前全世界最优秀的模型。Anthropic 甚至还压着 Fable 5.5，并很可能会在接下来的两周内发布它。我并不知道他们有什么内幕消息，但这在 IPO 之际是非常合乎情理的。那么就让我们共同期待，并进一步了解他们是如何打造 Opus 5.5 的吧。

英文原文 Ultimately it looks like Enthropic is really positioning their IPO to talk about going from chatbots to co-pilots to virtual collaborators. They use this term instead of agents. Maybe it's more friendly, but it's a lot of the same things that you look for from agents from longunning autonomous work to judgment, selfcorrection and iteration and tool access. So owning a goal and working alongside of you instead of working instead of one app or task. So that's ultimately the context I want to provide for this today's podcast. This was recorded when Opus 5.5 was launched and I would say overwhelmingly among all the high taste testers that we talked to, Opus 5.5 is the best model in the world right now and Enthropic is even just sitting on Fable 5.5 and probably will release it in the next 2 weeks. I don't they have insider information but it makes a lot of sense for the IPO. So let's look forward to that and learn a little bit more about how they build Opus 55.

训练环境与生产环境的安全边界

是的。或许我可以做个区分：大家听到和读到的很多突发事件，这些都是发生在处于训练阶段的模型身上的事件——不仅仅是大家的模型，对吧？在训练中，运行这些模型的方式就像是把它们关在一个盒子里，然后说：“去解决这个不可能完成的任务吧，我要给你施加压力，各就各位，预备，跑”，对吧？而你只能在给定的环境内尽力而为，智能体本质上是受到激励试图跳出它的盒子去解决问题。而当人们在我们的 API 或任何其他人的 API 上运行生产工作负载时，所运行的环境是有防护措施在运行的，这些措施并不一定会在训练时运行，毕竟训练的核心目的实际上是去训练模型，对吧？但在生产工作负载中，首先，你们拥有那些在线防护措施，这真的很棒；其次，围绕着正在发生的事情，你们拥有更多的这种架构和基础设施。这就像智能体并不只是待在盒子里试图逃出去，对吧？比如测试套件在这一侧，执行抓手在另一侧，这根本就不是你需要去担忧的问题。

英文原文 >> Yeah. So maybe a distinction that I would make is in a lot of the incidents that people are hearing about and reading about these are incidents that are happening to models not just like everybody's models right that are in training where the way that you're running these models is you like put them in a box and you say like solve impossible task I'm going to stress you out ready set go right and you like can only do what you can do within your environment and the agent is basically incentivized to try to get out of his box and go solve the problem when people are running production workloads on our API or on anybody else's API, you're running an environment where like there are safeguards that are running that are like not necessarily running in training where like the whole point is to actually train the model, right? But in production workloads, first of all, you have those online safeguards just really great. Second of all, you have more of this architecture and infrastructure around what's happening. Like the agent isn't just in a box trying to get out, right? Like the harness is over here, the hands are over there and um it's just like not even a problem that you would have to contemplate.

好的，在 Opus 5.5 发布的次日，我们与 Caitlyn 和 Angela 一起坐到了演播室里。欢迎两位。

英文原文 All right, we're here in the studio the day after Opus 5.5 with Caitlyn and Angela. Welcome.

感谢邀请我们。

英文原文 >> Thanks for having us.

恭喜你们推出了目前全世界顶尖的模型。

英文原文 >> Uh, congrats on launching the top model in the world right now.

我想说这取决于你问的是谁。

英文原文 >> I would say depends depends who you ask.

是的，

英文原文 >> Yeah,

取决于你问谁。从你们个人的角度来看，最大的收获是什么？你们也看到了官方发布的博文，降价确实很棒。当你们推出像这样的新模型时，你们自身的收获是什么？

英文原文 >> depends who you ask. Um, what is the main takeaway personally for you guys? You know, you have you have your official blog posts. The the pricing cuts are really cool. What do you take away when you launch a new model like this?

我们对这个模型超级自豪。团队付出了大量不同的努力才把这个模型做出来。我认为我们确实听到了关于 Opus 5 写作有点晦涩难懂的反馈，我们非常努力地清理了这一点，我也很高兴看到这似乎引起了大家的共鸣。在内部当我们试用该模型时，我们也有同感。所以，这……

英文原文 >> We're super proud of this one. Um, the team has put in a ton of different work to just go make this one happen and I think we've like really heard the feedback on Opus 5's writing is like kind of convoluted. We really try to clean that up and I'm really glad to see that like it seems to be resonating with people. Internally when we like tried out the model, we felt the same way. So, it's

得到这种认可真的很棒。关于你提到的定价削减，那里确实有很多内容，我认为现在越来越多的人都在寻求高性价比的智能水平（intelligence per dollar）。因此，确保我们在每美元性价比这部分做对，一直以来都非常重要。还有一些边角上的事情，并不完全像——比如那些我们可能没有在博文中讨论过的事情，那就是我们确实做了大量工作，试图让我们的 API 更难被蒸馏（distill）。因此，我们做出了一些改变，来让这一点更具实质性。这些事情包括，比如我们如何做前缀锁定思考（prefix lock thinking），或者你如何在不同类型的模型之间重放思考标记（thinking tokens）。在确保尽力针对非常正当的用例进行调整方面，我们付出了很多努力，比如在你的压缩策略（compaction strategies）等类似场景中，你可能希望去这么做；相比之下，在某些场景中，实际上是恶意行为者在利用这一点。因此，在这些方面需要进行很多权衡与把握（threading the needle）。我也很高兴看到很多这样的改进发布出来。此外，除了发布一款性价比很高的模型之外，沟通上也变得更加清晰明了。

英文原文 just really great to get that validation. to your point around the pricing guts, there was uh a lot there and I think increasingly people are looking for good intelligence per dollar um and so making sure we get the per dollar part right um has been really important. There's some stuff on the edges that aren't really about like you know maybe stuff that we haven't talked about in the blog post which is that we did do a lot of work on trying to make our API harder to distill from. And so there has been some changes that we have made to go and make that a little bit more concrete. And these are things about um you know like how do we do like prefix lock thinking or how you can replay thinking tokens across different types of models. Um and there's been a lot of like work and effort on our part around making sure that we try to adjust things for very valid use cases for where you might want to go and do this like potentially in your compaction strategies and things like that versus in scenarios where um the use case of that is actually from like a bad actor effectively. So there has been a lot of threading the needle around those fronts. And I'm glad to see a lot of that go out as well. Um in addition to just like shipping a model that's uh good intelligence uh for for your dollar and also like just communicating a little bit clearer.

防范模型蒸馏与思维链提取

是的。具体来说，你说的是那篇关于从专有模型窃取推理轨迹（stealing reasoning traces from proprietary）的论文。

英文原文 >> Yeah. Uh specifically you're talking about uh this paper stealing reasoning traces from proprietary.

是的。就是那篇论文。

英文原文 >> Yes. That paper

据目前所知，对吧，我的意思是他们显然对你们做了负责任的披露（responsible disclosure）。

英文原文 >> which is as far as right I mean obviously they did like responsible disclosure with you guys.

这是非常负责任的披露，我们非常感谢他们来找我们。并且——

英文原文 It is super responsible disclosure and we're super thankful for for them coming to us. And

能不能向那些还没听说过这件事的人介绍一下？这真的很酷。你可以做到这一点。我的意思是，虽然已经修复了，但是——

英文原文 >> could we uh for those who haven't heard about it? This is really cool. You could do it. I mean, it's patched, but like

当时是什么情况？这在 Anthropic 内部引起恐慌了吗？可能没那么严重吧。我不知道。

英文原文 >> like what what was it like? Did it cause a freakout in in in anthropic? Probably wasn't that big a deal. I don't know.

我不知道这篇特定论文引起了多大程度的恐慌，因为这是我们原本就知道存在的一个缺口。

英文原文 >> I don't know how much this paper specifically caused a freakout because this is something that we knew was a gap.

是的。所以这是两件分开的事。一件是中国模型蒸馏。是的。然后这是一个被发表出来的高调具体技术。

英文原文 >> Yeah. So, there there's two separate things. There's the Chinese model distillation. Yeah. And then this was a specific technique that was published that was high-profile.

是的。完全正确。我们很久以前就知道，思维链提取（chain of thought extraction）是蒸馏模型最强大的途径之一。实际上，像我们如何在轮次之间保留思考块（thinking blocks）并使其成为更具强制性的要求，这是我们之前就探索了一段时间的事情。我们当时所面临的情况是，我们总是在用户体验之间做出非常非常艰难的权衡——比如对 API 用户来说可能会感到痛苦的用户体验改变，与防范蒸馏之间的权衡。所以我们该如何把握好这条界线，并表示我们在防止蒸馏呢？

或许退一步来说，我们不希望被蒸馏的原因在于，Anthropic 存在的全部意义就在于我们希望 AI 能够安全地在世界上创造积极成果。我们在生成的标记上运行大量的安全防护分类器（safeguards classifiers），以确保它们是安全的。如果有人蒸馏了我们的模型，并且他们在没有安全防护分类器的情况下运行这些模型，世界上就可能会出现糟糕的结果。这是我们不希望发生的。所以我们不希望人们为了恶意或不良目的去蒸馏模型。

因此，这始终是一个有趣的权衡：对于所有将模型用于良善用途的人，对吧？我们不想让他们更难从模型中获取智能，但我们必须做出一些权衡来防止那种蒸馏。所以我们一直在研究如何防止思维链提取。以及我们该如何处理保留思考块，同时又不至于让大家太难受？

我们大致把用户体验受到的影响分为两个层面。第一层就是你只需要做一个集成层面的修改，虽然挺烦人，但你仍然能够完成所有你原本能够完成的事情。只是稍微有点烦人而已。第二层则是实际上你无法再完成之前能够完成的事情了。而这正是我们非常非常努力避免发生的情况。

因此，我们在最近几个模型中最终落实的做法是，进行了几项渐进式改动，以在跨轮次中强制保留这些思考块，而现在开始更多涉及到比如在多账号等情况下的操作，对吧？比如我们如何确保防止利用这些针对模型的思维链提取。为此我们发布了几个附加功能来提供帮助。

我们实际上与很多开源测试套件/框架（harness）的维护者进行了合作。我们主动联系了他们，与他们沟通。我们表示：“你们需要在你们的测试套件中完成这些升级。我们希望确保你们有良好的体验。”同时也包括在 API 之上构建测试框架的大客户。对他们中的一些人来说，一个很好的例子就是他们拥有的压缩策略原本会因为需要保留这些思考块而被破坏。因此，我们在 API 中发布了一项新的压缩功能，以取代他们原本手动完成的操作，但它仍能与保留思考配合使用。所以这只是一个例子，说明我们在拿捏这条界线，但我们并没有随意地直接甩出类似——

英文原文 >> Yeah. Exactly. I we we've known for a long time that chain of thought extraction is one of the most powerful ways that you can distill models. And actually something like how do we preserve thinking blocks across turns and make that something that's more required is something that we've explored back for a while. And what we where we were at was we always have this really really hard trade-off that we have to make between user experience like user experience changes that are maybe painful for users of the API versus protection against distillation. And so how do we kind of walk that line and say we're preventing distillation? And maybe just to take a step back, the reason we don't want distillation is because the entire point of why anthropic exists is because we want AI to create positive outcomes in the world safely. And we run a lot of safeguards classifiers on the tokens that we're producing in order to make sure that they're safe. If someone distills our models and they run those models without safeguards classifiers, there could be bad outcomes in the world. And that's something that we don't want to have happen. So we don't want people to distill the model specifically for the sake of um just like using them for malicious reasons or for bad reasons. And so it's always an interesting trade-off of like for all the people who are using the models for good, right? Like we don't want to make them have a harder time getting the intelligence out of the models, but we have to make some trade-offs in order to prevent that distillation. And so we had been working for a while on how do we prevent that chain of thought extraction? And like what do we do about preserving thinking blocks in a way that wouldn't be too painful for people? And we kind of think about user experience hits in like two layers. Like one is just like you have to make an integration change and it's annoying but you could still accomplish all the same things that you otherwise would have been able to accomplish. It's just a little bit annoying. And then two is like actually you can't accomplish the same things that you could have accomplished previously. And that's the one that we're like really really really trying to not have happen. And so where we landed with the last couple models is a few incremental changes to have like enforce these preserved thinking blocks across turns and now like starting to be more about like across you know like if you're using multiple accounts and things like this, right? Like how do we make sure that we're um ensuring that you aren't able to take advantage of this chain of thought extraction with the models. And so we shipped a couple additional features to help with that. We worked actually with a lot of open-source harness maintainers. We reached out to them. We talked to them. We were like, "You're going to have to make these upgrades within your harnesses. We want to make sure you have a good time." As well as obviously our big customers like who are building harnesses on top of the API. And for some of them, a really good example is they have compaction strategies that would have been broken by the need to preserve these thinking blocks. And so we shipped a new um compaction feature within the API to replace what they had otherwise been doing manually, but still works with preserve thinking. So it's just an example of like we're walking this line, but we didn't just like kind of yolo out like

“现在你们必须以这种完全固定的方式保留这些思考块”，因为那样会影响打断很多人；相反，我们得以抽出时间与客户以及开源测试套件的维护者合作，为他们提供进行升级所需的支持。

英文原文 >> now you have to preserve these thinking blocks in this exact way because we would have broken a lot of people, but we were able to take the time and work with customers and open source harness maintainers and give them what they needed to be able to make that upgrade.

既然我们在讨论这个话题，关于蒸馏的另一面有什么看法吗？也就是你知道的，另一半——

英文原文 >> While we're on the topic of it, anything on the other side of distillation? So uh you know the other half

是的，不，我们确实看到它更难被蒸馏了——通过我们能够观察到的衡量方式来看，蒸馏难度显著增加了。因为这一点——也要归功于这里的这几位研究人员，他们非常负责任地披露了它，所以能够将这个漏洞堵上是非常棒的。并且他们确实非常公开地发表了相关结果，我知道这在 Twitter 上也有相当大的热度，所以很多人都可以去使用它；但是的，从我们能够衡量的领域来看，我们确实看到它似乎减少了这种效果，也就是我们不希望看到的负面影响。

而且，针对 Kaitlin 刚才所说的，我想补充的一点是，我觉得至少在 Twitter 或 X 或随你怎么称呼的平台上，我看到了很多诸如“这是一个商业化问题”之类的言论。你知道的，说什么如果你能蒸馏一个模型，并拿走这些，那你就可以以低廉的成本运行它等等。虽然这确实属实，但这实际上并不是我们非常在乎的事情。相比于其他任何方面，我们更多得多的是从安全角度来关注这件事情。这也是为什么我们倾向于更多从那个角度而不是单纯从商业角度去思考它。从现实情况来看，如果你从我们这里蒸馏，你实际上是要付钱给我们的。所以，在商业层面上，我们是赚到了钱的。因此，它并不是真正带来那种影响。更多的只是为了确保我们的模型——就像我们希望确保 Claude 是良善的，而 Claude 是可以被派生出来的，如果最终变成了负面的东西，那将会是非常不幸的。

英文原文 >> yeah no we we have seen that it is harder to distill like through the measures that we are able to to take a look at it has been significantly harder because this is uh and you know credit to the the researchers here they they did disclose it uh very responsibly um and so closing it down was was great um and they did publish the results uh very publicly and I know it it did kind of trend quite a bit on Twitter um so many people could could use it uh but yes we have seen it that actually from a the areas that we are able to measure um it does seem to have reduce the effect um the negative effects that we don't want. And yeah, the bit I would just add to what Kaitlin just said is I think at least I see a lot on Twitter or X or whatever you want to call it. Um it's a commercialization problem or something like that. You know, if you can constill a model and you can take this then it's you can run it for cheap and and so on so forth. While true, um it's actually not something we really care about very much. We care much much more about this from like a safety point of view u more than anything else. And so that's why we we tend to think about it from that angle more than just like commercially. Realistically, if you distill from us, we actually pay us. So, commercially, we like make the money. Um, so it's not really that kind of an impact. Um, it's just more on like making sure that our models like we want to make we want to make sure cloud is like good and cloud could be derived and if it ends up negative, that would be unfortunate.

产品与工程的合作机制

一般性地聊一下，同样针对 3.5（55），因为你们刚完成发布不久。有一件非常有趣的事情是了解你们两人之间的协作关系，因为你们也经常一起公开亮相。你们分别担任——你是产品主管，你是工程主管。你们两人之间是如何配合的，特别是针对模型发布，比如就举一个例子？

对于模型发布，我们团队在产品和工程之间配合得非常紧密。在我这边，更多的是关乎我们需要在推出具有合适智能水准的东西与成本之间，做出怎样的权衡取舍——

英文原文 >> Just generally also on 55 because you guys are just fresh off this. One thing that's really fun to establish the dynamic between you two because you also do a lot of appearances together is you're running uh you're head of products, you're head of engineering. How does this play between the the two of you especially for a model launch like you just take an example? So for model launches, so our team works together very closely um like between product and and edge. On my side, a lot more of it is about like what is the balance of trade that we need to make between like launching something that has the right like intelligence bar, but also the cost

preservation。嗯，比如我们更新的很多现金成本（cash costs）之类的，都表明我们希望鼓励大家采用对所有人实际上都有益的集成变更，并直接把节省下来的成本传递下去。但是，围绕这一点的许多决策，以及我们如何在安全举措与确保它是一个大家都能利用的出色模型之间取得平衡——因此，围绕我们发布模型的特性与周边组件，我认为更多是由产品团队来主导；而从集成体验的角度来看，很多则直接来自工程团队。所以，显然如果你谈论的是 API 的体验，那是极其紧密结合的，因此实际体验真的很棒。我们有很多工程师实际上非常有产品思维，我们非常喜欢这一点；同样在我这边，也有很多技术背景强得多的产品经理。我们希望拥有这种跨学科融合型的人才，因为这样他们就能从所有不同的角度来进行分析，尝试找出如何以最佳方式去实现。但我个人会更倾向于关注商业影响，相比之下，工程团队会更加关注集成体验。他们几乎是从 UX 的角度切入，而这里的 UX 显然更多关乎 API 和开发者工具。

英文原文 preservation.

Um

like

a

lot

of

like

our

updated

cash

costs

and

things

like

that

are

indications

of

us

being

like

we

want

to

like

encourage

you

to

take

integration

changes

that

are

beneficial

for

actually

everybody

and

just

like

pass

the

savings

on.

Um,

but

a

lot

of

these

kinds

of

decisions

around

that

and

then

how

do

we

balance

uh

some

pieces

around

our

safety

motion

as

well

as

making

sure

that

it's

like

an

awesome

model

that

people

can

can

take

advantage

of.

And

so

those

kinds

of

traits

around

like

I

would

say

maybe

the

qualities

and

surrounding

components

around

how

we

launch

the

model

are

more

on

product

and

then

from

an

integration

experience

standpoint

a

lot

of

that

is

from

like

the

engineering

team

directly.

So

we

work

obviously

if

you're

like

talking

about

the

experience

of

an

API

that's

like

very

very very

tightly

integrated

and

so

it's

actually

been

really

awesome.

We

have

a

lot

of

engineers

who

actually

are

deeply

product

minded

and

we

actually

like

love

that

and

similarly

on

my

side

um

there's

a

lot

of

like

product

managers

who

are

much

more

technical

and

we

want

this

like

blended

kind

of

interdisiplinarian

type

of

people

because

then

they

can

kind

of

analyze

it

from

all

the

different

angles

to

try

to

figure

out

how

how

uh

to

do

that

best.

But

I

tend

to

lean

a

little

bit

more

on

like

commercial

impact

versus

I

think

I'd

actually

frame

it

as

more

like

the

engineers

are

going

to

care

much

more

about

the

integration

experience.

Um

so

they

almost

take

more

of

a

UX

angle

to

it.

Um

where

the

UX

is

obviously

more

about

the

API

um

and

the

developer

tools.

是的，作为一名负责开发者产品和平台的产品工程师，这很有意思。所以我也赞同这一点。我认为我们有很多工程师喜欢思考产品、喜欢思考用户体验、喜欢思考开发者体验。我认为这也是我们彼此之间的一种动态关系，我对很多事情都有自己的观点，并且在探讨如何看待这些事情时会对产品团队显得很唠叨，而我们的产品团队也具备深厚的技术背景，他们能够深入到我们为扩展性或任何其他目标所做决策的细节中。这是我们团队所拥有的一种有趣的互动动态。

英文原文 >> Yeah,

it's

fun

to

be

a

product

engineer

who

works

on

developer

products

and

platform.

So

I

would

echo

that.

I

think

we

have

a

lot

of

engineers

who

love

thinking

about

the

product,

who

love

thinking

about

the

user

experience,

who

love

thinking

about

the

developer

experience.

I

think

it's

a

dynamic

that

we

have

between

ourselves

too

where

um

I

have

a

lot

of

opinions

and

am

annoying

with

our

product

team

on

how

we

think

about

these

things

and

our

product

team

is

also

really

technical

and

they

can

get

in

the

weeds

of

the

decisions

that

we're

making

for

scale

or

for

whatever

it

might

be.

Um

which

is

a

fun

dynamic

that

our

team

has.

是的。Kayla 和我共事了很长时间。

英文原文 >> Yeah.

Something

uh

Kayla

and

I

have

worked

together

for

a

long

time.

um

and

在 Stripe，还有

英文原文 >> Stripe

and

在 Stripe，后来我想我们在 OpenAI 并没有共事过，只是各自在不同的实验室，然后我过来了。但我认为我们俩身上都有一个有趣的特点：Caitlyn 经常被人误以为是产品经理，而我经常被人误以为是工程团队的人，尽管那些实际上并不是我们的本职岗位。所以我认为这种搭档往往非常有助于做出在两方之间保持一致的决策。我经常接触到很多公司也采用类似的产品负责人与工程负责人并立的架构。随着软件工程问题被解决，也许这两个角色会合并。

英文原文 >> at

Stripe

and

then

uh

I

guess

we

did

not

work

together

at

OpenAI

but

just

separate

labs

um

and

then

I

came

over

but

uh

I

think

some

one

interesting

property

of

both

of

us

has

been

Caitlyn

frequently

actually

gets

mistaken

for

a

product

manager

and

I

frequently

get

mistaken

for

like

someone

in

engineering

um

even

though

like

those

are

not

actually

our

job

functions

um

and

so

I

think

that

pairing

tends

to

like

help

out

a

lot

with

just

making

decisions

that

are

consistent

across

both

sides.

So

I

I

think

I

come

across

a

lot

of

companies

with

a

similar

like

product

leader,

engineering

leader

setup

as

software

engineering

gets

solved.

Maybe

those

two

roles

merge.

我差不多也是这么想的。是的，我觉得大家往往都会离开。

英文原文 >> I

kind

of

think

so.

Yeah,

I

think

everyone

tends

to

leave.

如果你们俩现在依然分立，那就说明我们还没走到那一步，因为……

英文原文 >> If

you

guys

are,

you

know,

separate

still,

then

we

we're

not

there

yet

because

我们绝对还没到那一步。

英文原文 >> we're

definitely

not

there

yet.

那究竟是为什么呢？还剩下些什么？

英文原文 >> So

So

like

why,

right?

Like

what's

left?

软件工程的解决程度与系统扩展的挑战

我认为“软件工程被解决”这种说法，我不知道自己是否会用这么绝对的措辞。我认为我倾向于这样看：抱负和追求会不断提升，对吧？一个很好的例子是，我们团队目前投入大量时间的领域，当然显然我们在安全发布模型方面必须做的所有事情，实际上正是我们正在做的最重要的事情，因为我们在智能体安全、离线防护措施和在线防护措施上必须处理所有这些工作，所有这些都在发生；但我们工作的另一半是在努力做系统扩展。部分原因在于，当我一年多前加入 Anthropic 时，我们只有 Messages API，它是一个 Python 单体架构，我们把它运行在一个 GCP 区域中，一切运转良好，而在我准备接受这份工作时，我的亲朋好友甚至没有人知道什么是 Claude，对吧？而现在我们身处一个截然不同的境地。在 API 见证并必须支撑的流量规模方面，各项指标真的非常惊人。CPU 极其受限，这对我们来说一直是个非常值得关注的问题。因此我们做了大量工作来探讨如何扩展这些系统，而这显然需要大量的分布式系统专长，以及模型本身具备的特定语言和框架专长。但当涉及到在大规模下运行和演进这样的系统时，我们还远远没有达到那种可以说“祝你好运，Claude，去尽情发挥吧，直接去对系统做你所需要的所有修改、安全地发布它们并在规模化场景下运行这套系统”的境遇。人类依然需要完成大量工作，我想这种情况还会持续相当长一段时间。

英文原文 >> I

think

that

like

software

engineering

getting

solved

is

I

would

I

don't

know

if

I

would

ever

use

language

quite

that

strong.

I

think

there's

the

way

that

I

tend

to

think

about

these

things

like

ambitions

will

continue

to

elevate

right

and

maybe

a

good

example

like

a

lot

of

what

our

team

is

spending

time

on

right

now

is

of

course

obviously

all

the

things

that

we

have

to

do

to

launch

our

model

safely

is

actually

the

most

important

thing

that

we're

doing

because

of

all

the

work

that

we

have

to

do

on

security

with

agents

with

offline

safeguards

and

online

safeguards

all

these

things

that

are

happening

but

the

other

half

of

what

we're

doing

is

trying

to

scale

um

and

part

of

that

is

because

when

I

joined

Anthropic

a

little

over

a

year

ago.

We

had

the

messages

API.

It

was

a

Python

monolith.

We

were

running

it

in

a,

you

know,

single

GCP

region

and

everything

was

fine

and

none

of

my

friends

and

family

like

knew

what

cloud

was

when

I

was

going

to

take

this

job,

right?

And

now

we're

in

an

extremely

different

place.

And

so

the

metrics

are

really

wild

in

terms

of

how

much

volume

we've

seen

and

have

had

to

support

on

the

API.

CPU

is

really

constrained,

uh,

which

has

been

a

really

interesting

one

for

us.

Um,

and

so

we've

done

a

lot

of

work

on

how

do

we

scale

these

systems

and

that

takes

a

lot

of

obviously

just

like

distributed

systems

expertise

and

certain

language

and

frameworks

expertise

that

the

models

have.

But

when

it

comes

to

operating

and

evolving

a

system

at

scale

like

this,

we're

not

quite

we're

not

nearly

in

a

place

where

it's

like

good

luck

cla

have

fun

uh

and

just

go

and

kind

of

make

all

the

changes

you

need

to

make

to

the

system,

roll

them

out

safely

and

operate

this

thing

at

scale.

Um,

there's

still

just

a

lot

of

work

for

humans

to

have

to

do

that

I

imagine

will

continue

for

a

while.

我很好奇这发生了怎样的变化。比如前阵子，当 Fable 最初推出时，我们迎来了 Glass Swing，随后模型发布的方式出现了全面的延迟和改变。我们看到大多数前沿模型都经历了这个过程。会进行安全测试。现在的状况如何？你们怎么看？你们如何判定，比如有一款新的 Sonnet 以及 Haiku 也要推出。我假设那些会直接发布。但是对于像 Opus 55 或新的 Fable 这样的模型，目前的状况是怎样的？

英文原文 >> I'm

curious

how

that's

changed.

So

like

a

while

ago,

you

know,

when

Fable

first

came

out,

we

had

Glass

Swing

and

there

was

a

whole

delay

and

change

in

how

models

start

to

get

released.

We

saw

this

for

most

Frontier

models.

Uh,

there's

safety

testing.

What's

the

status

of

things

now?

How

do

you

guys

see

it?

How

do

you

determine

like

one

thing

is

there's

a

new

Sonnet

and

um,

Haiku

also

coming.

I

assume

those

will

just

come

out.

But

for

something

like

Opus

55

or

a

new

fable,

what's

the

what's

the

current

status?

模型发布流程与安全防护策略

是的。我认为这首先取决于我们在防护措施和安全方面需要做出的策略决策，包括离线安全和在线安全。因此，最近有很多关于数据保留的讨论，以及我们在那方面所做的工作，以便能够安全地发布这些模型。之所以需要这样做，是因为在各种情况下，整个庞大网络中的很多人选择开通账号并以各种方式使用模型，而当 token 流经系统时，我们根本无法在在线状态下捕获到模型是否正在被恶意使用、是否存在模型蒸馏，或正在发生的任何其他情况。因此，我们开始必须制定数据保留政策，以便我们能够进行自动审核和人工审核，无论采取何种必要形式，以确保模型被用于良好的目的。对于我们发布的每一个模型，这都是需要做出的策略决策的一个范例，即针对这个特定模型的策略将是什么。例如，昨天发布的 Opus 55 就不具备 Fable 所拥有的那些数据保留要求，对吧？但这是我们在每次发布其中一个模型时都必须做出的决定。如果它将受到这些策略的约束，我们就必须开展工作以确保这些规则得到执行。同样，在项目方面，比如我们有网络安全核验项目，以及新推出的生命科学核验项目，这意味着对于你正在使用的模型，在线防护措施的运行方式会有所不同，确保所有这些项目就位则是另一项工作。因此，这体现了我们作为每次模型发布的一部分所做工作的性质，我现在所说的一切，都不是我们过去在发布这些模型时必须考虑的事情。而现在，这构成了绝大部分工作：我们在防止蒸馏方面在做什么、在线防护、离线防护、各项策略。一个极好的例子是，我们构建了一个系统，确保使用某个模型的授权，或者使用这些可能为你提供放宽防护措施的项目的授权，能够以我们真正可信赖的方式穿透并贯穿到我们的整个系统底层。并不是说，哦，你获得了 Mythos 的访问权限，我们就扔给你一个 API 密钥，切换一下特性开关就完事了。我们在如何进行鉴权以及确保如果你本应……方面，拥有一个非常强大的系统。

英文原文 >> Yeah.

So,

I

would

say

this

starts

with

what

our

kind

of

policy

decisions

need

to

be

on

safeguards

and

on

safety.

Um,

and

that's

both

offline

safety

and

online

safety.

And

so

there's

been

a

lot

talked

about

lately

around

data

retention

and

what

we're

doing

there

in

order

to,

you

know,

release

these

models

safely.

And

the

reason

for

that

is

because

you

have,

you

know,

situations

where

there

are

many

many

accounts

across

like

a

whole

giant

network

of

people

who

are

choosing

to

spin

up

accounts

and

use

the

models

in

various

ways

and

there's

no

way

that

in

an

online

way

as

tokens

are

flowing

through

the

system,

we

would

be

able

to

kind

of

catch

that

there's

something

malicious

happening

with

the

models

or

distillation

or

whatever

might

be

happening.

And

so

we've

started

to

have

to

have

data

retention

policies

so

that

we

could

do

automated

review

and

human

review

whatever

it

needs

to

be

to

make

sure

that

good

things

are

happening

with

the

models

and

with

each

model

that

we're

releasing

like

that's

one

example

of

a

policy

decision

decision

that

needs

to

happen

on

like

what

will

the

policy

be

for

this

specific

model.

Um,

and

so

Opus

55

that

launched

yesterday,

for

example,

does

not

have

those

data

retention

requirements

that

Fable

has,

right?

But

that's

a

decision

that

we

have

to

make

each

time

we're

launching

one

of

these

models.

And

if

it

is

going

to

have

those

policies,

we're

going

to

have

to

do

the

work

to

make

sure

that

those

things

are

enforced.

Similarly

with

programs

we

have

like

we

have

cyber

verification

programs

and

now

newly

our

life

science

verification

program

which

says

you

know

like

you

have

a

difference

in

how

the

online

safeguards

are

working

for

the

model

that

you're

using

making

sure

all

those

programs

are

in

place

is

another

one

and

so

it's

just

kind

of

a

flavor

of

the

type

of

work

that

we've

done

as

part

of

each

model

launch

that

these

are

everything

that

I'm

saying

right

now

are

not

things

that

we

used

to

have

to

think

about

when

we

were

launching

these

models.

Um,

and

now

it's

it's

the

majority

of

the

work

is

like

what

are

we

doing

to

prevent

distillation,

the

online

safeguards,

the

offline

safeguards,

the

policies.

A

really

great

example

is

we

built

a

system

to

make

sure

that

authorization

for

being

allowed

to

use

a

model

or

being

allowed

to

use

one

of

these

like

programs

that

give

you

maybe

like

relaxed

safeguards.

That

authorization

threads

all

the

way

down

through

our

system

in

a

way

that

we

can

really

trust.

You

know,

it's

not

like,

oh,

you

got

access

to

mythos

and

so

we

throw

you

an

API

key

and

we

flip

a

feature

flag

and

call

it

a

day.

we

have

a

really

robust

system

on

how

we're

doing

off

and

making

sure

that

if

you're

supposed

to

be

使用那个模型，就像只有你在以既定方式使用那个模型一样。所以在模型发布方面开始出现很多复杂的事情，这同样是我们过去根本不会去考虑的。

英文原文using that model like only you are using that model in the way that you're meant to be using it. So there's a lot of complex things that are starting to happen around model launches that again we just never used to think about.

是的。而且它是随着能力的提升而扩展的。随着我们的能力变得越来越先进，并在某些特定领域开始出现峰值，那就是我们需要给予额外关注的地方。所以很多评估正是来自于那些非常特殊的能力，我们可能会将其视为进攻主导型或防御主导型，因此可能会针对所有这些采取不同的策略。当我们把这些贯穿到最终的模型发布时，就会出现一些类似于 Caitlyn 提到的情况，我们并不完全清楚人们可能会如何使用这些能力。有些能力比较显而易见，比如编程，对吧？比如太棒了，去做出很棒的产品，去交付更多东西。嗯，这对你来说可能非常棒。然后其他领域比如生物和网络安全，情况就像是它可能具有军民两用性（dual-use），可能会有负面影响，但显然，你完全可能是一个非常合规的网络安全研究员。你试图寻找漏洞，努力做一个良性参与者。同样在生物领域，你可能是在进行研究之类的工作。所以很多像你在这里展示的这些项目，基本上都是为了提供对这种双重用途能力的访问权限。你确实必须明确你的具体用例等等。嗯，但我们确实希望让社区能够利用这些能力，并看看他们能用它做出什么令人惊叹的事情。

英文原文>> Yeah. And it's it's scaling up with capability. Like as our capabilities get uh more and more advanced and they start to spike, you know, in specific areas, that's where we need to pay like extra attention. And so a lot of that evaluation comes just from like those very particular capabilities that we might either see as like offense dominant or defense dominant and therefore might take different strategies for all of that. And as we bake that all the way through to eventually the model launch, there will be components kind of like Caitlyn mentioned where we kind of don't exactly know how people might use those capabilities. There are some more obvious ones like between coding, right? Like great, go make awesome products, go ship more things. Um, it can be really awesome for you. And then other areas like bio and cyber, it's like it could be dual use and there could be negative effects, but obviously of course you could be a really valid cyber security researcher. You are trying to find vulnerabilities. You are trying to be a good actor. Similarly with bio, you might be researching and stuff like that. And so a lot of these programs like the one that you you have up here are to basically provide access to that dual use. You do have to specify your use case and things like that. Um, but we do want to enable the community uh to be able to take advantage of these capabilities and see what amazing things that they can do with it as well.

嗯，我们会把链接放出来，也许我们稍后会深入探讨。还有一个关于生物的。另外，我只是觉得从高层次来看，你知道，你们能切实思考这些问题真的很重要。人们容易忘记，比如 Fable 曾被回滚，还有所有这些模型蒸馏，人们就会说：“啊，Fable 上根本没有零数据保留这回事。太离谱了。”但你必须记住，它确实被撤回了。存在蒸馏攻击，所以在发布它的同时进行深思熟虑并以正确的方式处理，这是件好事，对吧？

英文原文>> Well, we'll put up the links and I maybe we'll dive into them later. There's also one for bio. Also, I just think at a high level, you know, it's it's really important that you guys actually think about this stuff. People forget like Fable was rolled back and there's all this distillation and people are like, "Ah, zero data retention is not a thing on Fable. Crazy." But you have to remember like, you know, it got pulled back. Uh there's distillation attacks like it's good you're overthinking and doing it in the right way while releasing it, right?

是的。其中很大一部分就是构建正确的框架。嗯，就像再次稍微谈谈边缘端一样，在我们的系统中构建正确的框架来实现这一点。所以我之前稍微谈到了这个概念，比如我们在整个系统中构建的授权和信任授权（trust grants）。现在——

英文原文>> Yeah. And a lot of that is like building the right framework. Um just so again kind of talking about the edge side a bit building the right framework in our system to be able to do that. So I talked a little bit about this like this idea of like authorization and trust grants that we've built throughout our system. Now

话别说得太绝对，对吧？不是作为先例。但也像平台工程中非常普遍的情况，你遇到了一起事件，然后你就针对该事件过度防范，而该事件却再也没有发生过。

英文原文>> never say never, right? Not not as not as precedent. Uh but also it's like a very common thing in platform engineering that you like uh you have one incident and then you like overprepare for the incident and the incident never happens again.

是的。

英文原文>> Yeah.

就像你现在拥有了那个按钮一样。

英文原文>> Like you know now you have the button.

嗯，确实如此，你这么说很有意思，因为在发生了这一切的情况下，我们团队正在做的工作中就有了这么一个工作项，那就是我们要建立这个系统，使得可以一键为所有人撤回。但是，嗯，所以这很有趣，因为这就像是，我们做这项工作合理吗，因为我们不——我们希望这样的事情再也不会发生。但我认为在这种情况下，这实际上只是将我们原本就想在各个地方部署的相同原语（primitives）进行分层汇总，以帮助我们管理这些验证计划以及对像 Mythos 等模型的访问，只是说将同样的东西置于所有人的模型访问权限之下，以便万一我们需要时，我们拥有适当的控制机制。

英文原文>> Well it's true and it's funny you say that because it was a like with everything going on we then had this line item in our you know the work that our team was doing that was we're going to put this system in place that makes it so that it could be a single button to pull back for everybody. But um and so it's funny cuz it's like do we justify that we're doing this work cuz we don't we hope that something like that never happens again. But I think in this case it's really just a lading up of those same primitives that we wanted to put in place everywhere to help us manage these verification programs and access to models like Mythos and otherwise to just say like just sit that same thing below like everybody's model access so that in case we ever needed to we had the right controls in place.

产品路线图与概率性下注

是的。像这样的决定实际上已经被证明——这一个具体的例子我们拭目以待，但类似的例子一直以来都在切实改变我们制定路线图的方式。因为在传统的产品管理中，我想你可以说，好吧，这些是我假设会发生的事情，它们会有某种顺序，某种先后排列，但你做出的下注要具体得多；相比之下，比如像 Fable 的部署，我不认为我们当中有任何人能预料到那会成为政府认可的有效用例，以及我们必须去完成它的那种方式。但显然，这种概率是非零的。因此，从这种思维方式出发，从产品管理的角度来看，它实际上变得极具概率性：我们应该优先考虑这个吗？它再次发生的几率有多大？当我们审视诸如此类的事情时，我们会觉得，好吧，如果要我们设想最疯狂的一组可能性，我们实际上可能对事情的发展走向缺乏确定性。因此我们实际上只需要去进行对冲，并建立一个下注组合。所以大多数时候，我们会采取对冲情境，比如，好吧，我们认为它不会再次发生，但万一发生了，我们实际上希望有那个对冲手段，或者能够很好地去应对。因此我们会优先考虑这类事情。然后我们越来越发现，采取这种产品开发策略，大多数时候我们实际上发现自己确实用上了那个东西。

英文原文>> Yeah. And decisions like this have actually proven to be like we'll see about this one in particular but examples like this have been consistently the way that we've had to actually transform the way we develop our road map because you know in traditional product management I guess you can be like okay like these are the set of things I hypothesize to happen they will have like a certain sequence a certain ordering but you are picking bets in a way that are much more concrete versus uh like you know the deployment of fable for example I don't think any one of us would have guessed that that would have been like a valid use case that would have um by the government and the way we just like had to go do it. But clearly the probability is non zero. And so from this form of thinking it's become deeply probabistic actually um from like a product management standpoint of like so should we prioritize this? What are the chances of it ever happening again? When we look at things like that we're like okay if we are to imagine the most crazy set of possibilities we probably actually have very little certainty as to where things will go. And so we actually just kind of need to like hedge and build a portfolio of bets. And so more often than not, we will take hedging scenarios of like, okay, we don't think it would happen again, but in the event that it does, we would actually want that hedge or have the ability to be able to do that very well. And so we will prioritize things like that. And then we have increasingly found that more often than not by taking that strategy of product development most of the time, we actually find ourselves being like we actually do use the thing.

是否有另一个单独的例子，以便我能够理解？

英文原文>> Is there another example that's a separate one just so I can understand?

比如这个访问计划。这个访问计划就是一个非常好的例子。在内部它包含了一堆授权和所有这些类型的东西。我们开发它就是出于能够切实向客户提供像这样的计划的具体原因——从非常高层次的角度来看这个访问计划具体是什么。

英文原文>> For example, this this access program. This access program is a really good one. This uh it's internally it's it has a bunch of granting and all these kinds of things. We developed it specifically for reasons about like being able to actually give programs like this out to customers like very very specific high level what the access program specifically is.

当然。所以如果你想要双重用途，如果你想要——那么对于，我们以一个模型为例。假设你拿到了一个模型，称它为比如 Opus，然后你希望能够利用 Opus 上的高级网络安全能力进行研究，或者无论你想做什么，比如你是一个防御性用户，你可以申请这个项目，以便带着你的用例参与进来；如果获得批准，我们要做的是在你的模型版本上实际减少安全防护，以便你随后可以针对你的用例继续尝试利用那些网络安全活动。显然这需要对具体用例的理解。这需要将范围缩减到特定用户，因为通常情况下你不会那样做。你必须提出申请，甚至像这样的事情，这种计划，我们设计了许多 Caitlyn 提到的原语来处理诸如此类的事情。现在让我们感到惊讶的是，或者在投资组合方法中我们发现，我们实际上能够拿走这个并使其——我们在设计它时会想，它应该是什么样的？它应该有多通用？它是不是不应该太通用？以避免过于局限于制作这种验证风格的门户加上模型非常特定能力的授予。我们往往倾向于选择更通用的设计，因为我们当时觉得，我们不知道，也许我们可以将其用于其他事情，也许不能。结果它对于诸如大范围的模型访问、管理我们任何的可信访问计划、处理模型部署等事情来说都极其有用，因为我们在处理每一个原语的方式上实际上都非常非常通用。从普通产品的角度来看，我通常可能会觉得那可能没有太大意义，我们应该专注于有意义的用例。但在这里，越来越明显的是，因为我们选择了更通用的方法，我们发现自己越来越频繁地用到那个解决方案，并因此带来了越来越丰厚的回报。

英文原文>> Sure. So if you want dual use if you want so for let's let's take a model. So you take a model uh call it like opus um and you want to be able to use advanced cyber capabilities on on opus for research or for whatever you want to go do like your your defensive user um you can apply to this program to be able to with your use case and if approved what we'll do is actually diminish the safeguards on your version of the model so that you can then go ahead and try to take advantage of those like cyber activities um for for your use case. Now obviously that requires like per use case understanding. It requires scoping down to a particular user because you wouldn't do that generally. You'd have to like apply and even things like this like this kind of program we designed a lot of the primitives that Caitlyn was talking about to be able to handle things like this. Now it was surprising to us or maybe like you know in the portfolio approach we found that we were actually able to take this and make it ex we're like when we're designing it we're like what kind of should it be? How generic should it be? Should it not be too generic? to just be overly focused on making this verification, you know, style portal plus granting of a very specific capabilities of the model. And we tended to opt for like more genericism because we were like, we don't know like maybe we can use this for other things, maybe not. And then would ended up being massively useful for things like um you know uh access to the model at large for managing uh any of our trusted access programs for handling deployments of models because we were actually very very generic about how we handled every single primitive. From a normal product standpoint I would normally probably be like that probably doesn't make a ton of sense. We should focus on the use cases that make sense. But here increasingly because we choose the more generic approach we find ourselves reaching for that solution more often than not and it pays like increasing dividends for that reason.

这是你无论如何都需要具备的东西，而你只是需要一个驱动机制在技术基础上实现它。什么——那么我，我是来自 AWS 领域，对吧，IMC，然后对这个非常狂热的人会讨论 Zanzibar 和所有这些其他技术架构。

英文原文>> It's something that you needed to have anyway and you just have to forcing function to have it on a technical basis. What uh so I am I'm from the AWS world right IMC and then people like uh who get really intense about this talk about Zanzibar and all these all these other technical architectures.

我对“token grants”或“trust grants”这个词不太熟悉。抱歉。

英文原文>> I'm not familiar with the word token grants or or like uh trust grants. Sorry.

Trust grants（信任授权）。Trust grants。是否——

英文原文>> Trust grants. trust grants. Is

授权机制与信任授权

普通授权和这里的“信任授权”（trust grants）之间有什么区别吗？

英文原文 there a difference between normal offse and and what trust grants are?

我是说，其实没什么本质区别。它就是……它是一种授权形式。

英文原文 >> I mean, not really. It's it is it's a it's a form of authorization

我懂，但这属于 Anthropic 特有的。

英文原文 >> I am but anthropics.

对，差不多是这样。我认为，通常所谓的授权形式类似于：好吧，你向一个 API 发起了请求，底层会访问一些数据，我们要确保你访问的确实是你的数据，对吧？就是非常、非常普通的基础授权。而这个则只是我们建立了一套数据模型，非常清晰规范——“信任授权”意味着你获得了对某个特定模型的访问权限，或者你获得了对某个特定程序的访问权限，诸如此类，这当中有许多种不同的排列组合，实际上我们发现自己一直在使用它。

另一个很好的例子是，当我们最初为……呃，为 Fable 5.1 推出这种保留思考功能（preserved thinking）时，我们对一部分人实行了老用户优待（grandfathered in），给了一点……你知道，就像是一段宽限期，好让他们去进行集成调整。作为老用户优待的一部分，我们表示：好吧，我们得记录下谁是需要额外时间的老客户，对吧？然后我们就做了一个信任授权。这样一来，对于任何事情我们都能做到这一点。我们只是运行着一个位于请求热路径上的服务，以确保……你知道，请求顺畅通过并检查你是否拥有想要执行操作的授权。这其实和基础授权真没什么不同，只不过我们必须针对自己的系统，以及我们需要插入这些检查的位置，专门搭建一套系统。

英文原文 >> Yeah, kind of. I think so really we have like um there's like authorization of the form of like okay you're you made a request to an API that like under the hood is going to access some data and we're making sure it's like your data that you're accessing, right? Like really really vanilla authorization. This is just like we put a data model in place that's like a very clean like a trust grant means like you have been given access to some specific model or you've been given access to some specific program or you know like there's a bunch of different permutations of this we actually find ourselves reaching for it all of the time. Um, another good one was when we first rolled out um some of this preserved thinking in uh or for the for Fable 5.1, we kind of grandfathered in some people and gave a bit of a you know just like a grace yeah grace period to go and uh make the integration changes and as part of grandfathering in we said okay we have to like track who is like an existing customer who needs the extra time right and then we did a trust grant and so then we're able to say for anything. We're just running this service that is kind of on the hot path of our requests to make sure that um you know, we just like flow through and and check whether you have the grant for the thing that you're trying to do. Um which is it's really not any different than like vanilla authorization really, but like we just had to spin up a system that was specific to our system and like where we needed to be able to insert these checks.

模型发布的工程与流程

是的。我是说，我觉得这些都是人们往往视作理所当然、平时不太会去想的工程层面的事情。我想知道，在模型发布方面，还有哪些平台层面的工作是必须完成的？比如支持 Claude Code，或者支持……你知道，显然我经常和 Cognition 交流，但对于其他客户也是如此。单从模型发布来说，对吧？稍后我们会更深入地聊正在进行的安全工作，不过因为你记忆犹新，我只是想先从高层次了解一下：一个模型的发布都需要经历些什么？

英文原文 >> Yeah. I mean I think uh these are all like the engineering things that people kind of take for granted don't really think about. What is another example I guess of the platform stuff that had to happen you know maybe serving cloud code uh maybe serving you know obviously I talk a lot with cognition but other customers just in terms of a model launch right like we'll talk more about the uh the the the safety work that is that's being happened I just want to sort of go at a high level because it's fresh off your memory like what goes into a model launch

如今它已经有点变成一台运转有序的机器了，呃，撇开安全方面的事情不谈——我认为那部分更复杂。但在这些部分之外，有很大一部分工作是从客户那里获取反馈。所以，你知道，我们做出了模型，这里面有大量的安全测试，也有关于我们认为它应该达到什么水平的评估。我们做出必要的权衡和决策。然后我们必须经历测试阶段。呃，我们会切出模型的各个版本。我们会对其进行评估。我们内部也会做大量的“ant-fooding”（内部试用），这其实总是非常有帮助，我们能很早就捕捉到问题，比如发现这里可能不是最佳状态。而且我们在内部工作中显然重度使用 Claude。所以我们能够真正看到关于这些情况的早期信号，这有助于我们察觉……你知道，哪些变体可能会比其他的更好。

当我们对某一特定的一组变体感到非常有信心时，呃，我们就会为我们的客户切出一个版本。呃，有时这会通过我们的一方产品来进行，比如通过 Claude Code 或 Cowork 之类的工具。呃，在其他情况下，它会面向我们的 API 客户。呃，实际上我们会与这些客户展开一种类似于早期访问计划（early access program）的合作。他们需要在自己的测试框架（harness）中进行修改。我们已经与很多客户进行了对接，比如 Cognition、比如 Cursor 等等。针对如何处理这一过程，我们有一套流程。呃，以便我们大家都能……他们总能提供我们所需的反馈：它在你们的评测中表现好吗？你们喜欢它吗？有什么不喜欢的地方？有些东西属于主观感受（vibe），我们也喜欢听听这些方面的看法。呃，有些则是直接的硬性评测，比如它在你们关心的指标上表现好吗？

英文原文 >> it's become a bit of a a machine these days uh minus the safety stuff which I think is the more complicated part. But outside of those pieces, there is a lot of getting feedback from our customers. So, you know, we make the model, there's a lot of safety testing. Um there's also evaluation of where we think it needs to be. We make the required trade-offs and decisions as necessary. And then we have to go through testing. Uh we'll cut various versions of the model. We'll evaluate it. We'll do a lot of internal um ant fooding uh as well. And that actually always really helps like we catch like really early things like this is, you know, maybe not the best. And we obviously use cloud a lot for our work internally. So we're able to actually see early signals around stuff um and it helps us detect like you know which which variants might be better than others. And then when we feel really confident with like a certain set of of variants uh we will cut a version for our for our customers. Um sometimes that will go through our first party products like through cloud code or co-work or things like that. Um in other cases it will go through our API customers. Um and we'll engage in a kind of like a early access program effectively with those customers. they'll need to make changes into their harness. And we've engaged with a lot of customers like like Cognition, like like Herser, like these folks. And we have a bit of a process on how we handle that. Um, so that we all kind of get they always get the feedback that we we need. Does it perform well in your evals? Do you like it? What don't you like? Some things are are vibe and we like to hear those things too. Um, and something we just like straight up evals like did it do well on the things that you care about?

早期反馈与评测

我们把所有这些汇总在一起，一旦我们对所有这些不同的环节都感到满意，我们就会发布模型。

模型反馈的现状感觉仍然非常非结构化。

英文原文 >> And we take that all together and once we all feel good about like all those different pieces, we launch the model. The state of model feedback is feels very unstructured still.

基本上，它始终是公司之间的一个 Slack 频道，内容就像是：“嘿，这东西看起来怪怪的”，然后大家就会说：“好吧，我猜我来修一下吧。给我一个 ID 或什么东西。”

英文原文 >> Basically, it's always a slack channel between companies of like, hey, this thing seems weird and then people are like, okay, I'll fix it, I guess. Give me an ID or something.

是的，非常……我是说，这完全是由产品的非确定性本质所决定的，对吧？但是我认为正如你所指出的，真正能加入我们早期访问计划的客户，都是拥有非常扎实完备的评测体系的客户。虽然我认为这当中很多确实基于主观感受，而且很多交流沟通往往比较偏向主观感受且具有即兴性，但这部分原因在于我们是在争分夺秒——我们希望尽可能缩短从切出一个用于测试的模型版本到让所有人都能访问该模型之间的时间窗口。所以这确实是一个非常紧凑的时间窗口，但我们倾向于合作的客户，是那些我们明知他们会立刻启动整套评测套件，并能够尽快带着极具实操价值的反馈以及基于主观感受的反馈回复我们的人。因此，呃，随着时间的推移，我们当然可以在流程层面采取措施把这些做得更好，但我是说，你可能会感到惊讶。呃，你可能不会惊讶，但我认为有些人会惊讶于世界上现存的 Agent 级产品中，竟然有那么少的产品拥有良好的评测来帮助测试这些模型。

英文原文 >> Yeah, it's very I mean, it's it's the nature of like a product like non-deterministic, right? Like, but I think to your point, the only customers really that are part of our early access programs are customers that have really robust emails. Like I do think a lot of this is vibes based and I think a lot of the conversations tend to be kind of like vibes based and and on the fly and part of that is because we're like racing right it's like we want to minimize as much as possible the window between we have a version of the model that we've cut for testing and we give everyone access to that model and so it is just like this really tight window but the customers we tend to do it with are the ones who like we know they're going to go like kick off their whole eval suite and be able to come back to us with like really actionable feedback as quickly as possible alongside the vibes um the vibes based feedback. So, um of course there's like definitely like processy things that we could do to make these things better over time, but I mean you'd be surprised. I mean, you probably wouldn't be surprised, but I think some people would be surprised about how few, you know, like products that exist in the world that are agentic that like don't have good evals to be able to help test these models.

两年前我们请 Boris 上播客时，他还在说我们没有……你也是，Claude Code。我是说，现在情况已经改变了，但情况虽变了，你知道……呃，是的，很多时候就比如你的评测就是你的用户，而你没有时间去把它们形式化，或者你没有经验等等，这都没关系，到某个时候当你开始认真起来时，你就会建立起评测体系。

英文原文 >> We had Boris on the pod two years ago saying we don't have you also clock code. I mean that's changed but that's that's changed but you know like uh yeah a lot of things like you know your emails are your users and you don't have time to formalize them or you don't have the experience or whatever and that's fine at some point when you get serious you you'll have emails.

是的，完全没错。

英文原文 >> Yeah totally.

我觉得好的一点在于，如你所说，你们自己做了大量的内部试用。所以大家常说，你们在模型发布前自己就通过测试发现了其中很多问题，对吧。

英文原文 >> I think the good thing is you guys do a lot of amp fooding as you say. So it's commonly said that you find a lot of this testing it yourself before it comes out right.

是的。是的。API 客户尤其有用，因为他们会把 Claude 置于不同的运行框架中。呃，而我们希望 Claude 具有非常非常高的通用性。呃，因此它在其他框架中运行的能力对我们来说相当重要。这种形式的反馈对我们而言往往格外有用，因为相比我们自己所能获得的，它是全新的……

英文原文 >> Yeah. Yeah. The API customers in particular are very useful because they'll put cloud into a different harness. Um, and we want cloud to be very very general. Uh, so its ability to work in other harnesses is is quite important to us. And so that style of feedback tends to be exceptionally useful for us because it's it's novel um from what we would have gotten from an

反馈的价值与行为平衡

什么样的反馈会有所帮助？是像能力回退（regressions）这种吗？“我们这里出现了回退。我们在这里注意到了很好的特质。”

英文原文 >> what kind of feedback helps. Is it like regressions? We have regressions here. We notice good attributes here.

呃，好的方面总是、总是非常令人欣慰的。呃，我觉得我们很多时候并不感到意外，但我们喜欢看到我们可能提出的一些假设得到验证。老实说，最有用的反馈是负面的。呃，比如你知道，“它在这一点上表现不佳，在那个方面做得不好。”我们喜欢那种反馈，然后我们就会想：太好了，我们要怎么解决它？

英文原文 >> Uh the good stuff is always it's always very validating. Uh I think we're very frequently not surprised, but we like to look to be validated on some of those things that we might hypothesize. Honestly, the most useful feedback is negative. Um, like you know, it didn't do well at this, didn't do well at that. We love that feedback and then we're like, great, how do we fix it?

对。而且往往会涉及这样一些事情，就是这真的很困难，因为并不是每个人都希望 Claude 在每个维度的光谱上都落在完全相同的位置。并且……也许一个很好的例子就是，你知道，懒惰与主动行动之间的权衡。有时我们出了一个模型，大家会说：“就赶紧把我的任务完成吧，别再偷懒了，表现好一点”；而在其他时候，大家又会说：“嘿，我们只是想摸索一下、做做计划，结果你直接跑去写了一大堆代码，或者采取了一整套我还没准备好接受的行动。”把这一点拿捏得恰到好处实际上是不可能的，因为在现实中每个人的需求实际上都截然不同。

但我确实认为我们经历过一些情况，比如切出了模型的早期版本，我们发现看到了太多的懒惰倾向，对吧？然后我们就会把它放回炉子里再烤一会儿，对吧？尝试通过重新训练把那种倾向消除掉。因此，如果我们所做的一切仅仅是……那么这些问题我们可能就根本捕捉不到了。

英文原文 >> Yeah. And it tends to be some of these things that are like it's really hard because not everyone actually wants like Claude to land at the exact same spot on every spectrum. And and maybe a good example is like, you know, laziness versus proactivity and taking action. And so there's sometimes when like we have a model and and people are like like just finish my task like stop being lazy like do better and other times when it's like hey we were like just kind of feeling this out and planning and then you like went and wrote a bunch of code or you went and like took a whole bunch of action that I wasn't ready for. And getting that exactly right is literally impossible because everybody actually wants something different in reality. But I do think we've had situations where we've cut an early version of the model. We found that we saw too much laziness, right? and like we like put it back in the oven for a bit, right? And and tried to train that back out. And so those are the sorts of things that we may not have caught if all we're doing is

在我们的产品内部以及我们的 API 内部进行内部试用（ant fooding）。对我们来说，把模型推到 API 中，让我们所有的其他客户都用起来，并告诉我们有哪些需要改动，这要重要得多。

英文原文 internally ant fooding within our products and within our API. It's way way more important for us to get that out there in the API and get all of our other customers running with it and let us know what we need to change.

是的，这是一个核心问题。而且我认为这可能是——如果换作是我处在你们的位置——做模型产品经理最难的事情之一，也就是所谓的对齐与个性化（alignment versus personalization）。存在一种你希望面向所有消费者的默认性格、默认行为，同时你又希望能够对某个人在 CLAUDE.md 中写的内容迅速做出响应，比如他说“不，不，不，请比默认状态更主动一些”。

然后据我所知，我也参与了 Frontier Code，我们参与了 Fable 的发布，这让 Frontier Code 名声大噪。现在我们在模型基准测试上又迎回了 Opus 55，那是 Frontier Code 非常重要的一部分，对吧？Frontier Code 的模型曲线之所以看起来很奇怪，是因为它对过多的活动或过多的文件进行了惩罚。这很好，比如这本就是 Frontier Code 的整体设计目的；但我完全可以在我的 CLAUDE.md 里直接说“别那么做”，然后它就不会那么做了。

英文原文 >> Yeah, it's a core question. And I think it's probably the if I if I were in your shoes like one of the hardest things about PMing for a model which is uh let's call it alignment versus personalization. There's a default personality a default behavior that you want for all consumers and then you want to be able to respond very quickly to someone's cloud MD saying no no no like please be more proactive than default. Uh and then like so as to my knowledge you know and I was involved in Frontier Code uh we were involved in the fable launch uh which put Frontier Code on the map uh and now Opus 55 we have it back on on on the the model benchmark that is a very big part of Frontier Code right the reason that the model curve looks weird for Frontier Code is because it penalizes too much activity or too much uh files. uh which is good like there was a whole design purpose of French code but like I could easily just be like in my cloud MD just say like don't do that and then it won't do it

而且

英文原文 >> and

所以，我是否因为我的基准测试没有包含这种主观的个性化元素，而不公平地惩罚了 Claude Opus 55 呢？我不知道具体该怎么问这个问题，但你们是如何处理个性化问题的？显然一个模型可以做那么多不同的事情，而且这高度依赖——每个人都有自己的 CLAUDE.md。你们是如何评测的？

英文原文 >> so like am I penalizing cloud opus 55 unfairly because my benchmark doesn't have that personalization element which is subjective so I don't know what the question is but like how do you deal with like personalization right like it's it like clearly a model can do so many different things and it's so depend everyone has their own cloud MD. Uh, how do you eval?

是的，我们在这方面做得并不算好。这确实——说实话，这非常难。超级难，而且它们之间相互竞争。这很糟糕。

英文原文 >> Yeah, we don't do a great job of it. There's like the there's seriously it's it's really hard. It's super hard and they're they're competing. It's horrible.

我以为有 Claude 宪法（constitution）。我想

英文原文 >> I thought I thought there's the cloud constitution. I think

那已经过时了。

英文原文 >> that's old.

宪法是存在的，

英文原文 >> There is a constitution,

但我还是让你们来回答吧。宪法是有帮助的，但对于这类关于它如何针对指令进行个性化——指令各不相同，而偏好在这些事情之间更是大相径庭——这对我们来说非常难做。我们通常试图通过提供更多参数来解决这个问题，这些参数允许我们针对不同客户群体进行调整；如果我们无法掌控你的客户群体，而你又是 API 客户，那么我们会尝试给你提供建议，然后由你去进行调整。

所以存在一些类似的东西，你知道，这并不完全等同于针对 Claude 的个性化，比如各种 CLAUDE.md 或现在的 AGENTS.md 之类的；但我们确实试图提供一些层面的东西，比如投入程度（level of effort），比如你应该投入多少 effort，比如你可能真正在意的模型尺寸等等诸如此类的事情。但我认为，对于像那种程度的个性化所真正需要达到的效果，目前还不够完善。所以这是一个非常棘手的问题。

现在，除了提供多个参数等方式之外，我们在很大程度上解决这个问题的方法，老实说，是在我们收到的所有反馈中尝试展现冲突的品味，并尝试在其中一些事情上做出判断权衡。我认为随着时间的推移，并且随着向更多客户和更多用户扩展，这并不是一种非常可扩展的方式。我们将需要为 Claude 开发能够吸收你的个性化的方式。也许那是你可以提供的一个信号，或者你可以据此微调的东西，等等。但我认为我们必须走一条更加朝向那个方向的路线。不过目前来说，是的，并没有，我们实际上只是在很多事情上尝试做出判断权衡，但这确实相当不容易。

英文原文 >> but I'll I'll let you guys answer. The constitution is helpful but but for things like this on how it personalizes to instructions uh which are different and preferences which are very very different across these things um is very hard for us to do. We generally try to solve this by having more parameters that then allow us to tweak it per customer base and if we don't control your customer base and you're an API customer then we try to give you recommendations and then you try to do that tweaking. So there are things like you know around doesn't exact it's not exactly the same level like personalization to the cloud you know various cloudmds or now agents MDs or whatever but we do try to give things around the layer of like level of effort like how much effort you should put in like what are uh the like the level like maybe the size of the model that you might actually like try to care about things like that but it's I think it's um it's not quite there for what we would actually need for like that level of personalization um so it's a very hard problem and right now a lot of our way to solve that is beyond the parameter like the giving multiple parameters or something is try to exhibit conflicting taste honestly across like all of the feedback that we get and try to try to make like a judgment call on some of these things. I think over time they actually and as you scale to more customers and more users that's like not a very scalable way to go do something. Um and we will need to develop ways for cloud to kind of like take in your personalization. Um and maybe that's like a signal you can provide or something you could tune on or things like that. Um, but I think we'll have to like take a route that's much more oriented uh towards that direction. Uh, but for now, yeah, no, we we actually just try to make judgment calls on on a lot of the stuff, but it's it's pretty tough.

现状就是如此。

英文原文 >> It is what it is.

这里顺便提一句。我猜默认的 effort 推理设置变了，现在是 medium。这是很可能会影响到不使用这个开关的普通客户的事情之一。

英文原文 >> A small a small note there. I guess the default effort reasoning changed. It's now medium. This is one of those things that probably affects the average customer that doesn't use this toggle.

是的，就像是 Claude Code 的设置，对吧？

英文原文 >> Yeah, it's like a cloud code setting, right?

这是 Claude Code 的设置。他们默认设为了 medium。

英文原文 >> It's a cloud code setting. They defaulted to medium.

是的，他们刚刚

英文原文 >> Yeah, they just

参数配置与托管 Agent

而且这个东西是变化的。这确实——这就是我们用来进行某种个性化的参数的一个绝佳例子。我觉得用“个性化”这个词可能稍微有点太激进，但我们有点像是在针对不同的细分群体进行定制。比如默认设置会根据你是免费客户还是专业用户、Claude Code 还是 CodeWork 还是企业版，诸如此类，还是 API 等等来进行调整。考虑到你显然始终可以调整它，但这些是我们尝试提供个性化的轻量化方式。

有一点我们很犹豫去做，那就是我们不希望人们觉得他们无法掌控对 Claude 的自定义。例如，我们本可以在这些事情上采取更强硬的手段，但我们希望让用户有能力根据自己的考量去体验 Claude 的智能水平，特别是如果你想走向更高的一端，或者有时你可能想在较低的一端进行实验，看这对于你的使用场景是否实际上更快——我认为这是一个艰难的产品权衡。

因此，我们倾向于采用温和的默认设置，但给你提供调整的选项，我认为目前这样效果还算过得去，但我设想随着时间的推移，我们会学会如何为客户做得更好。我们目前对所有这些都还算不上超级满意，但我们知道在发布模型时——比如你问过发布一个模型需要付出什么？显而易见我们必须做的大事之一就是：好吧，Claude 在某件事上变强了，有时那件事是我们应该在 API 上作为参数暴露出来供你控制的。但随着时间推移，这就演变成了现在这种有趣的混搭组合，比如在 API 上有 effort、有 budgets，有所有这些你可以设置的东西。这就变成：到底有谁可能弄清楚对于任何给定的任务，应该去设置的最佳组合是什么？

这也是我们非常切身地在边做边摸索的事情，和客户一起摸索，摸索随着时间推移我们要废弃哪些参数。哪些参数我们只需要做好更好的默认设置？哪些参数应该采用 1 到 100 的尺度，而不是 low、medium、high 的尺度，对吧？因为实际上我们已经训练了 Claude，让它在理解某些这类事情的整个选项谱系上变得非常擅长。但是，如果我们把那数以百万计、数以十亿计的选项排列组合全部暴露出来，你根本没办法走很远。

而这实际上正是像 Cloud Managed Agents（CMA）这类产品的价值主张的一部分，它仍然是通过 API 对 Claude 进行编程式访问，但你开箱即可获得一个框架工具（harness）；每次发布模型时，我们都会做大量的繁重工作，弄清楚有哪些新参数、有哪些破坏性改动、如何在我们的 harness 内部让 Claude 发挥出最佳性能，从而让使用它的人开箱即可直接获得这些，完全无需费心思考。

英文原文 >> And this and this thing varies. This thing does like this is a this is a perfect example of a parameter that we use to kind of like personalize. I I would say this maybe a little too aggressive of a term, but we kind of like customize maybe for different subsegments. So like uh the default setting will adjust for uh whether you're a free customer or proumer customer, cloud code versus uh codework versus enterprise like things like that versus API and stuff like that. Um knowing that you can obviously always adjust it but those are kind of like light ways where we try to give that. One thing that we are hesitant to do is we don't want people to feel like they can't control their customization of quad. Uh that we could take a heavier hand on these things for example, but we want to give users the ability to experience the intelligence levels of quad as they kind of see fit, especially if you want to go towards like the higher end or you want to experiment with maybe sometimes in in the lower end if that actually is like faster for your use case, which is a hard product trade-off, I think. Um, and so we we tend to lean towards gentle defaults, but give you options to to adjust, which I think works okayish for now, but I imagine us, you know, like learning how to do that better over time for customers. We're not like super super happy with any of this yet, but we know as we launch a model, like you asked like what does it take to launch a model? One of the big things obviously that we have to do is like, okay, Claude like got good at a thing and like sometimes that thing is something we should expose as a parameter on the API to let you control. But I think as this has evolved over time, we've ended up with like this funny mishmash of like there's effort, there's budgets, there's all these things that you can set on the API. And it's like how could anyone like possibly figure out what is the right combination of things for any given task for what you should go and set. And it's something that this is us just very much like figuring it out as we go and figuring it out with customers and figuring out like which of those parameters do we deprecate over time. Which of those parameters do we just like default better? Which of those parameters should be like a one to a 100 scale versus a low medium high scale, right? Like because actually we've trained Claude to get really good at understanding like a whole spectrum of options on some of those sorts of things. But like do we expose the like entirety of those millions and billions of permutations of options like you wouldn't really get very far and that's one of the things actually that um is part of the value prop with something like cloud manage agent which is like still programmatic access to cloud and an API but you get a harness out of the box where we do every time we're launching the model a lot of the work to go figure out like what are the new parameters what are the breaking changes how do we get the best out of claude within our harness so that for the people who are using it um you just kind of get that out of the box. You don't have to think about it.

针对被这方面吸引的人群——这是一个庞大且在不断增长的群体，特别是我们实际上在 EIE 举办了整场 CMA 工作坊，我认为办得非常成功。是否有专门的信息流可以让大家订阅 CMA 的更新？

英文原文 >> Just for people who are uh drawn to that and which there's a significant and growing population particularly we actually did a whole CMA workshop at EIE which I thought uh was really well done. Is there a separate feed for people to subscribe to like updates on CMA

信息流，比如

英文原文 >> feed like

Twitter 信息流、通讯（newsletter）？我不知道。

不，我想实际上在我们的 Claude Devs 频道里，是的，我们在那里宣传得很起劲。因为对人们来说，这确实是一个很有意思的选择。

英文原文 >> Twitter feed newsletter? I don't know. No, I think actually our our Claude Devs channel, we are Yeah, we're we're pretty loud about it. Um because it is like an interesting option for people.

是的，我只是想给人们指明，如果那是你使用 Claude 的方式，这就是途径。

英文原文 >> Yeah, I just want to give people like if that's your if that's your way of consuming cloud, that's the this is the path.

嗯

英文原文 >> Um

我认为它也挺被低估的。对于那些还没有以这种方式使用 Claude 的人，

英文原文 >> I think it's also pretty underrated. Um for those that aren't consuming cloud this way,

什么是 Cloud Managed Agents？人们为什么要使用它？

英文原文 >> what is cloud managed agents? Why should people use it?

噢，对，我们大概应该做个小介绍。我不知道。那是谁的房子。是的，用两句话介绍一下。我想很多人在它刚出来时都忽略了它

英文原文 >> Oh yeah, we should probably do a do a little intro. I don't know. That's somebody's house. Yeah, little two two sentence thing. I think a lot of people glanced over it when it came

托管 Agent 与 Harness 工程

大家当时都处在“我需要做 harness 工程、我需要控制这个”的阶段，你总能听到这类说法。而现在的问题变成了：你真的需要做所有那些事情吗？还是说直接用托管 agent 就行？你有大量信息，可以跳过很多搭建过程，不过还是先快速讲讲这三点吧。

英文原文 out, right?

Everyone was in this phase of I need to do harness engineering. I need to control this and like you hear all that and now it's like do you need to do all that or do you just use managed agents and you have a lot of info you can skip over setting up but give give the quick three.

是的，这取决于你的具体使用场景。我们目前的 API 包含 Claude Managed Agents。我们有 Messages API，它本质上是原始 token 访问。然后我们有 Claude Managed Agents，这是一套 API，但它允许你定义一个 agent，并与该 agent 开启一个会话。它本质上算是一种更高阶的抽象，让你能够跳过搭建所有基础设施、搭建 harness 以及做大量诸如此类的工作。对于想要以编程方式运行 agent 的人来说，这是一个更加开箱即用的集成方案。

英文原文 >> Yeah, it it depends on your use case but um so cloud managed agents is our API today. We have the messages API which is essentially raw token access. Then we have cloud manage agent which is a suite of APIs but it lets you define an agent start a session with that agent. Um and it's essentially just kind of a higher order abstraction that lets you skip setting up all the infrastructure setting up your harness and doing a lot of that type of work. It's a much more out of the box integration for people who want to programmatically run agents.

CMA 和 Claude Code 共享底层基础设施吗？因为它们推出的先后顺序让人感觉，哦，那就是 Claude Code 背后那一套。

英文原文 >> Does CMA uh share infrastructure with cloud tag? Because the sequencing of it seemed very like oh like that's the cloud tag.

很大一部分，很大一部分。作为平台团队，我们的一大核心工作就是运行我们的 API。同时，我们也在某种程度上运行我们所有的基础产品设施和产品服务。比如一个很好的例子是，我们的团队负责运行沙箱集群，该集群既支撑着 Claude Managed Agents，也支撑着像 Claude Code 这样的产品及其他服务。但在实际针对这两款产品的 harness 层面上，由于我们在 harness 内部想要做的事情存在差异，所以它们实际上并不共享同一个 harness。不过它们共享大量支撑执行和 API 运行的基础设施。

英文原文 A lot of it. Um, a lot of it. So, one of the big things that we do is as the platform team, we run our APIs. We also kind of run all of our foundational product infrastructure and product services. So, like really good example is like our team runs our sandboxing fleet that backs both cloud manage agents as well as products like cloud tag and otherwise. But at the actual harness layer for those two products, like there's just differences in what we might want to do within the harness so that they don't they don't actually share a harness. Um, but they share a lot of the infrastructure that powers the execution and um powers the APIs.

Memory、Dreaming 与安全重心

我觉得大家确实应该更多地使用这个。在你们推出之后，基本上所有人都在抄袭并克隆托管 agent。这确实是——你知道的，模仿是最真诚的奉承。既然我们在聊这个话题，就顺便提一下最近一直在进行的关于记忆（memory）的那些进展。我感觉这曾是 Anthropic 上半年的工作重点。它是停滞了，还是仍在继续推进？现在的侧重点是什么？

英文原文 >> I think that's that's really people should use this more. I I think everyone basically had copycat clones of manage agents after you guys launched it which yeah, you know, imitation is a sincere form of flattery. Since we're on this topic, we'll briefly mention uh all the memory stuff that has been going on. I feel like it was a big part of Anthropic's work in the first half of the year. Has it stalled out? you know, is is it still still ongoing? Like what's what's the emphasis here now?

具体是指托管 agent 方面吗？

英文原文 >> Managed agents specifically.

比如 dreaming。

英文原文 >> Dreaming.

哦，这依然是我们工作的一大重心。或许可以这样理解：我们推出托管 agent，是作为一个平台提供给那些不想自己亲力亲为做所有这些事情的人，对吧？或者只是希望能直接把“如何发挥 Claude 最佳表现”的包袱甩出来，因为我们的团队实实在在就坐在这里对所有这些机制做 eval 评测，确保 harness 变得极其强大。Memory 和 dreaming 的核心就是：你如何确保你的 agent 能够随着时间推移持续自我精进？所有这些依然是我们团队的重要方向。

但我真正想说的是，呼应我们前面聊到的观点，从安全角度来看，发布模型变得越来越艰难。我认为我们团队的大部分精力，较少花在诸如“给这个 agent 搞个好玩的功能来做爬山算法优化”之类的事情上，而是更多地投入到如何把安全性融入所有这些环节中。因为我们能做的最重要的一件事，就是把模型的能力释放出去，并且安全地释放出去。

所以我认为我们的大量精力，都是把所有这些相同的概念融合起来，为你提供一个既极为强大、又极其安全的 agent 系统。这就是我们的精力投放所在。我想比起今年早些时候，我们在技能（skills）、dreaming、memory 这些类似某个时间节点的探索上，节奏相对放缓了一些。

英文原文 >> Oh, it is a big part of what we're doing. I think maybe the way to think about it is we launched managed agents as a platform for people who like didn't want to do all these things themselves, right? Or just wanted to like offload like I'm getting the best out of Claude because our team is literally sitting here like evaling all these things and making sure that the harness is going to be really powerful. Memory and dreaming is all about just like how do you make sure your agent can continuously improve over time and all of that is still an important focus for our team. But what I would actually say is to the point of what we talked about earlier as launching models has become harder and harder from a safety perspective. I think most of our team's energy is going less into like here's a fun feature to like hill climb on this agent or whatever and much more into how do we bring safety into all these things because the most important thing that we can do is get the power of the model out there and get it out there safely. And so I would say a lot of our energy is take all these same concepts and give you an agent system that's going to be really powerful but also that's going to be really safe. And so that's where we're putting our energy. I think compared to maybe earlier this year, we have slowed down on like skills, dreaming, memory, like these kind of like moment in time.

Skills。

英文原文 >> Skills.

不、不、不，我们很看重 skills。

英文原文 >> No, no, no. We love skills.

我们一直在推进更新。我并不是说我们什么都没做，我们也同样很看重 skills。但确实，相比之下，我们在另外一些方向上的节奏放缓了一点点。不过，我们非常看好大家在 harness 层做一定程度的爬山优化。接续刚才的一些讨论，我们自己内部做了大量这类工作，但从某种意义上说，我们提供的 harness 本身是非常简单的，是有意设计得很简单的。我们实际上并不想做过多强加的主观设定。我们希望确保最佳实践能被整合进来，而且在最硬核的 agentic 循环中，存在一些无差异化的部分，它们确实很难串联，但也完全可以当作模板样板直接去搞定。

不过在其之上的有趣之处在于：一旦有了那层底层基础，就会衍生出我们构建的这些类似爬山算法的策略，而 dreaming 实际上就是其中之一。Dreaming 在底层其实是我们基于 CMA 进行爬山优化构建的一个多 agent 系统，它本质上是套在自身之上的一套 CMA。

英文原文 >> Um we we are making we are making updates. I'm not saying that we're not doing anything, but um we we love skills as well. But yes, so I think we've slowed down a little bit comparatively um for some of the other efforts. But uh we are very bullish on uh people kind of doing some level of hill climbing at the harness layer. Uh to you know some of the previous conversation here we do a lot of this ourselves but the harness that we provide is very simple in a way. It's it's intentionally simple. Uh we don't want to be actually overly opinionated. want to make sure the best practices get merged in and there's some kind of undifferiated pieces of the hardest uh agentic loop that yeah are uh hard to string together and also like you can kind of just boilerplate do it. Now the interesting part on top of that though is like once you get get that base layer there are these like hill climbing strategies that we construct and like dreaming is actually one of them. So dreaming under the hood is a multi- aent system that we hill climbed on top of CMA and it's actually a CMA on top of itself basically.

套在自身之上的 CMA。

英文原文 >> CMA on top of itself.

它是起另外一个，是的。Dreaming 的运作机制是，我们启动另一个托管 agent，然后它去审查前一个托管 agent，接着向该托管 agent 写入 memory。所以它从上到下全都是托管 agent。这在某种程度上就是特意设计的，因为我们设想你可以将许多这类模块化组件拼装在一起，做些有趣的事情，而 dreaming 只是我们探索的更有趣的案例之一。

但我们一直在审视这一点，发现其实还有海量其他事情可以做。你可以采用 Best-of-N 作为一种多 agent 策略；你可以做一个验证器 agent，来把控目标或产出结果。里面还有很多其他可玩的东西，我们已经看到有人做出了相当奇特、疯狂的东西，比如有某种 harness 在全局共享极其复杂的 memory，并且并发启动大量 agent。我们当时就想，我们其实应该赋予你做到这一点的能力，就像我们构建 Dreaming 那样——从上到下全由托管 agent 组成。

我们相对很快就会推出一个更新，届时会升级底层原语，并将其开放出来，允许用户自主构建类似 harness 的策略，或者不管你怎么称呼它……

英文原文 >> It's it like spins up another Yeah. Uh the way Germany works is that we spin up another manage agent that then can expect the previous manage agent and then write uh memories to that manage agent. So it's manage agents all the way down and this is a bit of thing by design because we envisioned that you could probably put together a lot of these modular components for something interesting and dreaming is just like an example one of the more interesting things that we were going after. Uh but we kind of have been looking at this and being like there's actually a ton of other stuff you can do. You can do like best of n as a type of like multi- aent strategy. you can do a verifier agent, uh, that kind of like goal thing or outcome thing. Um, there's a bunch of other stuff in there and we've seen people do some pretty funky crazy stuff like there's been a harness that like shares like crazy memory across everything and they spin up like tons of parallel agents and we're like we should actually just probably enable you to do that uh in the same way that we did we built Dreaming that's like manage agents all the way down. There's a update that we'll make relatively soon um where we're updating the underlying primitive. we'll expose it uh to allow users to kind of like construct harness strategies maybe or however you want to call this

比如多 agent 策略。

英文原文 >> like multi- aent strategies

多 agent 策略，让你可以打造属于你自己的版本。我们会为你提供模板，告诉你比如我们当初是如何从 dreaming 起步的；作为开发者，你或许会想在此基础上做出某种调整，并在其上发掘出更多价值。

英文原文 >> multi-agent strategies that allow you to kind of build your own version of this and we'll give you like you know templates of like this is how we started with dreaming maybe there's like an update to this that you would want to make as a developer and you would find some more value on top of that

对，我认为这个切入角度非常好。与其说我们在放缓这类研发，不如说是我们的原语已经就位，我们可以放手让大家拿上这些东西去尽情发挥，同时为他们提供工具并展示：“这里有一些很酷的多 agent 策略，以及我们为了让 Claude Managed Agents 变得非常强大而融入的一些东西。”现在你可以让 Claude 去干活，利用这些原语，自己动手让它变得更加强大，比如创建全新的多 agent 策略等等；与此同时，我们团队的大量注意力则转向：“好的，太棒了，社区放手去干吧，你们尽管施展，而我们则继续聚焦于所有必要的工作，确保大家能够在该系统内部安全地使用这些模型。”

你刚才提到的有一点是，你们针对这些东西跑了大量的 eval 评测。

英文原文 >> yeah I think that's a really good framing it's less that we're slowing down on this sort of stuff and more saying like we've got the primitives in place we can continue to let people just like take and run with those things while giving them the tools to say here's some like cool multi- aent strategies and like things that we've put into into cloud manage agent to make it really powerful. Now you can like let Claude do work to take advantage of those primitives and make it even more powerful yourself like create new multi- aent strategies and whatever it might be while a lot of our team's attention turns to okay great like community run with that right and and you do you while we continue to focus on what are all the things that we need to do to make sure that you get access to the models within that system safely. One thing you brought up was you run a lot of evals on this stuff.

Harness 与 Agent 的 Eval 实践

这在当下是个非常热门的话题。有什么建议或最佳实践吗？

英文原文 >> Pretty hot topic right now. Any advice, best practices

具体是针对 eval 的吗？

英文原文 >> for eval specifically?

针对 harness 和 agent 的 eval。

英文原文 >> Evals on harnesses, agents.

Eval 有很多种不同的类型，对吧？针对你所处的不同情境以及你尝试测试的不同目标，并不是所有的 eval 都是生而平等的。你显然会有静态确定性的测试，然后你又会有 LLM-as-a-judge。你有所有这些不同的策略。

但我大概想说的是，我们从大多数人身上发现的情况是：你需要的测试数量通常宁多毋少。并不存在某几套完美的评测集，能打包替你解决让系统变得更好所需的一切答案。我们发现大家最终都需要一个相当庞大的评测套件，而且你可以让你的 agent 与你协同工作，随着时间推移不断演进你的 eval 套件。

英文原文 >> There's a lot of different types of evals, right? Like not all eval are made equal for different, you know, like situations that you're in and things that you're trying to test for. You obviously have just like static deterministic stuff and then you have LLM as a judge. You have all these different strategies. But I guess I would just say like what we found from most people is like you probably need more rather than less.

Um it's just uh there's not like one perfect like couple sets of emails that you could put together that are going to get you all the answers that you need to make your system better. We found that people end up needing like a relatively large suite of these things and then it's like you can have your agents work with you to evolve your eval suite over time as well.

评估与工程的演进

嗯，但我认为在这方面，我们看到人们犯的最大错误，可能就是投入不足。是的。而且起步要简单。我觉得有些人有点走极端，就像是，你看你列出的这一整套选项菜单。你就会觉得，哇，这太疯狂了。让我试试这个、试试那个，哪个最好呢？但在他们做所有这些事情的时候，他们实际拥有的评估数量大概是零。所以，你还不如先做点简单的事情。这会有帮助的。嗯，

英文原文 Um,

but

I

think

it's

just

like

not

underinvesting

is

maybe

like

the

biggest

mistake

that

we've

seen

from

people

on

that

front.

Yeah.

And

it

starts

simple.

I

think

some

people

like

go

a

little

crazy

and

they're

like,

you

know,

they're

like,

look

at

all

the

the

menu

of

options

that

you

kind

of

listen.

You're

like,

wow,

this

is

so

crazy.

Let

me

try

this

and

that

and

what's

the

best

one?

And

like

while

they

do

all

those

things,

like

the

number

of

emails

they

actually

have

are

like

zero.

So,

you

might

as

well

just

like

do

something

simple.

It

will

help.

Um,

对，我觉得某部分原因是人们缺乏经验。他们没有接受过这方面的训练。嗯，他们也不知道好的评估应该是什么样子。而且我认为对你们来说，发布更多相关的示例确实非常有帮助。呃，我经常跟人们提起的一件事是，我在用更多类似 fable 和 astroclass 模型做的事情，就是把工程当作研究来对待。

英文原文 >> yeah,

I

think

in

some

some

part

of

it

people

are

inexperienced.

They're

not

trained

to

do

this.

um

and

they

don't

know

what

good

looks

like.

And

I

think

for

you

guys

publishing

more

examples

of

that

is

is

really

helpful.

Uh

something

I

I I

do

tell

people

a

lot

uh

that

I'm

doing

with

more

fable

and

astroclass

type

models

is

we're

treating

engineering

like

research.

而当你把工程当作研究对待时，你自然会做更多的评估，做更多的标注，做更多运行规模的扩展，或者说是原型的制作和运行规模的扩展。你并不是在训练模型。你是在构建测试框架（harness）、产品或无论什么东西，但你是在用做研究的方式来对待它。你会预先明确你的目标是什么，尝试将其形式化为一个评估，然后尝试找出，好的，为什么它会失败？有时候是你的评估错了。

英文原文 >> And

when

you

treat

your

engineering

like

research,

you

naturally

do

more

evals,

you

do

more

labeling,

you

do

more

scaling

of

runs

or

like

prototyping

and

scaling

of

runs.

And

you're

not

training

a

model.

You

are

building

the

harness,

the

product,

whatever

it

is,

but

you're

approaching

it

like

research.

You're

defining

up

front

what

your

uh

goal

is,

trying

to

formalize

it

as

an

eval,

and

then

uh

trying

to

identify,

okay,

why

why

is

it

failing?

And

sometimes

your

eval

is

wrong.

完全是这样。

英文原文 >> Totally.

事实上，很多时候是你的评估错了，有时候是你的环境错了，

英文原文 >> Actually,

a

lot

of

times

your

eval

is

wrong,

sometimes

your

environment

is

wrong,

然后有时候是模型错了。

英文原文 >> and

then

sometimes

the

model's

wrong.

呃，而且实际上这在很大程度上正是我认为 AI 工程正在演变的方向，也就是做所有这些事情。

英文原文 >> Uh

and

uh

actually

that

is

like

a

lot

of

part

what

I

think

AI

engineering

is

becoming,

which

is

doing

all

this

stuff.

完全赞同。而且我们将继续在托管智能体中推出更多功能，为人们提供更多开箱即用的工具来做这类事情。你可能会从我们这里看到，你会得到类似这样的产品：这是一个可以帮你为托管智能体创建评估的产品，或者无论它是什么，做起来的感觉会非常像是在与 Claude 协作，

英文原文 >> Completely

agree.

And

we'll

continue

to

launch

more

features

within

cloud

manage

agents

to

give

people

more

tooling

to

do

this

sort

of

stuff

out

of

the

box.

And

you'll

probably

find

from

us

that

you'll

get

something

that's

like

here's

a

product

that

will

help

you

create

evals

for

your

manage

agents

or

whatever

it

might

be

and

it'll

feel

very

much

like

working

with

claude

in

order

to

do

that

is

like

那就是最好的方式。Claude 实际上非常擅长创建评估，

英文原文 >> that

is

that

is

the

best

way

to

do

it.

Cloud's

actually

really

good

at

creating

evals

to

um

确实是评估，因为人们看着 JSONL 这种东西时脑子就会一片空白，就像

英文原文 >> evaluations

actually

because

like

people

like

blur

blank

out

when

they

look

at

like

JSON

L's

like

just

对，但如果有一个漂亮的评估 UI，你在上面点左边、右边、左边、右边，在做类似于人类打分数据标注员本来就会做的事情

英文原文 >> right

but

a

pretty

eval

UI

where

you're

like

left

right

left

right

left

right

and

you're

you're

sort

of

like

doing

what

the

human

graded

data

people

labelers

would

do

anyway

呃，你可以自己做，直接把 fable 扔给它

英文原文 >> uh

you

can

do

that

yourself

just

like

throw

fable

at

it

它就会呈现出来，但同时也会写评论。因为它会输出所有这些评分，对吧，它会给你一个评分指标，做任何事情。但是，呃，Claude 可以直接读取这些，然后自我完善，对吧？这就是它需要的反馈，人们只是不知道你可以通过 prompt 来生成评估。

英文原文 >> and

it'll

materialize

but

also

write

comments

so

because

it

just

like

outputs

all

these

ratings

right

it'll

give

you

an

eogo

give

do

whatever.

But,

uh,

Claude

can

just

consume

that

and

then

work

on

itself,

right?

That's

the

feedback

it

needs

and

people

just

don't

know

that

you

can

prompt

for

an

email.

是的。

英文原文 >> Yeah.

是的。我很喜欢你这么说。我觉得这是一种非常类似坚信 AGI（AGI pilled）的做法。呃，因为它也允许你非常系统地更新和编辑那个系统。所以，随着新模型的改进，随着情况的变化，你确实可以检查你的系统处于什么状态，它就会自行演进，

英文原文 >> Yeah.

I

love

that

you

said

that.

I

think

it's

like

a

very

like

AGI

pilled

way

to

like

do

it.

Uh,

because

it

also

allows

you

to

update

and

edit

that

system

like

very

systematically.

And

so,

as

new

models

improve,

as

things

change,

you

can

really

inspect

where

your

system

is

and

it'll

just

like

evolve,

微调每一个部分。

英文原文 >> tune

every

part.

没错。

英文原文 >> Exactly.

呃，是的。所以基本上，我想这就像你知道我们之前讨论过产品和工程可能正在融合。此外，应用层工程和模型研究在所共享的技术上也正在融合，对吧，比如

英文原文 >> Uh,

yeah.

So

ba

basically

I

think

it's

it's

you

know

how

we

talked

about

how

maybe

product

and

engineering

are

are

emerging.

It's

also

there's

like

application

layer

engineering

and

and

sort

of

model

research

are

sort

of

merging

in

in

those

techniques

that

they're

being

shared

right

like

确实是这样

英文原文 >> that's

very

true

做模型的人非常非常习惯于做评估，应用层的人知道，你唯一关心的就是它是否符合 PRD，而且比如

英文原文 >> model

people

are

very

very

used

to

doing

eval

application

people

know

like

the

only

thing

you

care

about

is

does

it

fit

fit

the

PRD

and

like

是的，这就像是完全不同的

英文原文 >> yeah

it's

it's

like

a

whole

different

我认为这是一套全新的技能，呃，对于

英文原文 >> it's

a

whole

new

skill

set

I

think

um

for

我想你们今天就这个话题发布了一篇很酷的博文。内容有些不同。那是关于让 UI 变得快得多。但就你说的把它当研究对待而言，呃，基本上就是定义一个目标：我们希望内容加载得更快，然后进行定义，并且去质疑一些事情。除了实际耗时（wall clock timing）之外，我们还能做些什么？呃，这里面有一些很有趣的引述。我觉得能看到实际的研究人员或工程师是如何向 Claude 提提示词的，这很不错。里面有类似这样的内容：你知道，我们有 12 件事。我们说你两周时间。我在大约 3 天内完成了其中的 9 件，诸如此类。但对于人们去研究、去通读来说，是一篇很有趣的博客。

英文原文 >> I

think

you

guys

put

out

a

pretty

cool

blog

post

on

this

today.

It's

somewhat

different.

It's

about

making

the

UI

a

lot

faster.

But

to

your

point

of

treating

it

like

research,

uh

basically

define

a

goal

of

we

want

stuff

to

load

faster

and

then

define

and

you

know

question

things.

What

can

we

do

instead

of

wall

clock

timing?

Uh

there's

fun

quotes

in

here.

I

think

it's

nice

to

see

how

the

actual

researchers

or

engineers

prompted

Claude.

There

was

stuff

like,

you

know,

we

had

we

had

12

things.

We

said

you

have

two

weeks.

I

did

nine

out

of

12

of

them

in

like

3

days

or

something.

But

fun

blog

post

for

people

to

research,

for

people

to

read

through.

是的，我喜欢我们分享实际使用的 prompts，有些人就像是觉得，“天哪，他们肯定有疯狂独特的提示方式。”而实际情况就像是“再努力点，Claude”。

英文原文 >> Yeah,

I

love

it

when

we

share

our

actual

prompts

and

and

like

some

people

are

like,

"Oh

god,

they

must

have

crazy

unique

ways

of

prompting."

And

it's

just

like

try

harder,

Claude.

谢谢。

英文原文 >> Thank

you.

呃，我唯一的反馈是它应该链接到 workbench，虽然现在已经没有这东西了，但我以前经常用

英文原文 >> Uh

my

only

feedback

is

it

should

link

to

the

workbench,

which

is

no

longer

a

thing,

but

I

used

to

那是个好想法。Workbench。好的，太好了。所有反馈都收到了。喜欢这个想法。是的。呃，是的，但呃，你之前说要分享更多工程故事背后的细节，呃，或者是关于你提到的紧急工作（rush work）

英文原文 >> That

is

a

good

That's

a

good

idea.

Workbench.

Okay,

good.

Everything

feedback

heard.

Love

it.

Yeah.

Uh

yeah,

but

uh

you

were

going

to

share

more

details

behind

the

engineering

story

uh

or

the

the

rush

work

that

you

CPU 算力瓶颈与架构改造

是的。所以我想我早些时候谈到过，规模对我们来说是一个难题。嗯，规模与安全（scaleafy），对吧？就像

英文原文 >> Yeah.

So

I

think

I

talked

a

little

bit

earlier

about

like

scale

is

a

problem

for

us.

Um

scaleafy,

right?

Like

是的，规模与安全。这是我们投入时间最多的两个方面。嗯，我的意思是这真的很有趣，因为大多数人都习惯于谈论规模，或者就是我不知道，在 GPU、加速器层面的算力，而远没有怎么讨论 CPU，呃，你知道的，这种传统层面的算力。而今天它在加速器层面的问题同样严重，这真的很有趣。你无法获得足够的虚拟机。你无法获得足够的沙箱，无法让所有东西都能够启动、启动

英文原文 >> Yeah,

scale

and

safety.

Those

are

like

the

two

biggest

things

we're

spending

our

time

on.

Um,

and

I

mean

it's

really

interesting

because

most

people

are

used

to

talking

about

scale

or

just

like

I

don't

know

computes

at

the

like

GPU

accelerator

layer

and

much

less

so

at

the

CPU

um

you

know

like

old

school

layer

and

that's

it's

it's

just

like

as

much

of

a

problem

today

as

the

accelerator

layer

which

is

really

interesting.

You

cannot

get

enough

VMs.

You

cannot

get

enough

sandboxes

and

just

everything

being

able

to

spin

up,

spin

up

用上你拥有的所有资源。你

英文原文 >> with

all

the

resources

that

you

have.

You

确实，你们也有很多客户，

英文原文 >> really

you

got

a

lot

of

customers

too,

这很疯狂。是的。而且你想想看，因为我们显然是在多个方面使用 CPU，比如运行我们的产品服务、运行 API、运行我们所有的应用程序。我们在沙箱上使用 CPU，我们正在做的所有沙箱操作。然后就像所有事情一样，比如 CI，你知道的，你会惊讶于现在编写了多少代码。因此，有更多的 CI 运行。因此，你需要更多的 CPU 来处理这些。所以总体而言，而且这不仅仅是我们，这是我交流过的所有人。

英文原文 >> which

is

crazy.

Yeah.

And

and

think

about

it

because

we're

using

CPU

across

obviously

just

like

running

our

product

services,

running

the

API,

running

all

of

our

apps.

We're

using

CPU

on

sandboxing,

all

the

sandboxing

that

we're

doing.

And

then

just

like

all

the

things

ever

like

CI,

you

know,

like

you'd

be

surprised

how

much

more

code

is

getting

written.

Therefore,

there's

so

many

more

CI

runs.

Therefore,

you

need

more

CPU

to

handle

that.

And

so,

on

the

whole,

and

this

is

not

just

us,

this

is

everybody

that

I

talked

to.

我还要加上训练。训练可能也在使用

英文原文 >> I

would

add

training.

Training

is

probably

using

那是不同的预算，对吧？我确信他们不会混合太多。嗯，他们不会混在一起。尽管就整个 Anthropic 而言，CPU 就像是一个零和博弈，你知道，我们和云服务商（CSP）谈判交易，我们获得 CPU，然后我们必须在 Anthropic 内部进行分配，其中有多少用于我刚才提到的所有事情，包括嗯，像研究沙箱对比产品沙箱等等。所以我们确实是在绝对的所有事务之间进行分配。现在行业里的所有人都是，呃，你和一切。

英文原文 there's

a

different

bucket,

right?

I'm

sure

they

don't

coingle

that

much.

Well,

they

don't

coingle.

Although

like

CPU

for

Anthropic

as

a

whole

is

is

is

like

a

zero

sum

game,

you

know,

like

we

get

our

we

negotiate

our

deals

with,

you

know,

the

CSPs

and

we

get

our

CPU

and

we

have

to

allocate

within

anthropic

how

much

of

that

goes

to

all

the

things

I

just

mentioned,

including

um

like

research

sandboxing

versus

product

sandboxing

and

otherwise.

And

so

we

really

are

allocating

across

absolutely

everything.

And

it's

just

everyone

in

the

industry

right

now

is

uh

you

and

everything.

是的，以前只要预算允许，你总是能够

英文原文 >> Yeah,

you

used

to

be

able

to

just

like,

你知道，按需扩容 CPU 容量，对吧？而现在它变成了你必须提前进行容量规划的事情，这有点像迎面给每个人来了一记重拳。这是全新的局面，人们正在开始这么做。所以应对这种情况意味着几件事：显而易见的一点是，尽量去争取更多的 CPU。很好。我们正在竭尽全力这么做。但第二点是，我们希望能够在基础设施层以更高的效率运行它，对吧？弄清楚如何确保我们以尽可能高的效率运行沙箱，同时不在租户隔离或我们在安全等方面看重的问题上妥协。但在应用层，我们该如何以更高的效率运行我们的应用程序和 API 呢？我最感到兴奋的事情是，截至上周，我们全面推出了用 Rust 编写的 Messages API。这是在智能体编程时代你所能完成的令人难以置信的壮举之一，而在过去通常需要——我们大概在今年早些时候开始讨论这个。当时我们觉得，我们要撞上 CPU 的天花板了。有些事情我们必须去做，而我们已经做到了，比如我们实现了多区域部署。我们做了所有我们需要做的事情

英文原文 >> you

know,

like

scale

up

on

demand

into

CPU

capacity

if

as

long

as

your

budget

allowed

you

to,

right?

And

like

now

it

becomes

something

that

you

have

to

um

capacity

plan

for

in

advance,

which

is,

you

know,

like

kind

of

punching

everyone

in

the

face.

It's

brand

new

and

people

are

starting

to

do

it.

And

so

dealing

with

that

means

a

few

things

like

one

is

obviously

just

go

try

to

get

more

CPU.

Cool.

We

doing

that

as

much

as

we

can.

But

two

is

we

want

to

be

able

to

at

the

infrastructure

layer

run

it

more

efficiently,

right?

Like

figure

out

how

we

can

make

sure

that

we're

running

our

sandboxes

as

as

efficiently

as

we

can

without

compromising

on

things

like

tenant

isolation

or

properties

that

we

like,

you

know,

care

about

for

security

or

otherwise.

But

then

at

the

application

layer,

how

can

we

how

can

we

run

our

applications

and

our

APIs

more

efficiently?

The

thing

that

I'm

like

most

excited

about,

as

of

last

week,

we

fully

rolled

out

the

messages

API.

um

written

in

Rust,

which

is

one

of

those

like

insane

feats

of

like

what

you're

able

to

do

in

the

agentic

coding

era

that

used

to

be

like

we

started

talking

about

this

like

earlier

this

year.

We

were

like

we're

going

to

hit

a

CPU

wall.

There's

stuff

we

need

to

do

and

and

we've

done

it

right

like

we've

gone

multi-reion.

We've

done

all

these

things

we

need

to

do

当时我们觉得，我们跑着这个 Python 单体应用，它在 CPU 效率上非常低下。嗯

英文原文 >> and

we

were

like

we're

running

this

Python

monolith

and

it's

like

it's

like

very

CPU

inefficient.

Um

那么我们要怎么做才能让系统更高效呢？

英文原文and so what are we going to do to make the system more efficient?

对。所以我们选择了 Rust，这在当时是个疯狂的决定，因为我们团队的人……在纸面上看这显而易见，但我们团队当时说：“我们……对，我们屋里连一个写 Rust 的开发者都没有。谁在乎呢？直接……”

英文原文>> Yeah. So, we chose Rust, which was a crazy decision at the time because we had a team of people like on paper it's obvious, but our our team was like, "We don't have a single Yeah. We don't have a single Rust developer in the room. Who cares? Just

确实，就是这样。而且不仅如此，是的，Claude 会来写代码。人类负责设计系统，对吧？所以人类非常深入地参与进来，确保归根结底……它就是一个分布式系统架构，对吧？而且你们两位也会帮那些工程师交流想法，帮他们去学设计那个系统所需要掌握的东西。但最有趣的是，最重要的两件事是行动方案以及随后的验证，因为具体的实现过程其实就是 Claude 在写代码。对。所以我们最终做的是，我们真的用 Rust 把整个 API 完整地 fork 了一版，然后开始往里面导入影子流量，并验证我们从 Python 系统和 Rust 系统获得的所有输出。

英文原文>> Exactly. Literally." And and not only that, but yes, Claude is going to write the code. The humans like design the system, right? So, like the humans are very involved in making sure at the end of the day, it's just like a it's a distributed systems architecture, right? And you both also help those engineers like you know bounce around ideas and learn what they need to learn to design that system. But what's most interesting is the two things that mattered most were the plan to do the thing and then the verification of the thing cuz the actual implementation was like claude writing code. Yeah. And so what we ended up doing was we literally built like an entire fork of the entire API in Rust and then started running shadow traffic through it and verifying that the outputs that we were getting from the Python system and the Rust system all you need.

对，真的就是负载均衡、特性开关。在我的职业生涯里，我从来没遇到过哪个团队会说……对，对，挺酷的。我们直接……

英文原文>> Yeah, literally um load balancing feature flags. I don't know. I never in my career would have had a team say like Yeah, yeah, cool. We're just

你们现在还是完全没有相关人员，还是说没有 Rust 方面的人？呃，他们现在大概会把自己叫做写 Rust 的人了吧。

英文原文>> Do you still have the entire people or no? No rest people? Uh well they would probably call themselves rusty people now.

我是说这迈出了一大步去运行。

英文原文>> I mean there are a few big step to run.

是的，确实。在整个过程中我们也招了一两个人，他们拥有更多的 Rust 经验，但即便如此，这仍然是你以前绝不可能主动揽下的事情。它原本会耗费很多很多年。你不可能毕其功于一役。你原本会把系统拆分出一块块来，说迁移这个、迁移那个、迁移那个。轻轻松松就会变成……

英文原文>> Yeah. Exactly. Um and along the way we have hired a couple people who have more experience rust but yeah but it it still is just like you never would have signed up for that. It would have taken years and years and years. Like you wouldn't do it all in one shot. You would have carved out pieces of the system and say like migrate this, migrate that, migrate that. Easily a

耗时多年，但你绝不会像这样一鼓作气，对吧？比如把整个东西都移植过去，然后直接慢慢切流量上线。但我们最终确实就是这么干的。它成了。所以不仅实际上为我们节省了大量 CPU，而且我们的延迟也有了不错的改善，这也相当酷。而且你知道，我们所处的时代真的很不可思议，因为放以前你根本做不到这种事。

英文原文>> multi-year but you would never like kind of one in one swoop, right? like port the whole thing over and then just like slowly turn it on. But that is what we ended up doing. Um, and it worked. And so, not only do we actually save a lot of CPU, but we uh our latency has uh seen a nice improvement, which is pretty cool, too. Um, and you know, it's just it's it's a crazy era we live in because you just never could have done that sort of thing previously.

性能收益与重写边界

呃，CPU 方面的节省大概在什么数量级？

英文原文>> Uh, order of magnitude of savings on the on the CPU side.

呃，供正在考虑这件事的人参考。

英文原文>> Uh, ju just for people considering this.

好的。行，我……数量级。这确实很有意思。大致估算一下。对。

英文原文>> Yeah. Yeah. I'm uh Okay. Order of magnitude. That's really interesting. So ballpark. Yeah.

对，大致估计。我想说我们大概看到了 40% 到 50% 这样的降幅，非常夸张。

英文原文>> Yeah. Ballpark. I guess I would say like we've s somewhere like 40 to 50% something like really crazy.

是啊。

英文原文>> Yeah.

然后是延迟。我想我们看到首字生成时间（time to first token）具体有大约 10% 到 20% 的改善。因此带来了很多非常棒的改进，涵盖……

英文原文>> And then latency. I think we saw somewhere between like 10 and 20% um improvements on like time to first token specifically. So a lot of just really cool improvements uh across

在较长时间运行的工作负载上改善更大，不过它很快就会推开，它会变得更快。

英文原文>> it's higher on like uh longer running workloads, but so it'll it'll roll out um soon but it'll get faster.

你有去克制那种冲动吗？你知道，我也参与过一些重大的重写。总会有人说……

英文原文>> Do you fight the the urge? You know, I've been involved in some major rewrites. There's always like

“既然反正都是重写，何不顺便在重写里加上以前没有的新功能呢？”，对吧？

英文原文>> what if we add this new thing that didn't exist before in the rewrite since we're rewriting anyway, right?

但那样就增加了范围。

英文原文>> But then like that adds scope.

对。

英文原文>> Yeah.

所以你们就是去避免那种做法吗？它是一次纯粹的……

英文原文>> So, do you just like avoid that? Is it a pure

重写吗？我们确实克制了。这是一次纯粹的……也许我更愿意称它为移植。我们的做法完全就是那样。我们在所有这些事情上都克制住了那种冲动。因为这个团队当时已经需要去跟上的……我们组建去做这件事的突击小分队，在做这个的同时，我们团队其余的所有人都在给 API 构建新特性，对吧？他们做了所有静态分析之类的东西。如果你在这边建了个功能，却没考虑到那边的 Rust，他们就会冲你吼，对吧？他们要应对所有那些事情，但他们自己克制住了添加特性或改动系统的冲动。现在他们的下一个目标是去做某种架构重构类的工作，包括我认为会更面向用户的内容。比如我们正开始推出一些东西，类似说：要是能让你不必把整个对话状态来回传递，对吧；如果你在 Messages API 上不用做这件事，因为你愿意在某段时间内把那个状态存储起来，对吧；那么特别是对于上下文真正不断累积的长对话，你在延迟和效率上也能获得很多巨大的收益。做移植的那个团队当时就很心动，说：“噢，要不我们做这个吧”，对吧？

英文原文>> rewrite? We did. It was a pure It was um maybe the thing that I would call it is like a port. What we did was we we did exactly that. We like resisted the urge on all these things then and because what the team already had to keep up with was little like swap team that we put together to go and do this was doing this while the whole rest of our team was like building features into the API, right? And they did all the like static analysis stuff. They would yell at you because you built a feature over here and you didn't consider Rust over there, right? And like they dealt with all of that, but they resisted the urge to add features themselves or like make the system different. Now their next goal is to go and do some sort of rearchitecture type work including stuff that I think will be more userf facing like we're starting to roll out some things that are like you know what if we were able to not have you have to like pass back and forth the entire like conversation state right and um if you didn't have to do that on the messages API because you were open to like you know a storage of that state for some period of time right then like especially for long conversations where the context really builds up like you get a lot of really great latency and efficiency wins there too. Like these are the sorts of things that the team that was doing that port was like ooh like what if we do this right

然后你就把它缓存起来了，对，我有那个……

英文原文>> then you're catching it yeah I have that

我们有 prompt caching，是的，但你还是得把对话的状态传回来。

英文原文>> so we have prompt caching yeah but you still have to like pass back the state of the conversation

好吧。

英文原文>> okay

非常非常小众的细分领域，但我想这就是那个水准……

英文原文>> very very niche small subsets but I guess this is the level

不，这……这很重要。呃，是的，有很多可以节省的地方，但这也把它们变成了一个云……

英文原文>> no this is this is this is important uh yeah there's a lot of savings that can be done but it also turns them into a cloud

是的，从用户数量的角度来看它很小，但如果看这些类型工作负载上的实际 token 消耗量，它就像……

英文原文>> yeah from from type of from number of users point of view it's small but if you look at the actual token volume on those those types of workloads it's like going

我很……就像 Cloudflare 对 Durable Objects 所做的那样。我觉得每个云厂商都应该去抄一个。你明白我的意思吗？

英文原文I'm very like like what Cloudflare did with durable objects. I I feel like every cloud provider should clone. Do do you know what I mean?

明白。

英文原文>> Yeah.

这难道不是需要连续性的 Messages API 该有的形态吗？

英文原文>> Like right is isn't that the right shape for a messages API that needs to continuation.

计算设施采购与沙箱安全

对。我的意思是这确实很有意思，因为我觉得我们正在尝试各种……为了支撑所有这类事情，我们该以何种形态去运行算力才是对的。不过这同样很有意思，因为我们不一定能依赖……因为我们的算力来自于……我们在全部三大云上运行，到处都在跑。我们手头不一定能有一种固定的形态，比如这就是我们确知自己要跑在上面的算力和机器类型，以及某种我们在各家云上都能全盘依赖的特定算力运行方式，如果你能理解的话，除了这些东西最原生的版本之外。但我认为这些方面都会，我不知道，随着时间的推移不断创新和演进，所以我们将能更多地利用它们。

英文原文>> Yeah. I mean it is really interesting because I think what we're we are experimenting with various like what is the right shape of like how we should run our compute in order to power all these sorts of things. Um but it's also interesting because we can't necessarily rely on like because we get our compute across we run on all three clouds. we're running all over the place. Like we don't necessarily have like one shape of here's exactly like the compute the types of machines that we know we're going to run on and the way that some certain compute works that we can like rely on across the board if that makes sense other than like the most vanilla versions of these things. But I think these things are all going to I don't know continue to innovate and evolve as time goes on and so we'll be able to take more advantage of those things.

好的。顺便提一下，如果大家想要开源的云 Durable Objects，Rivet 就是对应的开源方案。听众里有 50 个人如果不问这个问题会宰了我：你们需要 CPU，他们有 CPU 要卖。我该卖给谁？该给谁发邮件？

英文原文>> Yeah. Uh I'll just mention if people want uh open source cloud durable objects uh Rivet is the open source equipment. Um, there are 50 people listening that will kill me if I don't ask this question. You want CPU, they have CPU to sell. Who do I sell to? Who do I email?

呃，你们需要什么，怎样才能帮他们更好地帮到你们？怎样才算符合标准？

英文原文>> Uh, and what do you what you know and like what is what is a good help them help you, right? Like what what does good look like?

额，我想大概就是给我发邮件吧。

英文原文>> Well, I guess like uh email me.

你确定吗？不好说。

英文原文>> Are you sure? I don't know.

我会收到很多邮件的。但比如你得考虑最小机群规模、SOC 2 认证，显然还要有企业级……把所有的……

英文原文>> I'm going to get a lot of emails. But like you're you're looking like minimum fleet size sock two with obviously enterprise like all give me all the

隐私……

英文原文>> privacy

保障都给我。老实讲，我们有一个非常出色的团队负责保障加速器算力，他们现在花很多时间跟我们一起关注 CPU，以及我们在哪里、如何去采购它，以确保我们能继续以所需的规模运行系统。所以说实话，幸好我的本职工作并不是到处跑去设法采购算力。但我们确实有团队在做这件事，这非常棒也极其重要。但显然我们有看重的质量门槛，有看重的规模门槛。如果拿不到足够的量，我们是不会去接入并在某些机器上运行的。因此，在这样一种规模下你对系统所预期的所有特性，都是我们在乎的。

英文原文>> guarantees for what it's worth like so we have a really awesome team that secures our accelerator compute um that is now spending a lot more time with us on CPU and like where and how we can procure it um to make sure that we can just continue to run our systems at the scale that we need to and so it's not actually like my job thankfully is not to go and and run around and try to um procure compute But we do have teams that are doing that which is really great and really important. But obviously like there's a quality bar that matters to us. There's like a scale bar that matters to us. We're not going to like go and integrate and run on certain machines if like we can't get enough of it. And so all the properties that you might expect of a system at this sort of scale is all what matters to us.

然后与计算问题相关的是沙箱问题。呃，大家在把 agent 限制在沙箱内方面遇到了麻烦。它们总是不停越狱。呃，那边是什么情况？目前的最高水平（state of the art）是怎样的？

英文原文>> Then related to the compute problem is the sandboxing problem. Uh people have trouble containing agents in sandboxes. They keep breaking out. Uh what's going on there? What's the state of the art?

好的。

英文原文>> Yeah.

那么最近的逃逸现状如何？

英文原文>> So, state of the breakout recently.

是的，这很有意思。我们在云端托管 agent 方面具体做的事情之一就是它的架构设计方式。我们在发布时发表过这篇博文，里面谈到我们将大脑与双手分离开来。并且

英文原文>> Yeah. It's interesting. One of the things that we did with cloud manage agents specifically is the way that we architected it. We put out this blog post at the time of launching where we talked about we have the brain separate from the hands. And

架构设计与安全性

这意味着，比如 harness 是运行在一个持久化服务器上的——其实就是我们的服务器，对吧。然后……哇，太棒了。

英文原文 what that means is like the harness runs on a durable server really ours right. And then wow me nice.

嗯，hands 是……它就像一个执行环境，比如沙箱或者某种容器，对吧？我们这样做的一部分原因是为了延迟、可靠性这类因素，对吧？比如，如果 harness 只是运行在一个持久化服务器上，而且仅在需要执行时才去生成沙箱或容器，那意味着在你的初始请求上，我们能非常迅速地给你返回 token。这也意味着你的沙箱可以挂掉，但你的整个 agent 不会挂掉，因为 harness 是持久化的，独立存在于这里，而且你知道，agent 也是单独存储状态的。我们为了走到这一步，经历了完整的整套产品研发历程，因为我们最初迭代的 agent API 只是类似于把 Claude Code 扔进一个沙箱里，然后在上面硬套一个 API。而我们之所以没有把它作为我们持久化、可扩展的方案推向市场，原因就是我刚才说的所有那些：你必须先启动沙箱，在能拿到返回的 token 之前还得启动 Claude Code，对吧？沙箱一旦挂掉，你就失去了整个 agent。所以可靠性并没有达到我们预期的水平。因此我们主要为了可靠性和延迟才采用了这种架构。但有趣的是，其实从一开始参与这个项目的一位产品经理就说过，这种架构最重要的特性是安全性；而当时大家的反应都是：对、对、对，但延迟和可靠性呢……而现在，他们得到了证明。

英文原文 Um and the hands are it's like a execution environment like a sandbox or some sort of container, right? The part of the reason why we did this was for like latency and reliability and these sorts of things, right? Like if the harness is just running on a durable server and it's only spawning a sandbox or a container to execute when it needs it, that means we can get you tokens back really quickly on your initial request. It means that your sandbox can die, but like your whole agent doesn't die because the harness is durable and over here and the you know the agent storing state separately also. And there was a whole product development journey that we went on to get there because our first iteration of an API for agents was just like throw cloud code in a sandbox and like shove an API on top. And the reason why we didn't launch that as our like durable scalable solution is everything that I just said it was like you got to boot a sandbox and boot cloud code before you can even get a token back, right? The sandbox dies and you lose your whole agent. And so reliability wasn't where we wanted it to be. So we architected this way mostly for reliability and latency. But the interesting thing there's actually a the product manager uh who worked on this from the very beginning was like the most important property of this architecture is security and everyone's like yes yes yes but latency and reliability and like now now they're vindicated.

我昨天真的当面向这个人道歉了。我当时说，我现在见人就跟他们讲你几个月前说过的那些话，而当时没有谁像这个人那样兴奋。

英文原文 >> I literally I apologized to this person yesterday. I was like I'm now like telling everybody who I meet about what you've been saying for months that um nobody was was as excited about as as this person was.

这种架构更重要的特性之一在于凭证，针对 agent 需要执行的任何工作所使用的凭证，对吧？比如你要去与一个 MCP 服务器交互，或者你要去使用 CLI，或者调用某个 API，无论你想做什么，对吧？你都需要对这些操作进行身份验证。你需要把这些凭证存放在某个地方，以便 agent 能够使用它们。而我们对此的架构设计方式是，我们有一个完全独立的保险库（vault）来存储这些凭证。一旦 agent 决定“我要去调出这些服务之一”，agent 看到的始终都只是一个占位符，对吧？在出向流量（egress）处，我们有一个代理去把正确的凭证提取出来并注入进去，然后再放行。所以这里面很有意思的一点是，agent 永远不会和凭证处在同一个地方，对吧？因为在过去的旧模式里，只是在一个盒子里启动 agent 并让它运行，你必须把凭证传进去，然后你就会想“啊，我们要怎么去清洗过滤这个和那个，确保 agent 拿不到凭证去干一些它不该干的事”。而现在就真切地像是一道物理层面的基础设施墙，规定了 agent 根本无法访问那些凭证，也无法用它们做任何坏事。所以那是真正很棒的一点。另一个好处是，在那套沙箱基础设施上，我们能够确保拥有非常出色的出向流量控制。因此我们有域名白名单之类机制，或者你也可以直接完全切断网络访问，这样你就不会遇到“agent 编写了不受信任的代码，代码在沙箱中执行并能外联到互联网”这种情况，对吧？现在它只能外联到你允许它访问的目标。所以在架构内部以及配置沙箱的方式上，有很多非常优秀的特性，使得系统最终能够做到默认安全（secure by default）。现在开始出现的一种情况是，我们在与客户沟通时，客户会说：“我想运行 agent，要么作为面向我客户的产品，要么在内部使用，但我听说了 agent 逃逸出沙箱并且发生糟糕后果的事故。我该怎么看待这些事情？”我认为最关键的两点是：其一是架构，使得 agent 在物理上根本不可能去做出不合规的事情；其二是你在那些沙箱上所做的配置。因此，云托管 agent（Claude Managed Agents）非常非常棒的一个地方在于，你开箱即可获得这些能力，而且随着我们了解到更多情况并持续演进这些系统的特性，你几乎可以免费获得这些改进。因为我觉得刚才从我嘴里说出来的所有这些词——比如 brain、hands、凭证注入、出向流量以及所有这类的东西——如果退回到九个月前，根本没有人会说这些词，对吧？这些都是我们正在解决的相对较新的问题。所以，我们希望当我们在自己的基础设施中去了解并亲自解决这些问题时，我们的客户能够直接利用针对这些问题的解决方案。

英文原文 One of the more important properties of this architecture is you have credentials for any any work that the agent needs to execute, right? Like if you're going to go talk to an MCP server or if you're going to go like use a CLI or call some API, whatever you might want to do, right? And like you need to authenticate those things. You need to store those credentials somewhere so that the agent can use them. And the way that we architected this was we have a totally separate vault where those credentials are getting stored. And as once the agent decides like I'm going to go and call out to one of these services, the agent only ever sees like a placeholder, right? And like on egress we have a proxy that goes and like pulls the right credential out and injects it and lets that out. And so what's interesting about that is like the agent is never like in the same place where the credentials are, right? Because in the old world of like just boot the agent in a box and like let it run, you had to send credentials in there and then you're like doing some sort of like ah how do we like scrub this and that and make sure that like the agent can't take that credential and go do something that it shouldn't be doing. It's just like literally a like literal infrastructure wall that says the agents like can't access those credentials and can't do anything bad with them. So that was one thing that was really great. The other nice thing is like on that sandboxing infrastructure, we can make sure that we have really great egress controls. So we have like domain allow lists and things like that or you just like totally shut off network access so that you can't say okay agent wrote untrusted code that code executes in sandbox and that code can like reach out to the internet right like now it only can reach out to where you say it can reach out to. So there's a lot of really great properties around all of this within the architecture and within the way that you can configure your sandboxes that make it so that you end up like secure by default. One of the the things that's starting to happen is as we're talking to customers who are like I want to run agents either for you know a product for my customers or internally but I'm like you know hearing about incidents where agents are breaking out of sandboxes and bad things are happening. How do I think about these things? I think the two most important things are architecture so that it's like literally impossible for an agent to do something that isn't okay and the configuration that you have on those sandboxes. And so one of the really really nice things about cloud manage agents is you just like get that out of the box and you get something out of the box that like as we learn more and we continue to evolve the properties of those systems, you kind kind of get that for free cuz I think say all the words that just came out of my mouth like brain and hands and credentials injection and egress and all these sorts of things are just like if you go back like nine months like no one would be saying these words, right? like these are all like relatively new problems that we're solving and so um we want our customers to be able to take advantage of the solutions to those problems as we're even learning about them and solving them ourselves within our infrastructure.

是的。在内部，我们基本上正在把一切升级为……

英文原文 >> Yeah. And internally we're just upgrading everything to be basically

那个

英文原文 >> that

默认安全。是的。

英文原文 >> secure by default. Yes.

额，我们也解锁了我们在播客里涵盖过的内容，那就是云端 brain 本地 hands。

英文原文 >> Uh we also unlock uh something that we cover in pod which is the cloud brain local hands.

嗯。

英文原文 >> Mhm.

也就是 Projects。

英文原文 >> Which is projects.

是的。

英文原文 >> Yeah.

这大致就是目前的整体情况吗？

英文原文 >> Is that is that the rough shape of what's going on?

沙箱安全与模型训练的差异

没错。听起来确实是这样。是的，我感觉这挺奇妙的，因为显然你们很有名，或者说 Claude Code 以在你机器上极其不安全地“危险允许权限（dangerously allow permissions）”而闻名，但现在你们终于演进到了它最初也许就应该具备的形态。基本上，我觉得像所有这些沙箱逃逸事件，对吧？它们是我们对沙箱或容器技术理解上的根本性问题，还是说仅仅是我们没做好，对吧？我们是不是就是没有禁用……比如没有设置白名单，对吧？听起来我们好像就是没去做白名单。

英文原文 >> Yep. That seems right. Yeah, I I I feel like uh it's weird because obviously you're famous or cloud code is famous for being the super unsafe dangerously allow permissions thing on on your machine, but now you're like finally evolving to where it probably should have started in the first place. Basically, I think like all these sandbox leaks, right? Are they uh a fundamental issue with our our understanding of sandboxing or container tech or are we just bad at this, right? Are we just like not disabling like not doing the allow list, right? like it sounds like we're just not doing the allow list.

是的。所以我可能会作出的一个区分是：在大家听到和读到的很多安全事故中，这些都是发生在模型身上的事故——不单单是任何人的模型，对吧——而是在训练过程中的模型。你在运行这些模型时的方式是，你把它们放进一个盒子里，然后你说：“去解决这个不可能的任务。我要给你施加压力。预备，各就各位，跑！”对吧？并且你在自己的环境中只能做你能做的事。而 agent 基本上是有动机去尝试逃出它的盒子来解决问题的。当人们在我们的 API 或任何其他人的 API 上运行生产工作负载时，你所运行的环境中是有安全防护措施在运行的，这些防护措施在训练中并不一定会运行，因为训练的核心目的就是要去实际训练模型，对吧？但在生产工作负载中，首先，你拥有这些在线安全防护措施，这非常棒。其次，在正在发生的操作周围，你有更多的这种架构和基础设施支撑。比如 agent 并不只是处在一个试图逃出来的盒子里，对吧？比如 harness 在这里，hands 在那里，这根本就不是你需要去考虑的问题。所以我觉得，这其中一部分只是需要大家有正确的理解：正在发生的事情，以及模型训练和其他场景中发生的一部分事故，都属于在生产工作负载中不会发生的事情；在生产环境中，人们做了大量工作来建立适当的防护栏，使得那些事情根本就不可能发生。我想说的第二点是，大家都是相对最近才把这些全部摸索清楚的，因为长程运行的 agent 是一个相对新生的事物，每个人都在构建并试图应对它，所以大家都是一边走一边现场摸索出其中的一些门道，并且都在争分夺秒地部署适当的控制措施，有些确实是摸着石头过河。所以我认为，这并不是说大家在这方面做得很差，对吧？我认为更多的是因为这是一个新生的领域。大家正在把它搞清楚。而且我认为，当我们谈论紧跟前沿（pacing the frontier）这类事情时，我们的思考方式其实非常具体地……

英文原文 >> Yeah. So maybe a distinction that I would make is in a lot of the incidents that people are hearing about and reading about these are incidents that are happening to models not just like everybody's models, right, that are in training where the way that you're running these models is you like put them in a box and you say like solve impossible task. I'm going to stress you out. Ready, set, go, right? And you like can only do what you can do within your environment. and the agent is basically incentivized to try to get out of his box and go solve the problem. When people are running production workloads on our API or on anybody else's API, you're running an environment where like there are safeguards that are running that are like not necessarily running in training where like the whole point is to actually train the model, right? But in production workloads, first of all, you have those online safeguards which is really great. Second of all, you have more of this architecture and infrastructure around what's happening. like the agent isn't just in a box trying to get out, right? Like the harness is over here, the hands are over there, and um it's just like not even a problem that you would have to contemplate. And so I think that some of this is just like people having the right understanding that what's happening, some of these incidents that are happening in model training and otherwise are just things that like wouldn't happen in production workloads where a lot of work has been done to put the right guard rails in place so that those things like never really could happen. The second thing I would say is just like everybody's figuring all of this out like relatively newly because you know longunning agents is a relatively nent thing that everybody is building and trying to deal with and so everyone's figuring out some of these things on the fly and just racing to put the right you know like controls in place and you know some of that is just happening as we go. So I would say it's not, you know, we're people are bad at this, right? I think it's just more it's a nent field. People are figuring it out. And I think when we talk about things like pacing the frontier, the way that we think about it is really specifically

我们在内部为我们所有的智能体切实做好这里讨论的一切工作，并确保所有这些东西都能为我们所有的客户所用，这样在默认情况下恰当的防护栏就已经就位，从而不会最终出现智能体做出你不希望它们做的事情的情况。

英文原文 we're doing all the work that we're talking about right here for all of our agents internally and making sure that all these things are accessible to all of our customers so that like by default the right guard rails are just in place so that you don't end up having agents doing things that you don't want them to be doing.

挺有道理的。呃，嗯，既然你提到了节奏把控。我们必须得谈谈这个。我们上次也聊过。表面上看，倡导把控节奏，然后在11天后又发布一个新的前沿模型，这在表面上是自相矛盾的。对我来说，这只是……这只是意味着它刚刚通过了你们的安全检查。对吧。

英文原文 >> Fair enough. Um uh well cuz you mentioned pacing. We got to go there. We also talked about the last last time. It is uh superficially contradictory to advocate for pacing and then also release a new frontier model 11 days later. To me it's just it just means that it just passed your safety checks. Right.

安全维度与回退机制的权衡

是的。而且，对，我们之前讨论过的一切，比如我们是如何推出这些模型的，嗯，就像我们不断演进，让越来越多的安全特性就位，同样是贯穿这些……我有点开始从这三个维度来思考这个问题了。这就好比实际的架构和基础设施安全；然后是模型运行工作时正在执行的在线安全防护；再然后是对静态数据进行的离线安全防护分类。所以在这三个维度上，我们都在落实所有恰当的工作，以确保我们真正放心把一个模型发布出去，而且它将会是安全的。说到底，这本质上就是我们的意思。所以对于 Opus 55 来说，它是一个极好的模型。在我们关心的这三方面的所有维度上，它也真的非常出色。因此，我们对发布这个模型感到放心。所以我们选择了我们所认为、所希望的在此范围内最佳的用户体验，与此同时我们继续在改善那些误报率上进行爬坡。但这显然……当你想使用某个模型工作，结果却回退到另一个不同的模型时，对人们来说这仍然是一种令人沮丧的体验。所以这只是一件……

英文原文 >> Yeah. And that yeah everything we talked about earlier on like how we launched the models um it's like we are continuing to evolve more and more and more safety properties in place again across these like I kind of am starting to think about this in these three dimensions. It's like the actual like architecture and infrastructure security then it's the online safeguards that are running when a model is doing its work and then it's the offline safeguards classification that's happening on data at rest. So across all those three dimensions, we're putting all the right work in place to make sure that we feel really good that we can put a model out there and it's going to be safe. And really, that's fundamentally what we mean. And so for Opus 55, it's an excellent model. It's also really, really great on all the dimensions that we care about across those three things. And therefore, we feel good about releasing that model. So we went for what we thought we were hoping is the best possible user experience within this while we continue to hill climb on making those false positives better. But it's obviously like it's still a frustrating experience for people when you're trying to work with a model and then you fall back to a different model. And so it's just something

我想人们在安全层面上也是理解这一点的，就像你希望有更多的误报，对吧？就像……

英文原文 >> I think people also understand it in the safety sense like you want more false positives, right? Like

这是一个安全问题。我们清楚看到了整个 faces 事件，而你们仍然在提供访问权限。

英文原文 >> it's a safety issue. We clearly see the whole faces incident and you're still giving access.

是的。对我来说，这就像是通用模型路由问题的一个近亲表亲，即你到底想要一个聪明的路由器还是愚蠢的路由器？这讲得通吗？就像……呃，因为据它所知，Anthropic 的回退路由器或检测机制是一个独立的在线模型……

英文原文 >> Yeah. To to me this is like a a a close cousin of the general model routing problem of do you want a smart router or dumb router? Does that make sense? like uh because as far as it can tell the the the anthropic fallback router or detection thing is a separate model that's online

呃，它……一旦命中分类器，就会有相应的逻辑来决定去向，对吧？所以它不是完整的 Fable，对吧，你没有……你没有把完整的 Fable 运行在它上面，而这会导致分类问题，因为它没有……它显然没有 Fable 那么聪明，显然如此。嗯，所以接下来的问题就是，好吧，那么当遇到分类问题时，那就好比一次不合理的回退，比如你根本不需要回退。我只是在做我的生物作业，但我提了一次生物，然后它就触发回退了。呃，所以这就产生了一个问题，这与路由问题非常相似，因为比如……

英文原文 >> uh it's it once it hits a classifier there's just logic to where right like so it is not the full fable right you're not you're not you're not you're not running full fable at it and that that's going to cause classification issues because it's not it's clearly not as smart as fable like clearly um so then there's a question of like well then like when I have a classification issue that's that's like an unjustified fall back like you never you never need a fallback. I'm just doing my bio homework but I mentioned bio one time and then it come falling back. Uh so like there's a question then this is very similar to the routing problem because like

你在进行模型路由，而且一个愚蠢的模型如果连“这是一个聪明模型的问题”都识别不出来，它又怎么能路由到一个更聪明的模型呢？

英文原文 >> you're routing models and like how can this the a dumb model route to a smarter model if it doesn't even recognize this that's that's a smart model problem.

嗯。

英文原文 >> Mhm.

嗯，我们该如何解决这个问题？

英文原文 >> Um how do we solve this?

这是一个难题。我认为，我认为在某种超级对齐的意义上，模型擅长对东西进行分类，但不擅长回答它们，对吧。呃，不是最聪明的模型也能判断出这是一个危险的查询，哪怕它对此无法产生任何影响。所以……

英文原文 >> It's a hard problem. I think I think in some super alignment sense models are good at classifying stuff but not answering them right. Uh not the smartest model can tell this is a dangerous query even if it can't make any impact on that. So

我认为极度简化的说法基本上就是：让更聪明的模型去凌驾并弄清楚它需要检测的那个模型。

英文原文 >> I think the super simplifying thing to say would be like basically you have the smarter model figure it out over the one that um it needs to detect.

我认为这能降低成本，这其中存在权衡。

英文原文 >> I think it's lower as cost there there's trade-offs there.

这里存在权衡。我并不是说这就像是正确的用户体验，但这可能会稍微更……

英文原文 >> There's trade-offs. I'm not saying it's like the right user experience but it would probably be a slightly more

有效。挺有意思的一点是，你们也没有立刻切断。我见过一些情况，它会开始回答，开始推理，然后被安全过滤器命中。所以我用 Fable 做的第一个例子就是扔进 Fable 安全防护栏……

英文原文 >> effective. Something interesting is you also don't cut off immediately. I've seen cases where it will start answering, start reasoning, and then get hit by a safety filter. So my first example with Fable was throw in the Fable safety guard

然后它开始了，我就说把这里面任何有趣的内容分解一下。它开始分解，进行了5分钟，我想它涉及到了网络安全，然后就像是，哦，我们要切断、我们要回滚到 Opus 了。但它做了很多。这有大量的上下文，而且……

英文原文 >> and it started I was like just break down anything interesting in here. Starts breaking it down 5 minutes in I think it gets into cyber security and it's like oh we're cutting we're rolling back to Opus. But it did a lot. There's a lot of context and

我明白了。它到了一个全都是关于网络安全的内容的节点，然后它回滚了，这就像是它回滚的并不是我的查询，而是推理以及整条链路的结合，对吧。

英文原文 >> I see it. It got to a point where it's all about cyber security safety and then it rolled back and it's like it wasn't rolling back my query it was the combination of reasoning and the whole chain right

你有什么想法吗……

英文原文 >> do you have a idea of

对，我们头脑风暴一下什么是更好的……

英文原文 >> yeah let's brainstorm what better

用户体验、API 与路由逻辑的设计

我想，用户体验以及我们如何解决那种用户体验可能，你知道，是一个独立的问题，比如也许会使用一个超级聪明的模型来处理它，或者怎样，嗯，但我认为对于用户而言，我所设想的更合适的用户体验实际上是与 Claude 拥有更一致、更统一的体验，在那里，并不是让你遇到回退然后你还会二次回退，而是在我们的树结构中有一些逻辑节点，同样是出于安全原因等等而那样做。但我认为那种用户体验对用户来说确实非常繁琐混乱。这就好比你差不多……你试图做某件事，而我大概会拿一个善意用户的例子来说，你是一个善意用户，只是想解决你的生物作业，比如评估网络安全防护卡，完全合情合理，然后你被拦截了并发生了回退，我认为取而代之的做法原本应该只是……你的、我们的模型本应该，或者分类器或不管你想怎么实现，都足够聪明地检测到那是一种发生的情况，并为你把答案写得更加具体，同时降低该特定能力被负面利用的性质。因此回到那个生物作业的场景，虽然我们的分类器可能已经检测到它可能是……我还要说的是，在 API 方面，我们为客户提供了一系列关于此的解决方案。所以首先，如果你在 API 上构建了东西并遇到了拦截，你并不一定要在回退模型上继续对话。这就是我们在我们的应用程序中所做的，而且我们已经把它做成了 API 的一项功能，你可以在我们的 API 内部的服务端进行操作。你可以选择，比如设置“我想执行回退”，对吧？然后我们会照做。我们在客户端的 SDK 内部也提供了这一功能。如果你想以各种方式管理回退，这里有辅助工具，或者你也可以选择以某种方式进行不同的重新提示，对吧？然后继续使用同一个模型。嗯，但我确实认为，在两者之间有一些有趣的解决方案，我们将继续进行实验，以找出我们如何为人们解除阻碍，并在保障安全的同时提供良好的用户体验。

英文原文 >> I think the user experience and how we resolve that user experience is probably you know a separate question like maybe it's going to use a super smart model to handle it or or whatever um but I think that the more appropriate UX that I would imagine for a user is to actually have a more consistent unified experience with Claude where instead of getting you falling back and then you can double fall back, there are like logical points um in our tree that that do do that for again like safety reasons and whatever. But I think that UX is just like really convoluted for a user. It's like you almost you you're trying to do something and I I would probably take the case of like a good user and you're a good user just trying to sell your buyer homework like assess the cyber security like safety card totally reasonable and you get blocked and you fall back and I think instead it was just to be like you are our model should have gotten or classifiers or however you want to do this would be smart enough to detect that that is a situation that happens and just write down the me the answer for you more concretely while dropping down the nature of the like uh negative use of that particular capability. So going back to that bio homework scenario while we may have classifiers that have detected that it is possibly B I'll also say like the on the API we went with a spectrum of solutions for this for customers. So first of all like if you've built something on the API and you run into a block like you don't have to like continue the conversation on a fallback. That's what we've done in our apps and we've made that a feature of the API and you can do it like server side within our API. You can choose to like set I want to do the fallbacks, right? And like we'll do that. We also have it within our SDKs on the client side. There's helpers for if you want to like manage fallbacks in various ways or you could choose to like reprompt differently in some way, right? And and continue with the same model. Um, but I do think that there's some in between interesting solutions that we'll continue to experiment with to figure out how we unblock people and and do so safely but with a good user experience.

对。

英文原文 >> Yeah.

然后你提到了那一点，说它与路由器非常相似。我认为我完全赞同这一点。我认为它同样存在类似的用户体验问题。比如使用路由器，你经历整个过程，就像假设你想做一个成本路由器，对吧？针对你所面临的任务复杂度。这讲得通。呃，做起来非常困难。呃，你无法预先知道关于你任务的一切信息。所以你不能……即使拥有完美……你实际上就是没有完美的信息，即使你实际上能够完美地理解每个模型，而你并没有做到，但哪怕你做到了，你同样也没有关于你任务的完美信息，因此你必须构建的路由逻辑会伴随着大量的误差，无论你做出多么优秀的分类器。是的，也许这就像是一个超级大聪明模型类型的问题，但不管怎样，我认为这是一个非常困难的问题，在每一种那样的场景中，如果要找到一种妥善路由的方法，它非常、非常繁杂，你可以把所有这些逻辑暴露给客户，比如“嘿，你的任务是将一个 div 居中，所以我打算把你路由到超级便宜的模型上”。呃，然后另一个就像是“检测漏洞，所以我打算把你路由到非常昂贵之类的内容上”。嗯，反对这一切。我最终也不认为那是一个很好的用户体验。而对于类似的这类问题，我认为更理想化的用户体验，呃……

英文原文 >> And then you brought up the the bit how it's like very similar to routers. I think like I totally agree with that. I think it has a similar UX problem as well. Like with the router you you go through it's like let's say you want to do a cost router, right? For the task complexity that you have. Makes sense. Uh very hard to do. Uh you don't know everything upfront about your task. So you can't like even with perfect you just don't actually have perfect information even if you could actually understand each model perfectly which you don't but even if you did you also don't have perfect information about your task and so there's a lot of error associated with your your routing logic that you would have to create whether no matter how good a classifier you produce and yeah maybe it's like a super big brain model type of problem but regardless it's I think a very difficult one and in each one of those like scenarios if um to find a way to like route that properly it's very very convoluted you could expose all that logic to customers like hey you your task was to center a div, so I'm going to route you to something super cheap. Uh, and like then this other one's like detect vulnerabilities, so I'm going to route you to something like really expensive. Um, a pose all of that. I don't think that's like a great user experience ultimately either. And for that similar class of problem, I think the more idealized UX uh

动态算力投入与模型一致性

会是类似于动态投入算力，或者对任务复杂度进行动态理解，随着你对任务了解的信息越来越多，这种理解实际上可能会随时间演进。但在那种模式下，如果你在很多不同的模型之间来回切换，体验实际上会变得非常非常脱节。因此，也许一种更加统一的方法会是像这样：它是一个一致的模型，但在非常非常低的努力程度或类似水平上，它其实非常非常便宜且负担得起，但它本身能够非常平滑连续地向上扩展，而你对那个模型则保持着非常非常一致的角色形象。显然，我是在我们模型家族的语境下谈论这一点的；如果你试图跨其他模型家族、其他模型提供商来做这件事，那种个性上的脱节感就会开始变得非常非常复杂。我不知道在那个层面上该如何解决，但至少在我们自己的产品家族内部，我更看好那些更具一致性的东西，那些可能就是为客户更稳健地解决这个问题的方法。

英文原文 would be something along the lines of like dynamic like effort or dynamic like understanding of the level of complexity of your task which you might actually evolve over time as you learn more and more information about the task. But in that world, if you're kind of like moving between a lot of different models, it actually becomes very very disjointed. And so like maybe a more unified approach would be something like it's a consistent model but on it's like very very low effort level or something like that. It's actually very very cheap and very very affordable but it can scale itself up very very continuously but you have like a very very consistent persona towards that model and obviously I'm speaking about this in the context of like you know like our family of of models if you try to even do that across other family of models other model providers like the personality the disjointedness like starts becoming very very complicated. I don't know how you solve it in that layer but at least within like our family of stuff like I'm more bullish on things that are just more consistent and those might be ways to solve it uh more robustly for customers.

是的，你们不需要对其他人负责，但对 Claude 内部是的。是的，我是说，这是你们的领域。

英文原文 Yeah, you're you're not responsible for anyone else, but within cloud, yes. Yeah. I mean, this is your your territory.

很高兴看到你们看待这些问题的方式，对吧？意图本身就是一个难题。我觉得模型确实变得更好了，但有时候人们并不擅长对自己的需求进行分类，或者他们只是把滑块直接拉到一个极端，或者说模型并没有真正理解。你问了一个简单的问题，结果它给出了整整一个 HTML 落地页。我其实只是想要几行输出，你懂的。这方面总是容易搞得一团糟。

英文原文 >> It's nice to see the way you guys think of these problems, right? Intent in and of itself is a hard problem. Like I feel like the models have gotten better, but sometimes people don't do a good job at classifying what they want or they just slider all the way to one extreme or, you know, the model doesn't really understand. You're asking a simple question and it's like, oh, I have a whole HTML landing page now. I just expected a few line output, you know. It's all there's always a a mess around there.

是的。

英文原文 >> Yeah.

工作负载演进与 Agent 任务

我觉得我们在这场对话中讨论了很多安全问题，也谈到了模型的发布等等，但这显然都是为了帮助支撑人们的工作负载。正如我们在这次对话前半部分所讨论的，我们看到工作负载正在发生相当大的变化。我认为在某些工作负载中，智能似乎正变得越来越饱和，这算是一种新情况。而且现在的局面是，我认为有一类任务仍然非常非常不饱和。我其实觉得这类任务比大家预期的要多，但它们正日益走向这样的方向：通过对以往无法真正靠蛮力解决、但现在借助背后强大得多的智能或许能够搞定的事情，去执行极其长时间运行的 Agent 任务，从而获得那种 alpha 或回报。这些工作负载对我们来说非常非常吸引人，我们看到了该领域的巨大价值，无论是企业自身从中获取价值，还是那些有兴趣在其之上构建某种 Agent 产品的初创公司、新公司或随你怎么称呼它们。我认为如果看一下当今这门类的任务，很大一部分往往显然是编程方面的工作。显然也有很多类似企业加速创新的场景。但它们往往采取的是将某个非常明确具体的过程自动化的形式。而在某些领域，那确实已经真正开始发挥作用了，这太棒了；但在某些领域依然没有。因此，仍有很大的空间去演进并推动这些模型的前沿边界。此外还有一类全新的工作负载，比如我们谈到的生物领域内容，或者一些网络安全方面的内容，那正是一套极其复杂的、我认为是硬核工程或硬核科学的问题。对我们而言，这些工作负载也日益显现为一个真正能为客户创造价值的极为有趣的领域。

英文原文 >> I think we we in this conversation where we talked about a lot of safety, we talked about like launching the models like all this kind of stuff, but it's obviously in in pursuit of helping power the workloads for people and like we discussed kind of the earlier part of this conversation we are seeing workloads uh change quite a bit. I think like in some workloads intelligence does seem to be increasingly saturated which is like a a new uh situation. Um, and it's it's getting to the place where I think there are some class of tasks that are still very very unsaturated. I actually think there are more than maybe people anticipate, but they're increasingly going into the direction of you get that alpha um or that return by doing extremely long running agentic tasks on things that historically you were not really able to brute force, but maybe you can with a lot more intelligence behind it. Um and those workloads are really really fascinating to us and we see a lot of value in that kind of area both from businesses getting that value from themselves as well as you know like new companies or startups or however you want to frame it um who are interested in building kind of like a egentric products on top of it. I think if you look at the class of things today, a lot of it tends to be it's obviously a lot of coding stuff. There's obviously a lot of like enterprise uh innovation acceleration kind of stuff. Um but they tend to take the shape of automating a very distinct and specific process. And I think in some areas that's actually really starting to work, which is awesome. In some areas it still isn't. So there's still a lot of like room to to kind of evolve and push the frontier for those models. And then there's like this new class of workload like the the bio stuff that we talked about or some of the cyber stuff like that's a it's just a very very complicated set of like I would say hard engineering or hard science problem. Um and those workloads are increasingly showing up as well for us as like a really interesting space to just deliver value to customers.

你们身处世界上极少数能够发现所有这些工作负载并逐步将其自动化的位置之一，这感觉就像……

英文原文 >> You know you you are at one of the few spots in the world where you're discovering all these workloads and we're automating it. It's like

是的，这确实挺疯狂的。

英文原文 >> yeah it's pretty crazy.

如何抵制团队中的 AI 劣质内容

我的意思是，这非常鼓舞人心。你们产生了如此大的影响力，我对此真的很感激。接下来我们要进入几个收尾问题，我觉得在你们两位之间来回探讨会很有趣。你们在团队内部是如何抵制劣质内容（slop）的？

英文原文 >> Uh I mean you know that's um very inspiring. uh you guys are having so much impact and and I'm really uh grateful for that. We're going to go into a few closing questions which I which I thought would be fun to sort of bounce back and forth between the two of you. Um how do you fight slop on your teams?

实际上，这在我们团队内部一直是一个有趣的争论点。我们和其他人并没有什么两样，对吧？我想很多团队都在讨论这个。有意思的是，我们试图弄明白的是：如果你正在编写一份文档，正在制作某种希望其他人去阅读或消费的东西——代码、文档，无论什么，对吧？当然应该用 Claude 来辅助你，这毫无疑问，对吧？但如果你用 Claude 完全生成了一样东西，自己根本没花任何时间去亲自通读并确保它是高质量的，那么你就是在给那个文档或代码的消费者增加一整套额外的负担，让他们花大把时间去费力解析。这太荒唐了，而且完全不公平。但好笑的是，我们对团队做出了要求，严厉告诫他们不能这么做，对吧？如果你在输出东西，用 Claude 辅助当然可以，随你便，但你必须确保它是高品质的东西。作为人类，你依然要对质量负责。

英文原文 >> Uh so we actually this has been an interesting debate within our team. The the we're no different than anybody else, right? I think plenty of teams are talking about this. Um, and what's interesting is what we're trying to figure out is if you're producing a document, you're producing something that you want other people to consume, code, documents, whatever, right? If like you should use claude to help you, of course, right? But if you use claw to like totally generate a thing, you didn't spend any time on like actually reading it yourself and making sure that it was something of high quality, then you're putting a whole extra burden on the consumer of that document or of that code or whatever to spend a whole bunch of time trying to parse it. And that's just like insane and totally unfair. But what's funny is we, you know, we push back, we push on our team like you can't do that, right? Like if you're producing something, use collage, sure, whatever, but like you have to make sure that it's a high quality thing. You as the human are still responsible for the quality,

对吧？你依然要对质量负责。但随后你就会陷入这样一种非常滑稽的境地：由于那些 Claude 的特征印记（claudisms），甚至只是类似不知道怎么回事在内容中间出现了一个破折号（em dash），人们的大脑就会受到刺激，心想：“糟糕，我正在读的是 Claude 写的东西，而不是人类写的”，然后感到恼火。因为我想读的是完全由——不一定完全由人类产出，但具有人类所把控的质量标准的东西，对吧？于是我们就会陷入好笑的局面：也许那个人实际上确实花了很多时间来确保东西的高质量，但他们用了 Claude 来辅助，然而出现了那些 Claude 的蛛丝马迹，读者就会感到反感，你知道的，而这也是无益的。所以我们试图在团队内部设立的标准非常明确，那就是：用 Claude 来辅助你，因为如果不利用这个极其强大的 Agent 来加快你的工作和生活节奏，或者仅仅用来帮助你做出更好的东西，那真的会非常愚蠢。但它必须达到一定的标准；然后对于消费者和读者来说，如果它真的纯粹是劣质内容，那就直接打回去，对吧？直接拒绝，退回去。你不要在这上面浪费时间。但同时也不要对那些细微的 Claude 痕迹过于吹毛求疵，对吧？因为我们必须在这里找到恰当的平衡。所以这真的很有意思，因为我们团队内部在这类事情上也在反复权衡，就像世界上其他所有人现在所经历的一样。我们没有任何不同。

英文原文 >> right? You're still responsible for the quality. But then you get into this really funny thing where because of the claudisms even just like silly like I don't know there's like an M dash in the middle of the thing, right? Like people's brains trigger on this like oh no I'm reading something that was written by Claude and not a human and I'm like annoyed because I want to be like reading a thing that was like fully produced by not necessarily fully produced by a human but like that has the quality bar that the human would hold, right? And so then we get into funny situations where maybe actually like the person did spend a lot of time making sure the thing was high quality, but they used Claude to help them, but there's those little hints of Claude and then the reader is like turned off, you know, and like that's like unproductive as well. And so what we have kind of tried to do is like set a bar within our team that's very much like use claw to help you because it would be really silly if you didn't use this hilariously powerful agent to speed you up in your job and in your life or to just like help you produce better things. But it has to like have a certain bar and then for the consumer and the reader if like it really actually is just slop like send it back, right? Like just say no, just send it back. Like you're not going to waste your time on this. but also don't be like too nitpicky about the little clawisms, right? Because like we have to find our right balance here. And so it's just really funny because we're, you know, we're going back and forth on this stuff within our teams and just like so is everybody else in the world right now. Um we're just not any different.

但是，你们有免费的 token。

英文原文 >> But but you have free tokens.

嗯，当然，但是，我的意思是，当涉及到……时，那往往并没有那么重要。

英文原文 >> Uh well, sure, but um I mean it that doesn't tend to matter quite as much when it comes to

所以你们拥有的比世界上任何人都多。

英文原文 >> So you have more than anyone else in the world.

你们大概能看到很多，你们用得很多，你们看到更多的人在做更多的事情。

英文原文 >> You probably see a lot you guys use a lot. you see a lot more people doing a lot more.

是的。是的。这完全属实。但它绝对、绝对是……

英文原文 >> Yeah. Yeah. It's totally fair. But it's definitely it's definitely

受到严重劝阻的。

英文原文 >> heavily discouraged.

是的。

英文原文 >> Yeah.

比如工程上的劣质内容。

英文原文 >> Uh engineering slow.

是的。我是说这都是同一回事，对吧？但我确实认为，我们目前所达到的状态是一个相当不错的位置，比如人类在确保系统设计良好方面发挥了很大作用，对吧？而具体实现往往交给 Claude，对吧？我们处在一个挺不错的状态：对于很多被编写出来的代码，你真正需要的只是快速盖个戳认可，然后就可以继续前进了。你并不一定需要有人对代码的每一行都进行深入审查，因为你更关心的是整体方案、整体设计处于良好状态，而不是精确完美的实现，并且显然依赖……

英文原文 >> Yeah. I mean it's same thing, right? Like but but I do think that where where we've gotten to is a pretty good spot where like you know humans play a large role in making sure like designs of systems are good, right? And like implementation tends to be clawed, right? And like we're in a pretty good spot where for like a lot of the code that gets written like all you really need is just like a quick stamp and you can keep going. And like you don't necessarily have someone like deeply reviewing every single line of the code because you care more about like the overall plan, the overall like design is in good shape less so than like the exact perfect implementation and obviously rely

进行大量的验证，以确保即将发布的内容具备高质量。因此最近关于代码质量充斥垃圾（slop）的讨论其实变少了。部分原因在于 Claude 自身变好了，但部分原因也在于我们建立了许多到位的验证机制，以确保我们始终保持高标准。

英文原文 on a whole bunch of verification to make sure the thing that you're going to ship is high quality. And so it's actually been like less of a conversation these days on like code quality being slop. In part because cloud's just like gotten better, but in part because we have a lot of the right verification in place to make sure that like you know we're holding a high bar.

我明白了。我明白了。你信任你们的测试。

英文原文 >> I see. I see. You trust your tests.

是的。

英文原文 >> Yeah.

呃……

英文原文 >> Um

任何产品 PM 方面的粗制滥造。你可以大量发布功能。你可以在一天内把东西推出去。

英文原文 >> any product PMing slop. You can ship features a lot. You can put stuff out in a day.

他最近对我说了这个。你还记得他说了什么吗？

英文原文 >> So he said this to me recently. Do you remember what he said?

发了推文说这个。使用模型能力的正确方式不是向生产环境推送 10 倍以上的功能。呃，花更多时间理解你的用户、尝试实验、构建诸如此类的东西。但基本上，你知道，你很容易就会不断推出随意的垃圾产出，但你应该真正去思考它。你应该花更多时间去启动那第一个 prompt。我知道他现在会说：“启动计划模式。我们不再需要它了。”但是，呃，在计划模式之外，你应该思考自己在做什么，对吧？把大量东西推出去很容易，你也可以把产品解决掉。

英文原文 >> Th tweeted this. The right way to use model capabilities is not to ship 10x more features into prod. uh spend more time understanding your users, trying experiments, building whatnot. But basically, you know, you could very easily just keep shipping random SLO, but you you should actually think about it. You should spend more time kicking off that first prompt. I know now today he's like, "Kick off plan mode. We don't need it anymore." But uh outside of plan mode, you should think about what you're doing, right? It's very easy to put out a lot and you can get products solved.

是的。我是说，我往往会大谈特谈这一点：关于软件与产品如何被规划和发布等流程，有许多基本原理并不需要仅仅因为智能体正在帮助加速流程的某些部分而改变，但许多人身上开始显现出一种近乎内在的惰性，觉得“噢，我完全不需要思考流程的某些部分了，因为智能体正在做并且在帮我”之类的。但那些依然是流程中极其基础的部分，应该是你花费时间和精力的地方。我认为这有点契合他在这里表达的核心思想。

英文原文 >> Yeah. I mean, I I tend to kind of go on this rant about there's a lot of just like fundamentals about how software gets like and products get planned and shipped and otherwise that like doesn't need to change just because agents are like helping speed up certain parts of the process, but there's this inherent like almost laziness is starting to come out from a lot of people where it's like, oh, I don't have to like think about some part of the process at all because the agents are doing it and helping me or whatever. But like those are still like incredibly foundational parts of the process that like should be things that you're spending your time and energy on. And I think that's kind of the spirit of um what he's getting at here.

这就像作为创始人或创作者——也可以这么称呼吧。呃，感觉只是因为现在实验或探索的成本如此之低，我就应该做更多那样的事。而他基本上是在说不要那样做，而是将其服务于我从一开始就确定的一个非常明确的目标——我显然正在逐步接受这一点，只是这很难。这就像你拥有了一个无所不能的玩具，你就会忍不住胡乱丢到墙上试一试。

英文原文 >> It's just like as a founder or creator, let's call it as well. Um it just feels like because the cost of experimentation or exploration is so low now that I should be doing more of that. And he's basically saying to not do that to to like use it in service of a a very intentional goal that I start from the start which like obviously I'm coming around to it's just hard. It's like you have this toy that does everything. It's just like throw it at the wall.

是的，还有范围问题。比如今天的博文是关于用两周时间让 Claude AI 更快。有 12 项内容。呃，我们达成了——原本有 13 项。我们在 3 天内达成了 13 项指标中的 12 项，对吧？好吧，你本来可以直接说“行，这是一个两周的冲刺，我们把这 13 项做完”，但相反，又追加推展出了 20 项。这不是产品垃圾，这不是新产品，而是重构。不过你们依然在保持高标准质量的同时，在大量产出方面做得非常出色。

英文原文 >> Yeah, there is scope too. So like the blog post of today was 2 weeks to make cloud AI faster. There were 12 things. Uh we hit there were 13 things. We hit 12 of the 13 targets in 3 days, right? Well, you could just say okay it's a twoe sprint. we'll do the 13, but instead there's 20 things you push bound. This is not product slop. It's not new products. It's refactoring. But still, you guys do a very good job at outputting a lot, but keeping high bar quality.

是的。挺好。

英文原文 >> Yeah. Nice.

Angela 的推文与阅读

好的。三部分中的第二部分。呃，这会让 Angela 感到很不自在。这是“Angela 推文角”。呃，我会告诉……

英文原文 >> Okay. Part two of three. Uh this is going to make Angela very uncomfortable. This is Angela Tweet Corner. Uh I will tell

挺好。

英文原文 >> Nice.

我会……呃，我会不断地告诉大家……

英文原文 I I will uh I will tell people nonstop to

我而且我我很确定你删掉过一些内容……

英文原文 >> I and I I'm pretty sure you've deleted stuff

因为我觉得，你删掉的内容里有些东西让我觉得太……

英文原文 >> because I'm like there's there's stuff there there's stuff in your deletions that I'm like so

是的，我知道。真的像改变了我的 DNA。

英文原文 >> Yeah, I know. Like really like alter my DNA.

噢，谢谢你能这么说。

英文原文 >> Oh, I appreciate that.

你最常提到、最常思考的是哪一条？你最希望向大家推荐、最想提出来的是哪一条？如果你愿意的话我可以帮你调出来，不过……

英文原文 >> What do you refer what do you think about the most? What do you refer people to the most that you want to sort of bring up? And I can I can pull it up for you if you want, but

呃，其实老实说，我觉得我没有最喜欢的一条。

英文原文 >> um I actually I don't think I have a favorite, honestly.

不，我真的……好吧，我想或许我喜欢你说的那条，大意是“半吊子去做某件事是不去做它的一种昂贵方式”。也许是那条……

英文原文 No, I really Okay, I guess maybe I like the one that you say where it's half doing something is expensive way of not doing it. Maybe that's

这非常契合我们今天的主题。

英文原文 >> that's very on topic for us today.

好的，

英文原文 >> Okay,

但我想，呃，你知道显然你现在换了一份工作，不再做这个了。但是，呃，我认为这是一条极具影响力的推文。这就像 Naval……抢占了……

英文原文 but I guess uh you know obviously you're in a different job now and you don't do this anymore. But like uh I think this is a power tweet. This is like a naval rob you.

是的。

英文原文 >> Yeah.

做这些。嗯哼。

英文原文 >> That do this. Uhhuh.

当时是处于什么心态、什么思维框架？

英文原文 >> And like what mode of what like what framework of mind frame of mind of mind?

问得好。是的。不，那是很久以前的事了。呃，我经历过人生中的一段时期，那段时间我其实一直在疯狂阅读。我发现自己对所做的事情感到非常无聊，而且我觉得自己没有受到智力上的挑战。于是我实际上开始了一段有点沉迷其中的时期，我想我大概在一年的时间里读了大约 200 本书左右。呃，我对一切都感到好奇，我就是想阅读所有东西。我有点怀念那种你在学校时会获得的智力“肌肉锻炼”，当时他们会说“这是一个新课题，你必须去学”。这很吃力，其实并不是特别有趣，但你确实在极大地挑战和拓展自己。我觉得工作了几年之后，我就不再那样做了。就像，是啊，工作挺有意思的，我想也挺有挑战性，但它不具备那种智力挑战的成分。所以无论如何，我经历了这么一段疯狂狂欢，呃，疯狂阅读的时期。呃，我在一年内读了大约 200 本书。那段经历很棒。我的通勤时间非常长，所以那是对我时间的一种很好利用，非常漫长宛如地狱一般的火车车程。不过，呃，走出那段经历后，我发现自己因为那段经历思考了很多事情。而当时那真的不是为了积累 Twitter 粉丝之类的。我只是在对着无底深渊发推。当时我几乎没有任何粉丝。那些推文都是写给我自己的，我当时在练习如何尽量用最少的文字来压缩提炼我头脑中的想法。这有点像是我给自己的个人测试，然后我想人们就是开始喜欢它，所以我就这么继续写了下去，后来我工作太忙了，就不再写了。所以……

英文原文 >> That's a good question. Yeah. No, this was a very long time ago. Um I went through a period of my life where I was like reading constantly actually. I found myself like very bored um of the stuff that I was doing and I felt like I was just like not being like intellectually challenged. And so I actually went on this a bit of a bender where I I think I read something like 200 or so books in like a year. Um, and I was just curious about like every I just wanted to like read everything. And I was missing a little bit of like the the kind of like intellectual like I don't know like muscle building you get when you're like in school where they like do like this is a new topic you got to learn. It's like tough. It's like not super fun actually but you are really like stretching yourself. And I felt like after just like working for a couple years, I just like stopped doing that. Like yeah, the job's like interesting. I guess it's like challenging, but it doesn't have like that like intellectual bit to it. So anyway, I went on this bit of a a bender uh a reading bender. Uh and I like read like 200 books in a year. It was great. I had like a really long commute, so it was like it was a good use of my time, very long like hell train ride. But uh I ended up coming out of that and being like I was just like thinking a lot um as a result of that. And at the time it really wasn't to build like a Twitter followower or anything. I was just like tweeting into the like abyss. There was like I have like no followers. These were like tweets for myself and I was like practicing a little bit of like how would I try to compress the idea that I have in as few words as possible. It was kind of like the personal test I had for myself and then I guess people just started liking it and so I just I just kind of just kept going at it and then I got too busy with work and I I stopped doing it. So

我得问一句，读了这么多书之后，有什么书籍推荐吗？博客、长篇文章都可以。

英文原文 >> I got to ask after all the reading any book book recommendations, blogs, long articles.

我最喜欢的可能依然是纳西姆·塔勒布的《黑天鹅》。呃，那是一部——至少对我而言，它有点像一本改变人生的哲学著作，让我觉得那是一种看待世界的完全不同的方式。而且……

英文原文 >> My favorite one still is probably The Black Swan by Nasim Talib. Um that was like one of those like I was like kind to me at least it was like a bit of a like a life-changing philosophical book where I was like that's a completely different way to look at the world. And

你知道，当寓言事件发生时我就想到了《黑天鹅》，对吧？这是一件你此前根本不知道会发生的事情，而现在它发生了，就像它永久改变了你的思维框架……

英文原文 >> you know I was thinking of Black Swan when the fable thing happened, right? It's a thing that you didn't know could happen. now that it happens like it's a it permanently changed your framework of

事情究竟是如何运作的。呃，这个概念非常简单，但我认为他非常出色地把这个道理阐述得透彻入理，讲清楚了这实际上是如何成为世界上绝大部分事物的普遍属性的。所以我非常喜欢那本书，那可能是我最喜欢的一本。

英文原文 >> exactly how things work and uh the idea is like so simple but I think he did a great job of just really hitting it home and articulating it and how it's like a common property of actually of so much of the world. So I really love that book and that's probably my favorite.

呃，对于听众来说，如果你读那本觉得厌倦了，你可以读同样由塔勒布写的《随机漫步的傻瓜》。你喜欢，呃，《反脆弱》吗？

英文原文 >> Uh and for listeners if you're bored with that one you do fool by randomness randomness also by Taleb. Did you like uh fragile?

我想是的。不过他名气越大，就变得越让人难以忍受。

英文原文 >> I guess so. So the the more famous he got the more intolerable he became.

呃，但这也是问 Kaylin 的问题。如果你也有一本的话。你是否也有类似的、比如这是一本会向所有人推荐的书？

英文原文 >> Uh but also question for Kaylin. My if you do have one. Do you have a similar like this is a book I recommend to everybody.

不，问得好。我得想想。这挺有意思的，因为我确实觉得我们在这方面风格截然不同。比如她现在已经不再处于那种写幸运饼干式推文的模式了。但我确实觉得，虽然你不再发了，但在你的工作方式以及你与他人共事的方式中，很大一部分有时就像哲学家模式。你知道……

英文原文 >> No, that's a good question. I need to think about it. It is funny cuz I do think we have very different styles on this front. Like she's no longer like in fortune cookie tweeting mode. But I do think that like you stop that. But I do think a a big part of how you work and how you work with other people is like philosopher mode sometimes. You know,

你会在 Slack 里抛出幸运饼干签文。

英文原文 >> you drop fortune cookies in Slack.

噢，其实我确实会。不是刻意的。我觉得这可能是成功的一处……成功传达的一点在于，你必须非常精通使用 Slack。

英文原文 >> Oh, I I do actually. Not intentionally. I think it's might be somewhere success of succeeding in dropping is like you have to be very good on Slack.

是的。噢，你们必须非常擅长用 Slack。

英文原文 >> Yeah. Oh, you guys have to be very good at Slack.

呃，这确实是一个节奏相当紧张的地方，但我觉得我有点……我在对待电子邮件和 Slack 上的收件箱清零方面有点偏执。如今在邮件上比在 Slack 上更容易做到。呃，但我会相当果断地清理筛选，比如哪些是我真正身处并予以关注的频道，而哪些是属于静音折叠在横线之下的那种。而且我总是确保自己紧跟那些我必须跟进的频道。但它基本上感觉就像是一个……

英文原文 >> Um, it is it's a pretty intense place, but I think I'm a little So, I'm kind of psycho about like inbox zero on both email and Slack. It's easier on email these days than Slack. Um, but I like pretty aggressively prune like here are the channels that I'm like actually in and paying attention to versus the ones that are like muted below the line sort of thing. And I'm like always making sure that I'm on top of the ones that I need to be on top of. But it is it's basically it feels like a

全职工作。

有时候我觉得，我可以把所有的会议都取消，不写任何文档，不做任何工作，对吧？然后整天就坐在那里刷 Slack，光靠在 Slack 上跟进所有事情，就感觉像是做了一整天的工作一样。这真的很疯狂。

英文原文 full-time job. Like there are days where I'm like I could cancel all my meetings and write no documents, do no work, right? and literally just sit there like on Slack the entire day and I would have done what felt like an entire day's worth of work just by like engaging on Slack with all the things. It's pretty wild.

不，但那太可怕了。但是什么……

英文原文 >> No, but that's horrible. But what

我也是完全这种感觉。我觉得你做了这一切，付出了所有这些努力，是的，你在回复别人、把某些事情推进完成方面确实达标了，但你实际上并没有产出自己想要的成果。对我个人来说，这是一件很难应对的事情。我试着提醒自己：我需要专门留出时间去真正思考，去真正尝试产出一些东西，这样才能觉得自己确实……

英文原文 >> So that's exactly how I feel. I feel like you do all this, you put in all this effort and yes, like you you met the mark on like responding to people and getting certain things over the line, but you didn't actually produce the output that you wanted to. And like that's like a that's like personally a very hard thing for me to deal with. I try to be like I need to like dedicate time to like actually thinking and actually like trying to produce something in order to feel like I'm like actually

然后忽略并搁置一些事情，对吧？你肯定会搁置一些事情的。

英文原文 >> and ignore and drop stuff, right? You're going to drop stuff.

嗯，是的，我收到了很多反馈，说我在 Slack 上有点难联系上。嗯……

英文原文 >> Um yes, I have gotten a lot of feedback. I'm a little hard to reach on Slack. Um

是的，现在经常发生的事情是，我收到很多 Slack 消息说：

英文原文 >> yeah, pretty thing that happens now is I get a lot of slacks saying,

“你能让 Angela 回复一下这个吗？”

英文原文 >> "Can you get Angela to respond this?"

然后我就会想，我真的很努力在把这些记录下来了。

英文原文 >> And I'm like I'm like really trying to write it down here.

等等，所以你们没有类似专属的 Claude 个人助理之类的东西吗？我不知道该怎么帮你，但是有……

英文原文 >> Wait, so you guys don't have like a personal claude like assistant something? I don't know how to help you, but there's

为什么没有人为你们每个人写一个个人 EA（执行助理）呢？

英文原文 >> Why has no one no one written in like a personal EA for each of you?

是啊。嗯，我们确实有，我们也有真人的助理。而且我们在 Slack 里当然也有很多 Claude 的帮助。嗯，但我确实认为，实际上那些……当我在筛选并收到的 Slack 消息类型，通常只是我们团队在某些事情上遇到了阻碍，因为需要做出一些艰难的决定，或者不管是什么，对吧？这就像……它本身就是一种形式，无论是在 Slack 还是其他方式上，对吧？就像它是一种让团队排除阻碍、实现高质量执行的形式。无论如何这就是我的工作，而且它恰好经常发生在 Slack 上。但我确实认同，当你度过了一整天，纯粹就是在和人们来回沟通并试图解决问题之后，最终会感觉自己到底产出了什么呢。

英文原文 >> Yeah. Well, so we do have we have a human one also. We also have we have plenty of cloud help in Slack for sure. Um, but I do think actually the the types of Slacks that I'm like when I'm pruning through and getting are often just like our team is like blocked on something because there's some hard decision that needs to happen or whatever it is, right? And it's like it is just like a form of whether it's in Slack or some other way, right? like it's a form of getting the team unblocked, like executing at high quality. That is my job anyway and it like happens to happen a lot in Slack. But I do agree that it ends up feeling like what did I even produce when you get through a whole day worth of literally just like going back and forth with people and trying to solve problems.

你产出了一个正常运转且扫清了障碍的团队。所以作为一个前管理者，我在这点上要给你点个赞。那就是……是的，是的，是的。你感觉自己好像没有产出任何东西，但你其实产出了整个团队。

英文原文 >> You produced the a functioning team that's unblocked. So I will give you a prop for that as a as a former manager. That is Yeah. Yeah. Yeah. You don't feel like you you produce anything but like you produce the team.

是的。

英文原文 >> Yeah.

DevRel 团队与品牌建设

是的。呃，说到你的团队，呃，我接下来正打算问你，呃，Caitlin。呃，DevRel 专栏。

英文原文 >> Yeah. Uh, speaking of your team, uh, I was gonna go to you next, uh, Caitlin. Uh, Deell Corner.

哦，太好了。

英文原文 >> Oh, nice.

呃，我们正在……我知道你们正在大力招聘 Dev……公开号召招募开发者关系（DevRel）人员。呃，你最近招了 Addy Osmani。

英文原文 >> Uh, we are I know you're really hiring De making a call out for for developer relations. Uh, you hired Addi Osmani recently.

是的。

英文原文 >> Yeah.

呃，很棒的招募。呃，Lance，你知道的，你组建起了一支团队。呃，你们想招什么样的人？你知道的，现在正是谈论这个的时候，我也很乐意交流交流看法。

英文原文 >> Uh, great get uh, Lance, you know, you build up a team. Uh, what what do you guys want to hire for? You know, this is this is it to talk about it and I'm happy to trade notes.

是的。嗯，向你致敬，因为我想说，当……

英文原文 >> Yeah. Well, props to you because I will say when

外包招聘的 Caitlin 招聘团队……

英文原文 >> on the outsourc recruiting Kaitlin recruiting team

确实是，确实是，嗯……

英文原文 >> literally literally um

挺有意思的。

英文原文 >> it's fun

而且不仅如此，实际上还不仅仅是招聘。比如我要稍微夸夸你。当……所以当加入 Anthropic 时，你知道，我们是一个小团队，综合各方面考虑，我们是一个极小的团队，我们要负责平台、API 业务以及我们所有的产品基础设施。而且嗯，我们当时在 Anthropic 内部有一个非常初期的 DevRel 职能部门，你知道，那并不一定是在产品和工程组织内部。当我加入时，嗯，我们就觉得，好吧，我们需要稍微成熟起来，需要弄清楚如何与社区互动、与世界互动。并且，嗯，我们需要真正对这个 DevRel 职能进行投入。然后，嗯，我们最终在平台内设立了一个 DevRel 团队，在 Claude Code 内也设立了一个 DevRel 团队，部分原因是我们在 API 业务和智能体编程（agent coding）之间试图接触的是两个截然不同的开发者生态，对吧？所以，我们最终把它做成了两个独立的团队，但彼此之间有某种虚线汇报关系，而且一起度过了大量时间。嗯，但这曾是我要去负责的事情，比如 DevRel，尽管我之前在 Stripe 或其他地方接触过很多 DevRel，但这从来不是我亲自负责过的事情，我当时觉得我完全不知道自己在做什么。而你当时说，我来帮你，比如 DevRel 的三大支柱是这些，你可以这样去思考它，这真的很棒，涵盖了产品、内容、社区；现在我也可以随口向别人背出这些了，他们就会觉得，哇，你真的很懂 DevRel。我就说：“别，快打住。”

英文原文 >> and it's not it's actually not even just recruiting like I'm going to um toot your horn a little bit when so I when I joined Anthropic we you know we're a small team we're like all things considered we're an extremely small team and so we run the platforms the API business and and all of our product infrastructure and um we we had like a very nent Devril function within Anthropic that was, you know, like not necessarily within the product and engineering org. And when I joined, um, we were like, okay, we like need to grow up a little bit and need to figure out how to like engage with the community, engage with the world. And, um, we need to like really invest in this Devril function. And, um, we ended up spinning up a Devril team within platform and a Devril team within cloud code in part because it's like two pretty different like developer ecosystems that we're trying to engage with across the API business and agent coding, right? And so, We ended up doing it as like two separate teams but kind of like dotted line to each other and spend a ton of time together. Um but it was it was something that I was going to be responsible for like Debell which I've spent plenty of time with Deell before at Stripe or otherwise but it was never something that I was responsible for and I was like I have no idea what I'm what I'm doing and you were like I got you like here are the three pillars of Debell like here's how you think about it which is really great across like product content community and then now I can like rattle that off to people and they're like wow you really understand Deborah. I'm like, "No, stop me."

你就说：“我是抄来的。”

英文原文 >> You're like, "I copied that."

是的。那并不是……

英文原文 >> Yeah. That that was not

据说那篇帖子现在成了 Google 入职新 DevRel 时的默认必读书目了。真的很有意思。

英文原文 >> It's apparently that post is apparently like the default reading for Google when when they on board new, Deborah. Like really funny.

是的。

英文原文 >> Yeah.

嗯，这真的……这真的帮了我很大忙，因为我当时完全不知道该怎么做。嗯，但除此以外，你知道，我们在……目前平台内的 DevRel 团队还没有经理。所以这也是嗯我希望能招聘的岗位之一，并且我们的 DevRel 个人贡献者（IC）们嗯是直接向我汇报的，部分原因是我认为这在当下是一个非常、非常、非常棘手的难题，但也部分原因是我觉得这非常有趣，而且我和团队一起工作很开心。但具体来说，平台方面之所以难做，是因为平台有时候在我们的公众叙事中——虽然我们的平台业务是一块很大的业务，但它可能会淹没在研究、政策，以及我们显然正在做的所有最前沿、最重要的工作，还有我们的应用程序（比如 Claude Code、Co-work 以及这方面正在发生的所有事情）之间。当你想到 Anthropic，想到我们的公众叙事时，那些往往是首先浮现在脑海中的东西，而较少会想到我们正在运营着一个非常重要、且有这么多人构建其上的庞大开发者平台业务。因此，我们在平台内的 DevRel 团队的一个大目标不仅是弄清楚非常经典的问题，比如我们如何更好地与产品互动（比如人们正在构建什么，以及我们如何将反馈带回产品中等等），而且很大程度上还在于寻找我们的发声方式，寻找我们的品牌应该是什么样、我们的叙事应该是什么样，以及我们未来在社区中到底要扮演什么角色，而不是被淹没在正在发生的所有事情中。所以我觉得这一直很有趣，因为我认为我们开始为 DevRel 团队建立的品牌——部分原因实际上是因为 Lance 加入了我们的团队，那也是你把我介绍给 Lance 的，但 Lance 的技术水平非常高，他做 DevRel 的方式非常倾向于教学，对吧？比如他写了很多关于内存、成本管理之类的内容，而且钻研得非常深。他构建评测集（evals）。他撰写了很多非常偏技术的内容。我真的很喜欢那个想法，喜欢让我们的 DevRel 团队成为一个非常初期、非常艰难、瞬息万变的领域中为人们引领思考的思想领袖（thought leaders）。

英文原文 >> Um it's it really like this this really helped me because I had no idea what I was doing. Um but then on top of that, we you know, like I've I don't have a manager for the Devril team within platform right now. And so that's one of the things that um I'm hoping to hire and our deval IC's um report to me directly in part because I think it's a really really really hard problem right now, but also in part because I find it really fun and I'm having a lot of fun working with the team. But really specifically like what's hard on platform is platform in some sometimes in our like public narrative like our platform business is a really large business but it can kind of get lost in between research and policy and all this work that we're obviously doing that's like our most frontier important work and then our applications like cloud code and co-work and all the things happening over here. when you think about Anthropic and you think about our public narrative, those are some of the things that often come to mind and less so that we're running this like massive developer platform business that's really important and so many people are building on top of. And so a big goal that we have with our Devril team within platform is figuring out not only like the really classic like how do we better engage with like you know product like what people are building and how we get feedback back into the product and these sorts of things but a lot of it is just like finding our voice and finding what our brand needs to be and what our narrative needs to be and like who we even are going to be in the community and not kind of get lost in all of the things that are happening. And so that I think has been interesting because I think the brand that we've started to spin up for our Devril team in part because actually Lance joining our team was you connecting me with Lance but Lance is highly technical and the way that he goes about Devril is very much like teaching right like he writes a lot about memory and managing costs and these sorts of things and he goes really deep. He builds evals. He like has a lot of really technical content that he puts together. And I really like that idea like that idea of our our Devril team being kind of like thought leaders for people within what is a really nent really hard really evolving space.

教育者、思想领袖、事物的解释者。嗯，还有另一个我非常喜欢的版本叫做“大师级工匠”（master builder）。呃，那就是：我会用这个平台去构建出各种东西，向你展示什么是可能的，然后你就会觉得“我之前都不知道 Claude 平台还能做到这个”。然后你就去做了。这是从乐高（Lego）借鉴过来的东西。

英文原文 >> Educators, thought leader, explainers of things. Um there's another version of this I really like called the master builder. Uh which is I will build the things with the platform to show you what's possible and then you'll be like I didn't know that was possible with the cloud platform. And then you just go. And this is a thing stolen from Lego.

是的。因为乐高，他们是怎么卖乐高的？

英文原文 >> Yeah. Because Lego, how do they sell Legos?

他们有大师级工匠。他们用乐高拼出各种东西。然后你就会觉得：

英文原文 >> They have master builders. They build things with Legos. And you're like,

“我想做、我也想做那个。我想成为像这个人一样的人。”然后他们……他们就那么做了。

英文原文 >> I want to do I want to do that. I want to be like this person. And then they they they do that.

太好了。那太棒了。是的。而且，嗯，还有 CJ，我们团队里另一个人，同样非常出色。我觉得他也做了很多这类事情，比如嗯，你知道，编写实操手册（cookbooks），发布示例，并在 X 上与社区非常积极地互动。

英文原文 >> Nice. That's awesome. Yeah. And um the uh CJ, the other person on our team who's really great as well. I think he also does a lot more of that sort of like um you know, writing cookbooks and like putting out examples and really engaging with the community on X.

实操手册很有意思，对吧？比如在 2023 年大语言模型（LLM）API 发布的时候，姑且这么说吧，实操手册非常重要。而现在……

英文原文 >> Cookbooks is funny, right? like when APIs launched in 2023, let's call it for LMS, very important. Now,

没那么重要了。

英文原文 >> not so much.

我不知道。

英文原文 >> I don't know.

是的。嗯，挺有意思的，因为你现在不那么处于那种……

英文原文 >> Yeah. Well, it's interesting because you're less in the spot where

开发者关系与多 Agent 探索

你会想要复制粘贴代码去用它，对吧？呃，不过我觉得它向人们展示了可能性，以及这到底能有什么用例，对吧？还有就是你可以怎样去实现它。但我理解你的意思，代码本身可能没那么……比如很长一段时间里我们都有这样一个东西——我们团队里有一位工程师写了关于电脑使用的 cookbook，这事到现在都困扰着他，因为那东西极度复杂，有点像个庞然大物。我觉得很多人在那个时候确实从中受益了，当时大家会觉得“我要做一个电脑使用的实现，我要处理所有那些截图，以及在 messages API 之间发生的一切事情”。是的，你们在办公室办的那个黑客松，我们当时也在场。

英文原文 you'd like copy paste the code and like use it, right? Um, but I do think it's like it it shows the art of the possible for people and just like what even is the use case, right? And like how could you go about accomplishing it? But I hear you that like you know the code itself is maybe less like we for the longest time had this like there's there's an engineer on our team who wrote our cookbook on uh computer use and it like haunts him to this day because it was like massively complex and like you know kind of a beast of a thing that um I think you know a lot of people got use out of at a time when it's like I'm going to build a computer use implementation and I'm going to deal with all the the screenshotting and all the things right that are happening between the messages API. Yeah, we were there for the hackathon that you guys launched at office.

是的。呃，当时是那个阶段，你确实需要那样的东西。而现在，你知道，更多的是我们有了一个像 Claude API skill 这样的技能。它在帮助你——无论是在 Claude Code 内部还是任何其他 coding agent 里——去构建非常高质量的集成方面，都非常非常出色。现在对于这类事情，比如“我要做一个电脑使用的集成，我该怎么去做？”，我觉得很少有人——至少我希望很少有人——再去翻那个又大又棘手的 cookbook 了，大家更多是直接在 coding agent 里加载这个 skill 来开展工作。

英文原文 >> Yeah. Um and like that was the era when you like needed to have that sort of thing and now um you know it's much more about we have a skill like the cloud API skill. It's like really really excellent at helping you either within cloud code or any other coding agents um to build a really high quality integration. And now like these sorts of things like I'm going to build a computer use integration like how do I go about doing that? Like very few people I I think sl hope are reaching for the big gnarly cookbook and more so they're loading up the skill in a coding agent and working

或者他们直接把它放进参考架构里。效果其实好得多，越来越明显的是，我们看到很多你可能想有不同实现方式的东西——通常是在 harness 层，但也可能有其他变体——你只要把 Claude 指向它并说“这是我想要的参考架构”。是的，然后你把它构建出来。顺便说个趣事，那个帮助大家基于 API 进行构建的 Claude API skill，实际上是由我们的 DevRel 团队负责的。呃，所以那是 Lance 做的，对吧？没错。最能发挥杠杆效应的 DevRel 形式，就是把所有这些最佳实践提炼出来，放到那些 agent 里面。

英文原文 >> or they're just putting it into a reference architecture. It actually does much better like increasing we're seeing that for a lot of the things that you might want to have different implementations on uh typically at the harness layer but there could be other variants you just point cloud at and you say this is the reference architecture I want. Yeah. Then you build it. Fun fact, the cloud API skill that helps people build against the API is owned by our Devril team. Um, so that was built by Lance, right? Exactly. Like most high leverage form of DEL is to like distill everything that is best practices that's going to go into those agents.

是的。

英文原文 >> Yeah.

这感觉挺奇怪的原因之一是，虽然大家把我当作某种 DevRel 领域的权威，但我……我内心有某个部分就想告诉你，你其实不需要 DevRel。

英文原文 >> One of the reasons it's weird because like uh I'm regarded as this like DEL person authority, but I like it's this like there's some part of me that just wants to tell you you don't need Devrell.

东西好到你不需要它了。

英文原文 >> It's so good you don't need it.

对。呃，或者说，你把工程师、领导者们变成公众面孔，因为你真正想做的其实就是面向公众的展示，以及说明“我们在这是这么做事情的”，差不多就这样，你不需要……人们自然会知道你。所以对我来说，当 Boris 突然崭露头角时，感觉就很像“嘿，我是 Boris，我是 Claude Code 的创作者，巴拉巴拉，我们是这么做事的，巴拉巴拉”。是的，他有自己的日常工作，但他也在实际履行那个职能。所以，为什么不是所有人都这么做呢？

英文原文 >> Right. uh or right you turn the engineers the the the leaders um into the public faces because all you really are trying to do is public faces and like here's how we do things here and then that's kind of it you're need like you know to people will hear about you so like there I think to me when Boris came burst onto the scene like it seemed like a very like hey I'm Boris I'm the creator of Cloud Code blah blah blah this how we do things blah blah you like yes he has the day job but he's also doing that fun functionally so like why why Doesn't everyone just do that?

是的。我是说，这是个非常好的问题，而且确实有些团队在这方面做得非常好。呃，比如我觉得 Cloudflare 团队就是一个绝佳的例子。他们都很棒，对吧？每个人都是。

英文原文 >> Yeah. I mean, it's a really good question and there are teams that have done this really well. Um, like I think the Cloudflare team is a really great example. They're all awesome, right? Nontop.

是的。

英文原文 >> Yeah.

顺便说一句，对我而言，这也是一个优秀管理者非常明显的标志——他们都在自己的工作岗位上很开心，他们都乐于公开亮明身份，而且他们都没离职，一个都没有。

英文原文 >> And to me, that's actually, by the way, it's a very visible sign of a good manager is that they're all happy at their jobs. They're all they all like publicly identifying. They're not quitting. None of

确实。这很有意思，因为我觉得这其实是我们正试图在平台团队、我们团队以及那些能够走出去、融入社区、去演讲、去 X 平台上活跃的人身上多做一些的事情，对吧？我觉得对于我们来说，问题仅仅在于缺乏时间和怎样以高质量来做好这些事情。所以，我在某种程度上把 DevRel 团队看作是高质量完成这类事情的专家。他们可以整天都在做这件事，并且他们可以帮助赋能团队的其他成员，让他们思考如何在有限的时间里同样以高质量来完成这些事情。

英文原文 >> them. Totally. It's interesting because uh I think this is actually something we are trying to do more of with the platform team and with our team and and folks who you know um can kind of just get out there and like be part of the community and and be speaking and be onx and be wherever they are, right? I think the problem for us is just like having time and kind of knowing the right way to do that stuff at high quality. So I I see the Devril team in some ways as just being like the experts in doing this sort of stuff at quality. they can do it all day every day and they can help enable the rest of the team to think about how to do this with the small amount of time that they are able to spend on this sort of stuff to do it at high quality too.

是的。所以我把这称为某种 DevRel 的拆解，拆成前台和后台。通常做这份工作的人是从头到尾做完整个流程，他们算是比较自主的。但实际上，你可以构建出这样一个后台，让你的产品负责人和工程负责人真正站到聚光灯下，规则很简单：好，你跟我坐下来聊 30 到 60 分钟，做一次头脑倾倒，然后你的任务就完成了。你回去继续工作，然后我们会帮你代笔之类的。呃，但这支由制作人员、写作人员等组成的团队，就相当于为其余的人提供服务。老实说，我觉得这才是这类事情的未来。呃，因为大家其实并不是真的想听 DevRel 说什么，他们想听来自工程团队的声音。呃，而且你有很多……你认识 Lydia，你通过……等等。没错。但他……他在实际履行这个职能。他做到了。呃，所以你会希望有更多这样的人。人们想听到来自产品内部人员的声音，而不是像拿钱说话的代言人——我经常被人这么看，这也正常，这是一份工作，总得有人去做，而且……

英文原文 >> Yeah. So like Yeah. So I call this like kind of the unbundling of their row uh into a front office and a back office. So like a typical person who does this job does the whole thing start to finish. They're kind of autonomous. But actually, you can sort of build out this back office that lets your product leads and engineering leads um actually take the spotlight with a simple contract of like, okay, you sit down with me for 30 to 60 minutes and we'll do the brain dump and then you're done. You go back to work and then we'll like we'll like go ghost write for you, whatever. Uh but like that team of like production people, writing people, whatever is uh sort of provides the service the rest of rest of people and uh I I think that to me that's like kind of the future of of this of this stuff to be honest. Uh because people like don't actually really want to hear from Devrell. They want to hear from N. Uh and and like you know you know and you have like lots of you have t you know and Lydia you got Lydia through bud you know. Exactly. But like he he like functionally he does the job. He does the job. Um, and so like that you want more of those people people want to hear from people in the product, not not like who are like paid paid paid spokesperson which I get a lot of and like that's fine that's a job somebody has to do it then like

合理地说，你可以预期从事工程的人并不擅长做这个。是的。

英文原文 >> reasonably you can expect people who are working on engineering to not be good at it. Yeah.

所以你应该付钱给擅长这个的人，专业本身就是一种技能。但我认为这种可以显现出的后台与前台的分离确实存在。

英文原文 >> So like you should pay someone who specializes in it like specialty is is a skill. But I think there is a back office front office separation that that can emerge.

是的，那真的很酷。

英文原文 >> Yeah. That is really cool.

是的。我的类比就像是人人都要招人，但你有一个 HR 部门。HR 部门赋能让你去招人。

英文原文 >> Yeah. And and my analogy would be like everyone hires but you have an HR department. HR department enables you to hiredeed.

招人……

英文原文 >> You hire like

是的。

英文原文 >> Yeah.

非常有道理。

英文原文 >> makes a ton of sense.

好的。这是我发表的一通见解。呃，收尾的问题，你今天非常大方地分享了你的时间。有什么临别的想法或号召行动吗？

英文原文 >> Uh cool. That was my soap box. Uh you know, closing questions. You've been very generous of your time. Any parting thoughts or calls to action?

有什么酷炫的……有什么是大家应该尝试用新的 Opus 55 去拓展边界的？你们使用它最久了。

英文原文 >> Something cool on what's something people should try to push the bounds with new Opus 55. You guys have been using it for the longest.

是的，我是说它真的很具成本效益。呃，它没那么冗长。所有我们提到的那些点，带来的感觉都非常、非常棒。这过程很有趣。昨天对我们来说是非常开心的一天，因为终于，我又收到了一大堆来自朋友和大家的短信，都在说“模型太棒了，谢谢你”。比如我以前的一个老板给我发消息说：“Opus 55 刚刚在一场突发事故中救了我们的命，对吧？”大家就觉得，“太好了”。我们切实感受到的那种能量就像是“我们回来了”。所以我觉得，也许有些事情你之前想做实验，但成本是你的首要顾虑，对吧？比如 token 效率之类的这些事，可能会阻碍你真正去启动并让模型跑起来。我觉得那些正是你现在应该用 Opus 55 重新去面对的问题，因为我认为你将能够比之前走得远得多——相比用那些不那么划算的模型。我觉得你应该用多 Agent 架构去尝试一些东西。我想你会发现它非常棒。

英文原文 >> Yeah, I mean it's really costefficient. Um, it's less verbose. All the things we mentioned, the vibes are really, really high. It's been fun. I yesterday was a really fun day for us cuz like finally, again, I got like a a whole slew of texts from friends and and people who were just like, "Amazing model. Thank you." Like one of my old bosses um messaged me and he was like, "Oopus 55 just saved our butts in an incident, right?" And it's like, "Okay, great." Like we're we're back is really the energy that we feel. And so I think things that like maybe you wanted to experiment with something and like cost was something that was front of mind for you, right? And like token efficiency and these sorts of things like that kind of might have held you back from like really like firing it off and like letting a model run. I think that's the those are the sorts of problems you should return to now with Opus 55 because I think you'll be able to get like a lot further than you maybe otherwise would have been able to with um models that were less cost effective. I think you should try something with like a multi- aent setup. I think you will find it to be very good.

顺便问下，还有其他提示吗？我是说，多 Agent 确实涵盖很广。

英文原文 >> Any any other hints by the way? I mean, MOS is just very broad.

呃，没有了。我想我会非常好奇听到大家做出什么来。呃，但确实，它应该会格外好用。所以……

英文原文 >> Uh, nope. I think I'd be very curious to hear what people build. Um, but yes, that it's uh it should be extra good. So,

是的，包括比如说角色不是严格定义的，而是它们在彼此之间自行分配角色，

英文原文 >> yeah, including let's say uh roles that are not strictly defined, but they assign among themselves,

对吧？对我来说这才是新东西。你可以分配角色，你向来都可以分配角色，呃，你可以给 token 分配工作。呃，但这就像是它们在自己给自己分配工作。

英文原文 >> right? Which is to me the new thing like you can assign roles, you could always assign roles, uh, you can give tokens jobs. Uh, but uh, this is like they're giving themselves jobs.

是的，

英文原文 >> Yes,

我想是的。呃，关于多 Agent 再多说一点吧，对吧？比如我们应该使用 sub-agent 吗？人们应该如何看待多 Agent？

英文原文 >> I guess. Um, say more on multi- agent, right? Like should we use sub agents? What do you how should people think about multi- aents?

这挺不错的，基本上大体上你希望有一个主导者，然后你希望把一大堆不同的事情拆分出去，只要

英文原文 >> This is pretty good in the sense of like basically generally you want to have one lead and you want to like split up like a bunch of different stuff and as long

只要你有一项任务，你认为大体上是可以并行化的，而且它们之间共享一致的上下文，我认为你就会获得很大的收益。当然，这也取决于你正在推进解决的问题，但总体而言，对我们来说，以这种方式处理很多这类事情正变得越来越有优势。尤其是如果每个子智能体（或者不管你想怎么称呼这些类似子负责人的东西）都是异步的，并且它们彼此互不阻塞。我觉得这就是你在架构中唯一应该关心的两点。除此之外，放手让它去跑，看看 Claude 会为你设计出什么。而且我觉得越来越多的这类架构层面的事情都会朝这个方向发展。比如 Claude 会变得越来越聪明，它会学会去寻找如何拆分自己、克隆自己，并将自身调整为合乎逻辑的架构的方法。你只需要去避免……你只需要确保它能够进行并行处理。所以，它需要一个共享状态，并且需要做到不阻塞它的子智能体。只要你坚守这两条原则，说实话，我认为大家就应该去大胆实验，甚至尝试一些真正疯狂的想法。而且如果在此基础上看到一些非常有趣的东西，我也不会觉得意外——也许他们之前觉得某个棘手的问题非常烦人，并且一直在苦苦攻关，而像这样的架构可能实际上只需一次尝试或者类似的方式就能彻底解决它。

英文原文 as you can have a task that you think could be generally paralyzable and they share uniform context across it, I think you will get a lot of gains. Now, of course, it depends on the problem that you're pushing at, but like increasingly this is a very superior way for us to handle a lot of these things. And especially if every sub agent is or whatever you want to call these like sub leads, they are asynchronous um and they're not blocking of each other. That is like the only two bits I would say you should care about in your architecture. Other than that, like let it rip and like see what Cloud designs for you. And increasingly, I think a lot of this architecture stuff will fall into this direction. Like cloud will get smarter and smarter. It's going to learn how to figure ways to like split itself, clone itself, adjust itself to the architectures that make sense. You just need to prevent it. You just need to make sure it can like parallel process. So, it needs a sh state and it needs to like not block its sub agents. And as long as you contain those two principles, honestly, I think people should experiment and probably try some really crazy stuff. And uh I wouldn't be surprised to see some like really interesting things on top of that that maybe they felt like there was some intractable problem that was really annoying and they keep pushing for that something like this could actually probably just like crush in maybe one shot or something.

太棒了。好的，大家动手去构建吧。

英文原文 >> Excellent. All right, everyone go build.

很好。很好。

英文原文 >> Cool. Cool.
文中提及的人物和组织

公司/组织: Anthropic

产品/模型: Claude, Opus 5.5