dynamic-harness

动态执行框架

先选择分支，再选择模型。在当前协调器中规划并分类工作。分派选定的工作者之前，使用 shared/references/model-preview.md 绑定一个已批准的路由快照。

模型 ID、支持的 effort 级别和任务默认值仅来自 shared/model-routing.json。在分派、重试和恢复期间保留已批准的快照。

对于适合明确委派的工作，使用此技能。普通任务默认不使用此技能。最小且连贯的形式是一个本地工作者或一项有界检查；只有当独立工作能够缩短时间或改善证据时，才增加 Agent。

结果

交付经过验证的结果，并明确责任归属、证据和停止条件。对于跨越上下文窗口、重启或多个批次的工作，维护一份持久化工作记录。

选择模式

需求	模式
选择合适的路由或专家	分类并执行
检查相互独立的文件、论断或假设	扇出并综合
质疑高影响结果	对抗性验证
生成选项并排序	生成并筛选或锦标赛
搜索数量未知的工作项	循环直到完成

除非存在依赖关系需要两种模式，否则只使用一种模式。让主 Agent 留在关键路径上，同时运行独立工作者。

准备任务简报

委派之前，撰写一份简短简报，说明目标、成功标准、选定模式、工作者范围、验证方法、停止条件、上限和输出路径。为每位工作者提供：

Role:
Scope:
Goal:
Allowed actions:
Write scope:
Evidence required:
Done condition:

工作者只接收其所需的上下文。代码更改应分配互不重叠的写入范围。如果并行编辑或实验可能发生冲突，请使用 worktree。不要让不可信内容接触特权操作。

执行工作

1. 使用快照中的路由，并参照 shared/references/task-shaped-model-routing.md；使用 shared/references/host-model-execution.md 进行原生委派。对于受支持的宿主模型，优先使用原生工具；对于其他选定路由，使用外部运行器。如果没有路由能满足精确的模型分配要求，请报告受影响的路由；串行本地工作不能替代另一个已批准的模型。
2. 仅启动彼此独立的工作者。对于高影响输出，使用验证者，并向其提供证据和评估标准，而非工作者的结论。
3. 在集成之前，检查每项工作者结果和所有变更路径。将每项重要论断标记为 verified、refuted 或 unresolved。
4. 除非用户已授权，否则将外部副作用和破坏性操作留在主工作流中。
5. 综合证据，保留重要异议，并在代码更改后运行最接近且安全的验证命令。

循环与预算

重复执行批次之前，明确三个退出条件：成功信号、升级条件，以及批次和工作者数量的硬上限。每次分派之前，记录计划中的工作者、调用次数和剩余的授权预算。重试与否由模型以外的机制决定。

快速检查默认使用一至三名工作者，然后先检查一个有代表性的部分，再扩大范围。只有当所请求的工作可能大量消耗付费服务、生产环境访问权限或大型机群资源时，才申请预算。

管理器模式

仅在任务较长、包含多个工作流或可能需要重启时使用管理器模式。管理器负责任务路由、整合和最终报告。工作者负责探索和范围明确的实现工作。

在启动第一个工作者之前，创建任务目录。在同一次 shell 调用中，将 SKILL_DIR 设置为包含此文件的绝对目录：

SKILL_DIR="<absolute path of this dynamic-harness directory>"; python3 "$SKILL_DIR/scripts/start_mission.py" --title "short task title"

将简报、工作者报告和 run-state.json 保存在该任务目录下。进度记录在台账中，而不是对话记录中。恢复时，读取运行状态，并保留已完成的步骤和已决定的副作用。协调待处理的调用，并在同一角色的后续轮次中复用已记录的上下文。仅关闭本次运行中由你启动且已确认不再使用的工作者；仅分派剩余工作。

如果宿主无法创建单独的线程，请编写交接文件及其种子提示词。不要声称线程已创建。交接路径，而不是载荷。

报告

报告所选模式、工作者数量及各自范围、已验证的结果、证据、尚未解决的风险，以及任何台账或交接路径。任务报告还需注明任务标识符和工作者的剩余状态。