SandBase Managed Agents：开源 CMA 兼容 Agent 运行时

先说结论： SandBase Managed Agents 是 Apache-2.0 开源的本地优先 Agent 运行时。兼容 CMA /v1 API（直接拿 Anthropic SDK 指向 localhost 就能用），支持任意模型（OpenAI、Ollama、vLLM），SQLite 存所有状态，多种沙箱后端可选。一行命令启动：npx managed-agents init && npx managed-agents start。

为什么做这个

搞过 AI Agent 上生产的人都知道有多痛苦：session 状态随时可能丢，沙箱隔离基本靠祈祷，权限管控更是一塌糊涂。最后你花了大量时间搞基础设施，Agent 本身反而没时间打磨。

Anthropic 的 Claude Managed Agents 用托管服务解决了这些问题——但代价是只能用 Claude、数据过 Anthropic 的云、按 token + 运行时收费。

SandBase Managed Agents 走另一条路：相同的架构理念（brain/hands/session 解耦），但开源、本地优先、模型无关。你在自己的机器上跑，数据不出内网。

60 秒跑起来

npx managed-agents init && npx managed-agents start

搞定。你现在有了：

localhost:3000 上的 CMA 兼容 API + Web 控制台
SQLite 数据库存着 agents、sessions、memory、凭证保险箱

不需要 Docker、不需要 Redis、不需要 Postgres。Node.js 22+ 和一个模型 API key 就够了。

SandBase Managed Agents GitHub 仓库 sandbaseai/managed-agents——Apache-2.0 开源，本地优先，CMA 兼容 Agent 运行时。

架构

层级	组件	职责
API 层	`/v1` REST + SSE	CMA 兼容接口，可恢复流式传输
大脑层	Loop Engine	模型交互、工具编排、记忆
执行层	Sandbox Backend	代码执行、文件 I/O、进程管理
状态层	SQLite Store	Agents、Sessions、环境、文件、技能
配置层	YAML 定义	Agent 规格、权限、MCP 工具集
UI 层	Console 仪表盘	Session 监控、回放、调试

所有状态存 SQLite，零外部依赖（除了模型供应商）。

核心能力

沙箱后端：按需选隔离级别

后端	隔离性	适用场景
本地进程	无（宿主机执行）	开发、原型
Docker	每 session 独立容器	生产、资源限制
Kubernetes	kubectl exec/cp	企业集群
Worker Queue	分布式执行	多节点扩展

模型无关：想用啥用啥

model:
  provider: openai
  api_key: ${OPENAI_API_KEY}

OpenAI、Anthropic、Ollama、vLLM——只要兼容 chat completions 格式的都行。Agent 定义里指定具体模型 ID（gpt-4o、claude-sonnet-4、qwen2.5:72b），workspace 配置只管怎么连到模型服务。

CMA API 兼容

/v1 接口跟 Claude Managed Agents 线协议兼容。已有的 Anthropic SDK 代码改一行就能跑：

import Anthropic from '@anthropic-ai/sdk';

const client = new Anthropic({
  apiKey: process.env.MANAGED_AGENTS_API_KEY ?? 'local-dev-key',
  baseURL: 'http://127.0.0.1:3000',
});

const session = await client.beta.sessions.create({
  agent: 'agent_...',
  environment_id: 'env_...',
});

零成本迁移。

Console 控制台

内置 Web 控制台：

实时 session 监控（可恢复 SSE）
Session 回放，排查 Agent 循环问题
Agent 配置管理
凭证保险箱 UI
Memory 和文件浏览器

TypeScript SDK

import { ManagedAgentsClient } from 'managed-agents/sdk';

const client = new ManagedAgentsClient({
  baseUrl: 'http://127.0.0.1:3000',
});

const session = await client.sessions.create({
  agent: 'agent_...',
  environment_id: 'env_...',
});

for await (const event of client.sessions.chat(session.id, 'Hello')) {
  if (event.type === 'agent.message_chunk') {
    process.stdout.write(event.delta ?? '');
  }
}

Agent 定义（YAML）

# agents/incident-commander.yaml
name: Incident commander
description: 分流告警并协调响应。
model: gpt-4o
system: |-
  你是一个 on-call 事件指挥官。
mcp_servers:
  - name: sentry
    type: url
    url: https://mcp.sentry.dev/mcp
tools:
  - type: agent_toolset_20260401
    default_config:
      permission_policy: { type: always_ask }
  - type: mcp_toolset
    mcp_server_name: sentry

CLI

managed-agents init                  # 初始化工作空间
managed-agents start                 # 启动运行时 + 控制台
managed-agents list                  # 列出 agents
managed-agents reload                # 热重载 agent 定义
managed-agents chat <agent-id>       # 交互式对话
managed-agents template list         # 浏览模板

横向对比

	SandBase Managed Agents	Claude Managed Agents	自己造轮子
协议	Apache-2.0	私有	无
部署	自托管，本地优先	Anthropic 云	自托管
模型	任意	仅 Claude	任意
沙箱	本地/Docker/K8s/Worker Queue	云/自托管	自己搞
状态	SQLite（零配置）	Anthropic 托管	自己搞
Session 回放	内置	内置	自己搞
API 兼容	CMA `/v1` 兼容	原生	自定义
启动时间	60 秒	申请 + 配置	几周到几个月
成本	仅基础设施	Token + 运行时	工程人力
控制台	内置	Anthropic Console	自己搞

FAQ

这是 CMA 的 fork 吗？

不是。完全独立实现，目标是 API 层兼容 CMA /v1 规范。内部架构不同——SQLite 状态、可插拔沙箱后端、模型无关设计。

Anthropic SDK 能直接用吗？

能。baseURL 指向 SandBase 实例就行。/v1 端点和 Anthropic SDK 的 beta sessions API 线协议兼容。

生产能用吗？

SandBase 内部和多个早期用户已在生产跑。单节点场景 SQLite 完全够用。水平扩展用 Worker Queue 沙箱后端。

和 DeepSeek Harness 比呢？

不同路线。DeepSeek Harness 是插件优先的元框架——你用 Cordis 插件拼出一切。SandBase Managed Agents 是有主见的运行时——开箱即用、生产就绪。想要极致灵活选 DSH，想今天就上线选 SandBase MA。

为什么用 SQLite 不用 Postgres？

零配置。不用另外部署、配置、维护数据库服务。SQLite 完全能处理单节点 Agent 运行时的并发模式。如果超出 SQLite 能力，存储层是可插拔的。

Star 仓库，提 Issue，发 PR——Apache-2.0，社区驱动。

想了解 Agent 运行时为什么重要，推荐阅读《生产级 AI Agent 为什么需要运行时层》。