LLM 天生就不擅长规划。需要使用自定义模型和一种独特的方法来提高 LLM 的能力, 以通过 PDDL(规划领域定义语言)生成有效的计划基于严密的表示、微调和上下文学习, 采取行动的步骤仍然很复杂, 而且失败的次数比生产系统想要的要多最后, 它们很难大规模监控和调试。甚至不要谈论幻觉和成本。
这是最早的关于 LLM 代理的论文之一。虽然以今天的标准来看它似乎很基本, 但当时 ChatGPT 还没有发布, 教 LLM 使用工具的想法是开创性的。
“代理"可以通过多种方式定义。一些客户将代理定义为完全自主的系统, 这些系统在较长时间内独立运行, 使用各种工具完成复杂的任务。其他人使用该术语来描述遵循预定义工作流的更规范的实施。在 Anthropic, 我们将所有这些变体归类为代理系统, 但在工作流和代理之间划定了一个重要的架构区别:
- 工作流是通过预定义的代码路径编排 LLM 和工具的系统。
- 另一方面, 代理是 LLM 动态指导自己的流程和工具使用, 保持对他们完成任务方式的控制的系统。
0. 介绍
使用 LLM 构建应用程序时, 我们建议找到尽可能简单的解决方案, 并且仅在需要时增加复杂性。这可能意味着根本不构建代理系统。代理系统通常会以延迟和成本为代价来获得更好的任务性能, 您应该考虑何时进行这种权衡是有意义的。
当需要更高的复杂性时, 工作流为定义明确的任务提供可预测性和一致性, 而当需要大规模的灵活性和模型驱动的决策时, 代理是更好的选择。但是, 对于许多应用程序, 使用检索和上下文示例优化单个 LLM 调用通常就足够了。
目前, 有许多工作流程设计。为了根据它们的重点对它们进行总结, 我们将迄今为止学到的工作流设计模式分为两组: 以 Reflection-focus 和 Planning-focused。
将推理、计划和行动分解为不同的组件可以减少65%的代币, 并在生成答案方面提高4-5%的准确性。
关键原则是, 我们不是循环访问计划->工具使用->观察->推理->计划, 而是在一次调用中生成有效计划的列表, 从工具中获取观察结果并在一次调用中生成最终答案。
1. 工作流设计模式
为了根据它们的重点对它们进行总结, 我们将迄今为止学到的工作流设计模式分为两组: 以 Reflection-focus 和 Planning-focused。
1.1 Reflection-focus
Reflection 允许代理从经验中学习, 从而提高适应性和弹性。这些代理人强调反省和从过去的经验中学习。他们分析以前的行动和结果以改进未来的行为。通过评估他们的绩效, 他们发现错误和成功, 从而实现持续改进。这种反思过程使代理能够随着时间的推移调整其策略, 从而更有效地解决问题。
LangChain 博客
1.2 Planning-focused
规划使代理能够有条不紊地处理任务, 从而提高效率和效果。这些代理在采取行动之前会优先考虑制定结构化计划。他们将复杂的任务分解为可管理的子任务, 并对它们进行逻辑排序以实现特定目标。通过制定详细的计划, 这些代理可以预测潜在的挑战并有效地分配资源, 从而产生更有条理和目标导向的行为。
https://arxiv.org/pdf/2402.02716
- 计划与解决: 重新计划→→任务列表。
- LLM 编译器: →联合执行并行→ 计划行动。
- REWOO: 计划(包括依赖项)→ 操作(取决于上一步)。
- Storm: 搜索大纲 → 在大纲中搜索每个主题 → Summarize 转换为长文本。
在查看这些设计模式时, 我们将工作流视为业务流程协调程序。每个节点可以表示一个 LLM 任务、一个函数调用和其他任务, 例如检索增强生成(RAG)任务, 我们通常将其视为另一种类型的函数调用。这个概念是我们开发自己的代理的主要驱动力之一。我们将工作流设计为灵活的任务编排器, 允许开发人员创建各种工作流来解决不同的问题。
1.3 两种特定的工作流设计模式
1.3.1 ReAct 模式
ReAct 原则很简单, 反映了人类智能的一个核心方面: “由语言推理指导的行动”。每次行动后, 都有一个内心的"观察"或自我反省: “我刚刚做了什么？我实现了我的目标吗？这使代理能够保留短期记忆。在 ReAct 之前, 推理和行动被视为单独的过程。
例如, 假设你让某人在你的桌子上找到一支笔, 你给出分步说明(类似于 Chain-of-Thought 提示策略):
- 首先, 检查笔架。
- 然后, 看看抽屉里。
- 最后, 检查计算机显示器后面。
在特定场景中实现 Agent 需要自定义两个关键组件:
- 提示模板中的少数镜头示例
- 函数调用的外部工具的定义
少数镜头的例子基本上反映了结构化的人类思维模式。查看不同设计模式的提示模板是了解 Agent 设计的好方法。一旦掌握了这种方法, 它就可以类似地应用于其他设计模式。
1.3.2 Plan-Solve 模式
顾名思义, 这种设计模式涉及先规划, 后执行。如果说ReAct更适合于像"从桌子上拿笔"这样的任务, 那么Plan & Solve更适合像"制作一杯纯白的"这样的任务。您需要计划, 并且计划在此过程中可能会发生变化(例如, 如果您打开冰箱发现没有牛奶, 则可以在计划中添加"购买牛奶"作为新步骤)。
- Planner: 负责使 LLM 能够生成多步骤计划以完成大型任务。在代码中, 既有 Planner 又有 Replanner。Planner 最初负责生成计划;另一方面, Replanner 在每个单独的任务完成后开始发挥作用, 根据当前进度调整计划。因此, Replanner 的提示不仅包括零镜头输入, 还包括目标、原始计划和已完成步骤的状态。
- 执行程序: 接收用户的查询和计划中的步骤, 然后调用一个或多个工具来完成任务。
1.4 其他工作流设计模式
1.4.1 无观察的理性(REWOO)
REWOO(Reason without Observation) 是 ReAct 中观察过程的变体。虽然 ReAct 遵循以下结构: Thought → Action → Observation, 而 REWOO 通过删除显式观察步骤来简化此操作。相反, 它将 observation 隐式嵌入到下一个执行单元中。在实践中, 下一个执行程序会自动观察上一步的结果, 从而简化流程。
1.4.2 LLMCompiler
在计算机科学中, 编译器是指为优化计算效率而编排任务的过程。正如原始论文中概述的那样, 用于并行函数调用的 LLM 编译器背后的概念简单而有效: 它旨在通过启用并行函数调用来提高效率。例如, 如果用户问"AWS Glue 和 MWAA 之间有什么区别”, 编译器将同时搜索 AWS 服务定义并合并结果, 而不是按顺序处理每个查询。
1.4.3 基本反射
基本反射可以比作学生(Generator)和教师(Reflector)之间的反馈循环。学生完成作业, 教师提供反馈, 学生根据此反馈修改他们的作业, 重复这个循环, 直到任务圆满完成。
1.4.3 反射
Reflexion 建立在基本反射的基础上, 结合了强化学习的原则。在论文 Reflexion: Language Agents with Verbal Reinforcement Learning 中描述, 这种方法超越了简单的反馈。它使用外部数据评估响应, 并强制模型解决任何冗余或遗漏, 从而使反射过程更加稳健, 输出更加精细。
1.4.4 语言代理树搜索(LATS)
语言代理树搜索在语言模型中统一推理、行动和规划一文中详细介绍了 LATS。它结合了多种技术, 包括Tree Search、ReAct和Plan & Solve。LATS 使用树搜索来评估结果(从强化学习中汲取), 同时还集成反射以实现最佳结果。实质上, LATS 可以用以下公式表示:
LATS = 树搜索 + 反应 + 计划与解决 + 反思 + 强化学习。
在提示设计方面, LATS与早期的方法如Reflection、Plan & Solve和ReAct之间的差异微乎其微。关键的新增功能是树搜索评估步骤, 并在任务上下文中返回这些评估结果。在架构上, LATS 涉及多轮基本反射, 多个生成器和反射器协同工作。
1.4.5 自我发现
Self-Discovery 的核心是允许大型模型在更精细的级别上反映。虽然计划与解决侧重于任务是否需要额外的步骤或调整, 但自我发现更进一步, 鼓励对任务本身的反思。这涉及评估任务的每个组件以及这些组件的执行。
1.4.5 Storm
Storm 在论文 Assisted in Writing Wikipedia-like Articles From Scratch with Large Language Models 中进行了概述, 介绍了一种从头开始生成综合文章的工作流程, 类似于 Wikipedia 条目。代理首先使用外部工具搜索信息并生成大纲。然后, 它根据大纲为每个部分生成内容, 使过程结构化且高效。
2. 护栏
护栏是确保AI代理在安全和道德范围内运作的机制, 使其操作与用例、组织政策和社会规范保持一致。在传统软件中, 护栏侧重于安全措施、错误处理和用户输入验证。虽然这些元素仍然与代理AI相关, 但代理的自主性需要额外的监督, 例如道德准则、实时验证和动态监控, 以防止意外后果。
传统AI在人类的密切监督下运行, 自主行动的风险最小。相比之下, 代理AI必须独立运行, 需要复杂的护栏来管理安全性、监控道德行为、验证操作, 并通过日志记录和审计提供透明度。这种监督确保代理人即使在做出独立决策时也能负责任地行事, 降低风险并保持与道德标准的一致性。
- 企业级安全性和合规性
- 防止偏离主题的操作
- 合乎道德的AI框架和验证
- 日志记录和监控
- 增强的可观察性
3. 实现
3.1 ReWOO 的 langgraph 实现
ReWOO 的 langgraph 实现实现了 Planner(Re)、Worker(Act) 和 Solver
参考: https://github.com/langchain-ai/langgraph/blob/main/examples/rewoo/rewoo.ipynb
3.1.1 计划
计划器生成执行工具和其他步骤的可能策略, 这将以最佳方式解决问题。这些被提供给工人进行执行和证据收集。
3.1.2 Worker
执行任务的几个函数, 这里没什么特别的。
3.1.3 Solver
根据Woker的结果, 即计划员生成的计划, 求解器生成最终答案。
3.2 多代理系统
涉及AI代理网络协作解决问题或实现需要不同专业知识的目标。想想一个团队协作, 它在内部相互沟通, 互相批评, 并相互改进结果, 以解决给定的任务, 而单个代理只能从与之通信的人那里获得反馈。
多智能体系统特别引人注目, 因为它们可以动态地适应新的挑战、委派责任, 甚至相互协商以优化结果。多智能体系统旨在将人在回路中减少到最低限度, 仅在需要时或设计时才要求人工监督和/或批准采取行动。
参考:
ReAct: Synergizing Reasoning and Acting in Language Models
Plan-and-Solve Prompting: Improving Zero-Shot-Chain-of-Thought Reasoning by Large Language Models
Building effective agents
