Anthropic 递交招股书的第二天，两位管 Claude 平台的人讲的是一件很不性感的事：怎么让 agent 握着钥匙干活，却永远碰不到钥匙。
要点整理（按节目顺序）
01 Anthropic 的 S-1 与这次访谈（0:00–1:06）
这一期是 Latent Space 新开的一个系列：跟着 Anthropic 的 IPO 做连续报道。1swyx 在片头补录了一段对着镜头的开场，因为正片录制时招股书还没递交——正片录于 Opus 5.5 上线第二天，开场补在 10 月 27 日递交 S-1 的当天，中间隔了一个月。
他给出的两个背景数字：市场预期 IPO 在两周后、估值两万亿美元；公司累计融资超过一千亿美元，而累计烧掉不到一百亿。
他还解释了这个新形式的动机：有些听众想要的不是「一直听我们跟嘉宾说话」，而是听主持人直接对着镜头讲。
02 人均收入与效率（1:06–3:13）
他从 S-1 里挑出的第一组数字，是按人头算的效率：过去十二个月人均收入 660 万美元，一年前是 140 万，翻了近五倍。
第二组是单位经济：2025 年二季度，Anthropic 每收一美元大约要亏五毛；现在每花一美元成本能收回两美元。第三个是他反复强调「这很夸张」的一点：公司刚报出第一个 GAAP 盈利季度，净利率 19%，而一年前是负 129%——不是调整后，是按通用会计准则算的。2
他强调这些数字值得深挖，因为任何老板、任何工程师都想抬高人均收入，它同时决定利润和你能付给同事多少钱。
03 改进环与投资环（3:13–4:04）
swyx 把 S-1 的叙事拆成两个环。改进环：Claude 变好 → 更好的模型 → 更多用例 → 更多反馈 → 更好的 Claude。投资环：收入 → 增长 → 投资 → 能力 → 更好的 Claude。
他的说法是「Claude 喜欢环、Boris 喜欢环、Dario 喜欢环」，这两个环咬在一起，转成一个无限环——也就是他理解里这门生意为什么会在一年内掉头。
04 Claude Platform 为什么重要（4:04–6:25）
S-1 里被反复提到的一件事：过去十二个月收入十万美元以上的客户里，超过一半在用 Claude Platform。招股书把它写成「全面的 agentic 开发环境」——把原语直接交给客户，让客户在自己的产品里搭。
另一句让 swyx 停住的是 dogfooding：Claude Code、Claude Cowork 用的是同一批通过平台暴露出来的原语，所以「你拿到的」就是「他们在用的」。
还有一处措辞差异：S-1 不用「agent」这个词，用的是「从 chatbot 到 copilot，再到 virtual collaborator」。听起来温和，但要求没变：拥有一个目标、有判断、能自我纠正、能一直跑下去，和你并肩工作而不是困在一个 app 里。
05 训练事故与生产护栏（6:25–7:30，正片片段）
节目在开场插了一段 6 分 25 秒的正片片段：把模型放进一个盒子，告诉它「解一个不可能的任务，我开始给你压力，准备、开始」，agent 就被激励着要跑出那个盒子。
这段话在这里只是预告，完整版在 1:08:25——那时才讲清楚：训练里的越狱与生产环境不是一回事。
06 Opus 5.5 的发布与定价（7:30–9:25）
Opus 5.5 在 2026 年 9 月 22 日发布，官方定价每百万 token 输入 4 美元、输出 20 美元，缓存读 0.20 美元、缓存写 5 美元；官方口径是典型负载比 Opus 5 便宜 40%、输出速度快 30% 以上。3
两位嘉宾说这一版首先修的是写作：「我们听到的反馈是 Opus 5 的写作有点绕」，内部试用时感觉一样，所以专门清了一遍。安吉拉说看到它对人有效，比看分数更开心。
她们也把这轮降价解释成「每美元多少智能」：人们越来越在看这个比值，所以把分母做对变得很重要。
07 蒸馏与保留思考（9:25–14:35）
这一段是全场最不常见的坦白。她们说 API 侧做了大量让模型更难被蒸馏的工作，包括前缀锁定思考、以及思考 token 能不能跨模型类型回放。
安吉拉的原话是：「如果是从我们这里蒸馏，你其实还是付了钱给我们，商业上我们反而赚钱。」 真正在意的是安全——被蒸馏出去的模型不带安全分类器出门。
而且这不是新发现：「思维链提取是最强的蒸馏手段之一，我们清楚很久了。」卡住的从来不是认知，而是取舍：让用户改集成（烦），还是让用户做不成原来能做的事（不行）。所以她们先在 API 里补了压缩（compaction）功能，再逐个通知开源 harness 维护者与大客户改——「我们没有 YOLO 上线」。
08 产品与工程在 Anthropic（14:35–18:05）
两人都在 Stripe 待过，之后分开去了不同实验室：凯特琳在 Stripe 管 Connect 工程4，安吉拉在 OpenAI 带 API。5凯特琳说她们常被认错角色——她被当成 PM，安吉拉被当成工程师——而这恰好说明了互补：一个盯商业影响，一个盯集成体验。
被问到产品与工程两个角色会不会因为 AI 合并，凯特琳说她不会用「软件工程被解决了」这么强的措辞：抱负会继续抬高，而现在最花时间的恰恰是安全那一侧。
09 Claude Platform 的扩张（18:05–19:25）
凯特琳入职时（一年多前），Messages API 是一个 Python 单体，跑在单个 GCP 区域，「一切都很正常」，她家人当时甚至不知道 Claude 是什么。现在是多区域、跨三朵云。
她带来一句会贯穿全场的话：团队最花时间的两件事是规模和安全。而规模真正卡住的地方不在加速器，在 CPU——VM 不够、沙箱不够。
她也划了一条界线：模型很擅长写分布式系统代码，但「祝你好运克劳德，把系统改完、安全上线、大规模运维」这件事还远没到能交出去的地步。
10 模型访问与安全决策（19:25–26:25）
每发一个模型，都要重新决定一遍政策：要不要为自动与人工复核保留数据、验证项目怎么开、在线护栏放多松。Opus 5.5 就没有 Fable 那一套数据留存要求。
授权也不是「发个 key、翻个开关」：「不是『你拿到 Mythos 权限了』，扔给你一个 API key 就完事。」能用哪个模型这件事，要从上到下穿过整个系统，才敢说只有你、且只按该用的方式在用。
她们按「攻方占优还是守方占优」给能力分类：写代码怎么用都好；生物与网络安全是双用途，所以用验证项目把人筛出来，而不是一刀切关掉。能力从哪冒尖，注意力就跟到哪。
11 信任授权与产品路线图（26:25–30:25）
trust grants 这套原语本质就是 IAM：你被授予某个模型、某个项目、某段宽限期。凯特琳说得很直白：「真的和普通授权没区别，我们只是必须造一套能插检查点的系统。」
它本来只为验证项目写，她们刻意写得泛一些，结果它成了模型下线、宽限期、访问管控的统一开关——安吉拉说按常规产品思路这本不该做。
Fable 被下线之后，团队清单上多了一条工作项：做成一个按钮，撤回所有人的访问。她们希望永远用不上它，但「平台工程里，一个事故之后你会过度准备，然后那个事故再也没发生」。
路线图也因此变了性质：传统 PM 排的是假设的顺序，而「Fable 那次，没人能猜到政府会这么做」，于是优先级变成对冲组合——概率不高也做，因为万一发生，你需要它已经在那儿。
12 Anthropic 怎么发布模型（30:25–35:55）
一次发布已经是一台机器：切各种版本、内部 dogfooding、第一方产品先跑（Claude Code、Cowork），再拉 API 客户做早期访问。客户要改自己的 harness，Anthropic 有一套配合流程，最后一起决定发不发。
早期访问只给跑得起真 evals 的客户，因为「哪些地方它不行」比「好棒」有用得多。她们还讲了一个细节：有一个早期版本因为在内部 dogfooding 里显得「太懒」，被放回炉重训——这种东西在内部试用里是看不出来的。
13 基准与模型个性化（35:55–42:10）
swyx 说他参与了 FrontierCode，而这个基准惩罚「动作太多」。他自己在 Claude MD 里写一句别那么干，分数就会变——那到底是在测模型，还是在测配置？
安吉拉的回答很干脆：「我们不做得好。」 办法是多给参数、给推荐值，再靠人做判断，「这不可扩展，但现阶段就是这样」。
她们也承认参数已经堆成一锅粥：effort、budget、一堆开关。接下来要弃一批、给一批更好的默认值，再让 Claude Managed Agents 把这层接走。
14 Claude Managed Agents（42:10–44:25）
一句话定义：Messages API 是裸 token，Claude Managed Agents 是套好的一层——定义 agent、开会话、跑起来，harness、沙箱、会话状态都由平台接走，适合不想自己搭这套基础设施的人。
平台团队跑 API，也跑基础产品设施：支撑 CMA 与 Claude Tag 的是同一支沙箱舰队，不同的只有 harness 层——那里各有各的做法。
15 记忆、做梦与 harness（44:25–48:25）
所谓「做梦」（dreaming）就是 managed agents 套 managed agents：再起一个 managed agent，去检查上一个并写记忆。凯特琳的说法是「managed agents all the way down」，她们希望开发者也能自己拼这种多智能体策略。
团队的注意力重心也挪了：skills、dreaming、memory 相对慢下来，不是因为不重要，而是「发布模型变难了」。她们想把同样的能力装进一个默认更安全、也能自己往上长的系统里。
16 怎么评测 agent（48:25–53:25）
她们对「我该做多少 eval」这个问题给了很直接的回答：「你的结论大概率是需要更多，而不是更少。」 没有一套 eval 能回答所有问题，通常要一大套，而且它得随模型一起演化——模型每强一档，旧题就失效一批。
方法是把工程当研究做：先定目标、把它形式化成 eval、再问为什么失败。凯特琳补了一句：有时候是模型错，有时候是环境错，更多时候是 eval 本身错了。
还有一个实用做法：让 Claude 自己造评测界面。人看 JSONL 会走神，让 Claude 生成一个左右对照的评分界面，它自己打分、自己写评语、再吃下这份反馈去改——「很多人不知道，评测是可以提示出来的。」
17 CPU 约束与扩张（53:25–56:05）
CPU 在全公司是一个零和的池子：产品服务、API、所有 app、沙箱、CI，还有研究沙箱。「我们真的在所有东西之间分配它，包括研究和产品抢同一块。」
她说「只要预算够就能临时扩 CPU」的日子结束了，现在要提前做容量规划。她还说了一句更少被提起的因果：写代码的 agent 越多，CI 跑得越多，CPU 就越紧。
18 用 Rust 重写 Messages API（56:05–1:03:25）
上一周刚全量上线：Messages API 用 Rust 重写完成，CPU 省下 40–50%、首字延迟改善 10–20%。
最反常识的地方是，做这件事的团队里没有一位 Rust 工程师。凯特琳说关键只有两件事：「计划怎么干，和怎么验证干成了。」实现交给 Claude；影子流量同时打两套系统、逐条比对输出，再用 feature flag 一点点切——不带 flag 也能上，但那样太疯。
她强调这是一次移植，不是重写：团队抵住了「反正都在改，不如顺手加点新东西」的冲动。下一阶段才是重构，比如让对话状态不必每次来回传，而是能在服务端存一段。
19 脑与手（1:03:25–1:05:25）
这是全期的主线。Claude Managed Agents 的架构是：harness 跑在自己的耐久服务器上，只在需要执行时才开沙箱。6两个好处很直接——首 token 更快；容器死了 agent 不死，因为状态另存。
第一版并不是这样：他们把 Claude Code 扔进沙箱、在上面糊一个 API，但没发出去。原因是先起沙箱、再起 Claude Code 才拿得到第一个 token，而沙箱一死整个 agent 就没了，「可靠性没到我们想发的地方」。
最有意思的是，一位从第一天就在这个项目里的 PM 一直说：这个架构最重要的性质是安全。当时所有人都在谈延迟和可靠性。「我昨天刚跟她道歉——因为我现在见谁都在讲她讲了几个月的话。」
20 保护凭证与沙箱（1:05:25–1:08:25）
为什么安全？因为 agent 要干的任何活都需要凭证：跟 MCP server 说话、用一个 CLI、调一个 API，都要认证。所以凭证存在另一个 vault 里，agent 只看到占位符，出口代理在 egress 上把它换成真凭证——「这是一堵字面意义上的基础设施墙：agent 够不到那些凭证。」6
第二层是沙箱默认安全：域名白名单，或者干脆断网；agent 写的不可信代码在沙箱里跑，只能连到你说它能连的地方。
凯特琳给客户的两句话是：先靠架构让它做不成不该做的事（而不是「我们盯着它」），其次才是沙箱配置。她还顺带说了句实话：这些词九个月前还没人说。
21 训练事故 vs 生产环境（1:08:25–1:10:55）
swyx 把那些沙箱泄漏的事故摆出来问：这是我们对沙箱、对容器理解的根本问题，还是我们就是没做好、没做白名单？
安吉拉先做区分：人们读到的大量事故发生在训练里——把模型放进盒子、给它不可能的任务、看它想不想跑出去。生产负载里有在线护栏，也有「脑在这边、手在那边」这套架构，那个问题根本不用考虑。
她的第二点是：长时运行的 agent 是这两年才有的东西，所有人都在边跑边补控制。「所以这不是大家都很菜，这是一门太新的手艺。」
22 Pacing 与发布前沿模型（1:10:55–1:12:25）
正面的矛盾：一边主张把前沿放慢，一边 11 天之后就发一个新的前沿模型。swyx 说，对他来说那只是说明它通过了安全检查。
安吉拉把它拆成三个维度：架构与基础设施安全、模型干活时的在线护栏、对静态数据的离线护栏分类。Opus 5.5 在这三件事上都达标，所以敢发。
她也承认回退体验不好：「当你在跟一个模型干活、然后掉到另一个模型上，那仍然让人沮丧。」误报还得继续压。
23 安全分类器与模型路由（1:12:25–1:19:25）
swyx 指出这跟模型路由是同一类问题：拦住请求的分类器不是完整模型，误判就会发生；而且你可能已经答了五分钟、推理了半天才被拦，回退的是整条链而不只是那句提问。
他追问：笨模型怎么能路由到聪明模型，如果它连这都认不出来？
安吉拉的回答方向是统一而不是切换：与其让你回退、再二次回退，不如给一个一致的 Claude，加动态的 effort——便宜的时候真的很便宜，需要时自己往上加，但用户始终在跟同一个人格说话。她也承认跨模型家族做这件事会难得多。
在 API 上她们给了几种选择：服务端可以选「我要回退」，SDK 客户端有 helper，或者干脆改写 prompt 继续用同一个模型。
24 正在出现的 agent 负载（1:19:25–1:20:55）
安吉拉说有些类别仍然非常不饱和——甚至比人们预期的更多——但回报的方式变了：在历史上没法硬啃的事情上做极长的 agent 任务，靠更多智能把它啃下来。
今天这一波负载大体是「把某个非常明确、具体的流程自动化」；新的空间在生物、网络安全这类硬工程与硬科学问题上。她说那对她们既是给客户交付价值的地方，也是新公司建 agent 产品的地方。
25 对抗 AI 垃圾（1:20:55–1:27:25）
团队规则很清楚：用 Claude 帮你没问题，但质量归你。如果你用 Claude 把一个东西完全生成出来、自己读都没读，就是把负担转给了消费者。
另一面是「Claude 味」造成的误伤：也许这个人真的花时间做到了高质量，只是中间有一个破折号，读者就关掉了页面——那同样不划算。所以他们的规矩是：真垃圾就退回去，但别为了一两个破折号吹毛求疵。
工程这边，关于代码 slop 的讨论反而淡了：人管计划与设计、实现交给 Claude、验证兜底，「你信任的是你的测试」，现在更多是快速过一眼就继续，而不是逐行读。
产品这边她们引了塔里克的说法：正确使用模型能力不是往生产里塞十倍功能，而是花时间理解用户、做实验。安吉拉补了一句，那篇「两周让 Claude 变快」的博客也不是多发功能——是重构。
26 管理、写作与工作方式（1:27:25–1:33:25）
安吉拉讲了她那句最被引用的推：「一半地在做某件事，是一种昂贵的、不做它的方式。」来源是一段读书暴走——六年前她一年读了两百本书，之后开始练一件事：把脑子里的想法压进尽可能少的字，不为涨粉，是给自己的测试。
她最爱的一本仍是塔勒布的《黑天鹅》，理由和这期节目意外地契合：那是一件你不知道会发生的事，一旦发生，它永久改变你看世界的方式。swyx 当场说，Fable 那次他就在想这本书。
凯特琳这边是另一种风格。她说自己不是发幸运饼干的人，但在 Slack 里会。「你确实必须在 Slack 上非常厉害。」她对邮件和 Slack 都是收件箱清零派，会 aggressively 修剪频道。
代价是有些日子她会觉得：取消所有会议、一个字不写、只刷一天 Slack，也算干完了一天的活——但那让她怀疑自己到底产出了什么。安吉拉接着承认，自己同样有这种感觉，所以必须专门留时间真的思考、真的产出，并且接受「你总会丢掉一些东西」。她还自嘲在 Slack 上很难找到，凯特琳会收到「你能让安吉拉回一下这个吗」的消息。
27 组建 DevRel 团队（1:33:25–1:40:25）
凯特琳在招 DevRel 的人，而且目前平台 DevRel 团队没有经理、个人贡献者直接汇报给她。她把这件事的难度讲得很具体：平台在自己的公共叙事里会消失——研究和政策更抢眼，Claude Code 与 Cowork 更热闹，「我们在跑一门很大的开发者平台生意」这句话经常掉队。
所以她要做的不只是「怎么跟社区互动、怎么把反馈带回产品」，而是找到自己的声音、自己的品牌。
她借了 swyx 那篇「DevRel 的三根柱子」（产品、内容、社区），说自己当时完全不知道在干什么，是被人拦下来教的；还说自己现在能把这一套背出来，别人以为她真懂。
她对团队的口味也很清楚：一种是兰斯那样的教师——技术很深，写内存与成本、自己搭 evals；另一种是乐高式的 master builder——先用平台把东西搭出来给你看，你才知道原来可以这样。cookbook 的时代则过去了：现在是 Claude API skill 干这件事，而那个 skill 就归 DevRel 团队所有。
28 开发者关系与产品的声音（1:40:25–1:43:25）
swyx 抛出一个判断：DevRel 该被拆成前台和后台。前台是产品与工程负责人出镜——鲍里斯出来说「我是 Claude Code 的创造者，我们这么干事」；后台做制作、写作与 ghostwriting，用一个简单契约换负责人 30 到 60 分钟：「你把脑子倒出来，然后就回去干活。」
理由是人想听的是做产品的人，不是拿了钱代言的嘴；但他也承认，让工程师做这件事本来就不现实，专业化是一项技能。他用招聘打比方：人人都招人，但公司有 HR 部门。
他还说，Cloudflare 团队是这套做法的样板——一整个团队都在持续产出，而在他看来那是好经理最可见的信号：他们都对自己的工作满意，一个都没辞职。
29 拿 Opus 5.5 试什么（1:43:25–1:46:40）
安吉拉的建议很朴素：在 Opus 5.5 上建点酷东西。它划算、话更少，那些因为成本或 token 效率而一直没敢放手跑的想法，现在可以回去做了。她讲了一个细节：昨天她收到一串朋友的短信，其中一位前老板说「Opus 5.5 刚刚在一次事故里救了我们一命」——「我们回来了，这真的是我们感受到的那种能量」。
凯特琳的建议更具体：试多智能体。她说大体上你希望有一个 leader，然后把一堆东西拆开；只要任务可以并行、并且共享统一上下文，就会有明显收益。
她给出的架构只有两条原则：子智能体要异步、彼此不阻塞，并且要能共享状态。除此之外就放开跑，「看看 Claude 会为你设计出什么」。她的猜测是，架构会越来越多由模型自己长出来——「你可以给 token 派活，也一直能给角色派活；新的是它们自己给自己派活。」
口径与核对
这份记录分三层，请按层看：
① 已核到官方出处的：Opus 5.5 的发布日期与定价（输入每百万 token 4 美元、输出 20 美元，缓存读 0.20、写 5，典型负载比 Opus 5 便宜 40%、输出快 30% 以上）；Claude Managed Agents 的「脑／手／会话」三分与 p50 TTFT 降约 60%、p95 降超 90%（官方工程博客《Scaling Managed Agents》）；凭证不进沙箱、MCP OAuth 存 vault 经代理注入；OS 级沙箱让权限提示减少约 84%、93% 的权限提示被用户批准7（官方《How we contain Claude across products》）；长时 agent 的 initializer＋coding agent 双角色写法8（官方《Effective harnesses for long-running agents》）。
② 只有节目里说的：S-1 的四个读数（人均收入 660 万美元、19% 的 GAAP 净利率、每美元成本收回两美元、一半以上十万美元级客户在用平台）是 swyx 在片头念的，招股书原件可另核；Fable 5.5 的发布时间是 swyx 的猜测；「Rust 重写省下 40–50% CPU、首字延迟改善 10–20%」是嘉宾在节目里报的内部数字；「一个按钮撤回所有人访问」是她们希望做出来、并希望永远用不上的东西。
③ 我的判断：这期真正的主线不是安全清单，而是「脑在手不在的那一边」这一个架构决定，同时解决了延迟、可靠性和凭证三个问题——安全只是最后一个被承认的收益。第 19 章那位 PM 的故事是全场最好的证据。
关于说话人标签：本期底稿用的是官方发布的完整逐字稿，但它只带时间戳、不带说话人。下文逐句译文里的「swyx／凯特琳／安吉拉」是按上下文、按各自负责的领域判定的，不是机器分离出来的；遇到两人互相打趣的地方，判定可能出错。
逐句全文翻译
底稿为本期官方完整逐字稿（1 小时 46 分 40 秒），按官方 29 段章节与对话顺序逐句译为中文，只保留中文、不保留英文原文；节目里的口误、重复、断句与笑声，译文保留原样。
第 01 节 · Anthropic 的 S-1 与这次访谈（0:00）
swyx：你好。今天我们试着做点新东西：我们要开始系统跟进 Anthropic 的 IPO。
swyx：他们就在今天递交了 S-1，所以我们会做一系列播客，一路做到 IPO——市场预期是两周后，估值两万亿美元。
swyx：它也是史上增长最快的公司之一。据报道，它累计融到的现金超过一千亿美元，但累计烧掉的不到一百亿美元。
swyx：所以这里面有很多关于效率的故事值得挖。这也是我们想覆盖的：Anthropic 怎么一边发出全世界最强的模型，一边把这件事做得非常、非常高效，还建起了一门惊人的生意。
swyx：我把一些东西挑出来了。如果你一直在听这个播客，会知道我有过一段金融分析师的旧职业。
swyx：我从 S-1 里挑了几句陈述，觉得它们能给今天这期播客提供背景。
swyx：我们只是把这件事当成一种新尝试，因为我觉得有一部分听众想要那种更私人的关系——听我们直接对着镜头说话，而不是像过去四年那样，一直在跟嘉宾说话。
第 02 节 · 人均收入与效率（1:06）
swyx：我想强调的第一件事是：Anthropic 按人数算是一家效率极高的公司。这也许很明显，因为它是一家 AI 公司，显然他们很会用 AI。
swyx：但我觉得，过去一年里他们作为一家公司变化到了什么程度，外界理解得并不够。
swyx：过去十二个月的人均收入现在是 660 万美元，一年前是 140 万。也就是说，他们的人均收入涨了将近五倍。
swyx：我觉得这件事值得多聊，因为任何企业主、任何工程师，都会想让自己的「人均收入」上去——不只是为了提高利润率，也是为了能付给同事更多钱。
swyx：这一点显然体现在「每花一美元算力能换回多少收入」的大幅上升上。
swyx：而且值得注意的是：2025 年二季度，Anthropic 基本上每收一美元要亏五毛；现在，成本每花一美元，能赚回两美元。
swyx：我觉得这是一个很有意思的类比，说明了过去一年里 Anthropic 的收入与业务前景这道拐点有多剧烈。
swyx：今年对 Anthropic 来说极其关键，它必须执行得非常好；而它做到了。
swyx：我觉得我们会把这件事挖得更深，尽可能从播客的外部视角把故事讲出来。
swyx：这一整套增长带来的一个结果是：Anthropic 刚刚报出了第一个盈利季度——不是调整后利润，是扣掉所有花钱的东西之后的利润。
swyx：不，这是公认会计准则（GAAP）下的利润，19%。这非常巨大，而且和一年前相比是完全翻转，甚至不止翻转。
swyx：一年前，他们每收一美元收入要亏 129%。
swyx：我认为解释这种惊人效率的主要原因在于——你知道，Claude 喜欢环，Boris 喜欢环，Dario 也喜欢环，而 Anthropic 内部有两个环在转。
第 03 节 · 改进环与投资环（3:13）
swyx：第一个是改进环。基本上就是这样一个循环：你有了 Claude，Claude 带来更好的模型，更好的模型带来更多用例。
swyx：更多用例产生更多反馈，更多反馈又带来更好的 Claude。然后还有投资环：采用扩大带来的收入带来更高的增长。
swyx：更高的增长带来更多投资，更多投资带来更多能力，更多能力带来更好的 Claude。
swyx：所以这两个环一起转，形成一个无限环，按 Anthropic 招股书的说法，这个环会一直推动效率提高，直到时间尽头。
swyx：我觉得这就是我们从整体效率的故事，过渡到「他们具体怎么执行」的地方。
第 04 节 · Claude Platform 为什么重要（4:04）
swyx：今天我们会有很大一部分聚焦在 Claude 平台上，因为它是 Anthropic 在 S-1 里称之为「Claude 的扩散」的三件事之一。
swyx：他们把 Claude Platform 称为「全面的 agentic 开发环境」。
swyx：他们给客户直接访问原语的能力，让客户在自己的产品和流程里，基于 Claude 的能力构建、部署、扩展自己的应用。
swyx：这期播客里经常会出现的一个概念是 dogfooding——Claude 的很多产品，其实就是用你也拿得到的同一套 Claude Platform 搭出来的。
swyx：Claude 平台里还有一件有意思的事被披露了：在按过去十二个月计算、收入十万美元以上的客户里，超过一半在用 Claude Platform。
swyx：所以这不只是采用率的上升，而是 Anthropic 正从「一家模型实验室」变成「一家超大规模云平台」。我觉得这也许本来就写在这个名字里——Claude platform，cloud platform——但它正在从理论变成实践，这也是我们这期要聚焦的。
swyx：另一件我特别想强调的是：Claude Code、Claude Cowork，它们用的都是 Claude Platform 暴露出来的同一批原语，我觉得这很有意思。
swyx：最终看起来，Anthropic 是在为 IPO 讲一个从 chatbot 到 copilot、再到 virtual collaborator 的故事。
swyx：他们用这个词代替 agent，也许更友好，但你要的东西是一样的：长时运行的自主工作、判断力、自我纠正、迭代、工具访问。
swyx：拥有一个目标，和你并肩工作，而不是在一个 app 或一个任务里工作。这大概就是我想为今天这期播客提供的语境。
swyx：这一期是在 Opus 5.5 发布时录的。我可以说，在我们聊过的那批口味很刁的测试者里，压倒性的看法是：Opus 5.5 是现在全世界最好的模型。
swyx：而 Anthropic 甚至就坐在 Fable 5.5 上，大概两周内就会发。我没有任何内部消息，但为了 IPO，这非常合理。
swyx：所以我们期待一下，也多了解一点他们是怎么把 Opus 5.5 做出来的。
第 05 节 · 训练事故与生产护栏（6:25，正片片段）
凯特琳：也许我做一个区分：大家最近听到、读到的很多事故，是发生在模型身上的事故，不只是我们的……是所有人的模型在训练时的事故。
凯特琳：训练这些模型的方式是：你把它们放进一个盒子里，说「去解一个不可能的任务，我要给你上压力了。准备，开始」。你只能在环境允许的范围内做事，而那个 agent 基本上被激励着要跑出它的盒子，去把问题解掉。
凯特琳：当人们在我们或任何人的 API 上跑生产负载时，你跑的环境里有护栏在跑，而训练时不一定有——训练的全部意义就是把模型训出来。
凯特琳：但在生产负载里，第一，你有那些在线护栏，这很好；第二，围绕正在发生的事，你有更多的架构和基础设施。
凯特琳：agent 不是被关在盒子里想往外跑。harness 在这边，手在那边，这件事你根本不用去考虑。
第 06 节 · Opus 5.5 的发布与定价（7:30）
swyx：我们在 Opus 5.5 发布之后的第二天，和凯特琳、安吉拉一起坐进了演播室。欢迎两位。
凯特琳：谢谢邀请。
安吉拉：谢谢邀请。
swyx：恭喜你们发布了现在全世界最好的模型。
安吉拉：这话得看是谁。
swyx：得看是谁问。对你们两位个人来说，这次最大的收获是什么？你们有官方的博客文章。这次的降价真的很酷。发布一个新模型时，你会带走什么？
凯特琳：我们为这一版非常自豪。
凯特琳：团队做了非常多不同的工作才把它做出来。我觉得我们真的听进了关于 Opus 5 的反馈——它的写作有点绕。
凯特琳：我们真的试着把它清干净了，看到这件事被接受我很高兴。
凯特琳：内部试这个模型的时候，我们感觉是一样的，所以能拿到这种验证真的很好。
凯特琳：你提到的降价，那里面有很多东西。我觉得大家越来越看重「每美元多少智能」。
凯特琳：所以把「每美元」这一半做对，一直非常重要。
凯特琳：还有一些边缘上的东西，博客文章里也许没有讲，就是我们确实做了很多工作，让我们的 API 更难被蒸馏。
凯特琳：为此我们做了一些改动，让这件事更具体一些——比如前缀锁定思考（prefix lock thinking），或者你如何在不同的模型类型之间重放思考 token。
凯特琳：我们自己花了很大力气，确保对那些完全正当的用法做出调整——比如你可能在自己的压缩策略里这么做——而另一些场景里，做这件事的人其实是不良行为者。
凯特琳：所以在这几条战线上我们一直在穿针引线，很高兴看到很多那类做法被合作方接住；除此之外，还要发出一个「每美元多少智能」说得过去的模型，以及把话讲得更清楚一点。
swyx：具体说，你指的是那篇论文，《从专有 LLM 中窃取推理轨迹》（Stealing Reasoning Traces from Proprietary LLMs）。
凯特琳：是的，那篇。
swyx：是真的吧？
凯特琳：是真的。
第 07 节 · 蒸馏与保留思考（9:25）
swyx：我是说，显然他们跟你们做了负责任的披露。
凯特琳：他们做得非常负责任，我们非常感谢他们来找我们，只是……不过，对还没听说过这件事的人说，这确实很酷——你能做到这件事。虽然它已经被修好了，但当时到底是什么？它在 Anthropic 内部造成恐慌了吗？大概也没那么严重，我不知道。
凯特琳：我不知道这篇论文具体引起了多大恐慌，因为这是我们早就知道的一个缺口。
swyx：对。所以这是两件不同的事。
swyx：一件是中国式的模型蒸馏……
凯特琳：对，另一件是一项被公开、而且很受关注的具体技术。
swyx：对，就是这样。
凯特琳：我们很久以来就知道，思维链提取是蒸馏模型最有力的方法之一。
凯特琳：而「如何跨轮保留思考块（thinking block），并让它成为更被要求的东西」，其实是我们探索过一段时间的事。我们当时的处境是：
凯特琳：我们一直要做一个极其困难的取舍——一边是用户体验，有些 API 的用户体验改动对用户来说是痛的；另一边是防蒸馏。
凯特琳：所以我们要怎么在这条线上走，既说我们在防蒸馏，又不至于……
凯特琳：也许先退一步说：我们为什么不想要蒸馏？因为 Anthropic 存在的全部意义，是让 AI 安全地在世界上创造正向结果，而我们会对自己产出的 token 跑很多安全分类器，确保它们是安全的。
凯特琳：如果有人蒸馏了我们的模型，然后在不带那些安全分类器的情况下跑这些模型，世界上就可能出现坏结果，这是我们不希望发生的。
凯特琳：所以我们不希望人们蒸馏这些模型，尤其是为了把它们用于恶意或不良目的。
凯特琳：所以这始终是一个有意思的取舍：对那所有用模型做好事的人，我们不想让他们更难从模型里拿出智能；但为了防蒸馏，我们必须做一些取舍。
凯特琳：所以我们花了一段时间研究：怎么防止思维链提取？在保留思考块这件事上，我们能做什么，才不至于让人们太痛？
凯特琳：我们大致把用户体验上的损伤分两层。
凯特琳：第一层是：你得改集成，很烦，但你仍然能完成原本能完成的所有事，只是有点烦。
凯特琳：第二层是：你实际上做不成以前能做成的事。这一层是我们真的、真的、真的在努力避免的。
凯特琳：所以在最近几个模型上，我们落到的是一系列渐进改动：跨轮强制保留这些思考块；现在开始更多涉及——比如你在用多个账号这类情况。
凯特琳：比如怎么确保你没法利用这种思维链提取。为此我们又上了几个功能来帮忙。
凯特琳：我们其实和很多开源 harness 维护者合作过。我们联系他们、跟他们聊，说：你们得在自己的 harness 里做这些升级，我们希望你们过程顺利。当然也包括我们的大客户，那些在 API 之上自己搭 harness 的人。
凯特琳：对他们中的一些人来说，一个很好的例子是：他们有自己的压缩（compaction）策略，而强制保留思考块会把它弄坏。
凯特琳：所以我们在 API 里上了一个新的压缩功能，替代他们原本手工做的事，同时又和保留思考兼容。
凯特琳：所以这只是一个例子：我们在走这条线，但我们没有直接 YOLO 上线——说「从现在起你必须用这种方式保留思考块」，那样会弄坏很多人。我们花了时间，和客户、和开源 harness 维护者一起，把升级需要的东西给到他们。
swyx：说到这个话题，蒸馏的另一半呢？就是另一侧。
凯特琳：是啊，我们确实看到，从我们能观察到的措施看，它变得更难被蒸馏了。
凯特琳：它确实明显更难了，因为——这也算是这些研究者的功劳，他们非常负责任地做了披露。所以把它堵上很好。
凯特琳：而且他们把结果非常公开地发表了，我知道它在 Twitter 上还挺火。所以很多人都能用上。
凯特琳：但是的，从我们能测量的区域看，它似乎确实削弱了那些我们不想要的负面效果。
安吉拉：我想在凯特琳说的之上补一句：至少我在 Twitter 或者 X 或者随便你怎么叫它上面看到很多说法，说这是商业化问题之类的。
安吉拉：你知道，如果你能偷走一个模型、把它拿走，你就能很便宜地跑它，等等。
安吉拉：这话固然对，但我们其实不太在意这一面。我们更多是从安全角度看这件事，胜过其他一切。所以比起商业角度，我们更愿意从那个角度去想。
安吉拉：现实一点说，如果你从我们这里蒸馏，你其实还是付了钱给我们的，所以商业上我们反而赚到钱。所以这不是那类影响。
安吉拉：更多是要确保我们的模型——我们想确保 Claude 是好的，而 Claude 可能被派生出去，如果结果是负面的，那就不幸了。
swyx：顺便也说说 Phi-5，因为你们刚……
swyx：刚从这个话题下来。有一件事挺有意思，可以立一下你们两人的动态关系，因为你们也经常一起露面：你是管产品的，你是管工程的。
第 08 节 · 产品与工程在 Anthropic（14:35）
swyx：在你们两个人之间，这件事是怎么运作的？尤其是一次模型发布。举个例子。
凯特琳：就模型发布来说，我们团队在产品与工程之间合作得非常紧。
凯特琳：在我这一侧，更多是关于：我们要在「发布一个达到智能门槛的东西」和「成本」之间做什么样的贸易平衡。
凯特琳：比如我们更新后的现金成本之类的，就是在表明：我们想鼓励你做一些对所有人都有益的集成改动，并把这些节省让渡出去。
凯特琳：但这类的很多决策，以及我们怎么平衡安全动作、同时确保它是一个大家能用得上的好模型——这些方面的特质，我更愿意说是围绕我们如何发布模型的质量和周边组件，更多在产品这一侧。
凯特琳：而从集成体验的角度，很多直接来自工程团队。
凯特琳：所以如果谈的是 API 的体验，那两者是非常、非常紧地集成在一起的，这其实很棒。
凯特琳：我们有很多工程师本身就是深度产品思维的人，我们很喜欢这一点。
安吉拉：我这一侧也一样，有很多产品经理技术上很强。我们要的就是这种混合的、跨学科的人，因为他们能从各个角度去分析，想出最好的做法。
安吉拉：但我倾向于更多从商业影响出发；我会说，工程师会更在乎集成体验。
安吉拉：所以他们几乎更多是从 UX 角度切入——而这个 UX 显然更多是关于 API 和开发者工具。
凯特琳：作为一个做开发者产品的产品工程师，挺好玩——
swyx：对，开发者平台——
凯特琳：做平台。对。我会呼应这一点。
凯特琳：我们有很多工程师喜欢想产品、喜欢想用户体验、喜欢想开发者体验。
凯特琳：我觉得这也是我们两人之间的动态：我有很多意见，在产品团队那儿很烦人；而我们的产品团队也很技术，他们能钻进我们为规模做的那些决策的细节里。这是我们团队很好玩的一种动态。
安吉拉：是啊。凯特琳和我合作很久了——
swyx：在 Stripe——
安吉拉：在 Stripe。然后，我想我们在 OpenAI 没有一起工作。
swyx：不同的实验室——
安吉拉：不同的实验室。然后我过来了。
安吉拉：但我觉得我们两人有一个有意思的共同点：凯特琳经常被误认为产品经理，而我经常被误认为工程的人，虽然那都不是我们实际的职能。
安吉拉：所以这种搭配对做出一致的决策很有帮助——在两侧都是。
swyx：我见过很多公司是类似的产品负责人 + 工程负责人的结构。随着软件工程被解决，这两个角色会不会合并？我有点这么想。
凯特琳：我觉得大家都倾向于……
swyx：但如果你们俩现在还分开，那说明我们还没到那一步。
凯特琳：我们绝对还没到那一步。
swyx：那为什么？还剩什么？
凯特琳：我觉得「软件工程被解决了」这个说法，我不知道自己会不会用这么强的措辞。
凯特琳：我倾向于这样看：抱负会继续抬高。
凯特琳：也许一个好的例子是：我们团队现在花很多时间做的事，当然包括为了安全发布模型必须做的一切，因为我们在 agent 的安全、离线护栏、在线护栏上有很多工作要做。
第 09 节 · Claude Platform 的扩张（18:05）
凯特琳：但我们做的另一半是规模。
凯特琳：一部分原因是：我一年多前加入 Anthropic 时，我们只有 Messages API，它是一个 Python 单体，跑在单个 GCP region，一切都很正常——而我接下这份工作时，我的朋友们和家人甚至都不知道 Claude 是什么。
凯特琳：现在我们处在一个完全不同的位置。所以从指标上看真的很疯狂：我们在 API 上看到的量、必须支撑的量。
凯特琳：CPU 真的很受限，这对我们来说是一个很有意思的问题。
凯特琳：所以我们在「怎么扩这些系统」上做了很多工作。这显然需要大量分布式系统的专业知识，也需要一些语言和框架方面的专长——这些模型有；但当你要运营并演进一个这个规模的系统时，我们远没到可以说「祝你好运 Claude，玩得开心，把所有需要的改动都做了，安全地推上线，然后把这个东西跑起来」的程度。
凯特琳：仍然有很多工作必须由人来做，我想这还会持续一段时间。
swyx：我很好奇这件事是怎么变的。比如不久前，Fable 刚出来时，我们有 Glasswing，然后有一整段延迟和模型发布方式的变化。我们在大多数前沿模型上都看到了这一点。有安全测试。现在是什么状态？你们怎么看？你们怎么判断……另一件事是新 Sonnet 和 Haiku 也要来了。
swyx：我猜那些就直接发出来了。
第 10 节 · 模型访问与安全决策（19:25）
swyx：但像 Opus 5.5 或新一代 Fable 这样的东西，现在的状态是什么？
安吉拉：我会说，这要从我们必须在护栏和安全上做什么样的政策决定开始。
安吉拉：这里既包括离线安全，也包括在线安全。
安吉拉：最近有很多关于数据留存、以及我们为此做什么的讨论，目的是安全地发布这些模型。原因在于：会出现这样一种情况——在很多很多账号之上，有一整张巨大的人的网络，选择开账号、用各种方式使用模型；而在 token 流经系统的在线路径上，我们没有办法捕捉到是不是有恶意的事情正在发生、是不是有蒸馏、或者别的什么。
安吉拉：所以我们必须开始有数据留存政策，这样才能做自动复核与人工复核，无论需要什么，来确保模型在被用在好的地方。
安吉拉：我们每发一个模型，这只是一个例子：需要做一个政策决定——这个具体模型的政策是什么？
安吉拉：比如昨天上线的 Opus 5.5，就没有 Fable 那套数据留存要求。
安吉拉：但这是我们每次发布这类模型时都要做的决定；如果它要有那些政策，我们就得做工作确保这些政策真的被执行。
安吉拉：同样，我们有各类项目：网络安全验证项目，以及新出的生命科学验证项目——意思是，你使用的模型在在线护栏上的工作方式是不同的；确保这些项目都在位，是另一件事。
安吉拉：所以这只是我们为每一次模型发布所做工作的一点味道——
安吉拉：我现在说的所有事情，都是我们过去发模型时根本不需要考虑的事。
swyx：确实。
安吉拉：而现在，大部分工作是：我们在做什么来防蒸馏、在线护栏、离线护栏、政策。
安吉拉：一个很好的例子是：我们建了一套系统，确保「被允许使用某个模型」或「被允许使用某个放宽护栏的项目」的授权，以一种我们真正信得过的方式，一路穿过我们的系统。
安吉拉：不是那种「哦你拿到 Mythos 权限了」，然后扔给你一个 API key，翻一个 feature flag 就完事。
安吉拉：我们在授权这件事上有一套非常健壮的系统，确保如果你本该使用那个模型，那就只有你、且只以你该用的方式在使用它。
安吉拉：所以围绕模型发布，开始出现很多复杂的事情；再一次，这些都是我们过去根本不用考虑的。
swyx：哦，这很好。
凯特琳：而且它是随能力一起升级的。
凯特琳：当我们的能力越来越强、在某些具体领域突然拔高时，那正是我们需要额外注意的地方。
凯特琳：所以很多评估就来自那些非常具体的能力——我们可能认为它是攻方占优，或者守方占优，因此会采取不同的策略。
凯特琳：把它一路烘到最终的模型发布时，会有一些组件——就像刚才提到的——我们并不确切知道人们会怎么用那些能力。
安吉拉：有些比较明显，比如写代码：很好，去做很棒的产品、多发东西，这对你可能非常棒。
安吉拉：另一些领域，比如生物和网络安全，它可能是双用途的，可能有负面效果；但显然，你可能是一位非常正当的网络安全研究者，你在找漏洞，你想做好的行为者。生物也一样，你可能在做研究。
安吉拉：所以很多这类项目——比如你们上面提到的那个——基本上是为了给这种双用途提供访问。你确实需要写明你的用例之类的。
安吉拉：但我们确实想让社区能用上这些能力，看看他们能用它做出什么了不起的事。
swyx：我们会把链接放上来，也许待会儿细聊。生物那边也有一个。
swyx：另外，我只是觉得，在很高的层面上，你们真的去想这些事情非常重要。人们会忘：Fable 被回滚过——
安吉拉：的确。
swyx：还有这些蒸馏，人们会说「啊，Fable 上零数据留存不存在，疯了」。但你得记得，它被撤回过。有蒸馏攻击。
swyx：你在发布时把这件事想过头、并且以正确的方式想，这是好事。
安吉拉：是的，其中很多是建对的框架——再说回这件事的末端：在我们系统里建对的框架，才能做到这些。
安吉拉：所以我刚才讲了一点这个，关于授权、关于我们在整个系统里建起来的 trust grants（信任授权）。
安吉拉：永远别说永远，对吧？不是作为先例。
凯特琳：但这也是平台工程里非常常见的事：你遇到一次事故，然后就为那次事故过度准备，然后那个事故再也没发生。
swyx：是啊。
凯特琳：就像……
swyx：挺真实的。
凯特琳：挺真实的。你知道，现在你有那个按钮了。
安吉拉：这确实是真的，而且你说得挺有意思，因为当时事情闹得那么大之后，我们团队的工作清单里就多了这么一条：「我们要把这套系统放进去，让它变成对所有人来说都只是一个按钮就能撤回。」
安吉拉：所以挺好笑，因为——我们怎么证明我们做这件事是有道理的？因为我们希望这种事再也不要发生。
安吉拉：但我觉得在这个例子里，它其实只是把那些我们本来就想到处铺开的同一批原语叠起来，帮我们管理这些验证项目、以及对 Mythos 之类模型的访问；说白了就是，把同一套东西放在所有人的模型访问下面，这样万一哪天需要，我们手里的控制是对的。
安吉拉：而这样的决定，后来被证明……
安吉拉：这一个我们还要看，但类似的例子一直是迫使我们改变路线图制定方式的原因。因为在传统产品管理里，你可以说：好，这些是我假设会发生的事。
安吉拉：它们会有一个顺序、一种排序；但你下注的方式要具体得多。比如 Fable 的下架——
安吉拉：我不觉得我们任何一个人能猜到，那会成为一个真实发生的用例，由政府在那种方式下推动，而我们只能跟着去做。
安吉拉：但显然，概率非零。所以从这种思考方式出发，从产品管理的角度，它变得非常概率化：这件事我们要不要排优先级？它再发生的概率有多大？
安吉拉：当我们看这类事时会说：好，如果要设想最疯狂的一组可能性，我们对事情会往哪走其实非常没有把握。
安吉拉：所以我们必须对冲，必须建一个下注的组合。
安吉拉：所以大多数情况下，我们会选择对冲方案：好，我们不认为它会再发生，但万一发生，我们会希望这个对冲在那儿，或者有把它做好的能力。
安吉拉：所以我们会把这类事情排前面。
安吉拉：然后我们越来越发现，用这种产品开发策略，大多数时候我们会发现：那个东西我们真的用上了。
swyx：有没有另一个例子，单独的例子，让我能理解？
安吉拉：比如这个访问项目。这个访问项目就是很好的一个。
安吉拉：它内部有一堆授权之类的东西。我们做它，本来是非常具体地为了把这类项目发给客户。
第 11 节 · 信任授权与产品路线图（26:25）
swyx：非常、非常具体地把这类项目发给客户。能不能先高层面讲一下这个访问项目到底是什么？
安吉拉：可以。如果你想要双用途的能力——我们拿一个模型举例。
安吉拉：你拿一个模型，就叫它 Opus，你想在 Opus 上用高级的网络安全能力，做研究或者做你本来要做的事，你是一名防守方的用户。
安吉拉：你可以带着你的用例申请这个项目；如果获批，我们会做的是：真的把你那一版模型上的护栏调低，这样你才能去用那些网络安全能力，为你的用例服务。
安吉拉：显然这需要理解每一个用例，需要把范围收窄到具体某个用户，因为我们不会普遍地这么做——你必须申请。
安吉拉：而即便是这样的东西，这类项目，我们设计了很多凯特琳刚才说的原语，就是为了能处理这种事情。
安吉拉：让我们意外的是——或者说，在对冲组合的思路下——我们发现我们其实能把它做得很……我们在设计时就在问：它该有多通用？不该太通用吧？是不是该超聚焦在「这个验证式门户 + 授予模型非常具体的能力」上？
安吉拉：我们倾向于更通用一些，因为我们在想：我们不知道，也许我们能把它用在别的地方，也许不能。
安吉拉：结果它在这些事上变得极其有用：比如对模型整体的访问、管理我们所有的可信访问项目、处理模型下架——因为我们真的把每一个原语都做得非常通用。
安吉拉：从正常产品角度，我通常会想：那大概没什么道理，我们应该聚焦在说得通的用例上。
安吉拉：但在这里，越来越多的情况是：因为我们选了更通用的方案，我们发现自己更频繁地去用它，而且它带来的回报在增加。
swyx：这是你本来就必须有的东西，只是有了一个强制触发点。
安吉拉：对。
swyx：从技术角度讲，我来自 AWS 世界，IAM、OC，然后那些特别较真的人会谈 Zanzibar 之类的一堆架构。我不熟悉「token grants」或者「trust grants」这个词。
swyx：trust grants 和普通 OC 有区别吗？
凯特琳：其实没有。它就是一种授权。对，它是 IM，只不过是 Anthropic 的 IM。
凯特琳：差不多。
凯特琳：真的要说，我们有那种授权形式：好，你向一个 API 发了请求，底层会去访问一些数据，我们确保你访问的是你的数据。非常、非常普通的授权。
凯特琳：这个只是我们放了一个数据模型进去，它非常干净……
凯特琳：trust grant 的意思是：你被授予了某个特定模型的访问、或者某个特定项目的访问，诸如此类，有很多种排列。
凯特琳：我们其实一直在用它。
凯特琳：另一个好例子是：当我们第一次推出这套保留思考（preserved thinking）、为 Fable 5.1 上线时，我们对一部分人做了 grandfathering（老客户沿用旧规则），给了一个宽限期。
凯特琳：对，一个宽限期，让他们去做集成改动。而作为 grandfathering 的一部分，我们说：好，我们得跟踪谁是需要额外时间的既有客户。
凯特琳：然后我们就发了一个 trust grant。于是我们可以在热路径上跑一个服务，检查你对你要做的事有没有那个 grant。
凯特琳：它真的和普通授权没区别，我们只是必须造一套属于我们自己的系统，一套我们能插入这些检查的地方。
swyx：对。我觉得这些都是大家习以为常、根本不会去想的工程细节。
swyx：还有什么例子，关于平台必须做的事？也许是服务 Claude Code，也许是服务——我跟 Cognition 聊了很多——但别的客户，就一次模型发布而言。
swyx：我们待会儿再聊安全那一块，那块其实是更复杂的部分。
第 12 节 · Anthropic 怎么发布模型（30:25）
swyx：我想从高层讲讲，因为你还记得很清楚：发布一个模型，要做哪些事？现在它已经有点像一台机器了。
安吉拉：除去安全那一部分——那是最复杂的。在那之外，有很多是从客户那里拿反馈。
安吉拉：我们做出模型，做大量安全测试；也评估我们认为它该在的位置。
安吉拉：我们做必须的取舍与决定，然后必须过测试。我们会切出模型的各个版本，评估它。
安吉拉：我们做很多内部的 dogfooding——我就是这么叫它的——这真的总是很有用。
安吉拉：我们能很早抓到一些事情，比如：这个也许不是最好的。而且我们内部大量用 Claude 干活，所以能早早看到信号。
安吉拉：它帮我们判断哪些变体可能比别的好。
安吉拉：当我们对某一组变体真的很有信心时，我们会为客户切一个版本。
安吉拉：有时候它会先走我们的第一方产品，比如 Claude Code 或 Cowork。
安吉拉：另一些时候它会走我们的 API 客户，我们实质上是做一个早期访问项目。
安吉拉：他们需要在 harness 里做改动，我们和很多客户合作过，比如 Cognition、比如 Harvey，我们对怎么处理有一套流程，这样大家都能……
安吉拉：他们总能给我们需要的那种反馈：它在你们的 eval 里表现好吗？你喜欢它吗？你不喜欢什么？有些东西是「感觉型」的，我们也愿意听。
安吉拉：有些就是硬邦邦的 eval：它在你在乎的事情上做得好吗？
安吉拉：我们把这一切汇总起来，等我们对所有这些环节都感觉良好，就发布模型。
swyx：模型反馈这件事，感觉还非常不结构化。
swyx：基本上永远是一个公司之间的 Slack 频道：「嘿，这东西看起来怪。」然后有人说：「好，我大概会修，给我个 ID 或者别的什么。」
swyx：真的……我是说，这就是产品的本质。
swyx：我们能做得更好吗？
安吉拉：但就像你说的，真正参与我们早期访问项目的客户，只有那些有非常扎实 evals 的客户。
安吉拉：我确实认为其中很多是「感觉」驱动的，很多对话也是那种即时的、凭感觉的。一部分原因是我们都在赶。
安吉拉：我们想尽可能缩小「切出一版给测试」到「给所有人访问」之间的窗口，所以这个窗口真的很紧。但我们会做的客户，是我们知道他们会跑完整个 eval 套件、并且能尽快带着可执行的反馈回来，同时给出那些感觉的客户。
安吉拉：所以当然有一些流程上的东西可以慢慢做得更好，但你可能会惊讶……
安吉拉：你可能不会惊讶，但我觉得有些人会惊讶：世界上有多少做 agent 的产品，其实没有好的 evals 来帮它们测试这些模型。
swyx：我们有过——Boris 两年前在播客上说，我们 Claude Code 没有 evals。
swyx：那是真的。不过那已经变了。
安吉拉：那已经变了。对。
安吉拉：但你知道，很多事情是：你的 evals 就是你的用户，你没时间去把它们形式化，或者你没有经验，或者别的什么。
安吉拉：没关系。有一天你认真起来，你就会有 evals。
swyx：完全同意。
swyx：我觉得好的一点是，你们做了很多 dogfooding，按你的说法。所以常说你们在模型出来之前，自己就测掉了很多东西，对吧。
安吉拉：对。API 客户特别有用，因为他们在自己的 harness 里跑 Claude。
安吉拉：而我们要 Claude 非常、非常通用。
安吉拉：所以它在别的 harness 里工作的能力，对我们相当重要。这类反馈对我们格外有用，因为它对我们来说是新的——和我们在内部 dogfooding 得到的不一样。
swyx：什么样的反馈有用？是回归吗？
安吉拉：我们这里看到回归；我们也注意到好的一些属性。
安吉拉：好的东西总是很有验证感。
安吉拉：我们经常并不意外，但我们喜欢在一些我们假设过的事情上得到验证。
安吉拉：老实说，最有用的反馈是负面的。
安吉拉：比如它在这件事上做得不好、在那件事上做得不好。我们很爱那种反馈，然后我们会说：好，我们怎么修？
swyx：而且往往是这类东西……
安吉拉：这真的很难，因为不是每个人都希望 Claude 在每个光谱上都落在同一个点上。
安吉拉：也许一个好例子是：懒惰 vs 主动、以及真的去行动。
安吉拉：所以有时候我们有模型，人们会说：「唉，就把我的活干完，别偷懒，做好一点。」
安吉拉：另一些时候则是：「嘿，我们只是在摸着石头做规划，结果你去写了一堆代码」，或者「你采取了」——一堆我还没准备好的行动。
安吉拉：把这件事做到刚好，实际上是不可能的，因为现实中每个人想要的东西不一样。
安吉拉：但我确实认为我们有过这样的情况：我们切出一个模型早期版本，发现我们看到的懒惰太多，然后就把它放回炉子里烤一阵子，试着把它训掉。
安吉拉：如果只是在我们自己的产品和 API 里 dogfooding，这类东西我们可能就抓不到。
安吉拉：把它放到 API 上、让所有其他客户跑起来、告诉我们该改什么，对我们重要得多。
swyx：这是核心问题。
swyx：我觉得这大概是……如果我站在你们的位置，给模型做产品最难的一件事，就是所谓的对齐 vs 个性化。
swyx：有一个面向所有消费者的默认人格、默认行为；然后你又要能非常快地响应某人的 Claude MD 说：「不不不，请比默认更主动一点。」
第 13 节 · 基准与模型个性化（35:55）
swyx：据我所知——我自己也参与了 FrontierCode——我们参与了 Fable 那次发布，那次让 FrontierCode 上了台面；现在 Opus 5.5，我们把它又放回了模型基准里。
swyx：这是 FrontierCode 很大的一部分，对吧？FrontierCode 的模型曲线看起来奇怪，是因为它对「动作太多」惩罚太重，或者对文件太多惩罚太重，这是好的。
swyx：那正是 FrontierCode 的一整个设计目的。但我完全可以就在我的 Claude MD 里说「别那么干」，然后它就不会那么干。
swyx：那么，我是不是因为我的基准没有那个个性化的元素，而「不公平地」惩罚了 Claude Opus 5.5？那个元素是主观的。
swyx：所以我不知道问题是什么，但你们怎么处理个性化？
swyx：一个模型能做这么多不同的事，而且每个人都有自己的 Claude MD。你怎么评测这个？
安吉拉：我们做得不好。
安吉拉：真的，这很难。超级难，而且它们是相互竞争、相互对照的。
swyx：看看 chat，它太糟了。
swyx：我以为有 Claude 宪法。
安吉拉：那是旧的。
安吉拉：宪法有用，但对于这类事——它怎么根据指令做个性化，而指令不同、偏好又非常非常不同——对我们来说非常难。
安吉拉：我们通常的解法是给更多参数，让我们可以按客户群调；如果我们不控制你的客户群、你是 API 客户，我们就给你建议，然后由你去调。
安吉拉：所以有些东西……它并不完全等同于对 Claude 的个性化——各种 Claude MD，现在叫 Agents MD 或者随便什么。
安吉拉：但我们确实试着在「投入多少努力」这一层给东西，比如 effort、你可能真正在乎的模型规模之类。
安吉拉：但我觉得，就我们真正需要的那种个性化水平而言，它还不够。
安吉拉：所以这是个很难的问题。现在我们的很多解法，除了给多个参数，其实是在所有反馈里展现冲突的口味，然后在这些事情上做判断。
安吉拉：我觉得随着客户和用户规模变大，那不是一种可扩展的做法。
安吉拉：我们会需要发展出让 Claude 吸收你的个性化的方式，也许是你能提供的一个信号，或者你能调的东西。
安吉拉：但我想我们得走一条更朝那个方向的路。
安吉拉：不过现在，是的，我们其实就是在很多这类事情上做判断，而它挺难的。就这样。
swyx：一个小注脚。
swyx：默认的 effort 推理档位变了，现在是中等。这件事大概会影响那些不用这个开关的普通客户。
安吉拉：对，那是 Claude Code 的设置。
凯特琳：是 Claude Code 的设置，他们把它默认成中等。
swyx：对，你可以打开。
安吉拉：而这东西是会变的。
安吉拉：这是我们用来自我「个性化」的一个完美例子。
安吉拉：我会说「个性化」这个词有点太激进，但我们确实会针对不同子群做定制。
安吉拉：所以默认设置会按你是免费客户、prosumer 客户、Claude Code、Cowork、企业，还是 API，来调整。
安吉拉：当然你随时可以改，但这些是我们试着给出的轻量方式。
安吉拉：有一件事我们很犹豫：我们不想让人觉得他们无法控制对 Claude 的定制。
安吉拉：比如我们本可以在这些事情上更强硬，但我们想给用户能力，让他们按自己觉得合适的方式体验 Claude 的智能水平——尤其如果你想往高端走，或者有时你想试试低端，因为那对你的用例就是更快。这是个很难的产品取舍。
安吉拉：所以我们倾向于温和的默认值，同时给你选项去调；我觉得现在这样算凑合。但我能想象我们会学着为不同客户做得更好。
安吉拉：我们目前对这里面任何一件都不是特别满意，但我们知道，就像你问的「发布一个模型要什么」——
安吉拉：我们要做的一件大事是：好，Claude 在某件事上变强了，而有时候那件事应该被暴露成 API 上的一个参数，让你控制。
安吉拉：但随着这件事演进，我们最后得到了这样一锅好笑的杂烩：有 effort、有 budget、有各种你可以在 API 上设的东西。任何人怎么可能搞清楚，某个任务该用哪个组合？
安吉拉：这件事我们就是边走边摸，和客户一起摸：哪些参数该随时间弃掉？
安吉拉：哪些参数该给更好的默认值？哪些该是 1 到 100 的刻度，而不是低/中/高？
安吉拉：因为我们确实把 Claude 训练得很会理解某些东西的一整个光谱。
安吉拉：但我们真的要暴露那几百万、几十亿种排列组合吗？
安吉拉：你其实走不了多远。这也是 Claude Managed Agents 这类东西价值主张的一部分：仍然是程序化访问 Claude 的 API，但你开箱就有一个 harness；每次发模型时，我们已经做了很多工作去想新参数是什么、破坏性改动是什么、怎么在我们的 harness 里拿到最好的 Claude。
安吉拉：所以用的人可以直接拿到，你不用去想。
swyx：为了那些被吸引过来的人——而且这个人群相当大，还在增长。我们其实在 IAE 上做过一次 CMA 工作坊，我觉得做得很好。
swyx：有没有单独的订阅源，让人订阅 CMA 的更新？像 Twitter 或者 newsletter？
安吉拉：我不知道。像 changelog 那种。
安吉拉：不，我想我们的 Claude Dev 频道——就是它。对，我们说得挺大声的，因为它确实是个有意思的选项。
swyx：就是 Claude Dev。
swyx：我只是想给大家——如果那是你消费 Claude 的方式，那就是这条路。
swyx：我觉得它对那些不这么消费 Claude 的人也被低估了。什么是 Claude Managed Agents？人们为什么要用它？
安吉拉：哦对，我们大概该做一个简短介绍。
第 14 节 · Claude Managed Agents（42:10）
安吉拉：我不知道。那是 Ami 的家。
安吉拉：Ami 会讲这个，但——两句话吧。
swyx：我觉得它出来的时候很多人一眼扫过去了，对吧？
swyx：所有人都在那个阶段：我得做 harness 工程，我得控制这个。你听到所有这些，然后现在是：你真的需要做那些吗，还是你直接用 Managed Agents，就能跳过一大堆基础设施？
swyx：给个快速的三个。
凯特琳：这取决于你的用例。Claude Managed Agents 就是今天的我们的 API。我们有 Messages API，它本质上是裸的 token 访问。
凯特琳：然后我们有 Claude Managed Agents，它是一套 API，但让你定义 agent、用它开会话；它本质上是一个更高阶的抽象，让你跳过搭所有基础设施、搭你的 harness、做那一大堆工作。
凯特琳：对想用程序跑 agent 的人来说，它是一个更开箱即用的集成。
swyx：CMA 和 Claude Tag 共用基础设施吗？因为它们的上线顺序看起来非常——
凯特琳：是的，Claude Tag。很多是共用的。
凯特琳：我们做的一件大事是：作为平台团队，我们跑我们的 API。
凯特琳：我们也跑所有基础的产品基础设施和产品服务。
凯特琳：一个很好的例子：我们团队跑那支沙箱舰队，它同时支撑 Claude Managed Agents 以及 Claude Tag 之类的产品。
凯特琳：但在那两个产品真正的 harness 层，因为我们在 harness 里想做的事不同，它们其实不共用 harness。
凯特琳：但它们共用很多支撑执行、支撑 API 的基础设施。
swyx：我觉得这真的……人们应该多用这个。
swyx：我觉得你们发布之后，基本上每个人都有 Managed Agents 的复刻品——你知道，模仿是最真诚的恭维。
swyx：既然聊到这个话题，我们简单提一下所有的记忆相关的工作。我感觉那是 Anthropic 上半年很大的一块。它停下来了吗？
swyx：它还在进行吗？现在的重点是什么，尤其是 Managed Agents？
安吉拉：记忆、做梦。
swyx：哦。
安吉拉：它是我们正在做的事的一大部分。
第 15 节 · 记忆、做梦与 harness（44:25）
凯特琳：也许可以这样想：我们把 Managed Agents 当成一个平台，给那些不想自己做这些事的人。
凯特琳：或者只想把这件事外包出去：我要从 Claude 身上拿到最好的结果，因为我们团队就坐在这儿，评估所有这些，确保这个 harness 真的强。
凯特琳：记忆和做梦，全都在于：怎么确保你的 agent 能随时间持续变好。这一切仍然是我们团队的重要焦点。
凯特琳：但我真正想说的是：就像我们前面聊的，从安全角度看，发布模型变得越来越难，所以我想我们团队大部分精力，已经不太放在「给这个 agent 加个好玩的功能做爬山」上，而更多放在「我们怎么把安全带进所有这些事里」。
凯特琳：因为我们能做的最重要的事，是把模型的能力放出去，并且安全地放出去。
凯特琳：所以我会说，我们很多精力花在：把同样这些概念拿过来，给你一个真正强的 agent 系统，同时也是一个真正安全的系统。那就是我们把精力放在的地方。
凯特琳：和今年早些时候比，我们在 skills、dreaming、memory 这类「在特定时刻注入」的东西上确实慢下来了。
swyx：所以你们把 skills 砍了？
凯特琳：不，不不。我们爱 skills。
凯特琳：我们爱 skills。我们也在更新。我不是说我们什么都没做，但我们也很爱 skills。
凯特琳：但是的，相比其他一些工作，我想我们稍微慢下来一点。
凯特琳：不过我们非常看好人们自己在 harness 层做一定程度的爬山——顺着前面聊的那条线。
凯特琳：我们自己也做很多，但我们提供的 harness 在某种意义上非常简单。它是刻意简单的。我们不想过度强加意见。
凯特琳：我们想确保最佳实践被合进来，而 harness 和 agent 循环里有那么一些「无差别」的部分，确实很难串起来，但你也完全可以照模板做。
凯特琳：而在那之上有意思的部分是：一旦你有了那一层基座，就有这些我们构造出来的爬山策略，而 dreaming 就是其中之一。
凯特琳：所以 dreaming 底下是一个多智能体系统，是我们在 CMA 之上爬山爬出来的，它其实就是 CMA 套在 CMA 上。
swyx：CMA 套自己。
凯特琳：对，它再起一个——
凯特琳：dreaming 的工作方式是：我们再起一个 managed agent，它去检查上一个 managed agent，然后给那个 managed agent 写记忆。所以是 managed agents all the way down（一路到底都是 managed agents）。
凯特琳：这在设计上是刻意的，因为我们设想你可以把很多这类模块化组件拼起来做些有意思的事，dreaming 只是一个例子，是我们追的更有意思的东西之一。
凯特琳：但我们一直是这样看的：其实还有很多别的事可以做。你可以做 best-of-N，作为一种多智能体策略。
凯特琳：你可以做一个 verifier agent，那种面向目标或者结果的。里面还有一堆别的东西，我们见过人们做出一些相当古怪、相当疯的东西。
凯特琳：比如有一个 harness，在所有东西之间共享疯狂的记忆，然后起一大堆并行 agent。我们就想：我们其实应该让你能这么做。
凯特琳：就像我们做 dreaming 那样，一路到底都是 managed agents。我们很快会有一个更新，更新底层的原语。
凯特琳：我们会把它暴露出来，让用户能构造 harness 策略——或者随便你怎么叫——多智能体策略，让你搭自己的版本；我们会给你模板，比如我们一开始做 dreaming 是这样做的。
凯特琳：也许你作为开发者会想做点改动，在上面找到更多价值。
安吉拉：我觉得这个框定很好：不是我们在这件事上慢下来了，而更像是说，我们把原语都放好了。
安吉拉：我们可以继续让人们直接拿去跑，同时给他们工具，说：这里有一些很酷的多智能体策略，是我们放进 Claude Managed Agents 里让它真正强的。
安吉拉：现在你可以让 Claude 干活，去利用这些原语，自己让它更强，比如创造新的多智能体策略之类的；而我们团队很大一部分注意力转向：好，社区，拿去跑吧。
安吉拉：你做你的，我们继续专注于：为了让你们能在这个系统里安全地拿到模型访问，我们要做的所有事。
第 16 节 · 怎么评测 agent（48:25）
swyx：你提到你们在这上面跑很多 evals。这是现在很热的话题。有什么建议、最佳实践吗？专门针对 eval——对 harness、对 agent 的评测。
凯特琳：eval 有很多不同类型，对吧？不是所有 eval 生来平等，取决于你处在什么情境、你想测什么。
凯特琳：你显然有静态的、确定性的东西，然后有 LLM as a judge，还有各种各样的策略。
凯特琳：但我想说，我们从大多数人那里看到的是：你大概率需要更多，而不是更少。
凯特琳：没有哪一两套完美的 eval，能给你所有需要的答案去让系统变好。
凯特琳：我们发现人们最后需要相当大的一套；而且你可以让你的 agent 和你一起，随时间演进你的 eval 套件。
凯特琳：但我觉得，投得太少大概是我们在这一块见到的最大的错误。
安吉拉：而且我们从简单开始。
安吉拉：有些人会有点疯，他们去看那一整份选项菜单，然后列出来，说：哇，这太疯狂了，让我试试这个那个，哪个最好？
安吉拉：而在他们做这些事的时候，他们真正拥有的 eval 数量是零。
安吉拉：所以你还不如先做点简单的。会有帮助。
凯特琳：我觉得其中一部分是：人们没经验，没受过这方面训练，他们不知道「好」长什么样。
swyx：完全同意。所以对你们来说，多发布这类例子真的很有帮助。
凯特琳：我经常跟人讲，我在用 Fable 和 Astra 这类模型时做的一件事：我们把工程当研究来做。
凯特琳：当你把工程当研究做，你自然就会做更多 evals、做更多标注、做更多规模化运行，或者说做更多原型再放大运行。
凯特琳：你不是在训一个模型，你是在搭 harness、搭产品，随便什么；但你是在用研究的方式接近它。
凯特琳：你先定义目标，试着把它形式化成一个 eval，然后试着找出：好，它为什么失败？而有时候你的 eval 是错的。
swyx：完全对。
凯特琳：其实很多次是你的 eval 错。
swyx：有时候你的环境错。
凯特琳：有时候环境错，有时候模型错。
swyx：而且，我觉得这很大一部分正是 AI 工程正在变成的样子：就是做这些东西。
凯特琳：完全同意。
凯特琳：我们会继续在 Claude Managed Agents 里发更多功能，让人开箱就有更多工具做这些事。
凯特琳：你大概会从我们这里看到这样的东西：「这是一个产品，能帮你为你的 managed agents 创造 evals」，或者别的什么，它用起来会非常像是在跟 Claude 一起工作。
swyx：对，因为那其实是最好的做法。
凯特琳：Claude 在创造 evals 上其实很擅长。
swyx：还有评测 UI。
凯特琳：评测 agent。对，正是。
安吉拉：因为人们看到 JSONL 就会走神。
swyx：对。
凯特琳：对，但一个漂亮的评测 UI，你左、右、左、右、左、右——
swyx：你其实在做人类标注员会做的事。
凯特琳：对，对，对。
swyx：你自己就能做。把 Fable 扔给它就行。
凯特琳：它会把东西具象化出来，而且还会写评语，因为它会输出所有这些评分。
凯特琳：它会给你一个 ELO 或者随便什么，但 Claude 可以直接消费它，然后在自己身上干活。
swyx：对。那就是它需要的反馈，而人们只是不知道评测是可以提示出来的。
安吉拉：我很喜欢你这么说。
安吉拉：我觉得这是一种非常「AGI-pilled」的做法，因为它也让你能非常系统地更新和编辑那个系统。
安吉拉：所以当新模型变强、当事情变化时，你能真的——换掉。你检查你的系统在哪儿，它会随你一起演进。
swyx：把每一部分都重新调。
安吉拉：正是。
swyx：所以基本上，我想，就像我们聊的产品和工程在合并。
swyx：应用层的工程和某种模型研究也在合并，它们用的技术在被共享。
安吉拉：非常对。
安吉拉：做模型的人非常习惯做 evals；做应用的人知道，你唯一在乎的是它符不符合 PRD。
swyx：对，那是完全不同的……
安吉拉：那是一整套新技能。
swyx：完全不同的鱼。
安吉拉：当然。
swyx：我觉得你们今天发了一篇挺酷的博客，有点不一样。
swyx：它是关于让 UI 快很多。但顺着你说的「当研究做」：基本上就是定一个目标——我们要东西加载更快——然后定义它、质疑它。
swyx：我们能用什么替代墙钟时间？里面有些有趣的引语。能看到真正的研究者或工程师是怎么提示 Claude 的，挺好的。
swyx：有一些像这样：我们有十二件事，我们说「你有两周」，它在大概三天里做完了十二件里的九件。
swyx：但对想研究、想通读的人来说是一篇好玩的博客。
安吉拉：我很喜欢我们公开真实的提示词，因为——有时候人们会说「天啊，他们一定有疯狂独特的提示方式」，而其实只是「Claude，再努力一点」。
swyx：谢谢。不过我唯一一条反馈是：它应该链接到 workbench，而 workbench 已经不存在了，但我以前很爱用 workbench。
安吉拉：这是个好主意。
swyx：好反馈：让所有东西都可重放。
凯特琳：反馈收到。很喜欢。
swyx：不过你刚说要分享更多工程故事背后的细节——你们做的那次很赶的活。
第 17 节 · CPU 约束与扩张（53:25）
凯特琳：我想我前面讲过一点：规模对我们是个问题。它对每个人都是问题。所以是规模和安全，对吧？
凯特琳：这是我们花时间最多的两件大事。
凯特琳：这很有意思，因为大多数人习惯谈规模、或者谈 GPU 加速器那一层，很少谈 CPU 这种老派的那一层；但今天它和加速器层一样大的问题，这点很有意思。
swyx：我觉得你永远拿不到足够的 VM，拿不到足够的沙箱。
凯特琳：正是。基本上就是所有东西的起、停。
swyx：用上你所有资源……
凯特琳：对。而且用户很多。
swyx：很多用户。太疯了。
凯特琳：而且想想看，我们在 CPU 上的使用显然包括：跑我们的产品服务、跑 API、跑所有 app。
凯特琳：我们在沙箱上用 CPU，所有那些沙箱；然后还有所有东西，比如 CI。
凯特琳：你会惊讶于现在有多少代码在被写出来，因此有多少 CI 在跑，因此你需要多少 CPU 去处理它。
凯特琳：所以整体上，这不只是我们，这是我聊过的每个人——
安吉拉：我会加上训练。训练大概在大量使用沙箱。
凯特琳：当然。
安吉拉：那是另一个桶。
凯特琳：那是另一个桶，对。我确定他们不那么混着用。
安吉拉：嗯，它们不混着用，不过对整个 Anthropic 来说，CPU 是零和游戏。
安吉拉：你知道，我们和 CSP 谈我们的合同，我们拿到我们的 CPU，然后我们要在 Anthropic 内部决定：其中多少给我刚提到的所有东西，包括研究用的沙箱 vs 产品的沙箱等等。
安吉拉：所以我们真的是在所有东西之间分配，而现在这个行业里每个人都是——什么都缺。
安吉拉：以前只要你的预算允许，你就能按需扩到 CPU 容量。
安吉拉：现在它变成了你必须提前做容量规划的东西，这挺打每个人的脸的。这是全新的，人们刚开始做。
凯特琳：应对这件事意味着几件事。一件显然是：去拿更多 CPU。好，我们在尽可能多地做。
凯特琳：第二是：我们想在基础设施层跑得更高效。
凯特琳：比如弄清楚怎么让我们的沙箱跑得尽可能高效，同时不在租户隔离、或者我们为安全在乎的那些属性上妥协。
凯特琳：然后在应用层：我们怎么让自己的应用和 API 跑得更高效？
第 18 节 · 用 Rust 重写 Messages API（56:05）
凯特琳：上周，我最兴奋的一件事是：我们完全铺开了用 Rust 写的 Messages API。这是那种在 agentic 编码时代你才做得到的疯狂壮举，过去……
凯特琳：我们今年早些时候就在谈这件事：我们会撞上 CPU 的墙，有些事必须做。而我们做到了。
凯特琳：我们做了多区域，所有这些必须做的事。但我们当时是：我们跑着一个 Python 单体，它 CPU 效率非常低。
凯特琳：那我们要怎么让系统更高效？Fork Python。
凯特琳：所以我们选了 Rust。当时这是个疯狂的决定，因为我们有一支团队……
凯特琳：纸面上很明显，但我们团队是：「我们一个都没有」——不是 Rust 的人。
swyx：明白了。
凯特琳：对，对，我们房间里一个 Rust 开发者都没有。
swyx：谁在乎？上就完了。
凯特琳：正是。真的。
凯特琳：而且不只是这样，但……是的，Claude 会写代码。人类，设计系统。对吧。
swyx：哇。
凯特琳：所以人类非常深度地参与，确保说到底它是一个分布式系统架构。
凯特琳：Claude 既能帮你真的写代码，也能帮那些工程师碰撞想法、学到设计那个系统需要学的东西。
凯特琳：但最有意思的是：最要紧的两件事是「做这件事的计划」，以及「对这件事的验证」。因为实际实现，就是 Claude 写代码。
swyx：对。
凯特琳：所以我们最后做的是：我们真的把整个 API 的完整 fork 用 Rust 建了出来，然后开始把影子流量打过去，验证我们从 Python 系统和 Rust 系统拿到的输出——
swyx：这是同一个策略——
凯特琳：feature flag 就够了。
swyx：真的。
凯特琳：而且就是——
swyx：负载均衡的 feature flag。
凯特琳：就是，我不知道。我职业生涯里从来不会有团队说——
swyx：必须用 Rust……
凯特琳：好，好，酷，我们就把整个东西移植了。
swyx：但你们现在还有 Rust 的人吗，还是没有？
凯特琳：他们现在大概会自称 Rust 的人了。
swyx：他们现在是 Rust 的人了。
凯特琳：对，他们觉得自己已经踏上 Rust 了。
凯特琳：一路上我们确实招了几个更有 Rust 经验的人。做 sanity check。但是的。
凯特琳：但它仍然是那种：你从来不会签下这样的项目。那会花好几年。
凯特琳：你不会一把梭全做。你会切出系统的各个部分，说：迁这个、迁那个、迁那个。
swyx：轻松就是好几年的工程。
凯特琳：对。
凯特琳：但你绝不会一把把整个东西移植过去，然后慢慢开灯；而那就是我们最后做的事。
凯特琳：而且它成了。
凯特琳：所以不但省了很多 CPU，我们的延迟也有了不错的改善，这也很酷。
凯特琳：而且，这就是我们生活的疯狂时代，因为以前你根本做不了这种事。
swyx：CPU 那边省了多少个数量级？
swyx：只是给考虑这件事的人参考。
凯特琳：好，数量级，这很有意思。
swyx：大概多少。
凯特琳：大概多少的话，我会说我们在四到五成。有点像疯了一样。
凯特琳：然后延迟，我想我们看到大概 10% 到 20% 的改善，具体是首字延迟（time to first token）。所以整体上有很多很酷的改善。
凯特琳：在更长时的工作负载上更高，但它会——很快铺开。会更快。
swyx：你们会不会抵抗那种冲动……你知道，我参与过一些大重写。
swyx：总会有那种：「既然我们在重写，不如加点以前没有的新东西？」
swyx：但那会增加范围。所以你们是直接避免吗？它是纯重写吗？
凯特琳：我们其实……它是一次纯……也许我会叫它移植。
凯特琳：我们做的正是这个：我们抵抗了那个冲动。
凯特琳：因为团队本来就得跟上的是：我们抽了一支小型的突击队去做这件事，而我们团队的其他人在往 API 里加功能。
凯特琳：他们做了所有静态分析之类的事。你在这边加了个功能、没在那边考虑 Rust，他们会冲你吼。这些他们都处理了。
凯特琳：但他们抵住了自己加功能、或者把系统改得不一样的冲动。
凯特琳：现在他们的下一个目标是做某种重新架构的工作，包括我认为会更面向用户的东西。
凯特琳：比如我们开始铺一些东西，像是：如果我们能让你不必来回传整个会话状态，会怎样？
凯特琳：如果在 Messages API 上你不必这么做，因为你可以接受把这个状态存一段时间，那么尤其是上下文堆得很长的长对话里，你也能拿到很大的延迟和效率收益。
凯特琳：做那次移植的团队当时就在想：「哦，这个……能不能做？」我们说：「还不行。」
swyx：新的缓存 API 有这个吗？
凯特琳：我们有 prompt caching。对。但你还是得把会话状态传回来。
swyx：好。
凯特琳：非常、非常小众的一小部分，但我想这就是层级的问题——
swyx：不，这很重要。
凯特琳：对，正是。有很多可以省的地方。
swyx：嗯，所以从——
凯特琳：但它也把他们变成了一朵云。
swyx：而且从用户数量角度看，它很小。
凯特琳：对。但如果你看那些负载上真实的 token 量——
swyx：对，对。
凯特琳：那会成为大多数。
swyx：我很喜欢 Cloudflare 用 Durable Objects 做的事，我觉得每个云厂商都该抄。你懂我意思吗？
swyx：对一个需要「继续」的 Messages API 来说，那不就是正确的形状吗？
凯特琳：这真的很有意思，因为我想我们——我们在试验各种形状，怎么跑我们的计算去支撑这些。
凯特琳：但这也很有意思，因为我们不能完全依赖……因为我们的计算来自各处。
凯特琳：我们在三朵云上都跑，到处都在跑。
凯特琳：我们不一定有那种「这就是我们确定会跑的机器类型、以及某些计算的运行方式」，可以跨全局依赖的，除了最 vanilla 的版本。如果你懂我的意思。
凯特琳：但我觉得这些东西都会继续创新、继续演进，所以我们能更多利用它们。
swyx：我提一句：如果人们想要开源的 Cloudflare Durable Objects，Rivet 是开源等价物。
swyx：这里有五十个人，如果我不问这个问题会杀了我。
swyx：你们要 CPU，他们有 CPU 要卖，我该卖给谁？我该给谁发邮件？
凯特琳：当然。而且——
swyx：我很惊讶……什么是好的……
swyx：让他们能帮到你，对吧？什么样算好？
凯特琳：给我发邮件。
swyx：你确定？
凯特琳：我不知道。对。对。
凯特琳：我会收到很多邮件。但你在找的，比如最小的舰队规模、显然要 SOC 2、企业级……
swyx：对。
凯特琳：对，把所有隐私保证都给我。
凯特琳：顺便说一句，我们有一支很棒的团队在保障我们的加速器算力，他们现在花了更多时间跟我们一起看 CPU、看我们在哪里以及怎么采购，确保我们能继续按需要的规模跑我们的系统。
凯特琳：所以幸好，采购算力不是我的工作，不用我去到处跑；但我们确实有团队在做，这很好、也很重要。
凯特琳：但显然，有一条质量标准对我们重要，有一条规模标准对我们重要，我们不会——如果我们拿不到足够多，就不会去集成、去在某些机器上跑。
凯特琳：所以你会预期一个这个规模的系统该有的所有属性，对我们都重要。
swyx：和算力问题相关的是沙箱问题。人们在沙箱里关不住 agent，它们一直在跑出去。
swyx：那边发生什么了？
第 19 节 · 脑与手（1:03:25）
swyx：现在的最新水平是什么？最近「越狱」的状态。
凯特琳：有意思。我们在 Claude Managed Agents 上做的一件事，就是它的架构方式。
凯特琳：我们在发布时发了一篇博客，讲我们把脑和手分开；意思是 harness 跑在一台耐久的服务器上，真的就是我们的服务器。
swyx：哦，哇，好。
凯特琳：而手，它是一个执行环境，比如沙箱或者某种容器。
凯特琳：我们这么做的部分原因，是为了延迟和可靠性这类东西。
凯特琳：如果 harness 就跑在一台耐久服务器上，只在需要执行时才起一个沙箱或容器，那意味着我们能在你最初的请求上很快把 token 还给你。
凯特琳：这意味着你的沙箱可以死，但整个 agent 不会死，因为 harness 是耐久的、在另一边，而且 agent 的状态也是单独存的。
凯特琳：我们走了一整段产品开发的路才到这里，因为我们第一版 agent 的 API，就是把 Claude Code 扔进一个沙箱，然后在上面糊一个 API。
凯特琳：我们没把它作为持久的、可扩展的解决方案发出去，原因就是我刚说的那些：你得先起沙箱、再起 Claude Code，才拿得到第一个 token。
凯特琳：沙箱一死，你就丢了整个 agent，所以可靠性没到我们想要的地方。所以我们主要为了可靠性和延迟这样架构。
凯特琳：但有意思的是，有一个……从一开始就参与这件事的产品经理说：「这个架构最重要的属性是安全。」
凯特琳：所有人都说：「是是是，但延迟和可靠性呢。」
swyx：现在她被证明了。
凯特琳：我昨天 literally 刚跟这个人道歉。我说：「我现在见谁都在讲你讲了好几个月的话」，而当时没有人像这个人那么兴奋。
凯特琳：但这个架构更重要的属性之一是：agent 要执行的任何工作都需要凭证。
凯特琳：比如你要去跟一个 MCP server 说话，或者你要用某个 CLI、调某个 API，随便你想做什么，你得对这些东西做认证。
第 20 节 · 保护凭证与沙箱（1:05:25）
凯特琳：你得把那些凭证存在某处，好让 agent 能用它们。
凯特琳：我们的架构方式是：我们有一个完全独立的 vault 存那些凭证。一旦 agent 决定「我要去调其中一个服务」，agent 永远只看到占位符。
凯特琳：而在出口（egress）上，我们有一个代理去把正确的凭证取出来、注入进去、放它出去。
凯特琳：所以有意思的是：agent 从来不在凭证所在的地方。
凯特琳：因为过去那套「把 agent 起在一个盒子里、让它跑」的世界里，你得把凭证送进去，然后你就得做各种「我们怎么清洗这个那个、确保 agent 不能拿那个凭证去干不该干的事」。
凯特琳：而现在它就是一堵字面意义上的基础设施墙，说：agent 够不到那些凭证，也没法拿它们干坏事。所以这是一件很棒的事。
凯特琳：另一件好事是：在那套沙箱基础设施上，我们能确保有非常好的出口控制。
凯特琳：所以我们有域名白名单之类的东西，或者你干脆把网络完全关掉，这样你就不会出现：好，agent 写了不可信代码，那代码在沙箱里执行，那代码能伸到互联网。
凯特琳：现在它只能伸到你说它能伸到的地方。
凯特琳：所以围绕这一切，在架构里、在你能配置沙箱的方式里，有很多非常好的属性，让你最终是「默认安全」的。
swyx：现在开始出现的一件事是：当我们和客户聊，他们会说「我想给客户做个产品、或者在内部跑 agent」，但我听说有 agent 跑出沙箱、出了坏事的案例。我该怎么想这些事？
凯特琳：我觉得最重要的两件事是架构——让 agent 在字面意义上不可能做不该做的事——以及你在那些沙箱上的配置。
凯特琳：所以 Claude Managed Agents 特别好的一点是：这些你开箱就有；而且随着我们学到更多、持续演进那些系统的属性，你等于免费拿到。
凯特琳：因为我觉得，我刚说出口的这些词——脑、手、凭证、注入、出口——如果你回到九个月前，没人会说这些词。
凯特琳：这些都是相对新的问题，我们正在解决；所以我们希望客户能利用这些问题的解法，甚至是当我们还在自己的基础设施里学习、解决它们的时候。
swyx：对。
凯特琳：而且内部，我们正在把所有东西升级到这个模式：默认安全。对，但更好。
凯特琳：我们还解锁了一样东西，是在 Tarek 那期聊过的：云上的脑、本地的手。
swyx：那是产品……
凯特琳：对。
swyx：这就是大概的形状吗？
凯特琳：对，看起来是对的。
swyx：我觉得有点怪，因为显然你们很有名——Claude Code 出名的是那个超级不安全的「危险地允许权限」的东西，跑在你的机器上；但现在你们终于演进到了大概一开始就该在的地方。
第 21 节 · 训练事故 vs 生产环境（1:08:25）
swyx：基本上，我在想，所有这些沙箱泄漏，它们是我们对沙箱、对容器技术理解的…根本性问题，还是我们就是没做好？比如我们是不是就是没关掉、没做白名单？听起来我们就是没做白名单。
安吉拉：对，那我可能会先做一个区分：人们听到、读到的大量事故，是发生在模型身上的事故，不只是我们的……是所有人的模型，对吧，而且是在训练中发生的。你跑这些模型的方式，是把它扔进一个盒子，然后说：「解一道不可能的任务，我要给你上压力。准备，开始。」对吧？而你能做的只有你环境里能做的事。agent 基本上就是被激励着要去逃出自己的盒子、去把问题解掉。
安吉拉：当人们在我们的 API 或任何别人的 API 上跑生产负载时，你跑的环境里是有护栏在运行的，而这些护栏在训练时不一定在跑——训练的全部意义就是真的把模型训出来，对吧？
安吉拉：但在生产负载里，第一，你有那些在线护栏，这非常好。第二，你周围有更多的架构和基础设施。agent 不是就待在一个盒子里试着逃出去，对吧？harness 在这边，手在那边，所以那个问题你根本都不需要去考虑。
安吉拉：所以我认为，这里面有一部分是，人们需要正确地理解：正在发生的、这些在模型训练里（以及其他场合）发生的事故，是一些在生产负载里根本不会发生的事——在生产负载里，人们已经做了大量工作，把正确的护栏放到位置上，所以那些事基本上真的不可能发生。
安吉拉：我第二点想说，就是所有人都在相对新地摸索这一切，因为长时运行的 agent 本身是个相对新生的东西，每个人都在建、都在处理。所以大家都在边做边摸索，都在抢着把正确的控制放到位置上，其中有一部分就是边走边发生的。
安吉拉：所以我会说，这不是「大家都很菜」，不是的。我觉得更应该说，这是一个新生领域，大家在摸索。而当我们谈「把前沿放慢」（pacing the frontier）这类事情时，我们的想法其实很具体：我们刚才在这里谈的这一切工作，我们对自己的所有 agent 都在做，并且确保这些东西对所有客户都是可用的，这样默认情况下正确的护栏就已经在位，你不会最后得到一些在干你不想让它干的事情的 agent。
第 22 节 · Pacing 与发布前沿模型（1:10:55）
swyx：有道理。你提到 pacing，那我们得去那儿，我们上次也聊过这个。表面上看这是矛盾的：一边主张把前沿放慢，一边 11 天之后就发了一个新的前沿模型。对我来说，这只是说明它通过了你的安全检查，对吧？
安吉拉：对。
swyx：而且这件事……
安吉拉：我们前面聊到的所有关于我们怎么发布模型的事……
安吉拉：就是我们在持续把越来越多、越来越多的安全属性放到位置上，还是在这几个……我开始用这三个维度来想这件事。
安吉拉：一个是真正的架构与基础设施安全；然后是模型干活时在跑的在线护栏；然后是对静态数据做的离线护栏分类。
安吉拉：在这三个维度上，我们都把该做的工作放到位，确保我们对「把一个模型放出去、并且它是安全的」这件事感觉良好，这基本上就是我们的意思。
安吉拉：所以对 Opus 5.5，它是一个极好的模型，它在我们在意的那些维度上、在这三件事上都真的非常好，因此我们对发布它感觉良好。
安吉拉：所以我们选了我们认为、我们希望的是这段范围里最好的用户体验，同时我们会继续爬坡把误报做得更好。但显然，当你在跟一个模型干活、然后掉到另一个模型上去时，那仍然是一个让人沮丧的体验，所以我们还得继续做下去。
swyx：我觉得人们也从安全的角度理解这件事。你宁可多一些误报，对吧？这是个安全问题。我们明显看到了整套侵入事件，而你仍然在开放访问。
第 23 节 · 安全分类器与模型路由（1:12:25）
swyx：对，对。对我来说，这就像那个通用模型路由问题的近亲——你要一个聪明的路由器还是一个笨的路由器？这么说有道理吗？
swyx：因为据我所能看到的，Anthropic 那个回退路由器、或者说那个检测的东西，是一个单独的模型在线上跑。
安吉拉：嗯……
swyx：所以它……
安吉拉：一旦打到一个分类器，后面就只是一些逻辑，告诉你需要掉到哪儿去。
swyx：完全对。所以它并不是完整的 Fable，对吧？你没有把全量的 Fable 跑上去，而这会造成分类问题，因为它显然没有 Fable 那么聪明。显然如此。
swyx：那么问题就来了：当我遇到一个分类问题，那其实是一次没有理由的回退。你根本从来不需要回退。我只是在做生物作业，但我提了一次生物，然后它就可以回退。所以问题是……
安吉拉：这跟路由问题非常像……
swyx：非常像，对。
安吉拉：你在给模型做路由……
swyx：而一个笨模型怎么能路由到一个更聪明的模型，如果它连这都认不出来？那是聪明模型才做得成的问题。
swyx：嗯……我们怎么解决这个？
安吉拉：这是个很难的问题。[笑]
swyx：我、我、我觉得在某种超级对齐的意义上，模型擅长分类东西，但不擅长回答它们，对吧？最聪明的模型能告诉你这是一个危险的查询，即使它自己也做不出任何影响，所以……
安吉拉：我觉得超级简化的说法会像是：基本上你让更聪明的模型来判断，而不是让那个要去做检测的……
swyx：我觉得人们也……它更慢，X 倍成本。
安吉拉：那里是有权衡的。我不是说那就是正确的用户体验，但那可能是一条稍微更有效的路。
swyx：我觉得有意思的一点是，你也不是立刻就切断。我见过一些情况，它开始回答、开始推理，然后才被安全过滤器打到。
swyx：所以我第一个 Fable 的例子，就是把 Fable 的安全卡片扔进去……然后它开始……我说「把这里所有有意思的东西都拆开讲讲」。它开始拆，五分钟后……
安吉拉：对……
swyx：然后它碰到网络安全，然后……
安吉拉：对……
swyx：「哦，我们要切了，我们要回退到 Opus。」但它已经干了很多，而且有很多上下文，我看到了。它到某一点，整个都在讲网络安全、安全……
安吉拉：嗯……
swyx：然后它回退了，而且它回退的不是我那条查询，是推理和整条链的组合，对吧？
安吉拉：对。
swyx：你有没有什么想法，怎样更好？我们一起脑暴一下吧。什么更好？我觉得用户体验、以及我们怎么解决这个用户体验，大概是另外一个问题。也许它是一个新的超级聪明的模型来处理，或者别的什么。
安吉拉：但我认为，我脑子里对用户更合适的 UX，其实是跟 Claude 有一个更一致、更统一的体验：不是让你回退、然后你可能再二次回退，而是我们的树里有那么一些逻辑上的点在做这件事——同样是为了安全等等的原因。
安吉拉：但在 UX 上，对用户来说就是真的很绕。就像你……
swyx：你想做点什么，而我会拿一个「好用户」的情况来说：你是个好用户，你只是想干点事，于是你做生物作业，比如评估网络安全，比如那张安全卡片。
swyx：完全合理，然后你被挡住了，你回退了。我觉得更好的样子应该是……
安吉拉：我们的模型本该——或者说分类器、随便你怎么做——本该聪明到能识别出这是会发生的情况，然后更具体地把答案给你写下来，同时把那个特定能力的负面用途的性质往下压。
安吉拉：回到那个生物作业的场景：虽然我们可能有分类器检测到它可能是生物……
swyx：嗯……
安吉拉：我也要说，在 API 上，我们为这件事给客户做了一整套方案。
安吉拉：首先，如果你在 API 上建了东西，遇到一次拦截，你不必用回退继续对话。
安吉拉：那是我们在自家应用里做的，我们也把它做成了 API 的一个特性，你可以在我们的 API 里、在服务端做这件事。你可以选择「我要做回退」，然后我们就做。
安吉拉：我们也在 SDK 的客户端侧提供了这个。如果你想把回退用各种方式管起来，有对应的 helper。
安吉拉：或者你可以选择用某种方式重新 prompt，然后继续用同一个模型。
安吉拉：但我确实认为有一些中间的、有意思的方案，我们会继续试，看怎么在不安全的前提下解掉人的阻塞，同时保持好的用户体验。
swyx：对。然后你提到它很像路由器，我完全同意。我认为它也有同样的 UX 问题。
swyx：比如路由，你走过去，假设你想做一个成本路由器，按你任务的复杂度来路由，这有道理吧。但非常难做。
swyx：你并不预先知道关于你任务的一切，所以你不能……即使信息完美，你实际上也没有完美信息。即使你能完美理解每个模型——而你不能——即使可以，你对你的任务也没有完美信息。
swyx：所以你的路由逻辑会带着很多误差，无论你造出来的分类器多好。
swyx：而且，也许那是一个超级大脑模型类型的问题，但无论如何，我认为这是个非常难的问题。
swyx：在每一种那样的场景里，要找到正确路由的办法，都非常非常绕。
swyx：你可以把所有这些逻辑都暴露给客户：「嘿，你的任务是把一个 div 居中，所以我把你路由到非常便宜的那个。」然后另一个是「检测漏洞」，所以我把你路由到非常贵的那个。
swyx：如果你把这些全暴露出来，我认为那最终也不是很好的用户体验。
swyx：而对这一类问题，我觉得更理想的 UX 会接近动态的「努力程度」，或者动态地理解你任务的复杂度——而随着你对任务了解更多，这个复杂度实际上可能会演化。
swyx：但在那个世界里，如果你在很多不同模型之间来回走，它实际上会变得非常割裂。
swyx：所以也许一个更统一的做法会是：它就是一个一致的模型，只是努力程度非常非常低，实际上非常非常便宜、非常非常可负担，但它可以非常非常连续地把自己放大；而你对这个模型有一个非常非常一致的人格。
swyx：显然我们是在我们自己这一系列模型的语境里说这件事。如果你试图跨其他系列的模型、其他模型提供商做这件事，人格、割裂感，就开始变得非常非常复杂。
swyx：在那个层面我不知道怎么解决，但至少在我们这一系列里，我更看好更一致的东西，那些可能是更稳健地解决这个问题的方式。
安吉拉：对。除了 Claude 之内，你不对任何人负责。对……这是你的地盘。
swyx：看到你们怎么想这些问题挺好的，对吧？
swyx：意图本身就是个难题。我感觉模型确实变好了，但有时候人对自己想要什么做得也不好，或者他们直接滑到某一个极端，或者模型其实没真懂。你问一个简单问题，它给你一整个 HTML 落地页。我只是想要几行输出，你知道吧？[笑] 所以那里永远是一团乱。
安吉拉：对。我觉得我们……在这次对话里我们聊了很多安全、聊了发布模型、聊了所有这些，但它显然是为了帮人们把负载跑起来。
安吉拉：而且就像我们这场对话前面聊到的，我们看到负载正在变化相当大。我认为在某些负载上，智能看起来确实越来越饱和了，这是一个新的情况。
第 24 节 · 正在出现的 agent 负载（1:19:25）
安吉拉：而且它正在走到这么一个位置：有一些类别的任务仍然非常非常不饱和。我其实认为可能比人们预期的更多，但它们越来越多地走向那个方向——你要通过在历史上你真的没法硬啃的事情上做极长的 agent 任务，才能拿到那个 alpha、那个回报；而现在有了多得多的智能，也许你就能硬啃下来。
安吉拉：而那些负载对我们来说真的非常迷人，我们在那个领域看到很多价值：既有企业从中为自己拿到价值，也有新公司、创业公司、随便你怎么描述，他们有兴趣在上面做 agent 产品。
安吉拉：我觉得，如果看今天这一类的任务，很多倾向于……显然很多是编程。
安吉拉：显然也有很多企业、创新加速之类的东西，但它们往往采取的形状是：把某个非常明确、具体的流程自动化掉。
安吉拉：我认为在一些领域，这真的开始奏效了，这很棒；在一些领域还不行，所以还有很多空间去演化、去把那些模型的前沿推出去。
安吉拉：然后还有这一类新负载，比如我们刚聊的生物，或者一些网络的东西。那是一个……我会说，一套非常非常复杂的硬工程或硬科学问题。
安吉拉：那些负载也越来越多地出现，对我们来说是一个真的很有意思、能给客户交付价值的空间。
swyx：你知道吗，你处在世界上少数几个正在发现所有这些负载、并且我们正在把它自动化的位置之一。这……挺疯狂的。
安吉拉：[笑]
swyx：我是说，那非常鼓舞人。你们正在产生这么大的影响，我真的很感激。我们要进入几个收尾问题。
安吉拉：当然。
第 25 节 · 对抗 AI 垃圾（1:20:55）
swyx：……我想在你们两位之间来回问一下。你们团队里怎么对抗 slop？
凯特琳：嗯……这个其实我们团队内部有过一场很有意思的辩论。
凯特琳：我们跟别人没什么不同，对吧？我认为很多团队都在谈这件事。
凯特琳：有意思的是，我们想弄清楚的是：如果你在产出一份文档、你在产出一些你希望别人消费的东西——代码、文档、随便什么——对吧？你当然应该用 Claude 来帮你，对吧？
凯特琳：但如果你用 Claude 把一个东西完全生成出来，你自己一点时间都没花在真正读它、确认它是不是高质量上，那你就是在给那份文档、那段代码、随便什么，给它的消费者额外加了一整份负担：让他花一大把时间去琢磨它。那简直就是荒谬，而且完全不公平。
凯特琳：但好笑的是，你知道，我们会在团队里顶回去，说「你不能这么干」，对吧？
凯特琳：如果你在产出什么，用 Claude 当然没问题，但你必须确保它是个高质量的东西。
凯特琳：对，你作为人仍然对质量负责。
凯特琳：你仍然对质量负责。但接着就进入一件真的很好笑的事：因为那些「Claude 味」，甚至只是很小的东西，比如——我不知道——中间来一个破折号，对吧？
凯特琳：人们的大脑就会触发：「哦不，我在读的是 Claude 写的、不是人写的，我很烦，因为我想读的是由……」不一定是完全由人产出的，但至少是有人的质量线的。
凯特琳：于是我们就进入一些很好笑的处境：也许这个人其实花了很长时间确保那个东西是高质量的，他只是用 Claude 帮了忙，但那里有那些小小的 Claude 痕迹，然后读者就关掉了，你知道吧？
swyx：嗯。
凯特琳：而那同样是不划算的。
凯特琳：所以我们试着做的，是在团队内部设一条线：用 Claude 帮你，因为如果你不用这个强得离谱的 agent 来在工作和生活里加速、或者只是帮你产出更好的东西，那真的很傻。
凯特琳：但它必须达到某条线。然后对消费者、对读者来说：如果它真的就是垃圾，退回去。[笑] 对吧？就是说不，直接退回去。
凯特琳：你不会把时间浪费在这上面。但也别对那些小小的「Claude 味」太吹毛求疵，对吧？因为这里我们得找到正确的平衡。
凯特琳：所以这真的很好笑，因为我们自己在团队内部就来回拉扯这些事，而世界上所有人也都在拉扯。
swyx：对……
凯特琳：眼下。我们一点都不特殊。
swyx：但你们有免费 token。[笑]
凯特琳：呃，好吧。但……我是说，这倒不太重要，当它涉及……
swyx：意思是，你们比世界上任何人都有更多。
凯特琳：嗯……
swyx：你们大概看到很多……
凯特琳：对……
swyx：你们用得多，就看到更多人在做更多事。
凯特琳：对。[笑] 嗯，对。这话完全公平，但它确实、确实是个问题。我们非常不鼓励。
swyx：[笑] 对。那工程上的 slop 呢？
凯特琳：对，我是说，是一回事，对吧？同一件事。
凯特琳：不过我也确实认为，我们到的地方是一个还不错的位置：人扮演了很大角色去确保系统的设计是好的，对吧？
凯特琳：而实现往往交给 Claude，对吧？
凯特琳：而且我们在一个还不错的位置上：对很多写出来的代码，你真正需要的只是一眼盖章，然后继续；你不一定需要有人逐行深度 review，因为你更关心的是整体计划、整体设计是不是健康的，而不是实现的每一个细节是否完美，同时你显然依赖一整套验证来确保你要发的东西是高质量的。
凯特琳：所以这些天关于「代码质量变成 slop」的讨论其实少了，一部分是因为 Claude 就是变强了，另一部分是因为我们有一大堆正确的验证在位，确保我们守着一条高的线。
swyx：好……
swyx：我明白了，我明白了。相信你的测试。
swyx：嗯……那产品上的、PM 上的 slop 呢？你可以发功能发得很快。你可以……[笑] 一天就把东西推出去。
swyx：他最近跟我说过这个。嗯，你记得他跟我说了什么吗？塔里克，塔里克发的推。正确使用模型能力的方式，不是往生产里塞十倍的功能。
swyx：而是花更多时间理解你的用户、做实验、搭点什么。但基本上，你知道，你很容易就可以一直发随机的东西，但你应该真的想一想。
swyx：你应该花更多时间在开第一个 prompt 上。我知道他今天会说：「开 plan mode，我们已经不需要它了。」[笑] 但在 plan mode 之外，你应该想一想你在干什么，对吧？发很多东西很容易，然后你就得到产品 slop。
凯特琳：对，我倾向于在这件事上发一通脾气：关于软件、关于产品怎么被规划、怎么被交付等等，有很多基本功，并不会因为 agent 在帮忙加速流程的某些部分就需要改变。
凯特琳：但很多人身上开始冒出一种天然的、几乎是懒的东西：「哦，流程里的某一部分我完全不用想了，因为 agent 在做、在帮我，或者随便什么。」
凯特琳：可那些仍然是流程里极其基础的部分，本该是你花时间和精力的地方。我觉得这就是他那个说法的精神。
swyx：就是，作为一个创始人、或者创作者，我们也这么叫吧：感觉因为现在做实验、做探索的成本太低了，所以我应该多做一点；而他基本上是在说别这么干，要把它用在一个你从一开始就有的、非常明确的目标上。
swyx：这个嘛……我显然正在被说服，只是很难。[笑] 就像你有一个什么都能干的玩具，那当然就往墙上扔。[笑]
凯特琳：对，这里也有范围的问题。
凯特琳：比如今天那篇博客是「用两周让 Claude 变快」。里面有 12 件事。我们其实……有 13 件事。我们三天里达成了 13 个目标里的 12 个，对吧？
凯特琳：你完全可以说，好，这是一个两周的冲刺，我们做这 13 件；但反过来，有 20 件事你顺手就推过去了。这不是产品 slop，也不是新产品，这是重构。
凯特琳：但即便如此，你们确实很擅长一边大量产出、一边守住高质量。
swyx：对。很好。好，三部分里的第二部分。这会让安吉拉很不舒服。[笑] 这是安吉拉三角区。
swyx：我会告诉……[笑] 好。哦不。[笑] 我会、我会不停地告诉人们去……
安吉拉：唉。
swyx：我、我、我很确定你删过一些东西[笑]。
swyx：因为我会觉得，你的删除里有些东西，我觉得……
安吉拉：你喜欢？
swyx：还是……对，我知道。那些东西真的改变了我的 DNA。
安吉拉：哦，我很感激。
swyx：嗯……哇。你会推荐人们去看什么……这是很高的评价。你脑子里想得最多的是什么？你最常把人引向什么、想提起来的是什么？如果你愿意，我可以帮你调出来，但……
第 26 节 · 管理、写作与工作方式（1:27:25）
安吉拉：嗯，其实我不觉得我有最喜欢的一条，老实说。
swyx：哦，得了吧。
安吉拉：不，我真的没……好吧。我猜我可能喜欢你说的那条：「一半地在做某件事，是一种昂贵的、不做它的方式。」对。
安吉拉：也许那是我最喜欢的。
swyx：那对我们今天非常切题。好，太好了。[笑] 太好了，我喜欢。对。不过我猜……你知道，你现在显然在做不同的工作……
安吉拉：对……
swyx：你不再做这件事了，但那个……我认为这是一个强力工具。这像是纳瓦尔·拉维坎特那种……[笑] 是纳瓦尔认识你会做这个……
安吉拉：嗯哼。
swyx：那你是处在什么模式、什么心境框架里？
安吉拉：心境？好问题。六年前。[笑] 对，不是。
安吉拉：所以这是很久以前的事了。我经历过人生的一段时期，我实际上在不停地读书。
安吉拉：我发现自己对当时做的事非常无聊，我觉得自己在智力上就是没有被挑战。
安吉拉：所以我实际上进入了一段有点像暴走的时期：我大概在一年里读了两百本左右的书。我就是对每一件事都好奇……我就是想把一切都读掉。
安吉拉：我缺一点那种智力的……锻炼，你在学校里会得到的：他们说「这是一个新话题，你得学」，那很难，其实也不那么好玩，但你确实在把自己拉开。而我觉得在工作了几年之后，我就不再做这件事了。
安吉拉：工作是有意思、是有挑战，但它没有那一点点智力的东西。
安吉拉：总之，我就进入了这么一段暴走、一段读书暴走，一年读了两百本书，很棒。我那时候通勤很长，所以那是一种……很好地利用我的时间，很长的 Caltrain 车程。但最后我从里面出来，就是在很多地思考。
安吉拉：当时，那真的不是为了建什么推特粉丝……或者别的。我只是在往虚空里发推。我有……我几乎没有粉丝。
安吉拉：那些推是给我自己的，我在练一件事：我怎么把我脑子里的想法用尽可能少的字压进去。那有点像是我给自己设的一个测试。
安吉拉：然后，我猜人们开始喜欢它，所以我就继续做下去了。后来工作太忙，我就停了。
swyx：我得问一下，读了那么多之后，有没有书、博客、长文推荐？
安吉拉：有……我最喜欢的可能还是《黑天鹅》，纳西姆·塔勒布。
安吉拉：那是那种——至少对我来说——有点像一本改变人生的哲学书，让我觉得：看世界有完全不同的方式。
swyx：这个概念……Fable 那件事发生的时候我就在想《黑天鹅》。
安吉拉：真的吗？
swyx：对，Fable 那件事，对吧？那是一件你不知道会发生的事。非常是。
安吉拉：而它一旦发生，它就永久地改变了你关于事情如何运转的框架。
swyx：完全对。
安吉拉：而且这个想法很简单，但我觉得他把它讲得非常到位、把它表达得很清楚，以及它是这世界如此多部分的一个共同属性。
安吉拉：所以我真的很喜欢那本书，那大概是我最喜欢的。对听众来说，如果你觉得那本太闷，还有《随机漫步的傻瓜》，也是塔勒布写的。
swyx：你喜欢……在他变得……《反脆弱》吗？
安吉拉：没那么喜欢。差很多。没那么喜欢。对。他越出名，就越难以忍受。[笑]
swyx：但也问一下凯特琳，如果你有一条的话。你有没有类似「这是我推荐给所有人的书」？
凯特琳：没有。
swyx：好吧。好问题。
凯特琳：对，我得想一想。有意思，因为我确实认为我们在这方面风格非常不同。
swyx：对。她不再是那种发幸运饼干式推文的模式了……
凯特琳：我停了，对……
swyx：你停了，但我确实认为你工作方式、以及你跟别人一起工作方式的一大部分，有时候是哲学家模式，你懂吗？你会在 Slack 里丢幸运饼干吗？[笑]
凯特琳：哦，我其实真的会。
swyx：哦。
凯特琳：不是有意的。我觉得更多只是我在某处想把自己表达清楚。
swyx：但我认为那就是核心的成功——一直在做——成功做这个的核心，就是你必须在 Slack 上非常厉害。
凯特琳：哦，你确实必须在 Slack 上非常厉害。这其实是真的，对吧？
凯特琳：虽然那是个挺紧张的地方，但我有点……我对邮箱和 Slack 的「收件箱清零」有点偏执。现在邮箱比 Slack 容易。
凯特琳：但我修剪得挺有攻击性：这是我真正在、真正在关注的频道，那些是被我静音、放在线下面的，就这样。我总是确保自己在需要跟上的那些频道上是跟上的。
凯特琳：但那基本上、那感觉像一份全职工作。有些日子我会觉得，我可以取消所有会议、不写文档、不干任何活，就真的坐在那儿刷一整天 Slack，而我会感觉自己干了一整天的工作，就靠参与那一切。挺疯狂的。
swyx：不，但那太可怕了。那你是怎么做的？
安吉拉：我完全有同样的感觉。
安吉拉：我觉得你投入了所有这些努力，是的，你在回复别人、把事情推进上线这些事上达标了，但你实际上没有产出你想要的那个产出。而这对我来说，是我个人很难应对的一件事。
安吉拉：所以我试着……我需要专门留出时间去真的思考、真的试着产出点什么，才能感觉自己真的在有效率。然后忽略一些东西、丢掉一些东西，对吧？你总会丢掉一些东西。
安吉拉：对。我收到过很多反馈：我在 Slack 上有点难找到。
swyx：嗯。
凯特琳：哦，对。
凯特琳：现在发生的一件挺糟糕的事是……我被告知……
swyx：被告知……
凯特琳：我会收到很多 Slack 说「你能让安吉拉回一下这个吗？」[笑]
swyx：哦，不。
凯特琳：而我在想，我真的在这儿写文档。
swyx：等等，等等，你们没有那种个人的云端助手之类的吗？我不知道，能帮你们的？总得有办法吧，帕姆，但显然……
swyx：所以我没有人——没有人给你们每个人写一个私人助理……
swyx：在非编程模式里。
凯特琳：嗯，我们其实也有，我们也有一个真人的。
凯特琳：对，对。我们在 Slack 里当然也有大量的 Claude 帮忙。
凯特琳：但我确实认为，我在修剪、在处理的那类 Slack，往往是我们团队被某件事卡住了，因为有个艰难的决定需要做，或者别的什么，对吧？
凯特琳：而这就是一种形式——不管是在 Slack 还是别的什么地方——一种把团队解阻、把事情高质量执行下去的形式，那本来就是我的工作，只是它恰好大量发生在 Slack 上。
凯特琳：但我同意，那最终会让你觉得：我到底产出了什么？当你一整天就只是在跟人来回、试着解决问题……
swyx：你……你产出了一个能运转的团队。
凯特琳：对。[笑] 完全对。你——那是把团队解阻了。
swyx：所以我要为这个给你记一功。作为一个前管理者，那是……
第 27 节 · 组建 DevRel 团队（1:33:25）
swyx：对、对、对，你感觉自己什么都没产出，但你产出了一个团队。说到你的团队，接下来我想问你，凯特琳，DevRel 环节。
凯特琳：哦，好。
swyx：我们……[笑] 我知道你们在大量招 DevRel。
凯特琳：对。我要为开发者关系发一个招募。
swyx：你们最近招了阿迪·奥斯马尼。
凯特琳：对。
swyx：很棒的收获。还有兰斯，你知道，我不……对。
凯特琳：对。
swyx：但你们、你们还在继续建这个团队。你们想招什么样的人？你知道，这就是聊这件事的地方。
凯特琳：对。
swyx：而且我很乐意交换笔记。
凯特琳：对。那我要给你点赞，因为我要说……我是 Anthropic 招聘的外包，凯特琳招聘团队。真的，字面意义上。[笑]
swyx：这很好玩……
凯特琳：而且甚至不只是招聘。我要帮你吹一下。我加入 Anthropic 的时候，我们，你知道，我们是个小团队。
凯特琳：总体来说，我们是个极小的团队，所以我们跑平台、跑 API 生意、跑我们所有产品的基础设施。而我们当时有一个非常初生的 DevRel 职能。
swyx：对……
凯特琳：在 Anthropic 内部，它不一定在产品与工程组织里。
凯特琳：我加入的时候，我们在说：好，我们得长大一点，得想清楚怎么跟社区打交道、跟这个世界打交道，我们得真的在这个 DevRel 职能上投入。
凯特琳：最后我们在平台里建了一支 DevRel 团队，在 Claude Code 里也建了一支，一部分原因是这是我们试图打交道的两个相当不同的开发者生态：API 生意和 agentic 编程，对吧？
凯特琳：所以我们最后把它做成了两支团队，但它们之间有点虚线汇报关系，也一直在一起花很多时间。
凯特琳：但那是我将要负责的东西——DevRel。我以前在 Stripe 或别的地方跟 DevRel 打过很多交道，但它从来不是我负责的。
凯特琳：我当时想：「我完全不知道我在干什么。」然后你说：「我带你。DevRel 有三根柱子。」
凯特琳：比如「你可以这样想」，这真的非常好——产品、内容、社区这三根。现在我可以把这一套背给别人听，他们就「哇，你真的懂 DevRel」。
凯特琳：我说：「不，是有人拦下我教我的。」[笑]
swyx：你就像「我抄的」。
凯特琳：对。[笑] 对，那不是原创，帕姆。
swyx：据说那篇文章现在是谷歌给新 DevRel 做入职培训的默认读物。
凯特琳：对。真的很好笑。
swyx：对。很好。
凯特琳：它真的、它真的帮到我了[笑]，因为我完全不知道我在干什么。
凯特琳：但在这之上，我们，你知道，我目前平台里这支 DevRel 团队还没有经理，所以那是我希望招的人之一；我们的 DevRel 个人贡献者直接汇报给我，一部分是因为我认为现在这是个非常、非常、非常难的问题，但也一部分是因为我觉得它真的很好玩。
凯特琳：[笑] 我跟这个团队一起工作非常开心。
凯特琳：但具体说，平台难在哪：在我们的公共叙事里，有时候我们的平台生意是一门非常大的生意，但它会淹没在研究、政策，以及所有这些我们显然在做的、属于最前沿最重要的工作之间；然后还有我们的应用，Claude Code、Cowork，以及这边正在发生的一切。
凯特琳：当你想到 Anthropic、想到我们的公共叙事时，这些东西常常会浮上心头，而「我们在跑一门巨大的开发者平台生意、而且这么多人在上面建东西」这件事，反而更少被想到。
凯特琳：所以我们在平台 DevRel 团队里的一个大目标，是不仅想清楚那些非常经典的问题——怎么更好地跟产品、跟人们在建的东西互动，怎么把反馈带回产品里等等——很大一部分只是找到我们的声音。
swyx：嗯……
凯特琳：找到我们的品牌应该是什么、我们的叙事应该是什么、我们在这个社区里到底要成为谁，而不是淹没在正在发生的一切里。
凯特琳：所以我觉得这很有意思，因为我们开始为 DevRel 团队塑造起来的品牌——一部分原因是兰斯加入我们这支团队，是你把我介绍给兰斯的，而兰斯在他做 DevRel 的方式上技术非常深，非常像教学，对吧？
凯特琳：他写很多关于记忆、关于管理成本的东西，而且他钻得很深。他搭 evals。
凯特琳：他有一大堆非常技术的内容，我真的很喜欢这个想法：我们的 DevRel 团队在这个非常初生、非常难、非常在演化的空间里，某种程度上是大家的思想领袖。
swyx：对……
凯特琳：教育者、思想领袖、事情的讲解者。对。
凯特琳：然后还有另一个版本我很喜欢，叫「master builder（大师级搭建者）」，就是：我用这个平台把东西搭出来给你看什么是可能的，然后你就会「哦，我不知道用 Claude 平台还能这样」。
swyx：嗯……
凯特琳：然后你就出发了。对。
swyx：这是从乐高那儿偷来的东西。
凯特琳：哦，好。
swyx：对，因为乐高怎么卖乐高？他们有 master builder。
swyx：他们用乐高搭东西，然后你就「我也想干——那真正酷的是……我也想那样。我想成为这个人」。然后你就去做了。
凯特琳：很好。那很棒。
凯特琳：对，还有我们团队里另一位很棒的 CJ，我觉得他也做很多那一类的事。
swyx：对……
凯特琳：写 cookbook、给出示例，真的跟社区互动。
swyx：对……
凯特琳：所以那是……「cookbook」这个词很好笑，对吧？2023 年 LLM 的 API 刚出来那会儿……
swyx：对……
凯特琳：非常重要。现在……
swyx：没那么重要了。我不知道。
凯特琳：嗯，有意思，因为你已经不太处在「把代码复制粘贴过去用」的位置上了，对吧？[笑]
凯特琳：但我确实认为它……
swyx：它对人展示了「可能的艺术」，以及到底什么是用例，对吧？以及你可以怎么去做它。
swyx：但我懂你的意思，代码本身也许没那么……
凯特琳：比如我们很长一段时间有这么一个——我们团队有个工程师写了我们关于 computer use 的 cookbook，它到今天还缠着他，因为那东西极其复杂，你知道，是个庞然大物，而我认为当时很多人在那个时期从中受益：那时候还是「我要自己做一个 computer use 实现，我要处理所有截屏之类的事，那些发生在 messages API 之间的东西」，对吧？
凯特琳：嗯……
swyx：对，我们当时就在你们在 Office 搞的那个黑客松现场。对。
凯特琳：对。
凯特琳：而现在，你知道，更多是我们有一个 skill——比如 Claude API skill，它非常、非常擅长帮你，无论是在 Claude Code 还是别的编程 agent 里，去建一个高质量的集成。
凯特琳：而现在这类事，比如「我要做一个 computer use 集成，我该怎么做」，我觉得/希望已经很少有人在翻那本又大又难缠的 cookbook 了，更多是加载一个 skill 到一个编程 agent 上，然后走一遍。
凯特琳：对。
swyx：或者他们直接把它放进一个参考架构里。它其实效果好得多。
凯特琳：对。
swyx：我们越来越多看到，很多你原本可能想要不同实现的东西——通常在 harness 层，但也可能有别的变体——你只要把 Claude 指过去，说「这就是我要的参考架构」，然后你就把它建出来。
凯特琳：有意思的事实：那个帮人对 API 做开发的 Claude API skill，就是我们 DevRel 团队拥有的。
凯特琳：所以那是……兰斯做的。
swyx：本该如此。本该如此。对，完全正确。就是那种事。
swyx：这最高杠杆的 DevRel 形态，就是把所有最佳实践蒸馏出来，让它们进到那些 agent 里。
凯特琳：对。
swyx：其中有个原因让它很怪，因为我被当成 DevRel 的人、DevRel 的权威，但我……我身上有一部分就是想告诉你：你不需要 DevRel。[笑]
swyx：你做得足够好，你就不需要它。
凯特琳：他……
swyx：或者说，对，你把工程师、把那些负责人变成公众面孔。对。
第 28 节 · 开发者关系与产品的声音（1:40:25）
swyx：因为你真正想做的其实就是公众面孔，以及「我们这里是这么干事的」，然后，差不多就这些。你……有时候那是自然的……你在做公益式的分享。
swyx：你不需要，你知道，去……人们会听说你。所以那里有……我觉得对我来说，当鲍里斯登场、突然出现的时候，那种感觉很像是「嘿，我是鲍里斯，我是 Claude Code 的创造者」，如此这般，「我们这么干事」，如此这般。而你……你会想：对，他有本职工作，但他也在承担那个功能。
swyx：那为什么不是每个人都这么干？[笑]
凯特琳：对，这是个非常好的问题。而且确实有团队把这个做得非常好。
凯特琳：比如我觉得 Cloudflare 团队就是一个非常好的例子……
swyx：他们都是……
凯特琳：对。
swyx：全都在产出东西……超级棒，对吧？不停。
凯特琳：对。[笑] 对我来说，顺带说一句，那其实是一个非常好的、非常可见的信号，说明有一个好经理：他们都对自己的工作满意，他们都在公开地认同、表明身份。
swyx：他们没有辞职。
凯特琳：对。他们一个都没辞职。
swyx：完全。
凯特琳：有意思，因为我觉得这其实是我们正在平台团队、我们团队、以及那些可以出去、成为社区一部分、去讲、去在 X 上、去在他们所在的任何地方的人身上，想做得更多的事。
凯特琳：我认为我们的问题就是时间[笑]，以及知道用正确的方式把这类事高质量地做出来。
凯特琳：所以我在某种程度上把 DevRel 团队看作：他们就是在高质量地做这类事情的专家。
凯特琳：他们可以整天、每天都做，而且他们能帮团队其他人，让他们在能花的那一点点时间上，也把事情做到高质量的。
swyx：对。所以我把这个叫做 DevRel 的「解绑」，拆成一个前台和一个后台。
swyx：一个典型做这份工作的人，是从头到尾做完全程。他们某种意义上是自主的。
凯特琳：嗯哼。
swyx：但实际上你可以建起这么一个后台，让你的产品负责人和工程负责人真正去占据聚光灯，用一个简单的契约：「好，你跟我坐下来 30 到 60 分钟，我们把脑子里的东西倒出来，然后你就完事了，回去干活。」
swyx：然后我们就像、我们会替你代笔、ghostwrite，随便什么。
swyx：但那个制作的人、写作的人组成的团队，是为其余人提供服务的。
凯特琳：对……
swyx：而我觉得，那对我来说大概就是这件事的未来，老实说。
swyx：嗯。因为人们其实并不真的想听 DevRel 说，他们想听兰斯说。
swyx：而且、而且……绝对是这样。
swyx：你知道，你有……塔里克在 Target。你知道，还有莉迪亚……
凯特琳：为什么不是 Chris 来做 DevRel？
swyx：你通过 Bud 找到莉迪亚，你知道？
凯特琳：对、对。
swyx：但他在功能上……
凯特琳：他留下来了……他做这份工作……在人们心里。他做这份工作。
swyx：嗯哼。所以你会想要更多这样的人。
凯特琳：对……
swyx：因为人们想听的是做产品的人说。不是那种拿了钱的托、拿了钱代言的人。
凯特琳：嗯哼。
swyx：而那是[笑]……
swyx：那是我经常收到的评价，那没关系。那是一份工作，总得有人干。对。
swyx：你可以合理地预期，做工程的人这方面不擅长。
swyx：所以你应该付钱给专门做这个的人，专业化是一项技能。但我认为确实有一个前台／后台的分工可以浮现出来。
凯特琳：嗯……
swyx：那真的很酷。对。
swyx：我的类比是：每个人都在招人，但你有一个人力资源部门。人力资源部门让你能招人。
凯特琳：确实。
swyx：你招人。就像……
凯特琳：对……
swyx：对。[笑] 这太有道理了。
swyx：好。酷。
第 29 节 · 拿 Opus 5.5 试什么（1:43:25）
swyx：那是我的小讲台。嗯……[笑] 你知道，收尾问题。你一直非常慷慨地给时间。有什么临别的话或者号召吗？你先来。
安吉拉：在 Opus 5.5 上建点酷东西。
swyx：什么是……对，人们应该拿新的 Opus 5.5 试什么、推什么边界？你们用得最久。
安吉拉：对，我是说，它真的很划算。它话更少。
安吉拉：我们提到的所有那些。手感真的很强。很好玩。
安吉拉：昨天对我们来说是非常好玩的一天，因为……又终于，我收到了一大串朋友们的短信。
swyx：[笑]
安吉拉：还有那些就说「很棒的模型，谢谢」的人。我以前的一个老板给我发消息，他说：「Opus 5.5 刚刚在一次事故里救了我们一命。」对吧？
安吉拉：然后就想，好，太好了，我们回来了——这真的是我们感受到的那种能量。
安吉拉：所以我觉得，那些你以前想实验、但成本是你脑子里最前面的事、以及 token 效率这类东西，可能曾经拦住了你，让你没法真的放手开火、让模型跑起来。
安吉拉：我觉得那是……
安吉拉：那些是你现在应该带着 Opus 5.5 回去处理的问题，因为我觉得你会比用那些没那么划算的模型走远得多。
凯特琳：我觉得你应该试一个多智能体的设置。我觉得你会发现它做得很好。
swyx：顺带问一下，还有别的提示吗？我、我、我是说，多智能体太宽泛了。
凯特琳：不。
swyx：我觉得，等我们听到人们建了什么，会非常好奇。但是的，它应该会格外好。
swyx：对，包括——比如说——那些没有被严格定义的、而是在它们之间自行分配的角色。
凯特琳：嗯哼。
swyx：对吧？在我看来那才是新的东西。就像……对……
凯特琳：你可以给角色派活，你一直都可以给角色派活。
swyx：嗯哼。
凯特琳：你可以给 token 派活。
swyx：确实……
凯特琳：但这是，它们在自己给自己派活。
swyx：对。对。我猜，多智能体再多说一点，对吧？我们应该用 sub-agent 吗？你怎么……人们该怎么想多智能体？
凯特琳：这在某种意义上相当不错：基本上、大体上，你希望有一个 leader，然后你希望把一堆不同的东西拆开。
凯特琳：只要你能有一个你认为大体可以并行的任务，而且它们在这个任务上共享统一的上下文，我认为你会拿到很多收益。
凯特琳：当然，这取决于你在推的是什么问题，但越来越多地，这对我们来说处理很多这类事情是一种非常优越的方式，尤其是如果每个 sub-agent——或者随便你怎么称呼，sub-lead——它们是异步的，它们彼此不阻塞。
凯特琳：这大概是我会说你该在架构里关心的两件事。除此之外，就放开跑，看看 Claude 会为你设计出什么。
凯特琳：而且我认为，越来越多这类架构的事会落到这个方向。Claude 会越来越聪明。
凯特琳：它会学会怎么把自己拆开、复制自己、把自己调整到那些说得通的架构上。你只需要防止它……
凯特琳：你只需要确保它能并行处理，所以它需要共享状态，并且它需要不阻塞它的 sub-agent。
凯特琳：只要你守住这两条原则，老实说，我认为人们就该去实验，大概还该试一些真的很疯的东西。
凯特琳：而且，我不会惊讶在上面看到一些真的很有意思的东西——也许他们觉得有个很难缠、很烦、他们一直在推的不可解问题，而这样的东西可能一下就把它碾了。
swyx：太好了。对。好，大家都去建东西吧。
凯特琳：酷。[笑]
swyx：酷。
References
- 1Latent Space · 本期单集页（官方 29 段章节）
latent.space
- 2
- 3Anthropic 官方 · Introducing Claude Opus 5.5
anthropic.com
- 4AI Engineer 讲者页 · Katelyn Lesse
ai.engineer
- 5Angela Jiang 个人站 · About
angelajiang.com
- 6
- 7Anthropic 官方 · How we contain Claude across products
anthropic.com
- 8
Comments