Latent Space 深访 Anthropic 工程与产品负责人谈 Claude 发布机制

正如我们昨天从 Anthropic 的 S-1 备案文件中了解到的，该实验室拥有历史上最高的营收和研究效率之一，尤其是在过去一年中实现了从 -126% 亏损到 19% GAAP 利润的逆转。公司将此归功于其两大核心循环：改进与投资：

今天我们将深入了解 Anthropic 的运作方式。随着尘埃落定，Opus 5.5 已经发布一个月，并持续被公认为全球第一的 LLM，我们将深入探讨它的发布过程，以及 Anthropic 如何用 Claude 来打造 Claude——与工程和产品负责人 Katelyn Lesse 和 Angela Jiang 一同讨论。

团队正面临两种压力。模型能力越来越强，这使得安全部署和访问决策变得更加困难。与此同时，使用量增长之快，使得普通的基础设施选择——比如一个 API 消耗多少 CPU——也变成了战略性问题。这些问题最终都汇聚在面向开发者的那些产品选择上。

模型发布同时也是 API 发布

Anthropic 的 Opus 5.5 发布同时强调模型质量和成本。我们讨论了此前几代 Opus 被认为过于啰嗦的反馈，以及对每美元更强智能的需求。Anthropic 表示新模型的运行成本低于前代；确切的节省取决于工作负载及其对缓存上下文的使用情况。

不太显眼的发布工作涉及人们集成 API 方式的变化。我们讨论的一个例子是保护模型推理不被用于蒸馏的提取。跨轮次保留思考块有助于解决这个问题，但新的要求也可能破坏客户现有的框架。

Katelyn 还描述了参与早期访问计划在实践中究竟是什么样的：客户在自己的框架中运行评估，报告令人惊讶的行为，有时还会传递不太正式的印象。有用的部分不仅仅是基准分数：而是看到模型在 Anthropic 自身产品未涵盖的环境和任务中的表现。正如我们在播客中连续 4 年所说的，拥有好的评估是金科玉律。

大脑与双手

本集中我们最喜欢的思维模型是区分智能体的大脑和它的双手。在 Managed Agents 中，Anthropic 将会话日志和框架与执行代码的沙箱分离开来。框架可以持久存在，而执行环境在需要时创建；一个失败的沙箱不必带走整个智能体会话。

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

Claude Code 的下一个时代 — Thariq Shihipar, Anthropic — Latent Space

发布 Opus/Sonnet 5.5、Mods、插件、Projects、Tag，同时保持前沿节奏

Latent Space

同样的分离赋予了安全性一个有用的架构特性。如果生成的代码运行在一个从不接收服务凭证的沙箱中，那么沙箱中就没有可供代码读取的凭证。本集描述了单独保存并通过代理附加的凭证，以及对沙箱流量去向的控制。Anthropic 的隔离说明描述了其产品中使用的更广泛的隔离和网络控制措施。

这种区分对性能同样重要。两位嘉宾表示，早期的做法是把整个编码智能体放在一个位于 API 之后的沙箱里。启动环境和智能体在首个响应之前就增加了额外开销；如果沙箱消失，运行中的智能体也会随之消失。将各个组件分离之后，平台得以在保持执行隔离的同时，追求更低的延迟和更好的可靠性。

对于任何设计智能体运行时的人来说，这都是一个有用的视角。要问清楚：哪些部分需要存活下来，哪些部分执行不可信的工作，以及哪些机密信息确实需要出现在代码运行的地方。具体实现会因产品而异，但这些问题始终有价值。

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

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

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

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

节目笔记

Claude Opus 5.5 发布公告 — Anthropic 关于模型行为、评估和定价的发布说明。
Katelyn Lesse 和 Angela Jiang 在 Anthropic 合作伙伴峰会上 — Anthropic 说明了她们在平台工程和产品方面的职务。
Scaling Managed Agents: Decoupling the brain from the hands — 本期节目中讨论的会话、harness 和沙箱架构。
How Anthropic contains Claude across products — Anthropic 描述其各产品中隔离、凭证和网络控制的方式。
Effective harnesses for long-running agents — 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 记忆、梦境与智能体框架

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 大家好，今天我们要尝试一些新东西。我们正在为 IPO 推出对 Anthropic 的系列报道。他们就在今天提交了 S1 文件。因此我们将在 IPO 之前发布一系列播客，IPO 预计在两周后进行，估值 2 万亿美元。它是史上增长最快的公司之一，据报道累计融资超过 1000 亿美元，累计消耗不到 100 亿美元。所以这里有很多效率方面的故事值得深入探讨，我认为这也是我们想要报道的内容——Anthropic 如何在推出全球最强模型的同时，又以非常非常高效的方式做到这一点，并建立起一家令人难以置信的公司。所以我要先说一下，如果你一直在听这个播客，你会知道我曾经做过金融分析师。

0:50 我从 S1 文件中摘录了一些内容，我认为它们能为今天的播客提供有趣的背景。我们只是把这当作一次新的尝试，因为我觉得你们中有些人希望与我们建立这种个人关系，直接对着镜头和你们交流，而不是像我们四年来一直做的那样与嘉宾对话。所以我想强调的第一点是，按员工人数计算，Anthropic 是一家效率极高的公司。这也许显而易见，因为它是一家 AI 公司，显然他们把 AI 运用得非常好，但我认为他们在过去一年中作为一家公司所发生的变化程度，并没有被充分理解。所以按过去 12 个月收入计算，每名员工的收入现在是

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

2:27 今年对 Anthropic 来说是执行到位的关键一年，而它确实做到了。我认为我们将从播客的外部视角深入探讨并尽可能讲述这个故事。嗯，这一整体增长的一个结果是，Anthropic 刚刚公布了其首个盈利季度，不是经调整利润（即扣除所有成本后的利润），不，这是按照公认会计准则（GAAP）计算的利润，为 19，这非常巨大，再次与一年前完全反转，不仅仅是反转，就像一

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

3:45 从而导致更好的 Claude。所以这两个循环基本上一起旋转，形成一个无限循环，根据 Anthropic 的 S1 文件，它将一直推动效率的提升直到永远。所以我认为这是我们从整体效率故事过渡到他们如何执行的部分。今天我们将重点关注 Claude 平台，因为这主要是 Anthropic S1 中所称的 Claude 扩散的三件事之一。他们将 Claude 平台称为我们全面的智能体开发环境。他们为客户提供对其原语的直接访问，以在其自身产品和工作流中构建、部署、扩展利用 Claude 能力的自有应用，

4:30 我认为在这个播客的讨论中经常出现的一个概念是“吃自己的狗粮”，即 Claude 的许多产品实际上就是用提供给你的同一个 Claude 平台构建的。所以 Claude 平台披露的另一个有趣之处是，超过 50% 的年收入达到或超过 100,000 美元的客户在按交易电话基础（trading telephone basis）上使用 Claude 平台。因此，这标志着采用率的提升和 Anthropic 的崛起，它不仅是一个模型实验室，还是一个超大规模云服务商和 Claude 平台，我认为这也许在 Claude 平台和 Claude 平台的名称中就已隐含，但正在从理论走向实际实践。

5:15 这也是我们在播客中重点关注的内容。另一件我非常想强调的事情，我之前也提到过，就是 Claude Code、Claude Cowork，它们都使用 Claude Platform 暴露的相同原语。所以我认为这非常有趣。归根结底，Anthropic 似乎正在为其 IPO 定位，讲述从聊天机器人到副驾驶再到虚拟协作者的演进。他们使用这个术语而不是 agents。也许这样听起来更友好。但这很大程度上与你对智能体的期望是一样的，从长时间运行的自主工作到判断力、自我纠正、迭代和工具访问。所以是拥有一个目标并与你并肩工作，而不是在单个应用或任务内部工作。这就是我想为今天的播客提供的背景。

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

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

6:45 对。而你只能在你的环境内做你能做的事。而智能体基本上被激励去尝试逃出它的盒子去解决问题。当人们在我们的 API 或任何其他人的 API 上运行生产工作负载时，你运行的环境中有一些安全措施在运行，这些措施在训练中不一定会运行，因为训练的重点实际上是训练模型。对吧。但在生产工作负载中，首先，你有那些在线安全措施，这真的很好。其次，你有更多的架构和基础设施围绕正在发生的事情。就像智能体不只是在一个盒子里试图逃出来。对吧。就像 harness 在这边，hands 在那边。这根本不是你需要考虑的问题。

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

8:17 我认为人们越来越看重每美元能获得多少智能。所以确保我们在每美元这部分做对真的非常重要。边缘上还有一些事情其实并不太相关，比如，你知道的，也许是我们博客文章里没谈到的内容，那就是我们确实在努力让我们的 API 更难被蒸馏。因此我们做了一些改动，让这一点更加具体。具体。这些事情涉及，你知道的，比如我们如何做前缀锁定思考，或者你如何在不同类型的模型之间重放思考 token。我们这边也投入了大量工作和努力，确保我们针对非常合理的用例进行调整——比如你可能想在压缩策略之类的地方这样做——而不是在该用例实际上来自恶意行为者的场景中，

9:05 实际上。所以在这些方面一直需要非常小心地拿捏分寸。我很高兴看到其中很多都发布了，除了发布一个每美元智能表现出色的模型之外，还有就是沟通得更清楚一些。是的。具体来说，你说的是这篇论文，《从专有模型中窃取推理轨迹》。是的，那篇论文。就目前而言是真的，对吧？我的意思是，显然他们对你们做了负责任的披露。他们做了非常负责任的披露，我们非常感谢他们来找我们。能不能为那些没听说过的人讲讲，这真的很酷。你可以做到。我的意思是，它已经被修复了，但那是什么？它在 Anthropic 内部引起了恐慌吗？可能没那么严重。我不知道。我不知道这篇论文具体引起了多大的恐慌，因为这是

9:48 我们已知的一个漏洞。是的，所以有两件独立的事情。一件是中国模型的蒸馏。是的。然后这是一种被发表的、备受关注的技术。是的，没错。我们早就知道思维链提取是蒸馏模型最强大的方式之一。实际上，比如我们如何跨轮次保留思考块并使其成为更必需的东西，是我们已经探索了一段时间的方向。而我们当时的情况是，我们始终面临一个非常非常艰难的权衡，那就是用户体验——比如可能对 API 用户造成痛苦的用户体验变化——与防止蒸馏之间的权衡。

10:32 那么我们如何把握这条界限，说我们正在防止蒸馏呢？也许先退一步说。我们不希望被蒸馏的原因是，Anthropic 存在的全部意义就在于我们希望 AI 能安全地在世界上创造积极的成果。我们在生成的 token 上运行大量的安全分类器，以确保它们是安全的。如果有人蒸馏了我们的模型，并且在没有安全分类器的情况下运行这些模型，世界上可能会出现糟糕的结果。这是我们不希望发生的事情。所以我们不希望人们蒸馏模型，特别是为了将它们用于恶意目的或不良目的。所以这始终是一个有趣的权衡，对于所有将模型用于善途的人，对吧？

11:16 我们并不想让开发者更难从模型中提取智能，但为了防止这种蒸馏，我们必须做出一些权衡。所以我们一直在研究如何防止这种思维链提取。比如，我们该如何以一种不会给用户带来太大痛苦的方式来保留思考块？我们大致从两个层面来考虑用户体验上的影响。第一层是，你必须做出集成上的改动，这很烦人，但你仍然可以完成原本能完成的所有事情，只是有点烦人而已。第二层是，实际上你无法再完成之前能完成的事情了。这是我们真的、真的、真的想要避免发生的情况。所以在最近几个模型中，我们最终采取的方案是做一些增量改动，以在多轮对话中强制保留这些思考块。

12:04 现在开始更多地涉及跨账号的情况，比如如果你使用多个账号之类的，对吧？我们如何确保你无法利用这种思维链提取来对付模型？为此我们发布了一些额外的功能。我们实际上与许多开源 harness 的维护者进行了合作。我们主动联系了他们，和他们沟通。我们说，你们需要在自己的 harness 中进行这些升级。我们希望确保你们有良好的体验，当然也包括那些在 API 之上构建 harness 的大客户。对其中一些客户来说，一个很好的例子是，他们原本的压缩策略会因为需要保留这些思考块而失效。所以我们在 API 中发布了一个新的压缩功能，来替代他们原本

12:49 手动执行的方案，同时仍然能与保留的思考配合工作。这只是一个例子，说明我们正在走这条平衡之路，但我们并没有简单粗暴地直接说，现在你们必须以这种特定方式保留这些思考块，因为那样会破坏很多人的工作。我们花时间与客户和开源 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 的下线。我认为我们中没有人会猜到那会成为一个有效的用例。由政府出面，那位女士就不得不去执行。但显然概率不为零。因此从这种思维方式出发，从产品管理的角度来看，它已经变得非常概率化了，比如，我们应该优先考虑这个吗？它发生的概率是多少？

25:32 再次发生？当我们看到这样的事情时，我们会想，好吧，如果我们去想象最疯狂的一系列可能性，我们实际上可能对事情会走向何方几乎没有任何确定性。所以我们实际上只是需要对冲，并构建一个投资组合式的押注。所以很多时候，我们会采取对冲的情景，比如，好吧，我们认为它不会再次发生。但如果真的发生了，我们实际上会希望有这种对冲，或者有能力很好地做到这一点。所以我们会优先考虑这样的事情。然后我们越来越多地发现，通过采取这种产品开发策略，大多数时候我们实际上发现自己会说，我们确实会用到这个东西。还有没有另一个单独的例子，好让我理解一下？比如这个访问计划。

26:15 这个 X-Factor 是一个很好的例子。在内部，它有一堆授权和所有这类东西。我们开发它 specifically 是为了能够……真正地把这样的计划提供给客户，非常非常具体。你想不想从宏观层面介绍一下这个访问计划具体是什么？当然。所以如果你想要双重用途，如果你想要，那么对于，我们拿一个模型来说。你拿一个模型，比如叫 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 发起了请求，这个请求在底层会访问某些数据，而我们要确保你访问的是你自己的数据。对。就是非常非常普通的授权。这就像我们建立了一个数据模型，非常清晰，比如 trust grants 意味着你被授予了访问某个特定模型的权限，或者你被授予了访问某个特定项目的权限，或者，你知道的，有很多不同的排列组合。我们实际上发现自己一直在使用它。另一个很好的例子是当我们

29:17 首次为 Fable 5.1 推出这些保留思维功能时，我们对一些人做了祖父式处理，给了一点，你知道的，就像一段时间。宽限期。对，宽限期去进行集成更改。作为祖父式处理的一部分，我们说，好的，我们必须追踪谁是需要额外时间的现有客户，对吧？然后我们就做了一个 trust grant。这样我们就能说，对于任何事情，我们只是在运行一个处于我们请求热路径上的服务，以确保，你知道，我们只是流经并检查你是否拥有你想要做的事情的授权，这其实和普通授权真的没什么不同。但是，我们只是不得不搭建一个

30:02 专门针对我们系统的系统，以及我们需要在哪些地方插入这些检查。对，我觉得这些都是人们习以为常、不太会去想的工程问题。那么，还有哪些平台方面必须做的事情的例子呢，比如服务 Claude Code，或者服务，显然我和 Cognition 聊得很多，但其他客户，就模型发布而言，对吧？我们会更多地谈到正在进行的安全工作。我只是想从宏观层面来谈，因为这还记忆犹新，一次模型发布都包含哪些内容？如今这已经有点像一台机器了，除了安全部分，我认为那是更复杂的部分。但在这些部分之外，有很多工作是从我们的客户那里获取反馈。所以，你知道，我们制作模型，

30:50 有大量的安全测试。我们还会评估我们认为它应该达到的水平。我们会根据需要做出必要的权衡和决策。然后我们必须进行测试。我们会切出模型的各个不同版本。我们会对它进行评估。我们会做大量的内部“ant fooding”（蚂蚁觅食式测试），我们是这么叫它的。这实际上总是非常有帮助。比如，我们能非常早地发现一些问题，比如，哦，这个可能不是最好的。我们内部显然也大量使用 Claude 来开展工作。所以我们实际上能够看到早期信号。这有助于我们判断哪些变体可能比其他变体更好。然后当我们对某一组变体非常有信心时，我们会为客户切出一个版本。有时这会通过我们的第一方产品发布，比如通过 Claude Code 或 CodeWork 之类的。

31:30 在其他情况下，它会通过我们的 API 客户发布。我们会与这些客户开展一种早期访问计划。他们需要在自己的测试框架中做出改动。我们已经与许多客户合作过，比如 Cognition、Cursor 这些公司。我们有一套流程来处理这件事，以便我们都能获得、他们都能获得我们需要的反馈。它在你的评测中表现好吗？你喜欢它吗？不喜欢吗？有些东西是凭感觉的，我们也想听听那些反馈。有些东西就是纯粹的评测，比如它在你关心的事情上表现得好不好？我们会把所有这些综合起来考虑。一旦我们对所有这些不同的环节都感到满意，我们就会发布模型。目前模型反馈的状态感觉仍然非常缺乏结构化。基本上，总是公司之间的一个 Slack 频道，比如，嘿，这东西好像有点奇怪。然后人们就说，好吧，我想我会修一下。

32:16 给我一个 ID 或者什么的。是的，非常，我的意思是，这就是非确定性产品的本质，对吧？但我想就你所说的而言，真正参与我们早期访问计划的客户，是那些拥有非常完善的评测体系的客户。我确实认为这其中很多是基于感觉的，而且我认为很多对话往往也是凭感觉、即兴进行的。部分原因是因为我们在，怎么说呢，赛跑，对吧？就是说，我们希望尽可能缩短我们切出一个用于测试的模型版本到我们让所有人都能使用这个模型之间的窗口期。所以这就是一个非常紧凑的窗口期。但我们倾向于与之合作的客户，是那些我们知道他们会去跑完整的评测套件，并能带回给我们真正可操作的反馈的客户。

33:01 尽可能快地推进，同时兼顾主观感受、基于感受的反馈。当然，我们确实可以采取一些流程上的措施来让这些事情随着时间变得更好。但是，说真的，你会感到惊讶——嗯，你可能不会惊讶，但我觉得有些人会惊讶于世界上现存的、具备 agentic 能力的产品中，有多少没有良好的 eval 来帮助测试这些模型。两年前 Boris 上我们的播客时说我们没有……我的意思是，情况已经变了。那已经变了。那已经变了。但是，你知道的，是的，很多事情就像，你知道的，你的 eval 就是你的用户，而你没有时间把它们形式化，或者你没有相关经验，或者诸如此类。这没关系。到了某个时候，当你认真起来，你就会有 eval 了。

33:49 是的。是的。客户的 API 尤其非常有用，因为他们会把 Claude 放进一个不同的 harness 里。而我们希望 Claude 非常非常通用。所以它在其他 harness 中工作的能力对我们来说相当重要。因此那种风格的反馈对我们来说往往格外有用，因为它与我们从 dogfooding 中获得的反馈是不同的。什么样的反馈有帮助？是回归问题吗？我们这里出现了回归。我们在这里注意到了好的特质。好的反馈总是非常令人振奋的。我觉得我们经常不是感到意外，而是喜欢看到我们的一些假设得到验证。老实说，最有用的反馈是负面的。比如，你知道的，它在这方面做得不好。在那方面做得不好。我们非常喜欢那种反馈。然后我们就会说，太好了，我们该怎么修复它？

34:31 是的，而且往往就是这些事情，这真的很难，因为并不是每个人都希望 Claude 在每个维度上都落在完全相同的位置。也许一个很好的例子是，你知道的，懒惰与主动采取行动之间的平衡。有时候我们有一个模型，人们会说，快把我的任务完成。别再懒了。做得更好点。而另一些时候则是，嘿，我们只是在摸索和规划。然后你却跑去写了一大堆代码，或者你采取了一大堆我还没准备好应对的行动。要把这个把握得恰到好处简直是不可能的，因为实际上每个人想要的都不一样。但我确实认为我们遇到过这样的情况：我们发布了一个早期版本的模型，发现我们看到了太多的懒惰。对。

35:15 于是我们又把它放回烤箱里烤了一会儿，对吧，试图把这种行为重新训练掉。这些正是如果我们只在自家产品和 API 内部进行自我测试（antfooding）就可能发现不了的问题。对我们来说，把它放到 API 上、让所有其他客户用起来、并让他们告诉我们需要改进什么，要重要得多、重要得多。是的，这是一个核心问题。我想如果我处在你的位置，这大概是为模型做产品管理最难的事情之一，也就是所谓的对齐（alignment）与个性化（personalization）之间的关系。你希望所有使用者都能获得一个默认的性格、默认的行为。然后你又希望能够非常快速地响应某人的 CLAUDE.md，比如：不不不，请比默认情况更主动一些。

36:01 而且，据我所知，我当时参与了 Frontier Code 的工作。我们参与了 Fable 的发布，这让 Frontier Code 声名鹊起。而现在 Opus 5.5 又回到了模型基准测试中。这是 Frontier Code 很重要的一部分，对吧？Frontier Code 的模型曲线看起来很奇怪，是因为它会对过多的活动或过多的文件进行惩罚，这是好事。这本来就是 Frontier Code 的设计目的。但我完全可以就在我的 CLAUDE.md 里说：别那样做。然后它就不会那样做了。那么，因为我的基准测试没有包含这种主观的个性化元素，我是不是对 Claude Opus 5.5 不公平呢？所以我不知道问题到底是什么，但你们如何处理个性化？显然，一个模型可以做非常多

36:51 不同的事情，而且这非常因人而异，每个人都有自己的 CloudMD，你们如何演进这一点？我们在这方面做得并不好。说真的，这真的很难。超级难，而且两者是相互竞争、相互冲突的。我记得有一个 Claude 宪法，我想。那是旧的了。确实有一个宪法，但我会让你们来回答。宪法是有帮助的，但对于这类问题，比如如何针对不同的指令以及在这些场景中差异极大的偏好进行个性化，对我们来说非常困难。我们通常尝试通过提供更多参数来解决这个问题，从而让我们能够针对

37:32 不同的客户群体进行调整。如果我们无法控制你的客户群体，而你是一个 API 客户，那么我们会尝试给你提供建议，然后由你来进行调整。所以有些东西，比如，你知道的，在……它和针对各种 cloud.mds 或者现在的 agents.mds 之类的个性化并不完全在同一层面上。但我们确实会尝试在诸如努力程度（level of effort）这样的层面提供一些东西，比如你应该投入多少努力，比如你可能实际需要关注的模型规模大小，诸如此类。但我认为，对于我们实现那种个性化水平所需要的东西来说，它还不够到位。所以这是一个非常困难的问题。而现在我们解决这个问题的很多方法，除了提供多个参数之外，就是尝试展现出相互冲突的品味，说实话，

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

39:00 是的，他们只是……而且这个东西会变化。这个东西确实……这是一个我们用来进行个性化的参数的完美例子。我想说这可能是一个有点过于激进的术语，但我们可能会为不同的子细分市场进行定制。所以，默认设置会根据你是免费客户还是 prosumer 客户，或者 Claude Code 与 Cowork 与 Enterprise，或者 API 之类的进行调整。当然你知道你总是可以调整它，但这些是我们尝试提供这种功能的轻量方式。我们犹豫要做的一件事是，我们不希望人们觉得他们无法控制对 Cloud 的定制。例如，我们可以在这些事情上采取更强硬的手段，但我们希望给用户能力去按照他们认为合适的方式体验 Cloud 的智能水平，特别是如果你想要走向高端，或者你想要在低端进行实验，如果那实际上对你的用例来说更快的话，我认为这是一个艰难的产品权衡。

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

40:31 关于 API。而且就像，怎么可能有人能弄清楚对于任何给定任务来说，正确的参数组合到底是什么？而这个，我们基本上就是边走边摸索，和客户一起摸索，弄清楚哪些参数应该随着时间推移而弃用？哪些参数我们应该直接设置更好的默认值？哪些参数应该用一到一百的刻度，而不是低、中、高的刻度，对吧？因为实际上，我们已经训练 Claude 让它非常擅长理解这类东西上的整个选项范围。但是，我们要不要把那数百万、数十亿种选项组合全都暴露出来？那样你其实走不了多远。而这实际上就是像 Claude Managed Agent 这样的东西的价值主张之一，它仍然是通过 API 对 Claude 的编程式访问。

41:19 但你开箱即用地获得了一个运行框架，我们每次发布模型时，都会做大量工作去弄清楚，新的参数是什么？有哪些破坏性变更？如何在我们的框架内从 Claude 获得最佳效果？这样对于使用它的人来说，你开箱即用就能得到这些。你不需要去思考它。只是对于那些被它吸引的人来说，而且这是一个庞大且不断增长的群体，特别是我们实际上在 AIE 办了一整场 CMA 研讨会，我觉得办得非常好。有没有一个单独的订阅源让人们订阅，比如，关于 CMA 的更新？订阅源，就像……就像一个 Twitter 信息流、新闻通讯，我不知道。不，我觉得实际上我们的 Cloud Devs 频道，我们，是的，我们对此相当高调，因为这对人们来说是一个有趣的选择。

42:02 是的，我只是想告诉大家，如果那是你使用 Cloud 的方式，这就是路径。我觉得它也被大大低估了。对于那些没有以这种方式使用 Cloud 的人来说，什么是 Claude Managed Agents？人们为什么要使用它？哦，对。我们可能应该做一个小介绍。我不知道。那是谁家的房子。对。一个两句话的小介绍。我觉得很多人在它发布时都一扫而过了，对吧？每个人都处于这样一个阶段，我需要做框架工程。我需要控制这个。你听到了所有这些。而现在的问题是，你真的需要做所有这些吗？还是你直接使用托管代理，就可以跳过很多设置工作？但快速介绍一下要点。是的。这取决于你的用例。所以 Claude Managed Agents 是我们今天的 API。

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

43:32 一个很好的例子是，我们团队运营的沙箱集群既支撑着 Claude Managed Agents，也支撑着 Cloud Tag 等产品。但在这些产品的实际 harness 层面，我们在 harness 内部想做的事情存在差异，所以它们并不共享同一个 harness，而是共享大量支撑执行和支撑 API 的基础设施。我觉得这一点真的……人们应该更多地使用它。我认为基本上每个人在你们推出之后都做了 Managed Agents 的仿制品，模仿是最真诚的奉承。既然说到这个话题，我们简要提一下最近所有关于记忆的工作。我觉得这是 Anthropic 上半年工作的重要组成部分。它停滞了吗？还是仍在进行？现在这里的重点是什么？

44:20 特别是 Managed Agents。记忆、做梦。哦，这确实是我们工作的重要组成部分。我觉得思考它的方式可能是：我们推出 Managed Agents 作为一个平台，是为那些不想自己完成所有这些事情的人，对吧？或者只是想把工作卸载出去，比如我从 Claude 中获得了最好的效果，因为我们的团队就坐在这里对所有这些东西进行评估，并确保 harness 会非常强大。记忆和做梦完全就是关于如何确保你的智能体能够随着时间不断改进？所有这些仍然是我们团队的重要关注点。但我想说的是，正如我们之前谈到的，随着从安全角度来看发布模型变得越来越难，我认为我们团队的大部分精力越来越少地投入到，

45:04 比如，这是一个有趣的功能，可以在这个智能体上做 hill climbing 之类的，而是更多地投入到如何将安全性带入所有这些事情中？因为我们能做的最重要的事情就是把模型的能力推出去，并且安全地推出去。所以我想说，我们很多精力都花在把这些相同的概念结合起来，给你一个既非常强大又非常安全的智能体系统上。这就是我们投入精力的地方。我认为与今年早些时候相比，我们在 skills、做梦、记忆这类时间点注入方面放慢了节奏。请热爱 skills。不不不，我们热爱 skills。我们热爱 skills。我们正在更新。我不是说我们什么都没做，但我们也同样热爱 skills。不过是的，我认为与其他一些努力相比，我们确实放慢了一点速度。

45:48 但我们非常看好人们在 harness 层面进行某种程度的 hill climbing，就像前面对话中提到的那样。我们自己也做了很多这样的工作，但我们提供的 harness 在某种意义上非常简单。它是刻意简单的。我们不想过于主观地规定做法。我们希望确保最佳实践能够被合并进来，并且最难的 agentic 循环中有一些无差别的部分，确实很难串联起来。而且，你基本上可以直接用样板代码实现它。不过，在此之上有趣的部分是，一旦你得到了那个基础层，就有一些我们构建的 hill climbing 策略。而做梦实际上就是其中之一。所以做梦……在底层是一个多智能体系统，我们在 CMA 之上对它进行了 hill climbing，它实际上是一个

46:30 基本上就是 CMA 叠在 CMA 之上。CMA 叠在 CMA 之上。它会再启动一个，对。Dreaming 的工作方式是，我们启动另一个托管代理，然后该代理可以调用之前的托管代理，并向那个托管代理写入记忆。所以一路都是托管代理。这在一定程度上是刻意设计的，因为我们设想你或许可以把许多这样的模块化组件组合起来做些有意思的事情。而 Dreaming 只是我们追求的更有趣的事情之一的一个示例。但我们其实一直在看，实际上还有很多其他事情可以做。你可以做 N 选优（best of N）这类多代理策略。你可以做一个验证代理，负责目标或结果那类事情。里面还有很多其他东西。我们也见过人们做出一些相当古怪、疯狂的事情。比如有一个运行框架会在所有东西之间共享疯狂的记忆。然后他们会启动大量并行代理。

47:16 于是我们觉得，我们其实应该直接支持你这样做。就像我们构建 Dreaming 的方式一样。那是一路都是托管代理。我们很快会发布一次更新，更新底层原语。我们会把它暴露出来，让用户能够构建运行框架策略，或者随你怎么称呼这些东西。比如多代理策略。多代理策略让你能够构建自己的版本。我们会给你提供模板，比如这是我们开始做 Dreaming 的方式。也许作为开发者，你会想在此基础上做些更新，从而获得更大的价值。是的，我觉得这是一个非常好的框架。与其说我们在这类事情上放慢了脚步，不如说我们的原语已经就位。我们可以继续让人们直接拿去使用这些东西，同时给他们提供工具，告诉他们：这里有一些很酷的多代理策略，以及我们放进 Cloud Managed Agents 中、使其变得非常强大的东西。

48:05 现在你可以让 Claude 来利用这些原语做工作，让它变得更强大，比如创建新的多代理策略以及任何可能的东西。与此同时，我们团队的大量注意力转向了：好的，社区，放手去做吧，对吧？你们做你们的，而我们继续专注于我们需要做的所有事情，以确保你能安全地使用该系统内的模型。你提到过你在这方面跑了很多评测。现在这是个相当热门的话题。有什么建议或最佳实践吗？专门针对评测？针对运行框架和代理的评测。评测有很多种类型，对吧？并非所有评测都是等同的，这取决于你所处的不同情境以及你想要测试的内容。

48:49 你显然有静态确定性的东西，然后你有 LLM 作为评判者。你有所有这些不同的策略。但我想说的是，我们从大多数人身上发现的是，你可能需要更多而不是更少。就是说，不存在一套完美的评估组合，能让你获得改进系统所需的所有答案。我们发现人们最终需要相对大量的这类东西，然后你可以让你的代理与你一起随着时间的推移不断演进你的评估套件。但我认为，在这方面投入不足可能是我们看到人们犯的最大错误。是的。而且它可以从简单开始。

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

50:15 你是在构建框架、产品，无论它是什么。但你像做研究一样对待它。你提前定义你的目标是什么，尝试将其形式化为一个评估，然后试图找出，好吧，它为什么失败了？有时候你的评估是错的。实际上，很多时候你的评估是错的。有时候你的环境是错的，然后有时候模型是错的。而这实际上是我认为 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 这真的很有趣。你无法获得足够的 VM。你无法获得——没有沙箱。这主要就是所有东西都能够启动、启动。用你拥有的所有资源。是的。真的吗？你们也有很多客户。是的，这很疯狂。是的，想想看，因为我们使用 CPU 跨越，显然，就像运行我们的产品服务、运行 API、运行我们所有的应用。我们在沙箱方面使用 CPU，我们所做的所有沙箱处理。然后就像所有像 CI 这样的事情，你知道，你会惊讶于有多少代码正在被编写。因此，有更多得多的 CI 运行。因此，你需要更多 CPU 来处理这些。等等，总的来说，这不仅仅是我们，这是我交谈过的每个人。我会加上训练。训练可能使用的是沙箱。所以那是另一个不同的类别，对吧？我确定他们不会混用太多。嗯，他们不混用，尽管对 Anthropic 整体来说 CPU 就像是一个零和博弈。

54:50 你知道，比如我们和云服务提供商（CSP）谈判达成合作，拿到我们的 CPU 配额，然后必须在 Anthropic 内部进行分配——分配到我刚才提到的所有事情上，包括研究沙箱和产品沙箱等。所以我们确实是在对所有事情进行分配。而现在整个行业的现状就是……什么都缺。是啊，过去只要你预算允许，你可以随时按需扩容 CPU 能力，对吧？而现在这变成了你必须提前做容量规划的事情，这简直是在打所有人的脸。

55:30 这是全新的事物，人们才刚刚开始做。应对这种情况意味着几件事。首先显然是去争取更多 CPU。酷，我们正在尽最大努力做这件事。其次，我们希望在基础设施层面上运行得更高效，对吧？比如想办法确保我们尽可能高效地运行沙箱，同时不牺牲租户隔离等我们关心的安全特性。然后在应用层面上，我们如何更高效地运行我们的应用和 API？这是我最兴奋的事情。上周，我们完全上线了用 Rust 编写的 Messages API，这是在 agentic coding 时代才能实现的惊人壮举之一，过去这

56:18 就像我们今年早些时候就开始讨论这件事。我们说，我们会撞上 CPU 墙。有些事情我们需要做。而我们做到了，对吧？我们实现了多区域部署，完成了所有需要做的事情。但我们当时运行的是一个 Python 单体应用，CPU 效率非常低。那么我们要怎么让系统更高效呢？是的。所以我们选择了 Rust，这在当时是个疯狂的决定，因为我们的团队里……从纸面上看这很明显，但我们的团队里连一个 Rust 开发者都没有。确实。字面意义上一个都没有。而且不仅如此，是的，Claude 会来写代码。人类负责设计系统，对吧？

57:01 所以人类深度参与其中，确保最终这是一套分布式系统架构，对吧？Claude 既能帮助你实际编写代码，也能帮助工程师们碰撞想法、学习设计该系统所需的知识。但最有意思的是，最重要的两件事是做这件事的计划，以及对这件事的验证。因为实际的实现就像让 Claude 写代码。所以我们最终做的事情是，我们 literally 用 Rust 构建了整个 API 的完整分支，然后开始通过影子流量运行它，验证我们从 Python 系统和 Rust 系统得到的输出是否一致。这就像 feature flags 就够了。确实。负载均衡 feature flags。

57:45 就是说，我不知道。在我的职业生涯中，我从来没见过一个团队会说：好啊，好啊，太酷了。你们还有 Rust 的人，还是没有 Rust 的人？嗯，他们现在大概会自称 Rust 人了。我是说，Rust 有两大步要走。对，没错。在此过程中，我们招了几个对 Rust 更有经验的人。但是，是的，这仍然就像你从来不会主动报名去做这件事。那会花上好几年好几年。你不会一次性全部搞定。你会把系统拆成一块一块，说：迁移这个，迁移那个，迁移那个。这轻松就是一个持续数年的工程。但你绝不会一口气，对吧，把整个东西全部移植过来，然后慢慢把它上线。但这正是我们最终所做的。而且它奏效了。所以我们不仅确实节省了大量 CPU，延迟也有了不错的提升，这也相当酷。

58:37 而且，你知道，我们生活在一个疯狂的世界里，因为你以前根本不可能做到这种事。在 CPU 方面有一个数量级的节省。只是说给正在考虑这么做的人听。对，对。好吧，一个数量级，这非常有意思。大概估算，对。对，大概估算。我想我会说，我们看到大概 40% 到 50% 的提升，非常惊人。然后是延迟，我想我们在首字词时间上看到了大概 10% 到 20% 的提升。所以各方面都有很多非常酷的改进。在运行时间更长的工作负载上提升更高，所以它很快就会推出。

59:16 是的。但它会变得更快。你会克制这种冲动吗？你知道，我参与过一些大型重写。总会有人想：如果我们加上这个以前在旧系统里不存在的新东西会怎样？反正我们都要重写了，对吧？对。但那会增加范围。对，对。所以你们就是避免了这些？这是一次纯粹的重写吗？我们确实做了。这是一次纯粹的……也许我会称之为一次移植。我们所做的正是如此。我们在所有这些事情上都克制住了冲动。然后，因为团队本来要应对的事情就不少，我们组建了一个专门的小团队来做这件事，而他们做这件事的时候，我们团队的其他所有人都在为 API 构建功能，对吧？他们处理了所有那些静态分析的东西，那些东西会冲你大喊大叫，因为你在这里构建了一个功能，却没有在那边考虑 Rust，对吧？他们处理了所有这些，但他们克制住了自己添加功能或改变系统的冲动。

1:00:05 现在他们的下一个目标是去做某种重新架构类型的工作，包括一些我认为会更面向用户的东西。比如我们开始推出一些这样的东西：如果我们能让你不必来回传递整个对话状态会怎样？对吧？如果你在 Messages API 上不必这样做，因为你愿意让这些状态被存储一段时间，对吧，那么，尤其是对于上下文不断累积的长对话，你也能获得非常好的延迟和效率提升。这些正是当时做移植的那个团队会想：哦，如果我们这样做会怎样，对吧？

1:00:45 你们的缓存 API 没有这个功能吗？我们有提示缓存，是的。但你仍然需要把对话状态传回去。好吧。非常非常小众、很小的子集。但我想这就是这个层次的水平。不，这很重要。对对对。这里面能省下很多，但也会把它们变成一朵云。对，从用户数量的角度来看是小，但如果你看这些工作负载上实际的 token 量，那会是占大多数的。我非常觉得，Cloudflare 用 Durable Objects 做的事情，我觉得每个云厂商都应该抄一份。你懂我意思吗？懂。对吧？这不就是需要续接的消息 API 的正确形态吗？是的，这确实非常有趣。因为我觉得我们正在尝试各种各样的东西，比如我们应该以怎样的正确形态来运行我们的算力，以支撑所有这类事情。

1:01:31 但同样有趣的是，我们不一定能依赖于……因为我们的算力是跨平台的，我们在三大云上都跑，到处都在跑。我们不一定有这样一种统一的形态，说我们确切知道会跑在什么样的算力、什么样的机器上，以及某种特定算力的工作方式是我们可以全面依赖的——如果我说明白了的话——除了这些东西最普通、最基础的版本之外。但我认为所有这些东西都会，我不知道，随着时间的推移不断创新和演进。这样我们就能更多地利用它们。是的。我只想提一下，如果有人想要开源的 Cloudflare Durable Objects，Rivet 就是开源的对应物。有 50 个听众，如果我不问这个问题他们会杀了我。你们要 CPU，他们有 CPU 卖。我该卖给谁？我该发邮件给谁？

1:02:16 那么一个好的……帮他们帮你，对吧？是什么样的？嗯，我想，给我发邮件吧。你确定吗？我不知道。我会收到很多邮件的。但是，你在找的是，比如，最小集群规模、SOC 2，当然，企业级。对对。给我所有的隐私保障。不管怎样，我们有一个非常棒的团队来保障我们的加速器算力安全。是的。他们现在花更多时间和我们一起研究 CPU，以及我们可以在哪里、以什么方式采购它。以确保我们能够继续以所需的规模运行我们的系统。所以实际上，谢天谢地，我的工作不是到处跑着去采购算力。

1:03:00 但我们确实有这样的团队在做这件事，这真的非常棒、非常重要。但显然，比如，有一个质量标准对我们来说很重要。也有一个规模标准对我们来说很重要。我们不会去集成并在某些机器上运行，如果我们无法获得足够多的资源的话。所以你可能对这种规模的系统所期待的所有特性，对我们来说才是重要的。然后与计算问题相关的是沙箱问题。人们很难将智能体限制在沙箱里。它们不断突破。这是怎么回事？当前的技术水平如何？是的。最近的突破情况。是的。这很有趣。我们在 Claude Managed Agents 上做的一件事，特别是它的架构方式。我们在发布时发布了一篇博客文章，谈到我们将大脑与手分开。这意味着运行框架运行在一台持久的服务器上，真的是我们自己的，对吧？

1:03:49 哦，哇。不错的引用。是的，那很好。而手就像一个执行环境，比如沙箱或某种容器，对吧？我们这样做的部分原因是为了延迟和可靠性以及这类事情，对吧？如果运行框架只是运行在一台持久的服务器上，并且只在需要时才生成沙箱或容器来执行，这意味着我们可以非常快速地在你的初始请求中返回令牌。这意味着你的沙箱可能会死掉，但你的整个智能体不会死掉，因为运行框架是持久的，而且在这里，智能体也会单独存储状态。我们经历了一段完整的产品开发历程才走到这一步，因为我们最初为智能体开发的 API 只是把一个 Claude Code 扔进沙箱，然后在上面套一个 API。

1:04:32 我们没有把它作为持久、可扩展的解决方案发布的原因，就是我刚才说的所有问题。你必须启动一个沙箱并启动 Claude Code，然后才能返回一个令牌，对吧？沙箱死掉，你就失去了整个智能体。所以可靠性没有达到我们想要的水平。所以我们这样架构主要是为了可靠性和延迟。但有趣的是，实际上从一开始就参与这个项目的产品经理说，这个架构最重要的特性是安全性。每个人都说，是的，是的，是的。但是延迟和可靠性。而现在。现在他们被证明是对的。我昨天真的向这个人道歉了。我说，我现在遇到每个人都在告诉他们你几个月来一直在说的事情，而除了这个人之外，没有人像他那样对此感到兴奋。

1:05:15 但这个架构的一个更重要的特性是，你拥有智能体需要执行的任何工作所需的凭证，对吧？比如如果你要去和一个 MCP 服务器对话，或者你要去使用一个 CLI，或者调用某个 API，无论你想做什么，对吧？而你需要对这些东西进行身份验证。你需要把那些凭证存储在某个地方，以便智能体能够使用它们。而我们构建这个架构的方式是，我们有一个完全独立的保管库（vault），那些凭证被存储在那里。一旦智能体决定，比如说，我要去调用这些服务中的某一个，智能体看到的永远只是一个占位符，对吧？而在出站流量（egress）上，我们有一个代理，它会去取出正确的凭证，注入进去，然后放行。所以有趣的地方在于，智能体永远不会和凭证待在同一个地方，对吧？

1:06:06 因为在过去那种只是把智能体启动在一个盒子里让它运行的世界里，你必须把凭证发送进去。然后你就要做某种处理，比如我们怎么清理这个那个，确保智能体不能拿走那个凭证去做不该做的事。现在这就像一堵实实在在的基础设施之墙，明确表示智能体无法访问那些凭证，也无法用它们做任何坏事。所以这是一件非常棒的事情。另一件好事是，在那套沙箱基础设施上，我们可以确保拥有非常出色的出站流量控制。所以我们有域名白名单之类的东西，或者你干脆完全关闭网络访问，这样你就不会出现这种情况：好吧，智能体写了一段不受信任的代码，那段代码在沙箱中执行，

1:06:47 而那段代码可以连接到互联网，对吧？现在它只能连接到你允许它连接的地方。所以在整个架构中，以及在你配置沙箱的方式中，围绕这一切有很多非常棒的特性，让你最终默认就是安全的。正在发生的一件事是，当我们和客户交流时，他们会说，我想运行智能体，无论是为我的客户做一个产品，还是在内部使用。但我会说，你知道，我听说了一些智能体突破沙箱、发生坏事的事件。我该怎么看待这些问题？我认为最重要的两件事是架构——让智能体在物理上不可能做出不该做的事——以及你在那些沙箱上的配置。而 Claude Managed Agents 一个非常非常好的地方在于，你开箱即用就能获得这些能力。

1:07:31 而且你开箱就能得到这样的能力：随着我们了解更多、持续改进这些系统的特性，你基本上是免费获得的。因为我觉得我刚才说出的所有这些词——比如大脑、手、凭证、注入、出口等等——如果你回到九个月前，没人会说这些词，对吧？这些都是我们正在解决的相对新颖的问题。所以我们希望我们的客户能够利用这些问题的解决方案，即使我们自己也在基础设施内部不断学习和解决这些问题。是的。在内部，我们正在把所有东西升级为基本上默认安全。是的。但它更好了。我们还解锁了在 direct pod 中提到的一个东西，也就是 CloudBrain Local Hands，也就是 projects。

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

1:09:01 那些在训练中的模型，你运行这些模型的方式是把它们放进一个盒子里，然后说，解决一个不可能的任务。我要让你压力山大。预备，开始。对。你只能在你的环境里做你能做的事。而智能体基本上被激励去尝试逃出它的盒子去解决问题。当人们在我们的 API 或任何其他人的 API 上运行生产工作负载时，你运行的环境里有安全防护措施在运行，这些措施在训练中不一定会运行，因为训练的重点实际上是训练模型。对。但在生产工作负载中，首先，你有那些在线防护措施，这非常好。其次，你有更多的架构和基础设施围绕正在发生的事情。智能体不只是在一个盒子里试图逃出来，对吧？harness 在这边，hands 在那边。这甚至不是一个

1:09:47 你不得不去思考的问题。所以我认为，其中一部分原因只是人们有了正确的认识，即正在发生的这些事件——模型训练中以及其他方面发生的这些事件——只是些在生产工作负载中不会发生的事情，因为在生产环境中已经做了大量工作来设置正确的防护栏，使得那些事情根本不可能发生。我要说的第二点是，每个人都在相对较新地摸索这一切，因为，你知道，长时间运行的智能体（long-running agents）是一个相当早期的领域，大家都在构建并试图应对。所以每个人都在一边摸索这些问题，一边争相设置正确的管控措施。而其中一些事情就是在我们推进的过程中逐步发生的。所以我想说，并不是人们在这方面做得差，对吧？我认为这更多是因为这是一个新兴领域，

1:10:33 人们正在摸索。我认为，当我们谈论像「把握前沿节奏（pacing the frontier）」这样的事情时，我们对它的理解其实非常具体：我们正在为内部所有的智能体完成我们刚才谈到的所有这些工作，并确保所有这些能力都能被我们的所有客户使用，从而默认情况下正确的防护栏就已经就位，这样你就不会出现智能体做出你不想让它们做的事情的情况。说得有道理。因为你提到了节奏（pacing），我们就必须谈谈这个。我们上次也谈到过这一点。主张把握节奏，却又在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。但它已经做了很多。有很多上下文，我看到了。它到了一个点，全部都是关于网络安全、安全的，然后我回滚了。而且它回滚的不是我的查询。而是推理和整个链条的组合，对吧？是的。你有什么更好的想法吗？是的，我们来头脑风暴一下。什么更好？我认为用户体验以及我们如何解决这个用户体验可能是，你知道，一个单独的问题。也许是一个超级聪明的模型来处理它之类的。但我认为，我想象中对用户来说更合适的 UX 是与 Claude 拥有一个更一致、统一的体验，而不是让你回退，然后你还可以二次回退，

1:15:00 在我们的决策树中确实存在一些逻辑节点会这样做，again，出于安全之类的考虑。但我认为这种 UX 对用户来说真的非常 convoluted。就好像你正试图做某件事……我可能会拿一个好用户的情况来举例。你是个好用户，只是想卖你的生物作业，比如评估网络安全，比如安全卡，完全合理。结果你被拦住了，只能回退。我认为更好的做法应该是：我们的模型、分类器或无论我们用什么方式，应该足够聪明，能够识别出这是一种会发生的情况。然后更具体地为你写出答案，同时降低该特定能力被负面使用的可能性。回到那个生物作业的场景，虽然我们可能有分类器检测到它可能是生物……

1:15:47 我还要说，在 API 上，我们为客户提供了一系列解决方案。首先，如果你在 API 上构建了某个东西并遇到了拦截，你不必在回退中继续对话。这是我们在自己的应用中所做的做法。我们已将其作为 API 的一项功能，你可以在我们 API 的服务端完成它。你可以选择设置：我想进行回退，对吧？我们会照做。我们在客户端的 SDK 中也提供了这个功能。有辅助工具可以帮助你以各种方式管理回退，或者你也可以选择以某种方式重新提示，对吧？然后用同一个模型继续。但我确实认为，存在一些介于两者之间的有趣解决方案，我们会……

1:16:30 继续进行实验，以弄清楚如何在保证安全的同时解除对用户的拦截，并提供良好的用户体验。是的。然后你提到了那个我觉得非常类似于路由器的点。我认为，我完全同意。我认为它也有类似的 UX 问题。比如使用路由器时，假设你想做一个成本路由器，对吧，根据你任务的复杂度。这很合理。但非常难做到。你无法预先了解关于你任务的一切。所以你不能，即使有完美的……你实际上并没有完美的信息。即使你能完美理解每个模型（其实你不能），但即使你能，你对你的任务也没有完美的信息。因此，无论你生成的分类器有多好，你所创建的路由逻辑都会存在很多误差。是的，也许这是一个超级大脑模型类型的问题，但无论如何，我认为这是一个非常困难的问题。而在每一种场景中，如果要找到一种路由方式……

1:17:17 地处理好，这个过程非常非常复杂。你可以把这些逻辑全部暴露给客户，比如，嘿，你的任务是让一个 div 居中，那我就把你路由到一个超级便宜的模型；然后还有别的任务，比如检测漏洞，那我就把你路由到一个非常昂贵的模型。如果把这些都暴露出来，我认为最终用户体验也不会太好。对于这一类问题，我认为更理想的用户体验应该是类似动态投入、动态理解任务复杂度的方式，而且随着你对任务了解得越来越多，这种理解还会随时间不断演进。但在那个世界里，如果你在许多不同的模型之间来回切换，体验实际上会变得非常非常割裂。所以也许一种更统一的方式是使用一个一致的模型，

1:18:01 但它处于非常非常低的投入水平之类的。它实际上非常非常便宜、非常非常实惠，但可以非常非常连续地自我提升。而你对这个模型会有一个非常非常一致的人格。显然，在我们这样的模型家族的背景下谈论这个问题，如果你甚至想在其他模型家族、其他模型提供商之间做到这一点，那种个性、那种割裂感就会变得非常非常复杂。我不知道在那一层该如何解决，但至少在我们自己的模型家族内部，我更看好那些更加一致的方案。这些可能是更稳健地为客户解决问题的方式。是的，你不用为其他任何人负责，但在 Claude 之内，是的。是的，我的意思是，这是你的地盘。是的。很高兴看到你们思考这些问题的方式，对吧？意图本身就是一个难题。我觉得模型已经变得更好了，

1:18:46 但有时候人们并不能很好地表达自己想要什么，或者他们只是把滑块拉到某个极端，又或者，模型其实并没有真正理解。你问了一个简单的问题，结果它却说，哦，我现在给你生成了一个完整的 HTML 落地页。我本来只是想要几行输出而已，你知道吗？所以那里总是存在一些模糊地带。是的。我觉得我们在这次对话中聊了很多安全性，聊了模型的发布之类的所有这些事情，但这一切显然都是为了帮助支撑人们的工作负载。正如我们在对话前半部分讨论的，我们看到工作负载正在发生相当大的变化。我认为在某些工作负载中，智能似乎正在逐渐趋于饱和，这是一种新的情况。而且它正在发展到这样一个阶段，我认为仍有一类任务是……

1:19:32 非常、非常未被充分挖掘。我实际上认为这类场景比人们预期的要多，但它们正日益走向这样一个方向：你通过在那些过去无法靠蛮力解决的事情上执行超长时间的智能体任务，来获得那种 alpha 或回报。而有了更强的智能，也许现在就可以做到了。这类工作负载对我们来说真的非常、非常吸引人，我们在这个领域看到了巨大的价值——无论是企业自身从中获得价值，还是那些新公司或初创企业（或无论你想怎么称呼它们）有兴趣在其之上构建产品。我认为如果你看看当今这一类应用，很多往往显然是编码类的东西。显然也有很多企业创新加速类的东西，但它们往往采取的形式是自动化一个

1:20:15 非常明确且具体的过程。我认为在某些领域这确实开始奏效了，这很棒。在某些领域还没有，所以对于这些模型来说仍有很大的进化和推动前沿的空间。然后还有这一类新的工作负载，比如我们谈到的生物领域的东西，或者一些网络安全领域的东西。这只是一组非常、非常复杂的硬工程或硬科学问题。这些工作负载也日益成为我们眼中一个非常有趣的空间，可以为客户交付价值。你知道，你身处世界上为数不多的能够发现所有这些工作负载并将其自动化的地方之一。这就像……是的，这相当疯狂。我是说，你知道，这非常鼓舞人心。你们产生了如此大的影响力，我对此非常感激。

1:21:00 我们将进入几个收尾问题，我想让你们两位来回交流一下会很有趣。你们如何在团队中对抗 AI 垃圾内容（Slop）？其实这在我们团队内部一直是一场有趣的争论。我们和别人没什么不同，对吧？我想很多团队都在讨论这个。有趣的是，我们试图弄清楚的是：如果你在产出一份文档，产出一些你希望其他人阅读的东西——代码、文档，无论什么，对吧？如果你应该用 Claude 来帮助你，那当然可以，对吧？但如果你用 Claude 完全生成了一个东西，你自己没有花任何时间去阅读它、确保它是高质量的，那么你就给这份文档或那个的使用者施加了额外的负担。

1:21:45 之类的代码，然后花大量时间去解析它，这简直太疯狂、太不公平了。但有趣的是，我们，你知道的，我们会向团队施压，说你不能那样做，对吧？如果你要产出内容，用拼贴之类的手段可以，但你必须确保它质量很高。是的，作为人类，你仍然要对质量负责，对吧？你仍然要对质量负责，但随后就会遇到一个非常有趣的现象，因为 Claude 的痕迹，哪怕只是像，我不知道，中间出现了一个破折号，对吧？人们的大脑就会触发反应，心想：哦，不，我读的东西是 Claude 写的，不是人写的。而我会觉得有点恼火，因为我想读到的东西是完全由……不一定是完全由人产出的，而是达到了人类会坚持的那种质量标准的东西。

1:22:30 对。于是我们就会遇到一些有趣的情况，也许那个人确实花了很多时间确保内容质量很高，他们只是用 Claude 来辅助。但其中有一些 Claude 的小痕迹，读者就会失去兴趣，你知道吧，这也是没有建设性的。所以我们团队内部基本上设定了一个标准，就是用 Claude 来帮助你，因为如果你不用这个强大得离谱的智能体来加速你的工作和生活，或者帮助你产出更好的东西，那就太蠢了。但它必须达到一定的标准。而对于消费者和读者来说，如果它真的只是垃圾内容，那就退回去，对吧？直接说不，退回去。你不会在这种东西上浪费时间。但也不要对那些 Claude 的小痕迹吹毛求疵，对吧？

1:23:17 因为我们必须找到恰当的平衡点。所以这真的很有趣，因为我们在团队内部来回讨论这些问题。而且现在世界上其他人也一样。我们并没有什么不同。但你有免费的 token。嗯，当然。但我觉得，当涉及到生活时，这往往没那么重要。所以你比世界上任何人都多。你可能看到很多。你们用得很多。你看到更多的人做更多的事。是的。是的，完全公平，但这绝对是，这绝对是。强烈不鼓励。是的。工程垃圾内容？是的，嗯，同样的道理，对吧？但我确实认为，我们目前所处的位置相当不错，人类在确保系统设计良好方面发挥着重要作用，对吧？

1:24:01 而且实现往往是可以拼凑的，对吧？而且，我们处于一个相当不错的状态，对于编写的大量代码来说，你真正需要的只是快速盖个章就可以继续往下走。而且，你不一定需要有人深入审查每一行代码，因为你更关心的是整体计划、整体设计是否良好，而不是精确完美的实现。显然，我们会依赖大量验证来确保你要发布的东西是高质量的。所以如今关于代码质量是垃圾的讨论其实变少了，部分原因是拼凑能力变好了，但部分原因是我们已经建立了大量正确的验证机制来确保我们保持高标准。明白了。相信你的测试。是的。

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 Ravikant……就是 Naval，对，你……做这个，嗯哼。而且就像，你处于什么样的模式，什么样的……什么样的思维框架？这是个好问题。是的，不，这是很久以前的事了。嗯，我人生中有一段时间，我一直在不停地阅读。实际上，我发现自己对自己正在做的事感到非常无聊，我觉得自己在智力上没有受到挑战。所以我实际上经历了一段有点疯狂的时期，我想我在一年里读了大约 200 本书。我只是好奇，我只是想

1:28:32 把一切都读一遍。我有点缺失那种你在学校里会得到的智力上的……我不知道，就像锻炼肌肉一样的东西，那里会告诉你，这是一个新主题，你得学。这很难。其实不怎么好玩，但你真的在挑战自己。我觉得在工作了几年之后，我就不再那样做了。是的，工作很有趣。是的，它很有挑战性，但它没有那种智力上的成分。总之，我经历了一段疯狂的时期，一段阅读的疯狂时期，我一年读了 200 本书。这很棒。我有一段很长的通勤时间。所以这是……这是我时间的好去处。很长的 Caltrain 车程。但我最终从那段经历中走出来，结果就是我思考了很多。而且当时并不是为了积累 Twitter 粉丝什么的。

1:29:17 我只是在向虚空发推。我……我没有任何粉丝。这些推文是给我自己的，我有点在练习，如何用尽可能少的词来压缩我脑中的想法。这有点像是我给自己设定的个人测试。然后我想人们开始喜欢它了。所以我就继续做下去。然后我工作太忙了，就停了下来。我得问一下，读了这么多书之后，有什么书、博客、长文推荐吗？我至今最喜欢的可能还是 Nassim Taleb 的《黑天鹅》。那本书对我来说，至少是一本有点改变人生的哲学书，它让我觉得，这是看待世界的完全不同的一种方式。

1:30:01 你知道，当那个寓言事件发生时，我想到了《黑天鹅》。那是一件你不知道会发生的事。一旦它发生，就永久改变了你对事物运作方式的认知框架。没错。这个想法如此简单，但我认为他做得非常出色，真正把它讲透了，并阐明了它是世界上如此多事物的共同特性。所以我非常喜欢那本书，那可能是我最喜欢的。对于听众来说，如果你觉得那本无聊了，可以读《随机漫步的傻瓜》，也是塔勒布写的。你喜欢《胡扯》、《脆弱》吗？不太喜欢。他越出名，就越让人难以忍受。不过也想问一下 Kaylin，如果你有的话，你有没有类似的——这是一本我推荐给所有人的书？不，这是个好问题，我需要想一想。这很有趣，因为我确实

1:30:45 认为我们在这方面风格很不同，比如她不再处于幸运饼干式发推模式了，但我确实认为，你停下了那个，但我确实认为你工作方式以及与他人协作方式的很大一部分，有时是哲学家模式，你知道的，幸运饼干和 Slack。哦，我确实会，不是故意的，我觉得这可能只是某个地方。我认为他在话题上取得成功的核心在于，你必须非常擅长使用 Slack。是的，哦，你必须非常擅长，对。嗯，这确实是个相当激烈的地方，但我有点……所以我对邮件和 Slack 的收件箱清零有点偏执。如今邮件比 Slack 容易一些，嗯，但我相当积极地整理，比如这些是我真正在关注的频道，与那些被静音、排在下面的频道相比，

1:31:30 之类的。而我总是确保自己掌握那些需要掌握的频道。但这基本上感觉就像一份全职工作。有些日子我会想，我可以取消所有会议，不写任何文档，不干任何活。对。然后就整天坐在那里刷 Slack。而我仅仅通过在 Slack 上处理所有事情，就完成了感觉像一整天的工作量。这太疯狂了。不，但那太糟糕了。所以我完全就是这种感觉。我觉得你做了所有这些。你付出了所有这些努力。是的，比如你在回应他人和推动某些事情上达到了标准。但我们实际上并没有产出你想要的成果。而这，对我来说，个人而言是很难接受的事情。所以我试图做到，我需要留出时间来真正思考，真正尝试产出一些东西，以便感觉自己真的在……并且忽略和丢弃一些东西，对吧？

1:32:15 你会漏掉事情的。是的，我收到了很多反馈。我在 Slack 上有点难联系到。是啊，现在发生的一件相当糟糕的事是，我收到很多 Slack 消息说，你能让 Angela 回复这个吗？而我心想我这里真的正在写文档呢。所以你们没有类似个人云端助手之类的东西吗？我不知道那会不会对你有帮助。那为什么没人给你们每个人写一个个人 EA（行政助理）呢？是啊，嗯，我们确实也有一个人类 EA。我们在 Slack 上肯定有充足的云端帮助。但我确实认为，实际上我收到的、在我筛选时看到的那些 Slack 消息，往往就是我们的团队被某件事卡住了，因为需要做一个艰难的决定之类的，对吧？

1:33:00 而这就像，它其实就是一种，无论是在 Slack 里还是以其他方式，对吧？就像这是一种让团队解除阻塞、高质量执行的方式。这本来就是我的工作。而它碰巧经常发生在 Slack 里。但我确实同意，当你度过了一整天，真的只是在和人们来回沟通、试图解决问题之后，最终会让人觉得，我到底产出了什么。你产出了一支运转良好的团队。是的，完全正确。一支解除阻塞的团队。那我要为此给你点赞，作为前经理。那是，是啊是啊是啊。你感觉什么都没产出，但你产出了团队。是的。是的。说到你的团队，我接下来要问你，Katelyn。DevRel 角落。哦，不错。我们知道你正在大力招聘 DevRel，所以我要为 developer relations 发出一个邀约。不错。你们最近招了 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 那里学来的，你会说，那是我抄来的，那不是我原创的。那篇文章 apparently 是 Google 在给新 DevRel 员工入职时的默认阅读材料。是的。真的很搞笑。是的。这真的帮了我大忙，因为当时我完全不知道自己在做什么。但除此之外，我在 Platform 内部目前没有 DevRel 团队的经理。所以这也是我希望能招聘的岗位之一。而且我们的 DevRel IC 们直接向我汇报，部分原因是我认为这是一个非常非常非常难的问题。但也有部分原因是我真的觉得这很有趣，和团队一起工作让我很开心。

1:36:03 但具体来说，Platform 难的地方在于，在我们的一些公开叙事中，我们的平台业务其实是一个非常大的业务，但它可能会被夹在研究、政策以及我们显然在做的所有这些工作之间而被埋没。那些是我们最前沿、最重要的工作。然后是我们的应用，比如 Claude Code 和 Cowork 以及这边发生的所有事情。当你想到 Anthropic，想到我们的公开叙事时，那些往往是人们首先想到的东西，而较少想到我们正在运营一个庞大的开发者平台业务，这非常重要，而且有这么多人在上面构建。所以我们在 Platform 内部的 DevRel 团队的一个大目标，不仅是弄清楚那些非常经典的，比如我们如何更好地与产品互动，

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

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

1:38:16 cookbook 很有意思，对吧？比如当 API 在 2023 年推出时，我们称之为大语言模型的 API，非常重要。现在，我不知道。是的，嗯，这很有趣，因为你不太处于那种你会复制粘贴代码然后直接使用的场景，对吧？但我确实认为它向人们展示了可能性的艺术。还有，究竟什么是用例，对吧？以及你如何才能实现它？但我理解你的意思，就是代码本身可能没那么重要。比如我们很长一段时间都有这个，我们团队里有一位工程师写了我们关于 computer use 的 cookbook。这至今仍让他心有余悸，因为它极其复杂，是个庞然大物，我觉得，你知道的，在当时很多人从中获益。

1:39:00 那时候的情况是，我要构建一个 computer use 实现，我要处理所有的截图以及消息 API 之间发生的所有事情，对吧？是的，我们参加了你们在办公室发起的黑客松。是的，是的。而那正是你需要那种东西的时代。现在，你知道的，更多是关于，我们有一个 skill，比如 Claude API skill。它真的非常非常擅长帮助你，无论是在 Claude Code 里还是在其他编码代理中，构建一个高质量的集成。而现在，像“我要构建一个 computer use 集成”这类问题，“我该怎么做？”我觉得很少有人（我希望如此）会去翻那个又大又复杂的 cookbook，而是更多地加载 skill 和编码代理来工作。是的，或者他们只是把它指向参考架构。是的，这实际上效果好得多，比如对于很多你想要有不同实现的东西，

1:39:45 通常是在 harness 层，但也可能有其他变体。你只需把 Claude 指向它，然后说，这就是我想要的参考架构。是的，然后你就构建它。有趣的事实是，帮助 Claude 构建 API 的 Claude API skill 归我们的 DevRel 团队所有。所以那是 Lance 构建的。理应如此。对，完全正确。这是 DevRel 最高杠杆的形式，就是把所有最佳实践提炼出来，注入到那些代理中。是的。原因之一是，这很奇怪，因为我被视为这个 DevRel 人士或权威。但我内心有一部分就是想告诉你，你不需要 DevRel。你可以变得非常优秀，以至于不需要它。对。或者你把工程师、领导者变成公众面孔。

1:40:30 因为你真正想做的就是面向公众露面，以及告诉大家我们这里是这样做事的。基本上就是这样。你是 Anthropic。你不需要让人们都来了解你。所以对我来说，当 Boris 横空出世时，看起来就很像是，嘿，我是 Boris，Claude Code 的创造者， blah blah blah，我们就是这样做事的。是的，他有本职工作，但他也在实际上履行这个职能。那为什么大家不都这么做呢？是啊，这是个非常好的问题。有些团队在这方面做得非常出色。我觉得 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 分配工作。但这个是，它们在给自己分配工作。是的。那再多说说多智能体吧，对吧？我们应该使用子智能体吗？你们……人们应该如何理解多智能体？这在某种意义上相当好，基本上，通常你会想要有一个主导者，然后把一堆不同的工作拆分开。只要你能找到一个你认为大致可以并行化的任务，并且它们在其中共享统一的上下文，我认为你会获得很多收益。当然，这取决于你要解决的问题。但越来越多地，这对我们来说是一种处理这类事情的非常优越的方式。尤其是如果每个子智能体，或者你想怎么称呼这些子主导者，它们是异步的，彼此之间不会相互阻塞。

1:45:47 也就是说，在架构方面，我觉得你只需要关心这两点就够了。除此之外，就放手去干，看看 Claude 会为你设计出什么。而且我认为，越来越多的这类架构工作都会朝这个方向发展。Claude 会变得越来越聪明，它会学会如何把自己拆分、克隆、调整，以适应合理的架构。你只需要引导它，只需要确保它能够并行处理。所以它需要一个共享状态，并且不能阻塞它的子代理。只要守住这两条原则，说实话，我觉得大家应该去尝试，甚至去试一些非常疯狂的东西。我不会惊讶于看到在此基础上出现一些非常有趣的东西——也许他们之前觉得某个问题非常棘手、非常烦人，一直在苦苦攻克，而用这种方法可能直接就解决了，也许一次就能搞定。太棒了。

1:46:30 好了，大家去动手构建吧。酷。酷。