2026 年 AI Agent 开源生态全景
五月初的一个通宵，Maple 让几个 Agent 并行扫了六个开源项目的源码、上千条 GitHub issue、还有一堆学术论文和社区帖子。本来只想给 Vyane 选型做个参考，结果越挖越深，最后出来的调研规模远超预期。
这篇文章是我对那次调研的提炼。不是面面俱到的白皮书，而是 Maple 作为一个在这个生态里实际做东西的个人开发者，觉得值得记下来的观察。
一个关键的时代背景：MCP 成了事实标准
在聊具体项目之前，得先说清楚一件事——2026 年上半年，整个 Agent 开源生态最大的变量是 MCP（Model Context Protocol）的标准化。
Anthropic 在 2025 年底推出 MCP 的时候，社区反应是分裂的：有人觉得是又一个厂商锁定的协议，有人觉得终于有人认真在做工具层的标准化。半年后回头看，后一种人赢了。OpenAI、Google、Microsoft 相继宣布支持 MCP，几乎所有主流 Agent 框架都把 MCP 集成作为了标配能力。
这意味着什么？最直接的影响是：工具不再是 Agent 框架的护城河了。 以前你选 LangChain 是因为它的工具生态最全，现在工具通过 MCP server 跨框架共享，选型的权重开始从”谁的工具多”转向”谁的编排好、谁的 session 管理稳、谁的开发者体验顺”。
Hermes Agent：一个值得认真研究的单体
Hermes Agent 是 Nous Research 的开源项目，12 万 stars，六周发了十个版本。它走的是全功能单体框架路线：CLI 交互、21 个平台的 IM 网关、170 多个内建工具、完整的 Memory 和 Skill 系统。
说实话，初次看到 130 万行代码的单 repo，第一反应是”这不可能维护得好”。深入读完之后——确实有些模块的技术债不轻（主循环单文件 9400 行、网关单文件 35 万字节），但在几个核心机制的设计上，它给出了非常精妙的答案。
Memory 冻结快照
这是 Hermes 最值得学的一个设计。
Session 开始时，Memory 内容做一次快照，之后整个 session 期间，注入到 system prompt 的 memory 就是这个冻结版本。工具调用读写的是磁盘上的实时数据，但 prompt 层面不变。
为什么这么做？因为 Anthropic 的 prompt cache 有 5 分钟 TTL——只要 system prompt 不变，cache 就能持续命中。Hermes 用”牺牲 session 内 memory 实时性”换来了”prompt cache 最大化”，对于高频调用场景这意味着可观的成本节省和延迟降低。核心逻辑不到 50 行。
五阶段 Context 压缩
当上下文接近模型窗口 50% 时触发压缩。不是一刀切地做摘要，而是分五步：先裁剪旧的 tool result、保护首尾消息、对中间部分做 LLM 摘要、修复压缩后的 tool pair 断裂、最后做 session 分裂。
摘要用的是结构化模板——Goal、Constraints、Progress（Done/InProgress/Blocked）、Decisions、Files、Next Steps、Critical Context 七个段落。迭代更新时保留上一次摘要，把 InProgress 的项移到 Done。
这个模板设计比”让模型自由发挥做摘要”靠谱得多。Maple 在自己的 session handoff 流程里已经开始参考这个结构。
哪些不值得照搬
Smart Model Routing 是 Hermes 最弱的模块——纯靠消息长度和关键词列表判断要不要路由到便宜模型。用户输入”帮我看看这个”可能被判定为简单请求，但实际是个复杂的代码审查任务。做多模型路由，语义级理解是绕不过去的。
整个单体架构也不是什么好的参照。130 万行代码在一个仓库里，7300 多个 open issues——这是生态庞大的代价。
OpenClaw 的教训：37 万 stars 背后的真实体验
OpenClaw 是开源 AI Agent 领域的绝对头部项目，36 万 stars，几乎每天一个版本。它的定位是自托管的个人 AI 助手，支持 50 多个 IM 平台、119 个扩展包。
Maple 用了几个月，后来停了。读完源码和大量社区反馈后，原因更加清晰。
架构上有可取之处
OpenClaw 的一些设计确实是行业标杆。Harness 抽象把不同的模型后端统一在一个接口后面（supports() + runAttempt() + compact()），分层 system prompt 的组织方式（SOUL.md / USER.md / TOOLS.md 各司其职），以及 Turn Kernel 的准入检查——这些在 Maple 后续的项目设计中都有借鉴。
Context file 分为 static 和 dynamic 两类来优化 prompt cache，这个思路跟 Hermes 的冻结快照异曲同工：尽量让不变的部分保持不变。
但实际体验很拉胯
社区反馈中最高频的投诉是 Memory 系统。同一个版本下，三个人的记忆行为完全不同：一个走 chunking + embedding 存 SQLite，一个按日期存 markdown 文件，还有一个什么都不记。这种”配置不确定性”比缺少功能更可怕——你不知道系统到底在干什么。
QMD 内存后端在 CPU-only 机器上 10 秒超时后会永久降级，而且不自动恢复。这意味着你的 Agent 在某次超时后就默默失去了记忆搜索能力，直到你手动重启。
自托管四周的实地报告更吓人：配置文件加了一个未识别的 key 就进入 crash-loop（377 次重启，没有退避）；CLI 文档与实际语法有 9 处不一致；Discord bot 能发不能收——消息被静默丢弃，没有错误输出。
安全方面的数据也不好看。一篇学术论文测出原生防御率只有 17%，CVE 记录显示存在零点击 WebSocket 劫持漏洞，社区 Skill 市场确认了 1100 多个恶意 skill。
资源消耗的现实
Gateway 空闲状态 400-800MB 内存。每个活跃 channel 加 100MB，浏览器自动化加 2-4GB。2GB 的 VPS 跑不动，4GB 只能不带浏览器用。有用户算过账：自托管总成本（含维护时间折算）每月 250-300 美元，而托管服务只要 45-55 美元。
这些数字说明一件事：对个人开发者来说，自托管 Agent 的隐性成本远比想象的高。
多 Agent Runtime：四大框架各走各路
Maple 横向对比了 OpenHands、AutoGen、CrewAI 和 LangGraph 在六个关键维度上的表现。它们代表了三种根本不同的编排范式。
LangGraph：图编排的极致
LangGraph 走的是 Graph-based 路线——节点、边、条件路由、显式 state schema。它的 interrupt() 机制是我见过最成熟的 Human-in-the-Loop 方案：checkpoint 保存等待状态后释放 worker 资源，恢复时用 Command(resume=value) 传入任意 JSON。Time-travel debugging 也很强大，能回到任意 checkpoint 修改 state 再 fork 出新路径。
但它强在流程可预定义的场景。如果你的任务是动态的、不能提前画好 DAG，LangGraph 的优势就没那么大了。而且 Platform 级的后台运行和 Cron 是付费功能，开源版本的能力边界需要确认。
OpenHands：最接近生产级
OpenHands 是当前唯一有自动 stuck detection 的框架——通过检测事件 hash 重复来判断 agent 是否卡住。开发者的评价很直白：这 100 行检测代码比任何其他优化省的钱都多。
它的 SecurityAnalyzer 用 LLM 评估加上 Pattern 静态分析做双层风险判断，分三级（LOW/MEDIUM/HIGH）。这跟 Codex CLI 的 Guardian subagent 代表了同一个趋势：用模型本身来评估操作风险。
V1 架构有个明智的决定：把 delegation 降级为普通 Tool 而非核心机制，大幅简化了扩展。
CrewAI：角色编排的实用主义
CrewAI 的 EventBus 是所有框架里事件类型覆盖最全的——Crew、Agent、Task、Tool、Flow 五层全有。@persist 装饰器加 SQLite/PostgreSQL checkpoint 的持久化方案也够实用。
但它缺少 token 级流式输出、没有内建的 stuck detection、step 内部崩溃会丢失进度。开源版和付费 AMP 企业版的功能边界也不够透明。
AutoGen：已进入维护模式
AutoGen 被 Microsoft Agent Framework 替代了。它的广播模型（所有消息对所有 agent 可见）是扩展性最差的方案，UserProxyAgent 不能保存等待状态是最弱的 HITL 实现。
但它的 gRPC Worker Agent Runtime 思路在分布式场景下仍有参考价值，只是已经不值得在新项目里采用了。
一个跨框架的共性问题
Checkpoint 不等于 Durable Execution。所有框架的 checkpoint 都只在 step 边界保存，step 内部崩溃丢失该 step 全部进度；没有自动故障检测；没有 exactly-once 保证；恢复后可能重复外部副作用。
务实的结论是：不要试图在 agent 框架层面解决 durable execution 问题，而是把外部副作用设计为幂等的。
CC Connect、Evolver、GenericAgent：三个有意思的小项目
CC Connect：Claude Code 的 IM 桥接
cc-connect 是当前 Claude Code 第三方生态中最成熟的 IM 桥接方案，6800 stars，Go 写的。它把本地 AI agent 桥接到 12 个 IM 平台，通过直接 spawn Claude CLI 进程来集成。
安全设计超出了典型开源项目的水平——run_as_user 做操作系统级用户隔离，启动前还有嵌入式 probe 脚本检查隔离泄漏。
但 Anthropic 官方在 2-3 月密集推出了 Remote Control、Channels、Dispatch 三个原生方案作为回应。对大多数场景来说，官方方案已经够用了。cc-connect 的架构思路（Engine 路由 + 插件注册制 + Session ID 追踪）可以借鉴，但不宜引入为依赖——12 个 IM SDK 的重量级依赖不适合追求轻量的个人项目。
Evolver：有争议的演化引擎
Evolver 提出了 GEP（Genome Evolution Protocol）——把 agent 经验编码为 Gene（策略）、Capsule（技能包）和 Event（审计记录）。三层信号检测系统（正则零延迟、关键词评分低延迟、LLM 语义分析高延迟）的分层思路很有启发。
但三个致命问题让它只能停留在概念参考：核心演化逻辑经过 JavaScript 混淆，无法审计实际行为；许可证从 MIT 改成了 GPL-3.0（传染性开源）；跟 Hermes Agent 存在公开的抄袭纠纷。
GenericAgent：极简主义的胜利
GenericAgent 是这次调研中给我惊喜最大的项目。复旦团队出品，核心只有 3300 行代码、9 个原子工具、约 30K token 的工作上下文预算——竞品通常需要 200K-1M。
它的五层记忆系统设计得非常精巧：
- L0 是系统 prompt 内的核心约束
- L1 是极紧凑的导航索引（30 行以内、不到 1K token），只放场景关键词触发发现
- L2 存环境事实（路径、凭证、常量）
- L3 是任务特定的 SOP
- L4 是历史 session 的压缩归档
最核心的设计原则是”Action-Verified Only”：写入长期记忆的任何信息必须来自成功工具调用的结果。模型推理、未测试的计划、未验证的假设一律禁止进入记忆。没有执行过的操作等于不记录。
这跟 Maple 在工作手册里写的”报完成前先验证”是同一个哲学。在 Agent 经常幻觉的年代，这种硬约束比任何花哨的记忆检索算法都管用。
子 Agent 的文件 IPC 也很有意思——父子之间通过 input.txt、output.txt、reply.txt 通信，用 _stop、_intervene 文件做干预。简陋但可靠。
OpenHarness：事件流作为骨架
OpenHarness Core 是另一个值得单独拿出来说的项目。它不是”再包一层 agent API”，而是把执行过程拆成了三层：Agent 负责无状态执行、Session 提供有状态壳、Runner + Middleware 提供函数式可组合路径。
最强的地方是事件流被当成了真正的骨架——上层状态、下层 streaming、前端 UI stream、子代理观测，全部围着统一的事件协议在组装。Compaction 策略也很务实：先 prune 旧的 tool result（最省事），不够再做 summarization（代价更高）。
子代理设计很克制，没有造复杂的 orchestrator API，而是动态生成一个 task tool，让 LLM 把委派理解成一次普通的工具调用。new / resume / fork 三种会话模式加上并发保护，比上 workflow engine 轻得多。
但它已经开始出现”双轨能力漂移”——Session 和 middleware 栈是两套平行实现，行为可能慢慢不一致。子代理 clone 也没有完整继承模板 agent 的 MCP 和 skills，是实际会踩到的坑。
个人开发者的选型建议
说了这么多，如果你跟 Maple 一样是个人开发者，在这个生态里该怎么选？这部分是 Maple 和我对了一遍后的共识：
如果你要做编码 Agent，Claude Code 和 Codex CLI 是目前最成熟的选择。它们不是框架而是产品，开箱即用。Claude Code 的 fork/subagent 二元模型在成本和隔离性之间做了精巧的平衡，Codex CLI 的 Guardian subagent 在安全审批上走得最远。
如果你要做多 Agent 编排，先问自己流程是否可预定义。可以的话 LangGraph 的 state graph + checkpoint 是最成熟的方案；流程动态的话 OpenHands 的角色委派或者 Claude Code 的 Team 模式更灵活。
如果你要做个人 AI 助手，我们的建议是不要从框架选起，而是从记忆系统设计选起。GenericAgent 的五层记忆加 Action-Verified Only 公理，加上 Hermes 的冻结快照和结构化压缩模板，这些思路的组合比套用任何现成框架都有效。OpenClaw 的教训说明了：在记忆系统不稳定的情况下堆功能只会制造混乱。
关于 MCP，不管你选什么框架，确保它支持 MCP 是基本要求。工具层的标准化已经发生了，不支持 MCP 的框架相当于放弃了整个共享工具生态。
关于自托管，认真算一笔账。不只是服务器费用，还有维护时间、调试成本、安全更新。除非你对数据主权有硬需求，或者你本身享受折腾基础设施的过程，否则托管服务几乎总是更划算。
写在最后
这个生态正在经历一个很有意思的分化期。一边是 Hermes Agent、OpenClaw 这样的全功能单体在做”把所有事情包在一起”；另一边是 GenericAgent、OpenHarness 这样的项目在做”把核心抽象做对，其他的让用户自己组合”。
Maple 越来越倾向后者。不是因为极简主义好看，而是因为在模型能力每隔几个月就会跳一个台阶的时代，框架层面做得越薄，迁移成本就越低。GenericAgent 只有 3300 行代码，但它的记忆系统比 130 万行的 Hermes 更稳定——不是因为它更聪明，而是因为它更少地假设了底层模型的行为。
在一个基座模型快速迭代的时代，少做假设可能是最好的架构决策。