Codex-Loop In Sleep - AI-Scientist 专题

为什么这条线值得从 AI-Scientist 里单独拆出来

因为 ARIS 和我们自己的 codex-loop 都不只是“跑一个循环”。它们都在回答同一类问题：

循环如何持续

不是一次性 prompt，而是 plan、evolution、状态和 handoff 怎么留存。

循环如何自我修正

失败、偏航、模型分工、健康检查，哪些会反过来改下一轮行为。

循环如何沉淀长期记忆

不是只改完代码，而是把项目知识、失败记录和参考洞察沉淀下来。

所以这里值得讲的不是“它也有 loop，我们也有 loop”，而是：ARIS 更像研究专用的 in-sleep system，codex-loop 更像通用型 in-sleep shell。

ARIS 真正比我们厚的，不是 daemon，而是外层方法系统

能力层	ARIS / Auto-Research In Sleep	对 codex-loop 的启发
workflow family	`idea-discovery`、`experiment-bridge`、`auto-review-loop`、`paper-writing`、`rebuttal`	不只保留一个 loop 壳，而是继续长出 site-growth、publish-loop、reference-mining 等专门 workflow。
persistent wiki	`research-wiki` 会沉淀 paper、idea、negative results 和 anti-repeat memory	从 plan/evolution 再往外长一层 project wiki / topic memory / failed-attempt memory。
meta optimize	`meta-optimize` 会根据技能调用、失败日志和覆盖情况反向改技能	让运行日志不只是记录，而是反过来推动 prompt、skill、plan 的外层自优化。
watchdog health layer	单独的 `watchdog.py` 负责 session / download / GPU / idle 健康监控	把执行 daemon 与健康 watchdog 拆开，避免所有监控都挤在主循环里。
cross-model review	明确强调 executor / reviewer 可以来自不同模型族	后面可以把 codex-loop 长成 executor、critic、publish reviewer 三种角色分工。

[插图提示词]

用途：画 ARIS 到 codex-loop 的“可借鉴能力梯子”。

形式：五层能力梯子图；Mermaid 适合。

提示词：左列放 ARIS，右列放 codex-loop，中间用五条横向梯子连接：workflow family、persistent wiki、meta optimize、watchdog health layer、cross-model review。ARIS 一侧标出对应模块名，codex-loop 一侧标出当前状态（已有 / 部分已有 / 缺失 / 待建设）。

Mermaid 更适合：是。

ARIS vs codex-loop in sleep：五条最值得借的能力线与当前状态

我们已经有的部分，其实已经很像通用型 in-sleep shell

长循环壳

codex-loop 已经有 daemon、thread resume、prompt contract、status、tick logs。

计划与演化

已经有 dedicated plans、evolution notes、sticky active task、task board 和 workspace shell。

多域任务

不是只跑科研，还能跑 site、CLI、workspace、知乎、热榜、reference-mining 等长期任务。

发布闭环

GitHub、GitHub Pages、知乎发布时间窗和内容分发都已经接进 loop contract 里。

所以更准确的说法不是“我们也做了个 ARIS”，而是：我们已经有了一个面向工程与知识站点的通用型 codex-loop in sleep 外壳。

真正还差的，是三层外壳再加厚

1. 外层自优化

现在更多是人工看日志再改 prompt；下一步应该让 loop 能根据失败与命中情况自动建议改写 task / skill / plan。

2. 长期知识层

现在有 plan 和 evolution，但还缺 topic wiki、negative memory 和 reference insight memory。

3. 健康与执行分层

daemon、状态台和 workspace 已有雏形，但 watchdog 还没有真正独立成一层。

第一条真正回写到 codex-loop 路线图的借鉴能力

这一轮先不直接做“自动改 prompt”的大系统，而是先把 meta-optimize 落成一条最小可执行规则：每次 bounded pass 如果暴露了重复性的 loop 低效点，就提炼出一条短的 loop improvement candidate。

先记候选规则

每轮最多提炼一条 loop-level 改进候选，避免把演进记录写成无边界 wishlist。

再决定是否升级

只有在问题重复出现，或者新规则明显能改善下一 tick 时，才允许写回 .codex-loop/prompt.md。

保持操作性

prompt 级回写必须改变后续的 task selection、verification、publishing 或 handoff 行为，而不是多补一段解释文字。

层	当前状态	缺口	这次的最小回写
logs	已有 tick logs、evolution notes、handoff	记录很多，但没有把重复低效点收敛成固定候选规则	要求每轮只提炼一条 `loop improvement candidate`
prompt	主 prompt 已经能约束 task selection 和 publishing window	prompt 变更更多是人工临时补充，缺少“何时允许写回 prompt”的门槛	增加“重复出现或能改善下一 tick 才能升级到 prompt”的规则
skill / plan	会按 skill 执行，也会更新 active plan	缺少把 loop-level 经验沉淀成可复用操作约束的薄层	先把 meta-opt 定位成短规则回写，而不是大而全的新系统

persistent wiki 应该先从哪一层长出来

这一轮先把三选一问题定死：第一承载层先选 topic wiki，而不是先做一个过宽的 project wiki，也不是先孤立地新建一份 `failed-attempt memory`。

不先做 project wiki

因为 `codex-loop` 现在是多 topic、多页面、多发布链路并行生长；太早压回一个总账本，反而会把边界重新糊掉。

也不先孤立做失败库

因为 `.claude/plans/loloop/evolution-*.md` 已经天然记录了 bounded pass 的 defer、decision 和 anti-repeat 线索。

先把现有三层读清

topic page 是 topic wiki，active plan 是 working memory，evolution trail 是 failed-attempt memory。

层	当前承载	角色	为什么先这样定
topic wiki	`site/md/topic-.md` + `site/topic-.html`	对外稳定知识面	每个长期子专题已经有稳定 URL、结构和读者语义
working memory	`.claude/plans/loloop/active-*.md`	当前线程的执行上下文	最适合放 active focus、checklist、scope 和 routing rule
failed-attempt memory	`.claude/plans/loloop/evolution-*.md`	anti-repeat memory	bounded pass 的 failed / deferred / decision 已经是“别重复踩坑”的最小单元

所以 persistent wiki 的第一版，不是马上新建一套很大的 memory 系统，而是先把现有的 `topic page / active plan / evolution trail` 三层明确读成一套可复用的 memory layout。

watchdog health layer 应该怎么与 daemon / workspace 分层

这一轮先不做独立 watchdog 进程，而是先把三层边界说清。对 `codex-loop` 来说，关键不是“再造一个大 daemon”，而是把 推进循环、人工操作、异常健康检查 三类职责拆干净。

层	主要职责	不该承担什么	当前 codex-loop 对应物
daemon	驱动 tick、选任务、推进 handoff、维护主循环节奏	不该把所有健康探测和人工操作入口都塞进自己	`.codex-loop/prompt.md` + daemon tick / thread resume 约束
workspace	给操作者看状态、改计划、写 evolution、做局部控制	不该替代主循环做全局调度，也不该自己判断长期健康	`site/app-likecode-workspace.html` + relay shell
watchdog	低频、独立、面向异常的健康检查与告警	不该承担内容生产、任务选择或富交互工作台职责	目前还没有独立层，只是一个明确缺口

ARIS 给的样子

watchdog.py 更像任务注册 + 低频轮询 + 状态文件输出，只在 `DEAD / STALLED / IDLE` 这类异常上发信号。

codex-loop 现在该怎么读

daemon 继续负责推进循环，workspace 继续负责人工可视化和局部控制，watchdog 以后如果要长出来，只负责健康探测、异常摘要和恢复提示。

这轮的收缩决策

暂时不单独新开 `watchdog` 计划线；只有当 shell orphan、relay 卡死、session 丢失或下载挂起反复出现时，再升级成独立计划线。

把这条线做成长期子专题，最顺的开展路线

第一步：先固定站内口径

把 ARIS 读成研究专用 in-sleep system，把 codex-loop 读成通用型 in-sleep shell。

第二步：先落一条最小 meta-opt 规则

先把每轮提炼一条 loop improvement candidate 这件事固定下来，再谈更重的自优化系统。

第三步：先落三层 wiki 布局

先把 topic wiki + working memory + failed-attempt memory 读清，再决定要不要单独长出更重的 project wiki。

第四步：把 watchdog 固定成健康层

把 watchdog 固定成健康探测、异常摘要和恢复提示层，而不是再膨胀一个执行层。

第五步：作为 AI-Scientist 邻接样本

让它承担 “研究系统如何长出 sleep 层” 的解释任务，而不是跟 paper pipeline 混成一页。

Codex-Loop In Sleep 把 ARIS 的方法借到通用长循环里