Harness驱动的质量闭环-AiDD研发数字峰会2026-深圳站

论坛主席：罗慧

20年系统测试、质量管理、测试开发团队管理经验，先后负责过QQ秀、QQ会员、QQ音乐、电商、腾讯乘车码、区块链、证券、微信支付等业务的质量保障管理工作，涉及互联网、金融等多个领域。在业务高可用、资金安全、合规、效能建设、AI工作流套件及AI用例自动生成上有丰富的体系化实践经验。

腾讯质量管理通道委员/资深质量专家

Harness驱动的质量闭环

本论坛聚焦通过Harness构建AI Agent可控执行框架，解决自主运行带来的安全、合规与稳定性问题。论坛将讨论沙箱隔离、质量门禁、知识注入、反馈回路、风险约束、持续治理等主题，强调如何让Agent在边界内输出高质量的代码、测试用例等，并保留可审计性。听众将理解如何搭建“人定目标、Agent执行、系统把关”的质量闭环。

AI时代，速度背后它驱动的质量可信么？

李丽

腾讯支付平台研发部质量团队负责人

内容简介：

AI生成测试用例已不是技术难题，但在资金场景下，"错一笔即事故"的零容忍特性，使得核心问题变为：AI的结果，敢不敢用来做放行决策？
本次分享将介绍一套从"能用"到"可信"的完整方法论——以L1-L4资金红线模型定义AI的能力边界，以"AI自测 + 资金门控"双阶段防线构建可信验证体系，并通过业务语义绑定、万级用例AI辅助迁移、支付规则端到端门控等真实实践，展示从模型设计到工程落地的关键决策。最终探讨：当AI重塑研发效率，质量工程师到底在守护什么。

演讲提纲：

1.命题：AI时代，速度背后它驱动的质量可信么？
AI生成用例已不是难题，难题是"敢不敢用AI的结果做放行决策"
资金场景的特殊性：错一笔 = 资损事故，不是bug是事件
2.模型：从"测什么"到"凭什么信"——L1-L4资金红线模型
四层约束结构：动帐类型→资金要求→测试要求→测试目标
核心思想：AI能力边界由领域知识约束定义，不是模型能力定义
3.体系：两阶段可信防线的设计
Phase1 AI自测：快速反馈，降低开发成本
Phase2 资金门控：自测后的强制校验，双门控（状态机+业务规则）
设计原则：自测解决"有没有测"，门控解决"测得够不够"
4.实践：从模型到工程的关键决策
规则声明用业务语义绑定，不绑代码结构——降维护成本
万级用例AI辅助迁移中的人机分工边界
一个真实案例：支付流水号规则的端到端门控落地
6.思考：质量工程的下一个命题
AI不会让测试消失，但会重新定义"测试工程师在守护什么"
从经验驱动到知识工程：让领域安全规则可编码、可传承、可度量

听众收益：

1.拿到一个可复用的框架 —— L1-L4四层约束模型，可直接迁移到你的业务场景，用于定义AI生成内容的可信边界，尤其适用于资金、风控等高敏感领域。
2.看清人机协作的分工线 —— 通过万级用例迁移和支付规则门控两个真实案例，理解在AI辅助研发中，哪些环节交给AI提速、哪些环节必须人来兜底的实操判断标准。
3.获得质量工程转型的新视角 —— 从"经验驱动"到"知识工程"，理解如何将领域安全规则编码为可传承、可度量的工程资产，而非依赖个人经验口口相传。

腾讯支付平台研发部质量团队负责人，负责微信支付资金中台端的质量保障工作。2010年毕业于武汉大学，深耕支付领域质量工程16年。
长期聚焦资金安全与测试体系建设，主导设计了资金红线约束模型及"AI自测 + 资金门控"双阶段可信防线，将领域安全知识体系化编码为AI的能力边界，推动AI从"能生成用例"迈向"敢用于放行决策"的可信跃迁。当前致力于以知识工程思路重塑质量基础设施，探索AI时代质量工程师角色的重新定义。

从出报告到拦交付：自建 AI 内容质量门禁实践

包蕾

网龙网络 AI Native Engineer

内容简介：

AI 生成内容的质量怎么保障，这两年业界建了不少评测体系，但它们的产出大多是一份报告——跑完出分、人看一眼，产物该交付还是交付。行业自己也承认：评估做了不少，上线门禁大多没做。
我们把评测结论接进了在线交付路径。一款内容生成 Agent，每产出一份内容都走一次质量门禁：确定性规则做硬拦截，LLM 判官做多维软评分；判不通过不是记一笔日志，而是定位到出问题的地方自动修复，复检通过才交付给用户。
难点不在判得准不准。一是时延——结论必须在用户可接受的等待时间内返回，否则回来时产物早已发出，门禁形同虚设；而多 Judge 投票、重复采样、人工抽检这些常用手段，在这个预算里一个都用不了。二是评测器不可用时必须放行，门禁会悄悄失效，且失效记录与正常通过看起来一模一样。三是误拦比漏放更伤用户。四是判词直接呈现给用户，写砸了用户当场就不再信任这道门禁。门禁最终从"只记录不拦截"走到真的拦得住。

演讲提纲：

1. 为什么评测报告挡不住问题
开场钩子：两个举手问题——「在座的团队，LLM/Agent 产物上线前有自动或人工质检的请举手？」「质检结论是在放行之前回来、还是之后回来的请举手？」第二个问题直接引出本场主题：门禁「在跑」不等于门禁「拦得住」。
现状：评测体系与方法论并不缺，产出大多是一份报告——跑完出分、人看一眼，产物该交付还是交付。行业自己也承认：评估做了不少，上线门禁大多没做。
划界：离线评测与在线门禁是两套问题。报告可以跑一夜、可以重跑、可以人工复核；在线门禁必须在用户等得起的窗口内、每一次都给出结论，还要扛得住评测器自己挂掉。本场讲的就是放行前那道必须按时给结论的门。同一张图建立全场术语地图：回流 → 规则/判官 → 拦/放 → 派修 → 复检，后续各节均指回此图。
开场断言：拦不住的红线比没有红线更糟——它会让人以为已经拦住了。真实形态：门禁「在跑」，但结论总在产物放行之后才回来；这类记录与「正常过检」在数据里逐列相同，不留专门的痕根本分不出来。
2. 门禁是怎么搭起来的：从只记录到真拦截
评测集：人工维护的黄金评测集，加上线上真实失败的持续回流（判失败／未达标 → 候选池 → 人工采纳 → 不可变数据集版本）。回流口径的坑：只收「判失败」不收「分数未达标」，一半坏例会静默消失。
规则与判官的分工判据：能给出可复核证据的才配做硬拦截（确定性规则），其余只做多维软评分（LLM 判官加权）。红线判词必须带证据原文——「此处空白」与「此处图片透明通道未正常渲染（附证据原文）」是两个系统。
两个正交开关：判不判死（mode）与判死了拦不拦得住（block 开关）；上线走「仅记录 → 灰度 → 真拦」，标定期靠 would_block 列积累「如果真拦会拦多少」。
拦下之后必须有出口：定位到出错位置 → 派修（分批派发、单批限额——预算中断时已完成的批次保得住；最多两轮，仍不通的记下卡在哪）→ 复检 → 交付。还要认得「不能修」：有些「错」是产物里刻意摆放的反例（供读者辨错），派修反而毁掉它——判定器要能按行弃权，不判对错。
证据采集决定判官上限：交互式产物只采初始画面，判官看不到操作后才出现的内容；补采终态证据后，判官可见内容多出约三分之一。「判官只能判它看得见的东西」。
3. 第一个坑，时延：它废掉了三种标准做法
等待窗口怎么定：先定「可接受的超窗率」，再从实测时延分布反推窗口值，不能反着来。教训：样本量小的时候，中位数看着够用；样本量上来之后，长尾比中位数长出数倍——按均值（或中位数）定窗口，等于放任长尾全部超窗。
业界三手段——多判官投票、重复采样取均值、人工抽检——在这个预算里全都用不了：每一样都把时延乘一个系数。只能靠「规则与判官分工」换精度：确定性规则扛硬拦截，判官退到软评分。
一个反直觉的调优：视觉判官一次送 4 张图，延迟是送 2 张的 6.7 倍（超线性），而这个参数原本是为准确率定的。调优顺序：先动单请求的批大小，再动并发。
4. 另外三个坑：会自己消失的门禁、误拦的代价、判词即文案
会自己消失的门禁，两种真实形态：其一，fail-open 的自我消解——评测器不可用时必须放行，但放行必须单独分桶留痕，否则「超窗放行」与「正常过检」在数据里逐列相同，门禁悄悄失效且看不出来；其二，新产物形态上线，随行开关把门禁整段跳过，多份产物未经质检交付，直到看板上「未覆盖」一列才暴露——由此立的哨兵：新形态上线，盯第一份产物有没有对应的门禁记录。
误拦的代价不对称：误拦一次等于拒付一次交付，而「给不出结论」不能当成「有问题」——判官不可用、报错、观测不到，一律进第三种状态「存疑」，而不是拦（我们曾因此单日连续误拦、判词完全相同）；语境信息只能用于放宽、不得用于加严，放宽必须有人签字。应对是高危项「两次一致才拦」＋人工复核闭环，误杀率靠逐条人工标注量出来，再按根因一个个修下去。
判词即文案：门禁报「此处空白」，读判词的人打开产物一看内容都在——实际判的是图片渲染缺陷，判对了却像判错了。无论判词的读者是内部处理人还是终端用户，判词失真，门禁的公信力就丢了。
5. 做减法，以及最后拿到了什么
尺子要有版本号：判据、阈值、判官模型都要进指纹。真实教训：线上判官比测试环境悄悄旧了一代，分数漂移却没有任何记录暴露——模型不钉住，「同一把尺子」只是错觉。
评测器自己也要被测：同一份产物重复自评，看两两一致性；一致率本身有多个口径（按对／按次／按产物），只报一个数会误导。「没评完」的评测必须单列——「稳定地评不出来」会在一致率口径下冒充完全一致。
指标做减法的三数判据：触发次数长期为 0＝无区分度；不可判定占比高＝先修评测器、别急着上红线；误报率的分母必须是已复核数而不是触发数。够不上判据的维度，就下线。
收口——门禁从「只记录」走到「真拦得住」。带走一份清单：分工判据、两个开关、四坑各自的应对、三数减法判据、版本化的尺子。

听众收益：

1.在线质量门禁路径：黄金评测集加线上失败回流攒题目，确定性规则做硬拦截、LLM 判官做软评分，拦下即定位、派修、复检再交付。
2.在线门禁独有的四条硬约束及应对——时延预算（为什么多判官投票、重复采样、人工抽检在在线窗口里全部失效）、fail-open 的自我消解、误拦的不对称代价、判词即文案；这些约束在离线评测资料里找不到。
3.一套给评测指标做减法的量化判据（触发数、不可判定占比、误报率分母口径），以及把判据与判官模型钉进指纹的版本化做法。

13 年测试与质量保障经验。现负责公司 AI Agent 产品的评测体系与 AI Testing 技术探索。
2025 年带队参加微软 AI 开发者挑战赛，最终夺冠。

从告警到证明：Code Security Harness——超大规模代码仓的
安全智能体工程实践

周迪之

安势信息CTO

内容简介：

本演讲分享一条区别于"规则扫描增强"与"纯大模型问答"的第三条路线：以 Harness 为工程核心的代码安全智能体（Code Security Harness）。在超大规模代码仓中，我们让大模型负责语义理解与任务规划，让符号执行、静态分析等确定性工具负责路径可达性证明与漏洞验证，二者通过"假设—验证"闭环协同：Agent 先基于分层代码地图完成威胁建模、提出攻击路径假设，再调度确定性分析自动构造 PoC、验证可达性，把传统扫描的"疑似告警"升级为"可复现、可证明"的结论，并自动生成与回归验证修复补丁。演讲将拆解四项我们自己的工程实践：面向超大规模仓的分层代码地图与增量上下文工程、神经-符号双引擎编排、假设驱动的漏洞验证闭环，以及覆盖召回率/误报率/可验证率的安全 Agent 评测体系与 Token-算力调度策略，最后分享从 PoC 走向规模化生产的真实指标、踩坑与能力边界。

演讲提纲：

1.范式之辨：规则扫描与纯 LLM 方案在超大规模代码仓各自的天花板——为什么代码安全 Agent 的核心竞争力在 Harness 工程，而不在模型本身。
2.神经-符号双引擎（特有方法一）：LLM 负责语义理解与任务规划、符号执行/静态分析负责确定性证明的接口契约、任务分工、结果仲裁与失败回退机制。
3.超大规模仓上下文工程（特有方法二）：仓库—模块—函数—调用链四层代码地图、代码变更触发的增量分析、上下文按需装配与 Token 预算调度，如何把"喂不下的仓库"变成"可导航的地图"。
4.假设—验证闭环（特有方法三）：从威胁建模、攻击路径假设，到自动构造 PoC、可达性证明、风险研判，再到修复补丁生成与测试回归的端到端闭环，如何用确定性验证系统性消除误报。
5.评测驱动规模化落地：基于历史漏洞回归集的安全 Agent 评测基准（召回率、误报率、可验证率、修复正确率）、人机协同研判模式，以及生产环境的真实数据、典型失败案例与当前能力边界。

听众收益：

1.掌握一套可复用的神经-符号 Harness 架构：明确代码安全链路中哪些环节该交给 LLM、哪些必须交给确定性工具，避免"All in LLM"的工程陷阱。
2.获得超大规模代码仓上下文工程、Token-算力成本控制与 Agent 评测的具体方法和指标口径，可直接对照自身场景落地。
3.了解安全 Agent 从 PoC 到生产的真实路径：自动验证如何消除误报、人机如何协同研判、哪些环节今天仍必须人工兜底。

安势信息CTO，负责公司新一代Code Intelligence Agent产品研发、公司研发团队AI转型。计算机科学博士学位，曾在华为、Synopsys、Nokia等大厂担任技术专家、Technical Leader等高级技术职位，有丰富的软件工程管理和实践经验

大小模型协同下的智能体落地——金融业务场景的端到端智能文档
解析与信息提取系统实践

陈清宇

深圳前海微众银行数据算法工程师

内容简介：

在数据敏感、机器资源有限且精度要求高的私域生产环境中，智能体落地不能只依赖单一大模型。本分享结合金融复杂文档解析项目，介绍如何与业务共同定义交付指标、建设可脱敏评测集；如何以大小模型、专用能力和存量模型构成模型矩阵，通过智能路由、结果仲裁和规则校验协同处理多页文书、印章、手写和表格等难题；以及如何通过旁路回测、人工复核、问题归因和回归评测，形成可控、可审计、可持续迭代的质量闭环。

演讲提纲：

1. 项目背景与私域落地约束
1.1 结合金融复杂文档解析项目，介绍多页文档中正文、表格、印章、手写和附件并存的实际问题。
1.2 面对数据不能出域、算力资源有限、关键字段精度要求高等约束，单一大模型难以覆盖全部场景。
1.3 项目目标是建设可私有化部署、可评测、可回测、可持续迭代的端到端系统。
2. 需求指标与脱敏数据建设
2.1 在需求阶段与业务共同明确文档范围、字段要求、风险等级、自动化边界和验收指标。
2.2 从历史样本中构建脱敏数据集，保留版式结构和典型问题，覆盖标准、长尾、专项和回归场景。
2.3 以端到端业务结果为准，综合关注准确性、字段完整性、时延、失败率和人工复核率。
3. 系统架构与模型矩阵｜7分钟
3.1 介绍“任务接入—预处理—版面理解—智能路由—能力执行—结果融合—业务校验—审计输出—质量运营”的系统链路。
3.2 根据任务特点划分大模型、轻量模型、专项模型、规则组件和存量业务模型的职责。
3.3 统一封装存量模型的接口、能力标签、适用边界和质量指标，形成可组合、可替换的模型矩阵。
4. 智能路由与大小模型协同
4.1 根据业务任务、文档版式、局部图像质量、字段风险和资源状态动态选择处理路径。
4.2 先识别正文、表格、印章、手写和附件等区域，再按区域调用合适的模型或业务能力。
4.3 通过多模型协同兼顾复杂场景效果、资源消耗和处理时延，避免固定单模型或单一路径的局限。
5. 结果融合与质量保证
5.1 针对印章遮挡、手写、扫描模糊、跨栏文本和复杂表格等问题，对多路结果进行统一融合与校验。
5.2 综合文本语义、空间位置、版面结构、置信度和规则约束，避免简单采用最高置信度结果。
5.3 输出字段结果的同时保留原文位置、处理路径、校验状态和复核记录，确保结果可解释、可追溯。
6. 从离线评测到生产质量闭环
6.1 结合项目实践，介绍复杂文档的端到端验证、字段级评测和标准、长尾、专项及回归数据集建设。
6.2 通过模型常驻、并行调度、流式处理和缓存等工程手段，平衡系统准确性、响应速度和并发能力。
6.3 持续采集脱敏生产样本、人工修正、异常日志和业务反馈，沉淀专项数据集与回归测试集。
6.4 区分识别、结构、路由、仲裁、规则和工程问题，建立问题归因、专项修复和版本回归机制。
6.5 形成“问题发现—原因定位—离线回归—生产旁路—灰度观测—持续迭代”的质量闭环。
7. 方法论总结
7.1 需求阶段明确业务指标和自动化边界，数据阶段建设可脱敏、可复用的评测基线。
7.2 架构阶段通过模型矩阵和智能路由实现大小模型、专项能力及存量模型协同。
7.3 运营阶段通过生产回测、人工复核和持续回归，让智能体在私域环境中做到可用、可控、可评估、可审计和可迭代

听众收益：

1. 获得私域智能体从需求指标、脱敏数据集到端到端验收的落地方法，明确高精度、高敏感场景下的交付边界。
2. 掌握大小模型、专项能力、规则组件和存量模型协同的模型矩阵设计，以及按任务和文档区域进行智能路由的实践思路。
3. 建立从离线评测、生产旁路到回归测试、问题归因和持续迭代的质量闭环，提升智能体系统的可控性与可运营性。

微众银行武汉研发中心算法工程师，2023年开始从事多模态大模型方向研究。主导金融业务场景的端到端文档解析与信息提取系统、ai-native数字员工“纪要君”等多项智能体项目，具有大模型算法全生命周期落地应用经验。并在这三年中，发布五项国家发明创新专利，一篇CCF-A会议论文。

AiDD峰会

K+峰会

联系我们