多 Agent 并发治理

拓扑决定协调成本

中心 Orchestrator

中心节点分配、验收和汇聚，控制权清楚、预算易治理，是默认起点。风险是上下文与调度瓶颈、单点故障，以及中心对领域细节理解不足。可通过 Durable Runtime 与分层 Orchestrator 缓解，但不要马上演变成无界树。

流水线

每个 Agent 处理上一产物并交给下一节点，责任与数据流直观，适合阶段稳定的任务。缺点是尾延迟相加、早期错误逐级放大、每次序列化都可能损失信息；能用确定性步骤的阶段不必都变成 Agent。

点对点协作

Agent 互相发送任务或事件，灵活但最难治理身份、信任、共享状态、循环和全局终止。只有协作关系确实无法由中心编排表达、参与者自治是业务要求时才考虑；“更像人类团队”不是充分理由。

区分私有工作区与共享事实

每个 Agent 拥有私有 Scratchpad、临时 Context 和工作区；共享层只保存任务契约、经验证事实、Artifact、决策和外部回执。写共享状态要带 Owner、来源、时间、置信/验证状态与版本。

“所有 Agent 共享同一聊天记录”会制造 Context 污染、权限扩散和隐式耦合。正确模式是读版本化快照、提出事实/变更，再由单写者、事务或合并协议提交。自由文本可以作为候选说明，不能直接覆盖业务状态。

并发写入按业务实体治理

默认使用乐观并发：读取实体版本，生成变更，提交时比较基础版本；冲突则读取新状态并决定重算、三方合并或人工。高冲突实体可以采用单写者/Actor、租约或队列串行化；锁必须有 Owner、超时和 fencing token，防止过期持有者继续写。

可交换、幂等的更新适合并行；不可交换的外部效果必须串行或走事务/Saga。文件与代码合并还要区分文本无冲突和语义无冲突：自动 merge 通过后仍需类型、测试和领域验证。

interface FactWrite {
  entityId: string;
  baseVersion: number;
  patch: unknown;
  evidenceRefs: string[];
  authorRunId: string;
}

async function commit(write: FactWrite) {
  const current = await facts.load(write.entityId);
  if (current.version !== write.baseVersion) {
    return { status: 'conflict', current } as const;
  }
  return facts.compareAndSet(write);
}

Agent 间消息需要明确语义

至少区分 request、result、event、cancel 和 error。每条消息携带 message ID、sender/recipient、task 与 plan version、correlation/causation ID、Deadline、Schema 版本、数据级别和幂等键。传输层的“至少一次”会带来重复，消费者必须按业务 ID 幂等。

Deadline 是端到端预算，不应在每一跳重置；取消与错误需要传播到依赖节点。未知消息类型、版本或越权来源应拒绝并进入可观测死信，不能让模型自由解释 wire payload。

若跨进程或团队，可借鉴 CloudEvents 对事件元数据的标准化，以及 W3C Trace Context 的因果传播；但这些标准不定义业务任务状态，仍需自己的任务与能力契约。

检测委派循环与等待死锁

父子委派图应在加入边前做环检测，并限制最大深度、总子任务数、总 Tool 调用和累计成本。任务指纹可识别同一目标在 Agent 间来回转交；指纹要包含规范化目标、关键输入与计划版本，避免只比较文字。

死锁来自等待图而非委派图：A 等 B 的资源、B 又等 A 的结果，即使父子关系无环也会停住。运行时维护 wait-for edges，周期检测或超时后选择取消、抢占或人工；超时只是触发器，不是根因修复。

汇聚不是把答案拼接

Join 先检查必要依赖终态和目标覆盖，再处理重复、冲突、时效与不同假设。事实冲突应按权威性、来源独立性、对象版本和时间判断；无法消解时显式保留分歧或升级，不能用多数 Agent 投票代替事实。

最终决策主体承担验收责任。对代码产物是集成测试和 review；对研究是引用覆盖与来源质量；对业务写入是后置条件与对账。多 Agent 可以提供多个候选证据，却不会自动生成“集体正确”。

并发受系统级预算约束

每个子任务有局部预算，系统还要有全局模型并发、Tool 配额、队列、存储、沙箱和租户限额。若只限制单 Agent，递归委派仍可放大资源。Admission Control 根据任务价值、租户配额、当前负载和关键路径决定是否启动。

背压应从下游向父级传播：Tool 限流时减少新子任务，而不是让队列无限积压。公平调度防止一个高分支 Run 占满全部模型并发；取消与 Deadline 释放资源并禁止晚到提交。

Anthropic 的原始工程报告指出，其多 Agent 研究系统在特定评测中质量提升同时消耗远高于普通聊天的 Token。这再次说明指标应是每单位任务价值的成功、覆盖与时延，而不是 Agent 数、Tool 次数或总 Token。

何时不该使用多 Agent

• 任务依赖高度串行，拆分后仍频繁等待或转述；
• 所有执行者必须共享庞大且快速变化的同一状态；
• 写冲突频繁、业务要求强一致且无法可靠合并；
• 单 Agent 加确定性工具、检索或更好的任务契约已经达标；
• 没有子任务级验收，最终只能凭模型综合；
• 任务价值不足以覆盖多倍成本、尾延迟和治理负担。

采用决策需要渐进实验：单 Agent 基线；有限并行的 Star；必要时增加专业 Agent；只有中心瓶颈被证据确认后才讨论分层或 Mesh。RFC 写清收益假设、失败预算、Owner、回退开关和下线条件，并以代表性任务评测和生产 SLO 决定扩张。