为EKS值班引入只读调查与PR修复代理

作者提出了一套为 EKS GitOps 平台接入 AI 值班代理的方案：代理读取日志、事件和代码，调查故障，再通过 PR 提出修复；人审核合并后，由 Argo CD 执行集群变更。现有节选展示了架构和部分触发代码，还不足以确认整条流程的实际运行效果。

目前能确认什么

方案沿用 hub-spoke 集群结构：Argo CD 位于 hub，管理各 spoke 集群，业务与 CI/CD 分处不同 AWS 账号。GitOps 的基本做法是把期望配置保存在 Git，由控制器持续协调集群状态。

文中流程从 Pod 因内存不足被终止的 OOMKilled 告警开始。EventBridge 触发 Lambda，为发往 AWS DevOps Agent 的 webhook 计算签名。调查代理通过部署在 Amazon Bedrock AgentCore 上的只读 MCP server，以及 CloudWatch、CloudTrail 和 GitHub 仓库获取信息。

修复环节交给 CodeBuild 中运行的 Kiro CLI：修改 GitOps 仓库并创建 PR，随后由人合并、Argo CD 同步。这里的「只读」针对生产环境，修复流程仍需要仓库写入权限。

作者还记录了一个具体问题：最初选择的自定义告警指标无人上报，无法唤醒代理，后来改用了 Container Insights 已发布的指标。

我的判断

这套方案最有参考价值的是把调查权限与生产变更权限分开。

对平台工程师而言，AI 可以先承担收集证据、定位可疑配置和准备补丁的工作，已有的代码审查与发布流程继续承接变更。但 PR 可审查，不代表修复一定正确；审批人仍需要看到故障证据和修改依据。

节选尚未交代调查结果如何传给 Kiro CLI、跨账号权限如何收紧，以及错误补丁、重复告警和审计记录如何处理。因此，目前能判断的是权限边界设计清晰，还不能判断它能否稳定缩短值班处理时间。