LLM 工具调用三件套：Function Call、MCP 协议与 A2A 协议配置 TaoToken 实战

1. 先理清三件套到底各管什么Function Call、MCP 协议、A2A 协议经常被放在一起讲但很多人第一次接触时会混淆它们是不是互相替代的关系其实不是。你可以把它们理解成三个不同层级的“插头标准”。Function Call 解决的是“单个模型怎么调用一个函数”。模型本身不执行代码它只输出一段结构化 JSON告诉外部程序“我要调用 get_weather参数是北京”。真正执行的是你的后端代码。这是最基础的一层OpenAI、Anthropic、Mistral 等主流模型都支持。MCP 协议解决的是“模型应用怎么标准化地连接外部工具和数据源”。以前每接一个数据库、每接一个文件系统都要写一套自定义适配代码。MCP 把这个过程标准化成客户端-服务器架构主机应用通过 MCP 客户端连接 MCP 服务器用 JSON-RPC 2.0 通信。它管的是“上下文和工具的接入”。A2A 协议解决的是“多个 Agent 之间怎么互相发现和协作”。一个 Agent 可能擅长搜索另一个擅长筛选简历A2A 让它们通过 Agent Card 互相认识、通过 Task 分配工作、通过 Artifact 交付结果。它管的是“Agent 之间的通信”。三者协作边界可以用一句话概括Function Call 是模型的手MCP 是模型的工具箱接口A2A 是模型之间的对讲机。你完全可以在一个系统里同时用到三者——模型用 Function Call 触发操作应用层用 MCP 接工具多 Agent 协作用 A2A 通信。这篇要做的是用 TaoToken 作为统一的 Key 和 API 通道把这三层都跑通。TaoToken 提供统一的 API 入口你不需要为每个模型单独配 Key也不需要为每个协议单独搭通道。下面从环境准备开始一步步给出可复制的配置骨架和验证动作。2. TaoToken 前置统一 Key 与通道准备在配置任何协议之前先把 TaoToken 的接入信息准备好。这一步不复杂但顺序不能乱。首先到官网注册并登录https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。登录后进入控制台找到 API Keys 页面创建一个新的 Key。建议按用途命名比如llm-toolcall-dev方便后续排查问题时定位。创建完成后你会拿到一个以sk-开头的 Key。这个 Key 就是后续所有协议配置里统一使用的凭证。TaoToken 的 API 入口是https://taotoken.net/api注意这个地址在代码里不要加 UTM 参数保持干净。注意Key 只显示一次创建后立即复制到安全的地方。如果泄露了在控制台删除重建即可。接下来确认你要用的模型。TaoToken 支持多种模型通道Function Call 场景建议选支持工具调用的模型。你可以在模型对话页面先做一次简单测试确认 Key 和模型都能正常工作。模型对话入口https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite 。如果你打算长期做编码类 Agent 开发建议同时了解一下 Coding Plan它针对代码场景做了通道优化https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite 。环境变量建议这样设置后面所有配置都引用它export TAOTOKEN_API_KEYsk-你的Key export TAOTOKEN_BASE_URLhttps://taotoken.net/apiWindows 下用set或 PowerShell 的$env:语法。设置完可以用echo $TAOTOKEN_API_KEY确认一下。3. 可复制配置settings.json 与 config.toml 骨架这一节给出两个配置文件的完整骨架。settings.json用于 MCP 客户端侧的工具注册config.toml用于 A2A Agent 的声明与通道配置。两者都通过 TaoToken 统一走 API。3.1 settings.jsonMCP 工具注册骨架这个文件放在你的 MCP 主机应用配置目录下。不同客户端路径不同Claude Desktop 一般在~/Library/Application Support/Claude/claude_desktop_config.json其他 IDE 插件各有约定。核心结构一致{ mcpServers: { taotoken-filesystem: { command: npx, args: [ -y, modelcontextprotocol/server-filesystem, /Users/yourname/workspace ], env: { TAOTOKEN_API_KEY: sk-你的Key, TAOTOKEN_BASE_URL: https://taotoken.net/api } }, taotoken-fetch: { command: npx, args: [ -y, modelcontextprotocol/server-fetch ], env: { TAOTOKEN_API_KEY: sk-你的Key, TAOTOKEN_BASE_URL: https://taotoken.net/api } } } }这里注册了两个 MCP 服务器filesystem 用于文件读写fetch 用于网络请求。每个服务器都通过env注入 TaoToken 的 Key 和 Base URL。这样 MCP 服务器在需要调用模型能力时统一走 TaoToken 通道。如果你用的是支持 Function Call 的客户端还需要在同一个文件里声明工具 schema。以天气查询为例{ tools: [ { type: function, function: { name: get_current_weather, description: 获取指定城市的当前天气, parameters: { type: object, properties: { location: { type: string, description: 城市名称如 Beijing }, unit: { type: string, enum: [celsius, fahrenheit], default: celsius } }, required: [location] } } } ] }这个 schema 告诉模型有哪些函数可用、参数是什么格式。模型收到用户提问后会输出类似{name: get_current_weather, arguments: {location: Beijing}}的结构化 JSON你的后端解析后执行实际调用。3.2 config.tomlA2A Agent 声明骨架A2A 协议的核心是 Agent Card它描述一个 Agent 的能力、认证方式和支持的交互格式。下面是一个 TOML 格式的配置骨架用于声明一个旅行规划 Agent[agent] name travel-planner description 根据用户偏好规划行程并协调其他 Agent version 0.1.0 url https://your-domain.com/a2a/travel-planner [agent.provider] organization YourOrg url https://your-domain.com [agent.capabilities] streaming true push_notifications false [agent.authentication] schemes [bearer] credentials TAOTOKEN_API_KEY [agent.skills] [[agent.skills.items]] id plan-itinerary name 行程规划 description 根据目的地和天数生成行程 input_modes [text] output_modes [text, artifact] [[agent.skills.items]] id coordinate-weather name 天气协调 description 调用天气 Agent 获取目的地天气 input_modes [text] output_modes [text] [taotoken] base_url https://taotoken.net/api api_key_env TAOTOKEN_API_KEY model claude-sonnet这个配置声明了一个具备两个技能的 Agent行程规划和天气协调。[taotoken]段指定了该 Agent 调用模型时使用的通道。A2A 通信本身走 HTTP/SSE/JSON-RPC但 Agent 内部需要调用 LLM 时统一走 TaoToken。提示Agent Card 通常需要暴露一个/.well-known/agent.json端点其他 Agent 通过这个端点发现你的能力。生产环境记得加认证。4. 验证请求从 Function Call 到 A2A 的连通性测试配置写完后不要急着写业务逻辑先做连通性验证。分三步走先验 Function Call再验 MCP最后验 A2A。4.1 验证 Function Call 通道用 curl 直接测试 TaoToken 的 Function Call 能力curl -s https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: claude-sonnet, messages: [ {role: user, content: 北京天气怎么样} ], tools: [ { type: function, function: { name: get_current_weather, description: 获取指定城市的当前天气, parameters: { type: object, properties: { location: {type: string} }, required: [location] } } } ], tool_choice: auto }预期返回的 JSON 里choices[0].message.tool_calls应该包含一个函数调用请求function.name是get_current_weatherarguments里包含{location: Beijing}。如果返回的是普通文本而不是 tool_calls说明模型或通道不支持 Function Call需要换模型或检查配置。4.2 验证 MCP 服务器连通性MCP 服务器启动后用 JSON-RPC 格式发一个初始化请求echo {jsonrpc:2.0,id:1,method:initialize,params:{protocolVersion:2024-11-05,capabilities:{},clientInfo:{name:test,version:1.0}}} | npx -y modelcontextprotocol/server-filesystem /tmp如果服务器正常会返回包含serverInfo和capabilities的 JSON。接着测试tools/list方法echo {jsonrpc:2.0,id:2,method:tools/list,params:{}} | npx -y modelcontextprotocol/server-filesystem /tmp返回的result.tools数组里应该列出该服务器提供的所有工具。如果这一步通了说明 MCP 客户端-服务器链路正常。4.3 验证 A2A Agent Card 可发现启动你的 A2A Agent 后用 curl 请求 Agent Cardcurl -s https://your-domain.com/.well-known/agent.json | jq .预期返回的 JSON 包含name、description、skills、capabilities等字段。然后用 A2A 的tasks/send方法发一个测试任务curl -s https://your-domain.com/a2a/travel-planner \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { jsonrpc: 2.0, id: task-001, method: tasks/send, params: { id: task-001, message: { role: user, parts: [{type: text, text: 帮我规划北京三日游}] } } }如果返回的result.status.state是submitted或working说明 A2A 任务接收正常。后续可以通过tasks/get轮询状态或通过 SSE 接收流式更新。5. 本篇常见错排查配置过程中最容易踩的坑集中在几个地方这里按出现频率排列。第一个坑Key 没传进 MCP 服务器的 env。很多人只在 shell 里 export 了 Key但 MCP 服务器是独立进程启动的不会继承 shell 环境变量。必须在settings.json的env段显式传入。验证方法在 MCP 服务器代码里打印process.env.TAOTOKEN_API_KEY看是否有值。第二个坑Base URL 带了多余路径。TaoToken 的 API 入口是https://taotoken.net/api有些客户端会自动拼接/v1/chat/completions有些需要你手动写全。如果遇到 404先检查最终请求的完整 URL 是什么。建议在客户端开启请求日志。第三个坑Function Call 的 tool_choice 设置不对。tool_choice: auto让模型自己决定是否调用函数tool_choice: {type: function, function: {name: xxx}}强制调用指定函数。如果你希望模型必须调用某个函数用后者。如果模型返回了文本而不是 tool_calls先检查tool_choice和模型是否支持。第四个坑A2A 的 Agent Card 路径不对。A2A 规范约定 Agent Card 放在/.well-known/agent.json但有些实现放在/agent.json或/a2a/agent.json。发现不了 Agent 时先确认对方请求的路径和你暴露的路径是否一致。第五个坑MCP 服务器权限问题。filesystem 服务器需要指定允许访问的目录如果目录不存在或没有读写权限服务器会启动失败。用ls -la确认目录存在用chmod确认权限。第六个坑A2A 任务状态轮询超时。A2A 支持长时间运行任务但客户端默认超时可能很短。如果任务状态一直是working检查客户端超时设置或者改用 SSE 流式接收更新。6. 接入文档与后续动作三件套跑通后下一步是根据你的实际场景做扩展。如果你主要做工具接入和排障建议先把 API Keys 管理和接入文档过一遍确保 Key 轮换和权限控制有章法。API Keys 入口https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite 。接入文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 。如果你更关注模型本身的工具调用能力验证直接在模型对话页面测试不同模型的 Function Call 表现是最快的https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite 。如果你打算长期做编码类 Agent 或多 Agent 协作开发Coding Plan 提供了针对代码场景优化的通道配置可以减少你在通道调试上的时间https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite 。最后说一个实际经验Function Call、MCP、A2A 这三层不要一次性全上。先把 Function Call 跑通确认模型能正确输出结构化调用请求再加 MCP把工具接入标准化最后才考虑 A2A 的多 Agent 协作。每层都单独验证通过后再叠加排查问题时才能快速定位是哪一层出了状况。配置文件和验证命令都在上面了直接复制改改就能用。