LLM 的潜力与局限性
LLM 在语言生成、复杂任务理解等方面展现了强大的能力，特别是在需要生成纯文本输出的场景（如聊天机器人、文本摘要）中，表现尤为出色。然而，当需要超出“纸上谈兵”的实际应用时，这些模型依赖于外部用户执行建议的操作并反馈结果。
Agent 系统的引入
Agent 系统通过赋予模型与环境交互的能力解决了上述问题。这些系统通常利用一组工具，让模型能够执行特定操作，实现通过试错过程迭代解决问题的能力。
Multi-Agent 系统的概念
Multi-Agent 系统的核心是让模型能够访问其他 Agent 作为工具，分配任务给专用模型，并将输出结果组合成完整的解决方案。典型的实现方式是使用一个管理 Agent 来协调其他 Agent 的工作流，从而解决复杂任务。
对底层模型的需求
Multi-Agent 系统需要一个强大的 LLM 作为核心支持，该模型必须能够理解工具的用途，灵活地将问题分解为各个可操作的子问题。这使得诸如 ChatGPT 和 Claude 这样的专有模型成为 Agent 系统的首选。然而，随着开源 LLM 性能的提升，一些开源模型在某些场景下表现得几乎与专有模型相当，甚至体积适中的开源模型现在也能完成几年前无法想象的复杂任务。
使用Qwen2.5-7B-Instruct的案例
本文展示了一种基于消费级硬件运行的“小型”开源 LLM，如何在 Multi-Agent 系统中取得良好效果。
具体来说，作者通过教程介绍了如何使用 Qwen2.5-7B-Instruct 构建一个 Multi-Agentic RAG 系统，代码实现已上传至 GitHub：
https://github.com/GabrieleSgroi/multiagentic_rag
ReAct 框架：将推理与操作结合的 LLM Agent 方案
ReAct 是一种广受欢迎的框架，最早在论文《ReAct: Synergizing Reasoning and Acting in Language Models》中提出，专为构建基于 LLM 的 Agent 而设计。其核心理念是将链式思维（Chain of Thought）提示的优势整合到 Agent 框架中。
ReAct 的关键在于交替执行推理（Reasoning）和操作（Acting）步骤：
推理（Thought）：模型生成一系列推理步骤，包括整体规划和特定工具使用建议。
操作（Action）：根据推理结果，模型调用相关工具。
观察（Observation）：模型接收来自环境的反馈，并据此更新高层计划。
通过这种交替方式，ReAct 框架允许模型动态生成推理路径，在与环境交互的同时不断调整计划，从而实现迭代和增量式的任务解决。
这种设计能够让模型在每个循环中优化操作路径，不断改进任务解决方案，尤其适用于复杂问题的分步解决。
Code Agent
Code Agent 是一种特殊的 LLM Agent，通过可执行的 Python 代码与环境交互。它基于论文《Executable Code Actions Elicit Better LLM Agents》中提出的 CodeAct 框架。与 ReAct 框架类似，CodeAct 的区别在于每个操作步骤（Action）由可执行的任意代码组成，能够执行多项操作。这些 Code Agent 通过预定义的工具（以常规 Python 函数形式提供）完成任务。
下面是原始论文中的一个具体例子，展示了 Code Agent 如何需要更少的操作来解决某些任务。
Code Agent 相较于使用 JSON 或其他文本格式进行操作的传统 Agent，具有以下独特优势：
灵活性：可以结合现有软件包和任务特定的手工工具，执行复杂任务。
自我调试：Agent 能够利用错误信息自行调试生成的代码。
自然性：LLM 在预训练数据中广泛接触代码，使代码成为一种更自然的操作格式。
高效性：代码可以存储中间结果，并在单个操作中组合多项任务，而 JSON 或其他文本格式可能需要多步操作完成相同任务。
基于这些特点，Code Agent 在性能和执行速度上优于传统 Agent。
Hugging Face 提供了构建 Code Agent 的模块化工具：
清晰与模块化：Hugging Face 的 Transformer Agent 框架以清晰性和模块化为核心设计原则，便于用户掌控 Agent 系统中各个复杂的互联部分，是构建灵活自定义 Agent 系统的理想选择。
与开源模型兼容：框架与 Hugging Face 生态系统的模型和工具无缝集成，方便用户访问和使用现有资源。
生成代码的安全性一直是 LLM Agent 面临的挑战，因为无约束的代码可能引发严重问题（如意外删除重要文件）。Hugging Face 的 Code Agent 采用自下而上的安全执行方式：
操作授权：代码解释器仅能执行显式授权的操作，而非传统的“禁用危险操作”的顶层限制方式。
功能白名单：实现包括一份可执行函数和安全模块的白名单，未经预先授权的代码将无法执行。
通过这些功能，Hugging Face 的 Code Agent 为构建安全、高效、灵活的 Multi-Agent 系统提供了强大的支持。
Agentic RAG
RAG 是当前 LLM 信息检索任务的事实标准。其主要优势包括：
保持信息更新：通过检索最新信息弥补模型训练数据的时效性不足。
提供特定信息：访问特定领域的数据源，增强模型的专业性。
减少幻觉现象：提高生成结果的准确性和可信度。
提升可解释性：通过返回数据源帮助用户监督和理解生成过程。
然而，传统的 RAG 工作流程（基于用户查询的语义相似性进行检索，然后通过检索信息增强上下文）在以下场景中效果有限：
需要与信息源交互的任务。
需要多个信息片段来回答的复杂查询。
需要非平凡数据操作以将查询与信息源连接的复杂任务。
一个具体挑战是多跳问题回答（Multi-Hop Question Answering, MHQA）。这类任务需要从多个信息片段中提取并组合信息，可能涉及多轮推理。例如，针对问题“桦木胶合板是否漂浮在乙醇中？”即使数据源包含两种材料的密度信息，传统 RAG 框架可能因为缺乏直接链接而无法完成推理。
为克服上述局限，Agentic 系统成为增强 RAG 的流行方法：
任务分解：LLM Agent 可以将原始查询分解为一系列子查询。
动态调整：Agent 通过语义搜索工具检索子查询的信息，并根据收集到的信息实时调整计划。
自主决策：Agent 可自主判断是否已收集足够的信息回答问题，或是否需要继续检索。
将 Agentic RAG 扩展为 Multi-Agentic 系统可进一步提升性能：
任务分工：为每个 Agent 分配明确职责，例如将高层次任务规划与文档交互分开。
协作处理：多个 Agent 协同完成复杂任务，提高效率和准确性。
Multi-Agentic 系统可在复杂任务中表现出色。下一部分将展示这种系统的具体实现方案，以说明其如何提升 RAG 的能力。
Multi-Agent RAG 系统的架构与实现
系统目标与架构设计
目标：构建一个能够通过 Wikipedia 搜索回答用户问题的系统。
Agent 结构：由三个 Agent 组成，层级结构如下：
管理 Agent（Manager Agent）：拆分任务并整合结果，返回最终答案。接收用户问题，拆分为子任务，调用 Wikipedia 搜索 Agent 收集信息，并整合返回最终答案。
Wikipedia 搜索 Agent（Wikipedia Search Agent）：检索相关页面并提取信息。基于 wikipedia 包，利用语义搜索定位潜在的 Wikipedia 相关页面，必要时调用页面搜索 Agent 提取更具体的信息，将页面列表及摘要返回给管理 Agent。
页面搜索 Agent（Page Search Agent）：从特定 Wikipedia 页面提取与查询相关的信息。使用 LangChain 提供的 FAISS 向量数据库，将页面内容分块嵌入，利用语义相似度检索相关段落。
每个 Agent 都可调用下层 Agent 作为工具，系统基于 ReAct 框架设计，使用代码执行实现 Agent 间的协作。
实现选择与优化策略
提示词优化
每个 Agent 都有专门设计的系统提示词，包含针对性任务示例以增强模型性能。
针对聊天模型（如 Qwen2.5–7B-Instruct），提示词模板遵循模型的交互格式。
历史记录总结
为避免上下文过长影响性能，限制 Agent 仅接收必要的历史记录：系统消息、初始任务、最后的动作及所有观察结果。
删除已解决错误的记录，仅保留最新错误。
工具管理与代理包装
将 Agent 包装为工具，增强提示词控制，简化实现流程，同时减少提示词长度以提升计算速度。
限制页面搜索尝试次数
避免页面搜索 Agent 在无关页面上浪费资源，设置最大尝试次数，超过限制后返回最后的观察结果。
工具响应优化
针对 Qwen2.5–7B-Instruct 模型的聊天模板，仅支持 "system"、"user" 和 "assistant" 角色，将观察结果作为用户消息返回。
