为自定义 Joule 代理运用工具与模型上下文协议（MCP）

学习目标

  • 在 Joule Studio 中设计代理工具，并通过 MCP 进行集成

简介

想象你正在开发一个 Joule 代理来简化客户支持工作。该代理需要访问知识库、理解客户情绪，并在 CRM 系统中触发操作。为此，代理需要工具——即扩展其核心语言理解能力、使其能够与系统和数据交互的能力。本课将探讨什么是工具、它们在 Joule Studio 经典版中如何定义，以及模型上下文协议（MCP）如何通过促进互操作性与安全性来简化工具的集成。

什么是 AI 工具？

工具是一种可调用的能力，使 Joule 代理能够执行特定操作或访问外部资源。工具让代理得以超越文本生成，与真实世界的系统、数据和流程进行交互。

Joule 代理使用的常见工具示例包括：

以下是代理工具的一些常见示例：

工具

用途

企业用例示例

Joule 技能

使用受治理、可复用的函数安全连接到核心 SAP 或非 SAP 数据源。

供应链代理使用 Joule 技能检查仓库中特定产品的实时库存水平。

文档接地

从非结构化业务文档（PDF、Word 文档、合同）中提取信息并进行推理，以确保回答具备上下文感知能力且符合合规要求。

客户服务代理以保修政策文档为接地，准确判断客户的索赔是否有效。

计算器

执行财务与物流任务所需的精确数值推理、计算和评估。

创建销售订单的代理使用计算器，根据数量和客户历史应用复杂的多层折扣。

人工介入（Human in the Loop）

通过暂停工作流并请求用户对关键或高价值决策进行人工审批或输入来实施治理。

财务代理为一张异常大额的发票起草付款建议，并触发面向部门经理的人工介入审批任务。

Joule 代理

允许主代理调用另一个更专业的代理来执行特定任务，从而构建可组合、可扩展的生态。

主“销售订单代理”需要执行信用检查。它并不内置该逻辑，而是将专业的“信用检查代理”作为工具调用。该专家代理运行分析并返回“通过/不通过”结果，主代理随后使用该结果继续流程。

模型上下文协议（MCP）

使代理能够以标准化方式在 SAP 与非 SAP 应用之间发现并编排工作流，打破应用孤岛。

物流代理使用 MCP 直接从第三方物流服务商支持 MCP 的系统中查询发货状态。

工具补充了大语言模型的能力。LLM 可以推理并生成文本，而工具提供确定性执行——例如精确的计算或系统交互。

在 Joule Studio 经典版中定义良好工具的三项原则

在 Joule Studio 经典版中定义工具，就是把一项可信、可用于生产的能力打包供代理使用。为确保可靠性和可预期的行为，工具应遵循三项核心原则。

原则 1：它必须是经过验证的能力。

工具是一种承诺，即某项能力能按预期工作。在将其暴露给代理之前，底层功能必须经过独立测试并处于可运行状态：

  • 对于 Joule 技能：这意味着底层 API 调用或自动化已得到充分测试。你已验证它能正确连接到目标系统，并返回预期结果或执行所需操作且不出现错误。

  • 对于文档接地：这意味着文档流水线已经成功运行。源文档已被处理、建立索引，并生成了可供代理查询的知识“分块”。

你不是在定义一个想法，而是在打包一项经过验证的资产。

原则 2：用平实的业务语言定义其用途。

一旦你拥有可用的能力，就必须教会代理如何以及何时使用它。你可以在 Joule Studio 经典版中填写一份简单的“描述”表单来完成这件事。这是代理决策中唯一重要的要素。该描述的质量直接决定代理行为的准确性与可靠性。

原则 3：像为新团队成员编写工具使用指南那样编写代理指令

你在 Joule Studio 经典版中给代理的核心指令不仅仅是一个高层目标，而是它的操作手册。这本手册必须教会代理如何策略性地使用你赋予它的特定工具。

这样来理解：当新员工入职时，你不会只说“帮助客户”。你会向他们展示将要使用的软件，并解释每个应用该如何、何时使用。你的代理指令也必须做到这一点。

你的指令应当是一份指南，教会代理对工具进行推理：

1. 工具选择策略（哪项工作用哪个工具？）

指令必须明确引导代理为特定任务选择合适的工具，尤其是在多个工具看似相似时。

  • 模糊的指令：“使用工具查找订单信息。”

  • 新团队成员式指令：“当用户询问订单时，你的策略如下：如果他们询问配送状态，使用 GetOrderStatus 工具。如果他们想查看订单中的商品，使用 GetOrderDetails 工具。这是两个独立的功能。”

2. 工具调用顺序（我应该按什么顺序使用它们？）

对于多步骤问题，指令必须说明正确的工作流，教会代理如何将一个工具的输出用作下一个工具的输入。

  • 模糊的指令：“查找客户的订单。”

  • 新团队成员式指令：“要查找某位客户的所有订单，你必须遵循两步流程。首先，使用 FindCustomerByName 工具获取其唯一的 customerID。其次，将该 customerID 用作 ListRecentOrders 工具的输入。”

3. 数据源优先级（我最信任哪个工具？）

如果代理可访问多个信息源（例如一个实时工具和一个静态文档），指令必须告诉它优先使用哪一个。

  • 模糊的指令：“检查库存。”

  • 新团队成员式指令：“你的主要库存来源是 CheckStockLevel 工具，因为它提供实时数据。始终优先使用该工具。只有当该工具失败或不可用时，才查阅 DailyInventoryReport.pdf 文档；若查阅了该文档，你必须告知用户该信息来自昨天。”

4. 处理工具局限（当工具不够用时该怎么办？）

指令必须界定工具的边界，并提供清晰的升级路径。

  • 模糊的指令：“如果你帮不上忙，就升级处理。”

  • 新团队成员式指令：“CalculateStandardDiscount 工具只能用于非 VIP 客户。如果 CheckCustomerStatus 工具返回 ‘VIP’，你绝不能使用折扣工具。相反，你应说明可能适用特殊折扣，并需要将请求转交给人工销售经理审批。”

LLM 本身只能处理文本。当你向代理提供一个工具时，本质上是在教 LLM 该工具的存在，并指示它生成使用该工具的文本指令。

例如，如果你提供一个“天气”工具，而代理需要知道巴黎的天气，LLM 可能会生成文本调用 weather_tool('Paris')。代理随后解释该指令、执行工具并获取天气数据。LLM 再使用这些数据为用户生成听起来自然的回答。

模型上下文协议（MCP）：统一的工具接口

模型上下文协议（MCP）是一种开放协议，用于标准化应用程序向 LLM 提供工具的方式。它通过提供一种通用语言和结构，解决了将多样化工具与各种 LLM 集成的难题。可以把它看作 AI 工具的通用适配器。

MCP 旨在通过提供若干关键优势来简化工具集成：

  • 标准化接口： MCP 定义了一致的方式来描述和访问工具，无论其底层实现如何。这降低了集成新工具的复杂度，让开发者能够专注于工具的功能，而不是 LLM 接口的具体细节。

  • 不断壮大的生态： MCP 培育了一个开发者社区，他们贡献并维护着一个预构建集成库。这使 LLM 能够直接接入广泛的工具，加速开发并减少重复工作。

  • LLM 供应商灵活性： 通过抽象工具接口，MCP 使组织能够在不同 LLM 供应商之间切换，而无需重写工具集成。这提供了更大的灵活性并降低了供应商锁定。

  • 增强的安全性： MCP 提倡在你的基础设施内保护数据的最佳实践。通过定义清晰的边界和访问控制，它有助于在 LLM 访问工具时保护敏感信息。

通过实现 MCP，各框架可以利用协议中定义的工具，无需为每个框架重新实现相同的工具接口。这会带来更精简、更高效的开发流程。

小结

  • 工具是扩展 Joule 代理能力的函数，使它们能够与真实世界交互并访问外部信息。

  • 定义工具需要清晰的描述、可调用的函数、带类型声明的参数，以及可选的输出类型声明。

  • 模型上下文协议（MCP）为工具与 LLM 的集成提供了标准化接口，简化了开发并促进了互操作性。