优化 AI Agent Tokenomics：构建自定义深度研究流水线
优化 AI Agent Tokenomics：构建自定义深度研究流水线
Agentic 研究的高昂成本
运行复杂的 AI 研究流水线会导致 Token 消耗极快。一个标准的 /deep-research 运行可能会启动超过 100 个 Agent，并排队超过 100 个待验证的 Claim，这可能会在短短 30 分钟内耗尽高级订阅限制（例如 Claude Max 5x），且尚未产生最终的综合报告。
为了解决这个问题，我们开发了一个自定义的深度研究流水线，以优化 Token 消耗并提高输出的可靠性。通过从单一的前沿模型转向多模型编排策略，研究时长在不增加每月支出的情况下，大约延长了 10 倍。
模型编排与角色分配
效率的实现是通过根据模型的优势和成本将特定模型固定到特定角色，而不是对每个任务都使用最昂贵的模型。这可以防止“继承”问题，即子 Agent 默认使用父 Agent 的昂贵模型。
编排栈
| Role | Model | Rationale |
|---|---|---|
| Find | Claude Sonnet 5 | 强大的 Agentic 性能；在大规模搜索时具有成本效益。 |
| Verify | Claude Opus 4.8 | 高准确度；对于检查 Claim 和 Quote 非常关键。 |
| Judge & Plan | Claude Fable 5 | 最昂贵；保留用于高级别的分解和争议解决。 |
| Small Tasks | Claude Haiku 4.5 | 快速且廉价，适用于提取和格式化。 |
| Run Tools | Codex (GPT-5.5) | 在用于安装和检查的终端基准测试中表现出色。 |
| Second Opinion | Antigravity (Gemini 3.1 Pro) | 使用不同的模型家族以避免共同的盲点。 |
跨厂商集成
为了利用多个现有的订阅（Claude, Codex, 和 Antigravity），一个 Bash wrapper 允许 Claude Agent 调用其他厂商的 CLI 作为无头子 Agent。这种方法将 Token 使用量分布到不同的账户中，并提供了一种自动回退机制：如果一个厂商达到使用限制，编排器会将任务重定向到 Claude 模型。
确保信任并减少幻觉
仅靠成本优化并不能保证准确性。为了防止幻觉，该流水线实施了严格的验证规则：
- 关注点分离： 发现 Claim 的 Agent 绝不是负责验证它的那个 Agent。
- 来源要求： 任何发现的内容如果不包含 URL 和来自原始来源的直接 Quote，则不会进入知识库。
- 字面准确性： 禁止模型陈述未在原始页面上明确出现的数字。
这些规则是迭代的；每当验证步骤发现了一类新的错误，该规则就会被添加到系统提示词中。然而，人工监督仍然是强制性的。自动化规则可能过于僵化——例如，曾经有一个拒绝“未验证的 Claim”的规则导致流水线忽略了一个重大的行业项目，因为该项目的营销 Claim 尚未经过质量控制。解决方法是改进规则，使其拒绝特定的 Claim，而不是拒绝整个项目。
策略性流水线顺序
操作顺序会显著影响 Token 效率。流水线不再从宽泛的 /deep-research 命令开始，而是遵循以下顺序：
- Find & Verify： 廉价模型负责发现数据，准确的模型负责验证数据。
- Judge & Run： 高级模型负责规划并执行基于工具的证据收集。
- Deep-Validate： 通过多数投票和人工审批过程。
- Final Synthesis：
/deep-research被用作最终步骤，用于深化现有发现并填补空白，而不是盲目地在互联网上探索。这减少了所需的 Agent 数量，并确保工具在处理固定列表的 Claim 时工作。
Token 经济学方面的关键发现
通过该流水线进行的研究揭示了关于 AI Agent 如何消耗 Token 的几个关键见解解：
- Harness Impact： 使用某种模型运行的框架（harness）会导致相同模型在 Token 消耗量上产生 66 倍的差距，配置越精简的设置通常得分越高。 | | Context Compaction Risks： 自动化上下文压缩（context compaction）可能导致“压缩循环”，即模型总结历史记录，剔除除必要文件，然后又重新读取它们，从而可能使账单金额翻倍。 | | Cache Invalidation： 在会话中添加或重新排序单个工具 Schema，会使整个缓存的前缀失效，导致会话重新按全价计费。 | | Estimation Gaps： 简单的 Token 计数器往往会低估实际账单。在某些情况下，计算出的成本为每月 $3.60，但由于重试放大效应和框架开销，实际账单为每月 $25-40。 |
社区观点与反论点
虽然流水线方法提供了一种结构化的方式来管理成本，但社区讨论也强调了其他替代策略和潜在的坑：
"The reason most people burn through their allocated limits is mostly because of sub-agents. Stop using them and even the Pro tier is enough for daily 8-12h coding sessions."
其他贡献者建议专注于本地 LLM 以避免厂商锁定并降低成本：
"I never bought tokens in an，用 GPU 而不是买 Token。使用 Big/Cloud LLM 来帮助你为你的本地/小型 LLM "find good enough configs" for your local/small llms."
此外，一些人认为幻觉无法通过规则或其它模型完全解决，暗示着 LLM 的本质属性使得“无幻觉”成为一个不可能的目标。