你还在手动喂AI吗？2026年最值得了解的Loop Engineering
Loop Engineering 的核心是让开发者从”提示者”变成”系统设计者”——设计触发器、目标、验证机制和预算控制，让 Agent 在循环中自主完成任务，而不是一条一条地手动喂提示。
基本信息
- 来源类型：文章
- 原文位置：raw/articles/2026-06-22-192139-tg-be99a9.md
- 原文 URL：https://www.woshipm.com/ai/6416553.html
- 消化日期：2026-06-22
核心观点
-
Loop Engineering 的本质是角色转变：开发者从”提示者”（逐条推动 AI）变成”系统设计者”（搭建框架让 AI 自驱动）。Boris Cherny（Anthropic Claude Code 负责人）原话：“我已经不再直接提示 Claude 了，我的工作是写 loops。“——来源：2026-06-22-loop-engineering-woshipm
-
一个 Loop 的六个核心模块：触发器（Trigger）、目标设定（Goal）、工具调用（Tools）、记忆与上下文（Memory & Context）、验证机制（Evaluator）、预算控制（Budget）。其中目标设定是”最重要的一块，没有之一”，好目标的唯一标准是”可以被验证”——来源：2026-06-22-loop-engineering-woshipm
-
执行者和验证者必须分开：让同一个 Agent 既做事又评价自己质量会导致”自产自销”盲点。正确做法是 Generator（执行者）和 Evaluator（评判者）分离，Evaluator 可以是另一个 Agent 或确定性程序（如跑测试看通过率）——来源：2026-06-22-loop-engineering-woshipm
-
Loop Engineering ≠ 定时脚本：定时脚本跑固定逻辑（条件A→动作B），Loop 里跑的是 Agent，每次根据当前状态自己判断下一步（继续/重试/回滚/停下来）。“脚本是死的，Agent 是活的”——这个区别在 2025 年底模型能力跨过门槛后才真正可行——来源：2026-06-22-loop-engineering-woshipm
-
三个最典型场景：CI 自动修复（目标最清晰，最适合入门）、PR 自动审查（目标较软性，Evaluator 需要具体 rubric）、复杂任务自动重构（最接近自主工作，也最容易出问题）。三个场景的难度递增，对上下文管理和预算控制的要求也递增——来源：2026-06-22-loop-engineering-woshipm
-
三个新手常踩的坑：目标写得太模糊（“做好”不是目标，“测试全过”才是）；没设退出条件（Agent 陷入死循环烧钱）；上下文管理不做靠 Agent 自己记（长任务会”失忆”做出前后矛盾决策）。解法是主动管理上下文——把背景、决策、步骤写进文件让 Agent 每次读取——来源：2026-06-22-loop-engineering-woshipm
实操内容保留
Loop 六模块设计清单
- 触发器：明确什么事件启动循环（PR 提交 / CI 报错 / 定时 / 手动指令），条件要尽量精确避免不必要触发
- 目标设定：必须可验证，硬标准（测试通过/CI变绿）优于软标准（Agent评判）
- 工具调用：先给最小必要工具集，跑稳了再扩展；权限越大出错影响越大
- 记忆与上下文：用文件（如 CLAUDE.md）存储项目背景、规范、历史决策，不让 Agent 靠”记忆”
- 验证机制：执行 Agent 和验证 Agent 分开，避免自产自销
- 预算控制：设最大重试次数、最大花费上限、最大运行时间；超出边界停止并通知人工介入
Generator-Evaluator-Loop 三角色结构
Generator（执行者）产出结果
↓
Evaluator（评判者）对照目标检查
↓
未达标 → 把反馈传回 Generator 重新来
达标 → 循环结束
场景一：CI 自动修复（入门推荐）
- 触发器：CI 流水线跑挂
- 目标：CI 重新变绿
- Generator：读取报错 → 定位问题 → 修改代码 → 提交
- Evaluator：CI 本身（绿=结束，红=传回新报错继续修）
- 优势：目标极其清晰，完全客观标准
场景二：PR 自动审查
- 触发器：新 PR 提交
- 目标：找出代码问题并给出审查意见
- Generator：读取 PR 改动 + 项目规范 → 生成审查评论
- Evaluator：另一个 Agent 判断评论是否有实质内容
- 难点：目标较软性，需要具体评判 rubric
场景三：复杂任务自动重构
- Generator：大任务拆小步骤 → 逐个执行
- Evaluator：每步检查一次
- 全部通过 → Loop 结束通知人工 review
- 风险：任务越复杂，分叉越多，对上下文和预算要求越高
关键概念
- Loop Engineering — 核心概念，本文主要讨论对象
- Claude Code — Boris Cherny 负责的产品，Loop Engineering 的实践平台
- Agent Harness — Loop 的触发器+目标+工具+记忆+验证+预算构成的 Agent 运行框架
- 上下文工程 — Loop 中记忆与上下文模块的核心工程问题
- Agentic Workflow — Loop Engineering 是 Agentic Workflow 的一种具体实现模式
与其他素材的关联
- 与 2026-06-17-ai-agent-工程完全指南 的关系：工程指南从宏观视角讲 Agent 工程的环境瓶颈和多 Agent 拆分误区，本文从微观视角给出单个 Loop 的六模块设计框架，两者互补
- 与 2026-06-17-ai-skill-workflow-封装 的关系：Skill 封装是把重复流程固化为可复用资产，Loop Engineering 是让 Agent 在循环中自主执行；Skill 可以作为 Loop 中 Generator 的工具集组成部分
- 与 2026-06-03-claude-code-multi-agent-accounting 的关系：会计自动化的 5 Agent 顺序管道就是 Loop Engineering 的一个实例——数据准备→分类→对账→报告→洞察，每步有隐含的 Evaluator 检查
原文精彩摘录
Anthropic 内部负责 Claude Code 的负责人 Boris Cherny，最近在一次采访里说了一句让很多开发者觉得”被说中了”的话：“我已经不再直接提示 Claude 了，我的工作是写loops。“这句话在开发者社区里迅速传开，Google 工程师 Addy Osmani 随后给这个模式起了个名字：Loop Engineering。
定时脚本跑的是固定逻辑，条件A触发动作B，永远如此。而 Loop Engineering 里面跑的是一个 Agent，它每次都会看当前的状态，自己判断下一步该做什么——继续、重试、回滚，还是停下来告诉你”这个我搞不定”。脚本是死的，Agent 是活的。这是本质区别。
没有预算控制的 Loop，一旦 Agent 陷入某种错误循环——比如它一直在尝试修一个它根本修不了的 bug——就会一直跑下去，直到你的账单让你清醒。设定预算不是小气，是负责任。