OpenClaw 24h 更新快报（2026-04-03）：插件激活模型、TaskFlow 运行时与跨渠道审批路由
过去 24 小时，OpenClaw 主线合并了 44 个 PR，涵盖插件激活模型的全面重构、TaskFlow 运行时 API 的正式落地、跨渠道执行审批路由的修复，以及 Provider 请求策略的进一步统一。值得关注的变化是：插件加载策略从"全量启用快照"转向"显式激活来源追踪"，TaskFlow 现在支持插件创建托管子任务，Android 端要求远程 Gateway 必须使用 TLS 连接。
插件激活与加载体系重构
这是本周期最核心的变更集，跨越多个 PR 协同完成。核心问题是此前插件状态只有 enabled/activated 两个维度，但无法区分"配置中声明启用"和"代码实际已被加载到当前进程"——这两个状态在进阶场景下会产生行为差异。
PR #59641 重构了激活来源追踪机制：插件加载时现在会保留 explicit（显式配置）还是 auto-enabled（自动启用）的来源元数据，并将激活状态传递到运行时注册表、CLI 状态工具和 doctor 工作区诊断中。PR #59844 则将 activation（激活）和 enablement（启用）彻底分离——此前这两个概念被混用在插件状态字段中，现在 activation 仅指"代码是否已加载进进程"，enablement 指"配置是否声明该插件应被考虑"。
在此基础上，PR #59659 为插件状态报告新增了 imported 维度：通过 plugins list --verbose 和 plugins list --json 现在可以观察到每个插件的代码是否真正被导入到当前进程，而 doctor 工作区的插件备注中也新增了"Imported: N"统计。PR #59865 和 PR #59856 则进一步优化了 Provider 运行时解析路径，让 Web Search 和 Web Fetch 的快照复用能够在激活来源追踪的语义下正确工作。
在性能方面，PR #59754 将 Gateway 冷启动时的插件加载范围限制为"仅渠道插件"——Provider、Memory 和 Web Search 这类运行时路径不再在 Gateway 空闲启动时被预加载，保留按需懒加载。这一改动直接影响 Gateway 的启动速度和内存占用。
TaskFlow 运行时 API 落地
本周期 TaskFlow 完成了从内部状态管理到可编程运行时的关键跨越。PR #59622 为插件 SDK 新增了 api.runtime.taskFlow 命名空间，暴露给插件和可信创作层使用此前内部维护的 TaskFlow 生命周期操作，包括 createManaged、get、list、findLatest、cancel 以及子任务执行接口。PR #59610 则基于这一层新增了托管子任务的创建能力：TaskFlow 现在可以在自身生命周期内生成子任务（runTaskInFlow），取消行为也升级为 sticky 语义——一旦请求取消，TaskFlow 会立即停止调度新子任务，并在现有子任务全部结束后才迁移到 cancelled 状态。
CLI 侧也同步进行了清理：PR #59757 移除了顶层的 openclaw flows 别名命令，统一为 openclaw tasks flow，默认文本输出也精简为面向运维视角的字段，原始内部字段仅通过 --json 暴露。PR #59672 则增强了 TaskFlow 的恢复韧性——Registry 恢复失败时降级为审计发现而非崩溃首次访问，同时新增了 TaskFlow 审计和清理机制并接入 openclaw tasks audit 和 openclaw tasks maintenance。
跨渠道执行审批路由修复
执行审批（exec approval）在本次更新中修复了多个渠道的特殊路径问题。PR #59776 修复了一个核心回归：Telegram 执行审批在配置了 channels.telegram.execApprovals.target（如 dm/channel/both）但未显式设置 execApprovals.enabled: true 时，会错误地报告"此平台不允许审批"。根本原因是 getActionAvailabilityState 同时检查了 hasApprovers 和 isNativeDeliveryEnabled 两个条件，而 native delivery 模式是下游路由问题，不应作为审批能力本身的前置门控。
Telegram 渠道自身也有两项针对性修复：PR #59760 集中管理了审批回调的 callback_data 字节边界处理（覆盖 63/64/65 字节边界情况），确保长插件审批 ID（plugin:<uuid> 格式）在 Telegram 64 字节限制下不会被截断。PR #59733 则将 Telegram 的 /approve ... allow-always 回调中的 alias 从 allow-always 改写为 always，以符合 Telegram callback_data 的格式约束。
Provider 请求策略统一与扩展集成
Provider HTTP 请求路径的架构统一工作继续推进。PR #59682 将 Provider 传输策略（认证头、额外请求头、代理和 TLS 配置）统一到共享的请求配置解析路径上，OpenAI、Moon 和 WebSocket 传输现在使用同一套 Policy 解析逻辑。PR #59653 则进一步将 endpoint 策略、能力解析和 Header 优先级整合为单一 resolveProviderRequestPolicy 接口。
在图像生成场景下，PR #59729 将 OpenAI、MiniMax 和 fal 的图像生成请求统一路由到共享 Provider HTTP 传输路径，共享 base URL 标准化、私有网络保护和请求头合并逻辑。PR #59608 则将 Anthropic 的 api.anthropic.com 官方端点识别迁移到共享 endpoint 分类器中，此前这类判断逻辑散落在各个 Provider 的 stream wrapper 中。
安全与隐私：内部上下文泄漏封闭与平台加固
PR #59649 是本周期重要的隐私修复，封闭了 Agent 运行时内部上下文在多个用户可见表面的泄漏路径。问题出在 /tasks、/subagents info、/acp status 等命令的格式化逻辑中，直接输出了包含 OpenClaw runtime context (internal) 块的原始运行时状态文本，或暴露了 Exec denied (...) 这类原始执行拒绝详情。该 PR 新增了 sanitizeTaskStatusText 和 sanitizeUserFacingText 两个共享函数，集中处理这类清理逻辑，覆盖了任务状态、命令响应和执行审批后续通知等完整路径。
Android 平台的安全加固也在本周期落地：PR（Android TLS） 要求 Android 客户端在连接远程 Gateway 时必须使用 TLS，并加强了扫码入网时的 endpoint 校验逻辑，防止中间人攻击。此外，PR #59555 修复了 Subagent 场景下的设备配对问题：sessions_spawn 调用由于没有显式声明 scope，Gateway Client 的首次连接会以最低 scope 配对，后续需要更高权限的操作（如 sessions.patch）会触发 scope-upgrade 握手，而 headless 场景下无法完成该握手，导致 close(1008)"pairing required"。修复方式是将 callSubagentGateway 固定为 operator.admin scope，确保 Loopback 场景下第一次握手就以最高权限完成，后续不再触发 upgrade。
其他值得注意的变化
PR #59466 在 Windows 平台上为 exec 路径的子进程添加了 windowsHide: true，避免了执行命令时弹出可见的控制台窗口，这是一个对桌面用户体验有直接改善的小修复。PR（JSON5 插件清单） 将插件清单（plugin manifest）的解析从 JSON 切换到 JSON5，以容忍清单中出现的尾随逗逗等非标准但常见的写法，提升了插件加载的健壮性。PR（Android TLS） 还修复了 Android 端 IPv6 Gateway URL 的解析和括号保留问题，确保 IPv6 地址格式的 Gateway URL 在 Android 客户端上正确工作。
在 xAI 集成方面，PR #59674 将 x_search 的配置从核心的 tools.web.x_search.* 迁移到插件所有的 plugins.entries.xai.config.xSearch.*，x_search 的认证也统一到共享 xAI web-search 认证路径，PR #59691 则进一步将 tools.web.x_search.apiKey 从核心 schema 和 SecretRef 表面移除，遗留配置会在普通 config-load 和 openclaw doctor --fix 时自动迁移。
本周期还合并了大量内部架构清理，包括 Discord/Matrix/Groups Runtime 的 barrel 导入收窄（多处 size: XS 的 seam 调整）、macOS exec-host JSONL socket 的 deadlock 修复（通过 half-close 写侧避免 server 的 readLineFromHandle 等待 EOF），以及多个平台渠道（WhatsApp、Slack、Mattermost、QQBot、Zalo）的安全或健壮性补丁。
总体来看，本次更新以插件激活模型的语义升级和 TaskFlow 运行时的正式开放为主线，辅以跨渠道审批路由和 Provider 请求策略的架构统一。安全相关的内部上下文清理和 Android TLS 加固则填补了长期存在的用户可见信息泄漏和平台信任边界问题。
评论