架构

这是一套面向企业系统,而不是个人 Agent 的架构。

像 OpenClaw 这类个人 Agent 更偏向个人工具使用和用户自有配置。AtlasClaw 则把核心编排与 Provider 合同分开,让多用户部署、受控执行和企业系统边界能够在生产环境里成立。

核心原则

围绕企业边界设计。

AtlasClaw 的设计重点不是把所有逻辑堆进核心,而是保持边界稳定。

轻核心

核心负责路由、上下文、会话、工具与执行编排,不吞并每个平台的业务规则。

强 Provider

每个 Provider 都封装目标系统的鉴权行为、Skills、脚本、参考资料与接口归一化。

权限继承

AtlasClaw 传递真实用户身份边界,把授权与审计继续留在目标平台。

AtlasClaw overall architecture 点击放大

整体流转

从入口通道到 Core,再到 Providers 和企业系统,执行路径保持清晰。

AtlasClaw core architecture 点击放大

核心组成

API、Session、Agent Engine、Tools 和 Provider Registry 构成可复用底座。

CMP interaction flow 点击放大

Provider 参考流

SmartCMP 设计图展示了请求、审批与平台执行之间的关系。

运行时路径

从消息到受控执行。

  • 访问通道包括 Web UI、嵌入面板、聊天平台与 Webhook。
  • AtlasClaw Core 提供 API 层、会话服务、Provider Registry 与 Agent Engine。
  • 执行交给理解目标平台鉴权和操作模型的 Provider。
  • 外部企业系统仍然是执行落点与业务真实来源。
设计判断

为什么是这种架构。

为什么不是个人 Agent 架构?

像 OpenClaw 这类个人 Agent 更适合个人效率场景。企业环境需要共享部署、受控访问、Provider 合同和系统侧审计边界,AtlasClaw 把这些要求显式建模。

为什么要 Provider Qualified Skills?

显式的 Provider 前缀避免技能冲突,让执行目标更清晰,也让 Webhook 调度更安全。

为什么要同时支持嵌入式和独立式?

有些团队需要在已有产品中加 AI 模块,有些团队需要统一的跨系统 Agent 入口。AtlasClaw 用同一套核心心智支持两种形态。

系统如何接入 LLM brains?

通过 Webhook 入口和 provider-qualified skills,现有系统可以把 AtlasClaw 作为 AI 执行层调用,让传统产品无需重建一套 Agent 栈也能获得 LLM 能力。

下一步

继续进入集成模型。

理解架构之后,下一步就是看 AtlasClaw 如何把外部系统组织成 Providers。

集成