open-multi-agent 调度原理完整拆解事件驱动执行器、TaskQueue 依赖图与 AgentPool 并发控制【免费下载链接】open-multi-agentTypeScript AI agent orchestration framework with dynamic workflows. Describe the goal, not the graph: a coordinator plans the task DAG at runtime and runs it on any LLM (Claude, ChatGPT, Gemini, DeepSeek, or local models).项目地址: https://gitcode.com/gh_mirrors/op/open-multi-agentopen-multi-agent是一个用 TypeScript 编写的 AI Agent 编排框架多智能体编排框架你只描述目标协调器Coordinator会在运行时把任务规划成一张有向无环图DAG交给 Claude、ChatGPT、Gemini、DeepSeek 或本地模型等任意 LLM 并行执行。 本文将深入拆解它内部的三块调度核心事件驱动执行器、带依赖图的TaskQueue以及负责并发控制的AgentPool帮你彻底看懂一个任务从就绪到完成的全过程。30 秒看懂整体架构谁负责什么在 open-multi-agent 中一次团队执行runTeam()的调度链路可以概括为三层各司其职组件源码位置职责TaskQueue任务队列packages/core/src/task/queue.ts持有所有任务维护依赖图与状态机发出调度事件事件驱动执行器packages/core/src/orchestrator/task-execution.ts订阅队列事件决定现在该派哪个任务AgentPoolAgent 池packages/core/src/agent/pool.ts用信号量给全体 Agent 限流保证并发不超载Scheduler调度器packages/core/src/orchestrator/scheduler.ts把就绪任务分配给最合适的 Agent这个分层设计的核心思想是队列管能不能跑执行器管该不该派池子管同时能跑几个。三者解耦后任何一层都可以独立演进——官方文档 docs/task-scheduling.md 中也明确写道AgentPool的信号量始终是并发的最终权威concurrency authority。事件驱动执行器任务就绪即调度告别轮询很多工作流框架靠轮询检查进度来推进流程而 open-multi-agent 默认采用事件驱动模式Event-driven execution。执行器executeQueue()在启动时做三件事见 task-execution.ts订阅TaskQueue的task:ready事件——某任务的所有依赖一完成队列立即发出该事件执行器无需轮询维护两个集合就绪集合readyTaskIds和在飞映射inFlight Map记录正在执行的任务每轮循环通过**派发门dispatch gate**检查四件事是否被调用方取消abort、是否超出 token 预算、是否超过 AgentPool 容量、是否有待审批的边界。✅只有全部通过任务才会被派发给 AgentPool。这种事件喂料 门控放行的循环还有一个巧妙细节即使某个下游任务已经就绪执行器也会等它的前置任务彻底落盘结果、检查点、追踪事件写完后再启动保证完成事件早于开始事件的时序一致方便你事后用观测面板复盘。失败与跳过如何级联依赖图的另一半逻辑是失败传播全部在 queue.ts 中完成fail()某任务失败时递归地把所有传递性依赖它的下游任务标记为 failed避免它们永远卡在 blocked 状态skip()审批被拒绝等场景下skipRemaining()会先停止派发、等在飞任务排空再把剩余任务统一跳过关键在于级联只影响下游分支无关分支继续并行跑不会一损俱损。TaskQueue 依赖图任务状态机与 5 种核心事件TaskQueue是所有任务的单一事实来源single source of truth。每个任务在六种状态间流转队列以事件方式对外广播变化状态含义触发时机pending就绪等待派发无依赖或所有依赖已完成blocked被依赖阻塞存在未完成的dependsOn任务in_progress正在执行执行器派发后completed/failed/skipped三种终态执行结束 / 失败级联 / 跳过依赖解锁unblockDependents()的 O(n) 扫描任务完成时队列会调用 unblockDependents()扫描所有 blocked 任务凡依赖链全部满足者立即晋升为 pending并为每个新解锁的任务发出task:ready事件——这就是事件驱动执行器被叫醒的信号。实现上任务数组和 ID 索引 Map 各只构建一次把整个扫描控制在 O(n) 而非 O(n²)。任务队列发出的 5 种事件队列的对外接口非常克制只有 5 种命名事件task:ready— 新任务就绪含依赖解锁task:complete— 任务完成随后依次触发其下游的task:readytask:failed/task:skipped— 失败/跳过并携带级联信息all:complete— 全部任务到达终态执行器可以收尾 订阅方式也很简单queue.on(task:ready, handler)返回一个退订函数幂等安全详见 queue.ts 事件小节。快照与恢复断点续跑的基础生产场景必须考虑崩溃恢复。TaskQueue 支持snapshot()全量序列化、fromSnapshot()精确重建且可传入resetInProgress: true把崩溃时正在执行的任务重置为可重跑状态。配合 memory/checkpoint.ts 的检查点机制一次被中断的runTeam()可以从中断处继续而不是从头烧 token。AgentPool 并发控制信号量如何给 AI 团队限流LLM 调用又贵又慢并发失控意味着账单爆炸和 API 限流。open-multi-agent 用一把自研计数信号量utils/semaphore.ts给 AgentPool 限流构造时默认maxConcurrency 5。AgentPool 的并发控制其实是两把锁这一点初学者最容易忽略池级信号量Semaphore(maxConcurrency)限制整个池子同时运行的 Agent 数量。超出上限的调用会在acquire()中排队FIFO 依次放行Agent 级互斥锁每个 Agent 一把Semaphore(1)同一个 Agent 实例内部的status、messages、tokenUsage 是可变状态两件事同时打给它会互相踩脚所以同一 Agent 的运行被串行化。⚔️一个值得学习的工程细节是加锁顺序run()中先拿 Agent 锁、再拿池级信号量见 pool.ts这样第二个打到同一 Agent 的调用会在 Agent 锁处等待不占用池的并发槽位避免占着茅坑式的资源浪费。委托Delegation为什么走另一条路Agent 可以调用delegate_to_agent把子任务委托给同队伙伴。此时走的是runEphemeral()为被委托方新建一个一次性 Agent 实例只拿池级信号量、跳过 Agent 级锁。源码注释里解释得很直白——如果不这样做A 委托 B 时 B 又委托 A双方各持对方的 Agent 锁就会互相死锁。️此外池还暴露了availableRunSlots属性执行器在派发前会先检查剩余槽位inFlightCount runConcurrencyLimit即暂停确保委托一个任务永远不会把池子挤到死锁边缘。三种运行入口怎么选方法适用场景并发约束run(name, prompt)单个指定 AgentAgent 锁 池信号量runParallel(tasks)一批任务并行扇出池信号量封顶失败转为错误结果而非抛异常runAny(prompt)不指定 Agent轮询分派Agent 锁 池信号量调度器 5 大策略为不同 Agent 团队挑选排班方式任务就绪后派给谁由 Scheduler 决定。内置 5 种策略dependency-first是默认round-robin— 按索引轮流分派适合能力完全对等的 Agentleast-busy— 派给当前在跑任务最少的 Agent适合任务耗时差异大capability-match— 先按硬性要求过滤再按能力/关键词亲和度打分适合角色分工明确的团队dependency-first默认— 优先执行关键路径上的任务即解锁下游最多的任务靠正向 BFS 统计每个任务的关键度特别适合依赖密集的工作流composite— 加权组合关键度、能力匹配与当前负载默认权重 fit 0.7 / load 0.3多目标综合排序。举个直觉例子如果你的 DAG 是调研 → 写初稿 → 三人并行评审 → 汇总dependency-first会先把调研推出去因为它卡着后面 4 个任务评审三兄弟则自然并行。总结一张链路看懂 open-multi-agent 的调度把本文三块内容串起来一次任务派发就是下面这条流水线依赖完成→ TaskQueue 发task:ready→ 执行器就绪集合更新 → 派发门检查取消/预算/容量/审批→ Scheduler 选 Agent → AgentPool 两把锁放行 → 执行、重试、验证 → 结果回写队列task:complete再次唤醒循环 这正是 open-multi-agent 的设计哲学描述目标而非画图。依赖关系、并发上限、失败传播全部由框架在运行时托管你只关心每个任务做什么、谁能做。想动手验证可以从 examples/basics/team-collaboration.ts 这类最小示例入手再对照 packages/core/examples/patterns/event-driven-dag.ts 看事件驱动 DAG 的完整用法。【免费下载链接】open-multi-agentTypeScript AI agent orchestration framework with dynamic workflows. Describe the goal, not the graph: a coordinator plans the task DAG at runtime and runs it on any LLM (Claude, ChatGPT, Gemini, DeepSeek, or local models).项目地址: https://gitcode.com/gh_mirrors/op/open-multi-agent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
open-multi-agent 调度原理完整拆解：事件驱动执行器、TaskQueue 依赖图与 AgentPool 并发控制
open-multi-agent 调度原理完整拆解事件驱动执行器、TaskQueue 依赖图与 AgentPool 并发控制【免费下载链接】open-multi-agentTypeScript AI agent orchestration framework with dynamic workflows. Describe the goal, not the graph: a coordinator plans the task DAG at runtime and runs it on any LLM (Claude, ChatGPT, Gemini, DeepSeek, or local models).项目地址: https://gitcode.com/gh_mirrors/op/open-multi-agentopen-multi-agent是一个用 TypeScript 编写的 AI Agent 编排框架多智能体编排框架你只描述目标协调器Coordinator会在运行时把任务规划成一张有向无环图DAG交给 Claude、ChatGPT、Gemini、DeepSeek 或本地模型等任意 LLM 并行执行。 本文将深入拆解它内部的三块调度核心事件驱动执行器、带依赖图的TaskQueue以及负责并发控制的AgentPool帮你彻底看懂一个任务从就绪到完成的全过程。30 秒看懂整体架构谁负责什么在 open-multi-agent 中一次团队执行runTeam()的调度链路可以概括为三层各司其职组件源码位置职责TaskQueue任务队列packages/core/src/task/queue.ts持有所有任务维护依赖图与状态机发出调度事件事件驱动执行器packages/core/src/orchestrator/task-execution.ts订阅队列事件决定现在该派哪个任务AgentPoolAgent 池packages/core/src/agent/pool.ts用信号量给全体 Agent 限流保证并发不超载Scheduler调度器packages/core/src/orchestrator/scheduler.ts把就绪任务分配给最合适的 Agent这个分层设计的核心思想是队列管能不能跑执行器管该不该派池子管同时能跑几个。三者解耦后任何一层都可以独立演进——官方文档 docs/task-scheduling.md 中也明确写道AgentPool的信号量始终是并发的最终权威concurrency authority。事件驱动执行器任务就绪即调度告别轮询很多工作流框架靠轮询检查进度来推进流程而 open-multi-agent 默认采用事件驱动模式Event-driven execution。执行器executeQueue()在启动时做三件事见 task-execution.ts订阅TaskQueue的task:ready事件——某任务的所有依赖一完成队列立即发出该事件执行器无需轮询维护两个集合就绪集合readyTaskIds和在飞映射inFlight Map记录正在执行的任务每轮循环通过**派发门dispatch gate**检查四件事是否被调用方取消abort、是否超出 token 预算、是否超过 AgentPool 容量、是否有待审批的边界。✅只有全部通过任务才会被派发给 AgentPool。这种事件喂料 门控放行的循环还有一个巧妙细节即使某个下游任务已经就绪执行器也会等它的前置任务彻底落盘结果、检查点、追踪事件写完后再启动保证完成事件早于开始事件的时序一致方便你事后用观测面板复盘。失败与跳过如何级联依赖图的另一半逻辑是失败传播全部在 queue.ts 中完成fail()某任务失败时递归地把所有传递性依赖它的下游任务标记为 failed避免它们永远卡在 blocked 状态skip()审批被拒绝等场景下skipRemaining()会先停止派发、等在飞任务排空再把剩余任务统一跳过关键在于级联只影响下游分支无关分支继续并行跑不会一损俱损。TaskQueue 依赖图任务状态机与 5 种核心事件TaskQueue是所有任务的单一事实来源single source of truth。每个任务在六种状态间流转队列以事件方式对外广播变化状态含义触发时机pending就绪等待派发无依赖或所有依赖已完成blocked被依赖阻塞存在未完成的dependsOn任务in_progress正在执行执行器派发后completed/failed/skipped三种终态执行结束 / 失败级联 / 跳过依赖解锁unblockDependents()的 O(n) 扫描任务完成时队列会调用 unblockDependents()扫描所有 blocked 任务凡依赖链全部满足者立即晋升为 pending并为每个新解锁的任务发出task:ready事件——这就是事件驱动执行器被叫醒的信号。实现上任务数组和 ID 索引 Map 各只构建一次把整个扫描控制在 O(n) 而非 O(n²)。任务队列发出的 5 种事件队列的对外接口非常克制只有 5 种命名事件task:ready— 新任务就绪含依赖解锁task:complete— 任务完成随后依次触发其下游的task:readytask:failed/task:skipped— 失败/跳过并携带级联信息all:complete— 全部任务到达终态执行器可以收尾 订阅方式也很简单queue.on(task:ready, handler)返回一个退订函数幂等安全详见 queue.ts 事件小节。快照与恢复断点续跑的基础生产场景必须考虑崩溃恢复。TaskQueue 支持snapshot()全量序列化、fromSnapshot()精确重建且可传入resetInProgress: true把崩溃时正在执行的任务重置为可重跑状态。配合 memory/checkpoint.ts 的检查点机制一次被中断的runTeam()可以从中断处继续而不是从头烧 token。AgentPool 并发控制信号量如何给 AI 团队限流LLM 调用又贵又慢并发失控意味着账单爆炸和 API 限流。open-multi-agent 用一把自研计数信号量utils/semaphore.ts给 AgentPool 限流构造时默认maxConcurrency 5。AgentPool 的并发控制其实是两把锁这一点初学者最容易忽略池级信号量Semaphore(maxConcurrency)限制整个池子同时运行的 Agent 数量。超出上限的调用会在acquire()中排队FIFO 依次放行Agent 级互斥锁每个 Agent 一把Semaphore(1)同一个 Agent 实例内部的status、messages、tokenUsage 是可变状态两件事同时打给它会互相踩脚所以同一 Agent 的运行被串行化。⚔️一个值得学习的工程细节是加锁顺序run()中先拿 Agent 锁、再拿池级信号量见 pool.ts这样第二个打到同一 Agent 的调用会在 Agent 锁处等待不占用池的并发槽位避免占着茅坑式的资源浪费。委托Delegation为什么走另一条路Agent 可以调用delegate_to_agent把子任务委托给同队伙伴。此时走的是runEphemeral()为被委托方新建一个一次性 Agent 实例只拿池级信号量、跳过 Agent 级锁。源码注释里解释得很直白——如果不这样做A 委托 B 时 B 又委托 A双方各持对方的 Agent 锁就会互相死锁。️此外池还暴露了availableRunSlots属性执行器在派发前会先检查剩余槽位inFlightCount runConcurrencyLimit即暂停确保委托一个任务永远不会把池子挤到死锁边缘。三种运行入口怎么选方法适用场景并发约束run(name, prompt)单个指定 AgentAgent 锁 池信号量runParallel(tasks)一批任务并行扇出池信号量封顶失败转为错误结果而非抛异常runAny(prompt)不指定 Agent轮询分派Agent 锁 池信号量调度器 5 大策略为不同 Agent 团队挑选排班方式任务就绪后派给谁由 Scheduler 决定。内置 5 种策略dependency-first是默认round-robin— 按索引轮流分派适合能力完全对等的 Agentleast-busy— 派给当前在跑任务最少的 Agent适合任务耗时差异大capability-match— 先按硬性要求过滤再按能力/关键词亲和度打分适合角色分工明确的团队dependency-first默认— 优先执行关键路径上的任务即解锁下游最多的任务靠正向 BFS 统计每个任务的关键度特别适合依赖密集的工作流composite— 加权组合关键度、能力匹配与当前负载默认权重 fit 0.7 / load 0.3多目标综合排序。举个直觉例子如果你的 DAG 是调研 → 写初稿 → 三人并行评审 → 汇总dependency-first会先把调研推出去因为它卡着后面 4 个任务评审三兄弟则自然并行。总结一张链路看懂 open-multi-agent 的调度把本文三块内容串起来一次任务派发就是下面这条流水线依赖完成→ TaskQueue 发task:ready→ 执行器就绪集合更新 → 派发门检查取消/预算/容量/审批→ Scheduler 选 Agent → AgentPool 两把锁放行 → 执行、重试、验证 → 结果回写队列task:complete再次唤醒循环 这正是 open-multi-agent 的设计哲学描述目标而非画图。依赖关系、并发上限、失败传播全部由框架在运行时托管你只关心每个任务做什么、谁能做。想动手验证可以从 examples/basics/team-collaboration.ts 这类最小示例入手再对照 packages/core/examples/patterns/event-driven-dag.ts 看事件驱动 DAG 的完整用法。【免费下载链接】open-multi-agentTypeScript AI agent orchestration framework with dynamic workflows. Describe the goal, not the graph: a coordinator plans the task DAG at runtime and runs it on any LLM (Claude, ChatGPT, Gemini, DeepSeek, or local models).项目地址: https://gitcode.com/gh_mirrors/op/open-multi-agent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考