AI Agent 方法以及应用_ai agent应用

Agent介绍

1. 规划（Planning）

   子目标和分解：代理将大型任务分解为更小、易于管理的子目标，从而实现复杂任务的高效处理。

   反思和提炼：代理可以对过去的行为进行自我批评和自我反思，从错误中吸取教训，并为未来的步骤改进它们，从而提高最终结果的质量。

   1.1 任务分解

   任务分解主要是的目的是将复杂的任务分解成简单的小任务，这样LLM可以更简单地解决问题。
   思维链（CoT）、思想树

   1.2 自我反省

   自我反省是一个重要的方面，它允许AI Agent通过完善过去的行动决策和纠正以前的错误来迭代地改进。它在现实世界中发挥着至关重要的作用，在现实世界中，试错是不可避免的。

   ReAct（姚等人2023年）通过将动作空间扩展为特定于任务的离散动作和语言空间的组合，将推理和行为集成在LLM中。前者使LLM能够与环境交互（例如使用维基百科搜索API），而后者则提示LLM以自然语言生成推理跟踪。

   Reflexion（Shinn & Labash 2023）是一个为代理配备动态记忆和自我反思能力以提高推理能力的框架。Reflexion 具有标准的强化学习（Reinforcement Learning，RL）设置，其中奖励模型提供简单的二进制奖励，而行动空间则沿用 ReAct 中的设置，即在特定任务的行动空间中加入语言，以实现复杂的推理步骤。每次行动后，AI Agent会计算一个启发式的值，然后根据自我反思的结果决定重置环境以开始新的试验。

   Chain of Hindsight（CoH；Liu 等人，2023 年）通过向模型明确展示一系列过去的输出结果，鼓励模型改进自己的输出结果。

2. 记忆（Memory）

   短期记忆：所有的上下文学习，都是利用模型的短期记忆来学习。

   长期记忆：这为代理提供了在很长一段时间内保留和调用（无限）信息的能力，通常是通过利用外部矢量存储和快速检索

   记忆（Memory），是类似多轮对话中记住之前的输入和设定的一种能力。在当前的大模型架构中，随着对话的增长，要记住之前用户的输入内容再输出需要消耗大量的硬件资源。大多数模型支持的上下文长度都是非常有限的。

   超过这个长度之后，大多数模型的性能都会极具下降或者是不支持。但是长上下文是解决实际问题中必须要面对的。如代码生成、故事续写、文本摘要等场景，支撑更长的输入通常意味着更好的结果。

   人类大脑中的几种类型的记忆：感官记忆（Sensory Memory）、短时记忆（Short-Term Memory，STM）、长时记忆（Long-Term Memory，LTM）、显性/陈述性记忆。

   感官记忆是类似大模型学习原始输入（包括文本、图像或其他模式）的嵌入表征；

   短时记忆可以理解为大模型的上下文学习，类似于prompt。由于受到 Transformer 有限上下文窗口长度的限制，它是短暂和有限的，但是可以每次输入都引入。

   长期记忆一般就是大模型之外作为外部向量存储的数据了，AI Agent可在查询时加以关注，并可通过快速检索进行访问。

   最大内积搜索（MIPS）

   外部存储器可以缓解有限注意力的限制。标准的做法是将信息的嵌入表示保存到向量存储数据库中，该数据库可支持快速的最大内积搜索（MIPS）。

   为了优化检索速度，通常选择近似近邻（ANN）算法来返回近似的前 k 个近邻，从而以损失的少量精度换取巨大的速度提升。

3. 工具使用（Tool Use）

   代理学会调用外部API以获取模型权重中缺少的额外信息（在预训练后通常难以更改），包括当前信息、代码执行能力、对专有信息源的访问等。

Agent 方法

参考：https://mp.weixin.qq.com/s/EWdpOlzrgqOgHHWHdoFyGA

ReAct

论文主页：https://react-lm.github.io/
论文链接：https://arxiv.org/abs/2210.03629
代码链接：https://github.com/ysymyth/ReAct
LangChain：https://python.langchain.com/v0.1/docs/modules/agents/agent_types/react/

实现逻辑：

通过代码看逻辑：
https://github.com/samwit/langchain-tutorials/blob/main/agents/YT_Exploring_ReAct_on_Langchain.ipynb

Agent 要落地一个场景，需要定制两项内容。

• Prompt 模板中 few shot 中的内容。
• function calling 中的外部工具定义。

Plan and Solve

论文名称：Plan-and-Solve Prompting: Improving Zero-Shot Chain-of-Thought Reasoning by Large Language Models
论文链接：https://arxiv.org/abs/2305.04091
代码链接：https://github.com/AGI-Edgerunners/Plan-and-Solve-Prompting
LangChain：
https://github.com/langchain-ai/langgraph/blob/main/examples/plan-and-execute/plan-and-execute.ipynb
https://blog.langchain.dev/planning-agents/

核心思想是首先制定一个分步计划，然后一步一步地执行这个计划。完成特定任务后，您可以重新审视并根据需要调整该计划。

这与典型的 ReAct 相比，ReAct 是一次思考一步。这种“Plan and Solve”的优势包括：

1. 明确的长期规划能力

2. 在执行步骤中运用小型/能力较弱的模型的能力，而仅在规划步骤中使用大型/更优的模型

规划器：负责让 LLM 生成一个多步计划来完成一个大任务。代码中有 Planner 和和 Replanner，Planner 负责第一次生成计划；Replanner 是指在完成单个任务后，根据目前任务的完成情况进行 Replan，所以 Replanner 提示词中除了 Zeroshot，还会包含：目标，原有计划，和已完成步骤的情况。

Planner Prompt：

针对给定的目标，提出一个简单明了的分步计划。此计划应包含各项独立任务，如果正确执行这些任务，将得到正确的答案。不要添加任何多余的步骤。最后一步的结果即为最终答案。确保每一步都包含了所需的所有信息——不要跳过任何步骤。

Replanner Prompt：

针对给定的目标，提出一个简单明了的分步计划。此计划应包含各项独立任务，如果正确执行这些任务，将得到正确的答案。不要添加任何多余的步骤。最后一步的结果即为最终答案。确保每一步都包含了所需的所有信息——不要跳过任何步骤。
您的目标是：
{input}
您最初的计划是：
{plan}
目前已完成的步骤有：
{past_steps}
请据此更新您的计划。如无需更多步骤且可向用户回复答案，请直接告知。否则，请完善计划内容。仅需在计划中添加尚未完成、仍有必要的步骤，切勿重复已执行的步骤作为计划的一部分。

执行器：接受用户查询和规划中的步骤，并调用一个或多个工具来完成该任务。

局限性：每个任务仍然是顺序执行的，这意味着所有完全可以并行处理的操作都会累加到总的执行时间上。可以通过将每个任务表示为DAG（类似于LLMCompiler）而非常规列表来改进这一点，这样可以更高效地利用并行计算资源。

Reason without Observation

论文名称：ReWOO: Decoupling Reasoning from Observations for Efficient Augmented Language Models
论文链接：https://arxiv.org/abs/2305.18323
代码链接：https://github.com/billxbf/ReWOO/
LangChain：
https://github.com/langchain-ai/langgraph/blob/main/examples/rewoo/rewoo.ipynb
https://blog.langchain.dev/planning-agents/

REWOO(Reason without Observation)这种方法是相对 ReAct中的Observation 来说的，ReAct 提示词结构是 Thought→ Action→ Observation, 而 REWOO 把 Observation 去掉了。但实际上，REWOO 只是将 Observation 隐式地嵌入到下一步的执行单元中了，即由下一步骤的执行器自动去 observe 上一步执行器的输出。

在ReWOO中，提出了一种结合多步规划器和变量替换以有效利用工具的智能体。通过以下方式改进ReACT方法：

1. 通过一次性生成使用中的完整工具链来减少 token 消耗和执行时间。通过使用变量替换来避免对规划器LLM进行冗余调用。（ReACT 多次带有冗余前缀的大型语言模型调用（因为系统提示和先前步骤需要为每次推理步骤提供给LLM））
2. 简化微调过程。由于规划数据不依赖于工具的输出，理论上可以在不实际调用工具的情况下对模型进行微调。

简而言之，ReWOO提出的智能体设计旨在通过更高效的规划和执行流程，以及更为简便的模型微调方法，来提升基于语言模型的工具使用效能和效率。

• Planner：负责生成一个相互依赖的“链式计划”，定义每一步所依赖的上一步的输出。

• Worker：用提供的参数执行工具。

• Solver：根据工具观察结果生成初始任务的答案。

局限性：

1. 环境背景信息缺乏时，规划器在工具使用上的效果不佳。通常，这种情况可以通过少量示例提示和/或微调来缓解。
2. 任务仍然按顺序执行，这意味着总执行时间受到每个工具调用的影响，而不仅仅是每一步中最耗时的那一个调用。

LLMCompiler

论文名称：An LLM Compiler for Parallel Function Calling
论文链接：https://arxiv.org/abs/2312.04511
代码链接：https://github.com/SqueezeAILab/LLMCompiler
LangChain：
https://github.com/langchain-ai/langgraph/blob/main/examples/llm-compiler/LLMCompiler.ipynb
https://blog.langchain.dev/planning-agents/>

相比 REWOO 多了并行调用工具的功能。

优点：

1. 通过并行Function calling来提高效率
2. 减少对大型语言模型（LLM）的调用次数，节省了冗余 token 使用的成本

LLMCompiler 包含三个主要组件：

1. 规划器（Planner）：流式传输一个任务的有向无环图（DAG）。
2. 任务获取单元（Task Fetching Unit）：一旦任务可执行，就调度并执行这些任务。
3. 连接器（Joiner/Replanner）：响应用户或触发第二次规划

Planner Prompt

================================ System Message ================================
根据用户查询，创建一个解决方案计划，以实现最大程度的并行处理。每个计划应包括以下 {num_tools} 类型中的一个动作：
{tool_descriptions}
{num_tools}. join(): 收集并合并先前动作的结果。
- 调用 join() 时会召唤一个 LLM 代理，以完成用户查询或等待计划执行完毕。
- join 应始终作为计划中的最后一个动作，并在两种情况下被调用：
  (a) 如果通过收集任务的输出来生成最终响应可以确定答案。
  (b) 如果在执行计划之前无法在规划阶段确定答案。指导原则：
  - 上述每个动作都包含输入/输出类型和描述。
  - 你必须严格遵守每个动作的输入和输出类型。
  - 动作描述中包含了指南。使用这些动作时，你必须严格遵循这些指南。
- 计划中的每个动作必须严格是上述类型之一。遵循每个动作的 Python 约定。
- 每个动作必须有一个唯一ID，且这个ID必须是严格递增的。
- 动作的输入可以是常量或前序动作的输出。如果是后者，使用 $id 的格式来表示将作为输入的前一个动作的ID。
- 总是在计划的最后调用 join，并在调用 join 后说 '<END_OF_PLAN>'。
- 确保计划最大化了并行处理的能力。
- 仅使用提供的动作类型。如果查询不能使用这些动作解决，请调用 join 动作进行后续步骤。
- 绝不引入除已提供之外的新动作。

============================= Messages Placeholder =============================
{messages}
================================ System Message ================================
记住，仅以正确格式回复任务列表！例如：
idx. tool(arg_name=args)
None
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

局限性：

1. 计划器输出解析格式的脆弱性：如果您的函数需要超过1或2个参数，当前的解析格式可能不够健壮。我们可以通过采用流式工具调用来增强其稳定性。

2. 变量替换的脆弱性：在上述示例中，变量替换较为脆弱。可以通过使用微调后的模型和更稳健的语法（例如，利用Lark或工具调用架构）来提高其稳定性。

3. 状态信息可能过长的问题：如果您需要多次重新规划，状态信息可能会变得相当长。为了解决这个问题，当达到一定令牌限制时，您可以添加一个消息压缩器来减小信息体积。

Basic Reflection

LangChain:
https://github.com/langchain-ai/langgraph/blob/main/examples/reflection/reflection.ipynb
https://blog.langchain.dev/reflection-agents/

在构建LLM代理的背景下，反思是指促使LLM观察其过去的行为步骤（以及来自工具或环境的潜在观察）的过程，以便评估所选行动的质量。这一过程随后用于下游任务，如重新规划、搜索或评估。

Prompt Example:

1. Generate Prompt

   您是一名论文助手，负责为用户的请求撰写出色的五段式文章。请根据用户的诉求，生成最优质量的文章。若用户提供批评意见，应基于反馈对之前的文章尝试进行修订并重新提交。
   1

2. Reflect Prompt

   您是一位教师，正在批阅学生的作文提交。针对学生的作文，提出批评与改进建议。具体建议应涵盖多个方面，比如文章的长度、内容的深度、写作风格等。
   1

自我反思本质上是一个循环过程：如果反思步骤能获得额外的上下文或反馈（比如来自工具的观察、检查等），将会更加有效。如果反思步骤仅仅是促使LLM对其输出进行反思，仍然可以提升输出质量（因为LLM有多个“机会”来得到一个好的输出），但这样做的效果并不那么确定。为了更有效地利用反思，结合外部信息或结果验证，可以使LLM的自我调整和学习过程更为精准和高效。

Reflexion

论文名称：Reflexion: Language Agents with Verbal Reinforcement Learning
论文链接：https://arxiv.org/abs/2303.11366
代码链接：https://github.com/noahshinn/reflexion
LangChain：
https://github.com/langchain-ai/langgraph/blob/main/examples/reflexion/reflexion.ipynb
https://blog.langchain.dev/reflection-agents/

Reflexion明确地对其任务响应进行批判性评价，以此产生质量更高的最终响应，但会导致执行时间更长。

三个主要组成部分：

1. 带有自我反思的 Actor（代理）：能够执行任务并对自己产生的结果进行反思和评价。
   • 工具/工具执行
   • 初始响应器：生成初步回应（并进行自我反思）
   • Revisor：基于以往的反思重新作出回应（并再次反思）
2. 外部评估器：特定于任务的（例如，代码编译步骤），用于提供独立于代理的反馈。
3. 情景记忆：存储来自执行者自我反思的结果。

后两个部分高度依赖于特定任务。

Reflexion使用了强化学习的思路。和 Basic reflection 相比，引入了外部数据来评估回答是否准确，并强制生成响应中多余和缺失的方面，这使得反思的内容更具建设性。

局限性：

1.以执行时间换取质量。该方法明确地使 Agent 在几个步骤中批评和修改输出，这通常（并不总是）提高了响应质量，但需要更长的时间才能返回最终答案。

2.“reflections”可以与额外的外部反馈（如验证器）配合，以进一步指导 Actor。

Language Agent Tree Search

论文名称：Language Agent Tree Search Unifies Reasoning Acting and Planning in Language Models
论文链接：https://arxiv.org/abs/2310.04406
论文主页：https://www.andyzhou.ai/LanguageAgentTreeSearch/
代码链接：https://github.com/andyz245/LanguageAgentTreeSearch
LangChain：
https://github.com/langchain-ai/langgraph/blob/main/examples/lats/lats.ipynb?ref=blog.langchain.dev
https://blog.langchain.dev/reflection-agents/

Tree search + ReAct + Plan&solve
通过树搜索的方式进行 Reward(强化学习的思路)，同时还会融入 Reflection，从而拿到最佳结果。

它有四个主要步骤：

1. 选择：根据步骤2中的总奖励选择最佳的下一步行动。响应（如果找到解决方案或达到最大搜索深度）或继续搜索。
2. 展开和模拟：选择“最佳”的5个潜在动作，并且并行执行。
3. 反思+评估：观察这些行动的结果，并根据反思（可能还有外部反馈）对决策进行评分
4. 反向传播：根据结果更新根轨迹的分数。

结论：

1. 虽然有效，可能需要额外的计算时间。如果你想在生产应用程序中包括这一点，你要么想确保中间步骤是流式的（这样用户就可以看到思考过程/获得中间结果），要么用它来微调数据，以提高准确性，避免长时间的推出。
2. 候选动作的选择过程只有和你获得的奖励一样好。在这里，只使用自反射，但如果您有外部反馈源（如代码测试执行），则应将其包含在上述位置。

Self-Discover

论文名称：Self-Discover: Large Language Models Self-Compose Reasoning Structures
论文链接：https://arxiv.org/abs/2402.03620
代码链接：https://github.com/catid/self-discover/tree/main?tab=readme-ov-file
LangChain：
https://github.com/langchain-ai/langgraph/blob/main/examples/self-discover/self-discover.ipynb

Self-discover 的核心是让大模型在更小粒度上 task 本身进行反思，比如前文中的 Plan&Slove 是反思 task 是不是需要补充，而 Self-discover 是对 task 本身进行反思。

• Selector: 从众多的反省方式中选择合适的反省方式；
• Adaptor: 使用选择的反省方式进行反省；
• Implementor: 反省后进行重新 Reasoning;

Storm

论文名称：Assisting in Writing Wikipedia-like Articles From Scratch with Large Language Models
论文链接：https://arxiv.org/abs/2402.14207
代码链接：https://github.com/stanford-oval/storm
LangChain：
https://github.com/langchain-ai/langgraph/blob/main/examples/storm/storm.ipynb

STORM旨在根据用户提供的主题生成维基百科风格的文章。它运用两个主要见解来撰写更有条理、更全面的文章：

1. 通过查询类似主题创建大纲（计划）有助于提高覆盖率。
2. 多视角、接地气（在搜索中）的对话模拟有助于增加参考人数和信息密度。

STORM 有几个主要阶段：

1. 生成初步大纲+调查相关主题
2. 识别不同的视角
3. “采访主题专家”（角色扮演LLM）
4. 细化大纲（使用参考文献）
5. 写章节，然后写文章

专家采访阶段发生在角色扮演文章作者和研究专家之间。“专家” 能够查询外部知识并回答有针对性的问题，将引用的来源保存到向量库中，以便后期的细化阶段能够综合整篇文章。

你可以设置几个超参数来限制（潜在的）无限研究广度：
N： 要调查/使用的视角数量（步骤2->3）
M：步骤中的最大对话次数（步骤3）

Agent 应用

AutoGPT

GitHub地址：https://github.com/Significant-Gravitas/AutoGPT
AutoGPT：https://www.maartengrootendorst.com/blog/autogpt/

其创新还是在 prompt 层面，通过更好的提示词来激发模型的能力，把更多原先需要通过代码来实现的流程“硬逻辑”转化为模型自动生成的“动态逻辑”。类似个人助理，帮助用户完成指定的任务，如调研某个课题。AutoGPT比较强调对外部工具的使用，如搜索引擎、页面浏览等。

BabyAGI

GitHub地址：https://github.com/yoheinakajima/babyagi

相比 AutoGPT 来说，BabyAGI 是一个相对更聚焦在“思维流程”方面尝试的项目，并没有添加对各种外部工具利用的支持。其核心逻辑非常简单：

从任务列表中获取排在第一位的任务。获取任务相关的“记忆”信息，由任务执行 agent 来执行这个任务，获取结果。目前这个执行就是一个简单的 LLM 调用，不涉及外部工具。将返回结果再存放到记忆存储中。基于当前的信息，如整体目标，最近一次执行结果，任务描述，还未执行的任务列表等，生成所需要的新任务。将新任务添加到任务列表中，再判断所有任务的优先级，重新排序。

Lagent

GitHub地址：https://github.com/InternLM/lagent

上海人工智能实验室研发了 Lagent 智能体框架，Lagent 的命名来源于 Language Agents （L-Agent）的缩写，主要目标是为了高效构建和拓展基于大语言模型的智能体。它有如下三个特点：支持丰富、高度可配置的智能体，Lagent 目前支持了常见的 3 种类型的智能体，包括了 ReAct、ReWoo 和 AutoGPT。灵活支持多种大语言模型，Lagent 支持了闭源模型的 API，例如 GPT-3.5 和 GPT-4。同时接入了 Huggingface Transformers，因此可以使用 Transformers 中的所有开源大语言模型，例如 InternLM，Llama 2 和 Baichuan-chat 等。支持丰富的工具类型，Lagent 可以支持丰富的工具类型，包括目前已经支持的搜索和 Code Interpreter。用户需要支持新的工具，只需要基于 BaseAction 实现传参调用的逻辑，同时对这个工具进行命名和说明即可。

AgentGPT

GitHub地址：https://github.com/reworkd/AgentGPT

一个浏览器端的自主AI代理人工具，可以组装、配置和部署自主AI代理人。AgentGPT的关键创新之处在于其新增的自动任务拆分与自问自答功能。适用于需要运行文本生成和任务管理的场景，例如任务分配、自动化流程等。使用方式：用户给agent任务，例如“查找苹果公司的最受欢迎的产品，并找出它的价格”，agent会自动拆分成许多小的子任务，然后利用llm去逐步处理，最后输出整个任务的结果。

总体来说,AgentGPT实现的自动任务拆分与自问自答功能通过以下流程,降低了复杂问题解决的难度:

1. 用户输入一个复杂任务或问题的描述;
2. AgentGPT自动将任务拆分为多个步骤与子任务;
3. 针对每个子任务,AgentGPT自动生成相关问题(提问);
4. AgentGPT自动生成每个问题的回答(自问自答);
5. 用户对提问与回答进行确认或修改;
6. AgentGPT基于最新输入生成下一轮提问,循环此流程
7. 最后输出整个任务的结果。

HuggingGPT

GitHub地址：https://github.com/microsoft/JARVIS
论文地址：https://arxiv.org/abs/2303.17580

HuggingGPT 的核心概念是将语言作为 LLMs 与其他人工智能模型之间的通用接口。这一创新策略使得 LLMs 可以调用外部模型，进而解决各种复杂的人工智能任务。HuggingGPT 的设计强调了任务规划、模型选择、任务执行和响应生成四个阶段，使得整个系统可以高效地协调不同模型，解决多模态信息和复杂数字智能任务。

• 任务规划：使用 ChatGPT 分析用户请求以了解其意图，并通过提示将其拆分为可能可解决的任务。
• 模型选择：为了解决计划中的任务，ChatGPT 根据模型描述从托管在 Hugging Face 上的专家模型中选择模型。
• 任务执行：调用和执行每个选择的模型，并将结果返回给 ChatGPT。
• 响应生成：最后，使用 ChatGPT 将所有模型的预测整合起来，并为用户生成答案。
  
  HuggingGPT 在第一步，任务规划中，设计了 6 个任务，pose-control, pose-to-image, image-class, object-det, image-to-text, text-to-speech，并安排了它们的依赖关系。第二步中，ChatGPT 根据模型描述从候选在 huggingface 上的专家模型中选择模型，它们可能是在线的，可能是下载的。第三步，代码去真正执行对应的 huggingface 上的专家模型。第四步，将所有模型的预测整合起来，并为用户生成最后的返回。可以看到，确实就是去找了姿态相关的模型，生成了一个同样姿态的小女孩读书的图像。

HuggingGPT 已经在 Hugging Face 上成功集成了数百个模型，覆盖了 24 个任务，例如文本分类、目标检测、语义分割、图像生成、问答、文本转语音和文本转视频。实验结果证明了 HuggingGPT 在处理多模态信息和复杂人工智能任务方面的强大能力，为实现先进人工智能开辟了新的道路。

HuggingGPT 也有一些短板。比如效率，效率的瓶颈在于大型语言模型的推理。对于每一轮用户请求，HuggingGPT 在任务规划、模型选择和响应生成阶段至少需要与大型语言模型进行一次交互。这些交互大大增加了响应延迟，导致用户体验下降。第二个限制是最大上下文长度。受限于 LLM 能接受的最大标记数量，HuggingGPT 也面临着最大上下文长度的限制。它使用了对话窗口，在任务规划阶段仅跟踪对话上下文以减轻这一限制。第三个是系统稳定性，包括两个方面。一个是大型语言模型推理过程中出现的反叛现象。大型语言模型在推理过程中偶尔无法遵循指示，输出格式可能不符合预期，导致程序工作流中的异常。第二个是 Hugging Face 推理的专家模型的不可控状态。Hugging Face 上的专家模型可能受到网络延迟或服务状态的影响，导致任务执行阶段出错。

MetaGPT

GitHub地址：https://github.com/geekan/MetaGPT/
论文地址：https://arxiv.org/abs/2308.00352

一种多代理框架，它通过将包含现实世界专业知识的 SOP 编码到 LLM 代理中来扩展复杂问题的解决能力，实验表明，与现有方法相比，它可以生成更一致、更全面的解决方案。MetaGPT 的设计分为两层，即基础组件层和协作层，每一层都负责支持系统功能。

基础组件层：这一层详细定义了单个代理运行和整个系统信息交流所需的核心构件，包括环境、记忆、角色、行动和工具，并开发了协同工作所需的基本能力。

环境：为代理提供协作工作空间和交流平台
记忆：便于代理存储和检索过去的信息和情境
角色：根据领域专长封装专业技能、行为和工作流程
行动：代理为完成子任务和产生输出而采取的步骤。
工具：可用于增强代理能力的实用程序和服务的集合。

MetaGPT 框架会为各种角色（如产品经理和建筑师）生成代理，这些代理通过特定角色设置进行初始化。MetaGPT 框架提供的角色配置允许各方为特定领域和目的创建高度专业化的 LLM 代理。

协作层：它建立在基础组件层之上，为协作解决复杂任务提供了两种机制–知识共享和封装工作流。知识共享和封装工作流是协作解决复杂任务的机制。知识共享：这一机制允许代理高效地交换信息，存储、检索和共享各种粒度的数据。它不仅能加强合作，还能减少冗余通信，提高整体运行效率。封装工作流程：这一机制利用标准作业程序将复杂的任务分解为更小、更易于管理的子任务。这些子任务被分配给适当的代理，并通过标准化输出对其性能进行监控。基础组件层和协作层的这种分离有利于实现模块化，同时确保代理的个人和集体能力。核心组件设计：MetaGPT 方法的结构方式是将高级任务分解为由不同角色代理（产品经理、架构师、项目经理、工程师、QA工程师）处理的详细组件。该结构将任务分解为 SOP，SOP 是由不同角色代理（产品经理、架构师、项目经理、工程师、QA工程师）处理的详细组件，便于特定角色的专业人员进行处理。

工具使用例子

toolformer
Gorilla
ToolLLM
Autogen
OpenAgents
XAgent

https://zhuanlan.zhihu.com/p/662460753
https://www.zhihu.com/question/639349924
https://lilianweng.github.io/posts/2023-06-23-agent/
https://m.163.com/dy/article/IU9P4PTP05566ZHB.html