原文：Agent Tools & Interoperability with MCP
全文为整体大纲，细节部分看视频
一、问题背景：从"会思考的模型"到"能行动的系统"
当前，任何从事 AI 应用开发的人都会面临一个核心问题：如何让高度智能的语言模型在真实世界中产生可执行、可验证的价值？
尽管基础模型（Foundation Models）在语言理解与生成方面表现卓越，但其能力本质上仍受限于训练数据本身。模型无法主动感知实时信息，也无法直接对外部系统施加影响。
从工程角度看，语言模型更像是一个高度精确的模式匹配与推理引擎，却缺乏与现实世界交互的"感官"和"执行器"。它可以生成代码、撰写文本，却无法自行调用 API、查询实时股价，或触发一封邮件的发送。
正是这种感知与行动能力的缺失，构成了 Agentic AI 试图解决的关键问题，也使其在企业级应用场景中具备潜在的颠覆性价值。
二、工具（Tools）：Agent 的感官与执行机制
2.1 工具的定义
在 Agent 体系中，工具（Tool）本质上是一个函数或程序，用于弥补语言模型的能力边界，使其能够完成模型本身无法原生完成的任务。这些任务可以归纳为两类：
- 获取新信息（Know Something） 例如：调用 API 获取实时天气、查询当前股票价格等。
- 执行外部动作（Do Something） 例如：发送消息、更新数据库、创建工单、预订资源等。
2.2 工具的三种主要类型
根据白皮书中的分类，工具主要分为以下三类。
（1）函数工具（Function Tools）
函数工具由开发者显式定义，通常是外部函数（如 Python 方法）。在诸如 Google ADK 等框架中，函数工具通常依赖详细的文档字符串（docstring）来定义其接口契约，包括输入参数、输出结构与语义说明。
模型通过读取这些文档信息，理解如何正确调用该函数。例如：
- 函数：
set_light_values - 文档描述：指定亮度与颜色参数，用于控制智能家居灯光
文档即契约，是模型理解工具能力的唯一依据。
（2）内置工具（Built-in Tools）
内置工具由模型服务提供方隐式提供，开发者通常无法直接看到其实现细节。常见示例包括：
- 基于搜索的 Grounding 能力
- 代码执行
- 通过 URL 获取内容
这些能力通常作为平台特性存在，开发者只需使用而无需定义。
（3）代理工具（Agent Tools）
代理工具是一种更高阶的抽象：将另一个独立 Agent 作为工具进行调用。
其关键特征包括：
- 主 Agent 仍然保持控制权
- 子 Agent 仅作为能力模块被调用
- 返回结果被主 Agent 用作后续推理的输入
这是一种分层、委派式的协作模型，类似于管理者向专家团队请求分析报告，而非将整个任务完全移交。
三、工具的功能性分类（Taxonomy）
从更宏观的角度，工具还可按用途划分为：
- 信息检索类：获取数据、查询状态
- 动作执行类：对外部系统产生变更
- 系统 / API 集成类：与第三方软件系统交互
- 人类介入类（Human-in-the-loop）：在关键节点请求人工确认或澄清
四、Agent 工具设计的关键最佳实践
工具是否"可用"，很大程度上取决于设计质量。以下实践并非建议，而是工程上的必要条件。
4.1 文档优先（Documentation is Paramount）
模型理解工具的唯一方式是开发者提供的文档信息，包括工具名称、描述文本与参数定义。这些内容会被直接注入模型上下文。
清晰、具体的命名至关重要。例如：
- 正例：
create_critical_bug_with_priority - 反例：
update_jira
4.2 描述"做什么"，而非"怎么做"
工具描述应聚焦于任务目标，而非具体调用方式。例如：
- 正确：创建一个缺陷记录以描述该问题
- 错误：调用
create_bug函数
模型应负责推理决策，工具仅负责执行。
4.3 发布任务，而非暴露底层 API
应避免对复杂企业 API 进行薄封装。理想的工具应：
- 封装单一、高层语义任务
- 隐藏底层系统复杂性
例如：
- 正例：
book_meeting_room - 反例：直接暴露包含十余参数的日历 API
4.4 输出应尽量简洁
将大量原始数据直接塞回模型上下文会导致上下文窗口膨胀、成本与延迟上升，并显著降低推理质量。推荐做法包括：
- 返回摘要信息
- 返回确认状态
- 返回外部资源引用（如 URI）
4.5 错误必须"可指导"
错误信息不应仅是状态码。优秀的错误响应应明确指出问题原因，并提供可执行的恢复建议。例如："API 触发限流，请等待 15 秒后重试"。
五、MCP（Model Context Protocol）：工具标准化协议
5.1 协议背景
MCP 于 2024 年提出，旨在解决模型与工具集成中的 n × m 复杂性问题，其设计目标是实现 Agent 与工具之间的解耦与标准化连接。该协议在架构思想上借鉴了 Language Server Protocol（LSP）。
六、MCP 的核心架构组件
MCP 采用典型的 Client--Server 架构，包含三个核心角色。
6.1 MCP Host
- 负责整体用户体验
- 管理 Agent 推理流程
- 决定何时调用工具
- 强制执行安全策略与治理规则
6.2 MCP Client
- 嵌入在 Host 内部
- 管理会话生命周期
- 向 Server 发送工具执行请求
6.3 MCP Server
- 提供具体工具能力
- 声明可用工具
- 执行命令并返回结果
这种分离使 Agent 开发与工具实现可以由不同团队甚至第三方独立完成。
七、通信机制与传输方式
- 通信协议：JSON-RPC 2.0
- 本地传输：标准输入 / 输出（高效、低延迟）
- 远程传输：可流式 HTTP（支持 SSE，适合长时间任务）
八、MCP 中的工具定义与执行
8.1 标准化 Schema
工具定义必须包含名称、描述、输入 Schema（必需）以及输出 Schema（可选）。Schema 明确规定调用方式与结果结构，从而消除歧义。
8.2 工具执行结果
- 结构化结果：符合 Schema 的 JSON（推荐）
- 非结构化结果：文本、文件、URI 引用等
8.3 错误处理机制
- 协议级错误：JSON-RPC 调用失败
- 执行级错误：工具逻辑失败，通过
is_error标识返回
九、MCP 带来的战略价值
- 加速开发
- 促进工具复用生态
- 支持运行时工具发现
- 解耦 Agent 推理与执行
- 支持 Agent Mesh 等模块化架构
十、扩展性挑战：工具规模与上下文限制
当 Agent 可访问的工具数量达到数百甚至数千级别时，上下文成本将不可接受，推理质量也会急剧下降。
解决方向：Tool Retrieval（工具检索）
可采用类似 RAG 的机制：
- 先进行语义检索
- 选出少量最相关工具
- 仅加载这些工具的定义进入上下文
十一、安全挑战：Confused Deputy 问题
MCP 协议本身缺乏强认证与授权机制，存在被 Prompt Injection 利用的风险。所谓 Confused Deputy，是指低权限用户通过诱导 Agent，触发高权限 MCP Server 执行敏感操作。
企业级应对策略
- 不直接暴露 MCP Server
- 使用 API Gateway 进行统一治理
- 实施认证、授权、限流、审计与输入过滤
安全应构建在 MCP 之上，而非依赖 MCP 本身。
十二、总结与思考
语言模型是"思考引擎"，工具是"行动接口"，MCP 正在成为二者之间的通用语言。真正的价值来自于严谨的工具设计、清晰的职责分离，以及外围强治理与安全体系。
开放性问题在于：在 Agent 越来越自主的系统中，如何确保其行为始终反映的是用户被授权的真实意图，而非仅仅执行了被请求的指令？审计、授权与责任边界，仍是 Agentic AI 必须直面的核心议题。