工具调用详解：模型如何指令软件执行操作，以及可能出现的问题所在。
函数调用与工具使用的实用指南：请求循环、架构、读取工具与操作工具、智能体、MCP、提示注入、追踪及常见故障。
来源: Function Calling and Tool Use: How AI Agents Automate Workflows
早期的聊天机器人只是问答机器。用户输入问题，系统回复后交流即告结束。虽然实用，但功能十分有限。模型可以描述如何预订航班，却无法查询当天的票价；可以解释发票的内容，却无法在计费系统中生成发票；可以提议会议时间，却无法查看任何人的日历，更不用说将活动添加进去了。
函数调用打破了这一限制。语言模型能够向周围的软件寻求帮助，而整个技术架构也由此能力逐步扩展而来。
能够提出请求的模型
在没有工具的情况下，模型只能依据训练时学到的知识来回答问题。而有了工具，它就能判断某个问题需要外部帮助，并指出应使用哪种工具：天气服务、搜索索引、数据库查询、计算器、日历、支付流程、CRM查询系统、代码解释器，或是某些内部业务功能。模型不再凭猜测行事，而是会发出结构化的请求，应用程序负责处理该请求，模型则能获得更新且更准确的信息继续工作。包括OpenAI、Anthropic和Google在内的大型服务商，以及LangChain之类的框架，都对工具的使用给出了类似的描述：为模型提供定义明确的工具，由模型决定何时调用它们，传递结构化的参数，再将返回的结果整合到自己的答案或操作中。
一个便于理解的比喻：模型相当于对话的大脑，而各种工具则相当于手、眼、记忆、计算器、文件柜和送货车。大脑负责判断用户的需求，而工具则负责处理纯文本生成无法安全或可靠完成的任务。
函数调用与工具调用
这两个术语经常被互换使用，但实际上后者更为准确，因为其概念已超越了传统编程函数的范围。一个工具可能简单到只是get_weather(location)这样的函数，也可能包括数据库查询、浏览器会话、文档检索、计算器功能、shell命令、设计流程，或是对外部服务的链接。在OpenAI的术语体系中，工具是指向模型开放的功能，而工具调用则是一种特殊的模型回复，用于请求使用其中的某项功能。
关键在于，该模型通常不会自行执行任何操作。在常见的客户端架构中，它会返回一个结构化的请求，比如调用 get_customer_profile 函数并传入客户编号 12345。应用程序接收该请求后进行解析，执行实际的功能，收集输出结果后再将其返回给模型，模型随后会生成最终的响应。标准的处理流程为：提供可用的工具，接收工具调用，在自己的应用程序中运行相关代码，将结果传回，最终得到答案或进一步的工具调用。
但也存在例外情况。某些服务提供商会在自己的基础设施上托管服务器端工具。Anthropic 对这两种工具做了明确区分：客户端工具由你的应用程序执行，并以结构化的工具使用块形式呈现，而诸如网络搜索或代码执行之类的服务器端工具则可在 Anthropic 的服务器上运行。
这种区别非常重要。“模型调用了API”这一表述可能意味着模型生成了请求让您的软件来执行，也可能意味着平台代表模型运行了内置工具。在实际应用中，这会影响到安全措施、日志记录、成本、数据处理方式、谁有权审批事项，以及出现问题时由谁负责。
五步循环流程
大多数函数调用系统都会重复一个循环过程。
- 定义工具。每个工具都需要有名称、描述以及预期输入的列表。天气查询工具可能需要城市名和国家名；退款工具可能需要订单编号、退款原因以及最高退款金额；日程安排工具则需要参与者名单、日期、时间以及讨论主题。OpenAI的示例以JSON Schema格式描述参数，包括必填字段以及诸如additionalProperties设置为false之类的限制条件，而Google的Gemini文档则展示了基于名称、描述和输入结构构建的函数声明。
- 用户提出请求。模型会读取该请求，并判断是否能够立即回答。比如“解释一下函数调用是什么”很可能不需要使用任何工具，而“订单8472的当前状态如何？”则几乎肯定需要工具来处理。
该循环可能执行一次，也可能重复多次。智能体可以执行搜索、比较结果、调用其他工具、提出进一步询问、更新记录，最后总结其操作内容。
语言作为接口
使用工具的真正优势在于，日常语言能够成为软件的灵活前端。
传统上，每个功能都需要独立的按钮、表单、菜单和操作流程。而通过函数调用，用户可以直接表达意图：查找最新的Acme发票，确认款项是否到账，如果未到账则发送一封礼貌的提醒邮件。一句话背后就隐藏了多种工具：CRM搜索、发票获取、付款状态查询、邮件草稿生成，甚至在发送之前还可能包含审批请求。
优秀的产品设计并非可有可无。变化的是界面的起始点。软件不应要求用户去学习其结构，而应顺应人们日常讨论工作的方式。
这便使得工具描述显得极为重要。模糊的描述会让模型不知如何使用该工具；而清晰的描述则会说明何时该使用它、它的功能是什么、每个输入参数的含义以及哪些事项不可想当然。LangChain的文档将工具描述为具有明确定义的输入和输出功能的函数，并指出类型提示和简短描述有助于模型正确使用它们。
一个好的工具不仅仅是函数，更是一份契约。
四个相互关联的术语
尽管这些术语处于不同的层面，但人们常常将它们混为一谈。
- 函数调用是具体机制：模型会请求执行结构化的函数或工具调用。
- 工具使用则是更广泛的能力范畴，它包括函数调用、内置工具、网络搜索、文件搜索、代码执行、计算机控制、远程服务器操作，以及模型能够连接外部系统的任何其他方式。
- 智能体则是通过多步工具使用来达成目标的系统。OpenAI将智能体定义为能够规划任务、使用工具、与专业组件协作，并在多步骤任务中跟踪进度的应用程序；其Agents SDK则将智能体定义为配备了指令、工具以及可选功能（如任务交接、约束规则和结构化输出）的LLM。
换种说法：函数调用相当于插座，工具则是插入插座的设备，客服人员决定何时以及如何使用这些工具，而自动化则让整个流程作为一个有机系统运行起来。
为何要这么做
语言模型擅长理解、整合和传递信息，但无法替代计算器、数据库或实时监控系统。它们可以描述天气状况，但除非连接到相关数据源，否则无法知晓当天的天气预报；可以讨论发票内容，但除非与您的计费系统相连，否则无法获取相关数据；可以解释代码，但如果没有监控数据，就无法判断您的服务是否出现故障。
各类工具可以填补这些缺陷：计算器让算术运算更加可靠，搜索引擎能提供最新事实，文档检索工具则能基于私人文档给出答案，数据库工具可回答有关公司记录的问题，工作流工具则可用于创建工单、发送消息、更新订单或预约时间。谷歌的 Gemini 文档将它的优势归纳为三点：增加知识储备、拓展功能能力，以及通过外部系统执行操作。
从这一点开始，这种体验就不再像是聊天，而更像是使用软件。模型不再仅仅生成文字，还能协助协调各项任务。
这一理念背后的研究
能够使用工具的智能体并非凭空出现，早期的四项研究为该领域奠定了基础。
- MRKL Systems（2022年）提出了一种模块化设计，将语言模型与外部知识库及推理模块相结合。其核心理念很简单：不要让一个模型承担所有工作，而是将不同任务分配给专门的组件。
所有这些都指向同一个理念：最优秀的AI系统并非孤立的模型，而是与工具、内存、规则、软件以及人类监督相连接的更大系统的一部分。
优秀工具的特征
优秀的工具具有功能明确、易于理解且安全可靠的特点。
功能明确的工具有助于模型选择，也便于开发者控制。像update_everything这样的工具表述模糊且存在风险，而create_refund_request则更为清晰。approve_refund更需要谨慎使用，因为它会改变现实世界。
易于理解的工具会使用简洁的名称和描述。模型无需猜测fetch_record是用于获取客户资料、下载文件还是检索医疗记录。描述中应明确说明其用途、适用场景、每个参数的含义以及返回值的格式。
安全的工具具备内置限制机制。它们会检查权限、验证输入数据，避免授予不必要的访问权限。这类工具会给出清晰的错误提示、记录操作日志，并在执行敏感操作前要求人工确认。它们绝不会赋予模型超出任务需求之外的权限。
OpenAI建议使用严格的模式，以确保参数能够可靠地传递；随着工作流的扩展，其Agents SDK还会引导开发者关注规范约束、人工审核、清晰的结果展示、状态管理以及可观测性。实际上，最好的工具往往都很普通：它们各自擅长完成一项任务，不会给开发者、模型或用户带来任何意外。
模式即语法
模式就是工具使用的“语法”。当模型调用某个函数时，必须以应用程序能够理解的格式提供参数。模式规定了存在哪些字段、它们的类型、哪些是必填项，有时还会规定允许的取值范围。例如，一个天气工具可能要求输入字符串形式的地点信息，以及限定为摄氏度或华氏度的温度单位字段。
严格的模式能够减少歧义并简化验证流程。OpenAI的文档指出，严格模式会确保调用行为符合所声明的模式要求，它要求将additionalProperties设置为false，同时为所有必填字段添加标记，并使用可空类型来表示可选值。
不过，模式本身并不能保证系统的安全性。即使格式完美无缺的请求也可能存在问题。例如，向all_customers@example.com发送邮件的操作虽然完全符合模式要求，但可能仍是个糟糕的主意。因此，模式验证必须与业务规则、授权机制、速率限制、审核流程以及监控措施相结合使用。
读取与执行
一个重要的设计决策是确定某个工具是仅用于读取数据还是同时具备执行功能。
只读工具用于获取信息：搜索文档、查询记录、检查库存、获取天气数据、计算总数、查看日志。尽管它们仍可能泄露敏感数据，需要访问控制，但通常不会对数据本身进行任何修改。
操作工具则用于执行具体任务：发送邮件、下订单、取消订阅、办理退款、更新数据库、创建工单、部署代码或安排会议。使用这些工具时出错会带来实际后果。
设计良好的智能体会对这两类工具采取不同的处理方式。只读工具可在权限检查的前提下更自由地使用，而操作工具则一般需要更严格的控制措施：确认界面、审批流程、交易限额、审计日志、回滚选项以及向用户明确的提示信息。
此时，自动化已不再是单纯的技术问题，而是一个管理问题。关键不在于模型能否调用函数，而在于在何种条件下才应允许某个系统代表人类执行操作。
从单次调用到智能代理
一次工具调用就能回答简单的问题。而智能代理则是为处理更复杂、更繁琐的任务而存在的。例如，当需要准备每周销售汇总并标记出需要关注的账户时，智能代理可能需要获取销售数据，与前期数据对比，识别异常模式，查阅CRM中的备注，撰写汇总报告并发送给经理。这是一系列决策的体现，而非单次调用而已。
智能体框架负责管理整个流程。它们负责维护状态、运行工具、重试失败的步骤、在各个专业智能体之间传递任务、生成结构化输出、执行约束规则并记录操作轨迹。OpenAI的智能体SDK文档介绍了两种常见架构：一种是管理器模式，即中央智能体将其他专业智能体视为工具来调用；另一种是任务交接模式，即某个智能体将控制权移交给专业智能体。
虽然功能强大，但也不宜过度理想化。智能体并非存在于软件中的小型员工，而是一个由代码构成的概率系统，因此需要明确的职责划分、有限的权限、测试用例、监控机制、升级路径以及故障处理方案。智能体拥有的自由度越高，其背后的工程设计就需越谨慎。
自动化与实际工作的交汇点
自动化是工具使用转化为实际操作的阶段。
- 支持团队可以指派员工对工单进行分类、查找相关政策文件、起草回复内容并提出后续处理方案。
- 财务团队可以核对发票、查找缺失的采购订单并编制异常报告。
- 工程团队可以检查失败的测试用例、搜索日志、提出修复方案并提交拉取请求。
- 销售团队可以完善潜在客户信息、整理通话记录并更新客户关系管理系统。
最有效的自动化并非从模型能做什么出发，而是从现有的工作流程入手。工作从何处开始？需要哪些信息？哪些决策是常规的，哪些是敏感的？目前哪些环节由人工进行审核、批准或修正？哪些错误会令人烦恼，哪些错误又会带来高昂代价？
有了这些答案，相关工具就能让流程更加顺畅地推进。智能体负责收集事实、填写表格、起草消息、对比记录并给出建议，而在需要判断力、责任意识或信任关系的场合，则由人类来参与决策。
标准化连接
早期的集成都是定制化的。每个应用都有自己展示工具、资源、提示及认证方式的方法。这种方式适用于小型项目，但随着组织将更多模型与更多系统相连，便变得难以管理。
模型上下文协议（MCP）便是试图对这一层进行标准化的尝试之一。其规范说明了应用程序如何共享上下文、提供工具与功能，以及如何通过主机、客户端和服务器的架构实现灵活的集成。MCP服务器能够提供资源、提示和工具。该协议使用JSON-RPC 2.0格式进行消息交换，涵盖了能力协商、进度跟踪、取消操作、日志记录和错误报告等功能。
其优势显而易见：统一的工具层能让人工智能应用始终如一地连接到数据源和工作流，从而避免每家公司都重新构建集成方案。但缺点则是新的风险。提供强大功能的工具服务器应被宿主应用视为真正的安全边界，而非又一个插件。MCP本身的规范强调了用户同意、数据隐私、工具安全性，以及对任意数据访问和代码执行路径的管控。
安全至上
能够执行操作的工具型代理极具价值，但正是这种能力带来了风险。
提示注入是最为人熟知的威胁：它指的是隐藏在用户输入或外部内容中的恶意指令，这些指令会迫使模型做出本应避免的行为。OWASP将其列为大型语言模型应用面临的最主要风险之一，其在2025年的相关资料中也提到了“过度自主性”问题，即基于大型语言模型的系统拥有超出合理范围的行动权限，从而导致出现意外、模糊或被操纵的输出，进而引发有害行为。
间接注入则是与智能体相关的最令人担忧的问题。假设某个智能体能够阅读邮件并发送回复，恶意发送者便可以在邮件中嵌入某行指令，要求该智能体无视自身规则并转发用户的联系人信息。用户可能根本看不到那行指令，但模型依然会对其进行处理。如果系统过度信任且权限设置过宽，看似无害的邮件就可能会转化为实际的恶意行动。
安全团队逐渐将大型语言模型视为仅通过措辞即可被欺骗的系统，而不仅是通过代码缺陷。英国国家网络安全中心指出，提示注入与SQL注入不同，因为大型语言模型并未在指令与不可信数据之间设置严格的界限。
有效的应对措施是采取多层防御策略：
- 尽可能限制工具的权限。
- 将读取工具与写入工具分开使用。
- 对敏感操作进行审批。
- 将获取的任何内容，无论是网页、邮件、文档还是数据库字段，都视为不可信数据。
- 检查每个工具的参数，并在将其传递给其他系统之前对输出内容进行净化处理。
- 使用允许列表，记录每一次工具调用，并监控异常活动。
- 通过对抗性示例进行测试，并尽可能建立撤销操作的方法。
仅授予智能体其工作流程真正所需的权限。
查看智能体的操作记录
智能体软件需要的记录比普通软件更为丰富，因为一次执行过程可能包含模型推理、工具调用、任务传递、规则检查、重试以及最终结果。通过追踪功能，开发者可以完整了解从请求到结果的整个流程。根据 OpenAI Agents SDK 的追踪文档，追踪信息能够记录大语言模型的生成内容、工具调用、任务传递、规则约束以及自定义事件，从而帮助团队在开发和生产环境中调试、可视化并监控工作流程。
这关乎质量与安全。当智能体给出错误答案时，必须找出原因：是它选择了错误的工具？工具返回了过时的数据？模型误解了描述？防护机制失效了？用户缺乏权限？还是智能体过早停止了工作？如果没有相关痕迹，团队只能靠猜测。而具备良好的可观测性后，构建智能体就能真正成为一项工程实践。
这些系统通常如何出错
故障是可以预测的。在模型层面，当名称或描述不明确时，它可能会选择错误的工具；发送不完整或错误的参数；本应提出澄清问题时却直接调用工具；或者在需要最新数据时跳过调用。它还可能过度频繁地调用工具，从而增加成本和延迟；在反复调用中陷入循环却毫无进展；或者过度信任工具的输出结果。
该应用程序也可能会出现故障。它可能会在未经验证的情况下接受模型提供的参数，同时暴露过多工具，返回令模型困惑的混乱输出，吞没有用的错误信息，将结果错误地关联到生成它们的调用上，或者缺乏审计日志、速率限制和审批机制。
简单调整提示语很少能解决这些问题。真正的解决办法是设计更完善的工具、更清晰的架构、更严格的权限控制、更合理的状态管理、更多的测试以及更好的监控机制。
何时无需使用工具
并非所有情况都需要调用函数。如果某项任务仅需解释说明，使用工具反而会增加复杂性。如果所需信息已在提示中且不会变化，就无需再获取数据。对于那些无法安全验证或撤销的高风险操作，完全自动化可能并非最佳选择。此外，如果工具的输出不可靠、缺乏文档支持或存在安全漏洞，将其与智能体结合只会让问题更加严重。
用户体验也会受到影响。工具调用会带来延迟，权限提示会打断操作流程，而复杂的智能体则可能显得难以预测。有时，简单的表单形式比聊天式工作流更合适，尤其是当用户明确知道自己需要什么，并且追求速度、一致性或合规性的时候。
目标并非让所有事物都依赖智能体。只有在语言、上下文和操作真正契合的情况下，才使用工具。
构建优质系统的习惯
先从几款功能明确、不会产生歧义的工具开始，逐步扩大对该模型的使用范围。选择名称直观、功能单一的工具。为模型编写说明，而不仅仅是面向工程师。尽可能使用严格的架构，并在自己的代码中始终对输入数据进行验证。保持输出内容简短，只向模型传递其真正需要的信息。
需为每个工具单独设置权限。能够查询订单状态的客服人员并不一定需要具备退款功能；日程安排助手可能需要查看日历的空闲时间，但不需要私人事件的备注；编程助手在能够提交拉取请求之前，应已能够充分阅读代码仓库的内容。
对于任何敏感、昂贵、公开、具有法律约束力、涉及财务或难以撤销的操作，都必须要求相关人员签字确认，并且要使请求内容具体明确，以便审核者清楚了解将会发生什么。
相关阅读
- 代理在生产环境中的工具使用：来源追溯、重试机制与可观测性 —— 某银行开发的代理错误调用了付费API并编造了电话号码。本文介绍了最基本的工具组合、参数来源追溯、三级重试机制以及针对不同工具的指标监控方法。
- 代理内存快照、技能系统、数据衰减与分支作用域控制 —— 为编程型代理设计的嵌入式向量数据库内存层新增的四种功能：可合并的便携式快照、技能激活功能、带冲突检测的数据衰减机制，以及基于分支的作用域内存管理。