开源 Agent 架构深度拆解：核心认知与工程决策

AI 数据通道：JSON·Markdown

六条核心认知 #

在拆任何一个产品之前，先讲清楚六条原理。它们不是某个框架的特性，而是所有 Agent 系统都要面对的根本矛盾。后面的六个产品拆解，都是在这些原理上搭积木。

---

认知一：Agent 的本质是 Loop，不是 Chat #

很多人把 Agent 理解为”带工具的聊天机器人”。这是错的。

聊天是请求-响应：你问 → 它答 → 结束。

Agent 是闭环控制系统：感知 → 决策 → 执行 → 观察结果 → 再决策。和自动驾驶的控制循环是同一类东西——传感器输入 → 规划 → 操作执行器 → 感知环境变化 → 重新规划。

感知（signal）→ 检索（search）→ 决策（reason）→ 执行（act）→ 观察（observe）
     ↑                                                                   ↓
     └──────────────────  状态更新（state update）  ←───────────────────┘

理解这一点，就能理解为什么 2026 年所有成熟的 Agent 框架都在做同一件事：把 Loop 工程化。

• 早期的 agent 是”单轮 RAG + Function Calling”——本质上还是聊天，只是多了一步调工具
• 现在的 agent 是持续的闭环——信号捕获、上下文检索、记忆写入、知识链接、定时任务，每个环节都是可调度的工程对象

产品	Loop 的角色
OpenClaw	Gateway 是 Loop 的控制面
Hermes	自学习闭环是 Loop 的自我改进
GBrain	Dream cycle 是 Loop 的离线整理
ZeroClaw	SOP 引擎是 Loop 的事件驱动扩展

它们都在解决同一个问题：怎么让 Loop 可靠、持续、可观测地运转。

---

认知二：记忆有两种，程序性记忆才是”聪明” #

人脑有两种记忆：

• 陈述性记忆——“知道什么”（巴黎是法国首都）
• 程序性记忆——“知道怎么做”（骑自行车）

当前大部分 Agent 的”记忆”是陈述性的——记住你说了什么、聊过什么。Hermes 的突破在于：它做的是程序性记忆——完成复杂任务后自动把成功路径沉淀为可复用 skill，skill 在使用中持续改进。

区别是巨大的。陈述性记忆让 agent”想起”你上次说了什么。程序性记忆让 agent”会做”它上次不会的事。前者是检索增强，后者是能力增长。

陈述性记忆：对话 → 存储 → 检索 → "你上次说过喜欢暗色模式"
程序性记忆：任务 → 执行 → 成功 → 提取路径 → 沉淀为 skill → "我学会了怎么帮你部署博客"

Mem0 的 LoCoMo 91.6 分和 LongMemEval 94.8 分解决的是陈述性记忆的效率问题。Hermes 的 skill 自创建解决的是程序性记忆的生成问题。两者不是竞争，是不同层次：

	解决的问题	效果
Mem0	记忆效率	让 agent”记得牢“
Hermes	能力增长	让 agent”学得会“

---

认知三：安全是地基，不是功能 #

给 agent 接了 bash 工具，就等于给了它 root 权限。一条恶意消息可以让它执行 rm -rf /。

大多数框架的做法是”加个审批弹窗”——这不够。审批是应用层防护，如果 agent 绕过了应用层（通过 prompt injection 让它自己点确认），就完全暴露了。

ZeroClaw 的做法是纵深防御：

应用层审批（"你确定要执行这个命令吗？"）  ← 可被 prompt injection 绕过
     ↓ 失效时
容器隔离（Docker）                       ← 容器逃逸 = 完全暴露
     ↓ 失效时
内核沙箱（Landlock/Seatbelt）             ← 进程逃逸后内核仍拒绝
     ↓ 审计时
密码学回执                               ← 不可篡改的操作证据

单层防御的失效概率是 P，三层叠加是 P³。这不是过度设计——agent 有文件系统、浏览器、shell 的完整访问权时，任何单层防御的失效都是灾难性的。

---

认知四：能不用 LLM 就不用 #

LLM 擅长理解和生成，不擅长提取和匹配。

项目	做了什么	省了什么
GBrain	纯模式匹配从 [[wiki/people/bob]] 提取实体关系	146,646 页 × 每页 N 条边的 LLM 调用
Mem0	实体链接和嵌入预计算，检索时三路并行打分	检索时不调 LLM，只在写入时用一次
smolagents	Code = Action 让 LLM 一次输出完整程序	减少 30% 的 LLM 调用

架构设计的第一步是画一条线——哪些环节用 LLM，哪些环节不用。用 LLM 做不用 LLM 的事，既慢又贵又不可靠。

✅ 该用 LLM：理解意图、生成答案、综合多源信息、写代码
❌ 不该用 LLM：关键词匹配、实体提取（规则可做）、格式转换、排序、过滤

---

认知五：写入要快，检索要准 #

这是 Mem0 最核心的架构判断。

传统记忆方案是多轮的，每步一次 LLM 调用：

1. 提取记忆
2. 与现有记忆比对
3. 决定更新/合并/删除
4. 写回

4 步 = 4 倍成本和延迟。

Mem0 的 ADD-only 方案：一次 LLM 调用提取即存储，不管之前有没有。记忆只增不改。代价是可能积累冗余，但查询时用多信号检索（语义 + BM25 + 实体 + 时间）来弥补。

传统：  写入慢（4 步）→ 检索快（数据干净）→ 总成本高
ADD-only：写入快（1 步）→ 检索准（多信号融合弥补冗余）→ 总成本低

这和数据库的 WAL（Write-Ahead Log）+ checkpoint 是同一个思路——写入时只追加日志（快），定期做 checkpoint 合并（慢但彻底）。GBrain 的 dream cycle 也是同一个模式。

通用原则：高写入低查询的系统，写入追求简单，检索追求精准。 不要在写入时追求完美——那会让每次写入都变成一个复杂的事务。

---

认知六：框架是 runtime 可以换，记忆和 skill 是资产不应该换 #

37 个 Agent 框架中大部分会在 1-2 年内消亡。但你的记忆和 skill 是积累的资产。

会消亡的	会留下的
框架、runtime、编排引擎	记忆（Mem0）
具体某个 agent 平台	skill（agentskills.io）
可视化工作流画布	内容（PDC/llms.txt）

• Mem0 把记忆独立成服务——换 agent 框架不丢记忆
• agentskills.io 把 skill 标准化——Hermes 的 skill 理论上可以迁移到其他兼容框架
• OpenClaw 的 SOUL.md/AGENTS.md/TOOLS.md 是 Markdown 文件——换框架时这些文件可以手动迁移

这不是选型建议，是资产意识——你在哪个框架上投入的 skill 和记忆，才是你真正的竞争壁垒。

---

搭积木：六个产品的工程实现 #

以上六条认知是地基。以下六个产品是地基上的建筑——每个产品选择了不同的路来解决这些根本矛盾。拆开引擎盖，看的是原理如何变成代码。

---

OpenClaw：把 Loop 做成控制面 #

380k star · TypeScript · 解决认知一（Loop 工程化）的标杆

OpenClaw 的核心决策是 Gateway 控制面模式——来自 Kubernetes 的设计哲学：控制面（会话/工具/事件/沙箱）和数据面（消息渠道收发）分离。

消息渠道（24+ 适配器）          ← 数据面：只管收发
  WhatsApp / Telegram / WeChat / QQ / 飞书 ...
        ↓
   Gateway 控制面               ← 控制面：Loop 的调度中心
        ↓
   Agent 工作区                  ← 执行面：SOUL.md + AGENTS.md + TOOLS.md
        ↓
   Skills（ClawHub）             ← 能力层：程序性知识的复用

决策一：渠道是适配器，不是一等公民 #

Discord、微信、Telegram 都只是适配器，不触碰 agent 逻辑。换渠道 = 换适配器，agent 行为不变。 增加新渠道的成本是”写一个适配器”而非”改 agent 代码”——让 24+ 渠道的维护成本是线性的而非指数的。

经验：当系统需要对接多种外部接口时，把对接逻辑抽成适配器层——适配器只做协议转换，不碰业务逻辑。关键在于从一开始就做，后期重构成本极高。

决策二：DM Pairing——零信任输入 #

把入站 DM 当作不可信输入。默认 dmPolicy="pairing"——未知发送者收到配对码，bot 不处理消息。公开 DM 需显式 opt-in。openclaw doctor 主动暴露风险配置。

经验（呼应认知三）：任何连接外部世界的 agent，默认应假设输入是恶意的。DM Pairing 是零信任在 agent 场景的具体实现——先验证身份，再处理内容。

决策三：权限按会话隔离 #

会话类型	权限
main（你自己用）	全权
非 main（群聊被@触发）	自动沙箱

沙箱后端可选 Docker/SSH/OpenShell——不绑死一种隔离技术。

经验：权限模型应该是会话级而非用户级。同一个用户，在”我自己用”和”群聊被@触发”两种场景下，agent 权限应该不同。

决策四：配置即文件 #

三个文件被注入到每次对话上下文：

文件	作用
SOUL.md	人格定义（你是谁）
AGENTS.md	行为规则（你怎么做）
TOOLS.md	可用工具（你能做什么）

Agent 自己可以读写这些文件来修改自己的行为——不需要改代码、重启服务、配置中心。

经验（呼应认知六）：当系统的使用者是 AI 时，配置应该以 AI 可读可写的形式存在。Markdown 文件 + context 注入是最简单也最有效的方案。

不足：

• Gateway 是单点——挂了全挂
• TypeScript 单线程在密集工具调用时需要 worker thread 绕路
• 24+ 渠道 × 多种策略 = 配置矩阵复杂度高

---

Hermes：让 Loop 学会自己改进 #

203k star · Python 81.9% · 解决认知二（程序性记忆）的标杆

Hermes 不只是”记住你说了什么”（陈述性记忆），而是”学会怎么做”（程序性记忆）——这是它和所有其他个人 Agent 的根本区别。

用户请求 → Agent 执行任务 → 成功？
                          ├─ 是 → 提取成功路径 → 沉淀为 Skill
                          │         ↓
                          │    Skill 在使用中持续改进
                          │         ↓
                          │    FTS5 全文检索历史会话 → 跨会话回忆
                          │         ↓
                          │    Honcho 用户建模 → 对你的理解深化
                          └─ 否 → 记录失败轨迹 → 不沉淀

决策一：Skill 自动创建与持续改进 #

完成复杂任务后自动提取成功路径为可复用 skill，skill 在使用中持续改进——效果更好就更新，更差就回退。兼容 agentskills.io 开放标准。

经验（呼应认知二和六）：把”学习”从模型参数层面（需 GPU 微调）拉到”外部知识层面”（skill 是文件，改文件不需要训练）。Agent 的”变聪明”不需要重新训练模型，只需要更新 skill 文件。

代价：skill 质量取决于初始任务成功率——冷启动期 agent 经验不足，可能”学会错误”。

决策二：Serverless 持久化 #

六种终端后端：

后端	特点
local / Docker / SSH / Singularity	传统方式
Modal / Daytona	serverless 持久化——空闲休眠、按需唤醒

经验：Agent 是典型的”突发负载”场景——一条消息触发密集计算，然后长时间空闲。Serverless 持久化比 24/7 VPS 便宜一个数量级。“永远在线”不是 24/7 运行，而是”随时可唤醒”。

决策三：Trajectory 压缩器 #

trajectory_compressor.py 把 agent 执行轨迹批量生成 + 压缩，用于训练下一代工具调用模型。

经验：如果你的系统使用 AI，考虑”使用过程中产生的数据能否反哺模型”。Agent 执行轨迹（任务 → 工具调用 → 结果 → 修正）是高质量监督信号——即使不训练模型，这些数据也有商业价值。

不足：

• skill 漂移无防护——可能”学会错误”
• Python 部署对非技术用户有门槛
• 闭环依赖初始成功率——冷启动期 skill 质量低

---

ZeroClaw：在类型系统里把安全焊死 #

32k star · Rust 100% · 解决认知三（安全是地基）的标杆

四条哲学围绕一个核心：

You own the agent. You own the data. You own the machine it runs on.

入站消息（30+ 通道）→ Agent Loop → 工具调用请求
                                    ↓
                              风险评估（autonomy level）
                                    ├─ 低风险 → 直接执行
                                    ├─ 中风险 → 需要批准
                                    └─ 高风险 → 阻断
                                    ↓
                              沙箱执行（OS 级，三层纵深防御）
                                    ↓
                              密码学工具回执（不可篡改）

决策一：OS 级沙箱，而非容器级 #

平台	技术	本质
Linux	Landlock / Bubblewrap	内核命名空间 + 能力限制
macOS	Seatbelt	内核级沙箱配置文件
通用	Docker	容器级隔离

Docker 是”容器内隔离”（逃逸 = 完全暴露），Landlock/Seatbelt 是”内核级限制”（逃逸后内核仍拒绝）。这是纵深防御——沙箱之上还有沙箱。

经验（呼应认知三）：单层防御失效概率是 P，三层叠加是 P³。Agent 有 bash 执行能力时，这个差异是致命的。

决策二：密码学工具回执 #

每次操作生成不可篡改的密码学证明。日志可被修改，回执不可否认。企业合规的刚需——其他所有框架都只有日志。

经验：当 agent 管理生产系统时，”它做了什么”比”它说了什么”重要。日志是”可变的记录”，密码学回执是”不可篡改的证据”。

决策三：Peripheral trait——在类型系统层面抽象硬件 #

Rust 的 trait 抽象 GPIO/I2C/SPI/USB，让 agent 操作树莓派/STM32/Arduino/ESP32。

所有权模型保证硬件资源生命周期安全——编译期消灭 use-after-free，这是 C/C++ 硬件编程的常见灾难。

经验：用 trait/接口抽象能力，而非配置或 flag。类型系统在编译期保证资源安全，而非运行时报错。这是 Rust 在 agent 硬件化方向上不可替代的优势。

决策四：SOP 引擎——事件驱动扩展 #

事件触发（MQTT / webhook / cron / 外设）的标准操作流程，带审批门和可恢复执行。

Agent 从”你问它答”变成”传感器触发 → 决策 → 执行 → 回执”的事件驱动循环。

经验（呼应认知一）：对话驱动是 agent 的”手动挡”，事件驱动是”自动挡”。生产环境的 agent 大部分时间不应等人来问，而应被事件触发。

不足：

• Rust 开发者池小 = 社区门槛高
• 编译时间长 = 迭代慢
• “全都要”策略（30+ 通道 + ~20 provider）维护负担重

---

GBrain：零成本建图 + 告诉你不知道什么 #

24.1k star · TypeScript · Garry Tan（YC CEO）· 解决认知四和认知五的标杆

Search gives you raw pages. GBrain gives you the answer.

signal → search → respond → write → auto-link → sync
(每条消息) (大脑优先) (带上下文) (写页面+时间线) (类型化边,零LLM) (cron保新)
                                                    ↓
                                              dream cycle（夜间）
                                              去重/修复/发现矛盾/准备明天

决策一：自接线知识图谱——零 LLM 建边 #

[[wiki/people/bob]] 式引用被纯模式匹配提取，自动创建类型化边：

• attended · works_at · invested_in · founded · advises

零 LLM 调用。 P@5 49.1%，比禁用图谱变体高 31.4 个百分点。Garry Tan 跑着 146,646 页——如果每条边用 LLM 提取，成本会爆炸。

经验（呼应认知四）：模式匹配、正则、解析器在结构化数据上比 LLM 快 1000 倍、准 100 倍、成本为 0。不是所有”智能”都需要 AI——有些只需要正则。

决策二：综合层返回答案 + 缺口分析 #

gbrain think 不返回 chunk 列表，返回带引用的合成答案。末尾告诉你”大脑还不知道什么”：

“自 4 月 22 日起没有 Alice 的新信息，她可能通过邮件回复了你但大脑看不到。”

经验：信息检索系统最大的问题不是”找不到”，而是”找到了但用户不知道够不够”。缺口分析返回答案的覆盖范围——告诉用户下一步该做什么（”去问 Alice 确认”），比一个抽象的置信度分数实用得多。

决策三：Dream cycle——离线巩固 #

夜间自动执行：

• 去重人物页
• 修复引用
• 打显著性分
• 发现矛盾
• 准备明天任务

cron 驱动，不依赖用户触发。66 个 cron 作业。人类大脑在睡眠时整理记忆——GBrain 把这个生物学机制工程化了。

经验（呼应认知五）：记忆系统需要”整理期”。Dream cycle 是”写入-整理”分离的设计：白天只追加（快），夜间统一整理（慢但彻底）。和数据库的 WAL + checkpoint 是同一个思路。

决策四：Schema packs——渐进式发现 #

三层渐进，不是”一上来让你定义 schema”，也不是”AI 全自动帮你定”：

gbrain schema detect             # 自动分析你的文件系统，提出类型建议（免费、快）
gbrain schema suggest            # LLM 在建议上做一轮细化（花一点钱、好一点）
gbrain schema review-candidates  # 人工确认/拒绝/重命名（最终决策）

经验：给用户配置选项时，渐进式发现比”全手动”或”全自动”都好。先自动分析（降低认知负荷），再 AI 建议（比纯人工全面），最后人确认（保证可控）。

不足：

• 依赖结构化数据（wiki 风格链接）——非结构化笔记无法自动建边
• 维护 66 个 cron 作业本身就是一项工程
• 综合层依赖 LLM——答案质量受模型限制

---

Mem0：写入一步到位，检索三路融合 #

2026.4 新算法 · LoCoMo 91.6 分 · LongMemEval 94.8 分 · 解决认知五的标杆

Mem0 把记忆从 agent 内部功能变成了独立服务——换 agent 不丢记忆，如同数据库独立于 Web 框架。

Agent 对话 → Mem0.add(messages)
                ↓
          单次 LLM 调用（ADD-only，无 UPDATE/DELETE）
                ↓
          提取记忆 + 实体链接 + 嵌入
                ↓
          存储（Qdrant/Postgres）
                ↓
Agent 查询 → Mem0.search(query)
                ↓
          多信号检索：语义(HNSW) + BM25(关键词) + 实体匹配
                ↓
          时间推理（时间感知排序）
                ↓
          返回最相关记忆

决策一：单次 ADD-only 提取 #

一次 LLM 调用完成记忆提取，不做 UPDATE/DELETE。

传统方案是 4 步（提取 → 比对 → 决定更新/合并/删除 → 写回），Mem0 一步完成。代价是可能积累冗余，但 LongMemEval 从 67.8 提升到 94.8 证明折中是对的。

经验（呼应认知五）：不要在写入时追求完美，在检索时追求精准。写入要快（一次调用），检索要准（多信号融合）。 这是 WAL + checkpoint 思路在记忆系统的应用。

决策二：多信号检索融合 #

三路并行打分后融合：

信号	擅长	盲区
语义（HNSW 向量）	“意思相近”	精确关键词匹配
BM25（关键词）	精确命中	同义/近义表达
实体匹配	关系连接	语义相似但无关系

三者互补。再加时间推理——知道”这是上个月的旧信息”还是”今天的最新状态”。

经验（呼应认知四）：单一检索信号必然有盲区。向量是”意思搜索”，关键词是”字面搜索”，实体是”关系搜索”——它们看到不同的世界。融合三者比优化任何一个都有效。

决策三：Agent 自助注册 #

mem0 init --agent 在 5 秒内创建 API key——不需要邮箱、仪表板、OTP。人类后续用 mem0 init --email 认领。

经验：在 agent 时代，API key 的”用户”是 agent 而非人类。Agent 不看邮箱、不点验证链接、不填验证码。给它一个 CLI 命令，它自己执行。这和 OAuth device flow 思路一致——先授权设备使用，人类后续确认。

不足：

• ADD-only = 长期使用后记忆垃圾场，需更好的遗忘/合并机制
• 独立服务 = 多一跳延迟
• 依赖 LLM 提取记忆——提取质量受模型限制

---

smolagents：从声明式到命令式的范式跳 #

HuggingFace · 核心代码 ~1,000 行 · 解决认知四的另一面——少调 LLM

传统 ToolCallingAgent（JSON，声明式）：
  LLM → {"tool": "web_search", "args": {"query": "X"}}    ← 第 1 轮 LLM 调用
  执行 → 返回结果
  LLM → {"tool": "web_search", "args": {"query": "Y"}}    ← 第 2 轮
  执行 → 返回结果
  LLM → {"tool": "filter", "args": {...}}                  ← 第 3 轮
  ...（N 轮 LLM 调用）

CodeAgent（Python 代码，命令式）：
  LLM → for q in ["X", "Y", "Z"]:                          ← 1 轮 LLM 调用
            results = web_search(q)
            print(f"{q}: {results}")
  执行 → 一次完成 3 次搜索 + 打印

决策一：代码 = 命令式，JSON = 声明式 #

JSON 工具调用一次调一个工具。代码可以写循环、条件、变量赋值——一个代码动作里完成多次搜索 + 过滤 + 排序。

论文证明少 30% 步骤（减少 30% LLM 调用）：

30% 的调用减少 = 30% 延迟降低 + 30% 成本降低 + 30% 出错概率降低。

经验（呼应认知四）：当 LLM 的”输出”从”声明我要用什么工具”变成”写一段程序完成目标”，agent 的能力上限从”一次一个动作”跳到”一次一个程序”。不是增量改进，是量级跳跃。

决策二：~1,000 行核心代码 #

作者刻意保持极简。对比：LangGraph 的核心代码是它的几十倍。

框架越大，你越需要理解框架本身——而不是理解你的问题。

经验：框架的信任度与代码量成反比。1000 行你可以全部读完。10000 行你只能信任文档。100000 行你只能祈祷。当框架处理的是”agent 执行代码”这种安全敏感场景时，可审计性比功能丰富度重要得多。

决策三：诚实标注安全边界 #

LocalPythonExecutor 明确标注：

“provides best-effort mitigations only and is not a security boundary. Do not use it to run untrusted code.”

必须用 E2B / Blaxel / Modal / Docker。

经验（呼应认知三）：在安全问题上不要含糊。如果你的工具有安全限制，明确说出来。LocalPythonExecutor 的文档比那些声称”内置安全沙箱”但实际可被绕过的框架更值得信任——因为它说了真话。

不足：

• 安全完全依赖外部沙箱
• LLM 写的代码质量参差不齐——语法错误、逻辑错误、无限循环
• 缺乏对代码动作的约束机制——不像 DSL 那样可以限制能力

---

交叉思考：这些洞察如何改变自己的工程实践 #

以上六条认知和六个产品不是理论——它们对本博客已有的工程实践有直接启示。

认知管理 vs GBrain 综合层 #

本博客的《用 Hexo 搭建认知管理系统》论点是”知识管理的痛点不是存而是找”。但看完 GBrain 后，发现一个缺失：只有检索，没有综合。

search.json 返回关键词匹配的文本片段——正是 GBrain 批判的”返回 10 个 chunk 让你自己读”。

可行动的改变：在构建时从文章交叉引用中提取概念依赖图。不需要 LLM——解析 Markdown 链接 + front-matter 的 tags/categories 即可（呼应认知四）。

PDC 协议 vs MCP 生态 #

本博客实现了 PDC 协议（内容侧）和 PDC → MCP 适配器（agent 侧）。看完 37 个项目后判断得到验证：MCP 被几乎所有框架采纳。

内容生产端                  Agent 消费端
PDC（llms.txt + JSON/MD API） → MCP（工具发现 + 调用）
我的博客构建时生成              Claude/Cursor/OpenClaw 运行时发现

两者互补——37 个框架都在解决”agent 怎么调用工具”，很少有人解决”内容怎么被 agent 消费”。

RAG 实践 vs Mem0 多信号检索 #

本博客的 RAG 工程实践 核心论点是”纯向量不够，多信号融合才是方向”。Mem0 的 2026.4 新算法验证了这个判断——但 Mem0 走得更远，加了时间推理，区分”过时信息”和”当前状态”。

泡沫诊断 vs 框架过载 #

本博客的 AI 浪潮第一性原理 用庞氏结构诊断了 AI 浪潮。用到 Agent 生态上：大部分框架会死——“又一个可视化工作流”的特征是”可以互相替代”。

会存活的是不可替代的底层能力——它们不是”加个功能就能复制”的，而是地基选择（呼应认知六）。

本博客该用什么 Agent #

博客是 Hexo 静态站点 + GitHub Pages。结论清晰：

1. 不需要 OpenClaw/Hermes 做 blog agent——静态站点不需要 24/7 agent runtime
2. 需要 Mem0 做写作记忆——让 Claude Code 能记住”这个博客的风格偏好”
3. 博客的 PDC 协议就是它的”skill”——/llms.txt、/api/posts/*.md 与 OpenClaw 的 AGENTS.md/SOUL.md 走的是同一条路
4. 下一步：给 search.json 增加 related_posts 字段；在 AGENTS.md 中增加写作风格 skill；在 llms.txt 中增加概念依赖图

这些改变不需要换框架——改变的是记忆层和 skill 层。框架是 runtime 可以换，记忆和 skill 是资产不应该换。

---

选型速查 #

需求	推荐	核心理由
挂微信/TG 的全能助理	OpenClaw	24+ 渠道适配器，控制面/数据面分离
“越用越懂我”	Hermes	自学习闭环，skill 自动创建 + 改进
安全合规 / 驱动硬件	ZeroClaw	OS 级沙箱 + 密码学回执 + Peripheral trait
给 agent 加记忆	GBrain 或 Mem0	综合层 + 缺口分析 / 独立记忆服务
极简 Code = Action	smolagents	1000 行，代码比 JSON 少 30% 步骤

---

信息来源声明 #

本文全部数据截至 2026 年 6 月，来自各项目 GitHub 仓库 README 原始文件（raw.githubusercontent.com）。架构分析为基于 README 数据的独立判断。