# 面向 AI 智能体的云成本操作需要一条硬边界 AI 智能体读取云账单、整理闲置资源、估算节省机会时，风险通常很低。当它开始调整数据库大小、购买预留实例、转移计费关系或关闭账户时，工作性质就变了。这些调用会改变资金、服务容量、合同承诺或恢复选项。它们需要一条不同于普通报告的边界。 团队经常犯这个错误，是因为云 API 往往把报告和变更放在同一个身份之下。智能体先拿到一个宽泛令牌来检查成本，随后有人告诉它“执行明显的节省措施”。这样一来，权限模型就要求智能体自行判断分析何时结束、授权何时开始。不要把这个区分交给模型。 ## 报告权限不能同时带有支出权限 成本报告回答的是发生了什么，或者可能发生什么。改变支出的操作会在服务商账户中创造一个新的事实。这两类工作应使用不同凭据、不同工具，或者两者都分开。 智能体读取账单导出数据、使用指标、资源清单和价格数据后，可以安全地生成候选列表。输出应说明依据和缺口。不要因为预计节省超过某个阈值，就让它悄悄把候选项转成 API 请求。 一些名称看似无害的命令会模糊这条界线。“建议”端点可能会创建导出。“承诺”端点可能根据某个字段执行报价、购买、修改或取消。容量请求在一家服务商那里可能只是估算，在另一家服务商那里却可能是具有约束力的变更。应阅读提供商 API 文档中对确切操作的说明，不要只看控制台按钮上方的标签。 FinOps Foundation 的 Cloud FinOps 指南将活动分为提供信息、优化和运营。这是一个有用的业务模型，但它不会自动形成授权模型。人或智能体可以提供信息，却没有运营权限。应把这段差距当作有意的设计，而不是手续。 为报告端设置受限契约。它可以请求限定的时间范围、指定账户、指定区域和报告类型，并返回带有单位和来源的数据。当任务只涉及一个生产账户时，工具应拒绝“显示所有账单记录”这类无范围查询。 报告还需要携带足够的上下文，避免产生虚假的确定感。至少应保留： - 计费账户或项目范围 - 时间范围和数据新鲜度 - 货币、价格依据，以及是否包含税费或抵扣 - 每条建议对应的资源标识符 - 预测所使用的假设 这不是官僚手续。月度摊销成本和每日现金支出都可能是准确的，但它们可能会对同一项承诺得出相反结论。 ## 按后果而不是 API 动词对操作分类 像 `update` 这样的动词几乎无法说明风险。应根据云成本操作改变了什么、影响范围多大以及撤销难度如何来分类。 我会使用四个类别。第一类是观察操作，包括列出资源、获取发票、读取利用率和生成预测。第二类是局部可逆变更，例如调整自动扩缩容下限，或在团队已有经过测试的回滚方案时更改非关键工作节点的规格。第三类是受限承诺，包括购买预留实例、修改节省计划、把资源转到另一种计价安排，或更改预算告警。第四类是破坏性或治理操作，包括删除账单导出、移除付款控制、转移所有权、删除共享资源和关闭账户。 中间两个类别最容易造成错误决策。团队认为调整规格可逆，是因为可以再发送一个调整请求，却忽略了重启时间、容量限制、实例系列可用性、本地磁盘，以及依赖旧规格的应用。团队把预留实例称作一次购买，因为控制台写着“购买”。实际上，它还是一项关于未来符合条件使用量的预测，并附带期限和付款义务。 在智能体能够调用任何变更前，先要求一份后果记录。记录应写明目标、预计成本影响、服务影响、恢复方法和所需的人工批准。它可以是简单的 JSON： ```json { "action": "resize_compute_group", "scope": { "billing_account": "finance-prod", "region": "eu-west-1", "resource_group": "batch-workers" }, "before": {"instance_type": "c6i.2xlarge", "minimum": 6}, "after": {"instance_type": "c6i.xlarge", "minimum": 6}, "expected_monthly_delta": {"currency": "USD", "amount": -412}, "service_effect": "rolling replacement of batch workers", "rollback": "restore c6i.2xlarge and wait for replacements", "approval": "per_call" } ``` 这个工件可以防止一种反复出现的失败：智能体向一个有效目标提交了请求，但审核者从未看过这个目标。提供商只会验证请求内容是否可以执行，不会验证请求者是否真的指向了 `finance-prod`，预测是否采用了正确价格，或工作节点组是否有足够的备用容量。 不要只根据预计金额判断风险。小幅调整可能会中断营收服务。金额较大但范围明确的购买，如果财务已经分配预算，也可能可以接受。范围、可逆性和运行依赖都应与预计节省放在一起考虑。 ## 建议是证据，不是指令 智能体应以审核者可以反驳的形式提出成本建议。如果它无法说明资源为什么看起来浪费、使用了哪些指标，以及什么情况会证明建议错误，那么它只是在表格外面包了一层猜测。 对于计算资源调整，应要求覆盖一个相关的运行周期，而不是只取某个安静下午的方便样本。应包括 CPU、可用时的内存、队列深度、延迟、错误率和计划中的峰值。单看 CPU 经常会误导。许多服务实际受内存、存储、网络、连接池或许可限制影响。 对于存储变更，应区分分配容量与已使用字节数、预置性能与实际 IOPS，以及快照保留与当前卷成本。服务商无法原地缩小卷时，缩小卷的建议可能毫无意义。删除旧快照的建议，也可能摧毁某个数据库唯一可恢复的副本，而这份副本可能已经多年没有经过恢复测试。 承诺建议也应遵循同样的原则。智能体需要的是符合条件的使用量，而不是总支出。只适用于某个实例系列、区域、操作系统、租户模式或购买选项的承诺，无法覆盖整个宽泛服务类别。表面折扣的重要性低于真正符合条件且稳定的使用量。 当证据不足时，应要求智能体明确停止。好的停止说明可以是： > 我发现这些工作节点的 CPU 使用率较低，但没有内存指标，也没有它们计划峰值的记录。所有者确认峰值负载和回滚窗口后，我可以准备调整规格的请求。 这比一个自信的建议更有用，因为后者会迫使操作人员重新推导缺失的前提。模型倾向于补全模式。操作接口必须给它一个被正式允许的停止方式。 ## 承诺应经过独立的购买审核 预留实例、节省承诺、容量块和类似折扣，即使智能体的计算正确，也需要购买审核。它们会把使用量预测变成一项义务。 常见的弱规则是“超过某个金额阈值的承诺需要批准”。这个规则受欢迎，是因为容易解释，也容易自动化。但它会失败，因为低成本承诺可能把覆盖范围分散到许多团队，而较大的承诺可能正好符合财务已经批准的基线。阈值衡量的是工单金额，不是决策质量。 要求提案用清楚的语言写明： - 符合条件的每小时或每日使用基线 - 智能体建议购买的覆盖量 - 期限、付款选项和范围 - 计划迁移后可能失去资格的工作负载 - 对预测负责的人 一份可靠的提案还应分开三个经常被混为一谈的数字：按需支出、覆盖使用量对应的折扣支出，以及未使用承诺的成本。前两个数字让折扣看起来有吸引力，第三个数字说明预测错到什么程度后节省就会消失。 假设智能体发现多个计算资源组的使用量稳定，于是建议按总量购买覆盖。这可能合理，也可能是陷阱。一个团队可能在下个季度停用自己的资源组，另一个团队可能迁移到其他区域，第三个团队可能使用不符合条件的平台类型。智能体应报告每个贡献者以及它发现的即将发生的变化。审核者就能排除不确定需求，而不必对着一张混合图表争论。 提供商文档通常会精确描述资格规则，而计费控制台经常只是宽泛概括。如果两者不一致，应以 API 和计费文档为准。控制台上的“预计节省”只是一个场景，不是合同审核。 不要因为通用成本优化智能体有权限生成报告，就给它购买权限。应建立专门的购买路径，只接受完整的提案，并要求一位同时了解预算和工作负载计划的审核者批准。 ## 调整容量可能在省钱前先破坏服务 调整规格会改变运行中的系统，即使提供商把它视为例行操作。任何人批准较低账单前，智能体都必须展示运行层面的后果。 失败模式很常见。智能体发现实例平均 CPU 使用率较低，于是选择更小的规格并提交滚动更新。新实例内存更少。服务在每日流量峰值期间开始交换，队列延迟上升，自动扩缩容增加更多节点，月度账单反而上涨。另一种情况是，旧节点使用本地临时存储，而替换过程丢弃了未完成的工作。成本报告中从未包含这些事实。 调整规格的提案需要服务所有者、维护条件和回滚触发条件。“错误增加时回滚”太模糊，因为每个服务都有一定错误率。应定义信号和观察窗口。例如，所有者可能要求队列年龄低于某个上限、延迟达到目标，或批处理周期成功完成后，智能体才能报告成功。 执行请求应绑定所有目标选择器。绝不能让 `resize all nonproduction workers` 这类自由命令跨过授权边界。应先解析目标列表并展示出来，然后发送具体标识符，而不是发送一个批准后可能匹配新资源的标签查询。 一套有用的执行流程包含四个部分： 1. 智能体收集指标并解析出确切资源。 2. 它创建变更记录，写入当前配置、拟议配置、回滚方式和测试条件。 3. 人工批准这份针对指定资源的不可变记录。 4. 操作执行器发送请求，记录提供商的操作标识符，然后只报告契约要求它运行的检查。 “不可变”很重要。如果智能体能在批准后修改目标列表，批准卡片就只是表演。如果变更必须扩大范围，应创建新记录并重新请求批准。 ## 账户关闭需要不同的凭据和人工确认 账户关闭应单独分类，因为它会同时影响计费、身份、支持访问、保留数据和恢复路径。不要把它放进优化流程。 提供商可能会采用一系列步骤，而不是单个 API 调用。它可能要求所有者凭据、付款检查、等待期，或分别处理项目和组织成员。智能体绝不能把第一次成功响应当作关闭已经完成，或数据已经消失的证明。它应记录提供商状态，并告诉操作人员还需要做什么。 为账户关闭配置专用凭据，不承担普通读取或变更职责。要求输入账户标识符，或批准页面显示确切的账户标识符、记录中的法律名称或计费名称，以及预期影响的清楚说明。“关闭测试账户”这样的请求不够。名称会重复，标签也会被复制。 关闭账户和清理资源要分开。智能体可以盘点闲置资源并准备删除计划，但不能推断删除这些资源就获得了关闭账户的权限。清理带来的节省和终止账户这一治理决定，责任人不同。 恢复规划也会改变结论。如果团队能够导出记录、验证备份、转移域名、保留审计证据并记录依赖移除情况，就可以更有把握地批准关闭。如果做不到，智能体应生成准备度报告并停止。关闭流程失败很麻烦，带着未发现的依赖完成关闭则严重得多。 ## 批准必须绑定到确切调用 “允许本次会话执行云优化”这样的宽泛批准适合收集证据，却无法充分保护改变支出或销毁访问权限的操作。智能体可以先进行几十次合理读取，随后在操作人员停止关注后发出一次不合理的变更。 应将批准绑定到规范化请求。请求包括操作类型、账户、区域、资源标识符、目标值，以及购买期限或付款选项。预计成本影响可以作为上下文显示，但不要把它当作请求身份。预测会变化，提供商调用必须始终明确。 授权层应拒绝已批准请求与实际发出请求之间的关键差异。这些差异包括不同账户、更宽的选择器、改变数量、不同区域或不同承诺期限。缺少字段也要谨慎处理。提供商经常会填入默认值，而默认值可能在不同 API 版本或账户之间变化。 逐次确认有代价，会打断人。应把它用于少数情况下，因为中断带来的成本低于事后后悔。可以允许智能体进程使用会话级授权检查范围内的数据，但每次购买承诺、变更容量、执行账户治理操作，或使用特别标记的凭据时，都要单独确认。 Sallyport 采用了这种模式，为新的智能体进程提供会话授权，并可选择为每次使用凭据配置逐密钥批准。这个区分很有用，因为即使智能体运行已获批准，在它调用能够改变支出的凭据前，仍需要人工决策。 批准文字应让审核者看到提供商将收到什么。不要让他们只批准诸如 `cloud.execute` 这样的工具名称。应显示 `resize_compute_group`、确切目标组、新旧值以及回滚说明。如果界面无法容纳这些信息，操作契约就太宽泛了。 ## 保留智能体无法改写的审计记录 一次成功的云响应不是审计轨迹。它说明提供商接受了请求，但可能没有保留请求意图、授权、已解析目标或促成调用的证据。应在请求离开控制点前保存一份只追加记录。记录提案、证据引用、规范化请求、授权决定、调用者身份、时间戳、提供商响应和操作标识符。错误响应也要保存。被拒绝的请求经常能解释后续变通方案，或显示智能体曾尝试获取更宽的权限。 哈希链可以提供实际可用的完整性检查。每条记录都包含上一条记录的摘要和自身内容。如果有人修改、删除或重新排序历史记录，验证会在断点处失败。它不能证明原始请求是明智的，只能证明被记录的顺序未经检测就没有改变。 NIST SP 800-92《计算机安全日志管理指南》要求保护日志完整性，并确保日志可供审查。这项建议长期存在，是因为失败模式也长期存在：团队把日志收集到同一个遭到入侵的进程可以编辑的位置。对于智能体操作，应让审计写入器位于智能体直接访问文件系统和凭据的范围之外。 Sallyport 从不可写的加密哈希链审计日志中生成 Sessions 和 Activity 日志，`sp audit verify` 可以在离线状态下检查链条，无需保管库密钥。这是任何操作网关都应具备的特性：智能体可以接收结果，但不能修改自己请求执行过什么的记录。 变更后要审查记录，不要只在发生事故时审查。每周抽样检查智能体提案和已完成操作，可以发现范围错误、薄弱的回滚说明，以及人们未经阅读就点击批准的问题。日常工作比事后复盘更快暴露边界漏洞。 ## 建立狭窄的操作路径，而不是云超级用户 放在友好聊天界面后面的云超级用户凭据，仍然是云超级用户凭据。智能体的推理能力可能提高，但权限并没有因此更安全。 建立与真实决策相匹配的操作路径。一条路径可以为指定范围获取成本和使用记录。另一条路径可以准备调整规格的请求，但不能执行。购买路径只有在专门批准后才能提交承诺提案。关闭账户的路径只有在组织确实需要自动准备关闭流程时才应存在，并且最终必须停在人为确认处。 让凭据注入发生在操作执行器内部。智能体应收到结构化结果，而不是 bearer 令牌、SSH 私钥、暴露秘密的临时命令输出，或可能被它意外回显到对话记录中的占位符。这样既能保护凭据，也能减少智能体把权限带入无关工具的机会。 在信任正常流程前，先用失败案例测试这些路径。尝试在批准后替换区域，尝试让选择器匹配新创建的资源，尝试提交缺少期限的承诺请求，尝试提交只写别名而不写账户标识符的关闭请求。每一种情况都应被拒绝，并说明缺少或不匹配的字段。 通常最值得先建立的控制不是自主调整规格，而是一条能够生成证据包的报告路径，再加上一条无法调用提供商的提案路径。当审核者能够可靠地接受、拒绝和修改这些提案后，再添加一个带有绑定批准和经过测试的回滚方案的狭窄变更。需要你解释事故或不想要的购买行为的云节省，从来都不是真正的节省。