Anthropic 如何打造并推出全球排名第1的 LLM——对话 Katelyn Lesse 与 Angela Jiang

摘要

• 开场对 Anthropic IPO 的判断，建立在员工与资本效率大幅提升之上。 主持人援引 Anthropic 的 S-1 文件称，公司过去12个月人均收入为660万美元，去年同期为140万美元；GAAP 口径下首度实现单季盈利，利润率为19%，而此前亏损相当于营收的129%。开场还提到，公司累计融资超过1000亿美元，累计烧钱不到100亿美元，预计“两周后以2万亿美元估值 IPO”。
• Claude Platform 让 Anthropic 的业务不止于出售模型智能的使用权。 开场称，过去12个月营收至少10万美元的客户中，超过50%在使用该平台；Claude Code 和 Cowork 也建立在平台开放的同一套基础能力之上。Managed Agents 又加入基础设施与 harness 管理，呼应主持人将 Anthropic 定位为云平台的说法。
• Opus 5.5 的卖点，是更好的经济性与更易用的模型兼得。 Katelyn Lesse 提到降价、文风不再像 Opus 5 那样绕，以及客户对“每一美元买到足够智能”的需求。嘉宾对主持人所说的“顶级模型”补了一句“看你问谁”；开场预测 Fable 5.5 可能在两周内跟进时，也明确表示“我没有内幕消息”。
• 安全工程已成为模型发布工作的重要组成部分。 每次发布都要决定数据保留、在线防护、离线审查、验证项目和全链路授权如何安排。反蒸馏措施在保留思考块的同时，也要兼容正当的上下文压缩。Katelyn 解释安全层面的考量；主持人称主要顾虑是安全而非商业影响，并指出蒸馏使用会给 Anthropic 带来收入。
• CPU 供给正与加速器供应并列，成为实质性约束。 嘉宾称，API、沙箱、研究和不断增加的 CI 活动都在争夺 Anthropic 的 CPU 配额。借助 Claude，团队将 Messages API 从 Python 迁移到 Rust，CPU 用量下降约40–50%，首 token 延迟改善10–20%；关键的人类贡献是“计划”和“验证”。
• 把智能体的大脑与双手拆开，能让安全成为基础设施属性。 Managed Agents 让 harness 保持持久运行、执行环境相互隔离、凭证存放在独立保险库；出口代理负责注入智能体看不到的密钥。这套架构也缩短了启动延迟，并能在沙箱故障时提升韧性；一位嘉宾说，曾强调安全的同事最终证明了自己是对的。
• 评估与个性化仍是产品质量绕不开的难题。 不同客户对智能体主动程度的期待相互冲突，嘉宾坦言：“我们做得并不好。”团队的应对包括扩大评估套件、开放可调节的推理力度，以及提供托管 harness；Angela Jiang 相比让用户明显地在不同模型间切换，更看好同一个 Claude 动态调整推理力度。
• 下一波工作负载机会，是更长时间的自主执行与更强的验证。 Angela 认为，部分任务的智能需求正在接近饱和，但高难度工程和科学问题仍有很大空间。收尾时给出的多智能体建议是：设置一个主负责人，共享状态，并让异步工作者互不阻塞；与此同时，质量责任仍在人类手中，实施更快不能成为“往生产环境多塞10倍功能”的借口。

精读

1. IPO 叙事聚焦效率提升与更广的平台业务

• 开场主持人称 Anthropic 当天提交了 S-1 文件，并把 IPO 时间点描述为“两周后，估值2万亿美元”。他将累计融资超过1000亿美元与累计烧钱不到100亿美元作对比。这些数字引出本期的核心问题：Anthropic 如何在异常高效地发展业务的同时，持续推出主持人眼中最强的模型？

• 运营数据呈现出明显反转：过去12个月人均收入从140万美元升至660万美元，接近5倍。主持人称，Anthropic 在2025年第二季度每获得1美元营收，就要亏掉0.5美元；如今每1美元成本对应2美元营收。公司首个盈利季度的 GAAP 利润率为19%，此前亏损则相当于营收的129%。

• 主持人用两个相互强化的循环解释改善过程。一方面，更强的 Claude 模型解锁更多用例，采用率带来反馈，反馈再推动 Claude 改进；另一方面，采用率提升推高营收与增长，吸引投资，为进一步提升能力提供资金。他将其称为 S-1 中的“改进循环”和“投资循环”，把产品表现与持续改进所需资源联系起来。

• 据称，过去12个月营收至少10万美元的客户中，超过50%使用 Claude Platform。主持人强调，Claude Code 和 Cowork 使用的也是平台开放出来的同一套基础能力。他认为 Anthropic 正从聊天机器人和副驾驶，转向“虚拟协作者”：能够承担目标、调用工具、自我纠错，并与人协作完成周期更长的任务。

2. Opus 5.5 主打每美元智能含量与更清晰的表达

• 被问到如何庆祝“全球顶级模型”时，嘉宾立刻补充：“看你问谁。”Katelyn 特别高兴的是，客户对 Opus 5 文风绕的反馈，最终促成了更清晰的继任版本。降价则回应了另一项需求：客户越来越看重“每一美元买到足够的智能”，因此团队既要提升智能，也要降低其成本。

• 开场录制时正值 Opus 5.5 发布前后，主持人称测试者反响热烈。他还预测 Anthropic 手里已有 Fable 5.5，“很可能”会在两周内发布，但明确强调这只是猜测：“我没有内幕消息。”他把这一时间推测与预期中的 IPO 联系起来，而非将其说成已确认的发布安排。

• Katelyn 将产品团队的职责概括为平衡智能、安全、成本和商业影响；她说工程团队更关注集成与开发者体验。技术产品经理与具备产品思维的工程师之间存在刻意的职责交叠。被问到软件工程“已被解决”后两种角色是否会合并，Katelyn 不接受这么强的说法：“目标还会不断抬高。”因此，运营与设计工作仍有大量空间需要人来完成。

3. 反蒸馏措施保护安全机制，同时保留正当用途

• 关于《从专有大语言模型窃取推理轨迹》的讨论，先从负责任披露谈起，两位嘉宾都表示欢迎。Katelyn 称，论文揭示了 Anthropic 已意识到的一个缺口：提取思维链是“蒸馏模型最有力的方式之一”。工程上的难题，是如何堵住这条路径，同时避免显著损害有用的 API 集成。

• Katelyn 的解释重点在安全机制：Anthropic 会对生成的 token 分类，以降低有害结果；蒸馏出来的模型则可能在没有这些防护的情况下运行。主持人而非 Angela 表示，主要顾虑是安全而非商业化，并指出“如果你从我们这里蒸馏，实际上还要付钱给我们”。他担心 Claude 的衍生模型脱离外围安全系统后被用于负面用途。Angela 则另行表示，在 Anthropic 能够衡量的领域，蒸馏已经难得多。

• 团队区分了两种用户体验损害：一种是令人烦恼、但不影响功能的集成迁移；另一种是原本能做的事突然无法完成。团队尤其希望避免后一种情况。要在不同轮次间保留思考块，并收紧不同账户对思考块的处理方式，就必须区分正当工作流与提取手法，而不能简单禁止所有对推理轨迹的操作。

• 上下文压缩是具体的检验案例。一些客户原有的策略会因保留思考内容的要求而失效，因此 Anthropic 与客户及开源 harness 维护者合作，推出了兼容这些策略的 API 上下文压缩功能。Angela 并未声称团队掌握了全部情况，也没有说提取行为已被彻底消除。

4. 每个模型都需要单独制定安全部署策略

• 谈到发布安全时，一位嘉宾将其拆成3个维度：架构与基础设施安全、生成过程中实时运行的在线防护，以及对存储数据进行离线分类。所需工作取决于模型能力。Katelyn 补充说，如果模型在生物或网络安全方面出现特定能力跃升，团队可能需要区别对待；能力究竟偏攻击还是偏防御，会影响处置方式，不能把所有智能提升一概而论。

• 数据保留机制用于发现单个请求流式生成时未必能识别的行为。多个账户可能共同呈现恶意使用或蒸馏迹象，因此需要自动或人工审查。Angela 明确区分不同模型：Opus 5.5 不承担 Fable 的数据保留要求。这些要求按具体模型发布逐一决定，再由工程团队落实。

• 网络安全验证项目与新推出的生命科学验证项目，让经批准的用户可以在指定用途下，以较少的防护访问双重用途能力。正当的漏洞研究与生物研究就是相关例子。授权必须贯穿整个请求链路；Angela 将这种做法与随手发一把密钥、切换一个功能开关作对比。推出这些项目，如今已是模型发布本身的一部分。

5. 通用信任授权让不确定的部署情境更容易应对

• Fable 的回滚成为 Angela 举例说明路线图无法依赖精准预测用例的案例。团队原本不会预料到某件事会发生，但它确实发生了，足以说明概率并非为零。她的应对方式是“深度概率化”的产品管理：建立“一组押注”，包括一些可能永远用不上的控制措施，但如果类似异常情况再现，就能保留应对选项。

• 最初的访问系统是给特定用户授予特定能力，但团队选择了比传统产品权限划分更通用的基础原语。这些原语后来被用于更广泛的模型访问、可信项目和模型部署。团队正基于同一基础推进一键回滚。Angela 说，通用化设计屡次带来收益，但具体哪一项风险对冲措施最终有价值，仍无法确定。

• “信任授权”只是用 Anthropic 自己的数据模型表达常规授权，并非一种截然不同的安全概念。在 Fable 5.1 推出保留思考内容的过程中，现有客户获得了宽限期来更新集成，授权记录则用于追踪这些例外。请求热路径上的服务会检查请求方是否具备相应权限，同一机制因此可以支持多种策略。

6. 外部 harness 暴露的问题，能让模型反馈更有价值

• 模型发布会经过候选版本、评估、内部试用，以及选定客户的外部测试。Cognition 等客户提供了不同于 Anthropic 自家产品的 harness，这一点很重要，因为 Claude 的目标是具备泛化能力。Angela 既重视正式评估结果，也重视主观反应：“你喜欢它吗？不喜欢什么？”负面反馈往往最能推动进一步改进。

• 主持人质疑，反馈仍然像是在 Slack 频道里说一句：“这东西好像有点怪。”Angela 承认流程有时确实不够正式，部分原因是团队正在“争分夺秒”，尽量缩短模型可供测试到大范围开放之间的时间。因此，早期访问客户往往已有成熟的评估套件，能快速产出可执行的证据，同时也会提供主观感受。

• 懒惰还是主动，正是外部测试价值所在。一位客户希望 Claude“直接把我的任务做完”；另一位还在规划时，Claude 却已经开始写代码。Katelyn 说，要对所有人都精准把握这个尺度“根本不可能”。有一次模型懒得过头，团队因此把候选版本“放回烤箱里再烤一会儿”；仅靠内部产品使用，可能发现不了这个问题。

7. 现有参数还不足以表达个性化需求

• 主持人用一项代码基准挑战模型评估：即使用户可以通过自己的 CLAUDE.md 指令，阻止模型过度操作或创建过多文件，基准仍可能因此扣分。这样的基准是否不公平地惩罚了模型？嘉宾坦言，在评估个性化方面，“我们做得并不好”。Katelyn 说，模型宪法能有所帮助，却无法解决用户对辅助方式偏好相互冲突的问题。

• 推理力度提供了一种有限的自定义方式。对话中特别提到 Claude Code 默认使用中等推理力度；Katelyn 则说，免费用户、专业消费者、企业用户、Cowork 和 API 的默认值可能各不相同。团队倾向于提供“温和的默认设置”，同时让用户可以调整。有人想要最高智能，有人则更适合较低推理力度和更快回复，因此很难为所有人设置一个激进的默认值。

• Katelyn 将当前状况形容为推理力度、预算和其他参数的“有趣拼盘”，很难找到适用于每项任务的固定组合。选项包括开放低／中／高档位，还是1到100的刻度，以及哪些控制项应该退场。她说，客户数量增加后，单靠判断彼此冲突的偏好，迟早无法规模化；Claude 需要更丰富地吸收个性化信息，但这目前尚未解决。

8. Managed Agents 打包 harness，同时保留试验空间

• Angela 将 Messages API 的“原始 token 访问”与 Claude Managed Agents 区分开来：后者抽象层级更高，开发者可以定义一个智能体并启动会话。Anthropic 提供基础设施与 harness，包括适配新模型参数和破坏性变更的工作。它的价值在于提供程序化访问，让每位客户不必在每次模型发布时，重新摸索怎样才能获得最佳表现。

• Managed Agents 与 Anthropic 第一方产品共享大量基础设施，包括沙箱集群，但共享基础设施不代表 harness 完全相同。Angela 称，平台提供的 harness “刻意保持简单”：它纳入实用做法，并处理智能体循环中困难却不具差异化的部分。更有主张的策略可以建立在这层基础之上，而不必强加给每位开发者。

• 被问到记忆和“梦境”功能是否停滞时，Angela 承认，与今年早些时候相比，部分功能开发有所放缓，因为安全工作占用了更多精力。但这不等于放弃：“我们很喜欢 skills。”记忆与梦境仍然服务于持续改进；团队越来越希望开发者扩展现有基础原语，而 Anthropic 则专注于安全地开放模型能力。

• 梦境本身就是由多个智能体构成的：另一个托管智能体检查前一个智能体，并为它编写记忆。“托管智能体一层套一层。”Angela 还提到 best-of-N 和验证器智能体等策略。她预计“相对很快”会有一次更新，开放底层原语与模板，让开发者自行构建变体，而非只能使用 Anthropic 特定的梦境实现。

9. 智能体工程越来越像实验研究

• Angela 对评估的建议是扩大覆盖面：“评估最好多做，而不是少做。”静态确定性检查与 LLM 评审各有用途；规模很小、号称完美的评估套件无法回答所有问题。她也建议从简单做起。手上一个评估都没有，却先争论一套复杂的评估方法菜单，不如先实现一个基本而有用的检查，再逐步完善。

• 主持人提出把工程当作研究来做：明确目标、形式化评估、标注结果、制作原型，再扩大运行规模。诊断失败时，至少要考虑3种可能：评估错了、环境错了，或模型错了。Katelyn 认同：“很多时候是评估错了。”这种做法把模型研究人员熟悉的习惯带入应用工程；过去，应用工程更常以满足传统产品需求文档为主。

• Claude 可以协助构建评估本身，也能搭建评分界面。主持人对比了让人望而生畏的 JSONL 文件，以及可用的左右对比界面：人们可以打分、写评论，这些判断再成为 Claude 可利用的反馈，帮助系统改进。Katelyn 预计 Managed Agents 会提供一种工具体验，让人像与 Claude 合作创建评估，而不是被迫使用陌生的独立工作流。

• 一篇性能优化博客提供了一个例子，但节目记录给出了两组不同数字：主持人先说12项目标中有9项在约3天内完成，后来又说一次为期两周的工作中，13项目标有12项在3天内达成。对话讨论的是扩大优化清单，而不是把实施提速当作开发无关产品的理由。嘉宾也喜欢公开实际提示词，因为方法往往没想象中复杂：有时只是告诉 Claude，“再努力一点”。

10. CPU 需求如今也需要像加速器那样提前规划

• Katelyn 说，CPU 短缺“如今和加速器层面的短缺一样严重”。过去只要有预算、团队就以为随时能拿到的算力，现在必须提前规划。虚拟机和沙箱也受到影响。她的描述并不限于 Anthropic：她说，自己在行业里接触的其他人也遇到了类似短缺。

• 产品服务、API、应用、沙箱执行、研究和 CI 都在消耗 CPU。代码生成越多，CI 运行次数越多，智能体自身工作之外的需求也随之增加。研究与产品沙箱彼此隔离，但公司内部的 CPU 配额仍是“零和博弈”：Anthropic 从云服务商那里获取容量，再分配给彼此竞争的内部需求。

• 应对方式包括采购更多资源、提升沙箱基础设施效率，以及在不牺牲租户隔离和安全的前提下提高应用效率。是否值得接入新供应商，取决于规模和质量。Anthropic 同时运行在三大云平台上，以免过度依赖某一家供应商的特殊算力规格；嘉宾说，跨环境通用的基础通常必须采用最标准、最普通的能力。

11. Claude 辅助迁移 Rust，降低 Messages API 资源成本

• Katelyn 说，自己一年多前加入时，Messages API 还是部署在 GCP 单一区域的 Python 单体服务。团队后来扩展到多个区域，开始撞上 CPU 瓶颈。尽管当时会议室里一个 Rust 开发者都没有，团队还是决定采用 Rust。Claude 负责编写实现代码；人类负责设计分布式系统，并学习运营所需的知识。

• 关键工作在于“制定怎么做的计划，以及验证这件事确实做成了”。团队构建了完整的 Rust 版本，并通过影子流量将它与 Python 版本对比，再逐步开放生产流量。对话将此与过去预期的、需要数年逐步推进的迁移方式作对照。过程中团队还招聘了几位更有经验的 Rust 开发者。

• 介绍迁移的一位嘉宾称，Rust 版 Messages API 上周已完成全面上线。估算的资源节省幅度为 CPU 下降约40–50%，首 token 延迟改善约10–20%；运行时间更长的负载，改善幅度更大。这是此次迁移的运营结果，与另一篇关于几天内提升 Claude.ai 速度的博客案例不同。

• 范围控制很重要：这次只是迁移，组织其他团队仍在持续增加 API 功能。迁移团队通过静态分析和协作维持功能一致，避免重做设计。后续还可以把对话状态存起来，让客户端不必每次都重新发送全部历史记录。仅靠提示缓存无法消除这部分传输；长对话按用户数算可能不多，但按 token 量算占比可观。

12. 把大脑和双手分开，首先提升的是持久性，其次才是安全性

• 一位嘉宾解释，Managed Agents 最初完全可以做成把 Claude Code 放进沙箱，再附上一个 API。但这并不够：调用方必须等沙箱和智能体都启动后才能收到 token，沙箱一旦崩溃，智能体也会终止。最终方案是让 harness 运行在持久服务器上，状态单独保存，需要时再启动执行环境。

• 团队最初主要强调可靠性与延迟。一位产品经理不断坚持：“这个架构最重要的属性是安全。”嘉宾说，自己前一天还向这位同事道了歉。转变之所以重要，是因为将编排与执行分开带来了安全属性；此前团队主要从产品性能角度评估架构时，这些好处并不那么显眼。

• 凭证存放在独立保险库中。智能体看到的是占位符；它调用服务时，出口代理会取出并注入相应密钥。这样就不必先把原始凭证放进智能体的执行环境，再想办法清除或藏起来。嘉宾称，这种隔离在智能体与凭证之间筑起了一道“实打实的基础设施墙”。

• 沙箱可以配置域名允许列表，也可以彻底禁用网络访问，以限制智能体编写的代码能够连接什么。客户询问如何限制智能体时，嘉宾强调架构和配置都很重要。Managed Agents 将这些控制及后续改进一并打包：随着 Anthropic 不断吸取经验，客户能获得持续更新的防护，不必在行业变化时自行重建凭证处理、网络管理和执行环境方面的每项决策。

13. 训练环境中的越狱与生产部署条件不同

• 被问到沙箱越狱是否意味着技术有缺陷，还是实施不当，一位嘉宾区分了训练事故与部署系统。训练过程可能等于对一个被关在盒子里的模型说：“解决一个不可能完成的任务，我要给你压力。准备好，开始。”这会激励模型尝试逃逸。生产环境则可能有训练设置中不存在的在线防护和隔离基础设施。嘉宾提醒，不能把两种环境混为一谈。

• 主持人也质疑，一边倡导“循序渐进”，一边又在11天后推出前沿模型，是否自相矛盾。嘉宾回应说，循序渐进的意思是先做好安全和防护工作，达到可以放心发布的程度；Opus 5.5 满足了这些要求。但嘉宾仍把长时间运行的智能体称为新兴领域，团队还在摸索并争相建立控制措施，并没有把周边工程说成已经完工。

14. 安全回退暴露出与模型路由相同的未解难题

• 误报会打断正常工作。主持人举例称，他让 Fable 分析自己的安全卡片；模型推理约5分钟，转向网络安全内容后便回退到 Opus。触发条件似乎与不断演进的推理和上下文有关，而不只是最初的请求。用户做生物作业时，也可能因为正当用途而遭遇拦截。

• 主持人质疑，能力较弱的分类器可能误判更聪明模型正在处理的任务。嘉宾回应说，分类与回答是两种不同能力：识别危险，不需要具备实施危险行为的能力。更聪明的裁判模型或许有帮助，但会增加成本与延迟。嘉宾承认问题存在，并未声称已有明确解法。

• Angela 解释，API 提供了几种选择。客户可以启用服务端回退，也可以使用客户端 SDK 辅助管理回退，或者重新提示并让同一个模型继续处理。因此，应用里的回退行为并非唯一可选集成方式。Angela 更希望有一种统一体验：在限制问题能力的同时，仍能妥善回答请求中无害的部分。

• Angela 将这一问题与常规成本路由联系起来：一开始既无法完全理解任务，也无法完全确定该用哪个模型，执行过程中还会出现新的复杂情况。显眼的模型切换会让体验变得繁琐，也会让模型个性不一致。相比之下，她更看好同一个模型先以低推理力度、较低成本开始，再根据需要连续增加推理力度。至于跨不同供应商如何解决这种不连续性，她说自己也不知道。

15. 长时间运行任务仍是尚未饱和的重要需求来源

• Angela 说，部分工作负载的智能需求似乎越来越接近饱和，但另一些类别仍“远未饱和”，程度可能超出人们的预期。新的回报将来自“运行时间极长的智能体任务”，它们处理的是过去难以靠蛮力攻克、但或许能通过更多智能解决的问题。她认为，亲自开展这些工作的企业和围绕此类任务构建智能体产品的创业公司，都有机会从中受益。

• 现有需求包括编程和企业产品对不同流程的自动化。有些应用已经开始奏效，另一些仍然不行。生物学和网络安全则带来了另一类艰难的科学与工程问题，不只是简单的流程自动化。Angela 说，平台上正出现越来越有意思的工作负载，但并未声称模型能力或可靠执行已无所不在。

16. 实施提速后，判断与质量仍由人负责

• Angela 说，对文档和代码，人们可以使用 Claude，但必须确保结果质量过关；把未经阅读的生成内容直接转交出去，等于把作者该做的工作丢给读者，她认为这不公平。Katelyn 强调，质量责任仍在人类。使用者应把真正的劣质内容退回来，但不要因为出现破折号或其他“Claude 式表达”就条件反射地否定好作品。质量与文风上的痕迹是两回事。

• 在工程中，人类要确保系统设计和计划可靠；Claude 编写大量代码；验证则负责确认结果是否达标。Katelyn 说，有些变更只需快速审批。这不意味着可以把生产系统交给 Claude 后说声“祝你好运”：运营和演进大型系统仍然离不开人类专业知识。

• 主持人援引一条警告：新能力不该只带来“往生产环境多塞10倍功能”。Katelyn 认为，基础产品规划不会因为智能体加速了部分流程就消失。主持人承认其中的张力：当试验成本变低，什么都试一遍很有诱惑力。反方观点是，应该把速度用于服务明确目标，并更好地理解用户。

• 管理工作也有同样的拉扯。Katelyn 一整天都在 Slack 里帮忙排除决策障碍，可能觉得自己什么也没产出；Angela 会保护时间思考和写作，代价是别人更难联系到她。主持人反驳说，解决这些问题，打造的正是“一支运转正常、不再被卡住的团队”。Claude 的辅助并没有消除所有最终需要她们处理的难题。

17. 开发者关系正转向教会人和智能体如何构建

• Katelyn 说，在研究、政策、Claude Code 和 Cowork 等叙事之间，平台业务很容易从 Anthropic 的公众形象中消失。平台与 Claude Code 的 DevRel 团队分别服务不同开发者生态。平台仍需要一位负责人，其他团队成员则直接向她汇报。团队既要找到自己的声音和定位，也要承担熟悉的工作：收集产品反馈、创作内容、经营社群。

• Lance 围绕记忆、成本和评估开展的深度技术教学，体现了 Katelyn 希望看到的做法；CJ 则贡献了案例和社群工作。主持人补充了“造物大师”模式，借鉴自 Lego：用平台做出令人印象深刻的作品，让开发者看见自己可以构建什么。这类工作有助于挖掘可能的应用，而不只是宣布又多了一项能力。

• Cookbook 正越来越多地用于展示可能性，而非提供可直接复制的代码。Katelyn 将一套复杂的旧版计算机使用实现，与由 Lance 编写、归 DevRel 负责的 Claude API skill 对比；后者帮助编程智能体创建集成。Angela 补充，开发者可以让 Claude 参考架构文档。最佳实践正越来越多地通过协助用户构建的智能体传递。

• 主持人追问，工程师和产品负责人是否应该亲自成为公众面孔，就像 Boris 代表 Claude Code 一样。他提出的分工是由专家出面，再由制作团队提供支持：花30–60分钟口述想法，之后回去工作，其他人协助发布。Katelyn 认为 DevRel 的作用是帮助同事更好地沟通；主持人则把这种支持比作 HR 帮所有人招聘。

18. 多智能体的收益，取决于共享状态和可独立推进的工作者

• Angela 在结尾建议，重新尝试过去受成本或 token 效率限制的实验。Opus 5.5 的经济性改善、冗长程度降低，或许意味着开发者可以放手让它运行更久，做得更多。她特别建议试试多智能体架构，但没有为最有前景的应用给出狭窄配方；她想看看大家会用新增能力做出什么。

• 收尾建议是设置一名负责人，统筹可以并行化的工作；各智能体共享上下文，子智能体异步工作、互不阻塞。嘉宾强调的两个架构重点是共享状态与独立推进。只要问题适合这种做法，他们预期就能获得收益；除此之外，建议是多做实验，“放手去跑”，而不是过度规定每个角色。

• 主持人区分了给智能体分配固定工作，与让智能体彼此分派工作。嘉宾预计，更聪明的 Claude 模型会越来越擅长拆分、复制并调整自己的工作安排。嘉宾说，如果实验最终在以往看似无解的问题上取得有趣结果，自己“不会感到意外”——甚至可能“也许一轮就解决了”。这仍是鼓励测试，而非性能保证。