Claude变笨又变贵？开发者实测配额异常引发争议

一位开发者的深夜实测

近日，一位Reddit用户发帖抱怨Claude近期表现「既变笨又变贵」，引发社区共鸣。这位开发者描述了自己惯用的多智能体（multi-agent）工作流：用一个Fable orchestrator（编排器）来调度Opus或Sonnet子智能体（subagent）执行具体编码任务。

他的设定颇具代表性——编排器本身被禁止直接写代码，只负责审查并合并子智能体提交的PR（Pull Request）。这种「分工协作」的架构在AI编程实践中越来越常见，理论上能兼顾效率与质量控制。

reddit source

多智能体（multi-agent）工作流是一种将复杂任务分解给多个AI实例协作完成的架构模式。其中「编排器」（orchestrator）负责任务规划、分配与结果整合，相当于项目经理；「子智能体」（subagent）则专注执行具体的原子任务。Fable是一个专为AI编程场景设计的编排框架，允许开发者定义智能体角色权限（例如本文中编排器被禁止直接写代码），并以PR（Pull Request）作为代码交付的质量检查节点。这种架构的核心优势在于：通过角色分离让每个智能体保持较短的上下文窗口，理论上能减少「注意力漂移」并实现并行提速。然而，这种设计也引入了新的脆弱点——当子智能体输出质量下降时，编排器若缺乏有效的异常检测逻辑，整个系统会陷入「反复审查—反复失败」的死循环，而每一轮循环都在消耗真实的API配额。

一夜烧光整周配额

问题出在一次「过夜运行」上。他把任务丢给系统后离开，第二天回来发现整套流程消耗了他全部的每周Fable配额，外加总周配额的75%。

更让他不解的是过程本身：编排器与某个子智能体针对同一个PR进行了十九轮修订，反复修复又反复引入相同的bug，始终在原地打转。用他的话说，「我很确定它过去没这么蠢」——按以往经验，Opus子智能体本该更快给出正确结果，而Fable编排器也应该能察觉进展停滞，主动调整策略，或者停下来向人类求助。

配额消耗速度的异常

这位用户还提出了一个值得注意的量化观察：在过去，仅用3个智能体（其中1个Fable）工作时，他不可能在约12小时内耗尽配额。

这意味着问题可能是双重的：

智能体推理能力下降：无法一次性解决问题，陷入低效的反复修订循环；
单位任务成本上升：无论是token消耗还是配额计算方式，实际开销明显高于预期。

两者叠加，就形成了「变笨又变贵」的直观感受——模型解决问题的能力下降，反而需要更多轮次、消耗更多资源。

如何看待这类主观体验

需要冷静指出的是，这是一份单一来源、基于主观感受的报告，缺乏严格的对照实验数据。AI模型的「变笨感」在社区中是长期存在的争议话题，可能的解释有多种：

模型或路由策略的静默更新，导致行为变化；
服务端负载高峰期的性能波动；
用户任务本身的复杂度或代码库状态发生了变化；
多智能体架构的固有脆弱性——一旦子智能体陷入错误循环，编排器若缺乏有效的「止损」机制，成本会指数级放大。

最后一点尤其值得从事AI编程的开发者警惕：多智能体系统的失控成本是真实存在的工程风险。当编排器无法识别「无效循环」时，一次过夜运行就足以烧光配额。

给多智能体开发者的启示

无论Claude是否真的「退步」，这个案例都提供了实用教训：

为自动化工作流设置硬性熔断条件，例如同一PR超过N轮修订即强制停止；
避免无人值守的长时间过夜运行，尤其是涉及配额消耗的场景；
在编排器逻辑中加入「进展检测」，识别原地打转的信号并主动求助人类。

这类来自一线的真实反馈，比厂商的宣传更能揭示AI编程工具在实际生产中的边界与坑点。

「熔断机制」（circuit breaker）是借鉴自分布式系统工程的容错模式：当某个依赖服务连续失败超过阈值时，自动切断调用链路，避免级联故障与资源耗尽。在多智能体AI工作流中，这一思路同样适用——具体实现可以包括：追踪同一任务的重试次数并设置上限、对比相邻两轮输出的语义相似度（高相似度意味着原地打转）、监控单次任务的累计token消耗并设置预算上限。「进展检测」则更进一步，要求编排器能够判断任务是否在朝目标方向移动，而不仅仅是在「有输出」。这两类机制目前在大多数AI编排框架中仍属可选配置，而非默认开启，这是造成本文案例中配额失控的根本工程原因。