OpenClaw多平台渠道插件生命周期管理：server-channels.ts架构设计与实战

1. 项目概述：一个渠道插件的“大管家”

如果你正在或打算基于 OpenClaw 框架构建一个多平台集成的智能体应用，比如一个能同时在微信、飞书、钉钉上提供服务的客服机器人，那么你迟早会碰到一个核心的工程难题：如何优雅、统一地管理这些不同渠道插件的“生老病死”？server-channels.ts这个文件，就是为解决这个问题而生的。你可以把它理解为你整个渠道体系的“大管家”或“生命周期管理器”。

在 OpenClaw 的架构里，一个“渠道”（Channel）通常指代一个具体的通讯平台接入点，比如飞书机器人、微信小程序、WebSocket 服务等。每个渠道都需要一个对应的插件（Plugin）来实现具体的消息收发、协议解析和事件处理。当你的应用需要接入多个渠道时，这些插件的初始化、启动、运行状态监控、错误处理和优雅关闭就变得异常复杂。server-channels.ts的核心职责，就是将这套混乱的流程标准化、模块化，确保所有渠道插件都能在统一的调度下稳定运行，并且在出现问题时，不会“一颗老鼠屎坏了一锅粥”。

简单来说，它解决了几个关键痛点：一是避免了在应用主入口文件中堆积大量渠道初始化代码，让主逻辑保持清晰；二是提供了统一的启动、停止和健康检查接口，便于运维和部署；****三是**实现了插件间的隔离，一个渠道的崩溃不会直接影响其他渠道；四是为未来的动态加载、热更新等高级特性打下了基础。对于任何需要严肃部署 OpenClaw 到生产环境的团队来说，理解和实现这样一个管理器，是迈向稳定服务的第一步。

2. 核心架构设计与实现思路

2.1 为什么需要专门的生命周期管理器？

在小型或原型项目中，我们可能会简单粗暴地在index.ts或app.ts里直接new出各个渠道插件实例，然后调用它们的start()方法。这种做法在渠道数量少、逻辑简单时勉强可行，但一旦规模扩大，问题就会接踵而至。

首先，初始化顺序可能产生依赖问题。例如，某些插件可能需要依赖全局的数据库连接池或配置中心先就绪。其次，错误处理变得棘手。如果飞书插件启动失败，你是应该让整个应用崩溃，还是记录日志后继续启动微信插件？再者，优雅关闭（Graceful Shutdown）难以实现。当收到终止信号（如SIGTERM）时，你需要确保每个插件都能完成当前正在处理的消息，并释放资源（如网络连接、文件句柄），而不是被强行杀死。最后，缺乏统一的状态视图。你很难快速回答“当前有哪些渠道在运行？它们健康吗？”这类运维问题。

server-channels.ts通过引入“管理器”模式，将渠道插件视为需要被管理的资源，抽象出init,start,stop,healthCheck等生命周期钩子，并由一个中心化的ChannelManager类来协调执行。这本质上是控制反转（IoC）和模板方法模式的结合应用，将插件的具体实现与生命周期控制逻辑解耦。

2.2 管理器类的核心接口设计

一个健壮的生命周期管理器，其核心接口设计必须清晰且具备扩展性。以下是一个典型的ChannelManager类接口设计思路：

// 定义渠道插件必须实现的生命周期接口 interface ChannelPlugin { name: string; init(config: any): Promise<void>; start(): Promise<void>; stop(): Promise<void>; healthCheck(): Promise<{ healthy: boolean; details?: any }>; } // 渠道管理器类 class ChannelManager { private plugins: Map<string, ChannelPlugin> = new Map(); private isRunning: boolean = false; // 注册插件 register(plugin: ChannelPlugin): void { if (this.plugins.has(plugin.name)) { throw new Error(`Channel plugin "${plugin.name}" is already registered.`); } this.plugins.set(plugin.name, plugin); } // 初始化所有插件（依赖注入、配置加载等） async initializeAll(configs: Record<string, any>): Promise<void> { for (const [name, plugin] of this.plugins) { const config = configs[name] || {}; try { await plugin.init(config); console.log(`[ChannelManager] Plugin "${name}" initialized successfully.`); } catch (error) { console.error(`[ChannelManager] Failed to initialize plugin "${name}":`, error); // 策略选择：可以抛出错误终止所有初始化，也可以记录后继续 // 这里选择记录错误并继续，保证其他插件有机会启动 } } } // 启动所有插件 async startAll(): Promise<void> { if (this.isRunning) { throw new Error('ChannelManager is already running.'); } this.isRunning = true; const startPromises = []; for (const [name, plugin] of this.plugins) { // 注意：这里使用 Promise 来捕获每个插件启动的独立错误，避免一个失败影响全部 const promise = plugin.start().then(() => { console.log(`[ChannelManager] Plugin "${name}" started successfully.`); }).catch((error) => { console.error(`[ChannelManager] Failed to start plugin "${name}":`, error); // 即使启动失败，也不抛出，而是记录。管理器保持运行状态，其他插件不受影响。 }); startPromises.push(promise); } // 并发启动所有插件，提高启动速度 await Promise.allSettled(startPromises); console.log('[ChannelManager] All plugins startup attempts completed.'); } // 停止所有插件（优雅关闭） async stopAll(): Promise<void> { if (!this.isRunning) { return; } this.isRunning = false; const stopPromises = []; // 通常建议逆序停止，模拟栈的行为，但并非绝对必要 const pluginsArray = Array.from(this.plugins.values()).reverse(); for (const plugin of pluginsArray) { const promise = plugin.stop().then(() => { console.log(`[ChannelManager] Plugin "${plugin.name}" stopped successfully.`); }).catch((error) => { console.error(`[ChannelManager] Error stopping plugin "${plugin.name}":`, error); }); stopPromises.push(promise); } // 设置一个全局超时，防止某个插件 stop 方法卡死 const timeoutPromise = new Promise((_, reject) => { setTimeout(() => reject(new Error('Stop operation timeout after 30s')), 30000); }); try { await Promise.race([Promise.allSettled(stopPromises), timeoutPromise]); } catch (timeoutError) { console.error('[ChannelManager] Force shutdown due to timeout:', timeoutError); } console.log('[ChannelManager] All plugins have been stopped.'); } // 获取所有插件健康状态 async getHealthStatus(): Promise<Record<string, any>> { const status: Record<string, any> = {}; const checkPromises = []; for (const [name, plugin] of this.plugins) { const promise = plugin.healthCheck().then(health => { status[name] = health; }).catch(error => { status[name] = { healthy: false, error: error.message }; }); checkPromises.push(promise); } await Promise.allSettled(checkPromises); status.manager = { healthy: this.isRunning }; return status; } }

注意：上面的Promise.allSettled是关键。在启动和停止阶段，我们不希望因为一个插件的失败而中断整个流程。allSettled会等待所有 Promise 完成（无论成功或失败），这符合微服务架构中“隔离故障”的设计原则。

2.3 与 OpenClaw 核心的集成点

server-channels.ts并不是一个孤立的模块，它需要与 OpenClaw 的核心应用上下文（Application Context）紧密集成。通常，这个管理器会被实例化并挂载到全局的 App 对象或依赖注入容器中。

集成时机：

1. 应用启动时：在 OpenClaw 核心服务（如技能路由、记忆存储）初始化之后，调用channelManager.initializeAll()和channelManager.startAll()。
2. 应用关闭时：在接收到退出信号后，先调用channelManager.stopAll()，确保所有渠道的消息处理完毕、连接关闭，再关闭数据库等核心资源。
3. 健康检查端点：可以暴露一个/health/channels的 HTTP 端点，其处理器直接调用channelManager.getHealthStatus()，方便容器编排平台（如 Kubernetes）进行存活性和就绪性探测。

配置管理：每个渠道插件的配置（如飞书的 App ID/Secret、微信的 Token）应该通过统一的配置管理系统（如环境变量、ConfigMap、配置中心）来获取。管理器在initializeAll阶段将这些配置分发给对应的插件。这样做的好处是，渠道的增删和配置变更，完全不需要改动核心业务代码。

3. 关键实现细节与避坑指南

3.1 插件注册与依赖注入的优雅实现

在实际项目中，我们可能有很多渠道插件，手动new出每个插件并调用manager.register()会很繁琐。更优雅的方式是利用装饰器（Decorator）或模块扫描实现自动注册。

方法一：使用装饰器（推荐用于中型项目）

// 定义一个全局的插件注册表（简化版） const pluginRegistry: ChannelPlugin[] = []; function RegisterChannel(metadata?: { name?: string }) { return function (constructor: new () => ChannelPlugin) { const pluginInstance = new constructor(); pluginInstance.name = metadata?.name || constructor.name; pluginRegistry.push(pluginInstance); }; } // 在插件类上使用装饰器 @RegisterChannel({ name: 'feishu' }) class FeishuChannelPlugin implements ChannelPlugin { name = 'feishu'; // 装饰器会覆盖这个值 // ... 实现其他方法 } @RegisterChannel({ name: 'wechat' }) class WeChatChannelPlugin implements ChannelPlugin { name = 'wechat'; // ... } // 在管理器中，可以直接从 registry 加载 class ChannelManager { async autoRegister() { for (const plugin of pluginRegistry) { this.register(plugin); } } }

方法二：动态导入（适用于插件化架构）如果你的插件被打包成独立的模块（如单独的 npm 包或文件），可以使用动态导入。

// 假设有一个 plugins 目录，里面是各个渠道的入口文件 const pluginDir = path.join(__dirname, 'plugins'); const pluginFiles = fs.readdirSync(pluginDir).filter(f => f.endsWith('.js') || f.endsWith('.ts')); for (const file of pluginFiles) { const modulePath = path.join(pluginDir, file); // 动态导入模块，获取导出的插件类或实例 const module = await import(modulePath); const PluginClass = module.default; // 假设默认导出 const pluginInstance = new PluginClass(); this.register(pluginInstance); }

实操心得：使用装饰器会让代码更简洁，但需要你的构建工具（如 ts-node、Babel）支持装饰器语法。动态导入的方式更灵活，支持真正的热插拔，但要注意模块路径和循环依赖问题。对于大多数 OpenClaw 项目，我推荐使用装饰器，因为它编译时就能发现错误，且与 TypeScript 结合得更好。

3.2 错误处理与熔断机制

渠道插件在运行中难免出错，比如第三方平台 API 临时不可用、网络抖动、消息格式异常等。管理器的错误处理策略直接关系到系统的整体韧性。

分层错误处理策略：

1. 插件内部捕获：每个插件在自己的start,stop,healthCheck以及消息处理循环中，必须用try-catch包裹核心逻辑，将未知错误转化为可预期的错误状态或日志，避免抛出未捕获的异常导致整个 Node.js 进程崩溃。
2. 管理器隔离：如上文代码所示，管理器使用Promise.allSettled，确保一个插件的启动/停止/健康检查失败不会波及其他插件。
3. 熔断与降级：在healthCheck方法中，插件可以实现简单的熔断逻辑。例如，连续 5 次调用第三方 API 失败，则标记自身为不健康，并在start方法中进入“降级”模式（如返回静态提示信息），而不是不断重试导致雪崩。管理器可以通过定期健康检查来感知这种状态。

日志与监控：所有错误都必须被结构化日志记录，并关联上插件名、错误码和上下文信息。这便于通过 ELK（Elasticsearch, Logstash, Kibana）或类似工具进行聚合分析。同时，可以将健康状态上报到监控系统（如 Prometheus），当某个渠道长时间不健康时触发告警。

3.3 资源清理与优雅关闭的实现

“优雅关闭”是生产级应用的基本要求。对于渠道插件，需要清理的资源通常包括：

• HTTP/WebSocket 服务器：关闭监听端口。
• 长连接：如 WebSocket 连接、与消息队列的连接。
• 定时器：清除setInterval或setTimeout。
• 文件描述符：关闭打开的文件或数据库连接（虽然数据库连接通常由全局池管理）。

实现要点：

• stop方法必须是幂等的：多次调用stop()应该产生相同的效果（即资源被清理），且不会报错。
• 设置超时：如上文代码所示，为整个停止过程设置一个全局超时（如 30 秒）。如果超时，则记录错误并强制退出，避免应用无法正常终止。
• 处理 SIGTERM 和 SIGINT：在你的主应用文件中，需要监听系统信号。

// index.ts 或 main.ts const manager = new ChannelManager(); // ... 注册和初始化插件 const gracefulShutdown = async (signal: string) => { console.log(`\nReceived ${signal}, starting graceful shutdown...`); await manager.stopAll(); // 关闭其他全局资源，如数据库连接池 process.exit(0); }; process.on('SIGTERM', () => gracefulShutdown('SIGTERM')); process.on('SIGINT', () => gracefulShutdown('SIGINT'));

4. 实战：构建一个飞书渠道插件并接入管理器

让我们以接入飞书机器人为例，演示如何构建一个符合生命周期管理接口的插件，并集成到管理器中。

4.1 飞书插件基础实现

首先，安装必要的 SDK：npm install @larksuiteoapi/node-sdk。

// plugins/feishu-plugin.ts import * as lark from '@larksuiteoapi/node-sdk'; import { ChannelPlugin } from '../types'; // 假设你定义了上面的接口 export default class FeishuChannelPlugin implements ChannelPlugin { name = 'feishu'; private client: lark.Client; private eventDispatcher: lark.EventDispatcher; private isHealthy: boolean = true; private failureCount: number = 0; async init(config: { appId: string; appSecret: string; verificationToken?: string; encryptKey?: string; }): Promise<void> { // 1. 创建飞书客户端 this.client = new lark.Client({ appId: config.appId, appSecret: config.appSecret, disableTokenCache: false, }); // 2. 创建事件分发器（用于接收消息） this.eventDispatcher = new lark.EventDispatcher({ verificationToken: config.verificationToken, encryptKey: config.encryptKey, }); // 3. 注册事件处理器（这里以接收文本消息为例） this.eventDispatcher.register({ 'im.message.receive_v1': async (data: any) => { const { message } = data; if (message.message_type !== 'text') return; const openId = message.sender.sender_id.open_id; const textContent = message.content; // JSON字符串，需要解析 const parsedContent = JSON.parse(textContent).text; console.log(`[Feishu] Received from ${openId}: ${parsedContent}`); // TODO: 在这里调用 OpenClaw 的核心逻辑来处理消息，并获取回复 const replyText = `Echo: ${parsedContent}`; // 示例回复 // 调用飞书API发送回复 try { await this.client.im.message.create({ params: { receive_id_type: 'open_id' }, data: { receive_id: openId, content: JSON.stringify({ text: replyText }), msg_type: 'text', }, }); } catch (error) { console.error('[Feishu] Failed to send reply:', error); } }, }); console.log(`[${this.name}] Plugin initialized with appId: ${config.appId}`); } async start(): Promise<void> { // 飞书SDK通常不需要一个显式的“start”方法，因为HTTP服务器由上层框架（如Express）提供。 // 这里我们可以模拟一个启动过程，比如验证配置有效性。 try { // 尝试调用一个简单的API来验证凭证 await this.client.authen.getAccessToken(); this.isHealthy = true; this.failureCount = 0; console.log(`[${this.name}] Plugin started and credentials are valid.`); } catch (error) { console.error(`[${this.name}] Failed to start (invalid credentials):`, error); this.isHealthy = false; // 根据策略，可以选择抛出错误，或者标记为不健康但继续运行（等待健康检查修复） // 这里我们不抛出，让管理器继续启动其他插件。 } } async stop(): Promise<void> { // 飞书SDK没有需要关闭的长连接，这里主要进行状态清理。 console.log(`[${this.name}] Plugin is stopping...`); this.isHealthy = false; // 可以清理内部的缓存或定时任务 console.log(`[${this.name}] Plugin stopped.`); } async healthCheck(): Promise<{ healthy: boolean; details?: any }> { // 实现一个真实的健康检查，例如调用飞书“获取租户信息”API try { await this.client.tenant.get(); // 一个轻量级的API调用 this.isHealthy = true; this.failureCount = 0; return { healthy: true, details: { lastCheck: new Date().toISOString() } }; } catch (error) { this.failureCount++; this.isHealthy = false; return { healthy: false, details: { error: error.message, failureCount: this.failureCount, lastCheck: new Date().toISOString(), }, }; } } // 提供一个方法，供上层HTTP服务器将收到的飞书事件转发过来 handleEvent(req: any, res: any): void { this.eventDispatcher.invoke(req, res).catch((error) => { console.error('[Feishu] Error handling event:', error); res.status(500).send('Internal Server Error'); }); } }

4.2 在 Express 服务器中集成插件

OpenClaw 通常运行在一个 Web 服务器（如 Express、Koa）中。我们需要将飞书插件的事件处理器挂载到一个特定的路由上。

// server.ts 或 app.ts import express from 'express'; import { ChannelManager } from './managers/channel-manager'; import FeishuChannelPlugin from './plugins/feishu-plugin'; // ... 其他导入 const app = express(); app.use(express.json()); // 飞书事件是 JSON 格式 // 1. 创建管理器并注册插件 const channelManager = new ChannelManager(); const feishuPlugin = new FeishuChannelPlugin(); channelManager.register(feishuPlugin); // 2. 初始化插件（从环境变量读取配置） await channelManager.initializeAll({ feishu: { appId: process.env.FEISHU_APP_ID, appSecret: process.env.FEISHU_APP_SECRET, verificationToken: process.env.FEISHU_VERIFICATION_TOKEN, encryptKey: process.env.FEISHU_ENCRYPT_KEY, }, }); // 3. 设置飞书事件接收路由 app.post('/webhook/feishu', (req, res) => { feishuPlugin.handleEvent(req, res); }); // 4. 设置健康检查路由 app.get('/health', async (req, res) => { const healthStatus = await channelManager.getHealthStatus(); const allHealthy = Object.values(healthStatus).every((s: any) => s.healthy !== false); res.status(allHealthy ? 200 : 503).json(healthStatus); }); // 5. 启动服务器和管理器 const PORT = process.env.PORT || 3000; const server = app.listen(PORT, async () => { console.log(`Server is running on port ${PORT}`); // 服务器启动后，再启动所有渠道插件 await channelManager.startAll(); console.log('All channel plugins are started.'); }); // 6. 优雅关闭 const gracefulShutdown = async () => { console.log('Shutting down gracefully...'); await channelManager.stopAll(); server.close(() => { console.log('HTTP server closed.'); process.exit(0); }); // 设置强制关闭超时 setTimeout(() => { console.error('Could not close connections in time, forcefully shutting down'); process.exit(1); }, 10000); }; process.on('SIGTERM', gracefulShutdown); process.on('SIGINT', gracefulShutdown);

通过以上步骤，我们就完成了一个具备完整生命周期的飞书渠道插件的开发、注册、集成和托管。其他渠道（如微信、钉钉）可以如法炮制，只需实现相同的ChannelPlugin接口，并在管理器中注册即可。

5. 高级特性与扩展思路

5.1 支持动态热加载与卸载

在运维场景下，我们可能希望在不重启整个应用的情况下，更新某个渠道的配置或代码。这需要管理器支持动态操作。

扩展管理器接口：

class ChannelManager { // ... 原有代码 async loadPlugin(pluginPath: string): Promise<void> { // 动态导入插件模块 const module = await import(pluginPath); const PluginClass = module.default; const pluginInstance = new PluginClass(); this.register(pluginInstance); // 注意：动态加载的插件需要单独初始化，因为 initializeAll 已经执行过了 // 这里需要从某个地方获取该插件的配置 const config = this.loadConfigForPlugin(pluginInstance.name); await pluginInstance.init(config); if (this.isRunning) { await pluginInstance.start(); } } async unloadPlugin(pluginName: string): Promise<void> { const plugin = this.plugins.get(pluginName); if (!plugin) { throw new Error(`Plugin "${pluginName}" not found.`); } if (this.isRunning) { await plugin.stop(); } this.plugins.delete(pluginName); // 注意：在 Node.js 中，彻底卸载一个模块非常困难，可能需要清除 require.cache // 这通常用于配置热更新，而非代码热更新。 } }

注意事项：Node.js 的模块缓存机制使得真正的代码热替换（Hot Code Replacement）非常复杂且容易出错，通常不建议在生产环境使用。动态加载更适用于配置热更新或插件开关。例如，你可以通过一个管理 API 触发unloadPlugin和loadPlugin，传入新的配置对象，实现飞书 AppSecret 轮换而不重启服务。

5.2 实现权重启动与依赖管理

某些插件可能有启动顺序要求。例如，一个“审计日志”插件需要在所有其他插件之前启动，以确保能记录所有操作；或者插件 B 依赖于插件 A 暴露的某些服务。

实现思路：

1. 在插件接口中增加dependencies和priority属性。
2. 在管理器的initializeAll和startAll中实现拓扑排序。

interface ChannelPlugin { name: string; dependencies?: string[]; // 依赖的其他插件名 priority?: number; // 优先级，数字越小优先级越高 // ... 其他方法 } class ChannelManager { private async sortPluginsByDependency(): Promise<ChannelPlugin[]> { // 实现一个简单的拓扑排序算法（如 Kahn 算法） // 根据 plugin.dependencies 对插件进行排序 // 确保被依赖的插件先初始化、先启动 // 这里省略具体实现，可使用 `toposort` 等库 } async initializeAll(configs: Record<string, any>): Promise<void> { const sortedPlugins = await this.sortPluginsByDependency(); for (const plugin of sortedPlugins) { // ... 初始化逻辑 } } }

5.3 性能监控与指标暴露

为了更好的可观测性，管理器可以集成监控 SDK（如 OpenTelemetry 或 Prometheus Client），为每个插件的关键操作（初始化耗时、启动耗时、健康检查结果、消息处理量）打点。

示例（使用 Prometheus）：

import client from 'prom-client'; const pluginStartDuration = new client.Histogram({ name: 'channel_plugin_start_duration_seconds', help: 'Duration of plugin startup', labelNames: ['plugin_name'], }); async startAll(): Promise<void> { // ... for (const [name, plugin] of this.plugins) { const endTimer = pluginStartDuration.startTimer({ plugin_name: name }); const promise = plugin.start().then(() => { endTimer(); // 记录成功启动的耗时 }).catch((error) => { endTimer(); // 即使失败也记录耗时 // ... 错误处理 }); // ... } }

然后，你可以将/metrics端点暴露给 Prometheus，从而在 Grafana 上绘制出各渠道插件的启动时间趋势、健康状态等图表。

6. 常见问题排查与调试技巧

在实际开发和运维中，你肯定会遇到各种问题。下面是一些典型场景和排查思路。

6.1 插件启动失败，但管理器没有报错

现象：应用启动了，日志显示所有插件“启动完成”，但某个渠道（如飞书）收不到消息。排查步骤：

1. 检查管理器日志：确认在startAll阶段，该插件的start()方法是否被调用，是否有错误被catch并打印。管理器代码中使用了Promise.allSettled和catch，错误可能只打印了日志，没有向上抛出。
2. 检查插件自身的start()方法：是否有可能在异步操作中发生了错误，但没有被await或.catch捕获？确保start方法内部有完善的try-catch。
3. 检查健康状态：调用/health端点，查看该插件的healthy状态是否为false，以及details中的错误信息。
4. 检查网络与配置：确认插件配置（如飞书的 App ID/Secret）是否正确，网络是否能访问飞书 API 服务器。可以在插件start()方法中加入一个简单的网络连通性测试。

6.2 优雅关闭时进程卡住，无法退出

现象：发送SIGTERM信号后，应用日志停留在“Shutting down gracefully...”，然后超时被强制杀死。排查步骤：

1. 检查插件的stop()方法：它是否真的是异步的（返回 Promise）？里面是否有同步的无限循环或阻塞操作？确保stop()方法能快速完成资源释放。
2. 检查是否有未清理的定时器或连接：在 Node.js 中，活跃的定时器（setInterval）或打开的服务器（server.listen）会阻止事件循环退出。在stop()方法中，必须清除所有setInterval并关闭服务器。
3. 使用调试工具：在测试环境，可以在发送关闭信号后，使用kill -USR1 <pid>触发 Node.js 生成堆快照，或者使用node --inspect连接 Chrome DevTools，查看哪些异步句柄（Async Hooks）还在活动。
4. 简化复现：逐个禁用插件，找到是哪个插件的stop()方法有问题。

6.3 动态加载插件后，内存持续增长

现象：频繁使用loadPlugin/unloadPlugin后，Node.js 进程内存使用量只增不减。原因：Node.js 的require.cache会缓存模块。即使你从管理器的Map中删除了插件实例，模块代码本身可能还留在内存中，如果模块有全局状态或闭包引用，会导致内存无法释放。解决方案：

1. 谨慎使用动态加载：生产环境尽量避免频繁的代码热加载。将其用于配置更新，而非代码更新。
2. 清理require.cache：在unloadPlugin中，可以尝试删除对应模块的缓存。但这很危险，可能影响其他依赖该模块的代码。

   const modulePath = require.resolve(pluginPath); delete require.cache[modulePath];

3. 监控内存：使用process.memoryUsage()或更专业的 APM 工具监控内存变化，并设置进程重启阈值。

6.4 多个插件间需要通信

场景：飞书插件收到一条消息，需要微信插件也向特定用户发送一条通知。方案：不要在插件间直接相互引用，这会造成紧耦合。应该通过事件总线（Event Bus）或共享的、由管理器持有的服务来实现。

1. 事件总线：管理器可以初始化一个全局的事件发射器（EventEmitter）。飞书插件在收到消息后，发射一个cross-channel-notify事件，并携带数据。微信插件监听这个事件，并执行发送操作。
2. 共享服务：管理器可以持有一个NotificationService实例。所有插件在初始化时，由管理器将这个服务实例注入进去。插件通过调用notificationService.sendToWeChat(user, msg)来间接通信。

我个人在实际构建 OpenClaw 多渠道应用时，发现事件总线的方式更灵活，但要注意事件命名规范，避免冲突。而共享服务的方式类型安全更好，但会增加管理器的复杂度。对于中小型项目，一个简单的事件总线通常就足够了。