一位 DeepSeek 研究员刚刚开源了他的 AutoResearch 个人项目。

AutoResearch Agent 首次自主规划 GPU 实验，并在 DeepSeek 285B 模型上提交了真实的强化学习运行任务。整个强化学习流程——实验设计、代码编写、运行、调试和结论总结——实现了 100% 自动化，全程无需人工干预。同时，该项目还发布了第四篇综述论文，这次聚焦于自我对弈（Self-play）。

受 AlphaZero 启发，核心洞见在于：先验知识并不总能提升上限——模型仅通过与自己对抗就能发现更全局的最优解。团队将此视为其持续学习（Continual Learning）研究之旅的开端。

链接： 框架：https://victorchen96.github.io/auto_research/framework.html… 综述论文（自我对弈）：https://victorchen96.github.io/auto_research/paper.html… 自我对弈故事博客：https://victorchen96.github.io/blog_self_play_story.html…

与我 1对1 撰写 AI 论文 - https://airesearchmastery.com

#AI #强化学习 #自对弈 #开源 #自动化机器学习 #持续学习 #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 动机：三种失败模式

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

01

认知循环

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

02

停滞

Agent 完成一个块，进行总结，然后等待反馈。从外部看，会话似乎仍在运行，轮询也在继续，但工作实际上已经停止——这种情况比崩溃更常见。

03

运行时脆弱性

上下文压缩悄无声息地中断循环；关闭会话会带走寄生其上的计时器。默认情况下，故障不会被注意到。

02 行为约束

框架的硬性规则，每条都源自实际故障。

i

零交互

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

ii

准备即执行

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

iii

回调即报告存活

上下文压缩后，循环会悄然死亡。每个回调的第一个动作是更新自身的 last_seen，然后检查活性；一旦检测到故障，立即重启并记录。

iv

将状态持久化到文件

所有进度都写入 state/ 文件，而非会话记忆。每次迭代启动一个全新的会话，仅注入精心策划的状态；绝不使用恢复。

v

守护者/工作者分离

心跳巡逻队对非自身的任务只能执行三项操作：活性检查、重启、轻推。它不读取其数据、不修改其状态文件、也不代其向用户报告。依据：一次巡逻队曾越界干预其他任务的事务，导致上下文污染、报告漂移和并发写入风险。

03 架构

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

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

04 状态文件系统

每个任务维护自己的状态和日志目录。三种进程类型写入独立的日志流，因此调试永远无需跨文件关联。

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

05 停滞检测与转向

这源于实践：当任务在一个框架内反复停滞时，决定性的收益通常来自纠正环境/结构约束本身，而非在现有框架内更努力地调整策略参数。两次停滞应促使质疑环境，而非在同一方向更深挖掘。

06 心跳看门狗（3层）

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

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

07 子代理调度模式

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

08 工程约束

从实际失败的元学习循环中推导而来；违反这些约束会经验性地导致停滞或回归。

1

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

2

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

3

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

4

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

5

有多个候选方向时，优先增加多样性而非深挖一个。

6

无法解决的外部依赖故障需上报：完整报告 + 通知所有者 + 轮询回复；绝不静默放弃。

09 验证与限制

该框架已承担多项异构的长周期任务。论文撰写轨道的产出（页数/引用/框架内自评）：

1. 得分来自框架内多角色模拟评审；仅在同一协议内可纵向比较，不代表外部质量声明。
2. 最长连续运行时间为72小时，包含6次方向性人工输入——零操作干预，保留了方向性干预。
3. 虚构的引用和数据伪影源于 LLM 本身；框架将外部检查变为流程中的机械步骤，并不能消除错误源。
4. 职责分离依赖于协议约束，而非模型纪律；移除约束后越界行为会再次出现。

10 完整 SKILL.md

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

▶展开完整的 SKILL.md复制

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

# Deli_AutoResearch

这项技能是一个用于长周期自主任务（数天到数周）的协议框架。它不提供可执行代码；而是规定了一套经过实战检验的约定：如何持久化状态、如何检测停滞、如何分层守护者、以及哪些约束绑定 Agent 行为。实现细节留给采用者根据自身环境决定。

## 1. 动机

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

1. 认知循环——连续迭代尝试相似方向，收益递减，无法自行跳出局部最优。
2. 停滞——Agent 完成一块工作，输出摘要，然后等待用户反馈。从外部看会话似乎仍在运行，轮询也在继续，但工作实际上已经停止。运行日志显示这比崩溃更常见。
3. 运行时脆弱性——上下文压缩悄无声息地中断循环；关闭会话会带走寄生其上的计时器。默认情况下，故障不会被注意到。

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

## 2. 行为约束

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

## 3. 架构

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

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

## 4. 状态文件

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

    {任务}/logs/
    ├── work.jsonl             # 由工作者 Agent 写入；决策标记为 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) 如果 stale_count>=3 则生成新方向； (3) 通过 Agent 工具启动一个工作者 Agent
    （附带明确目标和完成标准）； (4) 将结果写回状态文件。零交互。

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

## 6. 停滞检测与转向

| 机制 | 规则 |
|------|------|
| 停滞检测 | 迭代产生0个新发现或指标下降 → 停滞计数 + 1 |
| 强制转向 | 停滞计数 >= 2 → 更改结构约束，而非战术参数；>= 4 → 标记为需人工关注 |
| 方向多样性 | 新方向必须与所有已尝试方向不同；停滞发生后，注入扰动策略 |
| 轮次上限 | 单个工作会话上限为15轮或30分钟 |

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

## 7. 心跳看门狗

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

| 层 | 形式 | 依赖 | 角色 |
|----|------|------|------|
| L0 | 驻留 Shell 守护 | 无会话 | 心跳过期 > 2小时 → 通过无头 Agent 启动紧急巡逻 |
| L1 | 持久化定时任务，每小时 | 一个活动交互式会话 | 检查每个循环的 last_seen，重启超时循环，检测停滞并进行轻推 |
| L2 | 业务循环 | 每个任务自己的会话 | 每个回调的第一行更新自身的 last_seen |

任何一层死亡都能被另一层检测并恢复。

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