AI 编程助手军备竞赛：基础设施准备好了吗？

Claude Code、Codex、Gemini CLI 这些工具已经被全球开发者实战测试过了。现在的问题不再是"这些工具到底行不行"，而是——怎么才能大规模部署这些东西，还不会把预算烧穿、延迟高到让开发者想把键盘砸了？

华盛顿大学 SyFI 实验室最近发了一篇论文，用真实数据告诉我们 AI 编程助手实际跑起来是什么样子。结果可能会让你重新审视自己的基础设施。

说起来容易，做起来难

编程助手和普通聊天机器人不一样，这道理说出来谁都懂，但真正做的时候很容易忘。当你让 AI 帮忙实现一个功能或者修一个 bug，你不是在发一条消息等回复——你是在启动一个自主工作流。AI 会思考、执行命令、读写文件、跑测试，反复折腾直到搞定（或者你手动打断它）。

研究团队收集了超过 4300 个真实会话，总共涉及大约 550 亿个 token。数据很有意思：平均每个用户请求会触发 8.8 次 LLM 和工具之间的来回交互。

也就是说，你问一个问题，AI 要来回折腾将近九轮才能完成。这不是单纯的问答，这是自动化流水线。

而且有个数据很关键：88% 的 LLM 推理轮次不是用户触发的，而是工具执行结果返回后触发的。AI 读完一个文件、执行一条命令，然后继续推理——这个循环占了绝大多数。

这说明什么？说明你之前针对简单对话设计的自动扩缩容、请求排队、缓存策略，可能都需要重新思考。

那个让缓存失效的数字

有个数字会让每个搞基础设施的工程师愣一下：输入和输出的比例是 294 比 1。

研究数据显示，模型读取了 525.6 亿个缓存的输入 token，预填充了 23.4 亿个新 token，但最终只生成了 1.869 亿个输出 token。平均每次交互的输入上下文在 32K 到 256K token 之间，模型只往里面加几百到几千个 token，然后生成几百个输出 token。

这和传统的 LLM 服务优化方向完全不同。大多数推理系统都在优化生成速度——每秒能吐出多少 token。但对于编程助手来说，瓶颈往往不是解码速度，而是工具执行完后、模型开始响应的首 token 延迟（TTFT）。

研究团队发现，Codex 每一步的 TTFT 大约是 3.1 秒，占整个推理周期的 25%。当你一个请求要走 9 轮的时候，这个开销累积起来就很可观了。

缓存这块也没那么简单。确实，输入缓存能帮忙处理巨大的上下文。但预填充 workload 分成两部分：缓存命中的 token 和需要真正计算的新 token。工具执行后的短增量预填充，和初始的长上下文加载，性能特征完全不一样。一套系统要同时处理好这两种情况，策略可能得不一样。

Shell 命令才是主角

你以为 AI 编程助手整天在做什么复杂的重构和深度推理？确实有，但实际情况更接地气。

在收集到的 43.3 万次工具调用中，76% 是 shell 或命令执行。跑构建、跑测试、git 操作、通过命令行操作文件——这些看起来不起眼的活儿，才是开发者日常工作的真实面貌。

文件编辑占 11%，文件读取和搜索占 9%，剩下的才是规划、子任务分发、网页查询之类的。

为什么这个分布很重要？

第一，这些操作的耗时差异极大。一个 ls 很快，但跑完整测试套件或者编译大项目可能要好几分钟。延迟分布横跨四个数量级，做容量规划头疼得很。

第二，不同助手的工具集差异不小。Claude Code 用到了 54 种工具，Codex 用了 31 种，但两者的调用量都集中在同一批核心工具上——shell、文件编辑、文件读取。这意味着如果你只优化这几个高频工具，效果可能比去搞定整个工具生态更明显。

对你的基础设施意味着什么

如果你在构建或者运营 AI 开发工具，这篇论文有几个实打实的建议：

按工作流来思考，别按请求来思考。 你的服务基础设施得适应编程助手这种自主、多步骤的特性。这意味着更长的请求上下文、更复杂的状态管理，还有批调度机会——把相关的工具调用打包到一起处理。

优化那些空闲间隙。 用户两次请求之间平均间隔 46.7 分钟，但中位数思考时间只有 1.4 分钟。分布非常偏——有些开发者飞快地迭代，有些人发个请求就去干别的了，几个小时才回来。如果能在这些空闲时间做智能预取和重新预填充，可能大幅降低用户感知的延迟，还不用多花钱加算力。

把你的预填充和解码路径分开。 294:1 的输入输出比意味着预填充计算很可能才是你的主要成本。工具执行后的增量预填充，和初始上下文加载，需要不同的优化策略。考虑用不同的资源池或者调度策略来处理这两种 workload。

别忘了工具执行的基础设施。 当 76% 的助手活动都是 shell 命令，你的容器编排、文件系统访问模式、构建工具缓存就成了 AI 助手服务的一等公民。模型推理只是整个流程的一部分。

未来怎么走

TraceLab 团队已经把他们的 trace 收集和分析工具开源了。这意味着基础设施团队可以生成自己的 trace，针对真实使用模式来优化，而不是对着合成 benchmark 调参。AI 基础设施这个领域正在从"先跑起来"往"跑得规模化"演进，这种真实数据正是行业需要的。

对于我们 NameOcean Vibe Hosting 社区来说，这些洞察也是我们持续投入基础设施的原因。服务 AI 编程助手不只是买 GPU 塞进去那么简单——你需要理解 agentic workload 的独特特性，构建能够handle 自主、多步骤、工具密集型现实的系统。

编程助手的时代才刚刚开始。我们今天做的基础设施决策，会决定这些工具未来几年服务开发者的效率。