业界多 Agent 系统的任务管理设计：面向相似与并发子任务的研究报告
本文来自ChatGPT DeepResearch
执行摘要
截至 2026 年 8 月 31 日，业界多 Agent 系统正在形成一个相当清晰的工程共识：不要把“多 Agent”本身当作调度系统，而应把它拆成“确定性控制面 + 概率性 Agent 执行面”。LLM/Agent 适合做语义理解、开放式任务分解、能力匹配、动态重规划和结果综合；依赖关系、并发上限、资源配额、重试、幂等、权限、状态机、超时和交付语义，则更适合由传统软件控制。Anthropic 明确区分预定义代码路径的 workflow 与模型自主决定过程的 agent；OpenAI Agents SDK 同样将 orchestration 分成“LLM 决策”和“代码控制”两类并允许混用；Google ADK 2.0、Microsoft Agent Framework 和 LangGraph 都正在向 graph/workflow + agent 的混合结构靠拢。
对于本报告特别关注的场景——一个用户请求中同时包含多个相似、重复、可并行或部分依赖的子任务——最重要的设计原则不是“尽可能多地 spawn agent”，而是：
先规范化与去重，再建立依赖 DAG；先复用公共工作，再 fan-out；执行时实行 bounded concurrency 和资源/成本预算；fan-in 时基于结构化结果、来源/provenance 和明确冲突策略聚合；整个过程通过 durable task state、幂等 side effect、checkpoint、trace 和最终 delivery contract 管理。
这一判断得到多种实践的交叉支持。Anthropic 在生产 Research 系统中发现，模糊的子任务描述会导致多个 subagent 重复做相同搜索，甚至早期系统会为简单问题创建几十个 subagent，因此后来显式规定任务边界以及随查询复杂度变化的 agent/tool-call 预算；同时，他们发现多 Agent 特别适合 breadth-first、彼此独立的搜索方向，而共享大量上下文、存在密集依赖的任务并不适合简单 fan-out。 Ray 文档从分布式系统角度给出了同样的另一半答案：无限提交任务会造成 pending task 堆积，应利用 ray.wait 等方式形成 backpressure；资源声明可以限制并发；过度拆分成过细粒度任务反而会损害性能。
因此，“一个输入项 = 一个 Agent”通常不是正确抽象；更合理的抽象是“一个有独立失败、依赖、资源和聚合语义的工作单元 = 一个 Task”。多个 Task 可以由同一个 agent 批处理，一个 Task 也可能由多个 agent 冗余执行。Agent 是能力执行器，Task 才应该是控制面的基本对象。这是本报告综合现有框架后提出的核心架构建议。
进一步看各生态的定位：
- Ray 最强的是分布式执行、资源调度、placement、actor、backpressure、故障恢复和隔离，但基本不替应用做语义任务分解；它适合作为多 Agent 系统的 execution substrate。Ray 2.58 文档明确覆盖 tasks、actors、placement groups、故障恢复、supervisor actor、并发控制、资源限制和反模式。
- LangGraph/LangChain 最强的是 agent/workflow graph、共享状态、conditional routing、supervisor/router、checkpoint 与 human-in-the-loop；LangGraph 的 super-step 执行模型天然适合表达 fan-out/fan-in，但真正的 CPU/GPU/模型配额调度通常需要下层基础设施。
- Microsoft Agent Framework + AutoGen/Magentic 覆盖的 orchestration pattern 最全面之一：sequential、concurrent、handoff、group chat、Magentic，并支持 workflow checkpoint、Durable Extension、可观测性和 HITL。Microsoft 当前迁移文档把 Agent Framework 定位为 AutoGen 的后继方向；AutoGen 的 actor/event-driven runtime 仍很值得参考。
- OpenAI Agents SDK 倾向于较薄的、Python-first 的 orchestration primitives：manager-style agents-as-tools、handoff、sessions、RunState、guardrails、tracing、sandbox；真正的企业级 durable orchestration 可与 Temporal、Dapr、Restate、DBOS 等结合。
- Google ADK 2.0 正从早期 Sequential/Parallel/Loop workflow agents 向 graph workflow、dynamic workflow 和 collaborative agent 发展，尤其适合“确定性 graph + agent node”的组合；其 ParallelAgent 官方文档还明确提醒，共享
InvocationContext时并发写需要自己处理锁或外部状态。 - Anthropic 提供了非常有价值的真实生产经验：Research 使用 orchestrator-worker、并行 subagent、memory、CitationAgent、checkpoint、production tracing；其公开工程文章也明确暴露了同步 wave/barrier 的 straggler 问题以及异步化带来的 consistency/error-propagation 成本。
- Meta 的最新公开实践已明显走向模型原生 orchestration。2026 年 7 月 Muse Spark 1.1 官方介绍称主 agent 可以规划并向 parallel subagents 分派任务，subagent 知道何时升级回主 agent，并将优化 end-to-end latency 作为训练目标；不过公开资料目前不像 Ray、LangGraph 或 Microsoft Agent Framework 那样详细暴露队列、checkpoint、一致性和重试 runtime，因此更适合作为“model-level orchestration”案例，而非完整 workflow runtime 参考。
- AgentScope 是中文生态中值得重点关注的框架之一，已经覆盖 orchestration、ReAct、状态/session、tracing、sandbox、A2A，并提供基于 Ray 的并行/分布式 evaluation；其 Runtime v1.0 还专门重构了状态序列化恢复和生产生命周期管理。
学术侧也在从“固定 topology 多 Agent”转向“如何动态形成协作结构”。ReAct 将推理与行动循环结合起来，但本质是单 agent/tool loop，并不是完整多 Agent 调度器；CAMEL、AutoGen 等工作进一步探索角色与消息协作；ICLR 2025 的 Scaling Large Language Model-based Multi-Agent Collaboration 研究了扩展 agent 数量与协作规模，NeurIPS 2025 的 Multi-Agent Collaboration via Evolving Orchestration 则直接针对静态 orchestration 的局限研究动态演化协作。传统 AAMAS 的任务分配研究提醒我们：通信异步性、agent capability、task dependency 和 allocation 本来就是 MAS 的核心问题，只是在 LLM Agent 时代又增加了 token、上下文和非确定性。
本报告最终建议的生产基线是：
Input
↓
Intent / Task Normalizer
↓
Canonicalization → Dedup / Similarity Cluster → Common-work Extraction
↓
Typed Task DAG
↓
Policy Router
├─ deterministic eligibility: permission / tool / region / capability
└─ semantic scoring: quality / latency / cost / confidence
↓
Budget-aware Scheduler
↓
Bounded Worker / Agent Pools
↓
Immutable Artifacts + Durable Task State
↓
Structured Reducer / Verifier / Conflict Resolver
↓
Partial / Final Delivery
其中，LLM 可以建议 DAG，但不能拥有最终调度权；LLM 可以提出“并发 20 个”，调度器仍然可以只批准 4 个。 这一区分是生产可靠性的关键。
研究范围、方法与假设
本研究以 2021–2026 年为主要时间窗，实际 LLM 多 Agent 资料主要集中在 2023 年之后；对于 Actor model、task allocation、资源调度、异步通信等基础机制，必要时参考近十年甚至更早形成但仍适用的分布式/MAS 原理。本次资料截点为 2026 年 8 月 31 日。例如 Microsoft Agent Framework workflow 文档目前更新至 2026 年 8 月 25 日，Ray 文档搜索到的是 2.58.0，Google 文档已进入 ADK 2.0 世代，Meta Muse Spark 1.1 发布于 2026 年 7 月 9 日，因此下述“当前状态”均以这一时间截点为准。
资料优先使用原始和官方来源：Ray、LangChain/LangGraph/LangSmith、Microsoft AutoGen 与 Agent Framework、OpenAI Agents SDK、Google ADK、Anthropic Engineering、Meta AI、AgentScope 官方文档，以及 OpenReview、NeurIPS、IJCAI、AAMAS/ACM proceedings 等论文或会议页面。由于这些系统没有一个统一、可复现的跨框架 benchmark 同时衡量“拆分质量、调度、p95 延迟、token 成本、故障恢复、一致性和安全”，本报告不把厂商自报 benchmark 转换成跨框架排名。Anthropic 的 90.2% internal-eval 提升以及约 15× chat token 使用量，只能理解为其特定 Research workload 下的内部结果，而不能推断“多 Agent 普遍提升 90%”或“任何框架都是 15 倍成本”。Anthropic 本身也明确指出多 Agent 更适合 breadth-first、可高度并行的任务，不适合共享上下文和依赖密集型任务。
本报告采用三个分析层次。第一层是语义控制层：任务怎样拆解，agent 怎样定义角色，如何选择 agent，以及何时重规划。第二层是分布式执行层：DAG readiness、queue、资源、concurrency、backpressure、checkpoint、retry 和 state consistency。第三层是产品交付层：aggregation、provenance、权限、trace、部分结果、终态、人工审批和发布升级。之所以这样划分，是因为现有生态实际上分别擅长不同层：Ray 明显偏执行基础设施；LangGraph、Microsoft Agent Framework、ADK 偏 workflow/control graph；OpenAI Agents SDK 偏 agent runtime primitives；Anthropic/Meta 的公开材料更多提供 production/model behavior 实践。
明确假设与未指定项如下。
另一个重要定义是：Task 与 Agent 不应一一对应。 本报告把 Task 定义为具有独立 task_id、输入、依赖、资源需求、权限、预算、生命周期和输出契约的工作单元；Agent 是能够执行某类 Task 的执行器。这样才能支持 batching、work stealing、重试换 agent、hedging 以及同一 task 的多 agent consensus。这个定义是综合上述框架机制后给出的工程抽象，而不是某一家框架的 API 限定。
一个推荐的 Task Contract 可以是：
task_id: t_017
parent_id: root_001
type: compare_company
dedupe_key: compare_company:apple:microsoft:2025
similarity_group: company_comparison
input_refs:
- artifact://normalized-request/17
dependencies:
- t_common_financial_data
capability:
domain: financial_research
tools: [web_search, filing_reader]
data_region: EU
effects: read_only
priority: 80
deadline_ms: 12000
token_budget: 18000
cost_budget_usd: 0.20
max_attempts: 3
idempotency_key: root_001:t_017:v1
aggregation:
group: company_results
schema: CompanyComparison
policy: evidence_weighted
delivery:
partial_allowed: true
ordering_key: 17
这个 contract 最有价值的地方是：调度策略、Agent prompt 和业务状态不再混在一段自然语言中。 Anthropic 的实践显示，仅靠模糊自然语言委派会导致重复搜索和职责遗漏；AutoGen 也把 message contract/protocol 视为形成 multi-agent pattern 的基础；LangGraph 则用显式 State/Nodes/Edges 表达控制流。
核心机制与方案比较
任务拆分首先应区分“语义拆分”和“执行拆分”
一个常见错误是让 planner 直接生成：
subtask 1 → agent 1
subtask 2 → agent 2
subtask 3 → agent 3
...
这会把三个本来应该分离的问题混在一起：需要做什么、有哪些共同工作、怎样执行最经济。Anthropic 的 Research 系统显示，planner 如果不给出明确目标、输出格式、工具范围和任务边界，subagent 很容易重复工作；其生产提示甚至加入了复杂度到 subagent/tool-call 数量的明确缩放规则。
对于相似子任务，更合理的 pipeline 是：
原始请求
↓
语义分解
↓
规范化
↓
完全重复？────── 是 ──→ 单任务执行 + 多消费者
│
否
↓
是否高度相似？── 是 ──→ 聚类 → 提取共享前缀 → 参数化 Map
│
否
↓
依赖分析 → DAG
例如用户说：
“分别分析 OpenAI、Anthropic、Google、Microsoft 的 agent framework；再分别比较它们的任务拆分、状态管理和并发。”
一个 naïve planner 可能生成 12 个独立研究 Agent。但更高效的设计通常是：
公共任务：
搜集四个平台的官方文档版本、术语和基础架构
Map：
company × framework-analysis
OpenAI
Anthropic
Google
Microsoft
Reduce：
将四个统一 schema 结果按属性做横向比较
而不是让 12 个 agent 各自重新查找“OpenAI framework 是什么”。这种 common-prefix extraction + parametric map 是处理相似任务时最值得额外加入的控制层。
路由不应该等同于让 LLM 任意选择 Agent
LangChain 当前文档已经清楚区分 Router 和 Supervisor：router 通常是一个分类步骤，不维持长期对话状态；supervisor 则是完整 agent，可以跨多个 turn 动态调用 subagent。 OpenAI 则提供 manager-style “agents as tools”和 handoff 两种主要语义：前者总体控制权留在 manager，后者把当前控制转移给 specialist。 Microsoft Agent Framework 同样明确区分 Handoff 和 manager/Magentic 模式，handoff 接收方取得任务 ownership，而 manager/tool-agent 模式由主 agent 保持总体责任。
生产环境因此更适合两阶段路由：
[ Eligible(i,a)= Permission \land Capability \land Tool \land Region \land Availability ]
先由确定性规则排除不允许执行 task (i) 的 agent (a)，然后才让规则、统计模型或 LLM 在可行集合中评分：
[ score(i,a)= w_q Q(i,a) -w_l E[Latency] -w_c E[Cost] -w_f P(Failure) +w_d DataLocality ]
最终：
[ a^*=\arg\max_{a \in Eligible(i)} score(i,a) ]
这里不是建议一定使用该具体公式，而是强调：LLM 不能绕过 hard constraints。 “这个 agent 看起来最聪明”不能覆盖“它没有数据库权限”“它位于错误数据区域”“它的浏览器 pool 已经饱和”等条件。
详细比较：控制面与执行面
以下表格不把框架简单评为“强/弱”，而是说明它们实际上解决哪一层问题。
Ray 和 AutoGen Core 特别值得放在一起理解。AutoGen Core 的官方描述直接采用 Actor model、async messaging 和 distributed runtime；Ray 本身则是成熟得多的通用 distributed task/actor substrate。 对生产系统而言，一个很自然的组合思想是：上层 Agent workflow 决定“谁应该做什么”，下层 actor/task runtime 决定“在哪里、什么时候、最多并发多少、失败以后怎么办”。 这是架构组合，不代表必须实际同时使用两个框架。
详细比较：一致性、聚合、容错、可观测性与安全
这里有一个非常关键的差别：“有 checkpoint”并不自动意味着“副作用 exactly-once”。 LangGraph 官方明确说明，checkpoint 在 super-step 边界保存；如果 node 在中断/失败后 resume，函数可能从头执行，因此前面的 side effect 应通过 idempotency key、upsert 或 read-before-write 等方式保证重放安全。 Microsoft Durable Extension 能保证已完成的 workflow executor/agent steps 在进程重启后不被重新运行，但远端 API 在超时边界处是否实际成功，仍应由业务 API 自己提供幂等协议。前半部分是 Microsoft 的 durable semantics，后半部分是本报告基于分布式 side-effect 边界给出的设计要求。
因此，对于多 Agent 系统，建议把 consistency 分成至少三类，而不要只有一个“共享 memory”：
推荐 task 状态机：
CREATED
↓
NORMALIZED
↓
READY ←──── RETRY_WAIT
↓ ↑
RUNNING ──fail───┘
│ │
│ ├────────→ DEAD_LETTER
│
├───────────→ CANCELLED
│
↓
SUCCEEDED
↓
AGGREGATED
↓
DELIVERED
SUCCEEDED 和 DELIVERED 最好是不同状态。否则一个 agent 已成功生成结果，但 WebSocket 断开、客户端离线或下游 notification 失败时，系统很容易错误地重新执行 expensive agent task，而真正需要重试的只是 delivery。
典型架构模式
规范化、共享前缀与有界 Fan-out/Fan-in
这是多个相似子任务的首选模式，也是本报告最推荐的默认架构。
LangGraph 明确把 parallelization 分为“不同独立 subtask 并行”和“同一 task 多次执行以检查不同输出”；Google ParallelAgent 则针对独立、耗资源 task 同时运行；Ray 强调 pending-task backpressure 和不要 over-parallelize。三者合起来说明，正确的问题不是“能不能 fan-out”，而是“哪些 task 值得 fan-out、fan-out width 应该是多少”。
设原始 planner 生成 (N) 个 task，规范化后有 (U) 个 unique tasks，进一步提取共享前缀后只需 (C) 个 common operations，则实际昂贵调用量可能从：
[ N \times k ]
降低到：
[ C+\sum_{i=1}^{U} k_i ]
尤其当多个子任务需要相同 web search、数据库 scan、文档解析或 repo checkout 时，收益可能非常大。这是架构推导，不是某框架公布的固定性能数字。
Supervisor–Worker 动态重规划
适合不知道完整执行路径的 research、debugging、incident investigation、复杂规划。
Anthropic Research 是典型 orchestrator-worker：lead agent 规划、创建专门 subagent、根据返回结果决定继续研究还是退出，最后让 CitationAgent 做 attribution。 Microsoft Magentic 则让 manager 维护 shared context、跟踪 progress、动态选择 specialized agents；Agent Framework 还允许 max_round_count、max_stall_count、max_reset_count 等约束，说明生产 manager 必须受到 execution budget 限制，而不能无限自主循环。
这里推荐引入两个 ledger：
Task Ledger
- 总目标
- 已知任务 / dependencies
- 完成定义
- 预算
Execution Ledger
- running tasks
- attempts
- artifacts
- failures
- remaining deadline
- remaining token/cost budget
这比让 manager 通过越来越长的 conversation 猜测“之前完成了什么”可靠得多。Anthropic 自己也将 plan 保存到 Memory，并在长程任务中利用 checkpoint/external memory/context compression。
这一模式的主要问题是中心协调器瓶颈。Anthropic 当前 Research lead 采用同步 wave，明确指出 coordinator 会等待一批中最慢的 subagent，且期间无法及时 steer；完全 async 可以增加并行度，却使 state consistency、result coordination 和 error propagation 更复杂。
生产中因此可以采用“半异步 supervisor”：
不是：
spawn 8 → await all 8 → rethink
而是：
spawn ≤ K
→ 任一 meaningful result 完成
→ update ledger
→ incremental rethink
→ 补充/取消 task
→ 最终 convergence barrier
也就是 as-completed scheduling + 最终一致的 aggregation barrier。
Event-driven Actor 与背压调度
当子任务数可能达到几十、几百甚至更多时，应从“agent workflow”上升到真正的执行系统。
Ray 是此类执行层的直接参考：它支持 task/actor、resource-aware scheduling、placement group、ray.wait backpressure、actor synchronization、supervisor actors 和 fault-tolerance primitives。 AutoGen Core 也从 Actor model 出发，提供异步消息、topic/subscription 和实验性的 host/worker distributed runtime。
这里最重要的不是使用哪一个具体框架，而是使用分层并发预算。例如：
request concurrency limit = 12
per-user active subtasks = 6
web-search calls = 8
browser sessions = 3
large-model calls = 4
small-model calls = 16
DB-write tasks = 1 per partition
GPU-code workers = 2
如果只使用一个全局 Semaphore(20)，会出现一个非常典型的问题：20 个 cheap LLM calls 占满全部 slots，阻塞真正位于 critical path 的浏览器任务；或者 20 个浏览器 task 反过来拖垮 remote service。因此应采用层级资源池 + 全局 admission control。
建议 scheduler 至少实现：
ready = dependencies_satisfied(task)
admit(task) =
ready
AND request_budget_available
AND user_quota_available
AND agent_pool_available
AND model_rate_limit_available
AND tool_resource_available
队列优先级则可以综合：
priority_score =
business_priority
+ critical_path_bonus
+ deadline_urgency
+ starvation_age
- estimated_cost_penalty
Speculative / Consensus Fan-out
不是所有“并行同一任务多次”都是浪费。LangGraph 官方明确把“多次运行同一 task，比较不同 output，以增加 confidence”列为 parallelization 用途。 AutoGen 还提供 Mixture-of-Agents、multi-agent debate、reflection 等结构，其中 MoA 让多个 worker 输出进入后续 layer/orchestrator。
需要区分两种用途：
Hedging 是为了 latency tail。 对非常慢的 task，在超过某个分位点后启动第二份副本，第一个成功后取消另一份。
Diversity/consensus 是为了 quality。 使用不同模型、prompt、search strategy 或角色执行同一问题，再由 verifier 根据 evidence 决定。
这两者都不应成为默认策略，否则成本会线性甚至超线性上升。Anthropic 的 Research 数据非常清楚地显示 multi-agent 的 token 代价很高，在其特定 workload 中约是普通 chat 的 15 倍。
因此推荐：
low-value + low-uncertainty
→ single execution
high-value + low-uncertainty
→ single execution + retry
latency-critical + high tail
→ hedged execution
high-value + high-uncertainty
→ diverse execution + verifier
irreversible side effect
→ NEVER speculative execute the side effect
speculation only applies to planning/validation stage
最后一条尤其重要：可以让三个 agent 同时起草“该不该退款”，不能让三个 agent 同时真的执行退款。
Durable Workflow、Saga 与交付
多 Agent 一旦执行几十秒以上、存在工具调用或副作用，最好把它视为 long-running workflow。
Microsoft Durable Extension 会 checkpoint graph workflow，使已完成 executor 和 agent step 在 process restart 后无需重复执行；OpenAI Agents SDK 官方则已经记录 Dapr、Temporal、Restate 和 DBOS 等 durable integration；LangGraph checkpointer 可以恢复 graph/task 进度，并明确要求 side effect 使用幂等设计。 Anthropic Research 在生产上也采用 retry + regular checkpoints，而不是失败后一律从头开始。
这说明“Agent framework 自带 retry”远远不够。需要回答的是：
什么失败可以 retry？
重试哪一级？
是否换 agent/model？
已经产生的副作用怎么办？
checkpoint 在哪里？
用户已经看到了 partial result 吗？
retry 会不会重复收费/发送/写入？
推荐错误分类：
OpenAI guardrail 的 parallel/blocking 模式提供了一个很典型的现实权衡：parallel guardrail 可以降低 latency，但在安全检查触发以前 agent 可能已经花费 tokens 甚至执行工具；blocking guardrail 会增加前置延迟，却能避免不必要的执行与 side effect。 这类权衡应该由 task 的 effects 和风险等级决定，而不是全系统固定一种模式。
面向相似与并发子任务的最佳实践和实现建议
把“相似性检测”放在 Agent spawn 之前
处理多个相似子任务时，我认为这是最容易被现有 agent framework 示例忽略、但对生产价值最大的能力。
推荐至少做三层去重：
Exact dedup
normalized hash / canonical key
Semantic dedup
embedding / lightweight classifier
Operational dedup
是否虽然目标不同，但需要相同前置工具结果？
例如：
“查 Apple 2025 revenue”
“找苹果公司 2025 年营收”
可能可以合并成一个 exact/canonical task。
而：
“分析 Apple 2025 毛利率”
“分析 Apple 2025 营业利润率”
不是同一个最终 task，但两者的：
获取 Apple 2025 10-K 财务表
是公共前缀，应该只执行一次。
建议为每个 task 生成：
dedupe_key = hash(
task_type,
canonical_entities,
canonical_period,
normalized_parameters,
data_version,
)
对于正在执行的相同 key，实现 single-flight：
task A ──┐
task B ──┼──> one underlying execution ──> result fan-out to A/B/C
task C ──┘
而不是三份 duplicate agent。
Anthropic 的生产经验直接说明了不明确 task boundary 会导致 subagent 做同一搜索；Ray 的 over-parallelization 反模式则说明即便 task technically parallelizable，粒度过细也可能降低性能。
先生成 Task DAG，再让 Scheduler 决定实际并发
Planner 输出最好不是一组字符串，而是结构化 DAG：
{
"tasks": [
{
"id": "fetch_common_docs",
"depends_on": [],
"capability": "retrieval"
},
{
"id": "analyze_openai",
"depends_on": ["fetch_common_docs"],
"capability": "agent_analysis"
},
{
"id": "analyze_google",
"depends_on": ["fetch_common_docs"],
"capability": "agent_analysis"
},
{
"id": "compare",
"depends_on": ["analyze_openai", "analyze_google"],
"capability": "aggregation"
}
]
}
然后：
Planner:
“这两个任务可以并行”
Scheduler:
“可以，但现在 large-model slots 只剩 1 个，
所以一个跑 large，一个路由到 small model，
或者其中一个排队。”
这样可以避免 LLM 把“语义独立”误认为“系统资源允许同时执行”。
Google ADK 的 ParallelAgent 明确要求 parallel branches 独立，并指出共享 context 时需要自己用 lock 或 external state 管理 race；Ray 则专门提供基于资源的 concurrency 限制和 placement。
对同类 task 使用“批量 + 参数化 worker”，不要复制完整 Agent context
当 50 个 task 使用完全相同的 agent role，只是参数不同：
extract(date=...)
extract(date=...)
extract(date=...)
优先考虑：
one role definition
one cached/shared system context
N compact TaskSpec
bounded map
而不是 50 份巨大 conversation context。
Anthropic 将 subagent 视为独立 context compression 单元，但同时指出多 Agent 会显著提高 token 使用量；其 appendix 还建议对大 artifact 让 subagent 直接写外部文件/系统，只向 coordinator 返回轻量 reference，以减少经过主 agent 的信息复制和“传话游戏”。
所以推荐数据流：
错误：
Agent A → 20k tokens result → Supervisor
Supervisor → copy 20k → Agent B
Agent B → copy...
更好：
Agent A → artifact://report/a.json
Supervisor receives:
{
artifact_id,
summary,
schema,
provenance
}
Agent B reads artifact when needed
共享状态尽量采用 Single Writer 或 Partition Ownership
并发 Agent 最大的 consistency 风险通常不是“两个 LLM 意见不同”，而是：
Agent A reads version 4
Agent B reads version 4
Agent A writes version 5
Agent B writes version 5'
Google ADK 的 ParallelAgent 文档直接指出共享 InvocationContext 需要谨慎管理 concurrent access，例如用 locks；Anthropic 也明确把 async multiagent 的 state consistency 列为额外复杂度。
推荐从容易到复杂依次选择：
首选
branch-local state
其次
immutable artifact + append-only event
再其次
partition ownership:
customer A → writer 1
customer B → writer 2
必要时
optimistic concurrency:
UPDATE... WHERE version = old_version
最后才是
共享锁 / distributed lock
不要默认让所有 Agent 共同修改一个巨大 JSON “shared memory”。
Task state 则最好由 scheduler/workflow runtime 成为 single authoritative writer：
task worker:
returns outcome
state manager:
RUNNING → SUCCEEDED
worker 不直接任意修改 scheduler metadata
Result Aggregation 应该是协议，不应只是“再让一个 LLM 总结一下”
对于并发结果，需要根据数据类型选择聚合策略：
Anthropic Research 最后使用单独 CitationAgent 处理引用，并在 evaluation 中按 factual accuracy、citation accuracy、completeness、source quality、tool efficiency 等维度判断结果；这说明 aggregation 最好不仅处理“语言流畅度”，还应消费 provenance 和质量信号。
推荐每个 worker 返回：
{
"task_id": "t17",
"status": "success",
"payload": {},
"confidence": 0.82,
"evidence": [
{
"source_id": "...",
"claim_ids": ["c1", "c3"]
}
],
"warnings": [],
"model": "...",
"tool_trace_ref": "...",
"artifact_refs": []
}
聚合器面对冲突：
不要：
A 说 10，B 说 12 → 平均为 11
应该：
A 的来源是什么？
B 的来源是什么？
数据日期？
primary vs secondary？
task parameter 是否相同？
是否一个用了 FY、另一个用了 calendar year？
即先做冲突解释，再做选择。
retry 要绑定 task，而不是简单重跑整条 Agent 对话
LangGraph 的 checkpoint 行为是很好的参考：task result 可以 checkpoint，恢复时避免重新完成已成功的工作；但 node 中其他 side effect 必须能够幂等重放。 Microsoft Durable Extension 同样是以“已完成步骤不要因为 restart 而重复”为核心。 Anthropic 也明确表示长程 agent 不能每次失败都从头重启，因而结合 checkpoint 和 deterministic retry。
推荐 retry hierarchy：
Level A: tool call retry
例如 HTTP 503
Level B: agent step retry
例如 malformed structured output
Level C: task retry
换 prompt/model/worker
Level D: task reroute
换 capability provider
Level E: local re-plan
重新分解当前 branch
Level F: global re-plan
只有任务定义已经失效才执行
越向下成本越高。
此外：
retry_policy = {
"max_attempts": 3,
"retry_on": ["429", "timeout", "503"],
"base_backoff_ms": 500,
"jitter": True,
"reroute_after": 2,
"deadline_aware": True,
}
应当和：
idempotency_key = f"{request_id}:{task_id}:{effect_version}"
一起设计。
对慢任务采用 as-completed，而不是无条件全量 barrier
Ray 的文档专门把“按 submission order 使用 ray.get 处理结果会增加运行时间”列为反模式之一；Anthropic 又实际遇到了同步 subagent wave 等待 slowest worker 的瓶颈。
因此典型 fan-out：
results = await asyncio.gather(*tasks)
虽然简单，却不一定是最佳生产语义。
更合理的逻辑是：
while pending:
result = await next_completed(pending)
state.add(result)
if aggregator.has_enough_evidence():
cancel_unnecessary_work()
if result.reveals_new_dependency:
schedule(new_task)
if deadline_near:
switch_to_partial_completion()
特别是：
6 个子任务：
4 个 2 秒完成
1 个 5 秒完成
1 个 45 秒卡死
不应默认让用户等待 45 秒，除非最后一个 task 是 final answer 的 hard dependency。
建议每条 edge 有：
required
optional
quorum
best_effort
例如：
aggregation requires:
all(required tasks)
AND at least 2 of 3 evidence tasks
这会比简单 await all 灵活得多。
并发宽度应该自适应，而不是固定
推荐 scheduler 监控：
queue_wait
service_time
rate_limit_rate
timeout_rate
token_rate
tool saturation
retry_rate
p95 latency
cost / request
再调节：
fanout_width
worker_count
model mix
batch size
一种简单策略：
if rate_limit_rate > threshold:
concurrency -= 1
elif queue_wait_high and tool_utilization_low:
concurrency += 1
更完善的系统可以对每类 capability 维护自己的控制器：
Search pool K = 8
Browser pool K = 3
Large LLM pool K = 5
Small LLM pool K = 20
Code sandbox pool K = 4
DB-write pool K = partition-based
Ray 的 resource-aware scheduling、pending-task backpressure 和 placement group 提供了这种执行层机制的成熟参考。
资源隔离不能只停留在“不同 prompt”
多个 subagent 具有不同“角色”并不等于安全隔离。
例如：
Research Agent:
web: read
internal docs: read
Billing Agent:
billing: read
refund: approval-required
Code Agent:
workspace: rw
shell: sandboxed
network: restricted
这三个 agent 不应该只是 system prompt 不同，而应该拥有不同 runtime capabilities。
Anthropic 2026 年对 Agent containment 的总结尤其值得注意：其产品利用 gVisor container、VM、filesystem/network boundaries、proxy 等进行环境层隔离；远程工具结果也被视为 prompt-injection attack surface；在 multi-agent 中还存在 trust escalation——subagent 生成的输出不能因为“来自自己的 agent”就自动升级为可信数据。 OpenAI Agents SDK 也提供 tool guardrails、approval 与 sandbox agents；Google ADK 提供 model/tool lifecycle callback，可用于 authorization/logging policy。
因此推荐给 artifact 增加 trust metadata：
{
"artifact_id": "...",
"producer": "web_research_agent",
"trust": "untrusted_external",
"contains_external_instructions": true,
"validated": false
}
而不是：
subagent output → automatically trusted system context
可观测性需要从“Agent trace”提升到“Task Graph trace”
OpenAI Agents SDK 已经内置 LLM generation、tool calls、handoffs、guardrails 等 tracing；LangSmith 支持 trace/metadata，并可接 OpenTelemetry 观测栈；Microsoft Agent Framework workflow 可导出 spans、metrics、events 和 delivery status；Anthropic 在生产中发现 full tracing 对排查“为什么 agent 没找到信息”非常关键，并额外监控 interaction structure。
一个生产 trace 最好具有：
request_span
├── planning_span
│ └── decomposition
├── task:t1
│ ├── queue_wait
│ ├── agent_run
│ │ ├── model_call
│ │ └── tool_call
│ └── artifact_write
├── task:t2
│ └──...
├── aggregation_span
└── delivery_span
建议重点监控以下指标，而不是只看模型 latency：
尤其值得增加一个：
[ UsefulParallelism= \frac{\text{critical-path useful work}} {\text{total agent work}} ]
如果系统 fan-out 20 个 agent，但最后 17 个结果没有进入 final answer，那么“并行度”很高却“有效并行度”很低。
为不同性能目标选择不同策略
由于用户没有指定 SLA，应根据目标切换 policy，而不是只有一种“最佳”配置。
Anthropic 对 agentic system 的总体建议也是从简单方案开始，只有明确带来收益时才增加 agentic complexity，因为 agentic systems 往往用 latency 和 cost 换取 task performance。 其 Research 生产数据进一步说明 breadth-first/high-value workloads 更容易证明这种成本合理。
一个可操作的参考调度器骨架
下面的代码不是某一框架 API，而是建议的控制面结构；底层 execute_with_agent() 可以替换成 OpenAI Agents SDK、LangGraph node、ADK agent、Microsoft Agent Framework executor 或 Ray task。
from __future__ import annotations
import asyncio
from collections import defaultdict
from dataclasses import dataclass, field
from enum import Enum
from typing import Any
class Effect(str, Enum):
READ_ONLY = "read_only"
IDEMPOTENT_WRITE = "idempotent_write"
IRREVERSIBLE = "irreversible"
@dataclass(frozen=True)
class TaskSpec:
task_id: str
dedupe_key: str
capability: str
dependencies: tuple[str,...] = ()
priority: int = 0
timeout_s: float = 30.0
max_attempts: int = 3
token_budget: int = 10_000
effect: Effect = Effect.READ_ONLY
aggregation_group: str = "default"
ordering_key: int = 0
payload: dict[str, Any] = field(default_factory=dict)
@dataclass
class TaskResult:
task_id: str
ok: bool
payload: Any = None
error: str | None = None
artifact_ref: str | None = None
class Scheduler:
def __init__(self, capability_limits: dict[str, int]):
self._limits = {
capability: asyncio.Semaphore(limit)
for capability, limit in capability_limits.items()
}
# single-flight: 相同 dedupe_key 的消费者复用同一个 underlying future
self._inflight: dict[str, asyncio.Future[TaskResult]] = {}
self._lock = asyncio.Lock()
async def submit(self, task: TaskSpec) -> TaskResult:
async with self._lock:
existing = self._inflight.get(task.dedupe_key)
if existing is not None:
return await asyncio.shield(existing)
loop = asyncio.get_running_loop()
future: asyncio.Future[TaskResult] = loop.create_future()
self._inflight[task.dedupe_key] = future
try:
result = await self._execute_with_retry(task)
future.set_result(result)
return result
except Exception as exc:
result = TaskResult(
task_id=task.task_id,
ok=False,
error=f"{type(exc).__name__}: {exc}",
)
future.set_result(result)
return result
finally:
async with self._lock:
self._inflight.pop(task.dedupe_key, None)
async def _execute_with_retry(self, task: TaskSpec) -> TaskResult:
sem = self._limits[task.capability]
last_error: Exception | None = None
for attempt in range(1, task.max_attempts + 1):
try:
async with sem:
async with asyncio.timeout(task.timeout_s):
return await execute_with_agent(task, attempt)
except Exception as exc:
last_error = exc
# 不可逆副作用不能盲目重试。
if task.effect == Effect.IRREVERSIBLE:
raise
if attempt < task.max_attempts:
backoff = min(0.5 * (2 ** (attempt - 1)), 8.0)
await asyncio.sleep(backoff)
assert last_error is not None
raise last_error
async def execute_with_agent(
task: TaskSpec,
attempt: int,
) -> TaskResult:
"""
Adapter:
- route to an eligible agent
- pass idempotency key
- execute model/tools
- validate structured result
- write immutable artifact
"""
raise NotImplementedError
实际生产实现还需要补：
persistent task DB
CAS/version state transition
distributed lock or durable single-flight
rate-limit token bucket
per-user fairness
priority/deadline queue
cancellation propagation
checkpoint
circuit breaker
dead-letter queue
Saga compensation
trace context
artifact store
permission policy
HITL
如果进程可能重启，示例中的 memory Future 和 Semaphore 都必须换成可分布式/持久化机制；这一点正是 Ray、Microsoft Durable Extension、LangGraph persistence 或外部 Temporal/Restate/DBOS 类 runtime 的价值所在。
推荐的生产落地组合
对于一个通用企业级多任务 Agent 平台，我更倾向于下面的分层，而不是绑定一个框架解决所有问题：
┌───────────────────────────────────────┐
│ API / Streaming / Job Status │
├───────────────────────────────────────┤
│ Planner + Normalizer + Dedup │
├───────────────────────────────────────┤
│ Typed Task DAG / Policy Router │
├───────────────────────────────────────┤
│ Durable Scheduler / Workflow Engine │
├───────────────────────────────────────┤
│ Agent Runtime / Model Adapter │
├───────────────────────────────────────┤
│ Tool Gateway / Permission / Sandbox │
├───────────────────────────────────────┤
│ Ray / K8s / Queues / Worker Pools │
├───────────────────────────────────────┤
│ State DB / Artifact Store / Event Log │
├───────────────────────────────────────┤
│ OTel / Trace / Eval / Cost Metrics │
└───────────────────────────────────────┘
在技术选型上：
快速构建复杂 agent workflow：LangGraph、Google ADK 2.0 或 Microsoft Agent Framework 都有很好的 graph/orchestration abstraction。LangGraph 在 state/checkpoint 语义方面透明，Microsoft 的 orchestration + Durable Extension 更完整地覆盖企业 durable workflow，ADK 2.0 则提供 deterministic graph 与 collaborative agent 的组合。
Python-first、希望自己掌握控制流：OpenAI Agents SDK 的 primitives 较薄，agent-as-tool/handoff/tracing/guardrail/session 与普通 Python orchestration 容易结合；需要 long-running reliability 时再接 durable runtime。
大量任务、复杂资源池、GPU/CPU/browser worker 调度：不要期待纯 LLM agent framework 替代 distributed execution substrate；Ray 的资源调度、actors、placement、backpressure 和 fault-tolerance 更适合这一层。
动态 research / investigation：可以借鉴 Anthropic lead-worker + artifact/evidence + citation/verifier + checkpoint 的结构，但应进一步解决其公开说明中的同步 wave/straggler 问题，并在高并发时引入 scheduler。
国内/中文模型栈和研究开发：AgentScope 已经覆盖 Agent、orchestration、state/session、A2A、sandbox、tracing/evaluation，并用 RayEvaluator 处理 parallel/distributed evaluation，是值得做 PoC 的国产开源路线。
最重要的是避免“框架驱动设计”：Anthropic 官方对 agent framework 的建议也是先理解底层 prompt、response 和控制流，因为框架抽象虽然方便，却可能隐藏真正的行为并诱导不必要的复杂性。
主要文献、官方文档与进一步阅读
以下均优先选择官方文档、公司工程文章或原始论文；引用本身可直接打开对应原始页面。
Ray。 Ray 2.58 的 Design Patterns & Anti-patterns、Key Concepts 和 Placement Groups 是理解 agent 系统底层 execution plane 的重要资料，尤其值得读 ray.wait backpressure、resources-based concurrency、supervisor actor、placement groups、fault tolerance 和 over-parallelization anti-pattern。
LangGraph / LangChain / LangSmith。 Workflows and agents 直接讨论 parallelization；Graph API 描述 State/Nodes/Edges、super-step、checkpointer 和幂等恢复；Multi-agent 文档区分 subagent/supervisor/router/handoff；LangSmith 提供 trace 与 OpenTelemetry 观测能力。
Microsoft Agent Framework。 当前最重要的是 Workflow capabilities、Workflow orchestrations、Magentic、checkpoints 和 Azure Functions Durable Extension。它们分别覆盖 sequential/concurrent/handoff/group-chat/Magentic、多 agent manager、持久 checkpoint 和 distributed durable execution。
AutoGen。 AutoGen Core 官方文档仍是理解 event-driven multi-agent runtime 的好材料：Actor model、asynchronous messaging、topic/subscription、concurrent agents、experimental distributed runtime，以及 Mixture-of-Agents 等 pattern 都有直接实现。Microsoft 当前 migration guide 同时说明了 AutoGen 与 Agent Framework 的演进关系。
Magentic-One。 Microsoft Research 的 Magentic-One 工作展示了一个 manager/orchestrator 如何协调 specialized agents，是当前 manager-led generalist multi-agent architecture 的代表性工作之一；当前 Agent Framework 的 Magentic orchestration 正是沿这一架构继续产品化，但 Microsoft 也明确提醒其超出原论文设计范围的效果尚不能直接保证。
OpenAI Agents SDK。 官方 Agent orchestration、SDK overview、Tracing、Guardrails、Human-in-the-loop 和 running-agents durable integrations 是最相关文档。其中 manager vs handoff、LLM-vs-code orchestration 以及 parallel-vs-blocking guardrail 很适合直接映射到任务管理系统。
Google ADK。 重点推荐 ADK 2.0 的 multi-agent/workflow、ParallelAgent、SequentialAgent、graph routes、collaborative workflow 和 state 文档。ParallelAgent 关于 branch independence 和 shared-state race 的说明尤其与本报告主题直接相关。
Anthropic，多 Agent Research。 How we built our multi-agent research system 是目前公开资料中对生产多 Agent orchestration 最具体的公司工程复盘之一，覆盖动态 decomposition、subagent budgets、重复工作、token economics、checkpoint、full tracing、synchronous-wave bottleneck、异步 consistency 问题以及 artifact handoff。
Anthropic，Agent 设计原则。 Building Effective AI Agents 提供 workflow vs agent、routing、parallelization、orchestrator-worker 等模式的工程背景，并强调只有在可验证改善结果时才引入额外 agentic complexity。
Anthropic，安全与隔离。 2026 年 How we contain Claude across products 对 sandbox、VM、egress、tool-output prompt injection、scoped identity 和 multi-agent trust escalation 提供了很强的 production security 参考。
Meta。 Muse Spark 以及 2026 年 7 月 Muse Spark 1.1 的公开资料显示 Meta 已把 multi-agent orchestration、parallel subagent delegation 和 end-to-end latency optimization 放入模型 agentic capability 本身。对模型级 planner/router 很有参考意义，但当前公开 runtime 一致性/调度细节仍少于专门 workflow framework。
AgentScope。 官方 orchestration、Runtime、evaluation 和 A2A 文档分别覆盖多 Agent 编排、生产状态/生命周期、Ray-based parallel evaluation 和跨 agent interoperability，是中文生态中较完整的一组资料。
ReAct。 ReAct: Synergizing Reasoning and Acting in Language Models，ICLR 2023。ReAct 通过交替 reasoning 和 action 构成 agent loop，是大量现代 tool-using agents 的基础思路；但应注意它解决的是 agent 内部 reasoning/action control，而不是完整的 multi-agent scheduler。
CAMEL。 CAMEL: Communicative Agents for “Mind” Exploration of Large Scale Language Model Society，NeurIPS 2023，代表了 role-playing/role-conditioned 多 Agent 协作路线，对“角色怎样定义、如何保持角色边界”具有基础参考价值。
AutoGen 论文。 Microsoft Research 的 AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation 为后续 AutoGen framework 的 message-based multi-agent conversation/runtime 奠定了学术基础。
Scaling Large Language Model-based Multi-Agent Collaboration。 ICLR 2025，研究 LLM 多 Agent collaboration 的规模扩展问题，说明“增加 agent/协作规模”本身已经成为一个独立研究变量，而不是默认越多越好。
Multi-Agent Collaboration via Evolving Orchestration。 NeurIPS 2025，关注固定 orchestration 结构的限制以及随任务动态演化协作结构，是从“静态 agent topology”走向“动态 task/orchestration policy”的代表性工作。
On the Resilience of LLM-Based Multi-Agent Collaboration。 该研究直接关注多 Agent collaboration 在 faulty/malicious agents 条件下的 resilience，对 verifier、trust propagation 和局部故障隔离问题具有参考价值。
AAMAS 的传统 Task Allocation 研究。 Asynchronous Communication Aware Multi-Agent Task Allocation（AAMAS 2023）从传统 MAS 角度研究异步通信条件下的 coalition/task allocation。虽然不是 LLM Agent 专用研究，但其问题定义——task allocation、communication delay、agent coordination——与现代 agent scheduler 本质上高度相关。
IJCAI。 IJCAI 2024 proceedings 包含 Large Language Model Based Multi-agents: A Survey of Progress and Challenges，可用于补充 LLM multi-agent 研究脉络；IJCAI 2023 proceedings 也保留了传统 multi-agent task allocation、dispatching/rescheduling 等研究线。
综合这些资料，可以把近几年多 Agent task management 的演进概括为：
2023 左右
Role / Conversation / ReAct
↓
2024
Supervisor / Group Chat / Agent Teams
↓
2025
Graph Workflow + Dynamic Orchestration
+ production tracing / checkpoint
↓
2026
Durable workflow + model-native delegation
+ stronger sandbox / identity / observability
↓
生产成熟方向
Semantic Planner
+
Deterministic Task Control Plane
+
Distributed Execution Plane
+
Evidence / Artifact / State Plane
+
Security / Observability / Delivery Plane
这个方向比“不断增加 Agent 数量”更重要。真正决定复杂输入能否稳定处理的，不是系统里定义了多少个角色，而是能否把重复消除、依赖、路由、bounded concurrency、资源预算、状态所有权、幂等、checkpoint、冲突协议、provenance、权限和 delivery semantics变成一等公民。Ray 从执行系统、LangGraph/ADK/Microsoft 从 workflow、OpenAI 从 agent runtime primitives、Anthropic 从生产实践、Meta 从模型级 orchestration 分别证明了这一趋势的不同侧面。
DataLearner 官方微信
欢迎关注 DataLearner 官方微信，获得最新 AI 技术推送
