AI Agent 任务评测框架设计

状态：🟢 已完成日期：2026-03-29 驱动问题：如何为 Claude Code 的异构任务交付物（代码/UI/文档/Skill/工作流）建立可量化、可复用的质量验收框架？方法论：技术评估框架综合法（Benchmark Survey + Rubric Engineering + 验证机制分类）

结论摘要

行业已收敛到三层验证架构：L1 确定性检查 → L2 LLM-as-Judge → L3 人工校准，所有主流案例趋同
「评结果不评路径」是 Agent 评测核心原则：不惩罚创造性有效解法，任务设计标准是两个专家独立达成一致
异构任务用「3 通用维度 + N 任务特定维度」统一：正确性/完整性/指令遵循 + 按任务类型激活特定维度
可靠性（pass^k）比能力上限（pass@k）更重要：生产环境关注「每次都能做到」
从 20-50 个真实失败案例起步，渐进减少人工比例（100% → 5%）

详细论证 → findings.md 落地模板 → 产出/评测框架模板.md

详细论证 → findings.md

方法论如何指导本次调研

Benchmark Survey（行业框架调研） 提供评测的基础范式：

现有 Agent 评测框架的维度设计思路 → 0-行业评测框架.md
评分方式（自动/LLM/人工）的适用边界 → 2-验证机制.md

Rubric Engineering（评分规则工程） 指导维度拆解：

异构任务如何统一评分维度 → 1-Rubric设计方法.md
权重分配、Pass/Fail 阈值定义方法

验证机制分类法 决定如何落地执行：

自动验证 vs LLM-as-Judge vs 人工 Checklist 的决策树 → 2-验证机制.md
三种方式的组合策略

实际案例参考 提供落地校准：

OpenAI Evals、Anthropic 评测实践、社区经验 → 3-实际案例.md

调研框架

0-行业评测框架.md     ← 行业现有框架的方法论提炼
1-Rubric设计方法.md   ← 异构任务的评分维度与权重
2-验证机制.md         ← 自动/LLM/人工三种方式的组合决策树
3-实际案例.md         ← OpenAI/Anthropic/社区的评测实践
    ↓ 三轮收敛
findings.md          ← Key Findings + 通用评测框架提炼
    ↓ 落地
产出/评测框架模板.md   ← 可直接使用的 Rubric 模板 + 决策树

关联调研

VisAgent可行性评估 — 可作为评测框架的首个试点案例

调研章节

0 行业 AI Agent 评测框架方法论提炼 ›

行业 AI Agent 评测框架方法论提炼

📍 位置：AI-Agent任务评测框架 / 框架节点 0 📌 核心发现：Agent 评测已形成从确定性到主观性的评分方式谱系，核心区别在于评「做到」而非「知道」，评「可靠性」而非「峰值能力」 📥 输入：8 个框架的深度调研（AgentBench/SWE-bench/WebArena/HumanEval/LLM-as-Judge/G-Eval/GAIA/τ-bench） 📤 流向：→ findings.md「框架设计原则」部分

核心框架方法论提炼

评分方式谱系（从确定到主观）

确定性高 ←———————————————————→ 主观性高

测试用例通过    数据库状态比较    精确匹配    LLM-as-Judge    人工评测
(SWE-bench)    (τ-bench)      (GAIA)     (G-Eval)       (Chatbot Arena)
(HumanEval)    (WebArena V2)

核心原则：能用确定性评测就不用 LLM；能用 LLM 就不用人工。WebArena Verified 明确从 LLM-as-Judge 回退到确定性评分，证实了这一原则。

Agent 评测 vs 模型评测：五个核心区别

维度	模型评测	Agent 评测
评什么	语言理解/生成 → 知道	任务完成 → 做到
步骤	单轮推理	多步骤决策链，错误累积
环境	封闭输入输出	开放动态环境
关注点	能力上限（pass@k）	可靠性下限（pass^k）
评测对象	单一模型	系统（LLM + 工具 + 规划）

关键指标设计

指标	含义	适用场景	代表框架
pass@k	k 次尝试中至少 1 次成功	探索性任务、能力上限	HumanEval/SWE-bench
pass^k	k 次尝试全部成功	生产可靠性、一致性	τ-bench
成功率	单次任务完成率	基础能力评估	AgentBench/GAIA

各框架可借鉴的设计思路

设计思路	来源	应用方式
多环境覆盖 + 细粒度错误分类	AgentBench	按任务类型分环境，追踪失败原因类别
真实任务 + fail-to-pass 验证	SWE-bench	用真实工作场景定义评测，有明确的前后对比标准
后端状态验证 > 页面表现	WebArena V2	修改型任务验证数据/文件实际状态
功能正确性 > 文本相似度	HumanEval	看「是否达到目标」而非「是否与标准答案相似」
CoT + 概率加权评分	G-Eval	LLM 评分时先推理后打分，用概率加权提高精度
简单任务需要工具链	GAIA	测试实用的端到端任务完成能力
数据库状态比较 + 规则遵守	τ-bench	将主观评判转化为客观状态验证
难度分级体系	GAIA (3级)	渐进式评测，保持区分度

近期趋势（2024-2026）

从静态到动态：LiveCodeBench 持续采集新题对抗数据污染
从 LLM-Judge 到确定性：WebArena Verified 明确放弃 LLM 裁判
从 pass@k 到 pass^k：可靠性成为核心评测维度
从单任务到全流程：DPAI Arena 评测完整开发生命周期
评测即开发方法论：评测贯穿 Agent 开发全过程，而非事后验收

1 Rubric 设计方法：异构任务的评分规则工程 ›

Rubric 设计方法：异构任务的评分规则工程

📍 位置：AI-Agent任务评测框架 / 框架节点 1 📌 核心发现：采用「通用维度（3）+ 任务特定维度」的分层 Analytic Rubric，5 分制 + 关键维度否决制，AHP 确定初始权重后用数据迭代校准 📥 输入：教育评估（Analytic/Holistic/Single-Point Rubric）、软件质量模型（ISO 25010/McCall）、LLM 评估实践 📤 流向：→ findings.md「Rubric 设计」部分 + 产出/评测框架模板.md

1. Rubric 类型选择

结论：Analytic Rubric 是基础范式。

场景	推荐类型	原因
迭代开发中的评测	Analytic	需要定位具体失败维度以指导改进
快速 A/B 测试	Holistic	仅需判断「哪个更好」
回归测试	Binary (Pass/Fail)	仅需确认功能未退化

Analytic Rubric 的优势：诊断性反馈、支持加权、评分一致性高、适合多评估者场景。

2. 维度设计：两层架构

通用维度（所有任务类型共享）

维度	定义	选取标准
正确性	输出是否满足功能要求	跨任务适用 ≥80%
完整性	是否覆盖所有需求	跨任务适用 ≥80%
指令遵循	是否遵循约束和规范	跨任务适用 ≥80%

任务特定维度（按任务类型激活）

任务类型	特定维度	来源
代码	可维护性、性能、安全性、错误处理	ISO 25010 + McCall
UI	视觉还原度、可用性、响应式、可访问性	ISO 25010 可用性 + Nielsen
文档	可读性、结构化、可操作性	技术写作标准
Skill	提示词质量、鲁棒性、可复用性	Skill 规范 + 提示词工程
工作流	可靠性、可观测性、可扩展性	ISO 25010 可靠性

维度来源映射：McCall FCM 三层分解法 → Factor = 评估维度 → Criteria = 评分锚点 → Metrics = 量化指标。

3. 权重分配

维度	代码	UI	文档	Skill	工作流
正确性	40%	25%	30%	30%	35%
完整性	25%	20%	25%	25%	25%
指令遵循	10%	15%	15%	15%	15%
任务特定合计	25%	40%	30%	30%	25%

权重迭代路径

冷启动：AHP + 专家共识 → 初始权重
数据积累：收集 100+ 评测样本 → 回归分析验证
迭代校准：回归结果微调 → 专家审核确认

4. 评分标准：5 分制锚点

分数	等级	通用锚点
5	卓越	完全满足所有要求，多方面超出预期，可作参考范例
4	熟练	满足所有核心要求，微小改进空间不影响交付
3	合格	满足大部分核心要求，1-2 维度需改进，需小幅修改
2	发展中	仅满足部分要求，存在明显缺陷，需较大修改
1	不合格	未满足核心要求，根本性问题，需重做

Pass/Fail 判定

Pass：总分 ≥ 3.0 且无任何维度 ≤ 1
Fail：总分 < 3.0 或任何关键维度（正确性/安全性）≤ 1（关键维度否决制）

部分计分

关键发现（ICER 2025「Rubric Is All You Need」）：

CRE（完整 Rubric 评估）优于 PRE（逐点评估）：Pearson 0.912 vs 更低
Question-Specific Rubric 显著优于通用 Rubric：Pearson 提升约 0.26
LLM 在完整上下文中判断部分计分更接近人类评分

5. 可量化性

代码可读性量化

直接量化：Cyclomatic Complexity ≤10 优秀、Maintainability Index ≥85 优秀、函数长度 ≤50 行
间接量化（需 LLM）：命名语义清晰度、代码组织逻辑性

UI 美观度量化

直接量化：像素差异百分比、WCAG 色彩对比度、间距一致性
间接量化（需 LLM/人工）：Nielsen 10 条启发式评估得分（每条 0-4）

LLM 评分校准

技术	效果
CoT 先推理后评分	显著提升准确性
Few-Shot 校准（1-2 个）	一致性从 65% → 77.5%
G-Eval 概率加权	分数连续化，提高区分度
多次采样 + 位置随机化	缓解位置偏差
Binary > 3-point > 5-point > 10-point	量表越粗可靠性越高

评分一致性度量

Cohen’s Kappa > 0.8 = 优秀，0.6-0.8 = 良好
ICC > 0.9 = 优秀（连续变量）
LLM Judge 与人类一致率 ~80-85%（接近人类间一致率 75-85%）

2 验证机制：自动/LLM/人工三种方式的组合决策 ›

验证机制：自动/LLM/人工三种方式的组合决策

📍 位置：AI-Agent任务评测框架 / 框架节点 2 📌 核心发现：四层漏斗（格式门禁 → 质量门禁 → LLM 审查 → 人工终审），自动 60-70%、LLM 20-25%、人工 5-15% 📥 输入：LLM-as-Judge 学术研究、CI/CD 质量门禁实践、Anthropic/OpenAI 评测指南 📤 流向：→ findings.md「验证机制」部分 + 产出/评测框架模板.md

1. 验证方式选择决策树

Q1: 该维度是否有确定性的对/错标准？
├─ 是（编译/测试/lint/格式/链接） → ✅ 自动验证
└─ 否
    Q2: 是否可用明确的评分标准描述？
    ├─ 是（代码可读性/文档完整性/回答准确性）
    │   Q3: 评判错误的后果是否严重？
    │   ├─ 否 → ✅ LLM-as-Judge（单模型）
    │   └─ 是 → ✅ LLM-as-Judge（多模型交叉）+ 人工抽样校准
    └─ 否（商业价值/品牌调性/伦理合规/创新性）
        → ✅ 人工 Checklist

2. 四层漏斗架构

Layer 0: 格式门禁    编译/类型检查/格式化         0 成本，不通过直接打回
    ↓ 通过
Layer 1: 质量门禁    测试/覆盖率/lint/安全扫描     低成本，秒级
    ↓ 通过
Layer 2: LLM 审查    可读性/架构/文档质量/需求覆盖  中成本，秒级
    ↓ 通过/灰区
Layer 3: 人工终审    商业价值/UX/品牌/合规 + 灰区    高成本，小时级

关键原则：

每一层只处理该层该做的事，不越级
越早失败越好
LLM 灰区（如 3 分/5 分）升级到人工，而非强行判定
人工收到的是经过两层过滤的高质量交付物

3. 自动验证覆盖矩阵

任务类型	可自动验证的维度	工具
代码	编译、类型检查、lint、测试、覆盖率、安全扫描、格式化	tsc/ESLint/Jest/SonarQube/Snyk
UI	视觉回归、Accessibility、性能(Lighthouse)、响应式	Percy/Applitools/axe-core/Lighthouse
文档	拼写、链接有效性、格式校验、结构完整性	cspell/markdownlint/markdown-link-check
工作流	端到端执行、输出格式(JSON Schema)、幂等性、性能	脚本化执行 + schema 校验

自动验证的边界：能覆盖二元判定和数值指标，不能覆盖「优雅」「美观」「有用」等主观维度。

4. LLM-as-Judge 方法论要点

评分范式选择

范式	鲁棒性	复杂度	适用场景
Pointwise	高（9% 翻转率）	O(n)	大批量质量评估
Pairwise	低（35% 翻转率）	O(n²)	模型选型/A-B 测试

结论：优先使用 Pointwise 评分。

Prompt 设计六原则

结构化 Rubric — 具体分级描述，不用模糊形容词
单维度单 Judge — 每个维度独立调用，不同时评多个维度
CoT 先推理后评分 — 推理必须在分数之前
Few-Shot 适度 — 1-2 个示例（覆盖高低分），不超过 3 个
二元判断优于细粒度 — Binary > 3-point > 5-point > 10-point
偏差缓解 — 位置交换、多 Judge 投票、温度控制、匿名化

已知偏差与缓解

偏差	严重度	缓解方法
位置偏差	高	随机化顺序 + 多次取平均
冗长偏差	中	Rubric 中明确简洁性标准
自我偏好	中	使用不同模型做 Judge
同意偏差	中	平衡正负样本 + 要求批判性

成本参考

单维度评分：$0.003-0.02/eval，1-5s
4 维度并行：$0.02-0.08/eval，5-20s
多 Judge 交叉（3×4）：$0.06-0.24/eval，最高质量

5. 人工不可替代的场景

维度	为什么 AI 不行
商业价值判断	需要业务上下文和战略视角
品牌一致性	需要内化品牌调性
用户体验直觉	需要真实用户视角
伦理/合规	后果严重，需要法律背景
创意原创性	AI 难以判断真正新颖
跨系统影响	需要全局架构理解

Checklist 设计原则

分层：阻断项（Must Pass）→ 关键项（Should Pass）→ 优化项（Nice to Have）
具体可判定：用可观察行为替代模糊描述
附带决策树：减少判断负担
动态裁剪：不同任务类型激活不同子集

6. 按任务类型的验证组合模板

代码任务

auto: [compile, type_check, lint, test(100%), coverage(≥70%), security_scan]
llm: [code_readability(5pt≥3), architecture_fit(binary), requirement_coverage(checklist)]
human: [security_review(高风险全量), cross_system_impact]

UI 任务

auto: [build, lint, accessibility(axe-core), lighthouse(perf≥80,a11y≥90), visual_regression]
llm: [layout_quality(screenshot+rubric), component_consistency, responsive_check]
human: [ux_flow, brand_consistency, edge_cases(空/错误/极端)]

文档任务

auto: [spell_check, link_check, format, structure_check]
llm: [accuracy(reference-based), completeness(checklist), readability(5pt), coherence]
human: [technical_accuracy(领域专家), audience_fit]

工作流任务

auto: [e2e_execution(exit=0), output_format(schema), idempotency, performance(≤timeout)]
llm: [output_quality, error_handling]
human: [business_logic, side_effects]

7. 渐进式升级路径

阶段	策略	人工比例	目的
冷启动	自动 + 全量人工	100%	建立标注数据集
引入 LLM	自动 + LLM + 50% 抽样	50%	验证 LLM 一致率
稳态	自动 + LLM + 10-20% 抽样 + 灰区升级	10-20%	持续校准
成熟	自动 + 分层 LLM + 5% 抽样	5%	成本最优

3 实际案例：行业评测实践与跨案例模式 ›

实际案例：行业评测实践与跨案例模式

📍 位置：AI-Agent任务评测框架 / 框架节点 3 📌 核心发现：10 个案例收敛到「L1 确定性 + L2 LLM-as-Judge + L3 人工校准」三层架构共识，Anthropic「评结果不评路径」是 Agent 评测核心原则 📥 输入：OpenAI Evals、Anthropic 官方指南、SWE-bench 系列、Aider/Devin/Cursor/Copilot、Promptfoo/Braintrust/LangSmith、社区实践 📤 流向：→ findings.md「案例验证」部分

关键案例发现

Anthropic Agent 评测方法论（最核心参考）

要素	内容
三层 Grader	L1 代码型（测试/匹配）→ L2 模型型（Rubric+LLM）→ L3 人工（校准）
核心原则	评结果不评路径——不惩罚创造性有效解法
任务设计标准	两个领域专家独立评判会得出相同 pass/fail 结论
关键指标	pass@k（能力上限）vs pass^k（可靠性下限）
起步建议	20-50 个真实失败案例
Eval 分类	Capability eval（低通过率起步）+ Regression eval（~100%）

OpenAI Evals

模板化设计（JSONL + YAML）降低评测门槛
确定性 Grader（match/fuzzy-match/includes）+ Model-Graded Grader 二分法
社区注册表模式可扩展覆盖面

SWE-bench 系列演化教训

变体	状态	教训
原版	饱和	静态基准终将被「做烂」
Verified	2026.2 退役	500 题精选仍不够，污染+饱和
Pro	当前事实标准	扩展到 41 仓库多语言
FeatureBench	前沿	Verified 上 74% 的模型在此仅 11%——基准远未反映真实复杂度

关键结论：基准需要生命周期管理（监控饱和度→退役→升级）。

Claude Code 社区实践

五维质量模型：正确性、完整性、简洁性、分解性、可操作性
Advisory（80%遵循）vs Deterministic（100%执行）：软约束 vs 硬约束的区分
AI 生成代码验收：人工审查 77.8%、自动测试 48.9%、安全扫描 21%

评估平台可借鉴设计

平台	可借鉴点
Promptfoo	17+ 断言类型全景（确定性 + LLM），YAML 声明式配置
Braintrust	Rubric 设计最佳实践：清晰分级 + CoT + 人工校准
LangSmith	从生产 traces 构建评估数据集的闭环

跨案例四象限分析

共识

三层评测架构（L1 确定性 → L2 LLM → L3 人工）—— 所有案例趋同
评分维度收敛：正确性（全部）、完整性（高频）、安全性（高频）、代码质量（中频）
评结果不评路径 —— Anthropic 明确提出，SWE-bench 隐含践行
从真实失败案例出发 —— 不需要数百个任务，20-50 个即可起步

矛盾

基准 vs 真实：SWE-bench 74% → FeatureBench 11%，基准分数不等于真实能力
精度 vs 可靠性：细粒度评分更丰富但一致性更低，二元判断更可靠但信息量少
自动 vs 人工：人工审查仍占 77.8%，但成本不可持续；LLM-as-Judge 已达人类间一致率水平

信号

评测感知：Claude 4.5 能识别评测环境并表现「最佳行为」——评测需要接近生产环境
生产指标 > 基准分数：PR 合并率、审查负载削减、事故率 > SWE-bench 得分
AI 代码 bug 率高 1.7x：企业开始追踪 AI 归因回归率
用户反馈闭环：GitHub thumbs-up/down 驱动持续改进

空白

多步骤工作流的整体评测（非单步聚合）
非代码 Agent 的标准化评测（研究/内容/运营 Agent）
成本-质量权衡的量化框架
Skill 任务的专项评测方法

调研发现

AI Agent 任务评测框架设计 — 调研发现

收敛自：0-行业评测框架.md、1-Rubric设计方法.md、2-验证机制.md、3-实际案例.md evidence/：行业框架调研、Rubric设计方法、验证机制调研、实际案例（共 4 份综合调研）

Key Findings

行业已收敛到三层验证架构：L1 确定性检查（测试/lint/安全）→ L2 LLM-as-Judge（Rubric 驱动）→ L3 人工校准（金标准）。所有主流案例（Anthropic/OpenAI/Promptfoo/Braintrust）趋同于此。
「评结果不评路径」是 Agent 评测的核心原则（Anthropic）：Agent 经常找到设计者未预期的有效解法，不应因路径不同而扣分。任务设计标准：两个领域专家独立评判会得出相同 pass/fail 结论。
异构任务可用「3 通用维度 + N 任务特定维度」的分层 Rubric 统一：通用维度（正确性/完整性/指令遵循）跨任务适用，任务特定维度（代码可维护性/UI 可用性/文档可读性等）按类型激活。
评测可靠性（pass^k）比能力上限（pass@k）更重要（τ-bench）：生产环境关注「每次都能做到」而非「至少一次做到」。gpt-4o pass^1 约 61% 但 pass^8 < 25%。
LLM-as-Judge 已达人类间一致率水平（~80%），但有 6 类已知偏差需缓解。Pointwise 评分比 Pairwise 更鲁棒（翻转率 9% vs 35%）。
基准分数不等于真实能力：SWE-bench Verified 上 74% 的模型在 FeatureBench 上仅 11%。基准需要生命周期管理。
从 20-50 个真实失败案例起步（Anthropic 建议），而非设计数百个人工任务。Capability eval 从低通过率起步，Regression eval 接近 100%。

共识（多源独立验证的发现）

1. 三层架构是事实标准

L3: 人工评判（校准 + 主观任务）     ← 金标准，用于校准 L2
L2: LLM-as-Judge（灵活评估）       ← Rubric 驱动，处理开放性任务
L1: 确定性检查（快速 + 可靠）      ← 测试通过、格式、安全、lint

验证来源：Anthropic 官方指南、OpenAI Evals、Promptfoo/Braintrust/LangSmith、WebArena Verified（从 LLM 回退到确定性）。

2. 评分维度已收敛

维度	出现频率	代表来源
正确性	★★★★★	所有框架和案例
完整性	★★★★☆	Anthropic/社区/Braintrust
安全性	★★★★☆	企业审查/Anthropic
指令遵循	★★★☆☆	MT-Bench/GAIA/Anthropic
代码质量	★★★☆☆	ISO 25010/Render/社区
可操作性	★★☆☆☆	Claude Code 社区/Copilot

3. 确定性优先原则

WebArena Verified 从 LLM-as-Judge 明确回退到确定性评分。评分方式谱系上，能用确定性就不用 LLM，能用 LLM 就不用人工。

矛盾（需要判断和权衡的发现）

1. 精度 vs 可靠性

5 分制提供丰富信息但一致性下降
Binary（Pass/Fail）最可靠但信息量最低
判断：日常评测用 5 分制 + CoT 提升可靠性；回归测试用 Binary；关键决策用多 Judge 交叉

2. 自动 vs 人工覆盖

人工审查仍占 77.8%（社区调查），但成本不可持续
LLM-as-Judge 已达人类间一致率水平
判断：用四层漏斗渐进减少人工比例（100% → 50% → 10-20% → 5%），而非一步到位

3. 基准评测 vs 生产指标

基准分数与真实能力差距巨大（74% → 11%）
PR 合并率、事故率等生产指标更有意义
判断：基准用于能力基线评估，生产指标用于持续监控，两者互补而非替代

信号（值得关注的新兴趋势）

1. 评测感知（Eval Awareness）

Claude 4.5 能识别评测环境并表现「最佳行为」。这意味着评测环境需要尽可能接近生产环境，或使用「暗评测」（Agent 不知道在被评测）。

2. 从 pass@k 到 pass^k

τ-bench 引入的 pass^k 正在成为可靠性评测的标杆指标。这对生产部署的 Agent 尤其重要。

3. AI 代码 bug 率高 1.7x

企业开始追踪 AI 归因回归率。AI 生成代码的安全审查不能等同于人工代码的审查标准。

4. 用户反馈闭环

GitHub Copilot 的 thumbs-up/down 反馈机制驱动持续改进，是评测系统从「一次性评测」到「持续改进」的关键设计。

空白（调研意图需要但所有来源都没覆盖的领域）

1. 非代码 Agent 的标准化评测

现有框架几乎全部聚焦代码/网页任务，对研究 Agent、内容创作 Agent、运营 Agent 的评测方法论几乎空白。我们需要为 Skill 任务、文档任务、工作流任务自主设计评测标准。

2. 多步骤工作流的整体评测

SWE-bench 是纯二元（通过/不通过），AgentBench 是单步聚合。缺少对「多步骤工作流整体质量」的评测方法——我们的工作流任务需要自主设计（端到端成功率 + 中间步骤质量 + 副作用检查）。

3. 成本-质量权衡的量化框架

如何量化「多花 X 成本能提升 Y 质量」？现有方法论没有给出明确的决策框架。

4. Skill 文件的专项评测标准

作为 Claude Code 特有的产物形态，Skill 文件的评测（提示词质量、鲁棒性、可复用性）没有行业先例可循，需要从提示词工程最佳实践中推导。

行动建议：Claude Code 交付物验收框架

框架设计原则

三层架构：L1 自动门禁 → L2 LLM-as-Judge → L3 人工终审
评结果不评路径：不惩罚创造性的有效解法
分层 Rubric：3 通用维度 + 任务特定维度，Analytic Rubric，5 分制
确定性优先：能用自动验证的维度绝不用 LLM
关键维度否决制：正确性或安全性 ≤ 1 分直接 Fail
从失败案例起步：先收集 20-50 个真实失败案例
渐进减少人工：100% → 50% → 10-20% → 5%

实施路线图

阶段	动作	产出
Phase 0	设计维度/权重/锚点	Rubric 规格文档（见产出/评测框架模板.md）
Phase 1	20-50 个真实任务人工评分	标注数据集 + 初始阈值
Phase 2	用标注数据校准 LLM Judge	校准后的评分 Prompt + Cohen’s Kappa 报告
Phase 3	自动化管道 + 抽样人工审核	持续评测系统
Phase 4	回归分析优化权重 + 扩展类型	演进版 Rubric

核心维度与验证方式速查表

维度	代码	UI	文档	Skill	工作流	验证方式
正确性	★★★★★	★★★★	★★★★	★★★★	★★★★★	自动(测试) + LLM
完整性	★★★★	★★★	★★★★	★★★★	★★★★	LLM(checklist)
指令遵循	★★	★★★	★★★	★★★	★★★	LLM + 自动(规则匹配)
可维护性	★★★★	—	—	—	—	自动(静态分析) + LLM
视觉还原	—	★★★★★	—	—	—	自动(截图对比) + LLM
可用性	—	★★★★	—	—	—	LLM + 人工
可读性	—	—	★★★★	—	—	LLM
提示词质量	—	—	—	★★★★★	—	LLM
可靠性	—	—	—	—	★★★★★	自动(重复执行)
安全性	★★★★	—	—	★★	★★★	自动(扫描) + 人工(高风险)

证据原始数据 (1 条) ›

行业 AI Agent 评测框架调研

/Users/eamanc/Documents/pe/jixiaxuegong/research/AI-Agent任务评测框架/evidence/行业框架调研/综合调研.md

AI Agent 任务评测框架设计

AI Agent 任务评测框架设计

结论摘要

方法论如何指导本次调研

调研框架

关联调研

调研章节

行业 AI Agent 评测框架方法论提炼

核心框架方法论提炼

评分方式谱系（从确定到主观）

Agent 评测 vs 模型评测：五个核心区别

关键指标设计

各框架可借鉴的设计思路

近期趋势（2024-2026）

Rubric 设计方法：异构任务的评分规则工程

1. Rubric 类型选择

2. 维度设计：两层架构

通用维度（所有任务类型共享）

任务特定维度（按任务类型激活）

3. 权重分配

推荐起点值（AHP 初始化）

权重迭代路径

4. 评分标准：5 分制锚点

Pass/Fail 判定

部分计分

5. 可量化性

代码可读性量化

UI 美观度量化

LLM 评分校准

评分一致性度量

验证机制：自动/LLM/人工三种方式的组合决策

1. 验证方式选择决策树

2. 四层漏斗架构

3. 自动验证覆盖矩阵

4. LLM-as-Judge 方法论要点

评分范式选择

Prompt 设计六原则

已知偏差与缓解

成本参考

5. 人工不可替代的场景

Checklist 设计原则

6. 按任务类型的验证组合模板

代码任务

UI 任务

文档任务

工作流任务

7. 渐进式升级路径

实际案例：行业评测实践与跨案例模式

关键案例发现

Anthropic Agent 评测方法论（最核心参考）

OpenAI Evals

SWE-bench 系列演化教训

Claude Code 社区实践

评估平台可借鉴设计

跨案例四象限分析

共识

矛盾

信号

空白

调研发现

AI Agent 任务评测框架设计 — 调研发现

Key Findings

共识（多源独立验证的发现）

1. 三层架构是事实标准

2. 评分维度已收敛

3. 确定性优先原则

矛盾（需要判断和权衡的发现）

1. 精度 vs 可靠性

2. 自动 vs 人工覆盖

3. 基准评测 vs 生产指标

信号（值得关注的新兴趋势）

1. 评测感知（Eval Awareness）

2. 从 pass@k 到 pass^k

3. AI 代码 bug 率高 1.7x

4. 用户反馈闭环

空白（调研意图需要但所有来源都没覆盖的领域）

1. 非代码 Agent 的标准化评测

2. 多步骤工作流的整体评测

3. 成本-质量权衡的量化框架

4. Skill 文件的专项评测标准