AI 编程代理的下一个战场：从「聊着写」到「编排式开发」

Sun, 05 Jul 2026 10:00:00 +0800

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 写代码。

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

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

Agentic Orchestration on Codexer

AI 编程代理的下一个战场：从「聊着写」到「编排式开发」

聊天模式的三个天花板

编排式开发的核心思想

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

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