OpenClaw Monitor

用 AI 监控 AI:为 OpenClaw 智能体提供免费开源的用量与会话可视化面板。

Star 数
★ 12
最近更新
4 个月前
License
MIT
主语言
JavaScript

30 秒速览

运行形态
自托管服务网页应用
可在哪里用
平台专用
费用
免费,无需付费服务
上手难度
中 · 需要几步配置
开始前需要
Node.js 18+OpenClaw Gateway(运行于 18789 端口)Shell / 命令行网络访问本地文件系统
典型场景
已经在跑 OpenClaw Gateway 的开发者,想按模型查看最近 7 天的 prompt/completion 令牌消耗,判断哪个模型的用量在增长。
不适合
  • 未部署 OpenClaw Gateway 的团队
  • 需要观测 OpenClaw 之外其他 AI 运行时的用户
  • 只想用一条命令行、不做前后端分离部署的用户

这个 Agent 能做什么,适合哪些场景?

OpenClaw Monitor 是一个面向 OpenClaw AI 智能体的自托管监控面板,采用 MIT 协议开源。它由三部分组成:Vue 3 + Vite + Element Plus + ECharts 的前端仪表盘、基于 Node.js + Express 并带 WebSocket 客户端的后端监控 API,以及位于 openclaw-monitor/ 目录下的监控辅助脚本。数据全部来自本地会话 JSON 文件与 .reset 历史文件,不经过云端,属于完全离线的工作方式。使用流程是:后端先连接运行在 18789 端口的 OpenClaw Gateway,再读取本地会话数据并对外暴露 REST 接口,前端在 localhost:5173/monitor-v2 拉取这些接口做图表渲染。它输出的内容包括令牌用量柱状图、实时会话列表、7 天消息趋势以及系统运行时长与内存指标。

后端监控 API 通过 WebSocket 连接 OpenClaw Gateway(18789 端口)获取状态,并读取本地会话 JSON 文件与 .reset 历史文件,然后以 REST 接口对外提供数据,包括 GET /health、GET /api/gateway/status、GET /api/sessions/list、GET /api/metrics/system、GET /api/messages/stats、GET /api/models/current。前端仪表盘从这些接口取数,用 ECharts 绘制按模型拆分的 7 天 prompt/completion 令牌柱状图与每日消息数量趋势,并用列表展示实时会话的模型、运行时长与状态;同时展示任务调度视图、系统运行时长和内存占用。它支持 Claude Code、OpenAI Codex、DeepSeek V4 等多个模型的数据展示,整个链路的输入是本地会话文件,输出是浏览器中的可视化面板。

  1. 已经在跑 OpenClaw Gateway 的开发者,想按模型查看最近 7 天的 prompt/completion 令牌消耗,判断哪个模型的用量在增长。
  2. 同时使用 Claude Code、OpenAI Codex、DeepSeek V4 的用户,希望在同一个面板里对比不同模型的调用与消息分布。
  3. 运维或值班同学需要实时看到当前有哪些会话在跑、各自用的什么模型、已经运行多久、状态是否正常。
  4. 想观察智能体定时任务调度情况的用户,通过任务调度视图确认任务是否按预期排布。
  5. 对数据外发有顾虑、希望监控数据只留在本机的用户,直接读取本地会话 JSON 而不依赖云服务。
  6. 排查资源问题时,需要结合系统运行时长与内存占用指标一起看会话与消息趋势的用户。

如何安装或部署这个 Agent?

前置条件:Node.js 18+,并且本机已有 OpenClaw Gateway 运行在 18789 端口。Windows 用户可在仓库根目录一键启动:

start-all.bat

也可以手动分开启动两个服务。先装并启动后端监控 API(3000 端口):

cd backend && npm install && npm start

再开一个终端装并启动前端(5173 端口):

cd frontend && npm install && npm run dev

停止服务可使用根目录的 stop-all.bat。README 未说明 Linux/macOS 的一键启动脚本,也未给出环境变量或配置文件清单。

如何使用这个 Agent?

两个服务都起来后,在浏览器打开前端地址即可看到面板:

http://localhost:5173/monitor-v2

后端 API 默认监听 3000 端口,可直接调用验证数据:

curl http://localhost:3000/health
curl http://localhost:3000/api/gateway/status
curl http://localhost:3000/api/sessions/list
curl http://localhost:3000/api/metrics/system
curl http://localhost:3000/api/messages/stats
curl http://localhost:3000/api/models/current

若前端或后端端口被占用,需要自行调整端口,并保证后端到 Gateway 18789 端口的 WebSocket 连接可用。

这个 Agent 有哪些优点和局限?

优点
  • 数据源完全是本地会话 JSON 与 .reset 历史文件,监控链路不依赖云服务,也不会把用量数据外发。
  • 按模型拆分的 7 天 prompt/completion 令牌柱状图和每日消息趋势,能直接回答“哪个模型在消耗预算”。
  • 界面明确支持 Claude Code、OpenAI Codex、DeepSeek V4 等多模型的并列展示。
  • 提供 Windows 一键 start-all.bat / stop-all.bat,前后端分开启动也只需要 npm install 与 npm start 两步。
  • REST 接口清晰(/api/sessions/list、/api/metrics/system、/api/messages/stats 等),便于自行接二次告警或报表。
局限
  • 强依赖 OpenClaw Gateway 运行在 18789 端口,没有 Gateway 时面板没有可用数据源。
  • 只能观测 OpenClaw 生态的会话与令牌数据,README 未提供对其他 AI 运行时的采集适配。
  • 需要同时部署后端 API(3000)与前端(5173)两个进程,端口冲突时要手动改配置。
  • 一键启动脚本只有 Windows 版本,Linux/macOS 需要照着手动步骤自行拼启动流程。
  • 仓库未给出 Docker 镜像、配置文件或环境变量文档,容器化与集中部署需要自行补足。

这个 Agent 与同类方案有什么区别?

与相关度最高的同类 agent 并排比较关键指标。

Agent 源码审查 形态 / 费用 Star 最近更新 主语言 完整支持的平台
OpenClaw Monitor 当前 38 · 缺口较多 自托管服务免费 ★ 12 4 个月前 JavaScript —
AgentAcct 61 · 存在缺口 命令行工具免费 ★ 754 1 天前 Python Codex · Claude Code
ClawMetry 81 · 表现良好 命令行工具免费版 + 付费版 ★ 420 今天 Python Codex · Claude Code
Agenttrail 77 · 表现良好 命令行工具免费 ★ 708 18 天前 JavaScript Codex · Claude Code

FollowAgents 如何评估这个 Agent?

FollowAgents 源码审查 · FARS-2.1
缺口较多
38/ 100 五分制 1.9 / 5
信任安全 8/29
可靠稳定 5/14
适用触发 8/18
规范维护 8/18
有效结果 6/13
证据核验 3/8
查看各维度的扣分理由
信任安全8 / 29 · 1.4/5

README 明确说明数据来自本地 session JSON 文件、完全离线、无云端,数据流方向(浏览器→前端→本地 API→Gateway WebSocket/本地文件)有架构图说明,故 data_flow_transparency 给 2。但仓库未提供任何权限声明、最小权限设计或用户确认机制:监控进程可读取本地会话文件并连接 Gateway WebSocket,属于隐式权限,未见范围限制,least_privilege 仅 1;无任何写操作前的确认流程,user_confirmation 为 0。敏感数据处理方面,会话 JSON 可能含提示词与 token 明细,README 未说明脱敏、访问控制或存储保护,仅 1。依赖安全方面,release.yml 使用 npm ci --ignore-scripts 是正向信号,但仓库未提供 lockfile 证据、依赖审计或版本固定说明,仅 1。外部影响方面,发布工作流会创建 GitHub Release 并打 tag,属于真实外部副作用,但仅限 CI 且无破坏性默认,给 1。回滚方面,无任何回滚、备份或恢复说明,为 0。来源归属方面,README 未标注上游 OpenClaw 项目来源或数据格式出处,仅 LICENSE 有版权人,给 1。

可靠稳定5 / 14 · 1.8/5

自一致性方面,README 的 API 端点、架构图与项目结构基本对应,但 release.yml 打包时引用了 README 中未出现的 QUICK_START.md,且发布说明中的启动步骤(frontend 用 npm run dev)与打包产物(frontend/dist 静态文件)不一致,存在内部矛盾,仅 1。依赖可用性方面,仅声明 Node.js 18+ 与 OpenClaw Gateway 端口 18789,未列出具体依赖版本或 lockfile,无法静态确认可复现安装,给 1。失败信息方面,README 未描述任何错误码、日志格式或故障排查路径,仅 1。

适用触发8 / 18 · 2.2/5

受众与场景方面,README 清楚面向需要监控 OpenClaw agent 的开发者,并给出功能清单与截图,给 2。能力边界方面,仅列出功能,未说明不支持哪些模型、哪些平台或数据规模上限,给 1。触发精度方面,监控为被动读取,无触发条件说明;start-all.bat 仅 Windows 一键启动,跨平台触发方式未定义,给 1。环境适配方面,明确依赖 Windows 批处理脚本与本地端口,但未说明 Linux/macOS 支持或端口冲突处理,给 1。

规范维护8 / 18 · 2.2/5

信息架构方面,README 有功能、技术栈、结构、快速开始、API、架构、许可证等分节,结构清晰,给 2。安装说明方面,提供前置条件、一键与手动两种启动方式及端口,给 2。命名稳定性方面,仓库名与产品名一致,但发布 tag 使用时间戳(v20260101-120000)而非语义化版本,命名策略不稳定,给 1。示例与 FAQ 方面,仅有截图与端点表,无使用示例、配置样例或 FAQ,给 1。已知限制方面,完全未提及,为 0。许可证方面,MIT 全文存在且 README 标注一致,给 2。版本与变更日志方面,无 CHANGELOG,仅 CI 自动生成时间戳 tag,给 1。维护责任方面,LICENSE 版权人为 Biglegs,与仓库所有者 flik2002 不一致,且无维护者、联系方式或贡献指南,发布者身份未经验证,给 1。

有效结果6 / 13 · 2.3/5

输出可用性方面,仪表盘提供 token 用量、会话列表、7 天趋势、系统指标等可视化,对目标用户直接可用,给 2。边际价值方面,功能与 OpenClaw 自带或通用监控工具可能重叠,README 未说明相对替代方案的独特价值,给 1。成本收益方面,需同时运行后端与前端两个 Node 进程并依赖 Gateway,部署成本中等,而收益仅为只读可视化,未给出资源占用或性能数据,给 1。

证据核验3 / 8 · 1.9/5

主张可追溯性方面,README 的功能主张无对应代码片段、测试或截图之外的证据,无法逐条追溯,给 1。跨源印证方面,仅有 README、LICENSE 与 CI 工作流三份文件,彼此仅部分印证(如 MIT、Node 版本),无测试或文档交叉验证,给 1。事实与推断分离方面,README 未区分已验证事实与规划中功能(如 demo.gif 仍为注释),但整体未做明确声明,给 1。

风险与缓解建议
  • 源码中未见:执行前用户确认开启或自行加上执行前确认;先在沙箱或测试环境跑通,确认行为后再接入真实数据。
  • 源码中未见:回滚或恢复路径运行前先备份,或在 git 分支、快照上操作,确保改动可以撤销。
  • 仓库仅提供 README、LICENSE 与 CI 工作流,缺少后端/前端源码、测试与 lockfile,无法静态验证功能实现与依赖安全。
  • 监控进程会读取本地会话 JSON 并连接 Gateway WebSocket,但未说明权限范围、脱敏或访问控制,敏感提示词与 token 数据可能被完整暴露。
  • 发布工作流引用了 README 中不存在的 QUICK_START.md,且发布说明的启动方式与打包产物不一致,安装步骤可能失效。
  • LICENSE 版权人(Biglegs)与仓库所有者(flik2002)不一致,发布者身份未经验证,维护责任与更新路径不明确。
  • 无回滚、备份或已知限制说明,且发布 tag 使用时间戳而非语义化版本,升级与回退缺乏依据。
证据充分度:低 评估于 2026年9月26日 审查版本 ed2d256d8832
查看完整评分方法 →

常见问题

需要额外付费吗?
不需要。项目以 MIT 协议开源,监控本身不调用任何付费服务;你的花费来自 OpenClaw 侧实际使用的模型,与监控面板无关。
必须有 OpenClaw Gateway 吗?
是。后端通过 WebSocket 连接 18789 端口的 Gateway 获取状态,没有它 /api/gateway/status 无法返回有效连接状态,面板也拿不到实时会话。
数据会被上传到云端吗?
不会。数据来源是本机会话 JSON 文件与 .reset 历史文件,前端只从本地 3000 端口的监控 API 拉取数据。
两个端口冲突了怎么办?
后端默认 3000、前端默认 5173。README 未提供端口环境变量,需要在后端与前端的启动配置中自行修改,并同步前端请求地址。
能在 Linux 或 macOS 上一键启动吗?
README 只给出了 Windows 的 start-all.bat/stop-all.bat。其他系统需要按手动步骤,分别进入 backend 和 frontend 执行 npm install 与启动命令。
在 GitHub 查看 ↗ 安装 ↓

相关 Agents