跳到正文
  1. 首页
  2. 知识库
  3. Loop Engineering 深度解析与落地实践
← 知识库目录 更新:2026-07-03 · AI Engineering · Agent 方法论
Loop Engineering

Loop Engineering 深度解析与落地实践

AI Agent 的杠杆点正在从“写一个好 prompt”迁移到“设计一个会持续发现、执行、验证、记忆并停止的工作循环”。Loop Engineering 不是让人退出工程,而是把人的判断前移到目标、环境、验证和边界设计里。

Loop Engineering 的闭环结构 VERIFY or stop Trigger Goal Memory Budget

核心结论

Prompt 不是消失,而是下沉。Prompt 仍然重要,但它不再只是人每轮手写的指令,而会被封装到 skill、goal、eval、automation 和 loop spec 里。
Loop 的本质是可复用工作制度。一个 loop 至少需要触发器、目标、验证、停止规则和外部记忆;否则只是一次更长的 agent 会话。
人的工作变成设计边界。你不再逐步催 agent 做事,而是设计目标、环境、权限、成本、验收标准和人工介入点。

如果把传统 prompt engineering 比作“给实习生写一条清楚的任务消息”,Loop Engineering 更像是“为一个小团队设计岗位、流程、检查机制和交付标准”。它让 AI Agent 能够自己发现工作、拆分任务、调用工具、验证结果、更新状态,并在满足条件时停止。

什么是 Loop Engineering

Loop Engineering 是围绕 Agent 构建长期、可重复、可验证工作循环的工程实践。Addy Osmani 将它描述为:人不再作为反复提示 agent 的那个人,而是设计一个替你提示 agent 的系统。这个系统会发现工作、派发工作、检查结果、写下状态,并决定下一步。

arXiv 论文《Stop Hand-Holding Your Coding Agent》给了更形式化的定义:loop specification 是一个有边界、可复用的 artifact,由 triggergoalverification stepstopping rulememory 组成,交给 Claude Code、Codex 等 agent harness 后,让 agent 自主追求目标,而不是依赖人一步步提示。

关键区分:Loop Engineering 不是普通编程语言里的 for/while 循环,也不是 agent harness 内部自带的 perceive-act-observe 循环。它是更外层的工作制度:什么时候启动、目标是什么、怎么验收、什么时候停止、状态写在哪里。

层级核心问题典型产物
Prompt这一次该怎么让模型回答好?一段指令、few-shot 示例、输出格式
Context模型需要知道哪些背景?文档、代码片段、数据、约束
Harness模型在哪个环境里行动?工具、权限、文件系统、测试命令、浏览器
Loop系统如何持续发现、执行、验证并记忆?自动化、goal、worktree、sub-agent、状态文件、停止条件

一个合格 Loop 的组成

实践上,可以把 Loop Engineering 拆成十个零件。少一个也能跑,但越缺关键件,越容易变成“很会消耗 token 的自动化”。

组件作用落地例子
Trigger决定什么时候启动每天 7:30、CI 失败、PR 打开、用户反馈新增
Goal定义要达成的结果修复失败测试、整理竞品周报、生成发布检查
Context / Skill减少每次重新解释项目SKILL.md、AGENTS、代码规范、业务语义层
Harness提供 agent 可行动的环境仓库、shell、浏览器、数据库、Figma、Gmail、GitHub
Worktree / Isolation防止并行 agent 互相踩文件每个任务独立 git worktree 和分支
Tools / Connectors让 loop 触达真实系统MCP、GitHub、Linear、Slack、数据库、VPS
Sub-agents把作者和审阅者分开实现 agent、代码审阅 agent、安全审阅 agent
Verification判断结果是否可信测试、lint、eval、人工抽检、业务指标
Stopping Rule防止无限循环和虚假完成所有测试通过、预算耗尽、连续三次同类失败
Memory / State跨运行保存进展Markdown 状态文件、issue、Linear board、数据库表

验证阶梯

Loop 的危险不在于它会做错一次,而在于它会在无人看守时重复做错。因此验证不应只靠模型自信地说“完成了”。我建议用五层验证阶梯:

  1. 自检层:agent 按 checklist 自查,适合低风险文本任务。
  2. 第二视角层:maker 与 checker 分离,用另一个 agent 审阅。
  3. 可执行层:测试、lint、类型检查、数据校验、eval 集通过。
  4. 环境层:在隔离环境、staging、worktree 或沙箱里验证。
  5. 业务层:上线后通过用户行为、错误率、成本和质量指标闭环。

六种高价值 Loop 模式

1. 代码维护 Loop

每天读取 CI、issue、最近 commits,识别可修复问题,创建隔离 worktree,交给实现 agent,再由审阅 agent 检查,最后把可合并结果交给人确认。

2. 研究情报 Loop

定期搜索指定主题,抓取新论文、新闻和竞品动态,生成结构化摘要,写入知识库,并标记需要人工判断的信号。

3. AI Eval Loop

收集生产失败样本,开放编码分类,更新 eval 集,跑不同模型和提示词版本,输出质量与成本对比。

4. 用户反馈 Loop

把客服、销售、社区、使用日志合并成反馈数据库,按用户痛点、频率、严重程度和付费影响排序,进入路线图讨论。

5. 发布质量 Loop

发布前自动检查 PQL:元数据、链接、图片、性能、埋点、权限、回滚方案和公开 URL 读回。

6. 个人 PM 助理 Loop

定期读取项目状态、会议纪要和待办,整理决策缺口、阻塞项和需要向上管理的事项,帮助 PM 保持项目“有心跳”。

落地实践:Loop Spec 模板

Loop Engineering 最重要的产物不是一大段 prompt,而是一份可复用的 loop spec。它要让另一个人也能理解:这个 loop 什么时候跑、做什么、不能做什么、怎样算完成、失败了怎么办。

# Loop Spec: 每日 AI 研究情报整理

## Trigger
- 每天 08:30 自动运行
- 手动触发:当用户说“刷新 Loop Engineering / Agent 资料”

## Goal
- 搜索过去 7 天 Agent / Loop Engineering / AI eval 相关资料
- 产出 5 条高价值信号、3 条行动建议、1 个待验证假设

## Context
- 使用本项目的 AI 方法论文章风格
- 输出简体中文
- 优先官方文档、论文、作者原文、可信媒体

## Allowed Actions
- 浏览公开网页
- 读取本地知识库
- 生成 Markdown 摘要

## Disallowed Actions
- 不发布
- 不修改线上页面
- 不引用无法打开的二手摘要作为事实

## Verification
- 每条关键事实至少有来源链接
- 明确区分事实、推断和建议
- 检查日期是否为过去 7 天

## Stopping Rule
- 找到至少 5 条相关信号,或连续 3 轮搜索无新增
- token 预算超过上限时停止并报告缺口

## Memory
- 写入 knowledge/agent-research-log.md
- 记录已看过的链接、结论和待复查项

## Terminal States
- complete: 摘要完成且来源齐全
- partial: 资料不足但有可用结论
- blocked: 需要登录、付费墙或用户确认

落地原则:先做低风险、可读回、可人工确认的 loop。比如资料整理、CI 摘要、HTML 链接检查、发布前 metadata 检查。等验证机制成熟后,再让 loop 进入写代码、部署、发邮件、改数据库这些高风险动作。

风险与反模式

反模式表现修正
无停止条件agent 一直尝试、一直改、一直消耗设置完成、部分完成、阻塞、预算耗尽等终态
自己批改自己写代码的模型也负责判定完成maker / checker 分离,引入可执行验证
外部记忆缺失每次运行都从零开始猜项目状态维护状态文件、issue 或 Linear board
工具权限过宽loop 能删除、部署、发送或改生产数据最小权限、人工确认、隔离环境
理解债务代码或内容增长很快,人却不理解要求摘要、diff review、架构说明和定期复盘
认知投降人把判断外包给 loop,只负责按确认保留人工目标设定、风险判断和验收责任
奖励黑客agent 为了通过指标绕开真实目标组合业务指标、人工抽检和对抗样本
成本失控sub-agent、长上下文和重试吞掉预算预算阈值、模型分层、低风险任务用低成本模型

最危险的错觉:Loop 不是“无人驾驶工程”。它只是把人从每一步提示里释放出来,让人能把精力放在制度设计、验证体系和关键判断上。越自动化,越需要清晰边界。

90 天落地路线图

第 0-30 天:从重复任务开始

  • 选择一个低风险任务:资料整理、CI 摘要、发布前检查、反馈归类。
  • 写第一份 loop spec,明确 trigger、goal、verification、stopping rule、memory。
  • 先手动运行 5 次,记录失败模式。

第 31-60 天:引入隔离和验证

  • 将写作/代码类任务放进独立 worktree 或沙箱。
  • 加入 maker / checker 双 agent。
  • 把结果写入状态文件,形成跨运行记忆。
  • 建立成本日志:token、工具调用、失败重试、人工修正时间。

第 61-90 天:产品化 loop

  • 把高频 loop 封装成 skill 或模板。
  • 接入真实工具:GitHub、Linear、文档、数据源、部署目标。
  • 定义组织级 PQL:哪些任务允许自动完成,哪些必须人工确认。
  • 每月复盘 loop 的 ROI、质量、风险和理解债务。

参考资料

按同一标的、主题与系列自动关联。