万级实时推理的商品领域Agent实践思考和总结

• AIFunction：灵活高效可复用

{  "data": [    {      "cateName": "显卡",      "propertyName": "GPU品牌",      "topItemCntValues": [        "NVIDIA/英伟达",        "AMD",        "intel/英特尔",        "凌久",        "丽台"      ],      "definition": "GPU品牌 是指显卡中使用的图形处理单元（GPU）的制造商或品牌，用于标识显卡的核心硬件来源，影响显卡的性能表现、兼容性及驱动支持，常见品牌包括NVIDIA、AMD、Intel等。"    },  ...  ],  "success": true}

[    {        "uuid": "7c2fb326-5226-4185-b7e0-c32219f65936",        "contentRaw": "{\"cate\":\"笔记本电脑\",\"examples\":[\"硬盘容量、内存容量、1TB等规格多次标记为N\",\"全国联保、外设等属性类描述不被接受为配件\"],\"specially\":[\"所有容量和规格类描述均无合理配件案例，需严格排除\"],\"standard_info\":\"商品属性和规格如容量大小不应作为独立配件，应视为主商品的固有属性。\",\"standard_name\":\"笔记本电脑属性规格排除规则\"}",        "customConfig": {            "cate": "笔记本电脑"        },    },  ...]

{    "core_scenario": "为现代家庭客厅提供兼具美观、实用与空间适配性的茶几选择，满足不同户型、风格偏好与收纳需求的用户对品质生活的追求。",    "structured_filters": [        {            "attribute_name": "长度",            "knowledge_needed": true,            "values": [                {                    "value_name": "1.2米",                    "scenario_translation": "小户型优选，节省空间不拥挤。"                },                {                    "value_name": "1.4米",                    "scenario_translation": "适合两人沙发，比例协调显精致。"                },                {                    "value_name": "1.6米",                    "scenario_translation": "适配三人沙发，日常使用刚刚好。"                },                {                    "value_name": "1.8米",                    "scenario_translation": "大客厅标配，摆茶具零食更从容。"                },                {                    "value_name": "2.0米",                    "scenario_translation": "宽敞客厅之选，聚会待客有面子。"                },                {                    "value_name": "2.2米",                    "scenario_translation": "大平层理想尺寸，气场十足显档次。"                },                {                    "value_name": "2.4米",                    "scenario_translation": "别墅客厅优选，搭配L型沙发更和谐。"                },                {                    "value_name": "2.6米",                    "scenario_translation": "超大空间专属，彰显大气家居格调。"                },                {                    "value_name": "2.8米",                    "scenario_translation": "豪宅级配置，打造客厅视觉焦点。"                }            ]     ...        }    ]}

后面在对不同workflow的长期调优过程中，我们总结出了几种最常用且有效的提示词使用技术，即架构图中体现的几种：长prompt拆分后的分步推理、单prompt循环执行、并行推理&统计+总结等。这几种不同的推理流程在sdk中使用不同类型的Action节点来支持，如Map节点、Reduce节点、Loop节点等。这些宝贵的实践，主要由我们年轻的实习小师弟们在实习阶段的实验场景：

为什么旧架构采用上述模式？这主要受限于当时的技术条件与工程能力。具体原因有三：首先，彼时缺乏成熟的在离线一体化数据处理框架，难以统一支撑实时与批量场景；其次，大模型的实时推理成本高、响应延迟（RT）较长，且在线服务通常设有严格的 QPS 限流，难以满足高并发实时需求，因此业界普遍采取“先离线、后实时”的演进路径；最后，业务尚处于探索阶段，亟需快速验证大模型能否带来实际价值。基于上述背景，我们优先构建了基于 ODPS 离线节点与批量推理平台（Omega）的离线推理链路

随着业务发展，我们在 2024 年探索大模型与业务融合的过程中，逐步暴露出原有链路的若干关键问题：

1. 数据处理复杂且维护成本高：批量推理的核心工作量集中在输入/输出数据的加工、解析（如复杂 SQL、UDF）以及离散离线节点的编排与调度。复杂的 SQL 可读性差，离散节点难以统一管理；同时，受上游数据延迟、大促期间资源紧张等因素影响，任务调度稳定性难以保障。

2. 流程扩展性与灵活性不足：面对复杂推理场景（如多轮迭代推理、多模型对比、推理后追加评测子流程等），现有“离线节点 + Omega”模式难以灵活支持，即使勉强实现，也因逻辑耦合、缺乏抽象而难以长期维护。

3. 推理调度存在不确定性：批量任务依赖共享资源池，易受资源争抢影响，导致任务延迟或产出不稳定。虽可申请独占 GPU 资源，但按卡粒度分配易造成资源浪费（申请过多）或处理效率低下（申请不足），最终仍被迫回归共享模式，陷入两难。

4. 在线与离线体系割裂：当前在线与离线采用完全独立的两套技术栈，代码、调度、推理逻辑各自维护。不仅带来高昂的重复开发与维护成本，更难以保证两者在数据处理逻辑上的一致性，严重影响迭代效率与结果可靠性。

针对上述问题，我们在 2025 年通过构建一套更工程化、统一化的智能体（Agent）驱动架构，系统性地实现了在线与离线推理的深度融合与高效协同。

业务实现在离线统一的方式有多种，例如可借助支持在离线一体的流程编排平台。但综合考虑业务逻辑的复杂性、未来对 Agent 扩展能力的需求，以及对全流程更高透明度和可控性的要求，我们最终选择通过更工程化的方式来实现在线与离线统一的处理。具体而言，我们基于 Spring AI Agent 将业务流程的复杂步骤封装为一个 Workflow，向上屏蔽触发源的差异（如定时调度 vs 实时事件），向下屏蔽计算资源的差异（如单机执行 vs 分布式集群），从而在代码、部署、推理资源和存储层面实现真正的统一。

在核心逻辑层面，我们实现了组件化与标准化：将业务处理过程抽象为三个标准化组件——Function（原子能力）、Action（业务动作）和 Workflow（流程编排）。所有业务逻辑，无论在线还是离线，均封装在同一个“统一工作流”中，由统一的编排服务驱动。这不仅实现了业务逻辑的集中管理，还彻底解耦了原本散落在不同代码库或平台中的实现。同一套代码既能支撑批量跑批，也能处理实时请求，显著提升了复用性与一致性。

在触发机制上，架构设计支持两种入口模式：一是离线批量推理，由调度任务触发，输入为实体 ID 列表，适用于大规模、非实时的存量数据处理；二是在线增量推理，由实时事件（如商品信息变更）驱动，适用于低延迟、高时效的增量更新场景。两种模式共享同一套工作流逻辑，仅入口不同，真正实现“一套逻辑，多端适配”。

为应对离线场景下的高吞吐需求，Agent 应用内部实现了通用的分布式数据处理能力。基础 Function 支持并行化与分片处理，Workflow 可根据负载动态调整批量处理的并发度与吞吐量，确保离线任务高效稳定执行。

在结果存储方面，我们实现了统一的写入机制：无论是离线还是在线调用，均由统一的存储写入 Function 负责。该机制支持将结果写入 MySQL/，供在线业务系统进行低延迟查询；同时可支持同步落盘至 ODPS，支撑离线数仓分析。双写操作由统一工作流协调，确保数据语义一致、链路可追溯。

通过上述设计，我们不仅实现了在线与离线 AI 推理的深度融合，也为未来引入多 Agent 协作、动态决策等高级能力沉淀了丰富的可复用原子业务组件，为系统长期演进奠定了坚实基础。

• AI生产数据质量评测体系

基于商品侧知识，利用AI实现商品与导购供给的智能化理解（特征识别、属性理解、场景导购等），目标是高质量、规模化、实时化地产出数据。面临挑战包括数据质量、规模化成本、实时性、资源瓶颈、置信度、离线与实时不一致及合规问题。为此，工程和测试同学一起，基于agent应用，构建一套可量化、可归因、可复现的属性摘要大模型自动化评测系统，科学评估新版数据的效果，评测系统流程如下：

评测归因后的可视化图	运营也可以针对单品或者线上badcase进行定向实时评测，帮助判断

基于商品领域agent生产的数据，通过saro+RDS的存储方案，可以通过调用ic现有的商品查询接口，但需要指定的特殊参数；在搜推广场景，我们也提供相应的tpp和saro能力，可以支持不同的场域或者应用链路接入；当然也接受业务侧自行生产的数据通过ic链路进行投放，下游进行消费。目前投放侧，也有一些投放策略进行选择，如query联动、字段优先级等。

• 事务型商品领域事件：实时推理的关键

在主搜SKU化的背景下，商品的存储模型复杂和迭代给ETL链路增加了理解成本和实施成本，与此同时从商品行到SKU行的变更（从万/s上升到数十万/s）处理给ETL链路带来了巨大的性能和成本的挑战。为了解决前者问题，FY25通过saro平台构建了SKU引擎1.0版本，主搜dump不再直接拉商品数据库GALICDB，而是通过saromirror的形式进行交互，IC内部完成存储模型到导购商品或者sku引擎数据字段的加工和处理。

但不管是saro还是精卫这样的数据通道，为上层提供的都是数据表+行变更的视角。而在商品域商家或者平台一次操作往往涉及多个数据表间的事务操作，会造成量级本身的放大；此外多表间特定字段的变更往往在应用层存在一定的链路或模型约束，如A表A1字段变更一定伴随B表B1字段变更，在数据表视角下这类变更需要频繁使用多表JOIN来计算最终结果，进一步加大了计算量（在saro链路上多表join由于A表B表两个字段会单独变更，因此会触发2次JOIN，造成进一步放大）。

为此，今年6月份我们升级了SKU引擎架构，通过将SKU变更降维到商品事务维度，作为ETL链路的数据底座，同时作为商品Agent推理的驱动源。我们在精卫链路设计并实现了基于商品ID+事务ID进行数据行变更聚合并转发的事务消息链路。精卫任务中只处理并发送下游关注字段（或模型）的事务消息，将秒级别最终要处理的事务量级降低了一个数量级；下游使用Java应用消费消息并补全数据，最终落到一张以经过增强的全局唯一skuId为主键的异构sku数据表，这张数据表直接DUMP到saro链路无须额外处理即可作为完整的sku数据供搜索消费。以上两步分别消除了一次操作到多行变更的放大和多行变更间的JOIN计算，因此具备极好的性能和低成本；

商品Agent应用进展

商品Agent已在商品属性、卖点等多个核心业务场景完成落地，覆盖亿级在线商品，显著提升了商品信息的完整性、准确率与丰富性，并在搜索、详情等核心导购场景中实现了成交转化率的正向提升。

在研发效能层面，面向数据流处理的商品Agent基础框架已全面搭建完成，具备较强的能力复用性与快速扩展能力。新业务需求到来时，开发团队仅需一周/人的时间即可完成能力开发、数据试跑及评测结果优化等全流程工作，大幅压缩了从需求到前台实验的交付周期，助力业务以更快的节奏在前台场景完成验证与迭代。

总结

通过25年一个季度对商品域Agent的探索与建设，我们初步验证了将大模型能力以结构化、工程化方式嵌入商品数据生产链路的可行性与价值。从底层事务驱动的数据引擎升级，到轻量Agent架构设计，再到多个核心业务场景的成功落地，商品Agent已展现出从“单点提效”向“系统自治”演进的巨大潜力。

展望未来，Agent技术正以前所未有的速度迭代演进，Harness、Skill等新一代Agent框架与范式的持续涌现，为商品域的智能化建设打开了全新的想象空间。我们正积极拥抱这些前沿技术，将其与商品域的实际业务场景深度融合：以更强的语义理解能力让Agent真正"读懂"商品的深层含义，以Skill模块化的方式沉淀和复用商品域的专业领域知识，以商品理解"大脑"为核心构建自适应决策机制，实现对商品信息的主动感知与动态更新。我们相信，持续夯实"数据+工具+知识+决策"四位一体的Agent基础设施，在拥抱技术浪潮中驱动能力持续跃迁，让系统真正读懂每一件商品、理解每一位消费者，驱动电商导购体验进入“主动理解、精准表达、高效决策”的新阶段。