他为了研究怎么省 Token，先在 30 分钟里烧光了 Claude 限额
林岚｜OC 开发者生态编辑
林岚｜OC 开发者生态编辑
据 Quesma 工程博客 分享，作者为了研究 AI Agent 的 Token 经济，最初让 Claude 的深度研究功能直接处理大问题，约 30 分钟便用完 Claude Max 5x 限额：系统启动 111 个 Agent，排队验证 123 条说法，只完成 25 条验证，甚至没来得及生成最终报告。
一句话结论： 省 Token 的关键不是让每个 Agent 都少说几句，而是把“寻找、验证、裁决和综合”拆开，让昂贵模型只处理真正需要它的环节，并避免一次无边界的研究把预算烧在中途状态上。
这篇文章最有意思的地方，是作者研究的对象先在自己身上发生了。一个看似合理的任务“帮我完整研究 Agent 成本”，被系统拆成一百多个并行工作单元；过程看起来非常忙，最后却因为配额耗尽，没有交付任何可用结果。
这也是 Agent 工作流和普通聊天最大的成本差异。聊天往往是一问一答，Agent 会反复读取上下文、调用工具、生成中间报告、验证结果，再把新材料塞回上下文。界面里看到的一段最终文字，背后可能已经发生几十次模型调用。订阅用户感受到的是“突然触顶”，API 用户看到的则是一张比预期大得多的账单。
作者后来把 Claude Code 作为主调度器，把不同订阅里的能力分工使用：较便宜的模型批量搜索，更准确的模型核对来源，最昂贵的模型只负责规划和解决冲突；Codex 负责克隆、安装和运行工具，另一个模型家族提供第二意见。多个工具通过共享记忆交换结果，某个订阅到限额后再回退到其他模型。
据作者自测，这套安排把连续研究时间从约 30 分钟延长到数小时，接近十倍。但这个数字不能直接理解成通用的“成本降低 90%”：他使用的是已经购买的多个订阅，等于把工作量分散到不同配额，并没有证明底层算力凭空减少。不同服务的使用条款也可能限制自动化调用，团队采用前必须先核对。
比省配额更值得借鉴的是验证规则。作者要求发现某项结论的 Agent 不能同时负责验证；知识库中的数字必须能在来源页面找到；没有 URL 和原始引文的说法不能入库。深度研究也被放到最后，用来整理已经经过初筛的材料，而不是从一个无限问题开始漫游。后一次运行用了 61 个 Agent 和 22 分钟，但至少输入范围和交付目标都已固定。
这种流程仍然不是全自动真相机器。作者自己举了一个失败：规则因为某项目宣传的节省数字未经验证，直接把整个项目排除，导致一个有大量用户的工具从知识库消失。Agent 正确执行了规则，错误的是规则本身。最后的修正是“拒绝未经证实的说法，而不是拒绝整个项目”。
这件事对普通用户也有直接意义。与其让一个模型“彻底研究某领域”，不如先限定问题、要求一页来源清单，再选择其中几条深入核验；先产出可恢复的中间结果，避免最后一步失败后什么都没有；长期任务则记录每条结论的来源、日期和置信度。Agent 越强，任务管理越不能只靠一句豪迈的提示词。
文章还提出一个容易被忽略的成本来源：Agent 的外壳同样重要。同一模型放进不同 harness，工具描述、上下文压缩、缓存失效和重试策略都可能让 Token 用量相差巨大。模型单价只是账单的一列，实际成本还包括它被迫重复读了多少内容、失败后重跑了几次，以及为了管理 Agent 又调用了多少 Agent。
关键事实
- 初始运行启动 111 个 Agent，123 条待验证说法只完成 25 条，约 30 分钟耗尽一次 Claude Max 5x 限额。
- 改造后按寻找、验证、规划、工具执行和最终综合分工，并在多个已购订阅间调度。
- “约十倍更久”是作者按触顶时间做的个人实验，不是标准化成本基准。
OC 判断
Agent 时代最昂贵的浪费，不是某次回答多了几百 Token，而是没有交付边界的递归工作。一个好流程应该随时能停、能看到已完成成果、能由不同模型接手，也能让人发现“规则本身错了”。
为什么重要
- 对开发者： 应记录每个阶段的调用、缓存、重试和产物，优化 harness 可能比换便宜模型更有效。
- 对企业： 多模型编排不是自动省钱，必须把订阅合规、质量验证和总体算力一起核算。
- 对用户： 大型研究先缩小问题、先要来源、分段保存，比一次点击“深度研究”更可靠。
评论
围绕这篇文章补充信息、提出问题或分享观察。