Architect Mode：多 Agent 流水线的演进之路

背景

AI 辅助编程正在改变软件开发的方式，但有一个核心矛盾始终存在：AI 的上下文窗口是有限的，而真实项目的复杂度是无限的。

当我们让 Claude Code 开发一个完整的全栈项目时，对话很快就会变得臃肿。早期的工作方式很简单——在同一个会话中不断地提出需求、让 AI 生成代码。这种方式在小脚本或单文件场景下工作得很好，但一旦涉及以下情况，问题就暴露无遗：

• 需要同时理解前后端多个模块的代码
• 需求在多轮对话中逐步演进
• 需要保证代码风格和架构的一致性
• 开发过程中需要反复切换上下文

这就是 Architect Mode 诞生的背景——它不是为了解决某一个具体问题，而是在多个项目的实践中渐进式演化出来的产物。

来龙去脉：从简单到复杂的三次演进

第一阶段：单会话协作

最原始的工作方式就是在一个 Claude Code 会话中完成所有工作。这种方式的好处是简单直接，但随着项目规模的增长，问题越来越明显：

• 对话越长，AI 的推理质量越差
• 前后端代码挤在同一个上下文中，互相干扰
• 无法并行工作，所有任务串行执行
• 一旦会话崩溃，进度全部丢失

第二阶段：引入子任务分离

为了解决单会话的瓶颈，我开始尝试将任务拆分到不同的子会话中执行——这就是 Subagent 的雏形。具体做法是：

• 将大任务拆成多个独立的小任务
• 每个小任务在独立的子会话中执行
• 子会话返回结果摘要，而非完整对话
• 主会话只负责编排和整合

这种方式带来了一定的改善，但很快又遇到了新的问题：没有统一的质量标准和审查机制。不同子会话生成的代码风格不一致，架构设计缺乏全局视角，接口对齐全靠人工检查。

第三阶段：Architect Mode 的诞生

在经历了多次项目迭代后，一个完整的流水线设计逐渐成型。我从软件工程的传统实践中汲取灵感——正如人类团队需要产品经理、架构师、开发者和测试工程师的分工协作，AI 编程也需要类似的角色分工。

于是 Architect Mode 诞生了：一套 6 角色 × 3 阶段的多 Agent 流水线。

架构设计

角色分工

三阶段流程

Phase 1 ──────────→  Phase 2 ──────────→  Phase 3 ──────────
Architect → Planner   Implementer × N      Reviewer → Tester
     ↓                    (并行)                ↓
  PLAN.md                                    Security Auditor
     ↓                                         ↓
  /compact                                  Test Report

Phase 1 — 架构与规划：由 Architect 输出完整的架构方案（PLAN.md），Planner 将其拆解为颗粒度合适的 Task 列表，并标注依赖关系和复杂度评估。

Phase 2 — 并行实现：多个 Implementer 通过 isolation="worktree" 在独立的代码副本上并行开发，互不干扰。每个 Implementer 完成后只返回摘要，避免详细对话积累到主会话。

Phase 3 — 审查与质量保障：Reviewer 对代码进行多维度审查，Tester 补充集成测试，Security Auditor 检查安全风险。

上下文管理策略

Architect Mode 内置了四层上下文防护机制：

1. Implementer 使用 worktree 隔离 — 子 Agent 的详细对话不会积累到主会话
2. 阶段切换前执行 /compact — 压缩历史释放上下文窗口
3. 状态持久化到 STATUS.md — 确保压缩不丢失进度
4. Agent 返回摘要而非完整记录 — 缩减每次子 Agent 返回的数据量

此外，还内置了**安全手断（Safe Cut）**流程：当检测到上下文压力信号（超过 50 轮对话、响应变慢、刚完成 Implementer 批次）时，自动保存状态、执行 /compact，必要时引导用户新开会话继续。

优缺点分析

优点

1. 任务隔离提升专注度

每个 Implementer 在自己的 worktree 中工作，不会受到其他任务的干扰。这意味着 AI 可以在一个干净、专注的上下文中完成特定功能，推理质量更高。

2. 质量保障闭环

从架构设计到代码实现，再到审查和测试，形成了一个完整的质量闭环。Reviewer 会从正确性、代码质量、完整性、效率、安全性五个维度打分，并标记问题的严重等级（critical/major/minor）。

3. 进度可追踪

通过 STATUS.md 和 Task 列表，任何时候都可以清晰地知道当前进展：哪些任务已完成、哪些在进行中、哪些被阻塞。即使会话崩溃，新会话也能快速恢复。

4. 并行效率提升

无依赖的任务可以同时启动多个 Implementer 并行开发，充分利用 AI 的计算资源，缩短整体开发时间。

5. 跨会话恢复能力

这是 Architect Mode 的一个重要设计目标——会话可能因为各种原因中断（上下文溢出、网络问题、模型切换），有了状态持久化机制，新会话可以在毫秒级恢复进度。

缺点

1. 上下文仍有瓶颈

这是最核心的局限性。尽管 Architect Mode 做了大量的上下文优化——worktree 隔离、/compact、摘要机制——但它无法突破模型的物理上下文上限。在 128K 上下文的时代，一个稍具规模的全栈项目（十几个后端接口 + 前端界面）就足以让会话不堪重负。这一瓶颈最终通过升级 1M 上下文的 deepseek-v4-flash 得以解决。

2. 对于小项目过于重量级

如果只是写一个脚本、修复一个 bug 或者做一个简单的 API 接口，走完整个 6 角色 3 阶段的流水线确实有些杀鸡用牛刀。对于这类场景，直接对话反而更高效。

3. 阶段切换的开销

每次阶段切换都需要执行 /compact 和状态同步，虽然这些操作用时很短（通常在几秒内），但在频繁迭代的场景下，累积的时间成本也不容忽视。

4. 对 PLAN.md 质量敏感

Architect Mode 的质量很大程度上取决于 Phase 1 输出的 PLAN.md 质量。如果架构设计存在偏差或遗漏，后续的实现和审查都会受到影响——这一点和人类软件工程团队完全一致。

生产级效果

经过多个全栈业务系统的实战验证，Architect Mode 在以下方面表现出了生产级的能力：

代码质量

Reviewer 机制确保了代码在合并前经过多维度审查。在实际使用中，大部分 critical 和 major 级别的问题都能在审查阶段被发现和修复，进入生产环境的代码质量显著高于无审查流程的 AI 生成代码。

架构一致性

因为有 Architect 角色在 Phase 1 统一规划，所有 Implementer 在同一个架构框架下工作，代码风格、接口约定、数据流设计保持了高度一致。这避免了多个 AI 子任务各自为政、代码风格割裂的问题。

效率对比

相比单会话开发模式，Architect Mode 在以下场景中效率优势明显：

适用场景总结

• 最适合：全栈业务系统开发、中大型功能模块开发、多人协作的 AI 开发流程
• 较适合：需要严格质量控制的代码生成、需要架构先行的工程项目
• 不适合：简单脚本、单文件修改、快速原型验证

总结与展望

Architect Mode 的核心思想并不新鲜——它借鉴了传统软件工程中经过验证的实践：架构先行、任务拆解、并行开发、代码审查、自动化测试。只是将这些实践适配到了 AI 编程的语境中。

这套流水线证明了，AI 辅助编程可以从”写代码的助手”进化为”参与完整开发流程的协作者”。角色分工和流程规范带来的收益，远远超过了阶段切换的额外开销。

当然，它远非完美。上下文窗口的限制仍然是一个需要持续关注的问题，而且随着项目规模的进一步增长，可能还需要引入更细粒度的模块化策略和增量式审查机制。

此外，目前的设计更多是”顺序流水线”——阶段之间是串行的。未来可以考虑更灵活的拓扑结构，比如允许某些审查与实现并行进行，或者在 Phase 1 就启动部分确定性较高的实现工作。

最后，值得一提的是，无论是 Architect Mode 还是其他 AI 编程方法论，最终的目的都不是让 AI 取代开发者，而是让开发者能够驾驭更复杂的项目、交付更高质量的软件。从这个角度看，Architect Mode 只是这条路的一个里程碑，远不是终点。