关于如何用一串相互独立的 agent 跑研究实验——从写实验计划到落地执行——所沉淀下来的一组准则。核心只有一句:持久的是文档,易逝的是上下文。
Agent 是任务的临时载体,不是文档的看护人。任务一完成,上下文就作废;下次要动同一份东西,开新的、从干净文档冷启动。文档活在 git 里、活在交接链里,是持久的;agent 是一次性的,用完即弃。
每一层只读上一层交给它的那一份交接文档,不继承上游的原始上下文。交接文档是上游产出的"定向压缩"——该带的脉络都沉淀进文档里,所以下游不必回头翻更上游的东西。
为什么做、假设是什么、实验设计能不能回答你的问题。整条链唯一只能由你判断对错、agent 无法自验的一层。错了后面全废,但 token 量小——把钱和注意力都砸在这里。
把抽象计划翻译成具体改动:改哪些文件、什么顺序、怎么验证。必须在此固化数据契约——用哪份数据、确切路径、字段语义、版本。代码库越复杂越往上靠。
按工程文档改代码、跑测试、调 bug。"想"的部分已在前两层做完。若它频繁要自己补决策,说明工程文档不够细——回去补文档,而不是给它加 model。
跑实验、收数据、监控、判断结果。debug 完成那刻,实现的上下文就归零——执行 agent 从干净的执行说明冷启动,不背调试噪音。它若回头改代码,是分层破裂的征兆,问题该退回实现层。
真正的分配原则是——哪一层需要做最多不可逆的判断,就给哪层最高 effort。这条链的决策是前重后轻的,所以 model/effort 也前重后轻。
预算紧时,最该省的是实现/执行层(便宜模型 + 低 effort),最不该省的是规划层。把钱花在"想错了代价最大"的地方。研究场景里规划层会被反复迭代、执行层相对一次性——这又是把好 model 留给前两层的理由。
该立即中断:变更触及了下游 agent 当前正在依赖的前提。继续做就是在错误地基上盖楼——停掉,从更新后的文档冷启动。沉没成本不要救。
不该中断:变更只影响还没开始的步骤,或是平行新增。让当前自洽的单元收尾,变更排到后面。强行打断会留下半成品状态,更乱。
比"中断 vs 不中断"更治本的,是从结构上降低中断代价:
把实现切成可独立交付的小单元,做完就 commit。上游任何时候要改,损失最多一个单元而非整条链。中断的痛感和单元粒度成正比,单元越小越不怕改。
上游产出"相对原计划改了哪几条、为什么",而非重写整份文档。下游能精确判断自己手上的活受不受影响,你也审得快。
别让下游自己决定要不要响应变更——它没有变更的来龙去脉,易误判。上游出 diff → 你看影响范围 → 决定收尾还是立刻停 → 重新下指令。
若上游频繁在下游开工后才推翻计划,真正的信号是规划层 effort 不够或迭代太早。把"改计划"尽量压到下游启动之前,比"如何优雅中断"更根本。
agent 自发去找数据位置,不是它多事,是上游没把这件事定死、它执行时缺信息又不能停,只好自己补——自动模式下连补错了你都不知道。根因在文档缺项,不在 agent 行为。
自动模式只适合"确定性的、错了也容易发现"的步骤(跑命令、改代码、跑测试)。数据源和数据语义的正确答案只在你脑子里——它无论多努力都是在猜。把这类步骤挖成强制停顿点,比"调教 agent 别找错"可靠得多。
撞到 bug 的那个 agent,是带着对数据的错误理解才暴露出问题的。让它就地修,等于让被污染的理解去纠正它自己错的东西——很可能改成它以为对的样子,错上加错还更自信。新指令并不能真正擦掉旧认知,两套会在它脑子里打架。
1. 执行 agent 撞错 → 不自行修改,停下并报告(哪条数据、什么问题)
2. 启动独立的纠错 agent(上下文干净,理解从零重建)→ 核对正确格式、修复、回显校验给你确认
3. 产出更新后的数据说明 → 提交,commit 写清改了什么格式、为什么
4. 全新执行 agent 从干净状态用修好的数据重跑。被污染的那个就此关闭。
改的是数据来源 = 改的是执行的地基,地基换了就重建,不在旧地基上贴告示。
同理:若你改了处理脚本(如从一级数据改用二级数据),正在跑的执行 agent 不能"只告诉它脚本更新了"就续跑——这正好改变了它赖以工作的前提,属于触及核心依赖,停掉重开。你新开 agent 改脚本是对的,差的只是别回头激活旧执行 agent。
四份文档同等强度审本身就是浪费。判断一份内容值不值得细看,看三点:是不是只能由你判断对错(外部知识)?错了是否不可逆或难察觉?有没有下游机制(test、回显)能兜住?
逐行审的冲动来自不信任流程。但信任该建立在机制上:test 兜实现、回显兜数据理解、diff 兜迭代。机制覆盖到的地方,逐行读是重复劳动;覆盖不到的地方(假设、数据来源),才是你不可替代、必须亲自盯的。
每份文档顶部放"人类审查区"——核心决策、关键假设、最可能错的地方、需你拍板的取舍,压到一屏内;下面才是"agent 执行区"的完整细节。你只读上面那段确认方向即可放行。读不动是文档的责任,不该靠你硬扛。
你定方向("把 A 换成 B、因为 X"),agent 落地,你审 diff。别把精力从"判断"挪到"当文字编辑"。HTML 这类手动改困难的格式更要交给 agent。
计划/工程文档/执行说明全程用 Markdown:agent 改起来无标签负担、git diff 清晰、你随手能改。确实要 HTML 形态的,只在定稿后转一次。你说的"改 HTML 有延迟"本质是用展示格式做了迭代工作,换回 MD 就治本。
commit message 带上放行语义("实验计划 v2:改用方案 B,因为…"),git 历史本身就成了决策记录。最终 git 历史和那条 agent 链同构——每个 commit 对应链上一个被你拍板过的节点。
何时关:交接文档放行、交付下游那一刻,上游 agent 即可关。不用留备用——它上下文里剩的全是写文档时的探索噪音,留着只占心智。
事后要改文档:开新 agent,不要恢复旧会话。旧 agent 带着当时已过时的思路和成见,新旧认知会打架。新 agent 读"已放行文档 + 你新发现的内容",两个都是干净输入,理解从正确起点重建。改完同样关闭。
改一份已交付的中间文档,记得顺着链往下看波及范围:产出 diff,判断影响不影响下游已做的部分;影响了就让对应下游也从更新后的文档冷启动重做受影响的单元。
默认链式、单份交接:下游只读直接上游那一份。交接文档是累积的(带着上游的关键脉络),不是替换的——所以读一份就够,不是信息丢了,是上游帮它压缩沉淀了。
受控例外:出问题诊断时(如执行结果异常,要判断是实现 bug 还是假设本身错),合理地向上回溯翻工程文档甚至实验计划。该禁止的是"不出问题就主动读一堆上游文档";该允许的是"诊断时按需回溯"。若下游不出问题就总得读多份才能干活,是上游那份交接没写够——回去补文档。