早上打开电脑，老张发现阿行半夜干了一堆事
那天早上，老张到工位，泡了茶，打开电脑。
内部 IM 里躺着一条消息，是阿行发的，发送时间凌晨 3 点 12 分。老张点开——阿行说，它刚跑完一轮工单巡检，处理了几条卡住的工单：其中一条它判断属于某个业务域，已经自动转给了对应的产品经理；另一条它判断不了，标注了"需要人工关注"，原因是"缺少必要的复现信息，无法定位"。
老张看完，松了口气。处理得挺合理。阿行凌晨干活，他早上看结果——节奏没问题。
但松完这口气，他反而愣住了。
盯着那条消息，他脑子里冒出一个之前没想过的念头：
阿行刚才做了好几件事。它自己判断了工单属于哪个业务域。它自己决定把工单转给了一个具体的人。它还自己处理掉了一条工单。
这些事——是谁允许它做的？
老张不是在质疑阿行做得不对。他是在质疑一件更根本的事：他从来没有明确地"允许"过阿行做这些。 阿行就自己干起来了。干得还挺对。但这让老张更不安——对，是因为它做对了所以你没察觉；那它要是哪天做错了呢？
老张开始后怕
老张把阿行能做的事列了一张清单。
他能创建工单并指派给人。这意味着他可以往团队的工作流里注入新任务。
他能在内部 IM 上给人发消息。他能绕开任何系统，直接 @ 任何一个同事。
他能自己判断一个工单属于哪个业务域，然后转派给对应的产品经理或开发者。这已经是在替项目经理派活了。
他还能自己关闭/归档工单。那 17 条无抓手记录，就是他自己归档的。
老张看着这张清单，他开始担心。不是因为阿行会干坏事——它目前干得都不错。让他发凉的是一种可能性：如果这些能力没有任何约束，迟早会出事。
他脑子里冒出几种场景：
- 阿行误判一条有修复抓手的记录是"无抓手"，把它归档了，真正的问题被掩盖。三个月后那个问题爆发，团队才发现——原来早就被 AI 关掉了。
- 阿行把一个工单转给了错误的人，那个人莫名其妙接了一个不属于自己的活，又不好意思退回去，硬着头皮做了一通。
- 最可怕的：阿行遇到一条它处理不了的工单，但它没有告诉任何人，工单就这么消失了。没人知道它存在过，也没人知道它被丢了。
老张意识到，他之前犯了一个错：他把阿行当一个"好用的工具"在用，但阿行不是一个工具——它是一个会自主行动的队员。 工具你不用它就停，队员你不约束它，它会自己干。
老张的三个角色
老张花了一周，想清楚了一个结构。他后来管这个叫"三角"——阿行、自动化规则、人，三者各管一摊。
第一个角色：自动化规则 + 权限边界。 老张一开始以为，管阿行要靠"告诉它什么能做什么不能做"。但他很快发现，光靠 prompt 说不靠谱——模型可能误解、忽略或被上下文影响。他换了个思路，从两个层面同时约束：任务层面，阿行每天的每个任务都由固定的自动化规则触发，规则写死了输入、动作和停止条件，没有触发就没有任务；权限层面，系统限制了阿行能调用的工具和能访问的数据范围——比如关闭工单这个动作，需要独立授权或人工确认，不是阿行在任务里自己就能做的。两层合起来，才是真正的白名单：不在允许范围内的，任务不会触发，工具也调不了。
老张把这叫"白名单"：不在允许列表里的事，一律不许做。 这比"黑名单"安全得多——黑名单永远列不全，今天它不能做的事，明天模型升级后可能就能做了，迟早漏一个。
第二个角色：阿行自己。 老张依然给阿行留了行动空间——他不是要把阿行变成只会执行命令的木偶。阿行可以在任务边界内，自己做判断：比如处理一条卡住的工单时，它可以根据业务域归属表，判断这条该转给谁。但这种自主权，被锁在白名单划定的范围里。
第三个角色：人。 在单次 Agent 任务执行链里，老张让人主要承担两件事。第一件，裁决：阿行给出一个建议，人说接不接受；阿行把工单转给某个人，那个人决定接还是退。第二件，异常处理：当阿行自己说"这个我做不了"，接手的是人。
一条差点被忘掉的规矩
老张把这个"三角"搭起来之后，觉得挺踏实。但他后来发现，三角能稳定运转，靠的不是这三个角色本身，而是一条容易被忘掉的规矩。
这条规矩是老张被一次"差点出事"逼出来的。
有一天，老张翻阿行的巡检报告，注意到一条工单。这条工单卡在阿行身上好几天了，状态是"进行中"，但什么进展都没有。老张翻了一下历史——阿行几天前处理过一次，但似乎没处理完，也没上报，就这么挂着。
老张把阿行叫来"问"了一下（其实是查了运行日志）。原来阿行判断这条工单属于某个业务域，但它在归属表里找不到对应的负责人，于是它"卡住了"——既没处理，也没上报，就那么悬着。
老张他马上补了一条规则。
这条工单，如果不是他偶然翻到，可能会一直挂下去。没人知道它存在，没人知道阿行处理不了。问题就这么消失了——不是被解决了，是被静默吞掉了。
老张当天就立了一条规矩，后来他把这条规矩当成整个体系的关键规则：
阿行凡是遇到自己处理不了、判断不准、或者超出边界的事，必须明确地转交给人工，并在转交时说明原因。绝不允许静默吞掉。
这条规则为什么关键？老张后来在和 AI 交流时了解到，这不是他一个人的直觉——分布式系统和 AI Agent 领域都有一个共识：静默失败（silent failure）是最危险的故障模式。系统完成了任务、返回了结果、一切看起来正常——但结果可能是错的，而且没有任何告警。这种"看起来成功了但其实错了"的失败，比直接崩溃难发现得多。
系统看起来在正常运转，每天出报告，但实际上有些东西被悄悄丢了。等发现问题的时候，往往已经晚了。
当然，老张也清楚一条限制：阿行不一定总能意识到自己"处理不了"。 有些静默失败恰恰是 Agent 自认为已经成功，根本不会触发上报。所以"主动上报"只是第一道防线——老张还加了一道兜底：每次任务跑完后，系统会做一次超时扫描和结果断言校验，如果发现某个工单的状态异常（比如标了"进行中"但超过时限没动），即使阿行没上报，系统也会把它捞出来标记为"需要人工关注"。
老张要求阿行在"处理不了"的时候，做三件事：
- 不强行处理——绝不做自己没把握的决策。
- 显式标记——把这条工单明确标成"需要人工关注"。
- 写清原因——为什么处理不了，缺什么信息。
那条凌晨三点的消息，为什么让老张安心了
故事回到那天早上，老张看阿行凌晨发来的消息。
老张后来回忆，他真正安心的时刻，不是看完消息发现"处理得挺合理"，而是他重新看了一眼消息的最后一行——
"其中一条判断不了，标注为'需要人工关注'，原因：缺少必要的复现信息，无法定位。"
这一行字让老张踏实了。
阿行没有把那条它搞不定的工单静默吞掉。它明确说了"我做不了"，说明了原因，交回给了老张。整条链路是透明的、可追溯的、不会丢失的。
老张后来跟团队讲：我们信任阿行，不是因为它不会遇到搞不定的事——它一定会遇到。我们信任它，是因为它搞不定的时候，会把"搞不定"这件事本身，干干净净地告诉我们。
这是一种"防御性的信任"：老张敢让阿行干活，不是因为他相信阿行无所不能，而是因为他已经为阿行"搞不定"的部分建好了通道。阿行不是要无所不能，它要对自己"不能"的部分做到完全透明。
三角之外：还有一道隐藏的保险
老张后来还加了一道保险，这道保险不太起眼，但他觉得很重要。
阿行每次跑完任务，都会往一个"记忆文件"里写一段话：这次做了什么、有什么注意事项、下次要注意啥。比如它会写："今天发现某类工单的归属判断需要更新""某个接口的响应格式变了"。
这个记忆文件的作用是让阿行的下一次运行能继承上一次的上下文。老张很清楚，它是一份工作摘要，不是审计日志——阿行自己写的，可能遗漏或重述不准。真正可追溯的记录，来自系统层自动生成的运行日志：每次任务的时间、输入、调用了哪些工具、执行了什么动作、结果如何，全部由系统记录，阿行改不了。想知道"阿行到底干了什么"，查系统日志；想知道"阿行自己觉得发生了什么"，看记忆文件。两者分开，各管各的。
老张说，这和那条铁律是一脉相承的：不仅"搞不定"要透明，"搞定了什么"也要透明。 阿行的每一次运行，都不是一次性的黑箱——系统日志是硬证据，记忆文件是软参考。
老张收了个尾
老张把"三角 + 铁律"搭好之后，过了大概一个月，他发现自己早上看阿行报告时不再紧张了。
不是因为没有消息了——阿行会把"需要人工关注"的项汇总到次日早上的报告里。老张知道，这些消息该来的会来，该说的会说。他不需要时刻盯着阿行——阿行会在边界内工作，搞不定会显式告诉他，每一层都有约束。
但老张心里还压着另一个问题，一个他一直在回避、但知道迟早要面对的问题。
阿行现在能把代码写完、把 review 做完、把工单处理好。但老张要真正验收阿行的活儿时——比如，验收一个阿行辅助修复的功能到底跑没跑通——他面对的是什么？
是一段文字说明，还是一个他可以直接进去点一点、试一试的真实环境？
如果老张验收时，还要自己拉代码、装依赖、配数据库、造测试数据……那前面建立的所有效率，都会在"最后这一公里"漏光。
老张想起上一次验收的场景：他花了两小时，才把环境跑起来。那两小时里，他做的事没有一件是"判断"。
怎么让人不用搭环境，就能验收 AI 的活儿？
这是第 5 篇的故事。
一句话结论
管控 AI 不靠"告诉它别做什么"，靠"只给它能做的任务"（白名单）+ "搞不定必须显式上报"（铁律）；AI 不需要无所不能，它只需要对自己做不到的部分完全透明。