多Agent协作中的死锁与循环：AutoGen消息调度机制与冲突解决实践

Xie Zhi 2026-08-05 14:25

想象一下，你拉了个工作群，里面有几个机器人同事。你让它们一起写个方案，结果一分钟过去，群里静悄悄；再一看，机器人甲和乙已经互相“你说得对，你先请”三百回合了，机器人丙一直没说话。这种场面，就是多Agent协作里最吓人的死锁与循环。AutoGen是微软出的一套多Agent开发框架，它内部有一套消息调度的逻辑，把这道逻辑吃透，你就能避开这些大坑。

一、消息调度：Agent之间靠什么通信

先别急着看代码，我们把AutoGen里面的消息想象成“快递”。每一个Agent都是一个驿站，它收到一个快递，会看看能不能处理，能处理就产出一个新快递，投递到下一个驿站；不能处理就搁置，甚至把快递退回去。驿站之间互相不直接“打电话”，而是通过递送快递来完成信息交流。

1.1 回复函数“接龙”

Agent收到消息后，会执行一个叫做回复函数列表的东西。这个列表里按顺序放了好几个函数，每个函数决定“这个活儿我接不接”。接的条件通常由开发者定。比如收到内容包含“报价”的消息，只有财务Agent会接。如果列表里所有函数都说不接，Agent就哑巴了。AutoGen里用register_reply可以把自定义函数塞到这个列表里。

举一个最简单的例子，让一个Agent专门处理“报价”这个词：

# 技术栈：Python + AutoGen
import autogen
from autogen import Agent, ConversableAgent

# 自定义回复规则
def my_reply_rule(recipient, messages, sender, config):
    # recipient：收到消息的Agent；sender：发消息的Agent
    # messages：之前所有聊天记录，最后一条在 messages[-1]
    if "报价" in messages[-1]["content"]:
        # 如果消息里带“报价”二字，就返回 (True, 回复内容)
        return (True, "我给你报个价")
    # 否则表示不接这个活儿
    return (False, None)

# 创建一个不连大模型的Agent，避免烧钱
agent = ConversableAgent(name="财务", llm_config=False)
# 把规则注册进去，任何Agent发来的消息都会先过一遍这个规则
agent.register_reply([Agent, None], my_reply_rule)

这个例子看起来简单，但它是整个调度机制的地基。你会在后面看到，所有死锁和循环，都是因为这一条条“回复规则”串在一起时没设计好。

1.2 为什么会出现互相等待

AutoGen里常见的调用是“同步”的：A调用B的generate_reply方法，B算完再返回给A。问题在于，如果A把自己下一步的动作绑定在B的结果上，而B又把自己下一步的动作绑定在A的结果上，两个Agent就这么干瞪眼。这就好比两个人吃饭时互相鞠躬，你不动我不动，谁都不敢先坐下。在计算机世界里，这叫死锁；在聊天气氛里，这就是尴尬的沉默。

二、死锁和循环的现场还原

为了把问题讲清楚，我们写一个能跑通的示例。你不需要真的接大模型，因为问题本身跟“聪明程度”无关，纯靠逻辑就能聊死。

2.1 互相客套的“死循环”

下面这个例子，两个Agent被我们变成了“太平绅士”。A收到任何话都回“你先请，我等你”，B收到任何话都回“你说得对，请你继续”。理论上它们可以聊到天荒地老，直到系统资源被耗光。

# 技术栈：Python + AutoGen
import autogen
from autogen import Agent, ConversableAgent

# 定义一个“客套话”回复函数
def polite_reply(recipient, messages, sender, config):
    # recipient 是收到消息的Agent，sender 是发消息的Agent
    if recipient.name == "A":
        # A 永远表示谦让
        return (True, "你先请，我等你")
    elif recipient.name == "B":
        # B 永远表示赞同
        return (True, "你说得对，请你继续")
    else:
        # 其他情况不处理
        return (False, None)

# 创建两个不接模型的 Agent
agent_a = ConversableAgent(name="A", llm_config=False)
agent_b = ConversableAgent(name="B", llm_config=False)

# 给两个 Agent 都注册客套话规则
agent_a.register_reply([Agent, None], polite_reply)
agent_b.register_reply([Agent, None], polite_reply)

# A 主动发起对话，最多交互 6 轮，你能看到它俩如何“礼尚往来”
agent_a.initiate_chat(agent_b, message="开始聊吧", max_turns=6)

这段代码跑起来之后，对话会变成这个样子：A说“开始聊吧”，B说“你说得对，请你继续”，A说“你先请，我等你”，B又说“你说得对，请你继续”……每一轮都没有新信息，只是单纯地把球踢来踢去。如果去掉max_turns这个参数，它们会一直聊到程序崩溃。这种是典型的“活锁”或者“循环等待”——看起来谁都没停，但实际上什么事情都没做成。

2.2 群聊里的“集体沉默”

除了两两对话，群聊里更常见的是死锁。GroupChat里面有一个Manager负责选下一个发言者。如果它用默认的auto方式让LLM选择，可能LLM觉得A和B还在聊，自己不适合插嘴，于是一直选A或者B，C就永远没机会说话。还有一种更糟的情况：Manager要求所有Agent提交“想不想发言”的意愿，但Agent们都在等别人先表态，结果Manager收不到任何意愿，整个群聊就干脆卡死。这种场景就像开会时主持人说“大家有意见吗？”，然后所有人低头看手机，谁都不第一个开口。

三、解决冲突的几种实用招数

别怕，AutoGen给你准备了好几个“脱困”旋钮。

3.1 设置轮次上限，强制刹车

最简单粗暴的办法就是限制聊天轮数。initiate_chat里有max_turns参数，表示最多交互多少轮；ConversableAgent里也有max_consecutive_auto_reply，限制一个Agent连续自动回复多少次。给“话痨Agent”加上这个参数，它说够三轮就得闭嘴。

# 技术栈：Python + AutoGen
from autogen import ConversableAgent

# 给Agent加上自动回复次数限制
agent_a = ConversableAgent(
    name="A",
    llm_config=False,
    max_consecutive_auto_reply=2,  # 最多连续自动回复2次
)

agent_b = ConversableAgent(
    name="B",
    llm_config=False,
    max_consecutive_auto_reply=2,
)

这样即使A和B都装了客套话规则，连续互相回复两次之后，其中一个会自动停手。整个流程虽然还是会走几轮，但不会再无限循环，你也能在日志里看出是哪个Agent先“闭嘴”的。

3.2 换一种“选人规则”

群聊卡壳很多时候是因为选发言人太自由。你可以把speaker_selection_method设成round_robin，让Manager按固定顺序轮流点名，这样每个人都有说话机会，谁也不被冷落。还可以设random，或者干脆写一个自定义函数，专门做仲裁。

# 技术栈：Python + AutoGen
from autogen import GroupChat, GroupChatManager, ConversableAgent

# 创建三个不接模型的Agent
agent_a = ConversableAgent(name="A", llm_config=False)
agent_b = ConversableAgent(name="B", llm_config=False)
agent_c = ConversableAgent(name="C", llm_config=False)

# 创建一个群聊，使用round_robin轮流发言
group_chat = GroupChat(
    agents=[agent_a, agent_b, agent_c],
    messages=[],
    max_round=6,                        # 最多6轮，防止无限循环
    speaker_selection_method="round_robin",  # 轮流点名发言
)

# 群聊管理器负责执行调度
manager = GroupChatManager(
    groupchat=group_chat,
    llm_config=False,   # 这里不接大模型，纯规则调度
)

这个配置会让每个Agent都得到发言机会，不会出现“某个人从头到尾一句话不说”的情况。对于需要平衡各方视角的任务，轮流发言往往比自由发言更稳。

3.3 给对话加一个“终止符”

好的协作应该懂得收场。我们可以在回复函数里判断，如果上一轮的消息还是那句套话，就不再继续，而是直接总结。或者定义一个is_termination_msg，让Agent学会识别“结束”信号。

# 技术栈：Python + AutoGen
from autogen import Agent, ConversableAgent

def polite_reply_with_stop(recipient, messages, sender, config):
    # 如果最近一条消息是客套话，就直接收场
    if messages and messages[-1]["content"] in ("你先请，我等你", "你说得对，请你继续"):
        return (True, "好吧，那就到这里吧，我先去忙了。")
    # 否则继续客套
    if recipient.name == "A":
        return (True, "你先请，我等你")
    else:
        return (True, "你说得对，请你继续")

agent_a = ConversableAgent(name="A", llm_config=False)
agent_a.register_reply([Agent, None], polite_reply_with_stop)

这段代码的核心逻辑很简单：一旦发现对方又在“踢皮球”，就主动喊停。虽然这个终止方式有点生硬，但在关键任务里，生硬一点总比无限循环好。

3.4 超时和重试，防止“鬼打墙”

真实世界还有网络波动，模型服务也可能抽风。给模型请求设置超时时间，超过就重试几次，再不行就跳过。AutoGen的llm_config配置里可以放timeout和max_retries。

# 技术栈：Python + AutoGen
import autogen
from autogen import ConversableAgent

config_list = [{
    "model": "gpt-4o-mini",
    "api_key": "your-api-key",   # 替换成你自己的key
    "base_url": "https://api.openai.com/v1",
    "timeout": 30,               # 单次请求30秒超时
    "max_retries": 2,            # 最多重试2次
}]

agent = ConversableAgent(
    name="带超时的Agent",
    llm_config={"config_list": config_list},
)

这样做的好处是，即使某一个Agent因为网络问题卡住了，其他Agent也不会跟着一直傻等。超时在分布式系统里是个老话题，在多Agent协作中同样好用。

四、这些招数背后的“道理”

其实死锁这个概念来自计算机操作系统。它有几个必要条件：互斥、持有并等待、不可剥夺、循环等待。放在多Agent场景里，对应关系很清楚。互斥就是每个Agent独占自己的回复规则；持有并等待就是Agent已经拿到一条消息，还在等着别人发新消息；不可剥夺就是你没法强制一个Agent立刻给结果；循环等待就是我们看到的A等B、B等A。明白了这一点，你就知道前面那些解法为什么有用：限制轮次打破了循环等待，终止条件相当于主动释放资源，超时重试相当于在等待时另开一条新路。

五、应用场景与优缺点

5.1 什么时候值得用多Agent

多Agent不是炫技。遇到一个任务可以被拆成多个角色并行协作时，用它很爽。比如做一个产品发布方案，让“市场调研”、“文案策划”、“风险合规”三个Agent各自出意见，再由一个“总结Agent”汇总。或者你想模拟一场商务谈判，让两个Agent分别扮演买卖双方，看看谈判会走向什么结果。这种场景下，多Agent能帮你快速体验不同“人设”的碰撞，还能暴露出很多你预想不到的细节。

5.2 不能回避的缺点

缺点也很明显。第一，Agent之间的对话完全依赖自然语言，结果不稳定，可能这次成功下次就翻车。第二，调试起来非常费劲，你往往不知道到底是哪个Agent的哪句话导致了死锁。第三，每次调用大模型都有成本，如果陷入循环，账单会很感人。第四，消息顺序一旦错乱，整个协作就崩了，所以必须有强约束。你不应该把所有希望寄托在“大模型很聪明”这件事上，它也会犯糊涂。

六、注意事项：给想踩坑的人

如果你正准备写一个多Agent应用，下面几条建议多少能帮你少掉几根头发。

开始写代码之前，先把Agent的角色边界定义清楚，别让两个Agent都管同一件事。职责重叠是产生循环回复的重要原因。
所有消息最好都带一个ID或者序号，方便追踪是谁先说的、哪条消息触发了哪条回复。没有追踪手段，死锁问题只能靠猜。
给每个Agent都设置自动回复次数限制，哪怕你觉得它很乖。人尚且会失控，何况是接了大模型的Agent。
不要迷信LLM的自觉，显式的终止条件比任何“聪明的判断”都可靠。宁可在规则里写死“遇到客套话就停”，也不要指望它自己领悟。
群聊中尽量用轮询或规则来选择发言人，不要完全交给自由竞争。自由竞争在理想状态下效率高，但容易翻车。
先跑通一个小规模实验，再扩展到真实业务。先用两个Agent试，再用五个，看看消息量增长后会不会出现新的卡壳点。

七、总结

多Agent协作里的死锁和循环，本质上是对消息调度缺少约束。AutoGen给了你很多调节旋钮：轮次上限、连续回复上限、发言选择规则、终止条件、超时重试。用好了，你的Agent团队就能高效协作；用不好，它们就是一群复读机或者装死的机器人。希望这篇文章能让你在调试Agent时，少掉几根头发，多写几行稳的代码。记住，Agent只是工具，真正的调度逻辑还是要靠你来设计。

围绕“多Agent协作中的死锁与循环：AutoGen消息调度机制与冲突解决实践”参与讨论

0 条

多Agent协作中的死锁与循环：AutoGen消息调度机制与冲突解决实践

一、消息调度：Agent之间靠什么通信

1.1 回复函数“接龙”

1.2 为什么会出现互相等待

二、死锁和循环的现场还原

2.1 互相客套的“死循环”

2.2 群聊里的“集体沉默”

三、解决冲突的几种实用招数

3.1 设置轮次上限，强制刹车

3.2 换一种“选人规则”

3.3 给对话加一个“终止符”

3.4 超时和重试，防止“鬼打墙”

四、这些招数背后的“道理”

五、应用场景与优缺点

5.1 什么时候值得用多Agent

5.2 不能回避的缺点

六、注意事项：给想踩坑的人

七、总结

评论

关联文章

AI助手

一、消息调度：Agent之间靠什么通信

1.1 回复函数“接龙”

1.2 为什么会出现互相等待

二、死锁和循环的现场还原

2.1 互相客套的“死循环”

2.2 群聊里的“集体沉默”

三、解决冲突的几种实用招数

3.1 设置轮次上限，强制刹车

3.2 换一种“选人规则”

3.3 给对话加一个“终止符”

3.4 超时和重试，防止“鬼打墙”

四、这些招数背后的“道理”

五、应用场景与优缺点

5.1 什么时候值得用多Agent

5.2 不能回避的缺点

六、注意事项：给想踩坑的人

七、总结

同分类面试题

关联文章

AI助手