写在前面
去年年初我加入某电商公司，业余投身AI Agent在电商领域的探索中，彼时朋友们开玩笑问我是不是去做AI客服，以后他们是不是再也没法转人工了？我说比这个想象力更大，项目尚且保密不便透露。当初踌躇满志，想要开启电商乃至AI行业排头兵，打造出一个具备感知、规划、行动甚至能协同的AI Agent，代替电商卖家部分的店铺经营工作，只是后来产品虽然上线，但效果不是很理想，负责期间也踩过很多坑，万般感慨和沮丧让我忍不住在此记录一些过程和想法，权当一次Agent先烈的复盘。
项目背景
现如今的电商卖家后台功能已变得十分庞大，加上电商平台规则复杂，给卖家经营增加了相当多理解成本，严重制约卖家的经营人效和经营信心。而AI大模型和AI Agent技术的出现，让我们看到通过智能化手段降低这一阻碍的机会。
基于卖家规模层级的痛点差异，我们着重瞄准年GMV千万以下的中小卖家，他们有货源但运营能力较弱，我们期望让AI Agent扮演卖家数字员工的角色，简化这部分卖家的经营动作。
产品思路
内部给这一产品起的代号是AI Team——由多个Agent组成的卖家经营团队，不同的Agent分别负责商品图生成、商品文案编辑、店铺运营代理和店铺数据分析等经营环节，卖家能够给它们指派任务，从不同Agent获取不同类的信息。
常规的信息和功能，例如店铺今日销量、店铺访客数、修改商品标题等，可以由LLM+RAG+工程化指令实现，使得问题被准确快速地满足，这类问题是收敛的，但仅占据用户所有query的30%~40%，更多问题在我们的知识库是没有的，属于开放且复杂的任务，例如选出店铺主推款、分析店铺流量下跌原因、配置合适的优惠券等等，这就需要我们推动去建设属于Agent应当有的核心组件能力——planning，我们内部管它叫复杂任务推理，后来在O1模型和R1模型等推理模型出现后，业内习惯于管它叫”深度思考“，是的，我们立项的时候，还没有推理模型出现，直到我们功能上线后，OpenAI才发布O1。
在判断场景切入点和优先级时，我们基于线上意图类型占比，寻找诉求占比较多、提升空间大和满足成本较低的场景，发现店铺经营数据分析是个不错的选择，这类复杂任务意图占整个大盘接近10%，但无法通过现有能力满足，空间很大，而且数据的获取对大模型来说是个相对比较简单的Action。
锚定好经营数据诊断这一方向后，便开始0~1的踩坑之路。
建设过程
在启动这个项目之前，我与算法和工程团队几乎没有成熟完整Agent搭建经验，面对做一个具备感知-规划-行动完整闭环，且能深度解决业务问题的Agent项目，一时间有些迷茫，加上彼时并没有推理基础模型可用，模型巅峰水平还停留在GPT-4那一代，我们对基础模型能否被激发出可用的推理能力并没有确定性把握，一切都有赌的成分在里面。经过一番盘点，想要实现预想中的效果，我们核心需要解决四个问题：推理技术选型、训练数据来源、训练数据规模和输出准确性。
- 推理技术选型： 彼时行业里的推理框架基础停留在学术demo阶段，我们决定采用ReAct思维链的方式来激发模型的planning能力，结合few-shot来做MVP实验，这会影响我们后续数据采集、训练、部署等一系列项目执行安排。
- 训练数据来源： 想要让Agent具备特定任务域的复杂任务推理能力，其本质在于让它学会像该领域的专家一样思考、分析和解决问题，因此用作这项能力训练的数据，其实就是专家们的思考过程，要让专家们来输出。我们首先解决了一系列信息搜集、联络、评估和谈判的问题，去找有能力有意愿配合的专家。通过公司内多个协同部门掌握的渠道，联系一些具备电商卖家经营经验的授课老师和代运营，付费邀请他们参与。但这类专家只是业务专家而非AI领域的技术专家，所输出的内容无法直接驱动大模型完成推理过程，因此我们仿照ReAct思维链框架制定出一个标准专家经验输出格式，专家只需按照格式要求填表，无需关心后链路。可即便如此专家产出的业务质量也不一定达标，期间发生多次返工的问题，这就需要业务同学在前期有严格的专家专业度评估，和密切的沟通对齐，此项工作量较大，我们临时借调了一些AI数据标注同学参与。最终我们管这一过程叫“人类知识萃取”，获得的专家原始经验称为“种子数据”。
- 训练数据规模： 在获得种子数据后，团队很快通过one-shot的方式验证了Agent在经营数据诊断领域的推理效果，但想要让这项能力真正可用，乃至完成SFT，还需要更多数据语料堆叠。原始种子数据输出成本很大，一名专家通常需要花费1到1.5天的时间，对应于我们需要的量级和速度远远不够。因此我们决定考虑用合成数据。合成数据的生产，本质上是利用大模型one-shot能力基于已有种子数据做扩增的过程，由此搭建出合成数据生产平台，来扩大训练数据规模到可用水平。考虑到业务深度和准确度的要求，合成后的数据仍需由人工校正，但效率比纯人工输出还是要高出不少。
- 输出效果和准确性： 随着复杂任务推理能力覆盖场景的增多，我们发现其输出效果上存在两大问题——速度慢，数据准确性不高。原因是多数场景所需的推理步骤较多，模型一步步完成的耗时叠加，使得速度较慢，且每一步中间都可能出现幻觉和遗忘问题，导致随着推理进行，对过程数据的解读出现偏差。因此我们采取两个动作，先是引入多Agent协同来参与单条推理链路，分别负责规划、数据解读和总结，再将其中某些分工蒸馏到小模型中，改善了复杂任务推理效果和速度。当然，为了缓解用户焦虑，我们还将每步推理过程展示出来，类似于之后推出的O1和R1在返回答案前的过程效果。
结果
最终我们成功上线了复杂任务推理能力，用于电商经营数据诊断的真正意义上的Agent算是诞生了。它能够在掌握各种数据相关工具和API的情况下，帮助商家分析商品流量和转化等相关问题，给出具体的经营建议。它不仅能分析我们微调部署好的场景，也能举一反三，泛化出更多问题场景的解答。
但这一结果并不算理想，主要体现在两方面：
一、投入成本较大。尽管通过复杂任务推理能力的建设，AI Team在某些场景下的回答满足率得到提升，但为达成这一目标，我们前后投入很多训练数据采集和部署资源，上线周期也比预计要长，这还只是一个经营数据诊断场景的覆盖，如果覆盖更多场景，例如店铺运营代理、营销工具配置等，投入会更为难估；
二、业务结果无法量化归因。在这一场景下，商家用户从Agent中所获得的是基于店铺数据分析得出的经营建议，但商家实际有没有采纳此类建议，我们无法通过产品化的手段获知，以及，采纳后对于店铺经营状况究竟有无影响，同样是模糊的，毕竟影响商家经营的因子实在太多。
所以从ROI和业务结果来看，这一项目不算特别成功。
反思
立项之初对项目结果抱有比较高的期望，结果上的不完美促使我反思整件事可以改进提升的点。
- 技术边界判断：基础模型能力尚不成熟，不应该过早追求对垂直行业领域复杂任务的planning。当然，彼时我们并不清楚模型潜力究竟在哪儿，现在这样讲多少有点马后炮。在技术上限不确定的情况下，做产品要谨遵MVP原则，判断效果不理想的时候，及时降低预期甚至放弃；
- 业务价值预估：无法证明Agent复杂任务规划与分析带来的结果真的对商家有用，像是为了能力做产品。项目的立项多少带着技术追求和信仰，能不能如我们预想的那样对用户产生真实价值很不确定，我们应该一开始就明确给用户交付的价值点是什么，或者基于用户期望，给Agent交付出的效果设定一个标准；
- 应用场景切分：对场景挖掘还是比较粗暴，应该精细化地分层分行业梳理子场景，挑其中重点和易点做闭环，这对延伸业务价值也是一个补充；
- 组织协同加强：自下而上的推动力不足。我们切入的方向比较大，所涉及的工具和接口分散在不同业务线，有些甚至不在一个BU，因此在部署能力的过程中遇到不少协同上的阻力，不过可以理解的是，在能力效果不明确的情况下，想要赢得上层老板的认同和给予资源也不现实。
整个过程最大的收获其实是从0到1摸索出一套Agent建设产品协同机制——定义场景，人类知识萃取，数据清洗，API开发，合成数据生产和校正，训练部署，验收和优化，每一步团队此前都基本没涉及过，是我们一点点探索的，而产品经理在大模型应用时代，关键职责就是把控产研流程，明确产品、运营、数据、研发和算法等职能的分工，以及认清技术能力边界，平衡技术上限和业务影响。
些许展望
我不会放弃对AI Agent可能性的探索，这次项目于我而言是宝贵的经历。我们知道在LLM火起来后，多数人都期待实现《钢铁侠》中的贾维斯那样的助手，大大方便我们的生活和生产力，AI Agent方向的火爆就是这一愿景的具象化。当然，做到那种程度还有很多路要走，主要依赖于基础模型的演化。
但我们也无需等待AGI和完全体实现的那一天，现在基础模型和Agent所具备的推理能力已经具备不小的应用价值，在现有条件下构建推理能力主要有两点意义——
- 显著降低工程成本。以往开发某个功能点，我们需要UI设计，投入各端开发，测试，上线，但基于大模型的方式做，可能仅仅需要输入推理数据，交由模型的推理能力实现，整条实现链路变得更加敏捷和低成本；
- 用不确定性换取泛化性，满足未知需求。大模型的自主推理能力使得其输出结果不如传统算法和工程手段可控，但正是这种自主能力使其自带举一反三的泛化性，传统软件的输入输出都是确定好的，我们只能实现预先获知和确定好的需求，功能对需求的满足总是滞后的，而大模型的推理泛化能力，能让产品具有未被我们预先定义好的场景满足能力，功能对需求的满足可能是同步的。
推理模型的出现证明了，Agent效果的提升更多还是需要依赖模型本身而非工程优化，而强化学习对目前模型能力的提升至关重要，但这意味着，模型能够解决好的问题需要处在方便做强化学习的领域，也就是能构建明确可量化评估反馈机制的领域，例如数学、编程等，那些难以构建低成本结果验证器的方向，还难以有好的效果。当然，强化学习可以发挥作用的不仅是答案本身，获取答案所需的每个关键行为也是训练对象，所以确保推导结果的步骤准确，对最终结果可能也是有意义的。无论如何，依赖人工构建的workflow，做知识嵌入和工程硬编码规则，不会是未来Agent的实现方式，通过强化学习等手段，让Agent具备自主探索和解决问题的能力才更值得期待。
前段时间看一篇Anthropic CPO专访，有段话让我深有感触：
“有些创业者在特定领域碰壁多年，无论是在帮助人们编写代码、进行法律分析，还是在医疗保健等领域。他们可能拼凑（用「拼凑」可能有点轻描淡写了，应该说是精心组装）了一套方案，其中可能涉及多种工具。但这套方案要么价格上没有竞争力，因为它需要使用 Opus 级别的高端模型，而这又无法得到底层业务的支持。但即使如此，这些努力仍然是有价值的，因为当更强大的模型出现时，你就不是从零开始了。通常，那些从模型代际升级中获益的公司，并不是那些在模型发布当天才突然起步的公司，而是那些一直在该领域深耕的公司。 以 Cursor 为例，有人给我展示了 Cursor 创始人在 Hacker News 上提交的帖子列表，他们最终取得了突破，但这并非他们的第一个产品或第一次迭代。他们一直在尝试和努力，时间可能不短。所以，他们的成功并非仅仅由模型的快速进步所驱动，而是建立在背景知识、经验积累以及对该领域痛点和成功经验的理解之上，从而让模型能够真正发挥作用。所以，更简洁地说，不要等待模型变得完美，而要积极探索这个领域，对当前模型的局限性感到沮丧，然后积极尝试下一代模型。这样，你就能感觉到，你终于可以实现你脑海中构想的东西了，只要模型再强大一点点。”
现在踩的坑，或许是通向未来成功的路，共勉。
