你的 AI 还在等你提问？别等了，让它自己转起来
上周在飞书上跟 Hermes 说：“帮我看看今天有什么新闻值得写。“它自动搜了一圈，整理出三个选题，存到文件里，然后安静地等着。第二天同一时间，它又跑了一遍。
我没写任何 prompt。这些动作是几周前设好的定时任务，到点就执行。选题池自动出现，新闻摘要自动推送。我唯一要做的事，就是早上打开飞书扫一眼。
当时没多想，觉得这就是个 cron job 罢了。
直到最近看到 Loop Engineering 这个概念，我才意识到——这几行 cron 配置背后，藏着一整套正在成形的方法论。
一句话讲清楚
Loop Engineering，就是让你从"写 prompt 的人"变成"设计 prompt 系统的人”。
你不再每次打开对话框手动输入指令。你设计一套规则，让 AI 自己循环运转：发现任务、执行、检查结果、记录状态、然后开启下一轮。
提出这个概念的人来头不小。Boris Cherny，Anthropic Claude Code 的负责人，原话是这么说的：
“I don’t prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops.”
不再 prompt Claude 了。我的工作是写 loop。
Google 工程总监 Addy Osmani 在6月7日的博客里正式给这个概念命名，定义是：“用一套自动运行的系统，取代你自己作为 prompt Agent 的那个人。”
说得直白一点：你以前是站在流水线旁边亲手拧螺丝的工人，现在你是设计整条流水线的人。螺丝还是那些螺丝，但你不用亲手拧了。
四个阶段，你到哪了
AI 工程的演进分四个阶段，每个阶段你干的事不一样：
第一阶段：Prompt Engineering。 你打开 ChatGPT，输入"帮我写一段 Python 代码”，然后复制粘贴。你的角色是提问者。
第二阶段：Context Engineering。 你发现光给指令不够，还得给背景。于是你整理好文档、代码、规范，一起喂给 AI。你的角色变成了信息组织者。RAG 就是这个阶段的产物。
第三阶段：Harness Engineering。 你不满足于一问一答了，你把 AI 和工具连起来——让 AI 能读文件、跑命令、调 API。这就是 Agent。你的角色升级为系统设计者。
第四阶段：Loop Engineering。 Agent 能做事了，但每次还得你手动触发。你开始设计让它自动运行的规则——什么时候启动、做什么、做完了怎么验证、失败了怎么办。你的角色是规则制定者。
回头看看，大多数人还卡在第一阶段和第二阶段之间。偶尔用用 RAG 的人算进了第二阶段，搭了 Agent 工作流的算到了第三阶段。但真正到达第四阶段的人不多——不是因为它有多难，而是很多人压根没想到这个方向。
四个阶段的分界线不一定那么清晰，很多人的使用习惯是混合的。但如果你的日常还停留在第一阶段——打开对话框、手动输入、等回复——那可能值得看看后面的世界。
一个 Loop 长什么样
抽象概念讲多了容易飘，拿一个真实的例子来说。
我每天有一组定时任务：晚上10点自动扫描我关注的博客有没有新文章，有就整理成推送发到飞书；晚上11点从扫描结果里筛选适合写公众号的选题，存到文件里。凌晨还有一个任务会检查 Syncthing 同步状态，如果异常会告警。
这套东西跑了几个月了，期间我几乎没有手动干预过。它每天自己转，该搜的搜，该推的推，该存档的存档。
这就是一个 Loop。拆开来看，它包含五个基本零件：
调度（Scheduling）。 用 cron 表达式定义什么时候启动。没有调度，Agent 就是一次性工具，不是持续运行的系统。
技能文件（Skills）。 一份 SKILL.md 文件，写清楚这个任务该怎么做、有什么约定、什么不能碰。Agent 每次启动都自动加载，不用每次重新教。
隔离环境（Worktree）。 如果多个 Agent 同时改同一个项目的代码，会冲突。给每个 Agent 一个独立工作目录，各自干活，互不干扰。
外部连接（Connectors）。 Agent 不可能什么都有，需要通过 MCP 协议接入外部工具——数据库、API、飞书、GitHub。没有连接器的 Agent 是个孤岛。
子代理分离（Maker/Checker）。 写代码的 Agent 不能评判自己的代码。一个 Agent 执行任务，另一个 Agent（用不同的 prompt，有时用更强的模型）负责审查。这是你敢让 Loop 无人值守运行的唯一保障。
再加一个隐含的第六件东西：状态文件（STATE.md）。 上一轮跑到了哪里，哪些做完了，哪些失败了在等人工干预——这些信息必须持久化保存，不然下一轮 Agent 从零开始，就是白忙活。
有个坑叫"意图负债"
每个用过 Agent 的人都有过这种体验：你给了 Agent 一个任务，它开始干了，但做出来的东西和你想的不一样。不是 Agent 笨，是你没说清楚。
问题在于，每次新对话，Agent 都是从零开始的。你没写在文件里的规范、偏好、禁忌，它会自己猜——而且猜得很自信。
这就叫"意图负债"。你欠 Agent 的上下文越多，它帮你干活的质量就越低。
Skills 解决的就是这个问题。你把项目规范、构建步骤、代码风格、历史踩坑记录写成文件，Agent 每次启动自动加载。写一次，管永远。
还有一个叫"理解负债"。Loop 产代码的速度比你阅读代码的速度快得多。跑了几周之后，你自己的代码库里大量代码是你没看过的。如果不定期审阅 Loop 的产出，你的理解负债只会越滚越大。
这听起来有点讽刺——你设计 Loop 是为了省事，结果省下来的时间又被审阅 Loop 的产出吃掉了。不过话说回来，至少你省事的那部分是真的省了。
Prompt Engineering 死了吗
没有。
Loop 由多个 Prompt 组成。调度触发 Agent、Agent 执行任务、子代理审查结果——每一个环节背后都是 Prompt。Prompt 写得烂，放进 Loop 里只会更快地产出烂结果。
Loop Engineering 是在 Prompt Engineering 之上的一个层次，不是替代品。
打个比方。Prompt Engineering 是写好每一行代码，Loop Engineering 是设计整个 CI/CD 流水线。行代码写不好的程序员，流水线设计得再漂亮也白搭。反过来，只会写代码不会搭流水线的程序员，做得再好也只停留在手工阶段。
两个都得会。
写在最后
我看了一圈 Loop Engineering 的讨论，最大的感触是：这个概念的描述框架终于把很多人（包括我）已经在做的事情给说清楚了。
Hermes 的 cronjob 就是调度，SKILL.md 就是技能文件，delegate_task 就是子代理分离，MCP 就是外部连接。这些东西我用了大半年，一直觉得是"AI 助手的高级功能"，现在才知道在概念上它有一个正式的名字，而且有一套完整的理论框架在支撑。
其实回头看，很多技术概念的流行走的是同一个路径——大家各自摸索了很久，突然有人站出来给了一个名字、画了一张图，所有人都觉得"这不就是我一直在做的吗？"
ChatGPT 刚出来的时候也是这样。大家都在用，但没有人把它拆分成 prompt、context、harness、loop 这几个层次。概念的价值不在于发明了什么新东西，而在于让人看清了已有的实践。
说到这，我想起《三国志》里诸葛亮的一句话：“善战者，求之于势，不责于人。“Loop Engineering 就是在"造势”——你设计好系统，让它自己去运转，而不是每次都亲自上阵。格局不同，产出自然不同。
你不需要追赶每一个新概念。但如果你的日常还在手动一问一答地使用 AI，也许值得停下来想想：你每天重复做的事里，有哪些可以让 AI 自己跑起来？
不复杂。一个定时任务加一份技能文件，就是最小的 Loop。