Distill 是一个主打「用更少 token 干更多事」的 AI 编程代理工具 🔥。它的子代理委托机制让主模型（Main model）把可执行的实施任务分发给独立的 Worker 子代理，自己只保留规划与审核，最终通过「自报 + 工具执行证据 + 独立 diff 复核」三重手段校验 Worker 的产出。这篇文章带你从零看懂这套任务分发与结果校验体系是如何运作的。

一、为什么要把任务分发给 Worker 子代理

在 Distill 中，主模型拥有整个会话：负责规划、拆分任务、审阅结果；而可选配置的Worker 模型专门跑主模型分派下来的子代理任务。官方路由文档用一张 ASCII 图概括了这种分工：

Main model: owns the session, plans, delegates, reviews | | | conversation delegated chunk Utility task (worker subagent) bounded payload report + diff -> main reviews

这种分层的直接收益是成本与速度：官方基准测试显示，在相同质量（9/9 冻结测试全通过）下，Distill 相比原生方式最多可节省87% 成本、快76%📉：

二、task工具：主模型发起委托的入口

主模型通过名为task的工具发起一次委托，工具名常量即TASK_TOOL_NAME。一次task调用的关键参数包括：

• prompt/description：任务规格（spec）与一句话描述
• subagent_type：Worker 类型（如explore、general-purpose、plan）
• model：显式指定子代理使用的模型（可选）
• run_in_background：是否后台执行
• resume_from：从上次已完成的子代理恢复续跑
• isolation/cwd：工作目录或隔离 worktree

分派前的四道预校验

在真正把请求交给协调器（coordinator actor）之前，TaskTool会做一系列急切校验，见 TaskTool::run：

校验通过后，后台模式会立即返回任务 ID 供轮询；阻塞模式则等待结果，若等待预算超时，协调器会自动把子代理转为后台任务，返回task_id供后续取回结果。

三、三类内置 Worker 与模型路由优先级

内置子代理类型

Distill 内置了三种 Worker 画像，定义在 distill-tool-types 的 task.rs：

• general-purpose：全能型，可搜索、分析多文件、执行命令，适合多步骤研究与复杂任务
• explore：只读探索型，没有文件编辑工具，专攻快速定位代码
• plan：只读「软件架构师」，探索代码库并产出实施计划，要求列出 3-5 个关键文件

每个类型的提示词模板都内置了工作策略约束，例如 explore 型明确要求「只回答被问到的问题，能答即停，并说明哪些内容无法确认」，见 EXPLORE_PROMPT。

模型路由：谁跑在主模型上，谁跑在 Worker 上

子代理的模型解析遵循一条清晰的优先级链，实现见 resolve_subagent_sampling_config：

[ subagents.models ] 配置固定 > 代理定义中的 model: > Worker 模型（被委托的新任务） > 父会话主模型

对应的路由规则（来自 jev-routing.md）：

判断一个子代理是否「有资格」落到 Worker 模型上的逻辑很紧凑，见 delegated_worker_eligible：必须是新会话（非 fork）、未显式指定模型、且不是plan/code-reviewer（除非决策层放行）。

Worker 纪律：注入的「执行手册」

一个跑在 Worker 模型上的全新子代理，系统提示词会被追加一段Worker 纪律（WORKER_DISCIPLINE），核心要求是：

• 只做规格里写的：不重构、不改名、不格式化、不加功能
• 遇到不匹配就停：代码与任务不符、或出现影响结果的开放决策时，停下上报而不是猜测
• 用最短命令验证：运行任务点名的检查，报告每条命令的退出状态与关键输出
• 报告保持紧凑：结尾给出「改动文件 + 检查命令 + 输出」的简报，50 词以内，不复述 patch 内容——因为主模型会独立检查真实 diff

子代理的通用提示词模板 subagent_prompt.md 还规定：最终消息是委托方唯一收到的内容，必须「先给结论，再给证据（path:line引用和每条命令及结果），最后说明哪些内容无法验证及原因」。

四、结果校验：不信任自报，三重独立证据

这是整套机制最有意思的部分——主模型不轻信Worker 的自述，而是拿到三份相互独立的证据：

1️⃣ 报告字节上限（防信息爆炸）

task_report_cap 根据子代理能力设定报告上限：能编辑文件或执行命令的子代理只有 3000 字节，只读类有 12000 字节。超长报告会被截断（优先在行边界），全文落盘并附注「完整报告已存至某路径」，见 cap_task_report。

2️⃣ 工具执行证据（harness 亲测）

worker_execution_evidence 由 harness 自己抓取子代理最后一批工具调用及其记录结果，包装成<worker_execution_evidence>块交给主模型，并标注truncated状态。即使子代理声称"测试通过"，主模型也能核对实际执行的命令与返回。

3️⃣ 独立 diff 复核（绕开子代理口径）

worker_repository_review 是真正的一票独立：harness 通过子代理自己的终端跑git status（对比启动前后，找出新增改动）加上其编辑工具实际触碰过的文件路径，只对该子代理真正改过的文件执行git diff HEAD，生成<repository_review>证据块。也就是说，主模型拿到的 diff 与 Worker 的自述完全解耦——Worker 报错了也没关系，diff 不会骗人。

如果 Worker 模型不可用、子代理回落到父模型运行，输出前还会插入一条显式警告，见 with_worker_fallback_warning：

Warning: worker modelxxxwas unavailable, so this subagent ran onyyy.

五、失败处理与续跑（resume）

• 恢复续跑：完成的成功子代理会在结果中携带resume_from提示（见 SubagentCompleted 输出），主模型可基于同一 ID 续跑，distill-subagent-resolution 负责续跑时的身份校验（类型/persona 匹配），且续跑时模型固定为源模型，显式model参数会被软忽略
• 自动转后台：阻塞等待超时的子代理会被协调器转为后台任务，完成后可通过 task output 工具轮询，或由 auto-wake 合成提示唤醒父会话
• 失败回传：result.success == false时直接把错误作为工具错误返回给主模型，主模型可带着具体错误重派任务（连续失败两次后按策略拆分任务或亲自接手）

六、关键源码文件速查

小结

Distill 的子代理委托机制可以浓缩为一句话：主模型负责"想"，Worker 负责"做"，harness 负责"验"。精准分发靠的是task工具的参数化规格 + 严格的模型路由优先级；结果校验靠的是报告截断、工具执行证据、独立 git diff 三重解耦。理解这套机制，就能明白 Distill 为何能在保持同等质量的前提下大幅压低 token 消耗。