「没有遥测，不许上线」：Gartner 说按量计价的 Agent 会把预算打穿 50%

2026 年 10 月 26 日，Gartner 发布了它对 2027 年基础设施与 IT 运营（I&O）的判断：五条 AI 趋势，覆盖 Agent 在运维里的角色、自主工作流的成本、混合 AI 基础设施、运营与网络安全的合流，以及 I&O 自身演变成企业 AI 平台的编排者。这份预测建立在一项调研上——2026 年 4 月到 5 月访问了 272 位 I&O 负责人，其中 58% 认为在未来 12 个月里，把 AI 的概念验证推进成 I&O 的实际采用是重要优先级。Gartner 副总裁分析师 Jonathan Forest 的建议是别贪多：把钱投在能产生可衡量业务影响的方向，而不是试图一次解决 AI 的所有面向。

痛的不是贵，是不可预测——这句话在 2026 年被反复验证。

一、Agent 进运维：从接近零到一半，只用了四年

第一条预测的跨度很大：到 2030 年，50% 的组织会在 IT 运营中使用几乎不需要人工介入的 AI Agent，而 2026 年这个比例接近零。Gartner 点名 Agent 会接手的活是事件分级（incident triage）、变更校验和修复执行。这几件事的共同点是「有明确判定标准、但需要人来回翻资料」，正好是 Agent 擅长的形状。对工程团队来说，这条预测的实际含义不是「准备被替代」，而是「现在就要把三样东西建起来」：Agent 的权限边界（它能改什么、不能改什么）、动作审计（谁在什么依据下做了什么）、以及回滚能力。没有这三样，第一个 Agent 上线的那周就会变成事故周。

# The gate Gartner is describing, written as a schema you have to fill
# BEFORE the agent gets a production credential.
workflow_id: io-incident-triage
agent:
  name: triage-agent
  version: 2026-10-24
  tools: [read_alerts, read_runbooks, open_ticket]
budget:
  pricing_model: variable            # variable | committed | bundled
  monthly_cap_usd: 400
  per_run_cap_usd: 0.40
  alert_at_pct: [50, 80, 100]
telemetry:
  emits:
    - run.span                        # one span per agent invocation
    - run.tokens.input
    - run.tokens.output
    - run.tokens.cache_read
    - run.tool_calls
    - run.outcome                     # success | timeout | denied
  sink: otel
  retention_days: 30
  owner: platform-ops
# No emits block, no credential. That is the whole policy.

二、Token 经济学：那 50% 到底在说什么

第二条预测是整份材料里最有信息量的一条。Gartner 说，到 2027 年，用不设上限的按 token 计价模式来跑 IT 运营 Agent 的企业，实际支出会超出初始预期 50% 以上——对照组是采用可预测的订阅制和打包定价的企业。这句话常被读成「模型涨价了」，其实是定价结构的问题：从对话式 AI 转向自主 Agent，每个任务要走的步数变多了，而每一步都要 token；难任务的步数没人能提前预测。同一份材料里的另一句解释是：Agent 消耗的 token 远多于对话式 AI，因为多步任务本身就需要多得多的 token。所以真正的行动项是两件——一是把「按量」和「包月/打包」放在一起算盈亏平衡点，二是给每一次 Agent 运行设上限，而不是给整个团队设一个总额。

# Why ">50% over expectation" is a pricing-model statement, not a
# statement about model prices falling. Compare two ways to buy the same
# volume before you sign anything.

def compare(monthly_runs, avg_tokens_in, avg_tokens_out,
            price_in, price_out, committed_monthly_usd, run_cap):
    variable = monthly_runs * (
        avg_tokens_in / 1e6 * price_in + avg_tokens_out / 1e6 * price_out
    )
    # Agents retry. A hard task can cost 3x the median run.
    variable_tail = variable * 1.6
    committed = committed_monthly_usd
    return {
        "variable_usd": round(variable, 2),
        "variable_with_tail_usd": round(variable_tail, 2),
        "committed_usd": round(committed, 2),
        "worst_case_overrun_pct": round((variable_tail / run_cap - 1) * 100, 1),
        "breakeven_runs": round(committed / (variable / monthly_runs), 0),
    }

# The useful output is breakeven_runs, not the headline bill. If your
# agent fleet runs below breakeven, variable pricing is correct and the
# cap is what protects you; above it, the overrun is structural.

三、把「没有遥测，不许上线」写成闸门

Gartner 给的建议原话很短：no telemetry, no deployment。这句话如果在会上念一遍，下周就会被忘掉；写成代码才有效。做法是给每个 Agent 工作流一张「上线前必须填满」的表：定价模型、月度上限、单次运行上限、以及必发的遥测指标——一次调用一个 span，输入/输出/缓存读取 token，工具调用次数，以及结果状态（成功、超时、被拒绝）。再加一个很多人会跳过的字段：遥测的负责人。没有负责人的成本，等于没人预测的成本，而这正是 Gartner 描述的那种失败：账单来了才知道超了。落地成 CI 检查之后，这套东西的维护成本接近于零，拦住的却是最贵的那类错误。

到 2029 年，80% 的大型企业会把生产 AI 负载铺在至少三种基础设施环境上。

# Enforcement, not exhortation. This runs in CI and blocks the deploy.
import json, sys

REQUIRED_EMITS = {
    "run.span", "run.tokens.input", "run.tokens.output",
    "run.tokens.cache_read", "run.tool_calls", "run.outcome",
}

def gate(path):
    cfg = json.load(open(path))
    tel = cfg.get("telemetry") or {}
    emits = set(tel.get("emits") or [])
    missing = REQUIRED_EMITS - emits
    problems = []
    if missing:
        problems.append(f"missing telemetry: {sorted(missing)}")
    if not cfg.get("budget", {}).get("monthly_cap_usd"):
        problems.append("no monthly_cap_usd")
    if not tel.get("owner"):
        problems.append("telemetry has no named owner")
    if problems:
        print("BLOCKED by no-telemetry-no-deployment policy:")
        for p in problems:
            print(" -", p)
        sys.exit(1)
    print("gate passed:", cfg["workflow_id"])

# The owner field is the part teams skip. Cost with no owner is cost
# nobody forecasts, which is exactly the failure mode Gartner describes.

四、混合基础设施：三种环境是容量规划，不是架构图

第三条预测说，到 2029 年，80% 的大型企业会把生产 AI 负载跑在至少三种基础设施环境上，可能包括公有云、neocloud、自有数据中心和边缘。Gartner 给的原因是隐私、成本、性能和数据主权四股力量同时在推。对做落地的人来说，这句话的后果很具体：每多一种环境，就多一套身份体系、多一条出网链路、多一份监控埋点。所以正确的做法不是「哪里有 GPU 就去哪」，而是先写一份放置策略：哪类数据的负载允许出网、每月的出网预算是多少、延迟预算是多少。特别提醒一条：被归类为受限数据的负载，不应该出现在任何需要出网的环境里——这条规则写进策略比写在文档里有用得多。

# Placement policy for the hybrid reality: production AI on public cloud,
# neocloud, on-prem and edge at the same time. Write the rules down once.
placement:
  workloads:
    - name: ticket-classifier
      data_class: internal
      environments: [public_cloud, on_prem]
      egress_budget_gb_month: 50
    - name: transcript-summariser
      data_class: restricted
      environments: [on_prem]          # sovereignty: no egress
      gpu: L40S
    - name: store-inference
      data_class: public
      environments: [edge, neocloud]
      latency_budget_ms: 300

policy:
  deny_if:
    - data_class == "restricted" and environment != "on_prem"
    - egress_gb_month > egress_budget_gb_month
  cost_attribution:
    tag_keys: [workload, environment, owner]
  review: quarterly

# Three environments is a capacity plan, not an architecture diagram:
# every extra environment duplicates identity, egress and monitoring.

五、NOC 与 SOC 合流，以及 I&O 变成编排者

第四条预测给了一组很具体的数字：到 2030 年，25% 的企业会把网络运营中心（NOC）和安全运营中心（SOC）合并，2026 年是 5%；合并后工具与人员的总支出可能降低超过 25%。它的逻辑和上一波「可观测性与安全合流」是同一个：当 Agent 拿着跨栈权限，一个错误动作既是故障也是安全事件。合并在工程上其实是一个查询——把运维事件和安全事件按资产与时间对齐，找出同一个小时内两边都出现的资产，那才是值得叫人的。第五条预测更像结论：到 2030 年，没有强 I&O 牵头 AI 基础设施设计、架构与支持的组织，AI 举措失败的概率是其他组织的两倍以上。Forest 的补充是，AI 基础设施太贵，容错空间很小——所以别把 I&O 当成审批关卡，把它当成编排者。

到 2030 年，25% 的企业会把 NOC 和 SOC 合并，2026 年这个比例是 5%。

-- NOC meets SOC: one correlation view, not two dashboards.
-- Join operational signals to security signals by asset and time,
-- then rank by blast radius rather than by source system.
WITH ops AS (
  SELECT asset_id, ts, 'ops' AS source, severity, signal
  FROM ops_events
  WHERE ts > now() - INTERVAL '1 hour'
), sec AS (
  SELECT asset_id, ts + INTERVAL '0 second' AS ts, 'sec' AS source,
         severity, signal
  FROM security_events
  WHERE ts > now() - INTERVAL '1 hour'
), merged AS (
  SELECT * FROM ops UNION ALL SELECT * FROM sec
)
SELECT
  asset_id,
  count(*) FILTER (WHERE source = 'ops')            AS ops_signals,
  count(*) FILTER (WHERE source = 'sec')            AS sec_signals,
  max(severity)                                     AS top_severity,
  min(ts)                                           AS first_seen,
  max(ts)                                           AS last_seen
FROM merged
GROUP BY asset_id
HAVING count(DISTINCT source) = 2
ORDER BY max(severity) DESC, ops_signals + sec_signals DESC;

-- Assets appearing in both systems within the hour are the ones worth
-- a human. "Merged NOC and SOC" is a query before it is an org chart.