vault: align ECC docs with current repo and add orchestration manual
Updated ECC notes to match the current state of affaan-m/everything-claude-code docs/token-optimization.md and docs/SKILL-PLACEMENT-POLICY.md: - Drop CLAUDE_AUTOCOMPACT_PCT_OVERRIDE recommendations (now warned against upstream — variable can only lower threshold, opposite of intent) - Add CLAUDE_CODE_SUBAGENT_MODEL=haiku as the new core token-saving setting - Flag the default `memory` MCP for disablement (no skill/agent/hook references) - Add Skill Placement Policy section (curated/learned/imported/evolved + provenance) - Cover missing commands: /checkpoint, /sessions, /security-scan, /claw, /projects Add new resource: ECC 编排实战手册.md (721 lines). Six orchestration patterns (dmux+worktree, sequential claude -p, continuous-claude, Ralphinho RFC-DAG, santa-loop, Task in-process) with real commands, real plan.json structures, real CLI flags, and explicit "could not verify online" markers for /multi-* and /feature-dev. All sourced to specific commands/*.md or skills/*.md files. Cross-link the new manual from 完整指南 and 用法速查.
This commit is contained in:
721
4 - Resources/Claude-Code/ECC 编排实战手册.md
Normal file
721
4 - Resources/Claude-Code/ECC 编排实战手册.md
Normal file
@@ -0,0 +1,721 @@
|
||||
---
|
||||
created: "2026-04-25"
|
||||
type: resource
|
||||
tags: [resource, claude-code, ECC, orchestration, multi-agent, parallel, autonomous, hands-on]
|
||||
source: "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 个问题:
|
||||
|
||||
```text
|
||||
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
|
||||
|
||||
### 真实命令(已验证)
|
||||
|
||||
```bash
|
||||
# 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,然后:
|
||||
|
||||
```bash
|
||||
# 仓库实际命令(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`):
|
||||
|
||||
```json
|
||||
{
|
||||
"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`
|
||||
|
||||
### 监控
|
||||
|
||||
```bash
|
||||
# 仓库实际命令
|
||||
node scripts/orchestration-status.js .claude/plan/workflow-visual-proof.json
|
||||
```
|
||||
|
||||
输出 JSON 包含:session 活动、tmux pane 元数据、worker 状态、目标、recent handoff summaries。
|
||||
|
||||
### `seedPaths`(把 dirty 文件带进 worktree)
|
||||
|
||||
如果 worker 需要看主分支没提交的本地文件(比如新写的脚本):
|
||||
|
||||
```json
|
||||
{
|
||||
"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 原文)
|
||||
|
||||
```bash
|
||||
#!/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
|
||||
|
||||
### 模型路由变体
|
||||
|
||||
```bash
|
||||
# 用 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..."
|
||||
```
|
||||
|
||||
### 工具限制变体
|
||||
|
||||
```bash
|
||||
# 只读分析
|
||||
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(关键加分项)
|
||||
|
||||
任何"实现"步骤后面都跟一个清理步骤,而不是用负面指令限制实现者:
|
||||
|
||||
```bash
|
||||
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."*
|
||||
|
||||
### 真实命令
|
||||
|
||||
```bash
|
||||
# 基础: 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`)
|
||||
|
||||
迭代之间靠这个文件传状态:
|
||||
|
||||
```markdown
|
||||
## 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
|
||||
|
||||
```bash
|
||||
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)
|
||||
|
||||
```bash
|
||||
# 从 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)
|
||||
|
||||
```text
|
||||
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 重新进队
|
||||
```
|
||||
|
||||
### 工作单元结构
|
||||
|
||||
```typescript
|
||||
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 下一轮:
|
||||
|
||||
```markdown
|
||||
## 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)
|
||||
|
||||
```bash
|
||||
# 评审当前未提交的改动
|
||||
/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:
|
||||
```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."*
|
||||
|
||||
### 输出格式
|
||||
|
||||
```text
|
||||
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`)
|
||||
|
||||
```bash
|
||||
# 一个 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
|
||||
|
||||
```bash
|
||||
# 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)
|
||||
|
||||
```bash
|
||||
# 把 RFC 写到 ./rfc.md
|
||||
ralphinho init ./rfc.md
|
||||
ralphinho run
|
||||
|
||||
# Linear 集成可选(human-in-the-loop triage)
|
||||
```
|
||||
|
||||
### D. 自治改 bug / 加测试
|
||||
|
||||
**主路:** 模式 3(continuous-claude)
|
||||
|
||||
```bash
|
||||
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 优化]]
|
||||
- [[上下文腐烂与全新窗口隔离]]
|
||||
@@ -83,6 +83,44 @@ Legacy shim 仍然可用(向后兼容),只是内部转发到对应 skill
|
||||
|
||||
Rules 新增:java, kotlin, dart, csharp, cpp, rust, perl, php, web, zh (中文)
|
||||
|
||||
### Skill 放置策略 (新规范)
|
||||
|
||||
仓库新增 `docs/SKILL-PLACEMENT-POLICY.md`,明确 4 类 skill 的放置位置和归属:
|
||||
|
||||
| 类型 | 路径 | 提交仓库 | provenance |
|
||||
|------|------|---------|-----------|
|
||||
| **Curated**(人工策划) | `skills/` (repo) | ✅ | 用 frontmatter `origin` 字段 |
|
||||
| **Learned**(`/learn` 自动产出) | `~/.claude/skills/learned/` | ❌ | 必须 `.provenance.json` |
|
||||
| **Imported**(外部导入) | `~/.claude/skills/imported/` | ❌ | 必须 `.provenance.json` |
|
||||
| **Evolved**(instinct 聚类产出) | `~/.claude/homunculus/evolved/skills/` | ❌ | 继承自源 instinct |
|
||||
|
||||
`.provenance.json` 必填字段:`source`、`created_at`、`confidence` (0-1)、`author`。
|
||||
|
||||
**实操含义**:
|
||||
- `/learn` 学到的 skill 自动落到 `~/.claude/skills/learned/` —— 不要手动提交进 repo
|
||||
- `validate-skills.js` 只校验 `skills/` 下的 curated skill,忽略其他三类
|
||||
- 跨项目分享走 `/instinct-export` + `/instinct-import`,不直接 copy 文件
|
||||
|
||||
详见 [docs/SKILL-PLACEMENT-POLICY.md](https://github.com/affaan-m/everything-claude-code/blob/main/docs/SKILL-PLACEMENT-POLICY.md)。
|
||||
|
||||
### Token 优化新基线
|
||||
|
||||
仓库 `docs/token-optimization.md` 当前推荐配置:
|
||||
|
||||
```json
|
||||
{
|
||||
"model": "sonnet",
|
||||
"env": {
|
||||
"MAX_THINKING_TOKENS": "10000",
|
||||
"CLAUDE_CODE_SUBAGENT_MODEL": "haiku"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
- **`CLAUDE_CODE_SUBAGENT_MODEL=haiku`** 是新的省钱大头,子 agent 跑 Haiku 比默认便宜约 80%
|
||||
- ⚠️ **`CLAUDE_AUTOCOMPACT_PCT_OVERRIDE` 已被官方警告弃用** —— 该变量在新版 Claude Code 上只能让压缩更早触发,与延后目的相反,移除即可
|
||||
- `memory` MCP 默认装但无 skill/agent/hook 引用 → 项目级 `disabledMcpServers` 关掉
|
||||
|
||||
---
|
||||
|
||||
## 全部 65 Skills
|
||||
@@ -266,6 +304,14 @@ Rules 新增:java, kotlin, dart, csharp, cpp, rust, perl, php, web, zh (中文
|
||||
### v1.8.0 新增
|
||||
`/loop-start` `/loop-status` `/model-route` `/quality-gate` `/harness-audit` `/promote`
|
||||
|
||||
### 验证 & 会话
|
||||
`/checkpoint`(verification-loop 检查点)`/verify`(完整验证管道)`/sessions`(会话历史)`/security-scan`(AgentShield 扫描)
|
||||
|
||||
### REPL & 工具
|
||||
`/claw`(NanoClaw REPL,模型路由 + 技能热加载 + 会话分支)`/projects`(continuous-learning v2 项目管理)`/setup-pm`(包管理器配置)
|
||||
|
||||
> 完整命令 → agent 映射见仓库 [docs/COMMAND-AGENT-MAP.md](https://github.com/affaan-m/everything-claude-code/blob/main/docs/COMMAND-AGENT-MAP.md)。
|
||||
|
||||
---
|
||||
|
||||
## Hooks 系统
|
||||
@@ -303,6 +349,7 @@ ECC_DISABLED_HOOKS="pre:bash:tmux-reminder,post:edit:typecheck"
|
||||
### Resources
|
||||
- [[Everything Claude Code 方法论与最佳实践]]
|
||||
- [[Everything Claude Code 用法速查]]
|
||||
- [[ECC 编排实战手册]] — 6 种编排模式真实命令 + 实战搭配 + 来源标注
|
||||
- [[Autonomous Loops 自主循环模式]]
|
||||
- [[dmux 多Agent并行编排]]
|
||||
- [[Ralphinho RFC-DAG 编排模式]]
|
||||
|
||||
@@ -242,15 +242,7 @@ ECC 最独特的创新 — **本能学习系统**。
|
||||
# Feature development: start new feature (清除调试噪音)
|
||||
```
|
||||
|
||||
禁用自动压缩的配置:
|
||||
|
||||
```json
|
||||
{
|
||||
"env": {
|
||||
"CLAUDE_AUTOCOMPACT_PCT_OVERRIDE": "50"
|
||||
}
|
||||
}
|
||||
```
|
||||
> ⚠️ **不要再设 `CLAUDE_AUTOCOMPACT_PCT_OVERRIDE`**。仓库 `docs/token-optimization.md` 现已警告:该变量在新版 Claude Code 上只能"降低阈值"(让压缩**更早**触发),与延后压缩的目的完全相反。完全靠手动 `/compact` + `strategic-compact` skill 控制压缩时机。
|
||||
|
||||
### 6. Verification Loop(验证循环)
|
||||
|
||||
@@ -316,13 +308,16 @@ ECC 最独特的创新 — **本能学习系统**。
|
||||
"model": "sonnet",
|
||||
"env": {
|
||||
"MAX_THINKING_TOKENS": "10000",
|
||||
"CLAUDE_AUTOCOMPACT_PCT_OVERRIDE": "50"
|
||||
"CLAUDE_CODE_SUBAGENT_MODEL": "haiku"
|
||||
}
|
||||
}
|
||||
// → ~60% 成本降低 (Sonnet vs Opus)
|
||||
// → ~70% thinking 成本降低
|
||||
// → ~80% 子 agent 成本降低 (Haiku 跑 Task 工具派发的子 agent)
|
||||
```
|
||||
|
||||
⚠️ **不要再设 `CLAUDE_AUTOCOMPACT_PCT_OVERRIDE`** —— 仓库现已警告该变量在新版只会让压缩更早触发,改用手动 `/compact`。
|
||||
|
||||
**模型选择策略**:
|
||||
|
||||
| 模型 | 场景 | 能力/成本比 |
|
||||
@@ -336,7 +331,8 @@ ECC 最独特的创新 — **本能学习系统**。
|
||||
- 启用的 MCP <= 10 个,活跃工具总数 <= 80 个
|
||||
- 10+ MCP 时,有效上下文从 200K 降至 ~70K tokens
|
||||
- 用 `disabledMcpServers` 禁用不用的
|
||||
- 重操作优先用 CLI(如 `gh`)而不是 MCP
|
||||
- **默认安装的 `memory` MCP 没有任何 skill/agent/hook 引用 → 优先关掉**(仓库 `docs/token-optimization.md` 明确建议)
|
||||
- 重操作优先用 CLI(如 `gh`、`aws`)而不是 MCP wrapper
|
||||
- 使用 `llms.txt` 模式(如 `vercel.com/docs/llms.txt`)代替 MCP 获取文档
|
||||
|
||||
### 会话管理
|
||||
|
||||
@@ -7,7 +7,7 @@ source: "https://github.com/affaan-m/everything-claude-code"
|
||||
|
||||
# Everything Claude Code 用法速查
|
||||
|
||||
按使用场景分类的快速参考手册。组件完整列表见 [[Everything Claude Code 完整指南]]。方法论深度分析见 [[Everything Claude Code 方法论与最佳实践]]。
|
||||
按使用场景分类的快速参考手册。组件完整列表见 [[Everything Claude Code 完整指南]]。方法论深度分析见 [[Everything Claude Code 方法论与最佳实践]]。**编排深度实战见 [[ECC 编排实战手册]]**(6 种模式真实命令 + 决策树)。
|
||||
|
||||
> **命名空间**: 通过插件安装的 ECC,命令需加 `everything-claude-code:` 前缀。本文用短名书写,实际使用时如 `/plan` → `/everything-claude-code:plan`。完整映射表见 [[Everything Claude Code 方法论与最佳实践#命令名映射速查]]。
|
||||
|
||||
@@ -79,14 +79,32 @@ source: "https://github.com/affaan-m/everything-claude-code"
|
||||
|
||||
## 三、按高级场景分类
|
||||
|
||||
### 1. 多模型协作
|
||||
### 1. 编排模式选择(优先看)
|
||||
|
||||
详见 [[ECC 编排实战手册]]。决策树:
|
||||
|
||||
| 想要 | 用什么 | 备注 |
|
||||
|------|--------|------|
|
||||
| 单功能全流程 | `/feature-dev` | 7 阶段:Discovery → Exploration → Clarifying → Architecture → Implementation → Review → Summary |
|
||||
| 顺序分步 | `/plan` → `/tdd` → `/code-review` | 最朴素也最稳 |
|
||||
| 双评审兜底 | `/santa-loop` | Claude Opus + Codex/Gemini 双独立评审,3 轮收敛 |
|
||||
| 多 worktree 并行 | `node scripts/orchestrate-worktrees.js plan.json --execute` | 需 tmux,看 [[dmux 多Agent并行编排]] |
|
||||
| 多日 PR 自治 | `continuous-claude` 外部工具 | 不属于 ECC,看 [[Autonomous Loops 自主循环模式]] |
|
||||
| 大 RFC + DAG | `ralphinho` 外部工具 | 不属于 ECC |
|
||||
| 启动 ECC 内置循环 | `/loop-start [pattern] [--mode safe\|fast]` | pattern: sequential / continuous-pr / rfc-dag / infinite |
|
||||
|
||||
> ⚠️ `/orchestrate` 是 **legacy shim**,转发到 `dmux-workflows` skill。新项目优先用 `/feature-dev` 或上面的组合。
|
||||
|
||||
### 2. 多模型协作 (需外部 CLI)
|
||||
|
||||
⚠️ **`/multi-*` 系列依赖 `~/.claude/bin/codeagent-wrapper` + 外部 codex/gemini CLI**(`ccg` 协议),不是 ECC 标配。装不上就用编排手册里的模式 1-3、5、6 替代。
|
||||
|
||||
| 命令 | 用途 |
|
||||
| ----------------- | ----------------------------------- |
|
||||
| `/multi-plan` | Claude + Codex + Gemini 并行规划 |
|
||||
| `/multi-execute` | 跨多个模型后端并行执行 |
|
||||
| `/multi-frontend` | 多前端框架并行开发(React/Vue/Svelte/Angular) |
|
||||
| `/multi-backend` | 多后端栈并行开发(Node/Python/Go/Java) |
|
||||
| `/multi-frontend` | 多前端框架并行开发(React/Vue/Svelte/Angular) |
|
||||
| `/multi-backend` | 多后端栈并行开发(Node/Python/Go/Java) |
|
||||
| `/multi-workflow` | 复杂多服务编排 |
|
||||
|
||||
### 2. 自主循环
|
||||
@@ -163,10 +181,13 @@ source: "https://github.com/affaan-m/everything-claude-code"
|
||||
| 更新文档 | `/update-docs` |
|
||||
| 审查 Python 代码 | `/python-review` |
|
||||
| 审查 Go 代码 | `/go-review` |
|
||||
| 多模型并行出方案 | `/multi-plan` |
|
||||
| 多模型并行出方案 | `/multi-plan`(需外部 CLI) |
|
||||
| 启动自主循环 | `/loop-start` |
|
||||
| 评估 harness 质量 | `/harness-audit` |
|
||||
| 从会话中学习模式 | `/learn` |
|
||||
| 单功能全流程一条龙 | `/feature-dev` |
|
||||
| 上线前对抗式双评审 | `/santa-loop` |
|
||||
| 多任务 worktree 并行 | `node scripts/orchestrate-worktrees.js plan.json --execute` |
|
||||
|
||||
---
|
||||
|
||||
@@ -175,6 +196,11 @@ source: "https://github.com/affaan-m/everything-claude-code"
|
||||
### Resources
|
||||
- [[Everything Claude Code 完整指南]]
|
||||
- [[Everything Claude Code 方法论与最佳实践]]
|
||||
- [[ECC 编排实战手册]]
|
||||
- [[ECC 编排替代方案 (orchestrate 迁移)]]
|
||||
- [[Autonomous Loops 自主循环模式]]
|
||||
- [[dmux 多Agent并行编排]]
|
||||
- [[Ralphinho RFC-DAG 编排模式]]
|
||||
|
||||
### Zettelkasten
|
||||
- [[Everything Claude Code 最佳实践]]
|
||||
|
||||
@@ -20,9 +20,13 @@ source: "https://github.com/affaan-m/everything-claude-code"
|
||||
90% 任务用 Sonnet,只在架构决策和安全分析时用 Opus,搜索探索用 Haiku。设置:
|
||||
|
||||
```json
|
||||
{ "model": "sonnet", "env": { "MAX_THINKING_TOKENS": "10000", "CLAUDE_AUTOCOMPACT_PCT_OVERRIDE": "50" } }
|
||||
{ "model": "sonnet", "env": { "MAX_THINKING_TOKENS": "10000", "CLAUDE_CODE_SUBAGENT_MODEL": "haiku" } }
|
||||
```
|
||||
|
||||
`CLAUDE_CODE_SUBAGENT_MODEL=haiku` 是省钱新核心 —— 子 agent(通过 Task 工具派发的)跑 Haiku,比默认便宜约 80%,文件读取/探索质量基本无损。
|
||||
|
||||
> ⚠️ **不要再设 `CLAUDE_AUTOCOMPACT_PCT_OVERRIDE`**。仓库 `docs/token-optimization.md` 已警告:该变量在新版 Claude Code 上只能"降低阈值"(让压缩更早触发),与延后压缩的目的相反。改用手动 `/compact` + `strategic-compact` skill。
|
||||
|
||||
用 mgrep 替代 grep 可减少约 50% token 使用。
|
||||
|
||||
## 记忆持久化
|
||||
|
||||
@@ -12,9 +12,12 @@ source: "https://github.com/affaan-m/everything-claude-code"
|
||||
### 1. 模型路由
|
||||
90% 任务用 Sonnet,Haiku 做搜索/文档,Opus 只用于架构和安全。用 `/model-route` 自动路由。
|
||||
|
||||
**子 agent 强制用 Haiku** —— 设置 `CLAUDE_CODE_SUBAGENT_MODEL=haiku`,所有通过 Task 工具派发的子 agent 都跑 Haiku,比默认便宜约 80%,文件读取/探索质量基本无损。这是新版的省钱大头。
|
||||
|
||||
### 2. MCP 精简
|
||||
- 保持 < 10 个 MCP 启用
|
||||
- 用 CLI + skill 替代 MCP wrapper(如 gh CLI 替代 GitHub MCP)
|
||||
- 用 CLI + skill 替代 MCP wrapper(如 `gh` 替代 GitHub MCP、`aws` 替代 AWS MCP)
|
||||
- 默认安装的 `memory` MCP 没有任何 skill/agent/hook 引用 → 优先关掉
|
||||
- 每个 MCP 消耗上下文窗口,多到一定程度 200k 变 70k
|
||||
|
||||
### 3. 工具替换
|
||||
@@ -30,11 +33,13 @@ mgrep 替代 grep/ripgrep,在 50 任务 benchmark 中减少约 2x token 使用
|
||||
"model": "sonnet",
|
||||
"env": {
|
||||
"MAX_THINKING_TOKENS": "10000",
|
||||
"CLAUDE_AUTOCOMPACT_PCT_OVERRIDE": "50"
|
||||
"CLAUDE_CODE_SUBAGENT_MODEL": "haiku"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
> ⚠️ **不要再设 `CLAUDE_AUTOCOMPACT_PCT_OVERRIDE`**。仓库 `docs/token-optimization.md` 已警告:该变量在新版 Claude Code 上只能"降低阈值"(让压缩更早触发),与延后压缩的目的相反。改用手动 `/compact` + `strategic-compact` skill 控制压缩时机。
|
||||
|
||||
## Skill 的渐进式加载
|
||||
|
||||
Skill 启动时只读描述(约 100 tokens),只在相关时才加载完整内容。这比把所有内容放在 CLAUDE.md 系统提示中高效得多。
|
||||
|
||||
@@ -15,7 +15,8 @@ source: "https://github.com/affaan-m/everything-claude-code"
|
||||
**最佳实践**:
|
||||
- 活跃 MCP <= 10 个,活跃工具总数 <= 80 个
|
||||
- 用 `disabledMcpServers` 动态禁用不用的
|
||||
- 重操作优先用 CLI(如 `gh`)而不是 MCP
|
||||
- **默认安装的 `memory` MCP 没有任何 skill/agent/hook 引用 → 优先关掉**(仓库 `docs/token-optimization.md` 明确建议)
|
||||
- 重操作优先用 CLI(如 `gh`、`aws`)而不是 MCP wrapper
|
||||
- 使用 `llms.txt` 模式获取文档,避免 MCP 常驻开销
|
||||
|
||||
这是 Claude Code 性能优化中**最重要的单一因素** — 比任何 Agent 或 Skill 都重要。
|
||||
|
||||
Reference in New Issue
Block a user