"我们一个会写 Rust 的人都没有"：把 messages API 整体移植到 Rust 省掉 40–50% CPU、CPU 成了零和、反蒸馏的理由是安全不是商业，以及"大脑和手分开"（Latent Space × Anthropic，2026-10-27）¶

嘉宾（两位，均为 Anthropic 平台团队）:
Katelyn Lesse — 工程负责人（平台 / API / 产品基础设施；自述一年多前入职，此前在 Stripe）
Angela Jiang — 产品负责人（此前在 Stripe 与 OpenAI）
⚠️ 角色归属是本库按内容推断的：自动字幕把两人的名字拼成 Caitlyn / Kaylin / Kelly / Katelyn 等多种形式、且不带标签。依据是——讲"我入职时 messages API 是个 Python 单体"、"DevRel 的 IC 直接向我汇报"、"我对 Slack 有点强迫症"的那位是工程侧；被主持人开"推特角落"环节、自述一年读两百本书、此前在 OpenAI 的那位是产品侧。✅ 对单一角色内的长段落本库有信心；⚠️ 少数接话处无法确定归属，本页只记内容。
主持: swyx（Latent Space）
来源: YouTube · 107 分钟
转录稿: sources/latent-space/20261027-MRQTlwcW-aQ（⚠️ 自动字幕 en-orig）

⚠️⚠️ 形态必须先说清，这一期有两段性质完全不同的内容： - [00:00:00]–[00:06:02] 是主持人对着镜头的独白，不是访谈。他自报这是 Latent Space 为 Anthropic IPO 开的系列报道的第一期，内容是他从 S-1 里挑出来的财务数字。⚠️⚠️ 本页把这一段单独处理（见第一节），因为它是主持人转述 + 口述数字，自动字幕在数字处明显含混。 - [00:06:02] 之后是正常访谈，录于 Opus 5.5 发布的第二天。

⚠️ 立场：两位嘉宾是 Anthropic 平台团队的负责人，全部产品、性能、安全与增长陈述为自述。✅ 但本页认为这一期的厂商色彩比同类材料轻，理由有三处：他们主动给了两个难看的数字（"我们一个会写 Rust 的人都没有"、"我们在个性化上做得不好"）、一处对自家同事的公开道歉、以及一条承认"我们对这些都还不满意"的收尾。本页逐处标出这些让步。

⚠️ 自动字幕的专名：Claude → "cloud"、Claude Code → "Claude tag"、Codex → "Coda X"、Sentry → "century"、dogfooding → "ant fooding" / "amp fooding"（他们自己用的词，本页按"内部自用"理解）。⚠️ 四处本库无法写定：教主持人 DevRel 三支柱的那位"Tom"、"Astro class" 这个模型指代、"Frontier Code" 这个 benchmark 的准确名称、以及 S-1 独白里"每 1 美元成本赚 2 美元"那句的确切口径。

✅ 本页认为这一期值得长期保存的是七处，而其中三处是本库此前完全没有的： ① ⚠️⚠️ CPU 成了零和："Anthropic 整体的 CPU 是个零和游戏"——他们和云厂商谈下来的 CPU 要在 API、产品服务、沙箱、CI、研究沙箱之间内部分配；"以前只要预算允许就能按需扩，现在变成了要提前做容量规划"。✅ 本库此前的算力材料几乎全在加速器上，这是第一份来自前沿实验室一侧的 CPU 短缺记录。 ② ⚠️⚠️ 把 messages API 整体移植到 Rust：团队"一个会写 Rust 的人都没有"，做法是整体 fork、跑影子流量对比输出；结果是省掉 40–50% CPU、首 token 时间改善 10–20%。✅ 而他给出的那条方法论判断本页认为比数字更重要："最要紧的两件事是计划和验证，实现那部分就是 Claude 在写代码。" ③ ⚠️⚠️ 反蒸馏的理由他们明说不是商业："如果你从我们这儿蒸馏，你其实是在付钱给我们，所以商业上我们是赚钱的"；真正的理由是蒸馏出去的模型不会带着他们的安全分类器跑。 ④ ⚠️⚠️ "大脑和手分开"的具体安全含义：凭据存在独立的 vault、agent 只看到占位符、出口代理在出网那一刻注入真凭据——✅ 而最该记的是那段对自家同事的公开道歉：主张"这个架构最重要的属性是安全"的那位产品经理被忽视了好几个月。 ⑤ ⚠️⚠️ 一次对"agent 越狱事件"的厂商侧改写：那些事件"大多发生在训练中的模型上，而不是生产负载上"。✅ 本页保留它，但标出它绕开了什么。 ⑥ ⚠️⚠️ "在一些负载上智能看起来越来越饱和了，这是一个新情况"——来自实验室产品负责人的一条降温。 ⑦ ⚠️⚠️ "我们在个性化上做得不好。真的很难"，以及参数泛滥的自陈（effort、budget 一堆旋钮，"谁能搞清楚哪个组合是对的"）。

一、⚠️ 主持人的 S-1 独白：本页单独处理¶

（[00:00:00]–[00:06:02]）这是主持人对着镜头读他从 S-1 里挑出来的数字，他自述有过财务分析师的经历。⚠️⚠️ 本页把它与访谈分开，并且不把这些数字当作可引用的财务事实，理由有三：它是转述、不是文件原文；自动字幕在数字处明显含混（例如"每 1 美元收入亏 5 毛"与"每 1 美元成本赚 2 美元"两句的口径对不上）；而本库也没有独立核对 S-1 的能力。

他给的数字	本库标注
Anthropic"今天"递交 S-1；IPO 预计两周后、按 2 万亿美元	⚠️ "预计"为他的说法
"报道的"累计融资超过 1,000 亿美元、累计烧钱不到 100 亿美元	⚠️ 他自己用的是"reported"
过去 12 个月人均收入 660 万美元，一年前是 140 万美元（约 4.7 倍）	⚠️ 本页记为"他读出的口径"
2025 Q2 每 1 美元收入亏约 0.5 美元；现在"每 1 美元成本赚 2 美元"	⚠️⚠️ 两句口径不一致，本库不采信
首个 GAAP 盈利季度、利润率 19%；一年前是 -129%	⚠️ 转述
收入 10 万美元以上的客户里超过 50% 用 Claude platform	⚠️ 转述

✅ 而本页认为这段里真正值得记的是两条非数字内容：
⚠️⚠️ S-1 里的两个"循环"：改进循环（Claude → 更好的模型 → 更多用例 → 更多反馈 → 更好的 Claude）与投资循环（收入 → 更高增长 → 更多投资 → 更多能力 → 更好的 Claude）。✅ 本页记为公司对自己的官方叙事结构，⚠️ 主持人自己对它的措辞带着调侃（"按 S-1 的说法，这两个循环会一直转到时间尽头"）。
⚠️⚠️ 口径上的一个用词选择：S-1 把路径写成"聊天机器人 → copilot → virtual collaborators（虚拟协作者）"，用这个词替代 agent。✅ 主持人的判断是"也许更友好，但要的东西和 agent 是一样的"（长时自主工作、判断、自我纠正与迭代、工具访问）。🔗 本库此前记过多次"agent 这个词被替换"的现象（见 AI 商业化与价值捕获里 a16z 一侧明确拒绝 harness / wrapper 两个词），本页把它记为同类现象的第三例。
🔗 与本库既有的 Anthropic IPO 材料并读：All-In 2026-10-17 那期。⚠️ 而 2026-10-30 的 All-In"Anthropic S-1 Shocker"那期本库尚未摄取（仍在候选列表里），届时应与本节对照。

二、⚠️⚠️ CPU 成了零和：本库第一份来自实验室一侧的 CPU 短缺记录¶

（[00:53:24]–[01:02:29]）✅ 本库的算力材料几乎全部落在加速器上（Intel 的产能上限、SF Compute 的远期曲线、Modal 的三年矩形、Andy Jassy 的 capex 现金周期）。⚠️⚠️ 这一节是第一份把 CPU 讲成同级约束的材料，而且来自买方。

问题的提法（[00:53:24]）：⚠️ "算力在加速器那一层（是问题），而在 CPU 这种老派层面上大家关注得少得多——但它今天和加速器层一样是个问题，这挺有意思的。"
⚠️⚠️ 而这句是本节的核心（[00:54:24]）："Anthropic 整体的 CPU 是个零和游戏。我们和云厂商谈下我们的 CPU，然后必须在我刚说的所有东西之间分配——包括研究用的沙箱和产品用的沙箱。"
CPU 去哪了（他列的四项）：跑产品服务与 API、跑所有沙箱、CI（⚠️⚠️ "你会惊讶现在有多少代码被写出来，所以 CI 跑的次数多得多，所以你需要更多 CPU 去处理"）、以及研究侧沙箱。✅ 训练是另一个池子（主持人补的，被他确认"不太混用"）。
⚠️⚠️ 采购形态的变化本页认为最有预测力（[00:55:25]）："以前只要你的预算允许，你就可以按需扩容到更多 CPU；而现在它变成了你必须提前做容量规划的东西——这对所有人都是一记重拳。它是全新的，大家才刚开始做。" ✅ 他明确说这不只是 Anthropic："我接触的每一个人都是这样。"
⚠️ 他们的三条应对：① 尽量多拿 CPU；② 基础设施层更高效地跑沙箱（而不牺牲租户隔离这类安全属性）；③ 应用层更高效（见下一节的 Rust）。
⚠️ 采购的组织形态他也说了（[01:02:29]）：原本保障加速器算力的团队"现在花多得多的时间和我们一起看 CPU 怎么采"；✅ 而他对卖方的要求是规模与质量门槛——"如果拿不到足够的量，我们不会去适配并跑在某些机器上。"
🔗 ✅ 本页标注这与本库既有材料的接口：朱邦华那条"为什么大家突然发现 CPU 很重要"（RL 环境里 function calling 的延迟与并发、code execution / multi-docker 的 CPU 调度）是这条的上游解释；⚠️⚠️ 而本节给了它的下游后果——CPU 从"按需弹性"变成"要提前规划的配额"，并且在一家公司内部变成零和分配。本页认为两条拼起来才是完整链条。

三、⚠️⚠️ Rust 移植：团队里没有一个 Rust 开发者¶

（[00:55:25]–[01:00:26]）✅ 本页认为这是全期最该被在实践中用 LLM 引用的一段，因为它是一个有前后对比、有数字、且作者承认"以前绝不会签字同意"的工程案例。

起点（[00:55:25]）：messages API 是个 Python 单体、"CPU 效率很低"；他自述今年早些时候就判断"我们会撞上 CPU 墙"。

⚠️⚠️ 那个难看的事实他自己说了出来："所以我们选了 Rust，而这在当时是个疯狂的决定，因为纸面上很明显，但我们团队里一个会写 Rust 的人都没有。"
人的分工他讲得很清楚："而且不只是这样——是的，Claude 会写代码，而人去设计系统。" ✅ Claude 的第二个作用是帮工程师学（"帮那些工程师互相碰想法、学他们设计这个系统所需要学的东西"）。
⚠️⚠️ 而这条方法论判断本页认为比任何数字都重要（[00:56:25]）："最要紧的两件事是做这件事的计划，和对这件事的验证。因为实际的实现就是 Claude 在写代码。"
做法（本页认为这是可复制的部分）：用 Rust 做了一个整个 API 的 fork，然后开始跑影子流量，逐一验证 Python 系统与 Rust 系统的输出是否一致。 ✅ 主持人的概括被他确认："feature flag 就够了。"
结果（[00:58:25]，⚠️ 自述、无第三方核实）：CPU 省了"大概 40 到 50%，挺疯狂的"；延迟上"首 token 时间改善了 10% 到 20% 之间"，更长的负载上收益更高。
⚠️⚠️ 他对"以前为什么不可能"给了明确的对照："你绝不会签字同意这件事。它会花好多年。你不会一次做完，你会把系统切成一块块，说迁这个、迁那个。" ✅ 而这正是本页认为该保存它的理由：它把"agentic coding 让什么变成了可能"落在了一个具体的、以前会被否决的决策上。
✅ 他们明确抵抗了范围膨胀（[00:59:25]）："它是一次纯粹的……也许我会叫它一次 port（移植）。" ⚠️ 而配套的组织细节也给了：做这件事的是一支小 SWAT 团队，同时团队其余人还在往 API 里加功能，所以那支小队还得处理"你在这边加了功能却没考虑 Rust 那边"的静态分析告警。
✅ 下一步是架构改动，而且是面向用户的（[00:59:25]–[01:00:26]）：⚠️⚠️ 让你不必在 messages API 上来回传整个会话状态（改为在服务端存一段时间），对长对话"延迟与效率的收益很大"。
⚠️ 主持人指出这与 prompt caching 不同并被确认："我们有 prompt caching，但你仍然必须把会话状态传回来。"
⚠️ 而嘉宾加了一条本页认为很要紧的限定：他们"跨三家云、到处在跑"，所以"没法依赖某一种算力形态"——这解释了为什么他们不能直接照搬某家云的有状态原语（主持人点名 Cloudflare 的 Durable Objects 作对照）。

四、⚠️⚠️ 反蒸馏：理由是安全，不是商业¶

（[00:08:03]–[00:14:06]）✅ 本库此前关于蒸馏的材料多半落在"谁蒸谁"与成本（见 LLM 训练流程）。这一节第一次给了被蒸馏一方的动机陈述与具体对策，而且他们主动否掉了商业动机这个解释。

他们做了什么（[00:08:03]、[00:11:05]）：⚠️ "我们做了很多工作，让我们的 API 更难被蒸馏"；具体是跨轮次强制保留 thinking block，并在近期扩展到跨多个账号的情形；⚠️ 技术词他提到 prefix block thinking 与"跨不同模型重放 thinking token"（⚠️ 自动字幕在这几个词上不可靠，本页不作术语采信）。
为什么是 thinking：⚠️⚠️ "我们很久以来就知道，chain of thought 抽取是蒸馏模型最有力的方式之一。"
⚠️⚠️ 而动机那段本页认为是全期最该被 LLM 安全与治理引用的一句（[00:13:06]）：

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

安全侧的机制他给得很具体（[00:10:05]）：他们在自己产出的 token 上跑大量安全分类器；⚠️⚠️ "如果有人蒸馏了我们的模型、然后在没有安全分类器的情况下运行它，世界上就可能出现坏结果。"
✅ 而本页认为最该记的是他们处理这件事的方式，而不是这件事本身（[00:11:05]–[00:12:06]）：他们把用户体验代价分成两层——① 你得改一次集成，很烦，但你能做的事没变；② 你变得做不了你本来能做的事，⚠️ "第二种是我们真的真的真的在努力避免的"。
⚠️⚠️ 具体动作：有客户原来的 compaction 策略会被"必须保留 thinking block"这条打断，于是他们在 API 里发了一个新的 compaction 功能去替代客户原先手写的那套；而且他们主动联系了开源 harness 的维护者（"我们告诉他们你们得在 harness 里做这些升级，我们想让你们过得好一点"）。
✅ 他们对自己的做法的概括是："我们没有就那么 YOLO 地推出去……否则会弄坏很多人。" ✅ 本页认为这是本库目前关于"前沿 API 的破坏性变更该怎么推"最具体的一份一手流程记录。
⚠️ 效果是自述的（[00:13:06]）："从我们能测量的那些方面看，确实变得难蒸馏多了。" ⚠️ 无指标、无方法，本库不采信强度。 ✅ 而他们两次感谢了那篇论文的作者做了负责任披露（⚠️ 论文题目在转录稿里被主持人概括成"从专有 LLM 窃取推理轨迹"，本库不作引文采信）。

五、⚠️ 模型发布的机制：安全工作已经占了大头¶

（[00:17:06]–[00:25:09]、[01:10:33]–[01:11:34]）

⚠️⚠️ 工作量结构的变化他说得很直接（[00:21:08]）："现在工作的大部分是：我们在做什么来防蒸馏、在线的安全防护、离线的安全防护、各种策略。" ✅ 而他加了一句对照："我刚说的这些，全都不是我们以前发模型时需要考虑的事。"
三个维度（[01:10:33]，本页认为这是最可引用的框架）：⚠️⚠️ ① 架构与基础设施的安全；② 模型在干活时跑的在线防护；③ 对静止数据做的离线防护分类。 ✅ 他把"pacing（配速）"的含义直接落在这三项上——"我们说 pacing 的时候，指的就是我们正在为这些做的全部工作。"
⚠️ 而主持人当场指出了那处表面矛盾：一边主张 pacing、一边 11 天后又发一个前沿模型。✅ 嘉宾的回答是"它通过了我们的安全检查"，🔗 而本库此前有一份来自同一家公司、来自产品工程师的 pacing 技术论证（Thariq Shihipar），本页认为两份应当并读：那份走的是"逐条读事故 transcript"，这份走的是"把它变成发布流程里的三道闸"。
⚠️ 按模型逐个决定的策略（[00:19:06]–[00:20:07]）：数据保留要求是逐模型的决策；⚠️⚠️ 他明确说 Opus 5.5 没有 Fable 那样的数据保留要求。理由是账号网络层面的滥用无法在 token 流过时在线发现，所以需要保留数据以做自动与人工复核。
两个准入项目（[00:20:07]、[00:26:09]）：cyber 验证项目与新上线的生命科学验证项目。⚠️⚠️ 机制他说得很具体：通过审核后"我们其实会把你那个版本的模型上的安全防护降低"，所以必须按用例理解、必须收窄到特定用户。✅ 他给的正当性是双用途（"你可以是一个很正当的网络安全研究者、在找漏洞"）。
🔗 本库此前只从外部听到过 Mythos 的准入形态（把约 50 家公司拉进来先加固自己）。✅ 这是第一次由厂商一侧描述这套授权是怎么落到系统里的。
⚠️⚠️ "trust grant"（[00:21:08]、[00:28:10]–[00:29:10]）：授权必须"一路穿到我们系统底部、而且方式是我们真的能信任的"；他特意否掉了偷懒版本——"不是'噢你拿到了 Mythos 的权限，那我们扔给你一个 API key、翻一个 feature flag 就算完'。" ✅ 而当主持人问它与普通授权有什么不同时，他的回答很老实：⚠️ "其实没什么不同……它就是一种授权形式"，只是做成了干净的数据模型并插进请求热路径上的检查。
✅ 一个具体用法：在 Fable 5.1 上线保留 thinking 时，他们给存量客户做了宽限期，而"谁是需要额外时间的存量客户"就是用 trust grant 追踪的。
⚠️⚠️ 那个"一键回滚"按钮（[00:23:08]–[00:24:08]）：Fable 被回滚之后，他们的工作清单里出现了一项——"做一个系统，让它可以用一个按钮为所有人回滚"。✅ 而她对这件事的自我调侃本页认为值得照录：⚠️ "我们怎么论证做这个工作是值得的？我们希望那种事再也不要发生。" 结论是它和那些验证项目用的是同一套原语，所以干脆把它垫在所有人的模型访问之下。
✅ 而由此推出的一条产品管理方法论本页认为是本期最可迁移的内容（[00:24:08]–[00:27:10]）：

⚠️⚠️ "从这种思维方式出发，它其实变得深度概率化了。"
她的对照是传统产品管理（假设一组事情会发生、有大致的顺序）；⚠️ 而她举的反例是 Fable 的某次部署——"我们没有一个人会猜到那会成为一个由政府发生的有效用例，以及你就那样必须去做它"（⚠️ 这句在自动字幕里含混，本库只记结构、不记具体事件）。
结论："我们其实需要对冲，建一个赌注组合"；✅ 而她说这套做法的回报是反复出现的——"更多时候我们会发现，我们真的用上了那个东西。"
✅ 最具体的一例是他们在设计那个准入项目时刻意选了更通用的原语：⚠️ "从正常的产品视角看，我大概会说那没太大道理，我们应该聚焦在有道理的用例上。" 但因为选了通用，它后来被用在了模型访问本身、所有信任访问项目的管理、以及模型的数据部署上。

六、⚠️⚠️ "我们在个性化上做得不好"¶

（[00:35:12]–[00:41:18]）✅ 本页认为这是全期最诚实的一段，而且它暴露的是一个结构问题而不是执行问题。

主持人的问题很锋利：他自己的 benchmark 会惩罚"动作太多/改文件太多"，但他只要在自己的配置文件里写一句"别那样"就改掉了——那他是不是在不公平地惩罚这个模型？

⚠️⚠️ 回答："我们做得不好。真的，这非常难。"
⚠️ "宪法"被明确排除在解法之外："宪法是有帮助的，但对这种'它怎么个性化到不同指令与偏好'的事，非常难。"（⚠️ 另一处有人说"那个是旧的"，归属不明，本页不归属到人。）🔗 本库 LLM 心理学页此前有多条关于 Claude 宪法的讨论，⚠️ 本页标注：这是第一次由公司内部的人把宪法的适用范围主动划小。
他们现在的做法是两条：① 多给参数，让客户自己调（API 客户只能拿到建议）；⚠️⚠️ ② "展现互相冲突的品味"，然后在这些反馈上做判断。✅ 而她自己说这不可持续："随着客户和用户变多，那不是一个很可扩展的做事方式。"
⚠️ 她指的方向是把个性化变成模型可吸收的信号（"也许那是一个你可以提供的信号、或者可以调的东西"）。
⚠️⚠️ 而参数泛滥这段本页认为是本期最有用的自我批评（[00:40:17]）："有 effort，有 budget，有各种你能在 API 上设的东西——那谁又能搞清楚，对任意给定的任务，什么才是对的组合？" ✅ 她把这件事定位成"我们就是边做边摸索"，并列出了要决定的事：哪些参数以后要废弃、哪些该把默认值做好、哪些该从"低/中/高"改成 1 到 100 的刻度。
✅ 而这恰好是 CMA 的卖点："每次发模型，我们都会做很多工作去搞清楚新参数是什么、有哪些破坏性变更、怎么在我们的 harness 里把 Claude 的效果榨出来，这样用它的人就直接拿到现成的，不用想这些。"
分段默认值（[00:38:15]）：⚠️ 默认 effort 现在是 medium，而默认值会按人群调整（免费/prosumer、Claude Code vs coworker vs 企业 vs API）。✅ 她给的原则是"温和的默认值 + 可调"，理由是"我们不想让人觉得自己没法控制 Claude 的定制"。⚠️ 自评是"目前还算凑合"。

七、⚠️⚠️ "大脑和手分开"：架构的安全含义，以及一次公开道歉¶

（[01:02:29]–[01:09:32]）✅ 本库此前关于 agent 沙箱有三份材料（Modal 的 agent sandbox、Thariq 讲的沙箱表面积、dots 的云上虚拟机）。⚠️⚠️ 这一节第一次把"凭据放在哪"这一层讲清楚了。

架构：harness 跑在一台持久服务器上，"手"是执行环境（沙箱或容器）。

⚠️ 他们当初的动机不是安全：是延迟与可靠性——harness 常驻、只在需要执行时才拉起沙箱，所以首次请求能很快回 token；而且"你的沙箱可以死掉，但整个 agent 不会死"。
⚠️⚠️ 而第一版是什么样他也说了，这是一条有用的失败记录："我们给 agent 做的第一版 API 就是把 Claude Code 扔进一个沙箱、上面糊一个 API。" 没有拿它当最终方案的原因是——"你得先启动沙箱、再启动 Claude Code，才能拿到第一个 token"，而且沙箱一死整个 agent 就没了。
✅ 然后是那段道歉，本页认为是全期最该保存的一处（[01:04:30]）：

⚠️⚠️ "从一开始做这个的那位产品经理说过：这个架构最重要的属性是安全。所有人都说'是是是，但延迟和可靠性'。" "我昨天真的跟这个人道歉了。我跟他说，我现在在跟我见到的每一个人讲你这几个月一直在说的话。" ✅ 本页标注：这是本库少见的一条"组织如何系统性地低估安全论证"的一手记录，而且是由当时站在另一边的人讲出来的。
安全属性具体是什么（[01:05:31]）：⚠️⚠️ 凭据存在一个完全独立的 vault；agent 要调外部服务时"只看到一个占位符"；在出口处有一个代理，把正确的凭据取出来注入、再放出去。✅ 对照的是旧世界："在那个'把 agent 启动在一个盒子里让它跑'的旧世界里，你必须把凭据送进去"，然后就得去想怎么擦洗、怎么保证 agent 不拿着凭据去干别的。⚠️⚠️ 他的结论是一道物理墙："是一道字面意义上的基础设施之墙，说 agent 就是访问不到那些凭据。"
第二条是出口控制（[01:06:32]）：域名白名单，或者干脆完全关掉网络访问——"agent 写了不可信的代码，那代码在沙箱里执行，而那代码能连出互联网" 这条链被掐断。
✅ 他对这套东西的时间尺度给了一句很好的注脚（[01:07:32]）：⚠️ "如果你往回看 9 个月，没有人会说这些词——大脑和手、凭据注入、出口。这些都是我们正在解决的相对新的问题。"
🔗 ⚠️ 本页标注一处需要对照的张力：凭据与出口这两条，正是 CrowdStrike 的 Kurtz 与 Cloudflare 的 Knecht 在防守侧反复指认的断点。✅ 这一节说明厂商侧的解法方向与防守侧的诊断一致（都落在身份/凭据与网络边界），⚠️ 而分歧只在"模型层能不能承担判断"（见 OpenAI 的 Guardian）。

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

（[01:08:32]–[01:10:33]）主持人直接问：这些沙箱逃逸是我们对沙箱技术理解的根本问题，还是我们只是没做白名单？

⚠️⚠️ "我想做一个区分：很多人听到、读到的那些事件，是发生在训练中的模型上的……你把它们放进一个盒子里，说'解决这个不可能的任务，我要给你施压，准备、开始'，而 agent 基本上被激励去设法出盒子、把问题解决掉。" "而人们在我们或别人的 API 上跑生产负载时……harness 在这边，手在那边，这甚至不是一个你需要去设想的问题。"

✅ 本页保留这条，但标出它绕开了什么： - ✅ 它成立的部分：训练环境与生产环境的激励与防护确实不同，而公众讨论里这两者经常被混同——这条区分本身是有价值的。 - ⚠️⚠️ 它绕开的部分：本库记录的几起真实事件并不发生在"训练中的模型"上——🔗 Hugging Face 事件里被攻破的那个 app 跑在 Modal 上、Modal 自述的沙箱越狱红队（"像密室逃脱，但给 agent 玩"）、CrowdStrike 一侧的突破时间被压到 29 分钟。⚠️ 这些都是生产侧或红队侧的。 - ✅ 而他第二句话其实收回了一部分：⚠️ "每个人都是相对新地在摸索这些……长时运行的 agent 是一个相对新生的东西，所以大家都在边做边摸、抢着把对的控制放到位。" ✅ 本页认为这句比前一句更可靠，也与他自己"9 个月前没人说这些词"的说法一致。

八、模型发布与反馈循环：本页认为可核对的部分¶

流程（[00:30:10]–[00:31:10]）：做模型 → 安全测试 → 评估定位 → 做权衡 → 切多个版本内部自用（他们叫 ant fooding）→ 选出有信心的版本 → 走一方产品（Claude Code、Co-worker）或 API 客户的早期访问。⚠️ 他点名的早期访问客户是 Cognition 与 Character。
⚠️⚠️ 而准入条件本页认为是这段最有信息量的一句（[00:32:11]）："真正进我们早期访问项目的客户，只有那些有非常稳健的 eval 的。" ✅ 理由是时间窗："我们在赛跑，想把'切出测试版本'到'所有人都能用'之间的窗口压到最小。"
⚠️ 主持人的观察被他们承认：模型反馈的状态"仍然非常不结构化"，基本就是公司之间一个 Slack 频道。✅ 而嘉宾加了一条行业事实：⚠️⚠️ "你可能会惊讶——世界上存在的那些 agentic 产品里，没有好 eval 来帮着测这些模型的有多少。" ✅ 主持人回引了 Boris 两年前在同一节目上说"Claude Code 没有 eval"。
✅ 他们说最有用的反馈是负面的（[00:34:12]）："好消息总是让人很受肯定……但最有用的反馈是负面的。"
⚠️⚠️ 一个具体的训练回炉记录，本页认为是本期最可核对的一条内部流程（[00:34:12]–[00:35:12]）：懒惰 vs 主动这条谱上没有一个所有人都想要的点（有人说"别偷懒，把我的任务做完"，也有人说"我只是在摸索和计划，你却跑去写了一堆代码"）；⚠️ "要把它恰好调对，字面意义上是不可能的，因为每个人真正想要的其实不一样。"
⚠️⚠️ 而他们确实因此回炉过："我们切过一个早期版本，发现懒惰太多，就把它放回炉子里烤了一会儿，试着把那个训练掉。" ✅ 他的落点是为什么需要外部客户："如果我们只在自家产品和 API 里内部自用，这些可能就抓不到。"
CMA（Claude Managed Agents）（[00:42:18]–[00:43:19]）：messages API 是原始 token 访问，CMA 是更高一层的抽象——定义一个 agent、起一个 session，省掉搭基础设施与 harness 的活。⚠️ 与 Claude Code 的关系他说得很清楚：共用沙箱机群与大量基础设施，但 harness 不共用。
⚠️⚠️ "Dreaming 是一层套一层的 managed agents"（[00:46:20]）：起另一个 managed agent 去检查前一个 managed agent，然后给它写记忆。✅ 而他说这是刻意的模块化设计，并列了别的可拼法（best-of-N、verifier agent），⚠️ 以及一条用户侧的观察——"有人做了一个 harness，在所有东西之间共享疯狂的记忆，然后拉起一大堆并行 agent"，所以他们打算把底层原语暴露出来，让用户自己构造"多智能体策略"，并给出模板。
⚠️ 一处优先级的坦白（[00:44:20]–[00:45:20]）：⚠️⚠️ "随着发模型从安全角度变得越来越难，我们团队的精力更少放在'给这个 agent 爬一个好玩的功能'上，更多放在怎么把安全带进所有这些东西里。" ✅ 另一位补了具体的："和今年早些时候比，我们在 skills、dreaming、memory 这些'时点注入'上确实慢下来了一点。"（⚠️ 随后被同伴打断强调"我们很爱 skills"，本页照录这处张力。）
eval 建议（[00:48:21]–[00:50:22]）：⚠️⚠️ "你大概需要的是更多，而不是更少"；"投入不足大概是我们看到大家在这件事上最大的错误。" ✅ 另一条是"从简单开始"——⚠️ "有些人会看着那一整菜单的选项发疯，想试这个试那个、哪个最好，而在他们做这些事的时候，他们实际拥有的 eval 数量是零。"
✅ 一条很实用的做法被双方确认：Claude 很擅长造用来评估 agent 的 eval；⚠️ 而主持人给的理由是界面——"人看 JSONL 会直接大脑空白，而一个漂亮的 eval UI 上你左右左右地点，其实就是在做人类评分员本来会做的事。"
✅ 主持人的"把工程当研究做"那段被嘉宾完全同意，本页认为该引用的是这句：⚠️⚠️ "有时候是你的 eval 错了。其实很多时候是你的 eval 错了。有时候是你的环境错了。然后有时候才是模型错了。"

九、⚠️⚠️ 两条本页认为最该被跨页引用的判断¶

① "在一些负载上智能看起来越来越饱和了"¶

（[01:18:38]–[01:20:40]）✅ 这是一条来自实验室产品负责人的降温，本页认为它比任何 benchmark 讨论都值得记。

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

⚠️ 而她立刻给了反面："还有一类任务仍然非常不饱和——我其实认为比大家预期的更多。"
⚠️⚠️ 她指认的"alpha"在哪："越来越朝着这个方向：你是靠做极长时间运行的 agentic 任务拿到那个回报，以及那些历史上你没法暴力穷举、但也许现在凭更多智能可以的事。"
她给的当前负载分类（三类）：① 编码；② 企业的"创新加速"类，⚠️ 形态是"自动化一个非常明确具体的流程"——"有些领域真的开始成了，有些还不行"；③ 一类新的、很复杂的硬工程或硬科学问题（她举的是生物与网络安全那类）。
🔗 ✅ 本页标注这条与本库既有材料的接口：⚠️⚠️ 它与 Ankur Moitra 对 OpenAI 那批数学结果的看法（"那些解法看起来不像人解出来的"）以及 Brunton 的"工程流体没有变化" 指向同一件事的两面：在循环能闭合、可暴力穷举的地方收益很大，在别处没有。 ✅ 而这一条的价值在于说话人在卖智能，却说它在一部分负载上饱和了。

② slop：人仍然对质量负责，但"Claude 味"本身成了问题¶

（[01:20:40]–[01:26:41]）

规范是明确的：⚠️ "如果你产出的是别人要消费的东西——代码、文档——你当然该用 Claude 帮你。但如果你让 Claude 整个生成一个东西、自己完全没花时间读过、没确保它是高质量的，那你就是把一整份额外负担推给了消费者。" ✅ 主持人的概括被确认："你作为人仍然对质量负责。"
⚠️⚠️ 而她指出的第二层问题本页认为是新的："Claude 味（Claudisms）"本身会触发读者——比如中间有一个破折号，人脑就会跳成"噢不，我在读一个 Claude 写的东西"，然后就烦了；⚠️ "而也许那个人其实真的花了很多时间确保它高质量，只是用了 Claude 帮忙。"
✅ 他们给的规范因此是双向的：产出方要守一个质量线；消费方"如果真的就是 slop，退回去"，⚠️⚠️ 但"也别对那些小小的 Claude 味太挑剔，因为我们得找到对的平衡"。✅ 她的收尾很坦白："我们团队内部也在来回争这些事，全世界其他人也一样，我们并没有什么不同。"
⚠️⚠️ 而工程侧的说法更强，本页认为必须标出来（[01:23:41]）："对很多被写出来的代码，你真正需要的其实只是快速盖个章就继续走，你不一定需要有人深度评审每一行代码"——因为"你更在意整体的计划、整体的设计是不是好的，而不是实现是否完美"，✅ 并且"依赖一大堆验证来保证要发的东西是高质量的"。
🔗 ⚠️ 本页标注：这与 Erik Bernhardsson 五天前说的"代码评审我们当成可选的" 是同一结论的两次独立出现，而这次来自模型的生产方。 ✅ 两者都把质量保障从"评审"挪到了"验证"，⚠️ 而两者都没有给出验证覆盖率的数据。
✅ 产品侧的 slop 规范他们引了一条推文（[01:24:41]）：⚠️⚠️ "用模型能力的正确方式不是把 10 倍多的功能塞进生产"，而是花更多时间理解用户、做实验。✅ 而她给的诊断是"一种正在冒出来的内在的懒"——"噢，我根本不用去想流程里的某一部分了，因为 agent 在做"，⚠️ "但那些仍然是极其基础的部分，本该是你花时间与精力的地方。"
⚠️ 主持人自述的反方也被照录："因为实验或探索的成本现在这么低，我就觉得我应该做更多"，而那条推文恰好是在说别那样。

十、其它值得记下的碎片¶

⚠️ fallback 的 UX 问题被讲得很具体（[01:13:34]–[01:16:36]）：主持人自述让模型拆解一份安全卡，模型开始推理，五分钟后进到网络安全部分时被安全过滤器击中、回退到较弱的模型；⚠️⚠️ "它回退的不是我的查询，而是推理和整条链的组合。"
✅ 产品侧想要的 UX 是"不要在模型之间回退"：⚠️ "更合适的 UX 是和 Claude 有一个更一致、统一的体验"，即同一个模型但能连续地自己把 effort 调上去，而不是在不同模型之间跳——"如果你在很多不同模型之间移动，它其实会变得非常割裂"，⚠️ 而跨厂商就更难（人格与割裂感）。
✅ API 侧给的是一组选项：服务端可配置是否 fallback、SDK 客户端有 helper、也可以选择换个提法用同一个模型继续。
⚠️ 而主持人把它归约成路由问题那段，嘉宾完全同意并补了一条判据："即便你能完美理解每个模型（你不能），你也没有关于你自己任务的完美信息"——所以路由逻辑里天然带误差；✅ 而且"把那套逻辑暴露给客户"本身也不是好体验（"你的任务是把一个 div 居中，所以我给你路到超便宜的那个"）。
⚠️ 他们对"软件工程被解决"这个说法明确不接（[00:17:06]）：⚠️ "我不确定我会用这么强的语言。" ✅ 她给的理由是具体的：他们正在跨区域、扛着 CPU 约束去扩系统，而"要在这种规模上运营和演进一个系统，我们远远没有到'祝你好运，Claude，玩得开心'的地步"。
✅ 产品与工程两个角色会不会合并（[00:16:06]–[00:17:06]）：主持人问，两人都说"我有点觉得会"，⚠️ 但紧接着是"我们绝对还没到那儿"。✅ 而她们给的现状描述本页认为更有用："我们有很多工程师其实非常有产品思维"、"产品经理也更技术"；⚠️ 而两人各自被认错过角色（一位常被当成产品经理、一位常被当成工程师）。
DevRel 那一段（[01:32:45]–[01:42:50]）：⚠️ 他们在平台与 Claude Code 分别建了 DevRel 团队，理由是两个开发者生态很不一样；⚠️ 近期招了 Addy Osmani；✅ 而本页认为这段里最有价值的是一条形态变化：
⚠️⚠️ cookbook 在变得没用："你现在不太处于那种'复制粘贴代码然后用'的位置了。" 他举的例子是团队里有人写的 computer use cookbook"至今让他难忘，因为它复杂得离谱"；✅ 而现在的形态是 Claude API skill（由 DevRel 团队拥有）——"把它加载进一个编码 agent 里去用"，或者"你就把 Claude 指向一个参考架构（reference architecture）"**。
✅ 主持人的概括被确认：⚠️⚠️ "DevRel 最高杠杆的形式，是把所有最佳实践蒸馏进那些 agent 里去。" 🔗 本页认为这条该被在实践中用 LLM 记下：它是"文档 → skill"这条位移的一个一手证据，而且提供方是模型厂商自己。
⚠️ 本页另记一处争论，因为它涉及行业形态：主持人主张把 DevRel 拆成"前台/后台"——让产品与工程负责人出面，后台提供写作与制作服务，理由是"人们其实不太想听 DevRel 说话，他们想听你们说"。✅ 嘉宾的回应是时间与质量（"我们的问题就是没时间、也不知道怎么高质量地做这些事"）。
多智能体的具体建议（[01:44:51]–[01:45:51]，本页认为是全期最可直接执行的一条）：⚠️ "基本上你想有一个 lead，然后把一堆不同的东西拆开"；✅ 只有两个要求——子 agent 之间异步、互不阻塞，以及共享统一的上下文/状态。⚠️ "除此之外，就让它跑，看看 Claude 给你设计出什么。" ✅ 她的预测是架构会往这个方向收："Claude 会越来越聪明，它会学会怎么拆分自己、调整自己去适配有意义的架构。"
⚠️ 收尾的卖点两条："用 Opus 5.5 造点酷东西"（理由是成本效率与更少的啰嗦，⚠️ 以及一条轶事："我的一位老板发消息说 Opus 5.5 在一次事故里救了我们的屁股"）；以及"试试多智能体的搭法，你会发现它非常好"。
两条个人侧的内容（[01:27:41]–[01:32:45]）：⚠️ 产品负责人自述曾在一段很长的通勤里一年读了约两百本书，并把推特当成"把一个想法压缩进尽可能少的词"的个人练习（"当时真的不是为了涨粉，就是对着虚空发推"）；她最喜欢的书是 Nassim Taleb 的《黑天鹅》。✅ 而工程负责人那段关于 Slack 的自述本页认为值得记：⚠️⚠️ "有些日子我可以取消所有会议、不写任何文档、不做任何工作，就只坐在 Slack 上一整天，而我会觉得那就等于干完了一整天的活。" ⚠️ 她自己说这件事很难受（"你并没有产出你想要的产出"），✅ 而主持人的回应是"你产出的是一个被解除阻塞的团队"。

本库此前未有、本期补上的空缺¶

空缺	本期给的内容
CPU 作为与加速器同级的约束	⚠️⚠️ "Anthropic 整体的 CPU 是个零和游戏"；采购从"按需弹性"变成"提前容量规划"；CI 是一个被忽视的消耗源
一个 agentic coding 改变决策边界的具体案例	messages API 整体移植到 Rust（团队里没有 Rust 开发者）、影子流量验证、省 40–50% CPU / 首 token 快 10–20%；方法论是"计划与验证最要紧，实现就是 Claude 在写代码"
被蒸馏一方的动机与对策	⚠️⚠️ "商业上我们是赚钱的"；真实理由是蒸馏出去的模型不带安全分类器；对策是跨轮次强制保留 thinking block，并主动给开源 harness 维护者与大客户铺迁移路径
agent 的凭据层	独立 vault + 占位符 + 出口代理注入 + 域名白名单；"大脑和手分开"
一条组织如何低估安全论证的记录	✅ 对自家产品经理的公开道歉（"所有人都说是是是，但延迟和可靠性"）
Claude Managed Agents 与 Dreaming	CMA 是 messages API 之上的抽象；Dreaming 是"一层套一层的 managed agents"（本库此前完全没有这两条）
前沿 API 破坏性变更的推法	把用户体验代价分两层、只接受第一层；替客户发一个 compaction 功能；提前联系开源 harness 维护者
一条来自实验室的智能饱和判断	⚠️⚠️ "在一些负载上智能看起来越来越饱和了，这是一个新情况"，而 alpha 在极长时间运行的 agentic 任务上
"文档 → skill"的位移	cookbook 在变没用；Claude API skill 由 DevRel 团队拥有；"把 Claude 指向一个参考架构"