多个智能体互相等消息，通常不是模型本身没返回，而是两件事之一：任务拆解把两个智能体写成了互相依赖的环，或者交接消息里没写清「谁交给谁、交什么、什么时候算完成」。建议先把「等待」拆成编排层和智能体内部两层来看，再看依赖结构，最后看消息字段，顺序别反——直接去改提示词往往只是让循环换了个位置继续转。
判断方向：先看编排日志里每个智能体的 waiting_on 指向，能快速区分是结构问题还是某个智能体内部卡住；接着画依赖图查环，用交接模板补齐交付物与完成标志；最后加轮次上限和超时，把不可见的等待变成可报错的事件。这些改动只影响可观测性和约束条件，不承诺缩短单次模型响应时间，阈值需要结合自己的环境确认。
先分清卡在编排层还是某个智能体内部
第一步是把范围缩小。编排层通常有调度事件或任务流水，智能体内部则是各自的对话轮次、工具调用记录。两处日志要按同一组字段对齐看，才能判断等待发生在哪一层：
- task_id / trace_id：把两边日志串起来，确认看的是同一次执行；
- round：第几轮派发，用来判断是否还在推进；
- agent_id 与 waiting_on（或 blocked_by）：当前在等谁；
- last_message_type：最近一条是 request、reply 还是 ack；
- status：waiting / running / done / failed；
- 时间戳：等待开始时间和最后一次投递时间。
如果编排日志里两个智能体的 waiting_on 互相指向对方，而中间没有新的消息投递记录，问题就在交接或依赖结构上，往下看第二节和第三节。如果某个智能体的 round 长时间不增加、工具调用没有返回、最后一条输出也不是明确的完成信号，那就是它内部卡住，先单独查这个智能体的调用链和外部依赖，别急着改编排。
检查任务拆解有没有形成互相依赖的环
依赖关系可以直接画：每个智能体画成一个点，A 需要 B 的输出才能继续，就画一条 A 指向 B 的边。画完盯着 arrows 看谁指回谁，比在对话记录里翻要快得多。用日志里的 waiting_on 字段批量生成这组边最省事。
识别环有两个可操作的判断方法。一是顺链走：从任意一个处于 waiting 状态的智能体出发，沿 waiting_on 一直往下读，如果走回了起点，就是环，路径上每个智能体都属于环内节点。二是做拓扑排序：把所有依赖边排一遍，排完后仍然剩下的节点，就是互相等待、没有入度为 0 起点的那些。
# 通用骨架：按 waiting_on 建图后做一次拓扑排序
edges = [(a, waiting_on[a]) for a in agents if waiting_on.get(a)]
indeg = {a: 0 for a in agents}
for u, v in edges:
indeg[v] += 1
queue = [a for a in agents if indeg[a] == 0]
seen = 0
while queue:
u = queue.pop()
seen += 1
for x, y in edges:
if x == u:
indeg[y] -= 1
if indeg[y] == 0:
queue.append(y)
stuck = [a for a in agents if indeg[a] > 0] # 非空即为环内节点
print(stuck)排到环之后，处理方式是打断其中一条边：把「等对方给全量结果」改成「先拿一个最小可用的中间产物」，或者把两个智能体的职责重新拆成先后两个阶段。这里改的是任务结构，不是提示词措辞。
对齐交接消息的三个要素
环排除掉之后，剩下最常见的现象是：A 已经发出去了，B 收到了却不知道该干什么，于是回一句「请确认」，A 又开始等。交接消息要能独立成立，至少写清三件事：谁发起并交给谁、要交付什么、什么算完成。
{
"task_id": "task-001",
"from": "researcher",
"to": "writer",
"deliverable": "结构化要点列表，每条含结论和出处标记",
"done_when": "writer 输出完整段落且每条结论都能对应到一条要点",
"max_rounds": 3,
"deadline_ms": 60000
}- 谁发起：from / to 加上 task_id，保证接手方能回溯上下文；
- 要交付什么：写清产物的形态和边界，比如「要点列表」而不是「一些资料」；
- 完成标志：必须是接手方自己就能判断的条件，不要写「做好后告诉我」这种需要对方再确认的表述。
如果接收方的实现里有字段校验，可以直接把 deliverable 和 done_when 设为必填；没有校验的话，至少在提示词里把这两项固定为输出结构的一部分，出现缺失就在编排层打一条告警事件。
加轮次上限和超时，让卡住变成可见的失败
互相等待最难受的地方是它不报错。加两个约束就够了：每个任务允许的最大往返轮次，以及单个智能体的单轮超时。配置项的命名各框架不同，下面是通用写法，替换成自己环境的字段名即可。
orchestration:
max_rounds: 6
agent_timeout_ms: 60000
on_round_limit: fail_and_report
on_timeout: fail_and_report触发后的预期行为要写清楚，否则等于没配：轮次到达上限时，任务状态置为 failed，原因记为轮次超限，同时向事件日志写入一条包含 task_id、参与智能体和 waiting_on 的记录，并停止继续派发；单轮超时则记录一条超时事件，带上具体 agent_id 和它最后等待的对象。这样原来「一直转」的状态就变成了一条可检索的失败记录。阈值不要照抄，需要结合任务粒度和模型响应情况确认。
用同一任务复跑，确认等待消失
验证不要换输入，换输入就分不清是改动生效还是任务变简单了。用同一份任务描述、同一组智能体配置复跑一次，按下面几步走：
- 复跑前先记下基线：上一次卡住的轮次、总耗时、结束状态；
- 用相同输入重新提交，观察编排日志里每轮的 waiting_on 是否还出现互指；
- 记录完成轮次、总耗时和最终状态；
- 检查日志里有没有轮次超限或超时的提示。
判定标准：结束状态为 done，完成轮次明显少于配置上限且不再持续增长，日志中不再出现两个智能体互相等待的同轮记录，也没有超限提示，说明等待已经消除。若复跑后仍然触发超限提示，说明环或字段缺失还没解决，回到第二节重新看依赖图，而不是继续调提示词。