Claude Code+Codex多智能体系统实测：缓存率98%背后的真问题

一位开发者用 Claude Code 和 Codex 搭建了多智能体开发系统，并公布了7天本地运行数据：Claude Code 的输入/输出 token 比高达 353.9:1，缓存读取占总 token 的 98.23%；Codex 对应数字为 314.7:1 和 96.42%。但作者坦承，这些只是用量指标，并不能证明系统更高效——他真正卡住的是组织调度和输出比例，于是公开向社区求教。

系统长什么样：共享任务协调与验证门

这套系统不只是把两个模型拼在一起。按照作者描述，它包含共享任务协调、结构化交接、验证门和本地用量遥测四个模块。换句话说，Claude Code 和 Codex 各自承担不同环节，中间通过显式约定的格式传递状态，再由验证门决定是否放行到下一步。

这种设计的出发点很明确：让多智能体像流水线一样协作，而不是让两个模型互相聊天。但其代价是，每一次交接都要携带上下文，协调层本身也会消耗 token。作者没有公布协调层的具体开销占比，这恰恰是评估多智能体系统时最容易被忽略的部分。

数据解读：98%缓存率说明什么

先看数字。Claude Code 的缓存读取占总 token 的 98.23%，Codex 为 96.42%。高缓存率通常意味着相同前缀被反复复用，说明工作流存在大量重复上下文——这既可能是系统设计良好的表现（缓存命中省钱），也可能是任务碎片化、每次只推进一点点的信号。

输入/输出比更值得警惕。353.9:1 意味着每生成 1 个输出 token，系统要吞掉约 354 个输入 token。生成输出占总 token 的比例仅 0.282%（Claude Code）和 0.317%（Codex）。作者自己点破了原因：输出比例低是因为系统在实现环节挣扎。这不是模型能力问题，而是编排层没能把任务拆到足够小、足够明确的粒度。

缓存读取（Cache Read） 是大型语言模型 API 中的一种计费与优化机制：当请求的前缀与之前某次请求完全一致时，服务商可以直接复用已计算好的键值缓存（KV Cache），而无需重新运行注意力计算。在 Anthropic 和 OpenAI 的定价体系中，缓存读取 token 的价格通常只有标准输入 token 的 10% 左右，因此高缓存率能显著降低单位成本。但缓存命中要求前缀严格匹配，这意味着智能体工作流中反复发送相同的系统提示、工具定义和对话历史会推高缓存率。反过来，缓存率过高也可能暗示每次只推进极小的增量，导致大量重复上下文被反复读取。

输入/输出比（Input/Output Ratio） 指一次 API 调用中消耗的输入 token 数与生成的输出 token 数之比。在常规聊天场景中，这个比例通常在个位数到几十比一之间；而在智能体工作流中，由于需要携带工具定义、历史记录和检索到的上下文，比例会显著升高。353.9:1 意味着模型绝大部分算力花在处理输入而非生成输出上，这不一定代表低效——如果输入中大量是缓存命中的廉价 token，实际成本可能可控。但过高的比例通常说明任务分解粒度过细，或系统在反复重试同一环节，导致有效产出被稀释。

作者的两个真问题：组织与输出

第一个问题是组织。作者说自己在多智能体调度上挣扎了数月，想更深入问题却始终不得其法。这其实是多智能体系统的通病：任务如何切分、交接协议如何设计、失败后如何回滚，这些工程细节远比选哪个模型更决定成败。

第二个问题是输出比例。系统在实现阶段卡壳，导致大量 token 花在读取上下文和重试上，真正落地的代码产出占比极低。一个直观的对比是：如果一次任务需要 100 次读取才换来 1 次有效生成，那么缓存率再漂亮也只是在优化无效循环的成本。

他向社区提的三个问题

作者的问题很有代表性。其一，这种缓存率和输入/输出比在常规编程智能体工作流中是否典型？其二，大家用什么指标区分“有用的实现”和“智能体在空转”？其三，是否存在公开数据集或可复现基准，能公平比较不同的智能体编排系统？

三个问题层层递进：先确认基线，再定义有效性的度量，最后要求可复现的对比方法。目前业界对智能体系统的评价多停留在任务完成率或人工评分，像成本 per 成功任务、上下文开销、崩溃恢复、人工干预次数这类指标，缺乏统一口径。作者的遥测数据虽然只是自用，但至少提供了一个可讨论的模板。

多智能体编排的共性难题

从这套系统能看出几个共性难题。成本核算不能只看单价，要看每次成功任务的综合 token 消耗，包括协调和重试。上下文开销会随智能体数量线性甚至超线性增长，交接设计不当就会陷入缓存率高但产出低的怪圈。崩溃恢复在多智能体场景下更复杂，一个环节失败可能导致整条流水线重跑。人工干预次数则是最诚实的指标——系统越自主，人越少插手，但前提是验证门足够可靠。

作者的系统在验证门上下了功夫，却仍在实现环节挣扎，说明验证门只能拦截错误，不能替代任务分解。把大任务拆成模型能一次做对的小步骤，可能比增加智能体数量更有效。

验证门（Verification Gate） 是多智能体流水线中的一种质量控制机制：在智能体完成某个环节后，由一个独立的检查步骤（可以是规则引擎、另一个模型或人工审核）判断输出是否满足预设标准，只有通过才允许进入下一环节。它的核心价值在于拦截错误传播，避免一个环节的偏差沿流水线放大。但验证门本身也消耗 token 和延迟，且只能判断“输出是否合格”，无法解决“任务是否被正确分解”这一上游问题。当实现环节反复失败时，验证门会不断拦截并触发重试，进一步推高输入/输出比。

结构化交接（Structured Handoff） 指智能体之间传递状态时采用显式定义的格式（如 JSON schema、固定字段的消息体），而非自由文本对话。它的好处是减少歧义、便于程序化校验和回滚，但也意味着每次交接都要序列化并携带必要的上下文，协调层因此产生额外开销。交接协议设计不当会导致两种极端：字段过多则上下文膨胀，字段过少则下游智能体需要额外读取来补全信息，两者都会推高输入 token 占比。

给同类实践者的参考

如果你也在搭多智能体开发系统，可以从这套数据里抄几个作业：记录每次任务的输入/输出比和缓存率，但别把它们当成绩单；把“每次成功任务的成本”作为主指标；把人工干预次数单独统计；为交接协议写明确的 schema，减少上下文歧义。至于公开基准，目前确实缺少公认方案，社区层面的遥测共享可能是过渡期的现实选择。