文章目录前言模型不缺聪明缺的是任务编排痛点一互不相干的任务也要排队痛点二把上下文当成任务调度器痛点三查一个函数和做架构设计用的是同一档模型痛点四同一种流程每次都从头规划痛点五中间一步失败后面还在若无其事地继续“自愈”到底能修什么开箱自带的工作流Meta-Orchestrator 适合什么任务如何安装怎么验证它有没有价值写在最后前言以前用 Claude Code 做复杂任务我最难受的不是它写不出代码。恰恰相反现在的 Coding Agent 已经很能打了。读代码、改功能、补测试、查 Bug这些都不是大问题。真正让我难受的是它的执行方式。明明有几个互不依赖的文件可以同时分析它偏要一个接一个地做任务稍微复杂一点就把所有步骤塞进上下文靠“记忆”维持顺序同一种流程已经重复了三次下一次还是从头规划中间某一步失败后面的步骤甚至可能沿着错误前提继续执行。我把这种体验叫作假聪明真串行。它很像一个代码能力不错但完全不会排期的工程师。你告诉它目标它马上开工却没有依赖图不知道哪些任务可以并行也没有清晰的失败处理。顺利的时候很聪明流程一长就容易变成一台“高级打字机”。所以我做了Meta-Orchestrator。它不负责教 AI 怎么写下一段代码而是解决另一个问题一个复杂任务究竟应该如何拆解、排序、并行、恢复和复用模型不缺聪明缺的是任务编排假设我们要给一个项目增加用户认证功能可能需要完成这些工作分析现有用户模型检查前端登录页面设计 Token 生命周期修改后端认证接口增加前端状态管理编写测试执行类型检查汇总变更与风险这些任务显然不是一条直线。分析用户模型和检查登录页面可以同时进行实现后端认证依赖用户模型的分析结果前端状态管理又依赖登录页面和接口约定测试则必须等待实现完成。它更接近这样一张图但在普通的对话执行中这张图通常没有被真正记录下来。依赖关系藏在自然语言里执行进度藏在上下文里失败状态也只能靠模型自己记住。任务少时还能撑住。任务一多顺序、分支和异常混在一起问题就来了。Meta-Orchestrator 做的第一件事就是把隐含在上下文里的执行关系变成显式 DAG。DAG 是“有向无环图”。简单理解就是一张不会循环的任务依赖图没有前置依赖的节点可以立即执行有依赖的节点必须等待上游完成同一层的独立节点可以并行失败节点可以进入单独的兜底路径。痛点一互不相干的任务也要排队假设要检查五个独立模块用户模块 订单模块 支付模块 日志模块 通知模块如果这些任务之间没有前置依赖也不会同时写入同一个文件合理的做法是并行分析。很多 Coding Agent 实际执行时却是这样的检查用户模块 ↓ 检查订单模块 ↓ 检查支付模块 ↓ 检查日志模块 ↓ 检查通知模块问题不在于模型没有并行能力而是执行过程中没有一套明确规则去回答哪些任务可以立即开始哪些任务必须等待上游结果哪些任务会产生写入冲突当前这一层是否可以批量分发Meta-Orchestrator 会先把任务拆成节点再用 depends_on 表达依赖。同层且互不冲突的任务会被并行分发有依赖的任务则继续等待。这里有一个重要边界Meta-Orchestrator 不是无脑并行。只有同时满足下面两个条件任务才适合并行节点之间没有前置依赖节点之间不存在资源或文件写入冲突。如果两个 Agent 会同时修改同一个文件强行并行只会制造新的麻烦。痛点二把上下文当成任务调度器复杂任务经常要求模型记住很多状态当前执行到哪一步哪个分支已经被选择哪些任务已经完成哪些任务仍在等待某个步骤是否执行失败后续任务究竟依赖哪个结果。但上下文不是任务调度器。对话越长前面的规则越容易被稀释。中间如果插入新的需求、诊断信息或用户反馈原有顺序还可能被打乱。Meta-Orchestrator 使用显式依赖代替这种“靠记忆硬撑”的方式。下面是一个简化后的工作流name:auth-featurekind:metadescription:实现前后端认证功能triggers:-实现用户认证-接入登录功能meta_priority:10always:falsefinal_text_mode:autocomposition:steps:-id:inspect_backendkind:agentdescription:分析后端认证结构agent_type:Exploremodel:haikuprompt:检查现有用户模型、认证接口和会话逻辑。-id:inspect_frontendkind:agentdescription:检查前端登录流程agent_type:Exploremodel:haikuprompt:检查登录页面、状态管理和接口调用。-id:implement_backendkind:agentdescription:实现后端认证agent_type:general-purposemodel:sonnetprompt:根据分析结果实现认证逻辑。depends_on:[inspect_backend]on_failure:implementation_failed-id:implement_frontendkind:agentdescription:接入前端登录状态agent_type:general-purposemodel:sonnetprompt:接入后端认证接口并更新前端状态。depends_on:[inspect_frontend,implement_backend]on_failure:implementation_failed-id:run_testskind:tooldescription:执行测试tool:Bashparams:command:npm testdepends_on:[implement_backend,implement_frontend]on_failure:test_failed-id:implementation_failedkind:generatedescription:汇总实现失败原因prompt:说明失败步骤、已有结果和建议的恢复入口。-id:test_failedkind:generatedescription:汇总测试失败原因prompt:汇总失败测试不要声称任务已经完成。inspect_backend 和 inspect_frontend 没有依赖因此可以同时执行。implement_backend 必须等待后端分析完成implement_frontend 又依赖前端分析和后端接口测试则等待两边都完成。执行顺序不再藏在模型的“记忆”里而是直接写在图中。痛点三查一个函数和做架构设计用的是同一档模型并不是所有任务都需要最强模型。搜索一个函数定义和设计多租户隔离方案显然不是同一种难度。如果所有任务都使用高规格模型会增加调用成本和等待时间全部使用轻量模型复杂任务的质量又很难保证。Meta-Orchestrator 把任务分为 T0 到 T3级别适用任务参考模型档位T0查找、阅读、解释haikuT1简单编辑、单文件修复haiku必要时升级T2功能开发、多文件修改、重构sonnetT3架构设计、复杂诊断、深度推理opus这里的原则很朴素从能够完成任务的最低档位开始任务确实需要时再升级。这套分级不是机器学习路由器也不会保证每次选择都绝对正确。它目前主要根据任务类型和上下文做启发式判断再由 Claude Code 或 Codex 等宿主环境执行可用模型。它的价值在于让选择模型这件事变得可解释而不是所有步骤都默认交给同一个模型。痛点四同一种流程每次都从头规划很多开发流程会反复出现。例如修复 Bug复现问题 → 定位原因 → 实现修复 → 编写回归测试 → 检查边界情况 → 汇总结果或者上线前检查运行测试 || 安全检查 → 构建 → 汇总风险 → 通知结果普通对话中的计划用完就消失了。下一次遇到类似任务Agent 仍然需要重新拆解、重新判断依赖。Meta-Orchestrator 会记录 T2、T3 任务的 DAG 模式。同一种复杂模式第三次出现时它会提出结晶建议把这套流程保存为 YAML 工作流。之后再遇到匹配的意图就可以优先复用已有工作流。这里用了一个刻意的限制T0、T1 不参与结晶。“读取文件、思考、回答”这种通用流程没有保存价值。如果什么都记录工作流目录很快就会被大量低价值模板淹没。如果用户明确说以后遇到这种问题都按这个流程处理。或者每次发布前都执行这套检查记住它。那么系统可以立即结晶不必等待第三次。这是用户已经明确表达了长期意图。需要注意的是“第三次出现”默认触发的是保存建议并不是不经确认就随意生成大量工作流。痛点五中间一步失败后面还在若无其事地继续这是复杂 Agent 任务中很危险的一类问题。假设工作流是读取数据库结构 → 设计迁移方案 → 修改服务层 → 编写测试如果读取数据库结构失败但失败状态没有被显式处理后面的步骤仍可能继续。生成出来的迁移方案看着很完整实际上建立在一个不存在的前提上。最麻烦的是这类问题不一定会立即报错。它可能以一份结构完整、逻辑通顺的错误结果结束。Meta-Orchestrator 允许关键节点声明 on_failure-id:inspect_schemakind:tooldescription:读取数据库结构on_failure:schema_failure_report-id:schema_failure_reportkind:generatedescription:汇总数据库结构读取失败的信息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 两套目录。先克隆项目gitclone https://github.com/youxing-max/Meta-Orchestrator.gitClaude Code 用户将 .claude 目录复制到项目根目录cp-rMeta-Orchestrator/.claude ./Codex 用户复制 .codexcp-rMeta-Orchestrator/.codex ./Windows 用户可以使用 PowerShellgit clone https://github.com/youxing-max/Meta-Orchestrator.git $env:TEMP\meta-orchestrator# Claude CodeCopy-Item-Recurse $env:TEMP\meta-orchestrator\.claude.\# CodexCopy-Item-Recurse $env:TEMP\meta-orchestrator\.codex.\如果项目已经存在 .claude 或 .codex 目录建议手动合并 skills、workflows 和模式记忆文件避免覆盖已有配置。为了让它在新会话中稳定加载还需要在 CLAUDE.md 或 CODEX.md 中加入类似指令(不过我设置了预加载选项也就是只要启动agent默认就会把它加载到上下文中省去了我们手动要求)## Meta-Orchestrator ALWAYS invoke meta-orchestrator skill at session start.全局安装、Windows CMD 命令和完整目录结构可以直接查看仓库 README。怎么验证它有没有价值不要拿一个单步骤任务测试它。可以找一个包含“至少三个独立子任务和一条依赖链”的真实任务例如分析认证模块的前端、后端和数据库实现 找出依赖关系与安全风险 将无冲突的分析任务并行执行 汇总后制定修改方案 完成实现并运行测试。然后观察这些问题独立分析是否真正并行有依赖的任务是否等待了正确的上游中间步骤失败时是否进入兜底最终结论是否明确区分成功、失败和未执行节点相同流程重复后是否值得沉淀为工作流。比起问“AI 有没有变聪明”这些指标更容易验证。写在最后我做 Meta-Orchestrator不是为了让 Coding Agent 多开几个子 Agent。并行只是表面。真正想解决的问题是把复杂任务的执行逻辑从聊天上下文里拿出来变成一张可以检查、追踪和复用的工程图。过去AI 在猜下一步。有了 DAG它至少知道哪些步骤可以现在做哪些必须等待失败以后又该走向哪里。它不会让所有任务自动成功也不会消除模型幻觉。但它能给复杂任务建立基本秩序。让 AI 从“会写代码的助手”变成一个更懂排期的工程执行者。项目地址https://github.com/youxing-max/Meta-Orchestratorskillhub地址https://skillhub.cn/skills/meta-orchestrator如果你也遇到过“假聪明真串行”欢迎试用、提交 Issue或者贡献自己的工作流模板。