32 lines
1.8 KiB
Markdown
32 lines
1.8 KiB
Markdown
---
|
|
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."
|