这次我们来看一个更偏架构和协议层面的项目An open protocol for AI-mediated product discovery。一句话解释它想定义一套开放协议让 AI Agent 在帮用户找产品、比较产品、给出购买建议的时候不依赖某个平台的私有接口而是有一套通用的消息格式、权限模型和数据规范。对这个方向我的判断是它比单个推荐算法、某个搜索工具更值得关注因为它解决的是AI 助手接入电商、本地生活、企业采购等场景时的“最后一公里协议问题”。这次文章不聊模型显存不聊推理优化重点是拆解这套协议的动机、核心设计、工程落地方法和适合哪些团队跟进。1. 核心能力速览能力项说明项目类型面向 AI Agent 与产品发现场景的开放协议规范要解决的问题AI 助手无法统一获取、比较、决策产品信息的碎片化问题核心能力意图解析、候选发现、参数提取、结果重排、决策解释、权限控制与 MCP 的关系可看作 MCP 思路在产品发现场景的垂直延伸用于连接商品/服务数据源适用平台电商平台、本地生活服务、企业采购系统、线下门店商品库是否支持 API协议定义的是接口交互规范工程落地时提供 SDK / HTTP / gRPC 实现是否支持批量任务可在代理层设计批处理任务例如批量商品比对、批量报价更新启动方式非独立应用需要以 SDK 或网关服务方式集成适合读者AI 应用开发者、推荐系统工程师、电商平台架构师、Agent 平台设计者需要强调这更多是一份协议设计愿景与技术规范不是某个可以直接启动的 WebUI 项目。进入正文前先把边界说清楚。2. 为什么需要一套 AI 产品发现协议2.1 现在 AI 找产品是“拼接口”过去一年大模型让“帮用户找产品”这件事变得可用但工程上依旧很痛苦。一个 AI 购物助手要完成一次完整推荐通常需要从用户对话里提取品牌、价格区间、品类、使用场景调用电商平台的搜索接口拿到商品列表后做过滤、排序再把结果转成自然语言推荐话术。听起来不复杂实际上每一个环节都是私有实现。每家平台的商品字段不统一有的叫title有的叫itemName有的叫product_title库存状态、价格字段、优惠信息、配送范围的表达更是千差万别。AI Agent 每接入一个新平台就要重新写一遍适配层。这是典型的接口碎片化问题。MCPModel Context Protocol解决了模型与工具之间的连接问题但产品发现场景还需要一层更垂直的协议来统一“产品意图”“候选结果”“决策解释”这些业务概念。2.2 用户要的不是链接是决策支持传统搜索框给用户一堆结果链接点击后自己判断。AI 产品发现则不同用户期望的是“2000 元以内适合编程的 4K 显示器有哪些”“通勤单程 40 分钟预算 15 万帮我选一辆电车。”“下周去杭州出差 3 天帮我找公司附近评分最高的酒店。”这些请求背后是多条件约束下的产品发现需要协议层支持结构化意图、候选集合并、属性过滤和可解释的排序结果。而现有平台的开放接口主要面向“关键词搜索”没有为 AI 决策设计。2.3 关键词与协议的核心定位从标题可以看出这套协议强调两个关键词open protocol开放协议不绑定单一平台、单一模型任何数据提供方都可以按规范暴露产品发现能力。AI-mediatedAI 中介由 AI 作为用户与产品之间的中介层协议设计要围绕模型的意图理解和生成能力展开。换句话说这不是一个搜索引擎协议也不是一个电商 API 规范而是一套“AI 作为对话式产品发现入口”的场景协议。3. 协议要覆盖的关键能力3.1 意图语义与约束提取传统搜索用关键词AI 产品发现要支持自然语言请求的结构化转换。协议需要定义一套统一的意图消息结构至少包含请求意图类型查询、比较、推荐、解释、购买前验证等。约束条件集合品牌、价格、尺寸、颜色、评分、发货时效。用户上下文场景、预算、历史偏好需要用户授权。排序偏好价格优先、评分优先、距离优先、综合推荐。这块是协议最核心的抽象。如果没有统一的意图格式AI Agent 接每个平台都要重写一套意图解析逻辑。3.2 候选产品发现协议需要定义产品发现的请求与响应格式包括数据源选择单平台搜索还是多平台聚合。分页与游标AI Agent 可能需要多轮翻页。结果归一化不同平台的商品必须映射到统一产品档案。可用性与库存实时库存、预售、区域限购的表示。如果没有统一响应结构多平台聚合就只能靠爬虫和接口逆向既不稳定也有合规风险。3.3 结果重排与解释AI 推荐产品不能只丢列表还要说明“为什么推荐这个”。协议应包含重排参数用户显式约束、模型推荐分数、平台排序、商业策略如广告标注。解释字段每个候选结果需要附带可读的推荐理由。对比维度多产品对比时的属性差异高亮。协议层面如果支持“解释”字段AI 应用就可以直接生成带理由的推荐话术而不是事后为每个商品编理由。3.4 权限与用户授权AI 访问用户购物历史、位置、企业采购预算等信息涉及敏感数据。协议需要设计权限层例如用户显式授权的数据范围。临时令牌与短时有效期。用户取消授权的机制。商业数据与个人数据的分离。没有权限设计这类协议很难被严肃平台采用。4. 协议消息设计示例协议不能只停留在概念层下面给一组简化的消息结构示例用于说明“统一产品档案”和“意图请求”应该如何设计。实际项目落地时可以按这套思路扩展 JSON Schema。4.1 产品档案对象{ product: { product_id: platform_a:sku_90831, source: platform_a, name: 某品牌 4K 27 英寸显示器, brand: 某品牌, category: [显示器, 办公设备], price: { amount: 1899, currency: CNY, original_amount: 2399 }, stock_status: in_stock, attributes: { screen_size: 27英寸, resolution: 3840x2160, panel_type: IPS, interface: [HDMI, DP, Type-C] }, seller: { name: 品牌官方旗舰店, rating: 4.8 }, shipping: { area_available: true, eta_days: 2 } } }这个结构解决的是字段归一化问题。无论底层平台用什么字段名协议层统一用name、price、attributes这类标准字段暴露给上层 Agent。4.2 发现请求{ request_id: req_20250601_001, intent: recommend, query_text: 2000元以内适合编程的4K显示器, constraints: { price_max: 2000, category: 显示器, attributes: { resolution: 3840x2160 } }, sort: { primary: score, secondary: price_asc }, pagination: { page_size: 10, cursor: null }, context: { scenario: coding_setup, priority: [screen_size, color_accuracy] } }从这个请求结构可以看出协议层把“自然语言”和“结构化约束”同时保留。query_text是为大模型准备的constraints是为检索系统准备的两者互补。4.3 发现响应{ request_id: req_20250601_001, candidates: [ { product_ref: platform_a:sku_90831, match_score: 0.92, matched_attributes: [resolution, price, panel_type], explanation: 27英寸 IPS 面板4K 分辨率价格 1899 元符合预算约束。, ranking_signals: { user_constraint: 0.7, model_score: 0.15, platform_rank: 0.15 } } ], total: 1, next_cursor: null, data_source_info: { platform: platform_a, cached: false, latency_ms: 320 } }响应里最值得借鉴的是explanation和ranking_signals。有了这两个字段AI Agent 的下游任务就会简单很多直接基于explanation生成推荐话术同时可以判断结果是否被商业策略干扰。5. 关键流程设计5.1 一次完整的产品发现流程用户输入自然语言 ↓ 意图解析与约束提取 ↓ 数据源路由单平台/多平台 ↓ 候选产品检索 ↓ 结果归一化与属性映射 ↓ 重排与过滤约束校验 ↓ 解释生成与结果返回 ↓ 用户反馈采纳/放弃/追问这个流程本质上把“对话式产品推荐”拆成了可以各自独立迭代的模块。协议要做的就是把每个环节之间的数据结构固定下来让不同团队可以独立开发、联动测试。5.2 状态机设计from enum import Enum class DiscoveryState(Enum): PENDING pending PARSING_INTENT parsing_intent ROUTING routing SEARCHING searching FILTERING filtering RERANKING reranking EXPLAINING explaining COMPLETED completed FAILED failed def next(self, event: str): transitions { submit: (DiscoveryState.PENDING, DiscoveryState.PARSING_INTENT), intent_ready: (DiscoveryState.PARSING_INTENT, DiscoveryState.ROUTING), sources_selected: (DiscoveryState.ROUTING, DiscoveryState.SEARCHING), candidates_found: (DiscoveryState.SEARCHING, DiscoveryState.FILTERING), filter_done: (DiscoveryState.FILTERING, DiscoveryState.RERANKING), rerank_done: (DiscoveryState.RERANKING, DiscoveryState.EXPLAINING), explain_done: (DiscoveryState.EXPLAINING, DiscoveryState.COMPLETED), timeout: (DiscoveryState.PARSING_INTENT, DiscoveryState.FAILED), no_results: (DiscoveryState.SEARCHING, DiscoveryState.FAILED), } if event not in transitions: raise ValueError(finvalid event: {event}) current, next_state transitions[event] if self ! current: raise ValueError(finvalid transition from {self} on {event}) return next_state工程落地时建议用状态机管理请求生命周期。分布式环境下每个请求都是一个状态实例方便追踪、统计、告警。6. 与其他方案的边界对比方案定位产品发现能力AI 解释能力开放程度传统电商开放 API提供商品搜索接口有但字段分散无各平台各自定义MCP模型与工具连接协议无垂直场景抽象无开放但需要自己设计这套产品发现协议面向 AI 产品发现的场景协议有核心卖点有包含解释字段目标开放MCP 和该协议不是替代关系。MCP 更底层负责模型怎么调用工具产品发现协议更上层负责产品发现场景的语义定义。实际工程中可以在 MCP Server 内部实现这套协议的逻辑让 Agent 通过 MCP 调用。7. AI Agent 接入场景与工程化落地7.1 适合接入的 Agent 类型电商导购 Agent从“找商品”到“对比商品”再到“购买前答疑”。企业采购助手批量询价、供应商比对、预算约束过滤。本地生活推荐找餐厅、找酒店、找服务门店需要位置和营业时间数据。比价工具 Agent多平台同一商品的价格、库存、优惠对比。7.2 统一产品档案映射层落地这套协议时最脏最累的活是字段映射。建议用一个独立的映射服务来处理{ source: platform_a, field_mapping: { product_id: spu_id, name: item_title, price: sale_price, brand: brand_name, category: category_path, stock_status: stock_state }, value_mapping: { stock_status: { 1: in_stock, 2: out_of_stock, 3: pre_order } } }这个映射层的好处是平台侧字段变化时只需要改映射配置不需要改上层 Agent 逻辑。考虑到电商平台接口经常变动这是维护成本的关键。7.3 批量任务设计如果 Agent 要做批量商品比对而不是单次查询建议在上层增加一个批量任务管理器。一个典型的批量任务可能包括输入一个商品清单每行包含商品名、需要的属性、目标预算。处理逐条调用产品发现协议接口抽取结构化结果。输出统一的 MongoDB / CSV / JSON 结果集。import asyncio import json from pathlib import Path async def run_batch_discovery(input_path: str, output_path: str, concurrency: int 5): tasks_input json.loads(Path(input_path).read_text(encodingutf-8)) semaphore asyncio.Semaphore(concurrency) results [] async def process_one(item): async with semaphore: # 这里替换为实际的产品发现协议客户端调用 result await discovery_client.request( intentrecommend, query_textitem[query], constraintsitem.get(constraints, {}) ) return {item_id: item[id], result: result.model_dump()} results await asyncio.gather(*(process_one(item) for item in tasks_input)) Path(output_path).write_text( json.dumps(results, ensure_asciiFalse, indent2), encodingutf-8 ) if __name__ __main__: asyncio.run(run_batch_discovery(batch_input.json, batch_output.json))批量场景下要特别注意控制并发数避免对数据源接口造成压力。每个请求单独记录耗时和结果状态。失败重试要有退避策略建议指数退避。输出结果中保留request_id便于回查日志。7.4 日志与可观测性协议层接口的观测重点和普通接口不同要额外关注约束命中率用户有 5 个约束最终结果满足几个解释覆盖率返回的候选结果里有说明的比例。数据源错误率平台接口超时、参数错误、字段变更。首次响应时间从用户提问到返回第一批候选的时间。建议把日志结构化成 JSON集中到日志平台方便做漏斗分析。8. 安全、隐私与合规边界这类协议一旦跑起来必然涉及用户数据、商品数据、商业策略数据部署和接入时必须先解决合规问题。用户授权边界读取用户位置、历史订单、浏览记录前必须获得明确授权并支持一键撤回。商业数据隔离平台侧的价格策略、广告排序权重属于商业数据协议接口不能暴露内部排序细节只输出最终结果。个人信息最小化AI Agent 请求中只传完成任务所必需的字段不传手机号、身份证、详细地址等无关信息。内容安全AI 生成的推荐理由不能包含虚假宣传、绝对化用语、未经核实的产品功效描述。版权与商标使用品牌名、商品图、详情文案时必须确认有授权或属于合理引用范围。这里尤其要提醒如果产品发现涉及“换脸、声音克隆、数字人导购、AI 直播带货”等生成式应用素材授权和肖像权确认是硬门槛不能跳过。技术协议解决不了法律风险接入前必须由业务方完成合规评估。9. 推荐实施路线9.1 第一阶段最小协议跑通在内部搭建一个最小可用的产品发现协议服务定义 3 个核心接口意图解析、产品搜索、产品详情。接入 1 个数据源完成字段映射。用 1 个 AI Agent 场景做端到端验证。目标让 Agent 能在 10 秒内返回带解释的产品推荐。9.2 第二阶段扩展数据源接入第 2、3 个平台验证映射层设计是否够用。增加多平台聚合排序。增加批量任务能力。目标让同一个 Agent 无差别调用不同平台的数据。9.3 第三阶段生态开放把协议文档、SDK、Schema 开放给第三方开发者和商家。增加沙箱环境方便新数据源快速接入。建立认证和配额机制。目标让“接入新平台”从数周缩短到数天。10. 常见问题与排查思路问题现象可能原因排查方式解决方案Agent 返回结果缺少品牌字段上游字段映射未配置品牌查看映射配置和数据源原始响应补充field_mapping中的品牌映射多平台价格单位不一致一个平台返回元一个返回分检查价格字段的归一化逻辑统一在协议层转换为amount currency结构候选结果不满足用户约束重排阶段没有强制过滤约束检查过滤逻辑执行顺序先硬过滤再做模型排序解释字段为空上游没有生成解释的模型能力查日志看解释生成模块是否被调用增加基于规则的解释模板或引入 LLM 生成数据源接口超时平台限流或网络问题查看数据源调用耗时和错误码增加超时重试与降级策略批量任务部分失败个别商品在平台上找不到匹配查看失败任务的 item_id单独记录失败原因不阻塞其他任务用户取消授权后旧数据仍在缓存设置了过长 TTL检查缓存生命周期授权变更时主动清理缓存11. 最佳实践与工程建议11.1 协议先行平台后接不要一开始就追求接入很多平台。先把协议的消息结构定稳特别是产品档案、意图请求、响应结果这三张表。后面每接一个新平台只是加一套映射配置。11.2 保留一条纯规则链路AI 生成推荐理由时建议同时保留一条纯规则链路基于约束条件、商品属性、价格对比生成固定模板解释。这样在 LLM 不可用或响应超时时系统还能降级返回基础结果。11.3 一次请求一个 request_id从用户提问到最终推荐全链路都带同一个request_id。排查问题的时候能省大量时间。协议层、Agent 层、平台适配层都要记录这个 ID。11.4 建立“约束可满足性”检测当用户约束条件互相冲突时如“2000 以内”和“顶配”协议层最好能识别出无解情况而不是硬返回空结果。可以在响应中增加suggestion字段提示“放宽价格约束”或“降低分辨率要求”。11.5 注意接口的幂等性批量任务和重试机制都要求接口幂等。请求会带request_id服务端做去重。否则重试时可能产生重复的订单、重复的推荐记录。12. 总结与下一步这套协议的思路能落地关键不在于定义多少消息字段而在于能否做到“一次接入多平台复用”。如果协议设计得好AI 应用团队只需要开发一次意图解析和推荐话术生成逻辑后续接新平台只是新增映射配置和适配器。最值得先验证的两个功能统一产品档案的字段映射一个真实平台的数据能否低成本映射到协议标准结构。解释生成与重排逻辑返回的结果能否让用户感觉“这个 AI 真的懂我要什么”而不是简单的关键词搜索。最容易踩的坑也在前面提到了字段分散、商业数据隔离、授权管理、解释生成的稳定性。这四个问题不解决协议设计得再漂亮也跑不起来。后续可以扩展的方向包括商品知识图谱接入、比价与降价通知、多模态商品搜索、基于用户反馈的个性化重排。如果你正在做 AI 电商导购、Agent 工具链、企业采购助手这类项目建议把“产品发现协议”纳入技术选型调研。它未必能直接抄代码但能帮你把系统边界和数据结构理清楚。收藏备用后面接新平台时再回头看会有参考价值。