Anthropic 工程与产品负责人对谈：如何用 Claude 发布 Claude 并将大脑与手分离

正如我们从昨天 Anthropic 的 S-1 招股书中了解到的，这家实验室拥有人类历史上最高的营收水平和研究效率，尤其是去年从 -126% 的亏损逆转为 19% 的 GAAP 盈利。该公司将此归功于他们的两个核心循环：改进与投资：

今天我们深入探究 Anthropic 的运作方式。如今，Opus 5.5 发布已满一个月，并一直被公认为全球排名第一的 LLM，我们与 Anthropic 的工程负责人 Katelyn Lesse 和产品负责人 Angela Jiang 一起深入探讨它的发布历程，以及 Anthropic 如何用 Claude 来交付 Claude。

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

模型发布同时也是 API 发布

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

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

Katelyn 还描述了参与早期访问计划实际是什么样子：客户在自己的运行框架中运行评估，报告意外行为，有时还会提供一些非正式的印象。有用的部分不仅仅是基准测试分数：而是在 Anthropic 自家产品覆盖不到的环境和任务中观察模型。正如我们连续四年在播客中所说，拥有好的评估集就是黄金。

大脑与双手

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

同样的分离给安全带来了一种有用的架构特性。如果生成的代码运行在一个永远不会收到服务凭证的沙箱中，那么该沙箱内就没有可供代码读取的凭证。节目中描述了凭证单独保存并通过代理附加的方式，同时还有对沙箱流量去向的控制。Anthropic 的隔离机制说明文章描述了其各产品中使用的更广泛的隔离和网络控制。

这种区分对性能也很重要。两位嘉宾说，早期的做法是把整个编码智能体放在沙箱中并通过 API 访问。启动环境和智能体在首次响应之前增加了额外的工作；如果沙箱消失了，正在运行的智能体也随之消失。将各部分分离使平台得以追求更低延迟和更高可靠性，同时保持执行隔离。

对于任何设计智能体运行时的人来说，这都是一个有益的视角。不妨自问：哪些部分需要持续存活，哪些部分要执行不受信任的工作，以及哪些密钥真正需要在代码运行之处存在。具体实现会因产品而异，但这些问题始终有用。

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

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

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

关于评估的讨论顺理成章地展开。harness 是一个应用，但改进它开始变得像研究工作：确定目标、衡量行为、检查失败并迭代。嘉宾与主持人讨论了用模型来帮助构建和分析评估，同时保留足够的判断力，以决定该评估是否反映了真实用户的工作。

节目笔记

Claude Opus 5.5 发布公告——Anthropic 关于模型行为、评估和定价的发布说明。
Anthropic 合作伙伴峰会上的 Katelyn Lesse 和 Angela Jiang——Anthropic 介绍了她们的平台工程与产品职务。
扩展 Managed Agents：将大脑与双手解耦——本期节目讨论的会话、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 记忆、做梦与智能体 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: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 每一美元营收差不多要亏掉半美元，而现在它每 1 美元成本能赚 2 美元。我认为这是一个很有意思的类比，说明过去一年里 Anthropic 的营收和业务前景发生了多么巨大的转折。

2:27 今年对 Anthropic 来说执行得如何是极其关键的，而它确实做到了。我认为我们基本上会深入挖掘这一点，尽我们所能从播客外部视角讲述这个故事。呃，这一整体增长的其中一个结果是，Anthropic 刚刚报告了其首个盈利季度——不是调整后利润，所谓调整后利润是指扣除所有成本之后的利润——不，这是公认会计准则（GAAP）利润，为 19……这非常惊人，再次相比一年前完全逆转，甚至不止是逆转，比如一年……

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

3:45 进而带来更好的 Claude。所以这两个循环基本上共同旋转，形成一个无限循环，按照 Anthropic S-1 的说法，它将永远推动效率的提升。所以我认为这就是我们从整体效率故事到他们如何执行这一故事的过渡。今天我们将大量聚焦 Claude 平台，因为这主要是他们在 Anthropic S-1 中所称的“Claude 扩散”的三件事之一。他们将这个 Claude 平台称为我们全面的智能体开发环境。他们为客户提供对其基础组件的直接访问，以构建、部署和扩展自己的应用程序，从而在自己的产品和工作流中利用 Claude 的能力。

4:30 我认为在本播客的讨论中经常出现的一个概念是“自食其力”（dogfooding），Claude 的许多产品实际上就是用你可获得的同一个 Claude 平台构建的。Claude 平台中披露的另一个有趣数据是：在追踪 12 个月（trailing twelve months）基础上收入达 10 万美元或以上的客户中，超过 50% 使用 Claude 平台。因此，这是 Anthropic 采用率的提升，它不仅作为模型实验室崛起，还作为一家超大规模提供商和 Claude 平台——我想这也许在名称本身就已隐含——正从理论走向实际实践。

5:15 而这也正是我们在播客中关注的内容。另一件我一直试图强调的事，我之前也提到过，就是 Claude Code、cloud 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 或任何其他人的 API 上运行生产负载时，你运行的环境里是有防护机制在运行的，这与训练时不同——训练时的整个目的就是真正去训练模型，那里不一定有这些。但在生产负载中，首先，你有那些在线防护机制，这非常好。其次，围绕正在发生的事情，你有更多的架构和基础设施。智能体不是被关在盒子里试图逃出去，对吧。工具架在这儿，工具在那儿。这根本就是一个你都不需要去考虑的问题。

7:30 好了，我们在 Opus 5.5 发布第二天请到了 Katelyn 和 Angela 来到演播室。欢迎。谢谢邀请我们。祝贺你们发布了目前世界顶级的模型。我觉得这取决于你问谁。是啊，取决于你问谁。你们个人最大的收获是什么？你们有官方博客文章。降价也确实很给力。发布这样一个新模型时，你们的感受是什么？我们为这个模型感到非常自豪。团队付出了大量不同的工作才把它做出来。我想我们确实听到了关于 Opus 5 写作风格有些绕的反馈。我们真的很努力地做了改进。而看到它似乎得到了大家的认可，我真的很高兴。在内部试用这个模型时，我们也有同样的感受。所以能获得这种印证真的非常好。关于降价，那里面确实有很多内容。

8:17 而且我认为越来越多的人正在追求每一美元能买到的优质智能。所以确保我们在“每美元”这部分做对是非常重要的。还有一些边缘的东西，其实并不是像我们博客文章里没谈过的那种——就是我们做了大量工作，试图让我们的 API 更难被蒸馏。因此我们做了一些改动，让这件事更加具体。这些改动涉及，比如说，我们如何做前缀锁定思考（prefix lock thinking），或者你如何在不同类型的模型之间重放思考 token。我们在这方面投入了大量工作和精力，确保针对非常合理的用例进行调整，比如你可能想在压缩策略（compaction strategies）之类的场景中这么做，而在另一些场景中，这种用例实际上来自恶意行为者，

9:05 有效来说。所以在这方面有很多走钢丝的平衡。我也很高兴看到很多这样的工作发布出来，除了推出一个每一美元智能性价比很高的模型，还有把沟通做得更清晰一点。是的。具体来说，你说的是这篇论文，《从专有……窃取推理轨迹》。是的，就是那篇。就我所知是真实存在的，对吧？我的意思是，显然他们向你们做了负责任的漏洞披露。他们做得非常负责任地披露，我们非常感谢他们来找我们。能给没听说过的人讲讲吗？这真的很酷。你是可以做到的。我是说，现在已经修补了，但是，那是什么样的？它在 Anthropic 内部引起过恐慌吗？应该没那么大不了。我不知道。我不太清楚这篇论文具体引起了多大的恐慌，因为这是我们早就知道的

9:48 一个缺口。对，这是两件分开的事情。一件是中国模型蒸馏。对。而这是后来发表的一项高知名度的技术。对，没错。我们很久以前就知道，思维链提取是最强大的模型蒸馏方式之一。实际上，我们探索了一段时间的一个方向是：如何跨轮次保留思考块，并使其成为更严格的必要条件。而我们面临的处境是，我们始终必须在这个非常非常艰难的权衡中做取舍：一方面是可能让 API 用户痛苦的用户体验改动，另一方面是对抗蒸馏的保护。

10:32 那么我们如何划定这条界线、说我们在防止蒸馏？也许先退一步说。我们不想被蒸馏的原因是，Anthropic 存在的全部意义，就是希望 AI 能安全地在世界上创造积极的成果。我们对产出的 token 运行大量安全防护分类器，以确保它们是安全的。如果有人蒸馏了我们的模型，并在没有安全防护分类器的情况下运行这些模型，可能会给世界带来不好的结果。这是我们不希望发生的事情。所以我们不希望有人为了恶意或不良的目的而去蒸馏模型。因此，对于所有出于善意使用模型的人来说，这始终是一个有趣的权衡，对吧？

11:16 我们并不想让大家从模型中获取智能变得更困难，但为了防止蒸馏，我们必须做出一些权衡。所以我们花了一段时间研究如何防止那种思维链提取？我们该如何以一种不会让人们太痛苦的方式保留思考块？我们基本上把用户体验的损失分为两层。一层是你必须做一个集成改动，这很烦人，但你仍然可以完成原本能完成的所有事情，只是有点麻烦。另一层是你实际上无法完成之前能完成的事情了。这是我们真的、真的、真的努力避免发生的情况。所以我们在最近几个模型上的落地方案是做一些渐进式的改动，来在多轮对话中强制执行这些保留的思考块。

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

12:49 同时仍然兼容保留的思考。这只是一个小例子，说明我们在这条线上小心行走，而不是直接莽撞地规定“你必须以这种确切的方式保留这些思考块”，因为那样会破坏很多人的工作，但我们花了时间与客户和开源 harness 维护者合作，为他们提供完成升级所需的东西。既然聊到契合度这个话题，蒸馏的另一面有什么要说的吗？就是另一半。是的，我们确实观察到蒸馏变得更难了，从我们能够查看的各项指标来看，难度显著提升。因为——这里要感谢研究人员——他们非常负责任地进行了披露。所以我们能够及时封堵，这很好。

13:30 他们确实非常公开地发布了结果。我知道这在 Twitter 上确实引发了不少热议。所以很多人都能使用它。是的，从我们能够衡量的方面来看，它似乎确实减少了我们不想要的负面影响。我想补充一下 Katelyn 刚才说的话：至少我在 Twitter（或者叫 X，随你怎么叫）上看到很多这样的说法：这是一个商业化问题之类的。如果你能窃取一个模型并拿来廉价运行等等。虽然没错，但这其实并不是我们非常在意的事情。相比其他任何方面，我们更多是从安全的角度来看待这个问题。所以这也是为什么我们更多从这个角度而不是商业角度来考虑。实际上，如果你从我们这里蒸馏，你是要付费的。所以从商业上讲，钱是我们赚的。所以它并不是

14:16 那种意义上的影响。更多是要确保我们的模型——我们想确保 Claude 是好的，而如果 Claude 被不当派生，那将是不幸的。另外，再谈谈 5.5，因为你们刚经历过这件事，有个很有意思的话题可以展现你们俩之间的协作关系，因为你们经常一起出席活动：你是产品负责人，你是工程负责人。这在你们之间是如何运作的？尤其是模型发布的时候。就举个例子吧。在模型发布方面，我们的产品团队和工程团队协作非常紧密。在我这边，更多是要权衡取舍：既要发布达到足够智能水平的产品，也要兼顾成本和保留策略。

15:00 我们更新缓存成本之类的举动，其实是在表明：我们希望你们采纳对所有人都真正有益的集成改动，并把节省下来的成本传递出去。这类决策，以及如何在安全机制与打造一个大家都能用得爽的好模型之间取得平衡……可以说，模型发布时围绕它的质量和周边配套更多属于产品侧，而集成体验方面，很多则直接来自工程团队。当然，如果你谈论的是 API 的体验，那两者是紧密交织在一起的。所以这其实一直非常棒。我们有很多工程师有着深厚的产品思维，我们非常欣赏这一点。

15:49 我这边也一样，有很多产品经理技术功底非常强。我们想要的是那种跨学科的复合型人才，因为他们能从各个不同的角度分析问题，找出最佳做法。不过我更偏重商业影响，而我觉得可以这样说：工程师会更关心集成体验。所以他们几乎是站在用户体验的角度看问题，只不过这里的 UX 更多是关于 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 再次发生？当我们审视这类问题时，我们会想，好吧，如果我们要设想最疯狂的一组可能性，我们实际上对事情会走向何方几乎没有把握。因此，我们其实需要做好对冲，构建一个押注组合。所以多数情况下，我们会采取对冲策略，比如：好吧，我们认为它不会再次发生，但万一发生了，我们确实希望有这个对冲，或者有能力把那件事做得很好。所以我们会优先考虑这类事情。然后我们越来越多地发现，多数情况下，采取这种产品开发策略后，我们往往发现：我们其实真的用上了这个东西。能再举一个独立的例子吗，好让我理解？比如这个 access 项目。

26:15 这个 X-Factor 是个很好的例子。它内部包含一堆授权之类的机制。我们开发它有非常具体的原因，就是为了……能把类似这样的项目开放给客户，非常、非常具体。你能大概介绍一下 access 项目具体是什么吗？当然。所以，如果你想要双用途，如果你想要——比如拿一个模型来说。你有一个模型，就叫它 Opus 吧，你想在 Opus 上使用高级网络（cyber）能力，用于研究或者其他你想做的事情，比如作为防御性用户。你可以带着你的用例申请加入这个项目，如果获得批准，我们会实际降低你那一版模型的安全防护，让你可以针对你的用例去尝试进行那些高级网络活动。当然，显然，

27:02 这需要针对每个用例进行理解，需要把范围缩小到特定用户，因为你不会普遍地这么做。你必须申请。而且即便是这类事情——像这样的项目——我们设计了 Katelyn 所谈到的很多底层机制来处理这类情况。对我们来说有点意外的是，或者说在组合式策略下，我们发现我们实际上能把这件事做成 X。我们在设计它的时候会想：它应该是什么样的？应该多通用？还是不该太通用？是应该过度聚焦于做这种验证风格的门户，再加上对模型非常特定能力的授权吗？我们倾向于选择更通用的方案，因为我们的想法是：我们不知道，也许能把它用在别的事情上，也许不能。结果它最终在诸如模型访问之类的事情上派上了极大用场。

27:47 writ large，用于管理我们所有的可信访问项目，处理模型的下线部署，因为我们对每一个基本原语的处理方式实际上都非常、非常通用。从普通产品的角度来看，我通常可能会说，这可能不太合理。我们应该专注于用例。这样说有道理。但在这里，由于我们选择了更通用的方案，我们越来越发现自己更频繁地用到那套方案。也因此，它带来了越来越多的回报。反正你本来就需要有这个东西，只是你有一个强制性的理由去把它做出来。从技术层面说，我是来自 AWS 世界的，对吧？IAM、OVC，然后真正深入研究这个领域的人会谈论 Zanzibar 和其他这些技术架构。我不熟悉“token grant”或者说“trust grant”这个词。

28:32 Trust grant，对。Trust grant。普通的 OVC 和 trust grant 之间有区别吗？我是说，其实没有。它是一种授权形式。对，就是 IAM，只不过是 Anthropic 的 IAM。对，算是吧。我觉得确实如此，我们有一种授权形式，比如，OK，你向一个 API 发起了请求，而这个请求在底层会访问一些数据，我们要确保你访问的就是你自己的数据。对。就是非常非常基础的授权。这就像是我们建立了一个非常简洁的数据模型，比如一个 trust grant 就意味着你已被授予访问某个特定模型的权限，或者你已被授予访问某个特定项目的权限，等等，有很多不同的变体。我们实际上发现自己无时无刻不在用到它。另一个好的例子是当我们

29:17 首次为 Fable 5.1 推出部分保留思考功能时，我们让一些老用户维持原状，给了他们一点，你知道，就像一段宽限期。对，宽限期。对，宽限期，让他们去完成集成上的改动。作为让老用户维持原状的一部分，我们说，好，我们必须跟踪谁是那些需要额外时间的现有客户，对吧？然后我们做了一个 trust grant。这样我们就可以说，对于任何请求，我们只是运行这个服务，它差不多处于我们请求的热路径上，以确保，你知道，我们只是顺便检查一下你是否拥有执行你想做的事情的授权，这其实和普通的授权没有任何区别，真的。只不过，我们不得不专门为我们的系统搭建一套机制，

30:02 并且要能在我们需要的那些位置插入这些检查。对，我是说，我觉得这些都是人们习以为常、不会真正去想的工程事务。那么，另一个例子呢？就是那些必须发生的平台层面的工作，你知道，也许是为 Claude Code 服务，也许是为……显然我和 Cognition 交流很多，但也包括其他客户——就模型发布而言，对吧？比如我们稍后会更多谈谈正在进行的安全工作。我只是想先在高层面上聊聊，因为你还记忆犹新，一次模型发布都包含哪些内容？如今它已经有点像一台机器了，先不算安全方面的部分，我觉得那才是更复杂的部分。但在那些环节之外，还有很多是从客户那里获取反馈的工作。所以，你知道，我们做出模型，

30:50 会有大量的安全测试。还会评估我们认为模型需要达到的水准。我们据此做出必要的权衡和决策。然后我们必须进行测试。我们会切出模型的各个版本。我们会进行评估。我们会做大量内部所谓的"蚂蚁觅食"式测试。这确实一直很有帮助。比如，我们很早就发现诸如"哦，这可能不是最好的"之类的问题。我们内部显然也大量使用 Claude 来开展工作，所以我们能够及早看到相关的信号。这有助于我们判断哪些变体可能优于其他变体。然后，当我们对某组变体非常有信心时，就会为客户切出一个版本。有时它会通过我们的一线产品提供，比如通过 Claude Code 或 CodeWork 之类的。

31:30 在其他情况下，它会通过我们的 API 客户提供。我们会与这些客户开展一种类似早期访问计划的合作。他们需要在各自的测试框架中做一些改动。我们与许多客户合作过，比如 Cognition、Cursor 这些公司。对于如何处理这件事，我们有一套流程，以便大家都能获得所需的反馈：它在你们的评估中表现好吗？你们喜欢它吗？不喜欢吗？有些东西是凭感觉的，我们也乐于听到这些。有些则是直截了当的评估，比如它在你关心的事情上表现如何？我们会把这些综合起来考虑。一旦我们对所有这些不同方面都感到满意，我们就会发布模型。模型反馈的现状感觉仍然非常缺乏结构化。基本上， always 就是公司之间的一个 Slack 频道："嘿，这东西好像有点怪。"然后大家就回："好吧，那我猜我来修一下。"

32:16 给我个 ID 什么的。是的，这很……我是说，这就是一个非确定性产品的本性，对吧？但我觉得正如你所说，真正加入我们早期访问计划的客户，都是那些拥有非常健全评估体系的客户。我确实认为其中很多是基于感觉的，很多对话也往往是凭感觉、临时进行的。部分原因在于我们在抢时间，对吧？我们想尽可能缩小从我们切出一个测试版模型到让所有人用上这个模型之间的时间窗口。所以这个窗口非常紧。但我们通常合作的客户，是那些我们知道会跑完整个评估套件、并能带着非常可操作的反馈回来找我们的客户。

33:01 尽可能快地与 vibe、基于 vibe 的反馈并行推进。当然，我们确实可以做一些流程上的事情，让这些东西随着时间变得更好。不过，你可能会惊讶——嗯，你可能不会惊讶，但我认为有些人会惊讶——世界上有多少智能体产品其实并没有好的评测来帮助测试这些模型。两年前我们请 Boris 上过播客，说我们还没有 so clock code。我是说，情况已经变了。确实变了。确实变了。但是，你知道，很多事情就是，你的评测就是你的用户，你没时间去把评测正式化，或者你没有经验，等等。没关系。等你认真起来的时候，自然就会有评测了。没错，完全同意。我觉得好的一点是，就像你说的，你们做了大量的 amp 内部测试。所以大家常说，在产品发布之前你们就能通过自己使用发现很多这类问题，对吧？

33:49 是啊。是啊。尤其是客户的 API 非常有用，因为他们会把 Claude 放进不同的测试框架（harness）里。而我们希望 Claude 非常非常通用。所以它在其他测试框架里的工作能力对我们来说相当重要。这类反馈对我们来说往往格外有用，因为它是我们从内部测试中得不到的新信息。什么样的反馈最有帮助？是回归问题吗？比如“我们这里有回归”“我们注意到这里表现好”。好的反馈当然很能验证方向。我觉得我们很多时候并不意外，但喜欢看到一些我们已有的假设得到验证。说实话，最有用的反馈是负面的。比如，它在这个任务上表现不好，在那方面也不行。我们非常欢迎这种反馈。然后我们就会想：好，怎么修复它？

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 里写一句：别这么做，然后它就不会这么做了。那我是不是在不公平地惩罚 Claude Opus 5.5，因为我的基准测试没有考虑个性化这个主观因素？所以我不知道问题具体是什么，但你们是如何处理个性化的？显然，一个模型可以做到很多

36:51 不同的事情，而且非常依赖个人——每个人都有自己的 CLAUDE.md，你们是如何演进的？这方面我们做得不算好。说真的，这非常难。非常非常难，而且它们之间既相互竞争又相互矛盾。我想是有 Claude 宪章吧，我觉得。那是老版本了。宪章是有的，但这个还是让你们来回答吧。宪章是有帮助的，但对于这类问题——模型如何针对各不相同的指令进行个性化，而这些偏好在不同用户之间差异极大——对我们来说非常难。我们通常尝试通过增加更多参数来解决，从而能针对不同客户群进行微调

37:32 如果我们无法掌控你的客户群，比如你是 API 客户，那我们就尝试给你提供建议，然后由你来做这些微调。所以有一些东西，比如说，虽然还没到针对各种 CLAUDE.md 或现在的 agents.md 之类文件进行个性化那种程度，但我们确实尝试在投入程度这一层面提供一些设置，比如你应该投入多少精力，比如你可能实际关心的模型大小之类的。但我认为对于我们真正需要的那种个性化程度来说，还差得远。所以这是个非常难的问题。目前我们解决这个问题的方式，除了提供多个参数之外，坦白说，就是尽量让模型展现出兼容冲突的品味，

38:15 纵观我们收到的所有反馈，并对其中一些事情做出判断。我认为随着时间推移，实际上，随着你扩展到更多客户和更多用户，这不是一种很有扩展性的做法。我们需要开发一些方法，让 Claude 能够吸收你的个性化偏好。也许这是你可以提供的一个信号，或者你可以调整的东西之类的。但我认为我们将不得不走一条更加朝这个方向发展的路线。不过就目前而言，是的，我们实际上只是对很多这类事情尽力做出判断，但这确实很困难。是什么样就是什么样吧。这里补充一个小细节。我想默认的推理努力程度改变了，现在是中等。这是那些可能会影响到不使用这个开关的普通客户的事情之一。是的，这就像是一个 Claude Code 的设置，对吧？这是一个默认为中等程度的 Claude Code 设置。

39:00 是的，他们只是……而且这个东西会变化。这个东西确实……这是我们用来实现个性化（我认为这个词可能有点过于激进，也可以说是定制）的一个参数的完美例子，也许针对不同的细分群体进行定制。比如，默认设置会根据你是免费客户还是 prosumer 客户、是 Claude Code 还是 Cowork 还是 Enterprise 之类的，还是 API 之类的来调整。当然，你显然总是可以自行调整，但这些是我们试图提供这方面支持的轻量方式。我们比较犹豫做的一件事是，我们不希望人们觉得自己无法控制对 Cloud 的定制。所以我们可以对这些事情采取更强硬的手段，例如，但我们希望让用户能够按照自己认为合适的方式体验 Cloud 的智能水平，尤其是当你想使用更高端的设置，或者想试验有时在较低端的设置是否对你的用例来说实际上更快时，我认为这是一个艰难的产品权衡。

39:53 所以我们倾向于采用温和的默认值，但给你调整的选项，我认为这在目前还算可行。但我可以想象，我们会随着时间推移，学会如何为客户把这件事做得更好。我们对目前这些还都不是超级超级满意，但我们知道，当我们发布一个模型时——就像你问的，发布一个模型需要什么？显然我们必须做的大事之一就是，好的，Claude 在某件事上变得擅长了，而有时那件事是我们应该在 API 上作为一个参数暴露出来让你控制的。但我认为随着这事逐渐演变，我们最终得到了一个有趣的混合体：有努力程度，有预算，还有所有这些你可以设置的东西。

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

41:19 但你可以开箱即得一个 harness，我们每次发布模型时都会做大量工作，去搞清楚新参数是什么？破坏性变更是什么？如何在我们自己的 harness 里把 Claude 的能力发挥到极致？这样对于使用它的人来说，你直接开箱即用就行，不用去操心这些。对于被这种方案吸引的人来说——而且这个群体相当庞大且在持续增长——顺便说一句，我们实际上在 AIE 上办了一场完整的 CMA 工作坊，我觉得办得相当不错。那么有没有单独的订阅源可以让人们获取 CMA 的更新？订阅源，比如……比如 Twitter 信息流、新闻通讯之类的？没有，我想实际上我们的 Cloud Devs 频道会发布，是的，我们在这方面挺高调的，因为它确实对人们来说是个有趣的选择。

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 上半年工作的重要部分。它停滞了吗？还在继续吗？

44:20 现在的重点是什么？尤其是 Managed Agents 方面。记忆、dreaming。哦，它确实是我们工作的重要部分。我想也许可以这样理解：我们推出 Managed Agents，是作为面向那些不想自己动手做这些事情的人的平台，对吧？或者说只是想把这些事情外包出去，比如我想从 Claude 中获得最佳表现，因为我们的团队就坐在这里评估所有这些内容，确保 harness 非常强大。记忆和 dreaming 的核心就是如何确保你的智能体能随时间持续改进？这些依然是我们团队的重要关注点。但我真正想说的是，正如我们之前谈到的，由于从安全角度出发发布模型变得越来越难，我认为我们团队的大部分精力已经不那么……

45:04 花在像“这里有个有趣的功能，可以用来对这个智能体做爬山优化”这类事情上，而是更多投入到如何把安全融入所有这些环节。因为最重要的事情是把模型的能力释放出去，而且是安全地释放出去。所以我想说，我们很多精力是在把这些同样的概念整合起来，给你一个既非常强大、又非常安全的智能体系统。这就是我们投入精力的地方。我觉得与今年早些时候相比，我们在 skills、dreaming、记忆这类“特定时刻注入”的功能上放慢了节奏。请热爱 skills。不，不，不。我们热爱 skills。我们热爱 skills。我们正在做更新。我不是说我们什么都没做，我们也热爱 skills。但是的，我认为相对而言，我们在其中一些工作上确实放慢了一些。

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 Managed Agents 里让它们真正强大的那些东西。

48:05 现在你可以让 Claude 去干活来利用这些原语，让它变得更强大，比如创建新的多智能体策略之类的。与此同时，我们团队的很多注意力会转向：好，社区，接着跑吧，你们自由发挥，而我们继续专注于，我们需要做哪些事情，来确保你能安全地访问这个系统内的模型。你提到一件事，就是你们在这类东西上跑了大量评估。这是个挺热的话题。有什么建议或最佳实践吗？专门针对评估的？对 harness、智能体的评估。评估有很多不同类型，对吧？并非所有评估都是平等的，取决于你所处的情境以及你想要测试的东西。

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 因为它还能让你以非常系统化的方式更新和编辑这套系统。所以随着新模型不断改进、情况不断变化，你可以真正审视你的系统所处的状态，而系统也会随之共同演进，在方方面面与你同步。没错。是的，基本上，我认为这就像我们讨论过的产品与工程正在融合一样，应用层工程和模型研究也正在通过这些共享的技术融合起来，对吧？确实如此。搞模型的人对做评估（evals）非常非常熟悉，而做应用的人只关心一点：它是否符合 PRD？这就完全是另一回事了……我觉得这是一种全新的技能组合。我记得你们今天发了一篇挺酷的博客文章，讲的就是这个，虽然角度有点不同。

52:30 那篇文章讲的是如何让 UI 快得多。但按照你说的像做研究一样对待它， basically 就是先定一个目标——我们想让东西加载得更快——然后去定义、去质疑各种事情。除了墙上时钟计时之外还能用什么？文里有一些有趣的引述。我觉得看到真正的研究员或工程师是怎么给 Claude 写提示词的，挺有意思。里面有类似这样的内容：我们列了 12 件事，说给你两周时间，结果他大概三天就做完了 12 件里的 9 件。对做研究的人来说，这是一篇值得读一读的有趣博客。是的，我很喜欢我们分享真实的提示词。有时候人们会惊叹：“天哪，提示词的写法居然这么疯狂、这么独特。”其实就只是“再努力点，Claude”。谢谢。我唯一的反馈是，它应该链接到 workbench。虽然那已经不是个东西了，但以前是。

53:17 这是个好主意。确实是个好主意。好。反馈收到。让一切都可以重放。反馈收到。很好。是的。嗯。不过你刚才本来要分享更多工程背后的故事，或者你们以前做的 Rust 相关工作。好的。我想我前面提到过一点，规模对我们来说是个问题。所以就是规模和安全，对吧？对，规模和安全。这是我们花时间最多的两件事。而且这真的很有意思，因为大多数人习惯谈论的规模，我不知道，通常是在 GPU 加速器那一层，而在 CPU 这个老派层面谈得少得多。而这在今天其实和加速器那一层一样是个大问题，

54:00 这真的很有意思。你拿不到足够的虚拟机，拿不到沙箱。主要就是一切都要能不停地启动、启动。用上你所有的资源。真的吗？你们的客户也很多。是啊，对，这很疯狂。你想想，我们的 CPU 用在——显然——运行我们的产品服务、运行 API、运行我们所有的应用上；CPU 用在沙箱上，我们做的所有沙箱化；然后还有 CI 之类的各种事情，你知道吗，你会惊讶于现在有这么多代码在被编写，因此 CI 运行次数多得多，因此你需要更多 CPU 来处理。所以总体而言——这不仅是我们的情况，我交谈过的每家公司都是如此。我要补充一点：训练。训练用的可能是沙箱。那是另一个类别，对吧？我确信它们不会混用太多。嗯，虽然不会混用，但对 Anthropic 整体来说，CPU 就是一场零和游戏。

54:50 你知道的，比如我们去和云服务商谈判签订合同，拿到我们的 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 做的东西。你明白我的意思吗？对。就像，对吧？这不正是需要延续性的消息 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 因为在过去那种直接把智能体启动在一个容器里让它运行的模式中，你必须把凭证送进去。然后你就得想办法清理、清洗，确保智能体不会拿那个凭证去做不该做的事情。而现在这实际上就是一堵实实在在的基础设施墙，明确规定智能体无法访问那些凭证，也无法用它们做任何坏事。这是一件非常棒的事情。另一个好处是，在这套沙箱基础设施上，我们可以确保拥有非常出色的出站控制。所以我们有域名白名单之类的东西，或者你干脆完全关闭网络访问，这样就不会出现“好吧，智能体写了不受信任的代码，这些代码在沙箱中执行”，

1:06:47 而这些代码还能连上互联网的情况，对吧？现在它只能访问你允许它访问的地方。所以，整个架构以及你配置沙箱的方式，围绕着这一切有很多非常出色的特性，让你最终实现默认安全。现在开始出现的一种情况是，我们和客户交流时，他们说想运行智能体，要么是面向客户的产品，要么是内部使用。但我听到过一些事件，智能体突破沙箱造成不良后果。我该怎么考虑这些问题？我认为最重要的两件事是架构——让智能体从字面上就不可能做出任何不合规的事情——以及你在那些沙箱上的配置。Claude Managed Agents 一个非常非常棒的优点就是，你开箱即得这些能力。

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

1:08:15 嗯。大致就是这样一个情况吗？是的。看来是这样的。对。我觉得这有点奇怪，因为显然你们或者说 Claude Code 以允许在机器上运行极度不安全、危险的权限而出名，但现在你们终于演进到了本来一开始就应该采用的方式。基本上我想问，所有这些沙箱逃逸，对吧？它们是我们对沙箱或容器技术理解上的根本性问题吗？还是我们只是做得不够好？我们只是没有做白名单吗？听起来就是我们没做白名单。嗯，也许我可以做一个区分：在人们听到和读到的很多事件中，这些是发生在模型身上的事件，而且不只是所有人的模型，对吧，

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

1:09:47 你需要去思考的问题。所以我认为，其中一部分原因只是人们对正在发生的事情缺乏正确的理解，其实模型训练等领域发生的一些事故，在生产环境中根本不会发生，因为生产环境已经做了大量工作来设置正确的防护栏，确保这类事情几乎不可能发生。第二点我想说的是，大家其实都是在比较新近的情况下摸索这一切，因为你知道，长时间运行的智能体是一个相对新兴的事物，每个人都在构建并试图应对它。所以大家都在边做边摸索，竞相建立正确的控制措施。而这些工作有些就是在过程中逐步完成的。所以我要说，这并不是人们不擅长这件事，对吧？我认为更多是因为这是一个新兴领域，

1:10:33 大家都在摸索之中。我认为，当我们谈论像“调控前沿速度”（pacing the frontier）这样的话题时，我们的思考方式其实非常具体：我们正在为内部所有智能体做我们在这里谈到的所有工作，并确保所有这些措施对所有客户都可用，这样默认情况下，正确的防护栏就已经就位，你就不会遇到智能体做出你不希望它做的事情的情况。有道理。因为你提到了“调控”，我们得聊聊这个话题。我们上次也谈过这个。表面上这很矛盾：一方面倡导调控前沿速度，另一方面又在 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 在我们的决策树里确实有一些逻辑点会这么做，又是出于安全之类的理由。但我认为这个用户体验对用户来说实在太过绕了。就像是，你本来想做成一件事，而且我大概会以一个好用户的情形来举例。你就是个好用户，只是想卖你的生物课作业，或者评估一下网络安全，比如安全凭证之类的，完全合理。然后你被拦下来了，你只能回退。我认为更理想的情况应该是：我们的模型、分类器，或者不管我们用什么方式，应该足够聪明，能识别出这种情形确实会发生，然后更具体地把答案写给你，同时说明这种特定能力被滥用的风险。所以回到那个生物作业的场景，虽然我们的分类器可能已经检测到这可能是生物学相关的内容。

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 非常、非常不饱和。我实际上认为机会可能比人们预期的要多，但它们正越来越朝着这个方向发展：通过执行运行时间极长的智能体任务来获取那种超额收益或回报，而这些任务在历史上你是无法用暴力方法解决的，但也许在背后有更强的智能加持下就可行了。这类工作负载对我们来说真的非常迷人，我们在这一领域看到了很大的价值，无论是企业自身从中获得价值，还是那些有兴趣在此基础上构建智能体产品的新公司、初创公司等等。我想如果你看看今天这类东西的构成，很多显然是编码相关的东西，显然也有很多企业创新、加速之类的东西，但它们往往采取自动化

1:20:15 某个非常独特且具体的流程的形态。我认为在某些领域这确实开始奏效了，这很棒。在某些领域仍然不行，所以这些模型仍有很大的进化和推进前沿的空间。然后还有一类全新的工作负载，比如我们谈到的生物领域的东西，或者某些网络安全领域的东西。那是一套非常非常复杂的困难工程或困难科学问题。这些工作负载对我们来说也日益成为一个非常有意思的、能够直接为客户交付价值的领域。你知道，你身处世界上少数几个能发现所有这些工作负载并实现自动化的地方之一。这就像……是啊，相当疯狂。我是说，你知道，这非常鼓舞人心。你们正在产生如此大的影响力，我对此真的很感激。

1:21:00 接下来我们要进入几个收尾问题，我觉得由我们俩互相抛来抛去会很有意思。你们在团队里是怎么对抗“垃圾内容”（Slop）的？其实，这在我们团队内部一直是一场有趣的辩论。我们和其他人没什么两样，对吧？我想很多团队都在讨论这个问题。有意思的是，我们试图弄清楚的是：如果你在产出一份文档，产出某种你希望其他人阅读的东西——代码、文档等等，对吧？比如说，你当然应该用 Claude 来帮助你，对吧？但如果你用 Claude 完全生成一个东西，你自己完全没有花时间去真正阅读它、确保它是有高质量的内容，那你就是给那份文档或那个

1:21:45 代码之类的，花大量时间去解析它，这简直太疯狂、太不公平了。但有趣的是，你知道，我们会反对，我们会要求团队：你不能那么做，对吧？比如你产出某个东西时用 collage 或者别的什么，但你必须确保它是高质量的东西。是的，你作为人类仍然要对质量负责。你仍然对质量负责，但接下来就出现了非常有趣的情况：由于 Claude 的那些小毛病，哪怕只是些愚蠢的，比如文中有个破折号之类的，对吧？人们的大脑就会触发反应：哦不，我读的是 Claude 写的东西，不是人写的。然后我就很恼火，因为我想读到的是不一定完全由人类创作的、但符合人类会有的质量标准的东西。

1:22:30 对。于是就出现了搞笑的情况：也许实际上这个人确实花了很多时间确保内容高质量，只是借助了 Claude。但里面那些 Claude 的蛛丝马迹会让读者望而却步，你知道，这同样是无益的。所以我们尝试做的是在团队内部设立一个标准：要用 Claude 来帮助你，因为如果不使用这个强大得离谱的智能体来提升你的工作和生活效率，或者帮你产出更好的东西，那才真是傻。但产出必须达到一定的标准。而对于消费者和读者来说，如果它真的就是垃圾，那就退回去，对吧？直接说不，退回去。不值得为此浪费时间。但也别对那些 Claude 的小毛病太吹毛求疵，对吧？

1:23:17 因为我们必须找到正确的平衡点。很有意思的是，我们在团队内部反复讨论这些事，而此刻世界上其他人也都在做同样的事。我们并没有什么不同。但你们有免费的 token。嗯，当然。不过说真的，在现实生活里这往往没那么重要。你们的 token 比世界上任何人都多，你大概见过很多。你们用得很多，见过更多人做更多的事。是的，是的，完全合理。但这确实是……确实是被强烈劝阻的。是的。工程上的垃圾内容？嗯，我觉得是一回事，对吧？但我确实认为我们目前达到了一个相当不错的状态：人类在确保系统设计良好这件事上扮演着重要角色，对吧？

1:24:01 而且实现往往比较粗糙，对吧？我们现在处于一个不错的状态：对于很多被写出来的代码，其实你只需要快速过一遍检查（盖章）就能继续往下走。你不一定需要有个人深入审查代码的每一行，因为你更在意的是整体计划、整体设计是否处于良好状态，而不是每一处完美无缺的具体实现。当然，你会依赖大量的验证来确保最终发布的东西是高质量的。所以如今关于“代码质量变成垃圾（slop）”的讨论其实变少了，部分原因是模型变好了，但另一部分原因是我们已经建立了许多正确的验证机制，确保我们守住了高标准。我明白了。相信你的测试。是的。

1:24:45 至于产品 PM 产出垃圾内容，你可以频繁发布功能，一天之内就能把东西上线。所以最近他对我说了这样一句话。你还记得他说了什么吗？Tarek 发推说过这个。使用模型能力的正确方式，并不是往生产环境里塞 10 倍多的功能。应该花更多时间去理解你的用户、做实验、搞构建等等。基本上，你可以非常轻松地不停发布一堆随意的东西，但你其实应该认真思考。你应该花更多时间打磨第一个提示词（prompt）。我知道今天他会说：启动 plan mode 就行了，不需要那些了。但在 plan mode 之外，你应该想清楚自己在做什么，对吧？很容易一口气发布一大堆东西，然后产品问题就解决了。是的。我是说，我常常会念叨这一点：现在有很多只是……基础性的东西

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 觉得我们在这方面风格很不一样，比如她已经不再处于“ fortune cookie 式发推”模式了——哦你以前是这样——但我确实认为，你的工作方式以及与他人协作的方式中，很大一部分是“哲学家模式”，你知道吗，fortune cookie 和 Slack——哦，我确实会这样，虽然不是故意的，我觉得可能只是某个地方。我认为这就是他在 Topic 成功的核心，就是你必须在 Slack 上非常出色。是的，你必须非常出色。嗯，那是个相当高强度的地方，不过我有点——我对邮件和 Slack 的“收件箱清零”近乎偏执。如今在邮件上做到这一点比在 Slack 上容易。我会相当激进地做精简，比如这些是我真正在关注、真正留意的频道，而其他的则被静音、放在次要位置那一档，

1:31:30 诸如此类。而且我总是确保自己能跟得上那些必须跟上的频道。但这基本上——感觉就像一份全职工作。有些日子我会想，我可以取消所有会议，不写文档，不做任何工作，对吧，然后一整天就坐在那里刷 Slack。光是参与 Slack 上所有的事情，就已经相当于干了一整天的工作量了。真的很疯狂。不，这太糟糕了。这正是我的感受。我感觉你做了这一切，投入了这么多精力，没错，你在回复别人、推动某些事情落地这些方面达标了，但我们实际上并没有产出你想要的成果。而这对我个人来说是非常难以接受的事情。所以我努力告诉自己，我需要专门留出时间来真正思考、真正尝试产出一些东西，这样才能感觉自己真的在做实事。并且要懂得忽略和放弃一些事情，对吧？

1:32:15 你总会漏掉一些东西。是的，我收到了很多反馈。我在 Slack 上确实有点难联系到。对，现在挺糟糕的一件事是我收到很多 Slack 消息说，你能让 Angela 回复一下这个吗？而我在想，我正努力写一份文档呢。所以你们没有类似个人云助理之类的东西吗？我不知道这能不能帮到你。那为什么没人为你们每个人写一个私人助理？嗯，其实我们也有一位人类助理。我们在 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 业务和智能体编程这两条线上分别与之互动，对吧？所以我们最终是作为两个独立的团队来运作的，但彼此之间有点虚线汇报关系，并且花了很多时间一起协作。这本该是由我负责的事情——DevRel，我在 Stripe 或其他地方与 DevRel 打过不少交道，但这从来不是我负责的领域，我当时想，我完全不知道该怎么做，然后你说：有我在。

1:35:16 比如这里是 DevRel 的三大支柱，教你如何思考，涵盖产品、内容、社区，真的很棒，现在我可以随口讲给别人听，他们会说：哇，你真的很懂 DevRel。我说其实不是，是从 Tommy 那儿学的，我是抄来的，那不是我原创的。那篇帖子 apparently 是 Google 新 DevRel 入职时的默认必读材料。是的。真的很有意思。是的。它真的帮了我大忙，因为当时我完全不知道自己在做什么。另外，我目前在 Platform 里还没有 DevRel 团队的经理，这也是我希望招聘的职位之一。我们的 DevRel IC 直接向我汇报，一部分原因是我认为这是一个非常非常难的问题，另一部分原因是我觉得这很有趣，和团队一起工作让我很享受。

1:36:03 但具体来说，Platform 难在哪里呢？在我们的公开叙事中，platform 业务有时是一个非常大的业务，但它可能会在我们明显正在做的研究、政策等最前沿最重要的工作，以及 Claude Code、Cowork 等应用业务之间被淹没。当你想到 Anthropic，想到我们的公开叙事时，浮现在脑海的往往是那些东西，而较少想到我们其实在运营一个非常重要、有很多人在其上构建的大规模开发者平台业务。所以我们 DevRel 团队（隶属 platform）的一个重要目标，不仅是解决那些经典问题，比如如何更好地与产品互动、如何把反馈传回产品等等，

1:36:46 还有很重要的一部分是找到我们的声音，明确我们的品牌应该是什么样的，我们的叙事应该是什么样的，以及我们在这个社区里究竟要扮演什么角色，而不是迷失在所有正在发生的事情之中。我觉得这很有意思，因为我们为 DevRel 团队打造的品牌，部分源于 Lance 的加入——实际上是我通过你认识的 Lance——他做 DevRel 的方式非常技术导向，本质上是教学，对吧？比如他写了很多关于记忆和成本管理之类的内容，而且钻研得很深。他会构建 evals，产出大量非常技术性的内容。我非常喜欢这个想法：让我们的 DevRel 团队在一个非常初期、非常困难、不断演进的领域里，成为人们心中的思想领袖。

1:37:36 教育者、思想领袖、事物的讲解者。还有一种我非常喜欢的角色叫做“搭建大师”，就是我可以用平台搭建出一些东西来向你展示什么是可能的。然后你会说，哦，我原来不知道 Claude 平台还能做到这些。然后你就去做了。这是从乐高那里借鉴来的。因为乐高是怎么卖乐高的？他们有搭建大师。他们用乐高搭出作品，你就会想：我想做那个，我想成为像这个人一样的人。然后他们就去做了。不错，太棒了。是的。还有我们团队里的另一个人 CJ，他也非常出色，我觉得他做的更多是这类事情，比如编写 cookbook、发布示例，以及在 X 上真正地与社区互动。

1:38:16 Cookbook 这个词挺有意思的，对吧？2023 年 LLM 的 API 刚推出时，可以说是非常重要。现在嘛，我不确定。是的，这很有意思，因为你已经不那么处在复制粘贴代码然后直接使用的位置了，对吧？但我确实认为它能向人们展示什么是可能的。以及究竟什么是使用场景，对吧？还有你该怎么去实现它。但我明白你的意思，代码本身可能没那么重要了。我们有很长时间都是这样——我们团队有一位工程师写了我们关于计算机使用（computer use）的 cookbook，这件事至今还困扰着他，因为那东西极其复杂，可以说是个庞然大物，我认为在那个时期确实有很多人从中受益。

1:39:00 就是那种“我要自己实现一个 computer use，然后处理所有的截图和各种在 messages API 之间发生的事情”的时代，对吧。是的，你们办公室举办黑客松的时候我们就在现场。对，对。在那个时候你确实需要那种东西。而现在，更多是——我们有一个技能，比如 Claude API 技能。它在帮助你在 Claude Code 或任何其他编码智能体中构建高质量集成方面，真的非常非常出色。现在像这类事情，比如“我要构建一个 computer use 集成，我该怎么去做？”——我认为，或者说是希望，很少有人在去翻那本庞大繁复的 cookbook 了，更多的人是加载这个技能，让编码智能体去干活。是的，或者他们直接去参考参考架构。是的，实际上那样效果好得多。越来越多地看到，对于很多你可能需要不同实现的东西，

1:39:45 通常是在 harness 层面，但也可能有其他变体。你直接让 Claude 指向它，说：这就是我想要的参考架构。对，然后你就把它搭出来。一个有趣的事实：帮助 SQL 针对 API 进行开发的 Claude 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 没错，但你看，他在做这份工作，他确实在做这份工作。所以你会想要更多这样的人，因为人们想听产品相关人员讲话，而不是那些拿钱办事的人，拿钱的代言人。虽然我收到很多这种合作邀约。这也没问题。这也是一份工作，总得有人来做。合理地讲，你可以预期做工程的人不擅长这件事。所以你应该花钱雇一个专门做这个的人。专业化是一种技能。我认为会出现一种后台与前台的分工。是啊，这真的很酷。我的类比是：每个人都在招人，但你有一个 HR 部门。HR 部门让你能够招人。确实。真正招人的是你。是的。非常有道理。好，这就是我的个人宣言了。

1:43:31 收尾提问。你们的时间已经很慷慨了。有什么临别感言或行动号召吗？Opus 5.5 上有什么酷的东西？有什么人们应该用来挑战极限的，Opus 5.5？你们用它的时间最长。嗯，它真的很划算。输出不那么啰嗦。我们提到的所有那些，体验感真的、真的很高。一直很有趣。昨天对我们来说是非常有趣的一天，因为终于又……我收到了一堆来自朋友和大家的短信，都在说：太棒的模型，谢谢。比如我的一位老上司给我发消息说，Opus 5.5 刚在一次事故中救了我们的命。对。然后就觉得，好吧，太好了。“我们回来了”真的是我们现在感受到的氛围。所以我认为，那些你以前想尝试、但成本曾是你心头大事的事情，

1:44:18 对，还有 token 效率之类的，这些东西可能曾让你不敢真正放手让模型去跑。我认为这些正是你现在应该带着 Opus 5.5 重拾的问题，因为我觉得你能走得比以前用那些性价比没那么高的模型时远得多。我认为你应该试试多智能体设置的东西。我觉得你会发现效果非常好。顺便问一句，还有别的提示吗？我是说，多智能体的范围很广。没有。我们非常好奇大家会构建出什么。不过对，它应该会格外好。对，包括那种没有严格定义、而是它们之间自行分配的角色。对吧？这对我来说是新东西。

1:45:00 你可以分配角色。你一直都可以分配角色。你可以给 token 派活。但这就像是，它们在给自己派活。是的。能再多聊聊多智能体吗？比如，我们该用子智能体吗？你……大家应该怎么理解多智能体？这方面相当不错，大致来说，通常你会想要一个主智能体，然后把一堆不同的任务拆分出去。只要你觉得某个任务大体上是可以并行处理的，而且它们之间共享一致的上下文，我认为你会获得很大的收益。当然，这取决于你面对的具体问题。但对我们来说，这越来越成为处理很多这类事情的优越方式。尤其是当每个子智能体，或者你想怎么称呼这些子负责人，它们是异步的、彼此不阻塞的时候。

1:45:47 在我看来，这就是你在架构层面唯一真正需要关心的两点。除此之外，放手让它去做，看看 Claude 会为你设计出什么。而且我越来越觉得，很多这类架构上的事情都会朝这个方向发展。Claude 会变得越来越聪明，它会学会如何拆分自己、克隆自己、把自己调整到合理的架构上。你只需要防止它越界，确保它能并行处理。所以它需要一个共享状态，并且不能阻塞它的子智能体。只要守住这两条原则，说实话，我觉得大家应该大胆尝试，甚至试一些非常疯狂的东西。我也不会惊讶于看到有人在此基础上做出非常有趣的东西——也许他们原本觉得某个棘手的问题很烦人、一直苦苦推进，而现在可能一口气就把它搞定了。很好。

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