阅读翻译-《LLM Powered Autonomous Agents》

文章介绍

题目：LLM Powered Autonomous Agents
网址：https://lilianweng.github.io/posts/2023-06-23-agent/
发布时间：2023年6月
说明：虽然发布在博客上，LLM Agent领域的开山之作

前言

以LLM为核心控制器构建代理是一个很酷的概念，潜力巨大，不仅可以生成副本，故事，论文和程序，可以被描述为一个强大的通用问题解决者。AutoGPT，GPT-Engineer和BabyAGI都是类似的案例。

Agent的系统概述

在LLM驱动的自主代理系统中，LLM充当着Agent的大脑，并辅助以几个关键的组件
（1），规划Planning
子目标和分解：Agent将大型任务分解为更小的，可管理的子目标，从而能够高效处理复杂的任务。
反思和完善：智能体可以对过去的行为进行自我批评和自我反省，从错误中吸取教训，并为未来的步骤进行改进，从而提高最终结果的质量
（2），记忆Memory
短期记忆：认为所有上下文学*（参见提示工程）都是利用模型的短期记忆来学*。
长期记忆：这为代理提供了长时间保留和回忆（无限）信息的能力，通常通过利用外部向量存储和快速检索。
（3），工具使用Tool Use
Agent学*调用外部 API 以获取模型权重中缺少的额外信息（通常在预训练后难以更改），包括当前信息、代码执行能力、对专有信息源的访问等。

第一部分：规划

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

任务分解

思维链（CoT）已成为增强复杂任务模型性能的标准提示技术。该模型被指示“一步一步思考”，以利用更多的测试时间计算将困难的任务分解为更小、更简单的步骤。CoT 方法将大任务转化为多个可管理的任务，并揭示模型思维过程的解释。

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

任务分解可以 （1） 通过 LLM 通过简单的提示（如 "Steps for XYZ.\n1." 、 "What are the subgoals for achieving XYZ?" ） 通过使用特定于任务的指令来完成;例如， "Write a story outline." 用于写小说，或 （3） 使用人工输入。

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

自我反省（Self-Reflection）

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

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

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

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

在知识密集型任务和决策任务的实验中，ReAct 都是比删除步骤的Act，Thought，-only基线效果更好。

Reflexion是一个框架，旨在为代理提供动态记忆和自我反思能力，以提高推理能力。Reflexion 有一个标准的 RL 设置，其中奖励模型提供简单的二元奖励，动作空间遵循 ReAct 中的设置，其中特定于任务的动作空间通过语言进行增强，以实现复杂的推理步骤。在每个动作 at 之后，代理都会计算一个启发式方法 $h_t$ ，并且可以选择根据自我反思结果决定重置环境以开始新的试验。

启发式函数确定轨迹何时效率低下或包含幻觉并应停止。低效规划是指轨迹花费太长时间而没有成功。幻觉被定义为遇到一系列连续的相同动作，导致环境中的相同观察结果。

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

事后认识链（CoH）通过显式呈现一系列过去的输出来鼓励模型改进自己的输出，每个输出都带有反馈注释。人类反馈数据是 $D_h={{(x,y_i,r_i,z_i)}}{i=1}^n$ 的集合，其中x是提示，每个$y_i$是模型完成，$r_i$是人类的$y_i$评分，$z_i$ 并且是相应的人类提供的事后反馈。假设反馈元组按奖励排名， $r_n$≥$r$≥⋯≥$r_1$ 该过程是监督微调，其中数据是 $τ_h$=$(x,z_i,y_i,z_j,y_j,…,z_n,y_n)$形式的序列，其中$≤i≤j≤n$。该模型经过微调，仅预测$y_n$以序列前缀为条件的位置，以便模型可以自我反映，以根据反馈序列产生更好的输出。该模型可以选择在测试时接收带有人工注释器的多轮指令。

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

他们实验中的训练数据集是 WebGPT 比较、人类反馈总结和人类偏好数据集的组合。

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

该论文假设，任何生成一组学*历史的算法都可以通过对动作执行行为克隆来提炼成神经网络。历史数据由一组源策略生成，每个策略都针对特定任务进行训练。在训练阶段，在每次 RL 运行期间，都会对随机任务进行采样，并使用多集历史的子序列进行训练，因此学*到的策略与任务无关。
实际上，该模型的上下文窗口长度有限，因此剧集应该足够短以构建多剧集历史。学**乎最佳的上下文内 RL 算法需要2-4集的多情节上下文。上下文内RL的出现需要足够长的上下文。
与三个基线相比，包括 ED（专家蒸馏，使用专家轨迹而不是学*历史记录的行为克隆）、源策略（用于生成 UCB 蒸馏的轨迹）、RL^2（用作上限，因为它需要在线 RL），AD 展示了上下文中的 RL，尽管仅使用离线 RL，但性能接* RL^2，并且学*速度比其他基线快得多。当以源策略的部分训练历史为条件时，AD 的改进速度也比 ED 基线快得多。

第二部分：记忆 Memory

在与 ChatGPT 的对话中，我学到了很多关于快速 MIPS 的人脑和数据结构的知识。

记忆类型

记忆可以定义为用于获取、存储、保留和稍后检索信息的过程。人脑中有几种类型的记忆。
（1），感觉记忆：这是记忆的最早阶段，提供在原始刺激结束后保留感觉信息（视觉、听觉等）印象的能力。感觉记忆通常最多只能持续几秒钟。子类别包括标志性记忆（视觉）、回声记忆（听觉）和触觉记忆（触摸）
（2），短期记忆（STM） 或工作记忆：它存储我们当前意识到并需要执行复杂认知任务（例如学*和推理）的信息。短期记忆被认为具有大约 7 个项目的容量（Miller 1956），持续20-30秒。
（3），长期记忆（LTM）：长期记忆可以存储信息非常长的时间，从几天到几十年不等，存储容量基本上是无限的。LTM 有两种子类型：

• 外显/陈述性记忆：这是对事实和事件的记忆，是指那些可以有意识地回忆的记忆，包括情景记忆（事件和经历）和语义记忆（事实和概念）。
• 内隐/程序记忆：这种类型的记忆是无意识的，涉及自动执行的技能和例行公事，例如骑自行车或在键盘上打字。

我们可以大致考虑以下映射：

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

最大内积搜索 （MIPS）

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

用于快速 MIPS 的 ANN 算法的几种常见选择：
（1）LSH（Locality-Sensitive Hashing）：它引入了哈希函数，使相似的输入项被高概率映射到相同的存储桶，其中存储桶的数量远小于输入的数量。

（2）ANNOY（*似最*邻）：核心数据结构是随机投影树，一组二叉树，其中每个非叶节点代表一个超平面，将输入空间分成两半，每个叶子存储一个数据点。树是独立且随机构建的，因此在某种程度上，它模仿了哈希函数。ANNOY搜索发生在所有树中，迭代搜索最接*查询的一半，然后聚合结果。这个想法与KD树非常相关，但更具可扩展性。

（3）HNSW（分层可导航小世界，Hierarchical Navigable Small World）：它的灵感来自小世界网络的思想，其中大多数节点都可以在少量步骤内被任何其他节点到达;例如社交网络的“六度分离”特征。HNSW 构建了这些小世界图的分层，其中底层包含实际数据点。中间的层创建快捷方式以加快搜索速度。执行搜索时，HNSW 从顶层的随机节点开始，导航到目标。当它无法再靠*时，它会向下移动到下一层，直到到达底层。上层的每一次移动都可能覆盖数据空间中的很远的距离，而下层的每一次移动都会提高搜索质量。

（4）FAISS（Facebook AI 相似性搜索）：它的运行假设是在高维空间中，节点之间的距离遵循高斯分布，因此应该存在数据点的聚类。FAISS 通过将向量空间划分为聚类，然后细化聚类内的量化来应用向量量化。搜索首先使用粗量化寻找候选聚类，然后进一步使用更精细的量化来研究每个聚类。

（5）ScaNN（可缩放最*邻）：ScaNN 的主要创新是各向异性矢量量化。它量化数据点$x_i$  $x_i~$ ，使内积$⟨q,xi⟩$尽可能与原始$∠q$，$x_i~$ 距离相似，而不是选择量化后最靠*的质心点。

查看更多 MIPS 算法和性能对比 https://ann-benchmarks.com。

第三部分：工具使用

工具的使用是人类的一个显着特征。我们创造、修改和利用外部对象来做超出我们身体和认知极限的事情。为LLM配备外部工具可以显着扩展模型功能。

MRKL是“Modular Reasoning， Knowledge and Language”的缩写，是一种用于自主代理的神经符号架构。MRKL 系统被提议包含一系列“专家”模块，通用 LLM 充当路由器，将查询路由到最合适的专家模块。这些模块可以是神经模块（例如深度学*模型）或符号模块（例如数学计算器、货币转换器、天气 API）。
他们做了一个实验，以微调LLM以调用计算器，使用算术作为测试用例。他们的实验表明，解决口头数学问题比明确说明的数学问题更难，因为 LLM（7B Jurassic1-large model）未能可靠地提取基本算术的正确参数。结果强调了外部符号工具何时可以可靠地工作，知道何时以及如何使用这些工具至关重要，这取决于 LLM 的能力。
TALM（工具增强语言模型）和 Toolformer都微调了 LM 以学*使用外部工具 API。根据新添加的 API 调用注释是否可以提高模型输出的质量，对数据集进行扩展。更多详细信息请参阅提示工程的“外部 API”部分。

ChatGPT 插件和 OpenAI API 函数调用是 LLM 在实践中通过工具使用能力增强的很好的例子。工具 API 的集合可以由其他开发人员提供（如插件）或自定义（如函数调用）。
HuggingGPT 是一个框架，以 ChatGPT 为任务规划器，根据模型描述选择 HuggingFace 平台中可用的模型，并根据执行结果总结响应。

该系统包括 4 个阶段：
（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 }}。聊天记录记录为 {{ 聊天记录 }}。从此聊天记录中，您可以找到用户提及的任务计划资源的路径。

（2）模型选择：LLM 将任务分配给专家模型，其中请求被框定为多项选择题。LLM 提供了可供选择的模型列表。由于上下文长度有限，需要基于任务类型的过滤。
指令为：

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

（3）任务执行：专家模型对特定任务执行并记录结果。
指令为：

根据输入和推理结果，AI 助手需要描述过程和结果。前面的阶段可以形成为- 用户输入：{{ 用户输入 }}，任务计划：{{ 任务 }}，模型选择：{{ 模型分配 }}，任务执行：{{ 预测 }}。您必须首先以直接的方式回答用户的请求。然后描述任务过程，并以第一人称向用户展示您的分析和模型推理结果。如果推理结果包含文件路径，则必须告诉用户完整的文件路径。

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

要将 HuggingGPT 投入实际使用，需要解决几个挑战：（1） 需要提高效率，因为 LLM 推理轮次和与其他模型的交互都会减慢这一过程;（2）它依靠较长的上下文窗口来就复杂的任务内容进行交流;（3）LLM 输出和外部模型服务的稳定性提升。

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

在 API-Bank 工作流程中，LLM需要做出几个决策，在每一步我们都可以评估该决策的准确性。决策包括：
（1）是否需要 API 调用。
（2）确定要调用的正确 API：如果不够好，LLM 需要迭代修改 API 输入（例如，决定搜索引擎 API 的搜索关键字）。
（3）基于 API 结果的响应：如果结果不满意，模型可以选择细化并重新调用。

该基准测试在三个级别评估代理的工具使用能力：
级别 1 评估调用 API 的能力。给定 API 的描述，模型需要确定是否调用给定的 API，正确调用它，并正确响应 API 返回。
级别 2 检查检索 API 的能力。模型需要搜索可能解决用户需求的 API，并通过阅读文档来学*如何使用它们。
第 3 级评估规划 API 的能力，而不是检索和调用。鉴于用户请求不明确（例如安排小组会议、预订航班/酒店/餐厅旅行），模型可能必须进行多次 API 调用来解决它。

实例探究

科学发现代理

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

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

一个有趣的观察结果是，虽然基于LLM的评估得出的结论是 GPT-4 和 ChemCrow 的性能几乎相当，但与专家一起进行的人类评估表明，ChemCrow 的性能大大优于 GPT-4。这表明使用 LLM 来评估其自身在需要深厚专业知识的领域的表现存在潜在问题。专业知识的缺乏可能导致LLM不知道其缺陷，从而无法很好地判断任务结果的正确性。

Boiko 等人还研究了用于科学发现的LLM赋能代理，以处理复杂科学实验的自主设计、规划和执行。该代理可以使用工具浏览 Internet、阅读文档、执行代码、调用机器人实验 API 并利用其他 LLM。
例如，当被要求 "develop a novel anticancer drug" 时，模型提出了以下推理步骤：

• 1，询问抗癌药物发现的当前趋势;
• 2，选择目标;
• 3，要求建立针对这些化合物的支架;
• 4，一旦确定了化合物，模型就尝试了它的合成。

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

生成代理模拟

生成代理是一个超级有趣的实验，其中 25 个虚拟角色，每个角色都由 LLM 驱动的代理控制，在沙盒环境中生活和互动，灵感来自《模拟人生》。生成代理为交互式应用程序创建可信的人类行为模拟。
生成智能体的设计将 LLM 与记忆、计划和反思机制相结合，使智能体能够根据过去的经验行事，并与其他智能体进行交互。
（1）记忆流：是一个长期记忆模块（外部数据库），用自然语言记录智能体经验的全面列表。每个元素都是一个观察，一个由代理直接提供的事件。- 代理间通信可以触发新的自然语言语句。
（2）检索模型：根据相关性、新*度和重要性，显示上下文以告知代理的行为。新*度：最*事件得分更高；重要性：区分平凡记忆和核心记忆。直接询问 LM；相关性：基于它与当前情况/查询的相关程度。
（3）反思机制：随着时间的推移将记忆合成成更高层次的推理，并指导智能体未来的行为。它们是对过去事件的更高层次的总结（< - 请注意，这与上面的自我反思有点不同）（用 100 个最*的观察结果提示 LM，并在给定一组观察/陈述的情况下生成 3 个最突出的高级问题。然后让 LM 回答这些问题。）
（4）规划和反应：将反射和环境信息转化为行动。规划本质上是为了优化当下与时间的可信度。提示模板： {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 工程师被指示考虑要构建的较小组件列表，并根据需要征求用户输入以澄清问题。

以下是发送到 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 是代码：

{```LANG
CODE
```}
 
您将从“入口点”文件开始，然后转到该文件导入的文件，依此类推。请注意，代码应该功能齐全。没有占位符。

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

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

Python 工具带首选项：
- pytest
- dataclasses  数据类

挑战

在经历了构建以 LLM 为中心的代理的关键想法和演示后，我开始看到几个常见的限制：
（1）有限上下文长度：受限的上下文容量限制了历史信息、详细说明、API 调用上下文和响应的包含。系统的设计必须利用这种有限的通信带宽，而自我反思等从过去的错误中吸取教训的机制将从长或无限的上下文窗口中受益匪浅。尽管向量存储和检索可以提供对更大知识库的访问，但它们的表示能力不如全注意力强大。

（2）长期规划和任务分解中的挑战：在漫长的历史中进行规划并有效探索解决方案空间仍然具有挑战性。LLM在面临意外错误时很难调整计划，这使得它们与从反复试验中学*的人类相比不太稳健。

（3）自然语言接口的可靠性：当前的代理系统依赖自然语言作为 LLM 与内存和工具等外部组件之间的接口。然而，模型输出的可靠性值得怀疑，因为 LLM 可能会犯格式错误，并且偶尔会表现出叛逆行为（例如拒绝遵循指令）。因此，大部分代理演示代码都侧重于解析模型输出。

总结和个人感悟

作者统领性地给出了AI Agent需要解决的问题，整体框架，未来发展。