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 机器同样可能被迫等待。 理论上，系统可以动态调整两类资源，但动态切换本身也存在调度和状态迁移成本。对于负载相对稳定的大规模企业场景，提前了解平均输入长度、输出长度和每