智能体Teamwork 3000亿Token账单｜长任务成本实测

我是 4sapi（https://4sapi.com），常年跑 API 接入与成本优化这条赛道。今天这期，我盯着 OpenAI 那份 3000 亿 token 的智能体账单，把长任务跑 API 的成本架构拆开讲。

一、痛点：长任务的 token 轮次爆炸

单次调用的成本很好算：一个 prompt 几千 token，一个 response 几千 token，乘上单价就行。可一旦任务从"一次问答"变成"一组智能体连续跑几十小时"，成本模型就完全换了一副面孔。长任务里真正吃掉预算的不是单轮价格，而是轮次爆炸：上下文越滚越大，每一轮都要把全部历史重新喂给模型；子智能体之间互相传消息，消息量按智能体数量的平方级上涨；中间任何一轮失败，整段重来，token 再翻一倍。

我见过太多类似的翻车现场：任务拆了 20 个子智能体，每个子智能体内部循环 30 轮，消息矩阵把上下文撑到几十万 token，随后每一轮调用的输入都直奔百万 token 而去。账单在后台以肉眼可见的速度滚动，等发现时预算早已超支。长任务工程的第一课，就是先把"轮次"和"token"当成一等公民来管理，而不是事后看账单。

二、今日现场：88 小时解方程，3000 亿 token 的账单

今天圈子里最热闹的一件事，是一组 OpenAI 智能体用大约 88 小时，给出了 Navier-Stokes 千禧年大奖难题的一个解——那是悬置了约 90 年的三维流体方程 blow up 问题。解出来之后，团队又用 GPT-6 Astra 花了约 17 小时，完成了整套结果的 Lean 形式化验证。

数字相当夸张：全程发送了 490 万条消息，消耗约 3000 亿输出 token。Noam Brown 承认这次跑动花费达数百万美元量级，不过他坚持认为这类成本会快速下降。消息一出，争议也如影随形：NYU 教授 Tristan Buckmaster 与 Anthropic 数学家 Levent Alpöge 指控研究路线信息被泄露，OpenAI 是靠海量算力沿着别人思路追赶；Sam Altman 给出了另一方的叙述。Simon Willison 的立场我很认同：数学证明本身可以争论，但被 Lean 机器校验过的形式化结果确凿无疑。

对 4sapi 上的开发者来说，真正值得抄作业的不是"解出千禧年难题"，而是这组数字背后的工程事实：490 万条消息意味着消息轮次已经爆炸到人类无法逐条审查的规模；3000 亿输出 token 意味着成本结构必须靠架构来控制，而不是靠事后买单。下面我把这套长任务架构拆成可复用的教程。

三、原理速览：任务分解 → 子智能体消息矩阵 → 汇聚验证

长任务智能体系统的骨架只有三步：任务分解、子智能体协作、汇聚验证。图示如下：

总任务：证明 Navier-Stokes 方程解的整体存在性与光滑性
  │  ① 任务分解（主智能体拆解）
  ├── 子智能体 A：PDE 先验估计与能量估计
  ├── 子智能体 B：blow up 反例搜索与构造
  ├── 子智能体 C：边界条件与正则性分析
  │  ② 消息矩阵（A↔B↔C 互传结论、互相质疑、修订）
  │  ③ 汇聚
  └── 主智能体：汇总全部中间结果
        │  ④ 汇聚验证
        ├── 生成阶段：产出 Lean 证明脚本（推理模型，token 大户）
        └── 校验阶段：GPT-6 Astra + Lean 编译器逐条检查（确定性兜底）
              └── 机器校验通过 → 结论确凿，可交付

三步里每一步都有各自的成本陷阱。任务分解如果粒度太粗，子智能体各自为战，汇聚阶段要花大量 token 弥合矛盾；消息矩阵如果放任自由转发，上下文会以平方级速度膨胀；汇聚验证如果只靠模型自查，错误会层层叠加，最后还得重跑整个生成阶段。下面按成本构成逐个拆。

四、长任务成本构成表

先把长任务的账单按来源拆开，我用相对倍数描述经验占比，不编造任何未公布的精确单价：

成本构成	触发机制	经验占比（相对倍数）	优化手段
上下文重读	每轮把累积历史整体重喂，输入随轮数线性膨胀	最大头，单轮输入可达首轮数倍到十余倍	消息合并、历史摘要、分片上下文
消息矩阵转发	子智能体互相传递中间结果，数量按智能体数平方级增长	中高，可占总量两三成	结构化通信、只传结论不传过程
轮次往返	收敛慢、反复修订，输出 token 反复消耗	中，占总量两三成	轮次上限、早停判定、结果缓存
失败重试	校验失败或超时，整段或整轮重跑	放大器，总量再乘 1.5–3 倍	降档重试、幂等缓存、退避
形式化校验	生成校验脚本 + 编译迭代，反复试错	较低但集中，占总量一成上下	小步验证、先小规模样例再全量

表格想传达的核心只有一句：长任务的成本大头不在"最后一次聪明输出"，而在"反复重读、反复转发、反复失败"。四个优化手段里，前两个省的是输入侧，后两个省的是输出侧，下面逐个用代码落地。

五、Python 示例：轮次限制与预算闸门

先把最基础的两道闸装上：轮次上限防死循环，预算闸门防账单失控。这套编排我在 4sapi（https://4sapi.com）上按真实长任务压测过，结构如下：

python

from openai import OpenAI

# 4sapi 合法中转接入：统一 OpenAI 兼容协议
client = OpenAI(
    api_key="sk-4sapi-xxxx",          # 在 4sapi 控制台申请
    base_url="https://4sapi.com/v1",  # 中转端点
)

MAX_ROUNDS = 8                # 单智能体轮次上限
BUDGET_OUT_TOKENS = 2_000_000 # 全局输出预算闸门（输出侧）

class BudgetExceeded(Exception):
    pass

def run_agent(task: str, model: str) -> str:
    messages = [{"role": "user", "content": task}]
    total_out = 0
    for round_no in range(MAX_ROUNDS):
        resp = client.chat.completions.create(
            model=model,
            messages=messages,
        )
        used = resp.usage.completion_tokens
        total_out += used
        if total_out > BUDGET_OUT_TOKENS:
            raise BudgetExceeded(round_no, total_out)
        # 轮次内业务逻辑：把新结论写回 messages，或分发给其他子智能体
        messages.append({
            "role": "assistant",
            "content": resp.choices[0].message.content,
        })
    return messages[-1]["content"]

要点：MAX_ROUNDS 与 BUDGET_OUT_TOKENS 必须是全局共享的，不能每个子智能体各自为政——我见过最惨的翻车就是 20 个子智能体各自设了 100 万 token 预算，合计直接超了 20 倍。预算闸门只数输出 token 不够，输入侧的膨胀由下一节的消息合并兜住。

六、Python 示例：消息合并与上下文压缩

上下文重读是长任务的第一大成本来源。做法是保留最近 N 轮完整消息，把更早的历史交给便宜模型压成摘要，塞进 system 消息，让强模型只面对精华：

python

KEEP_RECENT = 4              # 保留最近几轮原文
SUMMARY_MODEL = "cheap-summarizer"  # 便宜的摘要档

def merge_history(messages, client):
    if len(messages) <= KEEP_RECENT * 2 + 1:
        return messages
    old = messages[: -(KEEP_RECENT * 2 + 1)]
    recent = messages[-(KEEP_RECENT * 2 + 1):]
    dump = "\n".join(m["content"] for m in old)
    summary = client.chat.completions.create(
        model=SUMMARY_MODEL,
        messages=[{
            "role": "user",
            "content": (
                "把下面的历史压缩成 300 token 内的要点，"
                "保留关键结论与已排除的错误路线：" + dump
            ),
        }],
        max_tokens=300,
    ).choices[0].message.content
    return [{"role": "system", "content": "历史要点：" + summary}] + recent

要点：摘要本身也要花钱，所以合并频率要按轮次阈值触发，而不是每轮都压；摘要档用便宜模型，让"遗忘"这件事的单价远低于"记忆"的单价。消息矩阵同理——子智能体之间只传结论与证据引用，不传完整推理过程，转发量立刻从平方级掉回线性级。

七、Python 示例：失败降档重试

长任务里失败是常态，不是异常。硬着头皮用最强模型反复重试，等于给放大器持续供血。正确姿势是降档重试：失败先指数退避，再用便宜档快速重试；只有便宜档反复失败、确认是"难题"时，才把预算花到强模型上：

python

import time
from openai import OpenAI, RateLimitError

MODEL_LADDER = ["cheap-fast", "mid-balanced", "strong-reasoner"]

def call_with_retry(messages, ladder=MODEL_LADDER, max_tries=3):
    last_err = None
    for attempt in range(max_tries):
        model = ladder[min(attempt, len(ladder) - 1)]  # 越重试越便宜
        try:
            resp = client.chat.completions.create(
                model=model,
                messages=messages,
                max_tokens=2048,
            )
            return resp
        except (TimeoutError, RateLimitError) as err:
            last_err = err
            time.sleep(2 ** attempt)   # 指数退避
    raise last_err

要点：降档不是降质量，而是把"高频失败场景"的单价压下去。校验失败同理——Lean 校验报错时，先让便宜档按报错信息修订脚本，修订三次仍失败再上强模型；实测这一条能省下重试放大器中大半的水分。缓存也要跟上：同一子任务的幂等结果直接复用，避免重复烧钱。

八、生成与形式化校验分离的两段结构

这份账单最值得抄的架构，是把"生成"和"形式化校验"拆成两段。88 小时生成阶段用的是推理模型自由探索，token 便宜、允许试错、允许走弯路；17 小时校验阶段用 GPT-6 Astra 配 Lean，把最终结果交给确定性机器逐条检查。两个阶段花的钱完全不成比例，省钱的秘密就在这里：生成端的大规模试错只产生"草稿"，校验端的高单价只作用于"最终产物"。

为什么不能反过来全程强约束？原因在于形式化约束会卡死探索——每走一步都要先证明这一步，token 会以数倍于自由探索的速度烧掉，而且大量烧在注定被推翻的路线上。两段结构把"贵"集中到极少数的收敛点上，让不确定性只在生成端存在，确定性只在交付前出现。Simon Willison 那句判断放在这套架构里正好：生成端允许争议，校验端保证确凿。

我接长任务时的默认姿势就是这样：生成用开放式编排，把候选结果批量产出；交付前一律过一遍机器校验，校验不通过就带着报错信息回炉，通过才允许进入下一层。人工只抽检结论与边界情况，不逐行审——这既是成本策略，也是可信度策略，因为机器校验过的部分比人眼扫过的部分更靠得住。

九、成本与风险提示

先讲合规：4sapi（https://4sapi.com）只做合法接入与成本优化，不提供任何违规代理服务，上述所有做法都以正常付费 API 为前提。

再讲风险，两点足够。第一是成本失控。三个放大器叠加：上下文线性膨胀、消息矩阵平方级增长、失败重试成倍放大。对策只有一个字：闸。轮次闸、预算闸、合并闸、重试闸，四道闸全部做成全局共享的硬限制，并让每道闸都写审计日志——每轮用了哪个模型、多少输入 token、多少输出 token、谁触发了降档、谁触发了合并，全部留痕。账单异常时，审计日志能直接定位到具体子智能体和具体轮次，而不是对着总账单猜。断点续跑同样重要：中间任何阶段崩溃，都从最近检查点继续，而不是整段重来。

第二是泄密与对抗叙事的风险。这次事件里关于研究路线泄露的指控与反驳，一句带过：多智能体系统里"信息从哪里来、谁把什么喂给了谁"同样需要留痕，否则连争论都无从谈起。风险提示点到为止，重点是让长任务的每一步都可审计、可回放、可复现。

十、验收清单

给长任务跑 API 前，我按下面这张清单逐项过，全绿才放行：

[ ] 每个子智能体都有独立且全局共享的轮次上限，无死循环可能
[ ] 全局输出预算闸门生效，超支即中断并告警
[ ] 历史消息按轮次阈值触发合并，摘要档用便宜模型
[ ] 子智能体间只传结论与证据引用，不传完整过程
[ ] 失败重试走降档阶梯 + 指数退避，幂等结果走缓存
[ ] 生成与校验分账核算，校验阶段单独设预算
[ ] 审计日志记录每轮模型、输入/输出 token、降档与合并事件
[ ] 最终产物必须过机器校验（Lean 或其他形式化工具），人工只抽检
[ ] 中途任何阶段可断点续跑，不因单点失败推倒重来
[ ] 上线前用 1/100 规模的样例任务压测成本模型，验证估算与实测的偏差

清单看着琐碎，每一条对应的都是账单上的真金白银。规模小的时候少几条也无妨，一旦任务跑到几十小时、几百万条消息，缺任何一条都可能让总成本再翻一个数量级。

十一、总结

长任务智能体的成本问题，本质是架构问题：轮次不设限、消息不合并、失败不降档、生成与校验不分家，四件事叠加起来，就是 490 万条消息、3000 亿 token 这种量级的账单；反过来把四道闸装齐，把"生成-形式化校验"的两段结构做成默认姿势，成本下降是数量级的。这次新闻里的争议留待时间检验，但被 Lean 机器校验过的部分确凿无疑——这本身就是长任务架构最好的注脚。我这边（4sapi，https://4sapi.com）继续盯着这条赛道上的成本曲线。评论区聊聊：手头跑过最长的任务，账单最后是多少？