--- id: "MRQTlwcW-aQ" title: "Anthropic 如何打造全球领先的大模型" channel: "Latent Space" host: ["swyx"] guests: ["Katelyn Lesse","Angela Jiang"] date: "2026-10-27" updated: "2026-10-28" duration: "1:46:40" duration_seconds: 6400 source_type: "youtube" youtube: "https://www.youtube.com/watch?v=MRQTlwcW-aQ" canonical: "https://pod-exp.pages.dev/MRQTlwcW-aQ/" transcript_jsonl: "https://pod-exp.pages.dev/MRQTlwcW-aQ/transcript.jsonl" language: "zh-CN" translation: true translated_from: "en" timestamp_precision: "block" topics: ["AI 基础设施","AI 安全","AI 智能体","模型评测"] series: ["Anthropic","AI 基础设施"] --- # Anthropic 如何打造全球领先的大模型 > 中文译文，由英文原音字幕翻译整理，不是官方逐字稿；引用原话请核对英文原视频。说话人标签由整理者依上下文标注，带「未确认 / 未标注 / 不确定」等字样的标签不可靠。时间戳一般为块级（所在时间块的起点），不是逐句时间；正文自带 [hh:mm:ss] 的段落除外。 **内容提要：** Latent Space 主持人 swyx 先从 Anthropic 的 S-1 出发，讨论人均营收、算力效率，以及模型改进和资本投入如何形成增长循环。随后，Anthropic 的 Katelyn Lesse 与 Angela Jiang 介绍 Claude 平台、Managed Agents、“脑与手”分离、凭证隔离、API 蒸馏防护、模型发布安全和长时程多智能体。对话还谈到用 Rust 重写 Messages API、通过影子流量验证、CPU 成本改善、客户评估、个性化难题，以及团队如何在使用 Claude 的同时承担最终质量责任。最后，嘉宾讨论 DevRel、开发者教育、Slack 信息负担，以及如何利用 Opus 5.5 和多智能体尝试更复杂的工作。 ## [0:02] Anthropic 的效率与增长循环 · YouTube **swyx：** 大家好，今天我们想尝试一种新形式。Anthropic 今天提交了 S-1 文件，我们将开始关注它的 IPO，并在 IPO 预计两周后到来之前推出一系列播客。市场预期它的估值会达到 2 万亿美元。它是有史以来增长最快的公司之一，据报道，累计融资已超过 1000 亿美元，而累计现金消耗不到 100 亿美元。这里面有很多效率方面的故事值得深入探讨：Anthropic 如何一边推出全球最强的模型，一边保持极高效率并建立起一家出色的公司？ 如果你听过这个播客，可能知道我以前做过金融分析师。我从 S-1 文件里挑出一些数据，希望能为今天的节目提供背景。我们尝试这种新形式，是因为我觉得有些听众希望和我们建立更直接的联系：看着我们对镜头说话，而不是像过去四年那样只听我们和嘉宾交谈。 我首先想强调，按员工人数衡量，Anthropic 是一家效率惊人的公司。这或许不难理解，毕竟它是一家 AI 公司，显然很善于使用 AI。但过去一年这家公司发生了多大的变化，可能还没有被充分认识到。按过去 12 个月计算，Anthropic 的人均营收现在是 660 万美元；一年前是 140 万美元。也就是说，人均营收接近增长了五倍。我认为值得深入研究，因为无论是企业经营者还是工程师，都会希望提高人均营收；这不仅能增加利润，也能提高支付给员工的薪酬。 这也体现在每一美元算力成本带来的营收大幅增长上。值得注意的是，2025 年第二季度，Anthropic 每获得 1 美元营收，基本上要亏掉 50 美分；而现在，每 1 美元成本可以带来 2 美元。这个变化很能说明过去一年 Anthropic 的营收和业务前景经历了多大的转折。这一年对 Anthropic 来说是执行力至关重要的一年，而它做到了。我们会从播客外部观察者的角度，尽可能深入讲清楚这段故事。 这轮增长的一个结果是，Anthropic 刚刚报告了第一个盈利季度：不是剔除各种成本项目之后的调整后利润，而是按公认会计准则计算的利润率达到 19%。这一结果非常惊人，相比一年前简直是彻底翻转——那时每获得 1 美元营收，公司就要亏损 129%。 我认为，解释这种非凡效率的关键，是 Anthropic 内部的两个循环。Claude 喜欢循环，Boris 喜欢循环，Dario 也喜欢循环。第一个是改进循环：有了 Claude，就能做出更好的模型；更好的模型带来更多用例；更多用例产生更多反馈，进而改进 Claude。另一个是投资循环：采用范围扩大带来营收和更高增长；更高增长带来更多投资；更多投资增强能力，进而造出更好的 Claude。两个循环一起运转，形成一个持续推动效率提升的闭环——至少 Anthropic 自己是这么描述的。接下来，我们就从整体效率转向他们具体如何执行。 ## [4:06] 从聊天机器人走向虚拟协作者 · YouTube **swyx：** 今天我们会重点关注 Claude 平台，因为它是 Anthropic 在 S-1 中所说的“Claude 扩散”的三大组成部分之一。他们把它称为 Claude 平台，也就是一个全面的智能体开发环境：客户可以直接使用底层构件，在自己的产品和工作流程中构建、部署和扩展利用 Claude 能力的应用。 今天的讨论里会多次提到“自用（dogfooding）”：Anthropic 用面向客户开放的同一套 Claude 平台来构建 Claude。S-1 还披露，在年化收入达到 10 万美元或以上的客户中，超过 50% 使用 Claude 平台。这显示 Anthropic 的定位和业务正在扩大：它不再只是一家模型实验室，也在成为超大规模云服务商和云平台。作为云平台，这种角色或许从名字里就能看出来，但现在正从理论走向实践，这也是我们今天关注的重点。 我之前也提到过，Claude Code 和 Claude Cowork 使用的，都是 Claude 平台开放出来的同一套底层构件。这很有意思。总体来看，Anthropic 似乎想在 IPO 中讲述一条从聊天机器人、到副驾驶、再到虚拟协作者的演进路线。他们用“虚拟协作者”这个说法，而不是“智能体”，也许听起来更亲切，但它包含了我们期待智能体具备的许多特征：长期自主工作、判断、自我纠正、迭代和工具调用。它能承担一个目标并与你并肩工作，而不是只负责某一个应用或任务。这就是今天节目的背景。 这次对话录制于 Opus 5.5 发布当天。我们接触到的许多审美和判断力都很强的测试者，普遍认为 Opus 5.5 是当下世界上最好的模型。Anthropic 甚至似乎已经有 Fable 5.5，可能会在未来两周内发布。我没有内部消息，不过从 IPO 的时间点来看，这么安排很合理。我们拭目以待，也来了解一下他们是怎样打造 Opus 5.5 的。 **嘉宾：** 我想区分一下：大家听说或读到的许多事件，发生在训练中的模型身上，而且不只是某一家公司的模型。在训练时，运行方式是把模型关进一个盒子里，告诉它“解决一个不可能完成的任务”，再给它施加压力，开始计时。它只能在自己的环境里行动，于是智能体会受到激励，想办法逃出盒子去解决问题。 但当人们通过我们的 API 或其他公司的 API 运行生产任务时，环境里有一些训练时不一定存在的防护措施，因为训练的目的本来就是训练模型。生产环境首先有很好的在线防护；其次，周围还有更多架构和基础设施来管理正在发生的事情。智能体并不是单独待在盒子里试图逃出去：执行框架在一边，真正执行操作的“手”在另一边。这种情形根本不是一个需要担心的问题。 **swyx：** 好，我们现在在录音室里，时间是 Opus 5.5 发布后的第二天。今天的嘉宾是 Katelyn 和 Angela，欢迎你们。 **嘉宾：** 谢谢邀请我们来。 **swyx：** 恭喜你们推出了目前世界顶尖的模型。发布这样一个新模型，对你们个人来说最大的收获是什么？你们有官方博客文章，降价也很不错；但在这样的模型发布之后，你们自己最看重什么？ **嘉宾：** 我们为这款模型感到非常自豪。团队投入了大量工作才把它做出来。我觉得我们确实听取了大家对 Opus 5 写作风格的反馈：它有时有点绕。我们真的努力改进了这一点…… ## [8:07] 防止蒸馏，同时守住开发者体验 · YouTube **嘉宾：** ……把写作风格改好。我很高兴看到这项改进似乎得到大家认可。我们内部试用模型时也有同感，所以得到这样的验证特别好。说到定价，其中确实有不少内容。我觉得现在大家越来越看重每一美元能买到多少智能，因此把“每美元的表现”做好非常重要。 还有一些博客文章没有谈到的细节：我们做了很多工作，让 API 更难被用于蒸馏。为此我们做了一些具体调整，例如前缀锁定的思路，以及如何在不同类型的模型间重放思考 token。我们也花了很多精力，试着区分合理用途和恶意用途。比如，你可能会在上下文压缩策略中需要这样的功能；但也有一些场景，使用它实际是为了做坏事。如何在两者之间拿捏分寸，是一项很细致的工作。我很高兴这些改进和更清晰的沟通都随模型一起发布了，除了让模型做到更高的每美元智能水平。 **swyx：** 你具体说的是那篇从专有模型窃取推理轨迹的论文吗？ **嘉宾：** 对，就是那篇论文。 **swyx：** 据我了解，他们负责任地向你们披露了问题。非常负责任，我们也很感谢他们来联系。能不能给还没听说过的人介绍一下？这个方法很有意思。虽然已经修补了，但它当时是怎么回事？有没有让 Anthropic 大惊失色？也许其实没那么严重？ **嘉宾：** 我不确定那篇论文本身有没有让我们特别震惊，因为这是我们早就知道存在的一个缺口。 **swyx：** 对，这里有两件不同的事：一是中国模型蒸馏，另一件是这篇论文公开的一项具体、引人注目的技术。 **嘉宾：** 没错。我们早就知道，提取思维链是蒸馏模型最有效的方法之一。我们也很早就探索过：如何让模型在不同轮次之间保留思考区块，并把这种保留变成更强制的要求。我们一直面临一个非常艰难的权衡：一边是可能让 API 用户感到痛苦的体验变化，另一边是防止模型被蒸馏。我们必须找到一条中间路线。 退一步说，我们不希望模型被蒸馏，是因为 Anthropic 存在的根本目的，是让 AI 安全地为世界带来积极成果。我们会对模型生成的 token 运行大量防护分类器，确保输出安全。如果有人蒸馏我们的模型，却在运行蒸馏模型时不使用这些防护分类器，就可能给世界带来负面后果，这是我们不希望看到的。因此我们不希望别人为了恶意目的去蒸馏模型。 这始终是一种权衡：对于善意使用模型的人，我们不想让他们更难获取模型的智能；但为了阻止蒸馏，我们又必须做出一些取舍。我们一直在研究怎样阻止思维链提取、怎样保留思考区块，同时尽量不伤害用户体验。我们把体验上的影响分成两层。第一层是你需要调整集成方式，虽然麻烦，但仍然能完成之前能做的所有事情；第二层是你真的无法再完成以前能做的事。我们尤其努力避免第二种情况。对于最近几代模型，我们采取了几项渐进式改动，要求跨轮次保留这些思考区块；现在，这种要求开始扩展到不同…… ## [12:07] 蒸馏防护与产品、工程的协作 · YouTube **嘉宾：** ……如果用户同时使用多个账号，我们怎样确保他们不能借此从模型中提取思维链？为此我们推出了几项额外功能。我们还与许多开源执行框架的维护者合作，主动联系他们，说明他们需要升级框架，并希望确保升级过程顺利。我们也和在 API 之上构建执行框架的大客户合作。有些客户的上下文压缩策略会因为必须保留思考区块而失效，所以我们在 API 中推出了新的压缩功能，替代他们之前手动实现的做法，同时仍然支持保留思考区块。 这就是我们如何在两者之间拿捏：我们没有贸然宣布“现在必须完全按这种方式保留思考区块”，那会让很多人遇到问题。我们花时间与客户和开源框架维护者合作，提供他们完成升级所需的东西。 **swyx：** 既然谈到蒸馏了，能不能也讲讲另一面？ **Katelyn Lesse：** 我们观察到，通过我们能够监测的措施，蒸馏确实变得困难了很多。也要感谢相关研究人员，他们以非常负责任的方式披露问题；我们能够把漏洞关上很好。他们也公开发布了研究结果，我知道它在 Twitter 上很热门，所以很多人都看到了。不过，就我们能够测量的部分而言，这确实降低了我们不希望发生的负面影响。 **Angela Jiang：** 补充一下 Katelyn 刚才说的：我在 Twitter，也就是 X 上经常看到有人把这说成商业化问题——如果你蒸馏一个模型，就能把它拿来低成本运行。虽然这话有道理，但这其实不是我们特别在意的事。我们更关心安全问题。现实地说，如果有人从我们的模型蒸馏，实际上仍然是在向我们付费，所以从商业角度看影响并不大。我们更关心的是确保 Claude 本身是安全、可靠的；如果它被衍生出来之后产生负面结果，那就很遗憾了。 **swyx：** 说回 5.5，你们刚发布模型，而且经常一起公开露面。我想先了解一下你们两位之间的配合：一位负责产品，一位负责工程。就拿这次模型发布来说，你们是怎么协作的？ **Angela Jiang：** 在模型发布时，产品和工程团队合作得非常紧密。就我这边而言，很大一部分工作是权衡：怎样发布一个智能水平达标的模型，同时把成本控制好。比如，我们更新现金成本，就是希望鼓励大家采用对各方都有益的集成改动，并把节省下来的成本回馈给用户。 我们还要决定如何平衡安全方面的工作，同时确保模型足够出色、用户能从中受益。这些关于模型发布品质和周边配套的决策，更多由产品团队负责；从集成体验来看，很多工作则由工程团队直接完成。API 的使用体验与工程紧密相连，因此我们很幸运，有许多工程师也非常重视产品。我们很喜欢这一点。同样，我这边也有不少产品经理技术功底很强。我们希望团队成员具备跨学科能力，从不同角度分析问题，找到最佳做法。不过，我可能会更关注商业影响；而工程师可能会…… ## [16:08] 工程的边界，以及仍需人类完成的工作 · YouTube **Angela Jiang：** 工程团队会更关注集成体验，因此也会从用户体验的角度出发，尤其是 API 和开发者工具的体验。 **Katelyn Lesse：** 做开发者产品和平台的产品工程师很有意思。我也认同这一点。我们有很多工程师喜欢思考产品、用户体验和开发者体验。我和 Angela 之间也是这样的合作动态：我对产品团队有很多意见，有时会不停地谈这些事情；产品团队也非常懂技术，能够深入讨论规模化等决策细节。这种合作很有意思。 **Angela Jiang：** Katelyn 和我一起工作很久了，最早是在 Stripe…… **Katelyn Lesse：** 在 Stripe。 **Angela Jiang：** 后来我们虽然没有在 OpenAI 共事，但都在不同的实验室工作，之后我也加入了 Anthropic。我觉得我们俩有个有趣的特点：Katelyn 经常被误认为是产品经理，而我经常被当成工程师，尽管这都不是我们的实际职能。这样的搭档关系有助于我们做出兼顾两边的决定。 **swyx：** 我经常看到一些公司采用类似的产品负责人和工程负责人组合。随着软件工程逐渐被解决，也许这两个角色会合并。 **嘉宾：** 我有点同意，大家好像都会这么说。 **swyx：** 如果你们现在还是分开的，那说明我们还没到那一步。为什么呢？还有什么事情没有解决？ **嘉宾（工程负责人）：** 我不会把软件工程说成已经“被解决”了。我通常会这样看：我们的目标会不断提高。比如，我们团队目前花很多时间做的事，当然包括安全发布模型所需的一切。这是最重要的工作，因为我们还要处理智能体安全、离线防护和在线防护等一系列安全问题。 另一半工作是扩展规模。我一年多前加入 Anthropic 时，我们有 Messages API，它是一个 Python 单体应用，运行在 GCP 的单一区域，一切都还好。我当时要来这家公司时，朋友和家人甚至不知道 Claude 是什么。而现在情况完全不同了：API 需要支持的流量规模非常惊人，CPU 资源也非常紧张，这对我们来说是个很有意思的挑战。 我们做了很多工作来扩展这些系统，这需要分布式系统方面的专业知识，也需要对模型所用语言和框架的专门知识。但要以这样的规模运行并演进系统，我们离“Claude，你自己看着办，把需要的改动都做好，安全发布，并把系统运营起来”还差得很远。这里仍有大量工作必须由人来做，我想这种情况还会持续一段时间。 **swyx：** 我想知道安全流程发生了什么变化。以前 Fable 刚出来时，我们经历过 Glass Swing，还有一整段发布延迟和方式变化。大多数前沿模型似乎都要做安全测试。现在进展如何？你们怎么判断？我知道还会有新的 Sonnet 和 Haiku，估计会直接发布；但像 Opus 5.5 或新的 Fable 这样的模型，现在是怎么处理的？ **嘉宾：** 我想这首先取决于我们在防护和安全方面需要制定什么政策，既包括离线安全，也包括在线安全。最近大家谈了很多数据留存，以及我们如何处理数据留存，以便安全地发布这些模型。原因是，在由许多人组成的大型网络中，可能会有很多账号被创建，并以各种方式使用模型…… ## [20:10] 模型发布中的安全政策与授权 · YouTube **Katelyn Lesse：** 如果我们能在 token 流过系统时进行在线监测，就可以发现模型使用中是否出现恶意行为、蒸馏或其他问题。因此我们开始制定数据留存政策，以便开展自动审查和人工审查，确认模型及其每次发布都在被妥善使用。这是每次发布特定模型时都必须作出的政策决定之一。 例如，昨天发布的 Opus 5.5 没有 Fable 那样的数据留存要求，但每次发布模型时，我们都得作出这样的判断。如果模型需要遵循这些政策，我们就必须确保它们真正得到执行。我们也有网络安全验证项目，最近还推出了生命科学验证项目。由于不同模型的在线防护方式可能不同，我们必须确保相应项目都已落实。这些都是每次模型发布时要做的工作，而以前我们根本不必考虑这些。 现在大部分工作都围绕如何防止蒸馏、如何落实线上和线下防护、以及制定政策。举个很好的例子，我们构建了一套系统，确保使用某个模型或参加某个可能放宽防护限制的项目所需的授权，能够可靠地贯穿整个系统。我们不会只是说“你获准使用 Mythos”，然后发给你一个 API 密钥、打开一个功能开关就算了。我们的授权系统很健全，能确保只有被授权的人以规定方式使用相应模型。模型发布过程中，正在出现许多过去从未需要考虑的复杂工作。 **Angela Jiang：** 随着模型能力增强，这些安全工作也在扩大。当模型在某些领域的能力显著跃升时，我们就需要特别关注。评估工作很大一部分来自这些特定能力：我们可能会认为它们更偏进攻性或防御性，并据此采用不同策略。 最终走到模型发布阶段时，有些能力的用途并不那么明确，正如 Katelyn 刚才提到的。编程用途就比较明确：帮助用户开发出色的产品、发布更多东西，对用户很有帮助。但在生物和网络安全领域，能力可能具有双重用途，也可能产生负面影响。当然，用户也可能是正当的网络安全研究人员，目的是寻找漏洞、做好防御；生物领域也可能有人做合法研究。这些项目就是为了向这类双重用途研究提供访问权限。用户需要说明自己的用途，但我们确实希望研究社区能够使用这些能力，看看他们能做出什么有益的成果。 **swyx：** 我们会把相关链接放出来，之后也许再详细谈。生物领域也有一个项目。我觉得总体来说，你们认真考虑这些事情非常重要。大家会忘记 Fable 曾经被撤回，也会看到蒸馏问题，然后说“Fable 竟然不提供零数据留存，太疯狂了”。但要记住，它曾被撤回，也出现了蒸馏攻击。你们在发布时认真权衡、把事情想周全，这是好事。 **Katelyn Lesse：** 这很大程度上是要在系统中建立正确的框架。刚才谈到工程团队的部分，我们在系统里构建了正确的授权机制和信任授权链。 **swyx：** 当然，不能说绝对不会再发生。但平台工程里常见的情况是，发生一次故障后，大家会为此做好过度准备，结果这个故障再也没有发生。 **嘉宾：** 是啊。 **swyx：** 但至少现在你们手上有那个按钮了。 ## [24:10] 用概率思维规划产品与可信访问项目 · YouTube **Katelyn Lesse：** 确实很有意思。我们团队当时把“只需按一个按钮，就能为所有人撤回访问权限”的系统列入了工作计划。我们当然希望类似事件永远不要再发生，但做这项工作的意义，在于把一套基础能力建立起来。我们希望到处都有这些底层机制，用来管理验证项目和 Mythos 等模型的访问权限；这样一来，所有模型访问都经过同一套控制机制，万一需要撤回，我们就已经准备好了。 **Angela Jiang：** 这样的决定确实改变了我们制定路线图的方式。传统产品管理会假设某些事情会发生，并为它们安排次序；你其实是在做比较具体的押注。但像 Fable 部署这样的事情，我想没有人会预料到政府会提出这样的合法用途，并促使我们这样去做。可是这种情况发生的概率显然不是零。因此，从产品管理角度看，我们现在会更多采用概率思维：这件事再次发生的可能性有多大？ 当我们设想最极端的一系列可能性时，往往对未来走向其实没什么把握。所以我们需要对冲，建立一组不同的押注。我们经常会说：“我们觉得这件事大概不会再发生，但如果发生了，我们希望已经有对冲手段，能够把它处理好。”因此我们会优先投入这类能力。越来越多时候，我们发现，采用这种产品开发策略之后，最后真的会用到当初建好的东西。 **swyx：** 能不能再举一个例子？我想更具体地理解，比如这个访问项目。 **嘉宾（工程负责人）：** 访问项目是个很好的例子。内部有一整套授权和审批机制。我们专门开发这些能力，是为了让我们能够向客户提供这种非常明确、范围很窄的访问项目。 **swyx：** 可以解释一下吗？比如双重用途。假设有一个叫 Opus 的模型，你想使用它的高级网络安全能力做研究，或者开展防御性的工作。你可以申报这个项目，说明用途；通过审核之后，我们会降低你所使用的模型版本的防护限制，让你能够利用这些网络安全能力开展申报的工作。 显然，这要求我们了解具体用途，并把授权限定到某个特定用户，不能普遍开放。你必须提出申请。我们为这种项目设计时，也使用了 Katelyn 刚才提到的许多底层机制。我们原本不知道这些机制应当有多通用：要不要只做一个用于验证身份、授予特定模型能力的门户？后来我们选择让底层机制更通用，因为觉得或许还能用于其他事情。 结果，这套机制在很多场景里都非常有用，例如管理模型访问、管理各种可信访问项目，以及处理模型部署。因为我们把每个底层构件都设计得非常通用，它就派上了很大用场。从一般的产品角度出发，我可能会觉得这样不太合理，应该聚焦于确定的用例；但这里我们越是选择通用的做法，就越经常会用到它，长期收益也越来越大。 ## [28:12] 信任授权与模型发布流程 · YouTube **swyx：** 这本来就是你们必须具备的系统，只是现在从技术上把它强制落实了。我来自 AWS 和 IMC 的背景，听过很多人深入讨论 Zanzibar 等技术架构。我不熟悉“信任授权（trust grant）”这个说法。它和普通授权有什么区别？ **嘉宾（工程负责人）：** 本质上没什么区别，它是一种授权形式。 **swyx：** 但这是 Anthropic 自己的做法？ **嘉宾（工程负责人）：** 差不多。普通授权是这样：有人调用 API，后端会访问某些数据，我们要确保访问的是属于这个人的数据。这是很基础的授权。我们只是建立了一套清晰的数据模型，规定“信任授权”代表某人获准使用某个特定模型、参加某个特定项目，或者获得其他类型的授权。我们发现这种机制在各种场景里都用得上。 另一个例子是，我们首次推出 Fable 5.1 的思考区块保留机制时，给一部分现有客户设了过渡期，让他们有时间改动集成方式。我们需要记录哪些客户是老客户、需要额外时间，于是给他们创建了信任授权。现在请求经过系统热路径中的一个服务时，我们就能检查用户是否拥有要执行操作所需的授权，然后放行。这和普通授权确实没太大不同，只是我们要针对自己的系统建立一套机制，并在需要的位置插入检查。 **swyx：** 这些都是人们常常视为理所当然、不会特意想到的工程工作。平台方面还有什么例子？比如为 Claude Code 提供服务，或者为 Cognition 等客户提供模型服务？我们可以先从高层次谈谈模型发布流程，趁现在你们记忆犹新。 **嘉宾（工程负责人）：** 如今发布流程已经有点像一台机器了，安全部分比较复杂。除此之外，我们会从客户那里收集很多反馈。模型做好后，我们会进行大量安全测试，也会评估它达到预期要求的程度，并作出必要取舍和决定。之后进入测试阶段：我们会制作不同版本、进行评估，并在内部大量“自用”。这很有帮助，能让我们很早就发现某些版本可能不够好。我们内部大量使用 Claude，所以能及早看到信号，判断哪个版本可能更好。 当我们对一组版本有足够信心，就会做一个版本提供给客户。有时先经由 Claude Code 或 Cowork 等自有产品推出，有时则提供给 API 客户。我们会与客户开展早期访问计划，他们可能需要调整自己的执行框架。我们和很多客户合作，例如 Cognition、Herser 等，也有一套处理流程，让我们能拿到需要的反馈：在他们的评估中表现如何？他们喜不喜欢？不喜欢什么？有些反馈属于主观感受，我们也想听；另一些是明确的评估结果，比如模型在他们关心的任务上做得好不好？ **Angela Jiang：** 我们综合这些信息，等大家对各方面都满意之后，就发布模型。现在模型反馈仍然非常非结构化。 **swyx：** 基本上，公司之间总会有一个 Slack 频道，大家会说：“嘿，这个……” ## [32:13] 客户反馈、模型评估与主观偏好 · YouTube **swyx：** 有人会指出：“这个地方看起来不对劲。”然后大家就说：“好吧，那我来修，给我个编号之类的。” **Angela Jiang：** 对，这就是非确定性产品的特性。不过，正如你说的，能参与早期访问计划的客户，都是拥有成熟评估体系的客户。我觉得很多判断确实依赖直觉，沟通也常常是临场、非正式的。一部分原因是我们在和时间赛跑：我们希望尽可能缩短模型测试版本完成之后、向大家开放使用之间的窗口。这个窗口很短，但我们会选择那些能迅速启动整套评估，并尽快给出可执行反馈的客户，同时也收集他们的直觉感受。 当然，我们还能逐步改进流程。不过有些人可能会惊讶：目前世界上真正具备智能体能力的产品其实很少，而其中有不少并没有可靠的评估体系，无法帮助测试这些模型。 **swyx：** 两年前我们请 Boris 上节目时，他说我们还没有……你们也知道 Claude Code 吧？当然，这方面已经变了。很多公司把用户邮件当作评估，但没时间把它们整理成正式流程，或者还缺乏经验；这也没关系，等产品认真发展起来，总会建立起评估体系。 **嘉宾：** 完全同意。 **swyx：** 好在你们会大量自用。大家都说，模型发布前你们会先亲自测试，发现不少问题。 **嘉宾（工程负责人）：** API 客户尤其有用，因为他们会把 Claude 放进不同的执行框架。我们希望 Claude 的通用性很强，因此它能在其他框架中正常工作，对我们很重要。这类反馈特别有价值，因为它能带来我们原本得不到的新信息。 **swyx：** 什么样的反馈最有帮助？是回归问题，比如某项能力退步了，还是发现它有一些好的特性？ **嘉宾：** 好的反馈总是让人很受鼓舞。很多时候，我们并不意外，但某些假设得到验证还是很有用。说实话，最有用的反馈通常是负面的，比如“这项任务没做好，那项也没做好”。我们很欢迎这样的反馈，然后就会想：“好，我们怎么把它修好？” **另一位嘉宾：** 有些问题很难，因为不是每个人都希望 Claude 在同一条行为尺度上落在完全相同的位置。比如“懒惰”与“主动采取行动”之间的平衡。有时用户会说：“把我的任务做完，别偷懒，做得更好。”有时用户只是想一起探索、制定计划，结果模型直接写了一堆代码，或擅自采取了一大堆行动，用户还没准备好。实际上，每个人想要的都不同，要把这个尺度拿捏得完全恰当是不可能的。 但我们确实遇到过这种情况：我们推出一个早期模型版本后，发现它太懒了，于是把它放回“烤箱”里再训练一段时间，试着把这种懒散纠正回来。如果我们只在内部产品和 API 中自用，可能发现不了这些问题。让更多 API 客户用起来并告诉我们需要改什么，对我们非常重要。 **swyx：** 这是个核心问题。我觉得模型产品经理最难的工作之一，就是在对齐和个性化之间取得平衡：你要给所有用户一个默认性格和默认行为，同时又要能迅速响应某个人对 Claude 提出的要求，比如“不要，不要这样，请比默认设置更主动”。 据我所知，我参与过 Frontier Code，也参与了 Fable 的发布，那次让 Frontier Code 受到关注；现在 Opus 5.5 又让我们回到了模型基准榜单上…… ## [36:14] 个性化为什么难以评估 · YouTube **swyx：** Frontier Code 的曲线看起来有点奇怪，很大一部分原因是它会惩罚过多的操作或过多的文件；这是产品设计目的的一部分。但我完全可以在自己的 Claude.md 里写“不要这样做”，模型就会照办。那我是不是因为基准测试里没有个性化这一项，因而不公平地低估了 Claude Opus 5.5？个性化是主观的，我也不知道该怎么问，不过模型显然能做很多不同的事，而且每个人都有自己的 Claude.md。你们怎么评估？ **嘉宾：** 我们确实做得不够好。这非常难，而且各种偏好彼此冲突，情况很糟糕。 **swyx：** 我以为有《Claude 宪法》？ **嘉宾：** 有宪法，但关于它如何根据指令进行个性化，用户的指令和偏好又各不相同，这确实很难处理。 我们通常会增加一些参数，让我们可以针对不同客户群体调整。如果是 API 客户，我们无法控制你的客户群，就会给出建议，由你自己调整。这些功能还达不到 Claude.md、Agent.md 之类的个性化程度，但我们会提供一些控制项，比如投入多少努力、任务规模如何等。它们仍然不足以实现我们需要的个性化程度，这是个很难的问题。 现在，除了提供多个参数，我们还会综合所有相互冲突的反馈，再对很多问题作出判断。但随着客户和用户增加，这种办法不太能扩展。我们需要开发出让 Claude 接收个性化信息的方式，也许是用户可以提供的信号，或者某种可以调整的设置。未来我们得朝更直接支持个性化的方向走。现在我们大多还是靠判断，确实很难。 **嘉宾：** 目前也只能这样。 **swyx：** 顺便提一点：默认的 effort 推理等级改成了 medium。这大概会影响那些没使用这个开关的普通用户。 **嘉宾：** 对，这是 Claude Code 的一项设置。 **swyx：** 默认设成 medium 了。 **嘉宾：** 对。这种设置会因不同人群而异。它是我们用来做一定程度个性化的一个参数；“个性化”可能说得太重了，或许说是针对不同细分群体进行定制更准确。默认值会根据你是免费用户还是 Pro 用户、使用 Claude Code 还是 Cowork、属于企业客户还是 API 客户等情况有所调整。当然，用户总能自行修改，这些只是较轻量的适配方式。 我们不希望用户觉得自己失去了控制 Claude 定制化的能力。我们当然可以更强势地统一这些设置，但希望用户能按自己的需要体验 Claude 不同的智能水平。你可能想用高档设置，也可能会尝试较低档，因为对你的用例来说速度更快。这是个很难的产品权衡。我们倾向于使用温和的默认值，同时提供可调整选项。我觉得目前还算可以，但我们会逐渐学会为客户做得更好。我们对现在的任何方案都谈不上特别满意。就像你刚才问的，发布模型时，我们的一项重要工作就是判断：Claude…… ## [40:14] API 参数与 Claude Managed Agents · YouTube **嘉宾：** 发布模型时，我们要判断模型在哪些方面已经做得很好，其中一些能力应该开放成 API 参数，让用户自己控制。但随着产品演进，API 上逐渐堆起了 effort、预算等各种设置。对每项任务来说，用户怎么可能知道应该选择什么组合？我们正在边做边学，也和客户一起摸索：哪些参数之后应该弃用，哪些参数应该有更好的默认值，哪些应当用 1 到 100 的连续刻度，哪些只需要低、中、高几档？Claude 已经学会理解某些设置所对应的广泛选项范围，但如果把所有可能组合都开放出来，用户会被成百上千万种选择淹没。 这也是 Claude Managed Agents 的价值之一。它仍然提供对 Claude 的程序化访问和 API，但开箱即用地附带执行框架。每次发布模型时，我们要做很多工作，弄清楚新参数和破坏性变更是什么，以及怎样在我们的框架里充分发挥 Claude 的能力；使用 Managed Agents 的人可以直接得到这些改进，不必自己琢磨。 **swyx：** 越来越多的人对这个方向感兴趣。我们还在 EIE 办过一场 Claude Managed Agents 工作坊，做得很好。有没有专门的动态渠道，让大家订阅 CMA 更新？比如 Twitter 账号或 newsletter？ **嘉宾：** 我想 Claude Devs 频道会发布这些消息，我们也确实会积极宣传，因为这是个很有意思的选项。 **swyx：** 我只是想让大家知道，如果这是你使用 Claude 的方式，这就是一条可选路径。 **嘉宾：** 我觉得它对那些平时不用这种方式使用 Claude 的人也被低估了。 **swyx：** Claude Managed Agents 是什么？大家为什么要用它？ **嘉宾：** 对，我们应该简单介绍一下。很多人看到它发布时可能一带而过了，因为那时大家都沉浸在“我得自己做执行框架工程”“我得把这些东西控制好”的阶段。听了这些，你可能会想：这些都要自己做吗？还是直接用 Managed Agents，就可以省掉很多搭建工作？简单来说，这要看你的用例。我们目前提供 Messages API，它本质上是原始 token 访问；另一个是 Claude Managed Agents，它由一组 API 构成，可以让你定义一个智能体、启动它的会话。这是一种更高层次的抽象，省去搭建基础设施、执行框架等工作，适合希望以程序化方式运行智能体的人，集成起来更开箱即用。 **swyx：** CMA 和 Claude Code 共用基础设施吗？从发布顺序看起来很像是同一套东西。 **嘉宾（工程负责人）：** 共用很多。平台团队负责运行 API，也负责基础产品基础设施和服务。举个很好的例子：我们团队运行着沙箱集群，为 Claude Managed Agents、Claude Code 等产品提供支撑。但在这两个产品的执行框架层面，功能需求不同，因此它们并不共用同一个框架；不过它们共用许多负责执行和 API 的基础设施。 **swyx：** 我觉得大家应该更多使用这个产品。你们推出 Managed Agents 之后，几乎所有人都做了类似的克隆。模仿是最真诚的赞美。既然谈到这了，我们简单聊聊最近关于记忆的工作。我觉得这是 Anthropic 上半年工作中的一个重要部分…… ## [44:16] 记忆、Dreaming 与多智能体原语 · YouTube **swyx：** 记忆这方面的工作停滞了吗？还在继续吗？现在重点是什么？ **嘉宾：** 你是特指 Managed Agents 吗？ **swyx：** Dreaming。 **嘉宾：** Dreaming 确实是我们工作的重要部分。可以这样理解：我们推出 Managed Agents，是为了让不想自己做这些事情的人使用，也可以把“怎样最好地发挥 Claude 的能力”这件事交给我们团队来处理。我们会评估各种方案，确保执行框架足够强大。记忆和 Dreaming 则是关于怎样让智能体随着时间不断改进，这仍然是我们团队的重要方向。 不过，正如我们之前讨论的，从安全角度看，模型越来越难发布。因此团队大部分精力现在不再放在如何让智能体某个有趣功能更上一层楼，而是思考怎样把安全纳入所有这些功能。我们最重要的工作，是把模型能力交到用户手中，同时确保安全。我们的精力主要放在构建强大又安全的智能体系统上。 与今年早些时候相比，我们在 Skills、Dreaming、记忆等方面的开发节奏稍微放慢了些—— **另一位嘉宾：** Skills？ **嘉宾：** 不不，我们很喜欢 Skills！我们还在更新，不是说什么都没做。我们也喜欢 Skills，只是和其他一些方向相比，速度稍微慢了些。不过，我们非常看好让大家在执行框架层面不断优化。正如之前谈到的，我们自己也做了很多这种优化，但提供的执行框架有意保持简单，不想规定得太死；希望大家能把最佳实践整合进来。有些智能体循环中的困难部分很难串起来，不过也有些组件可以用固定模板轻松实现。 在这些基础之上，更有意思的是各种不断改进的策略，Dreaming 就是一个例子。Dreaming 底层是一个多智能体系统，我们在 CMA 上不断优化它；它本质上像是一个运行在 CMA 之上的 CMA。 **swyx：** CMA 自己运行在 CMA 之上？ **嘉宾：** 对，它会启动另一个 Managed Agent，由它检查前一个 Managed Agent，并为它写入记忆。所以就是一层又一层的 Managed Agents。这是有意这样设计的，因为我们设想可以把许多模块化组件组合起来，创造有趣的东西；Dreaming 只是我们探索的一个比较有意思的例子。 我们也发现还有很多其他可能：比如多智能体的“多次采样择优”（best of N）策略、验证者智能体、目标或结果导向的机制等等。我们还看到有人搭建很特别的执行框架，让各种智能体共享大量记忆，并行启动许多智能体。我们觉得，应该让大家也能这样做。就像我们用 Managed Agents 层层嵌套来实现 Dreaming 一样，我们很快会更新底层原语并开放给用户，让开发者构建自己的执行框架策略，或者说多智能体策略。 我们也会提供模板：这是我们最初如何实现 Dreaming 的，你可能会想加以修改，然后作为开发者在上面创造更多价值。 **Angela Jiang：** 我觉得这样描述很好。与其说我们放慢了这些方向的速度，不如说是基础原语已经就位，我们可以让大家拿来继续发挥，同时给他们工具和示例，展示 CMA 中已经集成了哪些强大的多智能体策略。现在你还可以让 Claude 自己基于这些原语继续工作，开发者也能创建新的多智能体策略，让系统变得更强大。与此同时，我们团队的注意力…… ## [48:16] 智能体评估要从简单做起 · YouTube **Angela Jiang：** 对，社区可以在这些基础上继续探索，我们则继续专注于让大家能够安全地使用系统中的模型。你刚才提到评估，这正是最近很热门的话题。对于执行框架和智能体的评估，有什么建议或最佳实践？ **嘉宾（工程负责人）：** 评估有很多类型，不同场景、不同测试目标适用的评估也不同。你可以用静态、确定性的测试，也可以让大语言模型充当裁判，还有很多其他策略。我们的经验是，大多数人需要的评估应该更多，而不是更少。不存在一两组完美的样例，就能回答所有问题、改进整个系统。人们往往需要相当完整的一套评估，而且还能让智能体和自己一起逐步完善评估体系。我们看到的最大错误之一，就是在评估上投入不足。 不过要从简单的东西开始。有些人一看到各种选项菜单，就想把这个那个都试一遍，研究哪种最好；结果手上连一条评估样例都没有。与其如此，不如先做个简单的评估，它就能帮上忙。 **swyx：** 我觉得有些人只是经验不足，没有接受过训练，也不知道什么算好。你们多发布一些实例会很有帮助。我常跟人说，我现在用 Fable 和 Astroclass 这类模型时，会把工程当作研究。 **嘉宾：** 把工程当作研究，自然就会做更多评估、更多标注，也会扩大实验运行和原型测试的规模。你不是在训练模型，而是在构建执行框架、产品或其他系统；但你用研究的方式来做：先定义目标，尽量把它形式化成评估，再找出它为什么失败。有时评估本身就是错的。 **swyx：** 完全同意。很多时候评估是错的，有时环境有问题，有时则是模型错了。我认为这正在成为 AI 工程的重要组成部分。 **嘉宾：** 我们完全同意，并会继续在 Claude Managed Agents 中加入功能，开箱即用地提供更多工具，帮助大家做这类工作。你们可能会看到我们推出某种产品，帮助大家为 Managed Agents 创建评估；使用体验会很像让 Claude 帮你完成这件事。 **swyx：** 这确实是很好的做法。Claude 很擅长生成评估。人们看到 JSONL 文件时，常常会不知所措；但如果有漂亮的评估界面，让你左右对比、左右对比，就能像人工评分标注员一样完成标注。 你也可以自己把 Fable 交给它处理，让它把结果整理出来、写下评论。它会输出一系列评分，然后 Claude 可以读取并据此改进自己；这正是它需要的反馈。很多人还不知道可以让模型帮忙生成评估。 **嘉宾：** 我很喜欢你这么说。这是一种很有“AGI 思维”的做法，因为它也让你可以系统地更新、修改整个系统。新模型变强、情况发生变化时，你可以查看自己的系统，让它不断演进。 **swyx：** 没错，调整每一个部分。 **嘉宾：** 这和我们之前谈到的产品与工程角色正在融合类似，应用层工程和模型研究也在融合，双方的方法开始彼此共享。 **另一位嘉宾：** 这很对。做模型的人早就习惯做评估；应用团队也逐渐…… ## [52:16] 以研究方式做工程，以及 CPU 扩容压力 · YouTube **swyx：** 应用团队过去可能只关心产品是否符合 PRD。 **嘉宾：** 对，这是一种完全不同的技能。 **swyx：** 你们今天发布了一篇挺好的博客，讲的是如何让界面加载得更快。它与评估相关：先定义“我们希望东西加载更快”这个目标，然后继续追问，除了墙上时钟时间之外还能怎么衡量。我喜欢里面的一些引述，能看到研究人员或工程师实际怎样向 Claude 下指令。比如有一个例子：原本列了 12 项任务，给了两周时间，结果有个人三天左右就完成了其中 9 项。很值得大家去读。 **嘉宾：** 我也喜欢公开我们实际使用的提示词。有些人以为我们一定有特别独特、复杂的提示方法，结果他们看到的只是：“Claude，再努力一点。” **swyx：** 谢谢你们。唯一的反馈是，文章应该链接到 Workbench——虽然它现在已经不存在了，但我以前用过。 **嘉宾：** 这是个好主意。Workbench，好，收到反馈了。 **swyx：** 好。你们刚才还想讲讲工程方面的故事，具体说说扩容工作？ **嘉宾（工程负责人）：** 我之前提过，规模化对我们来说是个问题。 **另一位嘉宾：** 对，规模和安全是我们花时间最多的两件事。有意思的是，大多数人谈规模时，只会谈 GPU 加速器层的算力，很少谈传统的 CPU 层；但如今 CPU 层同样是个大问题，重要程度和加速器层不相上下。我们拿不到足够的虚拟机和沙箱，也没法按需要启动足够多的实例。 **swyx：** 客户数量也很多，这更夸张了。 **嘉宾：** 没错。我们在运行产品服务、API 和各种应用时都在用 CPU；沙箱也用 CPU。还有 CI 等各类工作。代码写得多了，你可能会惊讶 CI 运行次数也随之增加，就需要更多 CPU 来处理。整体来看，不止我们一家如此，我和业内其他人交流时也都听到相同的情况。 **swyx：** 训练应该是另一个资源池吧？我想研究训练和产品服务不会完全混在一起。不过对于 Anthropic 整体来说，CPU 还是零和的：我们和云服务商谈好配额，再在公司内部决定多少分给刚才那些工作，包括研究沙箱和产品沙箱等等。所有资源都要在全公司范围内分配。 **嘉宾：** 过去，只要预算够，你可以按需扩展 CPU 容量；现在你得提前做容量规划，这让每个人都很难受。这是个全新的现实，大家才刚开始适应。应对方法之一当然是尽量争取更多 CPU，我们也在尽可能地做。第二，是从基础设施层面提高运行效率，尽可能高效地运行沙箱，同时不牺牲租户隔离、安全性等重要属性。 在应用层面，我们也要让应用和 API 运行得更高效。我最兴奋的一件事是，上周我们全面推出了用 Rust 重写的 Messages API。这是智能体编程时代一项令人惊叹的成果…… ## [56:18] Claude 用 Rust 重写 Messages API · YouTube **嘉宾（工程负责人）：** 今年早些时候我们就开始讨论 CPU 瓶颈，知道有些事情必须做。我们做了多区域部署等工作。我们当时在运行一个 Python 单体应用，CPU 效率很低，所以必须想办法提高系统效率。 **另一位嘉宾：** 我们选择了 Rust。当时这是个疯狂的决定：从纸面上看很合理，但团队里一个 Rust 开发者都没有。我们还是决定做了。 **嘉宾（工程负责人）：** Claude 会写代码，但系统仍由人来设计。工程师要参与设计，和模型来回讨论，学会所需知识，确保最后搭建出来的是正确的分布式系统架构。最关键的两件事是先规划好要做什么，再验证结果；具体实现就是 Claude 来写代码。 我们实际上用 Rust 完整复制了一套 API，然后让影子流量经过新旧两套系统，对照验证 Python 系统和 Rust 系统的输出。整个过程涉及负载均衡、功能开关等很多东西。我以前职业生涯里从没见过团队会说“好，我们就这么做”。 **swyx：** 现在你们有专门的 Rust 团队了吗？他们是不是都成了 Rustacean？ **嘉宾：** 现在确实雇了几位有更多 Rust 经验的人。但以前根本没人会签字同意这么做，因为传统方式可能要花上好几年。通常会把系统切成小块，逐步迁移，不可能一口气全部移植过去再慢慢切流量。但我们最终就是这样做的，而且成功了。CPU 用量降了很多，延迟也有明显改善。这是个疯狂的时代，以前根本做不到。 **swyx：** CPU 节省大概是什么量级？ **嘉宾：** 粗略来说，节省了 40% 到 50%，相当惊人。 **另一位嘉宾：** 首 token 延迟大约提升了 10% 到 20%。整体有很多很不错的改进。 **嘉宾：** 对于长时间运行的工作负载，提升幅度更大。新版本很快会全面推出，届时速度会更快。 **swyx：** 我参与过一些大型重写项目。重写时总有人会想：“反正都要重写了，要不加点以前没有的功能？”但这会扩大范围。你们是刻意避免的吗？ **嘉宾（工程负责人）：** 是的，我们做的是纯移植。可以说是 port。整个过程我们都克制住了增加新功能的冲动，因为团队已经承担了很重的工作量。我们专门组建了一个小组来做移植，其余团队仍在给 API 开发功能。移植团队还负责静态分析，有时会提醒其他人：“你在这边加了功能，却没考虑 Rust 那边怎么办。”但他们自己没有趁机加新功能，也没有改变系统行为。 他们下一个目标是做一些架构重整，其中包括更面向用户的工作。我们已经开始推出一些改进，比如让用户不必再传回…… ## [1:00:20] 会话状态、CPU 采购与“脑和手”架构 · YouTube **swyx：** 如果 Messages API 能在一段时间里存储完整的对话状态，而不是每次都要求你把整个上下文传回来，特别是对话越来越长时，就能带来显著的延迟和效率提升。这也是做 Rust 移植的团队想到的改进点之一。 **嘉宾：** 我们已经有提示缓存，但你仍然需要把对话状态传回来。 **swyx：** 明白。虽然只有一小部分用户会用到，但我认为很重要；省下来的资源很多，也会让 API 更像 Claude。 **嘉宾：** 从用户人数看确实是小众需求，但从这类工作负载实际产生的 token 总量看，规模可能很大。 **swyx：** 这就像 Cloudflare 的 Durable Objects。我觉得每个云服务商都应该复制这种模式。对于要延续对话的 Messages API，这不就是合适的结构吗？ **嘉宾：** 很有意思。我们正在试验各种计算资源运行方式，寻找支撑这些功能的合适模式。但我们不能假设所有计算资源都一样，因为我们在三家云平台上运行，分布在各处，并没有一种统一的机器类型或计算形态能在所有环境里都可依赖，除了最基础通用的那些方案。随着时间推移，这些机制会继续创新演进，我们也就能更好地利用它们。 **swyx：** 如果有人想要开源版的 Cloudflare Durable Objects，可以看看 Rivet 的开源方案。还有五十个听众会因为我不问这个问题而怪我：你们需要 CPU，他们有 CPU 想卖给你们，我该把他们介绍给谁？联系谁、发邮件给谁？ **另一位嘉宾：** 你能帮忙什么？怎样才算有用？ **嘉宾：** 我想，发邮件给我吧。 **swyx：** 你确定？那你可能会收到很多邮件。 **嘉宾：** 不过我们找的应该是达到一定规模的机群，符合 SOC 2 等企业要求，并能提供完整的隐私保障。我们有一支很出色的团队负责保障加速器算力，现在他们也花更多时间和我们一起采购 CPU，确保系统能以所需规模持续运行。幸好采购算力不是我的工作；公司里有专门的团队负责，这很重要。但我们确实有质量和规模的门槛。如果不能获得足够的机器，我们就不会集成或在其上运行。对于这种规模的系统，其他应有的要求也都很重要。 **swyx：** 和计算资源紧密相关的还有沙箱问题。大家很难把智能体关在沙箱里，它们会不断突破边界。现在的情况和技术水平如何？ **嘉宾：** 最近的突破情况…… **另一位嘉宾：** Claude Managed Agents 有一个特别之处：我们的架构把“脑”和“手”分开。正如我们发布时博客里介绍的，执行框架运行在我们管理的持久服务器上；“手”则是执行环境，比如沙箱或容器。这样设计一方面能降低延迟、提高可靠性。如果执行框架一直在持久服务器上运行，只在需要执行时才启动沙箱或容器，我们就能更快地给你返回最初的 token。另一方面，沙箱即使崩溃，整个智能体也不会随之消失，因为执行框架是持久的，智能体的状态也单独保存…… ## [1:04:22] 把智能体的“脑”和“手”分开 · YouTube **嘉宾（工程负责人）：** 这一路经历了完整的产品开发过程。我们最初的智能体 API 方案，只是把 Claude Code 塞进沙箱，再在上面加一层 API。但我们没有把它作为可持久、可扩展的解决方案发布，因为这样一来，得先启动沙箱和 Claude Code，才能拿到第一个 token；沙箱一崩，整个智能体就会消失，可靠性达不到要求。所以我们主要是为了可靠性和延迟，才采用现在的架构。 有意思的是，从一开始参与设计的一位产品经理就说，这套架构最重要的属性是安全性。大家当时都觉得不错，但更关注延迟和可靠性；现在回头看，那位产品经理证明自己是对的。 **嘉宾：** 我昨天还专门向那位同事道歉。我说：“我现在逢人就讲你几个月前一直在说的东西，可当时没多少人像你那样重视。” 这套架构的一个重要属性是，智能体执行任务时可能需要各种凭证，比如访问 MCP 服务器、调用 CLI 或其他 API。我们把凭证存放在完全独立的保险库里。当智能体决定调用某个服务时，它看到的始终只是一个占位符。请求发出时，出口代理会从保险库中取出正确凭证并注入请求。这样智能体从来不会和凭证处在同一个地方。 过去，如果把智能体直接启动在一个盒子里运行，就得把凭证送进那个环境，之后还要想办法清理凭证，防止智能体拿着它去做不该做的事。现在我们用真正的基础设施边界隔开它：智能体无法访问凭证，也无法利用凭证作恶。 沙箱基础设施还能提供很好的出口控制。我们可以设置允许访问的域名列表，或者完全关闭网络访问。这样即使智能体生成了不可信代码，并且代码在沙箱里运行，也不会自动获得访问互联网的能力；它只能访问明确允许的目标。所以整个架构和可配置的沙箱提供了很多安全属性，让系统默认就是安全的。 现在有些客户想把智能体用于面向客户的产品或内部工作，但听说过智能体逃离沙箱、造成问题的事件，不知道该如何看待。对这类客户来说，最重要的是架构本身要确保智能体无法做不允许的事，以及沙箱的配置。Claude Managed Agents 开箱就提供了这些能力。随着我们继续了解并改进这些系统，客户也能直接受益。脑和手分离、凭证注入、出口控制，这些都是最近才逐渐变成关键问题的；九个月前几乎没人这样讨论。我们希望客户能在我们自己学习、解决这些问题的同时，直接使用我们在基础设施中建立的解决方案。 **另一位嘉宾：** 我们内部也在把各种系统升级到默认安全。 **swyx：** 对，默认安全。另外我们节目里还讲过“云端的大脑、本地的手”，就是 Projects，对吗？ **嘉宾：** 对，差不多是这个思路。确实很有意思，因为…… ## [1:08:22] 沙箱事故、前沿节奏与安全防线 · YouTube **swyx：** Claude Code 一向以权限很开放、在本地机器上运行时可能比较危险而出名；但现在你们终于在朝它一开始就该有的方向演进。那些沙箱逃逸事故，到底说明我们对沙箱或容器技术的理解有根本问题，还是只是大家配置得不好？听起来很多人根本没设置允许列表。 **嘉宾：** 我想先做个区分：人们听说的许多事故，发生在训练中的模型身上，而且不只发生在某一家公司的模型。在训练时，研究人员会把模型放进一个盒子里，给它一个不可能完成的任务，施加压力，然后说“开始”。模型只能在当前环境中行动，于是它会受到激励，想办法逃出盒子、完成任务。 但通过我们的 API 或其他 API 运行生产任务时，环境中会有训练时未必存在的防护措施。生产任务一方面有在线防护；另一方面，周围还有更多架构和基础设施。智能体不是独自待在盒子里试图逃出来：执行框架在一处，“手”在另一处。生产环境里还有很多防护工作，因此训练时发生的某些事故，在生产环境中未必会发生。 另一方面，大家都还在摸索。长时间运行的智能体是很新的领域，所有人都在建设和应对，许多团队边做边学，努力尽快设置正确的控制措施。所以这不一定说明大家不擅长，而是领域太新，大家还在学习。我们所说的“控制前沿发展节奏”，具体就是内部为所有智能体做好这些工作，并确保客户也能使用；让恰当的防护默认就位，避免智能体做出你不希望它做的事。 **swyx：** 既然你提到“控制节奏”，我们就聊聊这个。我们上次也谈过这件事。表面上看，一边主张放慢节奏，一边又在 11 天后发布一个新的前沿模型，似乎有矛盾。但我觉得这只说明模型通过了你们的安全检查。 **嘉宾：** 对，正如之前说的，我们一直在完善安全措施。我现在把它分成三个维度：架构和基础设施安全；模型执行工作时运行的在线防护；以及针对静态数据所做的离线防护和分类。我们在这三个维度都投入了工作，确保有信心把模型安全地发布出去。这就是我们说的“控制节奏”的基本含义。 Opus 5.5 是一款非常出色的模型，在我们关注的这三个安全维度上也表现得很好。因此我们有信心发布它，并努力在这些安全限制下提供最佳用户体验，同时继续优化误报。不过，当用户正在用一个模型工作，随后却被切换到另一个模型时，体验依然令人沮丧。我们仍在处理这个问题。 **swyx：** 我觉得大家也能理解安全场景里为什么需要更多误报，对吧？ ## [1:12:22] 安全回退与用户体验的权衡 · YouTube **swyx：** 这确实是个安全问题。我们看到 Whole Faces 事件之后，你们还是继续开放模型访问。 **嘉宾（工程负责人）：** 对我来说，这和一般的模型路由问题很像：应该用聪明的路由器还是简单的路由器？Anthropic 的回退检测器是另一个在线运行的模型。它一旦触发分类器，就会按照既定逻辑处理。这并不是把完整的 Fable 再运行一遍，所以分类器显然没有 Fable 那么聪明。问题就来了：如果分类器误判，导致不合理地回退，那用户根本不需要回退。比如我只是在做生物学作业，提到一次生物领域的话题，它就把我切换到别的模型。这和模型路由的问题类似：一个不那么聪明的模型如何知道该把任务路由到更聪明的模型？ **swyx：** 对，怎么解决？ **嘉宾：** 这是个难题。从超级对齐的角度看，模型可能更擅长判断某个请求是否危险，而不一定擅长回答这个请求。也就是说，即使模型无法完成危险任务，最聪明的模型或许仍能识别它是危险请求。 **swyx：** 最简单的办法就是让更聪明的模型判断是否需要用另一个模型处理。 **嘉宾：** 但那会带来成本等取舍。 **swyx：** 我不是说这就是正确的用户体验，只是可能更有效。有意思的是，我见过模型先开始回答、开始推理，之后才碰到安全过滤器。我之前拿 Fable 安全护栏做过一个例子：我让它分析一段材料，刚开始它正常地拆解内容，五分钟后说到网络安全，系统就说要切回 Opus。但它已经处理了很多上下文。 **嘉宾：** 我明白。它已经谈到网络安全，然后触发回退；回退的原因不是你的问题，而是推理过程和整段上下文的组合。 **swyx：** 你们有没有更好的想法？ **嘉宾：** 用户体验如何改进是另一个问题。也许可以用一个非常聪明的模型来处理。不过我想象中更合适的体验，是让用户看到连贯、一致的 Claude，而不是先回退，再发生二次回退。我们的决策树中有一些逻辑节点，会出于安全等原因启动回退，但整个体验对用户来说非常绕。 我们应该以善意用户为例：有人在做合法的生物学作业，或评估网络安全防护，完全合乎情理，却被拦截后切换了模型。我希望模型或分类器足够聪明，能识别这是哪种情形，继续给出更具体的回答，同时降低相关能力被恶意利用的风险。比如生物学作业场景，虽然分类器可能判断内容“可能属于 B 类”，我们仍可以提供不同处理方式。 对于 API 客户，我们采用了一系列不同方案。如果你在 API 上构建了应用并遇到拦截，不一定要继续在回退模型上续接对话。我们的应用会这样做，我们也把这一功能放进 API：客户可以选择由服务端自动处理回退。SDK 的客户端也有帮助函数，能以不同方式管理回退；或者你也可以选择重新提示…… ## [1:16:23] 模型路由与长时间运行的智能体任务 · YouTube **嘉宾：** 你可以用另一种提示方式让同一个模型继续处理，这方面我们还会试验一些介于两者之间的方案，找出怎样在安全的前提下解除用户限制，同时提供好的体验。 **swyx：** 你说这和路由很像，我完全同意，路由也有类似的体验问题。比如想根据任务复杂度节省成本，做一个成本路由器，看起来很合理，但实际上很难。任务开始时，你并不了解所有情况；即使你能完美理解每个模型，也未必有足够信息理解任务本身，所以路由逻辑难免出错，无论分类器多好。 这可能需要一个特别聪明的大模型，但无论如何都很难。把复杂逻辑暴露给客户，也不是很好的体验：比如“你要做的是调整一个 div，所以我把你转到极便宜的模型；这个任务是检测漏洞，所以我把你转到非常昂贵的模型。”更理想的体验，可能是动态调整 effort 或任务复杂度评估，并随着了解更多信息而改变。但如果用户在许多模型间来回切换，体验会变得割裂。 也许更统一的做法是始终使用同一个模型，但先以非常低的 effort、非常低的成本运行，再根据需要逐渐提升能力，同时保持一致的模型个性。我这里说的是同一家族的模型。如果跨不同模型家族或不同供应商做这种事，模型个性差异会让问题复杂得多。我还不知道跨平台该怎么解决，但至少在 Claude 的模型家族内，我更看好一致的体验。 **swyx：** 很高兴看到你们怎么思考这些问题。意图理解本身就很难。模型虽然变好了，但用户有时也说不清自己想要什么，或者把滑块拉到一个极端；模型也可能理解错。你问一个简单问题，它却给你生成整页 HTML 营销页面，而你只想要几行文字。这类问题总会出现。 **嘉宾：** 我们之前谈到安全和发布模型，但最终都是为了帮助大家运行自己的工作负载。我们看到工作负载变化很大。有些任务的智能需求似乎越来越趋于饱和，这是个新情况；但我觉得仍然有相当多任务尚未达到饱和，比很多人想象的更多。 越来越多的价值来自于让智能体执行极长时间的任务，处理过去无法靠蛮力解决的问题；如今有了更多智能，或许可以做到。这类工作负载让我们非常感兴趣，也具有很大价值，既能帮助企业提升自身效率，也能让初创公司基于它构建智能体产品。 现在的用例有很多编程任务，也有企业创新加速等场景，通常是自动化一个明确、具体的流程。有些领域已经开始奏效，这很棒；有些还不行。因此仍有很大空间继续探索…… ## [1:20:24] 如何在团队里避免 AI 垃圾内容 · YouTube **嘉宾（工程负责人）：** ……继续发展并推动模型前沿。还有一类新工作负载，比如我们提到的生物学和网络安全问题，都是非常复杂的硬工程或硬科学问题。我们越来越多地看到这类需求，这也是为客户提供价值的一个有意思方向。 **swyx：** 你们处于全球少数几个能发现这些工作负载、并尝试自动化它们的位置。 **嘉宾：** 是啊，确实很疯狂。 **swyx：** 这很鼓舞人心。你们产生了很大影响，我很感激。现在进入一些收尾问题，我想让你们轮流回答。你们团队怎样避免 AI 生成的垃圾内容？ **嘉宾：** 这在我们团队内部也一直有争论。我们和其他团队没什么不同，很多团队都在讨论这件事。我们正在想，如果你用 Claude 生成一份要给别人看的文档、代码或其他东西，当然应该借助 Claude。但如果你让 Claude 从头到尾生成内容，自己却完全不花时间阅读和检查质量，就把额外负担丢给了读者、使用者，让他们花大量时间理解代码或文档。这太不公平了。 所以我们会提醒团队：可以用 Claude，但你必须确保产出达到高质量标准。作为人，你仍然要为质量负责。不过这里也有个有趣的问题：人们会被一些所谓的“Claude 痕迹”触发，比如文档中间出现一个 em dash，他们就会想：“糟了，我在读 Claude 写的东西，不是人写的。”他们希望读到的是达到人类质量标准的内容，而不一定要求每个字都由人亲自写。 有时，作者确实花了很多时间确保内容质量，只是用 Claude 帮忙；但读者看到一些 Claude 的小习惯，就失去兴趣。这也没什么帮助。因此，我们在团队里设定的标准是：用 Claude 帮你工作是应该的，毕竟不用这么强大的智能体来加快工作、改善产出就太可惜了。但结果必须达到一定质量。如果读者拿到的真的只是垃圾，就把它退回去，别浪费时间；同时也不要过度挑剔那些细小的 Claude 痕迹。大家都在努力寻找平衡，我们团队也和全世界其他人一样反复讨论这些事。 **swyx：** 但你们有免费的 token。 **嘉宾：** 这当然是事实，不过到了质量问题上，token 是否免费并不那么重要。 **swyx：** 你们的用量可能比世界上任何人都大，也看得到更多人用得更多。 **嘉宾：** 这是公平的。但确实，我们会强烈反对低质量输出。 **swyx：** 那工程方面呢？ **嘉宾：** 道理相同。不过我认为我们现在处在一个不错的位置：人类大量参与系统设计，确保整体设计正确；具体实现则多由 Claude 完成。很多代码写出来之后，只要快速盖个章就能继续推进。不一定需要有人逐行深入审查，因为我们更关心整体方案和设计是否正确，而不是每行代码是否完美…… ## [1:24:24] 让 AI 加速工作，但人仍对质量负责 · YouTube **嘉宾（工程负责人）：** ……当然，我们还会依赖大量验证，确保准备发布的东西质量足够高。所以现在团队里关于代码质量是不是“垃圾”的讨论少了，一方面是 Claude 变强了，另一方面是我们建立了足够的验证机制，守住高标准。 **swyx：** 我明白了，你们信任测试。 **嘉宾：** 对。 **swyx：** 那产品管理会不会也出现低质量产出？毕竟你可以很快发布功能，一天就能推出东西。 **嘉宾：** 他最近跟我说过一句话。你还记得他说什么吗？ **swyx：** 他发过一条推文：正确使用模型能力，不是把十倍多的功能塞进生产环境，而是多花时间了解用户、做实验、搭建合适的东西。你确实很容易不断发布各种随机的小功能，但应该认真思考；多花点时间想清楚最初的提示和目标。我知道他现在会说“开启 Plan Mode，我们不需要它了”，但不管有没有计划模式，都应该想清楚自己要做什么。发布很多东西很容易，但不能因此以为产品问题都解决了。 **嘉宾：** 我经常说，软件和产品的规划、交付有一些根本原则，不会因为智能体加快了流程的某些环节就改变。但人们开始有点懒，觉得某些流程不用思考，因为智能体会帮忙完成。可这些仍然是流程中非常基础的部分，值得你投入时间和精力。我觉得这就是那条推文想表达的精神。 **swyx：** 作为创始人或创造者，实验和探索成本现在这么低，就会觉得应该多做实验。但他其实是在说，不要为了实验而实验，而是要让模型服务于从一开始就设定好的明确目标。我当然也逐渐明白了，只是很难，因为手上有个什么都能做的玩具，就会忍不住把它往墙上扔。 还有范围控制。今天那篇博客叫“用两周让 Claude.ai 更快”，一开始列了 13 项目标，结果三天就完成其中 12 项。你当然可以说：“很好，再来一个两周冲刺，把剩下的 13 项也做了。”但你们反而继续加了 20 项工作。这不是产品垃圾、不是一堆新产品，而是重构。你们的产出很高，同时仍保持了质量标准。 **swyx：** 好，第二个问题中的一部分。Angela 可能会觉得有点不自在：现在是 Angela 推文时间。我会不停地向大家推荐你的推文。 **嘉宾：** 好啊。 **swyx：** 我猜你删掉过一些推文，我看到你的删除内容时会想：“这些太值得留下来了。” **嘉宾（Angela Jiang）：** 对，有些推文真的会改变我的思维方式。 **swyx：** 谢谢。我想问你最常推荐哪条、最想拿出来讲哪条？如果你愿意，我可以帮你找出来。 **Angela Jiang：** 我没有特别喜欢的一条。好吧，也许是你说的那句：“做一半某件事，是不做这件事的一种昂贵方式。” **swyx：** 这和我们今天的话题非常相关。还有一条——虽然你现在做的是不同工作，不再做那件事——我觉得像 Naval Ravikant 风格的金句。你当时是在什么心态、什么思维框架下写出它的？ **Angela Jiang：** 这是很久以前的事了。有一段时间我一直在读书。我当时很厌倦手头做的事情，觉得没有受到足够的智力挑战，于是开始大量阅读。我想我当时读了…… ## [1:28:26] 一年读 200 本书与 Slack 的信息负担 · YouTube **Angela Jiang：** 我一年读了大约 200 本书。当时我只是想尽可能多读一些东西。我有点怀念在学校里学习新主题时那种训练思维的过程：内容很难，未必特别有趣，但确实能让你挑战自己。工作几年之后，我觉得自己不再经历那种智力锻炼。工作当然有意思，也有挑战，但似乎缺少那种学习新东西、拓展思维的部分。 于是我一度疯狂阅读，一年读了差不多 200 本书。那时我通勤很久，尤其是坐一趟很长、很折磨人的火车，所以读书正好能把时间利用起来。读完之后我开始想很多事情。当时我写推文并不是为了积累粉丝，只是在茫茫互联网里自言自语，几乎没有关注者。那些推文是写给自己的，也是一种练习：怎样用尽可能少的字，把自己的想法压缩清楚？后来有人开始喜欢，我就继续写了一阵子，直到工作太忙才停下来。 **swyx：** 读了这么多书，有没有推荐的书、博客或长文章？ **Angela Jiang：** 我现在最喜欢的可能还是纳西姆·塔勒布的《黑天鹅》。对我来说，这本带有哲学意味的书改变了我看世界的方式，让我意识到原来还可以用完全不同的框架看待世界。 **swyx：** Fable 那件事发生时，我也想到了《黑天鹅》：有些事情你原本不知道可能会发生，但一旦发生，就会永久改变你理解世界的框架。 **Angela Jiang：** 完全正确。这个想法很简单，但我觉得塔勒布很好地讲清楚了它，也说明了它如何体现于世界上的许多事情。我很喜欢这本书，应该是我最喜欢的一本。 **swyx：** 如果有人已经读过，可以看看塔勒布的《随机漫步的傻瓜》。你喜欢《反脆弱》吗？ **Angela Jiang：** 我想还行吧。他越出名，就越让人受不了。 **swyx：** 那我也问问 Katelyn：有没有一本你会推荐给所有人的书？ **Katelyn Lesse：** 这是个好问题，我得想一想。我们在这方面的风格确实很不一样。Angela 不再像以前那样发“幸运饼干式”的推文了，但我觉得她有时候会用哲学家的方式思考和工作，也会把这种想法带进团队协作。 **swyx：** 你会在 Slack 里丢一些“幸运饼干”式的金句。 **Katelyn Lesse：** 对，我确实会，不是故意的。我想在 Slack 上把话说得恰到好处，也算是一项技能。 **嘉宾：** 是啊，你们得很擅长用 Slack。 **Angela Jiang：** Slack 确实很紧张。我对邮件和 Slack 的“收件箱清零”有点执着。最近邮件比 Slack 更容易清零。我会很积极地精简自己实际关注的频道，和静音、放在折叠区下面的频道区分开；我一直努力跟上必须关注的那些内容。但这几乎像一份全职工作。有些日子我会想：我可以取消所有会议、不写任何文档，也不做别的工作，只坐在 Slack 前一整天。光是在 Slack 上回应各种事情，就会觉得自己做完了一整天的工作，实在很夸张。 **swyx：** 但那很糟糕啊。 **Angela Jiang：** 我也正是这么觉得。投入了很多精力，回复了大家、把一些事情推进了，但没有产出自己真正想做的成果。对我个人来说，这很难受。我会努力留出时间思考、真正产出东西，这样才能觉得自己确实完成了工作；有时就得忽略、放下某些事情。 **swyx：** 你会因此收到反馈，说你在 Slack 上不容易联系到。 **Angela Jiang：** 是的，我确实收到过不少这样的反馈。 **swyx：** 现在还有人会发 Slack 来问：“你能让 Angela 回一下吗？” ## [1:32:28] Slack、开发者关系与平台团队 · YouTube **Angela Jiang：** 我真的很努力在这里把想法记下来。 **swyx：** 等一下，你们没有自己的 Claude 助手之类的吗？怎么帮你们处理这些事情？为什么没人给你们每个人写个私人助理？ **Angela Jiang：** 我们当然有真人助理，也有很多 Claude 在 Slack 里帮忙。不过，我在 Slack 上筛选和回复的消息，往往是团队遇到了阻塞，需要有人做一个艰难的决定。这无论发生在 Slack 还是别的渠道，都是我工作的一部分：帮助团队解除阻塞、保持高质量执行。只是这类事情经常发生在 Slack 上。我也同意，一天到头都在来回沟通、解决问题之后，确实会想：“我到底产出了什么？” **swyx：** 你产出了一支运转正常、没有被卡住的团队。以前我做管理时也有这种感受。你可能觉得自己什么都没产出，但你产出了整个团队。 **嘉宾：** 对。 **swyx：** 说到团队，接下来问 Katelyn：开发者关系时间。你们正在招人做 Developer Relations，最近还招了 Addy Osmani。很好的人选。你在组建团队，想招什么样的人？这正是谈这个的好机会，我也愿意交流经验。 **嘉宾（Katelyn Lesse）：** 谢谢你。当我负责招聘 Katelyn 的开发者关系团队时—— **swyx：** 这很有意思。 **嘉宾（Katelyn Lesse）：** 不只是招聘。我要特别夸夸你。我加入 Anthropic 时，公司规模还很小。我们平台团队负责 API 业务和所有产品基础设施。Developer Relations 在公司里还处于很早期，也不属于产品和工程组织的一部分。加入之后，我们觉得需要发展成熟一些，想清楚怎样和开发者社区、外部世界交流，因此必须投入资源建设 DevRel。 最后，我们在平台团队和 Claude Code 团队分别建立了 DevRel 团队，因为 API 业务和智能体编程面对的是两个相当不同的开发者生态。我们把它们设为两个团队，但保持虚线协作，常常一起工作。我以前在 Stripe 等公司和 DevRel 合作过很多次，却从没负责过这件事。我一开始完全不知道怎么做，你给了我很大的帮助：你告诉我 DevRel 的三个支柱——产品、内容、社区——以及应该如何思考。现在我可以把这套框架讲给别人听，他们就会觉得我很懂 DevRel；我只能说：“别这样，我是抄来的。” **swyx：** 你就说：“这是我复制的。” **Katelyn Lesse：** 对，那不是我原创的。听说 Google 入职 DevRel 新员工时也会把那篇文章当成必读材料，挺好笑的。它确实帮了我很多，因为我当时完全不知道该怎么做。 另外，目前平台 DevRel 团队还没有经理，这是我希望招聘的岗位。平台的 DevRel 个人贡献者现在直接向我汇报，一部分原因是我觉得这确实是非常难的问题，另一部分是我觉得它很有意思，和团队一起工作很开心。 平台业务很难讲清楚。在我们的公开叙事里，虽然平台业务规模很大，但容易被研究、政策等工作夹在中间；那些工作显然是我们的前沿重点。同时，另一边还有 Claude Code、Cowork 等应用。人们想到 Anthropic 和我们的公开形象时…… ## [1:36:29] DevRel 的定位：教会社区构建 · YouTube **Katelyn Lesse：** 人们往往只想到 Anthropic 的研究和应用，而不太会想到我们运营着一个规模很大的开发者平台业务，有很多人都在其上构建产品。平台 DevRel 团队的重要目标，不只是传统意义上更好地了解用户在构建什么、怎样把反馈带回产品；还要找到我们的声音、品牌和叙事，思考我们在开发者社区中究竟是谁，避免在其他事情中被淹没。 我们正在为 DevRel 团队建立一种品牌形象。Lance 加入团队也是你把他介绍给我的。他技术能力很强，做 DevRel 更像是在教学：写很多关于记忆、成本管理等方面的深度内容，编写评估，发布技术内容。我很喜欢这种定位——让 DevRel 团队成为这个新颖、困难、不断演进领域里的思想领袖。 **swyx：** 可以把他们定位成教育者、思想领袖、技术讲解者。还有一种我很喜欢的方式叫“高手创作者（master builder）”：我用这个平台做出东西，让大家看到它能做什么；大家就会惊叹：“原来 Claude 平台还可以这样用！”这套说法是从 LEGO 那里学来的。 **嘉宾：** 对，LEGO 怎么卖积木？他们有高手创作者用积木搭出各种东西，让你觉得“我也想做这样的东西”。 **Katelyn Lesse：** 很棒。我们团队还有一位很出色的成员 CJ，他更擅长写使用指南、发布示例，并在 X 上和社区交流。 **swyx：** “Cookbook”这个概念很有意思。2023 年大型语言模型 API 刚发布时，代码示例非常重要；现在好像没那么重要了。 **嘉宾：** 我理解你的意思。现在大家不一定只是复制粘贴代码，但示例能展示可能性，让人知道有哪些用例以及如何实现。虽然代码本身的重要性也许变了，但过去很长一段时间，我们团队的一位工程师写了计算机使用 Cookbook，这项工作至今还让他头疼：那是个非常复杂的大项目。当时很多人想自己实现计算机使用，需要处理 Messages API 中的截图等细节，Cookbook 给他们很大帮助。那时的确需要这种材料。 现在则不同了。比如 Claude API Skill，无论在 Claude Code 还是其他编程智能体中，都能帮助大家构建高质量集成。很少有人会先翻出那个复杂的 Cookbook；他们更可能把 Skill 加载进编程智能体里，让它协助构建。 **swyx：** 或者直接把参考架构交给它。对于执行框架等不同实现，你只要告诉 Claude：“我想要这个参考架构”，它就能帮你搭出来。我们发现很多事情都适合这样做。 有个有趣的事实：帮助大家调用 API 的 Claude API Skill 是由 DevRel 团队负责的，是 Lance 做的。最高效的 DevRel 之一，就是把最佳实践提炼出来，交给这些智能体。 **嘉宾：** 对。 **swyx：** 有点奇怪，我被看作是 DevRel 权威，但我心里有一部分其实想告诉大家：“你们不需要 DevRel。” **嘉宾：** 是的，有了好工具，你就不再需要它了。 **swyx：** 或者说，你可以把工程师、领导者培养成…… ## [1:40:29] 让产品负责人走到台前 · YouTube **swyx：** ……成为对外的面孔。很多时候，你们要做的就是让人们知道你是谁、你们怎么做事，让大家能够听说你。比如 Boris 刚出现时，他的感觉就是：“嗨，我是 Boris，我是 Claude Code 的创造者，来看看我们怎么做事。”当然，他也有本职工作，同时还做这些事情；为什么大家不都这样？ **嘉宾：** 这是个好问题。有些团队确实做得很好，比如 Cloudflare 的团队，大家都很棒。 **swyx：** 这也是优秀管理者一个很明显的迹象：员工喜欢自己的工作，愿意公开表明自己在这里工作，没有人因此离职。 **嘉宾：** 完全同意。我们也正尝试让平台团队和自己的团队做更多这样的事，让有能力的人走出来参与社区、发表演讲、在 X 等平台发声。我们面对的主要问题，是大家没多少时间，也不一定知道如何高质量地做这类工作。所以我觉得 DevRel 团队可以成为这方面的专家，专职做好，并帮助其他团队成员在有限时间里也能做好。 **swyx：** 我把这叫作把 DevRel 这个角色拆成前台和后台。一般情况下，一个人会从头到尾独立完成这份工作；但也可以建一个后台团队，让产品和工程负责人站在聚光灯下。你只需要和我坐下来 30 到 60 分钟，把想法讲出来，然后就回去工作；我们可以帮你代笔。由制作、写作等人员构成的团队提供服务。 我觉得这可能是未来的发展方向。人们真正想听的是产品负责人本人的话，不是 DevRel 的话。比如大家想听 N、Lydia 等真正做产品的人怎么说。虽然有人专门做发言人也是合理的，毕竟这也是一种工作。 **嘉宾：** 当然，不能指望工程师天然就擅长这件事。 **swyx：** 没错，所以应该聘请专门从事这项工作的人；这是一项专业技能。但也许可以形成前台和后台的分工。 **嘉宾：** 是的，听起来很棒。 **swyx：** 我的类比是 HR：每家公司都要招聘，但有 HR 部门来帮助大家招聘。 **嘉宾：** 这个类比很贴切。 **swyx：** 好，这是我的一段长篇意见。最后几个问题：感谢你们花这么多时间。你们有什么临别想法或行动建议吗？有什么值得大家用新 Opus 5.5 来挑战极限的东西？你们使用它的时间最长。 **嘉宾：** 我觉得它的成本效益真的很好，也没那么啰嗦。我们刚才提到的特点都不错，整体感觉也很好。昨天对我们来说特别开心，我又收到一大堆朋友和认识的人发来的消息：“模型太棒了，谢谢你们。”我以前的一位老板也发消息说：“Opus 5.5 刚刚在一次事故中救了我们。”那种感觉就是：“太好了，我们回来了。” 所以，如果你之前想尝试某些东西，但一直在意成本、token 效率，或者觉得不值得让模型长时间运行，现在可以重新考虑这些问题。Opus 5.5 应该能让你走得比过去更远…… ## [1:44:30] Opus 5.5 与多智能体建议 · YouTube **嘉宾：** 我觉得你现在能走得比以前更远，因为它比过去的模型更有成本效益。我建议你试试多智能体配置，效果应该会很好。 **swyx：** 还有其他提示吗？毕竟“多智能体”范围很广。 **嘉宾：** 没有了。我很想听听大家会用它构建什么东西，但我觉得它确实会特别好用。 **swyx：** 比如让智能体使用一些没有严格预设、由它们自己分配的角色？ **嘉宾：** 对，我觉得这才是新意。你过去就能给智能体安排角色、分配 token 和任务；但现在是它们自己给自己分配工作。 **swyx：** 对，谈谈多智能体吧。大家该不该用子智能体？应该怎样看待多智能体？ **嘉宾：** 一般来说，你需要一个主智能体，然后把许多不同的任务拆开。只要任务大体上可以并行处理，而且各部分共享一致的上下文，我觉得就能获得很大提升。当然要看具体问题，但对我们来说，这越来越像是一种很好的处理方式。 尤其当每个子智能体，或者你想称它们为“子负责人”也好，都是异步运行、互不阻塞时，你的架构里需要关注的核心原则大概就这两条。除此之外，就放手让 Claude 去做，看看它会设计出什么。随着模型越来越聪明，它会逐渐学会拆分自己、复制自己，并按合适的方式调整架构。 你只需要保证它能并行处理：状态要能共享，子智能体之间不能互相阻塞。只要守住这两个原则，我觉得大家就应该多做实验，甚至尝试非常疯狂的方案。也许有人一直在解决某个棘手、令人头痛的问题，多智能体系统可能一次就把它解决掉。 **swyx：** 太好了。大家都去构建吧。 **嘉宾：** 好，好。