Clawith 能补上 OpenClaw 的组织短板吗

这是我的第 228 篇原创文章

作者｜柏导

Clawith 官网把自己叫作“OpenClaw for Teams”，说 OpenClaw 让个人得力，Clawith 要把这件事推到组织里去；而 OpenClaw 官方文档对自己的定位是：你自己机器上的自托管网关，是给开发者和 power user 用的个人 AI 助手，网关是 session、routing 和 channel connection 的单一事实源。两边的话一对，差别就出来了：一个先天是“我”和“我的代理”，一个想补的是“我们”和“我们的代理”。

OpenClaw 不是不能多 agent，它本来就有 multi-agent routing，每个 agent 都有自己的 workspace、state 和 session store。但它的安全文档写道：一个 Gateway 默认对应一个受信任的操作者边界，不建议让多个互不信任的人共用一个网关；如果一个 agent 收多个 DM，还应该开 secure DM mode，不然上下文可能串到一起，Alice 的事被 Bob 接过去。也就是说，OpenClaw 的多人能力更像“一个人养几只手”，不是“几个人共用一家公司”。这正是 Clawith 想补的缺。

把 Clawith 代码和文档对起来看，它是另起了一层组织控制面。每个 agent 有 persistent identity、long-term memory、自己的 workspace；有 Aware 体系，能维护 focus item，自建 trigger，自改日程；有 Plaza，像组织里的信息广场；有 enterprise governance，讲配额、审批、审计、知识库；还能从 Smithery 和 ModelScope 的 MCP registry 动态找工具、装工具、做 skill。

它的技术栈不花哨。前端是 React 19、Vite、TypeScript、Zustand、TanStack Query；后端是 FastAPI、WebSocket、JWT、异步 SQLAlchemy，底下挂 PostgreSQL 或 SQLite，再配 Redis 和 Docker。应用启动时会先建表，再 seed 默认 tenant、内置工具、agent template、skill、默认 agent，然后起 trigger_daemon 和几路渠道流任务，像 Feishu、DingTalk、WeCom。README 还写得很实在：agent 的 workspace 数据直接落在宿主机 backend/agent_data// 目录里。也就是说，Clawith 从第一天起就不是单纯聊天页，它把“长期运行的后台工人”当正经对象来对待。

这类项目，最老实的地方是数据库。Clawith 里有 tenant，明说它是 multi-tenancy isolation boundary；有 agent，明说它是 digital employee，并分成 native 和 openclaw 两类；有 participant，把 user 和 agent 统一成一等身份；有 chat_session，把人与 agent、agent 与 agent 的对话都纳进一个模型里；有 org_departments 和 org_members，把组织结构落地；有 task，把 todo 和 supervision 放在一个表里；有 trigger，把 cron、once、interval、poll、on_message 这些自动唤醒条件写进去。一个产品肯不肯进组织，不是看首页写不写 enterprise，而是看它是不是把“组织”“关系”“职责”“记账”这些脏活累活写进 schema 里。Clawith 这一点是做了的。

Agent 这个模型写得很露骨。它不只存名字、头像和角色描述，还存 creator_id、tenant_id、agent_type、api_key_hash、openclaw_last_seen、status、container_id、container_port、primary/fallback model、autonomy_policy、token 配额、max_tool_rounds、max_triggers、heartbeat 周期、active hours、timezone、expiry、每天 LLM 调用上限。这里头有两层意思。第一，它把代理当成一个可运维的运行单元，不单是一个 prompt。第二，它把治理嵌到对象本身，不是外面再包一层制度文件。连默认 autonomy_policy 都写好了，读文件是 L1，写 workspace 是 L2，发外部消息、改 soul、删文件、财务操作是 L3。再往下看，AgentPermission 也不是一句空话，scope 分 company、department、user，access_level 分 use 和 manage。官网说 RBAC，不完全是拿来做样子的。

Clawith 最有意思的地方，在它怎么把 OpenClaw 接进来。代码里有一整套 gateway API，明说是给 OpenClaw agent 通信用的。远端 agent 用 X-Api-Key 认证，平台不存明文，只存 sha256 hash。OpenClaw 这边靠 /gateway/poll 轮询待办消息，平台会把 pending 改成 delivered，顺手更新 openclaw_last_seen 和 status；轮询结果里不只给消息，还给最近十条对话 history，以及 relationships，把同事名字、关系、可用渠道一起喂过去。agent 做完事，再用 /gateway/report 回报结果；如果原消息来自另一个 agent，平台会再把 reply 写回 gateway_message，让发起方在下次 poll 取到。要主动发消息，也走 /gateway/send-message，既能对 agent，也能对人。更细一点看，/gateway/setup-guide/{agent_id} 甚至会直接吐出一份给 OpenClaw 用的 clawith_sync skill 文件，再加一条 heartbeat 指令，叫它每次心跳时都去查 Clawith inbox。这个桥接思路很清楚：OpenClaw 负责个人侧、边缘侧、渠道侧的常驻能力，Clawith 负责组织侧、协同侧、治理侧的控制面。

这里还有一个值得记的细节。Clawith 里其实有两条协作路径。collaboration.py 那一条，委托任务时会直接给目标 agent 建一个 Task，要求对方 status 必须是 running；发 agent-to-agent 消息时，会把消息写进对方 workspace/inbox/ 目录下的 Markdown 文件，再记一条 AuditLog。Gateway 那一条，则是把消息塞进数据库消息队列，让 OpenClaw 端去 poll。为了让双向对话不乱，gateway 还会把双方 agent ID 排序后生成稳定的 uuid5 session，保证谁先开口都落到同一个 ChatSession 里。也就是说，它的架构思路已经是统一的——代理互相委托、互相咨询——但实现层还带一点过渡味道：本地协作偏文件箱，远程协作偏消息队列。这不算坏事，反而说明作者是在先把路走通，再慢慢收口成总线。只是企业级落地时，最终还是要把这些路径统一，不然审计、重试、SLA 和权限边界都会变复杂。

组织感这件事，它也不是靠形容词。org.py 明写了部门和成员是从 Feishu 同步来的；org_sync_service.py 里能看到它去调 Feishu 的部门和用户接口，再把同步回来的 member 绑定到 tenant，并尽量对上平台里的 User。官网也在企业能力里列了 Feishu / Lark ，说每个 agent 都有自己的 Feishu bot，支持 DM、群 @，还有 SSO。再加上 Tool 清单里确实有 Feishu Message、Agent Message、Task Manager、Document Reader、Code Executor、Resource Discovery，你就能明白这套东西为什么一眼看过去就很偏中国团队、偏飞书工作流：它想先站住一个最常见的组织入口，再往外扩。

治理部分。AutonomyService 里，L1 直接执行，L2 执行后通知创建者，L3 先建 ApprovalRequest，再挡住操作，等人批。批通过以后，服务会直接调工具执行器，不再重走 autonomy check；通知路径既走 Web，也能走 Feishu 文本或审批卡片。配合 agent 自带的 token、trigger、poll interval、webhook rate、LLM calls 上限，和官网说的 audit logs、dangerous-operation approvals、usage quotas，是能对得上的。对于企业来说，最怕的是它什么时候能自己干，什么时候必须叫人看一眼。Clawith 这条线，至少已经从概念走到了可运行的代码。

所以，团队版 OpenClaw 到底有没有企业市场的价值？有，而且价值不小。因为 OpenClaw 自己把边界讲明白了：它适合个人、自托管、单一受信任操作者边界；一旦进入多人、多渠道、多上下文共享场景，就得格外小心 secure DM、trust boundary 和 session isolation。Clawith 正好补上这些企业需要但个人工具通常不做的东西：tenant、org、permission、approval、audit、knowledge base、task board、shared feed、channel bot identity。换句话说，OpenClaw 擅长“把 AI 代理放到你身边”，Clawith 想做的是“把 AI 代理放进你的组织图里”。

但话说回来，代码里也露了几处还要补的地方。第一，README 和官网说 trigger 有六种，含 webhook，可 trigger 模型注释里目前列出来的是五种，没有 webhook；这可能是 webhook 走了别的实现，也可能是文档先跑在前面。第二，list_collaborators 的注释说返回同企业可协作 agent，可目前查询条件只是排除自己，再筛 running/stopped，没有直接把 tenant 条件钉死；也许外层还有防线，但这段本身值得复核。第三，给 human 发 Feishu 消息的 fallback 路径里，如果当前 agent 没有自己的 channel config，会去抓任意一条 channel == "feishu" 的配置，至少代码里没看见 tenant 约束，这对严格多租户是要谨慎的。

这就带出一个判断。Clawith 今天更像一个可用的“组织代理控制层”，还不像一个完备的“企业 AI 操作系统”。对十来个人、几十个人的团队，它是很有落地价值的，特别是已经把 Feishu/Lark 当中枢、愿意自托管、又希望 agent 真能长期跑起来的团队。它把最难啃的一块先啃了：让 agent 成为组织结构里的一个节点，有身份、有权限、有工作台、有同事、有时钟、有审计。可要是到了强监管行业、复杂集团、多地区数据隔离、统一身份目录、审计外送、密钥托管、灾备和高可用都得齐备的场景，Clawith 现在更像一辆能上路的车，还不是能直接跑跨省长途的车。

反过来讲，团队版 OpenClaw 用来构建一人公司，倒很像它眼下最顺手的用法。原因很简单：一人公司最大的优势，在信任边界单一。OpenClaw 那套“一个操作者，一个边界”的假设，在这里几乎原封不动成立；Clawith 多出来的 tenant、approval、audit、task、plaza、trigger、skill、tool discovery，则恰好能把一个人拆成几种角色：市场、研究、销售、交付、运营、财务助手、情报员。每个 agent 有自己的 soul.md、memory.md、workspace 和长期上下文；能定时巡检，能自己建 trigger，能把消息发给人，也能委托别的 agent；广场像内部简报，任务板像低配 PMO，审计像工作日志。一个人盯着几只 agent 干活，这比一个人盯着一个大模型聊天，离“公司”更近。

Clawith 能做的是组织化分工、持续运行、跨渠道沟通、知识沉淀和治理留痕；它不能自动替你完成真实世界的责任转移。钱还是要你签，合同还是要你看，关键客户关系还是要你维护，税务和合规还是要你背。说到底，它更像一个把“个人 AI 助手”抬升成“微型 AI 团队”的框架，还不是一台开机即自治的公司机器。对一人公司，这已经很有用；因为一人最缺的是不会累的分身。

所以我的结论是：Clawith 是一个可行的解决方案。它并不是简单把 OpenClaw 变成多人聊天室，是把 OpenClaw 放在边缘，把组织、协作、治理和长期运行放在中枢。对企业市场，它的真正是“可被管理的 AI 劳动力”；对一人公司，它的真正价值是“把你从一个人，变成一个有编制的组织”。这条路是走得通的，尤其适合 AI 原生小团队、内容与研发驱动的创业项目、以及愿意先从 Feishu/Lark 工作流起步的公司。只是要进大企业，下一步得补隔离边界、身份体系、消息总线、可观测性和交付级的可靠性。