源码与实测拆解多 Agent 交接机制

多 Agent 都配置好了，任务却可能在第一个 Agent 结束后就被标记为完成。dev.to 的一篇源码分析基于 Strands Agents 1.63.0 和运行记录，拆解了这种现象：节点通过工具调用请求交接；没有交接，运行时就结束任务。这里的「完成」，与交付物是否生成是两回事。

目前能确认什么

作者在单进程、三个 Agent、同一个模型的实验中，安排 researcher 读取输入、calculator 汇总并计算费用、writer 生成简报并保存。这个实验用于观察机制，不能代表生产环境的表现。

节选中的源码显示，每个节点都有 handoff_to_agent 工具。模型通过调用它选择交接对象；节点结束后，运行时检查交接状态，有目标就继续执行，没有就标记为 COMPLETED。

标题里的「没人决定下一个是谁」，并非没有路由决策，而是决策落在各节点模型的工具调用中，没有一个集中持有计划的调度组件。

作者给出的两次运行都返回 completed：一次依次执行三个节点并保存结果；另一次只让入口节点回答一句话、不调用工具，后续节点便没有运行，也没有生成交付物。

这里的 completed 表示执行流程结束，不能证明业务任务已经完成。

我的判断

如果你用这类机制搭建研究、计算、写作流水线，只检查最终状态，很容易漏掉「成功结束但没有产物」的情况。验收应落到具体结果：文件是否保存、必需字段是否齐全、需要执行的计算是否真的发生。

排查提前结束时，可以先看节点历史和交接工具调用记录。没有发起交接，与交接后执行失败，需要分开定位。

摘要还提到交接依赖发起请求的节点，但现有节选没有完整展开这条路径。节点超时或异常时，交接请求如何处理、能否恢复，仍需完整源码分析或官方文档确认。现有实验也不足以判断并发场景和生产负载下的行为。