我受够了 Coding Agent 的“假聪明，真串行”，于是做了 Meta-Orchestrator！

前言

以前用 Claude Code 做复杂任务，我最难受的不是它写不出代码。

恰恰相反，现在的 Coding Agent 已经很能打了。读代码、改功能、补测试、查 Bug，这些都不是大问题。

真正让我难受的是它的执行方式。

明明有几个互不依赖的文件可以同时分析，它偏要一个接一个地做；任务稍微复杂一点，就把所有步骤塞进上下文，靠"记忆"维持顺序；同一种流程已经重复了三次，下一次还是从头规划；中间某一步失败，后面的步骤甚至可能沿着错误前提继续执行。

我把这种体验叫作：

假聪明，真串行。

它很像一个代码能力不错，但完全不会排期的工程师。你告诉它目标，它马上开工，却没有依赖图，不知道哪些任务可以并行，也没有清晰的失败处理。

顺利的时候很聪明，流程一长，就容易变成一台"高级打字机"。

所以我做了 Meta-Orchestrator。

它不负责教 AI 怎么写下一段代码，而是解决另一个问题：

一个复杂任务，究竟应该如何拆解、排序、并行、恢复和复用？

模型不缺聪明，缺的是任务编排

假设我们要给一个项目增加用户认证功能，可能需要完成这些工作：

分析现有用户模型
检查前端登录页面
设计 Token 生命周期
修改后端认证接口
增加前端状态管理
编写测试
执行类型检查
汇总变更与风险

这些任务显然不是一条直线。

分析用户模型和检查登录页面可以同时进行；实现后端认证依赖用户模型的分析结果；前端状态管理又依赖登录页面和接口约定；测试则必须等待实现完成。

它更接近这样一张图：

但在普通的对话执行中，这张图通常没有被真正记录下来。

依赖关系藏在自然语言里，执行进度藏在上下文里，失败状态也只能靠模型自己记住。

任务少时还能撑住。任务一多，顺序、分支和异常混在一起，问题就来了。

Meta-Orchestrator 做的第一件事，就是把隐含在上下文里的执行关系变成显式 DAG。

DAG 是"有向无环图"。简单理解，就是一张不会循环的任务依赖图：

没有前置依赖的节点可以立即执行；
有依赖的节点必须等待上游完成；
同一层的独立节点可以并行；
失败节点可以进入单独的兜底路径。

痛点一：互不相干的任务也要排队

假设要检查五个独立模块：

text 复制代码

用户模块
订单模块
支付模块
日志模块
通知模块

如果这些任务之间没有前置依赖，也不会同时写入同一个文件，合理的做法是并行分析。

很多 Coding Agent 实际执行时却是这样的：

text 复制代码

检查用户模块
    ↓
检查订单模块
    ↓
检查支付模块
    ↓
检查日志模块
    ↓
检查通知模块

问题不在于模型没有并行能力，而是执行过程中没有一套明确规则去回答：

哪些任务可以立即开始？
哪些任务必须等待上游结果？
哪些任务会产生写入冲突？
当前这一层是否可以批量分发？

Meta-Orchestrator 会先把任务拆成节点，再用 depends_on 表达依赖。

同层且互不冲突的任务会被并行分发，有依赖的任务则继续等待。

这里有一个重要边界：Meta-Orchestrator 不是无脑并行。

只有同时满足下面两个条件，任务才适合并行：

节点之间没有前置依赖；
节点之间不存在资源或文件写入冲突。

如果两个 Agent 会同时修改同一个文件，强行并行只会制造新的麻烦。

痛点二：把上下文当成任务调度器

复杂任务经常要求模型记住很多状态：

当前执行到哪一步；
哪个分支已经被选择；
哪些任务已经完成；
哪些任务仍在等待；
某个步骤是否执行失败；
后续任务究竟依赖哪个结果。

但上下文不是任务调度器。

对话越长，前面的规则越容易被稀释。中间如果插入新的需求、诊断信息或用户反馈，原有顺序还可能被打乱。

Meta-Orchestrator 使用显式依赖代替这种"靠记忆硬撑"的方式。

下面是一个简化后的工作流：

yaml 复制代码

name: auth-feature
kind: meta
description: 实现前后端认证功能
triggers:
  - 实现用户认证
  - 接入登录功能
meta_priority: 10
always: false
final_text_mode: auto

composition:
  steps:
    - id: inspect_backend
      kind: agent
      description: 分析后端认证结构
      agent_type: Explore
      model: haiku
      prompt: 检查现有用户模型、认证接口和会话逻辑。

    - id: inspect_frontend
      kind: agent
      description: 检查前端登录流程
      agent_type: Explore
      model: haiku
      prompt: 检查登录页面、状态管理和接口调用。

    - id: implement_backend
      kind: agent
      description: 实现后端认证
      agent_type: general-purpose
      model: sonnet
      prompt: 根据分析结果实现认证逻辑。
      depends_on: [inspect_backend]
      on_failure: implementation_failed

    - id: implement_frontend
      kind: agent
      description: 接入前端登录状态
      agent_type: general-purpose
      model: sonnet
      prompt: 接入后端认证接口并更新前端状态。
      depends_on: [inspect_frontend, implement_backend]
      on_failure: implementation_failed

    - id: run_tests
      kind: tool
      description: 执行测试
      tool: Bash
      params:
        command: npm test
      depends_on: [implement_backend, implement_frontend]
      on_failure: test_failed

    - id: implementation_failed
      kind: generate
      description: 汇总实现失败原因
      prompt: 说明失败步骤、已有结果和建议的恢复入口。

    - id: test_failed
      kind: generate
      description: 汇总测试失败原因
      prompt: 汇总失败测试，不要声称任务已经完成。

inspect_backend 和 inspect_frontend 没有依赖，因此可以同时执行。

implement_backend 必须等待后端分析完成；implement_frontend 又依赖前端分析和后端接口；测试则等待两边都完成。

执行顺序不再藏在模型的"记忆"里，而是直接写在图中。

痛点三：查一个函数和做架构设计，用的是同一档模型

并不是所有任务都需要最强模型。

搜索一个函数定义和设计多租户隔离方案，显然不是同一种难度。如果所有任务都使用高规格模型，会增加调用成本和等待时间；全部使用轻量模型，复杂任务的质量又很难保证。

Meta-Orchestrator 把任务分为 T0 到 T3：

级别	适用任务	参考模型档位
T0	查找、阅读、解释	haiku
T1	简单编辑、单文件修复	haiku，必要时升级
T2	功能开发、多文件修改、重构	sonnet
T3	架构设计、复杂诊断、深度推理	opus

这里的原则很朴素：从能够完成任务的最低档位开始，任务确实需要时再升级。

这套分级不是机器学习路由器，也不会保证每次选择都绝对正确。它目前主要根据任务类型和上下文做启发式判断，再由 Claude Code 或 Codex 等宿主环境执行可用模型。

它的价值在于让选择模型这件事变得可解释，而不是所有步骤都默认交给同一个模型。

痛点四：同一种流程，每次都从头规划

很多开发流程会反复出现。

例如修复 Bug：

text 复制代码

复现问题
→ 定位原因
→ 实现修复
→ 编写回归测试
→ 检查边界情况
→ 汇总结果

或者上线前检查：

text 复制代码

运行测试 || 安全检查
→ 构建
→ 汇总风险
→ 通知结果

普通对话中的计划用完就消失了。下一次遇到类似任务，Agent 仍然需要重新拆解、重新判断依赖。

Meta-Orchestrator 会记录 T2、T3 任务的 DAG 模式。

同一种复杂模式第三次出现时，它会提出结晶建议，把这套流程保存为 YAML 工作流。之后再遇到匹配的意图，就可以优先复用已有工作流。

这里用了一个刻意的限制：T0、T1 不参与结晶。

"读取文件、思考、回答"这种通用流程没有保存价值。如果什么都记录，工作流目录很快就会被大量低价值模板淹没。

如果用户明确说：

text 复制代码

以后遇到这种问题都按这个流程处理。

或者：

text 复制代码

每次发布前都执行这套检查，记住它。

那么系统可以立即结晶，不必等待第三次。这是用户已经明确表达了长期意图。

需要注意的是，"第三次出现"默认触发的是保存建议，并不是不经确认就随意生成大量工作流。

痛点五：中间一步失败，后面还在若无其事地继续

这是复杂 Agent 任务中很危险的一类问题。

假设工作流是：

text 复制代码

读取数据库结构
→ 设计迁移方案
→ 修改服务层
→ 编写测试

如果读取数据库结构失败，但失败状态没有被显式处理，后面的步骤仍可能继续。

生成出来的迁移方案看着很完整，实际上建立在一个不存在的前提上。

最麻烦的是，这类问题不一定会立即报错。它可能以一份结构完整、逻辑通顺的错误结果结束。

Meta-Orchestrator 允许关键节点声明 on_failure：

yaml 复制代码

- id: inspect_schema
  kind: tool
  description: 读取数据库结构
  on_failure: schema_failure_report

- id: schema_failure_report
  kind: generate
  description: 汇总数据库结构读取失败的信息
  prompt: 说明失败原因和已知信息，不要继续生成迁移方案。

Fallback 节点平时处于休眠状态，只有父节点失败时才会触发。

它不能被当成普通前置依赖，否则正常流程会一直等待一个永远不会执行的失败节点，最终形成死锁。

"自愈"到底能修什么？

"工作流自愈"很容易被写成一句夸张的宣传口号，所以这里需要把边界说清楚。

Meta-Orchestrator 的自愈主要针对 YAML 工作流本身的结构问题，例如：

节点依赖了只在某个条件分支中执行的任务；
正常流程错误地依赖了 fallback 节点；
classify 声明了分类结果，却缺少对应路由；
汇合节点依赖了不可能同时执行的多个分支；
关键 Agent 或工具步骤没有失败处理；
工作流仍在使用占位命令；
工具命令明显不具备跨平台能力。

它会识别这些问题，进行最小范围修正，并报告修改内容。

它不会自动修好所有业务代码，也不能解决网络中断、权限不足或第三方服务故障，更不会保证任务永不失败。

更准确的说法是：

它能检查并修正工作流的结构错误，避免错误依赖和静默失败继续传播。

开箱自带的工作流

项目目前附带了 5 个工作流示例：

code-review-pipeline.yaml：并行执行安全、质量等维度的代码审查；
deploy-checklist.yaml：执行测试、安全扫描、构建和发布前汇总；
bug-fix-workflow.yaml：按严重程度分类，完成诊断、修复、测试和复核；
api-migration.yaml：审计接口、分析破坏性变更、设计迁移方案并分阶段验证；
parallel-analysis.yaml：从不同角度并行分析，再统一汇总结论。

这些工作流既可以直接使用，也可以作为编写自定义 YAML 的参考。

Meta-Orchestrator 适合什么任务？

它更适合下面这些场景：

一个需求涉及多个模块；
分析、实现、测试和审查之间存在依赖；
部分工作可以并行，部分工作必须串行；
团队反复执行相似的开发流程；
希望不同复杂度的任务使用不同模型档位；
不能接受中间失败后继续生成错误结果；
希望执行过程可以追踪和复用。

它不适合为了"看起来高级"而编排所有任务。

如果只是查一个变量、修改一行配置，建立 DAG 反而增加开销。多个步骤需要同时修改同一个文件时，也不应该强行并行。

Meta-Orchestrator 不是独立的调度服务器。它是运行在 Claude Code、Codex Skill 系统中的执行协议，不依赖额外的外部运行时。

这让安装和修改都比较简单，但实际执行效果仍然依赖宿主 Agent 是否正确遵守 Skill 指令。

如何安装？

仓库同时提供 .claude 和 .codex 两套目录。

先克隆项目：

bash 复制代码

git clone https://github.com/youxing-max/Meta-Orchestrator.git

Claude Code 用户将 .claude 目录复制到项目根目录：

bash 复制代码

cp -r Meta-Orchestrator/.claude ./

Codex 用户复制 .codex：

bash 复制代码

cp -r Meta-Orchestrator/.codex ./

Windows 用户可以使用 PowerShell：

powershell 复制代码

git clone https://github.com/youxing-max/Meta-Orchestrator.git `
  $env:TEMP\meta-orchestrator

# Claude Code
Copy-Item -Recurse `
  $env:TEMP\meta-orchestrator\.claude .\

# Codex
Copy-Item -Recurse `
  $env:TEMP\meta-orchestrator\.codex .\

如果项目已经存在 .claude 或 .codex 目录，建议手动合并 skills、workflows 和模式记忆文件，避免覆盖已有配置。

为了让它在新会话中稳定加载，还需要在 CLAUDE.md 或 CODEX.md 中加入类似指令(不过我设置了预加载选项，也就是只要启动agent，默认就会把它加载到上下文中，省去了我们手动要求)：

markdown 复制代码

## Meta-Orchestrator

ALWAYS invoke meta-orchestrator skill at session start.

全局安装、Windows CMD 命令和完整目录结构可以直接查看仓库 README。

怎么验证它有没有价值？

不要拿一个单步骤任务测试它。

可以找一个包含"至少三个独立子任务和一条依赖链"的真实任务，例如：

text 复制代码

分析认证模块的前端、后端和数据库实现，
找出依赖关系与安全风险，
将无冲突的分析任务并行执行，
汇总后制定修改方案，
完成实现并运行测试。

然后观察这些问题：

独立分析是否真正并行；
有依赖的任务是否等待了正确的上游；
中间步骤失败时是否进入兜底；
最终结论是否明确区分成功、失败和未执行节点；
相同流程重复后，是否值得沉淀为工作流。

比起问"AI 有没有变聪明"，这些指标更容易验证。

写在最后

我做 Meta-Orchestrator，不是为了让 Coding Agent 多开几个子 Agent。

并行只是表面。真正想解决的问题，是把复杂任务的执行逻辑从聊天上下文里拿出来，变成一张可以检查、追踪和复用的工程图。

过去，AI 在猜下一步。

有了 DAG，它至少知道哪些步骤可以现在做，哪些必须等待，失败以后又该走向哪里。

它不会让所有任务自动成功，也不会消除模型幻觉。但它能给复杂任务建立基本秩序。

让 AI 从"会写代码的助手"，变成一个更懂排期的工程执行者。

项目地址：

github.com/youxing-max...

skillhub地址：

skillhub.cn/skills/meta...

如果你也遇到过"假聪明，真串行"，欢迎试用、提交 Issue，或者贡献自己的工作流模板。