delegation-protocol

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

delegation-protocol

The main thread is a decision-maker with a scarce context window, not a worker. Everything it reads itself, it pays for on every subsequent turn.

Scope boundary — these compose in sequence, they do not compete: how to farm work out → here; whether the result means the task is done →

completion-gate

; the mechanics of committing → your commit-workflow skill.

main thread是具备有限上下文窗口的决策者，而非执行工作的角色。它自行读取的所有内容，都会在后续每一轮交互中产生成本。

范围边界 —— 以下规则按顺序构成，互不冲突： 如何分配工作 → 本文档；判断结果是否意味着任务完成 →

completion-gate

；提交的具体流程 → 你的commit-workflow技能。

When to Invoke

何时调用

About to read a lot of files, grep a repo, or look something up.
About to make the same mechanical edit across many files.
Something needs verifying or reviewing.
Writing a prompt for a subagent, or choosing which tier to spawn.
About to run agents in parallel.
A subagent just reported back.
Tempted to suggest the user switch the conversation's model.
Your last search/grep/read on this exact target (same repo, same symbol, same file set) didn't fully resolve it and you're about to run another one — that's the "don't know which file it's in" threshold firing right now, not a reason to narrow once more yourself.

即将读取大量文件、搜索代码仓库，或查找某类信息时。
即将对多个文件执行相同的机械性编辑操作时。
需要进行验证或评审工作时。
为subagent编写提示词，或选择要生成的模型层级时。
即将并行运行agent时。
subagent刚返回报告结果时。
想要建议用户切换对话所用模型时。
你针对同一目标（相同仓库、相同符号、相同文件集）的上一次搜索/查找/读取未完全解决问题，且即将再次执行操作时——这意味着“不知道目标所在文件”的阈值已触发，而非需要自行进一步缩小范围的理由。

Core Rules

核心规则

[NEVER VIOLATE] Never run two agents in parallel if both may write to the same file. Whichever finishes second silently overwrites the first — no error, no conflict marker, no trace. Parallelise reading and analysis; serialise writing.
[NEVER VIOLATE] When delegating a verification or review, hand over the artifact and the acceptance criteria only — never your reasoning, your draft rationale, or your defence of the work. A reviewer who has read your argument reviews your argument. The entire value of a fresh context is that it does not already believe you. Anchor it and you have converted a gate into a rubber stamp — while still paying for it, and still feeling reassured.
Hitting a threshold means delegate, not "consider delegating". The numbers below are deliberately numbers. A vague threshold never fires.
Do not accept a delegated result wholesale. See the last section.

[绝对禁止违反] 若两个agent可能写入同一文件，切勿并行运行它们。 后完成的操作会静默覆盖先完成的结果——无错误提示、无冲突标记、无任何痕迹。读取和分析工作可并行执行；写入操作必须串行执行。
[绝对禁止违反] 委托验证或评审任务时，仅交付工件和验收标准——绝不要提供你的推理过程、草稿理由或对工作的辩护内容。 读过你论点的评审者，只会评审你的论点。全新上下文的核心价值在于它不会预先认同你的观点。若引入锚定信息，你就把一个把关环节变成了橡皮图章——却仍要为此付费，还会误以为得到了可靠的确认。
触发阈值意味着必须委托，而非“考虑委托”。 以下数值是明确的硬性标准。模糊的阈值永远无法有效触发。
切勿全盘接受委托返回的结果。 详见最后一节。

Hard Thresholds

硬性阈值

Situation	Action
You expect to read more than 3 files or more than 400 lines to answer	Search agent
You do not know which file the thing is in	Search agent
Looking up web pages or official documentation	Delegate
The same mechanical change across more than 5 files	Cheap agent executes; you spot-check
Any judgement-level verification or review	Fresh-context agent (mechanical checks you may run yourself — see `completion-gate` )

⚠️ The "don't know which file it's in" row fires the moment a first search attempt doesn't resolve it — not after several. Each subsequent narrowing grep on the same target feels like progress; measured against the rule, it's the same "don't know which file" state repeating. Treat a second attempt on the same target as the trigger, not a fourth.

"It's faster if I just do it myself" is an illusion at the main-thread level. It is faster this turn. The context burned is repaid with interest on every turn afterwards, and the debt stays invisible until the thread starts forgetting things it was told.

Do not renegotiate a threshold because this case feels like an exception. If a threshold is genuinely wrong, change it deliberately, with evidence, outside the task that tripped it.

场景	操作
你预计需要读取超过3个文件或超过400行内容才能找到答案	委托给Search agent
不知道目标所在的文件	委托给Search agent
查找网页或官方文档	委托处理
对超过5个文件执行相同的机械性修改	由Cheap agent执行；你进行抽查
任何需要判断的验证或评审工作	委托给具备全新上下文的agent（机械性检查可自行执行——参见 `completion-gate` ）

⚠️ “不知道目标所在文件”的规则在首次搜索尝试未解决问题时立即触发——而非多次尝试之后。 针对同一目标的后续缩小范围搜索看似在推进，但根据规则，这仍属于“不知道目标所在文件”的重复状态。将第二次尝试视为触发点，而非第四次。

“我自己做更快”在main thread层面是一种错觉。 仅当前这一轮会更快，但消耗的上下文资源会在后续每一轮交互中产生复利成本，且这种消耗是隐形的，直到线程开始遗忘之前接收的信息。

不要因为某个案例看似特殊就重新协商阈值。若阈值确实不合理，请在触发它的任务之外，基于证据进行针对性修改。

If This Environment Has No Subagents

若当前环境无subagent可用

Not every harness can spawn agents, and some runs are non-interactive. Then:

The thresholds become a budget warning rather than a dispatch instruction: the work still costs context, so do it in the smallest slice that answers the question, write intermediate findings to a file, and work from the file.
Judgement-level verification cannot be faked by doing it yourself. Run every deterministic mechanical check available, then follow
```
completion-gate
```
's "When No Subagent Is Available" procedure in full — starting with its first step, which is to check whether a human can be the fresh reader before anything gets downgraded. That procedure is not restated here on purpose: one copy, one place to change it.
Never treat the absence of a reviewer as permission to self-certify.

并非所有框架都能生成agent，部分运行环境是非交互式的。此时：

阈值将变为预算警告而非调度指令：工作仍会消耗上下文，因此应采用最小切片方式完成以获取答案，将中间结果写入文件，并基于文件开展后续工作。
需要判断的验证工作无法通过自行执行来替代。请运行所有可用的确定性机械检查，然后完整遵循
```
completion-gate
```
中的“无subagent可用时”流程——从第一步开始，即先确认是否可以让人类作为全新评审者，再考虑其他降级方案。本文未重述该流程是有意为之：仅保留一份副本，便于统一修改。
绝不要将无评审者可用视为自我认证的许可。

Every Delegation Prompt Needs Three Things

每份委托提示词需包含三要素

Missing any one, do not send it:

Goal and motivation — what this is for, and who consumes the result. An agent that knows why produces a usable answer; one that doesn't produces a technically-responsive one.
Acceptance criteria — objectively checkable. If you cannot write these, you have not thought the task through; that is the finding, not the agent's problem.
Reporting format — field by field. "Report your findings" returns an essay you then have to read, which defeats the point.

缺少任意一项，请勿发送：

目标与动机 —— 任务的用途，以及结果的受众。知晓动机的agent会生成可用的答案；不知晓的则只会生成技术上符合要求但实用性不足的结果。
验收标准 —— 可客观验证的标准。若你无法写出这些标准，说明你尚未理清任务要求；这是你的问题，而非agent的问题。
报告格式 —— 分字段明确要求。仅说“报告你的发现”会返回一篇你需要自行阅读的长文，这违背了委托的初衷。

The Reporting Contract (paste into every delegation prompt)

报告约定（粘贴到每份委托提示词中）

Conclusions only, anchored as
```
file:line
```
.
Long output goes to a file; report the path plus a three-line summary.
Copy numbers exactly — never round, rephrase, or tidy a figure.
"Not found" is a valid answer. Say so plainly; never fill the gap with something plausible.
Never paste whole files back.

仅提供结论，并以
```
file:line
```
格式标注来源。
长输出需写入文件；仅报告文件路径及三行摘要。
精确复制数值——绝不四舍五入、改写或整理数据。
“未找到”是有效的答案。 请直接说明；切勿用看似合理的内容填补空白。
绝不要返回完整文件内容。

Choosing a Tier

选择模型层级

Think in tiers, not model names — names and IDs change, tiers don't:

Tier	Use for
Cheap	Mechanical work, inventories, read-backs, bulk edits
Standard	Ordinary search, implementation, routine review — and the main thread
Expensive	Genuine judgement calls, adversarial review, second opinions
Premium	Rare. Confirm before spending it (nobody to confirm with → don't).

Do not keep a table of exact model IDs, prices, or feature-support matrices in your rules or skills. It is a copy of vendor documentation: it goes stale silently, and a stale copy is worse than none because it is believed. Use the harness's own alias or tier selector where one exists. Where the harness insists on a concrete identifier and offers no lookup, state the tier you intended and take the harness default — do not reconstruct an identifier from memory.

以层级而非模型名称思考——名称和ID会变化，但层级不会：

层级	适用场景
Cheap	机械性工作、清单整理、内容回读、批量编辑
Standard	常规搜索、实现开发、日常评审——以及main thread
Expensive	真正需要判断的决策、对抗性评审、二次意见
Premium	极少使用。使用前需确认（无人可确认时请勿使用）。

请勿在规则或技能中保留精确的模型ID、价格或功能支持矩阵。 这些是供应商文档的副本：会悄然过时，而过时的副本比没有更糟，因为你会误以为它是准确的。若框架提供别名或层级选择器，请使用该功能。若框架要求使用具体标识符且无查询功能，请说明你想要的层级并采用框架默认值——切勿凭记忆重构标识符。

Escalation

升级机制

Cheap tier fails acceptance once → go straight to standard. No second attempt: another round-trip plus re-verification costs more than escalating.
Standard tier fails twice on the same subtask → escalate to the expensive tier with the full failure trace. Escalating without the trace just buys a more expensive repetition of the same mistake.
Once the expensive tier finds the pattern, drop back to a cheap tier to apply it across the remaining cases.

⚠️ When you need a stronger model, spawn a subagent at that tier — do not ask the user to switch the conversation's model. On providers that use prompt caching, switching the main thread's model invalidates the cache, so the whole conversation history is re-sent uncached on the next call. Measured on one real session: of 7 observed cache breaks, 6 immediately followed a manual model switch, averaging ~294k tokens burned per switch (single-session sample, one provider — the magnitude will differ elsewhere, and on a provider without prompt caching this particular cost does not apply). A subagent costs only its own call and leaves the main thread's cache intact. Suggest a manual switch only when the work genuinely cannot be delegated — it needs continuous back-and-forth with the user rather than being a self-contained subtask — and weigh the rebuild cost first.

Cheap tier未通过验收一次 → 直接升级到Standard tier。不要进行第二次尝试：再一轮往返加上重新验证的成本，比直接升级更高。
Standard tier在同一子任务上失败两次 → 升级到Expensive tier，并附带完整的失败痕迹。不提供失败痕迹的升级，只会导致更昂贵的重复错误。
一旦Expensive tier找到问题模式，可降级到Cheap tier将其应用到剩余案例中。

⚠️ 当你需要更强大的模型时，生成对应层级的subagent——不要要求用户切换对话的模型。 在使用提示缓存的服务商处，切换main thread的模型会使缓存失效，因此下一次调用时会重新发送整个对话历史且无缓存支持。基于一个真实会话的测量：观察到的7次缓存失效中，有6次紧随手动模型切换，每次切换平均消耗约29.4k tokens（单会话样本，单一服务商——不同服务商的数值会有差异，无提示缓存的服务商则不会产生此项成本）。subagent仅需承担自身调用的成本，且不会影响main thread的缓存。仅当工作确实无法委托（需要与用户持续交互，而非独立子任务）时，才建议手动切换模型，且需先权衡缓存重建的成本。

When the Result Comes Back

结果返回后的处理

Spot-check one or two load-bearing claims. Any number heading into a deliverable needs a second source.
Warning signs: the report is suspiciously clean, or states a key fact you have never seen first-hand evidence for.
⚠️ "X does not exist" is a far stronger claim than "X exists" and needs correspondingly more evidence — recorded twice in practice, the second time while writing up the first. Before accepting a non-existence result, check the search actually covered backup directories, lock files, and alternate locations — not just the obvious live path. A search that only proves "not in the place I looked" is routinely written up as "never existed".

抽查一到两个关键结论。 任何将纳入交付物的数值都需要二次验证。
预警信号：报告异常简洁，或陈述了你从未见过第一手证据的关键事实。
⚠️ “X不存在”比“X存在”的断言强度高得多，因此需要相应更多的证据 —— 在实践中需验证两次，第二次在整理第一次结果时进行。在接受“不存在”的结果前，需确认搜索确实覆盖了备份目录、锁定文件和其他备选位置——而非仅搜索了明显的活跃路径。仅证明“未在我查找的位置找到”的搜索结果，常被误写为“从未存在”。