给 Agent 设人工闸门：该卡在返工成本跳变的位置

2026-08-25

站内工具大模型 API 价格对比表 → 豆包 / GLM / Kimi / 千问 / DeepSeek 等 9 家厂商单价并排看，可按币种筛选、按价格排序，每行链到官方定价页。

我给那个写公众号文章的 Agent 画流程图的时候，顺手做了一件事：把所有需要人插手的节点用一个颜色单独标出来。纯粹是为了图好看，方便自己检查有没有漏掉分支。

画完往后一退，看了一眼，愣了一下——这些黄块不是散着的，它们扎堆。

我数了数，一共九个人工节点。但它们在流程上的地位完全不一样，而且这个不一样是我事先没想过的。这篇就是我事后把它们扒开、反推出来的东西。

先看这九个到底长什么样

按它们在流程上的位置排一下：

原文链接读不出来的时候，等我提供能读的替代素材
生成了几个写作方向之后，等我选
生成了提纲之后，等我确认
命中高风险题材的时候，等我判断能不能继续
外部能力或者授权出问题的时候，等我处理
正文和封面都好了之后，等我终审、决定发不发
我如果提了修改意见，走修改分支
发布本身出错的时候，等我处理

数完就发现了：这九个里，只有三个在正常路径上。 选方向、确认提纲、终审。其余六个全部挂在失败分支或者例外分支上——正常跑一趟，一个都不会碰到。

我一开始设这些闸门的时候完全是凭手感：这一步我不放心，加个确认。那一步我不放心，也加个确认。加完之后自己也说不清为什么是这三个，而不是四个或者两个。

那三个常规闸门，卡的都是同一类位置

把这三个位置摊开看：

选方向之前，Agent 手里是一堆素材和若干种可能的切法。选完之后，可能性从”若干种”塌缩成”一种”。 确认提纲之前，方向定了但结构还没定。确认完，整篇文章的骨架就固定了。终审之前，是一份完整的稿子，还可以推翻。之后就发出去了，推不翻了。

三个位置的共同点：它们都是信息量突然收敛的地方。 收敛之前，选择还是开放的；收敛之后，后面所有的工作都建立在这一次收敛的结果上。

于是就有了那条我事后才总结出来的判断：闸门该卡在返工成本跳变的位置。

方向如果选错，后面的提纲、资料、正文、封面全部作废，一路白干。提纲如果定错，正文作废。正文如果写砸，只有正文作废，前面的方向和提纲都还能用。你会发现越往前，一次错误的代价越大。 那三道闸门，正好卡在代价从”小”跳到”大”的三个台阶上。

而中间那些步骤——检索资料、优化标题、生成封面——它们错了就重跑一遍，不牵连别人。所以那里不需要闸门，加了反而是在拖慢一件本来可以自动跑完的事。

顺手一提：另外六个是完全不同的东西

我最初把这九个笼统地当成”需要人的地方”，后来发现这么归类会出问题。

那三个是常规闸门，每一趟都要过，是流程的一部分。另外六个是异常兜底，只在特定失败分支上触发，正常跑一百趟也碰不到一次。

这两类东西的设计要求完全不一样。常规闸门要考虑”人是不是方便确认、确认的信息够不够”；异常兜底要考虑”人会不会知道自己该出场了、出场之后手里有没有足够的上下文”。

我在岗位卡里就是把这两类分开写的，一栏叫触发条件，一栏叫必经检查。当时是下意识分的，现在回头看，这一分挺关键——混在一起写，最容易发生的事是常规闸门被当成异常处理，于是流程默认它不会触发，人也就不知道自己该做什么。

发布权为什么单独拆了一道

最后这个我想单独说，因为它是九个里唯一一个我明确改过设计的。

存草稿和公开发布，一开始在我脑子里是一件事。后来拆成了两级：

存草稿不用问我，审核通过就自动存。 存草稿这个动作是可逆的——存错了删掉就行，没人看见。让它自动跑，能省掉一次完全没必要的等待。

公开发布必须我点头。 这个动作不可逆。发出去了，就算三分钟后删掉，也已经被人看见了。

我把这条写进岗位卡的时候，还专门在”做错了”那一栏加了一句：没经过我确认就公开发布，即使文章质量再好，也算这次任务失败。流程违规本身就是失败，跟内容写砸了并列。

这一句是有用的。因为如果不写，Agent 面对”文章已经很完美了，就差发出去”这种情况，是有可能自作主张替你把最后一步做掉的——它会觉得这是帮你。你得明确告诉它，这不是帮忙。

闸门是一段状态，不是一个瞬间

还有个细节，是我画图的时候才意识到的。

“等我选方向”这一处，图上其实是两个节点而不是一个：一个负责判断”人确认了吗”，另一个是”等待人选择”，两者之间连成一个小循环，没确认就一直转回去。我当时觉得这是画得啰嗦，后来发现不是。

闸门不是一个瞬间发生的动作，它是一段可能持续很久的状态。 Agent 停在这儿的时候，得知道自己在等什么、等到了怎么继续、等不到该怎么办。把它画成一个点，就容易默认”人马上会回”——而人不一定马上会回，人可能在开会，可能压根没看见。

我这边就撞过一次没看见的：有一趟任务，Agent 把提纲生成好了，停在闸门前等我确认。我这边一直没收到那条消息，还以为它在写。等了半天觉得不对，才发过去一句”提纲我没看到，麻烦再发一次”。

这次之后我加了一条规矩：闸门处必须有送达检查。 因为这类卡死的形状特别别扭——Agent 以为自己在等人，人不知道自己该动，两边都觉得对方在忙，谁都没错，流程就那么静静地停住了。它不产生任何错误，也不会超时报警，你只能靠”怎么这么久了还没动静”这种模糊的感觉去发现。

所以设计闸门的时候，除了想清楚”卡在哪一步”，还得想一步：人怎么知道轮到自己了。

我现在怎么用这条

再设计新 Agent 的时候，我不再一个个凭手感加确认了。我按两步走：

第一步，把流程从头到尾列一遍，每一步问一句：这一步如果做错了，得从哪儿重来？ 答案是”重来这一步”的，跳过。答案是”前面全废”的，标记出来。第二步，标记出来的这些位置，就是候选闸门。再从里面挑代价最大的几个——不要全设，全设了就退化成了人工手动操作，Agent 等于白做。

还有一条自己给自己的提醒：闸门的数量应该随着我对这个 Agent 的信任而减少，但不可逆动作那一道永远不撤。 前者是效率问题，后者不是。

边界

这套反推是从一个人在用、一次做一篇的 Agent 身上得来的。它有个前提：人一直在旁边，随叫随到。

如果换成批量场景——一次跑几十个任务、人不可能挨个确认——闸门这个形态本身就不成立了，得换成别的机制：开工前把判断写进规格，收工后抽样验收，人退到流程的两端去。那是另一套做法，代价和收益都不一样，不能直接把这篇的结论搬过去。

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