开发工具CLI人工智能AI 应用浏览器控制GUI 自动化【免费下载链接】OpenCLIMake Any Website into CLI Use your logged-in browser by AI agent.项目地址https://gitcode.com/gh_mirrors/ope/OpenCLI点击查看免费下载导读OpenCLI 通过一个常驻的本地微守护进程micro-daemon作为 CLI 与 Chrome 浏览器扩展之间的 HTTP WebSocket 桥梁。在典型开发循环写代码 → 测试 → 修改 → 再测试中两次命令之间的间隔常常超过旧的 5 分钟固定空闲超时导致守护进程频繁退出、每次重启都要付出 24 秒的进程派生与扩展 WebSocket 重连开销。本文基于 docs/superpowers/specs/2026-03-31-daemon-lifecycle-redesign.md 这份设计文档完整讲解四项核心改造4 小时可配置空闲超时、CLI 与扩展双条件空闲判定、扩展 WebSocket 重连退避上限从 60 秒降到 5 秒、以及新增opencli daemon status/stop/restart生命周期管理命令。读完本文你将掌握该守护进程的完整生命周期模型、时间线伪代码、HTTP 端点契约与 CLI 连接体验优化并能结合仓库源码理解其安全边界与实现细节。1. 问题背景为什么要重设计 Daemon 生命周期OpenCLI 的架构核心是一个本地微守护进程其职责与数据流在 src/daemon.ts 的头部注释中描述得非常清晰CLI → HTTP POST /command → daemon → WebSocket → Extension Extension → WebSocket result → daemon → HTTP response → CLI守护进程监听在localhost:19825被第一次浏览器命令自动拉起一直存活直到显式关闭、收到 SIGTERM/SIGINT 或卸载。它承担三层安全防护浏览器 CSRF 防御校验请求 Origin 必须来自chrome-extension://、强制要求自定义X-OpenCLI请求头、命令端点不发送 CORS 头此外还有 1 MB 请求体上限和 WebSocketverifyClient升级前拒绝。在旧设计中守护进程被视为一次性进程单一空闲定时器在每个 HTTP 请求时重置连续 5 分钟没有请求就直接process.exit(0)。设计文档用一张成本对比表揭示了这种取舍的问题保持存活的成本重启一次的成本~12 MB 内存、0% CPU每次重启 24 秒延迟保持存活几乎不消耗 CPU内存占用也只有约 12 MB重启一次却要付出进程派生 扩展 WebSocket 重连共 24 秒的延迟。开发循环中思考/写代码的间隔经常超过 5 分钟于是守护进程频繁自杀、下一次命令又频繁被重启延迟打断——重启成本远超空闲成本。这正是本次重设计的动机从激进短超时转向常驻长寿命。2. 解决方案总览四项核心改动设计文档给出的方案是将 5 分钟固定超时替换为长寿命守护进程模型共四项改动延长空闲超时从 5 分钟改为 4 小时可配置双条件空闲判定必须同时满足无 CLI 请求和无扩展连接才退出降低扩展重连退避上限WebSocket 重连退避上限从 60 秒降至 5 秒新增管理命令opencli daemon status/stop/restart。这四项改动共同解决三个问题守护进程不再因开发间隙被误杀、Chrome 打开着就能无限期保活、以及重连不再需要长时间等待。3. 双条件空闲判定新的超时策略3.1 旧行为 vs 新行为旧行为单一空闲定时器任何 HTTP 请求都重置它5 分钟没有请求就退出。新行为守护进程独立跟踪两个活动信号CLI 活动最后一次来自任意 CLI 调用的 HTTP 请求时间戳扩展活动来自 Chrome 扩展的 WebSocket 连接当前是否处于打开状态。退出倒计时只有在这两个条件同时满足时才开始连续IDLE_TIMEOUT时长内没有任何 CLI 请求同时没有扩展 WebSocket 连接。任一信号活跃守护进程就保持存活。这意味着扩展已连接 → 守护进程无限期保活用户开着 Chrome大概率还在工作最近有 CLI 活动 → 即使扩展暂时断开Chrome 重启、扩展更新也保持存活。3.2 超时值与常量定义默认超时值为 4 小时对应代码const DEFAULT_IDLE_TIMEOUT 4 * 60 * 60 * 1000; // 4 hours const IDLE_TIMEOUT DEFAULT_IDLE_TIMEOUT;在实现层面该常量被规划在 src/constants.ts 中紧邻DEFAULT_DAEMON_PORT 19825命名为DEFAULT_DAEMON_IDLE_TIMEOUT。需要说明的是当前仓库 src/daemon.ts 已演进到持久化守护进程模型——注释明确写着 Persistent — stays alive until explicit shutdown, SIGTERM, or uninstall即文档所描述的双条件空闲超时是早期阶段的方案同时常量文件仍保留了端口相关配置校验如OPENCLI_DAEMON_PORT不再支持自定义端口。因此阅读本节时请注意设计文档中的 4 小时超时数值与IdleManager类描述的是本次重构的目标形态而仓库现行实现已经进一步走向了无超时常驻 显式生命周期管理。3.3 计时器实现核心伪代码设计文档给出了完整的计时器伪代码这是理解整个方案的关键完整保留如下resetIdleTimer(): clear existing timer if Extension is connected: do not start timer (Extension connection keeps daemon alive) return start timer with IDLE_TIMEOUT duration on timeout: process.exit(0) On CLI HTTP request: update lastRequestTime resetIdleTimer() On Extension WebSocket connect: clear timer (Extension keeps daemon alive) On Extension WebSocket disconnect: elapsed now - lastRequestTime if elapsed IDLE_TIMEOUT: process.exit(0) // CLI has been idle long enough already else: start timer with (IDLE_TIMEOUT - elapsed) // count remaining time这里有一个值得注意的细节扩展断开时不是重新从满额超时开始倒计时而是用IDLE_TIMEOUT - elapsed只计时剩余部分。这样即使 CLI 在扩展连接期间已经空闲了 3 小时扩展一断开也只需再等 1 小时即可退出避免了断开瞬间从头计时导致的不合理延长。3.4 落地为可测试的 IdleManager配套的实现计划 docs/superpowers/plans/2026-03-31-daemon-lifecycle-redesign.md 建议把上述逻辑抽取为独立导出的IdleManager类理由很工程化daemon 模块有副作用会启动 HTTP 服务器所以直接对逻辑单元做测试export class IdleManager { private _timer: ReturnTypetypeof setTimeout | null null; private _lastCliRequestTime Date.now(); private _extensionConnected false; private _timeoutMs: number; private _onExit: () void; constructor(timeoutMs: number, onExit: () void) { this._timeoutMs timeoutMs; this._onExit onExit; } /** Call when an HTTP request arrives from CLI */ onCliRequest(): void { this._lastCliRequestTime Date.now(); this._resetTimer(); } /** Call when Extension WebSocket connects or disconnects */ setExtensionConnected(connected: boolean): void { this._extensionConnected connected; if (connected) { this._clearTimer(); // Extension alive — clear pending exit timer } else { this._resetTimer(); // Extension gone — re-evaluate remaining budget } } private _resetTimer(): void { this._clearTimer(); if (this._timeoutMs 0) return; // Timeout disabled (0 never exit) if (this._extensionConnected) return; // Extension keeps daemon alive const elapsed Date.now() - this._lastCliRequestTime; if (elapsed this._timeoutMs) { this._onExit(); // CLI idle past timeout already return; } this._timer setTimeout(() this._onExit(), this._timeoutMs - elapsed); } }全局实例的退出回调带有诊断日志const idleManager new IdleManager(IDLE_TIMEOUT, () { console.error([daemon] Idle timeout (no CLI requests no Extension), shutting down); process.exit(0); });接线点包括handleRequest中对每个请求调用idleManager.onCliRequest()wss.on(connection)中调用setExtensionConnected(true)ws.on(close)与ws.on(error)中调用setExtensionConnected(false)httpServer.listen回调中调用onCliRequest()启动初始空闲倒计时。3.5 测试策略用假计时器验证时间边界实现计划给出了 6 个使用 Vitest 假计时器vi.useFakeTimers()的单元测试场景完整覆盖了双条件逻辑的时间边界测试场景预期行为扩展已连接时收到 CLI 请求推进 300s 1s 后不退出扩展保活CLI 刚活跃、随后扩展断开不立即退出推进满超时后才退出 1 次CLI 已空闲超过超时、扩展断开立即退出elapsed ≥ timeout 分支新 CLI 请求重置计时200s 处请求后继续计时满 300s 才退出超时配置为 0禁用24 小时后仍不退出扩展连接清除计时器连接后即使越过原超时点也不退出这些用例把伪代码里的每个分支都固化为可回归的行为契约例如扩展断开但 CLI 刚活跃 → 不立即退出和断开时若 CLI 已闲置超过阈值 → 立即退出。4. 扩展快速重连退避上限 60 秒 → 5 秒4.1 旧行为的问题当扩展丢失与守护进程的 WebSocket 连接时它以指数退避重连2s → 4s → 8s → 16s → 32s → 60s封顶。最坏情况下扩展要等60 秒才发起下一次重连尝试——如果守护进程恰好在这期间重启完成用户就得干等一分钟。4.2 新行为将退避上限从 60 秒改为 5 秒// extension/src/background.ts const WS_RECONNECT_MAX_DELAY 5000; // was 60000理由在 4 小时守护进程超时或现行常驻直到显式关闭模型下守护进程几乎总是在运行。长退避间隔不再必要只会增加重连延迟。5 秒上限意味着只要守护进程可用扩展最多 5 秒内就会重连成功。4.3 仓库现状印证在现行仓库中重连参数位于 extension/src/protocol.ts/** Base reconnect delay for extension WebSocket (ms) */ export const WS_RECONNECT_BASE_DELAY 2000; /** Max reconnect delay (ms) — kept short since daemon is long-lived */ export const WS_RECONNECT_MAX_DELAY 5000;WS_RECONNECT_MAX_DELAY 5000正是设计文档要求的改造结果。而 extension/src/background.ts 中的实际重连调度逻辑则进一步演进为// Reconnect cadence: plain exponential backoff with jitter, never giving up // while Chrome keeps the service worker alive. 1s → 2s → 4s → … capped at 15s // (0-500ms jitter); attempts reset on a successful WS open. const RECONNECT_BASE_DELAY_MS 1000; const RECONNECT_MAX_DELAY_MS 15000; function nextReconnectDelayMs(): number { const exp Math.min(RECONNECT_MAX_DELAY_MS, RECONNECT_BASE_DELAY_MS * 2 ** Math.min(reconnectAttempts, 6)); return exp Math.floor(Math.random() * 500); }可以推断从设计文档2s 起步、60s 封顶到实现计划WS_RECONNECT_MAX_DELAY 5000再到现行代码1s 起步、15s 封顶 0-500ms 抖动、成功连接即重置计数重连策略整体沿快速、有界、带抖动、永不放弃的方向收敛。配套测试 extension/src/background.test.ts 中也有对应用例reconnect delay backs off exponentially with a 15s cap and resets on success、a successful daemon ping resets the backoff before the WebSocket attempt来锁定该行为。5. Daemon 管理命令status / stop / restart5.1 命令概览新增三个 CLI 子命令用于守护进程生命周期管理opencli daemon status— 查询守护进程的/status端点并展示状态opencli daemon stop— 发送POST /shutdown请求触发优雅关闭opencli daemon restart— 等价于stop后重新派生一个新守护进程适用于守护进程进入异常状态时。5.2 status 命令的输出运行中状态示例设计文档给出的目标输出Daemon: running (PID 12345) Uptime: 2h 15m Extension: connected Last CLI request: 8 min ago Memory: 12.3 MB Port: 19825未运行时的输出Daemon: not running5.3 守护进程侧新增端点GET /status— 返回 JSONPID、运行时长、扩展连接状态、最后请求时间、内存占用POST /shutdown— 发起优雅关闭。两个端点都要求与现有端点相同的X-OpenCLI自定义请求头用于 CSRF 防护。5.4 优雅关闭流程/shutdown的处理在 src/daemon.ts 中真实存在if (req.method POST pathname /shutdown) { jsonResponse(res, 200, { ok: true, message: Shutting down }); setTimeout(() shutdown(), 100); return; }shutdown()的完整语义拒绝所有 pending 请求尚未派发dispatched false的命令按派发前契约返回客户端可安全重发已派发的命令返回daemon_shutting_down503客户端只在扩展具备日志记录能力时才重发——避免客户端把结果未知误判为可安全重试关闭所有扩展 WebSocket 连接extensionProfiles中每个 profile 的ws.close()关闭 HTTP 服务器等待拒绝响应 flush 完成后再process.exit(EXIT_CODES.SUCCESS)同步process.exit会杀掉写响应的微任务队列兜底定时器100ms 后调用closeIdleConnections?.()再 500ms 后强制退出并unref()同时注册了SIGTERM与SIGINT两个信号处理均走shutdown。5.5 仓库中的命令实现已落地版本设计文档规划的命令在 src/commands/daemon.ts 中已完整实现并且在注册于 src/cli.tsprogram.command(daemon).description(Manage the opencli daemon)下挂status/stop/restart三个子命令。落地版本在状态输出上做了增强版本信息Version: vX.Y.Z且通过 src/browser/daemon-version.ts 的isDaemonStale检测守护进程与 CLI 版本不一致若为旧版守护进程则标记Daemon: stale并提示opencli daemon restart多 Profile 细化状态对应 GH #1575 的修复当扩展未连接时区分三种结构上不同的情形——零个 profile准确的disconnected、多个 profile 连接但没有默认 profile提示opencli profile use name、请求的 profile 消失了同样提示切换 profileProfiles 列表显示所有已连接 profile 的contextId及扩展版本restart 前的告警如果当前有 N 个浏览器 profile 连接restart 会先警告它们将被断开扩展随后会自动重连。restart的实际执行位于 src/browser/daemon-lifecycle.ts 的restartDaemon()先fetchDaemonStatus()探测若在运行则requestDaemonShutdown()并轮询waitForDaemonStop(3000)等待端口释放200ms 间隔轮询随后spawnDaemonProcess()派生新进程再waitForDaemonStatus(5000)等待新进程上报状态。派生逻辑resolveDaemonLaunchSpec()会智能选择daemon.ts走--import tsx/esm或daemon.js以detached: true, stdio: ignore方式派生并unref()从而脱离 CLI 进程独立存活。5.6 测试覆盖src/commands/daemon.test.ts 通过全局 stubfetch和 mockchalk避免 ANSI 色码干扰断言覆盖守护进程不可达时daemonStatus输出 not running可达时展示 PID 等信息daemonStop在未运行与正常关闭两个路径上的输出。设计文档还规划了守护进程层面的集成测试opencli daemon status/stop/restart端到端正确性。6. CLI 连接等待体验优化6.1 旧行为的痛点当守护进程在运行但扩展未连接时CLI 会静默地每 300ms 轮询一次最终以一条笼统的错误超时收场——用户完全不知道系统在等什么、该做什么。6.2 新行为守护进程在运行、扩展未连接时显示进度指示与可操作提示⏳ Waiting for Chrome extension to connect... Make sure Chrome is open and the OpenCLI extension is enabled.轮询间隔从 300ms 降到 200ms略微加快检测速度。**守护进程完全未运行连接被拒绝**时CLI 照常先派生守护进程并显示⏳ Starting daemon...6.3 仓库落地形态在现行 src/browser/daemon-lifecycle.ts 的ensureBrowserBridgeReady()中这一 UX 已经实现并扩展出更完整的决策树先getDaemonHealth()探测检测到旧版本守护进程daemonVersion ! PKG_VERSION时显示⚠️ Stale daemon detected (vX ≠ vY). Restarting...先优雅关闭3 秒等待失败则对已知 PID 发起SIGKILL兜底再重新派生无守护进程时显示⏳ Starting daemon...并派生守护进程在运行但扩展未连接时显示⏳ Waiting for Chrome/Chromium extension to connect...及安装/启用提示最终通过waitForBridgeReady轮询timeoutSeconds默认 10 秒等待桥接就绪。提示文案仅在OPENCLI_VERBOSE环境变量设置或stderr为 TTY 时输出避免在脚本化/管道场景污染输出。7. 文件改动清单与影响评估设计文档给出了精确的改动范围清单合计约 143 行新增/修改代码文件改动预估 LOCsrc/daemon.ts双条件空闲超时、/status端点、/shutdown端点~40extension/src/background.tsWS_RECONNECT_MAX_DELAY60000 → 50001src/browser/daemon-client.ts更好的连接等待 UX、200ms 轮询间隔~20src/commands/daemon.ts新增status、stop、restart子命令~80src/constants.tsDEFAULT_IDLE_TIMEOUT常量2向后兼容性设计文档明确声明对 CLI 命令与扩展协议无破坏性变更守护进程与扩展使用固定的 Browser Bridge 端口localhost:19825见 src/constants.ts唯一可观察的行为变化是守护进程存活时间更长新增的daemon子命令是加法式的不影响既有命令。**超出范围Out of Scope**的项同样值得记录避免误读设计意图OS 级守护进程管理launchd / systemd——如需可后续补充守护进程自动更新机制多守护进程协调跨重启的持久化守护进程状态。8. 测试矩阵如何验证生命周期改造设计文档规划的测试矩阵完整覆盖单元与集成两个层次单元测试IdleManager仅当 CLI 与扩展同时空闲时才开始空闲计时扩展连接时清除计时器/status返回正确状态/shutdown触发优雅退出。集成测试扩展保持连接时守护进程在无 CLI 请求的情况下存活 10 分钟以上完全空闲时守护进程在配置的超时时间后退出opencli daemon status/stop/restart三个命令端到端工作正常。计划中还给出了手工冒烟测试序列可直接复现验证# 检查状态守护进程未启动时应显示 not running npx tsx src/main.ts daemon status # 运行任意浏览器命令启动守护进程再查状态 npx tsx src/main.ts daemon status # 优雅停止 npx tsx src/main.ts daemon stop # 确认已停止 npx tsx src/main.ts daemon status9. 从设计到现状仓库演进对照将设计文档、实现计划与当前仓库并排阅读可以梳理出这条生命周期改造的完整演进链目标形态spec5 分钟固定超时 → 4 小时可配置超时 CLI/扩展双条件判定 5 秒重连上限 三个管理命令落地步骤plan把计时逻辑抽成可单测的IdleManager逐任务提交配套 Vitest 假计时器用例现行实现srcsrc/daemon.ts 头部注释已明确 Persistent — stays alive until explicit shutdown, SIGTERM, or uninstall即空闲超时最终被进一步弱化生命周期完全交给显式管理/status、/shutdown两个端点已实现并扩展出/ping、/logs等端点/status返回结构远比设计文档丰富含多 profile、pending、session leases、commandResultUnknown 等诊断字段extension/src/protocol.ts 的WS_RECONNECT_MAX_DELAY 5000正是本设计的产物而 extension/src/background.ts 的重连算法进一步加入了 jitter 并调整了封顶值src/commands/daemon.ts src/cli.ts 落实了三个管理命令并叠加版本陈旧检测stale daemon与多 profile 状态细分src/browser/daemon-lifecycle.ts 承载了等待扩展连接的 UX 提示、200ms 级轮询与restartDaemon的完整编排。这展示了 OpenCLI 团队先写设计文档 → 拆分实现计划 → 逐步落地并叠加改进的工程方法也说明设计文档描述的是改造的目标骨架而仓库现行代码是这个骨架的超集演进。10. 结语与延伸阅读守护进程生命周期改造看似只是把超时改长一点实则牵动三处设计权衡保活成本的量化12 MB 内存 vs 24 秒重启延迟、多信号联合判定的边界处理断开时按剩余时间倒计时、扩展连接即清定时器、以及管理面与数据面的解耦/status、/shutdown走独立 HTTP 端点复用既有 CSRF 防护。对需要长时间运行的本地桥接型进程这套双条件保活 快速重连 显式管理命令的组合拳具有很强的参考价值。相关设计文档与实现路径均位于当前仓库设计规格docs/superpowers/specs/2026-03-31-daemon-lifecycle-redesign.md实现计划docs/superpowers/plans/2026-03-31-daemon-lifecycle-redesign.md守护进程实现src/daemon.ts管理命令实现与测试src/commands/daemon.ts、src/commands/daemon.test.ts生命周期编排src/browser/daemon-lifecycle.ts扩展重连参数extension/src/protocol.ts、extension/src/background.ts端口常量与校验src/constants.ts赞分享开发工具CLI人工智能AI 应用浏览器控制GUI 自动化【免费下载链接】OpenCLIMake Any Website into CLI Use your logged-in browser by AI agent.项目地址https://gitcode.com/gh_mirrors/ope/OpenCLI点击查看免费下载相关推荐【亲测免费】 dify-plugin-daemon插件生命周期管理的强大工具dify plugin daemon插件生命周期管理的强大工具 项目介绍 在现代软件开发领域插件化的架构设计越来越受到开发者的青睐因为它能够提供更灵活、可后端AI 插件插件系统qwen-code Standalone Daemon Sessions PR3daemon-only standalone-v1 完整生命周期 REST API 实现方案qwen code Standalone Daemon Sessions PR3daemon only standalone v1 完整生命周期 REST A人工智能AI Agent代码智能体工具调用交互助手CLIQwenno-mistakes Daemon 与 Worktree后台守护进程的架构、生命周期管理与崩溃恢复实战指南no mistakes Daemon 与 Worktree后台守护进程的架构、生命周期管理与崩溃恢复实战指南 本文基于 daemon.md https://l开发工具CLIAI 应用质量保障上一篇JetBrains MCP Server Proxy 配置问题解析与解决方案下一篇JetBrains MCP插件在Windows 11环境下的配置问题解析创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考