AI Agent、Skill 和 MCP 到底都是什么：从 Function Calling 到 config.toml 骨架一次讲清

1. 从 Function Calling 说起Agent 到底缺了哪块拼图如果你刚开始接触 AI Agent大概率会被三个词绕晕Function Calling、Skill、MCP。它们都跟让模型干活有关但职责边界模糊网上的解释又常常混着讲。这篇我用一个最小可跑的闭环把它们串起来先讲清各自是什么再给一份可以直接复制的config.toml骨架最后用一次真实请求验证整条链路通不通。先说结论Function Calling 是模型调用单个函数的机制Skill 是写给模型的流程说明书MCP 是把工具调用标准化的协议。三者不是替代关系而是分层协作。Agent 则是把这三层组装起来、能自主规划并执行任务的那个总调度。很多人卡在第一步模型明明支持 Function Calling为什么还要 Skill 和 MCP原因很实际——Function Calling 的工具定义写在代码里加一个工具就要改代码重新部署Skill 用自然语言描述流程零代码就能扩展行为MCP 把工具做成独立服务随时启停、跨项目复用。理解了这层动机后面的配置就不会觉得是多此一举。这篇适合谁写过一点 API 调用、想让模型真正动手做事、但还没跑通完整链路的开发者。下面每一步都有命令和配置你可以边看边操作。2. TaoToken 前置准备拿到能跑通 Function Calling 的入口要让上面的链路跑起来你需要一个能访问主流模型的 API 入口。TaoToken 提供统一的 API 地址兼容 OpenAI 风格的调用方式Function Calling、流式输出这些都能直接用。对刚上手 Agent 的人来说省去分别对接各家 SDK 的麻烦。先做两件事。第一注册并创建 API Key入口在控制台的 API Keys 页面https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite第二记下两个地址后面配置里会反复用到用途地址官网https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentAPI Basehttps://taotoken.net/api注意API Base 后面不加 UTM 参数直接用它作为base_url即可。很多 401 报错就是因为把带参数的官网地址误填进了 base_url。拿到 Key 之后建议先用一条最简单的对话请求确认连通再往上叠 Function Calling 和 MCP。顺序反了出问题很难定位是哪一层。3. 可复制的 config.toml 骨架与 MCP 服务注册下面这份config.toml是我实测下来结构比较清晰的一份骨架覆盖了模型接入、Skill 目录、MCP 服务注册三块。你可以直接复制把占位符换成自己的值。# config.toml —— Agent 最小闭环配置骨架 [model] # 统一走 TaoToken 的 API 入口 base_url https://taotoken.net/api api_key sk-你的Key name claude-sonnet # 换成你要用的模型标识 max_tokens 4096 temperature 0.3 [agent] # Agent 自身行为 system_prompt 你是一个会规划步骤、调用工具的助手。 max_steps 8 # 单轮任务最多执行几步防止死循环 enable_function_calling true [skills] # Skill 就是本地目录里的 Markdown 说明书 dir ./skills auto_load true # 注册一个 MCP 服务文件系统 [[mcp.servers]] name filesystem command npx args [-y, modelcontextprotocol/server-filesystem, ./workspace] transport stdio enabled true # 注册一个 MCP 服务HTTP 抓取 [[mcp.servers]] name fetch command npx args [-y, modelcontextprotocol/server-fetch] transport stdio enabled false # 先关掉验证完第一个再开几个关键点解释一下。transport stdio表示 MCP 服务器通过标准输入输出和 Agent 通信这是本地服务最常用的方式enabled让你可以逐个启停服务排查问题时特别有用。skills.dir指向的目录里放.md文件每个文件就是一份 Skill。配套的 Skill 文件长这样放在./skills/code_review.md# Skill: 代码审查 当用户要求审查代码时按以下顺序执行 1. 检查语法错误与类型标注 2. 检查未处理的异常分支 3. 检查是否符合团队规范 注意逻辑错误优先于风格问题超过 200 行先问用户是否只看关键部分。这份配置的加载顺序是Agent 启动 → 读取[model]建立连接 → 加载[skills]目录 → 按[[mcp.servers]]逐个拉起 MCP 服务。任何一步失败启动日志里都会有明确提示。4. 逐步验证从单次 Function Calling 到 MCP 闭环配置写完不代表能跑。我习惯分三步验证每步只测一层出问题好定位。第一步验证模型连通和 Function Calling。用一段最小 Python 代码定义一个工具并让模型决定是否调用import json, requests BASE https://taotoken.net/api KEY sk-你的Key tools [{ type: function, function: { name: get_weather, description: 查询指定城市的天气, parameters: { type: object, properties: {city: {type: string}}, required: [city] } } }] resp requests.post( f{BASE}/v1/chat/completions, headers{Authorization: fBearer {KEY}}, json{ model: claude-sonnet, messages: [{role: user, content: 北京今天天气怎么样}], tools: tools } ) print(json.dumps(resp.json(), ensure_asciiFalse, indent2))如果返回里出现tool_calls字段说明 Function Calling 通了。这一步成功的关键是tools的 JSON Schema 写对parameters里required和properties要匹配。第二步验证 Skill 加载。在对话里问一句帮我审查这段代码观察 Agent 是否按code_review.md里的三步流程走。如果它跳过了某一步多半是 Skill 没被加载检查skills.dir路径和auto_load。第三步验证 MCP 闭环。把filesystem服务打开让 Agent 读一个./workspace里的文件# 先确认 MCP 服务能独立启动 npx -y modelcontextprotocol/server-filesystem ./workspace服务能起来后在对话里说读一下 workspace 里的 notes.txt 并总结。Agent 会通过 MCP 协议向 filesystem 服务发请求拿到内容再整合回复。这一步跑通说明 Function Calling、Skill、MCP 三层已经串起来了。提示验证顺序不要跳。先单函数、再 Skill、最后 MCP每层单独确认比一上来就跑完整任务高效得多。5. 本篇常见报错与排查清单跑这套配置时下面几个错我踩过不止一次列出来帮你省时间。401 Unauthorized九成是base_url填错。确认是https://taotoken.net/api不要带任何查询参数也不要漏掉/api。Key 前后有空格也会触发。tool_calls 为空模型没决定调用工具。检查tools的description是否说清了什么时候用描述太模糊模型会直接回答而不调用。另外temperature太高也会让模型偏向闲聊。MCP 服务启动失败npx拉包失败通常是网络或缓存问题先手动跑一遍npx -y modelcontextprotocol/server-filesystem ./workspace看报错。路径不存在也会直接退出确认./workspace目录真实存在。Skill 不生效文件名后缀必须是.md且skills.dir是相对 Agent 启动目录的路径。启动日志里一般会打印loaded N skillsN 为 0 就是没加载到。Agent 陷入循环max_steps设太大又没收敛条件时Agent 会反复调用同一个工具。把它压到 8 以内并在 system prompt 里加一句若连续两次调用无新信息则停止。排查的通用思路是把enabled逐个关掉只留一层确认这层通了再开下一层。分层隔离比盯着完整日志猜要快得多。6. 把三层用起来按场景选对入口三层跑通之后怎么在实际项目里分工取决于你的目标。如果你只是想让模型调用一两个固定函数Function Calling 就够了不用引入 MCP配置越少越稳。如果你要固化一套工作流程——比如代码审查、部署前检查——写成 Skill 最划算改流程就是改 Markdown。如果你需要跨项目复用工具能力或者工具本身要独立维护那就上 MCP把它做成服务。长期做编码和 Agent 任务的建议直接走 Coding Plan省去每次手动配模型的麻烦https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite想先验证模型在 Function Calling 上的表现用模型对话页面快速试https://taotoken.net/model-chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite接入细节和参数说明看接入文档API Key 在控制台管理https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite最后一句实操建议先把filesystem这一个 MCP 服务跑顺再逐个加fetch、数据库这些。每加一个就回归测一次权限给到最小。Agent 能读写文件、能联网之后误操作的代价是真实的稳一点比快一点重要。