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

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

2025年被称为Agent元年，集团内外“涌现”了非常多的智能体框架，涵盖大模型Agent的方方面面，包含workflow编排、工具集成（MCP）、memory管理等，更有CrewAI、MetaGPT这样的多Agent解决方案。通过广泛评估和调研，我们最终决定选择轻度“耦合”spring-ai-alibaba来构建商品域Agent应用。毕竟在集团成熟的Java生态下，新的技术栈势必带来更多的额外复杂度，可维护性差并且与现有系统的集成难度显著升高。但未来也会向多应用类似微服务的架构演进，引入开源社区丰富的Agent组件如deepeval做评测、deepresearch做事实性验证等。附上在调研阶段，对一些相关框架病结合商品特性做一个的简单对比小结：

架构设计主要围绕以下几个命题来进行：

（1）面对具象的各异的前台业务场景，需要重点建设哪些组件来降低新场景的开发成本。

（2）商品领域知识如何融入大模型调用流程？

（3）要实现成本的最优，我们认为需实时和离线结合使用，那如何设计workflow及其调度 实现在离线处理逻辑一致？

（4）是否能走向实时推理？

结合大模型agent的几个核心（抽象）要素，我们认为Agent的应用架构应该足够简单和灵活，应采用类似大数据处理引擎的视角来看待Agent架构。因此我们将商品 Agent 抽象为两层结构：上层是面向业务场景的 workflow 编排层，下层是统一的能力供给层，两层之间通过抽象的AIFunction接口来交互。

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

AIFunction定义规范

使用agent-sdk中定义的注解@AiFunction进行声明，其中参数使用@AiParam进行标注。AiFunction中包含如下字段：

基础必备字段（最小集合）：这部分字段须统一行业规范，如OpenAI Function Spec中规定的字段名和用途，具备健壮性。

• name ：（可选，默认类/方法名）function唯一标识或显示名

• description ：（必需）一句话能力描述，主要给AI/开发/文档看

• parameters ：不需要必填，可通过反射自动通过@AiParam进行推导

• returns ：（可选）返回值类型/含义说明

• expose ：（可选）默认false，标明当前function是否对外暴露

扩展字段：

• tags ：能力标签，便于多维分组检索，比如 "llm"、"rag"、"tool"、"java2python"、"电商数据"、"memory"

• author ：维护人，便于治理

• sideEffect ：布尔型，是否有副作用（如写库、发消息、变更状态等）

• timeoutMs ：推荐执行超时时间（AI/流程调度友好）

• deprecated ：是否废弃

AIFunction访问规范

function作为整体架构约束，提供workflow、AI自规划两种模式下统一的访问方式会使得架构更统一和完整；但workflow是提前编排好的一组节点，节点内function也是固定的，基于统一入口的调用方式会使得常量或者枚举类泛滥，不好管理。比如下面这样的代码片段：

因此必须在架构SDK层面对此进行约束和改良。我们要求调用function时，必须按照{Registry}.{DomainRegistry}.{FunctionClass}.{FunctionName}的方式进行调用（仿照老IC客户端的模式）。这种方式若人工实现，势必带来很重的负担，每次新增Function都必须去对应的分组中进行手动声明。

因此希望通过lombok的模式，对注解进行编译期扫描，自动生成引用，来完成以下这样的链式调用：

这样在代码层面、编译器、运行期架构拥有一个统一、完整的视图。

AIFunction具体实例

一个典型的function声明如下：

其中返回值AiItemDO对HSF接口返回的ItemDO做了大量精简和字段含义的标注，再通过商品文档知识库的辅助，帮助大模型在ReAct的loop中准确选择工具并得到恰当的解释。

回到前面提到的开发成本的命题，在这样的设计下，新的场景可以快速复用已有的function能力。如“workflow产出的结果也可以使用通用的Repo工具进行context和推理结果的存储（OdpsWriter和在线StorageWriter）。

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

知识库架构图

知识定义

1. 显性事实知识

1. 在商品领域是对“显卡的GPU品牌是XXXX”、“显卡类目同一SPU下不同SKU差异较大”的客观描述。

2. 关键使用场景：运营决策（试跑阶段的数据有效的沉淀一些行业或者品类知识，后续可以用于做类目灰度的优先决策）、prompt增强、数据清洗和标准化

2. 关联情景知识：

1. 这层知识将商品与商品、需求场景连接起来，未来可以考虑与人的关联。如：商品-商品关系、商品-场景。

2. 关键使用场景：主配件

3. 隐性经验知识

1. 知识的顶层，难以被量化，但也最能建立信任和情感连接。通常来源于大量用户的使用经验、专家的评测和品牌的文化沉淀。

2. 关键使用场景：商品卖点、参数说明

知识生产&应用

显性知识生产

显性知识生产链路围绕“类目-属性元信息”构建，整合五类数据源：商品SKU主数据、商品图片（如主图）、外部素材（如小红书笔记和用户评价）、原始商品属性以及人工评测与运营配置，分别输入统计分析模块和LLM理解模块：前者计算填写率、SKU数量、PV对等统计指标，后者从图像和文本中提取属性、识别用户关注点并生成同义词与解释说明；二者输出与人工校验结果共同汇聚为结构化的类目-属性元知识库，包含决策属性重要性、必填性、枚举/输入类型、填写率、TOP值、商品/SKU标识、同义词、客观解释、SKU图上传率、属性覆盖数、平均SKU数、优级SKU占比、属性PV对及单图平均提取属性数等元信息；最终，知识库中的文本字段（如同义词、解释）被向量化存入向量数据库，支持高效语义检索。

c/cp/cpv知识样例：

商品属性名rerank的结果

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

情景知识提取

主配件场景在bad case结果集总结出的知识库中当前在10个类目的近10000条案例中总结出53条规则：

隐性经验知识

V值场景化主观描述，知识样例

SKU智能筛选场景

知识服务

在知识服务体系建设过程中，我们投入了大量精力深入探讨如何高效、灵活地存储和管理多类型知识。面对多样化的知识形态（如结构化元数据、半结构化规则、非结构化文本等），系统不仅需要支持高可靠的知识写入，还需满足多维度动态检索与基于语义的精准召回需求。为此，我们设计并实现了一套统一而可扩展的知识存储模型与服务体系。

该体系对外提供标准化的知识服务接口，包括写入（save） 和 读取（query / count / pageQuery） 核心能力，便于上层业务流程通过函数调用（function）无缝集成。在底层存储架构上，采用两层异构存储策略，兼顾实时性、持久性与语义检索能力：

• MySQL：作为主持久化存储，保障知识数据的强一致性与事务完整性，适用于结构化元信息的长期保存；

• TisPlus：提供批量向量化处理与大规模KV存储能力，适用于离线构建高维索引、深度语义挖掘及历史知识回溯。

通过协同工作，系统既能支撑高频、低延迟的在线知识调用，又能满足复杂语义理解与大规模知识分析的需求，为上层智能应用（AI决策属性排序、筛选&SKU参数提取场景运营决策等场景）提供坚实、灵活且可演进的知识底座。

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

在提示词技术方面，一开始就提供了通过（workflowname，templatekey，version）三元组持久化和读取prompt的function, 开发可以通过不断调休提示词版本，来提升数据产出的质量，同时开发在可以开发工作台低成本的维护提示词。