大家好，我是玄姐。

0、导语

当大多数团队还在纠结该用 ReAct 还是 Plan-and-Solve 做 Agent 编排时，Anthropic 已经把战场抬高了一个维度，他们不再卖模型，而是在卖"运行模型的操作系统"。这不是简单的基础设施托管，而是一次从"宠物架构"到"牲畜架构"的范式迁移。

1、从"宠物"到"牲畜"：一个架构反脆弱性的故事

早期 Managed Agents 的架构和所有初创团队的方案一样"直观"：把 Agent 的三个核心组件：推理循环（Harness）、执行环境（Sandbox）、会话状态（Session），全部塞进一个容器。好处显而易见：文件操作是本地系统调用，没有网络延迟，没有服务边界设计的复杂性。

但生产环境很快暴露了这种"亲密架构"的脆弱性：

故障诊断的黑箱化：当容器无响应时，工程师只能通过 WebSocket 事件流窥视内部，无法区分是 Harness 死锁、网络丢包还是容器崩溃。最尴尬的是，为了排查故障，工程师需要进入容器 shell，但容器里同时跑着用户代码和敏感凭证，调试即越权。

规模化的困境：每个新会话都需要预拉起完整容器，克隆代码库、初始化环境，即便这个会话只是想做一次简单的文本总结。这导致首 Token 延迟（TTFT）居高不下，用户感知到的"响应卡顿"实质是容器冷启动时间。

这就是经典的"宠物 vs 牲畜"（Pets vs. Cattle）架构困境：当服务器被命名、被 hand-tend、无法随意替换时，它就是宠物；当实例可以任意销毁重建而不影响系统整体，它们才是可规模化管理的牲畜。

Anthropic 的解法听起来激进但合理：把大脑从身体里取出来。

2、三层虚拟化：构建 AI 的"操作系统抽象"

Managed Agents 的核心架构可以用一句话概括：虚拟化 Agent 的组成部分，让接口比实现活得更久。这借鉴了操作系统的设计哲学：read()系统调用不关心底层是 1970 年代的磁盘组还是现代的 NVMe SSD。

架构被解耦为三个独立接口：

1. Session：超越上下文窗口的"外置记忆体"

传统长程 Agent 面临一个无法回避的物理限制：模型上下文窗口有限。常规的压缩（Compaction）、裁剪（Truncation）都是不可逆的信息丢弃，而未来某个决策点可能需要被压缩掉的细节。

Managed Agents 将 Session 设计为独立于模型上下文窗口的持久化日志，一个追加写入（append-only）的事件流。Harness 通过getEvents()接口按需读取事件切片，可以：

这分离了存储耐久性与上下文管理策略。Session 保证不丢数据，Harness 决定怎么给模型看数据。

2. Harness：可随时替换的"编排大脑"

Harness 是 Agent 的决策循环：调用 Claude、路由工具调用、处理错误恢复、管理上下文。关键在于，Harness 本身也是无状态的牲畜。

当 Harness 崩溃时，新实例通过wake(sessionId)唤醒，从 Session 日志getSession(id)获取完整事件历史，从最后一条事件继续执行。这种设计让 Anthropic 可以：

为什么这点很重要？

因为 Harness 本质上是对模型能力不足之处的补偿性假设。官方文档中提到一个细节：Claude Sonnet 4.5 有"context anxiety"（上下文焦虑），会在接近长度限制时提前结束任务。当时 Anthropic 在 Harness 里加了自动上下文重置。但当 Opus 4.5 发布，这个行为消失了，针对旧模型的补丁变成了死代码。

自建 Harness 的团队面临持续的技术债：每次模型升级，你写的错误恢复、重试逻辑、上下文管理可能从补偿变成累赘。托管 Harness 的价值在于，这些假设的维护成本被转移给最清楚模型能力边界的人。

3. Sandbox：被降维成工具调用的"执行双手"

解耦后，Sandbox 不再是 Harness 的生存环境，而是被降维成一个标准工具接口：execute(name, input) → string。

Harness 通过函数调用方式与 Sandbox 交互，就像调用 MCP 服务器或任何外部 API 一样。这带来了几个架构级优势：

安全边界的彻底隔离：在耦合架构中，Claude 生成的不可信代码与 Git Token、云凭证共处一室，Prompt Injection 可直接窃取环境变量。解耦后，凭证存在于 Sandbox 外部的 Vault 或代理层，Sandbox 初始化时通过挂载方式注入（如 Git 远程仓库的本地配置），Agent 代码运行时对凭证无感知。

执行环境的无限可能：Harness 不关心 Sandbox 是 Docker 容器、iOS 模拟器，还是 Pokémon 游戏机（文档中的原话）。只要符合输入输出接口，任何执行环境都可接入。这为"多手架构"（Many Hands）奠定基础，一个 Agent 可以同时操作容器、浏览器、手机 farm。

延迟的质变：推理可以在 Sandbox 就绪前就开始。对于不需要立即执行代码的任务（如先分析需求、制定计划），用户几乎感受不到容器拉起时间。官方数据显示，p50 TTFT 下降约 60%，p95 下降超 90%。

3、元架构（Meta-Harness）：为尚未想到的程序设计

Anthropic 把这套设计称为"Meta-Harness"，不假设具体的 Harness 实现，只定义 Claude 需要的接口形状。

这种设计应对的是一个古老的计算机科学问题：如何为尚未被发明的程序设计系统？操作系统的答案是虚拟化硬件；Managed Agents 的答案是虚拟化 Agent 组件。

接口的稳定性：

这些接口构成 Agent 世界的"系统调用"。底层实现可以今天用 K8s 跑容器，明天用 Firecracker microVM，后天用 Wasm，对上层 Harness 和模型完全透明。

多大脑、多手的拓扑自由：

解耦消除了拓扑约束：

4、商业闭环：从卖算力到卖"运行时"

技术架构的变迁往往预示商业模式的跃迁。

定价模型的信号意义：

这标志着 Anthropic 从"模型提供商"转向"Agent 基础设施提供商"。类比云计算的历史：当 AWS 把服务器从"买宠物"变成"租牲畜"，企业才开始大规模上云。Managed Agents 试图做 AI 时代的 EC2，让 Agent 基础设施从自建变成托管。

时间线也耐人寻味：4 月 4 日收紧 OpenClaw（第三方 Agent 薅羊毛通道），4 月 7 日发布 Mythos（最强模型），4 月 8 日推出 Managed Agents。三天完成"能力展示+基础设施闭环"的组合拳。

5、对架构师的启示

1. 假设会过时的防御性设计

所有针对当前模型局限的优化（复杂的重试逻辑、上下文切片策略）都可能是技术债。设计系统时，把这些"补偿逻辑"隔离在可替换的模块（Harness）中，而非渗入数据层或执行层。

2. 安全边界必须依赖架构而非规则

"不要把凭证和不可信代码放一起"不能靠审查制度保证，必须靠物理隔离的架构（凭证在 Vault，代码在 Sandbox，通信通过代理）。随着模型能力增强，Prompt Injection 的破坏力只会指数级上升，架构级隔离是唯一的防御纵深。

3. 上下文管理是独立 concern

把"记忆存储"和"记忆使用"分开。用不可变日志（Event Sourcing 模式）存储完整历史，用可插拔策略决定向模型展示什么。这为未来的长上下文模型（或外部记忆增强）留出扩展空间。

6、结语

Managed Agents 的架构哲学可以总结为：对形状有主见，对实现无执念。Session、Harness、Sandbox 的接口定义是坚定的，但背后跑的是容器还是裸金属、用的是 ReAct 还是全新编排算法，都是可替换的实现细节。

对于正在构建 Agent 平台的团队，这提供了一个高阶的参考框架：你可能不需要立即采用托管方案，但应该把你的系统设计成"元架构"，能够无损替换大脑，能够任意扩展双手，能够让记忆独立于思考而存在。

毕竟，在这个模型能力每季度翻新的时代，唯一不变的是变化本身。好的架构不是预测未来，而是让未来可以轻松接入。

本文转载自​​​玄姐聊AGI​​  作者：玄姐