1. 从 Function Calling 到 MCP为什么你的 Agent 工具越写越乱如果你正在做 Agent 开发大概率经历过这个阶段一开始用 Function Calling 手写几个工具函数感觉挺爽等到工具数量涨到十几个代码里全是if tool_name xxx的分支提示词和业务逻辑搅在一起改一个参数要翻三个文件。这不是你代码水平的问题而是 Function Calling 本身没有解决「工具与模型解耦」这件事。Function Calling 的原理并不复杂。大模型本质是纯文本进、纯文本出它没法直接读文件、发请求、查数据库。Function Calling 的做法是在请求里塞一个tools字段把可用工具的名字、描述、参数结构告诉模型模型如果判断需要调工具就在返回里给出tool_calls数组里面包含工具名和参数。你的后端拿到这个数组执行对应函数再把结果塞回对话历史继续问模型直到模型不再返回tool_calls为止。这个循环就是 Agent 最原始的形态。问题出在「工具需要包在后端服务里」这一步。硬编码工具函数业务规模一扩大代码维护性直线下降系统不确定性增加开发心智负担加重。更麻烦的是工具函数本身和大模型无关——它就像机器人的不同工种机械手换一个模型工具还得重写一遍绑定逻辑。工程化的本质是抽象MCPModel Context Protocol就是这层抽象。MCP 把工具Tool、提示词Prompt、资源Resource统一抽象成 MCP 服务器对外暴露的能力再用一套标准协议规定客户端怎么发现和调用它们。提示词不再内联在服务代码里而是作为服务器的一部分被管理运行时产生的庞杂输出比如浏览器 MCP 不断抓取的网页信息可以作为 Resource 提供给模型提升输出质量。Agent 后端服务负责业务客户层的 POST 请求MCP Server 层负责 Prompt、Tool、Resource 的暴露两层各司其职。这篇内容面向想用 fastmcp uv 快速搭建 Agent 工具的开发者我会给出可复制的 fastmcp 服务端配置、uv 依赖管理命令以及用 Function Calling 串联 Agent 的验证步骤帮你跑通一个最小可用的 MCP 服务并接入 TaoToken 统一 Key/API 通道。适合谁已经写过 Function Calling demo、想往工程化 Agent 走一步的后端或全栈开发者。2. TaoToken 前置准备统一 Key 与 API 通道配置在写 fastmcp 服务之前先把模型调用通道理顺。MCP 服务器本身不负责调模型它只暴露工具真正调模型的是 Agent 客户端。但你在调试阶段会频繁切换模型、对比不同模型对同一套工具的调用效果如果每个模型都去单独申请 Key、改 Base URL调试效率会被拖垮。TaoToken 在这里的作用是提供一个统一的 API 通道你只需要一个 Key就能在多个模型之间切换。先拿到 Key。访问 https://taotoken.net/api-keys 创建你的 API Key复制保存好后面配置里要用。注意这个 Key 不要提交到 Git 仓库建议放在环境变量里。Base URL 用 https://taotoken.net/api 这是不带 UTM 的纯 API 地址配置到客户端里。模型 ID 根据你当前要调试的模型填比如你想验证工具调用能力可以先用一个对 Function Calling 支持较好的模型 ID。这三件套——Base URL、Key、Model ID——是后面所有配置的核心缺一个都跑不通。如果你用的是 Claude Code 这类编码 Agent它的配置方式和普通 API 客户端略有不同。Claude Code 需要设置ANTHROPIC_BASE_URL和ANTHROPIC_API_KEY两个环境变量Base URL 同样指向 https://taotoken.net/api 。配置文档在 https://taotoken.net/doc 有详细说明建议对照着改。对于长期做编码和 Agent 开发的场景可以考虑 Coding Plan它在调用额度和模型切换上更适合高频调试。入口在 https://taotoken.net/coding-plan 。如果你只是想先验证模型对 MCP 工具的调用效果用模型对话页面快速试一下也行https://taotoken.net/chat 。这里有个容易踩的坑很多人把 Base URL 写成带/v1的地址结果请求 404。TaoToken 的 API 地址就是 https://taotoken.net/api 具体路径由客户端自己拼接你不要手动加后缀。另外Key 的权限要确认包含你要调的模型否则会返回 401 或权限错误。配置完成后建议先用一个最简单的 curl 请求验证通道是否通curl https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: your-model-id, messages: [{role: user, content: ping}] }如果返回正常的 JSON 响应说明 Key 和 Base URL 都没问题。这一步别跳过后面 MCP 调试报错时你能快速判断是通道问题还是工具问题。3. fastmcp uv 可复制配置从零搭一个 Word MCP 服务现在进入正题用 fastmcp 搭一个最小可用的 MCP 服务。为什么用 uv 管理依赖pip 会直接下载到全局环境不讲究环境隔离anaconda 体积过大对云原生环境不友好。uv 兼顾了隔离和速度而且uv init之后会生成一个类似package.json的.toml文件依赖声明清晰。先初始化项目uv init word-mcp cd word-mcp uv add fastmcp python-docxuv add会自动写入pyproject.toml并锁定版本。你的pyproject.toml大概长这样[project] name word-mcp version 0.1.0 requires-python 3.11 dependencies [ fastmcp2.0.0, python-docx1.1.0, ]接下来写服务端。fastmcp 用装饰器定义 Tool、Prompt、Resource非常直观。新建server.pyfrom fastmcp import FastMCP from docx import Document import os mcp FastMCP(word-mcp) DOC_PATH os.environ.get(WORD_DOC_PATH, ./demo.docx) mcp.tool() def create_doc(path: str DOC_PATH) - str: 创建一个新的 Word 文档。当用户需要新建文档时调用此工具。 参数 path 为文档保存路径默认为 ./demo.docx。 doc Document() doc.add_paragraph(这是一个由 MCP 工具创建的文档。) doc.save(path) return f文档已创建{path} mcp.tool() def add_paragraph(text: str, path: str DOC_PATH) - str: 向已有 Word 文档追加一个段落。当用户需要写入内容时调用。 参数 text 为段落文本path 为文档路径。 doc Document(path) doc.add_paragraph(text) doc.save(path) return f已追加段落{text} mcp.tool() def read_doc(path: str DOC_PATH) - str: 读取 Word 文档的全部段落文本。当用户需要查看文档内容时调用。 doc Document(path) content \n.join(p.text for p in doc.paragraphs) return content or 文档为空 mcp.prompt() def word_assistant() - str: Word 文档助手的系统提示词。 return 你是一个 Word 文档助手可以创建、追加和读取文档内容。调用工具前先确认用户意图。 mcp.resource(doc://current) def current_doc() - str: 当前文档的实时内容资源。 if not os.path.exists(DOC_PATH): return 文档尚未创建 doc Document(DOC_PATH) return \n.join(p.text for p in doc.paragraphs) if __name__ __main__: mcp.run()几个关键点。第一工具函数的 docstring 一定要写清楚因为最终大模型会吸收这些描述来判断什么时候调哪个工具。多写多行注释不是啰嗦是给模型看的接口文档。第二mcp.prompt()定义的是提示词模板开头做身份认同让模型找准定位后面可以插入参数。第三mcp.resource()暴露的是运行时资源比如当前文档内容模型可以在需要时读取。启动服务uv run server.pyfastmcp 脚手架有一层语法糖支持直接mcp run server.py不需要在main里写run。不过我个人习惯在main里写清楚调试时更可控。如果你公司已有业务服务不需要完全另开一个 MCP 服务器。在业务服务里选好 endpoint加上一圈mcp装饰器让原本的业务服务本身变成 MCP 服务器即可。这样改造成本最低。4. 验证请求与成功结果用 Function Calling 串联 Agent服务跑起来了怎么验证它真的能被大模型调用这里分两步先单点测试再交互测试。单点测试是直接调工具函数确认逻辑没问题交互测试才是让模型通过 Function Calling 去调。单点测试可以直接用 Python 调uv run python -c from server import create_doc, add_paragraph, read_doc print(create_doc(./test.docx)) print(add_paragraph(第一段测试内容, ./test.docx)) print(read_doc(./test.docx)) 如果三个函数都返回预期结果说明工具本身没问题。这一步别省否则交互测试报错时你分不清是工具 bug 还是模型调用问题。交互测试需要一个 MCP 客户端。可以用 OpenMCP Client 或 MCP Inspector 来调试验证。MCP Inspector 是运行时工具支持接入 LLM 调试OpenMCP Client 是一体化插件遵循 OVX 协议。两者都支持 MCP 接入和 LLM 调试。如果你想要命令行方式MCP-CLI 也能用。配置客户端时把 MCP 服务器地址填进去然后在 LLM 配置里填 TaoToken 的三件套{ mcpServers: { word-mcp: { command: uv, args: [run, server.py], cwd: /path/to/word-mcp } }, llm: { baseUrl: https://taotoken.net/api, apiKey: your-taotoken-key, model: your-model-id } }注意cwd要填你项目的绝对路径否则 uv 找不到pyproject.toml。启动客户端后在对话里输入「帮我创建一个 Word 文档然后写入一段关于 MCP 的介绍」观察模型是否返回tool_calls以及工具执行结果是否正确回传。成功的结果是这样的模型先调用create_doc拿到返回后调用add_paragraph最后可能调用read_doc确认内容。整个过程在客户端日志里能看到完整的 tool_calls 链路。如果模型没有调工具而是直接编了一段文本回复说明工具的 docstring 描述不够清晰或者模型本身对 Function Calling 支持不好换个模型 ID 再试。验证模型对工具的调用能力时可以用模型对话页面快速对比https://taotoken.net/chat 。把同一段用户输入发给不同模型看谁的 tool_calls 更准确。5. 本篇常见错排查401、local proxy failed、reading choices、OAuth调试 MCP Function Calling 时报错集中在几个地方。我按真实遇到的频率排一下。401 Unauthorized。最常见的原因是 Key 没配对或者环境变量没生效。检查TAOTOKEN_API_KEY是否真的导出到了当前 shellecho $TAOTOKEN_API_KEY看一下。另一个原因是 Base URL 写错了比如写成了https://taotoken.net/api/v1多加了路径。正确写法就是 https://taotoken.net/api 让客户端自己拼。如果 Key 权限不包含当前模型也会 401去 https://taotoken.net/api-keys 确认一下。local proxy failed。这个报错通常出现在客户端配置了本地代理但代理没启动或端口不对。检查你的客户端网络配置把代理关掉或改成直连。如果你在容器里跑 MCP 服务器确认容器网络能访问外网。reading choices 相关报错。这通常是模型返回结构不符合预期比如你期望choices[0].message.tool_calls但模型返回的是纯文本。原因可能是模型 ID 不支持 Function Calling或者请求里tools字段格式不对。检查你的请求体tools数组里每个工具要有type: function和function对象function里包含name、description、parameters。参数 schema 用标准 JSON Schema。OAuth 相关报错。如果你用的是 Claude Code 或类似需要 OAuth 的客户端报 OAuth 错误通常是认证流程没走完。Claude Code 的配置要写全三件套Base URL 用 https://taotoken.net/api Key 用你的 TaoToken KeyModel ID 填你要用的模型。三个缺一个都会认证失败。配置文档在 https://taotoken.net/doc 有完整示例。还有一个隐蔽的坑MCP 服务器启动时cwd不对导致python-docx找不到文件路径。工具函数里用相对路径时实际工作目录是客户端启动服务器时的目录不是server.py所在目录。建议在工具函数里用绝对路径或者通过环境变量传入文档路径。排查顺序建议先 curl 验证 API 通道再单点测试工具函数最后交互测试。这样能把问题范围快速缩小到某一层。6. 语义一致 CTA把 MCP 服务接入你的 Agent 工作流跑通最小 MCP 服务只是起点。接下来你要做的是把它接入真实的 Agent 工作流并且让工具调用稳定可控。第一步把调试好的 MCP 服务器注册到你的 Agent 客户端。如果你用的是 Cline 或类似支持 MCP 的编码 Agent在配置里加上 MCP 服务器地址和 TaoToken 三件套。Cline MCP 的配置格式和前面 JSON 类似注意command和args要指向你的 uv 环境。第二步封装 Prompt。测试完成后把验证过的提示词封装成mcp.prompt()方便后续复用也方便用户快速定位服务器能力边界。对于复杂的 Prompt可以考虑用 Jinja 模板做大规模组装和拓展。比如教会模型专业领域的冷门知识单靠模型自身能力可能不够通过 Prompt 注入案例和约束效果会好很多。第三步部署为 Web 服务。fastmcp 支持把服务器部署成 HTTP 服务这样多个客户端可以共享同一个 MCP 服务器。部署时注意把文档路径、Key 等敏感信息放到环境变量里不要硬编码。第四步建立验证闭环。Agent 开发部门和算法部分的衔接关键在于建模 Agent 的全生命周期让每个环节可控、可验证、可迭代。你需要回答三个问题如何验证真实业务场景下的结果如何通过验证的反馈迭代系统如何把这些步骤标准化和统一MCP 协议本身提供了一层标准化但业务层的验证逻辑还得你自己搭。长期做编码和 Agent 开发的话Coding Plan 在模型切换和调用额度上更适合高频迭代场景入口在 https://taotoken.net/coding-plan 。需要管理多个 Key 或查看调用情况去控制台 https://taotoken.net/console 。API Key 管理在 https://taotoken.net/api-keys 。接入文档和完整配置示例在 https://taotoken.net/doc 。最后说一个实用技巧MCP 服务器的工具数量不要一次暴露太多。模型在几十个工具里选准确率会下降。按业务域拆成多个 MCP 服务器每个服务器只暴露当前场景需要的工具调用准确率会明显提升。这是我踩过的坑工具堆在一起看着方便实际调试时模型经常选错。