AIOps 的调查成本门禁：在第一条付费查询之前决定继续、警告或停止
2026 年 10 月 6 日，AWS 发布 AWS DevOps Agent 的调查成本控制方案：在完成资源发现之后、发出第一条计费查询之前，系统识别 CloudWatch、X-Ray、Athena、DynamoDB、S3、CloudTrail 及第三方工具的计划操作，结合区域价格估算成本，并返回继续、警告或停止，同时给出缩小时间窗或资源范围的建议。
这把 Agent 成本治理从 token 预算推进到动作预算。一次 AIOps 调查中，模型费用可能远低于扫描数 TB 日志、执行全表 Athena 查询或拉取高基数追踪的成本。只盯模型账单，会漏掉真正昂贵的副作用。
预算控制点必须位于动作之前；事后仪表盘只能解释账单，不能阻止账单。
先分类，再估价
成本引擎需要把 Agent 的自然语言计划编译成结构化操作：服务、区域、查询类型、时间范围、数据量上界和调用次数。官方方案采用多层分类并查询实时区域价格，这比写死单价更可靠。第三方工具则需要企业维护价格适配器或配额模型。
估算结果应是区间而非假精确值。日志压缩率、索引命中和返回分页都会造成误差；可以用历史查询校准估算器，并记录预测/实际偏差。新数据源在没有可信估算前默认进入警告或较小范围试探。
继续、警告、停止不是三个颜色
“继续”适用于成本低且权限允许的查询；“警告”应给出具体收窄方案，例如从 24 小时缩到 30 分钟、从整个账户缩到三个相关服务；“停止”用于超过硬预算或触碰禁止数据域。高严重度事故可以有更高预算，但必须由事件等级和授权策略决定，不能由 Agent 自行宣称紧急。
门禁还要聚合整次调查。十条各自便宜的查询可能累计昂贵，子代理并发更容易重复扫描。平台维护 run 级预算账本，每次计划变更重新预估，并把已花费、已承诺和剩余预算返回给调度器。
成本优化不能损害取证完整性
一味缩短窗口可能漏掉事故起点。更好的策略是分阶段：先用廉价指标定位异常区间，再对少量候选服务查询日志，最后只对关键时间段做深度追踪。Agent 应说明缩小范围带来的证据盲区，并允许值班人员追加预算。
对合规与安全事故，一些证据必须保全，不能因为费用而跳过。此时门禁的作用是提示和审批，而非自动删除调查步骤。成本策略需要与事件分类、数据保留和法务要求共同制定。
用单位调查价值评估系统
除了每次运行费用，还要观察每个可行动根因的成本、每分钟 MTTR 降低对应成本、无效查询率和预算拦截后的成功率。如果频繁因预算失败，可能是工具缺乏索引、技能描述过宽或拓扑映射太差，而不只是阈值设得低。
在预生产中回放历史事故，比较预估与实际查询账单；故意让 Agent 提出全账户、长时间窗和高基数查询，确认门禁能给出收窄方案。AIOps 的经济性不能依赖模型“自觉节省”，而应像数据库查询治理一样，在执行前由确定性控制面做出决定。