文章总结： 作者通过多模型组合（Claude系列、Codex、Antigravity）和子智能体架构，将AI研究时长从30分钟延长至数小时，同时降低幻觉。关键发现包括运行框架影响巨大、上下文压缩可能增加成本、缓存失效导致重新计费等。建议使用廉价模型检索、高精度模型验证，并盘点已付费订阅以优化token消耗。 综合评分： 85 文章分类： 实战经验,解决方案
关于Token经济学与节省方案
原创
黑鸟 黑鸟
黑鸟
2026年7月19日 23:24 广东
在小说阅读器读本章
去阅读
一个名为Quesma的团队正致力于研究 AI 智能体的成本经济学：
智能体编程的真实成本几何，企业又该如何管控相关支出。
为开展这项研究，巴托什搭建了一套专属深度研究体系 ： 由多智能体组成的流水线，用于构建他能够完全信赖的知识库。
这套系统的初代版本仅用 30 分钟，就耗光了他 Claude Max 5x 套餐的全部额度上限。本文讲述了他如何在仅使用已有付费订阅的前提下，同时解决成本与可信度两大问题，以及读者该如何搭建同款系统。
他的目标是全面摸清所谓 “Token 经济学” 的行业现状。他希望厘清市面上有哪些监控系统，团队如何治理 AI 支出，以及哪些优化工具与实践在学术论文和真实场景中真正有效。
他起初沿用了常规方式，调用/deep-research指令，抛出这个宏大的开放性问题后便任其运行。仅 30 分钟左右的研究后，他就触达了额度上限，不得不等待数小时待额度重置，且全程没有产出任何有效结果。这次运行共启动了 111 个智能体，排队待验证的声明达 123 条，但额度耗尽前仅完成了 25 条验证，最终的内容整合步骤完全没能启动。
这件事给了他切身的冲击，也颇有几分趣味：从研究的第一天起，他就不得不在探索 Token 优化方法的同时，先动手优化自己的 Token 消耗，在实践中摸索学习。
盘活所有已付费的订阅服务
#
如果 Claude Fable 5 的额度 30 分钟就会耗尽，/deep-research工具消耗大量 Token 却毫无产出，他该如何提升研究的效率？他开始梳理自己已经付费订阅的工具：Claude、Codex 和 Antigravity 三份订阅，理论上不用额外付费就能获得三倍的 Token 额度。如果让这些工具协同运行、共享记忆，效果会如何？
由于他本身就在使用 claude-mem 插件，他对插件做了本地扩展，使其支持 Codex 与 Antigravity，让三款工具能在会话期间共享内存， 任意一款工具获取的信息，其他工具都可以直接调用。
用更廉价的模型充当子智能体
#
他的默认开发环境是 Claude Code，因此将其作为主控框架。在手动开展研究的过程中，他发现了一种模型编排模式，恰好能解决他当下的痛点：并非所有任务都需要调用 Fable 模型，Claude Opus 4.8、Claude Sonnet 5、GPT-5.5 和 Gemini 3.1 Pro 应对多数任务已经足够出色。
Claude Code 作为主控端，承载原生 Claude 智能体；Codex 与 Antigravity 作为无头子智能体接入，全部模块通过 claude-mem 共享内存，分别消耗对应订阅的额度，无需额外按量付费。
他参考了多项基准测试与成本分析数据，主要包括面向终端与智能体任务的 Terminal-Bench、面向端到端软件工程的 SWE-bench Pro，以及提供模型性能与价格整体概览的 Artificial Analysis。他并未将这些测试结果奉为圭臬， 基准测试各有侧重，数据也每月都在变动。他只需要一个粗略的参考，判断不同模型的擅长领域；从实验之初，他就计划采用多模型组合，并根据实际运行结果调整分工：
| 角色 | 模型 | 选型原因 | | — | — | — | | 信息检索 | Claude Sonnet 5 | 智能体基准测试表现优异，成本足够低，支持批量运行 | | 内容验证 | Claude Opus 4.8 | Claude 系列中准确率最高的工作模型；校验工作对精度的要求高于搜索 | | 评判与规划 | Claude Fable 5 | 成本最高的模型，仅用于任务规划、拆解及争议裁决 | | 琐碎任务 | Claude Haiku 4.5 | 成本低、速度快，适合信息提取与格式整理，不足以应对多步骤复杂任务 | | 工具执行 | Codex（GPT-5.5） | 终端基准测试表现极强，可完成代码克隆、环境安装、运行及工具检测等操作 | | 第二意见 | Antigravity（Gemini 3.1 Pro） | 属于不同的模型家族，不存在与 Claude 系列相同的认知盲区 |
这个分工并非最初的版本，实际运行中暴露短板后，他已经做了数次调整，自动降级规则也正是从这些失败案例中总结而来。
这套方案的核心优势在于，他将 Codex 和 Antigravity 配置为 Claude 的子智能体，由 Fable 统一调度，且二者都支持无头（Headless）运行模式。这套设计的巧妙之处在于：消耗的 Token 都来自 Codex 和 Antigravity 的订阅额度，他无需支付额外费用，就能立刻获得大幅提升的算力支持。
实现的核心只是一段简短的 Bash 脚本，他的 Claude 智能体可以像调用其他命令一样调用它：
# run-cli: 调用其他厂商的CLI作为无头子智能体# 用法: run-cli <codex|antigravity> "<提示词>"VENDOR="$1"; PROMPT="$2"case "$VENDOR" in codex) OUT="$(codex exec --sandbox read-only "$PROMPT")" ;; antigravity) OUT="$(agy --model "Gemini 3.1 Pro (High)" -p "$PROMPT")" ;;esacecho "$OUT"echo "$OUT" | claude-mem-save -s "$VENDOR" # 保存到共享内存（本地扩展版claude-mem）
这个封装脚本还会监测输出中的 “使用上限”“额度不足” 等提示，并返回特殊的退出码，这正是自动降级到 Claude 模型的实现逻辑：调度器收到信号后，就会改用 Claude 智能体完成对应任务。
另一个至关重要的细节是必须为每个角色固定模型，因为子智能体会默认继承父级的模型，而他最初 30 分钟耗光 Fable 额度，正是这个原因导致的。
借助这套方案，他能让研究持续运行的时长，达到了仅使用 Fable 时的 10 倍左右 ，衡量标准就是三份订阅中任意一份触达上限前，智能体的持续工作时长。从前只能运行 30 分钟，现在可以连续工作数小时，且没有多花一分钱。而当 Codex 或 Antigravity 触达额度上限时，框架会自动降级到 Claude 模型，研究不会中断。
降低幻觉发生率
#
成本只是第一个问题，第二个问题是内容可信度。在搭建这套研究框架之前，所有任务都由 Fable 完成，他有时会收到看似严谨、实则错误的结论。比如仓库的授权协议标注错误、没有来源的成本节省数据、引用页面中根本不存在的数字等。为了降低幻觉，他在研究框架中制定了明确规则，所有结论必须通过校验才能入库，部分规则如下：
提出结论的智能体不得参与验证，必须由不同的模型或智能体核验链接、原文引用和数据。
没有原始来源 URL 和原文引用的内容，一律不得进入知识库。
不得编造来源页面中不存在的数字。
这些规则并非一次性设计完成，而是在研究过程中逐步补充的 —— 每当验证环节发现新的错误类型，就会把对应规则补充到提示词中。这类框架只有持续迭代才能保持效果，因此需要定期复盘结论、标记无效内容，并将反馈回传给系统。
/deep-research放在最后一步
#
解决了成本和可信度问题后，最后一块拼图就是引发这一切的/deep-research工具。
它仍然在流水线中，但位置从第一步改成了最后一步。每天结束时，他会用它处理已经通过验证的结论：它不再是盲目探索，而是基于已有的结论做深度挖掘、清理冗余信息、填补框架遗漏的空白。
这种方式也更节省 Token，因为它只需要处理固定的结论清单，而非漫无目的地浏览全网。最近一次运行仅启动了 61 个智能体，耗时 22 分钟。对比第一天，111 个智能体 30 分钟耗光全部额度，最终连报告都没能生成。工具还是同一个，只是任务量大幅缩减了。
整套流水线的完整流程为：Claude Sonnet 5 负责信息检索→Claude Opus 4.8 负责内容校验→Claude Fable 5 负责内容评判与任务规划→Codex 执行工具类操作→Gemini 3.1 Pro 做缺口分析与补充检索→多模型投票完成深度验证→最终经人工审核后同步至知识库；Claude Haiku 4.5 全程负责信息提取与格式整理等辅助工作。
最终成果：值得信赖的知识库
#
所有通过验证的内容，都会存入他用 Obsidian 搭建的 LLM 知识库，这套设计灵感来自卡帕西的 LLM Wiki 模式：原子化的关联笔记、智能体定期巡检、规则由人制定。运行一周后，库中已经积累了数百条经过验证的笔记，覆盖定价、工具、基准测试、行业实践等多个维度。
自动化校验并非万能。有一次，他的分类规则悄悄屏蔽了 Headroom：这个拥有 5.6 万星标的项目是同类中规模最大的项目之一。
智能体的操作完全符合流程：验证确认项目本身合规，但声明校验准确标记出其宣传的成本节省数据缺乏质量管控。
而他的规则是 “未经验证的声明一律不得入库”，结果这个半个行业都在使用的项目，在他的知识库里完全查不到。直到两天后他问起 “我们怎么漏掉了这个项目”，问题才被发现。
修复方案是新增一条规则：驳回不实声明，而非整个项目。智能体可以完成检索和校验工作，但永远不会主动告诉你，规则本身存在缺陷。
如果想要搭建高质量的知识库，人工验证与研究补充是必不可少的。纯 AI 研究的质量往往堪忧，纯人工研究效率又太低。最优方案是人机协同：智能体承担繁重的基础研究工作，但运行的流水线由人设计、持续迭代；同时由人核验最终结果、填补研究空白。
知识库中的部分发现
#
Token 经济学这个主题的广度远超他的预期。
以下是库中一小部分最让他意外的发现：
-
运行框架的影响和模型本身一样大
在 Terminal-Bench 测试中，同一款模型在不同运行框架下的 Token 消耗差距可达 66 倍，且更轻量的框架得分反而更高，而非更低。另一项研究显示，仅更换运行框架，同一款模型的测试得分波动可达 54 个百分点。团队在测试向 AI 智能体说 “你好” 的真实成本时，也观察到了类似的小规模差异。
-
上下文压缩可能让账单翻倍，而非节省成本
压缩听起来和文件压缩类似，很容易让人默认它永远有益，但它并非零成本：模型需要总结对话历史，而这个总结过程本身就会消耗 Token。此外，压缩还可能误删智能体仍需使用的文件，导致智能体重新读取文件，上下文再次占满，进而再次触发压缩 —— 形成恶性循环。有记录的案例显示了这套循环的严重程度：某框架调整压缩阈值后，单会话压缩次数从 4 次飙升至 12-26 次，相同任务的 Token 消耗从 8900 万上涨至 1.6-1.85 亿。
-
会话中途修改工具，会悄悄导致全部内容重新计费
缓存读取的成本约为基础输入价格的十分之一，但缓存失效是分层级的：先工具层，再系统提示层，最后是消息层。会话中途新增或重排一个工具的配置，整个缓存前缀就会失效，按全价重新计费。不会有任何报错，只会收到更高的账单。
-
你的 Token 计数器数值不等于最终账单
有记录的案例显示，预估每月 3.6 美元的成本，最终账单高达 25-40 美元，差距达 7-11 倍。差额来自上下文累积、重试放大、框架开销、评估调用等诸多因素，而简单的 Token 估算工具完全捕捉不到这些成本。
框架将大部分这类结论标记为中等可信度，通常只有 1-2 个可靠来源，并且会明确标注可信度，而非假装结论已经盖棺定论。
如果你正在深度研究中频繁触达额度上限，不妨试试反转流程：用廉价模型做检索，用高精度模型做验证，把深度研究放在最后一步。
同时也可以盘点一下，自己已经付费的算力究竟有多少。
为每份订阅的模型分配明确的角色，远比盲目调用单一前沿模型效率高得多。
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：黑鸟 黑鸟 黑鸟《关于Token经济学与节省方案》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论