Kair 开源
Regmark 方案01 定位与痛点
  1. 00总览
  2. 01定位与痛点
  3. 02受众与场景
  4. 03功能模块
  5. 04架构与选型
  6. 05首期路线图
  7. 06调研依据

Regmark01

定位与痛点

协议接上了，不等于卖得出去。代理读到的价格、库存、运费只要有一处和结账对不上，这一单就丢了。

先说结论

Regmark 不是店铺系统，也不是协议适配器。它是一套测试工具，只管一件事：一家店对机器说的话，和它在结账时做的事，是不是一回事。

同一件商品的价格、库存、运费、退货政策，会从商品页、结构化数据、商品 feed、代理协议端点等好几个出口流出去，真正算数的只有结账那一步。Regmark 把这些出口逐项和结账实算结果比对，把对不上的地方定位到字段，并让它可以在 CI 里失败。

为什么是现在

协议这一层正在被平台包办。 2025 年 9 月，OpenAI 和 Stripe 发布了 ACP。2026 年 1 月，Google 联合 Shopify、Etsy、Wayfair、Target、Walmart 发布了 UCP。两套规范都在快速迭代：ACP 的规范仓库里已经有五个带日期的版本[1]，UCP 今年发了四版[2]。Shopify 的说法是商家的商品「默认可购」[14]，于是 UCP Checker 在 2026 年 8 月统计到的 15,735 家店里，93% 的发现文件评分在 A 档[5]。

但接上了不等于卖得出去。 2026 年 3 月，OpenAI 宣布不再把 ChatGPT 里的 Instant Checkout 当作独立功能推进，转为专注商品发现，结账交还给商家自己。它给的理由是初版「灵活度不够」[4]。Walmart 的高管对 WIRED 讲过数字：在 ChatGPT 里直接结账的商品，转化率只有跳回 walmart.com 那部分的三分之一左右。他的解释是买家不想每件商品单独结一次账，怕收到一堆包裹。Modern Retail 引述另一家零售商高管的话，说这个功能要成熟，还缺实时库存、优惠券和促销[3]。

合并发货、实时库存、优惠怎么叠加，这几样东西有个共同点：它们只存在于商家自己的结账系统里。站外的出口拿到的要么是估的，要么是旧的，要么没有。

一份格式完美的发现文件，保证不了里面的价格是对的。现有的检查工具恰好都停在格式这一层。

消费者这边的容错很低。 Worldpay 的调查显示，美国和英国只有约 6% 的消费者愿意让代理独立完成购买[11]。在这种信任水平下，代理报错一次价，用户下次就不让它代买了。

痛点拆开看

# 痛点 具体表现
1 同一个事实有很多出口，没人保证它们一致 商品页由主题渲染，JSON-LD 由 SEO 插件生成，feed 由另一个插件定时导出，协议端点又是一层适配。四套代码，四个缓存周期，改了一处不会自动改另外三处
2 决定成交的字段恰好最难对齐 运费、税、送达时间、某个变体能不能买、优惠能不能叠加，这些要走到结账才算得出来。前面几个出口上的值多半是估的、旧的，或者干脆没有
3 没有测试回路 想知道代理来买东西会怎样，眼下只能等上线后看转化。主题升级把 JSON-LD 里的价格弄丢了，没有任何东西会报警
4 协议还在变，押哪一个都有风险 OpenAI 撤回原生结账后，ACP 在 4 月的版本里补上了购物车和 feed 的接口[1]，重心往商品发现偏。只针对一种协议做的适配和检查，每个季度都要返工
5 代理的行为随模型版本漂移 研究显示，换一个模型版本，同一批商品被选中的概率会明显重排[10]；最好的代理在真实购物任务上的成功率也不到一半[8]。今天测过，不代表下个月还成立
6 商品内容成了新的攻击面 描述、评论、隐藏文字里写给机器看的指令，可能被代理照做[12]。平台要管第三方卖家的内容，自营店要管用户评论
7 Shopify 之外没人兜底 到 2026 年 5 月，UCP Checker 只找到 3 家通过验证的 WooCommerce 店铺[5]。用 WooCommerce、Magento 和自研系统的商家得自己接、自己测

现有工具各管一段

把现有工具按两个问题分开：被测的是代理还是店铺，检查的是形状还是事实。

看形状格式和协议合不合规范 看事实值对不对，买不买得成
测代理 协议的示例实现，SDK 里的模拟商家 ShopGym、ShoppingBench、ACES、Magentic Marketplace
测店铺 UCP conformance、UCP Checker、ucp-ready、Cloudflare Agent Readiness、CatalogReady Regmarkstoreprobe 也在这一格，处在早期
现有工具的分布。右下这一格几乎是空的。
工具 它检查什么 它不管什么
UCP 官方 conformance、ucp-ready、UCP Checker 发现文件和端点的形状合不合规范 里面的值对不对
Cloudflare Agent Readiness 站点对代理的通用友好程度，比如 robots 规则、Markdown 协商、MCP。电商协议只报告，不计分[6] 商品事实
CatalogReady 单个商品页的静态 HTML 里，机器读得到多少商品信息 读到的和别处是否一致，和结账是否一致
ShopGym、ShoppingBench、ACES、Magentic Marketplace 代理的购物能力和偏好[7][8][9][10] 这些测的是代理，被测对象不是你的店
storeprobe 代理能否找到并看懂商品。还在开发，目前只做目录检索 与结账的一致性

这些工具回答的都是「机器读不读得到」。Regmark 回答的是下一个问题：读到的，对不对得上。

同方向已经有人在试，而且都还很小，上面几个开源项目的星标都在个位数[13]。这说明需求是真的，也说明窗口不会开很久。

差异化押在哪

  1. 跨出口比对，而不是逐个出口打分。 单看任何一个出口都可能是满分，问题出在它们之间。
  2. 以结账为基准。 不是比谁和谁不同，而是所有出口都向结账实算结果对齐。
  3. 不押协议。 核心资产是一张归一化的商品事实表和一套购物任务，协议只是可以更换的采集器。ACP 转向、UCP 升版，换的是插件，不是地基。
  4. 为 CI 设计。 输出是可以设预算的断言，不是一个给人看的分数。
  5. 不依赖代理结账真的普及。 即使代理结账迟迟起不来，价格和库存对不上，同样会让 AI 搜索给出错的答案，也会让 Google Merchant Center 拒登商品。保守情形下这个工具照样有用。

明确不做

  • 不做店铺系统，不和 Medusa、Saleor、Vendure 重复。
  • 不替商家实现协议端点。生态里已经有适配器，Regmark 是给适配器的作者和使用者做验收用的。
  • 不做「AI 可见度」「品牌被提及率」这类营销分析。
  • 不发起真实支付。结账探针走到算出总价为止，然后取消。
  • 不帮人爬别家的店。带写操作的探针只对能证明归属的店铺开放。

考虑过但没选的方向

方向 没选的原因
再做一个无头电商后端 Medusa、Saleor、Vendure 已经成熟，Shopify 的开发者工具也很完整。一个人从零做起，没有任何一点能做得比它们好
给 WooCommerce、Magento 做协议适配器 需求真实，但 WordPress 插件目录里已经有好几个 UCP 适配插件，Saleor 官方也在做[16]。协议每个季度都变，适配器要跟着返工，而且是在和平台方正面竞争
用模型给商品数据补属性 商业产品很多，效果又难以验证。它是「修」，而修之前得先有「测」