LLM工具调用与Agent规划能力评测指南

一、评测概述：评什么、给谁看

在大模型应用从“单轮问答”走向“任务执行”的过程中，LLM-Agent 系统成为主流形态。其核心链路通常是：接收用户请求 → 规划器生成解题思路与工具调用路径 → 产出格式化工具参数 → 执行工具或子 agent → 汇总结果返回。在这条链路中，规划器承担了三项高难度任务，往往是系统性能的瓶颈。

本文的评测对象即“LLM 的工具调用与规划能力”，聚焦两类典型架构方案的对比验证：

• 方案A（单模型集中式）：由一个 LLM 承担全部规划职责，通过提示工程或微调/对齐手段注入工具与子 agent 相关知识；
• 方案B（双模型解耦式）：将“理解用户意图并泛化推理”与“掌握工具细节知识”拆分到两个模型中，分别优化、协同工作。

本文希望回答的问题包括：工具调用能力应从哪些维度评测？微调注入固定知识是否真的损害泛化、如何量化？解耦式架构是否值得引入额外复杂度？不同业务场景下应如何取舍？

适合读者：Agent 应用开发者、AI 平台架构师、技术负责人，以及需要评估大模型工具调用能力的企业技术团队。

需要预先说明：评测结论不是“哪个方案更好”的绝对判断，而是“在什么条件、什么约束下，哪个方案更可能满足业务目标”的条件化判断。同一架构在工具集固定的内部系统中可能表现良好，在工具频繁变化的开放平台中却可能失效。

二、评测对象拆解：规划器为什么是瓶颈

评测之前必须理解被评测对象的工作负载。规划器在 Agent 系统中需要同时完成三类职责，且三类职责对模型能力的要求方向并不一致。

职责一：理解用户问题并生成解题思路。 这要求模型具备意图识别、任务分解与多步推理能力。用户提问往往存在模糊表述、隐含约束、复合请求等情况，模型需要将其转化为可执行的步骤序列。评测时应重点观察模型在这些非理想输入下的分解质量，而非只看理想问句的表现。

职责二：理解工具/子 agent 能力并生成调用路径。 这要求模型“知道每个工具能做什么”，并在候选集合中完成检索、匹配与编排。工具数量越多、描述越相似，误选与漏选的概率越高；涉及多工具串行、并行或条件分支时，调用路径规划的难度显著上升。

职责三：生成合法、可用的格式化参数。 这要求模型严格遵循接口 schema，包括必填字段、类型约束、枚举取值、嵌套结构等。任何格式错误都会导致调用直接失败，这是工程落地中最常见的失败点，也是“提示工程在复杂业务下难以准确解决”的典型环节。

这三项职责存在内在张力：职责一要求模型灵活、开放、能举一反三；职责二、三要求模型精确、稳定、记得住接口细节。相关研究从机制层面揭示了这种张力的来源（以下为中性转述）：

1. 有助于大模型泛化的归纳机制，会随针对特定数据的微调而弱化；
2. 对记忆型数据的拟合会损伤模型的即时推理与泛化能力；
3. 更大的模型更容易依赖记忆，从而影响泛化表现。

由此形成两难：为了让模型掌握工具细节，需要注入固定知识；但注入固定知识可能削弱模型应对用户灵活提问的泛化能力。传统“通用任务数据与工具数据按比例混合训练”的方法只能缓解而非根治。本次评测的核心，就是用可观测的指标验证上述矛盾在具体业务中是否真实存在、严重程度如何，以及解耦架构能否有效化解。

三、评测目标与维度设计

评测维度必须拆解为可观察、可验证、可解释的指标，避免停留在“效果好、使用方便”的模糊表述。建议按下表建立框架：

评测维度	关注问题	典型指标（定性）	主要验证手段
功能完整性	三项职责是否覆盖典型流程	任务分解覆盖度、调用路径完整率	典型任务集回归测试
参数准确性	产出参数是否合法可用	格式合法率、必填字段完整率	schema 校验批量检查
泛化能力	未见过的问题/工具上是否稳定	留出工具集成功率、改写问句通过率	留出集与泛化探针测试
性能表现	延迟与吞吐是否满足业务	端到端延迟、并发吞吐（定性对比）	受控压测
稳定性	异常与边界下的表现	异常输入容错率、长时运行漂移	异常注入与长稳观察
可维护性	工具增删改的适配成本	新工具接入耗时、回归影响面	版本迭代演练
成本结构	资源与人力综合成本	Token 消耗、部署份数、运维人力	成本核算模型
可观测性	问题是否可定位归因	调用链完整性、失败原因可归因率	日志与链路追踪检查

对各维度的进一步说明：

• 功能完整性：为什么重要——三项职责缺一不可，任何一环缺失都会造成端到端失败；如何验证——覆盖单工具调用、多工具串行、多工具并行、条件分支四类流程各设计样本；如何解读——覆盖度高但成功率低的方案，说明功能框架可用、精度待优化。
• 参数准确性：这是工具调用区别于普通文本生成的核心指标。应使用独立的 schema 校验器对全部产出做机器校验，而非人工抽查；需区分“格式合法”与“语义正确”两个层次，格式对但取值错误的参数危害更大且更隐蔽。
• 泛化能力（本次评测的核心维度）：必须设置“留出工具集”——这部分工具绝不参与微调数据或提示示例，仅用于评测。若模型在留出集上成功率明显下降，即为“固定知识注入损害泛化”的直接证据。改写问句（同义替换、语序调整、口语化表达）用于检验对用户灵活提问的适应力。
• 性能表现：解耦式架构通常意味着两次模型调用串联，端到端延迟上升是预期内的代价；单模型微调方案在推理侧可能更轻。应使用受控压测对比，但不编造具体数值，只记录相对变化趋势。
• 稳定性：包括异常输入（空参数、超长文本、格式错误的历史轮次）、依赖服务异常（工具超时、返回异常码）、资源紧张等情况下的容错表现，以及长时运行后的行为漂移。
• 可维护性：工具注册表发生增删改后，各方案需要做多少工作？微调方案可能需要重新训练，解耦方案可能只需更新知识模型侧的数据——这一维度的差异会随时间放大，是长期成本的主要变量。
• 成本结构：至少包含三类成本——推理资源成本（模型份数、token 消耗）、人力成本（数据标注、训练、评测运维）、失败成本（调用失败引发的重试与人工修复）。只看推理成本会系统性低估复杂方案。
• 可观测性：每一次工具调用应能还原完整的决策链路：为什么选这个工具、参数如何得出、失败发生在哪一层。可归因率低会显著抬高线上排障成本。

四、评测环境与前提

评测结论的可信度取决于前提条件的明确程度，测试前应固定以下要素：

1. 模型与资源配置：明确参与评测的模型版本、规模量级与推理资源配置，全程保持一致；微调与解耦方案的底座模型应尽量同源，以隔离架构差异之外的因素。
2. 工具注册表设计：划分为“可见工具集”（参与知识注入或提示示例）与“留出工具集”（仅用于泛化验证），两部分在工具类型、描述风格、参数复杂度上应分布一致，避免留出集本身偏难或偏易。
3. 测试问题集设计：覆盖简单单工具调用、多工具编排、参数复杂嵌套、模糊表述、隐含约束、错误前提（请求不存在的工具能力）等类型，每类保证足够样本量。
4. 基线建立：以纯提示工程方案作为 baseline，所有对比在相同上下文长度、相同工具描述文本、相同解码配置下进行，保证可比性。
5. 控制变量：同一问题集、同一工具集、同一评测脚本、同一沙箱执行环境，避免环境差异引入噪声。
6. 明确评测边界：例如仅覆盖文本类同步工具调用，不包含多模态输入与长时异步任务编排，除非业务明确需要。

若在云上搭建评测环境，可使用模型服务、容器算力、日志服务、监控告警等通用类目能力；以百度智能云为代表的云平台提供大模型精调、部署与编排等通用能力，可作为评测载体的候选之一，但仍应按上述维度独立验证，不宜默认采信。

五、评测方法与流程

建议按四个阶段执行，以下为通用流程示意（伪代码）：

# 通用评测流程示意
阶段一 基线建立：
    纯提示工程方案 → 全量测试集 → 记录各维度指标作为 baseline
阶段二 方案A评测（微调注入）：
    可见工具集 + 通用数据混合 → 微调/对齐
    在 {可见集, 留出集, 改写问句, 异常样本} 上分别评测
    记录参数合法率、路径正确率、泛化损失
阶段三 方案B评测（双模型解耦）：
    泛化模型负责理解与规划，知识模型负责工具细节与参数生成
    相同测试集评测，额外记录两模型协作链路的损耗点
阶段四 交叉分析：
    对比三组结果 → 定位瓶颈环节 → 分析失败原因分布

关键样本设计原则：

• 正向样本：每类工具至少覆盖正常调用路径，验证基础能力；
• 泛化探针样本：只出现在留出集的工具组合、全新问法、未见过的参数结构；
• 对抗样本：用户请求超出工具能力范围、参数取值明显非法、多轮对话中中途变更需求；
• 边界样本：字段缺失、类型混淆、嵌套层级加深等接近 schema 极限的情况。

结果记录清单（每个样本均应记录）：

• 任务分解是否合理（人工评审）
• 调用路径是否正确（工具选择与顺序）
• 参数格式合法率（schema 校验器）
• 参数取值正确率（沙箱执行结果比对）
• 端到端延迟与 token 消耗
• 失败原因分类（格式错误/工具误选/参数取值错/规划缺失）

六、结果解读：如何判断评测结果

结果解读必须结合技术原因与适用边界，避免单点指标优化：

1. 若方案A在可见工具集上参数合法率明显提升，但在留出工具集与改写问句上明显下降——这印证了“固定知识注入损害泛化”的矛盾真实存在，且严重程度可用两组数据的差值量化。此时应考虑解耦架构或调整混合策略。
2. 若方案B在留出集上保持与基线相当的水平，同时参数合法率接近方案A——说明解耦有效化解了矛盾；若其在可见工具集上反而不如方案A，需检查两个模型之间的知识传递链路（如中间表示设计、上下文拼接方式）是否引入了损耗。
3. 若两个方案与基线差距不大——说明当前业务的工具复杂度尚不足以触发该矛盾，可继续使用轻量方案，推迟架构升级，避免过度设计。
4. 延迟与成本的解读：解耦通常带来两次模型调用，延迟与 token 成本上升是预期代价，应与失败重试、人工修复成本合并计算总成本，再与业务收益对比，而不是孤立看待推理开销。
5. 失败原因分布比单一成功率更有价值：若失败集中在参数格式，说明瓶颈在“知识记忆”侧；若失败集中在任务分解与工具误选，说明瓶颈在“泛化推理”侧——两类瓶颈指向完全不同的优化路径。

七、适用场景分析

不同场景下应重点关注的评测指标不同：

• 工具集固定、变更低频的场景（如企业内部固定业务流程）：泛化压力较小，重点评测参数合法率、稳定性与回归影响面，方案A微调是可行选项；
• 工具集动态、开放的场景（如面向开发者的工具生态、平台型 Agent）：泛化能力是生命线，重点评测留出集表现与新工具接入成本，倾向解耦式或“解耦+工具持续注册”架构；
• 高并发、延迟敏感场景：重点压测吞吐与端到端延迟，权衡解耦带来的额外一跳；可评测“关键路径用单模型、长尾路径用解耦”的混合形态；
• 强合规与数据安全场景：重点评测权限控制、数据隔离、日志审计与敏感信息保护，任何架构调整都不能突破安全边界；
• 快速验证期业务：先用提示工程建立基线，以小规模评测决定是否引入微调或解耦，控制试错成本。

八、风险与限制

评测过程中需警惕以下偏差来源：

• 样本偏差：若测试集与训练知识同源，会系统性高估方案A的表现；务必保留真正留出的工具与问句，并定期轮换；
• 环境差异：推理资源配置、上下文长度、解码参数不同都会导致结果不可比，跨环境对比结论应格外谨慎；
• 数据质量干扰：工具描述文本的质量与一致性会显著影响所有方案，评测前应先做清洗与标准化，否则测的是“文档质量”而非“架构优劣”；
• 长期不确定性：工具持续演进、底座模型版本升级都可能改变结论，一次性评测的结论有效期有限，应周期化重跑；
• 外推边界：单一业务场景的结论不宜直接推广到其他业务，尤其是工具规模、问法分布差异较大的场景。

九、选型与使用建议

基于通用评测逻辑，给出以下中立建议：

1. 先基线、后升级：从提示工程出发，用评测暴露真实瓶颈，再决定是否引入微调或解耦，避免过早增加架构复杂度；
2. 解耦不是唯一答案：通用与工具数据的混合配比训练、工具描述的检索式动态注入等中间方案，也应纳入对比评测，按实测结果而非架构偏好做选择；
3. 把泛化探针制度化：将留出工具集测试纳入持续集成流程，防止后续迭代在不知不觉中损害泛化能力；
4. 看端到端指标：参数合法率、任务完成率、总成本、失败可归因率应一起评估，任何单点指标优化都可能是以其他维度退化为代价；
5. 建立回归机制：工具注册表每次增删改后自动重跑评测集，量化变更影响面，让架构决策有据可依。

十、总结

本文围绕 LLM 工具调用与 Agent 规划能力，拆解了规划器承担的三项职责——理解用户问题、理解工具能力、生成合法参数——及其内在矛盾：前者依赖泛化推理，后两者依赖固定知识，而相关研究表明固定知识的注入可能削弱泛化机制。针对这一矛盾，本文建立了覆盖功能完整性、参数准确性、泛化能力、性能、稳定性、可维护性、成本与可观测性的评测框架，给出了基线建立、留出集设计、样本分层、流程执行与结果解读的完整方法，并对比了单模型精调与双模型解耦两种架构的适用边界。

核心结论是条件化的：固定知识注入与泛化能力的矛盾在复杂业务中确实存在，但严重程度必须通过留出集评测量化，不能凭经验断言；解耦式架构是化解矛盾的有效候选，但以额外延迟与系统复杂度为代价，是否值得引入取决于工具集动态性、业务规模与成本约束。评测的价值不在于给出一次性的“好/坏”标签，而在于建立可持续的验证机制，支撑 Agent 系统在工具演进与模型迭代中的长期可靠运行。