Arbor 执行器任务书（Executor Brief）编写指南：用单假设实验契约驱动 scientific-agent-skills 中的 HTR 自主优化-迪斯科星球

Arbor 执行器任务书（Executor Brief）编写指南：用单假设实验契约驱动 scientific-agent-skills 中的 HTR 自主优化

【免费下载链接】scientific-agent-skillsTurn any AI agent into an AI Scientist. The #1 Agent Skills library for science, used by 190,000+ scientists worldwide. 165 ready-to-use validated skills plus 100+ scientific databases covering biology, chemistry, medicine, and drug discovery. Compatible with Cursor, Claude Code, Codex, Pi, Antigravity, and the open Agent Skills standard.项目地址: https://gitcode.com/GitHub_Trending/cl/scientific-agent-skills

本文聚焦于 scientific-agent-skills 仓库中 Arbor 技能配套的执行器任务书模板，系统讲解如何在 Hypothesis Tree Refinement（HTR）自主优化流程中，为每个短生命周期的执行器子代理（executor subagent）撰写一份精炼、假设绑定、契约清晰的任务书。读完本文，你将掌握任务书各字段的填写方法、基于 git worktree 的隔离调度方式、执行器应返回的四项结构化证据，以及协调者（coordinator）如何通过tree.py set-evidence与tree.py propagate将执行结果写回并抽象为可复用的研究经验。

Executor 在 HTR 中的角色：一个假设、一次实验、一份证据

在 skills/arbor/SKILL.md 描述的自主优化流程中，研究与工程被刻意拆分为两个长期不对称的角色：

协调者（coordinator）是常驻、跨多次循环存续的 Agent，它持有持久化的假设树（hypothesis tree），决定在何处展开搜索、采信哪些证据、何时剪枝、何时触发合并；
执行器（executor）则是一个短生命周期（short-lived）的子代理，每次只被派去测试一个假设，并在隔离的 git worktree中完成实现与评估，最后返回结构化证据即告结束。

任务书（brief）就是这两个角色之间的唯一契约：协调者负责写，执行器负责照着执行并返回数据。关于这套分工的理论依据，htr-methodology.md 解释得更为深入——每个树节点是一个研究单元n = <h_n, iota_n, mu_n>（假设、洞察、元数据），其中mu_n中记录的branch_ref只是指向外部 worktree 中产物状态的 git 引用，树本身并不复制代码；这保证了假设树状态紧凑，同时每个假设都能追溯到可验证的实现。执行器正是负责把"假设h_n"落成"可运行的实现与可复核的数字"的那个环节。

从实现层面看，协调者与执行器围绕的持久化状态位于运行目录的.arbor/下（tree.py 顶部 docstring）：tree.json保存节点、边、证据与洞察，run.json保存目标、评估器、预算与当前最优产物M_best的引用。执行器自身不直接触碰这份状态——它的产出物只有结构化文本与一个 git 引用，所有写回动作都由协调者完成。

写好任务书的三条原则

原文档开门见山地给出任务书的核心约束：保持精炼（keep the brief tight）。执行器真正需要的只有三样东西，除此之外一概是噪音：

假设（hypothesis）——它要验证的、可证伪的主张；
上下文（context）——足以让它把假设实现好的背景信息（当前最优产物、祖先与兄弟节点的既有洞察、目标与评估器）；
返回契约（contract）——清晰界定"最终返回什么"。

背后的设计动机与 SKILL.md 的 Principle 一脉相承：HTR 之所以优于随机搜索，靠的不是让每个执行器自由发挥，而是让每轮实验都条件化于树中已有的证据。如果任务书信息过载或边界模糊，执行器返回的分数就不再是关于指定节点的证据，树的语义会被破坏。因此，任务书本质上是把"单点执行力"与"全局研究策略"之间的边界画清楚的文件。

任务书模板逐段拆解

原模板是一个可直接复制使用的文本块（见 executor-brief.md），全文以方括号标注待填写内容。逐段拆解如下。

头部五要素：让执行器知道"在哪、为何、如何被评价"

模板开头是一段约束宣言与五个上下文块，它们共同回答执行器开工前必须明确的五个问题：

角色与纪律声明

You are an Arbor executor. Test ONE hypothesis in an isolated git worktree and return structured evidence. Do not change the hypothesis — your job is to give the coordinator clean evidence about THIS claim, even if it turns out false.

这段声明是任务书的"宪法"：执行器是证据采集器而非研究者，即使验证结果是假设为假，也同样是合格产出。

HYPOTHESIS (h_n)：填写可证伪的主张，例如模板中的样例——"Aggregating K=5 independent rollouts by an evidence dossier recovers correct answers that majority vote discards."（用证据档案聚合 K=5 次独立 rollout，能找回多数投票丢弃的正确答案。）它必须是一个"改变产物会如何移动指标"的具体声明，而不是含糊的意愿。结合 htr-methodology.md 的节点粒度约定：靠近根节点的假设是宽泛方向（如"验证是瓶颈而非检索"），深层节点是可执行的干预（如"用 K=5 独立 rollout 并按证据档案聚合而非多数投票"）。

CURRENT BEST ARTIFACT (M_best)：填写当前最优产物的路径或 git 引用，例如分支arbor/best。它告诉执行器从哪个基线出发。这是 HTR 保证"所有候选都站在最优血统之上"的关键——合并时产物差距最小，也避免并行实验互相踩踏。

RELEVANT INSIGHTS FROM THE TREE：填写祖先与兄弟节点已产出的洞察，并注明"把这些当作既定事实，在其上构建，不要重新争论"（assume these; build on them, don't re-litigate）。例如模板样例中的"Verification is not the bottleneck; candidate coverage is."（验证不是瓶颈，候选覆盖率才是。）与"Search-augmented judging overfits dev questions."（搜索增强的评判在开发题上过拟合。）这一块正是"条件化搜索"的载体——它把树中积累的语义记忆注入每次实验，避免执行器从零开始、重复前人踩过的坑。

OBJECTIVE & METRIC：填写目标 O 及其方向，例如"Maximize BrowseComp answer accuracy."（最大化 BrowseComp 答案准确率）。注意此处只给方向与语义目标，不给执行器留出"改换指标"的余地。

DEVELOPMENT EVALUATOR (E_dev)：填写确切的评分命令，例如python eval.py --split dev --n 50。E_dev是搜索期间可自由反复运行的开发评估器，要求快、可重复；而独立的E_test只在合并门禁处由协调者运行（见下）。dev/test 分离正是捕捉过拟合的机制，这一点在 SKILL.md 的 AO 设置中被强调为"比之后任何决策都重要"。

WHAT TO DO：四步操作规程

模板给执行器的操作步骤浓缩为四步，每一步都服务于"干净证据"这一目标：

从 M_best 创建/确认隔离 worktree——确保不触碰其他实验与当前最优产物；
实现使假设成立的最小改动（MINIMAL change）——可以自由编辑、调试、重跑，但改动必须绑定在本假设上；若指标停滞，修自己的代码，不要转向另一个想法。这是"假设绑定"原则在操作层面的落实；
运行 E_dev 并记录分数——如果评估有噪声，多跑几次取稳；
在命名清晰的分支上提交产物——保证branch_ref是一个他人可检出、可复现的实体。

RETURN EXACTLY THIS：四项返回契约

模板最强调的部分是返回格式——执行器的最终消息本身就是协调者读取的数据。格式如下：

dev_score：E_dev给出的数字；
result：1～3 句事实性结论，描述改动实际做了什么；
insight：可复用的教训——说明结果为何支持 / 削弱 / 约束该假设。这是最有价值的输出，应写成未来实验可以使用的约束，而不是对分数的复述；
branch_ref：持有产物的 git 分支 / commit / worktree 路径。

这条契约之所以如此死板，是因为协调者必须把四者精确映射到树节点的metadata（dev_score、result、branch_ref）与节点insight字段上（见 tree.py 的节点结构）。格式不稳定，写回与后续的洞察抽象就无法自动化。

红线声明：不碰 E_test

模板末尾明确要求执行器不得运行留出测试评估器（held-out test evaluator）——那是协调者合并门禁的权力。这条红线与执行器"假设不可改"共同构成了 dev/test 分离机制不被破坏的两道防线：执行器只接触E_dev，从根上杜绝测试集信息渗入搜索过程。

调度方式：worktree 隔离与并行派发

原文档在模板之外给出了两条调度约定，它们是模板得以安全运行的工程前提：

隔离是硬性要求。使用 Agent 工具派发时，应携带isolation: "worktree"，让执行器获得仓库的独立副本；或者直接指示执行器自行运行git worktree add。隔离的意义在于：并行实验之间不能互相覆盖文件，探索性改动必须留在隔离区，直到通过合并门禁才能影响当前最优。

独立的兄弟假设并行派发。在同一消息中发起多个 Agent 调用，同时测试互不依赖的兄弟假设。正如 SKILL.md 所述，同一方向内的对比证据正是后续剪枝与抽象的依据——若串行执行，兄弟节点间的差异会被时间因素污染，难以归因。

派发前，协调者还应通过 cmd_set_status 命令将节点标记为running（例如python scripts/tree.py set-status --node n5 --status running），使 Observe 投影保持准确。从源码看，节点的合法状态集合为{pending, running, executed, merged, pruned, root}，set-status在写入node["status"]的同时会刷新updated_at时间戳。

证据写回：set-evidence 与 propagate 的源码级解读

执行器返回后，协调者要做两件书面上传工作，原文档给出了完整命令：

python scripts/tree.py set-evidence --node <id> \ --dev-score <n> --result "..." --insight "..." --branch-ref "<ref>"

从 cmd_set_evidence 的实现看，该命令的执行细节为：

--dev-score、--result、--branch-ref分别写入节点的metadata["dev_score"]、metadata["result"]、metadata["branch_ref"]；
--insight写入节点级字段node["insight"]（注意它与 metadata 平级，属于研究单元中的iota_n）；
节点状态默认置为executed（除非用--status覆盖）；
每次写入都会打上updated_at时间戳；
命令完成后，若节点存在祖先，会打印一行提醒：请将这一叶级洞察抽象到祖先节点，即执行tree.py propagate --node <id> --insight "..."，若结论具有普适性还应更新根节点n0的全局洞察。

第二步"向上抽象"由tree.py propagate完成：

python scripts/tree.py propagate --node n5 \ --insight "Candidate coverage, not verification, limits this direction" --to-root

cmd_propagate 的实现说明其语义：它先沿parent链收集节点到根的祖先列表，默认只更新直接父节点；加上--to-root后则更新整条祖先链直至根n0，每个祖先的insight字段都会被追加以[from n5]为前缀的新行。这意味着一条叶级观察（例如"数据接口不匹配"）可以先成为方向级约束，再在足够普适时沉淀为影响后续所有构思的全局先验。

值得强调的是：抽象与复述不是一回事。SKILL.md 明确指出，洞察传播是 HTR 收益的最大来源——论文在 MLE-Bench Lite 上的消融实验显示，去掉洞察反馈后（即便保留树结构），成绩反而低于没有树的扁平实验队列（54.5% vs 63.6% any-medal，完整系统为 81.8%）。仅靠层级结构远远不够，语义记忆才是关键。因此，协调者在propagate时提交的文本应是经过思考的抽象，而非把叶级 insight 原样复制上去。

合并门禁：为什么 E_test 只属于协调者

执行器不碰E_test，并不意味着测试评估永远不会发生——它发生在协调者一侧的合并门禁中。原文档给出的合并命令为：

python scripts/tree.py merge --node n5 --test-score 67.67 --branch-ref "wt/n5"

对照 cmd_merge 的实现可以还原其判定逻辑：协调者先在全新的 worktree（而非开发 worktree，避免泄漏）中运行E_test得到test_score，然后根据run.json中的metric_direction（max 或 min）比较该分数与当前best_test_score；只有确实更优时，节点才被标记为merged，并更新运行记录中的best_node、best_test_score与best_branch_ref。若门禁拒绝，M_best保持不变——而这次拒绝本身就是信息：高 dev / 低 test 的候选，说明该方向可能在利用 dev 信号而非产生可迁移的改进，应把这一教训记入树中。

任务书与合并门禁共同完成了一个闭环：执行器在 dev 上自由探索（Dev guides），协调者只在 test 上放行（Test admits）。这正是 HTR 将"探索性改进"与"经验证的产物级进步"区分开来的机制。

完整示例：从任务书到证据写回

结合模板样例与 SKILL.md 的示例运行（BrowseComp 搜索框架），一份填写完毕的任务书可以组织如下：

You are an Arbor executor. Test ONE hypothesis in an isolated git worktree and return structured evidence. Do not change the hypothesis — your job is to give the coordinator clean evidence about THIS claim, even if it turns out false. HYPOTHESIS (h_n): "Aggregating K=5 independent rollouts by an evidence dossier recovers correct answers that majority vote discards." CURRENT BEST ARTIFACT (M_best): branch `arbor/best` — start from this RELEVANT INSIGHTS FROM THE TREE (assume these; build on them, don't re-litigate): "Verification is not the bottleneck; candidate coverage is. Search-augmented judging overfits dev questions." OBJECTIVE & METRIC: Maximize BrowseComp answer accuracy. DEVELOPMENT EVALUATOR (E_dev) — run this to score your candidate: python eval.py --split dev --n 50 WHAT TO DO: 1. Create/confirm an isolated worktree from M_best. 2. Implement the MINIMAL change that realizes the hypothesis. 3. Run E_dev and record the score. Run it more than once if it's noisy. 4. Commit the artifact on a clearly named branch. RETURN EXACTLY THIS (your final message IS the data the coordinator reads): - dev_score: <number from E_dev> - result: <1-3 sentences of factual outcome> - insight: <the reusable lesson: WHY this result supports / weakens / bounds the hypothesis> - branch_ref: <git branch/commit/worktree path holding the artifact> Do NOT run the held-out test evaluator — that is the coordinator's merge gate.

执行器返回后，协调者依次完成写回与抽象（命令与占位值取自 SKILL.md 的 Backpropagate 示例）：

python scripts/tree.py set-evidence --node n5 --dev-score 70.0 \ --result "K=5 dossier aggregation recovers answers in minority rollouts" \ --insight "Correct answers often appear in a minority of rollouts; aggregation beats majority vote" \ --branch-ref "wt/n5" python scripts/tree.py propagate --node n5 \ --insight "Candidate coverage, not verification, limits this direction" --to-root

若后续该候选要通过合并门禁，则由协调者（而非执行器）在全新 worktree 中运行测试评估，再调用tree.py merge决定是否更新M_best。

常见误用与避坑要点

把原文档与源码中的约束汇总，实践中最容易出错、也最值得写进任务书的注意事项包括：

假设中途漂移：指标停滞时擅自改假设追分数，会让返回的分数不再是关于指定节点的证据。执行器唯一正确的做法是修自己的实现并重跑；
在 dev worktree 里跑测试：即使评估者变成了协调者，测试评估也必须在全新 worktree 中进行，防止开发痕迹泄漏到门禁判定；
返回格式松散：协调者"读"的是最终消息本身，缺字段或把 insight 写成对 result 的复述，都会让 Backpropagate 步骤失去养分；
把失败当噪音丢弃：被证伪的假设应连同原因一起记录（tree.py 的 prune 命令支持--reason），"带理由的剪枝"远比"剪掉并遗忘"有价值——它成为未来构思的负向约束。

企业官网建设流程全解析