n8n 工具执行成功，Agent 却说没结果：先查 executionOrder
工具记录有数据，n8n Agent 的 observation 却为空？核对同一次调用、旧执行顺序与读取时机，并在副本中验证 v1，避免重复执行写操作。
工具自己的执行记录显示成功，也有返回数据，n8n 的 AI Agent 却回答“工具没有返回结果”。反复让它再试，可能只会把同一个动作做第二遍。
遇到这个组合，先核对同一次工具调用的结果和执行顺序，尤其是旧工作流里的 settings.executionOrder。近期一个具体报告在 v0 下观察到 Agent 先继续回答、工具后执行；换成 v1 的副本则收到了结果。这个线索值得检查，但不能用来解释所有空结果。
本文资料核对日期为 2026-11-09，正式版查询返回 n8n 2.46.6。我们核对了该标签的相关源码并运行局部函数，没有启动完整 n8n、调用真实模型或复现生产工作流。初次配置模型入口，可先按 n8n 接入 Nbility 的入门文章完成基本连接，再用本文检查工具往返。
先确认空的是哪一层
AI Agent 的 Return Intermediate Steps 选项可以把中间步骤放进最终输出，入口与含义见官方 Tools Agent 文档。只在受控测试中保存必要数据，中间步骤可能包含工具参数和业务信息。
区分这几种现象：
| 看到的内容 | 优先核对什么 |
|---|---|
| 普通模型回复没有正文 | 是否正在调用工具、是否读错协议字段；可先看空响应排查 |
intermediateSteps 没有对应工具调用 | Agent 是否真的选择了工具，是否查看了正确执行记录 |
有对应调用，但 observation 是两个引号字符 | Agent 看到的工具结果怎样生成，读取时工具是否已完成 |
| 工具自己的结果确实为空 | 工具输入、查询条件和业务数据，而非直接修改执行顺序 |
报告里提到的两个引号，在 JSON 文件中表示为：
{
"observation": "\"\""
}
它是字符串里包含两个引号，与 null、没有字段、或返回对象中某个值为空并不相同。2.46.6 的结果序列化函数会在没有可用的首组 ai_tool 项目、也没有错误时返回 JSON.stringify('')。因此，真正的空结果和某些尚未填入结果的记录，都可能落到这个表示。
我们用该版本的原始函数做了离线检查：缺少数据与空项目数组都得到上述两个引号；返回项目是 {"response":""} 时，得到的是包含该对象的数组文本；明确的工具错误则得到错误对象文本。这些结果只能说明函数如何处理给定输入，无法单独证明线上是哪一步出了问题。
查旧工作流的 executionOrder
打开工作流右上角菜单，进入 Settings → Execution order。官方工作流设置把 v1 标为推荐选项，并把 v0 标为旧方式。
两者还会改变普通分支的执行顺序：
| 设置 | 多分支工作流的执行方式 |
|---|---|
v0 | 先执行各分支的第一步，再执行各分支的第二步 |
v1 | 完成一个分支，再执行下一个分支；分支顺序与画布位置有关 |
这也是为什么不能直接把生产工作流的开关改掉就算修完。旧图可能依赖原来的分支顺序；要先在副本中核对条件分支、汇合、循环和外部写操作。新旧方式的适用背景见官方执行顺序说明。
如果手头只有导出的工作流 JSON，可以用下面的 Python 3 代码读取字段。它兼容单个工作流对象和工作流数组，不打印节点、参数或凭据，也不修改文件：
import json
from pathlib import Path
data = json.loads(
Path("workflow.redacted.json").read_text(encoding="utf-8")
)
workflows = data if isinstance(data, list) else [data]
for index, workflow in enumerate(workflows):
settings = workflow.get("settings") or {}
print(json.dumps({
"workflow_index": index,
"executionOrder": settings.get("executionOrder", "not set"),
}))
导出中没有字段时，继续查看界面的有效设置、版本与实际执行记录；不要仅凭缺失字段推断它一定采用 v0 或 v1。升级程序和迁移旧工作流设置也要分别检查。
结束后的成功记录，为什么还不够
n8n Issue #38870最初报告工具有结果、Agent 的 observation 却为空。作者后来确认实际使用 2.34.5，更正了正文开头过时的 2.31.4。
11 月 8 日，另一位用户补充了 2.46.6、自部署、regular 模式下的对照：在一个小工作流中只改变 executionOrder，v0 时工具在 Agent 的最后一次模型调用结束后才开始；v1 时工具先执行，Agent 得到非空 observation。这是该用户的报告，本文没有重新运行它的完整环境，也没有采用其毫秒数作为本站测量。
我们同时核对了正式版的调度准备代码及其队列调用路径：请求工具后，Agent 需要再次进入执行队列。v0 与 v1 的入队方式不同，会影响 Agent 续接与工具的先后关系。对调度准备函数的离线执行、配合明确标注的简化入队模拟，得到了同方向的顺序差异；这仍不是完整引擎测试。
要定位自己的情况，关联同一个工具调用编号，并核对它实际指向的工具节点和那一次运行。Agent 可能反复调用同名工具，只比较节点名称容易看错记录。
保存后的工具记录有数据，只能证明在保存时看到了它。它无法单独证明 Agent 当时读取的结果也有数据。需要进一步比较对应工具运行、Agent 续接运行的 executionIndex 和时间；画布上的节点位置，以及执行面板的一眼排序，都不能代替这一步。
原报告描述间歇出现，并提到延迟的影响；后来的 v0 对照则描述确定出现。原作者的实际执行顺序尚未在讨论中确认，不能把两组现象直接归为同一个根因。截至查阅时，Issue 仍开放；后续回复讨论了调度修补和显式错误提示，并未据此确认正式修复已经发布。
在副本中验证，再迁移正式工作流
先保存原工作流和失败记录，再创建不会接收生产事件的测试副本。不要让真实通知、工单或数据库写操作参与第一轮验证。
- 缩小到一次只读工具往返。 保留一个 Agent、所需模型和一个返回公开固定信息的只读工具。例如让工具返回“演示退货期为 7 天”，再要求 Agent 先调用工具后回答。
- 确认工具确实被调用。 同一次执行中应有工具记录和对应中间步骤。Agent 没调用工具就给出答案，不能算这条路径已通过。
- 记录原设置下的结果。 保存版本、
executionOrder、对应调用编号、工具输出是否存在、observation 的类型与长度，以及执行顺序。不要对外分享完整 payload。 - 若原设置为
v0，只在副本中改为v1对照。 保持输入、模型和工具一致，观察工具是否先完成、结果是否进入对应 observation、最终答案是否使用了公开返回值。 - 恢复原图的分支后再检查。 核对分支、汇合、循环与写操作的顺序，确认结果符合业务要求后，再按团队流程迁移正式工作流。
如果本来就是 v1，或切换后仍为空，继续检查工具是否真的返回了项目、Agent 关联的是哪次工具运行，以及结果进入 Agent 前的结构。不要为了套上这个案例，把所有问题都归给旧执行顺序。
工具可能已经写入时，先查结果
Agent 说“没拿到结果”，不足以决定再次创建工单、发送邮件或更新记录。先用业务对象编号查询外部系统，确认那次动作有没有发生，再决定是补交结果还是重新执行。
正式自动化还需要稳定的业务编号和下游实际支持的去重机制。一次新的 n8n execution ID 或工具 call ID，只标识新的运行或调用，不能自动保证外部操作只发生一次。瞬时网络错误的重试与退避，也需要与这里的结果读取问题分开处理。
接入 Nbility 时，可以按连接基础确认实际模型与路径，并在用量日志关联对应模型调用。它们有助于查清模型请求是否完成；n8n 如何调度工具、何时读取 observation，仍要在 n8n 的执行记录中检查。恢复的目标是确认同一次工具结果被正确交给 Agent，并核对业务动作的真实状态。
