打开 Google Trends，搜索"Agent Loop"。
全球和美国的曲线，从 2025 年底就开始缓慢爬升，今年 4 月达到峰值。
中国的曲线不一样。它在 0 附近趴了整整一年，然后在最近几周几乎垂直地冲到了 100。
这种形状通常意味着：一个已经在海外沉淀了一段时间的概念，刚刚开始在国内扩散。
这篇文章，就来说清楚这个概念。
一句话引爆了讨论
6 月初，Google Chrome 工程负责人 Addy Osmani 写了一篇博客，里面引用了 Anthropic Claude Code 负责人 Boris Cherny 的一句话：
我不再提示 Claude 了。我有 Loop 在运行，这些 Loop 负责提示 Claude 并决定做什么。我的工作是写 Loop。(I don’t prompt Claude anymore. I have Loops running that prompt Claude and figuring out what to do. My job is to write Loops.)
这句话在推特上迅速扩散。不是因为它描述了一项新技术，而是因为它说出了一个很多人隐约感觉到但还没清晰表达过的东西——Agent Loop。
Agent Loop 是什么
Agent Loop 是 AI 智能体（Agent）工作的核心机制，一个反复执行的循环：
接收目标 → 思考下一步 → 调用工具 → 观察结果 → 再思考 → 再行动……
直到任务完成，或者遇到无法解决的问题。
这个概念本身不新。真正新的，是 Loop Engineering 这个说法——它描述的是一种工作方式的转变：
- 之前：你写一句提示词，AI按照提示词执行，你一轮一轮地手动推进AI完成任务。
- 现在：你设计一个系统，让这个系统自动去提示 AI，处理结果，决定下一步。你是系统设计者，AI 是被系统驱动的执行者。
你从"拿着工具教AI干活的人"，变成了"设计工具和系统驱动AI干活的人"。
我们是怎么到这里的
理解 Loop Engineering，需要先看它是怎么一步步演化过来的。
Prompt Engineering（2022-2023）
模型弱、上下文小，一次对话就是一个任务。核心工作是把你的意图翻译成模型能听懂的语言。Chain-of-thought、few-shot、zero-shot，本质都是在优化这个翻译过程。人全程在场，每一轮手动驱动。
Agentic Workflow Design（2023-2024）
Andrew Ng 在这个阶段提出了智能体工作流的四个模式：反思（Reflection）、工具使用（Tool Use）、规划（Planning）、多智能体协作（Multi-Agent）。人们开始思考如何把多个步骤串成一条流水线，而不只是优化单次对话。这是"设计流程"意识的起点，但执行还是单次的、人来触发的。
Context Engineering（2024）
模型变强，窗口变大，人们发现瓶颈不再是"怎么说"，而是"塞进去什么信息"。RAG、记忆管理、结构化上下文注入——本质是在解决"让模型在正确的信息上工作"的问题。人还是在流程中，但从"写指令"退到了"管理信息流"。
Agent Harness Engineering（2024 末-2026 初）
光设计流程还不够，你还得给 Agent 搭一个能稳定运行的"脚手架"：工具集、权限边界、错误处理、重试机制。这个阶段的核心问题是"怎么让单个 Agent 可靠地跑完一个任务"。Harness 解决的是稳定性，但还是一次性的——你触发一次，跑完就结束了。
Loop Engineering（2026）
工具调用成熟了，harness 也搭好了，真正的瓶颈变成：还需要一个人坐在那里一轮一轮地触发、验证任务吗？ 答案开始变成"不需要了"。Loop Engineering 就是在 harness 上面再加一层——让 harness 自己定时跑、自己发现工作、自己决定下一步。人从"驱动者"退成了"系统设计者"。Addy Osmani 的原话是：Loop engineering sits one floor above the harness. The harness but it runs on a timer, it spawns little helpers, and it feeds itself（Loop 是"在 harness 楼上一层的 harness，但它跑在定时器上，会自己生出小助手，会给自己喂数据"）。
逻辑一脉相承：瓶颈在哪，工程优化就在哪。 每一步都在把人往更高的抽象层推。
Loop 的五个组件
Addy Osmani 在博客里把一个 Loop 拆成五个要素，外加一个"记忆"。我按算法工程师最容易理解的方式来翻译：
① Automations（心跳）
定时触发的任务，负责"发现工作"。你不去找活儿，Loop 自己扫描环境——比如每天早上自动读昨天的 CI 失败、新增的 issue、最近的 commit，汇总出一份 triage 报告送到你手里。
② Worktrees（隔离）
多个 Agent 并行工作时，用 git worktree 给每个 Agent 一个独立的工作目录，防止互相影响。没有这个，两个 Agent 同时写同一个文件，冲突处理会把省下来的时间全还回去。
③ Skills（知识沉淀）
把项目上下文写成 SKILL.md——规范、构建方式、"这里不能这么做是因为那次事故"。Agent 每次运行都能读到，而不是每次从零重新推导你的项目。没有 Skills，Loop 每个周期都在重新发明轮子。
④ Plugins & Connectors（触手）
通过 MCP 连接真实工具——issue tracker、数据库、Slack。让 Loop 能在你的实际工作环境里行动，而不只是"告诉你它会怎么做"。有了这个，Loop 才能真正开 PR、更新 ticket、通知 Slack——不是模拟，是真做。
⑤ Sub-Agents（制衡）
写代码的 Agent 和审查代码的 Agent 必须分开。 让同一个模型给自己打分，它会给满分。一个 Agent 写代码，另一个 Agent 来验证——这是 Loop 在自动运行时能被信任的核心原因。
+持久化记忆
模型长时间运行会忘事，状态必须存到外部——一个 markdown 文件就够——记录"什么做了、什么没做、什么失败了"。下次运行接着来。
一个具体的 Loop 长什么样
把五个组件拼在一起，一个实际的 Loop 是这样运转的：
定时任务（每天早上）
└─ 调用 triage skill
└─ 扫描 CI 失败 + issue + 新 commit
└─ 写入 state 文件
└─ 对每个发现的问题：
├─ 开一个独立 worktree
├─ Agent-A 起草修复
├─ Agent-B 验证（对照 skill 和测试）
└─ 通过 → 开 PR + 更新 ticket + Slack 通知
失败 → 写入 triage inbox，等人处理
你设计它一次，然后它每天早上自己跑。你不再提示任何一个步骤。
当然，前几周你大概率还是得盯着它——loop 在磨合期会遇到各种奇怪的失败，很多是你设计时没想到的边界情况。真正能放手走开，需要一段时间建立信任。
它没解决什么
Loop engineering 很强，但有几件事它现在还做不到：
目标还是人定的。 你给 Loop 一个停止条件，但这个条件写对写错，完全是人的责任。目标定错了，Loop 会非常高效地把事情搞错。
验证还是粗糙的。 现在的 checker Agent 能验"测试通过"，但验证不了"这个方案三个月后会不会还能行"。
理解债在积累。 Loop 跑得越顺，你越不用理解它写的代码。Addy Osmani 把这个叫做 comprehension debt——如果你只是按下 go 然后 merge，你的系统认知会以 Loop 的速度衰减。
对算法工程师意味着什么
算法工程师其实对 loop 的底层结构不陌生——你写过训练循环，设计过 eval 指标，做过 pipeline 调度。loop engineering 的核心问题和这些是同构的：定义什么叫"完成"，并且设计一个能验证这件事的机制。
具体来说，有三件事可以现在就做：
找到你每周手动重复的一件事。 不用从复杂的开始。一个每天要手动跑的数据检查脚本，一个每周要整理的 issue 列表——把它的触发条件、执行步骤、验收标准写清楚，就是第一个 loop spec。
把你的项目知识写成 SKILL.md。 你的模型训练规范、数据格式约定、常见报错的处理方式——这些现在可能只在你脑子里。写下来，agent 才能在你不在场时做出跟你一样的判断。
设计 checker，不只是执行者。 这对算法工程师来说应该很自然：你不会只看 loss 曲线就说模型好，你会跑 eval。loop 里的 checker agent 就是这个角色——不要让做事的那个 agent 给自己的工作打分。
不是每个任务都适合 loop，也不是越自动化越好。有些事情你手动做一遍，比设计一个系统快得多。loop 适合的是那种你已经把流程想清楚了、只是不想每次亲自动手的事情。
粤ICP备14082021号
免费POC，
零成本试错
