“开发 Agent 的苦日子终于结束了！”

就在刚刚，Anthropic 发布了 一款让开发者都“破大防”的工具——Claude Managed Agents。

只需要告诉它干啥、能用啥工具、边界在哪，剩下的难题——沙盒代码执行、检查点、凭证管理、权限范围和端到端追踪等，都被 Managed Agents 一手包办了！

在X.上的网友直言：“之前：20%编写业务逻辑，80%构建基础设施；现在：Anthropic 负责这 80%”

这么牛的 Agent 是如何做到的，Claude官方发布了技术细节的博客，

我们一起来拆解一下Claude Agent 的背后：

传统 Agent Harness，越来越“拖后腿”

Anthropic 自己之前做过一系列 Agent 的探索，比如2026年3月发布的 Harness Design for Long-Running Apps 和2025年9月发布的Effective Context Engineering for AI Agents。

随着模型能力的提升，他们发现了一个问题：旧的假设会过时，因此需要不断重构。

举个经典例子：在之前的研究中，他们发现 Claude Sonnet 4.5 在感知到情境极限接近时会提前结束任务——这种行为有时被称为“情境焦虑”。

为了解决这个问题，工程师们加了各种上下文重置。

结果呢？当更强大的 Claude Opus 4.5 上线后，这些动作就完全没必要了，反而成了“累赘”。

更严重的是，随着模型快速迭代（从 Sonnet 到 Opus，再到未来更强版本），harness 里积累的假设会越来越“过时”。

每次模型升级，都要大改甚至重写整个控制逻辑。这就像给一辆不断升级引擎的汽车，配了一套超级老套的系统——模型越聪明，系统越容易出问题。

Anthropic 的解决思路很清晰：设计一套稳定的接口，让系统经得起模型迭代。

这也意味着解决计算机领域的一个老问题：如何为“ 尚未被想到的程序 ”设计系统。

几十年前，操作系统通过将硬件虚拟化为抽象—— 进程、文件 ——来解决这个问题，这些抽象足够通用，适合当时还不存在的程序。抽象概念比硬件更持久。read（） 命令对访问的是 1970 年代的磁盘包还是现代 SSD 是中立的。顶部的抽象保持稳定，而底层实现则自由变化。

核心技术细节拆解

不要养宠物

在早期的版本里，Anthropic 把 Agent 的所有组件——Session（会话日志）、Harness（大脑控制逻辑）、Sandbox（执行沙箱）——全部塞进同一个容器里。

这种方式有很大优点：可以直接通过系统调用编辑文件、调试也很简单。

但问题也随之而来，他们领养了一只宠物。

• 每个容器都是一个有名字、需要精心照料的“宠物”。
• 一旦容器挂掉，整个记忆就丢失了。
• 调试需要直接进容器，很容易暴露用户数据。

而且如果想让 Claude 连接企业内部 VPC 等外部设施？要么做复杂的网络打通，要么把整个 harness 扔到客户环境里跑。

当客户要求将 Claude 连接到他们的虚拟专用云时，他们要么将自己的网络与我们的进行对等连接，要么在自己的环境中运行我们的harness。当我们想将harness连接到不同基础设施时，一个内置的假设成了问题。

Anthropic 把这个问题总结为：不要养宠物，要养牛。

牛是可以被替换的——一头出现问题，马上拉另一头顶上，不影响整体。

备注：宠物与牛的历史及如何正确使用类比 |云尺度 --- The History of Pets vs Cattle and How to Use the Analogy Properly | Cloudscaling

将大脑与手部分离

Anthropic 达成的解决方案是将他们认为的“脑”与“手”以及“会话”分离。

每一个都成为一个对其他部分几乎没有假设的接口，并且每一个都可以失败或被独立替换。

他们把 Agent 拆成三个独立部分：

• Brain（大脑）：Claude 模型 + Harness（控制逻辑）
• Hands（双手）：执行环境的沙箱、工具、外部服务
• Session（记忆）：持久化的事件日志（会话历史）

其中的关键操作是：让 Harness 离开容器。

它调用容器的方式和其他工具一样： execute(name, input) → string

如果 Harness 崩溃了，直接用 wake(sessionId) 重启，从 getSession(id) 拉取事件日志，继续从上一个事件往下执行。通过 emitEvent(id, event) 把新事件持久化写入 Session。

同时，Harness 和容器分离，也使容器变成了牛，把容器当作一个普通的工具调用：

如果容器坏了， Harness 会将故障识别为工具调用错误，并传回给 Claude。

如果 Claude 决定重试，可以重新初始化一个新的容器：provision（{resources}）。不需要再人工“抢救宠物”。

总的来说：

大脑只负责思考和决策，双手可以随便换，记忆在外面安全保存。

“脑手分离”之后

安全性提升

在他们旧的架构里，凭证（token）和用户代码跑在同一个容器，prompt injection （提示注入）只需说服 Claude 读取自己的环境——攻击者就可以重新生成无限制的会话。

随着 Claude 越来越智能，原有的缓解方式（Narrow scoping）很难再保证安全性。

在将“大脑”与“手”分离之后，他们采用了两种模式：

1. Bundled Auth（捆绑认证）：认证信息可以与资源捆绑在一起，也可以存放在沙箱外的保险库中。比如 Git 操作，在沙箱初始化时就把仓库 token 写进本地 git remote，后面 push/pull 都不再需要暴露 token。
2. Vault + Proxy（保险库 + 代理）：自定义工具（MCP）的 OAuth token 存在安全 vault 里。Claude 通过专用代理调用 MCP 工具，代理负责取凭证，Harness 看不到真实 token。

上下文管理

长期任务往往超过 Claude 的上下文窗口长度，而在以前的方案里（压缩、记忆工具、裁剪）很容易做出不可逆决策，从而导致信息丢失。

压缩：当对话即将接近上下文窗口上限时，允许 Claude 保存上下文窗口的摘要。

记忆工具：允许 agent 把重要信息主动写到外部持久化存储，后面需要时再通过工具检索/读取。

裁剪：直接从消息历史中删除旧消息，或只保留最近几轮对话。

而现在，Session 本身就是一个Claude上下文窗口之外的上下文对象。

Harness 可以通过 getEvents() 接口灵活查询事件流的任意位置切片，从上次停止阅读的地方重新拾起，倒带某个特定时刻前的几个事件以了解前奏，或在特定动作前重读上下文。

Session 只负责持久化和耐久性，具体的上下文工程（compaction、prompt cache 优化等）由 Harness 灵活处理。

因为我们无法预测未来模型中需要哪些具体的上下文工程，但这样即使未来模型上下文窗口变得极大，或者出现全新上下文管理技术，系统也能轻松适配。

多脑多手

以前每个大脑 都要带一个容器，启动延迟（TTFT）很高。

当我们最初把大脑放进一个容器时，意味着许多大脑需要同样数量的容器。对于每个大脑，在该容器被配置之前，无法进行推理;每次会话都预付了全部容器设置费用。每个会话，即使是那些永远不会接触沙盒的会话，都必须克隆仓库、启动进程、从服务器获取待处理事件。

现在大脑与手部分离意味着容器仅在需要时通过工具调用 (execute(name, input) → string)可以瞬间启动，只在真正需要执行时才去连接到手上。

结果：p50 TTFT 下降约 60%，p95 下降超过 90%

将大脑与手分离后，每只手都是一个 execute(name, input) → string 的工具。

一个名字和输入输入进入，返回一个字符串。该界面支持任何自定义工具、任何 MCP 服务器以及我们自己的工具。Harness 无法判断沙盒是容器、手机还是宝可梦模拟器。而且因为没有手与大脑相连，大脑可以互相传递手。

真正的范式转变

Managed Agents 并不是一个具体的 Agent 框架，而是一个“meta-harness”。

正如X上的网友所言：2025 年：人人都在聊 Agent；2026 年：Agent 变成了云服务。这才是真正的范式转变。”

各位评论区的大佬们体验过 Claude Managed Agents 了吗？双手被真正解放了吗？

参考链接：
https://www.anthropic.com/engineering/managed-agents