并行派发多个subagent时，指令里缺少“等全部完成后再汇总”就会导致任务遗漏或结果混乱——当多Agent编排的正确性依赖于用户在自然语言指令里“恰好写全了等待机制”，这种“靠提示词保证并发正确性”的脆弱性，和传统编程里“靠代码保证并发安全”之间到底差了几个可靠性量级？

从自然语言屏障到运行时契约：多Agent并发正确性的可靠性量级分析

摘要与阅读导引

并行派发多个 subagent 已经成为复杂任务分解的常规手段，但一个被反复忽视的事实是：编排的正确性往往并不由框架保证，而是由用户在自然语言指令里是否“恰好写全”了等待与汇总语义来保证。一旦指令中缺少“等全部完成后再汇总”这类屏障描述，就会出现子任务结果被提前消费、部分分支被静默丢弃、汇总阶段读到半成品等典型故障。本文把这一现象抽象为“提示词级并发控制”与“代码级并发控制”的对照问题，沿着“语义缺失—调度竞态—可靠性衰减”这一条主线展开分析。

全文的核心判断是：二者并非同一坐标系内的强弱之分，而是分属两个不同的可靠性量级体系。代码级并发安全建立在编译期检查、运行时原语与形式化模型之上，其失效概率可以被建模、被度量、被压测；提示词级并发正确性则建立在自然语言的语用完整性与模型的行为稳定性之上，其失效概率既缺少可观测口径，也缺少可复现的边界。本文评述：把后者当作前者使用，本质上是用“期望”替代“约束”，在工程上等价于把并发安全交给注释来保证。

文章依次讨论问题定义、机制原理、量化对比、工程路径与前沿预判，并在每一节给出可操作的检查清单与代码骨架。适合已经具备多Agent编排经验、希望把系统从“能跑”推进到“可验证”的从业者阅读。

目录

一、问题定义：被自然语言掩盖的并发语义缺口

1.1 什么是“提示词级并发控制”

先给出本文使用的定义。提示词级并发控制，指多Agent系统中，子任务的派发顺序、并行边界、汇合时机与结果合并规则，全部或主要由自然语言指令中的描述来约束，框架层不提供强制性的同步原语。与之相对的代码级并发控制，指上述语义由程序结构承载，例如 Future/Promise 的 join、屏障（barrier）、信号量、结构化并发作用域（structured concurrency scope）等，编译器或运行时会对违反约束的行为报错或阻塞。

这个区分看似只是“写在哪”的问题，实则决定了失效模式。自然语言描述是一种“软约束”，模型可以遵守，也可以部分遵守，还可以在上下文压力下改变遵守程度；程序原语是“硬约束”，不满足条件时执行流无法继续。本文评述：把并发正确性寄托在软约束上，等于把系统的不变量交给了概率分布来维护，而并发缺陷恰恰是最不能容忍概率化的那一类缺陷。

1.2 典型故障的三种形态

在缺少显式等待语义时，故障通常呈现三种形态。第一种是提前汇总：编排者（orchestrator）在第一个或前若干个 subagent 返回后即触发汇总，汇总输入只覆盖部分分支，输出看似完整实则残缺。第二种是结果串扰：多个 subagent 共享同一输出通道或同一文件路径，后完成者覆盖先完成者，或汇总器把 A 分支的中间产物误当作 B 分支的结论。第三种是静默丢弃：某个分支超时或异常，但因为没有汇合点做完整性校验，缺失从未被感知，最终交付物中该子问题凭空消失。

三种形态的共同点是“不报错”。这与传统并发编程中的竞态条件高度相似：程序照常退出，结果却是错的。区别在于，传统竞态至少可以借助 ThreadSanitizer 一类工具在测试阶段捕获，而提示词级并发缺陷往往只在特定任务、特定模型版本、特定上下文长度下复现，缺少系统性的检测手段。

1.3 为什么这不是“写清楚就行”的小问题

一种常见反驳是：只要在指令里写清“等全部完成后再汇总”就解决了。这个反驳忽略了两点。其一，自然语言的完备性无法被静态验证，用户无法在派发前证明自己的指令覆盖了所有并发边界，尤其是当子任务数量动态变化、存在嵌套派发时，需要描述的等待关系会呈组合式增长。其二，即便写全了，模型对指令的遵守也不是确定性的，长上下文、工具调用失败、子任务返回格式异常都会削弱遵守程度。

笔者认为，真正的问题不在于用户是否细心，而在于系统把本应由运行时承担的职责转移给了用户。这是一种责任错配：并发安全是系统属性，不应由每一次调用的自然语言描述来重新保证。就像我们不会要求调用方在每次使用线程池时用注释声明“请保证线程安全”，多Agent框架也不应要求用户在提示词里手工声明屏障。

二、机制剖析：从语义缺失到调度竞态的因果链

2.1 编排器的控制流本质是一个数据流图

无论框架如何包装，多Agent编排在控制流上都可归约为一个有向图：节点是子任务，边是数据依赖，汇合节点需要等待其所有前驱完成。传统数据流系统（如 Apache Beam、TensorFlow 图执行）把这种依赖编码进图结构，调度器据此决定何时可以触发下游。多Agent系统若把图结构交给自然语言隐式表达，调度器实际上并不知道哪些边存在，只能依据模型输出的“下一步动作”逐步推进。

这带来一个结构性后果：依赖关系从“系统可知”退化为“模型可推断”。模型推断依赖上下文，而上下文是有损的。当子任务数量增多、返回内容变长，早期派发时写下的“最后统一汇总”很可能在后续轮次中被稀释。本文评述：这不是模型的“记忆力”问题，而是把图结构存放在了一个非结构化的、会被截断和重写的介质里。

2.2 三个层次的竞态来源

第一层是调度层竞态：并行派发后，各 subagent 的完成顺序不确定，若汇总触发条件写成“收到结果即汇总”，则触发时机取决于最慢分支与调度策略的交互。第二层是状态层竞态：多个 subagent 读写共享的会话状态、文件系统或向量库，缺少隔离与版本控制时产生覆盖。第三层是语义层竞态：即便调度与状态都正确，汇总器对“部分结果”和“完整结果”的判别也可能出错，因为它没有可靠的完整性信号。

三层竞态中，语义层最隐蔽。调度层问题可以通过日志观察完成顺序，状态层问题可以通过文件版本追溯，语义层问题却往往表现为“结果看起来合理但少了一块”。这也是为什么很多团队在事故复盘中只能得出“模型这次没按指令来”的结论，而无法定位到具体机制。

2.3 一个最小可复现的故障骨架

下面给出一个抽象化的伪代码骨架，用于说明缺少屏障时控制流如何提前进入汇总。该骨架不依赖特定框架，仅表达调度语义。

// 反面示例：汇总触发条件与分支完成数解耦
async function orchestrate(tasks, llm) {
  const results = [];
  const handles = tasks.map(t => dispatch(t));   // 并行派发
  for (const h of handles) {
    const r = await h;                          // 逐个 await
    results.push(r);
    if (shouldSummarize(llm, results)) {        // 由模型判断是否汇总
      return summarize(llm, results);           // 可能提前返回
    }
  }
  return summarize(llm, results);
}

这段代码的问题在于 shouldSummarize 把汇合判断交给了模型。模型可能因为首个结果“看起来足够完整”而返回真，导致后续分支被丢弃。正确的写法是把汇合条件写成对 handles.length 的确定性判断，模型只负责内容合并，不负责时机判断。本文评述：让模型决定“何时汇总”，本质上是把控制平面与数据平面混在一起，而控制平面恰恰是最需要确定性的部分。

2.4 与经典并发缺陷的对应关系

提前汇总对应“未等待所有生产者完成即消费”的读偏（read skew）；结果串扰对应“缺少隔离级别”导致的写覆盖；静默丢弃对应“异常被吞掉”的失败静默。这三类问题在数据库事务与并发编程中都有成熟的理论刻画，例如隔离级别、原子性、失败原子性（fail-atomicity）。多Agent系统的特殊之处在于，它的“事务边界”由自然语言划定，因而无法直接套用这些理论。

笔者认为，可以借用“失败原子性”的思想来设计多Agent编排：一次编排要么产出覆盖全部子任务的完整结果，要么显式失败并报告缺失分支，不允许产出“部分成功但看起来完整”的结果。这个约束一旦确立，就能把大量隐蔽故障转化为可观测的显式失败，从而把问题从“结果对不对”前移到“流程完不完整”。

三、可靠性量级：两套并发控制体系的对照度量

3.1 度量口径的差异

讨论“差几个量级”之前必须先明确口径。代码级并发安全的可靠性通常用两类指标刻画：一是缺陷密度，例如每千行代码的并发缺陷数，工业界常引用的是静态分析工具在大型代码库上的告警与确认缺陷比例；二是失效概率，例如在给定并发压力下的错误率，可通过压测与故障注入测量。提示词级并发正确性目前缺少对应指标，实践中常用的是任务成功率、人工抽检合格率，二者都依赖任务分布，难以横向比较。

本文评述：口径不可比，是“差几个量级”这个问题最难回答的部分。任何给出精确倍数的说法都需要谨慎对待。可行的做法是分层比较：在“约束是否可静态检查”“失效是否可复现”“缺陷是否可自动检测”三个维度上做定性到半定量的对照，再结合公开的工程经验给出区间估计，并明确标注为估计而非实测。

3.2 三维对照表

表中四行里，最具决定性的其实是最后一行。代码级并发缺陷大多以崩溃、死锁、断言失败的形式暴露，属于“响的失败”；提示词级并发缺陷则以静默错误的形式存在，属于“哑的失败”。在可靠性工程中，哑失败的危险性远高于响失败，因为它会污染下游决策而不被察觉。本文评述：若以“未被发现的错误交付比例”为口径，二者的差距可能达到两到三个数量级；但这一估计依赖任务复杂度与模型能力，应视为量级判断而非精确数值。

3.3 为什么差距难以被工程手段完全抹平

有人会提出，只要在框架层加校验、在汇总前检查分支数量，就能把提示词级控制提升到接近代码级的可靠性。这个思路方向正确，但存在上限。原因在于，框架能校验的是“结构完整性”，例如分支数是否齐全、每个分支是否返回了符合 schema 的结果；它无法校验“语义完整性”，例如某个分支虽然返回了结果，但结果是否真正回答了子问题。后者仍需要模型判断，而模型判断本身又引入了不确定性。

笔者认为，务实的定位是：用运行时契约把“结构完整性”做到接近确定性，把“语义完整性”留给模型并以抽检和置信度标注兜底。这样虽然不能完全消除差距，但可以把哑失败压缩到可接受范围，并把剩余风险显式化。这比追求“提示词写得足够好”要可靠得多，因为前者是系统能力，后者是个人技巧。

四、工程路径：把等待机制从提示词下沉为运行时契约

4.1 原则：控制平面与数据平面分离

第一条原则是把“何时汇总”与“汇总什么”分开。何时汇总由确定性代码决定，汇总什么由模型决定。具体做法是引入显式的汇合原语，例如 joinAll(handles, {mode: 'all'})，其语义与 Promise.all 一致：任一分支失败则整体失败，全部成功才进入汇总。这样即便提示词里没写“等全部完成”，运行时也会强制等待。

第二条原则是给每个子任务分配独立的输出槽位（slot），禁止共享可变通道。槽位带版本号与写入者标识，汇总器只读槽位，不读中间通道。这条原则直接消解了结果串扰这一类故障。本文评述：这两条原则并不新颖，它们在传统并发编程中几乎是常识，真正的新意在于把它们从“开发者自觉”变成“框架默认”，从而不再依赖提示词的完备性。

4.2 结构化输出契约

要求每个 subagent 返回结构化结果，至少包含任务标识、状态、产物与自评置信度四个字段。状态取值限定为成功、失败、部分完成三类，禁止自由文本描述状态。汇总器在合并前先做结构校验，任何字段缺失或状态非法都视为该分支失败，触发整体重试或显式报错。

{
  "task_id": "sub-03",
  "status": "success",          // success | failed | partial
  "artifact": { "type": "text", "ref": "slot://run-42/sub-03" },
  "confidence": 0.82,
  "elapsed_ms": 4310
}

结构化契约的价值在于把“语义完整性”的一部分转化为“结构完整性”。例如 status: partial 会强制汇总器进入降级路径，而不是把半成品当成品。本文评述：契约设计的关键是让“不完整”成为一种必须显式声明的状态，而不是一种默认被忽略的可能。

4.3 可操作的落地步骤

第一步，盘点现有编排流程，标出所有“由模型决定是否继续”的判断点，这些是控制平面泄漏的高风险位置。第二步，把这些判断点替换为确定性条件，模型只保留内容生成职责。第三步，为每个子任务建立独立槽位与结构化契约，并在汇总前做 schema 校验。第四步，引入完整性断言，例如汇总输入的分支数必须等于派发数，否则抛出显式异常。第五步，建立回归用例集，覆盖分支超时、返回格式异常、部分完成等边界，把并发正确性纳入持续集成。

这五步中，第四步最容易被跳过，却收益最大。一条简单的断言就能把大量静默丢弃转化为可观测失败。本文评述：工程上最有效的改进往往不是更聪明的模型，而是更笨但更确定的检查。把“聪明”留给内容，把“笨”留给控制，是这类系统走向可靠的基本分工。

4.4 拓展学习资源

关于结构化并发与并发缺陷检测，可参考 Java 结构化并发官方文档 与 ThreadSanitizer 文档；关于多Agent编排的工程实践，可参考 LangGraph 文档 与 AutoGen 文档。这些资料分别从语言运行时与编排框架两个方向提供了可借鉴的约束设计思路。

五、前沿预判与结论

5.1 三个可预期的演进方向

其一，编排描述语言化。业界正在探索用声明式配置描述子任务依赖与汇合语义，模型只填充内容，不参与控制流决策。其二，运行时校验前移。把 schema 校验、完整性断言、超时与重试策略内置到框架，使“忘记写等待”在结构上不可能发生。其三，评测体系专门化。针对并发正确性设计基准任务，度量静默错误率而非仅看端到端准确率。

本文评述：这三个方向共同指向一个判断——多Agent系统的成熟度，最终取决于它把多少“用户需要记住的事”变成了“系统自动保证的事”。提示词写得好不好，不应成为系统正确性的最后一道防线。

5.2 结论

回到最初的问题：靠提示词保证并发正确性与靠代码保证并发安全，差了几个可靠性量级？本文的结论是，在“结构完整性”层面，通过运行时契约可以把差距压缩到接近一个量级；但在“语义完整性”层面，由于模型判断的固有不确定性，差距仍可能维持在两到三个量级，且主要表现为静默错误而非显式崩溃。这个差距不是靠把提示词写得更长更全就能消除的，它需要系统设计层面的责任重新分配。

因此，务实的工程立场是：不要试图用自然语言去保证并发正确性，而应把等待、汇合、完整性校验下沉为框架的默认行为，让提示词只承担它擅长的内容描述职责。当“等全部完成后再汇总”不再需要用户特意写出来，而是运行时的默认语义时，这个问题才算真正被解决。

主要参考文献