如何做到意图识别？memory与多agent系统和意图识别的关系有哪些，和搜推的关系是什么。进行详细讲述，调用joye的blog以及可能的相关信息提供信息来源。

这个题问得很深，正好是「意图识别 + 记忆 + 多 agent + 搜推」一整串概念的关系网，我按三块给你讲透，信息来源标在最后。 一、意图识别怎么做到：不是一种方法，是分层的 工程上没有"一种"意图识别，实际是分层的金字塔： 第一层，规则与关键词。精确匹配、正则、关键词表，拦截高频确定性意图（命令式请求）。零延迟零成本、可解释，还能当兜底，但覆盖不了自然语言的变体表达。 第二层，分类模型。训练或微调一个轻量意图分类器，把输入分到预定义意图类别，输出带置信度。Joye 在多 Agent 面试里反复强调一个点：意图识别这种简单分类任务要用小模型、便宜模型（例子是 Qwen3-7B），延迟低、任务简单，不需要上旗舰；复杂推理才用大模型，长摘要用长上下文模型。这就是"按职责分级选型"的成本控制思路，是他的博客里很典型的考点（来源见后）。 第三层，LLM 直接判。让模型用结构化输出或 function calling 直接吐意图，灵活、能覆盖开放意图和边角情况，但贵、有延迟，还会幻觉。 第四层，混合路由。规则先拦高频 → 分类器给置信度 → 低于阈值或边界 case 走 LLM 或专门兜底。他博客里那个"意图识别 90.6% 准确率"的项目就是这套：200 个标注问题、覆盖 5 类常见意图 + 3 类边界情况 + 2 类对抗样本，识别不出来走 Text2SQL 兜底。真正值钱的是后面的 eval 体系和 fallback，而不是裸报一个准确率数字——没有 eval 体系的 agent 项目就是耍流氓，这是原话。 关键认知：意图识别是 router 的入口，路由错了后面全错。博客原话"路由本身可能错（意图识别错了一切都错）"，所以边界 case 处理、置信度阈值、兜底设计，比识别算法本身更值钱。 二、和 memory、多 agent 的关系：三者互相喂 1. Memory 帮意图识别消歧。意图识别不能只盯着当前一句话。省略、指代（"它""那个""刚才说的"）、跨会话的话题延续，都得靠短期会话记忆和长期记忆提供上下文。没有记忆的意图识别，遇到省略和指代基本瞎判。 2. 意图识别反过来决定 memory 怎么读。记忆不是每次都全量塞进上下文。读取策略的核心问题是：每次对话都检索一次，还是特定意图下才检索？这本身就是一个路由决策——触发到需要历史背景的意图（回忆、追问、跨会话任务）才去检索长期记忆，其余请求不带记忆，省 token 又降噪。 3. Memory 写什么，本身是个意图/价值判断。什么该记什么不该记？"今天想吃辣"是短期偏好，不该进长期记忆；"我对花生过敏"是长期事实，必须记。写入判断通常交给专门的 Memory Agent，按事实型/推导型/偏好型分类，标注置信度和时效性，还要做矛盾检测（用户说过爱吃辣又说不能吃辣，靠时间戳加上下文处理）。本质上"这条信息值不值得写"也是一种分类决策。 4. Memory 是多 agent 的粘合剂。多 agent 的优势是上下文隔离——每个 sub-agent 只看自己任务相关的上下文；代价恰恰也是隔离：sub-agent 没有全局视野。所以 agent 间通信的几种主流方式里，"共享中间文档"就是靠一个公共的记忆载体，让各 agent 把想法写进去、互相读。主从式里主 agent 判断调哪个 sub-agent，这个判断 = 意图识别 + 从记忆里拿到的全局上下文。而 memory 三层（working/short-term/long-term）正好对应：哪些记忆留在当前任务上下文、哪些留在会话内、哪些跨会话共享。 补一刀：意图识别驱动的 router 编排不等于多 agent。固定 router 分发、agent 之间没有通信的，叫 workflow，不叫 multi-agent——Anthropic 那篇 Building Effective Agents 之后这个词的边界基本定型了，面试里别把 workflow 硬说成多 agent，会被追问到死。 三、和搜推的关系：共享同一副"召回-排序"骨架 搜推的本质：给一个 query 或用户状态，从候选池里召回相关内容，再按相关性排序。这条骨架在 agent 系统里到处都是： 1. 意图识别是搜推的上游分流。搜索前先判意图类型（导航型/信息型/交易型），决定走哪套检索策略。Agent 的 web search 也一样：query 是模型生成的，检索前可以做改写、扩展来对齐意图，这就是 RAG 里的 query 优化。 2. RAG 和记忆检索直接借了搜推的召回-重排架构。RAG 三步：向量化 → 存向量库 → 召回，召回后还能加 rerank；评估指标也直接沿用信息检索那一套——召回率（100 个正确答案你召回了几个）和排序质量，而不是只看准确率。检索通道也不是只有向量：关键词、SQL、知识图谱、混合检索都行。 3. 意图识别决定走哪条召回通道，对应搜推里"选召回源/粗排"的角色。这个 query 走向量、走关键词（FTS5）还是直接结构化查询，本质是意图加路由的决策。Joye 笔记里有个"非对称成本结构"的思路很典型：FTS5 召回便宜，就敢拉宽召回口径（甚至 OR 扩展 query），反正后面 LLM 会自己过滤；如果召回贵（比如每次算 embedding），就得收窄口径，而收窄恰恰是漏召回的根源。这就是搜推里"召回率 vs 精度"权衡在 agent 记忆检索上的翻版。 4. 反向看，记忆检索本身就是一个"推荐问题"：从记忆库里把当前最该用的记忆"推荐"进上下文，用的也是向量相似度/关键词/图检索那套，读取策略还分按需触发和每次都检索。 一句话总结：意图识别决定往哪走，memory 决定带着什么走，多 agent 决定谁去走，搜推提供"怎么从大池子里捞相关东西"的底层骨架——四者共享同一个思想：分类/路由 + 检索 + 上下文装配。 信息来源： - Joye 博客《多 Agent 模拟面试》：2.2 模型按职责分级选型、2.3 workflow vs 多 agent 的定义、2.4 单/多 agent 与 router 优劣（路由错一切错）、2.5 意图识别 90.6% 的 eval 体系、3.1 上下文工程分层、3.2 记忆写入（该记不该记/矛盾检测） - Joye 博客《多 Agent 模拟面试复盘》：3.6 多 vs 单 agent 的选择、3.7 编排与通信方式（主从/共享文档）、4.5 RAG 大科普（召回/rerank/评估维度） - Joye 博客《Agent 入职指南》：5.2 记忆系统三层架构与写/读/忘策略、2.4 数据层（RAG/Memory 的 2026 年角色变化）、5.6 成本控制 - Joye 笔记《agent routing》：路由单位可以是 agent/tool/workflow/human - 业界参考：Anthropic《Building Effective Agents》（workflow 与 agent 的区分）