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

随着大语言模型能力的持续演进，电商场景下的智能对话系统正从传统 FAQ 问答向具备规划、决策与工具调用能力的 Agent 架构迁移。 本文整理自快手大模型应用算法专家邱慧在 AICon 2026 深圳站 的分享《智能互动 Agent 在快手商业场景的落地实践》。他围绕智能互动 Agent 在互动业务场景下的真实落地实践，系统阐述了商业 Agent 在效果、时延与成本三重约束下的工程选择，以及动态知识库构建、用户模拟器训练、自进化策略与成交归因等关键技术路径。 商业 Agent 落地背景与挑战 今天分享的核心问题很朴素：在一个真实的商业场景里，我们要做哪些事情，才能让一个对话 Agent 真正跑起来、跑得稳、并且持续变好。具体来说，我会从三个方面展开：第一，怎么建知识库，尤其是动态知识库，因为在我们的场景里，知识是有时效性要求的，我们需要知道要做什么才能在真实商业场景里让它用得好。第二，怎么解决用户模拟和 Agent 自进化的问题，避免模型越用越退化。第三，怎么解决模型训练中的奖励稀疏问题，我们整个场景是一个对话场景，对话本身的奖励非常稀疏，最终有没有成交、有没有解决用户问题，只有到最后一轮才能拿到信号，那中间过程的奖励应该怎么分配。最后，我会简单展望一下，从一个商业 Agent 走向下一代 Agent AI，我们还需要做哪些事情。 先讲落地背景和挑战。在端侧，大家常提“不可能三角”；在商业场景下，我们的不可能三角是效果、时延和成本。这个关系很好理解：如果希望效果好，就需要换更大的模型，需要给它加上思考过程，但这样一来整体时延就会上升，成本也会随之提高。我们面临的核心问题，就是怎么在商业场景下把这个三角做好平衡，既保证效果可用，又不让时延和成本失控。 具体到一个对话 Agent 的落地，我们面对的是四重约束，从下往上看。最底层是成本。商业场景下的 QPS 和请求量都非常大，数据又很敏感。如果直接调用外部开源 API，很难保证数据安全和成本可控。往上一层是稳定性。在高 QPS 环境下如何保证稳定输出，是一个非常实际的问题。现在大家用开源模型用得很多，但开源模型有一个普遍问题：相对时延较高，思考模式通常很难关闭，而且输出不稳定。在我们的业务场景下，我们其实希望模型输出尽可能稳定可控。再往上一层，是知识的变化速度。举个例子，在直播或者大促场景下，商家会频繁变更活动：可能现在是买二送一，过几分钟就变成买三送一。这种变化是实时的。如果知识更新不及时，就存在巨大风险，模型可能答错。最上面一层，是进化问题。模型如果长期不更新，会越用越退化，今天跑得好好的，明天出现新场景，效果就开始下滑。 为什么不用现成的方案？在大模型兴起之前，我们做客服、AI 经营小二等场景，主要用传统小模型。那时候的技术栈基本是 FAQ：客服场景用 BERT 比较多，图像任务用 EfficientNet，多模态后来出现了 ALBEF 之类的模型。这些东西做了很多年，但效果一直不理想。根本原因在于，小模型对复杂场景的理解能力不足。我们的对话场景非常复杂，尤其是在售后经营场景下，多轮对话涉及大量追问。如果只做小模型分类，整体流畅度很差，也缺乏稳定的推理和规划能力。此外，真实场景下涉及大量工具调用：用户问商品价格、问快递到哪里了、问能不能退货，这些都需要复杂的工具编排，小模型搞不定。 那为什么不用开源大模型？现在开源模型确实做得越来越好，也越来越便宜。但问题是，开源模型通用，却没有我们的业务数据。它在世界知识上回答得很好，但一旦涉及领域知识，表现就没那么好。而且它可能回答得“像模像样”，像专家一样，但不一定能促进成交。最后回到成本和稳定性的问题：在我们的场景下，我们希望模型能在一到两秒内返回结果。如果直接用开源大模型，一轮思考就可能超时。这些原因共同指向了一个结论：我们需要自研大模型，用自己的业务数据，训练一个懂业务、会决策、能调工具的大模型，同时把成本控制在安全边界内。 具体要做的事情可以归纳为三块。第一块是知识库，我们希望它支持实时更新，保证时效性。第二块是自进化，包括用户模拟器和自进化策略，这部分所有内容都在业务场景下真实落地。第三块是成交归因，就是前面提到的稀疏奖励问题，只有到最后一轮才知道有没有成交或解决问题。我们会分享在真实场景下怎么做分层奖励和信用分配。这三块形成一个闭环：知识库保证它答得对，进化机制保证它不越用越退化，成交归因让它学明白整个对话和交易策略。 动态知识实时性——“知道什么” 做知识库之前，得先知道要解决什么问题。第一个问题是时效和覆盖。所有业务、所有公司都会遇到索引滞后的问题，不管你怎么建索引，它都有滞后性。同时，知识分布在各种不同的载体上：商家维护的知识、商品详情页、直播口播、直播切片等，很难做有效的归总和复用。第二个问题是可信和理解。知识来源多样，商详页、口播、商家维护的信息之间可能存在冲突。知识越多，冲突问题就越难避免。还有语义缺口的问题，有些知识在检索时难度会更大。 针对这些问题，我们首先构建了一个全域知识库。整体链路不算复杂，核心目的是把所有知识统一成一种存储格式和统一形式。把知识做规整化之后，更有利于检索、存储和后续更新。整个知识来源包括两个维度：第一个是对话维度，用户跟人工客服聊天产生的真实对话，我们会从中挖掘知识。第二个是视频维度，包括商家上传的短视频和直播内容，我们从中做知识提取。提取完之后形成 QA 对，同时挂载 entity。这里的 entity 可以理解为知识的归属维度：如果是商品维度的知识，比如某个商品的价格，就挂在商品上；如果是店铺维度的知识，比如这个店铺通常发哪些快递，就挂在店铺维度上。 做完这一步之后，我们给每条知识添加了 intent 标签，目的是为后续检索服务。知识属于哪个维度，物流维度、商品维度，还是其他维度，都通过 intent 标注。这样整个知识库就构建得更加规整。这环可能被一些人理解为“脏活累活”，但它其实是保证整体回答质量最重要的一步。 知识构建完成之后，还需要持续的更新机制。目前我们做到的是天级别更新。当用户问题进来之后，我们会跟现有知识库做检索对比，判别工作交给大模型自己完成。如果发现冲突，就做冲突消减；如果有重叠，就做去重。如果模型能解决就让模型解决，模型解决不了就让人工做 check。通过这一整套机制，数据飞轮就能转起来：知识越用越准，覆盖面越来越广。 但天级别甚至小时级别的挖掘，仍然无法满足实时问答场景的需求。在直播等场景下，商家活动变化极快，这一秒是一个活动，下一秒就换一个。如果依靠离线知识，很难给用户精准回答。针对这个问题，我们在图片知识这一侧做了一个轻量级优化。图片是商品最重要的知识载体之一。用户每问一个关于某个商品的问题，我们会把这个商品下的所有图片一次性拿回来，平均二十到三十张，不做索引。这样做的好处可以做一个对比：原来的索引库方案，知识更新有滞后，而且刷库时间很长。如果我们有一亿商品，每个商品下面二十到三十张图，全量刷库的量非常大。向量模型想换一个，要先做 AB 实验，就要全量刷一遍，推全再全量刷一遍，这个计算量非常庞大。所以我们把所有的计算都放在在线完成：用户问题来了，把商品下所有图片取下来，在线做相关性检索，二十张图里检索一到两张最相关的