自动关联目录：Agent评测：任务完成率不能代表工程收益

核心判断：客户端 Agent 的评测单位不是一次对话，而是“从冻结起点到可验证变更”的完整运行；完成率必须和错误变更、修复成本、审查成本、回滚与资源消耗一起看。

一、业务冲突

Demo 能生成代码或画面，不能说明它能稳定处理真实工程。模型、Prompt、上下文压缩、工具策略和并发调度任一变化，都可能提高表面成功率，却增加无效读取、隐藏回归、人工修复或 Client/DS 不一致。

二、实际实现

实际运行时已经积累了可用的评测事实：每轮模型请求、工具调用、副作用调用、Token、成本、压缩次数与减少量、无进展重定向、Unknown Outcome、恢复次数、持续时间和残留资源。诊断摘要采用白名单，不持久化 Prompt 和工具参数；审计器检查事件序号、Turn 生命周期、工具终态配对、预算、压缩收益和资源清理。

测试层同时覆盖工具单测、会话恢复、取消、权限、成本、上下文压缩、Agent UI、生成资产、预览和桌面端到端流程。这些是建立评测集的好素材。

三、值得保留

事件日志和结构化运行摘要应成为评测底座，而不是另做一套埋点。尤其要保留 Unknown Outcome、无进展重复、资源泄漏和辅助摘要成本；只统计最终回复会完全看不到这些工程损耗。

四、结构性缺陷

现有测试主要证明机制能运行，尚未形成版本化的代表任务集。有些端到端用例在账号、模型或服务不可用时选择跳过，会让“未执行”混入“通过”。视觉判定和模型评分适合辅助分级，但不能让同类模型单独裁决自身结果。缺少人工修复分钟数、审查修改量和首次正确率时，Token 更低也未必意味着总成本更低。

五、目标设计

每个评测样本冻结输入和确定性判据：

struct EvalCase {
    CaseId id;
    WorkspaceSnapshot start;
    TaskIntent intent;
    AllowedCapabilities tools;
    vector<DeterministicGate> gates;
    ExpectedEvidence evidence;
    RiskClass risk;
};

Score = {
    acceptedWithoutRepair,
    invalidChangeCount,
    regressionCount,
    humanRepairMinutes,
    reviewMinutes,
    latency,
    tokenAndToolCost,
    cancellationCleanliness,
    rollbackCorrectness
};

样本必须覆盖编辑器、脚本、资产、Client、DS、网络、性能和构建；模型、Prompt、工具 Schema、知识快照与运行环境都进入 Run Manifest。

六、取舍与验证

高质量任务集维护昂贵，但没有它就无法判断 Agent 升级是否真的提高生产力。截至 2026-10-14，官方 Agent 评测指南也把 Trace、Grader、Dataset 和可重复 Eval Run 分开：Trace 用于定位过程问题，Dataset 用于比较版本；NIST 的生成式 AI Profile 则强调在整个生命周期治理、测量和管理风险。Evaluate agent workflows、NIST AI RMF Generative AI Profile

门禁应区分 Passed、Failed、Not Run 和 Infrastructure Error，并报告不同风险切片。只有在高风险样本不退化、人工总投入下降、回滚和取消仍正确时，新的模型或 Agent 策略才可以成为默认。