Open Multi-Agent：用 TypeScript 跑动态任务图

“多用几个 Agent”不是架构。真正难的是哪些任务能并行、哪个结果会解锁下游、Worker 共享什么状态、一个分支失败后整体如何收场。Open Multi-Agent（OMA）没有把这些问题藏进群聊，而是把它们变成运行时任务图。

先说结论

任务存在真实并行分支和依赖关系时，OMA 才能体现价值。

它能把 LLM Worker、Claude Code、Gemini CLI、Codex、ACP 与本地进程放进同一 DAG。

planOnly、持久化 Run、回放、审批与显式 Pipeline 让流程可以检查。

新版内建工具默认拒绝，但老版本曾隐式开放无沙箱 bash，必须核对锁定版本。

生产上先写显式任务图；有计划评测数据后，再让 Coordinator 动态生成 DAG。

OMA 到底是什么

Open Multi-Agent 是 2026 年 4 月发布的 MIT 开源 TypeScript 框架，核心包为 @open-multi-agent/core，运行在自己的 Node.js 环境。它不是基于 tmux 的 OMAR，也不是学术论文里泛指的开放多智能体系统。

Open Multi-Agent GitHub 仓库 OMA 的定位是自托管、可检查的动态任务图，而不是托管 Agent 服务。来源：GitHub。

模式	谁定义任务图	适用场景
`runAgent()`	不需要图	单 Agent 基线与简单任务
`runTeam()`	Coordinator 动态生成 DAG	目标形态经常变化的开放任务
`runTasks()`	应用明确写出任务与依赖	可重复生产流程

这个区分很务实：不是所有问题都需要 Planner，也不是所有并行计算都需要多 Agent 对话。

DAG 为什么比聊天记录可靠

假设一次发布审查需要 API 兼容性、依赖风险、迁移文档和测试证据。API 与依赖扫描可并行；迁移文档依赖 API 结果；最终判断等待所有分支。

检查 API ─────> 写迁移文档 ──┐
                             ├─> 最终评审
扫描依赖 ────────────────────┤
运行测试 ────────────────────┘

DAG 中 Ready、Blocked、Failed、Complete 都是明确调度状态。群聊则让模型从自然语言里猜当前进度。任务变长、进程崩溃后恢复时，两者差距会迅速放大。

任务节点也是预算与证据的天然单位：Assignee、输入、依赖、Token、输出、验证和状态都能记录。最终结论错了，可以追到提供错误证据的分支，而不是重读几十轮聊天。

自动规划是风险最高的一层

Coordinator 把 Goal 变成任务与依赖边，Scheduler 并行执行已就绪节点。这个设计很诱人，但一张错误任务图，可能比一个普通 Worker 的坏答案浪费更多钱。

planOnly: true 可以先看图再执行。进入 CI 前，至少验证：图是否无环；依赖是否指向真实节点；拥有写权限的节点是否会并发改同一文件；任务数、深度、Token 与时长是否超限；验证与综合节点是否存在；Coordinator 是否越权分配工具。

固定流程优先 runTasks()。只有任务形态确实随目标变化时，动态规划才值得引入。

把外部 Coding Agent 放进同一张图

OMA 当前的外部 Agent 集成支持 ACP 与本地进程 Backend。Claude Code、Gemini CLI、Codex 或其他 Agent 可以执行某个节点，而 OMA 继续掌握规划、调度、共享记忆、预算和故障传播。

OMA 外部 Coding Agent 集成文档 外部 Agent 是执行者，OMA 仍是控制面。来源：External Agents Guide。

这种做法比“所有 Agent 都有统一原生协议”的想象更可信。Claude Code 在官方示例中也需要 ACP Adapter，不支持 ACP 的工具则可以用 Process Backend 连接。

每个外部进程都应拿到窄工作目录、明确环境变量和超时。共享记忆用于传递任务产物，而不是堆放未经筛选的 Prompt、Secret 与工具输出。

一次值得认真看的安全改动

OMA 早期会隐式给 Agent 全部内建工具，包括未沙箱化的 bash。v1.7 将它改成默认拒绝：没有 tools 或 toolPreset 的 Agent 得到零个内建工具。Release Note 直接指出旧默认值可能被 Prompt Injection 利用，形成远程执行与数据外泄路径。

OMA Release 中的默认拒绝工具改动 安全默认值变化很快，因此不能只读最新 README，还要核对实际锁定版本。来源：OMA Releases。

危险的升级方式，是为了让旧代码继续跑而全局设置 defaultToolPreset: 'full'。更稳妥的授权是按角色最小化：Planner 不给文件与 Shell；Researcher 只给白名单网络与只读记忆；Developer 获得限定目录和沙箱命令；Reviewer 只读文件与测试证据；Synthesizer 只读任务产物。

任务分配和工具授权也必须分开。Coordinator 可以把开发任务交给某 Worker，但不能顺手扩大它的权限。

Consensus 不等于事实

OMA 新版支持 Consensus 与对抗验证：多个 Proposer 给答案，再由 Judge 评估。它可以暴露单模型盲点，却不能把多数意见变成证据。

代码任务优先用测试、类型检查、Lint、Schema 与 Diff Policy。模型 Judge 更适合评价难以确定性计算的质量，例如迁移文档是否易懂。即便如此，也要固定 Rubric，避免 Judge 因作者身份或格式线索产生偏差。

成本也会迅速膨胀。三个 Worker 加两个 Judge 如果都读取同一份大仓库上下文，一次“小验证”就是五次大调用。应传递节点级产物，并使用 Provider 支持的 Prefix Cache。

可观测性要能回答具体问题

节点动画不等于生产可观测性。一条 Run 记录至少要说明：节点为什么 Ready；哪版 Plan 创建了它；Worker 当时拥有什么工具权限；调用由哪个模型与 Provider 服务；读取的是哪版输入产物；Retry 有没有重复副作用；哪些证据进入最终综合。

持久化运行数据与离线 Viewer 的意义，在于调查不依赖活着的进程。与此同时必须制定隐私规则，因为 Prompt、Memory 与工具输出经常包含源码和凭据。

怎么验证复杂度是否值得

选一个人能画出依赖图的流程，分别用强单 Agent、显式 OMA Pipeline、Coordinator 动态 OMA Team 跑一遍。记录成功率、墙钟时间、Token、Retry、人工介入和复现性。

第一版生产候选应是显式图。它先回答并行和产物边界是否有价值，不把 Planner 随机性混进来。只有动态计划在多样目标上稳定胜出，且没有增加越权写入与成本，才让 runTeam() 进入受验证、受审批的路径。

它和我们上一篇 Copilot SDK 与 Agent Framework 形成互补：Harness 改善单个 Agent 的运行循环；OMA 则把多个 Worker 组织成有依赖的执行图。

什么时候适合 OMA

如果后端是 TypeScript，需要自托管、Provider 灵活的编排，并且任务确实有可观察的并行结构，OMA 值得试。尤其是要把现有 Coding Agent 变成 Worker，又不想把整个流程控制权交给某个供应商时，它的思路很清楚。

短客服 Bot、线性两步自动化、连单 Agent 都无法稳定评测的团队，不适合直接上动态 DAG。开源解决了许可证和可修改性，并没有替团队消化运维复杂度。

常见问题

Open Multi-Agent 是托管服务吗？

不是。核心框架运行在自己的 Node.js 环境，使用自己的基础设施和 Provider 凭据。

每次都必须由 Coordinator 生成图吗？

不必。runTasks() 使用应用定义图，runTeam() 才让 Coordinator 规划，简单任务可直接 runAgent()。

能运行 Codex 或 Claude Code 吗？

当前文档支持通过 ACP 或本地进程接入外部 Agent，但每种集成都要单独处理 Adapter、权限和生命周期。

内建工具默认安全吗？

当前版本默认不给内建工具，除非显式授权。务必核对锁定版本，也不要用全局 Full Preset 粗暴恢复旧行为。

Consensus 能保证结果正确吗？

不能。相关模型可能一致犯错。可以执行的任务，应优先相信测试和确定性验证。

最后的判断

Open Multi-Agent 最重要的不是“Agent 更多”，而是让拆解、依赖、权限与证据成为可检查的运行数据。动态 DAG 能带来真正并行，也让 Coordinator 的计划成为可执行控制面的一部分。

所以应把 Plan 当作不可信代码：先验证、再限制、全程观测；必须稳定复现的流程，则保留确定性任务图。