> ## Content Index > Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt > Use this file to discover other available public pages before exploring further. # Agent 的大脑和手要分开：Claude 沙箱里从来不存凭证 - URL: https://www.hubwiz.com/blog/anthropic-brain-hands-managed-agents/ - Published: 2026-10-31T11:31:17.000Z - Updated: 2026-10-31T11:31:53.000Z - Description: 会话持久、沙箱随时可死、凭证只走代理——Anthropic 把 agent 拆成脑子和手，安全成了顺带的收益。 - Author: admin - Tags: Agent, Claude, 沙箱, 平台工程 把 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 持久，沙箱随用随起。好处有三层：首包更快、沙箱崩溃不丢上下文、不可信代码被关在一个可以随时丢弃的地方。这条和站内[子代理交接的三种做法](https://www.hubwiz.com/blog/subagent-fork-fold-context-handoff/)是同一族问题——状态放在哪，决定了失败能有多大。 **二、凭证不进执行环境。** 独立 vault + 占位符 + egress 注入，把"擦洗"问题变成"物理隔离"问题。站内[Agent 安全事故九起与六项控制](https://www.hubwiz.com/blog/agent-security-nine-incidents-six-controls/)里，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](https://latent.space/p/opus55?ref=hubwiz.com) 本文由汇智网编译整理，转载请注明出处。 > **这是「Agent / MCP」专题的一部分。**完整地图见：[Agent / MCP / 自动化完全指南](https://www.hubwiz.com/blog/agent-stack/)