Agent 形态一天一个样，Infra 到底该为谁而建？| 请回答 WAIC 2026

过去一年，Agent 几乎成为大模型行业最密集的关键词。从工作流编排、低代码平台，到 Coding Agent、多 Agent 协作和能够长期自主运行的智能体，应用形态不断变化。但与市场期待的“Agent 元年”相比，真正进入稳定生产环境的项目仍然有限。问题或许并不完全出在 Agent 的能力上。随着模型快速迭代，一个现实的矛盾开始出现：企业投入大量工程资源搭建的 Agent，可能在下一个模型版本发布后，就被模型新增的原生能力覆盖。应用层尚未形成稳定范式，底层基础设施却已经需要提前面对并发增长、长上下文、缓存复用、推理延迟和服务可靠性等一系列问题。7 月 18 日，在 WAIC 2026 InfoQ 媒体直播间，清程极智联合创始人师天麾提出了一个相对谨慎的判断：Agent Infra 长期看一定会变得重要，但现在还没有到真正爆发的阶段。当前 AI Infra 最确定、也最值得投入的方向，仍然是围绕每一次模型调用，提高 Token 生产和交付的效率。直播回放视频链接：https://www.infoq.cn/video/Cpw9ye57OyQNHSKpem7T模型能力越强，Agent 的投资反而越谨慎师天麾认为，Agent 的发展速度确实有些不及此前的市场预期，但原因并不只是模型能力不足。恰恰相反，模型迭代过快，也可能抑制企业和创业公司对 Agent 的长期投入。一个 Agent 往往需要经过任务拆分、提示词设计、工具接入、工作流编排、评测和异常处理等多个环节。团队投入数月完成的系统，可能在下一代模型推出后，被模型原生的推理、工具调用或代码能力部分替代。这意味着，企业需要不断判断：哪些能力应该固化在 Agent 工作流中，哪些能力未来可能直接由通用模型提供。模型升级带来的不确定性，正在提高 Agent 项目的工程折旧速度。不过，这并不意味着 Agent 会失去价值。在师天麾看来，通用模型足够强时，理论上可以替代部分专用 Agent，但 Agent 仍然具有两个现实优势：稳定和成本可控。企业可以选择规模更小的开源模型，叠加行业数据、知识库和微调，使其在特定任务上接近更大规模的通用模型，同时显著降低推理成本。因此，Agent 的价值未必来自绝对能力超过通用模型，而可能来自对特定场景的约束、稳定输出和成本控制。问题在于，当前市场尚未形成一套足够稳定、能够跨越不同应用形态的 Agent 技术范式。过去，行业关注工作流编排和低代码平台，随后又转向 Coding Agent、多 Agent 和能够自主运行的智能体。应用层持续变化，使得第三方基础设施厂商很难提前判断：未来真正通用的 Agent Infra 究竟应该建立在哪一层。对于内部工作流高度统一的大型企业，这个问题相对容易解决。企业可以要求员工统一使用一套 Agent 平台，再围绕这套确定的架构做调度、监控和成本优化。但对于需要服务多种 Agent 形态的第三方厂商而言，现在就构建一套通用基础设施，仍然存在较高风险。因此，当前所谓 Agent Infra，更多还是以传统推理基础设施的形式存在：缩短每次 API 调用的延迟，提高吞吐量和成功率，降低单次调用成本，并尽量保证长链路任务不会因为某一次请求失败而整体中断。Agent 带来的压力，最终仍然落在 Token 上在普通聊天场景中，一次模型调用可能只包含一轮输入和输出。但在 Agent 系统中，一个任务通常会被拆解成多个步骤，涉及模型规划、工具选择、联网搜索、代码执行、结果校验和多轮反思。这意味着，一个用户请求可能触发十几次甚至更多模型调用。单次调用中的轻微延迟和失败，经过长链路放大后，会直接影响任务完成率。从基础设施角度看，Agent 并没有创造一套完全不同的计算指标。真正发生变化的是这些指标的规模：一是并发量提高。多个 Agent、多个子任务可能同时运行，对集群调度和请求排队提出更高要求。二是上下文变长。Agent 需要携带历史对话、系统提示词、工具描述、代码仓库和中间执行结果，输入 Token 数量持续增加。三是调用链变长。即便单次请求成功率达到 99%，连续调用几十次后，完整任务的成功率仍可能明显下降。四是成本结构变得复杂。除了模型输出，长上下文输入、重复计算、失败重试和跨服务商切换，都可能带来额外成本。在这些问题中，缓存命中率是最容易被低估、却直接影响成本的一项指标。大模型推理通常可以拆成两个主要阶段：Prefill 和 Decode。Prefill 阶段处理用户输入，对整段上下文进行计算并生成 KV Cache；Decode 阶段则根据已有状态逐个生成输出 Token。在代码生成或多轮对话场景中，新一轮请求往往会保留前一轮的大部分内容，只新增少量代码、问题或工具结果。如果此前的 KV Cache 能够被复用，就不需要重新计算全部输入。师天麾举例称，在一些服务定价中，缓存命中部分的输入成本可能只有重新计算的约十分之一。假设多轮请求中有 80%至 90%的上下文能够命中缓存，系统可以同时降低延迟和计算成本。值得注意的是，缓存命中率从 90%下降至 80%，表面上只下降了 10 个百分点，但未命中的比例实际上从 10%增加到了 20%。由于未命中部分需要执行完整的 Prefill 计算，成本增加通常会显著高于命中率数字本身所呈现的变化。这也是为什么低价 Token 并不一定意味着更低的最终成本。如果服务商频繁超时、请求失败或无法复用缓存，企业可能需要不断重试，最终承担更高的实际费用。缓存也限制了路由策略。理论上，系统可以把请求实时发送给最空闲、价格最低的服务商，但如果同一个会话频繁切换节点或供应商，原有 KV Cache 可能无法继续复用。因此，一个成熟的多模型路由系统不能只选择“此刻最便宜”的服务，而需要同时考虑实时负载、请求成功率、模型质量和缓存亲和性。系统通常需要在一段时间内保持会话黏性，只有当服务持续退化时再切换路径。企业不能只设置 Token 上限，还要理解输入输出结构随着推理模型通过更长的思考过程换取更高准确率，企业开始尝试为任务设置 Token、时间和调用次数上限。但在师天麾看来，真正进入生产环境后，单纯设置一个统一上限并不够。不同业务的输入输出比例存在明显差异。在 Coding 场景中，模型可能需要读取大量代码、依赖关系和上下文，但最终只修改少量内容，呈现出长输入、短输出的特点。师天麾提到，部分代码任务的输入输出比例可能达到数十比一。数学推理、试卷批改等任务则可能相反：输入相对较短，但模型需要进行较长的推理和结果生成，Decode 阶段的计算压力更大。这两类任务需要不同的资源配置。如果集群采用 Prefill 与 Decode 分离架构，就需要根据业务负载决定多少机器处理输入、多少机器负责生成输出。当 Prefill 资源不足时，长输入请求会排队，即使 Decode 资源仍然空闲，也无法完成后续任务；反过来，如果 Decode 资源不足，输出会成为瓶颈，Prefill 机器同样可能被迫等待。理论上，系统可以动态调整两类资源，但动态切换本身也存在调度和状态迁移成本。对于负载相对稳定的大规模企业场景，提前了解平均输入长度、输出长度和每分钟 Token 数量，再进行静态或半动态资源规划，通常更容易获得稳定性能。这也是企业从试验转向生产必须经历的一步。在探索阶段，为避免过早限制模型能力，企业可以允许任务使用较高的 Token 上限。但当场景固定下来后，就需要明确服务等级目标，包括首 Token 延迟（TTFT）、输出速度、并发能力、超时比例和高分位延迟。例如，短输入场景可能要求首 Token 在数秒内返回；长上下文任务可以接受更高延迟，但必须给出可预测的范围。企业关心的也不只是平均延迟，而是 99.5%或 99.9%的请求能否满足约定指标。换句话说，AI 系统进入生产环境后，需要管理的不是一个模糊的“模型速度”，而是一组可以拆解和测量的工程指标。Token 还不是标准化商品当前市场通常按照模型名称和 Token 数量进行报价，容易让用户产生一种错觉：同一个模型、同样数量的 Token，在不同服务商之间是可以相互替换的。但现实并非如此。即便使用相同硬件、相同模型权重和相同推理框架，不同团队部署出的服务也可能在延迟、吞吐和模型精度上存在差异。批处理策略、并行方式、算子实现、采样参数、缓存管理和量化方式，都会影响最终结果。其中，量化是最典型的变量之一。服务商可以把原本采用 FP8 精度的模型进一步量化到 INT8 甚至 INT4，以减少显存占用和计算量，但模型精度也可能随之下降。对于用户而言，这些配置通常是不可见的。采购前最容易比较的是价格，但模型是否保持原有能力、服务是否稳定、峰值时是否排队，往往只有经过真实测试才能确认。师天麾将当前模型服务形容为一种“黑盒”：用户在测试前很难知道服务的真实水平，而个人开发者和中小企业通常又缺少系统测试能力。清程极智因此搭建了 AI Ping 评测平台，据其介绍，平台在采访时覆盖 30 多家服务商和 600 多个模型服务，持续观察延迟、吞吐和可靠性等指标。从行业角度看，这类评测至少说明了一个问题：大模型服务仍缺少被广泛接受的统一质量标准。未来，一个相对完整的 Token 服务评价体系，至少需要覆盖模型效果、首 Token 延迟、输出速度、请求成功率、P95 和 P99 延迟、缓存命中率，以及高负载情况下的性能退化程度。对于 Agent 而言，可靠性尤其重要。单轮聊天中，98%或 99%的成功率可能尚可接受；但在连续执行多步任务时，任意一次失败都可能导致整个流程重试或中断。假设一个任务需要连续调用模型 20 次，且每次