LangBot 4.11：Runner插件化卡在"运行方式"

团队已经在用 Claude Code 和 Codex 干活，仓库、shell、MCP 服务器全在自己机器上。可同事想从企业微信、飞书、钉钉的群里调用同样的能力，不想开终端——这件事在 4.10 上很别扭。

别扭的地方不在入口。4.10.11 的 src/langbot/pkg/platform/sources/ 下已经躺着 openclaw_weixin、lark、dingtalk 三个来源。真正卡住的是处理侧：src/langbot/pkg/provider/runners/ 里是九个内置运行器，localagent.py、difysvapi.py 一直到 weknoraapi.py。想加 Claude Code，要么改 LangBot 本体，要么把 CLI 包成 HTTP 服务挂在机器人外面。

4.11 把这件事翻了个面：Runner 变成插件，平台只负责当事件源。能不能用，取决于适配器和平台，先看支持矩阵再动手。

内置运行器被整个拿掉了

对比两个版本的文件树很直接：src/langbot/pkg/provider/runners/ 在 v4.10.11 有十个文件，到 v4.11.0 这个目录不存在了；src/langbot/pkg/provider/ 只剩 modelmgr/、session/、tools/ 三个。

Runner 现在是插件组件。运行时通过 LIST_RUNNERS 上报已安装插件里的运行器，宿主在 RunnerRegistry（src/langbot/pkg/agent/runner/registry.py:20,24,152）里发现并缓存，id 按 plugin:author/plugin_name/runner_name 生成（id.py:24-27），不带这个前缀的一律拒绝（id.py:52-57；PROTOCOL_V1.md §13）。

清单文件就是契约：id、name、label、description、capabilities、permissions、config_schema、metadata（§4.2）。capabilities 是给 UI 和资源投影用的类型化布尔模型，不是权限授予；permissions 才是访问上限，还要和绑定策略取交集。官方 id 有两个：plugin:langbot-team/ClaudeCodeAgent/default 和 plugin:langbot-team/CodexAgent/default。

4.11 同时新增了适配器层。src/langbot/pkg/platform/adapters/ 在 v4.10.11 不存在，4.11 把它拆成十二个包，每个带 manifest.yaml、adapter.py、event_converter.py，飞书的清单里声明 kind: MessagePlatformAdapter。入站文件清单没变：两个版本之间 sources/ 下 22 个文件全是修改，没有新增也没有删除——所以这里并没有多出新的平台。

配置落在哪：ai.runner.id 存运行器 id，ai.runner_config[] 存它的设置（src/langbot/templates/metadata/pipeline/ai.yaml:6-18），换运行器时之前的设置还在。

动手：两个容器起步

Runner 插件在独立的 plugin-runtime 容器里执行，所以是双容器部署。先建网络，再起核心容器和运行时容器，运行时容器要挂同一个 plugins 目录，并设置网络别名 langbot_plugin_runtime。管理账号初始是 admin@langbot.local，密码是本地演示值，记得换掉。

第一步，从市场安装。界面路径是扩展 → 扩展市场；命令行走 POST /api/v1/plugins/install/marketplace，带 {plugin_author, plugin_name}，返回 {task_id} 对应 plugin-install-marketplace 任务，记录里 install_source=marketplace。这里装的是 langbot-team/LocalAgent；Claude Code 和 Codex 插件走同一扇门，仓库 langbot-plugins 下的 Runner/claude-code-agent 和 Runner/codex-agent。

第二步，确认它落在哪。产物不在挂载的 plugins/ 目录里，而在运行时容器内的 /app/data/plugin-runtime/artifacts/sha256//code/，里面有 manifest.yaml、main.py、pkg/、components/、CERTIFICATION.md；宿主挂载的 plugins/ 反而是空的。三个检查点：API 用 GET /api/v1/plugins 返回的数组里有没有它；数据库里 plugin_settings 有没有一行带着 artifact_digest、runtime_revision、install_source、enabled；日志里是否出现 Mounting plugin → Initializing Runner component: default → Component default initialized, instance type: DefaultRunner。关键在最后一句：运行时实例化的是组件实例，Runner 能力挂在这个实例上。

第三步，在流水线里选运行器。打开流水线编辑器的 AI 能力，找到标着"运行方式"的阶段卡片，里面那个必填的"运行器"下拉框，值要填完整 id，比如 plugin:langbot-team/LocalAgent/default；用 Claude Code 就填 plugin:langbot-team/ClaudeCodeAgent/default。这里 LocalAgent 的 ai.runner_config[] 读出来是 timeout: 300、max-tool-iterations: 100。

第四步，把聊天平台接成事件源。接上企业微信、飞书或钉钉适配器，事件进来，事件绑定把它路由进流水线，选中的 Runner 干活——一个机器人可以挂多条流水线，每条各用各的 Runner。

Claude Code 和 Codex 的参数来自各自 README：command 默认 claude / codex，timeout 默认 300 / 1800 秒，另有 workspace、ssh-target、mcp-servers-json。

验证与几个坑

API 返回里 langbot-team/LocalAgent 的 enabled 要为 true；数据库里 digest 和 revision 要落盘；运行时容器里 ls 能看到上面那批文件，而宿主挂载的 plugins/ 仍为空——空结果说明你看错了层。流水线里 ai.runner.id 必须以 plugin: 开头，ai.runner_config 要有一个以该 id 为键的对象。最后发一条真实消息，确认回复来自装好的 Runner。

几个需要留意的点：

• 平台只是事件源。入站 sources/ 的文件集和 4.10.11 一致，4.11 加的是 adapters/ 事件适配层；平台能不能用由适配器加事件绑定决定，不是 Runner 决定。01-event-system.md 里的支持矩阵，文档自己说是初步评估。
• 市场安装需要出网。归档从 {space_url}/api/v1/marketplace/plugins/download/{author}/{name}/{version} 拉取；从 GitHub 或本地归档安装则记为 github / local。
• 产物是内容寻址的。市场侧的 digest 不一定等于你本地的，拿 plugin_settings.artifact_digest 去比——这里两个 LocalAgent 0.2.1 的 digest 就不一样。
• 外部 CLI 运行器默认很宽松。ClaudeCodeAgent 把 dangerously-skip-permissions 默认为 true（设成 false 会恢复 Claude Code 自己的检查，LangBot 目前没有交互式审批流），CodexAgent 默认 approval-policy=never、sandbox-mode=danger-full-access。只在可信工作区里用。
• 交互不是挂起等待。两个 CLI 运行器会把 ask_user_question 这类请求转成 interaction.requested，交给适配器渲染成卡片；CLI 停下等用户回答，回答再启动一次新运行，续上同一个会话。
• harness 路径还是 MVP。协议文档写明外部 harness 运行器目前是 MVP / 开发路径：证明协议能接通，不是发布级的安全边界，也不是完工的 Docker 可部署性（PROTOCOL_V1.md §13）。
• 认证字段会打架。这里 install_info._certification 读出 verification: "invalid"、certificate_id: null，而市场报的是 certificate_status: "issued"——别因为插件在架上就假定本地验证过了。

一句话收束：4.11 里 Runner 不再随 LangBot 出货，而是从市场装、在应用里配、按流水线选。平台负责送事件，Runner 决定怎么处理——本地 CLI 代理（Claude Code、Codex、ACP），或者 Dify、Coze、n8n、Langflow、DeerFlow 这类服务型运行器。

主要参考是钉住的迁移文档 pipeline-migration-config-map.zh-CN.md，里面也列了迁移器要求的最低 Runner 插件版本；v4.11.0 发布页有说明。插件同样列在 langbot-plugins 的 Runner/ 下。下一步：如果你的实例是从 4.10 升上来的，旧配置落到新形状里是另一篇文章的事——迁移会同时动 ai.runner.runner、ai.runner.id 和 ai.runner_config。