真实架构拆解与设计选型：没有最好的架构,只有最合适的
前十四篇拆的都是”零件”
、工具契约、记忆、压缩、持久化、规划、编排、Harness、生产化、进阶模式。这一篇把零件放回真实系统里检验——看几个开源 Agent 各自怎么落地,再回答那个最容易问错的问题:哪个架构最好?先说结论
。研究得越深,越会发现每个项目的架构都不是偶然,而是它的约束逼出来的。所以正确的问题是——给定你的约束,哪个架构最合适?本文主要参考
《总体设计哲学与选型指南》《16 个开源项目差异对比总览》,how-pi-agent-works、how-deerflow-works、deepagents-in-action 三套真实架构文档。文中项目名、约束、结论均来自对公开源码与文档的分析。
一、三个真实系统,三种落地
pi-agent
pi-agent(how-pi-agent-works 拆解的对象)的核心洞察是:Agent 的状态本质是一棵会话树。每一次交互是树上的一个节点,fork 就是从某个节点长出新枝。这套模型把前面讲的”中断恢复""子智能体上下文继承”统一成了一件事——都是树的操作。
它的价值在于用一个数据结构统一了多个概念
,持久化是把树写盘,恢复是重放树,子智能体是子树。当你发现几个看似独立的机制能被一个模型统一,通常说明你抓到了问题的本质。DeerFlow 静态图编排
DeerFlow(how-deerflow-works 拆解的对象)走的是另一条路:用 LangGraph 的 StateGraph 把多智能体协作写成一张静态图。Coordinator、Supervisor、Researcher、Coder 是图上的节点,条件边决定路由,全部用 Python 代码写死。
对照第 9 篇的”谁决定并行度”
是典型的代码决定——LLM 只输出符合格式的 JSON,图结构负责路由。它的人机交互(第 11 篇)通过escalation 工具实现,等用户输入后带相同 thread_id 从 Checkpointer 快照恢复。这印证了第 7 篇的”从哪里恢复执行”——DeerFlow 的恢复是节点级的。
DeerFlow 的构建路线图(build-00 到 build-05)本身就是一份”从状态到模型到工具到中间件到子智能体”的渐进搭建教程,和第 10 篇的六步 Harness 路线图遥相呼应。
deepagents Harness 实战
deepagents-in-action 从另一个角度切入:虚拟文件系统 + 任务规划 + 子智能体 + 长期记忆,一步步搭出一个能用的 Harness。它的 ch03 虚拟文件系统对应第 3 篇的工具契约(把文件操作抽象成 Agent 可安全调用的工具),ch04 任务规划对应第 8 篇,ch05/06 子智能体(含异步)对应第 9 篇,ch08 长期记忆对应第 6 篇。
三个系统放在一起看,你会发现:它们用的零件是同一套,拼法完全不同。pi-agent 追求极简统一,DeerFlow 追求确定性编排,deepagents 追求完整能力。没有谁对谁错,只有约束不同。
二、四象限 个项目的派别地图
agent开发系列横评了 16 个开源 Agent,发现它们不是随机散落,而是形成四个清晰派别(按”约束强度 × 知识广度”两轴划分):
约束强度 ↑
│
快速原型派 │ 企业基础设施派
┌──────────────┐ │ ┌──────────────┐
│ DeerFlow │ │ │ Goose (Rust) │
│ Hermes Agent │ │ │ Eino (Go) │
│ Oh My OpenAgent│ │ │ OpenCode (TS) │
└──────────────┘ │ └──────────────┘
─────────────────────────┼───────────────────────→ 知识广度
│
行为塑造派 │ 多平台通信派
┌──────────────┐ │ ┌──────────────┐
│ Superpowers │ │ │ OpenClaw │
│ ECC │ │ │ NanoClaw │
│ Karpathy Skills│ │ │ Hermes Gateway│
└──────────────┘ │ └──────────────┘- 企业基础设施派(Goose/Eino/OpenCode),插件有稳定公开 API,安全是一等公民,为多团队协作设计。愿意为长期可维护性付出前期复杂性。
- 快速原型派(DeerFlow/Hermes/Oh My OpenAgent) 动态类型或无框架循环,承担运行时类型错误的风险,换迭代速度。适配 ML/研究场景。
- 行为塑造派(Superpowers/ECC/Karpathy)“LLM 行为主要靠上下文决定,最佳载体是 Markdown”。不写代码工具,只注入知识和规则(见第 12 篇)。
- 多平台通信派(OpenClaw/NanoClaw),channel 抽象是架构一等公民(见第 11 篇)。
四个派别不互斥。最好的系统往往跨象限
+ 领域知识注入 + 多平台部署。三、约束 → 架构的映射
这套横评最有价值的产出,是把”约束”直接映射到”技术选择”。
语言选择
| 需求 | 技术选择 | 代表项目 |
|---|---|---|
| 桌面应用轻量、无 Electron | Rust + Tauri | Goose |
| 类型安全图编排 + Go 生态 | Go 泛型 | Eino |
| 函数式依赖注入 + 穷举错误处理 | TypeScript + Effect | OpenCode |
| ML 生态 + 快速迭代 | Python | DeerFlow、Hermes |
| 知识注入而非代码、非程序员参与 | Markdown | ECC、Superpowers |
注意:语言选择不是品味问题,是约束的直接后果。Goose 用 Rust 是因为 Block 要做桌面应用且看重企业安全;Eino 用 Go 是因为字节有 Go 生态;Hermes 用 Python 是因为要快速支持 200+ 模型。
插件架构
| 约束场景 | 插件方式 | 代表项目 |
|---|---|---|
| 支持任意语言工具、需进程隔离 | MCP 协议 | Goose |
| 100+ 插件、启动性能优先 | manifest + 懒加载 | OpenClaw |
| 编译时类型安全 | Go interface 分层 | Eino |
| 非程序员可贡献 | Markdown 文件 | ECC |
| 单人使用简单即可 | 直接注册函数 | 小型项目 |
四、四个反复出现的规律
横评 16 个项目后,有四条规律在几乎每个设计良好的系统里都出现:
- 隔离是一切可维护性的基础——所有好系统都在把变化的部分和稳定的部分隔离开(对应第 4 篇的 prefix/tail、第 10 篇的 harness/application 分界)。
- 协议比实现重要——MCP、Plugin SDK、Runnable 接口才是长期价值的锚点。实现会重写,协议会留存。
- 约束驱动的设计比最佳实践驱动的设计更健壮——最好的架构决策来自清晰认识你自己的约束,而不是照搬别人的”最佳实践”。
- 知识和能力是两件事,混淆会造成架构混乱——Markdown Skill 是知识(塑造判断),MCP 工具是能力(执行操作)。这正是第 12 篇三种形态的核心。
五、如果你要从零开始
不要一上来就问”用什么框架”。先回答三个问题,答案会自动缩小选择范围:
- 你的主要用户是谁? 单开发者 / 小团队 / 企业大团队
- 你的核心需求是什么? 工具执行 / 知识注入 / 工作流编排 / 多模型 / 插件生态
- 你的团队背景是什么? Python·ML / Go 后端 / TypeScript 函数式
然后按本专题的顺序搭
(第 3 篇)→ 包进循环(第 2 篇)→ 加工具契约和权限(第 3、11 篇)→ 上下文和记忆(第 4-6 篇)→ 持久化(第 7 篇)→ 需要时再加规划、编排、生产化(第 8-13 篇)。从最小可运行开始,让下一步的需求自己浮现出来。收束,不是标准答案
这 16 个项目、三个真实系统的真正价值,不是让你复制某一个,而是给你一个工具箱
,你知道谁解决过类似问题、他们的解法是什么、代价是什么。没有最好的架构,只有最适合你约束的架构。
这也是整个专题的落点。前十四篇给你的是”零件和原理”,这一篇给你的是”怎么按自己的约束把零件拼起来”。下一篇(也是最后一篇),我们把这 16 个项目的 11 个维度横评摊开成一张完整地图,作为你日后选型时可以随时回来查的索引。
本文为「Agent 系列」第 15 篇。主要参考
《总体设计哲学与选型指南》《项目差异对比总览》,how-pi-agent-works、how-deerflow-works、deepagents-in-action。