204 lines
13 KiB
Markdown
204 lines
13 KiB
Markdown
---
|
||
created: "2026-06-18"
|
||
type: resource
|
||
tags: [resource, claude-code, ECC, orchestration, multi-agent, orch-pipeline, dynamic-workflow, team-orchestration]
|
||
source: "https://github.com/affaan-m/ECC"
|
||
---
|
||
|
||
# ECC orch-* 编排家族与 v2.0 团队编排
|
||
|
||
> 本笔记补的是 **ECC v2.0.0(2026-06-09)新增**的编排层。早期编排笔记停在 2026-04,覆盖的是 `/orchestrate`(已退役)、`/multi-*`、GSD、devfleet、自治循环。这一篇专门讲 **`orch-*` 家族、`plan-orchestrate`、团队编排(Kanban)、动态工作流**,以及 2.0 的"操作员系统"理念。
|
||
>
|
||
> 相关:[[ECC 编排实战手册]]、[[ECC 编排替代方案 (orchestrate 迁移)]]、[[Autonomous Loops 自主循环模式]]、[[Ralphinho RFC-DAG 编排模式]]、[[Everything Claude Code 完整指南]]、[[Everything Claude Code Agent 编排模式]]
|
||
|
||
---
|
||
|
||
## 1. `orch-*` 家族 —— 把单会话流程产品化
|
||
|
||
`/orchestrate` 退役后,ECC 2.0 用 **`orch-*` skill 家族**取而代之。这不是 5 个独立流程,而是 **5 个薄包装(thin wrapper)共用一个引擎 `orch-pipeline`**。包装层只做三件事:给任务**分级**、决定**跑哪几个阶段**、把每个阶段**委派**给现成的 ECC agent/命令。**它不重新实现任何东西**(`/feature-dev`、`/plan`、`/code-review`、`/build-fix`、`/refactor-clean`、`/gan-build`、`tdd-workflow` 都是被它编排的)。
|
||
|
||
### 五个操作 = 五种任务意图
|
||
|
||
| skill | 操作 | 触发条件 | 默认尺寸 | 第一步(关键) |
|
||
|-------|------|---------|---------|--------------|
|
||
| `orch-add-feature` | feature | 能力**还不存在** | standard | 先写**新**失败测试 → 实现 |
|
||
| `orch-fix-defect` | fix | 行为**坏了** | small | 先写**回归**失败测试 → 修 |
|
||
| `orch-change-feature` | tweak | 行为在但**不符合期望** | small | 先改**现有**测试到新规格 → 改实现 |
|
||
| `orch-refine-code` | refactor | 行为不变、**结构**改善 | standard | 先确认测试绿 → 重构 |
|
||
| `orch-build-mvp` | mvp | 从 design/spec **文档引导** | large | 读文档 → 切薄竖切片(vertical slices) |
|
||
|
||
> 选错入口没关系:引擎会先分级,small/trivial 的 feature 会自动塌缩成 `4→5→6`。
|
||
|
||
### 共用引擎 `orch-pipeline` —— 门控的 R-P-T-R-C 流水线
|
||
|
||
七个阶段(Phase 0 永远跑):
|
||
|
||
- **0 Intake** —— 复述请求;MVP 还要读 spec 抽 scope/锁定决策/功能清单
|
||
- **1 Research & Reuse** —— `gh search repos/code` → Context7/官方文档 → 包仓库 → Exa;**优先采用现成实现**
|
||
- **2 Plan** —— 委派 `planner`(结构性改动用 `architect`/`code-architect`),产出 `task_list`(薄竖切片排序)→ **GATE 1**
|
||
- **3 Scaffold** —— 仅 MVP:立起第一个端到端切片
|
||
- **4 Implement (TDD)** —— 走 `tdd-guide`/`tdd-workflow`:red→green→refactor,遵守该操作的"第一步"规则
|
||
- **5 Review** —— `code-reviewer`/`/code-review`;碰安全触发器加 `security-reviewer`
|
||
- **6 Commit** —— conventional commit,每个逻辑块一个 → **GATE 2**
|
||
|
||
### 核心设计:仪式随"爆炸半径"缩放(right-sizing)
|
||
|
||
Step 0 按三个信号(改动文件数 / 是否引入新依赖或契约 / 设计模糊度)取**最高**那一档:
|
||
|
||
| Tier | 文件 | 新依赖·契约 | 模糊度 | 跑哪些阶段 |
|
||
|------|------|------------|--------|-----------|
|
||
| trivial | 1、几行 | 无 | 改动显而易见 | 4 → 5 → 6 |
|
||
| small | 1 文件/函数 | 无 | 读完代码就清楚 | (1 轻量) → 4 → 5 → 6 |
|
||
| standard | 2–5 文件 | 可能新内部模块 | 一个真实选择 | 1 → 2 → 4 → 5 → 6 |
|
||
| large | 多/横切 | 新外部依赖、公开 API、spec 文档 | 多个开放问题 | 1 → 2 → (3) → 4 → 5 → 6 |
|
||
|
||
> 平局打破:碰**安全触发器**或**公开 API/契约**的,无论文件多少,**至少 standard**。
|
||
|
||
### 两道人类门(gated, not autonomous)
|
||
|
||
1. **GATE 1(Plan 之后)** —— 先给 `task_list`,用户批准前**不写实现代码**
|
||
2. **GATE 2(Commit 之前)** —— 先给 diff 摘要 + 提交信息,用户确认前**不提交**
|
||
|
||
两门之间一路不停。这正是 `orch-*` 与全自治循环([[Autonomous Loops 自主循环模式]])的根本区别:**有人在环**。
|
||
|
||
### 阶段→agent 映射
|
||
|
||
| 阶段 | 主用 | 兜底/升级 |
|
||
|------|------|----------|
|
||
| Intake/理解 | `code-explorer` | tweak/fix/refactor 前先 trace 现有路径 |
|
||
| Plan | `planner` | `architect`、`code-architect`(结构性) |
|
||
| Implement | `tdd-guide` / `tdd-workflow` | 构建炸了用 `build-error-resolver`/`/build-fix` |
|
||
| Review | `code-reviewer` / `/code-review` | 语言专属 reviewer(python/typescript-reviewer…) |
|
||
| Security | `security-reviewer` | — |
|
||
| MVP 内循环 | `/gan-build "<brief>" --skip-planner` | 驱动 `gan-generator`→`gan-evaluator` |
|
||
|
||
安全触发器(任一即拉 `security-reviewer`):认证授权、用户输入、DB 查询、文件路径、外部 API、加密、密钥凭据。
|
||
|
||
> 与 `/feature-dev` 的区别:`/feature-dev` 是这套流程的**独立版**;`orch-add-feature` 通过共用 `orch-pipeline` 引擎(分级器 + 两门),让 trivial 功能能右尺寸到 `4→5→6`,并和家族其余操作保持一致。
|
||
|
||
---
|
||
|
||
## 2. `plan-orchestrate` —— 把计划文档翻译成 agent 链
|
||
|
||
**纯生成,不执行**。输入一份多步计划(PRD/RFC/implementation plan),输出**每步一条可直接粘贴**的 `/orchestrate custom` 调用。三件事:
|
||
|
||
1. **检测 ECC 安装模式** —— plugin 形态命令是 `/everything-claude-code:orchestrate`、agent 是 `everything-claude-code:<name>`;legacy 形态是 `/orchestrate`、`<name>`。**一份输出里不混用两种**。
|
||
2. **拆步骤**(六级优先:显式编号 `## Step N` > 表格 Step 列 > `---` 分隔的动词块 > 否则每个 H2 一步)
|
||
3. **打标签 + 选 agent 链**(12 个触发词 → 默认链):
|
||
|
||
| 标签 | 默认 agent 链 |
|
||
|------|--------------|
|
||
| `design` | `planner,architect` |
|
||
| `impl` | `tdd-guide,<lang>-reviewer` |
|
||
| `impl+security` | `tdd-guide,<lang>-reviewer,security-reviewer` |
|
||
| `impl+db` | `tdd-guide,database-reviewer,<lang>-reviewer` |
|
||
| `refactor` | `architect,refactor-cleaner,<lang>-reviewer` |
|
||
| `migration` | `architect,tdd-guide,<lang>-reviewer` |
|
||
| `build` | `<lang>-build-resolver` |
|
||
| `security` | `security-reviewer,<lang>-reviewer` |
|
||
| `test` | `tdd-guide,e2e-runner` |
|
||
| `db` | `database-reviewer,<lang>-reviewer` |
|
||
| `docs` | `doc-updater` |
|
||
| `loop` | `loop-operator` |
|
||
|
||
输出含:全步骤总表、每步详情块(意图 + 选链理由 + 可粘贴命令)、批量执行块。
|
||
|
||
---
|
||
|
||
## 3. 团队编排 —— Agent Kanban
|
||
|
||
### `team-agent-orchestration`:把 agent 当队友
|
||
|
||
核心:agent 要有**显式 owner、scope、状态、合并门**。用 Agent Kanban 让并行工作可见。
|
||
|
||
**列(及退出标准)**:Backlog(写好验收) → Ready(分配 owner+分支/worktree) → Running(有 handoff 产物+改动文件) → Review(测试/diff/风险通过) → Merged。另有 Blocked(blocker 有 owner+下一步)、Archived。
|
||
|
||
**工作项 schema**(关键字段):`id / title / owner / state / branch / worktree / acceptance[] / merge_gate / handoff`。
|
||
|
||
**控制面板(control pane)应暴露**:活跃工作项及状态、owner/harness/分支/worktree/心跳、handoff/测试/PR 链接、按 owner 分组的 blocker、**按 gate 而非感觉判断的合并就绪度**、可复用工作流候选。
|
||
|
||
> 关键口号:**merge gate, not hope gate**(用门判断能否合并,而不是凭希望)。
|
||
|
||
### `team-builder`:按需组队
|
||
|
||
交互菜单从可用 agent 里拼并行团队。流程:`claude agents` 发现 agent → 按领域分组菜单 → 接受编号("1,3")或名字("security + seo") → **上限 5 个**(再多边际递减) → 用 Agent 工具 `subagent_type: general-purpose` 并行 spawn → 汇总(各 agent 输出 + 一致/冲突/建议)。
|
||
|
||
> 注意:用**并行 Agent 工具调用**(各自独立做事),不是 TeamCreate(那是给 agent 之间对话用的)。
|
||
|
||
---
|
||
|
||
## 4. `dynamic-workflow-mode` —— 为任务现造载体
|
||
|
||
让 agent 能**生成/改造工作流**,而不只执行静态命令。何时启用:任务需要自定义 loop/评估器/爬虫/fixture 生成器/watcher/dashboard;多个 agent 要同一可重复流程(但还没沉淀成 skill);需要持久 handoff 产物、eval 证据或操作员批准。
|
||
|
||
**决策树**:一次性 → 内联;输入会变的重复任务 → 建**任务局部载体(task-local harness)**;跨队友/跨仓库重复 → **抽成共享 skill**;有外部状态/排队/审批 → 先加控制面板可见性;有安全风险 → 加 eval 门 + 人类合并门。
|
||
|
||
**抽成共享 skill 的条件**(满足 ≥2):多会话/仓库/团队重复出现、需要特定语言/工具/安全顺序、失败反复发生、输入输出契约稳定、能受益于控制面板/状态板/团队 handoff。
|
||
|
||
**每类工作最便宜的可靠 eval 门**:代码 → 聚焦测试+lint+覆盖率+一条集成路径;UI → 浏览器冒烟+截图+溢出/报错检查;agent 工作流 → fixture transcript / 带预期路由的种子工作项;研究/内容 → 来源中立的 brief + claim 清单;集成 → dry-run 命令 + 配置校验 + 无密钥扫描。
|
||
|
||
---
|
||
|
||
## 5. v2.0 编排理念:操作员系统(operator system)
|
||
|
||
ECC 2.0 的论点:agent 工具正从"单人聊天窗"走向**团队编排系统**(看板、控制面板、动态工作流、eval 门、共享 skill)。三层架构:
|
||
|
||
1. **Meta-harness** —— 可移植的 skills/rules/hooks/MCP 约定/发布门/eval/安全证据
|
||
2. **专属 ECC agent** —— 一个**操作** ECC 资产的 agent(不只把它们当静态指令读)
|
||
3. **控制面板 / agentic IDE** —— 把 session/队列/skill/记忆/证据/发布/团队工作流变成**可观测**的操作员界面
|
||
|
||
提炼出的几条编排原则(可单独当 zettel 看,见 [[20260618073140 编排即排序门控与委派]]):
|
||
|
||
1. **编排 = 排序 + 门控 + 委派**(不是新 AI):价值在系统化排序、两道门、委派给被验证过的 agent。
|
||
2. **仪式随爆炸半径缩放**:trivial 跳过 Research/Plan;large 才上全套 + 安全审查。(同样体现在 Ralphinho 的 tier 分层、`parallel-execution-optimizer` 的"只在写面不冲突处并行"。)
|
||
3. **权威随领域走**:Codex=后端权威、Gemini=前端权威、Claude=代码主权(所有落盘);跨域意见仅供参考。(见 [[ECC 编排替代方案 (orchestrate 迁移)]] 路线 D)
|
||
4. **并行必须有可观测的合并门**:每个并行单元都要有 owner、分支/worktree、验收、证据(测试/截图)、merge gate。
|
||
5. **可复用的资产是工作流,不是答案**:一次性答案会扔;证明答案可用的任务局部载体有价值;多团队复用的共享 skill 才是制度资产。
|
||
6. **控制面板胜过隐藏的聊天输出**:"谁拥有这张卡、改了什么、什么失败、什么通过、什么能合并"才是操作员真正需要的。
|
||
|
||
---
|
||
|
||
## 6. 这一层在整张编排图里的位置
|
||
|
||
| 你要的 | 用 | 出处 |
|
||
|--------|-----|------|
|
||
| 单任务全流程、要分级 + 两道人类门 | `orch-add-feature` / `orch-fix-defect` / `orch-change-feature` / `orch-refine-code` | skill |
|
||
| 从 design/spec 文档起 MVP | `orch-build-mvp` | skill |
|
||
| 把一份 PRD/RFC 翻成可粘贴的 agent 链 | `plan-orchestrate` | skill(纯生成) |
|
||
| 多 agent 并行 + 看板可见性 + 合并门 | `team-agent-orchestration` | skill |
|
||
| 按需从可用 agent 拼并行小队(≤5) | `team-builder` | skill |
|
||
| 给任务现造 loop/评估器/dashboard | `dynamic-workflow-mode` | skill |
|
||
| 全自治长跑循环 | 见 [[Autonomous Loops 自主循环模式]]、[[Ralphinho RFC-DAG 编排模式]] | — |
|
||
| 跨 harness/tmux 并行 | 见 [[ECC 编排实战手册]]、[[dmux 多Agent并行编排]] | — |
|
||
|
||
---
|
||
|
||
## 来源(直接读取的仓库文件)
|
||
|
||
- `skills/orch-pipeline/SKILL.md`(共用引擎:5 操作、Step 0 分级表、7 阶段、两门、agent 映射、安全触发器)
|
||
- `skills/orch-add-feature/SKILL.md` 及 `orch-fix-defect/`、`orch-change-feature/`、`orch-refine-code/`、`orch-build-mvp/`
|
||
- `skills/plan-orchestrate/SKILL.md`(安装模式检测、拆步、12 标签链)
|
||
- `skills/team-agent-orchestration/SKILL.md`(Kanban 列、work item schema、control pane)
|
||
- `skills/team-builder/SKILL.md`、`skills/dynamic-workflow-mode/SKILL.md`
|
||
- `skills/parallel-execution-optimizer/SKILL.md`
|
||
- `docs/architecture/cross-harness.md`、`docs/architecture/platform-value-loop.md`、`docs/business/team-agent-orchestration-content-pack.md`
|
||
- `CHANGELOG.md`(2.0.0 Added: "orch-* orchestrator skill family and dynamic workflow team orchestration")
|
||
|
||
---
|
||
|
||
## Related
|
||
|
||
### Resources
|
||
- [[ECC 编排实战手册]]
|
||
- [[ECC 编排替代方案 (orchestrate 迁移)]]
|
||
- [[Autonomous Agent Harness 自主代理框架]]
|
||
- [[Autonomous Loops 自主循环模式]]
|
||
- [[Ralphinho RFC-DAG 编排模式]]
|
||
- [[dmux 多Agent并行编排]]
|
||
- [[Everything Claude Code 完整指南]]
|
||
|
||
### Zettelkasten
|
||
- [[20260618073140 编排即排序门控与委派]]
|
||
- [[Everything Claude Code Agent 编排模式]]
|
||
- [[Everything Claude Code 多服务编排详解]]
|