在构建智能体或 RAG 系统时，我们经常面临一个核心挑战：用户的自然语言输入与系统的执行逻辑之间存在巨大的鸿沟。
用户说：“我电脑连不上网了。”
系统如果直接检索：“电脑连不上网”，可能会匹配到一堆无关的维修广告。
但一个成熟的 IT 支持 Agent 应该做的是：
识别意图：这是一个“故障排查”请求，不是“购买咨询”，也不是“闲聊”。
重写查询：将口语化的描述转化为技术检索词，如“网络连接失败 故障排查 步骤 Windows/Mac”。
路由分发：调用“IT 知识库检索”工具，而不是去查“员工手册”。
这就是意图路由（Routing）和查询重写（Rewriting）的价值。它们构成了 Agent 的推理层，决定了系统是“智能”还是“智障”。
本文将深入探讨这两个模块的通用设计模式、prompt 工程最佳实践，以及它们在 dify/coze 等平台中的复用逻辑。
01 意图路由
意图路由的本质是一个分类任务（Classification Task）。它的目标是根据用户的输入，将控制权分发给最合适的下游工作流或工具。
在企业级应用中，这通常对应着不同的业务部门或数据孤岛。
一个典型的企业级 agent 路由逻辑简单示例如下：
通用路由 Prompt 模板
实现高准确率路由的关键，在于 Prompt 的设计必须遵循“定义明确、边界清晰、输出结构化”的原则。
以下是一个通用路由 prompt 模板示例：# Role
你是一个智能系统的意图分类器。你的任务是接收用户输入，并将其精准分类到预定义的意图类别中。
# Intent Definitions (意图定义)
请基于以下标准进行判断：
1. **[Knowledge_Retrieval]**:
-定义：用户询问关于产品功能、公司政策、操作手册等客观事实。
-示例："如何重置密码？"、"年假有多少天？"
2. **[Data_Analysis]**:
-定义：用户需要查询具体的业务数据、报表或进行统计分析。通常包含时间、指标和聚合需求。
-示例："上个月销售额是多少？"、"统计各部门人数。"
3. **[System_Action]**:
-定义：用户请求执行某个具体操作或变更系统状态。
-示例："帮我提交这个请假条"、"预订明天的会议室。"
4. **[General_Chat]**:
-定义：问候、闲聊或不属于上述任何类别的通用问题。
# Constraints (约束)
-不要尝试回答用户的问题。
-仅输出分类标签，不要包含任何解释。
-输出格式必须为 JSON: {"category": "分类标签"}
# User Input
{{user_query}}
这种路由逻辑是通用的，比如：
在 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：# Role
你是一个搜索查询优化专家。你的目标是将用户的原始问题转化为搜索引擎或向量数据库更容易理解的查询版本。
# Instructions1.
1. **分析意图**：理解用户问题的核心需求。
2. **消除歧义**：如果问题包含模糊代词（如“它”、“那个”），请结合常识进行补全。
3. **关键词提取**：提取核心实体、动作和约束条件。
4. **多维度扩展**：生成 3 个不同角度的搜索查询，以提高召回率。
# Output Format
请直接输出一个 JSON 列表，包含优化后的查询字符串：
["查询版本1", "查询版本2", "查询版本3"]
# Examples
User: "最近那个很火的 AI 视频工具叫什么？"
Output: ["OpenAI Sora2 介绍", "AI 视频生成工具 推荐 2025", "热门 文本转视频 AI 模型"]
User: "怎么配置那个环境变量？"
Output: ["配置系统环境变量 教程", "Windows/Linux 设置环境变量 步骤", "
ython PATH 环境变量配置方法"]
# User Input
{{user_query}}
03 意图识别与元数据过滤的联动
在结构化数据查询（如商品检索、简历筛选）中，意图识别不仅仅是分类，还需要提取实体（Entity Extraction），用于构建结构化的过滤条件（Pre-filtering）。
这是连接自然语言与数据库查询（SQL/NoSQL）的关键桥梁。
场景示例：用户输入：“帮我找几个北京的、三年经验以上的 Java 工程师。”
处理流程：
LLM提取：
location: "北京"years_of_experience: { "$gte": 3 }skill: "Java"role: "Engineer"系统动作：
生成数据库查询语句（或向量库 Filter）。
执行精确检索。
无论是手写代码，还是使用dify/coze等平台，“意图路由”和“查询重写”都是构建高质量 Agent 的必修课。
意图路由解决了“去哪里”的问题，防止了通用大模型在垂直领域胡乱回答。
查询重写解决了“怎么查”的问题，弥补了人类表达与机器索引之间的差异。
在 Agent 开发中，我们将不再直接把用户输入扔给 LLM，而是会构建一个由Router（路由）、Rewriter（重写）、Extractor（提取）组成的推理前处理层。
这层“认知中间件”，才是区分一个简单的 Chatbot 和一个真正的智能业务助理的分水岭。