1.8 KiB
1.8 KiB
created, type, tags, source
| created | type | tags | source | |||||
|---|---|---|---|---|---|---|---|---|
| 2026-06-18 07:31 | zettel |
|
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
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."