发布时间2026-07-12标签AI AgentLLMMCP标准化协议工程实践系列导航上一篇AI Agent 工程实践13Tool Calling——Agent 为什么要学会用工具下一篇AI Agent 工程实践15RAG 真正的瓶颈不是检索而是知识治理本文是 [AI Agent 工程实践] 系列的第 14 篇第二季 · 工程实现。去年我写了三个 Agent 项目用了三个框架Claude Desktop、LangChain、自己裸写。同一个查数据库的工具我写了三遍。不是因为逻辑不同——查询逻辑完全一样但每个框架要求不同的声明格式、不同的调用方式、不同的错误处理。我突然意识到Agent 的手已经标准化了Function Call但手抓的工具却没有统一接口。每个框架都是自己的插座你换个房间就得换插头。直到我理解了 MCP 在干什么——它不是又一个工具框架而是一个工具的 USB 协议。插一次哪里都能用。本文你将学到✓ 为什么 Agent 的工具需要标准化——以及没有标准化时多痛苦✓ MCP 的本质不是框架是协议——Model ↔ MCP ↔ 外部世界✓ Function Calling / Tool Calling / MCP 三者的精确区别和层级关系✓ MCP 的完整架构Host → Client → Protocol → Server → Resources/Tools适合阅读✓ 在不同 Agent 框架之间切换过、被工具适配折磨过的人✓ 听过 MCP 但不清楚它和 Function Call 有什么区别的人✓ 想给团队搭一套写一次、到处用的工具生态的人问题背景第13篇讲清楚了 Tool Calling 的四件套Registry / Schema / Selection / Retry。这套设计在一个 Agent 内部跑得很顺。但问题来了工具是写了可它只属于这一个 Agent。换个框架全要重写。这不是假设是真实困境。我踩过的坑Claude Desktop 要求 MCP 格式——工具必须实现 MCP ServerLangChain 要求BaseTool子类——工具必须继承它的抽象裸写 FastAPI Agent 要求自定义 Schema——工具按自己的 JSON Schema 来同一个查数据库三个框架三种写法。不是逻辑变了是接入标准不同——就像 USB-C 和 Lightning 和 Micro-USB功能一样插头不同每次换设备就要换线。如果 Agent 的工具能像 USB 一样——一个标准插上即用——会怎样这就是 MCP 要解决的问题。错误尝试第一次为每个框架写适配层最直接的做法——每个框架的工具调用写一遍。用一个 CSV 记下来工具 X 在框架 A 怎么调、在框架 B 怎么调。结果三个框架、十个工具 三十份适配代码。加一个新工具三份全要更新。这不是开发是翻译——把同一个工具的说明书翻成三种方言。第二次自己写一个工具抽象层既然框架不同我在它们上面再封一层——定义自己的 Tool 接口每个框架适配一次然后工具对接口写。结果短期的确省了事。但不久后我又想接入一个新的 Agent 平台Coze。它的工具格式又不一样。我发现自己在维护一个小型 MCP——解决碎片化的方式是加上自己的那一份碎片。两次尝试指向同一个结论工具接入的标准化不能靠自己再封一层解决——它需要一个行业级的协议。一个人的抽象层是碎片一群人的协议才是标准。MCP 就是那个协议。关键观察我把 Agent 工具接入的历史路径画了一条线每一步解决一个问题同时暴露下一个阶段解决了暴露了Prompt 手写—不可靠格式漂移Function CallLLM 能可靠输出工具调用工具怎么管理Tool CallingRegistry/Schema/Selection/Retry跨框架不兼容MCP工具跨框架复用生态还在早期Function Call 决定怎么叫工具MCP 决定工具怎么接入。一个是 LLM 层面的能力一个是协议层面的标准——不是竞争关系是栈上不同的两层。最终方案MCP 作为 Agent 的 USB 协议Model → MCP → 外部世界你给的链路——这是 MCP 的核心架构MCP 的关键设计HostAI 应用和 Server工具通过 MCP 协议通信。Server 只写一次任何实现了 MCP Client 的 Host 都能用。工具和框架解耦了。和 Function Calling / Tool Calling 的精确区别这是全篇的核心——三个概念不是同义词是不同层级的不同东西概念层级负责什么比喻Function CallLLM 层让模型输出结构化函数调用人学会用语言描述动作Tool CallingAgent 层管理工具的选、调、重试人的工具使用技能MCP协议层标准化工具的接入方式USB 接口逐层关系LLM 通过 Function Call 表达我要调db_query参数是 SQLAgent 通过 Tool Calling13 篇的四件套决定该不该调、怎么调、失败了怎么办MCP 决定db_query这个工具怎么被 Agent 发现和连接一句话Function Call 是嘴表达意图Tool Calling 是脑决策治理MCP 是插座标准化接入。三者在同一栈上但不在同一层。MCP Server 的实际效果写一个 MCP Server三个框架通用# mcp-server-db.yaml name: database-tools tools: - db_query: schema: query.json # 一份 Schema - db_list_tables: schema: list.json不改一行工具代码Claude Desktop加一行mcp-server-db.yaml到配置Cursor同一份 yaml你的 FastAPI Agent同一份 yaml这就是 MCP 的USB 效应写一次哪里都能插。架构图 / 流程图MCP 的会话生命周期关键发现Discovery阶段——Server 主动暴露它能提供什么工具Host 注册到自己的 Tool Calling 系统13 篇的 Registry。MCP 不是被动等待调用是主动声明能力。代码或配置示例MCP Server 声明 vs 直接 Function Call直接 Function Call框架锁死# 每个框架写一次 # Claude 版本 claude_tool def db_query(sql: str) - list: ... # LangChain 版本 class DBQueryTool(BaseTool): ... # 自定义版本 async def db_query_handler(request): ...MCP Server写一次到处用{ name: db_query, description: Execute a read-only SQL query, inputSchema: { type: object, properties: { sql: { type: string, description: SQL SELECT statement } }, required: [sql] } }# mcp_server.py —— 这是唯一要写的地方 server.tool() async def db_query(sql: str) - list[dict]: Execute a read-only SQL query validate_readonly(sql) # 安全约束 return await database.fetch_all(sql)对比触目惊心MCP 模式下工具逻辑只写一次Schema 声明一次三个框架共享。从写 N 遍到写 1 遍差的就是一个协议。设计权衡候选方案优点缺点为什么不选每个框架写适配灵活、无依赖重复劳动、不可持续N × M 的适配矩阵自己抽象一层短期省事自己成为新碎片一个人的抽象 ≠ 行业标准用 MCP 协议跨框架、生态在长协议还在早期、工具覆盖不全选择理由唯一有希望结束碎片化的方向MCP 不是银弹。它的生态还在早期——不是所有工具都有 MCP Server不是所有框架都支持 MCP Client。但方向是对的协议级标准化永远比框架级二次封装更有生命力。HTTP 没被某个框架的封装版取代USB 没被某个厂商的私有接口取代——标准协议胜出的逻辑从来没变过。总结✅ MCP 不是又一个工具框架是工具的 USB 协议——解决写一次、到处用。✅ 接入碎片化是 Agent 工具生态的最大痛点——每个框架有自己的插座换框架就得换插头。✅ Function CallLLM 层、Tool CallingAgent 层、MCP协议层——三者不是竞争是栈上不同层级各自解决各自的问题。✅ MCP 架构Host → Client → Protocol → Server → Resources/Tools。Server 主动暴露能力Host 注册后使用。✅ MCP 生态还在早期但方向是对的——协议级标准化永远比框架级封装更有生命力。参考资料MCP 官方文档Model Context Protocol→ 协议规范、Server/Client 开发指南第 13 篇Tool Calling→ MCP 接入后的上层治理Registry/Schema/Selection/RetryOpenAI Function Calling 文档→ LLM 层的能力基础MCP 的下层依赖Anthropic — MCP Announcement→ MCP 的设计动机与USB 协议类比LangChain — MCP 集成文档→ 框架如何作为 MCP Host 接入工具系列导航上一篇AI Agent 工程实践13Tool Calling——Agent 为什么要学会用工具下一篇 AI Agent 工程实践15RAG 真正的瓶颈不是检索而是知识治理本文是 [AI Agent 工程实践] 系列的第 14 篇第二季 · 工程实现。
发布时间2026-07-12标签AI AgentLLMMCP标准化协议工程实践系列导航上一篇AI Agent 工程实践13Tool Calling——Agent 为什么要学会用工具下一篇AI Agent 工程实践15RAG 真正的瓶颈不是检索而是知识治理本文是 [AI Agent 工程实践] 系列的第 14 篇第二季 · 工程实现。去年我写了三个 Agent 项目用了三个框架Claude Desktop、LangChain、自己裸写。同一个查数据库的工具我写了三遍。不是因为逻辑不同——查询逻辑完全一样但每个框架要求不同的声明格式、不同的调用方式、不同的错误处理。我突然意识到Agent 的手已经标准化了Function Call但手抓的工具却没有统一接口。每个框架都是自己的插座你换个房间就得换插头。直到我理解了 MCP 在干什么——它不是又一个工具框架而是一个工具的 USB 协议。插一次哪里都能用。本文你将学到✓ 为什么 Agent 的工具需要标准化——以及没有标准化时多痛苦✓ MCP 的本质不是框架是协议——Model ↔ MCP ↔ 外部世界✓ Function Calling / Tool Calling / MCP 三者的精确区别和层级关系✓ MCP 的完整架构Host → Client → Protocol → Server → Resources/Tools适合阅读✓ 在不同 Agent 框架之间切换过、被工具适配折磨过的人✓ 听过 MCP 但不清楚它和 Function Call 有什么区别的人✓ 想给团队搭一套写一次、到处用的工具生态的人问题背景第13篇讲清楚了 Tool Calling 的四件套Registry / Schema / Selection / Retry。这套设计在一个 Agent 内部跑得很顺。但问题来了工具是写了可它只属于这一个 Agent。换个框架全要重写。这不是假设是真实困境。我踩过的坑Claude Desktop 要求 MCP 格式——工具必须实现 MCP ServerLangChain 要求BaseTool子类——工具必须继承它的抽象裸写 FastAPI Agent 要求自定义 Schema——工具按自己的 JSON Schema 来同一个查数据库三个框架三种写法。不是逻辑变了是接入标准不同——就像 USB-C 和 Lightning 和 Micro-USB功能一样插头不同每次换设备就要换线。如果 Agent 的工具能像 USB 一样——一个标准插上即用——会怎样这就是 MCP 要解决的问题。错误尝试第一次为每个框架写适配层最直接的做法——每个框架的工具调用写一遍。用一个 CSV 记下来工具 X 在框架 A 怎么调、在框架 B 怎么调。结果三个框架、十个工具 三十份适配代码。加一个新工具三份全要更新。这不是开发是翻译——把同一个工具的说明书翻成三种方言。第二次自己写一个工具抽象层既然框架不同我在它们上面再封一层——定义自己的 Tool 接口每个框架适配一次然后工具对接口写。结果短期的确省了事。但不久后我又想接入一个新的 Agent 平台Coze。它的工具格式又不一样。我发现自己在维护一个小型 MCP——解决碎片化的方式是加上自己的那一份碎片。两次尝试指向同一个结论工具接入的标准化不能靠自己再封一层解决——它需要一个行业级的协议。一个人的抽象层是碎片一群人的协议才是标准。MCP 就是那个协议。关键观察我把 Agent 工具接入的历史路径画了一条线每一步解决一个问题同时暴露下一个阶段解决了暴露了Prompt 手写—不可靠格式漂移Function CallLLM 能可靠输出工具调用工具怎么管理Tool CallingRegistry/Schema/Selection/Retry跨框架不兼容MCP工具跨框架复用生态还在早期Function Call 决定怎么叫工具MCP 决定工具怎么接入。一个是 LLM 层面的能力一个是协议层面的标准——不是竞争关系是栈上不同的两层。最终方案MCP 作为 Agent 的 USB 协议Model → MCP → 外部世界你给的链路——这是 MCP 的核心架构MCP 的关键设计HostAI 应用和 Server工具通过 MCP 协议通信。Server 只写一次任何实现了 MCP Client 的 Host 都能用。工具和框架解耦了。和 Function Calling / Tool Calling 的精确区别这是全篇的核心——三个概念不是同义词是不同层级的不同东西概念层级负责什么比喻Function CallLLM 层让模型输出结构化函数调用人学会用语言描述动作Tool CallingAgent 层管理工具的选、调、重试人的工具使用技能MCP协议层标准化工具的接入方式USB 接口逐层关系LLM 通过 Function Call 表达我要调db_query参数是 SQLAgent 通过 Tool Calling13 篇的四件套决定该不该调、怎么调、失败了怎么办MCP 决定db_query这个工具怎么被 Agent 发现和连接一句话Function Call 是嘴表达意图Tool Calling 是脑决策治理MCP 是插座标准化接入。三者在同一栈上但不在同一层。MCP Server 的实际效果写一个 MCP Server三个框架通用# mcp-server-db.yaml name: database-tools tools: - db_query: schema: query.json # 一份 Schema - db_list_tables: schema: list.json不改一行工具代码Claude Desktop加一行mcp-server-db.yaml到配置Cursor同一份 yaml你的 FastAPI Agent同一份 yaml这就是 MCP 的USB 效应写一次哪里都能插。架构图 / 流程图MCP 的会话生命周期关键发现Discovery阶段——Server 主动暴露它能提供什么工具Host 注册到自己的 Tool Calling 系统13 篇的 Registry。MCP 不是被动等待调用是主动声明能力。代码或配置示例MCP Server 声明 vs 直接 Function Call直接 Function Call框架锁死# 每个框架写一次 # Claude 版本 claude_tool def db_query(sql: str) - list: ... # LangChain 版本 class DBQueryTool(BaseTool): ... # 自定义版本 async def db_query_handler(request): ...MCP Server写一次到处用{ name: db_query, description: Execute a read-only SQL query, inputSchema: { type: object, properties: { sql: { type: string, description: SQL SELECT statement } }, required: [sql] } }# mcp_server.py —— 这是唯一要写的地方 server.tool() async def db_query(sql: str) - list[dict]: Execute a read-only SQL query validate_readonly(sql) # 安全约束 return await database.fetch_all(sql)对比触目惊心MCP 模式下工具逻辑只写一次Schema 声明一次三个框架共享。从写 N 遍到写 1 遍差的就是一个协议。设计权衡候选方案优点缺点为什么不选每个框架写适配灵活、无依赖重复劳动、不可持续N × M 的适配矩阵自己抽象一层短期省事自己成为新碎片一个人的抽象 ≠ 行业标准用 MCP 协议跨框架、生态在长协议还在早期、工具覆盖不全选择理由唯一有希望结束碎片化的方向MCP 不是银弹。它的生态还在早期——不是所有工具都有 MCP Server不是所有框架都支持 MCP Client。但方向是对的协议级标准化永远比框架级二次封装更有生命力。HTTP 没被某个框架的封装版取代USB 没被某个厂商的私有接口取代——标准协议胜出的逻辑从来没变过。总结✅ MCP 不是又一个工具框架是工具的 USB 协议——解决写一次、到处用。✅ 接入碎片化是 Agent 工具生态的最大痛点——每个框架有自己的插座换框架就得换插头。✅ Function CallLLM 层、Tool CallingAgent 层、MCP协议层——三者不是竞争是栈上不同层级各自解决各自的问题。✅ MCP 架构Host → Client → Protocol → Server → Resources/Tools。Server 主动暴露能力Host 注册后使用。✅ MCP 生态还在早期但方向是对的——协议级标准化永远比框架级封装更有生命力。参考资料MCP 官方文档Model Context Protocol→ 协议规范、Server/Client 开发指南第 13 篇Tool Calling→ MCP 接入后的上层治理Registry/Schema/Selection/RetryOpenAI Function Calling 文档→ LLM 层的能力基础MCP 的下层依赖Anthropic — MCP Announcement→ MCP 的设计动机与USB 协议类比LangChain — MCP 集成文档→ 框架如何作为 MCP Host 接入工具系列导航上一篇AI Agent 工程实践13Tool Calling——Agent 为什么要学会用工具下一篇 AI Agent 工程实践15RAG 真正的瓶颈不是检索而是知识治理本文是 [AI Agent 工程实践] 系列的第 14 篇第二季 · 工程实现。
