解码通用 AI Agent：七步构建你的智能系统

LLM Agent 是一种程序，其执行逻辑由底层模型控制。

从独立的 LLM 到具备 Agent 功能的系统。（图片由原文作者提供）

LLM Agent 与简单的少量样本提示（few-shot prompting）或预设工作流程的不同之处在于，它能够制定并调整执行用户查询所需的步骤。当拥有诸如代码执行或网络搜索等工具集的访问权限时，Agent 能够自主决定使用何种工具、如何使用，并依据输出结果进行迭代优化。这种灵活性使得系统能够以极低的配置需求应对多样化的场景。

第一步：挑选合适的 LLM

挑选合适的模型是实现预期性能的关键。在决策时，需考虑多个因素，如版权许可、成本和语言支持。对于构建 LLM Agent 来说，最关键的考虑因素是模型在核心任务上的表现，例如编程、调用工具和逻辑推理。以下是一些评估标准：

此外，模型的处理窗口大小也非常重要。Agent 的工作流程可能会消耗大量 token —— 有时甚至超过 10 万个 —— 因此，更大的处理窗口将大大提高处理效率。

当前值得关注的模型（本文撰写时）包括：

一般来说，模型越大，性能越优越。但能够在本地运行的小型模型也是一个不错的选择。小型模型通常适用于较为简单的场景，并且可能只能与一到两个基础工具对接。

第二步：设定智能体的控制逻辑（亦称为通信结构）

单智能体（single Agent）架构图示。（图片由原文作者创作）

简单大语言模型（LLM）与智能体（Agent）之间的核心差异，主要体现在系统提示词上。

就 LLM 而言，系统提示词^[12]是指在模型开始处理用户查询前，提供给模型的一系列指令和背景信息。

我们可以通过系统提示词来编码大语言模型应展现的智能体行为。

以下是一些常见的智能体行为模式，它们可以根据您的具体需求进行调整：

在构建通用单智能体时，ReAct 和 Plan-then-Execute 这两种模式通常是起步的最佳选择。

常见智能体行为模式概览。（图片由原文作者创作）

为了有效地实现这些行为模式，我们需要对提示词进行精心设计。可能还需要采用结构化生成技术^[13]，这意味着会调整 LLM 的输出，使其符合特定的格式或架构，从而确保智能体的回复与我们所追求的沟通风格保持一致。

举例：下面是 Bee Agent Framework^[14] 中一个 ReAct 风格智能体的系统提示词片段。

第三步：设定智能体的核心指令

我们往往会想当然地认为，大语言模型（LLMs）一开箱就能提供一系列功能。虽然其中某些功能非常出色，但并非所有功能都能满足我们的具体需求。要想实现期望的性能表现，就需要在系统提示词中详细列出应该包含以及不应该包含的功能。

这可能涉及以下指令：

示例：以下摘录自 Bee Agent Framework^[14] 的操作指南部分。

第四步：定义并优化核心工具集

工具就是赋予智能体超能力的魔法。只需一套定义明确的工具，就能实现广泛的应用功能。重要的工具包括代码执行、网络检索、文档读取和数据解析等。

对于每一项工具，都需要定义以下信息，并将其融入系统提示词之中：

例如：以下是从 Langchain 社区摘录的 Arxiv 工具实现片段^[15]，需要 ArxivAPIWrapper^[16] 的支持。

在某些场景下，为了达到预期的性能，我们需要对工具进行优化。这可能需要通过微调工具名称或描述来进行提示词工程，设置高级配置来处理常见问题，或是过滤、筛选工具的输出结果。

第五步：确立内存管理策略

大语言模型（LLMs）受限于它们的上下文窗口大小 —— 也就是它们一次性能够“记下”的 tokens 数量。在多轮对话中，过往互动、工具输出的长文本或者是 Agent 所依赖的额外上下文信息，都可能迅速占满内存空间。因此，制定一个有效的内存管理策略是非常重要的。

在这里，所谓的“内存”是指智能体（Agent）存储、调用并利用历史交互信息的能力。这种能力使得智能体能够持续跟踪对话上下文，基于之前的对话来优化回答，从而提供更加定制化的用户体验。

常见的内存管理策略包括：

另外，我们还可以利用 LLM 来识别关键信息（key moments），并将其存储在长期记忆中。这样，智能体就能“记住”用户的重要信息，使用户体验更加个性化。

我们目前所讨论的五个步骤为创建智能体奠定了基础。那么，如果在这个阶段我们通过 LLM 处理用户查询，会发生什么呢？

答案是：你会得到一段未经处理的文本输出。（图片由作者提供）

示例如下：

此时，智能体会生成一段原始的文本输出。那么，我们如何确保智能体能够执行后续操作呢？这就需要引入解析和编排机制了。

第六步：解析智能体（Agent）的原始输出

解析器的作用是将原始数据转换成应用程序能够识别和使用的数据格式（例如，带有特定属性的对象）。

对于我们正在构建的智能体，解析器必须能够辨认出我们在第二步中设定的通信结构，并将其转换成结构化数据输出，例如 JSON 格式。这样做可以让应用程序更加便捷地处理和执行智能体的后续动作。

备注：某些模型供应商，例如 OpenAI，可以默认提供可直接解析的输出。而对于其他模型，尤其是那些开源模型，可能需要额外进行解析配置。

第七步：规划智能体的后续行动

最后一步是建立编排逻辑。这一逻辑决定了 LLM 输出内容结果之后的处理流程。依据输出内容，系统将执行以下任一操作：

尽管当前 LLM 的表现令人印象深刻，但它们在处理海量信息时却显得力不从心^[17]。一旦上下文过多或工具使用过杂，模型便可能不堪重负，导致性能下滑。面向多种用途的单智能体系统最终会触及这一上限，尤其是在它们对 token 的消耗量之大已是众所周知。

对于某些使用场景，部署多智能体系统或许更为合适。通过将任务分摊给多个智能体，可以有效避免单一 LLM Agent 的上下文负载过重，从而提高整体的执行效率。

尽管如此，通用的单智能体系统仍然是原型开发的一个极好起点。它能帮助我们迅速验证使用场景，并发现系统何时开始出现故障。在这个过程中，你将能够：

已经迫不及待想要开始构建智能体了吗？使用框架是快速测试和迭代智能体配置的好方法。