商品领域Agent实践：万级实时推理的架构与经验总结

首页

AI资讯

热心网友

转载

2026-05-27

面对海量商品信息的实时处理与智能化需求，如何构建一个既能支撑亿级规模、又能将新需求开发周期压缩到一周的系统？这不仅是技术挑战，更是工程架构设计的艺术。今天，我们就来深入拆解商品域如何通过一套“事件驱动的Function-Centric Agent”架构，实现从离线到实时、从单点提效到系统自治的关键跃迁。

为应对AI化带来的挑战，商品域在过去几年构建了一套全新的架构体系。其核心是一个两层设计：上层是面向具体业务场景的Workflow编排层，负责灵活组合业务流程；下层则是统一的能力供给层，通过标准化的AIFunction封装各类工具与领域知识。这套系统整合了显性事实、关联情景和隐性经验三类商品知识库，不仅统一了离线与在线的业务流程，更基于商品事务事件实现了高效的实时推理。目前，该架构已在商品属性、卖点等核心场景落地，覆盖亿级商品，显著提升了信息完整性与搜索转化率，并将新需求的平均开发周期缩短至每人每周，为商品智能化迈向“系统自治”奠定了坚实基础。

结合Agent这一技术趋势，搭建商品领域Agent被视为实现智能化跃迁的关键。这不仅是技术架构的升级，更是对商品数据生产与消费范式的重构。因此，在过去一个季度，商品中心围绕“商品Agent”展开初步建设，核心目标是将大模型能力以可控、可集成的方式嵌入商品生命周期链路，重点提升搜索与详情页中参数、摘要等信息的智能化水平，从而为消费者呈现更清晰、一致、可比的信息，辅助其高效决策。

商品Agent架构建设

落地一个面向具体业务领域的AI Agent，远不止“接入大模型+写Prompt”那么简单。要真正实现其可用、可靠、可提效、可运维，需要系统性地完成一系列工程化工作。

框架选型

2025年堪称Agent元年，集团内外涌现了大量智能体框架，覆盖了工作流编排、工具集成、记忆管理等方方面面。经过广泛评估，我们最终选择了与Spring AI Alibaba进行轻度耦合来构建商品域Agent应用。原因在于，在集团成熟的Java生态下，引入全新的技术栈往往会带来额外的复杂度、可维护性挑战以及与现有系统的集成难度。当然，未来架构也会向多应用、微服务化的方向演进，并计划引入开源社区丰富的Agent组件，如用于评测的deepeval、用于事实性验证的deepresearch等。

架构设计

整个架构设计主要围绕几个核心命题展开：如何降低各异的前台业务场景开发成本？如何将商品领域知识融入大模型调用流程？如何设计工作流以实现离线与在线处理逻辑的一致与成本最优？以及，最终能否走向实时推理？

基于对大模型Agent核心要素的思考，我们认为其应用架构应当足够简单和灵活。因此，我们采用了一种类似大数据处理引擎的视角，将商品Agent抽象为两层结构：上层是面向业务场景的Workflow编排层，下层是统一的能力供给层，两层之间通过抽象的AIFunction接口进行交互。

我们希望底层通过AIFunction对各类工具和领域知识进行标准化封装，向上提供结构清晰、语义明确、调用稳定的函数接口，从而支撑上层灵活、高效地构建智能流程。为此，我们也开发了轻量的aiagentsdk，提供一组简洁易用的注解，如@AIWorkflow、@AIAction、@AIFunction等。在这些注解和切面的增强下，所有Function都能轻松转换为一组高质量的MCP工具，供问答型Agent自由调用。

AIFunction：灵活高效可复用

AIFunction定义规范

使用agent-sdk中定义的@AiFunction注解进行声明，参数使用@AiParam标注。其中包含基础必备字段和扩展字段：

基础字段：如name（函数标识）、description（能力描述，必需）、parameters（参数）、returns（返回值说明）、expose（是否对外暴露）。
扩展字段：如tags（能力标签）、author（维护人）、sideEffect（是否有副作用）、timeoutMs（执行超时时间）、deprecated（是否废弃）。

AIFunction访问规范

为了让架构更统一，Function需要提供Workflow和AI自规划两种模式下的统一访问方式。为了避免常量或枚举类泛滥，我们在SDK层面对调用方式进行了约束和改良，要求必须按照{Registry}.{DomainRegistry}.{FunctionClass}.{FunctionName}的链式方式进行调用（仿照老IC客户端模式）。通过编译期注解扫描自动生成引用，最终实现类似registry.item().query().invoke(params)的优雅调用，在代码、编译器和运行期保持统一的视图。

AIFunction具体实例

一个典型的Function声明如下：

public interface ItemQuery {
    String QUERY_AI_ITEM_BY_ID = "queryAiItemById";
    @AiFunction(name = QUERY_AI_ITEM_BY_ID,
        description = "查询商品信息",
    expose = true)
    @AiResult(description = "商品数据")
    AiItemDO queryAiItemById(@AiParameter(name = "itemId", description = "商品ID") Long itemId);
}

其中，返回值AiItemDO是对HSF接口返回的ItemDO做了大量精简和字段含义标注后的对象，再结合商品文档知识库的辅助，能有效帮助大模型在ReAct循环中准确选择工具并理解结果。在这样的设计下，新场景可以快速复用已有的Function能力，例如Workflow产出的结果也可以使用通用的Repo工具进行上下文和推理结果的存储。

商品领域知识库：从定义、生产到服务

知识定义

显性事实知识：描述商品的客观事实，如“显卡的GPU品牌是XXXX”。关键使用场景包括运营决策、Prompt增强、数据清洗和标准化。
关联情景知识：连接商品与商品、商品与场景的关系，例如商品-商品、商品-场景关联。关键使用场景如主配件推荐。
隐性经验知识：难以量化但能建立信任和情感连接的知识，通常来源于大量用户经验、专家评测和品牌文化沉淀。关键使用场景如商品卖点、参数说明。

知识生产与应用

显性知识生产：链路围绕“类目-属性元信息”构建，整合商品SKU主数据、图片、外部素材、原始属性、人工评测五类数据源，通过统计分析和LLM理解模块，最终产出结构化的类目-属性元知识库，文本字段向量化后存入向量数据库。

情景知识提取：以主配件场景为例，从近万个Bad Case中总结出53条规则，形成情景知识库。

隐性经验知识：例如在SKU智能筛选场景中，为茶几的“长度”属性不同值赋予场景化描述，如“1.2米：小户型优选，节省空间不拥挤。”，将冷冰冰的参数转化为有温度的生活场景解读。

知识服务

为了高效、灵活地存储和管理多类型知识，我们设计了一套统一可扩展的知识存储模型与服务体系。对外提供标准化的写入和读取接口。底层采用MySQL和TisPlus两层异构存储策略：MySQL保障强一致性与事务完整性；TisPlus提供批量向量化处理与大规模KV存储能力，支撑高频在线调用与复杂语义检索，为上层智能应用提供坚实的知识底座。

提示词工程：经验沉淀为模版

在提示词技术方面，系统从一开始就提供了通过（workflowName, templateKey, version）三元组持久化和读取Prompt的Function。开发者可以通过不断调整提示词版本来提升数据产出质量，并在开发工作台低成本地维护提示词。

在对不同Workflow的长期调优过程中，我们总结出了几种最常用且有效的提示词使用技术，即架构图中体现的几种：长Prompt拆分后的分步推理、单Prompt循环执行、并行推理与统计总结等。这些不同的推理流程在SDK中通过不同类型的Action节点（如Map节点、Reduce节点、Loop节点等）来支持。这些宝贵的实践，很大程度上得益于团队在实习阶段的探索与积累。

AIWorkflow：在离线业务流程统一

旧架构实现与问题

早期的架构受限于技术条件，普遍采用“先离线、后实时”的路径。原因有三：缺乏成熟的在离线一体化框架；大模型实时推理成本高、延迟长、QPS受限；业务处于探索期，需要快速验证价值。因此，优先构建了基于ODPS离线节点与批量推理平台的离线推理链路。

随着业务发展，原有链路暴露出诸多问题：数据处理复杂、维护成本高；流程扩展性与灵活性不足；推理调度存在不确定性；以及在线与离线体系割裂，两套技术栈导致高昂的重复开发和维护成本，且难以保证逻辑一致性。

新架构的实现

针对上述问题，我们通过构建更工程化、统一化的Agent驱动架构，系统性地实现了在线与离线推理的深度融合。

在核心逻辑层面，我们将业务处理抽象为三个标准化组件：Function（原子能力）、Action（业务动作）和Workflow（流程编排）。所有业务逻辑，无论在线离线，都封装在同一个“统一工作流”中，由统一的编排服务驱动，实现了业务逻辑的集中管理与彻底解耦。

在触发机制上，架构支持两种入口：离线批量推理（由调度任务触发，处理存量数据）和在线增量推理（由实时事件驱动，处理增量更新）。两种模式共享同一套工作流逻辑，真正实现“一套逻辑，多端适配”。

为应对离线高吞吐需求，Agent应用内部实现了通用的分布式数据处理能力。在结果存储方面，设计了统一的写入机制，确保数据可同时写入在线存储和离线数仓，保障数据语义一致与链路可追溯。

AI生产数据质量评测体系

基于商品侧知识，利用AI实现商品智能化理解的目标是高质量、规模化、实时化地产出数据。面临的挑战包括数据质量、成本、实时性、资源瓶颈、置信度等多方面。为此，我们基于Agent应用，构建了一套可量化、可归因、可复现的自动化评测系统：

实现新老版本数据的AB对比评测；
利用大模型进行语义理解与多维度打分（准确性、完整性、可读性、一致性等）；
支持按不同评测场景配置打分规则集；
建设可持续的数据搜索与评测链路，并通过可视化支撑决策优化与问题归因。


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

数据投放链路：低成本接入消费

基于商品领域Agent生产的数据，通过Saro+RDS的存储方案，可以通过调用现有的商品查询接口（需指定特殊参数）进行消费。在搜推广场景，也提供了相应的TPP和Saro能力，支持不同场域或应用链路接入。同时，也支持业务侧自行生产的数据通过IC链路进行投放。目前投放侧提供了一些投放策略供选择，如Query联动、字段优先级等。

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

在主搜SKU化的背景下，商品存储模型复杂，ETL链路面临理解成本与性能成本的双重挑战。FY25通过Saro平台构建了SKU引擎1.0，但Saro或精卫这类数据通道提供的是数据表+行变更的视角。商家一次操作涉及多表事务，会造成变更量级放大，且多表间字段变更存在链路约束，需要频繁JOIN计算，进一步加剧了负担。

为此，今年6月我们升级了SKU引擎架构，将SKU变更降维到商品事务维度，作为ETL链路的数据底座和商品Agent推理的驱动源。我们在精卫链路设计并实现了基于商品ID+事务ID进行数据行变更聚合并转发的事务消息链路，将秒级需处理的事务量级降低了一个数量级。下游应用消费消息并补全数据，最终落到一张以增强型全局唯一SKU ID为主键的异构数据表，直接供搜索消费。这两步分别消除了操作到多行变更的放大效应和多行变更间的JOIN计算，具备极佳的性能和低成本优势。

同时，我们获得了实时的SKU素材（属性文本、图片等）和商品基础信息变更驱动源，为商品实时Agent打下了坚实基础。目前，商品Agent已通过事务型商品领域事件搭建了多个业务场景的实时推理能力。

应用分层

商品Agent系统采用高度模块化、分层解耦的架构设计：

客户端层（item-agent-client）：以轻量级SDK形式定义对外标准化能力。
服务层：包含三个模块：
- agent-server：封装核心领域业务逻辑。
- item-agent-instances：按业务场景拆分的具体Agent实例实现。
- item-agent-evaluation-client：专注于效果度量与A/B测试。
功能层（item-agent-functions）：提供Agent可调用的原子能力和业务能力。
SDK层（item-agent-sdk）：抽象出统一的调用契约。
公共模块：
- 事件引擎层（item-agent-event-engine）：负责异步消息与事件驱动。
- 管理后台层（item-agent-admin）：提供运维管控与人工干预能力。

部署架构

SKU引擎分组：处理商品领域事件，将商家侧的商品粒度信息转换为前台导购所需的SKU粒度，需重点保障。
LLM分组：承担基于不同业务场景的大模型实时/离线推理核心职能，并支持大模型评测任务。
服务分组：采用读写分离+单元化架构实现Agent数据的高效写入和投放。
- 写服务：以张北中心为唯一写入节点，确保数据写入的集中管控与容灾。
- 读服务：按单元化流量部署，通过分布式缓存和单元化读缓存链路，实现低延迟数据访问与最终一致性。

小结

相较于引入功能完备但复杂的Agent框架，我们更倾向于拥有一个“恰好够用”且负担轻的SDK。这样的SDK仅需极短的开发周期即可完成。至此，我们初步搭建完成了以“事件驱动的Function-Centric Agent架构”。

商品Agent应用进展

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

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

总结

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

展望未来，Agent技术正以前所未有的速度迭代演进。我们正积极拥抱Harness、Skill等新一代Agent框架与范式，将其与商品域的实际业务场景深度融合：以更强的语义理解能力让Agent真正“读懂”商品，以Skill模块化的方式沉淀和复用领域知识，以商品理解“大脑”为核心构建自适应决策机制。我们相信，持续夯实“数据+工具+知识+决策”四位一体的Agent基础设施，将驱动电商导购体验进入“主动理解、精准表达、高效决策”的新阶段。

来源:https://www.53ai.com/news/LargeLanguageModel/2026052564897.html

免责声明：游乐网为非赢利性网站，所展示的游戏/软件/文章内容均来自于互联网或第三方用户上传分享，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系youleyoucom@outlook.com。

上一篇：留神峪矿难警示：空地一体化如何重塑矿山智能安全体系下一篇：SEO老兵转型GEO新人的真实经历与自白