Back to Details

huicrew

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese
Huicrew = three subagent presets that emit hui output. Same job as Anthropic defaults (
Explore
, edit-style agents, reviewer); difference is the tool-result they return is compressed, so main context shrinks per delegation.
Huicrew是三个可输出hui格式内容的子代理预设。它们的功能与Anthropic的默认代理（
Explore
、编辑型代理、审查代理）一致；区别在于返回的工具结果经过压缩，因此每次委派任务都会缩小主线程上下文的体积。

When to use huicrew vs alternatives

何时选择Huicrew而非替代方案

TaskUse
"Where is X defined / what calls Y / list uses of Z"
huicrew-investigator
Same but you also want suggestions/architecture commentary
Explore
(vanilla)
Surgical edit, ≤2 files, scope obvious
huicrew-builder
New feature / 3+ files / cross-cutting refactorMain thread or 
feature-dev:code-architect
Review diff, branch, or file for bugs
huicrew-reviewer
Deep code review with rationale + alternatives
Code Reviewer
(vanilla)
One-line answer you already knowMain thread, no subagent
Rule of thumb: if you'd want the subagent's output in 1/3 the tokens, pick huicrew. If you'd want prose, pick vanilla.
任务使用对象
"X定义在哪里 / 谁调用了Y / 列出Z的所有用法"
huicrew-investigator
上述任务，但还需要建议/架构说明
Explore
（原生）
精准编辑，≤2个文件，范围明确
huicrew-builder
新功能开发 / 涉及3个及以上文件 / 跨模块重构主线程或
feature-dev:code-architect
审查差异、分支或文件中的bug
huicrew-reviewer
包含理由和替代方案的深度代码审查
Code Reviewer
（原生）
已知答案的简短问题主线程，无需子代理
经验法则：如果希望子代理的输出占用1/3的token数量，请选择huicrew；如果需要完整的描述性文本，请选择原生代理。

Why this exists (the real win)

设计初衷（核心优势）

Subagent tool results get injected into main context verbatim. A vanilla 
Explore
that returns 2k tokens of prose costs 2k tokens of main-context budget every time. The same finding from 
huicrew-investigator
returns ~700 tokens. Across 20 delegations in one session that's the difference between context exhaustion and finishing the task.
子代理的工具结果会直接注入主线程上下文。一个返回2000token文本内容的原生
Explore
，每次都会消耗2000token的主线程上下文预算。而
huicrew-investigator
返回相同的结果仅需约700token。在一个会话中进行20次任务委派时，这就是上下文耗尽与完成任务之间的区别。

Output contracts

输出约定

What main thread can rely on per agent:
huicrew-investigator
<Header>:
- path:line — `symbol` — short note
totals: <counts>.
Or 
No match.
Always file-path-first, line-number-attached, backticked symbols. Safe to grep with 
path:\d+
.
huicrew-builder
<path:line-range> — <change ≤10 words>.
verified: <re-read OK | mismatch @ path:line>.
Or one of: 
too-big.
/ 
needs-confirm.
/ 
ambiguous.
/ 
regressed.
(terminal first token).
huicrew-reviewer
path:line: <emoji> <severity>: <problem>. <fix>.
totals: N🔴 N🟡 N🔵 N❓
Or 
No issues.
Findings sorted file → line ascending.
主线程可依赖各代理的输出格式：
huicrew-investigator
<Header>:
- path:line — `symbol` — short note
totals: <counts>.
或返回
No match.
始终以文件路径优先，附带行号，符号使用反引号包裹。可安全使用
path:\d+
进行grep检索。
huicrew-builder
<path:line-range> — <change ≤10 words>.
verified: <re-read OK | mismatch @ path:line>.
或返回以下内容之一：
too-big.
/ 
needs-confirm.
/ 
ambiguous.
/ 
regressed.
（首词为终端标识）。
huicrew-reviewer
path:line: <emoji> <severity>: <problem>. <fix>.
totals: N🔴 N🟡 N🔵 N❓
或返回
No issues.
结果按文件→行号升序排列。

Chaining patterns

链式调用模式

Locate → fix → verify (most common):
  1. huicrew-investigator
    returns site list.
  2. Main thread picks 1-2 sites, hands paths to 
    huicrew-builder
    .
  3. huicrew-reviewer
    audits the diff.
Parallel scout (when investigation is broad): Spawn 2-3 
huicrew-investigator
calls in one message (different angles: defs vs callers vs tests). Aggregate in main thread.
Single-shot edit (when site is already known): Skip investigator. Hand exact path:line to 
huicrew-builder
directly.
定位→修复→验证（最常见）：
  1. huicrew-investigator
    返回位置列表。
  2. 主线程选择1-2个位置，将路径交给
    huicrew-builder
    。
  3. huicrew-reviewer
    审查差异。
并行侦察（当调查范围较广时）： 在一条消息中生成2-3个
huicrew-investigator
调用（从不同角度：定义、调用方、测试）。在主线程中汇总结果。
单次编辑（当位置已知时）： 跳过调查步骤。直接将精确的path:line交给
huicrew-builder
。

What NOT to do

禁忌操作

  • Don't use 
    huicrew-builder
    when you don't already know the file. Spawn investigator first or main thread will eat tokens passing context.
  • Don't chain 
    huicrew-investigator → huicrew-builder
    for a 5-file refactor. Builder will return 
    too-big.
    and you'll have wasted a turn.
  • Don't ask 
    huicrew-reviewer
    for "general feedback" — it returns findings only, no architecture opinions. Use 
    Code Reviewer
    for that.
  • Don't expect prose. Huicrew output is structured, sometimes terse to the point of cryptic. If a human will read it directly, paraphrase.
  • 当你不知道目标文件时，不要使用
    huicrew-builder
    。先生成调查代理，否则主线程会消耗大量token传递上下文。
  • 不要为涉及5个文件的重构任务链式调用
    huicrew-investigator → huicrew-builder
    。Builder会返回
    too-big.
    ，浪费一次调用机会。
  • 不要要求
    huicrew-reviewer
    提供“通用反馈”——它仅返回问题结果，不提供架构意见。此类需求请使用
    Code Reviewer
    。
  • 不要期望得到描述性文本。Huicrew的输出是结构化的，有时简洁到近乎晦涩。如果需要让人类直接阅读，请自行转述。

Auto-clarity (inherited)

自动清晰化（继承特性）

Subagents drop hui → normal English for security warnings, irreversible-action confirmations, and any output where fragment ambiguity could be misread. Resume hui after.
子代理会自动将hui格式转换为标准英语，用于安全警告、不可逆操作确认，以及任何可能因片段歧义导致误读的输出场景。之后会恢复为hui格式输出。