最近总算有空整理一下这个折腾了大半个学期的项目——Workforce Hub。

说实话，一开始的动机很简单：大三了，得有个拿得出手的项目。但真正开始写之后才发现，一个"企业级"系统的复杂度远超课堂上的 CRUD 练习。今天先聊聊这个项目是什么、为什么选这套技术栈，后续再分模块展开说。

一、这个项目是做什么的？——企业协同人事平台

简单说就是一个可以部署在企业自己服务器上的钉钉。员工用它聊天、请假、打卡，领导用它审批、管理团队。但和普通 OA 不一样的地方在于，我们在业务流程里嵌入了 AI Agent。

核心功能模块：

二、为什么选这套技术栈？——一个普通大三生的选型思考

2.1 模块化单体 vs 微服务

关于架构形态，一开始确实纠结过要不要拆微服务。但看了不少文章和实践后，结合自己的情况做了以下判断：

我：一个人，一台 Mac mini，一个 deadline
微服务：需要 10 个 repo、10 个 CI pipeline、服务发现、分布式事务...

血泪教训：对于个人项目或者小团队项目，在业务边界还不清晰的时候就拆微服务，大概率是在给自己找事做。模块化单体先把核心跑通，后续真要拆也有迹可循。

对比：

我的选择：模块化单体，但做了一些"预拆分"设计——通过 SPI 接口解耦模块，未来需要拆的时候只要把接口实现抽成独立服务即可。

2.2 后端选型：Spring Boot 3 + MyBatis-Plus

为什么不是 Spring Boot 2？

因为我们用了 Java 17 + Spring Boot 3.x，原生支持虚拟线程和 GraalVM AOT 编译。虽然这两个特性在这版项目里没有深度使用，但至少不用踩"从 2 升 3"的坑。

为什么是 MyBatis-Plus 而不是 JPA？

说实话我对 JPA 的"自动建表 + 延迟加载"有心理阴影。MyBatis-Plus 至少 SQL 是可见的，出了问题能直接看是哪个查询炸了。当然代价是多写点 XML，但配合 IDEA 的 MyBatis 插件，开发体验还不错。

技术栈一览：

2.3 前端选型：Vue3 + TypeScript + Element Plus

前端分了两端：

• admin-web（管理后台）：用 Element Plus，标准的 B 端风格，管理员操作的界面
• employee-web（员工端）：自研 UI 组件，消息优先的协同工具风格

为什么没有直接用一套？

因为管理员和普通员工的使用场景完全不同。管理员需要表格、表单、批量操作；员工更关心消息、审批、考勤。如果硬塞进同一个 UI 框架，要么管理员觉得不够专业，要么员工觉得太重。

三、数据存储：四个仓库各司其职

这也是我第一次在一个项目里同时接入四种存储：

为什么多一个 PostgreSQL？

因为 RAG 知识库需要向量检索。MySQL 虽然本身没什么问题，但 pgvector 做向量计算的性能和生态比 MySQL 的方案成熟。虽然多维护一个数据库有点麻烦，但在知识问答这个功能上，选错存储的代价更大。

四、Agent 平台：这个项目的核心差异点

大多数 OA 系统里，AI 就是一个聊天机器人叠在界面上。我们这个的思路不一样——Agent 是业务链路的一等公民。

Agent = 模型配置 + Prompt 模板 + 工具绑定 + 知识库绑定 + 触发器 + 权限审计

具体怎么落地：

1. 审批流程中的预审节点：请假天数超了？AI 直接驳回，不用等领导手工发现
2. 会话中的 @Agent 知识问答：在聊天框 @ 一下 Agent，"年假怎么算"、"报销流程是什么"，它从公司制度文档里检索回答
3. 定时任务主动提醒：考勤异常、假期快过期、审批超时未处理

这部分后续会单独写一篇展开说，设计思路比较有意思。

五、项目当前进度

总结

这个项目的核心思路其实就一句话：用模块化单体保证开发效率，用 Agent 平台做差异化，用 Docker Compose 降低交付门槛。

对我自己来说，它最大的价值不是代码本身，而是逼着我去理解一个完整的系统该怎么设计——从架构到数据库到接口到部署，课堂上学不到的工程思维在里面。

下一步：下一篇文章聊聊 Flowable 工作流引擎在实际项目中的集成过程，以及在审批流程嵌入 AI 预审的设计细节。

环境信息：JDK 17 + Spring Boot 3.4 + Vue3 + MySQL 8.4 + PostgreSQL 16 + Redis 7 + MinIO 更新日期：2026年5月14日