1. 从一次“模型不听话”说起Function Calling、MCP、Skills 到底解决什么问题刚接触大模型LLM的开发者最容易卡在同一个地方模型能聊天但一到“帮我查一下明天北京天气再算一下出差补贴”这种需要真实动作的任务就开始胡编。这不是模型笨而是它缺三样东西——调用函数的能力、连接外部工具的标准、以及按流程办事的说明书。这三样东西正好对应 Function Calling、MCP、Skills。先把三个概念用一句话钉死方便你后面检索Function Calling 是模型“决定调用哪个函数、并生成参数”的能力本质是自然语言到结构化调用的翻译层。MCPModel Context Protocol模型上下文协议是一套开放标准让 LLM 应用和外部数据源、工具之间用统一接口对接类似 USB-C 把各种设备统一起来。Skills 则是用 Markdown 文档加脚本告诉模型“这件事按什么顺序做、遵守什么规则”相当于给模型一本菜谱。适合谁看如果你写过几行 Python、调过任意一家大模型的 API但还没把“模型 工具”跑通这篇就是给你的。我会用 TaoToken 作为统一的 Key 和 API 通道把三个能力串成一条可复现的路径先配好环境再跑通 Function Calling然后接一个 MCP Server最后用 Skills 约束调用顺序。全程给可复制的配置和最小验证脚本你照着敲就能看到结果。为什么强调“统一通道”因为初学者最容易被劝退的环节不是写代码而是同时管理好几家的 Key、Base URL、模型名还要处理不同 SDK 的差异。把入口收敛成一个你才能把注意力放在能力本身。下面所有示例的 Base URL 都用https://taotoken.net/apiKey 在控制台生成模型 ID 按你实际开通的填。2. 前置准备在 TaoToken 拿到统一 Key 与 API 通道这一章的目标很明确让你手里有一个能用的 Key、一个 Base URL、一个模型 ID并且知道它们分别填在哪里。很多教程跳过这步直接贴代码结果读者卡在 401所以我把配置讲透。先注册并登录控制台地址是https://taotoken.net/console。进去之后找 API Keys 页面路径是https://taotoken.net/api-keys点创建复制那串以sk-开头的字符串。注意Key 只在创建时完整显示一次关掉页面就看不到了建议先粘到本地临时文件。模型 ID 在模型列表里看比如你开通的是通用对话模型就记下对应的 ID 字符串。Base URL 统一用https://taotoken.net/api注意末尾不要多加斜杠OpenAI 兼容的 SDK 会自动拼接/v1/chat/completions这类路径。如果你用的是 Claude Code 这类命令行工具或者 Cline、CC Switch 这类编辑器插件配置项通常有三件套Base URL、API Key、Model ID。以 Claude Code 的 settings 为例配置文件一般放在~/.claude/settings.json写入下面这段把 Key 和模型 ID 换成你自己的{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_API_KEY: sk-你的Key, ANTHROPIC_MODEL: 你的模型ID } }如果你用的是 Codex 系的工具认证信息常写在~/.codex/auth.json结构类似把 base_url 指向同一个地址即可。Cline 的 MCP 配置则写在插件设置里后面第 4 章会给完整片段。这里有个容易踩的坑Base URL 和完整 endpoint 是两回事。SDK 里填 Base URL不要自己拼/v1/chat/completions否则会变成双份路径导致 404。另一个坑是 Key 前后带空格复制时很容易带上建议用echo $KEY | tr -d 清洗一下。环境变量方式更适合脚本Linux/macOS 下export TAOTOKEN_API_KEYsk-你的Key export TAOTOKEN_BASE_URLhttps://taotoken.net/api export TAOTOKEN_MODEL你的模型IDWindows PowerShell 用$env:TAOTOKEN_API_KEYsk-...。配好之后先别急着写业务代码下一章我们用最小脚本验证通道是否通。3. 可复制配置Function Calling 最小可运行示例这一章是全文的技术核心我会给出一个完整的 Function Calling 示例包含工具定义、请求构造、结果回填三个环节。你复制过去改 Key 就能跑。先装依赖pip install openai然后写脚本fc_demo.py。核心思路是定义两个工具查天气、算补贴把工具描述以 JSON Schema 形式传给模型模型返回tool_calls我们本地执行函数再把结果作为tool角色消息回填让模型生成最终自然语言回答。import os, json from openai import OpenAI client OpenAI( api_keyos.environ[TAOTOKEN_API_KEY], base_urlos.environ[TAOTOKEN_BASE_URL], ) # 1. 本地真实函数 def get_weather(city: str) - str: fake {北京: 晴 26℃, 上海: 多云 24℃} return fake.get(city, 未知城市) def calc_subsidy(days: int, rate: int 200) - str: return f共 {days} 天每天 {rate} 元合计 {days * rate} 元 # 2. 工具描述JSON Schema tools [ { type: function, function: { name: get_weather, description: 查询指定城市的当前天气, parameters: { type: object, properties: {city: {type: string, description: 城市名}}, required: [city], }, }, }, { type: function, function: { name: calc_subsidy, description: 根据出差天数计算补贴, parameters: { type: object, properties: { days: {type: integer, description: 出差天数}, rate: {type: integer, description: 每日标准默认200}, }, required: [days], }, }, }, ] messages [{role: user, content: 帮我查下北京天气我出差3天补贴多少}] resp client.chat.completions.create( modelos.environ[TAOTOKEN_MODEL], messagesmessages, toolstools, tool_choiceauto, ) msg resp.choices[0].message messages.append(msg) # 3. 执行模型请求的工具并回填 if msg.tool_calls: for call in msg.tool_calls: name call.function.name args json.loads(call.function.arguments) result get_weather(**args) if name get_weather else calc_subsidy(**args) messages.append({ role: tool, tool_call_id: call.id, content: result, }) final client.chat.completions.create( modelos.environ[TAOTOKEN_MODEL], messagesmessages, ) print(final.choices[0].message.content)跑之前确认三个环境变量都设了。预期输出类似“北京今天晴26℃出差 3 天补贴合计 600 元。”如果模型只回了一半说明工具结果回填时tool_call_id对不上检查一下是否原样透传了call.id。这里的关键认知Function Calling 不是模型真的执行了函数而是模型输出了“我要调用 get_weather参数是北京”。真正执行的是你的代码。模型能力越强参数抽取和工具选择越准这就是为什么说 Function Calling 是基本功。4. 接入 MCP让工具集成从“手写”变成“插拔”上一章的工具有个问题每接一个新服务你都要手写函数和 Schema。MCP 就是来解决这个集成成本的。它把工具、资源、提示模板封装成 ServerClient 通过标准协议发现和调用模型侧看到的还是 Function Calling但开发者不用重复造轮子。MCP 的架构分四层Host 是接收你提问的应用Client 是 Host 和 Server 之间的桥梁Server 提供外部数据和工具Base Protocol 定义消息格式和传输机制。流程是你的问题发给 LLMLLM 选工具Client 通过 MCP Server 执行结果回给 LLMLLM 生成回答。注意最后一步——MCP 的调用决策依然依赖模型的 Function Calling 能力所以第 3 章跑通是前提。以 Cline 为例MCP 配置写在插件的 MCP Servers 设置里格式是 JSON。下面是一个本地 stdio 类型的 Server 配置片段把命令换成你实际要接的 Server{ mcpServers: { demo-server: { command: python, args: [-m, your_mcp_server], env: { API_KEY: sk-你的Key, BASE_URL: https://taotoken.net/api } } } }如果你用的是支持 MCP 的客户端配置项同样是三件套Base URL 指向https://taotoken.net/apiKey 用控制台生成的Model ID 填你开通的模型。三者缺一Server 能启动但模型侧调不通。验证 MCP 是否生效最直接的办法是问一个必须用外部工具的问题比如“列出当前可用的工具”看客户端是否把 Server 暴露的工具列出来。如果列表为空先查 Server 进程有没有起来再看 Client 日志里的握手信息。我实测下来MCP 最容易出问题的地方是环境变量没传进 Server 子进程。stdio 模式下 Server 是独立进程父进程的环境变量不一定继承所以配置里显式写env更稳。另一个坑是路径args里的模块名要能被 Python 找到建议先用python -m your_mcp_server在终端单独跑一次确认。MCP 的价值在于复用。别人把高德地图、12306 这类服务封装成 MCP Server 后你只要在配置里加一段就能让模型用上不用自己写对接代码。这就是“高速公路”的含义——路修好了车直接上。5. 用 Skills 约束流程从“能调用”到“按顺序调用”Function Calling 解决了调不调MCP 解决了好不好接但还有个问题复杂任务需要固定顺序和规则。比如“先查库存再算价格最后生成报价单”模型可能跳步或乱序。Skills 就是干这个的——用 Markdown 文档加脚本把流程写成模型能读的说明书。一个最小 Skill 通常包含三部分元信息名称、描述、触发条件、流程说明分步骤的自然语言指令、以及可选的脚本。下面是一个quote_skill.md的骨架--- name: quote-generator description: 当用户要求生成报价单时使用必须按顺序执行 --- # 报价单生成流程 1. 调用 get_inventory 查询商品库存若库存为 0 则终止并告知用户。 2. 调用 calc_price 计算单价乘以数量折扣参数从用户输入提取。 3. 调用 render_quote 生成最终报价单文本。 4. 禁止跳过第 1 步直接算价。把这类文档放到模型能读取的目录或在系统提示里引用模型在规划时就会参考这个顺序。Skills 和 MCP 的关系官方有个厨房类比很贴切MCP 提供工具、原料、设备Skills 提供配方。你有再好的锅没有菜谱也做不出稳定的菜。构建 Skill 时有几个注意点。描述要写清楚“什么时候用”否则模型不知道何时加载。流程步骤要可执行避免“适当处理”这种模糊词。如果涉及脚本脚本的输入输出要明确最好在文档里给出示例。我试过把步骤写得太抽象结果模型自由发挥顺序全乱改成“第 1 步必须调用 X参数从 Y 提取”之后稳定性明显提升。到这里三个能力就串起来了Function Calling 是底层调用能力MCP 是工具接入标准Skills 是流程编排。你可以先用第 3 章的脚本验证调用再用第 4 章的配置接一个 MCP Server最后用本章的 Skill 约束顺序形成一条完整的端到端路径。6. 常见报错排查401、local proxy failed、reading choices、OAuth这一章按真实报错来每个都给定位思路。你跑上面脚本时大概率会遇到其中一两个。401 Unauthorized。最常见的原因是 Key 错了或没传。先确认环境变量真的生效echo $TAOTOKEN_API_KEY看有没有值。如果值对但还报 401检查 Base URL 是不是写成了完整 endpoint正确写法是https://taotoken.net/api不要带/v1/chat/completions。还有一种情况是 Key 被复制时带了换行用tr -d \n清洗。local proxy failed。这个报错通常出现在客户端配置了本地代理但代理没起来或者环境变量里残留了HTTP_PROXY。先env | grep -i proxy看有没有多余的代理设置有就 unset 掉。注意不要配置任何非官方的网络中转直接用 TaoToken 的 API 地址即可。reading choices 相关报错比如KeyError: choices或reading choices。这说明返回体结构和你预期的不一样多半是请求根本没成功返回的是错误 JSON。打印完整响应体print(resp)或print(resp.model_dump())看里面的 error 字段。常见原因是模型 ID 写错或者该模型不支持 tools 参数。OAuth 报错。如果你在 Claude Code 或类似工具里看到 OAuth 相关提示说明工具在走账号授权流程而不是 API Key。检查 settings 里是否同时配了ANTHROPIC_API_KEY和 OAuth 凭据两者冲突时优先走 OAuth。解决办法是清掉 OAuth 缓存只保留 API Key 配置。三件套 Base URL、Key、Model ID 必须同时存在且一致。还有一个隐蔽的坑工具调用返回后回填消息的role必须是tool且tool_call_id要和模型返回的id完全一致。我见过有人写成function角色结果模型收不到结果反复请求同一个工具。排查顺序建议固定下来先看 Key 和 Base URL再看模型 ID然后看请求体结构最后看响应体原文。按这个顺序八成问题能在前三步定位。7. 继续深入把三个能力用起来的下一步跑通上面的流程后你手里就有了一条可复现的路径。接下来可以做的几件事把 Function Calling 的工具从两个扩到十个观察模型选择准确率的变化接一个真实的 MCP Server比如文件系统或数据库查询类体验“插拔式”集成给常用任务写 Skill 文档把流程固化下来。需要提醒的是MCP 不要直连生产库先用测试数据跑通。Skills 的文档要随流程变化及时更新否则模型会按旧配方执行。模型 ID 和价格以控制台实际显示为准不要照搬网上的评测数字。如果你在接入过程中卡住优先看接入文档里面有各客户端的完整配置示例。想先验证模型本身是否正常可以去模型对话页面发一条消息试试。长期做编码或 Agent 类任务Coding Plan 会更合适。三个入口按需选排障和接入配置API Keys 页面加接入文档验证模型连通性模型对话长期编码与 Agent 任务Coding Plan把第 3 章的脚本保存好它是你后面所有实验的基线。每次改配置后先跑它通了再往下做能省掉大量排查时间。