Agent 的交付物不该只有终稿

2026-08-25

我自己带着一个写公众号文章的 Agent 干活。它跑完一次任务，落到硬盘上的不是一篇 markdown，而是一个目录，里面有六个带编号的文件。这个形态不是我一开始就想清楚的，中间被现实修过一次。这篇写的是那次修改，以及我事后才想明白的那件事。

先说清楚：这是我自己那条流程里的安排，不是什么通用规格。你如果只跑单篇、跑完就贴出去，下面这些多半是多余的。

一次任务落盘的，是一个目录

我那条线上，一次任务结束后的目录长这样：

wechat-articles/YYYY/YYYY-MM-DD-文章主题/
├── 01-source.md      原始链接、主题和素材
├── 02-direction.md   备选方向和最终选择
├── 03-outline.md     确认后的提纲和主要观点
├── 04-references.md  补充资料和引用来源
├── 05-article.md     公众号文章正文
└── 06-cover.png      文章封面图

六个文件里，真正意义上的”交付物”只有两个：05 是正文，06 是封面。剩下四个都是过程。

顺带交代一句现状，免得这张图被读成比实际更完整的样子：这条链路的交付终点就是”文章和封面已生成并保存”，往微信公众号草稿箱写入这一步至今没有接通。也就是说，上面那个目录不是中转站，它就是终点本身。这更让人不得不认真对待——如果最后停在这里，那这里躺着的东西必须自己就能说明白发生过什么。

我不是设计时想明白的，是回头找东西时被逼出来的

这一段我本来最想跳过，因为结论听上去挺顺理成章。但发现的过程其实比结论更值钱。

真实情况是：我中间改过一次文章目录的命名。原因很朴素——当天写的文章没有次序，找起来伤神。

早期那批目录，名字是日期加一个随手起的后缀，同一天的第二篇就在后面加个数字，主题还没定下来的时候干脆用占位词顶着。这种名字在”一天写一篇”的时候完全够用：日期就是唯一标识，一眼定位。可一旦一天跑了不止一次，它立刻退化成一堆看不出先后、也看不出内容的兄弟目录，得挨个点进去看才知道哪个是哪个。

后来我把命名改成了在日期后面插入当日序号，再接主题词。改动很小，但它是被”我找不到自己的东西”这件事逼出来的，不是设计阶段推演出来的。

这件事真正的价值不在命名本身。它逼着我第一次以”读者”的身份去打开自己的产物目录——不是以生产者的身份，而是以事后要来翻它的人的身份。一旦换了这个视角，很多当时觉得理所当然的安排就站不住了：为什么方向和提纲要单独存？如果只留终稿，我事后翻这个目录的时候，能不能重建出当时到底发生了什么？

答案是不能。终稿是结论，结论不解释自己。

闸门在哪，文件就落在哪

想通之后回看，这个目录的编号顺序其实是跟流程里的人工确认节点对齐的。

我这条流程有三个常规闸门，卡在”方向 → 提纲 → 终审”这三处。它们的共同点是：都发生在一次信息量收敛之后。方向定错，后面全废；提纲定错，正文全废。闸门设在返工成本发生跳变的位置，而不是均匀撒在流程里。除此之外还有几个闸门，但都不在正常路径上——成因分两类，一类是技术异常（素材读不了、外部授权出问题、发布环节报错），一类是人工不放行（高风险内容需要放行、看完终稿后要求修改）。这些平时不触发。

真正每次都必经的，就是那三个。而这三处恰好对应着 02 和 03 两个文件，加上最后的 05 和 06。

于是这个目录的关键设计就浮出来了：它存的不是终稿，是每一个人工确认节点的输入与输出。

02 存的不只是”最后选了哪个方向”，还包括”当时给了哪几个方向”。这一点特别关键——只存被选中的那个，等于把选择过程抹掉了；把候选一起存下来，事后才能判断当时是不是选窄了、有没有一开始就漏掉某个角度。

03 存的是”确认后的提纲”，即通过闸门之后的那一版，不是 Agent 自己生成的初版。这个区别决定了它能不能当依据用：确认后的那一版才是我签过字的东西。

一句话概括：闸门处的决定被固化成了文件，而不是留在对话记录里。

我实际改掉的是命名，落盘结构本来就是这么定的

这里得诚实一点，别把复盘讲成一个更漂亮的故事。

被现实打过脸、我动手改过的，是目录命名那一处。至于”每个确认节点都单独落盘”这个结构，是这条线设计时就定下来的，我没有从”只存终稿”改到”存六个文件”的经历。我事后才真正理解它为什么重要，但它不是我踩坑踩出来的。

我把这两件事分开说，是因为它们的可信度不一样。命名那条有真实的失败作证据；落盘结构那条只有我的解释。你可以拿走前者，后者最多算一个值得你自己去验的假设。

命名那条能提炼的判断倒是很硬：产物命名的排序能力，要按峰值频次设计，不是按平均频次。日期粒度在”一天一次”时够用，在”一天多次”时立刻失效。而平均频次永远看不出这个拐点，因为它把峰值抹平了。

能带走的那句话

对话会散掉，文件不会。

这是我从这一次里带走的东西。Agent 跑的时候，人和它之间的每一次确认都发生在对话里——你在那一刻确实做了判断，也确实说清楚了理由。但对话是流水，翻上去很难，翻上去了也难对齐到具体是哪一步。而一旦这条链路要跑第二次、第十次，你需要的恰恰是”上次在这个位置我是怎么定的”。

所以我现在的判断是：**凡是需要人确认的节点，那一处的输入和输出都值得单独落盘。**判据不复杂——问一句”如果三个月后有人（包括我自己）来问，当时为什么是这个方向，我能不能不靠回忆就答出来”。答不出来，就说明这个节点的决定没有落地成文件。

再往前推一步，这条判据对”可移交”是有直接价值的。一份只有终稿的交付，接手的人只能看见结果；一份带着过程的交付，接手的人能看见判断是在哪几个岔口做出的、当时还有哪些没被选中的选项。前者只能照抄，后者才能被理解和修改。

这篇写的是我自己那套流程里的一次实际情况，不是通行做法。你的场景、工具和团队规模不同，结论未必适用，判断方式可能比结论更值得拿走。