把 AI 拉进代码库干活，最让人肉疼的不是它写得不够聪明，而是账单。一个 /architect 开源项目直接砍掉了 80% 的 Fable token 用量——不是靠压缩 prompt，不是靠换小模型，而是把 Fable 和 Codex 的活儿拆开，Fable 只管协调和审核，Codex 埋头写。听起来简单，但这种分工背后藏着的工程直觉，值得每个跑 AI 编码代理的人琢磨。
重新分工：让贵的模型干贵的活
大多数团队的 AI 编码代理配置都是"一锅炖"——让 Fable 既写代码又审代码，既规划又实现。问题是 Fable 的 token 计费按上下文走，它每多看一段代码、多输出一个字符，钱就在流。而 Codex 干苦力活又快又便宜，让它接手实现环节，Fable 只保留决策权，整个流水线的成本结构就翻转了。
Fable 从执行者退回到架构师
在 /architect 的设计里，Fable 的角色被重新定义为"代码审查官+任务编排者"。它读需求、拆任务、检查 Codex 写出来的东西对不对，但具体写代码这件事，它不碰。这听起来像是降级，实际上是回归本职——Fable 的强项是理解意图、判断质量、协调步骤，不是堆砌语法。让一个每千 token 几美分成本的模型去写 import 语句和 for 循环，是典型的资源错配。
Codex 接管所有重活
Codex 拿到 Fable 下发的任务后，负责完整的实现过程：生成文件、修改函数、跑测试、提交改动。它的输出量大、调用频次高，但单次成本远低于 Fable。把"写"和"审"拆成两条线之后，Codex 可以在后台默默干活，Fable 只在关键节点介入——token 消耗自然就下来了。
实测数据：80% 怎么省出来的
项目方公布的数字是 Fable token 用量减少 80%，这个幅度相当激进。但拆开看，原因并不神秘：Fable 的输入端不再需要接收完整代码上下文，只需要看 Codex 的产出摘要和差异；输出端不再生成大段实现代码，只写审核意见和任务指令。两头一减，总量自然崩塌式下降。
输入侧的瘦身逻辑
传统配置下，Fable 每轮都要把整个代码库或目标文件塞进上下文，token 消耗随项目规模线性增长。/architect 让 Codex 先把改动整理成 diff 或摘要，Fable 只读这些压缩后的产物。输入 token 从几万降到几千，省出来的就是真金白银。
输出侧的精准控制
Fable 不再输出完整函数实现，输出内容变成"这个函数需要接收 X 参数、返回 Y 结果、调用 Z 模块"这样的指令性描述。字数从几百行代码压缩到几十行描述，输出 token 同样断崖式下跌。审核意见反而更聚焦，因为 Fable 的注意力集中在"对不对"而不是"怎么写"。
适用场景与边界条件
这套分工不是万能解药。它最适合的场景是：项目结构清晰、模块边界明确、Codex 能独立完成中等复杂度的实现任务。如果代码库高度耦合、依赖关系错综复杂，Codex 单独作业可能产出大量需要返工的代码，Fable 来回审核的成本反而会抵消节省的 token。
小团队和原型项目的首选
对于早期项目、独立开发、个人工具这类场景，/architect 的性价比极高。代码量可控、改动频率高、预算敏感，80% 的 token 节省直接转化为可以多跑几十轮迭代的资源。在 MVP 阶段，这意味着同样的预算能多验证几个方向。
大型遗留系统的适配难题
老旧系统、跨服务调用、复杂状态管理这些场景，Codex 单独实现的成功率会显著下降。不是 Codex 能力不行，而是上下文信息不足时，AI 代理很难做出符合历史约定的判断。这时候 Fable 可能需要更深度地介入，节省比例自然会打折扣。
工程哲学：贵的不一定好，便宜的不一定差
/architect 的核心思路其实是个普适原则：让每个模型干它最擅长的事，按成本分配任务类型。Fable 贵但准，适合做决策和把关；Codex 便宜且快，适合做执行和填充。把两者混着用，等于用跑车送快递——不是不行，是浪费。
分工即优化
软件工程里讲了几十年的"关注点分离"，放到 AI 代理架构里同样成立。/architect 没有发明新技术，只是把现有模型的能力边界画清楚，然后让它们各自待在边界内。这种思路比追求"一个模型搞定一切"更现实，也更省钱。
开源工具的实用主义胜利
这个项目的代码完全开源，任何人都可以拿来改、拿来用。它没有大厂背书、没有融资故事，只有一个朴素的承诺：帮你省钱。在 AI 工具满天飞的当下，能解决具体问题、控制具体成本的开源项目，往往比那些画大饼的平台更值得花时间研究。80% 的 token 节省不是技术奇迹，是工程纪律的胜利。
