“大概能跑”在生产基础设施里是行不通的 #
BASTION 是一个由 AI 分析基础设施日志、自动阻断攻击、并控制带宽质量的”AI Ops Platform”。这样写听起来很炫，但我们在开发中最费心的并不是增加功能，而是“只把能够证明可用的东西放进生产”这条朴素的纪律。
给生产基础设施加入自动控制，意味着 AI 的判断失误会直接变成事故。把并非攻击的通信误判为攻击而阻断，正常客户就会被挡在门外；在并不拥塞时收紧带宽，服务就会劣化。所以我们不会把仅停留在”理论上应该正确””大概能跑”阶段的东西放进生产。
本文写的是，在把新的检测逻辑或控制放进生产之前，我们实际会做的事。
工程师会被”优美的设计”吸引 ―― 而这正是陷阱 #
老实说，我们自己也曾有一个”理论上优雅的模型”。在纸面上逻辑自洽，讲起来也很舒服。这样的设计很有魅力。
但生产流量并不会按照纸面上的假设运行。我们用自家基础设施的真实数据去检验那个模型，找出了与预期不符的部分。我们随之采取的行动很简单 ―― 把模型本身改造，将其主张收回到数据所支持的范围。不是”因为图好看就采用”，而是只采用数据所支持的范围。
这并不是失败。恰恰相反，能够用自己的数据反驳自己优美的假设，我们认为正是一个托管生产基础设施的产品所不可或缺的。
检验的章法 ―― 在不影响生产的前提下试验假设 #
具体来说，我们按这样的顺序检验。
1. 只用观测来试验假设（READ-ONLY） #
新的检测逻辑，首先以对生产不写入任何内容的”仅观测”模式运行。完全不触碰生产的阻断或控制，只是用真实数据记录”如果这是生产，会怎样判定”。这样一来，即使假设落空，也不会让任何人为难。
2. 确认它能否把真正的异常与单纯的噪声区分开 #
检测逻辑的价值，与其说取决于”能找出异常”，不如说取决于“不把非异常说成异常”。在满是背景噪声的日志中，能否只挑出真正的异常？我们关注的不是单一指标是否越过阈值，而是多个观测面是否步调一致地开始崩塌（协调性的起始，co-onset），并将其作为各对象相对于自身平常的相对变化来捕捉。我们在自家环境中施加模拟负载或事件，用真实数据确认检测逻辑能否把”真正的协调性异常”与”恰好同时发生的无关波动”分离开。若无法分离，那样的检测便毫无用处。
3. 给自己的假设迎头撞上相反的看法 #
我们会刻意把对立的解释抛向自己的假设：”这个检测真的有效吗？会不会只是碰巧命中？”即使改变观测窗口的取法，结论是否依旧不变；用别的解释会不会得出相同的结果。经不起反驳的主张，会从产品说明中剔除。
能证明的进生产，未能证明的进观察层 #
只有通过检验的，才会分阶段地推进到生产。对生产的写入，必定经过“试运行 → 受限生产 → 全量生产”这三个阶段。紧急停止命令从一开始就备好。并且所有的生产上线，都要通过“AI 提议、人来批准”这道关卡。
这条纪律也直接体现在产品的呈现方式上。比如 BASTION 的两个模块，运行状态就不一样。
- 安全模块在实战中检测并自动阻断了大量攻击行动，已有实绩，在生产中以全自动运行。
- 另一方面，质量模块（带宽的动态控制）作为功能虽已实现，但目前仍以观测为中心、处于分阶段投入中。当线路真正发生拥塞时控制是否如预期奏效，要先用那个场景的数据确认之后再说 ―― 所以我们不写”已在生产中全速运行”。
“已实现”并不等于”在生产中能跑”。这个区分，我们在产品页上也不会含糊。
对 AI（LLM）本身，我们同样不轻信、要检验 #
这种”不轻信、要检验”的姿态，同样指向作为 BASTION 核心的本地 LLM。
此前，本地 LLM 曾在监控报告中生成了并不存在的数值（其经过与对策，我们写在了《本地 LLM 在监控报告中捏造数值的经过及其对策》）。自那以后，在 LLM 的输出之中，真正驱动系统的判定 ―― 是否为攻击 IP 的最终判定、以及阻断的执行 ―― 不交给 LLM 决定，而是用与实机日志相对照的数学的、确定性的判定来完成。LLM 擅长的是自然语言的摘要与整形，而非生产中的决策。LLM 也好，（部署在可能被攻陷的 DMZ 中的）Agent 也好，对我们而言都是“不轻信、要检验”的对象。
为何这条朴素的纪律才是最大的差异化 #
AI Ops 与 AI 安全领域充斥着炫目的词藻。但真正托管生产基础设施的一线负责人，真正在意的是”它会不会引发事故””会不会因误检测、误控制而让我们为难”。
所以我们不靠流行词，而是用实际正在运行的事实来说话 ―― 在生产中运行的攻击行动检测、若为闭网构成则日志一概不外发、以及”只把能证明的东西放进生产”这一做法本身。
不以优美定夺，不在案头定夺。要能用数据去怀疑自己优美的假设。这就是我们把 BASTION 带到”可以放进生产基础设施”这一状态所凭借的纪律。
