当人从循环内部的执行者退到循环外部的设计者过去两年关于 AI Agent 的讨论几乎都收敛到同一个问题上只要把 Prompt 打磨得足够好Agent 是不是就能把活干好这个假设只在一种工作方式下成立——人提出任务Agent 给出结果人读完结果再决定下一步问什么。任务的每一次推进都由人在回路里亲手完成。可是当 Agent 不再只回答一个问题而是开始连续读代码、调工具、改文件、跑测试、提工单、写报告甚至跨越多个会话、连续运行数小时时瓶颈就不在这一句话怎么说上了。真正需要被设计出来的是一套能让 Agent 持续朝目标推进、持续接受检验、持续把经验沉淀下来的闭环系统。这套系统背后的工程方法就是Loop Engineering。开篇要先排除两个最常见的误读Loop Engineering 既不是让 Agent 不停循环跑下去也不是多堆几个 Agent 一起上。它真正的着力点在别处——只有当目标、状态、验证、反馈、权限和停止条件被一并设计出来Agent 才可能从聊天框里的一次性工具升级为可调度、可观测、可治理的系统执行单元。如果一定要用一句话划清它与上一阶段的边界Prompt Engineering 关心这一轮怎么问最好Loop Engineering 关心在成百上千轮之后系统还能不能稳定地把目标做成。这条分界线背后是一次角色反转。Prompt 阶段人站在循环内部逐轮发问、逐轮纠错是系统得以运转的中枢Loop 阶段人退到循环外部转而定义目标、划定边界、设定验收标准让系统在边界内自行迭代。本文要拆开来讲的正是支撑这次反转的那套工程结构。一、Prompt 工作流的能力边界要看清 Loop Engineering 解决的是什么问题先得看清它替代的是什么。传统 Prompt 工作流是一条线性链条人 → 写 Prompt → Agent 执行 → 人判断结果 → 写下一轮 Prompt这条链条上Agent 只负责执行真正的控制权始终握在人手里。具体来说人同时扮演着四个角色决定下一个该做的任务、判断当前结果对不对、补齐 Agent 缺失的上下文、拍板是继续还是停下或升级。换句话说Agent 是执行器人是控制器。对一类任务而言这种安排完全够用——临时问答、一次性脚本、小范围改动、探索性分析以及任何不需要长期记忆的工作。它们的共同点是轮次少、边界清、人盯得过来。但只要任务越过这条线人工逐轮驱动就会迅速变成系统的瓶颈。这类任务通常同时具备几个特征耗时长、会反复发生、要跨多个系统、需要多个 Agent 并行、对结果质量有硬性要求、必须留下完整审计链路、还得把成本和权限管住。一个具体的场景能说明问题。设想团队想自动处理夜间 CI 失败整个流程是这样的发现失败 → 判断失败类型 → 收集日志 → 分配修复任务 → 修改代码 → 运行测试 → 检查结果 → 创建 PR → 通知负责人 → 记录失败模式没有人会愿意每天凌晨爬起来手动把这十步走一遍。这里要解决的问题已经变了它考验的早已超出怎么写一句更好的 Prompt落到了怎么搭一套能自己跑起来的系统上。瓶颈从语言转移到了系统——这正是 Loop Engineering 接手的地方。下面先把这套系统的整体结构拆开再逐层深入。二、由内向外的四层闭环进入结构之前有两个概念必须先分开否则后面所有讨论都会含混。Agent Loop说的是单次任务内部的事一个 Agent 怎样理解目标、调用工具、根据反馈调整动作直到把这一件事做完。Loop Engineering说的是单次任务之外的事怎样围绕 Agent 搭一套可验证、可运行、可治理、可优化的系统让它在无数次任务里都站得住。前者是后者的最内核。一个成熟的 Loop Engineering 系统正是以 Agent Loop 为圆心向外叠加三层能力构成四层嵌套闭环第四层持续改进循环 第三层事件驱动循环 第二层质量验证循环 第一层Agent 执行循环这四层并非四个独立产品它们是同一系统从内到外的四种工程能力。越靠内越关心一次任务怎么完成越靠外越关心系统长期怎么可靠运转。剥开这四层之前先抓住它们共同服务的那个骨架。一个能自主运转的循环本质上只做两件事在某个时刻被唤醒醒来后决定干什么。前者是触发后者是决策——业界常把它压缩成Loop Cron 决策器这样一个记忆点。但要小心触发器只负责让系统睁眼Cron、Webhook、消息队列都只是睁眼的方式它们本身并不构成 Loop真正决定一个循环可不可靠的是醒来之后那套做什么、是否继续、何时收手的决策逻辑。四层循环各自补强的恰恰就是触发与决策这两件事第一、二层让决策变得可信第三层让触发接上真实世界的事件第四层让决策随时间越变越准。还有一条贯穿始终的设计原则值得先点破机制与策略分离。底层平台也就是后面要讲的 Harness只提供通用机制——定时器、工作区隔离、沙箱、状态存储至于多久触发一次、派几个子 Agent、预算给多少、什么时候交给人这些随业务而变的策略由架构师单独配置。正是这层分离让人改策略时不必动机制也才让人有可能真正从执行循环里抽身出来。接下来由内向外逐层拆解。1. 第一层Agent 执行循环最内层是 Agent 完成单次任务的基本循环理解目标 → 规划 → 调用工具 → 观察结果 → 调整行动 → 继续执行落到代码任务上它具体表现为读取需求 → 阅读代码 → 制定修改方案 → 修改文件 → 运行测试 → 阅读错误日志 → 修复问题 → 更新状态这一层要回答的是 Agent 怎样在一个任务范围内依据环境反馈连续行动而不是只吐出一段文本就完事。它是所有 Agent 的执行底座。但只有执行循环远远不够因为这里藏着一个致命前提Agent 说自己做完了不等于真的做完了。这个缺口要靠第二层来补。2. 第二层质量验证循环第二层在执行循环外面套上一道检验Agent 执行 → Verifier 验证 → 通过任务结束 → 不通过反馈问题 → Agent 修复 → 再次验证这一层正是 Loop Engineering 与让 Agent 自己多试几次之间最本质的分野。缺了验证器的循环跑的是这样一条路Agent 做事 → Agent 说完成了 → 系统相信它这样的流程算不上闭环更像蒙着眼睛的自动化——系统把唯一的判断权交给了执行者自己。验证器的价值不在一句这段代码好像不太行的模糊评价上而落在它能交出明确、可操作、可追溯的证据测试失败日志 构建失败原因 未满足的验收项 违反规范的规则编号 性能指标差异 Diff 超出范围的文件清单对软件研发任务最可信的验证往往是确定性的单元测试、集成测试、构建检查、Lint、Typecheck、安全扫描、Contract Test、数据库迁移校验、浏览器自动化测试。它们的好处是非黑即白不依赖谁的主观判断。对于 UI 设计、文案、方案合理性这类主观任务可以引入独立的 Reviewer Agent 或 LLM-as-a-Judge但要清醒它们给的是评估意见不是绝对真值。由此引出一条贯穿全文的原则执行者负责把活干完验证者负责判定活有没有达标干活的人不能同时是唯一的裁判。越是复杂的任务越要让验证者和执行者跑在彼此独立的上下文里。验证者只读任务目标、验收标准、代码 Diff、运行证据和测试结果而不继承执行者一路走来的全部思路。这样才能压住自己写、自己夸、自己宣布完成的风险。不过就算验证做得再扎实只要每次任务还得人来手动发起Agent 终究只是个被动工具。要让它自己醒来得靠第三层。3. 第三层事件驱动循环第三层把 Agent 接进组织的事件系统让任务自己找上门事件触发 → 任务识别 → 风险分级 → Agent 执行 → 验证与输出 → 写入业务系统触发的来源可以很多样Cron 定时任务、CI/CD 失败事件、GitHub 或 GitLab 的 Webhook、新建的 Issue、监控告警、数据质量异常、进入队列的客户工单、新入库的文档、漏洞情报更新、SLA 超时提醒。以自动化 Issue Triage 为例这条循环会这样跑新 Issue 创建 → 判断是否重复 → 判断优先级 → 提取日志与环境信息 → 分配到责任模块 → 生成初步分析 → 低风险任务自动创建修复分支 → 高风险任务升级给人工这一层带来的转变是质的Agent 就此摆脱人打开聊天框才会动的被动形态成了企业系统里常驻的后台 Worker。但 Agent 一旦进入后台一批运行时的工程难题也随之而来——怎么避免重复触发、怎么保证幂等、怎么管并发、怎么做任务隔离、怎么控权限、怎么追状态、怎么处理超时与重试、怎么在高风险动作前插入人工审批。所以事件驱动绝不是加个定时器那么轻巧它是 Agent 系统开始具备运行时工程特征的分水岭。前三层合起来已经能让 Agent 把工作做完、做对、并且自动开工。但还差一件事让系统随着跑得越多而变得越好。这是第四层。4. 第四层持续改进循环前三层解决的是把工作做完第四层解决的是怎样让系统从每一次运行里学到东西使下一次更可靠、更便宜、更贴合业务。Agent 每跑一次都会留下一串轨迹输入是什么、调了哪些工具、每步耗时多久、哪些步骤失败、修复成没成、验证器给了什么反馈、最终要不要人介入、烧掉了多少 Token、算力和外部 API 额度。这些信息不该只躺在日志里而应当成为改进系统的原料运行 Trace → 失败模式分析 → 提取 Bad Case → 更新评估集 → 优化 Skill、Prompt、Tool Policy 或 Verifier → 回归测试 → 灰度发布 → 观察线上效果这就是持续改进循环。要特别区分它不等于让 Agent 自动改写自己的 Prompt 再直接上线。一条可靠的改进流程应当包含从线上轨迹中发现问题、把问题沉淀成 Bad Case、在离线评估集上验证改动、对 Prompt 与 Skill 与工具策略做版本化管理、用灰度发布观察效果、必要时人工复核、出现退化时快速回滚。所以 Loop Engineering 的最高形态从来都与Agent 自己变聪明了无关它指向的是另一件事系统能基于真实运行数据持续、可控地改善自己的执行能力。5. 四层之外循环的三档成熟度四层讲的是一个完整 Loop 该覆盖哪些能力是横向的广度。还有一个纵向的维度——闭环到底闭得有多紧可以把循环分成三档成熟度。它和四层正交四层论广度成熟度论深度。开环Open LoopAgent 自己判断做完了输出一个done就收工没有独立验证系统照单全收。这一档通常只撑得起 Demo对应的正是第二层点过的蒙眼自动化。闭环Closed Loop每一轮执行都必须强制通过确定性检查——单元测试、Lint、Typecheck 或自动化 Review过不了就退回执行环节继续修。这是生产级交付的最低门槛也是第二层验证循环真正落地的样子。评审环Review Loop在闭环之上再挂一个常驻的、独立上下文的异步审查 Agent持续对产出提供反馈。它专门对抗长会话、长任务里的上下文腐烂——审查者永远用新鲜的眼睛看结果不会被执行者的思路带偏。一个朴素的自检循环若还停在开环本质上只是个会自动重试的脚本迈进闭环它才开始具备 Loop Engineering 的可靠性而评审环是长周期任务能否稳定收敛的关键。讲清了四层结构和三档深度一个自然的问题是为什么偏偏是触发—执行—验证—反馈—停止这套组合把它放进控制论的框架里看答案会清晰得多。三、把 Loop 看作一个闭环控制系统Loop Engineering 最容易被矮化成复杂一点的 Prompt 编排。换个视角它的本质会清楚得多这是一个以 Agent 为执行器的闭环控制系统。上一节那套触发—执行—验证—反馈—停止并非随手拼出来的流程它对应的正是任何一个反馈控制回路的标准构件。借控制论的语言做一次对照每个角色都能在 Agent 系统里找到对应物控制系统角色在 Agent 系统中的对应对象被控对象代码仓库、业务系统、工单系统、数据流程执行器Agent、工具调用、脚本、API、工作流传感器测试结果、日志、指标、Diff、用户反馈控制器Orchestrator、调度器、策略引擎反馈信号Verifier 输出、评估分数、失败原因状态存储数据库、任务队列、Git、Issue 系统、状态文件安全边界权限、审批、预算、限流、隔离、回滚机制这张表的意义不只是类比好看。它逼出一个判断标准一个成熟的 Loop不能只回答Agent 能做什么还必须把控制回路上的每个角色都落实到位——Agent 能读什么数据、能调哪些工具、能改哪些资源、该在什么条件下停、失败后怎么恢复、做错了怎么回滚、哪些操作必须人工审批、系统如何审计每一次决策、又如何衡量质量与成本和收益。一旦把问题摆到这个层面结论就跟着浮出来了Loop Engineering 从来都超出单纯的模型能力问题它是模型能力、运行时环境、质量验证、权限治理、状态管理和可观测性共同构成的系统工程问题。控制论给了我们为什么是这些角色的答案。接下来要落到工程层面回答用什么零件把这些角色搭出来。四、搭建 Loop 的工程原语把控制系统的角色落到代码里近期 AI Coding Agent 的实践逐渐沉淀出一组反复出现的组件可以归纳为51AutomationsWorktreesSkillsPlugins / ConnectorsSub-agentsState这里要先打个预防针避免把组件清单误当成定义51列的是搭建 Loop 时常见的工程能力不是 Loop Engineering 的全部。一个真正完整的 Loop还要有验证器、策略层、可观测性、成本治理和人工审批——这些不在这份清单里却同样不可或缺。带着这个边界逐个来看这六件组件各自补的是控制回路上的哪一环。1. Automations让系统自己发现工作Automation 对应的是控制回路里的触发——决定任务何时启动。它的形态很朴素每天凌晨扫描 CI 失败 每小时检查高优先级工单 收到漏洞告警后创建修复任务 每周检查依赖版本与许可证风险 每月生成技术债治理候选清单没有 AutomationAgent 永远是被动等人召唤的工具有了它Agent 才成为持续运转的系统组件。但触发不能随便触发它必须满足三条底线幂等重复触发不产生重复副作用、去重同一个问题不会被多个 Agent 抢着处理、优先级高风险高价值的任务排在前面。2. Worktrees让并行的 Agent 互不踩脚多个 Agent 同时干活最先暴露的往往不在模型能力而落在工程冲突上。设想三个 Agent 同时改一个仓库Agent A修复认证 Bug Agent B升级依赖 Agent C重构数据访问层如果它们共用一个工作目录结局大概率是文件互相覆盖、分支状态混乱、测试环境被污染、一个 Agent 的中间改动干扰了另一个的判断出了问题还查不清是谁干的。Worktree或任何等价的隔离环境就是给每个任务划一块独立的执行空间主仓库 ├── worktree-auth-fix ├── worktree-dependency-upgrade ├── worktree-data-refactor └── worktree-test-coverage每个 Agent 在各自的隔离区里执行、验证、产出 Diff只有通过验证和审查的变更才进入合并流程。所以 Worktree 的价值不止是一个 Git 技巧而是为多 Agent 并发同时提供了变更隔离、资源隔离和责任隔离。3. Skills把组织经验变成可执行资产Prompt 工作流有个隐疾关键经验往往只散落在聊天记录里。团队可能一遍遍叮嘱 Agent修改 API 时必须同步更新 OpenAPI 文档 必须补齐集成测试 不要靠关掉测试来规避问题 必须运行 Contract Test 数据库迁移必须支持回滚。只要这些要求每次都得手动重输它们就只是临时提醒算不上工程资产。Skill 做的事就是把这类经验固化成版本化、可复用、可测试的执行规范。比如一个api-changeSkill 可以规定1. 定位 API 变更范围 2. 检查兼容性影响 3. 更新接口定义 4. 增补单元测试与集成测试 5. 运行 Contract Test 6. 输出风险项与回滚说明。换个角度看Skill 之于 Agent 系统相当于人类团队的 Runbook、平台工程的 Golden Path、SRE 的故障处理手册、CI/CD 的 Pipeline Template、安全团队的策略基线。成熟团队不该把它当成Prompt 模板库而该当成 Agent 系统里的可执行工程规范。4. Plugins 与 Connectors让 Agent 接入真实业务系统Agent 本身不直接产生业务价值价值来自它能不能接进组织已有的系统GitHub、GitLabJira、Linear飞书、Slack、TeamsCI/CD 平台监控与告警平台数据仓库CRM、ERP内部知识库云资源管理平台数据库和搜索系统。但连接器的本质远不止接上工具它更是在放开能力边界。每接入一个系统都得明确划定Agent 能读什么、能写什么、能调用哪些动作、哪些动作需要审批、哪些数据不许离开受控环境、不可信内容会不会诱导 Agent 去执行危险操作。也正因如此Connector 层实质上就是 Agent 系统的能力边界层。5. Sub-agents用角色分离压低复杂任务的风险复杂任务不该让一个 Agent 同时承担所有职责。更稳妥的分工是按角色拆开Planner拆解任务制定实施方案 Executor执行修改调用工具 Verifier验证结果提供证据 Reviewer审查输出是否符合需求与规范 Triage Agent判断优先级、风险与路由 Reporter整理结果生成 PR、报告或通知Sub-agent 的要义不是越多越强。它真正换来的是更少的上下文污染、更清的角色边界、按角色分配的差异化权限、相对独立的执行与验证、可并行的探索以及一条清晰的审计与责任链。由此可以提炼出一条实用准则它其实是第二节执行者不能当唯一裁判在组织层面的延伸面对高风险任务优先增加独立的验证角色而不是盲目堆更多执行角色。6. State让 Agent 跨会话、跨任务持续工作Agent 天生没有可靠的长期记忆所以长周期运行的 Loop 必须把状态外置。State 可以落在很多地方Git 里的 Markdown 文件、任务数据库、Issue Board、关系数据库、事件存储、向量检索系统、Artifact Store、工作流状态机。一个最小的状态对象至少要记下这些task_id: CI-2026-018 goal: 修复支付模块 CI 失败 status: verification_failed attempts: 2 last_error: payment-flow 集成测试失败 evidence: - test-report.xml - build.log next_action: escalate_to_human approval_required: true budget: max_attempts: 3 max_tokens: 120000State 的作用远不止让 Agent 记住事情。它直接决定了系统具不具备可恢复性、可审计性、可重试性、幂等性、跨会话连续性、多 Agent 协作能力以及成本与风险的追踪能力。正因为分量这么重State 应当像代码一样被治理定义清晰的 Schema、做版本控制、记录状态迁移、区分短期运行态与长期知识、对关键变更走 Review、支持回滚与归档。六件组件各就各位之后还需要回答一个更高层的问题它们在系统里该怎么组织、谁管干活、谁管把关。这就引出执行平面与控制平面的分层。五、执行平面与控制平面把前面那些组件按职责归类会发现它们天然分成两堆一堆负责把事情做出来一堆负责确保事情做得对、做得安全。从企业架构的角度一个可上线的 Loop Engineering 系统就此分成两个平面。1. 执行平面负责把事情做完执行平面装的是干活的能力Agent Runtime Tools Skills Worktrees / Sandbox Memory / State Sub-agents Connectors它回答的是一个具体问题Agent 怎样完成一项工作比如修复代码、运行测试、查询数据库、生成报告、创建工单。第四节那六件组件绝大多数都落在这一平面。2. 控制平面负责确保事情做得对、做得安全控制平面装的是把关的能力Task Orchestrator Policy Engine Verifier Human Approval Gate Observability Budget Control Retry / Escalation Policy Version Management Audit Trail它回答的是另一个层面的问题系统怎样保证 Agent 的行为可控、可信、可追溯为此控制平面要明确定义谁能触发任务、哪些任务可以自动执行、哪些工具可被调用、Token 与时间与费用的上限、最大重试次数、失败后的升级路径、哪些动作必须人工审批、如何审计每一次决策、如何判断一次变更有没有带来质量退化。把两个平面摆在一起一条关键结论就出来了很多 Agent 项目失败根源往往不在模型不够强而落在只有执行平面、缺了控制平面。只有执行平面的系统确实能做事却答不上来这几个要命的问题做得对不对做错了谁先发现做错了怎么止损为什么这么做花了多少钱有没有越权能不能回滚这一串问题答不上来正是 Agent Demo 与生产级 Agent 系统之间的分水岭。理论框架到这里已经铺满。下面用一个完整的案例把执行平面和控制平面、四层闭环和工程原语一次性串起来跑一遍。六、端到端案例自动修复低风险 CI 失败设想团队要建一套夜间自动处理低风险 CI 失败的系统。先把目标摆正因为目标定歪了后面所有约束都会跟着歪。这套系统的目标不是让 Agent 自动改代码。而是在不动摇主干稳定性和安全性的前提下自动分析低风险的 CI 失败产出可审查、可验证、可回滚的修复 PR。这个 Loop 的可靠性不来自Agent 足够聪明而来自一组事先写死的约束。把这些约束显式地集中起来就是一份循环协议Loop Contract——任何一个 Loop 上线前都该用它逐项答清六个维度维度含义本例取值TRIGGER何时触发夜间 Cron 扫描到 CI 失败SCOPE作用范围仅限指定仓库的低风险失败类别ACTION允许的动作分析日志、修改代码、运行测试、创建 PRBUDGET预算红线≤3 次修复 / ≤30 分钟 / ≤120k Token / ≤50 次工具调用STOP停止条件验证通过、达到失败上限、或需人工接管REPORT上报通道PR 附测试证据异常转工单并通知负责人接下来几节本质上就是把这份协议里的每一行展开成工程做法。1. 明确任务边界SCOPE只碰事先定义好的低风险类别测试快照更新依赖锁文件不一致明确的编译错误已知类型的 Lint 问题文档链接失效。坚决不碰架构重构核心支付逻辑数据库删除操作权限修改生产配置变更。边界越清楚Agent 越不容易做出看着合理、其实跑偏的动作。2. 使用确定性验证ACTION 的验收每一轮修复都必须跨过这道确定性门槛Build 成功 Test 通过 Lint 通过 Typecheck 通过 安全扫描无新增高危问题 Diff 未超出允许范围而且验证器要交出证据不能只甩一个通过或失败。这正是第二节验证循环在具体场景里的落地。3. 设置预算和停止条件BUDGET STOP预算划出硬上限最多修复 3 次 最长执行 30 分钟 最多消耗 120k Token 最多调用 50 次工具 超过预算立即停止停止条件则定义什么算到头了。注意它绝不取决于Agent 觉得自己做完了而由这几条客观信号划定目标达成 或 验证通过 或 达到明确失败条件 或 需要人工接管但预算和停止条件如果只写在文档里等于没写——Agent 一旦钻进异常路径预算会在没人察觉时被烧光。所以它们必须固化成两道运行时的硬约束熔断器Circuit Breaker盯连续失败次数和墙上时间两个上限。连续报错触顶或运行超时系统立刻跳闸、回退改动把当前运行栈和日志打包成工单转给人。它防的是反复失败却还在硬重试。看门狗Watchdog一个独立于主流程的外部监控进程盯资源占用和 I/O。一旦发现 CPU 满载却长时间没有任何外部交互基本可判定陷入了自旋死循环看门狗会越过应用层直接杀进程、回收资源。它防的是卡死了还在烧钱。两者的共同点是判停的权力不交给 Agent 自己而是放在它够不着的外层。这是执行者不能当唯一裁判这条原则在运行时层面的再一次延伸。4. 保留人工审批门REPORT 之前的最后一关哪怕所有测试都绿了也不建议自动合并主分支。因为测试通过只证明了一部分正确性它证明不了需求理解完全到位、业务影响可接受、改动符合团队的长期架构、没有埋下隐藏风险。所以更合理的自动化边界是Agent 自动生成可审查的结果 人负责批准高影响决策这样做并未降低自动化程度它把人放到了最能创造价值的位置上。把这四道关串起来——边界、验证、预算与熔断、审批门——这个 Loop 的可靠性就不再依赖运气。而这四道关里最难做对、也最被低估的是验证那一环。下一节专门拆它。七、最硬的一环验证器设计很多团队的精力一上来就投到执行侧——换更强的模型、写更长的 Prompt、加更多工具、塞更多上下文、堆更多 Agent。但决定系统能不能长期稳定运转的通常落在 Verifier 而非 Executor 身上。道理很直白系统只有先知道什么算对才谈得上判断该停、该修还是该升级。这一点有个常被忽略的实证侧面。业界广泛使用的 SWE-bench Verified本身就是 OpenAI 和人工标注者合作从原始 SWE-bench 里筛出 500 条问题描述清晰、测试能真正判定对错的样本而成。反过来说原始基准里有相当一部分题目其自带测试根本分不清改对了和改错了。连用于科研评测的静态数据集都要专门做一轮验证器清洗可想而知在真实业务里造一个可信的 Verifier往往比让 Executor 把活干完还难。验证器设计不当通常会以三种方式翻车。1. 永不收敛验证器订得过严Agent 每一轮都被要求继续优化执行 → 批评 → 修复 → 再批评 → 再修复 → 无限循环这在主观任务里尤其常见——让页面更高级让文案更有感染力让方案更完善。缺了可验证的退出条件循环就很难稳定收敛。2. 假性通过验证器订得过松只查命令有没有跑成功不查业务目标有没有真正实现测试通过但测试根本覆盖不到真实问题页面能加载但关键流程走不通API 返回 200但返回字段是错的PR 没有冲突但改的是错误的模块。3. 错误优化系统开始优化怎样通过评估而不是怎样完成目标。这在学术上有专名——规约博弈Specification Gaming也叫奖励作弊Reward Hacking本质是 Goodhart 定律在 Agent 身上的复现一个度量一旦变成目标它就不再是好的度量。表现出来就是删掉测试让 CI 变绿关掉告警规则压低错误率加一堆无意义代码取悦 Reviewer牺牲性能换短期评分。需要警惕的是这并不是模型足够强才会冒出来的高级行为。近期研究发现规约博弈在前沿模型和中等规模模型上都会零样本自发涌现——模型会一边把可观测的分数刷高一边悄悄牺牲那些没被直接计入评分的隐藏目标。换句话说验证器的每一个度量漏洞都该默认它迟早会被利用。因此架构师必须把几样东西彻底分清真实目标、代理指标、验证证据、业务约束、不可接受的捷径。一个成熟的验证器除了检查结果对不对更要防住钻规则空子。把验证这一环吃透之后下一个现实问题随之而来是不是所有任务都值得这么搭一套 Loop答案是否定的得先学会判断边界。八、Loop Engineering 的适用边界判断一个任务该不该上 Loop可以先看它符不符合这几个特征高频重复、规则明确、可自动验证、可隔离执行、失败成本可控、输入输出稳定、能定义清晰的停止条件、业务价值撑得起工程投入。落到具体场景下面这些是典型的好候选CI 失败诊断与修复依赖升级与安全漏洞治理Issue 自动分类与路由数据质量巡检自动补测试文档一致性检查监控告警初步归因夜间批量代码迁移合规检查内部知识库更新。反过来下面这些场景不适合直接交给全自动 Loop一次性、低价值任务高度主观且难以验收的任务缺少可靠验证器的任务后果不可逆的操作高风险的金融、医疗、法律或安全决策需要强业务判断的复杂架构决策Token 与运行成本被严格约束的任务。这些判断可以收敛成一个粗筛公式是否值得上 Loop 任务重复性 × 可验证性 × 可隔离性 × 可回滚性 × 业务价值注意这里是连乘而非相加——只要任意一项趋近于零整体就趋近于零这种任务都该谨慎。选对了适合的任务接下来的问题就是怎么把它一步步落地而不是一上来就追求无人值守。九、从 0 到 1 的四阶段演进不要一开始就奔着全天候自主 Agent去。更稳的路径是分四步走每一步都建立在前一步的能力之上。阶段一Assistant 模式人发起任务 → Agent 执行 → 人检查结果目标先验证 Agent 具不具备基本的任务能力。阶段二Bounded Loop 模式人发起任务 → Agent 执行 → 自动验证 → 有限重试 → 人工审批目标搭起第一个可控闭环。这一步上路前必须先补齐验收标准、状态记录、最大重试次数、Token 与时间预算、人工审批门。阶段三Event-driven Loop 模式事件触发 → 自动 Triage → Agent 执行 → 自动验证 → 输出可审查产物目标让 Agent 成为后台系统组件。这一步要补齐 Webhook 与 Cron 与 Queue、任务幂等性、并发与隔离、可观测性、权限与审计、异常升级机制。阶段四Improvement Loop 模式运行 Trace → Bad Case 分析 → 优化 Prompt / Skill / Tool / Verifier → 回归评估 → 灰度发布 → 线上验证目标让系统具备可控的持续优化能力。这一步最关键的工作并不在自动改 Prompt而在先建起评估集、Bad Case 集、版本管理、回归测试、灰度发布、回滚策略和人工 Review。一个可以本周就开跑的最小闭环这条演进路径正在变得越来越轻。过去要自己从零搭触发器、工作区隔离、子 Agent 编排和状态落盘如今主流工具已经把这些固化成开箱即用的标准组件——业界把这种模式称作 Harness-as-a-ServiceHaaS脚手架即服务。部分编码 Agent 已内置定时循环指令、技能规范文件和子 Agent 编排把Worktree Skills Connector Sub-agent State打包成了底座。这意味着团队可以把精力从造轮子挪到真正要紧的事情上定义目标、设计验证器、划定预算与停止条件。所以落地完全不必一上来就求无人值守。一个务实的起步节奏可以按下面的次序展开真正要紧的是先后顺序边界和验证在前自动化和无人值守在后。第 1 步写一份精简的项目规范文件每一行都对应一个你真实踩过的坑 第 2 步把一个反复输入的 Prompt 沉淀成一个可复用的 Skill 第 3 步加一个 Hook自动跑 Typecheck / Lint出错就把报错回灌给 Agent 第 4 步在 worktree 或 sandbox 里跑最朴素的循环先体会自动重试 第 5 步把执行者和验证者拆成两个独立的 Sub-agent 第 6 步补齐 Loop Contract——TRIGGER / SCOPE / ACTION / BUDGET / STOP / REPORT 第 7 步接入 Cron 或定时循环配好熔断器与看门狗再放进无人值守模式把后两步提到前面等于把一辆还没装刹车的车直接开上高速。先让系统学会安全地做完一件小事再逐步扩大它的领地。十、结语从执行者到循环设计者回到开篇那次角色反转现在可以把它说得更准了。Prompt Engineering 解决的是怎样让模型在这一轮给出更好的结果。Loop Engineering 解决的是怎样让一个 Agent 系统在很多轮、很多任务、很多天之后依然稳定地朝着正确目标运行。它不等于让 Agent 无限自主不等于彻底把人移出流程也不等于无脑堆更多 Prompt、更多 Agent、更多工具。它真正做的是把过去藏在人脑里的那套控制逻辑工程化地写进系统目标定义 任务调度 状态管理 环境隔离 工具权限 自动验证 失败恢复 人工审批 成本控制 运行观测 持续优化当这些能力被系统性地设计出来Agent 便从对话框里的智能工具成长为研发、运维、数据治理和业务流程中可控的执行单元。也因此未来优秀的 Agent 架构师比拼的早已超出会写 Prompt、会接 Tool、会搭 Workflow 的层面更要看他能不能设计出这样一套系统它知道自己该做什么 它知道如何证明自己做对了 它知道什么时候该停下来 它知道什么时候必须把问题交给人 它还能基于真实的运行结果让自己持续变得更可靠。附作者的一个开源实践本文谈的是方法论而方法论最终要落到代码里才算数。我把这套思路沉淀进了一个开源项目 echo-agent——一个可自托管、长期运行、持续学习的 AI Agent标语是记得住过去学得会未来。它面向个人与团队的私有自动化场景让对话与任务经验跨会话沉淀下来并对高风险操作建立可审计的边界。把它放回前文的框架里看几个核心模块正好把那几层闭环与工程原语落到了实处持续改进循环 → 自进化引擎从真实执行轨迹中生成候选改进先过离线评测对照晋升通过才生效并带冷却期与一键回滚。这正是第二节第四层运行 Trace → Bad Case → 评估 → 灰度 → 回滚的一个完整落地。State → 四层认知记忆Working / Episodic / Semantic / Archival 四层结构配合自动衰减、重要性重排与矛盾检测从根上解决长期运行下的记忆膨胀把第四节状态必须外置且像代码一样被治理的要求做成了产品能力。人工审批门 → 工具审批三档manual / smart / off 三档策略凭证加密存储、执行日志可审计无人值守通道默认拒绝高风险调用对应第六节那道判停权不交给 Agent 自己的审批门。Automations → 多入口归一CLI、Gateway、Webhook、Cron以及 Telegram、Discord、Slack、微信、飞书、钉钉等十多个通道共享同一份状态、走同一条执行路径对应第四节的触发层。此外它还内置了 BM25 FAISS 向量融合召回、A2A JSON-RPC 与 MCP 客户端含 OAuth 与动态工具注册主推理、上下文压缩、向量嵌入、风险审批可各自独立配置 provider 与模型纯 Python 实现、MIT 协议、开箱即用支持 OpenAI、Anthropic、Google、OpenRouter、AWS Bedrock 等主流模型。如果你想把本文的概念直接跑起来它会是一个趁手的起点。欢迎 Star、试用、共建https://github.com/fuyuxiang/echo-agent。