谁来管控后续流程：AI 队员、自动化与人组成的三角
谁来管控后续流程：AI 队员、自动化与人组成的三角
——「人 × Agent 协作」系列 · 第 4 篇
前三篇建立了一个让人振奋的图景：AI 接手了不该占用人的工作（第 2 篇），AI review 治理了 AI 的代码产出（第 3 篇）。但越往下走，一个让人不安的问题就越甩不掉：
当一个 AI 既能写代码、又能 review、还能自己创建工单、自己给人发消息、自己决定把工单转给谁——这套流程的主导权，到底在谁手里？
答案比"人管控 AI"复杂得多：它是一个三角结构——AI 队员、定时自动化、人，三者各司其职，相互制约。而这个三角能稳定运转的关键，是一条看似平淡、实则致命的铁律。
先看清问题的严重性
让我们把小布一天能做的事，重新列一遍，感受一下"失控"的风险有多大。
他能创建工单并指派给人——这意味着他可以凭一己之力，往团队的工作流里注入新任务。
他能在内部 IM 上给人发消息——这意味着他能绕开任何工单系统，直接 @ 任何一个同事，催进度、转任务、汇报风险。
他能自己判断一个工单属于哪个业务域，然后把工单转派给对应的产品经理或开发者——这意味着他在某种程度上，行使了项目经理的调度权。
他还能自动关闭工单——那 17 条被归因为"模型幻觉"的 case，就是他根据分诊 agent 的判定结果执行关闭的。
如果这些能力没有任何约束，会怎样？想象几种失控场景：
- 他机械地执行关闭，把一个其实还有工程修复项的 case 误归为"模型幻觉"关掉了，真正能修的问题被掩盖。
- 他把一个工单转给了错误的人，那个人莫名其妙接了一个不属于自己的活。
- 他处理不了某条工单，但没有告诉任何人，工单就这么消失在黑箱里。
- 他凌晨自顾自地创建了一堆工单，第二天团队上班发现工作流被搅乱了。
这些不是臆想。任何一个让 AI 拥有"写、转、关、催"能力的团队，都会撞上这些问题。 区别只在于：你是事后救火，还是事前用结构去防止。
我们选了后者。而这个结构，是一个三角。
管控三角：三个角色，三种职能
角色一：定时自动化——节奏与边界的定义者
第一个角色出乎意料：既不是 AI，也不是人，而是定时自动化（cron）。
它做的事看似简单：在固定的时间，触发固定的 AI 任务。每天 9 点跑工单巡检，每天 9 点半跑 staging 评审，每天凌晨 2 点跑 bad case 分析。但它的真正作用，远不止"定时"。
自动化的第一个作用，是定义边界。 小布能做什么、不能做什么，从来不写在他的"大脑"里，全部写在每个自动化的配置里。每个自动化都有一段长长的 prompt，明确规定：这次运行的输入是什么、要做哪几件事、什么时候该停。比如工单巡检的自动化里明确写：只处理"指派给智能体且超过 24 小时未更新"的工单——这是一个精确的边界。AI 不能越界去处理别的工单，因为自动化根本没给他那个任务。
自动化的第二个作用，是定义规则。 这是最关键的部分。AI 没有"自己看着办"的余地——每一条决策规则都被写死在 prompt 里。看工单巡检自动化里的这段原文，它把 AI 处理一条卡单的所有分支都列了出来：
- 如果 issue 需要排期规划，应根据业务域归属表判断对应业务域 PM，并把 issue 分配给该 PM；如果无法可靠判断业务域或 PM，则保留为人工关注项，并在提醒中说明原因。
- 如果 issue 处于审核中环节，应根据业务域分配给对应的人类开发者；如果无法可靠判断业务域或开发者，则保留为人工关注项，并在提醒中说明原因。
- 如果线上 bad case 归因为"规则说明不合理"，应直接将该 issue 状态设置为"已完成"……
- 如果问题阻塞在信息补充上，应确保 issue 状态为"已阻塞"……
请注意加粗的那两句。这就是整个管控体系的灵魂，也是这一篇要讲的核心铁律。我们待会儿展开。
自动化的第三个作用，是强制可观测。 每个自动化跑完，都必须产出一个结构化的总结。工单巡检的总结第一句话，必须是这样一个固定格式：
本轮共有 X 条超过 24 小时未更新的智能体工单，其中 Y 条已阻塞，已处理 Z 条，仍有 W 条需要人工关注。
X、Y、Z、W 四个数字。这意味着，人不需要去看 AI 具体干了什么——他只需要看这四个数字，就能判断这一轮是否正常。如果 W（需要人工关注的数量）突然变大，人就知道出事了。这是一种用数字代替监督的设计：AI 的行为被压缩成几个可监测的指标，人监管指标，而不是监管 AI 的每一个动作。
角色二：AI 队员——执行者，而非决策者
第二个角色，是 AI 队员本身（小布）。
请注意我用的是"队员"而不是"工具"。因为小布确实拥有主动性：他有自己的 IM 账号，能主动找人；他能创建工单，能改工单状态；他甚至能在分析完一个 bad case 后，自动给涉及的客户写一份不带任何技术细节的总览报告。
但"主动性"不等于"自主权"。小布的所有主动性，都被锁在自动化定义的边界里。他可以处理工单，但只能处理 prompt 里明确列出的那几类；他可以转派工单，但必须遵循"无法可靠判断就保留为人工关注项"的铁律；他可以发消息，但消息内容必须包含规定的字段和那句加粗总结。
这里有一个重要的设计原则：AI 队员的权限，是"白名单"而非"黑名单"。 我们不规定"你不能做什么"，只规定"你只能做什么"。任何没被明确允许的，默认就是不能做的。这和传统软件安全的"默认拒绝"原则完全一致——只不过这里应用到了 AI 行为上。
为什么必须是白名单？因为黑名单永远列不全。AI 的能力在快速演进，今天他不能做的事，明天模型升级后可能就能做了。如果你靠"禁止做 X、禁止做 Y"来管控，迟早会漏掉一个你没预想到的 Z。而白名单天然免疫这个问题——不在允许列表里的，一律不许做，不管 AI 变得多聪明。
角色三：人——最终的裁决者与异常处理者
第三个角色，是人。
人在这个三角里做的事，被刻意收窄了。人不再做机械核查（那是自动化的活），不再做全量 review（那是 AI review 的活）。人只做两件事：
第一，裁决。 当 AI review 给出一个 🟠 强烈建议，人说改还是不改；当 AI 把工单转给某个 PM，PM 决定接还是退回；当 AI 判定一个 case 是规则问题，人确认这个判断对不对。所有需要"业务取舍"或"价值判断"的节点，最终都落在人身上。
第二，异常处理。 当 AI 自己说"我处理不了，需要人工关注"时，接手的也是人。我们在上一节看到，工单巡检会在总结里明确报出"仍有 W 条需要人工关注"——这 W 条，就是人要逐条处理的。AI 把它们整理好、说明原因、交回给人，人来做最后的判断。
这两件事有一个共同特征：它们都是低频、高价值的。 这正是第 2 篇讲的——把人的注意力，从高频低价值的洪流里解放出来，集中到低频高价值的判断上。
那条铁律：AI 处理不了，必须显式转人工
现在，可以展开这一篇的核心了。
整个三角能稳定运转，不在于 AI 多聪明，不在于自动化多严密，而在于一条看似平淡的铁律：
AI 凡是自己处理不了、判断不准、或者超出边界的事，必须显式地转交给人工，并在转交时说明原因。绝不允许静默吞掉。
这条铁律为什么致命？让我们看一个反例——如果 AI 静默吞掉会怎样。
假设 AI 在巡检时遇到一条工单，它判断不出这条工单属于哪个业务域。如果它选择"静默跳过"，那么这条工单就消失了——它既没被处理，也没被上报，就那么躺在系统里，没有人知道它的存在。等到三个月后这条工单对应的问题爆发，团队才会惊觉：原来早就有一条工单指出了这个问题，但被 AI 漏掉了。
这种"静默失败"是自动化系统最可怕的故障模式，因为它不可见。系统看起来在正常运转，每天产出报告，但实际上有些东西被悄悄丢了。等发现问题的时候，往往已经晚了。
我们的铁律就是为了杜绝这种情况。它要求 AI 在任何"处理不了"的节点，都必须做三件事：
- 不处理——绝不强行做出自己没把握的决策。
- 显式上报——把这条工单明确标记为"需要人工关注"，写进总结的 W 这个数字里。
- 说明原因——在提醒消息里，写清楚"为什么处理不了"。
来看一段真实的执行记录，这是某天工单巡检的真实输出：
处理了 2 条卡在智能体身上的工单：1 条已转 PM，1 条仍 blocked 并说明原因：
- HAR-1869：仍 blocked，因缺少单据号 / trace id / 精确操作时间，无法定位问题。
这条工单没有被静默吞掉，也没有被 AI 勉强处理。它被显式地标记为 blocked，并写明了阻塞原因——"缺少单据号、trace id、精确操作时间"。第二天，工单负责人看到这条提醒，第一件事就是去补齐这些信息。整条链路是透明的、可追溯的、不会丢失的。
更精彩的是 bad case 分析自动化里的另一段设计。那个自动化会派出一批子任务给 trace 分析 agent，然后等待它们全部完成。但如果等待超过 24 小时还没完成，它的规则是：
则停止继续等待，更新父 issue 说明阻塞原因，并返回 inbox 状态。
注意"返回 inbox 状态"——这意味着这个任务重新回到了人的工作流里，而不是无限挂起或静默放弃。AI 明确地、主动地、带着原因地，把一个自己搞不定的任务，退还给了人。
这就是铁律的完整含义：AI 不是要无所不能，而是要对自己"不能"的部分，做到完全透明。
为什么这条铁律是整个体系的最后一道闸
让我把视野拉高，解释为什么这条铁律如此重要。
前面三篇建立的体系，本质上是一个层层外包的结构：人把机械工作外包给 AI 队员，AI 队员把 review 外包给 AI review，AI review 把判断材料交还给人。每一层都在把上一层的负担减轻。
但外包有一个前提：被外包的部分，必须能被回收。 如果某一层出了问题，它必须能把这个问题显式地传递回上一层，而不是把问题藏起来假装一切正常。
这条铁律，就是这个"回收机制"。它保证了：无论 AI 在哪一层、因为什么原因、在什么场景下搞不定，这个"搞不定"本身，都会被放大、显化、传递到人能看见的地方。它不会变成一个潜伏的 bug，不会变成一次静默的数据丢失，不会变成三个月后的一场事故。
换句话说，这套协作体系之所以可信，恰恰因为我们不信任 AI——我们假设它一定会遇到搞不定的事，并为此准备好了显式上报的通道。
这是一种防御性的信任：让 AI 干活的前提，不是它值得信任，而是我们已经为它"不可信"的部分建好了兜底。两者的区别，是"盲目放权"和"有护栏的授权"。
三角之外：还有一道隐藏的保险
讲完三角和铁律，还有一个细节值得提，因为它经常被忽视。
小布有一个"记忆文件"（memory.md），每个自动化每次跑完，都会往里面写一段"本轮做了什么、有什么注意事项"。比如工单巡检的记忆里写着：
Notes for next run:
- Multica CLI and local daemon were healthy this run.
- Closed status values are
doneandcancelled.- Multica member matching:
张平matches aszhangping；梁长通matches as长通……
这段记忆有两个作用。第一，它让下一轮的 AI 能继承上一轮的上下文——比如它记住了"某个成员的名字要这样匹配"，下次就不会再匹配错。第二，更重要的是，它是一份给人看的运行日志。任何人想知道"这个自动化最近到底干了什么、有没有出过什么状况"，翻开 memory.md 就一目了然。
这是一种透明的积累：AI 的每一次运行都不再是一次性的黑箱，而是留下可审计的痕迹。这和铁律一脉相承——"搞不定"要透明，"搞定了什么"也要透明。
收束：管控的本质是分工，而非约束
让我用一句话收束这一篇：
管控 AI，目的从来不是限制它，而是为它划清楚它不需要扛的部分——然后，把那部分，干干净净地交还给人。
三角结构的本质，是一次清晰的分工：
- 自动化负责"什么时候、做什么、停在哪里"——它是节奏和边界的定义者。
- AI 队员负责"在边界内，把能做的做完"——他是执行者，权限是白名单。
- 人负责"裁决和异常处理"——只做低频高价值的判断。
而那条铁律——"处理不了必须显式转人工"——是连接三角的脐带。它保证了无论 AI 走到哪一步，人永远能接得住、看得见、管得了。
讲到这里，前四篇的逻辑闭环已经完成：AI 接手机械工作（第 2 篇）→ AI 治理 AI 产出（第 3 篇）→ 三角结构管控整个流程（第 4 篇）。但还有一个物理层面的问题没有解决：
当 AI 把代码写完、把 review 做完、把工单处理好之后，人要真正验收这些工作时，他面对的是什么？是一段文字说明，还是一个可以直接进去看、可以点、可以测的真实环境？
如果人接手时还要自己拉代码、配环境、造数据、找入口——那前面四篇建立的效率，会在"最后一公里"全部漏光。
这是本系列第 5 篇的主题：把工作现场从个人电脑，搬到共享环境。我们会讲清楚，为什么"共享环境"是这套协作模式能够落地的物理基础，以及它如何让人真正"接得住"AI 的产出。
下篇见。
一句话结论
管控的本质是用"自动化定边界 + AI 白名单执行 + 人裁决异常"的三角分工，加上"处理不了必须显式转人工"的铁律，保证决策权始终在人手里。约束只是表象，分工才是内核。