Loop Engineering：从 prompt agent 到设计 coding loop
这篇是对 PaperAgent 文章的整理，但会结合 Addy Osmani 的原文、Claude Code 的 /goal、/loop、subagents、worktrees，以及 0xCodez/PDF 的传播源做核对。
先放观点和启发
Loop Engineering 给我们的最好表达是：不要只研究 agent 能不能生成代码，而要研究那个让 agent 发现、生成、验证、记忆、再继续的系统。Multimodal verification 正是这个系统里的 judgment layer。
和我们相关的部分
- 任务对象从 prompt 变成 loop。 文章把 coding agent 的关注点从单次提示推进到
Schedule -> Discover -> Build -> Verify -> Repeat的持续系统。 - Verifier / evaluator 是 loop 的核心。 Addy、Claude
/goal和 Anthropic harness 都指向 maker/checker 分离；不能让生成者自己批准自己。 - Loop 错误会跨轮累积。 错误一旦进入 state，就可能被下一轮读回并继续放大；所以 verifier 反馈必须结构化、可观察、可持久化。
一手来源核对
定义 Loop Engineering：替代自己作为 prompt agent 的人，设计那个 prompt agent 的系统；将 loop 放在 harness 之上一层。
设定 completion condition，Claude 持续工作；每 turn 后小模型评估是否达成。这是 maker/checker 分离的最小产品形态。
按固定或动态间隔重复运行 prompt，适合部署、CI、PR 等轮询型任务，是 schedule layer。
专门化 agent 拥有独立 context、tools、model、permissions，可承担 explore、implement、review、verify 等角色。
为并行 session 隔离文件修改，使多个候选修复或多个 worker 不互相踩踏。
Markdown、issue board 或 Linear 这类外部状态是 loop 的脊柱；没有持久状态，就只是重复跑同一个 prompt。
和前两篇 blog 的关系
Anthropic Harness Design
Harness Design 讲如何组织一次长程 app build：planner / generator / evaluator、sprint contract、Playwright QA。Loop Engineering 则把它提升为会定时醒来、发现工作、派生 agent、验证并记录的持续系统。
Kimi 行为输入文章
Kimi 那篇强调输入从文本需求变成产品行为；Loop Engineering 强调执行从单次生成变成持续闭环。合在一起就是我们要研究的形态：从已有 artifact / behavior 出发，通过多模态 verification 让 agent 在既有系统里持续修正。
对我们项目的实验启发
- 比较 transcript-only evaluator 和 multimodal evaluator 在同一 UI/行为修复任务上的差异。
- 让 verifier feedback 写入 durable state，观察是否减少同类错误复发。
- 用 worktree 并行生成多个候选修复，再由 multimodal evaluator 选择或合并。
- 记录 loop 的 token/time/budget cap、iteration count、human checkpoint 和 verifier finding recurrence。
来源与边界
微信文章可访问并已抽取 metadata；正文不全文搬运。详细抓取记录见 source-capture.md。结构化笔记见 README.md。