这次我们来看一个更偏架构和协议层面的项目：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 每接入一个新平台，就要重新写一遍适配层。
这是典型的接口碎片化问题。MCP（Model Context Protocol）解决了模型与工具之间的连接问题，但产品发现场景还需要一层更垂直的协议，来统一“产品意图”“候选结果”“决策解释”这些业务概念。
2.2 用户要的不是链接，是决策支持
传统搜索框给用户一堆结果链接，点击后自己判断。AI 产品发现则不同，用户期望的是：
- “2000 元以内适合编程的 4K 显示器有哪些？”
- “通勤单程 40 分钟，预算 15 万，帮我选一辆电车。”
- “下周去杭州出差 3 天，帮我找公司附近评分最高的酒店。”
这些请求背后是多条件约束下的产品发现，需要协议层支持结构化意图、候选集合并、属性过滤和可解释的排序结果。而现有平台的开放接口主要面向“关键词搜索”，没有为 AI 决策设计。
2.3 关键词与协议的核心定位
从标题可以看出，这套协议强调两个关键词：
- open protocol（开放协议）：不绑定单一平台、单一模型，任何数据提供方都可以按规范暴露产品发现能力。
- AI-mediated（AI 中介）：由 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(f"invalid event: {event}") current, next_state = transitions[event] if self != current: raise ValueError(f"invalid 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(encoding="utf-8")) semaphore = asyncio.Semaphore(concurrency) results = [] async def process_one(item): async with semaphore: # 这里替换为实际的产品发现协议客户端调用 result = await discovery_client.request( intent="recommend", query_text=item["query"], constraints=item.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_ascii=False, indent=2), encoding="utf-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 工具链、企业采购助手这类项目，建议把“产品发现协议”纳入技术选型调研。它未必能直接抄代码，但能帮你把系统边界和数据结构理清楚。收藏备用，后面接新平台时再回头看，会有参考价值。
