1. 从 50 分钟到 2 分半这个数字背后到底发生了什么先把这个标题拆开看。50 分钟压到 2 分半压缩比是 20 倍。做过客服系统的人都知道这个数字不是靠调一个参数、换一个模型就能实现的。它背后牵扯的是整条链路的重新设计从用户发起咨询到意图识别、知识检索、答案生成、人工兜底每一个环节都在吃时间。我们团队做的是电商售后场景的 AI 客服日均咨询量在 8000 到 12000 条之间高峰期能冲到 15000 条。上线前纯人工客服的平均首次响应时长是 50 分钟左右——注意这是“首次响应”不是“问题解决”。用户发一条消息排队等 50 分钟才有人回这在售后场景里基本等于劝退。上线 AI 客服三个月后首次响应时长稳定在 2 分 30 秒上下复杂问题转人工的等待时间也从 40 多分钟降到了 6 分钟以内。这篇文章不讲虚的就讲我们这三个月踩过的三个坑以及每个坑背后对应的技术决策。涉及到的核心概念包括AI Agent、Token、多模态、AI 幻觉这些热搜词不是硬塞进来的而是我们在实际排查问题时反复撞上的东西。如果你正在做 AI 客服、AI Agent 搭建或者任何需要把大模型接入生产环境的项目这些经验应该能帮你少走至少一个月的弯路。先说结论三个坑分别是——Agent 编排过度设计导致链路冗长、Token 用量失控引发响应抖动、幻觉率在售后场景下被严重低估。每一个坑我们都付出了真实的代价有的是钱有的是用户投诉有的是团队通宵。2. 坑一Agent 编排过度设计链路越长死得越惨2.1 我们一开始是怎么设计的刚立项的时候团队里有人提了一个“完美”的 AI Agent 架构用户消息进来先过一个意图分类 Agent再过一个情绪识别 Agent然后根据意图分发给不同的子 Agent——退款 Agent、物流 Agent、商品咨询 Agent、投诉 Agent每个子 Agent 再调用自己的知识库检索工具检索完还要过一个“答案质量评估 Agent”最后才生成回复。整个链路走下来一次对话要经过 5 到 7 个 Agent 节点。这个设计在 demo 阶段看起来很漂亮每个 Agent 各司其职逻辑清晰。但上线第一天就崩了。原因很简单每一个 Agent 节点都是一次独立的模型调用每一次调用都要消耗 Token都要等待网络往返。5 到 7 个节点串行执行哪怕每个节点只花 3 到 5 秒加起来就是 20 到 35 秒。再加上知识库检索的向量查询时间、数据库查询时间一条简单咨询的响应时长直接飙到 40 秒以上。更致命的是链路越长出错概率越高。意图分类 Agent 分错了后面全错情绪识别 Agent 误判用户情绪回复语气就跑偏答案质量评估 Agent 偶尔会把本来正确的答案判为不合格触发重新生成又多吃一轮 Token 和时间。2.2 为什么 Agent 编排容易过度设计这里要区分几个概念。AI Agent和单纯的LLM调用是两回事。LLM 调用就是你给它一个 prompt它给你一个回复一次交互结束。Agent 的核心特征是它能自主决策、能调用工具、能根据中间结果调整下一步动作。理论上Agent 可以完成非常复杂的任务链。但客服场景有一个根本约束用户对响应时长的容忍度极低。售后场景下用户发完消息盯着屏幕等回复超过 30 秒就开始烦躁超过 1 分钟就会重复发送或者直接关掉。这意味着你的 Agent 链路必须在极短时间内完成所有决策。我们后来复盘发现过度设计的根源在于把“能力上限”当成了“默认路径”。Agent 能做的事情很多不代表每件事都要走完整链路。就像你去便利店买瓶水不需要经过导购咨询、商品对比、质量检测、结账复核五个环节直接拿了付钱走人就行。2.3 我们怎么改的改造的核心思路是能一次 LLM 调用解决的问题绝不拆成两次。具体做法是把原来的 5 到 7 个 Agent 节点压缩成两层第一层是一个轻量的意图路由用规则引擎加小模型做快速分类耗时控制在 200 毫秒以内第二层是一个主 Agent它同时承担意图理解、知识检索、答案生成三个职责通过一次模型调用完成。这里的关键技术点是Function Calling。我们把知识库检索、订单查询、物流查询这些能力注册成工具函数主 Agent 在一次调用中决定是否需要调用工具、调用哪个工具、拿到结果后直接生成最终回复。整个过程只消耗一次模型调用的时间。改造前后的对比指标改造前多 Agent 串行改造后单 Agent Function Calling平均响应时长38-45 秒8-12 秒单次对话 Token 消耗3500-50001200-1800意图识别准确率87%91%链路故障率12%3%注意压缩 Agent 节点不是万能药。如果你的业务场景确实需要多步推理比如复杂的退换货政策判断该拆还是要拆。关键是区分“必须串行”和“可以并行”的环节。2.4 实操心得Agent 编排的三个原则第一默认路径最短化。80% 的用户咨询是简单问题——查物流、问退款进度、问商品参数。这些问题的处理链路必须控制在一次模型调用以内。只有 20% 的复杂问题才走多步推理。第二工具调用并行化。如果主 Agent 需要同时查订单和查物流这两个工具调用可以并行发起不要串行等待。我们在代码层面用异步请求实现了这一点节省了大约 1.5 秒。第三设置链路超时熔断。任何一个环节超过预设时间我们设的是 5 秒直接跳过该环节走兜底逻辑。宁可给一个不那么完美的回复也不要让用户等。3. 坑二Token 用量失控账单和响应时长一起爆炸3.1 Token 是怎么悄悄吃掉你的预算和时间的Token是大模型处理文本的基本单位你可以粗略理解为“字”。中文里一个 Token 大约对应 1 到 2 个汉字英文里一个 Token 大约对应 0.75 个单词。每次模型调用输入的 Token 和输出的 Token 都要计费而且输入 Token 越多模型处理时间越长。我们上线第一周就发现了一个诡异现象响应时长波动极大快的 5 秒慢的 40 秒。排查后发现罪魁祸首是System Prompt 和上下文膨胀。具体来说我们最初的 System Prompt 写了将近 2000 个 Token里面塞了各种业务规则、话术模板、注意事项。每次对话还要把最近 10 轮历史消息全部带上又是 1500 到 2000 个 Token。再加上知识库检索返回的文档片段一次调用的输入 Token 轻松突破 5000。输出 Token 平均 300 左右。单次调用总 Token 在 5300 上下。这个数字看起来不大但乘以日均 10000 次调用一天就是 5300 万 Token。更关键的是输入 Token 从 2000 涨到 5000模型的首 Token 延迟TTFT会明显增加因为模型需要先“读完”所有输入才能开始生成。3.2 我们做了哪些 Token 优化第一刀砍在 System Prompt 上。把 2000 Token 的 System Prompt 压缩到 600 Token 以内。怎么压把静态规则改成动态注入——只在与当前意图相关的场景下才注入对应的规则片段。比如用户问退款才注入退款政策用户问物流才注入物流规则。这样每次调用的 System Prompt 平均只有 400 到 600 Token。第二刀砍在历史上下文上。不是所有历史消息都需要带上。我们做了一个滑动窗口加摘要的机制最近 3 轮对话保留原文更早的对话用一个小模型生成摘要摘要控制在 100 Token 以内。这样上下文从 1500-2000 Token 降到了 400-600 Token。第三刀砍在知识库检索上。原来每次检索返回 top-5 文档片段每个片段 300 到 500 Token。后来改成 top-3并且对片段做了截断和精炼每个片段控制在 200 Token 以内。检索返回从 1500-2500 Token 降到了 500-600 Token。优化前后的 Token 对比组成部分优化前 Token 量优化后 Token 量System Prompt1800-2200400-600历史上下文1500-2000400-600知识库检索结果1500-2500500-600用户当前输入50-15050-150模型输出200-400200-400合计5050-72501550-2350Token 总量降了大约 70%响应时长从平均 15 秒降到了 8 秒左右API 账单直接砍掉了三分之二。3.3 Token 优化的边界在哪里这里有一个很容易踩的坑过度压缩 Token 会导致回答质量下降。我们试过把 System Prompt 压到 200 Token结果模型开始胡编乱造因为它没有足够的业务规则约束。也试过把知识库检索结果压到 100 Token结果模型拿不到关键信息回答变得含糊其辞。我的经验是System Prompt 不要低于 400 Token知识库检索结果不要低于 300 Token。低于这个线幻觉率会明显上升。具体的阈值需要根据你的业务复杂度做 A/B 测试。提示Token 优化不是一次性工作。业务规则在变知识库在更新用户问法在演化你需要每个月重新审视一次 Token 分布看看有没有新的膨胀点。3.4 一个容易被忽略的 Token 陷阱多模态输入我们后来接入了图片识别功能——用户发商品破损照片AI 需要识别破损程度。这就是多模态能力。多模态输入图片、音频、视频的 Token 消耗和纯文本完全不是一个量级。一张 1024x1024 的图片经过编码后可能消耗 500 到 1500 个 Token取决于模型和分辨率。我们最初的方案是让用户随便发图结果有人发了 10 张高清图单次调用 Token 直接破万响应时长飙到 30 秒以上。后来加了限制单次对话最多处理 2 张图片图片在客户端先压缩到 512x512服务端再做一次降采样。这样单张图片的 Token 消耗控制在 300 以内。多模态能力很香但一定要设好闸门。不然 Token 账单和响应时长会一起教你做人。4. 坑三幻觉率被严重低估售后场景下每一句胡编都是事故4.1 AI 幻觉在客服场景下意味着什么AI 幻觉是指模型生成了看起来合理但实际错误的内容。在通用聊天场景下幻觉可能只是让人觉得“不太对”。但在售后客服场景下幻觉的代价是实打实的告诉用户“您的退款将在 2 小时内到账”但实际政策是 3 到 5 个工作日用户等了 2 小时没到账直接投诉告诉用户“这款商品支持 30 天无理由退货”但实际是 7 天用户寄回来被拒收又是一次投诉。我们上线第一个月因为幻觉导致的错误回复占比大约在 8% 左右。也就是说每 100 条 AI 回复里有 8 条包含错误信息。这个数字在内部测试时只有 2% 到 3%但真实用户的问法千奇百怪远超测试集的覆盖范围。4.2 幻觉率为什么在生产环境飙升第一个原因是知识库覆盖不足。测试集里的问题都是我们预设好的知识库里都有对应答案。但真实用户会问各种边缘情况“我买了两个商品一个退款一个换货运费怎么算”“我用了优惠券退款时优惠券退不退”“我地址填错了但已经发货了怎么办”这些问题知识库里没有现成答案模型就开始“合理推测”推测就是幻觉的温床。第二个原因是模型在压力下倾向于“给一个答案”而不是“说不知道”。大模型的训练目标决定了它倾向于生成连贯、有用的回复而不是承认自己不知道。当你问一个它不确定的问题时它更可能编一个看起来合理的答案而不是说“我需要转人工”。第三个原因是多轮对话中的上下文污染。用户在前一轮说了一个错误信息比如“我听说你们支持 30 天退货”模型在后续回复中可能会把这个错误信息当成事实来使用。4.3 我们怎么把幻觉率压下来的策略一强制引用来源。我们修改了 System Prompt要求模型在回答任何涉及政策、时效、金额的问题时必须引用知识库中的原文片段。如果知识库中没有相关内容模型必须回复“这个问题我需要为您转接人工客服确认”。这个策略把政策类问题的幻觉率从 12% 降到了 3% 以下。策略二答案一致性校验。对于关键字段退款金额、到账时间、退货期限我们在模型输出后加了一层规则校验。比如模型说“3 到 5 个工作日”校验层会去知识库确认这个数字是否正确。不匹配就拦截走兜底话术。策略三置信度阈值。我们让模型在生成答案时同时输出一个置信度分数通过 logprobs 计算。置信度低于阈值的答案不直接发给用户而是转人工审核或者走保守话术。这个阈值我们设的是 0.75调过几次0.75 是准确率和覆盖率的最佳平衡点。策略四多模态辅助验证。对于涉及商品破损、错发漏发的场景我们要求用户上传图片通过多模态模型识别图片内容与用户描述做交叉验证。如果用户说“屏幕碎了”但图片显示屏幕完好系统会标记为高风险转人工处理。这一步把这类场景的误判率降低了大约 60%。优化前后的幻觉率对比场景类型优化前幻觉率优化后幻觉率政策咨询退款、退货12%2.8%物流时效9%2.1%商品参数6%1.5%金额计算15%3.2%综合8.3%2.4%4.4 幻觉率没有降到零我们怎么兜底即使做到 2.4%日均 10000 次调用仍然有 240 条错误回复。我们的兜底策略是所有 AI 回复都带一个“这个回答有帮助吗”的反馈按钮用户点“没有帮助”直接转人工同时这条对话被标记进入人工复核队列。复核结果每周汇总一次用来更新知识库和优化 Prompt。另外我们在回复末尾加了一行小字“以上信息仅供参考具体以人工客服确认为准。”这句话看起来不起眼但实际降低了大约 30% 的投诉率——因为用户有了预期管理。注意不要试图把幻觉率降到零那是不可能的。你要做的是把幻觉的代价控制在可接受范围内。对于高风险场景涉及金额、时效、政策宁可转人工也不要让 AI 自由发挥。5. 三个月上线的完整时间线和关键决策点5.1 第一个月搭架子踩了 Agent 编排的坑第一个月的核心任务是搭起基本框架。我们选了主流的 LLM API 作为底座用 Function Calling 实现工具调用知识库用向量数据库做语义检索。第一版上线时用的是多 Agent 串行架构响应时长 40 秒以上用户投诉不断。这个月最大的教训是不要在一开始就追求架构的“完美”。我们花了大量时间设计 Agent 之间的通信协议、状态传递、错误处理结果发现这些复杂度在客服场景下大部分是多余的。如果重来一次我会先用最简单的单 Agent 架构跑通闭环再根据实际瓶颈做优化。5.2 第二个月压 Token响应时长砍半第二个月的重点是 Token 优化。我们做了三件事压缩 System Prompt、滑动窗口加摘要、知识库检索结果精炼。Token 总量从平均 6000 降到了 1800 左右响应时长从 40 秒降到了 12 秒。这个月还做了一件重要的事建立了 Token 用量监控看板。按小时统计 Token 消耗、按场景统计平均 Token 量、按模型统计调用次数。这个看板后来帮我们发现了多个 Token 异常点比如某个子 Agent 在特定意图下会疯狂调用工具单次消耗 8000 Token。5.3 第三个月治幻觉把错误率压到可接受范围第三个月的核心是幻觉治理。我们上了强制引用、一致性校验、置信度阈值、多模态交叉验证四层防护。幻觉率从 8.3% 降到了 2.4%。同时建立了人工复核队列和每周知识库更新机制。这个月还做了一次全链路压测模拟了 5000 并发咨询。发现的主要瓶颈是向量数据库的查询延迟在高并发下从 50 毫秒涨到了 800 毫秒。后来加了缓存层把高频问题的检索结果缓存起来延迟降回了 100 毫秒以内。5.4 关键决策点复盘决策点选择理由实际效果Agent 架构从多 Agent 改为单 Agent Function Calling减少链路长度和 Token 消耗响应时长降低 70%上下文管理滑动窗口 摘要平衡上下文完整性和 Token 成本Token 降低 60%幻觉治理四层防护 人工复核售后场景错误代价高幻觉率降低 71%多模态接入限制图片数量和分辨率控制 Token 消耗和响应时长单次多模态调用 Token 控制在 800 以内兜底策略反馈按钮 转人工给用户预期管理投诉率降低 30%6. 常见问题与排查技巧实录6.1 响应时长突然变慢怎么排查第一步看 Token 用量监控。如果某个时间点 Token 量突增大概率是上下文膨胀或者知识库检索返回了过多内容。第二步看各环节耗时分布。我们在链路里埋了点能精确看到意图识别、知识检索、模型调用、后处理各花了多少时间。第三步看模型 API 的响应时间。有时候是模型服务端的问题不是你的代码问题。6.2 幻觉率突然上升怎么排查先看知识库最近有没有更新。知识库更新后如果新内容与旧内容冲突模型会困惑幻觉率会上升。再看 Prompt 有没有改动。Prompt 里任何一句模糊的指令都可能导致模型行为变化。最后看用户问法有没有变化。如果最近有新的促销活动用户会问很多新问题知识库覆盖不足幻觉率自然上升。6.3 Token 用量异常怎么排查按场景拆分 Token 消耗。我们遇到过一个问题某个子 Agent 在处理“退换货”意图时会连续调用 5 次知识库检索每次返回 500 Token单次消耗 2500 Token。原因是检索关键词没设好模型反复尝试不同的查询词。后来加了检索次数上限最多 2 次问题解决。6.4 多模态识别不准怎么排查先看图片质量。用户上传的图片经常是模糊的、光线不足的、角度奇怪的。我们在客户端加了图片质量检测太模糊的直接提示用户重新上传。再看模型选型。不同多模态模型在不同任务上的表现差异很大商品破损识别和文字识别需要的模型能力不一样。最后看 Prompt。多模态 Prompt 需要更明确的指令比如“请判断图片中的商品是否有明显破损如果有指出破损位置和程度”。6.5 常见问题速查表问题现象可能原因排查方向解决方案响应时长突然增加Token 膨胀 / 链路变长查看 Token 监控和链路耗时压缩上下文 / 熔断超时环节幻觉率上升知识库冲突 / Prompt 改动对比知识库版本和 Prompt 版本回滚 / 补充知识库Token 用量异常工具调用失控 / 上下文膨胀按场景拆分 Token 消耗限制工具调用次数 / 压缩上下文多模态识别不准图片质量差 / 模型不适配检查图片质量和模型选型客户端质量检测 / 换模型用户投诉增加回复错误 / 预期不符分析投诉对话加强幻觉治理 / 加免责声明7. 一些关于 AI Agent 和 LLM 的认知纠偏做这个项目最大的收获不是技术上的而是认知上的。很多人问AI Agent 和 LLM 有什么区别我的理解是LLM 是一个能力Agent 是一种用法。LLM 像是一个博学但有时会胡说八道的顾问Agent 是你给这个顾问配了工具箱、工作流程和质量检查机制。顾问本身的能力决定上限Agent 的设计决定下限。AI Agent 搭建最容易犯的错误是“为了 Agent 而 Agent”。不是所有场景都需要 Agent。如果你的场景是简单的问答一次 LLM 调用就够了。只有当任务需要多步推理、需要调用外部工具、需要根据中间结果调整策略时Agent 才有价值。关于Token很多人只关注成本忽略了它对响应时长的影响。输入 Token 越多模型的首 Token 延迟越高。在客服场景下响应时长比成本更敏感。所以 Token 优化的第一目标是降延迟第二目标才是省钱。关于多模态我的建议是不要为了炫技而接入。多模态的价值在于它能处理纯文本处理不了的信息——图片、音频、视频。如果你的业务场景确实需要这些那就接如果只是文本问答多模态只会增加复杂度和成本。关于AI 幻觉这是一个无法根治的问题。你能做的是第一把幻觉率控制在可接受范围内第二对高风险场景设置人工兜底第三给用户合理的预期管理。不要相信任何声称“零幻觉”的方案那要么是场景太简单要么是在骗你。最后分享一个我们内部用的 Prompt 片段用来抑制幻觉当用户询问涉及金额、时效、政策的问题时你必须 1. 先在知识库中检索相关原文 2. 如果找到原文严格按原文回答不得添加任何原文没有的信息 3. 如果没有找到原文回复“这个问题我需要为您转接人工客服确认” 4. 禁止根据常识或推测回答此类问题这个 Prompt 看起来简单但效果非常明显。核心逻辑就是给模型一个“说不知道”的合法出口。模型之所以胡编很多时候是因为它觉得“必须给一个答案”。你明确告诉它“可以说不知道”它反而更诚实了。 AI客服响应从50分钟降至2分半：Agent编排、Token优化与幻觉治理实战
1. 从 50 分钟到 2 分半这个数字背后到底发生了什么先把这个标题拆开看。50 分钟压到 2 分半压缩比是 20 倍。做过客服系统的人都知道这个数字不是靠调一个参数、换一个模型就能实现的。它背后牵扯的是整条链路的重新设计从用户发起咨询到意图识别、知识检索、答案生成、人工兜底每一个环节都在吃时间。我们团队做的是电商售后场景的 AI 客服日均咨询量在 8000 到 12000 条之间高峰期能冲到 15000 条。上线前纯人工客服的平均首次响应时长是 50 分钟左右——注意这是“首次响应”不是“问题解决”。用户发一条消息排队等 50 分钟才有人回这在售后场景里基本等于劝退。上线 AI 客服三个月后首次响应时长稳定在 2 分 30 秒上下复杂问题转人工的等待时间也从 40 多分钟降到了 6 分钟以内。这篇文章不讲虚的就讲我们这三个月踩过的三个坑以及每个坑背后对应的技术决策。涉及到的核心概念包括AI Agent、Token、多模态、AI 幻觉这些热搜词不是硬塞进来的而是我们在实际排查问题时反复撞上的东西。如果你正在做 AI 客服、AI Agent 搭建或者任何需要把大模型接入生产环境的项目这些经验应该能帮你少走至少一个月的弯路。先说结论三个坑分别是——Agent 编排过度设计导致链路冗长、Token 用量失控引发响应抖动、幻觉率在售后场景下被严重低估。每一个坑我们都付出了真实的代价有的是钱有的是用户投诉有的是团队通宵。2. 坑一Agent 编排过度设计链路越长死得越惨2.1 我们一开始是怎么设计的刚立项的时候团队里有人提了一个“完美”的 AI Agent 架构用户消息进来先过一个意图分类 Agent再过一个情绪识别 Agent然后根据意图分发给不同的子 Agent——退款 Agent、物流 Agent、商品咨询 Agent、投诉 Agent每个子 Agent 再调用自己的知识库检索工具检索完还要过一个“答案质量评估 Agent”最后才生成回复。整个链路走下来一次对话要经过 5 到 7 个 Agent 节点。这个设计在 demo 阶段看起来很漂亮每个 Agent 各司其职逻辑清晰。但上线第一天就崩了。原因很简单每一个 Agent 节点都是一次独立的模型调用每一次调用都要消耗 Token都要等待网络往返。5 到 7 个节点串行执行哪怕每个节点只花 3 到 5 秒加起来就是 20 到 35 秒。再加上知识库检索的向量查询时间、数据库查询时间一条简单咨询的响应时长直接飙到 40 秒以上。更致命的是链路越长出错概率越高。意图分类 Agent 分错了后面全错情绪识别 Agent 误判用户情绪回复语气就跑偏答案质量评估 Agent 偶尔会把本来正确的答案判为不合格触发重新生成又多吃一轮 Token 和时间。2.2 为什么 Agent 编排容易过度设计这里要区分几个概念。AI Agent和单纯的LLM调用是两回事。LLM 调用就是你给它一个 prompt它给你一个回复一次交互结束。Agent 的核心特征是它能自主决策、能调用工具、能根据中间结果调整下一步动作。理论上Agent 可以完成非常复杂的任务链。但客服场景有一个根本约束用户对响应时长的容忍度极低。售后场景下用户发完消息盯着屏幕等回复超过 30 秒就开始烦躁超过 1 分钟就会重复发送或者直接关掉。这意味着你的 Agent 链路必须在极短时间内完成所有决策。我们后来复盘发现过度设计的根源在于把“能力上限”当成了“默认路径”。Agent 能做的事情很多不代表每件事都要走完整链路。就像你去便利店买瓶水不需要经过导购咨询、商品对比、质量检测、结账复核五个环节直接拿了付钱走人就行。2.3 我们怎么改的改造的核心思路是能一次 LLM 调用解决的问题绝不拆成两次。具体做法是把原来的 5 到 7 个 Agent 节点压缩成两层第一层是一个轻量的意图路由用规则引擎加小模型做快速分类耗时控制在 200 毫秒以内第二层是一个主 Agent它同时承担意图理解、知识检索、答案生成三个职责通过一次模型调用完成。这里的关键技术点是Function Calling。我们把知识库检索、订单查询、物流查询这些能力注册成工具函数主 Agent 在一次调用中决定是否需要调用工具、调用哪个工具、拿到结果后直接生成最终回复。整个过程只消耗一次模型调用的时间。改造前后的对比指标改造前多 Agent 串行改造后单 Agent Function Calling平均响应时长38-45 秒8-12 秒单次对话 Token 消耗3500-50001200-1800意图识别准确率87%91%链路故障率12%3%注意压缩 Agent 节点不是万能药。如果你的业务场景确实需要多步推理比如复杂的退换货政策判断该拆还是要拆。关键是区分“必须串行”和“可以并行”的环节。2.4 实操心得Agent 编排的三个原则第一默认路径最短化。80% 的用户咨询是简单问题——查物流、问退款进度、问商品参数。这些问题的处理链路必须控制在一次模型调用以内。只有 20% 的复杂问题才走多步推理。第二工具调用并行化。如果主 Agent 需要同时查订单和查物流这两个工具调用可以并行发起不要串行等待。我们在代码层面用异步请求实现了这一点节省了大约 1.5 秒。第三设置链路超时熔断。任何一个环节超过预设时间我们设的是 5 秒直接跳过该环节走兜底逻辑。宁可给一个不那么完美的回复也不要让用户等。3. 坑二Token 用量失控账单和响应时长一起爆炸3.1 Token 是怎么悄悄吃掉你的预算和时间的Token是大模型处理文本的基本单位你可以粗略理解为“字”。中文里一个 Token 大约对应 1 到 2 个汉字英文里一个 Token 大约对应 0.75 个单词。每次模型调用输入的 Token 和输出的 Token 都要计费而且输入 Token 越多模型处理时间越长。我们上线第一周就发现了一个诡异现象响应时长波动极大快的 5 秒慢的 40 秒。排查后发现罪魁祸首是System Prompt 和上下文膨胀。具体来说我们最初的 System Prompt 写了将近 2000 个 Token里面塞了各种业务规则、话术模板、注意事项。每次对话还要把最近 10 轮历史消息全部带上又是 1500 到 2000 个 Token。再加上知识库检索返回的文档片段一次调用的输入 Token 轻松突破 5000。输出 Token 平均 300 左右。单次调用总 Token 在 5300 上下。这个数字看起来不大但乘以日均 10000 次调用一天就是 5300 万 Token。更关键的是输入 Token 从 2000 涨到 5000模型的首 Token 延迟TTFT会明显增加因为模型需要先“读完”所有输入才能开始生成。3.2 我们做了哪些 Token 优化第一刀砍在 System Prompt 上。把 2000 Token 的 System Prompt 压缩到 600 Token 以内。怎么压把静态规则改成动态注入——只在与当前意图相关的场景下才注入对应的规则片段。比如用户问退款才注入退款政策用户问物流才注入物流规则。这样每次调用的 System Prompt 平均只有 400 到 600 Token。第二刀砍在历史上下文上。不是所有历史消息都需要带上。我们做了一个滑动窗口加摘要的机制最近 3 轮对话保留原文更早的对话用一个小模型生成摘要摘要控制在 100 Token 以内。这样上下文从 1500-2000 Token 降到了 400-600 Token。第三刀砍在知识库检索上。原来每次检索返回 top-5 文档片段每个片段 300 到 500 Token。后来改成 top-3并且对片段做了截断和精炼每个片段控制在 200 Token 以内。检索返回从 1500-2500 Token 降到了 500-600 Token。优化前后的 Token 对比组成部分优化前 Token 量优化后 Token 量System Prompt1800-2200400-600历史上下文1500-2000400-600知识库检索结果1500-2500500-600用户当前输入50-15050-150模型输出200-400200-400合计5050-72501550-2350Token 总量降了大约 70%响应时长从平均 15 秒降到了 8 秒左右API 账单直接砍掉了三分之二。3.3 Token 优化的边界在哪里这里有一个很容易踩的坑过度压缩 Token 会导致回答质量下降。我们试过把 System Prompt 压到 200 Token结果模型开始胡编乱造因为它没有足够的业务规则约束。也试过把知识库检索结果压到 100 Token结果模型拿不到关键信息回答变得含糊其辞。我的经验是System Prompt 不要低于 400 Token知识库检索结果不要低于 300 Token。低于这个线幻觉率会明显上升。具体的阈值需要根据你的业务复杂度做 A/B 测试。提示Token 优化不是一次性工作。业务规则在变知识库在更新用户问法在演化你需要每个月重新审视一次 Token 分布看看有没有新的膨胀点。3.4 一个容易被忽略的 Token 陷阱多模态输入我们后来接入了图片识别功能——用户发商品破损照片AI 需要识别破损程度。这就是多模态能力。多模态输入图片、音频、视频的 Token 消耗和纯文本完全不是一个量级。一张 1024x1024 的图片经过编码后可能消耗 500 到 1500 个 Token取决于模型和分辨率。我们最初的方案是让用户随便发图结果有人发了 10 张高清图单次调用 Token 直接破万响应时长飙到 30 秒以上。后来加了限制单次对话最多处理 2 张图片图片在客户端先压缩到 512x512服务端再做一次降采样。这样单张图片的 Token 消耗控制在 300 以内。多模态能力很香但一定要设好闸门。不然 Token 账单和响应时长会一起教你做人。4. 坑三幻觉率被严重低估售后场景下每一句胡编都是事故4.1 AI 幻觉在客服场景下意味着什么AI 幻觉是指模型生成了看起来合理但实际错误的内容。在通用聊天场景下幻觉可能只是让人觉得“不太对”。但在售后客服场景下幻觉的代价是实打实的告诉用户“您的退款将在 2 小时内到账”但实际政策是 3 到 5 个工作日用户等了 2 小时没到账直接投诉告诉用户“这款商品支持 30 天无理由退货”但实际是 7 天用户寄回来被拒收又是一次投诉。我们上线第一个月因为幻觉导致的错误回复占比大约在 8% 左右。也就是说每 100 条 AI 回复里有 8 条包含错误信息。这个数字在内部测试时只有 2% 到 3%但真实用户的问法千奇百怪远超测试集的覆盖范围。4.2 幻觉率为什么在生产环境飙升第一个原因是知识库覆盖不足。测试集里的问题都是我们预设好的知识库里都有对应答案。但真实用户会问各种边缘情况“我买了两个商品一个退款一个换货运费怎么算”“我用了优惠券退款时优惠券退不退”“我地址填错了但已经发货了怎么办”这些问题知识库里没有现成答案模型就开始“合理推测”推测就是幻觉的温床。第二个原因是模型在压力下倾向于“给一个答案”而不是“说不知道”。大模型的训练目标决定了它倾向于生成连贯、有用的回复而不是承认自己不知道。当你问一个它不确定的问题时它更可能编一个看起来合理的答案而不是说“我需要转人工”。第三个原因是多轮对话中的上下文污染。用户在前一轮说了一个错误信息比如“我听说你们支持 30 天退货”模型在后续回复中可能会把这个错误信息当成事实来使用。4.3 我们怎么把幻觉率压下来的策略一强制引用来源。我们修改了 System Prompt要求模型在回答任何涉及政策、时效、金额的问题时必须引用知识库中的原文片段。如果知识库中没有相关内容模型必须回复“这个问题我需要为您转接人工客服确认”。这个策略把政策类问题的幻觉率从 12% 降到了 3% 以下。策略二答案一致性校验。对于关键字段退款金额、到账时间、退货期限我们在模型输出后加了一层规则校验。比如模型说“3 到 5 个工作日”校验层会去知识库确认这个数字是否正确。不匹配就拦截走兜底话术。策略三置信度阈值。我们让模型在生成答案时同时输出一个置信度分数通过 logprobs 计算。置信度低于阈值的答案不直接发给用户而是转人工审核或者走保守话术。这个阈值我们设的是 0.75调过几次0.75 是准确率和覆盖率的最佳平衡点。策略四多模态辅助验证。对于涉及商品破损、错发漏发的场景我们要求用户上传图片通过多模态模型识别图片内容与用户描述做交叉验证。如果用户说“屏幕碎了”但图片显示屏幕完好系统会标记为高风险转人工处理。这一步把这类场景的误判率降低了大约 60%。优化前后的幻觉率对比场景类型优化前幻觉率优化后幻觉率政策咨询退款、退货12%2.8%物流时效9%2.1%商品参数6%1.5%金额计算15%3.2%综合8.3%2.4%4.4 幻觉率没有降到零我们怎么兜底即使做到 2.4%日均 10000 次调用仍然有 240 条错误回复。我们的兜底策略是所有 AI 回复都带一个“这个回答有帮助吗”的反馈按钮用户点“没有帮助”直接转人工同时这条对话被标记进入人工复核队列。复核结果每周汇总一次用来更新知识库和优化 Prompt。另外我们在回复末尾加了一行小字“以上信息仅供参考具体以人工客服确认为准。”这句话看起来不起眼但实际降低了大约 30% 的投诉率——因为用户有了预期管理。注意不要试图把幻觉率降到零那是不可能的。你要做的是把幻觉的代价控制在可接受范围内。对于高风险场景涉及金额、时效、政策宁可转人工也不要让 AI 自由发挥。5. 三个月上线的完整时间线和关键决策点5.1 第一个月搭架子踩了 Agent 编排的坑第一个月的核心任务是搭起基本框架。我们选了主流的 LLM API 作为底座用 Function Calling 实现工具调用知识库用向量数据库做语义检索。第一版上线时用的是多 Agent 串行架构响应时长 40 秒以上用户投诉不断。这个月最大的教训是不要在一开始就追求架构的“完美”。我们花了大量时间设计 Agent 之间的通信协议、状态传递、错误处理结果发现这些复杂度在客服场景下大部分是多余的。如果重来一次我会先用最简单的单 Agent 架构跑通闭环再根据实际瓶颈做优化。5.2 第二个月压 Token响应时长砍半第二个月的重点是 Token 优化。我们做了三件事压缩 System Prompt、滑动窗口加摘要、知识库检索结果精炼。Token 总量从平均 6000 降到了 1800 左右响应时长从 40 秒降到了 12 秒。这个月还做了一件重要的事建立了 Token 用量监控看板。按小时统计 Token 消耗、按场景统计平均 Token 量、按模型统计调用次数。这个看板后来帮我们发现了多个 Token 异常点比如某个子 Agent 在特定意图下会疯狂调用工具单次消耗 8000 Token。5.3 第三个月治幻觉把错误率压到可接受范围第三个月的核心是幻觉治理。我们上了强制引用、一致性校验、置信度阈值、多模态交叉验证四层防护。幻觉率从 8.3% 降到了 2.4%。同时建立了人工复核队列和每周知识库更新机制。这个月还做了一次全链路压测模拟了 5000 并发咨询。发现的主要瓶颈是向量数据库的查询延迟在高并发下从 50 毫秒涨到了 800 毫秒。后来加了缓存层把高频问题的检索结果缓存起来延迟降回了 100 毫秒以内。5.4 关键决策点复盘决策点选择理由实际效果Agent 架构从多 Agent 改为单 Agent Function Calling减少链路长度和 Token 消耗响应时长降低 70%上下文管理滑动窗口 摘要平衡上下文完整性和 Token 成本Token 降低 60%幻觉治理四层防护 人工复核售后场景错误代价高幻觉率降低 71%多模态接入限制图片数量和分辨率控制 Token 消耗和响应时长单次多模态调用 Token 控制在 800 以内兜底策略反馈按钮 转人工给用户预期管理投诉率降低 30%6. 常见问题与排查技巧实录6.1 响应时长突然变慢怎么排查第一步看 Token 用量监控。如果某个时间点 Token 量突增大概率是上下文膨胀或者知识库检索返回了过多内容。第二步看各环节耗时分布。我们在链路里埋了点能精确看到意图识别、知识检索、模型调用、后处理各花了多少时间。第三步看模型 API 的响应时间。有时候是模型服务端的问题不是你的代码问题。6.2 幻觉率突然上升怎么排查先看知识库最近有没有更新。知识库更新后如果新内容与旧内容冲突模型会困惑幻觉率会上升。再看 Prompt 有没有改动。Prompt 里任何一句模糊的指令都可能导致模型行为变化。最后看用户问法有没有变化。如果最近有新的促销活动用户会问很多新问题知识库覆盖不足幻觉率自然上升。6.3 Token 用量异常怎么排查按场景拆分 Token 消耗。我们遇到过一个问题某个子 Agent 在处理“退换货”意图时会连续调用 5 次知识库检索每次返回 500 Token单次消耗 2500 Token。原因是检索关键词没设好模型反复尝试不同的查询词。后来加了检索次数上限最多 2 次问题解决。6.4 多模态识别不准怎么排查先看图片质量。用户上传的图片经常是模糊的、光线不足的、角度奇怪的。我们在客户端加了图片质量检测太模糊的直接提示用户重新上传。再看模型选型。不同多模态模型在不同任务上的表现差异很大商品破损识别和文字识别需要的模型能力不一样。最后看 Prompt。多模态 Prompt 需要更明确的指令比如“请判断图片中的商品是否有明显破损如果有指出破损位置和程度”。6.5 常见问题速查表问题现象可能原因排查方向解决方案响应时长突然增加Token 膨胀 / 链路变长查看 Token 监控和链路耗时压缩上下文 / 熔断超时环节幻觉率上升知识库冲突 / Prompt 改动对比知识库版本和 Prompt 版本回滚 / 补充知识库Token 用量异常工具调用失控 / 上下文膨胀按场景拆分 Token 消耗限制工具调用次数 / 压缩上下文多模态识别不准图片质量差 / 模型不适配检查图片质量和模型选型客户端质量检测 / 换模型用户投诉增加回复错误 / 预期不符分析投诉对话加强幻觉治理 / 加免责声明7. 一些关于 AI Agent 和 LLM 的认知纠偏做这个项目最大的收获不是技术上的而是认知上的。很多人问AI Agent 和 LLM 有什么区别我的理解是LLM 是一个能力Agent 是一种用法。LLM 像是一个博学但有时会胡说八道的顾问Agent 是你给这个顾问配了工具箱、工作流程和质量检查机制。顾问本身的能力决定上限Agent 的设计决定下限。AI Agent 搭建最容易犯的错误是“为了 Agent 而 Agent”。不是所有场景都需要 Agent。如果你的场景是简单的问答一次 LLM 调用就够了。只有当任务需要多步推理、需要调用外部工具、需要根据中间结果调整策略时Agent 才有价值。关于Token很多人只关注成本忽略了它对响应时长的影响。输入 Token 越多模型的首 Token 延迟越高。在客服场景下响应时长比成本更敏感。所以 Token 优化的第一目标是降延迟第二目标才是省钱。关于多模态我的建议是不要为了炫技而接入。多模态的价值在于它能处理纯文本处理不了的信息——图片、音频、视频。如果你的业务场景确实需要这些那就接如果只是文本问答多模态只会增加复杂度和成本。关于AI 幻觉这是一个无法根治的问题。你能做的是第一把幻觉率控制在可接受范围内第二对高风险场景设置人工兜底第三给用户合理的预期管理。不要相信任何声称“零幻觉”的方案那要么是场景太简单要么是在骗你。最后分享一个我们内部用的 Prompt 片段用来抑制幻觉当用户询问涉及金额、时效、政策的问题时你必须 1. 先在知识库中检索相关原文 2. 如果找到原文严格按原文回答不得添加任何原文没有的信息 3. 如果没有找到原文回复“这个问题我需要为您转接人工客服确认” 4. 禁止根据常识或推测回答此类问题这个 Prompt 看起来简单但效果非常明显。核心逻辑就是给模型一个“说不知道”的合法出口。模型之所以胡编很多时候是因为它觉得“必须给一个答案”。你明确告诉它“可以说不知道”它反而更诚实了。