Deli AutoResearch SKILL 现已正式开源！ https://victorchen96.github.io/auto_research/framework.html…

同时，我们发布了第四篇综述论文——这次是关于自我对弈（Self-play）。 https://victorchen96.github.io/auto_research/paper.html…

受 AlphaZero 启发，我们获得了一个强有力的洞见：先验知识并不总能提升能力的上限。 模型仅仅通过与自己博弈，就可能发现更全局的最优解。

这篇论文最大的变化是什么？ AutoResearch Agent 首次自主规划了 GPU 实验——并在 DeepSeek 285B 模型上提交了真正的强化学习运行任务。

整个强化学习流程——实验设计、代码编写、运行、调试以及结论总结——实现了100%自动化，全程无需我进行任何人为干预。 这虽然极具挑战，但却是至关重要的一步。 https://victorchen96.github.io/blog_self_play_story.html…

这里，GRPO 是 AutoResearch Agent 调用的工具。 我们认为，这是我们持续学习（Continual Learning）研究之旅的开端。

一如既往，这是我的个人研究项目，与任何组织无关。所有观点均为个人见解。

#AI #强化学习 #自我对弈 #开源 #AutoML #持续学习 #DeepSeek

Deli_AutoResearch — 自主研究框架

来源：https://victorchen96.github.io/auto_research/framework.html 该技能本身是一份自包含的 Markdown 文档。

它不依赖任何外部资源或私有基础设施——单一 SKILL.md 文件完整定义了整个协议：动机、行为约束、架构、状态文件、停滞检测、心跳看门狗、调度模式以及工程约束。下面是结构化阅读指南；完整的 SKILL.md 附在文末，可一键复制。

↓ 跳转至完整 SKILL.md (https://victorchen96.github.io/auto_research/framework.html#fullmd)

01动机：三种失效模式

长时间运行的代码代理会反复出现三种失效模式，其共同原因是缺乏工程化支撑，而非模型能力不足。框架中的每个机制都针对这些模式。

01

认知循环

连续的迭代尝试相似方向，收益递减，无法自行摆脱局部最优。

02

停滞

代理完成一个工作块，总结，然后等待反馈。从外部看，会话似乎仍在活动，轮询也在进行，但实际工作已停止——这比崩溃更常见。

03

运行时脆弱性

上下文压缩静默地破坏了循环；关闭会话会终止其附带的定时器。故障在默认情况下不会被注意到。

02行为约束

框架的硬性规则，每条都源于一次真实的失败。

i

零交互

运行期间不得提示用户：不得使用计划模式，不得使用提问工具，不得以提问结束。持续工作直到被停止。自行解决歧义，并将推理过程记录到日志中（级别=决策）。

ii

就绪即执行

最常见的隐性违规：完成所有准备工作后询问“我应该提交吗？”。准备的目的就是为了执行；提交、重新提交、修复和启动监控都是常规操作，无需确认。

iii

回调即报告存活

上下文压缩后，循环会静默地消亡。每次回调的第一个动作是更新自身的 last_seen，然后检查活跃性；检测到失败则立即重启并记录日志。

iv

将状态持久化到文件

所有进度都写入 state/ 文件，而非对话记忆。每次迭代启动一个全新的会话，仅注入整理好的状态；绝不使用恢复（resume）。

v

守护者/工人分离

心跳巡逻队对其自身以外的任务只能执行三项操作：活跃性检查、重启、轻推。它不会读取任务数据、修改状态文件或代表任务向用户报告。依据：曾有巡逻队越权干预其他任务事务，导致上下文污染、报告偏差以及并发写入风险。

03架构

编排器监控状态、检测停滞并注入新方向；每个任务在其自己全新的会话中运行。三个核心决策：执行与评估分离，偏好新会话而非恢复，以及强制执行方向多样性。

┌── 编排器（当前会话/持久化定时任务）─────────┐│监控状态文件 → 检测停滞 → 注入新方向│└──────┬──────────────────┬──────────────────┬────────────┘▼ ▼ ▼[任务A] [任务B] [任务C] ← 每个任务使用各自全新的会话

04状态文件系统

每个任务维护其自身的状态和日志目录。三种进程类型写入不同的日志流，因此调试时无需跨文件关联。

{task}/state/ ├── task_spec.md # 目标 / 里程碑 / 成功标准├── progress.json # {迭代次数, 状态, 停滞计数, …}├── findings.jsonl # 累积的发现（仅追加）├── directions_tried.json # 已尝试的方向（多样性判断依据）└── iteration_log.jsonl # 每次迭代的摘要{task}/logs/ ├── work.jsonl # 工作代理；决策标记为 level=decision├── orchestrator.jsonl # 编排器└── heartbeat.jsonl # 心跳看门狗

05停滞检测与转向

为什么转向结构而非战术？

这源于实践：当一个任务在某个框架内反复停滞时，决定性的进展通常来自修正环境/结构性约束本身，而不是在现有框架内更努力地调整策略参数。两次停滞就应该促使重新审视环境，而不是在一个方向上挖掘更深。

06心跳看门狗（三层）

业务循环本身并不可靠，需要一个独立的守护层。三层相互检查：任何一层失效都能被另一层检测到并恢复。

停滞检测阈值

如果进度超过2小时没有更新，且最后一次输出是一个问题 → 判定为停滞，启动一个轻推子代理（注入该任务的 task_spec 和 progress，指示其继续并更新状态）。连续三次轻推后仍无进展 → 判定为结构性卡住；停止轻推，以新方向重新启动。2小时的阈值特意短于4小时的卡住任务阈值：停滞是自愿停止，修复成本低，值得更早捕获。

07子代理调度模式

子代理提示应包含：背景、可验证的交付物、工作目录、文件/行数限制以及完成标准。

08工程约束

源于元学习循环从真实失败中习得的规则；违反这些规则会经验性地导致停滞或退化。

1

每次迭代最多5个大文件；任何单个文件不超过300行。

2

状态通过文件注入，而非对话历史。

3

验证（测试/编译/检查）必须在迭代之间运行。

4

类似引用的内容每20条验证一次，绝不批量处理。

5

当存在多个候选方向时，倾向于增加多样性而非深入挖掘一个方向。

6

无法解决的外部依赖失败需升级处理：完整报告 + 通知所有者 + 轮询回复；绝不可静默放弃。

09验证与局限性

该框架已成功执行多个异构的长期目标任务。论文撰写任务的输出（页数/引文/框架内自评）：

局限性（坦诚说明）

1. 评分来自框架内的多角色模拟评审；仅可在同一协议内进行纵向比较，不构成外部质量声明。
2. 最长连续运行为72小时，期间有6次方向性的人工输入——零运营干预，保留了方向性干预。
3. 伪造的引文和数据伪影源于大语言模型本身；框架将外部验证作为流程中的一个机械步骤，并未消除错误根源。
4. 职责分离依赖于协议约束，而非模型自律；移除约束会导致越权行为再次出现。

10完整 SKILL.md

上述指南的权威来源——一份自包含的 Markdown 文档，不依赖任何外部资源。展开阅读；一键复制。

▶展开完整 SKILL.md复制``

name: Deli_AutoResearch description: 一个面向长期自主任务的协议框架。针对三个经验观察到的失效模式——认知循环、停滞、运行时脆弱性——通过规定状态管理、停滞检测和看门狗机制来解决。已在多种任务类型上验证，包括论文撰写（4篇ICLR格式综述，框架内自评8.0-8.6/10）。 type: 代理框架 tags: 自主, 长期, 零交互, 抗循环, 心跳看门狗, 循环, 多代理, 无人值守, 编排

Deli_AutoResearch

此技能是一个面向长期（数天至数周）自主任务的协议框架。它不附带任何可执行代码；相反，它规定了一套久经考验的约定：如何持久化状态，如何检测停滞，如何分层部署守护者，以及哪些约束约束了代理行为。实现细节留给采用者根据自己的环境处理。

1. 动机

长时间运行的代码代理会出现三种反复出现的失效模式：

1. 认知循环——连续迭代尝试相似方向，收益递减，无法自行摆脱局部最优。
2. 停滞——代理完成一块工作，输出总结，然后等待用户反馈。从外部看，会话似乎仍活跃，轮询也在进行，但实际工作已有效停止。运行日志显示这比崩溃更常见。
3. 运行时脆弱性——上下文压缩静默地破坏循环；关闭会话会终止其附带的定时器。故障在默认情况下不被注意。

这三种模式的共同原因是缺乏工程化支撑，而非模型能力不足。此框架中的每个机制都针对上述失效模式。

2. 行为约束

1. 零交互——运行期间不得提示用户：不得使用计划模式，不得使用提问工具，不得以提问结束。持续工作，直到用户要求你停止。自行解决歧义，并将推理写入日志（级别=决策）。
2. 就绪即执行——最常见的隐性违规：完成所有准备后询问“我应该提交吗？”。准备的目的就是为了执行；提交、重新提交、修复和启动监控都是常规操作，无需确认。
3. 回调即报告存活——上下文压缩后，循环静默死亡。每次回调的第一个动作是更新自身的 last_seen，然后检查活跃性；检测到失败则立即重启并记录日志。
4. 将状态持久化到文件——所有进度都写入 state/ 文件，而非对话记忆。每次迭代启动一个全新的会话，仅注入整理好的状态；绝不使用恢复。
5. 守护者/工人分离——心跳巡逻队对其自身以外的任务只能执行三项操作：活跃性检查、重启、轻推。它不会读取任务数据、修改状态文件或代表任务向用户报告。

3. 架构

┌── 编排器（当前会话/持久化定时任务）─┐
│ 监控状态文件 → 检测停滞 → 注入方向 │
└────┬─────────────┬─────────────┬────────────┘
  [任务A]      [任务B]      [任务C]   ← 每个任务使用各自全新的会话

核心设计决策：

• 执行与评估分离——执行工作的代理不自行判断进度；停滞判定由编排层基于量化指标做出。
• 新会话优于恢复——上下文累积是认知循环的主要原因。每次迭代从全新的上下文开始；状态通过文件注入。
• 强制执行方向多样性——每次迭代前，读取已尝试的方向列表；新方向必须与所有历史方向不同。

4. 状态文件

{task}/state/
├── task_spec.md           # 目标 / 里程碑 / 成功标准
├── progress.json          # {迭代次数, 总发现数, 状态, 停滞计数}
├── findings.jsonl         # 累积的发现（仅追加）
├── directions_tried.json  # 已尝试的方向
└── iteration_log.jsonl    # 每次迭代的摘要

{task}/logs/
├── work.jsonl             # 由工作代理写入；决策标记为 level=decision
├── orchestrator.jsonl     # 由编排器写入
└── heartbeat.jsonl        # 由心跳看门狗写入

日志行格式：{“ts”:“…”, “source”:“…”, “level”:“info|warn|error|decision”, “event”:“…”, “detail”:“…”}

5. 用法

# 1. 初始化任务目录，写入 state/task_spec.md 和初始 progress.json

# 2. 启动编排器循环：
/loop 2h 检查所有任务：(1) 读取 progress.json；
(2) 如果停滞计数>=3，生成一个新方向；(3) 通过代理工具启动一个工作代理
(带有明确的目标和完成标准)；
(4) 将结果写回状态文件。零交互。

# 3. 注册一个持久化的心跳看门狗（跨会话存活）：
每小时巡逻：写入一个时间戳；检查每个循环的 last_seen 是否超过间隔×3，
如果超过则重启；检查每个任务的进度是否有超过2小时的停滞，如果停滞则轻推。
零交互。

6. 停滞检测与转向

“转向结构而非战术“源于实践：当某个任务在某个框架内反复停滞时，决定性的进展通常来自修正环境/结构性约束本身，而不是在现有框架内更努力地调整策略参数。

7. 心跳看门狗

业务循环本身并不可靠，需要一个独立的守护层。三层相互检查（V3）：

任何一层失效都能被另一层检测到并恢复