前记：此前针对意图识别的路由决策，我们基于微调技术在公司内部训练了一个7B参数的小模型。尽管训练数据集仅有几百条，但在常见单轮问答场景中，意图识别准确率可达90%以上。然而，面对多轮复杂对话时，识别质量明显下降，难以满足实际需求。
此外，在运维场景中，若需让智能体执行生产环境的变更操作，则必须引入人工审批或确认环节。无论是主动发起交互还是被动接收询问，智能体的人机交互功能都是不可或缺的组成部分。
基于上述背景，这两方面均涉及智能体的多轮会话能力。因此，本周我对这两块内容进行了深入调研与学习。依据费曼学习法的实践心得，现将学习成果总结输出。若存在不当之处，恳请各位业界专家批评指正。
一、智能体问答多轮对话的意图识别与路由转发
借助大模型进行深度调研后，我总结了当前企业级智能客服系统普遍采用的四层标准架构：感知层（多渠道接入与ASR语音识别）、理解层（意图识别、情感分析、多轮会话管理）、决策层（RAG检索增强、规则引擎、工作流编排）、执行层（回复生成、API调用、转人工路由）。
从系统设计视角理解智能客服，四层架构描绘了宏观分工。但若要真正掌握处理用户问题的核心逻辑——多轮对话究竟如何运转——必须深入一层，明确智能体（Agent）与大语言模型（LLM）各自扮演的角色及其协作机制。
许多初次接触智能客服系统的人，容易将“大模型”与“智能体”混为一谈，认为用户发言后，大模型直接生成答案，整个过程仅是单一的语言模型推理调用。这种理解在单轮简单问答场景下基本成立，但在真实企业级应用中，会严重低估系统的复杂性和设计意图。
更准确的认知是：大模型提供能力，智能体负责编排。大模型赋予语言理解与生成的原始能力，而智能体则是一个有状态、可调用工具、管理流程的执行单元。智能体决定“何时使用大模型、用来做什么”，大模型本身并不知晓自己身处多轮对话系统之中。
1.1 智能问答单轮对话请求的完整链路
每当用户发送一条消息，系统内部会依次经历以下关键步骤，如上图所示。
第一步：问题改写。用户原始输入往往口语化、存在省略和指代。“那个上周买的”孤立来看毫无意义，但系统必须能还原其完整语义。改写模块会将当前输入与历史对话合并，输出结构清晰的标准化查询——例如将其还原为“上周购买的外套退货申请”。此步骤通常由专门的LLM调用或规则模板完成，输出的结果才是后续处理的真正“问题”。
第二步：意图识别。改写后的问题进入分类环节，系统判断用户意图——是查询、投诉、退货、修改订单，还是随意闲聊。输出并非简单标签，而是一组带概率分布的候选结果。以“我想退那个”为例，模型实际输出可能为：
每个数值代表该意图的置信度——本质是分类模型对“这句话属于哪个意图”的概率估计，所有候选意图概率之和为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 --> ALangGraph这类编排框架已将该模式做成官方能力：节点内执行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不会闷头跑十几分钟搜索，而是先弹出结构化的人工交互选择卡片，让用户回答几个关键分歧点：
- 时间范围倾向哪一段？
- 重点关注哪几家公司？
- 输出偏向数据对比还是叙事分析？
用户点击选项即可，无需打字。该设计有几层好处：
- 降低交互成本——移动端打字累，点按钮快得多。
- 让分歧显式化——把模型拿不准的几个分支翻译成用户能一眼看懂的选项。
- 避免长时任务跑偏——在耗费5分钟搜索预算前，先用30秒确认方向。
- 天然结构化——用户的选择是枚举值，非自由文本，下游处理无歧义。
将此产品行为映射回上述状态机模型：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系统设计的最大动力。
