1. 从 Function Call 到 Agent Skills工具调用到底解决了什么问题大模型工具调用Tool Calling这几年变化很快但很多同学第一次接触时都会卡在同一个地方模型明明能聊天为什么还要搞 Function Call、MCP、Agent Skills 这一堆概念简单说Function Call 让模型能“按格式点菜”MCP 让模型能“用统一插头接各种电器”Agent Skills 则是把“一整套专业操作手册”打包给模型随身携带。它们不是互相替代而是解决不同层面的问题。如果你正在做智能客服、代码助手、数据分析 Agent或者只是想让本地模型能查天气、读数据库、调内部接口那这套演进脉络你必须搞清楚。因为选错方案后面会不断返工要么工具描述塞爆上下文要么每接一个新工具就重写一遍胶水代码要么模型在专业领域里胡说八道。我按“能不能调 → 会不会用 → 好不好连 → 专不专业”四个阶段来梳理。第一阶段是 Function Call核心是把自然语言转成结构化 JSON 参数第二阶段是 Agent 自主规划模型自己决定调哪个工具、调几次第三阶段是 MCPModel Context Protocol把工具、资源、提示词抽象成统一协议解决生态碎片化第四阶段是 Agent Skills用渐进式披露把领域知识、操作文档、脚本打包成可移植模块。本文会给出可复制的 MCP 配置片段、Function Call 调用示例以及本地验证工具调用链路的完整步骤。你跟着做能亲手跑通一次“模型发起调用 → 本地执行 → 结果回传”的闭环。中间会用到 TaoToken 作为统一接入层把不同模型的调用方式收敛成一套配置省得你为每个模型单独改代码。先明确一个判断Function Call 是能力底座MCP 是连接标准Agent Skills 是知识封装。三者叠加才是当前比较完整的工具调用方案。下面从最基础的 Function Call 开始拆。2. Function Call 最小可跑示例与 MCP 配置前置准备Function Call 的本质是你在请求里告诉模型“有哪些函数可用”模型返回一个 JSON里面写明“我要调哪个函数、参数是什么”。你本地执行完再把结果塞回对话。听起来简单但第一次写很容易踩坑比如参数 schema 写错、模型返回空 choices、或者把工具结果格式搞乱。先看一个最小可跑的 Python 示例。这里用 OpenAI 兼容接口通过 TaoToken 统一接入Base URL 指向https://taotoken.net/api。你需要先在控制台创建一个 API Key然后把它放进环境变量。import os import json from openai import OpenAI client OpenAI( api_keyos.environ[TAOTOKEN_API_KEY], base_urlhttps://taotoken.net/api ) tools [ { type: function, function: { name: get_weather, description: 查询指定城市的当前天气, parameters: { type: object, properties: { city: { type: string, description: 城市名称例如杭州 } }, required: [city] } } } ] response client.chat.completions.create( modelgpt-4o-mini, messages[{role: user, content: 杭州今天天气怎么样}], toolstools, tool_choiceauto ) msg response.choices[0].message print(msg.tool_calls)跑通后你会看到类似Function(arguments{city:杭州}, nameget_weather)的输出。这说明模型已经正确识别意图并填好了参数。接下来你要在本地执行这个函数把结果以role: tool的消息追加回去。MCP 的前置准备和这个思路一致只是把“函数列表”换成了“MCP Server”。MCP Server 可以暴露 tools、resources、prompts 三类能力。你需要在客户端配置里声明要连接哪些 Server。以 Claude Desktop 为例配置文件路径通常是macOS~/Library/Application Support/Claude/claude_desktop_config.jsonWindows%APPDATA%\Claude\claude_desktop_config.json配置片段如下注意command和args要指向你本地实际安装的 MCP Server{ mcpServers: { filesystem: { command: npx, args: [ -y, modelcontextprotocol/server-filesystem, /Users/yourname/workspace ] } } }如果你用的是 Cline、Cursor 或 Claude Code配置位置不同但核心三件套不变Base URL、API Key、Model ID。比如在 Cline 的 MCP 设置里你需要填Base URLhttps://taotoken.net/apiAPI Key控制台生成的 KeyModel ID例如claude-3-5-sonnet-20241022或gpt-4o这里有个容易忽略的点MCP Server 本身不负责模型调用它只负责暴露工具。模型调用仍然走你的 API 配置。所以你要确保 API Key 有权限访问对应模型并且 Model ID 拼写完全正确。拼错会直接报model not found而不是回退到默认模型。配置完成后重启客户端在对话里问“列出工作区文件”如果 MCP Server 正常模型会发起list_directory调用并返回文件列表。这一步成功说明你的工具调用链路已经通了。3. 可复制配置MCP Server 与 Agent Skills 目录结构这一节给你可以直接抄的配置。先讲 MCP Server 的两种接入方式本地 stdio 和远程 SSE。本地 stdio 适合文件系统、数据库、命令行工具远程 SSE 适合团队共享的服务。本地 stdio 配置模板{ mcpServers: { sqlite: { command: uvx, args: [ mcp-server-sqlite, --db-path, /Users/yourname/data/app.db ] }, github: { command: npx, args: [-y, modelcontextprotocol/server-github], env: { GITHUB_PERSONAL_ACCESS_TOKEN: your_token_here } } } }远程 SSE 配置模板{ mcpServers: { remote-tools: { url: https://your-mcp-server.example.com/sse, headers: { Authorization: Bearer your_token_here } } } }注意env里的密钥不要提交到 Git。建议用.env文件或系统环境变量注入。如果你在团队里共享配置把密钥部分抽成占位符让每个人本地填。接下来是 Agent Skills 的目录结构。一个 Skill 就是一个文件夹核心是SKILL.md。以 PDF 处理 Skill 为例pdf-skill/ ├── SKILL.md ├── forms.md ├── reference.md └── scripts/ ├── extract_text.py └── fill_form.pySKILL.md的头部是元数据用 YAML front matter 写--- name: pdf-editor description: 用于读取、编辑、填写 PDF 表单支持文本提取和字段填充 --- # PDF 编辑技能 当用户需要处理 PDF 文件时按以下步骤操作 1. 先读取 forms.md 了解表单字段定义 2. 如需提取文本调用 scripts/extract_text.py 3. 如需填写表单调用 scripts/fill_form.py 4. 遇到复杂布局参考 reference.md这种结构的关键在于“渐进式披露”启动时只加载 name 和 description模型判断相关后才读SKILL.md主体需要细节时才读forms.md或reference.md。这样上下文不会被无关技能塞满。如果你用 Claude Code可以把 Skill 目录放在项目根目录的.claude/skills/下。Claude Code 会自动发现并加载。配置三件套同样要写全Base URLhttps://taotoken.net/apiAPI Key你的 KeyModel ID例如claude-3-5-sonnet-20241022在 Claude Code 的settings.json里可以这样写{ apiBaseUrl: https://taotoken.net/api, apiKey: your_key_here, model: claude-3-5-sonnet-20241022 }如果你用 Codex配置文件在~/.codex/auth.json格式类似{ api_base: https://taotoken.net/api, api_key: your_key_here, model: gpt-4o }这里提醒一句不同客户端的配置字段名不一样但逻辑都是 Base URL Key Model ID。你只要把这三个对齐工具调用链路就能跑起来。别在字段名上纠结太久先跑通再优化。4. 本地验证工具调用链路从请求到结果回传配置写完后必须验证。很多人卡在“配置看起来对但模型就是不调工具”。下面给你一套本地验证步骤按顺序排查。第一步确认 API 连通性。用 curl 直接打一次 chat completionscurl -X POST https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: gpt-4o-mini, messages: [{role: user, content: 你好}] }如果返回 401说明 Key 不对或没带Bearer。如果返回 404检查 Base URL 是否多了或少了/v1。TaoToken 的 API 地址是https://taotoken.net/api具体路径以文档为准。第二步验证 Function Call 返回结构。用第 2 节的 Python 脚本打印response.choices[0].message。正常应该看到tool_calls字段。如果tool_calls是None检查tool_choice是否设成了auto以及工具描述是否清晰。描述太模糊模型可能选择直接回答而不是调工具。第三步验证 MCP Server 是否启动。在终端手动跑一次npx -y modelcontextprotocol/server-filesystem /Users/yourname/workspace如果报command not found说明 Node.js 或 npx 没装好。如果报权限错误检查路径是否存在。MCP Server 启动后会等待 stdio 输入这是正常的按 CtrlC 退出即可。第四步在客户端里触发一次工具调用。以 Claude Desktop 为例重启后问“列出工作区文件”。如果模型回复“我没有文件系统访问权限”说明 MCP Server 没连上。检查配置文件路径是否正确JSON 是否有语法错误。JSON 不支持注释多一个逗号都会导致解析失败。第五步看日志。Claude Desktop 的 MCP 日志在macOS~/Library/Logs/Claude/mcp.logWindows%APPDATA%\Claude\logs\mcp.log日志里会写明连接成功还是失败以及具体的错误信息。这一步能帮你快速定位是配置问题还是网络问题。第六步验证 Agent Skills 加载。在 Claude Code 里输入/skills或查看启动日志确认 Skill 被识别。如果没识别检查SKILL.md的 front matter 格式name和description必须存在且---不能少。整套流程跑通后你会看到类似这样的结果用户提问 → 模型返回 tool_calls → 本地执行函数 → 结果回传 → 模型生成最终回答。这个闭环是后面所有 Agent 应用的基础。5. 常见报错排查401、local proxy failed、reading choices、OAuth这一节对照真实报错给你排查路径。这些错误我基本都遇到过按顺序查能省很多时间。401 Unauthorized最常见。原因通常是 Key 没带、Key 过期、或者 Base URL 写错导致请求打到了别的服务。检查Authorization头是否是Bearer key注意 Bearer 后面有空格。如果你用 TaoTokenKey 在控制台的 API Keys 页面生成。生成后复制完整不要漏字符。local proxy failed这个报错通常出现在客户端配置了本地代理但代理没启动或端口不对。检查客户端设置里的代理地址如果是http://127.0.0.1:7890这类确认本地服务在跑。如果你没开代理就把代理设置清空。有些客户端会默认读系统代理系统代理关了但客户端还留着旧配置也会报这个。reading choices这个报错说明响应结构不符合预期。常见原因是 Base URL 少了/v1或者模型返回了错误信息而不是正常 completion。先打印完整响应体看error字段。如果是model not found检查 Model ID 拼写。如果是invalid api key回到 401 的排查。OAuth 相关报错如果你用 GitHub MCP Server 或类似需要 OAuth 的服务报错通常是 token 过期或 scope 不足。重新生成 token确保勾选了需要的权限。GitHub 的 token 在 Settings → Developer settings → Personal access tokens 里生成。生成后放进 MCP 配置的env里重启客户端。MCP Server 启动失败检查command是否在 PATH 里。npx和uvx需要 Node.js 和 Python 环境。如果报spawn npx ENOENT说明系统找不到 npx装 Node.js 后重启终端。如果报EACCES检查文件权限。工具调用死循环模型反复调同一个工具不生成最终回答。这通常是因为工具返回结果格式不对模型无法解析。确保 tool 消息的content是字符串不是对象。如果是 JSON先json.dumps再传。上下文超限工具描述太多塞爆上下文。这时候就该考虑 MCP 或 Agent Skills 的渐进式披露了。把不常用的工具拆成独立 Skill按需加载。排查时记住一个原则先确认 API 通再确认工具注册最后确认模型选择。三层分开查不要混在一起。6. 接入路径与后续实践建议如果你已经跑通了上面的示例接下来可以按场景选接入方式。日常调试和验证模型能力用模型对话页面直接试改 prompt 和工具描述最快。长期写代码、跑 Agent 任务用 Coding Plan 更划算配额和并发都更适合持续调用。需要管理多个 Key、查看用量、给团队分配权限去控制台和 API Keys 页面操作。接入文档里有各客户端的详细配置示例包括 Claude Code、Cline、Codex 的完整字段说明。遇到配置问题先翻文档大部分报错都有对应说明。后续实践建议三条。第一先把一个 MCP Server 跑稳再叠加第二个。不要一次配五个出问题很难定位。第二Agent Skills 的SKILL.md要写清楚“什么时候用”和“怎么用”描述越具体模型判断越准。第三工具返回结果尽量结构化模型解析起来更稳定。工具调用这条链路跑通一次之后后面就是不断加工具、加 Skill、优化描述。核心三件套 Base URL、API Key、Model ID 对齐剩下的都是细节调整。