WAIC 2026 逛完，我发现一个问题：都在讲 Agent，没人讲它跑在什么上面

7月17-20日，WAIC 2026 在上海举办。AI Agent 第一次独立设峰会，132 家参展主体覆盖 17 个细分方向。阿里云喊出"Agentic Cloud"，腾讯推"即装即用"的智能体工具集。信号很明确：Agent 正在从 demo 走向生产。

但翻遍各路论坛议程，你会发现一件诡异的事——

所有人都在讲 Agent 能做什么。几乎没有人讲 Agent 跑在生产环境需要什么。

这就像大家都在讨论房子装修得多漂亮，没人关心地基是不是打在沙子上。

这篇文章想补上这个缺口。我会从 K8s 运维的视角，拆开 Agent 工作负载的三个本质特征，然后给出 GPU 调度、可观测性、长时运行三个层面的具体工程挑战和当前可行的解法。

Agent 不是微服务——用微服务的思路部署它，你会后悔

过去几年，我们在 K8s 上部署的都是"短生命周期、无状态、请求-响应"型工作负载。一个 API 请求进来，几百毫秒处理完，返回结果。Pod 挂了就挂了，拉一个新的顶上，毫发无损。

Agent 完全不同。

一个 Agent 任务的生命周期是这样的：接收用户指令 → 调用 LLM 生成计划 → 调用外部 API 获取数据 → 再调 LLM 分析 → 执行工具操作 → 再调 LLM 验证结果 → 返回最终答案。整个过程可能持续几十秒到几分钟，中间夹杂多次 LLM 调用和工具调用。

这不是微服务，这是一个有状态的、长时运行的工作流。

具体来说，Agent 有三个特征会让传统的 K8s 部署模式直接抓瞎：

1. 资源消耗是非确定性的

传统微服务的资源消耗大致可预测——每个请求吃多少 CPU、内存基本稳定，你可以比较准确地设置 resources.request/limit。

Agent 不一样：一次简单问答可能只调一次 LLM，消耗几百 token；但一次复杂任务可能触发十几次 LLM 调用 + 多次工具执行，GPU 显存、网络 I/O、内存都会突发性飙升。

这意味着什么：你没法用一个固定的 request/limit 把 Agent 框住。设低了 → OOMKilled。设高了 → GPU 闲置，成本爆炸。

2. 有状态，且状态跨调用

Agent 需要维护对话上下文、任务进度、工具使用历史。这些状态可能存在于内存、Redis 或向量数据库里。

Pod 被驱逐或重启，不是简单拉起一个新的就完事——上下文丢了，用户的体验就断了。

这意味着什么：Agent Pod 不能像无状态 Pod 一样"随便杀"。你需要优雅退出 + 状态外存 + 新 Pod 恢复上下文的能力。

3. 多步调用链，延迟分布极不均匀

一次 Agent 任务里，可能有 3 秒的 LLM 推理、200ms 的工具调用、5 秒的数据库查询。传统监控看"请求延迟 P99"毫无意义——瓶颈可能在任意一环，而且每次任务的瓶颈都不一样。

这意味着什么：你需要追踪的不是"这个请求花了多久"，而是"每一步花了多久、消耗了多少 token、哪个环节最慢"。

K8s 层面的三个实际挑战

挑战一：GPU 调度——一张卡上到底跑几个 Agent？

WAIC 2026 上最明显的趋势是"算细账"。企业不再比拼模型参数量，开始关心 GPU 利用率和推理成本。有篇文章标题说得好：AI 从"秀肌肉"进入"算细账"的时代。

但"算细账"的前提是 GPU 能被有效共享。目前 K8s 上的 GPU 调度，默认还是"一个 Pod 独占一张卡"。这在几年前大模型推理场景下勉强能接受——一张卡跑一个模型实例。但 Agent 时代不行了。

一个 Agent 服务可能同时处理几十个会话，每个会话的 LLM 调用是间歇性的——调一次 LLM，等几秒，再调一次。GPU 大部分时间在等。独占整张卡？成本根本扛不住。

目前 K8s 上的 GPU 共享有三种方案：

我的建议：生产环境优先选 MIG，按业务等级分区。高优先级 Agent 独占一个 MIG 实例，低优先级的共享 Time-Slicing。没有完美方案，只有取舍。

对于训练和批量推理任务，还需要队列调度。Kubernetes 原生调度器不支持 gang scheduling（成组调度），而分布式训练要求所有 Pod 同时就绪才能启动。这个 gap 目前由 Kueue（Kubernetes SIG 官方项目）或 Volcano来填。Kueue 1.3 已支持 JobSet，CoreWeave、Google GKE 都在生产环境用它管理 GPU 训练队列。

挑战二：Agent 调用链的可观测性——传统 APM 彻底不够用

这是 WAIC 完全没提、但实际部署时第一个撞上的问题。

传统 APM（SkyWalking、Jaeger）追踪的是 HTTP/gRPC 调用链。但 Agent 的调用链长这样：

用户请求
 └─ Agent 编排器
     ├─ LLM 调用 #1（2.3s, 1,200 tokens）
     ├─ 工具调用：搜索 API（0.8s）
     ├─ LLM 调用 #2（3.1s, 800 tokens）
     ├─ 工具调用：数据库查询（0.2s）
     └─ LLM 调用 #3（1.5s, 400 tokens）

你要追踪的不是 HTTP status code，而是：每次 LLM 调用的 token 吞吐、推理延迟、GPU 显存占用、prompt/completion 内容、工具调用的成功率和耗时。这些信息传统 APM 完全不采集。

好消息是 OpenTelemetry 已经在填这个坑。OTel 的 GenAI Semantic Conventions项目正在定义 LLM 调用的标准遥测字段——gen_ai.usage.input_tokens、gen_ai.usage.output_tokens、gen_ai.request.model等。MLflow 也提供了 OTel 兼容的 LLM Tracing 能力。

坏消息是，这套标准还在快速迭代，生产落地需要自己补胶水代码。

如果你现在就要做，第一步是这三件事：

1. 在 Agent 编排层（LangGraph / CrewAI / 自研）埋 OTel span，把每次 LLM 调用和工具调用作为子 span 上报
2. 后端对接支持 LLM 指标的系统（MLflow Tracing 或自建 OTel Collector + 时序库）
3. GPU 层面跑 NVIDIA DCGM Exporter，把显存利用率、SM 占用率拉进 Prometheus，和 LLM 调用链关联

目前没有一个开箱即用的方案把这三层串起来。做 K8s 可观测性的团队，这里有大把活可以干。

挑战三：长时运行与连接保持——基础设施的默认假设全是错的

Agent 任务动辄几十秒甚至几分钟，这超出了很多基础设施的默认超时设置。三个最容易被忽略的地方：

网关层（最常见，先改这个）：

很多 API 网关默认 30 秒超时。Agent 任务超过 30 秒 → 网关返回 504 → 但 Agent 还在后台跑。用户看到报错，Agent 侧却执行了一半——这种"幽灵执行"非常难排查。

改法：网关超时调到 300 秒，同时用 SSE（Server-Sent Events）流式返回中间步骤，让用户知道 Agent 还在跑，不是卡死了。

K8s 层：

Pod 滚动更新时，K8s 发 SIGTERM，默认 30 秒 grace period 后 SIGKILL。你的 Agent 正在执行多步任务，30 秒可能不够完成当前步骤并保存上下文。

改法：terminationGracePeriodSeconds调到 120-300 秒，配合 preStop hook 把当前任务状态写到 Redis/数据库，新 Pod 启动时恢复。

HPA 层（最容易踩坑）：

HPA 基于 CPU/QPS 扩缩容。但 Agent 的 QPS 可能很低（同时只有几个会话），CPU 也不高（大部分时间在等 LLM 返回）。HPA 看到的指标全是"闲"，缩容时杀掉一个"看起来很闲"的 Pod，里面可能正跑着一个 5 分钟的复杂任务。

改法：不用 HPA，用 KEDA。基于活跃会话数或任务队列深度做伸缩，而不是 CPU。

现在该关注什么：一份务实的工具链清单

按"你应该先装哪个"排序，不是按名气排序：

第一优先级：推理服务（先让 Agent 跑起来）

• KServe + vLLM：KServe 定义了 LLMInferenceService CRD，vLLM 提供高吞吐推理引擎。2026 年 4 月已验证 72B 模型在 8×GPU 上达 83 tok/s 单请求、11470 tok/s 峰值吞吐。这是目前 K8s 上部署 LLM 最成熟的组合。
• vLLM Production Stack：vLLM 官方的生产部署参考，多副本负载均衡。

第二优先级：GPU 调度（让 GPU 别闲着）

• NVIDIA GPU Operator + MIG 配置：先装 GPU Operator，再按业务等级配置 MIG 分区策略。
• Kueue：管理训练/批量推理的 GPU 队列。Kubernetes SIG 官方项目，Red Hat 已有商业支持。

第三优先级：可观测性（出问题能找到原因）

• NVIDIA DCGM Exporter：GPU 指标的 Prometheus exporter，采集显存、SM 占用、功耗。这个最简单，装完就有数据。
• OpenTelemetry GenAI Semantic Conventions：LLM 遥测规范，在 Agent 代码里埋点。地基性质的东西，越早用越好。
• MLflow Tracing：OTel 兼容的 LLM 调用追踪，适合开发阶段调试。

第四优先级：弹性伸缩（让 Agent 扛住流量波动）

• KEDA：事件驱动伸缩，基于队列长度、活跃会话数扩缩容。Agent 场景下比 HPA 合理得多。

写在最后

WAIC 2026 让我看到一件事：AI 行业正在从"模型竞赛"转向"工程化落地"。而工程化落地的核心，从来不是模型本身，是基础设施。

大会讲的全是 AI 的上层建筑——Agent 应用、大模型、具身智能、行业落地。但支撑这些建筑的地基——调度、网络、存储、可观测性——几乎无人提及。

这不是冷落，这是机会。

---