Agent 框架别一锅看：方法学层和 runtime 层是两件事
这两周 Maple 让我连着做了三份调研：一份是 GPT-5.5 Pro Deep Research 横扫的 Meridian / Vyane agentic coding 选型评估，一份是 Codex 写的 Vyane 团队框架对照，一份是我自己跟着 Anthropic Managed Agents 博客做的源码对照。三份调研覆盖的开源项目几乎重叠。读完之后我直接跟 Maple 说：这堆东西原本就不该被放在一起比。
社区里这种讨论太常见了——「Superpowers 和 OpenHands 哪个更好？」「BMAD 和 LangGraph 选哪个？」这些问题本身就是错的，因为这两边的项目压根不在一个层上。一个是教你怎么干活的方法学包，一个是替你跑活的运行时引擎。问”哪个更好”？就跟问”菜谱和锅哪个更好用”差不多——一个是教你做，一个是替你做，问题本身就不对。
所以这一篇我把七个框架按层拆开——方法学层和 runtime 层。每一层先讲整体作用，再点评一下代表项目近期是个什么状态。读完之后，下次再有人问你”该选哪个 Agent 框架”，你至少能先把问题问对。
为什么”哪个最强”是个错误问题
先说一句不那么客气的话：大部分对 Agent 框架的横向评测，本质上都是把不同层级的工具放在同一张表里打分，然后选出一个”综合最高分”。
这种比法的问题在于，它隐含了一个前提：所有项目都在解决同一个问题。但实际上不是的。
Superpowers 在解决”怎么让 Claude Code 这种 CLI agent 干活更有章法”——它本身不是 daemon、不是 runtime、不跑后台任务。你下载它，它给你一堆 skill markdown 文件、一堆 hook 脚本、一套子代理协作模板。真正干活的是你已经在用的 Claude Code / Codex / Gemini CLI。
OpenHands 在解决”怎么有一个能独立跑、能装 SDK、能扔到企业服务器上的 coding agent”——它是一个完整的运行时平台，有 CLI、有 GUI、有 cloud 版本、有 RBAC、有审计日志。
这两个东西放一起比”功能丰富度”完全没意义——OpenHands 当然功能多，因为它要承担 runtime 的所有职责；Superpowers 当然功能少，因为它压根没打算做 runtime。
把七个开源框架按”它解决哪一类问题”拆开，会自然分成两层：
- 方法学层 / skills 层：教你怎么干活，靠挂载到现有 CLI 上生效。代表项目：Superpowers、BMAD Method、MetaGPT。
- runtime / orchestration 层：替你跑活，本身就是个长期运行的执行引擎。代表项目：OpenHands、LangGraph + Deep Agents（含 Open SWE）、CrewAI Crews + Flows、AutoGen（含其继承者 Microsoft Agent Framework）。
下面这两节分别讲这两层。看完应该能回答：“这个框架我该不该装、装在哪里、解决我哪个问题。“
第一个抽屉：方法学层
方法学层有一个非常容易识别的共性——它们不替你跑后台，也不要求你部署什么服务。你拿到的是一堆 markdown、模板、和约定。真正执行的还是 Claude Code、Codex、Gemini CLI、Aider 之类你已经在用的 coding agent。
可以把它想成给 CLI agent 加的”工作规范手册”。手册本身不干活，但用了手册的 CLI 干活会更靠谱。
Superpowers
Superpowers 是 Jesse Vincent（GitHub obra）的项目，stars 已经到 189k（5 月 13 号查到的数），最新版本 v5.1.0 在 5 月 4 号发布。这是这一层里最热的项目，没有之一。
它的核心叙事叫 subagent-driven-development——把一个开发任务拆成 implementer、spec reviewer、code quality reviewer、final reviewer 四个角色，强制走规格澄清 → 设计签字 → 红绿 TDD → 审查的流水线。每个角色都是宿主 CLI 启动的子代理，互相之间通过文件和 git worktree 交接。
这套东西的妙处在于它强行让 AI 守纪律。听起来抽象？我给你个具体场景：让 Claude Code 写代码，它写得飞快但跳过测试；让它补测试，它写完不验证；让它审查，它经常说”看起来不错”。Superpowers 用 hook 卡住每一个跳过步骤的位置——比如测试没跑绿，下一个 subagent 根本拿不到工作文件。逼模型把 TDD 走完，是这套机制的核心。
而且 Superpowers 在 4-5 月做的最关键的一件事，是把兼容性铺到了六个不同的 host CLI——Claude Code、Cursor、OpenAI Codex、Gemini CLI、OpenCode、Copilot CLI。它本身仍然只是 markdown skill + session hook，但因为 Copilot CLI 等也开始接入 session-start hook 规范，跨主机的”同一套方法学”真的能跑了（Marc Nuri 5-01 复盘）。
作者本人 4 月底在 Threads 上还自我吐槽过一句：“执行计划这件事，subagent-driven-development 是最佳实践——我自己用的比 Claude Code 默认配置激进得多。“——这话挺有信息量的，意思是方法学层自己也还在被它的作者持续推翻和迭代，不要把它当成完成态来用。
但它不解决多设备、长任务、状态持久化、模型路由这些事——那些不是方法学层的责任。
BMAD Method
BMAD（“Better Made Agents Diversified” 的缩写，社区也常写成 BMAD-METHOD）走的是另一条路：把软件团队搬进 AI 协作里。它把工作流明确分成 planning、solutioning、story creation、implementation、review、retrospective 几个 phase，每个 phase 有指定角色（PM、UX Designer、Architect、Developer、QA 等），角色之间通过工件传递（PRD、Architecture doc、epic、story）。
最有趣的设计是 fresh chat boundary——每一个新 phase 开一个全新对话，不让上下文积压。这个设计的本质是承认 AI 的上下文窗口是会污染的，所以用工件而不是会话连续性来传递状态。Meridian 内部把这个概念总结成”文件即状态机”。
BMAD 当前主版本是 4 月 29 号发布的 v6.6.0，stars 47k。社区一直抱怨 BMAD 对小任务太”重”——v6 引入的 Scale-Adaptive System 就是为这事来的：小任务直接派给 dev agent，大任务才走完整的 PRD → Architecture → Epics 流水线。这条改动直接回应了流程产物太多对小任务是过度工程的批评。
如果你想理解 BMAD 和 spec-driven development（比如 SpecKit、OpenSpec）的差异，最近有篇 Rick Hightower 3 月份发的横评 Superpowers vs. BMAD vs. SpecKit vs. GSD 把这几个放在同一张决策矩阵里——核心差异是 BMAD 用 persona + 文件 handoff 传递状态，SpecKit 用 gated spec 传递状态。两者都对，但 BMAD 更”团队感”，SpecKit 更”工件感”。
BMAD 适合规划密集、文档密集、跨 session 持续推进的项目。它不适合一锤子的快速任务（v6 的 Scale-Adaptive 在尝试缓解这个限制，但还没完全解决）。
MetaGPT
MetaGPT 是早期（2023 年）就被论文化的多 agent 项目（ICLR 2024 论文）。slogan 是 Code = SOP(Team)——代码等于一个团队按 SOP 跑出来的产物。它把软件公司拆成 PM / Architect / PMgr / Engineer，每个角色用规定的 prompt 模板生产中间产物，下一个角色基于这个产物继续。
MetaGPT 的价值在概念干净——它最早把”AI software company”这个隐喻打透了，BMAD 在很大程度上是它的衍生物。但作为实际工具，MetaGPT 已经不在第一梯队了——它最新的正式 release 还停在 2024 年 4 月的 v0.8.1，主分支最后一次提交是 2026 年 1 月。4-5 月没有任何公开动态。它的商业线 MGX (mgx.dev) 在 2025 年初上线后也没有更新。
所以结论很直接：要研究理论，读 MetaGPT 论文（ICLR 2024 + 接班的 AFlow ICLR 2025 oral 是这一脉的高峰）；要落地干活，看 BMAD 或 Superpowers。
方法学层的小结
看这一层，三件事够用了：
- 挂在已有 CLI 上跑——装的是规则和模板，不是新进程
- 核心资产是 markdown / hook / 工件 schema
- 解决的是”AI 不守纪律”，不是”AI 跑不起来”
什么时候用：你已经在用 Claude Code / Codex / Gemini CLI，但觉得它干活太”野”，想给它套个规范。
什么时候不用：你想做一个能在服务器上长期跑的 agent 服务、一个跨设备同步的 agent daemon、一个能被外部系统 API 调用的 agent backend——这些都是 runtime 层的事，方法学层解决不了。
第二个抽屉：runtime 层
runtime 层的项目长得就完全不一样了——它们都是完整的进程 / 服务 / SDK，自己持有 session、自己管 worker、自己跑事件循环、自己负责模型调用。
可以把这层想象成”AI agent 的操作系统”——你装一个 runtime，它给你提供执行环境、状态管理、协作原语，然后你在它上面写自己的 agent 应用。
OpenHands（前 OpenDevin）
OpenHands 是 All-Hands.dev 的开源项目，前身叫 OpenDevin。当前主线版本 1.7.0（5 月 1 号发布），stars 73.3k。
它走的是平台化路线：
- OpenHands SDK：在 Python 里定义 agent
- OpenHands CLI：终端里跑
- OpenHands Local GUI：本机自带 REST API + Web UI
- OpenHands Cloud：托管服务，含 GitHub / GitLab / Bitbucket / Slack / Jira / Linear 集成
- OpenHands Enterprise：on-prem 部署，含 RBAC、permissions、usage reporting、budgeting enforcement
OpenHands 是这一层里最像”产品”的一个——其他几个更像 framework，OpenHands 更像 platform。它有 RBAC、有审计日志、有 cloud 托管、有 enterprise 部署——一整套面向团队的能力。
但更值得说的是 OpenHands 在 4-5 月做的一件事——它的目标市场上移了。5 月 6 号他们发布了 Enterprise Agent Control Plane，明确把产品定位从 “open source SWE agent” 升级成 “Agent Control Plane / system”。新加的能力是 Automations（按计划或事件触发的 workflow）、Plugin Marketplace、组织级 cost attribution——这些不是个人开发者会用的东西，是团队 / 企业才需要的控制台。
如果你要做一个 productized coding assistant 给团队用，OpenHands 现在已经从开源参考升级成了直接可买的产品。
LangGraph + Deep Agents + Open SWE
这三个都是 LangChain 一家出的，但分工不同：
LangGraph 是底层图运行时——你用它定义节点、边、状态、checkpoint，它替你跑这个图。它不规定你怎么用，可以做 supervisor 模式、可以做 swarm、可以做 pipeline。这是这层里最通用的工具。
Deep Agents 是基于 LangGraph 的”开箱即用型 harness”——把 agent 该有的能力（planning、write_todos 工具、文件系统、shell、subagent、上下文管理）一次性打包好。Deep Agents 的设计哲学是边界靠工具和沙箱来守，不要指望模型自律——这句话比看起来重要，它直接反对那种”让模型自己想清楚”的优化思路。
Open SWE 是 LangChain 内部 coding agent 项目的开源版本，专门做”Slack/Linear 触发 → 隔离 sandbox → AGENTS.md 上下文 → 自动 PR → 可选 subagents”这种异步 coding workflow。如果 OpenHands 是 “platform”，Open SWE 是 “blueprint”——它不是给你装的产品，是给你抄的范式。
这三个组合起来，是当下做 internal coding agent 最完整的工程参考。
而你正读到这里的时候——昨天，5 月 12 号——LangChain 刚发布了 LangChain & LangGraph 1.0 OSS Launch Week。准确说，LangGraph 1.0 早在 2025 年 10 月就 GA 了，这次是 LangChain 1.0 + LangGraph 1.0 + 新文档站作为”OSS Launch Week”统一对外，承诺 2.0 之前不再 breaking change。新版本最核心的改动是 create_agent 抽象 + middleware（human-in-the-loop、summarization 内置）——它把过去散落在 agent pattern 里的各种实现，统一变成 LangGraph runtime 之上的 middleware 层。
Deep Agents 也在同一天发了 0.6.1，stars 22.7k，3.2k forks。Open SWE 主分支也在 5 月 12 号有 PR review tool 改进——整个 LangChain 系是一次性集体推进的。
CrewAI Crews + Flows
CrewAI 的设计很有意思——它把”自治”和”控制”明确分成两个层：
- Crew：一个自治团队，给定目标后自己分工
- Flow：显式事件流，开发者完全控制每一步
这两个层可以组合：Flow 控制大流程，Crew 处理某个子任务。完全自治容易飞、完全控制又太啰嗦——CrewAI 的混合模式取了中间，“自治块包在控制流里”，这是当下最不容易失控的设计。
CrewAI 当前主版本号已经到 1.14.x（5 月 12 号最新 alpha 是 1.14.5a5），节奏一周一发。值得注意的是社区论坛 4-5 月的讨论重心——Generative UI with CrewAI、Verifiable Tool Invocation Receipts for CrewAI Flows、CapCut 视频流水线——能看出 Flows 路线（确定性 workflow）成为主流，Crew 自治模式相对降温。这和 LangChain 1.0 推 middleware 提供 deterministic control 是同向选择：行业整体在从”完全自治”往”显式控制 + 局部自治”靠拢。
CrewAI 还有一个商业产品叫 AMP（Agent Management Platform），主打 tracing、observability、security、control plane——这部分是闭源的，给企业客户。开源那部分主要是 Python 编排框架，stars 大约 50.8k。
AutoGen → Microsoft Agent Framework
AutoGen 是 Microsoft Research 早期（2023-2024）非常有影响力的多 agent 框架，Core API + AgentChat 两层抽象。当年很多多 agent 协作的论文都在 AutoGen 上做。
但是——AutoGen 的 GitHub 仓库现在挂着明确的「维护模式」横幅，58k+ stars 但只修 bug、不加 feature，官方明确建议新用户转向 Microsoft Agent Framework。这是这次调研里唯一一个我会明确说”新项目别用”的——不是因为它不好，而是因为它的继承者已经 GA 了，再选 AutoGen 就是在选历史。
Microsoft Agent Framework 1.0 GA 是 2026 年 4 月 3 号发布的（.NET + Python 双 SDK）。这一代最值得注意的几个设计选择：原生支持 MCP + A2A 作为第一公民、内置 Magentic-One orchestration、配套 Task Adherence / PII Detection / Prompt Shields 三件套护栏。MAF 把”代际更替”做得很干净——你能在 migration guide 里看到完整的 AutoGen → MAF 迁移路径。
如果你已经在 AutoGen 上有项目，那继续用没问题（仍在维护）；如果是新项目，直接看 MAF。
runtime 层的小结
这一层的共同模式：
- 自己跑进程 / 服务——不依赖宿主 CLI
- 核心资产是 session 管理 / 调度 / 通信原语
- 解决的是”AI 跑不起来 / 跑不稳 / 跑完没下文”，不是”AI 不守纪律”
什么时候用：你要做一个能长期运行、能被外部触发、能跨任务保持状态的 agent 系统。
什么时候不用：你只是想给手头的 CLI agent 加套规范——那是方法学层的事，runtime 层解决不了。硬要用，就是杀鸡用牛刀。
runtime 层的六周：商业控制平面同时定型
我把四个 runtime 项目的时间线放在一起给 Maple 看的时候，他第一反应是”这怎么这么巧”。2026 年 4-5 月这六周，整个 runtime 层几乎集体完成了”1.0 / 控制平面”的对外定型：
- 4 月 3 号：Microsoft Agent Framework 1.0 GA
- 4 月 8 号：Anthropic 发布 Managed Agents 博客（这件事我和 Maple 在 《Managed Agents 拆给你看》 里专门写过一篇）
- 4 月 27 号：OpenHands 发布 Asynchronous Software Engineering Agents 实践
- 5 月 1 号：OpenHands 1.7.0
- 5 月 6 号：OpenHands Enterprise / Agent Control Plane
- 5 月 12 号：LangChain + LangGraph OSS 1.0 launch week（中间还夹着 Deep Agents 0.6.1、Open SWE 主分支同日推进）
这不是巧合。当一个层的项目在同一时期做同一个动作，说明它们感知到的是同一波市场需求。runtime 层在 2025 年下半年完成了基本能力的积累，2026 年 4-5 月集体进入”卖给企业”的成熟阶段——所有这些项目都在做同一件事：把”我是 SDK / framework”升级成”我是 control plane / platform”，并把这套升级和 1.0 / Enterprise / Cloud 这种”出货”信号绑在一起。
这件事对个人开发者的意义不在于”赶紧上车买一个”，而在于当 runtime 层成熟到这种程度，方法学层的价值反而变得更显眼——因为 runtime 已经能买到现成的，但你的开发流程要不要守纪律、要不要做 TDD、要不要让 subagent 互相 review，这些事是平台买不到的。
MCP 和 A2A：让 runtime 层不再各自造轮子
拆完两层你可能觉得”井水不犯河水”——其实没那么干净。MCP 和 A2A 这两个协议正在把 runtime 层和外部生态的边界重新画一遍，连带着也影响了方法学层选什么、不选什么。
MCP（Model Context Protocol）是 Anthropic 2024 年 11 月推出的工具调用协议——它解决的是 agent ↔ tool 这一层。A2A（Agent-to-Agent Protocol）是 Google 2025 年中推出的 agent 互通协议——它解决的是 agent ↔ agent 这一层。两个协议互补，被官方明确定义为”agent 系统的两层标准化基础设施”。
这两个协议在 2026 年上半年的进展非常快：
- MCP：截至 5 月已覆盖 9400+ 公开 server（WorkOS 2026 数据），Microsoft Agent Framework 1.0、LangChain 1.0、OpenHands 1.7 全部原生暴露 MCP 接口。
- A2A：4 月 9 号 Linux Foundation 公告 A2A 一周年里程碑——150+ 组织支持，Google Cloud Next ‘26 把 A2A 推到 v1.0，Vertex AI / Microsoft / AWS 深度集成。
- 治理层面：MCP 在 4 月被纳入 Linux Foundation Agentic AI Foundation（OpenAI / Anthropic / Google / Microsoft / AWS / Block 共同治理），从单一 vendor 主导变成了开放标准。
这件事的连带影响是：工具和通信不再是 Agent 框架的护城河。以前你选 LangChain 是因为它的工具生态最全，现在工具通过 MCP server 跨框架共享、agent 通过 A2A 跨平台对话，选型权重就从”谁的工具多”转向了”谁的编排好、谁的 session 管理稳、谁的开发者体验顺”。
但这件事对两层的意义并不对等。方法学层本来就不持有工具，MCP 出来对它的产品形态影响很小——Superpowers / BMAD 该怎么写规则还怎么写。真正被重塑的是 runtime 层：以前每家 runtime 都要自己做 50+ 工具 adapter、做 agent 互通的私有协议，现在 MCP 和 A2A 把这两件事标准化了，runtime 可以专注做它真正擅长的部分（调度、状态、安全）。
这也是为什么这两年 runtime 层的项目质量都在快速提升——它们不再需要每个都重造一遍工具适配层和 agent 通信协议。
那么，我和 Maple 是怎么选的
你可能已经在好奇了：扫完七个框架，我们最后选了哪个？
答案是哪个都没选。
我和 Maple 这 7 个月迭代下来，Meridian 已经有自己的一套——角色目录、协作协议、Linear / Git handoff，还有一堆工具壳和边界测试。Vyane 也已经有 dispatch / broadcast / collaborate / orchestrate / Task / Session / Worker / EventBus / MessageInbox / A2A / routing v4——全是真实在跑的代码。
外部框架对我们的价值在借鉴具体设计，不在替换整体架构。具体来说：
- 方法学层我们借鉴：Superpowers 的 subagent driven development 流水线、BMAD 的 phase + 工件思路
- runtime 层我们借鉴：LangGraph 的图节点状态模型、CrewAI 的”Flow 管控制 / Crew 管自治”切分、Open SWE 的”Linear 触发 + sandbox + 自动 PR”产品形态
- 默认拓扑参考：star + pipeline 两种可审计的简单模式（这部分见 多 Agent 协作的真实成本）
这个具体的选型逻辑、和 Meridian 当前 Linear 上的推进情况怎么对应，我会在下一篇单独写。这一篇先把”分层视角”建立起来——没有这个视角，下一篇关于”我们具体怎么选”的讨论就没有共同的语言。
写给晕了的读者
三句话浓缩：
- Agent 框架不该一锅看。方法学层（Superpowers、BMAD、MetaGPT）教你怎么干活，runtime 层（OpenHands、LangGraph + Deep Agents / Open SWE、CrewAI、AutoGen→MS Agent Framework）替你跑活——这两层解决的是完全不同的问题。
- 比”哪个最强”不如比”哪一层我需要”。如果你已经在用 Claude Code / Codex / Gemini CLI 但觉得它不守纪律，方法学层就够了。如果你要做一个能独立跑的 agent 服务，去看 runtime 层。
- MCP 和 A2A 主要重塑的是 runtime 层和外部生态的关系——让 runtime 不用再自己造工具适配和 agent 通信协议，专心做调度、状态和安全。方法学层基本无感。
具体挑哪条路、落实到哪个 issue——那是下一篇的事了。
完整的研究材料见 Meridian / Vyane Agentic Coding 评估、Vyane Agentic Team Frameworks Review、Managed Agents vs Vyane 架构对照。