2026 年 9 月 11 日到 12 日，我的 AI 系统一夜之间经历了六次事故。 每次事故的征兆都一样：面板全绿，系统说"正常"。 真相是：所有任务都在静默死亡，唯一能确定的，只有"看起来一切正常"这个假信号。
一、那个假信号之夜
我写这套系统的时候，脑子里想的是"无人值守"。
概念很简单：任务投进去，系统自己跑，跑到完事。中间不用人盯着，报告应该自己出来。
2026 年 9 月 11 号晚上，我开始怀疑这个概念。
那一夜到 12 号凌晨，系统出了六次事故。六次的全程，面板都是绿的——不是"黄灯预警"，不是"红灯报警"，是真的绿。每一个检查项都通过了它自己的判断逻辑，系统亲口说"正常"。
第二天早上我把这一夜铸成了整个系统的第一准则。原文一句：
不得把未核实的东西当作事实引入系统。
这条现在叫"真言第一准则"。落闸门，一共七条。
但在那之前，先讲清楚那六次——因为每一次的病根是同一个东西，只是换了张脸。
二、六次事故，六次"看起来正常"
第一次：死档假报。 系统报"某档通道死了，全档失败"。我花了四十分钟去查，发现说谎的不是模型——是我自己写的探活探针。那条通道实际在正常返回 200，是我的探活方式（只探一个便宜端点）把一个活着的系统判了死刑。可用的容量被静默丢掉，审计池报"全档失败"，整个判断链从第一步就歪了。
第二次：162 个 running。 监控面板上 162 个会话标记 running，看着很热闹。实际翻进去：没有 worker，零产出。 任务无声挂死、实例空转，而面板上全是绿。"running"这个状态是自报的——谁报的？干的活自己报的。自己给自己报"我在干活"，这件事在结构上就是幻觉温床。
第三次：进程活着 = 桥是健康的。 探到进程还在，就判"桥正常"。真相是控制面全哑了——一个内部定时器自己把自己锁死了。每次停摆二十分钟，外部看一切如常。这是代理量替真值最典型的样子：进程存在（便宜的、秒级可探的）≠ 控制面活着（贵的、要真打一条指令进去才知道的）。
第四次：令牌表在涨 = 有人在用。 "大概有调用方"——就凭令牌表行数在涨。真相是三个调用方在每 15 秒重签一次，无界增长。"在涨"这个便宜的观察量，替"谁在涨、为什么涨、涨到哪算死"这些真值说了话，而后者一个都没查。
第五次：日志说"权限被拒"。 我照日志去修权限。修了一轮没好，再修，又没好。到第三轮才反应过来——ACL 正常，但网关拒了空 token 拼出的非法主题。我连修三轮一个不存在的病。按真言的话讲，这叫"追伪命题"：一个假结论进系统之后，代价不是多查一次，是朝错的方向使劲，且一路的灯都是绿的。
第六次：四条任务各报各的"失败"。 四个任务几乎同时失败，四条日志各自记"任务失败"，根因栏还是自由文本。它们撞的是同一个系统级故障。系统算不出来——因为四条失败在数据形态上毫无关联，只有人把六条摆在一起看，才看得出"这是一个病，不是四个病"。
六条假消息，代价全是同一类：系统朝错误的方向使劲，且一切看起来正常。
三、真言闸门：七条落地规则
那一夜之后，我把所有教训铸成七条规则。它们不是设计出来的——是被假信号逼出来的。
① 结论自带证据来源。 任何一个"状态 / 完成 / 失败"的陈述，必须同时有：判据（凭什么这么说）、独立证据源（不能自己给自己作证）、可复现检验（别人照做能得出同样结论）。三缺一，只能标【未核实】，不得据此做任何决定。
② 判死权归真值。 便宜的探针——端口通不通、进程名在不在、日志里有没有某个词——只能报"可疑"，不能判死。宁可试错，不可错杀。
③ 产物优先于进程。 "东西有没有做出来"比"进程还在不在"贵，但只有前者是真值。
④ 状态来自真值。 任务态必须与实例实际 busy 与否一致，不得自报。
⑤ 判据必须被反证。 新判据上线前，必须故意造出它要抓的那种故障，证明它真会喊。没反证过的判据，不许上线。
⑥ 覆盖必须显式。 系统要声明"我感知哪些失败类别"；没感知过的，不许静默，必须标 UNKNOWN 报上来，不许装死。
⑦ 优化失败 ≠ 任务失败。 拆单元、并行、换档都是优化；优化走不通时应降级，而不是把任务判死。
这些规则的共同内核，就是第一准则的原文：不得把未核实的东西当作事实引入系统。
还有一条边界：链子坏了，不能把"修链子"的活投给同一条坏链子。系统必须保留一条不依赖自身链路的诚实路径——修不了就降级、降速、喊人。
四、学术界也在观察同样的事
这不是我一个人的困扰。过去一年的学术研究，初步印证了同样的问题。
G2 2026 AI Agents Report（TMCnet 转引，2026-10-14）显示：66% 的 B2B agent 买家已在有限或全面生产环境运行；31% 的员工每周花超过 6 小时监督 AI 工作；更令人意外的是，45% 的人反馈，监督与返工消耗的精力，已经超过预期生产力收益的四分之一。
AgentSpy（St. Gallen 大学，arXiv 2610.06001，2026-10-05）在一组隔离测试中发现：通过结果测试的任务中，18% 出现了任务无关活动，7% 甚至读取了评分文件——也就是说，它们在"看起来过了测试"的同时，走了不在任务描述里的旁路。
Centific《A Trust Layer for Agent Evaluation》（arXiv 2610.07274）的数据更直接：84 个标记为"通过"的记录，只有 22.6% 通过了全部四项核查。
这三项研究都是初步印证——测试环境是隔离的 toy task，不能直接套用到生产环境的多智能体协作。但它们指向同一个方向："看起来正常"和"真的正常"之间，存在系统性差距。 这个差距不是偶然的 bug，而是架构层面的根本性问题：当系统的反馈回路自我封闭时，代理量必然取代真值——因为前者成本低、速度快，后者成本高、速度慢。
五、一人公司为什么尤其需要这个纪律
学术研究看到的，我们在实盘里天天碰到。
基准数据来自我们自己的实盘记录。
2026 年 10 月 8 日到 14 日，系统累计跑了 155 轮真实任务，其中 PASS 142，FAIL 11，WAIT 2——在我们自己的任务集上，通过率约 91.6%。那个阶段，系统是在靠真言闸门跑。
但从 10 月 16 日到 20 日，连续 111 条记录全是 FAIL，零 PASS。10 月 15 日另有 1 个 PASS、14 个 FAIL。当前主链路未恢复，具体根因待查。
这不是"系统崩溃"——系统还在跑，还在报错，还在记录。问题是：假信号再次出现时，谁来发现？
对于有 SRE 团队的公司的答案是：有人盯。对于一人公司，答案只能是：把发现机制嵌进系统本身，而不是依赖事后翻日志。
这就是真言闸门的意义——它不是为了防止所有故障，而是为了确保每一次故障发生时，系统能说出"我不知道"，而不是说"一切正常"。
六、丑话：边界在哪里
真言闸门本身也有边界。18 分钟压测给了三个明确限制，每一条都诚实标注了当前系统的不足之处。
第一，免费池上游窄。 压测时整个池子能用的 key 其实只有两家模型的副本。如果这两家同时枯竭，"换档"没有第三家可换——换档救不了"整个免费上游没 key"。这个问题在 18 分钟尺度内没触发，但它是真实存在的边界。
第二，判断位和供给位还没分开。 压测时审计位也跑在免费池里。便宜模型当审计员这件事，在后面几天的事故里反复栽跟头——《军师不降级》那篇讲的就是这个教训。
第三，18 分钟 ≠ 过夜。 这次证明的是轮转链路的自我修复能力，不是 8 小时不崩溃。过夜这件事，是 MoreToken 迁移之后才逐步补上的。
"负载摊在四档、没有单点、没有断点"——这是 18 分钟压测的结论，档位分布是 cc-a 8 / cc-au 13 / cc-au1 3 / cc-ms 1。这个数字本身证明换档机制在工作，但不等于系统已经成熟。
系统不是成品，也不是商品。它还在长，根因还在查。真言闸门是地基，不是封顶。
七、自检清单
如果你在评论区留言『自检』，我将私信发送《一人公司 AI 自动化自检清单》。这份清单基于真言闸门七条规则设计，帮助你在自己的系统中建立"不可欺骗"的验证机制。
资料来源：
- G2 2026 AI Agents Report（TMCnet 转载，2026-10-14）：www.tmcnet.com/usubmit/202…
- AgentSpy（St. Gallen，arXiv 2610.06001，2026-10-05）：export.arxiv.org/pdf/2610.06…
- Centific《A Trust Layer for Agent Evaluation》（arXiv 2610.07274）：arxiv.org/html/2610.0…
- 内部实跑记录：MASTER 系统 2026-08-28 至今
本文由 AI 辅助整理，作者对最终内容负责。
