Momentic让AI下场抓Bug

Momentic 最近发布了名为 Mo 的应用测试 Agent：开发者不需要先写测试脚本，只要提供应用、测试账号和目标，Mo 就会调度一组 AI Agent，像真实用户一样点击按钮、填写表单、切换页面，并把发现的问题整理成带复现步骤、日志、截图和视频回放的报告。

Mo 是一种自主探索式 QA Agent，即能够理解测试目标、操作真实产品并主动寻找异常的软件测试系统。 Momentic 将它定位为“AI QA 工程师”，试图把发布前由多人集中完成的 Bug Bash，变成一项可以并行、重复执行的云端任务。

Momentic 于 2026 年 9 月 28 日正式推出 Mo，距离今天约一个月。官方披露的测试期数据是：Mo 已执行超过 1100 次 Bug Bash，发现 3500 个经过确认的 Bug；在 Momentic 自己的评测中，它发现的 Bug 数量是“Codex 配合 Playwright MCP”方案的 3.8 倍，每小时发现的 Bug 数量达到 9 倍，单个 Bug 的发现成本约为后者的一半。需要强调的是，这些数字来自 Momentic 自测，目前没有独立第三方复现实验。(ycombinator.com)

它不是帮你写测试，而是直接进去找问题

Mo 最大的变化，是把 AI 从“测试脚本作者”变成了“产品使用者”。 过去两年，AI 测试工具主要解决的是如何更快地生成 Playwright、Cypress 或 Selenium 脚本，例如根据自然语言生成选择器、补充断言，或者在页面元素变化后自动修复定位规则。

这类工具确实降低了测试编写门槛，但没有消除测试用例设计本身的成本。开发团队仍然需要提前知道要测什么、需要覆盖哪些路径，以及什么结果才算异常。换句话说，AI 可以更快地执行一份清单，却不一定能够主动发现清单之外的问题。

Mo 试图跳过“先定义完整测试套件”这一步。 开发者可以给出“测试结账流程”“检查新用户注册”“尝试破坏文件上传功能”这类目标，Agent 会自行拆分任务，探索不同输入、页面状态和操作顺序，再判断产品行为是否合理。

Momentic 给出的一个案例是 GitHub Pull Request 页面：Agent 在没有修改预填搜索条件的情况下直接点击搜索，页面清空了原有查询并提示空查询错误。这个问题不一定会出现在传统 Happy Path 用例中，却很符合真实用户会做出的操作。

这种测试方式更像一群速度极快、耐心近乎无限的体验测试人员。 一个 Agent 可以尝试正常路径，另一个可以输入超长文本，第三个可以反复刷新页面，更多 Agent 则负责切换账户状态、跳过步骤、重复提交或测试边界输入。相比让一个通用浏览器 Agent 顺序探索，Momentic 的核心卖点是把这些路径拆开并行执行。

一次运行会交付什么

Mo 的最终产物不是一句“测试失败”，而是一份可以直接进入修复流程的证据包。 每个问题通常包括：

• Agent 实际测试了什么，以及选择这条路径的原因；
• 问题发生前后的完整操作步骤；
• 浏览器或移动端运行日志；
• 关键页面截图和完整视频回放；
• 可供开发者重复执行的复现步骤；
• 对问题影响范围和可能原因的初步判断。

视频回放是 Mo 比普通 LLM 测试报告更有用的部分。 AI 很容易把预期行为理解错，也可能因为页面加载慢、测试数据异常或第三方服务波动，把偶发问题判断成产品 Bug。如果只有自然语言结论，开发者仍然需要从头验证；如果同时提供操作录像、页面状态和日志，人工确认的成本会低得多。

Momentic 的官方示例仓库还显示，Mo 不只通过网页界面运行，也提供独立的 QA CLI。开发者可以启动测试任务、查询状态、等待执行完成并获取报告，这意味着它能够被放进预发布、夜间测试或持续集成流程，而不只是作为一次性的产品演示工具。(github.com)

Mo 和传统自动化测试并不是替代关系

Mo 更适合发现“团队没有想到要写成用例”的问题，而传统测试更适合稳定验证确定性规则。 两者解决的是不同层次的质量问题。

| 方案 | 测试如何产生 | 主要优势 | 主要限制 | 更适合的场景 | |---|---|---|---|---| | Momentic Mo | Agent 根据目标自主探索应用 | 不需要预先维护完整脚本，可并行寻找边缘问题，报告包含视频和复现步骤 | 行为存在非确定性，成本和覆盖范围不容易提前估算 | 发布前 Bug Bash、新功能探索、快速变化的产品 | | Momentic 常规测试 | 用自然语言和 YAML 描述用户意图 | 测试可版本管理，支持 CI、自愈和失败分类 | 仍然需要团队定义关键流程和断言 | 核心业务回归、跨 Web 与移动端流程 | | Playwright/Cypress | 工程师编写确定性代码和选择器 | 可控、可调试、运行结果稳定，适合复杂断言 | 编写和维护成本较高，选择器容易随 UI 变化失效 | 支付、权限、数据一致性等关键回归测试 | | 通用编码 Agent + 浏览器工具 | 编码 Agent 临时生成并执行操作 | 灵活，容易接入现有开发工作流 | 缺少专门的测试调度、证据管理和质量知识库 | 临时验证、小规模开发自测 |

如果一个团队因此删除全部 Playwright 用例，风险反而会变大。 支付金额、权限隔离、状态机、财务计算和数据写入等测试，需要精确、可重复的输入输出关系；让模型每次重新理解页面，通常不如一条确定性断言可靠。

Mo 更合理的位置，是放在现有测试金字塔的上方。单元测试验证函数和模块，集成测试验证服务之间的接口，传统 E2E 测试守住核心路径，Mo 则负责在这些固定路线之外“到处走走”，寻找产品团队没有预见的组合问题。

Momentic 真正押注的是产品知识库

自主测试 Agent 的上限，不取决于它能不能点击按钮，而取决于它是否知道产品应该怎样工作。 一个 Agent 看到“提交成功”提示，并不能自动判断订单金额是否正确；看到一个按钮被禁用，也不知道这是权限设计还是前端故障。

Momentic 因此把产品知识库作为整个平台的共享上下文。系统可以读取产品文档、用户流程、代码库，以及 Jira、Linear、GitHub、Figma 等内部信息，让不同 Agent 理解团队术语、功能规则和近期变更。Momentic 此前发布的 Explore Agent、故障分类 Agent 和测试修复能力，也建立在这套上下文之上。(momentic.reportablenews.com)

这套设计实际上是在为 AI 建立一份“产品应该如何运行”的动态说明书。 测试 Agent 负责把说明书和真实产品进行对照：代码变更后出现的新页面是否符合需求，某个失败是预期改版、测试过期，还是用户真正会遇到的回归问题。

Momentic 官方披露的平台累计数据包括超过 7060 万次测试运行、约 893 万次自动修复、超过 8 万个被验证的 Pull Request，并宣称已经捕获超过 11.7 万个 Bug。这些数字说明 Momentic 并非只在做一次性的 Agent 演示，而是在把自然语言测试、自愈、故障分类、CI 和探索式测试整合为同一个质量平台。(momentic.ai)

最难的问题不是操作，而是判断

Mo 面临的第一项挑战，是如何区分真正的 Bug、体验瑕疵和 Agent 自己的误解。 如果需求文档没有说明某个按钮为什么需要禁用，Agent 可能将合理限制报告为故障；如果测试环境中的邮件、支付或地图服务不稳定，它也可能产生大量无法复现的噪声。

Momentic 宣称平台的信噪比达到 96%，但企业最终需要关注的不是官网上的单一百分比，而是不同业务类型下的误报率。内容工具、后台管理系统和电商网站的容错空间不同，金融、医疗或权限系统更不能只依赖模型的语义判断。

Mo 面临的第二项挑战，是测试环境的权限和数据安全。 一个能够自由点击、提交表单和调用真实业务流程的 Agent，必须被严格限制在隔离环境中。测试账号可以访问哪些数据、是否允许发送邮件、能否创建订单、会不会误触真实支付，都需要企业提前设置边界。

Mo 面临的第三项挑战，是成本是否能够随测试规模线性增长。 数百个 Agent 并行探索听起来很有冲击力，但浏览器实例、移动模拟器、视觉模型推理和日志存储都需要成本。Momentic 在发布时为新用户提供了 250 美元试用额度，但没有公开足够清晰的 Mo 单次任务定价，企业很难仅凭公开信息计算一次完整发布检查的长期费用。(ycombinator.com)

Reddit 的 QA 社区中也已经出现不同反馈：有人认为自然语言测试可以降低初期门槛，也有人最终选择 Playwright 配合编码助手，理由是传统脚本更加透明、可控。讨论样本还很少，却指出了 AI 测试工具必须回答的问题：团队是否真正拥有测试资产，以及当 Agent 判断错误时，工程师能否快速接管。(reddit.com)

AI 写代码越快，验证层就越值钱

Momentic 选择现在推出 Mo，是因为 AI 编程正在把软件交付的瓶颈从“写代码”推向“验证代码”。 当 Cursor、Claude Code、Codex 或 Devin 可以在几分钟内生成一个功能时，开发团队节省的编码时间，可能很快被代码审查、回归测试和线上排错重新吃掉。

传统 QA 流程很难按同样速度扩张。一个团队可以同时运行多个编码 Agent，却不可能为每个 Agent 配备一名人工测试人员；固定的 E2E 测试套件也只能发现已经被预先定义的问题，无法覆盖 AI 生成代码带来的大量新组合。

Mo 的价值不在于彻底消灭测试脚本，而在于补上一层能够主动寻找未知问题的验证机制。 如果 Momentic 能够把误报控制在可接受范围内，并让企业持续积累自己的产品知识、测试证据和失败分类数据，它可能成为编码 Agent 之后的第二道自动化防线。

这也是 Momentic 与普通浏览器 Agent 的根本区别。浏览器 Agent 的目标通常是把任务做完，测试 Agent 的目标则是故意让任务失败，并证明失败不是自己的错。

我们的判断

Mo 是目前 AI QA 产品中方向更激进、也更符合 Agent 时代需求的一种形态。 它没有继续宣传“用自然语言写脚本更快”，而是直接挑战测试用例设计、执行、取证和初步分类这一整段工作流。

它最有价值的场景，是缺少专职 QA、发布频率高、界面变化快的开发团队。对这类团队来说，Mo 可以在每次发布前完成一次原本没人有时间做的探索式测试，并把结果交给开发者或编码 Agent 继续处理。

它暂时不适合独立承担关键系统的质量门禁。确定性回归测试、代码审查、权限测试和人工产品判断仍然不可替代，尤其是在高风险业务中。更现实的组合是：让传统测试守住已知规则，让 Mo 去寻找未知错误，再由人决定哪些发现值得阻止发布。

AI 编程工具解决的是“软件能不能更快写出来”，Mo 想解决的是“这些软件到底敢不敢上线”。 如果前者继续快速普及，后者很可能成为开发工具市场接下来最拥挤、也最有商业价值的战场。

参考来源

• Momentic 官方 GitHub 组织：包含 Mo QA CLI、Web 与移动端测试工具及 Agent Skills 等官方项目。
• Momentic CLI：官方自然语言端到端测试 CLI，可用于创建、运行和维护测试。
• Momentic Examples：官方示例仓库，展示 Mo 会话、Web、Android、iOS 和 CI 工作流。
• Reddit QA 社区关于 Momentic 的讨论：从实际选型角度讨论 Momentic 与 Playwright 等方案的取舍。