# PaperAgent / Loop Engineering：从 prompt agent 到设计会自转的 coding loop

Status: captured-for-positioning  
Type: WeChat blog + primary-source cross-check, not a paper  
Published: 2026-06-27 12:11:25 Asia/Shanghai  
Captured: 2026-06-27  
Language: 中文来源 + 英文一手来源；中文记录，保留关键英文术语。  

## Sources

- 微信文章：PaperAgent, "刚刚，Anthropic内部Loop Engineering方法论公开"  
  https://mp.weixin.qq.com/s/uTVEAxmfZb7mxCQoE5jLfQ
- Addy Osmani, "Loop Engineering"  
  https://addyosmani.com/blog/loop-engineering/
- Claude Code docs, `/goal`: "Keep Claude working toward a goal"  
  https://code.claude.com/docs/en/goal
- Claude Code docs, `/loop`: "Run prompts on a schedule"  
  https://code.claude.com/docs/en/scheduled-tasks
- Claude Code docs, subagents  
  https://code.claude.com/docs/en/sub-agents
- Claude Code docs, worktrees  
  https://code.claude.com/docs/en/worktrees
- 0xCodez X post about the 11-page PDF  
  https://x.com/0xCodez/status/2069736449902027136
- Google Drive PDF referenced by the WeChat article / X post: `Loop-Engineering-IEEE.pdf`  
  https://drive.google.com/file/d/1qzKI4DKnyHRpXK1J3ATPqwaqLc0iNu-M/view
- Related earlier note in this survey: Anthropic harness design  
  `../2026-03-24-anthropic-harness-design-long-running-apps/`

> Source boundary: the WeChat article frames this as "Anthropic internal Loop Engineering methodology." The primary sources I could verify are Addy Osmani's public "Loop Engineering" post, Claude Code public docs, 0xCodez's X post, and a public Google Drive PDF titled "Loop-Engineering-IEEE.pdf". The PDF itself says it is an independent reformatting of an open "Orange Book" guide, not an official Anthropic engineering blog post. Treat the WeChat article as a trend/positioning signal, not as official Anthropic documentation.

## 先放我们的观点和启发

这篇文章的重要性不在于它是否准确代表 Anthropic 内部材料，而在于它把我们一直在讲的东西换成了一个更容易传播的名字：

```text
Loop Engineering
  = stop prompting the agent directly
  = design the system that prompts, checks, remembers, schedules, and repeats
```

这和我们项目的核心非常近。我们不是只想做一个更会写前端、复刻网页、或修 bug 的模型；我们想做的是一个能在既有系统上持续推进的 coding loop。这个 loop 里，真正稀缺的不是 generation，而是 `verification / judgment`：谁判断当前产物是否满足目标，依据是什么，失败如何被记录和转化为下一轮行动。

## 和我们相关的部分

1. **任务对象从 prompt 变成 loop。** 这篇文章把软件开发 agent 的关注点从单次提示、单次代码生成，推进到 `Schedule -> Discover -> Build -> Verify -> Repeat` 的持续系统。它支持我们把 multimodal verification 放在 loop 层，而不是当作一个孤立打分器。

2. **Verifier / evaluator 是 loop 中最难也最值钱的组件。** Addy 原文、Claude Code `/goal` 文档和 Anthropic harness 文章都指向同一个结构：不要让正在生成的 agent 自己批准自己；需要一个独立 evaluator，用可观察证据决定是否继续。

3. **Loop 的失败会跨轮累积。** 单次 prompt 错了，用户马上看见；loop 错了，会把错误写进 state、第二天读回、继续建立在错误假设上。这正是我们要研究 `multimodal evidence -> actionable feedback -> persisted state -> next revision` 的原因。

## 这篇微信文章讲了什么

PaperAgent 文章把 Loop Engineering 概括成：不再逐行提示 coding agent，而是设计一个会自动提示、运行、检查和继续推进的系统。文章提到三条社区线索：

- Peter Steinberger / OpenClaw：不要再 prompting coding agents，而是设计 prompt agents 的 loops。
- Boris Cherny / Claude Code：他不再手动 prompt Claude，而是写 loops 让 Claude 自己运行。
- Addy Osmani：写下并命名 `Loop Engineering`。

文章随后把 loop 拆成：

- 四层栈：Prompt Engineering、Context Engineering、Harness Engineering、Loop Engineering。
- 五步动作：Schedule / Discover / Build / Verify / Repeat。
- 六类组件：automations、worktrees、skills、plugins/connectors、subagents、state/memory。
- 核心机制：Generator / Evaluator 分离。
- 失败模式和隐性成本：verification debt、comprehension rot、cognitive surrender、token blowout。
- 安全纪律：read a sample always、cap before you ship、keep one door open。

这些内容和 Addy Osmani 原文、Claude Code docs、以及 0xCodez/PDF 的结构高度重合。

## 一手来源核对

### 1. Addy Osmani 的 Loop Engineering

Addy 的原文定义很直接：loop engineering 是替代你自己作为 prompt agent 的人，转而设计那个做 prompt 的系统。它把 loop 放在 harness 之上一层：

```text
prompt -> context -> harness -> loop
```

Harness 负责单次 run 需要什么工具、动作和 done 条件；loop 负责让 harness 定时醒来、派生 helper、把上一轮输出喂回下一轮。

Addy 还把 Codex app 与 Claude Code 的能力并列表达为同一种 loop 原语：

- automations / scheduled tasks；
- worktrees；
- skills；
- MCP connectors / plugins；
- subagents；
- state / markdown / Linear 等外部记忆。

这点对我们有用：无论是 Codex 还是 Claude Code，关键不是单个产品，而是能力族已经趋同。

### 2. Claude Code `/goal`

Claude Code docs 把 `/goal` 定义为一个 completion condition：Claude 会持续工作，直到目标条件满足。关键不是“继续跑”，而是它在每个 turn 后由一个小而快的模型做独立检查。

这和我们的 verifier 思路非常接近：

```text
main agent does work
  -> evaluator checks condition from surfaced evidence
  -> if no, reason becomes next-turn guidance
  -> if yes, goal clears
```

限制也很重要：官方 docs 说明 `/goal` 的 evaluator 不独立运行命令或读文件，只能判断 Claude 在 transcript 中已经呈现出的证据。因此，如果要做更强的 multimodal verification，我们需要让主 agent 或 verifier 把截图、DOM、日志、测试结果、视频帧等证据显式记录出来。

### 3. Claude Code `/loop`

Claude Code docs 的 `/loop` 是 schedule-oriented：在固定间隔或动态间隔重复运行 prompt。它适合轮询 deploy、PR、CI、build 状态等。

这给我们的启发是：`/loop` 解决的是时间触发，`/goal` 解决的是条件达成；我们的 multimodal verifier 更像后者，但在长期系统里二者会组合：

```text
schedule wakes the loop
  -> discover work / observe system
  -> build or revise
  -> verify condition
  -> persist state
  -> schedule next wake
```

### 4. Claude Code subagents and worktrees

Claude Code docs 将 subagents 定义为专门化 assistants，每个有自己的 context window、system prompt、tool access 和 permissions。它们用于隔离探索、实现、review、debugging 等任务。Worktrees 则隔离并行 session，避免文件互相踩踏。

对我们来说，这意味着 verifier 可以被设计成一个 explicit subagent，而不是一个附带 prompt：

- generator subagent 负责修改；
- multimodal evaluator subagent 负责看 artifact 和证据；
- worktree 负责让多个候选修复并行；
- state 文件记录验证失败和通过原因。

## 和前两篇 blog 的关系

### 1. 和 Anthropic Harness Design 的关系

Anthropic harness 文章讲的是一个 concrete harness：planner / generator / evaluator、sprint contract、Playwright QA、多轮 app 构建。Loop Engineering 更像把这种 harness 提升为通用工作范式：不只是一次 app build，而是一个会持续醒来、发现工作、派生 agents、验证、记录并继续的系统。

可以把二者关系写成：

```text
Harness Design = how to structure one long-running build
Loop Engineering = how to make that structure recur, remember, and govern itself
```

### 2. 和 Kimi 行为输入文章的关系

Kimi 那篇强调输入侧变化：模型开始从已有产品、界面、行为记录中反推实现。Loop Engineering 则强调系统侧变化：模型不是一次性响应，而是持续运行并自我推进。

结合起来就是我们的任务形态：

```text
existing product / behavior / rendered artifact
  -> loop discovers mismatch
  -> generator revises code
  -> multimodal verifier checks visible behavior
  -> state records failure/pass
  -> loop continues
```

## 对我们项目的直接启发

### 1. Multimodal verification 是 loop 的 judgment layer

如果 generation 变得便宜，判断变得稀缺。我们可以把项目主张写得更锋利：

```text
The bottleneck of autonomous coding loops is not producing more code,
but knowing whether the produced artifact satisfies the intended behavior.
```

对于网页、交互、PDF、chart、动画、视频驱动 coding，这个判断必须用多模态证据。

### 2. Verifier 输出必须持久化

Loop 最大风险是错误跨轮累积。因此 verifier feedback 不能只是聊天里的建议，而应该写入 durable state：

- 当前失败是什么；
- evidence 是哪张 screenshot、哪个 DOM node、哪个 test log、哪个 API response；
- 失败影响哪个目标；
- 下一轮修复需要避免什么；
- 什么时候确认通过。

### 3. `/goal` 是最小概念原型，但还不够

Claude `/goal` 已经体现 maker/checker 分离，但它的 evaluator 只看 transcript，不独立观察环境。我们要研究的是更强版本：

```text
goal condition
  + rendered artifact evidence
  + browser/video/PDF/chart observation
  + structured verifier feedback
  + code revision loop
```

### 4. Loop benchmark 应该记录失败累积，而不只是最终分数

传统 benchmark 看最终 pass/fail；loop benchmark 要看：

- verifier 是否发现真实问题；
- 同一个问题是否反复出现；
- 错误是否进入 state 并污染下一轮；
- 人类检查点在哪里介入；
- token/time/budget 上限是否生效；
- 多模态证据是否减少 blind approval。

## 可靠性和 caveats

| Source | What it supports | Reliability |
| --- | --- | --- |
| Addy Osmani blog | Loop Engineering definition and component map; Codex / Claude capability comparison | high for Addy's view |
| Claude Code docs | `/goal`, `/loop`, subagents, worktrees as real Claude Code primitives | high |
| Anthropic harness design blog | Generator/evaluator separation and Playwright QA in long-running app build | high |
| 0xCodez X post | Community amplification of the 11-page PDF | medium |
| Google Drive PDF | 11-page "Loop-Engineering-IEEE.pdf" content and the "Anthropic Playbook" framing | medium-to-low; public PDF, not confirmed official Anthropic |
| PaperAgent WeChat | Chinese trend framing and local summary | low-to-medium; useful as signal, not primary evidence |

## 可转化为实验的问题

1. 在同一个 UI 修复任务上，`/goal`-style transcript evaluator 和 multimodal evaluator 的差异是什么？
2. Verifier feedback 写入 state 文件后，是否减少同类视觉/行为错误复发？
3. 一个 loop 中，`Schedule -> Discover -> Build -> Verify -> Repeat` 哪一步最容易导致错误累积？
4. 对已有系统继续开发，worktree 并行候选 + multimodal evaluator 选择是否优于单一路径迭代？
5. 人类只抽样阅读 verifier state，而不看全部代码，能否保持足够理解？什么样的 sample 最有代表性？
6. Budget cap、max turns、human checkpoint 对 loop safety 的贡献如何量化？

## 文章依据与短摘

> 公开页面只保留研究相关短摘和结构化说明，不全文复制公众号文章或 PDF。

可保留的短摘/术语：

- `Schedule -> Discover -> Build -> Verify -> Repeat`
- `Generator / Evaluator`
- `verification debt`
- `comprehension rot`
- `cognitive surrender`
- `token blowout`
- `Cap Before You Ship`
- `Keep One Door Open`

## Related Files

- Standalone page: `index.html`
- Local source extraction note: `source-capture.md`
- Board page: `../../../notes-blogs.html`