n8n 的 Agent demo 很容易跑通，真正上线却卡在跨会话记忆、高风险工具审批和发布后的可回滚上。
- 01先读摘要，判断是否与你的场景相关。
- 02再看来源，保留继续查证的路径。
- 03最后看步骤、风险和可复用动作。
很多人把 n8n AI Agent 写通后，第一版 demo 很能打，真正上线却卡在三个地方：对话记忆只在当前会话里、工具调用没有审批、发布后没人知道失败在哪里。与其急着接更多工具，不如先把 Agent 入口、持久记忆、工具审批、测试集和发布回滚串成一条完整链路。下面这套清单按生产环境顺序排，能直接套到你的工作流。
适用场景
- 你要在 n8n 里做可长期使用的客服助手、运营机器人或企业内部 Agent。
- 用户需要跨会话记住订单号、项目状态、偏好或待办事项，不能每次重讲。
- Agent 会调用发送消息、改记录、删数据等高风险工具。
- 你准备先小范围灰度，再逐步扩大权限和开放范围。
不适用场景
- 你只是临时问一次问题，不需要长期维护会话和工具链路。
- 工具边界、负责人和失败处理都还没有定，不适合直接上生产。
- 你需要实时处理超大并发，却没有先评估 n8n 部署和数据库压力。
- 你希望审批通道完全替代账号权限、数据源权限和工具本身的安全设计。
先把 n8n 的边界看清
n8n 官方文档把 Tools Agent 描述为 AI Agent node 中适合调用工具的模式。你可以在 Agent node 里连接一个或多个工具，让模型根据任务决定调用哪个工具，并把执行结果带回对话。Tools Agent 并不是唯一模式，但大多数需要实际操作的场景都会从它开始。
记忆部分，官方文档明确区分了三层。Simple Memory 最轻，只保存当前会话的一段聊天历史；Postgres Chat Memory、Redis Chat Memory、MongoDB Chat Memory 这类节点可以把历史存到外部服务，用来实现跨会话记忆；Chat Memory Manager 则适合需要注入消息、检查记忆大小或做更复杂管理的场景。选择哪一种，取决于你希望记忆留在哪里、能接受多少维护成本和是否需要查询历史。
工具审批则是另一条独立链路。n8n 支持在 AI Agent 的工具面板里加 Human review step，要求人在工具执行前批准或拒绝。官方文档明确，审批通过后工具会用 AI 指定的参数执行，拒绝后动作取消，AI 会知道请求被驳回。审批渠道可以是 n8n 内置聊天、Slack、Discord、Telegram、Teams、邮件、WhatsApp、Google Chat 或 Outlook。注意，审批是流程控制，不能替代最小权限凭证和工具本身的安全校验。
准备材料
- 可用的 n8n 实例，以及能管理 workflow、credentials 和 executions 的账号权限。
- 目标工具的凭证，按最小权限配置，不要直接复用管理员令牌。
- 持久记忆需要的数据库或 Redis/MongoDB 连接信息。
- 一个稳定的 sessionId 或 userId 来源，例如 webhook header、CRM 记录 ID 或登录用户 ID。
- 审批渠道的账号和接收人清单，明确谁可以批准哪类工具。
- 测试集、发布负责人和回滚方式。
步骤一：先收窄 Agent 范围，再连工具
最常见的翻车方式，是给 Agent 一次接十几个工具，希望它自己判断。实际更稳的是先定义 Agent 只处理哪个业务范围，例如“客服退换货助手”而不是“公司助手”。范围越窄，系统指令越好写，测试集越容易覆盖，审批边界也越清楚。
- 新建 workflow，添加 AI Agent node，并选择 Tools Agent 模式。
- 用一段简洁的系统指令定义角色、允许范围、不允许做什么、需要时如何请求更多信息。
- 只先连接 3 到 5 个与当前范围相关的工具。
- 为每个工具写清楚用途和参数限制，不要靠模型猜。
步骤二：把记忆从“当前会话”换成持久记忆
Simple Memory 适合验证流程，不适合用户第二天回来继续聊。要做跨会话记忆，先确定唯一标识，再让 Agent 从外部记忆服务读写历史。同一个用户每次进来都必须使用同一个 sessionId，否则数据库里会变成一堆孤立会话。
- 在入口节点里解析 userId 或 sessionId，并传到 AI Agent node。
- 选择 Postgres、Redis 或 MongoDB 对应的 Chat Memory node，连接到持久化服务。
- 在 memory node 配置里绑定会话字段，让每次请求都能命中同一段历史。
- 只存必要上下文，不要把密码、完整信用卡号或过度敏感的原始内容写进记忆。
- 用两次连续测试确认：第一次对话结束后，第二次从新会话进入仍能读到关键状态。
步骤三：给高风险工具加 Human review
发送外部消息、修改记录、删除数据、触发付费或调用内部写接口，都应该先经过审批。n8n 的审批步骤可以只套在特定工具上，而不是所有工具都停下来。这样低风险查询可以继续自动执行，高风险动作才等人工确认。
- 打开 AI Agent node 的 Tools 面板，找到 Human review 区域。
- 选择审批渠道，例如 Slack 的指定频道或 DM，并配置对应凭证。
- 把需要审批的工具连接到 human review step 的 tool connector。
- 配置审批消息，让审批人能看清工具名、参数和可能的后果。
- 分别测试 Approve 和 Deny 两条路径，确认拒绝后不会执行工具。
步骤四：用测试集覆盖正常、边界和拒绝路径
上线前不能只测“正常问题”。至少准备三类测试：普通查询、需要调用工具的任务、触发高风险工具并要求审批的任务。每一类都要记录预期输出，包括模型是否停在正确步骤、审批是否出现在正确渠道、拒绝后是否给出可理解回复。
- 测试跨会话记忆：用户第一轮说“我的订单 1024 需要退款”，第二轮只问“我那个订单现在怎样”。
- 测试工具参数：模型是否把日期、ID、金额等关键字段填对。
- 测试拒绝路径：审批人拒绝后，Agent 是否告知用户结果而不是继续尝试。
- 测试无权限场景：工具凭证缺少某个权限时，错误是否被捕获并转给负责人。
步骤五：发布前冻结版本，发布后接监控和回滚
把 workflow 从 Inactive 切到 Active 只是发布的一部分。改动前先导出一份 workflow JSON 或记录版本号；上线后确认 execution 列表能正常看到运行记录；失败时用 error workflow 或监控通知把异常送到负责人那里。回滚不是“把开关关掉”这么简单，还要确认没有半途执行的副作用。
- 发布前导出 workflow 备份，记录当前版本和关键凭证范围。
- 先在一个受限入口或测试账号上运行数天，再开放给全部用户。
- 设置 execution 保留策略，避免运行日志无限增长。
- 定义回滚步骤：停用 workflow、恢复旧版本、检查最后一批 executions、必要时人工修正副作用。
可复制上线模板
Agent 范围：
入口渠道：
Tools 清单：
工具风险等级：
需要审批工具：
审批渠道：
记忆类型：
sessionId 来源：
测试集数量：
上线日期：
负责人：
监控通知：
回滚方式：
最近一次权限复查：实际例子：客服 Agent 从单会话升级到生产版
一个小团队先做了一个能查订单状态的 n8n Agent，demo 时一切正常。正式使用后，用户换到新会话就忘记前面说的订单号，而且 Agent 偶尔会直接调用“发送退款邮件”的工具。改造后，他们把 Agent 范围限定为退换货客服，用 Postgres Chat Memory 按邮箱地址保存会话历史，把退款邮件和修改订单工具接入 Slack 审批，并补了三组测试。灰度一周后，高风险工具一次都没有被误执行，审批人也能在 Slack 里看清参数再决定。
验收清单
- Agent 范围已收窄，系统指令没有把权限写得太宽。
- 持久记忆使用外部服务，并用稳定 sessionId 跨会话命中。
- 所有高风险工具都已接入 Human review。
- Approve 和 Deny 两条路径都已实际测试。
- 测试集覆盖普通查询、工具调用、记忆延续和拒绝路径。
- 发布前有 workflow 备份，发布后有 execution 和 error workflow 监控。
- 回滚步骤已经写清楚，不只是停用开关。
常见坑
- 用 Simple Memory 以为用户第二天还能记住上下文。
- sessionId 每次随机生成，导致记忆永远无法命中。
- 把发送、删除、改数据等高风险工具和只读工具放在同一权限级别。
- 审批人清单过宽，结果谁都批、谁都不负责。
- 只在正常路径测试，拒绝和工具报错路径完全没有覆盖。
- 发布后不看 executions，出了问题只能靠用户反馈才发现。
排错路径
- 记忆不生效：先确认 sessionId 是否稳定，再检查 memory node 是否连接同一数据库并写入了历史。
- 审批消息没收到：检查 workflow 是否 Active、审批渠道凭证是否有效、目标频道是否允许应用发消息。
- Deny 后工具仍然执行：检查是否还有其他分支或另一个工具连接未挂到 human review，并复核 execution 日志。
- Agent 频繁选错工具：收窄系统指令，减少工具数量，并在测试集里记录错误案例。
- 长时间任务超时：评估 n8n 执行超时、外部 API 超时和审批等待时间，不要在高风险流程里设过短超时。
后续维护建议
更新日期：2026-08-13。n8n Agent 上线后最值得维护的不是模型 prompt，而是工具清单、记忆数据、审批人和回滚流程。建议每月做一次权限复查：删掉不用的工具、确认数据库容量、轮换过期凭证，并让审批人重新走一遍批准和拒绝流程。这样即使模型或平台版本变化，你的生产 Agent 仍能保持可控。