用四道安全关卡约束自演进运维 Agent

生产故障里的 AI，能不能从「帮忙看日志」走到「自己写补丁、验证效果，再记住教训」？Google 的研究参考架构 Project Chrysalis 尝试把这条链路串起来，并给代码执行和结构调整加上治理边界。

演示结果很亮眼：首次缓解从人工基线的 15 至 45 分钟缩短到 1.8 秒。但它采用的是模拟流量，而且「500 清零」伴随着大量 429。读这篇最有价值的地方，是看清自动处置如何形成闭环，以及这些数字到底证明了什么。

它解决的是缓存击穿后的连锁故障

原文设置了一场黑五抢购：流量涌向冷库存键，Memorystore（Redis）在 LRU 内存淘汰约束下丢失缓存，未命中请求直接打到 Cloud SQL，最终耗尽 PostgreSQL 连接池。

演示先用 5 个请求建立基线，再让 50 个并发请求访问 15 个冷库存键。缓存命中率从 100% 跌至 0.0%，连接池达到 100% 饱和，具体是 2/2 个活跃连接被占住。P99 延迟升至 312.8 至 519.8 ms，HTTP 500 比例达到 72.7% 至 80.0%，原文记录了 40 次失败结账。

这里的危险动作，是原文所谓的「凌晨 3 点恐慌反射」：看到连接池耗尽，就重启连接池。作者描述，这会进一步冲击数据库，让尾延迟接近十倍增长；后续归因阶段记录的延迟达到 3,800 ms。

作者想突破固定工具列表的限制。传统 Agent 即使判断出应该限制入口流量，也可能没有对应工具，只能继续给建议。Chrysalis 则让 Agent 临时生成令牌桶限流中间件，检查、签名后挂进 API Gateway。

第二轮同样的 50 请求突发中，HTTP 500 降至 0.0%，连接池饱和度从 100% 降至 0%，P99 回落到 18.2 ms。不过，只有 10 个请求从热缓存得到服务，另有 40 个请求被 HTTP 429 拒绝。

这组结果证明了限流可以保护服务，没有证明所有结账请求都恢复了成功。

「自进化」具体改了什么

这里的自进化，不是模型重新训练，而是工具、运行经验和 Agent 分工发生变化。作者用三个研究方向组织这套机制。

Dream-RSI 负责反事实模拟：把生产请求轨迹导入 BigQuery，比较不同令牌桶容量和补充速率。反事实就是拿同一批历史请求，计算「当时换一种策略会怎样」，尽量避免直接用线上用户试错。

APEX 把变化分成三层。Layer 1 生成临时内存补丁，先缓解正在发生的故障；Layer 2 提炼经验，把 Cloud KMS 签名的操作原则写入向量检索；Layer 3 调整多 Agent 有向无环图（DAG），增加长期负责某类问题的专家。

这次提炼出的规则是：缓存淘汰引发请求风暴时，禁止重启数据库，应使用令牌桶丢弃超额负载。随后，系统提议增加 Traffic Shaping Specialist Agent，让它拥有速率限制、队列深度检查和令牌补充工具。

结构更新需要人工签发批准令牌。获批后，系统在 RAM 中实例化专家，把它作为 Diagnostic Agent 的并行节点加入 Supervisor Router Agent，更新路由指令，再重新绑定运行中的 Google ADK Runner。作者报告，这一过程没有容器重启，也没有停机。

AgentEvolver 则负责逐步归因。它根据干预前后的 P99、HTTP 5xx 和连接池饱和度，计算各操作的边际 Shapley 贡献，惩罚重启动作，给令牌桶补丁记下 +0.97 credit。

这比「最后恢复了，所以所有操作都有功」更合理。但原文没有交代 Shapley 计算中的操作组合如何构造，也没说明怎样排除缓存自然变热等因素。它展示了归因思路，尚不足以让读者复核因果结论。

能写代码还不够，关键是执行边界

演示中的 Supervisor Router Agent 由 Gemini 4 Argon 驱动。告警进入推理流程前，Model Armor 检查提示注入并处理敏感数据。补丁生成后，还要经过三道检查。

首先，AST Sandbox Visitor 检查抽象语法树，阻止禁用系统模块和动态执行入口。随后，OPA Policy Controller 检查策略是否满足 SLA，本例要求令牌补充速率 >= 10.0 req/s。最后，Cloud KMS 使用 EC_SIGN_P256_SHA256 签名产物摘要，由 Binary Authorization 中间件在挂载边界验证来源。

通过这些检查的补丁，采用 10-token 容量和 40.0 req/s 补充速率。高风险的 Tier-2 拓扑调整另设 Dual-Custody HITL 审批，所有检查、签名、策略判定和批准记录进入 Cloud Logging。

这些机制分别回答不同问题：代码是否包含禁用结构、参数是否越界、产物是否来自可信流程、结构变化是否获批。它们不能互相替代。签名通过只能说明来源和完整性符合要求，不能说明限流算法一定正确；AST 检查也不能单独证明运行时安全。

后续验证还暴露出一个需要解释的地方。系统回放 400 组策略，报告约 0.5 ms 完成向量化内存扫描，选出的 Pareto 最优策略却是 5-token 容量、5.0 req/s 补充速率，同时保持零 5xx。

5.0 req/s 低于前面的 10.0 req/s 最低 SLA。原文没有说明它只是离线候选、采用了不同约束，还是需要额外审批才能部署。

约 0.5 ms 的口径也应谨慎理解。原文把 BigQuery 与内存回放放在同一流程中，但没有拆分数据导入、查询启动和扫描计算的耗时，不能据此认定完整 BigQuery 流程只需半毫秒。

最终，Curiosity Chaos Red-Team Agent 在隔离影子沙箱中清空 100% 缓存，发起 200 个并发请求，得到 0 个 HTTP 500 和 13% 的最高数据库负载。它补充了压力验证，但仍属于受控演示。

我的判断

我认可它把「处置、验证、归因、记忆」连成闭环。对自动运维来说，记录哪些动作加重了故障，和找到有效动作一样重要。把临时补丁与长期结构调整分开治理，也有实际价值。

不过，原文将其称为可用于生产的架构，证据还不充分。它展示的是小连接池、特定缓存故障和受控流量，没有给出复杂业务依赖、长时间运行、补丁回滚，以及多次故障下的稳定性数据。人工处置的 15 至 45 分钟基线，也没有交代测量方式和样本量。

与预先实现限流器、由 Agent 选择参数相比，运行时生成代码多了灵活性，也多了验证负担。本例的有效动作恰好是常见令牌桶，因此演示尚未证明「现场写工具」优于「调用已有工具」。固定工具不足以覆盖新故障，是作者的合理判断，但不能直接当成对照实验结论。

还有两处实现细节没有说清：Dual-Custody 在演示中只明确描述了一位值班 SRE 的批准，双重保管如何落实并不清楚；所谓永久专家通过 RAM 更新加入，容器重建后如何恢复，也未交代。

更值得借鉴的是治理闭环，具体性能数字应留在这场模拟的边界内。

能拿来做什么

• 在 Node API 的缓存故障演练里，同时记录 500、429、成功请求数、P99 和连接池占用，先区分服务受到保护与业务请求成功这两件事。
• 给运维 Agent 优先接入已有的限流、队列检查和连接池观测工具，把参数校验做成独立策略；确有工具缺口时，再评估代码生成与受限执行。
• 把故障处置拆成可审计的步骤，记录每步前后的指标，并将经过复核的禁用动作写成可执行约束，避免只保存一段复盘摘要。
• 如果尝试动态增加 ADK 专家节点，应同时设计审批、失败回滚和重启恢复机制，验证运行中的变化能否被可靠保存和重建。