我暂停了一个 AI 项目：架构图里没有的缓存账单

2026-09-19 · agents, jev, prompt-caching, engineering, 产品复盘

从 Jevis 的 v2 架构到暂停开发：为什么强模型规划、小模型执行的合理分工，仍需通过缓存、交接和返工的完整成本检验。

今天，我给一个准备认真做的 AI 项目按下了暂停键。

它叫 Jevis。名字定了，域名买了，v2 设计规范写了四十多页，整体框架和网站也开始搭了。我们甚至讨论过：不必再纠结功能优先级，决定做，就完整地做。

然后，一个问题把讨论拉了回来：我们这样调度模型，缓存怎么办？

这个问题没有证明多模型协作不成立。它揭示的是，我还没有证明自己的核心承诺成立：在有限预算下，让用户得到更多可靠的交付。

先交代边界：这是一篇设计阶段的复盘，不是性能测试报告。我们没有完成能够支持商业结论的端到端对照实验；以下数字是明确标注的假设算例，不能当作 Jevis 的实测收益或亏损。

这个想法为什么让人兴奋

起点很朴素：顶级模型擅长复杂判断，但价格高、额度有限。大量执行工作似乎不需要最强的模型。如果把架构设计交给顶级模型，把边界明确的实现交给普通模型，是不是可以同时得到能力和效率？

Jev 让这个想法更具体了。TypeSafe 将它定位为输出类型化判断的 System One 模型：给它状态和问题，它返回选择、分数或概率，而不是自由文本。它可以辅助路由和校验，但不能把它当成直接写代码或写摘要的生成模型。来源：TypeSafe 发布说明

于是我们的设想变成：强模型定义正确性，普通模型规模化执行，Jev 辅助传导与验收。

例如，让强模型定义一套接口迁移规则和不可破坏的约束，再让多个执行单元处理不同文件。Jev 在明确的问题上提供信号：实现有没有覆盖约束？是否需要升级处理？当前材料是否与任务相关？动作仍由代码和主 Agent 决定。

这套分工本身，直到现在我仍然认为有价值。

v2 已经相当认真，但认真不等于验证

v2 并不是一张“贵模型做难题、便宜模型做简单题”的路由表。

我们把两个问题放在分工中心：产出会不会被后续工作反复复用？错误能不能被检测出来？一个看起来简单的架构决定，可能影响后面几十项工作；一个很难解析的日志，反而可能有明确、可核验的答案。

原始设计规范第 6 页图 1。它表达设计假设，不代表这些分界已经经过实验验证。

系统被拆成十个模块：任务画像、输入处理、规格生成、调度、执行、状态承载、验收、安全闸、额度治理，以及日志与调优。中心是“承载包”，保存目标、规格、不变量、进度和工作区事实，向不同执行单元投影必要信息。

原始设计规范第 8 页图 2。图内延迟等数字是当时方案的预算或预期，不是本项目测量结果。

我们也考虑了失败升级、权限、任务边界和返工。原文甚至强调：“承载包不是缓存，是这台机器的状态。”这句话在概念上是对的。

问题出在下一步：状态可以交接，并不意味着交接便宜。

承载包解决“下一个执行者应该知道什么”。供应商侧的 prompt cache 解决“这段输入的哪些计算可以复用”。前者是我们维护的工作事实，后者是特定模型与服务条件下的计算结果。把一份 JSON 传过去，不等于把缓存也传过去。

被漏掉的，是已经读过现场的强模型

我们很容易比较两张价格表：强模型每百万 token 贵，普通模型便宜，所以执行任务应该下放。

但长任务进行到中途，比较对象可能已经变了。一边是读过仓库、积累了稳定前缀的强模型；另一边是单价便宜，却需要重新接收任务材料的执行模型。

Prompt caching 复用的是匹配的输入前缀，不是“语义差不多”的记忆。前部内容变化可能减少后续可复用范围；变化之前的稳定部分仍可能命中。新会话不必然全冷，同一会话也不保证一直热。具体行为受模型、缓存作用域、有效期和请求布局约束。来源：OpenAI 缓存文档、Claude 缓存文档

因此，真正应该比较的是：

已经拥有可复用上下文的强模型继续完成任务，与另一个执行模型接收材料、执行、接受检查，必要时再交回强模型，哪个更划算？

缓存把模型选择变成了一个与历史有关的问题。同一个任务交给谁，不能只由任务难度和当前模型单价决定，还要看此前谁已经付过理解现场的成本。

对不同供应商、不同模型，我们不能假设缓存可以直接共享。对子 Agent，也不能仅凭“新开了一个”就断言它一定没有缓存。这两种简单结论都会把账算错。

一个小算例，只用来拆掉错误直觉

假设某强模型普通输入价为 10 个成本单位/百万 token，缓存读取价为 1；某普通模型普通输入价为 2。两边都需要同样的 10 万 token 历史材料。

下一次请求的历史输入部分	假设成本
强模型完整命中已有缓存	0.10
普通模型冷读相同材料，按普通输入计费	0.20
普通模型只接收 1 万 token 的任务切片，按普通输入计费	0.02

这是人为设定的算例，不是任何厂商报价，也不是总任务成本。它不含新增输入、输出、缓存写入、Jev、验证或失败重试；此前已经发生的缓存建设成本，在这个“下一步如何选择”的例子里视为沉没成本。完整任务对照仍须把双方从起点开始的成本全部计入。

算例能说明的只有两件事：便宜模型不一定有更便宜的这一次输入；如果能给它足够小、又不损害完成质量的任务切片，下放仍然可能很划算。

困难恰恰在后半句。如果切片少了一条关键约束，执行者可能重新读文件、重做规划，或者产生需要强模型修复的结果。不能先假设切片无损，再用这个假设证明系统省钱。

压缩上下文，也有一笔回本账

另一个诱人的想法是：让 Jev 挑出没有用的历史，丢掉它们，后续输入就更少。

这可能有效，但“token 变少”不等于“账单变小”。如果删除发生在已被缓存的历史中间，后面一部分缓存可能无法继续复用。第一次请求的重建成本、压缩判断成本，以及遗漏信息后重新取证的成本，都要与未来节省相比较。

OpenAI 的当前文档明确提醒，compaction 可能降低下一次请求的缓存复用，但更短的上下文仍可能降低总成本。它也区分模型代际：GPT-5.6 及以后模型的缓存写入按普通输入价的 1.25 倍计费、读取为 0.1 倍，不能沿用“OpenAI 缓存写入一律没有额外费用”的旧印象。来源：OpenAI 缓存文档

Claude 同样区分写入与读取，且缓存时长、模型会影响价格。API 的这些费率，也不能直接当作 Claude 或 Codex 订阅额度的精确扣减公式。来源：Claude 缓存文档

可以用一个简单关系检查压缩是否值得：预计后续各轮节省的成本之和，是否超过判断、改写、缓存重建和预期返工的额外成本？其中“重建”已经计入输入收费，做账时不能再重复加一遍。

如果后面只剩一轮，回本机会可能很小；如果还有许多轮，压缩后又能形成稳定前缀，结果可能完全不同。到了上下文容量上限，还必须比较“不压缩是否已经无法继续”，而不是只比较价格。

同理，筛选尚未进入会话的新工具输出，与反复改写旧历史，是两种不同操作。前者通常更容易保留既有前缀，但仍需证明没有漏掉重要信息、没有为筛选付出更高成本。

更深的问题：我们把待验证的前提写成了模块

回头看，方案里最需要验证的几句话，被我们过早当成了基础条件。

“规格一次生成，可以复用很多次。”前提是任务真的足够同质，规格也足够完整。

“廉价执行有闭合验收。”前提是验收能抓住会影响交付的错误，而不只是给出一个漂亮分数。

“承载包让接班者不必重读现场。”前提是投影足够小，也足够完整。

“Jev 很便宜，所以多判断几次可以忽略。”单次低价不保证整个工作流开销可忽略；调用次数、重复状态、等待和误判都需要测量。

v2 的目标是最大化有限预算下的交付能力，不只是省钱。这也意味着现金支出不是唯一账本。订阅已经付过钱，不代表额度没有机会成本：执行阶段消耗的额度，可能正是后面复杂诊断需要的余量。

我们把系统拆得越来越细，却没有同样细地验证“为什么这些模块组合起来会比原生工作流更好”。

模块边界证明的是系统可以被实现；商业假设需要另一种证据。

如果重来，MVP 应该先验证什么

我会先拿一个现有 Agent 和一组有代表性的真实任务，做三种对照：原生工作流；保留主会话、只外包边界明确的子任务；启用完整的动态编排。

三组使用相同任务起点与验收标准，分别覆盖短任务、长会话和批量重复工作。把冷启动与热缓存情况分开记录；测试顺序也要避免某组碰巧继承另一组预热的优势。不能用一个最好看的案例代替重复试验。

观察单位应是“一个通过验收的任务”，而不是一次 API 调用：总费用、缓存读写量、完成时间、失败与重试、人工修正、最终质量。涉及订阅时，再单独记录可观测的额度变化，不伪造精确美元换算。

测试和规则能够确定的部分，直接验证；需要语义判断的部分，预留人工或独立复核。Jev 给出的高分不能成为证明 Jev 验收有效的唯一依据。

这样，我们可能发现这套分工只适合某类批量任务。那不是坏结果，而是终于找到了产品边界。

为什么今天选择暂停

缓存问题没有在实验室里“击败”Jevis。我们根本还没有完成那场实验。

它击穿的是我继续大规模投入所依赖的确定感：我以为已经想清楚了价值，只剩下工程实现。实际上，最关键的比较基线还没有站稳。

我们随后研究了 Jev 的 skills 和插件。官方已有开发指导 skill，社区也有审查、排序和输出筛选工具。把产品改成插件，可以缩小接管范围，但无法自动消除缓存、误判和维护成本。所以我也没有立即把它换个包装继续做。官方 Skills、Jev Review、jev-pruner

今天的决定是暂停项目，而不是否定 Jev，也不是宣布多 Agent 没有未来。

对我来说，MVP 与现实之间最容易被忽略的距离，是从“这条流程能跑”到“用户值得为这条流程付出成本”。AI 能显著加快前者，也会让我们更快地把未经检验的前提写成完整系统。

下一次，我希望最先交付的东西，是那个可能让我决定不做的实验。

本文基于 2026-09-19 的项目讨论、作者提供的《模型编排器设计规范 v2》及当日核实的官方资料，由 AI 辅助整理与配图。架构图为原始设计节选，封面与两张解说配图为生成的概念插画。没有宣称完成端到端性能测试。

我们也在运营 TopxAI，提供多模型 API 接入，目前已支持 TypeSafe 最新公开版本 Jev 1.13.0（截至 2026-09-19；版本以实时目录为准）。如果你想自己验证 Jev 的判断能力，可以从 Jev 接入指南开始。模型值得探索，工作流的收益值得实测。