构建 Agent 自主执行闭环：从上下文工程到循环工程

在 AI Coding 领域，上下文工程（Context Engineering）已经被广泛认为是提升模型输出质量的关键手段。通过精心设计 Prompt、提供充足的背景信息和领域知识，开发者可以让 AI 代理在单轮任务中表现出色。然而，当面对跨越数十分钟、经历多轮返修的复杂长链路任务时，上下文工程的局限性开始显现——它只能提高单轮执行正确的概率，却无法保证复杂任务在多次执行中始终沿着正确方向推进。

概述

本文深入分析长链路任务执行的核心挑战，并提出从"上下文工程"向"循环工程"演进的技术路径。在真实的业务开发场景中，需求可能存在歧义、代码入口可能找错、接口状态可能复现不了、UI 可能没有精准还原设计稿、测试可能被判断通过但用户路径不成立——只要任务足够复杂，执行中出现错误就是常态。自动执行系统需要建立对执行偏差的处理能力：即使单轮执行产生偏差，系统仍然能够识别目标、偏差、后续责任角色，以及必须转入人工处理的时机。

构建可收敛的循环执行系统

循环工程的核心目标，是将过去由人隐式承担的目标维护、任务调度、过程记忆、结果验证和失败止损，逐一转化为系统能力。这需要从以下几个维度构建支撑体系： 首先是目标持久化。在长链路执行中，初始目标会被中间过程逐渐稀释，Agent 可能只围绕最近一条反馈意见工作，忽略任务的整体交付要求，也可能将局部完成误判为任务完成。因此，需要将规划结果从一份"给人或 Agent 阅读的报告"，变成平台里的结构化对象。结构化 Task 需要以明确定义：最终要达成什么结果、哪些状态和用户路径属于本次范围、哪些内容明确不做、依赖哪些上游条件、什么证据可以证明任务完成，以及当前执行到了哪个阶段。 其次是定义最小执行单元。一个可以进入自动循环的 Job，必须明确四件事：这一轮要解决什么问题、可以用哪些结构化结果结束、结束时必须留下什么证据、不同结果分别流向哪里。不同结果对应不同的下一步，系统使用结构化结果推进状态，避免从大段模型回复中推测完成意图。

执行状态外部化与多 Agent 协作

循环要运行得足够久，就不能依赖某一个 Agent 记住所有事情。系统需要将任务、Job、结构化结果、评论、交接、截图、测试结果、Diff 报告和阻塞项写入执行账本。执行账本需要同时容纳事实证据与阶段判断：文件改动、运行命令、验证 URL、Mock 场景、截图、Diff 报告和测试结果属于可复查事实；方案理由、剩余风险、后续关注点和责任角色则用于支撑下一轮决策。下一轮 Agent 不需要重读整段历史，只需要读取当前任务、当前 Job、最近一次交接和必要证据。 多 Agent 协作的核心原则是：协作可以自由，状态必须受控。角色划分只有在不同角色对应稳定的工程责任，并且它们对"完成"的判断标准不同时才有价值。例如：前端 Agent 负责组件结构、业务状态、数据流和交互入口；视觉 Agent 负责截图、Diff 和可见结果修正；Review Agent 默认寻找反例和风险；验收 Agent 按用户目标和用户路径判断是否可交付；负责人 Agent 处理分派、冲突和无法自动解决的异常。

视觉修正小循环与端到端闭环

在整体执行闭环中，前端 UI 任务会经过实现与视觉验证两个责任阶段。只要改动影响用户可见结果，任务就会进入视觉验证阶段。以设计稿与实现截图的对比为例，系统会经历：通过 Mock 固定目标业务状态、使用视觉 Diff 工具对比设计稿与实现截图、根据差异进行设计侧与实现侧取证、视觉 Agent 按根因修复、使用相同状态和范围重新对比、视觉通过或退回前端 Agent / 负责人处理。这个过程构成了大循环内部的一个小循环，有效比较依赖稳定的业务需求背景输入，同一个页面可能包含多种状态，视觉 Agent 会通过 Mock 固定场景，再将实现结果与对应设计状态比较。 视觉 Agent 在确定修复方式时还需要进行双边取证：设计侧从 API 获取节点尺寸、相对位置和样式，实现侧通过浏览器读取实际 DOM 的位置与计算样式。两侧数据共同构成修改依据，避免根据截图目测参数。代码修改完成后，视觉 Agent 会在相同 Mock、视口和对比范围下重新执行 Diff。通过的视觉证据进入 Review；状态、结构或接口缺失会使任务退回前端 Agent；多轮修复仍无法收敛时，则转入负责人或人工仲裁。

如有侵权，请联系删除。