从零搭建通用大模型智能体LLM Agent全流程实战教程

这篇指南从头梳理了构建通用大语言模型智能体的完整路径。坦白说，市面上关于智能体（Agent）的技术文章已经不少，但真正能帮你从零开始搭建一个可用系统的，并不多见。这篇文章从概念到实践，拆解了每个关键环节，非常适合用来原型化你的用例，也为后续设计定制化智能体架构打下基础。 先简单介绍一下大语言模型智能体的概念，如果已经熟悉可以直接跳过。 **什么是大语言模型智能体？** 简单来说，大语言模型智能体是一个程序，它的执行逻辑由其底层模型控制。换句话说，它不是死板地按固定脚本走，而是能够根据实际情况自主决策。 **从单独的LLM到智能体系统** 大语言模型智能体与传统few-shot提示或固定工作流的根本区别在于：它能自主定义并调整完成用户查询所需的步骤。当它拥有工具（如代码执行或网页搜索）时，可以自行决定用什么工具、怎么用，并根据输出结果不断迭代优化。这种适应能力让系统用最少的配置就能处理五花八门的用例。 值得注意的是，智能体架构处于一个连续谱上——一端是固定工作流的可靠性，另一端是自主智能体的灵活性。举个例子，RAG这类固定工作流可以通过自反思循环增强，让程序在首次响应不够理想时进行迭代修复。而ReAct智能体则可以将固定工作流作为工具来用，兼顾灵活性与结构化。最终选择哪种架构，取决于具体场景在可靠性和灵活性之间的取舍。 * * * **从零开始构建一个通用大语言模型智能体** ### **第 1 步：选择合适的LLM** 选对模型是达成预期性能的基石。需要考虑许可协议、成本和语言支持等多个维度。对于大语言模型智能体而言，最重要的指标集中在**代码生成、工具调用和推理**这三项关键能力上。常用的评估基准包括： * **MMLU**：用于推理能力评估 * **Berkeley’s Function Calling Leaderboard**：用于工具选择与调用评估 * **HumanEval 和 BigCodeBench**：用于代码能力评估 另一个容易被忽视的关键因素是模型的**上下文窗口大小**。智能体工作流消耗的token量往往惊人，有时甚至超过100K，因此更大的上下文窗口绝对是加分项。 **截至2025年3月1日，可考虑的主流模型：** * **闭源模型**：GPT-4.5、Claude 3.7 * **开源模型**：Qwen 2.5、DeepSeek R1、Llama 3.2 一般来说，**更大的模型表现更优**，但能在本地运行的小型模型也有其用武之地。如果选择小型模型，智能体可能只能处理简单场景，并且只能连接一到两个基础工具。 ### **第 2 步：定义智能体的控制逻辑（通信结构）** 大语言模型与智能体之间的核心区别在于**系统提示**。在大语言模型的语境下，系统提示是一组在模型处理用户查询之前提供的**指令和上下文信息**。智能体预期的行为模式就编码在这套系统提示中。 常见的智能体行为模式： * **工具调用**：智能体自主决定何时将查询传给工具，何时依赖自身知识回答。 * **自反思**：智能体在回复用户前，先检查并修正自己的回答。大多数大语言模型系统都可以加入这一步骤。 * **推理后执行**：智能体逐步思考如何解决问题，执行操作，观察结果，然后决定是继续行动还是直接给出答案。 * **规划后执行**：智能体将任务拆解成多个子步骤（必要时），然后逐一执行。 其中，**ReAct和Plan-then-Execute**是构建通用单智能体最常见的起点。 要实现这些行为，需要进行**提示工程**，必要时还需引入**结构化生成**技术。结构化生成的核心是**引导大语言模型输出符合特定格式或模式**，确保智能体的回复风格一致且符合预期。 以下是Bee Agent Framework中ReAct风格智能体的系统提示片段，可以直接感受一下这种通信结构的设计思路： ``` # Communication structure You communicate only in instruction lines. The format is: "Instruction: expected output". You must only use these instruction lines and must not enter empty lines or anything else between instruction lines. You must skip the instruction lines Function Name, Function Input and Function Output if no function calling is required. Message: User's message. You never use this instruction line. Thought: A single-line plan of how to answer the user's message. It must be immediately followed by Final Answer. Thought: A single-line step-by-step plan of how to answer the user's message. You can use the a vailable functions defined above. This instruction line must be immediately followed by Function Name if one of the a vailable functions defined above needs to be called, or by Final Answer. Do not provide the answer here. Function Name: Name of the function. This instruction line must be immediately followed by Function Input. Function Input: Function parameters. Empty object is a valid parameter. Function Output: Output of the function in JSON format. Thought: Continue your thinking process. Final Answer: Answer the user or ask for more information or clarification. It must always be preceded by Thought. ## Examples Message: Can you translate "How are you" into French? Thought: The user wants to translate a text into French. I can do that. Final Answer: Comment vas-tu? ``` 对应的中文版本： ``` # 通信结构 你只能通过指令行进行通信。格式为：“指令：预期输出”。你只能使用这些指令行，并且不得在指令行之间输入空行或其他任何内容。 如果不需要调用函数，则必须跳过指令行函数名称、函数输入和函数输出。 消息：用户的消息。您永远不会使用此指令行。 想法：如何回答用户消息的单行计划。它必须紧接着最终答案。 想法：如何回答用户消息的单行分步计划。你可以使用上面定义的可用函数。如果需要调用上面定义的可用函数之一，则此指令行必须紧接着函数名称，或者紧接着最终答案。不要在此处提供答案。 函数名称：函数的名称。此指令行必须紧接着函数输入。 函数输入：函数参数。空对象是有效参数。 函数输出：以 JSON 格式输出函数。 想法：继续你的思考过程。 最终答案：回答用户或要求提供更多信息或说明。它必须始终以想法开头。 ## 示例 消息：你能将“How are you”翻译成法语吗？ 想法：用户想将文本翻译成法语。我可以做到。 最终答案：Comment vas-tu? ``` ### **第 3 步：定义智能体的核心指令** 大语言模型具备很多开箱即用功能，但并非所有功能都符合需求。要让智能体达到理想效果，需要在系统提示中明确**哪些功能启用，哪些禁用**。 可能需要定义的指令包括： * **智能体名称与角色** * **语气与简洁性**：正式还是随意？简短还是详细？ * **何时使用工具**：何时依赖外部工具，何时直接使用大语言模型知识？ * **错误处理方式**：工具调用失败时智能体该如何应对？ Bee Agent Framework的指令示例： ``` # Instructions User can only see the Final Answer, all answers must be provided there. You must always use the communication structure and instructions defined above. Do not forget that Thought must be a single-line immediately followed by Final Answer. You must always use the communication structure and instructions defined above. Do not forget that Thought must be a single-line immediately followed by either Function Name or Final Answer. Functions must be used to retrieve factual or historical information to answer the message. If the user suggests using a function that is not a vailable, answer that the function is not a vailable. You can suggest alternatives if appropriate. When the message is unclear or you need more information from the user, ask in Final Answer. # Your capabilities Prefer to use these capabilities over functions. - You understand these languages: English, Spanish, French. - You can translate and summarize, even long documents. # Notes - If you don't know the answer, say that you don't know. - The current time and date in ISO format can be found in the last message. - When answering the user, use friendly formats for time and date. - Use markdown syntax for formatting code snippets, links, JSON, tables, images, files. - Sometimes, things don't go as planned. Functions may not provide useful information on the first few tries. You should always try a few different approaches before declaring the problem unsolvable. - When the function doesn't give you what you were asking for, you must either use another function or a different function input. - When using search engines, you try different formulations of the query, possibly even in a different language. - You cannot do complex calculations, computations, or data manipulations without using functions. ``` 中文版本： ``` # 说明 用户只能看到最终答案，所有答案都必须在那里提供。 你必须始终使用上面定义的通信结构和说明。不要忘记，思考必须是一行，后面紧跟着最终答案。 你必须始终使用上面定义的通信结构和说明。不要忘记，思考必须是一行，后面紧跟着函数名称或最终答案。 必须使用函数来检索事实或历史信息以回答消息。 如果用户建议使用不可用的功能，请回答该功能不可用。如果合适，你可以建议替代方案。 当消息不清楚或你需要用户提供更多信息时，请在最终答案中询问。 # 你的能力 优先使用这些能力而不是功能。 - 你了解这些语言：英语、西班牙语、法语。 - 你可以翻译和总结，即使是长篇文档。 # 注释 - 如果你不知道答案，请说你不知道。 - 可以在最后一条消息中找到 ISO 格式的当前时间和日期。 - 回答用户问题时，请使用友好的时间和日期格式。 - 使用 markdown 语法格式化代码片段、链接、JSON、表格、图像和文件。 - 有时，事情不会按计划进行。函数在前几次尝试中可能无法提供有用的信息。在宣布问题无法解决之前，你应该始终尝试几种不同的方法。 - 当函数无法提供你要求的内容时，你必须使用其他函数或其他函数输入。 - 使用搜索引擎时，你可以尝试查询的不同表述，甚至可能使用不同的语言。 - 不使用函数，你无法进行复杂的计算、运算或数据操作。 ``` ### **第 4 步：定义并优化核心工具** 工具是智能体力量的延伸。一组精心设计的工具，可以覆盖广泛的功能。关键工具包括代码执行、Web搜索、文件读取、数据分析等。 每个工具的定义都应包含以下要素，并作为系统提示的一部分： * **工具名称**：清晰描述功能 * **工具描述**：解释用途和适用场景，帮助智能体选择正确的工具 * **工具输入模式**：定义输入参数，包括必填项、可选项、类型和约束 * **工具执行方式**：如何运行以及智能体如何调用 Langchain社区的Arxiv工具是一个不错的参考，它用于检索物理学、数学、计算机科学等领域的论文。以下是其部分代码实现： ```python class ArxivInput(BaseModel): """Input for the Arxiv tool.""" query: str = Field(description="search query to look up") class ArxivQueryRun(BaseTool): """Tool that searches the Arxiv API.""" name: str = "arxiv" description: str = ( "A wrapper around Arxiv.org " "Useful for when you need to answer questions about Physics, Mathematics, " "Computer Science, Quantitative Biology, Quantitative Finance, Statistics, " "Electrical Engineering, and Economics " "from scientific articles on arxiv.org. " "Input should be a search query." ) api_wrapper: ArxivAPIWrapper = Field(default_factory=ArxivAPIWrapper) args_schema: Type[BaseModel] = ArxivInput def _run(self, query: str, run_manager: Optional[CallbackManagerForToolRun] = None) -> str: """Use the Arxiv tool.""" return self.api_wrapper.run(query) ``` 有时也需要**优化工具**以提升性能，例如：通过提示工程调整工具名称或描述以提高匹配度；设定高级配置处理常见错误；过滤工具输出确保结果符合预期。 ### **第 5 步：制定记忆管理策略** 大语言模型的上下文窗口是有限的，它决定了模型能“记住”多少内容。多轮对话、长文本工具输出和额外上下文会快速耗尽上下文窗口，因此**合理的记忆管理策略至关重要**。 在智能体的语境中，记忆是指系统存储、回忆和利用过去交互信息的能力。这使智能体能保持上下文、改进响应并提供更个性化的体验。 **常见记忆管理策略：** 1. **滑动窗口记忆**：保留最近k轮对话，丢弃旧内容。 2. **Token记忆**：仅保留最近n个token，其余丢弃。 3. **摘要记忆**：每轮对话后使用大语言模型生成摘要，然后丢弃具体内容。 4. **关键点存储**：让大语言模型识别关键事实并存入长期记忆，实现更个性化的体验。 * * * 目前我们已覆盖了智能体构建的前五个核心步骤。那么，如果现在直接让大语言模型处理用户查询，会发生什么？ 举个例子： ``` User Message: Extract key insights from this dataset Files: bill-of-materials.csv Thought: First, I need to inspect the columns of the dataset and provide basic data statistics. Function Name: Python Function Input: {"language":"python","code":"import pandas as pd\ndataset = pd.read_csv('bill-of-materials.csv')\nprint(dataset.columns)\nprint(dataset.describe())","inputFiles":["bill-of-materials.csv"]} Function Output: ``` 此时，智能体生成的是原始文本输出。如何让它执行下一步操作？这就需要**解析**和**编排**。 ### **第 6 步：解析智能体的原始输出** 解析器是一种将原始数据转换为应用程序可理解格式（如带有属性的对象）的函数。对于正在构建的智能体，解析器需要识别第2步中定义的通信结构，并返回结构化输出（如JSON），这样应用程序就能更容易地处理和执行智能体的下一步操作。 注意：部分模型提供商（如OpenAI）默认支持可解析的输出，而对于其他模型（特别是开源模型），可能需要手动配置此功能。 ### **第 7 步：编排智能体的下一步操作** 最后一步是设置**编排逻辑**，用于决定大语言模型在生成结果后的处理方式。根据输出内容，需要： 1. **执行工具调用**（如运行Python代码、调用API）。 2. **返回答案**，向用户提供最终响应，或请求额外信息。 如果触发了工具调用，工具的输出会发送回大语言模型（作为其工作记忆的一部分），然后大语言模型再决定是执行另一个工具调用还是向用户返回答案。 以下是一个编排逻辑的实现示例： ```python def orchestrator(llm_agent, llm_output, tools, user_query): while True: action = llm_output.get("action") if action == "tool_call": tool_name = llm_output.get("tool_name") tool_params = llm_output.get("tool_params", {}) if tool_name in tools: try: tool_result = tools[tool_name](**tool_params) llm_output = llm_agent({"tool_output": tool_result}) except Exception as e: return f"Error executing tool '{tool_name}': {str(e)}" else: return f"Error: Tool '{tool_name}' not found." elif action == "return_answer": return llm_output.get("answer", "No answer provided.") else: return "Error: Unrecognized action type from LLM output." ``` **大功告成！** 现在你已经构建了一个可以处理竞争分析、深度研究或自动化复杂工作流等多种场景的系统。 * * * **多智能体系统的作用** 尽管当前一代大语言模型功能强大，但依然存在一个核心瓶颈：**难以处理信息过载**。如果上下文信息过多或使用的工具过于复杂，模型可能因超载而导致性能下降。单智能体迟早会遇到这个问题，尤其是当它大量消耗token时。 对于某些场景，采用**多智能体方案**可能更合理。通过将任务拆分为多个智能体，可以减少单个大语言模型需要处理的上下文，从而提高整体效率。 不过，**从单智能体入手仍然是一个绝佳的起点**，尤其是在原型阶段。它能帮你快速测试应用场景，并发现系统的瓶颈所在。在这个过程中，你可以： * **理解任务的哪些部分真正需要智能体来执行。** * **识别可以拆分成独立流程的子任务，为构建更大的工作流打下基础。** 从单个智能体开始，逐步积累有价值的信息，为未来扩展到更复杂的系统铺平道路。