夜雨聆风如果你最近刷 X 或者各种技术社区，大概率被同一个词洗了版。
Loop Engineering。
事情的导火索来自三个重量级人物，一周之内不约而同地说了一件事——
先是 Anthropic 的 Claude Code 负责人 Boris Cherny，在开发者大会上抛了一句话：
"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，让 loop 去 prompt Claude。
接着 OpenClaw 创始人 Peter Steinberger 在 X 上接力，更短，更绝：
"You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents."
别再搞 coding agent 了。去设计能 prompt agent 的循环。
然后 Google 工程总监 Addy Osmani 出手，一篇长文把这个概念做了系统性梳理，正式命名。
到这里，第四个 Engineering 的词尘埃落定。
但它不是凭空蹦出来的。Loop Engineering 是过去三年 AI 工程范式四次跃迁的最后一站。 你不会真以为 Loop 前面那三层都跳过去了吧？
把这四次进化串起来看，你才能理解三件事：每一层解决了什么问题、为什么不能跳级、以及下一步该往哪走。
第一层：Prompt Engineering（2022–2024）
核心问题：怎么跟模型说话，才能拿高质量输出？
这是大多数人接触大模型的第一课。
GPT-3 时代，人们发现同一道题，换一种问法，答案天差地别。问「写个排序」，它丢给你一坨能跑但没法看的代码。问「用 Python 写归并排序，带类型注解、docstring 和三个测试用例」，质量直接碾压。
于是诞生了一整套方法论：Zero-shot / Few-shot、Chain-of-Thought 思维链、角色设定、格式约束……每隔几天就有新的 prompt 技巧被发现和分享。2023 年，Prompt Engineer 甚至一度成为科技圈最热门的新职业。
但这些技巧有一个共同的边界：它们只管一次交互。
模型不记得上次对话，不知道你的代码库长什么样，不知道团队用哪种命名规范。每次开新对话，你都要从头教一遍。Prompt 写得再好，也是一次性的便利贴。
第二层：Context Engineering（2024–2025）
核心问题：不只怎么问——给模型看什么？
2024 年，上下文窗口突飞猛进。Claude 做到 200K，Gemini 冲上 1M+。窗口大了，新问题也来了：模型注意力在过长上下文中会稀释，token 成本直线飙升。
于是重心从「怎么写 prompt」转向「怎么管上下文」。
RAG（检索增强生成）从外部知识库拉取相关内容；上下文压缩把长对话提炼为结构化摘要；渐进式披露（Progressive Disclosure）做到需要什么才加载什么。记忆系统开始出现，让 Agent 在多次会话之间不再「失忆」。
Prompt 决定你怎么发出任务，Context 决定模型在关键时刻能看到什么。两层叠加，杠杆点向外移动了一格。
第三层：Harness Engineering（2025–2026）
核心问题：模型很强，怎么让它持续做对事？
2026 年初，OpenAI 抛出一个词，引爆了整个圈子：Harness Engineering。
他们内部一个 3 到 7 人的小组，用 Codex 在五个月内生成了近 100 万行生产级代码，全程没有工程师手写过一行业务逻辑。但他们最想讲的结论不是「模型好强」，而是——
「进展一直很慢，直到不再只盯着模型，开始建造工具。」
Harness 在英文里是马具——缰绳、胸带、鞍具。这个比喻很精准：AI 模型是马，力量巨大但不知道往哪跑；Harness 就是驾驭这股力量的约束和基础设施。
一个可用的 Harness 包含：
• 工具调用与权限边界：Agent 能调 API、删文件吗？分多层权限检查 • 多 Agent 编排：Coordinator 调度、Swarm 协作、Fork 并行探索 • 上下文压缩流水线：从低成本截断到 LLM 摘要，五级分层释放 token • 评估与反馈闭环：自动校验 → 人审 → 修正
如果说 Prompt 管「怎么说」、Context 管「看什么」——Harness 管的是「在什么体系里跑」。
第四层：Loop Engineering（2026 年 6 月，刚刚开始）
核心问题：我不再去 prompt agent 了——我去设计一个自动 prompt agent 的系统。
回到文章开头的那一幕。Peter 和 Boris 不是在否定前三次 Engineering 的价值——他们是在说，杠杆点已经再次上移了。
过去两年，你从一个 coding agent 拿到价值的方式很简单：写一条好 prompt，给足上下文，读返回结果，再敲下一句。你全程握着这个工具，一轮接一轮。你，就是回路里的那个调度器。
Loop Engineering 把它反转了：把那个不停敲下一行 prompt 的你，换成一套不停自动 prompt agent 的系统。而你，负责设计这套系统。
Loop 的六块拼图
| Automations（自动化） | |
| Worktrees（工作树） | |
| Skills（技能） | |
| Plugins / Connectors | |
| Sub-agents（子 agent） | |
| Memory（记忆） |
一个完整的 loop 长什么样
每天早上 9:00 Automation 触发 → 调分诊 Skill，读 CI 失败 + 未关闭 issue → 发现写入 TODO.md → 对每个值得做的项： → 开隔离 worktree → 子 agent-A 起草修复 → 子 agent-B（不同模型）对照规范 review → 开 PR，更新工单，频道里 @ 一声 → 处理不了的，落进 Triage 收件箱，等你来看你做了一件事：设计了这个系统一次。没有手动 prompt 其中任何一步。 这就是 Loop Engineering。
四层关系：谁都没有退场
把它放进时间线里看最清楚——
| Loop Engineering | 让马自己跑一整天 |
Loop 不会让 Prompt 过时——loop 里每个 turn 还是一条 prompt，一个糟糕的 prompt 在 loop 里只会更快地产出糟糕的工作。Context 不会退场——每个 turn 仍要加载正确的文档和工具。Harness 是 Loop 的底座——Loop 让 Harness 跑在定时器上、自我喂料、派生子 agent。
四层叠加，层层包裹，谁都没走。
但有一句话必须说在前头
Loop Engineering 的提出者也坦诚说出了三个风险：
1. 验证仍然落在你头上。 无人值守跑的 loop，也是无人值守犯错的 loop。你读过的、确认能跑的代码，才是你能发布的代码。
2. 理解债增长得更快。 Loop 越快地发布你没读过的代码，仓库里实际存在的东西和你真正理解的东西之间的鸿沟就越大。
3. 认知投降是最舒适的失败。 当 loop 自己跑起来，照单全收它的一切，诱惑极大。两个工程师搭出完全一样的 loop——一个用它在自己深刻理解的工作上跑得更快，另一个用它来逃避理解工作。Loop 分不清这两者，你分得清。
搭 loop，但继续做那个工程师。
四年，四次范式跃迁。从写 prompt，到管 context，到建 harness，再到设计 loop——每一次都是杠杆点的上移，每一次也都是工程师价值的重新定义。
不是「AI 取代了人的工作」，而是高价值的工作本身在变。
你现在的日常工作中，处在哪一层？是还在精心打磨每一条 prompt，还是已经开始让 loop 替你跑了？欢迎在留言区聊聊你的实践和踩过的坑。