03｜把兴趣变成研究问题

先从一次实际经历出发

“我想研究 Agent”是兴趣。“我想做一套更好的记忆系统”是方案。研究问题还要再向前走一步：你究竟不知道什么，知道以后有什么用？

例如你观察到：需求改了，Agent 在后续修改中又恢复了旧逻辑。先保留用户要求、当时的代码和交接记录，描述事实；不要立即认定是“模型不理解时间”。它也可能没读到文件、摘要漏了关键信息、测试写错了，或者代码里有与新要求冲突的旧注释。

一个好问题不是先选中某个原因，再找证据支持它。它允许这些解释竞争。

我们最初用“旧交接会不会误导 Agent”举例。继续检索后，至少找到三项很近的公开工作：

agent-memory-bench 已经让 Coding Agent 做实际任务，并包含旧事实被替换、事实相互冲突等条件。当前说明也明确，它主要测预先导入语料后的检索，不是完整的记忆自行更新过程。GiulioDER，作者仓库，2026 年公开项目，本次查阅 2026-09-07。
StateMemBench 已研究动态状态，包括撤回决定和旧值更新。因此“给记录加当前／作废状态”也不能直接声称新颖。Fan 等，Can Agent Memory Systems Track Evolving State?，2026-08-20。
Supersede 让 Agent 在连续会话后重写受限笔记，再仅凭笔记回答问题，已经涉及自维护记忆中的更新失败。Patel，Supersede，2026-06-25。

这意味着：既不能说没人测过旧记忆，也不能从第一个仓库的限制推出“整个领域都没研究自行更新”。必须把多个相近来源放在一起看。

那么还剩什么可以开始？可以先复现一个已知现象，再检查一个更具体的过程：Agent 自己更新交接后，在继续改代码时是否恢复废弃行为；这种失败发生在记忆写入、读取，还是实际执行阶段？

这仍只是待验证的方向。问答与改代码不同，说明了值得检查的理由；仅仅把问答换成代码，并不足以自动构成论文贡献。详细计划见课题 A。

可以用一句话检验意义：如果知道答案，谁会改变什么做法？

若发现某种摘要流程会把已经取消的决定重新当成当前要求，开发者可能调整摘要格式或增加执行前核验。若所有可靠对照都显示没有这种问题，也能阻止你为一个不存在的现象开发庞大系统。

相比之下，“把三个热门技术放在一起，看看分数涨不涨”还没有说明为何值得研究。它可能有用，但你要补上具体理由。

问题可以来自错误、效率、代价、适用范围和测量方法。你不必只找别人漏掉的一小块，也不必先创造一个领域。一个小实验可以帮助发现更大的问题，而不是预先限制你的上限。

可以用下面这个结构，先写自然语言：

我想知道，在连续更改需求的小型代码任务中，标明当前与作废状态的交接，是否比同等长度的普通摘要更少恢复旧行为。因为如果有效，开发流程可以更有针对性地保存变更；如果没有优势，就不应仅凭格式看起来清楚而增加系统复杂度。我会同时检查仍有效的旧要求有没有被错误删除。

这里已经有对象、条件、对照、结果与反面情况。它比“提出一种可靠、高效、通用的新框架”更接近能动手的研究。

再加两句：你预计结果怎样；什么结果会让你改主意。研究前有预期没有问题，问题是只保留符合预期的题目和结果。

复现目标： 在自己的环境中重做别人一个清楚的发现，学会实现与验收。

探索目标： 看失败集中在哪些情况，从记录里找新的解释。探索时可以改想法，但应保留改动记录。

验证目标： 在没被用来调方法的新任务上检查一个已经明确的判断。这时不能一边看答案一边反复改方法，再把最后成绩说成公平测试。

三者可以前后相接。你完全可以从复现开始；重要的是不要把复现包装成首次发现，也不要把探索中的巧合包装成已确认规律。

先问四件事：最接近的工作是否已经回答；题目和正确答案能否清楚定义；自己能否取得资源；预期发现是否会影响理解或选择。

如果只卡在实现，先把环境缩小。如果正确答案无法判定，先改题目和评分。如果已有工作完全覆盖，完成复现报告后换一个由证据引出的追问。如果几次预试没有现象，先检查题目太简单或方法有错，不必马上扩大到数百次。

这些判断不能机械化成“跑十次就必须放弃”。预试的作用是减少盲目投入，不是提前作普遍结论。

现在写下自己的问题段落，再进入下一篇。即使以后改题，这张纸也会告诉你：你原来以为在研究什么，后来为什么改变了。