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 RefinementHTR自主优化流程中为每个短生命周期的执行器子代理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 顶部 docstringtree.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 K5 independent rollouts by an evidence dossier recovers correct answers that majority vote discards.用证据档案聚合 K5 次独立 rollout能找回多数投票丢弃的正确答案。它必须是一个改变产物会如何移动指标的具体声明而不是含糊的意愿。结合 htr-methodology.md 的节点粒度约定靠近根节点的假设是宽泛方向如验证是瓶颈而非检索深层节点是可执行的干预如用 K5 独立 rollout 并按证据档案聚合而非多数投票。CURRENT BEST ARTIFACT (M_best)填写当前最优产物的路径或 git 引用例如分支arbor/best。它告诉执行器从哪个基线出发。这是 HTR 保证所有候选都站在最优血统之上的关键——合并时产物差距最小也避免并行实验互相踩踏。RELEVANT INSIGHTS FROM THE TREE填写祖先与兄弟节点已产出的洞察并注明把这些当作既定事实在其上构建不要重新争论assume these; build on them, dont 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_scoreE_dev给出的数字result13 句事实性结论描述改动实际做了什么insight可复用的教训——说明结果为何支持 / 削弱 / 约束该假设。这是最有价值的输出应写成未来实验可以使用的约束而不是对分数的复述branch_ref持有产物的 git 分支 / commit / worktree 路径。这条契约之所以如此死板是因为协调者必须把四者精确映射到树节点的metadatadev_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-rootcmd_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_directionmax 或 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 K5 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, dont 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 its 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 coordinators merge gate.执行器返回后协调者依次完成写回与抽象命令与占位值取自 SKILL.md 的 Backpropagate 示例python scripts/tree.py set-evidence --node n5 --dev-score 70.0 \ --result K5 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带理由的剪枝远比剪掉并遗忘有价值——它成为未来构思的负向约束。延伸阅读本文对应的模板文件与配套资料均位于仓库skills/arbor/目录下可按需深入executor-brief.md——本文讲解的原始任务书模板SKILL.md——Arbor 技能主文档完整描述 AO 任务元组、六步协调者循环与使用原则htr-methodology.md——HTR 方法论与论文实证结论节点结构、六步算法、消融与迁移证据适合理解每个设计决策背后的理由report-template.md——运行结束时的最终报告模板包含如何理解演化的主线与 dev/test 差距的诚实汇报要求tree.py——init、add-node、set-status、set-evidence、propagate、prune、merge、cycle、observe等全部状态管理命令的实现是验证本文所有命令行为的最终依据。【免费下载链接】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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 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 RefinementHTR自主优化流程中为每个短生命周期的执行器子代理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 顶部 docstringtree.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 K5 independent rollouts by an evidence dossier recovers correct answers that majority vote discards.用证据档案聚合 K5 次独立 rollout能找回多数投票丢弃的正确答案。它必须是一个改变产物会如何移动指标的具体声明而不是含糊的意愿。结合 htr-methodology.md 的节点粒度约定靠近根节点的假设是宽泛方向如验证是瓶颈而非检索深层节点是可执行的干预如用 K5 独立 rollout 并按证据档案聚合而非多数投票。CURRENT BEST ARTIFACT (M_best)填写当前最优产物的路径或 git 引用例如分支arbor/best。它告诉执行器从哪个基线出发。这是 HTR 保证所有候选都站在最优血统之上的关键——合并时产物差距最小也避免并行实验互相踩踏。RELEVANT INSIGHTS FROM THE TREE填写祖先与兄弟节点已产出的洞察并注明把这些当作既定事实在其上构建不要重新争论assume these; build on them, dont 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_scoreE_dev给出的数字result13 句事实性结论描述改动实际做了什么insight可复用的教训——说明结果为何支持 / 削弱 / 约束该假设。这是最有价值的输出应写成未来实验可以使用的约束而不是对分数的复述branch_ref持有产物的 git 分支 / commit / worktree 路径。这条契约之所以如此死板是因为协调者必须把四者精确映射到树节点的metadatadev_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-rootcmd_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_directionmax 或 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 K5 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, dont 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 its 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 coordinators merge gate.执行器返回后协调者依次完成写回与抽象命令与占位值取自 SKILL.md 的 Backpropagate 示例python scripts/tree.py set-evidence --node n5 --dev-score 70.0 \ --result K5 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带理由的剪枝远比剪掉并遗忘有价值——它成为未来构思的负向约束。延伸阅读本文对应的模板文件与配套资料均位于仓库skills/arbor/目录下可按需深入executor-brief.md——本文讲解的原始任务书模板SKILL.md——Arbor 技能主文档完整描述 AO 任务元组、六步协调者循环与使用原则htr-methodology.md——HTR 方法论与论文实证结论节点结构、六步算法、消融与迁移证据适合理解每个设计决策背后的理由report-template.md——运行结束时的最终报告模板包含如何理解演化的主线与 dev/test 差距的诚实汇报要求tree.py——init、add-node、set-status、set-evidence、propagate、prune、merge、cycle、observe等全部状态管理命令的实现是验证本文所有命令行为的最终依据。【免费下载链接】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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考