很多人第一次听说“工具调用”（tool calling / function calling），会以为这事很简单：不就是让 AI 输出一段格式正确的指令，去调个接口吗？
但真正做过线上 Agent 的人都知道，工具调用出问题，几乎从来不是因为“AI 选错了工具”。它更常见的死法是：参数里藏了个恶意路径、工具返回的错误信息被人做了手脚、工具一多 AI 就开始犯迷糊、还有协议本身给大规模部署埋了坑。
所以这里想说的是：工具调用的难点，不在于“AI 会不会调”，而在于你在 AI 和外部世界之间，立了几道拦得住东西的墙。
第一道坎：安全——别指望 AI“识破坏人”，要让坏人“干不了坏事”
关于工具调用的安全，大家第一反应是“检测提示词注入”，也就是识别出恶意指令然后拒绝。但最近的研究给这个思路泼了冷水。
有个团队测了 3250 个攻击场景、七个模型，结论是：用 Function Calling 架构时，攻击成功率高达 73.5%；MCP 架构也有 62.6%。更扎心的是，多步连环攻击的成功率到了 91%–96% ，而且模型越聪明，反而越容易被利用——因为检测能力变强，没转化成安全性变强。
这说明一个很朴素的事实：只要安全还依赖 AI 在脑子里“想一想这是不是恶意”，那它就有被绕过的空间。 越会推理的模型，也越会给自己找理由。
还有一个特别容易被忽略的漏洞：工具报错信息。工具返回的错误提示在 AI 眼里有一种“权威感”，会触发它进入“我要赶紧纠错”的模式，顺便就把平时的安全警觉绕过去了。在四个前沿模型上，往错误信息里塞注入内容，成功率能翻三倍，某些条件下甚至 100% 中招。为什么危险？因为错误信息本来就是“系统说的话”，AI 被训练成要信任它，而攻击者恰好能劫持这条信任通道。
那怎么办？有个项目叫 ToolClad，思路很值得借鉴：别去检测“危险参数”，而是让危险参数根本没法写出来。 它给每个工具的参数定死“形状”——比如某个参数只能是某个目录下的路径、某个参数只能是特定主机名——在真正调用之前先验一遍，写不成这个形状的一律拒绝。 它的关键点在于：这一层跟别的安全手段不重复。策略引擎管“这个动作允不允许”，消毒器不管参数内容，而 ToolClad 正好卡住了那个最要命的漏洞——动作是允许的，但参数被恶意改造了。
说白了：工具调用的安全，不该外包给 AI 的判断力，而应该写进调用的结构里。参数合约、类型限制、别把参数拼成字符串去执行——这些看着像“老掉牙的软件工程”，在 Agent 场景里恰恰是 AI 绕不过去的第一堵墙。
第二道坎：协议——MCP 火是火，但一上规模就烧钱
MCP 在如今几乎成了工具调用的“通用插头”，但它一上企业规模，就暴露了两个大成本。
第一个是服务器越堆越多。每接一个 API 就包一个独立服务器，各有各的部署、依赖和密码管理。有人分析了 116 个官方 MCP 服务器，发现 88.6% 背后就是普通的 REST API，92% 的工具就是 API 的裸包装，而一个服务器平均只暴露了底层 API 的 19% 功能。
第二个更根本：每个工具的名字、说明、参数格式，每次对话都得塞进 AI 的上下文里。 工具越多，占的地方越多，而且是线性增长。GitHub 的 API 有 900 多个接口，就算只取 200 个，在任何用户开口之前就已经吃掉几万 token 了。
结果就是“选择坍缩”：现实部署只能挑一小撮组织真用得上的 API 暴露出去，或者把工具集拆得七零八落，哪种都别扭。MCP 解决的是“AI 怎么调工具”的接口统一问题，但在“AI 怎么知道有哪些工具”这件事上，用的还是最原始的“全广播”。
这里推荐有个叫 DADL 的方案是对着这个缺陷来的：不把每个工具的说明全推给 AI，只暴露两个固定大小的操作——search（找工具）和 execute（执行）。工具广告的 token 成本从约 14.2 万降到约 1000，压缩了 142 倍。
数字本身不是重点，重点是协议设计的重心变了：工具调用能不能规模化，不取决于接口多“标准”，而取决于“找工具”这件事有没有被当成一个独立的检索问题来处理，而不是一股脑往上下文窗口里塞。
第三道坎：认知——工具一多，AI 就开始“眼花”
先不谈安全和协议，就算纯从“AI 能不能想清楚”这个角度说，工具调用也有个被低估的坎：工具越多，AI 选得越不准。
生产环境的数据显示，工具数量超过 15 个左右，准确率就明显往下掉；有个受控测试里，工具从 10 个涨到 40 个，选择准确率从 81.7% 掉到 62.5%。这不是“稍微难一点”，是两个机制在起作用。
第一个是注意力被稀释，好东西卡在中间没人看。AI 对上下文开头和结尾记得牢，中间容易丢。几十个长得很像的工具说明堆在一起，真正合适的那个往往恰好在中间的死角——它不是推理不出来，而是注意力被结构性地拉走了。
第二个是工具幻觉：AI 会编出不存在的工具名，或者调对了工具、参数却从另一个工具那儿借来——后者更阴，因为调用“看起来发生了”，但参数是错位的，属于硬失败。
这些发现指向一个反直觉的结论：工具调用靠不靠谱，主要不在工具本身，而在 AI 做选择之前看到了什么。 先用一个便宜的分类器判断“这轮到底要不要用工具”（门控），再把工具说明做成向量库、只召回跟当前意图相关的那几个（检索式选择），然后在候选集上分层决策——这套组合拳本质上是主动管理 AI 的注意力预算，而不是被动指望它聪明。
工具调用的质量，很大程度是信息架构的质量。
第四道坎：失败恢复——最贵的坑，是“调用成功了，活儿没干成”
工具调用领域有个系统性偏差：大家几乎都在看“调用成没成功”，但线上最烧钱的失败是调用成功了，整个流程却失败了。
一个工具可能返回合法的 JSON、正确的状态码，但返回的内容跟 Agent 当前所处的流程阶段对不上；一条工具链可能每一步都“调对了”，却在依赖关系上越积越偏，直到下游某一步才发现上游早就歪了，救不回来了。
工具之间有结构上的依赖，也有行为上的依赖，硬走单条路线，一出错就没法恢复，搜索空间还指数级爆炸。所以应该把 LLM 的工具调用拆成两层——上层四选一做决策，下层在工具依赖图上做路径搜索，用一个显式的“图导航器”去建模工具之间的关系。这样 API 挂了或者语义漂移了，能实时重组工具链，而不是从头重来。
这个架构选择的洞察就一句话：工具调用的恢复能力，不该指望从 AI 的推理里“自己长出来”，而该被设计进编排层的拓扑结构里。 回溯、备选路径、依赖图的动态重路由，这些是编排器的活儿，不是提示词的活儿。
相应地，评估也得跟着升级。一套完整的工具调用评估，至少要分清楚五件事：这轮该不该用工具（门控对不对）、工具选对没（选择准不准）、参数跟现实世界对得上吗（参数精确性）、调用链在依赖上走得通吗（编排有效性）、某一步挂了能不能绕到等价路径（恢复能力）。多数团队只在前两项上建了基准，后三项基本靠蒙——而这恰恰是线上事故的主要来源。
最后
模型会越来越强，推理会越来越好，但上面每一道墙要解决的问题，都不会因为模型变强而自动消失。它们只会从“AI 做不到”的明面失败，变成“AI 做得到、但你不希望它那样做”的暗面风险。工具调用真正成熟的标志，不是 Agent 能调一万个工具，而是它调每一个工具时，你都清楚边界画在哪，以及边界被越过时，有什么结构会接住它。
本文由 AI图鉴自动抓取并翻译，版权归原作者所有；如需查看原文请点下方链接。
For the first time, many people have heard of "tool calling / fight calling" and think it's simple: isn't it just for AI to output a command in the right format and switch an interface?
But the real people who did it online know that tool call had problems, almost never because "AI chose the wrong tool." The more common way to die is to hide a malicious path in the parameters, false information about the return of the tools, the use of more than one tool, and the agreement itself to bury the mass deployments.
So what we're trying to say here is that the hard part of tool call is not whether or not it's "AI" or not, but you're building a wall between AI and the outside world that can stop things.
First Cam: Security - Don't count on AI to destroy people, let the bad guys do bad things.
With regard to the security of tool call, your first reaction was to “detect the injection of prompt”, i.e. to identify malicious instructions and then reject them. But recent research has thrown cold water into this thinking.
A team measured 3250 attack scenes, seven models, and concluded that success rate was as high as 73.5 per cent when using the Function Calling structure; the MCP structure was also 62.6 per cent. Even more solid is that success rate, a multi-step series of attacks, has reached 91 per cent to 96 per cent, and the smarter the model, the easier it is to be used -- because the detection capacity has become stronger and it has not become safer.
And that's a very simple fact: as long as security depends on AI, "Think if it's malicious," it has the space to be bypassed. The more reasoned the model, the more reasoned.
There is also a particularly vulnerable loophole: the tool is misinformed. The tool returns the wrong hint in AI's eyes of a sense of authority that triggers a pattern of "I'm going to go wrong" and bypasses normal security. In four front-line models, plug in to the wrong message, success rate triples, and under some conditions even 100%. Why is it dangerous? Because the wrong message is the word of the system, AI is trained to trust it, and the attackers happen to be able to hijack this channel of trust.
So what? There's a project called ToolClad, and it's worth the thought: don't test the “danger parameters”, but make it impossible to write them. It sets the shape of the parameter for each tool -- for example, a parameter can only be a path under a directory, a parameter can only be a specific host name -- Before a real call is made, all those who cannot write this shape refuse. Its key point is that this layer does not duplicate other means of security. The policy engine tube "This action is not allowed" and the disinfector doesn't care about the parameters, and ToolClad just stuck the worst hole -- the action was allowed, but the parameters were maliciously modified.
Paraphrasing: tool call's safety should not be outsourced to AI's judgment, but should be written into the call structure. Parameter contracts, type limits, do not spell parameters into strings to execute -- these look like "old software projects," which is exactly the first wall in the Agent scene that I can't bypass.
Number two: protocol-MCP fire is fire, but it burns money at scale.
MCP is now almost a “general plug-in” for tool call, but it exposes two large costs as soon as it is enterprise size.
The first is that there are more servers. Each API goes through a single server, each with its deployment, dependence and password management. An analysis of 116 official MCP servers found that 88.6 per cent of the normal REST API, 92 per cent of the tool, was a naked package of API, while a server exposed on average only 19 per cent of the bottom API function.
The second is more fundamental: each tool's name, description, parameter format, each conversation has to be inserted into AI's context. The more tools, the more places, the more linear growth. GitHub's API has over 900 interfaces, even 200, and has already eaten tens of thousands of tokens before any user opens his mouth.
The result is "choice to collapse": real deployment can only expose a handful of organizations that can really be used by API, or break down the tool set, which is both awkward. MCP addresses the harmonization of interfaces of "AI How to Modify Tools", but in the case of "AI How to Know What Tools", it is still the original "full broadcast".
The proposal for a DADL is based on this shortcoming: instead of transmitting the description of each tool to AI, it exposes only two fixed-sized operations — the search for tools and the execution. Token costs for tool advertising have been reduced from about 142,000 to about 1,000, which has been reduced to 142 times.
The figure itself is not the focus, but the focus of the protocol design has changed: the size of tool call depends not on the multiple “standards” of the interface, but rather on whether the matter of finding tools is treated as an independent search rather than as a brain to context window.
Number three: Cognisance -- when there are more tools, AI begins to see.
Without talking about security and agreement, even from the perspective of "Ai, can you think clearly" tool call has an underestimation: the more tools, the more Ai chooses.
Data from the production environment show that the number of tools is more than 15 and the accuracy rate drops significantly; in one controlled test, the number of tools rose from 10 to 40, and the selection rate fell from 81.7 to 62.5 per cent. It is not “a little bit difficult”, it is the functioning of two mechanisms.
The first is that attention is diluted and good things are stuck in the middle. AI remembers the beginning and end of context, which is easy to throw. Dozens of similar tools show that they're stacked together, and the one that's really right is in the middle. Rather than being incomprehensible, it has been structurally drawn away.
The second is a tool illusion: AI will create a tool name that does not exist, or correct the tool, and the parameters will be borrowed from another tool — the latter, because the call “looks to have happened”, but the parameters are wrong and hard failure.
These findings point to an anti-intuitive conclusion: tool call does not depend on the tools themselves, and what was seen before AI made the choice. Let's use a cheap sorter to figure out whether or not the wheel is a tool (door control), then we'll use it as a vector bank, we'll call back only those that are relevant to the current intent (retribution), and then we'll decide at the top of the candidate pool -- This combination of fists is essentially a proactive management of AI's attention budget, not a passive expectation of its intelligence.
tool call quality, to a large extent, information architecture.
The fourth track: Failure to recover - the most expensive pit - was "The call worked, the job failed."
There is a systemic bias in the area of tool call: almost everyone's looking at "the call failed," but the biggest failure on the line was the call succeeded and the whole process failed.
A tool may return to a legitimate JSON, correct state code, but the content of the return is not in line with the process phase in which Agent is currently in; a tool chain may be “corrected” every step of the way, but it tends to become more biased in a dependency relationship, and it is not until a step downstream that it is discovered that the upstream is crooked and cannot be saved.
There is structural and behavioural dependence between instruments, a single route is imposed and cannot be restored once a mistake has been made, and the search space has exploded exponentially. So LLM's tool call should be broken down into two layers — the upper four to make decisions, the lower one to make a path search on a tool-dependent map, using a visible “graph navigator” to model the relationship between the tools. So, the API hangs, or the semantic drifts, can re-establish the tool chain in real time, not start over.
The vision chosen for this structure is one thing: the resilience of tool call should not be expected to grow from AI's reasoning, but should be designed into the structure of the architecture. Retrospective, alternative paths, dynamic re-routing of dependent maps, these are the work of the organizer, not the work of prompt.
Accordingly, the assessment has to be upgraded. A complete set of tool call assessments needs to distinguish between at least five things: whether this round should be using a tool (the door is right), whether the tool selection is right (the choice is wrong), whether the parameter is right with the real world (the accuracy of the parameter), whether the call chain works on dependence (the validity of the arrangement), whether a certain step can go around the equivalent price path (the ability to recover). Most of the teams have only established benchmarks on the first two, the latter three largely dependent — which is the main source of online accidents.
Finally.
Models will get stronger and reasoning will get better, but each wall above will not automatically disappear because it becomes stronger. They only fail from the face of "AI can't" to the risk of "AI can do it, but you don't want it to do it." The symbol of tool call's true maturity is not that Agent can adjust 10,000 tools, but when it adjusts every tool, you know where the border is and what structure will catch it when the border is crossed.
Auto-fetched and translated by AI Atlas. All rights belong to the original author.