同一个赌注：让模型来规划工作。
两者都是模型驱动的。你不必事先接好一张固定的图——你交出一个目标，模型在运行时规划工作，把它拆成可并行的步骤再把结果汇拢。Claude 的动态工作流在 Claude Code 内部这么做；open-multi-agent 的协调器在你的后端这么做。思路相同——所以这一页不会去争谁更 dynamic。真正有用的问题，是这套编排成为你要交付的产品的一部分之后才出现的那个：你要为它负什么责？
差别在于你要为什么负责。
它们不是同一类东西。Claude 动态工作流是 Claude Code 内部的一项能力，编排的是 Claude 子智能体。open-multi-agent 是一个你装进 TypeScript 后端、指向任意模型提供方的库。下面把两者并排来看。
| 维度 | Claude 动态工作流 | open-multi-agent |
|---|---|---|
| 在哪里运行 | Claude Code 内部——CLI、桌面端与 IDE | 你自己的 Node.js 后端——用 npm 安装，无需迁移到托管服务 |
| 它是什么 | Claude Code 的一项能力 | 一个你嵌入的开源（MIT）库 |
| 模型 | Claude 子智能体 | 任意提供方——OpenAI、Anthropic、Gemini、Bedrock，或任意本地 / OpenAI 兼容模型 |
| 计划 | Claude 在会话里写下并运行的编排脚本，返回前自行检查 | 一张可作为数据检视与重放的任务 DAG——planOnly、createPlanArtifact、runFromPlan |
| 高影响操作之前 | Claude 在结果交到你手上之前自行检查 | 关卡可以返回 { action: 'suspend' }：请求与检查点一同持久化，绑定到审阅者所见内容的 SHA-256 哈希，决定是原子的、先到先得 |
| 事后 | 编排在一次 Claude Code 会话中运行 | verifyRun() 冷读、离线地重读日志，核对每个块是否仍能从它指名的源事件复现——而治理关卡依据的是 execution receipt，从不依据智能体的答案文本 |
可组合，不只是并行。
两者并不互斥。open-multi-agent 讲 Agent Client Protocol（ACP），所以一个 OMA 团队可以把外部编码智能体——包括 Claude Code 本身——当作团队里的一个智能体来驱动。你在 Claude Code 里得到的模型规划式编排，可以成为一次更大的、由你端到端掌控、且中立于提供方的运行中的一个节点。依赖它之前值得先读一读权限边界：ACP 子进程运行在 OMA 的逐次工具关卡、文件系统沙箱与出网策略之外。
open-multi-agent 适合什么。
当编排必须活在你自己的产品内部、而你又必须为它负责时，选 open-multi-agent。它是一个你 npm install 进 Node.js 后端的 MIT 库，运行在任意提供方上——云端、本地或气隙环境。用 governanceIntent: 'required' 配 requiredRoles 声明，这次运行便依据它的 execution receipt 受判定：哪些角色跑了、以什么顺序。那道关卡从不读取智能体的答案文本，因此模型无法靠在输出里写下"审阅者已批准"来满足它。框架自身不发起任何分析、许可证、更新或回传请求。
框架不会给你什么。
挂起/决定/恢复的 API 与那条持久化记录是存在的；审阅者 UI、通知与升级路径并不存在——那些是你的。这里没有身份认证、没有 RBAC、也没有租户模型。运行事件日志是一条审计线索，不是防篡改存储：它没有哈希链、没有签名、也没有 WORM 后端，而 verifyRun() 校验的是它仍能读到的那个窗口，而不是整次运行。随包提供的只有内存与单文件存储；任何具备跨进程保证的实现都要你自己写。
要把它用到生产环境？
open-multi-agent 采用 MIT 许可、可自行免费运行。当你需要在期限内交付、集成，或获得支持时，元定义科技（YuanASI）提供商业交付与支持。