FinOps Capacity Intelligence让 ITOps Agent 从“能修”到“会省”想象一下你的自治运维 Agent 刚刚自动修复了一次数据库连接池耗尽响应速度比任何人类工程师都快。但当你翻开账单发现这一次修复消耗了 4 百万 token、调用了 37 次工具、触发了 3 次全量日志扫描——总计 87 美元。而这次故障本身的业务损失只有 50 美元。这就是我们进入 ITOps Agent 时代后必须面对的新现实可靠性、性能与成本必须一起优化否则“自治”会变成“账单失控”。在前 18 篇系列文章中我们构建了能自动发现、诊断、修复故障的 Agent Platform。现在是时候让它从“故障后自动修复”进入“故障前优化”了。本篇将引入两个关键能力FinOps成本运营与Capacity Intelligence容量智能并把它们统一进同一个Cost / Capacity Agent。为什么这个问题在今天突然重要传统 FinOps 关注云资源的单位经济性CPU 小时、存储 GB、网络流量。但当 AI Agent 成为运维的执行主体时新的成本维度出现了LLM token每次推理、每次工具调用的提示词和补全都消耗 token价格随模型而变化。Agent executionAgent 自身的编排逻辑、多步推理、记忆读写可能触发多次模型调用。Tool call查询监控、拉取日志、执行变更背后是 API 调用、数据库查询、甚至额外的计算资源。如果只盯着云资源账单你会完全忽略 Agent 自身的“智力消耗”。更危险的是Agent 的“修复成功”往往掩盖了成本一个 P1 事故可能被一个昂贵的多 Agent 协作流程解决但单位成本可能高得离谱。因此Cost per Incident、Cost per Successful Resolution这样的业务级指标必须被度量、跟踪和优化。这正是 FinOps 与 AI 运维融合的核心。核心概念回答三个问题FinOps 的经典三问在 Agent 场景下依然成立但答案的颗粒度变了Where is money spent?钱花在哪里Why is it spent?为什么花What should we change?我们应该改变什么为了回答这些问题我们需要一个更细的成本模型总成本 compute storage network database LLM token agent execution tool call注意最后三项。它们不是传统的云资源费用而是 Agent 运行过程中产生的“智力成本”。如果不把它们纳入模型你永远无法理解为什么某个 Agent 的“修复”如此昂贵。Cost / Capacity Agent 的架构设计在 ITOps Agent Platform 中我们引入一个独立的Cost / Capacity Agent它负责两件事成本归因与优化建议统计每个 Agent、每个工具、每个模型、每次 incident 的单位成本。容量预测与扩缩容建议基于历史负载和业务需求预测未来容量风险并给出带成本影响的建议。成本归因维度成本必须分维度统计否则无法定位问题cost_per_incident单次事故的 Agent 总成本cost_per_agent单个 Agent 的累计或平均成本cost_per_tool单个工具调用的成本cost_per_model不同 LLM 模型的成本cost_per_successful_resolution成功解决一次 incident 的平均成本这是最核心的业务指标例如你可能会发现某个 Agent 在调查 incident 时调用了昂贵的大模型做日志摘要但另一个小模型也能达到类似效果从而将cost_per_successful_resolution降低 60%。Capacity Agent 的输入与输出Capacity Agent 的输入包括系统指标CPU、Memory、QPS、Latency、Traffic业务信号季节性流量、促销活动、产品发布计划历史趋势过去 N 天的负载模式输出则是Forecast未来一段时间如 7 天、30 天的资源需求预测Scale Recommendation扩容/缩容建议包括具体规格和数量Capacity Risk容量风险评分以及触发预警的阈值Cost Impact该建议对月度云成本的影响关键点Capacity Agent 不是孤立工作它必须与Error Budget联动。扩容建议不仅要说明能降低多少延迟或失败率还要解释它对 SLO 和成本的双重影响。比如“增加 2 个副本可以降低 P99 延迟 30%预计月度成本增加 $350同时 error budget 消耗率降低 15%。”实战实验一周的成本审计假设我们运行了一个 ITOps Agent Platform过去一周处理了 50 个 incident。我们想知道Agent 调查这些 incident 花了多少钱哪些模型和工具最贵能不能优化步骤打标签确保每次 LLM 调用、工具调用都记录了model、agent、tool、incident_id等标签。聚合计算按 incident 维度汇总 token 数、工具调用次数、模型单价等。排名分析找出cost_per_successful_resolution最高的 incident以及使用最频繁/最昂贵的模型和工具。对比实验对于高频昂贵的操作尝试换用更小的模型、增加缓存、减少不必要的工具调用然后观察成本变化。举个例子我们发现某个日志分析工具平均每个 incident 被调用 8 次每次产生 $0.6 的成本主要来自调用 GPT-4 做摘要。改用 GPT-4o-mini 后摘要质量几乎不变但单次成本降到 $0.08cost_per_successful_resolution从 $12.4 降到 $4.7降幅 62%。代码示例计算单位成本下面是一个简单的 Python 函数用于计算每个成功解决 incident 的单位成本defunit_cost(agent_usage,resolved_incidents): agent_usage: 对象包含 tokens 数量和 token_price以及 tool_calls 数量和 tool_price resolved_incidents: 成功解决的 incident 数量 total(agent_usage.tokens*agent_usage.token_priceagent_usage.tool_calls*agent_usage.tool_price)returntotal/max(resolved_incidents,1)实际生产环境中你需要从分布式追踪、LLM 网关或成本数据库中聚合这些数据。但核心逻辑就这么简单把智力消耗折算成钱再除以业务成果数量。生产环境最佳实践打标签是第一原则Token、tool call、模型、agent 都必须打标签否则成本无法归因。没有标签的成本数据就像没有维度的监控指标几乎无用。容量预测与 Error Budget 联动扩容建议必须解释对 SLO 和成本的双重影响。不要只说“CPU 不够了加机器”而要说“当前 P99 延迟在 850ms接近 1s 的 SLO 阈值增加 2 个副本预计 P99 降至 600mserror budget 消耗降低 30%月度成本增加 $200”。建立 Capacity Risk 阈值不要等到资源耗尽才行动。设置预警阈值如 CPU 连续 4 小时超过 75%或预测未来 24 小时利用率超过 90%触发 Capacity Agent 主动评估并提前给出建议。常见错误只算云资源账单遗漏 Agent 自身的推理/执行成本。这是最普遍的错误。如果你的 FinOps 报告里没有 token 和 tool call 成本那么你的“成本优化”是盲目的。容量预测只看历史均值忽略季节性与业务活动。历史均值会掩盖周期性峰值。例如黑色星期五、年终结算、产品发布等事件会带来数倍的流量必须纳入预测模型。“优化”只降成本牺牲了可靠性。省了机器多了故障。成本优化必须在 SLO 约束下进行。一个 P1 故障造成的业务损失可能远超省下的几百美元云费用。安全与可观测性成本与容量数据属于敏感经营数据它们暴露了业务规模、流量模式、甚至商业活动。导出和 Agent 访问这些数据时需要权限控制避免泄露给无关人员或第三方服务。同时成本指标应该挂到Agent Trace和Incident上形成“这次故障花了多少钱”的完整账本。当你在事后复盘时可以看到每个步骤的 token 消耗、工具调用费用以及总成本。这不仅是财务需求也是技术复盘的重要输入。评估与验收如何知道 Cost / Capacity Agent 做得好不好预测准确率用 MAPE平均绝对百分比误差评估容量预测。低于 15% 通常认为不错。扩容建议命中率Agent 建议扩容后是否真的发生了容量风险或者发生了风险但 Agent 没有提前预警真实成本节省优化建议实施后是否真的降低了cost_per_successful_resolution需要对照实验A/B 或时间前后对比来验证。最终验收标准很直接能回答任意一次 incident 的单位成本并能给出带解释的容量预测与扩容建议。思考与延伸在结束之前留两个问题给你你知道“修好一次 P1 事故”平均花多少 token、多少钱吗如果你现在无法回答那么你的 Agent 平台还缺少成本可见性。上一次扩容决定是基于预测还是基于恐慌大多数团队是后者——等到系统开始报警才紧急加机器。而 Capacity Intelligence 的意义就在于把决定提前到“预测”阶段。FinOps Capacity Intelligence 不是锦上添花而是自治运维走向成熟的必经之路。当 Agent 既能快速修复故障又能控制成本、预测容量它才真正值得托付生产环境。延伸阅读CNCF: Agentic EnterpriseGoogle SRE: Eliminating ToilMicrosoft: Autonomous Operations下一篇我们将深入探讨如何将 Cost / Capacity Agent 与现有的告警、工单、变更流程集成实现真正的闭环自治。