9.7.6 多 Agent 挑战与解决

学习目标

理解多 Agent 系统最常见的失败模式
学会把问题拆成通信、协调、成本、质量几类
看懂一个最小冲突与去重示例
理解为什么多 Agent 的关键往往不是更聪明，而是更可控

为什么多 Agent 系统更容易出问题？

单 Agent 最常见的问题

单 Agent 常见问题通常是：

推理错了
工具选错了
输出不稳定

多 Agent 会额外多出一层系统复杂度

除了个体 Agent 自己会犯错，多 Agent 还会新增这些问题：

两个 Agent 做了重复工作
同一条消息被不同 Agent 不同理解
子任务完成了但主任务没收敛
成本和时延一层层叠加

也就是说：

多 Agent = 单体智能问题 + 分布式协作问题。

这也是为什么它听起来更强，但做起来往往更脆。

最常见挑战一：重复劳动

为什么容易重复？

只要任务边界不够清楚，就容易出现：

规划者派了一次
执行者又自己再检索一次
审核者还重复做了同样的检查

一个最小示例

tasks_done = []

def run_task(agent, task):
    tasks_done.append((agent, task))

run_task("retriever_a", "检索退款政策")
run_task("retriever_b", "检索退款政策")

print(tasks_done)

预期输出：

[('retriever_a', '检索退款政策'), ('retriever_b', '检索退款政策')]

这个例子很简单，但已经说明：

如果没有去重机制，多 Agent 很容易“表面很忙，实际在浪费”。

一个最小修复思路

assigned = set()
tasks_done = []

def run_task_once(agent, task):
    if task in assigned:
        return f"{agent}: 跳过，任务已有人处理"
    assigned.add(task)
    tasks_done.append((agent, task))
    return f"{agent}: 执行 {task}"

print(run_task_once("retriever_a", "检索退款政策"))
print(run_task_once("retriever_b", "检索退款政策"))
print(tasks_done)

预期输出：

retriever_a: 执行 检索退款政策
retriever_b: 跳过，任务已有人处理
[('retriever_a', '检索退款政策')]

最常见挑战二：消息失真和状态不同步

为什么会失真？

因为 Agent 间传递的不是“真实世界”，而是：

文本消息
JSON 消息
中间状态

一旦消息格式不统一、字段不清楚，系统很容易出现：

我以为你说的是 A
你其实表达的是 B

一个例子

message_a = {"task": "查退款", "detail": "只看对外政策"}
message_b = {"task": "查退款", "detail": "包括内部客服规范"}

print(message_a)
print(message_b)

预期输出：

{'task': '查退款', 'detail': '只看对外政策'}
{'task': '查退款', 'detail': '包括内部客服规范'}

这两个消息只差一点，但对结果影响很大。如果系统不约束消息协议，后面很容易走偏。

一个工程经验

只要系统里开始出现：

task
detail
context
notes

这类语义模糊字段，就要警惕通信设计是否已经开始松动。

最常见挑战三：冲突结论怎么收敛？

多 Agent 很容易得出不同结论

例如：

法规 Agent 认为“可以”
业务规则 Agent 认为“不可以”

这不是异常，而是常态。

一个最小冲突示例

results = {
    "policy_agent": {"decision": "allow", "confidence": 0.72},
    "risk_agent": {"decision": "deny", "confidence": 0.88}
}

print(results)

预期输出：

{'policy_agent': {'decision': 'allow', 'confidence': 0.72}, 'risk_agent': {'decision': 'deny', 'confidence': 0.88}}

冲突解决至少要明确一个规则

最简单也最常见的规则有：

置信度优先
审核者最终裁决
监督者最终裁决
保守优先（高风险任务常用）

例如一个保守优先版本：

继续在同一个文件或解释器会话中运行，确保上一段里的 results 已经定义。

def resolve_with_safe_bias(results):
    decisions = [r["decision"] for r in results.values()]
    if "deny" in decisions:
        return "deny"
    return "allow"

print(resolve_with_safe_bias(results))

预期输出：

deny

如果你不设计收敛规则，系统就会变成：

多个 Agent 都很努力，但没人能拍板。

最常见挑战四：成本和时延指数上升

为什么多 Agent 容易更贵？

因为每多一个 Agent，通常就多一层：

推理成本
上下文拼接
状态传递
工具调用

一个很直观的例子

agents = [
    {"name": "planner", "cost": 0.002, "latency_ms": 400},
    {"name": "researcher", "cost": 0.003, "latency_ms": 700},
    {"name": "writer", "cost": 0.004, "latency_ms": 900},
    {"name": "reviewer", "cost": 0.002, "latency_ms": 500},
]

total_cost = sum(a["cost"] for a in agents)
total_latency = sum(a["latency_ms"] for a in agents)

print("total_cost =", total_cost)
print("total_latency_ms =", total_latency)

预期输出：

total_cost = 0.011
total_latency_ms = 2500

如果这些步骤还是串行执行，整体时延会更明显。

一个非常重要的工程判断

很多时候，多 Agent 最大的问题不是质量不够，而是：

质量提升 10%，但成本和时延翻了 3 倍。

所以你必须有意识地问：

这一步真的值得保留吗？
能不能合并两个角色？
能不能只在高风险任务上触发审核者？

最常见挑战五：系统不可观测

为什么这是大坑？

多 Agent 一旦出错，如果你只看到最终答案，大概率根本不知道：

哪个 Agent 出错了
错在通信、分配还是工具层
是谁第一次把系统带偏的

最低限度也要记录这些信息

task_id
agent_name
action
input summary
output summary
延迟

一个最小 trace 示例：

trace = [
    {"task_id": "t1", "agent": "planner", "action": "decompose", "latency_ms": 120},
    {"task_id": "t1", "agent": "retriever", "action": "search_docs", "latency_ms": 350},
    {"task_id": "t1", "agent": "writer", "action": "draft", "latency_ms": 480}
]

for item in trace:
    print(item)

预期输出：

{'task_id': 't1', 'agent': 'planner', 'action': 'decompose', 'latency_ms': 120}
{'task_id': 't1', 'agent': 'retriever', 'action': 'search_docs', 'latency_ms': 350}
{'task_id': 't1', 'agent': 'writer', 'action': 'draft', 'latency_ms': 480}

没有这类 trace，多 Agent 系统的调试难度会非常高。

最常见挑战六：角色边界漂移

什么叫角色边界漂移？

本来：

规划者负责拆任务
撰写者负责写答案

但系统慢慢变成：

规划者也开始检索
撰写者也开始判断任务优先级

最后每个角色都越来越像“全能 Agent”。

为什么这很危险？

因为这会让：

分工变模糊
调试变困难
责任边界消失

所以多 Agent 系统要经常回头检查：

这个 Agent 的职责是不是已经越界了？

一个更实际的“挑战清单”

如果你在做多 Agent 系统，下面这份清单非常实用：

问题	常见症状
重复劳动	多个 Agent 做同一件事
消息失真	同一任务不同理解
冲突不收敛	多种结论没人拍板
成本太高	角色太多、每步太长
状态不同步	有人基于旧信息继续工作
无法调试	只看到最终输出，看不到中间过程

多 Agent 挑战控制结果图

解决思路不是“更复杂”，而是“更清楚”

很多人遇到问题的第一反应是：

再加一个协调 Agent
再加一个裁判 Agent
再加一个总结 Agent

但多 Agent 系统真正更稳的方向，往往不是继续堆角色，而是：

消息更清楚
分工更清楚
终止条件更清楚
观察手段更清楚

也就是说：

多 Agent 的修复，很多时候不是“继续加复杂度”，而是“把边界重新画清楚”。

留下的证据

学完这一页，至少保留这张证据卡：

角色: 负责人、执行者、评审者，或专家职责
消息契约: artifact、request、response 和交接状态
协同: 路由、任务拆分、冲突解决和最终负责人
失败检查: 重复工作、上下文丢失、没有明确负责人或消息循环
评估动作: 将多 Agent 结果与单 Agent 基线对比

小结

这一节最重要的不是把挑战列个清单，而是理解：

多 Agent 系统真正难的地方，不在单个 Agent 能力，而在系统整体是否可收敛、可观测、可控。

一旦你能从“重复、冲突、成本、观测”这四类问题去看多 Agent，系统调优就会清楚很多。

练习

给本节的冲突解决逻辑再设计一个“审核者拍板”的版本。
想一想：如果一个多 Agent 系统总是重复检索，你会优先改任务分配、通信协议还是共享状态？
设计一份你自己的多 Agent 追踪结构，至少包含 task_id、agent、action、latency_ms。
用自己的话解释：为什么多 Agent 系统出问题时，很多时候不是“模型太弱”，而是“系统边界不清”？

参考实现与讲解

“reviewer 最终裁决”设计中，每个 Agent 提交结论、证据和不确定性。reviewer 按标准比较它们，选择或合并答案，并记录裁决理由。
如果系统反复检索同一信息，优先检查 shared state 和 communication protocol。Agent 可能不知道哪些内容已经检索过，也不知道证据存在哪里。
有用的 trace 可以包含 task_id、agent、action、input_ref、output_ref、latency_ms、status、error。涉及判断时还应加 evidence references。
很多失败来自边界不清：谁负责这个任务、什么证据算数、什么时候停止、谁做决定。更强模型无法完全弥补糟糕的组织循环。