Appearance
69. 任务成功率（Task Completion Rate）
难度 P1 高频 · 岗位 应用 · 频率 ★★★★☆ · 预计阅读 8 min 公司 OpenAI · Anthropic · Google 相关题 Q70 工具调用准确率 · Q71 用户满意度 · Q68 Agent 评估概述
本题阅读地图
- 面试场景还原 — 1 min
- TL;DR 速记 — 30 sec
- 图解 — 30 sec
- 详细解析 — 5 min
- 4.1 什么是任务成功率？为什么需要多维度评估
- 4.2 四维度评估体系详解
- 4.3 任务成功的判定标准
- 4.4 数据采集与评估方法
- 4.5 与其他指标的关系
- 常见踩坑与反例 — 1 min
- 面试官可能继续追问 — 1 min
面试场景还原
�面试官：你们 Agent 的效果怎么样？怎么评估的？
🙋♂️我：看任务成功率，大概 80% 左右。
👔面试官：80% 是怎么算的？只看最终结果吗？
🙋♂️我：对，就是看最终有没有完成用户的要求。
👔面试官：那如果 Agent 走了弯路，绕了很多步才完成，也算成功吗？如果长任务成功率比短任务低很多，说明什么问题？复杂任务能不能拆解看每个子任务的成功率？
🙋♂️我：这个……
👔面试官：单看「完成/没完成」太粗糙了。专业的评估要分四个维度：完整任务完成率看最终结果；层级化完成率定位失败环节；轨迹精确度看路径效率；长周期稳定性看任务长度对成功率的影响。这样才能精确定位问题。
TL;DR 速记
- 是什么：Agent 完成用户请求的核心结果指标
- 评估维度：完整率（最终是否完成）、层级化（哪个子任务失败）、轨迹精确度（路径是否最优）、长周期稳定性（长任务成功率）
- 判定标准：结果正确性 + 过程合理性 + 符合用户意图
- 数据采集：自动判定（规则/单元测试）+ 人工标注 + 用户反馈
- 与满意度关系：成功率是技术指标，满意度是业务指标，两者可能不一致
图解
图 1：任务成功率的四维评估体系
图 2：任务成功率评估流程
详细解析
什么是任务成功率？为什么需要多维度评估
任务成功率（Task Completion Rate, TCR）是 Agent 最核心的结果指标，衡量 Agent 在给定任务上的最终完成能力。
简单定义：
任务成功率 = 成功完成的任务数 / 总任务数 × 100%但只用一个数字来衡量是不够的。两个 Agent 可能都是 80% 的成功率，但一个是因为简单任务都做对，复杂任务全失败；另一个是因为所有任务都做到 80% 完成度。这两个 Agent 的能力完全不同。
为什么需要多维度评估：
- 定位问题：单看最终成功率不知道失败发生在哪个环节
- 优化方向：需要知道是规划问题、工具调用问题还是理解问题
- 工程决策：不同维度的指标指导不同的优化策略
- 产品迭代：追踪各维度指标变化，评估优化效果
四维度评估体系详解
维度 1：完整任务完成率
定义：Agent 最终是否完成了用户给定的全部目标。
判定标准：
- 硬标准：任务的所有要求都被满足（如「查询天气并发送邮件」两个动作都完成）
- 软标准：主目标达成，次要目标未完成但可接受
计算方式：
完整任务完成率 = 完全成功的任务数 / 总任务数 × 100%示例：
- 用户：「查北京天气并告诉我明天是否适合出门」
- Agent 查到天气并给出建议 → 成功
- Agent 只查到天气没给建议 → 部分成功（不计入完整完成）
维度 2：层级化任务完成率
定义：将复杂任务拆解为子任务，分别计算每个子任务的成功率。
作用：定位失败发生在哪个环节。
示例：
任务：「帮我研究 Tesla 公司并写一份分析报告」
子任务：
- 搜索 Tesla 公司基本信息：成功率 95%
- 查询财务数据：成功率 70% ← 问题在这里
- 分析竞争优势：成功率 85%
- 生成报告：成功率 90%看到财务数据查询成功率低，可以针对性优化财务数据获取能力。
维度 3：过程轨迹精确度
定义：Agent 完成任务的路径与理想路径的匹配程度。
作用：评估 Agent 的效率和智能程度。
判定标准：
- 调用工具的数量（是否绕路）
- 调用工具的合理性（是否有冗余调用）
- 决策路径的正确性（是否走了最优策略）
示例：
用户：「北京今天天气怎么样？」
理想轨迹：直接调用天气 API → 返回结果
Agent A 轨迹：
1. 搜索 "北京天气查询方法"
2. 调用天气 API
3. 再次搜索 "天气数据解读"
4. 返回结果
Agent A 虽然完成了任务，但轨迹不精确，说明规划能力有问题。维度 4：长周期稳定性
定义：任务成功率随任务复杂度（步骤数、耗时）的变化趋势。
作用：评估 Agent 的可扩展性。
现象：
任务步骤数 vs 成功率：
- 1-3 步任务：成功率 90%
- 4-6 步任务：成功率 75%
- 7-10 步任务：成功率 50%
- 10+ 步任务：成功率 30%如果长任务成功率显著下降，说明 Agent 存在：
- 上下文丢失问题
- 规划能力瓶颈
- 错误累积效应
任务成功的判定标准
任务成功不是非黑即白，需要明确的判定标准：
自动判定方式：
规则匹配：用预定义规则检查输出
pythondef check_success(output, task): return output.contains(task.required_keyword)单元测试：代码生成类任务直接跑测试
pythondef check_code_success(code, test_cases): for case in test_cases: if not run_test(code, case): return False return True结构化验证：检查输出是否符合预期格式和内容
pythondef validate_json_output(output, schema): return jsonschema.validate(output, schema)
人工判定方式：
- 人工标注：人工检查 Agent 输出，标记成功/失败
- 众包评估：用平台如 Amazon Mechanical Turk 大规模标注
- 专家评估：领域专家评估输出质量
混合判定： 先用自动判定筛选明显成功/失败的案例，边缘案例再人工审核。
数据采集与评估方法
评估数据集构建：
- 真实用户数据：从生产环境收集真实任务和 Agent 执行记录
- 测试集：构建覆盖各种场景的测试任务集
- 对抗样本：专门构造的边界情况、困难案例
评估流程：
1. 收集 Agent 执行记录（输入、轨迹、输出）
2. 应用自动判定规则
3. 人工审核边缘案例
4. 计算各维度指标
5. 分析失败案例，归类失败原因
6. 生成优化报告失败原因归类：
| 失败类型 | 示例 | 优化方向 |
|---|---|---|
| 理解错误 | 用户要 A，Agent 做了 B | 优化意图识别 |
| 规划错误 | 步骤顺序错误导致失败 | 优化规划能力 |
| 工具调用错误 | 选错工具或参数错误 | 优化工具使用 |
| 信息不足 | 工具返回信息不够 | 优化工具/增加信息源 |
| 超时/中断 | 任务太长没完成 | 优化稳定性 |
| 外部依赖失败 | 第三方 API 挂了 | 增加容错机制 |
与其他指标的关系
任务成功率 vs 工具调用准确率：
- 工具调用准确率低 → 任务成功率通常也低
- 但工具调用准确率高，任务成功率不一定高（可能规划有问题）
任务成功率 vs 用户满意度：
- 任务成功率是客观技术指标
- 用户满意度是主观业务指标
- 两者可能不一致：
- 任务成功但用户不满意（完成方式粗暴、耗时太长）
- 用户满意但任务未完全成功（用户觉得「差不多就行」）
任务成功率 vs 响应时间：
- 通常存在权衡：追求成功率可能增加思考步骤，导致延迟增加
- 需要在两者之间找平衡点
常见踩坑与反例
踩坑 1：只看最终成功率
错误做法： 只看「完成了 X% 的任务」，不分析失败原因和过程质量。
问题： 不知道失败发生在哪个环节，无法针对性优化。
正确做法： 分层级统计成功率，定位问题环节。
踩坑 2：成功标准定义不清
错误做法： 没有明确的任务成功判定标准，标注人员凭感觉判断。
问题： 不同标注人员标准不一致，指标波动大。
正确做法： 制定详细的判定规则文档，标注前培训，定期校准。
踩坑 3：用简单任务的数据掩盖复杂任务的问题
错误做法： 测试集里 80% 是简单任务，20% 是复杂任务，整体成功率 80%，但复杂任务成功率只有 30%。
问题： 指标好看但实际能力不行。
正确做法： 按任务难度分层报告成功率，长周期稳定性单独统计。
踩坑 4：忽视轨迹质量
错误做法： 只看最终是否完成，不看完成路径是否合理。
问题： Agent 可能靠「运气」或暴力尝试完成任务，成本高且不稳定。
正确做法： 同时评估轨迹精确度，追求「又好又快」而非「能完成就行」。
踩坑 5：离线指标和线上表现不一致
错误做法： 离线测试集上成功率很高，上线后用户投诉多。
问题： 测试集分布和真实用户任务分布不一致。
正确做法： 测试集要反映真实用户分布；上线后持续监控真实成功率。
面试官可能继续追问
追问 1：任务成功率低怎么排查？ 答题要点：先分层看哪个子任务失败率高 → 看失败类型（理解/规划/工具）→ 分析具体失败案例 → 针对性优化。
追问 2：怎么平衡成功率和响应时间？ 答题要点：定义成功率的下限（如必须 >95%），在此约束下优化响应时间；或者定义响应时间上限，在此约束下最大化成功率。
追问 3：人工标注成本高，怎么降低？ 答题要点：用模型自动标注 + 人工抽检；用规则自动判定明确的成功/失败案例；用主动学习，只标注模型不确定的案例。
追问 4：怎么评估开放性任务（如创意写作）的成功率？ 答题要点：开放性任务用人工评估或多维度评分（相关性、创造性、流畅性），而非二元的成功/失败判定。
面试总结
任务成功率是 Agent 最核心的评估指标，但不能只看一个数字。面试时强调：
- 多维度评估：完整率、层级化、轨迹精确度、长周期稳定性四个维度
- 明确判定标准：自动判定 + 人工审核，标准要清晰一致
- 失败分析：分层统计定位问题，归类失败原因指导优化
记住：80% 的成功率背后可能隐藏着复杂任务的高失败率。专业的评估要能把指标拆细，定位到具体问题环节。