第 21 章：Managed Agents

本章导读

核心问题：如何托管 Agent，使 Brain、Hands、Session 解耦。

关键词：Managed Agents、Brain、Hands、Worker、Session Event Log、Recovery

学习产出：设计托管式 CI 分析 Agent 的 Brain、Worker 和 Session 恢复机制。

1. 本章要解决什么问题

上一章讨论了 Agent Runtime。

这一章进一步讨论 Managed Agents。

Managed Agents 关注的问题是：

当 Agent 需要长时间运行、访问外部资源、处理大量任务、支持多用户和多环境时，如何托管、调度、隔离和扩展？

普通 Agent Runtime 更像应用内部能力。

Managed Agents 更像平台级托管服务。

它需要解决：

多个 Agent 并发运行；
多个 Sandbox 动态创建；
长任务恢复；
Brain 与 Hands 解耦；
Session 持久化；
资源配额；
安全隔离；
任务调度；
生命周期管理；
多租户支持。

本章核心观点是：

Managed Agents 是把 Agent 作为可托管、可调度、可隔离、可恢复的生产级计算单元来管理。

2. 对应 Anthropic 文章

本章主要对应：

Scaling Managed Agents: Decoupling the brain from the hands

Anthropic 的核心设计是：

Brain
Hands
Session

三者解耦。

其中最重要的思想是：

Harness、Sandbox 和 Session 都应通过稳定接口连接，而不是互相绑定。

这种设计使得：

Harness 崩溃可以恢复；
Sandbox 崩溃可以重建；
Session 事件仍然保留；
多个 Brain 可以共享或动态请求 Hands；
资源可以按需创建，而不是每次任务都提前创建完整容器。

3. Brain、Hands、Session

3.1 Brain

Brain 是智能决策部分。

包括：

LLM；
Harness；
Planner；
Context Builder；
Decision Loop。

Brain 负责回答：

下一步应该做什么？
需要调用什么工具？
是否完成？
是否需要恢复？

Brain 不应该直接绑定某个容器。

3.2 Hands

Hands 是执行部分。

包括：

Sandbox；
文件系统；
命令执行；
浏览器；
MCP 工具；
企业系统连接器。

Hands 负责回答：

如何执行动作？
如何访问环境？
如何返回观察结果？

Hands 可以按需创建，用完销毁。

3.3 Session

Session 是持久化事件流。

它记录：

用户输入；
模型输出；
工具调用；
工具结果；
状态变更；
错误；
Checkpoint。

Session 是恢复的基础。

如果 Brain 崩溃，新 Brain 可以读取 Session 继续。

如果 Hands 崩溃，新 Hands 可以根据 Session 和 Workspace 重新初始化。

4. 为什么要解耦 Brain 与 Hands

4.1 降低启动延迟

如果每个 Agent 启动都必须先创建完整容器，用户会等待很久。

解耦后：

Brain 可以先开始推理
只有需要执行命令时才创建 Hands

这降低 Time-to-first-token。

4.2 提升弹性

容器可能失败。

如果 Harness 在容器里，容器失败会导致整个 Agent 失败。

解耦后，容器只是工具执行环境。

失败时可以返回 tool error，Brain 决定是否重试或重新 provision。

4.3 支持客户环境

企业可能希望 Hands 运行在自己的 VPC 或内网。

Brain 可以在平台侧运行，Hands 在客户环境运行。

二者通过标准接口通信。

4.4 支持多种 Harness

不同任务可能需要不同 Harness。

例如：

Coding Harness；
Research Harness；
Incident Harness；
Data Analysis Harness。

Managed Agents 不应绑定某一个 Harness，而应提供通用接口。

5. Managed Agent 的核心能力

5.1 Lifecycle Management

管理 Agent 生命周期：

CREATE
START
PAUSE
RESUME
STOP
CANCEL
COMPLETE
FAIL

5.2 Worker Pool

Hands 可以由 Worker Pool 承载。

Worker 可以是：

容器；
VM；
Kubernetes Pod；
浏览器实例；
本地进程；
远程执行器。

5.3 Resource Quota

每个 Agent 应有资源配额：

CPU；
Memory；
Disk；
Network；
Tool calls；
Token；
Wall-clock time；
并发数。

5.4 Isolation

隔离包括：

租户隔离；
项目隔离；
文件系统隔离；
网络隔离；
权限隔离；
Secret 隔离。

5.5 Scheduling

调度器决定：

哪个任务先运行；
分配哪个 Worker；
是否允许并行；
超时如何处理；
失败是否重试。

5.6 Observability

需要监控：

Agent 状态；
任务耗时；
token 消耗；
工具调用；
Worker 资源；
失败原因；
用户等待时间；
恢复次数。

6. 架构图 / 流程图

图 21-1 Managed Agents：Brain / Hands / Session 这张图展示 Brain、Hands Worker 和 Session Event Log 如何解耦并支持恢复。 Mermaid 源文件

6.1 Managed Agents 架构

图 21-2 Managed Agents 架构 Mermaid 源文件

6.2 Brain / Hands 解耦

图 21-3 Brain / Hands 解耦 Mermaid 源文件

6.3 生命周期

图 21-4 生命周期 Mermaid 源文件

7. Java / Spring Boot 落地方案

7.1 ManagedAgent

public record ManagedAgent(
    String agentId,
    String sessionId,
    ManagedAgentState state,
    AgentDefinition definition,
    ResourceQuota quota,
    Instant createdAt,
    Instant updatedAt
) {}

7.2 ManagedAgentState

public enum ManagedAgentState {
    CREATED,
    RUNNING,
    PAUSED,
    RESUMING,
    COMPLETED,
    FAILED,
    CANCELLED
}

7.3 BrainService

public interface BrainService {
    BrainDecision next(ManagedAgent agent, SessionSnapshot session);
}

7.4 HandsWorker

public interface HandsWorker {
    WorkerHandle provision(ProvisionRequest request);
    ToolResult execute(WorkerHandle handle, ToolCall call);
    void destroy(WorkerHandle handle);
}

7.5 WorkerPool

public interface WorkerPool {
    WorkerHandle acquire(WorkerRequirement requirement);
    void release(WorkerHandle handle);
}

7.6 AgentLifecycleManager

public interface AgentLifecycleManager {
    ManagedAgent create(AgentTask task);
    void start(String agentId);
    void pause(String agentId);
    void resume(String agentId);
    void cancel(String agentId);
}

7.7 ResourceQuota

public record ResourceQuota(
    int maxToolCalls,
    int maxTokens,
    Duration maxRuntime,
    int maxConcurrentWorkers,
    long maxDiskMb,
    long maxMemoryMb
) {}

8. 企业案例：托管 Coding Agent

场景：企业希望在平台中托管 Coding Agent。

设计：

Brain Service：运行 Coding Harness
Session Service：保存事件日志
Worker Pool：按需创建 Git workspace 容器
MCP Layer：连接 GitLab、CI、Jira
Policy：写操作需要审批
Quota：每个任务最多 30 分钟、100 次工具调用

流程：

用户提交“分析 CI 失败”
  ↓
Brain 先读取事件和上下文
  ↓
需要读取仓库时 provision Git Worker
  ↓
Worker clone repo 并执行只读工具
  ↓
结果返回 Brain
  ↓
Session 持久化所有事件
  ↓
任务完成后销毁 Worker

9. 常见误区

9.1 Brain 和 Hands 绑死

这会导致资源浪费、恢复困难和部署不灵活。

9.2 Session 存在 Harness 内存中

Session 必须外部持久化。

9.3 没有资源配额

Managed Agents 如果没有 quota，很容易成本失控。

9.4 Worker 不隔离

执行环境必须隔离，尤其是企业代码和数据。

9.5 平台绑定单一 Harness

Managed Agent 平台应支持多种 Harness。

10. 贯穿案例：CI 失败分析 Agent

如果 CI 失败分析 Agent 作为企业平台能力托管，就需要 Managed Agents 架构。

可以把它拆成：

Brain：运行 CI Failure Analysis Harness，负责推理和决策
Hands：按需创建 Git / CI Worker，读取日志、Diff、代码片段
Session：保存任务事件、工具调用、报告和 Checkpoint

对于 build #4312，Brain 可以先读取 CI 摘要并判断是否需要仓库访问。只有当需要读取 OrderStateMachine.java 时，才 provision 一个 Git Worker。

如果 Worker 崩溃，Brain 收到工具错误，可以重新 provision；如果 Brain 崩溃，新 Brain 可以通过 Session Event Log 恢复任务。

这个案例体现了 Managed Agents 的核心价值：Brain、Hands、Session 解耦，让 Agent 可以被安全、弹性、可恢复地托管。

11. 本章小结

本章讨论 Managed Agents。

核心结论：

Managed Agents 把 Agent 当成可托管计算单元来管理。
Brain、Hands、Session 解耦是扩展性和恢复能力的关键。
Hands 应按需 provision，并作为可失败、可重建资源处理。
Session 应作为外部 durable event log。
企业托管平台必须提供生命周期、调度、隔离、配额和观测能力。

一句话总结：

Managed Agents 的核心不是让 Agent 更聪明，而是让 Agent 能在生产环境中被安全、可靠、弹性地托管。

12. 实践任务

任务 1：设计 Brain / Hands 接口

定义 BrainService、HandsWorker 和 SessionService。

任务 2：设计 WorkerPool

说明 Worker 如何创建、复用、销毁和隔离。

任务 3：设计 ResourceQuota

为 Coding Agent、Research Agent、Review Agent 分别设置资源配额。

任务 4：恢复演练

模拟 Worker 崩溃和 Brain 崩溃，说明如何通过 Session 恢复任务。