AI 智能体（也有人称为 AI 代理），英文名称为 AI Agent，更准确地说现在就是指 LLM Agent，它是一个执行逻辑由其底层模型（LLM）控制的程序。

LLM Agent 与少样本提示（few-shot prompting）或固定工作流（fixed flows）等方法的不同之处在于，它能够定义和调整执行用户查询所需的步骤。如果能够访问一组工具（如代码执行或 Web 搜索），Agent 可以决定使用哪种工具、如何使用它，并根据输出迭代结果。这种适应性使系统能够以最少的配置处理各种用例。

Agent 架构涵盖了从固定工作流的可靠性到自主代理的范围。例如，像检索增强生成 (RAG) 这样的固定流程可以通过自我反思循环进行增强，使程序能够在初始响应不足时进行迭代。或者，ReAct 代理可以配备固定流程作为工具，提供灵活而结构化的方法。架构的选择最终取决于用例以及可靠性和灵活性之间的理想权衡。

接下来我将介绍如何从头构建一个通用的 AI Agent。

选择正确的模型对于实现所需的性能至关重要。有几个因素需要考虑，例如许可、成本和语言支持。构建 LLM Agent 最重要的考虑因素是模型在编码、工具调用和推理等关键任务上的性能。要评估的基准包括：

• 大规模多任务语言理解 (MMLU)（推理）

• 伯克利的函数调用排行榜（工具选择和工具调用）

• HumanEval 和 BigCodeBench（编码）

另一个关键因素是模型的上下文窗口。Agent 工作流可能会消耗大量 token——有时 100K 或更多——更大的上下文窗口确实很有帮助。

截至我写本文时，你可以需要考虑的模型：

• 闭源模型：GPT4-o、Claude 3.5

• 开源模型：Llama3.2、Qwen2.5。

一般来说，较大的模型往往提供更好的性能，但可以在本地运行的较小模型仍然是一个不错的选择。对于较小的模型，你将只能使用更简单的用例，并且可能只能将你的Agent 连接到一两个基本工具。

简单 LLM 和 Agent 之间的主要区别在于系统提示（system prompt）。

在 LLM 上下文中，系统提示是在模型处理用户查询之前提供给模型的一组指令和上下文信息。

LLM 所期望的 Agent 行为可以在系统提示中编纂。

以下是一些常见的 Agent 模式，可以根据您的需求进行定制：

• 工具使用：Agent 确定何时将查询路由到适当的工具或依靠自己的知识。

• 反思：Agent 在回复用户之前会检查并更正其答案。大多数 LLM 系统也可以添加反思步骤。

• 推理然后行动 (ReAct)：Agent 反复推理如何解决查询，执行操作，观察结果，并确定是否采取其他操作或提供响应。

• 计划然后执行：Agent 通过将任务分解为子步骤（如果需要）进行预先计划，然后执行每个步骤。

最后两种模式（ReAct 和计划然后执行）通常是构建通用单一 Agent 的最佳起点。

为了有效地实现这些行为，你需要进行一些提示工程（prompt engineering）。你可能还想使用结构化生成技术。这基本上意味着塑造 LLM 的输出以匹配特定的格式或模式，以便 Agent 的响应与你想要的沟通风格保持一致。

我们往往想当然地认为 LLM 具有一系列开箱即用的功能。其中一些功能很棒，但其他功能可能并不完全符合我们的需求。为了获得我们想要的性能，在系统提示中详细说明我们想要和不想要的所有功能非常重要。

这可能包括以下说明：

• Agent 名称和角色：Agent 的名称以及其用途。

• 语气和简洁性：听起来应该正式还是随意，以及应该简短到什么程度。

• 何时使用工具：决定何时依赖外部工具而不是模型自身的知识。

• 处理错误：当工具或流程出现问题时，Agent 应该做什么。

工具赋予了你的 Agent 超能力。使用一组定义明确的工具，你可以实现广泛的功能。要包含的关键工具是代码执行、Web 搜索、文件读取和数据分析。

对于每个工具，你需要定义以下内容并将其作为系统提示的一部分：

• 工具名称：功能的唯一描述性名称。

• 工具说明：清晰地解释工具的功能和使用时间。这有助于 Agent 确定何时选择正确的工具。

• 工具输入模式：概述必需和可选参数、其类型以及任何约束的模式。Agent 使用它根据用户的查询填写所需的输入。

• 指向在何处/如何运行工具的指针。

在某些情况下，你需要优化工具以获得所需的性能。这可能涉及使用一些快速工程调整工具名称或描述、设置高级配置以处理常见错误或过滤工具的输出。

LLM 受到其上下文窗口（即它们一次可以“记住”的 token 数量）的限制。这种记忆很快就会被诸如多轮对话中的过去互动、冗长的工具输出或代理所依据的额外上下文等内容填满。这就是为什么制定可靠的记忆处理策略至关重要。

在 Agent 的上下文中，记忆是指系统存储、调用和利用过去互动信息的能力。这使代理能够随着时间的推移保持上下文，根据以前的交流改进其响应，并提供更加个性化的体验。

常见的记忆处理策略：

• 滑动记忆：将最后 k 个对话回合保留在记忆中，并删除较旧的对话回合。

• token 记忆：保留最后 n 个 token，忘记其余的 token。

• 总结记忆：使用 LLM 总结每个回合的对话并删除单个消息。

此外，你还可以让 LLM 检测关键时刻以存储在长期记忆中。这使 Agent 能够“记住”有关用户的重要事实，从而使体验更加个性化。

到目前为止，我们介绍的五个步骤为建立代理奠定了基础。但如果我们在此阶段通过 LLM 运行用户查询，会发生什么情况？

此时，Agent 生成原始文本输出。那么我们如何让它真正执行下一步呢？这就是解析和编排的作用所在。

解析器是一种将原始数据转换为应用程序可以理解和使用的格式（如具有属性的对象）的函数

对于我们正在构建的 Agent，解析器需要识别我们在第二步中定义的通信结构并返回结构化输出，如 JSON。这使应用程序更容易处理和执行 Agent 的后续步骤。

注意：某些模型提供商（如 OpenAI）可以默认返回可解析的输出。对于其他模型，尤其是开源模型，则需要进行配置。

最后一步是设置编排逻辑。这决定了 LLM 输出结果后会发生什么。根据输出，你可以：

1. 执行工具调用，或

2. 返回答案 — 对用户查询的最终响应或对更多信息的后续请求。

如果触发了工具调用，则工具的输出将发送回 LLM（作为其工作内存的一部分）。然后，LLM 将确定如何处理这些新信息：执行另一个工具调用或向用户返回答案。

以下是此编排逻辑在代码中的示例：

虽然这一代 LLM 非常强大，但它们有一个关键的限制：它们难以应对信息过载。过多的上下文或过多的工具会使模型不堪重负，从而导致性能问题。通用的单一 Agent 最终会达到这个上限，特别是因为 Agent 是出了名的 token 饥渴。

对于某些用例，多 Agent 设置可能更有意义。通过将职责划分给多个 Agent，你可以避免单个 LLM Agent 的上下文过载并提高整体效率。

话虽如此，通用的单 Agent 设置是原型设计的绝佳起点。它可以帮助你快速测试用例并确定事情开始崩溃的地方。通过此过程，你可以：

1. 了解任务的哪些部分真正受益于 Agent 方法。

2. 确定可以在更大的工作流中作为独立流程分离的组件。

从单个 Agent 开始可以为你提供宝贵的见解，以便在扩展到更复杂的系统时改进你的方法。

准备好深入研究并开始构建了吗？使用框架是快速测试和迭代 Agent 配置的好方法：

• 计划使用 Llama 3 等开源模型？试试 Bee Agent Framework。

• 计划使用 OpenAI 等前沿模型？试试 LangGraph。