你构建了一个很棒的Agent，但它进入生产环境后，情况发生了变化。
在测试中，你的Agent能高效地自主评审拉取请求。它读取diff，在代码库中搜索相关用法，运行测试套件，检查CI是否仍因早先的提交而处于红色状态，并起草评论——这一切都在你读完diff之前完成。
但在生产环境中，想象同样的五个步骤，运行在团队所有Agent那一小时执行的每一次PR评审之后。有些评审几秒就完成；另一些则等了好几分钟，因为测试套件那一步落到了一个正被其他Agent的突发流量占用的节点上。
Agent没有变。变的是执行环境，而正是这个环境，决定了评审时间是保持稳定，还是慢慢爬升。
Agentic应用引入了与传统聊天应用不同的执行模式。当这些工作流变得越长、越动态，基础设施对延迟、可靠性和成本的影响，就远比一个简单聊天机器人要大得多。
这就是为什么说：你的Agent有多好，取决于你的基础设施有多好。
Agent不是“步骤更多的聊天机器人”
给聊天机器人做推理服务，和给AI Agent做推理服务，差别不在于谁“能力更强”。它们执行工作的方式就不一样：
- 聊天机器人通常对每条用户消息做一次推理调用。模型拿到提示词，生成回复，然后等下一次用户输入再继续。
- Agent则要执行整个工作流，把一条用户消息变成一串推理调用。它可能决定去搜文档、从数据库取数据、调API、执行代码、评估结果，然后重复这个过程，最后才给出答案。这其中的每一个决策，都可能触发另一次推理调用。而每一个结果，都会成为下一步的额外上下文。
“基础设施对延迟、可靠性和成本的影响，远比一个简单聊天机器人要大得多。”
这种执行模型，直接改变了AI Agent对基础设施的要求。
一个问题背后，藏着一串步骤
系统要优化的不再是单个推理请求，而是支撑长时间运行的工作流——它的延迟和可靠性，取决于链条上的每一个组件。
一次用户请求，常常会展开成一连串推理和工具执行步骤，有时被称为多轮工具调用，或者叫Agent循环。模型不是在生成一个回复，而是在推理和与外部系统交互之间来回切换。
举个例子。你问Agent：为什么结账延迟昨晚突然飙升？
Agent会去拉部署日志，查询监控系统，对连接池跑一次诊断，权衡到底是坏部署还是容量问题，然后把这些结论折叠进下一次推理调用，最后才产出一个完整的回答。
每一个推理步骤，都是一次新的推理请求。每一个工具返回的结果，都会在下个步骤前被加进模型的上下文里。
这套工作流，重新定义了“可靠性”
多轮工作流天生是串行的，所以哪怕每一步延迟都不高，累加起来也会很可观。每一个推理步骤，都要等上一步完成。如果一次数据库查询要花两秒，模型在这两秒里没法开始下一步推理。模型生成token可能很快，但其他步骤会把它拖住。
“在这个Agent工作流里，链条上的每一步都必须撑住，因为整条链的强度，取决于最慢的那一环。”
在这个Agent工作流里，链条上的每一步都必须撑住，因为整条链的强度，取决于最慢的那一环。推理栈要做的，不再是处理孤立的推理请求，而是编排一串相互依赖的模型调用和外部工具调用。工作流越长，这套栈就越决定应用跑得多快、多稳、多省钱。
但用户看不到编排打了个嗝。他们只看到一个Agent卡住了，或者干脆放弃了。
这就是为什么端到端的Agent可靠性，远不止取决于模型质量。基础设施决定了每一步在负载下，能不能拿到它需要的资源、可预测地执行。
为什么账单和性能都变得难以预测
Agentic工作流还有第二个差异，常常让团队措手不及：需求模式，以及它对推理账单的影响。
大多数推理服务，以及建立在其上的定价，都假设流量以可预测的节奏到来。典型的推理方案熟悉这种可预测的需求模式：用户流量上升，请求量上升，容量随之扩展。云基础设施通常用自动扩缩容、负载均衡、容量规划这些机制，来优化这种稳定的请求模式。
Agent工作负载不是这么表现的。单个工作流会在等待外部系统时暂停，一旦有新信息可用，又立刻恢复。
- 暂停：Agent在等外部API或数据库，服务这个工作流的GPU没有推理任务可做，而它累积的上下文，可能在等待期间被从GPU显存里驱逐出去。
- 爆发：外部系统一返回结果，推理就在许多工作流上同时恢复，制造出短暂而尖锐的GPU需求尖峰，每一个都要重新处理自己完整的累积上下文。
如果你盯着GPU利用率，发现它不像稳定负载，倒更像一次心跳——平的，然后每次工具结果回来就跳一下——那就是这个特征。它意味着你在按平均值做资源规划，而你应该按峰值来规划。这通常也是p99延迟悄悄失控的第一个地方。
“如果你盯着GPU利用率，发现它不像稳定负载，倒更像一次心跳，那就是这个特征。”
围绕稳定或可预测请求流设计的推理服务，在这些条件下可能难以高效分配资源。
热门跟贴