上一页展示了如何将 LLM 封装在代理中，从而为你提供持久的身份、说明和会话管理。 但是，即使所有这些内容，代理也只能生成内容（文本、图像等），它无法查找今天的股价、发送电子邮件或查询数据库。 它回答在训练过程中整合的任何知识，以及你在提示中提供的任何上下文。
工具 弥合了这一差距。 它们使代理能够 采取行动 ，超越其训练数据，并与现实世界交互。 添加工具是使代理真正有用的单一影响最大的步骤。
何时使用此项
在以下情况下向代理添加工具：
- 代理需要访问 实时数据或外部数据 （实时价格、天气、数据库记录、搜索结果），这些数据不在模型的训练数据中。
- 代理需要 采取措施 （发送电子邮件、创建票证、调用 API、写入文件），而不仅仅是生成内容。
注意事项
| 注意事项 | 详细信息 |
|---|---|
| 延迟 | 每个工具调用都会添加一个往返过程 —— 模型生成工具请求，代码执行该请求，并将结果回传到模型，然后模型才能继续进行。 多功能工具会增加复杂性。 |
| 令牌资源消耗 | 工具定义（名称、说明、参数架构）包含在每次提示中。 更多工具意味着可用于聊天历史记录和模型响应的令牌更少。 |
| 调试复杂性 | 出现问题时，原因可能是模型的工具选择、选择的参数或工具的执行。 你在同时调试推理和代码。 |
| 可靠性 | 模型可能会错误地调用工具、传递错误参数，或者在不应调用工具时调用工具。 良好的说明和 工具审批 可以缓解此问题，但不要将其消除。 |
为什么代理需要工具
如 LLM 基础知识中所述，LLM 经过训练以生成令牌，包括表示工具调用的特殊结构化格式。 但模型本身永远不会执行任何操作。 它是分析模型输出、运行实际函数并返回结果的应用程序（或代理框架）。
这意味着工具不会更改模型 是什么 ， 它们会更改代理可以 执行的操作。 没有工具，代理只是会话者。 借助工具，它将成为操作员。
请考虑旅行预订代理。 如果没有工具，它可以根据一般知识讨论航班和建议行程。 借助工具，它可以：
- 在航班 API 中搜索实时可用性和定价
- 代表用户预订航班
其中每个操作都需要一个工具， 代理可以调用的一段代码来与外部世界交互。
工具调用循环的工作原理
提供代理工具时，代理框架会自动管理 工具调用循环：
┌──────────────────────────────────────────────────────┐
│ User: "What's the weather in Seattle?" │
└──────────────┬───────────────────────────────────────┘
▼
┌──────────────────────────────────────────────────────┐
│ Agent sends messages + tool definitions to LLM │
└──────────────┬───────────────────────────────────────┘
▼
┌───────────────┐
│ LLM responds │
└───┬───────┬───┘
│ │
Tool call? No ──────────────────────────┐
│ │
▼ ▼
┌─────────────────────────────┐ ┌─────────────────────────────┐
│ Agent Framework executes │ │ Final response: │
│ the tool (e.g., │ │ "It's cloudy in Seattle │
│ get_weather("Seattle")) │ │ with a high of 15°C." │
└──────────────┬──────────────┘ └─────────────────────────────┘
│
▼
┌─────────────────────────────┐
│ Agent sends tool result │
│ back to the LLM │
└──────────────┬──────────────┘
│
└──────► (back to "LLM responds")
要点：
- 无需编写循环。 代理框架处理在模型的响应中检测工具调用、执行工具以及将结果馈送回。 定义工具;框架协调其余部分。
- 每回合可调用多个工具 在生成最终答案之前，模型可能会调用多个工具（可能并行），或链接工具调用，其中一个工具的输出会通知下一个答案。
- 模型决定何时调用工具。 根据用户的请求和提供的工具说明，模型会判断是否需要工具。 良好的工具说明会导致更好的工具选择。
小窍门
有关添加第一个工具并在操作中查看此循环的实践演练，请参阅“入门”教程中的 步骤 2：添加工具 。
工具类型
代理框架支持多种类别的工具。 选择合适的代理取决于您需要代理执行的任务以及功能所在的位置。
函数工具
函数工具 是向代理写入和注册的自定义函数。 它们在你的进程中运行，使你能够完全控制逻辑、安全边界和错误处理。
在以下情况下使用函数工具：
- 代理需要调用自定义的业务逻辑（例如查询数据库、调用内部 API 或执行计算）
- 您需要该工具能够在您的环境中运行，并能够访问您的资源。
- 需要编译时类型安全性和可测试性
函数工具是最常见的灵活工具类型。 大多数代理都从此处开始。
MCP 工具（模型上下文协议）
MCP 是一个开放标准，用于定义应用程序如何向 LLM 提供工具。 无需自行编写工具逻辑，而是连接到 一台 MCP 服务器 ，该服务器通过标准协议公开了一组工具，这类似于 REST API 公开终结点的方式。
代理框架支持两种类型：
| 味道 | 介绍 | 何时使用 |
|---|---|---|
| 托管 MCP 工具 | 由 Microsoft Foundry 或其他提供程序托管和管理的 MCP 服务器 | 你需要对常见功能（例如文件搜索、代码执行）的交钥匙访问，而无需管理基础结构 |
| 本地 MCP 工具 | 运行您自己的 MCP 服务器或通过任何提供商连接到它们 | 你有自定义或第三方 MCP 服务器，或者你需要在自己的环境中运行的工具 |
在以下情况下使用 MCP 工具：
- 预生成的 MCP 服务器已提供所需的功能
- 你想要通过共享服务器跨多个代理或应用程序重复使用工具
- 正在与提供 MCP 端点的第三方服务集成
提供程序托管的工具
某些提供程序提供在提供程序基础结构上运行的内置工具，无需本地代码。 这些包括：
| 工具 | 它的作用是什么 |
|---|---|
| 代码解释器 | 在提供商的基础设施沙盒环境中执行代码 |
| 文件搜索 | 上传至服务提供商的文件进行搜索 |
| Web 搜索 | 在 Web 中搜索实时信息 |
在以下情况下使用提供程序托管的工具：
- 你需要代码执行或 Web 搜索等功能，而无需自行生成或托管该工具
- 供应商已经提供一个更符合您要求的托管版本
注释
提供程序托管的工具可用性因提供程序而异。 有关完整的提供程序支持矩阵，请参阅 工具概述 。
注释
某些 LLM 提供商可能会在推理期间在其基础设施上执行托管工具，例如 OpenAI 的 Responses API。 将这些推理服务视为将推理与工具执行相结合的半代理服务。 它不会改变基础模型的工作方式，但确实意味着工具执行可以在服务的响应生成过程中发生。 这些服务无法执行本地工具，这些工具必须在自己的基础结构上运行。
选择正确的工具类型
| 问题 | 建议 |
|---|---|
| 我是否有自定义业务逻辑？ | 函数工具 - 编写和注册自己的函数 |
| 是否已经存在一台满足我需求的 MCP 服务器？ | MCP 工具 - 连接到它，而不是从头开始生成，例如GitHub MCP 服务器 |
| 是否需要代码执行、文件搜索或 Web 搜索？ | 提供者托管的工具 — 请检查您的提供者是否支持这些工具 |
| 是否需要来自多个类别的工具？ | 混合， 代理用户可以同时使用函数工具、MCP 工具和提供商托管工具 |
工具说明很重要
模型根据其 名称和说明选择工具。 模糊的描述会导致工具选择不佳 — 模型可能会调用错误的工具、跳过它应使用的工具，或传递不正确的参数。
编写工具说明的方式与编写 API 文档的方式相同：说明该工具的作用、每个参数的含义以及返回的内容。 说明越清晰，模型判断就越好。
小窍门
工具定义（名称、说明、参数架构）包含在指令中，并占用上下文窗口中的令牌。 如果注册了许多工具，开销可能很大。 仅登记代理实际需要的工具。
工具审批：人为参与
某些操作很敏感— 转移资金、删除记录、发送电子邮件。 你可能不希望代理自主执行这些工具。 工具审批让您在执行工具之前需要进行人工确认。
当工具标记为需要审批时，代理会在执行前暂停，并返回指示需要审批的响应。 应用程序负责向用户演示此情况并将其决策传回。
此模式通常称为 人机循环 ，对于生成处理后果操作的可信代理至关重要。
常见错误
| 陷阱 | Guidance |
|---|---|
| 工具过多 | 每个工具定义都使用令牌。 仅注册与代理用途相关的工具。 |
| 模糊说明 | “对数据进行一些操作”无助于模型。 具体来说：“按 SKU 查询库存数据库以获取产品可用性。 |
| 无错误处理 | 工具可能会失败（网络错误，输入无效）。 返回明确的错误消息，以便模型可以推理出问题的原因，然后重试或通知用户。 |
| 过于宽松的工具 | 可以“运行任何 SQL 查询”的工具是一种安全风险。 将工具的范围限定为特定的定义操作。 |
| 缺少对敏感操作的审批 | 如果某个工具可以进行不可逆转的更改，请添加 工具审批 以保持人类处于循环中。 |
特别提及：代码解释器工具
如 LLM 基础知识中所述，LLM 可以在精确计算和正式逻辑中出错。 这是因为 LLM 根据模式匹配逐个令牌生成答案，它们实际上不会 计算。 当要求 LLM 计算两个大数的乘积时，它并不进行算术运算；而是根据训练数据预测答案的“样子”。 在大多数情况下效果出人意料地好，但在边缘情况下则不可预测地失败。
代码解释器 通过让代理在沙盒环境中编写和执行代码来解决此问题。 模型不猜测答案，而是编写一个Python脚本，该脚本准确计算它，运行它，并在其响应中使用已验证的结果。
注释
每次要求模型解决相同的问题时，该模型可能会编写略有不同的脚本，但结果 应大多 一致。
警告
代码解释器不能替代人类的谨慎推理。 请始终检查代理的工作，并在必要时独立验证结果。
给代理提供代码解释器，当需要时：
- 执行精确的计算 （财务建模、统计分析、单位转换），其中近似的“最佳猜测”是不能接受的。
- 转换或分析数据 - 分析 CSV、聚合行、生成图表或重塑结构化数据。
- 处理文件 - 读取上传的文档、提取内容、转换格式或生成新文件。
- 验证自己的推理 — 编写测试代码以在向用户演示逻辑声明之前验证逻辑声明。
小窍门
代码解释器可以是由提供商托管的工具，代码在提供程序的基础架构中的沙盒上运行，而不是在你的环境中运行。 这样就可以安全地使用，而无需担心在服务器上执行任意代码。 有关设置详细信息，请参阅 代码解释器参考 。
后续步骤
代理拥有工具后，下一步是了解 技能 — 可移植的指令包、参考资料和脚本，为代理提供可按需加载的域专业知识。
更深入：
- 工具概述 - 所有工具类型和提供程序支持矩阵
- 函数工具 - 详细的函数工具参考
- 托管的 MCP 工具 — Microsoft Foundry MCP 服务器或其他提供程序
- 本地 MCP 工具 - 自定义 MCP 服务器
- 工具审批 - 人工干预工具审批过程
- 步骤 2：添加工具 - 动手教程