AI 浪潮里被忽略的赛道：企业系统连接器
一个传统 Java 工程师的两个月思考与实践。
这两年 AI 落地企业的话题很热，但具体到"怎么用熟悉的 Java 技术栈做这层接入"，能找到的内容非常少。
但企业系统的事——多租户、SQL 安全、限流、审计——恰恰是传统 Java 工程师的本行。
我用两个月做了个项目，验证了一件事：在 AI 浪潮里，传统后端工程师不是要被替代，而是有一条被忽略的赛道。
起点：我看到的 AI 是什么样
留意了一下市面上能看到的 AI 产品，几个主要方向：
- 通用助手类：ChatGPT、Claude、豆包、文心一言
- 内容生成类：图片、视频、语音、AI 配音
- 编程辅助类：Copilot、Cursor、Claude Code
- 垂直 Agent 类：RAG 知识库、Workflow 编排、自动化 Agent
它们有个共同点：几乎都不需要传统的企业级后端。
模型即服务，前端调一下接口就完事。Spring、关系型数据库、企业级中间件这些东西，在这类产品里几乎没出场。
那一段时间我就在想一件事：作为一个 Java 开发者，我在这股 AI 浪潮里能做点什么？
不是跟风转去做 Prompt 工程，不是把过去的经验全部丢掉重新当新手——这两条路成本都很高，而且我也不太相信"重头来过"是大多数传统开发者的最优解。
我想找的是一条能复用过去经验、又跟 AI 强相关的方向。
思考了一段时间，慢慢有了一个想法。
一个被很多人忽略的事实：老系统不会被 AI 替代
如果你只看科技媒体，会觉得 AI 要重塑一切了，仿佛明年所有企业系统都要被 AI 推倒重写。
但如果你做过几年企业项目，你会知道这个剧本根本演不起来。
设想一个常见的财务系统：跑了十几年、模块复杂、跨多张表的状态流转、有些规则甚至没有文档，只在某个老员工脑子里。让 AI 重写？连完整需求文档都写不齐。
ERP、CRM、进销存、订单系统、财务系统——咱们见过 / 用过的中大型企业系统，都是这个样子：
业务规则极其复杂，跨部门耦合，没人能完整说出"这个系统到底在做什么"。代码里藏着各种历史包袱，数据是公司的命脉，丢一条订单可能引发投诉，错一份合同可能被告。任何改动都要走变更评审、回归测试、合规审计——做一次发版要拉七八个部门开会。
让企业把这些系统全部用 AI 重写？只要你在企业里提过这种方案就知道：没有一家正经公司会批准。预算扛不住，风险扛不住，合规扛不住。AI 再先进，企业的稳定性优先级永远在它前面。
所以我得出第一个结论：企业不会推倒老系统，但企业仍然想用 AI。
这中间就有一个空缺。
那个空缺：AI 想"读"老系统，老系统读不懂 AI
具体设想几个场景：
- 销售老板想知道上周销冠是谁
- 采购想看库存周转
- HR 想查这周谁加班最多
- 运营想分析昨天哪个 SKU 卖得最好
AI 听得懂这些问题——这一步是它擅长的。但要回答这些问题，AI 必须真的去查企业的数据库，否则它只能编一个看起来合理、但跟真实数据无关的答案。
"去查企业的数据库"这件事，AI 自己做不到。它不知道这个企业用的是 PG 还是 MySQL，不知道订单表叫 orders 还是 t_order，不知道字段是 created_at 还是 gmt_create，更不可能拿到生产数据库的账号密码。
所以中间需要一层东西。这层东西的工作是：
接住 AI 的请求，认出这是哪个企业（多租户），安全地查到企业自己的数据，再把结果包装成 AI 能理解的格式返回。
这层东西需要懂什么？多租户隔离、鉴权、限流、SQL 安全防线、异构数据源整合、加密、审计、合规——这些东西恰恰是传统企业级 Java 工程师的日常。
不是新东西。是过去十年我们一直在做的事。
这就是我说的"被忽略的赛道"：AI 落地企业的真实瓶颈不在模型，在这一层连接的工程化。模型再强，没有这一层，AI 看不到企业的真实数据。
我做了一个企业连接器
想清楚这件事之后，我就动手做了一个项目，叫 Enterprise Connector。
它是一个面向多租户的 MCP（Model Context Protocol）Server——MCP 是 Anthropic 提出的开放协议，目的就是让 AI Agent 能用统一方式发现工具、调用工具。
AI Agent（Claude Desktop、Cursor、自研的 Agent 这类）通过 MCP 协议跟它对话，它在背后帮你处理认证、租户路由、安全防线、限流、审计这些事，最后去查企业的真实数据。
整体长这样：
flowchart LR
User[用户] --> AI[AI Agent<br/>Claude / Cursor / 自研 Agent]
AI -- MCP 协议 --> EC[Enterprise Connector<br/>本系统]
subgraph EC内部 [Connector 内部]
direction TB
Auth[认证 + 租户识别]
Policy[限流 + 授权 + 安全防线]
Adapter[适配器路由]
Auth --> Policy --> Adapter
end
EC --> EC内部
Adapter --> DB[(企业 DB<br/>PG/MySQL/Oracle/SQLServer)]
Adapter --> API[企业 HTTP API]
Adapter --> Audit[(审计日志)]
style EC fill:#e3f2fd,stroke:#2196f3,stroke-width:2px
style EC内部 fill:#fff4e6,stroke:#ff9800
AI 在最左边，企业的真实系统在最右边，中间这块——多租户、安全、隔离、可观测——就是这个项目要做的事。
完整代码已开源在 GitHub：enterprise-connector
项目从架构判断到具体实现涉及不少工程取舍——比如 Spring AI MCP 启动快照机制下怎么做多租户 tool schema、4 层 SQL 安全防线、高级租户自由 SQL 的安全校验、多租户 DataSource 池的 LRU + 双锁实现……这些会在后续博客里逐篇展开。
一个核心想法：让企业不写代码就能接 AI
做这个项目时，我有一个很直接的目标：企业接入 AI 的成本应该尽量低，最好低到运维改改配置就能搞定，不用专门为了"接 AI"再写一堆代码。
但企业的情况差异很大。有的企业开发力量薄弱，业务又比较直白；有的企业有自己的开发团队，业务规则也比较复杂。一种接入方式很难同时让两类企业都用得舒服。
所以我做的时候考虑了两种接入模式：
SQL 模板模式
这条路适合业务清晰、想快速接入 AI 的企业。
比如一个中小商家，主要的查询场景就那几种——查订单、查库存、查客户。这种企业大概率没有专职后端开发，也不愿意为了"接 AI"再投入开发资源。
对这类用户，运维只需要在系统里配几条 SQL 模板，比如"按时间范围查订单"、"按 SKU 查库存"——填写 SQL 文本、声明几个参数、给一段描述。配完之后，这些 SQL 模板就自动变成 AI 能调用的 MCP 工具，AI 通过 tools/list 就能发现它们，按模板里声明的参数来调用。
整个过程不需要任何编码。运维改改 DB 表，业务就接入 AI 了。
API 模式
这条路适合有开发能力的企业。
有些场景下，单条 SQL 表达不完业务逻辑——比如"查询要跨三个库，还要做几层过滤和聚合，再加一些规则判断"。这种情况硬塞进 SQL 模板既不优雅也不安全。
更好的做法是企业自己写一个 REST API，把所有复杂逻辑封装在 API 里，然后把 endpoint 配置进系统。系统会把这个 API 也包装成 MCP tool 暴露给 AI——从 AI 的视角看，调 SQL 模板和调 API 完全一样，都是"调用一个工具"。
差异只在于封装边界放在哪里：模板模式是系统帮你封装 SQL，API 模式是企业自己封装好之后接进来。
两种模式背后是同一个想法
不管走哪条路，企业接入 AI 的工作量都被压到了"配置"层面。无非是配 SQL 文本，或配 API 地址。剩下所有事情——MCP 协议握手、tool schema 自动生成、参数校验、限流、鉴权、审计、加密、多租户隔离——系统全部接管。
对企业来说这是 5 分钟的配置，对 AI 来说这是标准的工具发现。中间那层复杂度，被收敛进了系统内部。
用了什么技术
把项目用到的主要技术列一下：
| 类别 | 选型 |
|---|---|
| 语言 / 框架 | Java 21 + Spring Boot 3.4.5 |
| AI 协议接入 | Spring AI 1.1.4（spring-ai-starter-mcp-server-webmvc） |
| ORM | MyBatis-Flex 1.11.6 |
| 元数据 DB | PostgreSQL 16 |
| 缓存 | Caffeine（L1）+ Redis（L2） |
| 限流 / 熔断 | Resilience4j 2.3.0 |
| SQL 安全 | JSqlParser 5.1（AST 校验） |
| 加密 | AES-256-GCM（JDK 标准库） |
| 可观测 | Micrometer + Prometheus + Logback JSON |
| 集成测试 | JUnit 5 + Testcontainers |
| 部署 | Docker + docker-compose |
整个技术栈的特点是"传统 Java 企业栈 + AI 协议层（Spring AI MCP）"，没有一个组件是为了"蹭 AI"而新引入的。所有东西都是 Java 后端十年积累下来的成熟选型，加上一层 MCP 协议接入。
这正好对应了我做这件事的初衷：复用传统经验，做一个 AI 时代的连接层。
每条选型背后的具体取舍（包括为什么选 MyBatis-Flex 不选 Plus / 为什么选 GCM 不选 CBC / Testcontainers 在 Windows 上的坑等）会在后续博客里逐个展开。
项目状态：PoC 阶段，工程上站得住
老实交代下当前状态：
- ✅ 代码完整度：数据层、核心服务、异步任务、MCP 接入、安全防线、可观测、多数据源、多方言适配——全部落地，160+ 测试用例覆盖
- ✅ 架构决策比较扎实，每个工程取舍都对应一个真实的考虑
- ⚠️ 没有在真实生产环境跑过，没有真实的租户接入
- ⚠️ 产品化的东西（商家管理后台、计费系统、监控告警）都没做
我做这个项目的目的不是马上把它变成商业产品，而是想验证一件事：
"给老系统接 AI"这条路，作为一个传统 Java 开发者，能不能用熟悉的技术栈做出来，做出来的东西工程上是不是站得住脚。
到现在为止，我自己的回答是：能做出来，工程上也站得住。
生产侧还有什么坑、企业落地时还会遇到什么问题——这是我接下来想跟同行讨论的事。
系列预告
这是开篇。接下来 10 篇会一篇拆一个工程难题：
| # | 主题 |
|---|---|
| 01 | Spring AI MCP 1.1.4：tools/list 启动快照陷阱与 per-session schema 落地 |
| 02 | 为什么 AI Agent 不能直连数据库：4 层防线设计 |
| 03 | 三层配置体系：消除硬编码 + 运行时热更新 |
| 04 | 多租户 DataSource 池：LRU + 双重锁 |
| 05 | 软删 vs 物理删：每表独立 + 二级认证 |
| 06 | PREMIUM 租户自由 SQL：占位符子集校验 |
| 07 | MyBatis-Flex 实战：复合主键 + 软删 + 多方言 |
| 08 | Testcontainers 在 Windows 的 4 种死法 |
| 09 | AES-256-GCM 凭证加密全链路 |
| 10 | 项目反思：从 PoC 到能上生产差什么 |
你最想先看哪一篇？评论区告诉我——下一篇会按反馈安排顺序。
写在最后
这套思考——传统开发者在 AI 时代的位置、企业怎么接 AI、连接器这层怎么设计——在我自己脑子里转了挺久，但毕竟是一个人的判断。
可能有想得对的地方，也可能有完全没想到的盲点。
把项目和系列博客发出来，主要的目的有三个：
- 记录自己的思考过程——半年后回头看，至少能知道当时为什么这么决定
- 给同样在思考这个方向的人一个参考——如果你也是传统后端开发者，最近也在想"AI 浪潮里我能做什么"，希望这个项目对你有点帮助，哪怕只是排除掉某条路也是有价值的
- 听听同行的想法——如果你做过类似的项目，或者觉得我哪个判断有问题、哪个设计不合理，欢迎评论区聊
完整代码：enterprise-connector
如果觉得这个方向有意思，点个赞 / 关注追更——后续 10 篇技术拆解陆续发出来。
