AI商品发现开放协议：从意图解析到推荐理由的标准化设计

AI-mediated product discovery，也就是由AI介入的商品发现过程，最近讨论度很高。很多人第一反应是“再训一个推荐模型”，但实际落地时你会发现，真正的瓶颈往往不在算法，而在数据怎么进、意图怎么传、结果怎么回。这也是我越来越关注开放协议的原因：把商品发现这件事从各平台私有接口里解耦出来，让商品供给、用户意图和AI Agent之间按同一套规则对话。

这篇内容会围绕一个核心问题展开：如果要做一个“AI辅助商品发现”的开放协议，需要定义哪些东西、怎么跑通最小版本、怎么评估效果、哪些坑必须提前避开。我不打算讲一个很虚的架构图，而是按实际落地顺序拆开讲：先从场景和角色入手，再给数据模型和交互流程，最后落到部署、排查和工程化扩展。文章里给的协议字段和接口形态是示意设计，用来演示如何搭建，不代表某个已成型的标准。

1. 先想清楚：AI商品发现需要协议解决什么问题

1.1 现有推荐系统的三个断点

目前大多数商品推荐链路是这样的：用户在平台上产生行为数据，平台把这些行为喂给模型，模型输出一个Top N列表，用户在列表里选商品。这套逻辑在单平台内很成熟，但只要把“发现”这件事放到更多场景里，就会暴露出断点。

第一个断点是商品数据格式不统一。同一个商品，在平台A叫“SPU ID”，在平台B叫“item_code”，描述里有的带材质、有的不带。AI模型接收这些数据时，只能靠临时写转换脚本去对齐字段，一换数据源就崩。

第二个断点是用户意图没有统一载体。用户在搜索框里输入“适合长时间办公的无线键盘”，这个请求要传递到推荐系统、库存系统、排序模型、归因模块。每个模块都按自己的方式理解“长时间办公”，有的只抽关键词，有的只看价格带，有的压根不处理语义，结果就是召回和用户真实需求对不上。

第三个断点是推荐结果不可解释、不可回退。很多推荐接口只返回一个商品ID列表，用户侧展示“猜你喜欢”，但追问一句“为什么推荐这个”，系统答不上来。如果换成AI Agent来导购，Agent需要对用户负责，它至少要能把推荐理由说清楚。没有标准化的原因结构，这件事就很难做。

开放协议要解决的，就是把这三个断点统一掉：商品数据怎么描述、用户意图怎么表达、推荐结果怎么返回，都定出公共规则。

1.2 开放协议和平台私有接口的差异

平台私有接口的特点是：责任边界清楚、权限控制严格、性能容易优化，但接入成本高、跨平台迁移难。一个AI Agent要同时对接五个电商平台，就得写五套客户端、处理五种字段命名、适配五种错误码。

开放协议并不是要推翻私有接口，而是在私有接口之上或之外定义一套公共语义层。它不负责某个平台的鉴权细节，只负责把“一次商品发现请求”和“一次商品发现响应”用统一格式说出来。

实际差异可以看这几个维度：

这里要说明，开放协议不是银弹，它解决的是“协同”问题，不解决“推荐效果”问题。协议再完善，底层模型没训练好，商品池质量不行，返回结果照样不靠谱。

1.3 这个协议适合谁用

我理解最需要这套方案的场景有三类。

第一类是电商产品和后端开发。如果你们在做跨平台比价、多店铺选品、导购Agent，那统一的数据模型和接口格式能省掉大量重复适配工作。

第二类是AI应用开发者和产品经理。当你要做一个“AI帮你选商品”的Agent时，你不需要从零设计整套商品数据结构和推荐结论格式，直接参考协议里的意图对象、候选结果和推荐理由结构，能少踩很多格式坑。

第三类是独立站和小型平台。没有足够资源维护复杂推荐中台的时候，用开放协议定义清楚输入输出，后面无论换召回策略还是换排序模型，影响面都可控。

一句话总结：如果你只是做一个静态商品列表页，不需要协议；但只要你打算让AI Agent来“帮用户找商品”，并且希望这个能力不绑死在单一平台上，就应该从一开始就把协议层设计出来。

2. 协议设计：核心角色、数据模型和交互流程

2.1 核心参与角色

一个AI商品发现协议里，至少要区分四个角色。

商品供给方负责提供商品信息，可能是电商平台、品牌方、独立站或者线下门店系统。它们需要把自己的商品库映射到协议定义的商品模型上。

发现服务是整个协议的核心处理器，负责接收用户意图、召回候选商品、排序、生成推荐理由。它不一定是单一服务，可以是召回集群加排序模型加规则引擎的组合。

AI Agent是用户侧的智能助手，它负责把用户口语化需求解析成结构化意图对象，然后向发现服务发起请求，再把结果组织成自然语言回复。这里也可以统一叫导购Agent或智能体。

最终用户是真实的消费者或选品业务人员。他们不直接关心协议字段，但所有设计都得围绕他们的需求质量和体验来定。

建议在实现时，每个角色都要有明确的接入标识。比如用角色字段区分请求来源是Web端、App端还是Agent，这对后续做流量分析和限流都有用。

2.2 商品描述与意图描述的标准化

协议里最基础也是最容易做错的部分，就是商品对象和意图对象。

商品对象不能只有标题、价格、图片这几个字段。为了支撑AI召回和解释，至少要包含以下信息：

• product_id：商品唯一标识
• title：商品标题
• description：商品详细描述
• category_tree：类目路径，比如“数码 > 电脑外设 > 键盘”
• attributes：规格属性，键值对结构，比如“轴体: 红轴”
• price：价格
• currency：币种
• availability：库存状态
• image_urls：图片地址列表
• tags：扩展标签，用于补充运营信息

意图对象比商品对象更容易被忽略。很多推荐失败不是因为模型不好，而是因为用户意图没有被结构化表达。建议至少包含四个部分：

• query：用户原始文本
• constraints：硬性约束，比如价格上限、品牌白名单、发货时间
• preferences：软性偏好，比如喜欢紧凑布局、偏好静音
• context：场景信息，比如办公、旅行、送礼

硬性约束和软性偏好的区别很重要。硬性约束是“不满足就不行”，比如预算不能超过800元；软性偏好是“满足更好，不满足也可以”，比如更偏向某个颜色。协议里如果不区分这两类，排序模型很容易把硬性约束当成普通加权因子，结果就是用户说“不要超过800”，系统推荐了一个900元的商品。

2.3 一次完整的产品发现会话流程

一次标准流程可以分成六步。

第一步，用户表达需求。用户说“帮我找一款适合办公的静音键盘，预算800以内”。

第二步，AI Agent解析意图。Agent把这句话转成意图对象，query保持原文，constraints里写入价格上限800，preferences里写入“静音、办公、机械键盘”。

第三步，Agent向发现服务发起请求。请求里带上意图对象、需要返回的商品数量、排序策略等。

第四步，发现服务召回候选商品。召回阶段可以同时用关键词、向量语义、属性过滤等多种方式，先把候选集缩到几百条以内。

第五步，排序和生成推荐理由。排序模型对候选商品打分，规则引擎或大模型根据命中的硬约束和软偏好生成可读理由。

第六步，返回结果。响应里要包含request_id、商品列表、每个商品的score和reasons，如果发现意图不明确，还可以返回是否需要澄清。

关键点在于，整个会话要有request_id贯穿。后续用户点了哪个商品、有没有加购，都要通过request_id和product_id回传，形成反馈闭环。

2.4 接口交互示例

下面给一个示意格式，方便看清楚字段风格。

请求示例：

{ "request_id": "req_20240601_001", "agent_id": "agent_office_guide", "intent": { "query": "适合长时间办公的无线机械键盘", "constraints": { "price_max": 800, "currency": "CNY", "brands": ["Keychron", "Logitech"] }, "preferences": { "layout": "compact", "key_type": "quiet" }, "context": { "scene": "office", "user_profile": { "preferred_attribute": "red_switch" } } }, "config": { "top_k": 10, "strategy": "balanced", "need_reasons": true } }

响应示例：

{ "request_id": "req_20240601_001", "code": 0, "message": "ok", "items": [ { "product_id": "p_1001", "title": "Keychron K3 Pro 无线机械键盘", "price": 699, "currency": "CNY", "score": 0.92, "reasons": [ "价格在预算范围内", "紧凑布局符合偏好", "支持静音红轴，适合办公场景" ] } ], "session": { "clarification_needed": false, "suggested_next_questions": [] } }

接口设计上，我建议走HTTP POST，路径里带版本号，比如POST /v1/discovery/request。响应里所有业务结果都放在外层结构内，HTTP状态码只表示请求本身是否成功，不和业务逻辑强绑定。

3. 搭建最小可运行版本

3.1 环境与前置条件

这个协议的最小版本并不需要很大的硬件投入。我建议先用一台普通开发机来做验证，不一定要GPU。

基础依赖可以按这个思路准备：

• Python 3.10或更高版本
• FastAPI作为接口框架
• Uvicorn作为本地服务进程
• 一个向量Embedding模型，用于语义召回
• 一个轻量向量检索方式，数据量小的时候用numpy计算相似度也能跑

如果你的机器配置不高，或者不想引入大模型，可以先用规则加关键词做一版。比如“预算800以内”解析成价格上限，“静音”映射到属性标签，关键词命中就进候选池。这个方案召回效果未必好，但能先把协议链路跑通。

3.2 准备商品样本数据

不要一开始就接全量真实数据，我建议先准备20到50条商品样本，字段按照协议里的商品对象来整理。

每条商品至少要有以下字段：

{ "product_id": "p_1001", "title": "Keychron K3 Pro 无线机械键盘", "description": "矮轴机械键盘，支持蓝牙和有线双模，适配Windows和macOS", "category_tree": ["数码", "电脑外设", "键盘"], "attributes": { "layout": "compact", "key_type": "quiet", "connection": "wireless" }, "price": 699, "currency": "CNY", "availability": "in_stock", "image_urls": [], "tags": ["办公", "静音", "无线"] }

这个阶段的目的不是追求商品数量，而是验证你的协议字段够不够用。比如你发现用户说“无线”时，attributes里存的却是“connection: wireless”，那你需要在意图解析和属性映射之间做一层转换，这就是协议要解决的问题。

3.3 实现协议核心

最小版本里可以只用三个接口：

• POST /v1/discovery/request 处理发现请求
• POST /v1/discovery/feedback 回传用户反馈
• GET /v1/health 健康检查

核心逻辑可以拆成四个函数：意图解析、候选召回、排序、理由生成。这里给一个Python风格示意，不是完整可跑代码，但结构很有参考价值。

def parse_intent(raw_payload: dict) -> Intent: # 从请求体里提取结构化意图 intent = Intent( query=raw_payload["intent"]["query"], constraints=raw_payload["intent"].get("constraints", {}), preferences=raw_payload["intent"].get("preferences", {}), context=raw_payload["intent"].get("context", {}) ) return intent def recall_candidates(intent: Intent, product_pool: list[Product]) -> list[Product]: # 先用硬性约束过滤，再做语义召回 filtered = [p for p in product_pool if check_constraints(p, intent.constraints)] return semantic_recall(intent.query, filtered, top_k=50) def rank_items(candidates: list[Product], intent: Intent) -> list[RankedItem]: # 基于偏好和场景信息打分 scored = [score_product(p, intent) for p in candidates] return sorted(scored, key=lambda x: x.score, reverse=True)[:10] def generate_reasons(item: RankedItem, intent: Intent) -> list[str]: # 根据命中的约束和偏好生成可读理由 reasons = [] if item.price <= intent.constraints.get("price_max", float("inf")): reasons.append("价格在预算范围内") if item.attributes.get("layout") == "compact": reasons.append("紧凑布局符合偏好") return reasons

这个结构清晰，后续每个函数都方便替换成更强壮的实现。意图解析可以换大模型，候选召回可以接向量库，排序可以上学习排序模型，理由生成可以用LLM做摘要，但接口输入输出不需要变。

3.4 单条请求验证

服务启动后，先不要跑批量，用一条请求验证链路。

我一般会先发一个包含硬性约束的请求，比如“预算800以内的无线机械键盘”，然后看三件事：

• 响应是否返回200
• items是否非空
• 每个item是否都有product_id、score和reasons

如果结果为空，不要急着调模型，先检查意图对象里的constraints是不是解析成功了，再看候选池里有没有满足约束的商品。很可能是参数名对不上，或者商品数据里缺字段。

如果返回了结果但reasons为空，检查理由生成逻辑里对应的偏好字段是否和商品attribute键名一致。键名不一致是这类方案最常出现的问题。

3.5 批量、并发和日志

单条跑通之后再上批量。批量任务的核心不是“循环调用接口”，而是要处理命名、重试和日志。

每一条请求都要有独立request_id。失败的重试要有最大次数限制，一般建议3次以内。日志里至少记录这些信息：

• request_id
• 耗时
• 返回条数
• 是否命中硬性约束
• 失败原因

并发也不要一上来就拉满。先用2到4个并发跑一组测试，观察响应时间和资源占用。如果服务用单进程模型撑不住，再考虑加worker。

注意：这里不要一上来就开最大并发。先用一条样例确认输入、输出和日志都正常，再用小并发验证稳定性。

4. 评估和调优：不能只看“推荐得准不准”

4.1 多阶段评估指标

很多人评估推荐系统只看准确率，但在商品发现场景里，准确率不够用。用户可能不只想要“相关商品”，还希望价格合适、品牌可靠、类型符合场景。

我建议分阶段看指标。

这些指标没有统一的绝对标准，因为商品池规模、算力条件和用户场景不同。更合理的做法是长期观察趋势，每次改动后对比指标变化。

4.2 意图解析的边界

意图解析是整个协议最影响体验的部分，也是最容易高估的地方。

关键词解析方案速度快，但处理不了“不要太吵的键盘”这种否定表达。只靠打标会漏掉语义信息。

大模型解析方案能理解复杂表达，但有延迟和成本问题。我建议在需要实时响应的场景里，先用基于规则的解析作为兜底，把解析不了的高复杂度请求交给大模型处理。

另外，不是所有用户需求都能一次解析清楚。如果用户只说“帮我选个键盘”，没有预算、没有类型偏好，那协议里应该返回clarification_needed为true，再由Agent追问。不要强行返回一批没有依据的商品。

4.3 冷启动与长尾问题

冷启动分三种。

第一种是新商品冷启动。商品刚入库时没有点击和购买数据，这时候不能靠行为数据排序，要依赖商品属性、类目、内容描述和供给方提供的基础信息来做相关性匹配。

第二种是新用户冷启动。没有历史行为时，尽量利用当前会话里的query、constraints和preferences，不要拿全局热销榜糊弄用户。

第三种是新场景冷启动。比如原来只做数码产品，突然开通家具类目，那原有词表和属性库都不完整。建议先做好类目映射和词表扩充，再放开流量。

长尾商品的难点是召回不到。解决方案通常是降低硬过滤条件，或者把embedding阈值调低，但代价是可能带入不相关结果。我的做法是分两路召回：一路严格满足约束，一路做宽松探索，排序阶段再把两路结果融合。

4.4 资源占用和运行时判断

小数据量演示阶段，不需要考虑太多资源问题。但如果你准备做真实业务，就要提前判断服务能扛到什么程度。

向量维度决定内存占用。384维的轻量模型比1024维占内存少，但语义表达能力有差距。原始材料里没有给出明确推荐，建议按你的商品数据量和机器内存来测试。

候选池规模决定检索压力。数据量在万级以内，暴力计算相似度可接受；数据量到百万级，必须上向量索引。

响应时间决定缓存策略。如果同一类意图反复出现，可以把结果缓存起来，但缓存时间不要太长，否则商品价格和库存更新后用户会看到过期信息。

注意：低配置机器能跑通演示，不代表适合直接上生产。先明确你的数据量、QPS和延迟目标，再决定是否增加机器和索引。

5. 常见问题排查：先看日志，再改参数

5.1 请求失败或超时

请求失败时，先看的是HTTP状态码和错误信息，而不是马上改模型。

如果返回4xx，大概率是请求体结构不对。检查intent、constraints、preferences这些字段是否和协议定义一致，特别是字段名拼写。

如果返回5xx，优先看服务端日志。常见原因包括商品池加载失败、embedding模型没有初始化成功、向量索引为空。

如果请求超时，先看被卡的环节是哪个。我的排查顺序是：先确认服务日志有没有打印出请求进入时间，再确认是召回慢、排序慢还是理由生成慢。这三段都要单独记录耗时，不要混在一起。

5.2 返回结果为空

结果为空通常是四种原因。

第一，硬约束过滤太严格。比如预算设为300元，但商品池里最便宜的商品也要500元。这时可以放宽到无硬约束再看一次，用来判断是过滤问题还是商品池问题。

第二，属性映射不一致。用户意图里写“无线”，商品attributes里存的是“connection: bluetooth”，如果没有做同义词映射，就会召回为空。

第三，embedding相似度阈值设太高。建议先降到0附近跑一次，确认语义召回链路本身是通的。

第四，商品池本身太小或分类太偏。20条样本的情况下，空结果很正常，不代表协议有问题。

排查顺序是：先看约束满足情况，再看字段映射，再看向量相似度，最后看商品池完整性。

5.3 结果质量不稳定

结果质量不稳定，通常表现为同一意图反复请求，返回结果差异很大，或者结果相关但用户明显不满意。

同一意图结果波动大，可能是embedding模型不是确定性的，或者候选池在实时更新。建议在小数据量阶段固定候选池顺序，排查阶段不要混入动态数据。

结果相关但不满意，往往是偏好字段没有参与排序。比如用户说“安静”，但排序时只按价格和品牌加权，完全没考虑键盘轴体属性，用户当然不满意。这时要检查score_product函数里是否真的用到了preferences字段。

还有一种情况是推荐理由和实际属性对不上。比如reasons写“静音适合办公”，但商品attributes里没有任何静音相关标签。原因是理由生成用的是规则模板，但商品数据本身不满足条件。建议理由生成前先校验条件字段。

5.4 并发一高就延迟变大

并发升高后延迟变大，优先看三个地方。

第一是embedding模型是否被频繁调用。如果每条请求都实时生成商品embedding，那性能一定很差。正确做法是在商品入库或服务启动时，把商品embedding预计算好，请求阶段只计算query的embedding，再做向量检索。

第二是向量检索是否每次全量计算。数据量上来后，暴力计算会明显变慢。可以考虑用近似最近邻索引，但这个要看你的环境是否方便引入额外依赖。

第三是理由生成是否调用大模型。大模型生成结果耗时长，如果每条商品都生成一段长解释，P95会很快升高。建议优先用规则模板生成简短理由，只有复杂场景才调用大模型。

我的建议是：排查时不要一上来就优化代码，先看日志里的分段耗时，把热点找到，再动手改。

6. 工程化扩展与安全合规

6.1 从演示到服务化

实现跑通之后，如果想把它变成长期可维护的服务，至少要做五件事。

第一，加一层API网关或路由层。统一处理限流、鉴权、日志和错误码。协议本身是开放语义层，但接入方仍然需要身份识别。

第二，把商品数据从JSON文件移到数据库或对象存储。建议在入库时做一次字段校验，不符合协议的数据拒绝入库，不要等查询时才排查。

第三，加缓存层。热门意图和热门商品结果可以缓存，但要注意商品价格、库存变化后的缓存失效策略。

第四，做监控告警。重点监控请求成功率、平均耗时、P95耗时、硬约束过滤后候选池是否为空、理由生成失败率。

第五，做配置中心。排序权重、召回数量、阈值这些参数不应该写在代码里，应该放到配置中心，方便线上调整。

6.2 协议版本管理

开放协议一旦被多个接入方使用，就不能随意改字段。

建议从这几个方面考虑兼容性：

• 路径版本号，比如/v1/discovery/request，后续不兼容改动时升级到/v2
• 新增字段时设为可选，不能强制所有接入方立刻升级
• 枚举值要预留扩展位，不要用硬编码数字代替状态
• 删除字段要提前废弃，至少保留一个过渡周期

你也可以在响应里返回当前协议版本号，方便排查接入方和服务端是否对齐。

6.3 合规要求

商品发现协议涉及大量商品数据和用户意图数据，合规必须前置，不能等出问题再补。

对商品数据来源，要确认数据提供方有权提供这些商品信息，包括价格、库存和相关图片。对用户输入内容，要在进入发现链路之前做必要的隐私保护和脱敏处理。

对用户上下文，只采集当前会话所需的最小信息。比如用户说“送礼”，你可以记录场景类型，但不应该为了做推荐去采集与本次需求无关的历史位置或通讯录信息。

对所有人可见的输入和输出内容，都要有内容安全过滤环节。商品标题、描述、用户query和推荐理由，都应该经过过滤，避免低质或违规内容进入候选池和结果页。

对刷接口和恶意调用，要有限流、风控和异常行为识别。开放协议不等于完全开放调用，合理接入仍然要受平台规则约束。

6.4 边界与后续优化方向

最后说一点边界。开放协议能统一“怎么说”，但不能保证“说什么是对的”。协议定义得再清楚，如果商品数据本身有误、意图解析有偏差、排序模型训练数据有偏，结果照样不可靠。

在后续优化里，我比较看好的方向有三个。

第一个方向是多模态扩展。商品发现不只是文本匹配，图片、视频、语音都会进入需求表达。协议里的描述字段要预留多模态扩展位。

第二个方向是多Agent协同。一个Agent负责导购，另一个Agent负责比价，第三个Agent负责售后。它们之间通过同样的协议交互，会让整个购物链路更完整。

第三个方向是反馈闭环强化。通过在协议里加入feedback接口，把用户点击、收藏、加购、购买行为回传到发现服务，算法才能持续优化。

我对这类方案最直接的判断是：协议本身不复杂，复杂的是数据标准化和意图理解。先跑通单条，再管好批量，最后盯住日志和合规，比急着换一个更强的大模型更有效。