场景
一个 Telegram 交流群，群务分三件：新人进群要发欢迎语并顺手说清群规；有人问「怎么配」「这个报错怎么办」要有人答；刷广告、拉群的要当场处理。这三件事现在挤在同一个机器人身上------一条流水线、一套提示词。
麻烦在于触发时机不同。欢迎语只在「有人加入」那一瞬间有意义；群规问答面对每一条普通消息；移人、封禁这类动作本不该长在问答助手身上。合成一段提示词之后，模型每次都得先猜「现在是哪一种情况」，猜错一次就是一次误伤。
4.11 里怎么做
处理器这一层多了 Agent 这个选项。 4.10 里机器人只能挂一条流水线，想在入群时说话就得在流水线内部判断事件。4.11 改成事件路由：机器人身上存一张「事件模式 → 处理器」的表，处理器可以是流水线，也可以是一个 Agent；Agent 自带运行器（Runner，由插件提供，本例用官方插件 langbot-team/LocalAgent）与系统提示词。适配器各自声明自己支持哪些事件，具体支持取决于适配器/平台，请先核对支持矩阵。
同一条事件只命中一条路由。 逐行按顺序判定：是否启用 → 事件模式是否匹配 → 过滤条件 → 目标处理器是否声明支持该事件；第一个全部通过的行被选中，其余记为跳过（官方文档 docs/event-based-agents/04-event-routing.md §3）。本次实测（2026-10-16）的「检查路由」输出：
目标处理器 | Agent · tg-welcome-agent | 命中规则 | 第 2 条路由 | 诊断步骤 | 第 1 条路由已跳过。事件与此路由不匹配。已选择第 2 条路由。第 3 条路由已跳过。事件与此路由不匹配。事件范围决定三件事。 Agent 的「事件范围」是一组事件模式，本例三个 Agent 各自只声明一个。它决定该 Agent 收到哪些事件、调试下拉里能选什么、新建路由时处理器下拉里能不能选到它。本次实测（2026-10-16）建 group.member_joined 路由时，处理器下拉只列出 tg-welcome-agent 与 dify-wecomcs-agent，tg-rules-agent、tg-moderation-agent 不出现。
适配器声明什么，菜单就是什么。 本例的 Telegram 适配器 telegram-omni 声明 11 类事件，与源码 LangBot/src/langbot/pkg/platform/adapters/telegram/adapter.py:168-180 一致：message.received、message.edited、message.reaction、group.member_joined、group.member_left、group.member_banned、bot.invited_to_group、bot.removed_from_group、bot.muted、bot.unmuted、platform.specific。机器人详情页的「添加行为」菜单据此渲染：Telegram 上只有四个常用场景（「回复收到的消息」「欢迎新成员」「处理成员离群」「处理群管理事件」）加「配置其他事件」；预设表第五项「审核好友请求」（friend.request_received）不出现，因为这个适配器声明的事件里没有它（源码 LangBot/web/src/app/home/bots/components/bot-form/EventBindingsEditor.tsx:1554-1559、:194-230）。结论到此为止：菜单取决于适配器声明的事件，不是我们对某个平台能力的判断。
动手：步骤
先起一个本地演示实例：
bash
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（本地演示值，请自行替换）。
- 建 Telegram 机器人 ：机器人 → 新建 → 消息平台选
Telegram，填 BotFather 给出的令牌。本示例填占位令牌（本地演示值，请自行替换 ），Telegram 侧不会真的连上------本文验证的是事件被送到谁那里。详情页用查询参数/home/bots?id=<uuid>（源码LangBot/web/src/app/home/bots/page.tsx:7-8）。
- 认清适配器声明了哪些事件：详情页的事件面板显示「共 11 类」，这 11 个名字就是后面所有菜单的边界。
- 建三个 Agent，各只认一种事件 ：运行器选本地 Agent（
plugin:langbot-team/LocalAgent/default），主模型deepseek-chat，「事件范围」分别只勾一个事件：tg-welcome-agent→group.member_joined、tg-rules-agent→message.received、tg-moderation-agent→group.member_banned。范围越窄，能被叫醒的事件越少，下拉里的候选也越少。
- 给欢迎 Agent 写提示词、开工具 ：欢迎语控制在 60 字以内并点名两条群规，允许调用「回复当前会话」（
event_reply）。
- 先在调试页跑一次 ：打开
tg-welcome-agent的调试页（事件下拉只有它声明的那一个），给group.member_joined填载荷{"member_name": "小林", "member_id": "10086", "group_id": "-1001234567890"}并运行。本次实测（2026-10-16）记录到「已记录 1 次工具调用」，工具为「回复当前会话event_reply」，输出逐字为：
markdown
欢迎语已通过「发送消息」工具发出（模拟投递，未真实调用平台 API）：
> 欢迎小林加入 LangBot 交流群！🎉 提问请带上 LangBot 版本号，禁止发广告。配置说明可在 GitHub 仓库 docs 目录查看。
（53 字，符合 60 字以内要求：包含欢迎、两条群规与 docs 目录提示。）
- 群管理 Agent 只开必须的工具 ：它的「事件与工具」页显示「已添加事件 共 1 项」（
成员被封禁 group.member_banned）、「已启用 4 个工具」；14 项平台工具里只勾了「移出群成员」。该工具在源码里是event_kick_member→kick_member，风险等级dangerous（源码LangBot/src/langbot/pkg/agent/runner/platform_tools.py:99-203），界面标为「敏感」（read=只读、write=操作、dangerous=敏感，源码LangBot/web/src/i18n/locales/zh-Hans.ts:1368-1370）。
- 建三条路由 ：机器人详情页 →「事件路由」→ 逐行添加
message.received→tg-rules-agent、group.member_joined→tg-welcome-agent、group.member_banned→tg-moderation-agent。
验证
其一，路由落库。 保存后从 bots.event_bindings 读回三行（updated_at 2026-10-16 17:23:44，原始 JSON 见 series/langbot-4.11-release/evidence/demo-test-records.md §8.3）：
| 顺序 | 事件模式 | 处理器 | priority | enabled |
|---|---|---|---|---|
| 第 1 条 | message.received |
Agent · tg-rules-agent |
0 | true |
| 第 2 条 | group.member_joined |
Agent · tg-welcome-agent |
0 | true |
| 第 3 条 | group.member_banned |
Agent · tg-moderation-agent |
0 | true |
其二，试算一个事件。 「检查路由」里选「成员加入群组 group.member_joined」，本次实测（2026-10-16）的输出是 目标处理器 | Agent · tg-welcome-agent、命中规则 | 第 2 条路由，诊断步骤为「第 1 条路由已跳过。事件与此路由不匹配。已选择第 2 条路由。第 3 条路由已跳过。事件与此路由不匹配。」------三条路由各认自己的事件，互不遮蔽。
边界与注意
- 本文没有真实 Telegram 收发。 机器人填的是本地演示令牌（本地演示值，请自行替换），验证到的是「配置生效 + 事件被路由到正确的 Agent 并跑完一次模型调用」，不是群里的实际投递。
- 调试页的平台工具走 Mock。 原文：「平台工具使用 Mock：Agent 真实调用工具，回复、发送等平台动作模拟执行，不发送真实消息。其他工具仍按实际配置执行。」同一页也写着「未记录到工具调用；生成文本不代表消息已发送。」那段欢迎语是模拟投递的结果。
- 敏感工具要单独收敛。
event_kick_member一类风险等级是dangerous，只开给群管理 Agent；真实平台上移人、封禁立即生效，开之前想清楚给谁开。 - 处理器选型受事件限制。 流水线目标只能绑
message.received（官方文档docs/event-based-agents/04-event-routing.md§3），入群、封禁这类事件要用 Agent 或插件处理器。具体支持取决于适配器/平台，请先核对支持矩阵。 - 待确认 ：只在调试页观察了单次往返，没有在群内连续观测多轮对话；
tg-rules-agent的问答质量属于模型与提示词的表现，本次未做评测。 - 推断 「同一事件可由两条路由分别投递」不在实测范围内------实测确认的是仲裁只选一条（第 2 条命中，第 1、3 条跳过）。若确需同一事件触发多个目标，应走「插件处理器」这条独立路径。
小结与下一步
拆成三个 Agent，靠的不是更长的提示词，而是「事件模式 → 处理器」的路由行：group.member_joined 叫醒欢迎 Agent，message.received 叫醒群规问答 Agent，group.member_banned 叫醒群管理 Agent。每个 Agent 的事件范围收成一条，别的事件喊不动它，危险工具也只落在需要它的那一个身上。
从 4.10 升上来，先看迁移配置对照文档 docs/pipeline-migration-config-map.zh-CN.md；v4.11.0 release 页是版本入口，运行器插件源码在 langbot-plugins 仓库。不想自己维护实例时，托管服务 space.langbot.app 是另一个可选方向，是否合适取决于你的部署约束。