作者 | Steef-Jan Wiggers
译者 | 张卫滨
Expedia Group开源了 mockql-rs，这是一个 Rust CLI 工具，可以在请求时从 LLM 生成 GraphQL 的模拟响应。这是过去六个月内第三次公开尝试解决这一问题，前两次分别是 Airbnb 在 4 月推出的 @generateMock 指令和 2 月份开放的 GraphQL 基金会 RFC。这三种方案采用了显著不同的设计，其中两种使用相同的指令名称但含义并不相同。
它们的共同前提是 GraphQL 选择集（GraphQL selection set）已经是一个规范。Expedia Group 的软件工程师 Samuel Vazquez 指出了这种方法的吸引力，它颠覆了生成工具的常见失败模式，即模型不擅长创造形状，但擅长填充形状，而 schema 为它们免费提供了一个界限明确的形状。换句话说，就是开发者不再需要手工输入一个两百行的 JSON 固件文件，如果第二天早上 schema 发生了变更，该文件就会失效。
mockql-rs 作为独立进程位于客户端和服务器之间。开发者使用 @mock 注解标注字段以及可选的提示，该工具使用 apollo-compiler 解析并验证针对 schema 的操作，将被注解标注的字段与真实字段分离，将真实字段转发到上游，使用该操作和子集 schema 提示模型，然后将两者合并为一个响应。实际的结果是单个响应可以同时包含来自真实后端的数据和来自尚未实现的字段解析器的生成数据。Expedia 选择 CLI 的理由是任何测试运行器、CI 任务或构建脚本都可以执行进程，避免了 SDK 或客户端库依赖。
查询仅注解标注尚未准备好的字段：
}响应结合两个来源，其中 property 由上游解析，recommendations 在该上下文中生成：
}（代码示例来自 Expedia Group 的技术 博客文章，并进行了删减。）
酒店名称和地址来自后端；餐厅名称、描述和距离是模型输出。两者在同一个有效负载中都具有相等的权威性，响应中没有任何内容标识它们的差异。
Airbnb 的方法在 4 月发布，改为在构建时运行。它的 @generateMock 指令在 Niobe 代码生成期间进行处理，同时发出模拟数据的 JSON 文件和类型化的访问函数供演示应用、快照测试和单元测试使用，生成器在后续运行中有意保留了工程师的手动编辑能力。
RFC 采取了第三种立场。它在操作而不是字段上定义 @mock，使用名称参数在命名响应之间进行选择，并要求符合规范的客户端返回模拟数据而无需发出任何网络请求。模拟响应位于与源文件相邻的graphql_mocks目录中，以操作来进行命名，带有保留的default键和在重新生成时使用的可选描述。LLM 生成仅作为推荐策略出现，而不是作为一种机制。
这种差异不仅仅是语法上的差异。RFC 要求客户端检测模拟响应何时对其操作的有效性已经产生了漂移，并强制进行纠正措施，并声明模拟必须作为应用程序测试套件的一部分进行验证。Expedia 的生成数据在每次运行时生成，这提供了上下文一致性但不能提供快照测试所依赖的可重复性。两篇文章都没有解决非确定性装置（fixtures）对 CI 意味着什么的问题。
RFC 还直接预料到了智能体工作流的场景，建议实现者提供一个 Agent Skill，以便编码智能体可以对话式地添加或修改模拟变体，文档中包含建议的 SKILL.md。这样就能将模拟管理置于智能体被教授操作的其他代码库约定旁边。
对于要权衡采用的团队，需要注意这些标准目前所处的位置。RFC 仍处于第 0 阶段，被描述为初步草案（strawman），没有列出倡导者，这是 GraphQL 规范过程中最早的阶段，不能保证它的进展。Expedia 的实现已经在指令放置、参数名称和网络行为上与其产生了差异。所以，如果今天有团队把 @mock 作为标准来推行，实际上只是把某一家供应商对这个名称的理解当成了标准，只不过这个名称在规范草案中也有提及。
更值得关注的是，这种模式为何在 GraphQL 而不是 REST 中出现。与 Schema 形状一致的输出，是让生成的数据变得真正可用、而不只是“看起来像那么回事的乱码”的关键约束。同时，也正是基于此，工具才能够检测生成的数据何时不再匹配查询。至于它最终是会成为一个正式的规范，还是沦为三个互不兼容的实现，目前还是个未知数
查看英文原文：
LLM-Generated GraphQL Mocks Arrive at Airbnb and Expedia, While the Spec Lags Behind
会议推荐
柯南 AI 的实践仍在持续迭代。王泽锋将在 QCon 全球软件开发大会（上海站）2026 带来新演讲——《AI 时代的移动端稳定性保障——柯南 AI Agent 实践》。这次分享将重点介绍近几个月的新进展，得益于模型能力升级、产品方案迭代，柯南 AI Agent 的覆盖率和采纳率数据还在持续提升。届时，他将进一步讲解柯南 AI 如何从问题定位走向自动修复、治理闭环与知识沉淀，并结合鸿蒙原生、KMP 等新技术栈，分享 Agent 在 OOM、Freeze、Heap Snapshot 分析，以及跨语言循环引用、跨运行时死锁等复杂问题中的应用。如果你希望深入了解 Agent Workflow、Context Engineering、Agent Harness 和 Agent 友好型工程基建如何在真实业务中落地，可以关注本次分享。
今日荐文
你也「在看」吗？
热门跟贴