Agent 的人工兜底和人工闸门不是一回事

2026-08-25

你在写一份 Agent 的岗位卡，写到「人工兜底」那一段，脑子里冒出来的东西很杂：链接打不开要找人、方向定不了要找人、涉及高风险内容要找人、最后发布之前要找人。于是你一口气列了十来条，标题就叫「需要人介入的情况」。

这一段写完当时看着挺全的。问题要过一阵子才显出来：流程跑起来以后，本该每次都经过的那几步，有时候就那么过去了，你事后才发现自己压根没被问过。

我那个写公众号文章的 Agent，岗位卡里这一段是分成两栏写的：一栏叫「介入条件」，一栏叫「检查环节」。这篇想说的不是哪一栏里该写什么，而是这两栏为什么不能合成一栏——分栏这件事本身，比栏里写了什么更要紧。

一段岗位卡里同时列着两种东西

先把那一段的骨架摆出来。它长这样：

人工兜底
├── 介入条件（7 条）   —— 异常触发，只在特定分支上出现
└── 检查环节（3 条）   —— 常规必经，每次运行都会走到

介入条件 那 7 条的要点是：链接不可访问或需要登录付费；主题和目标读者不明确；关键事实缺可靠来源或者来源之间互相矛盾；涉及投资医疗法律政治这类高风险题材；可能抄袭或者素材图片有侵权风险；文章质量没达到自然、无 AI 味的要求；消息通道或者发布接口的授权出了异常。

检查环节 只有 3 条：选择写作方向；确认提纲和主要观点；审核最终正文与封面并决定是否公开发布。

这两栏的字面形式很像——都是「这时候需要人」。但把它们摊到流程图上，差别就没法忽略了。我那份流程图里用统一样式标出来的人工节点一共 9 个，其中 3 个卡在正常路径上，剩下 6 个挂在各自的失败分支上，正常跑完一遍根本不会碰到它们。

也就是说，这一段里躺着的是两种性质不同的东西：一种是流程的组成部分，一种是流程的出口。它们被同一个小标题收在一起，只是因为都需要人。

三个问题，把手里这一条分到该去的那栏

如果你现在手上就有一条没想好放哪的兜底条目，可以按这三个问题往下走。这是我给自己定的分法，不敢说别人也得这么分。

问题一：不写这一条，流程会不会照常跑完？

会照常跑完，说明它不在必经路径上，属于异常那一栏。链接打不开这条就是典型——它只在读取失败的那一支上出现，流程完全可以在它不触发的情况下从头跑到尾。

不会跑完，或者跑完了但结果没法要，那它就在常规那一栏。「选择写作方向」就是这样：没人选方向，后面所有步骤都失去了前提，Agent 要么停在这里，要么自己替你选了一个。

问题二：把它叫起来的是什么？

是流程推进到了某一步，还是某个判断的结果为否、某个外部调用失败了？

「确认提纲和主要观点」是被流程推进叫起来的：提纲一生成，这一步就到了。「关键事实缺可靠来源或来源矛盾」是被判断结果叫起来的：核验做完，发现来源对不上，才有它。前者的触发信号在流程内部，后者的触发信号是一个失败态。

问题三：人被叫来之后，要给的是「决定」还是「补救」？

这一问对我最好使。常规那 3 条要人给的都是决定——选哪个方向、这份提纲行不行、这一稿能不能公开发布。人给完就走，流程继续按原路往下。

异常那 7 条要人给的多半是补救——链接读不了，请你提供一份能读的替代素材；题材是高风险的，请你决定放不放行；授权异常了，请你去把授权修好。人给完之后，流程要么回到某个更早的步骤重来，要么才能接着走。

这三问的答案一般是一致的。不一致的时候，我按问题三定，因为「要决定还是要补救」直接决定了这个节点后面要接什么。

混写之后最容易发生的那件事

两栏混成一栏，两个方向的错都会犯，但我最担心的是这个方向：常规闸门被当成异常处理。

原因不难理解。一段十来条的清单，读它的人（包括后面照着它写 Profile 和流程图的人，也包括 Agent 自己）会给整段找一个统一的语气。这段清单里绝大多数条目讲的都是「出了什么问题才找人」，那三条常规的就很容易被一并读成同一个语气：没出问题，那就不用问了。

落到实现上，它就变成一个条件分支。条件不成立，分支自然跳过，不报错、不提示，跑得非常顺。等你在终审时看到成品，才发现方向压根不是你想要的那个。

这里还有一个更安静的变体，跟送达有关。我这边出过一次：确认提纲的消息实际上没有显示出来，Agent 那边在等人，人这边根本不知道有东西在等自己，流程就静默停在那儿了。从这件事里我拿走的判断是——人工闸门是靠消息送达来成立的，闸门处必须有送达检查，否则它会以「正在等待」的姿态卡死。

这条对两栏都成立。但如果只来得及先做一处，我会先做常规那 3 处的送达检查，理由只是它们每一次运行都会经过，出问题的机会更多。这是我的顺序取舍，不是说异常那一栏不要紧。

反方向的错也有代价：把异常条目写进常规必经，等于让它占上正常路径。原本只在失败分支上出现的那 6 个节点，一旦每次都问一遍，人就从「兜底的那个」变成了必经环节里的按钮。我这条线上这两栏是分开列的，落到流程图上的结果是：正常路径上只留着该留的那三处。

有依据才比：两处我不比的地方

对照到这里，我只在两栏都有明确记录的维度上比过：触发方式、是否占正常路径、人要给的是决定还是补救、以及跳过之后会发生什么。还有两个维度，我这边没有依据，就不比。

一处：异常闸门有没有对应的落盘产物。 常规那侧我是有依据的。我那条流水线的交付目录是六段式的，里面 02-direction.md 存的是「给了哪几个方向、最后选了哪个」，03-outline.md 存的是确认后的提纲——常规闸门上的决定被固化成了文件，而不是留在对话记录里。异常闸门触发之后有没有同样形态的留痕，我手上的材料没写清楚，所以这个维度我不比，也不建议你照着我这半边去推另外半边。

另一处：漏掉异常闸门算不算失败。 常规这侧同样有明确依据：那份岗位卡的成功标准是写成「做对了 / 做错了」两组对照的，做错了那组里有一条是「未经过你的确认便直接公开发布文章」——流程违规本身被定义为失败，和内容质量并列。异常那一栏有没有对等的写法，卡上没有，我不替它补。

对照写到这一步就停。我不打算说哪一栏更重要，那不是这篇要回答的问题；哪一处闸门该卡在流程的哪一步，也是另一篇的事。

边界：什么时候这套分法可以不用

有一处细分值得单说，因为它容易被误读成「常规闸门越多越好」。我这条线上，最终审核和公开发布是分开的两件事：审核通过之后同步草稿不需要再问一次，公开发布才必须人工确认。同一段流程末尾，两个动作被拆成了两个权限等级。所以常规那栏不是「凡是重要动作都摆一个闸门」，是先把权限分级，再决定哪一级需要人。

至于什么时候不必费这个劲：如果一件事从头到尾只有一次人机交互，或者这个 Agent 就跑一次性任务、跑完就扔，那这两栏分开写没什么收益，写在一起也不会出事。分栏的价值来自「同一条流程要反复跑很多遍」——重复运行才会把「这一步是不是每次都得过」这个问题变成一个真问题。

还有一种情况我拿不准：多个 Agent 串起来、上一个的产物是下一个的输入时，中间那个人工节点到底算谁的常规、算谁的异常。我这边还没跑到那一步，没有可说的。

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