Agent receives incorrect output when a tool workflow includes a webhook Wait node

问题场景

用户在 n8n 中搭建了一个顶层工作流，其中包含一个 Agent 节点，该 Agent 通过“工具”方式调用多个子工作流。其中一个子工作流内含 webhook Wait 节点，用于等待来自 Slack 的用户反馈。当子工作流执行到 Wait 节点并进入等待状态、之后被恢复执行时，顶层 Agent 无法正确接收子工作流的最终结果。

具体表现为：Agent 的 output 属性为 undefined，同时 Agent 的 JSON 输出与子工作流中 Wait 节点的输出完全一致。此外，这一问题还会影响 Agent 之后的其他节点。

复现路径（来自 Issue）：

1. 创建一个含简单 Agent 实现的顶层工作流；
2. 创建一个子工作流，其中包含 webhook wait 节点，后面再接任意其他节点（例如 Code 节点）；
3. 把该子工作流作为工具提供给顶层工作流中的 Agent；
4. 触发顶层工作流，在 Wait 节点进入执行范围后解除阻塞，观察 Agent 的输出。

报错原文

Agent receives incorrect output when a tool workflow includes a webhook Wait node

The agent's `output` property is `undefined`, and its JSON output is identical to the wait node's output from the sub-workflow.

It appears that including a webhook Wait node in one of the tools disrupts the agent's execution. The wait node's output overrides the agent's output once the tool execution is concluded.

Expected behavior: The top-level agent should wait until the sub-workflow is done executing end-to-end, and should take the output from the last executed node as normal.

原因分析

讨论中给出的一种可能原因是：子工作流从 Wait 节点恢复后，Agent 的输出上下文没有被正确恢复——恢复后的执行可能回到了与 Agent 所等待的作用域不同的作用域。社区评论将其描述为“工作流引擎充当 Agent 运行时”时的典型难点：在执行中途挂起再恢复会破坏 Agent 的状态连续性。

此外，维护者指出 webhook wait 会让执行进入 suspended 状态，这种状态下无法继续与 canvas chat 或 hosted chat 交互，需要改用 Using response nodes 响应类型并通过 Chat 节点手动发送响应。但该说明是否直接解释本 Issue 中“Wait 节点输出覆盖 Agent 输出”的现象，讨论中并未确认。

需要注意：这些都属于“可能原因”，Issue 最终被关闭时并没有给出经过验证的根因结论。

环境排查

• 确认 n8n 版本：报告版本为 2.10.2，维护者称在 n8n v2 起 Agent 应能正常获取工作流结果，可在 v2 及以上版本复测。
• 确认 Node.js 版本：报告版本为 24.13.1。
• 确认数据库类型：报告使用 PostgreSQL。
• 确认部署与执行模式：报告为 self-hosted / docker，executionMode 为 main（默认），生产环境为 scaling (single-main)。
• 确认 Wait 节点触发方式：是 webhook 触发恢复，还是 time-based 恢复（维护者曾专门询问这一点，报告者未在讨论中明确回答）。
• 确认响应方式：是否使用 Using response nodes 响应类型，并通过 Chat 节点手动发送响应。
• Issue 中未提供操作系统版本、CUDA、显卡等信息，无需在本问题中排查。

解决步骤

1. 先确认 Wait 节点的触发类型：分别用 webhook wait 与 time-based Wait 测试同一个子工作流，判断问题是否只出现在 webhook 触发恢复的场景（维护者明确问过这一区分，但 Issue 中没有结论）。
2. 在 Agent 使用子工作流作为工具时，检查子工作流是否在 Wait 节点之后仍有实际执行节点（例如 Code 节点），并观察 Agent 收到的是哪个节点的输出。
3. 如果使用的是 webhook wait，按维护者建议改用 Using response nodes 响应类型，并通过 Chat 节点手动发送响应，而不是依赖 canvas chat / hosted chat 的后续交互。
4. 在 n8n v2 及以上版本重新验证该工作流，因为维护者表示在 v2 中无法复现该问题。
5. 如果仍然能稳定复现，准备一个最小可复现工作流并附上执行记录：包括顶层 Agent 工作流、作为工具的子工作流、Wait 节点配置，以及 Agent 输出为 undefined 的执行数据，再向 n8n 提交新 Issue 或重新打开原 Issue。本 Issue 中报告者曾提供稳定复现的反馈并要求现场调试，但最终因长期无活动被关闭。

验证方法

触发顶层工作流，在子工作流执行到 Wait 节点后完成恢复，检查 Agent 节点的 output 是否为子工作流最后一个执行节点的结果，而不是 undefined，同时确认 Agent 的 JSON 输出不再是 Wait 节点的输出。还应检查 Agent 之后的下游节点是否恢复了正常数据传递。

参考来源

n8n-io/n8n #26820

AI 工具推荐

想把多个 AI 模型放在一个入口？

GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。

了解 GamsGo AI

推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。