kai/knowledge-base

Fork 0

Files

Yaojia Wang 040b94f898 vault: add ECC v2.0 orch-* family + team orchestration notes

2026-06-18 07:38:04 +02:00

13 KiB

Raw Permalink Blame History

created, type, tags, source

created

type

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.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")

13 KiB

Raw Permalink Blame History

ECC orch-* 编排家族与 v2.0 团队编排

1. `orch-*` 家族 —— 把单会话流程产品化

五个操作 = 五种任务意图

共用引擎 `orch-pipeline` —— 门控的 R-P-T-R-C 流水线

核心设计:仪式随"爆炸半径"缩放(right-sizing)

两道人类门(gated, not autonomous)

阶段→agent 映射

2. `plan-orchestrate` —— 把计划文档翻译成 agent 链

3. 团队编排 —— Agent Kanban

`team-agent-orchestration`:把 agent 当队友

`team-builder`:按需组队

4. `dynamic-workflow-mode` —— 为任务现造载体

5. v2.0 编排理念:操作员系统(operator system)

6. 这一层在整张编排图里的位置

来源(直接读取的仓库文件)

Resources

Zettelkasten

13 KiB Raw Permalink Blame History Unescape Escape

ECC orch-* 编排家族与 v2.0 团队编排

1. orch-* 家族 —— 把单会话流程产品化

五个操作 = 五种任务意图

共用引擎 orch-pipeline —— 门控的 R-P-T-R-C 流水线

核心设计:仪式随"爆炸半径"缩放(right-sizing)

两道人类门(gated, not autonomous)

阶段→agent 映射

2. plan-orchestrate —— 把计划文档翻译成 agent 链

3. 团队编排 —— Agent Kanban

team-agent-orchestration:把 agent 当队友

team-builder:按需组队

4. dynamic-workflow-mode —— 为任务现造载体

5. v2.0 编排理念:操作员系统(operator system)

6. 这一层在整张编排图里的位置

来源(直接读取的仓库文件)

Related

Resources

Zettelkasten

13 KiB

Raw Permalink Blame History

1. `orch-*` 家族 —— 把单会话流程产品化

共用引擎 `orch-pipeline` —— 门控的 R-P-T-R-C 流水线

2. `plan-orchestrate` —— 把计划文档翻译成 agent 链

`team-agent-orchestration`:把 agent 当队友

`team-builder`:按需组队

4. `dynamic-workflow-mode` —— 为任务现造载体