智能体多轮意图识别与人机交互的思考总结

前记：之前有针对意图识别的路由决策，微调训练了公司内部7B的小模型，虽然只有几百条的数据集，根据常见的单轮问答的意图识别准确率也能在90%以上，但是多轮复杂的意图识别质量就不太好。

另外，笔者所在的运维领域，如果涉及到让智能体执行生产环境的变更动作，就一定需要人工审批或确认，不论是主动交互还是被动询问，肯定会用到智能体的人机交互功能。

基于如上背景，这两块内容都是属于智能体多轮会话相关，所以本周去研究了解了下这两块内容，基于笔者践行的费曼学习法，需要把学习内容做一个总结输出，如果总结不对的地方，还请各位大佬批评指正。

一、智能体问答多轮对话的意图识别及路由转发

用大模型做了深度调研，总结了当前企业级智能客服系统形成的四层标准架构：感知层（多渠道接入 + ASR）、理解层（意图识别 + 情感分析 + 多轮管理）、决策层（RAG + 规则引擎 + 工作流编排）、执行层（回复生成 + API 调用 + 转人工路由）。

如果要从系统设计的角度理解智能客服，四层架构描述的是宏观分工。但对于真正在一线处理用户问题的核心逻辑——多轮对话究竟是怎么跑起来的——需要往里再走一层，看清智能体（Agent）和大语言模型（LLM）各自扮演什么角色，以及它们如何配合。

很多人第一次接触智能客服系统，会天然地把"大模型"和"智能体"混为一谈，认为用户说了什么，大模型就直接给出答案，整个过程就是一次语言模型的推理调用。这在单轮、简单问答的场景下基本成立，但在真实的企业级场景里，这种理解会让人对系统的复杂性和设计意图产生严重低估。

更准确的理解是：大模型是能力，智能体是编排。 大模型提供语言理解和生成的原始能力，智能体则是一个有状态的、可以调用工具和管理流程的执行单元。智能体决定"什么时候用大模型、用来做什么"，大模型本身并不知道自己身处一个多轮对话系统里。

1.1 智能问答单轮对话请求的完整链路

每当用户发送一条消息，系统内部会依次经过以下几个关键步骤，如上图所示。

第一步：问题改写。 用户的原始输入往往是口语化的、有省略的、充满指代的。"那个上周买的"这几个字，孤立来看毫无意义，但系统必须能还原它的完整语义。改写模块会把当前输入和历史对话合并，输出一个结构清晰的标准化查询——比如将其还原为"上周购买的外套退货申请"。这一步通常由一个专门的 LLM 调用或规则模板完成，输出的结果才是真正进入后续处理的"问题"。

第二步：意图识别。 改写后的问题进入分类环节，系统判断用户想做什么——是查询、投诉、退货、修改订单，还是随意闲聊。这里的输出不是一个简单的标签，而是一组带有概率分布的候选结果。以"我想退那个"这句话为例，模型实际输出的可能是：

退货申请：0.61　　订单查询：0.22　　换货申请：0.11　　其他：0.06

每个数值就是该意图的置信度——本质上是分类模型对"这句话属于哪个意图"的概率估计，所有候选意图的概率之和为 1。排名第一的意图得分越高，说明模型越确定；得分越低且与第二名差距越小，说明语义越模糊，模型越"拿不准"。除了置信度，识别环节还会同步抽取关键实体（订单号、商品名、时间等），供后续执行单元使用。

系统通常会设置一个置信度阈值，比如 0.75。最高置信度超过阈值，直接进入路由；低于阈值则触发澄清追问，系统会反问用户"您是想申请退货，还是查询订单状态？"，以人工确认替代模型猜测。这条阈值线是整个系统在"果断执行"与"谨慎确认"之间的平衡点，也是实际调优中最需要结合业务场景反复校验的参数——阈值定太高，追问频率过高影响体验；定太低，错误路由的概率上升，后续执行单元拿到的是错误前提。

第三步：路由决策。 有了意图标签和置信度，路由模块决定由哪个执行单元来处理这次请求。路由的另一个重要职责是管理"等待状态"：当系统正在引导用户分步填写信息、等待补充内容时，下一条用户消息不应该重新走完整的意图识别流程，而是直接被送回等待中的 Agent 继续处理。这个机制让对话能够自然地分步推进，而不是每轮都从零开始。路由决策的具体实现方式，后文会专门展开。

第四步：子 Agent 执行。 被路由到的子 Agent 才是真正处理业务逻辑的地方。以 RAG 问答 Agent 为例，它会先从知识库中检索相关内容，再将检索结果和问题一起送入 LLM，由模型生成最终回复。任务型 Agent 的工作则更像一个状态机：收集必要的槽位信息（比如订单号、退货原因），等槽位填满后调用业务 API 完成实际操作，最后把结果包装成自然语言回复给用户。

第五步：上下文更新。 每一轮对话结束后，系统会把本次的意图、实体、已完成的操作状态写回会话存储。下一轮开始时，这个状态包会被注入到问题改写模块和意图识别模块，形成"滚动记忆"。多轮对话之所以能记住上文，核心机制正在于此——不是大模型自己有记忆，而是系统在每次调用前主动把历史塞进 prompt 里。

1.2 大模型真正在做什么

理解了上述流程，LLM 在其中的定位就会变得清晰很多。它并不是一个全能的决策者，而是被精确调用的语言处理工具，在不同位置承担不同的具体任务：在改写环节负责消歧义，在意图识别环节负责分类和实体抽取，在生成环节负责把结构化的检索结果转化成流畅的自然语言。每一次调用都是独立的、无状态的推理，LLM 自身并不维护任何跨轮次的信息。

这也解释了为什么简单地把大模型接口接进来，并不等于拥有了一个智能客服系统。系统的"智能"很大程度上来自外围的工程设计：如何管理上下文、如何设计意图体系、如何处理低置信度的边界情况、如何在任务中途平滑地转接人工——这些都是 Agent 层面需要解决的问题，大模型本身无法开箱即用地处理。

1.3 意图识别的策略选择

意图识别并非每轮都做同样的事。一个容易忽略的设计问题是：多轮对话里，意图识别需要在每一轮重新执行吗？

答案是不一定，关键在于区分两类不同生命周期的意图。会话级意图是用户进入对话时确立的大方向，在整个会话过程中保持有效，比如"我要退货"这个诉求会贯穿整个退货流程；轮次级意图则是每一轮可能发生变化的具体动作，比如在退货流程中用户某一轮突然追问"那换货可以吗"，这就是一次轮次级的意图切换信号。

在任务型问答场景里，更合理的做法是首轮完整识别、后续轮次跟踪判断，而不是每轮都跑一次完整的意图分类。具体来说，系统在每轮对话开始时首先检查当前是否存在活跃意图：若不存在，走完整的意图识别流程；若存在，则只需用一个轻量分类器判断当前输入属于哪种信号——是对当前意图的追问或补充（延续），还是明显的话题跳转（切换），或者是感谢、告别、"好的明白了"之类的结束信号。只有在检测到切换信号时，才重新触发完整的意图识别。

这种设计的好处显而易见：延续状态下的判断非常轻量，可以用关键词规则或极简的三分类模型完成，整体延迟极低；同时，由于不是每轮都重新识别，对话上下文的连贯性也得到了更好的保障。当然，无论选择哪种策略，都有一个共同的前提：意图识别模型的输入必须包含近几轮的对话历史，而不只是当前这一句。"那它的价格呢"这类高度依赖上文的表达，如果只看当前输入，模型几乎无法正确分类；把最近两到三轮的对话拼接进输入，才能让模型感知到完整的语境。

1.4 路由决策：从规则到模型的演进

路由决策在整个链路中看似只是"转发"，实则是系统智能化程度的重要体现。它的实现方式经历了一条清晰的演进路径，也折射出不同阶段对准确性、灵活性和维护成本的不同取舍。

纯规则阶段。 最早期的路由几乎全靠 if-else 和关键词匹配——意图标签等于"退货"就走退货流程，等于"投诉"就转人工。规则简单直接，但扩展性差：意图体系一旦增长到几十上百个，规则之间的优先级冲突、遗漏覆盖、边界模糊就会变成持续的维护负担。更根本的问题是，规则只能处理被显式写出来的情况，对"不在预期内"的输入几乎没有任何泛化能力。

引入置信度阈值。 随着意图识别模块引入分类模型，路由开始能拿到置信度分数，从而有了第一层弹性：高置信度走快速规则路径，低置信度触发澄清追问或降级兜底。但意图到执行单元的映射本身，仍然是硬编码的对应关系，不具备从数据中学习的能力。

微调小模型承担路由映射。 这是当前正在被广泛采用的方向。核心思路是：把"意图 → 执行单元"的映射本身训练成一个轻量级分类模型，而不是写成静态规则表。

具体做法通常如下：以历史对话日志为基础，标注每条意图在实际业务中应该走哪条路径，构建训练数据集；选用 BERT、RoBERTa 或更小的 MobileBERT 等预训练模型作为基座，在标注数据上进行微调。模型的输入是意图标签、关键实体、置信度分数、当前轮次等特征的组合，输出是目标执行单元及其概率分布。训练出来的路由模型参数量通常只有百万级，推理延迟极低，但对复合意图、模糊边界、意图组合等情况的处理能力远超静态规则。

这种方案的另一个优势在于可持续迭代。当业务新增一类意图、或者某条路由路径的转化效果变差时，只需要补充标注数据重新微调，而不是梳理和修改复杂的规则逻辑。线上的错误路由日志本身就是天然的负样本来源，可以持续反哺模型训练，形成改进闭环。

三种方式的实际分工。 在成熟系统里，规则、置信度阈值和路由小模型通常并存，各自覆盖不同的决策范围：对于极高频、边界极清晰的意图（如"查订单""查余额"），规则路径仍然是首选，稳定可控；对于意图分布复杂、业务逻辑有一定模糊性的中间地带，路由小模型的判断作为主要参考；对于置信度极低、意图无法识别的兜底情况，转人工或澄清追问是最后一道保障。三层机制形成梯度，既保留了规则的可控性，又引入了模型的泛化能力，同时避免了完全依赖大模型带来的高延迟和不可控风险。

小结

多轮对话的挑战，本质上是一个状态管理问题，而不仅仅是语言理解问题。意图不需要每轮都重新识别，但每轮都需要判断"当前意图是否仍然有效"；路由不需要全靠规则维护，但也不必把所有判断都交给大模型。清楚认识到这一点，是设计和优化智能客服系统的重要前提。"小模型承担结构化决策、大模型承担语言生成"的分工思路，也代表了当前 Agentic 系统设计中一个重要的工程共识：不是所有环节都需要最强的模型，恰当的模型用在恰当的位置，才是兼顾效果与成本的合理路径。

二、智能体的人工交互

智能体（Agent）越来越多地被放进真实的业务流程中——RCA 根因分析、运维变更、合规审批、研究调研。这些场景共同的特征是：智能体不能一杆子捅到底，必须在某些关键节点停下来，等人确认、补充或拍板。

笔者了解到有些智能体是在 prompt 里说一句"请确认是否继续"，然后等用户回复。这种做法做 demo 没问题，但工程上很脆弱：模型自己未必知道当前处于"待审批"态；用户一句模糊的"嗯可以"容易和普通聊天混在一起；中间一旦服务重启、上下文超长被截断，整条流程就断了；事后还无法审计是谁、在什么时间、确认了什么内容。

真正稳的做法，是把人工交互当作一等公民的工程问题来设计，而不是当作 prompt 工程问题。

2.1、把会话建模成有限状态机

整个 Agent 的执行流程，应该被显式地建模成一个状态机，至少包含这些状态：

• RUNNING：自动执行中
• WAITING_HUMAN：等待人工确认
• RESUMED：收到人工输入，从断点恢复
• REJECTED：人工拒绝，流程终止或回退
• TIMEOUT：超时未处理
• ESCALATED：升级给更高权限的人

关键洞察是：人工确认不是一段自然语言，而是一条结构化事件。

{
  "session_id": "rca-20260409-001",
  "node_id": "change_validation",
  "status": "WAITING_HUMAN",
  "approval_type": "confirm_change_scope",
  "question": "检测到支付服务在故障前10分钟发布，是否作为优先排查对象？",
  "options": ["确认", "拒绝", "补充说明"],
  "context": {
    "suspect_service": "payment-service",
    "change_time": "2026-04-09 10:02:13",
    "evidence_score": 0.78
  }
}

前端、ChatOps、工单系统拿到的是这条结构化的待办，而不是一段聊天文本。

2.2、中断点 + 持久化状态 + resume 事件

整体链路可以抽象成下图：

flowchart LR
    A[Agent 自动执行] --> B{遇到关键节点?}
    B -- 否 --> A
    B -- 是 --> C[触发 interrupt]
    C --> D[(持久化状态)]
    D --> E[推送待办]
    E --> F[Chat / IM / 工单 / 审批中心]
    F --> G[人工确认/拒绝/补充]
    G --> H[结构化事件]
    H --> I[读取状态 + 注入结果]
    I --> J[从断点恢复]
    J --> A

LangGraph 这类编排框架已经把这套模式做成了官方能力：节点里 interrupt() 后，图执行暂停，状态通过 checkpoint 持久化，外部输入到达后 resume 即可继续。

Temporal 等工作流引擎走的是同样思路——把长时间等待人工处理当作正常能力，而不是异常。

微软的 Semantic Kernel / Agent Framework 也把 human approval 作为正式模式来支持。

恢复时不是重新喂一遍前文让模型重跑，而是读取持久化状态、注入人工结果、从断点继续。

这是 durable execution 区别于普通"多轮对话"的本质。

2.3、区分两类人工确认

这个区分不做，流程会越来越乱。

第一类：审批型确认。 本质是"是否允许执行某动作"——重启、回滚、切流、封禁、对外通知。输入很简单（approve / reject / edit），核心诉求是权限、审计、超时、幂等。这类最适合做成工具调用前拦截：对敏感 tool call 加策略，命中后暂停等审批。

LangChain 的 HITL 中间件就是这个思路。

第二类：认知型确认。 本质是"需要人的知识来补足模型判断"——这个变更是不是预期行为？这条告警是不是已知噪音？这个依赖关系在我们行内有没有特殊逻辑？输入往往不是简单按钮，而是单选/多选 + 备注 + 证据上传 + 指定下一步分支。

2.4、Claude 在调研中的弹框确认：一个产品级范式

笔者经常使用Claude 的调研功能，当我们给一个偏宽泛的调研需求（比如"帮我研究一下 XX 行业的竞争格局"），Claude 不会闷头跑十几分钟搜索，而是先弹出一个结构化的人工交互选择卡片，让用户回答几个关键分歧点：

• 时间范围倾向哪一段？
• 重点关注哪几家公司？
• 输出偏向数据对比还是叙事分析？

用户点选项即可，不用打字。这个设计有几层好处：

1. 降低交互成本——移动端打字累，点按钮快得多。
2. 让分歧显式化——把模型自己拿不准的几个分支翻译成用户能一眼看懂的选项。
3. 避免长时任务跑偏——在花掉 5 分钟搜索预算之前，先用 30 秒确认方向。
4. 天然结构化——用户的选择是 enum，不是自由文本，下游处理无歧义。

把这个产品行为映射回上面的状态机模型：Claude 触发的就是一次 WAITING_HUMAN 中断，弹框是这次中断的 UI 渲染，用户点击产生一条结构化 resume 事件，研究流程从断点继续。它本质上就是认知型确认在消费级产品里的一种实现。

2.5、真正难的几个问题

等用户回复本身不难，难的是这几件事：

• 回复归属：一个会话挂了多个待办时，"可以"是给哪个的？必须靠 task_id 锚定，UI 上卡片化，不要全靠自由文本。
• 硬暂停：进入 WAITING_HUMAN 后调度器必须真停住，不能让模型"先猜着继续"。
• 追加而非覆盖：人工补充的信息应作为新的 evidence 追加进 state，而不是覆盖原有判断——这样回放时才能看到完整推理链。
• 超时策略：30 分钟无人响应是自动结束、降级走保守分支、还是升级给值班经理？必须事先定义。
• 审计闭环：是谁确认的、当时看到了什么上下文、批准了什么动作、为什么这么决定——全部进 decision_log。运维和合规场景里，这一项不是加分项，是合规底线。

小结

智能体的人工交互，不是"让模型多问一句话"，而是一个完整的工作流编排问题：状态机定义清楚、关键节点显式中断、状态可持久化、恢复走结构化事件、决策全程可审计。

Claude 调研时的弹框确认是这个范式在消费侧的优雅落地；

在企业侧，LangGraph、Temporal、Agent Framework 提供了对应的基础设施。

把这些工程能力补齐，Agent 才能从"会聊天的玩具"变成"敢交给它做事的同事"。

三、结语

写完这两块内容，回头看其实有一条共同的暗线：大模型不是万能钥匙，工程设计才是地基。

意图识别和人机交互，这两件事拼在一起，描述的其实是同一种工程审美：把模型的不确定性，用工程的确定性兜住。

意图模糊时用置信度阈值兜住，决策风险高时用人工确认兜住，长流程容易断时用持久化状态兜住。

模型越强,这些"兜底"越容易被忽视;但恰恰是这些不显眼的工程细节,决定了一个 Agent 是停留在 demo 阶段,还是能被放进真实业务里跑起来。

回到笔者所在的运维领域,这种"敢把生产环境交给它"的信任,从来不是靠模型参数量堆出来的,而是靠一层层把不确定性变成可控性的工程努力换来的。这也是笔者继续学习和实践 Agentic 系统设计的最大动力。