为研究节省token，花光所有token

背景

在 AI 驱动的研发成本不断攀升的当下，如何高效使用 token 已成为现实问题。Quesma 团队正在研究 AI agent 的经济学——探究 agentic coding 的真实成本以及应对策略。作者本人为此搭建了一套深度研究框架，由多个 agent 组成的流水线用于构建可靠的知识库。然而，第一版框架在 30 分钟内就烧光了 Claude Max 5x 计划的全部 token 限额，且未产出任何可用结果。这篇文章记录了作者如何仅利用自己已订阅的服务，在不增加额外支出的前提下解决成本与信任问题，并分享如何复现这一方案。

核心内容

初始困境：昂贵且无效的深度研究

作者的目标是全面理解所谓的“tokenomics”（token 经济学），包括现有监控系统、团队如何治理 AI 支出，以及哪些优化工具和实践真正有效（既看论文也看实际效果）。他像往常一样启动 /deep-research，输入一个大问题后任其运行。大约 30 分钟后，限额被触发，必须等待数小时重置，且没有任何结果。这次运行启动了 111 个 agent，排队了 123 个 claim 待验证，但只有 25 个在限额前完成了验证，最终的综合报告从未执行。这迫使作者在第一天就不得不一边研究如何优化 token，一边亲身实践——边学边做。

利用已有订阅：三倍 token 但不花额外钱

既然 Claude Fable 5 在 30 分钟内耗尽，且 /deep-research 消耗大量 token 却无产出，作者开始思考如何利用已有工具。他已有 3 个订阅：Claude、Codex 和 Antigravity。理论上有三倍 token 可用，且无需额外付费。关键想法是让这些工具共享内存，协同工作。作者扩展了已使用的 claude-mem 插件，使其支持本地化的 Codex 和 Antigravity，这样三个工具在会话期间可以共享记忆：一个工具学到的内容，其他工具也能使用。

用更便宜的模型作为子 agent

默认设置是 Claude Code，作者将其作为主控制器。在研究过程中，他发现了一种模型编排模式：并非所有任务都需要 Fable。Claude Opus 4.8、Claude Sonnet 5、GPT-5.5 和 Gemini 3.1 Pro 在许多任务上已经非常优秀。他参考了几个基准测试和成本分析，主要是 Terminal-Bench（用于终端和 agent 工作）、SWE-bench Pro（用于端到端软件工程）以及 Artificial Analysis（用于性能和价格概览）。他并不将任何基准视为绝对真理，只是作为松散起点，判断哪个模型擅长什么。从一开始多模型并用就是实验的一部分，预期在真实运行后调整分配。

这里的核心技巧是：他让 Codex 和 Antigravity 作为 Claude 的子 agent，由 Fable 编排，利用两者的无头（headless）特性。为什么酷？因为 token 消耗来自 Codex 和 Antigravity 的订阅，不额外付费，但立即获得了更多可用的智能。

实现方式是一个简单的 Bash 脚本，Claude agent 可以像调用其他命令一样调用它：

# run-cli: call another vendor's CLI as a headless subagent
# usage: run-cli <codex|antigravity> "<prompt>"
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")" ;;
esac
echo "$OUT"
echo "$OUT" | claude-mem-save -s "$VENDOR" # save to shared memory

该包装器还会监控输出中的“usage limit”和“out of credits”消息，并返回特殊退出码，从而自动回退到 Claude 模型：当子 agent 用尽限额时，编排器检测到信号，改用 Claude agent 完成任务。

另一个关键的细节是：必须为每个角色固定模型，因为子 agent 默认继承父模型——这正是作者最初 30 分钟烧光 Fable 限额的原因。

使用这种技术后，作者能够连续运行研究的时间大约是仅用 Fable 时的 10 倍（以三个订阅中任何一个达到限额前 agent 能持续工作的时间来衡量）。之前是 30 分钟，现在是几小时，没有多花一分钱。当 Codex 或 Antigravity 达到自身限额时，框架自动回退到 Claude 模型，研究不会中断。

减少幻觉

成本只是第一个问题，第二个是信任。在搭建研究框架之前，所有工作都由 Fable 完成，有时会得到看起来可靠但实际错误的结果。例如，仓库的许可证信息错误、没有来源的节省数字、引用页面上不存在的数字。为了减少幻觉，作者在研究框架中实施了显式规则，每条发现必须通过验证才能被共享。部分规则如下：

• 谁发现 claim，谁就不验证它。由不同的模型或 agent 检查链接、引用和数字。
• 没有 URL 和主要来源的引用，任何内容不得进入知识库。
• 绝不陈述源页面中不包含的数字。

这些规则并非预先设计，而是在研究过程中不断生长。每次验证捕获到新类型的错误，该规则就被加入 prompt。这种框架只有持续调整才真正有效——审查结果、标记无用信息、反馈给系统。

/deep-research 放在最后

解决了成本和信任问题后，最后一部分是引发这一切的 /deep-research 工具。它仍然在流水线中，但放在最后一步，而非第一步。每天结束时，作者对它运行已经通过验证的发现，这样它就不是盲目探索，而是基于现有发现进行深化、消除混乱、并尝试填补框架遗漏的空白。这种方式也消耗更少的 token，因为它只处理一个固定的 claim 列表，而不是遍历互联网。最近一次运行使用了 61 个 agent，耗时 22 分钟。对比第一天：111 个 agent 在约 30 分钟内烧光限额，且从未生成报告。同样的工具，更小的工作量。

结果：一个可以信任的知识库

所有通过验证的发现最终进入一个 LLM wiki，作者将其保存在 Obsidian 中，灵感来自 Karpathy 的 LLM wiki 模式：原子笔记相互链接，agent 负责扫描，人类设定规则。一周后，该 wiki 已包含数百条经过验证的笔记，涵盖定价、工具、基准和实践。

但自动化检查本身并不足够。有一次，他的分类规则默默拒绝了 Headroom（一个 56k star 的项目，同类中最大的之一）。agent 做得正确，验证确认项目合法，但 claim 检查正确地标记了其标题节省数字未经过质量审核。然而规则是“未验证的 claim 意味着不收录”，导致半个行业都在使用的项目在知识库中不可见。作者两天后才注意到，问“我们怎么错过了这个？”修复措施是新规则：拒绝 claim，而不是拒绝项目。agent 可以搜索和检查，但没有 agent 会告诉你你自己的规则就是 bug。

作者总结：要构建高质量的知识库，人工验证和补充研究是必须的。纯 AI 的研究质量可能很差，纯人工的研究又太慢。最佳方式是混合：agent 承担繁重的研究工作，但运行在由人类不断打磨的流水线上；人类也负责验证结果并填补空白。

关键要点

• 初始痛点：单一高端模型（Claude Fable）的 /deep-research 在 30 分钟内烧光限额且无产出，成本与效率双输。
• 多订阅组合：利用已有 Claude、Codex