# RESEARCH-004: 7×24小时自主循环编码 Agent 架构与分层编排实证调研研报

- **研报编号**：`RESEARCH-004`
- **课题**：业界 7×24 小时不间断自主编码循环（Continuous Agentic Coding Loop）的真实底层实现机制、Ralph Loop / Loop Engineering 模式解析与大型复杂工程分层架构（Hierarchical Lead-Worker）落地范式
- **调研时间**：2026年10月（基于 X/Twitter 顶级开源实践、Boris Cherny、Geoffrey Huntley 及主流 Agentic Coding 框架一手事实考证）
- **一手信源与事实依据**：
  - Geoffrey Huntley: *The "Ralph Wiggum" loop pattern ("Ralph is a Bash Loop")* (2025-2026)
  - Boris Cherny (Creator of Claude Code): *Loop Engineering over Prompt Engineering*
  - Anthropic Claude Code / Aider / Cursor / OpenHands (OpenDevin) / Inngest Durable Orchestration
  - Sudoall & Mastra Multi-Agent Hierarchical Architectures (Manager-Worker Pattern)
- **统一语言遵循**：[`CONTEXT.md`](../../CONTEXT.md)
- **协议依据**：[`AGENTS.md`](../../AGENTS.md)（实证探路优先原则与实体资产留痕优先原则）
- **状态**：已落盘归档 ✅

---

## 1. 调研背景与核心问题 (Questions)

在 X（Twitter）与 AI 极客社区中，近期频繁出现关于 **“Agent 7×24 小时不间断工作 / 夜间自主编码循环 (Overnight Autonomous Coding)”** 的热烈讨论：开发者在睡前丢下一个目标，Agent 在后台不眠不休地迭代写代码、跑测试、修 Bug、提 PR，早晨醒来直接验收合并。

针对这种现象，本研报深入考证以下四个核心问题：
1. **真实物理机理**：大模型本质是无状态的单次 HTTP 调用，且受限于上下文窗口，它是如何做到“7×24 小时不间断运行”的？
2. **"Loop" 是如何建立的**：社区中最成熟、最稳定的 Loop 实现形态是什么？
3. **复杂大工程的解耦策略**：复杂工程是否必须拆解为小工程？如何由一个 Lead Agent 统一领导并调度子 Worker？
4. **防失控与工程落地方案**：如何防止“上下文腐烂 (Context Rot)”、“死循环空转 (Infinite Loop)”和“天价 Token 账单”？在本工作区如何落地方案？

---

## 2. 核心真相：7×24h Loop 的真实物理机理

### 2.1 破除迷信：不是单个 Agent 在超长对话里跑 24 小时
大模型受物理定律制约，单次长会话存在严重的 **"上下文腐烂 (Context Rot)"** 缺陷：
- 随着多轮工具调用输出堆积，上下文历史迅速膨胀到数十万 Token；
- 杂音污染导致模型注意力分散、产生幻觉、指令遗忘、甚至陷入重复调用同一工具的“推理死循环 (Reasoning Loop)”；
- 单会话持续跑 24 小时在工程上必崩无疑，且 Token 成本极度昂贵。

### 2.2 业界共识：外层宿主循环驱动内层无状态 Agent ("Ralph is a Bash Loop")
在 X 上爆火并被 Claude Code 官方社区采纳的 **Ralph Loop**（由 Geoffrey Huntley 命名与普及）和 Boris Cherny 提出的 **Loop Engineering** 揭示了 7×24h 的工业级真相：

```text
┌────────────────────────────────────────────────────────────────────────┐
│ 外层宿主循环 (Outer Runner: Bash while-true / Cron / PM2 / Orca Daemon)  │
│                                                                        │
│   1. 从工单队列 (docs/issues/ 或 GitHub Issues) 取出下一个待办 Task        │
│   2. 为该 Task 实例化一个 全新、干净、无状态 (Fresh Context) 的 Agent 进程 │
│                                                                        │
│        ┌────────────────────────────────────────────────────────┐      │
│        │ 内层 Agent 周期 (短暂、专注、有明确结束点)               │      │
│        │  - 读当前单一工单要求                                   │      │
│        │  - 读代码库规范 (AGENTS.md / CONTEXT.md)                │      │
│        │  - 编码改动 + 运行单元测试验证 (TDD 绿灯)                │      │
│        │  - 提交 Git Commit + 标记工单状态 Completed            │      │
│        │  - 发送 worker_done / exit 0 (主动销毁当前会话)         │      │
│        └────────────────────────────────────────────────────────┘      │
│                                                                        │
│   3. 宿主捕获退出码，回收终端资源                                        │
│   4. 触发 Git 合入或推送到远程 PR                                       │
│   5. 检查队列是否还有任务；若有则开始下一轮，若无则休眠监听新事件            │
└────────────────────────────────────────────────────────────────────────┘
```

> **核心哲学**：
> **“Memory is the Filesystem, not the Context Window.”**（记忆在外置的文件系统与 Git 中，而不是在模型的聊天上下文窗口中）。
> Agent 是消耗品，用完即弃；代码、测试、工单与 Git Commit 才是永恒的真实源（Ground Truth）。

---

## 3. 复杂大工程的解耦之道：分层架构 (Hierarchical Lead-Worker)

用户提出的设想：*“有的代码工程比较复杂，是不是要拆分成一个一个小的工程？然后由一个 Agent 来领导它？”*  
**这与当前全球 AI 软件工程最前沿的架构设计（Manager-Worker / Orchestrator-Worker Pattern）完全吻合。**

### 3.1 为什么必须拆解？
- **单模块认知负荷 (Cognitive Load)**：单个 Agent 每次只需要关注 2~3 个文件和局部测试，正确率接近 95%；一旦让它全局重构 50 个文件，正确率骤降至 20% 以下；
- **并行化收益 (Concurrency)**：解耦后的独立模块可以通过多 Agent 物理并发推进，原本需要 10 小时的迁移任务可缩短至 1 小时。

### 3.2 分层架构的分工职责

| 角色层级 | 对应实体 | 核心职责 | 行为约束 |
| :--- | :--- | :--- | :--- |
| **领导层 (Lead / Architect Agent)** | 主协调者 (Coordinator) | 1. 业务目标与需求分析；<br>2. 系统架构分解（深模块接口设计）；<br>3. 规划依赖 DAG，将复杂系统拆解为**示踪工单 (Tracer-bullet Tickets)**；<br>4. 派发 Worker，监控事件与验收合并。 | **严禁亲自写细节业务代码**。保持全局上帝视角，避免上下文被琐碎细节污染。 |
| **执行层 (Worker Agents)** | 专项子 Agent (Workers) | 1. 领到单一独立工单；<br>2. 在隔离环境（如独立 Git Worktree）中编写代码；<br>3. 编写并通过单元测试（红-绿-重构）；<br>4. 汇报 `worker_done` 并立即自我销毁。 | **只能改动工单授权的文件范围**。完成即退出，绝不跨工单滞留。 |
| **仲裁层 (Verification Oracle)** | 自动化门禁 (CI / Tests) | 1. 执行 `pytest` / `npm test` / 编译检查；<br>2. 静态合规扫描（Lint、0 LaTeX 残留、0 Markdown 乱码）；<br>3. 双轴代码审查（`code-review`）。 | **客观真理裁决器**。不依赖 Agent 主观口头报告，只看自动化命令退出码。 |

---

## 4. 7×24h 持续循环的防失控防线 (Safety Guardrails)

在实现无人值守的持续循环时，业界总结出三大必不可少的熔断防线：

1. **迭代步数与超时硬上限 (Turn & Time Budget)**：
   - 每个 Worker 会话硬性限制最大 Tool Call 次数（如最多 25 步）和最大超时时间（如 15 分钟）；
   - 超时未解决自动标记工单为 `failed`，由 Coordinator 记录日志并跳过，绝不陷入死等。
2. **工作树物理隔离与修剪 (Worktree Isolation & Prune)**：
   - 每一个 Worker 在独立的 Git Worktree（`--worktree new-child`）中作业；
   - 即使某个 Worker 写崩了代码或产生了死循环脏数据，主分支（`main`）完好无损，直接废弃并 Prune 该工作树即可。
3. **人类介入与高危熔断 (Human-in-the-Loop Hooks)**：
   - 禁止自动执行高危指令（如 `git push --force`、删除关键生产分支、清空数据库）；
   - 一旦触发高危行为，自动挂起循环并通过 Webhook/手机通知（如 Pushover / Telegram / Discord）呼叫人类介入。

---

## 5. 在本项目与 Orca 体系下的落地方案

我们当前的工程体系（`son_learning` + `Orca CLI` + `AGENTS.md`）实际上已经完成了 80% 的架构铺垫：
1. **外置状态已完备**：`docs/specs/`（规格说明）、`docs/issues/`（显式工单队列）、`docs/research/`（事实依据）、Git Commits；
2. **Orca 调度契约已就绪**：`run-create`、`task-create --deps`、`worker-start`、`check --wait`、`worker-release`；
3. **分级法则已立法**：Tier 1 微调极速闭环，Tier 2 启动 Coordinator 编排。

### 落地 7×24h Continuous Loop 的极简工业实践：
编写一个 **外部守护脚本 (`scripts/continuous_runner.py` 或 `scripts/ralph_loop.sh`)**：
```bash
#!/usr/bin/env bash
# Ralph-style Autonomous Runner for son_learning
while true; do
  # 1. 扫描 docs/issues/ 下是否有未完成 (status != completed) 的工单
  NEXT_TICKET=$(find docs/issues -name "*.md" | xargs grep -L "已完成" | head -n 1)
  
  if [ -z "$NEXT_TICKET" ]; then
    echo "All tickets completed. Sleeping for 60s..."
    sleep 60
    continue
  fi
  
  echo "Found pending ticket: $NEXT_TICKET. Spawning fresh agent worker..."
  
  # 2. 拉起干净上下文的 Agent 处理该工单（例如通过 orca / agy 执行）
  # 3. 校验自动化测试与代码审查
  # 4. 成功后更新工单为已完成并提交 Git
done
```

---

## 6. 调研结论与总结

1. **核心发现**：7×24 小时不间断写代码的 Agent，并不是单个大模型持续聊天 24 小时，而是 **“外层宿主死循环（Outer Bash/Orchestrator Loop）＋ 内层 Fresh Agent 短命会话 ＋ 外部文件/Git 记忆 ＋ 自动化测试客观门禁”** 的工程闭环；
2. **大工程解耦**：大工程必须由 Lead Agent 拆解为深模块与显式示踪工单，由短命的子 Worker 在隔离 Worktree 中物理并发或按依赖拓扑逐一击破；
3. **我们的优势**：本工作区现行的规范（`AGENTS.md` 实体资产留痕、Orca 调度、0 LaTeX 门禁、`docs/issues/` 工单树）天然就是为了这种工业级 Loop 设计的，完全具备一键开启“过夜持续编码”的架构底座。