Managed Agents 架构拆解 — Anthropic 给 Agent 造了一套 K8s
来源：Feisky 编译自 Anthropic 工程博客
核心论点
Managed Agents 就是 Agent 领域的 Kubernetes。
K8s 把硬件虚拟化成抽象层（Pod、Service、PersistentVolume），Managed Agents 把 Agent 的核心组件虚拟化成接口（session、harness、sandbox）。接口固定，实现自由替换。
解决的问题
跑过长时间 Agent 任务的人都碰过这些事：
- Agent 跑着跑着容器挂了，session 没了，只能从头来
- session 卡死了想调试，Harness、sandbox、session 全在一个容器里，根本分不清问题出在哪
- 上下文窗口满了，压缩还是丢弃，怎么选都可能踩坑
K8s 十年前解决的是同一类问题：组件耦合、状态丢失、扩展困难。
三大核心接口
Managed Agents 把 Agent 核心组件虚拟化成三个接口：
| 接口 | 作用 | K8s 类比 |
|---|---|---|
| session | 发生了什么的完整事件日志 | PersistentVolume |
| harness | 调用 Claude 和路由工具调用的循环 | Pod（无状态计算单元） |
| sandbox | Claude 跑代码和编辑文件的执行环境 | 容器运行时 |
每个组件可以独立替换，互不干扰。
别养宠物（Pets vs Cattle）
最初的设计问题
把所有 Agent 组件塞进一个容器：
- 容器挂了，session 就没了
- 容器卡住了，得想办法把它救活
- 调试困难，因为容器里有用户数据
这就是在养宠物（Pet）——精心照料的单台服务器，挂了就得抢救。
解法：把大脑从手上拆下来
大脑（Claude 和 Harness）从手（sandbox）和记忆（session 日志）上拆开：
- Harness 不再住在容器里
- 它像调用其他工具一样调用容器：
execute(name, input) → string - 容器变成了 Cattle，挂了就挂了
- Harness 把失败当作工具调用错误传回给 Claude
- Claude 决定要不要重试
- 重试的话，
provision({resources})拉一个新的就行
不用再抢救挂掉的容器了。
Harness 也是 Cattle
- session 日志在外部
- Harness 里没有任何需要在崩溃中存活的状态
- 挂了？
wake(sessionId)启动一个新的 getSession(id)拿回事件日志，从最后一个事件继续
安全架构
之前的问题
所有东西耦合在一个容器里：
- Claude 生成的不可信代码和凭证跑在同一个环境中
- 一次成功的 prompt injection 只需要说服 Claude 读一下自己的环境变量
- 拿到 token 之后，攻击者可以开新 session 干什么都行
结构性解法
让 token 在 sandbox 里根本不可达：
| 场景 | 解法 |
|---|---|
| Git 仓库 | sandbox 初始化时用 token 克隆仓库并写入本地 git remote，之后 push 和 pull 都走本地配置，Agent 从头到尾碰不到 token |
| 自定义工具 | 走 MCP，OAuth token 存在安全保险箱里 |
| 外部服务 | Claude 通过专用代理调用 MCP 工具，代理根据 session 拿到对应的凭证再调外部服务 |
整个链路里，Harness 不接触任何凭证。
Session 不是上下文窗口
传统方法的问题
长时间任务经常超出上下文窗口：
- compaction：把上下文压缩成摘要
- memory 工具：把信息写到文件
- context trimming：选择性地删掉旧的工具结果
共同软肋： 很难预判未来哪些 token 会被用到，删错了就回不来了。
Managed Agents 的解法
把上下文存在 sandbox 外面：
- session 日志是持久化的
- 通过
getEvents()接口让大脑按位置切片查询事件流 - 可以从上次读到的地方继续往下读
- 也可以倒回某个时刻前几个事件看看当时的背景
- 或者在执行某个操作前重新读一遍相关上下文
类比： session 就是 PersistentVolume，数据在那里，不管哪个 Pod 来挂载都能用。
多脑多手
多脑优化
之前： 每启动一个 session 就要起一个容器，克隆仓库、启动进程、拉取待处理事件，全卡在 TTFT（Time to First Token）上。
拆开之后：
- 容器只在需要时才通过工具调用启动
- 不需要 sandbox 的 session 直接跳过容器初始化
- 推理在编排层拉到 session 事件后就开始
效果：
- p50 TTFT 下降约 60%
- p95 下降超过 90%
多手架构
- 每只手就是一个工具调用：
execute(name, input) → string - 名字和输入进去，字符串出来
- 这个接口能接任何自定义工具、任何 MCP 服务器、Anthropic 自己的内置工具
- Harness 不知道也不关心 sandbox 到底是一个容器、一部手机，还是一个宝可梦模拟器
因为手不绑定任何特定的脑，多个 Agent 之间可以互相传递工具。
内测数据
在结构化文件生成任务上（根据 API schema 自动生成 SDK 代码和文档）：
- 相比标准的 prompting 循环
- 任务成功率最高提升了 10 个百分点
- 难题上增益最大
写在最后
Managed Agents 在做的事：
- 不规定 Harness 怎么写
- 把 Agent 的核心组件虚拟化成接口
- 接口固定，实现自由替换
差异：
- K8s 是开源的，CNCF 社区驱动
- Managed Agents 是 Anthropic 的托管服务，目前只服务 Claude 生态
但设计理念是通用的： 即使不用 Managed Agents，这套脑手分离的架构模式也能自己实现。
2026-05-03 更新：Scaling Managed Agents 生产实践
来源：AI 简报 2026-05-03 Afternoon、AI Builders Digest 2026-05-03
Anthropic Engineering 发布新博客，详述 Managed Agents 如何将高层推理（"大脑"）与执行（"双手"）分离以扩展复杂工作流：
- 脑手解耦：专用 handler 负责工具调用，保持长程规划连贯性
- 可靠性模式：生产环境中的错误恢复和可观测性实现
- 扩展机制：通过 delegate 工具调用给专门 handler，agent 可跨越复杂工作流扩展
这与原架构文章（2026-04-11）的接口抽象一脉相承，但补充了生产落地的具体模式。
关联
- harness-engineering/overview — Harness Engineering 概览
- harness-engineering/three-scaling-dimensions — 三个 Scaling 维度
- claude-code/overview — Claude Code
- ai-ecosystem/overview — AI 生态系统
产品视角：Angela Jiang & Katelyn Lesse 访谈（2026-05-11）
来源：Claude Managed Agents 深度解析 — Anthropic
基础设施才是真正的壁垒
Anthropic 平台团队观察到的模式：大多数人以为 Harness 工程最难，但真正投入生产后撞上的是基础设施之墙——沙箱断连、内存丢失、异步处理、服务器持续运行等问题。
Managed Agents 的设计动机来自 Anthropic 内部重复造轮子的疲劳："我们构建过能自主运行的智能体产品，踩过了无数次搞定基础设施的坑，最后我们觉得：够了，别再为自己重复造轮子了。"
Harness 与模型正高度配对
几个月前，构建一个通用 Harness 然后随时切换模型是标准做法。但下一代模型正在走向不同训练路线和工具偏好。为了榨出模型能力，Harness 和模型会变成一组交付单元，而不是随便拆开的零件。
内部实验：团队为 memory 试过多套 Harness，评估结果差异极大。看起来只是"怎么请求、怎么保存、怎么让模型用工具"的细节，最后会变成输出质量的差距。
一年后的 Claude 愿景
- 极致简化：用户关心的参数只有"结果"和"预算"
- 动态自编写：Claude 自动判断该用哪个模型，如何启动子智能体
- 很多现在的创新会消失：脚手架代码、提示词工程、手动模型选择
- 智能体持续运行、不断自我重构
多智能体编排的实际模式
- Advisor Strategy：将"执行"与"建议"分离
- 对抗智能体：一个生成内容，另一个进行对抗性审核
- 蜂群（Swarm）：任务拆解成很多微小碎片再重新组合，适合找 Bug
团队 Agent 的落地形态
Anthropic 内部案例：市场同事写完文案 → 提交给法律审稿 Agent → 第一轮检查 → 足够清楚直接放行 / 拿不准进法务收件箱。
关键差异：这不是一个 Skill 能完成的——需要独立会话、认证、权限和人工介入。团队 Agent 的难点不只在模型，难在谁能看、谁能改、谁负责。
2026-06-02 更新：Anthropic 官方 Workshop 生产实践
来源：Agent 从 Demo 到生产，只差一个托管底座 — Isabella He, 2026-06-02
Anthropic Applied AI 团队成员 Isabella He 的 workshop 将 Managed Agents 的生产化路径概括为五个步骤：
- 清晰场景 — 定义 Agent 要稳定处理的一类任务。
- 给 Agent 人类会看的材料 — logs、metrics、recent deployments、diff 等上下文。
- 每次工具调用可见 — 透明度本身就是产品。
- Runbook — 先让 Agent 稳定处理一类事故，再逐步开放修复动作。
- PR 修复 — 从观察到行动的最后一步。
关键数据：Managed Agents 以 10–15× 速度将进入生产。
上下文工程 > 模型调优
"能给 Agent 的数据越多，它就越强；上下文工程是让 Agent 强大的巨大部分。" 这比微调或 prompt 工程更重要。
示例：
- SRE agent：logs、metrics、recent deployments、diff
- 销售 agent：CRM 记录、邮件线程、报价规则
- 产品 agent：用户反馈、埋点、路线图
Session 作为可运维对象
- 状态机：idle → running → rescheduling → terminated
- Hard refresh 后 session 保留
- 事件流式返回
- 后续演进：subagents、memory、dreaming、vaults、webhooks
核心架构重申：脑和手分开
- Agent（脑）：思考与决策
- Environment（手）：执行空间和容器
- Session：连接两者，事件流回用户
收益：凭证隔离、P95 TTFT 降低 超过 90%、开发者只保留最了解的部分（任务、工具和领域知识）。