Agent篇

Agent包含哪些模块，实现了什么功能

Agent 就像一个多功能的接口，它能够接触并使用一套工具。根据用户的输入，Agent会规划出一条解决用户问题的路线，决定其中需要调用哪些工具，并调用这些工具。Agent = 大语言模型+规划+记忆+工具使用，具备以下关键能力：

规划（Planning）：最核心最关键的部分，负责拆解复杂任务为可执行的子任务，并规划执行任务的流程。同时Agent还会对任务执行的过程进行思考和反思，决定是否继续执行任务，并改进决策策略。
- 任务分解：将复杂任务分解为可执行的子任务，让大模型逐步解决，例如将订外卖分解为选择餐厅+选择菜品两步。关键技术例如CoT、LLM+P等。
- 反思：Agent 通过完善过去的行动决策和纠正以前的错误来不断改进。关键技术例如React、Reflexion等。
记忆（Memory）：包括短期记忆和长期记忆，用于存储会话上下文和业务数据等信息，来优化未来行为。
- 短时记忆：即上下文学习，由于受到Transformer上下文窗口长度的限制，它是短暂的和有限的。
- 长期记忆：则可对应为外部的向量数据存储，Agent 可在查询时引用，并可通过快速检索进行访问。
工具使用（Tools）：通过调用外部工具（如API、插件）扩展Agent的能力，如文档解析、代码编译等。

你有开发过Agent吗，知道哪些Agent开发平台

扣子coze（字节）
通义千问（阿里）
元器智能体（腾讯）
文心智能体（百度）
Dify
Fastgpt

开放式问题：谈谈你对Agent的理解

在Agent诞生之前，有两种方式能使机器智能化：

基于规则的方法：将人类指令转化成机器能理解的规则符号，这需要有丰富经验的人类专家，并且容错很低。
基于强化学习的方法：构建策略模型和奖励模型，需要大量的数据进行训练。

随着大模型的诞生，人类利用其在逻辑推理、工具应用、策略规划等方面的能力，构建以大模型为核心的Agent系统，极大的提升了机器的智能化程度。当然，为了进一步提升Agent的性能，还提出了CoT等规划方法、引入记忆和工具模块，使得Agent越来越逼近人类的思考方式。

从人机合作的角度出发，Agent 改变了人机合作的方式。截至现在，主要有三种模式：

人类主导：代表是SaaS+AI模式，人类完成大多数工作，而AI只负责完成特定任务。例如AI只负责实现人脸识别、OCR等能力，嵌入到人类操作的SaaS软件中，其他功能AI不参与。
AI作为人类助手：代表是Copilot模式，AI可以随时辅助人类完成各种任务，不再局限于特定的功能。
AI主导：代表Agent模式，人类只负责提出需求，在AI负责完成的过程中，可能需要人类进行进一步的描述需求、点评AI生成内容质量、矫正AI理解等。而Agent正式通往AGI（Artificial General Intelligence）的必经之路。

你怎么对Agent进行分类

按照工作模型可以分为单Agent、多Agent和混合Agent三种。

单Agent：

特点：由一个独立的智能体构成，所有的决策和执行都集中在一个智能体上，没有与其他智能体的协调和通信需求，适用于单一任务或相对简单的任务。
优点：不需要处理多个智能体之间的协调问题，也不需要额外的资源来管理多个智能体。
缺点：难以处理复杂、多变的环境，并且如果Agent出现故障，整个系统都将瘫痪。
应用场景：比如专门用于进行市场分析调研的Agent。

多Agent：

定义：多个Agent协同工作，相互交流信息，共同完成更复杂的任务或目标。多个智能体在分布式环境中独立运行，每个智能体可以自主决策，需要处理智能体之间的通信、协调和竞争等问题。
优点：能够处理复杂、动态和多变的环境，可以完成单个智能体难以完成的任务。多个智能体之间可以相互协作，即使部分智能体出现故障系统仍然可以正常工作，鲁棒性强。能根据环境和任务需求动态调整，具有可拓展性。
缺点：需要大量的通信和协调来确保智能体之间的同步和协作。
应用场景：比如一家公司就可以视为一个多Agent系统，由Agent来扮演产品经理、UI设计师、研发工程师、测试人员、项目经理等角色。
例子：斯坦福小镇

混合Agent：

定义：Agent系统和人类共同参与决策过程，交互合作完成任务，强调的是人机协作的重要性和互补性。这种系统通常包含一个或多个智能体，以及与人类用户的交互接口。
优点：通过人类的参与，混合Agent系统可以更好地处理复杂和多变的任务，提高任务完成的质量和效率，灵活地调整人类和智能体的角色和任务分配，提供更个性化和人性化的服务。
缺点：开发难度和复杂度较高。
应用场景：医生和Agent可以共同进行病情诊断，Agent负责快速分析病人的医疗记录、影像资料等，提供初步的诊断建议；而医生则可以基于Agent的分析结果和自己的专业知识和经验，做出最终的诊断决定。

Planning是怎么实现的

目前Agent大部分的planning逻辑，是通过提示词（prompt），手动告诉 LLM 它该怎么思考、怎么分步执行的。实际系统里常常先通过人工/程序硬编码固定主干流程以及有严格要求的核心业务，再在需要模型能力的节点中（例如创新、总结、标注、推理等任务），通过 Prompt 来让模型做局部规划或执行，从而在灵活和可控之间找到平衡。

Prompt 更像“指导”或“原则”，让模型在这些原则内自由思考、制定和执行流程，适合需要灵活应变、创造性或自动化程度高的场景。
人工/程序硬编码的流程，适合高度可控、可预测、合规、安全的任务；这些场景往往我们不希望模型自由发挥。

举个例子，比如在电商系统中，身份信息验证不能出错，售后政策有明确规定，这些都适合人工编码。而智能客服则可以通过prompt指导LLM来进行回复。

CoT

思维链将复杂的问题分解为更简单的任务，逐步解决问题，使用CoT能在算数、常识和推理任务都提高了性能。但这会增加推理的时间。CoT可以分为Few-Shot 和Zero-Shot（Zero-Shot 只需要在prompt中加入“让我们一步步的思考”）两种。

ToT

在需要多步骤推理的任务中，引导语言模型搜索一棵由连贯的语言序列（解决问题的中间步骤）组成的思维树，而不是简单地生成一个答案。ToT框架的核心思想是：让模型生成和评估其思维的能力，并将其与搜索算法（如广度优先搜索和深度优先搜索）结合起来，进行系统性地探索和验证。对于每个任务，将其分解为多个步骤，为每个步骤提出多个方案，在多条思维路径中搜寻最优的方案。

ReAct

ReAct的任务解决轨迹是Thought-Action-Observation，可以简化为模型按照Reasoning-Acting框架。Reasoning包括了对当前环境和状态的观察，并生成推理轨迹。这使模型能够诱导、跟踪和更新操作计划，甚至处理异常情况。ReAct的每一个推理过程都会被详细记录在案，这也改善大模型解决问题时的可解释性和可信度；Acting在于指导大模型采取下一步的行动，比如与外部源（如知识库或环境）进行交互并且收集信息，或者给出最终答案。

Reflexion

Redlextion采用了强化学习的方法，Reflexion代理在生成每一个轨迹后，进行启发式评估，生成反思文本并保留在记忆缓冲区中，以诱导在随后的尝试中做出更好的决策。

你还了解哪些比较新的planning算法

我了解BabyAGI和AutoGPT

BabyAGI 使用一个“Task List”来管理所有待办任务。它有三个主要组件：

Task Creation Agent: 根据当前任务、执行结果，不断新建子任务。
Task Prioritization Agent: 对现有任务重新排序，决定执行顺序。
Execution Agent: 真正去执行当前的任务（通常是调用LLM/工具等）。

循环流程

从 “Task List” 中取出最高优先级的任务。
调用 Execution Agent 去执行。
把执行结果（Result）交给 Task Creation Agent，是否需要生成新的子任务？
把更新后的任务列表给 Task Prioritization Agent，排序并循环。

AutoGPT 也有一个任务/目标管理系统，也能生成子任务并执行。它侧重更丰富的“工具”支持，如联网、读取/写入文件、执行代码等，包含以下模块：

AI Config: 存放 AI 的角色、名称、目标等基础信息。
Memory: 把过去的重要信息存下来，供下一步参考。
Planner（或类似角色）: 生成下一步要干啥。
Command Executor: 解析 LLM 返回的命令，然后在外部执行相应操作。

介绍以下记忆模块

记忆模块是智能体存储内部日志的关键组成部分，负责存储过去的思考、行动、观察以及与用户的互动。

短期记忆关注于当前情境的上下文信息，是短暂且有限的，通常通过上下文窗口限制的学习实现。
长期记忆储存智能体的历史行为和思考，通过外部向量存储实现，以便快速检索重要信息。
混合记忆 -通过整合短期和长期记忆，不仅优化了智能体对当前情境的理解，还加强了对过去经验的利用，从而提高了其长期推理和经验积累的能力。

为什么要使用Memory-based agent

从认知心理学角度：对于人类的认知来说，记忆重要的模块，agent想要替代人类完成一些任务，就要表现的像人类，为agent设置代理模块。
从自我进化角度：在完成任务的过程中，agent也需要在与环境交互时自我进化。记忆能帮助agent积累经验、探索更多的环境、抽象出概括性信息以增强泛化性。
从agent应用角度：在很多应用中记忆是不可取代的，例如chatgpt、虚拟角色。

Function call

为什么要用function call？

以前的LLM只能依靠自己已有的知识回答问题，无法直接获取实时数据、也无法与外部系统交互。

Function Call 是一种实现大型语言模型连接外部工具的机制。通过 API 调用 LLM 时，调用方可以描述函数，包括函数的功能描述、请求参数说明、响应参数说明，让 LLM 根据用户的输入，合适地选择调用哪个函数，同时理解用户的自然语言，并转换为调用函数的请求参数（通过 JSON 格式返回）。调用方使用 LLM 返回的函数名称和参数，调用函数并得到响应。最后，如果需要，把函数的响应传给 LLM，让 LLM 组织成自然语言回复用户。

大模型的function call能力是如何获得的？

主要通过对基础模型进行sft获得，基础模型需要先具备良好的指令遵循和代码/结构化数据生成能力。

sft的核心思想，是要教会LLM两件事：

1、识别意图：理解用户的请求是否需要借助外部工具/函数来完成，而不是直接生成文本回答。

2、参数提取与格式化：如果需要调用函数，需要能够正确地从用户请求中抽取出所需的参数，并按照预先定义的格式（通常是json）生成函数调用的指令。

sft的过程如下：

步骤 1：数据集构建：构建包含 Function Calling 场景的指令微调数据集，每条数据样本包含用户输入（可能需调用函数或直接回答的请求）、可用函数 / 工具描述（函数用途、参数类型等结构化文本）、期望输出（需调用函数时为含函数名与参数的 JSON，否则为直接文本回答）。
步骤 2：选择基础模型：选用具备强大指令遵循能力的预训练大模型（如 Llama、GPT、Qwen 等）。
步骤 3：格式化训练数据：将 “用户输入” 与 “可用函数描述” 拼接为模型输入（Prompt），“期望输出”（JSON 函数调用或文本回答）作为目标输出（Completion/Target），通过特定分隔符或模板区分。
步骤 4：进行微调：使用标准 SFT 方法（全参数微调或 PEFT 如 LoRA）在数据集上训练，优化目标为最小化预测输出与期望输出的差异（如交叉熵损失），使模型学会根据输入与函数描述，决定直接回答或生成特定格式的函数调用 JSON。

通过上述监督微调流程，大模型掌握识别意图（判断是否需调用外部工具）与参数提取格式化（正确抽取参数并生成规范函数调用指令）的能力，从而获得 Function Call 能力。

Function - Call 数据集的基本结构包含哪些部分？

Function - Call 数据集基本结构通常包含：

[系统提示 / 全局指令]（可选）：设定角色、能力边界等。
[可用函数 / 工具描述区]：详细列出每个可用函数的结构化描述。
[对话历史]（可选，多轮对话重要）：记录用户（User）和助理（Assistant）的交互历史及当前用户请求。
[触发指令 / 分隔符]：提示模型开始思考或生成，如 “Assistant:”。

Function - Call数据集中可用函数/工具描述区的格式是怎样的？

通常使用JSON列表或结构化文本，包含以下核心字段：

[  {  "name": "函数名",  "description": "函数功能描述",  "parameters": {  "type": "object",  "properties": {  "参数名": {  "type": "数据类型",  "description": "参数含义描述"  }  },  "required": ["必填参数名列表"]  }  }  
]

例如：

{  "name": "get_weather",  "description": "查询指定城市和日期的天气信息",  "parameters": {  "type": "object",  "properties": {  "city": {  "type": "string",  "description": "需要查询天气的城市名称，例如：北京"  },  "date": {  "type": "string",  "description": "需要查询的日期，例如：今天、明天、2023 - 10 - 26"  }  },  "required": ["city", "date"]  }  
}

Function - Call数据集的关键要素有哪些？

name：函数的唯一标识符。
description：用自然语言清晰描述函数的功能和适用场景，是模型判断何时调用的关键。
parameters：定义函数接受的参数，包含：
- type：通常为"object"。
- properties：列出每个参数的名称、数据类型（如string、integer）和描述。
- required：必须提供的参数名称列表。

Function - Call数据集中对话流程的格式是怎样的？

用户请求：用户发出指令（如“帮我查一下明天上海的天气，然后给张三发邮件”）。
模型首次响应（Function Call）：模型识别后生成调用函数的JSON（如get_weather）。
外部执行：应用程序调用实际工具（如天气API）。
结果喂回模型：将工具执行结果格式化后再次输入模型（如天气结果{"temperature": "25°C", "condition": "晴朗"}）。
模型再次响应：可能再次调用函数（如send_email）或生成最终回答（如“已查询并发送邮件”）。

如何将下游工具、插件转化为模型可理解的方式？

核心是标准化描述和执行对接：

标准化描述（Standardized Description）：
- 为工具设计符合Function Call格式的结构化描述（如JSON Schema），包含唯一名称（Name）、功能描述（Description）、参数定义（Parameters）。
- 描述语言自然准确，避免歧义。
执行对接（Execution Bridging）：
- 将工具描述作为上下文传递给模型。
- 解析模型输出的Function Call JSON，调用实际工具，处理参数校验和结果，再将结果反馈给模型。

简述Function Call的工作原理

LLM接收用户提示：用户输入请求。
LLM决定所需工具：根据提示判断调用哪些工具。
程序处理调用请求：开发者实现逻辑，接收LLM的工具调用请求并准备参数。
执行函数调用：将带参数的函数调用传递给后端服务执行，结果再反馈给LLM用于后续处理。

HuggingGPT

HuggingGPT是由大型语言模型（LLM）驱动的，设计用来自主处理一系列复杂的人工智能任务。HuggingGPT融合了ChatGPT与HuggingFace。具体来说，LLM在这里扮演着大脑的角色，一方面根据用户请求拆解任务，另一方面依据任务描述选择适合的模型执行任务。通过执行这些模型并将结果整合到计划的任务中，HuggingGPT能自主完成复杂的用户请求。下图展示了从任务规划到模型选择，再到任务执行，最后是响应生成的完整流程：