AI Agent 时代最贵的一句话:"刚刚那条命令花了多少钱?"

—— 阿里云 CLI 上线执行前询价,5 步换 IP 场景实测,预估与账单一分不差

一个凌晨的运维故事

假设是凌晨 3 点。

一台跑生产业务的 ECS 需要更换公网 IP。你把这件事交给了 AI Agent,它规划出一套 5 步动作:

① 改带宽计费方式 → ② 固定 IP 转 EIP → ③ 解绑 EIP → ④ 分配新 IP → ⑤ 释放旧 EIP

Agent 停下来问你:"要按回车吗?"

你犹豫了。不是不信任它的技术判断——是因为你不知道这五下回车按下去,一共要花多少钱。有的步骤是即时扣费,有的步骤是退费,有的会启动一段"未来按流量出账"的按量资源。5 个步骤加起来的账单,只有当真的按下去、订单结算完了,你才能在费用中心看到。

按之前的做法,你只有两个不太优雅的选择:

• 硬着头皮按,第二天早上打开费用中心盯着看;

• 打开 5 个产品的定价文档,把带宽、EIP、按量单价、剩余时长退款一项一项算——尤其变配的"退旧买新"差价,涉及原订单剩余价值、新配置价目、折扣叠加,自己很难算准。

如果 Agent 可以在按下回车之前,替你把 5 步的账都算好、告诉你"总计大约花 XXX 元,退费大约 XXX 元",你会不会更敢让它动手?

一条参数,让每条命令都能"先看账单"

从最新版 CLI 开始,任何一条已经接入询价的命令,后面加一个 --estimate-cost,请求就不会被真正执行,而是返回一份精确到"分"的报价:

aliyun ecs modify-instance-network-spec \
  --region cn-hangzhou --instance-id i-xxx \
  --network-charge-type PayByBandwidth --internet-max-bandwidth-out 5 \
  --estimate-cost

返回里的每一笔钱都有 module 拆解——原价、折扣、折后价、变配的退旧买新差价、按量资源的单价预告,一样不落。

这不是估算,是与交易系统同源的实时报价。也就是说,如果你把 --estimate-cost 去掉真的执行,产生的订单金额就是这个数字。

关键戏剧点:跨步骤怎么办?

真正让人皱眉的是文章开头那种 workflow——步骤 4 的费用,取决于步骤 1 是否已经执行完了。

在换 IP 这个案例里:

• 步骤 1 会把实例从"固定带宽"改成"按流量";

• 到了步骤 4,实例已经不是你现在看到的状态了;

• 如果直接问"步骤 4 花多少钱",服务端只会看到当前状态,报错说"参数组合无法匹配任何计费规则"。

询价服务为此设计了一个叫 PricingContext 的输入口袋:你可以传入"假设步骤 1 已经完成"、"假设月流量 100GB"这类未来状态或预估用量,报价引擎会按你给的假设算钱。

于是这 5 步 workflow 的账单,在按下第一次回车之前,就可以完整预知——每一步一条询价请求,免费步骤明确标注,汇总到一起就是一张事前的账单预览。

这个 workflow 的询价全貌:

执行前逐步询价 → 汇总为一张"事前账单":

  ① 转按流量        → 询价:未来流量费 ¥0.8/GB × 预估量
  ② 固定IP转EIP     → 询价:转换/持有单价
  ③ 解绑EIP         → 免费 ✔
  ④ 分新IP+设带宽   → 询价:PricingContext 假设「①已完成」
  ⑤ 释放旧EIP       → 免费 ✔(停止旧IP计费)
  ═══════════════════════════════════════════
  ⇒ 第一步回车之前,整单账单已知

一分不差:每一笔即时订单都对账过

光说不练不算数。真的用一台全新实例把 5 步走了一遍,凡是产生即时订单的动作,都拉了费用中心的订单核对，以下是示例:

四笔交易,预估与实际账单分毫不差。同一台实例、真实资金流水,截图和订单号都留档。

(不同账号、不同时段的绝对金额会有差异——折扣、剩余时长都会影响——但"预估等于实际"这个结论是恒定的。)

这能怎么玩

一旦"事前询价"变成一条参数,以下几种场景就有了新的可能:

运维圈——变更前先跑一遍 --estimate-cost,把预估金额贴到工单里,再走审批。再也不用等第二天早上看账单心跳加速。

AI Agent 圈——Agent 生成命令后,自动追加 --estimate-cost 探一次价,把金额嵌入到"按回车"前的确认信息里。用户看到的不再是"agent 想执行 X 命令",而是"agent 想执行 X 命令,预估花费 Y 元"。这一步,把 agent 从"技术助手"推向"财务上可信的助手"。

FinOps 圈——把 --estimate-cost 加进变更流水线的干跑环节:发布前先询一次价,预估金额超过阈值就让 pipeline 失败、转人工审批。事后账单分析永远滞后,事前询价才是真正的成本控制。

想自己试试?

一条命令,看看当前你关心的产品里哪些操作已经接入询价:

aliyun list-supported-pricing-apis

覆盖列表在持续扩大——你熟悉的核心产品大概率已经在里面了。

对哪条命令的花费好奇,就在后面加上 --estimate-cost,不用担心误操作:

aliyun ecs run-instances ... --estimate-cost              # 建个新实例要多少钱
aliyun ecs modify-prepay-instance-spec ... --estimate-cost # 升配要补多少差价
aliyun ecs modify-instance-network-spec ... --estimate-cost # 改网络配置要多少钱

想完整体验开头那个「换公网 IP 五步」?下面这套可直接复制(把 $INS 换成你测试账号里的实例 ID;全程只询价、不执行):

INS=i-xxxxxxxx          # 你的实例 ID(建议用测试实例)
REGION=cn-hangzhou

# 步骤1 带宽转按流量:按量计费需给出预估用量(PricingContext)
aliyun ecs modify-instance-network-spec --region $REGION \
  --instance-id $INS --network-charge-type PayByTraffic \
  --estimate-cost --estimate-cost-context EstimatedInternetTrafficOutGB=100

# 步骤2 固定公网 IP 转 EIP
aliyun ecs convert-nat-public-ip-to-eip \
  --instance-id $INS --biz-region-id $REGION --estimate-cost

# 步骤3 解绑 EIP(免费操作。对它询价会得到一条明确提示:
#   "no pricing information ... this OpenAPI either incurs no cost
#    or has no pricing mapping registered yet" —— 这不是故障,是"不涉费"的答复)
aliyun vpc unassociate-eip-address --region $REGION \
  --allocation-id <eip-id> --instance-id $INS --instance-type EcsInstance --estimate-cost

# 步骤4 设带宽分新 IP:用 PricingContext 假设"步骤1已完成(已按流量)"
aliyun ecs modify-instance-network-spec --region $REGION \
  --instance-id $INS --network-charge-type PayByBandwidth --internet-max-bandwidth-out 5 \
  --estimate-cost --estimate-cost-context InternetChargeType=PayByTraffic EstimatedInternetTrafficOutGB=100

# 步骤5 释放旧 EIP(免费,询价提示同步骤3;执行后停止旧 IP 计费)
aliyun vpc release-eip-address --region $REGION --allocation-id <old-eip-id> --estimate-cost

需要 CLI 版本 ≥ 3.4.2,并把产品插件更新到最新(aliyun plugin update)。

提示:示例中的金额是某一次实验的实测值。你的账号折扣、实例剩余时长不同,询出的数字会不同——但"询价 = 最终订单金额"这一点不变。

📖 How-to-use:完整命令参考、PricingContext 用法、ECS 换 IP 多步询价 step-by-step、以及给 AI Agent 的接入指引,都在这里 → 阿里云 CLI 询价能力技术手册

Agent 时代,让每一次"回车"都心里有数。