一个工程师让 AI Agent 修一个数据库慢查询。Agent 改了代码测试挂了工程师把报错贴回去Agent 再改CI 又挂了工程师再排查再贴代码审查又没过——六轮之后工程师花的时间比自己写还多。这不是个案而是当前 AI Agent 的结构性困境Agent 会回答但不会闭环。它能生成一个方案但不能自己验证方案是否可行、不可行时自己修正、修正后自己推进到下一步。用第一性原理追问剥离提示词、“对话”、工具调用这些表象人真正需要的是什么不是一个能回答问题的聊天机器人而是一个能把任务彻底完成的系统。彻底完成意味着从识别问题到分析原因、制定方案、实现修改、验证测试、通过审查、最终合并——整个链条闭环。Loop Engineering 的本质把人和 AI 的协作从问答式交互升级为闭环式自动化。不是我问你答而是我给你目标你自己跑完全程。这是 Loop Engineering 的核心哲学。从 Prompt 到 Loop 的范式革命在 Loop Engineering 出现之前AI 工程经历了三次演进。每一层都试图解决更深层的问题但每一层都有自己的结构性的局限。四层不是替代关系而是层叠关系——每一层包裹住内层杠杆点逐层向远离裸模型调用的方向移动。第一层Prompt Engineering核心问题“我该对模型说什么”Prompt Engineering 的核心假设是模型的能力是固定的影响输出质量的关键变量是你怎么提问。思维链、少样本学习、角色设定、格式约束——各种提示词技巧应运而生。Andrej Karpathy 在 2023 年说“最热门的编程语言是英语。”但 Prompt Engineering 有四个结构性死穴上下文硬限制提示词越来越长迟早撞到上下文长度上限。塞多了反而稀释重要信息的注意力权重。无状态遗忘LLM 大多是无状态的每次对话结束上下文清空。多轮迭代的任务每次重启都要重新喂背景。幻觉和注意力漂移提示词越长模型在中途走神的概率越大。精心设计的约束条件可能在第 10 步就被悄悄忽略。人始终是循环里的决策节点最致命的一点。AI 生成结果 → 人审核 → 人修改 → 人复制 → 人粘贴 → 人验证 → 人反馈——人从来没有真正解放。“Prompt Engineering 的根本局限它只能优化单次交互无法构建一个能可靠、连续、自主运行多步骤任务的系统。提示词是接口不是系统。第二层Context Engineering核心问题“我该让模型看见什么”Karpathy 推动了这次认知转变与其纠结如何措辞不如控制模型推理时能看到什么。上下文本身成了设计的核心对象——系统提示定义角色与约束MCP 协议接入外部工具RAG 即时注入检索结果对话历史维持任务连贯性。Anthropic 把 Context Engineering 定性为Prompt Engineering 的自然演化——问题的视角从如何问一个好问题转向了如何设计一个好的信息环境。但 Context Engineering 有清晰边界。它解决了信息给得对不对没有解决任务跑得动不动。一个被精心配置了上下文的 Agent面对需要多轮迭代、跨会话执行的复杂任务时依然会卡住——谁来跟进下一步谁来判断上一步是否成功谁来决定下一个操作仍然需要人来维持。“致命的是Context Anxiety上下文焦虑随着上下文窗口被填满模型进入急于完成的状态匆忙收尾质量骤降。第三层Harness Engineering核心问题“我该给 Agent 搭什么环境”Mitchell HashimotoHashiCorp 创始人提出了核心洞察每次 Agent 出错与其修改提示词让它下次做得更好不如改变系统结构让这个错误在结构上无法再次发生。这是从调教模型到设计防错系统的根本转变。Agent Model Harness。模型提供推理能力Harness 把这个能力变成可信赖的、可重复的生产力。Harness 解决了大量可靠性问题。OpenAI Codex 团队仅三人五个月产出约 100 万行生产级代码零手写——靠的不是更好的提示词而是严格的 Harness 架构约束。“但 Harness 是静态的。它建好了车间、配好了工具、定好了流程但谁来决定今天生产什么谁来验收产品谁来处理异常——这些动态的、持续运转的问题Harness 回答不了。第四层Loop Engineering核心问题“我该设计什么循环让 Agent 自主跑”2026 年 6 月 2 日Boris ChernyClaude Code 作者在 WorkOS Acquired Unplugged 活动上发言“我不再提示 Claude 了。我有循环在运行它们自己在提示 Claude自己决定下一步怎么做。我的工作是写循环。”2026 年 6 月 7 日Addy OsmaniGoogle 工程总监正式命名 Loop Engineering并明确定义“Replacing yourself as the person who prompts the agent. You design the system that does it instead.”Harness 是环境静态Loop 是机制动态。Harness 建好了车间Loop 是排班和验收制度——决定每天生产什么、谁来做什么、怎么验收、异常怎么处理。三、对比分析有没有 Loop差别在哪一个需要多轮迭代的工作任务修 bug、优化查询、重构代码典型流程是人识别问题打开 AI 助手输入提示词AI 生成方案 → 人复制执行 → 报错 → 人贴回错误信息AI 再生成 → 人再执行 → 测试失败 → 人再贴AI 再改 → 人再执行 → 审查不过 → 人再贴循环往复直到通过——或者人放弃特征每个环节都需要人手动推进。AI 是工具人是发动机。人一离开工位循环就停。AI 不记得昨天说了什么、项目有什么规范、上次踩过什么坑——每次从零开始。有 Loop 时的理想工作流人在 GitHub 提交 issue 或定义目标Loop 自动识别任务触发处理Loop 读取项目上下文代码库、文档、历史决策、团队规范Loop 在隔离环境中分析、实现、测试Loop 派验证者子 Agent 独立审查通过验证 → 自动提交 PR未通过 → 自主修正再迭代需要人工拍板 → 带着上下文升级给人不需要 → 自动合并Loop 记录处理经验更新知识库特征人只在定义目标和关键决策时介入其余环节自动闭环。第二天遇到类似问题Loop 复用已有经验更快完成。数据佐证这不是想象。Boris Cherny 从 2025 年 11 月起 100% 的代码由 Claude Code 产出每天 10-30 个 PR。Anthropic 内部数据每位工程师代码产出增长 200%PR 合并量增长 67%。公开 GitHub 上约 4% 的提交已由 Claude Code 产出。“核心转变发动机从你换成了一段一直在转的程序。你不再一轮一轮戳 Agent而是设计一个会自动戳 Agent 的系统。四、分析框架智能办公室模型综合前面的分析我提出一个理解 Loop Engineering 的分析框架智能办公室模型。一个运转良好的公司办公室本质上就是一个 Loop 系统一个任务进来前台自动识别分配执行者在自己的工位上干活查阅档案获取知识完成后质检员独立审查日志记录全过程。下次类似任务查日志即可复用。Loop 就是把一个运转良好的办公室自动化成 AI 系统。五原语 记忆的详细拆解Automations/Scheduling自动触发Loop 的心脏。没有调度就只是一次性运行。形式包括Claude Code 的/loop命令、Codex 的 Automations 标签页、GitHub Actions cron、事件钩子有人开了 PR 自动触发。Worktrees工作树隔离当两个 Loop 同时编辑同一份代码会出现 merge 地狱。Git worktrees 让每个 Agent 拥有独立的工作目录执行完后清理。真正卡住并行能力的往往不是能开几个 Agent而是能审几个——审查带宽才是上限。Skills技能/项目知识项目意图的持久化。一个 SKILL.md 文件编码了项目约定、构建命令、代码规范、领域知识。没有 SkillsLoop 每次从零推导——这就是意图债务。写一次每次都读这是原则。Plugins Connectors连接器让 Loop 碰到真实工具GitHub PR、Jira/Linear tickets、Slack 通知、数据库查询。MCP 已经成为这套生态的通用协议层。连接器的完整性直接决定 Loop 能解决的问题边界。Sub-agents子 Agent最重要的结构性模式。写代码的 Agent 不能评判自己的工作——运动员不能兼任裁判。第二个 Agent不同 prompt有时用更强模型负责验证。这种 Maker/Checker 分离是无人值守 Loop 能让人安心走开的唯一保障。Memory/State记忆/状态模型没有跨会话长期记忆。Loop 必须读写持久化的东西一个 STATE.md、一个 database row、一个 GitHub Project view。好的状态文件回答三个问题当前在做什么上次尝试了什么、结果如何什么在等人工处理最小可用循环一个最简单的 Loop 只需要四样东西一个触发什么时候开始一个写好的指令要做什么一个状态文件记录过程和结果一道验证门如何知道做完了顺序也不要反先手动把这件事完整跑通一遍整理成可复用的指令包进循环最后再配定时。以github上的 cobusgreyling/loop-engineering 的项目为例以github上的 cobusgreyling/loop-engineering 的项目为例逐步拆解每一个环节的设计逻辑。理解这个流程的关键不是记住步骤顺序而是弄清楚每一步解决什么问题跳过它会出什么毛病。第一步Schedule/Automation —— 任务从哪来这是 Loop 的起点也是最容易被忽略的一步。很多工程师的直觉是我手动触发就行了但手动触发不是 Loop那叫脚本。Loop 的本质区别在于它自己知道什么时候该动。触发方式分两种时间驱动和事件驱动。时间驱动就是 cron——每天凌晨两点扫描一次依赖更新事件驱动就是钩子——有人提了 issue、有人推了代码、有人改了配置Loop 自动响应。好的 Loop 设计时间驱动负责定期巡检事件驱动负责实时反应两者互补。这一步如果设计不好后果不是不工作而是总在你不想它工作的时候工作——比如在你演示的时候突然触发了重构循环。第二步Triage Skill —— 该做什么谁来做任务进来之后Loop 要做的第一件事不是动手而是判断。这个判断包含两个层面一是分类——这是 bug 修复、功能开发、依赖升级还是安全补丁不同类别走不同流程。二是优先级排序——哪些该立刻处理哪些可以排队哪些直接拒绝。Triage 为什么不能跳因为如果没有分流所有任务都会涌进同一条流水线。一个简单的依赖更新和一个涉及核心架构的重构需要的资源、审批流程和验证标准完全不同。不区分就硬跑轻则浪费 token重则让高风险操作绕过了该有的审查。Triage Skill 本质上就是智能办公室里前台的角色——不是自己干活而是确保每一件事被送到正确的处理通道。第三步ReadWrite STATE/Memory —— Loop 的眼睛和笔记本动手之前Loop 必须先看清当前状态。这一步做两件事读和写。读是加载上下文项目当前的 STATE.md 里记录了什么上次跑到哪一步了有哪些已知问题和团队约定这些信息决定了 Loop 接下来的行为不会是从零开始的盲目操作。一个没有读状态的 Loop就像一个从不看项目文档的新人——每次都重新踩同样的坑。写是更新状态每一步执行后把关键信息写回去——做了什么、结果如何、还有什么没做。这一步如果缺失Loop 就失去了跨迭代的记忆连续性。下次触发时它不知道上次做了一半的工作要么重复劳动要么覆盖已经完成的部分。Memory 的层次也很关键。粗分三层即时状态这次循环的执行记录、项目知识SKILL.md 等持久化约定、历史经验过去循环中学到的规则。三层信息用途不同——即时状态保证当前循环不失控项目知识保证行为符合团队规范历史经验保证不在同一个地方跌倒两次。第四步Isolated Worktree —— 给每个任务一个干净的工作台这一步解决的是并发冲突。当多个 Loop 同时运行时如果都在同一个工作目录上操作就像两个人同时编辑同一份文档——互相覆盖merge 地狱。Git worktrees 的设计思路是每个任务克隆一个独立的工作目录互不干扰。任务完成后再通过标准的 Git 流程分支、PR合并回主分支。这个隔离不只是技术上的便利更是一种结构性的保障——一个 Loop 的失败不会污染另一个 Loop 的工作成果。但这里有一个容易被忽视的瓶颈审查带宽。你可以同时开十个 worktree 让十个 Agent 并行干活但谁审查这十个 PR如果只有一个工程师审查并行度再高也没用瓶颈卡在人身上。所以 Isolated Worktree 的真正限制不是 Git 能开多少分支而是你的审查队列能消化多少。第五步Implementer Sub-agent —— 干活的人这是 Loop 的执行核心——一个独立的子 Agent按照 Triage 分配的任务和加载的上下文实际完成工作。它写代码、改配置、跑脚本把要做什么变成做完了。这里的关键设计决策是为什么是 Sub-agent 而不是主 Loop 自己做。原因有三个第一上下文隔离——主 Loop 保留全局视角子 Agent 只需要在干净、聚焦的上下文里工作避免信息过载导致注意力漂移。第二模型选择灵活——实现可以用快模型省成本验证可以用强模型保质量。第三可并行——多个子 Agent 可以同时跑不同的任务主 Loop 负责调度。子 Agent 的行为边界由 Skills 定义——它能调用什么工具、遵循什么规范、在什么条件下必须停下来问人。没有 Skills 约束的子 Agent就像一个没有操作手册的新人什么都敢做但什么都做不靠谱。第六步Verifier Sub-agent —— 说不的人这是整个 Loop 设计中最关键的架构决策。实现者不能验证自己的工作——这不是管理建议而是结构性约束。为什么因为 LLM 有一个系统性倾向自我确认偏差。当模型刚完成一段代码它会被自己的输出锚定——在审查时会倾向于认为自己的逻辑是对的对显而易见的错误视而不见。这不是模型不够聪明而是上下文的惯性刚写完的逻辑还在工作记忆里占据主导地位自然地顺着自己的思路检查。所以 Verifier 必须是一个独立的子 Agent运行在干净的上下文中。它看不到实现过程只看到最终产出和验收标准。它拿到的不是这段代码好不好而是这段代码是否满足以下清单。清单来自哪里来自你预先定义的 Skills、测试用例、代码规范——所有客观的、可逐条检查的标准。如果这一步缺失或弱化Loop 会规模化地生产自信的错误——跑得越快错的越多而且每次都觉得自己没问题。第七步TestsGates —— 客观的验收尺子Verifier 的主观判断之外Loop 还需要一层机器验证。测试套件、类型检查、lint、编译——这些都是不可谈判的硬门。通过就是通过不通过就是不通过不存在差不多。这一层的设计哲学是能用机器判定的绝不依赖 AI 判断。AI 可以评估代码质量、架构合理性但测试全过“无新增 lint 报错”构建成功这些事交给确定性程序远比交给另一个 LLM 可靠。Gate 的设置需要平衡两个极端太松坏代码溜过去太严Loop 永远通不过空转烧 token。好的 Gate 策略是分级的——编译和核心测试是硬门不过不能继续lint 和代码风格是软门不过可以继续但必须修复性能回归是观察门记录但不阻断。第八步MCP/Git/Tickets —— Loop 的手脚验证通过之后产出需要落到真实的系统里才有价值。这一步是 Loop 和外部世界的接口提交 Git commit、创建 Pull Request、更新 Jira/Linear ticket、发送 Slack 通知、触发下游 CI。MCPModel Context Protocol正在成为这一层的标准协议。它的价值不在于某个具体工具的对接而在于统一接口——不管是 GitHub 还是 Jira 还是 SlackAgent 都通过同一套协议访问新工具的接入成本从写一整套集成代码降到注册一个 MCP server。这一步如果缺失Loop 就是一个封闭的沙箱——能跑通但产出落不到任何真实系统里等于白干。第九步Need Human? —— Loop 的刹车和方向盘这是整个流程的分叉点。Loop 在这一步判断这件事我能自己拍板还是必须升级给人判断依据不应该是我能不能做而是做了之后的后果我能不能兜住。一个配置更新回滚成本很低可以自动通过一个涉及数据库迁移的操作出问题影响面大必须人工确认。好的升级设计不是简单的是/否二选一而是带着上下文升级。不是扔给工程师一句需要你确认而是附上做了什么、为什么这么做、验证结果如何、可能的风险是什么、推荐的操作是什么。工程师拿到的不应该是一个决策题而是一个已经有充分信息的审批题——他只需要判断不需要再从头理解。两条出路Yes需要人→ Escalate with context带着完整上下文升级给人。Loop 暂停在这个节点等待人工决策后继续。暂停不是失败而是设计——这就是 Loop 比无人看管的自动化更安全的地方。No不需要人→ Commit/PR自动提交。但自动提交不意味着无人负责——每一次自动提交都有完整的审计日志、可追溯的决策链路。出了问题你能回溯到是哪个 Loop、基于什么判断、在什么时间做了这个决定。流程总结为什么这九步缺一不可这九步构成了一个完整的认知闭环感知ScheduleTriage→ 理解Read State→ 隔离Worktree→ 执行Implementer→ 验证VerifierTests→ 行动MCP/Git→ 决策Need Human→ 产出Commit/PR或升级Escalate→ 记忆Write State。跳过任何一步都会在某个维度上打开漏洞“一个设计得当的 Loop不是每个环节都做到极致而是每个环节都做到刚好不漏。四层演化的核心脉络从 Prompt 到 Loop人类把对 AI 的控制权从更具体的层级移交到更抽象的层级。最终人只需要关心三件事我的目标是什么哪些规则必须遵守什么时候需要我来拍板五、开源项目案例与范式转变总结案例1cobusgreyling/loop-engineering——Loop Engineering 的方法论文档GitHubcobusgreyling/loop-engineering | 210 stars | MIT License这个仓库不只是代码更是 Loop Engineering 的方法论文档。它提供了7 个生产级模式覆盖从简单定时任务到复杂多 Agent 协作的场景3 个 CLI 工具直接在命令行中管理 Loop安全指南权限管理、密钥轮换、审计日志真实失败案例Ralph Wiggum 循环、过度烘焙Overbaking等它的五原语框架已成为 Loop Engineering 的标准参考。核心主张Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead.用智能办公室模型解读这个仓库就是办公室的管理制度手册——定义了每个角色该做什么、流程该怎么走、出了问题怎么处理。案例2loopengine/loop-engine——企业级 Loop 治理框架官网loopengine.io | npm 包 loop-engine/*这是一个完整的 Loop 治理框架提供了 SDK、Actors执行者、Signals信号、Adapters适配器等模块支持 Vercel AI SDK、OpenAI、Anthropic 等多种后端。核心模式wrapTool——把 AI 工具调用包进治理循环。高影响操作如金额超过 $5000 的采购单需要人工审批低影响操作自动通过。这直接解决了AI 自主行动的边界在哪这个关键问题。生产级示例展示了 Loop 从简单到复杂的递进关键设计思想不是全自动化而是高自动化 关键节点人工审批。这呼应了 Loop Engineering 的核心原则——人保留决策权AI 保留执行权。用智能办公室模型解读loopengine 就是办公室的审批系统——什么级别的事情谁有权批什么操作需要升级都有明确定义。案例3obra/superpowers——223k 星的 Agentic 技能框架GitHubobra/superpowers | 223k stars | MIT License这是目前最成功的 Agentic skills framework。Jesse VincentRequest Tracker 作者构建了 14 个技能覆盖完整的开发生命周期强制 AI 遵循专业开发流程。7 阶段开发工作流Brainstorming → Git Worktrees → Planning → Execution → Testing → Code Review → Finalization核心创新是Subagent-Driven Development每个任务派一个全新的子 Agent 执行两级审查Spec Compliance代码是否符合规格Code Quality代码质量是否达标强制 TDDRED-GREEN-REFACTOR——先写测试红再写实现绿再重构。代码写在测试之前删掉重来。跨平台支持 Claude Code、Cursor、Codex、OpenCode、Gemini CLI。2026 年 1 月被 Anthropic 官方接受进入 Claude 插件市场。用智能办公室模型解读superpowers 就是办公室的员工培训体系——它不是给办公室添工具而是给员工立规矩。技能自动触发Agent 不需要被提醒就遵循专业流程。设计哲学很直白流程必须清晰到一个热情但缺乏判断力的初级工程师也能遵循。案例4autoresearch-skill——Loop 在研究领域的延伸受 Karpathy 的 autoresearch 启发这个项目展示了 Loop 的另一扇门不只是工程任务可以 Loop 化研究任务也可以。给定一个研究目标AI 自动搜索、分析、总结、迭代直到得出结论或需要人工介入。用智能办公室模型解读这是把 Loop 从工程部门扩展到研究部门——同样的循环机制不同的工作内容。四个项目的生态定位这四个项目不是孤立的它们正在形成 Loop Engineering 的完整技术栈六、Loop Engineering 的关键设计问题什么时候该用 Loop不是所有任务都适合 Loop 化。四个必要条件缺一个成本就容易大过收益每周至少重复一次低频任务不值得自动化搭建成本靠反复运行摊平结果能自动验证有测试、有编译、有明确的对错判断。否则人还是要一遍遍看Token 预算扛得住循环一定会有空转和无效尝试计量收费下账单跟着跑Agent 有高级工程师级工具要能跑测试、查日志、开 PR典型翻车模式设计一个好 Loop 的核心问题完成由谁判定AI 自己独立验证 Agent人——不能让执行者兼任裁判反馈信号从哪来测试结果用户行为独立评审 Agent什么时候必须停迭代次数上限、预算上限、风险升级——没有止损的 Loop 要么烧钱要么规模化地生产自信的错误记忆写入什么、何时被消费哪些信息需要持久化什么情况下读取写入的东西经过验证了吗提炼成可复用形式了吗下次任务开始时会读到吗——三个环节断掉任何一个记忆就只是占地方的日志记忆的递进层次记忆不是存聊天历史——那本质是个回收站。一个理想的记忆回路应该完成五步递进“出错并记下来 → 弄清为什么错 → 验证自己的诊断 → 把诊断提炼成通用规则 → 新任务直接查规则而不是重新踩坑弱模型停在第一步记忆库就是一堆错题集。强模型走完全程把教训变成规则。两个关键设计原则原则一给验收清单而非操作步骤。告诉 AI要做到哪些标准而不是按这个步骤做。一条模糊的标准“代码质量要高”会让整个 Loop 空转换成可检查的写法“测试全过且无新增 lint 报错”它才收敛得了。原则二实现者和验证者必须分离。模型自我批判的效果不好它会倾向于认可自己刚做完的东西。有效的做法是再开一个独立的验证 Agent在干净的上下文里打分。Loop 之后第五层范式会是什么从前面的分析中可以提取出一条清晰的演化暗线每一层都解决了上一层解决不了的问题同时又暴露了新的结构性瓶颈。按这个逻辑推演Loop 的瓶颈在哪第五层就该从那长出来。Loop 的三个结构性瓶颈瓶颈一Loop 不能设计自己。当前的 Loop 需要人来定义——触发条件、流程步骤、验收标准、升级规则全部靠人预设。Loop 跑得再快它的结构是静态的。如果业务变化了、团队规范调整了、或者 Loop 自己发现了更优的执行路径它没法自我重构——只能等人来改。瓶颈二Loop 之间不能对话。一个团队可能有代码质量 Loop、安全扫描 Loop、依赖更新 Loop它们各跑各的。代码质量 Loop 重构了一段代码安全扫描 Loop 发现引入了漏洞依赖更新 Loop 又改了版本——三个 Loop 互相不知道对方在干什么产出互相打架。单个 Loop 的闭环能力再强Loop 之间的协调仍然靠人。瓶颈三Loop 不能质疑目标。Loop 擅长回答怎么把这件事做好但从不问这件事该不该做。你让它优化查询性能它就优化——哪怕整个表应该被弃用了。你让它修 bug它就修——哪怕修的成本比重写还高。古德哈特定律的根源就在这里Loop 优化你给的目标而不是优化你真正想要的。这三个瓶颈指向同一个方向Loop 缺少元认知能力——对自身、对同伴、对目标的反思能力。第五层的三个可能形态基于这三个瓶颈第五层范式可能沿着三条路径分化最终汇合。形态一Meta-Loop——自设计的循环核心问题“谁设计 Loop”当前人设计 Loop → Loop 执行任务。第五层Loop 观察自己的运行数据 → Loop 修改自己的结构 → 改进后的 Loop 继续执行。这不是递归的玄学而是有明确机制的闭环性能监控每个 Loop 记录自己的运行指标——成功率、空转率、token 消耗、人工介入频率、修复后回退率瓶颈定位Meta-Loop 分析这些指标识别结构性问题——比如80% 的升级发生在 Triage 之后说明 Triage Skill 的分流逻辑需要调整结构修改Meta-Loop 不是直接改代码而是修改 Loop 的配置和规则——调整触发条件、重写验收清单、增加或删除步骤、修改升级阈值AB 验证修改后的 Loop 先在影子模式下并行运行与原 Loop 产出对比确认改进后替换这与当前 Loop 的关键区别是当前 Loop 的结构是设计时确定的Meta-Loop 的结构是运行时演化的。就像生物体——DNA 是初始设计但免疫系统在学习、神经突触在重组个体的结构在生命周期中持续调整。风险也很明确Meta-Loop 的古德哈特问题更难检测。如果 Meta-Loop 优化减少人工介入次数它可能把升级阈值调到极低让本该由人判断的高风险操作自动通过。所以 Meta-Loop 的验收标准比普通 Loop 更难写——你验证的不只是任务做对了而是系统在往对的方向演化。形态二Ecosystem Engineering——Loop 之间的市场与协议核心问题“多个 Loop 如何协作”当 Loop Engineering 普及后每个团队、每个项目、甚至每个开发者都会有自己的 Loop。问题从如何设计一个 Loop变成如何让一百个 Loop 不打架。这不是规模问题而是协调问题。类比经济学一个工厂内部的生产调度单个 Loop和管理学相关但一千个工厂之间的资源配置多个 Loop 协作和经济学相关——后者需要市场、价格信号、合约机制。Ecosystem Engineering 需要三层基础设施协议层Loop 之间的通信标准。一个 Loop 完成了代码重构如何通知安全扫描 Loop不是靠人贴 Slack而是靠协议——一种机器可读的事件总线每个 Loop 发布自己的产出和状态变更订阅方自动响应。协商层当两个 Loop 的目标冲突时如何仲裁代码质量 Loop 要重构部署稳定性 Loop 要求冻结变更——谁优先这需要一种优先级市场每个 Loop 对自己的操作声明影响范围和紧急度由仲裁规则或更高层的调度 Loop 决定执行顺序。信任层一个 Loop 的产出被另一个 Loop 消费时前者如何证明自己的质量这需要一种可验证的信任链——不是我测过了你信我而是附上验证记录、测试报告、审计日志消费方可以独立验证。loopengine/loop-engine 的 wrapTool 模式已经在这个方向上迈出了一步——它给工具调用包了一层治理本质上就是在单个 Loop 内部建立信任边界。Ecosystem Engineering 是把这个逻辑扩展到 Loop 之间。形态三Intent Engineering——目标的精准表达与质疑核心问题“我真正想要的是什么”这是最深的一层。当执行被完全自动化后意图表达就成了最稀缺的资源。Prompt Engineering 教你说清楚做什么Context Engineering 教你给对看什么Harness Engineering 教你建对在哪做Loop Engineering 教你设计怎么循环——但所有这些的前提都是你知道自己要什么。现实是大多数时候你并不真的知道。你以为你要的是优化查询性能实际上你要的是用户不抱怨页面慢——前者是指标后者是意图。指标可以被游戏意图不能。Intent Engineering 要解决的不是如何更好地表达意图而是如何发现你表达的意图和你真正的意图之间的差距。这需要一种全新的机制意图反问系统在执行前不只接受你的目标还反向追问——你优化查询性能是为了降低成本还是改善体验如果是改善体验也许该优化的是前端缓存而非数据库查询。这种追问的质量决定了 Loop 是在优化指标还是在优化意图。结果回溯Loop 完成后不只报告任务完成还评估完成的结果是否真正改善了你关心的问题。测试全过了但用户满意度没变——说明目标和意图之间存在鸿沟。意图演化人的意图不是静态的。随着 Loop 的执行和结果的积累你对问题的理解会深化意图本身会进化。Intent Engineering 需要一种机制让 Loop 不只是执行固定目标而是跟着你的理解一起迭代目标。这呼应了文章开头的哲学每一次跃迁的术在升级但道始终是同一个——你对问题本身的理解是所有技术范式无法替代的核心。Intent Engineering 是把这句话从哲学判断变成工程实践不再假设人知道自己的意图而是把发现和校准意图本身作为系统的一部分。八、范式转变总结从 Prompt 到 LoopAI 工程经历了四次跃迁。暗线很清楚人一直在练一件事——把我想要什么说得越来越精确。一开始说给一个模型听现在说给一整套能自动运转的系统听。每一次跃迁术在升级但道始终是同一个问题你对问题本身的理解是所有技术范式无法替代的核心。Prompt Engineering 的术是措辞技巧背后的道是你需要知道你想要什么才能说清楚。Context Engineering 的术是信息架构设计背后的道是你需要知道什么信息是相关的才能给对。Harness Engineering 的术是系统结构设计背后的道是你需要理解 Agent 的失败模式才能设计防错结构。Loop Engineering 的术是循环程序设计背后的道是你需要知道什么叫完成才能让 Agent 自主停止。有一个值得认真对待的担忧当 Agent 越来越自主当 Loop 越来越精密会有人把 Loop Engineering 当成一种外包判断力的方式——让 Loop 决定做什么让 Agent 决定怎么做人只需要按一下启动。Boris Cherny 对此的表述很克制“你可以用 Loop 来更快地完成你理解的工作也可以用 Loop 来回避对工作的理解。这是两件完全不同的事。”Loop 是放大器。能放大你的能力也能放大你的懒惰。在 Loop Engineering 时代人保留的是意图表达权、规则制定权、关键节点决策权AI 获得的是执行权、优化权、自主迭代权。这是一次权力结构的重组——不是人变得不重要了而是人需要在更高的层次上发挥作用。给实践者的落地路径找任务别找循环先在日常工作里找一件事——重复做过三次以上而且结果能客观判断对错。找不到这样的事就还没到上循环的时候自己先跑通一遍手动从头到尾做一次把每一步、每个判断都记下来。你自己都说不清的流程别指望机器替你想清楚把做完了写成一把尺子把做得好这种模糊话改成机器能逐条检查的条件。写不出可验证标准通常说明你自己还没想清楚把指令整理成能复用的一块写成固定指令、Skill 或文档。写一次以后每次都调用给它配一道会说不的关一个测试、一次检查、一道人工审核门都行。没有任何东西能反驳的循环等于让 Agent 自己给自己打分最后才挂定时小预算试跑一开始给小额度盯紧两个数烧了多少 token错误率多高。确认它真在干正事再慢慢放权学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】