AI测试-08-AI测试平台怎么拆模型层工具层执行层和证据层

发表于 分类于 本文字数： 4k 阅读时长 ≈ 15 分钟

AI 测试平台最容易在第一阶段看起来很顺。

输入一句自然语言，模型理解任务，调用工具，跑出结果，再把结论写进报告。
从演示效果看，这条链路足够吸引人。

但只要平台开始进入真实测试场景，问题很快就会出现：

  • 模型输出不稳定，到底是谁来兜底
  • 工具一多，调用顺序越来越乱
  • 任务中断后，状态不知道该从哪一层恢复
  • 报告有结论，但没有足够证据支撑
  • 一次失败到底算模型问题、工具问题还是环境问题，难以收敛

这些问题的根因通常不是模型不够强，而是平台没有把边界拆开。

AI 测试平台如果把理解、执行、取证、收口都堆在一个模块里，短期可以跑通，长期一定会失控。
更稳的做法是明确拆出四层：

  • 模型层
  • 工具层
  • 执行层
  • 证据层

这篇文章只聚焦一个问题：AI 测试平台为什么要按这四层拆，以及每一层应该负责什么、不该负责什么。

一、为什么四层拆分是必要条件，不是架构美化

传统自动化平台里，脚本和执行引擎边界通常已经比较明确。
AI 测试平台不同，它引入了一个新的不确定因素：模型。

模型会带来两类变化：

  • 它能理解意图、补足上下文、规划步骤
  • 它也会误判、幻觉、越权、漂移

如果没有分层，平台就会出现三个典型后果。

1. 失败归因越来越混

例如一个任务失败，表面现象可能是：

  • 元素没点到
  • 接口没调通
  • 结果没收上来
  • 报告写错了

但真正根因可能分别来自：

  • 模型选错动作
  • 工具参数不对
  • 执行层状态断了
  • 证据层丢了关键结果

不拆层，失败都只能被归成“AI 不稳定”。

2. 平台越做越重，越改越脆

如果模型模块里直接塞：

  • 工具调用
  • 状态缓存
  • 重试逻辑
  • 证据写入
  • 报告生成

后面任何一个改动都会牵一片。
模型一升级、工具一增加、报告一调整，平台就会出现连锁回归。

3. 风险没有独立收口位置

AI 测试里的风险主要集中在：

  • 判断不确定
  • 步骤顺序错误
  • 工具越权
  • 结果收口失真
  • 证据不足却输出确定结论

这类风险如果没有单独层级收口，只靠提示词约束，基本不够。

所以四层拆分的价值不在“看起来更像架构图”，而在：

  • 让每一层都只做自己该做的事
  • 让失败可以定层归因
  • 让高风险动作有独立拦截点
  • 让证据和结论不再混在一起

二、模型层负责理解和规划，不负责直接执行

模型层是 AI 测试平台最显眼的一层，但不应该是最重的一层。

1. 模型层该负责什么

模型层更适合承担这些职责：

  • 理解任务意图
  • 结合上下文生成步骤建议
  • 选择候选工具
  • 组织输入输出语义
  • 对结果做摘要和说明

这一层的本质是：把自然语言任务收成结构化意图。

2. 模型层不该负责什么

模型层不适合直接负责：

  • 发起真实写操作
  • 持久化任务状态
  • 管理执行重试
  • 判断权限是否合法
  • 充当最终事实来源

原因很直接：

  • 模型擅长推理，不擅长强约束
  • 模型输出本质是概率结果，不是系统事实
  • 一旦让模型直接掌控执行和状态，失败会很难收口

3. 模型层更合适的输入输出

模型层的输入不应该是一段松散提示词，而应该至少包含：

  • 任务目标
  • 当前步骤状态
  • 环境信息
  • 工具白名单
  • 上一步执行结果
  • 当前证据引用

模型层的输出也不应该是自由文本，而更适合收成：

  • 下一步意图
  • 候选工具
  • 参数草案
  • 风险标记
  • 对结果的不确定性说明

这样做的目的不是限制模型发挥，而是让平台有地方接住模型输出。

三、工具层负责能力封装，不负责任务编排

工具层最容易被写成一堆零散函数。
短期看方便，长期会让平台越来越乱。

1. 工具层该负责什么

工具层更适合负责：

  • 统一工具接口
  • 参数校验
  • 权限校验
  • 执行前置检查
  • 标准化返回结果
  • 原始执行日志采集

这里的核心不是“把动作做掉”，而是把动作变成受控能力。

例如一个 call_api 工具，不应该只负责把 HTTP 请求发出去。
更完整的职责应该包括：

  • 校验当前任务是否允许访问这个接口
  • 校验环境和租户边界
  • 校验参数是否完整
  • 记录请求上下文
  • 返回标准化响应和错误码

2. 工具层不该负责什么

工具层不该直接承担：

  • 多步骤任务调度
  • 失败后的恢复编排
  • 任务级状态写回
  • 报告结论生成

否则工具层会慢慢演变成执行层，最后难以复用。

3. 工具层最关键的设计点

工具层至少要做到三件事：

  • 工具白名单和能力边界清晰
  • 参数和返回结构稳定
  • 同一个工具失败时有可识别错误分类

只有这样，执行层才知道下一步是该重试、该跳过，还是该转人工复核。

四、执行层负责状态机和失败收敛，不负责业务理解

执行层是最容易被忽略的一层，但它往往决定平台能不能长期稳定运行。

1. 执行层该负责什么

执行层更适合承担：

  • 任务拆步
  • 状态机推进
  • 超时控制
  • 重试策略
  • 中断恢复
  • 并发隔离
  • 结果收口

这一层要回答的是：

  • 任务现在跑到哪一步
  • 哪一步失败了
  • 失败能不能恢复
  • 该不该继续
  • 该不该终止

2. 执行层不该负责什么

执行层不适合负责：

  • 自己理解业务目标
  • 自己猜下一步动作
  • 自己生成结论文案

这类能力更适合留在模型层或证据层上方的报告层。

3. 执行层的关键是状态设计

AI 测试平台的状态不能只写：

  • 运行中
  • 成功
  • 失败

更实用的状态通常至少包括：

  • 待执行
  • 规划完成
  • 执行中
  • 等待证据
  • 待复核
  • 成功
  • 失败
  • 中断
  • 已回收

如果状态太粗，后面中断恢复和失败分析都会越来越难做。

4. 执行层怎么处理失败收敛

失败收敛至少要分三类：

  • 可重试失败：网络超时、临时资源不可用
  • 需复核失败：证据冲突、模型判断不确定
  • 必须终止失败：越权、环境错位、关键步骤失控

如果所有失败都统一重试，平台很容易把一次小问题放大成更大的现场污染。

五、证据层负责事实沉淀，不负责替代事实

AI 测试平台里最容易被压缩掉的一层就是证据层。
原因通常是它“不如模型效果直观”。

但真正进入生产级使用后，证据层往往比模型层更重要。

1. 证据层该负责什么

证据层更适合负责：

  • 保存原始执行结果
  • 保存截图、日志、请求响应、页面快照
  • 给每条证据分配引用 ID
  • 记录证据和步骤、任务、环境的关联关系
  • 提供可审计的回放入口

这一层的目标不是生成结论，而是保证：

  • 结论以后还能被验证
  • 失败以后还能被还原

2. 证据层不该负责什么

证据层不适合负责：

  • 代替模型做总结
  • 把原始结果压缩成一句成功或失败
  • 直接生成业务报告结论

证据层越“聪明”，越容易把事实和解释混在一起。

3. 证据层为什么必须独立

如果证据和结论混存，后面最容易出现两类问题：

  • 模型解释盖过原始事实
  • 报告可读性提高了，但可复核性下降了

AI 测试最怕的不是偶发失败，而是报告看起来很顺、后来却找不到证据。

六、四层之间的数据流应该怎么走

四层拆开后，最关键的是数据流不要乱。

一个更稳的基础链路通常是：

  1. 模型层读取任务上下文，产出下一步意图和候选工具
  2. 执行层接住这个意图，决定是否推进当前步骤
  3. 工具层校验权限和参数，执行真实动作
  4. 工具层把原始结果返回给执行层
  5. 执行层更新状态，决定继续、复核还是终止
  6. 证据层沉淀原始结果和引用关系
  7. 模型层在需要时只对结构化结果做解释，不覆盖原始事实

这条链路里最需要守住两条线：

  • 模型层不能绕过执行层直接调工具
  • 证据层不能被模型解释覆盖

只要这两条线守不住，平台很快就会变成“模型直接带着工具乱跑”。

七、最小可执行骨架

如果平台还在第一阶段，不需要一开始就做成大而全系统。
但至少应该先把下面这条骨架做出来。

1. 任务入口

  • 任务目标
  • 环境 ID
  • 允许工具白名单
  • 风险等级
  • 任务上下文初始化

2. 模型层输出

  • 当前步骤意图
  • 候选工具名
  • 参数草案
  • 风险提示
  • 不确定性标记

3. 执行层校验

  • 是否允许推进
  • 当前步骤状态是否合法
  • 是否命中中断或回滚条件
  • 是否需要转人工复核

4. 工具层执行

  • 参数校验
  • 权限校验
  • 工具调用
  • 返回标准化结果

5. 证据层写入

  • 原始响应
  • 关键截图
  • 日志片段
  • 步骤引用 ID
  • 审计字段

6. 执行层收口

  • 更新状态
  • 判断下一步
  • 生成阶段结果
  • 命中风险时终止或转复核

八、边界检查点

平台每增加一个新能力，都可以先用下面这组问题做边界检查。

1. 模型层检查点

  • 这项能力是不是必须由模型理解
  • 模型输出是不是结构化的
  • 模型有没有机会直接绕过规则层

2. 工具层检查点

  • 工具是否有清晰输入输出
  • 是否做了权限校验和参数校验
  • 返回结果是否能被统一收口

3. 执行层检查点

  • 任务状态是否可追踪
  • 中断后能不能恢复
  • 失败分类是否足够清晰

4. 证据层检查点

  • 关键步骤有没有原始证据
  • 证据是否可关联到任务和步骤
  • 模型解释是否覆盖了原始事实

只要其中一层回答不清，后面就容易出现“能跑，但不可信”的情况。

九、最容易拆错的几种方式

1. 把工具层写成执行层

表现通常是：

  • 工具自己决定重试
  • 工具自己推进下一步
  • 工具自己写任务状态

这样做的后果是：

  • 任务链路散在各个工具里
  • 出问题时找不到统一状态机

2. 把模型层写成万能控制器

表现通常是：

  • 模型自己挑工具
  • 模型自己改参数
  • 模型自己判断是否继续
  • 模型自己决定是否忽略失败

短期看自由度很高，长期会让越权和误判越来越难控。

3. 把证据层降级成附件仓库

表现通常是：

  • 只在失败时截张图
  • 日志没有步骤关联
  • 请求响应没有保存原文
  • 报告里只有摘要，没有证据索引

这会让平台在看板层看起来很完整，在复盘层几乎没有抓手。

4. 把执行层缩成一个简单队列

如果执行层只会“拿任务 -> 跑完 -> 返回结果”，那平台一旦进入：

  • 多步骤任务
  • 中断恢复
  • 风险拦截
  • 审计回放

就会明显吃力。

十、真实案例：一次 UI + API 混合任务为什么明明功能都成功了，平台还是判定架构有问题

场景

一个 AI 测试任务需要完成：

  • 打开订单页面
  • 确认页面展示已支付
  • 调只读接口确认订单状态
  • 生成截图和结论

平台第一版为了追求速度，把模型层和执行层混在一起实现。
模型直接决定下一步，也直接调用工具。

执行

任务跑通了，页面截图存在，接口也返回成功。
最终报告显示任务通过。

现象

后续回放时发现三个异常：

  • 截图里的页面状态来自缓存页面，不是本次操作结果
  • 接口结果来自上一次任务残留上下文
  • 平台无法确认是哪一步真正决定了“任务通过”

从表面上看，功能结果是对的。
但从平台角度看，证据链已经失真。

排查

拆链路后发现：

  1. 模型层没有只输出意图，而是直接带参数调用了页面工具。
  2. 执行层没有独立状态机，导致旧会话上下文继续被复用。
  3. 证据层只保存了最终截图，没有保存页面切换前后的步骤引用。
  4. 接口工具返回成功后，平台直接把结果写进报告，没有经过统一收口。

也就是说，这次任务不是“用例逻辑错了”，而是平台分层拆错了：

  • 模型层越界
  • 执行层缺位
  • 证据层过薄

修复

后续修复动作包括：

  1. 模型层只保留意图和参数草案输出，不允许直接调工具。
  2. 执行层补充步骤状态和会话隔离，任务切换时强制清空旧上下文。
  3. 工具层统一返回标准化结果和步骤 ID。
  4. 证据层把页面快照、接口响应和步骤引用强绑定。
  5. 报告层改成“先证据、后解释”的收口方式。

修完之后，任务速度有所下降，但平台开始具备可复盘、可审计、可恢复的基础能力。
对 AI 测试平台来说，这种变化比单次演示更重要。

十一、AI 测试平台真正要拆开的，不是技术栈，而是责任边界

AI 测试平台最容易在前期被误解成一个“把大模型接进自动化”的项目。
真正决定平台成熟度的，往往不是接入了哪种模型，而是有没有把下面这些边界守住：

  • 模型层只做理解和规划，不直接执行业务动作
  • 工具层只提供受控能力，不负责任务编排
  • 执行层只做状态推进和失败收敛，不替代模型理解
  • 证据层只沉淀事实，不覆盖事实

这四层拆清楚后，平台才有可能继续往下做：

  • 风险控制
  • 任务恢复
  • 审计闭环
  • 证据复用
  • 多模型接入

如果这四层一开始就混在一起，平台前面跑得越快，后面返工通常越大。
AI 测试平台真正需要优先搭好的，不是“更强的智能感”，而是能长期承受变化的工程边界。