做 Agent 方向的研究最怕的往往不是代码写不出来而是开题时坐在屏幕前憋不出一个像样的点。我从去年到今年集中把 ACL、EMNLP、NAACL、ICML、NeurIPS、ICLR、AAAI 这七个会议里的 Agent 相关高引工作翻了一遍粗算下来接近 180 篇。这些论文的主题分布、方法演进、以及被反复引用的核心模块把它们放在一起看其实远比单读一篇两篇要清晰得多。这篇文章就把这 180 篇工作按主题和脉络拆开重点给出四个现在还值得做的创新切口附带我整理文献时的选题判断方法希望能帮你缩短从焦虑到动手的时间。先说明一下我的筛选口径以 2023 年到近期的正式发表为主覆盖大语言模型驱动的自主智能体这条主线排除掉纯对话系统、纯文本生成以及没有与环境交互闭环的工作。我自己手动维护了一个选题表格把每篇论文拆成四列它解决什么任务、用了什么建模方法、跑在什么环境上、用什么指标评测。后面你会看到这张表不仅帮我定位了四大创新切口还帮我躲开了不少重复造轮子的坑。1. 顺着 180 篇高引工作看清 Agent 研究的整体版图1.1 这些论文是从哪七个会议里筛出来的说实话七大顶会本身就是一个很实用的小抄。NLP 线的 ACL、EMNLP、NAACL 侧重语言理解、指令遵循和任务型对话Agent 在这些会上的形态通常是用自然语言控制外部工具或完成复杂指令机器学习线的 ICML、NeurIPS、ICLR 更强调可扩展的框架设计、强化学习辅助、以及大规模评测Agent 在这些会上的形态往往带着明显的系统味道AAAI 则是两者折中的地方应用的落点更多。如果只盯着某一个会你很容易被它的口味带偏。比如全看 NLP 会议你会以为 Agent 的难点就是语义理解全看机器学习会议你会以为难点全在优化和泛化。实际上真正被引最多的 Agent 工作几乎都是跨线的既有自然语言层面的工具调用设计也有系统层面的记忆和调度设计。筛选的时候要主动跨线而不是只看某个方向的全部。这 180 篇我没有严格限定为只读正文而是按被引次数由高到低先读摘要和实验结论再挑四五十篇精读方法。高引本身是个滞后指标但它有一个好处它能明确告诉你这个领域里哪些问题是社区公认的核心痛点。相比去追最新的、还没经过检验的 idea先理解高引工作在解决什么更有利于找到下一个值得做的问题。1.2 高引论文大致分成四个簇把这 180 篇放平之后我看到的高频主题其实就四簇其余大多是它们的交叉组合。第一簇是推理与行动框架。这类论文的主角是把大模型本身的推理能力套到一个可循环的环境里先从模型自身得到思考过程再根据环境反馈修正下一步行动。最典型的设计就是推理-行动-观察交替围绕这个范式派生出大量变体。高引的关键原因是它把如何让模型自主收拾残局这个抽象问题变成了一套可复制的工程范式。第二簇是工具调用与外部信息融合。这个簇处理的问题是模型不懂的、记不住的、算不准的怎么通过调用外部工具补齐。检索、代码解释器、结构化数据库、网页操作都算在工具集里。高引的工作往往不是堆工具数量而是解决工具该在什么时机被选择、参数怎么由模型生成、失败之后怎么改走另一条路。第三簇是多智能体协作。多个模型角色在同一环境里各自负责一块任务通过通信协议和任务分解完成一个单个模型难以完成的整体目标。这一簇刚兴起时大家习惯把多个模型实例丢在一起自由发言后来高引的工作逐步转向更可控的编排、分层、或者说用固定协议约束的通信结构。第四簇是记忆与长期交互。面向真实任务时Agent 必须跨越很长的时间跨度先做完一件事再回来接着做另一件事这依赖显式的记忆读写。记忆这块高引工作集中在把自然语言经验存储到外部介质、在合适的时机检索回填、以及用总结和抽象减少无关信息的干扰。1.3 高引论文不是靠点子新赢的而是靠问题公开赢的如果让我总结这 180 篇的一个共性就是它们几乎都在解决一个人人都能感知到的痛点而不是一个只有作者自己才在意的细节。举个例子推理与行动框架之所以高引是因为当时所有人都在用纯单轮推理遇到多步操作就断线这是普遍痛点。工具调用之所以高引是因为模型输出的知识是有截止时间的也是普遍痛点。多智能体和记忆两个簇也是一样都不是小圈子问题。所以选题的时候我给自己提了一个硬要求这个问题必须能用一句话讲清楚谁在什么场景下遇到了什么麻烦。如果一句话讲不清说明问题本身还不够公开。这个标准放在后面的创新切口里同样适用。2. Agent 研究的里程碑脉络从单模型到系统2.1 第一波演进推理与执行交替的范式固定早期的工作大多数还是一次性推理思维你给模型一段指令它输出一段答案任务就算完。但真实场景里的任务几乎都是多步的比如订行程涉及查航班、比价格、选时间、确认支付一次性推理根本推不出正确结果。于是出现了把推理分解成多轮、每一轮都能接收环境反馈的工作。这个范式在今天看起来平平无奇但它的核心贡献不是加了某一步而是把整个 Agent 的逻辑从文本接文本改成了文本接环境状态模型思考之后不是直接产出最终答案而是先产出一个行动行动被环境执行再把执行结果拼回上下文让模型继续思考。这套闭环直接成了后来大量 Agent 框架的地基。从选题角度的启示是任何看起来已经变成常识的范式都可能挂着几个尚未被解决的二级问题。比如在什么时机停止思考直接行动、从环境反馈里提取什么信息送回上下文当年没人系统化研究而到今天这些依然存在大量优化空间只是你没意识到它们也能是论文。2.2 第二波演进工具不再是插件而是Agent的延展器官第一波框架把推理闭环做好之后模型很快暴露了一个问题光能推理没用很多信息它根本没有很多操作它做不了。于是工具调用浮出水面。我梳理下来早期工具类工作的重点在选择正确工具后来的重点转移到了工具用完之后的处理。比如模型调用搜索工具拿到了几十条结果如何压缩成推理需要的几十行模型调用代码工具执行出错如何拿报错信息指导下一步修改。这个迁移很有意思它说明 Agent 领域在快速从能做动作走向做对动作。还有一个值得注意的分支是隐式工具调用模型不需要显式输出工具名而是通过生成一段代码或一个查询语句来触发外部能力。这类工作在工程部署上更顺滑但在可解释性上更弱两条路线都在高引列表里占据重要位置。选题时不要只站在一条路线上想两条路线的缝合处往往是空白地带。2.3 第三波演进把单个Agent变成一群Agent单个 Agent 的能力上限受限于单次上下文、单模型偏好、以及单条推理线路。多智能体协作走的是另一条路让多个具备不同分工的模型实例通过对话、评审、投票或层级汇报来共同推进任务。我读下来的感觉是早期多智能体论文大多在论证数量多更有效直接让两个模型互相辩论来提升回答质量。但随着论文变多审稿人开始追问成本、收敛性、通信开销于是新的高引工作转而研究结构化编排什么时候需要引入新角色、角色之间的消息格式如何约束、哪个角色拥有终止权力。这些问题实际上已经不是模型能力问题了而是系统设计问题。这也解释了为什么很多 Agent 团队招人时更看重系统设计能力而不是纯模型调参能力。Agent 领域正在从单点模型优化转向模块之间的交互协议设计你的选题如果能看到这一点就不会陷入换个 Prompt 跑一遍的低水平重复。3. 四大创新切口拆解拿一个就能做出一篇像样的工作3.1 切口一任务与环境的可编程化把隐藏场景变成代码我观察到的第一个真实缺口是绝大多数研究仍在使用固定的公开环境比如网页操作、代码仓库、或者问答集合。环境一旦固定任务空间就固定了Agent 的能力上限也被环境锁死。而真实业务里任务总是长尾的、动态变化的、带噪声的。所以与其继续设计一个更强的 Agent 去适配旧环境不如研究如何低成本地生成新任务和新环境。这个切口的操作思路很直接利用大模型本身生成能力把自然语言描述的活动场景转化成可执行的评测任务。只要生成的任务具备可验证的标注结果你就得到了无限多的环境。这里真正的难点不是生成本身而是如何控制生成任务的难度分布、如何排除数据泄漏、以及如何保证任务没有歧义。从这个切口出发能做的具体课题很多比如面向特定行业客服、财务、科研的任务生成框架比如带难度自适应调节的评测环境生成比如把非结构化文档自动转化为带步骤标注的 Agent 任务。它的好处是数据好造验证闭环清晰缺点是需要花时间解决生成质量过滤问题。我实测下来用较大的基础模型负责生成、再用规则和小模型做质量闸门整体可控。3.2 切口二记忆的分层与遗忘策略不只会存还要会扔记忆是个看起来人人都在做、但绝大多数工作只做了存和取的方向。很多实现就是把对话历史或经验文本塞进向量库里然后根据余弦相似度检索。这种做法在短任务上够用但任务越长记忆越杂检索回来的信息里无关片段占比越高反而干扰主任务。我觉得真正的切口在于忘。一个健忘的人类助手其实知道什么时候该不看某份材料什么时候该把旧结论作废。具体到 Agent需要解决三件事一是写入时机哪些经验值得长期保存、哪些只对当前任务有用二是检索衰减随着任务推进旧记忆的权重应该动态下降而不是始终一致三是主动淘汰当记忆冲突时用什么策略决定保留哪条、删除哪条。这三件事每件都可以拆成一个研究课题而且都能设计成可评测的实验在长程任务里对比不同记忆管理策略的任务完成率、平均交互轮次、以及注入无关记忆后的抗干扰能力。做这个方向不需要特别大的算力因为你改的主要是记忆管理层的逻辑底层的模型推理接口可以保持不变。3.3 切口三多智能体协作中的成本与预算约束多智能体的高引工作让我特别在意的一点是论文里的理想协作往往假设所有角色可以无限次发言。但实际落地时每一轮调用都是在烧钱一个任务动辄几十次模型交互商用 API 的费用很快就让人肉疼。所以如何在有限预算下达到最好的任务效果是一个真实存在但研究远不充分的问题。这个切口有几个可以落地的子方向。一是角色调度不是所有任务都需要三个角色开会能不能用一个轻量模型预判任务难度只把困难任务交给多智能体协作简单任务单模型直接完成。二是终止机制让某个控制角色在任务达到充分条件时果断喊停避免无效辩论。三是通信压缩角色之间的消息长度、轮次、以及消息里携带的信息量都要优化能用五句话说清的事绝不用五十句。这个方向的实验便于量化固定一个总预算比如最多允许两万 token 或一百次调用然后比较不同调度策略在任务完成率上的差异。它在审稿人那里也讨喜因为成本指标是现在 Agent 论文里普遍缺失但实际约束力极强的数值。如果你担心纯调度太工程化可以把预算调度和模型能力分层结合做成一个学习型调度器这就是一个完整的论文故事了。3.4 切口四评测指标从任务成功率走向过程可控性当前大多数 Agent 评测只给一个最终正确率最多加一步报错率。但真实使用场景里用户关心的是过程指标Agent 是不是在一个没必要的地方反复重试是不是陷入了死循环是不是做出了不可逆的危险操作而不自知。我自己在做评测复现的时候最头疼的就是指标粒度太粗。两个 Agent 任务成功率一模一样但一个每次运行都稳定走同一条路径另一个时好时坏靠概率碰对结果。用现有指标你完全看不出差别。所以第四个切口是做一套面向过程控制的评测体系把死循环次数、无效工具调用率、关键节点偏离度、失败后的恢复时长都纳入评估。这套评测体系本身就有发表价值而且还可以往下挖一层基于过程信号训练一个预测模型在任务执行早期预判当前 Agent 会不会失败提前切换策略。这个像我前面几个切口一样也不需要改底层模型。它是在 Agent 外面加一个监测与干预层研究问题非常聚焦而且实验起来不需要海量算力半天就能出一个初步对比表格。3.5 四个切口如何选给你一张判断表如果有人让我一句话总结这四个切口之间的关系我会说它们是同一个问题的四个侧面都在关注Agent 系统作为一套完整的工程系统如何变得更可控、更便宜、更可靠而不是单纯把模型换大。下面是我自己选题时拿来做取舍的标准切口方向数据/环境需求算力需求验证难度适合谁任务与环境可编程化需要积累一批任务描述模板低到中容易出数瓶颈在质量过滤有工程能力、想快速跑通闭环的人记忆分层与遗忘需要长程任务基准中需要耐心设计消融对系统结构敏感、喜欢做架构设计的人多智能体成本约束需要商用或开源模型调用接口低对比指标清晰效果好量化对实际落地成本敏感的人过程化评测体系需要能采集完整过程日志的框架低到中需要先建指标再跑实验愿意做评测基建、擅长归纳的人这四条线并不互斥你可以把其中任意两条缝合。比如把过程化评测和成本约束放在一起设计一套既监控过程健康度、又控制调用预算的评测框架立刻就是一个不错的系统论文选题。缝合的关键是要让两条线之间产生因果关联而不是简单的模块叠加。4. 选题决策清单从粗浅想法到可执行方案4.1 用文献矩阵代替随缘阅读很多人读论文的方式是从最新一篇往前翻看到哪算哪。我的建议是先建一张 Excel四到六列就够论文标题、任务、方法、环境、指标、可复现性。每读一篇就填一行累计填到四五十行你的方向感会完全不一样。填的过程里你会自然形成对比视角。比如你会发现同样是在网页环境做操作为什么某工作能被反复引用另一篇工作却沉寂了。多数时候是前者给出了一种可复用的方法框架后者只报告了具体任务上的性能数字。这个观察对你的选题有一种警醒作用你是在造框架还是在报数。我还习惯给每篇重要论文加一列没解决的未来问题直接从原论文的 conclusion 或 future work 里抠出来。这个方法收益率极高因为作者自己指出的局限往往就是最可靠的选题来源。高引论文作者碍于审稿篇幅没法在正文里展开的若干方向就是你接力的地方。4.2 最小可行方案怎么设计确定一个切口之后不要直接铺开做一个完整系统。我通常要求自己先把基线跑通选一个开源 Agent 框架跑通一个公开基准复现出基线分数。这一步花不了太久却能在后续所有实验里节约大量时间因为所有改进都要拿它做参照。然后只做一个小改进。比如我做记忆方向的时候第一步只是在每次检索后增加一个与当前任务无关的过滤判断其他逻辑一律不动。就这一点点改动在长程任务上就能看到明确变化。小改进跑通之后再逐步加新的模块。这种增量式开发的好处是你能准确判断每个子模块的贡献写论文时消融表也顺理成章不用临时补实验。我给自己的硬性建议是四周内必须看到第一个不靠调 Prompt 获得的指标提升。如果四周还没动静要么是方向本身有问题要么是验证环境选错了要么就是基线太强你没有机会早点换方向比你硬撑高效得多。4.3 判断选题成不成立的三个问题每当我有个看起来还不错的主意我就会拿三个问题审它一遍。第一个问题这个问题是不是伪需求判断方法很简单去找一个真实任务跑一遍看这个问题是不是真的会造成可见的失败。如果只是理论上存在、实际很少触发建议换个场景。第二个问题如果去掉我的方法用更简单的基线能不能达到差不多效果我见过太多选题最后被审稿人一句话毙掉你这个复杂设计比简单 Prompt 只高零点几个点。因此在正式做实验之前先用简单基线做一个上限预估确认你的方法确实有不可替代的贡献。第三个问题我能用一张图把这个思路讲清楚吗不是流程图是那种让一个没读过文献的朋友也能看明白思路机制的示意图。如果画不出来说明你的故事还没成型。先回去把思路理顺再动手。这三个问题其实对应实验前、实验中和写作阶段的三种风险提前过一遍能帮你过滤掉大部分低质量选题。5. 实操中容易踩的坑与避坑实录5.1 复现高引工作时踩过的典型坑第一个坑是环境版本漂移。很多高引工作的环境是特定时间点快照的今天去复现时页面结构、工具接口都变了导致动手改 bug 的时间远超读论文的时间。我后来学乖了优先选带 docker 镜像或固定版本依赖的项目没有的话就直接读它在论文里定义的输入输出格式自己重新搭一个迷你环境保核心逻辑不变。第二个坑是参数藏在 appendix 里。有些论文正文里不写温度、不写最大生成长度也不写用了什么样的提示词模板只告诉你在某个基准上达到了多少分。复现这类工作最费时间。我现在的处理方式是先照着自己的经验填一套合理参数如果跑出来的分数明显低于论文报告再去 appendix 里翻详细设置很多时候翻完就发现他用了比正文大很多的采样次数或者做了多次 seed 平均。第三个坑是过度相信官方实现。有的官方代码仓库并不能直接复现论文数字因为它依赖了一些没写清楚的环境状态或随机种子。遇到这种情况我的做法是不纠结于复现到完全一致而是把重心放在复现它的方法机制上只要你的实现符合论文描述的核心逻辑它就能胜任基线的角色。5.2 审稿视角的常见质疑准备如果你打算投顶会下边这些问题迟早会被问到建议在做实验时就准备好答案。第一个是效率与质量的权衡你的方法虽然指标高了但耗时或费用增加多少每次实验请务必记录耗时和 token 消耗论文里放一个 trade-off 表能挡掉大半成本质疑。第二个是小规模结论的泛化性你只在两三个环境上做了实验凭什么说它能推广应对方式是让评测环境尽量多样化哪怕每个环境跑的任务少一点也要把环境数量做上去审稿人在意的是多样性而不是某个环境的绝对分数。第三个是目前最常被追问的鲁棒性问题换一个指令表达方式、换一个底层模型你的方法还灵不灵做实验时至少换两个不同规模的基础模型跑一遍如果规模有限就选一个开源小模型和一个商用大模型做对照。哪怕结果有波动只要你把波动规律讲清楚也比完全没有这个实验强得多。5.3 时间和资源分配建议我给实验室同事的默认配置是两个月完成选题与基线两个月做完核心实验一个月扩展实验和补齐消融最后一个月写论文和做图。这里的核心风险点在第一阶段超过一半的坏项目都是因为选题没想清就冲进实验期最后发现没法闭环。资源方面做 Agent 方向其实不用一上来就追求超大规模算力。先确认你的问题在中小规模模型上是否已经存在如果小模型上现象看不到再考虑切换大模型。很多时候你设计的记忆策略或成本调度机制在小模型上反而更容易观察到差距因为大模型的强泛化能力会掩盖一部分方法差异。用小模型把机制研究明白再在大模型上做验证是性价比最高的路径。我还想特别提醒一点与同行保持一个可分享的讨论群非常有用。我有很多次是在跟别人讲自己想法的过程中发现逻辑漏洞的写论文的时候这些漏洞比实验失败更致命。你不需要把想法藏到做完实验再公开在早期分享反而能让选题被磨得更扎实。6. 几个能立刻用起来的小技巧最后分享三个我在整理这 180 篇文献时验证过的小技巧。一是论文表格不要只记录它做了什么还要记录它不做什么。高引论文的方法里通常有明确的边界设定比如不支持某些任务类型、不处理某些噪声输入。这些边界就是选题机会你可以做那篇没被做的部分。二是收集各篇论文的失败案例。很多人只关注成功指标但我发现最有启发的反而是论文里展示的失败样例。它告诉你现有系统的薄弱环节而这些薄弱环节往往比成功点更值得研究。建议单独建一个文件存失败案例你的选题会从这里面自然涌现。三是给每十个 idea 打分时别只打创新性和可行性两个维度加入审稿人质疑难度这一项。如果一个 idea 听起来很花哨但你马上能想象到审稿人的两条致命质疑它的排名就应往后放。那些能相对从容应对常见质疑的题目才是稳中求胜的候选。做 Agent 方向最稀缺的其实不是灵光一现而是持续稳定的选题方法。这 180 篇高引工作给我最大的启发就是高被引的作者不是在追热点而是在解决一种足够普遍、足够痛、又不能不解决的问题。你照着这个标准去选自己的切口哪怕最后选到的不是大热方向做出来的东西也不会缺读者。