专场：Agent 驱动的智能化测试：从辅助到自治
测试是智能体落地最成熟的场景。完整拆解 AI 测试演进链路：从 AI 辅助生成测试用例、Agent 自主执行测试、自主研判结果到自主闭环修复，落地 LLM 赋能下测试左移、测试右移一体化自治测试体系，输出覆盖需求到上线全流程的智能化质量落地实践。
专场出品人：仲思宇
58同城 工程效能部负责人
负责58到家测试工具体系规划与架构设计，拥有多项测试工具发明专利。深耕客户端与服务端自动化测试多年，擅长业务质量体系规划及技术赋能落地，丰富的测试平台建设与效能提升经验。
仲思宇
58同城 工程效能部负责人
负责58到家测试工具体系规划与架构设计，拥有多项测试工具发明专利。深耕客户端与服务端自动化测试多年，擅长业务质量体系规划及技术赋能落地，丰富的测试平台建设与效能提升经验。
专注领域：质量体系建设、AI测试体系建设
专注领域：质量体系建设、AI测试体系建设
待定
待定
AI Coding 时代，面向需求交付的智能化测试体系建设与实践
议题背景：
随着 AI Coding、智能研发助手和代码生成工具逐步进入研发流程，需求到代码的交付速度正在显著提升。研发侧可以更快完成方案生成、代码实现和问题修复，业务迭代节奏被进一步压缩，测试侧也随之面临更高频、更不确定的质量承接压力。
传统测试方式依赖人工理解需求、设计用例、维护脚本和整理报告，在高频迭代下容易出现回归范围难判断、测试产物难复用、执行结果难沉淀等问题。AI Agent 虽然带来了需求理解、用例生成和自动执行的新能力，但如果缺少业务上下文、执行证据和反馈机制，也很容易停留在“看似智能但难以稳定交付”的阶段。
本议题将分享一种从需求理解到执行反馈的 AI Agent 测试交付闭环：以业务链路和测试产物为核心，将需求分析、用例生成、自动执行、回归验证、探索巡检和报告反馈串联起来，探索测试如何承接 AI Coding 时代下更快、更频繁的软件交付节奏。
内容大纲：
1.背景与挑战：AI Coding 加速后的测试承接压力
随着 AI Coding、智能研发助手和代码生成工具逐步进入研发流程，需求到代码的交付速度正在显著提升。研发侧可以更快完成方案生成、代码实现和问题修复，业务迭代节奏被进一步压缩，测试侧也随之面临更高频、更不确定的质量承接压力。
传统测试方式依赖人工理解需求、设计用例、维护脚本和整理报告，在高频迭代下容易出现回归范围难判断、测试产物难复用、执行结果难沉淀等问题。AI Agent 虽然带来了需求理解、用例生成和自动执行的新能力，但如果缺少业务上下文、执行证据和反馈机制，也很容易停留在“看似智能但难以稳定交付”的阶段。
本议题将分享一种从需求理解到执行反馈的 AI Agent 测试交付闭环：以业务链路和测试产物为核心，将需求分析、用例生成、自动执行、回归验证、探索巡检和报告反馈串联起来，探索测试如何承接 AI Coding 时代下更快、更频繁的软件交付节奏。
内容大纲：
1.背景与挑战：AI Coding 加速后的测试承接压力
1.1 AI Coding 对研发交付节奏的影响
1.2 传统测试交付链路中的断点问题
1.3 AI Agent 测试落地中的不确定性挑战
1.4 测试体系从单点工具走向体系化交付的必要性
1.2 传统测试交付链路中的断点问题
1.3 AI Agent 测试落地中的不确定性挑战
1.4 测试体系从单点工具走向体系化交付的必要性
2. 架构设计：测试能力的产品矩阵
2.1 核心枢纽：任务理解 → 拆解规划 → 调度分发
2.1.1 三阶段决策管线：需求解析 → 用例规划 → 步骤编排
2.1.2 状态机驱动执行流转控制
2.1.3 Sub-Agent 各司其职、并行执行
2.1.2 状态机驱动执行流转控制
2.1.3 Sub-Agent 各司其职、并行执行
2.2 专项能力单元
2.2.1 用例构建Agent：融合层级知识生成可执行用例
2.2.2 端执行Agent：Web/H5/Android/iOS/HarmonyOS 多端落地
2.2.3 知识中枢Agent：知识库检索 + 图谱推理 + 会话状态追踪
2.2.4 调度治理Agent：任务分发 + 资源编排 + 执行质量控制
2.2.2 端执行Agent：Web/H5/Android/iOS/HarmonyOS 多端落地
2.2.3 知识中枢Agent：知识库检索 + 图谱推理 + 会话状态追踪
2.2.4 调度治理Agent：任务分发 + 资源编排 + 执行质量控制
3. 技术突破：四个核心能力建设
3.1 结果可信：规则校验 + 证据链 + 质量门禁
3.1.1 置信度阈值控制输出稳定性
3.1.2 截图/日志/接口证据链完整采集
3.1.3 输出可审计、可回放、可归因
3.2 复杂任务：跨端跨系统长流程的无人值守执行
3.2.1 图谱导航确定执行路径
3.2.2 状态机编排复杂执行流程
3.2.3 执行反馈驱动路径、用例与策略优化
3.3 持续进化：执行结果回流知识体系
3.3.1 巡检探索沉淀链路图谱
3.3.2 失败案例丰富知识库
3.3.3 形成自我优化闭环
3.4 稳定输出：知识约束 + 图谱锁定 + 状态追踪
3.4.1 层级知识库约束模型输出
3.4.2 拓扑图谱锁定执行路径
3.4.3 运行时状态追踪保障环境一致性
4. 实践落地与效果
4.1 需求生命周期实践：需求、用例生成、执行、报告的链路贯通
4.2 多元场景覆盖：回归测试、巡检探索、无人化托管
5. 总结与展望
5.1 总结，测试从被动验证转向主动质量承接
5.2 展望，从测试自动化工具走向可持续演进的质量交付体系
听众收益：
1. 理解 AI Coding 加速研发后，测试团队如何构建与之匹配的质量承接能力。
2. 了解 AI Agent 如何贯穿需求理解、用例生成、自动执行、回归验证、报告归因和结果反馈。
3. 获得一套可渐进落地的 AI 测试平台建设思路：先打通需求测试闭环、回归测试闭环和探索巡检闭环，再扩展多 Agent 协同能力。
1. 理解 AI Coding 加速研发后，测试团队如何构建与之匹配的质量承接能力。
2. 了解 AI Agent 如何贯穿需求理解、用例生成、自动执行、回归验证、报告归因和结果反馈。
3. 获得一套可渐进落地的 AI 测试平台建设思路：先打通需求测试闭环、回归测试闭环和探索巡检闭环，再扩展多 Agent 协同能力。
李绪隆
腾讯 系统测试工程师
腾讯存储测试团队，担任系统测试工程师。长期深耕对象存储与分布式存储领域，聚焦高并发、大容量、高可用场景下的系统测试与质量建设。通过自动化测试平台、混沌工程、性能基准评测等手段，持续发现并解决底层存储瓶颈与风险，保障系统在极致规模下仍能稳定可靠运行，为腾讯海量数据存储业务提供全方位、高强度的质量保障。
待定
待定
基于LLM的全链路日志智能分析：
自动化 Case 执行路径捕获与根因定位实践
议题背景：
在质量保障过程中，传统方式难以高效追踪分散在多模块的服务端日志，导致case失败根因定位耗时长、效率低。
在质量保障过程中，传统方式难以高效追踪分散在多模块的服务端日志，导致case失败根因定位耗时长、效率低。
内容大纲：
1. 问题背景与挑战
1.1 质量保障中的日志分析痛点：多模块日志分散、人工串联效率低下
1.2 传统解决方案局限：串联不完整、跨协议支持不足、缺乏智能分析能力
2. LLM驱动的全链路日志分析架构设计
整体架构：case_tracer + log_tracer + case_analysis + post_processor四位一体
3. 核心组件实现与技术亮点
3.1 case_tracer：非侵入式case执行路径捕获
3.1.1 无代码侵入的Python库设计
3.1.2 多协议(HTTP/RPC)请求自动捕获机制
3.2 log_tracer：全链路日志精准捕获
3.2.1 双模式设计：mcp-server(LLM自驱动) vs 分布式server(配置驱动)
3.2.2 关键技术：关键字转换、模块跳转信息获取
3.3 skill_creator：知识自动化转化
3.3.1 从wiki/代码库自动生成追踪skill
3.3.2 skill到log_tracer配置的自动化固化
3.4 post_processor：分析后处理
邬淑敏
bilibili 高级测试开发工程师
上海幻电信息科技有限公司质量保障中心高级测试开发工程师，用例生成项目负责人。具备一线业务测试与专项建设经验，曾担任业务 Owner，熟悉需求交付与质量闭环。长期从事质量保障与测试效能建设，主导 AI 用例生成引擎与平台落地。擅长 AI 辅助测试、Agent/工作流工程化、质量度量与效能提升，致力于将用例从「能生成」推进到「准召、可读、可交付」
待定
待定
从草稿到资产：ai-case 的 Graph×Loop 闭环
议题背景：
AI 出例并不稀缺，稀缺的是准召可读且能进生产：长文易衰减、双入口行为分叉、生成正确却太泛难读、过检却落不了库。根因常被误判成 Prompt，实则缺阶段定责、缺可退出的质量迭代、缺语料清洗与交付运营闭环。ai-case 的方向是：用 LangGraph 固定主链，用 loop 拉升准召与可读，用语料清洗工程治理输入，再用权限触发、在线编辑与质量看板把结果做成可运营资产——从「能生成」走向「可交付、可运营」。
内容大纲：
1. 问题与目标：从「能生成」到「准召可读可交付」
AI 出例并不稀缺，稀缺的是准召可读且能进生产：长文易衰减、双入口行为分叉、生成正确却太泛难读、过检却落不了库。根因常被误判成 Prompt，实则缺阶段定责、缺可退出的质量迭代、缺语料清洗与交付运营闭环。ai-case 的方向是：用 LangGraph 固定主链，用 loop 拉升准召与可读，用语料清洗工程治理输入，再用权限触发、在线编辑与质量看板把结果做成可运营资产——从「能生成」走向「可交付、可运营」。
内容大纲：
1. 问题与目标：从「能生成」到「准召可读可交付」
1.1 问题：长文衰减、用例太泛难读、过检却落不了库
1.2 目标口径：召回（覆盖）↑、准确（少幻觉/少误扩写）↑、可读↑，并保证可落库
1.3 技术选型：LangGraph 主图定责 + 质量 Loop 收敛 + 语料清洗与输出门控
1.2 目标口径：召回（覆盖）↑、准确（少幻觉/少误扩写）↑、可读↑，并保证可落库
1.3 技术选型：LangGraph 主图定责 + 质量 Loop 收敛 + 语料清洗与输出门控
2. 主链路工程化：多入口统一编排
2.1 方案：`prepare → generate → review → score ⇄ improve`；
2.2 抉择：准备与生成解耦；完整性检查并入评分，避免多套政策
2.3 踩坑：大模型每次输出的case效果无法得到保证
2.4 实践：共享路由与落库契约；终态结果写回，禁止中途快照单独裁决
2.5 收益：失败可归因；无效重跑下降40%
2.2 抉择：准备与生成解耦；完整性检查并入评分，避免多套政策
2.3 踩坑：大模型每次输出的case效果无法得到保证
2.4 实践：共享路由与落库契约；终态结果写回，禁止中途快照单独裁决
2.5 收益：失败可归因；无效重跑下降40%
3. 质量闭环：用 Loop 拉升准召与可读
3.1 方案：Score → Improve → 同契约重评 → 交付/再改；Improve 内可挂有限 Tool 环
3.2 指标设计：覆盖≈召回；正确性+冗余控制≈准确；可读独立计分；结构保交付
3.3 实践：按缺口驱动增删改；锚点约束抑制空转提分；Tool 失败可降级继续主环
3.4 踩坑：硬回滚震荡；套话预期刷分；工具环过大导致成本与格式失控
3.5 收益：召回 55%→78%，准确60%→75%，可读达标约50%→80%；多数任务一轮内达门槛
3.2 指标设计：覆盖≈召回；正确性+冗余控制≈准确；可读独立计分；结构保交付
3.3 实践：按缺口驱动增删改；锚点约束抑制空转提分；Tool 失败可降级继续主环
3.4 踩坑：硬回滚震荡；套话预期刷分；工具环过大导致成本与格式失控
3.5 收益：召回 55%→78%，准确60%→75%，可读达标约50%→80%；多数任务一轮内达门槛
4. 输入侧工程化：建立语料清洗工程，为准召提供可用上下文
4.1 问题：多源语料裸进模型 → 噪声高、冲突多、格式串味，直接打穿召回与准确
4.2 建设目标：升级 语料清洗工程（采集 → 清洗 → 分片 → 注入 → 验收）
4.3 工程方案
4.2 建设目标：升级 语料清洗工程（采集 → 清洗 → 分片 → 注入 → 验收）
4.3 工程方案
4.3.1 采集归一：多源拉齐为统一语料对象
4.3.2 清洗降噪：去壳/去重/去无关噪声；历史稿与本次隔离；
4.3.3 分片编排：按角色分块进主链，拒绝超长线性堆叠
4.3.4 检索增强：平台/业务知识并行召回，作为清洗后的补充证据
4.3.5 注入验收：应注入/已送达/是否截断可观测，未达则回流清洗
4.3.2 清洗降噪：去壳/去重/去无关噪声；历史稿与本次隔离；
4.3.3 分片编排：按角色分块进主链，拒绝超长线性堆叠
4.3.4 检索增强：平台/业务知识并行召回，作为清洗后的补充证据
4.3.5 注入验收：应注入/已送达/是否截断可观测，未达则回流清洗
4.4 踩坑：截断不可见；参考稿污染输出；关联需求淹主需求；业务规范与平台模板冲突
4.5 收益：关键语料送达约 70%→90%+；脏语料导致的漏测与误测回流明显下降；
4.5 收益：关键语料送达约 70%→90%+；脏语料导致的漏测与误测回流明显下降；
5. 平台功能亮点：生成前可控接入，生成后可编、可评、可运营
5.1 生成前：以空间权限治理 +平台规则化自动触发，实现组织可控的规模化接入
5.2 生成后：XMind 在线编辑与侧栏协同（打标、同步、提 Bug）一体，生成结果可继续精修、可业务收口
5.3 质量运营：单条质量透视 + 平台指标看板；保存/上传自动评估，质量从体感变为可运营数据
5.4 收益：形成「触发—生成—编辑—评估—运营」闭环；人工收口效率与质量可见性同步提升
5.2 生成后：XMind 在线编辑与侧栏协同（打标、同步、提 Bug）一体，生成结果可继续精修、可业务收口
5.3 质量运营：单条质量透视 + 平台指标看板；保存/上传自动评估，质量从体感变为可运营数据
5.4 收益：形成「触发—生成—编辑—评估—运营」闭环；人工收口效率与质量可见性同步提升
6. 成效、边界与可迁移结论
6.1 成效：主指标看准召与可读（会上用上述量级对比 + 1～2 个样例说明）；
6.2 边界：知识自进化、偏好记忆、GUI 自动执行仍在演进；优势在生产级生成引擎 + 平台运营闭环
6.3 结论：引擎拉准召可读，平台把权限、触发、编辑、评估做成可运营；先建语料清洗与评分闭环，再换更大模型；
6.2 边界：知识自进化、偏好记忆、GUI 自动执行仍在演进；优势在生产级生成引擎 + 平台运营闭环
6.3 结论：引擎拉准召可读，平台把权限、触发、编辑、评估做成可运营；先建语料清洗与评分闭环，再换更大模型；
听众收益：
1. 可落地的生产级用例 Agent 拆法：何时用主图定责、何时用质量 Loop 拉准召/可读、何时先建语料清洗工程。
2. 可对照的工程手段与踩坑：双入口统一编排、同契约重评、空转提分治理、终态落库契约等真实反模式。
3. 平台运营闭环视角：权限与自动触发、XMind 线编辑与侧栏收口、质量看板与自动评估如何把生成结果做成可运营资产，而不只是一次性演示。
1. 可落地的生产级用例 Agent 拆法：何时用主图定责、何时用质量 Loop 拉准召/可读、何时先建语料清洗工程。
2. 可对照的工程手段与踩坑：双入口统一编排、同契约重评、空转提分治理、终态落库契约等真实反模式。
3. 平台运营闭环视角：权限与自动触发、XMind 线编辑与侧栏收口、质量看板与自动评估如何把生成结果做成可运营资产，而不只是一次性演示。
牛文芳
浙银理财 测试组质量保障专家
2025.12加入浙银理财金融科技部，任职质量保障专家，负责浙银理财资产管理相关系统质量保障工作，长期从事质量工程、测试平台和AI工程化实践，浙银理财AI质量门户平台负责人；2018-2025年曾就职于阿里巴巴淘天集团，负责淘宝营销基础链路质量保障和淘天集团大促全链路表达预演；
待定
待定
Multi-Agent + 知识图谱保鲜驱动的复杂金融监管规则智能测试实践
议题背景：
银行理财资管风险限额业务规则复杂，涉及 120+ 监管限额条目、30+ 指标因子，以及产品条件、资产条件、穿透条件等多维约束。需求变更时，回归场景规模大，传统测试依赖人工判断影响范围，存在评估不准、成本高、效率低等问题。本项目构建了基于 Multi-Agent 的限额智验质量门户，串联知识图谱智能引擎 Agent、知识图谱保鲜 Agent、数据工厂 Agent 和限额智验 Agent，实现需求变更识别、图谱保鲜、回归范围推荐、数据准备、自动化校验与结果分析闭环。方案通过DSL/YAML 建模限额规则，基于 Neo4j 构建规则、指标、因子的血缘关系，并以 Harness 规范约束 AI Coding 和 Agent 执行过程，保障线上库、测试库、YAML 文件与知识图谱一致。落地后，支持全量回归场景，回归效率提升120 倍，线上缺陷逃逸率下降60%。
银行理财资管风险限额业务规则复杂，涉及 120+ 监管限额条目、30+ 指标因子，以及产品条件、资产条件、穿透条件等多维约束。需求变更时，回归场景规模大，传统测试依赖人工判断影响范围，存在评估不准、成本高、效率低等问题。本项目构建了基于 Multi-Agent 的限额智验质量门户，串联知识图谱智能引擎 Agent、知识图谱保鲜 Agent、数据工厂 Agent 和限额智验 Agent，实现需求变更识别、图谱保鲜、回归范围推荐、数据准备、自动化校验与结果分析闭环。方案通过DSL/YAML 建模限额规则，基于 Neo4j 构建规则、指标、因子的血缘关系，并以 Harness 规范约束 AI Coding 和 Agent 执行过程，保障线上库、测试库、YAML 文件与知识图谱一致。落地后，支持全量回归场景，回归效率提升120 倍，线上缺陷逃逸率下降60%。
内容大纲：
1. 项目背景与挑战
1.1 银行理财限额测试业务现状
1）120+ 监管条目、30+ 指标因子、条目涉及的产品条件、资产条件、穿透条件等较多，需求变更时各种条件层层叠加，变更影响面难评估，测试/回归场景规模大；
1.2 测试挑战：
1）传统自动化执行时间较长性能差跑不动，当需求变更时主要是依赖人工测试，人工成本高、效率低、且没有有效的度量手段保障回归是否完整；
1）传统自动化执行时间较长性能差跑不动，当需求变更时主要是依赖人工测试，人工成本高、效率低、且没有有效的度量手段保障回归是否完整；
2. 整体产品方案：
2.1 建设高性能、精准可度量的Multi-Agent 限额智验质量门户：
1）自然语言入口 -> 知识图谱保鲜 -> 影响范围智能推荐 -> 数据工厂一键造数 -> 自动化校验 -> 结果分析，实现限额自动化任务调度、执行追踪、结果查看、差异分析全链路闭环；
2.2 构建闭环协作Agent链：
1）知识图谱智能引擎 Agent：限额条目结构化存入知识图谱，当条件因为变更时，可以根据血缘关系推荐出影响范围；
2）数据工厂 Agent：自动匹配限额条目和指令数据关系，一键自动化造数；
3）限额智验 Agent：串联知识图谱智能引擎推荐出测试范围->数据工厂自动获取测试数据->自动化用例执行校验结果->结果分析全链路闭环；
2）数据工厂 Agent：自动匹配限额条目和指令数据关系，一键自动化造数；
3）限额智验 Agent：串联知识图谱智能引擎推荐出测试范围->数据工厂自动获取测试数据->自动化用例执行校验结果->结果分析全链路闭环；
4）知识图谱保鲜 Agent：让知识图谱从“静态资产”变成“持续更新的规则底座”；
3. 整体技术方案实现：
3.1 Harness规范+AICoding落地知识图谱智能引擎推荐和保鲜：
3.1.1 限额条目规则建模沉淀知识图谱血缘：
1）DSL+YAML 抽象 rule_id + formula + metrics ；
2）条目与因子条件实体建模：建立条目与指标因子、规则、产品条件、穿透条件之间的关系；
3）YAML 到图谱：解析规则文件->提取实体关系->生成 Cypher写入 Neo4j；
2）条目与因子条件实体建模：建立条目与指标因子、规则、产品条件、穿透条件之间的关系；
3）YAML 到图谱：解析规则文件->提取实体关系->生成 Cypher写入 Neo4j；
3.1.2 知识图谱智能引擎Agent+RAG召回出测试范围：
1）自然语言输入需求变化->RAG血缘召回->精准推荐测试//回归范围；
3.1.3 知识图谱保鲜 Agent：让图谱从“静态资产”变成“持续更新的规则底座”：
1）保鲜原因：线上库、测试库、DSL/YAML 和知识图谱之间会随版本持续漂移，依赖人工线下约定 SOP，容易出现更新遗漏、口径不一致、责任边界不清；
2）保鲜链路设计：自然语言输入->自动同步线上库与测试库差异 -> 建立库表与DSL YAML 映射->Agent 自动更新 YAML Prompt -> YAML 自动更新至知识图谱；
2）保鲜链路设计：自然语言输入->自动同步线上库与测试库差异 -> 建立库表与DSL YAML 映射->Agent 自动更新 YAML Prompt -> YAML 自动更新至知识图谱；
3.1.4 Harness工程搭建知识图谱智能引擎和保鲜Agent优势：
1）传统：人工写代码生成知识图谱->跑脚本->线上库限额规则发生变化->线下约定SOP同步->人改代码->再跑脚本更新图谱（慢、滞后、易错）；
2）Harness式：用一个强Agent（codex）搭建知识图谱智能引擎和保鲜Agent，把 AI Coding 从“对话式生成”约束为“有输入、有步骤、有校验、有产物”的工程流程：自然语言输入-自动同步线上库与测试库差异 -> 保鲜Agent 自动更新结构化 YAML Prompt -> YAML 自动更新至知识图谱->智能推荐Agent RAG血缘关系召回->精准推荐出测试/回归范围，将复杂金融规则的限额模块的回归范围由难评估到只需要输入“自然语言指令”就可以变得精准可度量（快、实时、可验证）；
2）Harness式：用一个强Agent（codex）搭建知识图谱智能引擎和保鲜Agent，把 AI Coding 从“对话式生成”约束为“有输入、有步骤、有校验、有产物”的工程流程：自然语言输入-自动同步线上库与测试库差异 -> 保鲜Agent 自动更新结构化 YAML Prompt -> YAML 自动更新至知识图谱->智能推荐Agent RAG血缘关系召回->精准推荐出测试/回归范围，将复杂金融规则的限额模块的回归范围由难评估到只需要输入“自然语言指令”就可以变得精准可度量（快、实时、可验证）；
3.2 基于AgentScope搭建Multi-Agent 限额智验质量门户
3.2.1 整体技术实现
1）基于AgentScope 2.0的Agent/FunctionTool能力，将知识图谱推荐、数据工厂造数、限额自动化校验等能力封装为可配置 Agent 工具，并依托 FastAPI 会话接口、SSE 流式事件、上下文记忆和任务状态管理实现可配置、可追踪、可扩展的 Multi-Agent 协同链路；
2）数据流向：用户自然语言指令 → 门户会话接口 → 编排层 →（图谱推荐 Agent → 数据工厂 Agent → 限额智验 Agent 调 Java 引擎校验 → 结果对比）→ SSE 步骤进度 → 前端展示 + 结果落库，图谱保鲜 Agent 在后台定时保持图谱与线上/测试库一致；
2）数据流向：用户自然语言指令 → 门户会话接口 → 编排层 →（图谱推荐 Agent → 数据工厂 Agent → 限额智验 Agent 调 Java 引擎校验 → 结果对比）→ SSE 步骤进度 → 前端展示 + 结果落库，图谱保鲜 Agent 在后台定时保持图谱与线上/测试库一致；
3.2.2 数据工厂Agent技术实现：
1）Agent能力设计：自然语言一键触发造数-调用业务造数接口-测试数据预加载内存库，自动化构建触发限额测试数据；
2）性能提升设计：测试数据提前预加载到内存数据库中，减少 Oracle 重复查询，提升查询速度；
2）性能提升设计：测试数据提前预加载到内存数据库中，减少 Oracle 重复查询，提升查询速度；
3.2.3 限额智验 Agent技术实现：
1）Agent能力设计：串联"图谱推荐 → 一键造数 → 限额校验 → 结果对比 → 前端展示"闭环；
2）性能提升设计：限额计算校验逻辑由原始oracle内的sql计算改为java程序在Ignite 内存中计算校验；
2）性能提升设计：限额计算校验逻辑由原始oracle内的sql计算改为java程序在Ignite 内存中计算校验；
4. 关键成效与项目收益：
4.1 整体进展：
1）基于Harness和AgentScope完成一套高性能、精准可度量的Multi-Agent 限额智验质量门户搭建，自430基础框架上线以来，已经纳入5个版本回归测试，支持新需求测试3个（双周周期迭代版本，并非每个版本都有限额新需求），需求上线后限额计算均符合预期；
4.2 使用效果：
4.2.1 场景支持和质量提升：
1）支持银行理财资管限额模块100%回归测试；
2）线上缺陷逃逸率下降60%（由5%->2%）；
2）线上缺陷逃逸率下降60%（由5%->2%）；
4.2.2 性能和效率提升：
1）Multi-Agent 限额智验质量门户相对传统自动化执行效率提升了120倍，时间节省率为99.17%；（统计口径：跑同样9条条目所花费的时间，传统自动化花费6h，新自动化框架花费3min，时间节省率=（360-3）/360*100%=99.1667%，效率提升倍数=360/3=120倍）
4.2.3 节省人力：
1）资管限额模块回归测试100%交由Multi-Agent 限额智验质量门户执行，约节省120人日/年；
2）将银行理财资管限额模块测试人力投入由2减少到1人；
2）将银行理财资管限额模块测试人力投入由2减少到1人；
5. 未来展望
5.1 智能能力深化
1）新增“变更影响分析+校验用例自动生成“Agent：因为限额计算逻辑较复杂，目前校验限额计算脚本仍然是人工编写，编写速度较慢，后续会对限额计算的各类条件规则、计算方式等进行建模，实现从需求变更分析到校验用例脚本的自动生成，提高校验脚本的沉淀速度，将保鲜从"图谱"扩展到"用例/因子口径"全域保鲜；
2）新增结果根因分析 Agent：支持报告自动生成与风险预警，版本回归结束后自动产出覆盖范围、通过率、差异明细的质量报告，异常条目自动预警；自动定位校验失败是数据、规则、引擎哪一环节，输出归因结论与处理建议，替代人工排查；
2）新增结果根因分析 Agent：支持报告自动生成与风险预警，版本回归结束后自动产出覆盖范围、通过率、差异明细的质量报告，异常条目自动预警；自动定位校验失败是数据、规则、引擎哪一环节，输出归因结论与处理建议，替代人工排查；
5.2 建设可运营、可度量的质量门户体系
1）后续将围绕质量门户补充更多运营指标和看板能力，包括任务执行次数、版本回归覆盖率、自动化通过率、失败原因分布、节省人力、执行耗时趋势等，让限额自动化从工具建设升级为质量运营体系。通过统一门户沉淀过程数据，为后续质量改进、测试策略优化和管理决策提供数据支撑。
1）后续将围绕质量门户补充更多运营指标和看板能力，包括任务执行次数、版本回归覆盖率、自动化通过率、失败原因分布、节省人力、执行耗时趋势等，让限额自动化从工具建设升级为质量运营体系。通过统一门户沉淀过程数据，为后续质量改进、测试策略优化和管理决策提供数据支撑。
听众收益：
1. 一套"图谱血缘定范围"的智能回归方法论：掌握用 DSL+YAML 将复杂金融规则抽象为 rule_id+formula+metrics、构建知识图谱血缘，并基于 Graph RAG 从需求变化自动召回测试/回归范围的完整做法，直接解决"变更影响面难评估、回归是否完整无度量"的行业难题。
2. "Harness 保鲜"的 AI 工程化实践：学会如何把 AI Coding 从"对话式生成"约束为"有输入、有步骤、有校验、有产物"的工程流程，用强 Agent 自动同步库差异、更新 YAML、刷新图谱，解决 AI 系统上线后"规则漂移、图谱过期、越跑越脏"的核心痛点。
3. 掌握 Multi-Agent 质量门户的工程实现方法：学习如何基于 AgentScope 将知识图谱智能引擎 Agent、知识图谱保鲜 Agent、数据工厂 Agent 和限额智验 Agent 串联起来，实现“自然语言入口 -> 图谱保鲜 -> 范围推荐 -> 一键造数 -> 自动化校验 -> 结果分析”的端到端闭环。
1. 一套"图谱血缘定范围"的智能回归方法论：掌握用 DSL+YAML 将复杂金融规则抽象为 rule_id+formula+metrics、构建知识图谱血缘，并基于 Graph RAG 从需求变化自动召回测试/回归范围的完整做法，直接解决"变更影响面难评估、回归是否完整无度量"的行业难题。
2. "Harness 保鲜"的 AI 工程化实践：学会如何把 AI Coding 从"对话式生成"约束为"有输入、有步骤、有校验、有产物"的工程流程，用强 Agent 自动同步库差异、更新 YAML、刷新图谱，解决 AI 系统上线后"规则漂移、图谱过期、越跑越脏"的核心痛点。
3. 掌握 Multi-Agent 质量门户的工程实现方法：学习如何基于 AgentScope 将知识图谱智能引擎 Agent、知识图谱保鲜 Agent、数据工厂 Agent 和限额智验 Agent 串联起来，实现“自然语言入口 -> 图谱保鲜 -> 范围推荐 -> 一键造数 -> 自动化校验 -> 结果分析”的端到端闭环。
黄举光
中兴通讯 有线研究院技术教练
中兴通讯有线研究院技术教练，主要负责数据中心自动化测试平台的设计和开发，AI辅助测试技术的探索、工程化落地，包括不限于测试智能体框架的设计、记忆系统的规划和设计、知识工程建设等等。
待定
待定
共生伙伴：重构测试交付模式的人机协同智能体实践
议题背景：
数通产品测试面临组网灵活、步骤繁多、知识分散的固有挑战，交付压力持续增长（需求+52%、人力-18%），传统提效手段已到瓶颈。我们构建了"共生伙伴"——端到端测试交付智能体系统，通过知识逆构、AI+Web融合、通用测试仪接口界
面化、流程中知识生产等关键技术，重构"人找工具"的测试交付模式为人机协同模式，实现脚本生成采纳率85%+、AI累计生成代码200W+行、测试效率提升30%的效果。
本分享将完整呈现系统的工程实践——从知识定义、低成本知识生产、人机协同消费到知识自动沉淀的完整闭环，以及落地中的踩坑经验与量化效果，为测试智能化提供可复用的方法论。
内容大纲：
1. 为什么需要重构测试交付模式
数通产品测试面临组网灵活、步骤繁多、知识分散的固有挑战，交付压力持续增长（需求+52%、人力-18%），传统提效手段已到瓶颈。我们构建了"共生伙伴"——端到端测试交付智能体系统，通过知识逆构、AI+Web融合、通用测试仪接口界
面化、流程中知识生产等关键技术，重构"人找工具"的测试交付模式为人机协同模式，实现脚本生成采纳率85%+、AI累计生成代码200W+行、测试效率提升30%的效果。
本分享将完整呈现系统的工程实践——从知识定义、低成本知识生产、人机协同消费到知识自动沉淀的完整闭环，以及落地中的踩坑经验与量化效果，为测试智能化提供可复用的方法论。
内容大纲：
1. 为什么需要重构测试交付模式
1.1 数通测试的核心矛盾：需求+52%、人力-18%的交付压力
1.2 传统模式的瓶颈：知识分散、脚本开发耗时、提效到顶
1.3 重构思路：从"人找工具"到"人机协同"的范式转变
2. 知识定义：标准化的"业务积木"
2.1 知识单元的标准化：意图→动作的内聚业务逻辑
2.2 为什么要素因子库方案失败（2000+特性需363.6人月，依赖专家）
2.3 踩坑：同义不同名/同名不同义导致的语义映射错误
3. 知识生产：机器翻译+人工审核的逆构模式
3.1 存量脚本/手册的逆向解构（高熵→低熵）
3.2 工具提取初稿、人校正终稿的低成本生产
3.3 知识提纯：膨胀倍数差异与轻量级近似匹配
3.4 量化：知识生产人力成本降低（数据）
4. 知识消费：AI+Web融合的人机协同
4.1 页面即上下文、对话即操作
4.2 上下文管理：设备/用例/执行/知识四类上下文注入
4.3 通用测试仪API界面化：一份操作、多厂商通用
4.4 人机协同工作界面：挂起→呼叫人工、接受→人工恢复
4.5 踩坑：AI幻觉、上下文注入时机、Web页面与AI请求的衔接
5. 知识沉淀：流程中自动生产
5.1 新增知识在验证流程中自动生产
5.2 存量知识一处修改、全局同步
5.3 闭环验证机制
6. 效果与数据
6.1 核心指标：采纳率85%+、AI代码200W+行、效率+30%
6.2 质量指标：零因脚本问题泄露的故障、交付质量+16%
6.3 规模指标：覆盖900+需求、8000+用例
6.4 未达预期的尝试与反思
7. 未来展望
7.1 从"人找智能体"到"智能体驱动人评审决策"
7.2 知识飞轮：端到端知识贯通、度量反馈闭环
7.3 人机协作共生：可观测、可追溯、可进化的新范式
听众收益：
1. 重构测试交付模式的完整方法论：掌握"知识定义→知识生产→知识消费→知识沉淀"的全流程设计，理解人机协同如何替代传统"人找工具"模式，可迁移到其他研发领域。
1. 重构测试交付模式的完整方法论：掌握"知识定义→知识生产→知识消费→知识沉淀"的全流程设计，理解人机协同如何替代传统"人找工具"模式，可迁移到其他研发领域。
2. 知识工程低成本落地的实操方法：学习"机器翻译+人工审核"的知识逆构生产模式，解决知识建设成本高、依赖专家的行业难题，含知识提纯、近似匹配等踩坑经验。
3. 量化效果与可复用的架构参考：了解共生伙伴的三层架构（Master-Agent/Sub-Agent/Skill+MCP）、AI+Web融合、通用测试仪API界面化等关键技术选型，以及85%+采纳率等真实数据支撑。
李颖超
小红书 AI 工程架构师
小红书创新孵化实验室 AI 工程架构师，长期专注于移动端与多端协同场景的质量工程建设。近期聚焦 AI Native 研发模式下的质量保障，开展测试智能体的架构设计与工程落地，探索融合业务知识、质量策略与动态执行的智能化验证体系。关注复杂需求下的测试覆盖、执行可靠性与人机协作效率，推动质量工程能力融入 AI 研发流程，构建从需求分析到真实业务验证的智能化质量闭环。
待定
待定
小红书创新产品的 AI Native 质量工程实践
议题背景：
AI Coding 提升了代码交付速度，但需求验证并没有同步提速。以小红书创新 App 的需求验证过程为例，现有能力仍以单点工具为主：用例生成只能产出测试文本；E2E 自动化仍需要人工编写自然语言用例并反复调试，其配置成本往往不低于直接完成一次人工验证；日志查询、接口测试和数据准备也需要在测试过程中分别操作。这些工具之间没有共享需求理解、验证范围和执行结果，最终仍由 QA 人工串联测试设计、前置准备、能力选择、执行和结果判断，难以跟上 Coding Agent 的出码速度。
为解决这个问题，我们构建了一个 Quality Engineering Agent。它不是再增加一个需要 QA 单独操作的测试工具，而是直接从原始需求开始：先检查需求是否完整、清楚且可以验证，信息不足时向人工提出具体问题，并将确认结果整理成可信的验证上下文。Agent 通过解析 iOS、Android、RN 和后端代码，建立连接页面、路由、状态、接口与服务的多端质量知识图谱，并通过真机执行持续校准。Agent 据此生成和检查测试设计，将场景映射到代码检查、日志、接口、造数、Mock 和真机 E2E 等能力；执行前统一检查账号、数据、设备和环境，再通过动态 Quality DAG 组织执行和结果判断。
AI Coding 提升了代码交付速度，但需求验证并没有同步提速。以小红书创新 App 的需求验证过程为例，现有能力仍以单点工具为主：用例生成只能产出测试文本；E2E 自动化仍需要人工编写自然语言用例并反复调试，其配置成本往往不低于直接完成一次人工验证；日志查询、接口测试和数据准备也需要在测试过程中分别操作。这些工具之间没有共享需求理解、验证范围和执行结果，最终仍由 QA 人工串联测试设计、前置准备、能力选择、执行和结果判断，难以跟上 Coding Agent 的出码速度。
为解决这个问题，我们构建了一个 Quality Engineering Agent。它不是再增加一个需要 QA 单独操作的测试工具，而是直接从原始需求开始：先检查需求是否完整、清楚且可以验证，信息不足时向人工提出具体问题，并将确认结果整理成可信的验证上下文。Agent 通过解析 iOS、Android、RN 和后端代码，建立连接页面、路由、状态、接口与服务的多端质量知识图谱，并通过真机执行持续校准。Agent 据此生成和检查测试设计，将场景映射到代码检查、日志、接口、造数、Mock 和真机 E2E 等能力；执行前统一检查账号、数据、设备和环境，再通过动态 Quality DAG 组织执行和结果判断。
内容大纲：
1. 背景
代码变快了，验证没有同步变快：AI Coding 缩短了代码实现时间，但质量验证并没有同步提速。 在小红书创新 App 的需求验证过程中，现有测试能力仍以单点工具为主。用例生成大多直接从 PRD 产出文本用例，缺少需求澄清和实际工程链路等上下文，生成结果仍需要 QA 大量补充和修改；E2E 自动化仍需要人工编写自然语言用例并反复调试；日志查询、接口测试和数据准备也需要分别操作。工具之间不共享需求理解、验证范围和执行结果，仍需要 QA 人工串联，因此没有真正缩短一个需求从分析到完成验证的时间。
目标：从 QA 人工串联走向 Agent 驱动的 Quality Engineering： 要解决的不仅是增加一个测试工具，而是让 Agent 从需求开始，连接测试设计、工程知识、验证能力和结果判断，把原本每个需求都要人工重新组织的质量工作变成一条可执行、可复用的工程链路，缩短需求从分析到完成验证的时间。
目标：从 QA 人工串联走向 Agent 驱动的 Quality Engineering： 要解决的不仅是增加一个测试工具，而是让 Agent 从需求开始，连接测试设计、工程知识、验证能力和结果判断，把原本每个需求都要人工重新组织的质量工作变成一条可执行、可复用的工程链路，缩短需求从分析到完成验证的时间。
2. 可信验证上下文：让 Agent 明确要验证什么
我们先不让 Agent 急着进入测试设计，而是先让它审一遍需求。把需求里已经写出的用户操作、结果、条件等拆开看，检查它们能否组成一条清楚、没有矛盾、可以被确认的描述。比如，写了用户点击却没写会看到什么结果；写了“满足某条件”却没写条件下的具体行为；发现这类缺口后，Agent 会带着具体问题向人工确认，确认后的结果沉淀为本次需求的质量基准，后续测试设计和验证执行都以它为准。
3. 多端质量知识图谱：让 Agent 找到验证链路
起点：先让 Agent 知道“这个需求应该去哪里验”。最初，我们做的是页面知识快照。它像一份可检索的目录：Agent 能找到相关页面或代码，却不知道这些信息之间如何组成一条真实验证链路。比如一个“添加地点”需求，Agent 可能找到了地点页面，却不知道这个页面从哪个入口进入，入口出现是否有条件。结果要么由 Agent 自己猜路径，要么仍需要人工把这些上下文提前串起来。
演进：从页面知识快照变成多端质量知识图谱。 我们不再只记录页面和路由，而是把一次用户行为涉及的入口、经过的原生或 RN 页面、页面之间的跳转和关键状态，以及调用的接口、承接请求的后端服务，按照它们之间的关系连成一张有向图。这样，Agent 面对一个具体需求时，就不只是定位到一个相关页面，而是能拿到已有的入口、路径和关联信息。
持续校准：代码每天变化，只构建一次图谱远远不够。我们目前按版本刷新四端源码 Diff，按周更新图中的页面、控件、路由、接口及调用关系，并将变化先保留为候选知识；再由 Agent 在真机上验证这些候选路径，让已失效的关系及时降级或淘汰。
演进：从页面知识快照变成多端质量知识图谱。 我们不再只记录页面和路由，而是把一次用户行为涉及的入口、经过的原生或 RN 页面、页面之间的跳转和关键状态，以及调用的接口、承接请求的后端服务，按照它们之间的关系连成一张有向图。这样，Agent 面对一个具体需求时，就不只是定位到一个相关页面，而是能拿到已有的入口、路径和关联信息。
持续校准：代码每天变化，只构建一次图谱远远不够。我们目前按版本刷新四端源码 Diff，按周更新图中的页面、控件、路由、接口及调用关系，并将变化先保留为候选知识；再由 Agent 在真机上验证这些候选路径，让已失效的关系及时降级或淘汰。
4. 结构化测试设计驱动动态执行图：让 Agent 规划并完成验证
测试设计规划（Task Planning）：Agent 消费第一阶段形成的可信验证上下文，将每个需求点展开为用户操作、触发条件、预期结果和异常处理；再借助质量图谱定位相关页面、接口及服务，确定客户端、接口或日志的核对方式。由此形成包含前置账号和数据依赖、操作路径、预期结果、检查点及清理动作的测试场景。这是后续执行图生成节点和边的前置依赖。
测试设计校验与受约束修复（Plan Validation / Plan Repair）：为避免生成“看起来完整”的测试设计，Agent 会逐项检查生成的测试场景是否有遗漏，是否可执行，发现问题允许一次不丢失既有覆盖的局部修复。
能力解析与执行前就绪检查（Preflight / Readiness）：Agent 将测试场景中的操作和检查点映射到能力目录中的代码检查、接口、日志、Mock 和真机 E2E 等验证能力；数据依赖则由数据操作器注册表匹配具体的准备、校验和清理方式。执行前统一检查账号、数据、设备、环境、权限和页面定位，将场景标记为可执行、准备后可执行或阻塞，并将结果作为动态 DAG 的编排约束。
执行计划生成与逻辑 DAG 构建（Constrained Planning / Task Graph Construction）： Agent 基于测试设计和 Preflight 结果，先明确每个场景要验证什么、必须获得哪些观察结果；再规划所需能力、输入输出、前置依赖和清理动作。图编译器根据节点的输入输出和验证关系建立依赖边，明确哪些准备必须先完成、哪些验证可以并行、哪些结果决定后续分支，以及失败后如何回收。
动态 DAG 编排与执行（DAG Orchestration / Workflow Execution）： 进入执行阶段后，Agent Runtime 将逻辑 DAG 与当前可用的账号、数据、设备、环境和权限绑定，并补齐数据或 Mock 的准备、校验和回收任务，生成实际运行的动态 Quality DAG。执行过程中，前序结果或阻塞会决定后续任务是继续、调整还是停止，执行结束后，按需求点逐项给出验证结果，并说明发现的问题、缺少的条件和尚未完成的验证。
执行结果校验与交付判定（Verification / Evaluation）：执行完成后，Agent 将每条执行结果与对应的测试场景、检查点和运行记录逐项核对。最终报告会分别列出已验证的需求点、发现的产品缺陷、阻塞测试的具体条件、尚未执行的场景及其原因，以及数据和环境是否完成恢复。
测试设计校验与受约束修复（Plan Validation / Plan Repair）：为避免生成“看起来完整”的测试设计，Agent 会逐项检查生成的测试场景是否有遗漏，是否可执行，发现问题允许一次不丢失既有覆盖的局部修复。
能力解析与执行前就绪检查（Preflight / Readiness）：Agent 将测试场景中的操作和检查点映射到能力目录中的代码检查、接口、日志、Mock 和真机 E2E 等验证能力；数据依赖则由数据操作器注册表匹配具体的准备、校验和清理方式。执行前统一检查账号、数据、设备、环境、权限和页面定位，将场景标记为可执行、准备后可执行或阻塞，并将结果作为动态 DAG 的编排约束。
执行计划生成与逻辑 DAG 构建（Constrained Planning / Task Graph Construction）： Agent 基于测试设计和 Preflight 结果，先明确每个场景要验证什么、必须获得哪些观察结果；再规划所需能力、输入输出、前置依赖和清理动作。图编译器根据节点的输入输出和验证关系建立依赖边，明确哪些准备必须先完成、哪些验证可以并行、哪些结果决定后续分支，以及失败后如何回收。
动态 DAG 编排与执行（DAG Orchestration / Workflow Execution）： 进入执行阶段后，Agent Runtime 将逻辑 DAG 与当前可用的账号、数据、设备、环境和权限绑定，并补齐数据或 Mock 的准备、校验和回收任务，生成实际运行的动态 Quality DAG。执行过程中，前序结果或阻塞会决定后续任务是继续、调整还是停止，执行结束后，按需求点逐项给出验证结果，并说明发现的问题、缺少的条件和尚未完成的验证。
执行结果校验与交付判定（Verification / Evaluation）：执行完成后，Agent 将每条执行结果与对应的测试场景、检查点和运行记录逐项核对。最终报告会分别列出已验证的需求点、发现的产品缺陷、阻塞测试的具体条件、尚未执行的场景及其原因，以及数据和环境是否完成恢复。
5. 真实业务效果
测试分析与执行效率：以一个测试数据准备复杂的双端需求为例，人工从理解需求到完成测试分析、设计和双端验证，通常需要约 1～1.5 人日。Agent 首次完成测试规划耗时 22～30 分钟；在同一需求的后续迭代中，执行计划可在 10～17 秒内重新生成，双端真机第一轮验证约 21 分钟，将原本需要人工串联一天以上的分析、规划与执行工作压缩到 1 小时以内。
验证代价：一个双端需求使用高能力模型在 1 小时内完成首次验证时，消耗约几十万 Token。测试设计、审查与执行计划生成占 43.6%，真机执行监督占 47.7%，截图和 UI 树等界面观察占 8.7%。同一需求再次验证时可复用已有规划，Token 消耗减少约 43.6%。下一阶段将通过上下文裁剪和模型分级，保留高能力模型处理复杂判断，常规执行交给轻量模型或确定性能力，进一步降低运行成本。
知识规模与召回效果：四端源码分析形成 1 万+条功能映射和 7000+条行为候选，使用用户操作描述检索时，Top-1 命中率为 96.3%，Top-3 为 99.4%，Top-5 达到 100%。
验证代价：一个双端需求使用高能力模型在 1 小时内完成首次验证时，消耗约几十万 Token。测试设计、审查与执行计划生成占 43.6%，真机执行监督占 47.7%，截图和 UI 树等界面观察占 8.7%。同一需求再次验证时可复用已有规划，Token 消耗减少约 43.6%。下一阶段将通过上下文裁剪和模型分级，保留高能力模型处理复杂判断，常规执行交给轻量模型或确定性能力，进一步降低运行成本。
知识规模与召回效果：四端源码分析形成 1 万+条功能映射和 7000+条行为候选，使用用户操作描述检索时，Top-1 命中率为 96.3%，Top-3 为 99.4%，Top-5 达到 100%。
6. 实践痛点
多端质量知识图谱难在跨仓库关系的准确生成。 各端内部的页面、路由和调用关系可以分别提取，但跨越原生、RN、网关和后端的关系没有统一标识。如何利用明确的路由、接口和 RPC 锚点连接完整链路，同时识别断边、多候选和错误关联，是图谱构建阶段需要重点解决的问题。
多端质量知识图谱持续演化的难点：真机校准成本高。 源码节点和调用关系可以按版本批量更新，但代码变化只能说明某条行为路径可能受到影响。要确认这条路径当前仍然可用，Agent 需要从真实入口在真机完成操作，记录操作轨迹、截图和 UI 树，并在需要时核对接口或后端结果。如何根据代码变化找出真正受影响的行为路径，只重新校准其中高风险的部分，是图谱持续演化的核心难点。
测试设计容易“看起来完整”。 Agent 可以生成结构清晰的测试场景，但仍可能漏掉状态分支、异常处理、端别差异或关键结果。设计内容多不代表需求覆盖完整，因此需要独立检查每个需求点是否都有对应场景，并通过受约束修复补充遗漏。
动态执行图难在找到合适的能力组合。面对一个测试目标，Agent 需要在造数、Mock、接口、日志和真机等能力之间规划路径。它可能找不到形成目标数据状态的正确造数链路，也可能在一种验证方式走不通时，没有找到其他可行方式。难点是让 Agent 知道每项能力能确认什么、需要哪些条件，并选择当前真正可执行的验证路径。
多端质量知识图谱持续演化的难点：真机校准成本高。 源码节点和调用关系可以按版本批量更新，但代码变化只能说明某条行为路径可能受到影响。要确认这条路径当前仍然可用，Agent 需要从真实入口在真机完成操作，记录操作轨迹、截图和 UI 树，并在需要时核对接口或后端结果。如何根据代码变化找出真正受影响的行为路径，只重新校准其中高风险的部分，是图谱持续演化的核心难点。
测试设计容易“看起来完整”。 Agent 可以生成结构清晰的测试场景，但仍可能漏掉状态分支、异常处理、端别差异或关键结果。设计内容多不代表需求覆盖完整，因此需要独立检查每个需求点是否都有对应场景，并通过受约束修复补充遗漏。
动态执行图难在找到合适的能力组合。面对一个测试目标，Agent 需要在造数、Mock、接口、日志和真机等能力之间规划路径。它可能找不到形成目标数据状态的正确造数链路，也可能在一种验证方式走不通时，没有找到其他可行方式。难点是让 Agent 知道每项能力能确认什么、需要哪些条件，并选择当前真正可执行的验证路径。
7. 前沿亮点
可信上下文驱动的测试规划：Agent 先将需求、技术方案等整理成可追溯的测试上下文，信息不足时发起澄清；再据此生成结构化测试设计，并通过校验与受约束修复补充遗漏，为后续能力选择和动态 DAG 提供输入。
用多端质量知识图谱定位完整验证链路：连接原生页面、RN、接口、网关、RPC 和后端实现，使 Agent 能沿工程关系寻找验证范围，而不只依赖文档召回。
基于能力目录的动态测试编排：Agent 将测试设计映射到造数、Mock、接口、日志和真机等能力，根据验证目标、前置条件和执行结果选择并调整能力组合，生成动态 Quality DAG。
用多端质量知识图谱定位完整验证链路：连接原生页面、RN、接口、网关、RPC 和后端实现，使 Agent 能沿工程关系寻找验证范围，而不只依赖文档召回。
基于能力目录的动态测试编排：Agent 将测试设计映射到造数、Mock、接口、日志和真机等能力，根据验证目标、前置条件和执行结果选择并调整能力组合，生成动态 Quality DAG。
听众收益：
1. 获得一套从需求到真实执行的智能测试架构：理解可信上下文、结构化测试设计、多端质量图谱、能力目录和动态 Quality DAG 如何串成完整链路。
2. 掌握面向 Agent 的测试规划方法：学习如何发现需求信息缺口，约束模型生成测试设计，并通过 Plan Validation 与 Plan Repair 补充遗漏。
3. 多端知识与动态编排的实现思路：了解如何连接原生、RN、接口与后端，以及如何将造数、Mock、日志和真机等能力按需组合。
瞿曦超
华泰证券 开发工程师
华泰证券股份有限公司信息技术部测试交付中心-软件质量控制团队开发工程师，目前主要负责测试交付工具的建设与运营，涵盖日志回放平台、模糊测试、自动化测试、性能测试、测试知识库等核心工具建设，保障公司交易系统、业务系统的稳定性与测试质量，持续提升测试场景覆盖度与工作质效。毕业后即加入华泰证券信息技术部，早期曾从事FICC业务线开发工作。
待定
待定
证券交易领域测试 Skill 的进化体系与知识底座支撑实践
议题背景：
证券交易系统业务复杂、迭代快、质量要求高。大模型应用于测试场景，通用能力难以直接适配具体业务系统，测试Skill需要在真实使用中持续打磨、不断进化，才能真正发挥价值。
我们围绕测试Skill的进化，建设了从使用、标注到自训练的全链路能力：使用人员对Skill输出结果进行标注，标注信息驱动Skill自我训练与迭代优化，形成”越用越准”的进化闭环。目前该体系已在5个交易系统投产10+个系统级技能，覆盖需求分析、测试设计、用例生成与执行等环节。
与进化体系配套，建设知识底座：业务文档、代码、交易所规则等多源知识统一纳管，配套混合检索与场景化验收机制保障知识供给质量。
本议题分享”进化体系＋知识底座”的设计思路、差异化做法与量化成效。
内容大纲：
1. 背景与思路
证券交易系统业务复杂、迭代快、质量要求高。大模型应用于测试场景，通用能力难以直接适配具体业务系统，测试Skill需要在真实使用中持续打磨、不断进化，才能真正发挥价值。
我们围绕测试Skill的进化，建设了从使用、标注到自训练的全链路能力：使用人员对Skill输出结果进行标注，标注信息驱动Skill自我训练与迭代优化，形成”越用越准”的进化闭环。目前该体系已在5个交易系统投产10+个系统级技能，覆盖需求分析、测试设计、用例生成与执行等环节。
与进化体系配套，建设知识底座：业务文档、代码、交易所规则等多源知识统一纳管，配套混合检索与场景化验收机制保障知识供给质量。
本议题分享”进化体系＋知识底座”的设计思路、差异化做法与量化成效。
内容大纲：
1. 背景与思路
1.1 证券交易领域测试AI落地的挑战：通用能力与业务系统之间的差距
1.2 我们的思路：从”建能力”到”养能力”，让Skill在使用中持续进化
1.2 我们的思路：从”建能力”到”养能力”，让Skill在使用中持续进化
2. 测试Skill进化体系
2.1 输出标注与反馈链路：测试人员标注Skill产出，反馈自归集形成问题台账（投产案例：“使用—反馈—优化”闭环运转）
2.2 基于标注信息的Skill自训练：问题自识别、能力自优化、质量自评测、运营结果自评估的进化机制
2.3 Skill全链路闭环：需求分析、测试设计、用例生成、风险识别4类Skill标准化拆分，统一嵌入测试管理平台，已支撑10+个系统级技能投产
2.2 基于标注信息的Skill自训练：问题自识别、能力自优化、质量自评测、运营结果自评估的进化机制
2.3 Skill全链路闭环：需求分析、测试设计、用例生成、风险识别4类Skill标准化拆分，统一嵌入测试管理平台，已支撑10+个系统级技能投产
3. 知识底座支撑
3.1 知识库建设：业务文档、代码、交易所规则多源知识统一纳管
3.2 知识的动态补充与更新：增量更新管线保障知识常新
3.3 知识质量保障：混合检索，自进化审计驱动知识库持续调优
3.2 知识的动态补充与更新：增量更新管线保障知识常新
3.3 知识质量保障：混合检索，自进化审计驱动知识库持续调优
4. 应用成效与展望
4.1 量化成效：全流程贯通试用采纳率、测试设计采纳率
4.2 展望：Skill全链路闭环的完善与向更多业务系统的复制推广
4.2 展望：Skill全链路闭环的完善与向更多业务系统的复制推广
听众收益：
1. 了解测试Skill”使用—标注—自训练”进化体系的完整设计
2. 了解知识底座在多源知识纳管、动态更新、质量保障方面的工程实践与量化效果
3. 为金融测试团队规划AI能力的持续演进提供参考
1. 了解测试Skill”使用—标注—自训练”进化体系的完整设计
2. 了解知识底座在多源知识纳管、动态更新、质量保障方面的工程实践与量化效果
3. 为金融测试团队规划AI能力的持续演进提供参考
齐佩之
华为 测试专家
华为技术有限公司GTS业务体验领域测试专家，长期在测试技术和测试工程能力领域深耕，Web GUI测试能力构建，从Web低码和无码自动化写作->LLM辅助自主探索测试->基于多模态的文本用例自主测试Agent，在多个领域广泛使用。
待定
待定
基于多模态 Agent 的Web UI 智能化测试实践
——实现“版本转测即执行，执行即脚本，脚本即资产”
议题背景：
Web UI 产品的快速迭代特性使得传统自动化测试面临开发成本高、维护工作量大、DOM 变更导致脚本失效等困境。针对行业痛点，我们创新性的构建了基于多模态 Agent 的智能自动化测试系统，融合页面截图、DOM 结构和 OCR 文字识别，实现编号和坐标双重定位能力，统一支持 canvas 画布、GIS地图、无标签元素等复杂元素识别。通过感知、规划、校验、反思多Agent协同等机制实现文本用例自主执行与智能判断，无需人工开发维护自动化脚本。本方案已在公司多个业务线落地应用，页面元素识别率达到 90 %+，一次成功率 70 %+，月度自动执行用例 4万+，实现版本转测即自动执行，执行即可生成脚本，脚本免维护的全自动化闭环，为 Web UI测试提供了全新的技术范式。
内容大纲：
1. 业务痛点与行业技术现状分析
内容大纲：
1. 业务痛点与行业技术现状分析
1.1 Web UI 测试的核心痛点：快速迭代与传统自动化的根本矛盾
1.2 行业主流自动化技术方案对比：录制回放、代码框架、低码平台的局限性
1.3 技术范式演进需求：从依赖 dom 定位到 AI 智能理解
1.2 行业主流自动化技术方案对比：录制回放、代码框架、低码平台的局限性
1.3 技术范式演进需求：从依赖 dom 定位到 AI 智能理解
2. 整体技术方案与创新突破
2.1 核心概念：让 AI 像人一样看懂、理解、自主执行
2.2 三大创新突破：执行范式、维护范式、能力门槛的全面突破
2.3 方案架构：多 Agent 协同+多模态识别+知识库智能检索
2.2 三大创新突破：执行范式、维护范式、能力门槛的全面突破
2.3 方案架构：多 Agent 协同+多模态识别+知识库智能检索
3. 关键技术创新
3.1 多模态元素识别技术（核心创新）
技术原理：页面截图+DOM结构+OCR文字识别的多模态融合
技术差异对比：与传统方案在定位方式、复杂元素支持、无标签元素识别上的优势
实践效果：统一支持表单、Canvas、GIS地图等各类元素
技术差异对比：与传统方案在定位方式、复杂元素支持、无标签元素识别上的优势
实践效果：统一支持表单、Canvas、GIS地图等各类元素
3.2 多 Agent 协同机制
Agent 角色分工：规划 Agent、感知Agent、校验Agent，反思Agent
协同创新：任务记忆共享、交叉验证、早判断机制、阻塞自愈
对比优势：动态规划自适应 vs 传统脚本线性执行
协同创新：任务记忆共享、交叉验证、早判断机制、阻塞自愈
对比优势：动态规划自适应 vs 传统脚本线性执行
3.3 skill 知识库智能检索
按需渐进加载：降低冷启动时间，按需扩展能力
阻塞自检索：遇到执行阻塞自动补充领域知识
对比优势：Agent 能力动态生长 vs 传统架构预制操作库
阻塞自检索：遇到执行阻塞自动补充领域知识
对比优势：Agent 能力动态生长 vs 传统架构预制操作库
4. 应用效果与价值对比
4.1 核心应用指标：元素识别率 90%+，一次成功率 70%+，月执行用例 4 万+
4.2 核心价值实现：版本转测即执行、执行即生成脚本、页面变更自适应
4.3 效率提升对比：总体交付周期从 3-4 周缩短至 1-2 天，提升 10 倍+
4.2 核心价值实现：版本转测即执行、执行即生成脚本、页面变更自适应
4.3 效率提升对比：总体交付周期从 3-4 周缩短至 1-2 天，提升 10 倍+
5. 技术创新亮点总结
5.1 范式创新：从代码自动化到智能体自动化
5.2 技术创新：多模态融合定位与多 agent 协同执行
5.3 工程创新：skill 按需加载与知识库检索
5.2 技术创新：多模态融合定位与多 agent 协同执行
5.3 工程创新：skill 按需加载与知识库检索
6. 适用场景与未来规划
6.1 适用场景：快速迭代的 web 产品、测试自动化转型的团队
6.2 未来规划：扩展移动端、融合性能安全检测、构建测试知识图谱
6.2 未来规划：扩展移动端、融合性能安全检测、构建测试知识图谱
郭宁宁
百度 测试开发工程师
百度测试开发工程师；一直致力于服务端、端到端测试
待定
待定
从单点测试能力、端到端任务执行，到可信可控的 Agent 自进化体系
议题背景:
AIQA作为智能研发四层框架中的质量保障层，度小智作为AIQA面向真实测试场景打造的智能测试Agent，正在尝试让AI从一张需求卡片出发，自动完成需求理解、风险分析、Case生成、环境准备、测试执行、缺陷识别和质量报告。
但当Agent从“辅助生成”走向“自主执行”，新的问题也随之出现：Agent声称完成是否等于真实完成？长流程能否在会话结束后继续运行？多个Skill如何稳定协作？如何避免重复建Bug？线上失败又如何转化为下一轮能力改进？
本次分享将结合真实任务案例，介绍AIQA与度小智从单点能力建设到端到端质量闭环的演进过程，并重点分享我们如何通过确定性Workflow、结构化状态、独立结果判定、真实执行证据和Skill进化机制，让智能测试逐步实现“能执行、能闭环、结果可信、持续进化”。
内容大纲:
1. 智能测试不是一个大模型加一个Prompt
AIQA作为智能研发四层框架中的质量保障层，度小智作为AIQA面向真实测试场景打造的智能测试Agent，正在尝试让AI从一张需求卡片出发，自动完成需求理解、风险分析、Case生成、环境准备、测试执行、缺陷识别和质量报告。
但当Agent从“辅助生成”走向“自主执行”，新的问题也随之出现：Agent声称完成是否等于真实完成？长流程能否在会话结束后继续运行？多个Skill如何稳定协作？如何避免重复建Bug？线上失败又如何转化为下一轮能力改进？
本次分享将结合真实任务案例，介绍AIQA与度小智从单点能力建设到端到端质量闭环的演进过程，并重点分享我们如何通过确定性Workflow、结构化状态、独立结果判定、真实执行证据和Skill进化机制，让智能测试逐步实现“能执行、能闭环、结果可信、持续进化”。
内容大纲:
1. 智能测试不是一个大模型加一个Prompt
1.1 真正的智能测试需要：
1.2 模型推理能力
1.2 模型推理能力
1.2.1 测试领域Skill
1.2.2 确定性Workflow
1.2.3 外部执行平台
1.2.4 状态和证据体系
1.2.5 验证与发布治理
1.2.3 外部执行平台
1.2.4 状态和证据体系
1.2.5 验证与发布治理
1.3 模型适合处理理解、分析和决策；确定性系统负责状态、顺序、幂等、校验和恢复。
2. Agent说“完成”不等于任务真的完成
2.1 测试成功必须由真实证据证明：
2.1.1 是否生成正式Case；
2.1.2 是否搭建真实环境；
2.1.3 是否向Kami或Server执行器提交任务；
2.1.4 是否实际执行Case；
2.1.5 是否产生完整结果；
2.1.6 是否生成报告；
2.1.7 是否创建真实Bug。
2.1.2 是否搭建真实环境；
2.1.3 是否向Kami或Server执行器提交任务；
2.1.4 是否实际执行Case；
2.1.5 是否产生完整结果；
2.1.6 是否生成报告；
2.1.7 是否创建真实Bug。
2.2 最终结论不能只依赖Agent自然语言总结。
3. 自进化不是让AI无约束地修改自己
3.1 正确的自进化是：
真实任务暴露问题
→ 自动归类问题
→ 沉淀可复现样本
→ 形成原子能力改进
→ 冻结验证标准
→ 隔离修改
→ 独立验证
→ 灰度发布
→ 效果回流
→ 自动归类问题
→ 沉淀可复现样本
→ 形成原子能力改进
→ 冻结验证标准
→ 隔离修改
→ 独立验证
→ 灰度发布
→ 效果回流
3.2 AI可以负责发现和修复，但验证标准、预算和发布门槛必须由系统控制
听众收益：
1. 一张需求卡如何转化为完整测试任务；
2. AIQA目前已经具备哪些测试能力；
3. Agent进入真实测试流程后出现了哪些新问题；
4. 如何通过工程化手段保证结果可信和流程闭环；
5. 如何从线上问题中持续推动Skill能力进化；
1. 一张需求卡如何转化为完整测试任务；
2. AIQA目前已经具备哪些测试能力；
3. Agent进入真实测试流程后出现了哪些新问题；
4. 如何通过工程化手段保证结果可信和流程闭环；
5. 如何从线上问题中持续推动Skill能力进化；
赵旭峰
腾讯 游戏品质管理部
Agent 端到端落地负责人
IEG品质管理部 Agent 端到端自动化落地负责人。先后在自动驾驶、地图导航与游戏三个高复杂度业务领域从事质量保障与测试开发工作，测试对象覆盖从物理世界感知系统到大规模在线竞技系统，对强实时、高并发场景下的质量风险有系统性认知。现负责腾讯某大型竞技类游戏的测试开发，主导 Agent 驱动的端到端自动化测试体系建设，推动测试用例生成、自动化执行与结果研判的智能化改造。擅长AI 端到端自动化测试与智能测试工具链设计，长期关注大模型在测试工程领域的落地路径。
待定
待定
像真人一样越测越准！测试端到端 Agent 开发新范式
议题背景：
测试脚本的迭代开发和维护是自动化测试长期痛点：版本一改、地图一换，测试脚本就要人工重写，前置、重试、异常恢复各写一套，用例之间难复用；测试失败往往只留一行fail，没有前后帧、埋点等证据留存，定位全靠人反复复现，同一问题反复出现却说不清是环境、工具还是业务缺陷；踩过的坑也留在个人脑子里，换人换模块就要从零再来，投入的时间买到的是一次性交付，而非可沉淀的能力。我们的思考方向是：先设计稳定的数据结构（知识库、脚本、执行产物），再设计Agent行为，让AI自主探索界面把模糊需求结构化，自动生成脚本与执行计划，失败时基于截图、报告、埋点等证据自动归因、升版重试，跨机协同实现测试能力从"一次性交付"沉淀为"持续复用、越测越准"的智能闭环。
内容大纲：
1. 背景与思考
测试脚本的迭代开发和维护是自动化测试长期痛点：版本一改、地图一换，测试脚本就要人工重写，前置、重试、异常恢复各写一套，用例之间难复用；测试失败往往只留一行fail，没有前后帧、埋点等证据留存，定位全靠人反复复现，同一问题反复出现却说不清是环境、工具还是业务缺陷；踩过的坑也留在个人脑子里，换人换模块就要从零再来，投入的时间买到的是一次性交付，而非可沉淀的能力。我们的思考方向是：先设计稳定的数据结构（知识库、脚本、执行产物），再设计Agent行为，让AI自主探索界面把模糊需求结构化，自动生成脚本与执行计划，失败时基于截图、报告、埋点等证据自动归因、升版重试，跨机协同实现测试能力从"一次性交付"沉淀为"持续复用、越测越准"的智能闭环。
内容大纲：
1. 背景与思考
1.1 问题现状
1.2 核心判断
1.3 设计原则
1.2 核心判断
1.3 设计原则
2. 架构设计：从研发流程到底座的全景架构
2.1 研发流程层
2.2 知识库层
2.3 Agent 支持层
2.4 主 Agent 层
2.5 底座层
2.6 技术选型抉择
2.2 知识库层
2.3 Agent 支持层
2.4 主 Agent 层
2.5 底座层
2.6 技术选型抉择
3. 研发阶段：失败驱动的自愈闭环
3.1 证据体系设计
3.2 归因分型方法
3.3 升版机制
3.4 质量门与回归策略
3.2 归因分型方法
3.3 升版机制
3.4 质量门与回归策略
4. 部署阶段：跨机协同架构
4.1 三端分工
4.2 主Agent"薄"设计
4.3 Harness 的角色
4.2 主Agent"薄"设计
4.3 Harness 的角色
5. 工程实践与量化收益
5.1 治理演进路径
5.2 确定性收益
5.3 大项目实战验证
5.4 现状边界
5.2 确定性收益
5.3 大项目实战验证
5.4 现状边界
6. 真实踩坑
6.1 4K截图击穿传输链路
6.2 调用成功≠点击生效
6.3 二次VLM裁图系统偏移
6.4 工具故障伪装成断言失败
6.2 调用成功≠点击生效
6.3 二次VLM裁图系统偏移
6.4 工具故障伪装成断言失败
7. 总结与展望
7.1 三句话总结
7.2 下一步方向
7.2 下一步方向
听众收益：
1. 一套可复用的 Agent 工程化方法论：如何用结构化数据（知识库/脚本/执行三层产物）替代提示词堆砌来设计 Agent 工作流，可直接迁移到测试之外的其他 Agent 开发场景。
2. 失败驱动升版的自愈闭环实践经验：了解如何通过截图、报告、埋点等多维证据对失败进行归因分型（区分环境问题、工具故障与业务缺陷），获得一套可落地的证据驱动迭代范式。
1. 一套可复用的 Agent 工程化方法论：如何用结构化数据（知识库/脚本/执行三层产物）替代提示词堆砌来设计 Agent 工作流，可直接迁移到测试之外的其他 Agent 开发场景。
2. 失败驱动升版的自愈闭环实践经验：了解如何通过截图、报告、埋点等多维证据对失败进行归因分型（区分环境问题、工具故障与业务缺陷），获得一套可落地的证据驱动迭代范式。
敬请期待
......
.....
待定
待定
敬请期待
....
关注QECon公众号
关注QECon视频号
商务合作
151-2264-3988 木子
票务联系
159-0126-5561 小娟
媒体合作
135-1619-6409 皮皮
购票咨询
小娟 15901265561
