专场：AI 时代的效能度量与工程治理
AI 编程正推动代码产出效率十倍级提升，但传统度量体系失效、技术债加速堆积、安全风险隐性渗透——效能红利正以质量债的形式被悄悄透支。本专场聚焦"度量重构"与"工程治理"两大主线，从适配人机协同的质效度量新范式、度量驱动的组织协作提效，到存量系统的 AI 辅助重构、增量代码的 CR 与测试策略适配，再到 AI 生成代码的可维护性量化与安全左移，分享一线落地实战，帮企业在 AI 研发浪潮中既跑得快、又守得住。
专场出品人：李焕雄
腾讯音乐 研发效能中心总监
腾讯音乐研发效能中心总监、T12资深测试开发专家，集团质量通道会长，集团质量与效能负责人。中大MBA，具备PMP/ACP/NPDP全套项目产品管理认证，拥有10余项技术发明专利。统筹管理项目管理、测试、效能、运管技术等多支核心技术团队，专注全域质量保障、测试开发、研发效能治理、规模化项目管理领域多年，具备行业领先的质效平台落地、体系搭建与技术团队管理实战经验。
杨永
联想 中国区销售服务交付团队 AI架构师
联想中国区销售服务交付团队AI架构师，长期从事企业级应用、人工智能与智能体系统的技术研发及工程交付，拥有超过14年企业IT与数字化建设经验。
现主要负责企业级智能体、AI工程化及相关技术架构建设，参与并负责联想乐享企业超级智能体、凤凰企业级Agent能力底座、Agent质量治理与工程体系等核心项目，从业务场景、系统架构到生产环境落地积累了丰富实践经验。
在企业级Agent建设过程中，重点推动智能体从“功能实现”向“生产级质量工程”演进，围绕Agent Runtime、Skill/MCP体系、Trace全链路可观测、Badcase分析、Reflection反思机制、LLM-as-a-Judge质量评估以及持续优化闭环开展技术实践。
擅长领域包括：企业级Agent架构设计、Agent Quality Engineering、智能体可观测性与评估体系、Harness Engineering、AI Native研发工程、RAG与知识工程、Skill/MCP能力体系，以及AI在电商与企业服务场景中的规模化落地。
现主要负责企业级智能体、AI工程化及相关技术架构建设，参与并负责联想乐享企业超级智能体、凤凰企业级Agent能力底座、Agent质量治理与工程体系等核心项目，从业务场景、系统架构到生产环境落地积累了丰富实践经验。
在企业级Agent建设过程中，重点推动智能体从“功能实现”向“生产级质量工程”演进，围绕Agent Runtime、Skill/MCP体系、Trace全链路可观测、Badcase分析、Reflection反思机制、LLM-as-a-Judge质量评估以及持续优化闭环开展技术实践。
擅长领域包括：企业级Agent架构设计、Agent Quality Engineering、智能体可观测性与评估体系、Harness Engineering、AI Native研发工程、RAG与知识工程、Skill/MCP能力体系，以及AI在电商与企业服务场景中的规模化落地。
待定
待定
从可观测到可进化：企业级 Agent 的质量闭环与持续演进实践
一、议题背景：
随着企业级 Agent 从 Demo 逐渐进入真实生产环境，传统软件质量保障方法正在面临新的挑战。
Agent 的一次回答并不是简单的“输入—输出”，而可能包含意图理解、Planning、知识检索、Memory、Skill/Tool/MCP 调用、模型推理以及多轮状态管理等多个动态决策过程。
因此，在生产环境中经常出现一种新的质量问题：
系统调用成功、接口返回正常，但用户任务实际上失败了。
传统日志、APM、接口成功率只能告诉我们“系统有没有报错”，却很难回答：
Agent 为什么做出了这个决策？
哪一步开始偏离正确路径？
是知识问题、模型问题、上下文问题，还是 Tool/Skill 调用问题？
如何判断一次 Agent 执行过程到底“好不好”？
线上失败案例如何真正变成系统下一次提升的输入？
凤凰在企业级智能体实践中，逐步形成了一套围绕 Trace → Diagnose → Reflection → Evaluation → Improvement 的 Agent 质量闭环，希望通过本次分享探讨：如何让 Agent 从“能够运行”，走向“可观测、可评估、可优化、可持续进化”。
二、分享核心内容
01｜Agent 进入生产环境后，质量问题发生了什么变化
首先介绍传统应用质量保障与 Agent 质量保障之间的本质差异。
传统软件关注确定性执行，而 Agent 更接近一个动态决策系统。
一次任务的最终质量不仅取决于模型，还取决于：
Context × Planning × Knowledge × Memory × Model × Skill / Tool × Runtime
通过真实业务中的典型 Badcase，分析几类常见 Agent Failure：
最终答案正确，但执行路径存在风险
Tool 调用成功，但 Tool 选择错误
知识召回正确，但模型没有正确使用
Memory / Context 污染导致后续推理逐渐偏离
多轮任务中某一个中间步骤失败，最终结果仍然“看起来合理”
系统技术指标全部正常，但用户任务没有完成
引出核心观点：
Agent Quality ≠ Response Quality，而是 End-to-End Task Quality。
02｜Trace：把 Agent 的黑盒执行过程变成可观察的决策链
介绍凤凰如何构建 Agent 全链路 Trace。
不再只记录 API Log，而是记录一次 Agent Run 中完整的决策过程：
User Query
↓
Intent / Context
↓
Planner
↓
Knowledge / Memory Retrieval
↓
Model Reasoning
↓
Skill / Tool / MCP Selection
↓
Tool Execution
↓
Observation
↓
Next Action
↓
Final Response
重点分享 Trace 中需要关注的几个质量对象：
Input、Context、Decision、Action、Observation、Output。
通过 Trace 将传统的“结果排查”升级为：
Step-level Debugging + Decision-level Observability。
进一步介绍如何利用 Trace 实现：
异常步骤识别、调用链还原、Tool/MCP 参数分析、Token与Latency分析、上下文分析以及跨层 Root Cause Analysis。
03｜Reflection：从“找到问题”进一步走向“理解为什么失败”
仅仅有 Trace 仍然只能回答：
发生了什么？
下一步需要回答：
为什么会这样？
介绍凤凰如何在 Trace 之上引入 Reflection / AI Diagnosis 机制。
Agent 自动读取执行轨迹，对一次失败过程进行结构化复盘，包括：
Failure Stage
→ 问题发生在哪个阶段
Root Cause
→ 模型、知识、Context、Memory、Skill、Tool 还是业务规则问题
Evidence
→ 从 Trace 中提取关键证据
Expected Behavior
→ 正确执行路径应该是什么
Improvement Suggestion
→ Prompt、Knowledge、Skill、Model、Routing 或 Runtime 应该如何调整
最终把传统依赖人工专家分析的问题排查过程，逐渐转化为：
Trace → AI Diagnosis → Reflection Report。
同时分享 Reflection 如何与 Badcase、问题跟踪和工程研发流程连接起来。
04｜Evaluation：从“最终答案评分”升级为“Agent 过程质量评估”
Agent 评估不能只 Judge 最终回答。
一个最终答案可能是正确的，但执行过程中可能经历：
错误 Tool 调用、无效循环、多余检索、错误 Planning 或高风险推理路径。
因此凤凰逐步构建：
Result Evaluation + Process Evaluation。
从多个维度评估一次 Agent Run：
任务完成度
答案准确性
知识 Groundedness
Tool / Skill Selection
Tool Parameter Accuracy
Planning Quality
Context Utilization
Memory Usage
Execution Efficiency
Safety & Compliance
结合 Rubrics、规则评估、LLM-as-a-Judge 和业务指标，形成统一的 Agent Quality Score。
进一步介绍：
Single Step Evaluation → Trace Evaluation → Task Evaluation → Scenario Evaluation。
让质量评估从单次回答逐步提升到完整业务任务。
05｜Quality Loop：让线上问题真正驱动 Agent 持续进化
最后重点介绍凤凰如何把 Trace、Reflection 和 Evaluation 串成一个完整闭环：
Production Traffic
→ Trace Capture
→ Failure Detection
→ Root Cause Analysis
→ Reflection
→ Badcase Classification
→ Dataset / Testset Generation
→ Evaluation
→ Prompt / Knowledge / Skill / Model Optimization
→ Regression Evaluation
→ Release
→ Production Monitoring
形成：
Observe → Diagnose → Reflect → Evaluate → Improve → Verify
的 Agent Quality Loop。
线上每一个 Badcase 不再只是一个需要关闭的问题单，而会逐渐沉淀成为：
Failure Case → Evaluation Case → Regression Case → Quality Asset。
最终让生产数据成为 Agent 持续演进的数据资产。
三、实践案例
结合企业级超级智能体实际生产案例，展示一次典型问题如何完成完整闭环：
用户反馈问题
→ Session / Query 定位
→ Trace 自动还原
→ AI Diagnosis
→ Root Cause 判断
→ Reflection
→ 自动生成优化建议
→ Badcase 入库
→ Evaluation Case 生成
→ 修复验证
→ Regression
→ 再发布
重点分享真实实践中遇到的问题：
如何处理非确定性输出；
如何定义 Agent 的“正确”；
如何减少 LLM-as-a-Judge 自身的不稳定性；
如何平衡自动评估与人工评审；
以及如何让质量数据真正进入研发闭环，而不是形成另一个孤立的质量平台。
四、核心观点
本次分享希望传递三个核心观点：
1. Observability is the foundation of Agent Quality
看不见 Agent 如何思考和行动，就无法真正治理 Agent 质量。
2. Evaluation must move from Output to Process
Agent 质量评估必须从最终答案扩展到执行过程、决策过程和任务完成质量。
3. Every Failure Should Become a Quality Asset
真正成熟的 Agent Quality Engineering，不只是解决 Badcase，而是让每一次失败都进入评估体系和回归体系，推动系统持续进化。
最终实现：
From Observable Agent
to Measurable Agent
to Self-Improving Agent.
随着企业级 Agent 从 Demo 逐渐进入真实生产环境，传统软件质量保障方法正在面临新的挑战。
Agent 的一次回答并不是简单的“输入—输出”，而可能包含意图理解、Planning、知识检索、Memory、Skill/Tool/MCP 调用、模型推理以及多轮状态管理等多个动态决策过程。
因此，在生产环境中经常出现一种新的质量问题：
系统调用成功、接口返回正常，但用户任务实际上失败了。
传统日志、APM、接口成功率只能告诉我们“系统有没有报错”，却很难回答：
Agent 为什么做出了这个决策？
哪一步开始偏离正确路径？
是知识问题、模型问题、上下文问题，还是 Tool/Skill 调用问题？
如何判断一次 Agent 执行过程到底“好不好”？
线上失败案例如何真正变成系统下一次提升的输入？
凤凰在企业级智能体实践中，逐步形成了一套围绕 Trace → Diagnose → Reflection → Evaluation → Improvement 的 Agent 质量闭环，希望通过本次分享探讨：如何让 Agent 从“能够运行”，走向“可观测、可评估、可优化、可持续进化”。
二、分享核心内容
01｜Agent 进入生产环境后，质量问题发生了什么变化
首先介绍传统应用质量保障与 Agent 质量保障之间的本质差异。
传统软件关注确定性执行，而 Agent 更接近一个动态决策系统。
一次任务的最终质量不仅取决于模型，还取决于：
Context × Planning × Knowledge × Memory × Model × Skill / Tool × Runtime
通过真实业务中的典型 Badcase，分析几类常见 Agent Failure：
最终答案正确，但执行路径存在风险
Tool 调用成功，但 Tool 选择错误
知识召回正确，但模型没有正确使用
Memory / Context 污染导致后续推理逐渐偏离
多轮任务中某一个中间步骤失败，最终结果仍然“看起来合理”
系统技术指标全部正常，但用户任务没有完成
引出核心观点：
Agent Quality ≠ Response Quality，而是 End-to-End Task Quality。
02｜Trace：把 Agent 的黑盒执行过程变成可观察的决策链
介绍凤凰如何构建 Agent 全链路 Trace。
不再只记录 API Log，而是记录一次 Agent Run 中完整的决策过程：
User Query
↓
Intent / Context
↓
Planner
↓
Knowledge / Memory Retrieval
↓
Model Reasoning
↓
Skill / Tool / MCP Selection
↓
Tool Execution
↓
Observation
↓
Next Action
↓
Final Response
重点分享 Trace 中需要关注的几个质量对象：
Input、Context、Decision、Action、Observation、Output。
通过 Trace 将传统的“结果排查”升级为：
Step-level Debugging + Decision-level Observability。
进一步介绍如何利用 Trace 实现：
异常步骤识别、调用链还原、Tool/MCP 参数分析、Token与Latency分析、上下文分析以及跨层 Root Cause Analysis。
03｜Reflection：从“找到问题”进一步走向“理解为什么失败”
仅仅有 Trace 仍然只能回答：
发生了什么？
下一步需要回答：
为什么会这样？
介绍凤凰如何在 Trace 之上引入 Reflection / AI Diagnosis 机制。
Agent 自动读取执行轨迹，对一次失败过程进行结构化复盘，包括：
Failure Stage
→ 问题发生在哪个阶段
Root Cause
→ 模型、知识、Context、Memory、Skill、Tool 还是业务规则问题
Evidence
→ 从 Trace 中提取关键证据
Expected Behavior
→ 正确执行路径应该是什么
Improvement Suggestion
→ Prompt、Knowledge、Skill、Model、Routing 或 Runtime 应该如何调整
最终把传统依赖人工专家分析的问题排查过程，逐渐转化为：
Trace → AI Diagnosis → Reflection Report。
同时分享 Reflection 如何与 Badcase、问题跟踪和工程研发流程连接起来。
04｜Evaluation：从“最终答案评分”升级为“Agent 过程质量评估”
Agent 评估不能只 Judge 最终回答。
一个最终答案可能是正确的，但执行过程中可能经历：
错误 Tool 调用、无效循环、多余检索、错误 Planning 或高风险推理路径。
因此凤凰逐步构建：
Result Evaluation + Process Evaluation。
从多个维度评估一次 Agent Run：
任务完成度
答案准确性
知识 Groundedness
Tool / Skill Selection
Tool Parameter Accuracy
Planning Quality
Context Utilization
Memory Usage
Execution Efficiency
Safety & Compliance
结合 Rubrics、规则评估、LLM-as-a-Judge 和业务指标，形成统一的 Agent Quality Score。
进一步介绍：
Single Step Evaluation → Trace Evaluation → Task Evaluation → Scenario Evaluation。
让质量评估从单次回答逐步提升到完整业务任务。
05｜Quality Loop：让线上问题真正驱动 Agent 持续进化
最后重点介绍凤凰如何把 Trace、Reflection 和 Evaluation 串成一个完整闭环：
Production Traffic
→ Trace Capture
→ Failure Detection
→ Root Cause Analysis
→ Reflection
→ Badcase Classification
→ Dataset / Testset Generation
→ Evaluation
→ Prompt / Knowledge / Skill / Model Optimization
→ Regression Evaluation
→ Release
→ Production Monitoring
形成：
Observe → Diagnose → Reflect → Evaluate → Improve → Verify
的 Agent Quality Loop。
线上每一个 Badcase 不再只是一个需要关闭的问题单，而会逐渐沉淀成为：
Failure Case → Evaluation Case → Regression Case → Quality Asset。
最终让生产数据成为 Agent 持续演进的数据资产。
三、实践案例
结合企业级超级智能体实际生产案例，展示一次典型问题如何完成完整闭环：
用户反馈问题
→ Session / Query 定位
→ Trace 自动还原
→ AI Diagnosis
→ Root Cause 判断
→ Reflection
→ 自动生成优化建议
→ Badcase 入库
→ Evaluation Case 生成
→ 修复验证
→ Regression
→ 再发布
重点分享真实实践中遇到的问题：
如何处理非确定性输出；
如何定义 Agent 的“正确”；
如何减少 LLM-as-a-Judge 自身的不稳定性；
如何平衡自动评估与人工评审；
以及如何让质量数据真正进入研发闭环，而不是形成另一个孤立的质量平台。
四、核心观点
本次分享希望传递三个核心观点：
1. Observability is the foundation of Agent Quality
看不见 Agent 如何思考和行动，就无法真正治理 Agent 质量。
2. Evaluation must move from Output to Process
Agent 质量评估必须从最终答案扩展到执行过程、决策过程和任务完成质量。
3. Every Failure Should Become a Quality Asset
真正成熟的 Agent Quality Engineering，不只是解决 Badcase，而是让每一次失败都进入评估体系和回归体系，推动系统持续进化。
最终实现：
From Observable Agent
to Measurable Agent
to Self-Improving Agent.
徐为
黄梓航
亚马逊云科技
资深解决
方案架构师
亚马逊云科技
资深 AI 产品解决
方案架构师
徐为：
亚马逊云科技资深解决方案架构师。硕士毕业于 Erasmus Mundus IMMIT 经济与 IT 管理专业。自 2006 年起，先后以研发工程师、数据工程师、解决方案架构师身份在 SonyEricsson、SAP SE、Alibaba Cloud、Tencent Cloud 等多家跨国企业从事 IT 相关工作超过 15 年，积累了丰富的跨行业技术实践经验。目前专注于帮助客户在云上构建优雅的解决方案，核心技术方向包括微服务架构、可观测性、AIOps 与 AgentOps。致力于将前沿学术成果与工程实践相结合，推动企业级 AI Agent 系统从 POC 走向可靠的生产落地。
黄梓航：
......
待定
待定
非确定性系统的新一代质量工程：
Gödel 飞轮 —— 让 Agent 拥有可测量、可回归、可持续进化的质量
议题背景：
89% 的 AI Agent 项目在上线后表现急剧下滑——但这不是"模型问题"，而是质量工程范式的空缺：传统 QE 的确定性断言、覆盖率、回归测试面对非确定性、多步骤、带工具调用的 Agent 时集体失效。QA 团队被推到最前线，却没有拿到新的工具箱。
本 session 从 QE 的视角提出 Gödel Agentic Flywheel——一套把 AgentOps 重构为质量工程闭环的方法论：Observe（可测量） → Evaluate（可断言） → Optimize（可回归） → Govern（可审计），并让整个飞轮拥有哥德尔递归性——它不只是测 Agent，它也在测自己（"谁来评估评估者"）。
我们把每个环节都落到 QE 团队熟悉的概念：Eval-as-Test 取代单元断言、Golden Set + LLM-as-Judge 取代人工回归、Trace-as-Coverage 取代代码覆盖、Prompt/Model Change → CI 门槛 → 灰度 → 回滚 取代版本发布。理论支柱涵盖 Compound AI Systems、Antifragility、Cybernetic Feedback Loop 与 Evolutionary Architecture，并引用 2026 年最新学术成果：SARSI 递归自改进、MetaSkill-Evolve 双时间尺度演进、AgentOps Automation Pipeline 等 7 篇论文。
工具层由 Amazon Bedrock AgentCore Evaluations / Observability / Optimization 与 Amazon CloudWatch Omni for Agents 承担——把"人评 + 表格"升级成 managed evaluators、A/B experiments 与从本地到生产的一条 trace。
方案已在多个行业头部客户中落地，覆盖智能硬件、家电、生命科学、金融等场景——AgentCore Evaluation & Observability 项目、多租户 Agent 平台合规化 QE、以及金融高风险场景的四象限方案。Live Demo 演示：一次 Prompt 修改 → 自动跑回归评测 → 出质量报告 → 走 CI 门槛 → 灰度 → 回滚。你会拿到 QE 团队进入 Agent 时代的 Level 1 → Level 4 成熟度路线图 和一份可直接套用的 Eval Suite 模板。
内容大纲：
1. 传统 QE 为什么在 Agent 时代集体失效
89% 的 AI Agent 项目在上线后表现急剧下滑——但这不是"模型问题"，而是质量工程范式的空缺：传统 QE 的确定性断言、覆盖率、回归测试面对非确定性、多步骤、带工具调用的 Agent 时集体失效。QA 团队被推到最前线，却没有拿到新的工具箱。
本 session 从 QE 的视角提出 Gödel Agentic Flywheel——一套把 AgentOps 重构为质量工程闭环的方法论：Observe（可测量） → Evaluate（可断言） → Optimize（可回归） → Govern（可审计），并让整个飞轮拥有哥德尔递归性——它不只是测 Agent，它也在测自己（"谁来评估评估者"）。
我们把每个环节都落到 QE 团队熟悉的概念：Eval-as-Test 取代单元断言、Golden Set + LLM-as-Judge 取代人工回归、Trace-as-Coverage 取代代码覆盖、Prompt/Model Change → CI 门槛 → 灰度 → 回滚 取代版本发布。理论支柱涵盖 Compound AI Systems、Antifragility、Cybernetic Feedback Loop 与 Evolutionary Architecture，并引用 2026 年最新学术成果：SARSI 递归自改进、MetaSkill-Evolve 双时间尺度演进、AgentOps Automation Pipeline 等 7 篇论文。
工具层由 Amazon Bedrock AgentCore Evaluations / Observability / Optimization 与 Amazon CloudWatch Omni for Agents 承担——把"人评 + 表格"升级成 managed evaluators、A/B experiments 与从本地到生产的一条 trace。
方案已在多个行业头部客户中落地，覆盖智能硬件、家电、生命科学、金融等场景——AgentCore Evaluation & Observability 项目、多租户 Agent 平台合规化 QE、以及金融高风险场景的四象限方案。Live Demo 演示：一次 Prompt 修改 → 自动跑回归评测 → 出质量报告 → 走 CI 门槛 → 灰度 → 回滚。你会拿到 QE 团队进入 Agent 时代的 Level 1 → Level 4 成熟度路线图 和一份可直接套用的 Eval Suite 模板。
内容大纲：
1. 传统 QE 为什么在 Agent 时代集体失效
1.1 断言、覆盖率、回归三件套的失效方式
1.2 Flaky test 从"少数例外"变成"系统本质"
1.3 三个真实事故：一次 Prompt 改动引发的线上劣化
1.4 QA 团队被推到最前线，但工具箱没有升级
1.2 Flaky test 从"少数例外"变成"系统本质"
1.3 三个真实事故：一次 Prompt 改动引发的线上劣化
1.4 QA 团队被推到最前线，但工具箱没有升级
2. QE for Agents：核心概念重定义
2.1 Eval-as-Test：从单元断言到评分函数（scoring rubric）
2.2 Golden Set + LLM-as-Judge：新一代回归基线
2.3 Trace-as-Coverage：用 reasoning chain 替代分支覆盖
2.4 Non-determinism budget：把"允许多少不一致"作为一等质量属性
2.2 Golden Set + LLM-as-Judge：新一代回归基线
2.3 Trace-as-Coverage：用 reasoning chain 替代分支覆盖
2.4 Non-determinism budget：把"允许多少不一致"作为一等质量属性
3. Gödel Agentic Flywheel：QE 视角
3.1 Observe（可测量）— 五类 QE 必采信号
3.2 Evaluate（可断言）— LLM-as-judge、rubric、human-in-the-loop 的取舍
3.3 Optimize（可回归）— Prompt / Tool / Memory 变更后的自动回归
3.4 Govern（可审计）— 每一次决策都能回放的证据链
3.5 哥德尔递归："评估评估者"——Meta-eval 的必要性
3.2 Evaluate（可断言）— LLM-as-judge、rubric、human-in-the-loop 的取舍
3.3 Optimize（可回归）— Prompt / Tool / Memory 变更后的自动回归
3.4 Govern（可审计）— 每一次决策都能回放的证据链
3.5 哥德尔递归："评估评估者"——Meta-eval 的必要性
4. Eval Suite 设计：从零搭一套 Agent 质量基线
4.1 数据集：Golden Set / Adversarial Set / Drift Set 的比例
4.2 指标：Correctness / Faithfulness / Safety / Cost / Latency 五轴
4.3 打分方式：Rule-based vs. LLM-Judge vs. Human 的组合
4.4 覆盖度指标：如何量化"我测到了没有"
4.5 Eval 集自己的漂移检测
4.2 指标：Correctness / Faithfulness / Safety / Cost / Latency 五轴
4.3 打分方式：Rule-based vs. LLM-Judge vs. Human 的组合
4.4 覆盖度指标：如何量化"我测到了没有"
4.5 Eval 集自己的漂移检测
5. 把飞轮接进 CI/CD：质量门槛与发布节奏
5.1 Prompt / Model / Tool 变更的三级门槛
5.2 Trace diff：给 reviewer 一份"这次修改到底改变了什么"的可视化
5.3 灰度 + 自动回滚触发条件
5.4 事后 postmortem 自动生成与追责
5.2 Trace diff：给 reviewer 一份"这次修改到底改变了什么"的可视化
5.3 灰度 + 自动回滚触发条件
5.4 事后 postmortem 自动生成与追责
6. AWS 工具支撑
6.1 AgentCore Evaluations & Observability：从本地开发就能跑回归
6.2 CloudWatch Omni for Agents：IDE-first 的 QE 视图
6.3 Managed Evaluators 与 A/B Experiment 的 QE 用法
6.4 一份 trace 在开发 / 评测 / 生产 / 审计四个场景的复用
6.2 CloudWatch Omni for Agents：IDE-first 的 QE 视图
6.3 Managed Evaluators 与 A/B Experiment 的 QE 用法
6.4 一份 trace 在开发 / 评测 / 生产 / 审计四个场景的复用
7. QE 成熟度 Level 1 → Level 4
7.1 Level 1 手工飞轮：人评 + 静态基线
7.2 Level 2 半自动：eval 集自动化、告警驱动回归
7.3 Level 3 自动优化：CI 门槛、灰度、自动回滚
7.4 Level 4 Gödel 飞轮：飞轮自我评估、eval 集自演进
7.5 QA 团队组织重塑：从"测试执行者"到"质量策展人"
7.2 Level 2 半自动：eval 集自动化、告警驱动回归
7.3 Level 3 自动优化：CI 门槛、灰度、自动回滚
7.4 Level 4 Gödel 飞轮：飞轮自我评估、eval 集自演进
7.5 QA 团队组织重塑：从"测试执行者"到"质量策展人"
8. 大客户实证
8.1 智能硬件与家电行业多家头部客户 —— AgentCore Evaluation & Observability 项目里的 QE 团队角色
8.2 生命科学行业头部客户 —— 多租户 Agent 平台的合规化 QE
8.3 金融行业头部客户 —— 高风险场景下的 QE 门禁设计
8.2 生命科学行业头部客户 —— 多租户 Agent 平台的合规化 QE
8.3 金融行业头部客户 —— 高风险场景下的 QE 门禁设计
9. Live Demo：一次 Prompt 修改，走完整个飞轮
9.1 本地修改 → 触发自动回归 → 质量报告
9.2 走 CI 门槛 → 灰度 5%
9.3 CloudWatch 检测漂移 → 自动回滚
9.4 事后 postmortem 自动落地到 Eval 集，形成飞轮下一圈
9.2 走 CI 门槛 → 灰度 5%
9.3 CloudWatch 检测漂移 → 自动回滚
9.4 事后 postmortem 自动落地到 Eval 集，形成飞轮下一圈
10. Takeaway 与下一步
10.1 QE 团队进入 Agent 时代的 Level 1 → Level 4 成熟度路线图
10.2 可直接套用的 Eval Suite 模板（下载）
10.3 常见反模式：把 Agent 当传统软件测的五个坑
10.4 Q&A
10.2 可直接套用的 Eval Suite 模板（下载）
10.3 常见反模式：把 Agent 当传统软件测的五个坑
10.4 Q&A
听众收益：
1. 拿到一份可直接套用的 Agent Eval Suite 模板（Golden Set / Adversarial Set / Drift Set 三层）
2. 理解如何将 Eval-as-Test / Trace-as-Coverage 接入既有 CI/CD 流水线
3. 具备与 AI 团队协作时"该测什么、怎么算通过"的共同语言
4. 看清 QE 团队从"测试执行者"到"质量策展人"的转型路径
5. Positioning 与差异化（对内说明）
6. 面向 QA/QE，切入点是"传统 QE 在 Agent 时代失效"，不讲模型也不讲 agent 框架
7. 术语全部换到 QE 团队熟悉的层级：断言、覆盖率、回归、门槛、灰度、回滚
8. Live Demo 的主线不是"演一个 Agent"，而是"演一次 Prompt 修改如何走完质量流水线"
9. 与 Agentic Conference 版本相比：相同的飞轮，不同的听众语言与 demo 主线
2. 理解如何将 Eval-as-Test / Trace-as-Coverage 接入既有 CI/CD 流水线
3. 具备与 AI 团队协作时"该测什么、怎么算通过"的共同语言
4. 看清 QE 团队从"测试执行者"到"质量策展人"的转型路径
5. Positioning 与差异化（对内说明）
6. 面向 QA/QE，切入点是"传统 QE 在 Agent 时代失效"，不讲模型也不讲 agent 框架
7. 术语全部换到 QE 团队熟悉的层级：断言、覆盖率、回归、门槛、灰度、回滚
8. Live Demo 的主线不是"演一个 Agent"，而是"演一次 Prompt 修改如何走完质量流水线"
9. 与 Agentic Conference 版本相比：相同的飞轮，不同的听众语言与 demo 主线
郗瑶颖
腾讯音乐 资深测试专家
本人长期从事质量保障体系建设与AI研效工程化落地工作，拥有丰富的音乐产品全流程质量管控与研效平台建设经验。曾就职于中国科学院深圳先进技术研究院，现任TME/酷狗研效中心集成质量负责人。主导了酷狗音乐APP质量AI指标体系建设、AI反馈分析系统（Hamues）搭建、MTP平台AI需求澄清助手开发、AI自动化测试平台构建等多个专项从0到1的建设，并推动在酷狗业务线内持续落地。对AI自动化测试、AI智能化测试、研发效能提升、全流程质量管控、数据驱动质量改进等有丰富的实战经验。
待定
待定
从“人效”到“智效”：AI 研发效能治理的跃迁之路
内容大纲：
1. 背景：AI时代的研效新挑战
1.1 产出指标失真：代码行数、PR 数被 AI 生成代码迅速膨胀，"指标好看、交付没变快"
1.2 三个失效信号：产出≠价值、缺陷数据失去历史可比性、瓶颈从写代码转移到需求澄清/评审/测试
1.3 一次故障复盘：【待补：现象、发现渠道、根因、影响面】——结论：不是人的失误，是治理体系没跟上 AI 的速度
2. AI时代研发链路变更
2.1 散装的 AI 工具不可见、不可度量、不可治理
2.2 治理对象从"开发者的行为"变成"研发流水线的节点"
3. 腾讯音乐的KGHarness工程实践
3.1 需求阶段：AI 澄清前置 + 门禁拦截——保存即分析（A1）、澄清闭环（A2/A3）、未澄清则评审拦截（A4），澄清后自动生成需求文档/任务拆分/架构文档
3.2 任务阶段：AI 节点链——Aicoding（编码）→ AICR（评审）→ Ai智测（测试）→ AI 监控（告警与根因分析）
3.3 度量重建：从个人产出指标转向节点级指标——流转效率、门禁质量、质量结果三层
4. 业务运用与项目落地实际收益
4.1 业务运用场景：澄清门禁覆盖产品需求全量、Aicoding 与 AICR 嵌入核心业务线研发主流程（前后端/客户端/服务端按端分流）、Ai智测进入接口与前端自动化主链路、AI 监控接入核心业务发布后的核心链路与关键转化路径
4.2 落地后效能侧实际收益：需求澄清率、评审周转时长、缺陷逃逸率、交付周期等关键指标的变化，以及 Aicoding / AICR / Ai智测 / AI 监控各自的覆盖与贡献占比
4.3 落地后质量侧实际收益：澄清后返工率下降、评审拦截率误拦截率趋于稳定、线上缺陷改善、AI 监控告警准确率与根因定位效率提升
5. 总结与展望
梳理节点 → 绑定 AI → 设置门禁 → 节点度量
三条原则：度量对象从个人转向节点、度量内容从产出量转向门禁质量与流转效率、治理方式从规范文档转向平台强制
1. 背景：AI时代的研效新挑战
1.1 产出指标失真：代码行数、PR 数被 AI 生成代码迅速膨胀，"指标好看、交付没变快"
1.2 三个失效信号：产出≠价值、缺陷数据失去历史可比性、瓶颈从写代码转移到需求澄清/评审/测试
1.3 一次故障复盘：【待补：现象、发现渠道、根因、影响面】——结论：不是人的失误，是治理体系没跟上 AI 的速度
2. AI时代研发链路变更
2.1 散装的 AI 工具不可见、不可度量、不可治理
2.2 治理对象从"开发者的行为"变成"研发流水线的节点"
3. 腾讯音乐的KGHarness工程实践
3.1 需求阶段：AI 澄清前置 + 门禁拦截——保存即分析（A1）、澄清闭环（A2/A3）、未澄清则评审拦截（A4），澄清后自动生成需求文档/任务拆分/架构文档
3.2 任务阶段：AI 节点链——Aicoding（编码）→ AICR（评审）→ Ai智测（测试）→ AI 监控（告警与根因分析）
3.3 度量重建：从个人产出指标转向节点级指标——流转效率、门禁质量、质量结果三层
4. 业务运用与项目落地实际收益
4.1 业务运用场景：澄清门禁覆盖产品需求全量、Aicoding 与 AICR 嵌入核心业务线研发主流程（前后端/客户端/服务端按端分流）、Ai智测进入接口与前端自动化主链路、AI 监控接入核心业务发布后的核心链路与关键转化路径
4.2 落地后效能侧实际收益：需求澄清率、评审周转时长、缺陷逃逸率、交付周期等关键指标的变化，以及 Aicoding / AICR / Ai智测 / AI 监控各自的覆盖与贡献占比
4.3 落地后质量侧实际收益：澄清后返工率下降、评审拦截率误拦截率趋于稳定、线上缺陷改善、AI 监控告警准确率与根因定位效率提升
5. 总结与展望
梳理节点 → 绑定 AI → 设置门禁 → 节点度量
三条原则：度量对象从个人转向节点、度量内容从产出量转向门禁质量与流转效率、治理方式从规范文档转向平台强制
关注QECon公众号
关注QECon视频号
商务合作
151-2264-3988 木子
票务联系
159-0126-5561 小娟
媒体合作
135-1619-6409 皮皮
购票咨询
小娟 15901265561
