过去一年，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 次，且每次调用成功率为 99%，在各次请求相互独立的简化情况下，完整链路一次成功的概率只有约 82%。这意味着，Agent 的普及会迫使推理服务从“平均可用”走向真正的工程级高可用。
为什么国产芯片需要不同的推理引擎
推理框架是连接模型和硬件的关键中间层。目前，vLLM、SGLang 等开源框架已经成为主流选择，但这些框架最初主要围绕英伟达 GPU 的软件栈、内存体系和通信方式设计。
国产芯片厂商可以对这些框架进行移植，使模型先运行起来。但“能够运行”并不等于“能够充分发挥硬件性能”。
不同芯片在计算单元、显存层级、算子支持、指令系统、芯片互联和通信拓扑上存在差异。针对英伟达架构设计的调度和算子策略，即使能够移植到其他芯片，也可能无法取得理想的吞吐和成本表现。
师天麾将其比喻为：为烤面包设计的烤箱经过改造后也许能够蒸馒头，但与其持续改造，不如针对目标需求重新设计蒸锅。
更现实的问题是上游维护。企业如果在 vLLM 或 SGLang 基础上进行大量底层修改，后续上游版本迭代时，就需要不断处理代码冲突。继续合并新版本，可能破坏此前的硬件优化；停止跟进，又可能逐渐脱离开源生态。
因此，对于需要长期适配多种国产芯片的厂商，自研推理引擎存在一定工程合理性。不过，师天麾也强调，市场上真正具备从头研发推理引擎能力的团队并不多，因为这项工作对系统人才要求很高。
推理引擎的优化也不是只写几个高性能算子。完整系统涉及编译器、算子、缓存管理、Prefill 与 Decode 分离、专家并行、计算通信重叠、集群网络和任务调度。
如果只优化某个算子，局部性能可能提高，但系统瓶颈可能迅速转移到显存、通信或其他计算阶段。真正决定集群性价比的，是算法、系统软件和硬件之间的联合设计。
国产算力真正的机会，是把硬件变成 Token
过去，国产芯片落地面临的一个核心问题是使用门槛。
企业购买服务器后，不仅要完成模型适配，还需要解决驱动、框架、算子、通信、精度和性能调优等问题。即使芯片价格更低，如果部署周期长、稳定性不足、后续运维困难，企业仍然可能选择软件生态更成熟的产品。
推理服务正在改变这一逻辑。
当算力以 API 和 Token 的形式交付后，终端用户不再需要直接管理芯片。
国产芯片与英伟达 GPU 产生的 Token，在调用方式上可以保持一致，底层硬件适配和性能优化则由专业服务商完成。
从用户视角看，采购对象由一批服务器变成了具有明确价格、延迟和可靠性指标的模型服务。国产硬件的使用难度被封装在基础设施内部，芯片竞争也由“能不能运行模型”，逐渐转向“单位成本能够稳定生产多少有效 Token”。
师天麾表示，从其接触的项目看，2026 年以来部分国产芯片的闲置情况已经明显改善，一些新型号在较大规模集群中甚至出现供应紧张。不过，这一观察主要来自清程极智自身业务和合作范围，尚不能直接代表整个国产算力市场。
Token 化交付降低了国产芯片的使用门槛，但并不会自动解决生态问题。模型兼容性、量化精度、推理吞吐、集群通信和长期稳定性，仍然决定一款芯片能否获得持续负载。
对于国产算力而言，推理市场提供的真正机会，不是用户降低了对性能的要求，而是专业基础设施团队可以集中解决适配问题，再把底层差异封装成标准服务。
Agent 可以按结果收费，Infra 仍会像水电一样计量
随着 Agent 从辅助工具逐渐进入业务流程，行业也在讨论新的收费模式。
按照 Token 收费的优点是标准清晰，基础设施厂商只需要对模型调用和资源消耗负责。但企业真正购买 Agent，并不是为了获得更多 Token，而是为了完成代码修改、客户服务、内容审核或数据分析等具体任务。
因此，在 Agent 层按照任务完成数量或业务效果收费，可能更符合用户价值。对于服务商而言，这种模式也会形成更直接的成本优化动力：在保证结果的前提下，减少模型调用次数、缩短上下文和选择成本更低的模型，都可以提高毛利。
但在底层基础设施层，按照 Token 或计算资源计量仍可能长期存在。
师天麾将其类比为电网：基础设施负责提供稳定、价格透明的电力，但冰箱是否制冷、设计是否合理，并不由电网负责。同样，推理服务可以对 Token 的价格、延迟和可靠性负责，却很难直接保证上层 Agent 一定完成业务目标。
由此看，未来可能形成两套并行的计费逻辑：基础设施层继续按照 Token 或资源消耗收费，Agent 应用层则逐渐转向按任务、席位或结果收费。
这也对应着两层不同的责任边界。Infra 需要回答的是：模型服务是否稳定、便宜、可预测；Agent 厂商需要回答的是：最终任务是否真正完成。
结语
Agent 的快速发展并没有让 AI Infra 变得不再重要，反而暴露了推理基础设施中此前被单轮对话掩盖的问题。
当一次请求扩展为数十次调用，平均延迟会变成长链路等待，偶发失败会变成任务中断，较低的缓存命中率会演变为显著的成本差异，底层服务的轻微波动也会被 Agent 放大。
从这个角度看，Agent Infra 当前最迫切的任务，并不是构造一个全新的概念层，而是先把 Token 变成真正稳定、可评估和可规模交付的基础资源。
只有当 Agent 的应用范式、质量标准和责任边界逐渐稳定后，一套独立且通用的 Agent Infra 才可能真正成形。在此之前，行业竞争的重点仍将落在推理效率、缓存管理、服务路由、软硬件联合优化，以及单位成本能够交付多少可靠 Token 上。
大模型决定了能力的上限，而基础设施决定了这种能力能否以企业可以承受的成本，持续运行下去。
