第十四章　Multi-Agent 架构

第十四章　Multi-Agent 架构：协调与代价

核心命题：Multi-Agent 系统回答一个核心问题：如何将复杂的解空间分解为多个专业化的子空间，并协调这些子空间的求解者——在三轴约束上实现比单一通用 Agent 更优的帕累托位置。但专业化的收益与协调的代价之间存在必须被精确核算的权衡。

14.1 专业化的必然性与边界

单一通用 Agent 在极大的解空间中搜索，效率低且可靠性差。专业化是将有限能力集中投入特定解空间的优化策略。但专业化有边界：当子任务之间的信息耦合度高，分解后的协调成本可能超过专业化收益。判断标准：子任务的输出是否可以被简洁地结构化表达？如果 Agent B 需要 Agent A 的完整内部状态才能工作，则分解是错误的。

计算复杂性视角：协调问题的理论成本下界

Multi-Agent 协调问题的计算复杂性是被严重低估的。 $n$ 个 Agent 的联合规划问题（Dec-POMDP，去中心化部分可观测马尔可夫决策过程）是 NEXP-complete——比单 Agent 的 PSPACE 规划难指数量级。

这从计算层面解释了为什么 Swarm 模式在实践中成本失控：不只是协调机制设计不够好，而是问题的理论下界就在那里——无论协调机制如何优化，在 Agent 数量增长时的复杂性都存在不可消除的指数障碍。每增加一个 Agent 的边际协调成本可能超过其边际贡献，这是 Swarm 模式在实践中需要极其谨慎使用的计算理论根据。

边界说明：Dec-POMDP 的 NEXP-complete 结果来自理论最坏情况；实际 Multi-Agent 系统通过结构化约束（消息限制、角色专业化、Orchestrator 中心化）显著降低了实际复杂度。此处使用这个结论作为”为什么协调天然昂贵”的理论根基，不用于定量预测实际系统的协调成本。

14.2 通信协议设计

Agent 之间如何通信，直接决定了协调成本与信息损耗：

自然语言通信：灵活，但信息密度低、歧义高，适合开放性协作。结构化消息：精确，信息密度高，但需要预先定义 Schema，适合明确分工的系统。共享状态：适合需要频繁同步的 Agent，但引入并发一致性问题。

推荐原则：优先使用结构化消息；复杂的协调逻辑使用显式的消息 Schema，不依赖自然语言的隐式理解。

14.3 一致性与冲突解决

当多个 Agent 对同一状态做出矛盾判断或并发修改时，如何仲裁？这与分布式系统中的共识问题有深刻对应——但 Multi-Agent 系统的特殊性在于：冲突可能发生在工具层（并发写同一资源）、状态层（读取了对方已失效的缓存状态）、或目标层（两个 Agent 的子目标相互矛盾）。

三类典型冲突场景：

写-写冲突：Agent A 和 Agent B 同时对同一资源（文件、数据库行、API 状态）发起写操作，后写覆盖先写。解决模式：悲观锁（操作前加锁，代价是串行化）；乐观并发控制（操作时记录版本号，写入前检测版本冲突，失败时回滚重试）；操作转化（将”设置值为 X”的非交换性操作转化为”增加量 ΔX”的可合并操作，从根本上消除冲突）。

读-写冲突（幻读）：Agent B 基于 $T_0$ 时刻的状态 $S_0$ 做出决策，而此时 Agent A 已将状态更新为 $S_1$ ，B 的决策建立在失效的前提上——操作形式上成功，但语义上已经无效。这是 Multi-Agent 系统中最隐蔽的冲突类型。解决模式：状态版本戳（每次读取时记录版本，执行时验证版本未变）；Checkpoint 同步点（在关键步骤前强制读取最新状态）；不可变状态快照（Agent 操作副本，定期合并）。

目标层冲突：Agent A 的子目标是”最小化代码行数”，Agent B 的子目标是”最大化测试覆盖率”，两者都向各自目标优化，产生语义上相互矛盾的修改——两个操作都”成功执行”，但整体结果违背委托人意图，且无法在工具层检测到。解决模式：目标层约束在 System Prompt 中显式编码优先级（而非只描述子目标）；Orchestrator 在分配子任务时传递约束包——子 Agent 的操作空间不只是子目标，还包括不可侵犯的全局约束。

三种仲裁机制的工程权衡：

Orchestrator 中心仲裁：中心协调者持有全局状态，所有写操作经 Orchestrator 串行化。消除冲突最彻底，但协调者是瓶颈且单点故障。适合冲突频率高、写操作需要严格全局一致性的场景。
黑板模式（乐观并发）：共享”黑板”状态，冲突在写入时检测并由版本胜者或预定义策略解决。容许更高并发度，代价是需要设计回滚与重试逻辑，以及接受短暂的不一致窗口。适合冲突频率低、追求吞吐量的场景。
市场模式（投票/竞价）：通过竞价或投票解决冲突，没有中心权威。最高并发度，但共识过程本身消耗成本，且可能出现振荡（多个 Agent 反复改变决策）。适合没有明确权威、子问题间耦合松散的探索性场景。

14.4 元 Harness：驾驭多个 Agent 的 Harness

驾驭多个 Agent 的 Harness 是一个”元 Harness”——设计问题与单 Agent Harness 相似，但在状态管理和一致性上复杂度更高：如何维护分布式状态的一致性（防止多 Agent 并发写入导致状态混乱）？如何检测整个系统层面的发散，而不只是单个 Agent 的发散？

14.5 实际 Multi-Agent 架构模式

模式	适用场景	Q/T/C 特征	协调复杂性	典型失败模式
Orchestrator-Worker	明确分工，并行执行	T↓，C 可控	低（中心化，接近多项式）	Worker 失败级联
Pipeline	顺序依赖任务	Q↑（专业化），T 一般	低（线性传递，O(n)）	早期错误放大
Debate/Review	需要多角度验证	Q↑↑，C↑↑	中（轮次收敛，O(n²) 交互）	无休止的讨论
Swarm	探索性任务	Q 不确定，C 高	高（联合规划接近 NEXP，指数级）	协调成本爆炸

协调复杂性一列揭示了架构选择的计算理论依据：从 Orchestrator-Worker 到 Swarm，不只是”灵活性递增”，而是协调复杂性沿指数方向跃升。在评估 Swarm 模式的可行性时，需要显式核算复杂性代价，而非仅凭”任务是探索性的”直觉选择。

逐模式设计指南

Orchestrator-Worker

何时选择：任务可以被清晰分解为并行子任务；子任务间无强状态依赖；结果可以被独立验证；Orchestrator 的协调逻辑足够简单（不超过 O(n) 的调度决策）。若子任务间存在频繁的状态共享，则退化为高成本的中心化串行执行，丧失并行收益。

核心实现要点：Orchestrator 持有全局 Plan 和子任务分配逻辑；Worker 接收完整的子任务规范（包含完成标准、允许的工具集、预期输出格式），而非仅”做 X”的模糊指令；Worker 返回结构化结果摘要而非原始输出，防止 Orchestrator 的 Context 被低密度内容污染（见 §8.4）。

典型陷阱：Worker 失败后 Orchestrator 缺少 fallback 设计，整个任务卡住——应在子任务规范中包含 fallback_strategy 字段；Orchestrator 成为瓶颈，在高并发场景下响应延迟——应将 Orchestrator 设计为”轻量协调者”而非”重量处理者”，避免在 Orchestrator 层做大量计算。

Pipeline

何时选择：任务有明确的阶段性依赖（A 的输出是 B 的必要完整输入）；阶段间接口可以结构化定义；每个阶段的质量可以在阶段完成时独立验证。若阶段间需要频繁”回溯”，Pipeline 的线性假设被打破，应改用 Orchestrator-Worker。

核心实现要点：每个阶段的输出应是下一阶段的完整自足输入，不依赖”过去的历史”——每个阶段的 Agent 应能在没有前序对话记录的情况下独立工作；阶段间数据必须结构化（避免自然语言传递，歧义在多跳后会被放大）；每个阶段出口加 Hook 验证输出质量，而非只在最终阶段验证。

典型陷阱：早期阶段的错误被下游放大（“垃圾进，垃圾出”在多跳后变得不可追溯）——Hook 出口验证是必要的防线；阶段数量过多导致 Context 在传递中大量压缩，关键信息丢失——控制 Pipeline 深度，超过 5 个阶段时考虑引入中间状态 Checkpoint。

Debate/Review

何时选择：输出质量是关键约束，且单一 Agent 存在系统性盲点（如代码安全审查、多角度分析）；存在明确的验收标准，使”辩论”可以收敛到可判断的结论；成本预算允许 O(n²) 级别的交互开销。

核心实现要点：明确定义辩论终止条件——达成一致 OR 超过 N 轮 OR 超出 token 预算，三者取先到者；采用非对称角色设计（一个生成，一个批判）比两个平等辩手更易收敛，减少”互相赞同”的无效轮次；批判 Agent 的 System Prompt 应明确要求”找出具体问题”而非”是否同意”。

典型陷阱：无休止的讨论（未设定终止条件）；同质化偏差——两个来自相同模型的 Agent 容易相互迎合，失去”多角度”的初衷——解决：使用不同温度参数、不同 System Prompt 风格，或将批判者设计为专门的”反例生成器”。

Swarm

何时选择：任务空间极大且结构未知，需要大量并行探索；单个 Agent 的视野不足以覆盖全局；有充足的成本预算和时间缓冲（Swarm 的 C 轴代价高且难以精确预测）。使用前应优先问：这个任务能否用 Orchestrator-Worker 分解？若能，Swarm 是过度设计。

核心实现要点：每个 Agent 独立探索，定期向共享状态写入结构化发现（而非结论），由汇聚 Agent 整合；设计明确的汇聚机制——何时停止探索（时间预算 OR 覆盖率阈值 OR 边际新发现递减），以及如何合并结论（投票、加权、Orchestrator 综合）；必须设置硬成本熔断，而非只设软限制——Swarm 的成本失控风险在架构模式中最高。

典型陷阱：缺少汇聚设计导致探索永不结束，成本爆炸；Agent 间结果重复（多个 Agent 探索了相同区域）——解决：在共享状态中维护”已探索区域”标记，新 Agent 启动时先读取避免重复；Swarm 产生大量低质量发现，汇聚 Agent 被噪声淹没——解决：要求每个 Agent 的发现携带置信度评分，汇聚阶段按置信度加权。

14.6 Multi-Agent 调试与可观测性

§12.4 讨论了单 Agent 系统的调试方法论——从成本异常入手、复放（Replay）问题步骤、最小化复现条件。Multi-Agent 系统的调试是这些方法的延伸，但复杂度有质的跳跃：问题的根因可能跨越多个 Agent 的边界，且 Agent 之间的消息交错顺序在每次运行中可能不同（非确定性交错），传统的单线程调试思路在此失效。

三类 Multi-Agent 特有的失败模式：

失败类型	表现症状	根因定位难点
状态同步失效	每个 Agent 输出看似合理，整体任务失败	单个 Agent 日志正常，问题在状态传递边界
消息顺序敏感性	同一任务重跑结果不同	消息交错顺序随运行变化，难以稳定复现
级联失败	一个 Worker 失败后系统整体卡住	失败传播路径跨多个 Agent，追溯链断裂

可观测性的三层扩展：

单 Agent 系统的结构化日志（§12.3）需要在三个维度上扩展以适配 Multi-Agent 场景：

全局因果追踪（Causal Tracing）：每条消息和状态变更需要携带因果链标识符（Trace ID + Span ID + Parent Span ID），记录”这个操作是由哪个 Agent 的哪条消息触发的”。没有因果链，跨 Agent 的失败只能看到症状而非根因。最小化追踪记录格式：{trace_id, span_id, parent_span_id, agent_id, timestamp, operation, input_state_hash, output_state_hash}。

消息序列快照（Message Timeline）：记录所有 Agent 间消息的时序图——不只是每个 Agent 自身的日志，而是整个系统通信拓扑随时间的变化。在失败时可以”回放”消息顺序，识别是哪步通信引发了状态分叉。这与分布式系统的 Jaeger/Zipkin 追踪思路一致，在 Multi-Agent 场景中是同等必要的基础设施。

系统层传感器（Observer Agent）：在执行 Agent 之上设置一个观测 Agent，专门监控整体系统状态而非参与执行。Observer Agent 维护全局状态视图，检测跨 Agent 的不一致性（如两个 Agent 对同一变量的矛盾记录）和系统层异常（消息队列积压、Agent 沉默超时、成本异常加速）。这是元 Harness（§14.4）在可观测性层面的具体实现。

Multi-Agent 调试的实践步骤：

从系统层异常入手：先看 Observer Agent 或系统层监控的告警（哪个 Agent 超时、哪条消息队列积压），而非直接看单个 Agent 的日志——后者在多 Agent 并发时信息量过大
回放消息序列：用消息时序快照重建问题发生时的通信拓扑，找到状态分叉的时间点和来源 Agent
隔离边界：找到分叉点后，将问题缩小到两个 Agent 之间的单次通信——此时退化为单 Agent 调试问题（§12.4 的方法完全适用）
确定性重放：用记录的因果链 ID，在隔离环境中固定消息顺序，实现确定性重放——消除消息交错的随机性后，Bug 变为可稳定复现

不确定性管理：Multi-Agent 系统的调试困难根源于消息交错的随机性，这使”复现”本身成为工程难题。两个实践策略：确定性种子（为消息调度器设置固定种子，使测试环境可重现特定交错顺序）；混沌测试（主动引入随机延迟与乱序，探测系统对交错顺序的敏感性——比等待随机失败更高效地暴露竞态条件）。

章末案例剖析

一个代码审查 Multi-Agent 系统从设计到落地的全周期工程记录——架构选型、通信协议设计、两类真实冲突场景的解决机制，以及与单 Agent 方案的精确成本对比。这个系统在第一版全并行设计中暴露了信息依赖未被建模的问题，在修复过程中发现了一个导致人工审查效率下降的”幽灵冲突”缺陷——两者都指向同一个核心教训：Multi-Agent 架构的收益不来自并行本身，而来自对任务结构的精确建模。

系统背景：一个后端开发团队，每周处理约 80 个 PR，当前代码审查流程由一名高级工程师主导，人工审查时间约为每 PR 12–15 分钟。团队决定引入 Agent 辅助审查，目标是覆盖三类审查任务：代码静态分析（复杂度、风格一致性、已知反模式）、安全审查（OWASP Top 10、依赖漏洞、密钥泄露）、测试覆盖补全（识别未覆盖代码路径并生成测试用例）。

第一轮：单 Agent 基线（第 1–2 周）

团队首先部署了一个通用代码审查 Agent，由单一 System Prompt 覆盖三类审查任务。基线评估（20 个 PR 的黄金集）：

指标	基线值
综合审查质量（LLM-as-judge，满分 100）	68/100
安全问题漏报率	34%
生成测试的有效率（能编译通过且覆盖目标路径）	61%
每 PR Agent 耗时（端到端）	4.5 分钟
每 PR API 成本	$0.28
人工审查耗时（Agent 完成后）	12.3 分钟

失败分析：单一 Agent 在三类任务间分配注意力时存在明显的系统性偏差——在同一次运行中，完成静态分析后，Agent 在上下文中携带了大量代码风格相关的分析结论，这些内容压缩了后续安全分析能使用的有效上下文窗口（§8.2 中描述的认知负荷问题）。安全分析 34% 的漏报率，有相当部分源于 Context 中遗留的静态分析信息”稀释”了安全相关信号的权重。

第二轮：架构选型——为什么选 Orchestrator-Worker

对四种 Multi-Agent 模式进行了适配性分析（§14.5 的选型框架）：

架构模式	三类任务是否适用	主要障碍
Pipeline	否	三类任务无强顺序依赖，Pipeline 无法充分并行
Debate/Review	否	没有需要多角度辩论的单一判断，是三类不同专业知识
Swarm	否	任务结构已知，无需探索；成本风险高
Orchestrator-Worker	是	任务可被清晰分解，子任务间依赖可管理

选择 Orchestrator-Worker 的核心理由：三类审查任务需要不同的专业知识和不同的上下文配置（静态分析需要语言规范文档、安全分析需要 OWASP 检查表、测试生成需要现有测试文件）——将它们放在独立 Agent 中，各自拥有精确的专用 Context，正是 §8.5 Sub-Agent 隔离原则的目标场景。

架构设计：通信协议

角色定义

OrchestratorAgent：
  职责：PR 分发、子任务调度、结果聚合、冲突检测、最终报告生成
  允许的工具：read_pr_diff、assign_task、collect_findings、write_review_report

StaticAnalysisAgent：
  职责：代码复杂度、风格一致性、已知反模式检测
  System Prompt：包含项目编码规范文档（2,400 tokens）
  允许的工具：read_file、query_complexity_metrics

SecurityReviewAgent：
  职责：OWASP Top 10、依赖漏洞、密钥泄露、权限越权检测
  System Prompt：包含 OWASP 检查表 + 内部安全策略（3,100 tokens）
  允许的工具：read_file、query_dependency_vulnerabilities、scan_secrets

TestGenAgent：
  职责：识别未覆盖代码路径，生成对应测试用例
  System Prompt：包含项目测试框架约定（1,800 tokens）
  允许的工具：read_file、read_coverage_report、write_test_file

结构化消息 Schema

Orchestrator 向 Worker 发送 WorkPacket：

{
  "task_id": "pr_review_20250318_047",
  "agent_role": "security_review",
  "pr_diff": "...",
  "context": {
    "target_files": ["src/auth/handler.py", "src/api/endpoints.py"],
    "language": "python",
    "security_policy_ref": "OWASP_2021"
  },
  "constraints": {
    "max_findings": 15,
    "min_severity": "medium",
    "output_format": "structured_json"
  }
}

Worker 向 Orchestrator 返回 FindingReport：

{
  "task_id": "pr_review_20250318_047",
  "agent_role": "security_review",
  "findings": [
    {
      "finding_id": "sec_001",
      "file": "src/auth/handler.py",
      "line_range": [89, 102],
      "category": "authentication",
      "severity": "high",
      "description": "JWT 验证未检查 exp 字段为负数的边界情况",
      "recommendation": "在 line 94 添加 if token['exp'] < 0: raise InvalidTokenError"
    }
  ],
  "metadata": {
    "files_analyzed": 2,
    "lines_analyzed": 347,
    "confidence": 0.91,
    "execution_time_sec": 38
  }
}

Schema 设计的关键决策：line_range 字段是后续冲突检测的基础——仅有”文件名”不足以检测两个 Agent 对同一代码段的矛盾判断。confidence 字段作为 Orchestrator 在冲突仲裁时的权重输入。

冲突解决机制：两个真实案例

案例一：目标层冲突

PR #047 审查期间：

StaticAnalysisAgent 发现（finding_id: sta_003）：src/auth/handler.py 第 89–102 行”函数复杂度超过阈值（Cyclomatic = 12），建议提取辅助函数以提升可读性”（严重级别：medium）
SecurityReviewAgent 发现（finding_id: sec_002）：同一函数”包含时序敏感的身份验证逻辑，任何代码重组都存在引入计时攻击（Timing Attack）的风险，建议保持当前实现不变”（严重级别：high）

Orchestrator 在聚合时识别到两条发现的 file 和 line_range 重叠，触发冲突检测逻辑：

冲突检测结果：
  sta_003 vs sec_002
  冲突类型：目标层冲突（Readability improvement vs. Security constraint）
  冲突解决规则：安全约束优先于可读性改进（OrchestratorAgent System Prompt Rule #1）
  仲裁结论：保留 sec_002，暂缓 sta_003
  输出格式：两条发现均在报告中展示，注明冲突关系和仲裁理由

最终报告中的呈现：

[SECURITY] src/auth/handler.py, Line 89-102 [HIGH]
JWT 身份验证逻辑包含时序敏感操作，任何重构存在计时攻击风险，建议保持原实现。

[DEFERRED] src/auth/handler.py, Line 89-102 [MEDIUM] [延期：与安全约束冲突]
函数复杂度超过阈值（Cyclomatic=12）。重构建议因安全约束被暂缓；
如需重构，请先获得安全团队确认。

这个处理方式的工程价值在于：审查结论不只展示”优先项”，也保留了被压制的发现——人类审查者看到了完整的决策上下文，可以在未来的安全评审后重新激活暂缓的重构建议。这是 §14.3 “目标层冲突”的解决模式在实际代码审查中的映射：显式优先级 + 约束传递，而非静默丢弃。

案例二：信息依赖引发的测试冗余

第一版全并行设计中，三个 Worker 同时启动。TestGenAgent 无法访问 StaticAnalysisAgent 的覆盖率分析结果（后者尚未完成），只能基于代码 diff 估计哪些路径需要测试。

实测结果（前 15 个 PR）：

TestGenAgent 生成的测试中，28% 针对的是已有测试覆盖的代码路径（StaticAnalysisAgent 事后标记为”已覆盖”）
这些重复测试通过了格式验证，进入了最终报告，导致人工审查时需要过滤冗余内容
有效测试生成率从基线的 61% 下降到 54%（全并行版本比单 Agent 还差）

根因：TestGenAgent 的任务（“为未覆盖路径生成测试”）需要 StaticAnalysisAgent 的输出作为输入——这是一个信息依赖，而非纯并行关系。全并行设计隐含地假设三个任务是信息独立的，但实际上它们不是。这是 §14.1 的判断标准在实践中的具体验证：子任务的输出能否被简洁地结构化表达——可以；但 Agent B 是否需要 Agent A 的输出才能工作——TestGenAgent 在没有覆盖率报告时需要猜测，是的。

修复：半并行架构

阶段一（并行）：StaticAnalysisAgent + SecurityReviewAgent 同时运行
              ↓（等待阶段一完成，平均 41 秒）
阶段二（顺序）：TestGenAgent 读取 StaticAnalysisAgent 的覆盖率报告，
              定向生成针对未覆盖路径的测试

半并行设计使总耗时增加了 StaticAnalysis 的执行时间（约 41 秒），但消除了 28% 的测试冗余，有效测试生成率从 54% 回升至 79%。

“幽灵冲突”缺陷与可观测性修复

故障描述

系统上线后第 3 周，人工审查工程师反馈”最终审查报告有时会出现两条关于同一行的发现，逻辑上互不矛盾却没有被标记为’重复’——需要人工判断是否算同一个问题”。

典型样本（PR #063，src/api/endpoints.py 第 67 行）：

发现 A（来自 StaticAnalysisAgent）：
  Category: code_style
  "变量命名不符合规范：应使用 snake_case"

发现 B（来自 SecurityReviewAgent）：
  Category: security
  "同一变量在字符串格式化中可能存在注入风险"

两条发现位于同一行，但 Orchestrator 的冲突检测逻辑判断”Category 不同，非冲突”，将两者原样输出——人工审查者需要判断是应该重命名变量（解决 A）、修复注入风险（解决 B），还是同时做两件事。这不是逻辑冲突，而是功能上的重叠告警，在报告中制造了额外的认知负担。

可观测性追踪

问题出现时，通过 §14.6 描述的消息序列快照回放了 PR #063 的处理时序：

Task trace_pr063 [两个 Agent 并行运行，消息时序]

T+0.0s  Orchestrator → StaticAnalysisAgent: WorkPacket (endpoints.py)
T+0.0s  Orchestrator → SecurityReviewAgent: WorkPacket (endpoints.py)
T+38.4s StaticAnalysisAgent → Orchestrator: FindingReport
         └── findings: [sta_007: line 67, category=code_style]
T+41.2s SecurityReviewAgent → Orchestrator: FindingReport
         └── findings: [sec_012: line 67, category=security]
T+41.3s Orchestrator: 冲突检测
         └── sta_007 vs sec_012: file 一致, line_range 重叠 → 检查 category
         └── category 不同 → 判定为非冲突，原样保留两条
T+41.5s Orchestrator → write_review_report: 输出两条独立发现

追踪清晰地暴露了冲突检测逻辑的边界：它只识别语义冲突（两者互相矛盾），不识别信息重叠（两者指向同一行的不同侧面）。

修复

在 Orchestrator 的聚合逻辑中增加”行级重叠告警”标记：

冲突检测规则更新：
  规则一（原有）：同 file + 重叠 line_range + 同 category → 标记为冲突，触发仲裁
  规则二（新增）：同 file + 重叠 line_range + 不同 category → 标记为 [同行多发现]，
                 在报告中聚合展示，附注"此行有多个 Agent 的发现，建议同时处理"

修复效果：人工审查耗时从修复前（上线 3 周均值）的 9.4 分钟降回 7.2 分钟。

单 Agent vs. Multi-Agent 完整对比

指标	单 Agent 基线	Multi-Agent v1（全并行）	Multi-Agent v2（半并行）
综合审查质量	68/100	79/100	83/100
安全问题漏报率	34%	9%	6%
有效测试生成率	61%	54%（↓7pp，测试冗余）	79%（↑18pp）
API 成本/PR	$0.28	$0.44（↑57%）	$0.39（↑39%）
审查耗时（Agent 端到端）	4.5 分钟	2.1 分钟（并行收益）	2.8 分钟（半并行）
人工审查耗时/PR	12.3 分钟	—	7.2 分钟（↓41%）

成本结构重新核算：

若人工审查工程师时间成本为 ¥250/小时，每 PR 人工审查耗时减少 5.1 分钟：

成本项	单 Agent	Multi-Agent v2	差值
API 成本/PR	¥2.0（≈$0.28）	¥2.8（≈$0.39）	+¥0.8
人工审查成本/PR	¥51.3（12.3 min）	¥30.0（7.2 min）	−¥21.3
合计/PR	¥53.3	¥32.8	−¥20.5（↓38%）

API 成本增加 ¥0.8，换取人工注意力节省 ¥21.3——杠杆率约 26:1。这与 §9.4 中 Plan 审查的监督杠杆率分析属于同一类型的经济核算：Agent 能力的成本（API 费用）与其所释放的人类注意力成本（高昂得多）相比，通常处于不同数量级。

各设计决策的理论对应

决策	理论依据
选择 Orchestrator-Worker 而非 Swarm	§14.5：任务结构已知时，协调复杂性从 NEXP 压缩到接近多项式；Swarm 是过度设计
结构化 Schema 而非自然语言通信	§14.2：结构化消息消除歧义，支持 Orchestrator 的程序化冲突检测
全并行改为半并行	§14.1：信息依赖未被建模时，并行反而引入冗余；“子任务结果可被简洁结构化表达”≠“子任务信息独立”
目标层冲突保留被压制的发现	§14.3 目标层冲突解决模式：显式优先级 + 约束传递，不静默丢弃
消息序列快照定位幽灵冲突	§14.6 消息序列快照：跨 Agent 的行为问题无法从单 Agent 日志中定位

本案例的核心工程结论：Multi-Agent 系统的质量提升来自专业化，而非来自并行本身。第一版全并行设计的有效测试生成率反而低于单 Agent 基线，印证了 §14.1 的判断标准——如果 Agent B 需要 Agent A 的输出才能工作，分解正确而执行策略（并行化）错误，成本照付，收益反退。精确建模任务间的信息依赖关系，是 Multi-Agent 架构设计中被最容易忽视、代价却最直接的工程决策。“幽灵冲突”缺陷则揭示了可观测性在 Multi-Agent 系统中的额外价值：问题不在任何单个 Agent 内部，而在 Orchestrator 聚合逻辑中——没有跨 Agent 的消息序列追踪，这类问题只能通过人工审查工程师的主观感受间接发现，而无法被精确定位。

从技术可靠性到人机可信赖性

第十二章、第十三章和第十四章在三个递进的层次回答了工程问题：系统是否正常工作？经验如何在组织中积累演化？系统如何在更大规模下协调？ 这三章以”系统”为分析对象——评估指标、Skill 知识积累、多 Agent 协调协议，都是在工程层面让系统更可靠、更具持续改进能力。但有一个问题是这三章无法回答的：可靠地为谁工作？由谁来定义”正常”和”更好”？

当评估体系无法发现价值漂移时，当 Skill 积累的方向本身开始偏离人类真实意图时，当 Multi-Agent 系统产生人类未曾预见的涌现行为时，技术层的工具已到达边界。第十五章在此接手——不是作为技术系统工程的延伸，而是将视角从”系统是否可靠”切换到”系统是否可信赖”：一个根本不同的问题，需要根本不同的设计语言。

第十四章 Multi-Agent 架构：协调与代价

第十四章　Multi-Agent 架构：协调与代价