当全行业都在为“如何让 LLM 评价得更准”而绞尽脑汁时，我们是否走错了路？传统的生成式 LLM-as-a-Judge 正在成为企业沉重的“算力枷锁”：不仅全量评测成本高昂，更深陷字数偏置、中心化趋向等系统性偏置。

本次分享将带来一种全新的“探测式评测”范式——BoRP（Bootstrapped Regression Probing）。我们不再让模型“写”评语，而是直接“读取”模型隐状态下的满意度信号。通过对比表示提取与 PLS 回归技术，我们将评测成本降低了 97%，同时在人类对齐度上超越了传统的生成式 Judge。我们将深入解析如何从零构建这套“读脑”管线，包括如何在无标注流量中自动孵化评测标准，以及如何通过层间不确定性量化评测的可信度。这一方案已在万亿级流量的 A/B 测试中落地，为模型迭代提供了实时、高敏的“体温计”。

演讲提纲

1. 行业趋势与评测困境
   • 开放式对话评测的现状：指标 Gap 与滞后的用户反馈。
   • 传统生成式 Judge 的三大“税”：成本税、延迟税、偏置税（中心化倾向、字数偏置）。
2. BoRP 技术架构：从“读”取代“写”
   • 对比表示（Contrastive Representation）：如何通过 Suffix-only Prompt 剥离对话背景，提取纯净的满意度信号。
   • 几何感知探测引擎：利用向量范数（Norm）与离群度（Outlierness）量化极端样本。
3. PLS 回归头设计
   • 相比 PCA，如何通过有监督回归过滤话题噪音，提升样本效率。
   • 冷启动与自动化对齐管线：自引导（Bootstrapping）如何在无标注流量中通过“极化挖掘”自动生成评测标准（Rubric）。
   • 专家对齐：仅需数百条标注实现 Krippendorff’s alpha 0.80 的高信度对齐。
4. 工业级落地优化与 A/B Test 实践
   • KV-Cache 复用与前缀共享：如何支撑单卡 A100 日处理百万级会话。
   • 不确定性预警：利用中间层与输出层差异作为“认知冲突”代理，过滤异常预测。
5. 总结与未来演进
   • 骨干模型进化：更换 Backbone 时如何实现“免重训”迁移。
   • 局限性与未来：复杂推理场景下的生成式补充。

实践痛点：

1. 极端样本挖掘难（“大海捞针”）：在大规模工业流量中，极好或极差的“极化样本”分布极稀疏，传统随机抽样很难构建高质量的评测基准。
2. 评测成本与全量监控的矛盾：生成式模型评测 Token 消耗巨大，导致企业只能进行抽样评测，无法在 A/B Test 中捕捉微小的满意度波动。
3. 生成式评测的“不公平”偏置：模型容易因为回复更长或回复位置不同而给出高分，这种系统性偏置严重干扰了模型的真实优化方向。
4. 模型升级的沉没成本：每次升级 Base 模型，往往需要重新构建数万条评测数据集并重新 SFT 专用评测模型，开发周期极长。

前沿亮点：

1. 范式创新：提出了“Read, Don't Write”的评测新范式。不再依赖模型的生成能力，而是挖掘 LLM 的 latent knowledge，从底层逻辑上消除了字数偏置和格式敏感性。
2. 极高性价比的工程实现：通过 Suffix-only Probing 和多维度特征增强，实现了在 8B 模型上对齐 GPT-4 级的评测精度，且成本降低至前者的 3% 左右。
3. 可解释的评测不确定性：创新性地利用层间隐状态的“认知冲突”来量化评测结果的可信度，为工业界提供了自动化的“坏案例（Bad-case）”过滤机制。

听众收益：

1. 技术方案：掌握一套可落地的、基于回归探测的低成本 LLM 评测架构，解决评测算力贵的瓶颈。
2. 方法论：学习如何利用 Bootstrapping 从无标注数据中自动化提炼业务评测标准（Rubric）。
3. 实战经验：了解如何将 LLM 内部信号与传统 A/B Test 指标结合，提升线上实验的灵敏度和方差削减（Variance Reduction）。

随着 Agent 进入真实业务场景，传统日志、指标和链路追踪已经难以完整回答 Agent 是否正确完成任务、问题发生在哪个环节，以及如何持续衡量和改善 Agent 质量。本次分享将介绍我们建设企业级 Agent 可观测与评估体系的实践。在采集层遵循 OpenTelemetry GenAI语义约定，统一模型调用、工具调用和 Agent 执行过程的埋点与采集。在评估层以 Trace 为核心，配置化接入诊断任务，通过实时处理管线完成任务筛选、关键信息提取和自动评估，到达分钟级延迟。通过声明式表达式支持不同业务 Agent 低成本接入。先小模型粗筛，再大模型精筛的两阶段评估机制，可有效降低90% token成本，使大规模安全、合规等底线类指标评估覆盖全生产流量成为可能。针对部分复杂性能与质量类问题，还将介绍从 Agent 执行链路深入至推理引擎内部推理过程的探索。

演讲提纲

1. Agent 可观测面临的新问题
   • 为什么拥有日志、指标和完整 Trace，仍然难以判断 Agent 是否正确完成任务并定位质量问题。
2. 遵循 GenAI 语义约定的统一埋点与采集
   • 如何统一模型调用、工具调用和 Agent 执行过程的遥测语义，并在标准字段基础上支持业务场景扩展。
3. 以 Trace 为中心的实时评估链路
   • 从 Span 聚合、评估任务筛选和关键信息提取，到评估执行与结果沉淀。其中包括通过声明式表达式适配不同业务 Agent 和 Trace 结构，降低新 Agent 和新评估场景的接入成本。
4. 面向全量生产流量的两阶段评估实践
   • 首先使用轻量小模型进行全量、低成本、高召回筛查；再对候选 Trace 按需加载完整执行上下文，由大模型完成精准语义裁决，在保障评估覆盖范围的同时控制实时运行成本。
5. 从 Agent 执行到模型推理的深度分析
   • 如何关联 Agent Trace 与模型推理过程，在 Token 粒度进一步定位性能问题。并探索模型内部不确定性信号在轨迹分析中的应用。
6. 真实业务落地案例与实践经验
   • 结合具体业务 Agent，介绍从标准化埋点、评估任务配置和生产运行，到问题发现、原因定位与质量改进的完整过程，并分享落地中的工程取舍与实践经验。

实践痛点

1. 面向全量生产流量的两阶段评估实践可以有效解决token成本问题，但是强依赖有效的小模型。而小模型需要针对业务场景训练，才能做有效的过滤，成本不低。
2. 从 Agent Trace 到推理引擎的跨层深度可观测，要求对推理引擎埋点，存在一定开发接入成本。

前沿亮点：

1. 面向异构 Agent 的声明式 Trace 实时评估
   • 将 Trace 从事后查询的数据转变为持续运行的评估对象。评估任务可以通过配置动态定义 Trace 筛选、关键维度提取和评估输入。对于已经完成标准化埋点的 Agent，新增评估场景时无需修改 Agent 埋点或重复建设数据处理链路；接入新的 Agent 时，也可以通过表达式适配其业务 Trace 结构。
2. 面向全量生产流量的两阶段评估
   • 针对安全、合规等底线类场景，首先使用轻量模型进行全量、低成本、高召回筛查；再对候选 Trace 按需加载完整执行上下文，由大模型完成精准语义裁决，在保障评估覆盖范围的同时控制实时运行成本。
3. 从 Agent Trace 到推理引擎的跨层可观测
   • 将 Agent 业务请求、LLM 节点和模型推理过程关联起来，在 Token 粒度分析生成时序和推理性能，并结合 Token 概率分布、熵等不确定性信号，探索质量预测与后置分析。

听众收益

• 了解如何基于统一的 GenAI 遥测语义构建 Agent 可观测基础，以及如何从标准化 Trace 进一步走向实时质量评估、大规模生产运行和深度问题定位，获得一套可用于 Agent 可观测体系化建设思路。
   

运维的数据早就齐了——指标、日志、Trace、变更、CMDB 都在线上，但一个告警落地后，人仍要跨多个平台拼上下文、做初判、推处置。瓶颈不在工具覆盖度，在事件处理链路没被系统串起来。
我们没有把工具都挂到一个问答框里，而是把运维事件做成一等公民：告警、巡检、变更、应急触发后，先由确定性 pipeline 完成上下文预取，再交给 Agent 做归因推理与方案生成，并且在上下文中持续更新运维事件的状态。
但跑通一次只是起点。运维场景的长期难题是经验只沉淀在个别人身上、同类误判反复出现。所以我们把改进助手本身也做成闭环：从事件处理过程中提取运维经验，在同类事件中召回复用，用线上反馈驱动迭代，并配套可回归、可回滚的验证机制。体系已在公司多条核心业务线的大盘巡检、告警初判、应急定位场景落地。本次分享会讲清这套运维事件驱动的Agent架构，以及如何让运维Agent能持续进化。

演讲提纲：

1. 为什么工具都齐了，运维还是这么累
   • 一个告警到闭环要走十来步，真正耗时的不是决策，而是前面重复的信息查询和上下文拼接
   • DevOps 解决交付协同，AIOps 解决发现异常，但还没有理解事件的处理流程
   • 一个判断：Agentic AIOps 的第一个技术问题不是选模型，是上下文从哪来
2. 事件驱动而非对话驱动：运维助手的架构内核
   • 为什么不做运维版 ChatGPT：对话入口只服务"我主动问"，而运维的高价值场景是事件自己找上门
   • 运维事件与上下文的交互机制
3. 领域经验怎么进助手：Skill 与记忆的双层沉淀
   • Skill 承载流程，记忆承载结论，两者的边界与各自的适用场景
   • 关键设计是作用域绑定团队而非个人
4. 运维助手的自进化
   • 自进化的切入点：运维经验
   • 运维经验的提取、召回与迭代
   • 怎么验证效果：运维助手的评测能力
5. 总结与展望
   • 快手AgenticOps的实现路径和效果总结
   • 下一步：处置边界继续扩大，让助手从辅助判断走向风险可控的自主处置

实践痛点：

1. 上下文该放什么，运维事件可关联的信息几乎没有边界，放多了撑爆上下文、稀释注意力，真正的证据被淹没；放少了缺失关键信息，归因直接跑偏。
2. 人工沉淀下来的知识会劣化，业务写好的 Skill 和知识，随着时间推移和架构演进逐渐不再适配，助手会稳定地按过时的步骤做错事——怎么防劣化，甚至让它自己持续优化。
3. 运维 Agent 怎么评测。 只看准确率、时延或关键步骤达成率都不足以判断一次改进的好坏，而运维依赖的时序数据会过期，昨天的告警今天已经回放不出当时的现场。

演讲前沿亮点：

1. 以运维事件为一等公民而非以对话为入口，配合确定性上下文预取，让运维模式由"人决定查什么"变成"系统先跑一遍、人做确认"。
2. 自进化的对象是结构化的运维经验而非模型权重，反馈只回流到可 diff、可审计、可单独回滚的经验资产上，因此"助手为什么变好了"和"这次为什么变坏了"都能追溯到具体某次变更——这是低容错场景做自进化的前提。

听众收益：

1. 一套 Agentic Ops 的完整落地架构：事件模型、上下文预取、经验沉淀与自进化闭环，以及每个环节的取舍依据。
2. 一条不依赖模型微调的 Agent 自进化路径：运维经验怎么提取、怎么召回、怎么迭代、怎么验证效果。

大多数团队的 Agent 停在「能跑一次」：demo 惊艳，上生产后开始悄悄跑偏——输出看着完整却没达标、反复调同一个工具烧 token 却零推进、结果对但过程越权。根因不是模型不够强，而是缺少独立评估闭环。本次分享拆解两条仍在生产运行的 Loop：一条每天自动产出会议纪要并自我进化，一条支撑开放平台「申请→自动开通→通知→日报」。核心是双层评估：生产 checker 打 94 分，每天另跑一个盲评 Meta-Evaluator 只给 85 分，偏差超过 8 分自动触发 rubric 校准；每周再用 Planner-Generator-Evaluator 三 Agent 做单变量对抗迭代，让系统自己升级并支持快照回滚。我会给出可复用的设计八问、三类隐性失控信号的监控方式，以及一串真实踩坑：prompt 层去重被 LLM 无视、写接口「假成功」、快照把磁盘和 inode 双撑爆、评估成本翻倍怎么权衡。目标是让你的 Loop 从「跑通一次」变成「连续跑对十次」。

演讲大纲：

1. 开场｜为什么「跑通一次」不等于能上生产
   • Agent 是能力，Loop 是系统：敏态 Agent（Codex / Claude Code 作为通用执行引擎）与稳态 Loop（目标、触发、验收可定义）的分界
   • 一个反直觉判断：Loop 的门槛不是模型能力，是评估与信任架构
2. Part 1｜案例拆解：一条会进化的会议纪要生产线
   • 七块拼图：自动化触发（录音生成即启动）/ worktree 隔离 / Skill 场景模板 / MCP 连接日历·文档·IM / 子 Agent 分工（转写·总结·行动项·评审）/ 记忆库（让本周周会从上次接着开）/ 独立 Evaluator
   • 前六块只保证「做出来」，第七块才保证「做对」
   • 现场读看板：生产 checker 94 分 vs 盲评 Meta-Evaluator 85 分，两条线为什么必须分开
   • 自动校准机制：偏差 > 8 分即触发 rubric 重校，并把偏差原因存为下一轮升级素材
   • 自进化：每周 Planner → Generator → Evaluator 单变量对抗迭代 + 快照晋升/回滚 + HUMAN_GATE 人工闸门
3. Part 2｜通用方法：设计一个 Loop 的八问，与它的自然顺序
   •  ①目标与完成态 ②触发与调度 ③上下文与 Skill ④工具与分工 ⑤隔离与安全 ⑥记忆与状态 ⑦评估与观测 ⑧身份与权限
   • 顺序不能乱：先定义成功 → 再设计执行 → 最后补护栏
   • 关键实现细节：Evaluator 只返回 PASS / REWORK / ESCALATE + 修改建议；模型分层（高频执行追成本，关键验收追可靠性）；每个有副作用的动作必须有幂等键
   •  30 秒现场套用：一句话业务需求（「表单新增申请就自动开通模型权限」）如何逐句落到八问的每一格
4. Part 3｜踩坑实录：五个把我打醒的生产故障
   • 约束只写进 prompt 就等于没写：去重逻辑交给 LLM 判断，结果被无视、纪要重复生成——必须回落到代码层 filter 兜底
   • 写接口的「假成功」：清空多选字段传 null 返回 ok: true 但值没变；每次写入都要「写后复核」
   • 空跑被误判为失败：0 篇输入时依赖 Agent 自己写结果文件，可靠性不足导致告警刷屏——静默成功也要有显式标识
   • 自进化把磁盘撑爆：快照目录把根分区的容量和 inode 双打满，全链路自动化集体失败；配额/清理必须和自进化同步设计
   • 凭证与额度是隐性单点：user token 静默失效、算力预算池月度耗尽（HTTP 402）——需要区分「可自愈态」与「真失效」，真失效自动推二维码/停止重试（每个坑都给出「现象 → 误判 → 根因 → 现在的兜底」四段式）
5. Part 4｜三类隐性失控与信任架构
   • 三类失控信号：过早宣布完成 / 装忙死循环 / 结果对但过程越权 → 对应监控结果质量、状态推进、过程合规三层
   • 生产门槛四件事：稳定可恢复的运行载体（本地跑通的 demo 不是生产环境）、Agent Identity、最小权限（默认无权限、临时授予、用后回收）、全链路审计（模型/Prompt/工具调用/授权主体/成本）
6. 收尾｜可带走的三条与起步建议
   • 运动员 ≠ 裁判；先定义成功再设计执行最后补护栏；挑一个每周重复且结果可验收的小任务，让它连续稳定跑对十次

您认为，这样的技术在实践过程中有哪些痛点？

1. 评估成本与覆盖率的 tradeoff：双层评估几乎让 token 成本翻倍。全量盲评太贵，抽样又会漏掉长尾问题。我目前的折中是「生产 checker 全量 + Meta-Evaluator 每日抽样盲评」，代价是偏差发现有最长 24 小时的滞后。
2. 裁判自己也会漂移：LLM-as-Judge 的 rubric 会随模型版本和 prompt 微调而松动，谁来审计审计员？加第三层只是把问题推后一层，最终必须有人工闸门（HUMAN_GATE）兜底，这意味着「完全无人值守」是个伪目标。
3. 自然语言约束不可靠：写进 prompt 的硬规则（去重、幂等、格式）会被模型在长上下文里无视。可靠的做法是把确定性逻辑退回代码层，但这样 Loop 就变「硬」了，牺牲了灵活性——哪些约束该硬编码、哪些该留给模型，没有标准答案。
4. 自进化与稳定性天然冲突：让系统自己改自己（prompt、rubric、阈值）意味着回归难以复现。必须配快照晋升 + 一键回滚 + 单变量迭代，工程复杂度远高于「写一个 agent」，且快照本身会吃掉磁盘与 inode。
5. 幂等 vs 及时性：状态列/state 文件去重能防重复副作用，但轮询增量模型下，边界数据（并发写入、跨天记录）仍会漏或重；把去重窗口放宽会牺牲及时性。
6. 可观测性缺口：Agent 的失败大多是「语义失败」而非报错，传统 APM 和日志抓不到；trace 里能看到调用链，但判断「这次输出到底对不对」仍要额外一次模型调用，观测本身就是成本。
7. 凭证与配额是被低估的运维成本：无人值守系统里，token 过期、额度耗尽、机器磁盘满这类「非 AI 问题」，占了我实际故障的一半以上。

演讲有哪些前沿亮点？

1. 双层评估 + 偏差阈值自动校准（业界多数停在单层 LLM-as-Judge）
   • 常见做法是用一个 judge 给输出打分，但 judge 与执行同源、且尺子会自己变松。我的方案是在生产 checker 之上再架一个每日盲评的 Meta-Evaluator，用两条分数线的偏差（94 vs 85）作为可监控指标，偏差超阈值（8 分）就自动触发 rubric 重校，并把偏差原因沉淀为升级素材——把「评估质量」本身变成了一个可度量、可自动干预的信号，而不是靠人定期抽查。
2. Planner-Generator-Evaluator 三 Agent 单变量对抗式周迭代 + 快照晋升/回滚
   • 把「优化 Agent 系统」这件事也做成 Loop：每周由 Planner 提出单变量改动、Generator 实施、Evaluator 独立判优劣，通过则快照晋升，不通过则回滚，并保留人工闸门。相比手工调 prompt，它让系统升级变成可复现、可审计、可回滚的工程流程——这是把 Operator（经营者）这个角色自动化，而不只是把执行自动化。
3. 「八问」需求即设计法：让不写代码的产品/业务同学也能交付可运行 Loop
   • 一句话业务需求逐句映射到目标·触发·上下文·工具·隔离·状态·评估·权限八格，拆清楚即可交给 coding agent 实现。已在两个真实场景（会议纪要、开发者权限开通）验证通用性——它的价值不是方法论漂亮，而是把「Agent 落地卡在谁来设计」这个组织问题解掉了。

面对不同人群对 Agent 评估标准的差异化需求，本次分享介绍小红书普通配置与高级编排的方案取舍，展开多粒度评估、评估器组合、数据处理与串并行编排等关键技术，以及在线、离线评估的双轨闭环。结合真实案例，分享通用评估适配不足、复杂编排配置成本高及业务深度协作等落地经验。

演讲提纲：

1. Agent 评估的差异化需求与分层架构
   • 产品运营、轻量与深度 Agent 开发者的评价标准与使用需求；普通模式与高级模式的产品设计和适用边界；通用能力、业务定制与配置复杂度之间的取舍；统一评估底座的架构设计。
2. 多粒度评估与可扩展编排框架
   • 从生产 Trace、用户反馈和业务用例构建评估集；覆盖结果、节点、轨迹与多轮任务的评估需求；规则、代码、LLM Judge 与人工校准的分工；通过数据清洗、字段映射、共享中间结果及串并行编排，适配差异化业务标准。
3. 在线与离线评估的双轨闭环
   • 离线侧通过固定数据集、任务回放与版本对比验证修改效果；在线侧通过生产流量采样、持续评估和问题复核发现真实问题；讨论问题回流、数据集版本管理与持续回归的衔接设计，结合业务效果、时延及成本分析改进收益。

实践痛点：

1. 通用评估的业务适配能力有限。
   • 普通模式配置简单，适合快速验证，但面对差异化标准和复杂任务，通用指标难以准确反映真实业务效果。
2. 高级编排的配置与协作成本较高。
   • 高级模式能够满足核心 Agent 业务的定制需求，但配置与调试复杂，需要业务深度参与标准定义、样本建设和评估校准。

前沿亮点：

• 差异化标准驱动的分层设计：结合不同人群的评估需求，解析普通配置与高级编排的适用边界和设计取舍。
• 多粒度评估与可扩展编排：介绍结果、节点、轨迹及多轮评估，以及多类评估器、共享中间结果和串并行流程的组合设计。
• 双轨协同与真实案例复盘：围绕离线验证、在线评估和问题回流，分享通用能力适配、复杂配置与业务协作中的实践经验。

听众收益：

• 了解如何根据业务标准和评估深度，选择合适的产品模式与技术方案。
• 掌握将业务要求转化为评估维度、评估器和可执行流程的关键设计思路。
• 获得版本验证、问题回流及业务共建的方法参考，减少评估平台落地中的配置与协作成本

Agent 上线之后，团队通常并不缺少 Trace，也不缺少一次性的评估工具，真正困难的是如何把这些能力串成一条可以持续运行的改进链路：原始 Trace 噪声多、结构不一致，无法直接作为评估对象；业务规则散落在人和文档中，难以转化为 Pipeline 和 Evaluator；Badcase 被发现后没有进入版本化数据集；Prompt、Skill 或 Harness 调整之后，也缺少一致的实验环境证明它真的变好了。
本次分享将介绍我们在Agent调优中的数据飞轮实践：首先将 Trace 按 Session 聚合并清洗为包含完整上下文和行为过程的 Trajectory；再通过可配置、可对话构建的 Pipeline 完成数据重组、语义增强、AI 预标注与分流，持续沉淀黄金数据集和回归集；随后组合 Code、LLM、Agentic 等不同 Evaluator，对文本、多模态输入、工具调用和任务完成过程进行持续评估，并将 Badcase 和评估证据回流数据集；最后通过 Baseline、实验、回归门禁验证 Prompt、Model、Tool、Skill、Workflow 与 Harness 的改动。
在此基础上，我们进一步将调优划分为手动挡、半自动挡和全自动挡：从人分析 Trace，到系统生成优化候选，再到自动实验和受控发布；并探索 Trace to Skill、Workflow、SQL、Script，以及 Trace-based Skill Optimize、Harness Fix 等面向不同对象的优化方法。

演讲提纲：

1. 从 Trace 到 Trajectory：构建可评估内容的数据管线
   • 为什么原始 Trace 不能直接作为高质量评估数据
   • Trace、Session 与 Trajectory 的区别
   • 从 Span 清洗、Session 聚合到完整任务轨迹
   • 基于 Pipeline 完成去重、重组、字段提取和语义增强
   • AI 预标注、场景分类与数据分流
   • 如何通过对话描述业务目标、预览真实轨迹并调整 Pipeline
2. 从 Trajectory 到黄金数据集：沉淀可复用的质量资产
   • 从 Trajectory 构建结构化 Dataset
   • 候选样本、Badcase、黄金集和回归集的区别
   • 数据去重、质量筛选和场景覆盖度
3. 从持续评估到实验验证：发现 Badcase 并验证改进
   • 如何把业务目标转化为可执行的评估标准
   • Code、LLM 与 Agentic Evaluator 的区别与选择
   • 多模态 Agent 的评估对象建模与工程边界
   • 通过真实轨迹预览、人工校准、回测和版本管理保证 Evaluator 质量
   • 从持续评估到 Badcase 发现、聚类、归因和回流
4. Trace2Optimizers：从人工调优到受控自进化
   • 手动挡&自动挡&半自动挡的调优模式。
   • Token成本和效率：基于算法优化Agent的成本。
   • Agent自进化模式：Benchmark上的验证和实践落地。

实践痛点：

1. 轨迹完整性与采集成本之间存在矛盾。
2. 数据清洗与事实保真之间存在矛盾。
3. 不同类型的评估器选择。
4. 持续评估的需求和成本。
5.  Agent自进化与企业生产稳定性需求的矛盾。

前沿亮点：

1. 从“评估算法”转向“评估工程的生产与交付”
2. 以 Trajectory 为中心连接数据、评估和实验
3. 面向不同优化对象的 Trace2XX 方法
4. 手动挡、半自动挡、全自动挡的渐进式自进化

听众收益：

1. 理解 Trace、Session、Trajectory、Dataset、Evaluation 和 Experiment 在 Agent 数据飞轮中的职责边界。
2. 掌握从原始 Trace 构建可评估轨迹和版本化黄金数据集的方法。
3. 学会根据场景组合 Code、LLM 和 Agentic Evaluator，而不是只依赖单一 Judge。
4. 获得一套从 Badcase 发现、数据回流到实验验证和发布回滚的完整闭环。
5. 理解 Prompt、Skill、Workflow、SQL、Script 和 Harness 等不同对象如何基于 Trace 持续优化。
6. 根据业务风险选择手动、半自动或全自动调优模式。

被评测应用已经从 NLP、排序列表和问答，快速扩展到会规划、调用工具并改变系统状态的多轮 Agent。评测因此不再只是上线前的验收动作，而成为业务目标、产品需求与 AI 能力持续双向校准的自进化 PRD。

本次分享介绍一套兼容多评测对象、多评测方法的中台实践：以 Plan-and-Execute 组织动态评测路径，通过 Code/LLM/Agent Judge 与人工校准协同完成验证，并将评测集、Rubric、真实会话、badcase 和分歧样本沉淀为可持续迭代的质量资产。分享将重点拆解复杂 Agent 的过程验真、评分器稳定性、数据与标准演进、多轮 badcase 复现，以及“评测的评测”如何为自进化建立护栏。

演讲提纲：

1. 更精准、更低成本的评测诉求
   • 业务与评测双咬合进化：评测是 AI 时代可自进化的 PRD
   • 多种评测对象并存：NLP 结果、排序列表、LLM 问答、多轮 Agent 任务等，以及复杂 Agent 的评测挑战
   • LLM-as-a-Judge 的价值、实践与局限是什么，需结合 Agent-as-a-Judge 提升复杂场景准确度
   • 评测需求爆发，但评测本质是复杂工程科学
   • 评测中台的价值与核心诉求
2. 评测中台设计
   • 中台设计目标：解决成本高、不稳定、不精准、复用性差等问题
   • 中台分层结构：接入层、执行层、数据层、自进化层
   • 执行范式：采用 Plan-and-Execute，由 Planner 生成计划、Executor 编排执行、Summary 完成三层归因、Annotation 标注并推动改进
   • 动态执行方案：根据对象、数据、维度、风险和成本生成评测路径和调度策略
   • 统一评分器：Judge Node 接入 Code Judge、LLM Judge 与 Agent Judge
   • Agent Judge 稳定性：Harness 约束工具、轮次、Token、时间与结构化输出
   • 评测触发机制：门禁准入、实时线上巡检、历史真实会话巡检
   • 评测的评测：为评测自进化建立护栏
3. 业务落地实践经验
   • 评测集：按业务风险准备、更新与版本化数据集
   • 评测维度：静态评测覆盖 Skill、Prompt、知识库，动态评测覆盖任务过程、工具调用、系统状态与最终结果
   • Rubric 设计：单 query 定制 Rubric 与单目标通用 Rubric 的粒度取舍
   • Rubric 稳定性：通过证据要求、正反例、缺证处理与一致性校准提升准确性
   • 多轮执行：构造多轮评测，并复现和回放多轮 badcase
   • 人工校准：聚焦低置信、人机分歧和高风险样本，沉淀 golden set 与分歧集
   • 组织协同：明确不同角色的人与 AI Agent 的协同 SOP、站位与职责，何时需要做什么，使得系统Loop最更高效
4. 总结与反思
   • 评测成熟度如何度量、评测体系的进化路线
   • 未来挑战：持续应对模型切换、工具变化、知识过期、记忆污染、环境漂移与成本上升带来的质量退化
   • EDD 驱动的业务进化探索：PRD 与评测用例、预期结果同步给出

实践痛点：

1. 覆盖率、准确率、成本之间的平衡三角需要反复调整，比如评测效率与评测覆盖；比如 rubric越明确和细化，打分稳定性和准确性越高，但是维护和迭代成本也更高
2. 人机一致率、人人一致率、机机一致率 对齐成本高
3. 多轮badcase问题复现难：长短期记忆难以构造、多人交互的时序问题处理
4. agent 如果涉及前端样式评测，还需要还原客户端信息给人和评分器，否则与人的体验不一致

演讲前沿亮点：

1. 支持多对象、多评测方法的统一建模、执行与归因
2. 用 Plan-and-Execute 动态生成评测路径与数据，提升评测能力上限
3. 用什么样的 Harness 提升 Agent Judge 的稳定性与可控性
4. 用 golden set、分歧集和成熟度指标，实现“评测的评测”

听众收益：

1. 理解如何搭建通用的评测中台框架
2. 掌握评测过程的多轮 Agent 的过程验真、Rubric 设计和 badcase 复现思路
3. 学会用评测数据、人工校准和归因结果，推动业务持续进化