1. 从手动调工具到模型自主规划MCP Function Calling 到底解决什么问题如果你已经用过 MCPModel Context Protocol把本地或远程工具挂到模型上大概率经历过这个阶段工具能跑通但每次都得自己判断该调哪个、传什么参数、结果怎么塞回上下文。MCP 负责把工具标准化暴露出来Function Calling 负责让模型输出结构化的调用意图这两者拼在一起才是真正的模型自主驱动工具链。这篇要做的场景很具体让模型自己完成一条三步依赖链——先拿到本机公网出口 IP再用这个 IP 反查城市和经纬度最后用经纬度查实时天气。三步里每一步的返回值都是下一步的输入参数中间不需要人工干预。用户只说一句话模型自己规划顺序、自己填参数、自己判断什么时候停。适合谁看已经了解 MCP 基础用法知道怎么注册一个 HTTP 工具、怎么手动 run 一次但还没把工具清单交给模型去决策的开发者。如果你还在用把工具结果拼进 Prompt 再问一遍的土办法这篇的循环结构会帮你省掉大量胶水代码。核心检索词先摆出来MCP 工具链、Function Calling schema、多步推理、ToolCall 循环、统一 Key 接入。这几个词贯穿全文后面每一段配置和代码都围绕它们展开。我试过把三个工具写死在代码里按顺序调能跑但一旦工具增减或顺序变化就得改代码。换成 Function Calling 之后工具清单从配置文件读模型自己决定调谁扩展成本几乎为零。下面从接入通道开始一步步把这条链路搭起来。2. TaoToken 统一 Key 与 API 通道MCP 工具链的前置接入配置在写循环之前先把模型通道固定下来。多步推理对模型的 Function Calling 支持要求比较高——它得能稳定输出结构化的 tool_calls 字段而不是把调用意图混在自然语言里。TaoToken 在这里的作用是提供一个统一的 OpenAI 兼容入口你换模型时不用改鉴权逻辑Base URL 和 Key 保持不变只换 Model ID 就行。接入信息如下建议直接抄官网入口https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentAPI 基址https://taotoken.net/api模型对话调试页https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewriteAPI 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如果你用的是 Claude Code 这类编码 Agent长期跑工具链建议走 Coding Plan额度更稳https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite拿到 Key 之后先别急着写 Java 循环用最简请求验证通道能不能正常返回 tool_calls。这一步很关键很多人后面循环跑不通其实是通道层就没开 Function Calling。用 curl 测一下curl https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: qwen3.6-plus, messages: [{role: user, content: 现在几点}], tools: [{ type: function, function: { name: get_current_time, description: 获取当前时间, parameters: {type: object, properties: {}} } }], tool_choice: auto }返回体里如果出现choices[0].message.tool_calls说明通道支持结构化调用如果只有content字段说明当前模型或参数没走 Function Calling 路径需要换模型或检查tools字段格式。注意Base URL 填https://taotoken.net/api不要带/v1后缀再拼一次OpenAI SDK 通常会自动补/v1/chat/completions。填错会出现 404 或路径重复。统一 Key 的好处在这里体现得很明显MCP 服务端配置、Function Calling 请求、日志排查用的都是同一套鉴权不用在多个平台之间同步密钥。下面进入可复制的配置环节。3. 可复制配置MCP 服务端声明与 Function Calling schema 落地这一节给两份可直接用的配置。第一份是 MCP 工具声明第二份是模型侧需要的 Function Calling schema。两者字段要对齐否则模型输出的工具名在 MCP 侧找不到。先看 MCP 服务端配置mcp.config.json三个工具都放在default分组里{ default: { tools: [ { name: get_export_ip, description: 获取本机公网出口 IP 地址, method: GET, url: https://api.ipify.org?formatjson, parameters: { type: object, properties: {}, required: [] } }, { name: get_ip_location, description: 根据 IP 查询城市、经纬度、ISP 信息, method: GET, url: https://ipapi.co/{ip}/json/, parameters: { type: object, properties: { ip: {type: string, description: 要查询的公网 IP} }, required: [ip] } }, { name: get_weather_open_meteo, description: 根据经纬度查询实时天气, method: GET, url: https://api.open-meteo.com/v1/forecast?latitude{latitude}longitude{longitude}current_weather{current_weather}, parameters: { type: object, properties: { latitude: {type: number, description: 纬度}, longitude: {type: number, description: 经度}, current_weather: {type: string, description: 是否返回实时天气传 true} }, required: [latitude, longitude, current_weather] } } ] } }这份配置的关键点是parameters字段本身就是标准 JSON Schema可以直接转成模型需要的 tools 数组。manifestForInput()做的就是这件事——把 MCP 声明翻译成 Function Calling schema避免手写两份。如果你用 Cline 或 Claude Code 的 MCP 配置写法类似但要注意三件套必须齐全Base URL、Key、Model ID。缺任何一个都会在启动时报鉴权或模型不存在。以 Cline 的 MCP settings 为例{ mcpServers: { taotoken-tools: { command: npx, args: [-y, taotoken/mcp-server], env: { TAOTOKEN_BASE_URL: https://taotoken.net/api, TAOTOKEN_API_KEY: sk-你的Key, TAOTOKEN_MODEL_ID: qwen3.6-plus } } } }Codex 用户如果走auth.json结构是{ base_url: https://taotoken.net/api, api_key: sk-你的Key, model: qwen3.6-plus }三件套对齐之后模型侧拿到的 tools 数组长这样由 manifest 自动生成这里展示结构[ { type: function, function: { name: get_export_ip, description: 获取本机公网出口 IP 地址, parameters: {type: object, properties: {}, required: []} } }, { type: function, function: { name: get_ip_location, description: 根据 IP 查询城市、经纬度、ISP 信息, parameters: { type: object, properties: {ip: {type: string}}, required: [ip] } } } ]配置阶段最容易踩的坑是工具名不一致MCP 里叫get_ip_locationschema 里写成getIpLocation模型输出后执行器找不到对应工具直接抛异常。建议用同一份配置生成两边别手抄。提示current_weather参数在 Open-Meteo 里是布尔语义但 JSON Schema 里用 string 传 true 也能被接受。如果你追求严格类型改成type: boolean并在执行器里做转换。配置就绪后进入验证环节看模型是否真的按顺序调了三次工具。4. 验证请求与成功结果多步推理链路的完整日志验证的目标很明确发一句话看模型是否自主完成三次 ToolCall且每次的参数来自上一步的返回值。请求体如下curl https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: qwen3.6-plus, temperature: 0, messages: [ {role: system, content: 你是能调用 MCP 工具的智能体。按顺序1) 调 get_export_ip 拿公网 IP2) 把 IP 传给 get_ip_location 拿城市和经纬度3) 用经纬度调 get_weather_open_meteo 并设 current_weathertrue4) 只输出位置和天气结论。}, {role: user, content: 自动检测我的公网 IP推断所在城市并告知当前天气。} ], tools: [ ...上节的 tools 数组... ], tool_choice: auto }第一轮返回会是tool_calls包含get_export_ip参数为空对象。执行器拿到后调 MCP把结果以role: tool的消息追加回 messages再发第二轮。第二轮模型看到 IP 后输出get_ip_location的调用参数里带上真实 IP。第三轮同理输出天气查询。第四轮模型不再输出 tool_calls直接给最终回答。完整日志轨迹应该类似这样[MCP Function-Calling 链开始] [ToolCall] get_export_ip params - {} [Observation] {ip:123.117.177.40} [ToolCall] get_ip_location params - {ip:123.117.177.40} [Observation] {city:Dongcheng Qu,latitude:39.9117,longitude:116.4097,org:AS4134 Chinanet} [ToolCall] get_weather_open_meteo params - {latitude:39.9117,longitude:116.4097,current_weather:true} [Observation] {current_weather:{temperature:18.3,windspeed:6.1,weathercode:1}} [链执行完成] 最终回答 你的公网 IP 位于中国北京市东城区当前温度约 18°C天气晴朗风速 6.1 km/h。判断链路是否健康看三个信号一是 ToolCall 次数等于依赖步数这里是 3多了说明模型在重复调少了说明它跳步二是每次 Observation 都被写回 messages否则下一轮模型看不到上一步结果三是最终回答里没有暴露工具名说明 System Prompt 的约束生效了。如果模型在第二轮没有输出get_ip_location而是直接编了一个城市说明它没把 Observation 当回事。这时候检查两点Observation 是否以标准role: tool消息追加以及tool_call_id是否和上一轮tool_calls[].id对应。对不上模型会认为这条结果不属于它的调用直接忽略。验证通过后把循环封装成函数maxIterations设 5 就够防止模型陷入死循环。退出条件很简单某一轮返回的 message 里没有tool_calls字段就说明模型准备给最终答案了。5. 本篇常见错误排查401、local proxy failed 与 reading choices 报错多步链路跑不通报错通常集中在几个固定位置。下面按真实报错对照排查。401 UnauthorizedKey 没带上或格式不对。检查Authorization: Bearer sk-xxx里 Bearer 后面有没有空格Key 有没有被 shell 变量吞掉。用echo $TAOTOKEN_API_KEY确认变量非空。如果走 MCP 服务端检查env里的TAOTOKEN_API_KEY是否传进了子进程。local proxy failed / connection refused本地 MCP 服务没起来或者端口被占。先单独跑一次 MCP server 看能否启动再确认客户端配置里的command和args路径正确。这类错误和网络通道无关纯粹是本地进程问题。reading choices 报错cannot read property choices of undefined请求返回体不是预期的 OpenAI 格式通常是 Base URL 拼错导致打到了别的路径或者模型名不存在返回了错误对象。打印完整响应体看error字段。Base URL 用https://taotoken.net/api模型名从文档里抄别自己拼。OAuth 相关报错多见于 Claude Code 或 Codex 的登录态配置。如果你用的是 API Key 模式确保没有残留的 OAuth token 覆盖。检查auth.json或环境变量里是否同时存在两套鉴权冲突时优先 API Key。工具名找不到tool not found模型输出的function.name和 MCP 注册名不一致。打开日志对比两边字符串注意大小写和下划线。建议在manifestForInput()之后打印一次工具名列表和模型输出对照。参数解析失败invalid arguments模型输出的arguments是 JSON 字符串需要先JSON.parse再传给 MCP。如果直接当对象用会报类型错误。另外注意模型有时会输出带换行的 JSON解析前先 trim。循环不退出模型反复调同一个工具。检查 System Prompt 里有没有每个工具最多执行一次的约束以及maxIterations是否生效。温度设 0 能显著降低这种抖动。排查顺序建议从通道层往上先用 curl 确认 API 通再确认 MCP 单工具能跑最后才看循环逻辑。跳步排查容易在错误层浪费时间。6. 把工具清单交给模型统一 Key 驱动工具链的落地建议整条链路的核心只有一句话把 MCP 工具清单转成 Function Calling schema 交给模型模型决定调什么执行器只负责执行和回写结果。开发者不再写如果 A 则调 B的分支扩展工具时只改配置文件。落地时有几个实用建议。第一System Prompt 里明确调用顺序和次数上限能大幅降低模型跳步和重复调用的概率尤其在依赖链场景下。第二Observation 一律以标准 tool 消息回写带上tool_call_id这是模型识别结果归属的唯一依据。第三工具执行失败时不要把异常直接抛出而是把错误信息作为 Observation 写回让模型自己决定重试还是降级这样单点失败不会炸掉整条链。统一 Key 的价值在长期维护里更明显MCP 配置、Function Calling 请求、日志排查共用一套鉴权和 Base URL换模型只改 Model ID。如果你要长期跑编码类 Agent 或复杂工具链走 Coding Plan 额度更稳临时验证模型行为用模型对话页最快。最后留一个可复用的检查清单Base URL 是否为https://taotoken.net/api、Key 是否有效、Model ID 是否支持 Function Calling、工具名两边是否一致、Observation 是否带 tool_call_id、maxIterations 是否设置。这六项过了多步推理链路基本不会出问题。