RDS for MySQL 8.0 升级 8.4 的下游 Binlog 消费处理实战（二）—— 用 Kiro Custom Agent 为割接 Runbook 加上可执行的门禁
内容提要
本文介绍用 Kiro Custom Agent 为 RDS for MySQL 8.0 升 8.4 的 Canal 位点割接 Runbook 添加可执行门禁。核心是按“后果是否可逆、能否自动校验”分工：只读操作 allow 自动执行，停实例、删位点等变更 ask 需人工批准，switchover 等不可逆操作 deny 由人执行。实测 deny 跨作用域优先、复合命令逐条判定、Agent 不能改写自身权限文件。两轮演练跑通正常与故障路径，对账零缺失，并修正 retention 不继承、并集须在目标实例重算等六处结论。
延伸解读
门禁为何必须写成策略而非提示词
文章强调，仅靠提示词约束 Agent 并不可靠。Kiro 的能力级权限把操作分为 allow、ask、deny 三类，由运行时强制执行，Agent 无法绕过。实测证明 deny 跨作用域优先、复合命令按子命令逐条判定、Agent 不能改写自身权限文件。这意味着门禁是可检查、可审计的机器规则，而不是依赖模型自觉遵守的软性要求。对运维团队而言，这是把 Runbook 从文档升级为可执行工具的关键一步。
“配置了”不等于“生效了”
文章记录了一个易被忽视的陷阱：Kiro CLI 2.18.1 可以安装、Agent validate 校验通过，但 permissions 规则一条都不执行，且没有任何提示。validate 对随意编造的字段也返回退出码 0。这与文章开头那次位点事故属于同一类失败——配置被静默忽略，现场看不出异常。因此部署脚本必须同时检查 CLI 版本，并故意执行一次被禁止的操作，确认 deny 确实拦截，两项都通过才允许启动割接。
并集正确性取决于时点与对象两个条件
文章修正了前篇结论：并集的正确性不只取决于计算时点要在 retention 确认之后，还取决于计算对象必须是 Canal 实际要连接、且运行目标版本的实例。演练中曾在旧 reader 上算出并集，同一 UUID 区间从 1-3410 缩到 1-3356，差 54 个事务，会让 Canal 误判这些事务已消费而静默跳过。更危险的是，配置校验以并集文件为基准，基准错了校验反而通过，直到对账才暴露缺失。
演练环境与准入规则的实际成本
文章用 CDK 搭建与生产形态一致的演练环境，按 us-east-1 按需价格估算约 $264/月、约 $9/天，用完即销毁。环境必须复刻四项关键形态：Canal 官方镜像加 Admin 托管配置、位点存 ZooKeeper、订阅只读副本、从跳板机执行运维命令。准入规则只有一条：Agent 必须先在演练环境完整跑通割接并验证失败处置，才允许参与生产割接。两轮演练共发现十余个真实问题，并据此修正了前篇六处结论。
Q&A
运维中哪些工作可以交给 AI Agent，哪些必须由人来做？
按“后果是否可逆、能否自动校验”两个维度划分四类：后果可逆且机器可判定的（如逐项核对校验结果、顺序守护、故障分诊、动态取证）由 Agent 自主执行；后果可逆但机器不可判定的（如停实例、删位点、启动实例）由 Agent 提议、人批准；后果不可逆且机器不可判定的（如 switchover、改 RDS 参数组、销毁环境）由人独立执行，Agent 不得介入；定义成功指标、校验标准、执行顺序和权限只能由人完成。
Kiro Custom Agent 的权限模型 allow/ask/deny 是怎么工作的？
Kiro 采用能力级权限，按 fs_read、fs_write、shell 等能力声明匹配模式和效果：allow 静默执行、ask 弹出确认、deny 永久阻断。优先级为 deny > ask > allow，作用域之间没有优先级，最终采用最严格的效果，只要存在一条 deny 规则，任何位置的 allow 都无法覆盖。规则可写在用户级、工作区级或 Agent 配置的 permissions 字段中。
deny 规则真的能阻止 Agent 执行被禁操作吗？
实测可以。在 Kiro IDE 1.0.309 上用探针 Agent 验证了三条：直接执行禁区命令被阻断，提示中列出命中的规则及作用域；用 && 拼接禁区命令时整条命令被拒绝，前半段合法部分也不执行，复合命令会拆分逐条判定；跨作用域时 deny 优先于 allow，且运行时硬编码禁止 Agent 写入自己的权限文件。
为什么 Agent validate 通过不代表权限规则生效？
实测发现 Kiro-cli Agent validate 对随意编造的字段也返回退出码 0，它只做结构校验，不代表规则会被运行时执行。两轮演练使用的 Kiro CLI 2.18.1 就出现过校验通过但 permissions 一条都不执行的情况。因此必须用 deny 冒烟探针实际执行一次被禁止的操作，确认系统确实拦截，才能放行割接。
蓝绿割接中 binlog retention 需要注意什么？
retention 是实例本地配置，绿环境不继承。7-23 演练实测发现绿库 gtid_purged 一小时内从 1-8 增长到 1-1722，业务 binlog 正在被清理，已清理区间会被并集标记为已消费，导致数据丢失且无告警。因此 switchover 完成后的第一个动作是在新主库重设并验证 retention（如设为 168 小时），并集等 retention 确认之后再算。
并集修补时为什么必须在正确的实例上重算？
并集的正确性由两个条件共同决定：计算时点要在 retention 确认之后，计算对象必须是 canal 实际要连接且运行目标版本的实例。8-15 演练中先在旧 reader 上算并集，同一 UUID 区间从 1-3410 缩到 1-3356，差 54 个事务，错误并集会让 canal 跳过这 54 个事务，造成静默丢数据且不触发报错。检测方法是并集文件 mtime 必须晚于 switchover，且 UUID 段要与目标实例的 server_uuid 对应。
switchover 后如何确认每个成员都切换成功？
不能只看 B/G 的聚合状态。8-15 演练中聚合状态显示 SWITCHOVER_COMPLETED，但逐成员查看 SwitchoverDetails 发现 reader 成员是 SWITCHOVER_FAILED，原 reader 名仍解析到被冻结的 8.0.42 旧副本，而 Canal 订阅的正是 reader。检测方法：用 aws rds describe-blue-green-deployments 逐成员检查 SwitchoverDetails，并用 SQL 在 canal 实际要连接的 endpoint 上确认 @@version 是目标版本。
演练环境用 CDK 搭建的成本大概是多少？
按 us-east-1 按需价格估算约 $264/月，约 $9/天。分项：EKS 控制面约 $73/月，节点组 t3.large×1 约 $63/月，RDS db.t4g.micro×2 约 $28/月，MSK kafka.t3.small×2 约 $69/月，跳板机 t3.medium 约 $31/月。演练环境按天使用，用完立即 cdk destroy；中途暂停可停跳板机与 RDS 并将节点组缩容到 0，但 EKS 控制面和 MSK 不支持停止，长时间闲置仍会产生费用。
