周五下午 4:50，数据团队的某人启动了一次评估扫描（eval sweep）：针对公司的共享模型部署运行四万个提示词，计划在周末完成。下午 5:10，面向客户的聊天助手开始超时。值班工程师盯着仪表盘看了两个小时，显示服务商返回了 429 错误，直到有人想起问一句还有谁在使用该账号。没有任何东西损坏。系统正完全按照配置运行，也就是说什么也没做，因为没人配置它去做任何事。
这是一种新型故障的雏形，它具有一个比普通停机更棘手的特性：没有需要修复的 Bug。评估扫描是正当的工作。聊天助手的流量也是正当的工作。失败之处在于，两个具有不同紧急程度的团队从一个无差别的推理算力池中提取资源，而该池子对谁更重要没有任何判断。当你的公司有多个团队同时使用同一个服务商账号时，容量分配就不再仅仅是基础设施的细节——它变成了一个政治问题，而传呼机（pager）继承了这一麻烦。
15 年前，我们学会了畏惧 N+1 查询：一个在代码审查中看起来人畜无害的 ORM，会针对列表发起一次查询，然后为每一行数据再发起一次查询。一个本该只需要两次数据库调用的页面，最终却发起了两百次。我们通过预加载 (eager loading)、批处理 (batching) 和一代又一代的 Linter 解决了这个问题。然而，现在我们构建了 AI Agent，却在昂贵得多的层级上重犯了同样的错误。
一个单一的 Agent 任务——比如“核对这些发票”或“处理此故障”——通常会进行几十次串行的工具调用。每一次调用都是一次完整的网络往返：从 Agent 到工具，从工具到数据存储，数据返回工具，结果序列化到模型的上下文中，再进行一次推理以决定下一步操作。如果你的推理运行在一个云端，而数据存在于另一个云端，那么每一次跳转都会跨越一个计费且高延迟的边界。此时，Agent 系统成本的主要项不再是模型，而是地理位置。
没有人把这笔账算清楚。延迟预算是按次调用的，出网流量 (Egress) 只是存储账单中的舍入误差，而模型发票则受到了所有的关注。与此同时，工具循环悄然成为了你的基础设施所服务的通信最频繁 (chattiest) 的客户端。
Hadoop 时代的一代人彻底学会了一个教训，以至于它成了一种本能：移动数据是昂贵的，所以要把计算移动到数据所在的地方。每一个 MapReduce 调度器、每一个 HDFS 块放置决策、每一个“数据本地化”（data locality）仪表盘的存在都是为了服务于这一原则。然后，在托管模型 API 的兴起和智能体（agent）热潮之间的某个时刻，我们悄然颠倒了这一原则——而且没有人重新评估这一决策的成本。
看看现代智能体循环（agent loop）实际上在做什么。它从向量数据库中检索一堆文档，从对象存储中提取代码库快照，从六个内部服务中收集工具执行结果，将所有这些内容拼接进一个上下文窗口，然后将整个负载发送到通常位于不同 VPC、不同区域、甚至不同云平台的模型端点。然后在下一轮对话中重复这一过程。周而复始。你的上下文具有质量，而你正在为每一次跳转支付运费。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
