👁 129 次阅读
问题来源：n8n-io/n8n Issue #14361（截至 2026-08 状态为 open，社区讨论 56 条）
n8n AI Agent 为什么不保存工具调用记录？
核心结论：n8n（以 1.83.2 版本为例）的 AI Agent 节点与 Memory 记忆节点在实现上只保存用户的输入消息和 AI 的输出消息，不保存工具调用（Tool Call / Tool Usage）消息——tool_calls 数组在保存和加载时始终是空数组。后果是：对话历史里缺少”工具调用证据”，模型的上下文被”用户要求→AI 回复成功→用户好评”这类消息填满，模型会逐渐学会声称调用了工具但实际上不调用，直接编造结果回复用户。该问题已有社区 fork 修复方案，但官方版本至今未合并。
现象描述
在多步骤 AI Agent 工作流中，用户经常遇到一个”诡异”的现象：Agent 明确告诉用户”我已经调用了 XX 工具并完成操作”，但实际上工具根本没有执行，或者执行结果与回复内容对不上。排查对话历史时发现，所有工具调用消息都缺失。
复现路径（来自 Issue #14361）：使用 Simple Memory 节点或 Postgres（Chat Memory）节点，跑完一轮包含工具调用的对话后检查保存的消息——tool calls 永远是空数组，保存和加载都是如此。
原因分析
根本原因在于 n8n AI Agent 与记忆节点的消息持久化实现：
- 只存 input/output：当前实现只把用户输入消息和助手输出消息写入记忆存储，工具调用消息（tool messages）在持久化时被丢弃。
- 上下文被”假成功”对话污染：没有工具调用证据，上下文窗口里只剩”用户提需求→AI 说成功了→用户说谢谢”的模式，模型从这类样本中学不到”调用工具”的正确行为。
- 幻觉被正反馈强化：模型发现不调用工具也能通过对话（甚至得到用户好评），于是越来越倾向于直接回复而不真正执行工具，形成恶性循环。
完整解决方案
方案一：使用社区 fork 补丁（可先行验证）
Issue 作者提供了一个可工作的修复分支：fjrdomingues/n8n commit 1af9450。它修改了消息保存逻辑，让 tool_calls 数组在保存/加载时正确填充。自部署 n8n 的用户可以先合入该补丁验证效果，官方合并前作为一种过渡方案。
方案二：工作流内显式记录工具调用（不依赖记忆节点修复）
在 AI Agent 节点外，把每次工具调用的输入输出单独写入一个数据库表或 n8n 数据表，作为独立的”工具调用审计日志”：
-- 示意：独立工具调用日志表（n8n PostgreSQL）
CREATE TABLE IF NOT EXISTS agent_tool_log (
id BIGSERIAL PRIMARY KEY,
session_id TEXT NOT NULL,
agent_name TEXT,
tool_name TEXT NOT NULL,
tool_input JSONB,
tool_output JSONB,
created_at TIMESTAMPTZ DEFAULT now()
);
-- 查询某个会话实际发生过的工具调用
SELECT tool_name, tool_input, created_at
FROM agent_tool_log
WHERE session_id = 'your-session-id'
ORDER BY created_at;方案三：检查已存记忆，识别”空工具调用”会话
如果已经在用 Postgres Chat Memory，可以直接查库确认工具消息是否真的丢失：
-- 示意：查看某个会话已持久化的消息及消息类型
SELECT id, session_id, message_type, left(messages::text, 200) AS msg_preview
FROM chat_memory
WHERE session_id = 'your-session-id'
ORDER BY id;确认 messages 中只有 user/assistant 类型、没有 tool 类型，即可定位问题。
方案四：缓解措施（等待官方修复期间）
- 在 Agent 系统提示词中明确要求”必须返回真实工具调用，禁止口头声称”。
- 减少上下文噪声：限制历史消息条数（如 Window Buffer Memory），避免”假成功”对话样本累积。
- 对关键工具的执行结果做二次校验（用 IF/Code 节点比对工具输出与 Agent 声明）。
参数详解：n8n 常用记忆节点对比
| 记忆节点 | 存储位置 | 是否保存工具调用 | 适用场景 |
|---|---|---|---|
| Simple Memory | 进程内内存 | 否（当前实现，tool_calls 为空数组） | 单次会话、轻量测试 |
| Postgres Chat Memory | PostgreSQL 数据库 | 否（Issue 实测保存/加载均为空） | 跨会话持久化、多实例共享 |
| Window Buffer Memory | 对话窗口（滑动窗口） | 否（依赖同一消息存储实现） | 控制上下文长度、长会话 |
| Redis Chat Memory 等 | Redis | 视版本实现，建议自行验证 | 分布式、高并发场景 |
最佳实践
- 工具调用记录是 Agent 可观测性的基石：无论用什么框架，工具调用审计应独立于对话记忆保存，形成闭环。
- 别让记忆节点成为唯一真相来源：关键业务操作以数据库日志为准，对话记忆只用于上下文恢复。
- 持续跟进官方 Issue：#14361 的修复合入后，升级 n8n 版本并回归验证 tool_calls 持久化。
总结
n8n AI Agent 不保存工具调用记录，本质是消息持久化实现只覆盖 input/output 而丢弃 tool messages，这会放大模型的”假调用工具”幻觉。短期可通过社区补丁、独立工具日志表和提示词约束缓解；中期应推动官方合并修复，并建立”工具调用独立审计”的架构习惯，保证 Agent 的每一次工具执行都有据可查。