autoresearch

name	AutoResearch
description	一套面向长程自主任务的协议框架。针对三个经实证观察到的失败模式——认知循环、停滞、运行时脆弱性——通过规定状态管理、停滞检测和看门狗机制来应对。已在多种任务类型上验证，包括论文写作（4 篇 ICLR 格式综述，在框架内自评 8.0-8.6/10）。
type	Agent Framework
tags	autonomous, long-horizon, zero-interaction, anti-loop, heartbeat-watchdog, loop, multi-agent, unattended, orchestration

AutoResearch

这项 skill 是一个面向长程自主任务（数天到数周）的协议框架。它不附带可执行代码；相反，它规定了一组经过实战检验的约定：状态如何持久化、如何检测停滞、如何分层设置守护者，以及哪些约束绑定智能体行为。具体实现细节留给采用者的运行环境决定。

1. 动机

长时间运行的代码智能体会反复出现三类失败模式：

1. 认知循环——连续迭代尝试相似方向，收益递减，无法自行跳出局部最优。
2. 停滞——智能体完成一段工作，输出总结，然后等待用户反馈。从外部看会话仍然存活，轮询也在运行，但实际工作已经停止。运行日志显示，这比崩溃更常见。
3. 运行时脆弱性——上下文压缩会悄悄破坏循环；关闭会话会连带关闭依附于它的定时器。默认情况下，这些失败不会被发现。

这三者的共同原因不是模型能力不足，而是缺少工程脚手架。本框架中的每个机制都针对上述失败模式。

2. 行为约束

1. 零交互——运行期间不向用户提问：不进入 Plan Mode，不使用 question tool，不以问题结尾。持续工作，直到用户停止你。自行解决歧义，并将推理写入日志（level=decision）。
2. 就绪即执行——最常见的隐性违规是：完成所有准备工作后询问“是否提交？”。准备的目的就是执行；提交、重新提交、修复和启动监控都是常规操作，不需要确认。
3. 回调即报告存活——上下文压缩后，循环会悄无声息地死亡。每次回调的第一个动作都是更新自己的 last_seen，然后检查存活状态；一旦检测到失败，立即重启并记录日志。
4. 将状态持久化到文件——所有进度都写入 state/ 文件，而不是对话记忆。每次迭代都启动一个全新会话，只注入经过整理的状态；永远不要使用 resume。
5. 守护者 / 工作者分离——心跳巡逻对不属于自己的任务只能执行三类动作：存活检查、重启、推动。它不读取这些任务的数据，不修改它们的状态文件，也不代表它们向用户汇报。

3. 架构

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

核心设计决策：

• 将执行与评估分离——执行工作的智能体不判断自己的进展；停滞判断由编排层基于定量指标完成。
• 使用全新会话而不是 resume——上下文累积是认知循环的主要原因。每次迭代都使用全新上下文；状态通过文件注入。
• 强制方向多样性——每次迭代前，读取已经尝试过的方向列表；新方向必须不同于所有历史方向。

4. 状态文件

{task}/state/
├── task_spec.md           # 目标 / 里程碑 / 成功标准
├── progress.json          # {iteration, total_findings, status, stale_count}
├── 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 check all tasks under : (1) 读取 progress.json；
(2) 如果 stale_count>=3，生成一个新方向；(3) 通过 Agent tool 启动一个工作智能体
（带有明确目标和完成标准）；
(4) 将结果写回状态文件。零交互。

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

6. 停滞检测与转向

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

“转向结构，而不是战术”来自实践经验：当一个任务在某个框架内反复停滞时，决定性收益通常来自修正环境或结构性约束本身，而不是在现有框架内更努力地调参。

7. 心跳看门狗

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

层级	形式	依赖	角色
L0	常驻 shell guard	无会话	心跳过期 > 2h → 通过 headless agent 启动紧急巡逻
L1	持久 cron，每小时	一个存活的交互式会话	检查每个循环的 last_seen，重启超时循环，检测停滞并推动
L2	业务循环	每个循环都是自己的会话	每次回调的第一行更新自己的 last_seen

任意一层死亡，都可以被另一层检测并恢复。

停滞检测：如果进度超过 2 小时没有更新，并且最后输出是一个问题 → 判定为停滞，启动一个推动子智能体。连续三次推动仍无进展 → 判定为结构性卡住；停止推动，并用新方向重新打开。2 小时阈值故意短于 4 小时的卡住任务阈值。

8. 子智能体调度模式

模式	用途	核心思想
A 目标驱动	研究迭代	注入已尝试方向，要求可验证发现，写回 findings.jsonl
B 并行探索	复杂子问题	在一条消息中启动多个智能体：调查、反驳、跨领域类比
C 实验运行	长时间计算任务	提交后立即启动分钟级轮询：自动诊断错误、修复、重新提交
D 验证	迭代后 QA	一个独立子智能体审计发现的证据链

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

9. 工程约束

1. 每轮迭代最多 5 个大文件；单个文件不超过 300 行。
2. 状态通过文件注入，而不是通过对话历史。
3. 每轮迭代之间必须运行验证（test / compile / check）。
4. 类引用内容每 20 条验证一次，绝不批量堆积。
5. 当存在多个候选方向时，优先增加多样性，而不是在单一方向上继续深挖。
6. 无法解决的外部依赖失败需要升级处理（完整报告 + 通知所有者 + 轮询回复）；绝不静默放弃。

10. 验证与限制

该框架已承载多个异构任务：学术论文写作、长程研究等。论文轨道输出：

论文	页数	引用数	自评
Autonomous Research Agents	59	228	8.0/10
Continual Learning	65	326	8.0/10
Long-Horizon Decision-Making	55	384	8.0/10
Self-Play（285B 强化学习实验 + 理论加固）	75	217	8.6/10

限制：

1. 分数来自框架内多角色模拟评审；仅能在同一协议内进行纵向比较，不构成外部质量声明。
2. 记录中最长的连续运行是 72 小时，期间有 6 次方向性人工输入——零操作干预，但保留方向性干预。
3. 虚构引用和数据伪影源自 LLM 本身；该框架把外部检查变成流程中的机械步骤，但并不会消除错误来源。
4. 职责分离依赖协议约束，而不是模型自律；一旦移除这些约束，越权行为就会重新出现。