Skip to main content

9.7.6 多 Agent 挑战与解决

本节定位

前面几节你已经看到，多 Agent 可以分工、通信、协调。 但真正把系统做起来以后，你会发现一个现实：

多 Agent 的难点，不在“能不能多开几个 Agent”，而在“系统什么时候开始失控”。

这一节就是专门讲“失控点”的。

学习目标​

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

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

单 Agent 最常见的问题​

单 Agent 常见问题通常是：

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

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

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

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

也就是说：

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

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

最常见挑战一：重复劳动​

为什么容易重复？​

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

  • planner 派了一次
  • worker 又自己再检索一次
  • reviewer 还重复做了同样的检查

一个最小示例​

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}}

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

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

  • 置信度优先
  • reviewer 最终裁决
  • supervisor 最终裁决
  • 保守优先（高风险任务常用）

例如一个保守优先版本：

继续在同一个文件或解释器会话中运行，确保上一段里的 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 倍。

所以你必须有意识地问：

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

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

为什么这是大坑？​

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

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

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

  • task_id
  • agent_name
  • action
  • input summary
  • output summary
  • latency

一个最小 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 系统的调试难度会非常高。

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

什么叫角色边界漂移？​

本来：

  • planner 负责拆任务
  • writer 负责写答案

但系统慢慢变成：

  • planner 也开始检索
  • writer 也开始判断任务优先级

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

为什么这很危险？​

因为这会让：

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

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

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

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

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

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

多 Agent 挑战控制结果图

先排查控制信号

在继续增加 Agent 之前，先看问题是不是来自重复劳动、消息失真、冲突不收敛、成本叠加，或缺少 trace 记录。

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

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

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

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

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

也就是说：

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

小结​

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

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

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

练习​

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