十六个开源项目全景横评:一张可以随时回来查的选型地图
本文是「专题·Agent」系列第 16 篇,也是全专题的收官。上一篇真实架构拆解与设计选型拆了三个真实系统、立了四象限、给了”约束→架构”的映射。这一篇不讲任何新原理——它是一张索引地图
,让你日后选型时可以随时回来查。
前十五篇是”顺着原理往下讲”,每一篇讲一个子系统,顺手带出几个项目怎么做。但选型的时候,你要的是”横着看”
,16 个项目各自怎么解?这一篇就是把那些竖着讲的对比,转成一张横着查的地图。先说清楚一件事:这张地图不是让你照抄某一行,而是让你在自己的约束下快速定位”谁踩过我这个坑”。 没有哪一列是满分,每个项目的空格和实心格,都是它约束的直接后果。
一、16 个项目,四个阵营
16 个开源 Agent 不是随机散落的,它们按”对什么是 Agent 的理解”聚成四个阵营。这是全专题反复引用的底座框架:
flowchart TB
subgraph 企业基础设施派["企业基础设施派 · 类型安全优先"]
Goose["Goose · Rust"]
Eino["Eino · Go"]
OpenCode["OpenCode · TS"]
end
subgraph 快速原型派["快速原型派 · 迭代速度优先"]
DeerFlow["DeerFlow · Python"]
Hermes["Hermes · Python"]
OhMy["Oh My Open Agent · Python"]
end
subgraph 行为塑造派["行为塑造派 · 上下文即行为"]
Superpowers["Superpowers"]
Karpathy["Karpathy Skills"]
ECC["ECC"]
end
subgraph 多平台通信派["多平台通信派 · 频道即一等公民"]
OpenClaw["OpenClaw"]
NanoClaw["NanoClaw"]
end
四个阵营之外,本专题还深挖了几个作为”真实架构样本”反复出场的系统——它们更像教学参考,横跨多个阵营:
| 样本 | 定位 | 反复出现在 |
|---|---|---|
| pi-agent | 极简会话树,一个数据结构统一多个概念 | 第 3、7、9、15 篇 |
| deepagents | 虚拟文件系统 + 规划 + 子代理的完整 Harness | 第 10、15 篇 |
| Generic Agent(GA) | 92 行循环 + 9 原子工具,能力全靠涌现 | 第 6、8、14 篇 |
| Paperclip | Harness 与应用分离做得最干净的参考 | 第 10 篇 |
把四阵营的 11 个 + 这 4 个样本合起来,就是本专题横评过的完整项目面。下面的维度表,主要以四阵营的代表项目为列。
二、11 个维度 = 专题的 11 条主线
这张地图的”列”是项目,“行”是维度。而 11 个维度,恰好就是本专题从第 1 篇讲到第 13 篇的主干——每一行都能翻回对应那一篇看细节:
| # | 维度 | 核心问题 | 对应篇目 |
|---|---|---|---|
| 1 | 语言 / 类型系统 | 编译期安全 vs 运行时灵活 | 第 1、15 篇 |
| 2 | Agent 循环形态 | 循环怎么驱动、何时”停” | 第 2 篇 |
| 3 | 工具 / 插件架构 | 工具怎么注册、怎么隔离 | 第 3、12 篇 |
| 4 | 上下文 / 缓存策略 | 稳定前缀怎么保、缓存怎么活 | 第 4 篇 |
| 5 | 短期记忆 / 压缩 | 上下文满了怎么办 | 第 5 篇 |
| 6 | 长期记忆 / 检索 | 什么活到下次会话、怎么找回 | 第 6 篇 |
| 7 | 状态持久化 / 恢复 | 崩了从哪接着跑 | 第 7 篇 |
| 8 | 规划机制 | 循环之上要不要一层规划 | 第 8 篇 |
| 9 | 多智能体 / 并行度 | 谁决定并行度 | 第 9 篇 |
| 10 | 人在环路 / 连接器 | 人怎么介入、怎么接外部平台 | 第 11 篇 |
| 11 | 行为塑造 / 安全 | 怎么让 AI 遵从、怎么防跑偏 | 第 12、13 篇 |
这也是为什么这一篇必须放在最后
,都在这张表里填了几个格子。现在只是把它们收拢起来。三、核心横评表
下面按维度,把前文已经确立的对比汇到一起。每一格都来自前面某一篇里已经讲过的结论,不是这一篇新造的——这正是”索引”的意思。
维度 1(第 1、15 篇)
| 项目 | 语言 | 约束反推 |
|---|---|---|
| Goose | Rust + Tauri | 桌面应用要小二进制、低内存、企业级安全 |
| Eino | Go 泛型 | 字节 Go 生态 + 编译期图验证 |
| OpenCode | TS + Effect | 函数式依赖注入 + 穷举式错误处理 |
| DeerFlow / Hermes | Python | ML 生态 + 中间件运行时动态组装 |
| ECC / Superpowers | Markdown | 知识注入而非代码,非程序员可参与 |
一句话:语言不是品味,是约束的后果(第 15 篇的核心论点)。
维度 3 & 12(第 3、12 篇)
| 约束场景 | 插件方式 | 代表项目 |
|---|---|---|
| 支持任意语言工具、需进程隔离 | MCP 协议 | Goose |
| 100+ 插件、启动性能优先 | manifest + 懒加载 | OpenClaw |
| 编译期类型安全 | Go interface 分层 | Eino |
| 非程序员可贡献 | Markdown 文件 | ECC |
行为塑造派内部还能再切一刀,靠的是它们各自的”内核问题”(第 12 篇):
| 项目 | 内核问题 |
|---|---|
| Superpowers | AI 会不会在压力下绕过规则? |
| Karpathy Skills | AI 的默认行为模式对不对? |
| ECC | AI 有没有这个领域的背景知识? |
维度 6(第 6 篇)
这是差异最大的一个维度,直接把第 6 篇的横评搬过来:
| 项目 | 专门记忆系统 | 搜索方式 | 提炼方式 | 成本 |
|---|---|---|---|---|
| Hermes | ✅ 一等公民 | FTS5 + 外部向量插件 | LLM 提炼事实 | 低 |
| DeerFlow | ✅ | LLM 语义提取 | LLM + 30s 防抖批量 | 高 |
| Nano Claw | ✅ 文件 | 文件直读 | 用户手动 remember | 零 |
| Goose | ❌ 仅历史检索 | FTS5 全文 | 存原始消息 | 零 |
| Eino | ❌ 仅状态快照 | 无 | 无 | 零 |
关键观察(第 6 篇)
个项目里只有少数真正做了跨会话记忆,大多数依赖上下文窗口——大多数场景可能并不需要复杂的记忆系统。
维度 7(第 7 篇)
不同项目把”恢复”这件事做在了不同粒度上:
| 关注点 | 代表项目 | 解决的问题 |
|---|---|---|
| 执行状态精确恢复 | Eino | 从第五步继续,不是从头重来 |
| 用户取消与优雅退出 | Goose | Cancellation Token |
| 运行时健康检测 | Hermes | Agent 还活着吗?卡死了吗? |
| 跨会话任务进度 | Oh My Open Agent | 上次做到哪了? |
维度 9(第 9 篇)
“谁决定并行度”这一问,把项目切成了三派:
| 路线 | 谁决定 | 代表项目 | 并行度可预测性 |
|---|---|---|---|
| 代码决定 | 写死在图结构里 | DeerFlow、Eino | 最高 |
| LLM 决定 | 框架给工具,LLM 自己判断 | Goose | 最低 |
| 规则决定 | Skill 里写死严苛条件 | Superpowers | 高 |
DeerFlow 的一个硬约束值得记住:最多 3 个并发子代理——并发不是越多越快,它有上限,且子代理之间要协调。
维度 10 & 11(第 11、12 篇)
多平台通信派把”频道多样性”当成一等公民
/ NanoClaw 的 channel 抽象是架构的核心,而不是外挂。这与企业派、原型派把通信当边缘功能形成鲜明对比(第 11 篇)。四、四条反复出现的规律
横着看完 11 个维度,有四条规律在几乎每个设计良好的系统里都出现(第 15 篇已提炼,这里作为地图的图例再钉一次):
- 隔离是一切可维护性的基础 —— 好系统都在把”变的部分”和”稳的部分”隔开。
- 协议比实现重要 —— MCP、Plugin SDK、Runnable 接口才是长期价值的锚点;实现会重写,协议会留存。
- 约束驱动 > 最佳实践驱动 —— 最好的决策来自认清自己的约束,而不是照搬别人的”最佳实践”。
- 知识和能力是两件事 —— Markdown Skill 是知识(塑造判断),MCP 工具是能力(执行操作);混淆会造成架构混乱。
五、选型速查
真正用这张地图的方式,是从你自己的约束出发,反查该看哪一行、哪一列:
flowchart TD
Start["你的主要约束是?"] --> Desktop["桌面应用/小二进制"]
Start --> Team["企业大团队/类型安全"]
Start --> Fast["快速原型/ML 迭代"]
Start --> IM["多 IM 平台接入"]
Start --> Behave["控制 AI 行为/非程序员参与"]
Desktop --> G["→ 看 Goose(Rust)"]
Team --> E["→ 看 Eino(Go)/OpenCode(TS)"]
Fast --> D["→ 看 DeerFlow/Hermes(Python)"]
IM --> O["→ 看 OpenClaw/NanoClaw"]
Behave --> S["→ 看 Superpowers/ECC/Karpathy"]
配合第 15 篇的三问,选择范围会自动收窄:
- 主要用户是谁? 单开发者 / 小团队 / 企业大团队
- 核心需求是什么? 工具执行 / 知识注入 / 工作流编排 / 多模型 / 插件生态
- 团队背景是什么? Python·ML / Go 后端 / TypeScript 函数式
答完这三问,地图上属于你的那一行基本就亮了。
收官,和一整个专题
回到最开始那个问错的问题——“哪个架构最好?”。走完 16 篇,答案已经很清楚:
没有最好的架构,只有最适合你约束的架构。
这张地图不替你做决定,它只做一件事
,让你能快速找到”谁解决过类似问题、他们怎么解的、代价是什么”。这 16 个项目、11 个维度,是一个工具箱的索引,不是一份标准答案。整个「从概念到系统」专题到这里收束:
- 第 1–4 篇建立地基 是什么、对话循环、工具契约、上下文与缓存。
- 第 5–7 篇处理记忆与状态、长期记忆检索、持久化与恢复。
- 第 8–10 篇讲协调、多智能体编排、把一切装进 Harness。
- 第 11–13 篇面向对外与生产 MCP、Skills 与行为塑造、生产化。
- 第 14–16 篇进阶与全景、真实架构拆解、以及这张横评地图。
前十五篇给你”零件、原理和真实样本”,这一篇给你”一张随时能回来查的索引”。把它收藏起来——下次要造 Agent 或选型时,从约束出发,回到这里对一对,大概率能省掉几周的试错。
本文为「Agent 系列」第 16 篇,全专题收官。本文不引入新素材,所有横评数据均来自本专题第 1–15 篇已确立的对比结论,以及 agent开发系列《总体设计哲学与选型指南》《16 个开源项目差异对比总览》、how-deerflow-works「超级 Agent 的四个阵营」。术语保留英文原词。
