先看证据
模型发布，已经包含运行时设计
Anthropic 的 Claude Platform 提供 Managed Agents，用来运行会调用工具、执行代码的智能体。Katelyn Lesse 与 Angela Jiang 在谈 Opus 5.5 发布时，也谈到这套托管架构如何把会话、编排和执行环境拆开，服务对象是需要在真实工作流里部署智能体的开发者与团队。
这让一次模型发布不再只是“换一个更强的模型”。模型能力提升会带来安全与访问控制问题，使用量增长则会把延迟、基础设施成本和故障恢复推到台前。模型、API 和运行时因此成了同一项交付：模型的表现固然重要，客户现有的 harness 能否接住它，也决定了升级是否可用。
把会话、编排和执行拆成三件事
Anthropic 所说的“大脑与双手”，可以具体拆成三部分：Claude 负责推理，harness 负责调用模型并调度工具，会话日志则保存任务过程；沙箱和其他工具构成执行端。早期方案把会话状态、harness 和执行环境塞进同一容器，容器出故障时，任务状态和执行能力也可能一起丢失。
在 Managed Agents 的设计里，harness 留在沙箱之外，需要运行代码时才调用独立沙箱。沙箱失败可以作为一次工具错误返回给 Claude，必要时再创建一个新的；如果 harness 自身故障，外部保存的事件日志则能支持恢复并从已有事件继续。完整记录也不等于模型当前上下文：harness 可以选择要读哪些事件，再整理后传给模型。
安全边界落在凭证和网络上
把不可信生成代码放进沙箱，并不等于代码从此安全。更具体的设计目标是让沙箱里没有可直接读取的服务凭证：凭证保存在沙箱外，需要访问服务时由代理按需处理；Git 等操作也可以通过预先配置的方式完成，而不是把令牌交给代码。Anthropic 还描述了对沙箱网络流量的控制。
这种做法把一部分安全问题从“模型会不会做错事”，转成“执行环境能接触什么、凭证如何被使用、网络能通向哪里”。但代理本身、代理获准使用的权限和网络出口仍然是重要攻击面。隔离只能限制事故范围，不能替代权限设计、审计与策略配置；边界如果配错，分层架构也可能只是把风险移到了另一处。
延迟改善来自不必每次重启整套智能体
拆分也改变了启动与故障恢复的成本。访谈描述的旧做法会把整个编码智能体放在沙箱后面的 API 中，启动环境和智能体都可能增加首个响应前的工作量；沙箱消失时，运行中的智能体也会跟着中断。让会话与 harness 留在外面，意味着执行环境可以按需创建或替换，而不必把整段任务一起重来。
Anthropic 的工程文章称，这种 Managed Agents 架构让首 token 延迟的 p50 下降约 60%，p95 下降超过 90%。这是厂商公布的架构效果数字，说明其设计目标不只是隔离执行，也包括改善响应与可靠性；但材料没有提供足以独立复核的完整工作负载和测量细节，因此不应直接当作其他系统可获得的保证。
模型升级也会碰到客户的 API 边界
模型发布的兼容性问题，会直接落到客户的 harness 上。访谈提到，为了保护推理内容不被用于蒸馏，Anthropic 引入了跨轮次保留 thinking blocks 的要求；这类变化可能打断客户原有的调用或压缩逻辑。早期访问计划因此不只是让客户试跑模型，也是在他们自己的 harness 和任务里观察意外行为，收集基准结果之外的反馈。
访谈还举了 Messages API 从 Python 迁到 Rust 的例子：工程师设计并验证系统，Claude 协助写代码，迁移期间让两个版本同时接收影子流量、对比输出，再逐步切换。嘉宾粗略估计 CPU 节省约 40%–50%、首 token 延迟改善约 10%–20%，但没有给出基线或测量方法；这些是口述估算，不应与 Managed Agents 的延迟数据混为一谈，也不能直接当作客户账单预测。
记忆是编排能力，也是一项边界选择
同一套基础设施还能组合出更高层的行为。访谈把 Dreaming 描述为一个托管智能体检查另一个智能体过去的工作，再把记忆写回去。它说明所谓“记忆”可以建立在会话记录、事件筛选和智能体编排之上，并不必然意味着模型本身已经学会或永久记住了这些信息。
对正在构建长时程代理的团队，可执行的判断是先画清三条边界：哪些状态必须跨故障保留，哪些代码和工具调用应视为不可信执行，哪些凭证和网络权限必须留在执行环境之外。拆分能让这些部分独立恢复或替换，也会带来代理、日志和策略配置的额外复杂度。只有在故障隔离、权限控制和客户 harness 兼容性都能被分别验证时，这种架构才真正兑现了它的承诺。