2026 年已经过半。如果你在过去半年里用过任何 AI 编程工具——Codex、Claude Code、Cursor、Copilot——你应该已经习惯了一个基本模式：打开终端，描述需求，看着模型改文件，然后你检查、确认、提交。

这种模式解决了很多问题。但它也制造了一个新问题。

问题不在于模型不够聪明。GPT-5.4 能写的代码比大多数初级工程师都好。Claude Sonnet 对大型代码库的理解深度已经超过了很多工作三年的开发者。真正的瓶颈在别处：当需求从"改一个函数"变成"实现一个跨多个仓库的功能"时，聊天窗口装不下所有上下文。

DoorDash 最近开源了一个叫 Agentic Orchestrator 的工具，它的设计哲学直接回应了这个问题。我仔细读完了它的整个 README 和架构设计，这篇文章想和你聊聊它背后的范式转变。

聊天模式的三个天花板#

在理解编排模式之前，先看看聊天模式到底卡在哪。

第一，上下文是单线程的。 你和模型之间的对话历史就是唯一的记忆载体。当你从「实现用户登录」聊到「重构权限系统」再聊到「优化数据库查询」，最后让模型写一个新的 API 时，它看到的是一段可能已经超过 200K token 的聊天记录。前面的关键决策早就被压缩到注意力窗口的边缘了。这不是模型的问题，是聊天这个交互形式的结构性缺陷。

第二，质量检查发生在最后。 聊天模式下，你写完一大段代码才去跑测试、做 review。如果发现架构层面的问题（比如循环依赖或接口设计不合理），代价往往是一大段对话白费。更糟的是，很多时候你会选择「将就改改」，因为推倒重来的心理成本太高了。

第三，无法并行。 一个人的注意力和一个聊天窗口只能同时处理一件事。如果你手上有三个独立的需求，你只能串行——聊完一个、提交、再聊下一个。代码可以并行写，但人不行。

这三个问题不是靠更强的模型能解决的。它们需要的是流程设计。

编排式开发的核心思想#

Agentic Orchestrator 做的事情，本质上就是把一个高层的功能需求拆解成一个多阶段的工程流水线：

KB 构建 → 需求澄清 → 技术调研 → 方案设计 → 路线图规划 → 分阶段实现 → 终审 → 发布

这里面有几个关键设计，值得展开说。

1. 上下文不是聊出来的，是建出来的#

这个流水线的起点不是聊天，是知识库构建。在真正动手写代码之前，系统会先扫描整个仓库，自动生成一份结构化的知识图谱：架构约定、API 接口面、依赖关系、测试验证方式。这份 KB 会被缓存，只在代码发生变化时增量更新。

这意味着什么？意味着后面的每个阶段——需求澄清、方案设计、代码实现——都不是在凭记忆工作，而是在读一份经过结构化整理的项目文档。同一个仓库里的后续功能可以复用同一份 KB。你的项目越大，这个设计的价值就越高。

2. 质量关口前置到计划阶段#

传统做法是你写完代码再 review。编排模式的做法是：先让 AI 审查计划，再让 AI 写代码。

具体来说，在路线图规划和阶段计划生成之后，系统会启动多个并行的"计划评审专家"——它们分别从架构合理性、结构完整性、需求覆盖度、安全性、性能、测试覆盖这六个维度独立评分。任何一个评审专家要求修改，计划就会自动迭代。

这个设计背后有一个朴素但深刻的工程直觉：在计划阶段改架构，比在代码写完后重构便宜一百倍。

3. 每个功能拥有独立的 Git 工作树#

Agentic Orchestrator 使用 git worktree 为每个功能创建隔离的工作目录。这意味着：

  • 三个功能可以同时在不同的 worktree 里并行开发
  • 不会出现分支冲突
  • 你的主工作目录始终保持干净，不受影响

如果你曾经因为一个 AI 代理把你的主分支搞得一团糟而抓狂，你应该立刻理解这个设计有多重要。worktree 隔离不仅保护了你的代码，更保护了你的心理安全感——你可以放心让 AI 去试，反正搞不坏主环境。

4. 多 Provider 的显式编排#

一个比较反直觉的做法是：Agentic Orchestrator 不让单一模型包办一切。它把不同阶段分配给不同模型。

比如，规划阶段默认用 Claude Opus（长上下文、强推理），实现阶段也用 Opus，但审查阶段切换到 Codex 的 GPT-5.4（在代码审查基准上表现更好）。研究阶段和数据查询可以用成本更低的模型。用户可以通过配置覆盖每个阶段的模型选择，也可以在运行时动态切换。

这有点像微服务架构的思路：不是找一个全能的单体，而是让不同组件用最适合的工具。

更妙的是它支持 Codex、Claude Code 和 OpenCode 三种 Provider 共存。你可以把 Codex 的审查能力、Claude 的长上下文推理能力和 OpenCode 的本地模型灵活性组合在一起。这种异构编排的设计，比「选一个最好的模型」更贴近实际工程需求。

这对你意味着什么？#

你不需要现在就装上 Agentic Orchestrator——它还很新，学习曲线不低，而且需要同时安装多个 Provider CLI。

但你应该关注的是这个趋势。它指向一个清晰的未来：

AI 编程工具的下一个竞争维度不是「谁的模型更强」，而是「谁能在模型能力之上构建更好的流程编排层」。

一年前我们在比谁的代码补全更快。半年前我们在比谁能在聊天窗口里改更多文件。现在，赛道变了。DoorDash 的这个项目说明，至少有一类工程团队已经在思考：当 AI 能写代码之后，软件工程的流程本身应该怎么重写？

三个值得关注的信号#

除了 Agentic Orchestrator 本身，还有几个信号在印证这个方向：

  1. Claude Code 的 explore → plan → code 三阶段工作流被 Anthropic 官方写进了最佳实践文档。这说明模型厂商自己也意识到了「直接写代码」不是最优路径。

  2. OpenAI 在 2026 年初发布了面向企业的 Agent 编排指南，其中明确推荐了 prompt chaining、orchestrator-workers 和 evaluator-optimizer 等编排模式。这跟 Agentic Orchestrator 的设计思路高度重合。

  3. VibeRaven、143.dev、Cadreen 等一系列独立项目在最近一个月密集出现，它们的共同主题都是「在 AI 编程代理之上加一层编排/治理/记忆」。这不是巧合，是需求在推着工具走。

一个诚实的提醒#

不过我也想泼一点冷水。

编排式开发不是银弹。如果你的日常工作就是「打开终端，和 Claude 聊一个小时，边聊边重构一个模块」，那聊天模式可能更适合你——它的反馈循环更短，心智负担更低。强行切换到编排模式反而会因为过多的的阶段切换拉低效率。

编排模式最适合的场景是：需求明确但复杂度高、涉及多个模块或仓库、需要可复现的质量标准。简单说，当一个功能大到你不能在一次对话里搞定的时候，编排的价值才开始体现。

写在最后#

2024 年到 2025 年，AI 编程工具的叙事主线是「替代」。工具在替代搜索文档、替代写样板代码、替代改 bug。2026 年开始，叙事在悄然转向「编排」——不是让 AI 替代人的哪个环节，而是让人和 AI 以更高效的方式合作完成一个完整的功能周期。

DoorDash 开源 Agentic Orchestrator 是一个信号。信号的内容不是「这个工具多好用」，而是「有人已经在用工程化的方式解决 AI 编程的组织问题了」。

我们正在从「AI 能写代码」走向「AI 能参与工程」。这个转变的意义，可能比 GPT-5 的发布更大。

参考来源：