Agent 产物的命名要按峰值频次设计，不是按平均频次

2026-08-25

这件事发生在我自己搭的一条内容流水线上：我让一个 Agent 帮我写公众号文章，它每跑完一次，会把这一次产生的全部中间产物落成一个目录。改命名规则是我中途做的一次修正，不是一开始就想明白的设计。

先说这套产物长什么样。一次任务对应一个目录，目录里是编了号的六个文件：原始链接与素材、备选方向与最终选择、确认后的提纲、补充资料与引用来源、文章正文、封面图。这么落盘的用意是把每一个人工确认节点的输入和输出都单独存下来——我选了哪几个方向、最后挑的是哪个，提纲确认成了什么样子，这些决定不留在对话记录里，而是固化成文件。这一层我当时想得比较清楚，也一直好用。

这里有个连带效果我当时没往下想：既然每跑一次就要落一整个目录，那么目录的数量会跟着跑动次数一起堆起来，而我打开文件夹时唯一能一眼扫到的东西，只有目录名这一行字。目录里面设计得再整齐，也得先找到是哪个目录才用得上。

同一天出的几个目录，彼此认不出来

早期的目录名是这样的：

2026-08-24-another
2026-08-24-another2
2026-08-24-another3
2026-08-24-sth

日期是准的，后面那半截是占位词。another、another2、sth 这类词，是任务主题还没定下来时随手给的临时命名，后来也没人回头改。

把这几行摆在一起，两个毛病同时露出来。一是它们的排列顺序不表达产生顺序——another2 排在 another3 前面是字典序的巧合，sth 跑到最后面也是字典序，跟我实际先写了哪篇没关系。二是后半截根本不说明内容，看名字猜不出哪个是哪个，只能一个个点进去翻 05 那份正文。

这两条叠起来的效果是：同一天的产物，我既没法靠顺序定位，也没法靠语义定位。

我不是在跑的时候发现的

这一段我觉得比问题本身更值得记。

命名的毛病在生成环节是完全无感的。跑任务的时候，我的注意力全在内容上——确认写作方向、确认提纲、终审这三处闸门我都在场，每一次都要读、要判、要点头，目录名只是顺手落下来的一个字符串，它长什么样不影响这一次任务的任何一个判断，也不会报错。

真正暴露它的动作是「回头找」。具体是哪一天撞上的，我没有留下记录，能确认的是场景：我要翻回去看当天写的某一篇，从目录列表里扫过去，发现自己得靠打开文件来认人。那种伤神很具体：不是找不到，是每找一次都要多做一轮无谓的辨认。

我从这里带走了一个检验习惯：Agent 产物里凡是「Agent 写、人读」的部分，都不会在生成环节暴露问题，因为写入和读取发生在不同的时刻，中间隔着几天甚至更久。要检验这类字段，靠再跑一次是没用的，跑一百次也还是那个感觉良好的瞬间。有效的动作是隔一段时间去找一次旧产物，看自己需要几步才能定位到目标。找起来别扭，就是命名该改了。

为什么日期粒度会失效

事后看，是两个原因叠在一起。

一个原因是频次。日期粒度的命名，隐含的前提是「一天最多一件」——只要一天只落一个目录，日期本身就是唯一标识，够用。我当初为什么把粒度定在这一层，具体的考虑我没有留下记录；能确认的只有实际情况和这个前提对不上：同一天出现了多个目录，一天之内跑好几次成了正常状态。日期这一段一旦失去区分能力，全部的区分压力就压到了后半截那个词上。

另一个原因是，后半截那个词恰好是最不可靠的一段。它要能概括这一篇，得等到方向确认、提纲成型之后才有着落；而目录建起来的时候，主题往往还是模糊的。于是先占个位——another、sth 就是这么来的。占位本身没错，错在没有一个不依赖主题、也能天然带序的部分来兜底。

所以这不是「忘了取好名字」，是命名规则里唯一可靠的那一段（日期）分辨率不够，唯一有分辨力的那一段（主题词）在需要它的时刻还不存在。

改成了什么

改动很小，在日期后面插了一个当日序号：

2026-08-25-01-clay
2026-08-25-02-chataigne

就多了两位数字，但它接管了原来压在主题词身上的全部负担：

字典序重新等于时间序，列表怎么排，当天的先后就怎么摆着；
一眼能看出这是当天的第几次，不用打开文件；
后半截那个词从「唯一的区分手段」降级成注释——它写得好当然更好，写得潦草也不至于让人找不着。

有意思的是，同一套办法在目录里面早就用了。那六个文件从 01 到 06 全都带着序号，因为它们的先后是我设计出来的，写的时候就知道谁在前谁在后。而目录之间的先后是跑出来的，我在定规则的时候没把它当成一个需要排序的序列，就漏了。设计出来的顺序会被自然地编号，跑出来的顺序容易被当成没有顺序——我这次栽的就是这个。

顺带说一句，占位名本身是另一件事。序号解决的是「找不到第几篇」，解决不了「不知道这篇讲什么」。这两个问题长得像，成因不同，别指望一个改动同时治好。

我从这次带走的判断

一条命名规则够不够用，不取决于平均频次，取决于峰值频次。

日期粒度在「一天一次」的时候完全够用，在「一天多次」的时候立刻退化，中间没有缓冲带——它不会先变得难用一点、再变得更难用，而是从可用直接掉到不可用。这种断崖式的失效，是按平均值做设计时最容易踩的一类。

所以我现在给产物定命名规则时，问自己的不是「一般一天几次」，而是「最忙的那天可能有几次」。而且这个数在把活交给 Agent 之后会被重新抬高一档，因为决定跑几次的东西已经不是我一个人的手速了。凡是拿不准的，就把粒度往下多留一级——多加两位序号的成本几乎为零，等到堆出一屏认不出来的目录再回头改，成本是把已有产物全部重命名，还得记得哪些引用会跟着断。

再往外推一层，这条判断不只管命名。产物落盘时那些「现在看起来足够、频次一上去就不够」的设计，都值得用同一个问法过一遍：这个方案在最忙的那一天还成立吗。

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