Loop Engineering 入门到实战：从提示词到可运行的 AI 循环工程

一、先说结论Loop Engineering 到底是什么过去两年很多人学习 AI 的入口是“提示词工程”。大家反复研究怎么写 prompt怎么给角色怎么加约束怎么让模型一步一步思考。后来大家发现光会写 prompt 不够因为真实工作不是一问一答而是一串连续动作发现问题、收集上下文、生成方案、执行修改、跑测试、看结果、继续修、直到满足条件。这就是 Loop Engineering也可以叫“循环工程”。一句话解释Loop Engineering 是设计一个能反复驱动 AI agent 工作的闭环系统让 AI 不只是回答一次而是持续执行、验证、修正并在达到目标或触发风险时停下来。它关注的不是“这一句 prompt 怎么写得更漂亮”而是什么时候启动 AIAI 每一轮要读取什么信息AI 可以调用哪些工具AI 做完之后谁来检查检查不过怎么反馈最多循环多少次什么时候交给人状态记录在哪里下一轮怎么接着上次做如果把 AI 当作一个实习生Prompt Engineering 是“你怎么给他布置任务”Context Engineering 是“你给他哪些资料”Harness Engineering 是“你让他在哪个工位、用哪些工具、受哪些权限约束”Loop Engineering 则是“你设计一套每天自动派活、验收、返工、归档的流程”。所以Loop Engineering 不是一个神秘新框架它是一种工程思维把一次性的 AI 对话升级成可重复、可验证、可维护的 AI 工作流。二、为什么现在大家开始谈 Loop Engineering早期用 AI 写代码很多人是这样工作的打开 ChatGPT、Claude、Codex 或其他 AI 工具。输入“帮我实现某某功能。”复制代码。本地运行。报错了再把错误贴给 AI。AI 再修一版。再运行再报错再贴。这个过程看起来已经很智能但仔细想想大部分“循环”其实是人手动完成的。人负责发现错误人负责复制日志人负责提醒 AI 继续人负责判断什么时候算完成。随着 coding agent、工具调用、自动化任务、子 agent、worktree、MCP 连接器、测试工具越来越成熟AI 已经不只会“回答”它可以自己读文件、改代码、跑命令、查文档、开浏览器、写报告。于是新的问题出现了既然 AI 能行动为什么还要人每一轮都手动按一下继续Loop Engineering 就是在回答这个问题。Addy Osmani 在 2026 年 6 月发布的《Loop Engineering》中提到一个很有代表性的观点未来我们可能不再主要是“提示 agent”而是在“设计提示 agent 的循环”。他把 loop 看成是在 harness 之上的一层。也就是说harness 解决单个 agent 的运行环境loop 解决 agent 如何被持续触发、调度、检查和记忆。Anthropic 在《Building Effective Agents》中也强调很多 agent 本质上就是 LLM 根据环境反馈使用工具并在循环中推进任务。对代码任务尤其有效因为代码可以通过测试、lint、类型检查、运行结果来验证。OpenAI Codex 的 automations、skills、subagents、worktrees 等能力也都在把这种循环能力产品化定时触发、隔离工作区、复用技能、并行审查、记录结果。换句话说AI 工程的重点正在从“我怎么问得更好”转向“我怎么设计一个系统让 AI 在边界内持续做正确的事”。三、Prompt、Context、Harness、Loop 的区别很多新手容易把这些概念混在一起。我们用一个表格拆开名称关心的问题典型例子Prompt Engineering怎么问模型“请你扮演资深 Java 架构师按步骤分析”Context Engineering给模型看什么需求文档、代码片段、接口定义、日志、历史决策Harness Engineering模型在哪个环境里行动文件读写、命令执行、浏览器、权限、沙箱、测试脚本Loop Engineering如何持续驱动模型完成任务定时扫描 issue、自动修复、跑测试、失败后重试、成功后提交AgentOps / Governance上线后怎么管成本监控、审计、权限、人类审批、回滚、告警举个通俗例子。你让 AI 帮你修一个 bug。Prompt Engineering 是你写你是资深 Python 工程师请根据下面的报错定位 bug并给出最小修改。Context Engineering 是你把相关代码、错误日志、依赖版本、复现步骤都给它。Harness Engineering 是你允许它读取项目文件、运行pytest、修改代码但不能删除数据库。Loop Engineering 是你设计每天早上 9 点扫描失败测试。 如果发现失败创建独立 worktree。 让 agent 尝试修复。 每轮修复后运行测试。 如果测试通过生成 PR 描述。 如果连续 3 次失败写入人工待处理列表。 所有过程记录到 state.json。你会发现Loop Engineering 关注的是“系统如何自己转起来”。它不是一个 prompt而是一套闭环。四、一个标准 AI Loop 长什么样一个最小可用的 Loop 一般包含 7 个模块触发器 Trigger触发器决定什么时候启动循环。可以是人手动点一下也可以是定时任务、Webhook、CI 失败、GitHub issue 更新、Slack 消息、数据库状态变化。任务发现 DiscoveryAI 需要知道今天该干什么。比如扫描失败测试、读取未处理 issue、检查文章草稿、查看用户反馈、分析监控告警。状态存储 State循环不能失忆。它至少要知道哪些任务已完成哪些失败过失败原因是什么下一步要做什么。最简单可以用 Markdown、JSON、SQLite复杂一点可以用 Linear、Jira、数据库。执行者 Worker执行者是真正干活的 agent。它可以写代码、改文档、查资料、生成图片、运行脚本、提交结果。验证者 Evaluator验证者负责判断结果是否合格。可以是单元测试、规则检查、另一个 AI reviewer、人工审批也可以是多种方式组合。反馈机制 Feedback如果不合格要把失败原因反馈给 worker。好的反馈要具体比如“缺少边界条件测试”而不是“再优化一下”。停止条件 Stop Condition循环必须知道什么时候停。常见停止条件包括测试通过、评分达标、达到最大轮次、成本超限、出现高风险操作、需要用户确认。可以把它画成这样Trigger ↓ Discover Tasks ↓ Read State and Context ↓ Worker Executes ↓ Evaluator Checks ↓ Pass? ── Yes ── Save Result and Stop │ No ↓ Write Feedback ↓ Retry Until Max Rounds or Human Handoff这张图非常重要。新手只要记住它就已经抓住了 Loop Engineering 的骨架。五、Loop Engineering 的核心原则1. 先写停止条件再写执行逻辑很多人设计 AI 循环时第一反应是“让 AI 一直做直到做好”。这句话听起来很自然但工程上很危险。什么叫做好谁判断最多花多少钱失败几次算失败如果目标不清楚循环就会变成无限消耗 token 的机器。更好的写法是完成条件 1. 所有 pytest 测试通过。 2. 新增或更新至少 1 个相关测试。 3. git diff 中不包含无关格式化。 4. 如果连续 3 轮仍失败则停止并输出失败报告。这比“帮我修好这个 bug”可靠得多。2. 让环境给出真实反馈AI 自己说“我认为已经修好了”不算验证。真正的反馈应该来自环境测试结果、编译结果、API 响应、页面截图、数据库查询、静态扫描、用户点击路径。代码场景天然适合 Loop Engineering因为代码可以运行。比如pytest通过了吗npm test通过了吗ruff check还有报错吗页面按钮真的能点吗接口返回是否符合 schemaAI 的文字判断可以辅助但不要只靠文字判断。3. Maker 和 Checker 要分开一个常见错误是让同一个 agent 写代码又让它判断自己写得对不对。模型会倾向于相信自己的输出尤其是在复杂任务中。更稳的设计是让“执行者”和“验证者”分开Worker agent负责实现。Reviewer agent负责找 bug、缺测试、看安全风险。Test runner负责运行自动化测试。Anthropic 提到的 evaluator-optimizer 模式就是这个思想一个模型生成结果另一个模型提供评估和反馈然后进入下一轮改进。4. 状态要写到循环外部不要把所有记忆都放在聊天上下文里。上下文会被截断会过期会因为新信息太多而变混乱。长期循环需要外部状态比如{task_id:BUG-1024,status:retrying,attempts:2,last_error:test_user_login_timeout failed,next_action:inspect session timeout handling}最简单的做法是维护一个state.json。等团队规模变大再接 Jira、Linear、数据库都可以。5. 权限越大护栏越要明确Loop 可以自动运行这意味着它也可能自动犯错。尤其是涉及生产环境、数据库、云资源、账单、用户数据时一定要设置权限边界。建议从这些规则开始第一个版本只读。第二个版本允许写本地文件但不允许访问生产环境。第三个版本允许开 PR但需要人类合并。删除文件、迁移数据库、发生产请求都需要人工确认。每个循环都设置最大轮次和最大运行时间。Loop Engineering 的目标不是“完全无人值守”而是“在可控边界内自动推进”。六、动手案例用 Python 写一个最小 Loop下面这个案例不依赖任何 AI API新手可以直接复制运行。它模拟一个 AI agent 完成文章解释任务第一轮可能缺内容Evaluator 会指出问题下一轮 Worker 会根据反馈补齐直到通过检查或达到最大轮次。这个 demo 重点不是生成能力而是让你看懂 Loop Engineering 的结构任务、状态、执行、评估、反馈、停止。1. 新建文件创建一个文件loop_demo.py。importjsonfrompathlibimportPathfromdatetimeimportdatetime STATE_FILEPath(loop_state.json)MAX_ROUNDS4TASK{id:demo-001,goal:写一段给小白看的 Loop Engineering 解释,criteria:[包含触发器,包含验证者,包含停止条件,不少于 120 个中文字符]}defload_state():ifSTATE_FILE.exists():returnjson.loads(STATE_FILE.read_text(encodingutf-8))return{task_id:TASK[id],attempts:0,status:new,history:[]}defsave_state(state):STATE_FILE.write_text(json.dumps(state,ensure_asciiFalse,indent2),encodingutf-8)deffake_agent(goal,feedback,round_no): 这里模拟一个 AI worker。 真实项目中你可以把这个函数替换成 OpenAI、Claude 或本地大模型调用。 _feedback answerf目标{goal}。\nifround_no1:answerLoop Engineering 是让 AI 不只回答一次而是反复执行任务。elifround_no2:answer(Loop Engineering 是一种循环工程方法。它会用触发器启动任务让 AI 根据上下文执行操作再把结果交给验证者检查。)else:answer(Loop Engineering 是一种把 AI agent 组织成闭环的工程方法。一个循环通常从触发器开始例如定时任务、CI 失败或用户提交的 issue。随后 worker agent 读取上下文并执行操作例如修改代码、生成文档或分析日志。执行完成后验证者会根据测试、规则或人工标准判断结果是否合格。如果不合格循环会把具体反馈交还给 worker 继续修正。如果满足停止条件例如测试通过、评分达标或达到最大轮次循环就会记录状态并停止。)returnanswerdefevaluate(answer,criteria):problems[]checks{包含触发器:触发器inanswer,包含验证者:验证者inanswer,包含停止条件:停止条件inanswer,不少于 120 个中文字符:len(answer)120,}foritemincriteria:ifnotchecks.get(item,False):problems.append(f未满足{item})return{passed:len(problems)0,problems:problems,score:len(criteria)-len(problems)}defmain():stateload_state()feedbackprint(开始 Loop Engineering demo)print(f任务{TASK[goal]})forround_noinrange(1,MAX_ROUNDS1):print(f\n第{round_no}轮开始)answerfake_agent(TASK[goal],feedback,round_no)resultevaluate(answer,TASK[criteria])state[attempts]round_no state[history].append({round:round_no,time:datetime.now().isoformat(timespecseconds),answer:answer,result:result})ifresult[passed]:state[status]donesave_state(state)print(验证通过循环停止。)print(\n最终结果)print(answer)returnfeedback.join(result[problems])state[status]retryingsave_state(state)print(验证未通过)forprobleminresult[problems]:print(f-{problem})print(进入下一轮修正。)state[status]failedsave_state(state)print(\n达到最大轮次循环停止交给人工处理。)if__name____main__:main()2. 运行在命令行运行python loop_demo.py你会看到类似输出开始 Loop Engineering demo 任务写一段给小白看的 Loop Engineering 解释 第 1 轮开始 验证未通过 - 未满足包含触发器 - 未满足包含验证者 - 未满足包含停止条件 - 未满足不少于 120 个中文字符 进入下一轮修正。 第 2 轮开始 验证未通过 - 未满足包含停止条件 进入下一轮修正。 第 3 轮开始 验证通过循环停止。同时目录里会生成一个loop_state.json里面记录了每一轮的答案、评估结果和状态。这里有一个新手很容易忽略的细节反馈不能直接拼到最终答案里再交给 evaluator 检查。否则上轮反馈里出现了“停止条件”这几个字评估器可能误以为本轮答案已经满足要求。真实系统里也一样失败日志、审查意见、历史对话都要和“待验收产物”分开避免评估污染。3. 这个 demo 对应 Loop 的哪些部分Loop 模块demo 里的实现Triggermain()启动相当于手动触发TaskTASK字典Stateloop_state.jsonWorkerfake_agent()Evaluatorevaluate()Feedbackproblems转成下一轮反馈Stop Condition通过检查或达到MAX_ROUNDS你看哪怕没有接入真实大模型Loop 的工程结构已经完整了。真实项目只是把fake_agent()换成模型调用把evaluate()换成测试、lint、代码审查、页面检查等更真实的验证。七、把 demo 换成真实 AI 调用应该怎么做如果你已经有大模型 API可以把fake_agent()替换成类似这样的结构defreal_agent(goal,feedback,context):promptf 你是一个负责完成任务的 AI worker。 目标{goal}上一轮反馈{feedbackor无}当前上下文{context}请输出本轮结果。要求具体、可验证不要解释你不能做什么。 # 这里接入你使用的模型 SDK# response client.responses.create(...)# return response.output_textraiseNotImplementedError关键点不是 SDK 怎么写而是 prompt 里要带上三类信息当前目标。上一轮失败反馈。可用上下文和边界。Evaluator 也可以升级defevaluate_by_tests():# 运行 pytest、npm test、ruff、mypy 等# 根据退出码判断是否通过pass或者让另一个模型当 reviewerdefai_reviewer(answer,criteria):# 让 reviewer agent 根据标准给出 JSON 评估# 注意要求它输出结构化字段passed、problems、risk_levelpass新手建议先不要急着上复杂框架。先把这 4 个函数写清楚discover_tasks()worker_execute(task, feedback)evaluate(result)save_state(state)这 4 个函数稳定以后再考虑 LangGraph、AutoGen、CrewAI、OpenAI Agents SDK、Claude Code、Codex automations 等工具。八、实际案例 1自动修复失败单元测试假设你维护一个 Python 项目经常遇到小 bug 导致单元测试失败。以前流程是CI 失败。你打开日志。找到失败测试。把日志贴给 AI。AI 改代码。你运行测试。失败了再贴一遍。用 Loop Engineering可以设计成触发器 CI 失败或每天早上 9 点扫描 main 分支测试结果。 任务发现 读取失败测试名称、错误堆栈、最近修改的文件。 状态 state.json 记录每个失败测试已尝试几轮、最后错误、当前负责人。 执行 AI worker 只允许修改与失败测试相关的文件。 验证 运行失败测试对应的 pytest。 如果通过再运行相关模块的测试。 反馈 把新的错误堆栈、diff、测试输出反馈给 worker。 停止 测试通过则生成 PR 说明。 连续 3 次失败则停止输出人工处理报告。可以写成伪代码forfailureindiscover_ci_failures():stateload_state(failure.id)forattemptinrange(1,4):patchagent_fix_bug(failure,state.last_feedback)apply_patch(patch)test_resultrun_pytest(failure.test_name)iftest_result.passed:create_pr_summary(failure,patch)mark_done(failure.id)breakstate.last_feedbacktest_result.stderr save_state(state)else:handoff_to_human(failure,state)这里的重点是AI 不是“凭感觉说修好了”而是每一轮都被测试结果约束。测试输出就是环境反馈循环围绕反馈前进。这个案例适合从小处开始。你可以先只支持一种任务修复单个失败测试。等稳定后再扩展到多个测试、多个模块、自动开 PR、自动通知群。九、实际案例 2技术团队的 Issue 自动分拣和修复循环再看一个团队级案例。假设一个前端团队有很多 GitHub issue有 bug、有文档、有依赖升级、有用户反馈。每天早上工程师要花半小时分拣。这个过程很适合做 Loop。目标每天自动扫描新 issue判断类型和优先级。对于低风险任务比如文档错别字、简单样式 bug、依赖小版本升级可以让 AI 尝试修复。复杂任务则生成分析报告交给人工。Loop 设计Trigger 每天 9:30 自动运行或者 GitHub issue 新增时触发。 Discovery 读取过去 24 小时新增 issue。 读取标签、评论、复现步骤、相关文件。 Classifier AI 判断任务类型bug、docs、test、dependency、feature、unknown。 AI 判断风险等级low、medium、high。 State 把每个 issue 的处理状态写入 issue_loop_state.json。 Worker 如果是 low-risk docs 或简单 bug创建独立分支或 worktree让 agent 修改。 Evaluator 文档任务检查 Markdown lint。 前端任务运行单元测试和关键页面截图。 依赖升级运行测试和构建。 Reviewer 另一个 agent 审查 diff重点看是否改了无关文件。 Stop 通过则开 PR 并关联 issue。 不通过则写失败原因。 高风险任务只生成分析不自动改。为什么需要 worktree如果你让多个 AI 同时改同一个本地目录它们可能互相覆盖文件。Git worktree 的作用是给每个任务创建一个独立工作区。OpenAI Codex 的 worktrees 文档也强调worktree 可以让你在后台并行处理任务同时不打扰当前本地开发。对 Loop Engineering 来说worktree 是很关键的隔离机制。为什么需要 skills如果每次都把项目规范、测试命令、代码风格、PR 格式、发布流程写进 prompt循环会变得又长又难维护。更好的做法是把这些规则沉淀成 skill 或项目文档项目规则 1. 修改 React 组件后必须运行 npm test。 2. 样式使用 Tailwind不新增全局 CSS。 3. PR 描述必须包含问题、修改、验证三部分。 4. 不允许自动修改数据库 migration。Codex 的 Agent Skills 文档把 skill 定义为可复用工作流的作者格式它可以包含说明、脚本、参考资料和资源。放到 Loop 里skill 就是循环的长期记忆之一。为什么需要 subagents当任务复杂时让一个 agent 从头到尾全包风险会比较高。更稳的是拆成角色角色工作Triage agent判断 issue 类型、风险、优先级Worker agent实现修改Reviewer agent检查 correctness、安全、测试缺口Docs agent检查文档和说明是否清楚Codex 的 subagents 文档中提到subagent 工作流可以并行启动专门 agent并把结果汇总回一个响应。这个能力非常适合 Loop因为循环不是只有“做”还包括“查、审、证、记”。十、实际案例 3自媒体内容生产 LoopLoop Engineering 不只适合写代码。做内容也一样适合。比如你要运营 CSDN 博客想让 AI 每周帮你产出技术文章。传统方式是你每天问帮我想 10 个选题。 帮我写大纲。 帮我写正文。 帮我润色。 帮我生成摘要。这仍然是人工驱动。改成 Loop 后可以这样设计Trigger 每周一上午 10 点运行。 Discovery 收集最近一周 AI 工程、开发工具、编程框架的热门话题。 Filter 按读者价值、搜索热度、个人经验匹配度筛选 3 个选题。 Planner 为每个选题生成大纲要求包含实战案例。 Writer 生成初稿。 Evaluator 检查是否满足 1. 标题明确。 2. 文章超过 3000 字。 3. 有代码或可操作步骤。 4. 小白能看懂。 5. 没有明显虚假结论。 Rewriter 根据评估意见修改。 Stop 评分达到 85 分以上进入人工审核。这个内容 Loop 的关键不在“AI 会不会写文章”而在“你能不能把好文章的标准写成检查项”。如果标准模糊AI 会写得很热闹但没价值。如果标准明确循环就能不断接近你想要的质量。十一、新手如何从 0 到 1 搭一个 Loop下面给一个非常实用的路线不需要一上来就搞复杂系统。第 1 步选一个小任务不要从“自动开发整个项目”开始。先选一个低风险、可验证、重复出现的小任务每天总结失败测试。自动检查 Markdown 是否缺标题。自动给 PR 生成变更摘要。自动扫描 TODO 注释。自动整理报错日志。自动检查文章是否有摘要、标签和代码块。好的第一个任务应该满足三个条件经常重复。有明确完成标准。做错了不会造成严重后果。第 2 步写清楚完成标准比如“自动检查 Markdown 文章”完成标准 1. 必须有一级标题。 2. 必须有摘要。 3. 至少包含 3 个二级标题。 4. 如果是技术文章至少包含 1 个代码块。 5. 如果不满足输出具体修改建议。这一步越清楚后面的 loop 越稳。第 3 步先做只读 Loop第一版不要让 AI 自动改文件。只让它读文件、分析问题、输出报告。读取文章 - 检查规则 - 输出报告 - 保存状态只读版本跑稳定后再让它自动修改。第 4 步加状态文件哪怕只是一个小脚本也建议加state.json。它能帮你知道哪些任务已经检查过。哪些任务失败过。上次失败原因是什么。本轮是不是重复处理同一个问题。状态文件是从“脚本”升级到“循环系统”的标志。第 5 步加最大轮次一定要加MAX_ROUNDS3不要让 AI 无限重试。失败 3 次还不行就交给人工。这不是怂这是工程控制。第 6 步加真实验证能用程序判断就不要只让 AI 判断。比如文章长度程序统计。是否有标题正则检查。测试是否通过命令退出码。JSON 是否合法解析器检查。页面是否可访问HTTP 状态码。AI 适合处理语义判断程序适合处理确定性判断。两者结合Loop 才可靠。第 7 步最后再加自动触发很多新手一开始就想搞定时任务、Webhook、自动开 PR结果调试很痛苦。建议顺序是手动运行 - 本地稳定 - 只读定时 - 自动修改但人工确认 - 自动提交 PR - 更高自动化不要跳级。Loop Engineering 的成熟度应该一点点提升。十二、一个可复制的 Loop 设计模板你以后设计任何 AI Loop都可以先填这个模板Loop 名称 业务目标 触发方式 手动 / 定时 / Webhook / CI / 消息队列 / 其他 输入 需要读取哪些文件、日志、issue、网页、数据库记录 上下文 AI 需要知道哪些规则、背景、历史决策 执行者 谁来做一个 agent 还是多个 agent 可用工具 读文件 / 写文件 / shell / 浏览器 / GitHub / 数据库 / API 权限边界 允许做什么禁止做什么哪些操作需要人工确认 验证标准 测试、lint、schema、截图、AI review、人工 review 分别是什么 反馈方式 失败后把哪些信息反馈给 worker 状态存储 state.json / Markdown / SQLite / Jira / Linear / 数据库 停止条件 成功条件是什么最多几轮什么情况必须交给人 输出 报告 / diff / PR / 评论 / 通知 / 文件 风险 可能误删什么可能泄露什么可能浪费多少成本这个模板看起来很普通但它能避免 80% 的混乱。因为很多 AI 项目失败不是模型不够强而是没有人定义边界和验收。十三、Loop Engineering 常见坑坑 1目标太大“帮我自动开发一个 App”这种目标太大。Loop 很容易不知道先做什么也很难验证。应该拆成自动生成页面骨架。自动补测试。自动修 lint。自动生成接口文档。小 loop 稳定后再组合成大 loop。坑 2没有验证者只让 AI 生成不检查就不是工程。它只是自动输出。真正的 Loop 一定要有 evaluator。坑 3状态只存在聊天里聊天上下文不是长期状态。循环跑几天后你会需要明确知道每个任务到哪一步了。请尽早写状态文件。坑 4过早上生产权限刚开始不要让 AI 自动操作生产数据库、自动发版、自动合并 PR。先让它生成建议再让人确认。随着验证能力变强再逐步放权。坑 5反馈太抽象“写得不好重新写”不是好反馈。好的反馈应该是第 2 节缺少实际命令。 代码块没有说明运行环境。 没有解释失败后的处理方式。 结尾缺少总结清单。反馈越具体下一轮越容易变好。坑 6没有成本意识Loop 会重复调用模型。如果没有最大轮次、缓存、任务过滤很容易消耗大量 token。建议小模型做分类。大模型做关键推理。程序规则先过滤。只把必要上下文传给模型。失败多次就停止。十四、学习 Loop Engineering 需要掌握哪些能力新手不用一次学完所有工具但要逐步补齐这些能力基础脚本能力至少会用 Python 或 JavaScript 读写文件、调用命令、处理 JSON。测试意识知道怎么写单元测试、怎么运行测试、怎么根据退出码判断成功失败。Prompt 基础能把目标、上下文、约束、输出格式写清楚。结构化输出让 AI 输出 JSON而不是一大段自由文本。这样程序才能判断和流转。状态管理知道怎么保存任务状态、重试次数、失败原因。权限和安全意识知道哪些操作可以自动化哪些必须人工确认。逐步放权的产品思维先做助手再做半自动最后才做更高自动化。如果你是小白建议学习路线是Python 基础 ↓ JSON 和文件读写 ↓ 调用一个大模型 API ↓ 写一个 evaluator ↓ 写 state.json ↓ 加入重试和停止条件 ↓ 接入真实工具比如测试命令、GitHub issue、定时任务十五、Loop Engineering 和传统自动化有什么区别有人可能会问这不就是自动化脚本吗有相似之处但不完全一样。传统自动化适合规则非常明确的任务如果文件存在就复制。 如果测试失败就报警。 如果时间到了就执行脚本。Loop Engineering 适合中间有语义判断、计划、生成、修正的任务分析这个 bug 可能在哪。 判断这个 issue 是文档问题还是代码问题。 根据测试失败原因修改代码。 根据 reviewer 意见重写文章。 判断是否需要继续搜索资料。可以这样理解类型擅长自动化脚本确定性流程AI agent语义理解、生成、规划Loop Engineering把脚本的确定性和 agent 的灵活性组合起来最好的 Loop 往往不是“全都交给 AI”而是程序负责确定性检查。AI 负责不确定性推理。人负责高风险决策。这个组合才是可靠的。十六、一个团队落地路线图如果你在团队里推动 Loop Engineering可以按四个阶段走。阶段 1报告型 Loop只读不改东西。例子每天总结 CI 失败。每周汇总 issue 分类。每天检查新增 TODO。每次 PR 自动生成风险摘要。目标是建立信任。阶段 2建议型 LoopAI 不直接提交只生成 patch 或建议。例子为失败测试生成候选修复。为文档问题生成修改建议。为依赖升级生成风险说明。目标是让工程师看到 AI 的产出质量。阶段 3PR 型 LoopAI 可以在独立分支或 worktree 中修改代码并提交 PR但合并必须人工确认。例子自动修复 lint。自动补文档。自动升级低风险依赖。自动补简单测试。目标是节省重复劳动但保留人类控制。阶段 4受控自动化 Loop对低风险、高验证度任务自动完成。高风险任务仍然进入人工队列。例子文档错别字自动合并。格式化问题自动修复。测试快照更新需要人工确认。生产发布仍需审批。成熟团队不会追求“完全无人”而是追求“明确哪些可以无人哪些必须有人”。十七、总结Loop Engineering 的本质是把 AI 放进工程闭环最后再把重点收束一下。Loop Engineering 不是新的魔法词也不是某个固定框架。它是一种工程设计方法把 AI agent 放进一个可触发、可执行、可验证、可重试、可停止、可记录的闭环里。如果你只记住 5 句话记住这 5 句Prompt 解决一次对话Loop 解决持续工作。没有验证者的 Loop 只是自动生成不是工程闭环。状态必须写到外部不能只靠聊天上下文。停止条件要先写清楚否则循环会失控。最好的 Loop 是 AI、程序和人各做自己擅长的部分。对小白来说最好的入门方式不是先研究复杂框架而是从一个最小脚本开始一个任务、一个 worker、一个 evaluator、一个 state 文件、一个最大轮次。跑通以后你自然就会理解为什么 automations、skills、subagents、worktrees、evals 这些东西重要。未来的 AI 工程师不一定是每天手写最多 prompt 的人而是能设计好循环、边界和验证系统的人。你不只是让 AI 回答问题而是在设计一个能持续推进工作的系统。这就是 Loop Engineering 的价值。参考资料Addy Osmani《Loop Engineering》https://addyosmani.com/blog/loop-engineering/Anthropic《Building Effective AI Agents》https://www.anthropic.com/engineering/building-effective-agentsOpenAI Codex Automationshttps://developers.openai.com/codex/app/automationsOpenAI Codex Agent Skillshttps://developers.openai.com/codex/skillsOpenAI Codex Subagentshttps://developers.openai.com/codex/subagentsOpenAI Codex Worktreeshttps://developers.openai.com/codex/app/worktrees