这两周我做了一次 n8n 2.x 的升级迁移。
本来只是常规版本迭代，结果在收尾时发现了一个新聊天入口Chat Hub。
顺着这个入口往下试，我的直观感受是：n8n 正在从“工作流驱动”往“对话驱动 + Agent + 工作流”的组合方式移动。
对于做业务自动化和内容流水线的团队，这类交互变化实际影响不小。
这次更新的核心：新增了三类能力
1）Chat Hub：内置的大模型对话窗口
定位：在 n8n 内直接进行基础聊天，支持通过 OpenAI 兼容 API 选择模型。
体验：使用门槛低，配置 API Key 就能聊。但我在多个国内中转站测试时，Chat Hub 无法直接选择到 Gemini/Claude（即便这些中转站对 OpenAI 接口做了兼容）。
在 n8n 里要用 Gemini/Claude，依然需要走工作流中的 HTTP Request 节点；Chat Hub的模型选择列表目前不支持自定义 HTTP 端点。
适用：集中在一个界面里管理对话与自动化触发，方便团队统一入口。对单纯聊天来说，和直接使用模型官网差距不大，主要增益在“与后续工作流打通”。
2）Agent Assistant：预设提示词 + 联网工具的轻量智能体
定位：不写代码即可把提示词和工具组合成一个可复用的智能体。
体验：比较适合非技术同学快速搭建，比如“Code 助手”“文案助手”“标题生成助手”。
我个人写作类任务仍偏向用 Cherry Studio，但在 n8n 内置一个可调用的助手，对工作流衔接更顺手。
适用：标准化的内容生成、代码片段解释、表格化信息整理等轻量任务。
3）Workflow Agent：在聊天中直接触发并对话工作流
定位：从“进工作流运行再看结果”，转为“在聊天里下达指令、触发工作流、拿到结果”。
体验：用自然语言触发自动化，对业务同学更友好。对复杂流程，仍需要清晰的输入输出定义和权限设计。
适用：内部支持服务台、内容生产流水线、运营自动化指令集等，把工作流暴露给非技术用户时特别有用。
隐藏更新：Agent 节点的工具支线
这部分是我认为更有实际价值的改动。
社区节点（如飞书、小红书、微信公众号等）可以作为“工具”直接接到 Agent 上，模型可以尝试自己编写调用参数。
相比过去“单节点串流程 + 自己做参数拆解”，现在可以通过提示词明确工具用途和参数要求，让模型先行尝试填参，再在工作流里做校验和容错。
- 价值：减少人工编排的粘合代码，让“对话触发工具”成为主路径。
- 注意：要加上参数验证、节流控制、失败回滚等保护，避免模型误调用或超配额。
差异化与适配性：怎么选、怎么用
| 功能 | 范围与定位 | 技术特征 | 使用门槛 | 适合人群/场景 | 限制与风险 |
|---|---|---|---|---|---|
| Chat Hub | 内置对话，统一入口 | 模型列表选择；当前不支持自定义 HTTP 端点 | 低：配置 API Key 即可 | 希望在同一界面聊与触发工作流的团队 | Gemini/Claude 通过中转不工作；成本由模型计费决定 |
| Agent Assistant | 提示词 + 工具的轻量智能体 | 联网工具、无代码搭建 | 低：非技术用户可用 | 文案、标题、代码解释等标准化输出 | 强依赖提示词质量；复杂多步骤不擅长 |
| Workflow Agent | 聊天中触发工作流并多轮对话 | 自然语言到工作流映射 | 中：需定义好输入输出与权限 | 内部支持、内容流水线、运营自动化 | 指令歧义、权限与审计需要补齐 |
| Agent 工具支线 | 社区节点作为可调用工具 | 模型尝试自行填参 | 中：需理解工具参数与速率限制 | 社媒分发、通知、数据抓取 | 第三方接口变更、容错与限流 |
实操：通过 Docker 更新到 2.3.0
以下以 Windows PowerShell 为例，其他系统请调整路径与转义。
停止并删除旧容器
docker stop n8n
docker rm n8n
拉取镜像（按需选择具体版本标签）
官方镜像地址：https://hub.docker.com/r/n8nio/n8n/tags
docker pull n8nio/n8n:2.3.0
运行最新版本容器（Windows PowerShell 示例）
docker run -d `
--name n8n `
-p 5678:5678 `
-e GENERIC_TIMEZONE="Asia/Shanghai" `
-e TZ="Asia/Shanghai" `
-e N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=false `
-e NODES_EXCLUDE="[]" `
-e N8N_SKIP_AUTH_ON_OAUTH_CALLBACK=false `
-e N8N_RESTRICT_FILE_ACCESS_TO=/home/node/n8ndata `
-v "d:\n8n\n8n:/home/node/.n8n" `
-v "d:\n8n\n8ndata:/home/node/n8ndata" `
docker.n8n.io/n8nio/n8n:2.3.0
Linux/Mac 需调整挂载路径与转义，并额外加上：
-e N8N_SECURITY_AUDIT_FILE_PERMISSIONS_DISABLE_CHECKS=true
检查启动结果
在 Docker 管理界面或命令行查看是否有名为 n8n 的运行中容器。
浏览器访问 http://localhost:5678 确认能打开控制台。
使用建议与场景落地
- 如果团队需要一个统一入口把“对话”和“自动化”连起来，优先尝试 Chat Hub + Workflow Agent 组合。
- Agent Assistant 适合把高频、结构化的需求固化成模板，例如标题生成、素材改写、代码片段解释。
- 对接第三方平台（飞书、小红书、公众号等）建议走“Agent + 工具”的方式，把参数格式与调用规则明确到提示词，并在工作流里做参数校验与错误处理。
- 需要 Gemini/Claude 时，使用工作流的 HTTP Request 节点对接官方 API；Chat Hub 目前不适合通过中转站接入这两类模型。
结语
从这次版本观察到的变化来看，n8n 的思路已经不再仅是“把节点串起来”，而是把“对话入口、智能体、工具调用、工作流执行”组合在一个使用路径里。对产品和运营团队来说，这会改变我们设计自动化的方式：先定义指令和工具，再让模型尝试填参，工作流负责校验和交付结果。现阶段的限制主要集中在模型接入和可靠性上，但随着迭代，这条路径的可用性会逐步提高。
我会继续用 2.3.0 做两类测试：一类是内容流水线的对话触发，一类是社媒分发的 Agent 工具化。如果你也在评估这次更新，建议先升级并用一个小流程试跑，把输入、参数和权限设计清楚，再扩展到更复杂的场景。