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

一、先说结论：Loop Engineering 到底是什么？

过去两年，很多人学习 AI 的入口是"提示词工程"。大家反复研究怎么写 prompt，怎么给角色，怎么加约束，怎么让模型一步一步思考。后来大家发现，光会写 prompt 不够，因为真实工作不是一问一答，而是一串连续动作：发现问题、收集上下文、生成方案、执行修改、跑测试、看结果、继续修、直到满足条件。

这就是 Loop Engineering，也可以叫"循环工程"。

一句话解释：

Loop Engineering 是设计一个能反复驱动 AI agent 工作的闭环系统，让 AI 不只是回答一次，而是持续执行、验证、修正，并在达到目标或触发风险时停下来。

它关注的不是"这一句 prompt 怎么写得更漂亮"，而是：

• 什么时候启动 AI？
• AI 每一轮要读取什么信息？
• AI 可以调用哪些工具？
• AI 做完之后谁来检查？
• 检查不过怎么反馈？
• 最多循环多少次？
• 什么时候交给人？
• 状态记录在哪里，下一轮怎么接着上次做？

如果把 AI 当作一个实习生，Prompt Engineering 是"你怎么给他布置任务"，Context Engineering 是"你给他哪些资料"，Harness Engineering 是"你让他在哪个工位、用哪些工具、受哪些权限约束"，Loop Engineering 则是"你设计一套每天自动派活、验收、返工、归档的流程"。

所以，Loop Engineering 不是一个神秘新框架，它是一种工程思维：把一次性的 AI 对话，升级成可重复、可验证、可维护的 AI 工作流。

二、为什么现在大家开始谈 Loop Engineering？

早期用 AI 写代码，很多人是这样工作的：

1. 打开 ChatGPT、Claude、Codex 或其他 AI 工具。
2. 输入："帮我实现某某功能。"
3. 复制代码。
4. 本地运行。
5. 报错了，再把错误贴给 AI。
6. AI 再修一版。
7. 再运行，再报错，再贴。

这个过程看起来已经很智能，但仔细想想，大部分"循环"其实是人手动完成的。人负责发现错误，人负责复制日志，人负责提醒 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 个模块：

1. 触发器 Trigger

触发器决定什么时候启动循环。可以是人手动点一下，也可以是定时任务、Webhook、CI 失败、GitHub issue 更新、Slack 消息、数据库状态变化。

2. 任务发现 Discovery

AI 需要知道今天该干什么。比如扫描失败测试、读取未处理 issue、检查文章草稿、查看用户反馈、分析监控告警。

3. 状态存储 State

循环不能失忆。它至少要知道：哪些任务已完成，哪些失败过，失败原因是什么，下一步要做什么。最简单可以用 Markdown、JSON、SQLite，复杂一点可以用 Linear、Jira、数据库。

4. 执行者 Worker

执行者是真正干活的 agent。它可以写代码、改文档、查资料、生成图片、运行脚本、提交结果。

5. 验证者 Evaluator

验证者负责判断结果是否合格。可以是单元测试、规则检查、另一个 AI reviewer、人工审批，也可以是多种方式组合。

6. 反馈机制 Feedback

如果不合格，要把失败原因反馈给 worker。好的反馈要具体，比如"缺少边界条件测试"，而不是"再优化一下"。

7. 停止条件 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 还有报错吗？
• 页面按钮真的能点吗？
• 接口返回是否符合 schema？

AI 的文字判断可以辅助，但不要只靠文字判断。

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。

import json
from pathlib import Path
from datetime import datetime

STATE_FILE = Path("loop_state.json")
MAX_ROUNDS = 4


TASK = {
    "id": "demo-001",
    "goal": "写一段给小白看的 Loop Engineering 解释",
    "criteria": [
        "包含触发器",
        "包含验证者",
        "包含停止条件",
        "不少于 120 个中文字符"
    ]
}


def load_state():
    if STATE_FILE.exists():
        return json.loads(STATE_FILE.read_text(encoding="utf-8"))
    return {
        "task_id": TASK["id"],
        "attempts": 0,
        "status": "new",
        "history": []
    }


def save_state(state):
    STATE_FILE.write_text(
        json.dumps(state, ensure_ascii=False, indent=2),
        encoding="utf-8"
    )


def fake_agent(goal, feedback, round_no):
    """
    这里模拟一个 AI worker。
    真实项目中，你可以把这个函数替换成 OpenAI、Claude 或本地大模型调用。
    """
    _ = feedback
    answer = f"目标：{goal}。\n"

    if round_no == 1:
        answer += "Loop Engineering 是让 AI 不只回答一次，而是反复执行任务。"
    elif round_no == 2:
        answer += (
            "Loop Engineering 是一种循环工程方法。它会用触发器启动任务，"
            "让 AI 根据上下文执行操作，再把结果交给验证者检查。"
        )
    else:
        answer += (
            "Loop Engineering 是一种把 AI agent 组织成闭环的工程方法。"
            "一个循环通常从触发器开始，例如定时任务、CI 失败或用户提交的 issue。"
            "随后 worker agent 读取上下文并执行操作，例如修改代码、生成文档或分析日志。"
            "执行完成后，验证者会根据测试、规则或人工标准判断结果是否合格。"
            "如果不合格，循环会把具体反馈交还给 worker 继续修正。"
            "如果满足停止条件，例如测试通过、评分达标或达到最大轮次，循环就会记录状态并停止。"
        )

    return answer


def evaluate(answer, criteria):
    problems = []

    checks = {
        "包含触发器": "触发器" in answer,
        "包含验证者": "验证者" in answer,
        "包含停止条件": "停止条件" in answer,
        "不少于 120 个中文字符": len(answer) >= 120,
    }

    for item in criteria:
        if not checks.get(item, False):
            problems.append(f"未满足：{item}")

    return {
        "passed": len(problems) == 0,
        "problems": problems,
        "score": len(criteria) - len(problems)
    }


def main():
    state = load_state()
    feedback = ""

    print("开始 Loop Engineering demo")
    print(f"任务：{TASK['goal']}")

    for round_no in range(1, MAX_ROUNDS + 1):
        print(f"\n第 {round_no} 轮开始")

        answer = fake_agent(TASK["goal"], feedback, round_no)
        result = evaluate(answer, TASK["criteria"])

        state["attempts"] = round_no
        state["history"].append({
            "round": round_no,
            "time": datetime.now().isoformat(timespec="seconds"),
            "answer": answer,
            "result": result
        })

        if result["passed"]:
            state["status"] = "done"
            save_state(state)
            print("验证通过，循环停止。")
            print("\n最终结果：")
            print(answer)
            return

        feedback = "；".join(result["problems"])
        state["status"] = "retrying"
        save_state(state)

        print("验证未通过：")
        for problem in result["problems"]:
            print(f"- {problem}")
        print("进入下一轮修正。")

    state["status"] = "failed"
    save_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 里的实现
Trigger	main() 启动，相当于手动触发
Task	TASK 字典
State	loop_state.json
Worker	fake_agent()
Evaluator	evaluate()
Feedback	problems 转成下一轮反馈
Stop Condition	通过检查或达到 MAX_ROUNDS

你看，哪怕没有接入真实大模型，Loop 的工程结构已经完整了。真实项目只是把 fake_agent() 换成模型调用，把 evaluate() 换成测试、lint、代码审查、页面检查等更真实的验证。

七、把 demo 换成真实 AI 调用应该怎么做？

如果你已经有大模型 API，可以把 fake_agent() 替换成类似这样的结构：

def real_agent(goal, feedback, context):
    prompt = f"""
    你是一个负责完成任务的 AI worker。

    目标：
    {goal}

    上一轮反馈：
    {feedback or "无"}

    当前上下文：
    {context}

    请输出本轮结果。要求具体、可验证，不要解释你不能做什么。
    """

    # 这里接入你使用的模型 SDK
    # response = client.responses.create(...)
    # return response.output_text
    raise NotImplementedError

关键点不是 SDK 怎么写，而是 prompt 里要带上三类信息：

1. 当前目标。
2. 上一轮失败反馈。
3. 可用上下文和边界。

Evaluator 也可以升级：

def evaluate_by_tests():
    # 运行 pytest、npm test、ruff、mypy 等
    # 根据退出码判断是否通过
    pass

或者让另一个模型当 reviewer：

def ai_reviewer(answer, criteria):
    # 让 reviewer agent 根据标准给出 JSON 评估
    # 注意要求它输出结构化字段：passed、problems、risk_level
    pass

新手建议先不要急着上复杂框架。先把这 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 导致单元测试失败。以前流程是：

1. CI 失败。
2. 你打开日志。
3. 找到失败测试。
4. 把日志贴给 AI。
5. AI 改代码。
6. 你运行测试。
7. 失败了再贴一遍。

用 Loop Engineering，可以设计成：

触发器：
CI 失败，或每天早上 9 点扫描 main 分支测试结果。

任务发现：
读取失败测试名称、错误堆栈、最近修改的文件。

状态：
state.json 记录每个失败测试已尝试几轮、最后错误、当前负责人。

执行：
AI worker 只允许修改与失败测试相关的文件。

验证：
运行失败测试对应的 pytest。
如果通过，再运行相关模块的测试。

反馈：
把新的错误堆栈、diff、测试输出反馈给 worker。

停止：
测试通过则生成 PR 说明。
连续 3 次失败则停止，输出人工处理报告。

可以写成伪代码：

for failure in discover_ci_failures():
    state = load_state(failure.id)

    for attempt in range(1, 4):
        patch = agent_fix_bug(failure, state.last_feedback)
        apply_patch(patch)

        test_result = run_pytest(failure.test_name)

        if test_result.passed:
            create_pr_summary(failure, patch)
            mark_done(failure.id)
            break

        state.last_feedback = test_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：自媒体内容生产 Loop

Loop 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 注释。
• 自动整理报错日志。
• 自动检查文章是否有摘要、标签和代码块。

好的第一个任务应该满足三个条件：

1. 经常重复。
2. 有明确完成标准。
3. 做错了不会造成严重后果。

第 2 步：写清楚完成标准

比如"自动检查 Markdown 文章"：

完成标准：
1. 必须有一级标题。
2. 必须有摘要。
3. 至少包含 3 个二级标题。
4. 如果是技术文章，至少包含 1 个代码块。
5. 如果不满足，输出具体修改建议。

这一步越清楚，后面的 loop 越稳。

第 3 步：先做只读 Loop

第一版不要让 AI 自动改文件。只让它读文件、分析问题、输出报告。

读取文章 -> 检查规则 -> 输出报告 -> 保存状态

只读版本跑稳定后，再让它自动修改。

第 4 步：加状态文件

哪怕只是一个小脚本，也建议加 state.json。它能帮你知道：

• 哪些任务已经检查过。
• 哪些任务失败过。
• 上次失败原因是什么。
• 本轮是不是重复处理同一个问题。

状态文件是从"脚本"升级到"循环系统"的标志。

第 5 步：加最大轮次

一定要加：

MAX_ROUNDS = 3

不要让 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 需要掌握哪些能力？

新手不用一次学完所有工具，但要逐步补齐这些能力：

1. 基础脚本能力

至少会用 Python 或 JavaScript 读写文件、调用命令、处理 JSON。

2. 测试意识

知道怎么写单元测试、怎么运行测试、怎么根据退出码判断成功失败。

3. Prompt 基础

能把目标、上下文、约束、输出格式写清楚。

4. 结构化输出

让 AI 输出 JSON，而不是一大段自由文本。这样程序才能判断和流转。

5. 状态管理

知道怎么保存任务状态、重试次数、失败原因。

6. 权限和安全意识

知道哪些操作可以自动化，哪些必须人工确认。

7. 逐步放权的产品思维

先做助手，再做半自动，最后才做更高自动化。

如果你是小白，建议学习路线是：

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：建议型 Loop

AI 不直接提交，只生成 patch 或建议。

例子：

• 为失败测试生成候选修复。
• 为文档问题生成修改建议。
• 为依赖升级生成风险说明。

目标是让工程师看到 AI 的产出质量。

阶段 3：PR 型 Loop

AI 可以在独立分支或 worktree 中修改代码，并提交 PR，但合并必须人工确认。

例子：

• 自动修复 lint。
• 自动补文档。
• 自动升级低风险依赖。
• 自动补简单测试。

目标是节省重复劳动，但保留人类控制。

阶段 4：受控自动化 Loop

对低风险、高验证度任务自动完成。高风险任务仍然进入人工队列。

例子：

• 文档错别字自动合并。
• 格式化问题自动修复。
• 测试快照更新需要人工确认。
• 生产发布仍需审批。

成熟团队不会追求"完全无人"，而是追求"明确哪些可以无人，哪些必须有人"。

十七、总结：Loop Engineering 的本质是把 AI 放进工程闭环

最后再把重点收束一下。

Loop Engineering 不是新的魔法词，也不是某个固定框架。它是一种工程设计方法：把 AI agent 放进一个可触发、可执行、可验证、可重试、可停止、可记录的闭环里。

如果你只记住 5 句话，记住这 5 句：

1. Prompt 解决一次对话，Loop 解决持续工作。
2. 没有验证者的 Loop 只是自动生成，不是工程闭环。
3. 状态必须写到外部，不能只靠聊天上下文。
4. 停止条件要先写清楚，否则循环会失控。
5. 最好的 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-agents
• OpenAI Codex Automations：https://developers.openai.com/codex/app/automations
• OpenAI Codex Agent Skills：https://developers.openai.com/codex/skills
• OpenAI Codex Subagents：https://developers.openai.com/codex/subagents
• OpenAI Codex Worktrees：https://developers.openai.com/codex/app/worktrees