Multi-Agent Coordination 与组织设计：从并行幻觉到可验证协作

研究基线：2026-08-03；线上 freshness/reliability 复核完成于同日。本文对应总纲 Part 10，目标不是介绍几个“角色扮演框架”，而是建立一套能判断、设计、验证和审计多 Agent 系统的完整理论。默认场景是 Coding Agent，但结论适用于长任务 Agent、研究 Agent 与跨组织 Agent。

为防止把新论文中的单点结果讲成行业定律，本文对关键证据使用四级标记：

• E1｜规范或实现事实：官方 specification、release、文档或指定 commit 的代码；只能证明接口/行为，不证明效果更好；
• E2｜受控原始实证：原始论文在多模型、多任务或带统计检验的受控实验；仍未等于跨团队独立复现；
• E3｜窄域原始实证：单 benchmark、小样本、弱 baseline 或首版 preprint；只用于形成待验证假设；
• E4｜工程推论：由分布式系统原理、公开接口或上述结果推导出的设计判断；必须在目标产品和任务分布上验证。

数学恒等式和 work/span、Amdahl 一类模型属于理论工具，既不是经验常数，也不使用 E1–E4 充当“实测证据”。

0. 先给出结论

Multi-agent 不是把同一个 prompt 发给更多模型，也不是产品成熟度的标志。它是一次组织设计决策：把一个任务的认知状态、工具、权限、artifact ownership 与验证责任分布给多个自治执行单元，再为它们补上协调机制。

它成立的必要条件不是“任务很大”，而是以下收益至少有一项真实存在：

• 可分离工作能够缩短 critical path；
• context 隔离能避免无关轨迹污染主 Agent；
• 专业模型、工具或权限的异质性有可测价值；
• 独立求解能产生低相关性的候选或反证；
• generator、executor、verifier 的权责分离能控制错误或风险。

它失败的根因通常也不是 prompt 不够精致，而是：

• 任务其实是强顺序推理；
• 多个 Agent 竞争同一共享可变状态；
• decomposition 切断了必要上下文；
• handoff 只有结论，没有 provenance 与 acceptance evidence；
• 多数投票把相关错误误当成独立证据；
• orchestrator 既是瓶颈，又没有能力验证 worker；
• agent 数量增长快于 verification capacity；
• 系统没有 ownership、取消、一致性、重试和终止语义。

最稳健的默认策略是：

单 Agent 起步；把并行度建立在 task DAG、独立 artifact 和可执行 verifier 上；对共享写入使用单一 owner；对不可信产物集中验收；只有 ablation 证明收益后才扩大 Agent 数量。

1. 精确定义：什么才算 Multi-agent

1.1 四个容易混淆的对象

这里把 Agent 实例定义为：

Agent_i = (policy_i, context_i, local_state_i, capabilities_i,
           authority_i, budget_i, lifecycle_i)

如果多个“角色”只是向同一个上下文串行追加不同 system prompt，它们不一定构成真正的多 Agent 系统；如果多个 worker 有独立 context、权限、生命周期和可恢复状态，即便使用同一个基础模型，也可以构成多 Agent 系统。

1.2 Role、Profile、Instance、Principal 不要混

• Role：planner、coder、reviewer 等行为责任；它是组织语义，不是安全身份。
• Profile：模型、prompt、tool allowlist、budget 等配置模板。
• Instance：某次运行中有稳定 ID、context、状态与生命周期的实体。
• Principal：承担最终法律、权限或业务责任的人/组织/服务主体。

同一个 profile 可以生成多个 instance；不同 role 可以由同一模型承担；同一个 principal 可以委派多个 Agent。跨 principal 协作比同一产品内部的 subagent 更难，因为 trust、政策、身份和争议仲裁都不能再默认共享。

1.3 协调的五个问题

任何多 Agent 架构都必须回答：

1. 谁决定做什么：decomposition 与 allocation；
2. 谁能读写什么：ownership、authority 与 isolation；
3. Agent 之间传递什么：message、artifact、evidence 与 receipt；
4. 如何把局部结果变成全局结果：merge、judge 与 verifier；
5. 何时结束或失败：consistency、cancellation 与 termination。

缺少其中任何一项，多 Agent 都只是分布式 improvisation。

2. 什么时候单 Agent 不够

2.1 不够的不是“智力”，而可能是五种资源

时间并行度不足

任务由多个弱依赖分支组成，单 Agent 会把本可并行的 I/O、检索、测试或实现串行化。例如：同时调查五个互不依赖的 repository subsystem；对多个独立候选方案运行 benchmark；多个 package 在稳定 interface contract 下并行实现。

Context 带宽不足

探索过程会产生大量低价值中间轨迹。把独立调查放进隔离 context，只把带证据的 handoff 返回主 Agent，可以保护主上下文的 signal density。这里的收益是信息架构，不是额外智能。

Capability 或工具异质性不足

不同子任务可能需要不同模型、语言、运行环境、数据源或工具。一个低成本模型做广度检索，一个强模型做架构综合，一个具备 browser 的 Agent 查文档，一个只有 read 权限的 Agent 做安全 review，可能优于一个全能但昂贵且过度授权的 Agent。

权限隔离不足

高风险任务应把 research、planning、write、deploy、approval 分开。不是因为角色名能保证安全，而是不同 Agent 实例可以获得不同 capability set 和 delegation scope，使 least privilege 成为 runtime 强制边界。

独立验证不足

生成者通常对自己的假设、上下文遗漏和实现选择存在相关偏差。独立 evaluator 若能访问 ground truth、tests、spec 或不同证据通道，可以提供有价值的反证。

2.2 五种高价值任务形态

2.3 “任务很复杂”不是充分条件

复杂任务可能仍然是不可分割的强顺序任务。判断标准不是文本长度、文件数量或人类觉得难，而是能否形成：

independent work package
  + explicit input snapshot
  + exclusive or versioned ownership
  + independently checkable output

如果不能，增加 Agent 只会把一个复杂认知过程切成多个有损 handoff。

3. 什么时候 Multi-agent 反而更差

3.1 强顺序任务：推理状态被切碎

若后一步高度依赖前一步的完整隐含状态，handoff 必须复制几乎全部 context，既没有并行收益，又增加摘要损失。典型例子是单一路径调试、需要持续修正假设的规划、精细证明和强耦合代码迁移。

3.2 高共享状态：并发把局部正确变成全局错误

多个 Agent 同时修改相同文件、schema、依赖版本、锁文件或部署环境时，即使每个 patch 单独正确，组合后也可能错误。文本 merge 无冲突不代表 symbol、invariant、migration order 或 runtime behavior 无冲突。

3.3 同质 Agent：增加的是相关样本，不是独立证据

相同模型、相同 prompt、相同 retrieval corpus、相同工具和相同错误先验会产生高相关错误。三票一致可能只是在重复同一盲点。Agent 数量不是 diversity。

3.4 Tool-heavy 任务：协调抢占认知与执行预算

Agent 必须决定由谁调用哪个工具、同步结果、处理外部环境竞争和重复 effect。工具越多、side effect 越强，协调税往往越高。Google 论文 v3（2026-04-08） 在 260 个配置、6 个 agentic benchmark、5 种架构和 3 个 LLM 家族上发现：其 sequential-planning 任务中的所有 MAS 变体相对单 Agent 下降 39%–70%，模型回归中的 tool-coordination 系数为 β=-0.096, p=.002。这是 E2：足以反驳“更多 Agent 普遍更强”，但不能证明所有 tool-heavy 生产任务都会退化；Google 的早期官方解读对应旧版实验规模，数字以论文 v3 为准。

3.5 Capability saturation：强单 Agent 挤压协调收益

上述论文 v3 报告：在其测试配置中，single-agent accuracy 高于约 45% 后，协调收益平均转负（能力系数 β=-0.236, p=.004）。这是 E2 的 benchmark/configuration-dependent 分界现象，不是模型能力的行业阈值；正确抽象是存在一个随任务、模型、budget、harness 和 verifier 变化的 break-even point。单 Agent 已能稳定完成大部分工作时，多 Agent 的边际质量收益可能不足以覆盖额外 communication、merge、judge 和错误面。

3.6 Verification bottleneck：生产速度超过验收能力

若 N 个 worker 并行产生 artifact，而唯一 orchestrator 逐个读 summary、跑 tests、解冲突，则系统吞吐最终由 verifier 决定。更多 worker 会增加 queueing、过期结果和认知切换，反而拉长 makespan。

3.7 过度 decomposition：边界成本高于内部复杂度

一个 10 分钟任务拆成 5 个两分钟子任务，不意味着能两分钟结束；spawn、打包 context、读取结果、解释差异、合并和重验可能超过原始工作。深模块原则同样适用于 Agent 组织：子任务接口应窄而稳定，内部工作足够深，才值得成为独立 delegation boundary。

4. Task DAG：多 Agent 设计的事实源

4.1 从角色表切换到依赖图

角色表只告诉你“谁像什么人”，task DAG 才告诉你“什么能并行”。定义：

G = (V, E)

V_i = (objective, input_snapshot, owner, capability,
       artifact_schema, verifier, budget, state)

E_ij = task_j requires an accepted output from task_i

只有 zero in-degree 或前驱已 accepted 的节点才可运行。一个“Architect”可能连续执行多个节点；同一节点也可分配给不同候选 Agent。组织结构不应先于工作结构。

4.2 Decomposition 的八个轴

成熟设计经常组合多个轴：先按稳定模块做 write ownership，再按 security/performance concern 做只读 review；不要让多个 concern reviewer 同时改相同文件。

4.3 好子任务的五个性质

• Self-contained：输入 snapshot 足以开始，不依赖父 Agent 未说出的历史；
• Deep：内部工作量显著大于接口成本；
• Exclusive：write set 唯一，或有明确版本/合并协议；
• Verifiable：输出能由 tests、schema、source evidence 或 formal invariant 判断；
• Abortable：失败、过时或 budget exhausted 时可停止，不拖死全局。

4.4 反模式：按人格分解

“产品经理 Agent → 架构师 Agent → 工程师 Agent → 批评家 Agent”只有在每个边界都有真实 artifact、authority 和 verifier 时才有意义。仅靠角色 prompt 模拟组织，会制造：

• 相同模型伪装出的虚假多样性；
• 无法度量的主观 handoff；
• 每层重复复述问题；
• 上游错误通过权威角色名被放大；
• 责任归属模糊。

5. 五类核心 Topology

5.1 Centralized：hub-and-spoke

Orchestrator 拥有 task DAG、allocation、全局 budget 和 finalization；worker 只拥有局部任务。优势是 error containment、统一 policy、容易取消和审计；风险是中心 context 膨胀、调度瓶颈、单点偏差与 verifier queue。

适合 Coding Agent 的默认结构：可分解任务、多个隔离 worktree、统一 integration 和全局 test gate。

5.2 Decentralized：peer-to-peer

Agent 直接交换消息、协商任务与共识，没有唯一中心。它适合动态环境、局部信息分布、中心不可用或多个独立 principal 的场景；代价是 routing、重复工作、权限组合、身份、冲突、一致性和 termination 都更难。

去中心化不是“把所有 Agent 放进群聊”。必须定义：peer discovery、message admissibility、causal order、conflict object、quorum、成员变更与 Byzantine assumptions。

5.3 Hierarchical：树或多级 DAG

高层 manager 把任务分给中层 orchestrator，再由它们管理 worker。优势是降低单一 orchestrator fan-out，并使 domain ownership 与组织边界一致；风险是 summary 逐层压缩、延迟叠加、authority 过度委派，以及错误被上级“批准”后加速传播。

层级深度必须有硬上限。每增加一层，都应证明它减少了真实 coordination complexity，而不是把同一 handoff 再包装一次。

5.4 Market：基于能力、成本与效用的分配

任务发布者给出 objective、budget、deadline 和 acceptance；Agent 基于 capability、预计成功率、成本与 availability 出价，调度器选择组合。适合 heterogeneous agents、供应商生态和资源稀缺调度。

核心问题是 mechanism design：Agent 的自报能力和置信度未必校准，低价可能对应低成功率，供应商可能 gaming benchmark。正确选择应基于历史可验证表现与风险，而不是自然语言自荐：

score(agent_i, task_j)
  = calibrated_success_probability
  - lambda_cost * expected_cost
  - lambda_latency * expected_latency
  - lambda_risk * authority_risk

5.5 Blackboard：共享事实面，不是共享聊天记录

所有 Agent 围绕一个结构化 blackboard 读取任务状态、声明 intent、发布版本化 artifact 和 evidence；scheduler 或 opportunistic policy 根据新状态激活 Agent。

Blackboard 的价值是把知识与 Agent 生命周期解耦。它应包含 typed objects、version、owner、provenance、status 和 subscription，而不是把所有自由文本消息放在一个公共 context。共享 blackboard 仍需 single-writer、MVCC 或 conflict protocol，否则只是高并发污染源。

5.6 结构对比

现实系统多是 hybrid。关键不是给 topology 起名，而是明确每种语义由谁拥有。

6. 数学成本模型：并行收益不是 Agent 数量

6.1 Work–Span 下界

设 task DAG 总工作量为：

W = sum_i w_i

critical path 长度为：

L = max_path sum_{i in path} w_i

使用 N 个同速 worker 时，即使协调免费：

T_N >= max(W / N, L)

平均可用并行度上限是 W / L。若 W ≈ L，任务几乎完全串行；增加 Agent 不可能突破 critical path。

6.2 带协调税的 Amdahl 模型

设单 Agent 耗时为 T_1，可并行比例为 P：

T_N = T_1 * ((1 - P) + P / N)
      + C_spawn(N)
      + C_pack(N)
      + C_comm(N)
      + C_wait(N)
      + C_merge(N)
      + C_verify(N)
      + C_conflict(N)
      + C_rework(N)

Speedup S_N = T_1 / T_N
Efficiency E_N = S_N / N

经典 Amdahl 只描述不可并行比例；Agent 系统还多出随 N 增长的非零协调项。若 communication 是 all-to-all，C_comm 可能接近 O(N²)；若只有中心收发则消息边数接近 O(N)，但中心 queueing 可能成为非线性瓶颈。

6.3 Token 与货币成本

C_total = C_task
        + C_context_replication
        + C_coordination_messages
        + C_redundant_exploration
        + C_merge_and_judge
        + C_failed_or_stale_work

多 Agent 的 context isolation 能降低主 Agent context，但不会让 token 消失；它把 token 分散到多个独立窗口。评估必须报告全系统 token，而不是只看 orchestrator transcript。

6.4 质量—时间—成本—风险统一效用

给定 topology pi、Agent 数 N 与 allocation a：

U(N, pi, a)
  = E[Quality]
  - lambda_t * E[WallTime]
  - lambda_c * E[Cost]
  - lambda_r * E[RiskLoss]

增加 Agent 的 break-even 条件可以写成：

DeltaQuality + lambda_t * TimeSaved
  > lambda_c * ExtraCost + lambda_r * ExtraRisk

这比“成功率提升几个点”更接近产品决策：高风险写入任务的一点 success gain 可能不抵 authority surface 扩大；只读调研中 latency gain 则可能很值钱。

6.5 排队论视角：verifier 是服务台

若 worker 到达 artifact 的速率为 lambda，verifier 验收速率为 mu，当 lambda >= mu 时，验收队列不稳定增长。即使 lambda < mu，接近饱和时等待时间也会急剧上升。

解决办法不是盲目复制 judge，而是：

• 前移 schema validation 和局部 tests；
• 让 worker 附带 machine-checkable evidence；
• 分层 verifier，但保留关键全局 gate；
• 根据 verifier capacity 做 backpressure；
• 不允许过期分支继续无界生成。

7. 可靠性、相关错误与 Capability Saturation

7.1 多数投票只在错误足够独立时有效

若 N 个 Agent 的错误概率均为 p < 0.5 且彼此独立，奇数 N 的多数错误概率为：

P_majority_error
  = sum_{k=(N+1)/2..N} C(N,k) * p^k * (1-p)^(N-k)

但 LLM Agent 很少独立。用 pairwise error correlation rho 做粗略诊断，可使用有效样本量：

N_eff ≈ N / (1 + (N - 1) * rho)

当 rho -> 1 时，N_eff -> 1：十个同质 Agent 仍近似一个证据源。这个公式是相关采样的诊断近似，不是对 LLM majority accuracy 的严格保证。

7.2 Correlation 从哪里来

• 相同基础模型与 post-training；
• 相同 system prompt 与 few-shot；
• 相同 context ordering 与 retrieval source；
• 相同 harness bug 或 tool failure；
• Agent 看到彼此答案后的 anchoring；
• 共享错误 memory 或 blackboard 条目；
• 相同 judge 偏好和 benchmark contamination。

因此 diversity 必须在 causal source 上制造，而不是只改角色名。可用手段包括：不同证据子空间、不同 tool chain、不同模型家族、先独立作答再互审、隐藏其他候选、针对 minority evidence 的 verifier。

7.3 两个可操作的错误指标

Error Propagation Rate
  = downstream accepted artifacts influenced by a bad artifact
    / all downstream artifacts reachable from it

Error Amplification Ratio
  = P(final outcome bad | an upstream artifact bad)
    / P(final outcome bad | upstream artifact good)

必须通过 trace provenance 识别“influenced by”，否则只统计最终对错无法定位 topology 是否在放大错误。

Google 论文 v3 在其 trace-level 定义下报告 independent 架构错误放大 17.2×、centralized 架构 4.4×。这是 E2 的论文内测量，不是“中心化一定降低 4 倍错误”的通用倍率；它支持的较弱判断是：中心 orchestrator 可能通过验证关口限制错误扩散。工程上仍应在自己的 trace taxonomy 中复现 propagation metric。

7.4 Capability saturation 的机制

随着单 Agent 能力提高：

• 独立候选带来的新信息减少；
• worker 之间答案更趋同，error correlation 上升；
• orchestrator 已能独立解决任务，delegation 变成重复推理；
• verifier 若不强于 generator，无法兑现额外候选价值；
• 固定 compute 被通信和 aggregation 稀释。

所以“更强模型是否还需要 multi-agent”的正确答案是：需要的边界从补智力，转向缩 critical path、隔离 context/authority、扩大证据覆盖和建立独立验证。

8. Specialization 与任务分配

8.1 专业化必须对应可观测能力差异

有效 specialization 可以来自：

• 模型：代码、视觉、长 context、低延迟；
• 工具：browser、LSP、database、sandbox；
• 权限：read-only、write、deploy、billing；
• memory：对特定 repository/domain 的已验证经验；
• 位置：接近数据或运行环境；
• policy：安全 reviewer、performance profiler、migration expert。

“你是世界顶级架构师”不是 specialization，除非它改变了可验证成功率或行为边界。

8.2 Capability matrix

对 task j 和 Agent i，维护经历史轨迹校准的：

p_ij = P(task_j accepted | agent_i, harness, budget)
t_ij = expected latency
c_ij = expected cost
r_ij = expected risk loss

Allocation 目标不是把每个任务给“最强模型”，而是优化全局 DAG：

maximize sum_j value_j * p_{a(j),j}
         - lambda_t * makespan
         - lambda_c * total_cost
         - lambda_r * total_risk

subject to capability, authority, concurrency,
           dependency and budget constraints

8.3 Exploration–exploitation

永远只路由给历史最强 Agent 会失去对能力漂移和新 profile 的认识；平均轮转又会浪费成本。可以对低风险任务保留小比例 exploration，用在线 calibration 更新 p_ij，但 consequential action 应以保守下界而非自报置信度路由。

8.4 Specialist handoff 的危险

专业语言、局部 objective 和局部 verifier 会让 specialist 忽略全局 invariants。每个 specialist artifact 必须同时包含：

• 局部结论；
• 与公共 contract 的关系；
• 假设与未检查区域；
• 可能影响的其他 owner；
• 可重放 evidence；
• confidence 的来源，而不是一个裸分数。

9. Coordination Contract：委派不是一句自然语言

9.1 最小 contract

task_id: stable-id
objective: one measurable outcome
scope:
  read: [allowed roots/resources]
  write: [exclusive artifacts]
  forbidden: [explicit non-goals/effects]
input_snapshot:
  base_revision: immutable revision
  artifacts: [content-addressed references]
dependencies: [accepted predecessor task ids]
authority:
  principal: principal id
  delegated_capabilities: [narrow capabilities]
  expires_at: timestamp
budget:
  tokens: number
  wall_time: duration
  tool_calls: number
deliverable:
  schema_version: version
  required_artifacts: [typed outputs]
acceptance:
  verifier: executable or reviewer id
  criteria: [machine-checkable invariants]
handoff:
  required_evidence: [commands, sources, hashes, receipts]
  uncertainty_fields: [known gaps, assumptions]

自然语言可以描述 objective，但 scope、artifact、authority、version、budget 和 acceptance 不应只靠语义猜测。

9.2 Ownership 的四个层次

• Task owner：对子任务完成负责；
• Artifact owner：拥有特定文件、schema、report 或 branch 的写权；
• Decision owner：对冲突选择和风险接受负责；
• Effect owner：有权触发外部可观测副作用。

它们可以是不同实体。一个 worker 可以生成部署计划，但没有 deploy effect authority；reviewer 可以拒收 artifact，但不能偷偷改写它。

9.3 Handoff 是压缩，也是潜在损失点

完整轨迹通常太长，裸结论又不可验证。高质量 handoff 应分四层：

1. Decision：结论与建议；
2. Evidence：支持/反对的来源、tests、trace、artifact hash；
3. State：完成了什么、剩余什么、当前版本；
4. Uncertainty：假设、覆盖缺口、失败尝试和风险。

handoff 质量可以评估：

Coverage = required fields/evidence delivered / required total
Faithfulness = claims supported by referenced evidence / claims sampled
Freshness = artifacts still based on current accepted revision / delivered artifacts
Reuse rate = handoffs accepted without parent redoing the same work / total handoffs

9.4 Parent 必须能拒收

“子 Agent 已完成”只是 lifecycle 事件，不是业务 acceptance。parent/orchestrator 必须可：accept、reject、request_revision、accept_partial、cancel_as_stale。没有 rejection path，delegation 就变成信任传递。

10. 共享状态、消息与权限

10.1 Context isolation 不等于 state isolation

独立上下文防止 transcript 污染，但多个 Agent 仍可能共享 filesystem、Git index、database、ports、rate limits、credentials 和 deployment target。真正的并行安全需要同时描述：

read set + write set + external effects + resource locks

10.2 状态按一致性需求分层

不要对所有状态追求强一致，也不要把“最终一致”用作共享写冲突的借口。

10.3 Message envelope

Agent 间消息至少应包含：

message_id, task_id, sender_instance_id, principal_id,
schema_version, causal_parent_ids, created_at, deadline,
artifact_refs, provenance, authority_scope,
idempotency_key, confidentiality_label

自由文本 body 是 payload，不是协议。控制消息、evidence、artifact reference 和 effect receipt 应使用不同 type，避免一句“已处理”同时被当成进度、事实和授权。

10.4 Lease 与 fencing

长任务 worker 可能失联，orchestrator 需要 lease expiry 后重派。但旧 worker 可能稍后恢复并继续写。每次 ownership epoch 发放单调递增 fencing token；存储或 effect executor 只接受当前 epoch，才能阻止 stale worker。

10.5 权限委派必须衰减

Authority(child)
  subset_of Authority(parent)
  intersection TaskScope
  intersection TimeAndBudgetBound

child 不应凭任务文本获得 parent 的全部 credential。nested delegation 必须继续衰减，并记录 delegation chain。权限继承可以减少 approval friction，但扩大了 blast radius；对“always allow”尤其要审计传播范围。

11. Handoff、Merge 与全局正确性

11.1 Merge 不是文本拼接

Coding Agent 的 merge 至少有五层冲突：

1. textual conflict：同一行修改；
2. structural conflict：symbol、API、schema 不一致；
3. semantic conflict：各自 tests 通过，组合行为错误；
4. temporal conflict：基于不同 base revision；
5. policy conflict：一个 patch 扩权、降级安全或改变 product contract。

11.2 Branch-and-merge 参考流程

关键不变量：

• 所有 worker 从声明的 immutable base 开始；
• write ownership 在调度前分配；
• dependency owner 先落稳定 interface；
• 每个分支带本地 verifier evidence；
• merge 后重跑全局 verifier，不能复用“各自通过”；
• conflict resolution 本身是新变更，必须再验证；
• stale branch 可以拒收，不要求沉没成本驱动合并。

CAID 论文 v2（2026-07-08）把 centralized delegation、asynchronous execution、isolated workspace 与 executable verification 组合。其最大模型内增益是 PaperBench +25.6 个绝对百分点、Commit0 +14.7 点；其他模型的增益明显更小，Commit0 上 GLM 的 +3.6 点在论文所用检验下 p=.095。CAID 的 API 成本始终高于单 Agent，wall-clock 也未显著缩短；而且 SAS 最多 100 次迭代，CAID 使用 manager 50 次加每个 engineer 80 次、最多两轮，并非等总 compute。它是 E2：支持“isolated branch、中心集成和 test gate 在这些 SWE 设置中有效”，不支持“异步多 Agent 普遍提质、降时或更省成本”。

11.3 Contract-first implementation

对于 repository-level generation，先确定 public interface、dependency constraint 和 file ownership，再并行实现，通常比让多个 developer 自由协商更可控。2026 年 CodeTeam 使用多 Architect 候选、CTO 选择并规范成 machine-checkable contract、dependency-aware scheduler、Git coordination 与 QA repair；其 NL2Repo-Bench 报告 34.6% PE、42.3% SFT test pass rate。结果仍局限于论文任务，但清晰体现了 contract 是并行实现的前置条件。参考 CodeTeam。

12. Judge、Debate 与 Verification

12.1 四种聚合不要混

优先级通常是：可执行 verifier > 基于证据的局部审计 > 校准 judge > majority vote。不是因为 LLM judge 无用，而是越靠近外部可复现事实，验证越不依赖同一模型偏差。

12.2 独立 evaluator 的条件

Evaluator 至少要在一个关键维度独立：

• 不看 generator 自报 confidence；
• 先看 artifact/spec，再看其解释；
• 使用不同 prompt/model/tool/evidence source；
• 对候选身份和顺序做 blind/randomization；
• 能运行 tests 或查询 authoritative source；
• 记录 reject reason 并用 gold cases 校准。

如果 evaluator 只是让同一 Agent 再问一次“检查你自己”，那是 refinement，不是独立验证。

12.3 Debate 什么时候值得

Debate 适合：存在少数关键分歧、双方可提供可核查证据、judge 能定位 divergence、答案空间不适合简单 executable test。它不适合：事实可直接查询、候选高度同质、交流会导致 anchoring、或 budget 更适合花在工具验证上。

2025 年受控逻辑推理研究发现，intrinsic reasoning strength 与 group diversity 是 debate 成功的主要驱动，order 与 confidence visibility 等结构因素增益有限；majority pressure 会抑制独立纠错。参考 Can LLM Agents Really Debate?。

2026 年 AgentAuditor 把多 Agent reasoning trace 建成分歧树，在关键 divergence 上做局部审计；论文报告相对多数投票最高提升 5 个准确率百分点、相对 LLM-as-a-Judge 最高提升 3 点。这提示正确抽象是“验证证据分叉”，而不是“数人头”。参考 AgentAuditor。

12.4 Stop rule

Debate 必须有停止条件：

• 达到 evidence-complete rubric；
• 新一轮没有新增可核查证据；
• disagreement 已定位为不可判定 assumption；
• executable verifier 已裁决；
• round/token/deadline budget 到达；
• judge confidence 达到经校准阈值，且不处于高风险类别。

无界 debate 容易把表达能力优化成说服能力，而非正确性。

13. Adversarial 与 Byzantine Coordination

13.1 Byzantine 不只是“模型偶尔出错”

• Benign fault：timeout、crash、stale context、格式错误、能力不足；
• Rational fault：为了局部 reward、成本或 KPI 隐瞒问题；
• Adversarial fault：主动误导、注入、窃取、升级权限；
• Byzantine fault：可任意且对不同 peer 表现不一致，包括串谋。

LLM Agent 的额外风险是自然语言消息本身既承载数据又能影响 policy。另一个 Agent 返回的“证据摘要”也可能是 prompt injection channel。

13.2 主要攻击面

• Sybil：一个攻击者伪造多个 Agent 获得多数；
• collusion：worker 与 judge 共享偏差或串谋；
• message injection：在 artifact、comment、tool output 中嵌入指令；
• capability laundering：通过高权限 peer 代执行被禁止 effect；
• provenance forgery：伪造 tests、source 或 receipt；
• stale replay：重放旧的许可、结果或 ownership epoch；
• selective withholding：隐藏反例，使 consensus 假收敛；
• topology poisoning：操纵 peer discovery、routing 或 reputation。

13.3 防御原则

identity before voting
provenance before belief
capability before effect
independent evidence before consensus
fencing before shared write

具体机制：认证 instance 与 principal、抗 Sybil membership、消息签名/哈希、artifact provenance、capability attenuation、quorum 的 fault assumption、outlier/minority evidence 保留、独立 verifier、不可变 receipt、communication graph 监控与隔离。

13.4 不要误用经典 Byzantine 阈值

在部分同步、经过认证、确定性 state-machine replication 等特定假设下，经典 BFT 常要求 N >= 3f + 1 才能容忍 f 个 Byzantine 节点。这个结论不能直接证明 LLM 多数答案为真：semantic correctness 没有自动形成可复制的确定性状态机，Agent 身份可能不可控，judge 也可能被说服或污染。

2026 年 Self-Anchored Consensus 研究对去中心化 LLM-MAS 给出 (F+1)-robustness 通信图条件，并通过 local filtering/refinement 抑制 Byzantine influence；证据来自数学和常识推理 benchmark，应视为特定协议的研究结果，而不是通用安全保证。参考 Robust Multi-Agent LLMs under Byzantine Faults。

另一个 2026 年 4-player Stag Hunt 研究发现，诚实 Agent 即便一轮内识别背叛，也可能无法集体恢复；显式告知受限 topology 甚至会在没有攻击者时破坏合作。它揭示 communication channel 和 topology meta-reasoning 都是安全面。参考 Byzantine Cheap Talk。

13.5 多 principal 协作

跨组织 Coding Agent 同时编辑共享 repository 时，单一 principal 假设失效。2026 年 MPAC 提出 Session、Intent、Operation、Conflict、Governance 五层，使用 intent declaration、结构化 conflict、Lamport causal watermark、optimistic concurrency control 和 HITL arbitration；其三 Agent code-review benchmark 相对串行、人工中介 baseline报告 95% coordination-overhead reduction 和 4.8× wall-clock speedup。该结果是 E3：没有与 A2A、中心 orchestrator 或其他自动协调协议正面对照，不能据此声称 MPAC 更优。MPAC 目前是 preprint/reference implementation，不是行业标准；其主要价值是把跨 principal 的 intent、conflict、causality 与 governance 提升为一等协议对象。参考 MPAC。

13.6 应用协议不等于协作正确性

截至 2026-08-03，A2A v1.0.1 是官方最新稳定 release；其规范定义远程 Agent 之间的身份发现、message、task、status、artifact 与 transport binding。这是 E1：A2A 能提供互操作 lifecycle，但不负责决定 decomposition 是否正确，也不自动解决共享 repository 事务、semantic merge、trust composition、verifier 独立性或 Byzantine consensus。面试中应把 A2A 视为 communication/application protocol，把 MPAC 视为尚待验证的多-principal 协作提案，而不是把二者当成通用“多 Agent 智能层”。

14. 一致性：对控制状态求共识，不对真理做多数表决

14.1 四种不同的一致

• State consistency：大家看到同一 task status、owner epoch、base revision；
• Artifact consistency：依赖的 schema/interface/version 兼容；
• Decision agreement：Agent 对选择达成一致；
• Semantic correctness：选择真的满足外部目标。

前三者即使成立，也不能推出第四者。系统可以一致地接受一个错误方案。

14.2 哪些状态必须强一致

通常必须强一致或单写者的有：effect authorization、task owner、merge head、budget debit、finalization record。适合 causal/eventual 的有：探索笔记、候选 evidence、非关键进度和 metrics。

14.3 Optimistic concurrency

当冲突低、回滚便宜时，worker 可基于 base_version 并行，提交时 compare-and-swap；版本不匹配则生成结构化 conflict，而不是最后写入覆盖。高冲突或不可逆 effect 应采用预先锁定/串行 gate。

14.4 Consensus 的边界

Consensus 可以决定“哪个 artifact 被接受为当前版本”，但真值仍需 verifier、principal policy 或外部环境。把多数 Agent 同意当 correctness oracle，是把一致性协议误用成 epistemology。

15. 终止、取消与恢复

15.1 “所有人都没说话”不等于结束

分布式系统里可能仍有 in-flight message、后台 tool、未过期 lease、等待人类输入或因丢消息而永久等待的 Agent。终止必须是显式状态，而非安静推断。

15.2 任务状态机

queued -> runnable -> leased -> running
running -> produced -> verifying -> accepted
running -> blocked | failed | cancelled | expired
verifying -> revision_requested -> runnable
produced/verifying -> stale -> cancelled or replanned

状态转换必须带 stable task ID、owner epoch、reason、evidence 和 timestamp。

15.3 全局完成条件

Root task 只有同时满足以下条件才能 final：

• 所有 required DAG nodes 已 accepted 或由 policy 明确 waived；
• 所有 acceptance artifacts 与 evidence 存在且版本匹配；
• 没有可能影响结果的 in-flight effect/message/background task；
• 共享状态没有 unresolved conflict；
• 全局 verifier 已在最终组合 artifact 上通过；
• finalization 以幂等、不可变 receipt 记录。

15.4 Deadlock、Livelock 与递归爆炸

• Deadlock：A 等 B、B 等 A；用 wait-for graph 与 dependency cycle detection；
• Livelock：Agent 持续互相 request_revision 但没有新证据；用 progress metric 和 round cap；
• Retry storm：多个 worker 同时接管 expired task；用 lease、fencing、jitter 与唯一 requeue owner；
• Recursive explosion：subagent 无界创建 subagent；限制 nested depth、fan-out、global budget；
• False completion：parent 在 background effect 结束前汇报；finalization barrier 必须等待受管任务 settle。

15.5 Cancellation 是树传播，不是一个布尔值

取消 root 后：停止新 delegation；撤销可撤销 authority；向 descendant 发送 cancel；终止未开始任务；等待/强制结束工具进程；记录已经发生的不可逆 effects；保留 partial artifacts；标记 late result 为 stale。不能假设发出 cancel 就代表 effect 未发生。

15.6 恢复

恢复依据应是 durable task journal、artifact store 与 effect receipt，而不是只靠 parent summary。对每个 task 判断：

• 未开始：安全重派；
• 运行中、lease 过期：以新 epoch 重派；
• artifact 已提交、ack 丢失：按 content hash 去重；
• effect 可能发生、receipt 丢失：先 reconcile，不盲重试；
• verifier 中断：恢复 verifier，不要求 worker 重新生成。

16. 统一运行流程

这个流程的控制面由 deterministic runtime 拥有；LLM 可以建议 decomposition、routing 与修复，但不能靠自然语言独占 task state、权限和最终一致性。

17. 失败分类与首个坏决策

面试中不要只说“加重试、加 review”。先定位 first bad decision，再说明哪个 boundary 应拥有修复。

18. Metrics 与 Eval：证明组织结构真的更好

18.1 Outcome 指标

• task success / test pass / accepted patch；
• partial credit 与 requirement coverage；
• defect escape rate；
• safety violation / unauthorized effect；
• 人类最终返工量与 acceptance time。

18.2 Coordination 指标

Speedup               = T_single / T_multi
Parallel efficiency   = Speedup / N
Critical-path stretch = T_multi / ideal_DAG_makespan
Coordination token %  = coordination_tokens / total_tokens
Redundancy rate       = duplicate useful-equivalent work / total work
Handoff rejection     = rejected or reworked handoffs / total handoffs
Merge conflict rate   = conflicting merges / attempted merges
Stale work rate       = work invalidated before acceptance / total work
Verifier queue delay  = time waiting for verification / total wall time

18.3 可靠性指标

• pairwise error correlation；
• effective diversity / N_eff；
• error propagation rate 与 amplification ratio；
• false acceptance / false rejection；
• judge disagreement 与 calibration error；
• common-mode failure rate；
• recovery success、duplicate effect、false completion。

18.4 组织与权限指标

• task-to-owner uniqueness；
• authority utilization：授予能力中实际需要的比例；
• delegation depth 与 privilege attenuation；
• cross-owner write conflict；
• orphan task、expired lease、late result；
• human arbitration rate 与原因。

18.5 必做 ablation

至少比较：

1. product-native strongest single Agent；
2. pi 式最小、可组合 single-agent harness：同模型、同工具能力、同 sandbox，避免把产品 prompt/tool overhead 混进“模型能力”；
3. single Agent + 同等额外 test-time compute；
4. 多 Agent independent aggregation；
5. centralized orchestration；
6. 目标 topology；
7. 无 specialization / 无 verifier / 无 state isolation 的消融。

同时做两类 budget：固定总 token/工具调用，以及固定 wall-clock/允许更多 compute。否则多 Agent 可能只是花更多钱获胜。

跨产品实验还必须冻结 source revision、setup scripts、credential/effect scope、checkout isolation 和 verifier；同时记录公开 product contract 与实际 trace 中使用到的机制。无法观察的 planner、scheduler 或 context packing 只能标为 unknown，不能用最终分数反推出具体内部原因。

18.6 Eval 分层

• 按 decomposability、sequentiality、tool count、shared state intensity 分桶；
• 记录模型、harness、topology、N、communication rounds 与权限；
• stochastic tasks 重复多次，报告分布与 tail risk；
• 注入 crash、stale artifact、malicious peer、merge conflict、judge bias；
• outcome 与 trajectory 同评，定位 first bad decision；
• 最终 verifier 不得与被评系统共享同一未校准 judge。

18.7 什么时候可以宣布 multi-agent 有价值

只有当它在目标任务分布上满足：

• 相对强单 Agent 和等 compute baseline 有稳定增益；
• wall time 或质量至少一项显著改善；
• 成本、tail latency 和安全风险在产品预算内；
• 增益来自低相关工作、隔离或验证，而非 benchmark leakage；
• 随 Agent 数扩展时没有快速恶化的 verifier queue 与 shared-state conflict。

19. 2025–2026 一手研究：证据、边界与不能外推的部分

下表按截至 2026-08-03 可获得的最新论文版本复核。百分比中的“relative”与“absolute percentage points”不可互换；up to 也不代表跨模型平均收益。

前沿方向已经从“增加 Agent 数”转到评测 orchestration plan、信息保真、dependency structure 和 verifier capacity。但 2026 年 7 月的新结果仍以 v1 preprint、小样本或 synthetic harness 为主，只适合作为研究路线，不应升级为产品定律。

总判断：现有证据不支持“swarm 默认优于单 Agent”，而支持 conditional scaling：任务可分解度、tool density、single-agent capability、error correlation、workspace isolation、information preservation 和 verifier capacity 共同决定收益。

20. Realized Product Frontier：不要把 feature surface 当先进性排名

Codex、Claude Code、Kimi Code 与 pi 已经把不同的组织设计做成可运行产品或可组合 substrate。对比它们的目的不是选出“Agent 数最多者”，而是识别各自公开承诺了什么控制面、哪些行为可观察、哪些结果真正经过 eval。

20.1 四层证据必须分开

因此，Kimi 的 AgentSwarm 细节公开、Codex 的 subagent thread 可检查、Claude 的 agent team 有共享 task list，分别只是不同的 contract visibility。没有固定 compute、同任务、同版本的 product-level ablation，就不能把公开可见性排成先进性顺序。反过来，pi 明确不内建 subagent，也不能被简化成“落后”：它提供的是一个可审计、可替换的单 Agent substrate 和 control baseline。

20.2 四种已实现产品形态

20.3 Codex：多 Agent control plane 与 worktree data plane 分离

截至 2026-08-03，Codex 官方 Subagents contract 表明：本地 Codex multi-agent 默认开启，app、CLI 与 IDE 会展示 subagent activity；main 负责 spawn、follow-up routing、wait 与 close，用户可以检查、steer、interrupt agent thread。custom agent 还可独立配置模型、reasoning effort、sandbox、MCP 与 skills，并由 agents.max_concurrent_threads_per_session 控制 open spawned threads。subagent 会继承 parent turn 的 live sandbox/approval overrides；交互式 CLI 能从非当前 thread 弹出带来源标记的 approval。

这已经是 realized multi-agent product，而不只是 prompt pattern。但官方同一页仍建议 parallel agents 先用于 exploration、tests、triage、summarization，并警告 write-heavy 并行冲突。官方 Worktrees 则为独立 app chat/后台任务提供 Git checkout 隔离、Local↔Worktree handoff、snapshot/restore 与生命周期管理。两者应被理解为正交层：

subagent thread = delegation / context / lifecycle control plane
worktree chat    = repository checkout / branch / handoff data plane

除非某个具体 Codex surface 明确把二者绑定，不能从“Codex 支持 worktree”推出“每个 subagent 自动写隔离”；也不能从“subagent 与 parent 共享 workspace”推出整个 Codex 平台没有并行隔离能力。

20.4 Claude Code：从 subagent 到 team、background session 与 worktree 的多层产品面

Claude Code 的官方 parallel-agents overview 已把四类运行方式拆开：subagent 在一个 session 内委派并回传摘要；agent view 让用户 dispatch/attach 多个 background session；agent team 由 lead、shared task list 与 mailbox 协调多个 session；dynamic workflow 用 script 持有大规模计划与交叉验证。

几个 contract 细节尤其值得面试时指出：

• Subagents 有独立 context，可前台/后台运行；当前文档将后台作为默认，并按版本明确 permission prompt、completion notification 与 premature-completion 修复。这说明 lifecycle 语义必须带版本，不能只说“支持后台”。
• Agent view 是 research preview：每个 row 是可 attach/reply 的完整 background session，编辑任务可自动进入 worktree；但它在本机运行、消耗近似线性的额度，机器关机后停止。
• Agent teams 是 experimental/default-off：lead 和 teammate 有独立 context，通过 shared task list、dependency、claim lock 与 mailbox 直接协作；当前公开限制包括 in-process teammate 不能随 /resume 恢复，以及 task status 可能滞后。
• Worktrees 可用于独立 session，也可通过 isolation: worktree 给 subagent 单独 checkout；但官方 overview 明确 agent-team teammate 不自动获得 worktree 隔离，同文件写入必须先分 ownership。

这组产品事实说明“subagent、background agent、agent team、worktree”不是同义词：它们分别控制 delegation、human supervision、peer coordination 与 mutable-state isolation。Claude 的 feature breadth 是有价值的 contract 设计样本，但 experimental surface 不能与稳定、默认路径混写，更不能代替产品 eval。

20.5 pi：可组合单 Agent 是必要 baseline，不是残缺 swarm

pi 的官方代码审计冻结在 c6eb6281（2026-08-03）。其 coding-agent README明确选择最小核心：内建 read/bash/edit/write/grep/find/ls，支持多 provider/model、session tree、compaction、skills、packages、SDK 与 JSONL RPC；Extension API允许运行时注册/替换 tool、订阅 lifecycle event、写 UI 与 session state，Session format提供可分支、可压缩的 JSONL tree。

pi 同时明确说 core 不内建 subagent、MCP、permission popup、plan mode 与 background bash；这些由 extension/package、tmux 或 container 决定。正确评价是：

• 它把 single-agent loop、tool/event contract 和 durable session 暴露为可组合 substrate；
• 它适合作为最强单 Agent、同模型同 budget、少 orchestration token 的 control baseline；
• 它也让研究者能自己实现 subagent extension，但该扩展的协调、权限、隔离和 eval 责任不再由 pi core 承担；
• 因此比较 Kimi/Codex/Claude 与 pi 时，必须把“产品自带 orchestration 的完备性”和“底层单 Agent 的效率/可控性”分成两个指标。

20.6 Kimi Code：已公开的组织模型，而非先进性结论

本节只陈述可追溯的公开事实。复核时官方 changelog 的最新 release 是 Kimi Code CLI 0.31.1（2026-07-31），代码审计冻结在 main@29c9e2ab20a1646ad33f2b7c999b450152f9c01a（2026-08-03）的官方 snapshot。main 可能领先已安装的 0.31.1，因此以下 source-level 行为都应带 commit；实际面试若讨论用户机器行为，要再核对安装版本与 engine。这些是 E1 实现事实，不自动构成质量、效率或跨产品领先证明。

• 每个 session 由 main Agent 驱动，main 负责理解、规划、工具调用与必要时委派；
• subagent 只接收明确 task description，在独立 context 工作，最终只把结论交回 main，不直接与用户通信；
• 内建 coder、explore、plan 三种 profile，对应通用读写、只读探索和无 shell 规划；
• Agent 支持 foreground/background、resume，source/docs 中默认 foreground timeout 为 2 小时；coder 还能嵌套委派；
• 自动调度参考 task complexity、context consumption 与 subtask independence；
• 每个 subagent 独立消耗 model tokens；简单任务由 main 处理更经济；
• custom agent 可配置 model preference、tools、disallowed tools、subagents allowlist；Agent 与 AgentSwarm 在 dispatch 时重验 allowlist；
• subagent 状态持久化在 session 的 agents/ 下，各自有 wire.jsonl；background lifecycle 通过 tasks/ 暴露；
• AgentSwarm 接收共享 prompt_template（以 {{item}} 注入差异）以及新 items 和/或待恢复 Agent IDs，等待全部 worker 结束后统一聚合结果；
• v2 source把单次 swarm 总数硬限制为 128；这只是 protocol safety bound，不是“最优 128 并发”；
• 当前 snapshot 的 batch runner 默认先启动 5 个，随后每 700 ms 再启动一个；默认没有额外 concurrency cap，可用正整数 KIMI_CODE_AGENT_SWARM_MAX_CONCURRENCY 限制，并含 rate-limit-aware 恢复。AgentSwarm 必须是该 assistant response 中唯一的 tool call，调用本身会等待整个 batch settle。参考运行实现与工具包装。

20.7 Kimi 公开机制与本章理论的对应

20.8 五个必须提出的独立判断

Context isolation 不等于写隔离

官方文档明确独立的是 context window；coder 能写文件和执行命令。除非 runtime 另有 workspace 隔离机制，多个写 Agent 并行时仍必须做 file ownership、worktree/branch 或强制调度。这是从公开 contract 推出的工程要求，不应把它误称为已确认的 Kimi 内部实现。

Final-only handoff 保护主 context，也制造压缩边界

中间 reasoning/tool records 不混入主历史能提高 signal density，但 parent 若只能看到无引用结论，会难以验证。合理设计是 final handoff 携带 artifact/evidence references，而完整 trace 留在 subagent wire，按需查询，不把日志全部回灌。

权限继承是 UX 优化，也是 blast-radius 选择

官方文档说明 main 已接受的 always-allow rules 会传播到 subagents。它减少重复 approval，但意味着 parent 的宽权限可能扩散到并行和嵌套执行。custom profile 的 tool/subagent allowlist、runtime re-check、用户对 dispatch task 的可见性，应该共同形成更窄边界。这是 E1 的权限传播事实加 E4 的风险推论。

Dispatch approval 必须带 engine、mode 与 version

截至该 snapshot，官方资料内部不能支持一句无条件的“AgentSwarm 总是自动批准”或“每次都弹审批”：tools.md区分 Agent 自动允许，以及 AgentSwarm 在 swarm mode 自动允许、其他模式需审批；agents.md又描述每次 dispatch 为 approval request；v2 默认 policy同时列入 Agent 与 AgentSwarm，v1 默认 policy只列 Agent，另有专门 swarm mode。可靠回答应先说明 release、engine 和 permission mode，并以目标安装包的实际 policy/trace 为最终事实源；这里暴露的是官方文档需要收敛的 contract gap，而不是替某一种行为猜结论。

公开实现细节不能构成跨产品排名

Kimi 的 batch ramp、Codex 的 agent-thread controls、Claude 的 team mailbox 与 pi 的 extension event bus，都是产品 contract 的不同切面。公开源码多只能提高 auditability；封闭实现细节少只能留下 unknown。先进性必须落到目标任务上的 quality × latency × cost × risk，以及 trace 能否解释 first bad decision。若无同版本、同任务和同 budget 对照，最专业的回答是“contract 已确认，内部策略未知，效果未证”，而不是补出一个品牌排名。

20.9 面向 Kimi JD 的架构与评测回答

如果被问“怎样改进 Kimi Code multi-agent”，一个高质量答案不是增加更多 role，而是：

1. 用 task DAG 和 access-set conflict prediction 决定单 Agent、parallel read 或 isolated write；
2. 将 task contract、artifact refs、acceptance evidence 做成结构化 handoff；
3. main 维持 centralized policy/verification，但将局部 schema/test 验证前移以解除瓶颈；
4. nested delegation 采用 global fan-out/depth/budget 和 capability attenuation；
5. subagent wire、background task 与 parent trace 使用稳定 causal IDs；
6. 明确 late result、cancel、resume、effect receipt 与 finalization barrier；
7. 把 128 视为 hard safety ceiling；真实 concurrency 由 DAG runnable width、tool/write conflict、rate limit、verifier throughput 与 tail latency 自适应控制；
8. 用 fixed-compute ablation 按 task shape 证明 AgentSwarm 相对 main Agent 的收益，并单独报告 launch-ramp、straggler 和 all-settle 成本；
9. 竞争分析至少设置四个 control：pi 式可组合单 Agent、各产品 native strongest-single、等 wall-clock multi-agent、等 total-token/tool-call multi-agent；写任务统一使用等价 checkout isolation；
10. 把 contract coverage、trace completeness、false completion、human intervention、merge/stale work 与 effect safety 纳入 eval；对 planner、scheduler、context packing 等未公开内部机制标记 unknown，不用 feature checklist 猜能力。

这会把回答从“我们也要有 agent team/worktree”提升为可证伪的问题：Kimi 的哪个组织边界，在什么 task shape 和 budget 下，比强单 Agent 或其他已实现产品 contract 多创造了可验证工作？

21. Topology 决策表

21.1 十秒判断法

先问 task DAG 是否宽；
再问 artifact 是否独立；
再问 verifier 是否比 handoff 更便宜；
最后问错误是否真的低相关。

任意一项为否，默认不要扩大 Agent 数。

22. 二十组深追问与专家回答骨架

1. Parallel tool calls、ensemble 和 multi-agent 有什么本质区别？

回答骨架：从独立 policy/context/state/authority/lifecycle 定义 Agent；parallel tools 是单一策略的执行并发，ensemble 是独立采样后聚合，multi-agent 需要 task allocation、communication、ownership、merge 与 termination。不要按进程数或角色名定义。

2. 什么时候单 Agent 明确不够？

回答骨架：指出五种资源约束——critical-path time、context bandwidth、capability heterogeneity、authority isolation、independent verification；再给可验证条件：独立 work package、输入 snapshot、exclusive ownership、checkable output。

3. 为什么复杂任务不一定适合多 Agent？

回答骨架：复杂度与可分解度正交；强顺序、隐含状态多、共享写强时，critical path 不变，handoff/merge 只加成本。用 task DAG 的 W/L 解释最大并行度。

4. 怎样量化 Agent 数量的最优点？

回答骨架：写出带协调项的 Amdahl 公式；比较 marginal time/quality gain 与 spawn、context、communication、merge、verification、rework、risk；用 U = E[Q]-lambda_tT-lambda_cC-lambda_rR 选择，不固定 N。

5. Centralized 与 decentralized 如何选？

回答骨架：centralized 适合统一 principal、可分解、需强验收，优势是 error containment；decentralized 适合局部信息、动态 peer、中心不可用或多 principal，但必须付 discovery、identity、consensus、termination 与 Byzantine 成本。默认 Coding Agent 更偏 centralized。

6. Hierarchical topology 最大的隐藏风险是什么？

回答骨架：不是延迟，而是逐层 summary 损失与 authority 扩散；每层可能把不确定性压成确定结论。要求 artifact refs、causal trace、深度上限、越级 verifier 和明确 decision owner。

7. Blackboard 与共享聊天有什么区别？

回答骨架：blackboard 是 typed、versioned、owned、provenance-bearing shared state；聊天是自由文本事件流。前者支持 subscription、CAS、conflict 与 replay，后者不能充当一致性或事实源。

8. 如何做 task decomposition？

回答骨架：先建 DAG，再按 artifact/module/hypothesis/search space/concern/capability 等轴切；优化的是依赖边、write overlap、handoff surface 和 verifier cost，不是模拟人类岗位。强调子任务要 self-contained、deep、exclusive、verifiable、abortable。

9. 一个合格的 delegation contract 包含什么？

回答骨架：objective、scope/non-goal、input snapshot/base revision、dependencies、owner/write set、delegated authority、budget、deliverable schema、verifier/acceptance、evidence 与 uncertainty。parent 必须能 reject/partial accept。

10. Context isolation 为什么不能防止并行冲突？

回答骨架：context 只隔离模型输入；filesystem、Git index、ports、database、credentials、rate limit、deploy target 仍可能共享。并行安全要建 read/write/effect access set，并用 worktree、single writer、MVCC、locks 或 scheduler。

11. 多 Agent 写代码如何 merge？

回答骨架：freeze base、dependency-aware plan、exclusive file/interface ownership、isolated branch/worktree、local verifier + commit、按依赖顺序 integration、最终组合 artifact 重跑 global verifier；区分 textual、structural、semantic、temporal、policy conflict。

12. 为什么多数投票经常不可靠？

回答骨架：独立同分布是关键假设；同模型/同 prompt/同 sources/harness 产生相关错误。给 N_eff ≈ N/(1+(N-1)rho)；需要 causal diversity 和 evidence audit，而非更多角色名。

13. 怎样保证 evaluator 真正独立？

回答骨架：blind candidate identity/order；先读 spec/artifact 再读 generator explanation；不同 model/tool/evidence channel；能跑 external verifier；用 gold cases 校准 false accept/reject。相同 Agent 的 self-review 只是 refinement。

14. Debate 何时优于 verifier？

回答骨架：只有缺少直接 executable oracle、候选存在关键证据分歧、judge 能审计 divergence 时；事实可查询或 tests 可跑时优先 verifier。设 evidence-based stop rule，防止无限说服游戏。

15. 什么是 capability saturation？

回答骨架：单 Agent 越强，候选新增信息越少、相关性越高、orchestrator 重复推理越多；coordination marginal gain 跌破成本。引用 2026 研究的约 45% 现象时必须说明它是 benchmark-dependent，不是普适阈值。

16. Specialization 应如何路由？

回答骨架：用历史轨迹校准 p_ij、t_ij、c_ij、r_ij，做全局 DAG allocation；能力来自模型、工具、权限、memory、location、policy，而非 persona。对低风险任务保留 exploration，对高风险用保守置信下界。

17. 如何处理 malicious/Byzantine Agent？

回答骨架：先定义 fault model 与 membership；identity/anti-Sybil、message/artifact provenance、capability attenuation、fencing、minority evidence、independent verifier、graph monitoring。说明 3f+1 不能证明语义真值，经典 BFT 假设不可直接套 LLM 答案。

18. 如何判断一个多 Agent 任务真正结束？

回答骨架：required nodes accepted/waived、artifact versions match、no relevant in-flight effects/messages、no unresolved conflict、global verifier passed、atomic idempotent finalization receipt；quiet 不等于 termination。补充 deadlock graph、lease、late result 和 cancellation cascade。

19. 怎样评测 multi-agent，而不是只测模型？

回答骨架：强 single baseline、同等 compute baseline、independent/centralized/target topology ablation；按 decomposability/tool density/shared state 分桶；同时测 success、makespan、total token、coordination%、error correlation/amplification、merge/stale/false-complete、安全与人类返工。

20. 如何评价 Kimi、Codex、Claude Code 与 pi 的多 Agent 设计？

回答骨架：拒绝 feature checklist 排名，先分 product contract、observable trace、product eval、unobserved implementation。Codex 已实现可 steer/inspect 的 subagent thread 与独立 worktree chat；Claude 已实现 subagent、background agent view、experimental team 与 worktree isolation；Kimi 已实现 Agent/AgentSwarm、resume、profile/permission 和 per-agent wire；pi 刻意保持可组合单 Agent core，作为 control baseline。再对齐 task shape、版本、模型、checkout isolation 与 budget，比较 quality、latency、cost、conflict、false completion 和 human intervention。对未公开 planner/scheduler/context packing 明确说 unknown。

23. 面试中的一页式回答框架

被问任何 multi-agent 设计题时，按以下顺序回答：

1. Task shape：DAG 宽度、critical path、tool density、shared-state intensity；
2. Why multi-agent：时间、context、capability、authority 或 verification 哪个收益成立；
3. Topology：为什么 centralized/decentralized/hierarchical/market/blackboard；
4. Contract：input snapshot、ownership、authority、artifact、verifier；
5. State：isolation、version、lease、message、effect receipt；
6. Integration：handoff、merge、judge/debate、global verification；
7. Failure：correlated error、stale write、Byzantine、deadlock、false completion；
8. Evidence：fixed-compute ablation、outcome/trajectory/coordination metrics。

最后落到一句话：

Multi-agent 的 scaling unit 不是 Agent 数量，而是可独立验证的有用工作；组织设计的目标不是让更多 Agent 发言，而是缩短 critical path，同时控制 handoff、共享状态、权限和错误传播。

24. 一手论文与官方 Product Contract 索引

• Google Research：Towards a science of scaling agent systems
• Towards a Science of Scaling Agent Systems
• Effective Strategies for Asynchronous Software Engineering Agents
• CodeTeam
• Can LLM Agents Really Debate?
• AgentAuditor
• Robust Multi-Agent LLMs under Byzantine Faults
• Byzantine Cheap Talk
• MPAC
• OrchBench
• Matryoshka Agent
• A2A v1.0.1 release
• A2A specification
• Codex：Subagents
• Codex：Worktrees
• Claude Code：Run agents in parallel
• Claude Code：Subagents
• Claude Code：Agent view
• Claude Code：Agent teams
• Claude Code：Worktrees
• pi coding-agent frozen snapshot：c6eb628
• pi coding-agent README / philosophy
• pi Extension API
• pi Session format
• Kimi Code：Agents and Sub-Agents
• MoonshotAI/kimi-code frozen snapshot：29c9e2a
• Kimi Code tools reference（snapshot）
• Kimi Code AgentSwarm source（snapshot）