把人工轮询变成可验证、可记忆、可编排的 Agent 工程闭环。
原文链接：AI 小老六

很多人使用 Coding Agent 的方式，其实早就不是一次性问答了。

更常见的节奏是：先丢给 Agent 一个目标，等它跑完；人再回来读结果、挑问题、补 Prompt、重跑测试；如果还不满意，就继续追加要求。这个过程看起来像一串离散对话，本质上却是一条 ​Agent Loop​：观察现状，决定下一步，执行修改，验证结果，再根据验证结果回到下一轮。

过去这条链路里最忙的不是 Agent，而是人。Agent 做完一轮就停下，真正负责判断“下一步该干什么”的，是屏幕前那个不断切回来的用户。

Loop Engineering 讨论的核心问题就在这里：如果 Agent 已经能执行、能读结果、能写代码、能跑测试，为什么还一定要让人守在循环体里？

更准确地说，它不是发明了一种全新的智能，而是把原来靠人手动接力的循环，改造成一个由 Agent 自己推进的工程系统。人仍然要定目标、划边界、判断高风险取舍，但不必再充当每一轮的调度器。

图：目标、执行、验证与记忆组成一条可持续推进的 Agent Loop

Manual Loop：人为什么会被绑在最频繁的位置

把一次常见的 AI Coding 流程拆开，会看到几个固定环节。

你先写 Prompt，Agent 根据上下文动手。它改完代码、生成方案或补完测试后，输出一份结果。接着你检查文件、跑命令、看报错、判断它是否偏题，再写下一段 Prompt 让它修正。循环一直转，直到你认为结果可交付。

问题不在循环本身。循环是软件工程里非常自然的工作方式，调试、测试、Code Review、性能优化，哪个都不是一步到位。真正的问题是，人被放在了最密集的折返点上。

这会带来一个很实在的副作用：注意力被不断打断。你刚切去写文档，Agent 跑完了；你回来扫一眼，发现测试红了；改完提示词再让它跑，自己又切走。过不了多久，人不再是在管理任务，而是在给 Agent 做轮询服务。

图：Manual Loop 把人放在最频繁的折返点上

社区里出现过各种提醒工具，甚至有人用硬件设备提示“Agent 已完成”。这类工具有用，但也说明了另一件事：我们还在默认让人盯着循环跑。

Loop Engineering 想改的，就是这个默认设置。

Agent Loop：目标仍由人定，循环交给机器跑

一个可工作的 Agent Loop，通常可以拆成六个组件：​Goal、Discovery、Plan、Execute、Verify、Memory​。

Goal 是人输入的目标。这里最怕的是一句“帮我优化一下”这类含糊要求。更好的写法是把目标直接写成验收标准，例如“指定测试全部通过、类型检查无报错、现有行为不回退”。目标越能被检查，Loop 越容易收敛。

Discovery 是 Agent 自己发现当前状态。它可能会读代码、跑测试、看覆盖率、检查日志，也可能会读取上一轮留下的任务记录。Discovery 的价值是让 Agent 不必等人逐条派活，而是先建立一份自己的现场判断。

Plan 是把问题拆成可执行单元。一个好的计划不会只说“继续优化”，而会拆出边界清楚的子任务：哪个模块缺测试，哪个分支有 bug，哪个文档需要同步，哪些任务可以并行。

Execute 是执行阶段。这里可以是单 Agent 顺序推进，也可以由 Orchestrator 把任务 fan-out 给多个 Sub-Agent：一个补 parser 测试，一个检查 serializer，一个专门跑回归。并行不是为了炫技，而是因为拆分后的任务确实互不依赖。

Verify 是闭环的闸门。它决定循环是停止还是继续。测试、typecheck、lint、benchmark、构建结果、截图对比，都可以成为​验证信号​。验证失败时，失败信息要原样回流给下一轮，而不是让 Agent 凭印象猜。

Memory 是最容易被低估的一层。长循环不能只靠对话上下文撑住。对话窗口会膨胀，会遗忘细节，也会让旧信息干扰新判断。更稳的做法是把状态写到外部：哪些任务已完成，哪些失败原因已确认，哪些文件不要再动，下一轮从哪里开始。

图：Goal、Discovery、Plan、Execute、Verify、Memory 共同决定循环是否收敛

Self-prompting 的位置

在这种循环里，上一轮结束后，Agent 可以根据当前进度生成下一轮 Prompt。人不再负责给每个折返点续命，循环自己把接力棒递下去。这不是让 Agent 随便发挥，而是让它在既定目标和验证标准之内继续推进。

Orchestrator：把并行执行收成一条主线

Loop 一旦变长，就需要一个掌管目标的角色。这个角色通常叫 Orchestrator。

Orchestrator 不一定亲自做所有事。它更像一个小型调度器：读目标，读 Memory，判断哪些任务可以拆出去；等 Sub-Agent 返回后，再做 fan-in，把结果合并，决定是交付还是进入下一轮。

Fan-out / Fan-in 是什么

Fan-out 是把一个目标拆给多个 Agent 并行处理。Fan-in 是把这些结果重新汇总到一处，由 Orchestrator 统一检查冲突、合并产物、触发验证。前者解决效率，后者解决一致性。

从 Harness 的视角看，Orchestrator 属于编排层。模型负责推理，工具负责行动，Memory 负责状态延续，Orchestrator 负责把这些能力组织成一条持续运行的执行链。

如果继续往底层剥，仍然能看到 ReAct Loop 的影子：观察、思考、行动、再观察。Loop Engineering 不是替代 ReAct，而是把这个基础循环放进更稳定的工程外壳里，让它能跑更长、更复杂的任务。

Open Loop 与 Closed Loop：边界决定成本曲线

Agent Loop 有两种典型形态：Open Loop 和 Closed Loop。它们不是能力强弱之分，而是边界设计不同。

Open Loop 的目标开放。你给 Agent 一个方向，它自己探索现场，发现问题，挑选任务，执行之后再继续寻找下一个方向。

这种方式适合探索。比如把代码仓库、错误日志、用户行为数据、支付数据、实验结果、社媒反馈都接给一个 Agent，让它定期读取业务现场，自己发现转化漏斗问题、线上报错、Prompt Caching 成本异常或功能机会，再提出修改甚至提交 PR。

Open Loop 的好处是能撞见意料之外的东西。人事先不知道哪里有问题，Agent 反而可能从多个数据源里发现线索。代价也很明显：边界不清，停点不清，Token 和工具调用成本难以预估。它更适合预算充足、目标是“发现机会”的场景。

Closed Loop 则相反。它从一个有界目标出发，每一步都有比较清楚的验收标准。失败就带着失败信息回到实现环节，达标就停。

这种形态不一定惊艳，但更适合交付。因为它的成本曲线可估：大概几轮验证、哪些命令会跑、什么条件算结束，都能提前说清楚。

维度	Open Loop	Closed Loop
目标形态	开放，执行中继续发现	有界，开始前先定义
路径可见性	运行后才逐步展开	大致可提前拆分
验收方式	依赖 Agent 自判和外部预算	依赖明确检查信号
成本特征	难预测，需要强预算上限	可估算，容易收敛
适合场景	探索机会、发现问题	交付任务、修复问题

图：开放探索和有界交付对应两条不同的成本曲线

实践里更稳的顺序是：先跑 Closed Loop。把一个验收标准明确的小任务跑顺，了解 Agent 在这套工具链里的表现，再逐步放开边界。直接上 Open Loop，常见结果是成本和产出都不好解释。

研发闭环：让测试结果成为循环的方向盘

最适合解释 Closed Loop 的例子，是给工具库补测试并修掉暴露出来的 bug。

这类任务有天然的机器验收信号：acceptance test 通过，typecheck 通过，现有测试不变红。人不需要主观判断“差不多了”，命令退出码会给答案。

环节	在研发任务里的落点
Goal	目标直接写成验收标准：目标测试全绿、类型检查通过、现有行为不回退
Discovery	先跑测试和覆盖率，找出失败用例、未覆盖模块、可疑边界条件
Plan	按模块拆分待补测试和待修 bug，优先拆成互不依赖的小块
Execute	可并行派出多个 Agent 各处理一个模块，再由 Orchestrator 汇总
Verify	跑测试、typecheck、必要的构建命令；失败信息原样进入下一轮
Memory	记录已通过模块、仍失败用例、已确认不要修改的行为边界

这里最关键的不是 Prompt 写得多漂亮，而是验证信号足够硬。只要测试不绿，Loop 就没有资格结束；一旦全绿，Loop 就不该继续“顺手优化”。可判断的停点，是 Closed Loop 能控制成本的根本。

一个简化后的循环 Prompt 可以这样写：

/goal 为 <工具库> 补齐测试并修复发现的 bug。

验收标准：
- tests/acceptance/ 下目标用例全部通过
- npm run typecheck 无报错
- 现有测试不出现新的失败

循环规则：
- 先运行测试，读取失败用例和报错栈
- 若未通过，定位原因，修改最小必要代码或补充测试
- 修改后重跑验证命令
- 只要验收未通过，就继续下一轮
- 如果验收标准本身有歧义，先停下来提问

这类 Loop 还可以接入 hook 或 CLI 退出码，让测试结果自动回流到下一轮。人只负责最初的目标和少数边界判断，剩下的循环由 Agent 自己推进。

Acceptance Criteria 为什么重要

Acceptance Criteria 是一组能判断任务是否完成的条件。它的作用不是把需求写得更正式，而是把“做好了没”从人的感觉变成一个可执行的检查。Agent Loop 一旦有了这样的靶子，就能少很多自我感觉良好的停顿。

增长闭环：开放目标也要加上收敛条件

并不是所有任务都像测试那样有 0/1 结果。比如一个网店想持续增长，目标天然开放，判断也更模糊。但开放不等于失控，关键是给它装上循环边界。

一个可行的设计是让 Orchestrator 读外部 Memory，尤其是上一轮留下的 next_steps。它先判断哪些事项还没落地，再派出不同 Sub-Agent 处理增长链路上的不同环节。

Sub-Agent	职责
Builder	做一个可分享的小测验或小工具，用作 lead magnet，在结尾收集邮箱
Scout	从论坛、搜索趋势、竞品内容和用户讨论中寻找新选题，并按受众规模、购买意图、内容缺口、可工具化程度打分
Growth	根据站点和新产物写落地方案，包括站内入口、邮件草稿、社媒文案和下一轮素材建议

图：Builder、Scout、Growth 的输出由 Orchestrator 汇总进下一轮记忆

Builder、Scout、Growth 的输出不会直接散落在各处。Orchestrator 要把 quiz、选题排序、投放动作和下一轮建议合并进同一份 next_steps。下一次 Loop 启动时，它先读这份记录，再决定继续做什么。这样一来，每轮的尾巴就能接上下一轮的开头。

这类任务的收敛条件不可能像测试那样干净，但仍然可以人为设边界：是否还有足够多未消化的新选题，上一轮建议是否已经去重，站点增长指标是否值得继续投入。条件不满足就继续转，满足就停下等待下一次触发。

更多 Loop 形态：不是只有写代码能循环

把 Loop 抽象出来之后，它可以套进很多工作：定期触发，读取输入，过滤或打分，生成草稿，和历史记录去重，必要时交给人审，最后写回 Memory。

自由职业者

定期扫描项目文件夹，读取客户记忆，包括项目目标、沟通偏好和历史交付。Agent 为每个客户生成进度更新草稿，但不自动发送，而是放进 review 区域等人确认。这里的 human-in-the-loop 保留在对外沟通前的最后一道门。

持续学习者

按固定周期搜索领域进展，用当前学习目标做相关度过滤。低相关内容直接丢掉，剩下的写成简报：发生了什么，为什么值得知道，和已有知识有什么关系。写入前再比对历史简报，避免重复讲同一件事。

网店运营者

读取销售和流量数据，找出访问量高但转化低的商品，重写描述、CTA 和站内入口。每次改动都记录“为什么改”，方便之后回看哪些调整真的影响了转化。

内容创作者

读取选题库和内容表现数据，对每个选题重新打分：是否仍有受众，竞品是否已经做透，是否适合当前账号的表达方式。最后输出一份候选排序，并标注哪些题不该再碰。

相关度阈值挡住的是什么

循环最怕“看起来都有关”。如果不设阈值，长期运行后 Memory 和简报都会被噪声塞满。相关度阈值的作用，是替系统把勉强相关的东西挡在外面，让人只处理真正值得进入下一轮的内容。

结语：从循环体里退出来

Loop Engineering 最有价值的地方，不是让 Agent 显得更神秘，而是把一个普通但高频的工作模式工程化。

以前，人负责每一轮的接力；现在，人负责目标、边界和风险判断。Agent 负责在这个范围内发现问题、制定计划、执行修改、读取验证结果、写入外部记忆，再进入下一轮。

先从 Closed Loop 开始，挑一个验收标准能写清楚的小任务。不要急着放开边界，也不要一开始就期待它像一个完全自主的数字员工。让它先学会在明确靶子上收敛，等这条链路稳定了，再加入 Orchestrator、Memory、定时触发和更多 Sub-Agent。

真正的变化不在“循环”本身。循环一直都在。变化在于，人终于可以从那个最频繁、最耗注意力的折返点上退出来，把时间花在更值得自己判断的地方。

推荐阅读

SkillOpt 架构拆解：把 Skill 文本当参数，用执行轨迹训练 Agent

Agent Skill 状态机工程：Mode-Step 网格如何拆开工作流边界

Agent Skill Eval：从触发信号到 A/B 基准，如何把 Skill 做成可回归工程单元

GEPA 架构拆解：让 Prompt 和 Skill 优化不靠玄学

AI Native 竞争力：真正稀缺的不是会用 AI，而是把事往前推的人