Agent 设计模式—智能体系统基础:Workflow 与 Agents 的架构抉择

从 Anthropic 与 Google 的定义出发,辨析工作流系统与智能体系统在决策方式、确定性与适应性上的差异,给出智能体系统的设计策略,并解释为何在上下文窗口与工具规模的限制下需要引入多智能体协作。

https://mp.weixin.qq.com/s/brTJfUdW4Ihifv806pO1Ug

一、介绍

1.1 什么是智能体

关于智能体的定义比较多,这里结合下anthropic与Google关于Agent的定义:

智能体(Agent)是可以感知和理解环境并使用工具来实现目标的应用程序。

从架构上,可以将智能体系统分为两类:

  1. 工作流系统(Workflows) - 人做整体规划的决策,LLM是链路的一个节点
  • LLM和各类工具通过预定义的代码路径进行编排
  • 提供可预测性和一致性
  • 适用于明确定义的任务

2. 智能体系统(Agents) - LLM做决策,决定任务要怎么做

  • LLM能够动态指导自己的过程和工具使用
  • 保持对任务完成方式的控制
  • 适用于需要灵活性和模型驱动决策的场景
    两者的主要区别:
特征工作流系统智能体系统
执行路径预定义、固定动态、灵活
决策方式基于规则基于LLM推理
确定性相对较低
可预测性相对较弱
适应性
复杂度相对简单相对复杂
维护成本较低较高
应用场景明确、重复性任务不确定、创造性任务

在设计到智能体系统的开发实现时,可以考虑遵循的策略:

  • 简单优先:从最简单的解决方案开始,根据需要增加复杂度,避免过度工程
  • 渐进式发展:先优化单一LLM调用,添加检索和上下文示例
  • *必要时使用智能体系统: *从Workflow到Agents,Workflow为明确定义的任务提供可预测性和一致性,而当大规模需要灵活性和模型驱动的决策时,可以考虑Agents。
    参考:https://www.anthropic.com/research/building-effective-agents

接下来我们讨论的智能体统一是Agents,由LLM驱动决策的智能体系统。

1.2 为什么需要多智能体

单智能体本身就是为了解决足够复杂的任务,为什么还需要多智能体?

  • 随着任务复杂度增加,单一智能体需要理解的语境和工具使用面临上下文窗口限制,导致性能下降。
  • 多智能体协作通过动态任务分解、专业化分工和协同工作克服这一挑战。
  • 在处理复杂任务时,系统会将任务分解为多个子任务。每个子任务由专门的智能体处理,这些智能体在特定领域具有专长。
  • 智能体之间通过持续的信息交换和任务协调来实现整体目标,这种协作方法可能产生智能涌现,即系统整体表现超越单个智能体能力之和。

在当前的现实中,在开发一个单智能体系统时会遇到的问题:

  • 智能体可用的工具过多,在决定下一步调用哪个工具时效果不佳

  • 上下文过多对于单个智能体来说过于复杂,难以跟踪

  • 系统中需要多个专业领域(如规划器、研究员、数学专家等)


  • 为了解决上述的问题,可以考虑将应用拆分为多个更小的独立智能体,并将它们组合成一个多智能体系统,期望达到的效果

  • 模块化:独立的智能体使开发、测试和维护变得更容易;

  • 专业化:可以创建专注于特定领域的专家智能体,这有助于提高整个系统的性能。

  • 控制:可以明确控制智能体之间的通信方式(而不是依赖于函数调用)。
    智能体通过共同协作解决用户的问题,协作的模式:

参考:https://www.salesforce.com/blog/the-agentic-ai-era-after-the-dawn-heres-what-to-expect/

本文结束 感谢您的阅读