knowledge-base/4 - Resources/Claude-Code/ECC 编排实战手册.md

created, type, tags, source

created	type	tags	source
2026-04-25	resource	resource claude-code ECC orchestration multi-agent parallel autonomous hands-on	https://github.com/affaan-m/everything-claude-code

ECC 编排实战手册

ECC 没有"一种"编排,而是 6 种正交模式 散布在 commands/、skills/、scripts/ 三个层面。这份手册把每一种的真实命令、真实代码、真实出处全列出来,并明确标记"哪些有公开实操证据,哪些只能照命令文档说的去做"。

相关笔记:Everything Claude Code 完整指南、Everything Claude Code 方法论与最佳实践、ECC 编排替代方案 (orchestrate 迁移)、Autonomous Loops 自主循环模式、dmux 多Agent并行编排、Ralphinho RFC-DAG 编排模式、Autonomous Agent Harness 自主代理框架

---

0. 决策树:你到底在编排什么?

不同模式解决的是完全不同的问题。先回答 3 个问题:

Q1: 你需要并行,还是顺序但不间断?
    ├─ 顺序但不间断 → 模式 2 (Sequential Pipeline) 或 模式 3 (Continuous PR Loop)
    └─ 并行 → Q2

Q2: 并行的任务之间有依赖关系吗?
    ├─ 无依赖(独立的几件事) → 模式 1 (dmux / Worktree 并行)
    └─ 有依赖 → Q3

Q3: 需要"评审者≠实现者"的强制隔离吗?
    ├─ 需要(高风险、生产代码) → 模式 4 (Ralphinho RFC-DAG) 或 模式 5 (Santa Loop 双评审)
    └─ 不需要(单 session 内 agent 委派就够) → 模式 6 (Task 工具内嵌并行)

模式	用什么	真实存在	是否 Windows 可用
1. dmux + 多 worktree	dmux-workflows skill + scripts/orchestrate-worktrees.js	✅ 仓库内	❌ 需 tmux
2. Sequential claude -p 管道	shell 脚本 + claude -p	✅ 官方 CLI	✅
3. Continuous PR Loop	continuous-claude 外部工具	✅ AnandChowdhary	✅
4. Ralphinho RFC-DAG	ralphinho 外部工具 + ralphinho-rfc-pipeline skill	✅ enitrat	✅(用 jj)
5. Santa Loop 双评审	/santa-loop 命令	✅ ECC 命令	✅
6. Task 工具内并行	Claude Code 原生 Task tool	✅ 内置	✅
(退役)/orchestrate	legacy shim → 转发到 dmux/harness	⚠️ 已标记为 legacy	❌
(替代)/feature-dev	单功能 7 阶段全流程	✅ 命令存在	✅
(高级)/multi-plan /multi-execute	ccg 多模型协同(需外部 Codex/Gemini CLI)	⚠️ 需独立安装	部分

---

模式 1:dmux + 多 worktree(并行独立任务)

实事求是:这是 ECC 推荐的"真正多 agent 编排"

ECC 仓库 commands/orchestrate.md 第 1 行明确写:

"Legacy slash-entry shim for dmux-workflows and autonomous-agent-harness. Prefer the skills directly."

也就是说 /orchestrate 已退役,真实主力是 dmux-workflows skill。

何时用

• 3-5 个互不依赖的任务(不同模块/不同关注点)
• 你想用不同模型/不同工具(Claude Code + Codex + OpenCode 混搭)
• 你愿意装 tmux

真实命令(已验证)

# 1. 装 dmux(GitHub: standardagents/dmux)
# README 原话: "cd /path/to/your/project / dmux /
# Press `n` to create a new pane, type a prompt, pick one or more agents"
brew install tmux  # 前置依赖

# 2. 在项目根目录起 dmux
cd /path/to/project
dmux

# 3. 在 dmux 里:
#    按 n → 输入 prompt → 选 agent (Claude Code/Codex/Gemini/...)
#    每个 pane 独立 session,独立 context window
#    按 m → 把 pane 输出 merge 回主 session

ECC 自带的 worktree 编排器(无需 dmux)

如果你不想用 dmux,ECC 仓库有自己的 scripts/orchestrate-worktrees.js(实测存在,2873 字节)。用法是先写一个 plan.json,然后:

# 仓库实际命令(scripts/orchestrate-worktrees.js usage 输出)
node scripts/orchestrate-worktrees.js plan.json [--execute]
node scripts/orchestrate-worktrees.js plan.json [--write-only]
# 不带 flag 默认 dry-run,只打印计划

plan.json 的真实结构(直接来自 skills/dmux-workflows/SKILL.md):

{
  "sessionName": "skill-audit",
  "baseRef": "HEAD",
  "launcherCommand": "codex exec --cwd {worktree_path} --task-file {task_file}",
  "workers": [
    { "name": "docs-a", "task": "Fix skills 1-4 and write handoff notes." },
    { "name": "docs-b", "task": "Fix skills 5-8 and write handoff notes." }
  ]
}

可用占位符:{worker_name} {worker_slug} {session_name} {repo_root} {worktree_path} {branch_name} {task_file} {handoff_file} {status_file}。

每个 worker 会:

1. 在 .orchestration/<session>/ 下生成 task.md、handoff.md、status.md
2. 单独开一个分支 + git worktree
3. 在 tmux pane 里跑 launcherCommand

监控

# 仓库实际命令
node scripts/orchestration-status.js .claude/plan/workflow-visual-proof.json

输出 JSON 包含:session 活动、tmux pane 元数据、worker 状态、目标、recent handoff summaries。

seedPaths(把 dirty 文件带进 worktree)

如果 worker 需要看主分支没提交的本地文件(比如新写的脚本):

{
  "sessionName": "workflow-e2e",
  "seedPaths": [
    "scripts/orchestrate-worktrees.js",
    "scripts/lib/tmux-worktree-orchestrator.js",
    ".claude/plan/workflow-e2e-test.json"
  ],
  "workers": [{ "name": "docs", "task": "Update orchestration docs." }]
}

ECC 会在 git worktree add 之后把这些路径覆盖到每个 worker worktree。

5 个 dmux pattern(直接抄自 SKILL.md)

模式	Pane 1	Pane 2	Pane 3
Research + Implement	调研 + 写到 /tmp/x.md	先写实现框架,等调研完合并	—
Multi-File Feature	DB schema + migration	API endpoints	UI 组件
Test + Fix Loop	跑 watch mode,失败时总结	根据 pane 1 的输出修	—
Cross-Harness	Claude Code 审 auth 安全	Codex 重构 utility 性能	Claude Code 写 E2E
Code Review Pipeline	看 src/api 安全	看 src/api 性能	看 src/api 测试覆盖

硬约束(SKILL.md 原话)

"Independent tasks only. Don't parallelize tasks that depend on each other's output." "Each pane is a full agent session — keep total panes under 5-6."

---

模式 2:Sequential claude -p 管道(最朴素,最稳)

何时用

• 你想要确定性:每步独立 context,不会被前面污染
• 你想要 CI/CD 集成
• 你愿意写 shell

真实例子(skills/autonomous-loops/SKILL.md 原文)

#!/bin/bash
# daily-dev.sh — Sequential pipeline for a feature branch
set -e

# Step 1: Implement the feature
claude -p "Read the spec in docs/auth-spec.md. Implement OAuth2 login in src/auth/. Write tests first (TDD). Do NOT create any new documentation files."

# Step 2: De-sloppify (cleanup pass)
claude -p "Review all files changed by the previous commit. Remove any unnecessary type tests, overly defensive checks, or testing of language features (e.g., testing that TypeScript generics work). Keep real business logic tests. Run the test suite after cleanup."

# Step 3: Verify
claude -p "Run the full build, lint, type check, and test suite. Fix any failures. Do not add new features."

# Step 4: Commit
claude -p "Create a conventional commit for all staged changes. Use 'feat: add OAuth2 login flow' as the message."

关键设计原则(原文)

1. 每步隔离 —— 新 context window 意味着不会有前一步的污染
2. 顺序敏感 —— 每步建立在上一步留下的文件状态上
3. set -e 失败立即停
4. 负面指令危险 —— 别说"不要测类型系统",改成单独加一个 cleanup step

模型路由变体

# 用 Opus 做深度分析
claude -p --model opus "Analyze the codebase architecture and write a plan for adding caching..."

# 用 Sonnet 实现
claude -p "Implement the caching layer according to the plan in docs/caching-plan.md..."

# 用 Opus 审查
claude -p --model opus "Review all changes for security issues, race conditions, and edge cases..."

工具限制变体

# 只读分析
claude -p --allowedTools "Read,Grep,Glob" "Audit this codebase for security vulnerabilities..."

# 只写实现
claude -p --allowedTools "Read,Write,Edit,Bash" "Implement the fixes from security-audit.md..."

De-sloppify pattern(关键加分项)

任何"实现"步骤后面都跟一个清理步骤,而不是用负面指令限制实现者:

for feature in "${features[@]}"; do
  claude -p "Implement $feature with TDD."
  claude -p "Cleanup pass: review changes, remove test/code slop, run tests."
  claude -p "Run build + lint + tests. Fix any failures."
  claude -p "Commit with message: feat: add $feature"
done

原文洞察:"Two focused agents outperform one constrained agent."

---

模式 3:Continuous PR Loop(多日自治)

何时用

• 多日的迭代项目(比如"加完整测试覆盖率")
• 每次迭代要走 PR + CI
• 你愿意用别人写好的工具(continuous-claude)

真实工具(已验证存在)

• GitHub: github.com/AnandChowdhary/continuous-claude
• 作者博客: https://anandchowdhary.com/blog/2025/running-claude-code-in-a-loop
• HN 讨论: https://news.ycombinator.com/item?id=45938517

README 原话:

"Run Claude Code in a continuous loop, autonomously creating PRs, waiting for checks, and merging."

真实命令

# 基础: 10 次迭代
continuous-claude --prompt "Add unit tests for all untested functions" --max-runs 10

# 成本上限
continuous-claude --prompt "Fix all linter errors" --max-cost 5.00

# 时间盒
continuous-claude --prompt "Improve test coverage" --max-duration 8h

# 加 reviewer 子步骤
continuous-claude \
  --prompt "Add authentication feature" \
  --max-runs 10 \
  --review-prompt "Run npm test && npm run lint, fix any failures"

# 用 worktree 并行多实例
continuous-claude --prompt "Add tests" --max-runs 5 --worktree tests-worker &
continuous-claude --prompt "Refactor code" --max-runs 5 --worktree refactor-worker &
wait

跨迭代上下文桥(SHARED_TASK_NOTES.md)

迭代之间靠这个文件传状态:

## Progress
- [x] Added tests for auth module (iteration 1)
- [x] Fixed edge case in token refresh (iteration 2)
- [ ] Still need: rate limiting tests, error boundary tests

## Next Steps
- Focus on rate limiting module next
- The mock setup in tests/helpers.ts can be reused

每次迭代开始 Claude 读它,结束 Claude 更新它。这就是用 filesystem 桥接独立 claude -p invocation 的关键技巧。

CI 失败自动恢复

PR 检查失败时,continuous-claude 会:

1. gh run list 查最近的失败 run id
2. 起一个新的 claude -p 带 CI fix context
3. Claude 用 gh run view 看日志、修代码、提交、push
4. 重新等待检查(最多 --ci-retry-max 次,默认 1)

Completion signal

continuous-claude \
  --prompt "Fix all bugs in the issue tracker" \
  --completion-signal "CONTINUOUS_CLAUDE_PROJECT_COMPLETE" \
  --completion-threshold 3  # 连续 3 次发出信号才停

全部 flags

Flag	用途
--max-runs N	N 次迭代后停
--max-cost $X	花 $X 后停
--max-duration 2h	时间到后停
--merge-strategy squash	squash / merge / rebase
--worktree <name>	git worktree 并行
--disable-commits	dry-run
--review-prompt "..."	加评审子步骤
--ci-retry-max N	CI 失败自动修次数

---

模式 4:Ralphinho RFC-DAG(最复杂、最严谨)

何时用

• 已经有一份 RFC / PRD
• 多个互相依赖的工作单元
• 不能容忍"实现者评审自己代码"的偏见
• 多日大项目

真实工具(已验证)

• GitHub: github.com/enitrat/ralphinho
• README 原话:"Multi-agent AI development workflows — code review with improvinho, spec-driven implementation with ralphinho, and optional Linear integration for human-in-the-loop triage."
• 用 Jujutsu (jj) 而不是 git 做 worktree 隔离
• ~93% TypeScript

真实命令(从 README)

# 从 RFC 启动
ralphinho init ./rfc.md

# 或纯评审模式(improvinho)
ralphinho init review "review this auth module" --paths src/auth/

# 跑
ralphinho run

架构(skills/ralphinho-rfc-pipeline/SKILL.md + autonomous-loops/SKILL.md)

RFC/PRD Document
       │
       ▼
  DECOMPOSITION (AI)
  把 RFC 拆成依赖 DAG 的 work units
       │
       ▼
  RALPH LOOP (最多 3 轮)
       │
       ▼
  对 DAG 每一层(按依赖顺序):
       │
       ├── Quality Pipelines (每个 unit 并行,各自 worktree)
       │   research → plan → implement → test → review
       │   (深度按 tier 调整)
       │
       └── Merge Queue
           rebase → tests → land 或 evict
           被 evict 的 unit 带冲突 context 重新进队

工作单元结构

interface WorkUnit {
  id: string;              // kebab-case
  name: string;
  rfcSections: string[];   // 对应 RFC 哪些章节
  description: string;
  deps: string[];          // 依赖的其他 unit id
  acceptance: string[];    // 验收标准
  tier: "trivial" | "small" | "medium" | "large";
}

复杂度分层(关键)

Tier	Pipeline 阶段
trivial	implement → test
small	implement → test → code-review
medium	research → plan → implement → test → PRD-review + code-review → review-fix
large	加 final-review

模型分配(每阶段独立 context)

阶段	模型	用途
Research	Sonnet	读代码 + RFC,产出 context doc
Plan	Opus	设计实现步骤
Implement	Codex	写代码
Test	Sonnet	build + test
PRD Review	Sonnet	规范合规检查
Code Review	Opus	质量 + 安全
Review Fix	Codex	处理评审意见
Final Review	Opus	大改才走

关键设计:评审者从未写过它评审的代码(消除作者偏见)。

Merge queue eviction recovery

被 evict 时把完整冲突 context(冲突文件、diff、test 输出)喂回给 implementer 下一轮:

## MERGE CONFLICT — RESOLVE BEFORE NEXT LANDING

Your previous implementation conflicted with another unit that landed first.
Restructure your changes to avoid the conflicting files/lines below.

{full eviction context with diffs}

何时不用

信号	用 Ralphinho	用更简单的
多个互相依赖的单元	✅	❌
需要并行实现	✅	❌
单文件改动	❌	✅(用模式 2)
多日 + 已有 RFC	✅	❌
一个东西的快速迭代	❌	✅(用 NanoClaw)

---

模式 5:Santa Loop 双评审(对抗式收敛)

何时用

• 改完代码不想自欺欺人
• 想要"两个独立模型都点头才上线"的硬门槛
• 单一会话内可完成

真实命令(commands/santa-loop.md)

# 评审当前未提交的改动
/santa-loop

# 评审某个文件/glob
/santa-loop src/auth/

# 评审某个范围描述
/santa-loop "the new payment integration"

工作流(命令文档原文)

1. Identify scope —— 默认 git diff --name-only HEAD
2. Build rubric —— 至少包含 6 项:Correctness、Security、Error handling、Completeness、Internal consistency、No regressions。可加领域特定项(TS type safety、Rust memory safety、SQL migration safety)
3. Dual independent review (并行):
   • Reviewer A:永远是 Claude Opus(code-reviewer agent)
   • Reviewer B:按可用性顺序 codex CLI > gemini CLI > Claude Opus 兜底
   • 两个 reviewer 都看不到对方的输出
   • 都要返回结构化 JSON:

     {
       "verdict": "PASS" | "FAIL",
       "checks": [{"criterion": "...", "result": "PASS|FAIL", "detail": "..."}],
       "critical_issues": ["..."],
       "suggestions": ["..."]
     }
     

4. Verdict gate:
   • 都 PASS → NICE → push
   • 任一 FAIL → NAUGHTY → 进入 fix cycle
5. Fix cycle(NAUGHTY 路径):
   • 修所有 critical issue,只改被标记的,不顺手重构
   • 单个 commit:fix: address santa-loop review findings (round N)
   • 起新的 reviewer(没有上轮记忆)
   • 最多 3 轮,还是 NAUGHTY 就停下来让人介入

设计要点(命令文档原话)

"Reviewer A (Claude Opus) always runs — guarantees at least one strong reviewer regardless of tooling."

"Model diversity is the goal for Reviewer B. GPT-5.4 or Gemini 2.5 Pro gives true independence — different training data, different biases, different blind spots."

"External reviewers run with --sandbox read-only (Codex) to prevent repo mutation during review."

"Fresh reviewers each round prevents anchoring bias from prior findings."

输出格式

SANTA VERDICT: NICE / NAUGHTY (escalated)

Reviewer A (Claude Opus):   [PASS/FAIL]
Reviewer B ([model used]):  [PASS/FAIL]

Agreement:
  Both flagged:      [issues caught by both]
  Reviewer A only:   [issues only A caught]
  Reviewer B only:   [issues only B caught]

Iterations: [N]/3
Result:     [PUSHED / ESCALATED TO USER]

---

模式 6:单 session 内 Task 并行(轻量内嵌)

何时用

• 不想配 tmux/worktree
• 任务可以在一个 session 内做完
• 几个独立子任务想并行

用法

直接在 Claude Code 主会话里让它"用 Task 工具并行起几个子 agent":

请并行起 3 个子 agent:
- agent 1: 读 src/api/ 找 SQL injection 风险
- agent 2: 读 src/api/ 找性能瓶颈
- agent 3: 读 src/api/ 找测试覆盖空洞
所有 agent 都用 Read/Grep/Glob,不要写文件。最后合并报告。

Claude Code 会用 Task 工具(就是 prompt 里能看到的 Agent tool)起 N 个 subagent,每个独立 context window,并行跑完后把结果传回主 session。

关键约束

• 每个子 agent 会回报一段 summary,主 agent 看不到子 agent 的中间过程
• 子 agent 用 CLAUDE_CODE_SUBAGENT_MODEL=haiku 跑(便宜约 80%)—— 见 Everything Claude Code Token 优化
• 5-6 个并行是上限,再多 token 烧得心疼

---

命令对照表(全部带状态标记)

命令	状态	真实做什么
/orchestrate	⚠️ Legacy shim	转发到 dmux-workflows + autonomous-agent-harness skill
/feature-dev	✅ 现役	单功能 7 阶段:Discovery → Codebase Exploration → Clarifying Questions → Architecture Design → Implementation → Quality Review → Summary
/multi-plan	⚠️ 需外部 CLI	ccg:plan 多模型协同规划,需要 codex/gemini CLI 和 ~/.claude/bin/codeagent-wrapper
/multi-execute	⚠️ 需外部 CLI	同上,执行阶段
/multi-frontend /multi-backend /multi-workflow	⚠️ 需外部 CLI	multi-* 系列变体
/loop-start	✅ 现役	启动 loop,模式 = sequential / continuous-pr / rfc-dag / infinite,模式 = safe(默认严格) / fast
/loop-status	✅ 现役	看当前 loop 状态,--watch 持续刷新
/santa-loop	✅ 现役	双评审收敛(见模式 5)
/harness-audit	✅ 现役	跑 node scripts/harness-audit.js,7 类打分(各 0-10):Tool Coverage、Context Efficiency、Quality Gates、Memory Persistence、Eval Coverage、Security Guardrails、Cost Efficiency
/quality-gate	✅ 现役	质量管道(类 hook 行为)
/model-route	✅ 现役	推荐当前任务该用哪个模型
/devfleet	⚠️ 需 MCP	需要外部 Claude DevFleet 实例:claude mcp add devfleet --transport http http://localhost:18801/mcp

---

实战搭配建议

A. 单人,小项目,不想配 tmux

主路: 模式 2(Sequential claude -p)+ 模式 6(Task 内并行)+ 模式 5(/santa-loop)

# 一个 shell 脚本搞定
#!/bin/bash
set -e
claude -p "Plan the new feature based on docs/spec.md"
claude -p "Implement based on the plan, TDD"
claude -p "De-sloppify pass: remove test/code slop"
# 进 Claude Code 交互模式跑 santa-loop
echo "Now run: /santa-loop in interactive Claude Code"

B. 团队,多任务并行

主路: 模式 1(scripts/orchestrate-worktrees.js)+ 模式 5

# plan.json
{
  "sessionName": "sprint-23",
  "workers": [
    {"name": "feat-auth", "task": "Implement OAuth2 from .claude/specs/auth.md"},
    {"name": "feat-billing", "task": "Implement Stripe billing from .claude/specs/billing.md"},
    {"name": "feat-admin", "task": "Build admin panel from .claude/specs/admin.md"}
  ]
}

# 执行
node scripts/orchestrate-worktrees.js plan.json --execute

# 监控
node scripts/orchestration-status.js plan.json

# 每个 worker 完成后,合到主分支前
/santa-loop feature/feat-auth..main

C. 多日大项目,有 RFC

主路: 模式 4(Ralphinho)

# 把 RFC 写到 ./rfc.md
ralphinho init ./rfc.md
ralphinho run

# Linear 集成可选(human-in-the-loop triage)

D. 自治改 bug / 加测试

主路: 模式 3(continuous-claude)

continuous-claude \
  --prompt "Improve test coverage to 90% across src/" \
  --max-runs 20 \
  --max-cost 50.00 \
  --completion-signal "COVERAGE_90_REACHED" \
  --review-prompt "npm test && npm run lint"

---

反模式(全部从 SKILL.md 原文摘抄)

1. 无限循环没退出条件 —— 必须有 max-runs / max-cost / max-duration / completion signal。
2. 迭代之间没有 context bridge —— 用 SHARED_TASK_NOTES.md 或 filesystem state 桥接。
3. 重试同一个失败 —— 把 error context 喂给下一次,不要盲目 retry。
4. 用负面指令代替 cleanup pass —— 别说 "don't do X",加一个去 X 的 pass。
5. 所有 agent 在同一个 context window —— 复杂工作流必须分到独立 process。评审者绝对不能是作者。
6. 并行任务编辑同一文件 —— 必须有 merge 策略(顺序 land、rebase、冲突解决)。
7. 盲目并行 —— 引自 Longform Guide:"how much can you get done with the minimum viable amount of parallelization."

---

配套真实工具栈

工具	链接	何时装
dmux	github.com/standardagents/dmux	想要 tmux 多 pane 多 agent
continuous-claude	github.com/AnandChowdhary/continuous-claude	想跑 PR 自治循环
Ralphinho	github.com/enitrat/ralphinho	有 RFC,需要 DAG 编排
codex CLI	OpenAI Codex CLI	用 /santa-loop 第二评审者、/multi-* 命令
gemini CLI	Google Gemini CLI	同上
jj (Jujutsu)	github.com/martinvonz/jj	Ralphinho 的 worktree 后端

---

不可考的边界(诚实声明)

我搜了 X、Reddit、HN、Medium,没有找到 /orchestrate、/multi-plan、/multi-execute、/feature-dev、/loop-start 在公开场合的实操截图或 thread。这些命令在仓库里确实存在(我读过 commands/*.md 文件),但社区没人晒出过运行时的 demo。

这意味着:

• 上面这些命令的"真实命令行"我都是按 commands/*.md 文件里写的复述,不是观察到的实际行为
• /multi-plan /multi-execute 实际依赖的 ~/.claude/bin/codeagent-wrapper 不是 ECC 标配,需要自己装(看起来是从一个叫 ccg(codex-claude-gemini)的项目来的)
• /devfleet 需要单独跑 Claude DevFleet HTTP 服务

安全建议: 优先用模式 1、2、3、5、6(全部都有真实可观测的工具支撑)。模式 4 也行,但配置成本高。/multi-* 系列等你看到 affaan 或社区有人晒 demo 再用。

---

来源

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

• commands/orchestrate.md(legacy shim 声明)
• commands/feature-dev.md(7 阶段定义)
• commands/multi-plan.md、multi-execute.md(ccg 协议)
• commands/loop-start.md、loop-status.md
• commands/santa-loop.md(双评审完整流程)
• commands/harness-audit.md(7 类打分)
• skills/dmux-workflows/SKILL.md(5 个 pattern + plan.json 结构)
• skills/autonomous-loops/SKILL.md(6 种 loop 模式 + 反模式)
• skills/ralphinho-rfc-pipeline/SKILL.md(7 阶段 + tier 表)
• skills/autonomous-agent-harness/SKILL.md(cron + memory + dispatch + computer use)
• skills/continuous-agent-loop/SKILL.md(loop selection flow)
• skills/claude-devfleet/SKILL.md(plan_project / dispatch_mission MCP 工具)
• agents/loop-operator.md
• scripts/orchestrate-worktrees.js(实测存在,2873 字节)
• scripts/orchestration-status.js(实测存在,1604 字节)

二次来源(网上验证)

• The Longform Guide:https://github.com/affaan-m/everything-claude-code/blob/main/the-longform-guide.md
• Affaan 公告:https://x.com/affaanmustafa/status/2014040193557471352(2026-01-21)
• continuous-claude:https://github.com/AnandChowdhary/continuous-claude + https://anandchowdhary.com/blog/2025/running-claude-code-in-a-loop
• Ralphinho:https://github.com/enitrat/ralphinho
• dmux:https://github.com/standardagents/dmux
• Medium 评述:https://medium.com/@tentenco/everything-claude-code-inside-the-82k-star-agent-harness-thats-dividing-the-developer-community-4fe54feccbc1

---

Related

Resources

• Everything Claude Code 完整指南
• Everything Claude Code 方法论与最佳实践
• Everything Claude Code 用法速查
• ECC 编排替代方案 (orchestrate 迁移)
• Autonomous Agent Harness 自主代理框架
• Autonomous Loops 自主循环模式
• Ralphinho RFC-DAG 编排模式
• dmux 多Agent并行编排
• GSD 方法论与最佳实践

Zettelkasten

• Everything Claude Code Agent 编排模式
• Everything Claude Code 多服务编排详解
• Everything Claude Code 最佳实践
• Everything Claude Code Token 优化
• 上下文腐烂与全新窗口隔离