别让 AI 替你测试一切（把模糊交给 agent，把确定留给断言）
开源测试工具 e2e：把模糊的路径交给 agent，把确定的结果留给断言；通过后缓存 trace，界面稳定时重放不再花 token。
大多数团队对 AI 测试只有两种态度。
一种是：AI 不靠谱，测试里不许出现模型。
另一种是：让 agent 自己点一遍，它说过了就算过。
两种都是错的。
第一种把你困在脆弱的脚本里。
第二种把你的发布流程交给了一个你没法复现的判断。
真正该问的不是「要不要用 AI 测试」。
而是：哪一步该交给 AI，哪一步绝对不能。
2026 年 10 月 8 日，TesterArmy 的 CTO 发文，开源了一个叫 e2e 的测试框架。
Apache 2.0 协议，npm 包名就叫 e2e，一行 npx e2e init 起步。
它仍是 pre-1.0。
这一点先记住，后面会再说。
它有意思的地方不在「用了 AI」。
现在什么工具都「用了 AI」。
有意思的地方在于：它允许你在同一条测试里，把 agent 步骤和精确断言写在一起。
换句话说，它逼你画一条线。
默认陷阱：你在用一种工具解决两类问题
先看看端到端测试今天大概长什么样。
你写一串选择器。
点这个按钮。
填那个输入框。
等这个元素出现。
断言那段文字。
然后某天，设计师把按钮从左边挪到右边，改了个类名。
二十条测试一起变红。
没有一条是真正的 bug。
你花一个下午修脚本，修完了，什么都没变好。
这不是测试。
这是在维护一份界面快照的副本。
于是很多人转向另一头：让 agent 看着屏幕，用自然语言告诉它「去完成下单」，最后问它「成功了吗」。
脆弱感消失了。
但另一个东西也消失了：确定性。
模型今天说「成功」，明天可能说「看起来成功」。
每跑一次都要花 token。
CI 里跑一百次，就是一百次账单，外加一百次你无法逐字复现的判断。
两条路的共同问题是同一个：
你把两类本质不同的问题，塞进了同一种工具里。
- 「怎么走到那一步」是模糊的，界面会变，路径不唯一
- 「那一步的结果对不对」是精确的，金额就是金额，状态就是状态
拿精确的工具去处理模糊的问题，你得到脆弱。
拿模糊的工具去处理精确的问题，你得到不可信。
这就是测试里的 psychic entropy：注意力被反复拉去救火，却没有一次花在真正该判断的地方。
第一性原理：测试的价值是「可重复的判断」
我们先把测试拆到最底层。
一条测试的价值，不在于它跑了多少步。
在于它给出的结论能不能被重复、被信任。
传统脚本的问题，是把「重复」做到了极致，却把「适应」做到了零。
纯 agent 测试的问题，正好相反。
所以答案从来不是二选一。
是分层。
不确定性不可怕，可怕的是你不知道它藏在哪一层。
e2e 的设计，基本就是这条原则的工程化。
素材里给出的 API 很短：
agent.act：让 agent 去做一件事，比如走完一段流程agent.assert：让 agent 用判断去验证一个不好写死的条件agent.extract：让 agent 从界面里把信息取出来- 再加上 Playwright 风格的 locator，用来做你熟悉的精确定位和断言
这四样东西可以在同一条测试里混用。
这意味着什么。
意味着你不需要在「全手写」和「全托管」之间站队。
你可以一行一行地决定：这里我信任模型，这里我只信任代码。
这条边界就是你的 point of view。
它不是工具给你的。
是你写进测试里的。
反转：AI 的成本应该只花在「第一次」
这是我觉得最被低估的一点。
按素材的描述，e2e 在测试通过之后会缓存 trace。
下次再跑，只要 UI 没有大改，它就直接重放，不再调用模型。
首次运行花 token。
之后在界面稳定的前提下，重放是零 token。
把这件事想清楚，你对「AI 测试很贵」的判断会被整个翻过来。
大多数人默认 AI 是一种持续的税：每跑一次，交一次。
这里的模型更像一次性的探路成本。
agent 第一次替你把路走通。
走通之后，这条路被记下来。
之后你跑的，是一条确定的路径。
（如果 UI 发生了大改，会怎样处理，请以官方文档为准。素材只承诺了「没大改就重放」这一半。）
翻译成人话：
模型负责探索。
缓存负责重复。
断言负责裁决。
这三件事各守一层，谁也不越界。
这不是「AI 取代测试工程师」的故事。
这是一个把昂贵的判断压缩成一次、把廉价的重复交还给机器的故事。
doer 会想：AI 能不能帮我多写几条测试。
director 会想：哪些判断值得花一次 token，哪些判断永远不该交给模型。
可执行模块：怎么在自己的项目里画这条线
下面是我会怎么用它。
先说清楚：以下是思路和示意，不是完整教程，具体写法以仓库文档为准。
1) 先把每条测试拆成「路径」和「裁决」
动手写之前，先在纸上把一条关键流程拆开。
每一步只问一个问题：这一步的正确答案是唯一的吗。
- 是唯一的：用 locator 做精确断言
- 不唯一，但能描述：交给
agent.act或agent.assert - 需要从页面拿数据给后面用：交给
agent.extract
一条示意结构大概是这样（只是结构，不是可运行代码）：
测试：完成一次结账（示意）
1. agent.act → 用自然语言描述：加入一件商品并进入结账页
2. agent.extract → 从页面取出显示的订单信息
3. locator 断言 → 关键字段必须与预期完全一致
4. agent.assert → 描述性检查：页面是否清楚地告诉用户下单成功
注意第 3 步。
钱、状态、权限这类东西，别交给模型的「感觉」。
2) 把 token 当成探路费，而不是运营费
首次运行花 token 是正常的。
这是 agent 在替你摸清界面。
真正要盯的是：之后的运行有没有稳定地走缓存。
如果一条测试每次都在重新调模型，那它在提醒你一件事：要么界面在频繁大改，要么这条测试本身边界没画清。
成本异常，往往是设计异常。
3) 一套 API 覆盖三个端，别再维护三套脑子
按素材描述，浏览器端走 Playwright，移动端走 agent-device。
Web、iOS、Android 用的是同一套 API。
对小团队、对一人公司来说，这件事的意义比看上去大。
三个端，过去往往意味着三套工具、三种写法、三份心智负担。
现在你可以用同一种思维方式写三端的测试。
你省下的不是代码行数。
是切换上下文时流失的注意力。
4) 用你已经付过钱的模型
e2e 可以接 AI SDK，可以接本地模型，也可以用你已有的 ChatGPT、Copilot、SuperGrok 订阅。
素材里说得很明确：不加价。
这背后的逻辑很朴素。
测试框架不应该变成另一个按调用抽成的中间商。
模型是你的。
边界是你的。
框架只负责把两者接起来。
如果你在意数据不出本机，本地模型这条路也是开着的。
5) 让写代码的 agent 自己补测试
e2e 提供了 agent skill 和 MCP，面向 Claude Code、Cursor、Codex 这类 coding agent。
这意味着测试可以进入同一个循环：agent 写完功能，顺手用同一套框架补上测试、跑一遍。
但这里有一个陷阱。
如果你让 agent 既写功能，又写全部断言，又判断自己过没过，你等于让考生自己出题、自己阅卷。
所以规则可以很硬：
- agent 可以写
act、extract这类「走路」的部分 - 关键业务结果的精确断言，由人来定、由人来审
- 合并之前，人只看一件事：边界画在哪里
AI 负责铺开可能性。
你负责定义什么叫「对」。
这就是 taste 在工程里的样子。
6) 诚实对待 pre-1.0
最后，也是最容易被跳过的一条。
e2e 仍是 pre-1.0。
这不是缺点，是事实。
它意味着 API 可能还会变，行为细节可能还会调整。
合理的用法是：
- 先在一两条最痛的流程上试，而不是一次性迁移整个测试套件
- 把它和现有测试并行跑一段时间，看缓存命中和失败模式是否符合预期
- 锁定版本，升级前读变更说明
主权感来自匹配，不来自迷信。
新工具最危险的用法，是把它当成已经被验证过的基础设施。
冷静收尾
e2e 没有回答「AI 能不能测试软件」这个问题。
这个问题本身就问错了。
它回答的是另一个更有用的问题：
在一条测试里，模糊和确定应该如何共处。
模糊的部分，交给 agent，花一次 token，然后缓存下来。
确定的部分，交给断言，一个字符都不让步。
你可以继续在脆弱的脚本里修选择器。
你也可以把整条流程交给模型，然后祈祷它每次说的都一样。
或者，你可以坐下来，一行一行地决定：
哪里需要判断。
哪里只需要事实。
工具会继续迭代。
版本号会走到 1.0。
不变的是这个问题：
当 AI 能替你走完任何一条路时，你是否还清楚，哪一个结果必须由你亲手定义为「对」。
来源：dev.to：Introducing e2e: open-source agentic testing for web, iOS and Android（2026-10-08）；GitHub：tester-army/e2e；tester.army/e2e。文中代码块为结构示意，不代表真实函数签名。