技术 · 熟练
同一件事做第二遍，别再让它重读一遍
读一遍输出要付一次钱，重跑一条脚本不用
Agent 干活时最贵的一步，往往不是「做」，而是「想清楚怎么做」。同一个测试跑第二次、同一份报表第三次生成、同一个目录第四次清理 —— 每次它都要把上一轮的输出重新读进上下文，再重新推一遍该用什么命令。这一页讲的是把这一步的产物留下来：让 agent 把自己写过的脚本存起来，下次直接重跑。判据一句话：这件事第二次做时，命令是不是和上次一样 —— 是，就该有脚本；不是，就还该让它现场想。顺带说清三档处置（读、压、重跑）各自适用在哪。
方法 · 一图看懂
1
分清「想」和「做」 — 重读一遍输出去推同一条命令，付的是 token 加一次判断；脚本把这个判断的产物留下来
2
三档处置先选对 — 压缩（少读）、卸载到外部存储（留引用可回取）、重跑脚本（不再读）—— 三者代价不同
3
固化前过四问 — 输入能参数化 / 成功与否能判定 / 可重入或幂等 / 失败能回退到「现场想」
4
脚本要进版本库 — 不进库的脚本等于没写；下次它在别处又重推一遍，你还查不出为什么
5
定期清 — 脚本会腐烂：命令变了、路径变了、依赖没了；留着不跑的那条，比没有更危险
原理 · 为什么有效
模型每次「读输出 → 想命令」都要重新付一次上下文与一次判断，而这两样都不便宜：读进去的是十几 KB 的输出，付出去的是推理步与工具调用。脚本不是「更聪明的做法」，它只是把已经想对的那一次留下来。所以它省的不是算力，是重复判断。反过来说，脚本也不是越多越好 —— 一条只跑过一次的脚本、一条参数写死的脚本、一条没人维护的脚本，都会在下一次把错误变成既定动作。判断标准回到那句话：这件事第二次做时的命令，和第一次一样吗。一样才值得固化；不一样，说明它还需要现场判断。
适用场景
适用：固定流程的重复执行（测试 / 构建 / 数据导出 / 目录清理 / 报表生成）；你已经在用 agent 做同一类事超过三次；同一批命令每次只差几个参数。不适用：一次性的探索性任务（先跑通再说）；命令每次都要按当时的输出调整（那正是需要判断的地方）；涉及删除、发布、改线上配置的动作 —— 这类脚本必须保留人工确认，⛔ 不要做成「静默重跑」。另一条边界：⛔ 别把它当「缓存」用 —— 脚本缓存的是动作，不是数据；数据变了还重跑同一条命令，得到的是错答案。
自测 · 5 问
我说得出哪件事已经被 agent 做过三次以上，且每次命令基本一样
这条脚本的输入是从外面传的，不是写死在里面的路径或文件名
脚本跑完能自己判断「成了还是没成」，而不是打印一堆输出等人看
脚本失败时，agent 会回到「读一遍再想」，而不是硬着头皮重试
我知道哪些脚本已经过期了，并且已经把过期的那几条删掉
怎么上手 · 验证步骤
上手顺序：① 先只固化一条 —— 挑那件你已经重复过三次、且每次命令都一样的活 ② 让 agent 把它写成脚本，并要求它把「怎么算成功」写进脚本（返回码、关键输出行、产物大小任选其一）③ 把参数抽出去（路径、批次号、时间范围），脚本里只留逻辑 ④ 下次让它先找脚本再动手：把「先看有没有现成脚本」写进你的指令里，而不是靠它自己想起来。做完这四步再考虑第二条 —— 一次固化一堆脚本，最后一条都跑不起来。
自检动作：翻一下最近三次同类任务的对话，数一数「它读进来的输出」有多少是重复的。如果三次读的是同一份目录清单、同一份测试输出，那说明这里本该有脚本；如果三次的命令确实各不相同，那这里就不该有 —— 别为了「看起来工程化」而固化。再做一件事：把脚本目录打开，问自己「这一条上次跑是什么时候」，答不出来的，删掉。