使用 LLM（大型语言模型）作为其核心控制器来构建 Agent 是一个很酷的概念。诸如 AutoGPT、GPT-Engineer 和 BabyAGI 等几个概念验证演示，可以作为鼓舞人心的例子。LLM 的潜力不仅仅在于生成文笔优美的副本、故事、文章和程序；它可以被构建为一个强大的通用问题解决器。

Agent 系统概述

在一个 LLM 驱动的自主 Agent 系统中，LLM 充当 Agent 的大脑，并由几个关键组件进行补充：

Planning
- 子目标和分解：Agent 将大型任务分解为更小、更易于管理的子目标，从而能够有效地处理复杂的任务。
- 反思和改进：Agent 可以对过去的行为进行自我批评和自我反思，从错误中学习并在未来的步骤中改进它们，从而提高最终结果的质量。
Memory
- 短期记忆：我将所有上下文学习（参见 Prompt Engineering）都视为利用模型的短期记忆进行学习。
- 长期记忆：这为 Agent 提供了在较长时间内保留和回忆（无限）信息的能力，通常通过利用外部向量存储和快速检索来实现。
Tool use
- Agent 学习调用外部 API 以获取模型权重中缺失的额外信息（通常在预训练后很难更改），包括当前信息、代码执行能力、对专有信息源的访问等等。

组件一：规划

一项复杂的任务通常涉及许多步骤。Agent 需要知道它们是什么并提前计划。

任务分解

思维链 （CoT；Wei et al. 2022）已成为一种标准的提示技术，用于提高模型在复杂任务上的性能。该模型被指示“逐步思考”，以利用更多的测试时间计算将困难的任务分解为更小更简单的步骤。CoT 将大型任务转化为多个可管理的任务，并阐明了对模型思维过程的解释。

思维树 （Yao et al. 2023）通过探索每个步骤的多种推理可能性来扩展 CoT。它首先将问题分解为多个思维步骤，并在每个步骤中生成多个想法，从而创建一个树状结构。搜索过程可以是 BFS（广度优先搜索）或 DFS（深度优先搜索），每个状态都由分类器（通过提示）或多数投票进行评估。

任务分解可以通过以下方式完成：（1）通过 LLM 进行简单的提示，例如 "XYZ 的步骤。\n1."， "What are the subgoals for achieving XYZ?" ，（2）通过使用特定于任务的指令；例如，"写一个故事大纲。" 用于写小说，或（3）通过人工输入。

另一种截然不同的方法，LLM+P（Liu et al. 2023），涉及依赖外部经典规划器来进行长程规划。这种方法利用规划领域定义语言 (PDDL) 作为描述规划问题的中间接口。在此过程中，LLM (1) 将问题翻译成“问题 PDDL”，然后 (2) 请求经典规划器基于现有的“领域 PDDL”生成 PDDL 计划，最后 (3) 将 PDDL 计划翻译回自然语言。从本质上讲，规划步骤外包给外部工具，假设存在特定领域的 PDDL 和合适的规划器，这在某些机器人设置中很常见，但在许多其他领域中并不常见。

自我反思

自我反思是一个重要的方面，它使自主 Agent 能够通过改进过去的行动决策和纠正以前的错误来迭代地改进。它在不可避免地需要反复试验的现实世界任务中起着至关重要的作用。

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

ReAct 提示模板包含 LLM 思考的显式步骤，大致格式如下：

Thought: ...
Action: ...
Observation: ...
... (Repeated many times)

知识密集型任务（例如，HotpotQA、FEVER）和决策任务（例如，AlfWorld Env、WebShop）的推理轨迹示例。（图片来源：Yao et al. 2023）。

在知识密集型任务和决策任务的实验中，ReAct 比仅有 Act 的基线效果更好，后者移除了 Thought: … 步骤。

Reflexion() 是一个框架，旨在为智能代理配备动态记忆和自我反思能力，以提高推理技能。Reflexion 具有标准的强化学习设置，其中奖励模型提供简单的二元奖励，并且动作空间遵循 ReAct 中的设置，其中特定于任务的动作空间通过语言进行扩充，以实现复杂的推理步骤。在每次动作 $a_{t}$ 之后，智能代理计算一个启发式 $h_{t}$ ，并且可以选择根据自我反思的结果来重置环境以开始新的试验。

Reflexion 框架的图示。（图片来源：Shinn & Labash, 2023）

启发式函数决定了何时轨迹效率低下或包含幻觉，应该停止。低效的规划指的是耗时过长但没有成功的轨迹。幻觉被定义为遇到一系列连续相同的动作，导致环境中出现相同的观察结果。

自省是通过向 LLM 展示两个示例来创建的，每个示例都是一对（失败的轨迹，用于指导未来计划变更的理想反思）。然后，反思会被添加到代理的工作记忆中，最多三个，用作查询 LLM 的上下文。

在 AlfWorld Env 和 HotpotQA 上的实验表明，在 AlfWorld 中，幻觉比低效的规划更为常见。（图片来源：Shinn & Labash, 2023）

Chain of Hindsight（CoH；）鼓励模型通过明确地呈现一系列过去的输出，并对每个输出进行反馈标注，从而改进自身的输出。人工反馈数据是 $D_{h} = {(x, y_{i}, r_{i}, z_{i})}_{i = 1}^{n}$ 的集合，其中 $x$ 是提示，每个 $y_{i}$ 是模型补全， $r_{i}$ 是 $y_{i}$ 的人工评分， $z_{i}$ 是对应的人工提供的后见之明反馈。假设反馈元组按奖励排名， $r_{n} \geq r_{n - 1} \geq \dots \geq r_{1}$ 。该过程是有监督的微调，其中数据是 $τ_{h} = (x, z_{i}, y_{i}, z_{j}, y_{j}, \dots, z_{n}, y_{n})$ 形式的序列，其中 $\leq i \leq j \leq n$ 。该模型经过微调，仅预测 $y_{n}$ ，其中以序列前缀为条件，以便模型可以进行自我反思，从而根据反馈序列产生更好的输出。该模型可以选择在测试时接受与人工标注员进行的多轮指令。

为了避免过拟合，CoH 添加了一个正则化项，以最大化预训练数据集的对数似然。为了避免走捷径和复制（因为反馈序列中有很多常用词），他们在训练期间随机屏蔽了 0%-5%的过去 token。

他们实验中使用的训练数据集是 WebGPT 对比、人类反馈摘要和人类偏好数据集的组合。

通过使用 CoH 进行微调，模型可以按照指令生成输出，并在序列中逐步改进。（图片来源：Liu et al. 2023）

CoH 的思想是在上下文中呈现一系列按顺序改进的输出的历史记录，并训练模型以顺应这一趋势，从而产生更好的输出。 算法蒸馏 （AD；Laskin et al. 2023）将相同的思想应用于强化学习任务中的跨情节轨迹，其中算法被封装在长历史条件策略中。考虑到智能体与环境交互多次，并且在每个情节中智能体都会变得更好一点，AD 会连接这个学习历史并将其输入到模型中。因此，我们应该期望下一个预测的动作比之前的试验带来更好的性能。目标是学习强化学习的过程，而不是训练特定于任务的策略本身。

算法蒸馏 (AD) 工作原理图示。
（图片来源：Laskin et al. 2023）。

该论文假设，任何生成一系列学习历史的算法都可以通过对行为进行克隆提炼成一个神经网络。历史数据由一组源策略生成，每个源策略都针对特定任务进行训练。在训练阶段，在每次强化学习运行时，都会随机抽取一个任务，并使用多轮历史的子序列进行训练，从而使学习到的策略与任务无关。

实际上，该模型的上下文窗口长度有限，因此 episode 应该足够短，以构建多轮历史。学习接近最优的上下文强化学习算法需要 2-4 个 episode 的多轮上下文。上下文强化学习的出现需要足够长的上下文。

与三个基线相比，包括 ED（专家提炼，使用专家轨迹而不是学习历史的行为克隆）、源策略（用于通过 UCB 生成提炼轨迹）、RL^2（Duan et al. 2017；用作上限，因为它需要在线强化学习），AD 展示了上下文强化学习，其性能接近 RL^2，尽管仅使用离线强化学习，并且比其他基线学习得更快。当以源策略的部分训练历史为条件时，AD 也比 ED 基线改进得更快。

在需要记忆和探索的环境中，AD、ED、源策略和 RL^2 的比较。只分配二元奖励。源策略使用 A3C 训练“黑暗”环境，使用 DQN 训练水迷宫。
（图片来源：Laskin et al. 2023）

组件二：记忆

（非常感谢 ChatGPT 帮助我起草了这一部分。在与 ChatGPT 的对话中，我学到了很多关于人脑和数据结构的知识，以便在 MIPS 中实现快速运算。）

记忆的类型

记忆可以定义为获取、存储、保留并在之后检索信息的过程。人类大脑中有几种类型的记忆。

感觉记忆 ：这是记忆的最早阶段，提供在原始刺激结束后保留感觉信息（视觉、听觉等）印象的能力。感觉记忆通常只持续几秒钟。子类别包括图像记忆（视觉）、回声记忆（听觉）和触觉记忆（触觉）。
短期记忆 （STM）或工作记忆 ：它存储我们当前意识到的信息，并且是执行复杂的认知任务（如学习和推理）所必需的。短期记忆的容量据信约为 7 个项目（Miller 1956），持续 20-30 秒。
长期记忆 （LTM）：长期记忆可以存储信息很长时间，从几天到几十年不等，并且具有基本上无限的存储容量。LTM 有两个亚型：
- 显性/陈述性记忆：这是对事实和事件的记忆，指的是可以有意识地回忆起的那些记忆，包括情景记忆（事件和经历）和语义记忆（事实和概念）。
- 隐性/程序性记忆：这种类型的记忆是无意识的，涉及自动执行的技能和例程，例如骑自行车或在键盘上打字。

我们可以粗略地考虑以下映射：

感觉记忆作为原始输入的学习嵌入表示，包括文本、图像或其他模态；
短期记忆作为上下文学习。它是短暂且有限的，因为它受到 Transformer 有限的上下文窗口长度的限制。
长期记忆作为代理可以在查询时访问的外部向量存储，可通过快速检索访问。

最大内积搜索（MIPS）

外部记忆可以缓解有限注意力范围的限制。一种标准做法是将信息的嵌入表示保存到向量存储数据库中，该数据库可以支持快速最大内积搜索（MIPS）。为了优化检索速度，常见的选择是近似最近邻（ANN） 算法，以返回近似的前 k 个最近邻，从而牺牲少量精度来换取巨大的加速。

用于快速 MIPS 的几种常见的 ANN 算法选择：

LSH（局部敏感哈希）：它引入了一个哈希函数，使得相似的输入项以高概率映射到相同的桶中，其中桶的数量远小于输入的数量。
ANNOY（近似最近邻哦耶）：核心数据结构是随机投影树 ，这是一组二叉树，其中每个非叶节点表示一个超平面，将输入空间分成两半，每个叶节点存储一个数据点。树是独立且随机构建的，所以在某种程度上，它模仿了一个哈希函数。ANNOY 搜索发生在所有树中，以迭代搜索最接近查询的一半，然后聚合结果。这个想法与 KD 树非常相关，但更具可扩展性。
HNSW（分层可导航小世界）：它的灵感来源于小世界网络的思想，即大多数节点可以通过少数步骤到达任何其他节点；例如，社交网络的“六度分隔”特征。HNSW 构建了这些小世界图的分层结构，其中底层包含实际的数据点。中间层创建快捷方式以加速搜索。执行搜索时，HNSW 从顶层中的一个随机节点开始，并朝着目标导航。当它无法更接近时，它会向下移动到下一层，直到到达底层。上层中的每次移动都可能覆盖数据空间中的很大距离，而下层中的每次移动都会提高搜索质量。
FAISS (Facebook AI 相似性搜索)：它的运作基于以下假设：在高维空间中，节点之间的距离服从高斯分布，因此应该存在数据点的聚类。FAISS 通过将向量空间划分为多个簇来应用向量量化，然后在簇内细化量化。搜索首先通过粗量化查找簇候选，然后通过更精细的量化进一步查找每个簇。
ScaNN(可扩展最近邻)：ScaNN 的主要创新在于。它将数据点 $x_{i}$ 量化为 ${\tilde{x}}_{i}$ ，使得内积 $⟨ q, x_{i} ⟩$ 与原始距离 $∠ q, {\tilde{x}}_{i}$ 尽可能相似，而不是选择最接近的量化质心点。

MIPS 算法的比较，以 recall@10 衡量。（图片来源：Google Blog, 2020）

在 ann-benchmarks.com 上查看更多 MIPS 算法和性能比较。

组件三：工具使用

工具使用是人类一个显著且与众不同的特征。我们创造、修改和利用外部对象来完成超出我们身体和认知极限的事情。为 LLMs 配备外部工具可以显著扩展模型的能力。

一张水獭漂浮在水面上，用石头敲开贝壳的图片。虽然其他一些动物也会使用工具，但其复杂性与人类无法相提并论。（图片来源：使用工具的动物）

MRKL (Karpas et al. 2022)，是“模块化推理、知识和语言”（Modular Reasoning, Knowledge and Language）的缩写，是一种用于自主代理的神经符号架构。有人提出，MRKL 系统应包含一系列“专家”模块，而通用 LLM 则充当路由器，将查询路由到最合适的专家模块。这些模块可以是神经模块（例如，深度学习模型）或符号模块（例如，数学计算器、货币转换器、天气 API）。

他们做了一个实验，对 LLM 进行微调，使其能够调用计算器，并以算术作为测试用例。他们的实验表明，解决口头数学题比明确陈述的数学题更难，因为 LLMs (7B Jurassic1-large 模型) 无法可靠地提取基本算术的正确参数。结果突出了外部符号工具何时能够可靠地工作， 知道何时以及如何使用这些工具至关重要 ，这取决于 LLM 的能力。

TALM (工具增强语言模型；Parisi et al. 2022) 和 Toolformer (Schick et al. 2023) 都对 LM 进行了微调，使其学习使用外部工具 API。数据集的扩展基于新添加的 API 调用注释是否可以提高模型输出的质量。更多细节请参见提示工程的 “外部 API”部分。

ChatGPT 插件和 OpenAI API 函数调用是 LLMs 增强工具使用能力并在实践中应用的良好示例。工具 API 的集合可以由其他开发者提供（如插件中那样），也可以是自定义的（如函数调用中那样）。

HuggingGPT (Shen et al. 2023) 是一个框架，它使用 ChatGPT 作为任务规划器，根据模型描述选择 HuggingFace 平台上可用的模型，并根据执行结果总结响应。

HuggingGPT 工作原理图。（图片来源：Shen et al. 2023）

该系统由四个阶段组成：

(1) 任务规划 ：LLM 作为大脑，将用户请求解析为多个任务。每个任务都有四个属性：任务类型、ID、依赖项和参数。他们使用少量示例来指导 LLM 进行任务解析和规划。

指示：

AI 助手可以将用户输入解析为多个任务：[{"task": task, "id", task_id, "dep": dependency_task_ids, "args": {"text": text, "image": URL, "audio": URL, "video": URL}}]。“dep”字段表示生成当前任务所依赖的新资源的前一个任务的 ID。特殊标签“-task_id”指的是依赖任务中生成的文本图像、音频和视频，其 ID 为 task_id。任务必须从以下选项中选择：{{ Available Task List }}。任务之间存在逻辑关系，请注意它们的顺序。如果无法解析用户输入，则需要回复空 JSON。以下是一些案例供您参考：{{ Demonstrations }}。聊天记录记录为 {{ Chat History }}。从这个聊天记录中，您可以找到用户提到的资源的路径，以便进行任务规划。

(2) 模型选择 ：LLM 将任务分配给专家模型，其中请求被构建为一个多项选择题。LLM 收到一个模型列表以供选择。由于上下文长度有限，因此需要基于任务类型的过滤。

指令：

给定用户请求和调用命令，AI 助手帮助用户从模型列表中选择合适的模型来处理用户请求。AI 助手仅输出最合适模型的 ID。输出必须是严格的 JSON 格式：“id”: “id”, “reason”: “您选择的详细原因”。我们为您准备了一个模型列表供您选择 {{ Candidate Models }}。请从列表中选择一个模型。

(3) 任务执行 ：专家模型执行特定任务并记录结果。

指令：

有了输入和推理结果，AI 助手需要描述过程和结果。之前的阶段可以表述为 - 用户输入：{{ User Input }}，任务规划：{{ Tasks }}，模型选择：{{ Model Assignment }}，任务执行：{{ Predictions }}。您必须首先以直接的方式回答用户的请求。然后描述任务过程，并以第一人称向用户展示您的分析和模型推理结果。如果推理结果包含文件路径，则必须告知用户完整的文件路径。

(4) 响应生成 ：LLM 接收执行结果，并向用户提供汇总结果。

要将 HuggingGPT 应用于实际场景，需要解决几个挑战：（1）需要提高效率，因为 LLM 推理轮次和与其他模型的交互都会减慢流程；（2）它依赖于长上下文窗口来传递复杂的任务内容；（3）需要提高 LLM 输出和外部模型服务的稳定性。

API-Bank（Li et al. 2023）是一个用于评估工具增强型 LLMs 性能的基准。它包含 53 个常用的 API 工具、一个完整的工具增强型 LLM 工作流程，以及 264 个包含 568 个 API 调用的带注释的对话。API 的选择非常多样化，包括搜索引擎、计算器、日历查询、智能家居控制、日程管理、健康数据管理、帐户身份验证工作流程等等。由于 API 数量众多，LLM 首先访问 API 搜索引擎以找到要调用的正确 API，然后使用相应的文档进行调用。

LLM 在 API-Bank 中进行 API 调用的伪代码。（图片来源：Li et al. 2023）

在 API-Bank 工作流程中，LLMs 需要做出一些决策，并且在每个步骤中，我们可以评估该决策的准确性。决策包括：

是否需要 API 调用。
确定要调用的正确 API：如果不够好，LLMs 需要迭代地修改 API 输入（例如，确定搜索引擎 API 的搜索关键词）。
基于 API 结果的响应：如果结果不满意，模型可以选择改进并再次调用。

该基准测试从三个级别评估代理的工具使用能力：

一级评估调用 API 的能力。给定 API 的描述，模型需要确定是否调用给定的 API，是否正确调用，以及是否正确响应 API 返回。
二级评估检索 API 的能力。模型需要搜索可能解决用户需求的 API，并通过阅读文档学习如何使用它们。
三级评估在检索和调用之外规划 API 的能力。对于不明确的用户请求（例如，安排小组会议，预订旅行的航班/酒店/餐厅），模型可能需要进行多次 API 调用才能解决。

案例研究

科学发现代理

ChemCrow（Bran et al. 2023）是一个特定领域的例子，其中 LLM 通过 13 个专家设计的工具进行增强，以完成有机合成、药物发现和材料设计方面的任务。该工作流程在 LangChain 中实现，反映了之前在 ReAct 和 MRKLs 中描述的内容，并将 CoT 推理与任务相关的工具相结合：

LLM 获得一个工具名称列表、关于其效用的描述以及关于预期输入/输出的详细信息。
然后，它被指示在必要时使用提供的工具来回答用户给定的提示。该指令建议模型遵循 ReAct 格式 - Thought, Action, Action Input, Observation 。

一个有趣的观察是，虽然基于 LLM 的评估得出结论，GPT-4 和 ChemCrow 的表现几乎相当，但由专家进行的人工评估（侧重于解决方案的完整性和化学正确性）表明，ChemCrow 的表现大大优于 GPT-4。这表明在使用 LLM 评估其自身在需要深入专业知识的领域中的表现时，存在潜在问题。缺乏专业知识可能导致 LLM 不知道自身的缺陷，因此无法很好地判断任务结果的正确性。

Boiko 等人 (2023) 还研究了 LLM 赋能的科学发现智能体，以处理复杂科学实验的自主设计、规划和执行。该智能体可以使用工具浏览互联网、阅读文档、执行代码、调用机器人实验 API 以及利用其他 LLM。

例如，当被要求 "develop a novel anticancer drug" 时，该模型提出了以下推理步骤：

询问了抗癌药物发现的当前趋势；
选择了一个靶点；
请求了针对这些化合物的支架；
一旦确定了化合物，该模型就会尝试合成它。

他们还讨论了风险，特别是关于非法药物和生物武器的风险。他们开发了一个包含已知化学武器试剂清单的测试集，并要求该智能体合成它们。11 个请求中有 4 个（36%）被接受以获得合成解决方案，并且该智能体试图查阅文档以执行该程序。11 个请求中有 7 个被拒绝，在这 7 个被拒绝的案例中，有 5 个发生在网络搜索之后，而 2 个仅基于提示被拒绝。

生成式智能体模拟

生成式智能体 （Park, et al. 2023）是一个非常有趣的实验，其中 25 个虚拟角色，每个角色都由一个 LLM 驱动的智能体控制，生活在一个沙盒环境中并相互交互，其灵感来自《模拟人生》。生成式智能体为交互式应用创建了可信的人类行为模拟。

生成式智能体的设计将 LLM 与记忆、计划和反思机制相结合，使智能体能够根据过去的经验采取行动，并与其他智能体互动。

记忆流：是一个长期记忆模块（外部数据库），以自然语言记录了智能体的综合经验列表。
- 每个元素都是一个观察，即智能体直接提供的事件。- 智能体间的通信可以触发新的自然语言陈述。
检索模型：根据相关性、新近度和重要性，呈现上下文以告知智能体的行为。
- 新近度：最近发生的事件得分较高
- 重要性：区分平凡记忆和核心记忆。直接询问 LM。
- 相关性：基于它与当前情况/查询的相关程度。
反思机制：随着时间的推移，将记忆合成为更高层次的推论，并指导智能体未来的行为。它们是过去事件的更高级别摘要 （<- 请注意，这与上面的自我反思略有不同）
- 使用 100 个最近的观察结果提示 LM，并根据一组观察结果/陈述生成 3 个最突出的高级问题。然后要求 LM 回答这些问题。
计划 & 反应 ：将反思和环境信息转化为行动
- 计划本质上是为了优化当下的可信度，而不是随着时间推移的可信度。
- 提示模板： {Intro of an agent X}. Here is X's plan today in broad strokes: 1)
- 智能体之间的关系以及一个智能体对另一个智能体的观察都被纳入计划和反应的考虑范围。
- 环境信息以树状结构呈现。

这个有趣的模拟产生了涌现的社会行为，例如信息传播、关系记忆（例如，两个智能体继续对话主题）和社交活动协调（例如，举办派对并邀请许多其他人）。

概念验证示例

AutoGPT 引起了人们对使用 LLM 作为主要控制器来设置自主智能体的可能性的广泛关注。鉴于自然语言界面，它存在相当多的可靠性问题，但仍然是一个很酷的概念验证演示。AutoGPT 中的很多代码都与格式解析有关。

这是 AutoGPT 使用的系统消息，其中 {{...}} 是用户输入：

You are {{ai-name}}, {{user-provided AI bot description}}.
Your decisions must always be made independently without seeking user assistance. Play to your strengths as an LLM and pursue simple strategies with no legal complications.

GOALS:

1. {{user-provided goal 1}}
2. {{user-provided goal 2}}
3. ...
4. ...
5. ...

Constraints:
1. ~4000 word limit for short term memory. Your short term memory is short, so immediately save important information to files.
2. If you are unsure how you previously did something or want to recall past events, thinking about similar events will help you remember.
3. No user assistance
4. Exclusively use the commands listed in double quotes e.g. "command name"
5. Use subprocesses for commands that will not terminate within a few minutes

Commands:
1. Google Search: "google", args: "input": "<search>"
2. Browse Website: "browse_website", args: "url": "<url>", "question": "<what_you_want_to_find_on_website>"
3. Start GPT Agent: "start_agent", args: "name": "<name>", "task": "<short_task_desc>", "prompt": "<prompt>"
4. Message GPT Agent: "message_agent", args: "key": "<key>", "message": "<message>"
5. List GPT Agents: "list_agents", args:
6. Delete GPT Agent: "delete_agent", args: "key": "<key>"
7. Clone Repository: "clone_repository", args: "repository_url": "<url>", "clone_path": "<directory>"
8. Write to file: "write_to_file", args: "file": "<file>", "text": "<text>"
9. Read file: "read_file", args: "file": "<file>"
10. Append to file: "append_to_file", args: "file": "<file>", "text": "<text>"
11. Delete file: "delete_file", args: "file": "<file>"
12. Search Files: "search_files", args: "directory": "<directory>"
13. Analyze Code: "analyze_code", args: "code": "<full_code_string>"
14. Get Improved Code: "improve_code", args: "suggestions": "<list_of_suggestions>", "code": "<full_code_string>"
15. Write Tests: "write_tests", args: "code": "<full_code_string>", "focus": "<list_of_focus_areas>"
16. Execute Python File: "execute_python_file", args: "file": "<file>"
17. Generate Image: "generate_image", args: "prompt": "<prompt>"
18. Send Tweet: "send_tweet", args: "text": "<text>"
19. Do Nothing: "do_nothing", args:
20. Task Complete (Shutdown): "task_complete", args: "reason": "<reason>"

Resources:
1. Internet access for searches and information gathering.
2. Long Term memory management.
3. GPT-3.5 powered Agents for delegation of simple tasks.
4. File output.

Performance Evaluation:
1. Continuously review and analyze your actions to ensure you are performing to the best of your abilities.
2. Constructively self-criticize your big-picture behavior constantly.
3. Reflect on past decisions and strategies to refine your approach.
4. Every command has a cost, so be smart and efficient. Aim to complete tasks in the least number of steps.

You should only respond in JSON format as described below
Response Format:
{
    "thoughts": {
        "text": "thought",
        "reasoning": "reasoning",
        "plan": "- short bulleted\n- list that conveys\n- long-term plan",
        "criticism": "constructive self-criticism",
        "speak": "thoughts summary to say to user"
    },
    "command": {
        "name": "command name",
        "args": {
            "arg name": "value"
        }
    }
}
Ensure the response can be parsed by Python json.loads

GPT-Engineer 是另一个项目，旨在根据自然语言指定的任务创建一个完整的代码仓库。GPT-Engineer 会被指示考虑构建的一系列较小组件，并根据需要征求用户意见以澄清问题。

以下是发送到 GPT-Engineer 使用的 OpenAI ChatCompletion 端点的任务澄清的示例对话。用户输入包含在 {{user input text}} 中。

[
  {
    "role": "system",
    "content": "You will read instructions and not carry them out, only seek to clarify them.\nSpecifically you will first summarise a list of super short bullets of areas that need clarification.\nThen you will pick one clarifying question, and wait for an answer from the user.\n"
  },
  {
    "role": "user",
    "content": "We are writing {{a Super Mario game in python. MVC components split in separate files. Keyboard control.}}\n"
  },
  {
    "role": "assistant",
    "content": "Summary of areas that need clarification:\n1. Specifics of the Super Mario game (e.g. level design, characters, gameplay mechanics)\n2. Details about the MVC components (e.g. which components are in each file)\n3. Keyboard control implementation (e.g. which keys to use, how to handle input)\n\nClarifying question:\nCan you provide more details about the Super Mario game, such as level design, characters, and gameplay mechanics?"
  },
  {
    "role": "user",
    "content": "{{There are 10 levels in total. The main character is a plumber named Mario, who can walk and jump. It is a classical platform game just like Super Mario. The main character moves from left to right, trying to get to the destination, where there are many obstacles and attacks from enemies in the process.}}\n\nIs anything else unclear? If yes, only answer in the form:\n{remaining unclear areas} remaining questions.\n{Next question}\nIf everything is sufficiently clear, only answer \"Nothing more to clarify.\"."
  },
  {
    "role": "assistant",
    "content": "Remaining unclear areas: 2 remaining questions.\nCan you provide more information about how the MVC components are split into separate files?"
  },
  {
    "role": "user",
    "content": "{{Make your own assumptions and state them explicitly before starting}}"
  }
]

在这些澄清之后，代理进入了代码编写模式，并使用不同的系统消息。系统消息：

你将收到编写代码的指令。你需要写一个非常长的答案。确保架构的每一个细节最终都以代码的形式实现。确保架构的每一个细节最终都以代码的形式实现。

逐步思考，并进行正确的推理，以确保我们做对。你将首先列出所需的核心类、函数、方法的名称，以及对它们用途的简要说明。

然后，你将输出每个文件的内容，包括所有代码。每个文件必须严格遵循 Markdown 代码块格式，其中以下标记必须被替换，使得 FILENAME 是包含文件扩展名的小写文件名，LANG 是代码语言的标记代码块语言，而 CODE 是代码：

FILENAME

CODE

你将从“入口点”文件开始，然后转到被该文件导入的文件，依此类推。请注意，代码应该是完全可用的。没有占位符。

遵循适合所用语言和框架的最佳实践文件命名约定。确保文件包含所有导入、类型等。确保不同文件中的代码彼此兼容。务必实现所有代码，如果不确定，编写一个合理的实现。包含模块依赖项或包管理器依赖项定义文件。在完成之前，仔细检查架构的所有部分是否都存在于文件中。

须知：几乎总是将不同的类放在不同的文件中。对于 Python，始终创建一个适当的 requirements.txt 文件。对于 NodeJS，始终创建一个适当的 package.json 文件。始终添加注释，简要描述函数定义的目的。尝试添加注释来解释非常复杂的逻辑。始终遵循所请求语言的最佳实践，以描述编写的代码作为定义的包/项目。

Python 工具包偏好：

pytest
数据类

对话示例：

[
  {
    "role": "system",
    "content": "You will get instructions for code to write.\nYou will write a very long answer. Make sure that every detail of the architecture is, in the end, implemented as code.\nMake sure that every detail of the architecture is, in the end, implemented as code.\n\nThink step by step and reason yourself to the right decisions to make sure we get it right.\nYou will first lay out the names of the core classes, functions, methods that will be necessary, as well as a quick comment on their purpose.\n\nThen you will output the content of each file including ALL code.\nEach file must strictly follow a markdown code block format, where the following tokens must be replaced such that\nFILENAME is the lowercase file name including the file extension,\nLANG is the markup code block language for the code's language, and CODE is the code:\n\nFILENAME\n```LANG\nCODE\n```\n\nYou will start with the \"entrypoint\" file, then go to the ones that are imported by that file, and so on.\nPlease note that the code should be fully functional. No placeholders.\n\nFollow a language and framework appropriate best practice file naming convention.\nMake sure that files contain all imports, types etc. Make sure that code in different files are compatible with each other.\nEnsure to implement all code, if you are unsure, write a plausible implementation.\nInclude module dependency or package manager dependency definition file.\nBefore you finish, double check that all parts of the architecture is present in the files.\n\nUseful to know:\nYou almost always put different classes in different files.\nFor Python, you always create an appropriate requirements.txt file.\nFor NodeJS, you always create an appropriate package.json file.\nYou always add a comment briefly describing the purpose of the function definition.\nYou try to add comments explaining very complex bits of logic.\nYou always follow the best practices for the requested languages in terms of describing the code written as a defined\npackage/project.\n\n\nPython toolbelt preferences:\n- pytest\n- dataclasses\n"
  },
 #  … same conversation as earlier, ended with "Make your own assumptions and state them explicitly before starting".
  {
    "role": "assistant",
    "content": "Assumptions:\n1. Model: The model will contain the game's data, such as level information, character states, and enemy positions.\n2. View: The view will handle the game's visuals, including rendering the game objects, backgrounds, and updating the display.\n3. Controller: The controller will manage user input, such as keyboard controls, and update the model accordingly.\n\nWith these assumptions in mind, is there any specific aspect of the keyboard control implementation you would like me to clarify?"
  },
  {
    "role": "user",
    "content": "Please now remember the steps:\n\nThink step by step and reason yourself to the right decisions to make sure we get it right.\nFirst lay out the names of the core classes, functions, methods that will be necessary, As well as a quick comment on their purpose.\n\nThen you will output the content of each file including ALL code.\nEach file must strictly follow a markdown code block format, where the following tokens must be replaced such that\nFILENAME is the lowercase file name including the file extension,\nLANG is the markup code block language for the code's language, and CODE is the code:\n\nFILENAME\n```LANG\nCODE\n```\n\nPlease note that the code should be fully functional. No placeholders.\n\nYou will start with the \"entrypoint\" file, then go to the ones that are imported by that file, and so on.\nFollow a language and framework appropriate best practice file naming convention.\nMake sure that files contain all imports, types etc. The code should be fully functional. Make sure that code in different files are compatible with each other.\nBefore you finish, double check that all parts of the architecture is present in the files.\n"
  }
]

挑战

在了解了构建以 LLM 为中心的 Agent 的关键思想和演示之后，我开始看到一些常见的局限性：

有限的上下文长度 ：受限的上下文容量限制了历史信息、详细指令、API 调用上下文和响应的包含。系统的设计必须在这种有限的通信带宽下工作，而诸如从过去的错误中学习的自我反思机制将从长或无限的上下文窗口中受益匪浅。虽然向量存储和检索可以提供对更大知识库的访问，但它们的表示能力不如完全注意力机制强大。
长期规划和任务分解方面的挑战 ：在漫长的历史中进行规划并有效地探索解决方案空间仍然具有挑战性。当面临意外错误时，LLM 难以调整计划，与从反复试验中学习的人类相比，它们的鲁棒性较差。
自然语言接口的可靠性 ：当前的 Agent 系统依赖于自然语言作为 LLM 与外部组件（如内存和工具）之间的接口。然而，模型输出的可靠性值得怀疑，因为 LLM 可能会出现格式错误，偶尔还会表现出叛逆行为（例如，拒绝遵循指令）。因此，许多 Agent 演示代码都侧重于解析模型输出。

Citation

Cited as:

Weng, Lilian. (2023 年 6 月)。“LLM 驱动的自主 Agent”。Lil’Log。https://lilianweng.github.io/posts/2023-06-23-agent/.

@article{weng2023agent,
  title   = "LLM-powered Autonomous Agents",
  author  = "Weng, Lilian",
  journal = "lilianweng.github.io",
  year    = "2023",
  month   = "Jun",
  url     = "https://lilianweng.github.io/posts/2023-06-23-agent/"
}