别再死磕 Token 推理速度了，减少 Agent 往返次数才是 AI 编程效率的真解

很多人在评价 AI 编程 Agent 时，习惯性地把目光锁定在模型的 Token 生成速度上，认为只要推理快了，开发效率自然就提升了。但实际上，真正拖慢节奏的往往不是单次生成的毫秒级延迟，而是那些没完没了的“往返对话”（Round Trips）。

最近我对 YC 的新项目 Bullet 进行了深度研究，这个项目的表现非常激进。在 SWE-bench Verified 的评测中，它在 500 个任务中成功解决了 479 个，而且运行速度比 mini-SWE-agent 配合 Fable 或 Sol 快了 35% 到 67%。这个数据给了我一个很强的信号：优化 Agent 的执行链路，其边际效用远高于单纯堆模型参数或追求推理速度。

目前主流的 AI 编程工具在处理上下文时逻辑过于简单，要么试图把整个仓库粗暴地塞进 Prompt，要么依赖低效的 Embedding 索引。这导致模型在处理复杂任务时，经常在大量无关的垃圾信息中打转，为了确认一个细节而产生不必要的往返确认。Bullet 的核心逻辑是将 Agent 的行为模式从“线性串行”改为“选择性并行”。

在传统的 Agent 流程中，搜索文件、读取内容、执行命令通常是串行的。这意味着每一步都要等待模型响应，确认结果后才能进行下一步。而 Bullet 将这些独立的探测行为全部并行化，只有在必须依赖前一步结果的“编辑”和“验证”阶段才走串行。这种策略直接砍掉了 16% 的往返次数，极大地压缩了任务完成的总时长。

除此之外，Bullet 在上下文管理上展现出一种近乎“强迫症”的清理能力。为了防止上下文被冗余信息淹没，它会强制限制工具的输出长度，并自动删除过期的截图，避免重复读取同一文件。在搜索机制上，它抛弃了对整个 Repo 做全量 Embedding 的做法，转而采用更高效的 grep 机制在代码和上下文中进行定向搜索。这种精准搜索比模糊的向量检索更能保证模型定位到正确的代码行。

在实操过程中，有一个极易被忽视但至关重要的细节：正则方言的匹配。Bullet 的经验表明，如果 Agent 在进行代码搜索时使用的正则表达式方言与目标环境不匹配，会导致 Agent 在潜意识中找错方向，从而陷入死胡同。这种微小的技术偏差，往往就是 Agent 表现出“一本正经地胡说八道”的根源。

为了进一步优化成本和效率，Bullet 还引入了模型路由机制。它不再盲目地为所有步骤调用最昂贵的大模型，而是将简单任务分发给像 Sonnet 这样性价比更高的模型，仅在关键决策点使用顶级模型。

对于需要长时间迭代、步骤依赖极强的任务（比如构建复杂的数据流水线或运行大规模评测循环），这种通过减少往返次数、精简上下文和优化搜索精度来提升性能的路径，比单纯追求模型单次响应的毫秒级提升要实用得多。