1. 为什么 Function Call 写多了会崩一个咖啡机场景如果你用 Python 接过三个以上外部 API大概率经历过这种崩溃每个接口一套参数命名美团叫cup_size饿了么叫size_code星巴克叫size接口一升级所有调用点全红。Function Call 本身没问题它解决的是让模型知道有哪些函数可调但它不解决函数背后怎么统一管理、怎么复用、怎么发现。我把它类比成办公室咖啡机。Function Call 像是你手把手教每个新同事美式按哪个键、拿铁先按哪个再按哪个、糖度怎么调。人一多、机器一换教学成本爆炸。MCPModel Context Protocol想做的事是给办公室装一台智能咖啡机——你只需要说来杯美式它自己去匹配豆子、水温、杯型甚至自动选最便宜的那家供应商。这篇面向 Python 开发者把 Function Call 和 MCP 的协作方式讲清楚Function Call 负责模型决定调什么MCP 负责这个调用怎么标准化地落到真实服务上。我会给一套可复制的 MCP 服务端骨架、Function Call 调试验证动作以及通过 TaoToken 统一 Key/API 通道接入的方式。适合已经写过 Function Call、但被多接口维护折磨过的同学。2. 前置准备TaoToken 统一 Key 与 API 通道在动手写 MCP 服务端之前先把模型侧的通道理顺。MCP 服务端负责工具执行但工具调用往往需要模型先产出结构化参数这就需要一个稳定的模型 API 入口。TaoToken 在这里的角色是统一 Key 和 API 通道省去你在多个模型供应商之间来回切换配置。官网入口https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentAPI 基址不带 UTMhttps://taotoken.net/api你需要先拿到 API Key再去配置模型调用。拿 Key 的路径在控制台里具体入口控制台https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewriteAPI Keys 管理https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite拿到 Key 后建议先做一次最小验证确认通道可用再往下写 MCP。验证模型是否正常可以直接用模型对话页面模型对话https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel-chatutm_campaignrewrite如果你后续要做长期编码或 Agent 类项目Coding Plan 会更省心Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite接入文档在这里配置参数以文档为准接入文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite注意API Key 只放在环境变量里不要硬编码进 MCP 服务端源码更不要提交到 Git。这是后面排障章节里最常见的翻车点之一。3. 可复制配置MCP 服务端骨架 Function Call 调试3.1 环境搭建用 uv 管理虚拟环境比裸 pip 快且干净。Windows 和 macOS 通用# 安装 uv curl -LsSf https://astral.sh/uv/install.sh | sh # 创建并激活虚拟环境 uv venv mcp-demo source mcp-demo/bin/activate # Windows 用 mcp-demo\Scripts\activate # 安装依赖 uv pip install mcp[cli] httpx pydantic loguru openai这里openai库是用来走 TaoToken 的兼容接口mcp[cli]是 MCP 官方 SDKpydantic做参数校验loguru做日志。3.2 模型通道配置把 TaoToken 的 Key 和基址写进环境变量export TAOTOKEN_API_KEY你的Key export TAOTOKEN_BASE_URLhttps://taotoken.net/api然后在 Python 里初始化客户端import os from openai import OpenAI client OpenAI( api_keyos.environ[TAOTOKEN_API_KEY], base_urlos.environ[TAOTOKEN_BASE_URL], ) resp client.chat.completions.create( modelgpt-4o-mini, # 具体模型名以接入文档为准 messages[{role: user, content: 只回复 ok}], ) print(resp.choices[0].message.content)这一步能打印出ok说明模型通道通了。如果报 401先回去检查 Key 是否复制完整如果报连接错误检查 base_url 是否写成了带路径的地址。3.3 MCP 服务端骨架下面是一个咖啡采购MCP 服务端骨架核心是把不同平台的参数差异收敛到一个工具里。注意参数用 Pydantic 模型校验避免非法输入。from mcp.server import Server from mcp.server.stdio import stdio_server from mcp.types import Tool, TextContent from pydantic import BaseModel, Field import httpx from loguru import logger class BuyCoffeeParams(BaseModel): coffee_type: str Field(..., description咖啡类型如 美式/拿铁) size: str Field(..., description杯型如 中杯/大杯) app Server(coffee-service) PLATFORM_PARAMS { meituan: lambda p: {product_type: p.coffee_type, cup_size: p.size}, eleme: lambda p: {coffee_type: p.coffee_type.upper(), size_code: fSIZE_{p.size}}, } async def select_platform() - str: # 真实场景里做比价/比时效这里简化 return meituan async def unified_order(params: BuyCoffeeParams) - str: platform await select_platform() payload PLATFORM_PARAMS[platform](params) logger.info(f路由到 {platform}参数 {payload}) async with httpx.AsyncClient(timeout10) as c: # 这里换成真实下单地址 resp await c.post(https://example.com/order, jsonpayload) return resp.text app.list_tools() async def list_tools(): return [ Tool( namebuy_coffee, description统一咖啡采购自动适配不同平台参数, inputSchemaBuyCoffeeParams.model_json_schema(), ) ] app.call_tool() async def call_tool(name: str, arguments: dict): if name ! buy_coffee: raise ValueError(f未知工具: {name}) params BuyCoffeeParams(**arguments) result await unified_order(params) return [TextContent(typetext, textresult)] async def main(): async with stdio_server() as (read, write): await app.run(read, write, app.create_initialization_options()) if __name__ __main__: import asyncio asyncio.run(main())关键点inputSchema直接由 Pydantic 模型生成模型侧看到的参数定义和服务端校验用的是同一份不会出现模型传了 size服务端要 cup_size的错位。3.4 Function Call 调试验证MCP 服务端跑起来后用 Function Call 做一次端到端验证。把工具定义喂给模型看它能否产出正确参数tools [{ type: function, function: { name: buy_coffee, description: 统一咖啡采购, parameters: BuyCoffeeParams.model_json_schema(), }, }] resp client.chat.completions.create( modelgpt-4o-mini, messages[{role: user, content: 帮我买一杯大杯美式}], toolstools, tool_choiceauto, ) msg resp.choices[0].message if msg.tool_calls: call msg.tool_calls[0] print(模型决定调用:, call.function.name) print(参数:, call.function.arguments) else: print(模型没有触发工具调用检查 description 是否清晰)预期输出类似模型决定调用: buy_coffee 参数: {coffee_type: 美式, size: 大杯}拿到参数后再把它交给 MCP 服务端的call_tool执行整条链路就闭环了。这一步的意义是模型只负责决定调什么、传什么参数MCP 负责怎么执行、怎么适配平台。4. 验证请求与成功结果把上面的流程串成一个可运行的验证脚本确认三件事模型通道通、工具定义被识别、参数能落到服务端。import json from mcp.server import Server # 1. 模型通道验证 assert client.chat.completions.create( modelgpt-4o-mini, messages[{role: user, content: ping}], ).choices[0].message.content # 2. 工具定义验证 schema BuyCoffeeParams.model_json_schema() assert coffee_type in schema[properties] assert size in schema[properties] # 3. 参数解析验证 params BuyCoffeeParams(**json.loads({coffee_type:美式,size:大杯})) assert params.size 大杯 print(三项验证通过链路可用)成功结果表现为模型返回tool_calls参数 JSON 能被 Pydantic 正常解析服务端日志打印出路由平台和转换后的参数。如果模型不触发工具调用优先检查description是否写得太模糊——这是 Function Call 最常见的沉默失败。5. 本篇常见错排查5.1 模型不触发工具调用现象msg.tool_calls为空。原因通常是工具description太笼统或者用户问句和工具能力不匹配。解决把 description 写成什么时候该用我比如当用户要买咖啡、下单饮品时调用而不是只写咖啡采购。5.2 参数名对不上现象服务端报ValidationError提示缺少字段。原因模型侧看到的 schema 和服务端 Pydantic 模型不是同一份。解决统一用model_json_schema()生成不要手写两套参数定义。5.3 401 / 连接错误现象模型调用直接报鉴权失败或连接超时。原因Key 没放进环境变量、base_url 写错、或者把带路径的地址当成了基址。解决确认TAOTOKEN_BASE_URL是https://taotoken.net/apiKey 从 API Keys 页面重新复制。接入细节以接入文档为准。5.4 同步客户端拖垮并发现象并发一上来服务端就卡死。原因用了同步httpx.Client或requests。解决MCP 服务端统一用httpx.AsyncClient所有工具函数写成async def。5.5 服务发现没有心跳现象某个下游平台挂了请求一直超时。原因没有健康检查故障节点还在被路由。解决在select_platform里加一层心跳检测把连续失败的平台临时剔除。6. 下一步把通道和工具都管起来Function Call 和 MCP 不是替代关系。Function Call 让模型能点单MCP 让点单标准化地落到真实服务。你要做的是把模型通道和工具执行分开管理模型通道用 TaoToken 统一 Key工具执行用 MCP 服务端收敛参数差异。如果你还在排障阶段先把 API Keys 和接入文档过一遍API Keyshttps://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite接入文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite如果你要验证模型是否正常产出工具参数用模型对话页面快速试模型对话https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel-chatutm_campaignrewrite如果你打算长期做编码或 Agent 类项目直接上 Coding Plan省去每次手动配通道的麻烦Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite最后留一个我踩过的坑MCP 服务端的日志一定要打全尤其是路由到哪个平台、转换后的参数长什么样。Function Call 出问题时模型侧往往只告诉你调用了工具真正的原因藏在服务端日志里。把日志打清楚排障时间能砍掉一半。