为什么你的 AI 编程助手越来越慢？Subagent 模式真的省额度吗？

最近在折腾 AI 编程辅助工具的时候，遇到了几个让人头秃的问题，相信不少朋友也在用类似的“超级能力（Superpowers）”来提升生产力吧？但是，理想很丰满，现实有时候真的很骨感。

speech_balloon

用户反馈关于 Codex 和 superpowers 使用的性能问题

特别是最近，我发现我的 Codex 在执行每一个 Plan（计划）里的 Skill（技能）时，速度简直让人抓狂。每个任务都要反复复审，好像陷入了一个死循环。结果就是，我的 Plus 会员额度根本不够烧，眼睁睁看着它被这些无效的“反复咀嚼”给耗光。

而且，最离谱的是，当我把同样的 Plan 拿到其他的 CLI 工具里跑——明明大家用的都是 Subagent-Driven（子代理驱动）模式——那边的速度快得飞起！这鲜明的对比，真的让我一度怀疑是不是我的打开方式不对。

为什么会这样？今天就来聊聊这个问题，顺便给大伙儿分享几个排查思路和解决方案。

source-image

作者头像

我们常说的 Subagent 模式，本质上就是一个大模型拆解任务，然后指挥一帮小模型（或者同一个模型的多个实例）去干活。但是，观察日志你会发现，有时候它不停地出现“Spawned”提示，也就是启动子任务。

如果你的配置不够精简，或者上下文保留过多，每 Spawn 一次，都是在消耗 Token。更糟糕的是，有些时候子任务并没有带来实质性的效率提升，反而是在做重复的验证工作。这就解释了为什么你觉得“没在提升效率，反而更慢了”。

同样的一套逻辑，为什么网页版慢如蜗牛，命令行版却快如闪电？这很大程度上得归咎于环境配置和中间层损耗。

网络与渲染损耗：Web 端不仅要传数据，还要实时渲染聊天界面、处理高亮代码、甚至做大量的 DOM 操作，这都会让操作感变得“厚重”。而 CLI 是纯粹的文本流，没有任何视觉包袱，延迟自然低。
上下文管理策略：很多网页版工具为了保证对话的连续性，会把很长的历史记录塞进上下文。一旦历史记录太长，模型处理当前任务的算力就被分散了。而 CLI 工具通常默认只关注当前指令，或者允许你更灵活地控制上下文窗口，导致推理速度飙升。
并发策略不同：有的 Web 客户端为了稳定性，故意限制了并发请求的数量，或者对子任务的调度更加保守，导致你看到的 Spawned 频率虽高，但实际吞吐量很低。

既然问题找到了，我们总不能坐以待毙。针对“执行慢、复审多、费额度”这三个痛点，我有几个亲测有效的调优建议：

1. 强制精简上下文 不要在同一个对话窗口里无休止地聊。如果一个 Task 完成了，建议开启新的 Session，或者明确告诉工具“忽略之前的上下文，仅关注当前指令”。这能大幅减少模型反复读取无关信息的开销。

2. 调整 Subagent 的并发数（如果可以配置） 如果你有权限修改配置文件，试着调整 Subagent 的最大并发数和最大迭代次数。有些默认配置是“宁可错杀一千，不可放过一个”，导致它为了一个简单的 Bug 反复验证五遍。适当降低最大迭代次数，可以让它“差不多行了”的时候就停下来。

3. 用 CLI 做重活，Web 端做交互 既然 CLI 快，那就让 CLI 干跑代码、生成脚本的脏活累活。Web 端只用来做 Code Review、查看结果或者进行简单的问答。这种“高低搭配”能最大化利用你的资源。

4. 检查 Prompt 里的模糊指令 很多时候模型慢，是因为你的 Plan 写得太含糊。比如“优化这个代码”，模型可能会尝试十种优化方案并逐一验证。如果你明确说“把这个时间复杂度从 O(n^2) 降到 O(n)”，它就能直接 targeted 地执行，少走很多弯路。

现在的 AI 工具虽然强大，但并不是把所有东西交给它就完事了。Subagent-Driven 确实是个好方向，但如果不去理解它的运作机制，很容易陷入“看起来很忙，实际上在空转”的陷阱。

下次再遇到那种“不停 Spawned”且速度奇慢的情况，不妨换个思路：是不是上下文太长了？是不是指令不够清晰？或者，干脆切到终端里去把活干完。

希望这些小技巧能帮大家省下不少算力费用，把 AI 真正用到刀刃上。