开发 NodeGet 心得 | 记一次不太完美的收尾

Hi，这里是 GenshinMinecraft

前言

很高兴能参与到 NodeGet 的开发中，虽然已经退出，但是我仍在 NodeGet 的开发过程中学到了很多东西

本文仅作为个人小记，并不会涉及到特别高深的技术

就这样吧，本文写于 2026.11.01

(噩)梦开始开始的地方

310 天前，也就是 2025.12.26，酒神在 NodeSeek 发了个帖子

当时的我刚好完成了 Komari 教程的编写 (站内链接)，以及 komari-monitor-rs 的稳定，手上非常闲，鉴于又有监控项目开发经验，那必然是要参与一下开发的

其实，我是没有想过我会成为 NodeGet 的核心开发者的，当时我的想法是: 按开发者经验来算，我肯定不算多，但是我很喜欢开发一些项目外围的东西。虽然后面没有实现就是啦

讨论

在我完成了监控部分的系统详情信息的获取后 (这一 Part 是最简单的，直接从以前的项目顺过来就行了)，几位核心开发者在群聊内进行了不下 2000 条信息的交流

在此我先详细描述下酒神一开始对于 NodeGet 设计的思路:

• 所有的节点，既是服务器，也是客户端: 如果你用过类似 EasyTier 这样的工具，你大概可以理解。每一个机器都可以储存 / 提供 / 采样数据，非常去中心化以及分布式的思想
• 权限清晰透明: 在所有的节点上，都可以配置上游 / 下游 / 同级节点 对于自身数据的 所有访问权限，精细到字段级别颗粒度
• 可以由第三方调用: 社区最近有个 iLantency 项目，实际一开始的设计是和 NodeGet 绑定到一起的。所有人都可以运行一套 NodeGet 服务，并给予部分极小的权限 (比如 Ping 一个目标并获取结果) 到一个公用的站点，公开公共服务。也许这里比较难以理解
• 不需要前端: 可以简单理解为前后分离，官方前端仅作为展示，可以自由配置前端 (也就是后来的 NodeGet Show，类似主题)
• 大部分功能基于 CLI: 一个节点可以有一个 core service，并由一个 cli 来完全掌控它，可以配置上下游

如果真能按照这样的架构来写就好了

讨论了很久之后，才逐渐变成了现在的样子:

• 仍旧保留 C/S 架构: Client 也就是 Agent，不储存信息，仅作为信息的采集器；Server 储存信息，并具有管理能力 (权限由 Agent 授予)
• 权限清晰透明: 对于所有的字段的 CRUD 都具有详细的权限，采用权限覆盖 RBAC 的思想，可以自由控制权限的范围与对象，采用 Token 控制
• 插件化: Server 可以开发 JS 插件，拓展功能，并且具有超级牛力
• Server 功能互相独立: 所有的 Server 功能都互相独立，不干扰，不会存在内在联系，只有 Token 鉴权统筹管理

最大的转变就是从分布式变成了 C/S，直接大砍了去中心化的 Feature，并且将功能独立化

还有一些小细节，也在讨论范围中，不过我都快忘了

Features

既然要开发的是赛道极度拥挤的系统监控服务，那必然要有自己的亮点

插件

当时的两大轻量化监控 Nezha 与 Komari，并没有广泛应用插件的功能

我对于插件的理解是，他可以做以下的任务:

• 独立有一个管理界面，对外界面，独立注册 URL 路径
• 可以调用 NodeGet 自身的功能 (类比现在的 Agent ToolCall，当然是 AI Agent)
• 具有一定的储存数据的能力

因此，才有了 JS Worker 这一 Part

这个想法客观来说就是将功能交给用户实现

譬如对于一个需求: 当机器 CPU 占用率达到 80% 及以上时，发送通知给用户

Nezha 与 Komari 的做法是每次上报数据时检查，达到 80% 则调用通知函数

若有了插件，则流程是: 定时执行某个 JS 脚本，用 ToolCall 检查数据中是否达到 80%，若达到，则由 JS 脚本自行发送通知请求

用 JS 脚本的优势在于，他可以非常非常灵活地处理用户需要的各种要求，对于特定而复杂的通知要求 (比如多机器联立 / 多项检测同时触发) 具有无与伦比的简单与便捷性

而且还能自定义你需要的通知模板，通知的时候配张图，带个 Hitokoto，都是一般来说难以企及的自定义 (后续 Komari 好像上线了 JS 支持的通知模板，懒得查证了)

这只是 JS Worker 的冰山一角，如果你了解 Cloudflare 的 Workers，那么这可以完全替代其功能

并且鉴于 AI Agent 大流行趋势，编写脚本不再是复杂的工作，AI 在文档的加持下可以编写一个完全可用的脚本

功能独立

NodeGet 本体更像是一个由多个功能部分拼凑的大服务，但是每个功能都不会在第一次启动 NodeGet 的时候有数据

在连接到 NodeGet Dashboard 后，才会在 KV / JS Worker / Token 等地方写入数据，来开启其作为监控系统服务的作用

借用一句来自钟离老爷子的话: 摩拉天然是货币，货币天然不是摩拉。

探针(也许)天然是 NodeGet，NodeGet 天然不是探针。

你大可以将 NodeGet 作为监控服务使用，但是绝对有其他用处

譬如 KV 系统，若你的程序需要一个要求不高的 KV 系统，大可以拿 NodeGet 来作为一个替代

使用 NodeGet 的 KV 系统，不需要使用其他功能，还能享受来自 Token 功能的精细权限控制

还有 Static Stroage 系统，可以直接跑个简单的 HTTP 静态服务器，还能用 API 来 CRUD 文件，照样可以用权限系统

为什么会有这种思路？还是因为 AI Agent 的发展，这些功能还算有用的，虽然生态和支持没搞起来

再来一个如果，如果你用过 Cloudflare 的 Pages 和 KV 和 Workers 等等功能，那你都会在 NodeGet 找到对应。这几个搭配起来就是一个基础服务平台了，所以有的时候我会用 Selfhosted Cloudflare 来形容 NodeGet

发挥所有的功能当然是最好的，NodeGet 开发的所有功能当然是为了让探针监控更好用，但是不妨用在其他地方

Token 权限管理

以上所有的东西都有一个共同的功能穿插在里面，那就是 Token 权限管理

这个可以说是 NodeGet 最重要的系统，他很复杂，也很简单

复杂在于，他的权限设计非常不面向人类，人类可读性几乎为 0

简单在于，颗粒度精确到字段，降低了第三方接入的风险，提高了接入效率

我不想深入讲述其覆盖思想以及设计思路，这会涉及到数论等

大体思路就是，提供的 Token 的范围是集合 A，执行的操作要求是集合 B，B 必须是 A 的子集，Token 权限会将其序列化，来比较权限大小关系。

还是一开始的例子，比如社区要建立一个类 ITDog 的站点，收集全球的监测点的时候，你可以将你的 Agent 用 NodeGet 贡献到站点，并且只用赋予极小的权限

困难

理想很丰满，现实真的很骨感

协作问题

NodeGet 后端开发者有，且仅有我一个，我在 Github 的数据中，为 NodeGet 贡献了超过 400,000 行的 Diff

前端开发者有很多，都是酒神邀请来的具有丰富经验的开发者，在此也同样感谢前端开发者的贡献

在时间上，NodeGet 的后端开发进度较快，前端开始开发前，后端已经能完成作为监控的所有功能

还有就是，并不是所有的开发者 都能理解某个功能 想做些什么，我向每个人解释了项目的大体思路，虽然我也不知道他们理解了没有

鉴于我这个语言表达能力确实有些欠缺，一个功能就算举例说明也无法让每个人都理解

社区

社区有很多人并不需要 NodeGet 这样功能丰富的探针系统，Nezha / Komari 已经满足了他们需求

我也很想让 NodeGet 对于所有用户来说都是可以接受的，所以团队在简化配置这一方面做了非常大的工作

既想让高级用户具有足够可玩性，又想让普通用户开箱即用，还是非常难的

很难向协同开发者解释清楚功能，就更很难向社区解释清楚了

文档为了详细，确实有点长，很多人完全没有看过

最经典的一个例子是，很多用户认为 NodeGet 的数据是储存在 dash.nodeget.com 上面的，上传到官方服务器，如果被黑了都得遭殃。然而实际上它只是一个静态管理面板…

时间

我本来以为，NodeGet 可以在 2026 年的寒假内完成，在新年的时候就可以发布公测版。实际到了六一儿童节那天才发布了半成品的公测版

原因很多，开发进度缓慢是一个、协作困难是一个，总之很多…

上了高中之后，一个星期就一天在家的，更无时间开发，所以放下 NodeGet 了…

心得

把你的用户当成傻逼

我说的，不要太高估你的用户智力

向用户解释概念的事情，我不是很想做，但是必须要做，问这问那的还不如找 AI 呢

特别是对于这种中大型项目，用户理解你的思路，你理解用户的思路，都是极其难的事情

AI 真的好用

刚才说 40w 行 Diff，其实我手写最多不超过 10w 行

我设计的主要是每个功能的架构、Token 鉴权部分，以及最开始的项目初期的调度等

后期绝大多是 API 以及 CRUD 都是 AI 处理的，当然会 Review，不过最多只是看一眼关键步骤

花费 Token 当时有人报销了，全程都是 Opus 4.5/4.6，一个功能大概要 10 个亿的 Token

语言只是工具

用 Rust 的一大原因是我热爱并且会用它，一开始我是为了性能以及占用选择的 Rust

写大型项目该 Leak 的照样 Leak，Leak 了该开火焰图照样开火焰图

一开始决定用 GoLang 还是 Rust 其实没区别，也许如果用 GoLang 的话就没我什么事了

小结

实际我对于这个项目感想真的很多，但是写出来就 200 多行，就这样吧

当然，NodeGet 拥有光明的未来，感谢 @steve1996 的接手