说实话，研究过 Clawdbot 源码的人可能不到这个圈子里的 1%，但凡认真看过的都会有种"卧槽原来可以这么做"的感觉。
我去年底开始关注这个项目，从几万星追到现在十几万星，代码翻了不下五遍，中间还照着它的架构重构过自己的一个小项目，踩了不少坑也学了不少东西。
很多做 AI Agent 的创业公司花几百万请架构师，设计出来的东西还不如这个开源项目的十分之一精妙。不是我吹，是这玩意儿真的把"个人 AI 助手"这个赛道里能踩的坑都踩了一遍，然后给出了一套非常成熟的解决方案。
记忆系统设计
做过 AI Agent 的都知道，记忆是个老大难问题。大模型本身是无状态的，每次对话都是从零开始，你昨天跟它说过什么它今天全忘了。
市面上常见方案的局限性
- ✗把历史对话全塞进 context，直到塞爆 token 限制
- ✗用向量数据库做 RAG 检索，但检索质量不稳定
Clawdbot 的两层记忆架构
第一层：Daily Notes
按日期存的 Markdown 文件，每天一个，记录当天发生的事情、做的决策、完成的任务，是纯 append-only 的流水账。
第二层：Long-Term Memory
MEMORY.md 文件，存的是从日常记录里提炼出来的重要信息：用户偏好、经常出现的上下文、关键决策、踩过的坑。
💡 为什么好使？
因为它区分了"流水"和"沉淀"。就像人的记忆：昨天中午吃了什么你可能忘了，但你知道自己不吃香菜、对海鲜过敏。Daily Notes 负责记流水，MEMORY.md 负责存沉淀。而且用 Markdown 存储，人能直接看、能编辑、能用 git 管理版本。
插件和 Skills 系统设计
现在做 AI Agent 的一个普遍思路是"大而全"——恨不得把所有功能都内置进去。这种思路的问题是什么？维护成本高得离谱，功能越多 bug 越多。
🎯 Clawdbot 的思路：核心精简、外围开放
- • 核心系统只做最基础的事情：消息路由、模型调用、上下文管理、安全沙箱
- • 其他所有功能都通过插件和 Skills 来实现
- • 官方只维护核心的 9 个，社区贡献 264+ 个 Skills
工程化的 Skills 系统
每个 Skill 就是标准格式的配置文件加执行脚本，有 manifest 描述元信息，有 input/output schema 定义接口，有 sandbox 配置指定权限边界。照着模板填就行，一两个小时就能写一个可用的 Skill。
安全沙箱机制
AI Agent 和普通 chatbot 最大的区别是什么？是它能执行真实操作——跑命令、改文件、发请求、调 API。这个能力是双刃剑。
✅ Clawdbot 的多层防护
- • 默认情况下 Agent 执行任何敏感操作都需要用户确认
- • 文件操作只能在指定目录里进行
- • 网络请求有白名单限制
- • Docker 部署：非 root 用户、文件系统可只读、capabilities 全部 drop
⚠️ 务实的安全策略
Clawdbot 明确表示不试图防 prompt injection（因为以现在的技术防不住）。思路是：假设 Agent 会被"骗"，然后在执行层面做限制，让 Agent 就算被骗了也干不了太出格的事。
多平台架构
Clawdbot 支持 WhatsApp、Telegram、Discord、Slack、iMessage、Signal、Teams……基本上你能想到的聊天平台它都支持。
🔌 WebSocket Gateway 架构
搞了一个 WebSocket Gateway 作为中心枢纽，所有平台的消息都先转成统一的内部格式进 Gateway，处理完再转成各平台的格式出去。
这就是经典的适配器模式。每个平台对应一个 Channel Adapter，只负责格式转换这一件事，业务逻辑一行都没有。加新平台就写新 Adapter，不用动现有代码。
CLI 系统
Clawdbot 有 100+ 个 CLI 子命令，能干的事情包括：管理 Skills、配置插件、调试 Agent、查看日志、管理记忆、做安全审计、导入导出数据。
💻 为什么 CLI 重要？
对开发者用户来说，能用命令行搞定的事情就别让我点鼠标。每个命令都有详细的 help，输出格式支持 JSON 方便脚本处理。这才是懂用户的产品。
个人感受
研究 Clawdbot 最大的收获不是学会了什么具体技术，而是看到了一种做产品的态度：
不追求功能多，追求每个功能都做对
不追求大而全，追求核心足够稳
不追求理论完美，追求工程可行
如果你在做 AI Agent 相关的东西，真心建议花点时间把 Clawdbot 的代码过一遍。不是说要照搬它的实现，而是去理解它为什么这么设计、它踩过哪些坑、它怎么在各种约束下做取舍。这些东西比学会用某个框架的 API 有价值多了。