13 KiB
created, type, tags, source
| created | type | tags | source | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| 2026-06-18 | resource |
|
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)
- GATE 1(Plan 之后) —— 先给
task_list,用户批准前不写实现代码 - 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 调用。三件事:
- 检测 ECC 安装模式 —— plugin 形态命令是
/everything-claude-code:orchestrate、agent 是everything-claude-code:<name>;legacy 形态是/orchestrate、<name>。一份输出里不混用两种。 - 拆步骤(六级优先:显式编号
## Step N> 表格 Step 列 >---分隔的动词块 > 否则每个 H2 一步) - 打标签 + 选 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)。三层架构:
- Meta-harness —— 可移植的 skills/rules/hooks/MCP 约定/发布门/eval/安全证据
- 专属 ECC agent —— 一个操作 ECC 资产的 agent(不只把它们当静态指令读)
- 控制面板 / agentic IDE —— 把 session/队列/skill/记忆/证据/发布/团队工作流变成可观测的操作员界面
提炼出的几条编排原则(可单独当 zettel 看,见 20260618073140 编排即排序门控与委派):
- 编排 = 排序 + 门控 + 委派(不是新 AI):价值在系统化排序、两道门、委派给被验证过的 agent。
- 仪式随爆炸半径缩放:trivial 跳过 Research/Plan;large 才上全套 + 安全审查。(同样体现在 Ralphinho 的 tier 分层、
parallel-execution-optimizer的"只在写面不冲突处并行"。) - 权威随领域走:Codex=后端权威、Gemini=前端权威、Claude=代码主权(所有落盘);跨域意见仅供参考。(见 ECC 编排替代方案 (orchestrate 迁移) 路线 D)
- 并行必须有可观测的合并门:每个并行单元都要有 owner、分支/worktree、验收、证据(测试/截图)、merge gate。
- 可复用的资产是工作流,不是答案:一次性答案会扔;证明答案可用的任务局部载体有价值;多团队复用的共享 skill 才是制度资产。
- 控制面板胜过隐藏的聊天输出:"谁拥有这张卡、改了什么、什么失败、什么通过、什么能合并"才是操作员真正需要的。
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.mdskills/parallel-execution-optimizer/SKILL.mddocs/architecture/cross-harness.md、docs/architecture/platform-value-loop.md、docs/business/team-agent-orchestration-content-pack.mdCHANGELOG.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 完整指南