Agent 工序的边界该切在哪：三类位置

2026-08-25

拆工序这件事，是在结果不满意的那一次才变成问题的

那个写公众号文章的 Agent，从收到一个链接到交出正文和封面，中间要做十几件事：读素材、判断选题值不值得写、给出几个方向、写提纲、查资料、写正文、拟标题、做封面、做最终风险检查、落盘。

一开始这些事是连在一起的一段描述。跑通了，但只要结果不满意，我就只有一份成稿可看，没法说清是哪一环歪的。方向本身选偏了？提纲没问题而正文没兑现？还是资料那一步就没查？重跑一次，还是整条重跑，改动和结果之间对不上号。

于是要把它拆成工序。「拆成若干步」这句话写起来毫无难度，难的是每一刀具体落在哪。一开始我是凭手感切的，切完自己也说不上来为什么切在这儿而不是那儿。后来才想明白：刀口的位置不是美观问题，它决定了三件具体的事——我能在哪儿插手、我能存下什么、失败的时候我能退回到哪儿。这三件事全都发生在边界上，不发生在步骤内部。所以「这里要不要切」这个问题，其实是「我需不需要在这里插手、留档、或者退回」的另一种问法。

三个当场就能自问的问题

我现在切工序，就问三个问题。任何一个答「是」，那里就落一刀。

第一问：这个地方需要我点头吗？

这是最好判断的一类。我那条流水线上，常规必经的人工检查只有三处：选择写作方向、确认提纲和主要观点、审核最终正文与封面并决定是否公开发布。这三处必然是工序边界，理由很朴素——闸门只能设在两道工序之间，没法设在一道工序中间。你要求 Agent「写到一半停下来等我」，它停的那个位置本身就已经是一个工序末尾了，只是你还没给它命名。

要跟异常触发的兜底分开。兜底是链接打不开、来源互相矛盾、授权异常这类分支上才走的路，不占正常路径，它们不参与主干工序的切分。

第二问：手里的东西换形态了吗？

从素材，到方向，到提纲，到资料，到正文，到封面。每一次「我手里拿的东西变成了另一种东西」，就是一刀。

这一问有个当场可用的动作版本：把这一步的中间结果单独存成一个文件，你能给这个文件起出一个名字吗？ 起得出，说明形态确实变了；起不出，或者只能叫「第三步的输出」，说明它和上一步的产物是同一种东西，那里不该切。

第三问：这步失败了，我要退回到哪儿？和上一处失败退回的地方一样吗？

正文写出来不达真人感要求，退回撰写正文这一步重写；核心依据核验不过，退回的却是评估选题价值——因为依据都塌了，这个选题还值不值得写要重新判断。两处失败的退回目标不同，说明它们中间必然存在边界，否则你没法只退一半。

这一问我在这里只作为三分之一列出。回退目标怎么逐条定、退回去以后已经做过的部分算不算数，是另一件更麻烦的事。

落到具体：六个文件，和一个当日序号

前两问听起来还是有点抽象，但它在我这里有一个特别实的对应物——交付目录。一个任务一个目录，里面固定六个文件：

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

这里的关键不是「留了存档」，而是：交付物不是只有终稿，每一个人工确认节点的输入与输出都单独落盘了。02-direction.md 存的是「我给了哪几个方向、最后选了哪个」，03-outline.md 存的是「确认之后的提纲」。也就是说，闸门处的那个决定被固化成了文件，而不是留在对话记录里。

这六个文件就是第二问的物证。文件的个数，等于形态变化的次数。所以这条判据可以反过来用：先把交付物列成一份文件清单，再从清单回推工序。 我觉得这比正着拆容易得多——你更容易说清楚「最后要留下哪几样东西」，而不是「中间要做哪几件事」。

还有一处具体的，是同一个 Agent 的几份文档步骤数并不一致。执行用的那份写成十三步，判断用的那份写成十二步，差别在于后者把「保存结构化成果」和「同步草稿箱」合成了一步。我没有强行对齐。岗位卡讲边界、工作流卡讲判断、执行用的 Profile 讲执行，颗粒度各自服务各自的用途。这件事本身也说明一个问题：工序边界不是唯一解，同一个位置可切可不切，取决于这份文档要回答什么问题。

顺带一个和边界有关、却常被忽略的后果：切出来的产物得能被找到。我中间改过一次任务目录的命名，早期是 2026-08-24-another、another2、another3、sth 这样，一天写多篇的时候翻起来很伤神；后来改成在日期后插入当日序号，2026-08-25-01-clay、2026-08-25-02-chataigne。日期粒度的命名在「一天一次」时够用，「一天多次」就立刻退化。产物命名的排序能力要按峰值频次设计，不是按平均频次。

这三条在什么情况下不成立

三类位置会重合，重合处才是硬边界。「确认提纲」这一处，三问全中：它是我常规必经的检查环节之一、产物从方向变成了提纲、提纲没通过删除测试时退回的是「生成提纲」，和正文不合格、核心依据塌了各自退回的地方都不一样。这种地方切定了。反过来，只满足第二问、既不需要人点头也不构成独立退回点的位置，合起来也没什么损失——我把工作流卡里「保存结构化成果」与「同步草稿箱」合成一步，读成的就是这一类。所以这三条不是三个必要条件，是三个提示；命中一条值得停下来看看，命中三条就别犹豫了。

只跑一次的活儿不适用。 拆工序的收益全部来自重复：重复才有「上次是哪一步歪的」，才有值得固化的闸门和产物。一次性的任务，把它拆成六个文件的成本大于收益，直接一把梭更划算。

链路还没接通的那一段，边界是暂定的。 我这条流水线的交付终点，目前停在「文章和封面已生成并保存」，公众号草稿箱的写入至今没接通。没接通的那一段，我手上没有真实的失败样本，第三问在那里根本用不了——它依赖「失败过、知道会退回哪儿」。所以那一段的工序边界我是照着前两问先切的，等真跑起来大概率还要挪。这是我目前的状态，不是一个已经验证过的切法。

第一类边界还有个前提：消息真的送到人手上。 我遇到过提纲没在飞书里显示出来、我得主动去问「提纲我在飞书上没有看到」的情况。人工闸门是靠消息送达支撑的，闸门处如果没有送达检查，流程会静默停住：Agent 以为自己在等人，人根本不知道该自己动。这种时候边界画得再准也没用——它卡在那儿，而你以为它在跑。

这篇的判据来自我自己带 Agent 干活的实践，样本有限。它更像一份可以拿去验证的假设，而不是一份可以照抄的规范。