Agent Analyze

WorkFlow和Agent

在大型语言模型（LLMs）的应用中，我们主要看到两种不同的系统架构：工作流（Workflows） 和 智能体（Agents）。

• 工作流（Workflows）：可以理解为预先设定好的程序，它通过固定的步骤和流程来协调大型语言模型（LLMs）和各种工具。就像一条预先铺设好的轨道，程序会按照固定的顺序调用不同的模型和工具来完成任务。
• 智能体（Agents）：则更加灵活，它由大型语言模型（LLMs）驱动，能够自主地决定下一步做什么、调用哪个工具，从而动态地完成任务。智能体就像一个自主的决策者，它会根据当前的情况和目标来决定如何行动。

核心区别在于灵活性：

• 工作流（Workflows） 是一种静态的、预设好的链路。它通常在传统的程序流程中嵌入部分大型模型，利用大模型的智能来优化关键环节。
• 智能体（Agents） 则是一种动态的、自主的链路。它的动态性来源于大型语言模型（LLMs）的强大推理能力，能够根据任务需求自行规划、决策。

简而言之，工作流 是在既有的流程中引入AI，让AI在关键环节发挥作用。而 智能体 则是利用大模型强大的推理能力，让AI自主地完成复杂的任务。智能体 这项新兴技术，正是受益于大模型兴起后所具备的复杂自然语言推理能力，才真正具备了可行性。

哪个更优秀？

在工作流（Workflows）和智能体（Agents）之间，不能简单地说哪个更优秀，它们各有优势，适用于不同的场景。关键在于选择最适合当前任务的方案。
工作流（Workflows）： 稳定高效，适用于明确任务

• 优势： 工作流的特点是稳定和高效。由于它遵循预定义的流程，执行起来非常可靠，不易出错，且速度较快。
• 劣势：复杂场景会导致链路配置膨胀，难以持续迭代维护。
• 适用场景： 当任务目标明确、步骤固定，且输入变量相对简单时，工作流是理想的选择。例如，一个简单的语言翻译功能：用户选择源语言和目标语言，工作流就可以按照预设的步骤调用翻译模型，高效稳定地完成翻译任务。在这种场景下，工作流的稳定性是至关重要的。

智能体（Agents）： 灵活智能，适用于复杂开放任务

• 优势： 智能体具有高度的灵活性和智能性。它能够根据任务的复杂程度，自主规划、决策，并动态地调整步骤。这意味着它能适应不确定性和复杂性更高的任务。
• 劣势： 智能体的灵活性也带来一些缺点，比如相比于工作流，它可能不够稳定，执行过程中更容易受到环境或自身状态的影响，并且可能更耗时，因为它的每一步决策都需要推理。
• 适用场景： 当任务目标不明确、步骤不固定，且包含较多不确定性和需要推理时，智能体更具优势。比如“入驻进度咨询”这样的任务，它可能需要根据用户在不同阶段（事前、事中、事后）提出的问题，进行多轮对话和推理，智能体能够更好地理解用户意图，并提供个性化的回答。

LLM接口核心参数

虽然市面上的大型语言模型（LLMs）种类繁多，但在接口层面上，它们通常都遵循或类似于 OpenAI 的规范。这里我们以 OpenAI 的接口为例进行说明。

在与大型模型交互时，除了控制模型输出随机性的参数外，最核心的参数只有两个：messages 和 tools。可以说，市面上各种各样的大模型应用，都是基于这两个参数的基础上设计而来。

messages：对话上下文

用于记录用户与大型语言模型之间的对话历史。这个数组中的每一个元素都是一个消息对象，包含消息的角色 (role) 和内容 (content)。

messages 参数的主要作用是让大型模型理解对话的上下文。通过提供之前的对话记录，模型可以更好地理解当前用户的意图，并给出更准确的回复。

role代表当前对话的角色，从最初的system，user，assistant逐步演变，后续增加了tool代表工具执行结果。

1
2
3
4
5
6
7
8
9
10
11

[

{ "role": "system", "content": "你是一个乐于助人的助手" },

{ "role": "user", "content": "今天天气怎么样？" },

{ "role": "assistant", "content": "今天天气晴朗。" },

{ "role": "user", "content": "明天呢？" }

]

tools：外部资源

tools 是一个数组，用于指定大型语言模型可以调用的外部工具。每个工具对象都包含工具的名称、描述和参数等信息。tools 参数的主要作用是让大型模型能够利用外部资源来扩展自身能力，例如下面获取天气的tool：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

[
  {
    "type": "function",
    "function": {
      "name": "get_current_weather",
      "description": "Get the current weather in a given location",
      "parameters": {
        "type": "object",
        "properties": {
          "location": {
            "type": "string",
            "description": "The city and state, e.g. San Francisco, CA"
          },
          "unit": {
            "type": "string",
            "enum": ["celsius", "fahrenheit"]
          }
        },
        "required": ["location"]
      }
    }
  }
]

与tool配套的还有tool_choice：指定模型是自动选择工具，还是强制选择某个函数，用于控制模型稳定性的一种手段。
parallel_tool_calls：指定是否并行调用函数，也就是返回多次调用，以极端case，用户问上海，杭州，北京明天天气分别如何，该开关打开后，会返回三次函数调用请求。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

[
  {
    "id": "call_62136355",
    "function": {
      "arguments": { "city": "上海" },
      "name": "check_weather"
    }
  },
  {
    "id": "call_62136356",
    "function": {
      "arguments": { "city": "杭州" },
      "name": "check_weather"
    }
  },
  {
    "id": "call_62136357",
    "function": {
      "arguments": { "city": "北京" },
      "name": "check_weather"
    }
  }
]

Single Agent设计模式

在深入理解 Agent 之前，我们需要明确一点：Agent 并非一种全新的编程语言或技术，而更像是一种设计模式。它利用大型语言模型（LLMs）作为核心驱动力，结合特定的策略和工具，以完成特定的任务。

正如设计模式在软件工程中提供可复用的解决方案一样，Single Agent 的设计模式为构建智能系统提供了一种结构化的方法。它帮助我们组织和管理复杂的逻辑，并根据实际需求进行调整。Single Agent 致力于解决特定的问题，而不是试图处理所有问题。

ReAct模式 Reasoning and Acting)

• 核心思想： ReAct 模式是一种最基本的 Agent 设计模式，它让大型语言模型（LLMs）在推理（Reasoning）和行动（Acting）之间循环交替进行。
• 工作流程：
  1. 观察 (Observation)： Agent 获取当前的状态或信息（例如，用户输入、工具返回的结果）。
  2. 推理 (Reasoning)： LLM 基于观察，思考接下来应该做什么，选择合适的工具或制定行动计划。
  3. 行动 (Acting)： Agent 执行 LLM 决定的行动，例如，调用工具、生成回复、或者更新内部状态。
  4. 循环： Agent 返回到观察步骤，继续下一轮的推理和行动，直到完成任务。
• 特点：
  • 动态决策： LLM 自主决定下一步动作，使得 Agent 具有高度的灵活性。
  • 交互式： 通过反复的观察、推理和行动，Agent 能够逐步解决复杂的问题。
  • 基础模式： 许多更复杂的 Agent 模式都建立在 ReAct 模式之上。
• 适用场景： 适用于需要多步骤推理和决策的任务，例如，回答复杂的问题、规划行程等。
  

Plan And Execute

• 核心思想： Plan And Execute 模式在 ReAct 模式的基础上，引入了 规划（Planning） 阶段。它让 LLM 首先进行全局的规划，将复杂任务分解为多个子任务，然后再逐个执行。
• 工作流程：
  1. 规划 (Planning)： LLM 分析任务目标，生成一系列有序的子任务或步骤。
  2. 执行 (Executing)： Agent 按照规划的顺序，逐个执行子任务。在执行每个子任务时，可以采用 ReAct 模式或其他更适合的模式。
  3. 整合： Agent 将各个子任务的结果整合，最终完成整体任务。
• 特点：
  • 结构化执行： 通过预先的规划，使得复杂任务的执行更加结构化和有序。
  • 模块化： 子任务可以由不同的 Agent 组件执行，实现模块化设计。
  • 可扩展性： 更容易扩展到处理更复杂的任务，通过新增或修改子任务来实现。
• 适用场景： 适用于需要处理复杂任务，且可以被分解成多个子任务的场景，例如，构建复杂的流程、完成多阶段的任务等。
  

Reflection

• 核心思想： Reflection 模式引入了一个额外的 反思（Reflection） 步骤，让 LLM 对自身的输出进行评估和改进。
• 工作流程：
  1. 生成 (Generation)： LLM 生成初始的答案、文本或翻译结果。
  2. 反思 (Reflection)： 另一个 LLM 或规则引擎，对生成的初始结果进行评估和纠错。
  3. 改进 (Improvement)： 根据反思的结果，LLM 对初始结果进行修改和改进。
• 特点：
  • 提高质量： 通过反思机制，能够有效地减少错误和提高输出质量。
  • 自我纠错： Agent 具有一定的自我纠错能力，能够不断优化自身的表现。
  • 适用于翻译： 特别适合于翻译、文本生成等需要高准确率的任务。
• 适用场景： 适用于需要高准确率、高质量输出的任务，例如，翻译、文本编辑、代码生成等。
  

Multi Agent设计模式

Multi Agent 同样是一种设计模式，它并非特定的技术或工具。它专注于解决在复杂业务场景下，多个 Single Agent 之间的协作问题。你可以将 Multi Agent 看作是一个团队，每个成员（Single Agent）都有自己的专长，他们需要互相协作，才能完成共同的目标。
当前 Multi Agent 主要处于探索阶段，各家发布的所谓Multi Agent框架本质上是对自身业务特点产生的Agent分工模式封装。目前主流框架实现的基础模式有下面几种。

Network 模式

• 结构: Network 模式是一种去中心化的模式，其中各个 Agent 之间相互连接，形成一个网络。每个 Agent 都可以与其他 Agent 直接或间接地进行沟通和协作。
• 工作方式: Agent 之间可以根据需要自主地发起沟通、传递信息，并请求帮助。它们没有固定的领导者，通过分布式的方式进行协调。
• 特点:
  • 去中心化: 没有中心控制节点，每个 Agent 都是独立的。
  • 灵活性高: Agent 之间可以自由地连接和断开，网络结构可以动态变化。
  • 适应性强: 可以更好地适应复杂和不确定的环境。
  • 容错性好: 当某个 Agent 失效时，不会影响其他 Agent 的正常工作。
• 适用场景: 适用于需要高度灵活性、动态变化的任务，例如，开放式的探索性研究、分布式信息收集等。
• 举例: 可以想象成一个开放的科研团队，每个研究人员（Agent）之间可以自由交流，共同探索研究方向。
  

supervisor模式

• 结构: Supervisor 模式引入了一个中心化的监管者 (Supervisor) Agent，负责协调和管理其他 Agent (Worker Agent)。Worker Agent 专注于执行特定的任务，而 Supervisor Agent 负责监控任务执行、分配任务，并在必要时进行干预。
• 工作方式: Worker Agent 向 Supervisor Agent 汇报工作进度和结果，Supervisor Agent 根据情况调整任务分配和执行策略。
• 特点:
  • 中心化管理: 有明确的领导者，易于管理和控制。
  • 任务分配明确: Supervisor Agent 负责任务分配，Worker Agent 专注于执行。
  • 执行效率较高: 在明确的目标和计划下，通常执行效率较高。
  • 容易调试： 更容易监控和调试 Agent 的执行过程。
• 适用场景: 适用于任务目标明确、需要中心化控制的场景，例如，多步骤的任务流程、需要严格监控的任务执行等。
• 举例: 可以想象成一个项目管理团队，项目经理 (Supervisor Agent) 负责分配任务，团队成员 (Worker Agent) 负责执行任务。
  

Hierarchical Team

• 结构: Hierarchical Team 模式是一种层级化的组织结构，其中 Agent 分为不同的层级，上层 Agent 负责指导下层 Agent 的工作。每个层级的 Agent 都有不同的职责。
• 工作方式: 上层 Agent 将任务分解给下层 Agent，下层 Agent 完成任务后向上层 Agent 汇报。层级之间的信息传递是逐层进行的。
• 特点:
  • 层级化管理: 有清晰的层级结构，易于管理大型团队。
  • 分工明确: 不同层级的 Agent 负责不同的任务，分工明确。
  • 任务逐步分解: 复杂任务可以被逐步分解到不同的层级。
  • 易于扩展： 可以通过增加层级或增加每个层级的 Agent 来扩展系统。
• 适用场景: 适用于需要处理非常复杂的任务，并需要大规模协作的场景，例如，大型软件开发、复杂的工程项目等。
• 举例: 可以想象成一个大型公司的组织架构，不同部门、不同层级的员工 (Agent) 负责不同的任务。
  

Agent框架

AWS multi-agent-orchestrator

AWS的设计为supervisor模式的落地实践，其最初的Classifier承担了supervisor的职责，负责旗下的Agent管理。

OpenAI Swarm

Swarm为network模式的落地实践，其让智能体之间互相感知，比如下图中的Triage Assistant接收到请求后，主动转交给Weather Assiatant

微软 Magentic-One

也是为supervisor模式的落地实践之一，重点设计在协调上。

ANT agentUniverse

agentUniverse已经设计好了一套固定流程Agent，解决特定的问题。不过其架构支持他实现上述说提到的各种模式，本身Patterns就是可扩展的点。

• PEER 模式组件： 该pattern通过计划（Plan）、执行（Execute）、表达（Express）、评价（Review）四个不同职责的智能体，实现对复杂问题的多步拆解、分步执行，并基于评价反馈进行自主迭代，最终提升推理分析类任务表现。典型适用场景：事件解读、行业分析
• DOE 模式组件： 该pattern通过数据精制（Data-fining）、观点注入（Opinion-inject）、表达（Express）三个智能体，实现对数据密集、高计算精度、融合专家观点的生成任务的效果提升。典型适用场景：财报生成
  

Agent技术难点

Agent之间的协调

如何有效地管理多个 Agent 之间的交互，并降低由于 Agent 个体的自主性带来的不稳定性。

目前大多数框架倾向于在 Supervisor 模式上进行优化。这涉及到引入一个中心化的 Agent (Supervisor)，负责对其他 Agent 的行为进行协调和管理，从而降低系统的整体不稳定性。

Agent之间的记忆

当 Agent 之间允许互相嵌套时，如何有效地管理会话中的记忆 (memory)，特别是对应接口中的 messages 参数

• 主流解决方案：默认私有，显式共享
  • 独立记忆: 目前主流的做法是，默认情况下，Agent 之间的记忆不共享。每个 Agent 维护自己的独立记忆，例如，每个 Agent 都有自己独立的 messages 列表。
  • 显式共享: 如果需要在 Agent 之间共享记忆，需要显式地进行定义。例如，可以通过定义特定的共享记忆对象，或者通过特定的消息传递协议，将记忆从一个 Agent 传递到另一个 Agent。
  • 降低复杂性: 这种默认私有、显式共享的策略，可以有效地降低 Multi Agent 系统中记忆管理的复杂性，并避免因记忆共享而导致的数据混乱和冲突。
  • 更高的控制权： 这种方法让开发者可以更精确地控制 Agent 之间的信息共享，从而构建更可控的 Multi Agent 系统。

• 版权声明: 感谢您的阅读，本文由屈定's Blog版权所有。如若转载，请注明出处。
• 文章标题: Agent Analyze
• 文章链接: https://mrdear.cn/posts/llm_agent_analyze.html