cavecrew

Cavecrew = 三个子代理预设，输出穴居人风格结果。与 Anthropic 默认代理（Explore、编辑型代理、审查者）功能相同；区别在于它们返回的工具结果经过压缩，因此每次委托都会缩小主上下文。

何时使用 cavecrew 与替代方案

任务	使用
“X 在哪里定义 / 谁调用了 Y / 列出 Z 的使用”	cavecrew-investigator
同上，但还想要建议/架构评论	Explore（普通）
精确编辑，≤2 个文件，范围明确	cavecrew-builder
新功能 / 3+ 文件 / 跨领域重构	主线程或 feature-dev:code-architect
审查差异、分支或文件中的错误	cavecrew-reviewer
带有理由和替代方案的深度代码审查	Code Reviewer（普通）
你已经知道答案的一行回答	主线程，无需子代理

经验法则：如果你希望子代理的输出只用 1/3 的 token，选择 cavecrew。如果你希望得到散文，选择普通版本。

为什么存在（真正的优势）

子代理工具结果会被逐字注入主上下文。一个普通的 Explore 返回 2k token 的散文，每次消耗 2k token 的主上下文预算。同样的发现来自 cavecrew-investigator 只返回约 700 token。在一次会话中委托 20 次，这就是上下文耗尽和完成任务之间的区别。

输出契约

主线程可以依赖每个代理的以下内容：

cavecrew-investigator

<Header>:
- path:line — `symbol` — 简短说明
totals: <counts>.

或者 No match. 始终是文件路径优先、行号附加、反引号包裹的符号。可以安全地用 path:\d+ 进行 grep。

cavecrew-builder

<path:line-range> — <变化 ≤10 个词>.
verified: <re-read OK | mismatch @ path:line>.

或者以下之一：too-big. / needs-confirm. / ambiguous. / regressed.（终端第一个 token）。

cavecrew-reviewer

path:line: <emoji> <severity>: <问题>. <修复>.
totals: N🔴 N🟡 N🔵 N❓

或者 No issues. 结果按文件 → 行号升序排列。

链式模式

定位 → 修复 → 验证（最常见）：

1. cavecrew-investigator 返回位置列表。
2. 主线程选择 1-2 个位置，将路径交给 cavecrew-builder。
3. cavecrew-reviewer 审计差异。

并行侦察（当调查范围广泛时）：
在一条消息中生成 2-3 个 cavecrew-investigator 调用（不同角度：定义 vs 调用者 vs 测试）。在主线程中汇总。

单次编辑（当位置已知时）：
跳过 investigator。直接将精确的 path:line 交给 cavecrew-builder。

不要做什么

• 不要在你还不确定文件时使用 cavecrew-builder。先生成 investigator，否则主线程会消耗 token 传递上下文。
• 不要为 5 个文件的重构链式使用 cavecrew-investigator → cavecrew-builder。Builder 会返回 too-big.，你会浪费一次机会。
• 不要要求 cavecrew-reviewer 提供“一般性反馈”——它只返回发现，没有架构意见。使用 Code Reviewer 来获得架构意见。
• 不要期望散文。Cavecrew 输出是结构化的，有时简洁到令人费解。如果需要人类直接阅读，请转述。

自动清晰化（继承）

子代理在安全警告、不可逆操作确认以及任何片段歧义可能导致误读的输出中，会从穴居人风格切换为正常英语。之后恢复穴居人风格。