快手智能互动Agent商业场景落地实践

随着大语言模型能力的持续演进，电商场景下的智能对话系统正从传统 FAQ 问答向具备规划、决策与工具调用能力的 Agent 架构迁移。

本文整理自快手大模型应用算法专家邱慧在 AICon 2026 深圳站 的分享《智能互动 Agent 在快手商业场景的落地实践》。他围绕智能互动 Agent 在互动业务场景下的真实落地实践，系统阐述了商业 Agent 在效果、时延与成本三重约束下的工程选择，以及动态知识库构建、用户模拟器训练、自进化策略与成交归因等关键技术路径。

以下是演讲实录（经 InfoQ 进行不改变原意的编辑整理）。

今天分享的核心问题很朴素：在一个真实的商业场景里，我们要做哪些事情，才能让一个对话 Agent 真正跑起来、跑得稳、并且持续变好。具体来说，我会从三个方面展开：第一，怎么建知识库，尤其是动态知识库，因为在我们的场景里，知识是有时效性要求的，我们需要知道要做什么才能在真实商业场景里让它用得好。第二，怎么解决用户模拟和 Agent 自进化的问题，避免模型越用越退化。第三，怎么解决模型训练中的奖励稀疏问题，我们整个场景是一个对话场景，对话本身的奖励非常稀疏，最终有没有成交、有没有解决用户问题，只有到最后一轮才能拿到信号，那中间过程的奖励应该怎么分配。最后，我会简单展望一下，从一个商业 Agent 走向下一代 Agent AI，我们还需要做哪些事情。

先讲落地背景和挑战。在端侧，大家常提“不可能三角”；在商业场景下，我们的不可能三角是效果、时延和成本。这个关系很好理解：如果希望效果好，就需要换更大的模型，需要给它加上思考过程，但这样一来整体时延就会上升，成本也会随之提高。我们面临的核心问题，就是怎么在商业场景下把这个三角做好平衡，既保证效果可用，又不让时延和成本失控。

具体到一个对话 Agent 的落地，我们面对的是四重约束，从下往上看。最底层是成本。商业场景下的 QPS 和请求量都非常大，数据又很敏感。如果直接调用外部开源 API，很难保证数据安全和成本可控。往上一层是稳定性。在高 QPS 环境下如何保证稳定输出，是一个非常实际的问题。现在大家用开源模型用得很多，但开源模型有一个普遍问题：相对时延较高，思考模式通常很难关闭，而且输出不稳定。在我们的业务场景下，我们其实希望模型输出尽可能稳定可控。再往上一层，是知识的变化速度。举个例子，在直播或者大促场景下，商家会频繁变更活动：可能现在是买二送一，过几分钟就变成买三送一。这种变化是实时的。如果知识更新不及时，就存在巨大风险，模型可能答错。最上面一层，是进化问题。模型如果长期不更新，会越用越退化，今天跑得好好的，明天出现新场景，效果就开始下滑。

为什么不用现成的方案？在大模型兴起之前，我们做客服、AI 经营小二等场景，主要用传统小模型。那时候的技术栈基本是 FAQ：客服场景用 BERT 比较多，图像任务用 EfficientNet，多模态后来出现了 ALBEF 之类的模型。这些东西做了很多年，但效果一直不理想。根本原因在于，小模型对复杂场景的理解能力不足。我们的对话场景非常复杂，尤其是在售后经营场景下，多轮对话涉及大量追问。如果只做小模型分类，整体流畅度很差，也缺乏稳定的推理和规划能力。此外，真实场景下涉及大量工具调用：用户问商品价格、问快递到哪里了、问能不能退货，这些都需要复杂的工具编排，小模型搞不定。

那为什么不用开源大模型？现在开源模型确实做得越来越好，也越来越便宜。但问题是，开源模型通用，却没有我们的业务数据。它在世界知识上回答得很好，但一旦涉及领域知识，表现就没那么好。而且它可能回答得“像模像样”，像专家一样，但不一定能促进成交。最后回到成本和稳定性的问题：在我们的场景下，我们希望模型能在一到两秒内返回结果。如果直接用开源大模型，一轮思考就可能超时。这些原因共同指向了一个结论：我们需要自研大模型，用自己的业务数据，训练一个懂业务、会决策、能调工具的大模型，同时把成本控制在安全边界内。

具体要做的事情可以归纳为三块。第一块是知识库，我们希望它支持实时更新，保证时效性。第二块是自进化，包括用户模拟器和自进化策略，这部分所有内容都在业务场景下真实落地。第三块是成交归因，就是前面提到的稀疏奖励问题，只有到最后一轮才知道有没有成交或解决问题。我们会分享在真实场景下怎么做分层奖励和信用分配。这三块形成一个闭环：知识库保证它答得对，进化机制保证它不越用越退化，成交归因让它学明白整个对话和交易策略。

做知识库之前，得先知道要解决什么问题。第一个问题是时效和覆盖。所有业务、所有公司都会遇到索引滞后的问题，不管你怎么建索引，它都有滞后性。同时，知识分布在各种不同的载体上：商家维护的知识、商品详情页、直播口播、直播切片等，很难做有效的归总和复用。第二个问题是可信和理解。知识来源多样，商详页、口播、商家维护的信息之间可能存在冲突。知识越多，冲突问题就越难避免。还有语义缺口的问题，有些知识在检索时难度会更大。

针对这些问题，我们首先构建了一个全域知识库。整体链路不算复杂，核心目的是把所有知识统一成一种存储格式和统一形式。把知识做规整化之后，更有利于检索、存储和后续更新。整个知识来源包括两个维度：第一个是对话维度，用户跟人工客服聊天产生的真实对话，我们会从中挖掘知识。第二个是视频维度，包括商家上传的短视频和直播内容，我们从中做知识提取。提取完之后形成 QA 对，同时挂载 entity。这里的 entity 可以理解为知识的归属维度：如果是商品维度的知识，比如某个商品的价格，就挂在商品上；如果是店铺维度的知识，比如这个店铺通常发哪些快递，就挂在店铺维度上。

做完这一步之后，我们给每条知识添加了 intent 标签，目的是为后续检索服务。知识属于哪个维度，物流维度、商品维度，还是其他维度，都通过 intent 标注。这样整个知识库就构建得更加规整。这环可能被一些人理解为“脏活累活”，但它其实是保证整体回答质量最重要的一步。

知识构建完成之后，还需要持续的更新机制。目前我们做到的是天级别更新。当用户问题进来之后，我们会跟现有知识库做检索对比，判别工作交给大模型自己完成。如果发现冲突，就做冲突消减；如果有重叠，就做去重。如果模型能解决就让模型解决，模型解决不了就让人工做 check。通过这一整套机制，数据飞轮就能转起来：知识越用越准，覆盖面越来越广。

但天级别甚至小时级别的挖掘，仍然无法满足实时问答场景的需求。在直播等场景下，商家活动变化极快，这一秒是一个活动，下一秒就换一个。如果依靠离线知识，很难给用户精准回答。针对这个问题，我们在图片知识这一侧做了一个轻量级优化。图片是商品最重要的知识载体之一。用户每问一个关于某个商品的问题，我们会把这个商品下的所有图片一次性拿回来，平均二十到三十张，不做索引。这样做的好处可以做一个对比：原来的索引库方案，知识更新有滞后，而且刷库时间很长。如果我们有一亿商品，每个商品下面二十到三十张图，全量刷库的量非常大。向量模型想换一个，要先做 AB 实验，就要全量刷一遍，推全再全量刷一遍，这个计算量非常庞大。所以我们把所有的计算都放在在线完成：用户问题来了，把商品下所有图片取下来，在线做相关性检索，二十张图里检索一到两张最相关的，再给下游稍大一点的模型做推理。这个思路类似于排序里的粗排加精排。

这里有一个耗时瓶颈。前面提到我们的整体耗时要求很高，希望一秒内返回结果。如果用较大的图片输入，耗时根本扛不住。所以我们的做法是把所有图片 resize 到 224×224。按 224×224 的输入、patch size 为 28 来计算，对应的 token 数大约六十多个。三十张图加起来也就一千八到两千左右的 token，整体检索耗时可以控制在两百毫秒左右。如果图片稍大一点，耗时就会翻倍，检索时间可能到一秒，这是不可接受的。

但简单的 resize 会带来两个问题：首先是图片上的文字可能看不清了，其次整个语义信息会变形。我们的做法是先在大图上做 embedding，同时在大图上加 VCoT（Visual Chain of Thought），包括对图片的各种讲解和商品相关的知识，然后用其他工具把这些 VCoT 信息提取出来。接着训练一个 student 模型，它的输入是 224×224 的低分辨率图片，输出的向量对齐 teacher 模型在大图上学到的向量。这样相当于用小尺寸的向量去学大尺寸向量的表征能力。这是第一个 VCoT 对齐。

对应的 rule 我们加了两个。第一个是 srcc rule，即 student 和 teacher 模型对应向量的对齐 rule，这个保证下限，至少不比 teacher 模型差太多。第二个是 task rule，就是模型自身的分类 rule：我们把图文相关性分了三类：强相关、相关、不相关，做一个三分类任务。通过这两层训练，student 模型的向量就能对图片有一个比较好的理解。

在应用层面还有一个策略。很多图片大图上有大量文字，resize 之后文字看不清。我们在推理阶段会做一些轻量级检测，比如用连通区域检测的方法，把字比较密集的区域抠出来，然后做拼接，再进行推理。这样就能把图片上的关键知识信息保留下来。从效果上看，我们这种图文检索的训练方法相比 baseline 有明显的提升。

知识库构建完成之后，在使用层面有两个 tips 可以分享。第一个是给所有知识打编号。我们不让模型做长思考，但不思考的话模型很容易乱讲。解决方案是给每条知识编一个号，强制模型输出编号。输出一个数字几乎不增加耗时，同时用短溯源代替长思考，既避免了推理时间的增长，又能非常有效地控制“无中生有”。第二个是知识冲突处理。我们给知识设置了优先级：较新的知识优先级更高；从人类对话中挖掘出来、需要人工确认的知识设为较低优先级。通过优先级设置，缓解知识冲突带来的问题。

知识库做好之后，只能保证模型不容易乱答、对用户问题能够回答得比较好。但还有一个问题：怎么保证模型能有效迭代，不会越用越退化，能够突破性能和能力的上限。先讲一下背景，为什么固定的策略在商业场景下运行不好。第一个原因是反馈稀疏，前面已经讲过多次。第二个原因是环境在不断漂移，大促、时效性要求高的场景下，环境在持续发生断层。第三个是更新遗忘的问题。做业务的同学可能有体会：最近迭代了一个新能力，做着做着突然发现之前的能力不行了，发生了能力断层。第四个是预警缺失，很多时候上线之后，最近什么也没做，指标就跌了，但缺少有效的预警机制。

要解决迭代问题，首先要构建一个可以迭代的环境。这里我们做了一个用户模拟器。先回答一个根本问题：用户模拟器是不是必要的？我们有线上真实的对话语料，为什么还要用户模拟器？核心原因是我们的模型在持续迭代。模型变了，它给出的回答就变了。如果模型上一轮的回答和之前不一样，那下一轮就不能再拿用户之前的问题来继续对话。所以我们需要一个能够根据当前语境生成合理用户反应的模拟器。

为什么不能直接用开源大模型做用户模拟器？我们做过实验，把用户画像喂给 Gemini 或者豆包这类模型，效果不太理想，很容易被人识别出来是机器人。看右下角的图灵测试结果，Gemini 和豆包都很容易被识别出当前发问的人是一个机器人。所以我们需要自研一个用户模拟器，用快手自己的数据训练，让它能真实地模拟用户提问。

具体方法是一个两阶段的训练流程。第一阶段是 SFT，用真实数据训练，但这里我们加入了一个 thinking 维度的信息，这个 thinking 是用超大模型生成的。做完 SFT 之后，图灵测试指标就相对好了很多，但是还不够高。第二阶段我们做了一个 RL（Reinforcement Learning）的过程，包括三个部分：token 级别的 alignment，分层 reward design，以及最后的 advantage 分配。Token level alignment 是让 student 模型跟我们较好的模型在对应轮次上的输出做对齐；分层 reward 是对最终结果和中间结果做一个加权分配；同时加一些格式约束的 rule。做完 SFT 加 RL 之后，我们自己的用户模拟器的图灵测试结果基本达到了五五开，也就是说，人类已经分不清它到底是机器还是人了。

有了用户模拟器之后，后面积累迭代数据、做模型更新，整个流程就顺畅了很多。我们维护了两个自进化策略，整个线上模型的更新策略是维护在 prompt 里的。

第一个是机制层面的更新，核心是一个三元组策略池。策略池维护了三类信息：策略本身、环境中的用户数据、以及环境数据。环境数据包括用户环境，比如用户当前的情绪状态、系统环境、以及商品环境。这些环境信息共同维护在一个策略池中。第二个是停止检测机制。当我们发现最近某些轮次的检测值比较大时，就需要触发策略的重新选择，或者重新触发一个策略。

这个说起来比较抽象，举两个例子。第一个是用户环境的变化。我们刚开始跟用户正常聊天，聊着聊着发现用户情绪不对了，开始很生气。这时候我们的回答策略就不能再像普通回答一样，而是需要做更多的安抚动作。这就是用户环境变化导致的策略切换。第二个是系统环境的变化。比如最近一段时间，咨询某一款商品退款的人特别多。刚开始我们会正常告诉用户怎么退款，但当我们发现最近退款量异常高时，整个回答就会变得更加保守，会更多地询问用户为什么要退货，尽量维护商家权益。这就是系统环境变化带来的策略调整。这套策略在线上的使用是，我们把它放在 prompt 里，让模型去检索当前轮应该用什么样的策略，是沿用之前的策略，还是触发新的策略更新。

这样一来，用户、模型、策略、模拟用户之间形成了一个完整闭环：用户和环境产生真实交互，带来训练数据；模型通过数据不断迭代，产生新的数据和反馈；策略负责监督变化。同时我们还设置了围栏策略，如果新模型经过自进化之后策略不对，或者出现了异常变化，就可以做策略回退。通过这种方式，线上模型既能持续更新，又不至于更新到一个诡异的状态。

讲完了知识库和自进化，接下来是模型迭代中最核心的问题：怎么学。这里解决的是如何把最终的奖励拆解到关键的对话节点上。

为什么这个问题很难？因为最终的成交和问题解决都发生在最后一轮。但中间可能经历了很多轮：先识别用户需求，然后做商品推荐和比较，用户比较完之后可能还在犹豫，于是做顾虑消除，最后才促成成交。不能说最终成交了，只有最后一轮的奖励重要。中间环节的奖励怎么分配？顾虑消除这件事很重要，但怎么让模型知道它重要？

先讲动态环境建模。我们需要用户模拟器，在动态环境下产生对应的数据。真实场景是动态变化的，所以必须有一个对应的环境来刻画这种变化。然后是中间奖励的来源问题。最终的 session 级奖励只有最后一轮才有，那中间的过程奖励从哪里来？有一个比较直观的方法：看当前这一轮模型有没有回答用户的问题、有没有解决用户的问题。如果连问题都没回答，那这一轮肯定不是一个好轮次。这个判断可以用 LLM-as-judge 的方式来做。但有时候回答了问题也不一定是一个好回答。比如你回答完之后加了一个反问，引导用户给出更多信息，这反而更容易促进成交。至于 token level 的奖励，可以根据自己的业务场景来设计：大家可以用的最多的就是 LLM-as-judge，看当前有没有回答问题。如果业务场景更看重转化，觉得反问很重要，那就把反问也作为一个奖励维度。这些都需要结合具体场景来定。

然后是整个分层奖励的分配机制。最终的 session 级别奖励怎么分配回去？我们有一个比较有效且朴素的方法：给每一轮做一个权重加权，token 级别给一个超参，这个超参可以在对应数据集上搜索。session 维度的分配方式也有多种选择：可以做平均分，每一轮权重一样；也可以做时间衰减。在我们的业务实践过程中，时间衰减的效果比较好，越靠近后面的轮次，奖励分配越高。当然这跟业务有关，如果在你业务上越靠前的轮次越重要，比如第一轮就答错了，后面全错，那就该让前面的权重更高。这些都可以在自己的场景下尝试。最后加一个格式约束的 rule，相当于围栏，不管你回答得怎么样，至少格式得跟我设定的一样。如果让你输出一张卡片或一个按钮，就得按要求来。通过这种方式，我们把最终的结果拆到了过程环节里，模型就能知道为什么成交，做到可解释、可学习，让一次真实交互成为下一次决策的样本。

但这里有一个更深入的问题：按照朴素的方法分配奖励之后，多轮对话中中间某些轮答错了，这条样本可能一直学不到。这种情况下怎么处理？我们有两个方式。

第一种是 forward-to-back。如果中间某一轮答错了，我们就把后面的轮次都不分配奖励，只学那些答对的轮次，不断迭代，让答对的轮次越来越多。第二种是 back-to-forward。有时候刚开始就答错了，但后来模型靠自己的纠偏能力把结果慢慢掰回来了。这种样本虽然最终结果是对的，但也不能简单地认为是一条好样本，然而它确实有值得学习的地方。做法是找到哪一轮开始错的，把错的那些轮次跳过去，不参与学习。判断哪一轮开始错的方法很多，可以用熵最大的判断，也可以用 LM-as-judge 去判断这一轮是不是开始出错了。然后结合前面的奖励分配方式，只在对的轮次上做奖励分配。这两类策略的目标是一致的：把难例的利用率提上去。

还有一种情况：不管怎么学都学不会，怎么办？这就涉及到课程学习，现在 OPD 等课程学习在业界都很火。这里分享一个比较有效的例子：刚开始模型就是学不会，那我们就让教师模型给提示，比如发现第五轮错了，就告诉它第五轮应该怎么输出。后面逐步减少提示：刚开始告诉它第五、六轮应该怎么输出，之后发现学好了，就只提示第五轮，再往后再逐步减少，最后完全让它自己把完整过程输出出来。这种课程学习的方式在真实应用层面非常有效。

训练层面还有几个 tips。第一个是模型选型：分类任务用 2B 或 4B 的模型就够了；生成任务在我们这种对话场景下，9B 的模型相对更合理。第二个是奖励归因：不管做什么任务，奖励归因都很重要，需要先把奖励拆清楚，应该有哪些奖励维度，才能指导模型迭代。第三个是数据配比：领域模型不能全用业务数据训练，需要混合一定比例的通用数据，否则通用能力会消退。

目前我们在业务上的落地场景主要有四个。第一个是数字员工π，承担营销 Agent 的功能。第二个是快语 AI 小二，即电商客服场景。第三个是 AI 分身+ AI 助播，在直播间里回答用户问题。第四个是女娲互动，与互动变现相关的场景。

在时延和成本这两个维度上，由于我们采用了关闭思考模式的中等规模模型，整体响应时间控制在两秒以内。成本方面，我们没有使用外部大模型做在线推理，大模型主要用于数据生成，自己部署的成本比调用外部大模型低很多。

回顾整个迭代链路，我们经历了从早期 FAQ 架构，逐步升级到 multi-agent 架构，再升级到多模态 agent，中间结合了大量 RL 相关的工作。目前线上运行的架构是一个多模态、多 agent 的体系。

最后谈谈下一代 Agent AI 的方向。目前业界很多大厂和创业公司都在做“闭环”这件事，让 Agent 不只回答问题，而是真实促进成交。它能识别用户诉求，做决策，决定该说什么，甚至可以在特定条件下给用户发券、做优惠，类似于真实场景下的讨价还价。它还应该能复盘：今天为什么卖得不好，明天应该怎么卖，这个方向目前是业界的重点。

第二个方向是 Agent world 的概念。这里的 Agent world 是指我们不光让 Agent 去卖东西，还能协助商家做进货、经营复盘等工作。可以有多个 Agent 协同，把整个电商经营环境构建起来，让 Agent 从完成一次对话，变成在动态环境中做持续的经营协同和自我修正。在这个愿景下，人工的角色转变为设定目标和边界：不能给用户无限优惠，优惠多了用户肯定买，但不能亏本；退货等高风险动作需要人工确认；其他的经营、卖货、进货可以尝试交给模型去做。

会议推荐