背景： 这是我自己的一个旅行项目——一个跑在本地的旅行助手 Agent，基座是 Qwen3-0.6B（RTX 4060），能查攻略（Milvus + RAG）、查天气（和风天气）、查路线（高德地图）。它靠提示词也能调工具，但调用并不稳定，所以我正在基于这个项目做微调。这篇讲数据那一环：训练用的对话轨迹是怎么造出来的。

大模型微调最容易被误解的地方，是把“训练数据”理解成一堆问题和答案。对 Agent 来说，真正要学的是一条可执行的轨迹：什么时候应该追问，什么时候应该调用工具，工具参数如何组织，工具返回后怎样继续工作，最后怎样把结果说给用户。

MCP（Model Context Protocol，模型上下文协议）是一套开放协议，用于规范 LLM 应用与外部工具之间的连接方式：应用侧实现 MCP 客户端（Client），工具侧实现 MCP 服务端（Server）。

它的直接收益是：”N 个应用配 M 个工具”所需的 N×M 段适配代码，收敛为 N+M 段。

具体来说：你想让 Agent 能查 GitHub、查数据库、发 Slack，得写三段适配代码（各一套认证、参数格式、错误处理）；再写一个跑在 IDE 里的 Agent，又是三段，内容几乎一样；哪天工具那边换个实现，每个 Agent 里都得跟着改一遍——它们明明在做同一件事。

MCP 把这两个方向都解开了：换 Agent，工具侧不用动；换工具实现，应用侧不用动。两边甚至可以是不同的人、用不同的语言写的。

这篇讲这层协议长什么样：分了哪两层、有哪两种传输、一次连接要走哪三步，以及工具接进来之后怎么进到 Agent 的工具表里。

Function Calling（函数调用）是模型的一项输出能力：模型不只输出自然语言，还能输出一段结构化的调用申请——“我要调用这个函数，参数是这些”。

这个名字起得有误导性，先说清楚最容易搞错的一点：

模型不执行任何函数。 它只是把”我想调什么”表达成一个 JSON 对象。真正去执行的永远是调用方——你的代码。

谁做	做什么
模型	决定要不要调、调哪个、参数填什么，输出成结构化数据
你的代码	接收这个申请，执行，把结果发回去

所以更准确的说法是”函数调用申请“。这个往返的完整形状（tool_use / tool_result 怎么配对）上一篇已经拆过了，这里只记住分工：模型负责开口，你负责动手。