了解AI智能体：构建、行为与边界设定

Lori Mac Vittie杰出工程师兼首席技术布道师 | F5

有些人似乎混淆了LLM和AI智能体。我们不妨彻底厘清这一点。确实，有些人通过“扩展”聊天机器人，让其执行工具，并将其称为AI智能体。但如果想利用智能体实现高级自动化，这种方法还不成熟。当然，您确实希望这样做，因为您认识到，这是颇具价值的用例之一，有助于缓解混合多云环境的复杂性日益加剧所导致的运维疲劳。

AI智能体应当是一个以软件单元（应用程序）为边界的系统，能够解读目标、维护上下文，并通过调用工具执行操作。它可以使用大语言模型（LLM）来推理需要采取哪些行动，但LLM只是整个机制的一部分。智能体才是完整的系统。

具体而言，AI智能体接收一项任务（明确指定或推断得出），在上下文边界内对其进行评估，并决定如何采取行动。这些行动可能包括调用工具、查询系统或触发工作流。

如今，无需部署大量智能体，单个智能体也能创造价值。只要范围界定清晰，并与紧密集成的工具链相连，单个智能体现在就能完成实用的工作。它可以自动生成摘要和报告、对工单进行分类，甚至将告警引导至正确的队列。只要遵循既定范围和策略，它就已经能够发挥价值。

无需采用智能体式AI，也可以使用AI智能体。但一旦多个智能体开始协作，就意味着您正在使用智能体式AI，即使现有架构尚未做好准备。

根据我们最新的研究，我认为您要么已经在应对智能体行为（占受访者的9%），要么正朝这个方向发展（占受访者的79%）。智能体AI需要一个围绕受控执行构建的框架。在该框架中，多个智能体（没错，这里称为“minions”，因为这样更容易与智能体AI区分开来）会与共享工具、上下文目标以及MCP等执行层进行交互。

什么是智能体？

An 智能体是一种软件构造，可在明确界定的约束条件下自主或半自主运行。它能够解读任务、管理上下文、调用工具，并代表用户或更大的系统做出决策。在与MCP一致的架构中，智能体遵循结构化协议，由该协议规范任务、状态和策略之间的交互。

代理可以进行推理、委派任务并采取行动，但只能在为其提供的沙箱内执行。代理不会擅自发起系统调用，也不会自行创建工具访问权限。每项操作都应通过已声明的接口执行，以便对其进行保护、监控和撤销。

代理至少具备以下要素：

1. 上下文处理程序，用于跟踪状态、目标和记忆（短期或持久）
2. 推理引擎，通常是用于解读任务并规划执行过程的LLM或符号规划器
3. 工具接口：将意图映射为操作，并控制智能体可调用的操作
4. 安全边界：强制限定智能体可执行的操作及其适用范围
5. 传输层，用于传递消息和上下文，通常使用MCP、HTTP或事件总线

LLM负责思考，智能体负责行动，平台负责治理。

智能体构建模型

目前有两种主流模型，其中一种暗藏陷阱。

目前，构建AI智能体主要有两种方法：以LLM为中心和受应用约束。以LLM为中心的方法适用于聊天机器人，但不适合要求更高的自动化用例。

1. 以LLM为核心的智能体（单体式）

这是目前大多数框架（如LangChain、AutoGen、CrewAI等）的默认模式。智能体本质上是一个注入了工具并可选择使用记忆功能的聊天提示，封装在单个LLM会话中。

• 可快速构建原型
• 易于演示
• 扩展存在安全风险

局限性：

• 无持久化架构
• 不支持原生策略实施
• 模型容易虚构工具调用或忘记约束条件
• 除非进行扩展，否则无法观测令牌日志以外的信息

简而言之：它就像一个拥有root访问权限、却无人监督的聪明实习生。用起来很顺手，直到出问题为止。

2. 应用绑定型智能体（模块化）

这是适合在生产环境中使用的模型。

在这里，智能体是基于框架构建的完整软件服务。该框架会使用大语言模型，但并不依赖它来处理执行任务。

• 状态存储在外部系统中（Redis、向量数据库、策略引擎）
• 工具使用方式明确，并由控制层（MCP服务器、网关代理）管理
• 安全性和可观测性是首要考虑因素，而非事后补救
• 智能体是已部署的服务，而非提示词

这种方法可提供版本控制、访问日志、工具级治理和运行时隔离，帮助您将智能体从玩具转变为基础设施。

智能体不是角色设定

如果将智能体设计成具有智能的人格化角色，人们往往会本能地采用以人为中心的访问模型：基于角色的访问控制（RBAC）、登录令牌、用户属性和身份范围。当整个会话中的人类身份保持一致时，这些模型是合理的。但智能体并非如此运作。它们不是用户，而是执行者。这从根本上改变了访问控制的方式。

智能体在运行过程中会不断转换角色。单个智能体可能先检索数据，再制定计划，随后触发自动化操作，而这些角色转换通常发生在同一会话中，并服务于同一项任务。智能体并非登录后获取一个静态令牌，便始终执行单一职能。

传统访问控制正是在这里失效。基于角色的访问控制（RBAC）以静态角色为前提，基于属性的访问控制（ABAC）以固定属性为前提，会话令牌则以范围保持一致为前提。当智能体动态变化时，这些前提均不成立。在智能体系统中，身份取决于功能，而非个体。

因此，要治理智能体，就需要从基于身份的策略转向基于执行的策略。每次工具调用都必须根据智能体当前的任务角色、上下文状态和获准范围进行实时验证。策略位于工具层，而非身份验证层。承载执行这些策略所需元数据的是上下文块，而非登录会话。因此，我们将这种范式转变称为“策略随载荷传递”，因为策略实际上就在载荷中。

应将智能体视为智能体，并像治理软件一样治理智能体。切勿忘记：LLM负责思考，智能体负责行动，平台负责治理。如果混淆这些角色，构建出来的将是一个拥有管理员权限，却不记得上次所犯错误的“人格”。

LLM负责思考，智能体负责行动，平台负责治理。

坚持这一原则，就能构建可扩展、可保障安全，并能经受现实考验的智能体基础设施。

关于作者

Lori Mac Vittie杰出工程师兼首席技术布道师 | F5

Lori MacVittie是F5首席技术官办公室的杰出工程师兼首席技术布道师，在应用交付、自动化战略和基础设施领域拥有深厚的专业知识。无论是为AI智能体定义防护机制、剖析脆弱的多云架构，还是探索可扩展系统的极限，她都善于化繁为简。她在应用开发、IT架构以及网络和系统运维领域拥有30多年的行业经验。加入F5之前，她曾担任技术编辑，并因出色表现获得奖项。 MacVittie拥有计算机科学硕士学位，著述颇丰，出版作品涵盖安全、云和企业架构领域。她还热衷于桌面游戏和电子游戏，并且对奶酪有着毫不掩饰的鲜明见解。

Lori Mac Vittie 的更多博客文章