自用 Agent 走向可移交：要拆掉哪些东西

2026-08-25

我自己搭了一个写公众号文章的 Agent，链路从收到素材、确认写作方向、确认提纲、核验资料，一直跑到正文和封面生成、按结构保存到本地。自己用着挺顺，运行了一段时间，我对质量基本满意。

问题出在我动了「把它挪出这台机器」的念头之后。第一个卡住我的东西小得有点可笑：成果目录写死了我本机的绝对路径。改成配置项就完事了，但我改完那一行之后没能停下来——因为我意识到这类东西不太可能只有一处。一个只跑在我自己机器上、只由我一个人触发、只由我一个人验收的 Agent，它「离得开我」这件事，从来没有被验证过一次。

下面写的是我自己这一次的实际盘点，不是什么通用清单。

我是怎么发现的

不是靠一次事故发现的，这一点值得说清楚，因为发现方式比结论有用。

事故是有的，但事故都指向别的方向。比如有一次流程停在了确认提纲那一步，消息通道上没显示出来，我等了一会儿觉得不对，主动去问了一句「提纲我没有看到，请显示出来」，流程才继续。当时我把它记成了一个送达问题——闸门依赖消息送达，送不到流程就会静默停住，Agent 以为在等人，人不知道该自己动。这个结论没错，但它掩盖了另一层：当时之所以能救回来，是因为我知道流程该停在哪一步。换一个人坐在那里，他看到的只是「没动静」，连该不该催都判断不了。

再比如目录命名。早期一天写多篇的时候，目录名只带日期，同一天的几个任务只能靠 another、another2、sth 这样的临时名字区分，我自己回头找都伤神，后来在日期后面插了当日序号才理顺。当时我提炼的是「产物命名的排序能力要按峰值频次设计，不是按平均频次」。也对，但同样掩盖了一层：伤神的是我，我至少还记得那天写了什么。

所以真正的发现方式是：**我把「换个人跑」当成一次检查动作，而不是当成一个远期目标。**具体做法很笨——拿着已经有的那几份东西，一份份地问同一个问题：这一条离开我还成立吗？不成立的，就是要拆的。

这个问法之所以有效，是因为它不依赖出事。一个 Agent「离不开我」是不会报错的。它在我手上跑得越顺，这件事被暴露的可能性越小。

为什么自用时看不见

自用的时候，我本人是运行环境的一部分，而且是没有被声明的那一部分。

我在写内容的那条线上很习惯于怀疑——因为写内容没有客观真值，字数可测但好坏不可测，所以每一步都得人工确认，失败是显性的：字数不够、事实核不到、评审判不通过，都会当面告诉我。

但写代码那条线不一样，它有客观真值：构建能不能过、测试红不红。反直觉的地方就在这里——有真值反而更危险，因为「有真值」会让人停止怀疑，看到退出码是 0 就认为成功了。我这条产线上真实出过的几起事故，全都是这种形态：过滤器写法不对，匹配不到任何目标包，命令正常退出，「构建通过」是假的，其实什么都没构建；传输中断了，脚本照常打印「已上线」；新文件路径没匹配上，被静默跳过，一整批实现丢在了提交外面。

「Agent 离不开我」属于同一类：它不吵。所以只能靠主动去数，不能靠等它出事。

三类要拆的东西

盘完之后，落到手上的其实就三类。

**第一类，写死的本机路径。**这是最好办的，也是我实际动的第一处：默认成果目录从写死的绝对路径改成环境变量或者执行细则里的配置项。好办的原因是它有明确的形态，能一眼认出来，也能一次改干净。麻烦的是它太好办了，容易让人改完就觉得移交这件事已经做完了。

**第二类，只在我脑子里的判断。**这一类是大头。我的工作流卡片里有十二个判断点，每一个都写成「判断点 + 判断依据」两段——先写怎么判，再写为什么这么判。后半段看上去像是多余的——判据写清楚不就够了吗。不够：只写「怎么判」，执行的人一遇到卡里没写到的边界情况就没法推广；补上「为什么这么判」，才可能在卡里没覆盖的情况下做出跟我一致的决定。

具体一点。选题这一步的判据是三个硬门槛：有可靠依据、能解释深层机制、不是常识复述，三者缺一就换角度或者放弃。提纲这一步用删除测试：删掉这段，读者会不会失去重要认知或行动依据，不会就删。资料核验这一步只查会影响核心结论或读者决策的数字与事实，非核心又确认不了的直接删掉，核心依据确认不了就换观点。这些判据我自己执行时几乎不用想，但它们能被交出去，靠的是被写下来这一步，而不是靠我想得清楚。

同一类里还有几处不那么显眼的：岗位卡的成功标准我写成了「做对了」和「做错了」两组对照，不是单向的目标列表——其中「未经过你的确认便直接公开发布文章」被明确放进了「做错了」那一组，也就是说流程违规本身被定义为失败，跟内容质量并列。「本期不做」是独立的一段，五条：不绕过人工确认发布、不编造事实数据案例引用、不洗稿或大段复制、不擅自处理高风险内容、不使用版权不明素材。人工兜底分成两类写，一类是异常触发的介入条件，一类是常规必经的检查环节——兜底和闸门是两回事，混在一起写，接手的人会以为每一条都得等人。

这些段落之所以要拆开写，不是为了好看。是因为我在场的时候，这些区分靠默契就能维持；我不在场，默契就只剩下文本。

**第三类，只有我知道的验收标准。**这一类最隐蔽，因为它平时表现为「我看一眼就知道成没成」。

我这套东西里给草稿链路写死过一条成功判据：以接口返回标识之后再次查询草稿列表为准，并且明文写了禁止把「接口已提交」误报为「草稿已创建」。得说清时序——这条判据是写在说明书里的，那条链路本身至今没接通，它是我在还没做这个功能之前就先写好的验收标准，不是一次已经发生的事故。

后来我给它补了一条边界，因为「全部都要回查」不现实：回查本身有成本，也可能失败，也可能读到过期的缓存。链路很短、失败了立刻就能看见的动作，比如往本地写一个临时文件，配回查属于过度设计。**我用的判据是：只要这个动作的结果会被下一步当作前提使用，就必须回查。**前提一旦是假的，后面所有步骤都会在这个假设上继续跑，而且跑得很顺，最后交出一份看起来完整的错误产物。

同一条规律我在三条不同的线上各撞过一次：外部接口返回成功不等于目标对象已创建，编排层报完成不等于文件已落盘，退出码是 0 不等于事情办成了。三次都是独立踩到的。所以移交的时候，验收标准要从「我看一眼」改写成一个别人也能去回查的具体状态。

配套的还有两处小的。一是产物落盘的自检要校验内容特征而不是文件名——我这边出现过封面文件名写着一种扩展名、文件头其实是另一种格式的情况，本地保存不报错，接到下游才会暴露。二是交付物不只留终稿：我把每一个人工确认节点的输入和输出都单独落盘，备选方向和最终选了哪个存一份，确认后的提纲存一份。这样闸门处的决定被固化成了文件，而不是留在对话记录里——对话记录只有我看得到，文件是可以交出去的。

这只到「可移交」，不到别的

得把边界说死。

我没有接过单，没有给客户交付过，也没有走到报价那一步。这篇里关于「交出去之后会怎样」的部分，一个字都没有，因为我确实没走到。所谓「可移交」，我给它的定义很窄：换一台机器、换一个人，能按同样的判断跑出同样形态的产物。仅此而已。

而且这套东西本身也没做完。整条链路里还有一处至今没接通——公众号草稿箱的写入。它的交付终点目前是「文章和封面已经生成并保存」，不是「已经进入草稿箱」。岗位卡里那句一句话定义写着交付终点包含保存到草稿箱，那写的是目标态；现状是没通。我把这两者的差别摆在这里，是因为一份把自己的缺口藏起来的说明，本身就是不可移交的。

从这一次里能带走的一句话：自用与可移交之间的距离，等于「我这个人」在流程里承担了多少未被写下来的功能——路径、判断、验收标准，三样都算。把它们逐一拆出来落成文件之后，剩下的才是这个 Agent 真正拥有的能力。

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