收藏 | 拆解Loop Engineering：Agent如何跑完一件事（小白程序员进阶指南）

关注

原创最新推荐文章于 2026-08-09 13:08:51 发布 244 阅读 AI 写同款· GEO 优化 ›

ABB机器人绝对精度实战：从焊接路径优化到TCP控制（附配置步骤）本文深入探讨了ABB机器人绝对精度在焊接路径优化中的核心价值。通过对比重复定位精度，阐明绝对精度如何补偿机械误差，确保TCP在整个运动路径上的轨迹精度。文章提供了从示教器激活绝对精度功能的详细配置步骤，并分享了针对焊接抖动和实现0.2mm路径精度的进阶调优技巧，包括TCP标定、伺服参数优化与系统维护。阅读详情

Loop Engineering是AI coding圈的热门话题，本文探讨了如何让Agent完成复杂任务。作者通过实践Claude Code和Codex，总结了Loop Engineering的核心是让Agent知道何时继续、验证和停止。文章对比了Claude Code /goal和Codex /goal的差异，并提出了四种实现Loop的方式：Goal模式、Workflow模式、自定义Command/Hook和外部状态文件+多Agent。最后，作者给出了选型建议和常见踩坑点，建议从简单闭环开始逐步进阶。

我把 Loop Engineering 拆了一遍：Agent 到底怎么跑完一件事？

这一篇聊一下最近 AI coding 圈很火的一个词：Loop Engineering。

当 Agent 不只是回答问题，而是真的开始干活以后，怎么让它把一件事跑完？

这段时间我用 Claude Code 和 Codex 跑了不少自动化任务。

最爽的时候，是看着 Agent 自己改代码、跑测试、修 bug，一轮一轮往前推。

最崩溃的时候，是早上醒来发现它还在跑；或者它自信满满地说"完成了"，结果一看，关键问题根本没修。

所以我现在越来越觉得，很多人讨论 loop engineering，容易把重点放错：

Loop 不是让 Agent 一直干活，而是让它知道怎么继续、怎么验证、什么时候该停。

网上关于这个词的信息也挺散：有人把它当 prompt engineering 的下一站，有人把它讲成 agent workflow，有人直接拿 Claude Code /goal、Codex /goal、Dynamic Workflows 来对比。

这个词的来龙去脉，大概可以分成三步看。

第一步，是 prompt engineering。早期我们和 AI 协作，重点是把一句 prompt 写清楚：给背景、给格式、给例子、给约束。那时候 AI 更像一个强一点的问答工具，人负责一轮一轮地追问和纠偏。

第二步，是 agentic coding。 Claude Code、Codex、Cursor 这类工具起来之后，AI 不只是回答问题，而是开始读文件、改代码、跑命令、看报错。人的工作从"写代码"变成了"指挥一个会写代码的系统"。

第三步，才是 loop engineering。 2026 年 6 月，Addy Osmani 写了一篇《Loop Engineering》，把这个趋势讲得比较系统：loop 不只是一次 prompt，而是一个会发现任务、分配任务、验证结果、记录状态、决定下一步的小系统。Business Insider 后来也专门写了一篇文章，把它概括成从 prompt engineering 转向 loop engineering，并提到 Peter Steinberger、Boris Cherny 等人在讨论这个方向。

所以我更愿意把 Loop Engineering 理解成：Agent 时代的工作流设计。

它不是某个工具的新功能，也不是一个已经完全定型的学术概念，而是一套正在形成的实践：当 AI 可以连续执行任务以后，人类要设计的不再只是 prompt，而是目标、状态、验证和停止条件。

但真正落到实操，其实就三个问题：

目标怎么写？状态放哪里？谁来判断它真的完成了？

这一篇，我把 Loop Engineering 按实战拆开讲：先讲底层逻辑，再对比 Claude Code /goal 和 Codex /goal，最后给四种能落地的方案选型。

三句话速览

Loop 的核心：不是无限执行，而是观察、规划、执行、验证、停止这一整套闭环。

工具差异：Claude Code /goal 更像"验证优先"的裁判条件，Codex /goal 更像"长任务优先"的目标锚点。

落地选型：简单任务用 goal，周期任务用 workflow，团队规范用 command/hook，生产级任务用外部状态文件 + 多 agent。

一、Loop 到底是什么

从 prompt 到 loop，变化在哪

如果说 prompt engineering 解决的是"这一次怎么问"，那 loop engineering 解决的就是"一件事怎么被持续推进到完成"。

这两者的差别很大。

Prompt 是一次性的。你给一段上下文，模型给一次回答。回答好不好，主要看 prompt 写得清不清楚。

Loop 是过程性的。Agent 会经历多轮动作：观察当前状态、制定计划、执行修改、检查结果、根据反馈继续下一步。每一轮的输出，都会影响下一轮的输入。

所以，loop 工程真正关心的不是某一句 prompt，而是整个循环有没有收敛：

观察 → 规划 → 执行 → 验证 → 决定继续或停止

这里最容易被误解的一点是：loop 不是无限执行。

肯定有人会问：loop engineering 不就是让 agent 自动多跑几轮吗？

确实是，但只说对了一半。

真正的 loop 工程，不是"一直跑"，而是"跑到能证明自己对，或者证明自己需要停下来为止"。

最核心的环节是验证。

没有验证，前面的观察、规划、执行都没法收敛。Agent 很容易陷入两种极端：

一种是永远觉得自己没干完

你让它"优化代码"，它永远能再找点细节改。改命名、调注释、重构变量，循环到天亮。

一种是太早觉得自己干完了

测试明明没覆盖边界条件，它一看绿了就说任务完成，结果上线就炸。

Loop 的第一性原理，不是自动化，而是终止条件必须可验证、可量化、可判定。

验证条件怎么写

那什么样的终止条件才算好？我觉得至少分三层：

结果验证

比如测试全部通过、产物文件存在。风险是测试可能测错了东西。

行为验证

比如 API 返回正确、页面能打开。风险是没覆盖异常路径。

人工验证

关键改动必须人确认。风险是失去自动化的意义。

实际落地时，通常是三层叠加。完全无人值守目前还不现实，但我们可以尽量把前两层做扎实。

不过，写得出验证条件，不等于跑得起验证闭环。谁来在每一轮之后判断「到底达没达成」、没达成就自动再来一轮？这件事，现成工具已经帮我们做了一半。眼下最直接的两个入口，就是 Claude Code 和 Codex 的 /goal —— 但同样叫 /goal，这两个的思路并不一样。

二、Claude Code /goal VS Codex /goal

两个工具的使用体感不一样

Claude Code 和 Codex 都在往"目标驱动"这个方向走，但我不太建议把它们理解成同一种东西。

我的体感是：Claude Code /goal 更适合做明确条件下的验证闭环，Codex /goal 更适合给长任务挂一个持续目标，再慢慢推进。

这个差异不一定来自某个单一功能，而是两个工具整体工作方式不同：

Claude Code /goal 更像一个裁判条件

你给它一个目标，它会在每轮之后判断目标是否满足。它的重点是：这件事到底达没达成。

Codex /goal 更像一个任务锚点

你给它一个较长周期的目标，它会把这个目标挂在当前任务里。中间可以查看状态、继续推进，更适合需要持续跟进的工作。

Claude 更适合拿来做验证闭环

尤其是目标能一句话说清楚的时候，比如"所有测试通过且 lint 无报错"。

Codex 更适合拿来做长任务推进

比如批量补测试、迁移代码、持续跟一个 issue。它不一定天然更"正确"，但更适合把任务挂住，不容易因为一次上下文中断就散掉。

多 agent 不要简单按工具划线

Claude Code 和 Codex 都在往 subagent、MCP、skills、worktrees、automations 这些方向扩展。所以这里别简单说谁是单 agent、谁是多 agent，更重要的是看你有没有把角色、状态和验证拆开。

Claude Code /goal：验证优先

Claude Code 的 /goal 给我的感觉像是给 agent 装了一个"裁判"。

你设定一个条件，比如"直到所有测试通过且 lint 无报错"。每轮执行完后，会有一个小模型独立判断这个条件是否达成。如果没达成，自动进入下一轮；如果达成了，停下来给你结果。

它的优势：

验证和主模型分离，不是执行者自己说"我完成了"
会话状态连续，上下文不容易丢
适合高风险的改动，比如重构支付逻辑、修改用户权限

但也有坑：

验证条件必须写得够准，太松会"假通过"，太严会无限循环
Claude Code 支持恢复会话，但长任务最好仍然把状态写到外部文件里

Codex /goal：长任务优先

Codex 的 /goal 更像是一个"任务锚点"。

它的好处是，你可以把一个较长周期的目标挂住，中间查看进度、继续推进，不用每次重新解释"我到底要干嘛"。

它的优势：

适合长周期任务，比如批量补测试、迁移代码、跑数据清洗
目标挂住以后，对长任务更友好
可以和 skills、worktrees、automations 组合成更工程化的流程

缺点也很现实：

目标写得太虚，推进过程还是会散
验证不够严格时，容易留下集成层面的隐患
如果没有外部状态文件，长任务中途仍然容易丢细节

什么时候用哪个

我按场景给了一个简单粗暴的对照：

复杂重构、多文件改动 → Claude Code /goal

验证严格，上下文连续。

支付/权限等高风险代码 → Claude Code /goal

错不起，验证必须可靠。

DevOps 脚本、批量生成 → Codex /goal

适合挂住一个长目标，分多轮慢慢推进。

需要跑几小时/几天的任务 → Codex /goal

更适合挂住目标，分阶段推进。

CI/CD / 自动化集成 → Codex /goal / Automations

更适合和后台任务、仓库状态、自动化流程配合。

需要多 agent 协作 → 外部状态机 + subagent / MCP / worktree

重点不是选哪个工具，而是把规划、执行、验证拆成不同角色。

当然，现在也有不少团队两个一起用：Claude 做规划和最终验证，Codex 做中间执行。这种组合打法以后可能会越来越常见。

三、实现 Loop 的四种方式

上面对比的两个 /goal，本质是同一种打法：给一个条件，让它自动跑到满足为止。但 /goal 只是把 loop 落地的最轻一种方式——任务再大一点，光靠它就不够了。

下面四种，与其说是"四选一"，不如说是从轻到重的四层，按需往上叠：方式一管"什么时候停"，方式二管"什么时候再触发"，方式三管"怎么封装复用"，方式四管"状态放哪、谁干哪步"。它们解决的是不同的问题，可以同时存在——一个真实的生产级 loop，往往是四层一起上：Goal 判停 + Hook 自动验 + cron 定时调度 + 外部状态和多 agent 接力。

所以下面按"从轻到重"来看，你做到第几层，取决于任务有多大。

方式一：Goal 模式

这是四种里最轻量的一种：给一个终止条件，agent 自动跑到满足为止。它的现成实现就是第二节那两个 /goal——体感细节那边聊透了，这里只做张速记卡，方便和后面三种横向对比。

快速使用：

/goal 所有单元测试通过且覆盖率不低于 80%

适合场景：

修复某个具体 bug
跑 lint/test 直到全绿
改一个小功能，验证条件明确

优点：

门槛低，原生支持
自动推进，省人工

缺点：

验证条件必须写得准
复杂任务容易"假通过"

/goal 适合"条件能一句话说清楚"的任务。

方式二：Workflow 模式

Workflow 模式适合周期性、流程化的任务。同样是"定时再跑一轮"，按住在哪、谁来调度，分三档，越往下越无人值守：

会话内 loop（Claude Code /loop）：在当前会话里按间隔重跑，上下文还在；只在会话开着且空闲时触发，关掉就没了，且 7 天自动过期。适合"盯着一件事跑一阵"。 → /loop 1h 扫一遍新 issue 并分类；也能直接挂一条已存的命令：/loop 20m /review-pr 1234
外部调度（cron / GitHub Actions）：脱离会话、无人值守，但每次从干净状态起，得自己把上下文喂进去。适合"定时跑、跑完就走"。 → crontab 或 Actions 的 schedule: 里挂一条 claude -p "..."
Automations（产品级后台任务）：托管调度，自带触发与通知，最贴近生产。适合"长期挂着的后台流程"。 → 在平台上配一个 routine，定时触发 + 完成推送

适合场景：

每天扫描仓库 issue
每周自动生成周报
持续监控某个指标并告警

优点：

可编排复杂流程
支持定时触发
可以接入后台任务或外部调度器

缺点：

跨轮次容易"失忆"——每次定时触发都是新会话
需要外部状态管理（接方式四）

workflow 模式的关键是状态持久化，否则每次循环都从零开始。

方式三：自定义 Command / Hook

把跑通的 loop 流程固化下来，复用给自己和团队。这里其实是两个机制，解决的事不一样：

自定义 Command（手动触发）：把一段常用 prompt 存成斜杠命令，要用时自己调，复用的是"你反复在说的那段话"。网上写 “command loop” 最常见的套路，就是把"自评 → 行动 → 验证 → 没完就重来"这套循环、连同一个安全上限写进命令体，再用 $ARGUMENTS 接当次任务：

// .claude/commands/loop.md
你在 loop 模式下工作，目标是：$ARGUMENTS

循环执行：
1. 对照目标评估当前状态
2. 找出下一步该做什么
3. 执行
4. 验证结果
5. 达成 → 总结并停止；未达成 → 回到第 1 步
除非遇到必须人来拍板的卡点，否则不要在中途停下。
超过 20 轮仍未完成，就停下来汇报进度。

之后 /loop 盯着测试套件跑，把失败的修掉 就能复跑这套循环——任务换了，命令不用改。（.claude/commands/ 是经典写法，新版也可以写成 .claude/skills/<name>/SKILL.md。）

Hook（事件自动触发）：绑在事件上自动执行（Stop / PreToolUse / PostToolUse 等），由 harness 在对应时机调起，不用你记着喊，复用的是"该自动做的那道检查"。配置写进 .claude/settings.json：

// 每次 Edit/Write 改完文件，自动跑一遍 lint
{ "hooks": { "PostToolUse": [
  { "matcher": "Edit|Write",
    "hooks": [{ "type": "command", "command": "npm run lint" }] } ] } }

其实第二节的 Claude Code /goal 就是这种 hook 的现成例子——它本质是个 Stop hook：每轮结束后，由一个独立的小模型（默认 Haiku）判定条件达没达成，没达成就把理由带进下一轮。（Codex 的 /goal 是另一套机制——靠线程级持久化把目标存成"任务契约"，重点在跨中断不丢，并不走 Stop hook，详见第二节。）

再硬核一点，就是社区那套 Ralph Wiggum 技法：用一个 Stop hook 拦住"我做完了"、把同一个 prompt 再喂回去，循环到模型输出约定的完成标记（如 <promise>COMPLETE</promise>）或撞上 --max-iterations 上限为止。这套现在已经被官方 /loop（方式二）收编了，所以日常直接用 /loop 就行，自己写命令更多是为了把团队规范固化下来。

简单说：Command 复用"指令"，Hook 复用"时机"。

适合场景：

团队需要统一的 loop 规范
某些验证逻辑重复出现
想把最佳实践固化下来

优点：

高度定制化
可复用

缺点：

需要自己维护
新人理解成本高

自定义 command 是把个人经验变成团队规范的好办法，但前提是你已经跑通了流程。

方式四：外部状态文件 + 多 Agent

这一种听起来最复杂，其实核心很简单：不要把任务进度只放在聊天上下文里，而是写到一个外部地方。

比如一个大重构任务，不能只对 agent 说"你继续做"。更稳的做法是准备一个 Loop.md、GitHub issue、Linear ticket 或 state.json，专门记录这几件事：

当前目标：重构 user service，并保证所有测试通过
当前进度：接口已拆分，测试还差异常路径
下一步：补充权限失败场景的测试
验证条件：unit test + integration test 全部通过
约束：不动对外 API 签名，不碰数据库 schema
上限：最多 20 轮 / 预算烧完即停，没收敛就上报

后两行别省：跑无人值守的人基本都收敛到了同一套模板——目标、验证证据、不可违反的约束、外加一个轮数/预算硬顶。约束防它"帮倒忙"，硬顶防它原地打转烧 token（正对应后面坑 2、坑 3）。

状态放哪也有讲究：最稳的其实是直接押在 git 上——进度看 commit 历史，"谁在改哪块"用任务锁文件
落到工具上：角色用 subagent 来跑，会改同一批文件就让每个 subagent 各挂一个 worktree 隔离；它们之间不直接对话，全靠这个外部状态文件协调——开工前读它、干完回写进度。Claude Code 的 agent teams 就是把这套"共享任务清单 + 角色分工"做成了原生能力（目前实验性、默认关闭），没开它，你用一个 Loop.md 手动维护也完全成立。

快速使用：

- [x] 步骤1：拆分 user service
- [x] 步骤2：更新主流程测试
- [ ] 步骤3：补异常路径测试
- [ ] 步骤4：Verifier 确认测试和行为都通过

AGENTS/CLAUDE.md 更适合放长期规则、项目约定和验证规范，不太适合当每轮都会变化的状态表。动态状态最好放在 Loop.md、issue、Linear 或 state.json 里。

适合场景：

大型重构
多人或多 agent 接力
任务会跨会话、跨天推进
生产环境里需要审计和回滚

优点：

进度不会只藏在聊天里
换人或换 agent 也能接着做
规划、执行、验证可以分开，质量更稳

缺点：

比单次 prompt 麻烦
需要约定状态格式
状态文件没人维护，就会变成另一种噪音

Dynamic Workflows 放在哪

如果你的 Claude Code 环境支持 Dynamic Workflows，可以把它看成方式四的一种"编排加速器"。

它适合把复杂流程拆成多个阶段：先规划，再并行执行，再汇总，再验证。相比全靠 prompt 推进，它更像把编排逻辑写进脚本里。

但它解决的是"怎么编排多个步骤"，不是"状态应该怎么设计"。所以即使用了 Dynamic Workflows，重要任务还是建议把目标、进度、下一步和验证条件写到外部状态里。

方式四的重点不是多 agent，而是状态外置。状态清楚了，多 agent 才不会乱。

四、选型建议与踩坑

按场景选型

我把前面的内容汇总成一个决策清单——注意这里给的是"按最痛的点先补哪一层"，这些层通常是叠加的，不是互斥单选：

最怕做错 → Claude Code /goal + 独立验证
最怕中断 → Codex /goal / Automations
最怕重复劳动 → 自定义 command / hook / skill
最怕状态丢失 → 外部状态文件，比如 Loop.md、issue、state.json
最怕多人或多 agent 混乱 → 外部状态文件 + worktree + verifier

几个常见坑

说实话，这几个坑我都踩过。

坑 1：验证条件写得太松

比如只写"测试通过"，但测试本身没覆盖关键路径。agent 一看绿了就说完成，结果上线出问题。

坑 2：验证条件写得太严

比如要求"零 warning、零 lint 问题、覆盖率 100%"。agent 为了满足条件，开始做一些无意义的改动，token 烧光还没完。

坑 3：没有状态持久化

会话一断，前面几轮的努力全没。尤其是会话内循环和长时间 goal，一定要记得把中间状态写进文件。

坑 4：把"能跑"当"对"

agent 最喜欢说的就是"已经修复"。但代码能不能跑和代码对不对，是两件事。关键路径一定要人工或独立 verifier 再看一遍。

我的实践建议

如果你是第一次捣鼓 loop 工程，我建议这样渐进：

第一步：先用 goal 模式做几个简单任务，把验证条件写清楚。
第二步：遇到周期性任务，再加会话内 loop、cron 或 Automations。
第三步：有重复需求时，封装成自定义 command / hook / skill。
第四步：任务变大、角色变多，再考虑外部状态文件 + 多 agent。

一句话说清楚：从简单闭环开始，不要一上来就搞生产级架构。

总结

Loop 工程不是让 agent 无限执行，而是让它在正确的时机停下来。

Claude Code /goal 和 Codex /goal 的使用体感不一样：前者更适合明确条件下的验证闭环，后者更适合长任务里的持续目标。选择哪个，取决于你的任务更怕"错"、更怕"断"，还是更怕"状态丢"。

实现 loop 的方式也不止一种：

简单任务用 goal 模式
周期性任务用 workflow 模式
团队规范用自定义 command/hook
生产级任务用外部状态文件 + 多 agent

工具只是手段，验证条件才是 loop 工程的胜负手。

最后

如果说程序员已经是高薪职业，那么干AI的程序员，就是高薪中的高薪。

现在的市场，已经用数据给程序员指明了方向：学AI大模型，就是冲刺高薪的最优解！

看着身边越来越多的同行转型大模型、拿到高薪offer，很多人心里都动了心，但真正的难题来了：零基础小白不知道从哪入门？有基础的程序员找不到系统学习路径？实战项目练手无门？面试不知道考什么？

别慌！今天就给大家整理了一份【2026年最新版】AI大模型免费学习资源包，覆盖从入门到实战、从理论到面试、从基础到进阶的全流程，所有资料均已整理归档，无冗余、无套路，免费分享给每一位想抓住AI风口的程序员和小白！

👇👇扫码免费领取全部内容👇👇

在这里插入图片描述

1、大模型系统化学习路线

在这里插入图片描述

2、大模型学习书籍&文档

在这里插入图片描述

3、AI大模型最新行业报告

在这里插入图片描述

4、大模型项目实战&配套源码

5、大模型大厂面试真题

四阶段精细化学习规划（附时间节点，可直接照做）

结合上述资源，给大家整理了一份可直接落地的四阶段学习规划，总时长约2个月，小白可循序渐进，程序员可根据自身基础调整节奏，高效掌握大模型核心能力，快速实现从“入门”到“能落地、能面试”的跨越。

第一阶段（10天）：初阶应用

该阶段让大家对大模型 AI有一个最前沿的认识，对大模型 AI 的理解超过 95% 的人，可以在相关讨论时发表高级、不跟风、又接地气的见解，别人只会和 AI 聊天，而你能调教 AI，并能用代码将大模型和业务衔接。

大模型 AI 能干什么？
大模型是怎样获得「智能」的？
用好 AI 的核心心法
大模型应用业务架构
大模型应用技术架构
代码示例：向 GPT-3.5 灌入新知识
提示工程的意义和核心思想
Prompt 典型构成
指令调优方法论
思维链和思维树
Prompt 攻击和防范
…

第二阶段（30天）：高阶应用

该阶段我们正式进入大模型 AI 进阶实战学习，学会构造私有知识库，扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架，抓住最新的技术进展，适合 Python 和 JavaScript 程序员。

为什么要做 RAG
搭建一个简单的 ChatPDF
检索的基础概念
什么是向量表示（Embeddings）
向量数据库与向量检索
基于向量检索的 RAG
搭建 RAG 系统的扩展知识
混合检索与 RAG-Fusion 简介
向量模型本地部署
…

第三阶段（30天）：模型训练

恭喜你，如果学到这里，你基本可以找到一份大模型 AI相关的工作，自己也能训练 GPT 了！通过微调，训练自己的垂直大模型，能独立训练开源多模态大模型，掌握更多技术方案。

到此为止，大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗？

为什么要做 RAG
什么是模型
什么是模型训练
求解器 & 损失函数简介
小实验2：手写一个简单的神经网络并训练它
什么是训练/预训练/微调/轻量化微调
Transformer结构简介
轻量化微调
实验数据集的构建
…

第四阶段（20天）：商业闭环

对全球大模型从性能、吞吐量、成本等方面有一定的认知，可以在云端和本地等多种环境下部署大模型，找到适合自己的项目/创业方向，做一名被 AI 武装的产品经理。

硬件选型
带你了解全球大模型
使用国产大模型服务
搭建 OpenAI 代理
热身：基于阿里云 PAI 部署 Stable Diffusion
在本地计算机运行大模型
大模型的私有化部署
基于 vLLM 部署大模型
案例：如何优雅地在阿里云私有部署开源大模型
部署一套开源 LLM 项目
内容安全
互联网信息服务算法备案
…

👇👇扫码免费领取全部内容👇👇

在这里插入图片描述

6、这些资料真的有用吗？

这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理，现任上海殷泊信息科技CEO，其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证，服务航天科工、国家电网等1000+企业，以第一作者在IEEE Transactions发表论文50+篇，获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。

资料内容涵盖了从入门到进阶的各类视频教程和实战项目，无论你是小白还是有些技术基础的技术人员，这份资料都绝对能帮助你提升薪资待遇，转行大模型岗位。
在这里插入图片描述