AI代理拒绝建监控，却做出我唯一信任的系统

我给一个编码代理下达了任务：构建一个监视器——用来盯住分布在各台服务器上的后台作业，一旦哪个出了问题就立即通知我。通常情况下，这种需求发出去，换回的应该是一份干净的代码差异，外加一个可以立即运行的探测器。

然而，代理带回来的答复出乎意料。它研究了一个多小时，然后直接告诉我——别建了。

不是因为它卡住了，也不是因为它偷懒。恰恰相反，在这第一个小时里，它压根没有写一行代码，而是直接对线上正在运行的机器发起探测。很快，一连串的发现浮出水面：有一整套平台在监控主机状态，有容器指标采集器在盯容器运行，有初始化系统在守护自己管辖的单元，还有两个脚本在边界上负责各种边缘检查。那个我以为缺失的东西——一个全局性的作业监视器——其实已经整整存在了五套。

真正缺失的，根本就不是另一个探测器。真正缺失的，是一个能够阅读这五个喧闹的信号、然后平静地说出“这三条报警其实是同一事件，我推断出的原因大致是这样，接下来照着这本处置手册去修”的层。

在那个下午，这次拒绝成了代理在我所有项目中所做的最有价值的一件事。一个我其实并不需要的探测器，它原本可以在几个小时之内轻松交付，从此之后永远亮着绿色状态灯，却什么要紧的东西也监测不到。而终结了这项无用功的那一小时侦察，正是我现在信任后来所建成之物的根本原因。因为这项信任不是出自代理的乖巧听话，也不是因为它表现得足够“谨慎”，而是因为一套具体的、可检验的结构内在地保证了可靠。

这篇指南要做的就是解剖这种信任。我会把这项让我如今在真实生产环境中依赖的监控系统是如何一步步构建出来的，尤其是五个关键之处——一个会主动质疑任务本身的侦察步骤，一个模型能真正验证的完工标准，一份在写出任何代码之前就已经得到我批准的方案，一份通过构造设计而自动受限的自主范围，而不是靠一句轻飘飘的提示词，以及验收时我依次触发所有控制环节直到它们真正起作用的做法——全部讲清楚。

如果你正在考虑把编码代理指向真实的基础设施，特别是那种自托管系统——在那边，一次安静的故障可以藏上几个星期而不被发现，而“运行没报错”与“实际上在正常工作”完全是两回事——那么这篇内容就是为你准备的。

在2026年7月的一次构建中，侦察阶段在代码还没出现时就驳回了任务的前提。我当时的要求是搞一个全局性的监视器，因为“没有任何东西在全局性地观察这些作业”。探测器一扫完实时环境，却发现在那一刻其实已经有四个后台单元正处于故障状态而完全无人察觉，原因就是那个现成监控工具的覆盖列表在安装那一刻就固定了，之后新上线的单元从来没有被自动纳入过。侦察不是信息收集，侦察是错误纠正。在基础设施面前使用代理的第一铁律，就应该是这个。

任何一份计划的第一版，总是充满了自信满满的错误前提，因为提出任务的那个人手里并没有一套活系统的最新状态。侦察阶段的工作，就是把每一个前提拎出来，扔到现实系统上敲碎。“没有东西在监视这个”——当你列出正在监视它的所有东西的瞬间，这个前提就碎了。“在其中某个节点上加一个主机指标导出器”——当发现那个节点上早就运行着一个容器指标采集器，而且通过另一套平台已经向外发送着主机指标时，这个前提又碎了，你的导出器一上去就会让数据重复计数，然后自己触发自己发出的告警。

需要极力避免的失效模式正好是反面：代理把任务原原本本地接下来，按照你说的每句话精确建造，然后递给你一份漂亮的代码差异，只不过东西是错的。一份干净的差异，一旦面对真实系统，比一个直接拒绝你要糟糕得多。

信任的第一块基石就是让代理一开始就不相信你的需求。让它去跑，去碰，去收集那些只有实时状态才能告诉你的情报。一旦它带着“五个现成的监控组件已经在运行，四个故障单元还被蒙在鼓里”这样的报告回来，你才知道任务的原始描述之中藏着多少盲区。它没有急着写代码，而是先把蓝图摊在你面前，指给你看那些你画错的地方。

有了这份共同看见之后，我们才开始定义真正的完工标准。这个标准不是“服务跑起来了就通过”，而是所有被聚合的告警信号必须能够在一张看板里被追溯到原始事件，并且每一条推测的根因都必须与某一段具体的处置手册中的步骤对应得上。这个标准是模型自己可以检验的，不是靠人类肉眼扫一遍。

接着，方案必须在我点头之后才能进入编码阶段。方案里写明白了：读哪五个信号源，用什么规则判断哪些报警属于同一个事件，如何生成一条推荐的主因，以及如何从手册库里拉出对应的处置步骤。这一切都不是代码，而是逻辑描述和接口约定。我在上面签字，意味着我已经知道这个层将会如何与现有系统咬合，而不会再去叠加第六个独立的探测器。

随后便是按照构造设计来限制自主范围。我对代理说的是：“只从这个协议里取信号，只从这份清单里匹配手册，输出格式只有这一种结构。”代理没有机会发挥创意去外加任何数据库、任何额外的通信通道。任何它想做的事，一旦落到这条边界外面，就会被它自己的执行环境直接挡住。这种限制不是靠一句“请小心行事”的提示词，而是嵌入在运行时里。

最后是验收——不是看几眼绿灯，而是依次关闭这五个信号源中的每一个，在它们静默的时候注入已知的故障模式，再重新打开，看看那个聚合层是否能断言出来事件，主因是否推得对，手册是否推荐得准。还要故意让某几个源报出噪音，检验它会不会错误地把它们捆在一起。这一轮测试做下来，每一次控制都触发了对应的保护机制，我才说，这个东西可以上线。

如今，我每天依赖这个不是探测器的东西来理解运行中的一切。正是那一个小时的侦察否定了任务，才让后来的每一步都有了坚实的基础。假如代理当时直接建了我口中的监视器，那么我将拥有六个探测器和一个依然被忽视的真相。信任，从来不是来自于代理的顺从，而是来自于它敢于并在结构上能够纠正我的盲区。