智能体｜Agent Tool Use 技术演进路线

工具是大模型与环境交互的主要媒介，使用工具的技术经历了三次“正规”的升级换代。从给大模型加上工具调用函数 Function calling，到模型与工具交互标准MCP，再到把智能体当工具，多智能体之间的通信协议A2A，每种方式都有各自的痛点和适用场景。围绕Agent的工具使用技术介绍

1）工具使用的初级阶段 prompt工程。 2）Function calling 和 MCP 让工具使用进入发展快车道。 3）多智能体之间的通信方式 A2A

关注“AI老马” —【获取资源】&【进群交流】

1，prompt 工程调用

大模型完成一次任务，需要两个关键的问题的解决。是否需要调用工具，以及调用那个工具。

打怪小强开始上线，初级解决方式： prompt 工程

即，在 system prompt 中增加 tools 列表及对应描述。这样大模型就知道有哪些工具可以调用了，同时根据用户的问题能够自行判断是否需要调用外部工具，若需要则从用户问题或任务和相关的上下文中解析参数，然后以固定格式（一般为JSON) 返回函数调用命令。

此种方式简单易于实现，常用于快速验证工具效果和单一简单场景任务。

痛点：强依赖模型理解和推理能力！

• • 如果使用能力较弱的小模型，无法每次都给出使用正确工具的判断。
• • 存在即使明确要求输出 JSON，仍然出现语法错误、转义字符错误、多冗余文本，参数适配等等的问题。

最终导致简单任务失败率很高，模型仿佛吃了“弱智丸”一样！

在系统prompt 中给出了函数 get_weather 的使用方式，需要两个参数，“city"：必须传参，"date"：非必须，默认使用当天，相关的使用也在示例中给出。

假如大模型收到用户提问：“查询下北京今天天气”最终返回的结果：

{"too1":"get_weather", 
"params"：{
  "city"：“北京”，
  "date"："2024-01-19"
    }
}

模型根据问题找到正确的工具，并且从问题中解析出参数，最终以JSON 形式返回了调用请求，Agent收到这个JSON 格式信息后就可以真正的调用天气API去查询天气了。

2，Function Calling 函数调用

使用prompt 工程调用工具确实风险较大，不是一名经验丰富的 牛马 老程序员的调性！那Function Calling 是一个进阶的选择。

Function Calling 是大模型厂商（如OpenAl、Anthropic等) 通过微调或架构优化，赋予模型生成结构化指令的能力，模型能精准匹配预定义函数，而非依赖自然语言生成，使得工具调用“稳如老狗”。

注意：Function Calling 本身没有统一协议，不同厂商实现方式不同（如 OpenAl 的 tools 参数、Claude的 tool_use 字段）。这也是为什么后面又推出了标准化的MCP协议，统一工具调用流程的重要原因。

图1，function calling 的工作流

Function Calling 的一般流程：

• • 用户定义 Tools 并告知 LLM
• • LLM 根据拿到的Tools 信息判断需要调用哪个工具，并生成对应 JSON 格式调用请求
• • 大模型根据请求调用具体工具
• • 将调用结果返回 LLM，整合结果返回最终结果

Function Calling 起步相对容易，只需按照 API 要求定义函数规格（通常 JSON 模式）并将其随请求发送，模型就可能按照需要调用这些函数，逻辑较直观。因此，对于单一模型、少量功能的简单应用，Function Caling 实现起来非常直接，几乎“一键”将模型输出对接到代码逻辑中。

但是，它的局限在于缺乏跨模型的一致性，每个LLM 供应商的接口格式略有差异，开发者若想支持多个模型，需要为不同 API做适配或使用额外框架处理。

例如，如果有M个不同LLM应用和N个不同工具/服务，理论上可能需要实现 MxN次重复的对接工作。此外，对于函数的链式调用，Function Calling 本身并不直接支持多步调用组合，模型只能一次调用一个函数，获取结果后如果需调用下一个函数，需要由应用逻辑将结果馈入模型下一轮对话，再触发下一个函数调用。虽然在原理上可以实现函数输出作为输入形成链条，但这一切需要开发者在应用层精心编排，模型自身缺乏对跨调用流程的全局观。

小结：Function Calling 和 System Prompt 的区别

• • System Prompt 主要依赖于模型的自然语言生成能力，不够稳定，此时的模型只是根据Prompt 生成返回。
• • Function Calling 则是直接对模型进行微调，从而赋予模型生成结构化指令的能力，更加准确。此时的模型经 过特殊的微调，能够更好的处理这种需求，因此能够更加精准的匹配预定义函数

更多实际用例，请参考文末给出的openai官方链接。

3，MCP 模型上下文协议

Function Calling 不能解决一对多的适配问题，那必须整点“花活”才能在大模型工具调用这一块“游刃有余”！

MCP（Model Context Protocol）是 Anthropic 提出的协议，旨在解决不同大模型与不同外部工具集成的标准化问题。官方给了一个形象的比喻，MCP 像是一个用户AI应用级的 USB-C，它可以通过标准协议的方式连接任何的外部AI应用。

从架构上来说，MCP采用了客户端-服务器架构，主要包括以下几个核心组件：

图2，MCP 客户端-服务器架构图。

• • MCP 主机 (Hosts)：

这是需要访问数据的程序，如Claude Desktop、各种IDE 或AI工具。它们是MCP生态系统的入口点，负责向用户提供AI功能。

• • MCP 客户端(Clients)：

这些是协议客户端，负责维持与MCP 服务器的 1:1连接。它们处理通信细节，确保主机和服务器之间的数据传输顺畅。

• • MCP 服务器(Servers)：

这些是轻量级程序，每个服务器都通过标准化的 Model Context Protocol 暴露特定功能。服务器是 MCP的核心，它们连接 AI模型与实际数据源。

数据源，包括两类：

• • 本地数据源：

您计算机上的文件、数据库和服务，MCP 服务器可以安全访问这些资源

• • 远程服务：

通过互联网可用的外部系统 （如通过 API)，MCP服务器可以连接这些系统

这些组件共同工作，形成了一个完整的生态系统，让Al模型能够安全、高效地访问各种数据和工具

通过以上的讲解感觉MCP还是懵的！不如 prompt 工程和 function calling 来的实在。所以一般的工程小项目可以先采用简单的方式实现。过于复杂的工程，可以考虑采用MCP 方式。

不过，为了方便文末提供了官方快速上手的链接。

4, A2A 智能体间通信

有的博客上讲A2A就是炒作起来的概念，是Function Calling 和 MCP 的再次包装，既然它火起来了，也需要稍微的了解下，毕竟别人滔滔不绝 A2A 的时候，沉默的你倒显得不解风情。

图3，A2A交互示意图

A2A（Agent to Agent）解决是Agent 之间通信的问题，是一项开放标准，可让不同平台和框架之间的Al Agent 进行通信和协作，而无需考虑其底层技术。

Agent可以调用不同的工具，为什么还需要多个Agent？

因为构建一个能解决所有问题的Agent 很难，或者说基本不可能实现，因此一般选择多Agent 分工协作，每个 Agent 只需要专注某一方面解决，通过A2A让多个不同领域的Agent 协作解决问题，多个Agent 构成流水线共同完成某个任务。

又有人问了 ”如果把Agent 弱化成函数或者工具，那同样面临多个Agent 如何通信的问题吧？“

这时候A2A登场了（其实更像是进阶版的MCP）。A2A像一门统一的语言，让Agent ”说人话“，清晰的传递意图、协商任务、共享信息。能够连接任何其它的基于 A2A构建 Agent，并使用户能够灵活组合来自不同供应商的Agent。最重要的是，企业可以通过标准化方法管理其跨不同平台和云环境的 Agent。

A2A是一种开放标准，可让不同平台和框架之间的Al Agent进行通信和协作，而无需考虑其底层技术的协议。Agent 之间通过 A2A协议通信，Agent 通过 MCP协议调用外部工具

总结：

本文主要介绍了下，当前使用工具的几种主要方式，概念性的东西，没有涉及太多的实操，因为每一个单拎出来，都要讲好几天。做工程要找最合适的方法，如果function calling 能满足项目当前的需求，那就投入时间重点上手实践下，没必要使用MCP 和A2A 徒增项目的复杂性，还有MCP 和A2A 的学习成本还是有一些的。

参考资料：

https://ai-doc.it-docs.cn/docs_en/guides_function-calling#examples
https://docs.mcpcn.org/quickstart/server