过去两年，很多人学习 AI 编程的入口是「提示词工程」。你写一个更清楚的 prompt，给模型更多上下文，期待它一次性返回更好的结果。
但 Coding Agent 时代真正改变软件研发的，不是某一次回答更聪明，而是一个目标可以被持续发现、拆分、执行、验证、修复、记录，并在下一轮继续推进。
这就是 Loop Engineering。
Prompt Engineering 关心的是：一次调用的质量。
Loop Engineering 关心的是：持续反馈闭环的质量。
1. 从提示词到循环：杠杆点变了
Addy Osmani 在《Loop Engineering》里引用了两个很关键的判断：你不应该再只是在提示 coding agent，而应该设计提示 agent 的循环。Anthropic Claude Code 负责人 Boris Cherny 也说，他现在的工作不是不断 prompt Claude，而是写 loops，让 loop 去 prompt Claude 并判断下一步做什么。
这句话的重点不是「人不重要了」，而是人的位置变了。
以前你像驾驶员，一次次握着方向盘：写 prompt、看回复、补上下文、再写 prompt。Agent 是工具，你每一步都要亲自拿着它。
现在你更像系统设计者：你设计一个小系统，让它自己发现工作、派发工作、检查结果、写下状态，并决定下一步。
这不是把工程师从系统里删掉，而是把工程师的判断前移：从逐行指挥，变成设计闭环、设置验证门、定义停止条件。
2. 一个 Loop 至少需要五个部件
Addy 把 loop 拆成五个基础部件，再加一个外部记忆层。这个拆解很适合作为理解 Coding Agent 工程栈的起点。
Automations：心跳
自动化让 loop 不只是一次运行，而是会周期性醒来。它可以每天扫描 issue、总结 CI 失败、读取最近 commit、发现潜在 bug、生成 triage 列表。没有自动化，loop 只是一次更长的 prompt；有了自动化，loop 才有了心跳。
Worktrees：并行隔离
当多个 agent 同时改一个 repo，最大的问题不是智能不够，而是文件互相污染。Git worktree 让每个 agent 在独立分支和目录里工作，避免两个 agent 同时改同一份 checkout。
并行能力不是「多开几个窗口」那么简单。没有隔离，并行会变成混乱；有了 worktree，并行才开始像工程。
Skills：工程记忆
Skill 是把项目知识写到外部：约定、构建命令、历史踩坑、代码风格、不要做什么。没有 skill，agent 每一轮都像刚入职；有 skill，loop 才能复利。
这也是 WeHub 很重视 skills 的原因：它不是提示词收藏夹，而是 agent society 的工程记忆单位。
Plugins / MCP Connectors：外部神经系统
如果 agent 只能看聊天上下文和本地文件，它的 loop 很小。MCP 和 connectors 让 agent 接入 issue、数据库、浏览器、日志、CI、Slack、Linear、GitHub。
于是 agent 不只是说「你可以这样修」，而是可以查 issue、跑测试、开 PR、更新 ticket、通知团队。
MCP 的价值不是「又一个协议」，而是让 agent 从聊天窗口进入真实工作环境。
Sub-agents：分工与制衡
Loop 里最危险的结构，是写代码的 agent 自己宣布「我完成了」。生成者天然会宽容自己的结果。
所以 sub-agent 的核心价值不是热闹，而是分工和制衡：一个 agent 做规划，一个实现，一个审查，一个测试，一个补研究，一个写文档。尤其要把 maker 和 checker 分开。
一个健康的 loop，不是一个强 agent 从头干到尾，而是一组小闭环互相校验。
3. 外部状态：Agent 会忘，Repo 不会忘
长期运行的 agent 必须依赖外部状态。它可以是 markdown 文件、Linear board、issue、数据库、项目日志，形式不重要，关键是它不属于单次对话上下文。
模型会忘，repo 不会忘。
所以 Loop Engineering 的核心技巧之一，是把易失的智能体接到不易失的工程系统上：让状态在文件、issue、测试、PR、日志、skill 中沉淀，而不是只留在一次 conversation 里。
这也是为什么「记忆」不能只理解成聊天记录。真正的工程记忆，应该能被下一轮 agent 读取、验证、修改，并驱动下一步行动。
4. Coding Agent 的核心不是自动写代码
很多人把 Coding Agent 理解成「自动写代码」。这是低估了它。
真正的变化是，软件研发过程本身正在被 loop 化：
需求 → 计划 → 实现 → 测试 → Review → 修复 → 文档 → 状态更新 → 下一轮触发。
传统 Copilot 是局部补全；Coding Agent loop 是持续推进一个目标。
AI 开发效率的下一轮竞争，不在单次生成质量，而在 feedback cycle 的压缩：从「人发现问题」变成「系统持续发现问题」；从「人手动组织上下文」变成「loop 自动带着上下文回来」。
5. MSP 视角：Loop 还缺一个 Seed Layer
Addy 的文章主要讲工程 loop 的基础设施。WeHub/MSP 可以在上面补一层更重要的判断：loop 不应该只围绕 task 转，而应该围绕 seed problem 转。
普通 loop 问：下一步任务是什么？
MSP loop 先问：当前真正活着的问题是什么？这个问题有没有被错误地任务化？
没有 seed layer 的 loop，会高效执行错误问题；有 seed layer 的 loop，才可能持续吸收 human feedback，把模糊意图 grow 成真实 artifact。
这就是 MSP 和 Loop Engineering 可以接上的地方：
- Loop Engineering 让 agent 持续行动；
- MSP 让这种持续行动不偏离真正的问题；
- Seed 是 loop 的方向锚点，不是任务清单；
- Build 是 seed 在当前环境里的最小真实生长，不是无脑执行计划。
6. 风险：Loop 会放大能力，也会放大错误
Loop Engineering 听起来很强，但它不是自动生产力机器。它会放大能力，也会放大错误。
没有测试，loop 会持续生成不可验证代码。
没有 review，loop 会把 hallucination 固化进 repo。
没有权限边界，loop 会把小错误变成系统性事故。
没有工程师理解，团队会产生 comprehension debt：代码跑得越来越快，人越来越不懂自己系统里发生了什么。
没有 seed discipline，loop 会把错误方向做得越来越完整。
所以 Addy 的结尾很重要：Build the loop. Stay the engineer.
设计 loop 不是为了逃避思考，而是为了把人的思考放到更高杠杆的位置。你仍然要理解系统、审查结果、设置边界、承担质量责任。
7. 我的判断：软件研发会从 Task Management 走向 Loop Management
Prompt Engineering 会变成基础能力，但不再是核心壁垒。
Agent harness、loop、MCP、skills、external memory 会成为 AI-native 工程栈的基础层。
小团队会先受益，因为 loop 可以补齐大量中间工程角色：triage、review、测试、文档、同步、状态维护。
大团队会更难，因为权限、审计、责任边界、legacy system 和组织惯性会让 loop 设计变复杂。
真正强的工程师，会从「写代码快」变成「设计反馈系统强」。
软件研发会从 task management 走向 loop management：不是只管理谁做什么，而是管理目标如何被发现、验证、推进、记忆和纠偏。
而 MSP 要解决的是更上层的问题：当 loop 越来越强时，我们如何确保它围绕真正的问题生长，而不是围绕错误任务狂奔。
这可能是 Coding Agent 时代最重要的软件研发新范式。
Build the loop. But seed it first.