轻核心
核心负责路由、上下文、会话、工具与执行编排，不吞并每个平台的业务规则。
这是一套面向企业系统，而不是个人 Agent 的架构。
像 OpenClaw 这类个人 Agent 更偏向个人工具使用和用户自有配置。AtlasClaw 则把核心编排与 Provider 运行时合同分开，让多用户部署、受控执行、权限治理和企业系统边界能够在生产环境里成立。
核心原则
围绕企业边界设计。
AtlasClaw 的设计重点不是把所有逻辑堆进核心，而是保持边界稳定。
强 Provider
每个 Provider 都封装 SmartCMP、Jira、ITSM、可观测、OA、CRM 等目标系统的鉴权行为、Skills、脚本、参考资料与接口归一化。
权限继承
AtlasClaw 传递真实用户身份边界，把授权与审计继续留在目标平台。
点击放大 整体流转
从入口通道到 Core，再到 Providers 和企业系统，执行路径保持清晰。
整体流转
关闭预览 从入口通道到 Core，再到 Providers 和企业系统，执行路径保持清晰。
点击放大 核心组成
API、Session、Agent Engine、Tools 和 Provider Registry 构成可复用底座。
核心组成
关闭预览 API、Session、Agent Engine、Tools 和 Provider Registry 构成可复用底座。
点击放大 Provider 参考流
SmartCMP 设计图展示了请求、审批与平台执行之间的关系。
Provider 参考流
关闭预览 SmartCMP 设计图展示了请求、审批与平台执行之间的关系。
运行时路径
从消息到受控执行。
- 访问通道包括 Web UI、嵌入面板、聊天平台与 Webhook AI 集成。
- AtlasClaw Core 提供 API 层、会话服务、Provider Registry 与 Agent Engine。
- Skill 执行交给理解目标平台鉴权和操作模型的 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。