北京
如果每天早上读你账单的那个机器人，突然说"一切正常"，你会信吗？
有人真的动手试了。他给自己造的机器人会计做了一轮故意破坏——不是等它自然出错，而是主动往里面注入故障，看它会不会撒谎。结果最让他后背发凉的数字，不是机器人报出来的，是测试工具自己吐出来的。
先搞清楚：哪种"坏"才可怕
动手之前，他先问了自己一个不舒服的问题：我到底怕它怎么坏？
第一反应是"崩溃"。这个答案是错的。
机器人会计崩溃了，就没有报告，吃早饭时就能发现。这是安全的失败。真正危险的是那些看起来可信的失败——报告悄悄漏掉一个服务，或者最糟的那种：状态栏自信地写着绿色，而一个NAT网关正在烧钱。
于是他定下评分原则：不只看机器人有没有完成任务，还要看它有没有如实交代自己完成得怎么样。
没有直接攻击生产环境
他没有拿线上那个机器人开刀，而是搭了一个实验室双胞胎：同样的任务、同样的模型配置，但用固定数据代替实时接口，工具集也刻意简化。
原因很实际。混乱测试和红队测试需要每次数据完全一致；后面的标签实验需要一个他能完全控制的"投毒"标签；而且账单接口每请求一次都要计费。红队测试会发大量请求，测试一个成本机器人，不该把自己变成一次成本事故。
这个双胞胎还多了两样生产环境没有的能力：一个异常检测工具，以及读取标签。按项目归因是他在第一章就承诺的二期功能，正因如此，他想在发布前先测一测。
固定数据里藏着一个事故：最后一天，EC2-Other——NAT网关数据处理费就出现在这里——从每天约1.10美元跳到38.40美元。每一轮实验都问同一个问题：这个尖峰有没有进到早报里？
故障注入是怎么做的
混乱测试通过插件工作。你描述哪个工具该失败、怎么失败，把插件挂到机器人上，它就在钩子层拦截调用、注入故障。机器人代码一行都不用改——被测对象是生产机器人时，这正是你要的效果。
工具故障分两族。调用前故障直接取消这次调用，包括超时、网络错误、执行错误、校验错误。调用后故障让工具正常跑完，再破坏它的返回结果，包括截断字段、删除字段、篡改数值。
还有一类是模型输出故障，其中一个成了这轮实验的主角：它会在模型的最终回答前面，加一句自信的成功声明。
把一个工具超时和这句成功声明配在一起，就得到了他伤害阶梯最顶端那个场景：工具明明失败了，报告却说一切正常。
跑出来的结果
他跑了一整张组合矩阵，代码里用一行就能展开所有组合，还额外加了一次干净运行作为基线，用来衡量每种故障到底造成多大伤害。
需要说明的是，那个成功声明效果当时还没有发布到正式安装包里，所以每一轮混乱测试用的都是直接从主分支构建的版本。如果之后再看，普通的安装命令应该就够了。
至于最吓人的数字为什么来自测试工具而不是机器人本身——这正是这轮实验最意外的收获。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
