前言
假设一个场景：
小朋友做完作业，说了一声“写完了”，老师检查后发现：有一道题算错了，还有一道漏了单位。于是，小朋友根据批注订正，再检查一次，直到符合要求，或者遇到需要老师帮助的问题。
这里有一条很重要的线索：上一次的结果，决定了下一次要做什么。
Agent 完成复杂任务，也需要这样的过程。它不仅要能执行指令，还要能看见结果、对照目标、记住进度，并判断什么时候继续、什么时候停。
Loop Engineering 关注的，正是怎样把这套反馈机制设计成可靠的系统。
这也是 TRAE 在 Agentic Coding 场景中持续探索的方向：不只是让 AI 能执行任务，而是让它能基于结果继续推进，直到获得可验证的交付。
接下来，我们从一个常见场景出发，看看它为什么需要、如何运转，以及怎样落到实际任务中。
为什么需要 Loop Engineering？
图：Loop 把人从逐轮催促者，变成目标、证据与边界的设计者。
你让 Agent 修一个 Bug。它读代码、改文件、跑测试，然后告诉你：“已经完成。”
你检查后发现，仍有测试没有通过，于是把报错贴回去；它再改一次，却又漏了类型检查。你只好继续盯、继续提醒，还要判断什么时候才算结束。
这段协作里，Agent 执行了每一轮工作，但负责把多轮工作连接起来的，始终是你：看结果、对照目标、记住进度、决定下一步，并在事情跑偏时踩刹车。
Loop Engineering 要做的，是把这些规则相对明确、反复出现的监督动作写进系统。
拿到任务后，系统检查每轮结果、记录进度，再决定继续、换路、停止还是找人。人的工作由此从逐轮补充“接下来做什么”，更多地转向提前设计目标、验收标准、权限和例外处理。
这与小朋友学习独立完成作业很像。起初，每一步都需要老师提醒；后来，作业要求、检查方法和求助规则逐渐明确，小朋友就能自己推进更多步骤。老师仍然负责制定要求、处理疑难问题，只是不用一直站在旁边催促。
让系统根据反馈持续工作，并不是一个全新的愿望。今天，这件事更值得被认真讨论，与两方面能力的发展有关：一方面，模型越来越能处理多步骤任务，在较长的工具调用过程中保持目标；另一方面，工具、记忆、权限、日志和上下文管理等运行机制逐渐完善。
前者让 Agent 更有能力完成工作，后者让这份能力能够被系统可靠地组织起来。
Loop Engineering 则进一步关注：如何依据每轮结果，把任务持续带向终点。
一次 Run 结束，为什么不代表任务完成？
一轮里有反馈，整件事仍可能没有闭环
Agent 的一次运行，通常称为一次 Run。在这次运行中，它可能已经多次读取文件、调用工具、查看结果，再据此调整动作。
但当它交回最终答案后，如果外层系统就此结束，没有继续核对整个目标，也不会因为某项检查仍然失败而启动下一轮，那么从完整任务的角度看，这一层仍然是开环的。
可以把它想成一份分几页完成的作业：写完当前这一页，不代表整本作业已经做完。单页里的计算和检查，与整本作业的进度管理，是两个不同层次的问题。
开环并不一定有问题。改一句文案、解释一个概念、生成一段低风险草稿，一次调用可能已经够用。只有当任务需要等待环境反馈、尝试不同方案、跨越上下文窗口，或者收集多项验收证据时，才更需要外层机制持续推进。
如果这些检查和推进动作频繁发生，而且规则相对稳定，就值得把它们写进系统。工作的重心也随之变化：从临时拼接下一条 Prompt，转向设计一个会根据结果继续执行、验证和停止的系统。
闭环比“多跑几遍”，多了一条反馈链
小朋友做错一道题，把原答案重新抄三遍，通常不会因此做对。
看见老师圈出的单位错误，补上单位，再重新验算，才是在利用反馈。
Agent 也是一样：
方式 |
下一次依据什么 |
常见用途 |
一次执行 |
本轮产出后结束 | 简单、低风险、一步可完成的任务 |
盲重试 |
输入和策略基本不变，再执行一次 | 偶发网络超时、临时资源不可用 |
反馈 Loop |
读取新结果和已有进度，根据目标差距选择下一步 | 调试、修复、研究和需要持续推进的任务 |
重试可以是 Loop 中的一个动作。例如，系统判断失败来自临时网络波动，决定稍后重试。但只有“再试一次”这个动作，还不足以构成完整的反馈闭环。
定时器同样如此。它可以每隔五分钟叫醒任务，却不会天然知道任务为什么还要继续。真正形成闭环，需要让环境产生的新结果进入系统，与目标对照，再影响下一次决定。
判断一个 Loop 是否有效，关键要看：这一轮获得的反馈，是否真的参与了下一轮决策。
Loop 的原理：反馈怎样推动任务？
一个完整的反馈过程，可以拆成七项职责：
组成 |
用做作业来理解 |
在系统里负责什么 |
Goal，目标 |
作业要求和评分标准 | 定义完成条件与约束 |
Observer，观察器 |
看到答案和批注 | 收集测试、日志、文件变化等结果 |
Verifier，验证器 |
对照要求，找出未达标的题 | 判断是否通过，以及还差什么 |
Controller，控制器 |
决定订正、查资料还是求助 | 根据目标、反馈和状态选择下一步 |
Action / Tool，动作与工具 |
动笔订正、翻阅资料 | 把动作实际施加到环境中 |
State，状态 |
记下哪些已完成、哪些还没做 | 保存进度、证据、已尝试的方法和预算 |
Stop Policy，停止规则 |
何时交卷，何时停下找老师 | 区分完成、失败、停滞、超预算和人工接管 |
这些是职责划分，不意味着必须建立七个独立模块，或启动七个 Agent。一个简单控制程序，也可以承担其中多项职责。重点是每件事都有明确的负责机制。
运行起来时，反馈链大致是这样的：
明确目标 → 执行动作 → 观察结果 → 检查差距 → 更新状态 → 决定继续、换路或停止。
其中，有两个区别尤其值得说清楚。
Observer（观察器）像眼睛，Verifier（验证器） 像尺子
眼睛告诉我们发生了什么，尺子帮助我们判断离要求还有多远。
一份测试日志，是 Observer 带回的观察；“大部分文件已迁移，但三项时区检查仍然失败，因此任务尚未完成”，才是 Verifier 对照目标后给出的判断。
Verifier 负责指出差距，Controller 再决定下一步：改代码、补充信息、回退，还是请人处理。
观察结果也可能不完整。日志可能被截断，测试可能延迟，结果可能来自旧版本。可靠的 Loop 需要确认：正在使用的证据，是否对应当前这份输入和刚才的动作。
昨天的作业得了满分，不能证明今天的作业也全对。旧代码上的测试通过，同样不能替新提交证明完成。工程上，可以通过代码提交标识、数据快照版本或请求 ID，把证据与具体输入对应起来。
Stop 和 Success，是两件事
模型说“完成了”、用户取消、工具报错、预算耗尽，都可能让运行停止，但停止的原因各不相同。
一个可靠的系统，至少应区分这些结果：
- 成功（SUCCEEDED）：当前版本上的证据满足完成条件。
- 失败（FAILED）：出现已知且无法继续恢复的错误。
- 停滞（STALLED）：连续多轮没有取得有效进展。
- 预算耗尽（BUDGET_EXHAUSTED）：达到时间、轮数或费用上限。
- 需要人工接管（NEEDS_HUMAN）：需要业务判断、更高权限或关键决策。
- 已取消（CANCELLED）：用户或外部系统明确终止任务。
这就像“作业全对，可以交卷”和“放学了，先收起作业”。两者都结束了当前过程，但只有前者满足了完成要求。
预算上限负责让循环及时停下；验收证据负责说明任务是否成功。
为什么有些 Loop 越做越好，有些却越跑越乱？
反馈能帮助调整，却不保证每一轮都进步。Agent 可能修好测试 A，又破坏测试 B；也可能根据一次偶发失败反复改代码，越改越偏。
工程上所说的“收敛”，可以理解为：未完成的验收项逐步减少，已经通过的重要检查不再反复被破坏，最终获得足以支持完成判断的证据。
要接近这个结果，需要几个条件共同成立。
第一，完成条件可检查。“修好”“写得更棒”还不够具体。测试、查询、规则、明确的评分标准或人工验收，至少要有一把实际可用的尺子。
第二，系统有能力改变结果。没有代码权限、缺少关键数据、依赖服务不可用时，多跑几轮也不会凭空解决问题。系统需要识别阻塞，而不是一味继续。
第三，反馈与当前动作对应。旧缓存、延迟返回的测试、并发提交，都可能干扰判断。必要时应等待结果稳定，再决定是否修改。
第四，每轮改动适度且可回退。围绕明确缺口做小步调整，更容易判断原因。顺手重写大量无关逻辑，会增加定位问题和回退的难度。
第五，进度能交给下一轮。有用的 State 应告诉下一轮：当前是哪一版，试过什么，哪些检查通过，还差什么，以及剩余预算。堆积聊天记录和日志，并不等于保存了可用的进度。
第六，验收与停止规则可信。优先使用可重复执行的测试和规则；模型评审可以补充判断，但不宜只凭执行者的自评放行。验收规则和权限边界也应受到保护，避免 Agent 通过降低标准或绕过检查获得“成功”。
Loop 周围的概念，各自负责什么？
理解了反馈链，再看 ReAct、Harness、Skill 等概念，就容易分清它们的位置。
仍然用做作业来理解：解一道题时边做边看结果，像 ReAct；书桌、文具和使用规则，像 Harness；解题方法卡，像 Skill；根据整份作业的检查结果安排后续行动，则对应本文讨论的外层 Loop。
它们经常同时出现，但关注的问题不同。
ReAct：推理与行动交替
ReAct 描述的是一种推理与行动交替的方式：模型选择动作，工具执行并返回环境结果，模型再据此决定后续动作。
比如，Agent 先搜索旧库引用，再修改文件；看到测试失败后，读取报错位置，继续调整。工具结果不断进入后续决策，构成运行过程中的反馈。
本文区分的是两个反馈范围：当前 Run 内，如何决定下一次工具调用；当前 Run 结束后，如何检查全局目标、保存进度，并判断是否启动下一轮。
前者完成了局部步骤，不代表后者负责的整体目标也已完成。具体系统如何划分运行边界可以不同，但“谁来检查整件事是否完成”必须明确。
Harness：让 Agent 稳定运行的支撑环境
Harness 为 Agent 准备上下文、执行工具调用、限制权限、隔离文件、记录日志，并处理上下文压缩或重启等问题。
有了这些机制，模型提出的动作才能可靠地落实到环境中。
Harness 与 Loop 的关系，可以理解为运行支撑与反馈控制的配合。Harness 提供工具、权限、日志等能力，Loop 使用这些能力观察结果、作出决定，再启动后续工作。
行业对 Harness 的范围并没有统一边界。有些系统主要用它指单次运行环境，有些会把内层循环甚至更完整的控制机制包含进来。因此，不必强行把两者对应为固定的上下级，也不宜把它们简单视为自动化程度的不同等级。
更有用的问题是：谁拥有完成条件，谁保存跨轮状态，谁检查证据，谁有权因为风险、停滞或预算而终止任务？
Worktree 和 Connector 也可以放在这里理解。
Worktree 解决文件隔离。多个执行者并行修改同一个仓库时，可以分别使用独立工作目录和分支，就像每个小朋友都有一份练习册，避免直接覆盖彼此的答案。但它不能判断哪份答案更好，也不能自动消除合并冲突和业务逻辑冲突。
Connector 扩展观察和行动的范围。读取工单、测试状态或数据库时，它帮助系统看见环境；创建 PR、更新任务时，它帮助系统采取行动。至于为什么做、是否继续、何时完成，仍然需要目标和控制规则。
当工具能写入外部系统，还要考虑重复执行的后果。例如，同一轮恢复后再次执行，不应重复创建工单或发送相同通知。
Skill：保存方法，State：保存进度
Skill 是按需加载的可复用能力包，可以包含步骤、领域知识、脚本、模板和注意事项。
例如，一个库迁移 Skill 可以说明：先找到旧库引用，按 API 映射逐项替换，遇到缺失能力时接入对应插件，每完成一批就运行检查。
它解决的是“这类任务通常怎么做”。Loop 解决的是“这一轮之后还差什么，下一轮怎么推进，何时整体完成”。
两者经常配合：Controller 启动一次运行，Agent 根据 Skill 执行；Verifier 检查结果并指出缺口，Loop 再决定继续使用当前方法，还是切换到另一种做法。
Skill 像解题方法卡，State 像当前作业的进度便签。方法可以反复使用，进度则随这次任务持续变化。把做法写得再详细，也不能替代对当前结果的记录。
Memory 则提供跨运行保留信息的机制。一份当前状态，在任务结束后也可能提炼为可复用经验。它们并非严格互斥，但需要分清：哪些是长期做法，哪些是本次任务必须接续的信息。
Workflow、Scheduler 和 Eval：组织、唤醒与测量
Workflow 是路线图。它规定顺序、分支、并行和角色分工，可以是线性的，也可以在某一步包含反馈循环。外层 Loop 也可以把整个 Workflow 当成一次行动。
Scheduler 是闹钟。它决定什么时候再执行一次，例如稍后检查测试是否结束。测试结束后是否达标、要不要继续修改，则由验收与控制机制判断。
Sub-agent 提供角色分工。可以让不同执行者分别探索、修改和复核，用独立上下文或权限减少互相影响。但多一个评审模型，不等于多一份事实证明。关键结论仍需要测试、规则或人工判断支持。
Verifier 检查当前任务，Eval 帮助评估整套系统。前者直接影响这一轮是否通过；后者可以在一组真实案例上比较成功率、误判、人工接管、耗时和成本。评估结果能帮助我们判断：加上 Loop 后，系统是否真的更好用。
概念可以组合，名称也可能因产品而异。只要始终沿着“目标、反馈、状态、下一步、停止”这条线追问，就不容易把工具数量或重复次数误当成闭环能力。
一个库迁移任务，Loop 怎样把它带到终点？
下面用一个简化示例，把前面的机制放到同一件事里：将一个项目从日期库 Moment.js 迁移到 Day.js。
两个库的部分 API 看起来相似，但迁移并不只是替换名字。相对时间、时区、本地化格式等能力，需要逐项确认，有些还需要额外插件或配置。遗漏可能表现为报错，也可能表现为时间显示与预期不符。
因此，任务同时包含两个要求：清理约定范围内的旧库用法，并保持约定的时间处理行为不变。
这类跨文件任务可能需要多轮推进。是否需要下一轮，应由实际缺口决定。
第 0 轮：先写完成条件，再启动 Agent
就像交作业前先说明评分标准，迁移开始前，也要把“做到什么程度算完成”写清楚。
一张任务卡可以包含：
项目 |
示例约定 |
目标 |
将约定范围内的 Moment.js 用法迁移到 Day.js，保持相关时间行为 |
完成条件 |
旧库引用与依赖按约定清理；相关测试、类型检查和时间显示检查通过 |
修改边界 |
只调整迁移所需的代码与依赖，不改无关业务逻辑 |
预算 |
最多尝试 6 轮，并设置时间或费用上限 |
停止与求助 |
达标则结束；持续无进展、存在无法判断的行为差异或需要额外权限时交给人 |
证据要求 |
各项检查对应同一份当前候选代码，记录迁移起点与最新版本 |
这里有一个容易忽略的细节：证据必须针对同一份产物。
不能拿修改前的测试通过记录，搭配修改后的旧库清理结果，拼成“全部完成”。任务需要记录开始时的源版本，以及当前候选代码的版本。若迁移期间源代码发生变化，还应识别变化，重新判断是否需要同步和复验。
时间显示检查也需要有意义。可以把迁移前的重要场景输出保存为基线，再与迁移后对比，而不只是确认测试命令运行过。
此时，Harness 提供工具、隔离环境和日志；Skill 提供迁移方法；Goal 保存完成条件；State 记录版本、预算与待办清单；Controller 启动第一轮。
第 1 轮：完成部分工作，留下明确缺口
假设约定范围内有 40 个文件需要迁移。
Agent 先搜索旧库引用，从常见用法开始逐项替换，每完成一批就运行检查。处理相对时间时，发现需要接入对应插件，再继续修改。这些工具结果已经在影响当前 Run 内的动作。
第一轮结束，32 个文件完成迁移，但还有 8 个涉及复杂时区用法，另有 3 项时区相关检查没有通过。
Verifier 对照任务卡，给出判断：有进展，但未完成。系统留下一个检查点（checkpoint），也就是下一轮能够直接读取的进度记录：
round:1
max_rounds:6
source_version:<迁移起点的代码版本>
candidate_version:<当前候选代码版本>
completed:
-32个文件已迁移
-相对时间插件已接入，相关检查通过
remaining:
-8个时区相关文件待处理
-3项时区检查失败
-旧库依赖尚未移除
next_step:处理剩余时区用法，随后重新运行完整验收Controller 看见剩余问题明确、任务已有进展、预算仍然充足，于是启动第二轮。
下一轮拿到的是最新进度和具体缺口，无须从最初的任务描述重新猜测。
第 2 轮：证据齐了，才标记完成
Agent 集中处理剩余时区用法，接入所需插件与配置，生成新的候选代码。
随后，受控的验证流程针对这份代码重新检查：旧库引用是否按约定清理、依赖是否移除、测试和时间显示检查是否通过，以及迁移起点是否发生了需要处理的变化。
验证过程应受到保护。执行者不能为了获得通过结果，随意删除失败用例、修改基线或绕过验收。
如果约定的证据全部满足，Controller 才把任务标记为成功；如果仍有缺口，就结合风险、进展和预算决定下一步。
第二轮发生，是因为第一轮留下了明确问题。是否出现第三轮，则取决于第二轮的验收结果。
前者体现反馈，后者体现停止条件。
同时也要记住：通过检查，只能说明当前产物满足了已定义、已覆盖的条件。重要业务行为需要足够的验收覆盖，必要时仍要人工审查。
同一个 Loop，可以怎样实现？
理解了反馈链，再选工具会更清楚：任务需要补上的是再次唤醒、结束前检查、复杂编排，还是跨会话保存进度？
不同产品可能提供名为 /loop、/goal 的入口，也可能通过 Hook、Workflow 或 SDK 实现。名称相似，不代表机制和边界相同，具体能力应以对应产品和版本的文档为准。
从工程职责看，可以分为几类。
实现方式 |
主要解决什么 |
仍需明确什么 |
定时或事件触发 |
到时间、收到事件后启动运行 | 怎样读取上轮状态，如何判断任务完成 |
结束前检查机制，如 Stop Hook |
一轮准备结束时检查结果，必要时反馈问题 | 验收是否可信，何时强制停止，能否跨会话持续 |
目标评估机制 |
对照目标评估当前结果，未达标时推动继续 | 评估器能看到哪些证据，是否能独立调用工具验证 |
Workflow |
显式组织循环、分支、并行和角色分工 | 中断后如何恢复，状态如何保存，谁负责验收 |
外部 Controller |
管理队列、持久状态、预算、权限与恢复 | 工程成本是否值得，外部副作用怎样控制 |
再次唤醒，只是闭环中的一步
定时任务可以负责“十分钟后再看一次测试状态”，事件触发可以负责“测试结束后启动检查”。但每次被叫醒后，系统仍需要读取已有进度，识别新结果，再决定下一步。
如果每次都只从最初的 Prompt 开始，没有跨轮状态与验收规则，就很容易变成定时重复。
做法、约束和验收规则适合集中保存在可维护的 Skill、Workflow 或项目文件中；调度配置主要保存触发条件和调用入口，减少多处复制后更新不一致的问题。
结束前检查，要分清“自报”与“验证”
有些机制会在 Agent 准备结束时拦截，检查是否满足要求，再决定是否继续。
这里要看清检查依据：是模型输出了一句完成声明，还是系统实际运行了测试？如果额外的评估器只能读取对话，不能查看代码或调用工具，它就依赖执行过程提供充分、可核对的证据。
增加一次评估可以帮助发现遗漏，但验证能力取决于评估器实际能看到、能检查什么。
复杂任务，需要把生命周期管起来
当任务需要分支、并行、角色分工时，可以用 Workflow 显式组织流程。但保存了一份工作流脚本，只说明程序可以再次运行，不等于上一次做到哪里的进度已经保存。
如果任务还要跨会话、跨机器或长期运行，就需要更持久的状态和恢复机制。此时可以由外部 Controller 管理业务生命周期，Agent 负责其中一轮的执行。
它的主线依然很简单：
读取状态 → 执行与收集证据 → 保存进度 → 检查完成、停滞、风险和预算 → 决定下一轮或退出。
难点在于边界：中断后从哪里恢复，重复运行会不会产生重复操作，谁可以修改验收规则，哪些动作必须交给人。
实现应从最小机制开始。只有在持久运行、复杂编排或外部操作确实需要时，再增加控制层。
什么时候值得构建，怎样开始？
先判断：新反馈会不会改变下一步？
更适合 Loop 的任务，通常需要多轮反馈，有清楚的验收方式，能观察到动作结果，并且反复检查、等待或交接已经占用了较多人工。
如果一次调用或固定脚本就能稳定完成，额外的循环往往只会增加耗时和成本。如果目标主要依赖模糊感受，或者系统没有权限、没有有效反馈，也应先补齐这些条件。
开始前，可以选几个真实案例，记录人每次为什么说“继续”，又根据什么判断“完成”。其中重复出现、规则稳定的部分，就是最值得交给系统的控制逻辑。
先设计验收，再优化提示词
不知道怎么判断完成，Agent 再努力，也可能只是更快地产生难以验收的结果。
事实性要求优先交给测试和规则，语义与体验可以引入独立评审，业务取舍和高风险操作保留人工判断。Prompt 中的“最多四轮”“不要发布”也应有预算计数和工具权限等实际机制支撑。
同时让每轮工作尽量小，并保存检查点。需要跨会话推进时，将进度写入后续可读取的文件、数据库或任务系统，不能只依靠对话仍在上下文里。
自动化的速度，要与人的验收能力匹配
Loop 可以减少逐轮盯守，但团队仍然需要理解产物。
十个 Agent 在十个独立工作目录里修改代码，解决了部分文件干扰，却没有同时创造十倍的审查、测试、合并和回退能力。就像十个小朋友分桌写作业，老师仍然需要时间认真批改。
因此，并发数量应与验收能力匹配。结果应附带变更摘要、检查证据和回退信息；架构取舍、重要业务含义、生产发布等环节，保留必要的人工关卡。
人的注意力也是预算。没有新变化的轮次可以安静记录，关键进展、完成、失败或需要接管时再提醒，才能真正减少监督负担。
最后，用一组真实任务比较有无 Loop、不同控制策略下的成功率、误判、停滞、人工接管、耗时和成本。模型或工具升级后，也应重新检查：以前需要的复杂机制，是否仍然有价值？
今天就能开始的最小 Loop
第一次可以选一个低风险、能够自动检查的小任务，例如修复一项失败测试，先明确六件事：
- 目标：当前输入是什么，完成后必须满足哪些事实。
- 验收：用哪项测试、查询或明确规则检查。
- 权限：允许修改什么，哪些动作需要人工处理。
- 预算：例如先限制在 2～4 轮，并区分成功、停滞与超预算。
- 进度：每轮保存版本、动作、证据、剩余问题和下一步。
- 推进方式：由什么机制启动下一轮，何时等待、结束或交给人。
当新反馈能改变下一步，证据对应当前输入，系统也能因明确原因停下，一个最小的 Loop 就形成了。
回到最初那本作业。独立完成一件事，需要的不只是动手能力，还包括检查、订正、记住进度，以及知道何时求助。
Agent 同样如此。Loop Engineering 将这些环节组织起来，让每一轮执行有依据，让完成判断有证据，也让人把更多精力放到目标与关键决策上。
你也可以在 TraeCode 中体验这套思路
TraeCode 已支持 /goal 模式，它正是 Loop 思路在实际编码任务中的一种落地：围绕一个明确目标，根据执行结果和反馈持续推进任务。就像小朋友拿着作业要求完成练习、检查并订正，你可以先告诉 Agent 要完成什么、怎样才算完成，以及哪些范围不能改。
例如，将“帮我修一下这个 Bug”写成“修复日期显示错误，保持其他功能不变，并运行相关测试验证结果”。目标和验收标准越清楚，后续执行与检查就越有依据。
你可以从一个边界清晰的小任务开始，立即在 TraeCode 中使用 /goal，体验从逐轮补充指令，到围绕目标持续推进的协作方式；同时关注它提供的结果和验证证据，在需要业务判断或关键决策时参与其中。
本文作者咸鱼，TRAE 核心用户，来源@TRAE.ai。原文链接：https://mp.weixin.qq.com/s/F0hhVT2DLrAHWe_Xf_lipA