多智能体协作模式

• 理解 Supervisor-Worker 的分解、分派与汇总机制
• 理解 Supervisor 的瓶颈与单点风险
• 掌握缓解方案（层次化、状态持久化、负载均衡、降级）

Supervisor-Worker 中，Supervisor 负责把大任务分解为子任务，分派给 Worker，并汇总结果。分解要基于任务依赖与粒度，保证子任务可并行且可独立评估；分派要考虑 Worker 能力、负载与亲和性；汇总则要处理部分失败、合并 artifact 并做质量校验。Supervisor 成为瓶颈或单点的问题：1) 所有任务都经它串行决策，吞吐受限；2) Supervisor 崩溃则整个协作停摆。缓解方案：1) 层次化——把 Supervisor 拆成多级，避免单一大 Supervisor 承载全部；2) 状态持久化——把任务状态与分派记录落库，Supervisor 崩溃后可恢复而不丢失进度；3) 负载均衡与多副本——多个 Supervisor 实例分片处理任务；4) 减少同步点——尽量让 Worker 在无 Supervisor 介入下完成确定性工作，Supervisor 只做关键决策；5) 故障降级——Supervisor 不可用时暂停新任务、对运行中任务做最小回收，避免状态丢失。

Supervisor 是"编排焦点"，也是"吞吐瓶颈"与"单点故障"。缓解的关键是把"决策"与"执行"解耦，让 Supervisor 只做必须的集中决策，同时用持久化与多副本消除单点。层次化把集中式瓶颈摊薄到多级。

• 理解对等协商的职责划分问题
• 理解重复工作、意见循环与责任缺失的成因
• 掌握分工、仲裁与最终裁决机制

Peer-to-Peer 协商中，多个对等 Agent 地位相同，容易产生三类问题：1) 重复工作——多个 Agent 不知道他人已做而重复执行；2) 意见循环——A 反驳 B、B 反驳 A，无法收敛；3) 无人负责——没有明确的所有者，最终决策无人拍板。应对方法：1) 明确分工与任务所有权——通过共享状态/黑板声明"谁负责什么"，避免重复；2) 协商边界——设定轮次上限、共识阈值，超限即触发仲裁；3) 引入仲裁/裁判——外部裁判（人或规则系统）在僵局时做最终裁决；4) 明确决策责任——指定最终决策者（如发起方或按领域分派），即使是对等协商也要有"拍板人"；5) 记录决策理由——让最终决策可解释、可审计。对等不意味着无秩序，协商之上要有明确的收敛与责任机制。

对等协商的三大痼疾都源于"缺乏明确的所有权与收敛机制"。解决的核心是"协商 + 仲裁"并存：日常对等讨论，僵局/终局由仲裁或指定决策者收敛，并用共享状态消除重复。

• 理解 Swarm 拓扑的动态发现与成员管理
• 理解任务交接与退出机制
• 理解控制网络扩张的策略

Swarm 是动态拓扑，Agent 可随时加入、退出，控制网络扩张需要约束三个环节：1) 发现——限制 Agent 通过注册中心/白名单发现，控制最大成员数与入网条件，避免无限扩张；2) 交接——任务在不同 Agent 间传递时，明确交接协议（谁接收、何时完成、状态如何转移），防止任务在网络上无限转发；3) 退出——Agent 退出时声明状态、清理共享资源、通知依赖方，防止孤立引用。防止网络无限扩张：设置成员上限与扩容审批、限制"再委派"深度（防止 Agent 无限创建子 Agent）、对每个任务设定最大跳数/轮次、超限即终止并上报。核心是"动态不等于失控"，加入/交接/退出都要有边界与上限。

Swarm 的活力来自动态性，但失控扩张会带来成本与复杂度失控。通过"成员上限 + 委派深度限制 + 跳数上限 + 退出清理"来约束动态行为，让网络在可控范围内伸缩。

• 理解带病合并与细节丢失的成因
• 理解质量校验与结果结构化
• 理解保留原始 artifact 与中间结果

带病合并发生在 Supervisor 把质量差的 Worker 结果当作正常结果合并，丢失细节发生在合并时只保留摘要而丢弃有价值的原始信息。避免方法：1) 质量校验——Supervisor 对每个 Worker 结果做质量/一致性校验（schema、范围、置信度），不合格的标记或退回重做，而非直接合并；2) 保留原始 artifact——不丢失 Worker 的原始输出，把"合并后的摘要"与"原始 artifact"并存，便于追溯与复核；3) 结构化合并——合并时保留来源、版本与每个 Worker 的贡献，而非只留一个平铺文本；4) 冲突处理——Worker 结果冲突时显式标记并交由仲裁，而非静默取其一；5) 审计——记录合并过程与决策依据，能够回放"为什么这么合并"。核心是"合并是压缩而非丢弃"，质量与细节都要保留。

Supervisor 的汇总质量决定整体质量。带病合并源于"不校验就合并"，细节丢失源于"只留摘要"。把校验前置、原始结果保留、合并过程可审计，才能既保证质量又保留细节。

• 理解循环讨论的成因
• 理解轮次上限、共识阈值与仲裁
• 理解收敛与终止机制

循环讨论是没有收敛的反复反驳，浪费 token 且无法决策。解决机制：1) 轮次上限——设置最大协商轮数，超过即强制进入决策或终止；2) 共识阈值——设定"多少 Agent 达成一致即通过"，达到阈值即收敛，不必所有人都同意；3) 仲裁/裁判——仍无共识时由外部裁判（人或规则系统）裁决，作出最终决定；4) 结构化反驳——要求每个反驳必须携带新证据或新论点，禁止无新信息的重复反驳，防止"空转"；5) 时间/预算熔断——协商总时间或 token 超限即终止并采用当前最优解。循环讨论的本质是"缺乏收敛条件"，因此必须显式定义"何时停止、如何拍板"。

循环讨论的根因是没有终止条件。收敛机制就是给它设置"停止条件"：轮次、共识、预算、仲裁。结构化反驳则从输入侧减少无效争论，仲裁从输出侧保证必达决策。

• 理解动态拓扑中的一致性挑战
• 理解共享状态同步与消息去重
• 理解 artifact 版本控制

动态加入/退出时，需保证共享状态、消息与 artifact 的一致性。1) 共享状态——用中心化或最终一致的状态存储（如 KV/数据库/黑板）作为单一事实源，Agent 加入时读取快照、退出时写回并广播，避免各自缓存漂移；2) 消息去重——消息带全局唯一 ID 与幂等键，Agent 加入后重放补齐，重复消息被去重，避免重复副作用；3) Artifact 版本——artifact 带版本号与内容寻址，Agent 退出后其产物仍可被引用，新 Agent 基于版本快照工作，避免读旧版；4) 加入/退出协议——加入时注册并同步状态，退出时清理注册、提交未完成产物并通知依赖方。核心是"状态有权威源、消息有幂等、产物有版本"，这样成员的增减不会破坏协作一致性。

动态拓扑最怕"成员变动导致状态分裂"。单一事实源 + 幂等消息 + 版本化 artifact 三件套，使加入方总能拿到最新一致状态，退出方不会留下断裂引用。

• 理解共享状态与权威事实源的同步模型
• 理解冲突的检测与解决策略
• 理解版本与仲裁机制

多 Agent 同步的关键是"单一权威事实源 + 版本化 + 冲突仲裁"。1) 权威事实源——把共享状态集中到权威存储（KV/数据库/外部记忆），所有 Agent 读写同一事实源，避免各自缓存漂移；2) 同步——通过事件/订阅推送变更，或周期性拉取，用版本号/时间戳判断新旧；3) 消息——带全局 ID 与幂等键，保证顺序与去重；4) Artifact——版本化 + 内容寻址，多 Agent 可并发产出不同版本；5) 冲突解决——检测"同一对象被多个 Agent 并发修改"（版本冲突/写冲突），用策略解决：最后写入者胜（LWW）、显式合并、按优先级/权重取优、或交仲裁 Agent/人工裁决。冲突解决要可审计、可回放，并记录决策依据。核心是"状态有权威、变更可追踪、冲突有裁决"。

多 Agent 的一致性问题本质是分布式一致性问题。权威事实源收敛"读"，版本号解决"写"，仲裁解决"冲突"。三者结合，让并发的 Agent 协作而不互相覆盖。

• 理解 Agent 数增长带来的成本与风险
• 理解并发、轮次与预算上限的设置
• 理解熔断与降级

Agent 数增长会放大 token 消耗、尾部延迟与故障面，需用显式上限约束：1) 并发上限——限制同时运行的 Agent 数，避免资源耗尽与过载，用信号量/连接池控制；2) 轮次上限——限制协作轮次（总轮数、单个 Agent 内最大步数），防止循环与无限扩展；3) 预算上限——设置总 token 预算、单 Agent 预算、单任务预算，超限即熔断或降级；4) 时间上限——总时长/单跳超时，尾部延迟通过超时与并行化缓解；5) 故障面控制——限制单点影响的 Agent 数，用隔离与降级让部分失败不回滚全局。设置上限的依据是"成本/延迟/故障三者的权衡"：性能敏感任务调低轮次与并行，复杂任务则放宽预算但设硬上限。超限时熔断（停止新任务）、降级（用单 Agent/简化方案）并告警。

多 Agent 的收益有边际，成本却线性甚至超线性增长。设上限是把"无限潜在的协作"约束为"预算内的可预期协作"，同时用熔断与降级控制尾部延迟与故障扩散。

• 理解上下文隔离的意义
• 理解独立 system prompt 的设计
• 理解上下文污染与泄漏风险

不同 Agent 应隔离上下文，各自维护独立的 system prompt 与上下文窗口，避免互相污染。设计要点：1) 每个 Agent 有独立的 system prompt，定义其角色、能力边界、规则与工具，不共享中间状态；2) 上下文隔离——Agent 只接触自己任务相关的数据，不把其他 Agent 的输入/中间思考混入；3) 最小暴露——通过明确的输入/输出契约传递信息，而非共享整个上下文；4) 防止注入——不把其他 Agent 的原始输出直接拼入 system 或高风险上下文，隔离可降低提示注入面。独立 system prompt 的价值在于：职责清晰、行为可预期、可单独调优与测试，且能防止"一个 Agent 的指令污染另一个 Agent 的决策"。隔离不足会导致角色混淆、指令冲突与安全漏洞。

上下文隔离是"关注点隔离"的体现。每个 Agent 是独立决策单元，若共享上下文，角色边界与安全边界都会模糊。独立 prompt + 最小数据传递是隔离的落地方式。

• 理解任务预算的维度（token、时间、轮次）
• 理解预算的分配与监控
• 理解超限处理

任务预算包括三个维度：总 Token（LLM 调用成本）、总时间（端到端延迟上限）、最大轮次（协作深度）。设置方法：1) 按任务复杂度与价值设定预算——关键任务留足预算，简单任务收紧；2) 分配——把总预算分配到各 Agent/子任务，设定单 Agent 预算与单轮预算；3) 监控——实时统计 token 消耗、耗时与轮次，接近阈值即预警；4) 超限处理——触发熔断（停止扩展）、降级（用单 Agent 或简化流程）、或返回部分结果并告警。预算管理还应与可观测性结合，超限的 Agent 要能被定位。核心是"把无限潜力的协作约束为预算内的可预期执行"，并保证超限时优雅降级而非失控。

预算不是"降低质量"，而是"控制成本与风险"。三个维度（token/时间/轮次）分别对应成本、延迟与复杂度，缺一不可。超限降级是关键，保证预算内的最佳结果。

• 理解异步协作中的超时与迟到结果
• 理解部分成功与最终一致性
• 理解状态收敛与补偿

异步协作中，Agent 响应可能超时、迟到，任务可能部分成功，需处理：1) 超时——为每次调用设超时，超时后标记该 Agent 失败或降级，避免无限等待；2) 迟到结果——对超时后到达的结果做判别，若任务已由其他路径完成则丢弃或标记过期，用结果时间戳/幂等键判断；3) 部分成功——允许部分 Agent 成功、部分失败，Supervisor 汇总时合并成功结果并记录失败，形成"部分完成"的最终状态；4) 最终状态一致——用权威状态机收敛：所有子任务达到终态后，Supervisor 依据"成功/失败/超时"计算最终任务状态（completed/failed/partial），并记录每个子任务的状态供审计；5) 补偿——失败的子任务可重试或由替代 Agent 接管，但要在预算内。核心是"即使部分失败，整个任务也有明确、一致的终态"。

异步协作天然存在响应不确定性。处理关键是"定义明确的终态判定规则"：超时/迟到/部分成功都要有归属，最终通过权威状态机收敛到一致终态，避免"不知道任务到底算不算完成"。

• 理解单 Agent 加工具的适用场景
• 理解多 Agent 的必要条件
• 理解对照实验的评估方法

单 Agent 加工具适合：任务单一、依赖明确、无需并行或角色分工、单模型上下文足够承载的场景（如一问一答、单步工具调用、简单表单处理）。这类任务用多 Agent 只会增加 token、延迟与故障面而无收益。多 Agent 的必要性需通过对照实验证明：1) 设对照组——同一任务集分别用"单 Agent 加工具"与"多 Agent 编排"两种方案；2) 定义指标——任务成功率、质量评分、成本（token）、延迟、错误率、人工接管率；3) 控制变量——同一数据集、同一模型能力、同一评估标准；4) 统计对比——若多 Agent 在质量/成功率上有显著提升，而其成本/延迟增加可接受，则证明必要；否则说明单 Agent 更优。判断标准是"质量提升是否覆盖成本增加"，而非"多 Agent 听起来更先进"。

多 Agent 是手段不是目的。单 Agent 已能解决的就别上多 Agent。对照实验用数据说话，把"多 Agent 是否更值"从直觉变成可量化结论，避免过度设计。

• 理解角色定义应偏重能力而非人设
• 理解可验证属性（能力边界、工具、输出格式）
• 理解人格化过度削弱的风险

角色定义应聚焦可验证、可执行的属性，而非堆砌人格化描述。可验证属性包括：1) 角色目标与职责边界——明确"这个 Agent 负责解决什么、不负责什么"；2) 能力与工具——关联的能力、可用工具、数据范围；3) 输入输出契约——明确的输入格式、输出 schema 与约束；4) 决策规则与优先级——在冲突时如何取舍；5) 权限与安全边界——能访问哪些资源、不能做什么。过度"人格化"（如"你是一个友善的专家"）会引入模糊、不可测试的指令，可能削弱判断（Agent 更倾向迎合人设而非按事实决策）。设计原则是"角色 = 能力 + 边界 + 规则"，用可验证的属性描述，而非文学化人设。

角色定义的价值在于"可预测性与可测试性"。可验证属性让 Agent 行为可被评估、可被约束；人格化人设则引入不可控的偏差。工程上应把 persona 当作"契约"而非"性格"。

• 理解事实冲突的成因（数据源、模型、上下文）
• 理解冲突检测与仲裁
• 理解证据权重与可解释性

事实冲突源于不同 Agent 的数据源、模型或上下文不同。处理流程：1) 检测——统一 schema 或人工比对发现不一致；2) 溯源——追溯每个答案的证据来源与置信度，判断是数据过时、模型错误还是上下文缺失；3) 仲裁——用证据权重、来源可信度、最新时间戳等规则判定，或将冲突交由仲裁 Agent/人工裁决；4) 收敛——合并时取可信度最高的结论，或保留分歧并标注"待确认"；5) 可解释——记录仲裁依据与来源，让最终结论可追溯。若冲突无法解决，应显式暴露而非静默掩盖，交由用户或升级流程决定。原则是"冲突要显式处理、可解释、可升级"，而不是任取其一。

事实冲突是多 Agent 的必然现象。处理的关键是"检测 + 仲裁 + 可解释"：不能静默选一个，而要基于证据权重与来源裁决，并保留决策依据，这样既能保证质量又能审计。

• 理解串行轮次导致的延迟累积
• 理解每轮 LLM 调用的等待时间
• 理解缓解方法（并行、流水线、减少轮次）

多 Agent 系统总延迟远超单 Agent，主要因为：1) 串行轮次——多 Agent 协作常是"链式"或"协商式"，每一步都要等上一步完成，每轮都包含一次以上 LLM 调用，延迟逐轮累积；2) 每轮往返——每次 Agent 间消息传递、协商、仲裁都要等待完整 LLM 推理，单轮延迟已包含推理时间，多轮叠加后总延迟远高于单 Agent；3) 同步点——Supervisor 汇总、仲裁等待最慢的 Agent（尾部延迟），进一步拉长。缓解方法：1) 并行化——能并行的子任务并行执行，压缩串行关键路径；2) 减少轮次——减少不必要的协商与往返，用一次调用完成；3) 流水线——部分结果先行返回，减少等待；4) 精简层级——避免过深的串联链。核心是"串行关键路径上的轮次 × 每轮延迟 = 总延迟"。

延迟由"关键路径上的串行轮次"决定，而非总调用次数。多 Agent 把原本单次调用变成多次串行调用，每轮还叠加推理与网络延迟，因此总延迟显著上升。优化方向是缩短关键路径、并行化、减少轮次。

• 理解复盘所需的上下文与轨迹
• 理解隐私保护与数据脱敏
• 理解最小化与审计边界

失败复盘需要定位"哪个 Agent 在哪个环节出错"，应保留：1) 结构化轨迹——任务 id、各 Agent 的输入/输出、工具调用、状态转移、时间戳、错误信息；2) 决策依据——Agent 基于什么做出该决策（引用的数据/来源），但不包含推理过程中的敏感内部思考；3) 版本与配置——模型、prompt、工具版本，便于复现。同时不暴露隐私：1) 脱敏——对个人数据（姓名、邮件、身份）做脱敏/掩码，日志只保留"角色标签"而非真实主体；2) 最小化——不记录无关正文与内部思考，只记录任务相关的结构化信息；3) 权限控制——复盘日志按角色访问控制，审计人员只能看到脱敏轨迹；4) 保留期限——按合规要求设定日志保留期与删除策略。原则是"可复盘、可审计，但最小化、脱敏、不泄漏隐私"。

复盘与隐私是张力。解决方式是"结构化轨迹 + 脱敏 + 最小化"：记录足够定位错误的元数据与决策来源，但不记录真实个人数据与内部思考。这样既能故障定位，又满足合规。

• 理解僵局的触发条件
• 理解外部裁判的角色（人 / 规则系统）
• 理解裁判的裁决与记录

决策僵局是协商达到轮次上限或共识阈值后仍无法收敛的状态。外部裁判解决方式：1) 触发——协商超限或检测到分歧无新信息时，升级到外部裁判；2) 裁判类型——规则系统（基于事先定义的规则、优先级、证据权重自动裁决）用于确定性、可量化的分歧；人工裁判用于需要主观判断、涉及风险或合规的事务；3) 裁决输入——裁判接收各方的论点、证据与来源，而非仅凭身份；4) 裁决输出——作出最终决定并附理由，作为权威结论写入结果；5) 记录与回放——记录裁决过程与依据，供审计与改进规则。规则系统优先（快速、可解释、一致），人工作为兜底（处理规则无法覆盖的复杂/高风险情况）。裁判的存在让协商"必然收敛"。

僵局是协商的终点问题。外部裁判提供"最终权威"：规则系统保证确定性、可扩展、低成本，人工裁判保证复杂情况的合理判断。两者结合让协商总能收敛到决策。

• 理解可观测性（trace、log、metric）的统一
• 理解失败回放机制
• 理解权重调整与统一治理

统一治理基线要求 Supervisor 与 Worker 共享同一套观测、回放与调优机制：1) 统一可观测性——所有 Agent 用同一 trace 体系（taskId 贯穿），统一记录日志、时间、token、状态转移，Supervisor 与 Worker 的指标可关联分析；2) 失败回放——用结构化轨迹（含输入输出、工具调用、决策来源）支持离线回放，复现"哪个环节失败、为什么"；3) 权重调整——基于回放与指标数据，调整各 Agent 的权重/优先级/参数（如某个 Worker 反复失败则降低其调度权重或替换），并形成闭环；4) 统一基线——定义统一的成功标准、质量评分与告警阈值，让所有 Agent 在同一套标准下评估。治理基线把这些能力沉淀为制度化流程：观测数据 → 回放分析 → 调整 → 再观测，形成持续改进闭环。核心是"一套标准、一个闭环"。

治理不是各自为政，而是把观测、回放、调优统一起来。Supervisor 与 Worker 共享 trace 与指标，才能跨层级定位问题；回放提供依据，权重调整形成闭环，最终成为可持续治理的基线。

• 理解协商失败、资源争抢、循环依赖的成因
• 理解制度化的治理机制
• 理解回放与预防

三类问题可通过制度化治理避免：1) 协商失败——设置轮次上限、共识阈值、仲裁机制，把"协商必然收敛"固化为规则；2) 资源争抢——统一资源配额与锁，实现资源调度（如工具、数据库、LLM 配额），用优先级与公平队列避免争抢，并对争抢做监控告警；3) 循环依赖——静态分析 Agent 调用拓扑，检测环（A 调 B、B 调 A），用有向无环图约束调用关系，检测到环即拒绝或告警；4) 回放机制——把每次协作记录为结构化轨迹，离线回放可复现"哪里陷入协商失败/争抢/循环"，据此改进规则；5) 治理闭环——把规则沉淀为代码/策略（如策略即代码），用测试与监控持续验证。核心是"用制度与规则提前约束，用回放事后复盘改进"。

这三类问题都能通过"规则前置 + 回放复盘"制度化缓解：协商失败靠收敛规则，资源争抢靠配额与锁，循环依赖靠拓扑检测。回放让治理从"事后补救"变成"持续改进"。

• 理解循环讨论的三种收敛机制
• 理解轮次上限、共识阈值、仲裁熔断
• 理解三者组合

循环讨论通过三种机制组合收敛：1) 轮次上限——协商达到最大轮数即强制终止，避免无限争论；2) 共识阈值——设定"达到阈值即通过"，不必等所有人同意，加速收敛；3) 仲裁者熔断——超过轮次上限或长期无共识时，触发仲裁者裁决，熔断循环（立即终止协商并给出最终决定）。三者配合：轮次上限控制"最多讨论多久"，共识阈值保证"多数意见尽快生效"，仲裁者熔断保证"无论如何都收敛到决策"。仲裁者可以是规则系统或人工，裁决后记录依据供审计。若协商在轮次内达成共识则正常结束，未达成则熔断收尾，从而从机制上杜绝循环死锁。

循环讨论的根治是"给协商一个必达的终点"。轮次上限是时间闸，共识阈值是效率闸，仲裁熔断是兜底闸。三闸叠加，协商无论成败都有明确终局。

• 理解三类 Agent 的职责划分
• 理解如何减少通信噪声
• 理解流水线式协作

研究 Agent、执行 Agent、审校 Agent 应形成"流水线 + 有限交互"的分工：1) 研究 Agent——负责收集、检索与整理信息，输出结构化研究结果；2) 执行 Agent——基于研究结果执行具体任务（生成、计算、操作），输出产物；3) 审校 Agent——对产物做质量校验、纠错与一致性检查，输出审校意见。为避免通信噪声：1) 明确输入输出契约——每个 Agent 只输出结构化结果，下游只消费契约字段，不进行无边界闲聊；2) 单向流水线——研究→执行→审校，减少来回反复；3) 审校反馈有限轮次——审校发现问题时反馈给执行 Agent，但设回退轮次上限，超限则人工介入；4) 减少不必要同步——各 Agent 独立完成本职，只在接口处交互。核心是"分工明确、接口清晰、交互有界"，让协作提升质量而不淹没在噪声里。

质量提升来自"分工专业化 + 审校把关"，而非"更多 Agent 聊天"。清晰契约 + 单向流水线 + 有限反馈轮次，把通信限制在必要接口上，既统筹质量又控制噪声。

• 理解共享黑板、消息队列、Supervisor 三种传递方式
• 理解并发写入冲突
• 理解锁、版本与所有权

传递中间结果的三种方式：1) 共享黑板——所有 Agent 读写共享状态空间，适合数据共享，但需处理并发写冲突；2) 消息队列——通过消息传递结果，解耦生产与消费，天然避免"直接改同一状态"，但需处理排序与幂等；3) Supervisor 中转——通过 Supervisor 统一分配与回收，集中控制，避免直接竞争。避免多个 Agent 同时修改同一业务状态：1) 所有权——每块业务状态指定唯一所有者 Agent，其他 Agent 只能读取，避免写竞争；2) 锁/原子操作——对共享状态用乐观锁（版本号）或多版本，检测并拒绝并发写覆盖；3) 消息驱动——用事件/消息传递"变更意图"，由单一消费者应用变更，避免两处同时写；4) 版本化——所有写操作带版本，冲突时合并或仲裁。核心是"要么单一所有者，要么带版本冲突检测"，确保并发 Agent 不互相覆盖。

传递方式与"避免并发写"是两回事：黑板/队列/Supervisor 解决"怎么传"，所有权/锁/版本解决"谁写不冲突"。合理组合保证中间结果有效传递且业务状态不被多人同时破坏。

• 理解三种冲突解决方式
• 理解选择依据与优先级
• 理解可解释性

冲突解决应分级：1) 规则——确定性冲突（如格式、范围、明显错误）用预设规则直接裁决，快速一致；2) 证据权重——对"哪个答案更可信"的冲突，按来源可信度、置信度、时间戳等证据权重判定，可量化；3) 仲裁 Agent——规则与证据无法覆盖的复杂/主观冲突，交由仲裁 Agent 综合裁决。优先级由低到高：规则 → 证据权重 → 仲裁。保持可解释：1) 记录冲突各方的观点、证据与来源；2) 记录裁决依据（用了哪条规则/哪个权重/仲裁理由）；3) 输出时附带"为什么这样选"的解释；4) 裁决过程可回放审计。可解释性是关键，无论哪种方式，都要让最终结论能追溯"冲突是什么、为什么这么解决"。

冲突解决是"确定性 → 量化 → 综合"的升级路径。可解释性贯穿始终：记录冲突与裁决依据，让结果可追溯、可审计、可改进。不可解释的裁决即使正确也难以信任。

• 理解错误目标扩散的风险
• 理解预算、深度、超时边界
• 理解熔断与隔离

防止错误目标在协作网络中无限扩散，需设置三层边界：1) 预算边界——总 token、单任务成本上限，超限即熔断，防止错误目标无限消耗资源；2) 深度边界——最大委派/调用深度（Agent 最多能再委派几层），防止错误目标沿调用链无限下沉；3) 超时边界——单跳超时与总时长上限，超时即终止，防止错误目标无限执行。此外：1) 目标校验——在委派前校验目标是否在授权/能力范围内，发现异常目标即拒绝；2) 熔断——当某个 Agent 反复产出错误或消耗超限时，熔断其后续调用；3) 隔离——把错误目标限制在局部，避免影响全局。核心是"成本、深度、时间都有硬上限，让错误目标的扩散在边界处被截断"。

一个错误目标若被无限委派，会引发"扩散爆炸"。预算/深度/超时是三个硬闸门，配合目标校验与熔断，把错误的影响限制在有限范围内，避免灾难性扩散。

• 理解暴露为 Agent 与工具的选择标准
• 理解任务级 vs 工具级抽象
• 理解安全与受控边界

能力划分标准：1) 暴露为远程 Agent（A2A）——需要协商、异步、多步、状态管理、跨组织协作的能力，能独立完成一个"任务"，且需要与其他 Agent 交互；2) 保留为受控工具（MCP）——确定性、原子、短时、可同步调用的能力，属于内部底层能力，不需要暴露给外部 Agent。受控工具应保留在内部：1) 涉及敏感/内部数据的能力（避免暴露给外部 Agent）；2) 需要强权限控制、审计的能力；3) 不具"任务"语义的底层操作。判断原则：对外协作、任务化、独立 → A2A；对内、原子、受控 → MCP。同时保留"能力网关"——即使暴露为 Agent，也要对内部工具调用做鉴权与审计，防止外部 Agent 通过 A2A 间接调用敏感工具。

暴露面越大风险越大。A2A 暴露的是"任务级接口"，MCP 保留的是"工具级能力"。选择标准是"任务性 + 是否需对外协作 + 是否敏感"，敏感与内部能力应留在 MCP 受控层并加鉴权。

• 理解端到端评估的维度
• 理解通信轮数、成功率、错误传播、成本指标
• 理解评估方法与基准

端到端评估需在统一任务集上衡量四个维度：1) 通信轮数——统计每次任务完成的 Agent 间交互轮数，衡量协作效率与噪声度；2) 任务成功率——端到端完成率与质量达标率，衡量整体有效性；3) 错误传播——统计错误从源头 Agent 传播到下游并在最终结果显现的比例，衡量鲁棒性（理想是错误被拦截而非传播）；4) 单任务成本——每个任务消耗的 token、时间与费用，衡量经济性。评估方法：用固定测试集 + 统一评估标准，记录 trace 计算各指标，交叉对比不同方案（如单 Agent vs 多 Agent、不同编组）。综合看"质量/成功率是否值得成本与轮数"，错误传播率是质量红线。评估要可重复、可对比，形成基准。

端到端评估是"效率 + 质量 + 成本 + 鲁棒性"的多维平衡。通信轮数反映效率，成功率反映有效，错误传播反映鲁棒，成本反映经济。四维同测才能判断多 Agent 方案是否整体更优。

• 理解替代 Agent 的选择策略
• 理解降级为人工的触发条件
• 理解返回部分 artifact 的语义

编排需定义分级降级策略：1) 选择替代 Agent——主 Agent 失败/超时后，按能力匹配、历史成功率、负载选择替代 Agent 重试，设重试上限；2) 降级为人工——替代 Agent 也失败、或任务涉及高风险/高价值/无法自动决策时，升级给人工处理，并附上已完成的部分与上下文；3) 返回部分 Artifact——不可能完整完成时，返回已完成的 artifact 与失败说明，标记"部分完成"，让调用方/用户决定是否接受。选择依据：按失败类型（超时/内容错误/权限不足）与任务价值决定路径——低风险可自动替代，高风险降人工，部分结果明示保留。关键是要"可预期地降级"：明确在什么条件下走哪条路，并记录降级原因。

降级不是失败，而是"有计划的备选路径"。替代/人工/部分 artifact 是三种由轻到重的降级，按风险与价值选择，并保留部分结果与上下文，让任务即使不完美完成也有明确归宿。