AI Agent 的结构性困境与 Loop Engineering 的解决方案

本文探讨了 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 有四个结构性死穴上下文硬限制提示词越来越长迟早撞到上下文长度上限。塞多了反而稀释重要信息的注意力权重。无状态遗忘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 的控制权从更具体的层级移交到更抽象的层级。最终人只需要关心三件事我的目标是什么哪些规则必须遵守什么时候需要我来拍板结语抓住大模型时代的职业机遇AI大模型的发展不是“替代人类”而是“重塑职业价值”——它淘汰的是重复性、低附加值的工作却催生了更多需要“技术业务”交叉能力的高端岗位。对于求职者而言想要在这波浪潮中立足不仅需要掌握Python、TensorFlow/PyTorch等技术工具更要深入理解目标行业的业务逻辑如金融的风险控制、医疗的临床需求成为“懂技术、懂业务”的复合型人才。无论是技术研发岗如算法工程师、研究员还是业务落地岗如产品经理、应用工程师大模型都为不同背景的职场人提供了广阔的发展空间。只要保持学习热情紧跟技术趋势就能在AI大模型时代找到属于自己的职业新蓝海。最近两年大模型发展很迅速在理论研究方面得到很大的拓展基础模型的能力也取得重大突破大模型现在正在积极探索落地的方向如果与各行各业结合起来是未来落地的一个重大研究方向大模型应用工程师年包50w属于中等水平如果想要入门大模型那现在正是最佳时机2025年Agent的元年2026年将会百花齐放相应的应用将覆盖文本视频语音图像等全模态如果你对AI大模型入门感兴趣那么你需要的话可以点击这里大模型重磅福利入门进阶全套104G学习资源包免费分享扫描下方csdn官方合作二维码获取哦给大家推荐一个大模型应用学习路线这个学习路线的具体内容如下第一节提示词工程提示词是用于与AI模型沟通交流的这一部分主要介绍基本概念和相应的实践高级的提示词工程来实现模型最佳效果以现实案例为基础进行案例讲解在企业中除了微调之外最喜欢的就是用提示词工程技术来实现模型性能的提升第二节检索增强生成RAG可能大家经常会看见RAG这个名词这个就是将向量数据库与大模型结合的技术通过外部知识来增强改进提升大模型的回答结果这一部分主要介绍RAG架构与组件从零开始搭建RAG系统生成部署RAG性能优化等第三节微调预训练之后的模型想要在具体任务上进行适配那就需要通过微调来提升模型的性能能满足定制化的需求这一部分主要介绍微调的基础模型适配技术最佳实践的案例以及资源优化等内容第四节模型部署想要把预训练或者微调之后的模型应用于生产实践那就需要部署模型部署分为云端部署和本地部署部署的过程中需要考虑硬件支持服务器性能以及对性能进行优化使用过程中的监控维护等第五节人工智能系统和项目这一部分主要介绍自主人工智能系统包括代理框架决策框架多智能体系统以及实际应用然后通过实践项目应用前面学习到的知识包括端到端的实现行业相关情景等学完上面的大模型应用技术就可以去做一些开源的项目大模型领域现在非常注重项目的落地后续可以学习一些Agent框架等内容上面的资料做了一些整理有需要的同学可以下方添加二维码获取仅供学习使用