版本：v1.0
日期：2026-06-30
主题：AI-Agent 局限性、评价指标与典型 Benchmark 体系
适用对象：AI-Agent 技术学习、课程报告、研发方案评审、Agent 产品评测设计

---

摘要

AI-Agent 通常指以大语言模型（LLM）为核心，结合规划（Planning）、记忆（Memory）、工具调用（Tool Use / Function Calling）、环境交互（Environment Interaction）和反馈修正（Feedback）等能力构建的智能体系统。相比单轮问答模型，AI-Agent 更强调“能否把任务拆解、调用外部工具、与环境交互并完成目标”。

当前 AI-Agent 已经在代码修复、网页操作、办公自动化、客服、数据分析、检索增强问答等领域展现出应用潜力，但仍存在可靠性、长程规划、工具调用、环境感知、安全合规、成本效率与评测可信度等方面的明显局限。与此同时，AI-Agent 的评价也不再适合只用“答案准确率”衡量，而需要从任务完成率、工具调用正确性、轨迹过程、稳定性、安全性、成本、延迟和人类干预需求等多个维度综合评估。

本报告围绕两个问题展开：

1. 当前 AI-Agent 有哪些主要局限性？
2. 当前 AI-Agent 有哪些主流评价指标？

---

1. AI-Agent 的基本结构

一个典型 AI-Agent 可以抽象为如下闭环：

其中，大模型主要负责理解、推理、计划与生成调用指令；外部工具负责搜索、计算、数据库查询、代码执行、网页操作、文件处理等真实动作。Agent 的能力并不只取决于基础模型，也取决于工具设计、记忆机制、权限控制、执行环境、评测体系与工程编排。

---

2. 当前 AI-Agent 的主要局限性

2.1 长程任务可靠性不足

AI-Agent 在短任务中通常表现较好，但在长链路、多步骤、跨工具任务中容易出现错误积累。典型问题包括：

• 初始任务理解错误，后续步骤全部偏离；
• 计划看似合理，但中间缺少必要验证；
• 前一步工具结果被误读，导致下一步动作错误；
• 重复尝试无效路径，无法及时停止；
• 长任务中上下文膨胀，关键信息被遗忘或稀释。

AgentBench 在评测 LLM-as-Agent 时指出，长程推理、决策和指令遵循能力仍是影响 Agent 可用性的关键障碍之一。[1]

2.2 规划能力与执行能力不稳定

AI-Agent 常被要求“先规划、再执行、再反馈修正”。但当前模型的规划往往具有以下不足：

• 计划粒度不稳定，有时过粗，有时过细；
• 无法准确估计任务难度、依赖关系和执行顺序；
• 面对动态环境时，不能及时调整计划；
• 对失败原因判断不准，容易“自我解释正确”，但实际没有修复问题；
• 计划与执行脱节，计划中写了检查步骤，实际执行时跳过。

这意味着 AI-Agent 的“会写计划”不等于“会可靠执行计划”。在工程实践中，通常需要显式状态机、任务检查点、回滚机制、人工确认和外部验证器来增强可靠性。

2.3 工具调用存在错误与幻觉

Function Calling / Tool Use 是 AI-Agent 的核心能力，但也是高频故障点。常见问题包括：

问题类型	表现
工具选择错误	该查数据库却调用搜索工具，该计算却直接猜测
参数抽取错误	日期、城市、订单号、金额等字段填错
Schema 不合规	输出 JSON 格式错误、字段缺失、枚举值非法
过度调用	简单问题也调用工具，增加延迟和成本
调用不足	需要实时信息或业务数据时直接编造答案
工具结果误读	工具返回失败或空结果，却被模型解释成成功
工具执行幻觉	模型声称已经调用或完成某工具，但系统层面并未执行

Tool learning 相关研究将工具使用过程概括为理解用户指令、拆解子任务、动态调整计划、选择合适工具并完成子任务，这说明工具调用不是单纯的格式生成，而是涉及任务分解、工具理解和执行反馈的综合能力。[2]

2.4 幻觉问题从“文本幻觉”扩展为“行为幻觉”

传统大模型的幻觉主要表现为生成不真实事实；AI-Agent 的幻觉更复杂，因为它可能进一步变成错误行动。例如：

• 编造检索结果；
• 虚构数据库记录；
• 声称已经发送邮件、提交表单或完成支付；
• 错误解释工具返回值；
• 在没有权限或没有执行结果的情况下，输出“已完成”。

这类问题比普通文本幻觉更危险，因为它可能影响真实业务系统。因此，Agent 系统通常需要执行日志、工具调用审计、权限隔离、结果校验和人工确认机制。

2.5 记忆机制不成熟

AI-Agent 通常会使用短期上下文、长期记忆、向量数据库、事件日志或用户画像来维持连续性。但记忆系统仍有明显局限：

• 记忆检索不准，相关信息找不到；
• 检索到过时信息，却当作当前事实；
• 多轮任务中状态更新不一致；
• 长期记忆可能引入隐私风险；
• 记忆内容与当前任务冲突时，模型缺乏稳定判断机制。

关于 LLM-Agent 记忆机制的综述指出，记忆是支撑长期复杂交互的重要组件，但其设计、评估和应用仍存在系统化不足。[3]

2.6 环境交互与 GUI Grounding 仍然困难

对于网页 Agent、桌面 Agent、移动端 Agent，多模态理解和界面操作是关键能力。当前问题包括：

• 看不准按钮、表格、弹窗、菜单层级；
• 点击位置不精确；
• 无法理解页面状态变化；
• 动态网页、验证码、权限弹窗、异步加载造成失败；
• 页面布局更新后，原有策略失效。

WebArena 构建了一个更接近真实网站的网页任务环境，其初始评测显示 GPT-4-based agent 的端到端任务成功率明显低于人类表现，说明真实网页任务远比静态问答困难。[4] OSWorld 则进一步将 Agent 放入真实桌面操作系统环境，强调开放式电脑任务需要 GUI grounding、操作知识和执行验证。[5]

2.7 安全、权限与合规风险突出

AI-Agent 不只是“说话”，还可能执行真实动作。因此安全风险更高：

• Prompt Injection：网页、邮件、文档中嵌入恶意指令，诱导 Agent 泄露信息或错误执行；
• 权限越界：调用不该调用的 API，访问不该访问的数据；
• 数据泄露：把内部数据、用户隐私或业务机密传给外部工具；
• 不可逆操作：误删文件、误发邮件、误提交订单；
• 合规缺口：缺少审批、审计、留痕、可解释依据。

因此，生产级 Agent 需要权限最小化、工具白名单、敏感操作二次确认、沙箱执行、日志审计和安全评测。

2.8 成本、延迟与工程复杂度较高

AI-Agent 通常比单轮问答更昂贵，因为它可能包含：

• 多轮模型调用；
• 多次工具调用；
• 检索、重排、代码执行、浏览器操作；
• 日志存储与轨迹分析；
• 失败重试与人工审核。

这会带来更高 token 成本、API 成本、执行延迟和系统复杂度。在实时客服、交易、运维、办公自动化场景中，延迟和成本往往与准确率同样重要。

2.9 Benchmark 与真实部署之间仍有差距

当前公开 Benchmark 很有价值，但也存在不足：

• 测试任务覆盖有限，不能代表全部真实业务；
• 任务可能被训练数据污染；
• 固定测试集可能被针对性优化；
• 最终成功率不能解释中间失败原因；
• 自动裁判可能存在偏差；
• 很少完整覆盖安全、成本、权限、组织流程和用户体验。

SWE-bench 以真实 GitHub Issue 作为软件工程评测任务，但后续研究也指出，一些任务可能存在测试不足、信息泄露或记忆化风险。[6][7] StableToolBench 也指出，真实在线 API 状态变化会造成 ToolBench 评价不稳定，因此引入缓存和虚拟 API 服务以提高可复现性。[8]

---

3. 当前 AI-Agent 的主流评价指标

AI-Agent 的评价应从“结果—过程—系统—安全”四层展开。

3.1 任务成功率（Task Success Rate）

定义： Agent 是否完成用户目标。
公式：

任务成功率 = 成功完成任务数 / 总任务数

适用场景： 网页操作、办公自动化、客服、数据处理、代码修复、工具调用任务。

优点： 简单直观，最接近业务目标。
缺点： 无法解释失败原因，也无法区分“差一点成功”和“完全失败”。

WebArena、OSWorld 等交互式 Benchmark 常使用端到端成功率或执行结果校验来衡量任务是否完成。[4][5]

3.2 答案准确率 / Exact Match / F1

定义： 最终答案是否与标准答案一致。
适用场景： 问答、检索增强问答、GAIA 类复杂问答、知识型 Agent。

常见指标包括：

• Exact Match：答案完全匹配；
• F1：用于实体、短答案或信息抽取；
• LLM-as-a-Judge：用裁判模型评估答案质量；
• Human Evaluation：人工评估正确性、完整性、可用性。

GAIA 包含需要推理、多模态、浏览和工具使用的真实问题，适合评估通用 AI Assistant 的综合任务能力。[9]

3.3 功能正确性（Functional Correctness）

定义： Agent 生成的代码、补丁、配置或操作结果是否通过测试。
适用场景： 编程 Agent、软件工程 Agent、数据处理 Agent、自动化脚本生成。

SWE-bench 要求模型根据真实 GitHub Issue 修改代码库，并通过测试判断是否解决问题。[10]

常见指标包括：

• Resolved Rate：成功解决 Issue 的比例；
• Test Pass Rate：测试通过率；
• Patch Correctness：补丁是否真正修复问题；
• Regression Rate：是否引入新错误。

3.4 工具选择准确率（Tool Selection Accuracy）

定义： Agent 是否选择了正确工具。
适用场景： Function Calling、API Agent、插件 Agent、企业工作流 Agent。

例如用户要求“查订单物流”，Agent 应调用物流查询工具，而不是直接生成猜测文本。

评价方式：

工具选择准确率 = 正确选择工具次数 / 需要调用工具的任务次数

3.5 参数正确率（Argument / Parameter Correctness）

定义： 工具调用参数是否完整、类型正确、值正确。
示例：

{
  "name": "get_weather",
  "arguments": {
    "city": "上海",
    "unit": "celsius"
  }
}

需要检查：

• 是否缺少必填参数；
• 参数类型是否符合 Schema；
• 枚举值是否合法；
• 用户意图中的实体、时间、地点、ID 是否抽取正确。

BFCL（Berkeley Function Calling Leaderboard）专门评估模型函数调用能力，覆盖串行调用、并行调用、多语言调用和有状态多步场景，并使用 AST 等方法检查函数调用结构。[11]

3.6 JSON / Schema 合规率

定义： 工具调用输出是否满足 JSON、JSON Schema 或平台协议。
常见错误：

• JSON 括号不闭合；
• 字段名拼错；
• 参数类型错误；
• 输出了自然语言解释，导致解析失败；
• 使用了工具列表中不存在的函数。

该指标通常作为 Function Calling 的基础质量门槛。即使工具选择正确，如果 Schema 不合规，系统也无法执行。

3.7 轨迹质量（Trajectory Quality）

定义： Agent 完成任务的中间步骤是否合理。
关注点：

• 是否有合理计划；
• 是否按计划执行；
• 是否能根据观察结果修正；
• 是否避免无效循环；
• 是否存在危险或多余操作；
• 是否能在失败时恢复。

Agent-as-a-Judge 认为，只看最终结果会忽略 Agent 的逐步执行过程，因此提出用 Agentic Evaluator 对任务过程进行中间反馈和评价。[12]

3.8 进度率（Progress Rate）

定义： 即使任务没有最终成功，也衡量 Agent 完成了多少中间目标。
适用场景： 多轮任务、长任务、复杂环境任务。

AgentBoard 提出 Progress Rate，用于捕捉 Agent 在多轮环境中的增量推进，而不仅仅看最终成功率。[13]

示例：

用户目标：预订符合条件的酒店
步骤：搜索城市 → 筛选日期 → 筛选价格 → 比较评分 → 提交预订
如果完成前 4 步但最后提交失败，成功率为 0，但进度率可能为 80%。

3.9 操作成功率 / Action Accuracy

定义： 每一步动作是否正确执行。
适用场景： 浏览器 Agent、桌面 Agent、机器人 Agent。

常见细分指标：

• 点击是否正确；
• 表单填写是否正确；
• 页面跳转是否符合预期；
• 文件是否正确保存；
• 命令是否正确执行；
• GUI 元素定位是否准确。

对于多模态电脑操作 Agent，OSWorld 等任务更强调执行环境中的真实操作结果。[5]

3.10 稳定性与一致性（Reliability / Consistency）

定义： 同一任务多次运行，Agent 是否稳定成功。
原因： LLM 输出具有随机性；工具环境也可能动态变化。

常见指标：

• 多次运行成功率；
• 方差 / 标准差；
• pass@k / pass^k；
• Retry 后成功率；
• 失败模式重复率。

τ-bench 提出 pass^k，用于衡量 Agent 在多次试验中的行为可靠性，并通过最终数据库状态与目标状态对比来判断任务是否完成。[14]

3.11 成本指标（Cost Metrics）

定义： 完成单个任务所消耗的资源。
常见指标：

• Token 数；
• 模型调用次数；
• 工具调用次数；
• API 费用；
• 计算资源；
• 人工审核成本；
• 单任务平均成本。

单任务成本 = 模型调用成本 + 工具调用成本 + 计算资源成本 + 人工审核成本

在企业部署中，成本指标经常决定 Agent 是否具备商业可行性。

3.12 延迟指标（Latency Metrics）

定义： Agent 从接收任务到输出结果的时间。
常见指标：

• 首 token 延迟；
• 端到端完成时间；
• 每一步平均耗时；
• 工具调用等待时间；
• P50 / P90 / P95 / P99 延迟。

不同场景对延迟容忍度不同：

场景	延迟要求
在线客服	秒级响应
后台数据分析	可接受分钟级
代码修复	可接受更长，但要高正确率
自动交易 / 运维	低延迟且高可靠

3.13 安全与合规指标

AI-Agent 的安全评价不能只看内容安全，还要看行为安全。常见指标包括：

指标	含义
Policy Violation Rate	违反安全策略的比例
Unauthorized Action Rate	未授权动作比例
Sensitive Data Leakage Rate	敏感信息泄露比例
Prompt Injection Success Rate	被提示注入攻击成功诱导的比例
Harmful Tool Call Rate	危险工具调用比例
Human Approval Compliance	是否在高风险动作前请求人工确认

安全指标在金融、医疗、法律、政务、企业内网、自动运维等场景尤其重要。

3.14 人类干预率（Human Intervention Rate）

定义： 完成任务过程中需要人工接管、确认或修复的比例。

人类干预率 = 需要人工介入的任务数 / 总任务数

该指标能直接反映 Agent 的自动化成熟度。对于生产系统，低任务成功率并不一定不可用，只要 Agent 能在关键节点正确请求人工确认；反之，如果它自信地错误执行，风险更高。

3.15 用户体验指标

面向真实用户的 Agent 还应评估：

• 用户满意度；
• 解释清晰度；
• 交互轮数；
• 澄清问题质量；
• 是否能承认不确定性；
• 是否能给出可操作建议；
• 是否符合业务语气与品牌规范。

---

4. 典型 AI-Agent Benchmark 与评价重点

Benchmark / 框架	主要评估对象	典型指标	价值	局限
AgentBench	通用 LLM Agent，多环境任务	成功率、环境任务表现	覆盖多种交互环境	与真实企业流程仍有差距
WebArena	网页操作 Agent	端到端任务成功率	更接近真实网站任务	网站环境仍是受控环境
GAIA	通用 AI Assistant	答案准确率、工具使用能力	综合推理、浏览、多模态	更偏问答，不完全覆盖真实动作风险
SWE-bench	软件工程 Agent	Issue resolved rate、测试通过率	真实 GitHub Issue	可能存在数据污染、测试不足等问题
BFCL	Function Calling	工具调用准确率、AST 合规、状态化调用	专门测函数调用能力	不能完全代表真实业务闭环
ToolBench / StableToolBench	多工具 API 调用	Pass Rate、Win Rate	强调工具规划和 API 使用	自动裁判与虚拟 API 仍有偏差
τ-bench	工具-Agent-用户交互	pass^k、数据库最终状态	强调多轮用户交互和规则遵守	主要覆盖模拟客服类场景
OSWorld	桌面 / GUI 操作 Agent	执行成功率、操作结果	更接近真实电脑操作	环境搭建和评测成本较高
AgentBoard	多轮 Agent 分析	Success Rate、Progress Rate、Grounding Accuracy	能分析中间进度	指标解释依赖任务设计
Agent-as-a-Judge	Agent 过程评价框架	轨迹评价、过程反馈	弥补只看最终结果的不足	裁判 Agent 本身也可能有偏差

---

5. 不同场景下的指标组合建议

5.1 Function Calling / 工具调用 Agent

推荐指标：

1. 工具选择准确率；
2. 参数正确率；
3. JSON / Schema 合规率；
4. 工具执行成功率；
5. 任务最终成功率；
6. 错误恢复率；
7. 平均工具调用次数；
8. 成本与延迟。

5.2 RAG Agent / 知识库 Agent

推荐指标：

1. 检索命中率；
2. 引用准确率；
3. 答案事实正确率；
4. 幻觉率；
5. 拒答准确率；
6. 上下文利用率；
7. 用户满意度；
8. 安全合规率。

5.3 Coding Agent

推荐指标：

1. Issue resolved rate；
2. 单元测试通过率；
3. 回归错误率；
4. 补丁最小性；
5. 代码风格合规；
6. 修复耗时；
7. 失败重试次数；
8. 人工 Review 通过率。

5.4 Web / GUI Agent

推荐指标：

1. 端到端任务成功率；
2. 页面元素定位准确率；
3. 操作成功率；
4. 表单填写正确率；
5. 中间进度率；
6. 异常恢复率；
7. 平均步骤数；
8. Prompt Injection 抵抗能力。

5.5 企业生产级 Agent

推荐指标：

1. 业务目标完成率；
2. SLA 达成率；
3. 人类干预率；
4. 成本 / 任务；
5. P95 / P99 延迟；
6. 权限违规率；
7. 审计可追溯率；
8. 用户满意度；
9. 版本回归测试通过率；
10. 高风险操作人工确认率。

---

6. 评价设计中的常见误区

6.1 只看最终成功率

最终成功率重要，但不足以解释 Agent 为什么失败。对于长程任务，应同时记录：

• 失败发生在哪一步；
• 是否因为工具选错；
• 是否因为参数错误；
• 是否因为环境变化；
• 是否因为模型误读观察结果；
• 是否因为安全策略拦截。

6.2 用单一 Benchmark 判断整体能力

一个 Agent 在 SWE-bench 上表现好，不代表它会网页操作；在 BFCL 上工具调用好，也不代表它能处理真实客服流程。因此应结合公开 Benchmark、内部任务集、灰度测试和线上监控。

6.3 忽略成本与延迟

很多 Agent 在实验环境中能完成任务，但需要大量模型调用和工具调用。生产部署时，成本和延迟可能使其不可用。

6.4 忽略安全与权限边界

一个能“自主完成任务”的 Agent，如果没有权限控制和人工确认机制，反而可能成为风险源。

6.5 自动裁判未校准

LLM-as-a-Judge 或 Agent-as-a-Judge 能降低人工成本，但裁判模型也可能存在偏见、误判和不稳定。因此，高风险任务应保留人工抽检和金标准样本。

---

7. 建议的综合评价框架

一个较完整的 AI-Agent 评价框架可以采用如下结构：

建议至少保留以下日志：

• 用户输入；
• 系统提示词版本；
• 可用工具列表；
• 每次模型输出；
• 每次工具调用参数；
• 工具返回结果；
• 中间观察与状态变化；
• 最终输出；
• 成功 / 失败标签；
• 人工修正记录；
• 成本与延迟数据。

---

8. 结论

当前 AI-Agent 的核心瓶颈并不是“能不能调用工具”，而是能否在真实、动态、长程、高风险环境中稳定地完成任务。其主要局限集中在：

1. 长程任务可靠性不足；
2. 规划与执行脱节；
3. 工具调用错误和行为幻觉；
4. 记忆与上下文管理不成熟；
5. GUI 与环境交互能力不足；
6. 安全、权限、隐私与合规风险高；
7. 成本和延迟较高；
8. 公开 Benchmark 与真实生产环境存在差距。

因此，AI-Agent 的评价体系必须从单一准确率走向多维度、过程化、可审计的综合评估。主流指标应覆盖：任务成功率、答案准确率、工具选择准确率、参数正确率、Schema 合规率、轨迹质量、进度率、稳定性、成本、延迟、安全合规和人类干预率。

对于研发和企业落地而言，推荐采用“公开 Benchmark + 内部任务集 + 轨迹日志 + 自动评估 + 人工抽检 + 线上监控”的组合方式，而不是依赖单一排行榜或单次演示效果。

---

参考文献

[1] Liu, X. et al. AgentBench: Evaluating LLMs as Agents. arXiv, 2023 / ICLR 2024. https://arxiv.org/abs/2308.03688
[2] Qin, Y. et al. Tool Learning with Foundation Models. arXiv, 2023. https://arxiv.org/abs/2304.08354
[3] Zhang, Z. et al. A Survey on the Memory Mechanism of Large Language Model based Agents. arXiv, 2024. https://arxiv.org/abs/2404.13501
[4] Zhou, S. et al. WebArena: A Realistic Web Environment for Building Autonomous Agents. arXiv, 2023. https://arxiv.org/abs/2307.13854
[5] Xie, T. et al. OSWorld: Benchmarking Multimodal Agents for Open-Ended Tasks in Real Computer Environments. arXiv, 2024. https://arxiv.org/abs/2404.07972
[6] Jimenez, C. E. et al. SWE-bench: Can Language Models Resolve Real-World GitHub Issues? arXiv, 2023 / ICLR 2024. https://arxiv.org/abs/2310.06770
[7] Aleithan, R. et al. SWE-Bench+: Enhanced Coding Benchmark for LLMs. arXiv, 2024. https://arxiv.org/abs/2410.06992
[8] Guo, Z. et al. StableToolBench: Towards Stable Large-Scale Benchmarking on Tool Learning of Large Language Models. arXiv, 2024. https://arxiv.org/abs/2403.07714
[9] Mialon, G. et al. GAIA: a benchmark for General AI Assistants. arXiv, 2023. https://arxiv.org/abs/2311.12983
[10] SWE-bench official site. SWE-bench Leaderboards and Dataset Overview. https://www.swebench.com/
[11] Patil, S. G. et al. The Berkeley Function Calling Leaderboard. PMLR, 2025; BFCL V4 leaderboard, 2026. https://gorilla.cs.berkeley.edu/leaderboard.html
[12] Zhuge, M. et al. Agent-as-a-Judge: Evaluate Agents with Agents. arXiv, 2024. https://arxiv.org/abs/2410.10934
[13] Ma, C. et al. AgentBoard: An Analytical Evaluation Board of Multi-turn LLM Agents. arXiv, 2024. https://arxiv.org/abs/2401.13178
[14] Yao, S. et al. τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains. arXiv, 2024. https://arxiv.org/abs/2406.12045
[15] Yehudai, A. et al. Survey on Evaluation of LLM-based Agents. arXiv, 2025. https://arxiv.org/abs/2503.16416
[16] Mohammadi, M. et al. Evaluation and Benchmarking of LLM Agents: A Survey. arXiv, 2025. https://arxiv.org/abs/2507.21504

---