只信证据：基于LLM的测试Agent如何用证据链终结页面假绿-北京尧图网络

1. 六项检查全绿用户却在投诉“多收了钱”一次让人冒冷汗的回归测试做电商后端和测试平台的朋友应该都经历过这种时刻版本上线前自动化测试报告漂亮得可以裱起来功能测试通过、接口测试通过、页面渲染正常、响应耗时在阈值以内、视觉比对零 diff、性能压测也没毛刺——六个维度的检查全部满分。结果灰度放量不到两小时客诉群里就有人晒出支付截图“明明页面写的 199为什么扣了我 219”我当时看到用户反馈的第一反应是“肯定是个例”。我们那套自动化体系已经跑了两年多基于 Selenium 和 pytest 的 UI 断言、基于接口文档的契约测试、基于快照的视觉比对每一层都有专人维护。六个满分意味着六套检查全部符合预期怎么可能还有金额错误结果一查订单日志脸被打得生疼用户领了一张满 200 减 20 的券商品详情页展示的还是“券前价”结算页价格组件通过前端 JavaScript 做了动态换算把 199 显示成了 179但真正提交订单时后端价格计算服务并没有读取到券的有效期字段——后端接口返回的实际扣款金额还是 219。问题很清晰比问题更扎心的是我们那套“全面”的测试体系从头到尾都在验证“页面看起来对不对”而没有验证“页面背后的事实对不对”。页面文本可以被运行时脚本改写接口响应可能被网关拦截修正数据库里的状态才是最终的真相。但我们过去的所有断言都建立在“DOM 里有什么文本”这个最不可靠的证据之上。这次事故之后我开始认真思考一个问题能不能做一个测试 Agent它不预设“页面应该显示什么”而是主动去采集接口响应、数据库状态、服务日志、支付回调这些硬证据再回到页面上反查展示值跟硬证据对得上对不上。说白了一句话——只信证据不信页面。于是就有了后面这套只信证据的测试 Agent也踩了无数坑。下面把从设计到落地的完整过程都写出来。2. “六维满分”为什么翻车页面文本只是嫌疑人陈述不是证据2.1 我们原来引以为傲的六项检查每一项都在测什么先还原一下当时那套测试体系的六个维度它们分别是功能流程、接口契约、视觉还原、响应时效、性能基线、兼容覆盖。听起来已经很全面但拆开看就有问题功能流程基于 Playwright 脚本走主链路断言点全部是“某个元素应该包含某段文本”比如价格区域包含“199”订单状态包含“已提交”。接口契约校验返回字段名、类型、枚举值是否符合文档但不校验字段值之间的业务一致性。视觉还原截图做像素级对比看布局有没有漂移完全不知道里面数字是不是真的。响应时效统计每个请求的耗时分布只要 p95 低于阈值就通过。性能基线压测 TPS、错误率看服务能不能扛住并发。兼容覆盖在不同浏览器和分辨率下把主流程跑一遍确保不白屏、不报错。这套体系最大的问题不是单项检查做得不够细而是每个维度都在独立打分没有交叉验证。功能流程说“页面显示正确”接口契约说“返回结构合法”视觉检测说“像素没变动”于是整体结论就是“通过”。但没有任何一环去验证“页面显示的数字”和“接口返回的数字”是同一个数字。用户反馈的价格问题恰好就踩在这个盲区里。页面上的 179 是前端运用“券后价”规则算出来的展示值接口返回的 219 是后端真正的计费结果。页面断言抓的是 DOM 文本 179接口断言校验的是字段结构合法两边都对但对的不是同一件事。六项检查没有一项把这两条数据串起来比对过。2.2 页面文本为什么只能算“嫌疑人陈述”养成“只信证据”这个思维习惯之后我用一个类比跟团队解释为什么页面文本不可靠在审判里嫌疑人的陈述只能当参考不能当定案依据因为它随时可以翻供。页面文本就是嫌疑人的陈述它的生产链条太长、可篡改环节太多前端 JavaScript 可以在数据到达 DOM 之前做二次计算展示值不等于接口原始值。网关层可能对响应体做字段裁剪、格式修正你看到的结构和上游服务吐出来的不一定一样。页面可能命中 A/B 实验、灰度策略同一接口在不同用户请求下返回不同默认值。缓存组件可能把旧版本页面存了 10 分钟你断言的是过期文案。第三方脚本、浏览器插件、运营商劫持都可能改动最终展示的字符串。前端代码自身的 bug就是这次事故的直接原因——价格组件算错了券的有效期。所以页面文本天然带有“不可信”属性。它适合用来判断“页面有没有渲染出来”但绝不适合用来判断“业务事实是否正确”。业务事实的正确性必须从更接近事实源头的环节取证据服务端 API 的请求与响应、数据库落库记录、支付平台的回调报文、服务日志里的 trace 链这些才是定案时该用的硬证据。2.3 证据等级从文本到日志可信度逐级递增后来我们内部把事情简化成一张证据分级表测试 Agent 在给结论加权的时候就按这个表来证据来源可信度能证明什么容易被什么影响数据库落库状态最高业务真实发生的最终结果事务隔离级别、缓存未刷服务端日志链路很高处理过程发生了什么、异常在哪一步抛出日志采样丢失、编码问题后端接口原始响应高服务端计算逻辑的输出网关改写、序列化丢精支付/推送回调报文高外部系统确认的事实报文签名校验未做网络层抓包中实际传输的内容加密流量、双向 TLS页面 DOM 文本低浏览器最终展示的字符串JS、缓存、A/B、插件测试 Agent 的取证策略就是建立在这张表上的能用高可信度证据定案绝不用低可信度文本。每次给出“通过”结论时必须至少有一条高可信度证据印证如果一条硬证据都拿不到即使页面全绿结论也只能是“未证实”不能写“通过”。3. 只信证据的测试 Agent 长什么样整体架构与工作方式3.1 Agent 的定位一个主动取证的质检员不是一个会写断言的框架方案立项之前我们内部讨论过两条路线一是继续用传统自动化测试框架把证据采集逻辑写成断言前置步骤本质上是给 pytest 加一堆 fixture二是引入 Agent让 LLM 作为大脑负责理解业务目标、规划取证路径、调工具、汇总证据链、生成结论。最后选了 Agent 路线原因是传统框架解决不了“目标漂移”的问题。传统断言脚本要求你在写脚本的时候就知道“正确答案是多少”比如断言订单金额等于 199 元。但很多时候测试人员根本不知道正确答案——不同促销组合叠加、不同用户等级的折扣、不同支付渠道的手续费正确答案是动态计算的产物不是静态常量。传统脚本只能把“正确答案”也模拟一份等于用一套可能错的逻辑去校验另一套逻辑体系越复杂这种重复实现带来的偏差越大。Agent 不一样。它不预先假设正确答案它只做一件事把同一笔业务在四个证据源里的值都采集出来然后判断它们是否互相印证。页面说 179、接口说 219、数据库扣款记录是 219、日志里计费参数带的还是 219——在四个证据里三个说 219一个说 179。哪怕 Agent 不知道真正该收多少钱它也能确认页面这个 179 是孤立异常值需要标记出来交给开发排查。3.2 核心模块意图解析、工具注册表、证据库、裁决器Agent 按职责拆成四个模块各管一段意图解析器接收自然语言形式的测试任务比如“用新用户账号下一单领一张满 200 减 20 的券确认结算金额和实付金额一致”。解析器把这句话拆分出业务动作序列注册、领券、下单、支付和验证目标结算金额与实付金额的一致性。工具注册表维护一组可被 Agent 调用的取证工具。每个工具对外暴露统一的输入输出协议LLM 通过函数调用机制选择工具并传入参数工具执行后返回结构化结果。所有工具执行的结果都会自动写入证据库不经过 LLM 转述。证据库核心存储层。每一条证据都有全局唯一的证据 ID、来源标签page/api/db/log/callback、采集时间、原始内容、可信度等级。这个模块是后面所有裁决的数据基础没有它“引用证据”就无从谈起。裁决器负责把 LLM 的“印象”转成“决定”。裁决器拿到证据库里的若干条证据后执行三类交叉验证数字字段等值比对、订单状态时序校验、金额汇总关系复核。通过则输出“通过附引用证据 ID”不通过则输出“异常附差异证据 ID”证据不足则输出“未证实附缺失证据说明”。3.3 一次典型的取证流程下单场景全链路证据采集拿最经典的“领券下单”场景举例看 Agent 实际跑起来是什么节奏第一步Agent 调用create_test_user工具创造一个带指定优惠等级的测试账号然后把用户 ID 写入证据库。第二步调用open_page工具打开商品详情页用extract_page_value抓取页面渲染出的主价格文本同时通过 Playwright 的 CDP 会话截获页面加载期间所有 XHR/Fetch 响应把价格相关接口的原始返回体按 URL 规则提取出来。第三步Agent 调用apply_coupon工具领取测试券再调用submit_order工具提交订单成功后立即查询服务端订单接口的返回体。第四步Agent 调用query_db工具查订单表的应付金额、优惠分摊、实付金额字段再调用read_log工具捞取该订单号关联的服务端日志确认计费服务在日志里记录的入参。第五步所有证据进库后裁决器开始工作对比 page_value 的“页面展示价”、api_response 里的“接口应付金额”、db_record 里的“实付金额”三方一致则通过任意不一致则打回。整套流程里 Agent 全程在做“取证与比对”没有任何一步在预设“正确答案”。这也是它能在不重写业务规则的前提下发现真实问题的主要原因。4. 证据链的核心设计怎么让 AI 不做“一千个哈姆雷特”只认同一套事实4.1 LLM 在测试里的通病没有上下文约束时它会“脑补”结论Agent 方案刚跑通的时候我们发现一个特别让人头疼的现象LLM 太聪明聪明到会自己编故事。第一次演示时页面展示价是 179、接口返回 179、数据库落库也是 179Agent 给出结论“通过”。但第二次演示时数据库里落的是 219Agent 回看页面发现页面已经跳转走了抓不到展示价结果它居然基于上一次的上下文“推测”当前页面也是 179然后给了一个“通过”。这种“脑补”在传统测试里是大忌。测试结论必须能够回溯到指定时间点、指定请求、指定数据库记录的硬证据上一拍脑袋得到的结论没有任何工程价值。而且 LLM 的上下文窗口有限工具执行返回的长报文不可能全部塞进 prompt如果不做结构化约束它很容易把 A 工具的返回记成 B 工具的结果产生证据混淆。4.2 “证据回填强制引用”机制让推理过程闭环到每一个证据 ID为了掐掉“脑补”这个毛病我们给 Agent 加了两条硬规则第一证据一律直写证据库不允许经过 LLM 转述。工具执行结果在代码层面直接插入证据库LLM 的 prompt 里只出现证据的摘要证据 ID、来源、采集时间、关键字段的哈希摘要完整报文存在证据库里待查询。这样即使 LLM 记错了摘要内容完整证据也不会被污染。第二最终结论必须引用证据 ID没有证据 ID 支撑的结论不允许进入报告。裁决器输出结论时格式强制为“结论引用的证据 ID 列表差异描述”。在报告渲染层每个证据 ID 都可以展开查看原始回包、数据库行内容、日志片段。你拿到一份测试报告点开任何一个“通过”都能看到它引用了哪条接口响应、哪条数据库记录——这就是证据链闭环。这两条规则立竿见影。以前 LLM 一秒给出结论现在它会先去工具注册表里找工具、跑工具、等结果回填然后才做裁决。速度慢了一点但每个结论都有了实打实的出处。4.3 裁决器与 LLM 的分工LLM 负责找事实规则引擎负责下结论还有一件事必须讲清楚就是结论不能让 LLM 单独下。LLM 的强项是理解自然语言任务、拆解动作序列、从非结构化文本里抽取关键字段但它的弱点是数值计算不可靠、逻辑一致性不稳定。同一个问题你问它三次它可能给你三个答案——这在测试领域是灾难。所以我们的裁决器是一个纯规则引擎数字比对用 Python 内置 decimal 处理不完全依赖浮点字段匹配用精确值匹配加正则兜底订单状态流转校验用有限状态机判断合法转移路径。LLM 只做两件事一是把自然语言测试目标拆成工具调用序列二是从工具返回的文本里抽取需要比对的字段值。一旦抽到字段值后续的等值判断、范围判断、一致性判断全部交给规则引擎。这样一来整个 Agent 的可信度就有了保障LLM 的偶然性错误会被规则引擎挡在结论之外规则引擎的机械性盲区不会分析模糊的自然语言又由 LLM 来弥补。各干各的擅长事边界清晰。5. 从 Demo 到真正能“只信证据”地干活技术选型与实现细节5.1 技术栈选择为什么是 pytest LangChain 风格编排 Playwright先交代选型逻辑方便想复刻这套体系的朋友少走弯路pytest 做任务编排底座虽然 Agent 看着像是自带智能的独立应用但落地时我们仍把它挂在一套 pytest 工程下。原因很实际——pytest 已经有成熟的用例管理、失败重试、参数化、报告插件生态测试团队不用换工具链学习成本低。每个“取证场景”就是一个 pytest 用例Agent 在用例内部被调用。LLM 层用函数调用模式不走 ReAct 文本模式早期我们试过 ReAct 风格让模型输出“思考→行动→观察”文本发现解析不稳定一个输出格式偏差整条链路就断了。后来改成了类似 OpenAI Function Calling 的结构化工具调用模型直接输出 JSON 形式的工具名和参数代码侧做严格 schema 校验稳定性提升非常明显。Playwright 负责页面取证对比 SeleniumPlaywright 的 CDP 支持太好用了可以拦截网络请求、模拟更真实的用户手势、自动等待网络空闲。特别是page.expect_response()配合 URL 模式过滤能精准抓取指定接口的响应体这是页面证据采集的核心能力。SQLAlchemy Core 做数据库取证只读查询用 SQLAlchemy 的text()表达式执行原生 SQL避免 ORM 映射带来的字段名歧义。日志取证用文件尾监听加 traceId 关联测试发起时注入一个有特征的 traceId 前缀Agent 在日志文件里按 traceId 过滤出本次请求的完整链路。5.2 工具注册表的实现每个工具自带“证据源标签”和“可信度等级”工具注册表的核心数据结构每个工具描述包含五段工具名称、功能描述、参数 JSON Schema、返回结果结构、证据元数据。其中证据元数据最关键它声明了一个工具采回来的数据算什么来源、多大可信度。用代码说事这是工具注册表里的一个简化条目TOOL_REGISTRY [ { name: extract_page_value, description: 提取页面指定区域渲染后的最终文本值低可信度证据仅用于展示层对比, parameters: { type: object, properties: { selector: {type: string, description: CSS 选择器}, field_name: {type: string, description: 业务字段名如 order_amount} }, required: [selector, field_name] }, returns: { type: object, properties: { value: {type: string}, captured_at: {type: string} } }, evidence_meta: { source: page, credibility: 1, store_raw: True } }, { name: query_db, description: 对读库执行只读 SQL返回查询结果集最高可信度证据会存储原始行数据, parameters: { type: object, properties: { sql: {type: string, description: 只读 SELECT 语句}, db_name: {type: string, description: 目标数据库标识} }, required: [sql, db_name] }, returns: { type: object, properties: { columns: {type: array, items: {type: string}}, rows: {type: array, items: {type: array}} } }, evidence_meta: { source: db, credibility: 3, store_raw: True } } ]每个工具的evidence_meta在工具执行后由采集层自动附加在证据记录上LLM 全程不接触这个字段所以它无法“冒充”高可信度证据。5.3 证据库落库与检索证据 ID 怎么生成、怎么关联到结论证据库我们用 SQLite 加 JSON 字段就够用了单机测试场景的吞吐量不大SQLite 省去运维成本。每条证据的落库结构如下{ evidence_id: evt_8f3a2c1b_de_20240601_091523, test_run_id: run_20240601_090000, source: api, // page / api / db / log / callback credibility: 2, tool_name: fetch_order_api, captured_at: 2024-06-01 09:15:23.112, summary_hash: a94a8fe5ccb19ba61c4c0873d391e987982fbbd3, raw_payload: { ... }, // 完整原始报文按来源类型结构不同 indexed_fields: { order_id: ORD20240601001, pay_amount: 219.00, show_amount: 179.00 } }裁决器在比对字段时直接读indexed_fieldsLLM 在生成报告时引用evidence_id人工复核时展开raw_payload看原始内容。三层结构各管各的证据链自然就完整了。有一说一这个结构是我们被坑了两次之后才定下来的最初试过只存raw_payload结果每次比对都要解析一遍非结构化 JSON慢不说LLM 抽取字段还容易抽错。加了indexed_fields这一层打平结构之后整个裁决流程快了不是一点半点。5.4 裁决器三类交叉验证规则裁决器内部实现三类核心验证规则等值验证两个或多个证据源的同一业务字段必须完全一致。用于校验页面展示金额、接口返回金额、数据库实付金额三者关系。金额用Decimal(str(x))做精确比较绝不使用浮点。时序验证业务状态必须沿着合法路径转移。比如订单状态从“待支付”到“已支付”可以但直接从“已创建”跳到“已完成”就不合法。状态流转校验用预定义的状态机表。聚合验证多字段之间的运算关系必须成立。例如商品原价 - 优惠金额应付金额、应付金额运费实付金额。这类验证常能揪出“页面显示对、接口单个字段也对、但总和算错”的隐蔽问题。这三类规则不依赖任何 LLM全部是纯代码执行速度和可靠性都有保障。Agent 的角色就是把各个证据源的数据喂到这几套规则里。6. 踩过的坑和对应的处理如果你也要做测试 Agent这几点请提前准备6.1 LLM 的“证据混淆”问题上下文越长越容易串台先说最隐蔽的坑。Agent 在处理一个多步骤用例时会连续调用多个工具每个工具都产生若干证据。LLM 在汇总阶段阅读摘要时偶尔会把“步骤 1 的金额”安到“步骤 2 的订单”上尤其当两个字段值相近时它会在不自觉间完成错误的关联。处理办法我们在 4.2 节讲过就是强制引用证据 ID。这里补充一个细节摘要文本里不要把多个字段值揉在一起要一条证据一行字段名和值用固定分隔符。LLM 对这种结构化文本的理解准确度远高于自由排版文本这个经验亲测有效。6.2 异步时序问题页面还没渲染完“证据缺失”误报Playwright 打开一个页面脚本立刻开始抓数据结果 DOM 里什么都还没有extract_page_value返回空值Agent 就以为页面没展示价格给出“未证实”的结论。后来在工具层加了“重试超时”机制页面证据采集工具内部先等待目标选择器出现再等待 500ms 给前端脚本算完数据最后才抓取文本。必要时可以等待networkidle状态但要注意某些页面有长轮询接口会导致networkidle永远等不到。6.3 数据污染比环境崩溃更隐蔽测试 Agent 比传统脚本更容易踩数据污染原因是它追求“真实业务链路”经常真注册、真领券、真下单于是测试数据会污染线上统计报表、影响推荐池、触发风控。我们的对策是所有 Agent 用独立测试账号池账号带明显测试标记订单金额走小额区间支付环节走沙箱支付写完订单后统一跑数据清理任务把测试订单标记或者软删。更关键的坑是——测试账号的优惠券额度会越用越少。第二次跑同一条用例时上一个账号领的券还在或者同一账号额度耗尽导致结果和第一次不一致。现在我们对每个用例强制分配新建账号不重复使用任何已有账号避免“证据对得上但并不是同一条件”的闹剧。6.4 幂等性问题重复点击下单按钮生成了两笔订单Agent 模拟用户操作时重复点击“提交订单”按钮是个多发事故。第一下点击后按钮没有立刻置灰第二下点击又触发了一次请求数据库里就会落两笔订单。这种问题传统脚本偶尔也会遇到但 Agent 因为多了“观察规划”的节奏反而更容易在用户界面还没刷新完成时发起二次操作。解决方法是分层处理前端动作层加按钮防连点拦截后端订单创建接口做幂等校验Agent 在提交订单前会先检查当前页面是否处于“已提交”状态。三层都堵上之后这类问题基本绝迹。6.5 Agent 的“伪智能”陷阱看起来在自动化其实在流水账还有一个不算是 bug 但值得反思的坑。第一版 Agent 做出来后演示效果很好但团队成员私下说“这不就是个套了 LLM 的流程编排工具吗”——话说得不好听但确实是事实。工具调用链是预设的、裁决规则是写死的、报告模板是固定的LLM 只是在中间做字段抽取和自然语言转换。后来我慢慢想明白了在测试领域“求稳”比“求炫”重要一百倍。如果 LLM 真的自由发挥去设计测试步骤十次里有九次跑偏剩下的那一次也缺乏可复现性。测试工具的第一诉求永远是确定性同一输入、同一环境、必须得到同一结论。Agent 的责任是在“确定性”的大前提下把原来需要人肉完成的取证、比对、关联工作自动化而不是真的让模型替你做测试决策。7. 给想复刻这套体系的人一个最小可跑建议如果你所在的团队也面临“测试报告全绿但线上真实业务偶发异常”的困扰想快速验证“只信证据”的思路是否可行不一定要一步到位整套 Agent。我建议先做一个小闭环先挑一个业务上最容易出问题的链路比如下单结算。用 pytest 写一个用例在用例里依次采三路证据Playwright 抓页面展示金额、直接调用结算接口拿后端返回金额、SQLAlchemy 查订单表落库金额。然后你不需要 LLM先在代码里写死一个断言三者等值时通过否则输出三路各自的实际值到报告里。跑一周看看能抓出多少原来漏掉的问题。如果确实抓出了几个“页面显示对、库里不对”或者“接口返回对、页面显示不对”的真问题再引入 LLM 层做自然语言任务拆解和工具编排把证据链逐步扩展到日志、回调、缓存更多来源。我最终做完这套东西之后的体会是测试的使命不是证明系统“看起来是对的”而是证明系统“事实上是对的”。AI 在这一行真正的价值不在于它多聪明而在于它能帮你把每个结论都钉在实打实的证据上。页面文本、接口返回、数据库状态、服务日志四方对得上那才是真的稳。对不上哪怕六个维度全绿也值得你半夜爬起来看一眼订单流水。

只信证据：基于LLM的测试Agent如何用证据链终结页面假绿

相关推荐

SpringBoot个人博客项目实战避坑指南

LLM工程实践：安卓8部署、LLM as Judge与AgentPoison防御

开源本地语音工作室：声音克隆+可视化工作流引擎

更多资讯

Path of Building PoE2 离线BD规划器从入门到实战

MCP薄封装争议背后：Agent连接架构重选与工具调用取舍

直播带货退潮后，普通人如何用AI实现效率套利

AI教材开发：知识图谱与大模型如何提升效率与降低查重率

GEO优化服务：短期流量与长期品牌的平衡策略

MongoDB Atlas 版本门禁实战：解决 Agent Engine 并发写入数据覆盖

今日更新

微信个人号API开发案例：图片/语音/视频消息怎么下载解析存到本地？

Python股票自动交易系统源码解析：从行情获取到风控的完整链路

视酷酷信IM源码部署指南：Java 17+MySQL 8.0.33实战配置

本周精选

防幻觉智能体架构：电源硬件设计中的大模型编排与工具化实践

OpenGL面试核心考点：渲染管线、矩阵变换与性能排查全解析

全国计算机二级C语言真题PDF高效刷题指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？