深翼判例库DeepWing Case Library · INC-044 · 编排层Orchestration

Kimi K3.1 Pro 上线两天,多余的子 Agent 调用吃掉会员额度并触发限流:月之暗面致歉,给全部付费会员补偿月度额度的 25%Two days after Kimi K3.1 Pro launched, unnecessary sub-agent calls ate members' quota and triggered rate limits: Moonshot AI apologised and gave every paying member 25% of a month's quota back

主失效层Primary failure layer:编排层Orchestration | 证据状态Evidence:多源已核Multi-source verified | 披露日期Disclosed:2026-10-26 | 核查日期Checked:2026-10-28

时间线Timeline

2026-10-24 凌晨K3.1 Pro 发布(据报道)
10-24 至 10-26会员反映限流与额度消耗异常,投诉在用户社群发酵
2026-10-26 凌晨Kimi 致歉并公布补偿,当日完成额度重置
2026-10-24, early hoursK3.1 Pro launches (per reports)
10-24 to 10-26Members report rate limits and unusual quota use; complaints spread in user communities
2026-10-26, early hoursKimi apologises and announces compensation; quotas reset the same day

已证实事实Confirmed facts

发生了什么:K3.1 Pro 发布后,Kimi 会员在使用中遇到限流,任务执行里出现不必要的额度消耗,同样的额度能完成的有效任务变少,影响写作、资料研读、代码调试等场景。

当事方回应:2026-10-26 凌晨,Kimi 发布《致用户:关于近期使用体验问题的致歉与补偿》,承认「问题出在我们」,本应更早修复;称相关配置调整已完成,做法是减少不必要的子 Agent 调用、精简冗余输出长度、优化模型调用链路。

补偿:所有档位的有效订阅会员统一补偿月度总额 25% 的额度,约一周正常用量;已用不足 25% 的直接归零重置;用量进度条当日更新。

未公开:问题起止时间、受影响会员人数、多扣的额度规模。

证据说明:公告原文本站未直读,内容以多家报道一致的部分为准,记为多源已核。

What happened: after K3.1 Pro launched, Kimi members hit rate limits and saw unnecessary quota consumption during tasks, so the same quota completed fewer useful tasks, affecting writing, reading and code debugging.

Party response: in the early hours of 2026-10-26, Kimi published 'To users: apology and compensation for recent usage problems', saying the fault was the platform's and should have been fixed sooner. It said configuration changes were complete: fewer unnecessary sub-agent calls, shorter redundant output, and an optimised model call chain.

Compensation: every active paid member, at every tier, received 25% of the monthly quota back, about a week of normal use; members who had used less than 25% were reset to zero use; usage bars updated the same day.

Not disclosed: when the problem started and ended, how many members were affected, and how much extra quota was consumed.

Evidence note: the notice itself was not read firsthand; the entry relies on what multiple reports agree on, graded multi-source verified.

失效机制Failure mechanism深翼分析DeepWing analysis

按公告给出的整改方向,额度被吃掉的地方在调用链路:一次任务派生出多余的子 Agent 调用、输出过长,每一次都计入会员额度,而编排层没有给子 Agent 调用设上限或预算。第一处失效的防线在这里。

因此本案归入编排层。成本最后落在用户身上:平台按调用计量,用户按任务感受,两者之间缺一道「多余调用不由用户买单」的校验。

By the notice's own fixes, the quota was eaten in the call chain: one task spawned unnecessary sub-agent calls and over-long output, each charged to the member's quota, and orchestration set no cap or budget on sub-agent calls. That was the first defence to fail.

The case therefore belongs to the Orchestration layer. The cost landed on users: the platform meters calls, users experience tasks, and nothing in between checked that wasted calls are not billed to the user.

工程启示Engineering lessons

子 Agent 调用设上限与预算:每个任务能派生多少子调用、最多花多少额度,事先定好,超了就停下问人。

新模型上线前做额度回归:用一组固定任务比对新旧模型的平均额度消耗,异常就不放量。

扣费可解释:用户能看到一次任务分成了哪些调用、各扣了多少。

Cap and budget sub-agent calls: set in advance how many sub-calls a task may spawn and how much quota it may spend; stop and ask when it exceeds them.

Run a quota regression before launching a model: compare average quota use of old and new models on a fixed task set, and hold the rollout if it jumps.

Make charges explainable: users can see which calls a task made and what each one cost.

你的系统里,Agent 的对外动作有人盯着吗?Is anyone watching what your agents do outside your system?

做 17 题免费自检Take the free 17-question self-check

回到判例库Back to the Case Library →