模式五：直接连接与公开数据访问
在AI代理系统的早期阶段，直接连接（Direct Connection）是最基础且直观的模式。在这种架构中，用户与代理交互，而代理则直接通过API密钥或服务ID等现有方式连接到工具。这种模式常见于早期的生成式AI（Gen AI）和检索增强生成（RAG）系统中，代理利用大语言模型处理提示词与响应，并将结果返回给用户。
"It is a straight forward connection. It really doesn't take much more than what we already have." 这种连接方式的优势在于其简单直接性，无需引入复杂的额外组件即可实现功能。然而，该模式存在显著的局限性：缺乏用户可见性。代理使用自身凭据访问工具，导致工具无法识别具体是哪位用户在操作。为规避权限风险，早期系统通常仅允许访问公开信息或全公司通用的数据。这种妥协虽然解决了安全问题，但也限制了代理在个性化场景下的应用深度。
模式四：引入OAuth流程与身份认证
为了解决用户可见性问题，模式四引入了OAuth流。在此模式中，代理与工具交互时，工具会要求对特定用户进行身份验证。例如GitHub、Jira和Slack等主流开发工具均支持OAuth认证机制。
当代理发起请求时，工具会返回身份验证要求，随后向用户颁发访问令牌（Access Token）。代理获取该令牌后，即可代表特定用户与工具交互。这种模式在“氛围编码”（Vibe Coding）场景中尤为常见，如Claude等AI助手会获取并本地存储访问令牌。
"We've added a little bit over on top of what we did for pattern number five." 该模式的优势在于利用了成熟的OAuth标准，建立了有效的用户身份验证机制。但其缺点同样明显：引入了代理冒充（Impersonation）现象，即工具仅看到用户身份而无法感知背后代理的行为或权限；此外，还导致了长期凭据（Long-lived Credentials）的风险。例如在GitHub中，访问令牌可能长达90天有效，这增加了凭据泄露的安全隐患。
模式三：引入MCP抽象层与标准化协议
模式三的核心变革在于引入了模型上下文协议（Model Context Protocol, MCP），从而移除了代理与工具之间的直接连接。尽管底层仍保留OAuth认证和访问令牌机制，但MCP在代理与工具之间增加了一层抽象层（Abstraction Layer）。
在传统模式中，每个代理都必须掌握特定工具的交互细节；而在MCP架构下，代理只需了解如何与MCP协议交互，无需关心底层工具的具体实现。这种解耦极大地提升了系统的可扩展性。
"The agent only needs to know MCP. It doesn't need to know anything about the tools itself." 这一改变意味着代理不再需要为每个新工具编写特定的适配代码，只需通过标准的MCP接口即可调用各种后端服务。这不仅简化了代理的开发复杂度，也为不同工具之间的互操作性提供了统一标准。
模式二：令牌交换与代理身份认证
模式二进一步消除了OAuth中的用户直接交互流程，转而采用“代表用户操作”（On Behalf Of）的令牌交换机制。在此模式中，代理自身需要进行身份验证，系统能够同时识别用户和代理的身份。
该机制的核心在于委托（Delegation）：用户明确授权代理代表其执行特定任务。通过令牌交换，系统确保了令牌的流动过程是安全的。
"The token exchange adds a layer security onto this, to kind of make sure it's flowing correctly." 这种模式的优势在于实现了双重身份识别（用户与代理）以及增强的安全性。令牌交换机制防止了令牌的非法流转，确保只有经过授权的代理才能在特定权限范围内代表用户操作。相比模式四的长期凭据，这种机制通常涉及更短生命周期或受限范围的令牌交换，从而在便利性与安全性之间取得了更好的平衡。
身份认证与令牌传播的安全演进
在构建AI智能体连接工具的过程中，安全架构的核心在于如何处理身份验证与令牌交换。视频内容指出，系统首先需要完成对智能体本身的认证（authenticate the agent），而在此之前用户身份已经过验证。这一过程标志着从简单的直接连接向更复杂的令牌流（token flow）构建转变，逐步减少对传统OAuth作为单一应用依赖的倾向。当用户和智能体均完成认证后，关键的一步是让智能体代表用户进行操作（agent operating on behalf of the user）。这种机制引入了令牌传播的概念，使得整个交互流程更加紧密且具备上下文感知能力。
"We've actually started getting rid of some of these other mechanisms... Now we're going to start building out a token flow."
这种架构带来的显著优势在于消除了之前的可见性盲区。系统现在能够同时观察到用户和智能体的行为及其权限范围，从而彻底消除了冒充攻击的风险（eliminating impersonation）。通过实现全面的可观测性和透明度，系统能够按照预期的安全规范运行，为后续引入更高级的安全模式奠定了坚实基础。
密钥库（Vault）模式的架构设计
作为五种常见连接模式中的第一种，也是被推荐为“顶级模式”（top pattern）的方案，其核心创新在于引入了密钥库（Vault）。在之前的OAuth流程或第二种模式中，系统往往需要将用户的访问令牌长期存储以维持连接，这是一种高风险做法。新的架构改变了这一逻辑：工具不再直接持有或处理长期令牌，而是将长期访问令牌存储在受严格控制和锁定的密钥库中。这种设计确保了敏感凭证的物理或逻辑隔离，只有经过授权的组件才能访问。
在这种模式下，密钥库与模型上下文协议（MCP）进行交互。当智能体需要调用工具时，它不再使用长期凭证，而是由密钥库向MCP颁发短期凭据（issues a short-term credential to MCP）。这种机制确保了智能体流中仅使用短期有效的凭据，极大地降低了令牌被拦截后重放攻击（replay）的成功率和危害窗口。
短期凭据的安全优势与总结
引入密钥库模式带来的最直接且重要的收益是实现了短期有效凭据的使用（short-term lived creds）。由于令牌的生命周期极短，即使攻击者成功截获了传输中的凭据，其有效时间也微乎其微，从而彻底消除了长期令牌泄露带来的重放风险。这种设计从根源上解决了之前模式中因存储长期访问令牌而存在的安全隐患。
"We really want tokens to be very short lived. So if they're intercepted and replayed, then only last a short time..."
视频最后总结道，这五种连接智能体到工具的模式呈现出一种安全性逐级递增（providing a little bit more security than the one before）的趋势。从最初的简单连接演进到基于密钥库的短期凭据模式，每一步都在增强系统的可观测性、透明度和抗攻击能力。通过采用这种基于密钥库的架构，开发者能够构建出既具备功能灵活性又拥有企业级安全标准的AI智能体应用。