---
created: "2026-06-18 07:31"
type: zettel
tags: [zettel, claude-code, orchestration, agent-orchestration, design-principle]
source: "https://github.com/affaan-m/ECC"
---

# 编排即排序门控与委派

好的 agent 编排不靠"更聪明的 AI",而是三件事的组合:**排序 + 门控 + 委派**。

ECC 的 `orch-pipeline` 是最干净的例证:它**不重新实现任何东西**。它的全部价值在于把现成 agent(planner、tdd-guide、code-reviewer…)按 Research→Plan→Implement→Review→Commit **排好序**,在两个关键点**设人类门**(Plan 后批准 task_list、Commit 前确认 diff),然后把每一步**委派**出去。包装层(`orch-add-feature` 等 5 个)只负责分类意图和选阶段。

配套的关键原则:**仪式随爆炸半径缩放(ceremony scales to blast radius)**。改一行的 trivial 改动直接 `Implement→Review→Commit`,跳过 Research/Plan;横切、引入新依赖或动公开 API 的 large 改动才上全套 + 安全审查。把全套流程套在小改动上,和让大改动裸奔,是同一种错误的两面。

> 推论:当你想"造一个更强的编排器"时,先问——我是不是只需要把已有的步骤**排好序、设好门、委派对人**?新增的往往应该是 sequencing 和 gate,而不是新实现。

这条原则在 ECC 各处复现:Ralphinho 的 tier 分层(trivial 只 implement→test,large 才加 final-review)、`parallel-execution-optimizer`(只在写面不冲突处并行)、Santa Loop(评审者≠作者的强制隔离)。

---

## Related

- [[ECC orch- 编排家族与 v2.0 团队编排]]
- [[Everything Claude Code Agent 编排模式]]
- [[Ralphinho RFC-DAG 编排模式]]
- [[上下文腐烂与全新窗口隔离]]

## Source

- `skills/orch-pipeline/SKILL.md`(ECC v2.0)— "The orch-* skills are thin wrappers. They do not re-implement any work." / "Ceremony scales to blast radius."