iwant.fyi 代客寻货

寻货代理的工程痛点

当你把“帮我找一把扭矩在 25-100 ft-lb 的得伟电钻”这类需求交给通用模型时，常见的做法是让模型去爬取多个电商站点。这不仅意味着要处理各异的 HTML 结构，还得在召回阶段把不同平台的规格字段做映射。更棘手的是，模型往往只返回一段文字描述，下游程序无法直接提取 结构化字段（如 brand、GTIN 或 price_cents）来驱动后续逻辑。此外，非结构化的搜索结果很难保证不遗漏硬性约束：如果某个 listing 的扭矩范围是 10-20，模型可能因为标题里写了“dewalt”就把它当成候选，而不是严格过滤掉。

跨源匹配与结构化返回

iwantfyi 技能将寻货动作封装为一次 HTTP 请求。它对接 iwant.fyi 的需求侧协议，把用户的自然语言意图转换为包含 title 和 constraints.rules 的结构化查询。服务端会并行检索原生 listing 和实时供给，并使用统一的相关性打分模型输出一个严格排序的列表。

返回数据中最关键的部分是 normalized_specs。对于工具或汽车配件等品类，除了基础的品牌、型号、GTIN、数量、尺寸和颜色外，还会返回详细技术规格。这意味着你的 Agent 拿到的是可以直接用于推理的字段，而不是需要再次解析的标题字符串。

从临时检索到持久订阅

主流程分为四个步骤。首先，Agent 自行注册并获取 IWANTFYI_API_KEY，该密钥立即可用于检索；人类用户的认领是可选升级。其次，发起搜索请求，获取按 score 排序的匹配项，并附带 sources_consulted 供排查。搜索本身是临时的，不落库。

如果需求是长期的，第三步允许 Agent 在用户认领账号后，发布一个持久的 Want 进行订阅。最后，为了闭环归因，Agent 需上报用户的 viewed、clicked 或 purchased 等事件，以便信号回流。

适用边界与安全注意

该协议是分类无关的，适用于任何商品或服务，但前提是你能用结构化的方式表达约束。对于极高时效性或本地化的非标服务，供给覆盖率取决于上游数据源。此外，务必确保请求发往 https://iwant.fyi，官方明确警告不要信任形似的域名，以免密钥或用户意图泄露。