ApexGearNode | AI 知识库

在 AI Agent 越来越像"半个员工"的今天，很多团队开始发现一个尴尬事实：提示词写得再漂亮，Agent 一旦上下文窗口爆掉，就立刻变成"失忆实习生"——昨天刚刚对齐的接口规范，今天醒来又重头来过；上周定位好的回归 bug，今天又被重新引入。

Loop Engineering（循环工程）要解决的就是这个问题。它的核心思想不是写出更牛的提示词，而是设计一个能让 Agent 自动触发、自动执行、自动修复、自动交付的闭环系统。一旦循环跑起来，Agent 就拥有了突破单次会话窗口限制的可能性——而工程师的角色，也从"提示词作者"升级为"系统设计师"。

从 Prompt Engineering 到 Loop Engineering

过去两年，绝大多数团队的工作方式可以总结为一句话：你打一段提示词，AI 帮你写一段代码。这个模式有一个致命缺陷——每一轮对话都是孤立事件。

整个过程就像你再带一个非常聪明，但是记忆只有 7 秒的实习生：你告诉他今天要修登录的 bug，他立刻给出方案；第二天你再找他，他礼貌地问"你好我是 AI 助手，请问今天要做什么"。这不是 AI 笨，而是上下文窗口不会等你。

两种范式的本质区别

Prompt Engineering 是你亲自当项目经理，Loop Engineering 是你造了一个小型 AI 研发部门。前者你必须每一轮都在场，后者你只需要设计好流程，让系统自己去驱动 Agent。

换句话说：Prompt Engineering 是手工业，Loop Engineering 是流水线。你不再亲自一口一口喂 AI，而是搭一台自动喂饭机——饭由谁做、菜怎么配、碗谁洗，都由循环自己决定。

一个完整的 Loop 需要哪些组件？

很多人误以为 Loop 就是"加个定时任务"。真正能在生产环境跑起来的 Loop，至少需要六个核心组件。少一个，循环都会在某个时间点崩塌。

loop-six-components.json

{
  "automation": "定时或事件触发，无需人工值守",
  "worktree": "为每个 Agent 分配独立工作目录",
  "skills": "项目说明书：启动、测试、规范、踩坑记录",
  "plugins": "GitHub / Linear / Slack / CI 等真实连接器",
  "sub_agents": "写、审、测试、安全角色严格分离",
  "memory": "外部 Markdown 任务看板作为长期记忆"
}

这六个组件不是可选项，而是"完整循环"的最小集合。任何一个缺失，Loop 都会退化成 Prompt 工具，逃不掉"上下文一爆就失忆"的宿命。

自动化（Automation）

第一要素是自动化。Loop 必须能够在没有人类干预的情况下被触发——可以是定时（每天凌晨巡检），可以是事件（PR 提交后自动评审），也可以是 Webhook（Linear 上的新 ticket 自动分派）。没有自动化，所有"循环"都只是写给人看的剧本。

Worktree：给每个 Agent 一间独立房间

多个 AI Agent 同时跑在同一个仓库里时，最容易上演的戏码是：一个 AI 改登录模块，另一个顺手把登录文件删了，第三个觉得代码不优雅直接重构，最后 Git diff 像案发现场。

Worktree（Git worktree）就是为了解决这个问题而存在的。每个 Agent 在自己的 worktree 里工作，互不干扰，最后由人类或更高层的 Coordinator 做合并。这相当于把"共享办公区"改造成"独立工位"，冲突从源头消失。

外部记忆：突破上下文窗口的关键

模型会忘，对话会断，上下文会爆，但是代码库不会忘，文件不会忘，任务看板不会忘。这是 Loop Engineering 最重要的一条原则：把状态外化到模型之外。

外部记忆的实现方式通常很朴素：一个或一组 Markdown 文件，作为项目级任务看板。每一轮 Agent 启动时，先读这个看板；每一轮结束时，把自己做了什么、下一步要做什么、踩过什么坑都写回看板。

task-board.md

# 当前 Sprint 任务看板

## 进行中
- [ ] LOGIN-142 修复 token 过期逻辑（@agent-b）
- [ ] API-77 重构订单查询接口（@agent-c）

## 已完成
- [x] LOGIN-138 密码校验加固（@agent-a，已合入 main）

## 已知踩坑
- 数据库迁移前必须停掉 cron 任务
- 公司内网 token 每 6 小时过期，环境变量需走 vault

千万不要让 Agent 把记忆写在聊天上下文里——那等于没写。上下文窗口一旦重置，状态立刻归零，所有"昨天想好的方案"都会变成今天的灵感碎片。

Skills：把隐性知识显性化

Skills 是项目的"说明书"，告诉 Agent 这个项目怎么启动、怎么测试、接口规范是什么、历史上踩过哪些坑。没有 Skills，Agent 每次都从零猜测，AI 一猜，老板流泪。

好的 Skills 文件通常包括：项目启动命令、单测与回归测试命令、命名规范、目录结构、关键依赖版本、典型错误排查路径。它越接近"新员工入职手册"，Loop 跑得就越稳。Skills 不是一次性写完就丢，而是 Loop 在运行中持续反哺、持续修订。

Sub Agents 分工：千万不要让写代码的 AI 自己审自己

这一条是大多数 Loop 设计者最容易踩的坑：他们让同一个 Agent 既写代码又审查代码，然后惊讶地发现 bug 永远查不出来。

这就像让学生自己批自己的试卷——Agent 会非常温柔地原谅自己，而 bug 不会。AI 写完代码后回看，常会有一种"我感觉这道题非常有灵魂，给满分不过分吧"的蜜汁自信。

Plugins 与 Connectors：让 Agent 真的能干活

很多团队的 Loop 只停留在"AI 给建议"层面：Agent 告诉你"建议创建 PR"，然后人类去点按钮。这不叫 Loop，这叫高级搜索。

真正的 Loop 必须有 Plugins 和 Connectors，让 Agent 能直接调 GitHub 创建 PR、调 Linear 更新 ticket、调 Slack 通知相关人、调 CI 跑回归。从"建议创建 PR"升级到"真的创建 PR"，是 Loop 走向生产的最关键一跃。

工程师的角色：从写提示词到设计系统

Loop 不会自动让你变成高级工程师，它只会放大你原来的水平。懂项目的人搭出 Loop 后效率暴涨，不懂项目的人搭出 Loop 后更快地制造看不懂的代码。

以前高手会写 Prompt，现在高手会设计系统。这不是文字游戏，而是责任分配的重构：AI 可以帮你干活，但不能替你负责。

老板不会问这是 Cloud 写的还是 Codex 写的，老板只会问"谁合的"，然后大家一起看向你。线上炸了，AI 没有工资可扣，只有工程师会被追责。以前你是手写 bug，现在你是批量生成 bug——效率提升了，痛苦也自动化了。

Loop 是倍速器，但方向盘必须在你手里。设计系统是你的事，承担后果也是你的事。这两件事都不能外包给 AI。

结论

Loop Engineering 不是 Prompt Engineering 的升级版，而是一套完全不同的工程范式。它要求工程师从"提示词作者"变成"系统设计师"，从"亲自指挥 Agent"变成"设计 Agent 之间的协作流程"，并最终对 Loop 的产出负全责。

下一阶段真正该研究的，不是怎么让 AI 回答得更漂亮，而是怎么让 AI 自己形成工作流，而你稳稳坐在驾驶位上——build the loop, stay the engineer。