说到先问一个问题，Agent 为什么需要意图识别？话说回来，

直觉上。把使用者输入直接丢给 LLM 就好了——LLM 自己会判断该怎么做。

这个思路在工具少、场景单一的时候没问题。但当 Agent 同时拥有搜索工具、代码工具、计算工具、知识库工具时问题就来了：一样的 LLM。配上不同的工具集和 system prompt，在同一个任务上的表现差距极大。按理说，

专门回答知识问答的 Agent。会用知识库工具、深入解释概念；而一个通用 Agent 面对一样的问题，可能随手搜索了一下就返回了一个搜索摘要。

意图识别层做的事是：在把请求分发给专项 Agent 之前，先判断使用者真正想要什么。这样每个专项 Agent 只需要把自己的那件事做好。

从方案对比来看。关键词匹配 vs LLM 分类

先做一个对比实验，把结论建立在数据上。

关键词匹配的问题

传统 NLP 项目常用关键词规则：

_KEYWORD_RULES = {
"search":,"code":,"calculate":,"qa":,}
def keyword_classify -> str:
scores = {k: 0 for k in _KEYWORD_RULES}
for intent。keywords in _KEYWORD_RULES.items:
for kw in keywords:
if kw in text:
scores += 1
best = max
return best if scores> 0 else "unknown"

用真实输入测一下：

△ 输入：LangChain 最近发布了什么新版本？关键词 → unknown ← 没有命中任何关键词
LLM → search
△ 输入：帮我写个冒泡排序算法 关键词 → unknown ← “写” 不在列表里
LLM → code
”
LLM → qa
输入这方面。加 乘以 等于多少 关键词 → calculate ← 命中“等于”、“加”
LLM → calculate

关键词方案的致命缺陷只有当使用者恰好使用了规则里的关键词，分类才会有结果。稍微换一种说法——"LangChain 出新版了吗"、"帮我实现一个排序"——就直接返回 unknown。话说回来，

维护这个规则表的成本也非常高：新业务场景、新使用者表达习惯。都需要手动更新规则，

LLM 分类器

换成用 LLM 来做分类，手动解析 JSON 输出：

def llm_classify -> IntentResult:
system_prompt = f"""你是意图分类器。将使用者输入分类到以下种意图之一：
search — 搜索信息、查询最新动态
code — 编写/调试/调整代码
calculate — 数学计算、数值换算
qa — 知识问答、概念解释
clarify — 输入不清晰、指代不明
至于规则，1. 如果有对话历史，“调整一下”“改一下”等指令优先结合历史上下文判断。2. 信度低于阈值时统一返回 clarify，不要猜测。请仅返回以下 JSON 格式，不要包含任何其他文字：
{{"intent": "<意图>","confidence": <0到1的数字>,"reasoning": "<一句话理由>"}}"""
response = llm.invoke,HumanMessage])
raw = response.content if isinstance else str
再看try，match = re.search
data = json.loads if match else raw)
...
except Exception:
# 降级逻辑
for candidate in :
if candidate in raw.lower:
return IntentResult(intent=candidate。confidence=0.5,reasoning="")
return IntentResult(intent="clarify",confidence=0.5,reasoning="")

LangGraph 意图路由：把请求分发给专项 Agent

意图识别出来之后怎么把请求路由给对应的专项 Agent？LangGraph 的条件边天然适合做这件事。

图结构示例

START │ ▼
│ ├─ “search” ──→ web_search 工具
│ ├─ “code” ──→ run_code 工具
│ ├─ “calculate” ──→ calculator 工具
│ ├─ “qa” ──→ knowledge_base 工具
│ └─ “clarify” ──→
│ END

代码实现片段

class RouterState:
user_input: str
conversation_history: list
intent这方面，str
confidence: float
reasoning: str
response: str
def classify_node -> dict:
result = llm_classify)
print
return {"intent": result.intent,"confidence": result.confidence。"reasoning": result.reasoning}
def route_by_intent -> str:
return state
def build_intent_router:
graph = StateGraph
graph.add_node
graph.add_node("search",_make_specialist_node("search_agent",))


... 

return graph.compile


工厂函数创建专项节点示例：


def makespecialistnode:
specialist=createreactagent(model=specialistllm,tools=tools_list)
def _node->dict:
print
result= specialist.invoke({
"messages":
})
...
return _node



路由实测结果示例


LangGraph 最近发布了什么新版本？说起来，意图=search 信度=%
→ search_agent
LangGraph 引入了 functional API。支持更灵活的 Agent 编排方式。


它解决了 LLM 的哪些问题？...


置信度阈值与澄清机制

意图分类不是非黑即白——“帮我改一下”这种输入，LLM也无法确定使用者在说什么。不猜测，而是直接问澄清才是更好的策略。

置信度阈值控制路由行为示例：




def clarify_node->dict:
resp=llm.invoke()
return {"response": resp.content.strip}


再看实测效果。


至于输入，“帮我改一下”，置信度%→clarify
从澄清回答来看，“请问您需要修改什么内容呢？” 

再看输入，“再来一个”。置信度%→clarify
至于澄清回答，“您具体想了解哪方面的信息或帮助呢？” 

至于输入，“Python 当前版本有什么新特性”，置信度%→search
直接搜索。无需澄清 


多轮对话意图跟踪：上下文让模糊指令变清晰


User Pain Point: 当对话发生多轮后同一句简短命令往往因为缺乏上下文而被误判为模糊或未知。例如“调整一下”的字面意思很宽泛。
但如果前面已经讨论过代码，那么它是对代码调整一下请求。说起来，若无上下文，该命令会被误判为 'clarify'。导致不必要的交互延迟与使用者体验下降。


场景 A 示例:

已存在代码相关对话历史：
User这方面。“帮我写一个 Python 函数，计算列表平均值”
Assistant：“def average:…”
至于User，“这个函数如果列表里有非数字怎么办？”
Assistant：“可以…”
再看User，“调整一下”
→ 分类结果为 **'case'**。成功跳转至 `case` 专项代理，而不是 `clarify`。


场景 B 示例：计数延续


从User来看，“10 的平方是多少”
Assistant:“100”
从User来看。“再乘以二”

→ 分类结果保持 'calculate'，成功延续上一轮计算，而非误判为 'clarify' 或 'search'。


html
history_section="
从最近对话历史来看。"+ "
".join)
system_prompt=f"""你是意图分类器...{history_section}"""


真实运行中的有趣发现与痛点：


User Pain Point #1: "JSON 输出格式偶尔失效": 即便模型理解了请求，也可能因格式错误导致自动降级为 'clarify',给使用者增加额外确认步骤。

User Pain Point #2: "错误路由导致功能失效": 当被错误分配到无相关工具集的代理时该代理只能凭自身语言能力完成任务。但效果往往低于预期，如 calculator agent 写出 Python 函数却无法执行真正运算或调试；这类错误虽然偶尔出现，却严重影响整体质量与信任度。

User Pain Point #3: "模型语言偏移": 在中文环境下出现英文 reasoning 或者混合语言输出。对最终展示给终端造成可读性障碍，需要额外处理或后处理过滤。怎么说呢，

<强>User Pain Point #4: "多轮历史是必不可少但难以管理": 缺少足够有效上下文时即使模型本身功能比较强也无法正确推断；过长历史又会导致推理延迟上升并占用显存。设计合适截断策略与动态上下文长度成为关键挑战之一。



#工业级落地实践建议 .



Pain Point A – 对规则驱动性能的不满足:  单一词条匹配无法覆盖所有业务场景，新业务上线时需频繁维护表格；其代价不仅仅是人工，还包括潜在误判导致客服流程停滞与客户流失。这就是为什么我们要，以获得更宽泛且可迭代的根据数据调整解法。

Pain Point B – 对小模型性能的不信任:  虽然小模型速度快。但很多团队担心其准确率不足以满足生产 SLA，而且担心因训练数据不足产生长尾误判。话说回来，通过持续收集线上 bad case 并进行增量微调。可以快速修复此类缺陷，并将准确率提高至>90%。

Pain Point C – 对大模型成本控制的不确定性.  当 SLM 无法满足需求时才使用 GPT‑4o 等大模型，可将整体成本压缩至仅占总流量 ~5%。通过 OOD 拒识层过滤掉完全超出服务范围的问题，从而进一步降低无效调用次数。
\t\t\t\t\t\t\t\t\t \t \t \t\t \t \t \t \t\r
\r
\r"
### OOD 拒识设计思路


Pain Point D – 未能及时过滤非法/无意义请求.
程序若未能及时拒绝类似“请帮我写一首诗”的请求。会浪费资源并让后端代理陷入无关工作区间，从而影响其它合法请求响应速度和质量。怎么说呢，必须引入 OOD 层。仅当相似度或 confidence 均低于阈值才允许进一步处理。
\r
title=\"\r\ta\" title=\"\r\ta\">         \r
aid=\"\"\r
aid=\"\"\r
aid=\"\"\r
aid=\"\"\r
aid=\"\"\r
aid=\"\"\r"

\u200c\u200c\u200c\u200c\u200c\u200c\u200c\u200c\u200c\u200c\u200c"
### 数据流程持续迭代


Pain Point E – 缺乏实时反馈循环.
如果没有按实际使用情况收集 bad case 并即时标注。将永远只能靠静态验证数据维持程序稳定，这对于变化很快的业务场景来说根本不可行。在我们的闭环中，每日一次从线上日志抽取负面案例。再结合点击率/转人工等信号更新训练集，实现持续迭代提高准确率。其实，
---
### 实施要点快速参考表

f...


三层漏斗关键指标汇总 & 使用者痛点映射


'Layer'
'延迟'
'成本/req'
'占比'
'典型用途'
'主要痛点'
'方法'

Rule Route 

### 小结


*Keyword rule is fragile* - high maintenance cost and low coverage.
lower Confidence threshold triggers clarification instead of wrong routing.

小结