《Agentic Design Patterns》第 10 章导读模型上下文协议MCP本文是对开源书籍《Agentic Design Patterns》第 10 章的解读与导读内容忠实呈现原文并附个人思考。原书在线阅读https://adp.xindoo.xyz/ 翻译项目代码仓库https://github.com/xindoo/agentic-design-patterns前 9 章我们聊了很多智能体内部的模式——提示词链、路由、并行、反思、工具使用、规划、多智能体协作、记忆、学习。但智能体要真正有用光靠脑子不行还得跟外部世界连接——查数据库、发邮件、调 API、控制设备……问题是怎么连传统方式是一个工具写一套接入代码。接 OpenAI 的工具用一套写法接 Anthropic 的又是另一套接 A 数据库一个 SDK接 B 系统又一个 API。每加一个新工具都得改应用代码、改提示词、测试联调……非常痛苦。第 10 章讲的模型上下文协议Model Context ProtocolMCP就是来解决这个问题的用一套标准化协议让任何 LLM 都能连接任何外部系统。一、什么是 MCPAI 时代的通用插座书中有个很形象的比喻MCP 就像通用电源插座标准。在没有标准之前每个电器都有自己的插头形状你得为每个电器配一个专用插座——混乱、低效、扩展性差。有了标准插座之后任何符合标准的电器都能直接插上去用即插即用。MCP 就是 LLM 和外部系统之间的通用插座。它是一个开放标准定义了 LLM如 Gemini、GPT、Claude、Mixtral跟外部应用、数据源、工具之间的通信方式。图 1模型上下文协议MCP——LLM 与外部系统之间的标准化通信层。MCP 基于客户端-服务器架构MCP 服务器对外暴露能力——数据叫资源、交互模板叫提示、可执行函数叫工具MCP 客户端通常是 LLM 宿主应用或 AI 智能体连接服务器、发现能力、调用工具。有了这个标准接入一个新工具就变成了接一个 MCP 服务器不用再为每个 LLM、每个应用单独写集成代码。但书中也特别提醒了两个容易踩的坑第一MCP 不是魔法底层 API 设计很重要。如果只是把一个烂 API 用 MCP 包一层那对智能体来说照样难用。比如票务系统的 API 只能逐条拉取完整票务详情那智能体要总结高优先级工单时就得拉一堆数据慢慢处理——又慢又不准。好的做法是在底层 API 里就加上过滤、排序这些确定性功能帮非确定性的智能体减轻负担。第二数据格式要对智能体友好。MCP 保证的是能连上但不保证连得上能用。比如一个文档存储 API 返回 PDF 文件但智能体不会解析 PDF——连上了也白搭。更好的做法是让 API 返回 Markdown 之类的纯文本格式智能体才能真正读取和处理。二、MCP vs 工具函数调用有什么不一样你可能会问“工具调用不是已经能让 LLM 调外部函数了吗MCP 跟它有啥区别”书中给了一张很清晰的对比表特性工具函数调用模型上下文协议MCP标准化专有、各厂商各搞一套开放标准、跨厂商互操作范围直接调用特定预定义函数更广泛的框架定义发现和通信的完整方式架构LLM 与应用逻辑一对一交互客户端-服务器架构一个客户端连多个服务器发现机制LLM 被明确告知有哪些工具动态发现——客户端可以查询服务器有什么能力可重用性跟特定应用和 LLM 紧耦合MCP 服务器是独立的任何兼容客户端都能用再用个更生活化的类比工具函数调用就像给 AI 一套定制工具——特定型号的扳手、螺丝刀只能干特定的活换个牌子的 AI 可能就用不了MCP就像标准化插座——它本身不提供工具但任何符合标准的工具都能插上来用生态可以无限扩展。简单说工具调用适合简单、固定的场景MCP 适合复杂、需要扩展、需要互操作的系统。三、MCP 的核心概念与交互流程MCP 里有三个核心元素需要分清资源Resources静态数据比如 PDF 文件、数据库记录工具Tools可执行函数能做事情比如发邮件、查 API提示Prompts交互模板指导 LLM 怎么跟资源或工具打交道确保交互结构化、有效。整个交互流程是这样的发现MCP 客户端问服务器你有啥能力服务器返回一个清单——有哪些工具、哪些资源、哪些提示制定请求LLM 决定要用某个工具制定好参数比如要发邮件收件人是谁、主题是什么、正文写啥客户端通信MCP 客户端把 LLM 的请求转换成标准格式发给对应服务器服务器执行MCP 服务器验证请求、调用底层 API比如真的发一封邮件响应与上下文更新服务器把结果返回给客户端客户端再把结果喂给 LLMLLM 继续下一步。这个流程里MCP 还涉及很多实际考量可发现性客户端可以动态查询服务器能力不用重新部署就能接入新工具安全性必须有认证和授权机制控制谁能访问什么、能执行什么操作错误处理工具执行失败、服务器挂了、请求无效……这些错误都得标准化地传回 LLM让它知道出了什么问题、能不能试别的方法本地 vs 远程服务器本地服务器速度快、数据安全远程服务器可共享、可扩展传输机制本地用 STDIO标准输入输出上的 JSON-RPC高效进程间通信远程用 HTTP 流式传输和 SSE服务器发送事件适合 Web 环境。四、九大应用场景MCP 能把智能体的能力边界大大扩展。书中列举了 9 个关键用例数据库集成智能体用自然语言就能查 BigQuery、生成报表、更新记录——不用写 SQL生成媒体编排智能体可以调用图像生成Imagen、视频生成Veo、语音合成Chirp 3 HD、音乐创作Lyria串成完整的内容生产工作流外部 API 交互查天气、拉股价、发邮件、对接 CRM——标准化方式调用任何外部 API基于推理的信息提取超越传统搜索智能体可以分析文本、精确提取特定条款/数字/陈述直接回答复杂问题而不是返回整篇文档自定义工具开发用 FastMCP 之类的框架开发者可以轻松把内部函数或专有系统包装成标准 MCP 工具标准化通信层LLM 和应用之间有一致的通信协议减少集成开销促进互操作复杂工作流编排组合多个 MCP 服务的工具和数据——从数据库拉客户数据 → 生成个性化营销图 → 写定制邮件 → 发送——一条智能体流水线全搞定物联网设备控制用自然语言控制智能家居、工业传感器、机器人金融服务自动化分析市场数据、执行交易、生成个性化理财建议、自动化合规报告——全程安全、标准化。一句话总结MCP 让智能体从只会聊天的模型变成能操作真实世界系统的代理。五、实操示例用 ADK FastMCP 快速搭建说了这么多概念来看看实际怎么用。书中演示了两种方式用现成的 MCP 服务器和自己用 FastMCP 搭一个。方式一接入现成的文件系统 MCP 服务器Google ADK 里可以直接用MCPToolset连接 MCP 服务器。比如连接一个文件系统服务器fromgoogle.adk.agentsimportLlmAgentfromgoogle.adk.tools.mcp_tool.mcp_toolsetimportMCPToolset,StdioServerParameters root_agentLlmAgent(modelgemini-2.0-flash,namefilesystem_assistant_agent,instructionHelp the user manage their files.,tools[MCPToolset(connection_paramsStdioServerParameters(commandnpx,args[-y,modelcontextprotocol/server-filesystem,TARGET_FOLDER_PATH,# 智能体能操作的目录],),# 可选只允许读取操作# tool_filter[list_directory, read_file])],)就这么简单——一个MCPToolset配置进去智能体就获得了文件系统操作能力。npx会自动从 npm 下载并运行 MCP 服务器不用手动安装。方式二用 FastMCP 自己写 MCP 服务器FastMCP 是一个 Python 框架把 MCP 协议的复杂性大大简化了。用装饰器就能把普通 Python 函数变成 MCP 工具fromfastmcpimportFastMCP mcp_serverFastMCP()mcp_server.tooldefgreet(name:str)-str: 生成个性化的问候语。 参数 name: 要问候的人的名字。 返回 问候语字符串。 returnfHello,{name}! Nice to meet you.if__name____main__:mcp_server.run(transporthttp,host127.0.0.1,port8000)就这么几行代码——一个mcp_server.tool装饰器函数就成了 MCP 工具。FastMCP 会自动读取函数的类型提示和文档字符串生成 AI 模型需要的接口规范。省掉了大量手动配置工作。方式三ADK 智能体连接 FastMCP 服务器有了 FastMCP 服务器之后ADK 智能体怎么用呢用HttpServerParameters连接就行fromgoogle.adk.agentsimportLlmAgentfromgoogle.adk.tools.mcp_tool.mcp_toolsetimportMCPToolset,HttpServerParameters FASTMCP_SERVER_URLhttp://localhost:8000root_agentLlmAgent(modelgemini-2.0-flash,namefastmcp_greeter_agent,instructionYou are a friendly assistant that can greet people by their name. Use the greet tool.,tools[MCPToolset(connection_paramsHttpServerParameters(urlFASTMCP_SERVER_URL),tool_filter[greet]# 只允许用 greet 工具)],)整个流程启动 FastMCP 服务器python fastmcp_server.pyADK 智能体通过 HTTP 连接到服务器智能体动态发现有greet工具可用用户说Greet John DoeLLM 决定调用greet工具参数John DoeMCP 客户端把请求发给服务器服务器执行函数返回结果LLM 拿到结果组织成自然语言回复用户。完美的闭环。六、速览问题背景LLM 要成为有效的智能体不能只生成文本还得跟外部环境交互——访问实时数据、使用外部软件。但没有标准化通信方式的话每接入一个工具或数据源都得做定制集成复杂、不可复用、扩展性差。搭建互联的 AI 系统又难又低效。解决方案MCP 充当 LLM 和外部系统之间的通用接口提供标准化方案。它基于客户端-服务器模型——服务器对外暴露工具、数据资源和交互提示LLM 驱动的应用作为客户端动态发现和使用这些能力。标准化促进了可互操作、可重用组件的生态系统大大简化了复杂智能体工作流的开发。实践建议构建需要跟各种外部工具、数据源、API 交互的复杂、可扩展或企业级智能体系统时使用 MCP。当不同 LLM 和工具之间的互操作性很重要、或者智能体需要动态发现新能力而不用重新部署时MCP 是理想选择。简单应用、工具数量固定的话直接工具函数调用可能就够了。关键要点模型上下文协议MCP是一个开放标准促进 LLM 与外部应用、数据源和工具之间的标准化通信它采用客户端-服务器架构定义了资源、提示和工具的公开与使用方式ADK 支持使用现成的 MCP 服务器也支持通过 MCP 服务器公开 ADK 工具FastMCP 简化了 MCP 服务器的开发特别是用 Python 实现的工具MCP 让 LLM 和智能体能与真实世界系统交互、访问动态信息、执行超越文本生成的操作。结语与个人思考MCP 这一章看似在讲一个技术协议但它背后的趋势其实很重要智能体的能力边界正在从模型本身能做什么转向生态系统能提供什么。在 MCP 之前每个智能体应用都是一座孤岛——工具是定制的、接入是一次性的、换个模型就得重来。MCP 把工具接入这件事标准化了之后整个生态就活了工具开发者只需要写一个 MCP 服务器所有兼容 MCP 的智能体都能用智能体开发者只需要支持 MCP 客户端就能接入整个 MCP 生态的工具最终用户受益于丰富的工具选择和即插即用的体验。这很像当年 USB 标准之于外设或者 HTTP 协议之于 Web 服务——标准化带来生态繁荣。但 MCP 也不是没有挑战。我觉得有几个问题值得关注第一个是安全边界。智能体通过 MCP 能调用的工具越多安全风险就越大。一个恶意的 MCP 服务器可能窃取数据一个被劫持的智能体可能通过 MCP 搞破坏。认证、授权、审计、沙箱……这些安全机制必须跟得上生态扩展的速度。第二个是质量参差不齐。MCP 降低了工具开发的门槛但也意味着工具质量可能参差不齐。有的工具文档清晰、设计合理有的可能返回格式混乱、错误处理糟糕。智能体遇到烂工具怎么办怎么评估工具质量怎么容错这些都是生态成熟过程中需要解决的问题。第三个是发现的效率。MCP 支持动态发现工具但如果工具太多了呢智能体每次都要先问你有啥工具然后从上百个工具里找到合适的——光发现过程就消耗很多 token。怎么给工具分类、怎么让智能体快速找到最相关的工具也是个实际问题。总的来说MCP 的方向是对的。智能体的未来一定是生态化的——没有任何一家公司能提供所有工具也没有任何一个模型能搞定所有事情。标准化协议是构建这个生态的基础设施。而现在这个基础设施才刚刚开始搭建。下一步建议阅读第 11 章目标设定与监控Goal Setting and Monitoring——看看智能体怎么设定目标、追踪进度、确保自己走在正确的方向上。本文基于开源书籍《Agentic Design Patterns》https://github.com/xindoo/agentic-design-patterns 在线阅读 https://adp.xindoo.xyz/ 整理供学习交流版权归原作者所有。 
长河君 · 2026/10/10 9:12:31 · 阅读 1.2k 《Agentic Design Patterns》第 10 章导读：模型上下文协议（MCP）
《Agentic Design Patterns》第 10 章导读模型上下文协议MCP本文是对开源书籍《Agentic Design Patterns》第 10 章的解读与导读内容忠实呈现原文并附个人思考。原书在线阅读https://adp.xindoo.xyz/ 翻译项目代码仓库https://github.com/xindoo/agentic-design-patterns前 9 章我们聊了很多智能体内部的模式——提示词链、路由、并行、反思、工具使用、规划、多智能体协作、记忆、学习。但智能体要真正有用光靠脑子不行还得跟外部世界连接——查数据库、发邮件、调 API、控制设备……问题是怎么连传统方式是一个工具写一套接入代码。接 OpenAI 的工具用一套写法接 Anthropic 的又是另一套接 A 数据库一个 SDK接 B 系统又一个 API。每加一个新工具都得改应用代码、改提示词、测试联调……非常痛苦。第 10 章讲的模型上下文协议Model Context ProtocolMCP就是来解决这个问题的用一套标准化协议让任何 LLM 都能连接任何外部系统。一、什么是 MCPAI 时代的通用插座书中有个很形象的比喻MCP 就像通用电源插座标准。在没有标准之前每个电器都有自己的插头形状你得为每个电器配一个专用插座——混乱、低效、扩展性差。有了标准插座之后任何符合标准的电器都能直接插上去用即插即用。MCP 就是 LLM 和外部系统之间的通用插座。它是一个开放标准定义了 LLM如 Gemini、GPT、Claude、Mixtral跟外部应用、数据源、工具之间的通信方式。图 1模型上下文协议MCP——LLM 与外部系统之间的标准化通信层。MCP 基于客户端-服务器架构MCP 服务器对外暴露能力——数据叫资源、交互模板叫提示、可执行函数叫工具MCP 客户端通常是 LLM 宿主应用或 AI 智能体连接服务器、发现能力、调用工具。有了这个标准接入一个新工具就变成了接一个 MCP 服务器不用再为每个 LLM、每个应用单独写集成代码。但书中也特别提醒了两个容易踩的坑第一MCP 不是魔法底层 API 设计很重要。如果只是把一个烂 API 用 MCP 包一层那对智能体来说照样难用。比如票务系统的 API 只能逐条拉取完整票务详情那智能体要总结高优先级工单时就得拉一堆数据慢慢处理——又慢又不准。好的做法是在底层 API 里就加上过滤、排序这些确定性功能帮非确定性的智能体减轻负担。第二数据格式要对智能体友好。MCP 保证的是能连上但不保证连得上能用。比如一个文档存储 API 返回 PDF 文件但智能体不会解析 PDF——连上了也白搭。更好的做法是让 API 返回 Markdown 之类的纯文本格式智能体才能真正读取和处理。二、MCP vs 工具函数调用有什么不一样你可能会问“工具调用不是已经能让 LLM 调外部函数了吗MCP 跟它有啥区别”书中给了一张很清晰的对比表特性工具函数调用模型上下文协议MCP标准化专有、各厂商各搞一套开放标准、跨厂商互操作范围直接调用特定预定义函数更广泛的框架定义发现和通信的完整方式架构LLM 与应用逻辑一对一交互客户端-服务器架构一个客户端连多个服务器发现机制LLM 被明确告知有哪些工具动态发现——客户端可以查询服务器有什么能力可重用性跟特定应用和 LLM 紧耦合MCP 服务器是独立的任何兼容客户端都能用再用个更生活化的类比工具函数调用就像给 AI 一套定制工具——特定型号的扳手、螺丝刀只能干特定的活换个牌子的 AI 可能就用不了MCP就像标准化插座——它本身不提供工具但任何符合标准的工具都能插上来用生态可以无限扩展。简单说工具调用适合简单、固定的场景MCP 适合复杂、需要扩展、需要互操作的系统。三、MCP 的核心概念与交互流程MCP 里有三个核心元素需要分清资源Resources静态数据比如 PDF 文件、数据库记录工具Tools可执行函数能做事情比如发邮件、查 API提示Prompts交互模板指导 LLM 怎么跟资源或工具打交道确保交互结构化、有效。整个交互流程是这样的发现MCP 客户端问服务器你有啥能力服务器返回一个清单——有哪些工具、哪些资源、哪些提示制定请求LLM 决定要用某个工具制定好参数比如要发邮件收件人是谁、主题是什么、正文写啥客户端通信MCP 客户端把 LLM 的请求转换成标准格式发给对应服务器服务器执行MCP 服务器验证请求、调用底层 API比如真的发一封邮件响应与上下文更新服务器把结果返回给客户端客户端再把结果喂给 LLMLLM 继续下一步。这个流程里MCP 还涉及很多实际考量可发现性客户端可以动态查询服务器能力不用重新部署就能接入新工具安全性必须有认证和授权机制控制谁能访问什么、能执行什么操作错误处理工具执行失败、服务器挂了、请求无效……这些错误都得标准化地传回 LLM让它知道出了什么问题、能不能试别的方法本地 vs 远程服务器本地服务器速度快、数据安全远程服务器可共享、可扩展传输机制本地用 STDIO标准输入输出上的 JSON-RPC高效进程间通信远程用 HTTP 流式传输和 SSE服务器发送事件适合 Web 环境。四、九大应用场景MCP 能把智能体的能力边界大大扩展。书中列举了 9 个关键用例数据库集成智能体用自然语言就能查 BigQuery、生成报表、更新记录——不用写 SQL生成媒体编排智能体可以调用图像生成Imagen、视频生成Veo、语音合成Chirp 3 HD、音乐创作Lyria串成完整的内容生产工作流外部 API 交互查天气、拉股价、发邮件、对接 CRM——标准化方式调用任何外部 API基于推理的信息提取超越传统搜索智能体可以分析文本、精确提取特定条款/数字/陈述直接回答复杂问题而不是返回整篇文档自定义工具开发用 FastMCP 之类的框架开发者可以轻松把内部函数或专有系统包装成标准 MCP 工具标准化通信层LLM 和应用之间有一致的通信协议减少集成开销促进互操作复杂工作流编排组合多个 MCP 服务的工具和数据——从数据库拉客户数据 → 生成个性化营销图 → 写定制邮件 → 发送——一条智能体流水线全搞定物联网设备控制用自然语言控制智能家居、工业传感器、机器人金融服务自动化分析市场数据、执行交易、生成个性化理财建议、自动化合规报告——全程安全、标准化。一句话总结MCP 让智能体从只会聊天的模型变成能操作真实世界系统的代理。五、实操示例用 ADK FastMCP 快速搭建说了这么多概念来看看实际怎么用。书中演示了两种方式用现成的 MCP 服务器和自己用 FastMCP 搭一个。方式一接入现成的文件系统 MCP 服务器Google ADK 里可以直接用MCPToolset连接 MCP 服务器。比如连接一个文件系统服务器fromgoogle.adk.agentsimportLlmAgentfromgoogle.adk.tools.mcp_tool.mcp_toolsetimportMCPToolset,StdioServerParameters root_agentLlmAgent(modelgemini-2.0-flash,namefilesystem_assistant_agent,instructionHelp the user manage their files.,tools[MCPToolset(connection_paramsStdioServerParameters(commandnpx,args[-y,modelcontextprotocol/server-filesystem,TARGET_FOLDER_PATH,# 智能体能操作的目录],),# 可选只允许读取操作# tool_filter[list_directory, read_file])],)就这么简单——一个MCPToolset配置进去智能体就获得了文件系统操作能力。npx会自动从 npm 下载并运行 MCP 服务器不用手动安装。方式二用 FastMCP 自己写 MCP 服务器FastMCP 是一个 Python 框架把 MCP 协议的复杂性大大简化了。用装饰器就能把普通 Python 函数变成 MCP 工具fromfastmcpimportFastMCP mcp_serverFastMCP()mcp_server.tooldefgreet(name:str)-str: 生成个性化的问候语。 参数 name: 要问候的人的名字。 返回 问候语字符串。 returnfHello,{name}! Nice to meet you.if__name____main__:mcp_server.run(transporthttp,host127.0.0.1,port8000)就这么几行代码——一个mcp_server.tool装饰器函数就成了 MCP 工具。FastMCP 会自动读取函数的类型提示和文档字符串生成 AI 模型需要的接口规范。省掉了大量手动配置工作。方式三ADK 智能体连接 FastMCP 服务器有了 FastMCP 服务器之后ADK 智能体怎么用呢用HttpServerParameters连接就行fromgoogle.adk.agentsimportLlmAgentfromgoogle.adk.tools.mcp_tool.mcp_toolsetimportMCPToolset,HttpServerParameters FASTMCP_SERVER_URLhttp://localhost:8000root_agentLlmAgent(modelgemini-2.0-flash,namefastmcp_greeter_agent,instructionYou are a friendly assistant that can greet people by their name. Use the greet tool.,tools[MCPToolset(connection_paramsHttpServerParameters(urlFASTMCP_SERVER_URL),tool_filter[greet]# 只允许用 greet 工具)],)整个流程启动 FastMCP 服务器python fastmcp_server.pyADK 智能体通过 HTTP 连接到服务器智能体动态发现有greet工具可用用户说Greet John DoeLLM 决定调用greet工具参数John DoeMCP 客户端把请求发给服务器服务器执行函数返回结果LLM 拿到结果组织成自然语言回复用户。完美的闭环。六、速览问题背景LLM 要成为有效的智能体不能只生成文本还得跟外部环境交互——访问实时数据、使用外部软件。但没有标准化通信方式的话每接入一个工具或数据源都得做定制集成复杂、不可复用、扩展性差。搭建互联的 AI 系统又难又低效。解决方案MCP 充当 LLM 和外部系统之间的通用接口提供标准化方案。它基于客户端-服务器模型——服务器对外暴露工具、数据资源和交互提示LLM 驱动的应用作为客户端动态发现和使用这些能力。标准化促进了可互操作、可重用组件的生态系统大大简化了复杂智能体工作流的开发。实践建议构建需要跟各种外部工具、数据源、API 交互的复杂、可扩展或企业级智能体系统时使用 MCP。当不同 LLM 和工具之间的互操作性很重要、或者智能体需要动态发现新能力而不用重新部署时MCP 是理想选择。简单应用、工具数量固定的话直接工具函数调用可能就够了。关键要点模型上下文协议MCP是一个开放标准促进 LLM 与外部应用、数据源和工具之间的标准化通信它采用客户端-服务器架构定义了资源、提示和工具的公开与使用方式ADK 支持使用现成的 MCP 服务器也支持通过 MCP 服务器公开 ADK 工具FastMCP 简化了 MCP 服务器的开发特别是用 Python 实现的工具MCP 让 LLM 和智能体能与真实世界系统交互、访问动态信息、执行超越文本生成的操作。结语与个人思考MCP 这一章看似在讲一个技术协议但它背后的趋势其实很重要智能体的能力边界正在从模型本身能做什么转向生态系统能提供什么。在 MCP 之前每个智能体应用都是一座孤岛——工具是定制的、接入是一次性的、换个模型就得重来。MCP 把工具接入这件事标准化了之后整个生态就活了工具开发者只需要写一个 MCP 服务器所有兼容 MCP 的智能体都能用智能体开发者只需要支持 MCP 客户端就能接入整个 MCP 生态的工具最终用户受益于丰富的工具选择和即插即用的体验。这很像当年 USB 标准之于外设或者 HTTP 协议之于 Web 服务——标准化带来生态繁荣。但 MCP 也不是没有挑战。我觉得有几个问题值得关注第一个是安全边界。智能体通过 MCP 能调用的工具越多安全风险就越大。一个恶意的 MCP 服务器可能窃取数据一个被劫持的智能体可能通过 MCP 搞破坏。认证、授权、审计、沙箱……这些安全机制必须跟得上生态扩展的速度。第二个是质量参差不齐。MCP 降低了工具开发的门槛但也意味着工具质量可能参差不齐。有的工具文档清晰、设计合理有的可能返回格式混乱、错误处理糟糕。智能体遇到烂工具怎么办怎么评估工具质量怎么容错这些都是生态成熟过程中需要解决的问题。第三个是发现的效率。MCP 支持动态发现工具但如果工具太多了呢智能体每次都要先问你有啥工具然后从上百个工具里找到合适的——光发现过程就消耗很多 token。怎么给工具分类、怎么让智能体快速找到最相关的工具也是个实际问题。总的来说MCP 的方向是对的。智能体的未来一定是生态化的——没有任何一家公司能提供所有工具也没有任何一个模型能搞定所有事情。标准化协议是构建这个生态的基础设施。而现在这个基础设施才刚刚开始搭建。下一步建议阅读第 11 章目标设定与监控Goal Setting and Monitoring——看看智能体怎么设定目标、追踪进度、确保自己走在正确的方向上。本文基于开源书籍《Agentic Design Patterns》https://github.com/xindoo/agentic-design-patterns 在线阅读 https://adp.xindoo.xyz/ 整理供学习交流版权归原作者所有。