把人工轮询变成可验证、可记忆、可编排的 Agent 工程闭环。原文链接AI 小老六很多人使用 Coding Agent 的方式其实早就不是一次性问答了。更常见的节奏是先丢给 Agent 一个目标等它跑完人再回来读结果、挑问题、补 Prompt、重跑测试如果还不满意就继续追加要求。这个过程看起来像一串离散对话本质上却是一条 ​Agent Loop​观察现状决定下一步执行修改验证结果再根据验证结果回到下一轮。过去这条链路里最忙的不是 Agent而是人。Agent 做完一轮就停下真正负责判断“下一步该干什么”的是屏幕前那个不断切回来的用户。Loop Engineering 讨论的核心问题就在这里如果 Agent 已经能执行、能读结果、能写代码、能跑测试为什么还一定要让人守在循环体里更准确地说它不是发明了一种全新的智能而是把原来靠人手动接力的循环改造成一个由 Agent 自己推进的工程系统。人仍然要定目标、划边界、判断高风险取舍但不必再充当每一轮的调度器。图目标、执行、验证与记忆组成一条可持续推进的 Agent LoopManual Loop人为什么会被绑在最频繁的位置把一次常见的 AI Coding 流程拆开会看到几个固定环节。你先写 PromptAgent 根据上下文动手。它改完代码、生成方案或补完测试后输出一份结果。接着你检查文件、跑命令、看报错、判断它是否偏题再写下一段 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 LoopClosed 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 文本当参数用执行轨迹训练 AgentAgent Skill 状态机工程Mode-Step 网格如何拆开工作流边界Agent Skill Eval从触发信号到 A/B 基准如何把 Skill 做成可回归工程单元GEPA 架构拆解让 Prompt 和 Skill 优化不靠玄学AI Native 竞争力真正稀缺的不是会用 AI而是把事往前推的人