别再只写 Prompt 了：AI Agent 的下一站是 Loop Engineering

公众号名称：阿南的技术手记

作者名称：j5land

发布时间：2026-06-16 18:27

Prompt 不是消失了，而是从一次性交互，变成了闭环系统里的一个零件。

Prompt Engineering 没有消失，但它正在降级为系统工程的一部分。

真正重要的能力，正在从怎么问 AI，转向怎么设计一个会反复逼近正确结果的系统。

unsetunset你就是那个 Loopunsetunset

我们使用 Coding Agent 的方式大多是这样的，或许现在就是

你写 prompt，Agent 生成代码

你读代码，发现问题，你再补充上下文

Agent 再改，你再检查

接口测试失败了，你把报错贴回去

实现偏了，你再解释一遍需求，纠正Agent的方向

看起来是 Agent 在帮你干活，但从控制论角度看，真正的反馈回路是你

你负责发现问题，你负责决定下一步，你负责验证结果，你负责判断什么时候该停

Agent 只是这个循环里的执行器

Loop Engineering 要改变的正是这一点

把原本由人手工驱动的反馈循环，变成一个可运行、可复用、可验证的工程系统。

Prompt 解决的是一次输出，Loop 解决的是持续逼近正确结果

这句话很关键，单次 prompt 的目标是给我一个答案，Loop 的目标是“在约束内持续尝试，直到满足停止条件”

unsetunset什么是 Loop Engineeringunsetunset

可以先给一个朴素定义：

Loop Engineering 是设计可重复反馈循环的实践。它让 AI Agent 在明确目标、上下文、动作边界、验证标准和停止条件下，自动经历发现、计划、执行、检查、修正，直到产出被验证过的结果。

它不是一个新工具名，也不是某个模型能力的别名。它更接近软件工程中的工作流设计。

一个简单的 Coding Loop 可以画成这样：

人先给目标和边界，Agent 读取上下文、制定计划、改代码、跑测试和 lint。验证失败就修，验证通过就总结并停止。

注意这里的关键不是“让 Agent 多跑几次”。关键是每一轮都有明确输入、动作、反馈和停止条件。

如果没有验证，它只是自动重复

如果没有停止条件，它只是烧 token

如果没有外部状态，它下一轮可能忘记上一轮做过什么

unsetunset一个好 Loopunsetunset

一个可工作的 loop 通常包含五个阶段

**Discover：发现问题。**Agent 先搞清楚当前状态：需求是什么，代码在哪里，失败日志是什么，已有约束有哪些。

**Plan：制定计划。**把目标拆成可执行步骤。计划不需要华丽，但必须能被检查。比如“先修 parser，再补测试，最后跑 npm test”就比“优化代码”可靠得多。

**Execute：执行动作。**修改代码、写测试、查资料、调用工具、更新文档。这个阶段最像传统意义上的 Agent 工作。

**Verify：验证结果。**运行测试、lint、typecheck、E2E，或者让另一个审查 Agent 对照 spec 检查。没有 Verify 的 loop，最容易变成“看起来很忙”的幻觉制造机

**Iterate：修正并重跑。**验证失败时，loop 不应该立刻把问题丢回给人，而应该读取失败信息，更新计划，再跑一轮。通过验证后才停止。

这五个阶段并不神秘。它们其实就是工程师每天在做的事，只是过去它们散落在人的脑子里、命令行里、聊天框里。Loop Engineering 是把这些步骤外化出来，让系统可以重复执行

unsetunsetLoop vs Harness Engineeringunsetunset

聊到这里，很容易把 Loop Engineering 和另一个概念混在一起：Harness Engineering。

它们确实关系很近，但不是一回事。

一句话区分：

Harness Engineering 是给单个 Agent 搭“工作台”；Loop Engineering 是设计一套会反复驱动 Agent 工作的“反馈系统”。

可以用一张表看得更清楚：

维度	Harness Engineering	Loop Engineering
关注对象	单个 Agent 的运行环境	一个或多个 Agent 的循环系统
核心问题	Agent 在什么环境里工作，能用什么工具，权限边界是什么	Agent 如何持续发现、执行、验证、迭代，直到完成
典型组件	文件系统、终端、测试命令、工具调用、权限、上下文注入	Automation、目标、状态记忆、验证门禁、停止条件、sub-agents
类比	给工人配置工位、工具箱和安全规则	设计一条有质检、有返工、有排期的生产线
目标	让 Agent 能稳定完成一次任务	让系统能持续推进任务，并知道何时继续、何时停止、何时交还给人

更具体一点，Harness Engineering 解决的是 Agent 的“行动能力”问题。

比如 Agent 能不能读 repo，能不能改文件，能不能运行测试，能不能访问 issue，能不能调用浏览器，能不能安全地执行 shell，能不能拿到项目规则和上下文。

这些能力决定了 Agent 能不能真正工作，而不是只在聊天框里给建议。

Loop Engineering 解决的是 Agent 的“反馈闭环”问题。

比如什么时候启动，本轮目标是什么，失败后怎么修，谁来验证，最多重试几轮，状态写在哪里，多个 Agent 怎么分工，什么时候停止，什么时候交给人。

所以它们不是竞争关系，而是上下层关系。

Harness 是 Agent 的运行底座；Loop 是基于这个底座设计出来的工作循环。

没有 Harness，Agent 没有工具和环境；没有 Loop，Agent 只能靠人一轮轮 prompt 推着走。

理解这层关系之后，再看下面的六个工程构件就更清楚了：Worktrees、Skills、Connectors 更像底座能力，Automations、Memory、Sub-agents、Stop condition 更像循环能力。真实系统里它们会混在一起，但设计时最好分开想。

unsetunset真正落地，需要六个工程构件unsetunset

Loop 到底靠什么跑起来：

1. Automations：让 loop 有心跳

Automation 决定 loop 什么时候启动。

比如每天早上检查 CI 失败、每小时扫描新 issue、每次 PR 更新后自动跑审查。没有 Automation，loop 只是你手动触发的一次任务；有了 Automation，它才变成持续运转的系统

2. Worktrees：让并行不互相踩文件

多个 Agent 同时改一个 repo，最先爆炸的通常不是模型能力，而是文件冲突

Git worktree 给每个 Agent 一个独立工作目录和分支

这样一个 Agent 修登录，一个 Agent 写测试，一个 Agent 做重构，它们不会在同一个 checkout 里互相覆盖

这不是锦上添花。只要你想让多个 Agent 并行，它就是基础设施

3. Skills：把项目知识写到系统外面

每次新会话都让 Agent 重新猜你的项目结构、构建命令、代码风格和历史坑位，是一种隐性浪费

Skill 的价值在于把这些项目知识沉淀成稳定文件：怎么运行测试，哪些目录不能动，接口兼容性有哪些红线，为什么团队不采用某种写法

没有 Skill，loop 每轮都从零开始理解项目

有了 Skill，项目经验会复利

4. Plugins / Connectors：让 loop 接入真实工作环境

只会读写文件的 loop 很小

真正有用的 loop 要能碰到现实工具链：

Issue 系统、CI、数据库、监控、Slack、飞书、Linear、Gitlab

Connector 的意义是让 Agent 不只是说“我建议你创建一个 PR”，而是能够创建 PR、关联 ticket、读取 CI、把结论发到团队频道

5. Sub-agents：让执行者和检查者分离

让同一个 Agent 写代码再评价自己的代码，天然有偏差

它会倾向于相信自己的解释

更可靠的结构是：一个 Agent 探索，一个 Agent 实现，一个 Agent 验证

尤其是验证者，最好有不同的指令，甚至不同的模型和推理预算

Loop 越自动，Verifier 越重要。因为你不在场的时候，系统必须有能力说“不，这还没完成”

6. Memory：让第 47 轮知道前 46 轮发生过什么

模型上下文不是长期记忆。会话结束后，很多状态都会消失。

所以长期运行的 loop 必须有外部状态：Markdown 进度文件、Issue board、任务数据库、Linear ticket 都可以。关键是它要记录：

做过什么；
哪些通过了；
哪些失败了；
下一步是什么；
为什么之前的路线被放弃

这听起来很朴素，但它是 long-running agent 的脊柱。Agent 会忘，仓库不会

unsetunset从单 Agent 到 Agent Fleetunsetunset

不是所有任务都需要一支 Agent 队伍

Single-agent loop 适合边界清楚的小任务：修一个 bug、补一组测试、更新一段文档、根据失败日志做一次修复，一个 Agent 完整经历发现、计划、执行、验证、迭代就够了。

Fleet loop 适合更大的目标：比如“把一个模块迁移到新架构”

这时需要一个 orchestrator 拆任务，再交给研究、实现、测试、审查等不同角色。每个角色内部仍然跑自己的小 loop

判断是否需要 Fleet，不看任务听起来大不大，而看三个条件：

是否能拆成相互独立的子任务；
子任务是否有明确验收标准；
你是否有足够的 review 带宽接住结果。

第三点最容易被忽略。Agent 并行可以扩大产出，但不能自动扩大你的理解能力。并行越多，集成和审查压力越大

unsetunset先做闭环，再谈开放unsetunset

有一个很实用的区分：Open Loop 和 Closed Loop。

Open Loop 给 Agent 更大探索空间，适合研究、原型、找未知问题

但它也更贵、更难控，更容易在目标模糊时漂移

Closed Loop 则相反：目标明确、步骤有限、验证标准清楚、失败时按规则重试，超过边界就交还给人。

对大多数真实团队，我的建议很明确：先做 Closed Loop。

比如不要一上来就说：

帮我持续优化这个项目，直到它更好

更好的 loop 是：

目标：修复 test/auth 目录下失败的测试。
上下文：读取 README、ARCHITECTURE.md、相关测试文件。
动作边界：只能修改 src/auth
验证：运行 npm test -- test/auth，并运行 npm run lint。
停止条件：
测试和 lint 都通过，输出变更摘要；
如果三轮后仍失败，停止并说明阻塞点。

这就是工程化的差异，模糊目标会诱导 Agent 编故事，明确边界会逼它解决问题

unsetunset成本、质量和理解债unsetunset

Loop Engineering 最大的误区，是把它理解成“让 Agent 自己干，我就不用管了”

现实正好相反，Loop 会放大能力，也会放大问题

Token 成本会变成架构约束

一轮 Agent loop 可能要读文件、查上下文、调用工具、生成代码、跑测试、读错误、再生成修复

加上 sub-agent 和 verifier，token 消耗会很快上升

所以成本不是财务问题，而是架构问题

你需要限制搜索范围、缓存项目知识、缩短上下文、明确停止条件，避免“开放式探索”在后台无限燃烧。

成本图很适合作为提醒，但里面涉及具体模型价格和能力数字，正式发布前应该以官方文档复核。对工程实践来说，更重要的原则是：不要让 loop 的探索空间大于你的预算和验证能力。

质量门禁不能省

没有验证门禁的 loop，只是在自动生产待审稿，它可能越改越远，还能给出很自信的解释。

可靠的 Verify 至少包含三类：

机器可判定：测试、lint、typecheck、构建、E2E；
规则可判定：是否符合 spec、是否越权修改、是否破坏兼容性；
人类需判断：架构取舍、产品体验、安全影响；

能自动化的尽量自动化，不能自动化的明确交还给人

理解债会累积

风险非常关键：loop 让代码生成更快，也可能让你更快失去对系统的理解。

如果你只是收结果、不读 diff、不理解 trade-off，短期会很爽，长期会把项目变成你无法维护的黑箱。

Loop 的目的不是替你思考，而是把重复反馈自动化，把人的注意力留给判断。

这也是为什么“设计 loop”比“写 prompt”更像软件工程。它要求你定义边界、质量、状态、失败处理和责任归属

unsetunset今天就能试的最小 Loopunsetunset

如果你想在团队里试 Loop Engineering，不要从“全自动开发团队”开始。先做一个小闭环。

先澄清一句：下面这个模板不是某个工具的专属格式，虽然Claude Code 里确实有 /loop 和 /goal，但这份模板的本质是一份 runbook。

所以这里真正重要的不是命令名，而是这六样东西有没有写清楚：Goal、Context、Actions、Feedback、Stop condition、Memory。

可以从下面这个模板开始：

# Agent Loop: auth-test-fixer

## Goal
让 `test/auth` 下的测试全部通过，并保持 lint 通过。

## Context
- 先读 `README.md`
- 再读 `docs/architecture.md`
- 只关注 `src/auth` 和 `test/auth`

## Actions
- 可以修改实现和测试
- 可以新增小型辅助函数
- 不允许修改公共 API
- 不允许跳过或删除测试

## Feedback
- 每轮运行：`npm test -- test/auth`
- 每轮运行：`npm run lint`
- 失败时读取错误日志并修复

## Stop condition
- 测试和 lint 全部通过后停止
- 最多迭代 3 轮
- 3 轮后仍失败，输出阻塞原因和下一步建议

## Memory
- 把每轮尝试、失败原因、修改摘要写入 `.agent/state/auth-test-fixer.md`

这个模板不复杂，但它已经具备 loop 的核心骨架：

有目标、有上下文、有动作边界
有反馈、有停止条件、有外部记忆

你可以把它接到自动化任务里，每天扫一类失败；也可以让它在 PR 更新后自动跑；还可以把 verifier 拆成单独 sub-agent，只审查是否越权、是否破坏兼容性

当这个小 loop 稳定以后，再扩展到更多任务

unsetunset最后：杠杆点变了unsetunset

这不是描述升级，而是职责升级

未来优秀的 AI 工程师，未必是最会写漂亮 prompt 的人，而是最会定义目标、拆分反馈、设计验证、控制成本、管理状态的人

Prompt 是按钮，Loop 是机器，工程师的价值，不是永远亲手按按钮，而是设计一台不会乱跑、能被验证、出了问题知道停下来的机器

Build the loop. Stay the engineer.

内容效果不满意？点此反馈