4.3 任务分配、协调与冲突解决策略

4.3 任务分配、协调与冲突解决策略

多 Agent 一起干活，谁牵头？意见不合听谁的？这一节讲协作里的"组织问题"——它们不写在框架 API 里，却决定系统能不能成事。

任务分配：指定牵头还是自由认领

两种方式：

• 指定牵头：你明确让某个 Agent 当 coordinator，它负责拆任务、派活。可控，适合流程清楚的任务。
• 自由认领：谁觉得该自己上就让 Manager 选谁。灵活，适合探索型。

我们判断：任务边界清楚就指定牵头，省得群里互相客气没人动手。

from autogen import ConversableAgent, GroupChat, GroupChatManager
import os
cfg = {"model": "gpt-4o-mini", "api_key": os.environ.get("OPENAI_API_KEY")}

coordinator = ConversableAgent("coord", llm_config=cfg,
                               system_message="你是协调者，负责拆解任务并指派。")
worker1 = ConversableAgent("w1", llm_config=cfg, system_message="你做前端。")
worker2 = ConversableAgent("w2", llm_config=cfg, system_message="你做后端。")

group = GroupChat(agents=[coordinator, worker1, worker2], messages=[],
                  max_round=8, speaker_selection_method="auto")
mgr = GroupChatManager(group=group, llm_config=cfg)
mgr.initiate_chat(coordinator, message="做一个登录页，前后端分工。", max_turns=8)
​

协调机制：共享白板

多 Agent 协调最怕"各说各话"。一个实用办法是设一块"共享白板"——用一条固定格式的消息（比如 JSON）记录当前进度和决议，所有 Agent 都读它。这比靠自然语言互相猜状态稳。

# 用共享消息约定进度格式，避免各说各话
board = {"stage": "design", "owner": "w1", "done": []}
# 每轮开头把 board 放进对话，Agent 据此知道自己该干嘛
​

冲突解决：让一个裁判 Agent 拍板

当 reviewer 说"这代码不行"而 coder 坚持"没问题"，别让它们吵到 max_round。加一个 arbitrator（裁判）Agent，专门在分歧时出现做最终决定。

arbitrator = ConversableAgent("arb", llm_config=cfg,
    system_message="当两方分歧，你依据事实和测试结论拍板，给出最终方案。")
# 把它加入 group，并在 system_message 里告诉其他 Agent 分歧时找 arb
​

工程取舍

• 指定牵头 = 快但可能漏掉好想法。
• 自由认领 = 全但可能拖延。
• 裁判 Agent = 解决死锁，但多一次调用成本。

我们主张：小任务直接指定牵头；复杂且易分歧的任务加裁判；探索期才放开自由认领。

一个共享白板的代码示意

白板用一条固定格式消息记录进度，所有 Agent 都读它，避免各说各话。

# 共享白板：每轮开头把当前状态作为一条消息注入
board = {"stage": "design", "owner": "w1", "done": []}

def publish_board(sender):
    msg = {"role": "user",
           "content": f"[白板] 阶段={board['stage']} 负责人={board['owner']} 已完成={board['done']}"}
    # 发给所有 worker，让它们基于同一状态行动
    for w in [worker1, worker2]:
        sender.send(msg, w)
# 比起靠自然语言互相猜，白板让协调显式、可调试
​

冲突的真实例子

coder 说"我用列表存"，reviewer 说"该用字典"，tester 无所谓。没人拍板时，coder 可能按自己来，tester 按字典写测试，于是测不过——典型的"接口不一致"死锁。加 arbitrator 后，它看 tester 的测试基于字典，就裁定"用字典"，coder 改，顺畅收尾。这种裁决价值在省掉多轮无谓往返。

协调失败的两种典型

一种是"没人牵头"——群聊里大家等对方先动，max_round 用完啥也没产出。解法是显式指定 coordinator。另一种是"抢着牵头"——两个 Agent 都觉得自己该干，重复劳动还互相覆盖。解法是白板声明 owner，谁认领谁做。这两种失败都源于"责任没写清"，而非模型不行。所以协调问题，七成靠设计、三成靠模型。

规模与协调成本

角色越多,协调开销越大——每个新 Agent 都多一份"它知不知道别人在干啥"的同步成本。我们经验:4 个角色内协调可控,超过就考虑拆成"群套群"或退回顺序流程。别被"多 Agent 更智能"误导,协作有边际收益递减,到某个点再加角色反而更乱。这个拐点因任务而异,但存在是确定的。

冲突预防优于冲突解决

与其等分歧出现再裁,不如在 prompt 里先划好边界:谁负责哪类决定、超出范围找谁。预防做在前,仲裁 Agent 很少被触发,协作更顺。我们给每个角色写"职责清单"时,顺手标"不归我管的找 X",很多潜在冲突在源头消失。

协调能力的成长性

随着你对某类任务越做越熟,可以把"协调逻辑"从动态协商固化成固定流程——比如发现某任务总是 writer 先、reviewer 后,就写成顺序对话(4.1),省掉群聊开销。协调不是越动态越好,而是越"刚好够"越好。这是从探索到稳定的必经之路。

本节要点回顾

• 分配有指定牵头和自由认领两路，按任务清晰度选。
• 共享白板减少"各说各话"。
• 分歧靠裁判 Agent 拍板，避免吵到上限。

⚠️ 群里没牵头又没裁判，容易陷入"互相客气没人动手"或"吵到 max_round"，两种都产不出结果。

💡 协调策略是"对话即编排"里的组织设计——技术框架管不了谁拍板，得你来定。