Loop Engineering 是什么？AI 编程从 Prompt 到 Loop 的范式转变
最近 AI 圈又冒新词了。前年学 Prompt Engineering，去年追 Context Engineering，今年三月刚搞明白 Harness Engineering，六月又来了个 Loop Engineering。
说实话，我第一反应也是翻白眼——换个前缀就造一个赛道？但把来龙去脉扒了一圈之后，收回了白眼。这次不一样。
点火的是 Peter Steinberger（OpenClaw 作者），他在 X 上发了条帖子，拿了 650 万浏览：「别再给 coding agent 写 prompt 了，你该去设计那个替你 prompt 的 loop。」紧接着 Google 的 Addy Osmani 写长文给这个概念定了名，Claude Code 创始人 Boris Cherny 也说：「我已经不 prompt 了，是 loop 在运行着一切。」三个人同一周说了同一件事，这种共振值得认真看一看。
01 四个 Engineering，到底在 Engineering 什么？
先还账。Prompt、Context、Harness、Loop，四个词很多人到现在也只是"听过"。为什么一个接一个冒出来？因为上一个瓶颈解决了，新的瓶颈就暴露了。
2023 年，模型只会一问一答，你问得好不好直接决定答得好不好。于是大家研究话术——角色扮演、思维链、少样本示例。这是 Prompt Engineering，瓶颈卡在"怎么说"。
2025 年，模型变强了，开始当 agent 干活。你让它改 bug，它写得再漂亮也没用——它没看过你的代码。于是瓶颈从"怎么问"移到"喂什么"：把对的代码、文档、工具塞进上下文窗口。这是 Context Engineering，瓶颈卡在"喂什么"。
2026 年初，模型能连续干几小时了。但它的"工作环境"跟不上——需要工具执行命令、需要沙箱安全试错、需要权限边界防止误伤。这套运行装备叫 harness。这是 Harness Engineering，瓶颈卡在"在哪干"。
话术、材料、驾驶舱，三道坎都过了。最后剩的瓶颈是谁？
你自己。
模型在等你布置任务，harness 在等你启动，材料在等你投喂。整条流水线上，唯一还需要人肉驱动的环节，就是你坐在屏幕前敲下一条 prompt。你睡觉，它就停工。
Loop Engineering 瞄准的就是这最后一环：设计一个系统，让"下一次回车"不再由你来按。
| 代际 | 设计对象 | 瓶颈 | 你的角色 |
|---|---|---|---|
| Prompt Eng. (2022–2024) | 提示词的措辞、格式 | 怎么说 | Prompt Writer |
| Context Eng. (2025) | 模型看到的信息 | 喂什么 | Context Curator |
| Harness Eng. (2026 初) | 工具、沙箱、权限 | 在哪干 | Environment Designer |
| Loop Eng. (2026.6) | 自主迭代系统 | 谁来按回车 | System Architect |
规律很简单：模型每变强一截，瓶颈就往外移一层。四个 Engineering 不是营销轮换，是瓶颈迁移的路标。
02 Loop Engineering 到底是什么？
Addy Osmani 给的定义：「Loop Engineering 就是把亲自给 agent 写 prompt 的那个你替换掉。你转而去设计那个代替你做这件事的系统。」
说人话：过去两年你跟 coding agent 的协作是回合制的——你写一条 prompt，读输出，再写下一条。agent 是工具，你全程握着，一回合都不能松手。
Loop Engineering 说的是：松手吧。 你把"发现任务、布置任务、检查结果、决定下一步"这套流程设计成一个能自己运转的循环，让循环去握着 agent。
打个比方。以前你是客服热线的接线员，每个电话都要你亲自接、亲自答；现在你升级成了设计工单系统的人：电话怎么分流、哪类问题转给谁、办结标准是什么、办不了的怎么升级到你——规则定好，系统自己转。
你没有离开这家公司，但你的岗位变了。
这也是 Boris Cherny 那句"我的工作是写 loop"的真正含义。工作没有变容易，是杠杆的支点移动了。 以前你写一条好 prompt，收益是"这一次回答变好"；现在你设计一个好 loop，收益是"之后每一次循环都变好"。投入从消耗品变成了资产。
但反过来，设计 loop 比写 prompt 难得多——你要考虑触发、并行、验证、状态、止损，相当于从"说一句话"升级到"设计一套制度"。
03 一个 Loop，需要哪几样东西？
把真正跑起来的 loop 拆开看，零件出奇地一致：五大件，外加一个记东西的地方。 每一件都对应一个"不装它就会翻车"的场景。
① 自动化 — loop 的心跳
你写了一个完美的脚本，但每次都要手动启动——它算 loop 吗？不算。自动化才让 loop 成为真正的 loop，否则它只是一个你跑过一次的任务。 每天早上自动扫 CI 失败、每次 PR 合并自动跑检查。心跳有了，循环才算活着。
② Worktree — 让并行不变成打架
loop 一旦跑起来，经常几个 agent 同时干活。两个 agent 同时改同一个文件，就像两个工程师挤在一台电脑上改同一行代码。解法是 git worktree：给每个 agent 独立的工作目录，共享仓库历史但物理上互不干扰。各干各的，各开各的 PR。
③ Skill — 治好 agent 的"金鱼记忆"
agent 有个天生缺陷：每个会话都是冷启动，你项目里的规范、约定、坑，它一概不知。你不得不像对金鱼一样每个会话把项目重新解释一遍。Skill 就是把这些知识写成文件放仓库里，让 agent 该用的时候自己读。没有 skill，loop 每个周期都从零推导；有了 skill，知识是复利的。
④ Connector — 让 loop 摸到真实世界
只能看见文件系统的 loop，撑死了算半个 loop。你得让它能调 API、读 GitHub Issue、查 Linear 看板、发 Slack 通知。这就是 connector 干的事——通过 MCP 接入真实工具，让 loop 不再是个闭门造车的书呆子。
⑤ Sub-agent — 写的人和查的人必须分开
让写代码的 AI 给自己打分，它只会盲目自我赞美。必须引入一个完全独立的、默认持怀疑态度的"评估者"agent 来挑错。 写的人负责干，查的人负责挑刺，两个 agent 不共享上下文，验证才靠谱。
⑥ 记忆 — loop 的命根子
没有记忆的 loop，每次都从零开始，上一次踩过的坑这次照样踩。短期记忆记住本次循环干了什么，长期记忆记住项目约定和历史决策，实体记忆记住 API 文档和代码结构。第 2 次执行同一类任务时，应该比第 1 次更高效。
04 Loop 的六个设计维度
上面五大件是"零件"。Loop Engineering 还要在零件之上做系统设计——六个维度，每个都对应一个 Agent Loop 没回答的问题：
| 维度 | Agent Loop 的缺陷 | Loop Engineering 怎么补 |
|---|---|---|
| 目标定义 | 只接收一个 task 字符串 | 可测试的终止条件：测试通过、lint 干净 |
| 验证机制 | LLM 自己判断是否完成 | 确定性验证：跑测试、检查类型、对比 diff |
| 上下文管理 | messages 列表无限膨胀 | Token 策略：摘要压缩 + 外部记忆 |
| 安全与预算 | 只有 max_steps 硬上限 | Token/时间/成本预算 + 升级逻辑 |
| 记忆层 | 无状态，每次从零开始 | 短期 + 长期 + 实体记忆，跨会话学习 |
| 人机协作 | 要么全自动，要么全手动 | 精确介入点：破坏性操作前需确认 |
一句话区分：Agent Loop 是发动机，Loop Engineering 是整车设计。 发动机只有 30 行代码——推理、行动、观察、重复。整车设计要在发动机之上加变速箱、刹车、仪表盘和安全气囊。
05 怎么入门？从一件小事开始
不需要一上来就搭一个复杂的编排系统。从一个你已经在重复做的 AI 任务开始：
第一步，挑一个你每天都在做的 AI 重复任务——代码审查、测试修复、文档更新都行。
第二步，写下"完成"的判定标准——测试通过、lint 干净、或者一个独立 agent 说合格。必须是可检查的，不能是"看起来还行"。
第三步，加一个验证步骤，agent 不能跳过——跑测试、跑 lint、或者让另一个 agent review。
第四步，把指令存成 skill，下次不用从头 prompt。
第五步，最后才加定时触发或事件触发，让它自己跑。
不是所有事情都需要 loop。改一个变量名，一条 prompt 就够了。但"每天早上扫一遍 PR 有没有无障碍问题"这种事，就该设计成 loop。
06 三盆冷水
Loop 越好用，有三个问题越尖锐。不讲的话，就是骗你入坑。
第一盆：验证仍然归你
Loop 可以自动跑，但"跑出来的东西对不对"这个判断，最终还是得你来。验证器可以帮你跑测试、查 lint，但"这个设计方向对不对"、"这个方案用户买不买单"，模型替不了你。
第二盆：理解债，越顺滑涨得越快
Loop 跑得越顺，你越少看代码。一年后系统出问题了，你打开自己设计的 loop，发现已经看不懂它在干什么了。自动化不是免费的，代价是你的理解力在透支。
第三盆：认知投降，最舒服的姿势最危险
当你习惯了一切自动运转，最危险的事就发生了：你不再质疑结果。 Loop 给你什么你就收什么，反正它一直是对的——直到它不对的那天。
07 Loop 跑起来，Token 烧得起吗？
说个现实问题。Loop 的本质是让 agent 反复跑——推理、行动、观察、再推理。一个 loop 跑 10 轮，每轮塞几千 token 的上下文，加上子 agent 验证又烧一波，一天下来 token 消耗可能是单次 prompt 的几十倍。
Loop 越自动，token 越如流水。 这时候就得算一笔账了。
向量云是火山方舟官方 API 的优选接入渠道，专门解决"token 消耗大"这个问题。基于缓存隔离和分时段调度，长上下文、高频并发的 loop 场景下成本能降不少。官方 API 能力不变，到手价更低。
- ◆ 官方 API 直连，模型能力完全一致
- ◆ 分时段折扣，闲时价格更优
- ◆ 高缓存隔离命中率，loop 重复上下文省更多
- ◆ 企业级并发承载，多 agent 并行稳定可靠
- ◆ 多模型兼容，一站接入主流大模型
- ◆ 按量计费，余额耗尽即停，无欠费风险
平台网址：ark.tokenrize.cn（注册即享专属 Token 折扣）
Loop Engineering 一句话总结：你不再是 prompt 的作者，你是 prompt 生产系统的设计师。
杠杆变长了，对握杠杆的人要求也变高了。模型替你干活，但"干什么活"、"干到什么程度算完"、"干错了怎么办"——这些问题的答案，还是得你来给。
