重磅！Anthropic又一个平台级产品炸场:Harness难题一次性解决，把Agent宠物变成牲口

Anthropic推出平台级产品：Claude Managed Agents，开发周期从数月压缩到几天,To B业务更进一步，这是直接给了一个Harness Agent的盒子，用户只管干活就行了，随着产品发布，A厂还发布了一篇Harness（Managed Agents）工程细节文章，感觉A厂就差说在座的都是xx了，再一次遥遥领先！我们一文来说清楚

Anthropic今天正式推出Claude Managed Agents，一套可组合的API套件，专为在云端大规模构建和部署智能体而设计，目前已在Claude Platform上线公测。

架构是这个样子：

基础设施全托管，开发者只管业务逻辑

过去，构建一个可用于生产环境的智能体，开发者需要自己搭建沙箱代码执行环境、做断点续存、管理凭证、设置权限范围、实现端到端追踪。光这些基础设施工作就要耗掉数月时间，用户还没看到任何东西。

Managed Agents把这些复杂性全部接管。开发者只需定义智能体的任务、工具和安全边界，Anthropic负责在自己的基础设施上运行。内置的编排引擎会自动决定何时调用工具、如何管理上下文、如何从错误中恢复。

具体来说，Managed Agents包含以下能力：

生产级智能体运行环境，安全沙箱、身份验证和工具执行全部由平台处理。

长时任务会话，支持自主运行数小时，进度和输出在断线后依然持久保存。

多智能体协调，允许智能体启动并调度其他智能体来并行处理复杂任务，目前处于研究预览阶段，需申请访问权限。

可信治理机制，智能体访问真实系统时具备权限范围控制、身份管理和执行追踪能力。

专为Claude模型优化，任务成功率提升最高10个百分点

Managed Agents在设计上与Claude模型深度配合。开发者可以只定义目标和成功标准，由Claude自我评估并持续迭代直到达成（研究预览阶段，需申请访问权限）。同时也支持传统的提示词加响应工作流，便于开发者保持更精细的控制。

Anthropic内部测试显示，在结构化文件生成任务上，Managed Agents相比标准提示循环，任务成功率最高提升10个百分点，在难度最高的任务上提升最为明显。

会话追踪、集成分析和问题排查指引已直接内置在Claude Console中，开发者可以检视每一次工具调用、决策过程和失败原因。

多家企业已在生产环境中使用

Notion正在私测阶段将Claude集成到工作区，让团队成员可以直接在Notion Custom Agents中把任务委托给Claude。工程师用它来写代码，知识工作者用它来生成网站和演示文稿，数十个任务可以并行运行，整个团队可以协作处理输出结果。

Rakuten在产品、销售、市场、财务和HR等部门部署了企业级智能体，通过Slack和Teams接收员工指派的任务，返回电子表格、幻灯片和应用等可交付成果。每个专项智能体的部署周期在一周以内。

Asana基于Managed Agents构建了AI Teammates，让AI智能体在Asana项目中与人类并肩工作，承接任务、起草交付物。团队表示，使用Managed Agents后，高级功能的交付速度远快于原来的节奏。

Vibecode将Managed Agents作为默认集成方案，帮助用户从一句提示词直接到部署上线的应用，用户启动同等基础设施的速度至少快了10倍。

Sentry将旗下调试智能体Seer与Claude驱动的智能体配合使用，后者负责编写补丁并发起Pull Request，让开发者从发现bug到得到可审查的修复方案一气呵成。整个集成在Managed Agents上只用了几周时间完成上线。

Harness 工程细节：把大脑和双手分开

Anthropic 同步发布了一篇工程博客，解释了 Managed Agents 背后的架构设计思路。

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

核心问题是：如何为还没有被想到的程序设计一个系统。几十年前，操作系统通过把硬件虚拟化为抽象层（进程、文件）解决了这个问题，这些抽象足够通用，能支撑那些当时根本不存在的程序。read() 命令不管底下是 1970 年代的磁盘还是现代 SSD，都能正常工作。

Managed Agents 遵循同样的模式，把 Agent 的组成要素虚拟化为三个部分：会话（session，记录所有发生过事件的只增日志）、控制器（harness，调用 Claude 并把工具请求路由到相关基础设施的循环）、沙箱（sandbox，Claude 运行代码和编辑文件的执行环境）。三个部分各自可以独立替换，互不干扰。

为什么不能把所有东西放在一个容器里

最初的设计是把所有 Agent 组件放在同一个容器里，会话、控制器、沙箱共享同一个环境。这样做有一定好处，比如文件编辑直接走系统调用，也没有服务边界要设计。

但这种耦合带来了一个经典的基础设施问题：容器变成了一只宠物。用宠物对牲口的比喻来说，宠物是有名字、需要精心照料、不能失去的个体，牲口则是可以互换的。在这个场景里，服务器就是那只宠物，容器一挂，会话就丢了；容器无响应，就得花时间去哄它恢复。

调试也成了难题。唯一的观察窗口是 WebSocket 事件流，但它没法告诉你故障发生在哪里。控制器的 bug、事件流的丢包、容器下线，表现出来全都一样。要排查根因，工程师得进到容器里开 shell，但那个容器里往往还有用户数据，这条路实际上走不通。

另一个问题是，控制器假设 Claude 操作的资源和它自己在同一个容器里。当客户要求把 Claude 接入自己的私有云时，要么得把他们的网络和 Anthropic 的网络打通，要么在他们自己的环境里跑 Anthropic 的控制器。一个埋在控制器里的假设，变成了连接不同基础设施时的障碍。

把大脑和双手拆开

解决方案是把大脑（Claude 和它的控制器）、双手（执行操作的沙箱和工具）、会话（事件日志）三者解耦，每个部分变成一个接口，对其他部分的假设尽可能少，各自可以独立出故障或替换。

控制器离开容器之后，调用沙箱的方式和调用其他任何工具一样：execute(name, input) → string。容器变成了牲口。容器挂了，控制器把失败当成工具调用错误处理，交回给 Claude。如果 Claude 决定重试，新的容器可以用标准配方重新初始化：provision({resources})。不再需要把挂掉的容器哄回来。

控制器本身也变成了牲口。因为会话日志在控制器外面，控制器崩溃后不需要保留任何状态。新的控制器用 wake(sessionId) 重启，用 getSession(id) 取回事件日志，从最后一个事件继续。控制器在运行过程中通过 emitEvent(id, event) 持续写入会话，保持事件的持久记录。

安全边界

在耦合设计里，Claude 生成的不受信任代码和凭证跑在同一个容器里，一次提示注入攻击只需要说服 Claude 读取自己的环境变量，拿到 token 之后就能开出不受限制的新会话并分配任务出去。

结构性修复是确保 token 永远无法从 Claude 生成代码运行的沙箱里访问到。具体通过两种方式实现：凭证可以和资源绑定，也可以放在沙箱外部的保险库里。以 Git 为例，在沙箱初始化时用仓库访问 token 克隆仓库，并接入本地 git remote，沙箱内部 git push 和 pull 正常工作，但 Agent 自始至终都不会碰到 token 本身。自定义工具方面，支持 MCP，OAuth token 存在安全保险库里，Claude 通过专用代理调用 MCP 工具，代理拿到关联会话的 token 后，自己去保险库取对应凭证再调用外部服务，控制器对任何凭证都不知情。

会话不是 Claude 的上下文窗口

长周期任务经常超出 Claude 上下文窗口的长度。常见的处理方式——压缩摘要、写入文件、裁剪旧内容，都涉及不可逆的决策，很难预判未来的轮次会用到哪些 token。

Managed Agents 里，会话日志充当了一个活在上下文窗口外部的上下文对象。接口 getEvents() 允许大脑通过选取事件流的位置切片来查询上下文，可以从上次停止的地方接着读，也可以倒回某个时间点之前几个事件，或者在执行某个操作之前重读相关上下文。

取回的事件在传入 Claude 上下文窗口之前，还可以在控制器里做任意变换——包括上下文整理、提高提示缓存命中率等。具体需要什么样的上下文工程，随着模型不同会有变化，Managed Agents 的设计选择是把这个决策权留给控制器，只保证会话本身是持久的、可查询的。

一个大脑接多双手，多个大脑也可以

大脑和双手解耦之后，客户的私有云问题自然消失了，控制器不再假设资源和自己在一起，接入任意位置的资源都可以。

性能上也有收获。原来把大脑放在容器里，意味着多少个大脑就要准备多少个容器，每个会话都要等容器启动完才能开始推理，即使这个会话根本不需要沙箱，也要先克隆仓库、启动进程、拉取待处理事件。

解耦之后，容器只在大脑真正需要的时候才通过工具调用来启动，不需要沙箱的会话不用等。推理可以在编排层拉取会话日志里的待处理事件后立刻开始。按这套架构，p50 首 token 延迟下降了约 60%，p95 首 token 延迟下降超过 90%。扩展到多个大脑，只需启动多个无状态控制器，按需连接双手。

一个大脑接多双手的能力同样重要。实际上，这要求 Claude 同时感知多个执行环境并决定把任务发到哪里，认知负担比在单一 shell 里操作要重得多。早期模型能力不足，只能用单容器。随着模型智能提升，单容器反而成了瓶颈，那个容器挂了，大脑正在操作的所有双手的状态都会丢失。

解耦之后，每只手都成为一个工具：execute(name, input) → string，一个名字和输入进去，返回一个字符串。这个接口支持任意自定义工具、任意 MCP 服务器以及 Anthropic 自己的工具。控制器不需要知道沙箱是一个容器、一部手机还是一个 Pokemon 模拟器。因为没有哪只手和哪个大脑耦合，大脑之间也可以互相传递双手。

写在最后

Managed Agents 的设计目标是一个能容纳未来控制器、沙箱或其他组件的系统，不对将来具体需要什么样的控制器表态，而是提供一套通用接口，让各种不同的控制器都能运行。比如 Claude Code 是一个广泛使用的优秀控制器，针对特定任务设计的控制器在窄领域也表现出色，Managed Agents 可以容纳所有这些，随着 Claude 智能的提升持续匹配。

在接口设计上，Anthropic 的判断是：Claude 需要能够操作状态（会话）、执行计算（沙箱），也需要能够扩展到多个大脑和多双手。接口按照能在长时间跨度内可靠、安全运行来设计，但对大脑和双手的数量与位置不作任何假设。

定价与使用方式

Managed Agents按使用量计费。Claude Platform标准token费率照常收取，另外每活跃会话小时收费0.08美元。完整定价细节可查阅官方文档。

目前Managed Agents已在Claude Platform正式上线。开发者可以通过阅读文档、进入Claude Console或使用新版CLI来部署第一个智能体。

也可以使用最新版Claude Code，内置了claude-api技能，直接向Claude说start onboarding for managed agents in Claude API即可开始上手。

文档地址：

https://platform.claude.com/docs/en/managed-agents/overview

控制台入口：

https://platform.claude.com/login?returnTo=%2Fworkspaces%2Fdefault%2Fagent-quickstart

source：

https://claude.com/blog/claude-managed-agents

文章来自于微信公众号 "AI寒武纪"，作者 "AI寒武纪"