feat(agent): prepare 4.11.x EBA and AgentRunner integration

[huanghuoguoguo]

Scope

This PR prepares the 4.11.x integration branch for LangBot. It brings together the EBA adapter foundation and the AgentRunner pluginization host work.

Included in this branch:

• Event-based adapter structure and platform adapter implementations for supported IM platforms.
• AgentRunner Protocol v1 host infrastructure: runner discovery, binding/config projection, run orchestration, event log, transcript, persistent state, run ledger, and run-scoped pull APIs.
• Plugin runtime action handlers for AgentRunner resources, state, history/events, steering, run ledger, and minimal runtime control-plane primitives.
• Removal of the old built-in provider runner path in favor of pluginized AgentRunner components.
• Pipeline/preproc tests aligned with the pluginized runner path.
• Status docs updated for the current 2026-06-23 state.

Linked branches and companion PRs

This PR is part of the 4.11.x AgentRunner integration set and should be reviewed/tested with the matching SDK branch:

Repository	Branch / PR	Purpose
langbot-app/LangBot	dev/4.11.x -> master, #2277	Host-side EBA and AgentRunner integration branch.
langbot-app/langbot-plugin-sdk	dev/4.11.x -> main, langbot-app/langbot-plugin-sdk#88	Matching SDK protocol/entity/runtime support required by this LangBot branch.
langbot-app/langbot-local-agent	main, README.md	Official local AgentRunner plugin consuming Protocol v1 through the host APIs.
langbot-app/langbot-agent-runner	main, README.md	Official external-service AgentRunner plugin set and Protocol v1 consumer guidance.
langbot-app/langbot-agent-control-plane	main, README.md	Control-plane plugin for host-owned run/runtime/descriptor inspection and admin actions.

Joint test surface

Use this PR together with the SDK companion PR and the three AgentRunner plugin repositories above:

• LangBot must run against the local editable langbot-plugin-sdk from dev/4.11.x / PR [ENHANCE]使用限制，忽略某人私聊，忽略某群消息，忽略某群中某人消息 #88.
• langbot-local-agent/README.md documents the in-process local runner path that exercises host model, prompt, history, tool, knowledge-base, state, and storage pull APIs.
• langbot-agent-runner/README.md documents the external-service runner path, including run-scoped Host API/MCP access patterns and steering expectations.
• langbot-agent-control-plane/README.md documents the admin plugin path for listing runs, runtimes, descriptors, event pages, reconciliation, and cancellation.

These repositories form the cross-repo validation set for AgentRunner Protocol v1 compatibility.

Current status

Done / unit covered:

• SDK manifest schema, runner discovery, host resource authorization, run authorization snapshot, and result payload validation.
• Skill activation has been moved to the skill-as-tool model; activate persists host.activated_skills best-effort and later runs restore from pipeline-visible skills.
• Runtime Control Plane v2 foundation exists: host-owned run/event ledger, run control actions, runtime register/heartbeat/list/reconcile, and run claim/renew/release primitives.

Still intentionally out of scope for this PR:

• Full Agent Platform product UI.
• Daemon supervisor, runtime wakeup channel, distributed runtime management, and cross-host locking.
• Full product E2E and real-provider smoke for every official runner.

Verification

LangBot was tested against the local editable langbot-plugin-sdk from the matching dev/4.11.x branch.

• 467 passed, 64 warnings
• Covered: tests/unit_tests/agent, tests/unit_tests/plugin/test_handler_actions.py, tests/unit_tests/provider/test_skill_tools.py, pipeline chat/preproc/media fallback tests, and Telegram EBA adapter tests.
• Import smoke confirmed LangBot can load SDK agent_runner entities from the local SDK branch.

[huanghuoguoguo]

这里建议把 EBA / Agent 编排相关文档口径再收敛一下，避免把目标形态和当前实现混在一起。

我理解当前更准确的分层是：

事件源
  ├─ IM 平台
  ├─ GitHub / GitLab / Jira / Linear webhook
  ├─ 内部业务系统
  ├─ Scheduler
  ├─ Monitoring / CI/CD
  └─ WebUI / API

EventGateway / adapter
  -> canonical event / EBAEvent
  -> Bot event_bindings / future EventRouter
  ├─ target_type=agent
  │    -> 产品层 Agent 编排实例
  │    -> AgentBinding
  │    -> AgentRunOrchestrator.run(event, binding)
  │    -> AgentRunner
  ├─ target_type=pipeline
  │    -> legacy Pipeline，仅 message.*
  └─ target_type=discard

几个关键判断：

1. Agent 确实是从原来 Pipeline 里的 AI/agent 阶段被抽出来，变成一等公民。它现在有独立 agents 表、/home/agents 产品入口，并且可以通过 Bot event_bindings 直接绑定事件。

2. 但这不等于 Pipeline 被 Agent 吃掉。当前更像是 /home/agents 作为统一管理入口，里面有两类同级处理单元：Agent 编排面向 EBA / AgentRunner，可以处理 message、group、friend、bot、feedback、platform 乃至未来 GitHub/internal/scheduler 等事件；Pipeline 是兼容保留的消息流水线，只处理 message.*。

3. 对产品层 Agent 来说，背后的实现应该一视同仁：local-agent、外部 runner、Dify、n8n、Coze、DashScope、webhook、未来 workflow runner，本质都应该收敛成 runner_id + runner_config + resource/state/delivery policy，再投影为 AgentBinding，最后走 AgentRunner 协议。

4. 插件 EventListener 不是 Agent 的同级响应者，而是观察者广播链路。它可以做审计、风控、统计、拦截，并且可以 prevent_default；但不应该被收编进 AgentRunner 抽象。

5. 当前实现不是完整通用 EventGateway -> EventRouter 已经落地。代码里已经有 bot 侧 EBAEvent -> event_bindings -> target agent/pipeline/discard 的轻量路由，并且命中 Agent 时会构造 AgentEventEnvelope + AgentBinding 调 AgentRunOrchestrator.run()。但完整 EventGateway/EventRouter、跨 workspace/project/integration 的 binding scope、通用 webhook/scheduler/internal event 接入，仍应视为后续平台化能力。

因此建议文档上做两个调整：

• docs/event-based-agents/07-agent-orchestration.md 标清为早期方向稿/目标讨论，不再作为当前实现口径。里面 “pipeline-wrapper 收编 Pipeline”、“SDK 第七种 Agent 组件”、“所有 handler 统一为 Agent” 这些表述已经和当前 AgentRunner Protocol v1 / 08 文档有偏差。
• docs/event-based-agents/08-agent-page-and-event-orchestration.md 作为当前产品口径继续推进：Agent 页面统一管理 Agent 编排与 Pipeline，但运行语义保持分层；Agent 编排走 AgentRunOrchestrator.run(event, binding)，Pipeline 走 legacy message pipeline。

更宏观一点，这个设计的价值不只是 IM Bot。IM 是当前落点，因为 LangBot 既有资产在 platform adapter、bot、message pipeline 和投递能力上。但 AgentEventEnvelope + AgentBinding + AgentRunOrchestrator 的上限应该是事件驱动 Agent Host：GitHub webhook、内部系统事件、监控告警、CI/CD、定时任务、审批事件、知识库变更事件都可以被标准化成 event，再绑定到 Agent 执行。