How Anthropic ships the #1 LLM in the World — with Katelyn Lesse and Angela Jiang

Anthropic 过去一年人均营收从 140 万美元涨到 660 万，Opus 5.5 被高阶用户公认是当前最强大模型，公司首次实现 19% 利润率。

最强模型的发布，难点已不是训练

Katelyn Lesse 与 Angela Jiang 分别负责 Anthropic 的产品与工程。两人曾在 Stripe 共事，如今直接负责 Claude 平台、模型发布与开发者产品落地。她们谈的不是“模型多聪明”这种容易上头的话题，而是更具体也更棘手的部分：当 Claude 已经能写代码、跑 Agent、参与生产系统后，CPU 从哪来，权限怎么管，推理过程怎么保护，出了问题谁负责把关。

这期回答了 8 个问题：

1. 为什么一家大模型公司最紧缺的资源，竟然是 CPU 而非 GPU？
2. Claude 能重写整套 API 后，工程师真正还在负责什么？
3. 为什么一次模型发布的大部分工作，变成了安全政策与访问控制？
4. Anthropic 如何封堵推理链蒸馏，又不把 API 客户逼到无法使用？
5. 生产环境的 Agent 安全，关键为什么不在“把模型关进沙箱”？
6. 为什么 Anthropic 认为最有价值的模型反馈往往是负面反馈？
7. 当 AI 让产出暴增，团队如何避免把“slop”转嫁给下游同事？
8. 既然每个人都想要不同性格的 Claude，默认模型还能如何设计？

被问到 Anthropic 当前最棘手的工程规模问题时，Angela Jiang 没有先谈 GPU，而是说 CPU 已高度受限。API、产品服务、沙箱、CI 持续集成，以及研究沙箱和产品沙箱，都在争同一池 CPU。过去只要预算够，CPU 往往可以随用随扩；现在团队必须提前做容量规划，连“多跑一次测试”都会变成资源分配问题。

他们预判会撞上 CPU 墙后，决定把 Messages API 从 Python 单体迁移到 Rust。这个选择在纸面上很合理，现实里却很冒险：启动项目时，房间里没有一位 Rust 开发者。团队没有让 Claude 按模块一点点重写，而是先完整构建了一套 Rust 版 API，再把真实但不影响用户的 shadow traffic 导进去，比对 Python 与 Rust 的输出，随后用负载均衡和 feature flags 一点点放量。Angela 对这件事的总结是："the two things that mattered most were the plan to do the thing and then the verification of the thing"（最重要的两件事，是先规划要做什么，以及验证它是否做对。）

结果是，迁移节省了约 40% 至 50% 的 CPU，首 token 时间改善约 10% 至 20%。这意味着，AI 把“写出代码”的速度拉高后，基础设施改造的瓶颈不再只是有没有人掌握某门语言，而是能否先画对系统蓝图，再搭出足以承受真实流量的验证网。模型可以铺路，但仍不能被丢一句“good luck Claude”就独立改造、上线并运营大规模系统；架构、放量和事故责任还得由人接住。

被问到发布 Opus 5.5 这类前沿模型，和早期发布有什么不同时，Katelyn 给出的答案很直接：过去不需要考虑的工作，现在成了大头。模型训练完，并不代表它已经是一个可发布的产品。团队还要逐项决定安全政策、线上 safeguard、离线 safeguard 和访问控制怎么落到实际系统里。

数据留存就是一个例子。Opus 5.5 没有 Fable 所具备的数据留存要求，这不是一套规则自动套用，而是每次发布都要重新判断：这款模型有什么能力，可能被怎样使用，需要保留什么数据，才能在事后做自动审查或人工审查。对网络安全场景，Anthropic 建了 cyber verification program；又新增了 life science verification program。它们的作用不是简单“开通高级功能”，而是让特定用途、特定用户在经过核验后，获得对应的模型能力和线上保护配置。

因此团队还专门做了一套强授权系统。它不是发一个 API key、开一个 feature flag 就结束，而是要确保“谁被允许使用哪个模型、哪个计划”，这份授权能贯穿整套系统。换句话说，权限不能只停在产品页面上，必须跟着每一次请求流动。

这意味着，能力越强的模型，发布节奏越可能被治理系统决定，而不是单由训练进度决定。安全政策也不能一刀切：同一家公司对不同模型采用不同留存要求，恰好说明每次上线都在重新平衡能力、用途与风险，而不是拿一份旧清单打勾。

被问到研究者披露的推理链提取技术时，两人解释，chain-of-thought extraction，也就是从模型思考过程里提取可复用的推理轨迹，一直是蒸馏模型最强大的办法之一。蒸馏并不只是“别人学走了你的能力”的商业问题。Anthropic 更在意的是：如果有人拿到能力后，去掉原模型运行时附带的安全分类器和 safeguard，模型可能被用于恶意目的。

补洞的办法，是跨轮次强制保留 thinking blocks，也就是模型先前生成的思考块不能被用户任意抽走、改写或拼接；团队还开始处理多账户协作等场景，减少用户把推理链提取出来再复用的机会。但这项变化会直接撞上客户已有的工作流。许多开源 harness 维护者——也就是维护模型运行框架的人——需要升级；一些大客户原本还依赖 compaction 策略，即把长对话压缩成更短上下文来继续跑任务，而保留 thinking blocks 会打断他们原来的手工实现。

Anthropic 没有直接把接口封死，而是在改动前联系了许多开源维护者，并在 API 中新增 compaction feature，给客户一条替代路径。修补之后，从可观测指标看，蒸馏已显著变难。

这意味着，模型安全不是研究团队在后台加一层过滤器就结束，它会改变 API 契约：调用者能传什么、状态怎么保存、上下文如何压缩，都会变。真正难的不是宣布一项限制，而是避免第二类体验损失：客户不只是“集成改起来麻烦”，而是从此无法完成原本能完成的事。安全升级若没有迁移工具，最后只会逼客户绕路。

被问到 Agent 频繁出现沙箱逃逸事件时，Katelyn 的重点不是“把沙箱做得更牢”，而是先别把所有东西放进同一个箱子。Claude Managed Agents 的架构把 harness，也就是负责任务编排、状态和调用流程的运行层，放在 durable server 上；真正执行代码的部分才放进独立 sandbox 或 container。她把这个结构称为“brain”和“hands”分离。

这套设计最初主要为延迟和可靠性服务。Agent 不必等沙箱启动后才返回第一个 token；即使沙箱死掉，整个 Agent 也不会连带消失，因为状态和运行框架留在另一侧。但安全上的收益更大：外部服务的凭证不放给 Agent，而是存进独立 vault。Agent 只看得到占位符；真正要调用 MCP 服务、CLI 或 API 时，egress proxy 才从 vault 中取出正确凭证并注入请求。正如她所说："the agent is never like in the same place where the credentials are"（Agent 永远不会和凭证处在同一个地方。）

此外，沙箱可配置 domain allow list，限制代码只能访问指定域名，甚至可以完全关闭网络。这样，即使 Agent 写出了不可信代码，它也不能随便连到互联网。

这意味着，生产级 Agent 的安全重点不是反复提醒模型“不要干坏事”，而是通过系统边界让一些坏事在结构上就做不成。密钥不在代码环境里，代码就偷不到；网络不通，代码就出不去。边界也在持续演化：长时间运行的 Agent 仍是新领域，整个行业都在部署中补齐控制机制，并没有一套已经封顶的标准答案。

被问到模型上线前如何获得客户反馈，以及 eval 应该怎么做时，Angela 讲的是一条很朴素的链路：先内部 ant fooding，也就是员工自己用候选模型做日常工作；再交给第一方产品和早期 API 客户测试。能进入早期访问计划的客户，通常不是因为名气大，而是因为他们有健壮的 eval suite，能快速跑完整套评测，并返回可以行动的结果。

这些反馈里，最有用的并不是“模型很好”。Angela 说："Honestly, the most useful feedback is negative."（坦白说，最有用的反馈是负面反馈。） 例如，客户会指出模型在哪些任务上做得差、在哪个环节变慢、在某类工具调用中开始犯错。一次早期版本测试中，团队发现模型太懒，不愿主动把任务做完，于是把它“put it back in the oven for a bit”，继续训练，试图把这种倾向压回去。

这也解释了为什么 Anthropic 反复强调 eval 数量要更多，而不是急着寻找一套万能评分表。模型行为并不完全确定；同一个“主动”特征，对一类用户是省事，对另一类用户却是越权——前者希望 Claude 直接写完代码，后者只想讨论方案，讨厌它未经允许开始大改文件。

这意味着，模型质量越来越由真实 harness 中暴露的失败模式定义，而不只是实验室基准的排名。没有持续 eval 的团队，很难跟上模型快速更替，因为它们连“新模型究竟让自己的任务变好还是变坏”都无法迅速判断。与此同时，评测不会消灭基于感觉的反馈；它的作用是让这些感觉有地方落地、被复现和被修复。

被问到团队怎么对抗 AI 生成的低质量内容时，Katelyn 没有把问题归咎于模型。她把这种低质量产出称为 slop：它可能是一份文档、一段代码，表面完整，实际却没有经过作者理解、核对和取舍。问题不在于 Claude 参与了写作，而在于作者把解析和纠错成本扔给了下游读者或代码审查者。

她的原则很清楚："You as the human are still responsible for the quality."（作为人，你仍然要对质量负责。） 团队成员可以让 Claude 帮忙生成代码和文档，但如果本人没有认真阅读、把关，收到内容的人就应该直接退回。因为对方要花额外时间辨别哪些内容可靠、哪些结论有依据、哪些实现会出错，这笔账不能由消费者承担。

在工程上，Anthropic 的做法也不是要求人逐行手写。人的重心更多放在系统设计和整体计划，具体实现可以由 Claude 大量完成；但上线质量要靠验证体系兜住。这里的“验证”包括测试、输出比对和逐步放量，而不是看一眼代码长得像不像人写的。

边界在于，团队也不该把一个 em dash 之类的“Claudism”当成低质量铁证。有时作者已经认真审过，只是文字留下了模型协作的痕迹。真正该问的是：谁对结果负责，谁承担验证成本。AI 让产出量暴涨后，稀缺的反而是判断力——能把不可靠内容挡在自己这一环，而不是顺手往下游传。

被问到默认人格、主动程度与用户个性化需求怎么兼容时，两人先承认一个现实：同一项模型行为，在不同用户眼里可能完全相反。有人嫌 Claude 懒，希望它接到任务就直接完成；有人只想一起推演方案，看到它未经同意写出一大段代码就很反感。所谓“更好用的默认模型”，并不存在一条所有人同意的直线。

Anthropic 现在主要靠轻量定制处理这个问题：用 effort、预算等参数控制模型投入多少推理和行动；再针对免费用户、专业用户、Claude Code、Co-work、企业和 API 设置不同默认值。问题是，这些参数逐渐堆成了一个“funny mishmash”——用户面对 effort、budgets 等多个控制项，很难知道某项任务该选什么组合。

Katelyn 对现状的评价并不客气："we're not like super super happy with any of this yet"（我们对现在这些做法还远谈不上满意。） 团队正在判断哪些参数应该废弃，哪些该由系统给出更好的默认值，以及控制方式到底该用 low、medium、high 三档，还是 1 到 100 的连续刻度。

这意味着，下一阶段模型产品的竞争不只是默认能力谁更强，而是谁能持续理解用户的偏好，并在成本、速度、主动性之间自动调节。当前靠产品团队在冲突反馈中做主观判断的方式，用户少时还能运转，规模更大后就会失灵。参数本身只是过渡物；用户真正想表达的不是“给我 72 点 effort”，而是“这次先和我讨论，别替我做决定”。

在节目结尾被问到，开发者该如何用 Opus 5.5 尝试 multi-agent 系统时，Angela 给出的建议意外地不复杂：先有一个 lead Agent，再把确实能并行的任务拆出去。她的原话是："you want to have one lead and you want to like split up like a bunch of different stuff"（你需要一个主导者，然后把一大堆工作拆分出去。）

她给出两个比“角色设计”更重要的架构条件。第一，子 Agent 共享统一上下文。否则每个 Agent 都在自己的信息孤岛里工作，反复调查相同问题，甚至得出互相矛盾的结论。第二，子 Agent 必须异步，不能互相阻塞。任务拆得再漂亮，如果每一步都要等上一步回信，本质仍是一条慢队列。

Anthropic 的 Dreaming 就是这种思路的例子。它构建在 Claude Managed Agents 上：系统会启动另一个 managed agent，检查前一个 Agent 的过程，再为它写入 memories。团队还提到 best-of-N、verifier agent 等策略，并计划开放更底层的 primitive，让开发者自己拼出多 Agent 策略。

这意味着，多 Agent 的价值不主要来自给模型套上“研究员、工程师、审稿人、经理”这些华丽头衔，而来自任务到底能否真并行、信息能否共享、调度是否避免等待。它更像一个协作系统，而不是一场角色扮演。边界也很明确：只有能并行化的问题才会受益。把强依赖的流程硬拆成多个 Agent，只会额外制造沟通和协调成本。

“CPU 才是瓶颈”和“Agent 安全要拆开大脑、手和密钥”，表面上一个在谈成本，一个在谈安全，实际上都指向同一件事：模型只是大脑，真正决定它能否进入真实工作流的，是围绕大脑搭出来的系统边界。

Rust 迁移能省下 40% 至 50% 的 CPU，不是因为“让模型写代码”这件事本身神奇，而是因为团队先做了完整迁移计划，再用 shadow traffic、输出比对、feature flags 把风险切碎。“防蒸馏不能靠封死接口”也是同样的逻辑：安全限制必须配合 compaction feature、开源 harness 升级和客户迁移路径，才能从政策变成可执行的产品现实。

“最有价值的是负面反馈”与“人仍要为质量负责”也在说同一件事。模型越会生成，组织越不能把判断责任外包给模型，更不能把没审过的内容塞给下游。你需要 eval 来发现失败，需要验证来约束实现，也需要明确谁有权决定模型能访问什么、能做什么。

对使用 AI 的团队来说，真正的问题不再只是“要不要接入最新模型”。更现实的问题是：你的任务有没有可测的成功标准？模型生成的东西由谁验收？它拿到的权限是否超出必要范围？当它更快地产出十倍内容时，是否也把十倍审稿成本甩给了同事？模型能力会继续上升，但能把能力变成稳定结果的，始终是这些不那么显眼的系统、流程和责任边界。