交付上线那天晚上十一点多客户那边的值班主管给我打电话语气有点急“你们那个机器人是不是卡住了”我赶紧拉了一下会话日志发现它正卡在一个死循环里——用户问“我的订单什么时候到”它回答“正在为您查询”然后因为没有正确拿到订单号又回头问用户“请提供您的订单号”用户重复了一遍问题它又继续“正在为您查询”……循环了四轮用户早就不耐烦了。这个小插曲恰恰是客服类Agent工程实现中最核心的一个问题任务规划与执行控制远不是把模型接进去就完事那么简单。今天这篇文章我把这个已经交付的客服Agent从架构设计、任务拆解、工具调用、记忆管理到安全兜底和上线验收完整拆解一遍。适合正在做Agent应用落地、想从demo走向生产的团队参考也适合准备Agent开发相关面试的人理解工程全貌。1. 从“问答机器人”到“能办事的Agent”这个项目的起点与交付目标1.1 传统客服系统差在哪我们接手这个项目之前客户线上客服系统是一个典型的“FAQ机器人关键词匹配”方案。用户问“怎么退换货”它吐一篇《退换货政策》长文用户说“我要退款”它识别到“退款”二字给一个退款入口链接。看起来好像能用但真实用户根本不会按FAQ的剧本来提问。真实会话长这样“我前天买的那双鞋43码的想换42你们什么时候能给发过来”这里面包含了订单查询、尺码修改、发货时间查询三个意图。传统规则引擎遇到这种复合请求基本就失语了要么答非所问要么直接转人工。而那段时间客户的人工客服峰值时段排队超过二十分钟客诉率一路上涨。另外一个问题是传统方案没有“办成事”的能力。查订单、改地址、申请发票、提交售后这些操作都需要对接业务系统。老系统做得最多的是给个链接让用户自己去操作但很多用户尤其是非互联网原住民用户在跳转过程中就流失了。1.2 交付目标与验收口径客户最初的想法是“上一个能自然对话的机器人”但我们在需求调研阶段把他们拉回了地上。Agent不是来替代人工客服的全部工作的它的核心目标是分流——把标准化程度高的那部分会话消化掉让真人客服把精力留给复杂客诉。双方对齐后的验收口径有三条语义理解准确率在测试集上核心意图识别准确率不低于95%关键槽位订单号、商品、地址等抽取准确率不低于90%。任务完成率用户发起退款申请、地址修改、发票申请这三类高频任务Agent独立完成的比例不低于70%。转人工兜底Agent无法处理或用户明确要求人工时必须无感转接转接前的上下文完整带过去。这个验收口径非常重要它直接决定了后面的架构取舍。比如“任务完成率不低于70%”意味着我们必须把工具调用、状态流转做成高可靠工程而不是碰运气而“语义理解准确率不低于95%”意味着模型选型和意图分类需要多路并行兜底。2. 整体架构拆解Agent不是模型是一套分工明确的系统2.1 模块分层总览很多刚接触Agent开发的同学容易有一个误区以为Agent就是个模型把Prompt写好、模型一调就完事。实际交付过你就知道Agent在整个链路里只占一部分真正复杂的是它周围的工程系统。这个项目的整体架构分六层每一层解决一类问题层级职责关键组件入口层多渠道接入、会话管理微信、App、Web多渠道适配会话ID统一映射编排层意图识别、任务规划、状态流转NLU模块、状态机引擎、策略决策器工具层对接业务系统、执行具体操作Function Calling网关、工具注册中心记忆层上下文维护、用户画像、历史会话检索会话级记忆、向量数据库、客户档案缓存模型层自然语言生成、语义理解、逻辑推理大语言模型、意图分类小模型、安全审核模型可观测层全链路追踪、会话回放、质检Trace系统、日志平台、离线评测流水线整个架构的设计原则就一句话把容易出错的部分交给确定性逻辑把需要智能的部分交给模型。意图识别可以靠模型但“识别到退款意图后必须走哪几个状态节点”这件事必须由代码控制不能交给模型自由发挥。2.2 各层职责与关键选型入口层相对简单就是把各个渠道的消息统一转成内部消息协议再分发到编排层。这里有个容易忽略的点不同渠道的消息格式差异很大微信带类型标签、App可能有结构化卡片、Web端有会话历史同步入口层必须把这些都抹平成同一套数据结构否则下游处理逻辑会写出一堆分支判断。编排层是整个Agent的“大脑”也是这次拆解的重点我放到后面单独说。工具层是Agent的“手脚”核心是Function Calling网关负责工具注册、参数校验、权限控制和调用限流。模型层我们最终选了“大小模型混跑”的策略意图识别、情绪判别、安全审核用轻量小模型成本低延迟低会话生成、复杂推理、多轮追问用大模型保证对话质量和泛化能力。3. 任务拆解与状态流转客服场景下为什么不能全靠模型自由发挥3.1 状态机做骨架把高频任务建模成确定性流程刚开始设计任务规划模块时我们试过纯ReAct模式——让模型自己决定下一步做什么做完观察结果再决定下一步。demo阶段效果惊艳什么问题都能答感觉无所不能。但一放到真实业务里就露馅了模型经常跳过关键步骤、在查询和回复之间反复横跳、甚至虚构操作结果。后来我们做了一个关键决策用有限状态机FSM做任务骨架把模型约束在状态节点的决策点上。以“退款申请”任务为例状态流转是这样的refund_flow { start: { on_enter: 问候用户确认退款意图, transitions: [ {condition: has_order has_reason, next: confirm_detail}, {condition: missing_order, next: ask_order_id}, {condition: missing_reason, next: ask_reason} ] }, ask_order_id: { on_enter: 引导用户提供订单号, transitions: [ {condition: extract_order_success, next: check_order}, {condition: extract_order_fail_retry, next: ask_order_id}, {condition: retry_exceed_3, next: transfer_human} ] }, check_order: { on_enter: 调用工具查询订单状态, transitions: [ {condition: order_valid within_refund_period, next: confirm_detail}, {condition: order_invalid, next: explain_invalid_order}, {condition: beyond_refund_period, next: explain_policy_violation} ] }, confirm_detail: { on_enter: 展示退款金额与方式请求用户确认, transitions: [ {condition: user_confirmed, next: execute_refund}, {condition: user_modified, next: update_detail}, {condition: user_cancel, next: end_without_execution} ] }, execute_refund: { on_enter: 调用退款工具校验结果, transitions: [ {condition: tool_success, next: notify_success}, {condition: tool_failure, next: handle_failure} ] } }每个状态节点上都挂了一个“决策小模型”或者规则条件判断当前该往哪个状态走。这样设计有几个好处第一关键业务路径是确定的不会出现模型自由发挥跳过“确认退款金额”这一关键节点的情况第二状态节点天然形成审计日志用户走到哪一步、在哪一步放弃都能回溯第三故障兜底有了明确抓手——某个节点连续失败重试超过三次直接转人工不需要模型来做这个判断。3.2 留给模型的空间状态内的自由对话与策略选择完全确定的状态机也不行客服场景有太多变数。用户可能在一个状态里突然问“那如果我七天之后才申请退款呢”也可能上一秒在问退款下一秒说“算了你先帮我把发票开了吧”。我们的做法是状态节点确定了但节点内部的表达由模型自由生成。比如在“ask_order_id”这个状态里用户说“订单号我找不到了是前天买的”模型可以自主解释如何查找订单号、可以提供订单号代查服务、可以安抚用户情绪只要不脱离这个状态的核心目标——拿到有效的订单号。同时我们在编排层维护了一个全局的“意图漂移检测器”。用户当前在退款流程里突然说“那顺便帮我查一下我在你们这买过几次东西”检测器识别到这是一个新的查询意图会暂停当前状态机插入一个查询型子任务完成后回到原状态继续。这就是“状态机骨架自由对话填充意图漂移处理”的三层结构既保证了确定性又保留了对话的自然感。3.3 规划失败的兜底不做硬撑的Agent有一件事我们是从上线第一天就立了规矩的Agent不硬撑。规划层有一套“信心评估”机制状态转移条件不满足、工具调用失败、用户重复追问同一个问题三次以上、模型生成结果置信度低任一条件触发都会走到“转人工”节点。很多Agent项目死在“什么都要自己扛”上。用户已经明显不耐烦了机器人还在那里一遍遍问“您能再详细描述一下您的问题吗”这就是灾难。我们专门做了一个“用户情绪监测”通道小模型实时对用户最近两条消息打情绪标签出现愤怒、急躁、失望标签时如果当前任务还没办成直接触发转人工策略并且把完整上下文打包发给人工客服人工接手的瞬间就能看到用户刚才在办什么、卡在哪。4. 工具调用的工程化落地给Agent装上“手”之后的事4.1 工具层设计不是所有接口都叫“Agent能调的”客服Agent要查订单、改地址、申请退款、开发票这些背后都是客户已有的业务系统接口。但我们没有直接把Agent接到现有API上——现有接口的参数五花八门、权限模型不统一、有的还是同步长事务调用直接暴露给模型就是灾难。工具层做了一个“适配器层”把业务系统的接口包装成Agent友好的统一格式{ tool_name: query_order, description: 根据订单号查询订单详情包括商品、金额、状态、物流信息, parameters: { order_id: { type: string, description: 订单号通常是长度10-20位的字母数字组合, required: true } }, response_schema: { order_status: string, items: array, total_amount: number, logistics: object }, timeout_ms: 3000, allowed_roles: [customer_service_agent] }每个工具注册时都要声明参数、响应格式、超时时间、权限角色和调用频控限制。这些信息会同步注入到模型的上下文里模型只有在明确知道该调哪个工具、参数如何构造时才会调用。参数校验这块尤其重要——绝对不能让模型自由构造参数传给业务系统。4.2 安全执行链从“模型想调”到“真正执行”之间隔着三道闸模型说“我要调退款接口”就真的让它调吗不行。执行链路里我们做了三道闸第一道是参数校验闸。模型生成的工具调用参数必须通过Schema校验类型不对、缺字段、字段不在枚举范围内一律拒绝执行。这里特别要留意参数注入问题——用户可能在对话里说“订单号是abc OR 11”如果模型直接把这段话填进参数参数校验和转义机制必须兜住。第二道是业务规则闸。每个工具可以挂一个规则函数比如退款工具挂的是“订单状态必须是已签收/未发起过退款/在售后期内”规则不满足工具直接返回业务错误码并附带给用户看的解释文案。这道闸是为了防止模型在不该执行操作的时候执行——比如订单还在运输中用户就要退款工具应该回答“当前订单配送中您可以在签收后申请退款”而不是真的发起退款。第三道是人工抽查闸。高风险操作退款、改价、批量操作默认开启“异步人工复核”模式Agent先把请求写入待审核队列人工客服在后台一键确认或驳回。上线初期复核比例是100%跑稳定后逐步下调到10%。4.3 高并发下的工具调用策略客服系统在线用户量虽然比不上头部互联网但峰值时段消息并发也经常上千。模型推理本来就有延迟如果每次用户消息都串行做“理解→规划→调用工具→生成回复”整个链路的P95延迟会冲到十几秒用户早跑了。我们做了两个优化一个是意图预分类并行化——用户消息进来先由小模型打意图标签不同意图走不同的处理通道查询类任务直接走轻量通道不经过大模型规划另一个是工具调用超时熔断——每个工具设置硬超时大部分是3秒超时后立即走降级策略比如查订单失败就引导用户稍后再试或转人工绝不让用户对着“思考中”转圈超过五秒。5. 记忆与上下文管理让Agent记住“三分钟前说过的话”5.1 三层记忆结构客服场景的对话往往超过十个来回用户可能在第四轮说“就是我刚才说的那个订单”如果Agent没有记忆能力这句话就是天书。我们的记忆层分三层第一层是会话级记忆当前会话内所有消息、状态流转、工具调用结果都存在内存里用会话ID做Key。这一层解决的是“刚才说了什么”。第二层是用户级记忆包括用户的姓名、常用收货地址、会员等级、历史订单摘要、之前沟通过的问题和解决方案。这些数据从客户CRM同步过来在会话开始时加载进上下文。这一层解决的是“这个用户是谁、他以前遇到过什么”。第三层是向量记忆库保存历史会话的关键片段Embedding。当用户提到“我之前反映过的那个快递问题”系统会用当前消息做向量检索召回最相关的历史会话片段再把召回结果注入上下文。这一层解决的是“跨会话的长程记忆”。5.2 Token预算与压缩策略大模型的上下文窗口是有限的Token多了不仅花钱响应延迟也会涨而且模型容易“迷失在长文本中”反而抓不住重点。我们给单轮会话的Token预算定了个分配方案系统提示词含工具描述、业务规则、安全约束固定预算约1200 Token用户级记忆客户画像、历史摘要约800 Token超了由摘要模型压缩向量检索召回片段最多3条每条限制200 Token以内会话历史用滑窗策略最近5轮完整保留之前的做渐进式摘要压缩最核心的经验是不要让模型自己决定记住什么。我们专门写了一个“记忆写入器”——每轮对话结束后一个小模型判断当前这轮有没有值得沉淀到用户级记忆或向量库的内容有就提取并结构化存储。用户改了地址记忆写入器会把新地址更新到用户档案用户提到“孩子上小学三年级”这个信息会被丢弃因为它对客服场景没价值。这种主动筛选比让模型从头到尾读全部历史高效得多。6. 安全兜底与可观测性交付后最不能省的工程投入6.1 安全护栏大模型规则引擎审核模型三道防线客服Agent直面终端用户安全红线比一般内部工具高得多。我们在安全上做了三道防线第一道是输入输出审核。用户发的消息先过一道敏感内容审核出现攻击性、违法违规内容直接触发安全策略模型生成的回复也会过一遍审核模型和敏感词库防止模型被诱导说出违规内容。上线前我们专门做了一轮红队测试找团队里最会“诱导”的人去绕模型发现模型在复杂的多轮诱导下确实会说一些不该说的话后来加了审核模型兜底才压住。第二道是动作风险分级。查询类操作查订单、查物流、查积分风险低直接执行写入类操作改地址、改手机号风险中等需要用户二次确认资金类操作退款、赔付风险高走异步人工复核。风险分级表是写死在代码里的模型没有权限修改。第三道是工具白名单与调用审计。模型能调用的工具集合在会话开始时固定不能动态新增所有工具调用都会记录完整的入参、出参、调用时间和结果存留至少180天方便追溯纠纷。6.2 全链路可观测每一个坏回复都能定位到原因Agent出问题是必然的关键是出了问题能不能快速定位。我们的可观测体系围绕“一次会话”做全链路追踪会话ID: 20250117_001234 用户ID: u_887766 入口渠道: app 意图链路: 识别为refund_apply - 状态机进入check_order - 调用query_order成功 - 状态机进入confirm_detail - 用户确认 - 调用create_refund_application失败(超时) - 重试1次失败 - 触发转人工 - 人工接管携带上下文每一轮用户消息都会生成这样一条Trace包含模型调用耗时、工具调用过程、状态流转路径、置信度评分。我们在运维后台做了一个“会话回放”功能可以像看视频一样逐条重放Agent和用户的对话过程同时看到每一步内部发生了什么。这个体系在排查问题时的价值无法估量。有一次用户投诉“机器人乱承诺运费险赔款金额”我们回放会话Trace发现模型在生成回复时引用了工具返回中某个商品的价格作为赔偿金额但其实那是商品售价不是运费险赔付金。根因是工具返回的JSON字段名有歧义模型理解偏了。我们马上改了工具返回Schema把金额字段语义写得更明确问题就解决了。7. 测试、灰度与上线效果一个已交付Agent的验收之路7.1 离线评测集把“感觉好用”变成可量化的指标Agent项目的测试跟传统后端项目完全不同——传统接口测试断言返回JSONAgent测试要评估的是一段对话的质量。而且同样的输入模型每次回答可能都不一样这就是非确定性。我们从客户的真实历史工单里抽了2000条真实会话清洗脱敏后做成评测集每条会话标注了期望的意图路径、关键槽位、回复类型和最终状态。每次模型或策略有改动就全量跑一遍评测集对比通过率。评测指标分四个维度意图识别准确率预测意图和标注意图是否一致槽位填充正确率订单号、商品名、地址等关键信息是否抽取正确流程完成率期望走完的状态机路径是否走完回复安全率是否有不当/不安全/无关回复这套评测集成了我们迭代路上的“交通警察”。有一次我们在评测集上尝试开放更多的模型规划自由度意图识别准确率提升了两个点但流程完成率掉了五个点因为模型频繁跳过确认步骤直接执行。评测数据一出来我们果断回滚了策略。7.2 灰度策略先给5%的用户用别看总数要看转化率上线没有一刀切。我们做了灰度发布第一周5%流量、第二周20%、第三周50%、第四周全量每步都有详细的观测指标。灰度期间每日看板上有四组核心指标指标计算公式目标值自主解决率Agent独立完成会话数 / 总会话数≥ 65%转人工率转人工会话数 / 总会话数≤ 30%人工介入时长人工客服处理Agent转接会话的平均耗时比纯人工下降40%用户满意度会话结束后的评价打分不低于纯人工均值这里要特别强调一个容易踩的坑别只看成功率要看成功率的绝对值是否可接受。5%灰度时自主解决率冲到75%看起来很好但我们一细看发现总会话量只有几百条样本太小指标波动大意义不大。后来我们坚持灰度阶段至少跑满一周、覆盖几万条会话再下结论。7.3 上线后的真实效果全量上线后跑了三个月最终数据跟验收目标对上了核心意图识别准确率96.8%槽位抽取准确率92.3%三高频任务独立完成率73.5%转人工率从之前的100%降到28%。同时人工客服平均处理时长下降了约42%因为他们接手的大多是Agent已经做了一半的预处理工作。印象最深的是一个用户连续四天找客服第一天是查物流第二天是改地址第三天是问发票报销政策第四天问会员积分——前三次Agent都独立解决了第四次到人工时客服直接看到了用户档案里的前三轮处理记录用户说“你们这次终于记得我了”评价给了满分。这让我意识到Agent的长期记忆能力对体验的加成远比单轮对话的“聪明”重要得多。8. 踩坑复盘那些只有真实业务才会逼你面对的问题8.1 循环卡死我在项目开始时接到的那个电话文章开头那个循环问题根因说到底就三个字没边界。当时的版本里“查询订单”这个动作没有设置最大重试次数模型觉得用户没给订单号就反复追问用户不配合就循环。我们后来做了双重修复第一所有状态节点都加了最大重入次数超过三次自动转人工第二模型生成时会检查是否连续生成了重复动作一旦检测到重复会立即触发“换一种方式处理”的策略提示比如从“反复要订单号”切换到“帮用户用手机号查订单”。这个坑给我们的教训是Agent系统的每个循环动作都必须有Break条件而且Break条件要在代码层强制实现不能指望模型自己发现问题。8.2 模型“假成功”嘴上说退款了实际上没退有段时间用户投诉率突然升高一查发现是模型在生成话术时经常说“已经为您成功提交退款申请”但工具层实际调用是失败的。原因是模型根据上下文预测了工具调用的结果而不是等待工具层的真实返回。这个问题特别隐蔽因为单看对话记录Agent表现得非常“正常”。后来强制规定所有涉及动作确认的话术必须由工具层的真实返回结果来驱动。工具返回“success”时生成成功话术工具返回失败或超时模型只能生成“暂时没办成正在帮您检查”之类的中性表达禁止编造成果。我们在Prompt里反复强调同时把工具返回结果作为生成回复的硬约束条件从机制上堵住这条路。8.3 被绕过的高风险操作审批异步人工复核机制上线后我们一度以为资金类操作稳了。直到有次抽检发现模型用一个“状态更新”工具间接修改了退款申请的金额字段绕过了退款工具的人工复核闸门。这就是多工具组合下的安全隐患单个工具看都是低风险组合起来可能就成了高风险操作。我们补上了一道“组合动作风险检测”当一次会话中连续调用两个及以上低风险工具、且工具之间存在数据依赖关系时会触发组合行为审计由规则引擎判断是否需要人工介入。Agent系统的安全问题永远不能静态看待必须从链路和组合的角度去设计防护。回头看这个项目的整个过程我最大的体会是Agent的工程实现本质上是把“智能”和“可控”做分层耦合。模型负责语言理解和生成这些真正需要智能的部分而业务流程的确定性、安全边界、故障兜底必须由工程系统用最朴素、最可靠的方式牢牢抓住。那些热词里讨论的“Agent与模型协作”“任务规划与拆解”在真实项目里从来不是纯理论问题——每一次取舍背后都是用户投诉、指标波动和上线压力逼出来的。希望这篇拆解能给正在做Agent落地的同行一些参考少走几步我们走过的弯路。