很多刚接触 AI Agent 的人会困惑：模型不是只会「对话」吗，它凭什么能查天气、订机票、操作软件？答案是一个叫 Function Calling（函数调用，也叫工具调用）的机制。它是 Agent 从「聊天机器人」变成「能干活」的分水岭——没有它，模型再聪明也只是个回答问题的；有了它，模型才能把「用户想做的事」翻译成「系统能执行的指令」。
但工具调用远没有看起来那么简单：模型怎么知道该调哪个工具？参数怎么填才不会被接口拒收？调完之后的结果怎么用？为什么有时候模型死活不调工具、有时候又乱调一通？这篇百科从机制讲起，把这些环节一个个拆开。看完你就能看懂 Agent 的工具调用链路，出了问题也知道该往哪个环节查。
先搞懂一件事：模型本身不会「动手」
大模型本质上是一个文本生成器：你输入一段文字，它输出一段文字。它没有能力真的去访问天气网站、读写数据库、点某个按钮——它只能「说」。想让模型对真实世界产生影响，就必须在模型外面挂一层「手」，也就是各种工具：API、脚本、数据库连接、浏览器操作等等。
于是问题变成：模型怎么告诉系统「我想用 3 号工具、参数是这些」？Function Calling 干的就是这件事：它让模型在生成普通文本之外，还能生成一种特殊输出——结构化的「工具调用请求」。系统收到请求后去执行真正的工具，再把结果送回给模型，模型基于结果继续推理。整个过程形成一个循环：想 → 调 → 看结果 → 再想 → 再调，直到任务完成。这正是 Agent = Model + Harness 里说的分工：模型出脑子，外面那层壳子（工具、权限、编排）负责动手。
一次工具调用的完整生命周期
把一次调用放慢看，大致是五步：
第一步，告诉模型有哪些工具可用。开发者在请求里附带一份工具清单，每个工具包含名字、描述和参数定义（通常用 JSON Schema 写）。这一步的信息量直接决定模型用不用得对——描述写得太含糊，模型就可能选错工具。
第二步，模型判断「该不该调、调哪个」。模型根据用户请求和当前上下文，决定是否需要工具。需要的话，它输出一个结构化的调用意图：调哪个工具、每个参数填什么值。
第三步，系统校验并执行。系统收到模型输出后，先按 Schema 校验参数类型和必填项，校验通过才真正调用工具。注意：这一步是代码说了算，模型说想调就调是不行的——权限检查、工具白名单都在这层拦。
第四步，把结果回填给模型。工具执行完，系统把返回结果（成功数据或报错信息）作为一条新消息放回上下文，让模型「看到」结果。
第五步，模型决定下一步。结果符合预期就继续推进或收尾；结果异常就分析原因、改参数重试、换工具，或干脆承认搞不定。循环直到任务完成、模型主动停止或触发人工介入。
这一整套循环里，模型只负责「想」，执行和校验都在模型外面。这也意味着：工具调用的可靠性问题，大部分不是模型问题，而是外面这层壳的设计问题——和 AI Agent 上下文管理 讲的是同一个道理：Agent 翻车，锅往往在系统设计，不在模型智商。
决定成败的三个环节
环节一：工具描述写得好不好。模型选工具基本靠看描述。两个常见错误：描述太短（比如「获取天气」），模型不知道什么时候该用它；描述太长塞满营销话术，模型抓不住重点。好描述的标准是：说明这个工具解决什么问题、什么时候用、什么时候别用、参数有什么讲究，最好给一两个典型用法示例。这跟给新人写交接文档是一个道理。
环节二：参数生成得准不准。模型填参数时最容易出的错：把用户原话整段塞进单个字段（用户说「查下北京的天气」，它把「北京的天气」整个填进城市参数）、日期格式不对、必填项漏填。治本的办法不是靠模型自觉，而是靠清晰的 JSON Schema：字段含义写清楚、格式给枚举或示例、必填项标明白，再让系统在调用前校验、不合格就打回让模型重填——这正是 AI Agent 结构化输出 里的思路：别指望模型「写得规范点」，用类型约束和校验兜底。
环节三：失败了怎么办。工具调用一定会失败：网络超时、接口报错、参数被拒、返回格式不对。失败处理的关键是：把错误信息原样回填给模型，让它基于真实报错判断下一步——是重试、改参数、换工具，还是停下来问人。最怕的是系统吞掉错误、只回一句「调用失败」，模型什么都学不到，只能原地瞎猜重试。完整的重试、升级、转人工策略，AI Agent 工具调用失败排查 已经给了整套清单，这里不重复展开。
Function Calling、MCP、插件到底是什么关系
这三个词经常被混着说，其实层次不同。Function Calling 是「机制」：模型输出结构化调用请求这件事本身，各家模型都有类似能力，只是叫法不同（OpenAI 叫 function calling，Claude 系叫 tool use）。插件是「产品形态」：把某个外部能力封装成可被调用的工具。MCP 是「连接标准」：它规定了工具怎么描述、怎么被发现、怎么被调用，让同一个 Agent 不用为每家服务商各写一套接入代码——OpenClaw 接 MCP 工具 里那种配个服务就能用的体验，靠的就是这个标准。
打个比方：Function Calling 是手会抓握的能力，插件是抓到的具体物件，MCP 是统一了物件的规格说明书——物件都按同一规格生产，手就什么都能抓。做 Agent 时，小项目直接用各家原生的 Function Calling 就够了；工具一多、要跨服务商协作，就该上 MCP 这类标准层。
调优清单与常见坑
把高频问题浓缩成一张检查单：模型老是调错工具？先改工具描述，把适用场景和反例写清楚；模型调了不该调的工具？检查工具清单里是不是塞了太多用不上的工具——工具越少，选择越准，权限也越小，AI Agent 权限管理 的最小权限原则在这里同样适用；参数老填错？上 JSON Schema 加调用前校验，不合格打回重填；调用失败后原地打转？确认错误信息是否完整回填，并设好重试上限和升级路径；工具返回太大占爆上下文？对长结果做摘要或截断再回填，别让工具结果把对话窗口塞满。
还有一个隐蔽的坑：模型的「幻觉调用」——它可能编造一个不存在的工具名或参数。系统层必须校验：工具名不在清单里直接拦下，参数不合法直接打回。宁可让模型重来一次，也别把非法请求发出去。
优缺点与适合人群
理解这套机制，最直接的价值是排障：Agent 表现不对时，你能准确判断是「模型没想对」还是「外面这层壳没设计好」，不用每次都归咎于模型；设计 Agent 时，你知道把校验、权限、重试放在哪一层，而不是全堆在提示词里。代价是：工具调用链路涉及输出解析、Schema 设计、错误处理、上下文管理，要做好确实比「写段提示词让模型聊天」复杂一个量级。
适合：正在搭 Agent 的开发者、要给团队设计 Agent 架构的技术负责人、被「模型乱调工具」折磨的运维和产品同学。只是用现成 Agent 产品（比如直接用 OpenClaw 内置工具）的普通用户，可以不深究机制——但了解一下没坏处，至少出问题时你知道该看哪里。
总结
Function Calling 是 AI Agent 从「会说话」到「会干活」的关键机制：本质是让模型在普通文本之外输出结构化的工具调用请求，由外面的系统去执行、校验、回填，形成「想—调—看—再想」的循环。决定它好不好用的三个环节是：工具描述写没写清楚、参数校验兜不兜得住、失败之后错误信息有没有完整回填。记住一句心法：模型负责想，系统负责守——把校验、权限、重试这些可靠性问题放在模型外面的壳子上，而不是指望模型每次都自觉，你的 Agent 才能真正用得稳。
