Agent驱动的智能化测试_从辅助到自治-2026-上海站_QECon全球软件质量效能大会-橙柚科技

优惠倒计时

8折票抢购中

团购享更多优惠

北京站 · 10月16-17日

上海站 · 9月4-5日

深圳站 · 5月22-23日

专场：Agent 驱动的智能化测试：从辅助到自治

测试是智能体落地最成熟的场景。完整拆解 AI 测试演进链路：从 AI 辅助生成测试用例、Agent 自主执行测试、自主研判结果到自主闭环修复，落地 LLM 赋能下测试左移、测试右移一体化自治测试体系，输出覆盖需求到上线全流程的智能化质量落地实践。

专场出品人：高凯（花名：岑坚）

淘天集团营销技术质量负责人高级测试开发专家

淘天集团营销技术质量负责人，高级测试开发专家，2010年校招入职阿里，深耕电商质量工程16年。连续8届担任双11、618集团业务质量负责人（PTM），协调35+BU保障大促业务确定性；从0到1构建大促预演平台并推动SAAS化，打造"未来版淘宝"实现体验确定性前置。《阿里测试之道》联合作者。

近两年，带领团队全面转向AI原生质量工程，完整经历了专题所述的演进链路：从AI辅助用例生成与代码评审（测试左移），到数字员工自主执行会场验收、端智能路径规划（Agent自主执行），再到AI驱动的结果分析与问题定位、AI值守自主修复（测试右移）。大促端到端执行效率、深度超10倍提升，营销域验收人力投入降低80%，AI值守准确率、稳定性99.9%。同时定义了面向营销业务的智能体评测方法论，构建营销标准评测集，推动"AI评测AI"的新范式落地。

程瑾

快手海外质量团队负责人

现负责海外直播短视频质量保障团队，主导测试领域 AI 能力建设，包括服务端智能化测试、GUI Agent 智能测试、AI 模型及 Agent 评测体系等方向，应用过往AI从业经验，带业务型QA团队向智能化转型。

擅长领域：AI 模型及 Agent 评测体系、服务端接口自动化、移动端 GUI Agent、智能测试工程体系、压测与稳定性保障、测试人才转型

过往经历：从业 11 年，历经百度、美团、快手三家大厂，覆盖 AI 算法、大模型应用、智能硬件、移动端 SDK、直播短视频APP等多类产品形态，具备从 0 到 1 搭建测试体系和团队的完整经历，具体介绍如下：

1、百度（测试架构师）：主导视觉智能方向 CI/CD 能力建设，将服务端测试模式从"本地写代码手工执行"升级为流水线持续集成范式，测试人员并发度由 1~3 提升至流水线并行，研发自测率从 30% 提升至 60%，测试吞吐提升 3 倍，成为公司级效能提升专项的标杆团队。

2、美团（测试经理）：先后负责视觉智能和大模型平台/语音两大方向。主导 AIGC 文生图、文生视频、数字人、Agent 评测体系建设，支持 50+ 次评测，拦截 100+ 缺陷；主导人脸系统与安全审核系统稳定性专项，COE 故障量降低 50%，线上告警从 10 次/天压降至 10 次/周，近 3 年无 S9 级以上故障。

3、快手（高级测试经理，现任）：负责海外直播短视频质量保障团队，主导服务端智能测试（KATFlow 工作流体系）和移动端 GUI Agent 智能测试的建设与规模化推广。

待定

「大脑不够，还要有手脚」 ——智能测试规模化落地的工程真相

议题背景：
买了模型、接了API，AI测试的落地效果为何不达预期？我们发现，根因往往不在模型不够强，而在AI缺乏可靠的执行基础设施——有大脑，没有手脚。移动端GUI受限于环境不稳、系统未打通，成功率长期上不去；服务端陷入"夹心自动化"(AI只能生成接口代码，配置/账号/DB/缓存还靠人工)，压测则卡在跨平台手工梳理链路拓扑、限流阈值、隔离策略等。
本次分享将围绕移动端GUI Agent、服务端智能测试、智能压测、工作流重塑四大场景，系统性拆解如何为AI配齐工程手脚：服务端采用KATFlow Skill分层架构(AI推理层+Al Infra层打通配置/账号/DB/缓存/MQ+数据构造飞轮实现资产自积累)，GUI以工程基建优先策略，把App基础动作（登录/冷启动/滑动/手势）做海外专项适配，把配置类平台、工具链和设备环境全部前置打通，让AI指令与业务系统解耦，智能压测以MCP驱动，把链路拓扑、限流阈值、隔离策略等分散数据打通成AI可用的数据通道，AI由此接管方案生成与报告分析，最终把手脚能力嵌入研发流程，从局部效率走向模式转变。

内容大纲：
1. 开场：大脑与手脚

1.1 困境：买了模型、接了API，AI测试落地为何不达预期
1.2 框架：AI测试 = 大脑（模型）+ 手脚（工程基建）
1.3 判断：瓶颈往往不在模型，而在执行基础设施

2. 移动端 GUI Agent 智能测试

2.1 易做难落：为什么Demo能跑、生产跑不动
2.2 双维打标：场景 × 操作，A/B/C/D 四档定位工程缺口
2.3 四类缺口：配置/业务平台、工具类、设备环境、App基础操作适配
2.4 Agent框架重构：视觉决策 + 工程基建 + 状态机编排
2.5 双手双脚：App基础动作专项适配 + 外部系统与设备环境全链路打通
2.6 实战案例：从"人配人执行"到"参数+一条指令"
2.7 结果与归因：同一模型版本下，每次跃迁对应一类工程瓶颈的集中突破

3. 服务端智能测试

3.1 痛点：夹心自动化——AI能生成接口代码，配置/账号/DB/缓存仍靠人工衔接
3.2 大脑层：AI推理决策 + 多阶段Skill流水线
3.2 手脚① · AI Infra层：打通配置/账号/DB/缓存
3.3 手脚② · 数据构造飞轮：高质量数据源持续沉淀，支撑复杂场景验证
3.4 架构全景：从夹心自动化到全链路自动化
3.5 实战案例：售后需求端到端演示
3.6 结果：核心指标显著提升

4. 智能压测

4.1 痛点：跨平台手工梳理链路拓扑、限流阈值、隔离策略等分散数据
4.2 MCP驱动的压测助手

4.2.1 大脑：AI分析链路、理解压测结果、生成结论与推荐
4.2.2 手脚：OpenAPI打通数据获取通道
4.2.3 能力：方案生成 + 报告分析

4.3 成果：效率提升

5. 工作流重塑

5.1 从局部效率到模式转变：工具再强，流程还是人在串——中间人角色是天花板
5.2 新流程全景：状态驱动 + 需求分级管控，全链路Agent触发

5.3 试点结果：质量守住、效率释放

6. 展望与思考

6.1 复盘：数据驱动 → 大脑与手脚 → 模式转变（先跑数据，再建手脚，最后动流程）
6.2 规划：进入研发Loop · 工作流推广 · 从工具到组织形态重构

听众收益：
1. 一套解决"夹心自动化"的完整工程方法论
AI 能生成接口调用代码，但改配置、备账号、查 DB、验缓存这些环节还得人来——这是绝大多数团队 AI 测试卡在半自动化阶段的真实原因。本次分享会给出服务端（KATFlow Skill 分层架构 + AI Infra 层 + 数据构造飞轮）和移动端（GUI Agent 工程基建 + platform_tools 层与 AI 解耦）两套可直接对照落地的工程框架，不止讲"做了什么"，更拆解每个关键技术决策背后的判断依据和踩坑经验。

2. 破解"AI 测试成功率上不去"的工程真相
GUI 执行成功率从 47% 提升至 85%，贡献最大的不是换了更强的模型，而是 ADB 链路标准化、AB 实验自动化注入、设备稳态这些"脏活"。分享会完整拆解四条优化线（环境稳态 / 工程链路 / 独立断言 / 状态机重试）各自的量化贡献，给出一个可以直接套用到自己团队的诊断框架——在提模型之前，先问手脚是否配齐了。
3. 有据可查的研测协同转型路径
如何推动 QA 团队从"执行者"转型为"门禁设计者和 Agent 开发者"，不只是方向判断，而是有具体的落地方案：需求分类驱动的责任重分配（资金类 / 核心类 / 普通类）、两阶段角色重构节奏、Agent 打标准确率的冷启动方式。对于正在考虑推动团队转型的测试管理者，这套方案可以直接拿去对照自己团队的现状做裁剪，而不是从零摸索。

王文明

淘天集团测试开发工程师

淘天集团营销交易技术团队测试开发工程师，目前负责营销中台技术质量，保障商家营销工具以及淘系氛围等产品的稳定性，深度参与营销质量与Ai结合工作，去年投入建设营销Ai图片校验专项，今年建设UI自动化路径智能规划项目。毕业后曾就职于作业帮，从事端基础、vip等业务质量工作。

待定

基于多模态 Agent 的 UI 自动化路径智能规划：

从“写脚本”到“生成高质量用例”的跃迁

议题背景：
传统UI自动化依赖人工编写脚本，存在维护成本高、覆盖不全、边界场景遗漏等问题。我们提出基于多模态Agent的智能路径规划方案，融合DOM结构、页面截图与业务知识，通过AI自动生成高覆盖、低重复的测试路径。系统采用分阶段探索策略（主链路/边界/发散），结合RAG注入校验规则、视觉状态识别、向量去重防循环等技术，在淘系营销中台落地应用。

内容大纲：
1. 问题本质：为什么传统UI自动化“写不动”了？

1.1 脚本维护成本高

页面微调（如按钮文案变更、组件重构）常导致大量脚本失效，回归、维护成本增高。

1.2 覆盖盲区多

人工难以穷举空填、格式错误、非法操作等边界情况，多数用例仅覆盖正向流程。

1.3 缺陷发现滞后

自动化沦为“验证工具”，无法主动暴露潜在风险，质量左移效果有限。

2. 技术突破：如何实现“智能探索”？

2.1 架构演进：从“录制回放”到“AI驱动的多Agent流水线”

2.1.1 构建闭环协作的Agent链：

○ 状态分析Agent：解析DOM + 截图 → 输出页面类型、可操作元素、弹窗状态
○ 策略选择Agent：根据路径阶段决定走主链路或触发异常
○ 指令生成Agent：输出结构化操作指令（如“点击：开始时间”）
○ 断言判断Agent：动态判断是否完成路径并保存结果

2.1.2 所有Agent共享上下文，形成“感知-决策-执行-反馈”闭环。

2.2 多模态输入融合：不只是DOM，更是“看得见”的交互

2.2.1 输入包括四部分：

○ DOM结构（text、placeholder、disabled属性）
○ 页面截图（Base64编码，用于视觉识别）
○ 历史操作轨迹
○ 历史规划路径

2.2.2 关键实践：纯DOM易误判！例如某个输入框未禁用但截图显示为灰色，或弹窗遮挡背景按钮。必须结合视觉信号才能准确判断可操作性。

3. 核心技术创新点

3.1 分阶段探索策略设计

3.1.1 主链路：走通标准流程，确保必填项填写，达成业务目标
3.1.2 边界探索：通过RAG召回业务规则（如“活动名称不能为空”），故意留空或填错，验证前端提示是否正确
3.1.3 发散探索：利用LLM随机性尝试非主流程按钮（如“预览”“帮助”），发现隐藏跳转或异常路径

3.2 双重防重复机制保障探索效率

3.2.1 操作去重：记录已点击元素的文本+位置上下文，避免反复点击同一按钮
3.2.2 路径去重：将路径操作序列压缩计算余弦相似度，高于阈值则判定为重复并终止
3.2.3 用例去重：将历史规划用例作为规划参考，防止规划相同case

3.3 特殊控件精准处理

3.3.1 弹窗优先：一旦检测到遮罩或弹窗标题，强制优先处理弹窗内按钮
3.3.2 日期控件：若日历已展开，不生成“输入日期”，改为“点击具体日期”；跳过isDisabled或视觉置灰的日期
3.3.3 下拉菜单：展开状态下优先选第一个可用选项

4. 工程落地：从原型到平台化交付

4.1 平台化建设

4.1.1 提供Web平台，支持配置目标URL、登录方式、探索深度、步骤数、生成数量
4.1.2 后端通过MQ异步调度任务，完成后返回所有生成路径
4.1.3 输出标准YAML格式，兼容现有执行引擎，无缝集成CI/CD

4.2 落地效果

4.2.1 单任务平均生成有效路径数：15条以上
4.2.2 边界类用例占比达 60%
4.2.3 脚本生成耗时：平均 3.2分钟/用例

听众收益：
参会者将获得以下实战级启发与可复用经验：
1. 掌握可落地的“AI+自动化”架构设计方法：如何将LLM嵌入现有框架，构建具备“认知-决策-执行”能力的智能Agent系统，而非简单调用prompt；
2. 获取“视觉+DOM”协同分析的关键技巧：了解如何通过截图识别特殊case，解决传统自动化因“看不见”导致的误判问题；
3. 借鉴分层探索与去重机制的设计思路：可直接复用主链路/边界/发散三级模型及向量去重方案，快速构建自己的智能探索系统，避免无效循环。

王一勃

58同城高级研发工程师

58同城高级研发工程师，具备深厚的一线研发与质量保障实战经验，拥有多项 AI 测试领域的发明专利。曾深耕 AI 代码辅助工具的研发，对 AI 技术的底层实现机制与工程落地风险有极其深刻的洞察。近年来，全面聚焦 AI 技术与软件测试的深度融合，主导设计并落地了新一代智能测试解决方案。致力于依托大语言模型与自动化技术的双轮驱动重塑测试体系，为企业级研发效能的跃升提供坚实支撑。

待定

基于业务链路的 Web UI Agent 智能化测试实践

议题背景：
Web UI 测试正从脚本化执行进入智能化探索阶段。传统 UI 自动化依赖显式脚本和稳定元素定位，在业务快速迭代、页面频繁变化的场景下，往往面临维护成本高、链路复用弱、失败定位困难等问题。Agent 的引入，为自然语言驱动测试提供了新的可能，但也暴露出执行不确定、验证不充分、结果难追溯等工程化挑战。
本议题以业务链路管理为切入点，分享结合 Agent 执行、视觉证据与结果校验的 Web UI 智能测试实践，探索如何将一次性的智能执行沉淀为可复用、可验证、可持续演进的测试能力。

内容大纲：
1. Agent 测试的背景与机遇

1.1 传统 UI 自动化测试面临的挑战
1.2 Agent 带来的能力变化
1.3 AI 测试落地的关键问题

2. Web UI 智能测试架构

2.1 整体架构设计
2.2 核心流程闭环
2.3 需求智能探索测试演示

3. 关键技术实践

3.1 需求难落地：测试意图建模

3.1.1 业务目标与验证意图解析
3.1.2 结构化任务生成与校验
3.1.3 短周期规划与路径调整

3.2 元素难找准：语义视觉定位

3.2.1 页面快照与候选元素构建
3.2.2 语义、结构、视觉多证据匹配
3.2.3 SOM 标注与有界视觉仲裁

3.3 流程易跑偏：状态感知执行

3.3.1 执行前后页面状态观测
3.3.2 反思恢复与动态重规划
3.3.3 登录、风控、异常状态栅栏

3.4 结果难可信：多层验证闭环

3.4.1 操作效果与页面状态验证
3.4.2 任务级业务目标验证
3.4.3 报告证据链与链路沉淀

4. 未来规划与展望

听众收益：
1. 建立对 Web UI Agent 测试的系统认知，理解其从“页面操作自动化”走向“业务目标驱动执行”的能力边界与落地价值。
2. 掌握以业务链路为核心的智能测试设计思路，理解业务链路、Agent 执行、视觉证据与结果验证之间的协同机制。
3. 获得一套可落地的轻量化建设路径：通过链路沉淀提升资产复用，通过 Agent 执行增强测试弹性，通过报告与验证机制保障结果可信。

李景华

腾讯应用宝质效体系负责人

深耕研发领域10+年，现任腾讯应用宝质效体系负责人，主导全链路质效体系从0到1搭建，通过“敏捷+精益”流程重构、AI辅助智能自动化测试、质效度量闭环，助应用宝成为高效能研发团队。曾就职于全球顶尖的IT咨询公司Thoughtworks（，作为核心创始成员创立BeeArt系列提效工具矩阵，服务10+行业头部客户。核心能力聚焦质效体系构建、智能自动化测试、团队效能激活，用数据驱动突破瓶颈，打造高效能团队。

待定

通用智能体质量体系如何搭建?

来自腾讯Marvis AI办公智能体质量保障实战

议题背景：
随着大模型的快速发展，加之Openclaw和Hermes的带动，通用智能助手如雨后春笋般涌现出来，然而，与传统的B/S和C/S的互联网软件相比，AI智能体需要保障在一个“不确定性的自主系统中”能否达成目标，由于自主系统的不确定性、测试环境多样性以及智能体与用户意图之间的差距，导致质量保障体系非常困难；Marvis作为腾讯新型AI智能助手，从2026年5月20日发布以来，一周内DAU突破10W，一个月DAU突破30万，面对如此快速的增长，Marvis构建了一套“自动化评测+自动化E2E测试+人工Review”的测试新模式，保障了每天一个版本的快速迭代；本次分享将以Marvis智能体测试实战案例入手，阐述通用智能体质量保障中各个难点的解决方案！

内容大纲：
1. 通用智能体质量保障难点和痛点

1.1 腾讯Marvis智能体介绍
1.2 Marvis质量保障的难点

2. 腾讯Marvis质量保障实战

2.1 腾讯Marvis质量保障方案整体设计
2.2 腾讯Marvis的自动化测试体系
2.3 腾讯Marvis的评测体系
2.4 腾讯Marvis的质量保障样例

3. 腾讯Marvis质量保障效果评估

3.1 质量效果评估指标体系
3.2 质量评估指标与发版指标关系
3.3 重点评估指标详解

王睿

中国工商银行金融科技经理

长期从事软件质量保障、测试效能提升和智能研发工具建设工作。近年重点关注大模型在软件测试领域的工程化应用，参与推进测试设计、测试执行、研发知识工程、多智能体编排等方向的落地实践。2025年起，围绕智能测试，推动测试设计、测试执行智能化体系建设，逐步形成从“案例设计”到“执行验证”的闭环能力。关注AI能力从“能生成”走向“可评审、可入库、可执行、可度量”的真实落地。

待定

从用例生成到执行闭环：工商银行智能测试落地与实践

议题背景：

大模型在测试领域的应用越来越多，但不少实践仍停留在“生成测试用例”阶段，但测试人员真正耗时的地方，往往是理解需求变更、拆分测试对象、准备测试数据、构造接口报文、适配页面操作和判断执行结果。在银行复杂业务场景中，这些问题更加明显，本次分享将结合测试智能体在银行研发测试场景中的实践，介绍如何从“用例生成”出发，逐步打通“规约—案例—数据—报文—执行—断言”的测试链路。

内容大纲：
1. 测试设计智能体：四轮迭代优化，用“规约+方法”约束模型输出

1.1 测试设计智能体迭代进程：从单纯使用测试设计方法，到引入规约驱动生成，到两者结合
1.2 阶段效果

2. 测试执行智能体：打通“案例—数据—报文—执行”

2.1 基于测试案例提取执行约束，生成接口报文和自动化脚本草稿；对无法确认的字段保留人工确认，避免模型编造
2.2 测试数据的由来：围绕客户、账户、产品等业务实体，建立案例约束、字段映射和测试数据资产之间的连接
2.3 阶段效果

3. 工程化复盘和后续思路：测试智能体真正要沉淀什么

3.1 复盘经验1：Skill不只是提示词，而是模板、状态机、文件协议、确认机制和异常处理的组合
3.2 复盘经验2：能规则化的部分规则化，能资产化的部分资产化，模型主要负责理解、归纳、匹配和生成
3.3 后续方向：资产整理

听众收益：
1. 拆解测试设计、测试执行的建设思路和方式。
2. 了解智能测试落地中的典型坑：需求拆分不准、字段映射复杂、数据资产不足、UI控件适配、断言不完善、模型编造内容等问题，以及相应处理思路。

郭梦茹

腾讯音乐高级测试开发工程师

QQ音乐研发效能中心专项测试开发组高级测试开发工程师，主要负责QQ音乐、全民k歌等业务线下全部APP的性能专项测试保障体系建设、包括标准制定，大型、创新型项目的性能质量保障工作；同时主导CICD、AI代码漏洞挖掘专项工作。

待定

双引擎驱动 + 调用链穿透：AI 时代代码问题挖掘的规模化落地实践

议题背景：
AI Coding 时代代码产出效率飙升，但内存泄漏、crash、跨模块异常等深层逻辑缺陷仍高度依赖资深专家人工Review，传统Lint规则仅覆盖表层规范，漏报率超60%；且单次扫描动辄数百条告警，误报率超30%，人工二次分析成本居高不下。我们系统性建设了静态代码问题挖掘与质量左移工具链，核心创新在于：

① 双引擎融合检测——CI阶段传统Lint快速拦截规范问题，转测阶段AI智能检测覆盖隐式逻辑缺陷；

② 代码调用链图谱——突破单文件局限，精准追踪跨模块异常传播路径；

③ 误报分析自闭环Agent——实现“检测-分析-沉淀-优化”自动化循环。该体系各业务常态化运行，单季度累计发现有效问题2500+例，前置发现率从6%提升至20%+，沉淀规则1000余条、Agent及Skill 10余个，并提交相关专利7篇

内容大纲：
1. 困境：传统Lint为什么“管得了格式，管不住质量”

1.1 AI生成代码带来的深层隐患：内存泄漏、crash、并发竞争等依赖上下文分析的缺陷占比激增
1.2 传统Lint的“三座大山”：规则覆盖不全、误报率高、跨文件分析能力缺失
1.3 目标设定：将静态问题前置发现率从个位数提升至20%以上，同时压降人工二次分析成本

2. 破局：双引擎融合检测体系的设计与演进

2.1 整体架构：CI/CD流水线嵌入传统Lint（合入前自动拦截）+ 转测阶段AI智能检测（深度隐式问题挖掘）的分层策略
2.2 规则分层治理：SwiftLint/FindBugs等传统规则的场景化裁剪与阈值调优，降低基础误报
2.3 AI规则引擎：基于大模型的代码语义理解，覆盖传统工具无法检出的复杂逻辑缺陷

3. 核心突破：代码调用链图谱的构建与上下文穿透分析

3.1 调用链自动生成：基于代码提交diff，动态构建函数级调用关系图谱的技术实现
3.2 AICR（AI Code Review）增强：将完整调用链路作为上下文注入检测模型，实现跨模块异常传播路径的精准追踪
3.3 实战效果量化：跨文件缺陷检出率提升的具体倍数/百分比，以某次内存泄漏跨三层调用被成功捕获为例

4. 闭环：误报分析Agent与规则自沉淀机制

4.1 痛点：AI检测引入新误报，人工二次分析成本如何可控？
4.2 误报自动分析Agent：如何自动研判告警真实性、生成误报知识库
4.3 规则缺陷单自动闭环：从“发现问题→分析误报→沉淀规则→规则自动更新”的全链路自动化
4.4 踩坑实录：Agent“自我循环”导致的规则退化问题及应对策略（引入人工抽检Guard机制）

5. 规模化落地：从单点到全端、从工具到能力矩阵

5.1 能力横向扩展：需求完整度检测、UI异常检测、上报异常检测、双端实现不一致检测等衍生工具的共建模式
5.2 多端覆盖实战：Android（自定义Gradle插件）、iOS（Xcode插件化）、Web（ESLint增强）、后台（SpotBugs扩展）的技术适配差异与统一接入层设计
5.3 核心量化成果：接入Q1累计有效问题2000+例，前置发现率6%→20%+，沉淀规则500+条，Agent/Skill 10+个，专利7篇

6. 未来展望：从“辅助发现”到“自动修复”

6.1 当前瓶颈：AI修复准确率不足、修复引入新Bug的风险
6.2 探索方向：基于调用链的精准修复补丁生成 + 修复后自动化回归验证

听众收益：
1. 一套可直接复用的“双引擎检测+调用链分析”架构方案：了解如何在不推翻现有Lint体系的前提下，引入AI能力实现检测深度跃升，并获得跨文件上下文分析的落地实现细节，可用于自身团队的代码质量左移建设。
2. 误报治理的“自闭环”实战经验：学习如何通过Agent自动化处理AI引入的新误报问题，形成规则自沉淀的正向循环，避免“上了AI反而增加人工成本”的尴尬局面，并收获实际踩坑（如规则退化）的应对策略。
3. 规模化推广的“避坑指南”：了解在多端（Android/iOS/Web/后台）、多业务（Q音/K歌/JOOX/Wesing）场景下统一接入层的设计取舍与技术适配差异，为跨团队、跨技术栈推广提供真实参考。

沈阳

淘天集团高级测试开发工程师

淘天集团营销&交易技术高级测试开发工程师，目前主要负责淘天集团营销导购会场质量保障、会场AI测试智能测试数据员工落地实现等，保障营销导购会场、营销工具投放、营销大促等项目的高可用性、稳定性和演练；以及营销平台方舟搭建、阿拉丁投放以及其他相关营销工具稳定性保障工作。

待定

MTC 评测平台建设方案

议题背景：

MTC 把"Agent 好不好"从主观判断变成可复现、可回归、可归因的工程度量。平台层（MTC）解决怎么跑得稳、跑得可追溯；方法论层（ome skill）解决评什么、数据够不够、指标准不准、跑完怎么改。

内容大纲：

1. 背景与定位

1.1 Agent 时代测试的三个失效点

传统测试假设"输入确定 → 输出确定"。而 Agent 是概率性、多轮、带工具调用的系统，导致三个失效：

- 结果不可复现——同一 query 两次跑分不同，无法判断改动是否有效
- 没有基——只能说"感觉变好了"，说不出好多少、哪里好
- 指标无区分度——流畅度、连贯性这类维度所有版本都是高分，无法排序和选型

1.2 双层体系与硬边界

1.2.1 平台层 MTC：评测对象/指标/数据集实体、执行引擎、报告与归因
1.2.2 方法论层 ome skill：方案设计、数据集构建审计、指标设计校准、执行编排、归因分析

2. 评测矩阵 = 评测对象 × 数据集 × 评测指标

2.1 评测对象层：协议化屏蔽异构被测系统
2.2 评测指标层：规则、模型、人工三条通路并存

llm_judge（多模型通道）、rule（Groovy 本地脚本）、manual（人工打标）、custom HTTP 判分、本体召回专用指标。
两个关键设计：
打分范围与目标值解耦：targetAccuracy`是及格线不是打分上限，且不进 LLM prompt——否则分数会塌到阈值附近
pass@N/pass^N：把概率性系统的稳定性显式建模为一个维度

2.3 数据集层：从线上回流到基线沉淀

多来源接入（人工、ODPS、 QA、ALD、HTTP）+ 场景集 + 候选样本池与保鲜看板 + 按业务隔离。定位是把"线上真实流量 → 候选池 → 评测集 → 基线"这条保鲜链路工程化，而不是维护一份静态用例表。

3. 执行引擎：从单次调试到规模化批跑

3.1 编排主流程
3.2 复杂模式评测并发与稳定性

- pass@N 多次采样带 checkpoint 断点续跑
- llm as user；agent as user 多轮对话评测
- 对比对象评测

3.3 全链路可观测
3.4 评测工作台

工作台深链承接 → debugRun 单次调试 → 流式 SSE 执行 → 同步阻塞接口（供 CLI/CI 调用）→ 定时批跑 + 钉钉卡片通知。构成从"人工调试"到"无人值守回归"的完整梯度。

4. 结果层：报告、对比与归因

4.1 报告视图按评测形态分化

完整报告 / 本体召回面板 / 多对象对比 / 人工打标矩阵 / Query-GT-Actual 紧凑视图，同一份数据多种读法。

4.2 多对象 ABC 对比

父单记录多个评测对象快照，报告摘要、对比查看、评测记录三处共用同一套对比组件与 A/B/C 角标，支持人工判定胜出。这是版本选型和 prompt 迭代的主要决策界面。

4.3 三级归因体系

| 层级 | 粒度 | 用途 |
| --- | --- | --- |
| L1 Case 级 | 单条 bad case | 定位具体失败原因 |
| L2 报告级 | 一次评测 | LLM 生成归因报告 |
| L3 大盘级 | 跨报告聚合 | 趋势与优先级 |
报告级四分类：缺知识 / 缺工具 / 提示词问题 / 其他，直接映射到可执行的改进动作。

4.4 闭环

度量看板 + 缺陷台账 → 回灌候选池与数据集，让每次评测产生的失败样本成为下一轮的资产。

5. 方法论层：ome skill 把"怎么评"变成可执行流水线

5.1 定位

Skill 管方法论，引擎管执行。每个 skill 既能脱离平台独立跑（本地 jsonl + 统一结果契约），也能把产物发布进工程态获得可追溯性。

5.2 六环流水线

plaintext
benchmark-survey 生态调研
→ plan 评测方案 evaluation.spec
→ dataset 构建 + 10 维健康度审计
→ criteria 指标设计 → judge 装配对齐 → 校准门禁
→ run 统一结果契约
→ diagnosis 归因报告 + 改进 feedback