Shopify AI 与工程实践：从上下文压缩到智能体框架的全面进阶

今天是 XunbuOS Podcast 时间。Shopify 工程团队近期密集发布了多项 AI 与开发者工具方向的深度技术分享，涵盖 LLM 上下文压缩、移动端测试稳定性、持续学习闭环、智能体安全框架等多个维度，我们从中精选了十篇进行整理。

Gisting：压缩 LLM Agent 上下文，提升吞吐量并降低成本

4:1 上下文压缩

Shopify 将 Sidekick GraphQL agent 的系统提示词从约 6,000 个 token 压缩到约 1,500 个 gist token（4:1 压缩比），预测质量无损。方法是通过知识蒸馏学习一组特殊 token 的嵌入，在推理时用它们替换系统提示词。

关键收益

在每分钟 350 次请求（RPM）的负载下，中位首 token 延迟（TTFT）从 438ms 降至 354ms，中位端到端请求延迟从 6.8 秒降至 4.2 秒，吞吐量从每秒 20.2 个查询（QPS）提升至 23.4 QPS。这使 GPU 使用量减少了 14%。

实现要点

• Gist token：添加到模型词表中的特殊 token，每四个提示词 token 对应一个 gist token，冻结模型权重，仅训练 gist 嵌入。
• 教师-学生蒸馏：教师阶段模型看到完整提示词生成 logits，学生阶段用 gist token 替换提示词，通过 KL 散度训练嵌入。
• 自动研究优化：用系统提示词分块的均值初始化嵌入（初始损失降低 7 倍）、找到 4:1 最优压缩比、预计算教师 logits 将训练时间从三十小时缩短到六小时。

与 Prefix Caching 的叠加效果

Gisting 和前缀缓存的优化是叠加的。前缀缓存消除了重复计算，但 gisting 降低了注意力计算和 KV 缓存读取的成本——KV 缓存读取的减少在批次规模增大时对吞吐量的提升尤为显著。

Shopify 移动端 E2E 测试稳定性：从 50% 到 98%

问题根源

旧框架基于 Appium 和 WebdriverIO，API 设计纵容不良测试模式：开发者可轻易在点击后不加等待，或使用 pause(1000) 这类临时方案。即使测试通过，也往往只断言组件树中的节点存在，而非用户真实可见的元素。

重建方案

新框架是围绕 Appium 的"有主见"封装，核心包含两部分：

• 严格的 Builder 风格 API：强制每个步骤（touch、type）附带断言，声明操作后屏幕应呈现的状态。所有绕过安全护栏的选项显式命名为 UNSAFE_ 前缀。
• 计算机视觉定位：使用 PaddleOCR 识别文本，OpenCV 将 Polaris 设计系统中的 SVG 图标与截图匹配。开发者可以写 touch({ text: 'Save' })，无需查找 Test ID。

效果与经验

Shopify 主应用的测试稳定性从旧 API 的 50% 跃升至 98%，剩余的失败主要源于偶发的网络问题或模拟器启动故障。团队还设立了发布前的稳定性门槛，新测试必须通过多次运行的考验才能进入阻塞式套件。

Sidekick 的持续学习闭环：超越前沿模型并削减 96% 成本

核心飞轮

Shopify 的 GraphQL agent 是持续学习闭环的生产实践。自修复管道每天运行，将生产中的失败对话转化为训练信号，强化学习将信号折叠回模型权重中。结果：专用模型超越前沿模型性能，服务成本降低 96%（从约 2700 万美元降至接近 100 万美元）。

四步循环

1. 定义质量：先用评分标准（Rubric）定义"好"的标准，用 Cohen's kappa 衡量标注者间一致性，目标是与人类水平匹配。黄金集应包含随机抽样流量而非精选案例。
2. 校准评判者：使用 DSPy 和基于反思的优化器（如 GEPA），用 A/B 测试结果回溯测试，确认评判者能恢复已知赢家和输家的方向。
3. 自动研究改进基线：agent 提出对提示词、工具定义的更改，根据评判者评估，分数提高则保留。
4. 参数更新：从生产流量挖掘困难样本，用前沿推理模型小组批评分析，仲裁者合并为修复指令，重放对话成为强化学习轨迹。训练分两阶段：监督微调（SFT）提炼轨迹，GRPO 以评判者作为奖励信号强化。

Gisting 的作用

Gisting 将 agent 约 6,000 token 的系统提示词压缩到约 1,500 个 gist token。负载测试中 TTFT 下降约 19%，端到端延迟下降约 38%。同样的压缩提高了吞吐量约 16%，处理相同流量减少约 14% 的 GPU。

构建超越模型的智能体狩猎框架

核心工作流

框架内部名为 Dispatch，使用多智能体编排。首次扫描基于代码规模分区，并行部署多个"狩猎"智能体。后续增量扫描仅对比最新提交与上次提交的差异，降低 token 消耗。

成果数据

超过 80 个应用完成完整扫描，包括 Shopify Core 这一庞大的 Rails 单体应用。六周内产生 300 多个发现，相当于超过 40 万美元的漏洞赏金价值。每次完整应用扫描成本约 50-300 美元，增量扫描仅需 5-50 美元。

关键经验

• 验证器必须遵守严格规则：IDOR 测试必须从公开调用点反向推导、创建属于两个不同租户的测试数据、必须提取有影响的跨租户数据。
• 安全通才型智能体效果最差：没有明确漏洞类型导向，模型会陷入大量"潜在"问题的无序清单。严格指导原则下通才型可作为补充。
• 分区策略关键：目标是让每个分区的 token 量约为模型上下文窗口的 20%-30%。
• 使用确定性脚本：让智能体调用带参数的脚本输出固定格式报告，而非自行生成 JSON。

将 Checkout Blocks 升级到 Polaris Web Components

迁移背景

Checkout Blocks 的 UI 扩展渲染在三分之一的定制结账页面之上，旧版基于 React 和 Remote UI bridge 的架构将于 2025-07 API 版本停用。全部五个扩展迁移到基于 remote-dom 的 2026-01 版本，使用 Preact 和 Polaris web components。

包体积大幅缩减

加载性能提升

扩展加载时间（ELT）按结账量加权：P50 下降 8%，P90 下降 7%。分扩展看，payment-icons 的 ELT P50 下降 11.7%，P90 下降 11.9%。

架构变化与难点

核心变化：从 React 迁移到 Preact，使用 remote-dom 替代 react-reconciler，代码库重写为 TypeScript。最大的工程挑战是 2026-01 remote-dom CLI 对每个扩展包强制 64KB gzip 硬性上限：

• 移除 react-reconciler（约 89KB）：免费获得的单项最大收获。
• 替换 liquidjs（约 73KB）：自研 "droplet" 轻量 Liquid 解析器，gzip 后约 13KB（liquidjs 约 22KB），用 42,000 行生产回归测试验证。
• 替换 dayjs（约 12KB）：替代为内部小型日期工具。
• 保留 markdown-to-jsx：通过 pnpm catalog 将 React 别名到 Preact，markdown 行为无变化。

过程中修复的 Bug

• ID 冲突：Preact 的 useId() 生成限定在单一渲染树内的确定性 ID，同一扩展的两个实例会生成完全相同 ID。用 useStableId hook 生成随机的实例唯一 ID 解决。这是唯一一次生产回滚。
• 文本对齐：Polaris web components 的 Paragraph 和 Heading 已移除 textAlign 属性，最终在 ui-extensions 的 Paragraph 上重新开放 textAlignment 属性（PR #4455）。
• s-checkbox label slot：重构组件新增 label slot，接受字符串或 HTMLElement，并在 ui-extensions 中做消毒处理（PR #4395）。

Catalog API：用 LLM 聚类数十亿商品

问题与核心框架

不同商家对同一商品采用不同的列表结构，缺少统一数据模型。核心是"核心价值主张"框架：如果某个属性（如颜色、口味）不改变核心购买目的，则视为变体，否则视为独立产品。例如，蛋白粉的口味是变体，而油漆的颜色是独立产品。

分阶段方案

1. 商店内聚类：先通过"单例检测器"解析 Liquid 模板代码，识别已通过元字段、标签等确定性规则连接的产品，无需 LLM。只有少数商店需要 LLM 介入。
2. 预处理分块：使用近似最近邻（ANN）检索和稀疏平均链接算法，将产品分组为语义相关的块（每块最多 200 个产品）。
3. 两阶段 LLM 管道：第一阶段提取品牌和型号字符串，第二阶段进行异常检测，审查提案并标记不符合的产品。

关键突破

采用动态生成的严格 JSON 模式（OpenAI 结构化输出），确保模型必须为每个产品 ID 输出品牌和型号，从工程层面保证完整性。枚举约束防止了幻觉 ID。

质量指标

精确率失败会导致不同产品被错误合并（如男女款运动鞋混在一起），召回率失败则会导致相关变体被遗漏。Shopify 选择精确率优先策略，因为展示错误产品比遗漏产品更糟糕。

教 Sidekick 学会拒绝：LLM 评审共识驱动的数据策展

问题

生产训练数据只包含成功案例，模型从未学会说"不"。当被问到不可能完成的查询时，模型生成一个返回零结果的查询，给商家造成"没有客户匹配"的错误印象。

方法

将 Toloka 团队标注的约 600 个标准查询和 602 个拒绝标注的数据集作为种子，运行四个前沿 LLM 作为评审组合：

• 校准：用种子数据中的少样本示例校准每个评审，锚定人类标注者的判断。
• 严格共识门控：四个评审必须在决策和推理两方面都达成一致才能接受标签变更。分歧样本被过滤而非仲裁，优先精确率而非召回率。
• 互斥分类体系：四个类别——需要更多上下文、能力缺失、技能错误、歧义。类别必须互斥，否则评审会产生分歧。

成果

细分技能评估得分从 0.619 提升到 0.798（相对提升 28.9%）。拒绝准确率达 86.3%，误报率为 4.6%。评审组合与真实种子数据的 Cohen's kappa 系数均高于 0.75。

Ruvy：将 Ruby 代码编译为 WebAssembly 模块

工具定位

Ruvy 基于 ruby.wasm 构建，输入 Ruby 代码，输出可执行该代码的 Wasm 模块。通过预初始化 Ruby 虚拟机（VM）及包含的文件来提升性能，无需在运行时提供 WASI 参数。

性能对比

Ruvy 的 Wasm 到本地代码编译时间减少约 70%（从 1.6590 秒降至 446.31 ms）。

关键优势

预初始化 Ruby 虚拟机将运行时性能提升约 20%。Wasm 模块无需提供文件路径作为 WASI 参数，兼容无法配置额外 WASI 参数的计算环境（如边缘计算服务）。

Hack Days 项目：Shop Sounds 音乐播放器原型

项目背景

在过去一年中，归类为音乐与录音制品的产品创造了超过 10 亿美元的 GMV。但 Shopify 上没有内置的方式让顾客试听音乐。

三天成果

13 人团队构建了：原生音频播放器（平台级 Audio 媒体类型）、完整 Shopify 应用（含发布管理）、曲目列表播放器、六个实时音频驱动的 GLSL 着色器、同步歌词生成、带地理定位的巡演日期模块。

架构要点

• 全局音频单例：通过应用嵌入区块注入单一 audio 元素，导航到新页面时音乐不停止。
• metaobjects 作为数据层：发行作品、曲目、巡演日期全部用 metaobjects 和 metafields 存储，无需自定义基础设施。
• 六个自定义 GLSL 片段着色器：流体、几何、粒子、波形、隧道、Voronoi，共享相同的 uniform 接口（uBass、uMid、uTreble、uEnergy），支持七种配色方案，共 42 种独立视觉身份。
• 地理定位：使用 Haversine 公式计算到每个场馆的距离，显示"附近的演唱会"区域。

平台可行性验证

队友 Jamie Guerrero 用五个 PR 证明了原生音频媒体在 Shopify 平台上的架构可行性：新的 audios 数据库表、Audio GraphQL 类型、admin-web 支持、Liquid drop（AudioDrop、AudioSourceDrop）以及自定义 audio-visualizer Web 组件。{{ product.media | media_tag }} 渲染音频播放器的方式与 3D 模型的 model-viewer 组件完全一样。

构建 ShopifyQL 代码编辑器

挑战

ShopifyQL 笔记本应用选择了 CodeMirror 作为代码编辑器，但 CodeMirror 不支持 ShopifyQL。ShopifyQL 语法由 ANTLR 定义，语言服务器遵循 LSP 协议，而 CodeMirror 使用自己的 Lezer 解析引擎，不遵循 LSP。

解决方案

创建 LSP 适配器，将 ShopifyQL 查询传递给语言服务器，适配响应并返回 Lezer 解析树。最大障碍是 token 偏移量的语义差异：

• ANTLR token 偏移是相对的：行号和起始字符总是相对于前一个 token，ANTRL 按乱序解析时甚至会产生负行号。
• CodeMirror 偏移是绝对的：一切都是相对于文档顶部的，换行符和空白字符会影响 token 起始偏移。

核心实现

自定义 TokenIterator 类接收文档并计算每行长度，内部跟踪当前行和字符，使用当前行、字符和行长度计算 CodeMirror 风格的起始和结束偏移。最后将语言服务器的 doValidate、doComplete、doHover 分别适配到 CodeMirror 的 linting、autocomplete、requestHoverTooltips 插件。

本期十篇 Shopify 工程技术文章覆盖了从 LLM 优化到前端性能的多个层面。Gisting 和持续学习闭环展示了 Shopify 在 AI 基础设施上的深度投入；移动端测试稳定性和 Polaris web components 迁移提供了可复制的工程实践；Ruvy 和 ShopifyQL 编辑器则为开发者工具链增加了新选择。下期再见。

相关链接：

• Gisting: Compressing LLM Agent context to ↑ throughput and ↓ cost
• How we raised mobile end-to-end test stability to 98%
• Sidekick's continual learning loop
• Building an agentic harness that outlasts the model
• Upgrading Checkout Blocks app to Polaris web components
• Inside Shopify Hack Days: Building a prototype for music-playing pages
• Clustering billions of products for agentic commerce with Catalog API
• Teaching Sidekick to say no: automated data curation with LLM judge consensus
• Introducing Ruvy
• Building a ShopifyQL Code Editor

Shopify 今日动态：Collection Sources API 重构商品运营模型，Sign in with Shop 向店面应用开放

今天的内容覆盖了平台 API 的重大更新、合作伙伴基础设施的简化，以及多项值得关注的合作案例。最值得开发者注意的是新的 Collection Sources API 和 Sign in with Shop 的通用化——两者都直接改变了应用与店面交互的方式。

全新 Collection Sources API：更灵活的商品运营模型

告别智能/自定义二分法

Shopify 集合功能长期分为自定义集合（手动选择）与智能集合（条件自动填充）两种模式。新模型打破了这一限制，引入"来源"（source）概念——来源将产品或变体添加到集合中，可组合使用。

新模型支持五类来源：自动化条件、手动选择、排除项、其他集合引用，以及应用创建的可共享来源。商家可以先用条件生成集合，再手动精修，排除特定产品或集合，无需维护多个独立列表。

变体级定位

集合现在可以精准指定到特定变体，而非仅限整个产品。这对时尚、服饰类商家的价值尤为直接：情人节集合可以只包含红色变体，加大码促销可以只定位 XS 和 XXL 变体。对店面、搜索、筛选类应用的开发者而言，变体感知的集合为更精准的页面体验创造了空间。

应用来源的贡献途径

评论应用知道哪些产品评价高，订阅应用知道哪些产品符合订阅资格——但此前应用缺乏将这些信号注入原生集合的干净途径。

新模型下，应用可以创建和更新可共享来源，商家决定在何处使用，并可以与自己维护的条件、手动选择、排除项组合。Shopify 会在目录数据变化时自动评估组合后的来源，应用无需不断重写商家拥有的产品列表。

迁移要点

新模型已在 GraphQL Admin API 2026-07 中可用。现有的自定义集合和智能集合继续工作。重要提醒：2026-07 之前的 API 版本无法表示新模型的集合，这些集合会被过滤掉。 如果你的应用读取、写入、渲染、同步或检查集合成员关系，需要更新到 2026-07。

Sign in with Shop 向店面应用开放

身份识别层的通用化

Sign in with Shop 此前仅用于潜在客户信息捕获和客户账户，现在已成为任何需要识别买家身份的店面应用（心愿单、缺货提醒、忠诚度计划、评论等）的即插即用认证组件。

三个组成部分：

1. 开发者后台自助 OAuth 客户端设置——Shop API 与 Storefront API 和 Admin API 并列，使用相同凭证
2. 即插即用 SDK——嵌入店面应用 UI，处理登录流程、用户同意和会话创建
3. 可路由的识别信号——读取 Shop 是否已识别该商店的某位买家，显示"以 [姓名] 身份继续"按钮而非完整登录流程

设计逻辑：会话复利

Shop 会话的积累有复利效应：每次集成捕获一个 Shop 会话，都会提高后续所有交互界面（包括结账）的买家识别率。同一商店中第一个合作伙伴应用完成认证后即创建会话，其他应用无需再次提示，仅需为新增权限触发用户同意。

集成建议

官方给出四条经验法则：

• 增量方案，而非替代方案——对已使用 Shop 的购物者，Sign in with Shop 转化率更高；但仍有大量买家偏好邮箱登录
• 不要在首页加载时自动触发——在买家需要已知身份的操作时再显示按钮
• 为共享会话做规划——处理买家已通过其他应用登录的情况，只请求增量权限
• 测试未认证路径——确保应用能优雅降级回退到现有流程

官方估计大多数团队一个 sprint 内可完成集成。

合作伙伴组织与 RBAC 全面上线

三项联动功能

• Partner Organizations：Partner 组织采用与商户相同的组织模型——一名 Organization Owner、多名 Organization Admins，Dev Dashboard 新增 Organization Settings
• 基于角色的访问控制（RBAC）：七个系统角色覆盖构建者组织的典型结构，支持自定义角色，同一用户可分配多个角色（权限叠加）
• Dev Dashboard 统一管理：开发商店、客户转让商店和协作者商店全部收录于 Dev Dashboard，无需切换仪表板

七大系统角色速览

迁移预期

无需任何操作，3 月 30 日起自动迁移。现有多个所有者中主要所有者保留该角色，其余自动转为 Organization Admin。所有待处理的用户邀请将被取消，需要手动重新添加。

Partner Dashboard 的付款、应用分发、主题和推荐等功能保持不变。

2026 Shopify Build Award 获奖者揭晓

四个类别，七组获奖者

店面类：Human NYC（Wendywin 眼镜品牌，杂志式阅读体验）、Commerce UI（Lupine 店面，原生 Liquid 构建 B2B 功能）、Unlikely（Yse 无头构建，追求移动端原生质感）

应用类：Smile（忠诚度应用，构建了面向其他开发者的公开 API）、Discount Kit（折扣应用，折扣叠加逻辑原生构建于 Shopify Functions）、Easyteam（员工管理工具，从在线店铺切入实体 POS）

社区类：Zapiet 联合创始人 Emili Horncastle（首任社区奖得主，组织全球合作伙伴聚会）

商家影响力类：Elephant Room 与 Prosper Digital 联合获奖（帮助 Lioness 五年内线上收入提升约 140 倍，六周内总销售额提升 113%）

Ask Phill 的多品牌整合方法论

统一代码库，逻辑层解耦

Ask Phill 的核心方案是集中式 Shopify 代码库为多个品牌店面提供动力，通过专有的"逻辑层"（logic layer）处理品牌间差异——需求差异通过配置而非独立代码分支解决。

成果数据：开发效率提升 40-70%，缺陷减少 30-50%，新品牌上线从数月缩短至数周。已实施案例包括 Obey Clothing（3 品牌）、ID&T（8+ 品牌）、North Action Sports Group（4 品牌）。

80/20 框架：80% 共享基础设施（核心电商功能、技术架构、运营流程），20% 品牌专属定制（市场定位、视觉形象、专门功能）。

Built for Shopify：Seguno 的增长实证

认证带来的可量化结果

Seguno 旗下全部应用通过 Built for Shopify 认证后：整体安装量提升 14%，认证后六天内搜索排名跃升至第一页。

关键实践：全程使用 Polaris 组件库构建原生体验；满足 LCP 性能指标是最大挑战之一，Seguno 为此构建了自定义性能指标插件并使用 Sentry 追踪。Shopify 现已提供 Web Vitals 实时监控工具。

Bloomreach 与 Shopify：AI 个性化的企业级落地

客户数据透视

Bloomreach 与 Shopify 整合后取得的平均效果：访客平均收入提升 50%（其中客单价提高 24%），转化率提升 21%，自动化流程收入增长 310%。

核心整合产品是 Bloomreach Discovery（GenAI 搜索）与 Bloomreach Engagement（营销自动化），均由 Loomi AI 引擎驱动。英国女装品牌 Lovall 的案例：自动化流程收入增长 310%，弃购转化率提高 30%，平均订单价值提升 15%，CRM 收入增加 51%。

相关链接：

• Meet the 2026 Shopify Build Award winners
• Sign in with Shop opens to storefront apps
• Introducing the new Collection Sources API: a more flexible model for merchandising
• Build More, Manage Less: Teams, Stores, and Roles Simplified
• The Multi-Brand Blueprint: How Ask Phill Scales Multi-Brand Commerce on Shopify
• How Seguno propelled their success on the Shopify App Store with 'Built for Shopify'
• How partnering with Shopify has helped Bloomreach achieve yearly double-digit growth
• Bloomreach partners with Shopify to deliver AI-powered personalization, helping enterprises increase revenue by over 300%
• Deloitte Digital and Shopify Collaborate to Help Brands Achieve Unified Commerce
• Join Today

Shopify 工程博客精选：LLM Agent 基础设施、移动端测试稳定性与 Checkout 扩展性能优化

欢迎阅读本期 XunbuOS Podcast。今日内容涵盖 Shopify 在 LLM Agent 基础设施（Gisting 上下文压缩、连续学习飞轮）、移动端 E2E 测试稳定性提升、Checkout Blocks 向 Polaris Web Components 迁移，以及 Catalog API 产品聚类等多个方向的深度技术分享。

Gisting：压缩 LLM Agent 上下文以提升吞吐量并降低成本

4:1 压缩比下的延迟与吞吐量收益

Shopify 将 Sidekick GraphQL agent 的系统提示词从约 6,000 个 token 缩减到约 1,500 个 gist token（4:1 压缩比），预测质量不丢失。在 350 RPM 负载下，TTFT 中位数从 438ms 降至 354ms，端到端延迟从 6.8s 降至 4.2s，吞吐量从 20.2 QPS 提升至 23.4。

训练与部署机制

Gisting 通过知识蒸馏学习特殊 token 的嵌入。训练时执行两次前向传播：教师阶段模型看到完整提示词，学生阶段用 gist token 替换，使用 KL 散度训练嵌入。压缩成本只在训练时支付一次，推理时仅需将提示词替换为 gist token 字符串，无需自定义注意力掩码或特殊服务路径。

与前缀缓存叠加

前缀缓存无法消除解码成本——每个生成的 token 都必须对整个 KV 缓存做注意力计算。Gisting 降低了注意力计算和 KV 缓存读取的成本，两者优化叠加，生产环境同时使用。

Autoresearch 优化配方

Shopify 将 autoresearch 循环指向训练器，自动搜索超参数。关键优化包括：用提示词分块的均值初始化嵌入（初始损失降低 7 倍）、找到 4:1 为最佳压缩比、预计算教师 logits 将完整训练从 30 小时缩短到 6 小时。

移动端 E2E 测试稳定性从 50% 提升至 98%：重建测试框架

问题根源

旧框架基于 WebdriverIO + Appium，使用 React Native Test ID 定位元素。无机制强制良好测试模式，开发者常用 pause(1000) 绕过竞态条件，测试实际在验证实现细节而非用户体验。

重建方案：Builder 风格 API + 计算机视觉

新封装层有两个核心部分：

1. 严格 builder API：每一步必须携带断言，声明操作后屏幕应显示的内容。可复用切片如 logIntoApp，逃生舱口以 UNSAFE_ 前缀命名。
2. 计算机视觉替代 Test ID：每一步截取屏幕截图，用 PaddleOCR 识别文本、OpenCV 将截图与 Polaris SVG 进行图标匹配。Test ID 降级为回退方案。

迁移结果

在 Shopify 主应用阻塞 CI 后，测试稳定性从 50% 跃升至 98%。剩余失败主要源于偶发网络问题和模拟器启动故障。新测试必须通过多次运行才能进入阻塞套件。

Sidekick 的持续学习循环：将生产失败压缩为模型权重

从离散产物到参数更新

初始改进集中在提示词、工具定义和脚手架等离散产物。持续学习将生产经验转化为模型连续参数空间的更新。自愈管道每日运行，由前沿推理模型小组批评失败案例、仲裁者合并修复指令、重放对话，经 SFT 和 GRPO 微调。

GraphQL 代理实战数据

• 专用模型超越前沿模型性能
• 服务成本降低 96%：从每年约 2,700 万美元降至接近 100 万美元
• Gisting 将系统提示词从约 6,000 token 压缩至约 1,500 token
• 端到端延迟下降约 38%，GPU 用量减少约 14%

质量定义先行

质量始于评分标准，产品团队将需求转化为评分标准并配备具体锚点。两位专家标注员盲注 25 个随机样本，Cohen's kappa 低于 0.2 说明标准有歧义，需迭代。评判者需与人类标注一致性达到人类彼此间一致性水平。

构建超越模型的 Agentic 框架：安全测试的经验

Dispatch 多阶段扫描工作流

内部框架编排器 Dispatch 将扫描分为九个有序阶段：测试引导、架构文档、文件编目、分区、狩猎、验证、后处理、报告、修复。验证器使用与猎手不同的模型，对抗性审查减少噪音。

测试预言机是关键

Web 漏洞无直接测试预言机，Shopify 将验证嵌入应用现有测试流水线。例如 IDOR 验证器要求：从公开调用点反向工作、创建跨租户测试夹具、测试覆盖公共技术栈、提取有影响力的数据。

分区策略平衡成本与召回率

目标 token 数约为模型上下文窗口的 20-30%，按相关领域分组文件。使用分区后，准确率和召回率均有提升，同时保持低成本。完整应用扫描成本 50-300 美元，增量 diff 扫描仅 5-50 美元。

Checkout Blocks 应用升级至 Polaris Web Components

包体积缩减 40-85%

五个高流量结账扩展从 React + Remote UI 迁移至 Preact + remote-dom + Polaris Web Components。传输体积缩减：payment-icons 降 84.4%，static-content 降 54.1%，custom-field 降 44.6%。

加载性能提升

按结账量加权的 ELT P50 下降 8%，P90 下降 7%。payment-icons 扩展的 ELT P50 和 P90 均下降约 12%。

压到 64KB 以内

2026-01 版 remote-dom CLI 强制要求每个扩展包 gzip 后不超过 64KB。主要削减来源：

• 移除 react-reconciler（约 89KB），切换到 Preact 后免费获得
• 自研 Liquid 解析器 "droplet" 替换 liquidjs（gzip 后 13KB vs 22KB，使用 42,000 行生产对等语料库验证）
• 小型内部日期工具替换 dayjs（约 12KB）
• 保留 markdown-to-jsx（约 15KB），通过 pnpm workspace catalog 别名到 Preact

修复的关键 Bug

• ID 冲突（唯一一次生产回滚）：useId() 生成确定性 ID，同一扩展两个实例产生相同 ID。修复方案是 useStableId Hook 生成随机的实例唯一 ID。
• 文本对齐：Polaris Web Components 的 Paragraph 移除了 textAlign。跨职能决策后在 ui-extensions 重新暴露 textAlignment（PR #4455）。
• s-checkbox label 插槽：重构为接受字符串或 HTMLElement，仅允许 s-text 和 s-link（PR #4395）。

使用 Catalog API 对数百万产品进行聚类

核心价值主张框架

关键问题是：买家主要购买这个产品的目的是什么？属性不改变答案就是变体；确实改变答案就是产品身份的一部分。例如蛋白粉口味是变体，油漆颜色是产品本身。

精确率优先策略

收紧阈值提高精确率会错过有效匹配，放宽阈值提高召回率会错误归组。Shopify 选择严格精确率阈值下最大化召回率——展示错误结果比结果不完整更糟糕。

两阶段 LLM 管道

预分块使用 ANN 检索（FAISS + HNSW，每个产品连接 100 个最近邻）+ 稀疏平均链接（UPGMA，距离阈值 0.25，最大块大小 200 个产品）。阶段 1 提取品牌 + 型号，阶段 2 异常值检测，默认保持项目在一起除非有明确证据。

动态结构化输出 schema

为每个块动态生成 JSON schema，在输出 products 对象中为每个产品 ID 定义必需的 brand 和 model 字段。schema 强制完整性——LLM 不可能跳过产品。排序控制推理：要求 patterns 数组在 products 对象之前。枚举约束防止幻觉，outliers 数组列出聚类中每个有效产品 ID（上限 500）。

Teaching Sidekick to say no：LLM 评审共识驱动的数据整理

问题：训练数据盲区

生产语料只包含成功查询，模型从未学会拒绝。当被问及无法实现的查询时，模型生成返回零结果的查询，给商家造成"没有匹配客户"的错误印象。

四评审员严格共识

四个独立 LLM（A、B、C、D）各自评估查询，只有全部达成一致且推理一致才接受标签。分歧案例被过滤而非仲裁解决。四个互斥分类：需要更多上下文、功能缺失、技能错误、存在歧义。

成果数据

客户细分技能评估分数从 0.619 提升到 0.798（相对提升 28.9%）。拒绝准确率 86.3%，误报率 4.6%。四个模型与种子数据的 Cohen's kappa 全部高于 0.75。

Shopify Hack Days：为音乐页面构建音频播放器原型

平台级 Audio 媒体类型的可行性

13 人团队在三天内通过五个 PR 在 Core、Admin API、admin-web 和 storefront 中添加了新的 Audio 媒体类型：新增 audios 数据库表、Merchandising::Audio 模型、Audio GraphQL 类型、Liquid drops 及自定义 audio-visualizer web 组件。{{ product.media | media_tag }} 可像渲染 3D 模型的 model-viewer 一样渲染音频播放器。

Metaobjects 作为数据层

发布是 metaobject，曲目列表是其上的 JSON metafield，音频文件等是产品变体上的 metafields。具有 storefront: PUBLIC_READ 访问权限的 Metafields 可通过 Liquid 自动提供给主题扩展，无需自定义 API。

Ruvy：将 Ruby 编译为 WebAssembly 的工具链

预初始化 VM 提升性能

Ruvy 在构建 Wasm 模块时预初始化 Ruby VM，而 ruby.wasm 在模块执行时启动。基准测试显示实例化和执行 _start 函数快约 20%，Wasm 到原生代码编译时间减少约 70%。

免 WASI 参数执行

生成的模块无需提供文件路径作为 WASI 参数，适用于无法配置额外 WASI 参数的边缘计算环境。支持通过 --preload 标志预加载 Ruby 文件目录。

构建 ShopifyQL 代码编辑器：连接 ANTLR 语言服务器与 CodeMirror

自定义适配器桥接 LSP 与 Lezer

ShopifyQL 语言服务器基于 ANTLR TypeScript 目标构建，遵循 LSP 协议。CodeMirror 使用 Lezer 解析引擎，两者不直接兼容。解决方案是创建遵循 LSP 的自定义适配器：将查询传递给语言服务器，获取 token 流，转换为 Lezer 节点缓冲区。

Token 偏移转换

最困难的部分是处理 ANTLR 的增量偏移。ANTLR token 的行和字符值是相对于前一个 token 的，注释甚至可能出现在主通道解析完后才解析（行值可为 -2）。解决方案是自研 TokenIterator 类：

• 接收文档并推导每行长度
• 内部跟踪当前行和当前字符
• 摄取 ANTLR 风格描述符并移动位置
• 用当前行、字符和行长度计算 CodeMirror 风格的绝对偏移

完整语言功能

将语言服务器的 doValidate、doComplete、doHover 分别与 CodeMirror 的 linting、autocomplete、requestHoverTooltips 插件适配，实现语法高亮、自动补全、代码检查和悬停提示。

相关链接：

• Gisting: Compressing LLM Agent context to ↑ throughput and ↓ cost
• How we raised mobile end-to-end test stability to 98%
• Sidekick's continual learning loop
• Building an agentic harness that outlasts the model
• Upgrading Checkout Blocks app to Polaris web components
• Inside Shopify Hack Days: Building a prototype for music-playing pages
• Clustering billions of products for agentic commerce with Catalog API
• Teaching Sidekick to say no: automated data curation with LLM judge consensus
• Introducing Ruvy
• Building a ShopifyQL Code Editor

2026 Build Award 揭晓、Sign in with Shop 开放、Collection Sources API 上线：今日 Shopify 生态动态

今日 XunbuOS Podcast 聚焦 Shopify 生态多线进展：2026 Build Award 获奖名单出炉，Sign in with Shop 开放给店面应用，Collection Sources API 在 GraphQL Admin API 2026-07 中上线，以及合作伙伴组织与 RBAC 的推出。

2026 Shopify Build Award 获奖者揭晓

四个类别，七国获奖者

Build Award 在 DotDev 大会上颁发，今年覆盖应用（Apps）、店面（Storefronts）、商家影响力（Merchant Impact）和社区（Community）四个类别，获奖者来自七个国家。

值得关注的获奖项目

• Human NYC（店面）：为高端眼镜品牌 Wendywin 打造编辑杂志式店面，视频和动画贯穿购物体验，集合页面支持产品缩放和定制尺寸对照表
• Smile（应用）：生态中最大的忠诚度应用之一，构建了公共 API 供其他开发者接入，与平台深度集成。联合创始人 Mike Rossi 观点："商家已经能用一个周末 vibe-coding 做出完整应用，差异化在于对单一主题的深度"
• Discount Kit（应用）：高级折扣功能，折扣叠加逻辑原生构建在 Shopify Functions 上，核心团队精简，支持人员分布全球
• Commerce UI（店面）：第二次获奖，为 Lupine 构建了含交互式功能、复杂商品配置器和 B2B 功能的店面，全部用 Liquid 原生构建
• Easyteam（应用）：Shopify POS 最受欢迎应用之一，提供员工管理、工资核算和佣金管理，新员工已会收银就能直接打卡
• Zapiet（社区）：自提和配送应用先驱，疫情期间两个月从 6 人扩张到 33 人，现在有六个应用
• Elephant Room & Prosper Digital（商家影响力）：联合奖项。帮助 Lioness 五年内线上收入增长约 140 倍，随后在六周内将总销售额提升 113%、转化率提升 74%

Sign in with Shop 开放给店面应用

身份验证层扩展

Sign in with Shop 此前用于潜在客户信息捕获和客户账户，现作为即插即用的身份验证层，可集成到心愿单、到货通知、忠诚度计划、商品评价等任何需要识别已知买家的店面应用中。

三个核心设计：Shop 会话的认知度会累积，集成的应用越多识别能力越强；每个店铺一次登录而非每个应用一次；Shop API 与 Storefront API 和 Admin API 并列，使用同一套凭据。

SDK 三部分

• 开发者后台的自助 OAuth 客户端配置，无需手动入驻
• 即插即用的 Sign in with Shop SDK，处理登录流程、用户同意和会话创建
• 可路由的识别信号，可显示"以 [姓名] 身份继续"按钮而非完整登录流程

集成要点

大多数团队可在一个迭代周期内完成集成。最佳实践：将 Sign in with Shop 视为增强而非替代，保留现有身份层；不要在首次页面加载时自动触发，应在买家进行需要已知身份的操作时显示；需处理买家已通过其他应用登录的情况，只请求增量权限。

Collection Sources API：更灵活的商品分类模型

打破智能/自定义二分法

新模型在 GraphQL Admin API 2026-07 中可用。集合可组合多个来源：自动化条件、手动选择、排除项、其他集合引用，以及应用创建的可共享来源。

关键特性：变体定位允许集合精确到特定变体而非整个产品；集合作为构建模块可引用其他集合，来源集合变化时父集合自动同步；可共享的应用自有来源让应用将智能融入 Shopify 原生集合。

开发者影响

• 旧的自定义集合和智能集合继续正常工作，可增量迁移
• 2026-07 之前的 API 版本无法表示新模型的集合，这些集合会被过滤掉
• 读取、写入、渲染或检查集合成员资格的应用需升级到 2026-07

新机遇

感知变体的集合为店面、搜索、筛选和主题合作伙伴创造了新机会。集合还可作为更通用的业务基元：支持折扣、税务覆盖、物流工作流、目录操作，未发布的集合可仅用于内部工作流。

合作伙伴组织、RBAC 与 Dev Dashboard 聚合

三项核心更新

• 合作伙伴组织：一个组织所有者加多个组织管理员，Dev Dashboard 新增组织设置入口
• RBAC：内置七个角色，覆盖典型工作模式，支持自定义角色
• Dev Dashboard 聚合所有商店：开发商店、客户移交商店和协作者商店统一显示

七种系统角色

组织所有者（每组织仅一位，可转移所有权）、组织管理员（可管理用户、创建自定义角色）、组织用户管理员（管理团队成员）、商店管理员、商店用户管理员、应用开发者（Dev Dashboard 访问权限）、协作者商店访问。一个人可拥有多个角色，权限叠加。

迁移须知

3 月 30 日自动完成，系统根据现有访问权限自动分配角色。此前待处理的用户邀请已取消，需通过组织设置重新添加。迁移后建议：查看组织设置、审查角色分配、确认组织所有者人选。

Ask Phill 多品牌整合方案

技术蔓延的悖论

每次收购或上线新品牌意味着又一套技术栈、数据和代码库。77% 的美国技术决策者表示组织存在中到高度的技术蔓延问题。

Ask Phill 的方案是打造一个集中的 Shopify 代码库支撑多个品牌门店，核心是自有的"逻辑层"：通过配置而非分离的代码分支处理品牌间差异。

效果数据

• 开发效率提升 40-70%
• 缺陷率降低 30-50%
• 新品牌上线周期从数月缩短至数周
• 80/20 框架：80% 共享基础设施，20% 品牌专属定制

已验证案例：Obey Clothing 三个品牌整合、ID&T 八个以上品牌效率提升 40-50%、North Action Sports Group 四个品牌全球门店整合。

Seguno 的 Built for Shopify 经验

BFS 认证的量化收益

全部已认证应用安装量提升 14%，搜索排名在认证后六天内跃升至第一页，荣获 2024 年 Shopify Build Award。

Seguno 的经验：早期采用 Polaris 组件库使 BFS 设计标准较易满足；最具挑战的是后台性能要求，特别是 Largest Contentful Paint（LCP）指标；Shopify 现在已提供工具实时监控 Web Vitals，可避免他们当初自建性能插件的困难。

Bloomreach 与 Shopify 的 AI 个性化合作

集成成果

• 每位访客收入平均提升 50%
• 转化率平均提升 21%
• 自动化流程收入提升 310%

核心是 Loomi AI 引擎驱动的 Bloomreach Discovery（GenAI 搜索）和 Bloomreach Engagement。GenAI 搜索理解自然语言查询，例如"帮我找一条春季半正式婚礼宾客礼服"，并在每次交互中学习优化。案例：英国女装品牌 Lovall 通过 Bloomreach Engagement 集成 Shopify，自动化流程收入提升 310%，废弃购物车转化率提升 30%，客单价提升 15%，CRM 收入提升 51%。

Deloitte Digital 与 Shopify 合作实现统一商务

下一代零售商务加速器

Deloitte Digital 开发了可组合商务（composable commerce）解决方案，帮助客户将 Shopify 与 ERP、PIM、CRM 系统以及 Oracle 的 Unity CDP 无缝集成。预建集成覆盖库存管理、配送预估、门店库存、营销自动化、数据与分析。

合作模式：Deloitte Digital 提供咨询、定制解决方案和集成，同时构建可复用的加速器方案，帮助多个客户快速实施可扩展的商务解决方案。

今日生态动态的明显趋势是 Shopify 在平台开放性上的持续投入：Collection Sources API 让应用智能融入原生商品分类，Sign in with Shop 解决店面应用的身份识别问题，合作伙伴组织与 RBAC 则降低了多人协作的管理成本。Build Award 获奖者的共同点是深度贴近商家、在一个值得解决的问题上深入钻研——这也是 Shopify 生态最可靠的增长路径。

相关链接：

• Meet the 2026 Shopify Build Award winners
• Sign in with Shop opens to storefront apps
• Introducing the new Collection Sources API: a more flexible model for merchandising
• Build More, Manage Less: Teams, Stores, and Roles Simplified
• The Multi-Brand Blueprint: How Ask Phill Scales Multi-Brand Commerce on Shopify
• How Seguno propelled their success on the Shopify App Store with 'Built for Shopify'
• How partnering with Shopify has helped Bloomreach achieve yearly double-digit growth
• Bloomreach partners with Shopify to deliver AI-powered personalization, helping enterprises increase revenue by over 300%
• Deloitte Digital and Shopify Collaborate to Help Brands Achieve Unified Commerce
• Join Today

Shopify 工程博客精选：LLM 压缩、移动端测试稳定性与 Checkout 性能优化

今日 XunbuOS Podcast 汇总 Shopify 工程团队的十篇技术文章，覆盖 LLM 推理优化、移动端 E2E 测试重建、AI 代理安全扫描框架、Checkout Extensibility 迁移、Catalog API 聚类等热点话题。

Gisting：将 LLM Agent 系统提示词压缩 4 倍

压缩机制

Shopify 实现 gisting 技术，将 Sidekick GraphQL agent 的系统提示词从约 6,000 token 压缩到约 1,500 个 gist token（4:1 压缩比），且不损失预测质量。特殊 token 的嵌入通过知识蒸馏学习，推理时将完整提示词替换为 gist token。

关键实现：teacher pass 中模型看到完整提示词，student pass 中用 gist token 替换，通过 KL 散度损失函数训练 gist 嵌入。部署时直接将嵌入写入模型的嵌入矩阵，推理无需自定义注意力掩码。

性能数据

在 350 RPM 负载下：

• 中位首 token 延迟（TTFT）：438ms 降至 354ms（-19%）
• 中位端到端请求延迟：6.8s 降至 4.2s（-38%）
• 吞吐量：20.2 QPS 提升至 23.4 QPS（+16%）
• GPU 需求减少 14%

与前缀缓存的叠加效应

前缀缓存无法消除解码成本——每个生成的 token 需关注序列中所有 key，且 KV 缓存读取量随序列长度线性增长。Gisting 降低注意力计算和 KV 缓存读取成本，两种技术可叠加使用。

训练优化

Autoresearch loop 发现三项关键优化：均值初始化嵌入将初始 loss 降低 7 倍；4:1 是最优压缩比；大规模多样化数据集消除质量差距。预计算 teacher logits 和预 tokenize 数据将训练时间从 30 小时缩短至 6 小时。

移动端 E2E 测试稳定性提升至 98%

旧框架问题

Shopify 最大应用的 E2E 测试套件用 WebdriverIO + Appium + React Native Test ID，稳定性仅 50%。开发者用 pause(1000) 等临时手段掩盖等待问题，断言检查的是组件树节点存在性而非用户体验。

重建方案：严格 API + 计算机视觉

新框架由两部分组成：构建器风格 API（强制良好模式）和计算机视觉查找元素（像用户一样扫描屏幕）。底层仍由 Appium 驱动设备，但开发者无法绕过包装器。

• 每一步操作必须携带断言
• 逃生舱以 UNSAFE_ 前缀命名，提示开发者避免使用
• PaddleOCR 处理文本识别，OpenCV 将截图与 Polaris SVG 匹配
• 每次运行生成带注释的视频，显示每一步查找内容与结果

迁移效果

新 API 推广到阻塞式 CI 几周后，测试稳定性从 50% 提升至 98%。其余失败主要来自偶发网络问题和模拟器启动失败。预推广不稳定门槛要求新测试多次运行证明稳定后才允许进入阻塞套件。

Sidekick 持续学习循环：成本降低 96%

学习闭环架构

Shopify GraphQL agent 的持续学习循环包含五个阶段：

1. 定义质量：评估标准（rubric）将产品需求转化为评分维度，用 Cohen's kappa 验证标注者一致性
2. 校准评判器：用 DSPy + GEPA/ACE 优化器，回测 A/B 测试结果，执行定向降级测试
3. 自动研究改进编排：agent 提出修改，评判器评估，保留高分支方案
4. 从离散工件到参数更新：挖掘困难负样本，前沿模型批判分析失败，强化学习折叠回模型权重
5. Gisting 压缩服务提示词：减少延迟与 GPU 成本

效果数据

• 微调后模型在评判器质量上超越前沿模型基线
• 服务成本：前沿模型估算年成本约 2,700 万美元，微调模型接近 100 万美元（-96%）
• 延迟：TTFT 下降约 19%，端到端延迟下降约 38%
• 吞吐量：每秒请求数增加约 16%，GPU 减少约 14%

自愈管道

生产失败对话自动进入管道：前沿推理模型批判分析 → 仲裁器合并修复指令 → 重播对话 → 评判器评分 → SFT + GRPO 训练。Toloka 处理评判模型无法修复的案例。

构建智能体安全扫描框架

多智能体编排

Dispatch 框架用 Ruby 编写，包含九个有序阶段：测试引导、架构文档、文件编目、分区、猎手、验证、后处理、报告、修复。验证者使用与猎手不同的模型，对抗性审查减少噪音。

成果

• 超过 80 个应用完成完整扫描（含 Shopify Core 单体仓库）
• 六周内产生 300+ 发现，两个被评为"严重"
• 保守估计价值超过 40 万美元漏洞赏金
• 完整应用扫描成本：50-300 美元；增量差异扫描：5-50 美元

关键经验

• 分区策略：目标 token 数量约为模型上下文窗口的 20-30%，按相关领域分组文件，提高准确性和召回率
• 多个模型交叉验证：一个模型捕获另一个模型的错误，减少误报
• 确定性脚本：结构化输入输出用编程方式强制执行，减少格式错误
• 测试预言机：Web 漏洞候选用前端单元测试、多租户固件测试验证，无法证实则降级严重性

Checkout Blocks 升级到 Polaris Web Components

迁移范围

五个高流量 UI 扩展从 React + Remote UI 迁移到 Preact + Polaris Web Components + remote-dom，API 版本从 2025-07 升级到 2026-01，代码库重写为 TypeScript。

性能提升

传输体积缩减 40.5% 至 84.4%：

加载性能（ELT，按结账量加权）：P50 -8%，P90 -7%。

64KB 包体积限制下的工程决策

• 去掉 react-reconciler（约 89KB）：Preact 免费收益
• 自研 Liquid 解析器 "droplet"（约 73KB → 13KB，gzip 后）：42,000 行生产环境 fixture 对等性验证
• 替换 dayjs（约 12KB）：用小型内部日期工具
• 保留 markdown-to-jsx（约 15KB）：通过别名映射到 Preact，避免改变渲染行为

沿途修复的 Bug

• ID 冲突（唯一一次生产回滚）：useId() 生成确定性 ID 导致同一扩展两个实例冲突，改用 useStableId hook 生成随机实例唯一 ID
• 文本对齐：Polaris Web Components 的 Paragraph/Heading 移除 textAlign，重新暴露 textAlignment 属性
• s-checkbox label 插槽：重构为接受 HTMLElement，支持"接受[条款和条件]"模式

ShopifyQL Code Editor 构建实践

架构方案

ShopifyQL Notebooks 用 CodeMirror 作为编辑器框架，语言功能封装在 TypeScript 语言服务器中（ANTLR 语法 + LSP 协议）。由于 Lezer（CodeMirror 的解析引擎）不遵循 LSP，构建自定义适配器连接两者。

关键技术：令牌偏移量转换

ShopifyQL 语言服务器的令牌格式为 5 个整数：行号、起始字符、长度、类型、修饰符。其中行号和起始字符是相对前一个令牌的增量值，而非绝对位置。CodeMirror 则要求所有偏移相对于文档顶部。

解决方案是自定义 TokenIterator 类：

• 计算每一行长度（含换行符）
• 内部跟踪当前行和字符位置
• 将 ANTLR 相对偏移转换为 CodeMirror 绝对偏移

语言功能对接

• 语言服务器 doValidate → CodeMirror linting 插件
• doComplete → autocomplete 插件
• doHover → requestHoverTooltips 插件

Catalog API：聚类数十亿产品

聚类策略

Shopify 采用精度优先策略——展示错误结果比结果不完整更糟。先解决店内聚类（intra-store clustering），将单一全局任务分解为数百万个店铺级任务。

LLM 参与方式

"核心价值主张"框架作为提示核心：如果属性不改变买家购买的根本原因，则是变体；否则构成产品身份。两阶段管道：

1. 预分块：ANN 检索 + 稀疏平均链接，构建最多 200 个产品的语义相关块
2. 提取与聚类：提取品牌和型号分配 UPI，异常值检测默认保持合并

成本控制

单例检测器分析商店主题代码，Liquid 模板商家的确定性链接模式直接解决，LLM 仅处理模糊情况。动态结构化输出模式使字段顺序控制推理，清理非 ASCII 标记提升召回率 8%。

Ruvy：Ruby 到 WebAssembly 工具链

与 ruby.wasm 的差异

• 预初始化：Ruvy 在构建时预初始化 Ruby VM，运行时性能提升约 20%
• 编译耗时：Wasmtime 上比 ruby.wasm 快约 70%（446ms vs 1.66s）
• 无需运行时参数：不要求提供 WASI 参数，兼容边缘计算环境

使用方式

Ruvy 读取 Ruby 文件生成 index.wasm 模块，调用 _start 函数即执行代码。--prelude 标志预加载额外 Ruby 文件目录。

适用场景：Shopify Functions 中复用 Shopify Scripts 的 Ruby 逻辑。

Sidekick 拒绝能力：LLM 法官共识自动策展

问题根源

生产日志只记录成功案例，模型从未学过拒绝无法完成的请求。手动合并 600 条标注数据时，同一查询在生产和 Toloka 数据集标签相反，导致模型矛盾信号。

解决方案

四个前沿 LLM 法官（A/B/C/D）独立评估每条查询，仅当四者在判断结论和推理逻辑上完全一致时才采纳标签变更。分类体系必须互斥：可解决但需更多上下文、缺失能力、错误技能、歧义。

效果数据

• 分群技能评估分数：0.619 → 0.798（+28.9%）
• 拒绝准确率 86.3%，误报率 4.6%
• 法官与真实标签一致性接近 90%，Cohen's kappa 超过 0.75

Shopify Hack Days 39：音乐播放页面原型

平台级原型

13 人团队在三天内探索音乐产品页面。Jamie Guerrero 用 5 个 PR 构建了跨平台的 Audio 媒体类型：新数据库表、Merchandising::Audio 模型、Audio GraphQL 类型、Liquid drops、音频可视化器 web 组件。{{ product.media | media_tag }} 渲染播放器的方式与 3D 模型相同。

应用原型：Shop Sounds

• 完整 Shopify 应用：发布管理、产品变体同步、metafield 配置
• 音轨列表播放器：全局音频单例解决跨页面播放问题
• 六个 GLSL 着色器 × 七种配色方案 = 42 种视觉身份
• 巡演日期块：Haversine 公式计算到场距离，显示"23 英里外"
• 数据层全部用 metaobjects 和 metafields

分类：今日要点速览

相关链接：

• Gisting: Compressing LLM Agent context to ↑ throughput and ↓ cost
• How we raised mobile end-to-end test stability to 98%
• Sidekick's continual learning loop
• Building an agentic harness that outlasts the model
• Upgrading Checkout Blocks app to Polaris web components
• Inside Shopify Hack Days: Building a prototype for music-playing pages
• Clustering billions of products for agentic commerce with Catalog API
• Teaching Sidekick to say no: automated data curation with LLM judge consensus
• Introducing Ruvy
• Building a ShopifyQL Code Editor

XunbuOS Podcast：Shopify 工程深度技术周报

今天的 Shopify 工程博客为我们带来了十篇深度技术文章，覆盖了从 LLM Agent 优化、移动端测试稳定性到 Checkout 扩展迁移、巨型商品聚类等多个前沿领域。其中，关于 Gisting 上下文压缩 和 Sidekick 持续学习循环 的两篇文章揭示了 Shopify 在 AI 基础设施上的核心技术积累，而 移动端 E2E 测试 98% 稳定性 的重建方案则对任何移动团队都具有极高的参考价值。

Gisting：压缩 LLM Agent 上下文，吞吐量提升 16%

将 6000 token 系统提示词压缩至 1500

Gisting 将上下文压缩为一组学习得到的 token，在保持质量的同时让模型运行更快、成本更低。Gist token 是在训练时通过知识蒸馏学习嵌入的特殊 token，推理时直接替换系统提示词即可。Shopify 将 Sidekick GraphQL agent 的系统提示词从约 6,000 个 token 压缩至约 1,500 个 gist token（4:1 压缩比），预测质量无损。

关键优化

• 初始化：将 gist 嵌入初始化为提示词分块的均值（而非随机噪声），初始损失降低了 7 倍
• 压缩比：4:1 是质量开始下降的临界点
• 批处理平均损失：按整个批次取平均而非每个响应 token 取平均，保留了长响应中的信号
• 训练速度：预计算教师 logits 和数据预分词，将训练时间从三十小时缩短到六小时

性能收益

在 350 RPM 负载下，TTFT 下降 19%（438ms → 354ms），端到端延迟下降约 38%（6.8s → 4.2s），吞吐量提升 16%（20.2 QPS → 23.4 QPS）。实际生产中减少了 14% 的 GPU 用量。Gisting 与前缀缓存优化效果可以叠加，且能很好地融入持续学习循环。

移动端 E2E 测试稳定性从 50% 提升至 98%

旧框架的根因

旧测试基于 Appium 和 WebdriverIO，使用 React Native Test ID 定位元素。开发者常硬编码 pause(1000) 等待界面渲染，导致测试频繁闪崩，最终不得不从 PR 检查中移除。更糟的是，测试验证的是组件树中的节点存在，而非用户体验。

两层核心设计

Builder 风格测试 API：每个步骤必须携带断言，声明操作后屏幕应处于何种状态。提供可复用的切片（如 logIntoApp），逃生舱口显式标记为 UNSAFE_ 以便 code review 识别。

计算机视觉替代 Test ID：每个测试步骤截图，通过视觉查找目标。文本识别使用 PaddleOCR，图标匹配使用 OpenCV 将 Polaris SVG 与截图进行灰度匹配。Test ID 仍可作为后备，但需显式选择 UNSAFE_testID。

关键设计原则

• 对 AI Agent 友好：API 表面小、语法可预测，AI 可根据屏幕内容直接生成正确的测试代码
• 自诊断失败原因：每次运行生成带注释的视频，展示每个步骤在查找什么、在哪里查找
• 新测试在进入阻塞套件前，需在专用管道中多次运行，失败率超过阈值则被拒绝

Sidekick 的持续学习循环：成本削减 96%

飞轮核心架构

Shopify 的 GraphQL agent 每天从生产环境的失败中学习，通过自修复管道将失败对话转化为训练信号。一组前沿推理模型批评每个失败，仲裁者合并批评为单一修复指令注入用户回合之前，重放对话并由评判者打分，通过的轨迹成为强化学习的训练数据。

质量定义与评判者校准

质量始于评分准则（rubric），划分完整性、执行、响应质量和安全性等维度。地面真值应包含随机采样流量而非仅精选示例。使用 Cohen's kappa 衡量标注者间一致性，低分说明准则含糊不清。团队推崇使用 DSPy 和基于反思的优化器（GEPA、ACE）进行校准，并保持每个评判者小而专注。

实际效果

GraphQL agent 每秒服务高达 2,000 个请求。微调模型成本接近 100 万美元，相比前沿模型服务每年约 2700 万美元的成本，服务成本降低了 96%。Gisting 将系统提示词从约 6,000 tokens 压缩到约 1,500 个 gist tokens，TTFT 下降约 19%，端到端延迟下降约 38%，GPU 用量减少约 14%。

构建超越模型生命周期的 Agentic 框架

扫描工作流与成果

Shopify 应用安全团队构建了名为 Dispatch 的框架编排器，组织漏洞狩猎智能体进行安全扫描。在约六周内完成了超过 80 个应用的完整扫描，产生 300 多个发现，保守估值相当于超过 40 万美元的漏洞悬赏奖金，其中两个发现被评为"严重"（Critical）。

关键流程阶段

• 测试引导：找到正确的测试命令并验证测试套件可运行
• 架构文档化：生成数据模型、API、授权模式的共享描述
• 分区：将文件按领域分组，控制 token 数在上下文窗口的 20-30%
• 漏洞狩猎：每个分区并行运行狩猎智能体
• 验证：用不同模型顺序执行验证器，编写并执行测试
• 修复：自动创建分支并编写 PR

测试预言机原则

对于 IDOR 验证器，要求从公开调用站点反向推导、创建属于两个不同租户的测试夹具、不能仅依赖 Model 层单元测试、测试必须提取有影响力的跨租户数据、不得 stub 重要的上下游控制。无法证实的发现将被拒绝或降级。

成本控制

完整应用扫描成本在 50 至 300 美元之间（取决于模型选择和应用规模），增量 diff 扫描仅需约 5 至 50 美元。分区策略相比非分区方法提升了准确率和召回率，同时保持相对较低的成本。

Checkout Blocks 迁移到 Polaris Web Components，包体积缩减 85%

性能结果

所有扩展的传输包体积降幅在 40% 到 85% 之间。payment-icons 降低 84.4%，static-content 降低 54.1%，custom-field 降低 44.6%。按结账量加权的扩展加载时间（ELT），P50 提升 8%，P90 提升 7%。

架构变化

从 React 切换到 Preact，使用 remote-dom 将真实 DOM 节点从沙箱镜像到宿主环境。s-* 组件替换 Polaris React 组件树，代码库顺带改为 TypeScript。迁移采用"增量、最小优先"策略，在旧 core 旁新建 core-next 库，逐个扩展升级后合并。

64KB 包体积限制挑战

主要减重来源：切换到 Preact 后免除 react-reconciler（约 89KB）；自研精简版 Liquid 解析器 "droplet" 替代 liquidjs（约 73KB，gzip 后仅 13KB）；小型内部日期工具替代 dayjs（约 12KB）。markdown-to-jsx 因风险太高未替换，通过 pnpm workspace catalog 将 React 别名指向 Preact。

迁移中修复的 Bug

• ID 碰撞导致生产回滚：Preact 的 useId() 生成确定性 ID，同一扩展的两个实例生成相同 ID，导致第二个字段的链接错误打开第一个字段的弹窗。修复方案是编写 useStableId hook 生成随机且实例唯一的 ID
• textAlignment 属性移除：在 ui-extensions 中重新开放了 Paragraph 的 textAlignment 属性
• s-checkbox label 只接受纯字符串：重构组件，新增接受字符串或经过消毒的 HTMLElement 的 label slot

Hack Days 39：为产品页面构建音乐播放器

平台级 Audio 媒体类型

团队在五个 PR 中构建了真正的 Audio 媒体类型：新增 audios 数据库表、Merchandising::Audio 模型、Audio GraphQL 类型、admin-web 拖放支持、Liquid drops（AudioDrop、AudioSourceDrop）以及自定义 audio-visualizer Web 组件。{{ product.media | media_tag }} 渲染音频播放器的方式与渲染 3D 模型完全相同。

应用与店面

Shop Sounds 用 React Router、Polaris 和 Shopify App framework 构建，发布流程是约按顺序协调的七个 GraphQL 变更。店面端曲目列表播放器通过全局音频单例解决跨页面播放问题：应用嵌入块在页面主体中注入一个单独的 audio 元素和停靠的迷你播放器。

可视化器

六个自定义 GLSL fragment shader，共享相同 uniform 接口（uBass、uMid、uTreble、uEnergy），支持七种余弦调色板配色方案。六个 shader 乘以七种调色板，为艺术家提供 42 种视觉标识。由音频中频乘以时间驱动的 midShift 参数让调色板随音乐播放缓慢演变。

架构洞察

使用 Shopify 自身的 metaobjects 和 metafields 作为数据层，无需自定义数据库。发布作品是 metaobject，曲目列表是 JSON metafield，每首曲目的音频文件、可视化器配置等是产品 variant 上的 metafields。具有 storefront: PUBLIC_READ 访问权限的 Metafields 可自动通过 Liquid 提供给主题扩展。

Catalog API：对数十亿商品进行智能体语义聚类

核心价值主张框架

产品被购买的核心价值是什么？如果属性不改变核心价值，它就是变体；如果改变，就应拆分至不同的 UPI。蛋白质粉的风味不改变核心价值，巧克力和香草是变体；油漆的颜色改变核心价值，分属不同产品。这一原则被直接编码进提示词。

两阶段 LLM 管道

先由 singleton detector 做确定性预过滤：若主题已有明确的跨产品链接结构（metafield 引用、标签分组、collection 查询），直接分配 UPI，无需 LLM 处理。需要 LLM 时，用 FAISS HNSW 构建余弦相似度图（每个商品连接 100 个最近邻），再以稀疏平均链聚类（阈值 0.25，块大小上限 200）。

阶段 1（提案）：LLM 输出严格 JSON，为每个产品 ID 分配 brand 和 model 字符串。先输出 patterns 数组（观察到的命名模式），再标注产品，强制模型在上下文中推理。

阶段 2（批判）：对提案簇进行异常值检测，默认保留原簇除非有明确证据表明核心价值不同。

动态结构化输出突破

通过 OpenAI Structured Output 严格强制 JSON schema，让每个输入产品 ID 都在输出中拥有必需属性。将商品 ID 重映射为规范化 ID 提高缓存命中率，清理输出中的非 ASCII 标记在评测数据上将召回率提升 8%。

教 Sidekick 学会拒绝：LLM 评审共识

问题的表现

生产训练数据只包含成功查询，零拒绝样本，导致技能模型过于"乐于助人"。面对无法实现的查询（如查找是医生的客户，Shopify 并不存储职业数据），模型生成返回零结果的查询，给商家造成"零个客户匹配"的错误印象。

解决方案：评审共识管道

将小型 Toloka 数据集（约 600 条标准查询 + 602 条拒绝注释）作为种子数据，运行四个前沿 LLM 作为自动化数据评审。四个模型各自独立评估，只有在决策和推理两方面都达成一致才接受标签变更，分歧样本被过滤而非仲裁。

分类体系严格互斥：需要更多上下文、缺少能力、错误的技能、存在歧义。这些类别必须互斥，否则评审分歧会向下游传播。

结果

启用拒绝能力后，细分技能评估分数从 0.619 提升到 0.798（相对提升 28.9%）。拒绝准确率 86.3%，误报率 4.6%。评审模型与真实标签种子数据的一致性很强：四个模型的预测准确率接近 90%，Cohen's kappa 均在 0.75 以上。

经验教训

• 小型种子数据集的价值远超其规模，评审模型会继承种子数据中的偏差
• 分类体系的互斥性不容妥协
• 在早期管道中，全体一致共识优于单一模型的置信度分数
• 拒绝是产品功能，不是失败

Ruvy：将 Ruby 编译为 WebAssembly，性能提升 20%

预初始化带来性能优势

Ruvy 构建在 ruby.wasm 之上，在构建 Wasm 模块时就完成了 Ruby 虚拟机的预初始化。使用 Wasmtime 运行时，"Hello world" 场景耗时从 56.262ms 降至 44.543ms。Cranelift 编译器将 Wasm 模块编译为原生代码的耗时减少了约 70%（1.659s → 446.31ms）。

运行时无需指定参数

Ruvy 生成的 Wasm 模块无需在运行时提供文件路径作为 WASI 参数，这使其能兼容无法为启动函数配置额外 WASI 参数的计算环境，如边缘计算服务。这对希望将 Shopify Scripts 中的 Ruby 逻辑复用到 Shopify Functions 中的 Partners 尤其有吸引力。

构建 ShopifyQL 代码编辑器：ANTLR 到 Lezer 的桥梁

核心挑战：标记偏移转换

ShopifyQL 语言服务器基于 ANTLR TypeScript 目标构建，遵循 LSP 协议。CodeMirror 使用自己的 Lezer 解析引擎，两者偏移系统不兼容：ANTLR 的偏移值是增量式的（相对于前一个标记），而 CodeMirror 中一切都是相对于文档顶部的。

解决方案：自定义 TokenIterator

TokenIterator 接收文档并计算每行长度（含换行符），追踪当前行和当前字符，将 ANTLR 风格的行、字符和标记长度描述符转换为 CodeMirror 风格的起始和结束偏移。核心逻辑简洁：moveToLine 累加行数并重置字符位置，moveToCharacter 在当前行内增量移动，getStartOffset 对前面所有行长度求和再加上当前字符位置。

适配器架构

ShopifyQL 查询传递给语言服务器，服务器返回标记流，适配器将标记转换为 Lezer 节点类型，构建描述文档的缓冲区，再从缓冲区生成 Lezer 树。前端所有 ShopifyQL 语言功能（分词、解析、补全、悬停提示、代码检查）都封装在 TypeScript 语言服务器中，由 ANTLR 语法生成，并通过 Protobuf 在 Go 和 TypeScript 之间共享类型。

相关链接：

• Gisting: Compressing LLM Agent context to ↑ throughput and ↓ cost
• How we raised mobile end-to-end test stability to 98%
• Sidekick's continual learning loop
• Building an agentic harness that outlasts the model
• Upgrading Checkout Blocks app to Polaris web components
• Inside Shopify Hack Days: Building a prototype for music-playing pages
• Clustering billions of products for agentic commerce with Catalog API
• Teaching Sidekick to say no: automated data curation with LLM judge consensus
• Introducing Ruvy
• Building a ShopifyQL Code Editor

XunbuOS Podcast：Shopify 工程团队的 AI 基础设施、测试稳定性与性能优化实践

今天的动态来自 Shopify Engineering 博客的多篇文章，聚焦于 AI Agent 基础设施、移动端测试框架重建、UI 扩展性能优化，以及编程语言工具链的实践。核心主题围绕如何在生产环境中持续改进 AI 系统、如何构建可靠的测试体系，以及如何通过架构调整优化性能。

Gisting：压缩 LLM Agent 上下文以提升吞吐量并降低成本

4:1 压缩比的上下文蒸馏

Gisting 将长系统提示词压缩为一组可学习的 token，在保留预测质量的同时显著降低推理成本。Shopify 将 Sidekick GraphQL agent 的系统提示词从约 6,000 token 压缩到约 1,500 个 gist token，压缩比 4:1。

实现方式：通过知识蒸馏学习特殊 token 的嵌入，冻结模型权重，仅训练 gist 嵌入。推理时将完整提示词替换为 gist token 即可，无需自定义 attention mask 或额外编码器。

负载测试数据

在 350 RPM 负载下：

• 首 token 延迟（TTFT）中位数从 438ms 降至 354ms（下降 19%）
• 端到端请求延迟中位数从 6.8s 降至 4.2s（下降约 38%）
• 吞吐量从 20.2 QPS 提升至 23.4 QPS（提升 16%）
• 生产工作负载中 GPU 减少了 14%

与前缀缓存的叠加效应

Gisting 与前缀缓存的优化效果并非互斥，两者叠加使用。前缀缓存无法消除解码成本——每个生成的 token 都要关注序列中的每一个键。Gisting 降低了注意力计算和 KV 缓存读取的成本，在批量大小增大时对吞吐量的影响尤为显著。

Autoresearch 找到最优超参数

Shopify 将 autoresearch 循环指向训练器，自动提出方案、训练、评估并重复。三个关键优化：

• 初始化：用系统提示词分块的均值初始化 gist 嵌入，而非随机噪声，初始损失降低了 7 倍
• 压缩比：4:1 是该领域复杂度的最优比例
• 数据数量与多样性：策划庞大且多样的数据集弥合剩余差距

如何将移动端端到端测试稳定性提升至 98%

旧架构的问题

Shopify 移动应用通过 WebdriverIO 在 Appium 上运行 E2E 测试，使用 React Native Test ID 定位元素。问题在于测试经常因屏幕加载慢一秒而失败，“元素未找到”错误频发。更严重的是，测试在断言错误的东西——断言组件树中存在节点，而非商家真正能看到或使用的体验。

构建器风格测试 API

团队围绕 Appium 构建了一个有主见的封装层：

• 每个步骤都带有断言：不能在没有声明后续屏幕内容的情况下点击或输入
• 可复用步骤片段：logIntoApp 等命名序列可被任何测试引用
• 逃生舱口以 UNSAFE_ 为前缀：规避护栏的选项被刻意命名以劝阻使用
• 可读性足以让 AI 代理编写测试：API 表面小、语法可预测

计算机视觉替代 Test ID

每个步骤截取屏幕截图，像商家一样在视觉上查找元素。文本识别由 PaddleOCR 处理，OpenCV 将截图与 Polaris 设计系统的 SVG 进行匹配。Test ID 仅作为后备方案，需通过 UNSAFE_testID 显式选择。

稳定性数据

新 API 成为阻塞性 CI 的数周后，测试稳定性达到 98%（旧 API 为 50%）。剩余的失败主要来自偶发网络故障和模拟器启动失败。新测试在进入阻塞性套件前需在专门流水线多次运行，失败率超过阈值即被拒绝。

Sidekick 的持续学习循环

从失败中学习的飞轮

前沿模型不会自行从生产环境学习，但每次失败都是关于产品的宝贵知识。Shopify 构建了持续学习循环，将生产经验压缩到模型权重的连续空间中，同时将服务成本削减 96%。

质量定义作为奖励信号

评分标准（rubric）将产品需求转化为评分标准：完整性、执行、响应质量和安全性。两位最佳标注者盲目标记 25 个随机样本，使用 Cohen's kappa 衡量一致性。每个分数背后的推理过程是校准算法的金矿。

校准评判者

使用 DSPy 和基于反思的优化器（GEPA、Agentic Context Engineering）校准评判者。评判者需通过回溯测试：能恢复已知 A/B 测试的胜负方向吗？运行有针对性的降级测试，故意使行为变差并确认标准做出反应。

自愈管道与强化学习

• 挖掘生产流量中的难负样本：评判者评低分且暴露模型薄弱环节的对话
• 前沿推理模型对失败进行批判性分析，仲裁者合并为修复指令并注入用户回合前
• 重放对话，评判者评分，通过的轨迹成为强化学习数据
• SFT 蒸馏完整轨迹（包括推理过程），GRPO 使用评判者作为奖励信号
• 管道每日运行，全参数微调与 GRPO 交替进行

成本与性能数据

• 服务成本从约 2700 万美元/年降至接近 100 万美元/年（削减 96%）
• Gisting 将系统提示词从约 6,000 token 压缩到约 1,500 token
• TTFT 下降约 19%，端到端延迟下降约 38%
• 相同 GPU 上每秒请求数增加约 16%，GPU 需求减少约 14%

构建一个比模型更持久的 Agentic 框架

Dispatch 框架的九阶段工作流

Shopify 应用安全团队构建了 Dispatch，一个轻量级 Ruby 客户端，将智能体扫描的复杂性从扫描编写者处抽象出来：

1. 测试引导：自动发现测试命令并验证套件可运行
2. 架构文档化：生成数据模型、API、授权模式等共享上下文
3. 文件编目：建立相关文件的扁平清单
4. 分区：按领域分组，每个分区控制在上下文窗口的 20%-30% token 量
5. 狩猎：并行部署狩猎智能体，支持跨仓库搜索
6. 验证：使用不同模型运行验证器，对抗性审查降低误报
7. 后处理：去重、严重性评分
8. 报告：整合为人类可读输出
9. 修复：创建分支编写 PR 描述

关键成果

超过 80 个应用完成全量扫描，包括 Shopify Core（全球最大的 Rails 单体仓库之一）。过去六周内数千次扫描，产生 300 多个发现，保守估计价值超过 40 万美元的 bug bounty 等价回报。

成本方面，全量应用扫描约 50-300 美元，增量 diff 扫描仅需 5-50 美元。

核心经验：编码严格的发现准则

最初尝试的"安全通才"多智能体工作流产生了大量不可用的理论性发现。结论是：必须在智能体中编码严格的发现准则，专门的漏洞类别智能体比通才型更可靠。

升级 Checkout Blocks 应用至 Polaris Web Components

传输体积缩减 40%-85%

Checkout Blocks 的五个高流量结账扩展完成了从 React + Remote UI 到 Preact + remote-dom + Polaris web components 的迁移：

扩展加载时间（ELT）的 P50 降低 8%，P90 降低 7%。

64KB 硬性限制的挑战

2026-01 remote-dom CLI 对每个扩展包强制执行 64KB gzip 硬性限制。旧扩展体积超过限制两倍。关键削减项：

• 移除 react-reconciler（约 89KB）：切换到 Preact 后免费获得
• 替换 liquidjs（约 73KB）：自研极简 Liquid 解析器 "droplet"（gzip 后 13KB vs 22KB），用 42,000 行生产对等语料验证
• 替换 dayjs（约 12KB）：小型内部日期工具
• 保留 markdown-to-jsx（约 15KB）：通过 pnpm workspace catalog 将 React 别名到 Preact

过程中修复的 Bug

• ID 碰撞：useId() 生成确定性 ID 导致同一扩展两个实例生成相同 ID，引发模态框错乱。这是唯一一次生产回滚，当天回滚次日修复上线
• 文本对齐：Polaris web components 移除了 textAlign 属性，需在 ui-extensions 上重新暴露 textAlignment
• s-checkbox label 插槽：重构为接受字符串或 HTMLElement，支持带内联链接的条款模式

经验总结

• 硬性包体积限制虽有挑战，但迫使团队做出此前一直推迟的决策
• 指标是真正的回滚信号：纪律性的逐扩展指标加谨慎的每日发布
• 用生产数据验证而非合成用例
• AI 擅长机械性工作：agent skill 处理重复性转换，将团队时间解放给需要判断力的决策

Shopify Hack Days：为音乐产品页面构建音频播放器

原生 Audio 媒体类型的平台验证

13 人团队在第 39 届 Hack Days 中探索了为何音乐人不在 Shopify 销售数字音乐。"音乐与录音"产品在过去一年创造了超过 10 亿美元的 GMV。

团队在三天内构建了原生 Audio 媒体类型（五个 PR 跨 Core、Admin API、admin-web 和 storefront），一个完整的发行管理应用，六个由实时音频驱动的 GLSL 着色器，同步歌词生成，以及带地理定位的巡演日期板块。

架构：metaobjects 作为数据层

发布项目是 metaobject，曲目列表是 JSON metafield，音频文件、可视化配置、歌词是产品变体上的 metafields。具有 storefront: PUBLIC_READ 访问权限的 metafields 可通过 Liquid 自动用于主题扩展。

关键架构决策是全局音频单例：一个单例 audio 元素注入页面主体，带有停靠的迷你播放器，导航到新页面时音频不中断。

Catalog API：聚类数十亿商品

精确率优先策略

聚类将相关变体和产品归入统一通用产品标识符（UPI）。团队选择精确率优先：展示错误结果比结果不完整更糟糕——买家可以原谅遗漏某个变体，但绝不会原谅收到错误商品。

核心价值主张框架

关键判断问题是：买家主要购买这个产品的目的是什么？如果属性不改变答案，它就是变体；如果改变答案，它就成为产品身份的一部分。

例：蛋白粉的口味是变体（买家购买的是营养和健身效果），油漆的颜色是独立产品（买家购买的是外观）。

两阶段 LLM 管道

• Pre-chunking：ANN 检索（FAISS + HNSW）+ 稀疏平均链接（UPGMA），构建最多 200 件商品的相关 chunk
• 第一阶段：LLM 提取品牌 + 型号，相同 brand:model 对归入同一 UPI
• 第二阶段：异常检测——给定提议的聚类，识别不属于其中的商品。批判比创造容易得多

动态结构化输出 Schema

关键创新是 schema 按每个 chunk 动态生成：为每个产品 ID 定义必填属性，LLM 无法跳过商品。枚举约束防止幻觉——outliers 数组列出簇中所有有效产品 ID，LLM 只能输出真实存在的 ID。

数据策展：用 LLM Judge 共识训练 Sidekick 说"不"

训练数据的盲区

生产训练语料中的每个示例都是成功案例，被拒绝的案例永远不会出现在日志中。结果是模型从未学会说"不"——当被问到无法完成的查询时，模型生成返回零结果的查询而非直接拒绝。

严格共识优于松散置信度

四位前沿 LLM 作为自动化数据裁判，遵循三个原则：

• 校准：使用 Toloka 种子数据集的少样本示例校准，锚定人工标注者实际标记为"不可能"的内容
• 共识门控：四位裁判对结论和推理过程完全一致才接受标签，分歧样本被过滤而非仲裁
• 互斥分类体系：四个互斥类别——需要更多上下文、缺少能力、技能错误、模糊不清

效果数据

• 评估分数从 0.619 提升到 0.798（相对提升 28.9%）
• 拒绝准确率达 86.3%，假阳性率 4.6%
• 四个模型的预测准确率接近 90%，Cohen's kappa 均高于 0.75

数据飞轮闭环

改进后的模型上线后，其生产流量成为下一轮采样池。新模式由裁判组合标注后加入训练语料。每次微调循环都从比上一轮更大、更干净的基础上出发。

Ruvy：用 Ruby 构建 WebAssembly 模块

预初始化 VM 带来 20% 性能提升

Ruvy 构建在 ruby.wasm 之上，利用预初始化 Ruby VM 及预加载文件的性能优势。基准测试（Wasmtime 执行 _start 函数）：

Wasm 编译到本地代码的时间减少约 70%（从 1.659s 降至 446ms）。

无需运行时 WASI 参数

Ruvy 创建的模块无需提供文件路径作为 WASI 参数，兼容无法配置额外参数的边缘计算服务。

使用方式

cargo run --package=cli ruby_examples/hello_world.rb -o index.wasm
wasmtime index.wasm
# Hello world

--preload 标志将目录中每个文件包含进 Ruby VM，使定义对输入文件可用。

构建 ShopifyQL 代码编辑器

用适配器连接 ANTLR 与 CodeMirror

ShopifyQL 的语法由 ANTLR 定义，前端语言功能封装在符合 LSP 的 TypeScript 语言服务器中。CodeMirror 使用自己的 Lezer 解析引擎，不符合 LSP。团队创建了适配器，将 ANTLR token 流转换为 Lezer 可理解的缓冲区。

Token 偏移的挑战

ANTLR 的 token 偏移是相对前一个 token 的，而行号可能为负（如注释在主通道解析后处理时，指针需要向上移动）。CodeMirror 的偏移相对于文档顶部，换行符和空白会影响起始偏移。

解决方案是自定义 TokenIterator 类：接收文档并计算每行长度，跟踪当前行和字符，将 ANTLR 风格的行/字符/长度描述符转换为 CodeMirror 风格的起始/结束偏移。

额外语言功能

语言服务器的 doValidate 适配到 CodeMirror 的 linting 插件，doComplete 适配到 autocomplete 插件，doHover 适配到 requestHoverTooltips 插件。

相关链接：

• Gisting: Compressing LLM Agent context to ↑ throughput and ↓ cost
• How we raised mobile end-to-end test stability to 98%
• Sidekick's continual learning loop
• Building an agentic harness that outlasts the model
• Upgrading Checkout Blocks app to Polaris web components
• Inside Shopify Hack Days: Building a prototype for music-playing pages
• Clustering billions of products for agentic commerce with Catalog API
• Teaching Sidekick to say no: automated data curation with LLM judge consensus
• Introducing Ruvy
• Building a ShopifyQL Code Editor

Shopify 今日技术动态：Agent 架构、性能优化与平台升级

欢迎来到 XunbuOS Podcast。今日聚焦 Shopify 在 AI Agent 基础设施、移动端测试、Checkout Extensibility 迁移等方向的最新实践，以及多个开源项目的发布。

Gisting：压缩 LLM Agent 上下文以提升吞吐量并降低成本

4:1 上下文压缩

Gisting 将 Sidekick GraphQL agent 的系统提示词从约 6,000 token 压缩到约 1,500 个 gist tokens，且不损失预测质量。方法基于 2022 年提出的 gisting 技术，通过知识蒸馏学习特殊 token 的嵌入表示，推理时将完整提示词替换为这些 gist tokens。

性能收益

在 350 RPM 负载下：

• 首 token 延迟（TTFT）中位数从 438ms 降至 354ms（-19%）
• 端到端请求延迟中位数从 6.8s 降至 4.2s（-38%）
• 吞吐量从 20.2 QPS 提升至 23.4 QPS（+16%）
• 生产环境 GPU 用量减少 14%

与 prefix caching 叠加

Gisting 与 prefix caching 优势不互斥。Gisting 降低注意力计算和 KV cache 读取成本，后者在批处理规模增大时对吞吐量影响显著。两者可同时使用。

关键实现细节

• 冻结模型权重，仅训练 gist 嵌入
• 用 KL 散度训练学生 logits 匹配教师 logits
• 部署时无需自定义注意力掩码或特殊服务路径
• 用均值初始化嵌入将初始损失降低 7 倍

How we raised mobile end-to-end test stability to 98%

旧框架的问题

基于 Appium 和 WebdriverIO 的旧框架缺少约束，开发者容易写出不稳定测试。常见问题包括不加等待直接点击、硬编码 pause(1000)、断言实现细节而非用户体验。

重建框架：强约束 Builder API + 计算机视觉

新框架的两大核心变化：

严格的 Builder 风格 API：

• 每个步骤必须携带断言，应用状态偏离预期时立即失败
• 可复用步骤切片（如 logIntoApp）
• 规避路径命名为 UNSAFE_ 前缀，便于代码审查警示
• API 表面小、语法可预测，对 AI Agent 友好

计算机视觉替代 Test ID：

• 文本识别用 PaddleOCR，图标匹配用 OpenCV（与 Polaris SVG 灰度匹配）
• Test ID 降级为可选后备方案
• 测试编写速度大幅提升，直接写 touch({ text: 'Save' })
• 每次运行生成带注释的视频，失败时直观展示查找内容

效果与建议

• 测试稳定性从 50% 提升至 98%
• 建立了"推广前稳定性门禁"：新测试需多次运行证明稳定后才能进入阻塞性 CI 套件
• 建议将 API 限制为少量核心命令，用计算机视觉交互，要求每个动作包含验证过的断言

Sidekick's continual learning loop

飞轮循环：从生产失败到模型权重

Sidekick 的持续学习循环将生产环境中的失败压缩为模型权重，在超越前沿模型质量的同时将服务成本削减 96%。GraphQL 智能体是核心例证，每秒服务高达 2,000 个请求。

四步循环

1. 定义质量评分标准（rubric）：将产品需求转化为几个有评分的标准，用 Cohen's kappa 衡量标注者间一致性，作为评判器（judge）的天花板
2. 校准评判器：使用 DSPy 和基于反思的优化器（GEPA、ACE），用 A/B 测试结果回溯验证，保持评判器小而专注
3. 自动研究改善基线：智能体提出对提示词、工具链的修改，按评判器评估，保留提升分数的修改
4. 参数空间优化：挖掘生产流量中的难负样本，经自修复管道转化为训练信号，通过 SFT + GRPO 折叠回模型权重

效果数据

• 微调后模型服务成本从约 2700 万美元/年降至约 100 万美元/年（-96%）
• Gisting 将 TTFT 降低 19%，端到端延迟降低 38%
• 相同流量需要约 14% 更少的 GPU

Building an agentic harness that outlasts the model

多智能体安全扫描框架

Dispatch 是 Shopify 的内部框架编排器，覆盖 80+ 应用的完整扫描，包括 Shopify Core 单体。六周内执行数千次扫描，产生 300+ 发现，保守估计价值超过 40 万美元的等效漏洞赏金。

核心工作流

管道包含测试引导、架构文档、文件编目、分区、狩猎、验证、后处理、报告、修复九个有序阶段。关键创新：

• 测试预言机：验证智能体将验证逻辑嵌入应用现有测试，必须有跨租户数据、完整公开技术栈路径、有影响力的数据提取
• 分区策略：目标 token 数约为模型上下文窗口的 20-30%，按相关领域分组，准确率和召回率均有提升
• 模型互验：使用不同模型进行验证，对抗性审查降低噪声

成本控制

• 完整应用扫描成本 50-300 美元（取决于模型和应用规模）
• 增量差异扫描成本 5-50 美元
• 分区比全仓扫描成本更低且发现质量更高

经验教训

• 通才智能体在严格指导原则编码下可填补专业类别的空白，但需要额外严格审查
• 确定性脚本优于让智能体自由控制流程，格式错误更少、结果可验证
• 框架比模型更持久：新模型频繁更新，但针对自身生态调优的框架才是长期资产

Upgrading Checkout Blocks app to Polaris web components

迁移背景与结果

Checkout Blocks 的五个高流量结账扩展从 React + Remote UI 迁移到 remote-dom、Preact 和 Polaris Web Components（API 版本 2026-01）。2026 年 10 月 1 日起，早于 2026-01 版本的扩展部署将被阻止。

• 传输体积缩减 40% 到 85%
• 扩展加载时间（ELT）P50 -8%，P90 -7%
• 包体积从 gzip 后约 100-112KB 降至 64KB 预算内

关键架构决策

Preact 替代 React：remote-dom 直接镜像真实 DOM 节点，任何能渲染 DOM 的框架都能工作。移除 react-reconciler 节省约 89KB。

自研 Liquid 解析器 "droplet"：替换 liquidjs（约 73KB），gzip 后约 13KB vs 22KB（-40%）。用 42,000 行真实商家配置构建对等测试套件验证。

保留 markdown-to-jsx：通过 pnpm workspace catalog 将 React 别名到 Preact，无需重写，零行为变化。

踩过的坑

• ID 冲突：Preact 的 useId() 在同一渲染树内确定性生成 ID，导致两个相同扩展实例产生相同 ID。用 useStableId hook 生成随机实例唯一 ID 修复
• 文本对齐：Polaris Web Components 的 Paragraph 移除了 textAlign 支持，需重新暴露 textAlignment
• s-checkbox 标签插槽：只接受纯字符串，需重构支持 HTMLElement

经验总结

• 硬性包体积限制逼出了拖延已久的替换
• 用生产数据而非虚构用例验证（Liquid 对等语料 + 真实配置）
• AI 负责机械性转换工作，工程师专注判断决策
• 升级策略：增量、先小后大、每天最多一个扩展

Inside Shopify Hack Days: Building a prototype for music-playing pages

原型探索：为商品页面构建音频播放器

13 人团队在三天内为 Shopify 商品页面构建了完整的音频播放器原型。背景：音乐与录音制品品类在过去一年产生超过 10 亿美元的 GMV，但没有内置试听功能。

核心成果

• 平台级 Audio 媒体类型：通过五个 PR 在 Core、Admin API、storefront 添加原生音频支持，包括 audios 数据库表、Audio GraphQL 类型、Liquid drops 和 audio-visualizer Web 组件。{{ product.media | media_tag }} 渲染方式与 3D 模型相同
• Shop Sounds 应用：支持发布管理、曲目上传、变体同步、metafield 附加、发布到在线商店
• 曲目列表播放器：全局音频单例解决页面导航时音频中断问题
• 六个 GLSL 着色器可视化器：Fluid、Geometric、Particles、Waveform、Tunnel、Voronoi，共享统一接口（uBass、uMid、uTreble、uEnergy），7 种配色方案 × 6 个着色器 = 42 种视觉身份
• 巡演日期模块：metaobjects 驱动，带 Haversine 公式计算的地理定位

关键架构决策

使用 metaobjects 和 metafields 作为完整数据层而非自定义数据库。具有 storefront: PUBLIC_READ 权限的 metafields 可通过 Liquid 自动用于主题扩展，无需自定义 API。

Clustering billions of products for agentic commerce with Catalog API

问题背景

Shopify 托管数百万商家的数十亿商品列表，没有共享 Schema。AI 购物代理需要理解不同商家的不同组织结构（单一列表 vs 按口味拆分）描述的是同一产品线。

核心价值主张框架

关键问题：买家购买这个产品的主要目的是什么？如果属性不改变答案，它是变体；如果改变答案，它是产品身份的一部分。

示例：蛋白粉的口味是变体，油漆的颜色是产品身份。

两阶段 LLM 流水线

预分块：先用 ANN 检索（HNSW + FAISS）+ 稀疏平均链接（UPGMA），将产品分组成最多 200 个产品的语义相关块。阈值 0.25，超过即停止合并。

阶段 1（品牌 + 型号提取）：模型先输出 patterns 数组分析店铺命名惯例，再为每个产品分配 brand:model 字符串。相同 brand:model 对归入一个 UPI（shop_id:brand:model 格式）。

阶段 2（离群值检测）：审阅提议聚类，标记不匹配项。默认保持项目在一起，除非有明确证据表明核心价值不同。

关键创新：动态结构化输出 Schema

每个块的 Schema 动态生成，为输入中每个产品 ID 定义必需属性。LLM 不可能跳过产品——Schema 强制完整性。枚举约束防止幻觉 ID。改变 Schema 字段顺序会改变提取质量。

效果数据

• 精确度优先策略，先满足严格精确度阈值再最大化召回率
• 单例检测器通过解析 Liquid 模板识别无需聚类的商店
• 从输出结构中清除非 ASCII 标记使召回率提升 8%

Teaching Sidekick to say no: automated data curation with LLM judge consensus

问题：生产数据没有拒绝示例

Sidekick 的客户细分技能模型在生产日志（全部成功查询）上训练，从未学过拒绝无法实现的请求。遇到无法查询的数据（如职业为医生的客户）时，模型会生成返回零结果的查询而非拒绝。

解决方案：LLM 评审共识流水线

1. 种子数据集：600 条标准查询 + 602 条拒绝标注（Toloka 专家标注）
2. 校准评审员：四位前沿 LLM 先用种子数据校准，锚定人类标注的"不可能"案例
3. 严格全票共识：四位评审员对判决及推理逻辑完全一致才接受标签变更。分歧样本过滤而非仲裁，精确率优先于召回率
4. 四个互斥分类：需要更多上下文、能力缺失、技能错误、内容模糊

效果数据

• 细分技能评估分数从 0.619 提升至 0.798（+28.9%）
• 拒绝准确率 86.3%，误报率 4.6%
• 评审集成预测准确率接近 90%，四模型 Cohen's kappa 均超过 0.75

经验总结

小种子数据集价值超乎寻常；分类体系互斥性不容妥协；早期流水线共识优于置信度；拒绝是产品功能而非失败。

Introducing Ruvy

Ruby 到 WebAssembly 的新工具链

Shopify 开源 Ruvy，以 Ruby 代码为输入生成可执行该代码的 Wasm 模块。构建在 ruby.wasm 之上，核心优势：

• 预初始化 Ruby VM 和文件：构建时而非运行时初始化，性能提升约 20%
• 无需运行时 WASI 参数：兼容无法配置额外 WASI 参数的计算环境（如边缘计算服务）

性能对比

在 Wasmtime 中实例化并执行 _start：

使用方式

cargo run --package=cli -- ruby_examples/hello_world.rb -o index.wasm
wasmtime index.wasm

额外 Ruby 文件用 --preload=prelude/ 标志加载，目录中每个文件都加载到 Ruby VM 中。

Building a ShopifyQL Code Editor

问题：将 ANTLR 语言服务器连接到 CodeMirror

ShopifyQL 的语言功能封装在基于 ANTLR 的 TypeScript 语言服务器中，遵循 LSP。但 CodeMirror 使用自己的 Lezer 解析引擎，不遵循 LSP。重写为 Lezer 语法不合理，因此构建了一个适配层。

核心难点：分词偏移量转换

ShopifyQL 语言服务器的分词以 5 个一组的整数返回，偏移值是相对于前一个分词的增量值。CodeMirror 则一切相对于文档顶部。

关键点：

• 行号可为负数（注释在其他通道中非顺序解析，如 -2）
• 起始字符是相对于前一个分词的增量
• 分词始终按顺序计算（ANTRL 按非顺序模式解析时可能产生负行号）

解法：自定义 TokenIterator

接收 ANTLR 风格的行、字符、长度描述符，将当前行和字符移动到适当位置，用行长度计算 CodeMirror 风格的起始偏移（含换行符）。

export class TokenIterator {
  private currentLine = 0;
  private currentCharacter = 0;
  private lineLengths: number[];

  // 按行计算长度（含换行符），
  // 根据行/字符增量移动位置，
  // 结合起始偏移和分词长度计算结束偏移
}

语言功能对接

• doValidate → CodeMirror linting 插件
• doComplete → autocomplete 插件
• doHover → requestHoverTooltips 插件

这种架构模式适用于其他没有现成 Lezer 语法但已有 LSP 语言服务器的语言。

相关链接：

• Gisting: Compressing LLM Agent context to ↑ throughput and ↓ cost
• How we raised mobile end-to-end test stability to 98%
• Sidekick's continual learning loop
• Building an agentic harness that outlasts the model
• Upgrading Checkout Blocks app to Polaris web components
• Inside Shopify Hack Days: Building a prototype for music-playing pages
• Clustering billions of products for agentic commerce with Catalog API
• Teaching Sidekick to say no: automated data curation with LLM judge consensus
• Introducing Ruvy
• Building a ShopifyQL Code Editor

XunbuOS Podcast：今日 Shopify 技术动态

今日要闻：Shopify 工程团队在 AI agent 基础设施上发布了多项重要成果——Gisting 提示词压缩技术将推理成本降低 96%，移动端 E2E 测试稳定性提升至 98%，Sidekick 持续学习闭环和 Catalog API 产品聚类为 agentic commerce 铺平道路。同时，Checkout Blocks 完成向 Polaris web components 的迁移，Ruvy 工具链将 Ruby 引入 WebAssembly。

Gisting：压缩 LLM Agent 上下文，提升吞吐、降低成本

4:1 提示词压缩

Shopify 在 Sidekick GraphQL agent 上实现了 gisting 技术，将系统提示词从约 6,000 个 token 压缩到约 1,500 个 gist token，且不损失预测质量。核心方法是通过知识蒸馏训练一组特殊 token 的嵌入，推理时用这些 token 替换完整提示词。

性能收益

在 350 RPM 负载下：首 token 时间（TTFT）中位数从 438ms 降至 354ms（-19%），端到端延迟从 6.8s 降至 4.2s（-38%），吞吐量从 20.2 QPS 提升至 23.4（+16%）。这 16% 的吞吐量提升直接转化为 14% 的 GPU 节省。

与 prefix caching 叠加

Gisting 与 prefix caching 不互斥。Prefix caching 无法消除解码成本——每个生成的 token 都要与序列中所有键做注意力计算；Gisting 降低了 KV 缓存读取量，两者叠加效果更佳。部署简单：gist 嵌入直接写入模型嵌入矩阵，推理时唯一改动是将提示词替换为 gist token 序列。

Autoresearch 调优关键发现

• 初始化：用提示词片段均值初始化 gist 嵌入，初始损失降低 7 倍
• 压缩比：4:1 是预测质量开始下降的临界点
• 损失归一化：按批次平均优于按 token 平均，避免模型产生幻觉

移动端 E2E 测试稳定性提升至 98%

旧方案的问题

基于 Appium + React Native Test IDs 的测试框架存在根本性缺陷：点击元素后立即操作下一个元素导致"元素未找到"失败；开发者随手加 pause(1000) 掩盖问题；断言验证的是组件树节点而非用户体验，甚至能点击被遮挡的单元格并错误通过测试。

重建方案：严格 API + 计算机视觉

Builder 风格测试 API：每个步骤强制携带断言，不声明操作后屏幕应显示什么就无法执行 tap、wait 或 type。逃生舱口统一使用 UNSAFE_ 前缀标记。可复用切片如 logIntoApp 是具名步骤序列。

计算机视觉替代 Test IDs：每个步骤截取屏幕截图，PaddleOCR 负责文本识别，OpenCV 将截图与 Polaris 设计系统的 SVG 匹配。编写测试只需看着模拟器写下 touch({ text: 'Save' })。AI 代理也能利用这种语法与屏幕内容一一对应的优势直接生成正确代码。

效果数据

测试稳定性从 50% 提升至 98%，两个平台均达到此水平。每次运行生成带注释的视频，失败可在几秒内自诊断。新测试进入阻断套件前需通过专门 pipeline 的多次运行稳定性验证。

Sidekick 的持续学习闭环

飞轮架构

前沿模型是启动产品的最快路径，但成本高昂且无法从生产中学习。Shopify 构建了持续学习闭环：从生产流量捕获失败案例 → 前沿推理模型小组评判 → SFT 蒸馏 + GRPO 强化学习 → 部署改进模型 → 产生更多信号。GraphQL agent 是该闭环的标杆案例。

核心成果

• 质量超越前沿模型：专用微调模型在 GraphQL 任务上超过前沿基线
• 成本降低 96%：前沿模型服务年成本约 2700 万美元，微调模型接近 100 万美元
• 延迟降低：Gisting 压缩后 TTFT 下降 19%，端到端延迟下降 38%
• GPU 节省 14%：吞吐量提升 16%

关键方法论

评分标准（Rubric） 是质量契约：将产品需求转化为完整性、执行、响应质量和安全性的具体评分标准。标注者用它标注随机抽样流量（而非精选样本），形成客观事实。标注者间一致性用 Cohen's kappa 衡量，0.2 左右说明评分标准模糊需迭代。

评判器校准：使用 DSPy 和反思型优化器（GEPA、ACE）校准评判器。需针对历史 A/B 测试回溯验证，并运行退化测试确认评分标准能响应行为变化。每个评判器保持小而专注。

自愈管道：由前沿推理模型小组评判每个失败案例，仲裁者整合评判成单一修复指令，重放对话后评分，通过则成为 RL 训练轨迹。训练分两阶段：SFT 蒸馏完整轨迹（含思维链），GRPO 以评判器为奖励信号优化。

构建经得起时间考验的 Agentic Harness

Dispatch 框架

Shopify 应用安全团队构建的自动化代码审查系统。工作流分八个阶段：测试引导 → 架构文档化 → 文件编目 → 分区（每块控制在上下文窗口 20-30%）→ 并行 Hunter agent 狩猎 → Verifier agent 编写执行测试证明可利用性 → 去重评分 → 报告修复。

关键经验

测试预言机：Web 漏洞没有编译器标志作为直接预言机。Verifier agent 被严格编码：必须从公开调用点倒推、创建跨租户 fixture、提取有影响力的数据。无法证明的发现会被降级或拒绝。

专业 agent 优于通才：多 agent 通才工作流产生高噪音低精度结果。专业 agent 编码了多层安全知识和 Shopify 上下文，针对特定漏洞类型。

确定性优先：结构化输出场景用确定性脚本而非纯模型生成，显著减少格式错误。

实际成果

六周内完成数千次扫描，覆盖 80+ 应用（含 Shopify Core Rails monolith），产出 300+ 发现，含两个 Critical 漏洞，保守估计价值超 40 万美元 bug bounty。单次全量扫描成本 50-300 美元，增量差异扫描仅 5-50 美元。

Checkout Blocks 升级到 Polaris Web Components

迁移概况

Checkout Blocks 全部五个高流量结账扩展从 React + Remote UI bridge（2025-07 API）迁移到 Preact + Polaris web components + remote-dom（2026-01 API）。2026 年 10 月起部署旧版本扩展将被阻止，这是一次必要的技术债偿还。

性能收益

传输包体积下降 40%-85%。扩展加载时间（ELT）按结账量加权后 P50 下降 8%，P90 下降 7%。payment-icons 扩展包体积削减 84.4%，ELT P50/P90 改善 11.7%/11.9%。

64KB 硬限制下的工程决策

• Preact 替换 React 后去掉 react-reconciler（节省约 89KB）
• 自研 droplet Liquid 解析器替换 liquidjs（gzipped 13KB vs 22KB），基于 42,000 行对齐测试语料
• 自研日期工具替换 dayjs（节省约 12KB）
• pnpm workspace catalog 将 React 别名指向 Preact

平台层问题修复

迁移中发现并修复了 ID 碰撞问题（曾致生产回滚，自研 useStableId 钩子解决）、Polaris Paragraph/Heading 缺 textAlign 属性（在 ui-extensions 重新开放）、s-checkbox 不支持带内联链接的 label（重构为 slot）。

Catalog API：聚类数十亿产品支持 Agentic Commerce

核心挑战

数百万商家对同一真实产品的建模方式不同：有人用一个产品加变体，有人为每种口味创建独立产品。AI 购物代理需要理解这些不同结构描述的是同一产品线。

精确率优先策略

聚类质量用精确率和召回率衡量，两者此消彼长。Shopify 选择设定硬性精确率阈值、在该约束下最大化召回率——显示错误产品比结果不完整更不可接受。

两阶段方法

预分块：HNSW 构建最近邻图（每件产品连接 100 个最近邻），稀疏平均链接（UPGMA）合并簇，距离阈值 0.25，最大块大小 200 件产品。

两阶段 LLM 流水线：第一阶段提取品牌和型号，按 shop_id:brand:model 分组；第二阶段做异常检测，默认保留分组，除非有明确证据表明核心价值不同。批评性审查比创造性工作容易得多，局部判断即可。

关键工程决策

规则优先、LLM 兜底：单件检测器解析 Liquid 模板代码，识别已显式连接变体的商家，直接确定性解析，避免 LLM 成本和误合并。

动态结构化输出模式：为每个分块生成严格 JSON 模式，输入中的每个产品 ID 必须出现在输出中，模型不可能跳过产品。字段顺序控制推理过程，枚举约束防止幻觉。清理非 ASCII 字符使召回率提升 8%。

"核心价值主张"框架：问模型"买家主要购买这个产品的目的是什么？"——口味不改变蛋白粉的核心价值所以是变体，颜色改变涂料的核心价值所以是独立产品。

教 Sidekick 说"不"：LLM 评判共识驱动的自动数据策展

问题根源

生产训练语料中的每个样本都是成功案例——模型做对了事才上线。模型从未学过如何拒绝无法实现的请求，遇到这种情况会生成返回零结果的查询，误导商家以为真的没有匹配客户。

自动化策展引擎

以 600 条标准查询 + 602 条拒绝标注的小型种子数据集为起点，引入四个前沿 LLM 作为评审员，对全部训练语料进行评审。

严格共识优于置信度：四个评审员独立评估，只有全部一致且推理逻辑一致才通过共识闸门。分歧样本直接过滤而非强行仲裁，精确率优先。

互斥分类体系：四个分类选项——需要更多上下文、缺少能力、技能错误、表述模糊。分类不互斥会导致评审员分歧并向下游放大。

效果数据

客户细分技能评估得分从 0.619 提升至 0.798（+28.9%）。拒绝准确率 86.3%，误报率 4.6%。评审员与真实种子数据一致性近 90%，Cohen's kappa 均高于 0.75。

数据飞轮

改进后的模型上线后，其生产流量成为下一采样池——新拒绝场景、新商家表述经评审员标注后进入语料库。每一轮微调都比上一轮数据更大、标签更干净。核心经验：小型高质量种子数据集价值远超预期；分类互斥性不可妥协；早期共识优于置信度；拒绝是产品功能而非系统缺陷。

Ruvy：Ruby 代码编译为 WebAssembly

工具定位

Ruvy 以 Ruby 代码为输入，生成可执行该代码的 WebAssembly 模块。构建于 ruby.wasm 之上，提供两项关键优势：预初始化 Ruby 虚拟机带来约 20% 性能提升（Wasmtime 编译时间减少 70%）；无需在运行时提供 WASI 参数，兼容无法配置额外 WASI 参数的边缘计算环境。

使用方式

cargo run --package=cli -- ruby_examples/hello_world.rb -o index.wasm 编译 Ruby 文件为 Wasm 模块。--preload 标志指定额外 Ruby 文件目录。

场景价值

Shopify 开源此项目的动机是让开发者社区能在 Wasm 运行时中直接构建执行 Ruby 程序。对 Shopify 合作伙伴而言，解决与 Shopify Functions 的兼容性，将 Shopify Scripts 的 Ruby 逻辑复用至 Functions 可能尤为有价值。

构建 ShopifyQL Code Editor

架构方案

ShopifyQL Notebooks 采用 CodeMirror 提供引导式代码编辑体验。核心挑战：ShopifyQL 语言服务器基于 ANTLR 语法构建并遵循 LSP 协议，而 CodeMirror 使用自己的 Lezer 解析引擎——两者不兼容。团队没有重写 ANTLR 语法，而是构建自定义适配器在两种解析体系间转换。

Token 偏移量转换难点

ANTLR token 偏移量是相对前一个 token 的。例如，在 SHOW 前加五个空格后，product_title 的偏移量不变，因为 SHOW 和 product_title 之间的空格没变。更复杂的是乱序解析的语言特性（如注释）会产生负偏移量——解析器在解析完主通道后指针上移导致 -2 行偏移。

TokenIterator 解决

核心是一个 TokenIterator 类：接收文档推导每行长度（尾随空白正确表示），内部跟踪行和字符位置，将 ANTLR 风格的行/字符/长度描述符转换为 CodeMirror 风格的绝对起始偏移量。实现简洁但推导过程困难。

扩展语言功能

将语言服务器的 doValidate、doComplete、doHover 分别适配到 CodeMirror 的 linting、autocomplete、requestHoverTooltips 插件，实现语法高亮、代码补全、检查等完整编辑体验。

相关链接：

• Gisting: Compressing LLM Agent context to ↑ throughput and ↓ cost
• How we raised mobile end-to-end test stability to 98%
• Sidekick's continual learning loop
• Building an agentic harness that outlasts the model
• Upgrading Checkout Blocks app to Polaris web components
• Inside Shopify Hack Days: Building a prototype for music-playing pages
• Clustering billions of products for agentic commerce with Catalog API
• Teaching Sidekick to say no: automated data curation with LLM judge consensus
• Introducing Ruvy
• Building a ShopifyQL Code Editor

XunbuOS Podcast：Gisting 压缩、移动端测试稳定性与智能体基础设施

今日 Shopify 工程博客聚焦于大规模 AI 基础设施与开发者工具链的深度优化。从将 LLM Agent 上下文压缩 4:1 的 Gisting 技术，到移动端 E2E 测试稳定性从 50% 提升至 98% 的框架重构，再到 Sidekick 的持续学习飞轮，核心主题是：如何让系统在规模化下变得更便宜、更快、更可靠。

Gisting：压缩 LLM Agent 上下文，提升吞吐量、降低成本

4:1 上下文压缩

Gisting 将 Sidekick GraphQL agent 的系统提示从约 6,000 token 压缩到约 1,500 个 gist token，且不损失预测质量。通过知识蒸馏学习特殊 token 的 embedding，推理时用它们替换完整系统提示。

在 350 RPM 下，首 token 时间（TTFT）中位数从 438ms 降至 354ms，端到端请求延迟中位数从 6.8s 降至 4.2s，吞吐量从 20.2 QPS 提升至 23.4 QPS。生产环境中 GPU 用量减少 14%。

与 prefix caching 叠加

Gisting 与 prefix caching 并不互斥。Gisting 降低了注意力计算和 KV cache 读取的成本，后者在大 batch size 时对吞吐量影响尤为显著。两者在生产栈中同时使用。

Autoresearch 找到的关键优化

• 初始化：用系统提示分块均值初始化 gist embedding，初始 loss 降低 7 倍
• 压缩比：4:1 是预测质量开始下降的临界点
• 速度优化：预计算 teacher logits 并预分词数据，训练时间从 30 小时缩短到 6 小时

如何将移动端 E2E 测试稳定性提升至 98%

旧方案的根本缺陷

Shopify 移动应用旧的 E2E 测试套件（Appium + WebdriverIO）稳定性仅 50%，最终被移出 PR 阻塞检查。根因是框架自身制造不稳定：无强制测试模式，开发者常用 pause(1000) 掩盖问题；断言检查的是节点存在性而非用户体验。

约束严格的封装框架

• 构建器模式 API：每一步必须附带断言；可复用步骤序列；逃生舱口以 UNSAFE_ 为前缀
• 计算机视觉替代 Test ID：PaddleOCR 做文本识别，OpenCV 将截图与 Polaris SVG 图标匹配。编写测试从"打开检查器查找 testID"变为"看着模拟器直接写 touch({ text: 'Save' })"
• 统一 CLI：本地、CI 模拟器、远程真机通过 --runner 参数无缝切换

结果

测试稳定性从 50% 提升至 98%。每次运行生成带注释的视频，失败时能直接看到 OCR 搜索的内容和实际点击位置。

Sidekick 的持续学习循环

飞轮架构

Sidekick 的持续学习循环将生产环境中的失败压缩为模型权重。自修复管道每天运行：一组前沿推理模型批评失败案例，仲裁器合并批评为修复指令，重放对话后用评判器重新评分，通过的轨迹成为强化学习数据。

GraphQL 智能体每秒处理高达 2,000 个请求，通过该循环：

• 质量：超过前沿模型基线
• 成本：服务成本从约 $27M/年降至接近 $1M，降低 96%
• 延迟：Gisting 压缩后 TTFT 下降 19%，端到端延迟下降 38%
• 硬件：GPU 需求减少 14%

定义质量是第一步

评分标准（rubric）是奖励信号。用 Cohen's kappa 衡量标注者间一致性（目标约 0.2 以上），该一致性是评判器的上限。收集标注时要包含详细的"为什么"推理。

从离散工件到连续参数

框架改进（提示词、工具定义）趋于平稳后，通过挖掘匿名化生产流量中的难负样本进入参数优化。训练分两阶段：监督微调蒸馏完整轨迹（含推理过程），再用 GRPO 以评判器作为奖励信号优化。

构建一个比模型更长久的智能体框架

Dispatch 工作流

Shopify 应用安全团队构建的智能体框架可自动完成漏洞发现、测试验证、生成修复 PR。对 80+ 应用执行完整扫描，产生 300+ 发现，其中两个被评为"严重"，估计价值超过 40 万美元漏洞赏金。

单次完整扫描成本 50-300 美元，增量差异扫描仅 5-50 美元。约六周内在"我们睡觉时"完成了数千次扫描。

关键经验

• 测试预言机：将验证嵌入应用现有测试框架，编码严格指南（如 IDOR 测试必须创建两个租户的固件、提取有影响力的跨租户数据）
• 分区优于全量：按目标 token 数量（上下文窗口的 20-30%）分组文件，准确率和召回率都有提升
• 确定性脚本优先：直接提供确定性脚本而非让代理管理完整流程，减少格式错误输出
• 跨模型验证：用另一个模型的错误纠正某个模型的错误

将 Checkout Blocks 升级至 Polaris Web Components

Bundle 体积缩减 40%-85%

五个高流量结账扩展从 React + Remote UI 迁移到 Preact + remote-dom + Polaris web components，传输体积显著下降：

扩展加载时间 ELT P50 下降 8%，P90 下降 7%。

64KB 硬性限制驱动的工程决策

2026-01 版本 remote-dom CLI 对每个扩展 bundle 强制执行 64KB gzip 硬性限制，塑造了主要工程工作：

• 移除 react-reconciler（约 89KB）：切换 Preact 后免费获得
• 替换 liquidjs（约 73KB）：自研 "droplet" 解析器，用 42,000 行生产对等语料库验证（商户真实 Liquid 配置对等测试），gzip 后 13KB vs 原 22KB
• 替换 dayjs（约 12KB）：自研轻量日期工具
• 保留 markdown-to-jsx（约 15KB）：通过 pnpm workspace catalog 将 React 别名到 Preact，无需修改即可运行

过程中修复的 Bug

• ID 冲突：Preact useId() 生成确定性 ID，同一扩展多个实例产生重复 ID 导致 modal 错乱。修复为随机实例唯一 ID 的 useStableId hook
• 文本对齐：textAlign 从 Polaris web components 移除，推动上游在 ui-extensions 重新开放 textAlignment
• s-checkbox label slot：只接受纯字符串，重构为接受 HTMLElement，支持"接受条款"内联链接模式

渐进式发布策略

从小型低风险扩展开始，每天最多发布一个。唯一一次生产回滚（日期选择器 ID 冲突）靠监控当天发现、次日修复上线。

使用 Catalog API 聚类数十亿商品

核心价值主张框架

关键问题是：买家主要为了什么而购买此产品？如果属性不改变答案，它是变体；如果改变答案，它是产品身份的一部分。

两阶段 LLM 流水线

• 预分块：ANN 检索（FAISS + HNSW）+ 稀疏平均链接，将产品组装为最多 200 个产品的语义相关邻域，为 LLM 提供正确上下文
• 阶段 1：提取每产品 brand 和 model 字符串，相同 brand:model 对归入同一 UPI
• 阶段 2：离群值检测，默认保持项目在一起，除非有明确证据表明核心价值不同

动态结构化输出 Schema

为每个分块动态生成严格 JSON schema，为每个产品 ID 定义必需属性，LLM 无法返回跳过产品的响应。schema 中字段顺序可控制推理：要求 patterns 数组在 products 对象之前，强制模型先分析店铺命名模式。

singletons 预过滤

分析店铺主题代码判断是否需要聚类。只有一小部分店铺真正需要基于 LLM 的聚类，其余通过确定性规则解决。

教 Sidekick 说 "不"：LLM 评判器共识的数据策展

问题：生产数据盲区

生产训练语料库中的每个样本都是成功案例，模型完全用成功查询训练，从未学会拒绝无法实现的请求。结果遇到无法实现的查询时，模型生成返回零结果的查询，给商家错误印象。

解决方案：四模型共识门控

1. 小型 Toloka 标注数据集（~1,200 条）作为种子
2. 四个前沿 LLM 作为评审员，先用 few-shot 校准
3. 所有四个模型对同一判定达成一致且推理一致时，标签才通过共识门控。分歧样本被过滤而非仲裁

分类体系必须互斥

四个互斥类别：需要更多上下文、缺少能力、错误技能、存在歧义。模糊类别导致评审员分歧，不一致向下游传播。

结果

细分技能评估分数从 0.619 提升到 0.798（+28.9%）。拒绝准确率 86.3%，误报率 4.6%。Cohen's kappa 均高于 0.75（高度一致）。

Introducing Ruvy：预初始化 Ruby VM 的 WebAssembly 工具链

Ruvy vs ruby.wasm

Ruvy 构建在 ruby.wasm 之上，关键差异：

• 预初始化 Ruby VM：构建时预初始化，运行时性能提升约 20%
• 无需 WASI 参数：模块无需提供文件路径，兼容无法配置 WASI 参数的计算环境（如边缘计算服务）

性能对比

Wasm 编译时间减少约 70%。

使用方式

$ cargo run --package=cli -- ruby_examples/hello_world.rb -o index.wasm
$ wasmtime index.wasm
Hello world

--preload 标志将指定目录中的 Ruby 文件包含到 VM 中。

构建 ShopifyQL 代码编辑器

ANTLR 与 CodeMirror 的集成

ShopifyQL 语言服务器基于 ANTLR 构建并遵循 LSP，而 CodeMirror 使用自己的 Lezer 解析引擎。解决方案是创建适配器：将语言服务器生成的 ANTLR token 流转换为 Lezer 缓冲区。

Token 偏移的挑战

ANTLR token 的偏移是增量式的，每个值相对于前一个 token。注释甚至可能出现在主通道解析之后，产生负行数。自定义 TokenIterator 类跟踪当前行和字符，结合行长度计算 CodeMirror 风格的绝对偏移。

连接语言功能

适配语言服务器的 doValidate、doComplete、doHover 分别与 CodeMirror 的 linting、autocomplete、requestHoverTooltips 插件对接，提供语法高亮、代码补全、检查和悬停提示。

相关链接：

• Gisting: Compressing LLM Agent context to ↑ throughput and ↓ cost
• How we raised mobile end-to-end test stability to 98%
• Sidekick's continual learning loop
• Building an agentic harness that outlasts the model
• Upgrading Checkout Blocks app to Polaris web components
• Inside Shopify Hack Days: Building a prototype for music-playing pages
• Clustering billions of products for agentic commerce with Catalog API
• Teaching Sidekick to say no: automated data curation with LLM judge consensus
• Introducing Ruvy
• Building a ShopifyQL Code Editor

Shopify 用 Gisting 技术将 LLM Agent 提示词压缩 4 倍：延迟降低 38%，GPU 节省 14%

原文链接：Gisting: Compressing LLM Agent context to ↑ throughput and ↓ cost

长系统提示词（System prompt）每个请求可能占用数千个 token。提示词越长，推理速度越慢，成本越高。当使用专用硬件为同一流量提供服务时，这会直接导致需要更多的 GPU。

Shopify 实现了一种名为 "gisting" 的技术，基于论文 《Prompt Compression and Contrastive Conditioning for Controllability and Toxicity Reduction in Language Models》 ¹ 中首次提出的思想。这项技术让模型以短提示词的成本，获得长提示词带来的行为优势。

Gisting 的核心效果

通过 gisting，Shopify 将 Sidekick GraphQL agent 的系统提示词从约 6,000 个 token 压缩到约 1,500 个 gist token（4:1 压缩率），且没有损失预测质量。其原理是通过知识蒸馏（knowledge distillation）学习一组特殊 token 的嵌入（embeddings），推理时将系统提示词替换为这些 token。

在每分钟 350 个请求（RPM）的压力测试下，性能提升显著：

• 中位首 token 时间（TTFT）：从 438ms 降至 354ms，下降 19%
• 中位端到端请求延迟：从 6.8s 降至 4.2s，下降约 38%
• 吞吐量：从每秒 20.2 个查询（QPS）提升至 23.4 QPS，提升 16%

这些改进直接转化为生产环境中的 GPU 节省：在服务 GraphQL 流量的硬件配置下，GPU 使用量减少了 14%。

Gisting 的工作原理

Gist token 是添加到模型词表中的特殊 token。Shopify 训练一组嵌入序列，使其在上下文中的替换效果等同于模型看到完整提示词。在 4:1 压缩率下，每四个提示词 token 对应一个 gist token。训练过程中，模型权重被冻结，仅训练 gist 嵌入。

知识蒸馏的训练流程：

1. 教师阶段：模型看到完整的自然语言提示词，为模型响应的每个位置生成教师 logits
2. 学生阶段：将完整提示词替换为 gist token，再次运行同一模型，生成学生 logits
3. 损失计算：使用教师 logits 和学生 logits 之间的 KL 散度（KL divergence）训练 gist 嵌入

部署经过 gisting 处理的模型非常简单。训练完成后，gist 嵌入直接写入模型的嵌入矩阵，新的 gist token 注册为模型分词器（tokenizer）中的特殊 token。推理时模型的加载和运行方式与其他模型无异：无需自定义注意力掩码、额外的编码器或特殊的服务路径。唯一的变化在请求端——将提示词替换为 gist token 字符串。压缩的全部成本只在训练时支付一次。

为什么前缀缓存（Prefix Caching）不够

Gisting 的优势与前缀缓存并不互斥。所有现代服务引擎都维护 KV 缓存（KV cache），用于存储已见过序列的键和值。当新请求包含缓存中已有的序列（通常包括系统提示词）时，引擎直接获取该序列的 KV 张量，无需重新计算。

但前缀缓存不能消除解码成本。模型每生成一个 token，该 token 都需要对序列中的每个键进行注意力计算，无论是否被缓存。由于解码受限于内存带宽，每个生成的 token 都必须从高带宽内存中流式读取整个 KV 缓存，这种读取开销会随缓存序列长度线性增长。

Gisting 同时降低了注意力计算和 KV 缓存读取的成本，后者在批次规模增大时对吞吐量的影响尤为显著。Gisting 和前缀缓存的优化效果可以叠加，Shopify 在实验和生产服务栈中同时使用了这两种技术。

Autoresearch 找到最优配方

为了调整超参数，Shopify 将一个 autoresearch 循环指向了训练器。它会提出一个配方，训练 gist 嵌入，评估生成的模型，然后重复该过程。

在 autoresearch 循环中，有三项优化影响尤为显著：

• 初始化：不用随机噪声初始化嵌入，而是将系统提示词按长度 k 进行切分（k 由 k:1 的压缩比确定），并用第 n 个系统提示词分片的均值来初始化第 n 个 gist 嵌入。这一优化将初始损失降低了 7 倍
• 压缩比：尝试一系列压缩比后，找到了预测质量开始下降的临界点。对于 Shopify 所涉领域的复杂程度，4:1 是最优压缩比；其他领域会有所不同
• 数据量与多样性：策划一个大规模且多样化的数据集，填补了剩余的差距

autoresearch 还帮助实现了训练基础设施中的关键优化：

• 损失归一化改进：按每个响应 token 取平均会导致模型产生幻觉；按批次取平均则能保留长响应中的更多信号，生成稳定的嵌入
• 速度优化：预计算教师 logits 并对数据进行预分词，将一次完整训练的时间从三十小时缩短到六小时

Gisting 与持续学习

Gisting 也能很好地融入 Shopify 的持续学习循环。一旦获得模型的蒸馏 gist 嵌入，就可以将该模型视为持续学习的新起点。

具体做法是：使用 gist 嵌入作为前缀进行后训练（post-train），并将梯度更新同时应用到模型权重和 gist 嵌入上。通过在增量数据上同时优化权重和 gist 嵌入，可以持续校准和改进模型，而无需每次都从零开始重新蒸馏 gist 嵌入，从而避免了大量的计算开销。

结论

长系统提示词虽然有用，但代价高昂。Gisting 允许 agent 以极少的 token 数量充分利用详尽指令的所有优势，从而降低延迟和 GPU 开销。在 GPU 需求持续超过供应的当今时代，每一次推理优化都至关重要，但同样不愿在质量上妥协。Gisting 让 Shopify 两者兼得，并已成为其新标准。

参考文献

1. Wingate, Shoeybi, and Sorensen. Prompt Compression and Contrastive Conditioning for Controllability and Toxicity Reduction in Language Models. 2022.

相关链接：

• Gisting: Compressing LLM Agent context to ↑ throughput and ↓ cost

Shopify 发布 Gisting：将 LLM Agent 上下文压缩 4 倍，吞吐量提升 16%

长系统提示词每个请求可能占用数千个 token，直接推高推理延迟、成本和 GPU 占用。Shopify 在 Sidekick GraphQL agent 上实现了 gisting 技术，将系统提示词从约 6,000 个 token 压缩到约 1,500 个 gist token（4:1 压缩比），且没有损失预测质量。

工作原理

Gist token 是添加到模型词汇表中的特殊 token。Shopify 冻结模型权重，仅训练这些嵌入向量。通过知识蒸馏学习：teacher pass 让模型看到完整提示词生成 logits，student pass 将提示词替换为 gist token，然后用两者间的 KL 散度训练嵌入。

部署很简单：训练完成后将 gist 嵌入直接写入嵌入矩阵，推理时唯一的改动是在请求侧将提示词替换为 gist token 字符串。

为什么前缀缓存不够

前缀缓存无法消除解码成本——每个生成的 token 仍要对序列中所有键进行注意力计算，KV 缓存读取量随序列长度线性增长。Gisting 同时降低注意力计算和 KV 缓存读取成本，且与前缀缓存的优化完全叠加。

效果数据

在 350 RPM 负载下，首 token 时间（TTFT）中位数从 438ms 降至 354ms，端到端延迟从 6.8s 降至 4.2s，吞吐量从 20.2 QPS 提升至 23.4 QPS（+16%）。在实践中，这直接转化为生产负载中约 14% 的 GPU 节省。

Autoresearch 找到的 3 个关键优化

• 初始化：用系统提示词分块的平均值初始化 gist 嵌入，初始损失降低 7 倍
• 压缩比：4:1 是本领域复杂度下的最优值
• 数据规模：大规模多样化数据集补齐剩余差距

此外，预计算 teacher logits 和预分词数据将完整训练从三十小时缩短到六小时。

Shopify 移动端 E2E 测试稳定性从 50% 提升至 98%：用计算机视觉替代 Test ID

Shopify 应用的 E2E 测试稳定性曾跌破 50%，被从 PR 检查中移除。通过重建测试框架，稳定性提升至 98%。核心是两层改造：严格的 builder 风格 API 和基于计算机视觉的元素定位。

旧框架的失败原因

基于 Appium 和 WebdriverIO，用 React Native Test ID 查找元素。没有机制强制良好测试模式：测试点击后不等待新界面渲染就继续操作，开发者常用 pause(1000) 碰运气。更隐蔽的问题是只验证节点存在于组件树中，而非用户真的能看到或使用它。

重建策略

1. Builder 风格测试 API

• 每一步都强制携带断言，测试一旦脱轨立即在出错步骤失败
• 可复用的步骤片段（如 logIntoApp）
• 逃生舱门必须加 UNSAFE_ 前缀，作为 code review 警示信号

2. 计算机视觉替代 Test ID

• 文本识别用 PaddleOCR，图标匹配用 OpenCV（与 Polaris 设计系统 SVG 匹配）
• Test ID 仅作为视觉匹配不可靠场景的兜底，需显式启用
• 附带红利：写测试更快——看到 "Save" 直接写 touch({ text: 'Save' })

3. 统一的 CLI 运行器 一个命令在本地、CI 模拟器或远程设备农场运行同一套测试，只需切换 --runner 参数。

关键经验

当你将"每一步断言"、"像用户一样找元素"和"杜绝 footgun"贯彻到 API 设计中时，曾被移出 CI 的测试套件在双平台上跑出了 98% 稳定性。剩余失败主要是偶发网络问题和模拟器启动失败。新测试必须先通过专门管线的多次运行才能进入阻塞性套件。

Sidekick 持续学习循环：服务成本降低 96%，质量超越前沿模型

前沿模型不会从生产环境中学习。用户纠正、被拒绝的输出不会让下一个响应变好。Shopify 构建了一个持续学习飞轮，将生产经验压缩到模型权重的连续空间中，在降低延迟和削减 96% 成本的同时，提供了比前沿模型更高质量的服务。

从定义质量开始

质量始于评分标准（rubric），将产品需求转化为几个标准：完整性、执行、响应质量和安全性。关键是用随机抽样流量而非精选示例构建真实基准。先让两位产品专家盲标 25 个样本并记录标注者间一致性（Cohen's kappa）。该一致性就是评判器的上限——目标不是让评判器"完美"，而是与人类一致性达到人类彼此之间的程度。

校准评判器

Shopify 用 DSPy 配合基于反射的优化器（GEPA、ACE）校准评判器。保持每个评判器小而聚焦，而不是把所有产品行为塞入一个。将评判器回测到之前的 A/B 测试中，并运行针对性降级测试确认指标响应。

从离散产物到连续参数更新

一旦 harness 改进趋于平稳（提示词、工具定义、编排代码），通过挖掘匿名化生产流量寻找困难负样本。一组前沿推理模型对每个失败进行批评，仲裁者合并为修复指令，从该点重放对话，评判器再评分。修复通过则成为强化学习轨迹。

训练分两阶段：

1. SFT：将修复后的完整轨迹（包括推理过程）蒸馏到较小模型
2. GRPO：用校准后的评判器作为奖励信号直接优化

自愈流水线每天运行，持续向训练语料库添加新轨迹，全参数微调后重复 GRPO。

飞轮效果：GraphQL Agent

• 质量：专业化模型超越前沿模型性能
• 成本：前沿模型服务每年约 2,700 万美元，微调后接近 100 万美元（-96%）
• 速度：gisting 压缩系统提示词后，TTFT 下降 19%，端到端延迟下降 38%
• 硬件：相同 GPU 上 QPS 提升 16%，相当于减少 14% GPU

Shopify 构建 agentic 安全编排器：扫描 80+ 应用发现 300+ 漏洞

Shopify 应用安全团队构建了名为 Dispatch 的 agentic 编排器，用于自动化代码审计和漏洞验证。在 Shopify Core（全球最大的 Rails 单体应用之一）上完成了超过 80 个应用的完整扫描，发现 300 多个漏洞，其中两个被评为 Critical，预计 bug bounty 奖励超 40 万美元。

工作流程

1. 测试引导：找到正确测试命令并验证测试套件可运行
2. 架构文档生成：描述数据模型、API、授权模式和边界
3. 文件编目和分区：将相关文件分组，限制在模型上下文窗口的 20-30%
4. 并行扫描：每个分区由不同 Hunter 代理扫描
5. 跨模型验证：Verifier 代理（使用不同模型）编写并执行真实测试验证可利用性
6. 后处理与修复：去重、严重性评分，为开发者生成带测试和上下文的 PR

关键经验

• 测试预言对 Web 漏洞验证至关重要：需要编写跨租户集成测试证明可利用性，不同于内存安全漏洞可通过编译标志验证
• 分区策略提升准确率：按漏洞类别调整分区大小
• 安全通才型 agent 效果不佳：容易陷入"潜在问题"追踪导致上下文耗尽，需要严格指导原则
• 用确定性脚本处理结构化输出：避免 malformed outputs
• 跨模型验证：一个模型的错误能发现另一个模型的盲点

Checkout Blocks 升级 Polaris Web Components：包体积缩减 85%，结账提速 12%

Checkout Blocks 的 UI 扩展运行在三分之一的定制结账页面上。由于 Shopify 正将整个 UI 扩展体系迁移至 remote-dom 和 Polaris Web Components，团队将全部五个扩展从 React + Remote UI 升级至 Preact + Polaris Web Components，代码库重写为 TypeScript。

核心成果

64KB 包体积限制下的策略

• 移除 react-reconciler（约 89KB）：切换 Preact 后自动获得
• 自研 Liquid 解析器 "droplet"（约 73KB → 13KB）：以官方 Liquid 规范为唯一事实来源，用 42,000 行真实商户配置构建对照测试套件，与 liquidjs 输出完全匹配
• 自研轻量日期工具替换 dayjs（约 12KB）：精确覆盖 custom-field 所需功能
• 保留 markdown-to-jsx（约 15KB）：通过 pnpm catalog 将 React 别名到 Preact，无需修改即可运行

过程中修复的 Bug

• ID 冲突（唯一一次线上回滚）：Preact useId() 在同扩展多实例时生成重复 ID，导致模态框打开错误。修复为随机且实例唯一的 useStableId hook
• 文本对齐：Polaris Web Components 的 Paragraph/Heading 移除了 textAlign，导致多列网格文本靠左。推动 ui-extensions 重新开放 textAlignment
• s-checkbox label 插槽：只接受纯字符串，破坏"接受条款"模式。重构为接受字符串或 HTMLElement，通过消毒只允许 s-text 和 s-link

给开发者的建议

"增量推进，从小到大"策略：在旧 core 旁建立 core-next，逐个升级扩展，优先处理最小风险最低的，每天最多发布一个。AI agent skill 处理了 React 到 Preact 转换的机械性工作，工程师专注于需要判断力的决策。60% 的扩展包体积削减来自替换过大的依赖，而这些决策在无硬性限制前一直被拖延。

Shopify Hack Days 39：为商品页面构建音乐播放原型

过去一年，归类为音乐与声音录制的产品创造了超过 10 亿美元 GMV，但 Shopify 上数字专辑的产品页面通常就是图片加购买按钮，没有内置试听功能。13 人团队在 3 天 Hack Days 中构建了完整原型：从平台级 Audio 媒体类型到带 6 个 GLSL 着色器的音乐播放器。

平台级音频支持

团队通过 5 个 PR 添加了真正的 Audio 媒体类型：audios 数据库表、Merchandising::Audio 模型、Audio GraphQL 类型、Admin 拖放支持、Liquid drops 和自定义 audio-visualizer Web 组件。结果 {{ product.media | media_tag }} 渲染音频播放器的方式与渲染 3D 模型完全相同。

店面播放器

曲目列表播放器是主题应用扩展块，通过 metaobjects 读取发行数据。关键架构决策是全局音频单例：通过应用嵌入块在页面正文注入单一 audio 元素，页面导航时音频不中断。

可视化器

6 个自定义 GLSL 片元着色器（Fluid、Geometric、Particles、Waveform、Tunnel、Voronoi）共享相同 uniform 接口（uBass、uMid、uTreble、uEnergy），每个支持 7 种配色方案（余弦调色板实现），共 42 种视觉身份。运行在 Three.js 上，Unreal Bloom 后处理强度由音乐能量驱动。

架构启示

使用 Shopify 自身的 metaobjects/metafields 作为数据层而非自定义数据库。发行是一个 metaobject，曲目列表是 JSON metafield，音频文件/可视化器配置/歌词是 variant 上的 metafields。发布流程约按顺序协调 7 个 GraphQL mutations。数据存在于 Shopify 商家期望的地方，与平台其余部分（搜索、webhooks、Storefront API）协同工作。

Shopify Catalog API：用 LLM 对数百万商品聚类，驱动智能体商务

Shopify 在数百万家商店托管着数十亿商品列表，没有共享数据模式。Catalog 是一个统一智能层，将所有相关变体和产品归到通用产品标识符（UPI）下，通过 Catalog API 提供给开发者和 AI 智能体。

精确度优先策略

两个指标始终处于紧张状态：精确度失败将不同产品错误归组（买家收到错误商品），召回率失败遗漏本应归组的变体。Shopify 选择精确度优先："展示错误的结果比展示不完整的结果更糟糕"。设定严格精确度阈值，在该约束下最大化召回率。

核心价值主张框架

关键问题：买家主要为此产品购买什么？如果属性不改变答案，就是变体；如果改变答案，就是产品身份的一部分。

• 蛋白粉：巧克力 vs 香草 → 变体（购买的是营养）
• 油漆：午夜蓝 vs 鼠尾草绿 → 不同产品（颜色就是产品本身）
• 手机壳：红色 vs 蓝色 → 变体（不能定义产品身份）

两阶段 LLM 流水线

预分块：嵌入每个产品，用 HNSW 构建 100 最近邻图，稀疏平均连接（UPGMA）聚类，阈值 0.25，最大块 200 个产品。

阶段 1（提议）：LLM 为每个产品提取 brand 和 model 字符串，相同 brand:model 对归入一个 UPI。系统提示先要求输出模式数组（分析商店命名约定），再标记产品。阶段 2（审查）：LLM 审查提议聚类，标记异常项，默认偏向保持项目在一起除非有明确证据表明核心价值不同。

动态结构化输出是关键突破

用 OpenAI 结构化输出，模式按块动态生成——每个产品 ID 在模式中定义必需属性，LLM 无法跳过产品。还通过 product_id 重映射（真实 ID → 规范化 ID）提高缓存命中率。

模式是比提示词更可靠的行为塑造工具：排序控制推理（模式数组在 products 对象之前）、枚举约束防止幻觉（outliers 数组只能输出实际存在的 ID）、模式本身是超参数。

教 Sidekick 学会说"不"：LLM 评审共识驱动的自动化数据策展

生产训练数据只捕获成功查询——无法教会模型何时拒绝。Sidekick 的客户细分技能在遇到不可能查询时（如"找到是医生的客户"，Shopify 不存储职业数据）会生成返回零结果的查询，让商家误以为是零匹配而非请求不可能实现。

问题根源

训练数据是数万条去标识化的生产查询，全部成功，零拒绝样本。模型从未学会说"不"。

解决方案：LLM 评审共识

将小型人工标注数据集（约 600 条标准查询 + 602 条拒绝标注）变成自动化策展引擎的种子：

1. 校准评审：用种子数据中的 few-shot 示例校准每个前沿 LLM 评审，锚定人类标注者实际标记为"不可能"的内容
2. 严格共识：只有 4 个评审对判定和推理都达成一致时，标签才能通过共识门槛。分歧被过滤而非仲裁——优先精确率而非召回率
3. 互斥分类体系：更多上下文可解 / 能力缺失 / 错误技能 / 歧义。模糊类别产生评审分歧并在下游放大

数据飞轮闭环

改进后的模型部署后，其生产流量（包括正确处理的新边界情况）成为下一轮采样池。新模式被评审打标签并加入语料库，每次部署资助下一次改进。

结果

关键经验

小型高质量种子数据集价值远超体量——评审会继承种子数据中的偏见和错误。在早期流水线中，共识优于置信度：如果 4 个独立模型无法就标签达成一致，交给人类裁决。拒绝是产品特性，不是失败——诚实拒绝（最好附上建议）比幻觉式回答好得多。

Shopify 开源 Ruvy：将 Ruby 代码编译为 WebAssembly 模块

Ruvy 构建在 ruby.wasm 之上，通过预初始化 Ruby 虚拟机提供运行时性能提升，且无需在运行时提供 WASI 参数。

使用方式

$ cargo run --package=cli -- ruby_examples/hello_world.rb -o index.wasm
$ wasmtime index.wasm
Hello world

--preload 标志可将目录中的每个 Ruby 文件包含到虚拟机中，使这些定义对输入文件可用。

与 ruby.wasm 的差异

相关链接：

• Gisting: Compressing LLM Agent context to ↑ throughput and ↓ cost
• How we raised mobile end-to-end test stability to 98%
• Sidekick's continual learning loop
• Building an agentic harness that outlasts the model
• Upgrading Checkout Blocks app to Polaris web components
• Inside Shopify Hack Days: Building a prototype for music-playing pages
• Clustering billions of products for agentic commerce with Catalog API
• Teaching Sidekick to say no: automated data curation with LLM judge consensus
• Introducing Ruvy
• Building a ShopifyQL Code Editor

Shopify 技术日报：从 E2E 测试稳定性到 AI 智能体基础设施

今天带来 Shopify 工程团队的多项技术实践，涵盖移动端测试稳定性提升、Sidekick 的持续学习闭环、AI 安全审查框架、Checkout Blocks 迁移、Catalog API 聚类引擎、Quick 内部托管平台及多款开源工具。

如何将移动端 E2E 测试稳定性提升至 98%

问题背景

Shopify 移动端应用的 E2E 测试曾因不稳定而阻塞正常功能的 PR。旧框架基于 Appium 和 WebdriverIO，缺乏强制性的测试模式规范，导致测试步骤间缺乏同步保障。常见的 pause(1000) 硬编码等待在屏幕加载稍慢时频繁失败，测试套件最终被迫从 PR 检查中移除。

技术方案

团队围绕 Appium 构建了严格封装层，包含两个核心组件：

构建器风格 API：每个步骤必须包含断言，声明屏幕在操作后应呈现的状态。可复用片段（如 logIntoApp）支持命名步骤序列。绕过保护措施的选项统一添加 UNSAFE_ 前缀。

计算机视觉定位：每个步骤截图后通过视觉方式定位元素。文字识别使用 PaddleOCR，图标匹配用 OpenCV 将 Polaris 设计系统中的 SVG 与截图做灰度匹配。Test ID 仅作为动态生成内容场景的备用方案。

效果数据

新 API 投入使用数周后，测试稳定性从 50% 提升至 98%。团队还建立了"稳定门禁"，新测试在进入核心套件前必须通过多次运行验证。

Sidekick 的持续学习闭环

核心架构

Sidekick 采用持续学习飞轮：将生产环境中的失败自动转化为训练信号，通过强化学习压缩进模型权重。整个闭环以 GraphQL 代理为实战案例，该代理每秒最多服务 2,000 个请求。

关键实现

质量定义：通过评分标准（rubric）将产品需求转化为可量化的评分维度，使用 Cohen's kappa 验证标注者间一致性。校准后的 LLM 评判者作为奖励信号。

自修复管道：前沿推理模型小组对每次失败进行评判，仲裁者整合成修复指令，重放对话后由评判者再次评分。通过的轨迹进入 SFT + GRPO 训练管道。

Gist 压缩：将长系统提示词从约 6,000 token 压缩至 1,500 个学习到的 gist token。

效果数据

• 服务成本降低 96%（从每年约 2,700 万美元降至接近 100 万美元）
• 首 token 生成时间下降约 19%，端到端延迟下降约 38%
• 相同 GPU 上每秒处理请求数增加约 16%，GPU 使用减少约 14%

构建比模型更持久的智能体安全审查框架

框架设计

Dispatch 编排器是一个轻量级 Ruby 客户端，以多阶段流水线运行智能体扫描：测试引导 → 架构文档 → 文件编目 → 分区 → 猎手 → 验证 → 后处理 → 报告 → 修复。关键设计包括：

• 跨模型验证：验证者使用与猎手不同的模型进行对抗性审查
• 测试预言机：验证者必须编写并执行真实集成测试证明漏洞可利用性
• 分区策略：目标 token 数约为模型上下文窗口的 20-30%，按相关领域分组

成果

六周内运行数千次扫描，产生 300 多个发现项，保守估计价值超过 40 万美元的漏洞赏金。两个发现项被评为"严重"。

经验教训

• Web 漏洞可利用性确认困难，IDOR 验证需确保跨租户数据提取、公共堆栈覆盖和上下层控制评估
• 确定性脚本优于让智能体自由发挥，结构化输出显著减少格式错误
• 新模型带来更好的猎手，但也产生更多"听起来自信的噪音"——框架比模型更持久

Checkout Blocks 迁移至 Polaris Web Components

迁移背景

Checkout Blocks 的 UI 扩展占 Shopify 所有定制化结账页面渲染量的三分之一。旧方案基于 React + Remote UI bridge，API 将在 2025-07 版本弃用。团队将所有五个扩展迁移至基于 remote-dom 的 2026-01 版本。

架构变动

• React → Preact + Polaris web components（s-* 标签）
• JavaScript → TypeScript
• liquidjs → 自研 "droplet" 解析器（gzip 后 13KB vs 22KB）
• dayjs → 自研轻量日期工具

性能数据

关键坑点

• ID 冲突：useId() 生成确定性 ID，同一扩展多实例导致弹窗错位。修复为 useStableId hook 生成随机实例唯一 ID
• 64KB 包体限制：移除 react-reconciler 节省约 89KB，替代 liquidjs 节省约 73KB
• 文本对齐：Polaris web components 移除 Paragraph 的 textAlign 属性，需重新开放

使用 Catalog API 对数十亿商品进行聚类

问题定义

Shopify 承载数百万店铺中的数十亿商品列表，彼此间无共享数据模式。AI 购物智能体需要识别不同商家的商品列表是否描述同一产品线。核心指标权衡：精确率失败（不同产品误合并）和召回率失败（本应归组的变体遗漏）。

技术方案

核心价值主张框架：LLM 判断"买家购买这个产品的主要目的是什么"——属性不改变答案则为变体，改变则为独立产品。

预分块：使用嵌入 + HNSW 构建最近邻图，通过稀疏平均连接（UPGMA）合并语义相关的产品分块，每个分块最多 200 个产品。

两阶段 LLM 流水线：

• 阶段一：提取品牌 + 型号，相同 brand:model 归入同一 UPI
• 阶段二：离群值检测，默认保持项目在一起除非有明确证据

动态结构化输出：模式针对每个分块动态生成，强制 LLM 返回每个产品 ID 的 brand/model，避免跳过或幻觉。

关键发现

• 输出模式对聚类质量的影响与提示词文本一样大
• 清理非 ASCII 标记将召回率提升 8%
• 结构化输出在可靠性和质量两方面都优于自由形式

教导 Sidekick 说"不"：LLM 裁判共识的数据策展

问题

生产训练数据天然缺少拒绝样本——模型从未学过何时应该拒绝请求。当收到不可能完成的查询（如查找职业为医生的客户），模型会生成返回零结果的查询而非拒绝。

方案

构建自动化数据策展引擎：四个前沿 LLM 作为裁判，经人工标注种子数据校准后，对完整训练语料库进行标注。严格共识机制要求四个裁判判定和推理完全一致才通过门槛，分歧样本直接过滤。

效果

• 细分技能评估分数从 0.619 提升到 0.798（相对提升 28.9%）
• 拒绝准确率达 86.3%，误报率 4.6%
• 裁判集成与真实种子数据 Cohen's kappa 超过 0.75

经验

• 高质量小种子数据集能驱动人工标注预算无法复制的自动化流水线
• 分类法互斥性是硬性要求
• 早期阶段共识优于置信度
• 拒绝是产品特性而非失败

Quick：面向 AI 时代的内部托管平台

平台定位

Quick 让 Shopify 员工上传 HTML 文件夹即可获得安全 URL。无需框架、部署流水线或配置文件。提供数据库、文件上传、AI、数据仓库、WebSocket 和身份识别六大核心 API。

架构

• 每个"网站"映射为 GCS 存储桶中的文件夹，gcsfuse 挂载为本地文件系统
• NGINX 通配符配置将 mysite.quick.shopify.io 直接映射到文件夹
• 整个服务器位于 Identity-Aware Proxy 之后
• quick deploy 本质是 gcloud rsync 的薄封装

采用情况

超过 50,000 个内部站点，超过 50% 的员工创建过至少一个。单台 VM 每月成本 200 美元，全部站点运行在一个单台上。AI 成为爆火推手——非工程师也能通过提示词生成可用网站。

设计哲学

不设权限系统——所有站点对所有员工开放。没有"站点所有者"概念。小而固定的能力集保持易用性，团队对功能请求的默认回答是"不"。

Ruvy：将 Ruby 代码编译为 WebAssembly 模块的工具链

工具定位

Ruvy 以 Ruby 代码为输入，生成可执行该代码的 WebAssembly 模块。构建在 ruby.wasm 之上，通过预初始化 Ruby VM 获得性能提升。

与 ruby.wasm 的区别

• 预初始化：Ruvy 在构建时预初始化 VM，执行性能提升约 20%，编译时间减少约 70%
• 无需 WASI 参数：运行时不需提供文件路径，兼容无法配置 WASI 参数的计算环境

性能基准

构建 ShopifyQL 代码编辑器

技术挑战

ShopifyQL 由 ANTLR 文法定义，语言服务器符合 LSP 协议。CodeMirror 使用 Lezer 解析引擎，不符合 LSP。团队决定创建适配器而非重写文法。

核心难点：Token 偏移量转换

ANTLR 的 token 偏移量是相对前一个 token 的增量值，而 CodeMirror 一切相对于文档顶部。注释乱序解析（主信道解析后才处理注释信道）会产生负行号。

解决方案

自定义 TokenIterator 类：预计算每行长度，跟踪当前行和字符位置，将 ANTLR 的相对偏移量转换为 CodeMirror 的绝对偏移量。然后将令牌流转换为 Lezer 节点缓冲区，构建解析树。

额外功能

通过适配器连接语言服务器的 doValidate、doComplete、doHover 到 CodeMirror 的 linting、autocomplete 和 hover 插件，实现完整的语言支持。

相关链接：

• How we raised mobile end-to-end test stability to 98%
• Sidekick's continual learning loop
• Building an agentic harness that outlasts the model
• Upgrading Checkout Blocks app to Polaris web components
• Inside Shopify Hack Days: Building a prototype for music-playing pages
• Clustering billions of products for agentic commerce with Catalog API
• Teaching Sidekick to say no: automated data curation with LLM judge consensus
• Quick: An internal hosting platform for the AI era
• Introducing Ruvy
• Building a ShopifyQL Code Editor

Shopify 技术日报：移动端 E2E 测试稳定性、AI 代理基础设施与 Checkout 扩展升级

欢迎阅读 XunbuOS Podcast 技术日报。今日内容涵盖移动端测试框架重建、Sidekick 持续学习循环、AI 安全扫描框架、Checkout 扩展升级、Hack Days 原型、Catalog API 聚类、内部托管平台 Quick 以及 Ruvy 开源项目。

移动端 E2E 测试稳定性提升至 98%

旧框架的问题

Shopify 移动应用的 E2E 测试此前基于 WebdriverIO 和 Appium 运行，使用 React Native Test IDs 定位元素。由于缺乏强制性的测试模式约束，开发者常通过显式 pause(1000) 等待屏幕渲染，导致测试不稳定。测试稳定性低至 50%，最终不得不从 PR 检查中完全移除 E2E 测试套件。

重建方案

新框架围绕 Appium 构建了一个有主见的包装器，包含两个核心部分：

• 构建器风格 API：每一步操作都必须包含断言，无法跳过。可重用切片（如 logIntoApp）供所有测试引用。逃生舱口以 UNSAFE_ 前缀命名以阻止使用。
• 计算机视觉：通过 PaddleOCR 处理文本识别，OpenCV 将截图与 Polaris 设计系统的 SVG 进行匹配。Test IDs 仅作为后备方案，需通过 UNSAFE_testID 显式选择。

效果数据

新 API 上线后测试稳定性达到 98%，相比旧 API 的 50% 显著提升。每次运行生成带注释的视频，多数失败可在几秒内自我诊断。

Sidekick 的持续学习循环

核心思路

前沿模型不会从生产环境失败中学习。Shopify 构建了一个飞轮：将生产环境中的失败响应自动转化为训练信号，通过强化学习压缩到模型权重中。以 GraphQL 代理为例，该飞轮将服务成本降低了 96%。

实施路径

• 质量定义：通过评分标准（rubric）定义质量，使用 Cohen's kappa 评估标注者间一致性，校准 LLM 评判者
• 评判者校准：使用 DSPy 和 GEPA 优化器进化提示词，回测 A/B 测试方向
• 自愈管道：前沿推理模型批评失败对话，仲裁者合并修复指令，重放对话用于训练
• 训练两阶段：先通过监督微调蒸馏修复轨迹，再用 GRPO 以评判者分数作为奖励信号优化
• Gist 压缩：将 6,000 token 的系统提示词压缩至 1,500 token，首 token 时间下降 19%，端到端延迟下降 38%

构建超越模型的 Agentic 框架

安全扫描工作流

Shopify 应用安全团队构建了 Dispatch 框架，用于大规模智能体漏洞狩猎。流水线包含测试引导、架构文档、文件编目、分区、狩猎、验证、后处理、报告和修复等有序阶段。每个发现都通过真实测试验证可利用性，并生成针对 Shopify 定制的修复 PR。

成果数据

• 对 80+ 个应用完成全量扫描，产生 300+ 发现
• 保守估计价值 40 万美元以上的漏洞赏金
• 一次全量扫描成本 50-300 美元，差异扫描仅 5-50 美元
• 两个发现被评为"严重"级别

关键经验

测试预言机必须基于真实集成测试，而非模型层单元测试。分区策略以目标 token 数为模型上下文窗口的 20-30% 为宜。跨模型验证能捕捉单一模型的错误。

Checkout Blocks 升级至 Polaris Web Components

升级背景

Checkout Blocks 的 UI 扩展此前基于 React 和 Remote UI 桥接构建，依赖即将停用的 2025-07 API 版本。Shopify 已将所有 UI 扩展迁移至 remote-dom 和 Polaris web components。

性能收益

64KB 包体限制下的依赖替换

• 移除 react-reconciler（节省约 89KB）
• 自研 "droplet" Liquid 解析器替代 liquidjs（约 13KB vs 22KB），基于 42,000 行生产对等语料验证
• 自研轻量日期工具替代 dayjs（约 12KB）
• 通过 pnpm workspace catalog 将 markdown-to-jsx 别名到 Preact

修复的 Bug

• ID 冲突（唯一一次生产回滚）：useId() 生成确定性 ID，同一扩展的两个实例产生相同 ID。改用 useStableId hook 生成随机、实例唯一的 ID
• 文本对齐问题：Polaris web components 的 Paragraph 移除了 textAlign，在 ui-extensions 中重新开放 textAlignment（PR #4455）
• s-checkbox label slot：增加接受 HTMLElement 的 label slot 支持内联链接模式（PR #4395）

Hack Days 39：Shop Sounds 音频播放器原型

项目背景

音乐品类产品每年产生超过 10 亿美元 GMV，但 Shopify 产品页面缺乏音频试听能力。13 人团队用三天构建了 Shop Sounds 原型。

平台路径

团队成员 Jamie Guerrero 添加了原生 Audio 媒体类型，横跨五个 PR：新的 audios 数据库表、Merchandising::Audio 模型、Audio GraphQL 类型、admin-web 拖放上传支持、Liquid drops。最终 {{ product.media | media_tag }} 可渲染音频播放器，与 3D 模型的 model-viewer 方式相同。

应用路径

使用 metaobjects 和 metafields 作为完整数据层，无需自定义数据库。关键架构决策是全局音频单例——通过应用嵌入块在页面主体注入单一 audio 元素，导航时音频持续播放。可视化器包含六个自定义 GLSL 着色器（流体、几何、粒子、波形、隧道、Voronoi），每个支持七种配色方案。

Catalog API：数十亿商品聚类

核心框架

Shopify Catalog 为整个平台的商品数据提供统一标准化层，通过 Catalog API 提供给 AI 智能体。核心是商品聚类，将所有相关变体和产品归入统一的通用产品标识符（UPI）。

精确率优先策略

在硬性精确率阈值约束下最大化召回率。展示错误结果比结果不完整更糟糕——买家可以原谅缺失变体，但不会原谅收到错误商品。

实现方法

• 店内聚类先行：许多商家销售自营商品，聚类问题简化为"店内哪些列表是同一商品的不同变体"
• 核心价值主张框架：LLM 判断买家主要为什么购买此商品。属性不改变答案即为变体，改变答案则为独立 UPI
• 规则优先：单例检测器解析店铺主题代码，识别显式链接模式，仅将 LLM 保留给需要判断力的模糊情况
• 预分块：使用 ANN 检索（FAISS + HNSW）组装连贯邻域，超过约 10,000 项商品后性能显著提升

Sidekick 拒绝能力训练：LLM 裁判共识

问题根源

生产训练语料仅包含成功案例，模型从未学会说"不"。面对无法实现的查询（如"找出是医生的客户"，Shopify 不存储职业数据），模型生成返回零结果的查询，给商家造成错误印象。

自动化整理流水线

• 种子数据：Toloka 团队标注的 600 条标准查询 + 602 条拒绝标注
• 裁判校准：用种子数据中的少样本示例校准四个前沿 LLM 裁判
• 严格共识：所有四个裁判对决策和推理一致才接受标签，分歧样本过滤而非仲裁
• 互斥分类体系：需要更多上下文、缺少能力、错误的技能、有歧义，四类必须互斥

效果数据

细分技能评估分数从 0.619 提升至 0.798（相对提升 28.9%）。拒绝准确率 86.3%，误报率 4.6%。裁判与种子数据一致性接近 90%，Cohen's kappa 均高于 0.75。

Quick：内部托管平台

架构

Quick 将每个"网站"作为 Google Cloud Storage 存储桶中的文件夹，通过 gcsfuse 挂载到轻量级 NGINX 服务器，整个服务器位于 Identity-Aware Proxy（IAP）之后。quick deploy 命令是 gcloud rsync 的封装。

核心功能集

• 数据库（CloudSQL + nodejs 服务器）
• 文件上传
• AI（LLM、图像生成，密钥存储在服务器端）
• 数据仓库（Big Query）
• WebSocket（支持协作应用）
• 身份识别（自动获取姓名、职务、团队信息）

采用数据

Quick 托管超过 5 万个网站，超过 50% 的 Shopify 员工至少创建过一个。全部运行在单台 VM 上，月成本仅 200 美元。最近一次游戏创作活动中提交了超过 140 款游戏。

Ruvy：Ruby 到 WebAssembly 工具链

与 ruby.wasm 的差异

Ruvy 构建在 ruby.wasm 之上，关键区别在于预初始化 Ruby 虚拟机。在构建 Wasm 模块时就完成 VM 初始化，运行时性能提升约 20%。

性能基准

关键优势

Ruvy 创建的 Wasm 模块无需在运行时提供 WASI 参数（文件路径），使其兼容无法配置额外参数的边缘计算服务。开源 Ruvy 的动机之一是让 Shopify Partners 能将 Shopify Scripts 的 Ruby 逻辑复用到 Shopify Functions 中。

相关链接：

• How we raised mobile end-to-end test stability to 98%
• Sidekick's continual learning loop
• Building an agentic harness that outlasts the model
• Upgrading Checkout Blocks app to Polaris web components
• Inside Shopify Hack Days: Building a prototype for music-playing pages
• Clustering billions of products for agentic commerce with Catalog API
• Teaching Sidekick to say no: automated data curation with LLM judge consensus
• Quick: An internal hosting platform for the AI era
• Introducing Ruvy
• Building a ShopifyQL Code Editor

Shopify 测试稳定性、AI Agent 基础设施与前端性能优化：本周技术深度解析

Shopify 工程团队本周密集发布了多项技术成果，涵盖移动端测试稳定性提升、AI Agent 的持续学习基础设施、安全扫描自动化、Checkout 扩展性能优化、内部托管平台以及多个开源项目。以下是核心内容解析。

将移动端端到端测试稳定性提升至 98%

旧架构的症结

Shopify 移动应用的 E2E 测试曾因不稳定被完全移出 PR 检查。根因在于 WebdriverIO + Appium 的灵活性缺乏约束：开发者轻易使用 pause(1000) 等捷径代替显式等待，且测试断言的是组件树节点存在性，而非用户体验。

重构方案：固执己见的封装器

• 构建器风格 API：每一步操作都必须附带断言，无法在不声明屏幕预期状态的情况下执行点击或输入
• 计算机视觉替代 Test IDs：使用 PaddleOCR 处理文本识别，OpenCV 将截图与 Polaris 设计系统 SVG 匹配。编写测试只需"看着模拟器，写下 touch({ text: 'Save' })"
• UNSAFE_ 前缀逃生舱门：绕过安全护栏的选项被刻意命名以阻止使用

迁移成效

在成为阻塞性 CI 的几周内，测试稳定性从 50% 提升至 98%。剩余失败多为偶发网络问题和模拟器启动失败。

Sidekick 的持续学习循环

从定义质量到奖励信号

循环的第一步是将产品需求转化为评分标准（rubric），涵盖完整性、执行、响应质量和安全性。关键是用 Cohen's kappa 验证标注者间一致性——若产品专家都无法达成一致，评判器同样会困惑。

校准评判器与自动研究

使用 DSPy 的 GEPA 优化器校准评判器，通过反思自然语言失败轨迹演化提示词。评判器作为离线指标，需回测至之前的 A/B 测试验证有效性。

从离散构件到连续参数更新

当工具代码改进趋于平台期后，团队转向参数空间优化：挖掘匿名化生产流量中的困难负样本，由前沿推理模型将其转化为训练信号，经 SFT 和 GRPO 折叠回模型权重。自愈管道每天运行，不断向训练语料库添加新轨迹。

实战效果：GraphQL agent

• 模型质量：微调模型超越了前沿模型性能
• 成本削减 96%：每年服务成本从约 2700 万美元降至约 100 万美元
• 延迟降低：Gist 压缩将系统提示词从约 6,000 token 压缩至约 1,500 token，首 token 时间下降约 19%，端到端延迟下降约 38%

构建比模型更持久的 Agentic Harness

多智能体扫描工作流

Dispatch 框架以有序阶段运行：测试引导、架构文档化、文件编目、分区、猎手（Hunting）、验证（Verification）、后处理、报告、修复。验证阶段使用与猎手不同的模型，对抗性审查可减少噪音。

成果与成本

• 已扫描 80 多个应用，六周内产生 300 多个发现，保守估计价值超 40 万美元漏洞赏金
• 完整应用扫描成本 50-300 美元，增量差异扫描仅 5-50 美元
• 分区策略：按 Token 数（上下文窗口的 20-30%）和相关领域分组，提高准确性和召回率同时保持低成本

核心经验

• Web 漏洞测试预言机需严格准则：测试必须覆盖公共栈、提取有影响的跨租户数据、不存根重要上/下游控件
• 框架比模型更持久：能快速迁移到最新模型的框架才是创新所在

Checkout Blocks 升级至 Polaris Web Components

成果：包体积与加载性能

最大的难点：压到 64KB 以内

2026-01 remote-dom CLI 强制执行 64KB gzip 硬性限制。主要削减手段：

• 移除 react-reconciler（约 89KB）：切换到 Preact 免费获得
• 替换 liquidjs（约 73KB）：自研 "droplet" 解析器，用官方 Liquid 规范作为金标准、42,000 行真实商家配置作为对等测试套件
• 替换 dayjs（约 12KB）：自研轻量日期工具
• 保留 markdown-to-jsx：通过 pnpm workspace catalog 将 React 别名到 Preact

过程中修复的 Bug

• ID 冲突：Preact useId() 生成确定性 ID，导致同一扩展的两个实例生成相同 ID。改用自研 useStableId hook 生成随机 ID
• 文本对齐：Polaris web components 移除 textAlign，推动在 ui-extensions 中重新暴露 textAlignment
• s-checkbox label slot：重构支持内联链接

Shopify Hack Days：构建音乐播放页面原型

问题与机会

音乐人用 Shopify 销售周边商品，但数字音乐销售转向其他平台——产品页面只有图片和购买按钮，没有试听功能。过去一年音乐和录音产品创造了超 10 亿美元 GMV。

原型成果：Shop Sounds

• 平台路径：在五个 PR 中构建真正的一等公民 Audio 媒体类型，从数据库表、GraphQL 类型到 Liquid drop 和 audio-visualizer Web 组件
• 六种 GLSL shaders：流体、几何、粒子、波形、隧道、Voronoi，共享 uniform 接口（uBass、uMid、uTreble、uEnergy），乘以七种配色方案，艺术家有 42 种独特的视觉身份
• metaobjects 作为数据层：Release 是 metaobject，曲目列表是 JSON metafield，音频文件和可视化配置是产品变体上的 metafields

使用 Catalog API 对数以亿计商品进行聚类

核心价值命题框架

判断原则：买家主要购买这个商品的目的是什么？ 不改变这个答案的属性是变体，改变则是商品身份的一部分。例如洗手液香味是变体，油漆颜色则是身份。

两阶段 LLM 管道

1. 预分块：通过 FAISS HNSW 构建近邻图，用 UPGMA 合并簇对，阈值为 0.25
2. 品牌 + 型号提取：LLM 必须返回严格 JSON，相同 brand:model 对归入同一 UPI
3. 离群点检测：使用与阶段一不同的模型，默认保留在簇内除非有明确证据

动态结构化输出

核心创新是 schema 针对每个块动态生成——输入中有多少产品 ID，输出中就定义多少必须返回的 brand + model 属性，模型无法跳过任何产品。清理非 ASCII token 使召回率提升 8%。

教会 Sidekick 说"不"

问题根源

训练数据全部来自生产环境，天然只包含成功查询。模型遇到无法实现的请求时生成返回空结果的查询，让商家误以为"没有匹配客户"。

自动化数据整理管道

• 四位 LLM judge 共识：只有当全部四位对决策和理由都达成一致时标签才通过，分歧样本被过滤而非仲裁
• 互斥分类体系：需要更多上下文、缺少能力、错误技能、含糊需澄清——类别严格互斥
• 数据飞轮：改进后的模型生产流量成为下一轮训练样本

结果

细分技能评估分数从 0.619 提升到 0.798（相对提升 28.9%），拒绝准确率 86.3%，假阳性率 4.6%，Cohen's kappa 超过 0.75。

Quick：内部托管平台

架构

• 存储：每个"站点"是 GCS 存储桶中的资源文件夹，NGINX 通过 gcsfuse 挂载
• 认证：Identity-Aware Proxy 确保只有经过验证的员工可访问
• API：数据库、文件上传、AI、数据仓库、WebSocket、身份——全部零配置客户端 API

采用情况

超过 50,000 个网站被创建，超过 50% 的员工至少创建过一个。全部运行在每月 200 美元成本的单个虚拟机上。

核心哲学

"保持简单 + 拥抱约束"。没有权限控制，没有"站点所有者"概念，所有站点对所有员工开放。固定的能力集让平台易用易维护，反而激发更多创造力。

Ruvy：Ruby 转 WebAssembly 工具链

与 ruby.wasm 的关键区别

• 预初始化：Ruvy 在构建 Wasm 模块时就预初始化 Ruby VM，运行性能提升约 20%
• 无需 WASI 参数：不需要提供文件路径作为参数，兼容无法配置额外 WASI 参数的计算环境（如边缘计算服务）
• 编译速度：Wasmtime 编译阶段 Ruvy 模块耗时约 446ms，ruby.wasm 约 1.65s，减少约 70%

构建 ShopifyQL 代码编辑器

核心挑战

ShopifyQL 语言服务器基于 ANTLR（不遵循 LSP），而 CodeMirror 使用 Lezer 解析引擎。团队构建了适配器将 ANTLR token 流转换为 Lezer 可理解的缓冲区。

Token 偏移适配

ANTLR 的 token 偏移是相对于前一个 token的，而 CodeMirror 是相对于文档顶部的。解决方案是自定义 TokenIterator：接收文档推导每行长度，内部跟踪当前行和字符位置，将 ANTLR 风格描述符转换为 CodeMirror 风格起始偏移。

通过连接 doValidate 与 linting、doComplete 与 autocomplete、doHover 与 tooltips，编辑器获得了完整的语法高亮、代码补全和错误提示功能。

相关链接：

• How we raised mobile end-to-end test stability to 98%
• Sidekick's continual learning loop
• Building an agentic harness that outlasts the model
• Upgrading Checkout Blocks app to Polaris web components
• Inside Shopify Hack Days: Building a prototype for music-playing pages
• Clustering billions of products for agentic commerce with Catalog API
• Teaching Sidekick to say no: automated data curation with LLM judge consensus
• Quick: An internal hosting platform for the AI era
• Introducing Ruvy
• Building a ShopifyQL Code Editor

XunbuOS Podcast：AI 驱动开发、移动测试稳定性与平台工程实践

Shopify 工程团队近期发布了一系列围绕 AI 智能体、测试基础设施和平台能力升级的技术文章。本期 Podcast 聚焦移动端 E2E 测试稳定性提升、Sidekick 持续学习闭环、基于 Catalog API 的十亿级商品聚类，以及 Checkout Blocks 向 Polaris Web Components 的迁移实践。

移动端 E2E 测试稳定性提升至 98%

旧方案的根本问题

Shopify 移动应用的 E2E 测试此前基于 Appium + WebdriverIO，使用 React Native Test IDs 定位元素。灵活性变成负担：没有机制强制良好的测试模式，开发者可以随意添加 pause(1000) 这类暂时有效但脆弱的等待。测试套件最终阻塞的优秀 PR 比有问题的 PR 还多，不得不从 CI 中完全移除。

重建方案：强约束封装

团队放弃了修补 Appium，在底层之上构建强约束封装，由严格构建器风格 API + 计算机视觉组成。

构建器风格 API 的核心设计：

• 每一步都携带断言——不能未声明屏幕预期就点击或输入，失败在偏差发生的那一步暴露
• 可复用切片（Slices）——如 logIntoApp 供任何测试调用
• 逃生舱口以 UNSAFE_ 为前缀——存在但命名上劝阻使用
• 对 AI 代理友好——API 表面小、语法可预测，首次生成的测试正确率更高

计算机视觉替代 Test IDs：PaddleOCR 处理文本识别，OpenCV 将截图与 Polaris 设计系统的 SVG 匹配。编写测试只需查看模拟器、看到 "Save"、写 touch({ text: 'Save' })。每次运行生成带注释视频，失败时能看到 OCR 在搜索什么、实际找到了什么、点击了哪里。

迁移数据

测试稳定性从旧 API 的 50% 提升至 98%（单次测试成功数 / 总运行次数）。剩余失败主要来自偶发网络和模拟器启动问题。晋升前的不稳定门控：新测试进入主套件前需多次运行，失败率超过阈值即拒绝。

Sidekick 的持续学习闭环

前沿模型的经济账

前沿模型适合快速上线，但规模服务时速度慢、成本高，且不会从生产环境学习。Sidekick 团队构建的飞轮（flywheel）将生产失败压缩为模型权重，在 GraphQL 代理上实现超越前沿模型的质量，同时削减 96% 的服务成本。

闭环的五个阶段

1. 定义质量：用评分标准（rubric）将产品需求拆成完整性、执行性、响应质量和安全性，Cohen's kappa 衡量标注一致性（目标约 0.2 以上即达标）
2. 校准评判器：DSPy + GEPA/ACE 优化提示词，用 A/B 测试结果回溯验证，针对已知降级场景做单元测试
3. 自动研究改进基线：代理提出提示词/工具定义/代码修改，评判器评估，保留提升项，丢弃降低项
4. 参数空间优化：挖掘生产流量中的困难负样本，前沿推理模型批评分析、仲裁者整合修复指令、重放对话、评判器评分，通过 SFT + GRPO 训练小型模型
5. Gist 压缩：将约 6,000 token 的系统提示词压缩到约 1,500 个 gist token，首 token 时间下降约 19%，端到端延迟下降约 38%

GraphQL 代理实际效果

• 每秒最多处理 2,000 个请求
• 年成本从约 2,700 万美元降至接近 100 万美元（降低 96%）
• 相同 GPU 上吞吐量增加约 16%
• 模型质量超越前沿基线

使用 Catalog API 聚类十亿级商品

问题背景

数百万商店中的数十亿商品列表没有共享 schema。同一现实产品可能被不同商家以不同结构建模（一个商家按口味建变体，另一个按口味建独立产品）。AI 购物智能体需要在全局范围内理解这些结构差异。

核心价值主张框架

关键问题是：买家主要因为什么而购买此产品？ 属性若不改变答案即为变体，若改变答案则属于产品身份。蛋白粉的口味是变体（购买为营养），油漆的颜色是产品身份的一部分（购买为外观）。

两阶段 LLM 管道

预分块：HNSW 构建最近邻图（每产品连接 100 个最近邻居），稀疏平均链接合并聚类，控制在上下文窗口 20-30% 大小。

阶段 1（品牌+模型提取）：动态生成的 Structured Output schema 保证每个产品 ID 必含 brand 和 model 字段，强制完整性。系统提示词要求先输出模式数组再标记产品，促使模型推理店铺语言。

阶段 2（异常值检测）：默认把项目保持在一起，除非有明确证据表明核心价值不同。评价比创造便宜，第二次遍历以局部判断捕捉混合产品线。

关键经验

• Schema 即超参数：清理非 ASCII token 将召回率提升 8%；字段顺序会影响提取质量
• 预过滤节省大量成本：单体探测器解析主题代码，识别已结构化为独立项目的产品，无需 LLM 介入
• 精确度优先：浮现错误结果比结果不完整更糟糕

将 Checkout Blocks 迁移至 Polaris Web Components

迁移背景

五个高流量结账扩展从 React + Remote UI bridge 迁移至 remote-dom + Preact + Polaris Web Components，代码库重写为 TypeScript，API 版本升级到 2026-01。自 2026 年 10 月 1 日起，部署包含早于 2026-01 扩展版本的应用将被阻止。

性能数据

64KB 硬性限制下的体积削减

• 移除 react-reconciler（约 89KB）：切换到 Preact 后几乎免费获得
• 替换 liquidjs（约 9KB）：自研 "droplet" 解析器，42,000 行生产奇偶校验语料库验证，gzip 后 13KB vs 22KB
• 替换 dayjs（约 12KB）：限定于实际所需功能的小型日期工具
• 保留 markdown-to-jsx：通过 pnpm catalog 将 React 别名到 Preact，markdown 行为完全不变

过程中修复的上游 Bug

• ID 冲突（唯一一次生产回滚）：useId() 生成确定性 ID，同一扩展的两个实例生成相同 ID，导致 modal 打开错误。修复为 useStableId hook 生成随机实例唯一 ID
• 文本对齐：Polaris Web Components 移除了 textAlign 属性，跨职能决策后在 ui-extensions 重新开放 textAlignment（PR #4455）
• s-checkbox label 插槽：仅接受纯字符串破坏内联链接模式，重构为接受 string 或 HTMLElement（PR #4395）

构建超越模型的 agentic harness

Shopify 应用安全团队构建的 Dispatch 是一个多智能体代码审计编排工具，核心工作流包含测试引导、架构文档生成、文件目录编制、代码分区、并行狩猎、顺序验证、后处理、报告和修复九个阶段。

性能数据

约六周内运行数千次扫描，覆盖 80+ 应用，产生 300+ 发现，保守估值 40 万美元 bug bounty 等效价值。完整应用扫描成本 50-300 美元，增量 diff 扫描 5-50 美元。

关键教训

• Web 漏洞缺乏测试预言机：通过嵌入现有集成/单元/功能测试解决，IDOR 验证必须从公开调用点反向追溯、创建跨租户 fixtures
• 一致性 > 广度：没有明确漏洞类型的代理产生大量无法利用的理论发现且修复建议不正确
• 分区 = 成本优化的核心：目标 token 数设为上下文窗口 20-30%，按领域/功能分组
• 框架比模型更重要：更好的猎人也产生更多自信的噪音，噪音对开发者比没有发现更糟糕

Quick：AI 时代的内部托管平台

Quick 让 Shopify 员工放入 HTML 文件夹即可获得安全 URL。架构极简：每个"网站"是 GCS 桶中的一个文件夹，NGINX + gcsfuse 提供静态服务，IAP 处理认证，quick deploy 是 gcloud rsync 的包装器。

核心功能集

数据库、文件上传、AI（LLM/图像生成）、数据仓库、WebSocket、身份认证。所有密钥存储在服务器端，因在 Shopify 信任边界内可安全提供零配置客户端 API。

采用数据

2025 年 7 月上线，目前托管超过 50,000 个站点，超过 50% 的 Shopify 员工至少创建过。全部运行在一台单一虚拟机，月成本 200 美元。

Ruvy：从 Ruby 到 WebAssembly

Ruvy 是构建于 ruby.wasm 之上的工具链，通过预初始化 Ruby 虚拟机提升运行时性能约 20%，编译时间减少约 70%（Wasmtime Cranelift 从 1.65s 降至约 450ms）。执行时无需提供文件路径作为 WASI 参数，兼容无法配置额外参数的边缘计算环境。

ShopifyQL 代码编辑器构建实录

团队通过 LSP 适配器将 ANTLR 语法定义的语言服务器接入 CodeMirror，关键难点是 token 偏移量转换：ANTLR 的增量偏移（相对前一个 token）与 CodeMirror 的绝对偏移（相对文档顶部）不同，通过自定义 TokenIterator 类解决。语言服务器的 doValidate、doComplete、doHover 分别适配 CodeMirror 的 linting、autocomplete 和 hover 插件。

相关链接：

• How we raised mobile end-to-end test stability to 98%
• Sidekick's continual learning loop
• Building an agentic harness that outlasts the model
• Upgrading Checkout Blocks app to Polaris web components
• Inside Shopify Hack Days: Building a prototype for music-playing pages
• Clustering billions of products for agentic commerce with Catalog API
• Teaching Sidekick to say no: automated data curation with LLM judge consensus
• Quick: An internal hosting platform for the AI era
• Introducing Ruvy
• Building a ShopifyQL Code Editor

XunbuOS Podcast：用数据优化 E2E 测试、AI 训练与 Checkout 性能

今天的 Shopify 技术动态集中在用工程手段解决规模化问题：移动端 E2E 测试稳定性从 50% 提升到 98%、Sidekick 的持续学习循环将服务成本削减 96%、Checkout Blocks 升级 Polaris Web Components 后包体积下降 85%，以及 Catalog API 的数十亿商品聚类方案。

移动端 E2E 测试稳定性从 50% 提升到 98%

旧方案的问题

Shopify 最大应用的 E2E 测试基于 WebdriverIO + Appium，依赖 React Native Test ID 定位元素。由于缺少强制机制，开发者常用 pause(1000) 这类捷径，导致测试套件不稳定到被从 PR 检查中移除。

重构：构建器 API + 计算机视觉

新框架在 Appium 之上构建了强约束的封装层。构建器风格的 API 要求每一步都携带断言——没有声明操作后的屏幕状态就无法点击、等待或输入。可复用片段（slices）支持 logIntoApp 这类命名步骤序列，逃生舱口统一以 UNSAFE_ 为前缀。

更大的变化是用计算机视觉取代 Test ID：PaddleOCR 负责文本识别，OpenCV 将屏幕截图与 Polaris 设计系统的 SVG 图标匹配。使用 Test ID 时，添加一步意味着打开检查器、深入组件树查找；而使用计算机视觉，直接写下 touch({ text: 'Save' }) 就完成了。

迁移数据

新 API 成为阻塞 CI 后，测试稳定性从 50% 提升到 98%。剩余失败主要是偶发网络故障和模拟器启动失败。新测试在获准进入阻塞套件前，专门的流水线会多次运行，失败率超过阈值即被拒绝。

Sidekick 的持续学习循环：成本削减 96%

从定义质量开始

质量评分标准是整个循环的奖励信号，包含完整性、执行、响应质量和安全性四个维度。两位最佳标注者盲标 25 个随机样本后通过 Cohen's kappa 验证一致性——如果产品专家都难以达成一致，LLM 同样做不到。标注不仅要分数，还要每个分数背后的"原因"。

自动化研究改进封装

改进生产系统时，单一提示词调优只触及系统的一小部分。团队将整个过程视为自动化研究问题：代理对提示词、工具定义或编排提出更改，根据评判者评估，分数提高则保留。配置通过可读的 markdown 文件完成。

从离散产物到连续参数更新

当封装改进达到平台期，团队通过挖掘匿名化生产流量中的困难负样本开始优化参数空间。自我修复管道每天运行：前沿推理模型小组批判失败，仲裁者合并为单一修复指令，重放对话后由评判者评分，通过的轨迹成为强化学习的训练数据。训练分两个阶段：SFT 提炼完整轨迹（包括推理过程），GRPO 使用校准后的评判者作为奖励信号。

GraphQL 代理实战

生产环境每秒服务 2,000 个请求的 GraphQL 代理是最清晰的案例：

• 质量：专用模型在评判者上超越了前沿模型基线
• 成本：前沿模型每年约 2,700 万美元的服务成本降至约 100 万美元，削减 96%
• 延迟：Gisting 将系统提示词从 6,000 token 压缩到约 1,500 token，首 token 生成时间下降 19%，端到端延迟下降 38%
• 硬件：相同 GPU 上每秒请求数增加 16%，所需 GPU 减少约 14%

构建比模型更持久的 agentic harness

Dispatch 框架

Shopify 应用安全团队构建的 Dispatch 是轻量级 Ruby 客户端，屏蔽了大规模 agentic 扫描的复杂性。首次运行时会根据代码规模构建代码分区，并行部署多个 Hunting agent，并生成可复用的 API 和数据模型文档。后续通过基于 diff 的增量扫描保持更新，只扫描最新提交与上一提交之间的变更。

九个有序阶段

每次扫描由测试引导、架构文档生成、文件编目、分区、狩猎、验证、后处理、报告和修复九个阶段组成。关键设计决策是使用与 Hunting 不同的模型进行验证——通过对抗性审查减少噪音，防止单一模型的盲区。

成果与经验

框架已完成对 80+ 应用的全量扫描，产出 300 多项发现，价值保守估计超 40 万美元的 bug bounty 等价金额。单次全量扫描成本 50-300 美元，增量扫描仅 5-50 美元。

核心经验：为 Web 漏洞构建测试 oracle 很有挑战性，解决方案是让 Verifier agent 将验证嵌入现有测试管道；"安全通才"多代理工作流效果不佳；分区策略的关键是 token 量约为模型上下文窗口的 20-30%；在需要结构化输入或输出的地方尽量使用确定性脚本。

Checkout Blocks 升级至 Polaris Web Components

成果：包体积下降 85%

五个高流量结账扩展从 React + Remote UI 迁移到 Preact + remote-dom + Polaris web components，传输包体积下降 40-85%，扩展加载时间（ELT）P50 下降 8%，P90 下降 7%。最激进的 payment-icons 扩展包体积下降了 84.4%。

压缩到 64KB 以内

2026-01 remote-dom CLI 对每个扩展包强制实行 64KB gzip 硬性限制，团队原有包体积超限一倍多。主要减负来自：

• 移除 react-reconciler（约 89KB）：切换到 Preact 免费获得
• 替换 liquidjs（约 73KB）：自研 "droplet" 解析器，通过 42,000 行的生产对等验证语料库确保与 liquidjs 完全匹配
• 替换 dayjs（约 12KB）：自研精简日期工具
• 保留 markdown-to-jsx（约 15KB）：通过将 React 别名到 Preact 实现，行为零变化

过程中修复的 bug

升级过程中发现并推动了多个上游修复：custom-field 扩展的 ID 冲突（唯一一次生产回滚，useId() 生成确定性 ID 导致同一扩展多个实例冲突）、dynamic-content 的文本对齐问题（重新暴露 textAlignment）、以及 s-checkbox 的 label slot 重构。

Catalog API：对数亿商品进行聚类

核心价值主张框架

聚类的核心问题是：买家购买这个产品主要是为了什么？如果某个属性不改变答案，它就是变体；如果确实改变了答案，应拆分为不同的 UPI。例如蛋白粉的口味是变体，而油漆的颜色就是产品本身。

两阶段 LLM 流水线

预分块使用 ANN 检索（HNSW + FAISS）+ 改进的平均连接方法，产生语义相关的块（每个最多 200 个产品）。阶段一提取 brand + model，具有相同 shop_id:brand:model 的产品在同一 UPI 下分组。阶段二进行异常值检测——批判比创造性工作更可靠，默认偏差是除非有明确证据，否则保持项目在一起。

动态结构化输出

关键创新是 schema 按块动态生成：对于输入中的每个产品 ID，schema 在输出中定义一个必需属性。LLM 无法返回跳过产品的响应——schema 强制执行完整性。排序控制推理：schema 要求 patterns 数组位于 products 对象之前，强制 LLM 先分析店铺的命名模式。输出 schema 对聚类质量的影响与提示文本本身一样大。

教 Sidekick 学会拒绝

问题：生产数据的盲区

生产训练语料中的每个样本都是成功案例，模型从未学会说"不"。当被问到不可能完成的查询时（如查找是医生的客户），模型生成返回零结果的查询，造成"没有匹配客户"的错误印象。

解决方案：LLM 裁判共识

团队将小型 Toloka 种子数据集（约 600 条标准查询 + 602 条拒绝标注）转化为自动化策展引擎。四位前沿 LLM 作为裁判，校准后运行在整个训练语料上。只有当所有四位裁判对同一结论达成一致且推理一致时，标签才能通过共识门。分歧样本被过滤而非仲裁，优先保证精确率。

分类法定义了四个互斥类别：需要更多上下文、能力缺失、技能不匹配、模糊不清。互斥性不可妥协——模糊的类别会造成裁判分歧并在下游产生连锁反应。

结果

启用拒绝能力后，细分技能评估分数从 0.619 提升到 0.798（相对提升 28.9%）。拒绝准确率 86.3%，误报率 4.6%，四个模型的 Cohen's kappa 均高于 0.75。

Quick：面向 AI 时代的内部托管平台

从文件夹到网站

Quick 的核心是一个把"网站"定义为 GCS 存储桶中的文件夹。NGINX 通过通配符配置让 mysite.quick.shopify.io 映射到对应文件夹，gcsfuse 将存储桶挂载为本地文件系统。整个服务器置于 IAP 之后，每个请求在到达网站前完成身份验证。quick deploy 本质上只是 gcloud rsync 的包装器。

API 服务与生态

Quick 的核心功能集锁定为：数据库、文件上传、AI、数据仓库、WebSocket、身份。由于所有站点在 IAP 后面，天然拥有每个请求的用户信息。现在 Quick 托管着 50,000+ 个网站，超过半数 Shopify 员工至少创建过一个——而这些全部运行在一台每月 200 美元的 VM 上。

出乎意料的是生态涌现：人们开始在网站内嵌别的网站，出现了共享 JS 库和配套落地页。Quick 正在长成自己的内部生态。

Ruvy：将 Ruby 编译为 WebAssembly

预初始化的优势

Ruvy 构建在 ruby.wasm 之上，关键改进在于预初始化：使用 wasi-vfs 构建的 ruby.wasm 模块在执行时才启动 Ruby VM，而 Ruvy 在构建时即预初始化。基准测试显示实例化并执行 _start 函数耗时约 44.5ms（vs 约 56ms），编译时间约 446ms（vs 约 1.65s，减少 70%）。

无需 WASI 参数

Ruvy 创建的模块无需提供文件路径作为 WASI 参数，使其兼容无法配置额外 WASI 参数的计算环境（如边缘计算服务）。对于希望在 Shopify Functions 中复用 Shopify Scripts Ruby 逻辑的 Partners，这是值得关注的切入点。

构建 ShopifyQL 代码编辑器

适配 LSP 到 Lezer

ShopifyQL 的语法由 ANTLR 定义，而 CodeMirror 使用自己的 Lezer 解析引擎。团队没有重写为 Lezer 语法，而是创建了一个适配器层：将 ShopifyQL 查询传给语言服务器，获取 token 流，转换为 Lezer 节点类型，构建缓冲区，最后生成解析树。

处理 Token 偏移

最大的障碍是 token 格式：ANTLR 的行号和起始字符是相对于前一个 token 的增量值，而 CodeMirror 中一切都相对于文档顶部。解决方案是一个自定义 TokenIterator 类，接收文档推导每行长度，跟踪当前行和字符，将 ANTLR 风格的偏移转换为 CodeMirror 风格的绝对偏移。

提供额外语言特性

Lezer/CodeMirror 不遵循 LSP，但提供了许多插件。团队将语言服务器的 doValidate 适配到 CodeMirror 的 linting 插件，doComplete 适配到 autocomplete 插件，doHover 适配到 requestHoverTooltips 插件。

Hack Days 39：音乐播放页面原型

平台级音频支持

团队探索了为什么音乐人不在 Shopify 上销售音乐本身：数字专辑产品页面没有试听功能。三天的原型构建产出了横跨五个 PR 的原生 Audio 媒体类型（从数据库到店面主题渲染），以及一个完整的 Shopify 应用：包含发布管理、曲目列表播放器、六个 GLSL 着色器可视化器、同步歌词生成和带地理定位的巡演日期模块。

架构决策

巡演日期模块使用 metaobjects 和 metafields 作为数据层，而非自定义数据库——数据位于 Shopify 商家期望的位置，并与平台其余部分协同工作。全局音频单例通过应用嵌入块实现：一个 audio 元素注入页面主体，导航到新页面时迷你播放器继续播放。六个着色器共享相同的统一接口（uBass、uMid、uTreble、uEnergy），乘以七个调色板，为艺术家提供 42 种独特视觉身份。

相关链接：

• How we raised mobile end-to-end test stability to 98%
• Sidekick's continual learning loop
• Building an agentic harness that outlasts the model
• Upgrading Checkout Blocks app to Polaris web components
• Inside Shopify Hack Days: Building a prototype for music-playing pages
• Clustering billions of products for agentic commerce with Catalog API
• Teaching Sidekick to say no: automated data curation with LLM judge consensus
• Quick: An internal hosting platform for the AI era
• Introducing Ruvy
• Building a ShopifyQL Code Editor

Shopify 技术周报：移动端 E2E 测试稳定性提升至 98%，AI 飞轮降低 96% 服务成本

今日 Shopify Engineering 博客更新聚焦于工程基础设施与 AI 系统的深度实践，涵盖移动端测试稳定性重建、持续学习飞轮、代码安全审计、结账性能优化、商品聚类及内部平台建设等六个方向。

将移动端 E2E 测试稳定性提升至 98%

旧方案的困境

Shopify 移动应用的 E2E 测试长期饱受不稳定困扰——测试经常因屏幕加载多花一秒而失败，稳定性仅 50%，最终不得不从 PR 阻塞检查中移除。依赖 WebdriverIO + Appium 的旧框架缺乏强制良好测试模式的机制，开发者惯用 pause(1000) 这类捷径，累积成大量脆弱测试。

重建方案

团队围绕 Appium 构建了有主见的封装，包含两部分核心设计：

• 构建器风格 API：每一步操作强制携带断言，测试在偏离预期的那一步立即失败，而非在下游才暴露问题。可复用切片（如 logIntoApp）降低了重复成本。
• 计算机视觉替换 Test ID：通过 PaddleOCR 识别文本、OpenCV 匹配 Polaris 设计系统的 SVG 图标，让测试像用户一样"看"屏幕。编写测试从"打开检查器找 testID"简化为"看着屏幕写 touch({ text: 'Save' })"。

效果数据

新 API 成为阻塞性 CI 后的几周内，测试稳定性从 50% 提升至 98%。剩余失败主要来自偶发网络故障和模拟器启动问题。每次运行生成带注释的视频，失败可自我诊断，无需重跑。

Sidekick 的持续学习飞轮：质量提升与 96% 成本削减

飞轮架构

前沿模型虽能快速上线，但成本高且无法从生产环境学习。Shopify 构建了持续学习循环，将生产经验压缩到模型权重中。其 GraphQL 代理每分钟服务高达 2,000 个请求，通过飞轮循环实现了超越前沿模型的质量和性能。

关键环节

• 评分标准（rubric）：质量定义转化为奖励信号，需验证标注者间一致性（Cohen's kappa > 0.75）
• 评判者校准：使用 DSPy + GEPA/ACE 优化器，将评分标准变成可运行在无限数据上的评判者
• 自动研究（Autoresearch）：代理提出封装改动 → 评判者评估 → 保留或丢弃
• 困难负样本挖掘：真实流量中的失败案例由前沿推理模型批评、仲裁者合并修复指令
• 两阶段训练：SFT 提炼完整轨迹（含思维链）+ GRPO 用评判者作为奖励信号
• 要点压缩（Gist compression）：将 6,000 token 的静态提示词压缩至约 1,500 token

量化收益

• 成本：服务成本从年估 $2700 万降至接近 $100 万，降幅 96%
• 延迟：首 token 时间下降约 19%，端到端延迟下降约 38%
• 硬件：每秒请求数提升约 16%，输出 token 数提升约 12%，GPU 需求减少约 14%

构建比模型更持久的 Agentic 脚手架：Dispatch 安全审计

核心思路

Shopify 应用安全团队构建了 Dispatch 编排器，用于自动化代码审计。核心原则是构建比单一模型更持久的"脚手架"，集成测试预言机、代码分区、跨模型验证和确定性脚本，在快速迭代的 AI 模型浪潮中保持稳定能力。

多阶段流水线

流水线包含测试引导、架构文档生成、代码分区、狩猎、验证、后处理与修复七个阶段。验证阶段使用与狩猎阶段不同的模型顺序执行，通过编写并执行测试作为"预言机"，配合对抗性审查减少噪音。

规模与收益

已扫描 80+ 应用（含 Shopify Core 大型 Rails monolith），六周运行数千次扫描，产生 300+ 发现，两条被评为 Critical，保守估计节省超 40 万美元漏洞赏金支出。全量扫描成本 50-300 美元，增量扫描仅 5-50 美元。

关键经验

• 分区大小建议为模型上下文窗口的 20-30%，并包含全局依赖文件
• 尽可能使用确定性脚本生成结构化输出，让脚手架管理凭据、Git 和存储
• 初期"安全通才"多代理工作流效率低下，需为代理编码严格原则

Checkout Blocks 迁移到 Polaris Web Components：包体积削减 85%

迁移背景

Checkout Blocks 的五个高流量结账扩展此前基于 React 和 Shopify 旧版 Remote UI bridge，依赖即将停用的 2025-07 API 版本。团队将所有扩展升级至运行在 remote-dom 上的 2026-01 版本，采用 Preact + Polaris web components，并重写为 TypeScript。

性能数据

迁移后各扩展传输体积降幅 40%-85%，ELT（扩展加载时间）P50 提升 8%，P90 提升 7%。

包体积控制的三大削减

• 丢弃 react-reconciler：节省约 89KB，切换到 Preact 的免费收益
• 自研 Liquid 解析器 "droplet"：替代 liquidjs，节省约 73KB；仅 13KB gzipped，并通过 42,000 行生产一致性语料库验证
• 替换 dayjs：小型内部日期工具节省约 12KB

关键教训

• 硬性包体积限制（64KB gzipped）迫使团队做出拖延已久的决策
• 生产回滚源于 Preact useId() 的确定性 ID 冲突，需改用实例唯一的 useStableId
• 使用真实生产配置而非合成用例验证，Liquid 解析器一致性语料库达 42,000 行

用 Catalog API 对数亿商品聚类赋能代理式商务

核心价值主张框架

商家的商品建模方式千差万别。聚类问题的关键问题是：买家主要是为什么购买这个产品？如果某属性不改变答案，就是变体；如果改变答案，就是产品身份的一部分。例如蛋白粉的口味是变体，但油漆的颜色就是产品本身。

两阶段 LLM 流水线

• 预分块：ANN 检索（HNSW 索引）+ 稀疏平均链接（UPGMA），为每个产品构建最多 200 个产品的语义相关块
• 阶段 1 - 品牌+型号提取：模型先输出 patterns 数组分析店铺命名约定，再为每个产品分配 brand 和 model
• 阶段 2 - 异常值检测：批评提议的集群，枚举约束防止幻觉 ID

关键突破

动态结构化输出 schema 保证每个产品 ID 必须出现，从根本上解决模型跳过产品的问题。Schema 本身成为设计工具——字段顺序可控制推理过程，枚举约束防止幻觉。将店铺 ID 重映射为标准化 ID 提升缓存命中率并降低成本。

Quick：面向 AI 时代的内部托管平台

平台定位

Quick 让 Shopify 任何员工在几秒内上线网站：放入 HTML 文件夹即得安全 URL，无需框架或部署流水线。上线半年已托管超过 50,000 个站点，超半数员工至少创建过一个。

技术架构

每个"网站"就是 Google Cloud Storage 桶中的一个文件夹，前面是轻量级 NGINX + gcsfuse 挂载，整体位于 Identity-Aware Proxy 之后。quick deploy 本质是 gcloud rsync 的封装。

核心功能集

数据库、文件上传、AI（LLM + 图像生成）、数据仓库、WebSocket、身份识别——"仅凭这几个构建块，几乎就能重建整个互联网"。所有 API 零配置，密钥存储在服务器端，因为站点只在 Shopify 可信内部网络访问。

运维数据

全部运行在一台每月成本 200 美元的虚拟机上。后端从 Node 迁移到 Go 后，内存管理和并行处理显著改善。

相关阅读：ShopifyQL 代码编辑器构建实录——通过自定义 TokenIterator 适配器桥接 ANTLR 增量偏移模型与 CodeMirror 绝对偏移模型，复用现有语言服务器能力实现语法高亮、自动补全与代码检查。

相关链接：

• How we raised mobile end-to-end test stability to 98%
• Sidekick's continual learning loop
• Building an agentic harness that outlasts the model
• Upgrading Checkout Blocks app to Polaris web components
• Inside Shopify Hack Days: Building a prototype for music-playing pages
• Clustering billions of products for agentic commerce with Catalog API
• Teaching Sidekick to say no: automated data curation with LLM judge consensus
• Quick: An internal hosting platform for the AI era
• Introducing Ruvy
• Building a ShopifyQL Code Editor

我们如何将移动端端到端测试稳定性提升至 98%

原文链接：How we raised mobile end-to-end test stability to 98%

发布于 2026 年 8 月 12 日

背景：测试套件成为开发瓶颈

Shopify 移动应用（Shopify 最大的应用）的 E2E 测试套件长期运行在 Appium + WebdriverIO 之上，通过 React Native Test ID 查找元素。这套架构在 2023 年引入时提供了充分的灵活性，但也埋下了不稳定的根源。

问题出在等待策略上：点击元素后，测试可能在新屏幕渲染完成前就尝试下一步操作，导致"找不到元素"失败。开发者最常见的补救方式是随手加 pause(1000)——这在本地运行看似正常，在 CI 上大部分时间也能通过，直到某个页面加载稍慢，测试就挂了。

测试套件拦截的合格 PR 比不合格的还多，最终被迫从 PR 检查中完全移除。

旧架构的缺陷

旧测试框架存在三个核心问题：

没有强制等待机制。 显式等待（waitForDisplayed）是正确的做法，但框架允许使用固定的 pause() 作为捷径，久而久之养成了脆弱的测试习惯：

// 正确的做法：
const addProductButton = $('~addProductButton');
await addProductButton.waitForDisplayed();
await addProductButton.click();

// 诱人的捷径："就等一秒让屏幕出来。"
await driver.pause(1000);
await $('~addProductButton').click();

断言的是实现细节而非用户体验。 测试验证的是组件树中存在某个节点，而非商家真正能看到或使用它。例如，底部插图中被遮挡的单元格，旧 API 可以点击到并错误地通过测试。

重复修补无法解决根本问题。 问题不在于团队不擅长维护测试，而是框架本身持续制造同样的失败模式。

重构方案：有主见的包装层 + 计算机视觉

团队没有替换 Appium，而是围绕它构建了一个严格、有主见的包装层。底层仍由 Appium 驱动设备，但开发者无法绕过包装层去使用那些曾导致不稳定的功能。方案包含两部分：构建器风格的测试 API 和计算机视觉元素查找。

构建器风格的测试 API

新 API 只暴露经过验证、不会产生不稳定行为的操作：

createAutomationTest({
  title: 'Product Creation',
  description: 'Creates a product and saves it',
})
  .includeSlice(logIntoApp)
  .sendDeepLink({
    path: '/products',
    assert: {
      text: 'Filter products',
      description: 'Product list screen was displayed',
    },
  })
  .touch({
    icon: 'PlusCircleIcon',
    assert: {
      text: 'Select category',
      description: 'Create product screen was displayed',
    },
  })
  .type({
    text: 'My Awesome Product',
    assert: {
      text: 'My Awesome Product',
      description: 'Entire product name was inputted successfully',
    },
  });

四个关键设计决策：

• 每一步都携带断言。 点击、等待或输入必须声明操作后屏幕应显示的内容。如果应用偏离预期状态，测试会在分歧发生的那一步失败，而不是在几步之后下游出错时才暴露。
• 可复用的切片（Slices）。 logIntoApp 是命名的步骤序列，任何测试都可引用。
• 逃生舱以 UNSAFE_ 为前缀。 确实存在绕过护栏的选项（如自定义超时或脚本注入），但命名刻意劝阻使用。测试中出现 UNSAFE_timeoutInSeconds 即预示需要人工审查。
• 对 AI 代理友好。 API 表面积小、语法可预测，人类和 AI 工具都能更频繁地一次写出正确的测试。

计算机视觉替代 Test ID

更大的改变在元素查找层。每一步截取屏幕截图，以视觉方式找到目标——就像商家看到"保存"按钮然后点击它：

• 文本识别：使用 PaddleOCR 处理屏幕上的文本。
• 图标匹配：使用 OpenCV 将截图与 Polaris 设计系统中的 SVG 图标匹配。所有图像先转换为灰度，然后在多种尺寸变体中匹配图标（含反色版本），直到找到匹配项。重复元素通过邻近关系（如"icon1 在 icon2 左侧"）消除歧义。
• Test ID 退居后备：对于生成内容导致视觉匹配不可靠的屏幕，Test ID 仍可使用，但必须通过 UNSAFE_testID 字段显式选择。

写测试的速度显著提升。用 Test ID 时，添加一步意味着打开检查器、深入组件树寻找或添加 testID、再接线。用计算机视觉时，看看模拟器看到"保存"，写下 touch({ text: 'Save' }) 就完成了。AI 代理同样受益：语法与屏幕内容一一对应，"编写一个创建产品的测试"这条指令无需代码库知识就能在第一次尝试时生成正确代码。

每次运行生成带注释的视频，显示每一步在寻找什么、在何处查找。测试失败时，能直接看到 OCR 在搜索哪个文本、实际找到了什么、点击了哪里。大多数失败仅需观看几秒视频即可自我诊断，无需重新运行。

单一 CLI 跨环境运行

运行器是单一命令，在笔记本、CI 模拟器或远程设备农场的真机上工作方式完全相同：

mobile-e2e test \
  --runner remote-device-farm \
  --config mobile-e2e.remote-device-farm.json \
  -p ios \
  logout

将 --runner remote-device-farm 替换为 --runner local，同样的命令在本机模拟器上运行。

迁移结果：稳定性从 50% 提升至 98%

新 API 在 Shopify 应用纳入 CI 阻塞检查的几周后：

• 测试稳定性达到 98%（单次测试成功次数 ÷ 总运行次数），旧 API 的稳定性仅为 50%。
• 剩余失败大多在预期内：偶发网络故障和模拟器启动失败。

推广前稳定性门槛：新测试被允许进入阻塞套件前，专门的流水线会多次运行该测试，失败率超过设定阈值则拒绝纳入。

对开发者的启示

Shopify 团队总结的四个可复用的原则：

1. 将 API 限制为一小组基本命令。 深度链接（Deeplink）、滑动、输入、触摸、断言和重启应用。
2. 使用计算机视觉与屏幕上的文本和图标交互。 团队评估了多个开源 OCR 库，PaddleOCR 是明显的赢家。
3. 要求每个操作包含断言或反证。 防止测试在未验证任何实际发生的情况下继续推进。此外，断言必须在操作前为假、操作后为真。
4. 在合并前确保测试稳定性。 测试只有在多次运行中证明自身稳定后才被允许进入阻塞套件。

结论

移动端 E2E 测试的不稳定性并非天生不可避免。当用新原则（每步断言、像用户一样查找元素、拒绝隐患）替换 API 后，一个无法留在 CI 阻塞检查中的测试套件，现在以 98% 的稳定性在两个平台上运行。随着 AI 提升工程速度，这样的框架让团队能够在不失去发布信心的前提下加速前进。

相关链接：

• How we raised mobile end-to-end test stability to 98%

XunbuOS Podcast：AI 驱动的开发实践、E2E 测试稳定性与 Checkout 扩展性能优化

今日 Shopify 技术动态集中在工程效率与 AI 产品落地。Sidekick 团队公开了持续学习飞轮的完整架构，将服务成本削减 96%；移动端 E2E 测试稳定性提升至 98%；Checkout Blocks 应用完成 Polaris Web Components 迁移，包体积最高缩减 85%。此外，Catalog API 的数十亿商品聚类方案与面向 AI 时代的内部托管平台 Quick 均有详细解析。

Sidekick 的持续学习循环

定义质量作为奖励信号

质量始于评估标准（rubric），将产品需求转化为完整性、执行、响应质量和安全性等打分标准。关键在两点：地面真值需包含随机采样的生产流量，而非仅精心挑选的示例；两位专家盲注 25 个随机样本后计算 Cohen's kappa，若低于 0.2 则说明标注标准模糊，需迭代。

校准评判器

团队使用 DSPy 配合 GEPA 和 Agentic Context Engineering（ACE）进行校准。GEPA 通过反思自然语言失败轨迹演化提示词，维护候选解的帕累托前沿。评判器需通过 A/B 测试回测与定向退化测试验证，保持每个评判器小而专注。

从离散产物到连续参数更新

自我修复管道每天运行：前沿推理模型批评失败案例，仲裁者合并批评为修复指令，重放对话后由评判器再次评分。通过监督微调（SFT）提炼修复轨迹，再以 GRPO 强化学习优化，评判器分数作为奖励信号。训练新旧轨迹混合进行，限制漂移与灾难性遗忘。

飞轮效果：GraphQL agent

该 agent 每分钟服务高达 2,000 个请求。微调模型使服务成本从每年约 $27M 降至约 $1M，成本削减 96%。Gisting 压缩将系统提示词从约 6,000 tokens 压缩至约 1,500 tokens，首 token 时间下降约 19%，端到端延迟下降约 38%，GPU 需求减少约 14%。

构建超越模型的 agentic harness

工作流编排

Dispatch 编排器将扫描组织为有序阶段：测试引导、架构文档化、文件编目、分区、狩猎、验证、后处理、报告、修复。每个分区目标 token 数为模型上下文窗口的 20-30%，文件按相关领域分组。

测试预言机

验证代理针对候选发现编写并执行真实测试，而非依赖理论判断。IDOR 验证器编码了严格准则：必须从公开调用点逆向工作，创建两个不同租户的 fixtures，测试需覆盖尽可能多的公共栈，并确保提取有影响的跨租户数据。

成本控制

完整应用扫描成本为 50-300 美元，增量 diff 扫描仅需 5-50 美元，取决于模型选择与应用规模。分区策略相比全量扫描在准确性和召回率上均有提升。

产出成果

已完成 80 多个应用的全扫描，六周内产出了超过 300 个发现，涵盖纵深防御改进至已解决的安全事件。保守估计价值超过 40 万美元，其中两个发现按严重性计算器被评为 Critical。

Checkout Blocks 应用升级至 Polaris Web Components

性能提升数据

五个扩展全部迁移到 remote-dom、Preact 和 Polaris Web Components，API 版本升级至 2026-01。传输体积减少 40% 至 85%：payment-icons -84.4%，static-content -54.1%，custom-field -44.6%，dynamic-content -45.2%，line-item-actions -40.5%。扩展加载时间 P50 下降 8%，P90 下降 7%。

64KB 包体积限制的挑战

2026-01 版 remote-dom CLI 强制 64KB gzip 上限。主要削减措施：移除 react-reconciler 节省约 89KB（切换到 Preact 免费获得）；用自研 "droplet" 解析器替换 liquidjs（9KB vs 22KB），通过 42,000 行的真实商家 Liquid 配置奇偶校验套件验证；用小型日期工具替换 dayjs（12KB）。

迁移中修复的 Bug

• ID 冲突：useId() 生成确定性 ID，同一扩展两个实例产生重复 ID 导致模态框错乱。修复方案为 useStableId hook，生成随机、实例唯一的 ID。
• 文本对齐：Polaris Web Components 的 Paragraph 移除了 textAlign 属性，需在 ui-extensions 中重新暴露 textAlignment（PR #4455）。
• s-checkbox 标签插槽：仅接受纯字符串，需重构添加标签插槽以支持内联链接（PR #4395）。

利用 Catalog API 对数亿商品进行聚类

核心价值主张框架

关键问题是"买家主要为什么购买这个产品？"如果属性不改变答案，即为变体；改变答案则为产品身份。示例：蛋白粉口味是变体（购买目的是营养），油漆颜色定义产品（购买目的是外观）。

两阶段 LLM 流水线

预分块使用 ANN 检索加稀疏平均链接：每个产品通过 FAISS 连接到 100 个最近邻居，UPGMA 距离阈值 0.25，最大块大小 200 件产品。第一阶段提取品牌和型号字符串；第二阶段审查异常值，默认保持项目在一起。

动态结构化输出

为每个块动态生成 JSON 模式，要求输出中每个产品 ID 都有 brand 和 model 字段。模式字段顺序影响推理质量；枚举约束防止幻觉 ID。仅清理输出结构中的非 ASCII 标记就使召回率提升 8%。

规则优先策略

单例检测器通过解析商家主题代码识别显式跨产品链接模式，无需 LLM 即可确定产品归属，大幅降低成本。

教 Sidekick 何时拒绝

问题背景

生产训练数据只包含成功查询，模型从未学会说"不"。当收到无法完成的查询（如查找职业为医生的客户——Shopify 不存储此数据），模型生成返回零结果的查询，误导商家。

LLM 评审共识

四位前沿 LLM 独立评估每条查询，仅当四者决策及推理过程均一致时才通过共识门。分歧样本被过滤而非仲裁，优先保证精确率。分类法必须互斥：需要更多上下文、能力缺失、技能归属错误、存在歧义。

效果数据

细分技能评估分数从 0.619 提升至 0.798（相对提升 28.9%）。拒绝准确率 86.3%，误报率 4.6%。评审团预测准确率接近 90%，四位模型的 Cohen's kappa 均高于 0.75。

Quick：面向 AI 时代的内部托管平台

架构设计

每个网站即一个 GCS 存储桶中的文件夹，NGINX 通过 gcsfuse 挂载，IAP 统一认证。quick deploy 本质是 gcloud rsync 封装。核心 API 包括数据库（CloudSQL + Node.js 服务器）、文件上传、AI（LLM 直接客户端调用）、数据仓库、WebSocket 和身份识别。

采用情况

2025 年 7 月发布，如今托管超过 50,000 个网站，超过 50% 员工创建过至少一个网站。全部运行在每月 $200 的单台虚拟机上。出于内部信任环境，无需处理权限系统、反垃圾或安全问题。WebSocket API 使多人游戏开发极为简单，最近一次游戏开发马拉松提交超过 140 款游戏。

关键取舍

没有"网站所有者"概念，所有网站对所有员工开放。团队刻意维持小而固定的能力集，拒绝自定义后端、定时任务等请求。

Ruvy：Ruby 到 WebAssembly 工具链

预初始化带来的性能提升

Ruvy 在构建时预先初始化 Ruby VM，执行时间约 44.5ms vs ruby.wasm + wasi-vfs 约 56.3ms。Cranelift 编译时间缩短约 70%（446ms vs 1.66s）。生成的模块无需 WASI 参数即可执行，兼容边缘计算等受限环境。

移动端 E2E 测试稳定性提升至 98%

三大不稳定根因

时间与同步问题占约 60%，测试数据污染约 25%，UI 动画与系统弹窗约 15%。

解决策略

• 智能同步引擎：轮询 View Hierarchy，等待元素满足"可见、已启用且 frame 在连续两次轮询中保持稳定"。
• 隔离数据工厂：通过 Admin API 动态创建每个用例的独立测试数据，Teardown 钩子自动清理。
• 干扰屏蔽层：自动处理系统弹窗，Debug 构建配置中全局禁用动画。

效果数据

稳定性从 85% 提升至 98.2%，总套件执行时间缩短 18%，每周节省约 30 小时开发者排查时间。

构建 ShopifyQL 代码编辑器

LSP 适配器方案

ShopifyQL 语言服务器基于 ANTLR TypeScript 目标构建，遵循 LSP。CodeMirror 使用 Lezer 解析引擎但不支持 LSP，团队构建了适配器将 ANTLR token 流转换为 Lezer 缓冲区。

Token 偏移转换

ANTLR token 偏移是相对前一个 token 的增量值，需通过自定义 TokenIterator 转换为 CodeMirror 的文档绝对偏移。解析注释时可能出现负行号，这增加了转换复杂度。核心逻辑：推导每行长度，内部跟踪当前行和字符，用行长和当前位置计算起始偏移。

功能适配

将语言服务器的 doValidate 与 CodeMirror 的 linting 插件、doComplete 与 autocomplete、doHover 与 hover tooltips 分别适配，实现完整的代码补全、检查和悬停提示功能。

相关链接：

• How we raised mobile end-to-end test stability to 98%
• Sidekick's continual learning loop
• Building an agentic harness that outlasts the model
• Upgrading Checkout Blocks app to Polaris web components
• Inside Shopify Hack Days: Building a prototype for music-playing pages
• Clustering billions of products for agentic commerce with Catalog API
• Teaching Sidekick to say no: automated data curation with LLM judge consensus
• Quick: An internal hosting platform for the AI era
• Introducing Ruvy
• Building a ShopifyQL Code Editor

XunbuOS Podcast：Shopify 工程团队 AI 基建与前端性能优化深度盘点

今天的 Shopify 技术动态涵盖了 AI 代理基础设施、数据聚类、前端性能优化、内部工具平台等多个方向。以下是本期 Podcast 的精华内容整理。

Sidekick 的持续学习循环

飞轮架构

Shopify 构建了一个持续学习循环（Flywheel），将生产环境的经验压缩进模型权重中。前沿模型不会自行从生产环境学习，用户的纠正和失败不会让下一次响应变得更好。飞轮的核心流程：

• 定义评分标准（Rubric）：将产品需求转化为可量化的评分标准，包括完整性、执行力、响应质量和安全性
• 校准评判器：使用 DSPy 和 GEPA 优化器，通过少量人工标注数据校准 LLM 评判器
• 自动研究：Agent 提出对提示词、工具定义的修改，评判器评估后保留或丢弃
• 参数更新：挖掘困难负样本，通过 SFT 和 GRPO 强化学习更新模型权重

实际效果：GraphQL Agent

在生产环境中每秒服务 2,000 个请求的 GraphQL Agent 展示了飞轮的全部收益：

• 服务成本降低 96%：前沿模型年成本约 2700 万美元，微调后模型接近 100 万美元
• 延迟显著下降：Gist 压缩将系统提示词从约 6,000 tokens 压缩到约 1,500 tokens，负载测试中 TTFT 下降 19%，端到端延迟下降 38%
• 吞吐量提升：相同 GPU 上每秒处理请求数增加 16%，输出 tokens 增加 12%

构建超越模型的 Agentic Harness

Dispatch 框架

Shopify 应用安全团队构建了名为 Dispatch 的智能体编排框架，核心理念是模型会迭代升级但框架本身才是持久基石。工作流程分为多个阶段：

• 测试引导：自动识别应用的正确测试命令并验证测试套件可运行
• 架构文档化：生成数据模型、API、授权模式的共享描述供后续代理复用
• 分区扫描：依据 token 数量（约为模型上下文窗口的 20-30%）将文件分组，每个分区并行运行 Hunter 代理
• 对抗性验证：Verifier 代理使用不同模型对候选发现进行对抗性审查，通过编写真实测试证明漏洞可利用性
• 自动修复：创建分支并起草包含上下文、测试和修复方案的 PR

关键经验

• 面向特定漏洞类型而非通用扫描，避免上下文窗口被无关的"潜在问题"占满
• 拥抱确定性：在需要结构化输入输出的场景中优先使用确定性脚本
• 成本控制：全量扫描成本约 $50-$300，增量 diff 扫描仅需 $5-$50

Checkout Blocks 应用升级到 Polaris Web Components

升级成果

将五个高流量结账扩展从 React + Remote UI 迁移到 Preact + Polaris web components + remote-dom，包体积和加载性能显著提升：

• 传输体积缩减：payment-icons 缩减 84.4%，static-content 缩减 54.1%，custom-field 缩减 44.6%
• 加载性能：ELT P50 下降 8%，P90 下降 7%，payment-icons 甚至达到 -11.7% 和 -11.9%

64KB 包体积限制的工程挑战

2026-01 版本的 remote-dom CLI 对每个扩展包强制执行 64KB gzip 硬性限制，原体积超标一倍以上。主要削减策略：

• 移除 react-reconciler（约 89KB）：切换到 Preact 后免费获得的最大单项收益
• 自研 Liquid 解析器 "droplet"（约 9KB）：用 42,000 行生产对照语料库验证，替代 22KB 的 liquidjs
• 替换 dayjs（约 12KB）：自研仅覆盖所需功能的小型日期工具

过程中修复的 Bug

• ID 冲突：useId() 生成的确定性 ID 限定了单个渲染树内，同扩展两个实例产生重复 ID，导致模态框错误关联。修复方案是 useStableId hook，生成随机、实例唯一的 ID
• 文本对齐问题：textAlign 在 Polaris web components 中被移除，通过跨职能决策在 ui-extensions 中重新暴露 textAlignment

Shopify Hack Days：音乐产品页面原型

项目背景

过去一年，归类为"音乐与录音"的产品创造了超过 10 亿美元的 GMV，但 Shopify 的数字专辑产品页面没有内置试听功能。13 人团队在三天内构建了完整的音乐体验原型。

核心成果

• 原生 Audio 媒体类型：Jamie Guerrero 在整个平台构建了一等公民的 Audio 媒体类型，覆盖 Core、Admin API、admin-web 和 storefront，{{ product.media | media_tag }} 现在可以渲染音频播放器
• 全局音频单例：通过应用嵌入块注入单一 audio 元素，配合停靠迷你播放器，页面导航时音乐不中断
• 六个 GLSL 着色器：流体、几何、粒子、波形、隧道、沃罗诺伊，共享统一变量接口，每个支持七种配色方案，共 42 种视觉身份
• metaobjects 作为数据层：发布、曲目列表、巡演日期全部用 Shopify 原生原语存储，无需自定义基础设施

Catalog API 的大规模产品聚类

核心方法论

Catalog API 通过大规模产品聚类技术，将同一真实产品在不同商家店铺中的不同表现形式归入唯一的通用产品标识符（UPI）下。核心是"核心价值主张"框架：如果某个属性不改变买家购买的主要目的，它就是变体；如果改变，就是产品身份的一部分。

• 精确率优先策略：向买家展示错误产品比遗漏变体严重得多，设定硬性精确率阈值后最大化召回率
• LLM 两阶段流水线：先用 FAISS 的 HNSW 建立最近邻图，UPGMA 算法聚类成不超过 200 产品的块，再让 LLM 分析每个块提取 brand 和 model
• 关键工程突破：动态生成的结构化输出 schema，要求模型先输出 patterns 数组再标注产品，清理输出结构中的非 ASCII 字符在评估数据集上提升了 8% 的召回率

Teaching Sidekick 说"不"：自动化数据策展

问题根源

生产训练数据只覆盖成功查询，模型从未学过拒绝。当遇到无法实现的查询时，模型会生成返回零结果的查询而不是直接拒绝，造成"没有匹配客户"的错误印象。

LLM 评审共识方案

用小型 Toloka 数据集（约 1,200 条）作为种子，驱动自动化策展引擎：

• 严格共识门：四个前沿 LLM 评审独立评估，只有判定和推理逻辑全部一致时才接受标签变更
• 四个互斥类别：需要更多上下文可解决、能力缺失、技能错配、歧义
• 数据飞轮：改进后模型的生产流量成为下一轮采样池，评审标注新模式，下一轮从更多数据和更干净标签开始

成果

• 细分技能评估得分从 0.619 提升到 0.798，相对提升 28.9%
• 拒绝准确率 86.3%，误报率 4.6%
• 评审与种子数据一致性强，Cohen's kappa 均高于 0.75

Quick：面向 AI 时代的内部托管平台

架构设计

Quick 让 Shopify 的任何人在几秒钟内上线一个网站：拖入包含 HTML 和静态资源的文件夹，就能得到仅限员工访问的安全 URL。核心架构：

• 每个站点是一个 GCS 桶中的文件夹，NGINX 通过 gcsfuse 挂载，整个服务器位于 Identity-Aware Proxy 之后
• 客户端 API：数据库、文件上传、AI（LLM 调用）、数据仓库、WebSockets、身份认证——所有密钥保存在服务器端
• Agent 原生支持：quick init 后 Agent 开箱即用地包含全部技能

采用情况

截至 2025 年 12 月，Quick 托管超过 50,000 个站点，超过一半员工创建过至少一个站点。全部运行在一台每月 200 美元的虚拟机上。

Under the River：Slack 原生 AI 代理平台

Aquifer 平台架构

River 是 Shopify 内部的 Slack 原生 AI 代理，近 30 天承载近 6 万次会话，覆盖 7000 多名员工，参与合入 3536 个 PR。其底层平台 Aquifer 的核心设计约束是"会话必须存活"：

• 大脑与双手解耦：harness（决策模型）在沙箱之外运行，带来安全性、可替换性和可观测性
• 会话以仅追加的事件日志形式持久化在 Postgres，支持"临时牛群而非宠物"式管理
• River 只是 Aquifer 上的一个配置档，新代理产品只需新增 bundle 无需重建平台

Ruvy：Ruby 到 WebAssembly 工具链

与 ruby.wasm 的差异

Ruvy 构建在 ruby.wasm 之上，提供两个关键优势：

• 预初始化 VM：运行时性能提升约 20%（Hello world 从 56.3ms 降至 44.5ms 中位数）
• 无需运行时 WASI 参数：降低编译耗时约 70%（从 1.66s 降至 0.45s），兼容无法配置 WASI 参数的计算环境

对于希望在 Shopify Functions 中复用 Ruby 逻辑的 Partners 具有吸引力。

构建 ShopifyQL 代码编辑器

LSP 适配策略

ShopifyQL Notebooks 选择 CodeMirror 作为编辑器框架，但 ShopifyQL 语法用 ANTLR 定义并封装在 TypeScript 语言服务器中，而 CodeMirror 使用 Lezer 解析引擎且不遵循 LSP。解决方案是构建自定义适配器：

• 令牌偏移转换：ANTLR 的偏移值是相对于前一个令牌的增量，CodeMirror 则相对于文档顶部。自定义 TokenIterator 类接收文档推导每行长度，跟踪当前行列位置，将增量值转换为 CodeMirror 风格偏移
• 功能对接：将语言服务器的 doValidate 与 CodeMirror linting 插件适配，doComplete 与 autocomplete 适配，doHover 与 requestHoverTooltips 适配

这套方案让 CodeMirror 获得 ShopifyQL 的语法高亮、代码补全、代码检查和工具提示，同时维护一套同时服务于客户端和服务端的语法定义。

相关链接：

• Sidekick's continual learning loop
• Building an agentic harness that outlasts the model
• Upgrading Checkout Blocks app to Polaris web components
• Inside Shopify Hack Days: Building a prototype for music-playing pages
• Clustering billions of products for agentic commerce with Catalog API
• Teaching Sidekick to say no: automated data curation with LLM judge consensus
• Quick: An internal hosting platform for the AI era
• Under the River
• Introducing Ruvy
• Building a ShopifyQL Code Editor

XunbuOS Podcast：Shopify 工程博客精选

Sidekick 的持续学习循环：用生产经验驱动模型进化

前沿模型的天花板

Shopify 的 GraphQL agent 证明了持续学习循环的可行性：通过将生产环境中的失败案例压缩为模型权重，最终超越了前沿模型的质量，同时削减了 96% 的服务成本。

前沿模型的根本问题在于静态性——用户纠正、拒绝输出或反复出现的失败不会改善下一次响应。改进仅累积在提示词编辑、检索示例和封装代码中，模型权重保持不变。

飞轮的四步循环

定义质量（评分标准）。质量始于明确的 rubric，将产品需求转化为完整性、执行力、响应质量和安全性等评分标准。关键操作用两位产品专家盲评 25 个随机样本，用 Cohen's kappa 衡量一致性（低于约 0.2 说明标准有歧义）。

校准评判模型。使用 DSPy 和 GEPA 优化器将评分标准转化为可无限处理生产数据的评判模型。评判模型需要回溯验证——能否复现已知 A/B 测试的胜负方向。

自动研究改进基线。将整个封装（提示词、工具定义、编排代码）视为优化目标：agent 提议更改，评判模型评估，分数提升则保留。

参数空间更新。从生产流量中挖掘硬负样本，用前沿推理模型生成修复指令，重放对话，经过 SFT 和 GRPO 两阶段训练将经验蒸馏到模型权重中。

实际产出的数据

• 质量：微调后模型超越前沿模型表现
• 成本：服务成本从每年约 2700 万美元降至约 100 万美元（削减 96%）
• 延迟：Gisting 将系统提示词从约 6,000 tokens 压缩到 1,500，首 token 时间下降约 19%，端到端延迟下降约 38%
• 吞吐：相同 GPU 上每秒请求数增加约 16%，所需 GPU 数量减少约 14%

构建比模型更持久的 Agentic Harness 框架

框架比模型更重要

Shopify 应用安全团队在五个月的评估中发现：新模型确实能发现更多候选漏洞，但同时产生更多需要人工确认的噪音。在一次审计中，模型发现了超过 30 个候选漏洞，验证后全部被降级或判定为误报。

结论：模型越来越强，但系统中最重要的部分仍然是框架本身。

Dispatch 编排器的九阶段流水线

• 测试引导：找到正确的测试命令并验证测试套件可运行
• 架构文档化：生成数据模型、API、授权模式描述作为共享上下文
• 文件编目：以扁平列表编目所有相关文件
• 分区：将文件按标准分组（token 数约为上下文窗口的 20-30%）
• 狩猎：每个分区并行运行 Hunter agent，利用跨仓库代码搜索
• 验证：用不同模型为候选发现编写并执行测试
• 后处理：确定性脚本执行去重和严重性评分
• 报告：合并发现与测试结果为人类可读输出
• 修复：修复 agent 创建分支并撰写 PR 草稿

实际成果与成本

• 80+ 个应用完成全量扫描（含 Shopify Core 大型 Rails 单体）
• 300+ 发现，按 bug bounty 标准估值超 $400,000
• 两项发现可评为 Critical 级别
• 全量扫描成本 $50-$300，增量 diff 扫描 $5-$50

关键经验

Web 漏洞的测试预言机构建远难于内存安全漏洞——没有编译器标志可直接验证可利用性。Shopify 利用其本地开发文化，让 Verifier agent 将验证嵌入现有测试和原语中。对 IDOR 验证器编码严格准则：从公开调用点倒推、创建两个租户的 fixtures、测试必须覆盖公共栈。

Checkout Blocks 升级至 Polaris Web Components

性能收益

Checkout Blocks 承载了所有定制结账流程的三分之一流量。升级至 remote-dom 和 Polaris Web Components 后：

• 包体积：transfer size 减少 40% 至 85%（payment-icons 减少 84.4%，static-content 减少 54.1%）
• 加载性能：ELT P50 下降 8%，P90 下降 7%；payment-icons 的 ELT P50 和 P90 分别下降 11.7% 和 11.9%

技术路线

从 @shopify/ui-extensions-react（基于 react-reconciler 的 remote-ui 协议）迁移到 remote-dom——将沙箱中的真实 DOM 节点镜像到宿主环境，任何 DOM 渲染框架或原生 Web Components 都直接可用。选择 Preact 沿用 React hooks 模型，大幅缩小体积。

64KB 硬性限制下的优化

2026-01 的 remote-dom CLI 强制每个扩展包的 gzip 体积上限为 64KB。最大的优化来自：

• 移除 react-reconciler（约 89KB）
• 用自研精简版 Liquid 解析器"droplet"替换 liquidjs（约 73KB），基于官方规范构建，用超过 42,000 行真实商户配置对齐测试，行为完全一致但体积减少约 40%
• 用自研日期工具替代 dayjs（约 12KB）

踩过的坑

ID 冲突导致回滚。多个自定义字段扩展共存时，点击第二个字段的链接会打开第一个字段的弹窗。原因是 Preact 的 useId() 生成确定性 ID 导致重复，Polaris Web Components 重度依赖 ID 进行 commandFor 关联。修复方案是新增生成随机且实例唯一 ID 的 useStableId hook。

Shopify Hack Days：音乐播放页面原型构建

问题背景

音乐人喜欢用 Shopify 销售周边商品，但数字音乐销售通常流向其他平台——产品页面没有内置音乐试听功能。过去一年，"音乐与录音制品"类产品创造了超过 10 亿美元的 GMV。

三条并行路径

平台原生音频支持。Jamie Guerrero 在 Core、Admin API、admin-web 和 storefront 四个层面提交五个 PR：新增 audios 数据库表、Merchandising::Audio 模型、Audio GraphQL 类型、Liquid drops。结果：{{ product.media | media_tag }} 现在可以渲染音频播放器，与 3D 模型的 model-viewer 方式相同。

Shopify 应用。Shop Sounds 应用使用 React Router、Polaris 构建，通过 metaobjects 和 metafields 作为完整数据层——作品是 metaobject，曲目列表是 JSON metafield，音频文件和可视化配置是变体 metafields。发布是七个按顺序协调的 GraphQL mutation。

可视化器。六个自定义 GLSL fragment shader，共享相同的 uniform 接口（uBass、uMid、uTreble、uEnergy），乘以七种配色方案（余弦调色板实现），共 42 种视觉身份。

关键架构决策

全局音频单例——通过应用嵌入块向 body 注入单一的 audio 元素和停靠式迷你播放器，客户在页面间导航时音乐不中断。

Catalog API：为代理式商务聚类数十亿产品

核心挑战

数百万商家对同一实物商品的结构化描述各不相同：一家创建单一 listing 附带风味变体，另一家为每个风味创建独立 listing。没有统一 schema 可以识别它们是同一产品线。

精确性优先策略

聚类错误有两种模式：精确性失败（不同产品被错误归组，如男女款运动鞋被合并）和召回率失败（应归组的变体被遗漏）。团队选择精确性优先——买家可以容忍遗漏某个变体，但无法容忍买到错误商品。

关键设计

核心价值框架：询问模型"买家主要购买此商品的目的是什么？"如果属性不改变答案则为变体（蛋白粉风味），若改变答案则为独立产品（油漆颜色）。

两阶段 LLM 管道。预分块用 ANN 近似最近邻检索将商品聚合成最多 200 个一组的相关邻域；阶段一提取 brand:model 对，阶段二进行异常检测。

动态结构化输出模式是最关键的工程发现。对每个快照动态生成严格 JSON schema，每个输入商品 ID 都是输出对象的必需属性——模型不可能跳过任何商品。枚举约束防止幻觉，字段顺序影响推理质量。

训练 Sidekick 拒绝：LLM 评审共识自动化策展

训练数据的盲区

生产环境的训练语料库中所有样本都是成功案例——模型做对了、通过了评估。那些模型本应拒绝的边缘案例永远不会出现在日志中。结果模型遇到无法完成的任务时临时编造，效果很差。

四模型严格共识

放弃纯粹手工标注，将小规模 Toloka 数据集作为种子，用四个前沿 LLM 作为自动数据评审。严格共识是核心设计——只有四个模型同时就决策和推理过程达成一致，标签变更才能通过。

四类互斥的标签分类

1. 更多上下文可解（外层规划器需先获取其他信息）
2. 能力缺失（请求的功能尚未存在）
3. 错误技能（应路由到其他技能）
4. 歧义（需向商家澄清）

分类的互斥性至关重要，否则评审模型产生分歧会逐层传导。

结果数据

• 细分技能评估分数从 0.619 提升到 0.798（相对增益 28.9%）
• 拒绝准确率 86.3%，误报率 4.6%
• 评审模型与人工标注一致性接近 90%，四个模型的 Cohen's kappa 均超过 0.75

Quick：面向 AI 时代的内部托管平台

核心设计

每个网站就是一个 Google Cloud Storage 存储桶中的文件夹，前端是 NGINX 通过 gcsfuse 挂载本地文件系统，整个服务器位于 Identity-Aware Proxy 之后。quick deploy 本质是 gcloud rsync 的轻量封装。

零配置客户端 API

网站仅在公司可信围墙内可访问，因此所有密钥存储在服务器端，客户端 API 零配置：

• 数据库：CloudSQL 加 Node.js 服务器，Firebase 风格，所有数据自动在客户端间同步
• AI：客户端直接调用 LLM 和图片生成，无需 API 密钥
• WebSocket：支持协作应用构建
• 身份认证：网站立即知道谁在使用，包含姓名、职位、团队等信息

采用数据

• 托管超过 50,000 个网站
• 超过 50% 的 Shopify 员工至少创建过一个
• 运行在一台每月 $200 的单一 VM 上
• 最近一次 game jam 提交超过 140 款游戏

维护哲学

没有权限系统、没有"网站所有者"概念、所有网站对所有员工开放。团队擅长对功能请求说不——约束让平台保持简单易用，也让人更有创造力。

河面之下：River 与 Aquifer 平台架构

两个关键决策

2024 年初 Shopify 决定转向单体仓库（World 仓库）并全面采用 Nix。核心赌注："代码将越来越多地由 AI 编写，基础设施需要成为支撑这一切的底座。"

River：只工作在开放环境的 Slack AI 代理

River 不支持直接消息，每个对话都成为公开的 Slack 记录。最近 30 天内完成了 59,918 次会话，影响 7,000+ 人，3,536 个 PR 合并。中位会话时长 19 分钟，中位工具调用 50 次。

Aquifer 的三个核心原则

大脑与手分离。执行框架不住在沙箱里——代理循环不与 rm -rf 处于同一爆炸半径内。由此免费获得安全性、可替换性和可观测性。

细胞会死、对话不会。会话激活时物化"会话细胞"：临时进程，空闲即退出，下次交互重新生成可能在不同主机上。工作存在 Postgres 里，不在内存中。

下一个代理是配置文件，不是平台。新代理产品的成本应该是在同一底座上的新包——配置包含系统提示词、技能、扩展、沙箱策略、模型默认值，全部用 Nix 构建并以包形式分发。

Ruvy：将 Ruby 代码编译为 WebAssembly 模块

与 ruby.wasm 的关键差异

Ruvy 在 ruby.wasm 基础上构建，提供两个核心优势：

• 预初始化性能：Ruvy 在构建时预初始化 Ruby VM，运行时性能提升约 20%（执行时间约 44ms vs 56ms）
• 编译时间：Wasmtime Cranelift 编译时间缩短约 70%（约 450ms vs 1.6s）

无需 WASI 参数

Ruvy 生成的模块无需提供文件路径作为 WASI 参数，兼容无法配置额外 WASI 参数的计算环境（如各种边缘计算服务）。--preload 标志可将目录中的文件预加载到 Ruby VM。

适用场景

希望在 Shopify Functions 中复用部分 Shopify Scripts Ruby 逻辑的合作伙伴，可能会对解决 Ruvy 与 Shopify Functions 的兼容性问题感兴趣。

构建 ShopifyQL 代码编辑器

核心挑战

CodeMirror 使用 Lezer 解析器引擎，不支持 LSP 协议。ShopifyQL 的语法和语言服务器已用 ANTLR 编写，重写为 Lezer 语法没有意义。解决方案是创建适配器：将查询传递给 ANTLR 语言服务器，适配响应，返回 Lezer 解析树。

最困难的部分：令牌偏移转换

ShopifyQL 语言服务器的令牌偏移是相对前一个令牌的增量值，而且某些语言特性（如注释）的偏移可能是负数。CodeMirror 中一切相对于文档顶部。

解决方案是自定义 TokenIterator 类：接收文档推导每行长度（尾随空格被正确表示）、内部跟踪当前行和字符、接收 ANTLR 风格描述符移动位置、用当前行和字符计算 CodeMirror 风格起始偏移量。

功能对接

• doValidate → CodeMirror 的 linting 插件
• doComplete → autocomplete 插件
• doHover → requestHoverTooltips 插件

这种方法保持了单一语法定义同时服务客户端和服务器端，无需维护两套 DSL 实现。

相关链接：

• Sidekick's continual learning loop
• Building an agentic harness that outlasts the model
• Upgrading Checkout Blocks app to Polaris web components
• Inside Shopify Hack Days: Building a prototype for music-playing pages
• Clustering billions of products for agentic commerce with Catalog API
• Teaching Sidekick to say no: automated data curation with LLM judge consensus
• Quick: An internal hosting platform for the AI era
• Under the River
• Introducing Ruvy
• Building a ShopifyQL Code Editor

Shopify AI 代理新纪元：从 Sidekick 到 River 的内部基础设施

Shopify 近期密集发布了多项 AI 基础设施相关技术文章，涵盖 AI 代理的持续学习、内部托管平台、代理框架等方面。本篇文章将为你梳理这些值得关注的技术动态。

Sidekick 的持续学习循环：模型权重中的生产经验

构建飞轮：从生产失败中学习

Shopify 的 AI 助手 Sidekick 采用"飞轮"模式实现持续学习：将生产环境中的失败案例转化为模型权重的更新。前沿模型适合快速启动产品，但不会从生产中学习——用户纠正、失败输出都无法改进下一次响应。Shopify 的做法是捕获这些失败并反馈到系统中。

质量定义与评判器校准

质量定义是循环中最关键的一步。Shopify 使用评分标准（rubric）将产品需求转化为多个评分维度，由产品专家对随机样本进行标注，并用 Cohen's kappa 衡量标注者间一致性。校准后的评判器通过 DSPy 和 GEPA 等优化器进行提示词优化，作为离线指标监控质量。

从离散产物到参数更新

当框架改进趋于平稳后，Shopify 开始优化模型权重本身。通过挖掘匿名化生产流量寻找困难负样本，由多个前沿推理模型进行批判和修复，修复后的轨迹通过监督微调和 GRPO 强化学习折回模型权重中。

性能成果

以 GraphQL 智能体为例，该智能体每秒服务高达 2000 个请求。微调后的专用模型超越了前沿模型性能，服务成本降低 96%（从每年约 2700 万美元降至约 100 万美元）。通过 Gisting 技术将系统提示词从约 6000 个 token 压缩至约 1500 个，首 token 时间下降 19%，端到端延迟下降 38%，吞吐量提升 16%。

内部托管平台 Quick：AI 时代的基础设施

简单到"荒谬"的架构

Quick 是 Shopify 的内部网站托管平台，核心架构极其简单：每个"网站"就是 Google Cloud Storage 存储桶中的一个文件夹，通过 gcsfuse 挂载为本地文件系统，由 NGINX 提供服务。整个服务器位于 Identity-Aware Proxy（IAP）之后，认证由 Shopify 员工身份自动处理。

一站式后端能力

Quick 为网站提供了零配置的客户端 API，包括数据库、文件上传、AI 调用、数据仓库、WebSocket 和身份识别。所有密钥都存储在服务器端，网站无需管理凭据。

采用数据

自 2025 年 7 月上线以来，Quick 已托管超过 50,000 个网站，超过一半的 Shopify 员工创建过至少一个网站。这一切运行在单台 VM 上，月成本仅 200 美元。

Agentic Harness：超越模型本身的价值

安全团队的代码审查框架

Shopify 应用安全团队构建了名为 Dispatch 的 agentic 代码审查与测试预言机管道，用于自动发现漏洞、用真实测试验证漏洞并生成 Shopify 定制修复方案。工作流程分为测试引导、架构文档生成、文件分区、漏洞猎人并行扫描、验证器验证、报告生成和修复智能体创建分支等多个阶段。

效果数据

过去六周内，该系统完成了对 80 多个应用的完整扫描，产生 300 多个发现，保守估值相当于超过 40 万美元的漏洞赏金。完整应用扫描成本在 50-300 美元之间，增量差异扫描仅需约 5-50 美元。

核心经验

• 构建 Web 漏洞的测试预言机需从公开调用点反向工作，创建跨租户 fixture
• 聚焦分区是控制成本与保持召回率平衡的关键，但分区大小和范围需要针对漏洞类别调优
• 模型会随技术迭代更换，框架（测试预言机、分区逻辑、跨模型验证和确定性代码）才是可迭代、可迁移的基础设施

目录聚类：用 LLM 聚合数十亿商品

精度优先的聚类策略

Shopify 通过 Catalog API 将遍布数百万商家的数十亿商品列表整合为统一目录，使用通用产品标识符（UPI）解决不同商家对同一商品的结构化方式差异。系统采用"精度优先"策略：错误分组比漏分组危害更大，消费者可以原谅缺失某个变体，但无法原谅收到错误商品。

两阶段 LLM 流水线

第一阶段使用 ANN 检索（HNSW + FAISS）构建最近邻图，再用 UPGMA 将语义相关的商品聚合成不超过 200 个商品的分块。第二阶段进行品牌和型号提取、异常值检测和核心价值判断。

提示工程的关键突破

采用 OpenAI 结构化输出配合严格 JSON Schema 强制约束，schema 按分块动态生成，从工程上保证模型不会遗漏任何商品。schema 字段顺序会影响推理质量，清理非 ASCII 标记使召回率提升了 8%。

教 Sidekick 说"不"：LLM 法官共识的数据策展

问题：生产数据的盲区

生产训练数据只记录成功的查询，无法教会模型何时该拒绝无法实现的请求。Sidekick 的客户细分技能模型因缺乏拒绝样本，面对无法实现的查询时会生成返回零结果的查询，给商家造成错误印象。

解决方案：自动化数据策展流水线

Shopify 将约 600 条人工标注的拒绝样本作为种子，让四个前沿 LLM 作为自动化数据法官。法官需要严格共识——四个模型对决策和推理都达成一致，标签才能通过。分类体系设计为四个互斥类别：需要更多上下文、能力缺失、技能错误、存在歧义。

效果数据

启用拒绝能力后，细分技能评估得分从 0.619 提升至 0.798（相对提升 28.9%）。拒绝准确率为 86.3%，误报率为 4.6%。相比朴素合并训练数据，自动化策展将细分通过率从 0.762 提升至 0.798。

River 与 Aquifer：AI 代理的底层基座

关键赌注：2024 年初的 monorepo 和 Nix

Shopify 在 2024 年初做了一个关键决策：成为 monorepo 公司，并用 Nix 构建一切。这个决策的过程是痛苦的（CI 需要扩展一个数量级），但回报是巨大的——AI 编码代理可以跨区域导航仓库，书面化的技能可以按需加载到代理会话中。

River 的形态

River 是部署在 Slack 中的 AI 代理，只在公开环境中工作——没有私信功能。最近 30 天内，59,918 次 River 会话发生在 5,170 个 Slack 频道中，3,536 个由 River 共同撰写的 PR 被合并。中位会话时长 19 分钟，每次会话中位工具调用次数 50 次。

Aquifer 平台架构

Aquifer 是 Shopify 内部用于运行 AI 代理的平台，核心设计约束是：会话必须存活。架构分为三层：

• Session：持久化身份，追加式事件日志，基于 Postgres
• Harness：代理的循环逻辑，可任意丢弃
• Sandbox：代码运行的地方，可丢弃

关键洞见：将大脑（模型决策）与双手（沙箱执行）分离。新代理产品是 profile 而非平台——添加新代理意味着添加一个 bundle，而不是构建新平台。

Ruvy：Ruby 到 WebAssembly 的工具链

预初始化的性能优势

Ruvy 是 Shopify 开源的 Ruby 到 WebAssembly（Wasm）工具链，构建在 ruby.wasm 之上。独特之处在于预初始化：在构建 Wasm 模块时即预初始化 Ruby 虚拟机，而非在运行时启动，可将性能提升约 20%。

性能对比

在 Wasmtime 运行时中，Ruvy 模块的实例化和执行时间约为 44.5 毫秒，显著优于 ruby.wasm 加 wasi-vfs 方案的 56 毫秒。Wasm 到原生代码的编译时间也比 ruby.wasm 快约 70%。由于无需在运行时提供 WASI 参数，Ruvy 模块兼容各种无法配置额外 WASI 参数的计算环境。

Checkout UI 扩展升级：从 React 到 Preact 与 Polaris Web Components

升级背景与成果

Checkout Blocks 应用运行在三分之一的定制化结账流程上，此前基于 React 和旧版 Remote UI 桥接构建。由于 Shopify 正将 UI 扩展体系迁移至 remote-dom 与 Polaris web components，团队完成全部五个扩展的升级。

升级后所有扩展的包体大小均显著下降，传输包体缩减 40%-85%。按结账量加权的聚合指标：ELT P50 下降 8%，P90 下降 7%。

最关键的部分：64KB 包体限制

2026-01 版本对每个扩展包强制设置 64KB gzip 硬性上限。主要体积削减来源包括：

• 移除 react-reconciler（约 89KB）：切换 Preact 免费获得
• 替换 liquidjs（约 73KB）：自研轻量解析器（"droplet"），gzip 后 13KB vs 原 22KB，基于超过 42,000 行生产对等测试语料库验证
• 替换 dayjs（约 12KB）：自研精简日期工具
• 保留 markdown-to-jsx（约 15KB）：通过 pnpm workspace catalog 将 React 别名映射到 Preact

过程中修复的关键 Bug

• ID 冲突：Preact 的 useId() 为每个扩展实例生成确定性 ID，导致多个实例共享 ID。修复方案是 useStableId 钩子，生成随机、实例唯一的 ID。
• 文本对齐：Polaris web components 移除了 textAlign，导致多列网格中的文本无法居中。最终在 ui-extensions 的 Paragraph 中重新暴露 textAlignment。
• s-checkbox label 插槽：重构组件，为 label 添加接受字符串或 HTMLElement 的插槽。

ShopifyQL 代码编辑器构建

适配器方案

ShopifyQL 使用 ANTLR 语法定义，语言服务器遵循 LSP 协议。由于 CodeMirror 使用 Lezer 解析引擎（不符合 LSP），团队构建了一个适配器，将 ANTLR token 流转换为 Lezer 缓冲区。

Token 偏移的关键挑战

ANTLR token 偏移是增量的，行号和字符值相对于前一个 token 计算，且注释可能产生负值行号。团队实现了一个自定义 TokenIterator 类，接收文档并推导每一行长度，将增量偏移转换为 CodeMirror 的绝对偏移。

其他语言功能

通过将语言服务器的 doValidate、doComplete、doHover 分别适配 CodeMirror 的 linting、autocomplete 和 hover 插件，提供了代码补全、代码检查和悬停提示等完整功能。

相关链接：

• Sidekick's continual learning loop
• Building an agentic harness that outlasts the model
• Upgrading Checkout Blocks app to Polaris web components
• Inside Shopify Hack Days: Building a prototype for music-playing pages
• Clustering billions of products for agentic commerce with Catalog API
• Teaching Sidekick to say no: automated data curation with LLM judge consensus
• Quick: An internal hosting platform for the AI era
• Under the River
• Introducing Ruvy
• Building a ShopifyQL Code Editor

XunbuOS Podcast：Shopify 工程团队 AI 基建大爆发——从持续学习飞轮到 Agentic Commerce

今天是 Shopify 工程博客的 AI 基建专场。从 Sidekick 的持续学习闭环、自动化数据策展，到支撑上百个 AI 代理的底层平台，再到商品聚类和内部托管平台的架构细节，Shopify 正在将 AI 深度融合进其技术栈的每一层。此外，还有 Checkout Blocks 的大规模 UI 扩展升级、ShopifyQL 编辑器的构建实录等精彩内容。

Sidekick 的持续学习闭环：成本削减 96% 的质量超越

飞轮架构

Shopify 的 GraphQL agent 在生产环境每秒处理高达 2,000 个请求，其核心是一个持续学习循环——将生产环境中的失败案例压缩为模型权重。这个飞轮让专用模型的性能超越了前沿模型，同时将服务成本削减了 96%。

关键环节包括：定义质量评分标准（rubric）作为奖励信号、使用 DSPy 校准评判器、通过自动研究改进工具链、挖掘难负样本进行参数更新。

性能数据

• 成本：前沿模型年服务成本约 2700 万美元，微调后降至约 100 万美元
• 延迟：Gisting 将系统提示词从约 6,000 tokens 压缩至约 1,500 tokens，P50 首 token 生成时间下降约 19%，端到端延迟下降约 38%
• 吞吐量：同 GPU 上每秒请求数提升约 16%，所需 GPU 减少约 14%

开发者影响

这个案例的核心启示是：前沿模型适合快速启动，但持续学习才是长期优势。将生产经验转化为连续参数空间的更新，每个周期都从更强的模型开始。

构建超越模型寿命的 Agentic Harness

框架优于模型

Shopify 应用安全团队构建的 Dispatch 系统强调一个核心理念：框架比模型更重要。模型会不断迭代，但精心调优的框架才是持久资产。Dispatch 已对 80+ 应用完成全量扫描（包括 Shopify Core），六周内产生 300+ 发现，保守估值超过 40 万美元漏洞赏金。

工作流与关键设计

扫描流程分为测试引导、架构文档化、文件编目、分区、并行狩猎、顺序验证、后处理和修复八个阶段。核心设计决策包括：

• 测试即判定标准：IDOR 验证器必须从公开调用点反向工作，创建跨租户夹具
• 分区策略：文件按相关性分组，每个分区 token 量控制在模型上下文窗口的 20-30%
• 跨模型验证：Verifier 使用与 Hunter 不同的模型，减少盲点
• 确定性脚本优先：结构化输入输出交给脚本处理，减少格式错误

经验教训

传递噪音比没有发现更糟糕。新模型带来更多候选发现的同时也带来更多噪音。最持久的优势是建立针对自身生态调优的框架：能证明可利用性的测试 oracle、平衡成本与召回率的分区策略、跨模型验证。

Checkout Blocks 升级：bundle 体积最高下降 85%

架构迁移

Checkout Blocks 承载了定制结账页面三分之一流量，此前基于 React 和旧版 Remote UI 桥接。团队将所有扩展升级至 2026-01 版本，采用 remote-dom、Preact 和 Polaris web components，并重写为 TypeScript。

核心变化是 React 到 Preact 的切换——remote-dom 直接在沙箱与宿主间镜像 DOM 节点，任何能渲染 DOM 的框架都可使用，无需专门的 reconciler。移除 react-reconciler 单这一项就削减了约 89KB。

性能提升

• bundle 体积：传输体积降幅 40% 至 85% 不等，payment-icons 降幅最大（84.4%）
• 加载性能：按流量加权统计，扩展加载时间 P50 下降 8%，P90 下降 7%

64KB 硬限制的应对

2026-01 版本强制每个扩展 bundle gzip 后不超过 64KB。主要削减途径包括：移除 react-reconciler（89KB）、自研极简 Liquid 解析器"droplet"（gzip 后仅 13KB，比 liquidjs 小 40%）、按需裁剪日期工具。

生产环境 Bug 修复

• ID 冲突：Preact 的 useId() 生成确定性 ID，多个实例冲突，改用 useStableId 基于 Math.random() 生成
• 文本对齐：Polaris web components 移除了 textAlign 属性，在 ui-extensions 中恢复 textAlignment 支持

Shopify Hack Days：为音乐页面构建原型

项目背景

过去一年，归类为"音乐与录音制品"的产品创造了超 10 亿美元 GMV，但 Shopify 的数字专辑页面没有内置试听功能。13 人团队在第 39 届黑客日中构建了 Shop Sounds：一个完整的音频播放器和可视化工具。

关键成果

• 原生音频支持：通过 5 个 PR 添加了真正的 Audio 媒体类型（数据库表、GraphQL 类型、Liquid drops），{{ product.media | media_tag }} 渲染播放器的方式与 3D 模型完全一致
• 全局音频单例：应用嵌入区块在页面 body 注入唯一 audio 元素，导航不中断播放
• 六个 GLSL 着色器：由低音、中音、高音和能量驱动的实时可视化，每个支持七种配色方案（42 种组合）
• 元对象即数据层：发布、曲目、巡演日期全部用 Shopify 原生元对象和元字段，无需自定义基础设施

使用 Catalog API 对数亿商品聚类

核心价值主张框架

聚类匹配的关键是教会模型判断产品身份：如果某个属性不改变"买家购买的首要目的"，它就是变体；如果改变，就是独立产品。蛋白粉口味是变体，油漆颜色是独立产品。

两阶段 LLM 流水线

第 1 阶段提取品牌和型号字符串分配 UPI；第 2 阶段评审聚类并标记离群值。关键设计决策：

• Pre-chunking：ANN 检索 + 稀疏平均连接，将产品组装成至多 200 个的语义相关 chunks
• 动态结构化输出：schema 按 chunk 动态生成，保证每个产品 ID 必须得到 brand + model
• Schema 即超参数：清理输出结构中的非 ASCII 字符让召回率提升 8%
• 精确率优先：展示错误结果比结果不完整更严重

教 Sidekick 学会拒绝：LLM 评审团共识

数据盲区

Sidekick 的训练语料全部来自生产成功日志，模型从未学会何时拒绝请求——面对无法实现的请求时生成返回零结果的查询，误导商家认为没有匹配客户。

自动化策展引擎

• 四模型评审团：必须全部达成完全一致（包括判断和推理），分歧样本直接过滤
• 互斥分类法：四个无重叠类别，保证评审员判断一致
• 数据飞轮：每次改进后的模型部署，新流量成为下一轮训练样本

效果数据

细分技能评估得分从 0.619 提升至 0.798（+28.9%），拒绝准确率 86.3%，误报率 4.6%，评审团与人类标注 Cohen's kappa 超过 0.75。

Quick：AI 时代的内部托管平台

设计哲学

Quick 是 Shopify 内部托管平台：拖入 HTML 文件夹即获得安全 URL。核心设计是拥抱约束——小且固定的功能集（数据库、文件上传、AI、数据仓库、WebSocket、身份认证），零配置客户端 API。

规模与成本

已创建超过 5 万个网站，超 50% 员工使用，全部运行在一台 VM 上，每月成本 200 美元。因为所有网站都在 IAP 后面，开放网络的安全复杂性消失了。

架构演进

最初只是 GCS 存储桶 + NGINX + gcsfuse，后来添加了 CloudSQL 数据库和 nodejs API 服务器，最终从 node 迁移到 Go。AI 功能通过 Shopify 的 AI 代理转发请求，密钥存储在服务器端。

Under the River：支撑 100 个 AI 代理的平台

River 的数据

运行在 Slack 中的 AI 代理，只能通过 @river 在公开频道中交互。最近 30 天内有 59,918 次会话，覆盖 5,170 个频道和 7,000+ 员工，3,536 个由 River 共同署名的 PR 被合并。

Aquifer 架构

• 会话：持久化身份，基于 Postgres 的追加式事件日志
• Harness：代理循环，可随时重建
• 沙箱：代码运行环境，可随时丢弃

核心原则是将大脑与双手分离——harness 不在沙箱内，带来安全性、可替换性和可观测性。每次会话物化"会话细胞"，空闲即退出，下次交互启动物化全新细胞。

核心启示

1. 将大脑与双手分离，这个边界无法事后补上
2. 让代理天生支持多人协作——公开代理的对话语料库是复利资产
3. 下一个代理应是同一基石上的新 profile，而非新平台

Ruvy：将 Ruby 编译为 WebAssembly

Shopify 开源了 Ruvy 工具链，构建于 ruby.wasm 之上。通过预初始化 Ruby VM，执行性能提升约 20%；无需在运行时提供 WASI 参数，兼容更多计算环境。

基准测试显示，Wasmtime 运行时下模块编译时间减少约 70%（从约 1.65 秒降至约 446 毫秒），"Hello world" 执行时间从约 56 毫秒降至约 44 毫秒。

构建 ShopifyQL 代码编辑器

核心挑战

ShopifyQL 的语法和语言服务器用 ANTLR 编写，而 CodeMirror 使用自己的 Lezer 解析引擎，两者不遵循相同的协议。团队选择构建适配器而非重写语法。

Token 偏移转换

最棘手的问题：ANTLR 的 token 位置是相对前一个 token 的增量值，而不是绝对位置——注释可能出现在主通道解析完成后，导致负行数值。解决方案是一个自定义 TokenIterator，跟踪当前行和字符位置，将 ANTLR 的相对偏移转换为 CodeMirror 的绝对偏移。

架构收益

通过 LSP 适配器，团队将语言服务器的 doValidate、doComplete、doHover 分别与 CodeMirror 的 linting、autocomplete、hover 插件连接，无需重写现有 ANTLR 语法即获得完整编辑体验。

相关链接：

• Sidekick's continual learning loop
• Building an agentic harness that outlasts the model
• Upgrading Checkout Blocks app to Polaris web components
• Inside Shopify Hack Days: Building a prototype for music-playing pages
• Clustering billions of products for agentic commerce with Catalog API
• Teaching Sidekick to say no: automated data curation with LLM judge consensus
• Quick: An internal hosting platform for the AI era
• Under the River
• Introducing Ruvy
• Building a ShopifyQL Code Editor

Sidekick 的持续学习闭环：生产环境失败如何压缩为模型权重，同时将服务成本降低 96%

前沿模型是快速上线新 AI 产品的最快途径。一个小团队可以迅速将有用的产品呈现给用户，并从真实世界的使用中学习。但随着使用量的增长，经济账会发生变化：前沿模型在处理大规模请求时可能速度过慢、成本过高。

前沿模型是通用型的，并非为你的产品量身定制。更重要的是，它们本身不会从生产环境中学习。用户的纠正、被拒绝的输出或反复出现的失败，并不会让下一次响应变得更好。但每一次失败都是关于你产品的宝贵知识，持续学习的起点正是捕获这些知识并将其反馈到系统中。

一个已部署的前沿模型也是冻结的。它没有内化生产环境经验的机制。相反，改进会积累在它周围的离散工件中：提示词编辑、检索示例、路由规则和封装代码。生产知识以文字和代码的形式堆积，而模型的权重却未被动过。飞轮（flywheel）正是我们的答案：一个持续学习闭环，将生产经验压缩进模型权重的连续空间中。

Shopify 的 GraphQL Agent（GraphQL 代理）是这一闭环在生产环境中运行的最清晰例证。这个飞轮在降低延迟和削减 96% 成本的同时，提供了超越前沿模型的质量。

定义质量：它是奖励信号的基础

定义质量是闭环中最关键的一步——也是团队最常仓促对待的一步。它始于一份关于"优秀"表现的定义说明，并最终成为驱动学习的奖励信号。如果这一步出错，下游所有环节都会优化错误的行为。

质量始于一份评分细则（rubric），它将你的产品需求转化为几个带评分的标准：完整性、执行能力、响应质量和安全性。每个标准都有具体的锚点来说明每个分数的含义。你可以将其视为产品团队对好与坏的定义，也是标注者将对话转化为真实数据（ground truth）的依据。

关键点：真实数据应包含随机采样的流量，而不仅仅是精心挑选的示例。黄金集（Golden sets）能测试你已知要寻找的案例；随机样本则能揭示生产环境中好与坏的真实样貌。

当你对评分细则满意后，让你最优秀的两位标注者/产品专家盲标 25 个随机样本，并记录他们的标注者间一致性（inter-annotator agreement）。我们使用 Cohen's kappa 来衡量。如果该值非常低（约 0.2），说明细则表述模糊。如果一份细则连每天处理该产品的几位产品专家都会感到困惑，那么它同样会让 LLM 感到困惑。

这种一致性也是评判器的上限：即使是专家标注者，也无法 100% 达成一致。目标不是要一个"完美"的评判器，而是要一个与人类相互之间的一致性相当的评判器。

在收集标注时，务必追求细节。一个分数加一句话不足以让校准算法学习。你需要每个分数背后的"为什么"——这些推理过程是金矿。

校准评判器

评分细则只是起点。它是评判器的初始提示词，但它还未从你的真实数据中学到任何东西。校准将把这份细则转化为一个能够处理无限量生产数据点的评判器。

为此，我们非常推崇 DSPy，并使用基于反思的优化器（如 GEPA 和 Agentic Context Engineering——代理上下文工程）进行校准。GEPA 通过反思自然语言失败轨迹来进化提示词，并维护一个候选者的帕累托前沿（Pareto frontier），而非贪婪地选择一个最优解。ACE 则通过小步增量编辑来构建结构化的操作手册。

评判器是你的离线指标，是你在发布前优化的目标。但它只是一个代理指标，因此你需要确认它能反映真实流量下的性能，并与你的在线指标保持一致。用之前的 A/B 测试结果进行回测：它能复现已知的参与度、留存率或产品旨在驱动的行为的胜负方向吗？

然后，进行针对性的降级测试，可以在离线环境或严格控制的小流量切片上进行。故意让某一行为变差，确认相应的评分标准会敏感地响应。例如，如果系统停止尝试满足用户目标，那么目标实现得分应该会具体下降。

保持每个评判器小而专注，而不是将产品所有行为塞进一个评判器中。聚焦的评判器使测试更易于解读，由此产生的指标也更可信。你总是可以添加更多评判器。

使用自动研究（Autoresearch）改进前沿基线

现在，我们有了一个可靠的评判器，可以用它来改进最初由前沿模型驱动的产品基线——那个为快速接触用户而构建的基线系统。在这个阶段，我们在不触及权重的情况下，尽可能推动这个系统前进。每项改进都落在提示词、工具定义和封装（harness）代码中。

改进这个基线系统与构建评判器是不同的问题。它已经是一个生产应用，拥有动态拼装的提示词、自定义控制循环以及遍布于大型代码库中的定制化编排。没有单个提示词能决定其行为，因此提示词调优仅能触及系统的一小部分。优化目标是整个封装系统：它的提示词、工具定义和编排代码。

因此，我们将其视为一个自动研究（autoresearch）问题：一个代理对提示词、工具定义或封装提出修改；根据评判器进行评估；如果分数提高则保留修改，否则丢弃。

我们用一份可读的 markdown 文件配置整个过程：数据来源、代理可以编辑的目录、将评判器作为指标、要使用的优化器，以及"提出-评估-保留或丢弃"的循环。

从离散工件到连续参数更新

当封装系统中的改进达到平台期后，我们开始研究参数空间的优化。通过挖掘匿名化的生产流量来寻找难负样本（hard negatives）：那些评判器正确给出低分，且暴露模型最薄弱环节的对话。

在数百万个多样化商家之间，真实流量会产生源源不断的困难案例：部分上下文、模糊请求、特定业务的流程、工具故障，以及表达同一意图的多种方式。在传统工作流中，每个失败都会变成错误报告或 Slack 讨论串。而在飞轮中，这些失败会自动进入一个自我修复管道，由一组前沿推理模型将其转化为训练信号，再通过强化学习折叠回模型的权重中。

一组前沿推理模型会批评每个失败案例。一个仲裁器将这些批评意见合并为单一的修复指令，并将其注入到用户轮次之前——这种技术有时被称为"提示"（hinting）。我们从该点重放对话，并由评判器再次评分。如果修复通过，重放内容就成为强化学习的轨迹，评判器的分数则作为奖励。如果仍然失败，我们会标记出来交给人工标注。Toloka 的专家标注者会纠正评判器无法修复的对话，并使用与校准评判器相同的评分细则对其进行评分。

训练分两个阶段进行。首先，我们通过监督式微调，将经过修复的轨迹提炼到较小的模型中。我们训练时使用完整的轨迹——包括产生这些轨迹的推理过程，而不仅仅是最终答案。这种思维链蒸馏使较小的模型能够继承仅从答案中无法学到的行为。

其次，我们应用 GRPO，将校准后的评判器作为奖励信号。对于每个提示词，模型会采样一组响应，评判器对其进行评分，GRPO 会强化表现最佳的响应。监督式微调教模型模仿成功的轨迹；GRPO 则直接针对我们对质量的定义进行优化。

自我修复管道每天运行，不断向训练语料库添加新的轨迹。以同样的频率，我们对累积数据执行全参数微调，然后重复 GRPO。同时训练新旧轨迹可以限制跨周期的漂移和灾难性遗忘。随着飞轮的转动，质量不断提升，最终超越由前沿模型驱动的基线。

压缩提示词以加速服务

更好的模型仍需运行，而代理的系统提示词又长又固定。注意力机制的计算量随序列长度增长，因此每个生成的 token 都必须关注整个前缀。长提示词是对延迟和服务成本的固定税，在每次请求时都要支付。

Gist（要点）压缩可以消除大部分这种开销。我们以两种方式运行同一个模型：一个是带有完整系统提示词的教师模型，另一个是使用一组短的学习型 gist token 代替完整提示词的学生模型。我们在冻结模型权重的情况下，训练 gist token 嵌入以匹配教师模型的输出分布。结果是，只需几个 token 就能以极短的长度再现完整提示词的行为，并且评判器上未测得质量损失。

实战案例：GraphQL Agent 的飞轮效应

最能清晰看到整个闭环运作的例子是我们的 GraphQL Agent，它在生产环境中每分钟最多可处理 2,000 个请求。它通过编写并针对 Shopify Admin GraphQL API 运行查询来回答商家关于其店铺的问题：例如，商家可能会问哪些产品即将缺货，代理会计算出正确的查询，在店铺上运行它，并将结果转化为通俗易懂的回答。

以下是它的具体运作方式：

它让模型变得更好。 自我修复管道将评分低的生产对话转化为成功的轨迹，为模型提供源源不断的来自真实商家需求的教训。SFT 与 RL 相结合，使得专用模型能够超越前沿模型的性能。

它大幅降低了模型的服务成本。 基于平均 token 成本估算，在前沿模型上服务这些流量每年可能轻易花费约 2700 万美元。而微调后的模型成本可能只有零头，接近 100 万美元：服务成本降低了 96%。这就是一个在 Shopify 规模下难以运行的功能，与一个可以为每个商家轻松开启的功能之间的区别。

它让模型更快，而且差距在负载下还会扩大。 Gisting 压缩将代理冗长、静态的系统提示词从大约 6,000 个 token 缩减到约 1,500 个学习到的 gist token。在每分钟 350 个请求的负载测试中，首 Token 时间（time-to-first-token）下降了约 19%，端到端延迟下降了约 38%。

它释放了硬件资源。 同样的压缩提高了吞吐量：在相同 GPU 上，每秒请求数增加约 16%，每秒输出 token 数增加约 12%。这意味着，对于相同的流量，大约可以节省 14% 的 GPU。

超越封装：产生复利的持续学习

前沿模型帮助你上线，初期的改进存在于它们周围的离散工件中：提示词、上下文、工具定义和控制流。这些更改加强了封装系统，但模型本身保持不变。

持续学习更进一步，将这些经验转化为模型连续参数空间中的更新。每个周期都始于一个更有能力的模型，而不仅仅是更复杂的封装。这就是较小的模型如何变得比前沿基线更快、更便宜且在你的任务上表现更好的原因。持久的优势在于这个持续将生产经验转化为更好权重的闭环。

相关链接：

• Sidekick's continual learning loop

Shopify 技术播报：AI 智能体工程、Checkout 升级与平台基础设施

今天是 XunbuOS Podcast 精选日。我们从 Shopify Engineering 博客中选取了十篇深度技术文章，覆盖 AI 智能体（Sidekick）、内部托管平台（Quick）、Checkout 扩展升级（Checkout Blocks）以及 Catalog API 聚类等关键议题。如果你关注 Shopfiy 平台如何向 AI 原生架构演进,今天的播报不容错过。

Sidekick 的持续学习循环：从生产失败到模型权重

飞轮的核心：质量定义驱动一切

Shopify 构建了一个名为飞轮（Flywheel）的持续学习系统，将生产环境中的失败转化为模型参数更新。以 GraphQL agent 为例，该系统不仅超越了前沿模型的质量，更将服务成本削减了 96%——从每年预估的 2700 万美元降至约 100 万美元。

飞轮的第一步是定义质量。Shopify 用评分标准（Rubric）将产品需求转化为可量化的评分维度（完整性、执行力、响应质量和安全性）。关键细节：

• 使用 Cohen's kappa 衡量标注者间一致性，目标不是"完美"评判器，而是匹配人类专家的共识水平
• 基础事实（Ground truth）必须包含随机抽样的流量，而非仅精选示例——随机抽样能揭示生产环境的真实好坏
• 标注要求提供分数背后的原因，这是校准算法学习的核心材料

校准评判器与自动研究

评判器通过 DSPy 和基于反思的优化器（GEPA、ACE）进行校准。GEPA 维护帕累托前沿候选集而非贪婪选择单一赢家。校准后需回测 A/B 测试数据：评判器能否复现已知成功与失败的方向？

此后，Shopify 将改进视为自动研究问题：一个 agent 提议对提示词、工具定义或编排架构进行更改，评判器评估分数，提高则保留否则丢弃。整个过程配置在可读的 markdown 文件中。

从离散产物到连续参数更新

当编排改进趋于平稳，优化进入参数空间。自修复管道每日运行：前沿推理模型批评低分对话，仲裁器合并批评为修复指令注入用户回合前，重放对话后评判器再次打分。修复成功的轨迹成为强化学习（GRPO）的训练数据，失败则标记给 Toloka 人工标注。

训练分两阶段：先通过 SFT 蒸馏完整轨迹（包括推理过程——思维链蒸馏让小模型继承仅靠答案学不到的行为），再用 GRPO 以评判器分数为奖励直接优化。

Gist 压缩提升服务性能

每个生成的 token 都需要关注整个系统提示词，长提示词是每次请求的固定成本。Gist 压缩将约 6,000 token 的系统提示词压缩至约 1,500 个学习到的 gist tokens：

• 负载测试（350 请求/分钟）下：首 token 时间下降 19%，端到端延迟下降 38%
• 同 GPU 上吞吐量提升：每秒请求数提高 16%，输出 token 数提高 12%，节省约 14% GPU

构建抗模型更迭的智能体代码审查框架

框架整体架构

Dispatch 是 Shopify 的内部编排器，为智能体代码审查抽象了大规模扫描复杂性。核心阶段包括：测试引导（验证测试套件可运行）、架构文档生成、文件编目、分区、猎手扫描、验证、后处理、报告和修复。

关键设计：验证阶段使用与猎手不同的模型，对抗性审查降低噪音。扫描基于差异（diff）进行增量更新，大幅降低 token 消耗。

成果与经验

六周内运行数千次扫描，产生 300+ 发现，含 2 个 Critical 级别漏洞。评估价值超过 40 万美元的 bug bounty 回报。完整应用扫描成本 50-300 美元，增量差异扫描仅 5-50 美元。

核心经验：

• 测试预言机是关键：Web 漏洞不像内存安全漏洞有编译期验证。IDOR 验证器编码了严格指南：从公开调用点反向推导、至少两个租户的测试 fixture、测试必须提取有实际影响的跨租户数据
• 分区优化成本与召回率：分区目标 token 数为模型上下文窗口的 20-30%，按领域分组文件。基准测试显示分区方法同时提高精度和召回率
• 确定性代码胜于提示词：凭证管理、Git、存储等用确定性脚本实现，智能体只负责结构化输出

框架比模型更持久

更好的模型也产生更自信的噪音——噪音对开发者的危害比没有发现更糟。持久的优势来自针对生态量身定制的框架：测试预言机、分区策略、跨模型验证，以及确定性基础设施。这是"创新的核心所在"。

Checkout Blocks 应用升级至 Polaris Web Components

升级决策与结果

Checkout Blocks 的 UI 扩展运行在三分之一的定制化结账流程上。Shopify 正在将所有 UI 扩展表面迁移到 remote-dom 与 Polaris web components，2026 年 10 月 1 日起，含早于 2026-01 版本扩展的应用部署将被阻止。

升级后每个扩展的传输体积显著下降：

加载性能（ELT）P50 下降 8%，P90 下降 7%。

关键技术决策

核心变化是从 React 切换到 Preact，配合 remote-dom 和 Polaris web components。最大的免费收获是移除了 react-reconciler（约 89KB）。API 版本从 2025-07 升至 2026-01，代码库重写为 TypeScript。

压到 64KB 以下是硬性挑战。原始包 gzip 后 100-112KB，远超限制：

• 替换 liquidjs（约 73KB）：自研精简解析器 "droplet"，用 42,000 行生产对等语料库验证与 liquidjs 完全一致。最终 13KB vs 22KB，缩小 40%
• 替换 dayjs（约 12KB）：自研轻量日期工具覆盖所需功能
• 保留 markdown-to-jsx（约 15KB）：通过 pnpm workspace catalog 将 React 别名到 Preact，无需修改即可运行

修复的 Bug 与经验

• ID 冲突（唯一一次生产回滚）：Preact 的 useId() 生成确定性 ID，同一扩展的多个实例产生重复 ID，导致弹窗错位。修复方案是 useStableId hook 生成随机实例唯一 ID
• 文本对齐：Polaris web components 中的 Paragraph 移除了 textAlign 属性，最终在 ui-extensions 中重新暴露 textAlignment（PR #4455）
• s-checkbox label slot：重构组件以支持带内联链接的 label（PR #4395）

经验总结：硬性包体积限制对买家体验有益；指标才是真正的回滚信号；用生产数据验证而非合成用例；AI 擅长机械性转换工作，工程师聚焦判断性决策。

Catalog API 产品聚类：十亿级商品统一

核心挑战：统一真实世界的商品建模

不同商家对同一商品建模方式不同：有的创建一个含所有变体的 listing，有的为每个口味或颜色分别创建。聚类目标是将相关变体和产品归入统一的通用产品标识符（UPI）。

Shopify 选择精确率优先策略：展示错误商品比结果不完整更糟糕，买家可以原谅漏掉变体但不会原谅收到错误商品。

核心价值主张框架

LLM 判断的关键问题是：买家主要为什么购买这个产品？ 如果某属性不改变答案即为变体；改变答案则是产品身份的一部分。蛋白粉口味不改变核心价值（买家购买的是营养），而油漆颜色改变了核心价值（买家购买的就是外观）。

两阶段 LLM 流水线

预分块策略：构建最近邻图（HNSW/FAISS 连接每个产品的 100 个最近邻），通过 UPGMA 合并聚类对，最近距离超阈值（0.25）或达最大块大小（200 产品）时停止。

第一阶段从块中提取品牌和型号分配 UPI；第二阶段审查提案，标记异常值。关键突破是动态结构化输出模式：为每个块动态生成 JSON schema，要求每个产品 ID 必须输出，模型无法跳过任何产品。Schema 字段顺序控制推理路径，枚举约束防止幻觉。

扩展性策略

流水线首先通过单例检测器分析商家店铺主题代码，识别已有明确跨产品链接模式的商家（metafield 引用、标签分组约定），直接分配 UPI 无需 LLM。只有小部分店铺真正需要 LLM 聚类，大幅降低成本。

Sidekick 学会说"不"：LLM 法官共识的数据策展

问题：模型从未学过拒绝

Sidekick 客户细分技能面临盲区——生产日志中的数万条查询全部成功，模型不会拒绝不可能完成的请求（如查找 Shopify 不存储的职业数据），反而生成返回零结果的查询，给商家造成错误印象。

自动化策展引擎

与 Toloka 构建约 1,200 条种子数据集（标准查询 + 拒绝标注）后直接微调效果有限——同一查询在生产与 Toloka 数据中可能标签相反。最终方案：四个前沿 LLM 作为独立法官评估生产语料，每个法官先用种子数据少样本校准。严格共识：四个法官在决策和推理上完全一致才通过，分歧样本过滤而非仲裁。

定义四个互斥标签类别：需要更多上下文、能力缺失、错误技能、模糊请求。

效果数据与经验

启用拒绝能力后，细分技能评估得分从 0.619 提升至 0.798（相对提升 28.9%）。人工验证：拒绝准确率 86.3%，误报率仅 4.6%。法官集合与种子数据一致性接近 90%，Cohen's kappa 超 0.75。

经验：小而精的种子数据价值远超体量；分类法互斥性不可妥协；多法官一致共识胜过单模型置信度；拒绝是产品功能而非失败——幻觉回答是最坏结果。

Quick：面向 AI 时代的内部托管平台

架构：简单到极致

Quick 让 Shopify 员工几秒内发布网站——放入 HTML 文件夹即得安全 URL。已托管 50,000+ 个网站，超 50% 员工至少创建过一个。

架构极其简单：每个网站是 GCS 存储桶中的文件夹，NGINX 通过 gcsfuse 挂载文件夹，整个服务器位于 Identity-Aware Proxy（IAP）后。quick deploy 不过是 gcloud rsync 的封装。

API 与 agent 生态

API 提供六个核心功能：数据库、文件上传、AI（LLM、图像生成）、数据仓库、WebSocket、身份识别。开放网络需要防黑客的复杂场景，在内部信任边界内零配置即可实现。

Quick 开箱即用地包含 agent 所需的 skills，quick init 后即可让 AI 代理构建网站。2025 年 12 月后爆发式增长：从团队仪表盘到多人游戏，最近一次游戏开发比赛提交了 140+ 款游戏。

Quick 哲学

小且固定的能力集合是易用和易维护的关键。单台虚拟机（月成本 200 美元）支撑全部 50,000+ 网站。因为内部可见，每个网站都向下一个用户展示可能性。

River 与 Aquifer：Agent 平台的进化

2024 年初的两个决定

将代码迁移到单一 monorepo（World）且用 Nix 构建一切。当时不受欢迎，但为 AI 原生基础设施奠定了基础。回报：AI agent 能跨区域导航、skills 按需加载、"向仓库提问"成为可行交互。

River：公开环境中的 Slack 智能体

River 存在于公司 Slack 公开频道，没有私信功能——每次对话默认为全公司可见。最近 30 天：59,918 次会话、5,170 个频道、3,536 个由 River 共同署名的 PR 被合并。关键洞察：公开 agent 会话是复利资产——一个人艰难的修复成为下一个人的起点。

Aquifer：会话必须存活

核心设计约束：cell 会死、沙箱会死、机器会死，但对话不会。架构分解为三部分：

• Session：持久化身份，append-only 事件日志，Postgres 支撑
• Harness：agent 循环——读历史、调用模型、发出工具意图，存在于沙箱之外
• Sandbox：代码运行的地方，可丢弃

这带来三个属性：安全性（agent 循环与 rm -rf 不在同一爆炸半径）、可替换性（换模型/运行时不影响沙箱）、可观测性（决策流在 harness 侧集中可见）。

三种消费模式

交互模式（River）、自动化模式（PR 审查）、任务模式（CI/批处理）。一个新 agent 产品只是同一个 substrate 上的新 profile（系统提示词+skills+扩展+沙箱策略+Nix bundle）。未来构建 agent 的成本不再是新平台，而只是一个 profile。

Ruvy：Ruby 到 WebAssembly 的开源工具链

Shopify 开源了 Ruvy，将 Ruby 代码转换为可直接执行的 Wasm 模块。基于 ruby.wasm 构建，核心差异：预初始化 Ruby VM——在构建 Wasm 模块时就启动 Ruby 虚拟机，而非执行期间。

性能提升：

• 运行时性能提升约 20%（44.5ms vs 56.3ms）
• Wasm 编译为原生代码（Cranelift）时间减少约 70%（446ms vs 1.66s）

另一个优势：无需在运行时提供 WASI 参数（文件路径），兼容无法配置额外启动参数的计算环境（边缘计算服务）。Shopify 公开了此工具链，特别欢迎解决 Shopify Functions 兼容性问题的贡献。

构建 ShopifyQL 代码编辑器

桥接 ANTLR 与 Lezer

ShopifyQL 编辑器使用 CodeMirror，但 CodeMirror 的语法引擎 Lezer 不遵循 LSP 协议。方案是构建适配器：将 ShopifyQL 查询传给 ANTLR 语言服务器，返回 token 流后转换为 Lezer 节点类型。

核心难点是理解 token 的增量式、相对偏移量语义——每个 token 的偏移相对于前一个 token，与 CodeMirror 期望的文档绝对偏移完全不同。

TokenIterator 解决方案

实现了一个自定义 TokenIterator：接收文档并计算每行长度，内部跟踪当前行和字符，摄取 ANTLR 风格描述符后转换为 CodeMirror 风格的起始/结束偏移量。最终实现简单，但思考过程是"最难的部分"。

连接 LSP 的 doValidate、doComplete、doHover 到 CodeMirror 插件后，编辑器获得完整的语法高亮、补全、检查和悬停提示功能，无需重写为 Lezer 语法。

今天的播报覆盖了 Shopify 向 AI 原生架构演进的全景：从 Sidekick 的持续学习飞轮到 Aquifer 会话平台，从 Catalog 聚类到 Checkout 升级。值得注意的是 Shopify 对基础设施层面的持续投入——无论是 monorepo + Nix 还是 Quick 平台，都在为 AI 时代构建 substrate。这种长期主义值得每一位 Shopify 开发者关注。

相关链接：

• Sidekick's continual learning loop
• Building an agentic harness that outlasts the model
• Upgrading Checkout Blocks app to Polaris web components
• Inside Shopify Hack Days: Building a prototype for music-playing pages
• Clustering billions of products for agentic commerce with Catalog API
• Teaching Sidekick to say no: automated data curation with LLM judge consensus
• Quick: An internal hosting platform for the AI era
• Under the River
• Introducing Ruvy
• Building a ShopifyQL Code Editor

XunbuOS Podcast：Shopify 工程周报——Agentic 基建、Checkout 性能跃迁与库存系统重构

Shopify 工程团队本周密集发布了多项底层技术演进的核心细节：从 AI 代理基础设施（Agentic Harness）的构建哲学，到 Checkout 扩展的 Polaris Web Components 迁移，再到用 MySQL 替代 Redis 支撑库存预留的规模化实践。

构建超越模型生命周期的 Agentic Harness

Shopify 应用安全团队开源了名为 Dispatch 的 agentic 代码审查框架。其核心设计理念是：模型会不断迭代更新，但框架本身才是长期价值的所在。

Dispatch 以多阶段流水线方式运行扫描任务。首次扫描时会基于代码规模进行分区（partitioning），并行部署多个 Hunting agent 扫描各分区，并生成可复用的 API 与数据模型文档。后续扫描采用 diff-based 增量模式，仅对比最新两次提交的差异，大幅降低 token 消耗。

九个流水线阶段：测试引导、架构文档生成、文件编目、分区、狩猎、验证、后处理、报告和修复。验证阶段使用与 Hunting 不同的模型，通过对抗性审查降低误报率。

实际效果：已扫描超过 80 个应用（含 Shopify Core monolith），六周内完成数千次扫描，产出 300 多个发现（含 2 个 Critical 级别），保守估计价值超过 40 万美元的 bug bounty。全量扫描成本 50-300 美元，增量扫描仅需 5-50 美元。

关键经验：验证 web 漏洞的可利用性最难——不同于内存安全漏洞可用编译器标志直接验证，web 漏洞缺乏直接的测试预言机。解决方案是让 Verifier agent 将验证嵌入应用现有的测试框架中，并编码严格的判定准则（要求跨租户 fixture、完整公共调用栈、有实际影响力的数据提取）。团队还发现，"安全通才" agent 效果不佳，应转向按漏洞类别定制的专用 agent，并将分区 token 数控制在模型上下文窗口的 20-30%。

Checkout Blocks 迁移至 Polaris Web Components

Checkout Blocks 的 UI 扩展运行在三分之一的定制化结账流程上。团队将全部五个扩展从 React + Remote UI bridge 迁移至 remote-dom + Preact + Polaris web components，代码库重写为 TypeScript。

性能数据：各扩展传输体积缩减 40.5%-84.4% (payment-icons 从 100KB+ 降至约 16KB)；扩展加载时间（ELT）P50 下降 6.5%-11.7%。自 2026 年 10 月 1 日起，包含早于 2026-01 版本扩展的应用部署将被阻止。

将 bundle 压缩到 64KB 以下（2026-01 remote-dom CLI 硬性限制）是最大的工程挑战：

• 移除 react-reconciler（约 89KB）：切换 Preact 免费获得
• 替换 liquidjs（约 73KB）：自研 "droplet" 解析器，gzip 后 13KB vs liquidjs 22KB，依托 42,000 行生产 parity 测试语料库验证
• 替换 dayjs（约 12KB）：自研轻量日期工具
• 保留 markdown-to-jsx（约 15KB）：通过 pnpm workspace catalog 将 React 别名到 Preact

修复的关键 Bug：

• ID 冲突（唯一一次生产回滚）：Preact 的 useId() 生成确定性 ID，同一扩展两个实例会生成相同 ID。改用 useStableId hook 生成随机、实例唯一的 ID
• 文本对齐：Polaris web components 的 Paragraph/Heading 移除了 textAlign 属性，最终在 ui-extensions 中重新暴露 textAlignment（PR #4455）
• s-checkbox label slot：仅接受纯字符串，破坏"接受[条款与条件]"内联链接模式，重构为接受 HTMLElement（PR #4395）

Clustering 数十亿商品：Catalog API 的 Agentic Commerce 底座

Shopify Catalog 的核心是产品聚类（product clustering）——将不同商家对同一现实世界物品的多样建模方式（单一产品含变体 vs 按颜色拆分产品）统一到 Universal Product Identifier (UPI) 之下。团队采取精确度优先策略：呈现错误结果比不完整结果更糟糕。

"核心价值主张"框架：问模型"买家主要购买这个产品是为了什么目的？"——如果属性不改变这个答案，就是变体；如果改变，则是产品身份的一部分。例如：蛋白粉的口味是变体（购买为了营养），油漆的颜色则定义了产品（购买为了外观）。

两阶段 LLM 流水线：

1. 预分块：HNSW 嵌入 + 稀疏平均链接（UPGMA），每个产品连接到最近 100 个邻居，分块上限 200 个产品，距离阈值 0.25
2. 阶段 1：提取品牌 + 型号字符串，相同 brand:model 对分组到同一 UPI
3. 阶段 2：离群值检测——批判比创造更可靠，默认将商品保持在一起除非有明确证据

关键突破：采用动态生成的 OpenAI Structured Output schema，为输入中的每个产品 ID 定义必需的 schema 属性，保证 LLM 无法跳过任何产品。product_id 重映射为规范化 ID（如 12345 → 1）提高缓存命中率并降低成本。Schema 对聚类质量的影响与提示文本一样大——清理输出中的非 ASCII 标记使召回率提升 8%。

Teaching Sidekick to Say No：LLM Judge 共识驱动的数据策展

Sidekick 客户细分技能模型的问题：生产训练语料全是成功案例，零拒绝样本，模型从未学会说"不"。面对无法完成的查询（如查找"职业是医生"的顾客，Shopify 不存储该数据），模型会生成返回零结果的查询，给商家造成"没有匹配顾客"的错误印象。

方法：将小规模人工标注数据集（Toloka，约 600 标准 + 602 拒绝）作为种子，驱动自动化数据策展引擎——四个前沿 LLM 作为裁判（judge）独立评估查询。

关键设计：

• 严格共识优于宽松置信度：四位裁判必须在决策和推理两方面全部一致才接受标签变更，分歧案例被过滤而非仲裁。Cohen's kappa 均高于 0.75
• 互斥分类体系：需要更多上下文 / 功能缺失 / 技能路由错误 / 有歧义——模糊类别会造成裁判分歧并向下游累积
• 数据飞轮：改进后的模型上线后，生产流量成为下一轮采样池，裁判组合标注新模式，被接受样本加回语料库

成果：细分技能评估分数从 0.619 提升到 0.798（相对提升 28.9%）；自动化策展方案在相同基线上将细分通过率从 0.762 提升到 0.798；人工验证拒绝准确率 86.3%，误报率 4.6%。

用 MySQL 替换 Redis 做库存预留

Shopify 用 MySQL 的 SKIP LOCKED 特性替换 Redis 实现库存预留，消除了 Redis 方案中预留与库存台账分处两个系统无法原子操作的故障模式。

核心设计：每单位一行，有界设计。10 个单位的商品有 10 行，预留 3 个单位意味着在一个事务中选择并移动 3 行。预留和台账在同一数据库中获得 ACID 保证。但为避免 50,000 单位商品产生 500,000 行的表膨胀，维护了每个商品/地点组合上限 1,000 行的可用行池，补货进程从库存台账补充。池耗尽时预留路径触发内联补货，锁确保一次只有一个事务补货避免惊群效应。

四个关键技术决策：

1. 复合主键：shop_id, inventory_item_id, inventory_group_id, id 替代自增 ID——每行只产生一个锁而非两个（二级索引 + 聚簇索引）
2. READ COMMITTED 隔离级别：避免空表上的间隙锁（supremum 锁）阻塞补货事务
3. 一致的锁顺序：预留路径统一先 DELETE 单位表再 INSERT 预留表，消除死锁循环
4. UNION ALL 批处理：一次往返获取多行商品（line items）购物车的所有单位

真正的瓶颈：不是 CPU 而是连接。结账路径的其他部分持有连接时间超过必要，预留只是压垮骆驼的最后一根稻草。通过在应用层为每条 SQL 语句添加 /* conn_tag:checkout_completion */ 注释标签，在 ProxySQL 层聚合测量每个调用方的连接持有时长，定位并清理了结账路径——主数据库读取减少 50%，事务减少 33%。

Quick：AI 时代的内部托管平台

Quick 是 Shopify 的内部托管平台——放入包含 HTML 和静态资源的文件夹，即可获得仅 Shopify 员工可见的安全 URL。2025 年 7 月推出，如今承载超过 50,000 个网站，超半数员工至少创建过一个。

架构：每个"网站"即 Google Cloud Storage 存储桶中的一个文件夹，前置轻量级 NGINX 服务器通过通配符配置映射子域名，gcsfuse 将存储桶挂载为本地文件系统。整个服务器位于 Identity-Aware Proxy (IAP) 之后，所有请求已验证为 Shopify 员工身份。

核心功能集：数据库（CloudSQL）、文件上传、AI（LLM、图像生成）、数据仓库（Big Query）、WebSocket、身份认证——所有 API 零配置，密钥存于服务器端。

哲学：保持简单 + 拥抱约束。没有权限概念、没有"站点所有者"，所有站点对所有员工开放。单人维护，运行在一台单 VM 上，每月成本仅 200 美元。

Ruvy：Ruby 代码的 WebAssembly 工具链

Shopify 开源了 Ruvy——接收 Ruby 代码并生成可执行该代码的 WebAssembly 模块。构建于 ruby.wasm 之上，两个核心优势：

1. 预初始化 Ruby VM：构建 Wasm 模块时就预初始化虚拟机，运行时性能提升约 20%（Wasmtime 中实例化 + 执行 _start：44.5ms vs 56ms）；编译为原生代码时优势更显著，编译时间减少约 70%
2. 执行时无需 WASI 参数：不要求文件路径作为 WASI 参数，兼容无法配置额外参数的计算环境（如边缘计算服务）

对于希望在 Shopify Functions 中复用 Shopify Scripts Ruby 逻辑的 Partners，解决与 Functions 的兼容性问题值得重点关注。

相关链接：

• Building an agentic harness that outlasts the model
• Upgrading Checkout Blocks app to Polaris web components
• Inside Shopify Hack Days: Building a prototype for music-playing pages
• Clustering billions of products for agentic commerce with Catalog API
• Teaching Sidekick to say no: automated data curation with LLM judge consensus
• Quick: An internal hosting platform for the AI era
• Under the River
• We replaced Redis with MySQL for inventory reservations—and it scaled
• Introducing Ruvy
• Building a ShopifyQL Code Editor

Shopify 工程精选：代理基础设施、库存系统重构与 Ruvy 工具链

Shopify 工程团队近期发布了一系列深度技术文章，涵盖代理化代码审查、库存预留系统重构、AI 代理平台架构、以及 WebAssembly 工具链等前沿主题。

构建一个比模型更持久的代理框架

Dispatch 核心架构

Shopify 应用安全团队构建了一个名为 Dispatch 的 agentic 代码审查框架，用于在大型 Rails 单体应用中发现安全漏洞。核心设计理念是：模型会不断迭代，但框架本身才是长期价值所在。

Dispatch 是构建在 Ruby 之上的轻量级编排器，抽象了大规模 agentic 扫描的复杂性。首次扫描时，管线会基于代码规模和范围进行分区，并行部署多个狩猎代理进行全量扫描，并生成可复用的工件记录 API 和数据模型信息。后续扫描采用基于 diff 的增量方式，大幅降低 token 消耗。

实际成果

该框架已对超过 80 个应用完成全量扫描，在约六周内完成数千次扫描，产生 300 多个发现，保守估值超过 40 万美元的等价漏洞赏金。全量应用扫描成本在 50 至 300 美元之间，增量 diff 扫描仅需 5 至 50 美元。

关键经验

验证 Web 漏洞的可利用性具有挑战性，团队在代理中编码了严格指南，例如 IDOR 验证器要求从公共调用点逆向追溯、创建属于两个不同租户的 fixtures。分区策略是成本控制的关键：每个分区 token 数量约占模型上下文窗口的 20-30%，回测实验表明该方法能同时提高准确率和召回率。

用 MySQL 替换 Redis 支撑库存预留系统

超卖保护系统

Shopify 的超卖保护系统通过在支付处理期间预留库存来防止并发结账占用同一库存单位。旧系统运行在 Redis 上，但预留与库存台账分散在两个不同系统中，无法在 ACID 事务中封装全部操作。

SKIP LOCKED 核心设计

新方案为每个可售单位创建一行，而非每个商品一行。SKIP LOCKED 让 MySQL 跳过已被其他事务锁定的行，大幅降低争用。系统维护一个有限的可用行池，上限为每个商品/地点组合 1,000 行，通过补货进程从库存台账中补充新行。

关键技术决策

• 复合主键：减少每行锁，从每预留两个行锁降为一个
• READ COMMITTED：避免间隙锁阻塞补货事务
• 一致的锁顺序：统一操作顺序消除死锁
• UNION ALL 批量处理：减少数据库往返次数

真正的瓶颈

通过应用层 conn_tag 注释标签和 ProxySQL 层追踪，团队发现预留并非唯一的重度使用者——结账路径上的其他部分持有连接的时间超过了必要水平。清理后主数据库读操作减少 50%，事务减少 33%。高流量闪购期间，写入 CPU 保持在 50% 以下，读取 CPU 保持在 16% 以下。

内部 AI 代理平台 Aquifer 与 River

River 设计原则

River 是 Shopify 部署在公司 Slack 中的 AI 代理，设计上只支持公开渠道对话，让知识得以累积和复用。近期 30 天数据：59,918 次会话，覆盖 5,170 个 Slack 频道，7,000+ 员工参与，3,536 个由 River 共同署名的 PR 被合并。

Aquifer 三层架构

• Session：持久化身份，append-only 事件日志，基于 Postgres
• Harness：代理循环，可廉价重建，可丢弃
• Sandbox：代码运行环境，文件系统、shell、仓库

核心原则是解耦"大脑"与"手"——harness 不生活在 sandbox 内，带来安全性、可替换性和可观测性三个关键特性。

关键建议

1. 将大脑与手解耦，这一边界决定了安全性、可替换性和可观测性
2. 让代理从架构上就是多人协作的，公开代理教给每个后续会话
3. 将下一个代理视为 profile 而非新平台

通过 LLM 裁判共识训练模型说"不"

问题定义

Sidekick 的训练数据只包含成功查询，模型遇到无法完成的任务时只能即兴发挥。当被要求执行不可能查询时，模型不会拒绝，而是生成一个返回零结果的查询，给商家造成错误印象。

LLM 裁判共识方案

团队将小规模人工标注数据集用作自动化策展引擎的种子，四个前沿 LLM 作为独立裁判。只有当所有裁判对决策和推理都达成一致时，标签才通过共识门，以高精度换取部分覆盖率。

成果数据

启用拒绝能力后，细分技能的评估分数从 0.619 提升至 0.798（相对提升 28.9%）。人工验证显示：拒绝准确率 86.3%，误报率 4.6%。四个模型的 Cohen's kappa 均超过 0.75。

经验教训

• 小种子数据集价值远超其规模，种子数据的质量决定一切
• 分类互斥性不可妥协，模糊类别会造成裁判分歧
• 早期管道中共识优于置信度
• 拒绝是产品功能，不是失败——诚实的拒绝（最好附带替代建议）能让外层规划器保持对话的积极性

Catalog API：数十亿商品的聚类技术

核心价值主张框架

团队设计了一个关键原则来指导 LLM：买家购买这个产品的主要目的是什么？如果某个属性不改变这个答案，它就是一个变体；如果改变了答案，它就是产品身份的一部分。该原则被直接编码进提示词中。

两阶段 LLM 流水线

预分块阶段采用 ANN 检索 + 稀疏平均链接，使用 HNSW 在 FAISS 中查找每个商品的 100 个最近邻，聚类达到最大块大小（200 个商品）时停止合并。

第一阶段：LLM 为每个商品提取品牌和型号字符串，具有相同品牌:型号对的商品归入同一 UPI。第二阶段：离群点检测，从零开始决定聚类是创造性的工作，但测试一个已提出的聚类是批判性任务。

动态结构化输出突破

关键创新在于 schema 是根据每个块动态生成的：输入中的每个商品 ID 都会在输出 products 对象中定义一个必需属性，模型在结构上就不可能跳过任何商品。字段顺序可以控制推理过程，enum 约束可以防止幻觉。

Quick：面向 AI 时代的内部托管平台

平台定位

Quick 于 2025 年 7 月上线，让 Shopify 的任何人在几秒内上线一个网站。放入一个包含 HTML 和静态资源的文件夹，就能得到一个仅供员工访问的安全 URL。目前托管着超过 5 万个网站，超过一半的员工至少创建过一个。

架构演进

起点是"每个站点就是一个 GCS 存储桶中的文件夹"，通过 gcsfuse 挂载和 NGINX 提供服务。后续逐步添加了数据库、文件上传、AI、数据仓库、WebSocket 和身份识别六个核心 API。

核心哲学

所有 Quick 站点对所有员工开放，甚至没有"站点所有者"这个概念。一套小而固定的能力集合正是让 Quick 保持简单易用、易于维护的原因。全部运行在一台每月成本 200 美元的单一虚拟机上。

Agent + Quick

Quick 开箱即带了你所用 agent 需要的一切技能，通过 quick init 启动 agent，不到一分钟就能上线一个可分享、可使用的网站。

Hack Days：为音乐人构建产品页面音频播放器

问题背景

音乐类产品在过去一年创造了超过 10 亿美元的 GMV，但数字专辑产品页面通常只有图片和购买按钮，没有内置的音乐试听功能。

双路线并行

团队并行推进了两条路线：平台路线新增 audios 数据库表和 Audio GraphQL 类型，让 {{ product.media | media_tag }} 可以渲染音频播放器；应用路线构建了名为 Shop Sounds 的独立应用，基于 React Router、Polaris 和 Shopify App 框架。

关键架构决策

• metaobjects 作为数据层：避免自定义数据库和同步问题
• 全局音频单例：通过应用嵌入块注入单个 audio 元素，切换页面不中断播放
• 六个自定义 GLSL 着色器：由相同音频数据驱动，6 种着色器 × 7 种调色板 = 42 种视觉身份

Checkout Blocks 升级到 Polaris Web Components

升级结果

升级后所有扩展的传输包体积显著下降，降幅在 40% 到 85% 之间。加载性能方面，以扩展加载时间（ELT）为指标，P50 提升 8%，P90 提升 7%。

核心架构变化

从 React 切换到 Preact，用 s-* 组件替换了原来的 Polaris React 树。最困难的挑战是控制在 64KB gzip 以内的包体积限制。团队用 AI 辅助开发了名为 "droplet" 的精简版 Liquid 解析器（13KB vs 22KB），基于 42,000 行生产对等语料库验证。

过程中修复的 bug

• ID 冲突：Preact 的 useId() 生成确定性 ID 导致同一扩展的多个实例产生相同 ID，通过 useStableId hook 修复
• 文本对齐：textAlign 已从 Polaris web components 移除，最终在 ui-extensions 中重新暴露了 textAlignment 属性
• label 槽位重构：新增接受字符串或 HTMLElement 的 label 槽位

ShopifyQL 代码编辑器的构建

核心挑战

ShopifyQL 语言服务器基于 ANTLR 语法构建，而 CodeMirror 使用 Lezer 解析器引擎，两者不遵循同一协议。团队创建了一个遵循 LSP 并与 Lezer 集成的适配器。

Token 偏移转换

最大的障碍是 ANTLR 的 token 偏移值是相对于前一个 token 的，而 CodeMirror 中一切都是相对于文档顶部的。团队通过自定义 TokenIterator 类解决了转换问题，接收 ANTLR 风格的行、字符和 token 长度描述符，计算 CodeMirror 风格的起始偏移量和结束偏移量。

Ruvy：从 Ruby 代码生成 Wasm 模块

工具定位

Ruvy 以 Ruby 代码为输入，生成可执行该代码的 WebAssembly 模块。与 ruby.wasm 相比有两个核心优势：通过预初始化 Ruby VM 提升约 20% 的运行性能；执行时无需提供 WASI 参数，兼容边缘计算服务。

性能数据

Hello world 示例中，Ruvy 执行时间约 44.5ms，而 ruby.wasm + wasi-vfs 约 56.3ms。Wasm 到原生代码的编译时间约 446ms vs 1.66s，减少了约 70%。

Dispatch 之外：Hack Days 的价值

Shopify 每年大约举办两次 Hack Days，这是世界上最大的黑客马拉松之一，有数千名参与者。不是每个项目都能上线，但每个项目都让公司学到了关于平台能力和商家需求的新东西。

相关链接：

• Building an agentic harness that outlasts the model
• Upgrading Checkout Blocks app to Polaris web components
• Inside Shopify Hack Days: Building a prototype for music-playing pages
• Clustering billions of products for agentic commerce with Catalog API
• Teaching Sidekick to say no: automated data curation with LLM judge consensus
• Quick: An internal hosting platform for the AI era
• Under the River
• We replaced Redis with MySQL for inventory reservations—and it scaled
• Introducing Ruvy
• Building a ShopifyQL Code Editor

Shopify 技术周报：Agentic 基础设施、结账扩展性能优化与库存系统的 MySQL 迁移

Shopify 工程团队近期发布了多项值得关注的技术实践：从 Agentic 代码审查框架到结账扩展的性能升级，从数十亿商品的聚类系统到库存预留系统的底层迁移。

构建比模型更持久的 Agentic 框架

核心设计理念

Shopify 应用安全团队开发了一个可扩展的 Agentic 代码审查与测试预言机框架，用于自动发现安全漏洞、验证可利用性并提供修复方案。设计的核心原则是：模型会不断迭代升级，但框架本身才是值得长期投资的对象。

流水线架构

编排器名为 Dispatch，是一个轻量级 Ruby 客户端，以流水线方式运行多个有序阶段：测试引导、架构文档生成、文件编目、分区、漏洞狩猎、验证、后处理、报告和修复。增量扫描只对比最新提交与上次提交的差异，大幅降低 token 消耗。

实际成果与成本

该框架已扫描超过 80 个应用，约六周内执行数千次扫描，产生 300 多个发现。团队保守估计这些发现的等效漏洞赏金价值超过 40 万美元。一次完整应用扫描成本在 50 至 300 美元之间，增量差异扫描成本低至 5 至 50 美元。

关键经验

• 为 Web 漏洞构建测试预言机极具挑战，团队将验证逻辑嵌入现有测试体系
• 安全通才型多代理工作流效果不佳，应转向针对性更强的分类代理
• 将目标仓库打包为聚焦分区是性价比最高的方式，token 数量控制在模型上下文窗口的 20-30%
• 使用确定性脚本处理结构化输入输出，减少格式错误

Checkout Blocks 升级至 Polaris Web Components

升级背景与成果

Checkout Blocks 的五个高流量结账扩展已迁移到 remote-dom 和 Polaris web components，运行在 2026-01 API 版本上。升级后每个扩展的传输体积显著下降：payment-icons 缩减 84.4%，static-content 缩减 54.1%，custom-field 缩减 44.6%，dynamic-content 缩减 45.2%，line-item-actions 缩减 40.5%。扩展加载时间（ELT）P50 下降 8%，P90 下降 7%。

架构变化

核心变化是从 React 迁移到 Preact，从 JSX 迁移到 TypeScript。Polaris web components 作为框架无关的自定义元素，无需专门的 reconciler。升级采用增量策略：新建 core-next 共享库，逐个扩展升级，最后合并回单一 core。

64KB 包体积限制的应对

2026-01 版本 remote-dom CLI 对每个扩展包强制执行 64KB gzip 硬性上限。最大的优化来自移除 react-reconciler（约 89KB），替换 liquidjs 为自研精简解析器（gzip 后 13KB vs 约 22KB），以及用小型内部日期工具替换 dayjs（约 12KB）。markdown-to-jsx 通过别名到 Preact 保留。

过程中修复的 Bug

• ID 冲突：useId() 在多个扩展实例间生成相同 ID，导致回滚，修复方案是随机实例唯一 ID 的 useStableId hook
• 文本对齐：Polaris web components 移除了 textAlign 属性，最终在 ui-extensions 中重新暴露 Paragraph 的 textAlignment
• s-checkbox label slot：重构为接受字符串或 HTMLElement 的 label slot

用 Catalog API 聚类数十亿商品

问题背景

Shopify 托管着数十亿条商品列表，商家们对同一现实物品采用截然不同的结构。AI 购物智能体需要理解一个商家的单一列表和另一个商家的十二条列表描述的是同一产品线。

核心价值主张框架

团队向 LLM 提出的关键问题是：买家主要为什么购买这个产品？如果某个属性不改变答案，它就是变体；如果改变答案，它就是产品身份的一部分。例如蛋白粉的口味是变体，油漆的颜色是独立产品。

两阶段 LLM 流水线

• 预分块：使用 ANN 检索（FAISS/HNSW）加稀疏平均链接，将语义相关的产品聚成不超过 200 个产品的块
• 阶段 1：提取品牌和型号字符串，相同 brand:model 配对的产品归入同一 UPI
• 阶段 2：离群值检测，默认保留，除非有明确证据表明核心价值不同

动态结构化输出 Schema

采用 OpenAI Structured Output 强制 JSON schema，schema 按块动态生成，为每个产品 ID 定义必需属性。将产品 ID 重映射为规范化 ID 提高缓存命中率。清理非 ASCII 标记使召回率提升 8%。

教 Sidekick 学会拒绝：LLM 评判员共识的数据策展

问题：生产数据的盲区

生产训练语料中的每个样本都是成功案例，模型从未学会说"不"。当遇到无法实现的查询时，模型会生成返回零结果的查询，给商家造成"没有匹配的客户"的错觉。

解决方案：数据飞轮

团队将 Toloka 的小数据集转化为自动化策展引擎的种子数据，使用四个前沿 LLM 作为自动化数据评判员。四个评判员独立评估，只有全部达成一致且推理一致时标签才通过共识门。分类体系严格互斥：需要更多上下文、能力缺失、错误技能、含义模糊。

效果数据

启用拒绝能力后，细分技能评估分数从 0.619 提升到 0.798（相对提升 28.9%）。拒绝准确率 86.3%，误报率 4.6%。评判员与真实种子数据的一致性接近 90%，Cohen's kappa 系数均超过 0.75。

Quick：面向 AI 时代的内部托管平台

平台定位

Quick 让 Shopify 任何员工在几秒内上线网站：放入包含 HTML 和静态资源的文件夹，获得安全 URL。上线以来托管超过 50,000 个网站，超过一半员工至少创建过一个。

架构要点

• 基础架构：Google Cloud Storage 存储桶 + gcsfuse 挂载 + NGINX 伺服，整个服务器位于 Identity-Aware Proxy 之后
• 核心 API：数据库、文件上传、AI（LLM/图像生成）、数据仓库、WebSocket、身份识别
• 每月成本 200 美元，运行在单台 VM 上

设计理念

所有 Quick 网站对所有员工开放，没有"网站所有者"概念。一小套固定能力让平台易于使用和维护，也更有创造力。内部工具的性质让开放互联网的复杂性完全消失。

库存预留系统：从 Redis 迁移到 MySQL

核心方案：SKIP LOCKED

每个可售单位一行，而不是每商品一行。预留通过 SELECT ... FOR UPDATE SKIP LOCKED 选择并移动行，与库存台账在同一数据库中获得 ACID 保证。维护有界可用行池（上限每商品/地点 1,000 行），预留从池中消耗行，补货进程重新填充。

关键实现细节

• 复合主键：减少每次预留从两个行锁到一个
• READ COMMITTED 隔离级别：避免间隙锁阻碍补货
• 一致的锁顺序：预留先 DELETE 单位表再 INSERT reserved_quantities，避免死锁
• UNION ALL 批处理：一次往返获取所有订单行所需单位

真正的瓶颈：连接而非 CPU

生产环境中吞吐量上限远低于目标，但 CPU 未饱和。通过应用端 SQL 注释标签 + ProxySQL 层按调用方聚合连接持有时长，发现结账路径中其他代码持有连接时间过长。清理后主数据库读操作减少 50%，事务减少 33%。

迁移策略

以影子模式并行运行两套系统，每次预留同时写入 Redis 和 MySQL，Redis 保持为数据源。验证正确性和性能后切换数据源，kill switch 可随时回退。

ShopifyQL 代码编辑器构建实践

架构方案

ShopifyQL 语言服务器基于 ANTLR TypeScript 目标构建，遵循语言服务器协议（LSP）。CodeMirror 使用 Lezer 解析引擎，不遵循 LSP。团队创建了适配器，将 ShopifyQL 查询传递给语言服务器，转换 token 流为 Lezer 缓冲区。

Token 偏移量的关键挑战

ShopifyQL token 以 5 个整数一组返回（行号、起始字符、长度、类型、修饰符），但值是相对于前一个 token 的增量。注释可能产生负的行号偏移。解决方案是实现自定义 TokenIterator，跟随偏移量"方向"并转换为 CodeMirror 的绝对偏移量格式。

语言功能集成

将语言服务器的 doValidate 与 CodeMirror 的 linting 插件适配，doComplete 与 autocomplete 插件适配，doHover 与 requestHoverTooltips 插件适配，完成后提供完整的代码补全、检查和悬停提示。

本期关键数据回顾：Checkout Blocks 扩展传输体积最大缩减 84.4%；库存系统迁移后高峰期写 CPU 低于 50%；Agentic 安全扫描单次成本低至 5 美元；Sidekick 拒绝能力使评估分数相对提升 28.9%。

相关链接：

• Building an agentic harness that outlasts the model
• Upgrading Checkout Blocks app to Polaris web components
• Inside Shopify Hack Days: Building a prototype for music-playing pages
• Clustering billions of products for agentic commerce with Catalog API
• Teaching Sidekick to say no: automated data curation with LLM judge consensus
• Quick: An internal hosting platform for the AI era
• Under the River
• We replaced Redis with MySQL for inventory reservations—and it scaled
• Introducing Ruvy
• Building a ShopifyQL Code Editor

Shopify 工程团队：Agentic AI、库存系统重构与开发者平台的深度实践

今天的 Shopify 技术动态集中在 AI 代理的规模化落地、核心系统架构演进与开发者体验优化。从应用安全团队构建的 agentic 代码审查框架，到将 Redis 库存预留替换为 MySQL 的工程决策，再到内部托管平台 Quick 的爆发式增长——工程师们正以数据驱动的方式，重新定义平台能力的边界。

构建超越模型生命周期的 Agentic Harness

核心设计原则

Shopify 应用安全团队构建了名为 Dispatch 的 agentic 代码审查系统。设计理念是"模型会过时，但 harness 永存"——框架保持稳定，模型可随时替换。Dispatch 是一个用 Ruby 编写的轻量级客户端，将 agentic 扫描的复杂性抽象化，让扫描作者能轻松创建针对特定漏洞类别的猎手代理。

扫描流程与成本控制

扫描流程以八个有序阶段运行：测试引导、架构文档生成、文件编目、分区、并行猎手扫描、验证、后处理和报告。验证阶段使用与猎手不同的模型进行对抗性审查，以降低误报率。

成本控制上，团队采用分区策略，将文件按领域分组，每个分区控制在模型上下文窗口的 20-30%。完整应用扫描成本在 50 到 300 美元之间，增量 diff 扫描只需 5 到 50 美元。

成果数据

团队已在超过 80 个应用上完成完整扫描，包括 Shopify Core 单体应用。六周内产生超过 300 个发现，保守估值相当于 40 万美元的漏洞赏金，其中两个被评为 Critical。

升级 Checkout Blocks 至 Polaris Web Components

升级动因

Checkout Blocks 应用将五个高流量结账扩展从 React 迁移至 Preact + Polaris web components，传输包体积缩减 40% 至 85%。升级是为了满足 2026-01 CLI 强制执行的 64KB gzip 包体积上限。

关键决策

• 放弃 react-reconciler（约 89KB），切换至 Preact
• 移除 liquidjs（约 73KB），自研 "droplet" 解析器，仅 13KB gzipped
• 用小型自研 date utility 替换 dayjs（约 12KB）
• 保留 markdown-to-jsx，通过 pnpm workspace 别名指向 Preact

修复的平台问题

开发过程中发现并修复了三个平台级问题：ID 碰撞导致的生产事故、Polaris web components 文本对齐属性缺失、s-checkbox label 不支持内联链接。

扩展加载时间（ELT）的 P50 和 P90 分别下降约 8% 和 7%。

Shopify Hack Days：构建音乐播放页面原型

Shop Sounds 应用

一个 13 人团队在三天内构建了音乐播放页面原型。音乐和录音类产品年 GMV 超过 10 亿美元，但产品页面缺乏试听功能。团队构建了包含曲目列表播放器、六个 GLSL 可视化器、同步歌词和巡演日期块的完整应用。

关键技术实现

团队在平台层面新增了 Audio 媒体类型，包括新的 audios 数据库表、GraphQL 类型和 Liquid drops。全局音频单例通过应用嵌入块注入单个 audio 元素，确保页面导航不中断音乐播放。

六个自定义 GLSL 着色器共享相同的 uniform 接口，支持七种配色方案，共 42 种视觉组合。架构上使用 metaobjects 和 metafields 作为数据层，无需自定义数据库。

使用 Catalog API 对数十亿商品进行聚类

核心价值主张框架

Shopify Catalog 团队使用 LLM 对商家产品进行聚类，统一到通用产品标识符（UPI）下。关键问题是：买家购买这个产品的主要目的是什么？如果属性不改变答案，就是变体；如果改变，则是独立产品。

两阶段 LLM 流水线

• 预分块：使用 ANN 检索（FAISS）加稀疏平均链接，将产品组装成语义相关的块（最多 200 个产品）
• 阶段 1：提取品牌和型号字符串，据此分配 UPI
• 阶段 2：离群值检测，扫描聚类查找不匹配项

关键突破：动态结构化输出

使用 OpenAI Structured Output 的严格 JSON 模式强制，为每个块动态生成模式，保证每个产品 ID 都获得分类。枚举约束防止幻觉产品 ID。模式塑造行为比提示措辞更可靠，改变字段顺序会改变提取质量。

团队对齐评估基准和 LLM 裁判持续跟踪精确率与召回率，坚持精确率优先策略。

教会 Sidekick 何时说"不"

问题背景

Sidekick 的客户细分技能遇到训练盲区：生产日志只有成功案例，模型遇到无法满足的请求时会生成返回零结果的查询，而非告知请求不可行。

自动化策展管道

团队将 600 条人工标注数据作为种子，构建了自动化策展引擎。四个前沿 LLM 评审模型独立评估，只有全部一致通过才采纳标签。分歧样本被过滤而非仲裁，优先保证精确率。

每条查询被归入四个互斥类别：需要更多上下文、能力缺失、错误技能、含糊不清。

成果

细分技能评估分数从 0.619 提升至 0.798（相对提升 28.9%），拒绝准确率 86.3%，误报率 4.6%。评审集成与基准标注一致性接近 90%。

Quick：为 AI 时代打造的内部托管平台

平台定位

Quick 让 Shopify 员工在几秒内上线网站：放入 HTML 文件夹即得安全 URL。2025 年 7 月上线，如今托管超过 5 万个网站，超过半数员工创建过。

架构与核心功能

单台 NGINX 服务器 + GCS 存储桶，位于 Identity-Aware Proxy 之后。核心功能包括数据库、文件上传、AI（LLM、图像生成）、数据仓库、WebSocket 和身份认证。全部运行在一台每月 200 美元的虚拟机上。

涌现的生态系统

Quick 正在形成内部生态系统，人们开始发布共享 JS 库并制作落地页。最近一次游戏创作马拉松提交了超过 140 款游戏。团队保持简单哲学："未经认证的公共互联网复杂性在内部工具中消失不见。"

用 MySQL 替换 Redis 扩展库存预留

为什么放弃 Redis

原系统将库存预留存储在 Redis 中，但预留和库存台账分属两个系统，无法原子执行，可能造成超卖或欠卖。新方案使用 MySQL 8 的 SKIP LOCKED 特性，将数据模型从"每件商品一行"改为"每个库存单元一行"。

四个关键技术决策

• 复合主键减少行锁，过滤条件成为主键一部分
• READ COMMITTED 避免间隙锁，防止死锁
• 一致的锁顺序，标准化 reserve 和 claim 的锁获取路径
• UNION ALL 批处理，多个预留查询合并为一次往返

真正的瓶颈：连接池

通过给 SQL 语句添加注释标签并在 ProxySQL 层统计，团队发现预留并非连接消耗的真正来源——结账路径其他代码持有连接时间更长。清理后主数据库读取量减少 50%，事务量减少 33%。

迁移策略

团队运行影子模式：每个预留同时写入 Redis 和 MySQL，确认无误后逐步切换，并通过 kill switch 随时回滚。

推出 Ruvy：Ruby 到 WebAssembly 工具链

工具定位

Ruvy 以 Ruby 代码作为输入，生成可执行该代码的 WebAssembly 模块。构建在 ruby.wasm 之上，核心优势是预初始化 Ruby VM 和脚本文件，运行时无需提供 WASI 参数。

性能对比

在 Wasmtime 中实例化并执行 _start 函数：Ruvy 约 44.5 毫秒，ruby.wasm 约 56 毫秒。Wasm 编译为原生代码耗时减少约 70%（446 毫秒 vs 1.66 秒）。

适用场景

Ruvy 创建的模块兼容无法配置额外 WASI 参数的计算环境（如边缘计算服务）。对于希望在 Shopify Functions 中复用 Shopify Scripts Ruby 逻辑的合作伙伴，解决兼容性问题可能尤其值得关注。

构建 ShopifyQL 代码编辑器

架构方案

ShopifyQL 编辑器基于 CodeMirror，通过自定义适配器将 ANTLR 语法与 Lezer 解析器桥接。语言服务器遵循 LSP 协议，解析树通过分词流转换构建。

关键难点：分词偏移量

ANTLR 的偏移量是相对前一个分词的，而 CodeMirror 从文档顶部计算。注释在非默认 channel 解析，可能产生负行号（-2）。团队实现了一个自定义 TokenIterator 类，按语言服务器的偏移量"指示"移动并实时转换。

集成效果

转换完成后，CodeMirror 能理解 ShopifyQL 并提供语法高亮、自动补全、代码检查和悬停提示。这种分层架构可复用于未来在 CodeMirror 或其他 LSP 兼容编辑器中集成自定义语言。

相关链接：

• Building an agentic harness that outlasts the model
• Upgrading Checkout Blocks app to Polaris web components
• Inside Shopify Hack Days: Building a prototype for music-playing pages
• Clustering billions of products for agentic commerce with Catalog API
• Teaching Sidekick to say no: automated data curation with LLM judge consensus
• Quick: An internal hosting platform for the AI era
• Under the River
• We replaced Redis with MySQL for inventory reservations—and it scaled
• Introducing Ruvy
• Building a ShopifyQL Code Editor