若依还是 g2rain？两套"后台底座"的思路，差的不只是技术栈
做系统开发的朋友，可能都有过这种时刻：新接一个项目，第一周不是在写业务，而是在搭用户、角色、菜单、日志、代码生成这些"永远躲不开"的基础模块。
中小团队大多没有统一的 SSO，每开一个系统就得把这些重复造一遍——耗时、耗力，还很难向上面证明"这算工作量"。
所以"开箱即用的后台底座"一直是刚需。国内这一行绕不开的名字是 RuoYi（若依）；而 g2rain（谷雨），走的则是另一条——AI 原生、面向可持续交付的企业级底座的路。
这篇不吹不黑。先说清楚：g2rain 由谷雨开源团队维护，本文更熟悉它的一侧；但笔者在用若依系框架的很多年里，也确实受益良多。下面尽量客观地把两套东西摆到一起，聊聊它们到底在解决什么不同的问题。
一、先认识两位主角
RuoYi（若依）：把"基础模块"打包好给你
若依从 2018 年一路走到现在，是国内最成熟的开源后台脚手架之一。截至 2026 年 3 月，它仍在高频更新：
- 单体版 v4.8.3
- 前后端分离版（Vue）v3.9.2
- 微服务版（Cloud）v3.6.8
它的技术组合很"经典"：Spring Boot（2.x / 3.x / 4.x 多分支并行维护）+ Shiro / Spring Security + MyBatis + Vue / Element。功能上该有的都有——RBAC 权限（菜单/按钮/数据三级）、强大代码生成器、多语言、完全响应式布局，官方还衍生出 Python / .NET / Go / PHP / React 等一堆语言版本和工作流版本。
它的核心价值一句话概括：帮你把"用户、角色、菜单、日志"这段最无聊又最不能少的工作，一键生成出来，让你专注业务。社区生态极其庞大（Gitee 上百万级 Star、海量二次开发插件），文档和案例多到离谱，新手几乎零门槛。
g2rain（谷雨）：一个"AI 时代"的工程底座
g2rain 是谷雨开源的企业级 AI 原生底座，Apache 2.0，目前 25 个公开仓库、20 个官方项目。它最看重的不是"多租户卖 SaaS"，而是可持续交付——一个系统建在上面，能年复一年地持续迭代、加能力、接 Agent，而不会在复杂度里崩掉。它的技术基线更"新"一些：
- 后端：Java 25 + Spring Boot 4.0.5 + Spring Cloud 2025.1.1 + MyBatis，MySQL 8 / Redis / Nacos / Kafka
- 前端：Vue 3.5 + TypeScript 5.9 + Vite 7 + qiankun 微前端 + Element Plus
- 可观测：OpenTelemetry 全链路
但 g2rain 真正想解决的，不是"再做一个更好的后台脚手架"，而是另一个问题：
当企业系统开始接入 AI Agent——模型能规划、能调工具、能改数据——谁来治理"它到底能不能这么干、干了之后谁来负责"？
所以它把能力分成了五层（边缘入口 / 交互接入 / 平台核心 / 业务域扩展 / 工程支撑），并围绕"AI 原生"给出一套六步方法论：沉淀能力 → DDD 建模 → 最小颗粒度接口 → 注册到 MCP Server → 客户自定义 Agent / Skill → 云端编排、执行、监控与治理。
其中"治理平台"是它和若依最本质的分野（下面细说）。
图 1：同样是后台底座，两条技术路线
二、核心对比表
| 维度 | RuoYi（若依） | g2rain（谷雨） |
|---|---|---|
| 核心定位 | 企业级快速开发脚手架 | AI 原生企业级底座 + 治理平台，强调可持续交付 |
| 后端栈 | Spring Boot（2/3/4 并行）+ Shiro/Spring Security + MyBatis | Java 25 + Spring Boot 4 + Spring Cloud 2025 + MyBatis |
| 前端栈 | Vue 2/3（JS/TS）、Element / Element Plus，多版本并存 | Vue 3.5 + TS 5.9 + Vite 7 + qiankun 微前端 |
| 架构理念 | 单体 / 微服务脚手架，业务写在模块里 | 五层架构 + DDD 分层，模块边界清晰、可插拔 |
| 权限 | 成熟的菜单/按钮/数据三级 RBAC | 平台核心层（iam/basis）统一身份，叠加"权限三者交集"治理 |
| 代码生成 | 强大的一键 CRUD 生成器 | crafter：骨架生成 + 按表生成（已发布 Maven Central） |
| 可持续交付 | 靠约定与文档维持，长期易"各写各的"、难以演进 | 中央架构治理（Profiles + 版本钉死 + 偏差登记）+ 五层架构，让 25 仓库长期一致、系统可年复一年叠能力 |
| AI / Agent | 基本不涉及（靠第三方扩展） | 六步 AI 原生方案 + MCP + Agent 治理（Runtime 梳理中，尚未以自身名义开源） |
| 上手难度 | 低，文档案例极多 | 中高，体系更重、概念更多 |
| 成熟度 / 生态 | 成熟，Gitee 百万级 Star，插件海量 | 较新，25 仓库，生态建设中 |
| 开源协议 | Apache 2.0（主流版本） | Apache 2.0 |
三、差的不只是技术栈，是"在解决什么问题"
把两张表放一起，结论其实很清楚：它们不是替代关系，而是在不同层次上回答不同问题。
图 2：上手难度 × 治理能力，两者在不同坐标
若依回答的是："怎么少写点重复代码？"
它把后台开发的"公共部分"标准化了。你 clone 下来，改改实体、跑一下代码生成，一个带权限的后台就立起来了。它对"中小项目、OA/ERP/CRM、快速原型、外包交付"是降维打击级的效率工具。
g2rain 回答的是："系统要长期演进、还要接入会自己干活的 Agent，工程该怎么组织？"
这恰好是若依那一代框架没碰的话题。g2rain 做的几件"若依没有、或不强制"的事：
- 权限三者交集：一个操作能不能执行，不是单看角色，而是"运行时权威 + 参数溯源 + 风险等级"三者求交集，高风险强制人工确认。
- 上下文治理：Agent 的上下文里，哪些是已验证事实、哪些是模型假设，必须分开管理——不允许把"假设"当"事实"写回系统。
- 最小颗粒度接口 + MCP：把业务能力拆到最小可治理单元，再注册成 MCP 工具，让 Agent 可调、可审计。
- 中央架构治理：用统一的 Profiles 和版本钉死，保证 25 个仓库不会各写各的"最佳实践"。
这些不是炫技，而是同一个判断：AI 进来之后，系统的不确定性会指数级上升，"治理"会从锦上添花变成刚需。 而把"治理"做进架构，正是为了让系统能持续交付——不是在 demo 阶段好看，而是能年复一年地往上叠能力、接 Agent，而不散架、不被自己的复杂度拖垮。这才是 g2rain 真正的着力点：不是多租户卖 SaaS，而是让一个企业系统"活得久、长得稳"。
四、那到底怎么选？
图 3：三种典型场景的选型建议
我的建议很直白：
- 你要的是"下周就交付一个带权限的后台" → 若依，闭眼选。它把这条路上所有的坑都帮你踩平了，生态和文档能救命。
- 你要做一个"要长期持续交付、要上 AI Agent、要统一治理"的系统 → g2rain 的思路更对路。它的设计就是为了让你年复一年地往上叠能力而不崩。但请知悉：它的 Agent Runtime 目前尚未以 g2rain 名义开源（官方确认在梳理中），上手也更重，团队要有一定的架构承载力。
- 中间地带最现实 → 用若依把后台快速搭起来，同时借鉴 g2rain 的治理理念：接口拆到最小颗粒度、权限做"三者交集"、上下文区分事实与假设。这些理念不依赖某个框架，任何后台都能用。
说句心里话：若依这一代框架解决了"造轮子"的问题，功莫大焉；而 g2rain 想解决的，是"轮子会自己跑之后，谁来掌舵"的问题。前者是地基，后者是地基之上必须要补的一层。
写在最后
框架之争，正在从 "谁代码生成更快" 悄悄转向 "谁能治理好 Agent 的执行"。这不一定是 g2rain 赢，但一定是"带治理能力"的底座赢。
g2rain 由谷雨开源（G2Rain）维护，相关事实均基于 2026 年 9 月公开资料与官方口径，Agent Runtime 的开源进度以官方后续公告为准。
如果你也在纠结"后台底座到底怎么选"，或者正在把 AI Agent 塞进现有系统、被治理问题卡住，欢迎在评论区聊聊——关于 Agent 治理的更多细节（权限闸门、参数溯源、风险熔断），我们后续再展开讲。