LangBot 4.11：从消息回复走向事件驱动智能体
LangBot 4.11 正式发布：事件路由让机器人响应入群、回应与卡片交互，AgentRunner 插件化连接不同智能体，工作区助手让配置更直观。附实机截图与升级指南。
LangBot 是一个开源的 AI 聊天机器人与智能体平台，支持多种即时通讯平台、大语言模型、知识库和插件，帮助你构建、部署和管理 AI 助手。
过去，搭建一个聊天机器人通常从“收到消息，然后回复”开始。但真正的协作不只发生在消息里：新成员加入群组、用户对一条回复作出表情回应、同事点击卡片按钮，都可能是一个任务的起点。
LangBot 4.11 的核心变化，是把这些事件变成可以配置、交给智能体处理、并追踪执行过程的入口。 配合插件化的 AgentRunner 和新的工作区助手，LangBot 在连接聊天平台的同时，也让“由谁处理、怎么处理、如何管理”变得更清楚。
一、事件驱动：机器人不再只等待下一条消息
4.11 引入事件驱动智能体（Event-Based Agents，EBA）。除了普通消息，入群、退群、消息撤回、表情回应、卡片点击等平台事件，也可以进入处理流程。本次发布中，13 个平台适配器已经基于 EBA 架构重写。
这不意味着每个平台都有完全相同的事件能力。实际能收到哪些事件，仍取决于对应平台、适配器以及机器人权限。变化在于：收到事件之后，LangBot 有了一套统一的路由和处理方式。
4.11 正式版发布说明中的事件路由示例。
从场景出发，而不是先写一段胶水代码
在「事件路由」中，可以从欢迎新成员、处理成员离开等常见场景建立规则，再决定由哪个处理器执行。
例如，一个社区可以把普通问题交给知识库问答 Pipeline，把新成员加入交给负责欢迎与介绍规则的 Agent，再把需要固定业务逻辑的事件交给插件处理器。这是配置思路示例；实际启用前，需要确认平台事件支持和所需权限，并测试对应路由。
这种组织方式的好处是，平台接入与业务处理不必绑成一块。欢迎流程变了，可以调整处理器；问答策略变了，可以修改 Pipeline，而不必把所有行为塞进同一段提示词。
Pipeline、Agent、插件处理器，分别适合什么？
本文新启动的 LangBot 4.11.0 实例：创建处理器时，先选择处理方式。
- Pipeline：处理消息事件，适合直接生成回复、知识库问答和已有的消息处理流程。它仍是固定步骤清晰、容易配置的选择。
- Agent：用自然语言描述不同事件该如何处理，由 AI 执行，或者交给外部 Agent 平台。适合需要结合上下文作判断的任务。
- 插件处理器：由插件代码处理其声明支持的事件类型。适合规则明确、需要确定性逻辑或专门集成的场景。
不需要为了“用上智能体”而把每个流程都改成 Agent。明确的规则交给代码，稳定的问答交给 Pipeline，需要判断的部分再交给 Agent，往往更容易维护。
调试也围绕事件展开
事件调试器允许以表单编辑事件数据，查看运行日志和执行详情。配置好路由之后，可以先检查事件字段和处理结果，再到真实聊天平台验证。调试事件有助于定位问题，但不替代对平台连接、权限和真实回调的验证。
平台侧也有相应改进，包括 Slack Socket Mode、钉钉卡片交互、微信“正在输入”提示和 OneBot WebSocket 等；具体支持范围以对应平台文档为准。
二、AgentRunner 插件化：选择执行方式，不必等待 Core 发版
另一项重要变化是运行器与主程序的解耦。LocalAgent、Dify、Coze、n8n 等原内置运行器迁移为扩展市场中的官方插件，并新增 Codex、Claude Code、ACP 等运行器。
实机访问扩展市场，可看到官方 Runner 专区。市场内容独立更新，展示状态以访问时为准。
对于用户，最直接的变化是：按需安装运行器，并独立更新它们。你可以使用 LocalAgent 的模型、工具和知识检索能力，也可以把已有的 Dify 应用或 n8n 工作流接到聊天平台，不必为了不同的执行方式维护不同的机器人接入方案。
这也给开发者留下更清晰的扩展边界：实现 AgentRunner Protocol v1，就可以编写自己的运行器，而不必把特定平台的逻辑直接加入 Core。
4.11 正式版发布说明中的运行器插件示例。不同 Runner 的账号、API、运行环境要求仍需分别配置。
插件化并不等于把所有能力无条件交给插件。运行器只能调用当前上下文授权的工具与平台 API；扩展市场展示认证徽章，Core 校验认证插件的签名。认证与权限控制解决的是来源和授权问题，使用前仍应阅读插件说明，确认它适合自己的部署环境。
升级时，已有 Pipeline 怎么办？
4.11 提供迁移入口，自动安装所需插件，并备份原配置。升级后，在「流水线」页面完成迁移，再检查运行器、模型、知识库和工具配置。
需要特别留意：迁移后的流水线会开始新会话。旧版自定义 Runner 也需要改写为插件 Runner。离线环境可以选择「仅迁移数据」，再手动安装运行器插件。完整映射关系见 4.11 迁移说明。
三、工作区助手：把配置过程变成可确认的对话
WebUI 新增的工作区助手，面向的是管理 LangBot 的人，而不是聊天群中的终端用户。它可以查询当前工作区的资源，并通过对话帮助创建和配置流水线、知识库等资源。
实机中的工作区助手初始界面。此截图展示尚未配置模型的新工作区；使用前需要登录 LangBot Account 或配置可用模型。监控中的零值是这个新实例的真实空状态。
你可以从“当前有哪些模型、知识库和流水线？”这样的只读查询开始，再提出“帮我创建一个知识库问答应用”。重点不是把表单换成聊天框，而是让助手先理解当前资源，再提出具体配置。
所有写操作都需要确认后才会执行。 因此，在让助手新建或修改资源时，应先核对它提出的对象、参数和影响范围，再确认。助手降低了寻找配置入口的成本，也保留了管理者对变更的控制。
四、让日常运维跟得上新的执行方式
统一看执行，而不只看消息数量
当一个事件可能由 Pipeline、Agent 或插件处理时，排查问题需要看到完整的执行过程。4.11 更新了统一执行视图、工具调用追踪和实时处理中面板。
日常检查可以按这条顺序进行：先看事件有没有进入，再看交给了哪个处理器，最后查看模型与工具调用是否完成。这样更容易区分平台接入问题、路由配置问题和执行阶段的问题，而不是仅凭“机器人没有回复”猜测原因。
账号安全与操作记录
实机账号设置展示 Passkey 和两步验证入口；截图中的演示账号尚未启用这些功能。
4.11 新增 WebAuthn Passkey 登录和 TOTP 两步验证，并提供记录每次操作变更的操作日志及完整性校验。对于多人维护的工作区，这些能力分别帮助加强登录保护、追踪“谁改了什么”。Passkey 的使用还需要满足浏览器安全上下文等条件，应在合适的 HTTPS 部署环境中配置。
媒体存储也有调整：媒体按内容去重存储，减少重复媒体导致的 langbot.db 膨胀。此外，lbctl 和 API Key 提供了管理与诊断实例的命令行入口，适合把日常检查接入已有运维流程。
五、新用户更容易开始，老用户按步骤升级
新手引导从平台选择开始，再进入机器人配置与 AI 引擎设置。
第一次使用 LangBot，可以跟随侧边栏引导和场景化机器人创建向导，从平台、机器人配置、AI 引擎逐步完成设置。建议先验证一个简单问答流程，再添加知识库、工具和事件路由，避免同时引入太多变量。
已有实例升级，建议按下面的顺序处理：
- 先备份
data/目录或 PostgreSQL 数据库，建议从最新 v4.10.x 升级，并保留当前部署配置。 - 升级 Core 与配套 Runtime，检查服务连接状态。4.11.0 正式版固定使用 SDK
0.7.11，不要混用旧 Runtime。 - 完成流水线迁移并更新插件，检查迁移后的运行器及配置，注意新会话边界。
- 验证真实业务链路：先测试一个已有的消息问答，再逐步验证新事件路由和授权工具。
- 检查遥测与配置变化：新增执行遥测默认开启，不含消息内容；可用
space.disable_telemetry: true关闭这一遥测。配置新增media_cache、api.host、runner.admin_plugins，移除force_box_session_id_template。详见数据收集政策及正式发布说明。
开始使用 LangBot 4.11
4.11 的价值不在于新增了多少配置项，而在于把三个问题连起来：什么事件触发任务、由什么执行方式处理、怎样安全地管理和观察它。 你可以继续保留熟悉的消息问答，也可以逐步把社区协作、业务通知与交互任务放进同一套管理界面。
感谢所有参与本次版本开发、测试、文档和问题反馈的贡献者。本文围绕主要更新展开，完整贡献者名单见正式发布说明。
配图说明：事件路由与运行器插件总览来自 v4.11.0 GitHub Release，其余五张截图来自为本文独立运行的官方 rockchin/langbot:v4.11.0 实例。实机截图使用英文界面便于跨语言对照；没有连接生产机器人，也没有将演示界面描述为真实业务运行结果。