把 n8n 接进 Slack：在对话里 @机器人 触发自动化工作流

场景

团队已经在 Slack 里办公，自动化流程则在 n8n 里画好了：发版本通知、拉一次报表、给新客户建档。问题是这两件事各在各的地方------有人在频道里说「发一版通知吧」，然后另一个人切到 n8n 的浏览器标签，找到那条工作流，点「执行」，再回来把结果贴进频道。

想让对话本身成为入口，chatbot 框架这边要具备两件事：一件是「谁来跑」，也就是把消息交给 n8n 而不是交给大模型；另一件是「跑什么」，也就是一次会话要对应到 n8n 的哪条 webhook。4.10 的部署里，这两件事都得自己写一层胶水服务：起一个 HTTP 服务接收 LangBot 的转发、再调 n8n 的 webhook、最后把结果回帖到 Slack。胶水服务的地址、认证、错误处理全归你自己维护。

4.11 把「谁来跑」做成了插件：处理器可以在「运行器（Runner）」里选一个由插件提供的执行体，n8n 就是其中之一。本文只做一件事------把 Slack 频道里的一条 @机器人 消息，接到一条 n8n 工作流上，再把工作流的回应送回频道。

4.11 里怎么做

运行器（Runner）由插件提供。 4.11 把原先内置在宿主里的各类 runner 拆成了插件，n8n 对应官方插件 langbot-team/N8nAgent，运行器 id 是 plugin:langbot-team/N8nAgent/default（源码 LangBot/docs/agent-runner-pluginization/OFFICIAL_RUNNER_PLUGINS.md:30）。同一份文档把这批插件分成三批，n8n 属于「Batch 2（外部 workflow）」，和 langflow-agent 一组，特征是「webhook/workflow 输入输出、timeout、外部 conversation id」（同文件 :46）。文档同时说明：旧的内置 runner 代码不再提供运行时 fallback（同文件 :22）------也就是说，4.11 里要用 n8n，就得把插件装上。

处理器上的运行器配置。 新建一个「处理方式 = Agent」的处理器并在「运行器」里选 n8n 之后，配置项出现在处理器的 AI 能力 标签页里（不是插件页面------插件页面本身写着「插件没有配置项。」）。本次实测（2026-10-16）见到的字段是：Webhook URL、认证类型（本示例选「无认证」）、响应处理（本示例选「转发为聊天回复」）、供应商用户身份（本示例选「发送者」），以及一个「启用 LangBot 资产」开关。换句话说，一次 n8n 调用的出入口都在这一个页面上，不需要额外部署中间服务。

事件路由只负责「事件 → 处理器」。 机器人详情页的「事件路由」把事件模式绑定到处理器：EventBinding 的字段是 id / event_pattern / target_type(agent|pipeline|discard) / target_uuid / filters / priority / enabled / description，匹配顺序是「忽略 enabled=false → 检查 event_pattern 与结构化 filters → 校验目标存在且声明支持该事件 → 按 priority 从高到低选择，同优先级按列表顺序 → 只执行一个响应目标 」（文档 docs/event-based-agents/04-event-routing.md §3）。同一份文档明确：Webhook、Dify、n8n、Coze 这类外部系统需要响应事件时，「由对应 Runner 插件承接」，插件 EventListener 不是第三种响应目标（同文档 §1）。所以下图里只留了一条 message.received 路由------两条路由指向同一事件时，仍然只有一条会跑，多留没有意义。

在什么条件下才触发。 是否「只有被 @ 时才响应」属于处理器的触发条件 ：配置项 at（界面标签就是 @，描述「是否在消息@机器人时触发」）来自 LangBot/src/langbot/templates/metadata/pipeline/trigger.yaml:19-23，同页还有「群响应规则」的前缀、正则表达式、随机，以及「访问控制」的黑白名单、消息忽略规则、消息聚合。注意 at 在源码模板里的默认值是 false；本次实测的这个实例里它显示为已选中，属于本实例的处理器配置值，不要当成出厂默认。

如果你想更精确地表达「消息里带 @ 才走这条路由」，事件绑定的过滤条件 本身就能写：可用的字段是 chat_type / chat_id / message_text / message_element_types，其中 message_element_types 支持 contains / not_contains，可选项包含 At 与 AtAll（源码 LangBot/web/src/app/home/bots/components/bot-form/EventBindingsEditor.tsx:146-183）。@ 门控放在绑定上、还是放在处理器的触发条件里，取决于你要拦的是「路由」还是「处理器」------推断 触发条件属于流水线执行链上的响应规则（规则注册在 src/langbot/pkg/pipeline/pipelinemgr.py:43，@ 规则实现见 src/langbot/pkg/pipeline/resprule/rules/atbot.py:34），路由到 Agent 时走的是 Runner Host 编排（文档 docs/event-based-agents/04-event-routing.md §4.2）。两者不是同一处开关。

Slack 这一侧。 适配器的字段来自 LangBot/src/langbot/pkg/platform/sources/slack.yaml：bot_token（「机器人令牌」，必填）、socket_mode（「长连接模式」，默认 false）、app_token（长连接模式下的 App-Level Token，xapp- 且带 connections:write）、webhook_url（「Webhook 回调地址」，非长连接模式）与 signing_secret（「密钥」，非长连接模式）。想省掉公网回调地址就把「长连接模式」打开，改用 App-Level Token。具体支持取决于适配器/平台，请先核对支持矩阵。

动手：步骤

先起一个本地演示实例（命令来自本期实测环境）：

docker network create a4
docker run -d --name a4-core --network a4 --restart on-failure -e TZ=Asia/Shanghai \
  -e BOX__ENABLED=false -e SPACE__DISABLE_TELEMETRY=true -p 15800:5300 \
  -v "$PWD/deploy/a4/data:/app/data" rockchin/langbot:v4.11.0
docker run -d --name a4-runtime --network a4 --network-alias langbot_plugin_runtime --restart on-failure \
  -e TZ=Asia/Shanghai -e SPACE__DISABLE_TELEMETRY=true -v "$PWD/deploy/a4/data/plugins:/app/data/plugins" \
  rockchin/langbot:v4.11.0 uv run --no-sync -m langbot_plugin.cli.__init__ rt

管理员初始账号 demo@langbot.local，初始密码 LangBot411!demo（本地演示值，请自行替换）。

1. 建 Slack 机器人 ：机器人 → 新建 → 消息平台选 Slack，填入 Slack 应用的「机器人令牌」（Bot Token，作用域至少需要 chat:write 与 app_mentions:read）。本示例使用的是占位令牌，因此这一步之后日志里会出现来自 slack.com/api/auth.test 的报错------这是预期的：本文只验证「消息进来之后能不能触发 n8n」，不验证 Slack 侧的真实收发。
2. 装 n8n 运行器插件 ：扩展市场 → 搜索 n8n → 安装 N8nAgent（本次实测装到的版本是 v0.2.0，来自 langbot-team）。装完在 /home/extensions 里能看到它，和内置的 LocalAgent 并列。
3. 建处理器并选运行器 ：处理器 → 新建 → 处理方式选 Agent → 「运行器」里选 n8n；随后在「AI 能力」标签页把 Webhook URL 填成 LangBot 运行时容器能访问到 的地址。本演示里两个容器在同一个 Docker 网络 a4 上，n8n 容器的网络别名是 n8n，所以填 http://n8n:5678/webhook/langbot-slack（本地演示值，请自行替换 ）；整条链路都在同一台机器、同一个网络命名空间里，才用 http://127.0.0.1:5678/webhook/langbot-slack。
4. n8n 侧建工作流 ：Webhook 节点（HTTP Method POST、Path langbot-slack、Response Mode Respond to Webhook）→ Respond to Webhook 节点，响应体返回 JSON，例如 {"text": "n8n 收到：{``{ $json.body.text }}（工作流已执行）"}。保存并启用，让 webhook 路径注册到 n8n 上。
5. 绑定事件路由 ：机器人详情页 →「事件路由」→ 新建一条：事件模式 message.received、目标选刚建的处理器。绑定的过滤条件面板可加 message_element_types contains At，把入口限制成「带 @ 的消息」。
6. 确认触发条件 ：回到处理器的「触发条件」标签页，确认「群响应规则」里的 @ 已勾选（本实例默认勾选）。

验证

验证的目标只有一个：LangBot 运行时容器能不能把消息转成一次 HTTP 调用打到 n8n 的 webhook 上。这一步可以完全绕开 Slack------从同一个网络里的容器直接 POST webhook 地址即可：

docker exec a4-core python3 -c 'import json,urllib.request as u
r=u.urlopen(u.Request("http://n8n:5678/webhook/langbot-slack",
  data=json.dumps({"text":"@langbot 发一版通知"}).encode(),
  headers={"Content-Type":"application/json"}),timeout=20)
print(r.status, r.read().decode())'

本次实测（2026-10-16）的结果、以及工作流未启用时的对照行为，记录在 series/langbot-4.11-release/evidence/demo-test-records.md。

边界与注意

• at 是实例状态，不是出厂默认值 ：源码模板里的默认值是 false（LangBot/src/langbot/templates/metadata/pipeline/trigger.yaml:19-23）；本次实测实例显示为已勾选。
• Webhook 地址必须能被运行时容器访问到 ：宿主机上 curl 通，不代表容器里通。
• Slack 侧未做端到端验证：演示机器人用的是占位 Bot Token，本篇只覆盖「消息进入 LangBot → 触发 n8n webhook → 回复回频道」这条链路。
• Runner 是插件 ：旧的内置 runner 代码不提供运行时兜底（docs/agent-runner-pluginization/OFFICIAL_RUNNER_PLUGINS.md:22），用 n8n 之前先确认插件已安装。

小结与下一步

会话是入口，事件路由决定谁来处理，Runner 插件是桥：装上 langbot-team/N8nAgent，把处理器的 Webhook URL 指向一条 n8n webhook，再把 message.received 绑到该处理器 ------ 一次 @ 就是一次工作流运行，回复原路回到频道。

主要参考：随版本锁定的迁移文档 docs/pipeline-migration-config-map.zh-CN.md 与 v4.11.0 发布页。第 2 篇讲 Runner 插件的来源，第 3 篇讲从 4.10 升级。托管版只作为条件性的次要选项（space.langbot.app），本篇不对它作任何承诺。