作者：Mike Styer, Kanchana Patlolla, Madhuranjan Mohan, 和 Sal Diaz
发布日期：2025年11月
连接AI智能体与外部工具的桥梁
探索智能体工具的设计最佳实践和Model Context Protocol (MCP) 的应用
核心观点：没有外部函数访问能力，最先进的基础模型（Foundation Model）只是一个模式预测引擎
只能基于之前训练的数据生成内容
基础模型可以做得很好：
解决方案：现代基础模型现在可以调用外部函数或工具来解决这个问题。工具就像智能手机上的应用程序，使AI系统能够做更多事情，而不仅仅是生成模式
关键洞察：随着Agentic AI的出现，工具对AI系统变得更加重要
AI Agent (智能体)：使用基础模型的推理能力与用户交互并为他们实现特定目标，外部工具赋予智能体这种能力
工具充当智能体的"眼睛"和"手"
对外部世界采取行动
挑战：将外部工具连接到基础模型带来了重大挑战，包括基本技术问题以及重要的安全风险
背景：Anthropic于2024年引入Model Context Protocol (MCP) 作为一种简化工具和模型集成过程的方法，并解决一些技术和安全挑战
讨论基础模型使用的工具的性质
了解Model Context Protocol
深入探讨安全挑战
定义：在现代AI世界中，工具是LLM应用程序可以用来完成模型能力之外任务的函数或程序
获取信息：
执行操作：
示例：天气智能体工具调用示例 - 调用API获取用户位置的天气预报，并以用户偏好的单位呈现信息
在AI系统中，工具的定义就像非AI程序中的函数一样。工具定义声明了模型和工具之间的契约，至少包括清晰的名称、参数和自然语言描述
函数工具：
内置工具：
智能体工具：
示例：在Google ADK中定义的工具，从Python工具代码的docstring中提取定义
def set_light_values(
brightness: int,
color_temp: str,
context: ToolContext) -> dict[str, int | str]:
"""This tool sets the brightness and color temperature
of the room lights in the user's current location.
Args:
brightness: Light level from 0 to 100. Zero is off
and 100 is full brightness
color_temp: Color temperature of the light fixture,
which can be `daylight`, `cool` or `warm`.
context: A ToolContext object used to retrieve the
user's location.
Returns:
A dictionary containing the set brightness and
color temperature.
"""
user_room_id = context.state['room_id']
room = light_system.get_room(user_room_id)
response = room.set_lights(brightness, color_temp)
return {"tool_response": response}Google Gemini API内置工具：Grounding with Google Search, Code Execution, URL Context, Computer Use
from google import genai
from google.genai.types import (
Tool,
GenerateContentConfig,
HttpOptions,
UrlContext
)
client = genai.Client(http_options=HttpOptions(api_version="v1"))
model_id = "gemini-2.5-flash"
url_context_tool = Tool(url_context=UrlContext)
url1 = "https://www.foodnetwork.com/recipes/..."
url2 = "https://www.allrecipes.com/recipe/..."
response = client.models.generate_content(
model=model_id,
contents=("Compare the ingredients and cooking times "
f"from the recipes at {url1} and {url2}"),
config=GenerateContentConfig(
tools=[url_context_tool],
response_modalities=["TEXT"],
)
)注意：工具定义本身对开发者是不可见的；它单独提供给模型
优势：智能体也可以作为工具被调用，防止完全的用户对话交接，允许主智能体保持对交互的控制
from google.adk.agents import LlmAgent
from google.adk.tools import AgentTool
tool_agent = LlmAgent(
model="gemini-2.5-flash",
name="capital_agent",
description="Returns the capital city for any country or state",
instruction="""If the user gives you the name of a country
or a state (e.g. Tennessee or New South Wales), answer
with the name of the capital city of that country or
state. Otherwise, tell the user you are not able to
help them."""
)
user_agent = LlmAgent(
model="gemini-2.5-flash",
name="user_advice_agent",
description="Answers user questions and gives advice",
instruction="Use the tools you have available to answer
the user's questions",
tools=[AgentTool(agent=capital_agent)]
)A2A协议：Google的A2A协议甚至允许您将远程智能体作为工具使用
根据主要功能或它们促进的各种交互类型来分类智能体工具
信息检索：
操作/执行：
系统/API集成：
人机协作：
| Tool Use Case | 工具用例 | Key Design Tips | 关键设计技巧 |
|---|---|---|---|
| Structured Data Retrieval | 结构化数据检索 | Define clear schemas, optimize for efficient querying, handle data types gracefully | 定义清晰的模式，优化高效查询，优雅处理数据类型 |
| Unstructured Data Retrieval | 非结构化数据检索 | Implement robust search algorithms, consider context window limitations | 实现强大的搜索算法，考虑上下文窗口限制 |
| Connecting to Built-in Templates | 连接内置模板 | Ensure template parameters are well-defined, provide clear guidance | 确保模板参数定义良好，提供清晰指导 |
| Google Connectors | Google连接器 | Leverage Google APIs, ensure proper authentication and authorization | 利用Google API，确保适当的身份验证和授权 |
| Third-Party Connectors | 第三方连接器 | Document external API specifications, manage API keys securely | 记录外部API规范，安全管理API密钥 |
关键点：工具文档（名称、描述和属性）都作为请求上下文的一部分传递给模型，所以所有这些对于帮助模型正确使用工具都很重要
create_critical_bug_in_jira_with_priority 比 update_jira 更清晰提供输入和输出参数、工具目的以及有效调用工具所需的任何其他细节的清晰详细描述
def get_product_information(product_id: str) -> dict:
"""
Retrieves comprehensive information about
a product based on the unique product ID.
Args:
product_id: The unique identifier for the product.
Returns:
A dictionary containing product details.
Expected keys include:
'product_name': The name of the product.
'brand': The brand name of the product
'description': A paragraph of text describing
the product.
'category': The category of the product.
'status': The current status of the product
(e.g., 'active', 'inactive', 'suspended').
Example return value:
{
'product_name': 'Astro Zoom Kid's Trainers',
'brand': 'Cymbal Athletic Shoes',
'description': '...',
'category': 'Children's Shoes',
'status': 'active'
}
"""def fetchpd(pid):
"""
Retrieves product data
Args:
pid: id
Returns:
dict of data
"""对比：好的文档提供了清晰的类型、详细的描述和示例返回值；坏的文档使用了模糊的名称、缺少类型信息和详细描述
价值：示例可以帮助解决歧义，展示如何处理棘手请求，或阐明术语区别
澄清模糊的术语或边缘情况
展示如何处理棘手请求
无需使用微调等更昂贵的方法来细化模型行为
动态示例：还可以动态检索与即时任务相关的示例，以最大限度地减少上下文膨胀
提供默认值：为关键参数提供默认值，并确保在工具文档中记录和描述默认值。如果文档良好，LLM通常可以正确使用默认值
原则：假设每个工具都有良好的文档，模型的指令应该描述操作，而不是特定工具
错误做法：工具应该封装智能体需要执行的任务，而不是外部API
常见错误：很容易编写只是现有API表面的薄包装器的工具，但这是一个错误
关键区别：API旨在由具有可用数据完整知识的开发人员使用；复杂的企业API可能有数十甚至数百个可能影响API输出的参数。如果工具代表智能体应该完成的特定任务，智能体更有可能能够正确调用它
最佳实践：保持函数简洁并限于单个功能是标准编码最佳实践；定义工具时也应遵循此指导
不要创建多工具：通常，不要创建依次采取许多步骤或封装长工作流的工具
例外情况：如果常用的工作流需要按顺序进行许多工具调用，定义单个工具来封装许多操作可能更高效。在这种情况下，确保非常清楚地记录工具正在做什么，以便LLM可以有效地使用该工具
问题：设计不当的工具有时可能返回大量数据，这会对性能和成本产生不利影响
解决方案：使用外部系统
最佳实践：大多数工具调用框架都包括工具输入和输出的可选模式验证。尽可能使用此验证功能
关键点：定义的模式应该清晰描述和仔细措辞，两个模式中定义的每个属性都应该有描述性名称和清晰的描述。两个模式字段都应该被视为必需的
机会：工具错误消息是改进和记录工具功能的一个被忽视的机会
常见问题：即使文档良好的工具也可能只返回错误代码，或者最多返回简短、非描述性的错误消息
示例：检索产品数据的工具可以返回一个响应，说"未找到产品ID XXX的产品数据。请客户确认产品名称，并按名称查找产品ID以确认您有正确的ID。"
背景：工具提供了AI智能体或LLM与外部世界之间的基本链接。然而，外部可访问工具、数据源和其他集成的生态系统变得越来越分散和复杂
图：N x M集成问题 - 每个模型和工具组合都需要自定义连接器
挑战：将LLM与外部工具集成通常需要为每个工具和应用程序配对构建定制的、一次性的连接器。这导致开发工作量的爆炸性增长，通常称为"N x M"集成问题
N x M问题的影响：随着每个新模型(N)或工具(M)添加到生态系统中，必要的自定义连接数量呈指数级增长
Model Context Protocol (MCP)：Anthropic于2024年11月引入的开放标准，旨在解决这种情况
架构模型：MCP实现客户端-服务器模型，受到软件开发世界中Language Server Protocol (LSP)的启发
主机：负责创建和管理单个MCP客户端的应用程序
客户端：嵌入在主机中的软件组件
服务器：提供服务器开发人员希望向AI应用程序提供的一组功能的程序
管理用户体验、工具编排、安全策略
维护连接、发布命令、接收响应
工具、资源、提示
工具、资源、提示
工具、资源、提示
图2：Agentic应用程序中的MCP主机、客户端和服务器
目标：这种架构模型旨在支持竞争性和创新的AI工具生态系统的发展。AI智能体开发人员应该能够专注于他们的核心竞争力——推理和用户体验
标准化：MCP客户端和服务器之间的所有通信都建立在标准化的技术基础之上，以确保一致性和互操作性
JSON-RPC 2.0：MCP使用JSON-RPC 2.0作为其基本消息格式。这为所有通信提供了轻量级、基于文本和语言无关的结构
请求：从一方发送到另一方并期望响应的RPC调用
结果：包含相应请求成功结果的消息
错误：表示请求失败的消息，包括代码和描述
通知：不需要响应且无法回复的单向消息
MCP还需要客户端和服务器之间通信的标准协议，称为"传输协议"，以确保每个组件都能解释另一方的消息
标准输入/输出：
可流式HTTP：
注意：直到协议版本2024-11-05，MCP使用HTTP+SSE进行远程通信，但该协议已被弃用，转而支持Streamable HTTP
能力定义：在基本通信框架之上，MCP定义了几个关键概念或实体类型，以增强基于LLM的应用程序与外部系统交互的能力
工具：服务器向客户端提供的功能
资源：服务器提供的可访问数据
提示：服务器提供的可重用提示示例或模板
采样：服务器可以请求LLM完成
诱导：服务器可以请求额外的用户信息
根：定义服务器可以在文件系统中操作的范围
当前状态：在MCP规范定义的这些能力中，只有工具得到了广泛支持
| Capability | 能力 | % Supported | 支持率 |
|---|---|---|---|
| Tools | 工具 | 99% | 几乎全部支持 |
| Resources | 资源 | 34% | 约三分之一支持 |
| Prompts | 提示 | 32% | 约三分之一支持 |
| Sampling | 采样 | 10% | 支持率较低 |
| Elicitation | 诱导 | 4% | 支持率很低 |
| Roots | 根 | 5% | 支持率很低 |
数据来源：https://modelcontextprotocol.io/clients，检索于2025年9月15日
定义：MCP中的工具实体是服务器向客户端描述其提供的函数的标准化方式
最佳实践：虽然title和description等属性在模式中是可选的，但它们应该始终包含。它们为给客户端LLM提供关于如何有效使用工具的重要指令提供了重要渠道
{
"name": "get_stock_price",
"title": "Stock Price Retrieval Tool",
"description": "Get stock price for a specific ticker symbol.
If 'date' is provided, it will retrieve the last price or
closing price for that date. Otherwise it will retrieve
the latest price.",
"inputSchema": {
"type": "object",
"properties": {
"symbol": {
"type": "string",
"description": "Stock ticker symbol"
},
"date": {
"type": "string",
"description": "Date to retrieve (in YYYY-MM-DD format)"
}
},
"required": ["symbol"]
},
"outputSchema": {
"type": "object",
"properties": {
"price": {
"type": "number",
"description": "Stock price"
},
"date": {
"type": "string",
"description": "Stock price date"
}
},
"required": ["price", "date"]
},
"annotations": {
"readOnlyHint": "true"
}
}定义：annotations字段声明为可选，应该保持这种状态。规范中定义的属性都是提示，并不保证准确描述工具的操作
可能执行破坏性更新（默认：true）
使用相同参数重复调用不会有额外效果（默认：false）
可能与"开放世界"的外部实体交互（默认：true）
不修改其环境（默认：false）
安全警告：MCP客户端不应依赖来自不受信任服务器的这些属性。即使服务器受信任，规范也不要求工具属性保证为真。使用这些注释时应谨慎
灵活性：MCP工具可以通过多种方式返回结果。结果可以是结构化或非结构化的，并且可以包含多种不同的内容类型
文本：表示非结构化字符串数据
音频：包含base64编码的音频数据，标记有适当的MIME类型
图像：包含base64编码的图像数据，标记有适当的MIME类型
资源链接：MCP还允许工具返回指定的资源，这为开发人员提供了更多选项来管理其应用程序工作流。资源可以作为存储在另一个URI的资源实体的链接返回，或者完全嵌入在工具结果中
安全警告：客户端开发人员应该非常谨慎地检索或使用以这种方式从MCP服务器返回的资源，并且应该只使用来自受信任来源的资源
格式：结构化内容始终作为JSON对象返回
最佳实践：工具实现者应始终使用outputSchema功能提供客户端可用于验证工具结果的JSON模式，客户端开发人员应根据提供的模式验证工具结果
双重目的：与标准函数调用一样，定义的输出模式具有双重目的：它允许客户端有效地解释和解析输出，并向调用的LLM传达如何以及为何使用此特定工具
两种机制：MCP定义了两种标准错误报告机制
JSON-RPC错误：服务器可以为协议问题返回标准JSON-RPC错误
结果错误：服务器还可以通过在结果对象中设置"isError": true参数来返回错误消息
机会：错误消息是给调用的LLM提供进一步指导的重要且经常被忽视的渠道。MCP工具开发人员应该考虑如何最好地使用此渠道来帮助其客户端从错误中恢复
{
"jsonrpc": "2.0",
"id": 3,
"error": {
"code": -32602,
"message": "Unknown tool:
invalid_tool_name. It may be
misspelled, or the tool may not
exist on this server. Check the
tool name and if necessary request
an updated list of tools."
}
}{
"jsonrpc": "2.0",
"id": 4,
"result": {
"content": [
{
"type": "text",
"text": "Failed to fetch weather
data: API rate limit exceeded.
Wait 15 seconds before calling
this tool again."
}
],
"isError": true
}
}关键点：工具的错误消息还应该给LLM一些关于如何处理特定错误的指令。例如，检索产品数据的工具可以返回一个响应，说"未找到产品ID XXX的产品数据。请客户确认产品名称，并按名称查找产品ID以确认您有正确的ID。"
定义：资源是服务器端能力，旨在提供可以由主机应用程序访问和使用的上下文数据
安全风险：将任意外部内容引入LLM的上下文会带来重大的安全风险，因此任何由LLM客户端消费的资源都应该从受信任的URL进行验证和检索
支持率：资源只有约34%的MCP客户端支持
定义：MCP中的提示是另一种服务器端能力，允许服务器提供与其工具和资源相关的可重用提示示例或模板
安全担忧：虽然它们确实有潜力为AI系统增加价值，但在分布式企业环境中，使用提示引入了一些明显的安全担忧。允许第三方服务将任意指令注入应用程序的执行路径是有风险的，即使通过分类器、自动评分器或其他基于LLM的检测方法进行过滤
建议：在开发更强的安全模型之前，提示应该很少使用，如果有的话
定义：采样是客户端能力，允许MCP服务器从客户端请求LLM完成
定义：诱导是另一种客户端能力，类似于采样，允许MCP服务器从客户端请求额外的用户信息
规范要求：MCP规范指出"服务器不得使用诱导来请求敏感信息"，并且用户应该清楚地了解信息的使用情况，并能够批准、拒绝或取消请求
实施建议：这些准则对于以尊重和保护用户隐私和安全的方式实施诱导至关重要。禁止请求敏感信息的指令不可能以系统方式执行，因此客户端开发人员需要警惕这种能力的潜在滥用
定义：根，第三个客户端能力，"定义服务器可以在文件系统中操作的范围的边界"
实际应用：目前尚不清楚根将如何在生产MCP系统中使用。一方面，规范中关于服务器相对于根的行为没有防护措施，无论根是本地文件还是其他URI类型
规范声明：规范中关于此的最明确声明是"服务器应该在操作期间尊重根边界"
建议：任何客户端开发人员都不应过于依赖服务器关于根的行为
概述：MCP为AI开发人员的工具箱增加了几个重要的新功能。它也有一些重要的局限性和缺点，特别是当其使用从本地部署、开发者增强场景扩展到远程部署、企业集成应用程序时
最直接的好处：MCP在简化集成过程中提供最直接的好处。MCP为工具与基于LLM的应用程序集成提供了通用协议
MCP注册表：几个公共MCP服务器注册表和市场已经出现，允许开发人员发现、共享和贡献预构建的连接器。为了避免MCP生态系统的潜在碎片化，MCP项目最近启动了MCP注册表，它为公共MCP服务器提供了单一真实来源，还提供了OpenAPI规范来标准化MCP服务器声明
网络效应：如果MCP注册表流行起来，这可能会创造网络效应，从而加速AI工具生态系统的增长
MCP在几个重要方面增强了智能体功能调用
动态工具发现：
标准化工具描述：
扩展LLM能力：
解耦：通过标准化智能体-工具接口，MCP将智能体的架构与其能力的实现解耦
面向未来：这种模块化架构还允许组织切换底层LLM提供商或替换后端服务，而无需重新架构整个集成层，前提是新组件通过符合的MCP服务器公开
当前限制：虽然MCP的原生安全功能目前有限（如下一节详述），但其架构至少为实现更强大的治理提供了必要的挂钩
用户同意：此外，协议规范本身通过明确推荐用户同意和控制，为负责任AI建立了哲学基础。规范要求主机在调用任何工具或共享私人数据之前获得明确的用户批准。这种设计原则促进了"人机循环"工作流的实施，其中智能体可以提出行动但必须在执行前等待人类授权，为自主系统提供了关键的安全层
核心挑战：除了安全性，MCP的当前设计对性能和可扩展性提出了基本挑战，主要与它如何管理上下文和状态有关
上下文窗口膨胀：
推理质量下降：
有状态协议挑战：
新兴挑战：上下文窗口膨胀问题代表了一个新兴的架构挑战——当前预加载所有工具定义到提示的范式很简单，但不可扩展
潜在解决方案：这种现实可能迫使智能体发现和使用工具的方式发生转变。一种潜在的未来架构可能涉及工具发现本身的RAG式方法
转变：这将把工具发现从静态、暴力加载过程转变为动态、智能和可扩展的搜索问题，在agentic AI堆栈中创建一个新的必要层
新攻击向量：然而，动态工具检索确实打开了另一个潜在的攻击向量；如果攻击者获得对检索索引的访问权，他或她可以将恶意工具模式注入索引并欺骗LLM调用未经授权的工具
当前状态：虽然MCP正在被快速采用，但几个关键的企业级功能仍在发展或尚未包含在核心协议中，组织必须自己解决这些差距
身份验证和授权：
身份管理模糊性：
缺乏原生可观察性：
解决方案：为了解决这个问题，企业软件提供商正在MCP之上构建功能，如Apigee API管理平台，它为MCP流量添加了一层可观察性和治理
双重考虑：MCP带来的新功能，通过连接智能体与工具和资源，也带来了一组新的安全挑战，超出了传统应用漏洞
主要风险：最突出的是未经授权的行动和数据泄露
应对策略：因此，保护MCP需要主动、演进和多层面的方法，解决新旧攻击向量
风险描述：MCP服务器可能会动态更改其提供的工具、资源或提示集，而无需明确的客户端通知或批准。这可能潜在地允许智能体意外继承危险能力或未经批准/未经授权的工具
场景：诗歌创作智能体连接到Books MCP服务器（内容检索和搜索服务）以获取引语，这是一个低风险的内容生成活动。然而，假设Books MCP服务突然添加了书籍购买能力，这是一个善意的尝试，以为其用户提供更多价值。那么这个以前低风险的智能体可能会突然获得购买书籍和发起金融交易的能力，这是一个高风险活动
与其他风险结合：与其他风险或漏洞结合，这可能会被恶意服务器利用，导致客户端中的未经授权行为
显式允许列表：
更改通知：
工具固定：
安全API网关：
受控环境：
风险描述：工具描述可以指定任意触发器（工具应该被规划器选择的条件）。这可能导致安全问题，其中恶意工具遮蔽合法工具，导致潜在的用户数据被攻击者拦截或修改
官方公司服务器：
secure_storage_service攻击者控制的服务器：
save_secure_note结果：面对这些竞争描述，智能体的模型很容易选择使用恶意工具来保存关键数据而不是合法工具，导致未经授权地泄露用户的敏感数据
防止命名冲突：
双向TLS：
确定性策略执行：
人机循环：
限制未经授权的服务器：
风险描述：工具描述符字段，包括其文档和API签名，可以操纵智能体规划器执行流氓操作。工具可能摄入包含可注入提示的外部内容，导致智能体操纵，即使工具本身的定义是良性的
工具描述符操作：
外部内容注入：
数据泄露：工具返回值也可能导致数据泄露问题。例如，工具查询可能返回关于用户的个人数据或关于公司的机密信息，智能体可能会未经过滤地将其传递给用户
输入验证：
输出清理：
分离系统提示：
双规划器策略：更进一步，可以用两个独立的规划器构建智能体，一个受信任的规划器拥有对第一方或经过身份验证的MCP工具的访问权限，一个不受信任的规划器拥有对第三方MCP工具的访问权限，它们之间只有一个受限的通信通道
风险描述：在用户交互过程中，MCP工具可能会无意中（或在恶意工具的情况下，有意）接收敏感信息，导致数据泄露
对话上下文：
诱导能力：
关键问题：MCP规范中的禁令不可能以系统方式执行，因此客户端开发人员需要警惕这种能力的潜在滥用
结构化输出和注释：
污点源/汇：
污点输出：
框架要求：框架必须能够分析输出并验证其格式
问题：MCP协议仅支持粗粒度的客户端-服务器授权。在MCP身份验证协议中，客户端在一次授权流程中向服务器注册
影响：这种限制使得在企业环境中实施细粒度访问控制变得困难
受众和范围凭据：
最小权限原则：
将秘密保留在上下文之外：
核心观点：基础模型在孤立时仅限于基于其训练数据的模式预测。它们无法感知新信息或对外部世界采取行动；工具赋予它们这些能力
MCP的价值：这些设计最佳实践构成了任何可靠和有效的智能体系统的必要基础。Model Context Protocol (MCP)作为管理此工具交互的开放标准被引入，旨在解决"N x M"集成问题并培育可重用生态系统
动态工具发现：虽然其动态发现工具的能力为更自主的AI提供了架构基础，但这种潜力伴随着企业采用的巨大风险
企业采用：因此，MCP在企业中的未来可能不是其"纯"开放协议形式，而是与集中治理和控制层集成的版本
机会：这为可以执行MCP中不存在的安全和身份策略的平台创造了机会。采用者必须实施多层防御，利用API网关进行策略执行，强制执行带有显式允许列表的硬化SDK，并遵守安全工具设计实践
MCP的角色：MCP提供了工具互操作性的标准，但企业承担构建其运行所需的安全、可审计和可靠框架的责任
感谢您的阅读！
Agent Tools & Interoperability with MCP
智能体工具与MCP互操作性