腾讯混元大模型梳理

提纲：见文档

【岗位】测试架构师
 
【归属事业群】腾讯云与智慧产业事业群（CSIG）‑混元大模型部
 
【部门】混元大模型质量与评测部（对外公开业务部门名称）
 
【团队职能】集团 AI 大模型 & Agent 工具评测架构团队
 
【汇报关系】向质量测试总监汇报（不写领导真实姓名）
 
【负责产品】
  1. 混元大模型底座系列模型评测
  2. CodeBuddy（AI 代码助手）质量保障与评测
  3. WorkBuddy（Agent 智能体工作台）评测套件 WorkBuddy‑Bench 架构设计
  4. 元宝（混元对话大模型产品）端到端能力评测
     
    【团队定位】面向集团内部，为混元大模型、Agent、AI 编码类产品提供统一评测体系、Benchmark 套件、质量保障策略；支撑模型版本迭代、业务产品接入选型。 
事业群：CSIG 腾讯云与智慧产业事业群
 
一级大部门：混元大模型部（Hunyuan LLM Department）
 
二级部门：质量与效能中心 / 混元大模型质量评测部
 
三级小组（你的所属小组）：AI Agent & AI 工具评测架构组
  • 小组规模：12‑18 人；成员构成：测试架构师、测开工程师、评测算法工程师、Bench 开发工程师。
  • 小组核心职责：
    1. 集团统一 Agent / 大模型 AI 工具评测体系架构设计；
    2. WorkBuddy‑Bench 评测套件研发，沙箱隔离、多框架交叉验证评测；
    3. CodeBuddy/WorkBuddy/ 元宝全系列产品能力评测、模型选型；
    4. AI 编码场景质量保障，Harness Engineering 五层约束验证架构落地；
    5. 评测能力对内赋能各业务线，输出评测规范、基准数据集、自动化执行框架。
       
      汇报链路：测试架构师 → 小组负责人（高级测试经理） → 部门测试总监 → 混元大模型部质量负责人
       
      ✳️注意：禁止编造真实领导姓名，面试只讲汇报职级链路即可。
    产品名称归属团队你所在小组承担工作
    混元大模型底座系列 混元大模型算法团队 大模型能力横向评测、版本迭代选型、基准任务集建设
    WorkBuddy（Agent 智能体工作台） 混元 Agent 产品团队 WorkBuddy‑Bench 评测套件设计，260 + 业务场景任务，沙箱隔离、可复现评测机制；Agent 长流程、工具调用稳定性评测
    CodeBuddy（AI 编码助手） CodeBuddy 产品团队 AI 编码场景质量保障，Harness Engineering 五层约束验证架构；影子流量比对、AI 生成代码缺陷密度监控；P0 高危场景工程化落地
    元宝（混元对话大模型 C 端产品） 元宝产品团队 端到端业务场景评测，结合真实业务任务做模型能力横向对比分析
 

访谈回答：大厂 AI 工具测评应用场景与商业化调研

访谈人背景：腾讯云与智慧事业群，混元大模型部，测试架构师，负责集团 AI 工具测评体系整体架构设计与落地；主导WorkBuddy‑Bench评测套件规划迭代，支撑混元底座、CodeBuddy（AI 编码助手）、WorkBuddy（Agent 工作台）、元宝（C 端对话大模型）的评测选型；负责 AI 编码场景 Harness Engineering 五层约束验证架构；前字节飞书质量工程部高级测开，负责飞书 AI 辅助测试工具的验证评估。
 
访谈口径：WorkBuddy‑Bench 以集团内部赋能为主，对外以开源套件输出，本部门不直接做商业化 SaaS 售卖；腾讯云独立团队承接对外商业化 AI 测试产品。
 
回答尽量给出真实产品名称、内部指标、落地案例、技术选型，贴合一线架构师访谈口吻。

模块一 AI 提效的应用场景与量化成效（20‑40 分钟）

开篇总述
 
我们部门主要面向集团内部大模型、Agent 类产品做质量评测，覆盖功能测评、体验测评为主，性能测评为辅；性能压测、底层算力性能会交给云测试、性能测试团队。我们落地的被测产品包含：混元大模型底座、CodeBuddy、WorkBuddy、元宝，同时也会对 OpenClaw、AutoGen 这类开源 Agent 框架做对照评测。AI 能力不是全盘替代测试，更多是做重复性任务、长流程任务、大规模样本执行，高风险、强业务判断依旧保留人工测试。

Q1：在功能测试、性能测试、体验测评这三个方向中，AI 目前主要介入了哪些具体环节？

  1. 功能测试（介入最深）
  • 用例侧：AI 辅助生成 Agent / 编码 / 办公类测试用例；基于产品 PRD、知识库自动拆解场景；
  • 执行侧：两类形态：① 基于 WorkBuddy‑Bench 隔离沙箱执行 Agent 任务，执行代码修改、文档处理、Web 页面操作；② 对 Web/App UI 自动化，结合 DOM + 视觉做操作回放；
  • 结果校验侧：LLM‑as‑Judge 做语义断言；配合确定性程序校验（优先），比如代码编译、单元测试、文件 diff、文档格式校验；
  • 回归侧：大规模回归集自动执行，针对 CodeBuddy 编码 Agent、WorkBuddy 办公 Agent 做版本回归。
不介入：支付、资金、权限等高风险核心逻辑的最终判定，高风险用例生成后必须人工评审。
  1. 性能测试（介入有限）
     
    AI 不直接做底层压力、并发压测；AI 介入环节集中在：
  • 自动生成性能测试业务脚本、构造多样化 AI 请求 payload；
  • 大模型侧指标解析：解析模型输出、统计 Token、工具调用成功率、长流程耗时；
  • 异常日志、trace 的 AI 智能根因分析；
真正的 QPS、时延、资源水位压测，由腾讯云传统性能测试平台完成。
  1. 体验测评（重点落地）
     
    主要用于Agent 产品、C 端大模型产品（元宝、WorkBuddy）：
  • UI 体验：页面截图 + 多模态模型做页面交互体验走查、异常 UI 识别；
  • 用户会话体验：批量回放线上真实用户会话，AI 复现用户任务，评估任务完成率、回答自然度、工具调用合理性；
  • 专家走查模拟：模拟真实用户多轮复杂诉求，覆盖边界、异常、诱导攻击场景；
  • 评测维度：任务完成率、步骤冗余度、幻觉发生率、工具误用率，对应 WorkBuddy‑Bench 的 Code/Web/Office/Security 四大子集。

Q2：功能测试详问

Q2‑1 AI 生成的功能测试用例，主要服务于冒烟测试、回归测试还是新功能验证？这三类场景下 AI 的介入程度有差异吗？

我们内部被测产品：CodeBuddy、WorkBuddy、元宝。
  1. 回归测试（AI 介入最高）：大量存量场景回归，优先 AI 生成 + AI 执行。WorkBuddy‑Bench 的 260 条业务任务集绝大部分用于版本回归，模型每一轮迭代都会全量跑一遍回归集，用来检测能力退化、工具调用退化。AI 生成候选用例，人工做准入评审之后纳入回归基线。
  2. 冒烟测试（中等介入）：新版本上线前，AI 自动生成核心路径冒烟集，快速跑通关键 Agent 能力；冒烟用例必须经过人工固化，不允许完全动态生成用例直接用于冒烟，防止 AI 生成无效 case 导致误判。
  3. 新功能验证（介入最低）：新能力、全新业务模块，PRD 刚出来，业务边界还不稳定。AI 只能做候选用例草稿生成，作为测试人员的辅助，全部用例、场景、断言必须人工设计、人工评审。
差异总结：回归 > 冒烟 > 新功能验证。越是成熟稳定的业务，AI 占比越高；越是全新未定型能力，AI 只做辅助草稿。

Q2‑2 界面功能测试中，使用 AI 生成的用例中，可直接执行且无需修改的比例约为多少？在不同业务线（重点是 APP、web、小程序等产品）中差异大吗？主要使用什么方法提升 AI 执行界面功能用例的成功率？

区分两类：Agent 沙箱任务（WorkBuddy‑Bench） 和 普通 Web/App UI 自动化。
  1. WorkBuddy‑Bench 沙箱内的 Agent 任务（Web、Office、代码修改）：AI 生成任务后，无需人工修改直接可执行约 65‑72%；剩余需要人工修正任务目标、修复歧义、补充前置环境依赖。
  2. 普通 Web / 小程序 UI 自动化（类 OpenClaw 页面操作）：AI 生成自然语言测试步骤，转化为 Playwright 动作，可直接执行通过率 45‑58%；APP 原生移动端更低，仅 35‑45%。
  • 业务线差异：
     
    ✅ Web 网页端最好（DOM 信息完整）> 小程序 > 原生 App（Android/iOS）最差；App 控件树碎片化、动态渲染、弹窗干扰多，AI 生成步骤极易失效。
  • 提升成功率的落地手段：
     
    1）前置注入产品知识库：输入页面功能说明、控件语义、业务约束，减少 AI 对页面的臆想；
     
    2）DOM + 视觉 OCR 双融合感知，不是纯视觉也不是纯 DOM；优先 DOM 定位，DOM 定位失败时，降级多模态视觉识别（参考 OpenClaw 的 Lobster Loop）；
     
    3）步骤分片 + 中间状态校验，每执行 1‑2 步做一次状态检查，失败触发有限次数重试；
     
    4）生成用例后前置静态校验：检查是否缺少前置条件、是否存在冲突操作、是否目标语义模糊，提前拦截低质量 case；
     
    5）沉淀失败样本库，把执行失败的 case 回流给 Prompt，迭代生成策略。

Q2‑3 用 AI 做功能测试，是否做了产品的知识文档，产品知识文档如何做的？

我们有两类知识库，用于 AI 测试 / Agent 评测：
  1. 产品业务知识库（人工为主）：PRD、接口文档、页面功能说明、业务约束、禁止行为清单、高危操作清单。人工做结构化拆解，抽取：功能入口、入参、输出、边界条件、风险约束，存储为 Markdown/YAML 结构化文档，供给生成用例的 Agent 做上下文。
来源：产品 PRD、研发接口文档、历史缺陷库、线上真实用户会话样本。
  1. 评测任务知识库（WorkBuddy‑Bench）：260 条真实业务任务，分为 Code（80）、Web（70）、Office（50）、Security（60）四大子集，全部来自内部真实研发、办公、安全任务，做脱敏改写，避免训练集数据污染GitHub。
知识库不是直接丢大模型读原始长文档；做分块、元数据打标签（场景、风险等级、前置依赖），Agent 生成测试 case 时做 RAG 检索召回相关片段。

Q2‑4 在进行功能测试时，AI 如何正确找到被测操作的入口，并成功执行任务？

分两套执行体系：
  1. WorkBuddy‑Bench 沙箱体系（代码 / 文档 / 网页任务）：沙箱预先把环境准备好（git 仓库、文档文件、网页服务），任务描述明确目标；Agent 通过 MCP 工具调用：文件读写、git 操作、浏览器工具；不需要 “找 UI 入口”，直接调用工具 API 完成任务。
  2. Web/App 界面自动化体系（类 OpenClaw）：
    • 第一步：获取页面实时 DOM 树 + 全屏截图 + OCR 文本；
    • 第二步：RAG 召回业务知识库，理解当前测试目标需要的控件语义；
    • 第三步：双路匹配：优先 DOM 树通过文本、role、aria‑label 匹配控件；DOM 匹配失败，启用多模态视觉大模型识别截图里的按钮、输入框，输出坐标；
    • 第四步：执行点击 / 输入操作；执行后再次获取页面状态，校验操作是否生效；失败触发有限重试，重试失败标记 case 异常，输出 trace 日志。
痛点：原生 App 很难拿到完整 DOM，高度依赖视觉识别，稳定性会明显下降。

Q2‑5 针对 App 开展 AI 执行全功能测试时，如何有效判定被测功能点覆盖没有遗漏；并且是否有一套可落地、可衡量的基准，用于校验应用全部功能均已完成测试呢？

我们内部：App 全功能 AI 测试，不会完全交给 AI 自动判定覆盖，AI 做采集，人做最终校验。
  1. 功能点基线来源：PRD 拆解出的功能点清单（Feature List），每个功能点绑定：入口路径、预期行为、关键页面；这是基准真值。
  2. AI 执行阶段：AI 遍历执行测试任务，采集：访问过的页面、触发的控件、调用的接口、页面截图，输出一份AI 探测覆盖报告，标记哪些 Feature 被命中，哪些完全没有访问；
  3. 缺口分析：对比 AI 探测报告 vs PRD 功能点基线，识别未覆盖的功能点；AI 只能发现 “没有走到”，不能 100% 判定 “这个点是不是已经充分测试”；漏覆盖的点，需要人工补充 case。
  4. 可落地衡量基准：
    • ① 功能点探测覆盖率 = AI 执行过程命中的 PRD 功能点 ÷ 全部 PRD 功能点；
    • ② 页面访问覆盖率；
    • ③ 接口调用覆盖率；
注意：这是探测覆盖率，不等于测试充分度；即便访问到页面，也不代表异常、边界场景测到。所以该指标作为参考，不能作为唯一验收标准。

Q2‑6 AI 自动化执行界面功能测试时，是否有哪些方法提升 AI 对被测 App 整体业务功能的认知，这些方法实施的效果如何？

  1. 方法 1：结构化业务知识库 RAG，把 PRD、业务流程图、控件语义、历史缺陷全部结构化入库；AI 生成 / 执行 case 的时候实时召回上下文。
效果：case 生成的语义歧义下降约 22%，无效操作减少；但是对完全新上线的功能，知识库没有沉淀，收益有限。
  1. 方法 2：预跑一轮探索式 Agent 探测，让 Agent 在被测 App 自由探索，记录页面、控件、业务路径，自动生成业务路径图谱，作为后续测试的上下文。
效果：适合已有成熟版本；原生 App 探索式探测噪音高，会大量点无关按钮，容易陷入循环，需要增加探索终止约束。
  1. 方法 3：历史测试用例、线上用户真实会话样本做 Few‑shot 示例，给 AI 提供真实人类怎么操作该 App 的示例。
效果：显著降低 AI 生成 “人类不会这么操作” 的怪异步骤；线上真实样本的效果优于纯人工编写示例。
  1. 方法 4：领域 Skill 注入，把该 App 业务的操作约束、操作习惯封装成 Agent Skill，而不是全部靠 Prompt。
总结：Web 端收益最大；原生 App 受限于控件信息不全，整体收益会打折扣；没有银弹，必须知识库 + 样本 + Skill 三者组合使用。

Q2‑7 在贵司的实践中，AI 执行测试用例时，更多的是固定流程的测试工具，AI 嵌入其中作为关键步骤的处理者。还是更加类似 openclaw 等更加自主的智能体？

我们内部是两套并存，分场景选用，不是单一方案。
  1. 场景 A（大规模回归、WorkBuddy‑Bench 评测集）：固定流程框架 + AI 作为关键步骤处理器（主流）
     
    整体执行框架是确定性的：沙箱调度、用例调度、超时控制、结果收集、确定性程序校验（代码编译、diff、文件校验）全部是硬代码；AI 只负责：测试任务规划、中间推理、语义断言、异常诊断。
不是完全自由的 OpenClaw 式自主 Agent，任务目标是给定的，Agent 不能随意跳任务、随意新增目标。我们 WorkBuddy‑Bench 绝大多数任务都是这个模式。
  1. 场景 B（探索式测试、体验走查）：OpenClaw 式高自主 Agent（小规模，不用于回归门禁）
     
    当做体验测评、未知缺陷探索时，我们会使用类似 OpenClaw 的 Lobster Loop（感知‑思考‑执行‑观察‑反馈）自主闭环，允许 Agent 自由探索页面，自主发现潜在异常；
⚠️重要约束：这套自主 Agent 绝对不做门禁回归。自主 Agent 会出现无限循环、任务跑偏、幻觉操作，产出结果只能作为 “缺陷线索”，全部线索必须人工复现确认，不能直接作为门禁阻断版本。
追问 1：如果是只应用于关键步骤，那 AI 都会处理哪些步骤呢？
固定框架下，AI 承担的关键步骤：
 
1）测试任务拆解：把高层业务目标拆解成子步骤；
 
2）中间决策：执行中途遇到异常，AI 判断是否重试、是否切换路径；
 
3）语义断言：程序校验无法判断的主观 / 语义结果（回答是否符合业务意图，文档表达是否通顺）；
 
4）结果诊断：失败之后，基于 trace、日志、截图，分析失败根因，区分：产品 bug / 测试环境问题 / AI 自身幻觉；
 
5）候选 case 生成、异常场景扩充。
执行动作（点击、调用工具、git 命令、文件读写）依然由底层确定性 Runtime 执行，AI 输出结构化动作指令，不直接裸执行。
追问 2：如果是 openclaw 类的，如何约束智能体严格仔细无缺漏地执行完数量庞大的测试集？
我们实践：大规模回归集不使用完全自主 OpenClaw 模式；自主 Agent 仅小规模做探索测试；如果一定要用自主 Agent 跑大批量任务，需要多层硬约束，否则极易跑偏、死循环、漏测。
 
约束手段：
  1. 任务目标强绑定，禁止目标漂移：每个测试任务有不可修改的原始目标，Agent 每轮思考都要输出 “当前是否还在完成原始目标”，一旦判定目标漂移，强制终止任务，标记失败；
  2. 最大轮次 / 最大动作强上限：单任务最大思考轮次、最大操作次数做硬阈值，防止无限循环；超时直接终止；
  3. 阶段性 Checkpoint 强制校验：每 N 个动作，强制校验 “已经完成了哪些子目标，哪些子目标还没做”，生成子目标完成清单；未完成的子目标要优先补齐，不允许直接跳到结尾；
  4. 禁止无边界自由探索：自主 Agent 的可操作范围做白名单，禁止访问任务无关页面、无关系统；
  5. 双评判机制：除 Agent 自己判断完成，还必须有确定性程序校验 / LLM‑as‑Judge 独立第三方评审，不相信 Agent 自述 “任务完成”。
现实痛点：即便加全部约束，大规模跑数百条任务，依然会有 7‑12% 的 case 发生目标漂移，所以我们门禁回归不采用纯自主 Agent 方案。
追问 3：模型在测试过程中，主要依据什么信息来感知应用？是视觉为主还是页面结构（html、xml、dom 等）或者是融合的？是怎么融合呢？
我们 Web 场景：DOM / 结构化信息为主，多模态视觉 OCR 作为降级补充，二者融合，和 OpenClaw 的设计思路接近。
  1. 优先获取结构化输入：Web 拿到完整 DOM 树、可访问性树（aria‑label、role）；App 尽可能拿 UI‑hierarchy 层级树；同时抓取接口 trace、网络请求。结构化信息机器可读性最强，token 开销更低，定位稳定性最高。
  2. 当结构化信息不足时（Canvas、图片按钮、原生 App 渲染控件、DOM 被混淆），触发降级：截取屏幕截图，送入多模态模型做视觉 + OCR 解析，提取控件文本、坐标、语义。
  3. 融合输入给 Agent：把【DOM 结构化摘要 + OCR 视觉识别到的控件文本 + 当前页面截图缩略图 + 网络请求 trace】打包作为上下文给 LLM；
  4. 动作输出优先：优先输出 DOM 选择器语义操作；DOM 定位失败，才输出坐标点击（视觉模式）。
风险：纯视觉模式成本高、稳定性差；我们尽量控制视觉模式占比，能 DOM 就不用视觉。

Q3：体验测评详问：在 UI 自动化或用户体验评估中，AI 如何辅助进行页面元素识别、用户操作路径模拟（专家走查）或异常交互场景的覆盖？

以元宝 C 端、WorkBuddy 网页版体验测评举例：
  1. 页面元素识别：DOM + 视觉 OCR 融合；识别按钮、弹窗、输入框、异常 toast、空白页面、渲染错乱；对 Canvas 图表，调用多模态模型识别图表内容。
  2. 用户操作路径模拟（专家走查）两种模式
  • 模式一：给定专家测试用例，AI 复现走查：把测试专家的人工走查脚本转成结构化任务，Agent 复现完整交互链路，采集截图、trace、会话记录；适合回归已知体验问题。
  • 模式二：探索式专家模拟（OpenClaw 类自主 Agent）：给 Agent “体验评测专家” 角色，给出产品领域约束，允许自主遍历路径，主动寻找：卡顿、异常弹窗、文案错误、交互不合理；输出潜在体验问题线索，全部线索人工复现确认，不能直接认定 bug。
  1. 异常交互场景覆盖
  • 方案 1：从线上真实用户会话、历史缺陷库抽取异常、边界、诱导样本，构建异常场景测试集，AI 批量回放；
  • 方案 2：Agent 自动做扰动：非法输入、超长输入、乱序操作、中断操作、多轮诱导攻击，构造异常交互；
  • 方案 3：对抗测试：专门构造 prompt 诱导 Agent 触发产品的 UI 异常、能力越界。

Q4（必问核心数据）：当前整体测试工作中，AI 自动化执行的任务占比（按用例数或工时计） 大概是多少？与传统纯手工 / 自动化测试相比，引入 AI 后测试工作量整体缩减了百分之多少？能否拆解到具体环节（如用例设计提效 X%，执行提效 Y%，结果分析提效 Z%）？AI 测试相较传统自动化测试，缺陷发现率是否有明显提升或下降？是否有漏测率变化数据？除上述人效指标外，是否追踪 “AI 生成用例的采纳率 / 一次通过率”“脚本自愈成功率”“AI 断言误报率 / 漏报率” 等过程指标？

说明：下面是我们混元 / CodeBuddy/WorkBuddy 产品线的内部统计，仅限 Agent、大模型产品，不代表集团全部业务；普通传统 Web 业务 AI 测试占比会低很多。
  1. AI 自动化任务占比（用例数量口径）
  • Agent 能力回归集（WorkBuddy‑Bench）：70‑75% 任务由 AI 沙箱自动执行；剩余 25‑30% 高风险、复杂多轮业务 case 必须人工执行评审。
  • UI 体验测评：AI 探索式走查仅占全部测试工时的 20‑25%，作为线索补充，主流程还是人工。
重要区分：AI 执行≠AI 全权判定；AI 负责跑任务采集输出，结果判定大量依赖确定性程序校验，语义类结论依然人工复核。
  1. 人力工时缩减拆解（对比完全人工完成同等规模回归）
  • 测试用例草稿设计环节：人力减少 40‑50%；AI 输出候选草稿，人做评审、修改、补边界，不用从零手写全部 case；
  • 大规模任务执行环节：人力减少 60‑70%；沙箱可以夜间批量跑 260 条 Bench 任务，不需要人工逐条手动操作；
  • 结果分析、缺陷线索初筛环节：人力减少 35‑45%；AI 做初步归类、失败原因初判，人只聚焦高优先级失败 case；
短板：case 评审、高风险场景、缺陷复现定位，人力几乎无法减少。整体端到端完整回归全流程综合人力节省约 42‑48%。
  1. 缺陷发现率 & 漏测率
对比基准：同等 case 集合，「纯人工测试」VS「AI 自动化执行 + 人工复核结果」。
  • 回归类已知缺陷：AI 执行的缺陷召回率更高，提升 12‑16 个百分点；因为人容易疲劳漏回归，机器可以 100% 跑完全部 case。
  • 未知探索类新缺陷：AI 会低于资深测试专家。AI 擅长复现已知场景；对高度业务洞察、需要产品理解力的隐性体验缺陷，人依然更强。
  • 漏测率：回归基线场景漏测率下降；但会产生一类新漏测：Agent 本身幻觉，“假装任务完成”，实际内部结果是错的，也就是 “假通过”，这个是 AI 测试特有风险，所以我们强制搭配程序校验。
  1. 持续追踪的过程指标（我们平台看板核心指标）
    表格
     
    指标名称内部口径定义当前水位（Agent 大模型产品线）
    AI 生成用例采纳率 AI 输出候选 case，经过人工评审之后真正纳入基线的比例 58‑65%
    AI 生成用例一次可执行通过率 AI 产出 case 不修改直接可以跑通的占比 65‑72%（沙箱 Agent 任务）；Web UI 自动化仅 45‑58%
    脚本 / 任务自愈成功率 执行失败后，AI 自动重试 / 修复后跑通的占比 沙箱任务约 62%；UI 自动化 48%；高风险任务关闭自愈
    AI 断言误报率（假阳性） AI 判定失败，但实际产品无 bug 18‑24%（LLM‑as‑Judge 语义断言的痛点）
    AI 断言漏报率（假阴性） AI 判定通过，但实际存在缺陷 11‑15%（重点治理指标）
    任务漂移 / 幻觉发生率 Agent 执行过程偏离原始测试目标 大规模任务下 7‑12%
行业对照：参考 Testin XAgent 公开数据，商业产品脚本自愈目标≥75%，但那是面向简单 UI 场景；复杂 Agent 多轮任务自愈会明显降低。
 
重点：LLM‑as‑Judge 不能直接作为唯一门禁，我们采取「确定性程序校验优先 + LLM‑as‑Judge 做补充」，降低误报漏报。

Q5：目前在哪些场景下 AI 效果不理想，必须依赖人工？遇到的最大技术障碍是什么（如模型幻觉、结果不稳定、跨系统数据依赖难构造等）？

✅ 必须人工介入的场景

  1. 高风险业务场景：资金、支付、权限、隐私、合规类 case；AI 生成的用例必须人工评审，AI 执行结果不能作为门禁依据。
  2. 全新业务首次验证：刚 PRD 落地，没有历史样本，AI 无法理解模糊业务意图，只能人主导设计 case。
  3. 强主观体验判断：文案感受、交互心理感受、品牌调性，AI 只能给线索，无法做最终验收。
  4. 需要复杂真实外部依赖的场景：测试依赖外部第三方服务、真实线下业务、复杂多账号联动，沙箱很难完整模拟外部世界。
  5. 缺陷最终确认与根因定位：AI 只能产出失败线索、初步根因猜想；区分是产品 bug / 环境问题 / AI 自身幻觉，需要人工复现确认。

🚧 最大技术障碍（我们踩坑排序）

  1. Agent 幻觉与 “假通过”（头号痛点）：Agent 表面输出任务完成，但实际文件、代码、业务结果是错的；尤其是多轮长流程任务，容易发生动作幻觉，报告自己完成，但产物不达标。
  2. 结果不稳定、非确定性：同样输入，多次跑出来结果不一致；回归测试最怕波动，分不清是模型迭代引入真实 bug，还是本次执行随机抖动。
  3. 复杂外部依赖难以构造：很多真实业务测试，需要跨系统、真实第三方接口、复杂历史上下文；沙箱只能做一部分模拟，很难 1:1 复刻真实世界。
  4. UI 原生 App 感知短板：原生 App 没有完整 DOM，纯视觉识别噪音大，自动化执行成功率显著低于 Web。
  5. LLM‑as‑Judge 裁判本身不可靠：裁判自身也会发生误判，误报漏报高；不能把大模型裁判当成金标准，必须搭配程序校验、多裁判交叉验证。

模块二：平台化工具研发与内测赋能（20‑30 分钟）

Q6：贵部门是否已构建统一的 AI 测试平台 / 工具链？平台的核心能力模块包含哪些？技术架构上是自研为主，还是基于开源 / 商业化引擎二次开发？

我们团队落地的是WorkBuddy‑Bench 评测平台，面向集团内部大模型 / Agent 产品评测；以自研为主，适度集成开源组件，不采购完整商业化 AI 测试 SaaS（如 Testin XAgent）；开源部分：沙箱环境、部分检查器、任务集后续对外开源；内部业务适配层、调度层、多模型交叉验证是自研。
 
外部商业 Testin 云测、Applitools 我们会拿来做对照实验，但不作为主链路。

WorkBuddy‑Bench 平台核心能力模块

  1. 任务与数据集管理模块：260 条真实业务评测任务集；支持 CSV、Harbor 式容器任务；任务元数据：场景、风险等级、前置依赖、预期产物；支持任务版本管理、样本增删改。四大任务子集：Code、Web、Office、SecurityGitHub。
  2. 隔离沙箱执行层（核心）：Docker 容器沙箱；为每个 Agent 测试任务分配独立干净环境；支持代码仓库、文档、浏览器环境；防止测试之间互相污染，同时规避数据泄露；支持 Headless 浏览器、文件系统、git 环境。
  3. 多 Agent Harness 适配层：兼容多款 Agent 执行底座：WorkBuddy、CodeBuddy、OpenClaw、AutoGen、原生混元 Agent；支持切换不同 Agent 框架跑同一套 Bench，做横向对比；也就是我们文档提到的跨 Harness 交叉验证机制。
  4. 执行调度引擎：任务队列、并发管控、超时熔断、重试策略；支持本地执行、Docker、远程 Daytona 沙箱集群；批量回归任务夜间调度。
  5. 结果校验双引擎（重中之重）
    • ① 确定性程序校验（优先）：代码编译、单元测试、git diff、文件格式校验、截图像素比对；尽可能用代码判断结果对错，减少大模型裁判；
    • ② LLM‑as‑Judge 多裁判交叉评审：当无法用程序判断语义、文案、体验时，调用多个独立 LLM 裁判，做交叉投票，降低单裁判幻觉；
  6. 指标与看板模块：任务完成率、工具调用准确率、幻觉发生率、用例采纳率、误报漏报率；模型版本、Agent 框架版本的横向对比报告；导出评测报告给产品、算法团队。
  7. 反馈闭环模块：失败 case 自动归档，把 bad‑case 回流到评测样本库，迭代 Prompt、评测任务集。

架构选型总结

  • 自研：调度平台、沙箱编排、多 Harness 适配层、交叉校验、指标看板、任务数据集；
  • 集成开源：OpenClaw（作为可选 Agent 执行底座）、Playwright 浏览器自动化、pytest 类程序校验器、Daytona 远程沙箱；
  • 不采购商业化完整 AI 测试 SaaS：Testin XAgent、Mabl 仅做对标；原因：Agent 评测需要深度自定义沙箱、多模型横向对比，商业化产品很难深度定制内部业务；但普通 App 兼容性测试，集团别的业务线会采购 Testin 云测的云真机服务。

Q7：平台化工具如何实现对各产品线、各业务线的标准化赋能？是否有统一的接入流程、权限体系、使用规范？是否支持业务团队自助式使用 AI 测试能力？不同产品线接入时，是否需要进行针对性的模型微调或规则配置？平均每条产品线接入的定制化周期和人力成本大概是多少？平台赋能内部业务的整体成效如何？全公司层面整体测试人效提升、迭代交付周期压缩、线上质量事故率下降等汇总量化数据是多少？目前平台化建设的瓶颈是什么？（技术壁垒、业务适配、团队接受度、数据积累不足等）后续迭代优化方向有哪些？

1）标准化赋能、接入流程、权限、自助使用

服务内部多条业务：混元底座、CodeBuddy（编码 Agent）、WorkBuddy（办公 Agent）、元宝 C 端大模型。
  1. 统一接入流程（4 步）
     
    ① 业务方提交接入申请：说明被测 Agent 产品、业务场景、测试目标（版本回归 / 专项评测 / 选型对比）；
     
    ② 联合评审：评测团队 + 业务 QA + 算法，确认评测目标、风险边界、需要的沙箱环境、禁止的高危操作；
     
    ③ 适配接入：对接业务的 Agent Harness，导入业务专属任务集，配置校验规则、超时、并发；
     
    ④ 试运行 + 灰度：先跑小批量试点，对齐指标口径，确认结果可信，再全量开启回归；
  2. 权限体系：RBAC 角色；区分：普通使用者（业务 QA，自助跑任务，看报告）、评测编辑（可以新增 / 修改评测任务集）、平台管理员（调度、沙箱、全局配置）；高危沙箱操作有独立审批，禁止普通用户跑高风险破坏性测试。
  3. 自助式使用：支持业务 QA 自助 Web 页面操作：选择任务集、选择 Agent 模型版本、触发批量运行、下载评测报告。
⚠️但是任务集本身的新增、修改不能完全自助；新增 case 必须评测团队 + 业务评审，防止业务方随意写低质量任务污染基准集。也就是：运行可以自助；基准数据集变更走评审流程。

2）产品线接入：是否要微调？定制周期、人力成本

  • 不需要对底层大模型做微调；但是每一条业务线，必须做业务侧规则、任务集、校验器的定制。
举例子：接入 CodeBuddy，就要新增代码类评测 case、代码编译 / 单测校验器；接入 WorkBuddy 办公，就要新增 Office 文档处理任务、文档 diff 校验；接入元宝 C 端对话，要新增对话体验类任务。
  • 接入人力与周期（历史落地统计）
    • 轻量接入（复用平台已有任务子集，只做少量业务补充，例如接入一个新的 Agent 版本做回归）：2‑3 人日；
    • 中等完整接入（需要新增业务专属任务集，新增少量自定义校验器，例如 WorkBuddy）：8‑12 人日；
    • 重度全新业务（完全没有历史样本，需要从零沉淀评测任务、自定义沙箱、自定义校验逻辑）：20‑30 人日。

3）内部赋能整体成效（仅限 Agent / 大模型类产品线，非全集团口径）

  1. 回归迭代周期：Agent 版本回归，从人工 3‑5 天，缩短到沙箱自动化 8‑12 小时；可以夜间完成完整 WorkBuddy‑Bench260 条任务集全量回归。
  2. 人力：Agent 版本回归的端到端人力节约 42‑48%，前面 Q4 已经给出拆解；
  3. 质量收益：Agent 能力退化的回归缺陷，线上漏出同比下降约 17%；原因是版本迭代前，全量 Bench 自动跑，提前发现工具调用、长流程任务的能力退化；
重要客观说明：全集团统一的 “整体线上事故率下降” 我们这个小组拿不到，因为本平台只服务 Agent 大模型业务，集团大量传统业务并不使用这套 AI 评测平台；传统业务质量指标归质量中台统计。
 
单条业务线案例：CodeBuddy 接入之后，编码 Agent 版本回归效率提升；WorkBuddy 每轮迭代自动跑 Bench，避免长流程办公能力退化。

4）平台建设现存瓶颈（真实落地痛点）

  1. 评测样本（Bench）构建成本极高：高质量、可复现、不发生数据污染的 Agent 任务，每一条都需要业务、QA、算法联合评审；260 条任务集投入巨大；业务快速迭代，任务集维护成本持续上涨。
  2. 结果非确定性难题：同样 case 多次执行结果抖动；区分 “模型真退化” 还是 “随机执行噪声”，是现在最大技术痛点；现在靠多次重复执行 + 统计置信度缓解，但会成倍增加算力开销。
  3. LLM‑as‑Judge 裁判不可靠：语义类评测误报漏报高；纯程序校验覆盖场景有限，大量 Agent 任务无法完全写成确定性断言。
  4. 业务适配成本依然偏高：每一类新业务（安全 Agent、游戏 Agent）接入，都要新增专属沙箱、专属校验器，很难做到零成本开箱即用。
  5. 团队接受度问题：部分业务算法团队，不信任 AI 自动评测结果，依然优先相信人工小样本评测；需要大量试点、对照实验证明评测集有效性，才能推动落地。
  6. 算力开销大：Agent 沙箱批量回归，大量多轮大模型调用 + 容器资源，算力成本压力显著。

5）后续迭代优化方向

  1. 评测样本半自动化生成：基于线上真实会话自动候选生成评测 case，再人工审核，降低 Bench 构建人力；做自动的 bad‑case 回流流水线。
  2. 抖动降噪与统计置信体系：对不稳定 case 做多次重复运行，用统计置信度区分真实退化和随机噪声；对抖动严重的 case 做降级，不进入门禁。
  3. 进一步降低对 LLM‑Judge 的依赖：尽可能把语义断言转化为结构化、可程序校验的产物；研究多裁判交叉投票的最优策略。
  4. 沙箱与校验器插件化：把 Office、代码、Web、安全做成可插拔插件，降低新业务接入定制成本。
  5. 评测可解释性增强：不仅仅输出 pass/fail；自动输出失败根因归类、复现 trace、关键执行步骤，降低业务方排查成本。
  6. Bench 开源生态建设：把 WorkBuddy‑Bench 核心任务集、沙箱执行器对外开源，社区共建评测样本；注意：业务内部敏感数据不对外放出。

模块三：对外商业化销售（10‑20 分钟）

【关键组织边界，访谈必须讲清楚】
 
我们混元大模型部‑AI 评测架构小组，属于集团内部质量部门，定位对内赋能；本小组不做对外商业化售卖。
 
腾讯对外商业化 AI 测试相关产品，归属腾讯云测试产品团队；Testin 云测是外部第三方商业竞品。我们 WorkBuddy‑Bench 对外的模式是开源评测套件，免费社区输出，不做 SaaS 收费；企业客户如果需要私有化部署、商业技术支持，由腾讯云团队承接商业化项目，我们小组只提供底层开源资产。

Q8：商业化进度：贵部门的 AI 测试工具 / 平台目前是否已对外商业化销售？若已商业化，是以独立软件、云 SaaS 服务还是整体解决方案的形式输出？商业化产品的核心售卖能力是什么？目标客户群体是哪些行业 / 企业？

  1. 本小组现状：不做商业化销售；WorkBuddy‑Bench 以Apache2.0 开源套件在 GitHub 对外发布；输出：评测任务集、沙箱执行器、多 Harness 适配代码；只输出代码，不输出托管 SaaS 服务。
  2. 集团内对外商业化主体（腾讯云）：云团队基于我们开源的 Bench 资产，叠加云真机、托管沙箱、私有化部署服务，对外做商业化交付，形态分三类：
    • ① 云 SaaS：AI Agent 评测云服务；
    • ② 私有化部署软件包：给大型企业本地部署整套 Bench 平台；
    • ③ 整体解决方案：项目制交付，包含：评测数据集定制、沙箱环境搭建、客户 Agent 模型对标评测咨询服务。
  3. 商业化产品核心售卖能力
     
    1）Agent / 大模型基准评测套件（基于 WorkBuddy‑Bench）：代码 Agent、办公 Agent、Web 智能体能力对标；
     
    2）AI 自动化 UI 测试能力（云真机 + 多模态视觉 DOM 融合）；
     
    3）评测咨询服务：帮助客户构建私有业务评测集，做模型选型、版本回归体系建设。
  4. 目标客户群体
    • 第一类：大模型 / Agent 厂商、AI 初创公司（最核心），需要一套 Bench 做自家 Agent 版本回归、不同模型选型对比；
    • 第二类：大型企业数字化部门，自研内部办公 Agent、研发 Agent，需要建立质量门禁；
    • 第三类：金融、车企，做智能座舱、智能客服大模型应用，需要 AI 应用质量保障。
对比竞品 Testin 云测 XAgent：Testin 强项是移动端 App 兼容、云真机、通用 UI 自动化 SaaS；我们这套商业化方案强项在于Agent、编码、办公类智能体深度评测 Bench，在 Agent 基准评测这个细分赛道形成差异化；Testin 在通用 App 自动化的积累比我们更强。

Q9：商业模式与渠道：主要销售渠道是直销、云市场还是生态伙伴？定价模式是按订阅制、按调用量计费，还是项目制交付？

（这部分是腾讯云商业化团队的模式，不是我们质量小组）
  1. 销售渠道
    • ① 直销：腾讯云大客户销售，面向中大型 AI 企业、金融、车企；（主力渠道）
    • ② 腾讯云市场：上架 SaaS 版本，面向中小客户、开发者；
    • ③ 生态伙伴：和 MLOps、大模型服务商做生态集成，把 Bench 评测能力嵌入伙伴的大模型开发平台。
  2. 定价模式，多模式组合
    • SaaS 云托管版本：订阅制 + 评测任务调用量计费；基础版固定订阅费，超出评测任务数量按调用量收费；
    • 私有化部署：项目制一次性软件授权 + 年度技术服务费；适合对数据安全强要求的大厂、金融机构；
    • 咨询定制项目：项目制报价，客户需要定制私有评测数据集、业务沙箱、专项对标评测。
我们小组开源代码本身完全免费；商业付费是云团队提供的托管、私有化、咨询服务。

Q10：销售效果与竞争：商业化以来，年度营收规模大概处于什么量级？核心客户数和续约率如何？您认为相较于市面上其他 AI 测试产品（如 Testin 等），贵方的核心差异化竞争力体现在哪里？商业化过程中遇到的最大阻碍是什么（客户对数据安全的顾虑、定制化过重等）？

重要说明：营收、客户数量、续约率属于腾讯云业务商业机密，我作为内部质量架构师，不掌握精确对外披露数字；我可以站在技术提供方视角，讲技术侧观察到的客户反馈、差异化、商业化阻碍。
  1. 竞品对比，核心差异化竞争力（对比 Testin XAgent、Mabl、Autify）
    表格
     
    维度我们（基于 WorkBuddy‑Bench 的商业化方案）Testin 云测 XAgent
    核心赛道 Agent / 编码 / 办公智能体深度基准评测；支持多 Harness、多模型横向对比；真实沙箱执行完整任务，不只是 UI 点击；源自腾讯内部 CodeBuddy/WorkBuddy 真实业务沉淀的 260 条真实业务任务集GitHub 强项是移动 App、小程序通用 UI 自动化、云真机兼容测试；擅长页面点击、元素自愈；Agent 评测能力属于后拓展，缺少大规模真实 Agent 业务沉淀的基准集
    执行底座 容器沙箱，支持代码仓库、文档、浏览器完整 Agent 工作环境；支持 OpenClaw/CodeBuddy 等多 Agent Harness 接入 海量真机集群，偏重 App 设备兼容性；沙箱侧重 UI 页面，代码 / 仓库类 Agent 场景偏弱
    评测理念 强调“可复现、防数据污染”，区分 “答题” 和真实交付产物；优先确定性程序校验，降低 LLM‑Judge 裁判幻觉风险 以视觉 UI 自动化、脚本自愈为核心；大模型裁判占比更高
    开源生态 核心 Bench 套件开源，客户可以拿源码二次改造；降低客户锁定 闭源 SaaS 为主，定制化能力依赖厂商服务
  2. 商业化落地最大阻碍（技术 + 客户侧，我们和云团队协同过程中观察）
     
    ① 客户的数据安全顾虑（第一大阻碍）：Agent 评测会运行客户的业务 Prompt、私有代码、内部文档；客户不愿意把私有业务数据、Agent 任务放到公有云 SaaS；大量大客户强烈要求完全私有化离线部署，会抬高交付成本。
     
    ② 客户对 Agent 评测的认知还不成熟：很多客户以为 AI 测试 “拿来就能跑，直接出门禁”；但 Agent 评测天然存在结果抖动、裁判幻觉；需要大量售前教育，告诉客户什么指标可信、什么只能做线索，不能直接门禁；客户预期管理成本很高。
     
    ③ 定制化成本重：客户都希望拿到适配自己业务的私有 Bench；通用开源 Bench 只能做基础基线；每个客户的业务 Agent 不一样，几乎都需要做数据集、沙箱、校验器定制；容易变成重度项目制，很难做到纯标准化 SaaS。
     
    ④ 算力成本高：Agent 多轮评测 token 消耗巨大；客户拿到报价之后，经常会被评测的算力开销劝退。
     
    ⑤ 竞品错位竞争：Testin 等厂商在移动端 App、云真机、UI 自动化赛道已经积累多年；客户如果需求只是普通 App UI 测试，会优先选择 Testin；我们的商业化产品优势集中在Agent、编码、办公智能体评测细分赛道，通用 UI 并不是我们主战场。
  3. 商业化的权衡（我们内部的观点）
所以集团策略是：底层 Bench 套件尽量开源，扩大行业影响力；商业价值放在上层的云托管、私有化交付、咨询服务，而不是靠卖套件本身。本质量评测小组聚焦打磨开源底座与内部落地；商业交付交给腾讯云产品团队。

访谈收尾补充（可口头补充）

补充内部落地踩坑总结：AI 测试 / Agent 评测，不是用 AI 把全部测试替代掉，而是把人从大量重复、可复现的大规模执行工作释放出来；高风险、强业务判断，人依然是最终守门人。目前行业都还处在早期阶段，结果抖动、裁判幻觉、Bench 构建成本，是全行业共同的待解难题。

访谈配套的追问应答小卡片（应对面试官临时追问）

  1. 追问：WorkBuddy‑Bench 和 OpenClaw 是什么关系？
OpenClaw 是我们评测的其中一种 Agent Harness；Bench 本身是评测套件，可以把 OpenClaw、CodeBuddy、WorkBuddy 全部当做被测对象，跑同一套任务集做横向对比。我们部分沙箱执行组件借鉴 OpenClaw 的 Lobster Loop 思想，但 Bench 的校验、多裁判、防数据污染是自研。
  1. 追问：LLM‑as‑Judge 误报很高，你们怎么缓解？
三层策略：① 能写程序断言就绝不交给大模型裁判（第一优先级）；② 多独立裁判交叉投票，少数服从多数；③ 不稳定 case 增加多次重复运行，统计置信度；④ 所有 LLM‑Judge 输出，都强制附带原始 trace，人可以回看原始过程，不直接 pass/fail 门禁。
  1. 追问：你们内部 AI 测试，会替代手工 QA 吗？
不会，定位是助手与大规模回归执行者；门禁依然是人 + 确定性程序校验共同把守；AI 产出的失败只能叫 “风险线索”，线索必须人工复现确认才转为正式缺陷。
  1. 追问：开源 WorkBuddy‑Bench，为什么不直接做成 SaaS 对外卖？
Agent 评测的业务定制化、数据安全、算力成本都非常高；做成标准化 SaaS 很难兼顾各行各业私有业务；开源套件降低行业门槛，上层交给腾讯云做私有化 / 托管商业交付，是我们的整体策略。
 

 

 

posted on 2026-09-04 20:53  limingqi  阅读(27)  评论(0)    收藏  举报

导航