当 AI 编程告别「拨号上网」时代，会发生什么？

作者：Martin Alderson

人类对新技术的适应速度快得惊人，这事儿想想还挺有意思的。就在几个月前，Claude Code 和其他 AI 智能体（AI Agent）还如同魔法一般。可现在呢，用它们的感觉越来越像 90 年代末用拨号调制解调器上网了。

首先，Anthropic 公司近来一直饱受糟糕的、不稳定的、各种问题的困扰。看看 OpenRouter 的数据，他们绝不是唯一一家遇到这种情况的公司（注意：OpenRouter 的数据并非决定性的，但我相信它确实为我们提供了一个关于服务可靠性的有趣视角）。

如果你一直在用 AI 编程智能体，你就会知道它们有多么不稳定，经常卡住不动，需要反复重试。这感觉，就像天气不好时你的 56k 猫掉线，或者家里有人突然拿起电话要打一样。

这种情况其实并不奇怪。尽管一些评论员认为 AI 被过分炒作了，但 AI token 的使用量确实在爆炸式增长。虽然 AI 领域的“三巨头”（谷歌、Anthropic 和 OpenAI）没有公布官方统计数据，但 OpenRouter 公布了：

同样，我们必须非常谨慎地看待这份数据：

• 首先，相比全球市场，OpenRouter 处理的大语言模型（LLM）请求量可能只占极小一部分，这意味着这些统计数据可能会扭曲真实趋势。

• 其次，Grok（尤其）正在通过 OpenRouter 向市场“倾销”大量免费的 LLM token，以获取模型反馈，这可能也影响了这些统计数据的准确性。

我们只能通过 OpenRouter 这个小小的窗口来窥探软件开发领域的这场革命性巨变，这本身就说明了很多问题。谷歌、Anthropic 和 OpenAI 像保守国家机密一样守护着它们的使用数据。我们唯一能看到的一点线索就来自 OpenRouter，它处理的流量可能还不到全球 LLM 流量的 1%，但即便是这个微小的样本，也显示出了 50 倍的增长。

考虑到 AI 智能体编程工作流消耗的 token 数量，可能比非智能体的“聊天”或大多数 API 调用要多出大约 1000 倍，所以看到如此巨大的增长也就不足为奇了。

这无疑给幕后的基础设施带来了巨大的压力，让我想起了宽带刚刚普及的那些日子，当时的互联网服务提供商（ISP）在高峰时段处理网络互联负载时也是焦头烂额。

只要 token 输出速度够快就行了？

更有趣的是大语言模型的运行速度。目前，最前沿的模型的运行速度大概在每秒 30-60 个 token（tok/s）之间。至少对我来说，当我在全监督模式下使用 Claude Code 时，这个速度慢得令人抓狂。

我试过同时运行多个 Claude Code 实例，但没成功——至少对我来说，一旦超过两个实例，涉及到的上下文切换 (context switching) 强度就太大了。我摸索出的一个可行工作流是：让一个智能体处于“规划模式”来计划下一个任务，同时我自己在“监督模式”下处理另一个任务。但即便是这样也有缺点，因为规划中的任务会随着我的修改而过时。

我最近在试用 Cerebras Code，它（曾经）是 Gemini CLI 的一个分支，生成 token 的速度快了 20-50 倍（这个速度提升，和从拨号上网到第一代 ADSL/光缆调制解调器的飞跃非常相似）。

当速度达到 2000 tok/s 时，瓶颈很快就变成了你自己。代码生成得太快，快到你忍不住想全盘接受，结果往往一塌糊涂。目前，Gemini CLI 在上下文管理等方面给我的感觉仍然远远落后于 Claude Code，所以它并没有带来我所期望的飞跃，但确实让我瞥见了未来的一角。

不过，它也让我开始思考，超高的 tok/s 速度究竟能带来什么。但在此之前，请允许我先解释一下我是如何看待大语言模型在软件工程领域的几个发展里程碑的。

我们在 AI 编程智能体之旅的哪一站？

从专业角度看，我使用大语言模型进行软件开发的旅程迄今为止主要经历了三个阶段：

• GPT-3.5 时代： 偶尔问个问题，但只要问题稍微复杂点，通常就会得到一个一本正经的胡说八道般的答案。那时感觉，我们现在所处的阶段遥远得不可思议。

• GPT-4 / Sonnet 3.5 时代： 回答的质量大幅提升，它成了一个不可或缺的助手，可以用来提问和编写小段代码。我似乎一直不太习惯在 IDE 里用编程助手，所以大部分时间都是在 IDE 和聊天界面之间来回复制粘贴。

• 监督式命令行智能体： 我们现在就处于这个阶段。我的大部分开发工作都有一个 AI 编程智能体辅助，并且所有输出都由我亲自监督。

我认为，下一个时代可能很快就会由更高 tok/s 的基础设施开启，那将是一种更偏向无监督的模式。或许，智能体会对一个任务并行尝试 5-10 次，然后进行一些（半）自动化的评估，把“最佳方案”呈现给你，你再从这个基础上开始迭代。

这确实和我自己以无监督模式运行智能体的经验相符——有时候它能搞定，但大多数时候不行，还不如从头再来。而在监督模式下运行，你就可以及时阻止它“跑偏”。

你可能会问，为什么我们现在不能用慢一点的模型来做这件事呢？虽然理论上当然可以，但我认为，从开发者体验的角度来说，为了几个选项而等待 1 到 10 分钟，太破坏开发节奏了。如果我们能以 2000 tok/s 的速度运行，基本上就可以用和现在差不多的工作流速度，完成复杂程度高一个数量级的任务。

无限的需求循环

我们正陷入一个潜在的无限需求循环，这让传统的基础设施扩容模式相形见绌。每当我们改进大语言模型时，我们不只是更高效地使用它——我们从根本上改变了工作方式，而这些新方式会消耗掉高出一个数量级的资源。

媒体上的很多论调都预计，AI 领域会重演 21 世纪初的电信泡沫破裂——当时网络容量的建设速度远远超过了消耗速度（近年来，宽带带宽消耗几乎已停滞，在许多市场每年仅增长 10-15%）。虽然我不排除数据中心建设可能会有所回落，但我看不出 AI 的基础需求曲线会像当年那样趋于平缓。

然而，也正是在这一点上，我那个 ISP 的类比不成立了。半导体工艺的进步在过去几年里确实停滞了（不像网络容量的增长速度远超需求）。这就导致了效率提升有限，并为算力的供给设置了一个“上限”。

收费模式

我猜，这将导致面向开发者的定价模型变得不再那么友好，目前的定价模型还非常“粗放”。虽然我不认为推理 (inference) 是一个巨大的亏本项目，但服务提供商在“高峰时段”显然面临着巨大挑战。这些时段通常是美国市场和欧洲市场工作时间的重叠期。

在这些时段之外，肯定有巨大的闲置算力。我认为我们将会看到“错峰”套餐的出现，允许用户在非高峰时段以更低的成本消耗更多资源。虽然 OpenAI 和 Anthropic 为批量处理提供了折扣价，但这和我们说的不太一样，因为它不适合交互式的智能体工作流。我还怀疑，我们会看到其他定价模式的“创新”，试图将全天的需求拉平。

底线

大语言模型发展的每一个“阶段”，都在为那些懂得如何利用它的团队和开发者解锁更多的生产力。我认为软件工程师的工作方式即将迎来巨变，而许多开发者和团队对此毫无准备。

我的建议是，一定要紧跟所有新进展，并尽可能保持好奇心。我自己就吃过这方面的亏：我曾一度完全否定 Claude Code，认为它是个死胡同，直到我花了好几个小时认真尝试后，才意识到它比我见过的其他许多方法都要强大得多。

我不认为我们正处在一个很快会趋于稳定的过渡期。感觉在工具层面上，改进 AI 智能体还有太多唾手可得的成果可以采撷，更不用说有了速度更快的模型后，一切皆有可能。

根据我的经验，最能驾驭这种变化的开发者，往往是那些经验更丰富的人。然而，矛盾的是，也正是这群人，常常对新技术最不屑一顾。

原文链接：https://martinalderson.com/posts/what-happens-when-coding-agents-stop-feeling-like-dialup/