1. 先厘清一个真实场景为什么你的 Agent 总是调错工具我见过太多团队在搭 Agent 时把 tool、function calling、skill、mcp 这四个词混着用结果代码里出现用 MCP 定义了一个 skill然后靠 function calling 去触发 tool这种四不像结构。跑起来能出结果但一旦工具数量超过 10 个模型就开始乱调该查天气的去发了邮件该走审批流程的直接跳过了风控。问题的根源不是模型笨而是这四个概念在职责上根本没被分开。它们其实处在 Agent 调用链的不同层级Tool工具最底层的执行单元一个函数、一个 API只干一件事。比如get_weather(city)。Function Calling函数调用模型服务商提供的协议能力负责把自然语言翻译成结构化的 JSON 调用指令。它不执行代码只产出我要调 get_weather参数是 Beijing。Skill技能面向业务的高层封装是工具 调用逻辑 领域知识的 SOP。比如天气专家技能规定了什么时候调、参数怎么补全、回复用什么模板。MCP模型上下文协议工具接入的开放标准解决的是工具怎么被发现和挂载的问题相当于给所有工具装了一个统一的 USB-C 接口。一句话概括分工MCP 管接入Function Calling 管翻译Tool 管执行Skill 管编排。四者不是替代关系而是从发现工具到完成业务的一条流水线。这篇内容面向正在搭 Agent 的开发者我会给出四者对照表、一个可复制的 function calling 与 MCP 组合配置示例以及用最小请求验证各层调用链是否生效的完整步骤。如果你正在用 TaoToken 这类聚合接入服务做模型调用这套分层思路能直接套上去后面我会给出具体的 Base URL 和配置片段。先记住一个判断标准当你发现模型不知道该调哪个工具时问题通常在 Skill 层当模型调了但参数不对时问题在 Function Calling 的 schema 定义当工具根本挂不上时问题在 MCP 接入层。分层排查比盲目改 prompt 有效得多。2. 四者对照表与 TaoToken 接入前置准备在动手写配置之前先把四个概念摊开对照。很多开发者卡住是因为把谁产生、谁执行、谁编排这三件事搞混了。对比项ToolFunction CallingSkillMCP本质可执行函数/API模型输出结构化指令的协议业务 SOP 封装工具接入标准谁产生开发者写代码模型服务商提供能力开发者写提示词/手册社区/官方定义协议谁执行你的运行时不执行只产出 JSON编排层调度不执行只做发现与挂载数据形态纯逻辑代码JSON 参数Markdown 脚本JSON-RPC是否可执行是否是间接否解决什么问题具体能力自然语言转指令怎么专业地做工具怎么统一接入看懂这张表你就明白为什么不能拿 MCP 当 Skill 用。MCP 只负责告诉 Agent 有哪些工具可用它不关心业务上该怎么组合这些工具那是 Skill 的活。接下来是接入前置。无论你用哪家模型服务Agent 调用链都需要一个稳定的模型入口。我用 TaoToken 做演示因为它同时提供对话模型和 Coding Plan适合 Agent 这种需要反复调用的场景。第一步拿到 API Key。访问控制台创建密钥https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite第二步确认你的 Base URL。所有请求走这个地址注意 API 路径不带 UTM 参数https://taotoken.net/api第三步选模型。Agent 场景建议用支持 function calling 的模型Model ID 在模型列表里查。如果你要做长期编码类 Agent可以看 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite这里有个容易踩的坑很多人把 Base URL 写成官网首页结果请求 404。记住区分——官网是https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentAPI 入口是https://taotoken.net/api两者不能混。准备好 Key 和 Base URL 后我们进入配置环节。下面这段配置会同时体现 Function Calling 的工具 schema 和 MCP 的工具发现你可以直接复制到项目里改。3. 可复制配置Function Calling 与 MCP 组合示例这一节是全文的核心。我会给出一个完整的配置结构包含三件套Base URL、API Key、Model ID以及 Function Calling 的 tools 定义和 MCP Server 的挂载配置。先看模型客户端的基础配置。以 Python 为例用 OpenAI 兼容格式import os from openai import OpenAI client OpenAI( base_urlhttps://taotoken.net/api, api_keyos.environ[TAOTOKEN_API_KEY], ) MODEL_ID your-model-id # 在模型列表中选择支持 function calling 的模型注意base_url后面不要加/v1具体路径以接入文档为准。如果你用的是 Claude Code 这类工具配置方式不同需要走 Anthropic 兼容入口文档在这里https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite接下来是 Function Calling 的工具定义。这是给模型看的说明书schema 写得越清楚模型调得越准weather_tool { type: function, function: { name: get_weather, description: 获取指定城市的当前天气温度当用户询问天气、温度、冷热时使用, parameters: { type: object, properties: { city: { type: string, description: 城市名称如 Beijing、Shanghai }, unit: { type: string, enum: [celsius, fahrenheit], description: 温度单位默认 celsius } }, required: [city] } } }然后是 MCP Server 的挂载配置。MCP 的价值在于工具发现——Agent 客户端连上 Server 后自动拉取工具列表不用你手动维护。一个标准的 MCP 配置以 JSON 格式为例常见于 Claude Desktop 或 Cline 类客户端{ mcpServers: { weather-server: { command: python, args: [-m, weather_mcp_server], env: { WEATHER_API_KEY: your-weather-key } } } }如果你用的是 Cline 或类似支持 MCP 的编辑器插件配置项名称可能略有差异但核心三件套不变Base URL Key Model ID。MCP Server 本身不关心模型是谁它只负责暴露工具模型调用走的是 Function Calling 协议。这里要强调一个协作关系MCP Server 启动后通过tools/list方法返回工具清单Agent 客户端把这些工具转换成 Function Calling 需要的 schema 格式再传给模型。也就是说MCP 负责有哪些工具Function Calling 负责模型怎么调Tool 负责真正执行。一个完整的组合流程是这样的# 1. MCP 层从 Server 拉取工具列表伪代码 mcp_tools mcp_client.list_tools() # 返回 [{name: get_weather, inputSchema: {...}}] # 2. 转换层把 MCP 工具转成 Function Calling schema fc_tools [convert_to_openai_schema(t) for t in mcp_tools] # 3. 模型层发起请求携带工具 schema response client.chat.completions.create( modelMODEL_ID, messages[{role: user, content: 北京现在多少度}], toolsfc_tools, ) # 4. 执行层解析模型返回的 tool_calls执行本地函数 tool_call response.choices[0].message.tool_calls[0] func_name tool_call.function.name func_args json.loads(tool_call.function.arguments) result dispatch(func_name, func_args) # 真正调用 get_weather这段代码把四层串起来了。你可以看到MCP 和 Function Calling 不是二选一而是上下游关系。很多教程把它们对立起来讲是误导。配置写完后别急着上复杂业务。先用最小请求验证每一层是否生效下一节给步骤。4. 最小请求验证逐层确认调用链生效配置写完不代表能跑通。Agent 调用链有四层任何一层断了表现都是模型没反应或工具没执行。所以要用最小请求逐层验证而不是一上来就跑完整业务。第一层验证模型连通性。先确认 Base URL 和 Key 没问题发一个不带工具的普通请求resp client.chat.completions.create( modelMODEL_ID, messages[{role: user, content: 回复 OK 两个字母}], ) print(resp.choices[0].message.content)如果这一步报 401说明 Key 错了报连接失败说明 Base URL 写错了。这一步不通后面都别谈。第二层验证Function Calling 是否触发。带上工具 schema问一个必然触发工具的问题resp client.chat.completions.create( modelMODEL_ID, messages[{role: user, content: 北京现在多少度}], tools[weather_tool], ) msg resp.choices[0].message print(tool_calls:, msg.tool_calls)预期结果是tool_calls不为空里面包含get_weather和参数{city: Beijing}。如果tool_calls是空的说明模型没识别出该调工具检查你的description是否写清楚了触发条件。第三层验证工具执行。把模型返回的参数解析出来真正调用你的函数import json tool_call msg.tool_calls[0] args json.loads(tool_call.function.arguments) print(解析参数:, args) result get_weather(**args) print(执行结果:, result)这一步验证的是你的 dispatch 逻辑。常见错误是参数名对不上比如 schema 里写city函数签名里写city_name直接 TypeError。第四层验证MCP 工具发现。如果你用了 MCP Server单独验证它能否返回工具列表tools mcp_client.list_tools() print(MCP 暴露的工具:, [t[name] for t in tools])预期能看到get_weather。如果列表为空检查 MCP Server 是否正常启动、command和args路径是否正确。四层都通了再把结果回传给模型生成自然语言回复messages [ {role: user, content: 北京现在多少度}, msg, { role: tool, tool_call_id: tool_call.id, content: json.dumps(result, ensure_asciiFalse), }, ] final client.chat.completions.create(modelMODEL_ID, messagesmessages) print(final.choices[0].message.content)到这里一条完整的用户提问 → 模型决策 → 工具执行 → 结果回传 → 自然语言回复链路就跑通了。实测下来这套逐层验证法能帮你快速定位问题出在哪一层比盯着完整日志猜要快得多。5. 常见报错排查401、local proxy failed、reading choices、OAuthAgent 调用链的报错往往有迷惑性同一个错误可能来自不同层。下面按真实报错逐条排查。401 Unauthorized。最常见也最好定位。原因通常是 API Key 没设置、复制时带了空格、或者环境变量名写错。检查os.environ[TAOTOKEN_API_KEY]是否真的有值。另一个隐蔽原因是 Base URL 写成了官网首页而不是 API 入口导致请求打到了错误的服务上。确认你的base_url是https://taotoken.net/api。local proxy failed / connection refused。这个报错在 MCP Server 启动时特别常见。MCP 通过本地进程通信如果command指向的可执行文件不在 PATH 里或者args里的模块没安装就会连接失败。排查方法先在终端手动跑一遍python -m weather_mcp_server看能不能启动。能启动再放进配置里。另外注意MCP Server 的启动环境和你主程序的环境可能不是同一个 Python依赖要装对。reading choices of undefined。这个报错说明你拿response.choices时response本身是 undefined 或结构不对。常见于三种情况一是请求抛异常被吞了返回了空对象二是用了流式响应但没正确处理 chunk三是模型返回了错误结构比如被限流时返回的是错误对象。加一层防御if not resp or not getattr(resp, choices, None): print(响应异常:, resp) returnOAuth 相关报错。如果你用的是 Claude Code 或 Codex 这类工具它们可能走 OAuth 授权流程而不是简单的 API Key。报 OAuth 错误时先确认你用的是正确的接入方式。Claude Code 的接入配置和普通 API 调用不同需要参考专门的文档https://taotoken.net/ClaudeCodeAnthropic?utm_sourcetaotoken_aicg_blog_endutm_contentClaudeCodeAnthropicutm_campaignrewrite如果你用的是 Codex它读的是auth.json配置结构又不一样。这类工具的三件套依然是 Base URL、Key、Model ID但字段名和存放位置要按各自规范来。工具调了但结果不对。这类问题不报错但结果错。排查顺序先看模型返回的arguments是否符合 schema再看你的 dispatch 是否正确映射函数名最后看工具函数内部逻辑。我踩过的坑是 schema 里required漏写了关键参数模型有时不传函数用了默认值结果查了错误的城市。MCP 工具列表为空。除了 Server 没启动还有一种情况是协议版本不匹配。MCP 在演进客户端和 Server 的协议版本要对齐。检查你的 MCP 客户端版本必要时升级。排查的核心思路还是分层先确认模型连通401 类再确认工具发现MCP 类再确认指令生成choices 类最后确认执行结果类。按这个顺序90% 的问题能在五分钟内定位。6. 把四件套用对从能跑到好用的关键动作跑通最小链路只是起点。真正让 Agent 稳定工作的是四件套各司其职、边界清晰。我的建议是工具定义只写做什么不写什么时候做。get_weather的 description 就说获取天气别写用户问天气时调用——那是 Skill 的职责。Skill 层用 Markdown 手册规定触发条件、参数补全规则、回复模板通过系统提示注入。这样工具可以复用技能可以替换互不干扰。MCP 的价值在工具数量增长后才显现。三五个工具时手写 schema 没问题超过十个就该上 MCP 做统一发现和挂载。它让 Agent 客户端不用预置工具列表连上 Server 就能动态获取扩展性完全不同。Function Calling 是模型能力你控制不了它的实现但能控制 schema 质量。参数描述越具体、枚举值越明确模型调得越准。这是投入产出比最高的优化点。最后验证永远分层做。模型层、发现层、指令层、执行层每层都有独立的最小验证方法。别等完整业务跑挂了才去翻日志那时候四层混在一起定位成本翻倍。如果你还没开始搭可以从模型对话入口先感受一下 function calling 的实际返回结构https://taotoken.net/model-chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel-chatutm_campaignrewrite需要管理多个 Key 或查看用量时控制台在这里https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite把四件套的分工想清楚你的 Agent 才不会在工具变多之后失控。