Clawith 深度拆解：如何用开源方案搭建多 Agent 团队协作平台
核心摘要
Clawith 是一个基于 OpenClaw 生态的开源多智能体协作平台，它解决了 OpenClaw 在团队场景下「Agent 之间互不认识、缺乏组织架构、没有权限管控」的三大核心痛点。 通过引入 Aware 自主感知系统、数字员工身份体系和广场知识沉淀机制，Clawith 让多个 AI Agent 具备了真正的团队协作能力。项目采用 Apache 2.0 开源协议，支持 Docker 一键部署，最低 2 核 CPU + 4GB 内存即可运行。
一、从 OpenClaw 到 Clawith：为什么需要「团队版」
2026 年初，OpenClaw 在开发者社区掀起了一股热潮。作为一款开源的个人 AI 智能体网关，OpenClaw 的核心卖点在于「本地优先、隐私可控」——它运行在用户自己的设备上，通过自然语言指令就能驱动电脑完成文件整理、邮件处理、代码编写等实际工作，而不只是在对话框里回答问题。它赋予 Agent 灵魂（soul.md 人设文件）和记忆（memory.md 长期上下文），还能接入飞书、Slack、Discord 等主流通讯工具，让用户在聊天窗口里就能指挥 AI 干活。
但当我们试图把 OpenClaw 拉进真实的团队工作场景时，问题就来了。
OpenClaw 的架构天然是为「单人使用」设计的。一个 Gateway 对应一个人的多个 Agent，Agent 之间虽然可以在同一台机器上共存，但它们彼此并不「认识」对方。你没法让一个负责数据分析的 Agent 把处理结果自动交给另一个负责写报告的 Agent，更做不到让 Agent 理解团队内部的汇报关系和分工。此外，OpenClaw 缺乏统一的用量管控——每个 Agent 各自持有 API Key，Token 消耗无人把关，操作过程没有审计日志，出了问题很难溯源追责。
正是在这个背景下，Clawith 项目应运而生。它由 DataElem 团队开源，GitHub 仓库地址为 https://github.com/dataelement/Clawith，采用 Apache 2.0 协议。用官方的一句话概括定位就是：OpenClaw 赋能个人，Clawith 将其扩展到组织。
下面我就从技术原理和实际操作两个维度，把这个项目拆开来讲清楚。
二、核心架构：Clawith 的技术底座长什么样
在动手部署之前，先理解 Clawith 的整体架构非常重要。它的技术栈可以用三层来概括：
前端展示层采用 React 19 + Vite + TypeScript 构建，状态管理用的是 Zustand，数据请求用 TanStack Query。这一层提供了 Web 管理界面，用于创建和管理 Agent、查看审计日志、配置组织信息等。
后端服务层基于 Python 的 FastAPI 框架，内置 18 个 API 模块，通过 WebSocket 实现实时通信，JWT + RBAC 负责认证和权限控制。这一层还包含了技能引擎（Skills Engine）、工具引擎（Tools Engine）和 MCP 客户端，是整个平台的业务核心。
基础设施层支持 SQLite 或 PostgreSQL 作为数据库。轻量级试用可以直接用 SQLite，生产环境建议 PostgreSQL。Agent 的工作区文件（包括 soul.md、memory、skills、workspace 文件）存储在宿主机的 ./backend/agent_data/ 目录下，每个 Agent 按 UUID 独立隔离。
用一个简化的架构图表示如下：
┌──────────────────────────────────────────────┐
│ Frontend（React 19） │
│ Vite · TypeScript · Zustand · TanStack Query │
├──────────────────────────────────────────────┤
│ Backend（FastAPI） │
│ 18 API Modules · WebSocket · JWT/RBAC │
│ Skills Engine · Tools Engine · MCP Client │
├──────────────────────────────────────────────┤
│ Infrastructure │
│ SQLite / PostgreSQL · Agent File System │
└──────────────────────────────────────────────┘
值得注意的是，Clawith 本身并不在本地运行 AI 模型——所有 LLM 推理都由外部 API 提供商完成（比如国内常用的各类大模型 API），平台本身是一个标准的 Web 应用加 Docker 编排。这意味着你不需要 GPU，也不需要高性能显卡，一台普通的云服务器或者办公电脑就能跑起来。
三、Aware 自主感知系统：从「定时闹钟」到「主动感知」
如果要说 Clawith 最核心的技术创新，Aware 自主感知系统绝对排在第一位。
OpenClaw 原本有一个 Heartbeat（心跳）机制，默认每 30 分钟触发一次，让 Agent 醒过来看看有没有什么事情要处理。这种机制放在个人场景下勉强够用——毕竟你一个人用，对时效性要求没那么高。但在团队协作中，30 分钟的间隔会导致任务流转严重滞后，多个环节卡在那里等心跳唤醒，效率根本上不去。
Clawith 的 Aware 系统彻底重构了这套逻辑。它引入了「关注点（Focus Items）」和「触发器（Triggers）」的双层结构：
关注点是 Agent 当前正在跟踪的任务和目标，每个关注点有明确的状态标记——待处理（[ ]）、进行中（[/]）、已完成（[x]）。这实际上是 Agent 的结构化工作记忆，让它随时知道自己手头有哪些事情需要盯着。
触发器则绑定在关注点上，决定 Agent 在什么条件下被唤醒。Clawith 内置了 6 种触发器类型，其中最关键的是 on_message 消息触发器——它让 Agent 能够等待特定对象（人或其他 Agent）的回复，收到消息后立即响应并推进工作流。除此之外，还有 Webhook 触发器（接收外部系统的事件推送）、轮询触发器（定时检查某个条件是否满足）、固定间隔触发器等。
这套机制的精髓在于「自适应」三个字。Agent 不是被动执行预设的定时任务，而是根据任务进展动态地创建、调整甚至删除触发器。举一个具体的场景来帮助理解：
假设你给一个「秘书 Agent」下达指令：收集公司 100 名员工对下周团建的想法，没回复的每 6 小时提醒一次，截止本周五。Agent 收到指令后，会先创建一个关注点「团建意见收集」，然后给每位员工分别挂上 on_message 触发器。一旦某位员工回复了消息，对应的触发器就自动取消，不再催促。如果有员工回复说「在忙，晚点看」，Agent 还会智能地降低催促频率。到周五截止时间一到，Agent 会自动汇总已收集的所有意见并生成报告。
这个过程中，Agent 维护的不再是一张死板的定时任务列表，而是一组围绕目标的动态关注点。任务进展变了，策略就跟着变，始终在自适应调整，直到任务完成。
再比如运维监控场景：把 Clawith 接上你的监控系统（通过 Webhook），一旦发现服务器 CPU 或内存异常，Agent 就会被自动唤醒。它可以自己写代码做初步诊断，判断故障严重程度。如果是小问题就记录日志并继续监控；如果是严重故障，就直接往团队群里发警告通知，甚至给自己设一个循环复查任务，每 10 分钟检查一次，直到故障恢复后自动撤销。
从底层实现来看，Aware 系统的关注点和触发器之间是严格绑定的。每一个与任务相关的触发器必须关联到一个明确的关注点（通过 focus_ref 字段引用）。Agent 在创建触发器之前，必须先创建对应的关注点。当关注点的状态被标记为完成时，它下面挂载的所有触发器会被自动取消。这种设计确保了 Agent 不会产生「孤儿触发器」——每一个被唤醒的动作都有明确的目标和意义，避免了无意义的计算资源浪费。
这套机制的另一个好处是可观测性非常好。管理员可以在 Web 界面上直接看到每个 Agent 当前关注着哪些事情、每个关注点挂了哪些触发器、触发器的状态和历史执行记录。这比 OpenClaw 原来那种简单的心跳机制透明得多，出了问题排查起来也更方便。
四、数字员工身份体系：让 Agent 真正融入组织
Clawith 的另一个核心设计是「数字员工身份」。在这里，Agent 不再是孤立的聊天助手，而是组织架构中的正式成员。
每个 Agent 在创建时都需要经过一个 5 步向导：命名 → 设定人设（soul.md）→ 配置技能 → 分配工具 → 设置权限。创建完成后，Agent 就拥有了完整的组织身份——它知道公司里有哪些人类同事、有哪些其他 Agent 同事，了解彼此的汇报关系和职责分工。
这种设计带来了几个很实用的能力。首先是任务委派：当一个 Agent 收到超出自己能力范围的任务时，它可以主动把子任务委派给更合适的 Agent 同事。比如市场分析 Agent 需要一份竞品数据，它会自动把数据采集任务转交给数据分析 Agent，等结果返回后再继续自己的工作。
其次是协作咨询：Agent 之间可以互相发消息、提问题、请求协作。这不是简单的 API 调用，而是基于组织关系图谱的智能路由——Agent 会判断谁最适合处理当前的请求，然后主动发起沟通。
第三是督办跟进：Clawith 引入了一类特殊的「督办任务（Supervision Tasks）」。你可以指定一个 Agent（比如秘书 Agent）去主动跟进其他同事——不管是人类还是 AI——确保待办事项按时完成。它会自动发提醒、升级告警、汇报进展，省去了管理者亲自催人的精力。这个功能在项目管理和行政协调场景中非常实用，相当于给团队配了一个永不疲倦的项目助理。
每个 Agent 的身份信息还包括一份 soul.md 文件，定义了它的人格特质、价值观和工作风格。这份文件不是一次性的会话提示词，而是跨所有对话持久生效的身份文件。这意味着同一个 Agent 无论在什么时间、在哪个对话中被唤醒，它的行为风格都是一致的。比如你把一个 Agent 定义为「严谨、注重数据、不喜欢模糊表述」，那它在所有交互中都会保持这个风格。
在通讯工具集成方面，Clawith 做得非常彻底。每个 Agent 可以拥有独立的飞书机器人账号、Slack 账号或 Discord 账号，直接在工作群里参与讨论和协作。这意味着对于团队中的人类成员来说，跟 Agent 交互和跟同事交互的体验几乎没有区别——都是在聊天群里发消息。
五、广场机制：Agent 的组织知识沉淀池
Clawith 引入了一个叫做「广场（Plaza）」的模块，这是一个面向全组织的内部信息交流中心。Agent 可以在广场里发布工作动态、分享发现、评论彼此的工作成果，人类成员也可以参与进来。
广场的设计意图不是做一个简单的消息板，而是构建一个持续性的组织知识吸收通道。随着时间积累，每个 Agent 会通过广场里的内容逐渐建立起对团队业务流程、工作风格和领域知识的理解。这避免了一个常见的痛点——传统的 AI 助手每次开启新对话都要从头开始理解上下文，而 Clawith 的 Agent 通过广场机制实现了知识的持续沉淀。
从技术实现来看，广场模块通过内置的 Plaza Browse、Plaza Post 和 Plaza Comment 三个工具来支撑。Agent 在执行任务的过程中会自动浏览广场动态，将相关信息纳入自己的工作上下文。这个机制配合每个 Agent 独立的 memory.md 长期记忆文件，形成了一个「组织级知识 + 个体级记忆」的双层信息架构。
六、企业级管控：让团队敢放开手脚用
很多团队面对 AI 工具的态度是「不是不想用，而是不敢用」。怕 Agent 乱操作搞出事故，怕调用成本失控，出了问题不知道找谁负责。Clawith 在管控层面做了相当完善的设计。
用量配额管理方面，管理员可以为每个用户设置消息数量限额和 LLM API 调用上限，也可以为每个 Agent 设置 TTL（存活时间），防止资源被无限制消耗。
操作审批机制方面，Clawith 支持三级自主权限控制：L1 级别是完全自动执行，适合低风险的日常操作；L2 级别是执行后通知，Agent 先干活再向管理员汇报；L3 级别是执行前审批，涉及高风险操作必须经过人工确认才能执行。这三个级别可以按 Agent 或按操作类型灵活配置。
审计日志方面，所有 Agent 的每一步操作都有完整记录，可追溯、可审计。这在合规性要求较高的行业场景中尤为重要。
此外，Clawith 还支持多租户隔离和 RBAC 权限控制——不同团队或部门的数据和 Agent 完全隔离，角色权限可以精细化管理。平台内置的企业知识库功能，则可以把组织的共享文档和规章制度自动注入到每个 Agent 的对话上下文中，确保 Agent 的输出符合组织规范。
七、内置能力清单：开箱即用的技能和工具
Clawith 预装了 7 项技能和 15 个工具，覆盖了团队日常工作的大部分场景。
技能方面包括：网络研究（带来源可信度评分的结构化调研）、数据分析（CSV 分析和模式识别）、内容写作（文章、邮件、营销文案）、竞品分析（SWOT 分析和波特五力模型）、会议纪要（带行动项和跟进提醒）、复杂任务执行器（多步骤规划和分步执行）、技能创建器（Agent 可以为自己或同事创建新技能）。
工具方面包括：文件管理、文档阅读器（支持 PDF/Word/Excel/PPT 解析）、任务管理（看板式的任务创建和跟踪）、Agent 消息（Agent 间委派和协作）、飞书消息（向人类同事发送飞书消息）、Jina 搜索和 Jina 阅读（网络搜索和全文提取）、代码执行（沙箱化的 Python/Bash/Node.js 运行环境）、资源发现和导入 MCP 服务器（从 Smithery 和 ModelScope 搜索并安装新工具）。
特别值得一提的是自进化能力——当 Agent 遇到现有工具无法解决的任务时，它会自动搜索公开的 MCP（Model Context Protocol）工具注册中心，找到合适的工具后一键导入并立即获得新能力。这个过程不需要重启服务，也不需要人工干预。
八、实战部署：手把手教你搭建 Clawith
下面进入实操环节。Clawith 提供了两种部署方式：本地脚本安装和 Docker 部署。对于大多数用户，Docker 方式更简单可靠。
8.1 硬件要求
官方建议的最低配置为 2 核 CPU、4GB 内存、30GB 磁盘空间。这个配置非常亲民，绝大多数云服务器和办公电脑都能满足。需要再次强调：Clawith 不在本地跑 AI 模型，所有推理工作由外部 API 完成，所以不需要 GPU。
8.2 Docker 部署步骤
确保你的机器上已经安装了 Docker 和 Docker Compose，然后依次执行以下命令：
# 第一步：克隆项目代码
git clone https://github.com/dataelement/Clawith.git
# 第二步：进入项目目录并复制环境配置文件
cd Clawith && cp .env.example .env
# 第三步：启动所有服务
docker compose up -d
执行完毕后，打开浏览器访问 http://localhost:3000/ 就能看到 Clawith 的 Web 管理界面了。
8.3 本地脚本安装
如果你更倾向于不使用 Docker，可以通过本地脚本安装：
# 克隆项目
git clone https://github.com/dataelement/Clawith.git
cd Clawith
# 生产环境安装（仅安装运行时依赖，约 1 分钟）
bash setup.sh
# 开发环境安装（额外安装 pytest 等测试工具，约 3 分钟）
bash setup.sh --dev
安装脚本会自动检测 PostgreSQL 是否可用。如果你的机器上没有 PostgreSQL，脚本会自动下载并启动一个本地实例。如果你想使用已有的 PostgreSQL，需要在运行 setup.sh 之前创建 .env 文件并配置数据库连接：
# .env 文件中添加 DATABASE_URL=postgresql+asyncpg://user:pass@localhost:5432/clawith?ssl=disable
8.4 国内网络加速配置
如果你在国内服务器上部署，Python 包的下载速度可能不理想。Clawith 贴心地提供了国内镜像源配置，只需要在运行安装之前设置两个环境变量：
export CLAWITH_PIP_INDEX_URL=https://pypi.tuna.tsinghua.edu.cn/simple
export CLAWITH_PIP_TRUSTED_HOST=pypi.tuna.tsinghua.edu.cn
8.5 首次使用和管理员配置
部署完成后，打开 Web 界面，点击「注册」创建你的账号。第一个注册的用户会自动成为平台管理员，拥有所有管理权限。后续注册的用户权限由管理员分配。
创建管理员账号后，你需要做的第一件事是配置 LLM 模型池——进入设置页面，添加你的大模型 API 提供商信息（API Key、模型名称、接口地址等）。Clawith 支持同时配置多个提供商，并可以设置路由策略。比如你可以把简单的对话任务路由到成本较低的模型，把复杂推理任务路由到能力更强的模型，从而在效果和成本之间取得平衡。
然后就可以开始创建你的第一个 Agent 了。按照 5 步创建向导：给它取个名字 → 写一段人设描述（定义它的性格、工作风格和专长领域）→ 选择它需要的技能 → 分配可用工具 → 设定权限级别。完成后 Agent 就上线了，你可以在聊天界面直接和它对话，也可以配置飞书或 Slack 集成后在通讯工具里跟它交互。
这里有一个新手容易踩的坑需要提醒：Agent 的人设描述（soul.md）写得好不好，直接影响它的工作质量。建议在人设中明确三件事——它擅长什么、它的工作边界在哪里、遇到超出能力范围的任务应该怎么处理（比如转交给哪个 Agent 同事）。人设描述不需要很长，但要足够具体，避免模糊的泛泛之谈。
另外，Agent 的工作空间数据存储在宿主机的 ./backend/agent_data/<agent-uuid>/ 目录下。如果你需要备份或迁移 Agent，直接备份这个目录即可。每个 Agent 目录中包含 soul.md（身份文件）、memory 相关文件（长期记忆）、skills 目录（已安装的技能）和 workspace 目录（工作过程中产生的文件）。
九、进阶配置：通讯工具接入与多 Agent 编排
9.1 飞书集成
Clawith 支持每个 Agent 拥有独立的飞书机器人身份。配置飞书集成后，Agent 可以在飞书群里直接接收和回复消息，也可以主动向特定用户发送通知。具体的配置步骤需要在飞书开放平台创建应用、获取 App ID 和 App Secret，然后在 Clawith 后台填入对应的凭据信息。
9.2 Slack 和 Discord 集成
Slack 集成允许 Agent 连接到指定的 Slack 频道，通过 @ 提及来触发响应。Discord 集成则注册了 /ask 斜杠命令，团队成员在 Discord 服务器中使用该命令即可与 Agent 交互。
9.3 多 Agent 协作编排
当你创建了多个 Agent 后，需要在组织关系图中配置它们之间的关系。指定谁是谁的「同事」，谁可以向谁委派任务。这样当一个 Agent 需要协作时，它就知道应该找谁帮忙。
一个典型的团队 Agent 编排示例：
- 「项目经理 Agent」——负责接收需求、拆解任务、分配给下游 Agent，并跟踪整体进度
- 「数据分析 Agent」——负责数据采集、清洗和分析，将结果交给需要数据支持的其他 Agent
- 「内容创作 Agent」——负责撰写文档、报告和宣传文案
- 「运维监控 Agent」——通过 Webhook 接入监控系统，自动处理告警并在必要时通知团队
这些 Agent 之间通过消息工具（Agent Messaging）互相通信，通过广场（Plaza）共享组织知识，各司其职又紧密协作。
十、与其他方案的横向对比
目前开源社区中做多 Agent 协作的方案并不多。简单做一个对比来帮助大家判断 Clawith 是否适合自己的场景。
OpenClaw 原版适合个人用户和小型自动化场景，架构轻量、部署简单，但缺乏团队协作和企业管控能力。如果你只是个人使用，OpenClaw 本身已经足够强大。
HiClaw是另一个基于 OpenClaw 的团队化方案，采用 Manager-Worker 架构，强调安全隔离——Worker 不持有真实的 API Key，所有凭据通过 AI Gateway 代理。它内置了 Matrix 通讯服务器，不依赖外部 IM 工具。HiClaw 更侧重安全性设计，适合对凭据管理有严格要求的场景。
Clawith 的差异化优势在于 Aware 自主感知系统和数字员工身份体系。它不只是把多个 Agent 放在一起跑，而是让它们真正理解彼此的角色和关系，能够自适应地协调工作流程。加上广场机制带来的知识沉淀能力和完善的企业管控功能，它更适合想要构建长期运行的 AI 团队工作流的组织。
十一、写在最后的一些思考
从个人 AI 助手到团队级多 Agent 协作，这个演进方向几乎是确定的。当下的挑战不在于大模型够不够聪明——事实上，主流大模型的推理能力已经相当可观——而在于如何把这些能力有效地组织起来，嵌入到真实的团队工作流程中。
Clawith 给出了一个值得参考的思路：不是用复杂的编排框架去硬编码工作流，而是让每个 Agent 成为组织中有身份、有记忆、有感知能力的「数字员工」，通过关注点和触发器的机制自适应地推进工作。这种设计更接近于人类团队的实际运作方式——每个人知道自己的职责，知道有事找谁，根据进展灵活调整工作节奏。
当然，作为一个还比较年轻的开源项目，Clawith 还有不少需要完善的地方。社区生态还在起步阶段，文档和最佳实践还不够丰富，在复杂生产环境中的稳定性也有待更多用户验证。但从架构设计和功能完整度来看，它已经具备了相当的工程化水准。
从更宏观的视角来看，AI Agent 的能力边界正在快速扩张。从最初只会回答问题的聊天机器人，到能够操作电脑执行任务的个人助手，再到现在能够组队协作的数字员工团队——每一步跨越都在降低人与 AI 协作的门槛。当部署一套多 Agent 协作系统的成本和难度降低到一台普通电脑就能搞定的程度时，很多原本需要大量人工协调的重复性工作就有了全新的解决路径。
对于技术团队来说，现在是开始实验和积累经验的好时机。不妨先从一两个简单的场景入手——比如让一个 Agent 负责每日的竞品资讯监控，另一个 Agent 负责整理汇总——在实践中摸索多 Agent 协作的边界和注意事项。等到工具和模型能力进一步成熟，你积累的这些经验就会成为团队的核心竞争力。
如果你正在用 OpenClaw 做各种自动化实验，或者你的团队正在寻找一套可自主部署的 AI 协作工具方案，Clawith 确实值得花时间去试一试。
