过去在 n8n 里搭智能体，是在画布上自己攒：Chat Trigger 触发器、Memory 记忆节点、AI Agent 节点，再把一个个工具节点挂上去，最后用一圈 workflow 把它们包起来。能跑，但每个零件都要自己挑、自己接。2026 年 9 月 n8n 官方发布了独立的 Agents 产品：Agent 成为一等公民，用一段大白话描述职责、选个模型、指几个工具就能开工；它能直接待在 Slack、Telegram 这些你已经在用的通道里接活，还能反过来把你的存量工作流当成自己的工具来用。官方博客的比喻很准确：自己攒机 versus 整机。本篇照官方发布路径完整走一遍，结尾说明它与教程 390（AI Agent node 手工搭法）各自适合什么场景。
Step 1：创建 Agent，用写岗位说明书的方式描述职责
登录 n8n 后，在左侧导航进入 Agents 区域，选择新建。与新建空白 workflow 不同，这里从一个描述框开始：用大白话写清楚这个 Agent 做什么、语气如何、哪些事不能做、优先用哪些工具。n8n 会把这段描述整理成结构化的 instructions，官方的说法是「读起来像你给同事写的一份工作简报」。参考写法（客服查订单场景）：
角色：电商售后支持 Agent
职责：回答订单状态、物流进度、退换货政策三类问题。
语气：简洁友好，中文回复，每段不超过 3 句。
可以做：调用 query_order 工作流查订单；调用 policy_search 工作流查政策原文。
不可以：直接承诺退款金额；回答与订单无关的问题时引导用户联系人工。
优先策略：涉及具体订单号时必须先查订单再回答，禁止凭记忆编造状态。写完保存后重新打开这个 Agent，你会看到 n8n 已经把它整理成了职责、语气、边界、工具偏好几个分区。后续所有行为都以这份 brief 为准，改需求时直接改这里，不用动画布。
Step 2：选模型——自带凭据或 Gateway credits
在 Agent 设置里选择模型：如果实例里已经配好了 OpenAI、Anthropic、Gemini 等凭据，直接从凭据列表选；如果在支持 Gateway credits 的 n8n Cloud 套餐上，可以选 Gateway credits 选项——这是 n8n 提供的共享预付余额，选了它就不用再去服务商注册账号、生成 API key，按官方公布的牌价计费，用量在 Cloud 管理面板按工作流和服务查看。
模型选择决策参考：
流程验证期 → 便宜快速的模型（如 mini / flash 档），跑通流程为主
上线前替换 → 换成能力更强的模型，重点回归测试工具调用是否稳定
数据敏感型 → 自带 key 或私有部署模型，不走 Gateway creditsStep 3：配置工具——少而准，优先接 MCP
在 Agent 的工具区添加能力：内置工具（如网页搜索、HTTP 请求）按需勾选；需要连外部系统时，可以从 MCP server 注册表里直接连接一个服务，Agent 拿到的是这个 server 暴露的成套工具。原则是「少而准」：每个工具都在扩大 Agent 的行动面，也都在增加它选错工具的概率。客服查订单场景挂两个就够了：订单查询、政策检索。
Step 4：把存量 workflow 挂成 Agent 的工具（本篇核心）
这是 Agents 与 workflow 协作的关键设计：你的 Agent 可以使用你的工作流作为工具，于是「哪些事按固定流程办」由你说了算。把查询订单这类有确定步骤的逻辑做成一个 workflow，定义好输入输出，然后在 Agent 的工具列表里把它挂上。给 workflow 写清输入参数说明——Agent 靠这段说明决定何时调用、传什么值：
workflow: query_order（挂为工具时的说明写法）
用途：按订单号查询订单状态、物流进度、最近一条物流轨迹。
输入参数：
order_id (string, 必填) 订单号，形如 SO-2026-XXXXXX
输出：
status 订单状态（已支付/已发货/已完成/已关闭）
logistics 物流承运方与最新轨迹摘要
refundable 是否支持 7 天无理由退货（布尔值）挂好后先在 Agent 的对话预览里测一轮：输入「帮我看下 SO-2026-091801 到哪了」，观察它是否解析出订单号并调用 query_order。调用轨迹在执行日志里全程可见，出问题时直接点开看它传了什么参数。
Step 5：接入 Slack / Telegram 通道，真实对话验证
Agent 的通道与触发器支持 Slack、Telegram、Linear、Discord，也可以按定时计划运行。以 Slack 为例：在通道设置里完成 OAuth 授权，把 Agent 拉进一个测试频道，然后 @ 它发起多轮对话。官方博客举的场景很典型——「同事在 Slack 里问某客户上月用量为什么下降了」：这类问题要查账号、确认产品线、翻支持记录、再汇总追问，每一步取决于上一步的答案，固定流程画不出来，正是 Agent 的用武之地。
多轮验证对话记录（Slack 测试频道）：
张三 14:02 @售后助手 订单 SO-2026-091801 什么状态？
Agent 14:02 已发货，顺丰 SF1398****，昨日 18:42 到达杭州转运中心。
张三 14:03 那这个订单还能 7 天无理由退吗？
Agent 14:03 可以。该订单签收后 7 天内支持无理由退货，
需要保持吊牌完整。需要我把退货流程发你吗？Step 6：反向调用——在工作流里用 Message an Agent 节点
Step 4 是 Agent 调工作流，这一步反过来：当工作流的某个环节需要开放式判断时，用新的 Message an Agent 节点把 Agent 调进来。典型场景：工单表单提交触发 workflow → 前置节点做完格式校验与去重 → 中间一步调 Agent 对工单做意图分类与优先级判断 → 后续节点按分类结果路由到不同处理队列。这样整体流程可控可审计，开放判断集中在被托管的一步。
Message an Agent 节点配置要点：
agent 选择已创建的「工单分诊」Agent
message 传入上游节点的工单文本，例如
{{ $json.ticket_title }} + {{ $json.ticket_body }}
输出 Agent 返回的分类 JSON，交给下游 Switch 节点路由
超时与重试 沿用节点默认配置，超时视为分类失败走人工队列Step 7：上线护栏——审批、版本与监控
记忆、会话、版本、审批这些 Agent 运行必需的机制在 Agents 里是内置的，不用再自己拼节点。上线前做三件事：① 打开敏感操作的审批开关，让写操作先过人；② 修改 instructions 前利用版本机制留存当前版本，出问题能快速回到上一个版本；③ 固定查看执行日志的习惯，重点盯工具调用失败率和被审批拦截的操作。运行一周后再根据日志微调 brief 和工具集。
执行日志关注字段（每次运行）：
tool_calls[] 本次调用了哪些工具、入参与返回
approvals 哪些操作被审批拦下、由谁放行
session_id 会话标识，用于回放完整多轮上下文
tokens / cost 单次运行消耗，用于模型档位决策常见问题 FAQ
Q1：自托管实例找不到 Agents 入口？ 功能分批推送，自托管需 2.35 以上并按官方 Agents 文档启用；升级后仍不可见时检查许可证与功能开关。
Q2：Agent 不调用我挂的 workflow 工具？ 九成是工具描述问题：确认挂载时写的用途说明包含用户真实的说法（如「查订单」「物流到哪了」），并确认 workflow 的输入参数有类型与必填标注。
Q3：Gateway credits 和自带 key 能混用吗？ 能。同一个实例里按节点选择；官方建议过渡期用 credits 快速试，正式跑量后切回自带 key 以便对账与议价。