Anthropic 工程与产品负责人谈 Opus 5.5 发布与 Claude 智能体架构

← 阅读室Latent SpaceAnthropic 如何用 Claude 打造 Claude：将大脑与双手分离

Katelyn Lesse 与 Angela Jiang 谈 Opus 5.5、Claude 平台以及 AI 智能体背后的工程。swyx .ai10月27日·104 分钟阅读播放视频

在 YouTube 上打开视频 ↗

在 YouTube 上观看完整节目

正如我们昨天从 Anthropic 的 S-1 申报文件中了解到的，这家实验室拥有人类历史上最高的营收与研究效率之一，尤其是过去一年从 -126% 亏损到 19% GAAP 盈利的扭亏为盈。公司将这归功于他们的两个核心循环：改进与投资：

今天我们深入 Anthropic 的运作方式。如今 Opus 5.5 的尘埃已经落定，它作为全球公认的第一大 LLM 已持续一个月，我们深入探讨它的发布，以及 Anthropic 如何用 Claude 打造 Claude——嘉宾是工程负责人 Katelyn Lesse 和产品负责人 Angela Jiang。播放视频

在 YouTube 上打开视频 ↗

团队正承受着两种压力。模型能力越来越强，这让安全部署和访问决策变得更加困难。与此同时，使用量增长得足够快，以至于普通的基础设施选择——比如一个 API 消耗多少 CPU——都变得具有战略意义。这些问题最终汇聚在触达开发者的产品选择上。

模型发布也是一次 API 发布

Anthropic 的 Opus 5.5 发布同时强调模型质量和成本。我们讨论了关于前几代 Opus 过于冗长的反馈，以及提升每美元智能水平的需要。Anthropic 表示新模型的运行成本低于前代；具体节省取决于工作负载及其对缓存上下文的使用。

发布工作中不那么显眼的部分涉及人们集成 API 方式的改变。我们讨论的一个例子是保护模型推理不被用于蒸馏的提取。跨轮保留 thinking blocks 有助于解决这一问题，但一项新要求也可能破坏客户现有的 harness。

Katelyn 还描述了参与早期访问计划在实践中究竟是什么样子：客户在自己的 harness 中运行评估，报告令人意外的行为，有时还会传达不太正式的感受。有用的部分不只是基准分数：而是在 Anthropic 自家产品未覆盖的环境和任务中看到模型的表现。正如我们连续 4 年在播客上所说的，拥有好的评估是无价之宝。

大脑与双手

本期节目中我们最喜欢的思维模型是智能体的“大脑”与“双手”之分。在 Managed Agents 中，Anthropic 将会话日志和 harness 与执行代码的沙箱分离。harness 可以持续存在，而执行环境在需要时才创建；一个沙箱失败不必连带整个智能体会话一起失败。

我们在 Thariq 那期播客中讨论过这一点：

发布 Opus/Sonnet 5.5、Mods、Plugins、Projects、Tag，同时把握前沿节奏

Latent Space

同样的分离也为安全提供了有用的架构特性。如果生成的代码运行在一个永远不会收到服务凭据的沙箱中，那么该沙箱中就没有可供代码读取的凭据。本期节目描述了凭据单独持有并通过代理挂载，同时对沙箱流量可以流向何处进行控制。Anthropic 的隔离性文章描述了其产品中使用的更广泛的隔离与网络控制措施。

这种区分对性能也很重要。嘉宾们说，早期的一种做法是把整个编码智能体放在 API 后面的沙箱中。启动环境和智能体会在首次响应之前增加工作量；如果沙箱消失，运行中的智能体也随之消失。将各部分分离使平台能够在保持执行隔离的同时追求更低的延迟和更好的可靠性。

对于任何设计智能体运行时的人来说，这都是一个有用的视角。问问哪些部分需要存活，哪些部分执行不受信任的工作，以及哪些密钥真正需要出现在代码运行的地方。不同产品的实现会有所不同，但这些问题仍然有用。

一个帮助另一个智能体记忆的智能体

Managed Agents 还为记忆和多智能体工作流的实验提供了基础。Dreaming 的实现很简单，就是一个智能体检查另一个智能体的先前工作并写回记忆。这使得该功能成为用同一套底层托管智能体原语构建更高层行为的例子。

他们对路线图的描述比一份功能清单更为细致。记忆和学习仍然重要，但团队表示，随着模型发布变得越来越困难，他们更多的近期注意力已转向安全。他们还讨论了保持基础 harness 相对简单，同时让开发者在其上试验验证器、并行智能体和其他策略。提到的未来平台能力构想应被视为计划，而非已交付的承诺。

关于评估的对话自然随之展开。harness 是一个应用，但改进它开始变得像研究：选定目标、测量行为、检查失败，然后迭代。嘉宾和主持人讨论了如何用模型来帮助构建和分析评估，同时保留足够的判断力，以决定该评估是否反映了真实用户的工作。

节目笔记

Claude Opus 5.5 发布公告——Anthropic 关于模型行为、评估和定价的发布说明。

Katelyn Lesse 和 Angela Jiang 在 Anthropic 合作伙伴峰会上——Anthropic 标明了她们的平台工程和产品职位。

扩展托管智能体：将大脑与双手解耦——本期节目讨论的会话、harness 和沙箱架构。

Anthropic 如何在各产品中约束 Claude——Anthropic 对其产品中隔离、凭据和网络控制的描述。

面向长时间运行智能体的有效 harness——Anthropic 早期关于在多个上下文窗口之间保持进展这一挑战的工作。

Anthropic 模型系统卡——该公司公开的模型评估和安全文档。

Anthropic S-1 解析——新录制的开场介绍背后的数字与背景。

时间戳

0:00 Anthropic 的 S-1 与本次访谈

1:06 人均营收与效率

3:13 改进循环与投资循环

4:04 为什么 Claude Platform 很重要

6:25 训练事故与生产防护措施

7:30 Opus 5.5 发布与定价

9:25 蒸馏与保留思考

14:35 Anthropic 的产品与工程

18:05 扩展 Claude Platform

19:25 模型访问与安全决策

26:25 信任授权与产品路线图

30:25 Anthropic 如何发布模型

35:55 基准测试与模型个性化

42:10 Claude Managed Agents

44:25 记忆、dreaming 与智能体 harness

48:25 评估智能体

53:25 CPU 约束与扩展

56:05 用 Rust 重建 Messages API

1:03:25 大脑与双手

1:05:25 保护凭据与沙箱

1:08:25 训练事故与生产环境

1:10:55 前沿模型的节奏与发布

1:12:25 安全分类器与模型路由

1:19:25 新兴的智能体工作负载

1:20:55 对抗 AI 垃圾内容

1:27:25 管理、写作与工作风格

1:33:25 组建 Anthropic 的 DevRel 团队

1:40:25 开发者关系与产品声音

1:43:25 用 Opus 5.5 可以尝试什么

文字记录

自动转录草稿。姓名和措辞可能需要更正；说话者身份尚未分配。

0:00 大家好，今天我们尝试一些新东西。我们正在启动对 Anthropic 的 IPO 报道。他们今天刚刚提交了 S1。因此，我们将发布一系列播客，为 IPO 预热，预计 IPO 将在两周后进行，估值 2 万亿美元。它是有史以来增长最快的公司之一，据报道其生命周期现金融资额超过 1000 亿美元，而生命周期消耗不到 100 亿美元。所以这里有很多效率故事值得深入探讨，我认为这是我们想要覆盖的内容：Anthropic 如何同时交付世界上最强的模型，又以非常非常高效的方式做到这一点，并建立起令人难以置信的业务。所以我提取了一些，你们知道，如果你们一直在听这个播客，就知道我曾经是一名金融分析师。

0:50 我从 S1 中提取了一些陈述，我认为它们能为今天的播客提供有趣的背景。我们只是把这当作一个新尝试，因为我觉得你们中有些人想要那种与我们直接面对镜头交流的个人关系，而不是与我们邀请的嘉宾交流——后者我们已经做了四年。所以我想强调的第一件事是，按人数计算，Anthropic 是一家效率极高的公司，这也许显而易见，因为它是 AI 公司，所以显然他们非常善于使用 AI。但我认为他们在过去一年里作为一家公司所改变的程度并未被充分理解。所以现在每员工 12 个月营收是

1:32 660 万美元。而一年前是 140 万美元。所以他们的每员工营收几乎增长了五倍。我认为这是我们更需要深入探讨的事情，因为我认为任何企业主、任何工程师，都希望提高每员工营收，不仅是为了提高盈利能力，也是为了增加你能支付给员工的薪酬。这显然伴随着每美元算力所带来营收的显著增长。值得注意的是，基本上在 2025 年第二季度，Anthropic 基本上每收入一美元就亏损半美元。而现在每花一美元成本就能赚两美元。我认为这是一个有趣的类比，说明过去一年 Anthropic 的营收和业务前景发生了多么巨大的转折。

2:27 今年对Anthropic来说，执行到位极其关键，而它做到了。我认为我们基本上会进一步深入这一点，并尽可能从播客的外部视角讲述这个故事。嗯，这整个增长带来的一个结果是，Anthropic刚刚公布了它的首个盈利季度——不是调整后利润，也就是扣除所有让我们花钱的项目之后的利润，不，这是公认会计准则下的利润，嗯，是19，这又是巨大的，再次与一年前完全翻转，不只是翻转，就像一年

3:03 前，它每收入一美元就亏损129%。所以我认为，解释这种非凡效率的主要归因是：如你所知，Claude喜欢循环，Boris喜欢循环，Dario喜欢循环，而Anthropic内部有两个循环在运转。第一个是改进循环。基本上，这个循环是：你拥有Claude，Claude带来更好的模型，更好的模型带来更多用例。更多用例产生更多反馈，而这又带来更好的Claude。然后还有投资循环。所以扩大采用带来的收入带来更高的增长。更高的增长带来更多投资，更多投资带来更多能力。

3:45 这带来更好的Claude。所以这两个循环基本上一起旋转，形成一个无限循环，根据Adoptic S1的说法，这个循环将推动效率提升直到时间尽头。所以我认为，这就是我们从整体效率故事过渡到他们如何执行的方式。而今天我们将大量聚焦于Claude Platform，因为这是他们在Anthropic S1中称为Claude扩散的三件事之一。所以他们把Claude Platform称为我们全面的智能体开发环境。他们为客户提供对其原语的直接访问，以便构建、部署、扩展他们自己的应用，这些应用在他们自己的产品和工作流中利用Claude的能力。

4:30 我认为在这个播客的讨论中经常出现的一个概念是“吃自己的狗粮”（ad fooding），即Claude的许多产品实际上是用同样对你开放的Claude Platform构建的。所以Claude Platform中披露的另一件有趣的事是，按过去十二个月计算，他们超过50%的收入在10万美元或以上的客户使用Claude Platform。所以这体现了采用的增加，以及Anthropic不仅作为模型实验室，还作为超大规模提供商和Claude Platform的崛起，我认为这也许就蕴含在Claude Platform这个名字本身之中，但它正在从理论走向实际实践。

5:15 而这也是我们在播客中关注的内容。我真正想强调的另一件事，我之前也谈过，就是Claude Code、Claude co-work。它们都使用Claude Platform所暴露的相同原语。所以我认为这真的很有趣。最终，看起来Anthropic确实在为其IPO定位，谈论从聊天机器人到副驾驶再到虚拟协作者。他们用这个词而不是“智能体”。也许这样更友好。但它包含了很多你期望从智能体身上看到的东西，从长时间运行的自主工作到判断力、自我纠正、迭代和工具访问。所以是拥有一个目标，与你并肩工作，而不是在一个应用或任务内部工作。所以这最终就是我想为今天播客提供的背景。

6:00 这是在Opus 5.5发布时录制的，我想说，在我们交谈过的所有高品味测试者中，压倒性地认为Opus 5.5是目前世界上最好的模型。而Anthropic甚至只是把Fable 5.5留着，可能在未来两周内发布。我不需要有内部消息，但这对IPO来说非常合理。所以让我们期待那一点，并多了解一点他们是如何构建Opus 5.5的。

6:25 是的，所以我想做的一个区分是，在人们听说和读到的许多事件中，这些事件发生在模型身上，而不只是所有人的模型，对吧，这些模型处于训练中，你运行这些模型的方式是，你把它们放进一个盒子里，然后说，解决不可能的任务。我要给你压力。准备，开始。

6:45 对。而且你只能在你所处的环境里做你能做的事。而智能体基本上被激励着去试图逃出它的盒子，去解决问题。当人们在我们或任何其他人的 API 上运行生产工作负载时，你运行的环境里会有一些正在运行的安全防护措施，而这些措施在训练时不一定在运行——训练的全部意义就在于真正训练模型。对吧。但在生产工作负载中，首先，你有那些在线安全防护措施，这真的很棒。其次，你周围有更多这样的架构和基础设施来支撑正在发生的事情。就像智能体并不是被关在盒子里试图逃出来。对吧。就像 harness 在这边，手在那边。这甚至都不是一个你需要去考虑的问题。

7:30 好了，我们在 Opus 5.5 发布后的第二天，和 Katelyn 与 Angela 一起在演播室里。欢迎。谢谢邀请我们。恭喜你们发布了目前世界上最好的模型。我会说这取决于你问谁。对。取决于你问谁。对你们个人来说，主要的收获是什么？你们有官方的博客文章。降价真的很酷。当你们发布这样一个新模型时，你们收获了什么？我们为这个模型感到非常自豪。团队付出了大量不同的努力才让这个模型成为现实。而且我认为我们确实听到了关于 Opus 5 的写作有点晦涩难懂的反馈。我们真的努力把它清理干净了。我很高兴看到这似乎引起了人们的共鸣。在内部，当我们试用这个模型时，我们也有同样的感觉。所以能得到这样的验证真的很好。说到你提到的降价，那里有很多内容。

8:17 而且我认为，越来越多的人开始追求每一美元能换来的优质智能。因此，确保我们把“每一美元”这部分做对，一直非常重要。还有一些边缘上的东西，其实并不完全关于——你知道，也许是我们在博客文章里没有谈到的东西，那就是我们确实做了大量工作，努力让我们的 API 更难被蒸馏。因此，我们做了一些改动，让这一点变得更具体一些。具体来说。而这些事情关乎，你知道，比如我们如何实现前缀锁定思考，或者你如何在不同类型的模型之间重放思考 token。我们这边投入了大量工作与努力，确保我们尝试针对非常合理的用例去调整这些东西——比如你可能想在压缩策略之类的地方这么做——而不是在那种用例实际上来自不良行为者的场景中，

9:05 实际上。所以围绕这些方面，一直在做很多精细的权衡。我很高兴看到其中很多内容也一并发布了，除了发布一个在每一美元智能上表现优秀的模型之外，也把沟通做得更清晰了一些。是的。具体来说，你指的是这篇论文，《从专有 Yellow Lips 中窃取推理轨迹》。对，就是那篇论文。就我们所知，它是真实的，对吧？我的意思是，显然他们向你们做了负责任的披露。他们做了超级负责任的披露，我们非常感谢他们来找我们。能不能——给那些还没听说过的人讲讲，这真的很酷。你们本来可以做到的。我的意思是，它已经被修补了，但当时是怎么回事？比如，它在 Anthropic 内部引起恐慌了吗？大概没那么严重。我不知道。我不知道这篇论文具体引起了多大恐慌，因为这是我们

9:48 早就知道的一个缺口。是的，所以这是两件不同的事。一个是中文模型蒸馏。是的。然后这个是发表出来的一项技术，而且备受关注。没错。我们早就知道，思维链提取是蒸馏模型最强大的方式之一。实际上，类似“我们如何跨轮次保留 thinking blocks，并让这成为更被要求的事情”这样的问题，我们已经探索了一段时间。而我们当时所处的状态是，我们总是必须在用户体验——比如那些对 API 用户来说可能很痛苦的用户体验变更——与防蒸馏保护之间做出非常非常艰难的权衡。

10:32 那么，我们该如何把握这条界线，并表明我们正在防止蒸馏呢？也许先退一步说。我们之所以不希望蒸馏，是因为 Anthropic 存在的全部意义就在于，我们希望 AI 能够安全地在世界上创造积极成果。我们会对所生成的 token 运行大量安全防护分类器，以确保它们是安全的。如果有人蒸馏了我们的模型，并在没有安全防护分类器的情况下运行这些模型，就可能在世界上造成不良后果。这是我们不希望发生的事情。因此，我们不希望人们专门为了将模型用于恶意目的或不良目的而蒸馏模型。所以这始终是一个有趣的权衡：对于那些将模型用于正当用途的人，对吧？

12:04 而现在，这更多开始涉及跨账户的情况，你知道，比如如果你使用多个账户之类的情况，对吧？比如，我们如何确保你无法利用这种针对模型的思维链提取？因此，我们发布了几项额外功能来帮助解决这个问题。我们实际上与许多开源 harness 维护者进行了合作。我们联系了他们，与他们交谈。我们当时说，你们将需要在你们的 harness 中进行这些升级。我们希望确保你们有良好的体验，当然也包括我们那些在 API 之上构建 harness 的大客户。对他们中的一些人来说，一个很好的例子是，他们原本的压缩策略会因为需要保留这些 thinking blocks 而失效。因此，我们在 API 中发布了一项新的压缩功能，以替代他们原本手动进行的操作。

12:49 一直在手动进行，但在保留思考内容的情况下仍然有效。所以这只是一个例子，说明我们正在走这条线，但我们并不是随便就 YOLO 式地宣布，现在你们必须以这种确切的方式保留这些思考块，因为那样会破坏很多人的使用，但我们能够花时间与客户和开源 harness 维护者合作，给他们提供完成升级所需的东西。既然我们谈到了适配，那么蒸馏的另一面呢？你知道，就是另一半。是的，不，我们确实看到，通过我们能够采取的衡量方式来看，蒸馏变得更难了，难度显著增加，因为这是——这里要归功于我们的研究人员，他们非常负责任地披露了这一点。所以把它关闭是件好事。

13:30 而且他们非常公开地发表了结果。我知道这在 Twitter 上确实引起了不小的反响。所以很多人可以使用它。但是的，我们确实看到，从我们能够衡量的领域来看，它似乎确实减少了我们不想要的那种效果，即负面影响。是的，我想补充 Katelyn 刚才所说的一点是，至少我在 Twitter 或 X 或随便你怎么称呼它上面看到很多说法，说这是商业化问题之类的。如果你能蒸馏一个模型，你就能拿到它，然后就能低成本地运行，等等等等。虽然这是真的，但这其实并不是我们非常关心的事情。我们更多是从安全角度而不是其他任何角度来关心这件事。所以这就是为什么我们倾向于从那个角度而不是仅仅从商业角度来考虑它。现实地说，如果你从我们这里蒸馏，你实际上是在付钱给我们。所以从商业上讲，我们赚了钱。所以这并不是

14:16 真的会有那种影响吗。这更多是关于确保我们的模型，我们要确保云是好的，而且云是可以被推导出来的。如果结果是负面的，那就不太妙了。总的来说，还有关于 5.5 的问题，因为你们刚刚完成这件事，有一件很有意思的事是确立你们两人之间的互动关系，因为你们也经常一起露面，你是产品负责人，你是工程负责人。你们两人之间是如何配合的？尤其是对于模型发布来说。我们就举个例子。所以对于模型发布，我们的团队在产品与工程之间合作得非常紧密。在我这边，更多是关于我们需要在发布一个达到正确智能门槛的模型与成本保持之间做出怎样的权衡。

15:00 我们很多更新后的现金成本之类的东西，都表明我们希望鼓励大家采取对所有人实际上都有益的集成变更，并把这些节省传递下去。但很多这类决策，以及我们如何平衡安全举措方面的部分，同时确保它是一个人们可以充分利用的出色模型。所以这些特质，我会说也许是围绕我们如何发布模型的品质和相关组成部分，更多属于产品方面。然后从集成体验的角度来看，很多都直接来自工程团队。所以显然我们会合作，如果你说的是 API 的体验，那是非常、非常、非常紧密集成的。所以这实际上非常棒。我们有很多工程师实际上非常有产品思维，我们真的很喜欢这一点。

15:49 同样在我这边，有很多产品经理在技术方面要强得多。我们希望有这种混合的、跨学科类型的人才，因为这样他们就能从各个不同角度来分析问题，设法找出最佳做法。但我倾向于更偏重商业影响，而我觉得工程师们实际上会更关心集成体验。所以他们几乎更多是从用户体验的角度来看待这件事，而这里的用户体验显然更多关乎 API 和开发者工具。是啊，做一个负责开发者产品和平台的产品工程师很有意思。所以我也赞同这一点。我觉得我们有很多工程师很喜欢思考产品，喜欢思考用户体验，喜欢思考开发者体验。

16:31 我觉得我们之间也有这样一种互动关系：我有很多意见，在产品团队面前很烦人地表达我们对这些事情的看法。而我们的产品团队也非常懂技术，他们能深入到我们为规模化或其他目的所做决策的细节中，这是我们团队之间一种有趣的互动。是啊，有些……Kayla 和我已经合作很长时间了。在 Stripe。在 Stripe，然后我想我们在 OpenAI 没有一起工作过。不同的实验室。不同的实验室。然后我过来了。但我觉得我们两人有一个有趣的特点，就是 Katelyn 经常被误认为是产品经理。而我经常被误认为是工程方面的人，尽管这些实际上都不是我们的工作职能。所以我觉得这种搭配往往很有帮助，能让我们做出在两边都一致的决策。

17:18 所以我觉得我遇到过很多公司，都是类似的产品负责人、工程负责人的配置。随着软件工程逐渐被解决，也许这两个角色会合并？我有点这么认为。是啊。我觉得大家往往倾向于……但如果你们仍然是分开的，那说明我们还没到那一步。我们肯定还没到那一步。那为什么呢？还剩下什么？我觉得软件工程被解决这件事……我不知道我会不会用那么强烈的措辞。我觉得有……我倾向于这样看待这些事情，比如雄心会持续提升，对吧？也许一个很好的例子是，我们团队现在花很多时间在做的事情，当然，显然是我们为了安全发布模型所必须做的所有事情，实际上是我们正在做的最重要的事情，因为我们在安全方面有大量工作要做，涉及智能体、离线防护和在线防护，所有这些正在发生的事情。

18:06 但我们做的另一半是试图扩展规模。部分原因是，当我一年多前加入 Anthropic 时，我们有 Messages API。它是一个 Python 单体应用。我们在单个 GCP 区域运行它。一切都很正常。而当我准备接受这份工作时，我的朋友和家人都不知道 Claude 是什么，对吧？而现在我们的处境已经截然不同。所以从我们在 API 上看到并不得不支持的流量规模来看，这些指标真的非常惊人。CPU 资源确实很受限，这对我们来说一直是个很有意思的问题。所以我们做了大量工作，研究如何扩展这些系统。而这显然需要大量分布式系统方面的专业知识

18:45 以及模型所具备的某些语言和框架方面的专业能力，但当涉及到在如此规模上运营和演进一个系统时，我们远未达到那种“祝你好运，Claude，玩得开心”然后就直接去做、对系统做出所有需要的改动、安全地推出并大规模运营这套东西的程度。仍然有大量工作必须由人类来完成，我想这种情况还会持续一段时间。我很好奇这方面发生了怎样的变化。比如不久前，当 Fable 刚推出时，我们有 Glasswing，当时出现了整体延迟以及模型发布方式的改变。我们看到大多数前沿模型都是如此。会有安全测试。现在情况如何？你们怎么看？你们如何判断——一方面，会有新的 Sonnet，Haiku 也会推出。

19:31 我猜那些会直接发布。但对于像 Opus 5.5 或新的 Fable 这样的模型，目前是什么状态？是的，我想说这首先要从我们在防护措施和安全方面的政策决定应该是什么开始。这既包括离线安全，也包括在线安全。所以最近围绕数据保留以及我们在这方面为安全发布这些模型所做的工作有很多讨论。原因在于，你会遇到这样的情况：有许许多多账户，分布在一个庞大的用户网络中，这些人选择注册账户并以各种方式使用模型。而在线的、随着 token 流经系统的方式，我们根本无法捕捉到模型是否存在恶意行为、蒸馏或其他可能正在发生的事情。

20:19 因此，我们开始不得不制定数据保留政策，以便我们能够进行自动审查和人工审查，无论需要采取何种方式，来确保模型的表现符合预期。而且对于我们发布的每一个模型，这都是一个需要做出的政策决策示例，比如针对这个特定模型的政策将会是什么。例如，昨天发布的 Opus 5.5 就没有 Fable 所具备的那些数据保留要求，对吧？但这是我们每次发布这些模型时都必须做出的决定。如果它确实要具备那些政策，我们就必须做好工作，确保这些政策得到执行。同样，对于我们开展的项目也是如此，比如我们有网络验证项目，以及最近新设立的生命科学验证项目，也就是说，你所使用的模型在在线防护措施的工作方式上会有所不同。

21:09 确保所有这些项目落实到位是另一项工作。所以这只是我们在每次模型发布中所做工作类型的一个缩影——我现在所说的这一切，都是我们在发布这些模型时过去不必考虑的事情。而现在，大部分工作都是：我们在做什么来防止蒸馏？在线防护措施、离线防护措施、政策。一个非常好的例子是，我们构建了一个系统，确保使用某个模型的授权，或者使用某个可能为你提供较宽松防护措施的项目的授权，能够以我们真正可信的方式贯穿我们的整个系统。

21:47 并不是说，哦，你获得了 Mythos 的访问权限，然后我们就给你一个 API 密钥、打开一个功能开关，就完事了。我们有一套非常稳健的系统来处理身份验证，并确保如果你应该使用那个模型，那么就只有你以预期的方式使用那个模型。所以，在模型发布前后，开始出现许多复杂的事情，而这些事情，我们以前从来不用考虑。是的，而且它会随着能力提升而扩展。比如，随着我们的能力越来越先进，并且开始在某些特定领域出现尖峰，那就是我们需要格外关注的地方。因此，很多评估都来自那些非常特定的能力，我们可能将其视为进攻占优或防守占优，因此可能会对所有这些采取不同的策略。而当我们把这一切一直贯穿到最终的模型发布时，就会有一些组成部分，就像 Katelyn 提到的那样，我们并不完全确定人们可能会如何使用这些能力。

22:37 还有一些更明显的方向，比如做编程，对吧？很好，去打造出色的产品，去发布更多东西。这对你来说可能非常棒。然后其他领域，比如生物和网络，它们可能具有双重用途，也可能带来负面影响。但显然，当然，你完全可以成为一名非常合格的网络安全研究员。你在努力寻找漏洞。你在努力做一个好人。同样，在生物领域，你可能在做研究之类的事情。所以很多这些项目，比如你上面展示的这个，基本上就是为了提供对这种双重用途的访问权限。你确实必须说明你的用例之类的东西。但我们确实希望让社区能够利用这些能力，看看他们能用它做出什么了不起的事情。好，我们会把链接放上去。也许我们稍后会深入探讨它们。

23:15 生物领域也有一个。另外，我只是觉得，从高层面上看，你们真正去思考这些事情非常重要。人们忘了 Fable 曾被回滚，还有各种蒸馏攻击，人们就说，啊，Fable 上零数据保留根本不存在，太疯狂了。但你必须记住，它被撤回了。存在蒸馏攻击。你们在发布的同时过度思考并以正确的方式去做，这是好事。是的。而其中很多就是建立正确的框架。再次谈谈边缘方面，在我们的系统中建立正确的框架以便能够做到这一点。所以我稍微谈过这个，就是我们如今在整个系统中构建的授权和信任授予这一理念。永远别说永远。对吧。不作为先例。是的。但这也是平台工程中非常常见的事情：你遇到一次事故，然后你就为这次事故过度准备，而这次事故再也不会发生。

24:06 是的。就像，你知道的，现在你有了那个按钮。嗯，这是真的。你这么说很有意思，因为当时在发生的这一切之中，我们团队的工作里就出现了这样一个事项：我们要把这个系统落实到位，让它能够成为一个按钮，为所有人一键回滚。所以这挺有意思的，因为就像，我们做这项工作，是不是因为我们希望类似的事情再也不要发生？但我觉得在这个情况下，这其实只是把那些我们想在所有地方都落实的相同基础能力层层叠加起来，帮助我们管理这些验证项目，以及对 Mythos 等模型的访问权限，说白了就是，把同样的东西放在下面，放在所有人的模型访问之下，这样万一我们哪天需要，我们就有正确的控制措施到位。

24:48 是的。而像这样的决策实际上已经被证明是，呃，这一个我们还得再看看。但像这样的例子一直是我们不得不真正改变我们制定路线图方式的典型情况。因为，你知道，在传统的产品管理中，我想，你可以说，好吧，这些是我假设会发生的一系列事情。它们会有某种顺序、某种排序。但你下注的方式要具体得多，相比之下，比如说，你知道的，Fable 的撤下部署。我不认为我们中任何人会猜到那会成为一个实际发生的有效用例。由政府那边，那位女士就不得不去执行。但显然概率是非零的。所以从这种思维方式出发，从产品管理的角度来看，它实际上已经变得深度概率化了，比如，我们应该优先考虑这个吗？它发生的几率有多大

再次发生吗？当我们审视这类事情时，我们会想，好吧，如果我们要去想象最疯狂的一整套可能性，我们其实很可能对事情会走向何方几乎没有确定性。所以实际上我们就是需要做对冲，并构建一个押注组合。因此，大多数情况下，我们会采取对冲情景，比如，好吧，我们认为它不会再次发生。但如果它真的发生了，我们实际上会想要那个对冲，或者具备能够非常好地做到那件事的能力。所以我们会优先考虑这类事情。然后我们越来越发现，大多数情况下，通过采取这种产品开发策略，我们很多时候实际上会发现自己真的在用那个东西。有没有另一个例子，是独立的，好让我能理解？比如，这个访问计划。

26:15 这个 X-Factor 就是一个非常好的例子。在内部，它有一堆授权之类的东西。我们开发它，具体原因就是为了能够……实际上把这样的计划提供给客户，非常非常具体地。你想不想高层次地说一下这个访问计划具体是什么？当然。所以如果你想要双重用途，如果你想，那么，我们拿一个模型来说。所以你拿一个模型，就叫它 Opus 吧，然后你希望能够为了研究或者为了你想去做的任何事情，在 Opus 上使用高级网络能力，比如你是防御性用户。你可以申请这个计划，带着你的用例，如果获批，我们实际上会降低你这个版本模型上的防护措施，这样你就可以接着为你的用例去利用那些网络活动。现在，显然，

27:02 这需要对每个用例进行理解。它需要把范围缩小到特定用户，因为你不会普遍地这么做。你必须申请。而即便是像这样的事情，比如这类项目，我们设计了很多 Katelyn 提到的原语，就是为了能够处理这类事情。现在，令我们惊讶的是，或者说在组合式方法中，我们发现我们实际上能够拿这个来做并把它变成 X。我们当时在设计它的时候就想，它应该是什么样子？它应该有多通用？它是不是不应该太通用？它是不是应该过度专注于实现这种验证式的门户，再加上授予模型非常特定的能力？而我们倾向于选择更通用的做法，因为我们当时想，我们不知道。也许我们可以把它用于其他事情，也许不行。然后它最终对诸如模型访问之类的事情变得极其有用

27:47 这一点在管理我们所有的可信访问计划、处理模型下线部署时体现得尤为明显，因为我们当时在处理每一个原语时都非常非常通用。从正常的产品角度来看，我通常大概会说，这大概不太合理。我们应该聚焦于用例。这说得通。但在这里，越来越多地，因为我们选择了更通用的方法，我们发现自己往往更倾向于采用那个解决方案。正因如此，它带来的回报越来越大。这是你本来就需要具备的东西，而你只是有了一个必须实现它的契机。从技术角度来说，我来自 AWS 世界，对吧？IAM、OVC，然后那些对此非常较真的人会谈论 Zanzibar 以及所有其他技术架构。我不熟悉 token grants 或 trust grants 这个词。

28:32 Trust grants，对。Trust grants。普通 OVC 和 trust grants 之间有区别吗？我是说，其实没有。它是一种授权形式。对，它是 IAM，但是 Anthropic 的 IAM。对，差不多。我觉得实际上我们有，比如有一种授权形式是，好，你向一个 API 发出了请求，而这个 API 在底层会访问一些数据，我们要确保你访问的是你自己的数据。对，就是非常非常基础的授权。这里只是我们建立了一个数据模型，它非常清晰，比如 trust grant 意味着你被授予了对某个特定模型的访问权限，或者你被授予了对某个特定计划的访问权限，或者，你知道，这方面有一堆不同的排列组合。我们实际上发现自己一直在用这个。另一个很好的例子是当我们

29:17 我们最初为 Fable 5.1 推出了一些这种保留式思考，我们对一些用户做了祖父条款处理，给了他们一段，你知道，就像一段宽限期。是的，宽限期，让他们去完成集成变更。作为祖父条款处理的一部分，我们说，好，我们得追踪谁是现有客户、谁需要额外时间，对吧？然后我们做了一次信任授权。于是我们就能说，对于任何事情，我们只是运行这个服务，它位于我们请求的热路径上，以确保，你知道，我们只是让请求流过并检查你是否有针对你试图做的事情的授权，这其实和普通的授权没什么不同，真的。但就像，我们只是必须搭建一个系统

30:02 一个专门针对我们系统的系统，以及我们需要能够插入这些检查的地方。是的，我是说，我觉得这些都是人们习以为常、不太会去想的工程上的事情。我想另一个例子是，平台方面必须做的事情，你知道，也许是服务 Claude Code，也许是服务，你知道，显然我和 Cognition 聊了很多，但其他客户在模型发布方面也是如此，对吧？比如我们会更多地谈论正在进行的安全工作。我只是想在高层次上谈一谈，因为这刚从你的记忆中出来，就像模型发布需要什么？如今这已经变成了一台有点庞大的机器，除去安全方面的工作，我认为那是更复杂的部分。但除了那些部分之外，还有很多从客户那里获取反馈的工作。所以，你知道，我们做模型，

30:50 有大量的安全测试。我们还会评估我们认为它需要达到的水平。我们会按需做出必要的权衡和决定。然后我们必须经过测试。我们会切出模型的各个版本。我们会评估它。我们会做很多我们称之为内部“吃狗粮”的测试。而这实际上总是非常有帮助。比如，我们能很早就发现一些问题，比如，哦，这个可能不是最好的。而且我们显然在内部工作中大量使用 Claude。所以我们实际上能够看到围绕一些事情的早期信号。这有助于我们判断哪些变体可能比其他变体更好。然后，当我们对某一组变体非常有信心时，我们会为客户切出一个版本。有时这会通过我们的第一方产品发布，比如通过 Claude Code 或 CodeWork 之类的东西。

31:30 在其他情况下，它会通过我们的 API 客户发布。我们会有效地与这些客户开展一种早期访问计划。他们需要对自己的 harness 做出更改。我们已经与很多客户合作，比如 Cognition、Cursor 这些人。我们有一套处理这件事的流程，以便我们大家都能得到所需的反馈。它在你们的评估中表现好吗？你们喜欢它吗？不喜欢吗？有些事情是凭感觉的，我们也喜欢听这些。还有些事情就是纯粹的评估，比如它在你们关心的事情上表现好吗？我们把所有这些综合起来。一旦我们对所有这些不同的部分都感觉良好，我们就发布模型。模型反馈的状态感觉仍然非常无结构。基本上，它始终是公司之间的一个 Slack 频道，比如，嘿，这个东西看起来很奇怪。然后人们就说，好吧，我想我会修好它。

32:16 给我一个 ID 之类的。对，这非常，我是说，这就是一个非确定性产品的本质，对吧？但我觉得，就像你说的，真正参与我们早期访问计划的客户，都是那些邮件系统非常健全的客户。比如，我确实认为这里面很多都是凭感觉的，而且我觉得很多对话往往都是那种凭感觉、即兴进行的。部分原因是我们正在，比如，赶进度，对吧？就像，我们想尽可能缩短从我们切出一个用于测试的模型版本到我们让所有人访问那个模型之间的窗口。所以这确实就是，比如，一个非常紧凑的窗口。但我们倾向于合作的客户，是那些我们知道他们会去，比如，启动他们整套评估套件，并且能够带着真正可执行的反馈回来找我们的客户。

33:01 尽可能快地推进，同时结合感觉，也就是基于感觉的反馈。所以，当然，我们肯定可以做一些流程化的事情，随着时间推移让这些变得更好。但我的意思是，你会感到惊讶。我的意思是，你可能不会感到惊讶，但我觉得有些人会感到惊讶：世界上存在的智能体产品中，竟然有那么少的产品没有好的评估来帮助测试这些模型。两年前我们请 Boris 上播客时，他说我们没有那个时钟代码。我的意思是，那已经变了。那已经变了。那已经变了。但是，你知道，就像，是的，很多事情就像，你知道，你的评估就是你的用户，而你没有时间把它们正式化，或者你没有经验，或者随便什么。那没关系。到了某个时候，当你认真起来，你就会有评估。是的，完全同意。我觉得好的一点是，你们做了很多 amp fooding，就像你说的。所以人们常说，很多这类测试都是你自己在它发布之前先做的，对吧？

33:49 是的。是的。尤其是客户的 API 非常有用，因为他们会把 Claude 放进不同的 harness 里。我们希望 Claude 非常非常通用。所以它能在其他 harness 中工作，对我们来说相当重要。因此，这种形式的反馈往往对我们特别有用，因为它不同于我们从 AntFooting 那里得到的东西。什么样的反馈有帮助？是回归问题吗？我们这里有回归问题。我们注意到这里有好的属性。好的东西总是很有验证价值。我觉得我们经常并不感到意外，但我们喜欢在一些我们可能提出假设的事情上得到验证。老实说，最有用的反馈是负面的。比如，你知道，它在这方面做得不好。它在那方面做得不好。我们很喜欢这种反馈。然后我们就会说，太好了，我们怎么修复它？

34:31 是的，而且往往就是这类事情，真的很难，因为并不是每个人都希望 Claude 在每个光谱上都落在完全相同的位置。也许一个很好的例子就是，你知道，懒惰与主动性、采取行动之间的对比。所以有时候，我们有一个模型，人们会说，就完成我的任务。别偷懒了。做得好一点。而另一些时候，人们会说，嘿，我们只是在摸索和规划。然后你就去写了一堆代码，或者你采取了一大堆我还没准备好的行动。要把它做到完全正确，实际上是不可能的，因为现实中每个人都想要不同的东西。但我确实认为我们遇到过这样的情况：我们切出了一个早期版本的模型。我们发现我们看到了太多的懒惰。对。

35:15 然后我们把它放回烤箱里烤一会儿。对吧。并试着把那种特性训练掉。所以这类事情，如果我们只是在自家产品和自家 API 内部做 antfooding，可能就发现不了。对我们来说，把它放到 API 里、让所有其他客户都用起来、并告诉我们哪里需要改，要重要得多。是的，这是个核心问题。我觉得这大概就是——如果我处在你的位置——为模型做产品经理最难的事情之一，我们姑且称之为对齐与个性化之间的取舍。你希望所有消费者都有一个默认人格、默认行为。然后你又希望能非常迅速地响应某人的 CLAUDE.md，说，不不不，请比默认更主动一些。

36:01 然后，据我所知，你知道，我参与了 Frontier Code。我们参与了 Fable 的发布，正是那次发布让 Frontier Code 崭露头角。而现在有了 Opus 5.5，我们又把它放回了模型基准上。这是 Frontier Code 非常重要的一部分，对吧？Frontier Code 的模型曲线看起来奇怪，是因为它会过度惩罚活动过多或文件过多，这其实是好事。就像，Frontier Code 有一整套……设计目的。但我完全可以就在我的 CLAUDE.md 里说，别那么做。然后它就不会那么做了。那么，我是不是因为我的基准缺少那个主观的个性化元素，就在不公平地惩罚 Cloud Opus 55？所以我不知道问题到底是什么，但你是如何处理个性化的？显然，一个模型可以做很多

36:51 不同的东西，而且它如此依赖于每个人都有自己的 CloudMD，你如何演进它？我们在这方面做得并不好。说真的，这真的很难。这超级难，而且它们相互竞争又相互对照。我以为有云宪法，我想。那是旧的。确实有一部宪法，但我会让你们来回答。宪法是有帮助的，但对于像这样的事——它如何根据不同的指令进行个性化，以及在这些东西之间非常非常不同的偏好——对我们来说非常难做到。我们通常试图通过拥有更多参数来解决这个问题，这些参数随后允许我们进行调整

37:32 针对每个客户群。如果我们不控制你的客户群，而你是 API 客户，那么我们会尝试给你建议，然后你尝试进行那种调整。所以有些东西，你知道，围绕，它并不完全等同于对各个 cloud.mds 或现在的 agents.mds 或随便什么进行个性化的那种水平。但我们确实尝试在努力程度这一层给出一些东西，比如你应该投入多少努力，比如有哪些级别，也许是你可能真正需要关心的模型大小，诸如此类。但我认为它还没有达到我们实际需要的那种个性化水平。所以这是一个非常难的问题。而现在我们解决这个问题的大量方法超出了参数层面，比如给某个东西提供多个参数，老实说，是试图展现出相互冲突的品味，

38:15 综合我们收到的所有反馈，并尝试对其中一些问题做出判断。我认为随着时间推移，实际上，当你扩展到更多客户和更多用户时，这并不是一种很可扩展的做法。我们将需要开发一些方法，让 Claude 能够接收你的个性化设置。也许那是你可以提供的一个信号，或者你可以调优的东西，诸如此类。但我认为我们将不得不采取一条更倾向于那个方向的路线。但就目前而言，是的，我们实际上只是尝试对很多这类事情做出判断，但这相当困难。事情就是这样。这里有一个小提示。我猜默认的 effort reasoning 变了。现在它是 medium。这属于那种可能会影响不使用这个开关的普通客户的事情之一。是的，这就像是一个 Claude Code 设置，对吧？这是一个默认设为 medium 的 Claude Code 设置。

39:00 是的，他们只是……而且这个东西会变化。这个东西确实会……这是一个很好的例子，说明我们用来做某种个性化的一个参数。我得说，这个词可能有点太激进了，但我们确实会针对不同的子群体做一些定制。所以，比如默认设置会根据你是免费客户还是专业消费者客户，或者使用的是 Claude Code、Cowork 还是 Enterprise 之类来调整，也会根据 API 之类的情况来调整。当然，你显然随时都可以调整它，但这些算是我们尝试提供这种体验的一些轻量方式。有一件事我们不太愿意做，就是我们不希望人们觉得自己无法控制对 Claude 的定制。所以在这类事情上，我们本可以采取更强硬的手段，比如，但我们希望给用户能力，让他们按自己认为合适的方式去体验 Claude 的智能水平，尤其是如果你想往更高端的方向走，或者你有时想试试更低端，如果那对你的使用场景来说确实更快的话——我认为这是一个很难的产品权衡。

39:53 所以我们倾向于采用温和的默认值，但会给你提供调整选项，我认为这在目前还算可以。但我设想我们，你知道，会随着时间推移学会如何更好地为客户做到这一点。我们对这些目前都还不是特别特别满意，但我们知道，当我们发布一个模型时，就像你问的，发布一个模型需要什么？显然，我们必须做的一件大事就是，好吧，Claude 在某个方面变得擅长了。而有时候那个方面是我们应该作为 API 参数暴露出来让你控制的。但我认为随着这件事随时间演变，我们最终得到了这种有趣的混杂局面，比如有 effort、有 budgets、有所有这些你可以在 API 上设置的东西

40:31 而这就好像是，任何人怎么可能弄清楚对于任何给定任务来说，正确的组合是什么，你应该去设置什么？而这件事就是我们一边摸索一边弄清楚，和客户一起弄清楚，弄清楚这些参数中哪些我们要随时间弃用？哪些参数我们只要把默认值设得更好？哪些参数应该是 1 到 100 的刻度，而不是低、中、高的刻度，对吧？因为实际上我们已经训练 Claude 变得非常擅长理解这类事情上的一整个选项谱系。但比如，我们要不要暴露那数百万、数十亿种选项排列组合的全部？你其实不会走得很远。而这实际上正是像 Claude Managed Agent 这样的东西价值主张的一部分，它仍然是通过 API 对 Claude 的编程式访问。

42:02 是的，我只是想给大家提供一种方式，比如，如果这就是你使用 Cloud 的方式，那这就是路径。我觉得这种方式也被相当低估了。对于那些不是这样使用 Cloud 的人，什么是 Claude Managed Agents？人们为什么要用它？哦，对。我们可能应该做个简短的介绍。我不知道。那是某人的房子。对。用两句话简单说说。我觉得很多人在这东西刚出来时都忽略了它，对吧？当时每个人都处在这样的阶段：我需要做 harness 工程。我需要控制这个。你听到的都是这些。而现在就变成：你真的需要做所有这些吗？还是你直接用托管智能体，你有很多信息，可以跳过设置？但给个快速的三点说明。对。这取决于你的使用场景。所以 Claude Managed Agents 就是我们今天的 API。

42:47 我们有 Messages API，它本质上就是原始的 token 访问。然后我们有 Claude Managed Agents，它是一套 API，但它让你可以定义一个智能体、用该智能体启动一个会话。它本质上就是一种更高阶的抽象，让你可以跳过搭建所有基础设施、搭建你的 harness，以及做大量那类工作。对于想要以编程方式运行智能体的人来说，这是一个更加开箱即用的集成。CMA 和 CloudTag 共享基础设施吗？因为它的推出顺序看起来非常像，哦，那就是 cloud tag。很多。很多。所以我们做的一件大事是，作为平台团队，我们运行我们的 API。我们也在某种程度上运行我们所有的基础产品基础设施和产品服务。

43:32 一个很好的例子是，我们的团队运营着我们的沙箱集群，它为 Claude Managed Agents 以及 Cloud Tag 等产品提供支持。但在那两个产品实际的 harness 层，我们在 harness 内想做的事情存在差异，所以它们实际上并不共享同一个 harness，但它们共享大量支撑执行和支撑 API 的基础设施。我觉得这真的很……人们应该更多地使用这个。我觉得在你们推出 Managed Agents 之后，基本上每个人都有它的山寨克隆版，而这种模仿是一种真诚的奉承。既然我们聊到这个话题，我们就简要提一下一直在进行的那些记忆相关的工作。我觉得那是 Anthropic 今年上半年工作的重要部分。它是停滞了吗？还是仍在进行中？现在这里的重点是什么？具体是托管智能体。记忆、dreaming。哦，这是我们正在做的事情的重要部分。也许可以这样理解：我们推出托管智能体，是作为一个平台，面向那些不想自己做所有这些事情的人，对吧？或者只是想卸载出去，比如“我要从 Claude 那里获得最好的效果”，因为我们团队就坐在这里，对这些东西做评估，确保 harness 会非常强大。记忆和 dreaming 全都是关于如何确保你的智能体能够随着时间持续改进。而所有这些仍然是我们团队的重要关注点。但我想说的是，回到我们之前谈到的那个点，从安全角度看，发布模型变得越来越难，我觉得我们团队的大部分精力正越来越少地

45:04 比如，这里有个有趣的功能，可以在这个智能体上做爬山之类的，以及更多关于我们如何把安全融入这一切的问题。因为我们能做的最重要的事情，就是把模型的能力释放出去，并且安全地释放出去。所以我想说，我们大量的精力都花在把所有这些相同的概念整合起来，给你一个真正强大的智能体系统，同时也要真正安全。所以这就是我们投入精力的方向。我觉得和今年早些时候相比，我们在技能、dreaming、记忆，以及这类时间点注入方面放慢了节奏。请爱技能。不不不。我们爱技能。我们爱技能。我们正在做更新。我不是说我们什么都没做，但我们也爱技能。不过是的，我觉得相比其他一些工作，我们确实稍微放慢了一点。赞助你的赞助广告位在这里，触达正在构建下一个时代的 AI 工程师。

Latent Space 的读者正是那些在交付智能体、模型和基础设施的人。咨询赞助此广告位：business@latent.space →

45:48 但我们非常看好人们在一定程度上于 harness 层进行爬山式优化，你知道，就像这里之前的对话提到的。我们自己就做了很多这类工作，但我们提供的 harness 在某种程度上非常简单。它是有意保持简单的。我们其实不想过度强加自己的观点。我们希望确保最佳实践被合并进来，并且有一些最难智能体循环中尚未差异化的部分，是的，这些部分很难串联起来。而且，你基本上可以直接用样板代码完成。不过，在此之上有趣的部分是，一旦你有了那个基础层，我们就会构建这些爬山式策略。而 dreaming 实际上就是其中之一。所以 dreaming……在底层是一个多智能体系统，我们在 CMA 之上对它进行了爬山式优化，而且它实际上是一个

46:30 基本上就是在 CMA 之上再叠一层 CMA。在 CMA 之上再叠一层 CMA。它就像又启动了一个，对。Dreaming 的工作方式是，我们再启动一个托管智能体，这个智能体可以检查前一个托管智能体的历史，然后把记忆写入那个托管智能体。所以就是一层层的托管智能体，一直往下。这在某种程度上是设计使然，因为我们设想你大概可以把很多这样的模块化组件组合起来，做出一些有趣的东西。而 Dreaming 只是我们追求的更有趣的东西中的一个例子。但我们一直把这件事看作是这样：其实你还能做大量其他事情。你可以做 best of N，作为一种多智能体策略。你可以做一个验证器智能体，就是那种目标或结果导向的东西。里面还有一堆其他东西。我们见过人们做一些相当古怪、疯狂的事情。比如有一个 harness 会在所有东西之间共享疯狂的记忆。然后他们启动大量并行智能体。

47:16 我们觉得，其实我们大概应该直接让你能这么做。就像我们之前做的那样，我们构建了 Dreaming。那基本上就是一路向下管理智能体。我们很快就会做一个更新，更新底层的原语。我们会把它暴露出来，让用户可以构建 harness 策略，或者随便你怎么称呼这些东西。比如多智能体策略。多智能体策略能让你构建自己的版本。我们会给你模板，比如，这就是我们做 Dreaming 的起点。也许你会想作为开发者对它做个更新，并在此基础上发现更多价值。是的，我觉得这个框架非常好。并不是说我们在这些事情上放慢了脚步，而更多是说，我们已经把原语准备好了。我们可以继续让人们直接拿走这些东西去用，同时给他们工具，说，这里有一些很酷的多智能体策略，以及我们放进 Cloud Manage Agents 里让它真正强大的东西。

48:05 现在你可以让 Claude 去做工作，利用这些原语，并自己让它变得更强大，比如创建新的多智能体策略之类的。虽然我们团队的很多注意力转向了，好，很好，社区，去用吧，对吧？你们做你们的，而我们会继续专注于我们需要做的所有事情，以确保你们能安全地访问该系统内的模型。你提到的一点是，你在这方面跑了很多评估。这是当下相当热门的话题。有什么建议、最佳实践吗？具体针对评估？针对 harness、智能体的评估。评估有很多不同类型，对吧？并不是所有评估对不同的、你知道的、你所处的情况和你试图测试的东西都是平等的。

48:49 你显然有静态确定性的东西，然后你有 LLM 作为评判者。你有所有这些不同的策略。但我想我会说，我们从大多数人那里发现的是，你可能需要更多而不是更少。只是并不存在一两套完美的评估，你把它拼起来就能得到让系统变得更好所需的所有答案。我们发现人们最终需要一套相对庞大的这类东西，然后你可以让你的智能体与你合作，随着时间推移演进你的评估套件，但我觉得在这方面投入不足也许是我们在人们身上看到的最大错误。是的。而且它从简单开始。

49:30 我觉得有些人会有点走火入魔，他们会说，你知道，他们喜欢把菜单上所有选项都看一遍，你听着就会想，哇，这也太疯狂了。让我试试这个那个。哪个最好？而就在他们做这些事的时候，他们实际拥有的邮件数量大概是零。所以你还不如就做点简单的事。会有帮助的。是的，我觉得一部分原因是人们缺乏经验。他们没有受过这方面的训练。他们也不知道什么才算好。完全同意。我觉得对你们来说，多发布一些这样的示例真的很有帮助。是的。我经常告诉别人、并且正在用更多 Fable 和 Astro Class 类模型做的事是，我们把工程当作研究来做。当你把工程当作研究来做时，你自然会做更多评估。你会做更多标注。你会做更多运行的扩展，比如原型设计和运行的扩展。而你就不会把模型当成……

50:15 你是在搭建 harness、做产品，不管具体是什么。但你是把它当作研究来做的。你一开始就定义好你的目标是什么，试着把它形式化为一个评估，然后再去识别，好，它为什么失败？而有时候你的评估是错的。实际上，很多时候你的评估都是错的。有时候是你的环境错了，然后有时候是模型错了。而实际上，我认为这正是 AI 工程正在变成的样子的一大部分，也就是做所有这些事情。完全同意。我们会继续在 Claude Managed Agents 中推出更多功能，让人们开箱即用地获得更多工具来做这类事情。而且你大概会从我们这里看到，你会得到类似这样的东西：这是一个能帮你为你的托管智能体创建评估的产品，或者不管它具体是什么，而用起来会非常像是在和 Claude 一起做这件事。

51:00 因为那才是最好的做法。Claude 其实非常擅长创建评估来评估智能体。对，正是如此。因为人们一看到 JSON-L 就脑子一片空白。对吧？但一个漂亮的评估界面，你在左边、右边、左边、右边、左边、右边地点，你差不多就是在做人类标注员、数据标注员本来就会做的事。对，对，对。你可以自己做。你可以的。就像把 Fable 扔给它一样。对。它会给出建议。但也会写评论，因为它就是输出所有这些评分，对吧？它会给你一个 ELO，给你随便什么。但 Claude 可以直接消费这些，然后在此基础上自我改进，对吧？这就是它需要的反馈。而人们就是不知道你可以用提示词来要一个评估。对。对。我很喜欢你这么说。我觉得这是一种非常“AGI 信仰派”的做法。

51:46 因为它还能让你非常系统化地更新和编辑那个系统。所以随着新模型不断改进、情况不断变化，你确实可以检查你的系统处于什么状态，而它会随着你一起演进。在每个部分都跟上你。完全正确。对，所以基本上，我觉得这就是我们之前谈到的，产品与工程可能正在融合。同时，应用层工程和模型研究也在融合，那些技术正在被共享，对吧？确实如此。做模型的人非常非常习惯做评估。做应用的人知道，你唯一关心的就是它符不符合 PRD？而且，对，这完全是另一套……我觉得这是一套全新的技能组合。我觉得你们今天发了一篇挺酷的博客文章讲这个。有点不一样。

52:30 它是关于让 UI 快得多。但就像你说的，把它当作研究来做，基本上就是先定义一个目标：我们希望东西加载得更快，然后去定义，并且，你知道，去质疑一些事情。除了挂钟计时，我们还能做什么？这里面有些有趣的引语。我觉得看到实际的研究人员或工程师是怎么给 Claude 写提示词的，挺不错的。有些内容是这样的，你知道，我们有 12 件事。我们说你有两周时间。结果我在大概三天里就做完了 12 件里的 9 件之类的。但这是些有趣的博客文章，供人们研究、供人们通读。对，我很喜欢我们分享自己实际用的提示词。有时候人们会说，天哪，有些疯狂又独特的提示词写法。而其实就像，再努力点，Claude。谢谢。我唯一的反馈是它应该链接到 workbench。虽然那东西已经不存在了，但我以前会。

53:17 这是个好主意。这是个好主意。好。反馈收到了。让一切都可回放。反馈收到了。很喜欢。对。对。但你本来要分享更多关于工程故事或者你以前做的 Rust 工作的细节。对。所以我想我之前稍微谈过，规模对我们来说是个问题。所以是规模和安全性，对吧？对。规模和安全性。这是我们花时间最多的两件大事。而且我觉得这真的很有意思，因为大多数人习惯谈论规模，或者只是，我不知道，在 GPU 加速器层面的算力，而在 CPU，你知道，那种老派层面上谈得少得多。而这在今天和加速器层面一样是个大问题，

54:00 这真的很有意思。你拿不到足够的虚拟机。你拿不到沙箱。这主要就是一切都得能启动、启动。用上你所有的资源。对。真的吗？你们客户也很多。对，这很疯狂。对，想想看，因为我们在用 CPU，显然，就像运行我们的产品服务、运行 API、运行我们所有的应用。我们在沙箱上用 CPU，我们做的所有沙箱化。然后还有像 CI 之类的所有事情，你知道，你会惊讶于现在写的代码多了多少。因此，CI 运行也多了那么多。因此，你需要更多 CPU 来处理这些。所以总体上，而且这不只是我们，我交谈过的每个人都是这样。我还要加上训练。训练大概也在用沙箱。所以那是另一个不同的桶，对吧？我确信他们不会那么混在一起。嗯，他们不混在一起，不过对 Anthropic 整体而言，CPU 就像是一场零和博弈。

54:50 你知道，比如我们和CSP谈判我们的交易，我们拿到我们的CPU，然后我们必须在Anthropic内部进行分配，决定其中有多少用于我刚才提到的所有事情，包括比如研究沙箱与产品沙箱等等。所以我们确实是在所有事情之间进行分配。而现在行业里的每个人都是……什么都缺。是啊，以前你只要预算允许，就可以按需扩展到CPU容量，对吧？而现在这变成了你必须提前做容量规划的事情，你知道，这就像是在打每个人的脸。

55:30 这是全新的，人们开始这么做了。所以应对这一点意味着几件事。比如一件显然是，就是去设法拿到更多CPU。好，我们正在尽可能多地这么做。但第二是，我们希望在基础设施层能够更高效地运行它，对吧？比如弄清楚我们如何确保尽可能高效地运行我们的沙箱，同时不在租户隔离或我们关心的安全等属性上妥协。但在应用层，我们如何更高效地运行我们的应用和API？这是我最兴奋的事情。截至上周，我们已全面推出用Rust编写的Messages API，这是那种在智能体编程时代你能做到的疯狂壮举之一，它用了

56:18 就像我们今年早些时候开始讨论这件事时那样。我们说，我们会撞上 CPU 墙。有些事我们必须做。而我们做到了，对吧？比如我们实现了多区域，我们做了所有需要做的事。然后我们说，我们跑着这个 Python 单体，它非常 CPU 低效。那么我们要怎么做才能让系统更高效？于是我们选择了 Rust，这在当时是个疯狂的决定，因为我们的团队——纸面上看很明显，但我们团队里连一个 Rust 开发者都没有。确实。字面意义上没有。不仅如此，但没错，Claude 会来写代码。人类设计系统，对吧？

57:01 所以人类深度参与，确保最终它是一个分布式系统架构，对吧？Claude 既能帮你实际写代码，也能帮那些工程师碰撞想法、学习他们设计该系统所需的知识。但最有意思的是，最重要的两件事是做这件事的计划，以及对这件事的验证。因为实际实现就像是 Claude 在写代码。所以我们最终做的是，我们真的用 Rust 构建了整个 API 的完整分支，然后开始让它跑影子流量，并验证我们从 Python 系统和 Rust 系统得到的输出是否一致。这就是功能开关就够了。没错，字面意义上。负载均衡加功能开关。

57:45 就是，我不知道。在我的职业生涯中，我从来不会有一个团队说，对，对，酷。你们还有 Rust 的人吗，还是没有了？嗯，他们现在大概会自称 Rust 人了。我是说，转向 Rust 有两个非常、非常大的步骤。对，没错。而且在这个过程中，我们招了几位 Rust 经验更丰富的人。但是，对，但这仍然就像你从来不会一开始就签下这种事。那会花上好多年、好多年、好多年。你不会一次性全做完。你会把系统一块块切出来，说迁移这个、迁移那个、迁移那个。轻松就是多年的努力。但你绝不会像那样一口气搞定，对吧，比如把整个东西移植过去，然后只是慢慢把它打开。但那正是我们最后做的事。而且它奏效了。所以不仅我们实际上省下了大量 CPU，而且我们的延迟也有了不错的改善，这也很酷。

58:37 而且，你知道，这只是一个我们身处其中的疯狂时代，因为以前你根本不可能做那种事。在 CPU 方面省下了一个数量级。只是给考虑这件事的人参考。对，对。好，一个数量级，那真的很有意思。大概，对。对，大概。我想我会说，我们看到了大约 40% 到 50%，类似这种真的很夸张的数字。对。然后延迟方面，我想我们在比如首个 token 时间上看到了大约 10% 到 20% 的改善。所以有很多非常酷的改善。在运行时间更长的工作负载上会更高，但它很快就会推出。

59:16 是的。但它会变快。你会抵制这种冲动吗？你知道，我参与过一些重大重写。重写时总会有这种想法：既然反正都要重写，何不加上以前没有的新东西？对吧？对。但那样就会扩大范围。对，对。所以你会刻意避免那样吗？是纯粹的重写吗？我们做了。那是纯粹的。也许我会称之为移植。我们所做的就是完全照搬。我们抵制了所有这些事情的冲动。而且，因为团队本来就要应付的事情已经够多了——我们组建了一个小型的交换团队来做这件事，而团队其余所有人都在往 API 里构建功能，对吧？他们做了所有静态分析之类的东西，一旦你在这边加了个功能却没在那边考虑 Rust，它就会冲你大喊大叫，对吧？他们处理了所有这些，但他们克制住了自己添加功能或改变系统的冲动。

1:00:05 现在他们的下一个目标是去做某种重新架构类型的工作，包括我认为会更面向用户的东西。比如我们开始推出一些东西，像是，你知道，如果我们能让你不必来回传递整个对话状态会怎样，对吧？如果你不必在 Messages API 上这么做，因为你可以接受把那个状态存储一段时间，对吧，那么，尤其是对于上下文真正积累起来的长对话，你也能在那里获得大量很棒的延迟和效率收益。比如，这些正是做那次移植的团队会想的事情：哦，如果我们这样做会怎样，对吧？

1:00:45 你们的缓存 API 没有这个功能吗？所以，我们有提示缓存，是的。但你仍然必须，比如，把对话状态传回去。好。非常、非常小众，小范围的子集。但我想这就是目前的水平。不，这很重要。对，对，对。可以节省很多，但这也把它们变成了一朵云。对，然后从用户数量的角度看，它很小，但如果你看这类工作负载上的实际 token 量，它会占大多数。我非常喜欢 Cloudflare 用 durable objects 做的事，我觉得每个云提供商都应该克隆它。你懂我的意思吗？对。对吧？这不正是需要延续的 messages API 该有的形态吗？对，我的意思是，这真的很有意思。因为我觉得我们正在试验各种方案，比如我们应该以什么样的正确形态来运行我们的计算，以支撑所有这些类型的东西。

1:01:31 但这也很有意思，因为我们不能必然依赖，因为我们的计算资源是跨云获取的，我们在三家云上运行，到处都在跑。我们不一定有某一种固定的形态，比如这里确切就是计算资源、我们知道要运行的机器类型，以及某些计算的工作方式，让我们可以全面依赖，如果这说得通的话，除了这些最基础的版本。但我觉得这些东西都会，我不知道，随着时间推移继续创新和演进。所以我们就能更好地利用这些东西。是的。我只提一句，如果人们想要开源的 Cloudflare、durable objects，Rivet 就是那个开源方案。有 50 个听众，如果我不问这个问题他们会杀了我。你们想要 CPU，他们有 CPU 要卖。我该卖给谁？我该给谁发邮件？

1:02:16 那什么是一个好的……帮他们帮你们，对吧？比如，那看起来是什么样的？嗯，我想，就给我发邮件吧。你确定吗？我不知道。我会收到很多邮件。但是，比如，你们要看的是，比如最小机队规模、SOC 2，显然还有企业级。对，对。把所有隐私保证都给我。而且值得一提的是，我们有一支非常棒的团队负责保障我们加速器计算的安全。是的。他们现在花更多时间跟我们一起研究 CPU，以及我们能在哪里、如何采购它，以确保我们能继续以所需的规模运行我们的系统。所以实际上，幸好我的工作不是到处跑去采购计算资源。

1:03:00 但我们确实有团队在做这件事，这非常棒，也非常重要。但显然，有一个质量标准对我们很重要。有一个规模标准对我们很重要。如果拿不到足够的量，我们就不会去集成并在某些机器上运行。所以，你对这种规模的系统可能期待的所有特性，对我们来说都很重要。然后，与计算问题相关的是沙箱问题。人们很难把智能体限制在沙箱里。它们总是逃出来。这是怎么回事？目前最先进的做法是什么？是的。最近越狱的现状。是的。这很有意思。我们专门针对 Claude Managed Agents 做的一件事就是它的架构方式。我们在发布时发了一篇博客文章，谈到我们把大脑和手分开。这意味着 harness 运行在一台持久化的服务器上，实际上是我们自己的服务器，对吧？

1:03:49 哦，哇。不错的引用。是的，这很好。而手就像执行环境，比如沙箱或某种容器，对吧？我们这样做的部分原因是为了延迟和可靠性之类的东西，对吧？比如，如果 harness 只是运行在一台持久化服务器上，只在需要执行时才启动一个沙箱或容器，这意味着我们可以在你的初始请求上很快把 token 返回给你。这意味着你的沙箱可以死掉，但你的整个智能体不会死，因为 harness 是持久化的、在这边，而且，你知道，智能体也单独存储状态。我们经历了一整段产品开发历程才走到这一步，因为我们第一版的智能体 API 基本上就是把 Claude Code 扔进沙箱，然后在上面套一个 API。

1:04:32 而我们之所以没有把它作为我们那种持久、可扩展的解决方案推出，原因就是我刚才说的一切。就像你必须先启动一个沙箱、再启动 Claude Code，然后才能拿回一个 token，对吧？沙箱一死，你的整个智能体就没了。所以可靠性没有达到我们想要的水平。因此我们这样设计架构，主要是为了可靠性和延迟。但有意思的是，其实从一开始就参与这个项目的产品经理当时就说，这个架构最重要的特性是安全性。大家都说，对对对。但大家关注的是延迟和可靠性。而现在，他们被证明是对的。我昨天真的向这个人道了歉。我说，我现在逢人就讲你几个月来一直在说的那些事，而当时没人像你那么上心。

1:05:15 但这个架构更重要的特性之一是，智能体需要执行的任何工作都有对应的凭据，对吧？比如你要去跟一个 MCP 服务器通信，或者你要用某个 CLI，或者调用某个 API，不管你想做什么，对吧？你需要对这些东西进行认证。你需要把那些凭据存在某个地方，好让智能体能够使用它们。我们设计这个架构的方式是，我们有一个完全独立的保险库来存储这些凭据。一旦智能体决定，比如，我要去调用这些服务之一，智能体看到的永远只是一个占位符，对吧？而在出站时，我们有一个代理，它会去取出正确的凭据、注入进去，然后放行。所以有意思的地方在于，智能体从来不会和凭据处在同一个地方，对吧？

1:06:06 因为在旧的世界里，你只要把智能体启动在一个盒子里，然后让它跑起来，你就得把凭据送进去。然后你就得琢磨，我们怎么清理这个那个，怎么确保智能体不能拿着那个凭据去做它不该做的事。而现在就 literally 是一道基础设施的墙，说智能体不能访问那些凭据，也不能用它们做任何坏事。所以这是非常棒的一点。另一个好处是，在那套沙箱基础设施上，我们可以确保拥有非常好的出站控制。比如我们有域名允许列表之类的，或者你干脆完全切断网络访问，这样你就不能说，好吧，智能体写了不受信任的代码，代码在沙箱里执行，

1:06:47 然后那段代码就能连上互联网，对吧？现在它只能连到你说它可以连的地方。所以围绕这一切，在架构层面、在沙箱的配置方式层面，都有很多非常好的特性，让你最终做到默认安全。现在开始出现的一件事是，我们在和客户交流时，他们会说，我想运行智能体，要么是为我的客户做一个产品，要么是在内部用。但我会听到一些事故，智能体逃出了沙箱，发生了坏事。我该怎么考虑这些问题？我认为最重要的两件事是架构，让智能体 literally 不可能做出不被允许的事，以及你在那些沙箱上的配置。所以 Claude Managed Agents 一个非常非常好的地方就是，你开箱即得。

1:07:31 而且你开箱就能得到一些东西，随着我们了解更多、并不断演进这些系统的特性，你基本上就能免费获得这些。因为我觉得我刚才说出来的所有词，比如大脑、手、凭据、注入和出站等等，就好像，如果你回到九个月前，没人会说这些词，对吧？这些全都是我们正在解决的相对较新的问题。所以我们希望我们的客户能够利用这些问题的解决方案，哪怕我们自己都还在学习并在我们的基础设施内解决它们。是的。而在内部，我们只是把一切都升级到基本上默认安全。是的。但这样更好。我们还解锁了一些我们在 Direct 播客里讲过的东西，也就是 CloudBrain Local Hands，那些项目。

1:08:15 是的。这大致就是正在发生的情况吗？对。看起来是这样。是的。我觉得这有点奇怪，因为显然你出名，或者说 Claude Code 出名，是因为它是你机器上那个超级不安全、危险地允许一切权限的东西，但现在你终于演进到了你大概一开始就该在的地方。基本上我觉得，所有这些沙箱逃逸，对吧？它们是我们对沙箱或容器技术理解的根本性问题，还是我们只是不擅长这个？我们只是没做允许列表吗？听起来我们只是没做允许列表。是的，所以也许我想做的一个区分是，在人们听说和读到的很多事件中，这些事件是发生在模型身上的，而不只是所有人的模型，对吧，

1:09:01 也就是在训练中，你运行这些模型的方式是把它们放进一个盒子里，然后你说，去解决不可能完成的任务吧。我要给你施加压力。预备，开始。对吧。而你只能在自己的环境里做你能做的事。而智能体基本上被激励着去尝试逃出它的盒子，去解决问题。当人们在我们的 API 或任何其他人的 API 上运行生产工作负载时，你运行的环境里有正在运行的防护措施，这些措施不一定在训练中运行，因为训练的全部意义就在于真正训练模型。对吧。但在生产工作负载中，首先，你有那些在线防护措施，这真的很棒。其次，围绕正在发生的事情，你有更多这样的架构和基础设施。比如智能体并不是只在一个盒子里试图逃出去，对吧？比如 harness 在这边，手在那边。而这甚至就不是一个

1:09:47 你需要考虑的问题。所以我认为，其中一部分只是人们正确地理解了正在发生的事情：模型训练中以及其他场景下发生的一些事件，只是在生产工作负载中不会发生，因为在生产环境中已经做了大量工作来设置正确的防护措施，使得那些事情几乎不可能真正发生。我想说的第二点是，大家都在相对较新地摸索这一切，因为长时运行的智能体是一个相对新生的事物，每个人都在构建并试图应对它。所以大家都在边做边摸索其中的一些问题，并争相设置正确的控制措施。而且，其中一些只是随着我们推进而自然发生的。所以我想说，这并不是说人们不擅长这个，对吧？我认为这更多是因为这是一个新兴领域，

1:10:33 人们正在摸索。而且我认为，当我们谈论为前沿发展设定节奏时，我们的思考方式非常具体：我们正在为我们内部所有智能体做我们这里所谈论的全部工作，并确保所有客户都能使用这些东西，这样默认情况下正确的防护措施就已经到位，你就不会最终让智能体做出你不想让它们做的事情。说得对。因为你提到了节奏，我们必须谈谈这个。我们上次也谈过这个。倡导设定节奏，然后11天后又发布一个新的前沿模型，这表面上看起来是矛盾的。对我来说，这只意味着它通过了你的安全检查，对吧？是的。我们之前谈到的关于我们如何发布模型的一切，

1:11:19 这就像我们正在持续演进，不断加入越来越多的安全属性，而且，再次强调，是在这些方面——我开始从这三个维度来思考这件事。一个是实际的架构和基础设施安全。然后是模型执行任务时运行的在线防护措施。再然后是对静态数据进行分类的离线防护措施。所以在这三个维度上，我们都在把该做的工作做到位，以确保我们非常有信心可以把模型发布出去，而且它会是安全的。从根本上说，这就是我们的意思。所以对于 Opus 5.5 来说，它是一个非常出色的模型。在我们关心的这三个方面的所有维度上，它也都非常非常出色。因此，我们对发布这个模型感到放心。

1:12:01 所以我们选择了我们认为、也希望是在此范围内尽可能最佳的用户体验，同时我们继续努力改进那些误报。但显然，当你想用一个模型工作、结果却回退到另一个模型时，这对人们来说仍然是一种令人沮丧的体验。所以这是我们必须要继续努力的事情。我认为人们从安全角度也能理解这一点。就像你希望有更多误报，对吧？因为这是个安全问题。我们清楚地看到了整个侵入事件，而你仍然在给予访问权限。对我来说，这就像是通用模型路由问题的一个近亲：你想要智能路由器还是笨路由器？这样说有道理吗？有道理。因为据我所知，Anthropic 的回退路由器或检测机制是一个单独的在线模型。

1:12:46 一旦它碰到分类器，就只剩下逻辑，你只需要把它丢掉。所以这不是完整的 Fable。你并没有把完整的 Fable 跑在上面。而这会导致分类问题，因为它显然没有 Fable 那么聪明。很明显。所以问题就来了：当我遇到分类问题时，那就像是一次没有正当理由的回退。你根本不需要回退。我只是在做我的生物作业。但我提了一次生物，然后它就可能回退。所以这里有个问题。然后这和路由问题非常相似，因为你的路由模型——一个笨模型如果连这都识别不出来，它怎么能路由到一个更聪明的模型？那是聪明模型才能解决的问题。我们怎么解决这个？这是个难题。我觉得在某种超级对齐的意义上，

1:13:32 模型擅长对东西进行分类，但不擅长回答它们，对吧？不是最聪明的模型才能判断这是一个危险查询，即使它对此产生不了任何影响。我觉得超级简化的说法大概是：基本上，你让更聪明的模型去搞明白那个它需要检测的东西。我觉得它在 X 成本上更慢。有取舍。有取舍。我不是说这就是正确的用户体验，但它可能会是一条稍微更有效的路线。我觉得一件有趣的事是，你也不会立刻切断。我见过一些情况，它会开始回答、开始推理，然后被安全过滤器拦截。所以我第一个关于 Fable 的例子就是触发了 Fable 安全卡。它开始了，我当时想，就把这里任何有趣的东西拆解一下吧。

1:14:15 开始，五分钟后它就开始拆解了。我觉得它进入了网络安全的部分，然后就像是，哦，我们要削减，我们要回退到 Opus。但它做了很多。有很多上下文，我看到了。它到了某个点，全都围绕网络安全、安全，然后我回退了。而且它并不是在回退我的查询。它是推理和整个链条的组合，对吧？对。你知道什么更好吗？对，我们来头脑风暴一下。什么更好？我觉得用户体验以及我们如何解决那个用户体验，可能是一个，你知道，单独的问题。也许是一个超级聪明的模型来处理它之类的。但我觉得，我会为用户设想的更合适的用户体验，实际上是拥有一个更一致、统一的 Claude 体验，而不是让你回退，然后你还可以双重回退，

1:15:00 在我们的树里确实有一些逻辑点会这样做，同样是为了安全原因之类的。但我觉得那个用户体验对用户来说实在是太绕了。就像你几乎，你在试图做某件事。我大概会拿一个好用户的情况来说。你是一个好用户，只是想完成你的生物作业，比如评估网络安全，比如安全卡，完全合理。然后你被拦截了，你回退了。我觉得相反，它应该只是，你处在我们的模型本应达到的位置，或者分类器，或者不管我们想怎么做，会足够聪明地检测到那是会发生的情况。然后直接为你更具体地写下答案，同时降低那个特定能力的负面用途的性质。所以回到那个生物作业的场景，虽然我们可能有分类器检测到它可能是生物的。

1:15:47 我还要说，在 API 方面，我们为客户提供了一系列解决方案。所以首先，如果你在 API 上构建了某些东西，然后遇到了阻塞，你不必像在回退方案上继续对话那样。这就是我们在自己的应用中所做的。我们把它做成了 API 的一个特性，你可以在我们的 API 中在服务端这样做。你可以选择设置，比如，我想做回退，对吧？然后，我们会那样做。我们在客户端的 SDK 中也有这个功能。如果你想以各种方式管理回退，有相应的辅助工具，或者你可以选择以某种方式用不同的提示重新提问，对吧？然后用同一个模型继续。但我确实认为，还有一些介于两者之间的有趣解决方案，我们会

1:16:30 继续试验，弄清楚我们如何解除对用户的阻塞并安全地做到这一点，同时提供良好的用户体验。是的。然后你提到了那个我觉得和路由器非常相似的点。我想，我完全同意。我认为它也有类似的用户体验问题。就像你用路由器一样，比如说你想做一个成本路由器，对吧，根据你所拥有的任务复杂度。这说得通。但非常难做。你并不能预先知道关于任务的所有信息。所以即使拥有完美的信息，你也做不到，你实际上并没有完美的信息。即使你能够完美地理解每个模型——而你并不能——但即使你能，你对自己的任务也没有完美的信息。因此，无论你训练出的分类器有多好，你所要创建的路由逻辑都会伴随着大量误差。是的，也许这属于那种需要超级大脑模型来解决的问题，但无论如何，我认为这是一个非常困难的问题。而在每一种场景中，如果能找到一种方式来路由

1:17:17 妥善地做到这一点，它非常、非常复杂。你可以把所有这些逻辑都暴露给客户，比如，嘿，你知道，你的任务是把一个 div 居中，所以我会把你路由到某个超级便宜的东西上。然后还有其他的，比如检测漏洞，所以我会把你路由到某个非常昂贵的东西上。如果你把所有这些都暴露出来，我认为最终那也不会是一种很好的用户体验。而对于那类相似的问题，我认为更理想的用户体验应该是类似动态投入，或者动态理解你任务的复杂程度，而随着你对任务了解的信息越来越多，这种理解实际上可能会随时间演变。但在那种世界里，如果你在大量不同的模型之间来回切换，它实际上会变得非常、非常割裂。所以也许一种更统一的方案应该是类似这样的：它是一个一致的模型，

1:18:01 但它的投入程度非常、非常低，或者类似那样。它实际上非常、非常便宜，非常、非常实惠，但它可以非常、非常持续地自我扩展。但你对那个模型有一个非常、非常一致的人格设定。显然，在比如我们模型家族的语境下谈这个，如果你甚至试图跨其他模型家族、其他模型提供商去做这件事，比如人格、那种割裂感，就会开始变得非常、非常复杂。我不知道你在那一层怎么解决它，但至少在我们自己的模型家族范围内，我更看好那些更一致的东西。而那些可能是为客户更稳健地解决这个问题的方法。是的，你不必为其他任何人负责，但在 Cloud 内部，是的。是的，我是说，这是你的地盘。是的。很高兴看到你们思考这些问题的方式，对吧？意图本身就是个难题。我感觉模型已经变得更好了，

1:18:46 但有时候人们并不能很好地对自己想要的东西进行分类，或者他们直接把滑块拉到某一个极端，或者，你知道，模型并不能真正理解。你问的是一个简单的问题，结果它却像，哦，我现在有一整个 HTML 落地页了。我本来只期望几行输出，你知道吗？所以那里总是存在一些错配。是的。我觉得，在这次对话中我们谈了很多关于安全的内容，我们谈到了发布模型之类的所有这些东西，但这显然是为了帮助为人们的工作负载提供动力。而且就像我们在这次对话较早部分讨论的那样，我们看到工作负载正在发生相当大的变化。我觉得在某些工作负载中，智能似乎越来越趋于饱和，这算是一种新情况。而且事情正在发展到这样一个地步：我认为还有某一类任务仍然

1:19:32 非常、非常不饱和。我实际上认为这类任务比人们可能预想的要多，但它们正越来越朝着这个方向发展：你通过执行极其长时间运行的智能体任务来获得那种 alpha 或那种回报，而这些事情在历史上你其实并不能真正靠蛮力解决。但也许有了更多智能的加持，你就能做到。而那些工作负载对我们来说真的、真的非常吸引人，我们在这类领域看到了很多价值，既包括企业从中为自身获取价值，也包括，你知道，那些有兴趣在其之上构建某种类似衍生产品的公司或初创企业，或者不管你怎么表述。我觉得如果你看看今天这一类东西，很多显然都是编程相关的东西。显然也有很多类似企业创新加速之类的东西，但它们往往呈现出自动化的形态

1:20:15 一个非常独特且具体的过程。我认为在某些领域，这实际上真的开始奏效了，这很棒。在某些领域它仍然不行，所以对于那些模型来说，仍然有很大的演进和推进前沿的空间。然后还有这一类新的工作负载，比如我们谈到的生物相关的东西，或者一些网络相关的东西。它只是一组非常、非常复杂的困难工程或困难科学问题。而这些工作负载也越来越多地出现在我们面前，对我们来说是一个真正有趣的空间，可以为客户交付价值。你知道，你身处世界上少数几个地方之一，在那里你正在发现所有这些工作负载，而我们正在将其自动化。这就像……是的，这相当疯狂。我是说，你知道，这非常鼓舞人心。你们正在产生如此大的影响，我对此真的非常感激。

1:21:00 我们要进入几个收尾问题，我觉得让你们两位来回交流一下会很有趣。你们在团队中如何对抗 Slop？所以我们实际上，这一直是我们团队内部一场有趣的辩论。我们和其他任何人没什么不同，对吧？我认为很多团队都在讨论这个。有趣的是，我们试图弄清楚的是，如果你在制作一份文档，你在制作某种你希望别人消费的东西，代码、文档，随便什么，对吧？如果你应该用 Claude 来帮你，当然，对吧？但如果你用 Claude 来完全生成一个东西，你没有花任何时间自己去实际阅读它并确保它是高质量的东西，那么你就是在给那份文档或那个东西的消费者增加一整个额外的负担

1:21:45 代码之类的，花一大堆时间去试图解析它，这简直疯了，而且完全不公平。但有趣的是，你知道，我们会反过来要求，我们会要求我们的团队，你不能那样做，对吧？比如如果你在产出什么东西，用 Claude 或随便什么工具，但你得确保它是高质量的东西。是的，作为人类，你仍然要对质量负责，对吧？你仍然要对质量负责。但然后你就会遇到一件非常搞笑的事：因为那些 Claude 式的痕迹，哪怕只是很傻的，比如，我不知道，那东西中间有个破折号，对吧？人们的大脑就会触发这种反应，哦不，我读的东西是 Claude 写的，不是人写的。我就会很烦，因为我想读的是那种，不一定是完全由人类产出的，但至少是达到人类会坚持的质量标准的东西。

1:22:30 对。然后我们就会遇到一些好笑的情况：也许实际上这个人确实花了很多时间确保这个东西质量很高，但他们用了 Claude 来帮忙。可那些 Claude 的小痕迹一出现，读者就会反感，你知道，那同样也是没有产出的。所以我们一直试图做的，就是在我们团队内部设定一个标准，基本上就是：用 Claude 来帮你，因为如果你不用这个强大得离谱的智能体来加速你的工作和生活，或者帮你产出更好的东西，那真是太傻了。但它必须达到某个标准。然后对消费者和读者来说，如果它真的就是垃圾，那就退回去，对吧？就直接说不行，直接退回去。你不会在这上面浪费时间。但也不要对那些小小的 Claude 痕迹过于吹毛求疵，对吧？

1:23:17 因为我们必须在这里找到正确的平衡。所以这真的很好笑，因为你知道，我们团队内部一直在来回讨论这些东西。而世界上其他所有人现在也一样。我们并没有什么不同。但你们有免费 token。嗯，当然。但我的意思是，放到生活中，那往往没那么重要。所以你们比世界上任何人都多。你们可能见得多。你们用得也多。你们看到更多人在做更多的事。是啊。是啊，这完全说得通，但这绝对是，绝对是……被大力劝阻的。对。工程上的垃圾？是啊，我的意思是，同样的事，对吧？但我确实认为我们已经到了一个相当不错的位置，就是，你知道，人类在确保系统设计良好方面扮演着重要角色，对吧？

1:24:01 而且实现往往会被削减，对吧？而且我们现在的处境相当不错：对于大量被写出来的代码，你真正需要的只是一次快速的盖章确认，然后就能继续推进。而且你不一定需要有人去逐行深入审查代码，因为你更在意的是整体计划、整体设计是否处于良好状态，而不是那个精确完美的实现。当然，还要依赖大量验证来确保你要发布的东西是高质量的。所以如今关于代码质量是否垃圾的讨论其实变少了，部分是因为 Claude 变得更好了，但部分也是因为我们有了很多正确的验证机制，确保我们维持着高标准。我明白了。相信你的测试。是的。

1:24:45 任何产品上的 PM 垃圾，你可以大量发布功能。你可以在一天内把东西推出去。所以他最近对我说了这番话。你还记得他对我说了什么吗？Tarek 发了这条推文。正确使用模型能力的方式，不是把 10 倍多的功能塞进生产环境。花更多时间去理解你的用户、做实验、构建等等。但基本上，你很容易就能一直发布随随便便的东西，但你应该真正去思考。你应该花更多时间打磨第一个提示词。我知道现在他会说，启动计划模式。我们不再需要它了。但在计划模式之外，你应该思考你在做什么，对吧？很容易推出大量东西，你也能把产品做出来。是啊。我的意思是，我倾向于就这个问题发一通牢骚：有很多就是基本功

1:25:30 关于软件如何成形、产品如何被规划和发布，以及诸如此类的事情，并不会仅仅因为智能体在帮助加速流程中的某些环节就需要改变。但很多人身上开始冒出一种近乎天生的懒惰，就是那种，哦，我完全不用去思考流程中的某个部分，因为智能体在做这件事、在帮我之类的。但这些仍然是流程中极其基础的部分，应该是你投入时间和精力的地方。我觉得这大概就是他想表达的精神。就像作为创始人或创作者——我们也这么称呼吧——感觉现在实验或探索的成本太低了，所以我应该多做这些。而他基本上是在说不要那样做，

1:26:16 要把它用于服务于一个我从一开始就定下的非常明确的目标，这我显然正在逐渐接受。只是很难。就像你有了这个玩具，它什么都能做。就像，往墙上扔就是了。是啊，这里也有范围的问题。比如今天那篇博客文章是“两周让 Cloud AI 更快”。里面有 12 件事。我们完成了，有 13 件事。我们在三天内完成了 13 个目标中的 12 个，对吧？嗯，你本可以就停在那里，好吧，这是两周的冲刺，我们做那 13 件。但相反，有 20 件事你推进了边界。这不是产品垃圾。不是新产品。是重构。但尽管如此，你们在输出大量内容的同时保持高标准质量方面做得非常好。是啊，不错。好，第二部分，或者第三部分。这会让 Angela 非常不舒服。

1:27:00 这里是 Angela 推文角。我会告诉……不错。我不知道。我会不停地跟人说……而且我很确定你删过一些东西。因为我心想，你删掉的东西里有那么些，让我觉得……是你喜欢的？对，我知道。它真的改变了我的 DNA。哦，我很感激。你思考得最多的是什么？你最常向别人推荐、最想拿出来说的是什么？如果你想的话，我可以帮你找出来。其实说实话，我不觉得自己有最喜欢的一条。哦，得了吧。不，我真的没有。好吧，我猜也许我喜欢你说的那条，说一件事只做一半，是一种昂贵的“不做”方式。也许那就是我的最爱。这跟我们今天的主题非常契合。好，不错。好，谢谢。很喜欢。就是它，对。

1:27:45 我想，你知道，显然你现在做的是另一份工作，不再做这个了。但我觉得这是一条很有力量的推文，这有点像 Naval 的推文——Naval 就是你说的那种人，对——那么，你当时处于什么模式、什么心境、什么思维框架里？这问题问得好。对，不，这是很久以前的事了。我经历过人生中一段时期，那时我一直在不停地读书，其实我发现自己对当时在做的事情感到非常无聊，觉得自己就是没有受到智力上的挑战。所以我实际上经历了一段相当放纵的时期，我想我在大概一年里读了差不多 200 本书左右。我就是很好奇，我就是想

1:28:32 把所有东西都读完。而我当时缺少了一点那种，怎么说呢，那种智力上的、那种肌肉锻炼，就像你在学校里会得到的那种，他们会说，这是一个新话题，你得去学。它挺难的。其实它并不是特别有趣，但你确实在真正地拉伸自己。而我觉得，在仅仅工作了几年之后，我就停止了那样做。就像，是啊，这份工作挺有意思的。是的，它挺有挑战性的，但它没有那种智力上的成分。所以总之，我就经历了一段小小的放纵期，一段阅读放纵期，我一年里大概读了两百本书。太棒了。我当时通勤时间特别长。所以那算是很好地利用了我的时间。非常长的 Caltrain 车程。但最终我从那段时期走出来，然后我就想，正因为那段经历，我思考了很多。而且当时真的不是为了积累 Twitter 粉丝或者别的什么。

1:29:17 我只是像对着虚空发推。我当时几乎没什么粉丝。那些推文是写给我自己的，我在练习一点点，比如，我怎样才能用尽可能少的词把我脑子里的想法压缩出来？那算是我对自己的一种个人测试。然后我猜人们就开始喜欢它了。所以我就这么一直做下去了。后来我工作太忙，就停下来了。我得问一下，在读了那么多之后，有什么书、博客、长文章可以推荐吗？我最喜欢的可能仍然是纳西姆·塔勒布的《黑天鹅》。那对我来说，至少是那种有点像改变人生的哲学书之一，让我觉得，那是一种完全不同的看待世界的方式。

1:30:01 你知道，当那个寓言般的事件发生时，我想到了《黑天鹅》，对吧？就是那种你根本不知道会发生的事。而一旦它发生了，它就永久地改变了你理解事物运作方式的框架。正是如此。这个想法如此简单，但我觉得他做得非常出色，真正把它讲透了、表达清楚了，还说明了它为何是世界如此多领域的共同属性。所以我真的很喜欢那本书，那大概是我的最爱。对听众来说，如果你对那本感到厌倦了，可以读读塔勒布的另一本《随机漫步的傻瓜》。你喜欢《黑天鹅》吗？《反脆弱》？没那么喜欢。他越出名，就越让人难以忍受。不过，凯琳，我也有个问题要问你，如果你有的话——你有没有类似这样的一本书，你会推荐给所有人？不，这是个好问题，我得想想。有意思的是，我确实

1:30:45 觉得我们在这方面风格很不一样，比如她不再处于那种幸运饼干式发推的模式了，但我确实觉得，你不再那样了，但我确实觉得你工作方式以及与他人合作方式的一大部分，有时就像哲学家模式，你知道，幸运饼干和 Slack 哦，我其实不是故意的，我觉得它可能只是某个地方，我觉得这就是他在话题上取得成功的核心秘诀，就像你必须在 Slack 上非常出色，是啊，哦，你必须非常出色，对吧，嗯，那是个相当紧张的地方，但我觉得我有点，所以我对邮件和 Slack 的收件箱清零都有点强迫症，如今邮件比 Slack 容易些，嗯，但我喜欢相当激进地清理，比如这些是我真正在、并且关注的频道，而那些则是被静音、排在线下的那种

1:31:30 之类的东西。我总是确保自己掌控着那些我需要掌控的事情。但这基本上感觉像是一份全职工作。比如有些日子我会想，我可以取消所有会议，不写任何文档，不做任何工作。对吧。就真的整天坐在那里刷 Slack。而我仅仅通过在 Slack 上参与所有那些事情，就会感觉自己已经完成了一整天的工作量。这挺疯狂的。不，但那太糟糕了。所以那正是我的感受。我觉得你做了所有这些事。你投入了所有这些努力。是的，比如你在回复别人、把某些事情推进过线方面达到了标准。但我们实际上并没有产出你想要的那种成果。而这对我来说，是个人层面非常难以应对的事情。所以我试着做到，我需要专门留出时间来真正思考，真正尝试产出一些东西，才能感觉自己确实在……并且忽略和放下一些事情，对吧？

1:32:15 你总得放下一些事情。是的，我收到了很多反馈。我在 Slack 上有点难联系到。是的，现在发生的一件挺糟糕的事是，我收到很多 Slack 消息说，你能让 Angela 回复一下这个吗？而我正努力在这里写一份文档。所以你们没有类似个人云端助手之类的东西吗？我不知道那能不能帮到你。那为什么没有人给你们每个人写一个个人 EA 呢？是啊，嗯，所以我们也有一个人类的。我们在 Slack 上当然有大量云端帮助。但我确实认为，当我筛选和处理那些 Slack 消息时，它们往往只是我们团队因为某个需要做出的艰难决定之类的事情而被卡住了，对吧？

1:33:00 这就像是一种形式，不管是在 Slack 上还是通过其他方式，对吧？就像是一种让团队解除阻塞、以高质量执行的方式。反正这就是我的工作。而且它恰好经常发生在 Slack 上。但我确实同意，当你一整天都在跟人来回沟通、试图解决问题之后，最终会感觉，我到底产出了什么？你产出了一个能正常运转的团队。对，正是如此。那是解除阻塞的。所以作为前管理者，我要为此给你点个赞。就是这样，对对对。你不会觉得自己产出了任何东西，但你产出了团队。对。对。说到你的团队，我接下来本来就要找你，Katelyn。DevRel 角落。哦，不错。我们，我知道你正在大力招聘 DevRel，所以我要为开发者关系发一个招募邀约。不错。你最近招了 Addy Osmani。

1:33:45 对。很棒的收获。Lance，你知道，你还没有团队。你们想招什么？你知道，这正是要聊的。我很乐意交换笔记。是啊，为你点赞，因为我要说，当我——我是 Anthropic 的全源招聘，Katelyn 的招聘团队。真的，真的。这很有趣。而且实际上甚至不只是招聘。我要稍微替你吹一吹。所以当我加入 Anthropic 时，我们，你知道，我们是个小团队。我们，总的来说，是个极小的团队。所以我们运营平台、API 业务以及我们所有的产品基础设施。而我们当时在 Anthropic 内部有一个非常初期的 DevRel 职能，你知道，它不一定在产品与工程组织之内。

1:34:30 我刚加入的时候，我们大概是这样的：好吧，我们得稍微成熟一点，得想清楚怎么去和社区互动、和世界互动。我们得真正投入这个 DevRel 职能。最后我们在 Platform 里组建了一个 DevRel 团队，在 CloudCode 里也组建了一个 DevRel 团队，部分原因是，我们试图在 API 业务和 Agenda coding 这两块去接触的，是两个相当不同的开发者生态，对吧？所以我们最终把它做成了两个独立的团队，但彼此之间有点像虚线汇报关系，而且花大量时间待在一起。但这件事是我要负责的，比如 DevRel——我在 Stripe 之前或之后都在 DevRel 上花过不少时间，但它从来不是我负责的东西，我当时就想，我完全不知道自己在干什么，然后你说，交给我吧。

1:35:16 比如 DevRel 的三大支柱是这样的，你应该这样去思考它——这真的非常棒，涵盖产品、内容、社区，现在我可以张口就向别人讲这套东西，他们就会说，哇，你真的懂 DevRel，我说，不，这是 Tommy 你的功劳，我是抄来的，那可不是我的原创。那篇文章显然已经成了 Google 给新 DevRel 做入职培训时的默认读物。是的。真的很好笑。是的。它真的帮了我大忙，因为我完全不知道自己在干什么。但除此之外，我现在在 Platform 里的 DevRel 团队还没有经理。所以这是我希望能招到人的事情之一。而且我们的 DevRel IC 直接向我汇报，部分是因为我觉得这现在是一个非常、非常、非常难的问题，但部分也是因为我觉得它真的很有趣，我和这个团队一起工作非常开心。

1:36:03 但具体来说，平台业务难就难在，有时候在我们的公共叙事里，我们的平台业务其实规模很大，但它很容易被淹没在研究、政策以及我们显然在做的所有这些工作之间。那才是我们最前沿、最重要的工作。然后是我们的应用，比如 Claude Code 和 Cowork，以及这边正在发生的所有事情。当你想到……Anthropic，想到我们的公共叙事时，这些往往是首先浮现在脑海里的东西，而相比之下，我们正在运营的这个庞大的开发者平台业务就没那么显眼——它其实非常重要，有那么多人在它之上构建。所以我们在平台内部的 DevRel 团队有一个很大的目标，就是弄清楚，不只是那些非常经典的，比如我们如何更好地与产品团队互动，你知道，比如

1:36:46 人们在构建什么，以及我们如何把反馈带回产品中，诸如此类的事情，但其中很大一部分其实只是找到我们自己的声音，弄清楚我们的品牌应该是什么、我们的叙事应该是什么，以及我们在这个社区里究竟要成为什么样的存在，而不是在发生的所有事情中迷失方向。所以我觉得这一点很有意思，因为我们已经开始为 DevRel 团队打造的品牌，部分原因其实是 Lance 加入我们团队——是你把 Lance 介绍给我的——但 Lance 在技术方面非常强，他做 DevRel 的方式非常像教学，对吧？比如他写了很多关于内存和成本管理之类的内容。而且他钻研得非常深。他会构建评估。他整理了大量非常技术性的内容。我真的很喜欢这个想法，就是让我们的 DevRel 团队成为这个非常新兴、非常困难、不断演进的领域里人们的思想领袖。

1:37:36 教育者、思想领袖、事物的解释者。这个角色还有另一个版本，我很喜欢，叫做“大师建造者”，就是我会用这个平台去构建东西，向你展示什么是可能的。然后你就会想，哦，我不知道 Claude 平台还能做到这个。然后你就去做了。这是从乐高偷来的点子。因为乐高是怎么卖乐高的？他们有大师建造者。他们用乐高搭东西，然后你就想，我也想这么做。我想成为这样的人。然后他们就去做了。不错。太棒了。是的。还有我们团队里的另一个人 CJ，他也非常出色，我觉得他也做了很多这类事情，比如写 cookbook、发布示例，并且在 X 上真正与社区互动。

1:38:16 Cookbook 挺有意思的，对吧？比如 2023 年 API 发布的时候，我们就姑且说是面向 LM 的，非常重要。现在，我不知道。是啊，这挺有意思的，因为你已经不太处于那种想直接复制粘贴代码然后拿来用的境地了，对吧？但我确实觉得，它向人们展示了什么是可能的。以及用例到底是什么，对吧？还有你该如何去实现它？但我明白你的意思，就是代码本身可能没那么重要了。比如我们很长一段时间都有这么个东西——我们团队里有一位工程师写了我们关于 computer use 的 cookbook，这事到现在还让他心有余悸，因为它极其复杂，你知道，算是个庞然大物，不过我觉得当时很多人从中受益

1:39:00 当你想的是，我要构建一个 computer use 实现，我要处理所有的截图和所有那些事情，对吧，那些在 messages API 之间发生的事情。是啊，我们就在你们办公室办的那场黑客松现场。对对。那时候你确实需要这类东西。而现在，你知道，更多是关于——我们有一个技能，比如 Cloud API 技能。它在帮助你，无论是在 Claude Code 还是任何其他编码智能体中，构建高质量的集成方面，真的非常非常出色。而现在这类事情，比如我要构建一个 computer use 集成，我该怎么做？我觉得，或者说希望，很少有人再去翻那本又大又复杂的 cookbook 了，更多是加载技能、编码智能体，然后干活。是啊，或者他们直接把它当作参考架构。是啊，实际上效果好得多。比如在很多事情上提升或者看到

1:39:45 你可能希望有不同的实现，通常是在 harness 层，但也可能有其他变体。你只需把 Cloud 指向它，然后说，这就是我想要的参考架构。对，然后你就去构建它。有趣的是，帮助 SQL 基于 API 构建的 Cloud API 技能，是由我们的 DevRel 团队负责的。所以那是 Lance 构建的。理应如此。对，完全正确。这是 DevRel 最高杠杆的形式，就是把所有最佳实践提炼出来，放进那些智能体里。对。原因之一，说来也怪，因为我被视为这个 DevRel 人物或权威。但我内心有一部分只想告诉你，你不需要 DevRel。你变得足够好，就不需要它了。对。或者你把工程师、领导者变成对外的公众面孔。

1:40:30 因为你真正想做的只是公众面孔，以及我们这里是怎么做事的。差不多就是这样。你是 Anthropic。你不需要人们来听说你。所以我觉得，对我来说，当 Boris 横空出世时，看起来非常像，嘿，我是 Boris，Claude Code 的创造者，等等等等。我们就是这么干事的。是的，他有本职工作，但他在功能上也在做这件事。那为什么不是每个人都这么做呢？对，我的意思是，这是个非常好的问题。而且有些团队做得非常好。我觉得 Cloudflare 团队就是个很好的例子。他们都在不停地输出东西。不停歇。对。而对我来说，这实际上是一个优秀管理者的非常明显的标志，就是他们都在自己的岗位上很开心。他们都在公开表明身份。他们没有辞职。对，完全对。这很有意思，因为我觉得

1:41:17 这其实正是我们试图与平台团队、我们自己的团队，以及那些能够真正走出去、成为社区一部分、发声、活跃在 X 上、出现在大家所在之处的人一起做得更多的事情，对吧？我认为对我们来说，问题就在于要有时间，并且知道如何以高质量的方式做这些事情。所以我在某种程度上把 DevRel 团队看作是在高质量完成这类事情上的专家。他们可以整天、每天都做这件事，而且他们可以帮助团队里的其他人思考，如何利用他们能花在这类事情上的少量时间，也把这件事做得高质量。是的。所以我把这称为 DevRel 的解绑，拆分成前台和后台。就像一个做这份工作的典型人物会做完整套流程。

1:42:02 从头到尾，他们基本上是自主的。但实际上，你可以建立起这样一个后台，让你的产品负责人和工程负责人真正站到聚光灯下，只需要一个简单的约定，比如，好，你和我坐下来 30 到 60 分钟，我们做一次头脑倾倒，然后你就完事了。你回去工作。然后我们会替你代笔，诸如此类。但那个由制作人员、写作人员等组成的团队，其实是在为其他人提供服务。而我认为，对我来说，老实说，这就是这件事的未来，因为人们其实并不真的想听 DevRel 说话，他们想听 Lance 说话，你懂的，你有很多 Tariq，你懂的，还有 Lydia，你通过 Bun 认识了 Lydia

1:42:45 你很清楚，但就像他，他做这份工作，他做这份工作，所以你想要更多这样的人，因为人们想听产品团队里的人说话，而不是那些像付费节目、付费代言人那样的人。我遇到过很多这种情况。那也没问题。那是一份工作。总得有人做。按理说，你可以预期做工程的人并不擅长这个。所以你应该付钱请专门做这个的人。专长是一种技能。我认为会出现一种后台与前台分离的模式。是的，那真的很酷。是的。我的类比是，每个人都会招聘，但你有一个人力资源部门。人力资源部门让你能够招聘。确实。你负责招聘。对。是的。这完全说得通。酷。这就是我的个人主张。

1:43:31 收尾问题。这段时间你非常慷慨。有什么临别想法或行动号召吗？Opus 5.5 上有什么很酷的东西？人们应该尝试用 Opus 5.5 突破什么边界？你们使用它的时间最长。是的。我是说，它真的很有成本效益。它没那么啰嗦。我们提到的所有东西，氛围真的非常非常好。一直很有趣。昨天对我们来说是非常有趣的一天，因为终于又……而且我收到了一大堆来自朋友和人们的短信，他们就说，了不起的模型。谢谢。比如我的一位老老板给我发消息说，Opus 5-5 刚刚在一次事故中救了我们的命。对。然后就像，好，太好了。就像我们回来了，这真的是我们感受到的能量。所以我认为，也许你之前想尝试某些东西，而成本是你最关心的问题之一。

1:44:18 对。还有 token 效率之类的问题，这些可能一直阻碍你真正放手让模型跑起来。我认为你现在应该带着 Opus 5.5 重新回到这类问题上，因为我觉得，相比那些成本效益较低的模型，你现在能取得的进展可能比原本能取得的要大得多。我觉得你应该试试多智能体（multi-agent）的配置。我想你会发现它非常好用。顺便问一下，还有其他提示吗？我是说，多智能体这个说法很宽泛。没有。我想我们会非常好奇大家会构建出什么。但没错，它应该会格外好用。对，包括比如说，那些并非严格定义、而是由它们自己相互分配的角色。对吧？在我看来，这才是新东西。

1:45:00 你可以分配角色。你一直都可以分配角色。你可以给 token 派活。但这次是，它们自己在给自己派活。是的。我想，再多讲讲多智能体吧，对吧？比如，我们应该使用子智能体（sub-agents）吗？你觉得……人们应该如何看待多智能体？从某种意义上说这相当不错，基本上，一般来说，你希望有一个主导者，然后你想把一堆不同的东西拆分开。只要你能有一个你认为大体上可以并行化的任务，而且它们在整个任务中共享统一的上下文，我想你就会获得很多收益。当然，这取决于你正在攻克的问题。但越来越明显的是，对我们来说，这是处理许多这类事情的一种非常优越的方式。尤其是如果每个子智能体，或者不管你怎么称呼这些子负责人，它们是异步的，彼此之间不会阻塞。

1:45:47 也就是说，在你的架构里，我认为你真正需要关心的就这两点。除此之外，就放手去干吧，看看 Claude 会为你设计出什么。而且我越来越觉得，很多这类架构上的事情都会朝这个方向发展。Claude 会越来越聪明。它会学会想办法把自己拆分、克隆自己、调整自身去适配合理的架构。你只需要防止它乱来。你只需要确保它能并行处理。所以它需要一个共享状态，而且它不能阻塞自己的子智能体。只要守住这两条原则，说实话，我觉得大家就应该去实验，甚至去尝试一些非常疯狂的东西。而且如果在此基础上出现一些非常有趣的东西，我一点也不会感到意外——也许他们原本觉得某个问题棘手得让人头疼，一直在死磕，结果这东西可能直接就能把它拿下，说不定一次就搞定了。太好了。

1:46:30 好了，各位，去构建吧。好，好。感谢阅读

保持稍微领先于时代。