做 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 篇高引工作给我最大的启发就是：高被引的作者不是在追热点，而是在解决一种足够普遍、足够痛、又不能不解决的问题。你照着这个标准去选自己的切口，哪怕最后选到的不是大热方向，做出来的东西也不会缺读者。
做 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 篇高引工作给我最大的启发就是：高被引的作者不是在追热点，而是在解决一种足够普遍、足够痛、又不能不解决的问题。你照着这个标准去选自己的切口，哪怕最后选到的不是大热方向，做出来的东西也不会缺读者。