Momentic Mo 发布：AI QA 代理在您的应用中查找 Bug（QA Bench 对比 Codex、Claude Code、Devin）

Momentic 的 Mo 已退出测试阶段，现作为代理式 QA 工程师全面可用，可端到端驱动真实应用、查找 Bug 并提交发现的问题。此次发布意义重大，因为它将验证推入编码代理已存在的同一循环中：Mo 可从编码代理会话、PR 评论、Momentic 应用或 qa CLI 运行，并且另一个代理会在 Mo 报告每个功能性 Bug 之前尝试复现它。发布 HN 线程（155 分，105 条评论）既包含对具体基准测试的好奇，也包含对每个 Bug 成本、UI 之下的可观测性、供应商锁定以及嘈杂的上手体验的尖锐质疑。

Mo 是什么及其定位

Mo 是一个基于 Momentic 三年工作和来自真实应用的数百万测试轨迹构建的自定义代理框架，定位为验证而非测试编写。Momentic 网站将问题描述为：“编码代理已大幅加快了软件构建速度。瓶颈现在在于确认其是否正常工作。”Mo 被定位为属于代理循环内部，编写变更的编码代理可以使用 MCP 编写测试、在实时会话中检查测试，并将 YAML 与代码一起提交。

发布时发布的站点累计数据：

  • 创建的测试：77,813
  • 执行的测试运行：70,607,819
  • 已验证的变更：339,166
  • 已验证的 PR：80,290
  • 自动修复：8,932,104
  • 捕获的 Bug：117,010

已具名客户包括 Notion、Quora、Webflow、Framer、Xero、Whatnot、Retool、Runway、Bilt、Collectors、Podium、SPS Commerce、GPTZero、Vapi、Mutiny、Squire、Arena 和 Kumo。

五部分工作流程

Momentic 将产品描述为五个循环：一个知识库，记录术语、业务规则和预期行为，供代理在每个 AI 步骤查阅；运行时恢复，在 UI 中途变化时重新查找控件；永久修复，提出测试文件差异供审查；MCP 集成，使编码代理能够编写和检查测试；步骤级失败证据，包含截图和轨迹；以及一个 CLI，其退出代码可在合并或部署前作为必需条件。

测试以纯英文 YAML 编写，并在仓库中进行版本控制。分类循环将失败分类为应用 Bug、不稳定或环境问题，AI 分类提出修复建议供审查。

QA Bench 结果：Mo 对比 Codex、Claude Code 和 Devin

QA Bench 对 Mo、Codex、Claude Code 和 Devin 在 Gitea、Metabase、Twenty 和 Saleor 的 20 个领域进行了评分，每个领域给予 60 分钟。Momentic 报告称，Mo 发现了约 269 个标记的 Bug，而次优代理发现了约 86 个。

Momentic 自己的发布框架添加了两个主导线程的诚实注意事项。精确度：Mo 为 84%，而 Codex 为 86%。成本：“Mo 每个 Bug 花费 2.67 美元，而 Codex 为 0.80 美元，低于 Claude Code 和 Devin。”评论者 @podoman 带着明显的困惑读回了这一点：

这好吗？所以 Mo 每个 Bug 花费更多？我很困惑。

@staindk 也提出了同样的权衡，询问这种框架是否实际上表明 Codex 既更好又更便宜。Momentic 自己的立场是召回优先：接受较低的精确度和较高的每个 Bug 成本，以换取捕获其他代理遗漏的 Bug。

框架如何探索：DAG 探索和召回

Momentic 将 Mo 描述为基于 DAG 的探索图，评论者将其视为实质性的技术主张。@2001zhaozhao 认为这确实有实质内容，因为 DAG 系统地增加了探索表面积，并指出根据个人经验，编码代理中的 Playwright 风格 QA 步骤能可靠地捕获某些 Bug 类别，但会遗漏边缘情况。同一位评论者提出了关键细微差别：

我认为这种 DAG 方法只对代码库范围的 Bug 扫描有用？如果将其集成到逐个功能的代理循环中，那么每个变更后的 QA 已经很窄（因为它只需要测试 1 个变更的功能），因此这种探索彻底性优化（用作者自己的话说“召回”）就不那么重要了。

@karinago 提出了相应的盲点担忧：如果销售宣传是 LLM 不擅长测试，因为它们强化了自己的假设，而 Mo 基于来自 Momentic 自身产品的数百万条轨迹，那么该框架如何避免在框架层面而非模型层面产生盲点？

Momentic 声称 Mo 捕获的示例 Bug

该网站按流程和影响发布了一组匿名 Bug，全部按检测阶段标记。代表性示例：

  • 一个消费金融科技登录路由变更静默跳过了新设备 2FA 提示，在功能分支上检测到。
  • 一个拼车应用的实时 ETA 订阅在依赖更新后静默失败，在暂存环境中检测到。
  • 一个健康应用的 iOS 生命周期变更在屏幕锁定时重置了活动睡眠计时器，在 CI 中检测到。
  • 一个食品配送支付表单重构在结账时停止预填已保存的卡片，在部署前八分钟检测到。
  • 一个零售市场在翻到第二页时重置了所有活跃类别和价格筛选器，在夜间运行中检测到。
  • 一个旅行市场的验证变更在最终结账步骤拒绝了多段促销代码，在合并前检测到。
  • 一个流媒体平台的区域检测 Bug 在首次播放时选择了错误的字幕轨道，在发布前检测到。
  • 一次为期一天的扫描捕获了 12 个 Bug，并暴露了本会在未检测到的情况下发布的遗留 API 问题，在发布前检测到。

这些是产品营销声明，应如此对待；来源未提供复现。

评论者质疑的内容：成本模型、可观测性和锁定

Token 成本和自带订阅问题

最直接的经济异议来自 @aliasxneo，他将按 token 的 SaaS 定价描述为“当前订阅危机的加强版”，并认为默认应该是 BYOA：自带代理。理由是，开发者在多个前沿订阅中剩余的配额无法在 Momentic 内使用，迫使在不可转移的 token 上进行第二次并行支出。@AgentMasterRace 报告称，在短暂使用中，该服务感觉太慢且太贵，更喜欢带有技能和 maestro 脚本的 Claude。@JulianPaul 直截了当地提出了底层产品问题：为什么 Mo 比将前沿模型直接指向带有自定义 Playwright 框架的应用并使用现有订阅更好？

代理能看到 UI 之下的内容吗？

@bsp580 提出了线程中最尖锐的技术可观测性问题：当失败不在屏幕上时，代理能看到多少失败表面？

我遇到的很多失败在屏幕上不可见：返回 200 但带有错误主体的请求、重试循环、静默失败的调用。代理能获得失败流程的网络流量，还是只有截图和视图层次结构？

@moon0917 从 QA Bench 目标之一 Saleor 的具体示例提出了同样的观点。他们描述了一个价格重新计算任务，该任务本应仅在脏列表上运行，但过滤后的查询集从未重新赋值给变量，因此每次运行都重新计算所有列表。单元测试因无关原因保持绿色，而空操作在生产中持续存在，因为最终输出仍然有效。他们向 Momentic 提出的问题是：Mo 能捕获这种外部状态看起来正确的静默空操作类，还是主要挂钩可见状态差异？

确定性、锁定和目标用户

@staindk 汇总了企业采用的关键购买者问题：供应商锁定是什么样子，Momentic 代码或测试标准是否会足够开放以允许离开平台或在关闭后幸存，测试的确定性如何，以及预期用户是谁——产品负责人、开发人员还是 SDET。

@beavisringdin 又添加了三个：偏好将开源工具与自定义框架结合，明确询问一家 YC W24 公司两年做了什么，以及关于支持真实设备上移动开发构建的路线图问题，并表示如果支持真实设备，愿意付费。

重试循环、通过静默和中间地带

@bshafiq 询问框架如何处理代理卡在点击一个永不加载的元素上，特别是是否有硬性最大步骤限制或更智能的状态变化检测来终止运行。

@daniiel 认为精确度和召回率不是 QA 代理首先重要的指标，因为最糟糕的结果是在已损坏的流程上静默通过：

静默通过比不稳定测试更糟糕，因为不稳定的至少会发出一些噪音。

该评论者描述了运行突变测试风格的评估，在开源应用中植入 Bug 并计算有多少被遗漏，并报告说添加第三个可能答案“我无法判断”消除了大多数错误通过，因为引擎停止了猜测。对 Momentic 的开放问题：Mo 无法复现的 Bug 是否会出现在任何地方或被丢弃，以及 QA Bench 的 Bug 是植入的还是仅从现有应用中标记的。

从非 Bug 中学习、PR 级范围和护城河

@gophigure 询问将发现标记为“不是 Bug”是否会让 Mo 为下次运行学到什么，还是同样的发现会再次出现。@throwaway7783 描述了在之前的雇主处给 Codex 和 Claude Code 源代码访问权限以及浏览器和 Playwright 控制，并报告说它们发现了 Bug 并将其与相关 UI 和后端代码关联起来，这表明存在一个带有源代码访问权限的基准变体。@bortimus 提出了线程中最简单的问题：护城河是什么？@maxdo 反驳了基准测试框架本身，认为将裸的找 Bug 代理与具有产品知识的真实工程框架进行比较不是苹果对苹果。

早期用户报告的上手和 UX 摩擦

并非每条评论都关于架构。@ecares 报告说，注册 Mo 后实际上没有上手引导，流程在配置身份验证时停滞，页面路径不清晰。@ice_cream_man_9 在个人网站的一个页面上运行了 Mo，并列出了四个 UI 问题：状态指示器显示“尚无 Bug”，而选项卡报告“Bug：11”，然后说 Mo 未发现 Bug，而选项卡显示 12；所有 Bug 都标记为“中等”，没有严重性标准解释，也无法重新排序；停止测试按钮只在运行结束时出现，而不是始终可用；没有发现 Bug 列表的导出功能。@vfosnar 标记了一个隐私问题，称 Momentic 似乎在登录时将他们的电子邮件交给 Slack 以进行联系，而没有事先通知，而他们在产品内对 Slack 的通知设置已关闭。

如何解读此次发布

Momentic 的核心赌注是，测试瓶颈已从编写测试转移到确认编码代理的变更是否真正有效，并且基于真实应用轨迹构建的专用框架将比通用编码代理具有更高的召回率。已发布的 QA Bench 数字在有限数据集上支持了这一召回主张，但也承认 Codex 在精确度上略高，且每个 Bug 的成本显著更低。线程中最强的未解决问题是：Mo 是否能看到从未在视图层次结构中出现的静默失败，其定价模型能否在自带代理工作流兴起中幸存，以及如果供应商关系结束，团队能否提取其 YAML 测试。这些是买家在替换手工构建的 Playwright 框架之前应坚持提出的问题。

Sources