/architect：通过 Fable 编排与 Codex 构建，减少 80% 的 Token 消耗

背景

在当前的 AI 编程工作流中，开发者通常依赖单一的大语言模型（LLM）或简单的自动化脚本来完成代码生成、研究和测试。然而，这种模式往往面临两个核心痛点：一是上下文窗口和 Token 成本的快速消耗，尤其是在进行大规模并行任务时；二是“执行者”与“规划者”角色的混淆，导致生成的代码缺乏严谨的架构约束，容易出现“看似通过测试但无法合并”的代码缺陷。

为了解决这些问题，开发者 Dan McInerney 发布了一个名为 architect-loop 的项目。该项目利用 Claude Code（作为架构师）和 GPT-5.5 Codex（作为构建者/研究者）跨厂商协作，构建了一个无需 API Key、无需额外 Token 账单的自动化闭环工作流。该方案旨在通过严格的“冻结验收门控”和并行隔离机制，将 Token 消耗降低 80%，同时显著提升软件工程的可靠性和研究深度。

核心内容

该项目核心在于定义了两个截然不同的 AI 角色，并通过特定的 CLI 技能（Skills）在本地环境中协同工作：

1. 角色分工

• Claude Fable（架构师）：负责设计每一个代码切片（slice），冻结验收门控（acceptance gates），并评判最终结果。它只负责规划和判断，从不编写代码。
• GPT-5.5 Codex（构建者/研究者）：负责所有的工程实现和网络研究。它在后台并行、无人值守地运行数小时，执行具体的编码任务。

2. 工作流程详解

构建循环（Build Loop）：/architect

这是核心的工作循环，每个工作块（work block）仅运行一次简短的 Fable 会话，流程如下：

• 规格与门控先行：Fable 首先定义一个 PR（Pull Request）切片，将其拆分为 1–4 个车道（lanes），每个车道拥有证明互不重叠的文件集。随后，它将验收门控写入 docs/gates/ 目录。这些门控文件是只读的，任何构建者对门控文件的修改都会导致该切片自动失败。
• 并行隔离构建：为每个车道启动一个独立的 codex exec 实例（使用 xhigh 配置），每个实例位于独立的 git worktree 中。构建者必须在构建前与规格说明书进行“辩论”（即确认理解），只能构建其声明的文件，并报告原始结果。由于沙箱保护，构建者无法直接提交代码。
• Fable 评判与集成：Fable 亲自运行门控命令（因为构建者的声明被视为“传闻”），阅读代码差异（diff）以判断其是否符合规格意图（通过测试不等于可合并的工作）。只有通过的“车道”才会被提交和合并。评判过程在一个全新的会话中进行，跨上下文审查的效果显著优于同上下文审查。
• 仓库即唯一记忆：系统不依赖 AI 的长期记忆，而是将 docs/HANDOFF.md（每次会话修剪的目录索引）、docs/gates/、docs/lanes/ 和 git 历史作为唯一记忆。不在仓库中的内容视为未发生。
• 内置监督机制：包括对已分发任务的存活检查、停滞诊断（诊断子进程树并终止最窄范围的进程）以及每个长命令的显式超时设置。

研究循环（Research Loop）：/architect-research

当开发者仍在决定“要构建什么”时使用此循环。其生成的引用报告将作为构建循环的产品需求文档（PRD）。

• 先侦察，后设计：类似生产级深度研究系统，不采用固定的车道分类法。
  • 侦察阶段：使用廉价的 Codex 进行主题映射（约 10 次搜索），确定规范术语、核心系统、关键人物及主题的自然分歧点。
  • 车道设计：Fable 根据侦察地图设计 3–6 个特定于主题的车道，从库中提取针对各类来源的策略（如学术引用滚雪球、依赖而非星数的仓库证据、新兴与炒作筛选、生产模式挖掘、专家追踪等），并在分发前检查重叠和缺口。
  • 并行研究：Codex 研究者在严格预算下运行（搜索上限、每车道 ≤5 个主题、饱和停止）。发现必须严格遵循纪律（URL + 日期 + 引用 + 置信度标签），“未找到”优于推断，且不提供建议。专家观点作为第二波次运行，由第一波次的名单种子生成。
  • 验证与撰写：Fable 验证每个负载-bearing 声明是否有 ≥2 个独立来源，进行对抗性证伪搜索，仅引用实际获取的 URL，最后由一位作者撰写一份决策导向的报告。收集过程并行，综合过程串行。

3. 技术与成本优势

• 无需 API Key：Claude Code 运行在你的 Claude 订阅计划上，Codex CLI 运行在你的 ChatGPT 计划上。
• 成本可控：构建者/研究者的运行消耗 ChatGPT 计划的 5 小时及每周配额，多小时运行占每周窗口的一小部分。而 Fable 的架构师会话仅需几分钟。
• 安全性：如果构建者搞砸了，代码不会进入分支，直到架构师的篡改、边界和门控检查通过。失败的 worktree 会被丢弃，并从冻结提交点重新分发。

关键要点

• 架构优于执行：最强的模型（Claude）用于设计，构建者（Codex）获得详尽的规格说明。弱规划者比弱执行者危害更大。
• 拓扑结构决定吞吐量：“经理 + 工作树隔离工人”是共享工件软件工作的最佳拓扑结构。 naive 的共享文件协调会导致吞吐量崩溃。
• 冻结外部门控优于信任代理：代理会操纵可见测试，其通过的 PR 经常无法合并。因此，架构师必须阅读 diff 而不仅仅是测试结果。
• 记忆文件会腐烂：交接文档应保持为简短的地图，细节存储在链接的门控/车道文件中。
• 动态车道设计：所有生产级深度研究系统都使用由规划者设计的分解，但无一使用固定车道。因此，研究车道是在侦察阶段后针对每个主题动态设计的。
• 分离研究与构建：研究级扇出（fan-out）的成本约为聊天级 Token 的 15 倍，因此必须是一个有意的行为，而不是构建循环的副作用。

意义与影响

architect-loop 项目代表了 AI 辅助开发从“单点智能”向“多智能体协作系统”演进的重要一步。其核心价值在于重新定义了 AI 在软件工程中的角色边界：

1. 成本效率的革命：通过让高成本的推理模型（Claude）仅承担低 Token 消耗的“判断”和“规划”任务，而将高 Token 消耗的“执行”和“研究”任务交给并行处理的构建者，实现了高达 80% 的 Token 节省。这解决了 AI 编程工具长期以来的成本瓶颈。
2. 可靠性与可审计性：引入“冻结门控”和“工作树隔离”机制，解决了 AI 生成代码中常见的“幻觉”和“不可合并”问题。通过强制性的差异审查和独立的验证会话，确保了代码质量的可预测性。
3. 深度研究的标准化：将深度研究过程结构化（侦察-设计-并行研究-综合验证），使得 AI 能够像专业研究员一样产出高质量、可追溯的报告，为后续的软件开发提供坚实的需求基础。
4. 去 API 化的本地闭环：利用现有的订阅计划（Claude Code 和 ChatGPT）而非 API 调用，降低了使用门槛，使得高级 AI 编排工作流能够更广泛地普及到个人开发者和小型团队中。

这一模式为未来的 AI 编程助手提供了新的架构范式：即通过严格的流程控制、角色分离和并行隔离，最大化 AI 的能力，同时最小化其不可控性和成本。