这两年程序员第一次碰到了一个有点反常的问题：
代码写得太快了。
以前一个需求可能是：
产品评审半天。
开发3天。
测试2天。
修Bug一天。
上线。
现在有了Cursor、Claude Code、Codex之后，有些中小需求真的可能变成：
产品需求刚下来。
开发把Prompt扔进去。
Agent读代码。
Agent改代码。
Agent补接口。
Agent写SQL。
Agent提交PR。
半小时以后，开发转头问测试：
“好了，可以测了。”
测试工程师：
？？？
昨天三个需求还没测完，今天又来了五个。
这就是AI Coding越来越普及以后，一个很容易被忽视的问题：
开发速度提高，不等于整个软件交付速度同比提高。
如果代码生成速度提高5倍，而验证速度只提高20%，最后新的瓶颈反而会出现在：
QA。
也正是在这个背景下，一个叫 Argus 的开源项目最近登上了Hacker News。
它打出的定位非常直接：
Agentic QA for teams whose coding agents move faster than QA.
翻译成人话就是：
既然写代码的已经是Agent了，那为什么测试代码还必须靠人一条一条写？
这件事情，可能比“AI帮我生成测试用例”要重要得多。
一、Argus到底干了什么？
先别把它想得太复杂。
传统UI自动化通常是：
测试工程师
↓
设计测试场景
↓
写Playwright/Selenium脚本
↓
维护Selector
↓
运行脚本
↓
看报告
Argus想做的事情变成了：
测试目标
↓
AI理解我要测什么
↓
自己探索页面
↓
自己规划测试步骤
↓
调用Playwright操作浏览器
↓
动态判断页面结果
↓
输出报告、截图、执行时间线
Argus官方把一次测试拆成了五个Agent。
Validator
先检查你的URL和测试目标是不是可执行的。
Comprehender
把一句自然语言需求拆成测试场景。
Explorer
先去页面里探索：
有什么页面？
有什么按钮？
可以做什么操作？
Strategist
根据页面地图和测试目标规划执行步骤。
最后是：
Executor
真正打开Playwright浏览器，点击、输入、滚动、检查结果。
所以它真正值得测试工程师研究的，并不是：
“又来了一个AI自动化工具。”
而是：
测试自动化正在出现另外一种组织方式。
过去：
Script Driven Testing。
现在开始出现：
Agent Driven Testing。
二、但这里有一个非常容易被吹过头的地方
很多文章会直接得出结论：
XPath没用了。
Playwright不用学了。
自动化脚本要消失了。
我觉得都说早了。
因为Agentic QA不是把确定性测试扔掉。
真正合理的架构其实是：
AI负责理解
+
AI负责规划
+
自动化工具负责执行
+
确定性程序负责验证
这句话特别重要。
因为：
LLM适合推理。
但：
测试Oracle最好尽可能确定。
什么叫Oracle？
简单说就是：
你凭什么判断这个测试到底通过了？
这恰恰是很多初级测试工程师天天在做，但面试的时候又很容易讲浅的地方。
我们从一个最简单的真实案例讲起。
三、案例一：为什么你的UI自动化总是“昨天能跑，今天挂了”？
假设你负责一个商城。
最普通的登录自动化：
from playwright.sync_api import sync_playwright
with sync_playwright() as p:
browser = p.chromium.launch()
page = browser.new_page()
page.goto("https://test.example.com/login")
page.locator("#username").fill("tester")
page.locator("#password").fill("123456")
page.locator("#login-btn").click()
page.wait_for_url("**/home")
assert page.locator(
".welcome"
).inner_text() == "欢迎回来"
browser.close()
跑了两个月。
突然有一天CI红了。
TimeoutError:
locator("#login-btn")
not found
你打开网站。
登录功能根本没坏。
只是前端重构以后：
变成：
于是：
业务没有变。
自动化挂了。
四、面试官问：为什么UI自动化维护成本高？
很多初级工程师回答：
因为元素容易变化。
对。
但如果只回答到这里，最多算60分。
真正更深的问题是：
我们把“业务意图”和“页面实现”绑定得太紧了。
测试真正想表达的是：
输入用户名
输入密码
点击登录
验证登录成功
但是脚本表达的是：
page.locator(
"#app > div:nth-child(2) > form > button"
).click()
前者是什么？
业务语义。
后者是什么？
实现细节。
于是页面实现只要调整：
测试资产跟着坏。
这才是传统UI自动化一直被Flaky Test困扰的重要原因之一。
五、Playwright其实已经往前走了一步
所以为什么现在越来越多自动化工程师喜欢：
page.get_by_role(
"button",
name="登录"
).click()
而不是：
page.locator(
"//*[@id='root']/div/div[2]/button"
).click()
因为前者更接近：
用户看到的东西。
而不是：
DOM具体怎么实现。
这就是一个非常值得记住的变化：
结构定位
↓
语义定位
↓
意图驱动
而Argus这类Agentic QA，实际上是在继续往下一层走：
测试人员甚至不告诉它：
get_by_role("button", name="登录")
只告诉它：
验证正常用户是否可以成功登录商城。
剩下的页面理解和操作规划让Agent完成。
六、一个最小的Agentic QA到底长什么样？
我们甚至不需要上来就搭一个复杂Agent框架。
先把测试目标变成结构化描述：
test_task = {
"goal": "验证正常用户是否能够成功登录商城",
"user": {
"username": "tester",
"password": "123456"
},
"expected": [
"登录成功",
"进入用户首页",
"页面展示当前用户名"
]
}
然后让LLM负责：
理解测试目标
↓
观察页面
↓
产生Action
例如：
{
"action": "click",
"target": {
"role": "button",
"name": "登录"
}
}
最终仍然可以交给Playwright执行：
def execute_action(page, action):
if action["action"] == "click":
target = action["target"]
page.get_by_role(
target["role"],
name=target["name"]
).click()
注意这个结构。
LLM没有直接控制Chrome。
而是：
LLM
↓
Structured Action
↓
Browser Tool
↓
Playwright
↓
Browser
这实际上就是Agent工程里非常重要的一条原则：
不要让模型直接干所有事情。
尽量让模型：
决策。
让Tool：
执行。
七、但是问题来了：Agent说“登录成功”，你信吗？
这是我特别建议拿去做面试题的一句话。
假设Agent完成操作以后告诉你：
测试通过。
用户成功登录商城。
你敢直接把CI标绿吗？
当然不能。
因为：
Agent自己的结论不能直接等于测试结果。
这也是Agentic QA最容易被初学者忽略的问题。
八、我们需要一个Evaluator
比如登录成功，不要问LLM：
“你觉得是不是成功了？”
可以直接验证三个事实。
第一：
URL。
assert "/home" in page.url
第二：
登录态。
cookies = page.context.cookies()
token_exists = any(
cookie["name"] == "access_token"
for cookie in cookies
)
assert token_exists
第三：
页面状态。
expect(
page.get_by_text("tester")
).to_be_visible()
于是整个系统变成：
Planner Agent
↓
Executor
↓
Browser
↓
Evaluator
这里真正发生了一件非常重要的事情：
Agent可以是概率性的。
但是：
核心业务结果尽量使用确定性验证。
九、“测试从确定性脚本走向概率性推理”，到底是什么意思？
这句话最近很火。
但是特别容易被误解。
传统自动化：
click("#login")
fill("#username")
assert url == "/home"
只要环境不变：
执行路径就是固定的。
这种东西叫：
Deterministic。
Agentic QA不一样。
同样一句：
测试一下登录功能。
第一次Agent可能：
先看登录按钮。
第二次可能：
先分析表单。
第三次：
可能尝试注册入口以后再返回登录。
它的执行路径：
并不一定完全一致。
这就是概率性推理。
所以Agentic QA真正难的不是：
能不能点页面。
真正难的是：
每次走的路都可能不同，怎么证明最终质量是稳定的？
这就把测试行业带到了一个新的问题：
我们开始需要测试“测试Agent”。
十、怎么测试一个Agent？
假设我们让Argus类Agent执行：
验证用户可以正常登录
不要只跑一次。
跑100次。
记录：
results = {
"total": 100,
"success": 87,
"failed": 13
}
success_rate = (
results["success"]
/ results["total"]
)
print(success_rate)
结果：
87%
现在问题来了。
传统自动化：
通过
失败
Agent测试开始出现：
成功率
继续。
为什么13次失败？
可能是：
5次页面定位错误
3次错误判断验证码状态
2次模型超时
2次错误规划
1次环境故障
测试工程师开始需要统计：
metrics = {
"task_success_rate": 0.87,
"avg_steps": 8.6,
"avg_latency": 14.2,
"avg_tokens": 3260,
"retry_rate": 0.18
}
这其实已经不是传统UI自动化的思维了。
这是：
Agent Evaluation。
十一、再看一个真正企业级的案例
前面登录的例子大家每天都能遇到。
接下来我们上一个难度。
假设现在测试的是：
电商退款。
需求：
用户购买商品后，在订单发货前申请退款，退款成功后订单关闭、支付原路退回、库存恢复、优惠券返还。
页面看起来只有一个按钮：
申请退款
但是背后的业务链路可能是：
退款申请
↓
订单服务
↓
支付服务
↓
库存服务
↓
优惠券服务
↓
MQ
↓
数据最终一致
这时候如果Argus只看到：
页面显示“退款成功”
它真的测完了吗？
没有。
甚至只完成了20%。
十二、这也是为什么“像用户一样测试”还不够
真正的企业QA必须同时回答：
页面状态对不对？
接口状态对不对？
数据库对不对？
支付流水对不对？
库存有没有回滚？
优惠券有没有恢复？
消息有没有重复消费？
这就是单纯Browser Agent和真正企业级Agentic QA之间的差距。
Argus当前公开项目主要聚焦视觉UI测试和真实Playwright浏览器环境；但其“理解目标—探索环境—规划—执行”的思路，可以继续向API、数据库、日志、消息队列等企业测试工具扩展。
十三、退款场景怎么设计Agentic QA？
可以拆成：
Test Planner
↓
UI Agent
↓
API Agent
↓
DB Tool
↓
MQ Tool
↓
Evaluator
例如UI Agent负责：
page.get_by_role(
"button",
name="申请退款"
).click()
page.get_by_text(
"退款原因"
).click()
page.get_by_role(
"button",
name="提交"
).click()
然后API层验证：
import requests
def get_order(order_id):
response = requests.get(
f"https://test-api.example.com/orders/{order_id}"
)
return response.json()
order = get_order("ORDER_10086")
assert order["status"] == "REFUNDED"
十四、然后查支付
def get_payment(order_id):
response = requests.get(
"https://payment-test.example.com/query",
params={"orderId": order_id}
)
return response.json()
payment = get_payment("ORDER_10086")
assert payment["refundStatus"] == "SUCCESS"
再查库存：
stock_before = 100
stock_after = query_stock(
sku_id="SKU_001"
)
assert stock_after == stock_before
优惠券：
coupon = query_coupon(
user_id="USER_001"
)
assert coupon["status"] == "AVAILABLE"
这时候你会发现：
真正可靠的Agentic QA，不是：
所有东西都让AI判断。
反而是：
AI负责协调越来越多确定性的验证工具。
十五、这里藏着一道特别经典的面试题：什么叫最终一致性？
假设退款成功后。
订单：
立即变成 REFUNDED
但是库存服务因为MQ异步消费：
3秒后才恢复。
你的测试代码：
assert query_stock("SKU_001") == 100
立即执行。
结果：
99
测试失败。
这是Bug吗？
不一定。
可能只是：
Eventually Consistent。
很多初级测试工程师遇到这种问题第一反应就是：
time.sleep(10)
这也是面试特别容易说不清楚的地方。
十六、为什么sleep(10)不是好方案？
因为：
如果1秒恢复：
浪费9秒。
如果11秒恢复：
还是失败。
正确思路应该是：
Poll + Timeout。
例如：
import time
def wait_until(
condition,
timeout=10,
interval=0.5
):
start = time.time()
while time.time() - start < timeout:
if condition():
return True
time.sleep(interval)
return False
使用：
success = wait_until(
lambda:
query_stock("SKU_001") == 100,
timeout=10
)
assert success
这背后真正考的是：
同步等待和异步最终一致性的区别。
如果面试官问：
为什么不能直接sleep？
只回答：
“浪费时间。”
明显不够。
更完整的答案应该是：
sleep属于固定等待，既无法根据实际状态提前结束，也无法适应超出固定等待时间的异步延迟；对于最终一致性场景，更适合使用带超时的条件轮询。
这就是面试官真正想听的东西。
十七、Agent反而能让这件事情更聪明
假设Evaluator发现：
订单 = REFUNDED
支付 = SUCCESS
优惠券 = AVAILABLE
库存 = 99
它不应该立即：
FAILED
Agent可以根据系统知识判断：
库存由异步MQ更新，需要等待最终一致。
于是调用：
wait_inventory_consistency
再检查。
10秒以后仍然：
99
才真正失败。
然后自动继续：
查询MQ Trace。
trace = query_mq(
key="ORDER_10086"
)
发现：
RefundSuccessEvent
sent = 1
InventoryRollback
consumed = 0
再查日志：
logs = search_log(
keyword="ORDER_10086"
)
发现：
inventory-service
ERROR:
consumer timeout
最后Agent给出的已经不是：
退款测试失败。
而可能是：
测试失败
影响：
退款成功后库存未恢复。
已确认：
订单状态正常
支付退款成功
优惠券已返还
异常模块：
inventory-service
证据：
InventoryRollback消息未被成功消费
建议：
检查库存消费服务及MQ积压。
这才开始接近企业真正想要的：
Autonomous QA。
十八、Argus最让我感兴趣的，其实不是“无脚本”
因为“自然语言测试”以前也有人做。
真正重要的是它把：
理解、探索、规划、执行
拆开。
这意味着未来测试Agent很可能不会是：
一个超级大模型
什么都干
而是：
Comprehender
↓
Explorer
↓
Planner
↓
Executor
↓
Evaluator
甚至继续扩展：
Diagnosis Agent
↓
Bug Agent
↓
Regression Agent
这种Multi-Agent测试架构。
这跟AI Coding正在发生的变化非常像。
十九、未来研发链路可能真的会变成“双Agent”
过去：
产品
↓
开发
↓
测试
AI Coding之后：
产品
↓
Coding Agent
↓
测试工程师
但如果Coding Agent一天能够提交几十个Change：
人类测试不可能永远线性跟着增加。
下一步很可能是：
Coding Agent
↓
生成代码/修改
↓
提交Change
↓
QA Agent
↙ ↓ ↘
UI API DB
↓
Evaluator
↓
发现问题？
↙ ↘
Yes No
↓ ↓
Coding Agent修复 Merge
↓
Re-Test
这就是：
AI写码Agent + AI测试Agent
形成闭环。
但有一个特别重要的前提：
绝不能让写代码的Agent自己给自己打满分。
二十、为什么“自己写、自己测”有风险？
假设Coding Agent生成：
def discount(price, level):
if level == "VIP":
return price * 0.8
return price
然后它自己生成测试：
def test_discount():
assert discount(
100,
"VIP"
) == 80
通过。
于是它认为：
功能正确。
但是需求真正写的是：
VIP 8折
但单笔最高优惠50元。
对于：
1000元商品
正确价格应该：
950
而代码返回：
800
Coding Agent只测了：
自己理解到的需求。
于是产生一个非常危险的问题：
同源偏差。
这就是为什么开发Agent和测试Agent最好拥有：
独立上下文、独立测试策略甚至不同模型。
否则就变成：
自己出题。
自己答题。
自己判卷。
最后：
100分。
二十一、这也是未来测试工程师真正值钱的地方
如果你看到Argus以后，只得出：
以后测试不用写代码了。
我认为理解浅了。
恰恰相反。
未来测试开发可能更需要理解：
业务。
架构。
测试Oracle。
异步系统。
接口。
数据库。
Agent。
上下文。
工具调用。
评测指标。
因为AI可以帮你：
点击。
输入。
生成脚本。
探索页面。
但是有一个问题AI永远很难凭空知道：
到底什么叫“对”？
退款成功以后库存是不是必须立刻恢复？
订单金额和支付金额如何对账？
优惠券能不能重复返还？
一个请求执行两次应该生成两个订单还是一个？
管理员和普通用户到底有什么权限边界？
这些东西叫：
Business Oracle。
谁最懂这些？
还是长期理解业务系统的人。
二十二、顺便再送一道面试高频题：什么叫幂等？
假设Agent测试：
点击支付
网络卡了一下。
它没看到结果。
于是再点一次。
支付
支付
结果后端生成：
PAY_001
PAY_002
用户被扣了两次钱。
测试发现重大Bug。
这里面真正的知识点叫：
Idempotency。
一个幂等接口：
重复执行一次和执行多次：
最终业务效果应该一致。
例如：
headers = {
"Idempotency-Key":
"ORDER_10086_PAY"
}
requests.post(
"/pay",
json=data,
headers=headers
)
重复调用：
requests.post(
"/pay",
json=data,
headers=headers
)
服务端应该识别：
同一个业务请求。
而不是再创建一次支付。
你会发现：
Argus、Agentic QA这些新技术，最后真正落到测试里，绕不开的依然是：
幂等。
并发。
事务。
最终一致性。
缓存。
MQ。
权限。
这些经典问题。
所以AI时代最危险的学习方式是什么？
每天背：
Agent
MCP
Skill
Harness
RAG
结果面试官问：
为什么支付接口必须做幂等？
回答不上来。
那还是很难成为真正的AI测试开发工程师。
二十三、所以确定性脚本真的要消失吗？
不会。
我甚至认为恰恰相反。
未来测试体系很可能分成三层。
第一层：
Deterministic Test
稳定、关键、强规则。
例如：
assert order_total == 1000
assert pay_amount == 1000
assert stock == 98
这种测试：
不要让AI自由发挥。
第二层：
Agentic Test
适合：
探索。
异常路径。
UI变化。
未知场景。
自然语言需求。
复杂流程组合。
第三层：
AI Evaluator
负责：
理解复杂输出。
异常归类。
失败分析。
测试覆盖评估。
最终形成：
确定性自动化
+
概率性Agent
+
Evaluator
这才可能是更现实的下一代测试体系。
不是：
Agent替代Playwright。
而是：
Agent站到Playwright上面。
二十四、对于初级测试工程师，应该学什么？
看完Argus，不需要马上去造一个五Agent系统。
真正建议的顺序还是：
Python
↓
HTTP/API
↓
SQL
↓
Playwright
↓
Pytest
↓
CI/CD
↓
LLM基础
↓
Tool Calling
↓
MCP
↓
Agent
↓
Agent Evaluation
尤其不要跳过前半段。
因为Agent失败以后。
最终你还是要回答：
为什么接口404？
为什么Cookie没写进去？
为什么元素不可点击？
为什么数据库数据不一致？
为什么MQ延迟？
为什么接口重复提交？
为什么事务回滚？
AI能给你一个猜测。
但是：
测试开发工程师必须能判断这个猜测对不对。
写在最后
Argus现在当然还是一个很年轻的开源项目。
它目前重点解决的也是UI测试，而不是企业所有QA问题。
所以现在就喊：
测试脚本彻底消失。
显然言之过早。
但我认为它出现的时间点非常有意思。
因为过去两年软件行业几乎所有的AI效率提升，都优先发生在：
写代码。
Cursor。
Claude Code。
Codex。
Copilot。
越来越多Coding Agent出现以后，我们终于开始面对一个过去不存在的问题：
如果代码生成能力已经不再稀缺，谁来验证这些代码到底能不能上线？
于是测试突然重新变得重要。
只不过：
未来负责测试的不一定只有人。
很可能还有另外一群Agent。
Coding Agent负责疯狂生产Change。
QA Agent负责疯狂寻找问题。
人类测试工程师逐渐从：
亲自点每一个按钮
往：
设计测试规则
构建Tool
定义Oracle
治理测试Agent
分析真正高风险问题
移动。
这也是为什么我觉得，Argus真正值得测试工程师关注的不是：
“AI会不会把测试脚本干掉？”
而是：
AI已经把写代码这件事提速了，下一个必须被重新设计的环节，会不会恰恰就是测试？
如果答案是Yes。
那么未来最有价值的测试工程师，可能不再是：
最会写Case的人。
也不一定是：
最会写XPath的人。
而是那个真正知道：
什么必须测、什么才算通过、出了问题应该去哪找证据，以及怎么让一群Agent可靠地替团队完成这些工作的工程师。
这可能才是 Agentic QA 真正值得关注的地方。
