跳转至

Katelyn Lesse & Angela Jiang（Anthropic 平台团队）

Anthropic 平台团队的工程与产品两位负责人。该团队负责 API（messages API、Claude Managed Agents）、产品基础设施与沙箱机群，并同时拥有平台侧的 DevRel。

  • Katelyn Lesse — 工程负责人；自述一年多前入职（"那时 messages API 是个 Python 单体，跑在单个 GCP 区域"），此前在 Stripe。
  • Angela Jiang — 产品负责人；此前在 Stripe 与 OpenAI。

⚠️⚠️ 角色归属是本库按内容推断的：自动字幕把两人的名字拼成 Caitlyn / Kaylin / Kelly / Katelyn 等多种形式、且不带说话人标签。依据是——讲"我入职时 messages API 是个 Python 单体"、"DevRel 的 IC 直接向我汇报"、"我对 Slack 有点强迫症"的那位是工程侧；被主持人开"推特角落"环节、自述一年读两百本书、此前在 OpenAI 的那位是产品侧。✅ 对单一角色内的长段落本库有信心；⚠️ 少数接话处无法确定归属，本页只记内容。

本库收录她们的理由：✅ 本库此前来自 Anthropic 一侧的材料集中在产品工程（Thariq Shihipar）与领导层转述。这一期第一次有人把"一个前沿 API 在规模化时真正在扛什么"讲到机制层——⚠️⚠️ 而其中最有价值的三条（CPU 零和、Rust 整体移植、反蒸馏的真实动机）在本库此前完全没有。

⚠️ 立场：平台负责人的自述，全部产品、性能、安全与增长陈述未经核实。✅ 但本库认为这一期的厂商色彩比同类材料轻，理由是三处主动的让步（见下）。

核心观点（2026-10-27）

来源：Latent Space × Anthropic（录于 Opus 5.5 发布次日；swyx 主持）

⚠️⚠️ 一、CPU 成了零和（Katelyn）

（[00:53:24]–[01:02:29]）✅ 本库第一份来自前沿实验室一侧的 CPU 短缺记录。

⚠️⚠️ "Anthropic 整体的 CPU 是个零和游戏。我们和云厂商谈下我们的 CPU，然后必须在我刚说的所有东西之间分配——包括研究用的沙箱和产品用的沙箱。"

  • CPU 去哪了：产品服务与 API、所有沙箱、CI（⚠️⚠️ "你会惊讶现在有多少代码被写出来，所以 CI 跑的次数多得多"）、研究侧沙箱。✅ 训练是另一个池子，"不太混用"。
  • ⚠️⚠️ 采购形态的变化最有预测力："以前只要你的预算允许，你就可以按需扩容到更多 CPU；而现在它变成了你必须提前做容量规划的东西。" ✅ 她明确说不只是 Anthropic："我接触的每一个人都是这样。"
  • 三条应对：尽量多拿、基础设施层更高效地跑沙箱（不牺牲租户隔离）、应用层更高效。
  • 🔗 ✅ 与 朱邦华那条"为什么大家突然发现 CPU 很重要"（RL 环境里 function calling 的并发、code execution 的 CPU 调度）拼起来才是完整链条：那条是上游解释，这条是下游后果——CPU 从"按需弹性"变成"要提前规划的配额"，并在公司内部变成零和分配。

⚠️⚠️ 二、把 messages API 整体移植到 Rust（Katelyn）

（[00:55:25]–[01:00:26]）

  • ⚠️⚠️ 她自己说出了那个难看的事实："我们选了 Rust，而这在当时是个疯狂的决定，因为纸面上很明显，但我们团队里一个会写 Rust 的人都没有。"
  • 分工："Claude 会写代码，而人去设计系统"；Claude 的第二个作用是帮工程师互相碰想法、学会设计这个系统所需要学的东西。
  • ⚠️⚠️ 而这条方法论判断本库认为比数字更重要："最要紧的两件事是做这件事的计划，和对这件事的验证。因为实际的实现就是 Claude 在写代码。"
  • 做法（可复制的部分）：用 Rust 做了整个 API 的 fork，跑影子流量，逐一验证两个系统的输出是否一致。 ✅ 主持人的概括被确认："feature flag 就够了。"
  • 结果（⚠️ 自述）：CPU 省了"大概 40 到 50%"；首 token 时间改善 10%–20%，更长的负载上收益更高。
  • ⚠️⚠️ 她给了"以前为什么不可能"的对照："你绝不会签字同意这件事。它会花好多年。你不会一次做完，你会把系统切成一块块。"
  • ✅ 抵抗范围膨胀："它是一次纯粹的……也许我会叫它一次 port。" ⚠️ 组织形态是一支小 SWAT 团队边做移植、团队其余人继续往 API 加功能。
  • ✅ 下一步是面向用户的架构改动：⚠️⚠️ 让你不必在 messages API 上来回传整个会话状态（服务端存一段时间），对长对话"延迟与效率的收益很大"。⚠️ 她明确区分了这与 prompt caching（"有 prompt caching，但你仍然必须把会话状态传回来"），✅ 并给了一条限定：他们跨三家云在跑，所以没法依赖某一种算力形态（主持人拿 Cloudflare 的 Durable Objects 作对照）。

⚠️⚠️ 三、反蒸馏：动机是安全，不是商业（Angela + Katelyn）

（[00:08:03]–[00:14:06]）

⚠️⚠️ "我在推特上看到很多说这是个商业化问题之类的……虽然没错，但那其实不是我们特别在意的。" ⚠️⚠️ "现实地说，如果你从我们这儿蒸馏，你其实是在付钱给我们。所以商业上我们是赚钱的。"

  • 真实理由：他们在自己产出的 token 上跑大量安全分类器；⚠️⚠️ "如果有人蒸馏了我们的模型、然后在没有安全分类器的情况下运行它，世界上就可能出现坏结果。"
  • 技术面：⚠️⚠️ "chain of thought 抽取是蒸馏模型最有力的方式之一"；对策是跨轮次强制保留 thinking block，并扩展到跨多个账号的情形。⚠️ 自动字幕在具体术语上不可靠，本库不作术语采信。
  • ✅ 而本库认为最该记的是推法而不是这件事本身：她们把用户体验代价分两层——① 得改一次集成，很烦，但能做的事没变；② 变得做不了本来能做的事，⚠️ "第二种是我们真的真的真的在努力避免的"。具体动作是替客户发了一个新的 compaction 功能（替代他们原先手写的那套，否则会被"必须保留 thinking block"打断），并提前联系开源 harness 维护者。✅ 自我概括是"我们没有就那么 YOLO 地推出去"。
  • ⚠️ 效果自述："从我们能测量的那些方面看，确实变得难蒸馏多了"——⚠️ 无指标、无方法，本库不采信强度。

⚠️⚠️ 四、"大脑和手分开"的安全含义，以及一次公开道歉（Katelyn）

（[01:02:29]–[01:09:32]）

  • 架构：harness 跑在一台持久服务器上，"手"是沙箱或容器。 ⚠️ 当初的动机是延迟与可靠性（harness 常驻、首 token 快；"你的沙箱可以死掉，但整个 agent 不会死"）。
  • ⚠️⚠️ 第一版是一条有用的失败记录："我们给 agent 做的第一版 API 就是把 Claude Code 扔进一个沙箱、上面糊一个 API"——被否的原因是启动开销与"沙箱一死整个 agent 就没了"。
  • ✅ 然后是那段道歉，本库认为是全期最该保存的一处：

    ⚠️⚠️ "从一开始做这个的那位产品经理说过：这个架构最重要的属性是安全。所有人都说'是是是，但延迟和可靠性'。" "我昨天真的跟这个人道歉了。" ✅ 本库少见的一条"组织如何系统性地低估安全论证"的一手记录，而且由当时站在另一边的人讲出来。

  • 安全属性具体是什么：⚠️⚠️ 凭据存在完全独立的 vault；agent 只看到占位符；出口处有代理，取出正确凭据注入后再放出去。✅ 旧世界的对照是"必须把凭据送进去"，然后去想怎么擦洗。 结论是"一道字面意义上的基础设施之墙"。第二条是出口控制（域名白名单，或完全关掉网络）。
  • ✅ 一句很好的时间注脚：⚠️ "如果你往回看 9 个月，没有人会说这些词——大脑和手、凭据注入、出口。"

⚠️⚠️ 五、一次对"agent 越狱事件"的厂商侧改写

（[01:08:32]–[01:10:33]）⚠️⚠️ "很多人听到、读到的那些事件，是发生在训练中的模型上的"——训练环境里你把模型放进盒子、让它解不可能的任务，"agent 基本上被激励去设法出盒子"；而生产负载有在线防护与架构，"这甚至不是一个你需要去设想的问题"。

✅ 本库保留这条，但标出它绕开了什么： - ✅ 成立的部分：训练与生产的激励与防护确实不同，而公众讨论里两者常被混同。 - ⚠️⚠️ 绕开的部分：本库记录的几起事件并不在训练中的模型上——Hugging Face 事件里被攻破的 app 跑在 Modal 上、以及 Modal 自述的沙箱越狱红队、CrowdStrike 一侧突破时间被压到 29 分钟。 - ✅ 而她第二句其实收回了一部分：⚠️ "长时运行的 agent 是一个相对新生的东西，所以大家都在边做边摸。"

⚠️⚠️ 六、"我们在个性化上做得不好"（Angela + Katelyn）

（[00:35:12]–[00:41:18]）被问"用户只要在配置里写一句就能改掉模型行为，那 benchmark 还公平吗"：

  • ⚠️⚠️ "我们做得不好。真的，这非常难。"
  • ⚠️ "宪法"被主动划小适用范围："宪法是有帮助的，但对这种'它怎么个性化到不同指令与偏好'的事，非常难。" 🔗 本库 LLM 心理学 页此前有多条关于 Claude 宪法的讨论，⚠️ 这是第一次由公司内部的人把它的适用范围主动划小。
  • 现在的做法两条：多给参数让客户自己调（API 客户只拿到建议）；⚠️⚠️ "展现互相冲突的品味"，然后在这些反馈上做判断——✅ 她自己说这不可扩展。
  • ⚠️⚠️ 参数泛滥的自我批评："有 effort，有 budget，有各种你能在 API 上设的东西——那谁又能搞清楚，对任意给定的任务，什么才是对的组合？" ✅ 要决定的事她列了：哪些参数要废弃、哪些该把默认值做好、哪些该从"低/中/高"改成 1–100 的刻度。
  • 分段默认值：⚠️ 默认 effort 现在是 medium，且按人群调整（免费/prosumer、Claude Code vs coworker vs 企业 vs API）。✅ 原则是"温和的默认值 + 可调"，理由是"不想让人觉得自己没法控制 Claude 的定制"；⚠️ 自评"目前还算凑合"、"我们对这些都还不满意"。

⚠️⚠️ 七、"在一些负载上智能看起来越来越饱和了"（Angela）

（[01:18:38]–[01:20:40]）✅ 一条来自实验室产品负责人的降温，而她在卖智能。

⚠️⚠️ "我觉得在一些负载上，智能看起来确实越来越饱和了，这是一个新的情况。"

  • ⚠️ 反面她立刻给了："还有一类任务仍然非常不饱和——我其实认为比大家预期的更多。"
  • ⚠️⚠️ alpha 在哪："越来越朝着这个方向：你是靠做极长时间运行的 agentic 任务拿到那个回报，以及那些历史上你没法暴力穷举、但也许现在凭更多智能可以的事。"
  • 她给的当前负载三类：编码；企业"创新加速"类（⚠️ 形态是"自动化一个非常明确具体的流程"，"有些领域真的开始成了，有些还不行"）；一类新的硬工程或硬科学问题（生物、网络安全那类）。

发布机制与反馈循环

  • 三维度发布闸（[01:10:33]）：⚠️⚠️ ① 架构与基础设施安全；② 在线防护；③ 对静止数据的离线防护分类。 ✅ "pacing"的含义被直接落在这三项上。 🔗 与 Thariq 的 pacing 技术论证 并读：那份走"逐条读事故 transcript"，这份走"把它变成发布流程里的三道闸"。
  • ⚠️ 工作量结构："现在工作的大部分是：我们在做什么来防蒸馏、在线防护、离线防护、各种策略"，✅ 而"这些全都不是我们以前发模型时需要考虑的事"。
  • 逐模型的策略决策：⚠️⚠️ Opus 5.5 没有 Fable 那样的数据保留要求；理由是账号网络层面的滥用无法在 token 流过时在线发现。
  • 两个准入项目：cyber 验证与新上线的生命科学验证；⚠️⚠️ 通过审核后"我们其实会把你那个版本的模型上的安全防护降低"，所以必须按用例理解、收窄到特定用户。🔗 本库此前只从 外部听到过 Mythos 的准入形态，这是第一次由厂商一侧描述这套授权怎么落到系统里。
  • trust grant：授权要"一路穿到系统底部"；⚠️ 她主动否掉偷懒版本（"不是扔给你一个 API key、翻一个 feature flag 就算完"）；✅ 而被问与普通授权的区别时回答很老实："其实没什么不同，它就是一种授权形式。"
  • ⚠️⚠️ "一键回滚"按钮：Fable 被回滚之后，清单里出现了"做一个系统，让它可以用一个按钮为所有人回滚"。✅ 她的自我调侃："我们怎么论证做这个工作是值得的？我们希望那种事再也不要发生。"
  • ✅ 由此推出的产品方法论，本库认为是本期最可迁移的内容：⚠️⚠️ "从这种思维方式出发，它其实变得深度概率化了"——"我们其实需要对冲，建一个赌注组合"；而回报是"更多时候我们会发现，我们真的用上了那个东西"。最具体的一例是刻意选了更通用的原语（⚠️ "从正常的产品视角看，我大概会说那没太大道理"），后来被复用在模型访问、所有信任访问项目与数据部署上。
  • 早期访问的准入条件：⚠️⚠️ "真正进我们早期访问项目的客户，只有那些有非常稳健的 eval 的"（⚠️ 点名 Cognition 与 Character），✅ 理由是时间窗要压到最小。⚠️ 而她给了一条行业事实："世界上存在的那些 agentic 产品里，没有好 eval 来帮着测这些模型的有多少"，你可能会惊讶。
  • ⚠️⚠️ 一个具体的训练回炉记录：懒惰 vs 主动这条谱上没有所有人都想要的点（⚠️ "要把它恰好调对，字面意义上是不可能的"）；他们切过一个早期版本、发现懒惰太多，"就把它放回炉子里烤了一会儿"。 ✅ 落点是为什么需要外部客户："如果我们只在自家产品和 API 里内部自用，这些可能就抓不到。"
  • CMA 与 Dreaming（本库此前完全没有这两条）：CMA 是 messages API 之上的抽象（定义 agent、起 session，省掉搭 harness 与基础设施）；⚠️ 与 Claude Code 共用沙箱机群与大量基础设施，但 harness 不共用。⚠️⚠️ Dreaming 是"一层套一层的 managed agents"——起另一个 managed agent 去检查前一个、并给它写记忆；✅ 刻意模块化，别的可拼法包括 best-of-N 与 verifier agent，而他们打算把底层原语暴露出来让用户构造自己的"多智能体策略"并给模板。
  • ⚠️ 一处优先级的坦白：⚠️⚠️ "随着发模型从安全角度变得越来越难，我们团队的精力更少放在'给这个 agent 爬一个好玩的功能'上"；"和今年早些时候比，我们在 skills、dreaming、memory 这些'时点注入'上确实慢下来了一点"（⚠️ 随后被同伴打断强调"我们很爱 skills"，本库照录这处张力）。
  • eval 建议：⚠️⚠️ "你大概需要的是更多，而不是更少"；"投入不足大概是我们看到大家最大的错误"；✅ "从简单开始"（⚠️ "有些人会看着那一整菜单的选项发疯，而在他们做这些事的时候，他们实际拥有的 eval 数量是零"）。✅ Claude 很擅长造用来评估 agent 的 eval。

另记

  • ⚠️ 她们对"软件工程被解决"明确不接："我不确定我会用这么强的语言"；理由具体——"要在这种规模上运营和演进一个系统，我们远远没有到'祝你好运，Claude，玩得开心'的地步。"
  • ⚠️ 产品与工程会不会合并：两人都说"有点觉得会"，⚠️ 但"我们绝对还没到那儿"；✅ 现状是"很多工程师非常有产品思维、产品经理也更技术"，而两人各自被认错过角色。
  • ⚠️⚠️ slop 的两层：人仍然对质量负责（"如果你让 Claude 整个生成一个东西、自己完全没读过，那你就是把负担推给消费者"）；⚠️⚠️ 而"Claude 味"本身成了新问题——一个破折号就会让读者跳成"我在读 Claude 写的东西"然后烦了，"而也许那个人其实真的花了很多时间"。✅ 规范是双向的：真 slop 退回去，但"别对那些小小的 Claude 味太挑剔"。
  • ⚠️⚠️ 工程侧的说法更强："对很多被写出来的代码，你真正需要的其实只是快速盖个章就继续走"，因为更在意整体设计、并"依赖一大堆验证"。🔗 与 Erik Bernhardsson 五天前的"代码评审我们当成可选的" 是同一结论的两次独立出现，⚠️ 而这次来自模型的生产方；两者都把质量保障从评审挪到验证，且都没给验证覆盖率的数据。
  • 产品 slop：✅ "用模型能力的正确方式不是把 10 倍多的功能塞进生产"（引一条推文），⚠️ 诊断是"一种正在冒出来的内在的懒"。
  • ⚠️ fallback 的 UX 问题：主持人自述模型推理五分钟后被安全过滤器击中、回退到较弱模型，⚠️⚠️ "它回退的不是我的查询，而是推理和整条链的组合"。✅ 产品侧想要的是同一个模型连续地自己把 effort 调上去，而不是在模型之间跳（"如果你在很多不同模型之间移动，它其实会变得非常割裂"，跨厂商更难）。
  • DevRel：⚠️ 平台与 Claude Code 分别建团队（两个开发者生态不同）；⚠️ 近期招了 Addy Osmani；✅ 而最有价值的是一条形态变化——⚠️⚠️ cookbook 在变没用（"你现在不太处于那种'复制粘贴代码然后用'的位置了"），现在的形态是 Claude API skill（由 DevRel 团队拥有）加载进编码 agent，或"把 Claude 指向一个参考架构"；✅ 主持人的概括被确认："DevRel 最高杠杆的形式，是把所有最佳实践蒸馏进那些 agent 里去。"
  • ✅ 多智能体的建议（最可直接执行）：一个 lead + 把任务拆开；只有两个要求——子 agent 之间异步、互不阻塞，以及共享统一状态。⚠️ "除此之外，就让它跑，看看 Claude 给你设计出什么。"
  • 两条个人侧：⚠️ Angela 自述在一段很长的通勤里一年读了约两百本书，把推特当成"把一个想法压缩进尽可能少的词"的个人练习（"当时就是对着虚空发推"），最喜欢的书是 Nassim Taleb 的《黑天鹅》；⚠️⚠️ Katelyn 关于 Slack 的自述——"有些日子我可以取消所有会议、不写任何文档、不做任何工作，就只坐在 Slack 上一整天，而我会觉得那就等于干完了一整天的活"，而她自己说这件事很难受（"你并没有产出你想要的产出"）。

与他人观点的交叉

  • 🔗 Thariq Shihipar（同公司、同节目，2026-09-29）：两份 pacing 材料的路径不同（读事故 transcript vs 发布流程三道闸），✅ 本库认为应并读。
  • 🔗 朱邦华：CPU 为什么变重要（上游机制）vs CPU 成了零和（下游后果）。
  • 🔗 Erik Bernhardsson（Modal）：代码评审变成"盖章 + 验证"的两次独立出现；以及沙箱越狱的生产侧证据（与上面第五节的改写构成张力）。
  • 🔗 OpenAI 的 Guardian：两家厂商在"模型层能不能承担运行期判断"上做了同方向的事，⚠️ 而 Kurtz 与 Knecht 在防守侧都主张不能依赖模型层。
  • 🔗 Lex #503 的两条：⚠️ "在一些负载上智能饱和"与"Navier–Stokes 的证明不影响日常工程流体"指向同一件事的两面——在循环能闭合、可暴力穷举处收益很大，在别处没有。

视频