本文探讨了 AI Agent 在解决复杂任务时的局限性，即“会回答但不会闭环”。通过分析 Prompt Engineering、Context Engineering、Harness Engineering 的不足，提出了 Loop Engineering 的概念，旨在构建能自主完成从识别问题到验证测试、审查合并的全链条任务的系统。文章详细阐述了 Loop Engineering 的核心哲学、设计框架、关键设计问题以及未来可能的发展方向，为 AI 工程的范式革命提供了深入见解。

---

一个工程师让 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 有四个结构性死穴：

1. 上下文硬限制：提示词越来越长，迟早撞到上下文长度上限。塞多了反而稀释重要信息的注意力权重。
2. 无状态遗忘：LLM 大多是无状态的，每次对话结束上下文清空。多轮迭代的任务，每次重启都要重新喂背景。
3. 幻觉和注意力漂移：提示词越长，模型在中途"走神"的概率越大。精心设计的约束条件，可能在第 10 步就被悄悄忽略。
4. 人始终是循环里的决策节点：最致命的一点。AI 生成结果 → 人审核 → 人修改 → 人复制 → 人粘贴 → 人验证 → 人反馈——人从来没有真正解放。

“

Prompt Engineering 的根本局限：它只能优化单次交互，无法构建一个能可靠、连续、自主运行多步骤任务的系统。提示词是接口，不是系统。

第二层：Context Engineering

核心问题：“我该让模型看见什么？”

Karpathy 推动了这次认知转变：与其纠结如何措辞，不如控制模型推理时能"看到"什么。上下文本身成了设计的核心对象——系统提示定义角色与约束，MCP 协议接入外部工具，RAG 即时注入检索结果，对话历史维持任务连贯性。

Anthropic 把 Context Engineering 定性为"Prompt Engineering 的自然演化"——问题的视角从"如何问一个好问题"转向了"如何设计一个好的信息环境"。

但 Context Engineering 有清晰边界。它解决了"信息给得对不对"，没有解决"任务跑得动不动"。一个被精心配置了上下文的 Agent，面对需要多轮迭代、跨会话执行的复杂任务时，依然会卡住——谁来跟进下一步？谁来判断上一步是否成功？谁来决定下一个操作？仍然需要人来维持。

“

致命的是 Context Anxiety（上下文焦虑） ：随着上下文窗口被填满，模型进入"急于完成"的状态，匆忙收尾，质量骤降。

第三层：Harness Engineering

核心问题：“我该给 Agent 搭什么环境？”

Mitchell Hashimoto（HashiCorp 创始人）提出了核心洞察：每次 Agent 出错，与其修改提示词让它下次做得更好，不如改变系统结构，让这个错误在结构上无法再次发生。这是从"调教模型"到"设计防错系统"的根本转变。

Agent = Model + Harness。模型提供推理能力，Harness 把这个能力变成可信赖的、可重复的生产力。

Harness 解决了大量可靠性问题。OpenAI Codex 团队仅三人，五个月产出约 100 万行生产级代码，零手写——靠的不是更好的提示词，而是严格的 Harness 架构约束。

“

但 Harness 是静态的。它建好了车间、配好了工具、定好了流程，但谁来决定今天生产什么？谁来验收产品？谁来处理异常？——这些动态的、持续运转的问题，Harness 回答不了。

第四层：Loop Engineering

核心问题：“我该设计什么循环，让 Agent 自主跑？”

2026 年 6 月 2 日，Boris Cherny（Claude Code 作者）在 WorkOS Acquired Unplugged 活动上发言：“我不再提示 Claude 了。我有循环在运行，它们自己在提示 Claude，自己决定下一步怎么做。我的工作是写循环。”

2026 年 6 月 7 日，Addy Osmani（Google 工程总监）正式命名 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、优化查询、重构代码），典型流程是：

1. 人识别问题，打开 AI 助手，输入提示词
2. AI 生成方案 → 人复制执行 → 报错 → 人贴回错误信息
3. AI 再生成 → 人再执行 → 测试失败 → 人再贴
4. AI 再改 → 人再执行 → 审查不过 → 人再贴
5. 循环往复，直到通过——或者人放弃

特征：每个环节都需要人手动推进。AI 是工具，人是发动机。人一离开工位，循环就停。AI 不记得昨天说了什么、项目有什么规范、上次踩过什么坑——每次从零开始。

有 Loop 时的理想工作流

1. 人在 GitHub 提交 issue 或定义目标
2. Loop 自动识别任务，触发处理
3. Loop 读取项目上下文：代码库、文档、历史决策、团队规范
4. Loop 在隔离环境中分析、实现、测试
5. Loop 派验证者子 Agent 独立审查
6. 通过验证 → 自动提交 PR；未通过 → 自主修正再迭代
7. 需要人工拍板 → 带着上下文升级给人；不需要 → 自动合并
8. 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 系统。

五原语 + 记忆的详细拆解

9. Automations/Scheduling（自动触发）

Loop 的心脏。没有调度，就只是一次性运行。形式包括：Claude Code 的 /loop 命令、Codex 的 Automations 标签页、GitHub Actions cron、事件钩子（有人开了 PR 自动触发）。

10. Worktrees（工作树隔离）

当两个 Loop 同时编辑同一份代码，会出现 merge 地狱。Git worktrees 让每个 Agent 拥有独立的工作目录，执行完后清理。真正卡住并行能力的，往往不是能开几个 Agent，而是能审几个——审查带宽才是上限。

11. Skills（技能/项目知识）

项目意图的持久化。一个 SKILL.md 文件编码了项目约定、构建命令、代码规范、领域知识。没有 Skills，Loop 每次从零推导——这就是"意图债务"。写一次，每次都读，这是原则。

12. Plugins & Connectors（连接器）

让 Loop 碰到真实工具：GitHub PR、Jira/Linear tickets、Slack 通知、数据库查询。MCP 已经成为这套生态的通用协议层。连接器的完整性直接决定 Loop 能解决的问题边界。

13. Sub-agents（子 Agent）

最重要的结构性模式。写代码的 Agent 不能评判自己的工作——运动员不能兼任裁判。第二个 Agent（不同 prompt，有时用更强模型）负责验证。这种 Maker/Checker 分离，是无人值守 Loop 能让人安心走开的唯一保障。

• Memory/State（记忆/状态）

模型没有跨会话长期记忆。Loop 必须读写持久化的东西：一个 STATE.md、一个 database row、一个 GitHub Project view。好的状态文件回答三个问题：当前在做什么？上次尝试了什么、结果如何？什么在等人工处理？

最小可用循环

一个最简单的 Loop 只需要四样东西：

1. 一个触发：什么时候开始
2. 一个写好的指令：要做什么
3. 一个状态文件：记录过程和结果
4. 一道验证门：如何知道做完了

顺序也不要反：先手动把这件事完整跑通一遍，整理成可复用的指令，包进循环，最后再配定时。

以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 本质上就是"智能办公室"里前台的角色——不是自己干活，而是确保每一件事被送到正确的处理通道。

第三步：Read+Write 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 会"规模化地生产自信的错误"——跑得越快，错的越多，而且每次都觉得自己没问题。

第七步：Tests+Gates —— 客观的验收尺子

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。

MCP（Model Context Protocol）正在成为这一层的标准协议。它的价值不在于某个具体工具的对接，而在于统一接口——不管是 GitHub 还是 Jira 还是 Slack，Agent 都通过同一套协议访问，新工具的接入成本从"写一整套集成代码"降到"注册一个 MCP server"。

这一步如果缺失，Loop 就是一个封闭的沙箱——能跑通，但产出落不到任何真实系统里，等于白干。

第九步：Need Human? —— Loop 的刹车和方向盘

这是整个流程的分叉点。Loop 在这一步判断：这件事我能自己拍板，还是必须升级给人？

判断依据不应该是"我能不能做"，而是"做了之后的后果我能不能兜住"。一个配置更新，回滚成本很低，可以自动通过；一个涉及数据库迁移的操作，出问题影响面大，必须人工确认。

好的升级设计不是简单的"是/否"二选一，而是带着上下文升级。不是扔给工程师一句"需要你确认"，而是附上：做了什么、为什么这么做、验证结果如何、可能的风险是什么、推荐的操作是什么。工程师拿到的不应该是一个决策题，而是一个已经有充分信息的审批题——他只需要判断，不需要再从头理解。

两条出路：

• Yes（需要人）→ Escalate with context：带着完整上下文升级给人。Loop 暂停在这个节点，等待人工决策后继续。暂停不是失败，而是设计——这就是 Loop 比无人看管的自动化更安全的地方。
• No（不需要人）→ Commit/PR：自动提交。但"自动提交"不意味着"无人负责"——每一次自动提交都有完整的审计日志、可追溯的决策链路。出了问题，你能回溯到是哪个 Loop、基于什么判断、在什么时间做了这个决定。

流程总结：为什么这九步缺一不可？

这九步构成了一个完整的认知闭环：感知（Schedule+Triage）→ 理解（Read State）→ 隔离（Worktree）→ 执行（Implementer）→ 验证（Verifier+Tests）→ 行动（MCP/Git）→ 决策（Need Human）→ 产出（Commit/PR）或升级（Escalate）→ 记忆（Write State） 。

跳过任何一步，都会在某个维度上打开漏洞：

“

一个设计得当的 Loop，不是每个环节都做到极致，而是每个环节都做到刚好不漏。

四层演化的核心脉络

从 Prompt 到 Loop，人类把对 AI 的控制权从更具体的层级移交到更抽象的层级。最终，人只需要关心三件事：我的目标是什么？哪些规则必须遵守？什么时候需要我来拍板？

结语：抓住大模型时代的职业机遇

AI大模型的发展不是“替代人类”，而是“重塑职业价值”——它淘汰的是重复性、低附加值的工作，却催生了更多需要“技术+业务”交叉能力的高端岗位。对于求职者而言，想要在这波浪潮中立足，不仅需要掌握Python、TensorFlow/PyTorch等技术工具，更要深入理解目标行业的业务逻辑（如金融的风险控制、医疗的临床需求），成为“懂技术、懂业务”的复合型人才。

无论是技术研发岗（如算法工程师、研究员），还是业务落地岗（如产品经理、应用工程师），大模型都为不同背景的职场人提供了广阔的发展空间。只要保持学习热情，紧跟技术趋势，就能在AI大模型时代找到属于自己的职业新蓝海。

最近两年大模型发展很迅速，在理论研究方面得到很大的拓展，基础模型的能力也取得重大突破，大模型现在正在积极探索落地的方向，如果与各行各业结合起来是未来落地的一个重大研究方向

大模型应用工程师年包50w+属于中等水平，如果想要入门大模型，那现在正是最佳时机

2025年Agent的元年，2026年将会百花齐放，相应的应用将覆盖文本，视频，语音，图像等全模态

如果你对AI大模型入门感兴趣，那么你需要的话可以点击这里大模型重磅福利：入门进阶全套104G学习资源包免费分享！

扫描下方csdn官方合作二维码获取哦！

给大家推荐一个大模型应用学习路线

这个学习路线的具体内容如下：

第一节：提示词工程

提示词是用于与AI模型沟通交流的，这一部分主要介绍基本概念和相应的实践，高级的提示词工程来实现模型最佳效果，以现实案例为基础进行案例讲解，在企业中除了微调之外，最喜欢的就是用提示词工程技术来实现模型性能的提升

第二节：检索增强生成（RAG）

可能大家经常会看见RAG这个名词，这个就是将向量数据库与大模型结合的技术，通过外部知识来增强改进提升大模型的回答结果，这一部分主要介绍RAG架构与组件，从零开始搭建RAG系统，生成部署RAG，性能优化等

第三节：微调

预训练之后的模型想要在具体任务上进行适配，那就需要通过微调来提升模型的性能，能满足定制化的需求，这一部分主要介绍微调的基础，模型适配技术，最佳实践的案例，以及资源优化等内容

第四节：模型部署

想要把预训练或者微调之后的模型应用于生产实践，那就需要部署，模型部署分为云端部署和本地部署，部署的过程中需要考虑硬件支持，服务器性能，以及对性能进行优化，使用过程中的监控维护等

第五节：人工智能系统和项目

这一部分主要介绍自主人工智能系统，包括代理框架，决策框架，多智能体系统，以及实际应用，然后通过实践项目应用前面学习到的知识，包括端到端的实现，行业相关情景等

学完上面的大模型应用技术，就可以去做一些开源的项目，大模型领域现在非常注重项目的落地，后续可以学习一些Agent框架等内容

上面的资料做了一些整理，有需要的同学可以下方添加二维码获取（仅供学习使用）