有些人把大型语言模型(LLM)和人工智能代理混为一谈。 我们还是澄清一下吧,好吗? 虽然确实有人用聊天机器人扩展工具执行能力来称其为人工智能代理,但如果你想利用代理实现高级自动化,这种做法还很不成熟。 你肯定希望如此,因为你清楚这是应对混合云和多云复杂性带来运营疲劳的最有价值方案之一。
人工智能代理是一个软件单元(应用)有限的系统,它解读目标、维护上下文,并通过调用工具来执行操作。 它可能依赖大型语言模型(LLM)来推理需要完成的任务,但LLM仅是其中的一个组成部分。 代理即是整个系统。
从实际角度看,AI代理接收任务(明确指定或推断得出),在特定上下文中评估任务,并决定具体行动。 这些行动可能包括调用工具、查询系统或启动工作流。
您现在无需依赖大量代理也能获得价值。 一个范围清晰、紧密整合于工具链的单一代理即可发挥实际作用。 它能自动汇总、生成报告、分类工单,甚至将警报引导至正确队列。 只要遵守范围和政策,它就已经具备价值。
您可以使用AI代理而不必执行代理式AI。不过,一旦代理开始协作,即便您的架构尚未完全准备好,您其实已经在做代理式AI。
根据我们最新的研究,我猜你要么已经在处理代理行为(9% 的受访者),要么正朝着那方向发展(79% 的受访者)。 代理 AI 需要一个以受控执行为核心的框架,多个代理(对,就是“minions”,这样更容易区分代理AI)会利用共享工具、环境目标和像 MCP 这样的执行层进行协作。
代理是一个在明确定义的限制条件下自主或半自主运行的软件实体。 它负责理解任务、管理上下文、调用工具,并代表用户或更大系统做出决策。 在符合 MCP 的架构中,代理遵循一套结构化协议,规范任务、状态与策略之间的交互。
代理能推理、委派和执行操作——但只限于其授权的沙箱内。 他们不会随意调用系统接口。 他们不会自行启用工具权限。 所有操作都必须经过声明接口,才能确保安全、监控和权限撤销。
代理至少具备以下条件:
大型语言模型 思考。 智能体 行动。 平台 管理。
现在流行两种模型,其中一种会让你掉入陷阱。
图 1 当前构建人工智能代理主要有两种方法: 以大型语言模型为核心和以应用为界限。 以大型语言模型为核心的方法适合聊天机器人,但不适用于更复杂的自动化场景。
这是大多数框架当前的默认模式: 包括 LangChain、AutoGen、CrewAI 等。 该代理本质上是一个聊天提示,集成了工具和可选的记忆功能,围绕单个 LLM 会话构建而成。
限制:
简单来说:它像是一个有最高权限却无人监管的聪明实习生。 工作出色,直到突然失灵。
这是您在生产环境中应选择的模型。
在这里,代理是一个基于使用LLM 的框架构建的完整软件服务,但不依赖于它来处理执行。
这种方法为你提供版本控制、访问日志、工具层面的治理和运行时隔离。 这才是真正将代理从简单工具变成关键基础设施的方式。
当人们将代理设计成智能角色时,他们直觉地采用以人为本的访问模型:基于角色的访问控制 (RBAC)、登录令牌、用户属性和身份范围。 面对持续统一的人类身份时,这类模型非常合适。 但代理并非如此运作。 它们不是用户。 它们是执行者。 这使一切都不同了。
代理在执行过程中会转换角色。 一个代理可能先作为数据检索者,再变为规划者,随后触发自动化,通常都在同一会话和同一任务框架内完成。 它不会登录获取静态令牌后固守单一方式。
传统访问控制在这里失效。 RBAC 依赖静态角色。 基于属性的访问控制(ABAC)依赖固定属性。 会话令牌依赖一致的权限范围。 当代理动态变化时,这些假设都不成立。 代理系统中的身份是基于功能,而非个人。
这就是为什么管理代理需要从基于身份的策略转向基于执行的策略。 每次工具调用都必须实时验证代理的当前任务角色、上下文状态和允许范围。 策略存在于工具层,而非认证层。 承载执行策略所需元数据的,是上下文块,而非登录会话。 这也是我们称这种范式转变为“有效载荷中的策略”的原因,因为策略实际上就存在于有效载荷中。
把代理人当作代理人来对待。 像管理软件一样对他们进行治理。 绝不要忘了:大型语言模型负责思考,代理人负责行动,平台负责管理。 一旦混淆这三者,你就是在打造一个带有管理权限却忘记上次错误的人格。
LLM 思考。 代理执行行动。 平台负责管理。
坚持这一原则,您将打造出可扩展、安全且能经受现实挑战的代理基础设施。