用Orchestrator把AI Agent编排成状态机：告别人形确认按钮

从「人形确认按钮」说起

最近用AI编码的人可能都有同感：AI每做完一步就来问你「要不要继续？」，你的回答永远是「可以、可以、可以」。表面上效率很高，实际上你已经退化成了流水线里的一个人形确认按钮。

当前AI编码生态中，Skill负责稳定行为，Subagent负责并行执行，MCP负责连接外部系统——这些能力单点都很强，但大多数人还停留在单点调用阶段，没有把组合能力真正编排起来。

值得一提的是，MCP（Model Context Protocol）是Anthropic于2024年底发布的开放协议，借鉴了编辑器领域LSP（Language Server Protocol）的设计思路——就像LSP统一了编辑器与语言服务器的通信方式，MCP标准化了AI模型与外部工具、数据库、API之间的连接接口，使得「一次实现，处处可用」成为可能。而Subagent架构则将复杂任务分解给专门化的子代理并行处理，前端、后端、QA各司其职，互不阻塞，每个子代理的上下文窗口只包含与其职责相关的信息，既提升速度，也减少干扰。

问题的本质不是流程太慢，而是系统还没学会自己往前走。

用软件工程视角重新看AI编码

转折点在于一个类比：做CI/CD时，我们会设计阶段、设置Gate、用状态机保存状态，也支持并行和断点续跑。既然Agent也是执行单元，为什么不用同样的方法来管理它？

CI/CD（持续集成/持续交付）是现代软件工程的核心实践，经过几十年演进已形成成熟方法论。其底层模型本质上是一个有限状态机：系统在任意时刻处于有限个状态之一（构建中、测试中、待审批、已部署……），通过明确定义的转换条件在状态间迁移，Gate（质量门禁）就是状态转换的触发器。Jenkins、GitHub Actions、GitLab CI等工具将这套理念工程化，积累了大量关于并行执行、失败重试、断点续跑的实战经验。

这个思路一旦打通，Orchestrator的定义就非常清晰了：

• 不创建新Agent，只编排已有Agent
• 不自己写代码，也不亲自跑测试
• 只负责在正确的时间调度正确的Agent和Skill
• 在关键节点等人类做决策

Orchestrator的四层架构设计

整套Orchestrator架构分成四层，职责明确分离：

1. YAML模板：定义流程（Explore → Propose → Review → Implement → QA Test → Archive）
2. Orchestrator Skill：让主Agent可执行编排逻辑
3. Pipeline Server：管理状态和API
4. Dashboard：负责进度、Gate和日志展示

编排逻辑、运行状态和可视化从这里被明确分开。这种分层设计的好处是，每一层都可以独立迭代，不会互相耦合。

其中，YAML模板作为流程定义语言的选择颇具深意。YAML已成为DevOps领域的事实标准配置语言，被Kubernetes、Ansible、GitHub Actions广泛采用。相比代码，YAML降低了非技术人员理解和修改流程的门槛；相比图形化界面，YAML天然支持版本控制，可以像代码一样进行diff、review和回滚。这实现了「流程即代码」（Pipeline as Code）的理念——团队的最佳实践不再口口相传，而是以结构化、可审计、可复用的形式沉淀下来，与基础设施即代码（Infrastructure as Code）的演进路径如出一辙。

Gate机制：从机械确认到质量判断

Gate是整个编排系统的灵魂。它不是每一步都来问你「行不行」，而是让AI先自主推进，只在方案确认、质量审查和测试验收这些关键节点暂停，并给出三个明确选项：通过、修复或放弃。

实战中最能说明问题的场景是：Gate1（方案审查）一旦通过，系统就会自动把Implement阶段标为Active，并行拉起后端和前端的SubAgent。两个实现都完成后，再自动进入下一阶段。整个过程不再需要人一步步盯着往前推。

QA Gate的真正价值

QA Tester跑完后，不是简单输出「通过/失败」，而是给出结构化的报告：哪些项已经没问题，哪些项建议修复，然后把决策权留给人。

这样，人类关注的是质量判断，而不是机械确认。这是一个本质性的角色转变——从操作者变成决策者。

多需求并行与团队协作

当多条需求同时推进时，Dashboard会把每条流水线的阶段、Gate状态、活跃SubAgent和审计日志都放到同一个看板里。它带来的不只是可视化，更是多需求切换时的状态记忆和组织协作能力。

团队协作场景下的放大效应

团队协作场景下，Orchestrator的价值被进一步放大：

• 经验沉淀：高手的经验不再只存在脑子里，而是沉淀成可复用的YAML模板
• 降低门槛：新人沿着流水线前进，在Gate做决策就行
• 模板复用：同一套Agent可以被复用到后端、全栈和Hotfix等不同场景

这意味着团队的AI编码能力不再取决于个人水平，而是取决于流程模板的质量。

AI编码演进的三个阶段

把AI编码的演进总结为三个阶段，可以更清晰地看到Orchestrator所处的位置：

阶段	特征	人的角色
工具调用	单点使用AI能力	操作者
流程固化	固定步骤，逐步确认	确认者
Orchestrator编排	状态机驱动，自主推进	决策者

真正的变化，不是让人一直按确认，而是把航线设好，让AI自动巡航，人只在关键节点接管。

什么时候该用Orchestrator

这套方案的核心洞察其实很简单：AI Agent和微服务一样，都是执行单元，都需要编排。在分布式系统领域，Orchestrator模式（编排模式）与Choreography模式（编舞模式）是两种经典的服务协调方式：编排模式由中央控制器显式指挥各服务的执行顺序，Kubernetes调度器、Apache Airflow、Netflix Conductor都是典型实现；编舞模式则让各服务通过事件响应自主协调。编排模式的核心优势在于可观测性和可控性——所有执行路径都经过中央编排器，状态变化有迹可查，异常处理有章可循，这与AI Agent场景的需求高度契合。CI/CD领域积累了几十年的工程实践——状态机、Gate、并行、断点续跑——完全可以平移到AI编码场景。

但也要注意，Orchestrator本身增加了系统复杂度。对于简单任务，直接对话可能更高效；只有当流程足够复杂、需要多Agent协作、且有团队复用需求时，这套架构才能真正发挥价值。关键是找到那个「值得编排」的临界点。

核心要点

• Orchestrator不创建新Agent，只负责编排已有Agent，在正确时间调度正确的能力单元
• Gate机制让AI自主推进，仅在方案、质量、测试等关键节点暂停等待人类决策，将人从机械确认者变为质量决策者
• 四层架构（YAML模板、Orchestrator Skill、Pipeline Server、Dashboard）实现编排逻辑、运行状态和可视化的明确分离
• 团队经验通过YAML模板沉淀和复用，降低新人门槛，同一套Agent可适配不同开发场景
• AI编码演进三阶段：工具调用→流程固化→Orchestrator编排，核心是让AI自动巡航、人只在关键节点接管