团队里想给自己搭一个 Agent 工作台的人，最近半年问得最多的一句话是：能不能装在自己服务器上，数据不外流，界面还像样？
LobeHub 是这个问题的热门答案之一。它现在是 85,397 星、16,292 个分叉，11 月 14 日当天还在提交代码，前身就是那个很多人用过的 LobeChat。我把整个仓库拉进沙箱，不装任何依赖，只做静态核对，数了 24,954 个文件，也数出了三个会直接影响你决策的事实：116 个内部包，仓库里一个根锁文件都没提交；package.json 里写的是 MIT，根目录的许可证文件却是另一套带商业附加条款的社区许可；最近 100 条发行版里，93 条是每次提交都会生成的预发布构建。
先说清一件事：它虽然带了 56 份写给 AI 看的技能说明，但它不是技能库，是一个近三万个文件的应用仓库。这一点后面还会绕回来，因为它恰好是这篇里最有意思的地方。
它到底长成了什么
一句话：一个可以自己托管的 Agent 工作台。网页端、桌面端（Electron 打包的本地应用）、命令行工具三个入口共用一套后端；后端是 Next.js 16 + React 19，界面用 React 单页应用的形式挂在 Next.js 里，数据层是 PostgreSQL 加 Redis，文件走对象存储。
先看规模。我拿到的这份快照是默认分支 canary（它们把开发分支叫这个名），目录分布非常不均匀：
| 目录 | 文件数 | 装什么 |
|---|---|---|
src |
10,108 | 网页端界面与前端状态 |
packages |
7,217 | 116 个内部包：数据库、Agent 运行时、工具集、多语言文案 |
apps |
4,872 | 服务端、桌面端、命令行、分享页、工作台 |
locales |
1,062 | 18 种语言的文案 |
src、packages、apps 三个目录加起来 230MB 上下，全仓 21,602 个 TypeScript 文件（.ts / .tsx），测试文件 6,669 个，占全部代码文件约三成。对一个要同时发网页版、桌面版、命令行版本的产品来说，这个测试比例是合理的工程习惯，不是刷数字。
它跟别的开源聊天前端最不一样的地方
不是界面，也不是模型接得多。是这个仓库里塞了一整套「给 AI 看的说明书」，而且是真在用的。
根目录有一份 199 行的开发规范文件，开头就写清了分工：仓库全局的架构和流程归这份文件管，具体实现规则全部下沉到技能目录，做到「单一事实来源」。然后它逐条点名——改 React 组件之前先读 react 这份技能；改页面路由之前先读 spa-routes；要理解代码分层先读 project-overview。
我去核了这套说法有没有真落地，结论是落地了：
| 我核的地方 | 结果 |
|---|---|
| 技能说明文件数量 | 56 份 |
| 这 56 份合计行数 | 8,689 行 |
| 给 AI 读的文档目录下 Markdown 总数 | 287 份 |
| 这个目录的体积 | 5.3MB |
| 根规范里点名要读某份技能的地方 | 26 处 |
| 被标成「可手动调用」的技能 | 3 份，其余由 AI 按场景自动读 |
也就是说：规则不是写在规范文件里堆成一大坨，而是一份规则一个文件，规范文件只当目录和入口。举个具体的——改页面路由这件事，spa-routes 那份技能里明确写着公共的网页端和桌面端路径必须注册在同一个共享文件里，两个平台各自的配置文件只许写真正的差异，不许把同一条路由抄两遍。
还有一层更少见的：那个目录下面另有一整套「验收」流程，51 个文件，包含截图、录屏、探针脚本，还有一份把项目专属命令、端口、服务写全的说明文件。它要求改完行为之后，到真实产品上跑一遍，把证据（截图或录屏）发布出来，PR 里贴上验收链接。规范文件里还特别写了一句提醒：本地开发时有个能连到线上后端的调试代理，但那是开发便利，不是验证环境。
这是它和同类项目最本质的差别：它在用 Agent 维护一个 Agent 产品。 顺带一个小反差——自动选品工具看到仓库里有 56 份技能说明，会直接把它判成「技能库」，可这明明是个应用。
三个硬事实，都自己核过
第一，没有根锁文件。 锁文件记录每个依赖的确切版本，是「今天在你机器上装出来的东西，和三个月后别人装出来的东西一致」的唯一凭据。这个仓库的情况是：
| 核对项 | 实际结果 |
|---|---|
| 根目录的依赖锁文件 | 不存在 |
| 另外三种常见锁文件 | 全部不存在 |
| 忽略清单第 54 行 | *.lock |
| 忽略清单第 151 行 | pnpm-lock.yaml |
| 工作区配置第 1 行 | lockfile: false |
| 生产依赖 + 开发依赖 | 313 + 110 = 423 条 |
| 内部工作区包 | 116 个 |
| 唯一被提交的锁文件 | 桌面端自己的那一份（54 万字节），因为桌面端是独立工作区 |
配置里那一行写得很直白：根工作区不生成锁文件。它们改用了另一套办法——在工作区配置里固定了一批关键依赖的版本，还有一条「新版本发布后最短等待期」的策略，代价是每次安装都可能解出一组不完全相同的依赖树。对 423 个外部依赖加 116 个内部包的组合来说，这是「可复现性」上的一处空白，不是笔误。同一份配置里还留着一句注释，说某个补丁是为了「在没有根锁文件的情况下」保持生效。
第二，许可证三处口径不一致。 这条最需要你自己判断，我只列事实：
| 出处 | 写的是什么 |
|---|---|
| 打包配置里的许可证字段 | MIT |
| npm 上同名包的许可证字段 | MIT |
| 根目录许可证文件 | 自称社区许可，基于 Apache 2.0，附两条额外条件 |
| GitHub 接口返回的许可证 | 识别为「其他」，标准标识无法匹配 |
许可证文件里那两条附加条件，原文大意是：一，可以商业使用，包括直接把它当前后端服务跑起来、不改源码；二，如果你想基于它做一个衍生品再分发，必须先向出品方拿到商业授权，联系邮箱也写在了里面。另外它声明贡献者同意出品方可以自行收紧或放宽开源协议，且贡献的代码可被用于其云版本。
对普通读者意味着什么：自己部署来给自己团队用、改了自己用，条款没拦你；但把它改造成一个产品对外分发，需要先发邮件谈授权。三处口径里打包配置和 npm 那两处写 MIT，与根目录文件的实际条款不一致——这是打包元数据没有跟着许可证变化更新，不是隐藏条款。要不要在意，取决于你打算走到哪一步。
第三，版本号几乎失去了索引意义。 我拉了最近 100 条发行版记录分类：
| 类别 | 条数 |
|---|---|
| 每次 PR 触发的夜间构建 | 86 |
| 预发布版本（带 canary 后缀那种） | 7 |
| 真正的语义化版本 | 7 |
| 被标记为「预发布」的比例 | 93% |
这 100 条覆盖 10 月 7 日到 11 月 13 日，38 天，平均每天 2.6 个发行版。把这三个数字摆在一起对照着看，更能说明问题：仓库里的版本号是 2.3.3，GitHub 上最近的稳定标签是 v2.3.3、最新的标签是 v2.3.4-canary.1，而 npm 上这个包的最新版本停在 2.1.26，发布于 2026 年 2 月 10 日——九个月没动过。想靠版本号判断「我装的是哪个功能状态」，在这个项目上基本走不通。
自托管不是一条命令的事
它们的部署目录里备了三套容器编排文件（也就是描述「要起哪些容器、怎么连起来」的配置文件，分开发用、部署用、评测用），部署那套我逐个服务数了：
| 服务 | 作用 | 能不能省 |
|---|---|---|
| 应用本体 | 网页与接口 | 不能 |
| 网关 | 把 Agent 的运行过程推给浏览器，走长连接 | 不能，默认开启 |
| PostgreSQL（带全文检索扩展） | 主数据库 | 不能 |
| Redis | 缓存与会话 | 不能 |
| RustFS | 对象存储，存图片和文件 | 不能 |
| RustFS 初始化任务 | 建桶、设跨域规则，一次性的 | 不能 |
| SearXNG | 联网搜索 | 可去掉，但联网搜索功能就没了 |
| Elasticsearch 三件套 | 全文搜索的进阶方案 | 可选，默认不开，开了要单独 2GB 内存 |
必需的环境变量 19 个，其中四个密钥由安装脚本自动生成（配置加密密钥、登录签名密钥、网关令牌、内部签名密钥对）；另有 13 个可选变量在示例文件里以注释形式给出。安装脚本 862 行。根目录的构建文件 375 行、4 个阶段，CI 流水线 31 条。
结论很直接：这不是一个 docker run 就能跑起来的聊天前端，是一套要起五个以上容器、配四个密钥、还要给对象存储单独配跨域的服务。示例文件里甚至专门写了一句——如果应用地址是内网 IP，AI 生图这类功能会失败，得额外补一个内部地址变量。
测试面：我跑成了什么，没跑成什么
本机沙箱里没有现成的 Node 环境，我把宿主机的 Node 二进制（v24.22.2）拷进沙箱，只跑那些不依赖第三方包的自测脚本：
| 脚本 | 结果 |
|---|---|
| 构建跳过逻辑自测 | 8 项全过 |
| PR 准入检查自测 | 19 项全过 |
| 打包体积闸门自测 | 10 项全过 |
| 体积基线查找自测 | 1 项全过 |
| 体积评论生成自测 | 8 项全过 |
| 命令行发版脚本自测 | 跑不起来，缺第三方模块（未安装依赖） |
这 46 项全过，说明它们的构建和发版自动化本身是带回归测试的。但这只是一个边角：项目主体那 6,669 个测试文件我一个都没跑——423 个依赖在 700MB 内存上限的沙箱里装不完，装了就是拖垮这台机器。所以本篇不评价它的测试质量，只记录我实际跑过的那部分。
放进坐标系里看
站内评过的对照物里，LibreChat 是最直接的对照组：同样是自托管 AI 前台，同样接多家模型，许可证是干净的 MIT，部署要 5 个服务、203 个环境变量。差别在定位——LibreChat 卖的是「把对话留在自己服务器」，LobeHub 卖的是「一群能自己干活的 Agent」，所以它多了网关、桌面端、命令行，也多了那套给 AI 读的规则库。
Agent 框架那一侧可以看 deepagents：它给你一套拆任务的框架，你自己写业务；LobeHub 反过来，把界面、存储、权限、工具全配好，你要的是接受它的做法。前者适合要嵌进自己系统的人，后者适合要一个能直接用的成品。
我的判断
值得放进观察清单，但别被 8.5 万星冲昏。它的工程质量在同类里偏上：测试覆盖到三成、自动化脚本自己带测试、规则写得克制（一份规则一个文件，规范文件只当目录）。真正的门槛在三个地方，而且都不在代码里：
一，运维成本。五个必需容器、四把密钥、对象存储跨域、内网地址这类坑，配下来是半天到一天，不是五分钟。
二，许可证边界。自用、自托管、自己改，条款没拦；做成衍生品对外分发要先拿商业授权，而打包元数据里写的还是 MIT，容易让人误判。
三，发版噪音。93% 的发行版是自动构建，npm 上的包九个月没更新，别把「发行版页面很热闹」当成「功能在按版本迭代」。
没跑成它自己的完整测试，所以我不评价它的测试质量。 这一条比前面三个数字都重要：你可以相信我说过的每一个数字，但别把「46 项全过」外推成「这项目很稳」。
关注 AI商业快讯，每天一篇 AI 热点深度解读。想对照自托管这一侧的取舍，可以翻我们评过的 LibreChat；想看 Agent 框架那一端怎么拆任务，可以翻 deepagents。