AI 模块架构演进与意图识别方案深度讨论记录

讨论时间 ：2026-02-10 13:50+ (模拟时间)
参与者 ：User (项目负责人), AI Assistant (架构顾问)
背景说明 ：

本次讨论源于用户查阅项目文档 devDoc/开发问题.md 中关于"意图判断与检索逻辑"的章节。

用户对文档中提到的基于"硬编码关键词"进行意图判断的现有实现提出了质疑，认为其灵活性不足，并希望能探讨市面上成熟产品的解决方案，以及如何利用 LLM 本身的能力来实现更智能、更自然的交互体验（即 Agentic RAG 模式）。

核心议题围绕：是否应该用 LLM 替代关键词判断、本地路由与 LLM 路由的优劣、以及如何通过 Agent 工具调用实现"懂业务逻辑但不堆砌代码"的高质量回答。
文档内容概述：
该文档详细记录了我们的五轮核心对话，逻辑清晰地梳理了从"现有关键词判断的局限性"到"Agent 工具调用 (Function Calling) 终极方案"的思维演进过程。

背景与起因：基于您对 devDoc/开发问题.md 中现有死板实现提出的质疑。
核心议题：
- 现有机制的局限与 Semantic Router/Agent 升级方向。
- 市面上成熟产品（LangChain 等）的三种主流处理方案。
- 关于"LLM 本身就会，是否画蛇添足"的深度辨析（时序悖论与成本效率）。
- Agent 模式下如何处理模糊提问（通过工具定义诱导查阅，通过 Prompt 控制输出）。
- 如何避免"废话文学"，确保 AI 能结合 SQL 和代码细节讲清深层业务逻辑。

1. 核心议题一：现有意图判断机制的局限与升级方向

1.1 用户提问

问题：参考 devDoc/开发问题.md 文档，我对目前的实现有疑问。

目前通过 shouldQueryVector 方法里的关键词（如 api, sql, 报错）来区分是否查向量库，这种方式是否太过死板？有没有办法升级让其更灵活？
对于"无检索意图"的场景，能否走 Skills 技能库来回答，而不是简单的直接问大模型？

1.2 AI 回答与分析

现状诊断 ：

目前的实现确实存在局限性。依赖 StrUtil.containsAny 匹配硬编码关键词（Hard-coded Keywords）虽然简单高效，但缺乏语义理解能力，容易出现漏判或误判。

升级建议：

引入语义路由 (Semantic Router)：
- 原理：不再匹配关键词，而是预先定义意图（如 RAG_CODE, CHAT）的例句。将用户提问向量化后，计算与例句的相似度。
- 优势：能理解"查代码"和"看看代码"是同一个意思，无需穷举所有词汇。
升级为 Agent 工具调用 (Function Calling)：
- 原理：将 Skills（技能）和 RAG（检索）封装为大模型可调用的 Tools。
- 流程：不预设判断逻辑，而是把问题直接扔给 LLM，让 LLM 决定是"查代码"、"查历史"还是"执行技能"。

2. 核心议题二：市面上成熟产品的解决方案

2.1 用户提问

问题：目前市面上（如 LangChain、企业级 RAG 应用）的产品都是怎么处理"意图识别"这种问题的？

2.2 AI 回答与分析

市面主流方案分为三个梯队：

语义路由 (Semantic Routing) ------ 性价比首选
- 机制：利用向量相似度（Embedding Similarity）在本地进行极速分类。
- 代表：LangChain EmbeddingRouterChain、Semantic Router 库。
- 特点：速度快（毫秒级）、零 Token 消耗、泛化能力强。
LLM 路由 (LLM Classifier) ------ 智能但昂贵
- 机制：调用一个小模型（如 GPT-3.5）专门做分类，Prompt 为："你是一个路由助手，请分类..."。
- 特点：理解力最强，但延迟高、成本高。
Agent 工具调用 (Function Calling) ------ 终极形态
- 机制：完全依赖大模型的决策能力，将检索视为一种"工具"。
- 特点：最灵活，支持多步决策（ReAct），是目前最先进的 Agentic RAG 模式。

3. 核心议题三：LLM 本身具备能力与"画蛇添足"的悖论

3.1 用户提问

问题：本质上来说，意图判断是 LLM 本身就会的（就像 DeepSeek）。我自己去调一次模型判断，或者本地查向量库，是不是有点多余？是不是"画蛇添足"？

3.2 AI 回答与分析

这是一个非常深刻的工程架构问题。

核心观点：

时序悖论 (Chicken-and-Egg Problem) ：

DeepSeek 虽然聪明，但它没有你的私有代码 。

如果你想让它回答代码问题，你必须在提问之前 先把代码查出来喂给它。

如果你不先做路由（判断要不要查），你就不知道该不该喂代码。
本地路由的价值：
- 省钱 & 提速：本地算向量距离只需 10ms 且免费；调一次 LLM 哪怕只是做判断，也要几百毫秒且消耗 Token。
- 分层治理：就像公司前台（路由）和 CEO（LLM）。前台能拦下来的小事（闲聊），就没必要打扰 CEO。
结论：

并不是画蛇添足，而是为了解决"LLM 不知道它不知道什么"的问题，以及出于成本效率的考量。但如果您追求架构的极致简洁和智能感，Agent (Function Calling) 确实是最符合您"不画蛇添足"直觉的方案，因为它把判断逻辑内化到了模型思维链中。

4. 核心议题四：Agent 模式下如何处理模糊提问（"看起来更聪明"）

4.1 用户提问

问题：如果采用 Agent (Function Calling) 方案，告诉 DeepSeek "手里有 search_codebase 工具"。

但很多时候用户问得比较模糊，比如"项目表查询是什么逻辑？ "。

用户没有明确说"贴代码"，也不希望看到大段代码，只希望 AI 能结合代码逻辑给出聪明的业务解释。

这种情况下，Agent 会怎么处理？是直接甩代码，还是不查？

4.2 AI 回答与分析

这涉及到 Prompt Engineering 和 工具定义 的精细化控制。

解决方案：两步走策略

诱导 AI 去查 (Tool Definition)：
- 在定义 search_codebase 工具描述时，故意扩大范围。
- Prompt 示例 ："当用户询问业务逻辑 、功能流程 或实现原理 时，必须调用此工具获取代码上下文，即使是宏观问题也需要代码佐证。"
- 效果：DeepSeek 看到"查询逻辑"四个字，虽然用户没要代码，但受描述引导，它会去查。
控制 AI 怎么说 (System Prompt)：
- 在 System Prompt 中约束 AI 的输出行为。
- Prompt 示例 ："当你阅读代码后，严禁直接粘贴大段代码。请将代码逻辑翻译为自然语言的业务规则。仅在必要时提及核心类名。"
- 效果：AI 查了代码，理解了逻辑，但忍住不贴代码，而是用"人话"讲出业务流程。

5. 核心议题五：如何避免"废话文学"，讲清深层业务逻辑

5.1 用户提问

问题：针对"项目表查询逻辑"这个例子。

如果 Controller 里写了连表过滤等业务逻辑，AI 能不能说清楚？

我不希望它回答"进入 Controller 调用 Service 最后查库"这种废话模板 。

我希望它能讲出"当条件符合 A 时，会进行 B 连表查询"这种深度的业务逻辑。Agent 方案能做到吗？

5.2 AI 回答与分析

痛点分析 ：

AI 说废话通常是因为：

没看到"肉" ：只检索到了接口定义，没看到 SQL 或实现类里的 if-else。
没被逼：Prompt 太宽泛，没要求它做"代码-业务"的翻译。

解决方案：深度检索 + 强制翻译

检索策略必须深入：
- search_codebase 工具不能只抓 Controller。
- 必须顺藤摸瓜，抓取 ServiceImpl 的具体实现逻辑。
- 最关键 ：必须抓取 Mapper.xml 里的 SQL 语句（因为连表、过滤往往写在 SQL 里）。
Prompt 强制指令：
- 明确要求 AI 识别 条件判断 (if/else) 和 数据关联 (JOIN)。
- Prompt 示例 ："如果代码中有 LEFT JOIN sys_dept，你必须解释为'查询时自动关联了部门信息'；如果代码中有权限校验，你必须解释为'普通用户只能看自己的数据'。"

最终效果：

问题："项目表查询是什么逻辑？"

AI 回答：

"项目表的查询逻辑包含以下核心业务规则：

权限隔离机制：

代码中进行了角色判断，如果是普通用户发起查询，系统会强制追加当前用户 ID 作为过滤条件，这意味着普通用户只能看到自己参与的项目，而无法查看全量数据。（管理员除外）
数据完整性关联：

在底层查询时，系统执行了连表操作。主表 sys_project 会左连接 sys_dept 部门表。这样做是为了在返回项目列表时，能直接带出项目所属的部门名称，而不仅仅是显示一个部门 ID。
默认过滤规则：

查询语句中默认包含了 del_flag = '0' 的硬性条件，这意味着所有逻辑删除（已归档或回收站）的项目，在常规列表查询中是默认不可见的。

Agent 会结合 SQL 里的 LEFT JOIN 和 Java 里的 DataScope 注解，回答出："这是一个基于参与者权限隔离 且自动关联部门信息的查询流程"，而不是废话。