Multi-Agent 系统：拓扑、通信与结果不一致的裁决

五种协作拓扑 · 三层通信机制 · 冲突消解四级阶梯 · MAS 特有失效

名词速查

首次阅读可跳过本表，直接看「场景问题」，遇到生词再回查。

本篇是多 Agent 协作这一组名词的归属页。这一组词对后台工程师格外友好——它本质上是分布式系统那套问题在 Agent 上重演一遍：服务编排、消息中间件、共享状态一致性、脑裂裁决、级联故障，你都见过。区别在于每个"节点"都会自信地胡说八道。

篇幅较长，按 spec 拆成两张表：本篇自有名词（完整版）与引用自其他上下文（只给去处）。

本篇自有名词

本篇引用的其他上下文名词

场景问题

一个内容审核流程：主 Agent A 收到一条待审内容，分别问两个下游——B（规则检索 Agent，查审核规则库）和 C（案例检索 Agent，查历史判例）。

B 回来说：「该内容违反 3.2 条，应下架。」
C 回来说：「历史上 4 起同类内容全部判为『通过，加提示标签』。」

A 现在拿着两个矛盾的结论。它做了最自然的事——把两段话都塞进自己的上下文，然后问模型「综合判断」。模型输出：「建议下架并加提示标签。」

这个输出是荒谬的（下架了还加什么标签），但它没报错、格式合法、看起来还挺全面。这就是 MAS 最典型的坏法：冲突没被消解，只被拼接了。

再往下看一层，问题更细：

• B 说的「3.2 条」和 C 说的「同类内容」，是不是真的同一类？没人验证过。
• C 说的「4 起」是什么时间范围？如果规则 3.2 是上个月新增的，那 4 起判例全部作废——这是时序冲突，不是事实冲突，两者的处理方式完全不同。
• 假如再叫来一个 D 投票？D 和 B 都是同一个模型跑的，会犯同向错误。投票只会让错的那边变成 2:1。

这篇要回答的就是：拓扑怎么选、信息怎么流、结论冲突时听谁的。

实现方案

维度一：五种协作拓扑

拓扑决定「谁能指挥谁、谁等谁」。五种，按工业实践频率排序：

规模锚点：上表的「实际上限」是指单任务内同时活跃的 Agent 数，前提是每个 Agent 有独立上下文窗口。超过上限时的信号不是崩溃，而是「Planner 的上下文里 Worker 回复占比 > 60%」——此时 Planner 已经在做摘要工作而不是决策工作。

三种主要拓扑的消息流向对比：

维度二：三层通信机制

打个比方：这三层就是你搭微服务时选的那三种通信方式——RPC 直连（点对点，知道对方是谁）、Kafka/消息队列（发出去就不管，谁订阅谁消费）、共享数据库/Redis（不互相说话，都往同一份状态里读写）。耦合度从高到低，可观测性也从高到低。类比失效边界：微服务之间传的是结构化 payload，接收方按 schema 解析，传多少就是多少；Agent 之间传的消息要进对方的上下文，于是有两件事变了——一是它会占预算且随 Agent 数平方增长，二是接收方是模型，它会对同一段文本做自己的解读，传过去的不一定是收到的。所以这里的选型压力不只是耦合度，更是 token 与语义保真度。

拓扑说的是「谁跟谁」，通信机制说的是「怎么传」。三层，从松到紧：

1. 消息传递

三种寻址方式，耦合代价递减：

2. 共享状态（黑板）

黑板不是"一个 dict"。它是一个带并发语义的存储，最少要有三样东西：

// 黑板：结构化共享状态，非自由文本。
// 关键在 Version —— 没有它，两个 Agent 的并发写必然丢一个。
type Blackboard struct {
    mu      sync.RWMutex
    entries map[string]Entry
}

type Entry struct {
    Key     string
    Value   any
    Version int64  // 乐观锁：写入时必须带上读到的版本
    Author  string // 谁写的 —— 冲突归因时唯一的线索
    WroteAt time.Time
}

var ErrStaleWrite = errors.New("blackboard: stale write, re-read and retry")

// CompareAndSwap：读到 v3 就必须以 v3 提交，否则拒绝。
// 拒绝后 Agent 必须重读 —— 而不是覆盖。
func (b *Blackboard) CAS(key string, expectVer int64, val any, author string) error {
    b.mu.Lock()
    defer b.mu.Unlock()

    cur, ok := b.entries[key]
    if ok && cur.Version != expectVer {
        return fmt.Errorf("%w: key=%s want=%d got=%d (held by %s)",
            ErrStaleWrite, key, expectVer, cur.Version, cur.Author)
    }
    b.entries[key] = Entry{
        Key: key, Value: val, Version: expectVer + 1,
        Author: author, WroteAt: time.Now(),
    }
    return nil
}

三个必须有的性质：

• 版本号 / 乐观锁：没有它，两个 Agent 并发写同一 key 必然丢一个写，且不会报错——这是 MAS 最难查的 bug 之一。
• Author 字段：冲突发生后要归因「这个结论是谁写的」，没有 author 就只能靠猜。
• 结构化而非自由文本：黑板存 {"protagonist": {"name": "林", "age": 28}}，不存「主角叫林，28 岁」。自由文本的黑板等于让每个 Agent 重新做一次信息抽取，抽取偏差会累积。

3. 控制权交接（Handoff）

交接是"我做不了，你来"，与派单的区别在于控制权真的转移了——交出去之后自己不再等待结果。

交接时的关键决策是带什么、不带什么：

交接必须幂等，因为交接消息可能重发（网络重试、调度器崩溃恢复、上游超时后误判失败而重发）。如果不幂等，同一个子任务会被下游执行两遍——如果它带副作用（发一条消息、扣一次费），就是真实事故。

令牌三段构成 task_id + from + seq，缺一不可：

// HandoffToken：三段缺一不可。
//   task_id 定位是哪个任务（跨任务的同名子任务不能互相去重）
//   from    定位是谁交接的（同一任务里 B→D 和 C→D 是两次不同交接）
//   seq     定位是第几次（同一对 Agent 之间可能多次交接）
type HandoffToken struct {
    TaskID string
    From   string
    Seq    int
}

func (t HandoffToken) Key() string {
    return fmt.Sprintf("%s/%s/%d", t.TaskID, t.From, t.Seq)
}

type HandoffGuard struct {
    mu   sync.Mutex
    seen map[string]Result // 已执行过的交接 → 上次的结果
}

// Accept：重复交接直接返回上次结果，不重新执行。
func (g *HandoffGuard) Accept(t HandoffToken, exec func() Result) Result {
    g.mu.Lock()
    if prev, dup := g.seen[t.Key()]; dup {
        g.mu.Unlock()
        return prev // 幂等：副作用只发生一次
    }
    g.mu.Unlock()

    r := exec()

    g.mu.Lock()
    g.seen[t.Key()] = r
    g.mu.Unlock()
    return r
}

三段里最容易被漏掉的是 from：只用 task_id + seq 时，同一任务里 B→D 的第 1 次交接和 C→D 的第 1 次交接会撞成同一个 key，第二次被当成重复而静默跳过——一个子任务凭空消失，且日志上看不出来。

矩阵：拓扑 × 通信机制

这是本篇的主骨架。两维不是自由组合——同一拓扑配不同通信机制，失效模式完全不同。只填工业实践里真会遇到的格：

空缺的格子（❌ / ⚠️ 标注）不是没想到，是这些组合在语义上冗余或自相矛盾——上表已逐格给出理由。

维度冲突时的裁决规则

规则：以一致性要求为先。需要强一致的共享状态，就不能用广播消息传递，必须走黑板 + 版本号。

具体冲突就在上表 Blackboard × 消息传递 那一格。看一个例子——三个 Agent 协作写一份剧本，需要共享「主角当前年龄」这个设定：

• 走广播消息：Agent X 广播「主角改成 32 岁」。问题是广播没有版本语义——如果 Y 在收到广播前已经基于 28 岁写了一段，它的输出就是脏的，而且没有任何机制能发现。更糟的是，如果 Y 和 Z 同时各广播一个新年龄，最终状态取决于消息到达顺序，不可复现。
• 走黑板 + CAS：X 读到 age@v3，以 v3 提交 32。Y 同时也想改，它读到的是 v3，提交时被 ErrStaleWrite 拒绝，被迫重读拿到 v4=32，再决定要不要改。冲突从"静默丢写"变成"显式报错"——这就是全部的收益。

对照另一个方向的冲突，Supervisor × 黑板 vs Supervisor × 消息传递：

一句话记法：消息传递的失效是吵（吵到爆窗），黑板的失效是静（静悄悄丢数据）。选黑板就必须付版本号这笔钱。

冲突消解：可判定的四级裁决阶梯

打个比方：这套阶梯就是你值班时的故障定级与升级流程——P3 先让自动化重试一把（看能不能自己好）、P2 值班的人查日志判一下、P1 拉群把相关方叫齐、P0 直接叫老板决策。每一级都有明确的进入判据，而且不允许跳级：不是因为流程官僚，而是因为越高级别越贵，能在低级别解决的问题上升一级就是浪费。类比失效边界：故障定级的输入是客观信号（错误率、影响面），谁都能算出同一个级别；这里的输入是两个 Agent 各自的说法，而其中一方可能在编造依据。所以这套阶梯的第 1 级不是"判断谁更可信"，而是先去外部找证据把编造的那方直接踢掉——少了这一步，后面所有级别都是在两份可能都不可信的材料之间做选择。

回到开篇的场景。B 和 C 的结论矛盾，A 该怎么办。

这道题最常见的错答法是给一串并列选项：「可以投票、可以让它们再讨论一轮、可以交给人」。并列清单不是答案，因为它没回答"什么时候用哪个"。正确的结构是有序阶梯 + 每级的进入判据。

第 0 级：先分类，再选手段

不分类就选手段，等于用治骨折的方法治感冒。四类冲突，识别特征与处理方向完全不同：

表是四类的并列定义，但真正难的是判断次序——四个问题必须按下面这个顺序问，第一个答「否」的地方就是它的类型：

<rect x="8" y="90" width="210" height="42" rx="6" fill="#1e293b" stroke="#38bdf8" stroke-width="1.5"/> <text x="113" y="108" text-anchor="middle" fill="#e0f2fe">② 双方基于同一时刻吗</text> <text x="113" y="123" text-anchor="middle" fill="#94a3b8" font-size="10">比对依据上的时间戳</text> <rect x="8" y="152" width="210" height="42" rx="6" fill="#1e293b" stroke="#38bdf8" stroke-width="1.5"/> <text x="113" y="170" text-anchor="middle" fill="#e0f2fe">③ 口径 / 单位 / 时间窗一致吗</text> <text x="113" y="185" text-anchor="middle" fill="#94a3b8" font-size="10">统计范围是不是同一个</text> <rect x="8" y="214" width="210" height="42" rx="6" fill="#1e293b" stroke="#38bdf8" stroke-width="1.5"/> <text x="113" y="232" text-anchor="middle" fill="#e0f2fe">④ 事实冲突</text> <text x="113" y="247" text-anchor="middle" fill="#94a3b8" font-size="10">至少一方错了 → 找证据复算</text> <rect x="300" y="28" width="352" height="42" rx="6" fill="#1e293b" stroke="#f97316" stroke-width="1.5"/> <text x="316" y="46" fill="#fed7aa">幻觉冲突 → 直接判负</text> <text x="316" y="61" fill="#94a3b8" font-size="10">不进入后续裁决，整条阶梯在这里就结束了</text> <rect x="300" y="90" width="352" height="42" rx="6" fill="#1e293b" stroke="#a855f7" stroke-width="1.5"/> <text x="316" y="108" fill="#e9d5ff">时序冲突 → 按时间戳取新</text> <text x="316" y="123" fill="#94a3b8" font-size="10">两边在各自时刻都对，旧结论是作废而不是「错」</text> <rect x="300" y="152" width="352" height="42" rx="6" fill="#1e293b" stroke="#a855f7" stroke-width="1.5"/> <text x="316" y="170" fill="#e9d5ff">口径冲突 → 统一口径后重算</text> <text x="316" y="185" fill="#94a3b8" font-size="10">两边可能都对，此时「选一边」本身就是错的</text> 

开篇场景的真实分类：看起来是事实冲突，实际很可能是时序冲突——如果规则 3.2 是新增的，C 的 4 起判例全部作废，根本不需要"综合判断"。

不分类的后果是具体的：把时序冲突当事实冲突处理，你会去比较 B 和 C 谁更可信，然后得出一个"B 置信度 0.8、C 置信度 0.7，听 B"的结论——碰巧对了，但理由完全是错的，下次口径反过来就会错。把口径冲突当事实冲突处理更糟：两边都对，你却强行判了一边负。

分类这一步本身要落地成一个动作：要求每个下游 Agent 的回复必须带上「依据 + 依据的时间戳 + 可溯源标识」三个字段。没有这三个字段，分类无法自动进行，只能靠人看。

第 1~4 级：阶梯与进入判据

逐级说清楚：

第 1 级 · 证据优先。 「可复算」的判定要具体：B 说"违反 3.2 条"，可复算 = 拿条款号去规则库查原文，看内容是否真的落在条款描述内。这一步能筛掉的不只是错答，还有幻觉冲突——如果 3.2 条不存在，B 直接判负，裁决在第 1 级就结束了。证据优先能解决的冲突比想象的多，因为 Agent 的冲突里相当大比例是一方在编造依据。

第 2 级 · 置信度加权。 两个坑：其一，LLM 的 self-report 置信度校准很差（普遍高估，且对措辞敏感），单用它不如不用；必须乘上一个外部观测到的历史准确率——即这个 Agent 在这类任务上过去的实际命中率，这个数字来自 评测与线上运营 的离线回放。其二，加权的结果是一个连续分数，必须设阈值把"没有明显优势"这种情况识别出来，而不是硬取较大值——0.71 vs 0.69 判 B 胜，是在把噪声当信号。

第 3 级 · 第三方仲裁。 仲裁 Agent 的 prompt 有个硬要求：只给它双方的论据，不给双方的身份和置信度。给了身份它会偏向"听起来更权威"的那个，给了置信度它会直接抄分高的那个——这两种偏差都会让仲裁退化成第 2 级。另外仲裁 Agent 最好换一个模型（不同厂商或不同规模），理由见下一节。

第 4 级 · 人工闸门。 两个触发条件写死在代码里，不由模型判断：不可逆动作（下架内容、扣费、对外发布——这层分级复用 运行时 · 危险动作三级分级）；不收敛（仲裁重试 N 次，出现同分或结论反复翻转）。「反复翻转」这个信号特别要监控——它说明输入本身是模糊的，再仲裁一百次也不会收敛，继续重试只是在烧钱。

为什么「多数投票」不在这个阶梯里

这是这道题真正的区分度所在。两条独立的原因，任一条都足以否掉它：

原因一：A/B/C 场景里实际只有 2 个投票者，2 票在数学上无法产生多数。 A 是提问者和裁决者，不是投票者；投票者只有 B 和 C。两票相反就是 1:1 平局，投票机制不产生任何结论——它需要奇数个投票者才有定义。这不是"投票效果不好"，是投票在这个场景下没有输出。想用投票就必须加一个 D，而这引出第二个问题。

原因二：同源模型的投票不独立，会把错误加权放大成"虚假共识"。 投票的全部数学基础是投票者的错误相互独立——独立时多数投票才能把准确率从 p 提升到超过 p。但 B、C、D 如果是同一个模型（同一权重、同一训练数据）的三个实例，对同一段模糊输入，它们会犯同向错误：不是随机分散地错，而是一起错到同一个答案上。

这时投票的结果是最坏的：三票一致，置信度看起来极高，但答案是错的。你不但没纠错，还把一个错答包装成了"三个 Agent 一致确认"，让下游更难质疑它。这就是虚假共识——投票把相关性误当成了独立验证。

所以阶梯的第 1 级是证据而不是投票：证据是外部的、与模型无关的，它天然独立于模型的偏差。投票只在一个前提下有效——投票者来自不同模型且各自有独立信息源，这个前提在大多数 MAS 里都不成立（通常是同一个模型换了 system prompt），所以默认不把它放进阶梯。这也是第 3 级仲裁 Agent 建议换模型的理由。

裁决时机：必须在主 Agent 装配上下文之前

这一条是把 MAS 和单 Agent 运行时接起来的关键。

裁决 MUST 在 A 装配自己的上下文之前完成，只有裁决结果进 A 的窗口。

开篇场景里 A 犯的错正是这个：它把 B 和 C 的矛盾结论都塞进了自己的上下文，然后指望模型"综合判断"。后果有两层：

1. 立刻的后果：模型面对矛盾输入时倾向于拼接而非取舍（"下架并加提示标签"），因为拼接在语言上更像"全面考虑"。
2. 长期的后果：矛盾结论一旦进了 A 的上下文，就成了 A 后续所有推理的前提——这就是 运行时 · 上下文中毒 记的那个坑。而且它比普通的上下文中毒更难清：中毒的不是一条错事实，是一对互斥事实，压缩摘要时模型会随机保留其中一条，之后你完全不知道它按哪条在推理。

所以正确的流程是：

图里那两条虚线红叉是全篇最重要的一笔：B 和 C 的原始矛盾结论没有一条直连到 A 的上下文装配。

裁决结果进 A 的窗口时，还要带上裁决理由与被否结论——但形态是「已裁决：采纳 X，因为 Y；C 的相反结论因时序作废」这样一条已闭合的事实，而不是两条待判断的开放信息。这个区别很细但很实在：前者模型不会再去权衡，后者会。

仲裁器代码骨架

把上面四级写成可执行的样子。注意 Resolve 的每个 return 都对应阶梯的一级，升级人工是一个显式返回分支，不是注释：

package arbiter

// Claim：下游 Agent 的一条结论。三个非结论字段是分类的前提 ——
// 没有 Evidence / AsOf / Traceable，第 0 级分类无法自动进行。
type Claim struct {
    Agent      string
    Conclusion string
    Evidence   string    // 依据（条款号、文档 ID、查询语句）
    AsOf       time.Time // 依据对应的状态时刻 —— 时序冲突全靠它
    Traceable  bool      // 依据能否溯源到 SSOT
    SelfConf   float64   // 模型自报置信度，校准很差，只作为第 2 级输入之一
}

type Verdict struct {
    Level    int    // 在第几级收敛（1~4），落 metric 用
    Winner   *Claim // nil 表示需要人工
    Rejected []Claim
    Reason   string // 进 A 上下文的那句话
    NeedsHuman bool
}

type ConflictKind int

const (
    KindFactual ConflictKind = iota // 事实冲突
    KindMetric                      // 口径冲突
    KindTemporal                    // 时序冲突
    KindHallucination               // 幻觉冲突
)

type Arbiter struct {
    verify     func(Claim) (ok bool, err error) // 工具复算/溯源
    accuracy   func(agent string) float64       // 历史准确率，来自离线回放
    judge      func(a, b Claim) (winner string, err error) // 换模型的仲裁 Agent
    confMargin float64 // 第 2 级的阈值，经验 0.15
    maxJudge   int     // 第 3 级最多重试次数
    irreversible func(conclusion string) bool   // 是否触发不可逆动作
}

func (r *Arbiter) Resolve(a, b Claim) Verdict {
    // ── 第 0 级：分类。不分类就选手段 = 必错。
    switch r.classify(a, b) {

    case KindHallucination:
        // 一方依据不可溯源 → 直接判负，不进入后续裁决。
        if !a.Traceable && b.Traceable {
            return Verdict{Level: 1, Winner: &b, Rejected: []Claim{a},
                Reason: fmt.Sprintf("采纳 %s：%s 的依据 %q 无法溯源", b.Agent, a.Agent, a.Evidence)}
        }
        if !b.Traceable && a.Traceable {
            return Verdict{Level: 1, Winner: &a, Rejected: []Claim{b},
                Reason: fmt.Sprintf("采纳 %s：%s 的依据 %q 无法溯源", a.Agent, b.Agent, b.Evidence)}
        }
        // 双方都不可溯源 —— 没有任何可信输入，不做自动裁决。
        return Verdict{Level: 4, NeedsHuman: true,
            Reason: "双方依据均无法溯源，无可信输入"}

    case KindTemporal:
        // 时序冲突：按时刻取新，旧结论「作废」而非「错误」——
        // 措辞很重要，写成"错误"会污染该 Agent 的历史准确率统计。
        newer, older := a, b
        if b.AsOf.After(a.AsOf) {
            newer, older = b, a
        }
        return Verdict{Level: 1, Winner: &newer, Rejected: []Claim{older},
            Reason: fmt.Sprintf("采纳 %s（依据时刻 %s）；%s 的结论基于更早的 %s，已作废",
                newer.Agent, newer.AsOf.Format("2006-01-02"), older.Agent, older.AsOf.Format("2006-01-02"))}

    case KindMetric:
        // 口径冲突：两边可能都对，不能选一边 —— 必须统一口径重算。
        // 这是唯一一个「不产出 Winner 也不需要人工」的出口：回退给调用方重问。
        return Verdict{Level: 1, Winner: nil,
            Reason: "口径不一致（统计窗口/单位不同），需统一口径后重新查询，不做优劣裁决"}

    case KindFactual:
        // 走完整阶梯。
    }

    // ── 第 1 级：证据优先。能复算的复算。
    aOK, aErr := r.verify(a)
    bOK, bErr := r.verify(b)
    if aErr == nil && bErr == nil && aOK != bOK {
        w, l := a, b
        if bOK {
            w, l = b, a
        }
        return Verdict{Level: 1, Winner: &w, Rejected: []Claim{l},
            Reason: fmt.Sprintf("采纳 %s：其依据 %q 经复算成立，%s 的依据复算不成立",
                w.Agent, w.Evidence, l.Agent)}
    }

    // ── 第 2 级：置信度加权。self-report 必须乘历史准确率。
    sa := a.SelfConf * r.accuracy(a.Agent)
    sb := b.SelfConf * r.accuracy(b.Agent)
    if math.Abs(sa-sb) > r.confMargin {
        w, l, ws, ls := a, b, sa, sb
        if sb > sa {
            w, l, ws, ls = b, a, sb, sa
        }
        return Verdict{Level: 2, Winner: &w, Rejected: []Claim{l},
            Reason: fmt.Sprintf("采纳 %s：加权置信 %.2f vs %.2f（差距超阈值 %.2f）",
                w.Agent, ws, ls, r.confMargin)}
    }

    // ── 第 3 级：第三方仲裁。隐去身份与置信度，只给论据。
    flips := 0
    var last string
    for i := 0; i < r.maxJudge; i++ {
        winner, err := r.judge(strip(a), strip(b)) // strip: 去掉 Agent 名与 SelfConf
        if err != nil {
            break
        }
        if last != "" && winner != last {
            flips++ // 结论翻转 —— 输入本身模糊，再判也不会收敛
        }
        last = winner
        if flips == 0 && i+1 >= 2 { // 连续两次同结论才算收敛
            w, l := a, b
            if winner == b.Agent {
                w, l = b, a
            }
            return Verdict{Level: 3, Winner: &w, Rejected: []Claim{l},
                Reason: fmt.Sprintf("采纳 %s：第三方仲裁连续两次一致", w.Agent)}
        }
    }

    // ── 第 4 级：人工闸门。显式返回分支，不是 TODO 注释。
    // 两个触发条件都由代码判定，不交给模型。
    why := "仲裁未收敛（结论反复翻转，输入本身模糊）"
    if r.irreversible(a.Conclusion) || r.irreversible(b.Conclusion) {
        why = "冲突涉及不可逆动作，按策略强制人工确认"
    }
    return Verdict{Level: 4, NeedsHuman: true, Reason: why}
}

三个容易写错的实现细节，都在上面代码里：

1. 时序冲突的措辞是「作废」不是「错误」。如果把旧结论记为错误，它会进入该 Agent 的历史准确率统计，把一个本来正确的 Agent 的准确率拉下来——而准确率正是第 2 级的输入。这个反馈回路会慢慢腐蚀整个裁决系统。
2. 口径冲突的出口既不是 Winner 也不是人工，而是「回退重问」。它是唯一一个可以自动修复但不产生胜负的分支，漏掉它会导致把两个都对的结论判一个负。
3. 第 3 级的收敛判定要求"连续两次同结论"，不是"跑一次就信"。跑一次的仲裁和第 2 级的加权一样脆弱，而翻转次数正是"该升级到人工"的最强信号。

任务调度、分派与结果聚合

打个比方：这一节就是你写过的任务编排器——把大活拆成 DAG、按 worker 能力或负载派单、收回结果做验收、失败了决定重试还是换台机器。Airflow、Celery、你自己那套调度框架，做的都是这件事。类比失效边界：常规编排里 worker 的产出是确定的——同样输入跑两遍结果一样，失败会明确抛错。这里 worker 是模型：它可能"成功返回"一个错答案（不抛错、格式还合法），所以验收不能省，且验收方不能是产出方；它的失败也分两类——偶发（该重试）和能力不匹配（该改派），而区分二者要看失败原因，不能一律重试。

任务分解与 DAG

多 Agent 的调度输入是一张 DAG，关键是哪条边是真依赖、哪条是假依赖：

• 真依赖（必须串行）：下游需要上游的确定性产物才能开始。分镜必须等剧本定稿——不是"最好等"，是没有剧本无法分镜。
• 假依赖（可并行）：只是书写顺序上先后，实际无数据依赖。查规则库和查历史判例之间没有依赖，串行只是因为代码是顺着写的。

判定方法很朴素：问「上游产物的内容变化，会不会改变下游的输入」。会 → 真依赖；不会 → 假依赖，拆开并行。这个判定要在编排期做（写 DAG 时），不能交给运行时的模型判断——模型倾向于保守串行，会白白丢掉并行度。

三种分派策略

默认选能力路由。它最简单、最可预测、最好调试。只有当"派给谁"这件事本身需要运行时信息才升级到后两者。

结果聚合与验收

派出去之后，谁负责验收必须显式指定，否则就是下面要讲的「责任扩散」。三条规则：

1. 验收方不能是产出方。让 Worker 自己判断自己的产物是否合格，等于没有验收——模型对自己的输出评价普遍偏高。
2. 验收标准要在派单时就给出，写进子任务的定义里（"返回必须是含 X/Y/Z 三字段的 JSON，且 X 非空"），不是产出后再临时定。
3. 验收失败要区分「重派」和「改派」：同一个 Agent 重试（可能是偶发失败）vs 换一个 Agent（可能是能力不匹配）。判据是失败原因——格式错/超时 → 重派；「我做不了这个」→ 改派。重试次数上限与退避策略复用 运行时 · 重试策略。

整体回滚边界：这是 MAS 比单 Agent 难的地方。子任务 1、2 成功且已产生副作用，子任务 3 失败——不能简单地"整体回滚"，因为 1、2 的副作用可能不可逆。可行的边界是：把有副作用的子任务尽量后置，编排成「所有只读/可回滚的先跑，不可逆的集中在最后一段」，这样失败时需要补偿的范围最小。这本质上是 Saga 模式在 Agent 编排上的应用。

拓扑无关的 Agent 接口 + 消息总线

这是"模块化可插拔"落到代码上的样子。关键性质：换拓扑不改 Agent 实现——Agent 只认识 Envelope 进、Envelope 出，完全不知道自己身处 Supervisor 还是群聊：

package mas

// Envelope：唯一的传输单元。Agent 只认识它，不认识拓扑。
type Envelope struct {
    TaskID  string
    From    string
    To      string   // 直接寻址；广播时为空
    Topic   string   // 发布订阅时使用
    Payload any
    Trace   string   // 贯穿全链路的 trace id，归因全靠它
}

// Agent：拓扑无关的最小接口。
// 注意它没有任何「向谁发送」的能力 —— 发送由总线按拓扑决定。
// 这是「换拓扑不改 Agent」的全部秘密：剥夺 Agent 的寻址权。
type Agent interface {
    Name() string
    Handle(ctx context.Context, in Envelope) ([]Envelope, error) // 返回想发出的消息
}

// Topology：决定一条消息实际投递给谁。换拓扑 = 换这一个实现。
type Topology interface {
    Route(out Envelope, registry map[string]Agent) []string // 返回收件人名单
}

type SupervisorTopology struct{ Planner string }

func (t SupervisorTopology) Route(out Envelope, reg map[string]Agent) []string {
    // Supervisor：Worker 的输出一律回 Planner，Worker 之间互不可见 —— 这就是 O(N) 的来源
    if out.From != t.Planner {
        return []string{t.Planner}
    }
    if out.To != "" {
        return []string{out.To}
    }
    names := make([]string, 0, len(reg))
    for n := range reg {
        if n != t.Planner {
            names = append(names, n)
        }
    }
    return names
}

type GroupChatTopology struct{}

func (GroupChatTopology) Route(out Envelope, reg map[string]Agent) []string {
    // 群聊：广播给除自己外所有人 —— O(N²) token 就是在这一行产生的
    names := make([]string, 0, len(reg))
    for n := range reg {
        if n != out.From {
            names = append(names, n)
        }
    }
    return names
}

// Bus：调度循环。预算与终止条件在这里，不在 Agent 里。
type Bus struct {
    agents   map[string]Agent
    topo     Topology
    guard    *HandoffGuard
    maxHops  int // 硬闸：消息传递总跳数上限，防活锁
}

func (b *Bus) Run(ctx context.Context, seed Envelope) error {
    queue := []Envelope{seed}
    for hops := 0; len(queue) > 0; hops++ {
        if hops >= b.maxHops {
            return fmt.Errorf("mas: max hops %d exceeded (可能活锁), trace=%s", b.maxHops, seed.Trace)
        }
        cur := queue[0]
        queue = queue[1:]

        for _, name := range b.topo.Route(cur, b.agents) {
            ag := b.agents[name]
            in := cur
            in.To = name

            outs, err := ag.Handle(ctx, in)
            if err != nil {
                return fmt.Errorf("mas: agent %s: %w", name, err)
            }
            queue = append(queue, outs...)
        }
    }
    return nil
}

换拓扑只需要 bus.topo = GroupChatTopology{}，六个 Agent 的实现一行不动。代价也要说清：这层抽象让"消息去哪"从 Agent 代码里消失了，调试时你不能再从 Agent 代码读出数据流向，必须去看 Topology + trace。这是可插拔的固定成本。

为什么这么做

为什么冲突消解必须是阶梯而不是策略池

策略池（"有这几种方法可选"）的问题不在于方法不对，在于它把选择权留给了运行时——而运行时的选择者是模型。让模型选"这次用投票还是用仲裁"，你就得到一个不可复现的系统：同一个冲突两次运行走了不同路径，线上出问题无法回溯。

阶梯把选择权收回到代码里的判据：能不能复算是一次工具调用的返回值，差距是否超阈值是一个减法。这两件事对同一输入永远给同一答案，所以整条裁决路径是确定性的、可回放的。落 metric 时 Verdict.Level 直接告诉你「本周有多少冲突在第 1 级就解决了、多少升到了人工」——这个分布是 MAS 健康度最直接的指标，比成功率灵敏得多。

为什么裁决要放在装配之前，而不是让模型自己权衡

反直觉的点在于：模型确实有能力识别矛盾。你给它两段冲突文本并明确问"这两段矛盾吗"，它答得很好。

但在真实的 Agent 循环里，A 的任务不是"识别矛盾"，是"完成审核"。矛盾输入只是它上下文里的一部分材料，而模型面对材料冲突的默认行为是找一个能同时容纳两者的表述——因为在语言概率上，"综合考虑 X 和 Y" 比 "Y 是错的" 更常见、更安全。于是你得到"下架并加提示标签"这种荒谬输出。

把裁决前移，本质是把一个模型不擅长的判断（在有任务压力时取舍矛盾）换成一个框架擅长的判断（按判据走阶梯）。这跟 运行时 里"不能让模型自己判断操作危险不危险"是同一个道理：不是模型能力不够，是这个判断不该由带着任务倾向的一方来做。

为什么黑板要付版本号这笔钱

不加版本号的黑板在 demo 里跑得很好——两个 Agent 很少真的同时写同一个 key。问题是这个 bug 的发生率随并发度上升而上升，而可发现性始终为零：丢写不报错、不留痕，只表现为"某个 Agent 的修改好像没生效"。

版本号买到的唯一东西是把静默失败变成显式报错。ErrStaleWrite 一抛，你至少知道发生了并发写；Agent 重读重试，语义上正确。这笔钱必须付的判据很简单：只要有两个以上 Agent 可能写同一个 key，就必须付。如果 key 空间按子任务严格划分（Agent X 只写 shot_1.*），可以不付——但那要靠命名规范保证，而规范会腐化。

为什么别的选择不行

MAS 特有的五种失效

这五种只在多 Agent 下出现，单 Agent 再怎么坏也坏不出来：

它们与单 Agent 失效的共同点：多数不报错，只表现为"结果变差"——和 运行时的三种记忆失效 一样，必须靠主动断言发现，不能等异常。

差异在于：单 Agent 的失效是纵向的（一条轨迹上前面污染后面），检测只需看一条 trace；MAS 的失效是横向的（两个 Agent 的状态互不一致），检测必须跨 trace 比对。这是 MAS 可观测性真正难的地方，也是为什么 span 必须挂同一个 Trace id（上面 Envelope.Trace）——归因手段见 评测 · span 树归因。

何时不该上 MAS

MAS 是有固定代价的：token 组合爆炸（互看输出 O(N²)）与调试面积膨胀（N 个 Agent 的状态组合 + 跨 trace 比对）。付这笔钱之前先过三条否决判据：

三条都否 → 用单 Agent + 工具，不要上 MAS：

1. 子任务之间需要并行吗？ 如果本来就是顺序执行，多 Agent 只是把一个 for 循环拆成了几个进程。
2. 需要不同的 system prompt 隔离吗？ 如果所有子任务都能在同一个 system prompt 下完成，拆成多个 Agent 只是给同一个模型换了几个名字——这是最常见的伪 MAS。
3. 需要不同的权限边界吗？ 如果所有子任务用同一批工具、同一套凭据，"多 Agent"提供不了任何隔离价值。

主流框架的核心抽象对照

只对照核心抽象，不写 API——API 半年一变，抽象不变。选型结论见 Agent 开发 · 框架对比（枢纽页给"该选哪个"），本节只给"它们各自把什么做成了一等公民"：

沉淀结论

面试常见问题清单

拓扑与通信

• Q：Multi-Agent 有哪几种协作方式，怎么选？ A：五种——Supervisor（中心调度，最常用，O(N)）、Pipeline（阶段固定）、Group Chat（需互相质疑，O(N²) 最贵）、Blackboard（长任务共享大状态）、Contract Net（学术常见工业罕见，因为出价靠模型自评而自评系统性高估）。选型看三件事：子任务边界是否清晰（清晰→Supervisor）、是否需要互相质疑（需要→Group Chat 但限轮数）、共享状态是否大（大→Blackboard）。
• Q：Agent 之间怎么通信？ A：三层——消息传递（直接寻址/广播/发布订阅，耦合递减）、共享状态（黑板，必须带版本号做 CAS）、控制权交接（Handoff，令牌 task_id+from+seq，必须幂等）。最大陷阱是消息进彼此上下文导致 token O(N²)。
• Q：拓扑和通信机制冲突时怎么裁决？ A：以一致性要求为先——需要强一致的共享状态就不能用广播（广播无版本语义，并发改同一事实会静默丢写且不可复现），必须黑板 + 版本号。一句话：消息传递的失效是吵到爆窗，黑板的失效是静悄悄丢数据。

冲突消解（高频）

• Q：A 分别问 B 和 C，两者结果有出入怎么办？ A：先分类再走四级阶梯。第 0 级分类：事实（一方错）/ 口径（两边都对，统一口径重算）/ 时序（基于不同时刻快照，取新，旧的作废不是错）/ 幻觉（依据不可溯源，直接判负）。四级阶梯：证据优先 → 置信度加权（self-report × 历史准确率，差距需超阈值）→ 第三方仲裁（换模型、隐去身份、要求连续两次一致）→ 人工闸门（涉不可逆动作，或仲裁反复翻转）。关键：裁决必须在 A 装配上下文之前完成，只有裁决结果进 A 的窗口，否则就是上下文中毒。
• Q：为什么不用多数投票？ A：两条独立原因。① A/B/C 场景实际只有 B、C 两个投票者，1:1 平局时投票在数学上没有输出，它需要奇数投票者。② 即使凑到奇数，同源模型的投票不独立，对模糊输入会犯同向错误——三票一致但全错，还把错答包装成"三方确认"，这叫虚假共识。投票的数学基础是错误独立，而这前提在同模型换 prompt 的 MAS 里不成立。所以第 1 级是证据（外部的、与模型无关）。
• Q：为什么不让 A 自己综合判断？ A：模型有能力识别矛盾，但在有任务压力时面对矛盾材料的默认行为是找一个能同时容纳两者的表述（"下架并加提示标签"）——拼接在语言概率上比否定更安全。前移裁决，是把"带任务倾向的一方做取舍"换成"框架按判据走阶梯"，与"不让模型自判操作危险"同理。

失效与选型

• Q：MAS 特有的坑有哪些？ A：五个——死锁/活锁（含礼貌性死锁：都等对方先出方案，靠 maxHops 硬闸 + 编排期 tie-breaker）、责任扩散（无人认领，靠子任务唯一 owner + 禁止无 owner 广播派单）、上下文分裂（同一事实两个版本，靠共享事实只存黑板 + 跨 Agent 一致性断言）、级联幻觉（猜测被当事实多跳传递，靠保留来源链 + 只交接已确认事实）、token 组合爆炸（改拓扑或改传递内容，没有第三条路）。共同点是都不报错；与单 Agent 失效的差异是它们是横向的，检测必须跨 trace 比对。
• Q：什么时候不该上 MAS？ A：三条否决判据全否就别上——无需并行、无需 system prompt 隔离、无需权限边界隔离。固定代价是 token O(N²) + 调试面积膨胀。典型反例：代码审查拆成安全/性能/风格三个 Agent——三条全否，单 Agent 三次不同 prompt 即可；拆开反而凭空多出"三者冲突听谁的"这个新问题。答案反转的条件：「查安全」需要独立工具权限而另两个不该有时。
• Q：Eino 和 LangGraph / AutoGen 的区别？ A：抽象层面——Eino 是 Go 的分层编排（Chain/Graph/Workflow）+ 泛型带来的编排期类型安全，上下游类型接错编译期就报；LangGraph 是显式状态图 + 全局 State（本质是黑板）+ checkpointer 内置断点续跑；AutoGen 把 GroupChat 与发言权轮转策略做成一等公民，代价是默认 O(N²)。共同缺口：没有框架内置冲突消解阶梯。

记忆口诀

• 五拓扑：Supervisor（中心 O(N)）/ Pipeline（单向）/ Group Chat（互见 O(N²)）/ Blackboard（共享态）/ Contract Net（竞标，工业罕见）
• 三层通信：消息传递（直接/广播/订阅）→ 共享状态（黑板 + CAS）→ 交接（令牌 task_id+from+seq，必幂等）
• 矩阵裁决一句话：强一致共享状态必走黑板+版本号，不走广播
• 两种失效的性格：消息传递失效是吵（爆窗，看得见）；黑板失效是静（丢写，看不见）
• 冲突第 0 级：先分类——事实（一方错）/ 口径（都对，统一重算）/ 时序（取新，旧的作废）/ 幻觉（不可溯源，直接判负）
• 四级阶梯：证据优先 → 置信度加权 → 第三方仲裁 → 人工闸门
• 投票双否：2 个投票者平局无解 + 同源模型投票不独立（虚假共识）
• 裁决铁律：裁决在装配上下文之前，只有结果进主 Agent 窗口
• MAS 五失效：死锁活锁 / 责任扩散 / 上下文分裂 / 级联幻觉 / token 爆炸——都不报错，且都是横向的（须跨 trace 比对）
• 不上 MAS 三否：无需并行 + 无需 prompt 隔离 + 无需权限隔离 → 单 Agent 加工具

内容来源

综合整理：Contract Net Protocol（Smith, 1980）的任务分派思想、AutoGen / LangGraph / CrewAI / MetaGPT / Eino 各自公开文档中的编排抽象、分布式系统的乐观并发控制（CAS / 版本号）与 Saga 补偿模式在 Agent 编排上的迁移、以及站内 Agent 运行时深水区 的单 Agent 结论。

框架生态更新快，具体 API 与参数请以官方文档为准；文中阈值（置信度阈值 0.15、仲裁连续两次一致、Agent 数上限区间）均为经验值，需按自身任务的冲突分布与成本预算重新标定。

自测：合上资料能说清楚吗？

1. A 分别问 B 和 C，拿回两个矛盾结论。完整说出你的处理流程，包括第 0 级在做什么、为什么裁决不能放在 A 推理之后。

2. 为什么不用多数投票？说出两条独立的原因，以及投票在什么前提下才成立。

3. 对比 Group Chat + 消息传递 与 Supervisor + 黑板 两种组合：各自的主要失效是什么、性质有何本质不同、分别在什么场景下选？

4. 一个「代码审查系统：安全 Agent + 性能 Agent + 风格 Agent，最后汇总」的设计，该不该上 MAS？用判据回答，并说明什么条件下答案会反转。

5. 交接令牌为什么是 task_id + from + seq 三段？去掉 from 会发生什么？