在AI编码代理快速渗透开发流程的当下，token消耗正变得比代码行数更昂贵。虽然OpenAI的Codex能够直接生成代码，但高频率的上下文轮询和冗长的回复使得token开销快速上升，开发者面临“可用的工具，但未必用得起”的尴尬局面。

开源项目/architect给出了一个更具经济性的答案：它将Fable token消耗削减了80%。这并非基于某种粗暴的“缩减采样”或“限制回复长度”，而是通过重新分配角色，让Fable从“写代码”变成“管代码”，由此改变了token的支出结构。Fable作为协调者和审核者，负责拆解任务、设计架构并审核结果；而Codex被降级为纯粹的执行者，专注于具体的代码构建任务。这种分层调度机制，使得最为消耗token的“生成-修改”循环被显著压缩。

从工程角度看，这种拆分背后是对AI能力边界的清醒认知。Codex在代码生成上高效且专精，但在任务规划与多步骤分解中往往会产生冗余内容，尤其是在Agent循环中反复输出相似的上下文和调试信息。而/architect的机制允许Fable以极低的token成本进行“轻调度”：例如，Fable只需输出一份结构清晰的概要，由Codex填充具体实现，再由Fable验证一致性。这种“分而治之”显著减少了Codex在规划阶段的漫游性输出，也避免了频繁的完整上下文重载。

对于使用OpenAI模型构建代码代理的开发者而言，这带来的不仅是成本优化。更重要的是，它提供了一种可复用的架构模式：通过引入一个额外的“管理者”角色，将昂贵模型的“全面通行”替换为了“分任务调用”的劳动分工。这种模式在长周期开发任务中尤为有效，尤其是涉及多文件修改或多步骤重构时，agent循环的“token瀑布”会被有效截断。

当然，这一设计也并非无代价。引入Fable作为中间层必然会引入额外的推理延迟，同时Fable自身的token开销也需谨慎权衡。但按照项目报告的数据，整体80%的降幅已经证明，在大多数足够大的任务上下文中，这种开销是可接受的，甚至可以说是必要的。

对开发者的实用建议是：在构建自己的代码Agent时，不必迷恋“单一模型从引导到生成”的全能幻觉。任务拆分、角色隔离与结果收敛机制，这些软件工程的基本原则，在AI时代依然有效。对于那些已经在基于OpenAI模型搭建自托管代码Agent的团队，/architect是一个可以直接上手的路径——不仅是省钱，更是重构AI生产力单元的工作流程。