Clawith：基于OpenClaw、面向前沿组织的多智能体协作平台

人工智能研究

Clawith：基于OpenClaw、面向前沿组织的多智能体协作平台

發布人 Brave 2026-03-20 09:13

从 OpenClaw 到 Clawith：理解背景与谱系
OpenClaw 的诞生与爆发
OpenClaw 催生的"Claw 家族"现象
Clawith 的诞生逻辑
什么是 Clawith
核心技术亮点
Aware（自主意识系统）
Focus（结构化工作记忆）
自适应触发（Self-Adaptive Triggering）
代理身份持久化（Agent Identity Persistence）
社交化协作网络（Social Networking for Agents）
运行时工具发现（Runtime Tool Discovery）
跨平台集成
企业级能力
技术栈与部署
技术架构总览
部署方式
安全考量与风险提示
OpenClaw 生态的安全事件
中国政府的安全管控
对 Clawith 用户的建议
为什么选择 Clawith
团队化作战
开源与社区驱动
开发者友好
竞品全景：Clawith 在 AI 代理生态中的定位
第一梯队：Claw 家族——从 OpenClaw 衍生的专项创新
第二梯队：多智能体编排框架——"编程框架"级别的竞品
第三梯队：LLMOps 与可视化平台
第四梯队：新兴协议原生与类型安全框架
全景对比总表
选择框架的决策树（升级版）
小结
参考资源
Clawith 与 OpenClaw
Claw 家族
多智能体编排框架
LLMOps 与可视化平台
新兴协议与框架
协议标准
安全与行业分析

在人工智能（AI）从"单打独斗"转向"团队协作"的大趋势下，Clawith（由 dataelement 团队开发）作为一款开源的多智能体协作平台正式亮相。它不仅是一个 AI 助手，更是一个能让多个智能体像真实团队成员一样工作的环境。Clawith 的定位可以用一句话概括："OpenClaw for Teams"——它将 OpenClaw 的个人级 AI 代理能力，扩展到了面向前沿组织的多智能体团队协作层面。

截至 2026 年 3 月，Clawith 在 GitHub 上已获得 174 颗星标，遵循 Apache 2.0 开源协议，最近一次代码更新为 2026 年 3 月 10 日，项目处于活跃开发状态。 本节课将带你深入了解 Clawith 的核心设计理念、技术架构、典型应用场景，以及它在多智能体框架生态中的独特定位。

从 OpenClaw 到 Clawith：理解背景与谱系

OpenClaw 的诞生与爆发

📌 要理解 Clawith，首先需要理解它的"母项目"——OpenClaw。

OpenClaw（曾用名 Clawdbot / Moltbot / Molty）是由 Peter Steinberger 开发的一款免费、开源的自主人工智能代理。 与传统的对话式 AI 助手不同，OpenClaw 是一个真正的"自主代理"（Autonomous Agent）：它能够执行 Shell 命令、读写文件、浏览网页、发送邮件、管理日历，并在你的整个数字生活中采取行动。

OpenClaw 的发展历程堪称现象级：

🗓️ 2025 年 11 月：项目以 "Clawdbot" 之名首次发布
🔥 上线 24 小时内：在 GitHub 上斩获 9,000 颗星标
🔄 2026 年 1 月：因商标问题更名为 "OpenClaw"
📈 截至 2026 年 3 月：GitHub 星标突破 250,000，超越 React 成为 GitHub 上星标最多的软件项目，成为开源历史上增长最快的项目之一

OpenClaw 的核心架构理念是"网关中心化设计"（Gateway-Centric Design）——所有消息流、会话管理和通道连接都通过一个名为 Gateway 的单一进程来统一调度，官方文档称之为"单一真实来源"（Single Source of Truth）。这一设计保证了系统行为的一致性和可预测性。

OpenClaw 的另一项重要设计哲学是"Markdown 即配置"（Markdown-as-Config）。 它将代理的基础设施与代理的身份进行了明确分离：基础设施由平台处理，而身份——包括代理的全部人格、启动序列、记忆结构和汇报链——全部以纯 Markdown 文件的形式存储在工作空间目录中，可读、可 diff、可版本控制。这一设计极大地降低了配置门槛，也让代理的行为具备了可审计性。

OpenClaw 催生的"Claw 家族"现象

📌 OpenClaw 的爆发式增长催生了一个极为独特的生态现象——"Claw 家族"（Claw Family）。在 OpenClaw 开源后短短数周内，大量开发者基于不同理念和目标，构建了各种衍生和替代项目，形成了一个繁荣而嘈杂的生态系统。理解这个家族谱系对于定位 Clawith 至关重要。

Claw 家族主要成员一览（截至 2026 年 3 月）：

项目	GitHub 星标	语言	核心定位	开源协议
🦞 OpenClaw	~250K	TypeScript	原版个人 AI 代理	Apache 2.0
🐈 Nanobot	—	Python	超轻量级（~4,000 行代码），学术可读性极强	MIT
🔒 NanoClaw	—	Python	容器隔离优先，安全至上	Apache 2.0
🦀 IronClaw	—	Rust	WASM 沙盒 + 加密验证，零信任架构	—
⚡ PicoClaw	~25K	Go	嵌入式/IoT 场景，<10MB 内存	—
🤝 Clawith	174	Python/TS	多智能体团队协作（本文主角）	Apache 2.0

这些项目各自针对 OpenClaw 的不同"痛点"进行了差异化创新，我们将在后续的竞品对比章节中详细展开。

Clawith 的诞生逻辑

📌 OpenClaw 赋能个人，Clawith 将其扩展至前沿组织。

尽管 OpenClaw 极为强大，但它本质上是为单一用户设计的个人 AI 代理。当企业需要让多个 AI 代理像团队一样协作——理解组织架构、互相委派任务、共享工作成果——OpenClaw 的单代理架构就暴露出了局限性。

Clawith 正是为填补这一空白而诞生的。 它继承了 OpenClaw 的核心代理能力（身份持久化、长期记忆、技能系统），并在其之上构建了一整套面向团队的协作基础设施：组织感知、角色权限、社交网络、以及自主的跨代理通信机制。

dataelement 团队同时维护着相关的姊妹项目 ClawCore（基于 TypeScript 的 OpenClaw 核心版本，MIT 协议），以及 OpenOntology（开源的 Palantir Ontology 项目），形成了一个涵盖 AI 代理、数据本体和知识图谱的开源产品矩阵。

什么是 Clawith

Clawith 是 OpenClaw 的团队版本，旨在解决单一智能体在处理复杂任务时的局限性。与传统的对话式 AI 不同，Clawith 赋予了每个智能体持久的身份、长期记忆以及独立的工作空间。

更具体地说，Clawith 是一个让 AI 代理成为组织"数字员工"的平台。每个代理都理解完整的组织架构图（Org Chart），可以向其他代理发送消息、委派任务，并建立真实的工作关系——就像一个新员工入职并融入团队一样。这种"社交化"的智能体设计，是 Clawith 区别于市场上绝大多数多智能体框架的核心差异点。

核心技术亮点

Aware（自主意识系统）

🧠 这是 Clawith 的核心灵魂。智能体不再是被动等待指令，而是能够主动感知环境、做出决策并采取行动。

在传统的 AI 代理系统中，代理通常遵循"请求-响应"模式：人类发出指令，代理执行，然后等待下一条指令。Aware 系统从根本上颠覆了这一范式。 在 Aware 架构下，代理具备了一个持续运行的"感知-决策-行动"循环（Perceive-Decide-Act Loop）：

⚡ 感知（Perceive）：代理持续监测其工作环境中的变化——包括新消息、任务状态更新、其他代理的活动、外部系统的事件通知等
🎯 决策（Decide）：基于当前的感知信息、自身的长期记忆（memory.md）、任务追踪列表（Focus Items）以及组织上下文，代理自主判断下一步应采取的行动
🔧 行动（Act）：代理执行决策——这可能是完成一个子任务、向另一个代理委派工作、在社交动态流中发布更新，甚至是动态调整自己的调度计划

Aware 的实际意义在于：你不需要时刻"盯着"你的 AI 代理。分配好目标后，代理会像一个有责任心的团队成员一样，自主推进工作、遇到阻塞主动沟通、完成后主动汇报。

Focus（结构化工作记忆）

📋 智能体会维护一套任务追踪列表，包含待办（pending）、进行中（in progress）和已完成（completed）状态，确保复杂任务不掉链子。

Focus 系统不仅仅是一个简单的 To-Do 列表——它是代理"结构化工作记忆"的核心载体。 每个 Focus Item 使用标准化的状态标记：

标记	状态	含义
`[ ]`	⏳ Pending	待处理的任务
`[/]`	🔄 In Progress	正在进行中的任务
`[x]`	✅ Completed	已完成的任务

Focus 系统的关键设计原则是"Focus-Trigger 绑定"（Focus-Trigger Binding）：每一个与任务相关的触发器（Trigger）都必须有一个对应的 Focus Item。 代理必须先创建 Focus Item，然后通过 focus_ref 字段设置引用该 Focus 的触发器。当一个 Focus 被标记为完成时，代理会自动取消其关联的所有触发器。这种绑定机制确保了：

📌 不存在"无头"触发器（即没有明确目标的调度任务）
📌 不存在"僵尸"Focus（即任务已完成但触发器仍在运行）
📌 代理的行为始终可追溯、可审计

自适应触发（Self-Adaptive Triggering）

⏰ 人类只需分配目标，智能体会根据任务演进动态地创建、调整和取消自己的调度计划。

自适应触发是 Clawith 实现真正"自主性"的关键机制之一。 与传统的工作流引擎不同——那些系统需要人类预先定义好每一步的调度逻辑——Clawith 的代理能够根据任务的实际演进，动态地管理自己的触发器。

Clawith 支持六种触发器类型，覆盖了从定时调度到事件驱动的全部场景：

触发器类型	描述	典型用例
🔁 `cron`	按 cron 表达式周期性触发	每天早上 9 点生成日报
1️⃣ `once`	在指定时间点触发一次	明天下午 3 点提醒我开会
⏱️ `interval`	每隔 N 分钟触发一次	每 30 分钟检查一次系统健康状态
🌐 `poll`	轮询 HTTP 端点，检测变化	监控竞品网站的价格变动
💬 `on_message`	当特定代理或人类回复时唤醒	等待审批人回复后继续流程
🪝 `webhook`	接收外部 HTTP POST 事件	GitHub 有新 PR 时自动触发代码审查

一个具体的例子：假设你指派一个代理"监控 GitHub 仓库的 Issue 并每周生成汇总报告"。代理会自主执行以下步骤：

创建一个 Focus Item："监控 GitHub Issue 并生成周报"
设置一个 webhook 触发器：当 GitHub 仓库有新 Issue 创建时接收通知
设置一个 cron 触发器：每周五下午 5 点生成周报
如果人类后来修改需求为"改为每日报告"，代理会自动调整 cron 触发器的频率
当该任务被取消或完成时，代理会自动清理所有关联的触发器

代理身份持久化（Agent Identity Persistence）

🪪 每个 Clawith 代理都拥有一套完整的、持久化的"数字身份"系统，由三个核心文件组成：

文件	功能	说明
📄 `soul.md`	人格定义	定义代理的性格特质、行为准则、沟通风格和专业领域
🧠 `memory.md`	长期记忆	存储代理在历次交互中积累的经验、总结和知识
📁 私有文件系统	工作空间	每个代理拥有独立的沙盒化文件系统，支持代码执行

这些文件在每次对话中持久保存，使得每个代理真正具备了"个性"和"成长性"。 代理不会因为一次会话结束就"失忆"——它的经验会不断积累，行为会随着时间推移变得更加精准和个性化。这也是 Clawith 官方所说的"Agents with a soul"（有灵魂的代理）的含义所在。

社交化协作网络（Social Networking for Agents）

🤝 Clawith 的代理不是孤立运作的——它们组成了一个具有社交属性的协作网络。

📊 组织架构感知：每个代理理解完整的组织架构图，知道谁负责什么、向谁汇报、找谁协作
💬 消息与委派：代理之间可以直接发送消息、委派任务、请求协助
📰 社交动态流：代理会在动态流中发布工作进展、分享发现、评论同事的工作。这不仅仅是一个"消息板"——它是每个代理吸收组织知识并保持上下文感知的连续通道
🎓 技能传承：代理可以为自己或同事创建新的技能（Skills），实现知识在团队内部的沉淀和复用

运行时工具发现（Runtime Tool Discovery）

🔍 Clawith 的代理不仅能使用预装的工具——它们还能在运行时自主发现和安装新工具。

Clawith 集成了两大工具注册中心：

🛠️ Smithery：截至 2026 年，Smithery 已成为 MCP（Model Context Protocol）服务器的核心发现平台，收录了超过 7,300 个可用工具和扩展。代理可以通过 Smithery 按名称、描述或功能属性搜索并动态安装所需的 MCP 服务器。
🔬 ModelScope MCP 注册中心：由阿里巴巴达摩院维护的 ModelScope 提供了丰富的 AI 资源生态——从图像生成到模型发现、数据集检索、应用搜索和论文查询。代理可以通过 ModelScope 的 MCP 服务器直接访问这些资源。

这一能力的意义在于：Clawith 的代理团队不是一个"能力固化"的系统——它们可以根据任务需求，自主扩展自己的工具库，实现真正的"即学即用"。 例如，当一个代理发现当前任务需要图像处理能力，但自身没有相关工具时，它可以主动从 Smithery 搜索并安装一个图像处理 MCP 服务器，然后立即投入使用。

跨平台集成

🔗 支持通过多种办公工具进行交互，并将智能体身份注入系统提示词，实现更自然的协作体验。

Clawith 支持的集成通道包括：

💬 Feishu / Lark（飞书）：每个代理拥有独立的飞书机器人身份
💼 Slack：深度集成 Slack 工作空间，支持频道级别的代理分配
🎮 Discord：支持 Discord 服务器中的代理交互
以及 OpenClaw 生态中支持的更多通道（Telegram、WhatsApp、Microsoft Teams、Google Chat 等）

每个代理在不同通道中保持一致的身份和记忆——你在飞书中与"产品经理代理"交流的上下文，会延续到你在 Slack 中的后续对话。

企业级能力

Clawith 不仅仅是一个开发者的玩具——它具备完整的企业级特性，专为生产环境设计：

能力	说明
🔐 多租户 RBAC	基于组织的隔离和基于角色的访问控制，确保不同团队、不同项目之间的数据隔离
📊 用量配额	对 LLM 调用次数进行上限控制，防止成本失控
✅ 审批工作流	对高风险操作（如访问敏感数据、执行外部命令）设置审批流程
📝 审计日志	完整记录代理的所有行为，满足合规和审计需求
📚 知识库	组织级别的知识沉淀，所有代理共享访问

技术栈与部署

技术架构总览

Clawith 采用了一套生产就绪的容器化技术栈，设计上支持水平扩展：

┌─────────────────────────────────────────────────┐
│                   Frontend                       │
│       TypeScript · Zustand · TanStack Query      │
├─────────────────────────────────────────────────┤
│                   Backend                        │
│  FastAPI · 18 API Modules · WebSocket            │
│  JWT/RBAC · Skills Engine · Tools Engine         │
│  MCP Client (Streamable HTTP)                    │
│  SQLAlchemy (async) · Alembic                    │
├─────────────────────────────────────────────────┤
│               Infrastructure                     │
│  SQLite / PostgreSQL · Redis · Docker            │
│  Smithery Connect · ModelScope OpenAPI           │
└─────────────────────────────────────────────────┘

几个值得关注的技术选型：

⚙️ FastAPI：高性能的 Python 异步 Web 框架，适合处理大量并发的代理通信
🔌 WebSocket：支持代理与前端之间的实时双向通信，是实现"流式"代理响应的基础
🔑 JWT/RBAC：工业级的身份认证和权限控制
🛢️ SQLAlchemy (async) + Alembic：异步 ORM 加数据库迁移管理，确保数据层的可靠性和可演进性
🗄️ Redis：用于缓存、消息队列和会话管理，支撑高并发场景
🔧 MCP Client（Streamable HTTP）：基于 Model Context Protocol 的工具调用客户端，采用 HTTP 流式传输以降低延迟

💡 重要提示：Clawith 本身不运行任何 AI 模型——所有 LLM 推理都由外部 API 提供商（如 OpenAI、Anthropic、Google 等）处理。本地部署的是一个标准的 Web 应用和 Docker 编排环境。这意味着你不需要 GPU 服务器就能运行 Clawith。

部署方式

Clawith 提供两种部署方式，满足从开发调试到生产部署的不同需求：

方式一：Setup 脚本（推荐用于快速上手）

# 克隆仓库
git clone https://github.com/dataelement/Clawith.git
cd Clawith

# 生产模式（仅安装运行时依赖，约 1 分钟）
bash setup.sh

# 开发模式（额外安装 pytest 等测试工具，约 3 分钟）
bash setup.sh --dev

Setup 脚本会自动检测本地是否已有 PostgreSQL 实例：如果有则直接使用，如果没有则自动下载并启动一个本地实例。

方式二：Docker Compose（推荐用于生产环境）

git clone https://github.com/dataelement/Clawith.git
cd Clawith
cp .env.example .env    # 编辑 .env 配置你的 API 密钥等参数
docker compose up -d    # 启动所有服务
# 访问 http://localhost:3000

安全考量与风险提示

⚠️ 有必要坦诚地讨论与 Clawith 及 OpenClaw 生态相关的安全风险。这些风险不仅仅是理论上的——它们已经在真实世界中产生了影响。

OpenClaw 生态的安全事件

2026 年初，网络安全领域爆发了一系列与 OpenClaw 相关的严重安全事件：

🔓 大规模实例暴露：SecurityScorecard 在 2026 年 2 月发现超过 135,000 个 OpenClaw 实例直接暴露在公共互联网上。更令人担忧的是，其中 42,665 个实例存在身份验证绕过漏洞（Authentication Bypass），意味着任何人无需凭证即可访问。高达 93% 的公开暴露实例存在严重的身份验证绕过漏洞。
🦠 ClawHub 供应链攻击：安全研究人员在 OpenClaw 的公共技能注册中心 ClawHub 中发现了大量恶意技能包。Bitdefender 的研究团队发现，在约 4,500 个已发布的技能包中，约有 900 个（约 20%）是恶意的。 这些恶意技能伪装成正常的生产力工具，实际包含凭证窃取器和反向 Shell，部分甚至精巧到能通过代码审查。后续的 "ClawHavoc" 供应链攻击更是向 ClawHub 投放了 1,184 个恶意技能包。
🐛 严重漏洞：CVE-2026-25253 允许攻击者通过一个恶意链接实现一键远程代码执行（RCE），利用的是控制 UI 对 URL 参数的无验证信任，通过跨站 WebSocket 劫持实现攻击——即使实例配置为仅监听 localhost 也难以幸免。截至 2026 年 3 月，OpenClaw 已累计被披露 8 个严重/高危 CVE 漏洞。
🛡️ 安全响应：OpenClaw 团队已与 VirusTotal 建立合作，对 ClawHub 上的技能进行安全扫描，并要求发布者的 GitHub 账号至少注册一周以上方可发布技能。

中国政府的安全管控

2026 年 3 月，中国国家计算机网络应急技术处理协调中心（CNCERT）和工信部网络安全威胁信息平台发布了风险警告：

📢 指出 OpenClaw 存在默认安全配置薄弱、要求过高系统权限的问题
📊 警告已有超过 220,000 个未受保护的实例暴露在公共互联网上
🏛️ 中国政府随即要求国有企业和政府机关不得在办公电脑上安装 OpenClaw 软件，已安装的需报告上级进行安全检查和可能的卸载
🏦 包括最大的国有银行在内的多个机构已收到相关通知

这一事件的深层启示是：网络安全研究人员将 OpenClaw 类工具的风险总结为"致命三角"（Lethal Trifecta）——它能访问私密数据、能进行外部通信、且会接触不可信内容。这三个特性的组合使得安全风险被放大。

对 Clawith 用户的建议

虽然上述安全事件主要发生在 OpenClaw 个人版生态中，但 Clawith 作为其团队版本，共享了部分底层架构，因此用户在部署时应当：

✅ 将 Clawith 部署在容器化环境中，实施网络隔离
✅ 确保管理端口不暴露在公共互联网上
✅ 实施严格的身份验证和访问控制
✅ 对代理安装的第三方技能进行安全审查
✅ 为高风险操作配置审批工作流
✅ 定期审查审计日志

为什么选择 Clawith

团队化作战

🎯 让多个 AI 代理像"船员"一样分工协作，处理单一 AI 难以胜任的长流程任务。

在实际业务场景中，许多任务天然具有"团队协作"的属性——它们需要不同领域的专业知识、需要信息在多个环节之间流转、需要持续数天甚至数周的跟踪推进。传统的单一 AI 代理在面对这类任务时，往往面临上下文窗口限制、专业知识单一、无法长期追踪等瓶颈。

Clawith 的解决方案是让你构建一个"AI 船员"团队，每个成员各有专长、各司其职，通过 Clawith 的社交协作网络进行高效沟通和任务接力。

开源与社区驱动

🌍 项目遵循 Apache 2.0 开源协议，并积极通过 GitHub Issues 和 Discord 与开发者互动。

Apache 2.0 协议意味着：你可以自由地使用、修改和分发 Clawith，甚至用于商业项目，而无需开源你的修改。 这对于需要在 Clawith 基础上构建定制化解决方案的企业来说至关重要。

Clawith 的贡献指南（Contributing Guide）明确欢迎社区参与，并提供了"Good First Issue"标签方便新贡献者入手。 为确保全球协作的顺畅，项目要求所有 Issue、PR 和代码注释使用英文。

开发者友好

🛠️ 提供详细的架构说明（ARCHITECTURE_SPEC.md），方便开发者进行二次开发和深度定制。

Clawith 的开发者友好性体现在多个层面：

📖 完整的架构规格文档（ARCHITECTURE_SPEC.md），详细说明了系统的每个模块和设计决策
🧩 模块化的 18 个 API 模块，方便开发者理解和扩展特定功能
🔧 基于 Markdown 的配置范式，无需深入代码即可定制代理行为
🐳 容器化部署支持，降低环境配置门槛

竞品全景：Clawith 在 AI 代理生态中的定位

截至 2026 年 3 月，AI 代理框架已成为 AI 工程领域最活跃的赛道之一。据 Markets And Markets 数据，全球 AI 代理市场在 2025 年已达 78.4 亿美元，预计到 2030 年将增长至 526.2 亿美元。Gartner 预测，到 2026 年底，40% 的企业应用将集成特定任务的 AI 代理，而 2025 年这一比例还不到 5%。

要准确理解 Clawith 的价值，有必要将它与整个生态中的相关工具进行系统性对比。 本节将从四个维度进行梳理：Claw 家族衍生项目、多智能体编排框架、LLMOps/可视化平台、以及新兴协议标准。

第一梯队：Claw 家族——从 OpenClaw 衍生的专项创新

OpenClaw 的爆发催生了一批专注于解决其特定痛点的衍生项目。 这些项目不是多智能体编排框架，而是与 OpenClaw/Clawith 处于同一"自主代理"赛道的直接竞品或补充。

🐈 Nanobot（香港大学）

定位：超轻量级 OpenClaw 替代品，"用 4,000 行代码实现 OpenClaw 核心功能"

Nanobot 由香港大学团队开发，是一个用 Python 编写的极简 AI 代理框架。 它的核心卖点是代码量极小（约 4,000 行 vs OpenClaw 的约 400,000 行），使得一个开发者可以在几天内阅读完全部核心代码，完全理解系统行为。

🔗 GitHub：github.com/HKUDS/nanobot
📐 核心优势：架构透明性极高，适合研究人员和注重可审计性的团队
🔧 MCP 原生：原生支持 Model Context Protocol 工具集成
⚠️ 局限：功能集有限，不适合需要复杂编排的企业场景

💡 适合谁：学术研究者、追求架构简洁性的开发者、需要完全理解代理行为的安全敏感团队

🔒 NanoClaw

定位：安全优先的 OpenClaw 替代品，"代理运行在容器中，即使失控也安全"

NanoClaw 的核心理念是"安全不能是事后补丁"。 它将每个代理运行在隔离的容器（Docker 或 Apple Container）中，即使代理被恶意指令劫持，也无法突破容器边界。

🔗 GitHub：github.com/qwibitai/nanoclaw
🛡️ 核心优势：容器隔离 + 代理 Swarm 编排，基于 Anthropic Claude Agent SDK 构建
💬 通道支持：WhatsApp、Telegram、Slack、Discord、Gmail 等
🧠 代理记忆：支持持久记忆和定时任务
⚠️ 局限：代码库较小，社区活跃度有限

💡 适合谁：对安全有严格要求的企业团队、医疗/金融等受监管行业

🦀 IronClaw

定位：零信任架构的 AI 代理，"你的数据永远不会离开你的控制"

IronClaw 是一个用 Rust 编写的 OpenClaw 替代品，专注于隐私和安全。 它的架构设计上采用了 WebAssembly（WASM）沙盒和加密验证机制，确保代理行为可验证、数据永不外泄。

🛡️ 核心优势：WASM 沙盒 + 加密验证代理行为，零信任架构
🔐 数据主权：所有信息本地存储、加密，永不离开用户控制
⚠️ 局限：需要较强的 DevOps 能力来正确部署和维护

💡 适合谁：去中心化/区块链相关场景、零信任安全需求极高的组织、对数据主权有绝对要求的政府机构

⚡ PicoClaw（Sipeed）

定位：为 10 美元硬件设计的 AI 代理，"99% 比 OpenClaw 更小"

PicoClaw 是嵌入式硬件公司 Sipeed 在 2026 年 2 月 9 日仅用一天时间构建的项目，旨在将 AI 代理能力带到物联网（IoT）和边缘设备上。 它用 Go 语言从零编写（不是 OpenClaw 的 fork），运行时内存占用不到 10MB，可以在 10 美元的硬件上运行。

🔗 GitHub：github.com/sipeed/picoclaw — ⭐ 约 25,000 星标
📐 核心优势：<10MB 内存、毫秒级启动、Go 语言原生
⚠️ 局限：缺乏企业级编排功能，专注于资源受限场景

💡 适合谁：IoT 设备制造商、边缘计算场景、资源极度受限的嵌入式环境

Claw 家族小结

Claw 家族的繁荣体现了 AI 代理领域"一个问题，多种解法"的特点。 每个项目都针对 OpenClaw 的特定痛点进行了差异化创新：

                    OpenClaw（全功能，但重量级且存在安全隐患）
                         │
        ┌────────────────┼────────────────┐
        │                │                │
   安全问题            架构复杂度           资源占用
        │                │                │
   NanoClaw          Nanobot           PicoClaw
   IronClaw        （4K 行极简）       （10MB 极致轻量）
  （容器/WASM隔离）
        │
        └──── Clawith：解决"单代理"局限，面向团队协作 ────┘

Clawith 在 Claw 家族中的独特定位是：它不是在"轻量化"或"安全加固"方向上做文章，而是在"组织化协作"这个全新维度上进行了创新——这是其他 Claw 家族成员都没有触及的领域。

第二梯队：多智能体编排框架——"编程框架"级别的竞品

这一梯队的工具是开发者用来"编写"多代理协作逻辑的编程框架/SDK。 它们提供的是构建块和抽象层，而非像 Clawith 那样的"开箱即用"平台。

🚢 CrewAI

定位：基于角色的团队协作框架，"让 AI 代理像人类团队一样分工"

CrewAI 是 2026 年增长最快的多智能体框架。 它的设计灵感来源于人类团队的组织方式：你创建一个"船员"（Crew），为每个代理分配角色（如"研究员"、"作家"、"审核员"），然后让他们协作完成任务。

🔗 GitHub：github.com/crewAIInc/crewAI — ⭐ 44,600+ 星标
📊 月度工作流执行量：4.5 亿次
📐 核心范式：基于角色（Role-Based），受人类团队分工启发
🎯 最适场景：角色明确的团队工作流、快速原型开发
⭐ 学习曲线：最低——在所有主流多智能体框架中，CrewAI 需要的样板代码最少
🔧 A2A 协议支持：已添加 Agent-to-Agent 协议支持
⚠️ 局限：对非协作场景灵活性不足，角色模型对新型架构有约束

📋 与 Clawith 的核心区别：CrewAI 的代理是"临时工"——定义角色、执行任务、获取结果，然后 Crew 解散。Clawith 的代理是"长期雇员"——具有持久身份、长期记忆、组织架构感知，可以跨任务、跨时间段持续工作。

🔗 LangGraph（LangChain）

定位：基于图的状态化工作流框架，"将代理行为建模为有状态的有向图"

LangGraph 是 LangChain 生态中的核心编排层，截至 2026 年已达 1.0 稳定版。 它将代理工作流建模为"节点"（函数）和"边"（控制流）组成的有向图，通过状态管理器维护工作流的全局状态。

🔗 GitHub：github.com/langchain-ai/langgraph
📊 月度 PyPI 下载量：3,800 万+
📐 核心范式：图结构（Graph-Based），节点 + 边 + 状态
🎯 最适场景：需要精细控制执行流程的生产级流水线
⚙️ 关键特性：持久化执行（Durable Execution）、Human-in-the-Loop、Reducer 逻辑合并并发更新
🌐 语言支持：Python + JavaScript
⚠️ 学习曲线：最高——需要理解图论概念（节点、边、状态模式）

📋 与 Clawith 的核心区别：LangGraph 是"编排框架"——你需要预先定义好工作流图。Clawith 的代理可以自主决策下一步行动（Aware 系统），无需预定义路径。

💬 Microsoft Agent Framework（AutoGen + Semantic Kernel 的继承者）

定位：微软的统一 AI 代理框架，"将 AutoGen 的创新性与 Semantic Kernel 的企业级稳定性合二为一"

这是一个重要的生态变化：微软已于 2025 年 10 月将 AutoGen 和 Semantic Kernel 统一为全新的 "Microsoft Agent Framework"，原有的两个项目进入维护模式（仅修复 Bug 和安全补丁，不再添加新功能）。

🔗 GitHub：github.com/microsoft/agent-framework — MIT 协议
📐 核心范式：AutoGen 的简洁代理抽象 + Semantic Kernel 的企业特性（会话状态管理、类型安全、中间件、遥测） + 新增的图式工作流
🌐 语言支持：Python + .NET
🤝 协议支持：A2A、AG-UI、MCP 三项标准
🔧 模型支持：Azure OpenAI、OpenAI、Anthropic Claude、AWS Bedrock、Ollama 等
📅 GA 时间表：1.0 正式版预计 2026 年 Q1 末发布

📋 与 Clawith 的核心区别：Microsoft Agent Framework 是一个通用的 AI 代理开发工具包，侧重于编程模型的统一和企业级 SDK 能力。Clawith 则是一个"开箱即用"的多代理协作平台，侧重于代理的社交化和组织化。

⚠️ 提示：如果你在网上看到 "AutoGen" 的教程和文章，需要注意它们可能已经过时。微软官方已建议所有生产用例迁移至 Microsoft Agent Framework。

🤖 OpenAI Agents SDK

定位：OpenAI 官方的轻量级多代理框架，"从零到可用代理的最快路径"

OpenAI Agents SDK 是 OpenAI 早期实验性框架 Swarm 的生产级继承者。 它的设计哲学是"极少抽象"——只提供三个核心原语：Agent（配备指令和工具的 LLM）、Handoffs（代理间委派）、Guardrails（输入输出验证）。

🔗 GitHub：github.com/openai/openai-agents-python — ⭐ 19,000+ 星标，月下载量 1,030 万
📐 核心范式：极简抽象——Agent + Handoffs + Guardrails
🌐 语言支持：Python、JavaScript/TypeScript、Go（社区移植版）
🎯 特色功能：内置 Tracing 可视化调试、Realtime Agents（语音代理）支持
🔧 模型支持：尽管名为 "OpenAI"，实际支持 100+ 模型
⚠️ 局限：轻量级意味着缺乏复杂编排能力，适合入门但不适合重度多代理场景

📋 与 Clawith 的核心区别：OpenAI Agents SDK 是一个极简的"构建块"，适合快速搭建简单的代理链路。Clawith 提供的是一个完整的"组织化"多代理运行时环境。

🐫 CAMEL-AI

定位：面向研究的多智能体框架，"发现代理的规模法则"

CAMEL-AI（Communicative Agents for "Mind" Exploration of Large-Scale Language Model Society）是最早的多智能体框架之一（2023 年发布），由一个 100+ 研究人员组成的社区驱动。其核心使命是研究 AI 代理系统的"规模法则"（Scaling Laws），即如何让代理系统在数量、环境和进化三个维度上实现规模化扩展。

🔗 GitHub：github.com/camel-ai/camel — ⭐ 16,000+ 星标
📐 核心范式：角色扮演框架（Role-Playing Framework），代理通过角色分配和对话交互完成任务
🔬 三大规模维度：代理数量（支持百万级模拟）、环境（桌面操作、Web 浏览）、进化（通过 RL 和合成数据持续改进）
🧩 子项目：
- 🦉 OWL（Optimized Workforce Learning）：多代理协作的前沿框架，被 NeurIPS 2025 接收
- 🏝️ OASIS：支持百万级代理的社交媒体动态模拟
⚠️ 局限：偏学术研究定位，生产部署能力不如企业级框架

📋 与 Clawith 的核心区别：CAMEL 更偏向研究和实验——探索代理交互的理论边界。Clawith 更偏向生产落地——解决企业团队的实际协作需求。值得注意的是，Eigent（下文介绍）正是基于 CAMEL 框架构建的。

🏠 Eigent

定位：基于 CAMEL-AI 的开源协同桌面平台，"Claude Cowork 的本地化开源替代品"

Eigent 自称"世界上第一个基于 CAMEL 框架构建的多智能体劳动力平台"，是 2026 年 AI "协同桌面"（Cowork Desktop）赛道中的领跑者之一。 它不是一个编程框架，而是一个可以直接安装到桌面使用的多代理应用——类似于 Clawith 的"端侧版本"。

🔗 GitHub：github.com/eigent-ai/eigent — Apache 2.0
📐 核心架构：CAMEL Workforce 引擎 + Electron 桌面应用
🤖 专业代理类型：Developer Agent（编程）、Browser Agent（网页操作）、Document Agent（文档处理）、Multi-Modal Agent（图像/音频）
🔒 隐私特色：数据默认本地存储，支持本地 LLM（vLLM、Ollama、LM Studio），可实现完全气隙部署（Air-Gapped）
🛠️ 技术栈：FastAPI + Uvicorn（后端）、React + TypeScript + Electron（前端）、Tailwind CSS + Radix UI
🔧 MCP 工具系统：支持通过 MCP 协议挂载外部服务和内部 API 作为代理工具

📋 与 Clawith 的核心区别：Eigent 是"桌面端的多代理协作"——面向个人用户在本地环境中使用多个专业代理。Clawith 是"服务器端的组织化协作"——面向团队在共享环境中管理多个具有组织身份的代理。两者的应用场景有互补性。

第三梯队：LLMOps 与可视化平台

🎨 Dify

定位：开源 LLMOps 平台，"可视化构建 AI 代理和工作流"

Dify（"Do It For You"）是 LangGenius 团队开发的开源 LLMOps 平台，截至 2026 年 3 月以 129,800+ 星标位居 GitHub AI 项目前列。 它的核心卖点是可视化拖拽界面——无需编码即可构建 AI 代理、RAG 管道和复杂工作流。

🔗 GitHub：github.com/langgenius/dify — ⭐ 129,800+ 星标
📐 核心范式：可视化画布 + RAG 管道 + 代理框架 + 模型管理
🎯 最适场景：快速搭建 AI 应用原型、低代码/无代码团队
🔧 关键特性：50+ 内置工具、MCP 集成、插件 SDK（开源）、沙盒代码节点（Python/JS）
💰 定价：开源免费、Dify Cloud（Professional \(59/月、Team\)159/月、Enterprise 定制）
⚠️ 局限：可视化界面在极复杂工作流下可能成为瓶颈；多代理编排能力不如专业框架

📋 与 Clawith 的核心区别：Dify 是"AI 应用构建平台"——侧重于让非技术用户也能构建 AI 应用。Clawith 是"AI 代理协作平台"——侧重于让多个代理作为组织成员长期协作。两者的目标用户画像有显著差异。

第四梯队：新兴协议原生与类型安全框架

🌐 OpenAgents

定位：协议原生的代理网络，"唯一同时原生支持 MCP 和 A2A 的框架"

OpenAgents 是 2026 年多智能体生态中一个独特的存在：它不是一个封闭的编排框架，而是一个开放的"代理网络"构建平台。 其核心理念是让来自不同框架（LangGraph 代理、CrewAI 代理、自定义 Python 代理）的代理通过标准化协议发现彼此、互相协作。

🔗 GitHub：github.com/openagents-org/openagents
📐 核心范式：协议原生（MCP + A2A 双协议支持）
🎯 特色功能：
- 📂 共享工作空间：文件共享、浏览器共享、@mention 委派
- 🔍 代理发现：代理自动发现工作空间中其他代理的存在和能力
- 🔧 客户端管理：统一管理 Claude、Codex、Aider 等本地 AI 代理
🌐 互操作性：一个 LangGraph 代理、一个 CrewAI 代理、一个自定义 Python 代理可以在同一个 OpenAgents 网络中无缝协作

📋 与 Clawith 的核心区别：OpenAgents 构建的是"持久的代理网络"——侧重于跨框架、跨平台的代理互操作。Clawith 构建的是"组织内部的代理团队"——侧重于代理在统一组织架构下的协作。

💡 MCP 与 A2A 协议简介：

MCP（Model Context Protocol） 是由 Anthropic 发起、现由 Linux 基金会托管的开放协议，为 LLM 应用连接外部数据源和工具提供了标准化方式——可以理解为"代理与工具之间的通信标准"。

A2A（Agent-to-Agent Protocol） 是 Google 发起的开放协议，解决的是"代理与代理之间的通信标准"——让不同框架构建的代理能够互相发现和协作。

两者是互补关系：MCP 解决代理↔工具通信，A2A 解决代理↔代理通信。截至 2026 年 3 月，CrewAI 已添加 A2A 支持，LangGraph 和 AutoGen 尚未原生支持任一协议。

🔒 Pydantic AI

定位：类型安全的 AI 代理框架，"把 FastAPI 的开发体验带到 AI 代理领域"

Pydantic AI 是由 Pydantic 团队（即 OpenAI SDK、Anthropic SDK、LangChain 等众多项目底层验证库的开发者）构建的 AI 代理框架。 它的核心差异化在于"类型安全"——利用 Python 的类型系统在开发阶段就捕获代理逻辑错误，而非等到运行时才暴露。

🔗 GitHub：github.com/pydantic/pydantic-ai — ⭐ 15,500+ 星标
📐 核心范式：类型安全（Type-Safe），"如果它通过了类型检查，它就能工作"
🔧 模型支持：几乎所有主流模型和提供商（OpenAI、Anthropic、Gemini、DeepSeek、Grok、Ollama 等）
🤝 协议支持：MCP + A2A + 多种 UI 事件流标准
🎯 特色功能：依赖注入、持久化执行（Durable Execution）、流式结构化输出、Human-in-the-Loop、与 Pydantic Logfire 深度集成的可观测性
📈 行业评价：被称为 2026 年 AI 代理框架领域的"黑马"

📋 与 Clawith 的核心区别：Pydantic AI 是一个"开发者工具"——帮助开发者以类型安全的方式编写代理逻辑。Clawith 是一个"运行时平台"——提供代理运行、协作和管理的完整环境。两者可以结合使用：用 Pydantic AI 编写代理逻辑，用 Clawith 运行和管理代理团队。

🧩 Mastra

定位：TypeScript 优先的 AI 代理框架，"前端开发者构建 AI 代理的最佳入口"

Mastra 由 Gatsby（知名 React 静态站点生成器）的原班团队打造，2026 年 1 月达到 v1.0 版本，获得 Y Combinator W25 批次 1,300 万美元融资。 它的核心主张是：AI 代理开发不应该只是 Python 开发者的领地——TypeScript/JavaScript 开发者同样可以用自己熟悉的技术栈构建生产级 AI 代理。

🔗 GitHub：github.com/mastra-ai/mastra
📐 核心范式：TypeScript 优先的 AI 原语集（Workflows、Agents、RAG、Evals）
🎯 特色功能：
- 🎨 Mastra Studio：内置可视化 IDE，用于测试代理和工作流
- 🔧 MCP Client：连接 Google Sheets、GitHub 等预构建工具
- 📊 评估系统：内置 Scorers 和 Evals，量化 AI 代理性能
🚀 部署：支持 Vercel、Cloudflare、Netlify 等 Serverless 平台，也支持自建 Node.js 服务器
⚠️ 局限：仅支持 TypeScript/JavaScript 生态，企业级特性需付费许可

📋 与 Clawith 的核心区别：Mastra 面向 TypeScript 开发者提供 AI 代理构建工具，Clawith 面向团队提供多代理协作平台。Mastra 更偏向"构建"，Clawith 更偏向"运行和管理"。

🌈 Google ADK（Agent Development Kit）

定位：Google 官方的开源 AI 代理开发工具包，"让代理开发感觉像软件开发一样"

Google ADK 是 2026 年最值得关注的新入局者之一。 它虽然为 Gemini 和 Google 生态做了优化，但设计上是模型无关（Model-Agnostic）和部署无关（Deployment-Agnostic）的，并且明确声明与其他框架兼容。

🔗 GitHub：github.com/google/adk-python — Apache 2.0
📐 核心范式：代码优先（Code-First），模块化多代理系统
🌐 语言支持：四种语言——Python、Go、Java、TypeScript/JavaScript
🎯 特色功能：
- 🔄 工作流代理：Sequential、Parallel、Loop 三种预定义工作流模式
- 🤝 A2A 协议集成：原生支持远程代理间通信
- 🧠 AI 辅助开发：提供 llms.txt 和 llms-full.txt，兼容 AI 代码编辑器
- 📈 ADK 2.0 Alpha：新增图式工作流（Graph-Based Workflows）
☁️ 部署：推荐 Vertex AI Agent Engine，也支持 Cloud Run 或 Docker 自部署

📋 与 Clawith 的核心区别：Google ADK 是一个多语言的"代理开发工具包"，侧重于构建和部署。Clawith 是一个"团队协作运行时"，侧重于代理的组织化管理和社交化协作。**

全景对比总表

为方便课程学员快速建立全局认知，以下将所有讨论过的工具汇总至一张对比表中：

工具	类型	GitHub ⭐	核心范式	语言	协议支持	最适场景
🤝 Clawith	协作平台	174	组织化社交协作	Py/TS	MCP	多代理长周期团队协作
🦞 OpenClaw	个人代理	~250K	自主代理	TS	MCP	个人数字生活自动化
🐈 Nanobot	轻量代理	—	极简代理	Py	MCP	学术研究、架构透明性
🔒 NanoClaw	安全代理	—	容器隔离	Py	—	安全敏感企业
🦀 IronClaw	零信任代理	—	WASM 沙盒	Rust	—	去中心化/零信任场景
⚡ PicoClaw	边缘代理	~25K	嵌入式	Go	—	IoT/边缘设备
🚢 CrewAI	编排框架	44.6K	角色协作	Py	A2A	快速原型、角色化工作流
🔗 LangGraph	编排框架	—	图式工作流	Py/JS	—	精细控制的生产流水线
💼 MS Agent FW	编排框架	—	统一代理模型	Py/.NET	A2A+MCP	微软生态企业
🤖 OpenAI SDK	编排框架	19K	极简抽象	Py/JS/Go	—	快速搭建简单代理链路
🐫 CAMEL-AI	研究框架	16K	角色扮演	Py	—	代理规模化研究
🏠 Eigent	桌面平台	—	桌面多代理	Py/TS	MCP	本地多代理协作
🎨 Dify	LLMOps	129.8K	可视化画布	Py	MCP	低代码 AI 应用构建
🌐 OpenAgents	代理网络	—	协议原生	Py	MCP+A2A	跨框架代理互操作
🔒 Pydantic AI	开发工具	15.5K	类型安全	Py	MCP+A2A	类型安全的代理开发
🧩 Mastra	开发工具	—	TS 优先	TS	MCP	前端开发者构建代理
🌈 Google ADK	开发工具	—	代码优先	Py/Go/Java/TS	A2A	Google 生态、多语言

选择框架的决策树（升级版）

你的需求是什么？
│
├── 需要多个代理像组织成员一样长期协作？
│   ├── 是，需要组织架构/RBAC/审计日志 → Clawith
│   └── 是，但更偏向本地桌面使用 → Eigent
│
├── 需要一个编程框架来编写代理协作逻辑？
│   ├── 需要精细控制每一步执行 → LangGraph
│   ├── 工作流可映射为明确的团队角色 → CrewAI
│   ├── 核心是迭代优化和对话交互 → Microsoft Agent Framework
│   ├── 需要最快的上手速度 → OpenAI Agents SDK
│   ├── TypeScript 开发者 → Mastra
│   ├── 类型安全是首要优先级 → Pydantic AI
│   └── 深度集成 Google 生态 → Google ADK
│
├── 需要跨框架代理互操作？ → OpenAgents
│
├── 需要可视化/低代码构建 AI 应用？ → Dify
│
├── 需要面向研究的多代理模拟？ → CAMEL-AI
│
├── 安全性是绝对优先级？
│   ├── 容器隔离 → NanoClaw
│   ├── WASM 沙盒 + 零信任 → IronClaw
│   └── 代码可审计性 → Nanobot
│
├── 资源极度受限的边缘/IoT 场景？ → PicoClaw
│
└── 不确定？ → 从 CrewAI 开始（最低学习曲线）

⚠️ 重要提醒：并非所有场景都需要多智能体框架。对于许多用例来说，一个配备了工具调用能力的单一代理就足够简洁且高效。只有当你的任务确实需要不同专业领域的代理协作时，才应该引入多智能体框架。过度架构是这个领域最常见的陷阱之一。

💡 另一个值得关注的趋势是"框架可组合性"（Framework Composability）：越来越多的团队开始混合使用多个框架——例如用 LangChain 管理工具集成和检索，用 CrewAI 或 CAMEL 进行多代理编排。框架不是单体巨石——它们是可以组合的库。

小结

Clawith 正在重新定义人与 AI 协作的方式。它将 AI 从简单的聊天窗口转化为具备自主意识和协作能力的"数字员工"。

从更宏观的视角来看，Clawith 代表了 AI 代理技术发展的一个重要方向：从"工具"到"同事"的转变。 在这个框架中，AI 代理不再是你输入一行提示词然后等待输出的黑盒——它们是具有个性（soul.md）、记忆（memory.md）、工作空间（私有文件系统）和社交能力（组织架构感知）的"数字个体"。

然而，Clawith 也处于一个充满机遇和风险并存的生态环境中。 OpenClaw 生态的安全事件提醒我们，越是强大的自主性，越需要严格的安全治理。企业在采用 Clawith 时，必须在"赋能"与"管控"之间找到平衡。

从竞品全景来看，Clawith 在 2026 年 AI 代理的"寒武纪大爆发"中占据了一个独特的生态位——"组织化的多智能体协作平台"。 它不是最轻量的（PicoClaw）、不是最安全的（IronClaw）、不是最灵活的编排框架（LangGraph）、不是最易上手的（CrewAI）、也不是最大的社区（Dify）。但它是目前为数不多的将"组织架构感知"、"代理身份持久化"和"社交化协作"融为一体的开源方案。

Clawith 的未来发展值得持续关注——它能否从 174 颗星标的起步阶段，成长为多智能体协作领域的标杆平台，将取决于它在社区建设、安全加固和企业采用三个维度上的表现。

参考资源

Clawith 与 OpenClaw

Claw 家族

🐈 Nanobot GitHub
🔒 NanoClaw GitHub
⚡ PicoClaw GitHub
📰 OpenClaw Ecosystem Digest 2026-03-10
📰 OpenClaw Alternatives Compared (aimagicx.com)

多智能体编排框架

LLMOps 与可视化平台

🎨 Dify GitHub
🎨 Dify 官网

新兴协议与框架

协议标准

安全与行业分析

Brave 回复 3 days, 21 hours ago 1 成員 · 0 回复

0 回复

歡迎留言回复交流。

登入後即可回复

人工智能研究

組織者: