CloudClaw：我们在做一个企业级 AI Agent 平台

一个真实的场景

想象一家 500 人的公司。产品经理需要让 AI 帮忙整理竞品分析报告，客服团队需要 AI 自动回复常见问题，开发团队需要 AI 做代码审查，HR 需要 AI 筛选简历。

这些需求背后是同一件事：企业需要一批 AI Agent——数字员工——为不同的团队、不同的岗位提供不同的服务。

但现实是，大部分 AI Agent 工具都是给个人用的。一个人跑一个本地进程，用本地的文件系统、本地的内存、本地的 Shell。你用得好，不代表你的同事能用；你今天能用，不代表服务挂了还能恢复。

CloudClaw 要解决的就是这个问题：让企业开发者构建一组 Agent（数字员工），然后让企业里所有人都能使用这些 Agent。

• GitHub：cloudclaw-dev/cloudclaw
• 官网：cloudclaw.run

它长什么样？

先看全貌，再说细节。

这张图从上到下四个部分：

顶部——企业员工：所有员工通过浏览器访问平台，每人对话各自的数字员工，数据互不干扰。产品经理用文档 Agent，客服用客服 Agent，HR 用数据分析 Agent，各取所需。

中部——CloudClaw 平台：三层结构。工作流引擎编排多个 Agent 之间的协作；一组数字员工各司其职；底层是 MCP 网关、技能系统、代码沙箱、LLM 路由等基础设施。

左下——企业开发者：通过管理后台配置 Agent、编排工作流。不需要写代码就能定义数字员工的能力和行为。

中下——基础设施：可插拔的后端——PostgreSQL、Redis，也可以用 SQLite 跑单机模式。

右下角还放了一个对比：OpenClaw。个人用户 + 本地记忆，一个人用一个 Agent。和 CloudClaw 的多租户、多 Agent 架构是两种完全不同的东西。

个人助手 vs 企业平台

CloudClaw 和 OpenClaw 是同一作者的两个项目，定位完全不同：

OpenClaw 是一个人的私人管家，拿来就用。CloudClaw 是给团队搭的 Agent 底座，企业开发者按需构建数字员工，服务全员。

为什么选择 Java？

看完架构图，你可能会有一个疑问：为什么不用 Python？

现在的 AI Agent 框架和平台，绝大部分是 Python 生态的。这很自然——AI 和数据科学领域 Python 是绝对主力。

但换个角度看：企业里跑着的系统，大部分是 Java 写的；企业的程序员，大部分是 Java 技术栈。让一个 Java 团队去部署和维护一个 Python 平台，门槛不在于技术难度，而在于生态割裂——不同的包管理、不同的部署方式、不同的运维体系、不同的技术文化。

CloudClaw 选择 Java + Spring Boot，不是因为它更酷，而是因为它是大部分企业最熟悉的技术底座。用团队已经会的东西，永远是最务实的选择。

几个关键的设计决策

从架构图对应到代码，几个核心模块：

• cloudclaw-agent：Agent 引擎，提示词组装，对话编排，工作流调度
• cloudclaw-llm：多 LLM 提供商路由，凭证加密，用量统计
• cloudclaw-mcp：MCP 网关，连接池，工具路由
• cloudclaw-memory：记忆服务（JDBC / Mem0 引擎）
• cloudclaw-sandbox：代码沙箱（Local / Docker / E2B）
• cloudclaw-session：会话 & 消息持久化
• cloudclaw-ui：Vue.js 前端（Chat + Admin 统一 SPA）

其余模块（auth、admin、user、common、debug、standalone、skill、mq、release）各司其职，有兴趣可以看源码。

围绕这些模块，几个关键的设计决策：

1. 无状态设计

所有状态存在数据库或缓存中。加机器就能扩容，某台挂了其他的自动接管。这在企业环境是基本要求。

2. MCP 作为安全边界

Agent 不直接访问宿主机。所有外部交互通过 MCP（Model Context Protocol）进行。100 个员工使用的 Agent，如果可以直接跑 Shell 命令，那等于所有人共享一个 root 权限的终端。MCP 让你可以精确控制 Agent 能做什么。

3. 插件化

记忆引擎、消息队列、LLM 提供商、MCP 服务器——全部可替换。企业技术栈千差万别，CloudClaw 不绑定具体实现。

五种多 Agent 编排模式

一个 Agent 不够用时，多个 Agent 怎么协作？CloudClaw 内置了 5 种编排模式：

Pipeline（流水线）

输入 → [Agent A] → [Agent B] → [Agent C] → 输出

多个 Agent 按顺序处理，前一个的输出是后一个的输入。

场景：需求分析 → 代码生成 → 测试用例生成。

Parallel（并行）

       ┌→ [Agent A] ─┐
输入 ──┤→ [Agent B] ──┤→ 汇总 → 输出
       └→ [Agent C] ─┘

多个 Agent 同时工作，结果汇总。

场景：一份文档同时由语法检查、逻辑审查、格式规范三个 Agent 并行处理。

Router（路由）

               ┌→ [客服 Agent]
输入 → [意图识别] ─→ [销售 Agent]
               └→ [技术 Agent]

根据用户意图自动路由到合适的 Agent。

场景：企业客服入口，先判断问题类型，再分给对应的专业 Agent。

Supervisor（监督者）

             ┌→ [工作 Agent A] ─┐
输入 → [主管 Agent] → [工作 Agent B] ──→ 审核汇总 → 输出
             └→ [工作 Agent C] ─┘

主管 Agent 负责拆分任务、分配和审核，工作 Agent 执行。

场景：写市场分析报告，主管负责规划和审核，工作 Agent 各自调研。

Handoff（移交）

输入 → [Agent A 处理前半段] → [Agent B 接手后半段] → 输出

Agent 之间转移对话上下文。

场景：前台 Agent 收集完信息后，把上下文移交给后台专家 Agent。

每个节点可以独立配置模型、系统提示词、MCP 服务器和 Skill，也可以混搭使用——外层 Router 分发，内层 Pipeline 串联，某个分支用 Supervisor 监督。

怎么跑起来？

方式一：Docker Compose（推荐）

最简单的方式，不需要装 Java、不需要编译：

git clone https://github.com/cloudclaw-dev/cloudclaw.git
cd cloudclaw

# 设置密钥
export JWT_SECRET="***"
export CRYPTO_SECRET="***"

# 一键启动
docker compose up -d

打开 http://localhost:8080/ ，默认账号 admin / admin123。

方式二：JAR 直接运行

适合不想用 Docker 的场景，需要 JDK 17：

git clone https://github.com/cloudclaw-dev/cloudclaw.git
cd cloudclaw && mvn clean package -DskipTests

export JWT_SECRET="***"
export CRYPTO_SECRET="***"

java -jar cloudclaw-app/target/cloudclaw-app-1.0.5.jar

单机模式用 SQLite + 内存队列 + Caffeine 缓存，零外部依赖。

切换到集群模式

生产环境加一个参数：

java -jar cloudclaw-app/target/cloudclaw-app-1.0.5.jar \
  --spring.profiles.active=cluster

配合 PostgreSQL + Redis，水平扩展。

安全设计

Agent 执行隔离：Agent 不直接访问宿主机，通过 MCP、数据库或沙箱交互。沙箱支持 Local / Docker / E2B 三种后端。

认证 & 授权：JWT（HS384）认证，基于角色的访问控制。

凭证加密：LLM API Key 等敏感配置 AES 加密存储。

多租户隔离：不同用户的会话、记忆、配置完全隔离。

技术栈

任何 OpenAI 兼容的 API 都能用，不绑定单一提供商。

写在最后

CloudClaw 目前还是个雏形。核心的 Agent 引擎、多 Agent 编排、MCP 网关、多租户这些能力有了，但很多地方还粗糙——文档不完善，UI 还在迭代，一些边界情况还没处理好。

开源出来，是因为觉得 Java 生态需要一个这样的东西，哪怕现在还不成熟。如果你也在找 Java 技术栈的 Agent 平台，或者对 Agent 平台的设计感兴趣，可以试试，也欢迎提 Issue 和 PR，一起把它打磨好。

• GitHub: github.com/cloudclaw-dev/cloudclaw
• 官网: cloudclaw.run