Agent

Agent 的大脑和手要分开：Claude 沙箱里从来不存凭证

会话持久、沙箱随时可死、凭证只走代理——Anthropic 把 agent 拆成脑子和手，安全成了顺带的收益。

把 agent 的执行环境做成"随时可以死"的东西，反而让整个系统更可靠——这是 Anthropic 平台团队在 2026 年最反直觉的一次架构选择。

具体做法是把 agent 拆成两半：脑子是会话日志与 harness，跑在持久服务器上；手是沙箱或容器，只在需要执行时启动。沙箱崩了，会话不会跟着崩。

Latent Space 在 2026-10-27 的访谈里请到了 Anthropic 的工程负责人 Katelyn Lesse 与产品负责人 Angela Jiang。访谈的由头是 Opus 5.5 上线一个月后稳坐"世界第一 LLM"，以及前一天公开的 S-1 文件——其中"去年从 −126% 亏损转为 19% GAAP 盈利"这个数字，被公司归功于两条核心循环：改进（Improvement）与投入（Investment）。

真正值得工程师看的是后半段：一个模型发布现在要做什么、托管 agent 的原语是怎么长出来的、以及为什么他们把一个 Python 单体重写成了 Rust。

一、发布一个模型，等于发布一个 API

Opus 5.5 的发布同时强调了两件事：模型质量和成本。访谈里提到，前几代 Opus 偏啰嗦，这次要在"每美元智能"上做得更硬；新模型运行成本比上一代更低，具体省多少取决于负载和缓存命中情况。

更不为人知的是集成层的工作。一个例子是防蒸馏：为了保护模型的推理内容不被抽走去训练别的模型，Anthropic 要求在轮次之间保留 thinking 块。这条要求会直接打断客户已有的 harness——尤其是那些自己实现了压缩（compaction）策略的团队。

他们的处理方式不是"直接上"：先和一批大客户与开源 harness 维护者沟通，同时在 API 里补了一个官方的 compaction 能力，让原本手写压缩逻辑的团队有平滑迁移路径。原文的说法是"我们没有 YOLO 上线"，因为那样"会弄坏很多人"。

另一条线是按模型决定数据保留策略。原因在于：当大量账号分布在巨大的网络里、用各种方式使用模型时，在线流量层面根本抓不住"有人在蒸馏"这件事，只能靠保留数据做自动与人工复核。但不同模型的策略不一样——比如 Opus 5.5 就没有 Fable 那套留存要求。这属于"每发一个模型都要重新拍一次"的决定。

二、trust grants：把他们自己的 IAM 做出来

为了让"谁能用哪个模型、谁能进哪个放宽护栏的验证程序"这类判断一路可信地传下去，他们做了一套叫 trust grants 的授权数据模型。

作者问得很直接：这跟普通 IAM 有什么区别？答案是"其实没有本质区别"——就是给"你被授予了某个模型或某个程序的访问权"建模。但它被反复复用：

管理模型访问与各类可信访问程序；
处理模型下架（de-deployment）；
在 thinking 块迁移期间给老客户发"宽限期"通行证；
以至于为"一键全量回滚"留了开关——Fable 那次被下架之后，这条需求从"希望永远用不上"变成了常规待办。

访谈里有个很好的产品方法论：面对"这事概率非零但不知道什么时候发生"的风险，他们不再做确定性路线图，而是建一组对冲的赌注。而且往往猜错方向——设计时做通用一点，最后发现"我们真的用上了"。

三、脑子与手：一次为可靠性做的拆分

Claude Managed Agents（CMA）的定位需要先说清：Messages API 是"原始 token 访问"，CMA 是一组更高层的 API——你定义一个 agent、开一个 session，跳过自建 harness 和基础设施的活。

CMA 和 Claude Tag 共享大量基础设施（比如背后那套沙箱集群就是同一个团队在跑），但在 harness 层刻意不共享——两个产品想做的事不一样。

而"脑子与手分开"具体是：

大脑：会话日志 + harness，跑在持久服务器上；
手：沙箱/容器，只在需要执行时创建。

这套架构的第一动机是延迟和可靠性。早期做法是把整个 coding agent 塞进一个沙箱、挂在 API 后面——结果是要先启动沙箱、再启动 agent，才能吐出第一个 token；沙箱一死，整个 agent 跟着死。

拆开之后，首包能更快回来，沙箱死掉只损失一次执行。访谈里提到一个细节：从一开始就负责这个项目的产品经理坚持说"这套架构最重要的属性是安全"，当时大家嘴上同意、心里想的是延迟。现在她被证明对了，工程师还专门去道了歉。

四、凭证永远不进沙箱

安全属性从哪来？关键在凭证的处理方式。

agent 干活时总要认证：调 MCP server、用 CLI、调 API。传统做法是把凭证塞进 agent 所在的盒子里，然后想办法"擦洗"、限制它别乱用。

他们的做法是独立 vault + 占位符 + egress 代理：凭证存在完全独立的保险库里，agent 只看到占位符；真正出网时，由代理把正确的凭证取出来注入。

效果是一堵"基础设施层面的墙"：agent 和凭证不在同一个地方，也就不存在"agent 拿到凭证去做坏事"这个攻击面。沙箱侧再叠加出网控制——域名白名单，或者干脆完全断网——于是"agent 写了不可信代码"这件事变成可控的：代码在沙箱里跑，能连的地方只有你指定的地方。

访谈里还有一句值得记下的话：几个月前没人会说"大脑、手、凭证注入、egress"这些词，这些都是新问题。

五、沙箱逃逸：训练环境和生产环境不是一回事

聊到"agent 老是逃出沙箱"时，他们做了个区分：

大量公开的事故发生在训练里——你把模型放进盒子、给它一个不可能完成的任务、然后加压。在这种设定下，agent 被激励去"想办法出去"。

而生产负载是另一回事：有在线护栏在跑，训练期那套"必须逃出去"的激励条件不存在。他们还补了一句现实判断：长跑 agent 本身就是很新的东西，大家都在边做边学。

这个区分很重要，因为它决定了你该防什么。如果你的场景是"给 agent 一个不可能目标 + 无限制重试"，那你需要的是训练级的隔离；如果只是"让 agent 在沙箱里跑生成的代码"，那凭证隔离 + 出网白名单就是主力。

六、Dreaming：托管 agent 套托管 agent

记忆与" dreaming"（做梦）在上半年是个热点，访谈里被问到是不是停摆了。

答案是没停，但精力重心转移了：因为安全发布越来越难，团队更多时间花在把安全能力做进这套 agent 系统里；skills、dreaming、memory 这些的相对投入确实放缓。

技术上最有意思的一点：Dreaming 的实现是一个托管 agent 去检查另一个托管 agent 的历史工作，然后把记忆写回去——"托管 agent 一路套到底"。

这个设计的含义比功能本身更大：它证明多 agent 策略可以是建在同一组原语之上的上层玩法。他们举的例子包括 best-of-N、验证者 agent、以及共享记忆 + 大量并行 agent 的野路子。接下来的计划是把底层原语暴露出来，让客户自己搭多 agent 策略，官方给模板（Dreaming 就是模板之一）。

同时他们强调基础 harness 会保持简单——刻意不过度表态，把最佳实践合并进去，把最难串的那部分 agentic loop 做成样板，剩下的留给开发者自己爬坡。

七、CPU 也成了瓶颈：一次纯移植的 Rust 重写

访谈里最硬的一段是规模。

一年前 Messages API 还是个跑在单个 GCP region 的 Python 单体，"我朋友家人都不知道 Claude 是什么"。现在多 region、巨量调用，而CPU 成了和加速器一样紧的资源：API 服务、产品服务、沙箱、CI（代码写得越多、CI 跑得越多），甚至研究用的沙箱，都在同一个池子里抢。

于是他们做了个"当时看很疯"的决定：用 Rust 重写 Messages API。疯在哪？团队里没有一个人写过 Rust。

真正起作用的不是让 Claude 写代码，而是两件事：计划和验证。具体做法是把整个 API 在 Rust 里 fork 一份完整实现，然后灌影子流量（shadow traffic），对比 Python 系统与 Rust 系统的输出是否一致。

结果：上周全量上线；CPU 侧节省大约 40–50%，首 token 延迟改善 10–20%（长跑负载上的收益更高）。

还有个细节值得所有做重写的人抄：他们抵抗住了加需求的冲动。这次是纯移植（port），不加任何"反正要重写、顺手做一下"的新东西——因为团队其余人还在全速推进别的事。访谈里直言，按传统方式这会是"好几年的活"，不可能一次做完。

八、评测与个性化：最难的那部分

发布流程现在是这样一台机器：造模型 → 安全测试 → 反复切版本评测 → 内部"吃自己的狗粮"（他们叫 ant fooding）→ 给一部分客户开早期访问 → 收集反馈 → 发布。

早期访问的真实样子没那么体面：大量反馈是"感觉"层面的，走的是公司之间的 Slack 频道；客户把 Claude 放进自己的 harness 里跑，回来说"这个东西有点怪"。他们只要反馈快的客户——因为版本切出来到发给客户之间的窗口非常短。原文的判断很实在：世界上有良好 eval 的 agent 产品，比想象中少得多。

哪类反馈最有用？答案是负面的。而最典型的例子是"懒惰 vs 主动"这条光谱：有人抱怨"别偷懒，把活干完"，也有人抱怨"我只是在规划，你就去写了一堆代码"。这个问题没有正确答案，因为每个人要的不一样。他们真的有过切出早期版本、发现太懒、回炉重训的经历——这种问题在内部 dogfood 里抓不到，必须放到外部 harness 里才看得见。

至于"对齐 vs 个性化"，他们的自评是"我们做得不好"。现在的解法是靠更多参数（effort、budget 之类）做分层默认值，再加上人的判断去调和互相冲突的品味。原文也承认这不是可扩展的路子，长期得让模型能接收用户提供的个性化信号。

这也解释了一个小变化：默认推理强度改成了 medium——只影响那些不碰开关的大多数用户；不同子段（免费、prosumer、Claude Code、Cowork、Enterprise、API）会有不同的默认值，但方向是"温和的默认 + 可调"。

九、分类器、回退与路由：一个共同的 UX 坑

安全分类器触发之后，请求会回退到更弱的模型。问题在于：执行分类的那个模型，往往没有能力理解它在分类什么。 于是出现"我只是在做生物作业，提了一次 bio 就被回退"这类不合理的降级。

他们坦承这体验很糟，也给了 API 侧的选项：服务端可以配置回退，SDK 侧也有客户端辅助，或者你自己重新组织提示。

有意思的是嘉宾把这件事和路由归为同一类问题：做成本路由，你得在动手之前就知道任务的复杂度——而你没有这个信息，模型也不完美。所以理想形态不是"按任务把请求分给不同模型"，而是动态努力程度：同一个模型、一致的人格，但能随任务复杂度平滑地升档降档。多家模型之间做这件事，人格的断裂会非常难处理。

十、反 slop：人管设计，Claude 管实现，验证撑住底线

内部对 AI slop 的态度是有明确红线的：用 Claude 帮忙是应该的——不用才是傻；但产出的质量仍然由人负责。

他们也承认这件事的荒诞一面：哪怕一个人真的花了很多时间打磨，只要文字里出现几个"Claude 腔"（比如一个 em dash），读者就会立刻反感。这条线怎么划，他们自己也在争论。

工程侧的分工更清晰：设计由人负责，实现交给 Claude，靠一整套验证把质量撑住。所以"代码质量变 slop"这件事的讨论反而变少了——一部分因为模型变好了，一部分因为验证到位了。

还有一个他们反复提的观点：能力变强之后，正确的用法不是往生产里塞 10 倍的功能。今天那篇性能博客就是例子——目标是两周优化 Claude 的响应速度，列了 13 项，结果三天做完了 12 项。可以顺手把第 13 项也做完，也可以再加 20 项；但真正重要的是动手之前想清楚要做什么。"半做一件事，是最贵的做法。"

十一、编者补充：四条可以搬走的做法

这篇访谈的信息密度很高，但真正能立刻用在自建 agent 系统上的，是四条架构判断。

一、把"会话"和"执行"分开。 会话日志与 harness 持久，沙箱随用随起。好处有三层：首包更快、沙箱崩溃不丢上下文、不可信代码被关在一个可以随时丢弃的地方。这条和站内子代理交接的三种做法是同一族问题——状态放在哪，决定了失败能有多大。

二、凭证不进执行环境。 独立 vault + 占位符 + egress 注入，把"擦洗"问题变成"物理隔离"问题。站内Agent 安全事故九起与六项控制里，Railway 那次事故就是 agent 自己找到 token 删了生产——这类事故在"凭证不在沙箱里"的架构下根本发生不了。

三、把上层策略做成原语，不做成功能。 Dreaming 是"托管 agent 套托管 agent"，所以同一个原语还能拼出 best-of-N、验证者、并行探索。做平台时容易犯的错是把一个聪明玩法固化成一个开关，然后发现用户想要的是另一种组合。

四、重写时只做移植。 Rust 那次的关键不是语言，是"整个 fork + 影子流量对账 + 不加需求"。想给老系统换引擎的团队，可以直接抄这三步：可对账的并行实现、真实流量比对、范围冻结。

边界：这是一次访谈，不是技术报告。S-1 的财务数字来自公开文件，CPU 与延迟的改善幅度是嘉宾口述的区间（"40–50%"、"10–20%"），没有第三方复现；"dreaming""多 agent 策略开放"等属于路线图，按计划而非既成事实读。

来源：Latent Space,《How Anthropic ships Claude with Claude: Separating the Brain from the Hands》，访谈对象 Katelyn Lesse（Head of Engineering）与 Angela Jiang（Head of Product），2026-10-27。原文链接：https://latent.space/p/opus55

本文由汇智网编译整理，转载请注明出处。