前言
最近硅谷的 Agent 圈又冒出了一个新概念：Loopcraft。
第一次看到这个词，我想这不就是给 Agent 套一个 while true 吗？前几年叫 Agent Loop，后来叫 Workflow、Harness Engineering，现在又发明了一个 Loopcraft，硅谷 AI 圈总是在不断造词……
不过顺着最近 Peter Steinberger、Claude Code 负责人 Boris Cherny，以及 Andrej Karpathy 关于 Agent Loop 的讨论看下去，我发现这次的变化还是有点不一样的，所以来系统梳理一下。
Peter Steinberger 的说法是：
You shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents.
你不应该继续亲自 Prompt Coding Agent，而应该设计一个负责 Prompt Agent 的循环。
Boris Cherny 的说法是：
I don’t prompt Claude anymore. I write loops. The loops do the work.
我不再亲自 Prompt Claude。我负责写循环，循环负责干活。
Karpathy 在介绍 Autoresearch 时也表达了类似的观点：如果人还需要不断查看结果、判断下一步、再给 Agent 新指令，那么人本身就成了整个系统的吞吐量瓶颈。
这几句话放在一起，背后其实是一次抽象层上移：
以前：
人 → Prompt → Agent → 结果
现在：
人 → 设计 Loop
↓
任务发现 → Agent 执行 → 自动验证 → 失败重试 → 保存状态 → 继续运行
我目前对 Loopcraft 最简洁的理解是：Prompt Engineering 优化一次交互，Loopcraft 优化整个反复运行的系统。
它关注的不是这一个任务怎么做好，而是：
- 下一次任务由谁发起；
- Agent 如何知道自己该做什么；
- 输出由谁检查；
- 失败后如何获得反馈；
- 是否需要重试、换策略或者交给人；
- 状态如何跨越不同会话保存；
- 多次运行积累下来的经验，如何反过来改进系统。
这篇文章，我想具体拆三个问题：
- Loopcraft 到底是什么，为什么最近突然火了；
- 它与之前很火的 Agent Harness 有什么区别；
- 普通开发者现在能不能搭一个简单的 Loop 跑起来。
一、为什么大家突然不谈 Prompt，开始谈 Loop 了
过去两年，我们使用 Coding Agent 的典型方式，大致是这样的：
告诉 Agent 要做什么
→ 等它修改代码
→ 人检查结果
→ 告诉它哪里不对
→ Agent 继续修改
→ 人再次检查
模型已经在写代码、搜索文件和运行测试，但整个过程仍然由人一步一步驱动。
Agent 每完成一轮，就停下来等下一条指令。
从表面上看，这是人在使用 Agent；换一个角度看，其实也是人充当了 Agent 系统的调度器、状态机和验证器。
所以模型虽然很快，人却依然无法离开。各种 Agent 产品推出移动端异步监管功能，也是为了缓解这个问题。
这正是最近 “Loop discourse” 提出的问题：不要只让 Agent 自动执行其中一步，而是把任务发现、分配、验证和继续推进也设计成一个系统。
比如，以前修复一个 CI 问题可能是：
我看到 CI 失败 → 打开 Codex → 复制错误日志 → 让它分析 → 看修改结果 → 让它运行测试 → 检查通过 → 手动创建 PR
放进 Loop 之后可以变成：
CI 失败事件 → 自动读取错误日志 → 判断是否属于可自动处理的问题 → 在独立 worktree 中启动 Agent → 修改代码 → 运行测试和 lint → 第二个 Verifier 检查 diff → 通过后创建 PR → 无法处理时通知人
这里真正被自动化掉的，是修改代码周围的整个闭环。
因此 Loopcraft 不是某个新的模型能力，也不是某个特定框架。
它更像是一种 Agent 系统设计方法：将任务执行、结果验证、事件触发、状态保存和系统改进，组织成多个可以嵌套的循环。
二、Loopcraft 是新概念吗？
Loopcraft 作为名字，确实非常新。但它背后的技术元素并不新。
我们早就有：
- Agent 的 Reason-Act-Observe 循环；
- Workflow 和状态机；
- 自动测试和 CI/CD；
- 定时任务与事件驱动；
- 多 Agent 协作；
- LLM as a Judge；
- Reflexion 和 Self-Refine；
- 长期记忆；
- 自动实验与爬山优化。
甚至最简单的 Ralph Loop，本质上就是不断重新调用 Coding Agent：
while true; do
claude "读取任务和当前进度，继续完成工作"
done
三、Agent Harness 和 Loopcraft 到底有什么区别？
这是我觉得最容易混淆的地方。
过去一年，Agent Harness 已经是一个很热门的概念。
Anthropic 对 Harness 的定义很清楚：它是让模型能够作为 Agent 工作的系统，包括上下文处理、工具调用、权限、环境、状态管理和结果返回。
简单说，Harness 解决的是：这个 Agent 在什么样的环境里工作？
而 Loopcraft 解决的是另一个问题：这个 Agent 什么时候被启动，为什么继续运行，结果由谁检查，下一轮做什么？
用一组不完全严谨，但容易理解的比喻：
Model：工人的大脑
Tools：工人手中的工具
Harness：工人的工位和工作环境
Loop：工厂的生产节拍、质检和任务调度
Loopcraft：如何设计并叠加整套生产循环
当然，我在真实实践里发现两者边界并不能完全绝对。
一个成熟的长任务 Harness，本身就包含重试、验证和状态交接；一个 Loop 也必然依赖 Harness 提供工具和环境。
我更愿意把它们理解为关注点不同：
| 概念 | 主要关注的问题 |
|---|---|
| Prompt Engineering | 这一轮模型应该看到什么指令 |
| Context Engineering | 模型此刻应该看到哪些信息 |
| Tool Engineering | Agent 可以执行哪些动作 |
| Harness Engineering | 一次 Agent 运行如何可靠发生 |
| Loopcraft | 多次运行如何被触发、验证、连接和持续改进 |
所以 Loopcraft 并没有取代 Harness。
恰恰相反，没有稳定的 Harness，Loop 只是在自动、持续地制造错误。
四、Loopcraft 不是一个循环，而是多个循环的叠加
LangChain 后来把 Loopcraft 拆成了四个比较容易落地的层级。我觉得这个拆法很实用。
第一层：Agent Loop
最内层就是我们熟悉的 Agent：
模型思考
→ 调用工具
→ 读取工具结果
→ 继续思考
→ 直到认为任务完成
例如一个文档 Agent 可以：
读取 Issue → 搜索仓库 → 修改 Markdown → 检查链接 → 创建 PR
第二层：Verification Loop
Agent 说完成了，不代表任务真的完成了。因此，需要在 Agent 外面包一层验证：
Agent 执行
→ Verifier 检查
→ 不通过则返回具体反馈
→ Agent 再次执行
→ 直到通过或超过预算
Verifier 可以是单元测试、类型检查、lint、Schema 校验等等。
但这里有一个很重要的原则：尽量不要让做题的人，同时负责给自己判卷。
第三层：Event-driven Loop
有了执行和验证，接下来是不再由人手动启动。
任务可以由真实事件触发，此时 Agent 不再只是一个聊天工具，而是业务系统中的后台组件。
事件
→ 确定性规则判断是否需要处理
→ 启动 Agent
→ 验证结果
→ 更新真实系统
第四层：Hill-climbing Loop
前三层自动化的是工作。
第四层开始自动化如何把工作做得更好。
每次 Agent 运行都会留下 Trace：
- 收到了什么任务；
- 调用了哪些工具；
- 在哪里失败；
- Verifier 为什么拒绝；
- 消耗了多少 Token；
- 是否需要人工接管。
外层系统可以定期分析这些轨迹：
收集多次运行记录
→ 找出高频失败模式
→ 调整 Prompt、Tool、Skill 或 Verifier
→ 在 Eval 集上重新测试
→ 通过后更新 Harness
这一层才是我认为 Loopcraft 最有价值的部分。
因为普通的循环只是重复工作，而 Hill-climbing Loop 会改变产生结果的系统。
普通 Loop：
失败 → 再试一次
改进 Loop：
失败 → 分析为什么失败
→ 修改 Prompt、工具或验证规则
→ 让未来的运行更可靠
外层循环的返回箭头，不只是回到任务开头，而是伸进了 Agent 内部，开始改造内层循环。
这时候，系统才真正出现了复利。
五、Karpathy 的 Autoresearch，是目前最标准的 Loopcraft 案例
要理解 Loopcraft，Karpathy 的 Autoresearch 是一个很好的实践样本。
这个项目做的事情并不复杂：
Agent 提出一个训练改进
→ 修改 train.py
→ 运行固定五分钟的训练
→ 读取 val_bpb 指标
→ 指标更好则保留
→ 指标变差则回滚
→ 开始下一次实验
它能够在无人干预时，每小时执行大约 12 次实验，睡一觉可以完成接近 100 次实验。
这里真正聪明的不是 Agent Prompt 写得多么复杂，而是 Karpathy 把问题改造成了一个非常适合循环优化的环境：
- Agent 只能修改一个文件；
- 评价指标固定；
- 每次实验时间固定；
- 结果可以自动比较；
- 失败可以回滚；
- Git 记录完整实验历史；
- 验证代码不能被 Agent 修改。
这就是 Loopcraft 的核心变化：人从直接完成任务，转向设计一个能够反复完成、验证和改进任务的系统。
六、自己怎么搭一个最小 Loop？
Autoresearch 的环境比较特殊。普通开发者可以先从更简单的场景入手：
自动接收一个小型 Issue，尝试修复，通过测试后创建 PR，失败则带着反馈重试。
先别急着上多 Agent。一个最小 Loop 只需要六个部分：
- Trigger：什么事件启动任务，例如 CI 失败、定时任务或带有特定标签的 Issue。
- Goal：明确什么叫完成，最好能转化为测试、lint、类型检查等机器可验证条件。
- State：把尝试次数、失败原因和当前进度写进文件或数据库，不要只依赖聊天上下文。
- Worker：让 Coding Agent 在独立的 worktree 或容器中执行，避免污染主分支和其他任务。
- Verifier：优先使用测试、规则和静态检查，只有难以形式化的部分才交给 LLM Reviewer。
- Budget：限制尝试次数、运行时间和成本，涉及高风险操作时及时交给人。
整个流程可以简化成：
for attempt in range(3):
result = run_agent(goal, load_state())
verdict = verify(result)
save_state(result, verdict)
if verdict == "passed":
create_pull_request()
break
if verdict != "retryable":
notify_human()
break
具体使用 Claude Code、Codex、GitHub Actions，还是自己写 Bash 或 Python 都不重要。
真正需要设计清楚的是这条链路：
触发 → 执行 → 验证 → 反馈 → 重试或退出
只要任务有明确目标、可靠反馈、可恢复状态和停止条件，就已经具备了一个最小 Loop。
七、Loopcraft 最容易踩的几个坑
第一个坑：把无限重试当作自主性
不断运行不等于不断进步。
如果 Agent 缺少新的反馈，重复十次通常只是用十倍 Token 犯相似的错误。
第二个坑：让 Agent 修改自己的考试规则
执行 Agent 不应该随意修改测试、评价指标、时间预算、权限边界、Verifier Prompt。
否则它很可能不是把任务做得更好，而是把“通过”变得更容易。
第三个坑：一开始就上多 Agent
多个 Agent 不会自动产生智能，只会先产生更多 Token 消耗、文件冲突、重复工作、状态同步问题等。
先把一个 Worker、一个 Verifier、一个持久状态跑通，再考虑并行。
第四个坑：只衡量 Agent 有多忙
Agent 数量、运行时长、Token 消耗和工具调用次数，都不是最终价值。
真正应该关注的是：单位成本下，经验证的有效进展。
例如自动解决 Issue 的成功率、每个合格 PR 的平均成本、人工接管比例等。
第五个坑：Loop 越顺，人越容易放弃理解
这是我觉得最值得警惕的一点。
当 Agent 可以自动写代码、测试、修复并创建 PR，人很容易只看最终的绿色勾选。
但系统产出代码的速度越快，人对系统的理解可能下降得越快。
Loopcraft 不应该成为不再思考的借口，而这需要人对自身有更高的要求。
写在最后
我最近隐约感觉，Agent 工程正在经历一次抽象层迁移。
最早我们在讨论 Prompt，后来开始讨论 Context、Tool、Memory 和 Harness。
现在，大家开始将关注点继续向外移动，研究如何把一次 Agent 运行放进更大的任务、验证和改进循环中。
我对“完全把人移出循环”仍然保留怀疑。
但有一点我基本认同：
不要只修复 Agent 当前产生的结果，也要开始修复那个不断产生结果的系统。