Open Multi-Agent：把任务图交给运行时，而不是写死在代码里
具有动态工作流程的 TypeScript AI 代理编排框架。描述目标，而不是图表：协调员在运行时规划任务 DAG，并在任何 LLM（Claude、ChatGPT、Gemini、DeepSeek 或本地模型）上运行它。
秒懂
- 它是什么？
- Open Multi-Agent 是一个 TypeScript 多智能体编排框架，核心主张是“描述目标，而不是图”：协调器在运行时规划任务 DAG，调度器确定性执行，全程可审计、可恢复。本文基于其 README 与仓库信息，拆解它的机制、用法、边界与适用场景。
- 适合谁用？
- Open Multi-Agent 适合已经用 TypeScript 写后端、需要把多个 LLM 调用组织成可控流程的团队，尤其是那些受够了手写状态机、又担心全自动编排失控的开发者。它不适合只需要单次 prompt 调用、或者对运行时动态规划没有信任基础的项目，因为协调器生成的 DAG 本身可能不稳定，你需要先验证它在你的任务类型上的成功率。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 2 天前。
- 用什么语言写的？
- 主要是 TypeScript（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月14日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决的是哪一类问题
多智能体框架的常见写法是让开发者手工画一张图：谁先跑、谁的结果喂给谁、什么时候合并。这张图在需求变化时就要改代码。Open Multi-Agent 把这一步移到了运行时。你只给一个目标，比如“比较三种方案并推荐一个”，协调器负责把目标拆成任务 DAG，调度器按依赖关系执行，最后汇总结果。它的受众是 TypeScript 后端开发者，不是前端调 API 的脚本玩家。框架要求 Node.js 20 或更高，并且明确说生产环境要用当前维护的 LTS 版本。这意味着它假设你已经有一个正经的 Node.js 服务，而不是一个临时脚本。
运行时规划与确定性执行的分工
框架的核心机制是两层分离。第一层是协调器，它接收自然语言目标，在运行时生成任务 DAG，并为每个任务分配智能体。第二层是确定性调度器，它不重新解释目标，只按 DAG 的依赖关系执行任务，处理重试、超时、循环检测和 token 预算。这种分离让“动态”与“可控”不冲突：图的生成是模型行为，可能每次不同，但图的执行是确定性的，可以暂停、批准、恢复。README 强调“没有手写的图需要维护”，但同时也提供“声明必需角色和顺序”的选项，说明它允许在需要时锁定拓扑。这种设计承认了纯动态规划的不可预测性，给了开发者一个逃生门。
三种运行模式：runTeam、runAgent、runTasks
README 给出了三个入口。runTeam 是核心模式，接受一个团队定义和一句目标，内部走协调器规划。runAgent 只跑单个智能体，适合不需要协作的场景。runTasks 执行显式管线，适合你已经知道任务顺序的情况。示例代码里，团队定义只包含 agent 名称和 systemPrompt，加上 sharedMemory: true 表示共享上下文。调用 oma.runTeam(team, 'Compare three approaches and recommend one.') 之后，结果存在 result.agentResults 里，可以取 coordinator 的输出。值得注意的是，代码里没有任何地方声明任务图，这就是“描述目标”的体现。但 README 没有说明协调器是如何决定拆分的，是模型直接输出 JSON，还是有一套约束模板，这部分在文档里是缺失的。
从脚手架到现有后端：两种接入路径
快速体验用脚手架命令 npm create oma-app@latest my-oma，它会在交互终端里选择一个 starter 和 runtime，安装依赖，然后跑一个确定性本地 demo。这个 demo 不需要 API key，也不发模型请求，用脚本化的模型响应驱动真实的调度器、结果聚合和离线仪表盘。这设计很聪明，它让开发者先看到框架的执行机制，再决定是否接真实模型。对已有后端，直接 npm install @open-multi-agent/core，然后按示例初始化 OpenMultiAgent 实例，设置 defaultProvider 和 defaultModel。示例里用了 openai 和 gpt-5.4，但 README 说 provider 文档覆盖了其他托管模型、本地服务器、OpenAI 兼容端点和 AI SDK providers。环境变量 OMA_MODEL 可以覆盖默认模型，这给了部署时的灵活性。
可观测性与恢复：运行记录不是日志，是证据
框架把每次运行都变成可检查的数据。README 提到“稳定的身份、执行收据、追踪”，以及内置的离线 Run Viewer 可以回放任务 DAG 和 span 瀑布图。还可以通过可选的 OpenTelemetry 适配器导出。这意味着运行记录不只是一行行日志，而是结构化的、可重放的轨迹。恢复机制包括从检查点恢复中断的运行，以及在任务结果屏障处进行追加式的计划修复。这里有个取舍：计划修复是“追加式”的，意味着它不会推翻已执行的节点，只在边界处调整后续计划。这保证了已发生的事实不被篡改，但也意味着如果初始规划有严重错误，修复可能只是补丁。预算控制是硬性的，有 token 和成本预算，防止失控调用。
安全模型：默认拒绝的工具调用
工具调用是默认拒绝的，单个调用需要单独授权。这不是一个软提醒，而是框架层面的强制策略。README 说“Tools are default-deny, individual calls are gated”，意味着智能体想调用 bash 或文件操作，必须先过一道审批。这适合生产环境，但也带来交互成本：每个工具调用都可能打断流程。框架还提供隐私控制，应用于遥测和持久化状态。另一个安全点是支持进程和 ACP 后端，可以把 Claude Code、Gemini CLI、Codex 接入同一个任务 DAG，共享内存和预算。这扩大了适用范围，但 README 没有说明这些外部进程的隔离级别，比如它们是否运行在沙箱里，还是直接使用宿主机权限。这是采用前需要查文档确认的点。
本地模型与 fallback 解析器
框架支持本地模型，甚至提到有用户完全离线运行在量化模型上，靠协调器和上下文压缩在有限 VRAM 下维持自主循环。这里有一个具体机制：fallback parser，用于处理那些把工具调用以文本形式输出的本地模型。很多开源模型不原生支持工具调用格式，而是把 JSON 或 XML 打印在回复里。这个解析器就是干这个的。但这意味着本地模型的可靠性依赖解析器的健壮性，如果模型输出的格式稍有偏差，解析可能失败。README 没有给出解析器的容错率或失败处理细节，只提到它存在。对于想用本地模型的团队，这是一个需要实测的环节：先跑几个任务看解析成功率，再决定是否投入生产。
维护成本与许可：MIT 下的双刃剑
项目以 MIT 许可发布，2026 年 4 月 1 日启动，到 2026 年 8 月底已经发布到 v1.17.0，更新频率大约每周一个小版本。这显示上游很活跃，但也意味着 API 可能还在变动。采用者需要跟上发布节奏，否则可能积累技术债。README 列出了几个已知用户，包括 WordPress 安全分析平台、离线运行的贡献者、PR 审查助手和终端编码助手，但这些是案例引用，不是用户规模证据，不能作为成熟度判断。框架的依赖面不小，涉及 provider 适配、OpenTelemetry、进程管理，升级时这些都可能受影响。MIT 允许你 fork 修改，但如果你改动了协调器逻辑，就失去了上游更新的兼容性，这是每个开源采用者都要做的权衡。
编辑结论
Open Multi-Agent 适合已经用 TypeScript 写后端、需要把多个 LLM 调用组织成可控流程的团队，尤其是那些受够了手写状态机、又担心全自动编排失控的开发者。它不适合只需要单次 prompt 调用、或者对运行时动态规划没有信任基础的项目，因为协调器生成的 DAG 本身可能不稳定，你需要先验证它在你的任务类型上的成功率。采用前应确认三件事：你的 Node.js 版本是否满足 20+，你使用的模型是否被 provider 适配层支持（本地模型可能要走 fallback 解析器），以及你是否接受默认拒绝的工具调用策略带来的额外审批开销。MIT 许可意味着你可以改源码，但维护责任在自己，上游的发布节奏（v1.17.0 在 2026-08-28 发布）说明项目仍在活跃迭代，升级前应阅读 changelog 并跑一遍示例集。
社区笔记