智能体系统正无处不在地涌现，并被整合到我们的企业流程中。目前将智能体连接到这些工具的方法有很多。今天我们将盘点连接智能体与工具的五大模式，从第五名开始倒数。首先是第五名：直接连接。
这种模式的基本含义是用户与智能体交互，而该智能体直接与工具相连。这是我们在生成式AI早期、RAG模型甚至一些智能体系统中看到的模式，当时我们构建智能体并使用API密钥或服务ID等现有方式连接工具以提取信息。利用大语言模型处理提示词和响应并返回给用户，这是一种非常简单直接的模型。
让我们看看这种模式的优缺点。首先是优点：连接简单直接，无需额外复杂操作。我们构建智能体并连接工具，使用现有方式即可良好运作。然而缺点在于缺乏对用户可见性：智能体使用自身凭据访问工具，工具无法得知用户身份及其权限。早期通过仅允许访问公开或全公司可用信息来解决此问题。
接下来是第四名：直接连接但加入OAuth流程。我们在过程中引入身份提供商以进行用户认证，明确用户身份并将此绑定在工具端。GitHub、Jira和Slack等许多工具都具备OAuth认证能力。当智能体与工具交互时，工具会要求验证用户身份并发放访问令牌，随后智能体使用该令牌连接工具。
这种模式在其他领域也已常见。例如在使用Claude进行开发时，它会与工具交互获取访问令牌并本地存储，从而知道用户身份。其优点是利用了成熟的OAuth流程，建立了有效的认证机制，比第五种模式更进了一步。
但从缺点来看，这引入了“冒充”现象：对工具而言它看到的是用户，智能体在交互时实际上是在冒充用户。因此工具无法看到智能体的存在、意图或权限，完全将其视为最终用户。此外还引入了长期有效的凭据问题。
在OAuth流程中，某些工具如GitHub允许创建长达90天的访问令牌（取决于配置）。虽然智能体可以获取并存储这些凭据，但长期有效的凭证带来了安全风险，这是第四种模式的一个显著缺点。
现在进入第三种模式：移除直接连接部分，引入模型上下文协议（MCP）。我们在架构中加入MCP层。虽然基本流程不变——智能体与工具交互、进行OAuth认证并获取访问令牌——但MCP的加入带来了抽象层。
此前智能体必须了解特定工具的具体交互方式，每个智能体都需掌握所用工具的细节。引入MCP后，抽象层使得智能体无需了解工具本身的具体实现，只需理解如何与MCP交互即可。这消除了智能体需要掌握所有工具细节的负担，增加了系统的灵活性。
接下来是第二种模式：我们移除OAuth流程，引入“代表用户”（on behalf of）机制及令牌交换。首先引入令牌交换机制，整个系统现在将协同工作。我们需要智能体进行自身认证，从而明确智能体的身份，并使其代表用户操作，实现委托功能。
用户可以声明将任务委派给智能体去执行针对工具的工作。这样我们既知道用户是谁，也知道代理者（智能体）是谁。令牌交换还涉及令牌的流转：通过引入访问令牌并确保其流动安全，增加了安全性层以保障流程正确性。
让我们看看这种模式作为优点的部分：
引入令牌交换机制。首先，我们需要对智能体进行身份验证。此前我们已经对用户进行了认证。实际上，我们正在逐步淘汰一些其他的机制，特别是直接连接的方式。我们不再完全依赖 OAuth 作为应用程序的唯一手段，而是开始构建令牌流程。
现在，我们拥有了经过认证的用户和智能体，并且该智能体代表用户进行操作。这非常理想。我们将这一机制融入整体架构中，并增加了令牌传播功能。
回顾之前的缺点，现在我们消除了用户可见性的问题，实现了对用户的透明可视。同时，我们消除了冒充行为的风险。系统现在能够清晰看到用户和智能体的权限范围以及所有正在发生的事件，实现了完全的可见性和透明度。这使得我们能够真正按照期望的方式观察和运行系统。
接下来进入第一种模式，也就是我们的首选模式。基本操作是引入一个保险库（Vault）。
查看示意图可知，我们将在此处加入保险库，并与 MCP 进行交互。正如之前讨论的，在 OAuth 流程以及第二种模式中，我们需要获取用户的访问令牌并长期存储。这是我们极力避免的情况。
我们强烈希望令牌的有效期尽可能短。如果令牌被拦截或重放，由于其生命周期极短，攻击者将无法利用它进行后续操作。
因此，我们引入了一种新机制：不再让工具或整个流程直接持有长期令牌，而是将长期存储的令牌放入我们严格控制的安全保险库中。随后，该保险库为用户向 MCP 签发短期凭证。
这样一来，智能体流程仅使用短效凭证，这是该模式带来的一个显著优势：即短期有效的凭据。当然，引入这一机制也彻底消除了之前提到的安全隐患。
以上就是连接智能体与工具的五大最常见模式的总结，每种模式都比前一种提供了更高的安全性。非常感谢大家的观看。