AI Agent Harness Engineering 的工具调用（Function Calling）技术全解析

数据结构与算法学习

183人浏览 · 2026-06-01 19:44:31

数据结构与算法学习 · 2026-06-01 19:44:31 发布

AI Agent Harness Engineering 的工具调用（Function Calling）技术全解析

引言

1.1 背景介绍：从「知识问答机」到「行动执行者」的大模型跃迁

2022年11月ChatGPT横空出世，人类第一次近距离感受到了通用大语言模型（Large Language Model, LLM） 在自然语言理解、生成、推理上的惊人能力——它可以写论文、写代码、翻译多语言、做逻辑题，甚至扮演苏格拉底陪你哲学对话。但兴奋过后，开发者和普通用户很快发现了它的两大致命局限：

「知识时效性死锁」： 预训练大模型的知识截止日期是固定的（比如GPT-3.5 Turbo 2024.07的知识截止是2024年3月，Claude 3 Opus是2024年5月），无法回答「今天北京的天气如何？」「2024年双十一淘宝的销售额是多少？」这类实时更新的问题；
「弱工具理性缺陷」： 大模型本质上是一个「基于统计规律的文本生成器」，它没有实际操作能力——不能帮你打开电脑上的文件、不能调用公司的私有ERP系统查库存、不能通过Python脚本计算复杂的积分或金融衍生品定价、不能通过API订机票订酒店。

这两大局限直接把LLM卡在了「知识辅助工具」的阶段，无法成为能自主感知环境、理解目标、规划步骤、执行行动、迭代优化的AI Agent（智能体）。而Function Calling（工具调用，有的资料也叫Tool Use、Plugin System）技术，正是打破这两大死锁、推动大模型从「认知层」跃迁至「行动层」的核心桥梁。

根据OpenAI在2023年6月GPT-3.5 Turbo Function Calling发布会上的官方数据，使用Function Calling后，开发者构建能调用外部工具的AI应用的效率提升了80%以上，而2024年全球Function Calling相关的API调用量同比增长了1200%——这足以证明Function Calling已经成为AI Agent Harness Engineering（智能体工程化）中最基础、最核心、最被广泛使用的技术之一。

1.2 核心问题：Function Calling的本质是什么？它是如何让大模型「动起来」的？

在深入探讨Function Calling的技术细节之前，我们必须先明确以下8个贯穿全文的核心问题——这也是构建对Function Calling完整认知体系的关键：

本质问题： Function Calling到底是大模型的「内置能力」，还是OpenAI/Anthropic/Google等厂商「外挂给大模型的一层交互协议」？
原理问题： 为什么大模型能从一段自然语言描述（比如「明天北京有雨吗？」）中，识别出「我需要调用一个天气查询工具」？它是如何生成符合工具要求的JSON参数的？
架构问题： 一个完整的Function Calling AI Agent系统，从用户输入到输出最终结果，经历了哪些流程？每个流程的核心组件是什么？
技术细节问题： OpenAI的Function Calling和Anthropic的Tool Use有什么区别？谷歌Gemini的Native Function Calling和通过Prompt Engineering模拟的Function Calling有什么优劣？
落地问题： 在实际的AI Agent项目中，如何定义工具？如何处理工具调用失败的情况？如何让大模型自动规划多步工具调用？
数学模型问题： 工具调用的核心逻辑「意图识别+参数提取」，在大模型的预训练阶段和微调阶段是如何建模的？它背后有没有对应的数学或算法基础？
发展趋势问题： Function Calling从最初的OpenAI单步、单工具调用，发展到现在的Anthropic Claude 3 Opus多步、多工具、并行调用，未来还会有什么新的突破？
工程化问题： 如何在生产环境中优化Function Calling的延迟、成本、准确率？有没有成熟的开源框架或最佳实践？

1.3 文章脉络：从原理到实践，从底层到工程

为了系统、全面地回答上述8个核心问题，本文将按照「基础认知→历史演变→核心原理→技术对比→工程落地→未来趋势」的逻辑脉络展开，具体章节安排如下：

引言（本章）：介绍Function Calling的背景、核心问题和文章脉络；
基础概念与定义：明确Function Calling、Tool Use、AI Agent Harness Engineering等核心术语的定义，梳理Function Calling与Prompt Engineering、RAG（检索增强生成）等其他AI Agent核心技术的关系；
Function Calling的发展历史：用表格和时间轴梳理Function Calling从早期的「Prompt Engineering模拟工具调用」到现在的「原生多步并行工具调用」的完整演变过程；
核心原理解析：大模型是如何学会调用工具的？：深入探讨Function Calling的底层原理，包括大模型的「内置思维链+格式约束」机制、意图识别与参数提取的数学模型、预训练/微调阶段的设计思路；
主流大模型Function Calling技术对比：对比OpenAI GPT-4o/GPT-3.5 Turbo、Anthropic Claude 3 Opus/Sonnet、Google Gemini 1.5 Pro/Flash、Meta Llama 3的Function Calling/Tool Use技术，从功能、性能、易用性等维度进行表格化对比，并给出对应的架构图；
工程落地：从零到一构建一个多工具调用的AI Agent：通过一个完整的「个人智能助手Agent」案例，详细讲解Function Calling的工程化实现，包括项目介绍、环境安装、工具定义、系统架构、核心代码、最佳实践；
生产环境优化与最佳实践：探讨如何在生产环境中优化Function Calling的延迟、成本、准确率，处理工具调用失败、超时、参数错误等异常情况，以及安全、隐私方面的最佳实践；
行业发展与未来趋势：分析Function Calling当前的应用场景和行业痛点，展望未来的发展趋势（比如自主工具选择、动态工具注册、多Agent协作工具调用、视觉-工具-语言多模态工具调用）；
总结与延伸阅读：回顾全文的核心观点，总结Function Calling的关键技术点和工程化经验，提供相关的论文、官方文档、开源框架和学习资源。

2. 基础概念与定义

2.1 核心概念：什么是Function Calling？什么是Tool Use？什么是AI Agent Harness Engineering？

在开始深入之前，我们必须先统一术语的定义——因为在AI领域，不同的厂商、不同的资料、不同的开发者经常会用不同的术语来指代同一个概念，或者用同一个术语来指代不同的概念，这很容易造成混淆。

2.1.1 Function Calling（工具调用）的狭义与广义定义

2.1.1.1 狭义定义：OpenAI提出的「原生格式约束工具调用协议」

狭义的Function Calling，是OpenAI在2023年6月13日发布的GPT-3.5 Turbo 0613和GPT-4 0613模型中推出的一项原生功能——它允许开发者在发送给大模型的请求中，通过一个结构化的JSON格式工具列表（tools参数） 告诉大模型「你可以调用哪些工具」，大模型会根据用户的输入自动判断是否需要调用工具、调用哪个工具、需要哪些参数，然后返回一个结构化的JSON格式工具调用请求（tool_calls字段），开发者再根据这个请求去调用实际的工具，最后把工具的返回结果（tool_outputs字段）再发送给大模型，大模型会结合工具的返回结果生成最终的自然语言回答。

OpenAI官方给出的狭义Function Calling的定义是：

Function Calling is a feature that allows you to connect LLMs to external tools and APIs. You can describe functions to the model, and the model will intelligently choose to output a JSON object containing the arguments to call those functions.

为了让大家更直观地理解狭义Function Calling的流程，我们来看一个简单的OpenAI官方示例：

开发者定义工具列表（tools参数）：比如定义一个get_current_weather工具，用来查询指定城市的当前天气，工具的名称、描述、参数类型、参数要求都用结构化的JSON格式描述；
发送用户请求和工具列表给大模型：比如用户输入「What’s the weather like in Boston today?」，开发者把这个用户消息（user role）和工具列表一起发送给GPT-3.5 Turbo 0613；
大模型返回工具调用请求（tool_calls字段）：大模型会识别出「我需要调用get_current_weather工具，参数是location: "Boston, MA"」，然后返回一个包含tool_calls字段的响应；
开发者调用实际的天气API：开发者解析tool_calls字段，调用OpenWeatherMap等实际的天气API，获取波士顿的当前天气数据；
把工具返回结果发送给大模型：开发者把天气API的返回结果（用tool role的消息包裹）再发送给GPT-3.5 Turbo 0613；
大模型生成最终的自然语言回答：大模型结合工具的返回结果，生成类似「It’s currently 72 degrees Fahrenheit and sunny in Boston today.」的自然语言回答。

2.1.1.2 广义定义：所有「让大模型识别意图、提取参数、调用外部工具」的技术

广义的Function Calling（也经常被称为Tool Use），是指所有能够让大模型从自然语言输入中识别出「需要调用外部工具」的意图、提取出工具所需的结构化参数、生成工具调用指令、执行工具调用、整合工具返回结果的技术的总称——它既包括OpenAI、Anthropic、Google等厂商推出的「原生工具调用功能」，也包括早期的「Prompt Engineering模拟工具调用」、中期的「LangChain等框架封装的工具调用」。

比如，在OpenAI推出原生Function Calling之前，很多开发者就已经在用Few-Shot Prompting（少样本提示） 或Chain-of-Thought Prompting（思维链提示） 来模拟工具调用了——他们会在Prompt中给大模型举几个「自然语言输入→工具调用指令→自然语言输出」的例子，告诉大模型「当你遇到需要查询实时信息、计算复杂数学题、访问私有数据的情况时，请用指定的JSON格式生成工具调用指令，不要直接回答」。

2.1.2 Tool Use（工具使用）的官方定义

Tool Use是Anthropic在2023年10月26日发布的Claude 2.1模型中推出的原生功能——它的核心逻辑和OpenAI的Function Calling几乎完全一样，但在参数结构、多步调用支持、并行调用支持、上下文压缩等方面有一些细微的差异（我们会在第5章详细对比）。

Anthropic官方给出的Tool Use的定义是：

Tool Use lets Claude 2.1 and Claude 3 models interact with external systems, APIs, and functions to extend their capabilities beyond what’s possible with text alone.

2.1.3 AI Agent Harness Engineering（智能体工程化）的定义

AI Agent Harness Engineering是最近两年才兴起的一个新兴技术领域——它的核心目标是把通用大语言模型（LLM）、多模态大模型（MLLM）、外部工具（Tools）、知识库（Knowledge Bases）、环境感知模块（Environment Sensors）等组件组装成一个能自主感知环境、理解用户目标、规划行动步骤、执行行动、评估结果、迭代优化的完整AI Agent系统，并解决这个系统在生产环境中遇到的延迟、成本、准确率、安全、隐私、可扩展性等问题。

Function Calling/Tool Use是AI Agent Harness Engineering中最基础、最核心、最被广泛使用的组件之一——没有Function Calling/Tool Use，AI Agent就只能是一个「封闭的知识问答机」，无法和外部世界交互，无法执行实际的行动。

2.2 概念之间的关系：Function Calling与Prompt Engineering、RAG、Agent Framework的ER实体关系图与交互关系图

为了更清晰地理解Function Calling在整个AI Agent技术栈中的位置，以及它和其他核心技术的关系，我们来画两个图：一个是ER实体关系图（Entity-Relationship Diagram），用来表示概念之间的「关联关系」；另一个是交互关系图（Interaction Diagram），用来表示概念之间的「数据流和控制流」。

2.2.1 ER实体关系图：概念之间的关联关系

首先，我们来定义ER实体关系图中的实体（Entity）、属性（Attribute）、关系（Relationship）：

实体（Entity）：
- LLM/MLLM：通用大语言模型或多模态大模型，是AI Agent的「大脑」，负责自然语言理解、推理、生成、意图识别、参数提取；
- Prompt Engineering：用来引导LLM/MLLM输出符合要求的内容的技术，是AI Agent的「指挥棒」；
- RAG（Retrieval-Augmented Generation）：检索增强生成技术，用来把私有知识库的信息注入到LLM/MLLM的上下文中，是AI Agent的「记忆库」；
- Function Calling/Tool Use：工具调用技术，用来让LLM/MLLM和外部世界交互，执行实际的行动，是AI Agent的「手脚」；
- Agent Framework：用来组装LLM/MLLM、RAG、Function Calling/Tool Use等组件的开源框架，是AI Agent的「骨架」，比如LangChain、LlamaIndex、AutoGPT、AgentVerse；
- External Tools/APIs：外部工具或API，是AI Agent可以调用的「外部资源」，比如天气API、股票API、ERP系统、Python脚本、数据库、浏览器；
- Knowledge Bases：私有知识库，是AI Agent可以检索的「私有信息源」，比如企业内部文档、个人笔记、产品手册；
- Environment Sensors：环境感知模块，是AI Agent用来感知外部环境的「眼睛、耳朵、鼻子」，比如摄像头、麦克风、温度传感器、GPS定位；
- AI Agent：由上述所有组件组装而成的完整智能体系统。
关系（Relationship）：
- LLM/MLLM 使用 Prompt Engineering：Prompt Engineering用来引导LLM/MLLM的输出；
- LLM/MLLM 使用 RAG：RAG用来把私有知识库的信息注入到LLM/MLLM的上下文中；
- LLM/MLLM 使用 Function Calling/Tool Use：Function Calling/Tool Use用来让LLM/MLLM调用外部工具；
- Function Calling/Tool Use 调用 External Tools/APIs：External Tools/APIs是Function Calling/Tool Use的执行对象；
- RAG 检索 Knowledge Bases：Knowledge Bases是RAG的信息源；
- AI Agent 包含 LLM/MLLM、Prompt Engineering、RAG、Function Calling/Tool Use、Agent Framework、（可选）Environment Sensors：AI Agent是所有组件的组装体；
- Agent Framework 封装 LLM/MLLM、Prompt Engineering、RAG、Function Calling/Tool Use：Agent Framework用来简化这些组件的组装和使用。

根据上述定义，我们可以画出如下的ER实体关系图（使用Mermaid语法）：

2.2.2 交互关系图：概念之间的数据流和控制流

接下来，我们来画一个完整的多步多工具调用AI Agent的交互关系图（使用Mermaid语法的Sequence Diagram）——这个图展示了从用户输入到AI Agent输出最终结果的完整流程，包括所有核心组件之间的数据流和控制流：

 渲染错误: Mermaid 渲染失败: Parse error on line 45: ...和园散步或者去奥林匹克森林公园骑行」） ----------------------^ Expecting 'SPACE', 'NEWLINE', 'INVALID', 'create', 'box', 'end', 'autonumber', 'activate', 'deactivate', 'title', 'legacy_title', 'acc_title', 'acc_descr', 'acc_descr_multiline_value', 'loop', 'rect', 'opt', 'alt', 'par', 'par_over', 'critical', 'break', 'participant', 'participant_actor', 'destroy', 'note', 'links', 'link', 'properties', 'details', 'ACTOR', got '1'

2.3 概念核心属性维度对比：Native Function Calling vs Prompt-Engineered Function Calling vs Framework-Wrapped Function Calling

在广义的Function Calling中，根据实现方式的不同，我们可以把它分为三类：

Native Function Calling（原生工具调用）：由OpenAI、Anthropic、Google等大模型厂商直接在模型中内置的工具调用功能，比如OpenAI的Function Calling、Anthropic的Tool Use、Google Gemini的Native Function Calling；
Prompt-Engineered Function Calling（提示工程模拟工具调用）：不依赖大模型的原生工具调用功能，完全通过Few-Shot Prompting、Chain-of-Thought Prompting等提示工程技术来引导大模型生成工具调用指令；
Framework-Wrapped Function Calling（框架封装工具调用）：由LangChain、LlamaIndex等Agent Framework封装的工具调用功能——它可以同时支持Native Function Calling和Prompt-Engineered Function Calling，并且提供了很多额外的功能，比如工具注册、工具执行、异常处理、多步调用支持、并行调用支持。

为了更清晰地对比这三类Function Calling的优劣，我们来画一个核心属性维度对比表格：

核心属性维度	Native Function Calling（原生工具调用）	Prompt-Engineered Function Calling（提示工程模拟工具调用）	Framework-Wrapped Function Calling（框架封装工具调用）
实现难度	低（只需要按照厂商的要求定义工具列表，其他的都由厂商处理）	高（需要自己写复杂的Prompt，处理意图识别、参数提取、格式约束、异常处理等所有问题）	中等（框架已经封装了大部分功能，只需要按照框架的要求定义工具）
准确率	高（大模型厂商在预训练和微调阶段专门针对工具调用做了优化，意图识别和参数提取的准确率通常在90%以上）	低（完全依赖Prompt Engineering，意图识别和参数提取的准确率通常在60%-80%之间，而且很不稳定）	高（如果使用Native Function Calling作为后端，准确率和Native Function Calling一样；如果使用Prompt-Engineered Function Calling作为后端，准确率会低一些，但框架可以提供一些优化措施）
格式约束	严格（必须按照厂商指定的JSON Schema定义工具列表，工具调用请求的格式也是固定的）	灵活（可以自己定义工具调用请求的格式，比如XML、YAML、自定义JSON）	灵活（框架通常支持多种格式的工具定义和工具调用请求，并且可以自动转换格式）
多步调用支持	原生支持（OpenAI GPT-4o、Anthropic Claude 3、Google Gemini 1.5都原生支持多步调用）	不原生支持（需要自己写Prompt引导大模型一步步调用工具，处理对话历史的管理）	原生支持（框架已经封装了对话历史的管理和多步调用的逻辑）
并行调用支持	原生支持（OpenAI GPT-4o、Anthropic Claude 3、Google Gemini 1.5都原生支持并行调用多个工具）	不原生支持（需要自己写Prompt引导大模型同时调用多个工具，处理并行工具执行的逻辑）	原生支持（框架已经封装了并行工具执行的逻辑）
成本	中等（和普通的LLM调用成本一样，不需要额外付费，但工具调用会增加对话的轮数，从而增加总成本）	低（和普通的LLM调用成本一样，但需要更长的Prompt，从而增加每轮的成本）	中等（和使用的后端Function Calling的成本一样，框架本身不需要额外付费）
可扩展性	低（受限于大模型厂商的原生工具调用功能，比如最大支持的工具数量、最大支持的参数Schema复杂度）	高（完全由自己控制，可以支持任意数量的工具、任意复杂度的参数Schema）	高（框架通常支持动态工具注册，可以支持任意数量的工具、任意复杂度的参数Schema）
兼容性	低（只支持特定厂商的特定模型，比如OpenAI的Function Calling只支持GPT-3.5 Turbo 0613及以上、GPT-4 0613及以上的模型）	高（支持所有的LLM/MLLM，只要模型能理解和生成文本）	高（框架通常支持多个厂商的多个模型，可以自动切换后端）
适用场景	生产环境中的高准确率、高稳定性需求，比如客服机器人、智能助手、企业内部应用	快速原型开发、学习研究、支持所有模型的场景	大部分生产环境和原型开发场景，是目前最常用的实现方式

2.4 边界与外延：Function Calling能做什么？不能做什么？

在了解了Function Calling的定义、分类、和其他核心技术的关系之后，我们必须明确Function Calling的边界与外延——也就是它能做什么，不能做什么，避免对它产生不切实际的期望。

2.4.1 Function Calling能做什么？

Function Calling的核心能力是打破大模型的「知识时效性死锁」和「弱工具理性缺陷」，让大模型从「封闭的知识问答机」变成「能和外部世界交互的行动执行者」。具体来说，它能做以下几类事情：

查询实时/动态信息：比如查询天气、股票、新闻、航班、酒店、快递、体育赛事结果等；
访问私有/定制化信息：比如调用企业的私有ERP系统查库存、调用CRM系统查客户信息、调用内部文档系统查产品手册、调用个人笔记系统查日记等；
执行复杂的计算/操作：比如通过Python脚本计算复杂的积分、金融衍生品定价、数据分析、机器学习模型推理，通过Shell脚本打开电脑上的文件、创建文件夹、运行程序，通过数据库查询语句查询数据库中的数据等；
与外部系统交互：比如通过API订机票、订酒店、点外卖、发送邮件、发送短信、发布社交媒体内容等；
多步任务规划与执行：比如帮用户规划一次旅行（先查出发地和目的地的天气，再查机票和酒店，再查当地的旅游景点，最后生成一份完整的旅行计划）、帮用户完成一份数据分析报告（先从数据库中提取数据，再用Python脚本清洗数据、分析数据、生成图表，最后把图表和分析结果整合成一份报告）等。

2.4.2 Function Calling不能做什么？

虽然Function Calling很强大，但它并不是万能的——它有以下几个明显的边界：

不能解决大模型的「推理能力有限」的问题：Function Calling只能帮大模型获取外部信息或执行外部操作，但不能提升大模型的推理能力——如果大模型本身无法理解用户的目标、无法规划合理的步骤，那么即使有Function Calling，它也无法完成任务；
不能解决大模型的「幻觉（Hallucination）」问题：Function Calling可以减少大模型的幻觉（因为大模型可以通过调用工具获取真实的信息），但不能完全消除幻觉——大模型仍然可能会编造工具的参数、编造工具的返回结果、或者在整合工具返回结果时产生幻觉；
不能解决「安全与隐私」的问题：如果给AI Agent开放了太多的工具权限（比如可以删除电脑上的文件、可以转账、可以访问企业的敏感数据），那么一旦AI Agent被攻击或者产生错误的指令，就可能会造成严重的安全事故或隐私泄露；
不能解决「工具调用成本与延迟」的问题：每一次工具调用都会增加对话的轮数，从而增加总成本和总延迟——如果一个任务需要调用10次工具，那么总成本可能是普通LLM调用的10倍以上，总延迟也可能会达到几十秒甚至几分钟；
不能解决「工具定义不完善」的问题：如果工具的名称、描述、参数Schema定义得不够清晰、不够准确，那么大模型就可能会无法识别出需要调用这个工具、或者提取出错误的参数，从而导致工具调用失败。

（文章剩余部分将按照之前规划的章节继续撰写，包括「3. Function Calling的发展历史」「4. 核心原理解析」「5. 主流大模型Function Calling技术对比」「6. 工程落地：从零到一构建一个多工具调用的AI Agent」「7. 生产环境优化与最佳实践」「8. 行业发展与未来趋势」「9. 总结与延伸阅读」，总字数将达到10000字左右。）