大型语言模型(LLM)的潜力远不止于简单的文本生成。通过引入Agent(智能体)的概念,LLM可以执行更复杂的任务,与外部工具交互,并进行规划和推理。以下是当前业界在构建高级LLM应用时,需要了解的八种核心Agent模式。

一、反思模式 (Reflection Pattern)

核心思想: 通过引入用户反馈和模型的自我批判与修正,迭代提升输出质量,使其更符合用户期望。这种模式强调了学习和适应的过程。

工作流程:

  1. 用户输入查询 (User Input): 用户通过界面或API向Agent提交具体的请求或问题。
  2. LLM生成初始输出 (Initial Output Generation): Agent内置的LLM接收查询,并生成一个初步的响应。
  3. 用户反馈 (User Feedback): 用户评估初步响应,并针对其不足或需改进之处提供明确的反馈。
  4. LLM反思与调整 (Reflection and Adjustment): LLM结合用户的反馈,对先前的输出进行“反思”——重新评估、分析不足,并据此调整其思考路径和生成策略。
  5. 迭代优化 (Iterative Process): 第3步和第4步可能会重复多次。每一次迭代,LLM都会尝试生成一个更优的响应,直至用户满意或达到预设的优化目标。
  6. 返回最终响应 (Final Response): 经过一次或多次反思和调整后,最终优化后的响应通过界面或API返回给用户。

流程图:

否/满意
用户输入查询
LLM生成初始输出
用户提供反馈
LLM进行反思与调整
返回最终响应

概念公式: 我们可以将迭代优化的过程概念化地表示为: Ri+1=Reflect(Ri,Fu)Ri+1=Reflect(Ri,Fu)Ri+1=Reflect(Ri,Fu) 其中:

  • RiRiRi 代表第 iii 次迭代的响应。
  • FuFuFu 代表用户的反馈。
  • Ri+1Ri+1Ri+1 代表经过反思和调整后的下一次响应。
  • Reflect(⋅)Reflect(⋅)Reflect() 函数代表LLM基于当前响应和用户反馈进行反思和调整的过程。

将“Reflection”翻译为“反思”而非“反射”,能更准确地体现模型在此模式下主动进行思考、评估和修正输出的能力,这与其核心工作机制更为吻合。

二、工具使用模式 (Tool Use Pattern)

核心思想: 赋予LLM调用外部工具、API或知识库的能力,以克服其固有知识的局限性,获取实时信息或执行特定领域的专业任务。

工作流程:

  1. 用户输入查询 (User Input): 用户向Agent提出查询。
  2. LLM处理与决策 (Query Processing and Tool Identification): Agent中的LLM分析查询,判断是否需要以及何种外部工具或API来辅助回答。这可能涉及到对查询意图的理解和所需信息的判断。
  3. 调用工具/API (Tool/API Invocation): 如果LLM确定需要外部协助,它会选择合适的工具(例如搜索引擎、计算器、数据库接口、特定行业API等,这些工具可能预先注册并存储在向量数据库中以便检索)并发起调用。
  4. 信息整合与生成响应 (Information Integration and Response Generation): LLM接收来自工具或API的返回信息,将其与自身知识整合,并生成一个综合的、更准确的响应。响应格式可以是文本、图表、数据摘要等。
  5. 返回给用户 (Return to User): 最终响应通过界面或API呈现给用户。

流程图:

需要外部工具?
不需要外部工具
用户输入查询
LLM处理查询
识别并选择工具/API
调用工具/API
获取工具返回信息
LLM整合信息并生成响应
返回给用户

概念公式: LLM决定是否使用工具可以表示为:
UseTool(Q)={Trueif P(toolNeeded∣Q)>θ Falseotherwise\text{UseTool}(Q) = \begin{cases} \text{True} & \text{if } P(\text{toolNeeded}|Q) > \theta \ \text{False} & \text{otherwise} \end{cases} UseTool(Q)={Trueif P(toolNeededQ)>θ Falseotherwise
其中:

  • QQQ 是用户的查询。
  • P(ToolNeeded∣Q)P(\text{ToolNeeded}|Q)P(ToolNeededQ) 是LLM判断查询 QQQ 需要工具的概率。
  • θθθ 是一个预设的阈值。

最终响应 R 可以看作是LLM内部知识 KLLM 和工具提供的信息 ItoolItoolItool 的函数: R=Generate(KLLM,Itool)R=Generate(KLLM,Itool)R=Generate(KLLM,Itool)

三、ReAct模式 (Reasoning and Acting Pattern)

核心思想: 将LLM的推理能力与行动能力紧密结合,形成一个“思考 -> 行动 ->观察 -> 思考…”的动态循环,使LLM能够通过与环境(或工具)的交互来解决复杂问题。

工作流程:

  1. 用户提出任务/查询 (User Query): 用户向系统下达一个需要完成的任务或请求。
  2. LLM进行推理 (Reasoning - LLM): LLM(通常扮演“推理者”角色)分析用户的查询,理解目标,并制定一个初步的行动计划或策略(思考,Thought)。这包括决定首先应该采取什么行动(Action)以及使用什么工具(Tool)。
  3. 执行行动 (Action - Tools): 根据LLM的指令,系统调用相应的工具或执行特定的操作。
  4. 观察环境反馈 (Observation - Environment): 工具执行操作后,会产生一个结果或状态变化,这个结果被视为来自“环境”的观察(Observation)。
  5. LLM再推理与生成 (Further Reasoning and Generation - LLM): LLM接收这个观察结果,评估当前状态与目标的差距。基于新的观察,LLM会进行新一轮的推理(Thought):
    • 如果任务未完成,它会规划下一步的行动,回到第3步,形成一个循环。
    • 如果任务已完成或判断可以结束,LLM(此时可能扮演“生成者”角色,或同一LLM承担双重角色)会基于整个交互过程和最终观察结果,生成最终的响应。
  6. 返回响应 (Response): 最终生成的响应返回给用户。

流程图:

产生行动计划
判断任务完成
用户查询
LLM: 思考/推理
执行行动 (调用工具)
观察环境/工具结果
LLM: 生成最终响应
返回响应给用户

概念公式: ReAct循环中的每一步可以表示为:

  1. 思考 (Thought): τt=Reason(St−1,Ot−1,Quser)τt=Reason(St−1,Ot−1,Quser)τt=Reason(St1,Ot1,Quser)
  2. 行动 (Action): At=SelectAction(τt)At=SelectAction(τt)At=SelectAction(τt)
  3. 观察 (Observation): Ot=Execute(At,Environment)Ot=Execute(At,Environment)Ot=Execute(At,Environment) 其中:
  • St−1St−1St1 是上一步的状态。
  • Ot−1Ot−1Ot1 是上一步的观察结果。
  • QuserQuserQuser 是用户的原始查询或目标。
  • τtτtτt 是当前步骤的思考过程。
  • AtAtAt 是基于思考选定的行动。
  • OtOtOt 是执行行动后从环境中获得的新观察。 这个过程(τ→A→O)(τ→A→O)(τAO)会迭代进行,直到任务完成。

ReAct模式的关键在于其迭代循环的特性。环境(工具执行)返回的结果会再次输入给LLM进行推理,指导后续行动,而非简单地直接生成最终答案。它强调了LLM在解决问题过程中的动态规划和适应能力。

四、规划模式 (Planning Pattern)

核心思想: 对于复杂任务,首先由一个“规划器”LLM将其分解为一系列更小、更易于管理和执行的子任务,然后按计划逐步执行这些子任务,并根据执行结果动态调整后续计划。

工作流程:

  1. 用户提出复杂查询/任务 (User Query): 用户提交一个多步骤或复杂的目标。
  2. 计划器生成任务序列 (Planner Generates Tasks): 一个专门的LLM(计划器 Planner)接收查询,分析并将其分解为一系列有序的、逻辑相关的子任务(Generated Tasks)。
  3. 任务分配给执行者 (Task Delegation to Executor): 生成的子任务(通常是逐个或按批次)被传递给一个或多个执行者Agent(例如,一个ReAct模式的Agent)。
  4. 执行者执行单个任务 (Executor Performs Task): 执行者Agent负责完成分配给它的具体子任务,并将执行结果(成功、失败、具体产出等)返回给计划器。
  5. 结果反馈与计划调整 (Feedback and Plan Adjustment): 计划器接收执行结果。
    • 如果一个子任务成功完成,计划器可能会触发下一个子任务的执行。
    • 如果遇到失败或非预期结果,计划器可能需要重新评估计划,修改、删除或增加子任务,甚至重新规划。
    • 计划器会持续跟踪整体任务的完成状态(Finished?)。
  6. 生成最终响应 (Final Response): 当所有子任务成功完成,或者计划器判断已达到用户目标时,计划器会综合所有执行结果,生成最终的响应并返回给用户。

流程图:

否 (所有任务完成)
用户复杂查询
计划器LLM: 分析并生成任务序列
是否有未执行任务
分配子任务给执行者Agent
执行者Agent执行子任务
返回执行结果给计划器
计划器: 评估结果, 调整计划
计划器: 生成最终响应
返回响应给用户

概念公式: 初始计划 P0 由规划器生成: P0=task1,task2,...,taskn=Planner(Quser)P0=task1,task2,...,taskn=Planner(Quser)P0=task1,task2,...,taskn=Planner(Quser) 在执行第 iii 个任务 taskitaskitaski 后,得到结果 resiresiresi。计划器可能会更新计划: Pi+1=AdjustPlan(Pi,taski,resi)Pi+1=AdjustPlan(Pi,taski,resi)Pi+1=AdjustPlan(Pi,taski,resi) 直到所有任务完成或目标达成。

五、多智能体模式 (Multi-agent Pattern)

核心思想: 模拟真实世界中团队协作的方式,将一个复杂任务分解并分配给多个具有不同角色或专长的Agent协同完成。每个Agent负责一部分工作,并通过层级或网络结构进行通信和协作。

工作流程示例(以软件开发为例):

  1. 用户提出需求 (User Query): 用户提出一个较复杂的项目需求,例如开发一个小型应用。
  2. 项目经理Agent (PM Agent): 接收用户需求,进行初步分析、需求拆解,并将高层任务分配给合适的下级Agent。PM Agent负责整体协调和进度管理。
  3. DevOps Agent / 架构师Agent等 (Specialized Agents):
    • DevOps Agent: 可能负责环境配置、部署流程等。
    • 技术负责人Agent (Tech Lead Agent): 可能负责技术选型、模块设计,并将更具体的开发任务分配给SDE Agent。
  4. 软件开发工程师Agent (SDE Agent): 负责具体的代码编写、单元测试等任务。
  5. 任务执行与逐级反馈 (Task Execution and Hierarchical Feedback): 每个Agent执行其被分配的任务。完成后,结果会反馈给其上级Agent。例如,SDE Agent完成编码后,结果反馈给Tech Lead Agent;Tech Lead Agent整合模块后,可能反馈给PM Agent。
  6. 结果汇总与综合响应 (Result Aggregation and Final Response): PM Agent收集所有下级Agent的工作成果和报告,进行整合和最终校验。
  7. 返回给用户 (Return to User): PM Agent将最终完成的项目成果或综合报告以统一的响应形式返回给用户。

流程图(简化层级示例):

分配任务
分配任务
分配任务
分配任务
完成反馈
完成反馈
完成反馈
完成反馈
综合结果
用户需求
项目经理 Agent
DevOps Agent
技术负责人 Agent
SDE Agent 1
SDE Agent 2
最终响应

概念公式: 一个多智能体系统 (MAS) 可以表示为一组Agent和它们之间的交互: MAS=(Ag1,Ag2,...,Agk,C,O)MAS=(Ag1,Ag2,...,Agk,C,O)MAS=(Ag1,Ag2,...,Agk,C,O) 其中:

  • Ag1Ag1Ag1,…,AgkAgkAgk 是系统中 k 个Agent的集合。
  • C 定义了Agent之间的通信协议和协作机制。
  • O 是整个系统的目标或要解决的复杂任务。 每个Agent Agj 可能有其自身的内部状态 sjsjsj 和行为函数 bjbjbj:
  • sj′=bj(sj,messagesreceived)s_j' = b_j(s_j, {messages_received})sj=bj(sj,messagesreceived)

特点: 这种模式通过任务分解和专业化分工,能够处理高度复杂的系统性任务。Agent之间的通信协议和协作机制是成功的关键。

六、记忆增强模式 (Memory-Augmented Pattern)

核心思想: 为Agent配备显式的记忆机制(如短期工作记忆、长期知识库、向量数据库等),使其能够存储、检索和利用来自过去交互或大量数据的信息。这使得Agent能够提供更具上下文感知性、一致性和个性化的响应,并克服LLM固有的上下文窗口限制。

工作流程:

  1. 用户查询/输入 (User Query/Input): 用户向Agent发出请求。
  2. 记忆检索 (Memory Retrieval): Agent首先查询其记忆系统(例如,基于查询的语义相似性从向量数据库中检索相关信息,或从对话历史中提取上下文)。
  3. 上下文增强 (Context Augmentation): 检索到的相关记忆被用来增强原始查询或作为额外的上下文信息提供给LLM。
  4. LLM处理 (LLM Processing): LLM基于增强后的查询和上下文信息进行推理和生成。
  5. 生成响应 (Generate Response): LLM生成响应。
  6. 记忆更新 (Memory Update): 当前交互的关键信息(如用户偏好、新知识点、对话摘要等)被处理并存储回记忆系统,以供未来使用。
  7. 返回给用户 (Return to User): 响应返回给用户。

流程图:

用户查询/输入
记忆检索
上下文增强
LLM 处理
生成响应
记忆更新
返回给用户

概念公式: 响应 R 的生成可以表示为:
Mretrieved=Retrieve(Memory,Quser)Mretrieved=Retrieve(Memory,Quser)Mretrieved=Retrieve(Memory,Quser)
R=LLM(Quser,Mretrieved)R=LLM(Quser,Mretrieved)R=LLM(Quser,Mretrieved)
记忆更新:
Memorynew=Update(Memoryold,Quser,R,Contextcurrent)Memorynew=Update(Memoryold,Quser,R,Contextcurrent)Memorynew=Update(Memoryold,Quser,R,Contextcurrent)
其中:

  • MretrievedMretrievedMretrieved 是检索到的记忆。
  • ContextcurrentContextcurrentContextcurrent 是当前交互的上下文。

七、自我纠错/自我批判模式 (Self-Correction/Self-Critique Pattern)

核心思想: LLM或Agent系统内部包含一个机制,使其能够自主地审查、评估并改进其自身生成的初步输出。这种批判和修正过程基于预定义的启发式规则、质量标准、一致性检查,或者由另一个“批判者”LLM执行,从而在没有即时外部反馈的情况下提升输出的准确性和可靠性。

工作流程:

  1. 初始输出生成 (Initial Output Generation): LLM根据输入生成一个初步的响应或计划。
  2. 内部批判/评估 (Internal Critique/Evaluation): 系统对初始输出进行审查。这可能包括:
    • 检查事实准确性(可能借助外部工具)。
    • 评估逻辑连贯性和合理性。
    • 检查是否符合特定约束或格式要求。
    • 识别潜在的偏见或不安全内容。
  3. 生成修正指令/反馈 (Generate Correction Instructions/Feedback): 批判模块生成关于如何改进输出的具体建议或修正指令。
  4. 输出修正 (OutputRefinement): 原始LLM或另一个专门的修正LLM根据批判结果和修正指令来修改初始输出。
  5. 迭代修正 (Iterative Refinement) (可选): 第2至第4步可以重复多次,直到输出达到预设的质量标准或无进一步改进空间。
  6. 最终输出 (Final Output): 返回经过自我纠错后的最终响应。
  7. 返回给用户 (Return to User): 最终输出返回给用户。

流程图:

发现问题/可改进
达到质量标准/无问题
用户输入
LLM: 初始输出生成
内部批判/评估模块
生成修正指令
LLM: 根据指令修正输出
最终输出
返回给用户

概念公式: 令 O0 为初始输出。 批判过程: Critiquei=Critic(Oi)Critiquei=Critic(Oi)Critiquei=Critic(Oi) 修正过程: Oi+1=Refine(Oi,Critiquei)Oi+1=Refine(Oi,Critiquei)Oi+1=Refine(Oi,Critiquei) 这个过程迭代进行,直到 CritiquekCritiquekCritiquek 满足某个停止条件(例如,批判分数为优,或无明显错误)。最终输出为 Ok。

八、分层规划与执行模式 (Hierarchical Planning and Execution Pattern)

核心思想: 借鉴人类解决复杂问题时采用的分解策略,此模式通过一个或多个层级的规划来实现。高层规划器将宏大目标分解为若干抽象子目标,这些子目标再由中层或低层规划器进一步细化为具体的、可执行的动作序列。这种分层结构使得Agent能够处理更长远、更复杂的任务,并能更好地适应环境变化和不确定性。

工作流程:

  1. 用户定义高层目标 (User Defines High-Level Goal): 用户提出一个复杂的、可能需要多步骤才能完成的目标。
  2. 高层规划器分解任务 (High-Level Planner Decomposes Task): 高层规划器(通常是一个LLM)将主目标分解为一系列有序的、较高层次的子目标或阶段 (e.g., SubGoal1,SubGoal2,…,SubGoaln)。
  3. 中/低层规划器细化子目标 (Mid/Low-Level Planner Refines Sub-Goals): 对于每个高层子目标,一个或多个中层或低层规划器(可以是专门的LLM或算法)将其进一步细化为更具体的子任务或可执行的动作序列 (e.g., Action1.1,Action1.2,…)。
  4. 执行器执行动作 (Executor Performs Actions): 最底层的具体动作由执行器(可能是ReAct模式的Agent或直接调用工具)执行。
  5. 结果逐层反馈与监控 (Results Propagate Upwards & Monitoring): 执行结果从底层逐级向上传递。各层规划器监控其负责的子目标/任务的执行状态,并根据实际结果进行调整。
  6. 动态重规划 (Dynamic Replanning): 如果某个动作失败或环境发生未预期的变化,可能需要从相应的层级开始进行重规划。
  7. 目标完成 (Goal Achievement): 当所有层级的任务都成功完成,最终实现用户定义的高层目标。
  8. 返回结果给用户 (Return Result to User): 最终结果返回给用户。

流程图:

重规划循环
选择一个高层子目标
选择一个动作
当前动作序列完成/需调整
当前子目标完成/需调整
所有高层子目标完成
中/低层规划器: 细化为具体动作序列
获取动作结果
高层规划器: 分解为高层子目标
用户高层目标
处理高层子目标
执行具体动作
执行器: 执行动作
最终目标达成
返回结果给用户

概念公式:
高层计划:
PH=SG1,SG2,...,SGm=PlannerH(Goaluser)PH=SG1,SG2,...,SGm=PlannerH(Goaluser)PH=SG1,SG2,...,SGm=PlannerH(Goaluser)
对于每个子目标 SGjSGjSGj,中层/低层计划:
PL(SGj)=Aj1,Aj2,...,Ajk=PlannerL(SGj)PL(SGj)=Aj1,Aj2,...,Ajk=PlannerL(SGj)PL(SGj)=Aj1,Aj2,...,Ajk=PlannerL(SGj)
执行函数:
Res(Aji)=Execute(Aji)Res(Aji)=Execute(Aji)Res(Aji)=Execute(Aji)
状态更新和重规划依赖于
Res(Aji)Res(Aji)Res(Aji)
和当前世界状态。

通过理解和应用这些Agent模式,开发者可以构建出更加智能、灵活和强大的AI应用,更好地满足用户的复杂需求。

Logo

火山引擎开发者社区是火山引擎打造的AI技术生态平台,聚焦Agent与大模型开发,提供豆包系列模型(图像/视频/视觉)、智能分析与会话工具,并配套评测集、动手实验室及行业案例库。社区通过技术沙龙、挑战赛等活动促进开发者成长,新用户可领50万Tokens权益,助力构建智能应用。

更多推荐