一、问题的提出
当前AI编程工具（Claude Code、Cursor、Copilot Workspace等）普遍采用单Agent架构：一个强模型从头到尾完成所有步骤——读文件、理解代码、修改、测试、纠错。
这种架构对用户而言简单易用，但存在一个被广泛忽视的问题：token效率极低。
本文从商业模式与用户利益的错位角度，分析这一问题的根源，并提出更优的架构方向。
二、单Agent架构的token消耗问题
以一个典型的"修bug"任务为例：
手动操作流程：
- 读相关文件（1次调用）
- 修改代码（1次调用）
- 跑测试验证（1次调用）
总计：3次调用
单Agent自动流程：
- 扫描项目结构，读数十个文件"理解上下文"（10-20次调用）
- 定位相关代码，生成修改方案（3-5次调用）
- 执行修改，跑测试（3-5次调用）
- 测试失败，自动分析原因，重新修改（10-20次调用）
总计：30-50次调用
结果相同，token消耗差10倍。用户感知到的只是"我说了一句话，bug修好了"，感知不到的是后台50次API调用带来的成本。
三、商业模式与用户利益的结构性错位
按token收费是当前模型服务商的主流商业模式。这一模式天然存在一个倾向：用户消耗的token越多，服务商收入越高。
这种利益结构不需要服务商做任何"恶意"行为，就会自然产生以下现象：
3.1 工具设计的默认路径是高消耗路径
Claude Code默认全流程使用Opus模型。Cursor默认使用Claude Sonnet。没有任何主流工具默认询问"这个步骤是否需要使用最强模型"。
这不是疏忽。工具的设计者和服务商的利益一致——让用户使用更多token。而用户的利益是——用最少的token完成任务。这两个方向天然错位。
3.2 "最佳实践"的隐性成本
服务商文档中推荐的Prompt Engineering技巧——思维链、多视角分析、分步推理——确实能提升效果，但每一项技巧都伴随着token消耗的成倍增长：
| 技巧 | 效果提升 | token消耗增幅 |
|---|---|---|
| 思维链（CoT） | 推理准确率提升 | 输出token ×3-5 |
| 多视角分析 | 分析全面性提升 | 调用次数 ×3 |
| 规划-执行分离 | 任务完成率提升 | 调用次数 ×5 |
从80分优化到90分，可能需要10倍的token消耗。这个边际成本是否合理，服务商不会替用户计算。
3.3 微调路线的系统性缺位
对重复性任务，微调（Fine-tuning）是ROI远高于持续API调用的方案：前期投入略高（数据准备+租显卡），但边际成本趋近于零。
然而，微调路线在服务商的推荐体系中几乎不可见。原因很简单：微调后的用户不再频繁调用API，从"持续付费客户"变为"一次性付费后离场"。
3.4 套餐包装的信息不对称
服务商按token计费，却常用"调用次数"包装套餐。一次调用可以是100个token，也可以是10000个token。用户以为90000次很多，实际上长上下文调用可能消耗远超预期的token量。
四、更优架构：多模型分工 + 验证闭环
单Agent架构的token效率天花板很低，因为所有步骤都使用同一强模型，包括大量不需要强模型能力的机械性工作。
更合理的架构是按任务难度分配模型：
| 角色 | 模型要求 | 成本 | 占比 |
|---|---|---|---|
| 规划（理解需求、拆任务） | 强模型 | 付费 | ~20% |
| 执行（按指令改代码） | 中等模型 | 本地/免费 | ~50% |
| 验证（跑测试、检查diff） | 轻量模型 | 本地/免费 | ~20% |
| 审查（最终质量把关） | 强模型 | 付费 | ~10% |
强模型只处理需要强模型能力的20%工作，剩余80%由本地模型免费完成。同一任务，token成本降至单Agent方案的20%。
验证闭环
这不是单向流水线，而是一个闭环纠错机制：
- V通过 → 进入Review
- V失败 → 自动回滚改动（
git reset），回到P重新规划 - V发现跨文件关联 → 补充任务给P
- 3轮不收敛 → 暂停，人工介入
关键：V失败不回E（同一个脑子反复撞墙），而是回P（换视角重新规划）。3轮换视角纠错 > 10轮同视角循环。
实测数据
用上述架构（PERF + Aider）跑10个游戏开发任务：
| 任务 | 用时 | 模型 | Token成本 |
|---|---|---|---|
| Minesweeper | 2min | 本地Gemma4-26B | 免费 |
| Flappy Bird | 3min | 本地Gemma4-26B | 免费 |
| Asteroids | 3min | 本地Gemma4-26B | 免费 |
| Invaders | 4min | 本地Gemma4-26B | 免费 |
| 2048 | 19min | 本地Gemma4-26B | 免费 |
| Pong | 27min | 混合 | — |
| Snake | 61min | 云端API（配置错误） | 29.7K |
| Tetris | 62min | 云端API（配置错误） | 31.2K |
| Pac-Man | 66min | 云端API（配置错误） | 42.9K |
| Breakout | 67min | 云端API（配置错误） | — |
本地模型2-4分钟完成，云端模型60-67分钟。速度差15-20倍，成本差：免费 vs 付费。
注：Snake到Breakout这批误用了云端模型（E阶段配置错误），不是架构设计如此。但恰好证明了一个观点：同一架构、同一任务复杂度，仅模型选择不同，成本差15-20倍。
总成本对比：
| 方案 | 云端Token | 估算成本 | 耗时 |
|---|---|---|---|
| 全Claude Code（估算） | ~500K | ~$15-20 | ~3-5hr |
| PERF：云端P + 本地E/V | ~50K（仅P阶段） | ~$1-2 | ~1.5hr |
| PERF：全本地（免费API） | 0 | $0 | ~1.5hr |
代码质量80%正常，写入成功率90%。云端token消耗降至单Agent方案的~10%。
五、建议
对用户：
- 将AI视为函数而非对话者——定义清晰的输入输出，减少反复试错的调用循环
- 重复性任务优先考虑微调，而非持续API调用
- 评估工具时关注token效率，而非仅看功能完整性
- 对"最佳实践"保持成本意识：效果提升是否值得对应的token增幅
对工具开发者：
- 默认采用token效率最高的执行路径，而非token消耗最多的路径
- 提供token消耗的透明度——让用户知道每一步花了多少
- 支持多模型分工架构，允许用户为不同步骤选择不同模型
对行业：
- 套餐定价应基于token而非调用次数，消除信息不对称
- 鼓励而非抑制微调等降低长期依赖的路线
- 建立token效率的行业标准评测，如同能效标识
六、结论
当前AI编程工具的token效率问题，不是技术能力的不足，而是商业模式的必然结果。按token收费的模式下，服务商的利益与用户的利益存在结构性错位——服务商希望用户用得更多，用户希望用更少token解决同样的问题。
解决这一错位，不需要对抗，只需要清醒：理解工具设计背后的商业逻辑，选择token效率最高的路径，把AI当作解决问题的函数而非消耗token的对话者。
90000次API够不够用？取决于你走哪条路。
