LLM智能体能力评测：维度、方法与边界

一、评测概述

以大型语言模型（Large Language Model，以下简称LLM）为推理核心的智能体（Agent，常译作“代理”），正在成为AI应用落地的重要形态。较早的研究已经提出把LLM视为“推理引擎”，并通过思维链（Chain-of-Thought）等方式扩展其推理过程。随着工具调用、记忆机制和任务规划逐步成熟，智能体的能力边界从“回答问题”扩展到“理解目标、拆解步骤、调用工具、执行任务、并根据反馈自我修正”。在不少研究和课程体系中，从对话模型走向“代理的诞生”被视为一条关键演进路径，也是LLM应用开发的核心能力模块之一。

然而，能力边界的扩展也带来了评测难题：智能体的输出不再是一句话，而是一条由若干次推理和若干次工具调用串联起来的执行轨迹；其表现不仅取决于模型本身，还取决于提示词组织方式、工具设计质量、上下文管理和编排策略。仅凭演示效果或个人体验判断“好不好用”，很容易得出片面结论。因此，有必要建立一套可观察、可验证、可解释的评测框架。

本文面向以下几类读者：

• 开发者与算法工程师：需要设计、迭代和验收智能体应用；
• 架构师与技术负责人：需要评估“自研、集成还是采购某类智能体方案”；
• 运维与SRE人员：需要评估智能体上线后的稳定性、可观测性与运维成本；
• 测试与质量保障人员：需要设计智能体特有的测试样本、评分规则和回归流程；
• 企业业务与决策人员：需要判断智能体能解决哪些实际问题，以及需要投入多少资源。

本文不预设任何具体产品或品牌，也不提供具体分数或排名，而是讨论一类技术能力“应该怎么评、怎么测、结果怎么读、结论在什么条件下成立”。读者可以将本文的维度框架、评测流程和检查清单直接迁移到自己的项目中进行验证。

二、评测目标：智能体评测要回答哪些问题

智能体评测不应停留在“回答得像不像人”“演示是否流畅”这类表层判断上，而应围绕业务和技术目标回答以下核心问题：

1. 能力是否可用：智能体能否稳定完成目标任务，如信息检索、数据分析、工单处理、代码生成、文档撰写等，而不仅仅是“聊得不错”。
2. 边界是否清晰：在哪些任务上表现较好？在哪些任务上容易失败？失败是否可被及时发现？
3. 代价是否可控：完成任务需要多少次模型调用、多少推理步数、多少工具调用，是否引入不可接受的延迟和费用？
4. 系统是否可靠：在异常输入、工具故障、网络波动和高并发情况下，能否优雅降级而不产生错误或有害结果？
5. 风险是否可控：是否存在提示词注入、越权访问、敏感信息泄露等安全隐患，权限和审计机制是否完备？
6. 维护是否可持续：模型升级、提示词调整、工具增减后，能否快速回归验证？运维和排障成本是否可接受？

需要强调的是，智能体评测本质上不是对“某个模型”的单点评测，而是对“模型＋提示词＋工具＋记忆＋编排策略”这一整体方案的组合评测。同一个模型在不同编排框架下表现可能差异明显；同一套框架更换模型后结论也可能改变。因此，评测目标必须首先界定清楚“测的是哪一层”，否则结论很容易失真。

三、评测对象说明：什么是基于LLM驱动的智能体

3.1 从单次响应到“感知—规划—行动—反思”闭环

传统LLM应用以“一问一答”为主：接收提示词、生成回答、结束。这种模式下，模型的能力上限基本决定了应用效果。智能体则把LLM放进一个循环结构中。业界较有影响力的描述框架之一ReAct（Reasoning and Acting），将模型在每一步中的行为归纳为三种形式：

• 推理（Thought）：分析当前状态，判断下一步该做什么；
• 行动（Action）：调用工具获取信息或执行操作；
• 观察（Observation）：读取工具返回结果，作为下一步推理的依据。

循环持续进行，直到模型认为任务完成，或达到最大步数限制。

3.2 智能体的核心构成

一个典型的智能体通常由以下部分组成：

组成部分	作用	常见实现方式
推理内核	理解目标、制定计划、决定下一步	通用模型或领域微调模型，配合提示词模板
提示词与指令模板	定义角色、目标、约束、输出格式	系统提示词、任务模板、Few-shot示例
工具集	连接外部能力与数据	函数调用、检索、数据库查询、接口调用等
记忆	保存上下文与历史经验	对话历史、摘要压缩、向量检索式外部记忆
规划与调度	拆解复杂任务、分配子任务	任务分解、计划生成、子智能体协作
反思与校验	检查输出质量、纠错	自我评估、结果比对、重试策略
运行环境	执行代码、管理资源与安全	沙箱环境、容器化运行环境、权限控制

其中，工具调用能力尤为关键。如果模型无法稳定地“选对工具、填对参数、读懂返回结果”，那么无论规划写得多么完善，智能体也无法真正完成任务。这也是智能体和普通对话式应用在评测重点上的根本区别。

3.3 常见形态与评测含义

智能体在实际落地中通常呈现为以下几种形态，每种形态的评测重点各不相同：

形态	典型特征	主要风险点	评测重点
单工具型	围绕某一类工具，如检索问答	工具选择错误、答案无出处	工具调用准确率、答案忠实度
多工具型	根据任务动态选择多种工具	参数构造错误、工具链衔接失败	任务完成率、平均步数
规划型	先制定完整计划，再逐步执行	计划不合理、中途偏离目标	任务分解质量、纠错能力
多智能体协作型	多个角色分工配合	职责重叠、信息丢失、循环冲突	协作效率、冲突解决、总成本控制

四、评测维度设计：从11个维度拆解智能体能力

下面这张表给出智能体的评测维度总览。每个维度都需要“可观察的指标＋可重复的方法＋可解释的判断依据”，三者缺一不可。

评测维度	关键问题	可观察指标（示意）	验证方法
功能完整性	是否覆盖典型使用流程	功能覆盖率、必选流程通过率	按业务流程逐项走查
任务有效性	是否真正完成任务	任务成功率、一次成功率、结果正确率	分层任务集＋评分规则＋人工抽检
性能表现	是否满足时延与吞吐要求	首步响应时间、端到端耗时、并发成功率、单任务调用次数	逐级计时、阶梯加压、资源监控
稳定性	异常情况能否被正确处理	错误率、任务中断率、重试成功率、循环步数分布	异常输入测试、工具故障注入、长时运行观察
易用性	接入与调试是否顺畅	接入耗时、配置项数量、问题定位耗时、学习曲线	新人试用记录、文档走查
兼容性	能否融入现有系统	协议适配、数据格式适配、与现有流程衔接情况	集成测试、接口适配测试
安全性	是否存在可被利用的风险	攻击拦截率、越权访问次数、敏感信息泄露率、高危操作确认率	安全测试用例集、权限越权测试
可观测性	出问题能否快速定位	日志完整度、链路追踪覆盖、监控与告警有效性	注入故障验证排障时效
可维护性	变更后能否快速回归	回归耗时、变更引发的问题数、版本回滚时间	变更演练、回归测试
成本结构	投入产出是否合理	单任务成本、无效步骤占比、人力投入、迁移与运维成本	成本归集与单位任务成本测算
场景适配度	是否契合业务特征	关键指标达标情况与业务目标的匹配度	场景化验收测试

4.1 功能完整性：先验证“能不能走完流程”

功能完整性关注的是智能体是否覆盖真实业务所需的完整链路。评测时应从业务流程出发逐环节走查，至少包括以下清单：

• 目标理解是否准确（是否理解用户真正想做什么）；
• 是否正确选择工具并构造合理的调用参数；
• 工具返回异常时是否有处理逻辑；
• 中间结果是否被有效整合；
• 是否按约定格式输出结果；
• 是否需要人工确认时能否及时中止并上报。

解读要点：功能覆盖率高只说明“链路能跑通”，不等于“结果正确”。仍需结合任务有效性进一步判断。

4.2 任务有效性：智能体最核心的价值指标

任务有效性直接决定智能体能否投入使用。建议区分以下指标：

指标	含义	说明
任务完成率	在规定步数和时限内完成目标的样本比例	衡量“能不能做成”
一次成功率	无需人工干预或重试即成功的比例	衡量“稳定程度”
结果正确率	结果内容正确、数据准确、结论有依据的比例	衡量“做得对不对”
结果可用率	经人工检查后可直接使用的比例	衡量“实际产出质量”
无效步数占比	无信息增量的推理或工具调用比例	衡量“过程是否高效”

评测时需要把“完成”和“正确”分开统计。智能体可能给出看似合理、实则错误或编造的结论（即“幻觉”），如果只看完成率，很容易高估其能力。因此评分规则中应明确：

• 哪些结果算“正确”（如关键字段准确、结论有出处）；
• 哪些算“部分正确”（如步骤正确但结论偏差）；
• 哪些算“失败”（如步骤错误、数据编造、工具误用）。

4.3 性能表现：关注“端到端”而非单次响应

智能体的性能与单次模型调用不同，应重点观察：

• 首步响应时间：从接收任务到产生第一个中间结果的时间；
• 单步平均耗时：每次推理或工具调用的平均耗时，便于定位瓶颈；
• 端到端完成时间：任务从开始到产出最终结果的总时间；
• 并发成功率：在高并发下仍能正常完成任务的样本比例；
• 资源占用曲线：推理服务、工具服务和编排层的资源使用情况；
• 队列积压与超时情况：高峰期是否出现请求堆积或超时中断。

智能体通常需要多轮调用，总时延会随步数累积放大。即使每一步都很快，十几步的链路也可能产生明显的端到端延迟。因此，性能评测必须同时记录“步数”和“每步耗时”，才能找到真正的瓶颈——是模型推理慢、工具响应慢，还是编排逻辑导致无效循环。

4.4 稳定性与容错：异常是常态，必须主动制造异常

智能体的稳定性评测要主动“制造麻烦”，而不能只测顺利路径。建议覆盖以下场景：

• 工具返回空结果、错误码、格式异常或超长文本；
• 模型输出不合法的工具调用参数或格式错误；
• 网络抖动、依赖服务超时或限流；
• 智能体陷入重复循环、无法终止或超出步数上限；
• 上下文过长导致关键信息被截断；
• 并发请求下的状态串扰（如不同用户会话记忆混淆）。

可借助开源工具和社区项目中较通用的故障注入与压测思路，构造上述异常场景，而不是依赖某一家厂商的专有测试工具。稳定性的判断标准不是“不报错”，而是“出错后能否被识别、被限制、被恢复、被记录”。

4.5 安全性：智能体的攻击面远大于传统应用

智能体可以调用工具、访问数据、执行操作，风险面也相应扩大。评测至少应覆盖：

• 提示词注入：在用户输入或外部网页、文档中植入恶意指令，诱导智能体泄露系统提示词、越权操作；
• 越权访问：通过参数篡改或上下文混淆访问未授权数据；
• 敏感信息泄露：把内部信息、密钥或个人隐私带入输出或日志；
• 高危操作确认：删除数据、发送消息、执行代码等操作是否有确认机制与权限校验；
• 数据隔离：多租户或多人会话场景下，上下文与记忆是否严格隔离；
• 传输与存储安全：接口调用是否加密，敏感数据是否脱敏存储。

安全评测应结合通用安全要求（如身份认证、权限控制、最小权限原则、传输加密、日志审计、敏感信息保护），并针对智能体特点增加“工具滥用”和“指令注入”类用例。

4.6 易用性与可观测性：决定落地效率的两个软性维度

易用性评测关注：

• 接入是否需要大量定制改造；
• 配置项是否清晰、默认值是否合理；
• 文档、示例是否完整，错误提示是否可理解；
• 调试工具是否支持逐步查看推理过程、工具调用和上下文。

可观测性评测关注：

• 是否记录每次推理的输入输出、工具调用参数与返回、耗时、错误信息；
• 是否支持按任务ID进行全链路追踪；
• 是否具备指标监控、异常告警和日志检索能力；
• 是否支持从日志回放一次失败的完整执行过程。

可观测性差的系统在演示阶段可能“看起来很好”，一旦上线就会因无法定位问题而持续消耗人力。因此这一维度应尽早纳入评测。

4.7 可维护性与成本结构：长期使用的决定因素

可维护性关注模型升级、提示词调整、工具变更后的回归验证效率，以及版本管理和灰度发布能力。

成本结构需要关注：

• 算力与调用成本：推理资源、模型调用次数与上下文长度带来的消耗；
• 无效调用成本：因循环、重试、重复检索产生的额外调用；
• 人力成本：接入、调试、评测、运维、安全加固所需的人力投入；
• 迁移与集成成本：与现有系统对接的工作量；
• 长期维护成本：模型迭代、工具变更带来的持续投入。

需要说明的是，智能体的单位任务成本往往远高于单次问答，因为一个任务可能触发多次推理和多次工具调用。评测时应计算“每完成一个有效任务的平均成本”，而不是只看单次调用价格。

4.8 场景适配度：不同场景下权重不同

同一套评测维度，在不同业务场景中的权重差别很大。例如，内部辅助场景可以容忍一定的人工介入，而面向用户的实时场景则对时延和稳定性要求更高。评测前应明确场景的权重分配，再据此给出综合判断，避免用单一标准衡量所有情况。

五、评测环境与前提：先把“可比条件”固定下来

评测结论是否可信，很大程度上取决于前提条件是否一致。开始前建议明确以下内容：

项目	需要明确的内容
模型与服务	被测模型的类型与规格、调用方式、上下文长度上限、采样参数（如温度）
评测数据	任务集来源、规模、分布（简单、中等、复杂任务比例）、是否已脱敏
评测脚本	输入构造方式、调用参数、超时与重试策略
环境与资源	推理资源规格、工具服务部署方式、沙箱或容器运行环境、网络条件
并发设定	并发用户数、请求到达方式（固定速率或阶梯加压）、压测持续时间
指标口径	成功判定标准、评分规则、耗时统计口径
评分方式	自动规则评分、模型评审、人工抽检的比例与流程

这些条件应事先记录并形成评测方案文档。任何一项发生变化，都可能使前后两次评测结果不可直接比较。

需要特别提醒的是：不同模型、不同工具服务之间的对比，必须在同一套任务集、同一套评分规则、同一类资源条件下进行，否则结论没有意义。

六、评测方法：从“跑几个例子”到“可重复的评测流程”

6.1 第一步：明确评测问题

评测前应先写清楚要回答的问题，例如“该智能体在合同审核场景下能否达到可接受的任务成功率”。避免一开始就堆砌指标。指标过多而无法指导决策，是评测常见的浪费。

6.2 第二步：设计测试样本

建议构建三层测试集：

测试集类型	目的	设计要点
单元级用例	验证单个环节	模型是否遵循输出格式、工具参数是否正确、上下文截断行为是否合理
端到端任务	验证完整流程	覆盖典型业务流程，包含多步推理与多工具调用
对抗与异常样本	验证鲁棒性	模糊表述、信息缺失、工具失败、注入攻击、超长输入等

任务集设计应尽量贴近真实业务分布，并包含一定比例“本来就该失败”的样本，用于检验智能体是否会正确放弃或上报，而不是强行编造答案。

6.3 第三步：建立基线

在引入优化前，先用当前版本完成一轮完整评测，记录各维度的基准表现，包括任务成功率、平均步数、平均耗时、错误类型分布等。后续任何提示词调整、模型替换或工具增减，都与基线对比，才能判断改动是否真的带来提升，还是只是在不同任务上“此消彼长”。

6.4 第四步：分维度验证与控制变量

按照维度分别验证，避免把多个变量混在一起。每次调整只改变一个因素（如仅修改提示词、仅更换模型），保持评测集、评分规则、资源条件一致。

6.5 第五步：记录过程数据

建议以结构化方式记录每一次执行的完整信息，包括任务ID、模型版本、提示词版本、工具调用序列、每一步的输入输出与耗时、错误信息、最终评分与人工复核意见。这些数据既是评测依据，也是后续优化与回归的基础。

6.6 第六步：结构化评分

对于开放式输出，可采用“规则校验＋模型评审＋人工抽检”的组合方式：

• 规则校验适用于有确定答案或明确约束的任务；
• 模型评审适用于主观性较强的任务，但需注意评审模型自身的偏差；
• 人工抽检用于校准前两者的可靠性，并发现规则未覆盖的问题。

6.7 第七步：分析结果边界并形成改进建议

评测的价值不止于“打分”，而在于指出下一步优化方向。例如，若失败集中在工具参数构造，说明工具描述或调用提示需要优化；若失败集中在多步任务的中途，说明规划与纠错策略不足；若时延主要来自等待，则应检查串行调用能否改为并行。

6.8 示意性评测框架（伪代码，仅作结构参考）

# 说明：以下为通用评测流程示意，不依赖任何特定产品或工具
CASES = load_cases("agent_eval_set")        # 任务集：输入、期望约束、评分规则
AGENT = load_agent("agent_under_test")      # 被测智能体（版本信息需记录）
def evaluate(case, agent, max_steps=20, timeout=120, repeat=3):
    """对单个任务重复执行 repeat 次，降低随机性影响"""
    runs = []
    for i in range(repeat):
        try:
            trace = agent.run(case.input,
                              max_steps=max_steps,
                              timeout=timeout)
        except Exception as e:                 # 异常也要记录，视为失败样本
            trace = {"error": str(e), "steps": []}
        score = judge(case, trace)             # 规则校验 / 模型评审 / 人工复核
        runs.append({
            "case_id": case.id,
            "run_index": i,
            "success": score.passed,
            "step_count": len(trace.get("steps", [])),
            "latency": trace.get("latency"),
            "error": trace.get("error"),
            "score_detail": score.detail
        })
    return runs
def summarize(all_runs):
    """按维度汇总，输出结构性报告而不是单一分数"""
    return {
        "task_success_rate": ratio_pass(all_runs),
        "first_try_success": ratio_first_pass(all_runs),
        "avg_steps": mean_step_count(all_runs),
        "avg_latency": mean_latency(all_runs),
        "error_distribution": count_errors(all_runs),
        "flaky_cases": find_unstable(all_runs)   # 多次执行结果不一致的样本
    }
results = [evaluate(case, AGENT) for case in CASES]
report  = summarize(flatten(results))

6.9 评测记录表模板

用例ID	任务描述	复杂度	期望结果	实际结果	步骤数	耗时	评分（规则/评审/人工）	错误类型	备注
T-001	查询指定周期数据并生成摘要	低	数据准确、结论有出处	数据准确，结论有少量推测	4	中等	部分正确	无	需补充出处约束
T-002	跨系统核对并输出差异清单	高	差异清单完整、字段一致	工具超时后中断	6	长	失败	依赖超时	建议增加降级策略

七、结果解读：数字背后说明什么

7.1 什么结果代表能力较强

• 在高难度任务子集上仍保持较高的任务成功率，而不是只靠简单任务拉高平均分；
• 一次成功率与任务成功率差距不大，说明行为稳定、少走弯路；
• 多轮重复执行的结果一致性较高，说明随机性影响可控；
• 无效步数与平均步数较低，说明规划与工具选择效率较高；
• 失败样本集中在少数可识别类型，而非广泛、随机地失败，说明边界清晰、可预期。

7.2 什么结果需要结合场景进一步判断

• 完成率高但人工复核通过率低：说明结果形式合规但内容质量不足，需加强校验环节；
• 平均时延较高但成功率很高：在离线批处理场景可接受，在实时交互场景需优化；
• 简单任务表现好、复杂任务表现差：适合做辅助性工作，不宜直接承担关键决策任务；
• 指标波动大：需增加样本量与重复次数，或检查采样参数与环境是否稳定。

7.3 差异背后的技术原因

评测结果的差异通常不是单一因素造成的，常见原因包括：

• 资源配置：算力规格、推理实例数量、并发上限不同，会直接影响时延与吞吐；
• 上下文与记忆策略：上下文窗口使用方式、摘要压缩策略不同，会影响长任务的稳定性；
• 缓存与复用：工具结果或检索结果是否缓存，会影响重复调用成本；
• 网络链路：调用链路经过的环节越多，抖动与超时的概率越高；
• 并发模型：串行与并行调用、异步与同步执行，会显著改变端到端时间；
• 依赖组件差异：检索服务、数据库、外部接口的稳定性差异会传导到智能体层面；
• 编排策略：是否设置反思、重试、终止条件，直接影响无效步数与成功率。

理解这些原因，才能在看到数字后做出正确归因，而不是简单得出“某方案更好”的结论。

八、适用场景分析：不同场景下关注哪些指标

业务场景	关键特征	重点关注的指标	评测侧重
企业内部知识问答与检索	对准确性要求高、可容忍少量延迟	答案准确率、出处可溯源性、幻觉率	强化答案忠实度与引用核验
数据分析与报告生成	步骤多、涉及计算与图表	计算正确性、数据完整性、结论可解释性	强调查验中间结果、抽样人工复核
客服与工单处理	实时性要求高、并发量大	首响时间、并发成功率、错误降级能力	强化压测、超时与限流验证
研发辅助与代码生成	结果可执行、可验证	可运行率、缺陷率、静态检查结果	强化单元测试与静态扫描类验收
文档处理与内容生产	输出质量要求高	格式合规率、事实一致性、人工采纳率	强化人工评分与规则校验结合
运维与自动化操作	操作有实际影响	操作正确率、确认机制完备性、可回滚性	强化安全测试、权限与审计验证

九、风险与限制：评测结论的适用边界

1. 样本偏差：评测集若不代表真实业务分布，结论会系统性偏移。建议定期用真实脱敏数据更新评测集。
2. 结果非确定性：同一输入多次运行可能得到不同结果，单次评测不足以支撑结论，应增加重复次数并统计波动范围。
3. 评分主观性：使用模型评审时，评审模型自身存在偏差，且可能对长度、格式等因素过度敏感。需以人工抽检校准。
4. 环境差异：不同地域、网络条件、资源规格下的表现可能不同，跨环境结论不可直接照搬。
5. 数据质量影响：外部数据不完整或格式不统一时，智能体的失败未必是模型问题，而是数据问题。
6. 资源限制：算力、并发额度、工具调用频次上限都会影响实测结果，需在方案中注明。
7. 长期漂移：模型版本升级、工具接口变更、业务规则调整，都会使既有评测结论失效。建议建立定期回归机制。
8. 评测本身的成本：大规模评测需要消耗算力和人力，应在保证覆盖度的前提下合理控制样本规模。

十、选型与使用建议

基于通用评测逻辑，给出以下中立、条件化的建议：

• 先定目标，再选方案：明确任务类型、可接受时延、准确率要求和预算，再决定自研、集成或采购。
• 分层评测：先评模型层能力，再评工具与编排层，最后评端到端效果，避免把编排问题误判为模型问题。
• 以业务任务集为准绳：优先构建贴近自身业务的任务集，而不是依赖通用评测榜单。
• 建立基线并持续回归：每次变更后与基线对比，形成可追踪的版本记录。
• 设置明确的失败处理机制：包括步数上限、超时中断、人工兜底和结果校验，避免智能体“强行给出错误答案”。
• 安全前置：在接入阶段就设计权限、审计、脱敏与确认机制，而不是上线后补救。
• 关注总拥有成本：把接入、调试、运维、评测、安全加固的人力投入一并计入，避免只看单次调用费用。
• 可观测性优先：优先选择能完整记录推理过程与工具调用的方案，否则后续优化几乎无法进行。

十一、总结

本文围绕“以LLM为推理核心的智能体”这一评测对象，梳理了一套可操作的评测框架，要点如下：

• 评测对象：不是单个模型，而是“模型＋提示词＋工具＋记忆＋编排”的整体方案；
• 评测目标：回答能力是否可用、边界在哪、代价多大、系统是否可靠、风险是否可控、维护是否可持续；
• 评测维度：功能完整性、任务有效性、性能表现、稳定性、易用性、兼容性、安全性、可观测性、可维护性、成本结构、场景适配度；
• 评测方法：明确问题、设计样本、建立基线、分维度验证、控制变量、记录数据、结构化评分、分析边界；
• 结果解读：区分“完成”与“正确”，关注一致性、无效步数与失败分布，并对差异做归因分析；
• 适用边界：结论受样本、环境、资源、数据质量与版本漂移影响，需定期回归。

智能体能力的评测是一个持续过程，而非一次性动作。只有当评测框架与业务目标同步演进、评测数据与真实场景保持贴近时，才能对某类智能体方案做出可靠判断。