Agentic AI (代理型AI)

智能体式 AI 系统由以下组件构成：

• 智能体编排组件负责管理并协调一组智能体的行动。智能体编排组件可以利用 LLM 将复杂任务拆解并动态生成工作流；也可以仅依赖通过业务流程建模表示法 (BPMN)、业务流程执行语言 (BPEL) 等技术预先定义的静态工作流。
  
  
• 一个或多个智能体——能够自主决策并执行操作，以实现既定目标的软件组件。智能体通常利用 LLM 动态生成任务执行计划。智能体还可以借助工具与外部系统交互，例如调用企业应用 API、查询知识库（如维基百科），或执行计算任务（如数学运算），这些任务单靠 LLM 往往难以准确或高效完成。
  
  
• 最后，这些工具会与企业内部及外部的数据源和系统进行交互，以检索信息并更新记录系统。

智能体拥有其自身的概念架构，如下图所示。

智能体由以下核心组件组成：

• 输入组件是触发智能体采取行动的一个或多个输入来源。通常，这些输入来自用户的自然语言查询或任务；但也可能是系统事件，例如文件创建、Kafka 队列中的消息或结构化 API 调用。
  
  
• 执行组件负责协调智能体的活动，以完成所需任务。通常，执行组件首先会：(i) 整理智能体可用的工具与资源列表；(ii) 调用规划与反思组件生成任务执行计划。随后，执行组件按照生成的计划执行任务，并根据需要调用工具和资源收集信息或改变智能体的外部环境；必要时还会再次调用规划与反思组件，以根据工具反馈或失败情况调整计划。
  
  
• 规划与反思组件通常由 LLM 实现，使智能体能够根据输入制定分步骤的行动计划以完成任务，并对行动结果进行反思，从而相应地调整其计划。
  
  
• 工具集成组件使智能体能够通过“工具”调用 API 并访问资源，以执行操作并收集信息，从而推动整体任务完成。
  
  
• 记忆组件负责管理短期任务上下文以及长期知识，使智能体既能在多次任务调用中保持上下文（例如“撤销上一份采购订单”），又能基于历史行为分析并优化未来决策。
  

还可以添加图中未展示的组件，用于实现智能体运行管理、性能监控以及安全控制（例如身份传播和数据泄露防护）。

下图展示了该概念架构中的控制流与信息流。

1. 用户向生成式 AI 应用（例如聊天机器人或企业应用中的查询界面）提交请求。
   
   
2. 生成式 AI 应用会将用户请求传递给智能体编排器，形式可以是原始查询（如聊天输入），也可以是触发预定义工作流（例如发起采购申请）。以下示例流程假设用户输入的是原始查询。
   
   
3. 路由器利用经过调优的 LLM，将用户查询拆解为一系列必要的操作或步骤，以得出最终答案。例如，要回答这样一个查询：“加拿大曼尼托巴省温尼伯市当前的气温是多少？与一年中这一时期的历史平均气温相比如何？”LLM 可能会给出如下概念性的操作步骤列表：
   
   
   • 使用 Weather 智能体查询温尼伯当前气温
   • 使用 Calendar 智能体查询当前日期
   • 使用 Search 智能体查询温尼伯在该日期的历史平均气温
   • 使用 Calculator 智能体计算当前气温与历史平均气温之间的差值
   • 使用 Language 智能体生成自然语言回复
     
     
4. 然后，Orchestrator 为列表中的每个操作调用适当的智能体。继续以第 3 步中的示例为例：
   
   
   • Orchestrator 调用 Weather 智能体获取温尼伯的当前气温，为 -1°C。
   • Orchestrator 调用 Calendar 智能体获取当前日期：2023 年 11 月 9 日。
   • Orchestrator 使用 Search 智能体查询温尼伯 11 月 9 日的历史正常气温，为 1.4°C。
   • Orchestrator 调用 Calculator 智能体计算两者温差：-1 - 1.4 = -2.4°C
   • Orchestrator 使用 Language 智能体，基于收集的数据生成对初始查询的回答
      
5. 当代理被调用时，它同样可以借助 LLM 来规划自己的操作步骤，如同 Orchestrator 一样。延续该示例，Weather 智能体收到请求 “温尼伯当前气温是多少？”，将生成如下执行计划：
   
   
   • 查询温尼伯所属国家或地区
   • 查找温尼伯所在国家或地区的权威国家气象服务
   • 使用 Weather API 向天气服务查询温尼伯当前气温。
   • 智能体随后通过 LLM 或外部服务确定温尼伯所在国家（加拿大），查找加拿大的国家气象服务（加拿大环境部），并使用 Weather API 获取温尼伯的当前温度。
      
6. 生成的响应随后返回至生成式 AI 应用程序；在本例中为：“温尼伯当前气温为 -1°C，比历史平均值 1.4°C 低 2.4°C。”
   
   
7. 最终回答将传递给用户。

上图展示了 IBM 产品在智能体式 AI 架构中的映射关系。

watsonx Orchestrate 是一款“一体化”智能体式 AI 解决方案，集成了以下功能：

• 发布与管理工具（在 Watsonx Orchestrate 中称为技能）；
• 使用声明式工作流将技能组合成复杂的多步骤流程；和
• 为横向业务领域（如人力资源、采购等）提供预构建的特定领域智能体。

watsonx.ai Agent Builder 是一款低代码/无代码工具，使开发者能够构建智能体，并通过预构建流程定义和管理工具。

编排战略

智能体编排可以通过多种方式实现。集中式编排方法使用单一主编排组件来管理系统中所有其他智能体的操作。单点配置与管理使整个系统易于管理、控制和排查故障。缺点在于单一控制点可能成为瓶颈，当请求量或智能体数量增加时，会面临可扩展性挑战。

去中心化编排方法通过任务队列实现：智能体从队列中获取任务并提交结果，同时在智能体之间分配多步骤任务；类似于黑板系统。去中心化编排方案具有高度稳健性和容错性，但随着系统规模和功能增加，其设计与排错难度也随之提升。

最后，分层编排方法融合了集中式与去中心化方法的特点。在分层编排中，主编排器负责协调高级智能体的操作，这些高级智能体可以调用其他智能体完成复杂任务。这种方法保留了集中式编排易于管理和控制的优势，同时降低了在高请求量或大量智能体情况下中央控制组件成为瓶颈的风险。

智能体粒度

AI 智能体的粒度指其可执行任务的复杂程度。高粒度智能体可能足以详细处理许多任务或少量复杂任务，而低粒度智能体则可能只完成少量甚至单一任务，并且细节有限。为更清晰说明，可举客户服务智能体为例。低粒度智能体可能只能回答有关产品的简单问题（例如，“它是黑色的吗？”），而高粒度智能体可能足以检查本地库存并安排将产品交付给客户家中。

智能体解决方案设计者需决定系统中智能体的粒度，例如采用少量高粒度智能体，或大量低粒度智能体。高粒度智能体功能强大，但需要更多计算资源且任务完成时间更长。低粒度智能体功能有限，但关注范围窄，因此所需计算资源少，通常可更快完成任务。

尽管“最佳”粒度尚未确定，但早期经验显示，将低粒度智能体与特定业务流程（如 Purchase_Order_Processing_Agent）对齐，可在资源需求、处理速度和方案复杂性之间取得良好平衡。低粒度智能体可被纳入静态工作流，或由高粒度智能体在更大流程中调用。

静态工作流与动态工作流

智能体式 AI 解决方案的设计者需在智能体遵循预定义静态流程与根据用户提示动态生成工作流之间取得平衡。虽无绝对正确或错误，但建议架构师参考以下建议与注意事项。

• 静态工作流相对容易进行监控、审计和操作，其本身也可作为合规性的证据。在此类情况下使用静态工作流可为架构师带来若干优势：

  • 静态工作流相对容易监控、审计和操作，其本身也可作为合规性证明。动态生成的工作流在执行时更难监控，每个流程的执行需从各个智能体日志中重建。动态工作流可能改变任务顺序，这进一步增加了审计与合规监控的难度。
    
    
  • 在各专业领域之间明确“交接点”，可清晰划分责任，并确保信息传递完整准确。虽然动态生成工作流也能实现同样目标，但在设计与实现上需要更多关注和投入。
    
    
• 动态工作流适用于“单步”操作或紧密连贯的功能，这些操作不跨知识领域，且执行不受监管或控制。