引言
过去一年里，「代理购物」从一个概念迅速变成一条真实的产品线。聊天助手可以替用户比价、加购、甚至完成支付的前半段。但所有做这件事的团队都会撞上同一个墙：价格数据从哪来。模型自己不会知道某家店今天的牛肉多少钱一斤，搜索引擎返回的是可能已经过期的页面缓存。
Perplexity 的做法是把这个问题产品化：开放一套商家报价接口，让第三方代理直接查询零售商的价格、库存与配送时效，结果以结构化字段返回。它不是给终端用户的购物助手，而是给开发者的一块砖。定位清楚，评价标准也随之变化：不看界面好不好看，而是看字段是否够用、数据是否新鲜、接入成本是否可接受。
本文基于官方公开的接口说明、字段定义与示例代码整理，不涉及商业机密，也不对未公开的定价做推测。
核心分析
第一，字段设计克制而实用。返回结果里包含商品标识、价格、币种、库存状态、配送时效、来源链接与数据更新时间。对于一个典型的下单前查询，这几个字段已经构成最小可用集合。很多同类接口会塞入大量推荐字段，反而增加了下游的解析负担，这里的克制是优点。
第二，来源与时间戳被强制要求。这条规则看着是合规要求，实际上是产品设计的核心。代理在对话中引用价格时，如果无法说明「这个价格是什么时候、从哪个页面来的」，一旦用户到店发现价格不同，信任就会崩塌。强制来源字段把新鲜度校验的责任明确交给了下游，同时也让下游有能力做这件事。
第三，缺失处理是明确的空值，而不是猜测。当某家零售商没有开放数据或查询失败时，接口返回空，而不是回填一个估算值。对开发者来说这是好事：空值可以被处理，错误的数字不能。这一点在购物场景里尤其重要，因为用户对价格的容错率极低。
第四，实时性受制于零售商的开放程度，这是整套方案的天花板。接口本身只是管道，管道另一端有多少数据源接入，决定了它在什么品类上真的可用。目前覆盖更偏向标准化程度高的品类，生鲜、区域连锁、本地小店的数据接入普遍滞后。
第五，成本结构需要提前算清。按调用量计费意味着一次「帮我找便宜的牛奶」可能触发十几次查询，代理为了给出可靠答案往往会多查几家。如果产品面向的是高频、轻决策的场景，单次查询成本会迅速堆成一座山。这类接口更适合放在客单价高、决策慢的场景里。
实操建议
其一，接入前先做一次缓存层设计。同类商品的价格在几分钟内很少变化，把查询结果缓存三到五分钟，能显著降低调用量，同时不影响用户体验。
其二，把「数据更新时间」直接透出到对话里。不要只把它当作内部字段，明确告诉用户价格采集于几个小时前，比含糊其辞更能建立信任。
其三，为缺失数据准备降级路径。接口返回空时，不应该让代理直接说「找不到」，而是引导用户到零售商页面自行确认，或者给出同品类可查的替代选项。
其四，评估时按「有效查询率」而不是「调用成功率」来衡量。返回了数据但价格过期的查询，对业务是没有价值的，把这类情况单独统计才能看清真实成本。
风险与不足
第一，覆盖面是硬约束。数据源没有接入的零售商，无论接口做得多好都查不到，代理在这些场景下会显得无能。
第二，计费模式对高频场景不友好，缺少按套餐或包月封顶的选项，中小团队难以预估月度支出。
第三，价格数据的法律边界。抓取与二次分发零售商价格在不同地区有不同要求，开发者需要自行确认合规性，接口本身并不解决这个问题。
第四，对代理框架有隐性依赖。示例代码围绕特定的工具调用格式展开，迁移到其他框架时需要一定改造。
评分结论
综合评分 4.1 分。这是目前少数把「代理查价」做成工程可交付形态的产品，字段干净、来源可查、空值处理正确，工程团队接入的成本很低。扣分主要在两处：数据覆盖面决定了它的实际可用范围，按量计费让高频场景的经济性变差。如果你的产品客单价较高、查询频率可控，值得优先评估；如果是低客单高频导购，先算清调用账再动手。
参考来源
- Perplexity 官方站点与开发者文档入口：https://www.perplexity.ai/
- 官方公开的接口字段说明与示例代码（2026-11 查阅）
- 零售价格数据抓取与分发的公开合规讨论资料
- 本文为免费编辑收录，非赞助内容，无联盟链接。
