致歉信里的一句话
10 月 25 日，Kimi 发布致歉信，承认会员使用 K3.1 Pro 时出现“限流及不必要的额度消耗”，并写道：“问题出在我们，我们也本应更早修复。”补偿方式是为所有档位的订阅会员重置一次额度：每位有效期内的会员获得月度总额的 25%，Kimi 称这相当于一周的用量；当前用量不足 25% 的，直接归零。
致歉信的末尾提到了一项技术调整：“我们已调整配置，并正在减少不必要的子 Agent 调用和输出长度，让同样的额度完成更多实际任务。”路透社的报道也转述了这句话，并解释说，子 Agent 调用是指任务在多个 AI 智能体之间的分派。
方向相同的改动，在致歉信发出之前已经出现在 Kimi Code 的公开代码仓库里。K3.1 Pro 于 10 月 23 日上线。不到两天，Kimi Code 仓库合并的几个 PR，把“开不开子智能体”这个决定从模型手里拿走，交给了用户。
致歉前一天的 PR
第一个 PR 是 #4382，提交于 10 月 24 日 18:05 UTC，提交账号为 kimi-agent-bot。PR 描述写道：模型在做文档、调研类任务时，会大量并行派生子智能体，甚至自行开启 agent swarm，导致“token/额度消耗过大”，这是“KFC 侧集中反馈的 badcase”。KFC 是 PR 中未加解释的内部简称；从 Kimi Code 的模型 ID kimi-for-coding 看，很可能指 Kimi For Coding，即编程会员这一侧。这个 PR 只在两段工具描述里加了限制语句。作者也在描述中承认，提示词层面的约束“能降低发生频率，但不是硬上限”。截至 10 月 26 日，这个 PR 仍未合并。
第二个 PR 是 #4384，提交于 10 月 24 日 19:00 UTC，22 分钟后合并。它处理的是 swarm 模式。按 PR 描述，在 2.3.1 版本里，用户没有输入 /swarm，模型也可以自己调用 AgentSwarm 工具，“一次启动大量 subagent（上限 128）”；而且这个工具“对主 agent 始终可用，并且默认自动放行”。修复的办法是在执行层直接拒绝：只要用户没有开启 swarm 模式，调用就返回错误，不弹审批，也不启动任何子智能体。
第三个 PR 是 #4386，提交于 10 月 24 日 19:44 UTC，在 10 月 25 日 07:26 UTC 合并。它处理的是普通子智能体。PR 描述给出的复现方法是：在一个中等规模的仓库里提出“全面调研”类的请求，模型通常在前 1 到 5 步内就调用 Agent 工具，一次并行开出 2 到 4 个子智能体。
最后，10 月 25 日 07:59 UTC，Kimi Code 2.3.2 发布。这两个改动都在其中。
提示词在鼓励委派
#4386 列出的根本原因并不复杂：提示词有好几处在主动推动模型委派任务，却没有一处要求先等用户提出要求。
PR 引用了原有的几句提示词。explore 类型子智能体的说明是：预计需要超过 3 次搜索的只读探索就用它，并且“Prefer launching multiple explore agents concurrently”，也就是优先同时启动多个。Agent 工具的描述在讲委派的好处，说委派能把大量中间文件内容挡在主上下文之外。plan 模式的说明则要求先派一个 explore 子智能体去调查。
改动后，Agent 工具的描述里多了一条硬规则：除非用户明确要求，否则不启动子智能体。哪些情况算“要求”也有明确清单：用户在消息里点名要子智能体、要委派或要并行，AGENTS.md 或某个 skill 写明了要委派，或者用户打开了 swarm、tower 等多智能体模式。只是任务大、可以分成几块，或者用户说了“深入”“彻底”“调研”，都不算。
PR 里附了一组用真实模型测得的数据。在一个中等规模的开源 TypeScript 仓库上，用 4 个调研、排查类请求测试，用户都没有要求开子智能体。改动前 8 次运行里 8 次开了，改动后是 0/8。用户明确要求开子智能体时，改动前后都照做了。作者自己也写明了这组数据的局限：“受用量额度限制，每格样本较少，只能排除较大的差异。”
代码里的开关和提示词里的规则
这组改动里，两种约束方式并存。
swarm 是一次可以开出上百个子智能体的模式，Kimi 用代码锁住了它：只要用户没开 swarm 模式，模型的调用一律被拒绝。普通子智能体用的仍是提示词规则。#4386 写明这次“只改提示词文本，没有逻辑代码改动”，也没有配置开关；用户想恢复原来的行为，只能在对话里明确要求，或者写进 AGENTS.md 或 skill。#4382 的作者提到，如果需要硬约束，可以在负责派生子智能体的服务里加一个全局并发上限，并表示可以另开 PR 来做。
这些改动也有代价，PR 里的行为变更表写得很清楚。print 模式（kimi -p）和 Zed 等 ACP 客户端原本可以由模型自行发起 swarm，现在根本没有开启 swarm 的入口，表中“退路”一栏写的是“无”。VS Code 扩展这次没有发版，暂不受影响，但下次发版会带上这个改动，而扩展同样没有开启 swarm 的入口；表中对它的退路写的是“扩展发版前需要决定”。依赖模型主动委派来节省主上下文、并行提速的用户，现在也要自己开口要求。截至 10 月 26 日，主分支的中英文文档都仍写着 subagent 由 main agent 自动调度，“无需用户手动指定”。#4386 的作者在 PR 中注明，文档“待补”。
10 月 26 日的后续
10 月 26 日，又有两个 PR 合并，都标注为 2.3.3 hotfix。截至 10 月 26 日，2.3.3 尚未发布。
一个是 #4414，07:13 UTC 合并。原来模型被拒绝调用 swarm 时，界面会画出一个“所有子 agent 都失败”的面板，实际上一个子智能体都没有启动。修复后不再显示这类面板。
另一个是 #4423，09:01 UTC 合并。用户手动开启 swarm 时，界面会显示一行警告：swarm 为大型并行任务设计，消耗的 token 可能是普通任务的许多倍，建议从小任务开始，用完关掉。PR 写明，这行提示对所有用户都一样，不区分是否使用 Kimi 账号的套餐。
同一天还有一个尚未合并的 PR #4418。它指出，用户配置了较便宜的副模型给子智能体用之后，子智能体仍可能“悄悄跑回主模型”，和“副模型用来省钱”的预期不符。另外，有开发者在 #4373 和 #4392 里提出，希望用一条命令以 JSON 格式输出账户额度，方便编辑器集成显示。#4373 这个 PR 还没合并，#4392 这个 issue 也还开着。
订阅制下，谁来决定花多少
Kimi Code 的计费方式是会员订阅，按月或按年付费，有频控限制。K3.1 Pro 上线时公布的开放平台价格是：每百万输出 token 68 元。订阅用户面对的则是额度：致歉信里说，调整结果会显示在“用量进度条”上。
在按量付费的 API 上，模型多开一个子智能体，多出来的 token 会出现在账单上，开发者可以自己权衡划不划算。在订阅制下，这个权衡被提示词里的一句“优先同时启动多个”替代了。花多少由模型决定，扣的是用户的额度。
这几个 PR 的共同方向，是让花费的决定和付钱的人重新对上：swarm 改成用户主动开启，普通委派需要用户明确要求，开启时提示消耗可能成倍增加。致歉信里的 25% 额度重置，则是 Kimi 按统一比例给出的补偿。
这个结构并不限于 Kimi。只要一款包月的编程智能体允许模型自行决定开多少个子智能体，写在提示词里的委派默认值实际上就是一项定价决定。在 Kimi 这里，#4382 把起因写成 KFC 侧集中反馈的额度消耗；随后合并的 #4384、#4386 改掉了这些默认值。
致歉信没有说明，额度异常消耗中有多少来自子智能体，有多少来自输出长度或限流本身；PR 里也没有给出消耗数据。默认改为单智能体之后，任务完成的速度和质量会受到多大影响，同样还要看后续的使用反馈。