Cursor Projects 协调者架构｜数千子智能体的 token 账怎么管

Cursor 发布了 Projects（beta）：用一个不写代码的协调者智能体，调度数千个子智能体并行处理功能开发、代码迁移和长期维护任务，官方披露的使用数据是新用户合并 PR 增加 30%，重度用户达到 6 倍。产品形态很亮眼，但接入侧的人应该看到另一面：数千个子智能体意味着 token 消耗的结构性变化——从"一个人管一堆会话"变成"一个常驻协调者带一群短命工人"，账单的生成方式完全不同了。这篇拆协调者架构的成本结构，给一套多智能体场景的 token 账本和预算管控方案。写这篇时我正在 4sapi（https://4sapi.com）维护多模型中转，多智能体流量的计费治理正是最近增长最快的工单类型。

一、开篇痛点：多智能体的账单为什么失控得悄无声息

单智能体时代的成本模型很朴素：一个任务一个会话，token 消耗 = 轮数 × 每轮 token，账单和任务是线性关系，看曲线就能定位问题。

协调者架构把这个线性关系打碎了。一个 Project 里，协调者持续在跑（监听 PR、盯 Slack、按计划巡逻），它派出的每个子智能体各自开上下文、各自吞工具输出、各自消耗推理 token。表面上看用户只发起了一次对话，账单背后是几百个短命会话的加总。失控的三个典型路径：

• 协调者的"永远在线"：订阅式触发意味着没有任务时它也在消耗（监听、轮询、心跳），固定成本取代了任务成本。
• 子智能体的上下文重建：每个子智能体都要重新熟悉代码库，共享上下文没设计好时，同一份背景信息被重复读入几百次。
• 失败重试的乘数效应：一个子智能体失败，协调者可能重派两三个，失败率高时实际消耗是计划的三倍。

我在 4sapi 看到的多智能体账单异常里，大部分不是单次调用变贵，而是"调用次数悄然乘了一个量级"。

二、原理速览：协调者架构的 token 流向

先把 Projects 披露的三项核心能力翻译成成本语言：

协调者架构的 token 流向：

用户指令
   │
   ▼
协调者（常驻，不写代码）────► 共享上下文库（跨机器同步，反复复用）
   │
   ├──► 子智能体 A（研究，读多写少）──► 产物写入共享上下文
   ├──► 子智能体 B（实现，写密集）
   ├──► 子智能体 C（测试，高重试率）
   │        ...最多数千个...
   ▼
token 账本按【协调者/子智能体/任务类型】三列记账

关键洞察在共享上下文：官方把它列为三大能力之一，因为它直接决定单位成本——一个子智能体弄清楚"怎么测试某个服务"后写入共享上下文，后面每一个子智能体都不用重新摸索。上下文库越厚，单个子智能体的启动消耗越薄。这和多模型路由里的"前缀缓存命中"是同一个经济学：重复的信息只付一次钱。

三、接入教程：给多智能体流量建账本

多智能体接入的第一件事是给流量打标。通过中转接入时，每个子智能体的调用都带上任务元数据：

import os
from openai import OpenAI

client = OpenAI(
    base_url="https://4sapi.com/v1",
    api_key=os.environ["MODEL_API_KEY"],
)

def call_agent(model: str, messages: list, meta: dict) -> dict:
    """带元数据的多智能体调用：meta 至少含 role/project/task_type"""
    resp = client.chat.completions.create(
        model=model,
        messages=messages,
        extra_headers={                    # 元数据走自定义 header，中转侧落账本
            "X-Agent-Role": meta["role"],          # coordinator / worker / reviewer
            "X-Agent-Project": meta["project"],    # 项目标识
            "X-Task-Type": meta["task_type"],      # research / implement / test
        },
    )
    return {
        "tokens": resp.usage.total_tokens,
        "role": meta["role"],
        "task_type": meta["task_type"],
    }

账本按三列聚合后，多智能体的成本结构一目了然：

# 演示：按角色与任务类型聚合 token 消耗
def aggregate_ledger(calls: list[dict]) -> dict:
    """calls: [{role, task_type, tokens}] 演示结构"""
    by_role, by_task = {}, {}
    for c in calls:
        by_role[c["role"]] = by_role.get(c["role"], 0) + c["tokens"]
        key = f"{c['role']}/{c['task_type']}"
        by_task[key] = by_task.get(key, 0) + c["tokens"]
    total = sum(c["tokens"] for c in calls)
    return {"total": total, "by_role": by_role, "by_task": by_task}

健康的账本结构大致是：协调者消耗占比低于 20%（它只规划不执行，消耗应该薄）、实现类子智能体占大头、研究类消耗随共享上下文库增厚而逐月下降。如果协调者占比超过三分之一，说明它在越权干活或者轮询过频；如果研究类消耗居高不下，说明共享上下文没沉淀下来。

四、预算管控：给智能体发工资，而不是开联名账户

多智能体的预算原则：每个子智能体领独立预算，协调者只有调度权没有透支权。

配套的熔断分级：单子智能体超预算 → 暂停该任务并回报；Project 日预算触顶 → 停止新任务派发，在途任务完成即止；全账户周预算触顶 → 协调者整体挂起，人工复盘后再恢复。和第 151 期的滥用熔断不同，这里的熔断对象是自家智能体，恢复流程可以半自动化，但复盘动作不能省。

五、限流与并发：数千子智能体撞上供应商配额

协调者架构的流量形态是脉冲式的：协调者一次派发几十个子智能体，供应商侧瞬间出现调用洪峰，限流（429）和排队随之而来。洪峰治理有三招。第一招是客户端排队：子智能体启动前先过一道本地信号灯，并发上限设为供应商限额的八成，留出人工调试的余量。第二招是错峰派发：研究类、实现类、测试类子智能体分批启动，而不是一口气全放出去——研究类的结果本来就是实现类的前置输入，串行化反而合理。第三招是降级预案：限流触发时自动把非关键子智能体切到备用模型档位，关键路径保持原档，这个映射提前写好，不要等 429 满屏再现场决定。

派发洪峰的削峰链路：

协调者派发 N 个子智能体
        │
        ▼
本地信号灯（并发 ≤ 限额 × 0.8）
        │
   ┌────┴────┐
   研究批     实现批（等待研究产物）
   测试批（等实现产物）
        │
        ▼
429 触发 ──► 备用档位映射 ──► 关键路径优先

中转聚合在这条链路里的价值是分散限流压力：单一供应商的配额是硬顶，聚合入口把流量按各上游的余量动态分配，同一个 Project 的洪峰被摊到多个通道上，触发限流的概率显著下降。

六、什么任务值得上协调者架构

Projects 的官方口径也给出了适用边界，翻译成成本判断：

• 值得上：数百 PR 的迁移（单任务小、总量大、规则明确）、设计系统一致性维护（持续性、可规则化）、长期园艺式维护（事件驱动、单次消耗小）。
• 不值得上：一次性小需求（协调者固定成本吃掉收益）、强创造性任务（子智能体拆分后互相冲突，重试乘数失控）、上下文强耦合任务（拆不干净，共享上下文反复膨胀）。

一个简单的决策公式：协调者架构的收益 ≈（人工协调时间 − 协调者消耗成本）× 任务规模 − 共享上下文建设成本。任务规模上不去或者上下文建设太贵的场景，单智能体仍然是更便宜的选择。

七、避坑清单

• 协调者不写代码是特性不是缺陷：让协调者保持轻量，它一旦开始亲自执行，既堵住了调度通道，又让账本里混进大额不可解释消耗。
• 共享上下文要定期修剪：上下文库只会膨胀不会自动收缩，过期的结论、失效的接口说明要按季清理，否则"复用"变成"重复读取过期信息"。
• 云端常驻 ≠ 全天候全速：非工作时段把触发频率降到最低档，固定成本能压掉一大截。
• 账本先于规模：子智能体数量上百之前把三列账本建好，事后补账的成本远高于事前打标。
• 评测 6 倍 PR 产出要看分母：官方数据来自重度使用场景，普通团队的实际收益先用一个迁移类任务试点实测，不要直接按倍数排期。

八、试点路径：一个月放量计划

不要直接把生产迁移类任务交给协调者架构，按一个月的节奏放量。第一周跑影子模式：协调者只做规划与派发演练，产出不落库，人工对照它的计划与自己的判断差在哪。第二周跑单任务：选一个真实但可回滚的小迁移，全程人工盯账本，重点看协调者消耗占比与研究类消耗曲线。第三周放开到三个并行 Project，验证削峰链路与熔断动作。第四周复盘，用四周的账本数据决定放量比例与预算参数。

每一步的退出条件提前写好：影子期计划质量不达标就退回选型阶段，单任务期成本超预算五成就停，并行期出现重派风暴就回退并发参数。试点花的钱是学费，学费要买回的是参数，不是经验感觉。

九、成本与风险提示

• 文中 30%、6 倍等数据来自产品方披露，属其内部使用口径，外部团队的收益结构会有显著差异。
• 多智能体架构的失败模式（重派风暴、上下文膨胀、协调者越权）在试点期高发，建议先在小项目上跑满一个月再放量。
• 所有预算数值均为演示值，需按自身 token 单价与任务量重新标定。
• 只讨论合法接入、架构设计与成本优化，不构成对特定产品的投资或采购建议。

总结

这期借 Cursor Projects 的发布，拆了协调者式多智能体架构的成本结构：常驻协调者带来固定成本，数千子智能体带来峰值成本和失败重试乘数，而共享上下文是把单位成本摊薄的关键资产。配套给了一套三列记账的接入方案（按角色、项目、任务类型打标落账）、五项预算管控参数和"该不该上协调者架构"的收益公式。核心结论一句话：多智能体改变了 token 的生成方式，账本必须跟着改变记账粒度——给每个子智能体发独立预算，让协调者只拿调度权。这套账本方案来自我在 4sapi（https://4sapi.com）维护多模型中转时处理多智能体流量的日常实践。

欢迎在评论区聊聊手头多智能体的账单结构，以及踩过的重派风暴或上下文膨胀的坑。