在 JiuwenSwarm 这类多 Agent 协作框架里，任务依赖通常应当写在「编排层的任务定义」中：由前置任务 id 和后置任务的输出引用字段共同描述先后关系，Agent 自身不负责判断谁先运行、谁该等待。如果你现在的做法是在 Agent 的提示词里写「等 Agent A 返回后再继续」，实际就在依赖模型自行判断，Agent 之间互相等待或集体卡住也就很自然了。判断方向是：先把依赖从提示词搬到任务声明，再用日志确认前置输出确实传到了后置 Agent 的输入。

适用场景：多个 Agent 协作时互相等输出、最后一起卡住，分不清是依赖没声明还是执行超时。操作动作：用两个 Agent 的最小任务复现一次，记录各自开始和结束时间；把先后关系改写成显式声明；在日志里比对前置输出片段与后置输入片段。验证方式：看后置 Agent 的开始时间是否晚于前置结束时间，以及传入片段是否一致。风险边界：字段名和引用语法以你所用仓库的文档为准，本文给出的只是通用骨架，不能直接当作官方接口。

复现一次互相等待的协作任务

先别改配置，先确认等待发生在哪一环。用两个 Agent 的最小任务跑一次：Agent A 只做一件有明确输出的短任务，比如返回一段固定文本；Agent B 的输入引用 A 的结果。跑之前把两边的开始时间、结束时间和状态都记下来，状态取值按你框架里的实际状态名记录，比如 pending、running、waiting、done、failed。

# 观察窗口，按你的日志路径替换
watch -n 1 'date +%T; grep -E "agent_a|agent_b|status" /path/to/swarm.log | tail -5'

记录表建议至少留三列：Agent、开始时间、结束时间、最终状态。如果两个 Agent 几乎是同时进入 running，之后长时间都没有新输出，最后一起失败，这通常说明依赖没有被读取，两个任务被当成互不相关的并行任务调度了。如果 A 正常结束，B 一直停在等待状态，或者 B 在 A 结束之后才开始跑，那依赖大概率是生效的，剩下的问题是传参或者超时。

把先后关系写成显式声明

依赖由声明决定，不靠 Agent 自己判断。下面是一段通用骨架，字段名（depends_on、outputs、inputs 这类）需要你按仓库文档核对，没有文档依据的字段不要硬写，否则不会报错，但会被静默忽略，这也是最常见的排查干扰源。

tasks:
  - id: step_a
    agent: agent_a
    outputs:            # 输出名，字段名以仓库文档为准
      text: result
  - id: step_b
    agent: agent_b
    depends_on: [step_a]        # 前置任务 id
    inputs:
      raw: ${step_a.outputs.text}   # 输出引用，语法以文档为准

要检查的点有：depends_on 是否写在任务层级，而不是塞进 inputs 或 metadata；引用里的任务 id 是否和上面的 id 完全一致；前置任务是否真的声明了对应的输出名。改完之后不要立刻跑完整流程，先用这两个最小任务验证一次。

用输出引用验证依赖传参

依赖生效不等于参数传对。打开后置 Agent 实际收到的输入，和前置 Agent 实际的输出做一次比对，最直接的办法是抓两段特征片段比字符串。

grep -n "step_a.*output" /path/to/swarm.log | tail -3
grep -n "step_b.*input"  /path/to/swarm.log | tail -3

不一致时优先看这几个错位位置：一是引用路径的层级写错，比如输出挂在 result 下却按 text 取；二是前置声明了输出名 A，后置引用的是 B；三是插值没生效，后置输入里原样出现了 ${step_a.outputs.text} 这种字面量；四是多个前置任务里有同名输出，取到了另一个任务的值；五是后置 Agent 复用了上一次运行的缓存结果，看上去「有值」，其实是旧的。第五种用改一次前置输出内容、看后置是否跟着变来排除。

区分依赖等待超时和执行超时

这两类超时的日志表现不同，改错配置会白花时间。依赖等待超时：后置任务长时间停在等待状态，日志里找不到该 Agent 的调用记录或模型请求记录，最终在调度侧报出等待超时。这类要调的是依赖等待或任务调度层面的超时值。执行超时：Agent 已经开始，日志里能看到请求发出、有部分输出，然后在某个固定时长上被截断，报错里通常带的是调用侧的超时。这类要调的是 Agent 调用或工具调用的超时值，同时检查前置任务本身的耗时是否已经超过了给它的时间预算。

做一次验证操作来确认：临时把前置任务改成一个明确耗时较长但不失败的动作（比如固定等待一段可控时间），再跑一次。如果后置任务等不到前置结束就报超时，问题在依赖等待；如果前置自己先失败，问题在执行时长预算。

把协作任务临时改串行再改回并行

这是验证依赖声明是否真被读取的最省事办法。先按声明并行跑一次，记录 B 的开始时间相对 A 结束时间的关系；再把依赖改掉、让两个任务互不引用，按固定顺序串行跑一次，记录同样两项。串行只是验证手段，不是优化方案，验证完要改回并行。

对比结果这样读：改回并行后，如果 B 的开始时间稳定晚于 A 的结束时间，且 B 的输入片段和 A 的输出一致，说明依赖声明被读取了；如果改回并行后 A、B 又开始同时进入 running，B 的输入与 A 输出无关，那说明依赖没有生效，优先回头核对 depends_on 的层级和字段名拼写。执行时长和整体耗时只作参考，不要在改串行、改并行之间做任何耗时结论。