1. 为什么“万物皆可若依”：先看懂平台架构的底层基因

做了几年后台管理系统，我越来越觉得若依（RuoYi）这类脚手架最大的价值不是替你写代码，而是替你规范了“权限、组织、日志、监控”这些上一代人肉硬扛的脏活累活。到整合AI这一步，很多人第一反应是“直接调API不就行了”，但真正动起手来，你会发现平台本身的架构基因决定了AI功能能长成什么样。所以这篇“拔高原理篇”，我想先带你把若依的底层逻辑翻个底朝天，再讲AI怎么融进去最自然。

若依目前主流的两个分支，一个是专门做前后端分离的RuoYi-Vue，一个是基于Spring Cloud的RuoYi-Cloud微服务版。两者在表结构上高度一致，都围绕“用户-角色-菜单-部门”这套RBAC模型展开，区别在于微服务版把“系统管理”模块拆成了独立服务，引入了注册中心、配置中心和网关。理解这一点对整合AI至关重要，因为AI能力本身可以是一个嵌入现有系统的功能模块，也可以是一个独立部署的AI服务，你选哪种路线，完全取决于你的基座是单体还是微服务。

举个例子，在RuoYi-Vue里，你写一个AI问答模块，就是普通的Controller加Mapper，跑在同一个JVM里，连跨服务调用的序列化成本都不需要考虑。但如果你的基座是RuoYi-Cloud，AI模块理论上更适合拆成一个独立的“AI服务”注册到Nacos上，由网关统一路由，这样才能享受微服务带来的独立伸缩与故障隔离好处。我在实际项目里见过很多团队在单体版本里硬拆微服务，又在微服务版本里把所有业务塞进System模块，两头都不讨好。所以整合AI之前，先得对自家基座的门派心中有数。

另一个关键点在于若依本身提供了完善的数据字典、定时任务、操作日志和缓存服务。这些能力在AI场景里常常被忽略，但用好了非常出效果。比如数据字典可以用来管理AI模型的可选配置，像温度参数、模型版本，而不需要写死在代码里；定时任务可以用来做模型调用量的日汇总，甚至定时触发离线分析任务；操作日志天然可以记录谁在什么时间问了AI什么问题——这个在合规和内审场景下特别重要；而缓存服务，则直接决定了你回答用户问题时能不能扛住高并发。

我这里简单列一张思维对照表，把若依Vue版和Cloud版在AI整合时的差异明确一下：

从这张表能看出来，单体版本胜在集成简单，微服务版本胜在扩展灵活，但两者在AI整合这条路上，真正拉开差距的都是在“会话管理”和“配置治理”这两个细节上。很多人说若依漏洞多、代码老，我不否认，但就我个人的经验判断，若依更大的价值是它的扩展边界足够清晰——你完全可以只把它当成一套“带权限体系的Spring Boot工程”，至于AI层怎么长出来，主动权在你手里。

2. 两种整合路线：内嵌式模块与独立AI服务，怎么选怎么看

明确了基座类型以后，接下来最关键的问题就是：AI能力以什么身份进入若依体系？目前主流的做法有两条路，一条是把AI功能做成若依内部的一个业务模块，另一条是把AI能力架构成一个独立部署的服务，再反接回若依。这两条路我都有实际落地经历，下面把各自的适用场景、原理和坑都拆开讲。

2.1 路线一：AI作为若依内部模块的“嵌入式”套路

嵌入式整合最直观的做法，就是在若依的管理端里新建一个“AI对话”菜单，前端用Vue组件实现聊天窗口，后端写一个Controller接收用户输入，然后由Java代码调用大模型服务的API，拿到结果后返回给前端。整个过程在若依体系内部闭环，用户、权限、日志都沿用现有机制。这种方式的原理本质上是把“模型推理”当成一个远程API来依赖，不关心模型部署在哪里，只需要关心HTTP调用这个动作本身。

我实际搭建过一套对话模块，流程差不多是这样：用户在页面上输入问题，前端把消息内容POST到后端的/ai/chat接口，Controller里先校验用户是否在已登录状态（若依的Token机制自动处理），然后从业务层组织好系统提示词和用户输入，拼装成大模型API要求的请求结构，最后通过RestTemplate或Hutool的HttpUtil发起远程请求。返回的文本直接回填到页面，整个过程没有引入任何新的中间件或服务。

这种方案的优势很明显，第一是开发速度快，半天到一天就能跑通一个能用的对话接口；第二是权限天然统一，完全复用若依的用户体系和菜单权限，不需要额外做身份认证；第三是运维成本低，部署架构不需要变化，原来服务器上跑的是单体Jar，现在还是那个Jar。代价则是，所有请求都经过主应用线程池，如果模型响应时间较长（比如超过10秒），容易占用Web服务线程，导致其它业务接口响应变慢，所以必须依赖Java的异步机制（例如将请求提交到独立线程池，或使用Spring的@Async注解），再配合前端轮询或SSE（Server-Sent Events，服务端单向推送）来承接结果。

嵌入式方案比较适合的场景是“低频内部工具”，比如企业内部的知识库问答、运营团队的文案生成助手，请求量不大，逻辑简单，不需要独立的模型网关和负载管理。如果业务目标是面向C端大规模用户提供AI服务，嵌入式方案的线程占用和限流短板就会被快速放大，这时候就得考虑第二条路。

2.2 路线二：独立AI服务解耦，打通若依的“神经系统”

独立AI服务的思路，是彻底把“模型推理”从若依业务系统中抽出来，部署成一个独立的Python服务（或者Java服务），这个服务负责模型调度、Prompt模板维护、上下文管理、多模型路由这些脏活累活，而若依这边只充当“消息入口”和“权限认证层”。两者之间通过HTTP接口联通，若依将用户ID、问题内容、会话ID发送给AI服务，AI服务处理完成后返回结果。

这个架构在原理上类似于“前后端分离”思路的延伸——只是把UI层和后端业务层分离的理念，再次应用到了业务层与AI推理层之间。好处有三层：

• 隔离性：大模型调用过程中的异常（比如超时、模型崩溃、限流触发）不会拖垮主业务，AI服务独立崩溃独立恢复，不影响若依的登录、权限、CRUD这些基础功能。
• 伸缩性：AI推理是典型的计算密集和IO密集混合型负载，独立部署后，可以根据请求量单独为AI服务增加实例数，而不需要把整个若依应用一并扩容。
• 语言自由：很多成熟的大模型生态其实是在Python侧，比如LangChain、LlamaIndex，以及各类向量数据库客户端，你用Java硬写AI编排层，技术选型上非常别扭。独立服务让你可以顺理成章地用Python承接AI编排，Java负责业务数据，各用各的看家本领。

独立服务模式的技术核心在于两件事：其一是接口契约设计，双方要约定好一套稳定的通信协议，包括请求头携带的认证信息（若依登录用户通过token透传）、请求体的消息结构、返回体的状态码规范；其二是上下文关联，既然AI服务独立于若依，它必须自己去存储和管理每个会话的历史消息，通常是落到Redis里，以会话ID为key维护一个消息列表。

我在做企业级AI识别系统的时候就选择了这条路线，原因是调用链路上不光有文本对话，还有图像识别、文档解析这类重负载任务，这些任务一旦失败，重试逻辑和资源消耗都不适合放在Java事务里硬扛。独立Python服务的模式，能让我灵活地使用异步任务队列（Celery这类组件）去串接整个识别流程，Java侧只负责提交任务和轮询结果，体验非常顺滑。

2.3 选型之前，先画一张决策图

很多新手容易陷入“什么火用什么”的盲目，但以我的经验，这里最关键的是先看你自己对系统的控制力预期。

如果你是一个人维护整个系统，没有专职运维，也没有独立的AI基础设施团队，那嵌入式模块是你能掌控的最稳妥范围。管理端后面加一个“AI助手”菜单，内部用用，成本极低，出了问题你直接看若依日志就行。反之，如果你所在团队已经有多条产品线，未来各个系统都可能有AI需求，那独立AI服务本质上是建设一个“AI能力中台”，一次性把接入层的认证、审计、模型路由、配额管理都做进去，后续接任何业务系统都只是加一个对接配置而已，这也是“AI Agent”落地时最推荐的治理模式。

我见过最可惜的案例是，一个团队在单体若依里强行嵌入了一个AI对话模块，开始用着挺好，后来用户量涨起来，主业务接口和AI接口互相挤占线程池，频繁出现网关超时和系统卡死。当时改造已经来不及，只能连夜把AI逻辑拆出去重做成独立服务，中间的痛苦和业务中断只有经历过才懂。所以我的建议是，评估AI整合方式时，不要只看“现在能不能跑”，更要看“半年后还能不能扛”。

3. 原理拔高：数据流、会话上下文与Token算力经济学

不少教程都会告诉你“拿来即用怎么对接”，比如创建个Key、填下API地址、跑个Demo。但这篇既然是拔高原理篇，我更想花整块篇幅来聊聊那些决定AI功能真正好用的底层机制，也就是数据流怎么设计、会话上下文该怎么管、以及Token成本怎么精算。

3.1 全链路数据流设计：从用户输入到结果落库

先画一个纵向的数据流全貌（用文字描述，你脑海里可以勾勒出一张时序图）：

用户在前端聊天输入框敲下一句话，点击发送。前端把文本打包成JSON，带上若依的登录Token，POST到后端网关接口。网关负责校验Token和权限，随后将请求路由到若依的AI业务Controller。Controller拆出用户ID、会话ID、消息内容，调用AI核心服务。AI核心服务把历史会话数据从Redis里取出来，拼上系统预设的Prompt模板，一起组装成一条完整请求，发给大模型API（比如通义千问的接口）。大模型处理完后返回流式文本，服务端通过SSE长连接将内容推给前端。前端逐字渲染。同时在异步线程里，这轮问答的输入输出、耗时、Token消耗被记录到日志表，或者通过定时任务汇总统计。

这条链路中有一个非常容易被忽视的瓶颈：用户的历史消息长度。大模型的上下文窗口是有限的，你不可能每轮对话都把全部历史一股脑塞进去。业界通常的做法是“滑动窗口”，只保留最近的N轮对话，超出部分丢弃或做摘要压缩。更进阶的玩法是“分层记忆”，把短期对话（最近一两轮）和长期用户画像（比如用户偏好、国籍、项目背景）分开存储，在构造Prompt时才动态拼接。如果你没有做过这一步，那么对话超过一定轮数之后，模型回答质量会急剧下降，而且Token费用会肉眼可见地涨，这就是“上下文失控”问题。

设计这个链路的时候，我还有一个习惯，就是把“日志记录”和“业务请求”做成异步解耦。用户点发送到看到回复之间，不应该有任何写库操作阻塞主链路。消息记录先扔进消息队列（或者利用Spring的@Async），再异步落库，这样即使日志写入出现波动，也不会拖慢用户对话的返回速度。你如果用过若依的定时任务组件，可以顺带把每天的Token消耗统计和消息量统计做成一个定时任务，每天跑一次，运维成本极低。

3.2 会话上下文管理的三种主流方案

关于会话上下文，我问卷过不少同行，落到实现层面上，其实主流方案就三种。

第一种方案是“前端全量携带”：前端把整段对话历史放在浏览器内存里，每次请求都带上完整的对话历史，后端完全无状态。优点是不占服务端存储，实现极简；缺点是每轮请求的Token开销随轮数线性增长，而且刷新页面上下文就丢了，体验比较初级。

第二种方案是“服务端Redis集中管理”：若依系统（或独立AI服务）在Redis中维护每个会话的消息列表，以ai:session:{sessionId}作为Key，每次收到新消息时，先从Redis取历史，再追加本轮提问，组装后发给模型，最后把模型回复也写入Redis。好处是前端可以随时刷新页面而对话不丢，多个端（比如管理后台和用户端）可以共享同一份上下文；坏处是要考虑Redis的过期策略，而且消息量大的时候，单个Key对应的Value会变得特别长，需要做截断或压缩。

第三种方案是“向量数据库记忆增强”：在处理长对话或文档问答场景时，把历史消息向量化存入向量库（比如Milvus或Elasticsearch的向量插件），每次问答前先做相似度召回，只把最相关的历史片段拼进Prompt。这是我做企业级知识库问答的首选方案，它能真正解决长期记忆问题，而不是靠滑动窗口粗暴截断。代价是架构复杂度明显提升，需要额外维护Embedding模型和向量库。

三种方案的适用性我做过很清晰的分类：内部小工具用第一种就够了，正式业务系统至少要上第二种，而凡是涉及知识库问答、AI辅助撰写长文档的，建议直接考虑第三种。我的项目中通常采取第二种+第三种混合，短期会话用Redis，长期知识沉淀用向量库，各管各的。

3.3 Token算力经济学：别再对账单一无所知

很多团队上了AI功能才发现，最大的坑不是技术而是账单。因此我强烈建议所有接入AI的系统，都必须提前做好Token计量和配额控制。这里有两个关键概念需要先弄明白：Prompt Tokens和Completion Tokens。前者是你发出去的所有请求文本折算的Token数，包括系统提示词、历史消息、用户输入，后者是模型生成回复折算的Token数，两者通常分开计费，生成侧一般更贵。

在实际操作中，我一般会在若依的数据字典里维护一份“模型计费配置表”，记录每百万Token的价格，同时在代码里埋点，把每轮请求的Token消耗数据作为一条操作日志入库。这样每天跑一次定时统计，就能精确算出每个部门、每个用户消耗了多少费用。没有这一步，你上线一个AI助手，月底账单来了才傻眼。

另外一个经验是控制Prompt膨胀。曾经我在给一个客户调一个文档总结AI时，发现他的API账单高得离谱。排查下来，原来他把数据库里存储的“历史关联文档”全部塞进了每次请求的Prompt里，几千字无脑追加。后来我改成了“先检索再拼装”的策略，用一个Embedding模型先对海量文档做语义检索，只挑出最相关的三至五段文本放进Prompt，Token消耗直接下降80%，回答质量反而因为上下文更聚焦而提升了。这就是典型的“Token经济学”思维。

4. 实操层配置：账号体系打通、密钥治理与Druid加密实战

原理讲得再多，落地遇到配置问题一样会卡住半天。这一章我结合自己的真实操作，把若依整合AI过程中最容易踩的配置坑全部捋一遍。尤其是数据库密码加密、账号体系打通、以及前端Vue3项目接入AI时的注意点。

4.1 若依账号体系与AI服务的无缝集成

若依的登录状态通过Token机制承载，前端每次请求在请求头中携带Authorization: Bearer {token}。当AI功能被独立成服务时，需要确保这个Token能被AI服务识别。常用做法有两种：一种是由若依后端解析Token后，把用户信息（userId、userName、角色）注入请求头后再转发给AI服务；另一种是AI服务调用若依提供的开放式认证接口（例如自建一个/auth/checkToken接口）来校验Token有效性。

我的建议是采用第一种，因为它的效率更高。若依内部已经完成了登录校验，AI服务无需再向若依发起一次鉴权调用，只需信任来自网关的内部请求头即可。但在微服务环境中，要务必注意：外部用户永远不能直接访问AI服务，请求必须经过若依网关或主应用转发，否则身份伪造风险非常高。你可以在AI服务的Nginx层加一条规则，只允许来自内网IP的反向代理访问，此为最基本的安全红线。

4.2 使用若依对配置文件进行脱敏处理

若依的体系里经常会使用Druid作为数据库连接池，而很多人的项目里有这么一个坏习惯：把数据库密码明文写在application.yml里。这在整合AI后风险更大，因为AI模块往往需要读取更多配置项，比如API Key、模型Endpoint等敏感信息，配置文件一旦泄露，核心机密也随之打包送走。

实际上若依提供的Druid配置本身就支持数据库密码的加密存储，原理是使用Druid内置的ConfigTools工具生成一对公私钥，把原密码用公钥加密得到密文，配置数据源时再把密文写入application.yml，同时配上connection-properties和filters参数，这样Druid启动时会自动用私钥解密。手动执行一次工具类，大概的命令是这样的：

java -cp druid-1.2.20.jar com.alibaba.druid.filter.config.ConfigTools your_password

执行后会输出三个关键值：privateKey、publicKey与password，你在application.yml中配置数据源时，改为使用password输出的那串密文，同时打开filters: config，并在connection-properties中填入config.decrypt=true;config.decrypt.key=你的公钥。重启服务，若依就能正常连接数据库，而配置文件里再也看不到真实密码的明文。

在AI场景中，大模型API Key一样不能写成明文字符串。我个人的习惯是把所有AI相关的密钥和Endpoint统一放到Nacos配置中心（微服务版）或者若依的配置文件中，再通过@ConfigurationProperties注入到一个专门的AiProperties类中，应用内所有组件只通过这个Bean读取配置。如果项目条件不允许上配置中心，最低限度也应该将密钥放到环境变量或者独立的配置文件里，并在.gitignore中排除掉，防止提交到代码仓库后变成“开源漏洞”。

4.3 Vue3 TypeScript项目连AI接口的典型报错

网上关于“若依Vue3 TS报错”的提问很多，我在集成AI聊天页面时就遇到过一个非常典型的问题：明明接口请求成功，前端却一直拿不到返回的数据流，控制台报出跨域或类型不匹配错误。原因通常出在两个点：

第一，若依项目自带的前端代理配置在Vue3版本里位于vite.config.ts的server.proxy中。AI接口如果不是挂在同一个域名下，必须把代理规则加上，比如把所有/ai-api前缀的请求代理到后端AI网关地址，否则就会出现前端直连导致的跨域问题。

第二，TypeScript在接收到SSE流式响应时，默认的axios并不能直接处理文本流，需要使用EventSource或fetch的ReadableStream。如果你非要用axios去接收SSE，很容易因为响应类型被解析成JSON而报错。我的做法是封装一个独立的流式请求函数，基于fetch来实现，把response.body.getReader()读到的数据块逐段推给回调函数，再在页面上做逐字渲染。这样做既绕开了TS的类型坑，也保证了渲染的“打字机”效果。

以下是一个极简的流式请求函数骨架，我用在实际项目里稳定跑了好几个月：

async function streamChat(url: string, body: object, onChunk: (text: string) => void) { const response = await fetch(url, { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify(body) }) const reader = response.body.getReader() const decoder = new TextDecoder('utf-8') let buffer = '' while (true) { const { done, value } = await reader.read() if (done) break buffer += decoder.decode(value, { stream: true }) const lines = buffer.split('\n') buffer = lines.pop() || '' for (const line of lines) { if (line.startsWith('data:')) { const payload = line.slice(5).trim() if (payload === '[DONE]') continue try { const json = JSON.parse(payload) onChunk(json.choices?.[0]?.delta?.content || '') } catch { /* 忽略格式异常的片段 */ } } } } }

这个函数虽然简单，但它保证了三个特性：第一，支持服务端流式推送；第二，逐片段解析JSON不会因为半包数据导致解析崩溃；第三，将UI更新完全隔离到回调里，前端组件只需要负责把onChunk拿到的文本追加到对话框即可。实测在若依Vue3项目中接OpenAI兼容协议或是通义千问的流式接口，都非常顺畅。

4.4 “若依验证码不出现”这类经典环境问题

有人可能觉得验证码和AI整合没什么关系，但在实际项目里，如果AI模块部署到了一台新的服务器或者Docker容器，经常会出现“若依验证码不出现”这类问题。原因是若依的验证码依赖Redis存储，生成时把验证码写入Redis并返回Base64图片，前端提交登录时再从Redis读取校验。假如Redis连接超时或序列化配置不对，验证码生成接口就会静默失败，页面自然是一片空白。

排查方法其实很朴实：先看后端日志里有没有Redis连接异常，再看Redis中是否能查询到对应的key。很多情况下，问题出在spring.redis.host配置指向了本机而非实际Redis地址，或者是Docker容器内没有暴露端口导致连接被拒。学会了这一类环境排查思路，对后续AI服务的部署也同样适用，因为AI服务的会话管理也依赖于Redis，不同的只是key的前缀和业务含义。

5. 陷阱排查：模型超时、对话串号、乱码与“AI不说话”

整合到约80%进度的时候，往往才是真正考验人的时刻。下面我把实际项目中遇到过的高频故障整理成速查表，给出对应思路，然后再抽三个典型案例详细展开。

5.1 模型超时——表象在模型，根源在架构

第一个典型案例是模型超时。我们早期做AI辅助专利撰写工具时，调用一个大模型做长文本生成，经常出现请求超过60秒才返回的情况。若依的默认网关超时设置通常是几十秒级别，结果前端早就报了“请求失败”，后端模型还在吭哧吭哧生成，两边对不上账。

后来我做了三处调整：第一，把AI相关的网络调用统一设置HTTP连接超时和读超时，一般给到120秒，避免过早掐断生成长任务；第二，接入流式响应，让模型生成多少就推多少，前端感受到的“首字延迟”大幅缩短，感知速度会快得多；第三，后台启用一个独立的任务状态表，模型调用过程写入状态（处理中/成功/失败），前端轮询状态而不是干等HTTP结果。这套组合拳下来，超时投诉几乎清零。

5.2 对话串号——一次会议系统事故的复盘

第二个典型案例是对话串号。有一次我给客户上线一个“AI会议助手”，测试时发现A用户提问，回复内容里居然夹杂着B用户的历史对话。查了半天，原因让人啼笑皆非：我在拼接会话Key时，用的是前端传来的一段会话标识，但这段标识长度太短，多个用户并发时产生了重复的UUID碰撞。修复方案是把会话ID的生成规则改成“用户ID + 下划线 + UUID”，同时在Redis里以用户ID作为key的命名空间，确保不同用户的数据物理隔离。这条经验现在已经被我固化到了所有项目的AI模块代码里。

这里我们要拆一个更深层的原理：在微服务多实例环境下，如果不用集中式缓存，而是把会话数据放在应用本地内存，用户在多个实例间负载均衡时，每一跳都可能丢失上下文，表现就是“上一句还记得，下一句就忘了”。所以只要牵扯到会话，Redis这个中心化存储的地位没法动摇。

5.3 接口返回乱码与“AI不说话”

第三个案例是乱码和空回复。乱码大多数是编码声明问题，解决方案清晰，不再赘述。更诡异的是“AI不说话”：接口返回200，但response.data里空空如也，前端什么也渲染不出来。

我遇到的一次原因是，模型返回的内容被服务端强制走了内容审核过滤，命中了一些敏感词，返回结果被置空。这类问题没有通用解，只能逐类排查：先绕过前端直连后端接口，看原始返回是否为空；再检查网关是否对响应做了特殊处理；最后检查模型参数（比如max_tokens设置太小导致生成中断）。我习惯在对接阶段就写一个“接口自检工具”页面，直接把原始请求和原始响应打印出来，省去一层一层猜谜的时间。

6. 工作流化与AI Agent：从问答工具到主动服务的跃迁

如果说上面讲的都是“单次问答”的设计，那AI Agent和工作流就是把单点能力织成一张网。这也是“若依整合AI”系列能拔高的方向。顺带回应一下那些“教别人用AI赚翻了”之类的说法——真正能产生价值的AI功能，一定是嵌入了业务流程，而不是单纯挂个聊天框。

6.1 使用若依的定时任务与消息队列构建AI工作流

若依本身带了@Scheduled定时任务的支持，可以非常方便地实现AI工作流的“定时触发”。举个例子：每天早上8点，系统自动拉取前一天各渠道的用户反馈数据，调用大模型做情绪分析和主题聚类，生成一份摘要报告，推送给运营人员的企业微信或钉钉群。整个过程分为数据准备、模型调用、结果落库、消息通知几个环节，每个环节都可以视作工作流的一个节点。

如果流程中有异步耗时的步骤，比如生成一份长报表，建议在若依中集成消息队列（如RocketMQ或RabbitMQ），把“任务提交”和“任务执行”解耦。用户提交数据后立刻得到“任务已受理”的响应，后端的AI处理任务投递到队列，由独立消费者逐条处理。这样既能保护主服务，又方便做失败重试，是目前企业级AI落地的标配思路。

6.2 借助开源工作流引擎扩展AI编排

搜索热词中出现了warm-flow，这是一个国内开源的工作流引擎，正好可以和若依集成，让AI模块的处理流程走向可视化。我研究过它的设计，它最大的特点在于“零侵入”：可以独立于业务系统启动，数据库表结构做到平台无关，不同业务域通过“流程Key”做隔离。如果你想在若依里做“AI审批助手”——比如用户发起一项申请，AI根据条件做预审打分，再流转到人工审批——结合warm-flow这类引擎，可以省掉大量状态机的编码工作。

具体到实现原理，其实不复杂：AI写好的判断结果可以作为流程节点中的一个“任务处理器”，将输出写入流程变量，工作流引擎根据变量的条件表达式决定下一步走向“通过”“转人工”或者“拒绝”。整个流程可以在前端通过可视化拖拽来维护，非常直观。这也是后续将AI的能力融入“业务审批、工单流、内容审核”这类场景的主要方式，比单纯做一个聊天机器人要高级得多，价值也厚实得多。

6.3 动手设计一个“专利相关AI辅助工具”的多Agent协作场景

热词里连续出现“专利相关辅助链接AI辅助”，我就拿这个场景来演示一下多Agent协作。专利文档的撰写是一个典型的“高门槛、强流程、长文本”任务，很适合拆成多个AI角色协同工作：

• 检索Agent：负责在已有专利库或公开文献中检索对比文件，输出的是一组相关专利列表和相似度打分。
• 撰写Agent：基于用户输入的技术方案描述，生成专利交底书的初稿，包括背景技术、发明内容、实施例等章节。
• 审查Agent：对生成文本做可读性检查和逻辑一致性校验，标记出缺少前序引用的段落。
• 润色Agent：针对语言表达做优化，使措辞更严谨，符合专利文书的语体风格。

这些Agent之间如何协作？我的做法是定义一套标准的工作产物中转结构：检索Agent产出“检索报告JSON”，撰写Agent读取这份JSON作为输入，审查Agent把修改建议写回到一个“批注数组”，最后由润色Agent消费批注并输出终稿。每个Agent都是一个独立的大模型调用单元，彼此之间通过若依的数据表或Redis来传递中间结果，整条流水线由工作流引擎编排。

这套架构的要害在于“Agent之间的依赖不能成环”。一旦两个Agent互相等待对方的输出，就死锁了。所以设计阶段一定要把流程画成“有向无环图”，每个节点只依赖上游节点，绝无回头依赖。这是我踩过最深的一个坑，写完那版代码后，我连着两天都在清理线程卡死问题，最后硬是通过引入“超时熔断”和“手动状态重置”才稳定下来。

7. 性能、安全与后端扩展：AI落地后的长期主义

功能正常跑通只是起点，真正考验系统的是高并发下的稳定性、数据安全，以及后续业务扩展的灵活性。这一章我想聊一些长期主义视角的优化手段，它们不一定在Demo阶段用得上，但上线后几乎都会遇到。

7.1 缓存与限流：别让你的AI接口裸奔

任何对外服务的AI接口都必须有完整的缓存和限流策略。先讲缓存：对于同一问题（内容完全相同的前提下），如果答案不要求实时性，可以直接用若依的Redis缓存命中结果，大幅降低Token消耗。我用一个非常简单的“问题MD5取前16位 + 前缀”作为Key，设置一小时的过期时间，实测命中率能达到30%~40%，对成本控制帮助明显。

限流则建议在网关层做。独立AI服务的接口用Sentinel做流量控制，按用户ID维度限流（比如每用户每分钟10次），防止个别激进用户刷爆模型配额。在RuoYi-Cloud的网关模块里启用Sentinel也和Nacos配合得非常自然，规则可以动态下发，不需要重启服务。

这里额外补一个“日志查询”的经验：AI请求日志要单独建一张表，和普通业务操作日志区分开，因为AI日志的读取频率更高，字段结构也不同。每个表至少包含：用户ID、会话ID、模型名称、Prompt Tokens、Completion Tokens、总耗时、错误信息。有了这张表，出现问题时就能快速定位，而不是像无头苍蝇一样翻tomcat日志。

7.2 用Sentinel与线程池隔离护栏挡住AI风暴

流量防护除了限流，还必须做线程池隔离。在嵌入式方案中，AI请求和普通业务请求共享Tomcat线程池，高并发时AI的长耗时请求可能把线程池占满。我的标准做法是：给AI调用单独设置一个线程池，最大线程数控制在10~20，队列长度按机器配置设定，同时用Semaphore做信号量控制并发调用总量，超出之后直接返回“系统繁忙，请稍后再试”，保护核心业务不被拖死。这也是从“若依微服务Plus”架构中常用的隔离思路借鉴过来的，即便你用的是单体版，也要在代码层实现同样的护栏。

7.3 打造自己的“AI网关”实现多模型路由

最后一个高阶玩法，是在若依系统上自己封装一层“AI网关”，对外提供统一的接口，对内实现多模型路由和灰度切换。比如，日常对话走通义千问，文档摘要走另一个专用模型，图像识别走自建模型服务，这个路由逻辑可以完全写在若依的配置中心里，随时切换，不改变前端任何代码。

实现上，我会在AI服务里定义一个AiRouter接口，不同模型供应商实现各自的适配器类，用责任链模式串起来。路由的选择依据可以是请求参数里的模型标识字段，也可以是后端根据任务类型自动判断的。这个玩意的价值在于：你今天接入通义千问，明天要换成其它模型，只需要新增一个适配器，修改一下路由规则，根本不用改动业务代码。很多市面上高价的AI中间件，核心原理也不过如此。

AI技术迭代很快，但工程化的底座思维不会过时。我在做这一系列“若依整合AI”的过程中，最大的体会是：先吃透平台本身的架构设计，再决定AI以何种身份接入，最后用工程化的手段去维护整个链路的稳定。如果你正打算把AI能力嵌进若依系统，我建议你先别急着写代码，花一个下午把项目里的Redis、线程池、权限配置、日志规范全部捋一遍——这些基础能力的健康度，往往决定AI功能上线后是添彩还是添乱。希望这篇原理篇，能帮你少走几段我走过的弯路。