![在这里插入图片描述](https://developer.qcloudimg.com/http-save/yehe-11458826/034f11e576a2f5fd4435aa41d6962be6.png)

前言
---

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

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

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

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

**我把这种体验叫作：**
> 假聪明，真串行。

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

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

所以我做了 `Meta-Orchestrator`。

它不负责教 AI 怎么写下一段代码，而是解决另一个问题：
> 一个复杂任务，究竟应该如何拆解、排序、并行、恢复和复用？

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

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

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

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

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

它更接近这样一张图：

![在这里插入图片描述](https://developer.qcloudimg.com/http-save/yehe-11458826/0c333be8d16cf2672e1e1b67f9cec6b3.png)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

![在这里插入图片描述](https://developer.qcloudimg.com/http-save/yehe-11458826/2e4bfb26f11555d9c123242ae2c392be.png)

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

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

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

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

如果两个 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 个工作流示例：

1. code-review-pipeline.yaml：并行执行安全、质量等维度的代码审查；
2. deploy-checklist.yaml：执行测试、安全扫描、构建和发布前汇总；
3. bug-fix-workflow.yaml：按严重程度分类，完成诊断、修复、测试和复核；
4. api-migration.yaml：审计接口、分析破坏性变更、设计迁移方案并分阶段验证；
5. 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 从"会写代码的助手"，变成一个更懂排期的工程执行者。

**项目地址：**
> <https://github.com/youxing-max/Meta-Orchestrator>

**skillhub地址：**
> <https://skillhub.cn/skills/meta-orchestrator>

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


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

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

以前用 Claude Code，最难受的不是它写不出代码，而是“假聪明，真串行”：明明几个文件互不相干，它非要一个一个憋；稍微复杂点的任务，它就靠“记忆”硬撑，顺序一乱全盘皆输；重复三次的相同流程，它永远从头讲起；一旦中间某步失败，后面全是幻觉和静默错误。我受够了这种“高级打字机”式的体验，于是做了 Meta-Orchestrator：用 DAG 强制定义依赖，同层任务并行分发

人工智能

开发工具

架构设计

Meta-Orchestrator解决AI编程任务编排痛点，通过DAG图显式管理任务依赖关系，实现并行执行、失败处理和流程复用。支持任务分级调用不同模型，避免简单任务占用高规格资源。适用于多模块协同开发、复杂流程管理等场景，提升AI编程效率与可靠性。

机器学习

回归测试

代码解释

数据库

服务器

路由器

Windows

路由

Agent

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

我受够了 Coding Agent 的“假聪明，真串行”，于是做了 Meta-Orchestrator！-腾讯云开发者社区-腾讯云

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

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

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐