Smart Subagent Dispatch
Most agentic coding sessions burn tokens by spawning a full-price subagent for every delegated task — including ones that are just "go read these five files and tell me what's there." That's a pure lookup, and a small/cheap model does it exactly as well as your primary model for a fraction of the cost. The trap is doing the opposite: pushing a task that actually requires judgment onto a cheap model and silently trusting whatever it returns.
This skill is the classification step that goes before you spawn a subagent.
Step 1 — Classify the task
- Pure retrieval: search for references, list matching files, count call sites, format/reformat, read a file and state its literal contents. → route to a cheap/fast model (e.g. Haiku-tier).
- Diagnostic: root-causing an error, cross-file causal analysis, judging why behavior doesn't match expectation. → keep the primary model. Do not downgrade.
- Hybrid (needs both retrieval and judgment — e.g. "find every place X is called, and tell me which ones would cause Y"): → split it into two steps. Cheap model does the retrieval pass first; the primary model then reasons over that output. Never let a cheap model attempt a hybrid task in one shot — the "judgment" half quietly gets skipped or hallucinated.
Step 2 — The actual test
Ask what the subtask's output looks like:
- If the output is a fact list (file path + line number + literal content, no interpretation) → cheap model is fine.
- If the output has to contain "why" — reasoning, a causal claim, a judgment call → do not downgrade.
If you're not sure which bucket a task falls into, default to diagnostic (no downgrade). The point of this skill is saving tokens without paying for it in wrong answers — when in doubt, don't gamble the answer's correctness to save a fraction of a cent.
Step 3 — Verify before you trust it (this is the step people skip)
A cheap-model retrieval pass is not automatically correct. Once it comes back:
- The primary model does a fast pass over the returned file paths/line numbers to confirm they're actually right.
- Pay extra attention on anything involving same-named variables across scopes, cross-scope references, or multi-hop call chains — this is exactly where small models under-report edge cases.
- Unverified cheap-model output must never be used directly as the basis for a subsequent diagnosis or an edit. Spot-check it first, every time.
The principle
Token savings are only a win if they don't cost you decision quality. If a task's category is ambiguous, that ambiguity itself is a signal to not downgrade — the failure mode of a wrong "cheap and fast" call is much more expensive than the tokens it saved.
Adapt, don't copy-paste. This is the shape of the idea, not a config to drop in verbatim — the exact thresholds (which tasks count as "hybrid," how deep the verification pass goes) should be tuned against your own project's actual failure patterns.
智能子代理调度
大部分 agent 编程 session 都在做一件浪费 token 的事:每一个委派出去的任务都用全价模型跑一遍子代理——哪怕这个任务只是"去读这五个文件,告诉我里面有什么"。这种纯查找类任务,便宜/快速的小模型跟你的主模型做得一样好,成本却低一大截。真正的坑在反方向:把一个其实需要判断力的任务丢给小模型,然后不加核实就直接采信它的结论。
这个 skill 就是派发子代理之前的那一步分类判断。
第一步:任务分类
- 纯检索类:搜索引用、列出匹配文件、统计调用位置、格式化/重排、读文件并原样陈述内容 → 派给便宜/快的模型(如 Haiku 档位)
- 诊断类:定位报错根因、跨文件因果分析、判断"为什么"逻辑不符预期 → 保持主模型,不降级
- 混合类(既要检索又要判断,例如"找出所有调用 X 的地方,并判断哪些会导致 Y 问题") → 拆成两步:先用便宜模型做检索,再让主模型基于检索结果做判断。禁止让便宜模型一步到位完成混合任务——"判断"那一半会被悄悄跳过或编造。
第二步:真正的判断标准
问子任务的输出长什么样:
- 输出是"事实清单"(文件路径 + 行号 + 原文内容,不含解释)→ 用便宜模型没问题
- 输出必须包含"为什么"——推理、因果判断、下结论 → 禁止降级
不确定任务属于哪一类时,默认归为诊断类(不降级)。这个 skill 的意义是"省 token 但不牺牲答案质量"——不确定的时候,别为了省一点点钱去赌答案对不对。
第三步:采信前先核实(这一步最容易被跳过)
便宜模型跑出来的检索结果不会自动就是对的。拿到结果后:
- 主模型要快速复核一遍返回的文件路径/行号是否准确
- 涉及同名变量跨 scope、跨作用域引用、多层调用链的任务,复核时要重点检查是否漏掉边界情况——这正是小模型最容易漏报的地方
- 未经核实的便宜模型输出,不能直接作为后续诊断或修改的依据——每次都要先抽查
核心原则
省 token 的前提是不能牺牲决策质量。如果一个任务的类别本身就模糊不清,这种模糊本身就是"别降级"的信号——一次廉价模型判断错误的代价,远比省下来的那点 token 贵得多。
别照搬,自己微调。这里给的是思路的骨架,不是一份可以直接粘贴进项目的配置——具体阈值(什么算"混合类"、复核要查到多细)应该根据你自己项目里真实踩过的坑来调整。