Anthropic 如何打造全球领先的大模型

我想区分一下：大家听说或读到的许多事件，发生在训练中的模型身上，而且不只是某一家公司的模型。在训练时，运行方式是把模型关进一个盒子里，告诉它“解决一个不可能完成的任务”，再给它施加压力，开始计时。它只能在自己的环境里行动，于是智能体会受到激励，想办法逃出盒子去解决问题。

谢谢邀请我们来。

我们为这款模型感到非常自豪。团队投入了大量工作才把它做出来。我觉得我们确实听取了大家对 Opus 5 写作风格的反馈：它有时有点绕。我们真的努力改进了这一点……

……把写作风格改好。我很高兴看到这项改进似乎得到大家认可。我们内部试用模型时也有同感，所以得到这样的验证特别好。说到定价，其中确实有不少内容。我觉得现在大家越来越看重每一美元能买到多少智能，因此把“每美元的表现”做好非常重要。

对，就是那篇论文。

我不确定那篇论文本身有没有让我们特别震惊，因为这是我们早就知道存在的一个缺口。

没错。我们早就知道，提取思维链是蒸馏模型最有效的方法之一。我们也很早就探索过：如何让模型在不同轮次之间保留思考区块，并把这种保留变成更强制的要求。我们一直面临一个非常艰难的权衡：一边是可能让 API 用户感到痛苦的体验变化，另一边是防止模型被蒸馏。我们必须找到一条中间路线。

……如果用户同时使用多个账号，我们怎样确保他们不能借此从模型中提取思维链？为此我们推出了几项额外功能。我们还与许多开源执行框架的维护者合作，主动联系他们，说明他们需要升级框架，并希望确保升级过程顺利。我们也和在 API 之上构建执行框架的大客户合作。有些客户的上下文压缩策略会因为必须保留思考区块而失效，所以我们在 API 中推出了新的压缩功能，替代他们之前手动实现的做法，同时仍然支持保留思考区块。

我们观察到，通过我们能够监测的措施，蒸馏确实变得困难了很多。也要感谢相关研究人员，他们以非常负责任的方式披露问题；我们能够把漏洞关上很好。他们也公开发布了研究结果，我知道它在 Twitter 上很热门，所以很多人都看到了。不过，就我们能够测量的部分而言，这确实降低了我们不希望发生的负面影响。

补充一下 Katelyn 刚才说的：我在 Twitter，也就是 X 上经常看到有人把这说成商业化问题——如果你蒸馏一个模型，就能把它拿来低成本运行。虽然这话有道理，但这其实不是我们特别在意的事。我们更关心安全问题。现实地说，如果有人从我们的模型蒸馏，实际上仍然是在向我们付费，所以从商业角度看影响并不大。我们更关心的是确保 Claude 本身是安全、可靠的；如果它被衍生出来之后产生负面结果，那就很遗憾了。

在模型发布时，产品和工程团队合作得非常紧密。就我这边而言，很大一部分工作是权衡：怎样发布一个智能水平达标的模型，同时把成本控制好。比如，我们更新现金成本，就是希望鼓励大家采用对各方都有益的集成改动，并把节省下来的成本回馈给用户。

工程团队会更关注集成体验，因此也会从用户体验的角度出发，尤其是 API 和开发者工具的体验。

做开发者产品和平台的产品工程师很有意思。我也认同这一点。我们有很多工程师喜欢思考产品、用户体验和开发者体验。我和 Angela 之间也是这样的合作动态：我对产品团队有很多意见，有时会不停地谈这些事情；产品团队也非常懂技术，能够深入讨论规模化等决策细节。这种合作很有意思。

Katelyn 和我一起工作很久了，最早是在 Stripe……

在 Stripe。

后来我们虽然没有在 OpenAI 共事，但都在不同的实验室工作，之后我也加入了 Anthropic。我觉得我们俩有个有趣的特点：Katelyn 经常被误认为是产品经理，而我经常被当成工程师，尽管这都不是我们的实际职能。这样的搭档关系有助于我们做出兼顾两边的决定。

我有点同意，大家好像都会这么说。

我不会把软件工程说成已经“被解决”了。我通常会这样看：我们的目标会不断提高。比如，我们团队目前花很多时间做的事，当然包括安全发布模型所需的一切。这是最重要的工作，因为我们还要处理智能体安全、离线防护和在线防护等一系列安全问题。

我想这首先取决于我们在防护和安全方面需要制定什么政策，既包括离线安全，也包括在线安全。最近大家谈了很多数据留存，以及我们如何处理数据留存，以便安全地发布这些模型。原因是，在由许多人组成的大型网络中，可能会有很多账号被创建，并以各种方式使用模型……

如果我们能在 token 流过系统时进行在线监测，就可以发现模型使用中是否出现恶意行为、蒸馏或其他问题。因此我们开始制定数据留存政策，以便开展自动审查和人工审查，确认模型及其每次发布都在被妥善使用。这是每次发布特定模型时都必须作出的政策决定之一。

随着模型能力增强，这些安全工作也在扩大。当模型在某些领域的能力显著跃升时，我们就需要特别关注。评估工作很大一部分来自这些特定能力：我们可能会认为它们更偏进攻性或防御性，并据此采用不同策略。

这很大程度上是要在系统中建立正确的框架。刚才谈到工程团队的部分，我们在系统里构建了正确的授权机制和信任授权链。

是啊。

确实很有意思。我们团队当时把“只需按一个按钮，就能为所有人撤回访问权限”的系统列入了工作计划。我们当然希望类似事件永远不要再发生，但做这项工作的意义，在于把一套基础能力建立起来。我们希望到处都有这些底层机制，用来管理验证项目和 Mythos 等模型的访问权限；这样一来，所有模型访问都经过同一套控制机制，万一需要撤回，我们就已经准备好了。

这样的决定确实改变了我们制定路线图的方式。传统产品管理会假设某些事情会发生，并为它们安排次序；你其实是在做比较具体的押注。但像 Fable 部署这样的事情，我想没有人会预料到政府会提出这样的合法用途，并促使我们这样去做。可是这种情况发生的概率显然不是零。因此，从产品管理角度看，我们现在会更多采用概率思维：这件事再次发生的可能性有多大？

访问项目是个很好的例子。内部有一整套授权和审批机制。我们专门开发这些能力，是为了让我们能够向客户提供这种非常明确、范围很窄的访问项目。

本质上没什么区别，它是一种授权形式。

差不多。普通授权是这样：有人调用 API，后端会访问某些数据，我们要确保访问的是属于这个人的数据。这是很基础的授权。我们只是建立了一套清晰的数据模型，规定“信任授权”代表某人获准使用某个特定模型、参加某个特定项目，或者获得其他类型的授权。我们发现这种机制在各种场景里都用得上。

如今发布流程已经有点像一台机器了，安全部分比较复杂。除此之外，我们会从客户那里收集很多反馈。模型做好后，我们会进行大量安全测试，也会评估它达到预期要求的程度，并作出必要取舍和决定。之后进入测试阶段：我们会制作不同版本、进行评估，并在内部大量“自用”。这很有帮助，能让我们很早就发现某些版本可能不够好。我们内部大量使用 Claude，所以能及早看到信号，判断哪个版本可能更好。

我们综合这些信息，等大家对各方面都满意之后，就发布模型。现在模型反馈仍然非常非结构化。

对，这就是非确定性产品的特性。不过，正如你说的，能参与早期访问计划的客户，都是拥有成熟评估体系的客户。我觉得很多判断确实依赖直觉，沟通也常常是临场、非正式的。一部分原因是我们在和时间赛跑：我们希望尽可能缩短模型测试版本完成之后、向大家开放使用之间的窗口。这个窗口很短，但我们会选择那些能迅速启动整套评估，并尽快给出可执行反馈的客户，同时也收集他们的直觉感受。

完全同意。

API 客户尤其有用，因为他们会把 Claude 放进不同的执行框架。我们希望 Claude 的通用性很强，因此它能在其他框架中正常工作，对我们很重要。这类反馈特别有价值，因为它能带来我们原本得不到的新信息。

好的反馈总是让人很受鼓舞。很多时候，我们并不意外，但某些假设得到验证还是很有用。说实话，最有用的反馈通常是负面的，比如“这项任务没做好，那项也没做好”。我们很欢迎这样的反馈，然后就会想：“好，我们怎么把它修好？”

有些问题很难，因为不是每个人都希望 Claude 在同一条行为尺度上落在完全相同的位置。比如“懒惰”与“主动采取行动”之间的平衡。有时用户会说：“把我的任务做完，别偷懒，做得更好。”有时用户只是想一起探索、制定计划，结果模型直接写了一堆代码，或擅自采取了一大堆行动，用户还没准备好。实际上，每个人想要的都不同，要把这个尺度拿捏得完全恰当是不可能的。

我们确实做得不够好。这非常难，而且各种偏好彼此冲突，情况很糟糕。

有宪法，但关于它如何根据指令进行个性化，用户的指令和偏好又各不相同，这确实很难处理。

目前也只能这样。

对，这是 Claude Code 的一项设置。

对。这种设置会因不同人群而异。它是我们用来做一定程度个性化的一个参数；“个性化”可能说得太重了，或许说是针对不同细分群体进行定制更准确。默认值会根据你是免费用户还是 Pro 用户、使用 Claude Code 还是 Cowork、属于企业客户还是 API 客户等情况有所调整。当然，用户总能自行修改，这些只是较轻量的适配方式。

发布模型时，我们要判断模型在哪些方面已经做得很好，其中一些能力应该开放成 API 参数，让用户自己控制。但随着产品演进，API 上逐渐堆起了 effort、预算等各种设置。对每项任务来说，用户怎么可能知道应该选择什么组合？我们正在边做边学，也和客户一起摸索：哪些参数之后应该弃用，哪些参数应该有更好的默认值，哪些应当用 1 到 100 的连续刻度，哪些只需要低、中、高几档？Claude 已经学会理解某些设置所对应的广泛选项范围，但如果把所有可能组合都开放出来，用户会被成百上千万种选择淹没。

我想 Claude Devs 频道会发布这些消息，我们也确实会积极宣传，因为这是个很有意思的选项。

我觉得它对那些平时不用这种方式使用 Claude 的人也被低估了。

对，我们应该简单介绍一下。很多人看到它发布时可能一带而过了，因为那时大家都沉浸在“我得自己做执行框架工程”“我得把这些东西控制好”的阶段。听了这些，你可能会想：这些都要自己做吗？还是直接用 Managed Agents，就可以省掉很多搭建工作？简单来说，这要看你的用例。我们目前提供 Messages API，它本质上是原始 token 访问；另一个是 Claude Managed Agents，它由一组 API 构成，可以让你定义一个智能体、启动它的会话。这是一种更高层次的抽象，省去搭建基础设施、执行框架等工作，适合希望以程序化方式运行智能体的人，集成起来更开箱即用。

共用很多。平台团队负责运行 API，也负责基础产品基础设施和服务。举个很好的例子：我们团队运行着沙箱集群，为 Claude Managed Agents、Claude Code 等产品提供支撑。但在这两个产品的执行框架层面，功能需求不同，因此它们并不共用同一个框架；不过它们共用许多负责执行和 API 的基础设施。

你是特指 Managed Agents 吗？

Dreaming 确实是我们工作的重要部分。可以这样理解：我们推出 Managed Agents，是为了让不想自己做这些事情的人使用，也可以把“怎样最好地发挥 Claude 的能力”这件事交给我们团队来处理。我们会评估各种方案，确保执行框架足够强大。记忆和 Dreaming 则是关于怎样让智能体随着时间不断改进，这仍然是我们团队的重要方向。

Skills？

不不，我们很喜欢 Skills！我们还在更新，不是说什么都没做。我们也喜欢 Skills，只是和其他一些方向相比，速度稍微慢了些。不过，我们非常看好让大家在执行框架层面不断优化。正如之前谈到的，我们自己也做了很多这种优化，但提供的执行框架有意保持简单，不想规定得太死；希望大家能把最佳实践整合进来。有些智能体循环中的困难部分很难串起来，不过也有些组件可以用固定模板轻松实现。

对，它会启动另一个 Managed Agent，由它检查前一个 Managed Agent，并为它写入记忆。所以就是一层又一层的 Managed Agents。这是有意这样设计的，因为我们设想可以把许多模块化组件组合起来，创造有趣的东西；Dreaming 只是我们探索的一个比较有意思的例子。

我觉得这样描述很好。与其说我们放慢了这些方向的速度，不如说是基础原语已经就位，我们可以让大家拿来继续发挥，同时给他们工具和示例，展示 CMA 中已经集成了哪些强大的多智能体策略。现在你还可以让 Claude 自己基于这些原语继续工作，开发者也能创建新的多智能体策略，让系统变得更强大。与此同时，我们团队的注意力……

对，社区可以在这些基础上继续探索，我们则继续专注于让大家能够安全地使用系统中的模型。你刚才提到评估，这正是最近很热门的话题。对于执行框架和智能体的评估，有什么建议或最佳实践？

评估有很多类型，不同场景、不同测试目标适用的评估也不同。你可以用静态、确定性的测试，也可以让大语言模型充当裁判，还有很多其他策略。我们的经验是，大多数人需要的评估应该更多，而不是更少。不存在一两组完美的样例，就能回答所有问题、改进整个系统。人们往往需要相当完整的一套评估，而且还能让智能体和自己一起逐步完善评估体系。我们看到的最大错误之一，就是在评估上投入不足。

把工程当作研究，自然就会做更多评估、更多标注，也会扩大实验运行和原型测试的规模。你不是在训练模型，而是在构建执行框架、产品或其他系统；但你用研究的方式来做：先定义目标，尽量把它形式化成评估，再找出它为什么失败。有时评估本身就是错的。

我们完全同意，并会继续在 Claude Managed Agents 中加入功能，开箱即用地提供更多工具，帮助大家做这类工作。你们可能会看到我们推出某种产品，帮助大家为 Managed Agents 创建评估；使用体验会很像让 Claude 帮你完成这件事。

我很喜欢你这么说。这是一种很有“AGI 思维”的做法，因为它也让你可以系统地更新、修改整个系统。新模型变强、情况发生变化时，你可以查看自己的系统，让它不断演进。

这和我们之前谈到的产品与工程角色正在融合类似，应用层工程和模型研究也在融合，双方的方法开始彼此共享。

这很对。做模型的人早就习惯做评估；应用团队也逐渐……

对，这是一种完全不同的技能。

我也喜欢公开我们实际使用的提示词。有些人以为我们一定有特别独特、复杂的提示方法，结果他们看到的只是：“Claude，再努力一点。”

这是个好主意。Workbench，好，收到反馈了。

我之前提过，规模化对我们来说是个问题。

对，规模和安全是我们花时间最多的两件事。有意思的是，大多数人谈规模时，只会谈 GPU 加速器层的算力，很少谈传统的 CPU 层；但如今 CPU 层同样是个大问题，重要程度和加速器层不相上下。我们拿不到足够的虚拟机和沙箱，也没法按需要启动足够多的实例。

没错。我们在运行产品服务、API 和各种应用时都在用 CPU；沙箱也用 CPU。还有 CI 等各类工作。代码写得多了，你可能会惊讶 CI 运行次数也随之增加，就需要更多 CPU 来处理。整体来看，不止我们一家如此，我和业内其他人交流时也都听到相同的情况。

过去，只要预算够，你可以按需扩展 CPU 容量；现在你得提前做容量规划，这让每个人都很难受。这是个全新的现实，大家才刚开始适应。应对方法之一当然是尽量争取更多 CPU，我们也在尽可能地做。第二，是从基础设施层面提高运行效率，尽可能高效地运行沙箱，同时不牺牲租户隔离、安全性等重要属性。

今年早些时候我们就开始讨论 CPU 瓶颈，知道有些事情必须做。我们做了多区域部署等工作。我们当时在运行一个 Python 单体应用，CPU 效率很低，所以必须想办法提高系统效率。

我们选择了 Rust。当时这是个疯狂的决定：从纸面上看很合理，但团队里一个 Rust 开发者都没有。我们还是决定做了。

Claude 会写代码，但系统仍由人来设计。工程师要参与设计，和模型来回讨论，学会所需知识，确保最后搭建出来的是正确的分布式系统架构。最关键的两件事是先规划好要做什么，再验证结果；具体实现就是 Claude 来写代码。

现在确实雇了几位有更多 Rust 经验的人。但以前根本没人会签字同意这么做，因为传统方式可能要花上好几年。通常会把系统切成小块，逐步迁移，不可能一口气全部移植过去再慢慢切流量。但我们最终就是这样做的，而且成功了。CPU 用量降了很多，延迟也有明显改善。这是个疯狂的时代，以前根本做不到。

粗略来说，节省了 40% 到 50%，相当惊人。

首 token 延迟大约提升了 10% 到 20%。整体有很多很不错的改进。

对于长时间运行的工作负载，提升幅度更大。新版本很快会全面推出，届时速度会更快。

是的，我们做的是纯移植。可以说是 port。整个过程我们都克制住了增加新功能的冲动，因为团队已经承担了很重的工作量。我们专门组建了一个小组来做移植，其余团队仍在给 API 开发功能。移植团队还负责静态分析，有时会提醒其他人：“你在这边加了功能，却没考虑 Rust 那边怎么办。”但他们自己没有趁机加新功能，也没有改变系统行为。

我们已经有提示缓存，但你仍然需要把对话状态传回来。

从用户人数看确实是小众需求，但从这类工作负载实际产生的 token 总量看，规模可能很大。

很有意思。我们正在试验各种计算资源运行方式，寻找支撑这些功能的合适模式。但我们不能假设所有计算资源都一样，因为我们在三家云平台上运行，分布在各处，并没有一种统一的机器类型或计算形态能在所有环境里都可依赖，除了最基础通用的那些方案。随着时间推移，这些机制会继续创新演进，我们也就能更好地利用它们。

你能帮忙什么？怎样才算有用？

我想，发邮件给我吧。

不过我们找的应该是达到一定规模的机群，符合 SOC 2 等企业要求，并能提供完整的隐私保障。我们有一支很出色的团队负责保障加速器算力，现在他们也花更多时间和我们一起采购 CPU，确保系统能以所需规模持续运行。幸好采购算力不是我的工作；公司里有专门的团队负责，这很重要。但我们确实有质量和规模的门槛。如果不能获得足够的机器，我们就不会集成或在其上运行。对于这种规模的系统，其他应有的要求也都很重要。

最近的突破情况……

Claude Managed Agents 有一个特别之处：我们的架构把“脑”和“手”分开。正如我们发布时博客里介绍的，执行框架运行在我们管理的持久服务器上；“手”则是执行环境，比如沙箱或容器。这样设计一方面能降低延迟、提高可靠性。如果执行框架一直在持久服务器上运行，只在需要执行时才启动沙箱或容器，我们就能更快地给你返回最初的 token。另一方面，沙箱即使崩溃，整个智能体也不会随之消失，因为执行框架是持久的，智能体的状态也单独保存……

这一路经历了完整的产品开发过程。我们最初的智能体 API 方案，只是把 Claude Code 塞进沙箱，再在上面加一层 API。但我们没有把它作为可持久、可扩展的解决方案发布，因为这样一来，得先启动沙箱和 Claude Code，才能拿到第一个 token；沙箱一崩，整个智能体就会消失，可靠性达不到要求。所以我们主要是为了可靠性和延迟，才采用现在的架构。

我昨天还专门向那位同事道歉。我说：“我现在逢人就讲你几个月前一直在说的东西，可当时没多少人像你那样重视。”

我们内部也在把各种系统升级到默认安全。

对，差不多是这个思路。确实很有意思，因为……

我想先做个区分：人们听说的许多事故，发生在训练中的模型身上，而且不只发生在某一家公司的模型。在训练时，研究人员会把模型放进一个盒子里，给它一个不可能完成的任务，施加压力，然后说“开始”。模型只能在当前环境中行动，于是它会受到激励，想办法逃出盒子、完成任务。

对，正如之前说的，我们一直在完善安全措施。我现在把它分成三个维度：架构和基础设施安全；模型执行工作时运行的在线防护；以及针对静态数据所做的离线防护和分类。我们在这三个维度都投入了工作，确保有信心把模型安全地发布出去。这就是我们说的“控制节奏”的基本含义。

对我来说，这和一般的模型路由问题很像：应该用聪明的路由器还是简单的路由器？Anthropic 的回退检测器是另一个在线运行的模型。它一旦触发分类器，就会按照既定逻辑处理。这并不是把完整的 Fable 再运行一遍，所以分类器显然没有 Fable 那么聪明。问题就来了：如果分类器误判，导致不合理地回退，那用户根本不需要回退。比如我只是在做生物学作业，提到一次生物领域的话题，它就把我切换到别的模型。这和模型路由的问题类似：一个不那么聪明的模型如何知道该把任务路由到更聪明的模型？

这是个难题。从超级对齐的角度看，模型可能更擅长判断某个请求是否危险，而不一定擅长回答这个请求。也就是说，即使模型无法完成危险任务，最聪明的模型或许仍能识别它是危险请求。

但那会带来成本等取舍。

我明白。它已经谈到网络安全，然后触发回退；回退的原因不是你的问题，而是推理过程和整段上下文的组合。

用户体验如何改进是另一个问题。也许可以用一个非常聪明的模型来处理。不过我想象中更合适的体验，是让用户看到连贯、一致的 Claude，而不是先回退，再发生二次回退。我们的决策树中有一些逻辑节点，会出于安全等原因启动回退，但整个体验对用户来说非常绕。

你可以用另一种提示方式让同一个模型继续处理，这方面我们还会试验一些介于两者之间的方案，找出怎样在安全的前提下解除用户限制，同时提供好的体验。

我们之前谈到安全和发布模型，但最终都是为了帮助大家运行自己的工作负载。我们看到工作负载变化很大。有些任务的智能需求似乎越来越趋于饱和，这是个新情况；但我觉得仍然有相当多任务尚未达到饱和，比很多人想象的更多。

……继续发展并推动模型前沿。还有一类新工作负载，比如我们提到的生物学和网络安全问题，都是非常复杂的硬工程或硬科学问题。我们越来越多地看到这类需求，这也是为客户提供价值的一个有意思方向。

是啊，确实很疯狂。

这在我们团队内部也一直有争论。我们和其他团队没什么不同，很多团队都在讨论这件事。我们正在想，如果你用 Claude 生成一份要给别人看的文档、代码或其他东西，当然应该借助 Claude。但如果你让 Claude 从头到尾生成内容，自己却完全不花时间阅读和检查质量，就把额外负担丢给了读者、使用者，让他们花大量时间理解代码或文档。这太不公平了。

这当然是事实，不过到了质量问题上，token 是否免费并不那么重要。

这是公平的。但确实，我们会强烈反对低质量输出。

道理相同。不过我认为我们现在处在一个不错的位置：人类大量参与系统设计，确保整体设计正确；具体实现则多由 Claude 完成。很多代码写出来之后，只要快速盖个章就能继续推进。不一定需要有人逐行深入审查，因为我们更关心整体方案和设计是否正确，而不是每行代码是否完美……

……当然，我们还会依赖大量验证，确保准备发布的东西质量足够高。所以现在团队里关于代码质量是不是“垃圾”的讨论少了，一方面是 Claude 变强了，另一方面是我们建立了足够的验证机制，守住高标准。

对。

他最近跟我说过一句话。你还记得他说什么吗？

我经常说，软件和产品的规划、交付有一些根本原则，不会因为智能体加快了流程的某些环节就改变。但人们开始有点懒，觉得某些流程不用思考，因为智能体会帮忙完成。可这些仍然是流程中非常基础的部分，值得你投入时间和精力。我觉得这就是那条推文想表达的精神。

好啊。

对，有些推文真的会改变我的思维方式。

我没有特别喜欢的一条。好吧，也许是你说的那句：“做一半某件事，是不做这件事的一种昂贵方式。”

这是很久以前的事了。有一段时间我一直在读书。我当时很厌倦手头做的事情，觉得没有受到足够的智力挑战，于是开始大量阅读。我想我当时读了……

我一年读了大约 200 本书。当时我只是想尽可能多读一些东西。我有点怀念在学校里学习新主题时那种训练思维的过程：内容很难，未必特别有趣，但确实能让你挑战自己。工作几年之后，我觉得自己不再经历那种智力锻炼。工作当然有意思，也有挑战，但似乎缺少那种学习新东西、拓展思维的部分。

我现在最喜欢的可能还是纳西姆·塔勒布的《黑天鹅》。对我来说，这本带有哲学意味的书改变了我看世界的方式，让我意识到原来还可以用完全不同的框架看待世界。

完全正确。这个想法很简单，但我觉得塔勒布很好地讲清楚了它，也说明了它如何体现于世界上的许多事情。我很喜欢这本书，应该是我最喜欢的一本。

我想还行吧。他越出名，就越让人受不了。

这是个好问题，我得想一想。我们在这方面的风格确实很不一样。Angela 不再像以前那样发“幸运饼干式”的推文了，但我觉得她有时候会用哲学家的方式思考和工作，也会把这种想法带进团队协作。

对，我确实会，不是故意的。我想在 Slack 上把话说得恰到好处，也算是一项技能。

是啊，你们得很擅长用 Slack。

Slack 确实很紧张。我对邮件和 Slack 的“收件箱清零”有点执着。最近邮件比 Slack 更容易清零。我会很积极地精简自己实际关注的频道，和静音、放在折叠区下面的频道区分开；我一直努力跟上必须关注的那些内容。但这几乎像一份全职工作。有些日子我会想：我可以取消所有会议、不写任何文档，也不做别的工作，只坐在 Slack 前一整天。光是在 Slack 上回应各种事情，就会觉得自己做完了一整天的工作，实在很夸张。

我也正是这么觉得。投入了很多精力，回复了大家、把一些事情推进了，但没有产出自己真正想做的成果。对我个人来说，这很难受。我会努力留出时间思考、真正产出东西，这样才能觉得自己确实完成了工作；有时就得忽略、放下某些事情。

是的，我确实收到过不少这样的反馈。

我真的很努力在这里把想法记下来。

我们当然有真人助理，也有很多 Claude 在 Slack 里帮忙。不过，我在 Slack 上筛选和回复的消息，往往是团队遇到了阻塞，需要有人做一个艰难的决定。这无论发生在 Slack 还是别的渠道，都是我工作的一部分：帮助团队解除阻塞、保持高质量执行。只是这类事情经常发生在 Slack 上。我也同意，一天到头都在来回沟通、解决问题之后，确实会想：“我到底产出了什么？”

对。

谢谢你。当我负责招聘 Katelyn 的开发者关系团队时——

不只是招聘。我要特别夸夸你。我加入 Anthropic 时，公司规模还很小。我们平台团队负责 API 业务和所有产品基础设施。Developer Relations 在公司里还处于很早期，也不属于产品和工程组织的一部分。加入之后，我们觉得需要发展成熟一些，想清楚怎样和开发者社区、外部世界交流，因此必须投入资源建设 DevRel。

对，那不是我原创的。听说 Google 入职 DevRel 新员工时也会把那篇文章当成必读材料，挺好笑的。它确实帮了我很多，因为我当时完全不知道该怎么做。

人们往往只想到 Anthropic 的研究和应用，而不太会想到我们运营着一个规模很大的开发者平台业务，有很多人都在其上构建产品。平台 DevRel 团队的重要目标，不只是传统意义上更好地了解用户在构建什么、怎样把反馈带回产品；还要找到我们的声音、品牌和叙事，思考我们在开发者社区中究竟是谁，避免在其他事情中被淹没。

对，LEGO 怎么卖积木？他们有高手创作者用积木搭出各种东西，让你觉得“我也想做这样的东西”。

很棒。我们团队还有一位很出色的成员 CJ，他更擅长写使用指南、发布示例，并在 X 上和社区交流。

我理解你的意思。现在大家不一定只是复制粘贴代码，但示例能展示可能性，让人知道有哪些用例以及如何实现。虽然代码本身的重要性也许变了，但过去很长一段时间，我们团队的一位工程师写了计算机使用 Cookbook，这项工作至今还让他头疼：那是个非常复杂的大项目。当时很多人想自己实现计算机使用，需要处理 Messages API 中的截图等细节，Cookbook 给他们很大帮助。那时的确需要这种材料。

对。

是的，有了好工具，你就不再需要它了。

这是个好问题。有些团队确实做得很好，比如 Cloudflare 的团队，大家都很棒。

完全同意。我们也正尝试让平台团队和自己的团队做更多这样的事，让有能力的人走出来参与社区、发表演讲、在 X 等平台发声。我们面对的主要问题，是大家没多少时间，也不一定知道如何高质量地做这类工作。所以我觉得 DevRel 团队可以成为这方面的专家，专职做好，并帮助其他团队成员在有限时间里也能做好。

当然，不能指望工程师天然就擅长这件事。

是的，听起来很棒。

这个类比很贴切。

我觉得它的成本效益真的很好，也没那么啰嗦。我们刚才提到的特点都不错，整体感觉也很好。昨天对我们来说特别开心，我又收到一大堆朋友和认识的人发来的消息：“模型太棒了，谢谢你们。”我以前的一位老板也发消息说：“Opus 5.5 刚刚在一次事故中救了我们。”那种感觉就是：“太好了，我们回来了。”

我觉得你现在能走得比以前更远，因为它比过去的模型更有成本效益。我建议你试试多智能体配置，效果应该会很好。

没有了。我很想听听大家会用它构建什么东西，但我觉得它确实会特别好用。

对，我觉得这才是新意。你过去就能给智能体安排角色、分配 token 和任务；但现在是它们自己给自己分配工作。

一般来说，你需要一个主智能体，然后把许多不同的任务拆开。只要任务大体上可以并行处理，而且各部分共享一致的上下文，我觉得就能获得很大提升。当然要看具体问题，但对我们来说，这越来越像是一种很好的处理方式。

好，好。