前沿重器
栏目主要给大家分享各种大厂、顶会的论文和分享，从中抽取关键精华的部分和大家分享，和大家一起把握前沿技术。具体介绍：仓颉专项：飞机大炮我都会，利器心法我还有。（算起来，专项启动已经是20年的事了！）
2024年文章合集最新发布！在这里：再添近20万字-CS的陋室2024年文章合集更新
往期回顾
前沿重器[74] | 淘宝RecGPT：大模型推荐框架，打破信息茧房
前沿重器[75] | 腾讯元宝重磅出击：Agentic RAG如何让搜索“重生”
前沿重器[76] | 让小BERT学会思考——美团大模型蒸馏新框架
前沿重器[77] | 美团WOWService（上）：四阶段训练打造高质量可维护的对话模型
前沿重器[78] | 美团WowService（下）：多智能体和评估实现闭环
量子位在前几天将2025称为Agent元年，我是认可的，2025的从技术发展到落地雏形，我们有目共睹。前面有提到过Agent的重要性（心法利器[147] | Agent，是大模型落地的殊途同归），也受到这位大佬的文章的启发（https://zhuanlan.zhihu.com/p/1983512173549483912），最近就聊一聊Agent的那些关键的技术要点以及对未来的展望。（PS：大模型工具起的标题还真不错）
要聊整体情况，就离不开一些关键的论文和博客，我先把一些我做了重点参考的文章放出来。
一篇比较早的Agent综述博客： https://lilianweng.github.io/posts/2023-06-23-agent/
以及他的翻译： https://zhuanlan.zhihu.com/p/704093024
今年3月份的Agent综述论文： https://arxiv.org/abs/2503.21460
以及他的翻译： http://zhuanlan.zhihu.com/p/1974120693932238820
最新版来到今年10月份的一篇长综述论文： https://arxiv.org/abs/2508.17281
可惜他没有看到翻译博客。
之所以要穿插，是因为，第一篇能以最直白的方式讲明白Agent的格式，但还是太早了，Agent的模式还没收敛，第二篇比第一篇更系统和完善，但他讲的内容可能覆盖范围不如第三篇，但是第三篇的面有过于广，Agent有些内容好像没必要覆盖这么多，所以我就综合3篇文章综合地讲讲。
这里只是大概以这些论文的信息作为参考，很多我们可能平时关心没那么多的模块我没有讲，想了解整个研究生态还是建议大家看看原论文。
目录：
Agent的概念和研究课题
Agent基本框架
Memory记忆
Planning规划
Action行动
Tool工具
回顾一下我的视角的Agent
我们该怎么做
展望
Agent的概念和研究课题
挺尴尬的，在这3篇论文里，都没有用严谨而直白的话来定义何为Agent，什么样的一个系统或者模式，能被称为Agent，而是很直接地开始去讲Agent这一个话题，包括他有关的研究工作。
通过这几篇文章的阅读，我是想这么定义的，可能并不要紧，但大家在讲Agent的时候，普遍是这么个事。
An LLM-based agent is an autonomous system that combines language model reasoning with memory, planning, external tool use, and (optionally) multi-agent collaboration to perform complex tasks in dynamic environments.
说白了，说白了就是一个能借助大模型来完成复杂任务的系统，这个概念很广，也很模糊，似乎把大模型所有的应用，都归纳进了这个范围里面来，这在研究层面做起来会有一些难度，但好处是，大模型应用的范式和思路，我们都能从里面找到了，这个海纳百川的概念里很可能有我们日常工作可能会用到的大模型使用技巧。
尽管如此，我们还是可以整理出Agent的生态，围绕Agent，我们主要有4个大的研究方向。
Agent内的主要技术方案，包括其核心模块与架构、模块协作模式以及自我演化的能力。
评估和工具。这里包括Agent的benchmark和数据集，以及工具的触发应用、构建以及实际开发。
Agent的现实问题。如安全、隐私、社会影响等。
应用。Agent在多个场景的应用。
Agent基本框架
早期的Agent基本就被定义成这个结构，即工具、记忆、规划、Action这个模块，如下图所示。
Memory，是一个记录整个推理流程、多轮对话流程的工具，通过记忆，能让大模型在多次交互中，仍然能够不忘记任务本身以及其他关键信息。
Planning是规划器，他更多是用来做后续的任务规划，对复杂任务，他能规划具体的行动路径（毕竟复杂任务可能并非一步就能完成），还能在任务执行出现异常时考虑到补救措施，逐步引导最终完成任务。
Action是基于Planning来执行的行动器，他能在Planning模块的指令下，去调用必要的工具完成实际任务。
Tool是工具，能完成一些特定任务，例如一些数值的计算、某个数据库的搜索等。
后续有了更丰富的概念，并且也有很多玩法，我分别举几个例子。
早年的Memory是多轮对话系统中的记忆模块，而在Agent中，已经形成一个知识库的概念，里面可以是对话记忆，在销售Agent内可以是商品知识库，在旅游Agent内则可以是旅游笔记库，在陪伴聊天Agent中可以是用户画像记录等等，这不单纯是个记忆，而是一个数据库、信息库的代称了。（PS：所以RAG并没有消失，只是以新的形态出现在这里！）
Planning和Action的概念倒是没怎么拓展。
Tool的拓展就变得很广了，在多Agent的平台里，Tool可以是一个子Agent，能嵌套，如此一来，就和大领导发布任务一样，从上往下层层拆解，各自完成最终汇总。
Memory
首先，我们来讲一下Memory，记忆模块。记忆模块因为从多轮对话开始，所以历史比较悠久，内容也会更加更丰富。这里给两篇最近的综述。
From Human Memory to AI Memory: A Survey on Memory Mechanisms in the Era of LLMs
Memory in the Age of AI Agents
在笼统概念中，会把记忆划分为短期记忆、长期记忆和RAG记忆（有的论文叫Knowledge Retrieval as Memory，一个意思），我先按照这个来讲吧。
首先是短期记忆，他更关注于短期、即时的对话信息，在Agent内，除了多轮对话历史，还有对话上下文（包括大模型调度的各种指令及其返回信息）、中间的推理步骤等，比较典型的是ReAct，这里我用大模型生成的一个例子，参考这个流程。
假设问题是：“谁是现任法国总统？”
Thought: 我需要知道当前法国总统是谁，可能需要查询最新信息。
Action: 调用搜索引擎工具，查询 “current president of France”。
Observation: 搜索结果返回 “Emmanuel Macron is the current president of France (as of 2024).”
Thought: 信息已确认，可以回答问题。
Action: 回答用户：“现任法国总统是埃马纽埃尔·马克龙。”
这个流程里，例如走到了第四步，我们其实应该记录1/2/3/4步内的所有大模型分析、请求、结果返回的所有内容，这里的边思考边行动的模式就要求我们必须有一个模块去存储这一大堆内容。从实现上，我们可能可以简单地存在内存里，由变量一直待下去，但在复杂场景，信息太多，我们可能就要开始考虑数据库，构造一个session_id来存储这些内容了。
一般情况，这种短期记忆，基本是用后即焚，也依赖于大模型的上下文窗口，推理长了，很多早期的信息也会失效。
第二便是长期记忆，这是跨对话、跨时间的，所以必须有个比较复杂的模块来记住这些复杂的东西，在Agent里，可以是自动生成的新工具、新技能、新经验，更广泛的，可以理解为整个对话、处理过程的所有内容及其二次甚至多次加工产物。举个例子，对话过程中的反思，经过收集整理，是可以形成经验存到记忆中的，再举个例子，对话过程中用户透露的信息，被记忆下来就可以形成用户偏好，去做一些商品方面的推荐，这个在一些销售类的产品中就很常见。
Memory领域我觉得比较有代表性的工作是两篇，一篇是我之前分享过的MemoryOS（前沿重器[67] | 北邮腾讯MemoryOS：分层记忆模式解决大模型长记忆问题（上）、前沿重器[68] | 北邮腾讯MemoryOS：分层记忆模式解决大模型长记忆问题（下）），另一篇是我有点想分享的"MIRIX: Multi-Agent Memory System for LLM-Based Agents"（https://arxiv.org/abs/2507.07957v1）。
MemoryOS聚焦多轮对话的记忆，把对话内容分为3层，短期记忆专注最近几轮聊的内容，确保流畅性，中期记忆定期把局部片段对话进行摘要后入库，在后续的对话中被提及时才会召回，用更炫酷的方法说就是“记忆唤醒”，更长期的关注用户的偏好、观点等重要记忆点进行针对性记忆，在回复风格、情绪价值等方面有更多的能力；
MIRIX亮点在于把记忆从多轮的视角进行了拓展，让其更适配于Agent这种灵活的模式，作者设计了一套由六大记忆组件构成的综合架构：核心记忆（构造出来的智能体的人设和用户的长期事实，如用户的姓名偏好等）、情景记忆（捕捉带时间戳的事件与时间定位的交互，反映用户的行为、经历或活动）、语义记忆（保存与具体时间或事件脱钩的抽象知识与事实信息，充当关于世界或用户社交图谱的概念）、程序记忆（存放结构化、目标导向的流程，如操作指南、业务工作流与可执行脚本）、资源记忆（保存用户正在阅读或编辑、但又不适合归入其他类别的完整或部分文档、转录文本或多模态文件）与知识保险柜（存储逐字敏感信息的安全仓库，涵盖凭证、地址、联系方式、API 密钥）。
第三便是RAG记忆。在这里，我的理解，并非是把RAG从短期和长期的记忆中脱离出来，而是记忆这个模式逐步发展形成了RAG这个模式，各种记忆都需要被记录到数据库里，下一步便是要有触发手段把他给查出来了，查出来便是应用，于是一个RAG的模式很自然地就出来了。
而在后续，记忆功能承载了一个新的能力——进化的储备池。在Agent运行过程中，系统总能发现一些行不通的路径或者工具，而又能在流程中获得反馈并完成，此时，这些信息能够存下来，便能让整个系统得到优化，这便是自我进化的流程，类似MIRIX的程序记忆，能记录流程，这些流程就是在执行过程中得到优化的结果。
因此总结下来，我的理解下，记忆模块的发展路径大概是这样的。
记录最近对话的内容，形成短期记忆。
记录更长、更久远甚至围绕用户或者AI的记忆系统。（长期、个性化）
记忆信息的更深入处理，划分多种实用的记忆类型。（MIRIX模式）
形成反馈机制，通过总结、反思，反哺Agent系统，成为提升Agent的一部分。
Planning
Planning是贯穿整个Agent最重要的部分，他需要对给定的query进行合理的拆解，再逐步分配任务逐步完成，复杂的，可能还需要反思，重新优化流程，甚至可能要多条路径进行尝试，收集多个内容然后再安排整合，最终逐步把事情推向完成。
Planning这个任务的综述，我找到的是一篇：Understanding the planning of LLM agents: A survey，他的拆解就会比较细了，有兴趣大家看可以去详细读一读。我后面写的更多是目前的核心思路以及工业界常见的一种方法。
一般的，拆解的思路主要是，简单地静态链式规划、树结构多路径规划，这个挺好理解，就是看一条路走到黑还是分多个来走罢了。具体选哪个，更多还是取决于问题本身是否需要，以及目前的系统是否支持。
至于伴随拆解的反馈，思路则比较朴素，就是基于多个反馈来源的信息，来动态调整自己的思路，这个反馈的来源会比较多，环境反馈（代码报错）、人类反馈（人主动提出代码有问题）、模型审查（模型自己查出来的问题）、多智能体之间的反馈（多个智能体互相批评）。
如此一来，形成整个planning的体系，规划、执行、反馈/反思、更新规划，最终逐步完成任务。
不过，在实际应用中，大家通常会发现，在一些垂类的任务中，大模型做Planning的效果也不尽人意。大家整体的思考路径基本都是这样的。
发现大模型对一些子任务的拆解并不合理，也跟下游的Action、Tools不适配，要想做得更好，训练几乎是必然的。
planner训练的数据并不好弄，人工编辑流程显然也不好做，SFT这条路困难重重。
RL似乎是一个不错的路径，虽然我们无法或者无法大量地总结出一个好的路径是啥样的，但是我们知道什么样的路径是好的路径。
RL的一大重点工作就变成了构造reward，比较合适路径就是llm-as-judger（之前写过一篇综述文章的总结：前沿重器[65] | 大模型评判能力综述）模块，让大模型给方案打分，从业务层面拆解评分标注，如红线、工具支持度、流程合理性等。这种方式构造起来更方便，也具有很强的业务可解释性。
这种构造reward的模式，就非常适合GRPO之类的训练方法，一拍即合，对标注数据要求没那么高，而是需要一个合理的reward。
我的视角看，目前大量的应用，都是通过这套推导思路，设计出了合适的训练方案，并在这个思路下做了很多延伸。知乎里看到“是念”大佬的一篇对Planning的强化学习总结的文章，就对RL的有关技术做了总结：https://zhuanlan.zhihu.com/p/1902381952998281700。
Action
Action很多时候会和Planning一起，也有些时候会分开，Planning聚焦做什么，Action聚焦怎么做，具体的思路便是，从工具库里选择合适的工具，完成实际任务。简而言之，就是选择工具。
但是，如果数量足够多，简单的模型识别分类完不成时，大模型的上下文吃不下的时候，就需要专门的模块来完成了，有些地方叫路由，早年的搜索或者对话系统，会叫做意图识别，在一些Agent结构不完善的系统里，会把这玩意和planning放一起。说白了，就是分类，对一个任务A，要用哪个工具来完成最好。
目前，我自己的理解，比较好的方式是类似前段时间写元宝的那篇文章讲的工具选择的方案（前沿重器[75] | 腾讯元宝重磅出击：Agentic RAG如何让搜索“重生”）。当工具已经堆积成山的时候，例如几千个，而且变动还很大，哪怕大模型来，也不可能把所有工具的描述都扔进去选，所以用搜索的方式缩小范围就很合适了。于是，以搜代分的模式就非常适合（心法利器[26] | 以搜代分：文本多分类新思路）（以搜代分还在发力啊？！），下面是（前沿重器[75] | 腾讯元宝重磅出击：Agentic RAG如何让搜索“重生”）给出的方案。
插件系统有如下模块。
插件召排。改写query输入进行搜索，召回TOP K，再用Rank简化列表。
外部知识引入。为FC（Function Call）提供外部知识，提升槽位提取精度。（这也算是一种RAG思想的应用了）
FC（Function Call）。提取插件API所需槽位信息。
API调用。
质量控制。更笼统地说，对API调用结果做后处理。
Tools
工具是整个Agent的关键执行模块。前面的记忆也好，规划也罢，还是选择工具，都可以说是准备，最终的执行，还是得看Tool。Tool作为底层能力，其广度和深度/可靠性直接决定了整个系统的可靠性，因此他的建设很重要，在项目的初期，他是雏形建立的关键，而在项目后期，前面模块逐渐收敛的情况下，Tool的拓展更新也会是一个重点。那么，Tool可以是什么样的。
大模型，能帮你回答一个问题大模型，往定制地走，精心设计一个模板，通过拼接prompt然后请求大模型，完成一个任务，也可以是一个Tool。例如，一个文章摘要Tool，内部可能就是一个prompt模板，拼接你的输入后，请求大模型拿回的结果。
数据库查询甚至RAG接口。例如一个做商品销售的Agent，当需要做商品推荐时，需要了解用户画像，此时就需要做数据库的查询，查完了可能还要用大模型筛除无效信息，此时说不定就是个小的RAG了，甚至换个角度，这就是调用Memory能力了。
API接口。例如调天文台接口查天气。
另一个Agent。换个角度，Tool是一个功能模块，那这个功能，为什么不能是另一个Agent做的呢。另一个Agent，可以通过API接口接入，也可以通过函数，内化成自己的内部代码使用，都行，但实际上，Multi-Agent的本质就可以是这个模式的运作。
回顾一下我的视角的Agent
前一篇文章（心法利器[147] | Agent，是大模型落地的殊途同归），我提到了Agent是大模型落地的殊途同归，从大家的分析推演，逐步把大模型的整个应用推进到了一个共识层面，即Agent的这个模式，虽然这个概念并未形成完整意义的边界（大家也多少能感受，上面的很多东西，都存在“换个说法”、“换个视角”之类的描述），但是这个应用模式已然形成，现在来回顾一下2025年我的视角下的一些关键性工作吧。
RAG——功成身不退
首先，是RAG，还是从我自己比较熟悉的RAG模式开始，在24年的总结，我是对RAG这个模式进行了总结（心法利器[125] | 24年算法思考-小模型的生存空间），这里提到了RAG已经从初步范式的建立（毕竟这个模式的结构还比较简单），到各个模块的定制拓展，现在视角看那个时候已经一定程度有了收敛的迹象，开始往定制和专长的方式发展，顶多是Agentic RAG的模式（前沿重器[61] | Agentic RAG综述解读），基本真的就是真的收敛了，到了DeepSearch那篇文章看（前沿重器[69] | 源码拆解：deepSearcher动态子查询+循环搜索优化RAG流程），Agent的味道真的就很浓了，有collection router，也有reflection。
至此，真的可以说，RAG已经算是完成自己的阶段使命，大模型的应用要跳出RAG的模式，寻找新的模式。当然，这里值得强调的是，不是说RAG就没用了，RAG会成为后续系统的一部分，继续发展，所以我这里用的词是，“跳出”，而并非抛弃。毕竟，要抛弃一个技术，真的很难。
多轮对话——开枝散叶
对话一直是我接触的领域，各个历史形态以及他的变迁我都算是看在眼里了，真的挺有感情（前沿重器[21-25] | 合集：两万字聊对话系统）。
在2025年，作为大模型应用的排头兵，开始开枝散叶，各个模块在大模型应用都有了长足的进步，他能串联系统内部多次大模型调度的协调，对外作为产品，成为用户交互的窗口，System、User、Agent3个角色真的可以生动形象地描述这个格局。
首先，是Memory模块的升级和拓展，大模型之前的多轮，可能局限在上下文的对齐，以确保连贯性和长期记忆性，在大模型极具包容性的支持下，简单地上下文连贯早已不成问题，长期记忆也可以借助后处理和数据库的模式完成，甚至有了更多的升级。如前文所言，MemoryOS之类的工作开始融合更为长期的兴趣偏好，而MIRIX则带来了更丰富的记忆体系，甚至甚至，能反思作为系统自升级的养料。
其次，便是个性化的大幅升级。从普通的问题解决机器人，能逐步引入个性化，今年给大家分享过sigir25的一篇个性化机器人（前沿重器[63] | SIGIR25-个性化实时检索增强机器人主动对话能力），也有一些有关的个性化文文章分享（前沿重器[73] | 深入技术深水区：RAG与Agent如何实现精准个性化、心法利器[138] | 大模型如何避免“千人一面”？个性化开发的破局之道），让对话系统能“更懂你”。
在这，基于多轮对话，在下半年多了新的概念——上下文工程，Andrej Karpathy也对这个概念进行过分享，至此，多轮对话确定成为了Agent这个系统的土壤，真的要开始开枝散叶了。
搜广推——“钱袋子”
继续个性化的话题，搜广推是很多互联网公司的“钱袋子”，这方向的研究者当然不会放弃大模型这个发展的“东风”，生成式推荐便是这个产物。今年我也先后分享了多篇和生成式推荐、搜索相关的方案。
前沿重器[59] | 淘宝LLM落地电商推荐实践启示
前沿重器[64] | 阿里妈妈URM大模型：基于LLM的通用推荐新方案
前沿重器[66] | 美团搜索广告召回迭代实践启示
前沿重器[74] | 淘宝RecGPT：大模型推荐框架，打破信息茧房
前沿重器[75] | 腾讯元宝重磅出击：Agentic RAG如何让搜索“重生”
然而，尴尬的是，目前生成式的这套模式，可能很难独立在一个系统中生存，这个问题曾经写过一篇文章来讨论（心法利器[146] | 生成式搜索：惊艳但难落地的技术浪漫），因此，Agentic化，可能也是大势所趋，至少，一些AI客服销售，已经开始做类似的尝试了，这套商业化的模式，仍然能继续走。
最近也有听到一些消息，有一些AI公司，可能要在大模型里面加入广告以获得盈利，这将会是一个非常实用的应用场景，这个也算是初步印证了这个猜测吧。
自优化的闭环
这应该是今年年末我自己发现的最大的惊喜，那就是自优化，让整个模型迭代，形成闭环。
早在半年前，我就分享过一篇综述（前沿重器[65] | 大模型评判能力综述），详细讲解了大模型作为评估器的有关研究。众所周知，一旦一个工作能形成综述，意味着这个方向形成了一股合力，有了足够多的铺垫了，这个评价的模式一出，整个自优化的过程很大程度就完成了闭环。
来看一个月前我分享的美团的WOWService（前沿重器[77] | 美团WOWService（上）：四阶段训练打造高质量可维护的对话模型、前沿重器[78] | 美团WowService（下）：多智能体和评估实现闭环），美团便成功完成了这个闭环，内部构造了自我检测回流迭代机制，主动发现问题、分析问题、解决问题，最终反馈到定时训练中，完成了优化，实现用户满意度提升与成本降低的双重目标。
再者，我自己也简单写了一个自动化标注的模式，大家通过阅读，应该能直观理解这个模式的运作机制（心法利器[142] | 大模型自动化标注：实战代码分享），当然，要想实现自动化，光靠这里面的简单代码肯定不够，需要结合实际进行大幅度调整，最终才能真正把流程走通。
我们该怎么做
在（心法利器[147] | Agent，是大模型落地的殊途同归）文章内，我曾讲过一次我们该怎么做，总结了下面3点，讲的是宏观的发展方向。
Agent的整套模式和方法论值得学习和应用的，在新项目开发的时候，直接按照这个范式走会更简单。
Agent产品，尤其是垂类产品，目前仍需打磨，未来仍有巨大空间，会在26年有长足发展。
以NLP为出发点，带动多模态领域。
然而微观层面，学习和操作层面，在自己的总结分析下，有新的启示。
大模型的有关技术，已然成为基操，而且是不能不会的基操，后续大量的应用都需要围绕这个来进行，不会真的连活都干不了，很残酷。
通用的是最快的，但定制的才是最好的。尽管目前基于通用的大模型已经能做出很多不错的Agent框架或者应用，但要想好，离不开各个模块的精心设计和训练，包括但不限于Planning模型、Memory模块构造、Tool的精细化定制以及合理的调度与维护。
算法重新从算法模型设计转移向算法+工程的配合设计，在Agent模式下，工程的调度将会变得复杂，对于算法而言，工程能力的重要性会初见增加，能手撸服务或者框架的算法在某种程度上会很抢手，而另一方面，工程在这里也会是新的介入机会，可能比infra更加吃香。
