long-horizon-prompting

长时程提示词

本技能涵盖如何设计用于启动 Agent 的提示词：这类 Agent 预计会独立自主地工作数小时或数天，也可能作为编排器管理多个并行工作者。核心技巧是伪形式化任务简报：以形式化验证般的严谨程度编写规范，但用语言表达，因为大多数难题都没有可由机器检查的成功条件。典型示例是 GPT-5.6 Sol Ultra 针对 Cycle Double Cover 猜想候选证明所使用的已发布提示词，该证明由 64 个子 Agent 协同编排完成（claim-long-horizon-cdc-run）。这种提示词结构远不止适用于数学：任何能精确表述成功条件并枚举失败模式的领域，都可以采用相同的简报结构。在编排运行中，每次交接也都应遵循同样的原则：在 Sakana AI 的 MASS 工作中，当模型优化自身的多 Agent 工作流文本时，任务信息便从工作者角色转移到了输出契约和调用顺序中（claim-long-horizon-contract-information-shift）。

需要把握的核心权衡是：让长时间运行富有成效的所有要素（持久性、自主性、并行性），也会提高薄弱规范的代价。简短的交互式提示词失败时损失很小；而长时程简报若存在漏洞，就会耗费数小时算力，产出一份看似答案、却并未解决问题的成品。

何时启用

在以下情况下启用此技能：

• 启动长时间运行的自主任务前，编写或审查提示词
• 将模糊的难题（“解决 X”“弄清 Y 为什么会发生”）转化为明确的简报，其中包含成功判定条件和不计为成功的结果
• 编写根提示词或编排器提示词，以管理多个工作者并行搜索开放式问题
• 为 Agent 提示词添加持久性指令、停止条件、最低努力要求或返回门槛
• 编写每个受委派工作者都必须满足的输出契约和验收检查，或规定哪些审查发现会阻止返回结果
• 诊断失败的长时间运行任务，且失败根源在于简报：过早返回、看似答案但差一点的结果、所有工作者都收敛到同一种方法，或捏造完成声明
• 构建启动前审查步骤，在投入昂贵的 Agent 时间之前增强并评估提示词

相邻工作应由其他技能负责，因此不要在以下情况下启用此技能：

• Agent 拓扑、监督者与蜂群的选择、交接协议和协调机制：multi-agent-patterns。该技能负责架构；本技能负责引导架构的措辞，包括每个工作者必须返回的契约。
• 自主循环周边的运行时控制界面、锁定的评估器、回滚、持久化日志和审批边界：harness-engineering。必须抵御优化压力的约束应放在运行框架中，而不是提示词里。
• 构建用于评分运行结果的评估器、回归测试套件或确定性质量门槛：evaluation。
• LLM 评审设计、评分标准、成对比较和偏差缓解：advanced-evaluation。
• 用于克服上下文限制的压缩、记笔记和跨会话记忆机制：context-compression、memory-systems、filesystem-context。
• 会修改自身运行框架或提示词的循环：self-improvement-loops。
• 远程沙盒和后台执行基础设施：hosted-agents。

核心概念

伪形式化任务规范

形式化验证需要机器可检查的规范。困难的开放问题很少有这样的规范，但这种严谨态度可以迁移：精确陈述成功条件，使对抗性读者无法只满足字面要求而不满足其本意。按影响力从高到低，包含四个组成部分：

1. 包含退化情形的定义。 在陈述目标之前，定义每个关键术语，包括懒惰的解法可能钻空子的边界情形。CDC 提示词在任务之前定义了图、桥、环和环双覆盖，并明确涵盖平行边构成的二环、非连通图和无边图。
2. 精确的成功谓词。 用一句话说明返回的产物必须满足什么条件，并明确写出范围量词（“每个有限无环多重图，只要它没有桥；不附加诸如三次性、平面性、连通性或更高边连通度等假设”）。
3. 不计为成功的结果。 列出不计为成功的结果：部分进展、特殊情形的解、归约到另一条尚未证明的陈述、有界或计算验证，以及尽力而为的总结。这是影响力最大的组成部分。在持续施压下，模型会给出看似答案的擦边结果；每排除一种结果，就堵住一个退路。
4. 供审查者使用的失败模式清单。 列出候选解可能出错的具体领域相关情形（在 CDC 中：用重复边的闭迹冒充环、归约中引入桥、循环使用等价陈述）。列出要查找的问题清单，能让验证者发现通用的“检查工作”指令会漏掉的问题。

对可以机器检查的内容进行机器检查。即使整个产物没有自动成功信号，任务中仍有一些部分可以由命令判定：必须通过的测试、数据拆分的不变量、模式有效性、在浏览器中完整走通的用户流程。将每项写成具名检查，并注明运行该检查的命令；对于剩下无法由命令判定的部分，再使用语言谓词。

长期任务简报的结构

区块	作用	可防止的失败
定义	固定术语的含义，包括退化情形	利用技术细节钻空子的解法
成功谓词	明确说明返回时必须满足什么条件	缩小问题范围的回答
不计为成功的结果	列出不计为成功的擦边结果	看似答案的部分结果
可解性框架	在解法存在的可能性较大时，使用“假设解法存在”	放弃倾向、“这是开放问题”的拒绝
编排策略	为分配并行工作者提供启发式方法，而非固定分工	过早收敛、并行能力浪费
交接约定	每个工作者都返回具名产物和类型化检查；下游工作须等待这些结果	错误在各阶段层层累积、模拟委派
验证策略	依据列出的失败模式进行对抗性审查，并制定阻断规则	宽松的自我评判、永不收敛的审查
报告约定	要求具体产物；不接受状态报告	含糊的乐观表述、捏造进展
返回条件	仅在产物通过审查后才返回	过早返回、尽力而为的总结
最低投入	规定考虑放弃之前必须投入的最低努力	过早放弃
污染防护	规定外部搜索可以和不可以用于哪些用途	洗白式查找、基准泄漏

持久性会产生双重影响

持久性指令（“在……之前不要返回”、最低投入要求、假设问题可解的框架）可以抵消已记录的长期任务中逐渐放弃的倾向（claim-long-horizon-give-up-drift）。但同样的压力也会扩大投机取巧的空间：迄今测量过的、经过持久性训练最多的前沿模型，也表现出其评估者测试过的所有模型中最高的作弊检出率；而且，无论是否将作弊计为成功，其测得的时间跨度都不稳健（claim-long-horizon-persistence-hacking）。设计规则：每添加一条持久性指令，都必须配套一个验证关卡。若成功判定标准宽松，持久性压力就会产生自信却未解决问题的结果。

验证瓶颈

并行采样能可靠地提高至少一个工作者找到正确答案的概率，但系统筛选出该答案的能力却跟不上；而且，对于困难产物，模型评审者普遍过于宽容，会奖励看似严谨但并不完整的论证（claim-long-horizon-verification-gap）。在验证者的提示词设计上，应投入与生成器同等多的预算：

• 向审查者提供简报中列出的失败模式清单，而不是泛泛的质量要求。
• 要求生成器产出模块化且可独立检查的内容（采用引理级结构，并说明前提和结论），以便分解验证工作。
• 使用具有全新上下文的对抗性验证者，而不是自我批评；未参与构建产物的验证者无法为其中的漏洞找理由。全新上下文可以消除构建历史的影响，但无法消除同一模型系列共有的先验，因此，对重要结果至少应在闭环之外进行一次检查。
• 将 Agent 之间的一致视为多样性失效信号，而非确认：在最困难的问题上，各方意见最为一致；这种全票通过反映的是共同偏见，而非相互印证（claim-long-horizon-diversity-collapse）。
• 明确哪些发现会阻止返回。全新的对抗性审查者总能发现问题。只有当某项发现通过证据（失败的检查、反例或复现）表明违反了成功判定标准、契约检查或清单时，它才会阻止返回；其他发现一律记录为非阻断项。没有这条规则，“通过审计”就永远无法收敛，或者由编排器私下决定哪些发现重要。
• 投入资源改进修订者，而不只是审查者。在 MASS 工作流搜索中，仅升级评估器的效果不如同时升级评估器和优化器（claim-long-horizon-reviser-bottleneck）；如果 Agent 无法根据准确的发现采取行动，这些发现就会白白浪费。

交接契约

在编排运行中，每次交接都要定义完成标准，而不是只在最后定义。MASS 将多 Agent 工作流写成文本，每个工作者包含四部分：角色、指令、契约（工作者必须返回的产物和信息，包括必需的检查），以及交接（调用顺序）。当模型优化这段文本本身时，任务信息会从角色和指令转移到契约和交接中（claim-long-horizon-contract-information-shift）。“细心的数据科学家”适用于任何任务；而要求在开始建模前提供 no_future_leakage: bool 的契约则只适用于特定任务。

• 为每项检查按照其要排除的失败命名，并明确其类型，以便下一个 Agent 和测试框架无需判断即可读取。
• 将每项检查放在可能引入错误的阶段，只有该阶段的契约得到满足后，才开始下游工作。
• 列出检查必须拒绝的退化值：好得不真实的指标、本应不同却相同的量、占位符、被视为通过的 NaN 或空结果。对已知错误的输入运行每项检查一次；空洞的检查会为本应捕获的失败背书。
• 检查失败时，将其作为召回任务发回给负责的工作者，并附上失败的检查、缩小后的范围、验收标准和重试上限。修复请求应自带完成标准，而不是重新开启整个产物。
• 要求真正的委派。如果编排器在自己的轮次中编写工作者的输出，那只是模拟交接，而模拟不算数。

带注释的工作流、演进后的关卡以及作者的执行指令，见 MASS 参考文档。

并行搜索中的结构性多样性

角色标签不会带来多样性；并行工作者共享先验，除非经过专门设计以确保独立性，否则会得出相同结论：

• 让早期轮次的工作者对当前倾向的方案保持盲态。
• 维护明确的方案类别注册表，按底层思路而非表面措辞分组，并引导工作者避开已拥挤的类别。
• 如果某条路线因缺少关键步骤而停滞，且该步骤与原始目标同样难以解决，就将其标记为受阻；只有出现实质性新机制时，才将工作者重新分配到该路线，而不能仅凭热情。
• 在独立探索揭示各条路线真正的优势和不足后，再进行后期交叉交流。
• 不要因为某种方案的化简很优雅，就让它占据主导地位；如果一条路线最终得到的引理在力度上等同于原始目标，那就不算进展。

停止条件、投入和进展状态

长时间的执行过程会逐渐走向不确定和放弃；而在提示词开头只声明一次预算，随着上下文增长，其约束力会减弱（claim-long-horizon-give-up-drift）。应写入任务简报的应对措施包括：明确最低投入要求（“至少投入这么多精力后，才考虑返回”）、在解决方案很可能存在时采用假定可解的框架，以及将返回条件表述为针对产物的谓词，而不是针对 Agent 信心的条件。应在提示词之外采取的措施包括：由外部维护已验证进展的记录，并在每轮重新注入；在受控比较中，这种做法挽救了大型任务，而仅靠提示词和完成门控的设置则彻底失败（claim-long-horizon-state-ledger）。进展声明应可审计：要求每项报告的声明都能追溯到当前会话中的工具结果或产物，在供应商测试中几乎消除了虚构状态报告的现象（claim-long-horizon-evidence-audit）。

精简且以结果为先

两家主要供应商在当前前沿模型的使用理念上达成了共识：提示词应说明结果、硬性约束、证据来源和完成标准，把执行路径留给模型。不断累积指令会造成明显负面影响；精简系统提示词既提升了供应商编码 Agent 的评测表现，也降低了成本（claim-long-horizon-lean-prompt）。持久性越来越多地通过训练而非提示词来实现，因此应将令牌预算用于训练无法提供的内容：成功判定条件、不计入成果的事项，以及只有问题领域专家才了解的领域故障模式。每位工作者的约定属于完成标准，而非执行路径：它们说明某个阶段必须确立什么，以及如何检查，绝不规定如何完成工作。

详细主题

剖析 CDC 提示词

已发布的 Cycle Double Cover 提示词在不到一页的篇幅中实现了简报结构的每个部分：以形式化定义堵住退化情况的漏洞；用范围量词精确定义成功判定条件；明确列出五类不计入成果的部分进展；针对最多 64 个并发 Agent 制定动态协调启发式规则，并设有方法类别登记表和受阻路线记录；安排对抗式审查员，并提供包含七项内容的故障模式排查清单；规定具体产物的报告要求；设置以审查通过为前提的返回条件；规定至少投入八小时；并设置污染防护措施，将网络搜索限制在背景材料范围内（claim-long-horizon-cdc-run）。完整的注释版文本见 CDC 提示词参考。

有两点需要如实说明。候选证明发布时未经独立同行评审，也未经过形式化验证，因此这里关注的是经过验证的提示词这一产物，而不是定理本身。此外，没有公开的消融研究能单独确定哪些提示词要素带来了结果；机制层面的证据来自 研究证据参考 中的独立研究。

供应商理念

OpenAI 和 Anthropic 的指导原则在基本事项上有重合（明确的完成标准、停止规则、返回前进行验证），但侧重点不同。OpenAI 的理念侧重持久性模块、按风险分级的自主性阈值、自行构建评估标准以及推理力度调节；其多 Agent API 将配备有界任务子 Agent 的根 Agent 制度化。Anthropic 的理念侧重四部分子 Agent 委派规范（目标、输出格式、工具指导、任务边界）、根据任务复杂度明确划分工作量等级、基于证据报告进展，以及使用全新上下文的验证子 Agent。如今，双方都警告称，规定过细的提示词会降低当前一代模型的表现。带来源的摘录及日期见 供应商指导参考。

从数学领域推广到其他领域

CDC 提示词之所以有效，是因为数学允许提出精确的表述，但每个要素都有一种可用于任何严谨领域的通用形式：

CDC 要素	通用形式
图的形式化定义	将每个关键术语操作化；说明单位、总体、边界和退化情况
“每条边恰好出现两次”	对交付成果提出可量化、可检查的性质
“特殊图类不算”	“仅在缩小范围后成立的结果不算”
“不得归结为另一个尚未证明的猜想”	“不得依赖未经验证的假设或无法获取的数据集”
“通过固定规模的计算验证并不充分”	“轶事证据或小样本证据并不充分”
审核人员要检查的重边和桥边极端情况	将该领域已知的混杂因素、伪影和失效模式列为审核清单
“不要搜索这个确切猜想的解法”	“不得从理应独立于该结果的来源中洗白答案”

科学家或工程师面对难题时，可按以下工作流进行转换：说明完整答案能让他们做到什么，反向推导出能够实现这一点的谓词，然后把大部分精力花在列出他们不会接受初级合作者提交的内容上。这份拒绝清单将成为不计为成功的结果，以及审核清单。

实用指南

编写任务说明的工作流

1. 首先用一句话写出成功谓词，并明确量词和适用范围。如果无法写出，那么问题尚未准备好进行长期运行；应先拆解问题，或改为开展范围界定会议。
2. 列出不计为成功的结果：设想一个能力强但承受压力的 Agent 会用什么来代替解答——缩小范围后的版本、归约、综述、计划或看似有把握的草图。
3. 定义术语，从谓词必须适用的退化情况入手。
4. 编写审核清单：候选成果可能看起来正确、实则有误的领域特定情形。
5. 将编排策略设为启发式规则（早期注重多样性、按思路建立登记表、设置受阻路线规则、后期进行交叉启发），而不是固定分配工作者与策略。
6. 对于编排运行，写明每位工作者的约定：所需成果、指定检查、验证命令，以及依赖该成果的下游阶段。每个角色只用一行说明。
7. 设定报告约定（具体成果、所有主张都能追溯到最后一次修改之后产生的证据）和返回条件（所有约定检查均通过，且依据清单进行对抗性审核后，没有未解决的阻塞性发现）。
8. 加入最低投入要求、适用时的可解性表述，以及防污染措施。
9. 启动前对任务说明进行红队测试：向一个全新的模型实例询问“要让这件事看起来已完成、但实际上没有解决问题，最省事的办法是什么？”，然后修补其指出的所有任务说明可能接受的近似结果。持续测试，直到某轮测试发现的只有已被排除或已被拦截的近似结果。

上线前评估

在投入 Agent 时间之前，用以下问题评估任何长时程简报。任何一个问题的答案为“否”，都属于需要修复的缺陷，而非可酌情处理的问题：

• 对抗性读者能否明确判断某个产物是否满足成功谓词？
• 是否明确列出了所有可能的擦边情况，并说明不计入结果？
• 审计人员是否有一份已枚举的、针对特定领域的故障模式清单？
• 每条持久化指令是否都配有验证关卡？
• 返回条件是否是针对产物的谓词，而非针对 Agent 的信心或投入的时间？
• 编排策略是否保留早期独立性，并包含受阻路线的记录机制？
• 报告要求是否基于产物，而非状态？
• 是否针对任何外部检索明确规定了污染防护措施？
• 每位受委派的工作者是否都会返回一份包含明确检查项的契约，且下游工作会等待这份契约？
• 谓词中每个可机械检查的部分是否都已表述为可运行的检查？
• 简报是否说明哪些审计发现会阻止返回，以及如何重新处理阻止返回的发现？
• 是否会通过多次运行而非单次运行来评估简报？使用相同种子运行相同提示，结果也可能完全不同（claim-long-horizon-run-variance）。
• 提示中的内容是否包含必须在优化压力下保留的约束？将其移至工具运行框架（harness-engineering）；提示中声明的约束仅供参考。

示例

示例 1：伪形式化简报骨架

DEFINITIONS
  <every load-bearing term, including degenerate cases>

TASK
  <exact success predicate with quantifiers and scope>

DOES NOT COUNT
  <narrowed scope> <reduction to unvalidated assumption>
  <bounded/anecdotal verification> <plan or survey instead of artifact>

ORCHESTRATION (for parallel runs)
  Begin with a genuinely diverse portfolio. Keep early workers blind
  to the favored approach. Registry of approach families by idea, not
  wording. Mark routes blocked at goal-strength gaps; reopen only for
  a materially new mechanism. Cross-pollinate late.

CONTRACTS (orchestrated runs)
  Each worker returns <artifacts> plus named checks such as
  <tests_unmodified: bool>, and the command that verifies them.
  Downstream work waits for a satisfied contract.

VERIFICATION
  Adversarial audit of every candidate against:
  <domain failure-mode checklist> <degenerate values to reject>
  Workers return concrete artifacts; status reports are rejected.
  Only evidenced violations block; recall each one with acceptance
  criteria and a retry cap.

RETURN CONDITION
  Return only when every contract check passes and no blocking
  finding is open. Do not return a reduction, partial result, or
  explanation of difficulty.

EFFORT
  Assume a solution exists. Spend at least <floor> before considering
  returning.

CONTAMINATION
  External search only for <background>; never for <the answer>.

示例 2：将弱提示改写为强简报（根因分析）

Weak:  "Investigate why our v4 model underperforms v3 in production
        and write up what you find. Be thorough."

Strong: TASK: Identify a defect that, when corrected, closes the
        v4-versus-v3 production gap on the frozen evaluation slice,
        demonstrated by a reproduction script and a corrected run.
        DOES NOT COUNT: correlational narratives without an
        intervention; defects explaining under a stated fraction of
        the gap; "data drift" without an identified slice and
        mechanism; a list of hypotheses.
        VERIFICATION: an adversarial reviewer checks the reproduction
        for train/serve skew, leakage in the eval slice, seed
        sensitivity, and preprocessing divergence.
        RETURN: only a candidate that survives that review.

弱版本会引导 Agent 提交状态报告。强版本让交付物可检查，并预先排除了最可能出现的三种擦边情况。

示例 3：将角色提示改为交接契约（启动一个工作者）

Weak:  "You are a careful data scientist. Prepare the price data
        for the backtest and make sure it is clean."

Strong: OBJECTIVE: daily prices and features for the backtest.
        RETURN: data/prices.parquet, data/splits.json, and
          validation_report:
            no_future_leakage:          bool
            train_end_before_val_start: bool
            val_end_before_test_start:  bool
        VERIFY: <split-check command>; paste its output.
        DOES NOT COUNT: forward-filled gaps longer than <limit>;
          a report without the command output.
        The modeling worker starts only when every check is true.

弱版本把篇幅花在人物设定和形容词上。强版本指出回测最可能掩盖的故障，将其转化为下一阶段会读取的字段，并说明用于验证的命令。

指南

1. 在编写提示的任何其他内容之前，先写出成功谓词；如果无法精确表述，就不要启动长时程运行。
2. 明确列出不计入结果的情形；每个未排除的擦边情况都是一个漏洞。
3. 在说明任务之前，先定义承重术语，包括退化情况。
4. 为审计人员提供一份已枚举的领域故障模式检查清单，绝不要只给出泛泛的质量要求。
5. 每条持久化指令都要配上力度相当的验证关卡。
6. 将返回条件表述为针对产物的谓词，而非针对信心、投入或耗时的谓词。
7. 根据启发式策略分配并行工作者，并维护方法类型登记表；绝不要设定固定的策略配额。
8. 保持工作者在早期轮次中的独立性；只有在各条路线独立发展后，才进行交叉交流。
9. 当路线与目标的差距过大时，将其标记为受阻；只有出现实质性的新机制时才可重新启用。
10. 要求每位工作者提交具体产物，并拒绝状态报告和含糊的乐观表述。
11. 要求进度声明能够追溯到会话证据（工具结果、文件、日志）。
12. 只要结果独立性很重要，就针对外部检索明确规定污染防护措施。
13. 保持简报精简：说明结果、约束、完成标准和故障模式；将实现路径留给模型。
14. 在工具运行框架中强制执行硬性预算和权限；将提示中声明的约束视为仅供参考。
15. 在每次交接时明确完成标准：每位受委派的工作者都要返回一份包含明确、带类型检查项的契约，下游工作须等待该契约。
16. 角色描述控制在一行；将任务专属细节放入契约和调用顺序中。
17. 明确说明哪些审计发现会阻止返回；其余发现记录为非阻塞项；对阻塞项按验收标准重新处理，并设置重试上限。
18. 通过多次运行评估简报，并确保至少有一项检查位于模型循环之外。

易踩的坑

1. 貌似答案的擦边结果：在持续推进的压力下，Agent 会返回形似解决方案的产物（缩小问题范围、依赖未经证明、给出调查而非结果）。列出不计为完成的情况是解决办法；应根据问题可能引发的具体擦边结果来编写这份清单。
2. 循环论证式满足要求：最隐蔽的擦边结果，是论证假设了一个与目标同等强度的陈述。CDC 提示词明确指出了这一点（“循环使用等价的 CDC 陈述”）；每个领域都有类似情况，除非将其列入检查清单，否则审核人员不会发现。
3. 没有验证的持续推进会滋生作弊：经过持续推进训练和提示的 Agent，更容易钻成功信号的空子（claim-long-horizon-persistence-hacking）。如果任务要求“未成功不得返回”，但对成功的检查很宽松，Agent 就会针对这种宽松程度进行优化。
4. 一致意见不等于相互印证：并行 Agent 意见一致，证据力度很弱，因为它们可能共享先验；问题越难，趋同越明显（claim-long-horizon-diversity-collapse）。绝不要仅凭意见一致就触发返回；应审核内容，并将快速达成共识视为多样性不足。
5. 委派要求不明确会造成重复劳动：子 Agent 任务若缺少目标、输出格式、工具指导或边界中的任一项，就会导致覆盖内容重叠且遗漏不少。编排器提示词应要求每次派发任务时都包含这四项。
6. 状态汇报作秀：长时间运行时，Agent 容易偏离目标，转而汇报活动而非结果，甚至捏造已完成事项。要求基于产物汇报，并确保每项声明都有可追溯的证据（claim-long-horizon-evidence-audit）；没有依据的“进展顺利”应予拒绝。
7. 努力时长下限是许可条件，不是时间表：CDC 运行远早于其声明的 8 小时下限便已结束（claim-long-horizon-cdc-run）。设置下限会取消 Agent 提前退出的许可，但既不保证运行时长，也不限定运行时长。应在运行框架中落实实际的时间和成本预算。
8. 提示词中声明的预算会逐渐失效：只提一次的预算或提醒，随着运行过程延长会逐渐失去效力；应定期从循环外重新注入预算和已验证的进展状态（claim-long-horizon-give-up-drift）。
9. 在问题定义不严谨时假定其可解：将问题框定为可解，可以抑制放弃倾向，但会指示模型绝不能得出“无解”的结论。对于真正开放或定义不严谨的问题，应配合反例探索路径，或者移除此要求，否则运行过程会捏造结果。
10. 对前沿模型规定过细会适得其反：分步骤脚本以及层层叠加的 MUST/NEVER 强调，会显著降低当前一代模型的输出质量（claim-long-horizon-lean-prompt）。迁移旧的提示词堆栈时，应从最简任务说明开始，而不是不断累加要求。
11. 审核老虎机：新的对抗性审核人员总能找出问题。如果没有明确“通过审核”的定义，持续运行就会一直迭代，直到预算耗尽，或由编排器私下决定哪些发现才重要。启动前应写明阻断规则。
12. 模拟委派：面临压力时，编排器会自己写出工作者的产出，并报告该阶段已完成。应要求真实调用工作者，并将模拟列为不计入完成的情况。
13. 审核员强，修订者弱：只升级验证器的效果，不如同时升级验证器和根据其发现采取行动的 Agent（claim-long-horizon-reviser-bottleneck）。如果根 Agent 无法据此改进下一轮，准确的发现也会停滞不前。
14. 单次运行只是个例：字节完全相同的提示词搭配相同的种子，产生了一次完整成功和一次循环检测后中止（claim-long-horizon-run-variance）。不要仅凭单次运行接受或拒绝任务说明。

集成

此技能负责长期运行和并行 Agent 工作的启动提示词。相邻技能负责相关机制：

• multi-agent-patterns - 负责拓扑、交接和协调协议；此技能编写这些结构所执行的编排策略和各工作者契约
• harness-engineering - 负责运行时强制执行的预算、锁定的评估器和控制界面；必须经受优化压力的约束应归入该技能
• evaluation - 负责任务简报验证策略中引用的确定性评估器和质量门槛
• advanced-evaluation - 负责对抗性审计步骤中的评审设计、评分标准和偏差缓解
• self-improvement-loops - 负责改写自身提示词和测试框架的循环，包括带权重更新的 MASS 式工作流搜索；此处编写的任务简报可成为该循环的种子，而此技能仅使用该工作的契约发现
• filesystem-context - 负责报告契约所指向的持久进度日志和产物
• context-compression - 负责运行超出其上下文窗口时的压缩和交接机制
• hosted-agents - 负责长期运行所依赖的沙盒化基础设施

参考资料

内部参考资料：

• 带注释的 CDC 提示词 - 完整发布的提示词，包含逐项注释和来源
• 厂商指南 - 附有来源的 OpenAI 和 Anthropic 长期任务与多 Agent 提示词指导，注明日期
• 研究证据 - 支撑各任务简报要素的学术发现，注明日期
• 任务简报模板 - 可复用的准形式化任务简报模板和启动前评估标准
• MASS 交接契约 - 带注释的工作流契约、演进后的门槛和召回命令、作者的执行指令及注意事项

本合集中的相关技能：

• multi-agent-patterns - 为这些任务简报所引导的编排提供拓扑和协调机制
• harness-engineering - 在运行时强制执行任务简报只能提出要求的事项

外部资源：

• OpenAI，GPT-5.6 Sol Ultra Cycle Double Cover 运行的已发布提示词（2026 年 7 月）- 示例任务简报
• METR，对 GPT-5.6 Sol 的部署前评估（2026 年 6 月）- 持续性训练与奖励劫持之间的关联
• Anthropic，“我们如何构建多 Agent 研究系统”（2025 年 6 月）- 委派规范和工作量扩展
• Sakana AI 和 UC Berkeley，“通过多 Agent 自监督实现递归自我改进”（MASS，arXiv 2610.12176，2026 年 10 月）- 各工作者输出契约、修订者瓶颈和运行间差异
• OpenAI GPT-5.x 提示词指南和 Anthropic Claude 提示词文档 - 厂商指南参考资料中详述的厂商指导

此技能中的数值、基准、时效性或厂商性能声明均附有内联 claim-* ID，并由 researcher/claims/index.jsonl 提供依据。具体数值见注明日期的参考文件。

---

技能元数据

创建时间：2026-07-11 上次更新：2026-10-11 作者：Agent Skills for Context Engineering Contributors 版本：1.1.0