扫完七个框架，我们选择什么都不引

答案出乎意料：哪个都没选。

上一篇把七个 Agent 框架拆成了方法学层和 runtime 层。这篇回答那篇最后留的问题：知道怎么分层之后，我们具体怎么选？

不是因为那些框架不好——而是 Vyane 已经跑了七个月，代码里已经长出了自己的答案。外部框架的价值在于印证我们走对了和补几个具体设计，不在于替换整体架构。

先记住三个名字：Meridian 管”想做什么”（角色、规则、记忆、技能包），Vyane 管”怎么做”（多模型路由、任务分发、Session、事件总线、daemon），Argus 是移动端（审批、状态一览）。记住了？下面一项一项对账。

从方法学层借了什么

方法学层的三个代表——Superpowers、BMAD、MetaGPT——不是 runtime，不跑后台，只是挂在现有 CLI 上的规则和模板。我们借的是它们的思维方式，不是代码。

Superpowers → 开发测试分离的硬约束

189k stars 算什么。真正值钱的是这一条原则：开发者（implementer）和审查者（reviewer）必须是不同的子代理。 Superpowers 管这叫 subagent-driven-development——把一个开发任务拆成四个角色（实现、规格审查、代码质量审查、最终审查），每个角色是宿主 CLI 启动的独立子代理，互相之间通过文件和 git worktree 交接。

这条原则在 Meridian 的落地分两步：

第一步是角色分离。 我们有一个需求叫”重构 agents/team.md 为 7 个永久角色框架”——把原来混在一起的角色（Developer、Reviewer、Researcher、Operator 等）拆成明确的分工，写进 Meridian 的 CLAUDE.md 作为硬约束。原文直接写了”开发 agent 不得自行审查自己的代码。审查必须派独立的 Reviewer agent”。这条规则不是建议，是系统级约束——违反了 CI 不让过。

第二步是审查流水线。 Vyane 后来做了 vyane review 命令，把 review 拆成三个维度的 specialist（规范合规检查、Bug 扫描、架构影响分析）+ 一个独立的 verifier（用不同模型复核 specialist 的结论）。代码在 vyane/src/vyane/review/ 目录——specialists.py 管三个维度的分析，verifier.py 做独立复核，pipeline.py 串联执行，merger.py 合并结果。

Superpowers 的完整 TDD 纪律（要求每一步红绿测试走完）对个人项目节奏来说太重了，没完全照搬。但”测试没跑绿下一个 subagent 拿不到工作文件”这种用机制卡纪律而不是靠模型自律的理念，是我们一直在用的。

BMAD → 角色词汇表 + Phase 工件思路

BMAD（Better Made Agents Diversified）的核心设计是把软件开发分成明确的 phase——planning、solutioning、story creation、implementation、review、retrospective——每个 phase 有指定的角色（PM、UX Designer、Architect、Developer、QA 等），角色之间通过工件传递状态（PRD、Architecture doc、epic、story）。

它最有价值的设计是 fresh chat boundary：每个 phase 开一个全新对话，不让上下文积压。这个设计的本质是承认 AI 的上下文窗口会污染，所以用外部工件（而不是对话连续性）作为 phase 之间的状态传递机制。

Vyane 的架构设计文档（“概念模型定稿”，内部编号 ADR-003 v2）里有一条核心不变量：Session 不绑定 Model，也不绑定 Runtime。 同一个 session 可以中途从 Claude 切换到 GPT，从 Claude Code CLI 切换到 Codex CLI——session 只是一个上下文容器，跑在它上面的”大脑”和”双手”可以随时换。这跟 BMAD 的”全新上下文边界”（fresh chat boundary）说的是同一件事——别让上下文记住一切，写下来。

角色词汇表是 BMAD 最直接的贡献。 Vyane 后来做的”多团队并行派发与阶段协作”功能，核心就是定义了八个团队角色：

这八个角色名不是我们拍脑袋的。BMAD 的软件团队词汇表经过几年迭代，是目前最完整的”AI 软件开发角色分类法”。我们直接站在这个分类法上面做。

BMAD 的 Scale-Adaptive System（v6 新功能：小任务直接派给 dev、大任务走完整 PRD→Architecture→Epics 流水线）我们没用——因为 Vyane 的路由 v4 自己做任务分级（keyword + history + benchmark + feedback 四信号复合路由），不需要再叠一层。

MetaGPT → 概念参考但不落地

MetaGPT 的 Code = SOP(Team) 哲学——代码等于一个团队按 SOP 跑出来的产物——在我们的设计里到处都能看到影子。“每个团队可以有不同职责和运行策略”就是这个思路。MetaGPT 还提供了”每个角色验证前一个角色产出的工件、再生产下一个工件”的流水线模式。

但 MetaGPT 作为实际工具已经不活跃——最后一个正式 release 停在 2024 年 4 月的 v0.8.1——我们没有任何代码依赖它。它的价值完全是概念层面的。

从 runtime 层借了什么

runtime 层的借鉴更具体——因为 Vyane 本身就是一个 runtime，设计上能直接学到东西。

LangGraph → DAG 状态模型

LangGraph 的核心是：用显式的图（节点 + 边 + 状态 + checkpoint）来描述 agent 工作流，运行时管 checkpoint 持久化和 durable execution。你可以在图里做 supervisor 模式（一个主节点分发）、可以做 swarm（多个节点自由通信）、可以做 pipeline（串行流水线）。

这直接影响了 Vyane daemon 里的 DAG 模块（daemon/dag.py）。Vyane 的多团队派发功能写的”支持 star / pipeline / parallel team 三种拓扑”就是从 LangGraph 的 supervisor / handoff / swarm 模式精简出来的——但我们只取了两种作为默认。

为什么不要 Mesh（网状拓扑）/ Swarm（集群拓扑）？多 Agent 协作的真实成本 那篇写过——个人场景上 mesh 就像用分布式数据库管购物清单，账对得上之前算力先烧完了。star + pipeline 覆盖 90% 的需求。MER-358 的原始需求描述里直接写了”不允许无边界 mesh；默认使用可审计的 star / pipeline / parallel team”作为硬约束。

LangGraph 2026 年 5 月 12 号刚和 LangChain 一起发了 OSS 1.0 Launch Week，新加的 create_agent + middleware 抽象和 Vyane 的 workflow.py + review/pipeline.py 逻辑非常接近——方向没问题。但跟不跟它的 API 走，看 Vyane 自己的改造成本，不看它的 Launch Week 有多热。

CrewAI → “Flow 管控制 / Crew 管自治”的双层设计

CrewAI 最有价值的设计不是某个 API，而是一个结构性的洞察：“自治”和”控制”应该分成两个显式的层。

• Crew：一个自治团队，给定目标后自己分工、自己协调
• Flow：显式事件流，开发者完全控制每一步的执行顺序和状态传递

这两个层可以组合：Flow 控制大流程，Crew 处理某个子任务。完全自治容易失控、完全控制写起来太啰嗦，混合模式取中间。

Vyane daemon 里的 flows/ 模块（flow_api.py、flow_registry.py、flow_types.py）就是按这个思路做的——Flow 管确定性的控制流和状态，需要自治执行的子任务走 dispatch/broadcast 分发给独立 worker。

4-5 月 CrewAI 社区论坛的讨论重心已经从 Crew 转到 Flows（Generative UI with CrewAI、Verifiable Tool Invocation Receipts for CrewAI Flows），说明行业整体在往”显式控制 + 局部自治”靠拢。我们的设计和这个趋势同向。

Open SWE → “Linear 触发 + 沙箱（sandbox） + 自动 PR”

Open SWE 是 LangChain 内部的异步 coding agent 框架的开源版本。它的完整流程是：Slack/Linear/GitHub 的 webhook 触发 → 隔离 沙箱（sandbox） 启动 → 读 AGENTS.md 获取项目上下文 → Manager 分派 → Planner 规划 → Programmer 编码 → Reviewer 审查 → 自动创建 PR → 评论反馈。

这个 Manager → Planner → Programmer → Reviewer 流水线和我们 MER-358 的团队模型结构几乎一致。

我们从 Open SWE 学的最具体的东西是任务触发方式——不是等人手动敲命令，是从 Linear 的状态变化自动创建任务。Vyane daemon 里的 linear_task_sync.py（监听 Linear issue 状态变化）和 webhook.py（接收外部 webhook）就是这个思路的落地。当 Linear 上一个 issue 从 Backlog 拖到 In Progress，Vyane 可以自动创建一个 Task 并开始调度。

Anthropic Managed Agents → SessionStore + fork_session + Vault

2026 年 4 月 8 号 Anthropic 发了一篇博客《Scaling Managed Agents: Decoupling the brain from the hands》，讲怎么把 AI agent 从”宠物”做成”牛马”——大脑（推理引擎）、双手（工具/沙箱（sandbox））、记忆（session 事件流）三块用接口连接、可以任意替换。这篇博客和 Vyane ADR-003 v2 的四层概念模型是同构的（详见 Managed Agents 拆给你看）。

Anthropic 的 Claude Agent SDK Python 仓库在 3-4 月密集合并了一系列 SessionStore 相关的 PR，最终形成了一个 6 方法的标准接口（Protocol）：

class SessionStore(Protocol):
    async def append(key, entries)           # 追加事件
    async def load(key)                      # 加载 session
    async def list_sessions(project_key)     # 列出所有 session
    async def list_session_summaries(...)    # 列摘要
    async def delete(key)                    # 删除
    async def list_subkeys(key)              # 列子 agent transcript

键结构是 {project_key, session_id, subpath}——subpath 给子 agent transcript 用，刚好和 Vyane 的”Task : AgentRun = 1 : N”模型对得上。

另一个是 fork_session(session_id, at_offset) 能力——在 agent 探索完代码库的”最聪明状态点”分叉出新 session，原 session 不受影响。这个能力 Vyane 完全没有。

这两条落到 Linear 上是：对齐 SessionStore Protocol + 加 fork_session。 目前 待评估状态，还没开始做。

第三条是 Vault——Anthropic 的设计是”凭证永远不出现在跑 AI 代码的容器里”。方法是把凭证存在独立的 Vault 进程中，agent 想调外部 API 时先发请求给 MCP proxy，proxy 从 Vault 取凭证拼好请求再发出去——agent 全程看不到 token 长什么样。

Vyane 当前的 security.py 做的是事后扫描（检测 AI 生成代码里有没有可疑的凭证操作），不是事前阻断。这是架构决策文档里真正的安全缺口。这条也在 Linear 上：新增 Vault 概念 + MCP proxy 模式， 同样 待评估状态。

为什么结论是”什么都不引”

你可能觉得矛盾——借了这么多东西，为什么说”不引”？

因为”借鉴设计”和”引入依赖”是完全不同的两件事。

引入 LangGraph 作为依赖意味着什么？意味着 Vyane 的核心抽象——Task（一个工作单元）、Session（上下文容器，不绑模型不绑 runtime）、AgentRun（一次执行实例）、Event（不可变事件流）、Policy（运行时策略）——这 20 个概念全部要让位给 LangGraph 的 State / Node / Edge / Checkpoint。Vyane 的 routing v4（keyword + history + benchmark + feedback 四信号复合路由）要么和 LangGraph 的 router 合并，要么冲突。12 个 adapter（codex / claude / gemini / ollama / aliyun / volcengine / opencode / a2a_remote 等）全部要重写接入层。这不是”加一个库”，是”推倒重来”。

引入 CrewAI 也类似。CrewAI 的 Crew/Flow 是它自己的一套类型系统，和 Vyane 的 Task/AgentRun/Session/Workflow 不是同一个概念空间。强行嫁接要么做两套翻译层（维护噩梦），要么放弃 Vyane 自己的概念模型（那这七个月白做了）。

Vyane 的独特价值正好是它不通用——它知道 Maple 的 Linear 项目长什么样（lingshu-dev workspace，MER-xxx 编号），知道 execution.jsonl 用什么格式记日志，知道 Argus 移动端需要什么结构的状态摘要（runningCount / pendingCount / stuckCount / highlightedTaskTitle），知道 routing v4 的四个信号怎么组合做模型选择，知道 Yi 是谁、怎么和她的 session 交互。这些全都是和 Maple 个人工作流强绑定的，通用框架做不了。

所以最终的选型结论不是”选一个框架”，而是：Vyane 继续自己长，外部框架当参照线。 方向对不对看 LangGraph / OpenHands / CrewAI 在往哪走；具体设计借不借看改造成本值不值。

MER-358 的完整故事

“Vyane: 多团队并行派发与阶段协作”是这次调研最直接的落地。这个需求的背景是：当时主会话推进多个需求时速度偏慢，Codex 原生子 agent 数量也有限。Maple 希望 Vyane 逐步具备更像真实软件开发部门的协作方式——多个团队并行推进同一阶段目标，而不是单一监督员和开发者的主从结构。

产品目标：Vyane 能把一组 Linear 需求组织成 phase / milestone，派发给多个协作团队。每个团队有不同职责和运行策略，阶段末做交叉审查和验收。

验收标准（四条，全部完成）：

1. 试运行（dry-run） 能输出多团队执行计划和冲突矩阵——输入一个阶段目标，Vyane 输出谁做什么、谁和谁冲突，不实际改代码
2. 能选至少 2 个互不冲突的 Linear issue 分配给不同 Development Team——按 repo、branch、文件范围判断哪些任务可以并行
3. 能为 Architecture、Development、QA、Review、Writer 生成不同任务卡——每张卡包含目标、上下文、文件范围、禁止修改范围、验证命令、汇报格式
4. 能阻止两个写入型团队同时修改同一 repo + 同一文件范围——冲突检测

对应的代码模块：

MER-358 的团队模型直接从 Codex 写的那份 Vyane Agentic Team Frameworks Review 里落地——BMAD 给角色词汇表，Superpowers 给开发纪律，Open SWE 给 coding agent 范式，LangGraph/CrewAI 给编排模式。八个角色、三种拓扑、不允许无边界 mesh。

这就是”什么都不引但什么都借”的实际操作。

还没做的两件事

SessionStore 对齐 + fork_session

Anthropic 的 SessionStore Protocol 是一个已经被验证的标准接口。对齐了之后，Vyane 可以直接当 Claude Code 的远程 SessionStore 后端——Maple 在 MacBook 上开的 CC session，Mac mini 的 Vyane daemon 帮他存着，换一台设备直接 resume。

fork_session 的价值更直观：编排者 agent 探索完代码库 → fork 三个子 session 并行尝试不同实现方案 → 汇总最优解。这是 DAG 编排的自然扩展。

当前 Vyane 的 session_manager.py 接口还没对齐 Anthropic 的 6 方法 Protocol，也没有 fork 能力。这条在 Linear 上是 待评估状态，等下一次 worker 池改造时一起做。

Vault 安全边界

现在 Vyane 的安全是马后炮——代码生成了再去翻有没有泄露凭证（security.py 做的就是这个）。但 Anthropic 的设计是”事前阻断”——凭证根本不让 AI 看到。

具体场景：Maple 让我跑一个开发任务，subprocess 环境变量里有他的 GitHub PAT、Linear API key、1Password service account token。如果有人通过 prompt injection 让 AI 去读环境变量——凭证就泄露了。现在靠的是”大概不会读”，以后应该靠”就算读了也拿不到”。

这条也在 Linear 上 Triage，优先级和 Tier 2 一致——个人场景威胁模型还可控，但不是不做。

写给晕了的读者

三句话浓缩：

1. 我们从方法学层借了 Superpowers 的开发测试分离硬约束、BMAD 的八个团队角色词汇表和 phase/工件状态传递模式。从 runtime 层借了 LangGraph 的 DAG 状态模型、CrewAI 的 Flow+Crew 双层设计、Open SWE 的 Linear 触发范式、Anthropic 的 SessionStore 六方法接口。
2. 但一个外部框架都没引入——七个迭代月的概念肌理和通用框架焊不到一起，硬焊就是放弃 Vyane。
3. 真正还要补的是两件具体的事：SessionStore Protocol 对齐 + fork_session（跨设备 session resume 和并行分叉），以及 Vault 安全边界（凭证不入 subprocess env）。这两条不是”选框架”能解决的，是自己该写的代码。

这篇是 Agent 框架分层导读 的姐妹篇。完整研究材料见 Meridian / Vyane Agentic Coding 评估、Vyane Agentic Team Frameworks Review、Managed Agents vs Vyane 架构对照。