83% 的企业必须为 Agentic AI 重建基础设施：解读 Google Cloud 2026 报告

Google Cloud 第二份年度《Agentic AI 时代基础设施状况》报告，以一个应当让你重排路线图的数字开场：83% 的组织表示需要升级基础设施，才能支撑生产级 Agentic AI。这个结论来自对 1400 多名资深 IT 负责人的调研，反映的是一次真实的架构迁移。企业 AI 已从「会回答」的聊天，转向「会行动」的 Agent。会规划、会调用工具、会执行多步任务的 Agent，给基础设施带来的是对话式系统从未有过的压力。本文讲清报告发现了什么，以及如何据此做工程。

旧基础设施是为聊天而建

一、Agent 为何压垮聊天时代的基础设施

报告的核心论断是：昨日的基础设施不是为自主行动的 Agent 而建。一次对话式请求短小、无状态、容错高。一次 Agent 提示恰好相反：单个提示可以触发数百个下游动作，每一个都在内存中持有庞大的上下文窗口，同时跨工具与系统推理。报告把生产级 Agent 工作负载描述为「持久且有状态」，而这恰恰是「请求之间缩到零」的传统自动扩缩部署最不擅长的。代码示例 1 展示了修正后的默认姿势：把 Agent 工作进程当作长生命周期的有状态服务，配一个热池与共享上下文存储。

# agent-worker.yaml — agents are persistent services, not one-shot jobs
apiVersion: apps/v1
kind: Deployment
metadata:
  name: support-agent
spec:
  replicas: 4                       # a warm pool, not cold starts
  template:
    spec:
      containers:
        - name: agent
          resources:
            requests: { cpu: "2", memory: "8Gi" }
            limits:   { cpu: "4", memory: "16Gi" }
          env:
            - name: CONTEXT_STORE
              value: "redis://context-cache:6379"
            - name: SESSION_MODE
              value: "persistent"   # keep long-lived agent state warm
# A single agentic prompt can fan out into hundreds of downstream
# actions, so treat workers as long-lived and stateful.

二、逃离「推理税」

Google 的调研点名了一个具体的成本问题：62% 的负责人表示存在显著的推理税，由数据出网费用、存储膨胀与闲置的专用硬件驱动。与此同时，81% 把运维复杂度列为扩展 AI 的隐性成本。这些不是模型成本，而是架构成本，也是最可修复的部分。代码示例 2 在保住有用上下文的同时砍掉持有它的花费，用提示缓存加克制的裁剪，让 20 万 token 的窗口成为上限而非默认。代码示例 3 则从源头打击这笔税——让计算与数据同址，因为每一个跨区域的字节，都是你被收两次费的字节。

// context-budget.ts — hold the right context without paying for all of it
const WINDOW = 200_000;              // tokens the model accepts
const HEADROOM = 24_000;             // reserve for tool results + output
type Turn = { role: "user" | "assistant" | "tool"; text: string };

export function trim(history: Turn[]) {
  let budget = WINDOW - HEADROOM;
  const kept: Turn[] = [];
  for (const turn of [...history].reverse()) {
    budget -= Math.ceil(turn.text.length / 4);
    if (budget < 0) break;
    kept.push(turn);
  }
  return kept.reverse();
}
// Google's report calls out massive context windows held in memory.
// Prompt caching plus trimming is how you pay for the useful part only.

三、让芯片与任务匹配

报告对成本压力的答案是「流式计算（fluid compute）」：把合适的芯片动态匹配给合适的任务，而不是把所有东西都跑在同一种加速器上。重训练受益于极致规模；低延迟推理受益于为最大化片上内存而专门设计的加速器，让 Agent 能实时思考与反应；而通用 CPU 正在成为编排与控制逻辑的关键组件。对平台团队而言，教训不是多买最大的 GPU，而是把训练、推理与编排拆开，各给所需硬件。

# egress-policy.yaml — keep compute and data in the same place
policy: co_locate
rules:
  - store_agent_state: "same_region_as_compute"
  - dataset_reads:
      path: "gs://analytics/*"
      prefer: "same_zone"
  - model_calls:
      cache: "shared_prompt_cache"
      max_retries: 2
cost_guards:
  alert_on_egress_usd_per_day: 250
  block_on_monthly_egress_over: 5000
# 62% of leaders report an inference tax driven by data egress fees,
# storage bloat, and idle specialized hardware. Co-location attacks all three.

四、按积压扩缩，而不是按均值

Agent 工作负载的突发性，会让朴素的自动扩缩失效。平均 CPU 利用率这类指标看起来很平静，而 Agent 任务队列已经在堆积；一个会在请求之间缩到零的集群，会把每次冷启动都变成一次丢失的任务。代码示例 4 按 Agent 队列深度扩缩，保留非零下限，并用稳定窗口放慢缩容，避免把长时间运行的会话中途杀掉。报告把这称作需要「有韧性、可流动的基础」，落到实践上就是：你的扩缩器必须理解任务，而不只是理解 CPU。

# autoscale.yaml — agent fan-out is bursty, not steady
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: support-agent-scaler
spec:
  minReplicaCount: 2            # never drop to zero; cold starts hurt agents
  maxReplicaCount: 40
  triggers:
    - type: prometheus
      metadata:
        query: sum(agent_queue_depth{app="support-agent"})
        threshold: "20"          # ~20 queued agent tasks per replica
  advanced:
    horizontalPodAutoscalerConfig:
      behavior:
        scaleDown:
          stabilizationWindowSeconds: 600   # avoid thrashing long sessions
# One prompt can trigger hundreds of downstream actions; scale on
# backlog, and scale down slowly so in-flight agent sessions finish.

五、让隐性成本可见

你无法优化一个从未被度量的推理税。代码示例 5 把闲置加速器支出与出网量做成每周看板，并与「每任务 token 数」并列，让两处最容易修复的成本泄漏，暴露在拥有 Agent 的同一个团队眼前。这正是报告那 81% 运维复杂度结论从抱怨变成工程任务的地方。一旦闲置支出与出网量和 Agent 吞吐量画在同一张图上，「同址部署」与「热池」就不再是架构品味之争，而变成了算术。

-- inference-tax.sql — turn idle spend and egress into a dashboard
SELECT
  date_trunc('week', ts)                                        AS week,
  SUM(CASE WHEN status='idle' THEN cost_usd END)                AS idle_accel_usd,
  SUM(egress_bytes)/1e9                                         AS egress_gb,
  SUM(egress_cost_usd)                                          AS egress_usd,
  SUM(tokens_in)/NULLIF(SUM(tasks),0)                           AS in_per_task
FROM agent_usage
GROUP BY 1
ORDER BY 1 DESC;
-- 81% of leaders call operational complexity a hidden cost.
-- Make it visible: idle accelerators and egress are the two you can fix
-- fastest with co-location and a warm pool.

六、先做什么

如果那个 83% 描述的就是你，顺序很清楚。把 Agent 工作进程从「缩到零」迁到有状态的热池，并配共享上下文存储。在每一次长上下文调用前放上提示缓存与裁剪。让计算与数据同址，并在财务团队之前对出网告警。把训练、推理与编排拆开，各跑在合适的芯片上。最后，为闲置支出与出网做度量，让这笔税可见。报告传达的不是「Agentic AI 太贵」，而是「聊天时代的基础设施有一个功能上限」，而在 2026 年越过这个上限的团队，将是那些真正把 Agent 送上生产的团队。