我是 Luhui Dev一个长期拆解 Agent 工程、探索 AI 教育落地的开发者。关注 Agent Harness、LLM 应用工程、AI for Math 与教育 SaaS 产品化实践。前言最近硅谷的 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 JudgeReflexion 和 Self-Refine长期记忆自动实验与爬山优化。甚至最简单的 Ralph Loop本质上就是不断重新调用 Coding Agentwhiletrue;doclaude读取任务和当前进度继续完成工作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 EngineeringAgent 可以执行哪些动作Harness Engineering一次 Agent 运行如何可靠发生Loopcraft多次运行如何被触发、验证、连接和持续改进所以 Loopcraft 并没有取代 Harness。恰恰相反没有稳定的 HarnessLoop 只是在自动、持续地制造错误。四、Loopcraft 不是一个循环而是多个循环的叠加LangChain 后来把 Loopcraft 拆成了四个比较容易落地的层级。我觉得这个拆法很实用。第一层Agent Loop最内层就是我们熟悉的 Agent模型思考 → 调用工具 → 读取工具结果 → 继续思考 → 直到认为任务完成例如一个文档 Agent 可以读取 Issue → 搜索仓库 → 修改 Markdown → 检查链接 → 创建 PR第二层Verification LoopAgent 说完成了不代表任务真的完成了。因此需要在 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 案例要理解 LoopcraftKarpathy 的 Autoresearch 是一个很好的实践样本。这个项目做的事情并不复杂Agent 提出一个训练改进 → 修改 train.py → 运行固定五分钟的训练 → 读取 val_bpb 指标 → 指标更好则保留 → 指标变差则回滚 → 开始下一次实验它能够在无人干预时每小时执行大约 12 次实验睡一觉可以完成接近 100 次实验。这里真正聪明的不是 Agent Prompt 写得多么复杂而是 Karpathy 把问题改造成了一个非常适合循环优化的环境Agent 只能修改一个文件评价指标固定每次实验时间固定结果可以自动比较失败可以回滚Git 记录完整实验历史验证代码不能被 Agent 修改。这就是 Loopcraft 的核心变化人从直接完成任务转向设计一个能够反复完成、验证和改进任务的系统。六、自己怎么搭一个最小 LoopAutoresearch 的环境比较特殊。普通开发者可以先从更简单的场景入手自动接收一个小型 Issue尝试修复通过测试后创建 PR失败则带着反馈重试。先别急着上多 Agent。一个最小 Loop 只需要六个部分Trigger什么事件启动任务例如 CI 失败、定时任务或带有特定标签的 Issue。Goal明确什么叫完成最好能转化为测试、lint、类型检查等机器可验证条件。State把尝试次数、失败原因和当前进度写进文件或数据库不要只依赖聊天上下文。Worker让 Coding Agent 在独立的 worktree 或容器中执行避免污染主分支和其他任务。Verifier优先使用测试、规则和静态检查只有难以形式化的部分才交给 LLM Reviewer。Budget限制尝试次数、运行时间和成本涉及高风险操作时及时交给人。整个流程可以简化成forattemptinrange(3):resultrun_agent(goal,load_state())verdictverify(result)save_state(result,verdict)ifverdictpassed:create_pull_request()breakifverdict!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 当前产生的结果也要开始修复那个不断产生结果的系统。
)
