在构建智能体或 RAG 系统时，一个关键瓶颈始终存在：用户用自然语言表达的需求，与系统底层的执行逻辑之间，往往隔着一道难以跨越的沟壑。
当用户脱口而出："我电脑连不上网了。"
若系统仅做字面匹配，检索"电脑连不上网"，结果很可能是满屏的广告链接和非专业维修服务。
而一个真正稳健的 IT 支持 Agent，应当完成三步精准操作：
意图识别：这是一次"故障诊断"请求，而非"产品购买"或"闲谈闲聊"。
查询重写：将口语表达转化为结构化技术关键词，如"网络连接失败 故障排查 步骤 Windows/Mac"。
路由分发：定向调用"IT 知识库检索"模块，而非误触"人事制度文档"或"入职指南"。
这正是 意图路由（Routing） 与 查询重写（Rewriting） 的核心意义------它们是 Agent 的推理引擎，直接决定系统是"聪明应对"，还是"机械误判"。
本文将系统剖析这两个模块的通用架构模式、Prompt 工程的实战准则，以及它们在 dify/coze 等平台中的可复用实现路径。
01 意图路由
意图路由的核心是一个分类任务（Classification Task），其目的在于依据用户输入，将处理权限精准交由最匹配的下游工作流或工具。
在企业级场景中，这一机制通常映射至各异的业务单元或信息隔离系统。
一个典型的企业级 agent 路由逻辑的简易示例如下：
通用路由 Prompt 模板
实现高准确率路由的核心，取决于 Prompt 的设计必须严格遵循 "定义明确、边界清晰、输出结构化" 三大准则。
以下是一个通用路由 prompt 模板示例：
这种路由机制具有普适性，例如：
在 Python 中：它体现为 RouterChain 或 LLMChain 的底层逻辑。
在 dify 中：其对应功能为 "问题分类器" 节点，只需在界面中配置分类规则，系统即自动构建分流路径。
02 查询重写
用户的提问常显模糊、缺乏上下文支撑，甚至潜藏误导倾向；而查询重写（Query Rewriting）的核心使命，正是将这类"原始需求"精准重构为机器可清晰解析的"指令性表达"。
1. 常见重写策略
根据不同的应用场景，文本重写策略可归纳为以下三种类型：
同义扩展：用于缓解专有名词在检索中因表述差异导致的匹配失效。
输入："我想买个本子。"
重写："笔记本电脑 Laptop 办公电脑 价格 型号"
指代消解：用于补全多轮交互中因代词缺失而断裂的语义链。
输入："它多少钱？"（上文聊的是 iPhone 15）
重写："iPhone 15 的价格是多少？"
后退提示：用于化解查询粒度过细引发的检索失效，通过抽象化提升泛化能力。
输入："为什么我的 Python 代码报了 KeyError？"
重写："Python 中 KeyError 的常见原因及解决方法。"
2. 高级策略：HyDE (假设性文档嵌入)
在复杂知识检索场景中，仅依赖关键词重写往往效果有限。此时，可引入 HyDE（Hypothetical Document Embeddings）技术。
其核心机制是：先由 LLM 构造一个"假设性答案"，再以该答案作为查询向量，去匹配真实文档。原因在于，向量空间中，"答案"与"答案"之间的语义距离，显著小于"问题"与"答案"之间的距离。
通用重写 Prompt 模板
以下是一个集成了"多角度分解"和"关键词优化"的prompt：
03 意图识别与元数据过滤的联动
在结构化数据查询（如商品检索、简历筛选）中，意图识别的职责远不止于分类，更需精准抽取实体（Entity Extraction），以支撑结构化过滤条件（Pre-filtering）的构建。
该过程构成了自然语言与数据库查询语言（SQL/NoSQL）之间的核心映射纽带。
场景示例：用户输入："帮我找几个北京的、三年经验以上的 Java 工程师。"
处理流程：
LLM提取
location: "北京"
years_of_experience: { "$gte": 3 }
skill: "Java"
role: "Engineer"
系统动作：
构建数据库查询条件（或向量库过滤器）
启动精准匹配检索
无论是手写代码，还是依托 Dify、Coze 等平台，"意图路由"与"查询重写"始终是打造高性能 Agent 的核心技能。
意图路由 回答了 "该向何处发力" 的疑问，有效避免了通用大模型在专业场景中的盲目响应。
查询重写 则厘清了 "如何精准检索" 的路径，消解了自然语言表达与结构化索引之间的语义鸿沟。
在 Agent 的工程实践中，我们不再将原始用户输入直接喂给 LLM，而是前置一层由 Router（路由）、Rewriter（重写）、Extractor（提取）协同构成的推理预处理模块。
这一层"认知中间件"，正是划清浅层对话机器人与真正智能业务助手的终极界线。