项目地址：Arona WebUI

技术栈：Node.js、Vanilla JS、WebSocket、OpenClaw Gateway Protocol。

Arona WebUI 是我做的一个 OpenClaw AI Gateway 管理面板。项目没有引入复杂的前端框架，起因也很简单：网关运行起来之后，状态、配置、日志和定时任务分散在不同入口里，日常查看和操作不太顺手。

我先遇到的问题

我自己使用 AI Gateway 时，经常需要确认几件事：网关到底有没有正常连接，当前用了哪个模型，最近有没有报错，定时任务是否按预期执行。

openclaw的使用场景多在三方channel渠道里，比如飞书、tg、slack等，并不能可视化的看到当前模型在执行什么具体的命令操作，更无从可知token的消耗速度、缓存是否命中等；而且当网关无响应的时候这些三方channel就彻底与openclaw失联……针对这些问题，才开始着手开发Arona WebUI

最初版本围绕三类动作展开：

  • 看状态：连接、CPU、内存、模型用量和日志。
  • 改配置：模型配置和定时任务。
  • 发操作：通过页面向网关发送控制命令。

这个范围看起来不大，但已经覆盖了从观察到操作的一条完整路径。

功能顺序是怎么定的

对管理工具来说，如果连网关是否在线都不知道，配置页面做得再完整也很难用。所以当前版本的顺序是：先让状态可见，再让配置可改，最后把常用操作接进来。

页面上目前包含这些模块：

  • 网关连接状态。
  • CPU 和内存监控。
  • 模型用量统计。
  • 流式日志查看。
  • 模型配置。
  • 定时任务。
  • 网关命令下发







    这里有一个产品上的取舍。权限系统、多网关编排和大规模数据分析当然都有价值，只是当前版本更需要先把个人使用链路跑通，所以暂时没有把它们放进来。

技术方案

项目使用 Node.js 原生 API 搭建服务端，前端使用 Vanilla JS 和 ES Modules，没有引入构建工具。整体链路比较直接：

1
2
3
4
5
6
7
浏览器页面
    ↓
Node.js 管理服务
    ↓
WebSocket 双向通信
    ↓
OpenClaw AI Gateway

为什么选 WebSocket

这个面板会持续接收日志、连接状态和任务结果。要是一直靠轮询，代码和状态处理都会变得麻烦。

WebSocket 能同时处理两类消息：页面向网关发送命令，网关把事件和结果推回来。实时日志和状态更新也可以沿用同一条连接，页面不需要反复请求才能知道有没有新内容。

为什么先不用前端框架

这个项目的规模和目标都比较明确，我想先把浏览器、Node.js 服务和网关之间的通信关系理清楚。Vanilla JS 的好处是依赖少、部署简单，代码也更贴近实际的数据流。

代价同样明显：模块边界、状态更新和 DOM 渲染都需要自己维护。后续如果增加多网关、权限管理和复杂表单，我会重新评估是否需要引入更完整的前端工程方案。

LLM 在里面做了什么

我使用 Claude Code 和 Codex 辅助开发，但没有把它们当成“输入一句话就交付全部代码”的工具。

我自己负责确定场景、功能优先级、信息架构和验收标准，也需要理解 OpenClaw 的消息协议，确认连接、命令和返回事件是否符合预期。LLM 更适合帮我处理这些工作：

  • 生成模块的初始代码。
  • 补齐重复性逻辑。
  • 根据错误日志提供排查方向。
  • 整理文档和测试清单。

实际流程通常是先拆出一个小任务，让模型给出实现方案，再逐步生成代码和验证。这样做比直接生成一个“完整系统”更容易发现问题，也不容易把不需要的复杂度一并带进来。

现在做到什么程度

当前版本已经实现了实时监控、模型配置、定时任务、日志查看和网关命令下发等核心能力。项目代码已经公开在 GitHub，仓库目前有 60+ Star。

这里的 Star 更像是项目完成度和公开展示度的辅助证据，并不代表商业用户规模。Arona WebUI 目前主要还是我自己使用和迭代的工具，这个边界需要说清楚。

还缺什么

这个版本离更成熟的产品还有距离，比较明显的缺口包括：

  • 身份认证和权限控制还不完善。
  • 多网关管理还没有形成完整方案。
  • 网络断开后的自动重连和错误恢复需要加强。
  • 端到端测试和性能指标还不够系统。

如果继续迭代，我会先处理连接恢复和权限边界，再考虑扩展更多配置能力。对于这类工具，出了问题之后能不能看懂、能不能恢复，通常比再多一个配置入口更重要。