工具越来越能干，接入越来越快，业务一边催上线，一边又开始担心另一件事： 这个 Agent 到底会不会越权？ 分数看起来很好，结果到底靠不靠谱？ 流程是跑通了，但中途断掉、重试、恢复之后，状态还是不是同一个状态？
这不是焦虑变多了。 是测试对象真的变了。
Anthropic 发布 Claude Opus 4.7 时，把安全行为、诚实性和对恶意 prompt injection 的抵抗能力明确写进了版本说明；OpenAI 更新 Agents SDK 时，把 native sandbox execution 和 model-native harness 放到了核心位置；伯克利 RDI 则公开展示，多个常用 AI benchmark 可以在不真正完成任务的情况下拿到高分；浏览器侧又开始出现 self-healing browser harness 这类更强调运行时自修复的工具。现在很多团队面对的，已经不是一个“会回答问题的模型”，而是一个会读文件、跑命令、接浏览器、写产物、带状态恢复、带权限边界的执行系统。
很多岗位变化，表面上看是 AI 能力升级。 落到测试现场，实际发生的是另一件事：过去那套只盯输出、只盯流程、只盯结果对错的方法，开始越来越不够用了。
一、先出问题的不是功能点，而是边界和可信度
最近不少团队遇到的问题，并不是“功能做不出来”。
而是做出来之后，开始发现新的不确定性正在往前顶。
Claude Opus 4.7 的官方说明里，重点不只是模型能力本身，还专门列出了 honesty、deception、misuse cooperation 和对 malicious prompt injection 的抵抗能力等安全维度，并明确说明 4.7 在部分指标上比 4.6 更强。这个信号很清楚：前沿模型的发布，已经不再只是能力发布，也是在同步发布行为边界。([Anthropic][1])
OpenAI 对 Agents SDK 的更新也很说明问题。官方把 agent 放进 controlled workspace，把执行层做进 sandbox，把 harness 作为编排层独立出来，目标不是“再多一个接口”，而是让 agent 能在文件、工具、命令和长链路任务中安全地工作。这个变化一旦落到业务里，测试就不可能只盯接口返回和文本输出。 ([OpenAI][2])
而伯克利 RDI 这次把另一层问题捅得更透。他们审计了 13 个常用 benchmark，结论是全部存在 critical risk；更进一步，他们展示了 agent 如何直接利用评测逻辑漏洞，在多个 benchmark 里跑出高分。这里最危险的，不是某个模型偶尔答错，而是评测系统本身也可能在误导人。([加州大学伯克利分校RDI][3])
能力越强，先暴露问题的，往往不是功能，而是边界、环境和评测。
这句话放在现在的测试现场里，几乎已经成了事实。
二、真正变厚的不是模型参数，而是系统外沿
很多人还在用一个旧前提理解 AI 产品： 它只是一个更复杂一点的接口。
这个前提现在越来越站不住。
今天的 Agent，已经不只是“给我一个问题，我给你一个答案”。 它可能要先读资料，再拆任务，再进工作区，再装依赖，再执行命令，再开浏览器，再写文件，再产出报告，必要时还要停下来等人工审核，审核通过后继续往下跑。OpenAI 这次更新 Agents SDK，强调的正是这种长链路、受控执行和安全运行，而不是单轮调用。
browser-use 的公开仓库对这种趋势写得也很直接。无论是 browser-use 主仓库，还是 browser-harness 子项目，都把“self-healing browser harness”当成核心定位。这里真正重要的，不是“浏览器也能被模型控制”，而是执行过程本身开始具备运行时修复和能力补齐的属性。
也就是说，系统真正变复杂的地方，不只是模型内部。 更大的变化发生在模型之外：
- 它接了什么环境
- 它拥有什么权限
- 它在失败后如何恢复
- 它的行为如何被审计
- 它的分数是否可信
这些东西一旦加进来，测试对象就不再只是“结果”，而是一整条执行链。
过去很多团队测的是 C。 现在真正容易出问题的，越来越多出在 B、D、E、F、G、H 这些位置。
三、安全、评测、运行时，正在变成 AI 测试的三条主线
1. 安全规则开始前移
Claude 4.7 最值得测试人注意的，不是它又刷新了哪个榜单，而是官方公开把安全行为当成版本变化的一部分来讲。Anthropic 明确说，Opus 4.7 在 honesty 和抵抗 malicious prompt injection 上优于 4.6，同时也承认并不是所有安全维度都同步增强。这个表述本身就很工程化。它说明模型不是“整体更强”这么简单，而是在不同能力和不同风险面上做权衡。
对测试来说，这意味着以后不能只问它会不会做事。 还得问它在什么时候必须不能做事。
会做，是功能问题。 该停住，是边界问题。 后者的难度，明显更高。
2. 评测可信度开始独立成题
伯克利 RDI 这次最有价值的，不是又曝出几个 benchmark 有漏洞。 而是它把行业里一个长期存在但经常被跳过的问题，正式推到了台前：评测器本身，也应该被当成被测对象。
如果 benchmark 共享环境、验证逻辑有缺口、judge 能被注入、ground truth 泄露，那最后看到的高分，很可能不是能力结果，而是利用结果。 这件事一旦进入模型选型、平台采购、对外宣传，后果比普通线上 bug 更重。
AI 测试里最危险的幻觉，不是模型幻觉，而是“评测可信”的幻觉。
很多团队现在已经开始做 AI 评测了。 但后面谁会吃亏，往往不是谁测得少，而是谁把评测器当成理所当然。
3. 运行时开始独立成层
OpenAI 这次对 Agents SDK 的描述里，有一个非常关键的信号：orchestration 和 execution 被明确拆开了。sandbox 负责受控执行，harness 负责模型与工具、文件、审批、任务流之间的编排。
这对测试影响很大。
以前测 agent，更多是在测：
- 提示词是否稳定
- 工具调用是否正确
- 输出是否符合预期
现在还要测：
- 工作区是否隔离
- 文件状态是否一致
- 中断恢复是否可控
- 重试是否引入副作用
- 审核前后上下文是否断裂
- 产物、日志、回答能否对得上
这些问题，本质上已经更像运行时测试，而不是单纯的结果测试。
四、同样叫 AI 测试，新对象已经不是老办法能覆盖的
这两年很多团队都在说自己在做 AI 测试。 但把对象展开看，差别已经非常大。
| 过去更常见的测试对象 | 现在开始出现的测试对象 |
|---|---|
| Prompt 输入与文本输出 | 工作区、文件、命令、浏览器、产物 |
| 单轮回答正确率 | 长链路任务完成率 |
| 功能通过或失败 | 权限边界、恢复能力、审计能力 |
| 跑分高低 | 评测器是否可信 |
| 页面脚本稳定 | 浏览器执行能否自愈 |
这个变化不是名词换了，而是对象真的换了。 browser-harness 这类项目强调的是 self-healing，不是简单脚本回放；OpenAI 强调的是 sandbox execution，不是单纯 tool calling；Anthropic 强调的是 safety profile，不是只讲效果。三边一起变，说明行业正在把 AI 从“模型问题”改造成“系统问题”。
所以今天再说 AI 测试，至少要分清两种工作：
一种还是在测输出。 另一种已经是在测一个带状态、带权限、带环境、带恢复的执行系统。
这两类都重要。 但后者明显更难，也更接近下一阶段岗位要求。
五、工程落地时，测试团队最该补的不是“多写几个用例”
真正该补的，不只是测试数量。 而是测试对象的定义方式。
1. 先把评测器纳入范围
后面做 AI 评测，不能只建设任务集和评分逻辑。 至少还要补上这些检查：
- ground truth 是否泄露
- 评分逻辑是否会被输入污染
- judge 是否存在注入路径
- 评测环境和执行环境是否共享状态
- 高分到底是能力提升，还是规则漏洞
伯克利这次已经把教训给得很具体了：不测评测器，后面的分数可能没有太强讨论价值。
2. 从结果测试，升级到运行时测试
如果系统里已经接了 Agent，建议最少补四类用例：
- 环境隔离测试：命令、依赖、文件、网络访问是否越界
- 状态恢复测试：中断、超时、容器丢失后能否续跑
- 人工审核衔接测试：审批前后上下文和产物是否一致
- 审计追踪测试：日志、文件、截图、回答能否串起来复盘
这些问题如果不上线前测，往往会在上线后变成“偶发失败”“重复执行”“状态错乱”“查不出原因”的问题。OpenAI 把 sandbox 做进 Agents SDK，本身就在说明：运行时已经不是可有可无的外围能力了。
3. 把浏览器自动化从脚本工程升级成策略工程
这一点对测试开发尤其重要。
过去浏览器自动化更像在解决“脚本怎么写得更稳”。 后面更关键的问题会变成：
- 页面状态怎么感知
- 中途跑偏怎么恢复
- 动态流程怎么纠偏
- 执行过程怎么观察
- agent 临时补出来的 helper 怎么审计
self-healing browser harness 这类方向继续走下去，测试侧真正拉开差距的，不再只是 locator 和等待时间，而是运行过程设计能力。 ([GitHub][4])
这里再放一张图，会更适合读者理解“结果测试”和“系统测试”的差别：
同样叫测试。 覆盖范围已经不是一个量级。
下一代 AI 测试的分水岭，不是会不会多写几个 Prompt，而是能不能把模型当成一个真正会跑起来的系统来测。
六、下一阶段拉开差距的，可能不是 Prompt，而是系统验证能力
很多在校生会觉得这些变化离自己还远。 其实一点都不远。
岗位要求的变化，通常先出现在技术栈里，再出现在 JD 里，最后才出现在大家的体感里。 当 Claude 4.7 这种版本开始把安全行为公开写进版本说明，当 OpenAI 把 sandbox 和 harness 正式推成标准能力，当 benchmark 被证明能被系统性刷分，测试岗位对“只会测功能、只会看结果、只会写普通断言”的容忍度一定会越来越低。
对初级工程师来说，最该补的是从“结果验证”走向“过程验证”的意识。 对中级工程师来说，更该补的是把 AI 测试接进工程系统的方法。 对在校生来说，最值得尽早建立的认知也很直接：
以后你面对的很多测试对象，已经不是一个页面、一个接口、一个功能点。 而是一条真正会执行、会中断、会恢复、会影响外部环境的链路。
问题已经摆在这了。 你现在手里的测试体系里，评测器、执行环境、权限边界、恢复机制，哪一项已经被你当成正式的被测对象了？
