用 Agent 辅助科研，一些经验
最近一直在用 Agent 辅助科研，互相折磨了一段时间后，完成了从整理文献、修改正文、检查图表，到投稿的全流程。有了些经验，作为记录。
在最开始，我像和传统的 chatbot 对话一样，在不同对话窗直接命令执行 Agent 去做研究的各个步骤。但随着任务变多，首先遇到的问题不是它做的正确与否，而是它的执行速度很快超过了我的审查速度。它毫不费力吐出成千上万字和 N 个中间文件，我完全无力审查。
为了解决这个问题，经过摸索，我逐渐形成了一个三层结构，用下来还比较顺手。
第一层是研究者，也就是我。我负责判断研究问题是否值得、证据能支持多强的主张、一次修改究竟有没有让论文变好，以及项目是否值得继续投入。这些判断的源头和具体执行都由 Agent 来，但不能让它自动决定。
第二层是总控对话。这是固定、高频与我直接交流、对话的一个固定窗口，类似于一个掌握所有要求和进度的秘书+项目经理。在此之前，这些讨论被我都放在执行 agent 中，和来回操作文件融在一起。但研究和 coding 一个很大的不同在于标准模糊，并不存在一个“跑起来”一般的稳定状态，尤其是在概念、观点层面的来回可能完全推导前序的分析工作。为此我试过引入 Git 来做版本管理，但实在太重，而且问题其实主要是出现在上下文召回上，同一对话来回拉风箱形成的超长上下文让当时的 GPT5.5 明显降了智。随后我引入了这个总控层，这一层目的就是把过程推敲讨论从执行中隔离出来。在 Codex 中它始终是同一个窗口对话，一篇论文周期里至少经历了上百轮对话，由于基本都是对话，并不涉及复杂的文件操作，上下文召回总的准确性能出乎我预料。在实操上：对于执行结果，我会让他做初步审查返回要点，交由我判断，避免让我直接面对海量内容；对于要改的内容，我会给自然语言描述，它帮我把意见转成边界明确的任务（prompt），当前应该读取和修改哪个文件，有什么要求。然后转交给：
第三层执行 Agent。它们直接处理范围清楚、可以独立验收的工作，例如参考文献核查、Methods 事实框架、图表方案、格式审查、匿名化检查和投稿包生成。执行 Agent 不需要理解整个项目，只需要知道自己的任务、必读材料、证据边界、禁止事项和交付标准。
简而言之，我在研究中间增加了一个长期总控对话，让它负责初步审查、拆解任务、维护项目状态，再把边界清楚的工作交给其他 Agent。
事后来看，Agent 最适合承担的是高成本但可检查的研究劳动。检查引用、图表编号等等，这些工作琐碎，但都有清楚的对错标准。相反，“帮我提升论文贡献”“看看还能讲出什么机制”一类任务很危险，因为它很容易让 agent 把没有证据的解释包装成完整论证。
Agent 带来的主要问题也发生在这里：它把生产变得太便宜了。
- 文字可以过度生产。一个简单判断会被展开成许多概念，制造一种内容丰富的错觉。
- 边界也可以过度生产。为了避免越过证据，Agent 会不断补充限制和免责声明，最后论文主线反而被防御性表达淹没。
- 审查同样可以过度生产。两个意思相近的句子，审查 Agent 也能列出一长串差异，仿佛每处措辞都关系重大。
- 文件更容易过度生产：revision_v1、v2、v3，audit、historical draft、submission package，每一份都像进展，最后却可能没人知道哪一份才是当前源稿。
这些问题源自同一个原因：Agent 可以继续生成，却不知道继续生成是否还值得。
我的做法是在研究初期，尽早和 Agent 讨论，建立目录导航指引、README、执行标准流程，并不断更新，把任务、版本、证据和边界落到文件里。这样做降低了上下文丢失的风险，也让后续 agent 不必从零猜测项目状态。
这些文件看起来像额外的管理成本，实际上是在给不同 Agent 建立同一个世界。Agent 不知道哪个旧计划已经失效，也不知道一个文件名相似的版本是不是正式稿。没有导航，它只能把眼前最像答案的材料当成答案。上下文越多，这种误判未必越少，反而可能更加隐蔽。
总控层也不能彻底解决这些问题。它可以替我做第一轮检查，却同样可能过度审查；可以提醒我两种表述存在差异，却不能自动判断这种差异是否值得花半天修改。
尤其在自己并不熟悉的领域，交叉审查确实能暴露原本看不到的问题，但审查意见一旦超出我的判断能力，增加更多 Agent 通常只会增加更多相互竞争的说法。这一点还没有什么特别好的办法，只能在审查与放松之间找平衡。人还是很难赚到认知以外的钱。
这也是我现在刻意保留人工交接的原因。我会先看总控对话整理出的任务，再亲自确认并转交执行 Agent。复制粘贴当然不高效，但这个停顿迫使我知道任务正在从哪里走向哪里。全自动流程减少了一次操作，也可能顺手取消一次本该发生的判断。
另一个关于 skill 的额外经验是：与其寻找一个能“一键写完整篇论文”的大 skill，不如针对局部任务定制几个小 skill。Introduction 的 polish 需要处理问题递进、论证张力和研究必要性；Methods 的 polish 更看重可复现、无歧义和口径稳定。它们都叫 polish，背后却是两套不同标准。真正有用的 skill，通常只是把某一种质量标准写清楚，再通过反复使用逐渐修正。
Agent 把论文写快以后，变慢的是判断。而问题、边界和取舍，仍然是研究者自己的工作。