三亩地 三亩地SAN MU DI · CODE DIARY
交流投稿
ARTICLE DETAIL

日记详情

真实记录编程学习的某一天，欢迎挑你感兴趣的翻一翻。

首页/学习日记/日记详情

AI智能体赋能：Tool与MCP两种外部能力调用方案深度解析

发布时间：2026/8/12 14:40:34 三亩地 编程学习日记
AI智能体赋能：Tool与MCP两种外部能力调用方案深度解析

1. 项目概述：当AI智能体需要“动手”

在AI智能体（Agent）的开发实践中，我们常常会面临一个核心问题：如何让一个只会“思考”和“说话”的大语言模型（LLM）真正地“动手”去操作外部世界？无论是查询实时天气、操作数据库，还是调用一个复杂的API，这都需要模型具备执行外部动作的能力。过去一年，围绕这个核心需求，开发者社区主要形成了两种主流的技术范式：Tool（工具调用）和MCP（Model Context Protocol，模型上下文协议）。

乍一看，它们的目标似乎一致——都是为LLM“赋能”。但当你深入项目，尤其是在构建一个需要处理复杂、异构外部系统的生产级Agent时，你会发现这两种方案在理念、架构和适用场景上存在着深刻的差异。选择Tool还是MCP，远不止是技术选型问题，它直接决定了你Agent系统的扩展性、维护成本和长期演进方向。我自己在多个从零到一的Agent项目中，都反复经历了从Tool到MCP，再到两者混合使用的探索过程，踩过不少坑，也积累了一些心得。

简单来说，Tool更像是一种“紧耦合”的赋能方式，你将外部能力（函数）直接“教”给模型，模型在推理时决定调用哪个函数并传入参数。而MCP则倡导一种“松耦合”的架构，它将外部资源（如数据库、搜索引擎、文件系统）抽象为统一的“资源”和“工具”，通过一个标准化的协议与模型交互，让模型能够“发现”并“使用”这些资源，而非仅仅“调用”预设的函数。

这篇文章，我将结合具体的代码示例和架构图（文字描述），为你彻底拆解Tool和MCP的核心原理、实现细节、优劣对比，并分享在不同场景下的选型建议和实操避坑指南。无论你是刚开始接触Agent开发的新手，还是正在为现有系统架构纠结的资深工程师，相信都能从中获得启发。

2. 核心思路拆解：两种赋能哲学的根本分歧

要理解Tool和MCP，我们不能只停留在API调用的层面，而需要深入到它们的设计哲学和所要解决的元问题上。

2.1 Tool（工具调用）：函数即能力的直接映射

Tool，通常通过Function Calling机制实现，是目前最主流、最直接的Agent赋能方式。其核心思想非常直观：将外部能力封装成一个个具名的函数，并连同其详细的描述和参数格式（通常是一个JSON Schema），作为“工具”列表提供给大语言模型。

当模型在对话或任务执行过程中，判断需要调用某个外部能力时，它会在其输出中插入一个特殊的结构化片段，指明要调用的函数名和参数。应用程序（或Agent框架）捕获到这个调用请求后，在本地执行对应的函数，并将执行结果返回给模型，模型再基于结果进行后续的推理和输出。

它的工作流程可以概括为：

  1. 定义工具：开发者编写函数，并为其生成描述（名称、描述、参数schema）。
  2. 提示注入：在每次与模型交互时，将这些工具定义作为系统提示（System Prompt）的一部分发送给模型。
  3. 模型决策：模型根据对话上下文，决定是否、以及如何调用工具。
  4. 本地执行：应用程序解析模型的工具调用请求，在本地执行对应函数。
  5. 结果回传：将函数执行结果（成功或错误）返回给模型，模型继续处理。

一个典型的Tool定义（以OpenAI格式为例）看起来是这样的：

tools = [ { "type": "function", "function": { "name": "get_current_weather", "description": "获取指定城市的当前天气", "parameters": { "type": "object", "properties": { "location": { "type": "string", "description": "城市名，例如：北京，上海" }, "unit": { "type": "string", "enum": ["celsius", "fahrenheit"], "description": "温度单位" } }, "required": ["location"] } } } ]

Tool模式的优势在于：

  • 简单直接：概念清晰，上手极快，与传统的编程思维（定义函数、调用函数）无缝衔接。
  • 控制力强：所有工具都在开发者的完全掌控之下，执行逻辑、错误处理、安全边界都非常明确。
  • 性能高效：工具调用发生在应用进程内，没有额外的网络开销，延迟低。

然而，它的局限性也随着项目复杂度提升而日益凸显：

  • 紧耦合与提示膨胀：所有工具定义都必须硬编码在应用中，并随着工具数量增加，系统提示会变得异常庞大，消耗大量上下文窗口（Context Window），影响模型性能和成本。
  • 静态与僵化：工具的增删改需要修改应用代码并重新部署。模型无法动态发现新能力。
  • 上下文隔离：工具通常只能访问调用时传入的参数，难以维护跨多次调用的状态或上下文（例如，一个需要多步认证的复杂操作）。
  • 异构集成困难：当需要集成来自不同团队、不同技术栈的多种后端服务时，为每个服务都编写一个适配函数的工作量巨大，且难以统一管理。

实操心得：在项目早期或工具数量很少（<10个）时，Tool模式是最高效的选择。但一旦工具列表开始膨胀，或者你需要集成第三方服务，就必须开始考虑架构重构，否则提示词管理会成为噩梦。

2.2 MCP（模型上下文协议）：资源与工具的标准化总线

MCP（Model Context Protocol）是由Anthropic提出并开源的一种协议，它旨在从根本上解决Tool模式面临的扩展性和管理性问题。MCP的核心思想是将外部能力抽象为“资源”（Resources）和“工具”（Tools），并通过一个标准化的、进程间通信（IPC）的协议来暴露它们。

你可以把MCP想象成计算机的USB总线。你的电脑（LLM应用）不需要事先知道所有可能连接的设备（外部能力）的具体驱动。它只需要遵循USB协议。当一个新的U盘、打印机或摄像头（MCP Server）插入时，电脑就能通过协议发现它，并获取其提供的功能描述，然后按需使用。

MCP的核心组件包括：

  1. MCP Server（服务器）：封装了特定领域能力的外部进程。例如，一个“文件系统MCP Server”可以提供读写文件的能力；一个“数据库MCP Server”可以提供查询和操作数据的能力。Server启动后，会通过标准输入输出（stdio）或HTTP等传输层，等待连接。
  2. MCP Client（客户端）：通常是你的LLM应用程序或AI IDE（如Cursor、Claude Desktop）。Client连接到Server，并通过MCP协议进行通信。
  3. MCP Protocol（协议）：定义了一套基于JSON-RPC的请求/响应消息格式，用于Client和Server之间的对话。核心操作包括：
    • initialize：握手与能力协商。
    • tools/list：Client向Server请求可用的工具列表。
    • tools/call：Client调用Server上的某个工具。
    • resources/list：Client向Server请求可用的资源列表（如数据库表、文件目录）。
    • resources/read：Client读取某个资源的内容（如读取文件内容、查询数据库表结构）。

MCP的工作流程是动态和发现式的：

  1. 启动与连接：MCP Server作为独立进程启动。LLM应用（MCP Client）根据配置连接到对应的Server。
  2. 能力发现：Client通过tools/list和resources/list请求，动态获取Server暴露的所有能力和资源描述。这个过程是运行时发生的，无需在应用代码中硬编码。
  3. 按需调用：当LLM需要某项能力时，Client通过tools/call请求调用Server上的工具，或通过resources/read获取资源内容。
  4. 结果返回：Server执行操作，将结果通过协议返回给Client，Client再将其提供给LLM。

MCP模式的优势在于：

  • 动态发现与解耦：能力与主应用解耦，可以独立开发、部署和更新。模型能动态发现新接入的能力，系统扩展性极强。
  • 统一的接口：无论后端是Python脚本、Go服务还是Shell命令，都通过统一的MCP协议暴露，降低了集成复杂度。
  • 丰富的上下文：通过resources，MCP可以为模型提供丰富的、结构化的背景信息（如数据库schema、项目文件树），而不仅仅是调用一个函数。
  • 生态与复用：社区正在构建大量的开源MCP Server（用于SQLite、PostgreSQL、文件系统、搜索引擎等），可以直接复用，避免重复造轮子。

当然，MCP也引入了新的复杂度：

  • 架构复杂：需要维护独立的Server进程，并处理进程间通信、生命周期管理等问题。
  • 延迟增加：相比进程内函数调用，IPC通信会带来额外的延迟。
  • 学习曲线：需要理解MCP协议、Server编写规范等新概念。

核心洞察：Tool和MCP不是简单的“新旧”替代关系。Tool是“让模型调用我预先定义好的函数”，而MCP是“为模型提供一个可以探索和操作的标准化的外部环境”。前者是“赋能”，后者是“接入环境”。

3. 核心细节解析与实操要点

理解了核心理念，我们深入到实现层面，看看在具体项目中如何运用它们，以及有哪些必须注意的细节。

3.1 Tool Calling的实现关键与陷阱

实现一个健壮的Tool Calling机制，远不止定义几个JSON Schema那么简单。以下是几个关键的实操要点：

1. 工具描述的“艺术”模型的调用准确性极度依赖工具描述的质量。模糊的描述会导致误调用或参数错误。

  • 清晰明确：description字段要用模型能理解的自然语言，精确说明工具的用途、适用场景和限制。例如，“获取天气”不如“获取指定城市当前的温度、天气状况和湿度，数据来源为OpenWeatherMap”。
  • 参数约束：在parameters的description中明确参数的格式和示例。对于enum类型，列出所有可能值并解释其含义。
  • 结构化思维：复杂的工具可以拆分成多个步骤更细、功能更单一的工具，这往往比一个“巨无霸”工具效果更好。

2. 错误处理与重试机制模型调用工具可能失败（参数错误、网络超时、权限不足等）。一个健壮的Agent必须能处理这些情况。

  • 结构化错误返回：不要只返回一个错误字符串。应该返回一个结构化的对象，包含错误码、错误信息和可能的修正建议。例如：{"error": true, "code": "NETWORK_ERROR", "message": "无法连接到天气服务", "suggestion": "请检查网络连接，或稍后重试"}。
  • 让模型参与纠错：将错误信息原样返回给模型，并提示它“上次调用失败了，原因是XXX，请根据这个信息调整你的请求或尝试其他方法”。模型通常具备不错的错误理解和调整能力。
  • 设置调用超时和重试：对于可能超时的工具（如网络请求），必须在应用层设置超时限制，并设计合理的重试逻辑（例如，指数退避）。

3. 上下文管理与状态保持Tool本身是无状态的。但如果一个任务需要多步工具调用，且后续调用依赖前一步的结果（例如，先登录获取token，再用token查询数据），就需要在应用层维护会话状态。

  • 状态注入：可以将之前工具调用的关键结果，以摘要的形式插入到后续对话的上下文（如系统提示或用户消息）中。
  • 专用会话工具：对于复杂的多步操作，可以设计一个“会话管理器”工具，用于创建、存储和检索与当前对话相关的状态信息。

4. 安全性考量让模型调用外部工具存在潜在风险（无限循环、敏感信息泄露、恶意操作等）。

  • 权限沙箱：为不同的工具设定执行权限。例如，文件写入工具可能比文件读取工具需要更高级别的授权。
  • 用户确认：对于高风险操作（如删除文件、发送邮件、执行数据库写操作），可以实现一个“用户确认”步骤，在真正执行前，将模型的操作意图以自然语言形式呈现给用户，等待用户明确批准。
  • 输入验证与净化：在执行工具前，务必对模型传入的参数进行严格的验证和净化，防止注入攻击。

3.2 MCP Server的构建与集成实践

构建一个MCP Server是体验其威力的最佳方式。下面以构建一个简单的“记事本”MCP Server为例，展示关键步骤。

1. 选择SDK与初始化Anthropic官方提供了Python/TypeScript/Go的SDK，大大简化了开发。我们以Python为例：

pip install mcp

2. 定义工具（Tools）工具的定义方式与Function Calling类似，但使用的是MCP SDK的类。

from mcp import ClientSession, StdioServerParameters from mcp.server import Server from mcp.server.models import Tool import anyio # 创建MCP Server实例 server = Server("notebook-server") # 定义一个“添加笔记”的工具 @server.list_tools() async def handle_list_tools() -> list[Tool]: return [ Tool( name="add_note", description="向记事本中添加一条新的文本笔记", inputSchema={ "type": "object", "properties": { "title": {"type": "string", "description": "笔记的标题"}, "content": {"type": "string", "description": "笔记的正文内容"}, }, "required": ["title", "content"], }, ), Tool( name="list_notes", description="列出记事本中所有笔记的标题", inputSchema={"type": "object", "properties": {}}, # 无参数 ), ] # 实现工具的处理逻辑 @server.call_tool() async def handle_call_tool(name: str, arguments: dict) -> list[dict]: if name == "add_note": # 模拟保存笔记（实际项目中会写入数据库或文件） note = {"title": arguments["title"], "content": arguments["content"]} # ... 保存逻辑 ... return [{"type": "text", "text": f"笔记 '{arguments['title']}' 已成功添加。"}] elif name == "list_notes": # 模拟返回笔记列表 notes = [{"title": "会议记录"}, {"title": "项目想法"}] notes_text = "\n".join([f"- {n['title']}" for n in notes]) return [{"type": "text", "text": f"当前笔记：\n{notes_text}"}] else: raise ValueError(f"未知工具: {name}")

3. 定义资源（Resources）资源是MCP更强大的概念，它允许Client“读取”结构化的上下文信息。

from mcp.server.models import Resource # 定义一个资源，例如“系统状态报告” @server.list_resources() async def handle_list_resources() -> list[Resource]: return [ Resource( uri="notebook://system/status", name="系统状态", description="当前记事本服务器的运行状态摘要", mimeType="text/plain", ) ] @server.read_resource() async def handle_read_resource(uri: str) -> str: if uri == "notebook://system/status": # 动态生成状态报告 import psutil, datetime status = f""" 记事本服务器状态报告 生成时间：{datetime.datetime.now()} CPU使用率：{psutil.cpu_percent()}% 内存使用率：{psutil.virtual_memory().percent}% 总笔记数：{len(notes)} 条 """ return status raise ValueError(f"未知资源: {uri}")

4. 运行ServerMCP Server通常通过标准输入输出（stdio）与Client通信。

async def main(): async with server.run_stdio_server() as (read_stream, write_stream): # Server会在此处持续运行，处理Client请求 await anyio.Event().wait() if __name__ == "__main__": anyio.run(main)

5. 在Client中集成在支持MCP的客户端（如Claude Desktop）中，你只需要在配置文件中添加这个Server的启动命令即可。对于自定义的LLM应用，你需要使用MCP Client SDK来连接和调用Server。

注意事项：编写MCP Server时，要特别注意资源URI的设计和工具/资源的权限边界。URI应该具有清晰的命名空间（如fs:///home/user/doc.txt,sqlite:///mydb.db/users）。对于可能产生副作用的工具（如写操作），应在描述中明确警告，或者在Server端实现额外的安全检查。

4. 实战对比：从需求出发的选择指南

理论说再多，不如看实战。我们通过几个具体的开发场景，来对比Tool和MCP的抉择。

4.1 场景一：构建一个内部知识库问答Agent

需求：你有一个公司内部的Markdown文档库，需要构建一个Agent，能回答员工基于这些文档的问题。

  • Tool方案：

    1. 编写一个函数search_documents(query: str) -> List[DocumentSnippet]。
    2. 将该函数定义为Tool，描述为“根据问题关键词搜索内部知识库文档”。
    3. 在系统提示中注入这个Tool。
    4. 当用户提问时，模型调用该Tool获取相关文档片段，然后基于这些片段生成答案。痛点：文档库更新后，需要更新Agent的系统提示吗？不一定，因为搜索逻辑在函数内部。但如果增加了新的文档来源（如Confluence API），就需要修改函数并重新部署Agent。

  • MCP方案：

    1. 构建一个knowledge-base-mcp-server。
    2. 该Server暴露两个主要能力：
      • 资源：knowledge://index（列出所有可用的文档分类或最近更新列表）。
      • 工具：search（执行搜索）。
    3. Agent应用启动时连接该Server，动态获取这些能力。
    4. 模型不仅可以调用search工具，还可以在需要时先“读取”knowledge://index资源，了解知识库的总体结构，再提出更精准的搜索查询。优势：知识库Server可以独立迭代（更新搜索算法、添加新数据源），只要协议不变，Agent无需任何修改即可获得新能力。模型对知识库的“感知”也更丰富。

结论：对于这种能力相对独立、且可能频繁演进的后端服务，MCP的解耦和动态发现优势明显。

4.2 场景二：为一个现有SaaS产品添加AI助手功能

需求：你有一个成熟的CRM系统，现在想在里面添加一个AI助手，帮助销售查看客户信息、更新跟进记录。

  • Tool方案：

    1. 为CRM的各个核心操作编写封装函数：get_contact(id),update_contact(id, data),create_follow_up(contact_id, note)等。
    2. 将这些函数作为Tools提供给模型。
    3. 在CRM前端，当用户与AI助手对话时，后台调用模型并传入这些Tools。优势：实现快速，与现有业务代码结合紧密，权限控制可以复用现有的CRM权限体系（因为Tool函数在CRM进程内执行）。挑战：CRM的业务逻辑复杂，可能需要暴露几十个Tools。管理庞大的Tool列表和臃肿的系统提示会成为负担。

  • MCP方案：

    1. 构建一个crm-mcp-server，作为CRM系统对AI世界的“网关”。
    2. Server内部封装所有对CRM数据库和API的调用，并对外暴露一组精心设计的、面向AI交互的Tools和Resources（例如，contact资源，search_contacts、log_activity工具）。
    3. AI助手前端作为一个独立的MCP Client，连接到这个Server。优势：
      • 关注点分离：AI交互逻辑与核心业务逻辑分离，Server可以专注于设计对AI友好的接口。
      • 安全边界清晰：Server可以集中实现所有AI请求的认证、授权、审计和限流。
      • 统一接入点：未来其他AI应用（如自动生成报告的分析Agent）也可以通过同一个Server接入CRM，无需重复开发。劣势：增加了架构复杂度，需要维护一个额外的Server进程。

结论：对于复杂、已有成熟系统的集成，MCP提供了更优雅、更可持续的架构。它相当于在核心系统和AI之间建立了一个适配层，这个层专门为AI交互优化，并承担了安全网关的职责。

4.3 场景三：快速原型验证与简单自动化脚本

需求：你想快速验证一个想法，比如一个能帮你整理下载文件夹的脚本。

  • Tool方案：

    1. 直接用Python写脚本，利用LangChain或LlamaIndex的Tool装饰器，快速将几个文件操作函数（list_files,move_file,categorize_file）暴露给模型。
    2. 写一个简单的循环，让模型根据你的指令调用这些Tools。优势：极其高效，几分钟就能跑通整个流程。所有代码在一个文件里，调试方便。

  • MCP方案：

    1. 需要先设计MCP Server的接口。
    2. 编写Server代码。
    3. 再编写Client代码来连接和驱动。劣势：杀鸡用牛刀，引入了不必要的进程通信和架构复杂度，拖慢验证速度。

结论：对于一次性任务、快速原型或极其简单的场景，Tool的轻量、直接是无可比拟的优势。先跑通，再优化。

4.4 混合架构：现实世界的最佳实践

在真实的复杂项目中，纯粹的Tool或MCP架构可能都不够。更常见的是混合架构。

  • 核心模式：高频、简单、稳定的核心能力用Tool，低频、复杂、易变的外部系统用MCP。
    • 例如，你的Agent应用本身可能需要一个format_responseTool来美化最终输出给用户的文本，这是一个简单、稳定、高频的内部函数，非常适合用Tool实现。
    • 同时，它需要连接公司内部的数据库、项目管理软件（Jira）、文档系统。这些都应该通过对应的MCP Server来接入。
  • 实现方式：现代的Agent框架（如LangGraph）已经支持同时加载Tools和连接MCP Servers。你可以在初始化时，既注册本地Tools，也配置远程MCP Servers的地址。框架会负责将两者的能力合并，并提供给模型。

选型决策树：

  1. 你的能力是否简单、稳定且数量少（<10）？->是：优先使用Tool。
  2. 你的能力是否来自复杂、独立的外部系统或服务？->是：优先考虑MCP。
  3. 你的项目是否处于早期原型阶段，需要快速验证？->是：使用Tool。
  4. 你是否需要为多个不同的AI应用（如Chatbot、分析Agent）提供统一的能力接入点？->是：强烈建议使用MCP。
  5. 你是否担心系统提示过长影响模型性能？->是：MCP的动态发现机制可以缓解此问题。

5. 常见问题与排查技巧实录

在实际开发和运维中，你会遇到各种各样的问题。下面是我总结的一些典型问题及其解决方法。

5.1 Tool Calling的典型故障

问题1：模型不调用工具，或者调用了错误的工具。

  • 排查步骤：
    1. 检查工具描述：这是最常见的原因。用另一个LLM（比如Claude）来评审你的工具描述，看是否清晰无歧义。确保工具名称和参数名是描述性的。
    2. 检查系统提示：确认工具定义被正确注入到了系统提示中，并且没有被其他提示词内容干扰或截断。
    3. 简化测试：用一个最简单的、必会调用的用户指令测试（例如，明确说“请调用XXX工具查询YYY”），看模型是否能正确响应。如果简单指令能行，复杂指令不行，说明问题在于模型对任务的理解和规划上，可能需要优化你的用户指令或引入思维链（Chain-of-Thought）提示。
    4. 查看原始响应：打印出模型API返回的原始消息，检查其中是否包含了格式正确的tool_calls字段。如果没有，说明模型认为不需要调用工具；如果有但格式错误，可能是SDK解析问题。

问题2：工具执行成功，但模型无法理解返回的结果。

  • 解决方案：
    • 结构化返回：尽量以清晰、简洁的JSON或纯文本格式返回结果。避免返回过于复杂嵌套的对象或过长的文本。
    • 添加摘要：对于复杂结果，可以在返回原始数据的同时，附加一个由你代码生成的“摘要”或“关键要点”。例如，查询数据库返回10条记录，你可以附加一句“共找到10条记录，其中最近3条是：...”。
    • 错误信息友好化：工具执行出错时，返回的错误信息应该能指导模型或用户下一步该怎么做，而不是堆栈跟踪。

5.2 MCP集成中的“坑”

问题1：MCP Server启动失败，或Client连接不上。

  • 排查步骤：
    1. 检查传输层：MCP支持stdio、HTTP、SSE等。确认Client和Server配置的传输方式一致。对于stdio，确保启动命令和参数正确。
    2. 查看日志：在Server和Client端启用详细的日志输出（MCP SDK通常有日志级别设置）。最初的握手（initialize）消息交换是排查重点。
    3. 验证协议兼容性：确认你使用的MCP SDK版本与协议版本兼容。检查initialize请求/响应中的protocolVersion字段。

问题2：模型通过MCP调用工具时表现不稳定，有时成功有时失败。

  • 可能原因与解决：
    • 工具描述不一致：Server在tools/list返回的描述，与tools/call时模型“看到”的描述，可能因为上下文窗口限制被截断或混淆。确保你的工具描述非常精炼且关键信息前置。
    • 资源状态变化：MCP的resources是动态的。如果模型基于一个旧的资源列表（如文件目录）进行推理，而实际资源已发生变化，可能导致调用失败。可以考虑让Server在资源变化时通知Client（部分MCP扩展支持），或者在工具描述中提醒模型“资源列表可能不是实时的”。
    • Server状态异常：MCP Server可能崩溃或处于异常状态。实现Client端的心跳检测和Server重启机制。

问题3：如何管理多个MCP Server的依赖和生命周期？

  • 实践建议：
    • 使用容器化：将每个MCP Server打包成Docker容器，使用Docker Compose或Kubernetes来统一管理它们的启动、停止和健康检查。
    • 实现服务发现：对于更复杂的部署，可以引入一个轻量级的“MCP代理”或“注册中心”。Client只需要连接代理，由代理负责管理和转发到后端的各个Server。
    • Client端连接池：对于高频调用的Server，在Client端实现简单的连接池和重连逻辑，避免频繁创建连接的开销。

5.3 性能与成本优化

挑战：工具/MCP调用导致对话响应变慢，API调用次数（成本）增加。

  • 优化策略：
    1. 批量处理：如果模型连续发出多个独立的工具调用请求（例如，查询三个不同城市的天气），可以在应用层将其合并，并行执行，然后将结果一次性返回给模型。这能显著减少来回交互的轮次。
    2. 缓存结果：对于幂等的、结果变化不频繁的工具调用（如查询静态数据、计算类任务），可以实现一个缓存层。用“工具名+参数”作为键，缓存一段时间内的结果。
    3. 预测性预加载（针对MCP资源）：如果模型经常在对话开始时读取某个资源（如项目文件结构），可以在初始化连接后，由Client主动预加载该资源，并缓存在本地，避免每次对话都重新读取。
    4. 精简上下文：定期清理对话历史中过时的工具调用和结果，只保留对当前推理最关键的部分，以节省上下文窗口。

最后，我的个人体会是，Tool和MCP不是二选一，而是Agent能力演进的两个阶段和两种维度。在智能体开发的“石器时代”，我们用手工打造的Tool来赋予模型最初的能力。而当我们需要构建一个能够生长、能够连接复杂数字世界的“智能体生态”时，MCP这样的标准化协议就成为了必不可少的“基础设施”。从Tool到MCP的演进，本质上是从“编写硬编码的指令”到“定义交互协议”的思维跃迁。对于大多数团队，我建议从Tool快速开始，但在设计之初就为未来接入MCP留好接口，当感受到Tool的维护之痛时，就是平滑过渡到MCP或混合架构的最佳时机。

编程学习 学习日记 实战经验
← 返回列表