头部 AI 智能体 / Claw 类产品上线测评闸门与指标体系

访谈身份：腾讯云与智慧事业群，混元大模型部，测试架构师；负责 WorkBuddy‑Bench 评测套件，支撑 WorkBuddy、CodeBuddy、元宝等 Agent/Claw 类产品的版本测评、上线质量门禁；参与内部 Agent 从研发到灰度上线完整测评流程。

 

背景说明：以下为腾讯内部 Agent/Claw 类产品（WorkBuddy、CodeBuddy）真实落地实践，区分硬性一票否决指标、观察参考指标；覆盖测评关卡、样本规模、人机分工、竞品对标、行业建议；所有阈值为内部业务生产实践值，不同业务线会做微调，不是集团统一强制标准。

模块一：整体测评框架与指标分层逻辑（20‑30 分钟）

开场承接：感谢您拨冗指导。我们特别想了解头部 AI 产品在上线这道 “闸门” 前，究竟是如何设立测评关卡和评价标准的。

Q1（指标分层核心问题）

问题：贵公司在 AI 智能体、claw 类产品上线前，测评指标是如何分层设计的？请明确列举，哪些属于 “硬性上线指标”（一票否决，不达标绝不上线） ，哪些属于 “参考性 / 观察性指标”（仅用于版本对比和优化方向参考，不阻碍上线）？

 

追问：划分硬性与参考性指标的根本逻辑是什么？

回答正文

我们内部针对 WorkBuddy（办公 Agent）、CodeBuddy（编码 Agent）这类 Claw 式智能体，会把全部测评指标划分为三大类：【硬性门禁・一票否决指标】、【半硬性风险预警指标】、【观察参考型指标】。

补充：除了硬指标，还有合规安全类是最高优先级红线，独立于技术指标，一旦触碰直接阻断上线，例如产生违法内容、越权高危操作、隐私泄露，属于绝对红线。

1）硬性上线指标（一票否决，不达标禁止上线 / 扩量）

核心定位：关系到用户资产、业务正确性、重大风险、核心主链路不可用；一旦指标不达标，上线后会直接引发客诉、线上故障、资金 / 数据安全事故，没有妥协空间。

 

分为四大组：功能正确性、高危风险、执行稳定性、合规安全红线。

1. 核心场景任务成功率（Agent/Claw 最核心硬指标）
    
   定义：Bench 基准集中 P0 优先级核心任务，完整完成任务的占比；P0 是用户最高频、主链路不可缺少的场景。
    
   业务示例：CodeBuddy 的代码修改编译运行成功；WorkBuddy 文档处理、表格分析主流程；Claw 的网页操作完成完整业务目标。
2. 高危行为误触发率
    
   定义：在风险专项测试集下，Agent 误触发破坏性高危动作的概率；例如：git reset‑hard、文件批量删除、越权访问隐私文件、模拟资金操作。
3. 工具调用基础正确率
    
   定义：P0 场景下工具选择、入参参数正确性；Agent 不能乱选工具、传非法参数，工具调用错误会直接导致任务彻底失败。
4. 长流程任务异常终止率
    
   定义：多轮长流程（≥8 轮思考）任务，非人为干预下出现崩溃、无限循环、任务漂移的占比；长流程是 Claw 类产品高频故障点。
5. 合规 & 安全红线（独立最高优先级，无条件一票否决）
    
   输出违规内容、隐私泄露、诱导高危操作、越权访问，只要样本出现可复现案例，直接阻断上线，不看数值。
6. 基础环境兼容性通过率
    
   支持的沙箱 / 浏览器 / 运行环境下，基础任务可正常启动执行；大面积环境不可用直接阻断发布。

✅注意：硬性指标只针对 P0 最高优先级场景；P2、P3 次要场景不会作为一票否决。

2）半硬性・风险预警指标（不直接一票否决，但触发必须做风险评审）

指标不直接卡死上线，但恶化之后必须输出风险评估报告，评估是否可以灰度小流量放行；如果风险评估结论为高风险，同样会阻止全量上线。

• P1 次优先级场景任务成功率
• 工具调用幻觉发生率（工具编造参数、编造不存在 API）
• 任务漂移发生率：Agent 偏离原始测试目标的比例
• LLM‑as‑Judge 断言误报 / 漏报率
• 资源开销指标：单任务平均 Token 消耗、执行耗时暴涨

举例：P1 场景成功率小幅下跌，下跌幅度在可接受区间，同时没有高危新增问题，可以申请灰度小流量观察；如果伴随高危误触发上涨，则禁止全量上线。

3）参考 / 观察性指标（仅用于版本对比，不会阻塞上线）

定位：用于版本迭代对比、定位优化方向、产品体验持续改进；指标好坏不直接决定是否放行上线；允许版本间小幅波动。

主要包括：

1. P2/P3 低频次要场景任务完成率
2. 对话自然度、语言流畅度、文案润色效果主观打分
3. 非核心链路的工具调用效率、步骤冗余度（Agent 做多余无效步骤）
4. 探测类覆盖率：功能点探测覆盖率、页面访问覆盖率、接口调用覆盖率（前面访谈提到的三个指标）

重点说明：这三个覆盖率我们只作为观察参考指标，不做上线门禁。覆盖率高只说明探测到的路径多，但不等于任务做对；覆盖率低，用来提示测试团队 “测试集可能存在缺口”，但不会直接阻止版本上线。

5. 用户体验主观问卷得分、回答文采丰富度
6. 非主链路的 token 开销、次要场景的执行时延
7. 竞品对标差距分：和豆包、通义千问、OpenClaw 横向对比分，仅用来找迭代差距，不做上线闸门。

👉追问回答：划分硬性与参考性指标的根本逻辑

我们划分的底层逻辑有 4 条，不是简单看 “指标名字”：

1. 线上故障的损害量级：一旦不达标上线，是否直接产生重大客诉、数据 / 资金安全事故、核心主流程大面积不可用。如果是，定为硬性 P0 门禁；次要体验变差、低频场景效果下滑，归为观察指标。
2. 问题的可观测性 & 可灰度兜底能力：如果缺陷一旦上线，小流量灰度也很难捕捉、一旦扩散后果严重，就必须前置设硬性门禁；如果问题仅影响低频体验，线上灰度、用户反馈可以快速发现，可降级为观察指标。
3. 指标本身的确定性：指标是否是客观可复现、确定性强。

   举例：P0 任务是否编译成功、文件是否被误删除，是客观程序校验，结果稳定，适合做硬性门禁；

    

   而 “文案好不好看、自然度” 主观打分，本身打分存在抖动，只能做参考观察，不能一票否决上线。

4. 场景优先级分层（P0/P1/P2/P3）：同一个指标，P0 场景是硬门槛，放到 P3 低频场景就变成观察指标。

举个例子：“任务漂移发生率”，P0 长流程任务漂移是硬性风险；但对于低频 P3 娱乐类任务，漂移只会影响体验，仅作为观察。

补充一个内部踩坑经验：最容易犯的错误，就是把主观体验指标、探测覆盖率这类参考指标强行设置为硬性门禁。Agent/Claw 大模型本身存在合理的随机抖动，如果把主观分、覆盖率作为硬门槛，会出现版本无法发布，大量无意义回滚。所以必须严格区分客观事实类指标和主观体验类指标。

Q2（维度与具体指标）

问题：测评体系覆盖哪些维度？请举例说明核心硬性指标的具体阈值（如：核心场景准确率≥85% 等）。对于 “参考性指标”，请举例说明其用途。

回答正文

一、整体测评五大维度（WorkBuddy‑Bench 体系）

表格

 

测评大维度	说明	包含的指标类型
1. 任务功能完成度（最核心）	Agent/Claw 能不能把给定任务真正做完，产物是否符合预期	✅硬性（P0 任务成功率）、半硬性（P1 成功率）、🟡观察（P2/P3）
2. 工具与执行行为维度	工具调用、多轮思考、动作执行、是否漂移、是否死循环、高危误操作	✅硬性：高危误触发率、工具调用正确率、长流程异常终止率
3. 知识与内容生成质量	知识问答、文档生成、信息准确性、幻觉、事实错误	✅硬性：P0 知识事实错误率；🟡观察：通用问答幻觉占比
4. 体验与交互维度	对话自然度、步骤冗余、文案流畅、用户感知体验	🟡绝大多数为观察参考指标，极少设置硬门槛
5. 安全合规 & 性能资源	内容合规、越权高危动作、耗时、token 消耗、环境兼容性	✅硬性：合规红线；半硬性：资源暴涨告警；🟡观察：单任务 token 消耗

特别说明：对于 Claw 类智能体，任务完成度、工具执行行为，优先级高于单纯的文本问答准确率。传统 LLM 只看回答文本；但 Claw 会产生真实文件、执行工具、操作网页，产物正确性＞输出话术好不好看，这是和普通大模型测评最大的区别。

二、核心硬性指标 + 内部生产阈值（WorkBuddy、CodeBuddy，P0 基准集，基于 Bench 自动化程序校验，不同业务线 ±3 个点浮动）

⚠️重要前提：阈值不是拍脑袋，是结合线上客诉基线、历史版本故障数据定下来；P0 任务为最高频核心场景，样本来自线上真实用户任务脱敏沉淀；阈值会随产品成熟度迭代，早期 Beta 版本阈值会适度放宽，正式全量发布版本收紧。

1. P0 核心场景任务完整成功率【硬性・一票否决】
   • Beta 灰度版本：≥82%
   • 正式全量上线版本：≥88%

   解释：是指任务最终产物经过程序校验完全达标，不是 “Agent 嘴上说自己做完”；CodeBuddy 看代码编译 + 单测通过；WorkBuddy 看文档导出结果 diff 校验。低于阈值禁止全量上线；如果灰度版本跌到＜75%，直接回滚。

2. 高危动作误触发率【硬性・一票否决】
   • P0 风险专项集：高危破坏性动作误触发 = 0（零容忍）

   只要 Bench 风险测试集中，可稳定复现 Agent 主动触发删除文件、git reset‑hard、越权读取隐私文档这类破坏性动作，直接阻断上线，不接受百分比。允许出现 “用户显式下达高危指令才执行”，但禁止 Agent 在无用户指令下主动触发高危操作。

3. P0 场景工具调用基础正确率【硬性】

    

   Beta 版≥86%；正式全量≥92%

   工具调用选择正确、入参合法；排除用户指令本身语义模糊的 case；大量工具调用错误会直接让任务直接失败。

4. P0 长流程任务（≥8 轮）异常终止 / 漂移率【硬性】

    

   正式全量上线：≤6%；Beta 灰度允许≤10%

   包含无限循环、任务严重漂移、执行崩溃；超过阈值，长流程主链路稳定性不足，不允许全量扩量。

5. P0 知识事实错误率（事实类任务）【硬性】

    

   正式版：P0 知识场景事实幻觉错误 ≤4%；

   针对需要严格事实的 P0 任务，文档分析、财报提取；虚构关键事实属于硬故障；P2 普通闲聊问答不纳入硬性约束。

6. 基础环境兼容性通过率【硬性】

    

   全部官方支持的沙箱、浏览器环境，P0 任务基础启动执行通过率 100%；大面积环境不可用直接阻断。
7. 合规安全红线（独立最高优先级）：可复现违规 / 隐私泄露案例 = 0，一票否决，无百分比。

三、半硬性风险预警指标示例（触发后风险评审，不直接卡死，但高风险则阻止全量）

1. P1 次优先级任务成功率：灰度版本≥75%，正式版≥83%；低于该值启动风险评审；
2. P1 任务工具幻觉发生率 ≤12%；
3. 单任务平均 Token / 耗时，对比基线上涨超过 30% 触发资源风险评审，评估成本与服务稳定性。

四、参考性 / 观察性指标：用途 + 实例

观察指标不阻塞上线，三大用途：①版本之间横向对比，看迭代变好还是变差；②定位产品优化的薄弱环节，给算法 / 产品输出优化方向；③作为竞品对标参考基线。

示例 1：P2/P3 低频次要场景任务完成率

 

用途：看低频边缘场景能力变化；哪怕从 65% 跌到 60%，只要 P0/P1 硬指标全部达标，不阻断上线；但是会记录在版本报告，作为下个迭代优化重点。

示例 2：功能点探测覆盖率、页面访问覆盖率、接口调用覆盖率（前面访谈提到）

 

用途：评估当前测试 Bench 数据集是否完备。比如功能点探测覆盖率从 86% 跌到 79%，不阻止版本发布，但是提示 QA 团队：有一部分 PRD 功能点没有被现有任务集命中，需要补充测试 case，完善 Bench。

再次强调：覆盖率只评估测试集完备度，不代表 Agent 能力好坏，绝对不做上线门禁。

示例 3：主观体验打分：对话自然度、步骤冗余度

 

由人工评测员打分（1‑5 分）；用途：版本之间对比体验变化；比如新版本任务成功率硬指标达标，但是 “步骤冗余” 分明显下降，说明 Agent 虽然任务做完，但是绕路、多余步骤多；不会不让上线，但是会给到算法团队，作为 Prompt、Agent 逻辑优化的方向。

示例 4：竞品对标差距分

 

和 OpenClaw、豆包 Agent 横向对比各项得分；用途：看清行业位置，找到差距点，指导 roadmap；不会因为不如竞品就不上自己的版本。

示例 5：单任务 token 消耗（非主链路）

 

观察成本变化；只有暴涨超过 30% 才升级为半硬性风险预警。

---

模块二：测评执行流程与上线决策机制（20‑30 分钟）

Q3（流程与闸门）

问题：从 AI 智能体 \claw 类产品研发完成到最终上线，测评需要经过哪几道 “关卡”（如：准入冒烟测试 → 全量自动化客观评测 → 人工主观对抗评测 → 线上灰度 A/B 测试）？每道关卡的通过标准是什么？测评集构造方法是什么？一般测一个指标，测评集的样本量是多少？

回答正文

以 WorkBuddy / CodeBuddy 这类 Claw 智能体内部发布流程为例；整体分为研发自测准入 → 冒烟门禁 → 全量 Bench 自动化客观评测 → 人工专项对抗评测 → 灰度小流量 A/B → 全量发布六道关卡；每一关不通过，不允许进入下一关。

 

重要区分：Claw 类 Agent 和传统 App 最大区别：自动化 Bench 跑客观产物校验是核心闸门；人工评测更多做风险挖掘、主观体验，不做全部 case 的全覆盖，全部 case 靠自动化。

关卡 1：研发自测准入关卡（研发提测前，前置关卡）

• 执行主体：算法、产品研发自测
• 输入：待发布 Agent 程序、Harness、Prompt 变更、模型快照
• 测试内容：P0 核心任务最小集合冒烟，验证基本可跑通；做基础高危动作快速扫测。
• 通过标准：P0 小集合冒烟全部可执行，无复现高危 bug；如果冒烟直接大面积失败，拒绝进入正式 QA 测评，退回研发。
• 产出：提测单，附带变更说明，本次版本改动点。

关卡 2：QA 冒烟测试（正式测评第一道闸门）

• 执行主体：质量评测团队（我们评测架构小组）
• 测评集：P0 精简冒烟集（20‑40 条最高频核心任务，从完整 Bench 中抽取）
• 测试内容：在标准沙箱环境执行，跑核心 P0 任务；自动化程序校验产物正确性；快速确认本次版本没有主链路雪崩式退化。
• ✅通过标准（硬性）：冒烟集 P0 任务成功率达到正式版本硬阈值；一旦出现可复现高危误触发，直接阻断提测。
• 不通过动作：打回研发，不进入全量大规模评测。

关卡 3：全量 Bench 自动化客观评测【最重要核心闸门，WorkBuddy‑Bench】

• 执行主体：评测平台自动调度，WorkBuddy‑Bench 沙箱集群执行
• 测评集：完整 Bench 评测集（我们内部 260 条业务任务，区分 P0/P1/P2/P3；包含功能任务集、高危风险专项集、知识事实专项集）
• 测试内容：
   
  1）自动化沙箱执行全部任务；优先使用确定性程序校验（编译、diff、文件校验），尽可能减少 LLM‑as‑Judge 作为主判定；
   
  2）产出完整版本评测报告：硬性指标、半硬性指标、全部观察参考指标；对比上一个基线版本，标注指标上涨、下跌；识别退化 case；
   
  3）风险专项集：专门跑高危动作诱导 case，检测是否新增高危误触发。
• ✅通过标准：
   
  1）全部硬性一票否决指标全部达标（P0 任务成功率、高危误触发 0、工具调用正确率、长流程漂移率、合规红线）；
   
  2）半硬性风险指标如果出现恶化，不能直接拒绝版本，但必须输出正式风险评估报告，明确风险影响范围、触发概率、缓解手段，作为下一关卡人工评审输入；
   
  3）参考观察指标只做记录，不做拦截。
• 不通过动作：硬性指标不达标 → 直接阻断版本；研发定位退化 case，修复后重新从冒烟开始跑整套流程。

补充：这里会做多框架交叉验证机制；同一个任务集，可同时跑上一版 Agent、竞品 Agent，做横向对照，区分是本次版本引入的退化，还是任务本身天然抖动。

关卡 4：人工专项对抗评测（不是全量 case 重测，聚焦风险 + 主观体验 + 自动化盲区）

❗关键点：不会人工把 260 条 Bench 全部手跑一遍，成本不可接受；人工评测重点瞄准自动化的盲区：自动化难以识别的隐性体验缺陷、对抗诱导 case、复杂多轮真实用户场景、主观体验判断。

• 执行主体：专职 AI 评测测试专家、业务产品，部分场景引入真实业务用户参与体验评审。
• 测评集构成（三类）
   
  1）自动化 Bench 跑出来的失败 case、边缘抖动 case，人工复现区分：是产品 bug / 环境问题 / Agent 随机幻觉；
   
  2）人工构造对抗诱导测试集：诱导 Agent 越权、做高危动作、诱导编造事实；
   
  3）精选线上真实脱敏用户会话样本（P0/P1 高频真实复杂多轮任务）；
• 测试内容：
   
  ①风险对抗挖掘；②主观体验（自然度、交互感受）；③自动化校验覆盖不到的隐性业务逻辑缺陷。
• ✅通过标准
   
  1）没有人工复现出来新增高危、合规类缺陷；
   
  2）主观体验没有出现 “大面积明显恶化”；
   
  3）所有自动化标记的高风险失败 case 完成根因分析，给出处置方案（修复 / 灰度规避 / 已知问题登记）。

⚠️本关卡主观打分不设置硬性数字门槛；如果体验变差，但硬性指标全部合格，不阻断上线，记录为已知问题，排入下迭代优化，进入灰度观察。

• 不通过动作：发现可复现高危 / 合规缺陷，直接阻断发布；普通体验差，不阻断，但风险报告必须写明。

关卡 5：线上灰度 A/B 测试（小流量真实环境验证）

沙箱 Bench 是离线模拟；Claw 类 Agent 沙箱和真实线上用户环境仍然存在 gap；所以必须灰度。

• 执行主体：产品、质量、算法、线上运维。
• 流量分配：对照组（旧版本）VS 实验组（新版本）；从小比例灰度开始（比如 5% 流量），逐步放大。
• 观测内容：线上真实业务埋点指标：真实用户任务完成率、Agent 报错、高危行为拦截、用户会话流失、客诉工单、token 成本；同时和离线 Bench 指标做交叉对照，看离线指标是否和线上趋势对齐。
• ✅通过标准：
   
  1）灰度周期内，线上高危事件 0 新增；
   
  2）线上核心任务指标不劣于基线版本；
   
  3）客诉、负面工单没有异常抬升；
   
  4）如果出现指标恶化，根据严重程度：修复回滚 / 维持小流量继续观察 / 终止灰度。
• 产出灰度报告，完成评审会之后，才允许进入全量发布。

关卡 6：全量发布 & 发布后持续观测

全量上线之后不是测评结束；持续监控线上指标；一旦出现线上突发退化，具备快速回滚机制。

✨测评集的构造方法（WorkBuddy‑Bench）

我们的评测集不是网上公开数据集直接拿来，采用4 个来源混合构造，并且做脱敏、防训练集污染处理：

1. 线上真实用户会话脱敏抽取（最高价值）：从真实 WorkBuddy、CodeBuddy 线上用户会话，做脱敏，剥离隐私，抽取高频 P0/P1 真实任务；是 P0 核心集最主要来源。
2. 人工专家对抗构造：安全、高危诱导、边界异常 case，由测试专家、安全专家专门编写。
3. PRD 需求拆解生成：新功能迭代，根据 PRD 拆解新增测试任务，补充进 Bench。
4. 失败 case 回流闭环：线上客诉、版本回归失败 case，经过评审之后沉淀进入 Bench，持续迭代扩充任务集。

重要约束：所有进入 Bench 的样本，要做训练集污染检测；避免评测任务被模型训练见过，导致 Bench 分数虚高，失去评测有效性。

✨样本量：不同指标对应的测评集样本规模（内部实践）

样本量会结合业务风险、统计显著性来定；Agent 任务执行有随机性，样本太少结果抖动巨大。

1. P0 硬性核心任务成功率（全量 Bench）：P0 集合 80‑120 条独立任务样本；冒烟精简子集 20‑40 条。

   说明：Agent 存在随机抖动，P0 单条 case 会重复跑 2‑3 次，降低随机噪声；不是跑一遍就下定论。

2. 高危风险专项测评集：40‑70 条专门对抗诱导 case，重点覆盖各类高危操作诱导；安全类 case 宁可多，不能少。
3. P1 次优先级场景：100‑140 条；
4. P2/P3 低频边缘场景（观察指标）：几十条，不追求大样本；
5. 人工主观评测样本：不会全量人工；人工精选30‑50 条高价值样本（自动化失败、对抗、真实用户复杂会话）做人工评审；不会人工跑几百条。
6. 线上灰度 A/B：至少数千真实用户会话样本，获得线上统计置信。

内部踩坑：Claw 类 Agent 千万不要用很小的 10‑20 条样本就判定版本好坏，随机性很强，很容易被偶然结果误导。

Q4（自动化与人工分工）

问题：客观指标是否完全依赖自动化工具跑分？主观体验类指标（如对话自然度、上下文连贯性、情感共鸣）如何通过人工测评进行量化？人工测评员的人数和评测轮次如何设定？

回答正文

1. 客观指标是否完全依赖自动化工具跑分？

答案：不会完全依赖自动化跑分，自动化是主力，但有多重校验兜底。

1. 优先：确定性程序自动化校验（最可信）
    
   对于 Claw 任务产物，代码编译、单元测试、文件 diff、文档格式、工具入参合法性这类客观结果，完全交给 WorkBuddy‑Bench 沙箱自动化程序校验，这是硬指标的主要来源，可信度最高。
2. LLM‑as‑Judge 仅做补充，不作为唯一判决
    
   有一部分语义类产物无法写程序断言，会使用 LLM‑as‑Judge 裁判，但我们有三条约束：
   • 不把 LLM 裁判输出当做硬性上线门禁；
   • 采用多裁判交叉投票（3 个独立模型裁判），降低单裁判幻觉误判；
   • LLM 标记的失败 case，必须抽样人工复核，统计裁判本身的误报漏报率，定期校准裁判 Prompt。
3. 自动化发现异常之后，高风险 case 人工复现兜底
    
   自动化报出来的高危 case、P0 失败 case，尤其是 LLM‑Judge 判定失败的，人工抽样复现，区分是产品真实缺陷 / 测试环境问题 / Agent 随机抖动 / Judge 裁判误判。

总结：硬性上线指标，尽可能使用程序自动化；LLM‑Judge 只做辅助；自动化的高危失败，人工复现兜底，避免自动化误判把好版本打回，也防止漏掉真实 bug。

2. 主观体验类指标如何量化；评测人员规模、轮次设置

针对：对话自然流畅度、上下文连贯性、交互体验、文案可读性这类，没有办法用程序判定的主观指标。

 

我们不追求把主观指标变成 “一票否决的硬数字”，主观打分全部作为观察参考指标，不做上线门禁，只做版本对比。

1）量化方法：采用结构化打分量表 + 多维李克特 5 分制量表，而不是自由写感想。

示例：Claw 智能体主观体验 4 维打分表（每道任务 1‑5 分）

 

① 上下文连贯性：是否遗忘前文用户指令

 

② 步骤合理性：执行步骤是否简洁，有没有大量无效绕路、重复动作

 

③ 输出语言自然度：回答是否生硬、机械

 

④ 任务完成体感：作为真实用户，你是否愿意接受本次 Agent 输出结果

每条样本，评测员除打分之外，强制要求填写 1 条具体理由，不能只给分数；分数背后要有案例，方便算法定位优化点。

2）评测员选择：三类人员混合评审

• 内部专职 AI 评测测试专家（主力）；
• 业务产品经理（懂业务真实用户诉求）；
• 少量真实种子用户（内测用户，用来避免内部人员 “专家滤镜”）。

3）人数与轮次设置（内部落地规则）

• 单条待评测样本，至少 2 位评测员独立盲评，互相看不到对方打分；
• 如果 2 个人打分分差≥2 分，触发第三位仲裁评测员介入，取仲裁结果；
• 样本规模：主观评测不会全量跑 260 条 Bench；精选30‑50 条高价值样本：自动化失败 case、线上真实用户复杂会话、版本变更新增场景；
• 评测轮次：每个版本一轮主观评审；重大模型 / Prompt 重构版本，增加一轮复测。

不建议上百人大规模人肉标注，成本极高；主观评测核心是抓典型 case，而不是海量全覆盖。

补充：主观评测输出产出不是 “一个总分”，输出三样东西：①各维度平均分（版本对比）；②高频问题 top‑N 案例清单；③定性优化建议；给到算法和产品迭代使用。分数只是参考，案例才是价值核心。

---

模块三：竞品对标与行业参考借鉴（20 分钟）

Q5（竞品对标实践）

问题：贵部门是否定期对字节豆包、阿里通义千问、百度网盘 genflow 等智能体或 claw 类产品进行横向对标测评？通常在哪些核心维度上进行对标？

回答正文

1. 是否定期对标：会做定期横向对标，但分两类：例行季度对标 + 重大版本触发专项对标。

• 季度例行对标：每一个季度，选取对外公开可用的竞品版本，在 WorkBuddy‑Bench 统一任务集下，做横向测评；被测对象包含：字节豆包 Agent、阿里通义千问 Agent、百度网盘 GenFlow、OpenClaw，还有其他行业 Claw 类开源 / 商业 Agent。
• 专项触发对标：当我们自己做重大版本迭代、关键 Prompt/Harness 改造，或者竞品发布重大 Agent 新能力的时候，启动临时专项对标。

注意：对标有边界：我们拿公开可访问的产品能力来测；无法拿到竞品内部私有 Harness，只能测对外暴露的用户能力；Bench 任务集会做适配，保证各家 Agent 都可以执行同一套任务输入。

 

同时会做对照：防止 Bench 任务集对某一家模型天然偏置；会分析 “分数差异到底是模型能力，还是 Harness 工程实现差异”。

2. 横向对标核心五大维度（和我们内部测评维度对齐）
   表格

    

   对标维度	对标重点
   ① P0 核心任务完成能力（最重要）	同一套 Bench 任务，各家 P0/P1 任务成功率；区分：是模型本身能力，还是 Harness / 工具调用工程实现带来的差异
   ② 工具调用质量	工具选择正确率、入参正确性、工具幻觉编造比例、长流程任务漂移率
   ③ 风险安全能力	高危诱导场景下，误触发破坏性动作的抵御能力，风险防御水平
   ④ 内容事实质量	知识问答、文档分析任务的事实幻觉、虚构信息占比
   ⑤ 用户体验维度（观察项）	步骤冗余度、回答自然度、交互体感；人工精选样本主观打分对比

补充：我们不会拿对标分数来直接定义自己版本能不能上线；对标结果主要用于：

 

1）看清行业整体水位，识别我们自身短板；

 

2）分析竞品优秀实现，做技术借鉴；

 

3）输出给产品，用于产品 Roadmap 规划；

 

对标分数绝对不作为自家版本上线的硬性门禁，不出现 “必须超过竞品才允许发布” 的要求。

Q6（给新进入者的核心建议）

问题：相较于行业通用测评标准，贵司自研 AI 智能体、claw 类产品的测评体系的核心优势、差异化亮点是什么？对于中小公司搭建 AI 智能体和 claw 测评体系，在指标取舍、阈值设定、体系落地方面有哪些核心建议？哪些指标是必备底线，哪些可后期逐步完善？当前头部 AI 智能体、claw 类产品测评体系存在的痛点和短板是什么？未来测评体系的迭代升级方向有哪些？

回答正文

第一部分：我们 WorkBuddy‑Bench 测评体系的核心差异化优势

对比行业很多团队直接拿公开数据集、或者纯 LLM‑as‑Judge 打分的做法，我们内部体系 4 个差异化亮点：

1. 区分「Claw 类 Agent」和普通 LLM 测评，优先产物客观校验，而不是只看文本回答

    

   很多行业测评只看模型输出文本好不好；但 Claw 会操作真实文件、调用工具、修改代码。我们优先对任务最终产物做程序校验（编译、diff、文件校验），把 Agent 实际干出来的结果作为第一判定，而不是看它说自己完成了任务。这是针对 Claw 类智能体最关键的设计。
2. 完整 P0‑P3 场景分层 + 硬性 / 参考指标严格隔离，拒绝 “主观指标一刀切卡版本”

    

   把指标按照故障损害、场景优先级分为硬门禁、风险预警、观察指标；很多小团队踩坑：把主观体验、覆盖率设为硬性门槛，导致版本迭代阻塞，被模型随机抖动裹挟。我们把客观可复现的 P0 风险、任务正确性作为唯一硬闸门，体验类全部降级观察。
3. 沙箱隔离 + 防训练集污染 + 多 Harness 交叉验证，保障评测结果可信可复现

• 独立隔离沙箱，每个任务干净环境，任务之间互不污染；
• Bench 样本做训练集污染校验，避免评测集流入训练，分数虚高；
• 支持多套 Agent Harness 跑同一套 Bench；可以区分：分数差异来自模型能力，还是 Harness 工程、Prompt 差异；

行业很多公开 Bench 缺少这一层，分数容易失真。

4. 完整闭环：线上真实用户问题回流到评测集
    
   Bench 不是一次性静态数据集；线上客诉、失败会话、灰度发现的 bug，经过脱敏评审之后持续回流扩充 Bench，评测集跟着真实业务持续生长，而不是依赖网上公开静态数据集。

第二部分：中小公司搭建 Agent/Claw 测评体系的落地建议（指标取舍、阈值、落地步骤）

很多中小团队一上来就想做大而全的 Bench，直接复刻大厂 260 条任务集，很容易资源耗尽。我的建议是底线能力优先，循序渐进建设，不要追求一步到位。

✅【必备底线：第一阶段必须做，不建议直接做产品上线】

这部分是最低生存门槛，资源有限优先建设，少而精，不求数量多。

1. 指标层面（只建硬性门禁，不要一开始堆大量观察指标）
    
   必备硬性底线指标（P0 最高频核心场景）：
    
   ① P0 核心任务成功率：样本不需要几百条，优先沉淀 30‑50 条真实业务 P0 任务，全部来自你的真实用户需求，不要直接下载网上公开数据集；
    
   ② 高危行为误触发率：风险对抗集 20‑40 条，重点测试 Agent 会不会主动触发删除、越权、破坏性动作；高危误触发必须等于 0，零容忍，这是生死线；
    
   ③ 工具调用基础正确率（P0 场景）；
    
   ④ 长流程任务漂移 / 死循环异常终止率；
    
   ⑤ 合规内容红线校验。

⚠️第一阶段，不要把下面这些作为硬性门禁：

 

功能点探测覆盖率、页面访问覆盖率、主观自然度打分、P2/P3 海量边缘场景指标、全量竞品对标；全部放到二期迭代，只做观察。

2. 体系落地建议（中小团队实操）
    
   ① 优先搭建最小可运行沙箱环境，保证任务可以隔离执行，产物可以做程序校验；不要一上来重度依赖 LLM‑as‑Judge 做全部判决；能写程序校验就不用大模型裁判。
    
   ② 评测集从真实业务沉淀，而不是直接拿公开数据集；公开数据集只能做辅助参考。优先沉淀 P0，P1 少量，P2/P3 先不建设。
    
   ③ 流程最小闭环：研发自测冒烟 → 自动化 Bench（小 P0 集合） → 人工高危对抗抽样评审 → 灰度小流量上线；不要跳过灰度，不要离线 Bench 跑完直接全量发布。
    
   ④ 人工评测不用搞大规模众包；挑选少量业务专家，重点评审失败 case 和风险 case，不要追求人工全量跑所有样本。

✅【第二阶段，资源充足之后，后期逐步完善】

1. 扩充 P1 次优先级场景评测样本；
2. 引入 LLM‑as‑Judge 作为补充，配套多裁判投票，同时建立裁判误报人工复核机制；
3. 建设观察类指标库：探测覆盖率、主观体验量表、token 成本、步骤冗余度；
4. 定期做竞品横向对标；
5. 建设线上失败 case 回流评测集的闭环机制。

✅【不建议中小公司优先投入】

• 一上来构建几百条大规模全场景 Bench，人力投入巨大；
• 把主观体验指标、覆盖率做成上线硬门禁；
• 完全依赖 LLM‑Judge 裁判，没有程序校验，没有人工复核；
• 直接采购外部商用 AI 测试 SaaS，不做业务场景适配，直接拿来当上线门禁（通用 SaaS 很难贴合自家 Agent 业务 P0 场景）。

第三部分：当前头部 AI 智能体、Claw 类产品测评体系现存痛点短板

1. 测评结果的随机性、复现性差（行业第一大痛点）

    

   Claw 多轮 Agent，同一个 case 多次跑结果不一致；很难区分：版本真的能力退化，还是本次执行随机噪声。各家都在靠多次重复执行 + 统计置信缓解，但会带来巨大算力成本。
2. “评测集污染” 问题普遍存在

    

   大量公开 Bench 数据集被混入模型训练集，评测分数虚高，无法反映真实线上能力；业务私有 Bench 的防污染校验，很多团队没有配套流程。
3. LLM‑as‑Judge 裁判本身不可靠

    

   行业大量 Agent 测评把大模型裁判当做金标准；但是裁判本身会幻觉、误判，误报漏报很高；很多团队缺少裁判校准、人工复核流程。
4. 离线 Bench 与真实线上用户环境存在 Gap

    

   沙箱是模拟环境；真实用户复杂上下文、多变输入、异常外部依赖，离线很难 1:1 复刻；离线跑分很好，线上真实用户使用出现大量问题，这是普遍痛点。
5. Claw 类 Agent 缺少行业统一标准

    

   普通 LLM 有 MMLU 等基准；但是 Claw 智能体，涉及工具调用、文件操作、长流程执行，行业没有公认统一的测评基准；各家都是自建私有 Bench，Bench 之间分数无法横向对比，对标成本很高。
6. 风险类测评建设难度高

    

   Agent 高危行为（删除文件、越权访问）的对抗样本构造成本高；很难穷尽全部诱导攻击路径。

第四部分：测评体系未来迭代升级方向（我们团队的规划）

1. 降噪与统计置信体系：针对 Agent 结果随机性；对抖动 case 做多次重复执行，用统计置信度区分 “真实能力退化” 和随机噪声；对高度不稳定 case，从门禁基准集中降级为观察集，不拿波动 case 卡版本发布。
2. 评测样本自动化生成 + 自动回流闭环：从线上真实会话自动候选生成评测 case，再人工审核，降低人工写 Bench 的巨大成本；完善 bad‑case 自动回流流水线。
3. 降低对 LLM‑as‑Judge 的依赖：尽可能把语义类主观断言，转化为结构化、可程序校验的产物校验；研究多裁判交叉投票的最优策略，建立裁判的持续校准机制。
4. 缩小离线沙箱与真实线上 Gap：把线上真实用户会话，安全脱敏之后回放进沙箱做复现测试；让离线 Bench 尽可能贴近真实线上输入分布。
5. Bench 开源生态共建：我们 WorkBuddy‑Bench 把沙箱执行框架、基础任务集开源，希望推动行业共建 Claw 类 Agent 评测基准，缓解各家闭门造 Bench 的现状；业务私有敏感任务保留内部私有。
6. Agent 风险测评专项体系建设：建设专门针对工具调用、高危动作诱导的对抗评测库，完善智能体安全风险测评方法论。

---

访谈配套快速追问应答卡片（临场备用）

追问 1：你们硬性指标阈值，Beta 灰度版本和正式全量版本为什么不一样？

Beta 版本面向小范围种子用户，允许存在少量 P0 抖动，核心是尽早拿到真实反馈；一旦全量面向海量用户，就要收紧阈值，降低大规模故障风险。阈值不是固定死，是结合线上历史故障、客诉基线迭代调整，不是拍脑袋的数字。

追问 2：Agent 随机抖动很大，P0 任务跑 2 次一次成功一次失败，你们怎么处理？

我们不会单轮一次运行结果下定论。P0 硬指标 case 会重复执行 2‑3 次；同时区分：

 

1）如果大部分轮次成功，偶发失败：标记为抖动 case，移出硬性门禁，转为观察样本，重点看版本之间抖动概率是否显著恶化；

 

2）如果新版本相比基线，抖动失败概率显著统计学上涨，即使没有 100% 失败，也要触发风险评审。

 

不能简单一次失败就阻断版本发布，否则会被 Agent 随机性绑架。

追问 3：Bench 自动化已经测完，为什么还必须人工对抗评测，不能全部交给机器？

自动化只能测 “我们已经想到的已知场景”；Agent 的高危诱导、巧妙的越权攻击、非常隐蔽的体验缺陷，是自动化 case 很难全部覆盖的。人工对抗测试的核心价值是挖掘未知风险，而不是重复跑已知 case。自动化负责已知回归，人工负责未知风险挖掘，二者互补。

追问 4：中小公司没有沙箱资源，想做 Claw 测评，有什么折中方案？

优先最小化：不需要复杂完整容器集群。可以用 Docker 单机沙箱做最小环境；P0 任务数量求精不求多；优先做产物文件 diff、代码编译这类程序校验；尽量减少 LLM‑Judge 依赖；重点把高危对抗 case 人工梳理出来，做抽样测试；千万不要在没有隔离沙箱的环境下跑带文件修改、删除的 Agent 任务，有真实数据破坏风险。

 agent 评测集合：https://mp.weixin.qq.com/s/hBSIPQnsBeWwX9UZLjWYFA