【学习笔记】LLM Interview(Agent相关)
文章目录
- 0 Agent相关资料
- 0.1 Agent分类
- 0.2 Agent项目跟踪
- 0.2.1 热门项目
- 0.2.2 新兴的企业级框架
- 0.2.3 多智能体协作框架
- 0.2.4 生成式智能体
- 1 什么是Agent?讲讲你对它的理解
- 1.1 头部厂商对Agent的定义
- 2 Agent与LLM有何区别?
- 3 介绍一下Agent框架
- 3.1 Agent 常见设计框架
- 3.1.1 Anthropic
- 3.1.1.1 Workflow
- 3.1.1.2 Agent
- 3.1.2 OpenAI
- 3.1.2.1 单智能体系统
- 3.1.2.2 何时考虑使用多智能体系统?
- 3.1.2.3 多智能体系统
- 3.1.3 Google
- 3.1.3.1 模型
- 3.1.3.2 工具
- 3.1.3.3 编排层(Orchestration)
- 3.2 建议框架一:Agent 框架三种循环类型
- 3.2.1 手动 Agent 框架【白盒系统】
- 3.2.2 半自动 Agent 框架【灰盒系统】
- 3.2.3 全自动 Agent 框架【黑盒系统】
- 3.2.4 小结
- 3.3 建议框架二:Lilian Weng
- 3.4 总结
- 4 Agent Planning
- 4.1 整体分类方法
- 4.2 任务分解
- 4.2.1 核心思想
- 4.2.2.1 分解优先方法(Decomposition-First)
- 4.2.2.2 交替分解方法(Interleaved)
- 4.2.3 优势与挑战
- 4.3 多方案生成与选择
- 4.3.1 核心思想
- 4.3.2 两个关键步骤
- 4.3.2.1 多方案生成
- 4.3.2.2 最优方案选择
- 4.3.3 优势与挑战
- 4.4 外部规划器辅助
- 4.4.1 核心思想
- 4.4.2 两类外部规划器
- 4.4.2.1 符号规划器
- 4.4.2.2 神经规划器
- 4.4.3 优势与挑战
- 4.5 反思与优化(Reflection & Refinement)
- 4.5.1 核心思想
- 4.5.2 实现机制
- 4.5.2.1 反思过程
- 4.5.2.2 改进策略
- 4.5.3 优势与挑战
- 4.6 带记忆的规划(Memory-Augmented Planning)
- 4.7 总结
- 5 Agent 中 planning 能力的常用评估指标
- 5.1 正确性与精确度指标
- 5.2 效率与最优性指标
- 5.3 一致性与合理性指标
- 5.4 工具使用的评估指标
- 5.5 人机交互指标
- 6 Agent Memory
- 6.1 谈谈 Memory
- 6.2 Memory 定义
- 6.3 LLM-based Agent 需要 Memory 的必要性(为什么需要)
- 6.4 提升 Memory 的方法
- 6.4.1 Memory Sources(记忆来源)
- 6.4.2 Memory Forms(记忆形式)
- 6.4.3 Memory Operation(记忆操作)
- 6.4.4 小结
- 7 Memory 评估方法
- 7.1 直接评估
- 7.2 间接评估
0 Agent相关资料
推荐阅读:
- https://lilianweng.github.io/posts/2023-06-23-agent/
- OpenAI:A practical guide to building agents
- Anthropic:Build effective agents
0.1 Agent分类
- Autonomous Agent:通过自然语言的需求描述。能够自动化执行各项任务达成目标结果,必要时需要人为引导,具有明确的工具属性,以服务于人为目的,比如 Auto-GPT
- Generative Agent:模拟人类特征、具备自主决策能力以及长期记忆等,一种具有数字原生意义上的 AI-Agent,不以服务于人的需求为目的,比如斯坦福的虚拟小镇项目。
0.2 Agent项目跟踪
统计截至20250820
0.2.1 热门项目
- Auto-GPT【178K⭐】
- 项目地址:https://github.com/Significant-Gravitas/Auto-GPT
- 项目简要:Auto-GPT是一个实验性的开源应用程序,展示了 GPT-4 语言模型的功能。该程序由 GPT-4 驱动,将LLM思想链接在一起,以自主实现设定的任何目标,作为 GPT-4 完全自主运行的首批示例之一,Auto-GPT 突破了 AI 可能的界限。
- 核心特点:支持长期记忆、网络访问、文件管理等功能,采用 ReAct 框架进行任务分解和执行。
- BabyAGI【21.8⭐】
- 项目地址:https://github.com/yoheinakajima/babyagi
- 项目简介:此项目是一个 AI 支持的任务管理系统示例。该系统使用 OpenAI 和 Pinecone API 创建、优先级排序和执行任务。该系统背后的主要思想是基于先前任务的结果和预定义的目标创建任务,然后使用 OpenAI 的自然语言处理能力根据目标创建新任务,并使用Pinecone存储和检索任务结果以获得上下文。
- 核心特点:任务优先级管理、向量数据库存储、连续学习能力
- GPT Engineer【54.7⭐】
- 项目地址:https://github.com/AntonOsika/gpt-engineer
- 项目简介:此项目是一个简易的工具,可以根据要求生成代码。
- 核心特点:代码生成、项目结构创建、迭代开发管理
0.2.2 新兴的企业级框架
- Dify Agent 平台:
- 项目地址:https://github.com/langgenius/dify
- 项目简介:Dify 是一个开源的大模型应用开发平台,提供从 Agent 构建到 AI 工作流编排、RAG 检索、模型管理等能力。它融合了后端即服务(BaS)和 LLMOps 的理念,使开发者可以快速搭建生产级的生成式 AI 应用。
- 核心特点:可视化工作流编排、企业级 RAG 管道、丰富的集成能力、一站式 AI 应用开发平台
- TaskWeaver(Microsoft)
- 项目地址:https://github.com/microsoft/TaskWeaver
- 项目简介:代码优先的 Agent 框架,用于无缝规划和执行数据分析任务。该框架通过代码片段解释用户请求,高效协调各种插件形式的函数来执行数据分析任务,以有状态的方式运行。
- 核心特点:代码优先的设计理念,保持聊天历史和代码执行历史,支持复杂数据结构处理,反思性执行能力,插件化架构。
- Semantic Kernel(Microsoft)
- 项目地址:https://github.com/microsoft/semantic-kernel
- 项目简介:轻量级、开源的一个开发工具包,使得开发者轻松构建 AI 智能体并集成最新的 LLM 模型。它是一个模型无关的 SDK,开发者可以轻松构建、编排和部署 AI 智能体系统。
- 核心特点:多语言支持(.NET,Python,Java),模型无关设计,企业级安全和合规。
0.2.3 多智能体协作框架
- OpenManus:https://github.com/FoundationAgents/OpenManus,MetaGPT团队开发,原型3小时内即可启动,支持一行命令运行,集成了数据分析智能体,支持自定义添加多个智能体,支持浏览器自动化,MCP工具版本等多种应用。
- AutoGen:https://github.com/microsoft/autogen
- Langchain:https://github.com/langchain-ai/langgraph
0.2.4 生成式智能体
- Generative Agents(Stanford):
- 项目地址:https://github.com/joonspk-research/generative_agents
- 项目简介:斯坦福虚拟小镇演示源码,也是《Generative Agents:Interactive Simulacra of Human Behavior》的论文实现。该研究将 25 个 AI 智能体放在一个像素风格的虚拟小镇上,智能体之间可以实现人类生活行为的模拟交互,也可以与小镇所在环境发生交互,并且可以与虚拟世界外的人类产生交互。
- 核心特点:社会化交互模拟、长期记忆系统、believable human behavior,环境交互能力
- GPT Researcher:
- 项目地址:https://github.com/assafelovic/gpt-researcher
- 项目简介:该项目能够生成详细、客观、不带偏见的研究报告,并提供定制选项,以便集中关注相关资源、提纲和教训。受到 AutoGPT 和最近的 Plan-and-Solve 以及 RAG 论文的启发,GPT Researcher 解决了速度和确定性的问题,通过并行化代理工作而非同步操作,提供更稳定的性能和更快的速度。
- 核心特点:研究任务自动化、并行化处理、客观性报告生成、多源信息整合
- MetaGPT:
- 项目地址:https://github.com/geekan/MetaGPT
- 项目简介:MetaGPT式一个多代理框架,将不同 GPT 分配给不同角色,形成一个协作的实体来完成复杂任务。MetaGPT 接受一行需求作为输入,并输出用户故事/竞争分析/需求/数据结构/接口/文档等。它包含产品经理/架构师/项目经理/工程师等角色,提供了一个完整的软件公司和精心设计的标注操作程序。
- 核心特定:软件开发全流程模拟、角色专业化分工、标准化操作程序、文档自动生成。
- DevOpsGPT:
- 项目地址:[https://github.com/kuafuai/DevOpsGPT]
- 项目简介:用于 AI 驱动软件开发的多整体系统。将 LLM 和 DevOps 工具结合,将自动语言需求转换为工作软件。支持任何开发语言并扩展现有代码。
- 核心特点:DevOps 工具集成、端到端开发流程
1 什么是Agent?讲讲你对它的理解
开发题
- 究竟该如何定义 Agent,当下众说纷纭,每种说法都有自己的道理,接下来我会先整理头部厂家对 Agent 的定义,然后结合他们所讲与之前看的文档,尝试解释 Agent 到底是什么/
1.1 头部厂商对Agent的定义
-
OpenAI:《A practical guide to building agents》
-
Agents are systems that independently accomplish tasks on your behalf
-
智能体是一类能够自主替你完成任务的系统
-
认为工作流属于智能体(但有些人认为工作流不是智能体)
-
-
Lilian Weng:《LLM Powered Autonomous Agents》
-
In a LLM-powered autonomous agent system, LLM functions as the agent’s brain, complemented by several key components: Planning, Memory, Tool use. (2023.6)
-
在一个又 LLM 启动的自主智能体系统中,LLM 充当智能体的大脑,并辅以若干关键组件:规划、记忆、工作使用
-
-
Anthropic:《Building effective agents》
-
在Anthropic,我们将这些不同形态统称为 具备代理性 的系统(agentic systems),但在架构上对工作流和智能体做了重要区分:
-
工作流是指由预定义的代码路径来编排 LLM 和工具协作的系统
-
智能体则不同,它们让 LLM 能够自主动态地引导自身的流程和工具使用,并始终掌握任务完成的方式。
-
-
Google:《Agents》
-
生成式 AI 智能体可以定义为:它通过观察世界,并运用自身可支配的工具采取行动,以此来实现既定目标。
-
综述:
上面的定义都太复杂了,一个很简洁的说法就是:
Agent = LLM + Tools(大模型和工具的有机组合)
- Agent的本质其实很简单,AI 通过调用工具获得了与现实世界交互的能力,再通过交互产生反馈、循环优化最终完成任务。这是最核心的东西
- 所以在真正的开发实践种,其实只要在 LLM 外接工具,再加伤基础的循环逻辑,立刻就能跑起来。
- 至于后面那些复杂的调度(记忆、上下文管理),本质上都是选配,目的是为了使得 Agent 具备更加鲁棒的能力。
2 Agent与LLM有何区别?
-
LLM 是一种通过海量文本训练,掌握语言结构与语义的生成模型,能够进行语言理解与生成,但本身不具备自主行为能力,无法与动态环境交互,也不具备长期记忆或规划能力。本质上是一种模式预测器,通过上下文预测下一个单词,生成连贯文本,但其行为并无因果理解。
-
Agent是一个具有自主性的系统:能够感知环境、制定目标、执行行动、并能在必要时调整策略。可以理解为 LLM 是 Agent 的大脑,结合记忆模块、规划模块、工具使用接口等组件,形成可主动思考、分解任务、执行任务的系统。
对比:
LLM | Agent | |
---|---|---|
知识范围 | 知识仅限于训练数据 | 通过工具连接外部系统,能够在模型自带的知识之外,实时、动态扩展知识。 |
状态与记忆 | 无状态。每次推理都和上一次没关系,除非在外部给模型加上会话历史或上下文管理能力 | 有状态,自动管理会话历史,根据编排自主决策进行多轮推理 |
原生工具 | 无。 | 有,自带工具和对工具的支持能力。 |
原生逻辑层 | 无。需要借助提示词工程或使用推理框架(CoT、ReAct等)来形成复杂提示,指导模型进行预测。 | 有,原生认知架构,内置CoT,ReAct等推理框架,或LangChain编排框架 |
小结(来自《Agents》by Google):
- LLM 是能力强大的语言大脑,善于理解与生成自然语言
- Agent 是赋予 LLM 实践能力的行动体,它不仅可以看懂问题,还能主动计划、调用工具、执行任务、甚至根据反馈修正行动。
- 从架构角度看,Agent 本质上是一个融合了 LLM 的多模块系统,包括规划、记忆、工具调用、安全控制等。
3 介绍一下Agent框架
目前,关于 Agent的框架设计标准,呈现百花齐放的态势。文中展现设计框架分类,是一些大厂的分类。大家阅读后,选择性接收。
3.1 Agent 常见设计框架
3.1.1 Anthropic
Anthropic 把涉及到智能体的内容统一叫为:agentic systems,在细节处对 Workflow 和 Agent 做出了重要的架构区分, 因此二者属于两类不同的系统:
-
Workflow:通过预定义的代码路径来编排大模型和和工具
systems where LLMs and tools are orchestrated through predefined code paths.
-
Agent:大模型动态决定自己的流程及使用什么工具,自主控制如何完成任务
systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks
3.1.1.1 Workflow
-
提示链(Prompt Chaining):提示链将任务分解为一系列顺序的子任务
-
每个 LLM call 处理前一个 LLM call 的输出
-
可以在中间任何步骤添加检查点(即 Gate),以确保任务处于正轨
-
-
路由(Routing):通过路由对输入进行分类,并将其转发到专门的后续任务(specialized followup tasks)
- 将任务的关注点进行拆解,从而针对每个具体任务设计和调整提示词。
- 否则,(all-in-one)提示词不仅很长,而且针对任何一种任务的提示词优化都可能导致其他任务的性能下降。
-
并行化(Parallelization):多个任务同时进行,然后对输出进行聚合处理。考虑两个场景。
- 分段(Sectioning):类似MapReduce,将任务分解为独立的子任务并行运行,最后对输出进行聚合。
- 投票(Voting):相同的任务并行执行多次,以获得多样化输出。
-
编排者—工作者(Orchestrator-workers):
在这种 Workflow 中,一个中心式的 LLM 动态地分解任务,将其委托给 worker LLM,并汇总它们的结果。
-
评估者—优化者(Evaluator-optimizer):一个 LLM call 生成响应,而另一个提供反馈和评估,形成闭环。
3.1.1.2 Agent
Agent 一般从下面场景收到任务并开始执行:
-
收到明确的人类指令
-
与人类交流到一定程度时,理解了自己接下来应该做什么
一旦任务明确,Agent 就会独立规划和执行,中间也可能会问人类一些问题,以获取更多信息或帮助它自己做出正确判断。
-
在 Agent 执行过程中,对它来说最重要的是每一步执行之后,都能从环境中获得真实信息(例如工具调用或执行代码),以帮助它评估任务的进展。
-
Agent 可以在检查点或遇到障碍时暂停,然后向人类获取帮助
-
任务通常在完成时终止,但也可以包括停止条件(例如最大迭代次数),以避免 Agent 行为不可控。
在实现 Agent 时,建议遵循三个核心原则:
- Agent 设计的简洁性。
- Agent 工作过程的透明性,例如能明确显示 Agent 的规划和步骤
- 通过完善的文档和测试,精心设计 Agent 与计算机之间的接口(agent-computer interfaces,ACl)
小结:
- 不管是 workflow 还是 agent,都是一种模式,而不是规范,开发者可以组合和改造这些模式来实现自己的 AI 系统,成功的关键,是能衡量系统的性能,然后不断对实现进行改进和迭代。
- 大模型领域的成功不是构建最复杂的系统,而是构建符合需求的系统。从简单的提示词开始,不断评估和优化,只有在简单的解决方案解决不了问题时,才应该考虑引入 multi-step agentic systems
3.1.2 OpenAI
OpenAI把框架设计成为编排(Orchestration),共分为两类:
- 单智能体系统:由一个配备了适当工具和指令的模型在循环中执行工作流
- 多智能体系统:在多个互相协调的 Agent 之间执行工作流
3.1.2.1 单智能体系统
单 Agent 可以通过逐步添加工具来处理许多任务,这样可以控制复杂性,简化评估和维护
每个编排方法都需要“运行”的概念,通常实现为一个循环,让智能体一直运行,直到满足退出条件。常见的退出条件包括工具调用、特定的结构化输出、错误或达到最大轮数。
3.1.2.2 何时考虑使用多智能体系统?
一般建议是:优先充分发挥单智能体系统的能力。
以下是常见需要拆分 Agent 的两个参考标准:
- 逻辑复杂:当提示词中包含大量的条件判断(如多个 if-then-else 分支),或模板逻辑变得难以维护时,建议按逻辑片段将任务拆分给不同 Agents 分别处理。
- 工具过载:问题不在于工具数量本身,而在于它们之间的相似度和重叠度。有些系统能成功管理 15 个以上定义清晰的工具,而另一些则在不到 10 个模糊重叠的工具中就出现混乱。
3.1.2.3 多智能体系统
多智能体系统可以根据不同的业务流程和场景需求,设计出各种结构。
但从实际客户经验来看,我们总结出两种通用、可落地的设计模式:
-
管理者模式(Agent 作为工具本身),由一个中心 Agent 担任管理者角色,通过工具调用的方式调度多个专职 Agent,每个 Agent 负责一个具体任务或领域。
-
去中心化模式(Agent 之间相互交接):多个 Agent 平行运行,彼此间根据各自专长进行任务接力和分工协作:
多 Agent 系统可以抽象为一张计算图,图中节点表示 Agent,在管理者模式中,连线表示工具调用;在去中心化模式中,连线表示任务的转交和流转。
3.1.3 Google
Agent架构中有三个核心组件:
3.1.3.1 模型
这里指的是用作 Agent 中做核心决策的语言模型:
- 可以是一个或多个任何大小的模型,能够遵循基于指令的推理和逻辑框架,如 ReAct、chain-of-Thought、Tree-of-Thoughts
- 可以是通用的、多模态的,或根据特定 Agent 架构的需求微调得到的模型。
- 可以通过 能展示 Agent 能力的例子或数据集 来进一步微调模型,例如 Agent 在什么上下文中使用什么工具,或者执行什么推理步骤。
3.1.3.2 工具
基础模型在文本和图像生成方面非常强大,但无法与外部世界联动极大限制了它们的能力。 工具的出现解决了这一问题。有了工具,Agent 便能够与外部数据和服务互动,大大扩展了它们的行动范围。
工具可以有多种形式,常见是 WebAPI方式,即 GET、POST、PATCH和 DELETE 方法。例如,结合用户信息和获取天气数据的 tool,Agent 可以为用户提供旅行建议。
有了工具,Agent 可以访问和处理现实世界的信息,这使它们能够支撑更专业的系统,如 RAG,显著扩展了 Agent 的能力。
3.1.3.3 编排层(Orchestration)
编排层描述了一个循环过程:Agent 如何接收信息,如何进行内部推理,如何使用推理结果来指导其下一步行动或决策。
- 一般来说,这个循环会持续进行,直到 Agent达到其目标或触发停止条件
- 编排层的复杂性跟 Agent 及其执行的任务直接相关,可能差异很大。例如,一些编排就是简单的计算和决策规则,而其他的可能包含链式逻辑、额外的机器学习算法或其他概率推理技术
3.2 建议框架一:Agent 框架三种循环类型
- 参考资料:https://mp.weixin.qq.com/s/0X58GZqPHbN9Sw5begW__w
目前,大厂对 Agent 框架的分类方法各有不同,有的强调技术栈(如基于 LLM 的、基于规则的),有的强调功能定位(如对话型、任务型、工具调用型),还有的从交互模式来区分(如单体 Agent与多 Agent 协作)
这些分类方法各有价值,但往往存在边界模糊,定义不一的问题。相比之下,通过系统可控性与自动化程度为标准来划分,更直观也更便于理解。
基于这一思路,可以将 Agent 框架分为三类:
-
手动 Agent 框架(白盒系统):类似 workflow
-
半自动 Agent 框架(灰盒系统):类似 multi-agent
-
全自动 Agent 框架(黑盒系统):类似 single-agent
这种分类方式不仅能体现系统的“黑箱程度”,也能帮助我们更清晰地理解不同Agent 在实际应用中的定位与适用场景。
3.2.1 手动 Agent 框架【白盒系统】
开发者预先设定好任务执行的每一步计划,明确规定哪个步骤使用哪个工具,LLM 主要负责在预设节点上填充内容或做简单决策。
它是一个白盒系统,可以称之为工作流
Dify 和 Coze 就是典型的代表,能够提供可视化流程编排工具。此时 Tools 的执行步骤,在很多时候是被人强制执行的,以此换取更多的确定性。
企业中目前还是以 workflow 为主,因为可控。
3.2.2 半自动 Agent 框架【灰盒系统】
将 AI 预设为不同身份的垂直 Agent(系统提示词+特定工具),每个垂直 Agent 完成不同的子任务,最后通过框架将每个子任务的执行过程和结果组合起来,完成最终目标。
我称之为 Multi-Agent System(多 Agent 系统),它是一个灰盒系统。
Manus 和扣子空间的规划模式就是典型的多 Agent 框架。规划和记忆管理都属于编排的一部分。
3.2.3 全自动 Agent 框架【黑盒系统】
只给模型设定一个最终目标,模型接收到目标就开始自我循环,直到完成目标或遇到无法解决的障碍。
全自动 Agent 框架是最简洁的,调用工具的那几行代码,就是其全部的核心了,复杂过程全部交由模型去解决。
我称之为 Single-Agent System(单 Agent 系统),也就是所谓的通用 Agent,它是一个黑盒系统。
3.2.4 小结
可以将 Agent 框架分为以上三类(手动、半自动、全自动),但是这三种框架并非对立,而是可以组合使用。比如 multi-agent 系统可以和 workflow 相结合,single-agent 系统也是其他两者的重要组成部分。
3.3 建议框架二:Lilian Weng
- 参考资料:https://lilianweng.github.io/posts/2023-06-23-agent
在一个由LLM驱动的自主系统中,LLM 充当 Agent 的大脑,并辅以几个关键组成部分:
-
规划(Planning)
- 子目标与分解(Subgoal and decomposition):Agent 将大型任务分解为更小、更易于处理的子目标,从而实现对复杂任务的高效处理。
- 反思与完善(Reflection andrefinement):Agent 可以对过去的行动进行自我批评和自我反思,从错误中吸取教训,并为未来的步骤进行改进,从而提高最终结果的质量。
-
记忆(Memory)
- 短期记忆(Short-term memory):所有上下文学习都是利用模型的短期记忆来学习
- 长期记忆(Long-term memory):这为 Agent 提供了在长时间内保留和回忆(无限)信息的能力,通常通过利用外部向量存储和快速检索来实现。
-
工具的使用(Tooluse)
- Agent 会调用外部 API 获取模型权重中缺失的额外信息(预训练后通常很难改变),包括当前信息、代码执行能力、访问专有信息源等。
3.4 总结
-
Anthropic:
- 把涉及到智能体的内容统一叫为:agentic systems
- 在细节处对 Workflow 和 Agent 做出了重要的架构区分
- Workflow:通过预定义的代码路径来编排大模型和工具
- Agent:大模型动态决定自己的流程及使用什么工具,自主控制如何完成任务
-
OpenAl
- 把框架设计成为编排(Orchestration),共分为两类:
- 单智能体系统:由一个配备了适当工具和指令的模型在循环中执行工作流。
- 多智能体系统:在多个互相协调的 Agent 之间执行工作流。
- 把框架设计成为编排(Orchestration),共分为两类:
-
Google:Agent架构中有三个核心组件:模型、工具和编排层。
-
建议框架一:Agent 框架可以根据系统可控性与自动化程度分为三类
-
建议框架二(Lilian Weng):在一个由LLM驱动的自主系统中,LLM充当 Agent 的大脑,并辅以几个关键组成部分——规划、记忆和工具使用
4 Agent Planning
参考论文:Understanding the planning of LLM agents: A survey
文章中针对大语言模型驱动的智能体的规划能力(planning ability)进行全面系统的综述。论文首次以规划能力为核心,提出了完整的分类体系,并对各类方法进行了深度分析。
4.1 整体分类方法
作者构建了一个五大类的规划方法分类体系:
- 任务分解(Task Decomposition):将复杂任务拆成多个子任务后逐步规划
- 生成并选择多条计划(Multi-plan Selection):LLM 生成多个可能方案,再进行优选
- 外部规划器辅助(External Planner-Aided Planning):将任务形式化后,借助传统符号规划器或神经规划器处理。
- 反思与优化(Reflection & Refinement):通过生成-反馈-改进的循环增强规划质量。
- 带记忆的规划(Memory-Augmented Planning):通过引入记忆机制(如检索或调优)提高规划效果。
4.2 任务分解
4.2.1 核心思想
采用分而治之的策略,将复杂的多步骤任务分解为更简单、更易管理的子任务。
4.2.2.1 分解优先方法(Decomposition-First)
- 工作流程:首先完整分解任务,然后逐一规划子任务
- 代表方法:
- HuggingGPT:将多模态任务分解为子任务,明确任务间依赖关系,协调不同型协作
- Plan-and-Solve:改进零样本CoT,用先制定计划,再执行计划的两步提示
- ProgPrompt:将自然语言任务转化为编程问题,通过函数调用实现规划
4.2.2.2 交替分解方法(Interleaved)
- 工作流程:动态交替进行任务分解和子任务规划
- 代表方法:
- Chain-of-Thought(CoT):通过逐步推理链引导复杂问题解决
- ReAct:交替进行推理(Thought)和行动(Action),解耦思考和执行
- PAL/POT:结合编程能力,将推理过程形式化为代码执行
4.2.3 优势与挑战
- 优势:降低复杂任务难度,提高可解性
- 挑战:分解粒度控制、上下文长度限制、错误传播问题
4.3 多方案生成与选择
4.3.1 核心思想
生成多个候选规划方案,通过搜索算法或评估机制选择最优方案。
4.3.2 两个关键步骤
4.3.2.1 多方案生成
- 采样策略:利用解码过程的不确定性(温度采样、topk采样)
- 显式生成:通过提示工程明确要求生成多个方案
- 代表方法:
- Self-consistency:对同一问题采样多个推理路径
- Tree-of-Thought:构建思维树结构,支持采样和提议两种生成策略
4.3.2.2 最优方案选择
- 投票机制:Self-consistency采用多数投票
- 树搜索:ToT 支持 BFS/DFS 等传统搜索算法
4.3.3 优势与挑战
- 优势:扩展搜索空间,提高方案质量和鲁棒性
- 挑战:计算成本显著增加,LLM评估能力有限,随机性影响一致性
4.4 外部规划器辅助
4.4.1 核心思想
结合 LLM 的语义理解能力与专门规划器的高效性和可靠性。
4.4.2 两类外部规划器
4.4.2.1 符号规划器
-
工作机制:LLM 负责任务形式化,符号规划器生成方案
-
代表方法:
-
LLM+P:将任务转换为PDDL格式,使用Fast-Downward求解器
LLM+P介绍:
- 三阶段管道:①自然语言→PDDL转换 ②使用Fast-Downward求解器规划 ③PDDL结果 →自然语言翻译
- 挑战:需要准确的PDDL建模,对复杂领域适应性有限
- 什么是PDDL:PDDL(Planning Domain Definition Language)是人工智能规划领域的标准语言,用于描述规划问题。
-
LLM-DP:针对动态环境,结合BFS求解器
LLM-DP介绍:
- 创新点:处理不完整信息环境下的动态规划;LLM生成多个可能的世界状态,规划器为每个状态生成计划。
- 适应性:能够根据环境反馈动态调整规划。
-
4.4.2.2 神经规划器
-
工作机制:结合轻量级神经网络的领域特定规划能力
-
代表方法:
-
SwiftSage:基于双过程理论,快思考(Decision Transformer)& 慢思考(LLM 推理)
介绍:
- 理论基础:基于认知心理学的双过程理论
- 快思考:直觉响应
- 慢思考:深度推理
- 自适应切换:根据执行结果动态选择思考模式
-
4.4.3 优势与挑战
- 优势:理论完备性、稳定性、可解释性强
- 挑战:需要准确的任务形式化,领域适应性限制
4.5 反思与优化(Reflection & Refinement)
4.5.1 核心思想
通过自我反思和错误分析来迭代改进规划质量,类似语言层面的强化学习
4.5.2 实现机制
4.5.2.1 反思过程
- 错误检测:识别规划执行中的失败点
- 原因分析:分析失败的根本原因
- 经验总结:提炼可用于后续规划的经验教训
4.5.2.2 改进策略
- 代表方法
- Self-Refine:生成-反馈-改进的迭代循环
- Reflexion:扩展ReAct,加入轨迹评估和自我反思
4.5.3 优势与挑战
- 优势:提高容错能力,支持从失败中学习
- 挑战:文本更新的收敛性缺乏理论保证,可能陷入循环反思
4.6 带记忆的规划(Memory-Augmented Planning)
利用外部记忆模块存储和检索信息:
- RAG:Generative Agents,MemoryBank,MemGPT等
- 具身记忆:通过参数微调嵌入历史经验
- 权衡:RAG方法灵活实时但依赖检索效果;微调方法容量大但更新成本高
4.7 总结
类别 | 核心思想 | 优势与挑战 |
---|---|---|
任务分解 | 分解复杂任务,逐步规划 | 可提升性能,但上下文长度与计算成本限制 |
多方案生成与选择 | 生成多计划并优选 | 探索能力强,代价高,选择机制需优化 |
外部规划器辅助 | LLM形式化任何,符号/神经规划器处理 | 结合统计与符号优势,方向明确 |
反思与优化 | 循环生成、反思、改善计划 | 增加容错,但缺少理论收敛保障 |
带记忆的规划 | 引入RAG或微调,记忆辅助规划 | 提升记忆能力,成本与检索准确性仍是挑战 |
5 Agent 中 planning 能力的常用评估指标
评估 Agent 的 planning 能力,是衡量其实际应用价值的关键环节。本文将介绍一套较为全面的指标体系,涵盖从基础的成功率到更高级的人机交互质量等多个维度,用于衡量 Agent 的规划水平。
Planning 能力的评估可以分为五个关键指标:正确性与精确度、效率与最优性、一致性与合理性、工具使用,以及人机交互。
对于垂类 Agent 可以增加自定义的指标
5.1 正确性与精确度指标
正确性的目标在于评估智能体是否能够准确、无误地完成任务,这是最基本的评估维度。常见的衡量指标是成功率(SR),可细分为:
-
响应成功率(Response Success Rate):衡量智能体文本回答与标准答案的一致性。
- 例如,在 WebArena: A Realistic Web Environment for Building Autonomous Agents 中,通过计算三个实例化函数——
exact_match
、must_include
、fuzzy_match
,来评估预测结果与答案的一致程度
- 例如,在 WebArena: A Realistic Web Environment for Building Autonomous Agents 中,通过计算三个实例化函数——
-
步骤成功率(Step Success Rate):衡量预测的单步动作与专家标注的一致性。
- 在 Mind2Web 中,用于评价预测单步动作与人工标注动作的一致性
- 在 FlowBench 中,则通过 GPT-4 与预设的评分模板直接对轨迹的正确性进行打分。
-
基于状态的成功率(State-Based Success Rate):由于达成目标的路径可能不唯一,一些指标基于环境状态进行评估,以解决路径多样性的问题
- 例如,最终状态成功率(final-state SR)通过在程序执行过程中构建最终状态检查点,来判断环境是否达到预期状态。
- 另一些指标则关注中间检查点的得分,如 TheAgentCompany 提出的 Partial Completion Score,用于检测中间子任务是否完成。
5.2 效率与最优性指标
除了基本的成功率外,planning 还强调执行效率与规划结果的最优性这类指标主要包括:
- 执行效率指标(Execution Efficiency Metrics):衡量执行计划过程中的操作经济性,例如完成任务所需的动作数量
- 在 LangSuit·E 中表现为 Average Steps(平均步骤数),在 PARTNR 中则为 Simulation Steps(模拟步骤数),其原则是越少越好。
- 规划最优性(Plan Optimmization):进一步评估在可行方案中,所选择的计划是否在任务标准下最小化了资源消耗。
- 典型框架如 PlanBench 在研究中涉及的方法,在生成计划的同时,额外引入了Cost-optimal Planning(成本最优规划),每个规划动作都附带一个成本。这个成本可以映射为执行时间、钱等常识概念。
5.3 一致性与合理性指标
此类指标旨在确保生成的计划不仅符合用户指令,还能满足环境约束从而在现实场景中具备可行性。
- 约束满足性(Constraint Satisfaction):关注计划在客观条件下的技术可行性。
- 环境约束遵守度(Environmental Constraint Adherence)用于评估计划是否遵守外部限制。ChinaTravel 引入了 Environmental Pass Rate,用于衡量对预设环境约束的满足度。
- 同时,动作可执行性(Action Executability)用于评估每一步计划是否能在给定的动作集合中实现。OpenGrounded Planning 提出了 executableness 指标,以验证计划步骤是否存在于动作库中。
- 认知连贯性(Cognitive Coherence):关注计划是否符合人类常识性推理及逻辑一致性
- 常识一致性(Commonsense Alignment)衡量计划是否符合日常人类预期和直观合理性
- 逻辑一致性(Logical Coherence)则评估计划步骤之间是否逻辑自治、无矛盾。
5.4 工具使用的评估指标
为了系统评估大模型的工具使用能力,可进一步细分为工具调用精度(Tool Invocation Precision)
其核心在于评估智能体是否能够正确选择和操作外部工具,包括识别正确的接口元素并填写必要参数。
- 工具选择准确率(ToolSelection Accuracy):衡量任务中是否选择了正确的工具。TaskBench 使用 Node F1和 Edge F1 来评估。
- 参数填充准确率(Parameter Specification Accuracy):评估智能体在调用工具时是否正确填写了参数。TaskBench 提出了 Parameter Name F1与 Parameter Name-Value Pair F1以衡量参数生成的准确性
5.5 人机交互指标
从用户体验的角度,衡量规划系统的整体性能与实际应用价值。其重点在于体现技术之外的 可用性、认知负担与用户满意度 等关键因素,这些最终决定了系统在现实中的采纳与效果。
常见维度包括:协作流畅性、解释清晰度等。
6 Agent Memory
6.1 谈谈 Memory
- 参考来源:https://lilianweng.github.io/posts/2023-06-23-agent/
记忆可以定义为获取、存储、保留和后续检索信息的过程
人脑中有几种类型的记忆?
-
感知记忆(Sensory memory):这是记忆的最早阶段,能够在原始刺激结束后保留感觉信息(视觉、听觉等)的印象能力。感觉记忆通常只持续几秒钟。子类包括图像记忆(视觉)、回声记忆(听觉)和触觉记忆(触感)
-
短期记忆(Short-term memory)或工作记忆(Working Memory):它存储我们目前意识到并需要进行复杂认知任务(如学习和推理)所需的信息。短期记忆被认为具有大约7个项目的容量(Miler 1956),并持续 20-30 秒。
- Short-term memory is believed to have the capacity of about 7 items (Miller 1956) and lasts for 20-30 seconds.
- 人在短期记忆中能同时保留的信息数量是有限的,
- 这里的item并不一定是一个单一的字或数字,而是一个有意义的单位。比如电话号码138-246-802,我们往往会把它分成三段来记(138/246/802),每一段就算作一个item。
- 这个结论来自心理学家 George A.Miller 在 1956 年的经典研究,也被称为神奇的数字 7±2
-
长期记忆(Long-term memory):长期记忆可以将信息存储在一个非常长的时间内,从几天到几十年不等,并且具有几乎无限的存储容量。
长期记忆有两个子类型:
- 显性/陈述性记忆(Explicit/declarative memory):这是指事实和事件的记忆,指的是那些可以有意识地c回忆起来的记忆,包括情景记忆(事件和经历)和语义记忆(事实和概念)
- 隐式/程序性记忆(lmplicit/procedural memory):这种记忆是无意识的,涉及到自动执行的技能和例行公事,比如骑自行车或者键盘打字。
Agent 中挑战比较大的就是长期记忆如何处理?
6.2 Memory 定义
我们可以从狭义和广义两个层面定义 Agent 的 Memory:
- 狭义 Memory:一般指那些在当前会话或任务中临时存储与检索信息的模块,比如上下文片段、短期记忆,这通常通过文本形式(如对话历史)存在。
- 广义 Memory:涵盖更长时间跨度、跨会话的经验、知识和外部资源,例如 Agent 自学得到的经验、外部知识库或参数化记忆等。
6.3 LLM-based Agent 需要 Memory 的必要性(为什么需要)
- 认知心理学视角:人类通过记忆积累经验、抽象知识、形成行为习惯。Agent 若要具有人类般的认知能力,其设计自然应借鉴记忆机制。
- 自我进化角度:
- 经验积累:记住失败或错误的策略,有助于未来做得更好
- 环境探索:记忆帮助更好地选择探索策略,如优先尝试失败过的行动
- 知识抽象:从原始观测中抽象出更高层次的信息,从而提升泛化与适应能力
- 实际任务应用视角:
- 对话 Agent 需要记住以前的对话内容才能保持上下文连续性
- 模拟 Agent(如角色扮演场景)需要保持角色一致性,不会偏离设定
6.4 提升 Memory 的方法
我们从 Memory Sources,Memory Forms,Memory Operations 三个维度来寻找提升方案。
6.4.1 Memory Sources(记忆来源)
Agent 的记忆来源主要有三类:
- Within-trial memory(任务内记忆)
- 指在一次任务或会话中的临时信息,比如用户刚输入的上下文、临时推理轨迹
- 类似人类的短期记忆。
- 常见应用:对话 Agent 的即时上下文维护。类似一个 session 中,维护的上下文内容
- Cross-trial memory(跨任务/跨会话记忆)
- 能够跨越不同任务或会话保存信息,比如用户的偏好、历史任务记录
- 类似人类的长期记忆
- 常见应用:多轮交互系统、长期用户画像。类似一个用户多次在一个 Agent 中交互内容
- External knowledge memory(外部知识记忆)
- 借助外部数据库、文档库、RAG 来扩展 Agent 的知识范围
- 避免把所有信息都放进模型参数或对话历史里,降低计算和存储负担
- 常见应用:企业知识库问答、代码文档检索
6.4.2 Memory Forms(记忆形式)
两种主要形式:
- Non-parametric memory(非参数化记忆):
- 信息以显式的文本/向量形式存储在外部例如 KV 缓存、向量数据库、记忆日志。
- 优点:透明、可解释、易更新、可控
- 缺点:需要额外的检索机制(如语义搜索),效率受限。
- Parametric memory(非参数化记忆):
- 信息存储在模型参数内部,例如通过 fine-tuning,LoRA或 memory-augmented training。
- 优点:调用效率高,能直接被模型使用。
- 缺点:更新代价大(需要再训练),不易解释,存在遗忘或污染的风险。
实际系统里通常结合两者:
- 短期 & 灵活信息 → 非参数化存储(vector DB+检索)
- 稳定 &高频知识 → 参数化存储(fine-tuning 融入模型)
6.4.3 Memory Operation(记忆操作)
这部分是 Memory 的核心部分,涉及 写入 → 管理 → 读取 三阶段
- Memory Writing(写入):
- 写什么?是保存所有对话内容,还是只存关键信息?
- 什么时候写?实时写入、定期写入、还是触发式写入(如用户强调记住这个)
- 写入策略(建议):
- 可包含压缩(Summarization),embedding化,过滤无关信息
- Memory Management(管理):
- 挑战:记忆会不断膨胀,带来成本和噪声
- 方法:
- 剪枝(forgetting)、聚合(clustering/summarization)、分层管理(short-term + long-term + episodic memory)
- 目标:避免记忆污染,保证存储的知识相关可用
- Memory Reading(读取):
- 检索机制:关键词检索、语义检索、混合检索。
- 增强方法:结合注意力机制、RAG、或者记忆分层结构。
- 挑战:如何确保检索到的信息既准确又与当前任务高度相关,避免错误回忆
6.4.4 小结
实现路径主要有三方面:
- 来源:Memory 可以来自任务内上下文、跨会话长期信息,以及外部知识库。
- 形式:既可以用非参数化的显式存储(如向量数据库),也可以用参数化的方式直接融入模型参数,实际往往结合使用。
- 操作:包括写入(决定保存什么/何时保存)、管理(压缩、筛选、分层)、读取(通过检索或注意力机制调用),这是 Memory 效果能否真正落地的关键。
- 例如:在一个长期对话 Agent 中,短期上下文可以放在缓存里,长期偏好放进向量数据库,稳定的知识通过 fine-tuning 存到模型里;这样 Agent 既能快速响应,又能长期记住用户的习惯。
7 Memory 评估方法
参考来源:http://arxiv.org/abs/2404.13501
- 直接评估:将 Memory 模块作为独立组件进行性能测试
- 间接评估:基于下游任务性能反推 Memory 组件的性能
7.1 直接评估
- 主观评估:
- 通过人工打分或专家评审,衡量 memory 模块提供的信息是否符合人类判断的合理性与价值。
- 一致性(Coherence):Memory 召回的内容是否与当前场景自然匹配
- 合理性(Rationality):Memory 内容本身是否逻辑合理、事实正确
- 通过人工打分或专家评审,衡量 memory 模块提供的信息是否符合人类判断的合理性与价值。
- 客观评估(Objective Evaluation)
- 采用客观量化指标,如准确率、召回率等,用于评估 memory 在特定任务中的表现。
- 结果正确率(Result Correctness):基于记忆回答问题的准确性
- 参考召回率(ReferenceAccuracy):能否精准定位到相关记忆片段
- 效率指标(Time & HardwareCost):时间成本和计算开销
- 采用客观量化指标,如准确率、召回率等,用于评估 memory 在特定任务中的表现。
7.2 间接评估
通过 agent 执行任务来检验 memory 的效用,包括以下几类典型任务场景:
- 对话:评估agent 能否在多轮对话中利用 memory 保持一致性与相关性
- 多源问答:考量 memory是否能从多渠道提取、整合信息来回答问题
- 长上下文应用:测试 agent 在极长交互历史中对信息的理解与利用
- 其他任务:根据具体应用场景,通过完成任务的成功率、效率等指标来间接评估 memory 的实用性