一、从FAQ到Agent：架构演进的技术分水岭
传统智能客服的底层架构是"检索式问答"。用户提问后，系统在FAQ库中检索最相似的问题，返回对应的答案。检索的核心技术是向量相似度匹配和关键词权重排序。这种架构的优点是简单、可控、延迟低，但天花板很明显：只能回答知识库中已有的问题，无法处理需要多步推理或跨系统操作的场景。
Agent架构的底层逻辑从"检索答案"转变为"理解任务→规划步骤→执行操作"。用户说"我要退货"，Agent不是检索"退货政策"的FAQ条目，而是理解这是一个包含"查询订单→核实状态→生成退货单→通知物流"等多个步骤的任务，然后按顺序执行。每一步可能涉及不同的系统调用和知识检索。
两种架构的技术分水岭在于：FAQ架构的知识边界是静态的——知识库里有什么，AI就能回答什么。Agent架构的知识边界是动态的——AI可以调用API、查询数据库、生成工单，在对话过程中持续获取新信息来完成任务。这一能力的提升，直接改变了智能客服能够覆盖的业务范围。
二、Prompt编排：对话策略的结构化表达
Agent的"大脑"是Prompt——不是传统意义上的一段提示词，而是一套结构化的对话策略定义。
系统级Prompt
系统级Prompt定义了Agent的基本角色和行为边界。它不是"你是一个客服助手"这样一句话，而是一个结构化的配置集合，包含以下要素：
角色定义：Agent的身份和沟通风格。不同场景下角色定义不同——售后场景的Agent需要更耐心和共情，售前场景的Agent需要更主动和引导。
行为约束：Agent不能做什么。哪些问题必须转人工、哪些操作需要用户确认、哪些信息不能直接告知。
输出格式：Agent的回复是否需要结构化。例如查询订单时需要以"订单号+状态+预计时间"的固定格式输出。
流程级Prompt
流程级Prompt定义了Agent在特定场景下的对话路径。不同于传统对话树的"if-else"结构，Agent的流程定义更接近"目标导向"——设定一个目标（如"完成退货申请"），Agent自主规划达到目标的步骤。
流程级Prompt的核心是"步骤分解"：目标分解为子任务——身份验证→订单查询→退货条件判断→生成退货单→通知物流；每一步的操作指引——调用哪个API、查询哪个知识库、是否需用户确认；异常处理——某一步失败时是重试、转人工还是跳过。
策略级Prompt
策略级Prompt定义了Agent的决策规则——什么情况下应该追问、什么情况下应该转人工、什么情况下可以自主决策。这些规则不是硬编码的条件判断，而是通过Prompt向Agent传达的决策原则。策略级Prompt的质量直接影响Agent在实际对话中的表现——太保守会导致过度转人工，太激进会导致错误操作。
三、意图路由：从"分类"到"理解"
意图路由是Agent架构中承上启下的关键组件。它的任务不是"把用户说的话分到一个类别"，而是"理解用户想要什么，决定下一步做什么"。
意图识别的技术路线
传统客服的意图识别基于分类模型——预定义N个意图类别，模型将用户输入映射到其中一个类别。这种路线的问题在于：用户表述和预定义类别不完全匹配时，分类准确率急剧下降；无法处理复合意图——用户一句话包含多个意图（"我想查一下订单，顺便问问退货政策"）。
Agent架构的意图识别基于大模型的理解能力，不依赖预定义类别。用户说"我那个单子好像有点问题"，Agent不是匹配"订单异常"这个类别，而是理解"用户对某个订单有疑问，但不确定具体是什么问题"，然后通过追问获取更多信息。
路由策略的设计
意图识别完成后，Agent需要决定"下一步做什么"。路由策略通常包含以下选项：
直接回答：意图明确且知识库中有对应答案。
追问澄清：意图不够明确，需要更多信息才能回答。
系统查询：意图明确但答案需要从业务系统中获取。
转人工：意图超出Agent的处理范围或用户明确要求转人工。
路由策略的设计原则是"最小转人工"——只要Agent有50%以上的把握能处理，就应该尝试处理而非直接转人工。转人工的成本不仅是人工成本，还包括用户等待时间和上下文丢失的风险。
四、知识检索：从"查FAQ"到"多源信息融合"
Agent架构中的知识检索，不再是"从FAQ库里找一条最匹配的答案"，而是从多个知识源中获取信息，融合后生成回答。
知识源的类型
Agent需要访问的知识源通常包括：
FAQ知识库：结构化的问答对，覆盖高频标准问题。
产品文档：非结构化的PDF、Word文档，包含产品规格、使用说明、故障排除等深度信息。
业务系统数据：通过API查询的实时数据——订单状态、物流轨迹、客户信息。
对话历史：用户在当前会话中的历史消息，以及用户的历史服务记录。
多源融合的技术挑战
多源融合的核心挑战不是"检索"，而是"融合"——从不同知识源获取的信息可能存在冲突（如FAQ说"退货周期7天"，业务系统显示某类商品的退货周期是15天），Agent需要判断哪个信息源更权威；信息可能存在冗余（多个知识源包含同一问题的不同表述），Agent需要去重后生成简洁的回答；信息可能不完整（某个知识源缺少关键信息），Agent需要从其他知识源补充或主动追问用户。
多源融合的质量取决于两个因素：知识源的权威性标注（哪类信息优先使用哪个知识源）和信息冲突的解决策略（冲突时以哪个来源为准）。
五、对话管理：上下文保持与多轮收敛
对话管理是Agent架构中最容易被低估的组件。用户在真实对话中不会按"一问一答"的标准流程走，而是会说半截话、跳转话题、在多个问题之间来回切换。
上下文窗口的设计
Agent需要维护的上下文信息包括：当前会话中的对话历史（用户和Agent的每一轮对话）；当前任务的中间状态（正在执行哪个步骤、已获取了哪些信息）；用户画像信息（用户的身份、历史行为、偏好设置）。
上下文窗口的设计需要平衡"信息充分"和"Token成本"。保留全部对话历史信息最充分但Token消耗大、响应速度慢。通常的策略是：保留最近N轮对话的完整内容，超过N轮的内容压缩为摘要；当前任务的中间状态始终保留；用户画像信息在会话开始时加载，会话过程中不重复加载。
多轮收敛的策略
用户说"我那个单子"后，Agent需要在一轮追问内锁定具体订单。如果用户说"就是昨天那个"，Agent需要从对话历史中提取"昨天"对应的信息。如果用户说"算了，先问另一个事"，Agent需要暂停当前任务，切换到新问题，保留当前任务的中间状态，等用户回来后继续。
多轮收敛的核心不是"让AI更聪明"，而是"让对话路径更短"。每一轮追问都应该获取一个关键信息点，三轮追问后仍无法收敛的问题应该转人工，而不是继续追问。
六、工单闭环：从对话到业务操作的最后一公里
Agent架构与传统FAQ架构最大的区别，在于"能不能完成业务操作"。
工单生成的触发条件
Agent在以下条件触发工单生成：用户明确要求人工介入（"让客服联系我""安排师傅上门"）；Agent经过多轮尝试后无法解决问题；问题类型在预设的"必须转人工"列表中（如投诉、退款纠纷、紧急求助）。
工单内容的结构化
Agent自动生成的工单需要包含：用户信息（姓名、联系方式、用户ID）；问题摘要（Agent对对话内容的自动总结，而非逐字转写）；已尝试的操作（Agent已经做了哪些排查、用户已确认了哪些信息）；优先级标记（根据问题类型和用户情绪自动标记紧急程度）。
工单的结构化程度直接影响人工座席的处理效率。一个好的工单应该让座席在30秒内理解用户的核心诉求和Agent已做的处理，不需要从对话记录中逐条翻找。
工单流转与闭环
工单生成后，自动路由到对应的处理团队或服务商。处理完成后，工单状态变更信息回传至Agent，Agent在用户下次来电时可以告知处理进度。至此，从用户提问到问题解决的完整链路形成闭环。
七、架构演进的方向
从单Agent到多Agent协作
复杂客服场景正在从单Agent处理所有任务，演进为多Agent分工协作——一个入口Agent负责意图识别和路由，一个知识Agent负责知识检索和答案生成，一个操作Agent负责工单生成和系统对接。多Agent架构的优势是每个Agent的职责边界清晰，Prompt设计和优化更有针对性。
从被动应答到主动服务
Agent正在从"用户问什么答什么"的被动模式，演进为"在用户提问之前主动提供帮助"的主动模式。用户进入售后页面后，Agent根据用户最近的订单状态主动询问——"我注意到您昨天购买的XX商品已经签收，使用过程中有什么问题吗？"
从知识驱动到数据驱动
Agent的优化正在从"人工维护知识库"演进为"从对话数据中自动学习"。未被解决的问题自动标记为知识缺口，高频转人工的场景自动触发知识库补充流程。知识库的维护成本从"人工逐条配置"降低为"人工审核机器生成的候选答案"。
核心观点
智能客服Agent的技术架构，本质上是一套"理解→规划→执行→闭环"的自动化系统。Prompt编排定义了Agent的行为边界和对话策略，意图路由决定了Agent能否准确理解用户需求，知识检索决定了Agent能否获取有效信息，对话管理决定了多轮交互的流畅度，工单闭环决定了Agent能否完成从对话到业务操作的完整链路。五个组件不是独立运行的模块，而是紧密协作的流水线——任何一个环节的短板，都会影响Agent的最终表现。
