把AI变成个人执行系统，Claude最新Managed Agents实践手册

原文标题：Launching Claude Managed Agents
原文作者：Lance Martin
编译：Peggy，BlockBeats

编者按：本文介绍了 Claude 推出的 Managed Agents。它提供了一个更接近未来的软件形态：智能体不再是一次性响应请求的接口，而是可以被配置、部署、调度并长期运行的执行系统。

通过将「智能」（模型与运行框架）、「执行」（工具与沙箱）与「过程」（会话与日志）彻底解耦，Claude Managed Agents 将 agent 从「代码里的逻辑」转变为一种独立的基础设施单元。这种设计不仅提升了系统在长周期任务中的稳定性与安全性，也使 agent 能够随着模型能力的演进而持续扩展，而不被既有框架所束缚。

在这一框架下，常见的使用模式也随之发生变化：从事件触发、定时运行，到「触发即交付」的自动执行，再到跨天甚至跨周的复杂任务，agent 开始真正具备「持续工作」的能力。这意味着，AI 的价值不再只体现在单次回答的质量上，而在于其能否在时间维度上积累与复利。

如果说过去的 API 让开发者「调用智能」，那么 Managed Agents 正在尝试回答另一个问题：如何让智能成为可以被托管、调度并持续运转的系统。在这一意义上，agent 不再只是工具，而更接近一种新的计算原语。

以下为原文：

TL;DR

Claude Managed Agents 是一套预构建、可配置的智能体运行框架（agent harness），运行在托管基础设施之上。你只需将一个智能体定义为模板——包括工具、技能、文件/代码仓库等，其余的运行框架和基础设施都由系统提供。该系统旨在跟上 Claude 快速增长的智能水平，并支持长周期任务。

相关链接如下：

·Claude 博客：使用模式与客户案例

·工程博客：Claude Managed Agents 的设计

·文档：上手指南、快速开始、CLI 与 SDK 概览

Claude Managed Agents

为什么需要 Claude Managed Agents

Claude 的 messages API 本质上是直接与模型交互的入口：输入消息，返回内容块。基于 messages API 构建的智能体，需要依赖一个「运行框架」（harness）来完成工具调用的路由、上下文管理等工作。但这会带来几个问题：

1、运行框架需要不断跟上 Claude 的能力演进
我最近写过一篇博客，介绍如何基于 Claude API 的底层能力来构建智能体，用于处理工具编排和上下文管理。但问题在于，agent 的运行框架通常隐含了一些关于「Claude 做不到什么」的假设。随着 Claude 能力提升，这些假设很快会过时，甚至反过来成为性能瓶颈。因此，运行框架必须持续更新，才能跟上 Claude 的进化速度。

2、Claude 的任务周期正在变得更长
Claude 能处理的任务时间跨度正呈指数级增长，在 METR 基准测试中，已经超过 10 小时的人类工作量。这对智能体的底层基础设施提出了更高要求：必须具备安全性、在长时间运行中的稳定性（应对各种基础设施故障），以及可扩展能力（例如支持多个智能体团队同时运行）。

为什么这些问题重要

解决上述挑战至关重要，因为我们预计，未来的 Claude 将能够在数天、数周甚至数月的时间尺度上，持续运行并处理人类最复杂的问题。

Claude Agent SDK 是这一方向的第一步，它提供了一个通用、易用的智能体运行框架。而 Claude Managed Agents 则是进一步演进：在此基础上，提供了完整的运行框架 + 托管基础设施，专门用于支持在长时间跨度下安全、可靠地执行任务。

如何开始使用

一个简单的入门方式，是使用我们开源的 claude-api skill，它可以在 Claude Code 中开箱即用。你只需安装最新版 Claude Code，然后运行以下子命令，即可完成 Claude Managed Agents 的初始化配置。

我个人对「skills」这种接入新功能的方式非常看好，也在实际中大量使用这个 skill。

此外，你也可以参考我们的文档，通过 SDK 或 CLI 快速上手，并在 Claude Console 中对智能体进行原型开发。

使用场景

你可以在 Claude 官方博客中看到许多有意思的案例。结合这些案例以及我自己的实践，我观察到一些常见的使用模式：

1、事件触发（Event-triggered）
由某个服务触发 Managed Agent 执行任务。
例如，当系统检测到一个 bug 时，会自动调用一个托管智能体来编写修复补丁并提交 PR。在「问题被标记」到「执行修复」之间，不需要人工介入。

2、定时执行（Scheduled）
为 Managed Agent 设置定时任务。
例如，我和很多人都会用这种方式生成每日简报（比如 X 平台或 GitHub 的动态汇总，或者一个智能体团队的工作进展）。下面是我日常使用的一个 X 活动每日简报示例。

3、一次触发、无需跟进（Fire-and-forget）
由人类触发 Managed Agent 执行任务，但过程中无需持续参与。例如，通过 Slack 或 Teams 给托管智能体分配任务，它会自动完成并返回结果（如表格、幻灯片，甚至应用程序）。

4、长周期任务（Long-horizon tasks）
长时间运行的任务，是我认为 Managed Agents 特别有价值的场景之一。
我曾基于 Andrej Karpathy's auto-research repo 做过一些实验，探索不同的应用方式。比如，我最近将 _chenglou's pretext library 作为输入，让一个 Managed Agent 去研究如何将其应用到我们的工程博客内容中。

核心概念

在上手过程中，有三个核心概念需要理解：

1、Agent（智能体）
一个带版本管理的配置，定义了智能体的「身份」：包括模型、system prompt、工具、技能、MCP 服务器等。创建一次后，可以通过 ID 反复调用。

2、Environment（环境）
一个模板，用于描述为智能体工具运行所提供的沙箱环境（例如运行时类型、网络策略、依赖包配置等）。

3、Session（会话）
一次有状态的运行实例，基于预先创建好的 agent 配置和 environment 启动。它会从环境模板中生成一个全新的沙箱，挂载本次运行所需的资源（如文件、GitHub 仓库），并将认证信息安全存储在密钥库中（如 MCP 凭证）。

可以这样理解：

·Agent = 配置本身

·Environment = 智能体运行所需的沙箱模板

·Session = 一次具体执行过程

一个 Agent 可以对应多个 Session。

使用方式

具体可参考文档。整体使用分为两类：

1、SDK（面向代码）
在应用中引入 SDK，在运行时驱动 session。当前已有 6 种语言支持 Managed Agents：Python、TypeScript、Java、Go、Ruby、PHP。

2、CLI（面向终端）
通过命令行操作所有 API 资源，包括 agents、environments、sessions、vaults、skills、files 等，每一类资源都有对应子命令。

常见实践模式：
通常使用 CLI 完成配置与初始化，用 SDK 处理运行时逻辑。
Agent 模板是持久化的——你可以创建一个模板（例如用 YAML 定义模型、system prompt、工具、MCP 服务器、skills），存储在 Git 中，并通过 CLI 在部署流程中应用。

工作原理

我和 @mc_anthropic、@gcemaj、@jkeatn 一起写过一篇 Anthropic 的工程博客，详细介绍了 Claude Managed Agents 的构建过程。文章中一个重要结论是：让智能体能够随着 Claude 智能水平扩展，本质上是一个「基础设施问题」，而不仅仅是运行框架（harness）设计问题。

也就是说，真正的挑战不在于「怎么写一个更聪明的 agent」，而在于如何构建一套能够长期稳定运行、可扩展、可演进的系统，让 agent 能够承载越来越复杂、越来越长期的任务。

基于这一思路，我们并没有去设计一种固定的 agent 运行框架（harness），因为我们预期它会持续演进。相反，我们将系统中的几个关键部分进行了「解耦」：

「大脑」（Claude 及其运行框架）

「双手」（执行具体操作的沙箱与工具）

「会话」（记录执行过程的事件日志）

这三者被设计为相互独立的接口，对彼此的假设尽可能少。每一个部分都可以单独失败、单独替换，而不会影响整体系统。

我们在文中也分享了，这种架构如何带来更高的可靠性、安全性与灵活性——同时也为未来接入新的运行框架、沙箱或承载会话的基础设施预留了空间。

结语

我对那些正在探索多智能体协同（multi-agent orchestration）或长周期任务的项目感到非常兴奋。过去我一直感到困扰的一点是：agent 的运行框架很难跟上模型能力的进化。

而 Claude Managed Agents 的意义在于，它替你处理了运行框架与基础设施层的问题，使你可以把精力放在更高一层——把「agent」本身当作 Claude API 中的一种新的基础原语，在其之上进行更多探索与构建。

[原文链接]