什么是 LLM Agent？
LLM Agent（大语言模型智能体）是一种程序，其执行逻辑由底层模型控制。与简单的少量样本提示（few-shot prompting）或预设工作流程不同，Agent 能够制定并调整执行用户查询所需的步骤。
当拥有诸如代码执行或网络搜索等工具集的访问权限时，Agent 能够自主决定使用何种工具、如何使用，并依据输出结果进行迭代优化。这种灵活性使得系统能够以极低的配置需求应对多样化的场景。
Agent 架构存在于一个连续的变化范围内，从固定工作流程的可靠性到 autonomous agents 的高度灵活性。例如，像检索增强生成（RAG）这样的预设流程，可以通过加入自我反思循环（self-reflection loop）来提升改进，使得程序在初次响应不充分时能够进行改进。另一方面，ReAct Agent 可以配备预设流程作为其工具之一，实现一种既灵活又有条理的处理方式。架构的选择最终应根据具体应用场景以及可靠性与灵活性之间的平衡需求来决定。
从头开始打造一款通用 LLM Agent
第一步：挑选合适的 LLM
挑选合适的模型是实现预期性能的关键。在决策时，需考虑多个因素，如版权许可、成本和语言支持。对于构建 LLM Agent 来说，最关键的考虑因素是模型在核心任务上的表现，例如编程、调用工具和逻辑推理。
评估标准包括：
- 大规模多任务语言理解（MMLU）：用于推理能力评估。
- 伯克利大学的函数调用排行榜：用于工具的选择与调用能力评估。
- HumanEval 和 BigCodeBench：用于编程能力评估。
此外，模型的处理窗口大小也非常重要。Agent 的工作流程可能会消耗大量 token —— 有时甚至超过 10 万个 —— 因此，更大的处理窗口将大大提高处理效率。
当前值得关注的模型包括前沿模型（如 GPT-4o, Claude 3.5）和开源模型（如 Llama 3.2, Qwen 2.5）。一般来说，模型越大，性能越优越。但能够在本地运行的小型模型也是一个不错的选择，通常适用于较为简单的场景，并且可能只能与一到两个基础工具对接。
第二步：设定智能体的控制逻辑
简单大语言模型（LLM）与智能体（Agent）之间的核心差异，主要体现在系统提示词上。我们可以通过系统提示词来编码大语言模型应展现的智能体行为。
常见的智能体行为模式包括：
- 工具运用：智能体判断何时应将问题转交给适当的工具处理，或是依赖自身知识库。
- 自我反思：智能体在回复用户前，会审视并修正自己的答案。
- Reason-then-Act（ReAct）：智能体通过反复推理来确定解决问题的方法，执行操作，观察结果，并决定是否需要进一步行动或直接给出回答。
- Plan-then-Execute：智能体通过将任务细分为多个子步骤来进行事前规划，然后逐一执行这些步骤。
在构建通用单智能体时，ReAct 和 Plan-then-Execute 这两种模式通常是起步的最佳选择。为了有效地实现这些行为模式，我们需要对提示词进行精心设计，可能还需要采用结构化生成技术，这意味着会调整 LLM 的输出，使其符合特定的格式或架构，从而确保智能体的回复与我们所追求的沟通风格保持一致。
第三步：设定智能体的核心指令
要想实现期望的性能表现，就需要在系统提示词中详细列出应该包含以及不应该包含的功能。这可能涉及以下指令：
- 智能体的名称与职责：智能体的命名及其预期执行的任务。
- 语言风格与简洁性：智能体在交流时应该保持的正式或随意程度，以及信息传达的简洁性。
- 工具使用时机：确定何时应该利用外部工具，何时依赖模型自身的知识库。
- 错误处理：当工具使用或流程执行出现问题时，智能体应采取的行动。
第四步：定义并优化核心工具集
工具就是赋予智能体超能力的魔法。只需一套定义明确的工具，就能实现广泛的应用功能。重要的工具包括代码执行、网络检索、文档读取和数据解析等。
对于每一项工具，都需要定义以下信息，并将其融入系统提示词之中：
- Tool Name：为这项功能起一个独特且具描述性的名称。
- Tool Description：清晰地阐述该工具的作用及其使用时机。
- Tool Input Schema：这是一个框架，它规定了必需和可选的参数、参数类型以及所有约束条件。
- 运行指南：提供一个指示或者指南，告诉用户或者开发者这个工具应该在哪里以及如何被运行。
在某些场景下，为了达到预期的性能，我们需要对工具进行优化。这可能需要通过微调工具名称或描述来进行提示词工程，设置高级配置来处理常见问题，或是过滤、筛选工具的输出结果。
第五步：确立内存管理策略
大语言模型（LLMs）受限于它们的上下文窗口大小。在多轮对话中，过往互动、工具输出的长文本或者是 Agent 所依赖的额外上下文信息，都可能迅速占满内存空间。因此，制定一个有效的内存管理策略是非常重要的。
这里的'内存'是指智能体存储、调用并利用历史交互信息的能力。常见的内存管理策略包括：
- Sliding Memory：只保留最近 k 轮对话的记忆，较早的对话则被舍弃。
- Token Memory：只记下最近 n 个 tokens，其余的则被遗忘。
- Summarized Memory：每轮对话后，使用 LLM 对对话内容进行总结摘要，并丢弃原始信息。
另外，我们还可以利用 LLM 来识别关键信息（key moments），并将其存储在长期记忆中。这样，智能体就能'记住'用户的重要信息，使用户体验更加个性化。
如果在这个阶段我们通过 LLM 处理用户查询，你会得到一段未经处理的文本输出。此时，智能体会生成一段原始的文本输出。那么，我们如何确保智能体能够执行后续操作呢？这就需要引入解析和编排机制了。
第六步：解析智能体的原始输出
解析器的作用是将原始数据转换成应用程序能够识别和使用的数据格式（例如，带有特定属性的对象）。
对于我们正在构建的智能体，解析器必须能够辨认出我们在第二步中设定的通信结构，并将其转换成结构化数据输出，例如 JSON 格式。这样做可以让应用程序更加便捷地处理和执行智能体的后续动作。
备注：某些模型供应商，例如 OpenAI，可以默认提供可直接解析的输出。而对于其他模型，尤其是那些开源模型，可能需要额外进行解析配置。
第七步：规划智能体的后续行动
最后一步是建立编排逻辑。这一逻辑决定了 LLM 输出内容结果之后的处理流程。依据输出内容，系统将执行以下任一操作：
- 执行工具调用
- 给出回应 —— 这可能是对用户查询的直接回答，也可能是为了获取更多信息而提出的后续问题。
如果触发了工具调用，工具的输出信息会被送回 LLM（作为其工作记忆的一部分）。LLM 将据此决定如何利用这些新数据：是继续进行工具调用，还是直接向用户返回答案。
多智能体系统在什么情况下派上用场？
尽管当前 LLM 的表现令人印象深刻，但它们在处理海量信息时却显得力不从心。一旦上下文过多或工具使用过杂，模型便可能不堪重负，导致性能下滑。面向多种用途的单智能体系统最终会触及这一上限，尤其是在它们对 token 的消耗量之大已是众所周知。
对于某些使用场景，部署多智能体系统或许更为合适。通过将任务分摊给多个智能体，可以有效避免单一 LLM Agent 的上下文负载过重，从而提高整体的执行效率。
尽管如此，通用的单智能体系统仍然是原型开发的一个极好起点。它能帮助我们迅速验证使用场景，并发现系统何时开始出现故障。在这个过程中，你将能够洞察哪些任务环节确实能通过 Agent 模式得到优化，确定可以作为独立流程分离出来，成为更大工作流程中一环的部分。
总结
构建通用 AI Agent 是一个系统工程，需要平衡模型的推理能力、工具的可用性以及系统的稳定性。通过遵循上述七个步骤，开发者可以搭建出一个具备基本自主能力的智能体。随着技术的演进，未来的 Agent 将更加智能化，能够处理更复杂的跨领域任务。在实际落地过程中，建议从单智能体原型开始，逐步迭代优化，再根据实际需求扩展至多智能体协作架构。
