Momentic Mo 发布：AI QA 代理在您的应用中查找错误（QA Bench 对比 Codex、Claude Code、Devin）
Momentic 的 Mo 已退出测试阶段，现作为代理式 QA 工程师全面可用，它能够端到端驱动真实应用、查找错误并提交发现的问题。此次发布意义重大，因为它将验证推入编码代理已经存在的同一循环中：Mo 可从编码代理会话、PR 评论、Momentic 应用或 qa CLI 运行，并且在 Mo 报告每个功能错误之前，会有一个单独的代理尝试复现该错误。发布 HN 线程（155 分，105 条评论）混合了具体的基准测试好奇心和关于每错误成本、UI 之下的可观测性、供应商锁定以及嘈杂的入门体验的尖锐怀疑。
Mo 是什么及其适用位置
Mo 是一个基于 Momentic 三年工作和来自真实应用的数百万测试轨迹构建的自定义代理框架，定位为验证而非测试编写。Momentic 网站将问题框架为：“编码代理已使构建软件的速度大幅提升。瓶颈现在在于确认其是否正常工作。” Mo 被定位为属于代理循环内部，编写变更的编码代理可以使用 MCP 编写测试、在实时会话中检查测试，并将 YAML 与代码一起提交。
发布时发布的站点累计数据：
- 创建的测试：77,813
- 执行的测试运行：70,607,819
- 已验证的变更：339,166
- 已验证的 PR：80,290
- 自动修复：8,932,104
- 捕获的错误：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 编写，并版本化存储在仓库中。分流循环将失败分类为应用错误、不稳定或环境问题，AI 分流提出修复建议以供审查。
QA Bench 结果：Mo 对比 Codex、Claude Code 和 Devin
QA Bench 对 Mo、Codex、Claude Code 和 Devin 在 Gitea、Metabase、Twenty 和 Saleor 的 20 个领域进行了评分，每个领域给予 60 分钟。Momentic 报告称，Mo 发现了约 269 个标记的错误，而次优代理发现了约 86 个。
Momentic 自己的发布框架添加了两个主导线程的诚实警告。精确度：Mo 为 84%，而 Codex 为 86%。成本：“Mo 每个错误成本为 2.67 美元，而 Codex 为 0.80 美元，低于 Claude Code 和 Devin。” 评论者 @podoman 带着明显的困惑读回了这一点：
这好吗？所以 Mo 每个错误花费更多钱？我很困惑。
同样的权衡由 @staindk 提出，他问道，这种框架是否实际上在说 Codex 既更好又更便宜。Momentic 自己的立场是召回优先：接受较低的精确度和较高的每错误成本，以换取捕获其他代理遗漏的错误。
框架如何探索：DAG 探索和召回
Momentic 将 Mo 描述为基于 DAG 的探索图，评论者将其视为实质性的技术主张。@2001zhaozhao 认为那里有真实的东西，因为 DAG 系统地增加了探索表面积，并指出在个人经验中，编码代理中的 Playwright 风格 QA 步骤能可靠地捕获某些错误类别，但会让边缘情况溜走。同一位评论者提供了关键细微差别：
我认为这种 DAG 方法仅对代码库范围的错误扫描有用？如果实际上将其集成到逐功能代理循环中，那么每次变更后的 QA 已经很窄（因为它只需要测试 1 个变更的功能），所以这种探索彻底性优化（用作者自己的话说“召回”）就不那么重要了。
@karinago 提出了相应的盲点担忧：如果销售宣传是 LLM 不擅长测试，因为它们强化自己的假设，而 Mo 基于来自 Momentic 自身产品的数百万轨迹构建，那么框架如何避免在框架层面而非模型层面发展盲点？
Momentic 声称 Mo 捕获的示例错误
网站按流程和影响发布了一组匿名错误，全部按检测阶段标记。代表性示例：
- 一个消费金融科技登录路由变更静默跳过了新设备 2FA 提示，在功能分支上检测到。
- 一个拼车应用的实时 ETA 订阅在依赖更新后静默失败，在暂存环境中检测到。
- 一个健康应用的 iOS 生命周期变更在屏幕锁定时重置了活动睡眠定时器，在 CI 中检测到。
- 一个食品配送支付表单重构在结账时停止预填已保存的卡片，在部署前八分钟检测到。
- 一个零售市场在翻到第二页时重置了所有活动类别和价格过滤器，在夜间运行中检测到。
- 一个旅行市场的验证变更在最终结账步骤拒绝了多段促销代码，在合并前检测到。
- 一个流媒体平台的区域检测错误在首次播放时选择了错误的字幕轨道，在发布前检测到。
- 一次一日扫描捕获了 12 个错误，并暴露了本会在未检测情况下发布的遗留 API 问题，在发布前检测到。
这些是产品营销声明，应如此对待；来源未提供复现。
评论者质疑的内容：成本模型、可观测性和锁定
令牌成本和自带订阅问题
最直接的经济反对来自 @aliasxneo，他将按令牌的 SaaS 定价框架为“当前订阅危机的加强版”，并认为默认应该是 BYOA：自带代理。论点是，拥有多个前沿订阅剩余配额的开发人员无法在 Momentic 内花费这些配额，迫使在不可转移的令牌上进行第二次并行支出。@AgentMasterRace 报告称，在短暂使用中，该服务感觉太慢且昂贵，更喜欢带有技能和 maestro 脚本的 Claude。@JulianPaul 直截了当地提出了底层产品问题：为什么 Mo 比在现有订阅上使用自定义 Playwright 框架直接将前沿模型指向应用更好？
代理能看到 UI 之下的内容吗？
@bsp580 提出了线程中最尖锐的技术可观测性问题：当失败不在屏幕上时，代理能看到多少失败表面？
我遇到的很多失败在屏幕上不可见：返回 200 但带有错误主体的请求、重试循环、静默失败的调用。代理是否获得失败流程的网络流量，还是只有截图和视图层次结构？
@moon0917 从 QA Bench 目标之一 Saleor 的具体示例中提出了同样的观点。他们描述了一个价格重新计算任务，该任务本应仅在脏列表上运行，但过滤后的查询集从未分配回变量，因此每次运行都重新计算所有列表。单元测试因无关原因保持绿色，并且由于最终输出仍然有效，无操作留在生产中。他们向 Momentic 提出的问题：Mo 是否捕获这种外部状态看起来正确的静默无操作类别，还是主要挂钩可见状态差异？
确定性、锁定和目标用户
@staindk 对企业采用重要的购买者问题进行了分组：供应商锁定是什么样子，Momentic 代码或测试标准是否足够开放以离开平台或在关闭中生存，测试的确定性如何，以及预期用户是谁，产品所有者、开发人员还是 SDET。
@beavisringdin 添加了三个更多：偏好将开源工具捆绑到自定义框架上，明确询问 YC W24 公司两年做了什么，以及关于支持真实设备上移动开发构建的路线图问题，如果处理真实设备支持，愿意为产品付费。
重试循环、通过静默和中间地带
@bshafiq 询问框架如何处理代理卡在点击从未加载的元素上，特别是是否有硬最大步数限制或更智能的状态变化检测来终止运行。
@daniiel 认为精确度和召回率不是 QA 代理首先重要的指标，因为最糟糕的结果是在已损坏的流程上静默通过：
静默通过比不稳定测试更糟糕，因为不稳定的至少会发出一些噪音。
该评论者描述了运行突变测试风格评估，在开源应用中植入错误并计算有多少溜过，并报告说添加第三个可能答案“我无法判断”消除了大多数错误通过，因为引擎停止猜测。对 Momentic 的开放问题：Mo 无法复现的错误是否出现在任何地方或被丢弃，以及 QA Bench 错误是植入的还是仅从现有应用标记的。
从非错误中学习、PR 级范围和护城河
@gophigure 询问将发现标记为“不是错误”是否会在下次运行中教给 Mo 什么，或者相同的发现是否会再次出现。@throwaway7783 描述在之前的雇主处给 Codex 和 Claude Code 源代码访问权限以及浏览器和 Playwright 控制，并报告它们发现了错误并将其关联到相关 UI 和后端代码，这表明存在一个带有源代码访问权限的基准变体。@bortimus 提出了线程中最简单的问题：护城河是什么？@maxdo 反驳了基准测试框架本身，认为将裸找错误代理与具有产品知识的真实工程框架进行比较不是苹果对苹果。
早期用户报告的入门和 UX 摩擦
并非每条评论都关于架构。@ecares 报告说，注册 Mo 后，实际上没有入门，流程在配置身份验证时停滞，没有清晰的页面路径。@ice_cream_man_9 在个人网站的一个页面上运行了 Mo，并列出了四个 UI 问题：状态指示器说“尚无错误”，而选项卡报告“错误：11”，然后说 Mo 未找到错误，而选项卡显示 12；所有错误都标记为“中等”，没有严重性评分标准的解释，也没有重新优先排序的方法；停止测试按钮仅在运行结束时出现，而不是在整个过程中可用；并且没有发现错误列表的导出功能。@vfosnar 标记了一个隐私问题，说 Momentic 似乎在登录时将他们的电子邮件交给 Slack 以进行联系，而没有事先通知，而他们的产品内 Slack 通知设置已关闭。
如何解读发布
Momentic 的核心赌注是，测试瓶颈已从编写测试转移到知道编码代理的变更是否真正有效，并且基于真实应用轨迹构建的专用框架将比通用编码代理具有更好的召回率。发布的 QA Bench 数字在有限数据集上支持该召回声明，但它们也承认 Codex 稍微更精确且每个错误便宜得多。线程中最强的未解决问题是 Mo 是否能看到从未在视图层次结构中出现的静默失败，其定价模型是否能在自带代理工作流的兴起中生存，以及如果供应商关系结束，团队能否提取其 YAML 测试。这些是买家在替换手工构建的 Playwright 框架之前应坚持的问题。