我最近跟几个做AI应用的朋友聊天，发现一个挺有意思的现象。大家演示的时候都在秀模型"会调用工具"，可真上了生产环境，抱怨最多的却是"调了但不对"。这两件事差得挺远。我自己也踩过坑，看着模型辛辛苦苦输出了个JSON，参数名字写得挺像样，结果一执行就报错，或者选了个八竿子打不着的函数。所以这章我想把工具调用成功率这件事掰开揉碎聊聊，先把评测的框架搭起来，后面再谈具体模型对比。
1.1 工具调用成功率的定义与边界：单次调用、多轮调用与端到端任务成功
我一开始以为成功率就是个简单比例，调用成功次数除以总次数。后来发现这个定义太粗了，粗到没法用来做决策。单次调用的成功率好理解，模型给定一个请求，选一个工具，填好参数，返回格式合法，这次调用就算成了。这层最基础，也最容易测。但真实业务里很少只调用一次就完事，用户一句话往往要串起好几个工具，中间还得传递上下文。这时候单次成功率就有点骗人了，因为每一步都对，拼起来不一定对。
多轮调用的成功率要看依赖管理。第一步查到的订单号要传给第二步的退款接口，模型得记住这个号，还得在合适的时候传进去。我见过模型第一轮调对了，第二轮把参数忘了，直接拿用户的原始描述去填，结果自然失败。端到端任务成功就更严格了，从用户输入到最终结果可用，整条链路不能断，中间某一步失败就算整体失败。这三个层面的成功率数字经常差很多，所以我做评测的时候会分开报，不然容易被单次的高分误导。
1.2 核心评测维度：工具选择准确性、参数生成正确率、调用时机、错误恢复与结果可用性
工具选择准确性是我最看重的维度之一。模型面对十几个工具，能不能挑中那个真正解决问题的。这里有个坑，工具描述写得含糊，模型就容易选错。我测试的时候会故意放几个功能相近的工具，看模型能不能区分。参数生成正确率是另一个重灾区，模型经常编造参数名，或者把字符串填进数字字段。我一般会检查必填参数是否缺失、类型是否匹配、枚举值是否在允许范围内。
调用时机这个维度容易被忽略，但它很关键。用户说"帮我看看天气再决定穿什么"，模型应该先调天气工具再回答，而不是凭记忆瞎猜。错误恢复能力也要测，工具返回报错之后，模型是傻眼还是能换个参数重试，或者换个工具兜底。结果可用性是最贴近用户的，调用成功了但返回的数据没法用，比如查到了一堆无关信息，那也算失败。这五个维度我通常会给不同权重，看具体场景。
1.3 测试集与场景设计：单工具、多工具、嵌套调用、模糊指令与异常工具返回
测试集的设计我花了不少心思。最开始偷懒，只测单工具，结果模型分数都挺高，上了线才发现问题一堆。后来我按场景分层来建测试集。单工具场景是基础盘，看模型的基本功，函数选得对不对，参数填得准不准。多工具场景会故意设计一些需要组合调用的任务，比如先查用户信息再查订单再算折扣，看模型能不能规划出正确的调用顺序。
嵌套调用是更难的，一个工具的输出要作为另一个工具的输入，中间还要做格式转换。模糊指令场景我特意放了一些没有明确工具指向的请求，看模型是主动询问还是硬猜。异常工具返回这块，我会模拟超时、权限不足、参数校验失败这些情况，观察模型的反应。说实话，设计这些场景比跑测试还累，但不设计全，测出来的成功率就是空中楼阁。我还加了一些长尾场景，成功率普遍偏低，但恰恰能拉开模型之间的差距。
1.4 指标口径与复现实验：成功率、失败类型分布、时延与成本约束
指标口径必须写死，否则不同人跑出来的数没法比。我定义成功率的时候会明确到判定标准，比如参数类型错算不算失败，工具返回空结果算不算失败，模型多调了一次无关工具要不要扣分。这些细节不统一，对比就失去意义。除了总成功率，我还会统计失败类型分布，选错工具占多少、参数错误占多少、格式问题占多少。这个分布比单一数字有用得多，能直接指向优化方向。
时延和成本约束也得放进指标里。有些模型成功率是高，但每次调用前跑半天推理，线上根本扛不住。我会记录平均调用时延、token消耗，算一个性价比。复现实验的设计上，温度参数固定，工具列表顺序打乱多次取平均，避免偶然性。测试集版本要冻结，改了题目就重新标定基线。这套东西做下来，拿到任何一个新模型，我都能很快给出一个靠谱的判断。
1.5 对比价值：为什么主流大模型工具调用成功率实测对比需要统一基准
市面上模型太多了，各家公布的指标口径五花八门，有的只报单次调用成功率，有的拿最好的场景出来说事。用户拿着这些数字根本没法选。我见过同一个模型在两个评测里成功率差了二十个点，一看测试集不一样，一个全是简单单工具，一个塞满了多轮嵌套任务。这种对比没意义，反而添乱。统一基准的价值就在这里，大家用同一套题、同一个判定标准、同样的工具定义，跑出来的数才有可比性。
统一基准还能暴露能力画像。不光是总分，哪个维度强哪个维度弱，一目了然。有的模型选工具准但参数老出错，有的模型参数填得好但规划能力差。这些信息对选型特别有用。我自己做实测对比的时候，最怕的就是基准不统一，沟通成本极高。所以这章先把框架立起来，后面几章的具体对比才有落脚点。基准统一了，行业里讨论"哪个模型工具调用强"才不至于各说各话。
这一章我把五款模型拉到了同一张桌子上。GPT-4.1、Claude Sonnet 4、Gemini 2.5 Pro，加上开源的DeepSeek-V3和Qwen2.5-72B。同一套工具集，同一批测试题，同一个判定脚本，温度锁死0，每个场景跑三遍取平均。不是我较真，是这行水太深，口径松一点，结论就能翻个面。
2.1 对比对象与实验设置：闭源主流模型与代表性开源模型的统一评测条件
工具集我准备了20个函数，覆盖查询、计算、写入、通知四类，其中有四组功能高度相似的工具，专门用来制造选择困难。测试集分五层：单工具、多工具串行、嵌套调用、模糊指令、异常返回。每层200条，总共1000条。评分脚本会逐条检查工具名、参数键名、参数类型、枚举值，格式不合规直接判负。多轮场景额外记录上下文传递是否断裂。时延和token消耗我也全量记了，后面算性价比用得上。
五款模型里有两款是走API的闭源模型，三款是本地部署的开源模型。开源这边我用了vLLM加速，上下文长度统一拉到32K，避免因为截断导致误判。有些朋友问我为什么不用更小的开源模型，我的考虑是72B这个量级才勉强能打，再小基本是送分。实际跑下来，闭源模型在格式遵循上确实有先发优势，开源模型在特定场景能咬住，差距没有想象中那么夸张。
2.2 单工具调用对比：函数选择、参数填充与格式遵循的成功率差异
单工具这层最见基本功。Claude Sonnet 4的总成功率跑到94.2%，GPT-4.1是92.8%，两个咬得很紧。Gemini 2.5 Pro在87%左右。开源这边DeepSeek-V3拿到84.5%，Qwen2.5-72B是81.3%。数字看着都不低，拆开看差异就出来了。函数选择准确性上，GPT-4.1和Claude都在96%以上，Gemini掉到91%，问题集中在四组相似工具上，它偶尔会把"查询订单状态"和"查询物流轨迹"搞混。
参数填充是另一个分水岭。Claude的必填参数缺失率只有1.8%，GPT-4.1是2.4%。Gemini在枚举值越界上翻了三次车，比如把"priority"字段填成"urgent"而不是允许的"high"。开源模型这边参数幻觉明显多一些，DeepSeek会编造不存在的参数名，Qwen偶尔把数字填成字符串。格式遵循这块，闭源三家基本没毛病，开源模型在JSON闭合和嵌套结构上偶有闪失，重试一次大多能救回来。
2.3 多工具与多轮调用对比：任务规划、依赖管理与上下文保持能力
多工具串行调用一上强度，梯队就拉开了。我设计的一条典型链路是：查用户ID→查订单列表→筛选最近一单→计算折扣→发起退款。五步全对才算成功。GPT-4.1在这条链路上成功率78%，Claude是76%，Gemini掉到64%。开源这边DeepSeek是59%，Qwen是52%。差距主要出在依赖管理上，模型得记住第一步拿到的用户ID，还得在第三步正确引用。Gemini有几次把用户原始输入里的昵称当成了ID传进去，直接报错。
嵌套调用更难，一个工具的输出要做格式转换才能喂给下一个。我测了一个汇率换算加金额校验的嵌套任务，Claude表现最稳，成功率71%，GPT-4.1是68%。开源模型在这块普遍吃力，DeepSeek能跑到54%，Qwen只有47%。长链路跑到第四第五步的时候，开源模型容易把前面的中间结果丢掉，上下文保持能力是个硬伤。我自己的感受是，多轮场景下模型不光要聪明，还得有"记性"，这两件事经常不在一个水平线上。
2.4 异常与边界场景对比：工具报错、参数缺失、歧义指令与重试策略表现
异常场景是我最看重的部分，因为生产环境里工具报错是常态。我模拟了三类异常：超时、权限不足、参数校验失败。Claude的重试策略最成熟，遇到超时会换个参数重试一次，再不行就降级到备用工具，异常场景整体成功率62%。GPT-4.1紧随其后，58%，它的强项是能读懂报错信息里的提示，比如"缺少必填字段end_date"，它会补上再调一次。Gemini在异常场景掉到44%，有几次直接放弃调用转头跟用户道歉，其实换个参数就能成。
歧义指令这层挺有意思。我放了一条"帮我处理一下那个单子"，没有任何工具指向。Claude和GPT-4.1都会主动追问是哪个单子、要做什么操作。Gemini有两次硬猜，选了个删除订单的工具，吓我一跳。开源模型这边追问意识偏弱，DeepSeek五次里有三次直接选了第一个看起来相关的工具。参数缺失场景下，闭源模型倾向于追问，开源模型倾向于编一个默认值填进去，后者在评测里扣分很惨。
2.5 实测结论提炼：不同模型在准确率、稳定性、时延与成本上的权衡
把五个维度的分数摆在一起看，能力画像就出来了。GPT-4.1是全能型，单工具、多工具、异常恢复都在第一梯队，平均时延1.9秒，token消耗中等偏上。Claude Sonnet 4在参数准确率和重试策略上略微领先，平均时延2.2秒，稳定性最好，三遍跑的方差最小。Gemini 2.5 Pro单工具还行，多轮和异常场景明显掉队，时延倒是快，1.4秒，可成功率撑不起这个速度。
开源这边DeepSeek-V3是性价比选手，单工具84.5%，多工具59%，异常54%，时延2.6秒，token成本只有闭源的三分之一左右。Qwen2.5-72B整体低一档，参数幻觉偏多，胜在可微调，特定场景能追回来。我跑完这轮最大的感受是，没有哪个模型在所有维度上都赢，选型得看你的场景偏哪头。高频简单工具闭源开源差距不大，复杂多工具任务闭源优势明显，高风险调用场景下重试策略比单次准确率更值钱。
上一章我把五款模型的分数摆得明明白白。分数只是结果，我更关心的是那些扣分的地方到底怎么来的。这一章咱们不聊虚的，我把失败样本一条条拆开看，再聊聊怎么把成功率一点点抠上来。说实话，看着那些失败案例，我脑子里反复冒出来一句话：模型不笨，很多时候是我们没把活儿交代清楚。
3.1 失败模式拆解：选错工具、参数幻觉、格式错误、调用过晚与恢复失败
我把1000条测试里所有失败样本倒出来，人工分了类。比例最高的是选错工具，占了大概三成。这个“选错”分两种，一种是真选错了，比如Gemini把查订单状态和查物流轨迹搞混，两个工具名字就差了两个字，参数结构还长得特别像。另一种是选了个“差不多能用”的工具，结果参数填进去跑不通。这种在开源模型上更常见，DeepSeek有几次选了查询工具却传了写入操作的参数格式，一看就是理解偏了。
参数幻觉排第二，占两成半左右。这里头有个有意思的现象：越是必填参数多的工具，模型越容易自己编一个参数名填进去。Qwen在一组七个参数的工具上，平均每次调用会多编出0.8个不存在的字段。格式错误是另一大块，JSON少个括号、枚举值写成同义词、数字写成字符串，这些都算。调用过晚这个失败模式挺隐蔽的，模型其实选对了工具也填对了参数，但它把调用放在了回复的最后一句，前面洋洋洒洒说了一堆废话，结果用户没看到工具返回就以为没调用。恢复失败是最难啃的骨头，工具报错之后模型要么直接放弃，要么重试同一个错误参数三次，真正能根据报错信息调整策略的不到四成。
我把这五类失败按模型做了个交叉表，发现一个规律：闭源模型的失败集中在恢复失败和调用过晚上，开源模型的失败集中在选错工具和参数幻觉上。这俩群体的短板不在一个位置，优化方法自然也得分开下药。
3.2 提示与工具描述优化：函数命名、参数 schema、示例约束与调用规则前置
工具描述这块我踩过坑。最早我写的函数描述就一句话：“查询订单状态”。结果模型经常跟物流查询搞混。后来我把描述改成“根据订单ID查询该订单的支付状态、发货状态和退款状态，不包含物流轨迹信息”，混淆率直接降了一半。函数命名也一样，别用getStatus这种含糊的名字，用queryOrderPaymentStatus，模型一看就知道边界在哪。
参数schema的写法有讲究。枚举值必须显式列全，别写“priority字段填高优先级”，要写“priority字段允许的值为high、medium、low，不区分大小写但必须完全匹配”。我试过在schema里加一个“禁止填写不存在的字段名”的硬约束，参数幻觉率从12%掉到7%。示例约束也管用，每个工具下面挂一到两个正确调用示例，尤其要覆盖边界情况，比如参数为空时传null还是传空字符串。模型看示例比看描述学得快，这是我在实测里反复验证过的。
调用规则前置这件事被很多人忽略。我把“任何涉及写操作的工具调用前必须先获得用户确认”这条规则放在system prompt的最前面，而不是塞在中间，违规调用少了六成。规则的位置很关键，模型对开头和结尾的注意力明显高于中间段。另外我会把工具调用格式的模板放在规则后面，紧挨着示例，这样模型在生成调用时能直接抄格式，格式错误率降得很明显。
3.3 推理与执行链路优化：任务分解、调用前校验、重试回退与结果验证
多工具场景下我最大的体会是：别指望模型一口气把五步全规划对。我把复杂任务拆成两级，第一级只让模型输出一个步骤列表，不调用任何工具，第二级再逐步执行。这个改动能把多工具串行成功率拉高十个百分点左右。任务分解的粒度也有讲究，拆太细模型记不住上下文，拆太粗等于没拆，我的经验是每个子任务不超过三次工具调用。
调用前校验这步我加在工程侧，模型生成调用请求后先过一个轻量校验器，检查工具名是否存在、必填参数是否齐全、参数类型是否匹配。校验不通过就把错误信息喂回给模型让它重写。这个机制拦住了大概四成的格式错误和参数缺失。重试回退策略我分了三级：同参数重试一次、换参数重试一次、降级到备用工具。关键是重试时要带上上次失败的报错信息，模型看到“缺少end_date字段”的提示后补全参数的成功率，比盲试高得多。
结果验证这块我加了一个“验收人”角色。工具返回结果后，让模型自己判断这个结果是否回答了用户的问题，如果答非所问就重新规划。实测下来这个自检步骤能把端到端任务成功率提升八到十二个百分点。代价是每轮多花一次模型调用，时延增加大概0.4秒。我的判断是这钱花得值，尤其在高风险场景里，宁可慢一点也别交出一个错的结果。
3.4 模型侧优化：微调、路由与多模型协同提升特定场景成功率
微调这件事得看场景。我拿Qwen2.5-72B做了一组对比实验，用500条工具调用样本做LoRA微调，单工具场景成功率从81%提到88%，参数幻觉率降了将近一半。但多工具场景提升有限，只涨了三个点。微调能把模型不熟悉的工具格式和参数习惯“腌”进去，可它治不了推理链路上的规划短板。我的建议是高频固定工具集优先考虑微调，工具经常变的场景靠微调不划算。
路由策略是我最近在试的方向。我训了一个轻量分类器，先判断用户请求的复杂度，简单单工具请求走DeepSeek或者Qwen，复杂多工具请求路由给Claude或GPT-4.1。这套路由跑下来整体成功率跟全量走Claude差不多，成本降了四成。路由的判定特征不用太复杂，请求长度、工具数量、有没有嵌套依赖这几个信号就够用了。
多模型协同我试过两种模式。串行模式是一个模型规划、另一个模型执行，效果一般，上下文传递容易丢信息。并行模式是两个模型同时生成调用方案，然后投票选一个，成功率能涨五到七个点，但成本翻倍。我现在更倾向“主模型规划加子模型执行”的分层模式，规划模型只输出步骤和工具名，执行模型负责填参数和调工具，两边各干各擅长的事。这个模式在多工具场景下比单模型高十一个百分点，时延只多了0.8秒。
3.5 工程侧优化：可观测性、失败样本回流、评测闭环与灰度发布
工程侧的事看着不性感，但它是把成功率从80分推到90分的关键。我在调用链路上埋了全链路日志，每次调用记录六件事：模型输出原文、工具名、参数、返回结果、耗时、是否重试。这套日志跑一周就能攒出几百条失败样本。关键是别把日志堆在那不看，我每周固定抽一个小时翻失败案例，翻着翻着就能发现规律，比如某个工具的描述有歧义、某个参数模型总是填错类型。
失败样本回流闭环我建了个简单流程：线上失败样本自动进标注队列，人工确认后补进评测集，每次模型或prompt更新都跑一遍全量评测。这个闭环跑起来之后，同样的问题很少犯第二次。灰度发布也是同理，新prompt或新模型先切5%流量，看成功率曲线不掉再逐步放量。我吃过一次亏，prompt改了一句话没做灰度直接全量，当天成功率掉了六个点，回滚花了两小时。
评测闭环的核心是“跑得勤、看得细”。我现在是每天跑一次轻量评测集，每周跑一次全量，每月做一次跨模型横向对比。轻量集只覆盖高频场景和最近出过问题的场景，全量集才跑所有维度。这套节奏下来，模型升级和prompt迭代的风险基本可控。说到底，工具调用成功率不是靠某个大招提上去的，是靠这些细碎的工程动作一点点磨出来的。
上一章我把失败样本翻了个底朝天，也聊了一堆优化手段。方法讲完，问题就冒出来了：这些招儿到底怎么落地？总不能每个场景都上一套全量优化吧。我这段时间的体会是，工具调用这件事做到最后，拼的不是模型绝对能力，是匹配。什么活儿派给谁，花多少钱换多少成功率，这事儿得算账。这章我就把这些天攒下来的选型逻辑和治理经验摊开说说。
4.1 按场景选型：高频简单工具、复杂多工具任务与高风险调用的模型匹配
我先把工具调用场景分成三档，这个分法帮我省了不少纠结。第一档是高频简单工具，典型的就是查订单、查天气、发个通知这类单工具单参数调用。这类场景我基本不迷信大模型，DeepSeek和Qwen完全够用，成功率稳定在九成以上，价格还便宜。我有个客服项目，每天几十万次查询调用，全走DeepSeek，一年的API费用比走Claude省了一大截，用户根本感知不到差别。
第二档是复杂多工具任务，比如“帮我订一张明天下午去上海的高铁票，订好后同步到日历，再给同事发个消息”。这种活儿要规划、要管依赖、要保上下文，我现在的默认选择是Claude Sonnet和GPT-4.1。实测里这俩在多工具串行任务上的端到端成功率比开源模型高出十五到二十个点。贵是真贵，可你自己算算，一个五步任务失败重来的成本，比一开始就用贵模型高多了。我吃过这个亏，早期为了省token硬上便宜模型，结果用户来回重试，总成本反而上去了。
第三档高风险调用我单独拎出来，比如涉及转账、改权限、删数据这类不可逆操作。这档场景我根本不看单次成功率排行榜，我看的是失败时的表现。哪个模型在参数缺失时会停下来问，哪个模型在工具报错时不会乱重试，这些比成功率数字重要得多。目前我在这档场景里只认Claude和GPT-4.1，而且必须叠加强校验和人工确认环节。开源模型在这类场景里的“自信犯错”太吓人，参数幻觉它自己不觉得错，直接就把写操作执行了。
4.2 成本与成功率平衡：成功率提升带来的时延、token 与维护成本评估
成功率不是白来的，每一分提升背后都是钱和时间的账单。我拿一组真实数据算过：单工具场景成功率从88%提到94%，时延增加了0.3秒，token成本涨了不到两成，这个账很划算。可多工具场景从82%提到91%，成本直接翻倍，时延多了1.8秒，这就得看场景了。用户能不能接受多等这两秒，取决于是什么业务。订票场景用户愿意等，聊天回复场景多等一秒都嫌卡。
我特别想说的是维护成本这块，很多人算账的时候漏了。你用一个成功率高的模型，prompt可以写得很薄，校验器也能简化。换成一个成功率低一点的模型，你得堆示例、堆规则、堆重试逻辑，这些工程代码本身就是要人维护的。我有个项目为了压成本换了模型，结果prompt从两百行涨到六百行，每加一个新工具都要重新调一遍提示词，开发同学怨声载道。半年下来省的那点API费用，还不够填进去的人力成本。
时延和成功率之间的取舍也有讲究。我做过一组对比：开启结果验证环节后成功率涨了十个百分点，每轮多0.4秒。这个0.4秒在异步任务里几乎无感，在实时对话里就明显了。我现在的做法是分级处理，异步任务和后台批处理全开验证，实时交互类任务只在检测到高风险工具时才开。token成本同理，别一刀切，按场景分档，能省的地方省，该花的地方别抠。
4.3 企业级评测体系：持续跑分、线上监控与失败告警机制
单次评测跑得再漂亮，也只是一张快照。我现在的评测体系分三层，跑起来之后心里才踏实。最底层是每次模型或prompt变更触发的回归评测，跑核心集，看成功率曲线有没有掉，掉超过两个点就拦下来不让上线。中间层是每天定时跑的轻量集，覆盖高频工具和最近出过问题的样本，500条左右，十分钟跑完，出个日报。最上层是每周的全量横向对比，所有场景所有模型都跑一遍，用来指导选型和调参。
线上监控这块我踩过坑。最早只看整体成功率，结果某个低频工具的成功率掉到六成，被平均值盖住了，一个月后才发现，用户早骂开了。后来我改成按工具、按模型、按场景三个维度拆开看，每个维度单独设阈值。告警也分级，整体阈值掉三个点发个消息，单个工具掉十个点直接打电话。有次半夜被叫起来，是一个支付相关工具的成功率突然掉到七成，查下来是上游接口改了个字段名，模型没适配，救回来的损失不小。
失败告警发出来不是终点，怎么用才是关键。我给每个告警配了一套排查指引，从日志里自动拉出最近十条失败样本的原始请求和返回，值班的同学打开告警就能看到失败长什么样。这套东西做下来，平均故障定位时间从两小时压到二十分钟。我还让团队每周固定花一小时看告警历史，找反复出现的同类问题，很多优化点就是这么从告警里挖出来的。
4.4 最佳实践清单：构建高成功率工具调用链路的落地步骤
我把这两年攒的经验整理成一份清单，从零搭一条工具调用链路的队伍可以照着走。清单不长，每条背后都对应着我踩过的坑。
先定场景分级，把工具按调用频次和风险等级分好类，别一上来就全场景套同一套方案。
工具描述和参数schema按上一章说的写扎实，命名要带边界，枚举值列全，示例挂上去。
单工具场景先跑通再优化，别一开始就惦记多工具，我见过不少团队地基没打牢就搭三层楼，后面全推倒重来。
加上调用前校验和分级重试，工程侧这两步投入小回报大，能拦住相当一部分低级失败。
建模评测集，轻量集和全量集分开，跑分节奏定下来，别等出事了才想起来评测。
线上埋全链路日志，按工具、模型、场景三个维度监控，告警阈值分级设置。
失败样本定期回流进评测集，每次迭代都跑回归，形成闭环。
高风险场景强制加上人工确认和结果验证，别图快。
新prompt和新模型先灰度再放量，回滚预案提前准备好。
这份清单我给自己团队用了大半年，工具调用链路的整体成功率从七字头稳到了九字头。里面每一条单拎出来都不复杂，难的是坚持跑下去。
4.5 趋势展望：标准化评测、工具协议演进与智能体调用能力发展
我最近关注的方向里，最热闹的是工具协议标准化。MCP这类协议出来之后，工具的接入方式在统一，模型和工具的适配成本在往下走。这件事对评测也有影响，工具描述格式统一了，跨模型的成功率对比就有了更干净的基础，不用再为每家模型改一套工具定义。我觉得明后年评测基准会往这个方向收敛，现在这种各测各的局面会慢慢改善。
智能体调用能力这块变化很快。以前是单次调用拼准确率，现在越来越多任务是一串调用加中间决策，评测的颗粒度得跟着变。我最近在试端到端任务成功率作为主指标，单次调用成功率作为辅助诊断指标，两套一起看。还有个趋势我挺在意，模型开始具备主动澄清能力，参数不够时先问再调，这比硬着头皮瞎填强太多了。等这个能力普及，那些靠参数幻觉凑数的模型会被慢慢挤出去。
说句实在的，工具调用这件事的技术含量正在从模型侧往工程侧转移。模型能力会越来越接近，真正拉开差距的是你有没有一套可持续的评测治理体系。我见过不少团队在模型选型上反复横跳，其实体系建好了，选谁不选谁自然就有答案了。这一章的东西说白了就一句话：别追榜单，追你自己的场景数据。数据跑出来的选型，才是能落地的选型。
