Workforce Hub 项目简介：从零构建企业级协同办公平台的技术选型之路

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

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

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

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

核心功能模块：

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

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

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

对比：

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

为什么不是 Spring Boot 2？

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

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

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

技术栈一览：

技术	用途
Java 17 + Spring Boot 3.x	主框架
Spring Security + Session + Redis	认证鉴权
MyBatis-Plus	ORM
Flowable	审批流引擎
Spring AI	LLM 统一接入
Spring WebSocket (STOMP)	IM 实时通信
Flyway	数据库版本迁移
Spring Scheduling	Agent 定时任务

前端分了两端：

为什么没有直接用一套？

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

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

为什么多一个 PostgreSQL？

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

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

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

具体怎么落地：

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