★ FEATURED ARTICLE 做 Agent 选题没思路我懂那种感觉。方向看起来到处都是可打开论文列表要么是别人已经做烂的要么是根本不知道从哪儿下手的。我从七个主流 AI 顶会里筛出了近三年的高引论文大概 180 篇与 Agent 直接相关的工作花了两周时间做结构化梳理。这篇不是论文清单而是我把这些工作拆成“方向分布、创新切口、调研方法、落地评估”四个维度之后得到的一套选题方法论。适合正在开题的研究生、想转 Agent 方向的工程师以及那些已经进场但总觉得自己在跟风的人。1. 高引工作里藏着哪些信号180 篇样本的粗读结果先说我怎么筛的。我这次只关注七个会议NeurIPS、ICML、ICLR、ACL、EMNLP、AAAI、IJCAI。时间跨度取近三个年度周期然后把引用量排前 20% 且标题或摘要里明确出现 agent、tool、planning、memory、multi-agent、evaluation 这些关键词的工作挑出来最后得到大约 180 篇样本。这个筛选标准谈不上严谨但对于观察趋势流向已经够用了。第一轮粗读之后最直观的感受是Agent 方向已经明显分化出了几个冷热不均的子领域而“高引”和“投稿量大”完全不是一回事。我按研究主题做了个分布统计情况大致如下子方向大致占比高被引集中度我对竞争烈度的判断工具调用与 API 使用约 32%中高非常卷但仍有细分空间规划与推理优化约 24%高头部集中新玩家很难正面突破多 Agent 协作约 15%中热度上升快连接点还很多记忆与长程任务约 12%中明显上升期评价标准尚未统一Agent 评估与安全约 9%中低被提及频率高但系统产出少具身与模拟环境约 8%中门槛在环境侧不是算法侧工具调用为什么占比这么高因为这个方向工程链路短、评测相对好做、基线也容易跑。很多工作其实是在“函数选择正确率”和“参数填充正确率”上做提升指标直观。但也正因为这样这个方向上要想做出区分度你拼的不是“再用一个模型”而是“换一种交互机制”。比如我注意到高引工作里凡是能沉淀出通用 benchmark 的被引速度明显快于单纯提效果的论文。这说明社区本质上还是渴求标准化的度量工具。规划与推理类的高引论文则呈现出另一番图景。做得好的都遵循一个共同思路不追求一步到位而是把任务拆成可控的阶段。有的做子目标生成有的做失败后的重规划有的在搜索树里嵌入大模型的打分能力。回过头看那些想用一条指令让 Agent 完成整个长程任务的“端到端派”热度明显回落取而代之的是组合式方法——规划器只负责走一步看一步每步的动作由更专门的组件负责。记忆和长程任务这个细分方向占比只有百分之十几但被引的增长斜率非常好看。有个现象值得玩味早期的高引工作都在琢磨“怎么把更长的上下文塞进模型”最近风向则转向“怎么让 Agent 自己找到需要的那段记忆”。这其实是从存储思维转向检索思维的信号后面我会在创新切口里详细展开。多 Agent 协作的比例看上去不高但我在粗读时发现一个很有趣的细节很多工作引用量并不靠前却频繁出现在其他论文的 related work 和 baseline 对照里。换句话说少部分多 Agent 框架已经从“被研究的对象”变成了“被使用的工具”。这个转变通常意味着基础设施方向已经初具规模而基础设施之上还有大片应用层和被忽略的问题空间。所有这些信号叠在一起会得到一个很务实的结论选题机会不在最大的池子里而在“大家天天挂在嘴边、却很少有人系统解决”的缝隙中。下面我要拆的四个创新切口就都是从这些缝隙里挖出来的。2. 四大创新切口的完整拆解从现象到可落地的研究问题我仔细想了想与其给你二十个泛泛的方向词不如把精力集中在四个我已经验证过“有得写、做得动、审稿人认”的切入点上。每一个我都会拆成三层来讲现状痛点在哪里真正值得回答的科学问题是什么以及如果交给你做第一步实验该怎么设计。2.1 切口一多 Agent 之间的“接口设计”比单个 Agent 的“脑子”更值得做现状是大部分人做多 Agent本质上是“一个强 Agent 加一个弱助手”的简单分工。你让他做市场调研他负责写报告再叫一个擅长代码的来跑数据最后汇报时互相转述——这套路已经被写滥了。真正没被解决的问题是 Agent 与 Agent 之间的交互成本、信任机制和冲突消解。我最近看到的一种新倾向是把交互切成“协议层”。你说每句话都是内部思路每句话都是最终结论旁边的人根本不知道你什么时候需要帮助。于是有人开始研究“Agent 之间是否该有一套标准化的消息格式”比如结构化字段里必须包含意图、置信度、依赖关系还包含“我这句话是对谁说的”。看起来是个很工程的问题但背后对应的科学问题是沟通协议如何影响群体任务完成效率。从高引工作里我也观察到凡是涉及“角色分配”的论文基本停留在静态分工而涉及“动态再分工”的论文极少且引用量都不高。这就是一条清晰的缝隙。你可以问当任务中途出现不可预料的障碍时Agent 之间的角色和权力结构应不应该重组如何重组重组会不会引入新的沟通开销如果让我给一个具体的实验设计我会这么做做一个双 Agent 协作解题的环境一个负责探索信息一个负责归纳结论。让他们在固定的有限轮数里去解决一个多步骤谜题。你先把交互日志全部打出来统计“哪些对话是不产生任何信息增量的废话”然后设计一个过滤机制比如只允许传递结论或请求不允许复述过程。直接对比两种情况下的解题成功率。你会发现限制反而经常是好事。2.2 切口二把反思从“事后总结”搬到“过程信号”里现在的反思机制有一个通病都是让 Agent 在自己生成的文本上做自我检查。你让模型做一次代码生成它跑挂了你就把报错信息贴回去叫它“反思一下再改”。有些工作做得更复杂一点让多个模型互相审。这类做法有一个天花板——模型面向的永远是基于文字的猜测而不是真正的中途状态。我看到的另一个趋势是从“结果反馈”转向“过程反馈”。具体来说不是等整件事做完之后再总结哪里错了而是实时采集执行过程中的中间信号用这些信号判断是否应该及时转向。有人把工具调用失败率当作早期预警指标有人观察到上下文里重复 token 的比例突然上升就意味着模型开始原地打转还有人用“连续 N 步没有产生信息增量”来做早停。这里有一个生活化的类比开车从 A 到 B你肯定不会到了终点才跟导航说你刚才有个路口走错了。导航是每过一个路口就检查一次是否偏航。Agent 的自我修正也一样它需要的是任务进行中的高频低开销校验而不是任务结束后的长篇大论。这个方向的科学问题很简单但很尖锐哪些中间信号对任务成败最有预测力我们能不能训练一个小模型专门负责监控主 Agent 的运行时行为在它即将走偏之前发出纠偏信号哪怕这个监控模型只判断“继续 / 切换策略 / 放弃”本身都能做成一个极其好发论文的问题。我建议的第一个实验也相对轻量找一个本身就困难的长程任务集让 Agent 自己跑每跑十步就保存一次轨迹快照。然后离线标注每个快照对应“正常 / 疑似偏航 / 肯定偏航”。下一步用这些标注训练一个小的二分类监控器实时判断 Agent 是否需要人工干预。对比不用监控器的实验组你大概率会看到成功率不升反降——因为这个监控器会非常频繁地打扰主 Agent。别怕这个失败本身就是论文里最宝贵的分析素材。2.3 切口三记忆的关键不在容量在“唤醒机制”让我先说说这个方向多容易产生“假问题”。你看很多论文写“我们给模型加了一个记忆模块”实际做法是把历史对话全部拼起来或者用向量数据库存上一堆 chunk。但凡任务一长这些方法就露馅了因为 Agent 根本不知道该在什么时候调取哪一段记忆。你问一个 AI 助手“我上周跟你说过的那个需求还作数吗”它搜出来的可能是三十段完全不相关的历史片段。人脑的厉害之处不是记住得多而是几乎不出错地知道“当前场景需要调用哪段记忆”。这个能力对应到 Agent 上就是记忆的唤醒机制。我梳理高引工作时注意到研究“存多少”和“怎么存”的文章早就不新鲜了但研究“什么时候想起来”的文章依然稀罕。你往这个方向深挖几乎每次都能撞到没有系统解法的问题。怎么把模糊的“唤醒”转成一个可研究的问题我建议拆成三层来看。第一层是触发条件什么样的外部事件会让 Agent 认为“该翻翻记忆了”第二层是筛选机制从已有的记忆里用什么样的信号来选出相关的几条而不是一大坨塞给模型第三层是遗忘策略什么样的旧记忆应该被降权避免它在关键时刻误导决策。带上这三层去做实验你会看到一个很有意思的现象记录 Agent 在长程任务里主动触发记忆检索的次数它的分布不是均匀的。大量检索发生在任务刚开始时和任务转折点上比如在遇到失败之后。这就引出一个假设记忆检索的高价值时机可能与“不确定性上升”强相关。如果你能设计出一个不确定性估计器让它决定何时主动唤起记忆这比任何花哨的存储结构都更容易落地。我在某实验室的模拟环境里见过类似尝试结论是主动唤醒机制能让长程任务完成率提升一大截而存储部分换成最简单的内容拼接也几乎不影响效果——这就是路线选对了的信号。2.4 切口四把“评测质量”本身做成研究而不是附属于任务的研究这个切口看起来最不像创新但我在整理那 180 篇高引工作时发现了一个奇怪的现象顶会里专门做 Agent 评测的论文很少但每篇的引用量都相当稳定。几乎所有被引高的大模型 Agent 框架都会自己顺手造一个评测集出来而那个评测集往往又被下一批论文拿来当基线跑分。整个领域仿佛建立在许多“未经检验的尺子”上。从这里能挖出好几个干得动的问题。其一任务完成率这个指标严重偏向“最终答案正确与否”而完全不在乎过程是否合理、是否有大量低效尝试。其二现有评测大多假设环境是静态的任务不会因为 Agent 的策略而改变。这在真实应用里几乎不存在你的 Agent 乱问问题用户的耐心就会下降它不说话用户又会觉得冷场。评测环境本身应该是动态且可被 Agent 行为影响的。还有一个被反复忽略的维度是成本。很多 Agent 论文不会报告一次完整任务的 token 消耗也不会报告工具调用总次数。但其实对产业界来说这东西比准确率多一个百分点重要得多。每次调用都得花钱不可靠的外部工具还可能拖垮整个任务。把“成本效率”纳入评测体系本身就可以支撑一个完整的 benchmark。我个人的判断是这个方向在接下来两年会迎来一轮爆发。原因很简单Agent 的应用场景正在铺开所有团队都会面临同一个问题——“我们的 Agent 到底行不行”光靠“能跑通”无法回答这个问题必须有一套独立的、多维的、可复现的质量度量体系。这就是你能贡献的独立价值。3. 怎么把 180 篇论文变成选题地图四步文献调研法很多人调研文献喜欢按时间顺序一篇接一篇往下读读完后除了“好厉害”什么也记不住。我自己的方法完全反过来先不管论文质量而是把所有候选论文当成一张牌桌先看它们打的是什么牌再决定自己要不要上桌。第一步动词聚类。把所有论文标题里的核心动词抽出来——improve、learn、evaluate、coordinate、memorize、align——然后按动词分组。这样你会发现一个研究方向里真正被反复尝试的动作只有那么几个。比如工具调用方向的核心动词永远是 choose、filter、correct、calibrate每一个动词对应一拨工作集群。做完这一步你就知道这个方向的“问题骨架”是什么了。第二步追引用树而不是读正文。找每个集群里被引量最高的 2 到 3 篇作为根节点先读它们的问题设定和最后讨论部分。然后把引用它们的论文列表拉出来挑最近十篇看摘要你瞬间就能看出“这个根节点引出了多少分支哪些分支已经枯死哪些分支正在新发”。我自己有个不成文的规则如果某个根节点近一年没有任何新的高引子节点这个方向基本就别碰了说明很难延续反之如果它的子节点持续出现且各不相同说明问题空间还很宽。第三步专门读 Related Work 的最后一两段。论文的前面部分都在帮你理解它做的事情但收敛到末尾作者往往会态度暧昧地承认“还有一些问题没解决”。这些句子通常数学不严谨、措辞含糊、范围也不清析恰恰是宝藏。比如“如何让 agent 在动态环境下有效复用历史经验仍然是一个开放问题”这类表述直接翻译过来就是“我知道我的方法在此处不行但我没空解决”。你在选题策划阶段把这些“认怂句”抄成一张清单里面随便挑一个都有机会成为一篇工作。第四步按复现难度排序而非按影响因子排序。选题时你最怕的不是问题不够好而是做到一半发现环境搭不出来。规划类论文往往依赖很大的搜索空间具身类论文需要模拟器工具调用类论文大多只需要 API 调用记录。我建议在正式立项前做一个“48 小时复现测试”选三四个候选论文每个花一天时间只做最小难度的复现能跑起来的留下跑不起来的直接淘汰。这个测试几乎不花成本却能帮你躲开八成的工程陷阱。做完这四步你会得到一张相当清楚的地图每一个细分方向上谁做了、谁没做、谁做砸了、谁可能接着做。到这一步你才有资格谈“创新”二字——你不是凭空想一个题目而是在地图上找到一处别人还没下脚的空地。4. 选题落地前必须想清楚的三件事算力、评估稳定性、基线公平性好的选题是一回事能顺利出成果是另一回事。我在看别人开题报告和实际项目复盘时见过太多项目死在“题目很漂亮执行没回头路”上。这里有三件事我建议你在正式投入两个月之前就琢磨清楚。第一件事是算力成本。很多 Agent 方向的论文看起来只是调 API成本主要在 token 消耗上但如果你的实验设计要跑很多轮、每组对比要重复多次累计消耗很惊人。我在调研时遇到过一个项目原本只设计了五组对比结果临提交前审稿人要求补实验一补就是多两万块的 token 开销。我现在的习惯是立项前先用一个小规模集跑通全流程估算出单次完整实验的成本乘以你计划中的实验组数和重复次数再乘以三倍作为安全余量。算下来心里没底就果断压缩任务长度或者换一个更便宜的可控环境。第二件事是评估稳定性。Agent 评测和普通模型评测有个致命的区别同一个任务让 Agent 跑三次结果可能完全不一样。很多场景下LLM 的生成随机性、工具调用的网络延迟、外部服务的返回波动都会叠加放大。我建议在准备实验的第一周就做一次“稳定性基线测试”固定种子跑同一批评测任务看指标方差有多大。如果方差已经大过你要验证的效果量那这个方向就需要先设计更稳定的评测协议或者增加足够的重复次数。这个环节没有捷径但这一周花得越早后期回头的成本越低。第三件事是基线公平性。Agent 方向最常犯的错误是拿最弱版本的 baseline 和自己对比证明自己的方法好。这种做法骗不了审稿人但更严重的是它会骗过你自己——让你误以为自己的方法真的有效。比较稳妥的对照组设计至少要有三层完整版方法、去掉核心模块的消融版、以及一个不属于你创新思路的强基线。好选题的特征是你的完整版能稳定赢过这所有对照组并且你能解释清楚赢在哪一步。还有一个我反复踩过的坑是“选题范围开得太大”。很多同学一写方案就想要“通用 Agent 框架”想让自己的方法适配一切任务。我之前也栽过——项目做了一半才发现为了通用性做了无数个 if-else每个场景都跑通但没有一个场景特别出彩。相反那些把问题收窄到“文档密集型的多跳问答场景下的记忆唤醒机制”这类清楚目标的工作实验更聚焦论文也好写得多审稿人也不会一直追问“你这个能不能泛化到别的任务”。先在一个精确定义的场景里把效果做扎实再谈扩展这个顺序几乎是所有高引工作共同遵循的节奏。最后再分享一个我的个人习惯。我会把候选选题按照“验证成本”和“审稿人接受度”两个维度分成三类绿色标注的是低成本且有明确产出的可以先推进黄色标注的是中等成本但方向可持续的适合作为主线储备红色标注的是机会很大但工程极重或风险极高的我会先保留问题设定等到资源和时机合适再启动。做完这次调研我自己最大的体会是Agent 方向并没有变难它只是从“谁都可以做做看”的粗放期进入了“需要精确选择战场”的深水期。谁先学会系统地画地图、找缝隙、算成本谁就能在这个阶段跑在前面。
阅读完成 · 觉得有帮助？
