AI开发进入新时代:Agent Loop Engineering - 讲座总结

大语言模型（Large Language Model，LLM）的发展正在改变软件开发的基本范式。早期的LLM应用通常比较简单：用户提出问题，应用程序将问题和提示词发送给模型，模型生成答案，系统再将结果返回给用户。在这种模式下，开发者关注的重点主要是提示词设计、模型选择和上下文组织。

但当人工智能开始承担真正复杂的任务时，仅仅让模型“一次性回答”已经远远不够。例如，一个编码Agent可能需要先理解需求，再检查项目文件，制定实现方案，修改代码，运行测试，分析错误，修复问题，最后才能交付结果。整个过程天然具有多步骤、反馈、试错和重复执行的特征。

这意味着，AI系统的工程重点正在发生变化：开发者不仅需要研究“应该给模型什么提示”，还需要研究“模型应该如何行动、如何观察结果、如何判断是否成功，以及失败之后如何重新尝试”。

这正是Agent Loop Engineering，即“智能体循环工程”所关注的核心问题。

需要特别说明的是，Agent Loop Engineering目前更适合作为一种工程实践和设计思想来理解，而不是一个已经高度标准化、具有唯一严格定义的技术标准。课程中将其放在Agent Harness这一更大范围内讨论，并与Prompt Engineering、Context Engineering以及Multi-Agent系统的Graph Engineering进行区分。

一、从Prompt Engineering到Agent Loop Engineering

大语言模型应用的发展可以看作一个逐步增加系统控制能力的过程。

最初是Prompt Engineering，也就是提示工程。开发者通过设计系统提示词、任务模板和输入结构，引导模型按照特定角色和目标生成结果。例如，一个数据分析应用可以在系统提示中规定模型承担数据科学家的角色，再将用户问题嵌入模板，从而让模型以特定专业背景回答问题。

随后出现了Context Engineering，即上下文工程。它关注的不再只是提示词本身，而是如何控制提供给模型的全部上下文。检索增强生成（RAG）、Memory、历史对话以及其他外部信息，都可以成为上下文的一部分。上下文工程的目标，是让模型在获得恰当信息的基础上完成更可靠的任务。

然而，Prompt Engineering和Context Engineering主要解决的是“模型在当前一次调用中应该看到什么信息、按照什么方式回答”的问题。当任务变成多步骤执行时，仅仅优化一次模型调用仍然不足。

Agent Loop Engineering解决的是另一个层面的问题：如何让Agent持续行动、观察反馈、评估结果，并根据结果决定下一步行动。

因此，可以将三者简单理解为不同层次的问题：提示工程重点解决如何表达任务，上下文工程重点解决模型应该获得哪些信息，而循环工程重点解决Agent如何围绕目标持续行动。

二、为什么Agent天然需要Loop

Agent存在的价值，恰恰来自它能够处理复杂任务。

如果一个问题只需要一次模型调用就能够解决，那么通常并不需要复杂的Agent架构。Agent真正发挥作用的场景，往往是那些需要多个步骤才能完成的任务。

以构建网站为例，一个完整过程可能包括需求理解、方案设计、文件读取、代码编写、运行程序、测试功能、分析错误、修复Bug以及最终部署。任何一个步骤都可能产生新的信息，并影响后续行动。

因此，Agent不能简单地按照一条固定路径从开始执行到结束，而需要形成一个反馈循环：

规划 → 行动 → 观察 → 评估 → 继续执行或重新规划。

这就是Agent Loop的基本思想。

循环的关键并不只是“重复执行”，而是每次循环都应该利用上一轮行动产生的新信息，使下一轮行动更加接近任务目标。换句话说，Agent Loop是一种以状态和反馈为基础的迭代式任务执行机制。

三、Agent Loop的基本结构

一个典型的Agent Loop可以抽象为几个核心组成部分。

首先是目标（Goal）。系统必须明确Agent最终希望达到什么结果。

其次是状态（State）。状态记录任务当前进展，包括已经完成的步骤、获得的信息、工具执行结果以及当前环境情况。

第三是策略（Policy）。策略负责根据当前状态决定下一步应该采取什么行动。实际系统中，这一部分通常由大语言模型承担，也可以结合规则、传统算法或其他控制逻辑。

第四是行动空间（Action Space）。Agent必须知道自己能够做什么，例如读取文件、调用搜索工具、查询数据库、执行程序或者修改代码。

第五是观察（Observation）。Agent执行行动以后，需要获取环境反馈。例如程序运行是否成功、API返回什么结果、测试是否通过等。

第六是评估（Evaluation）。系统需要判断当前结果是否已经满足目标。如果已经完成，就应该退出循环；如果没有完成，则进入下一轮行动或重新规划。

因此，Agent Loop并不是简单的“让模型多想几次”，而是一套完整的状态—行动—反馈控制机制。

四、经典Agent Loop模式之一：Plan-Execute-Observe-Reflect

一种典型架构是Plan-Execute-Observe-Reflect，即计划、执行、观察和反思。

Agent首先根据目标制定计划，然后按照计划执行具体操作。在执行过程中不断观察环境反馈，最后评估当前结果并进行反思。

如果结果符合预期，任务可以结束；如果没有达到目标，Agent则需要重新规划。

这种模式比较适合能够拆解成多个相对明确步骤的复杂任务。例如软件开发、数据分析和研究型任务，都可以采用类似机制。

它与传统固定工作流的区别在于，计划并非永远不可改变。环境反馈可以迫使Agent修改原有计划，这种动态调整能力正是自主Agent的重要特征。

五、ReAct：推理与行动交替进行

另一种经典模式是ReAct，即Reasoning and Acting，将推理与行动结合起来。

Agent首先根据当前问题形成判断，然后采取行动，再根据行动产生的观察结果决定下一步。

例如，编码Agent发现程序构建失败，它首先分析错误信息，然后读取相关日志，再根据日志决定检查文件路径、依赖关系或者具体代码。每次行动都会产生新的信息，并影响下一步决策。

ReAct的特点是循环粒度比较小。它不一定要求Agent在开始时制定一个非常完整的长期计划，而是通过“推理—行动—观察”的连续过程逐步解决问题。

这种机制特别适合环境信息不断变化、无法提前确定全部执行步骤的任务。

六、Self-Reflection：让Agent从失败中调整

自主Agent经常需要处理第一次尝试失败的情况，因此Self-Reflection，即自我反思，也是一种重要的循环模式。

在这种架构中，Agent完成一次尝试后，会对结果进行评估，并进一步分析失败原因或可以改进的地方，然后将这些信息用于下一轮尝试。

例如，Agent生成了一段程序，但测试没有通过。它可以分析测试结果，判断错误来源，再修改实现并重新测试。

需要注意的是，“反思”并不意味着Agent一定具有类似人类的主观意识。工程意义上的Self-Reflection通常是利用模型生成分析、评价或修正建议，再将这些结果反馈到后续执行过程中。

它本质上是一种反馈机制。

七、Tree of Thoughts：从单一路径走向搜索

对于复杂推理问题，单一路径的连续推理可能并不是最优方案。Tree of Thoughts等方法尝试让模型探索多种候选路径。

传统的思维链可以被理解为沿着一条推理路径逐步前进，而树状思维则允许系统产生多个候选方案，并通过评估选择更加可行的路径。

这实际上已经接近搜索问题。系统可以采用不同的搜索策略探索候选状态，并根据评估结果淘汰不可行路径。

在Agent系统中，这类机制能够用于复杂规划和决策，但它通常会增加模型调用次数和计算成本。因此，是否采用树状搜索，需要根据任务复杂度、质量要求和延迟预算进行权衡。

八、Retry与Recovery：Agent必须能够处理失败

真实的软件系统不可能永远成功，因此Agent Loop必须考虑错误处理。

Agent运行过程中可能遇到多种失败，例如网络不稳定、请求超时、速率限制、工具调用失败、输出格式错误、权限不足等。

最简单的机制是Retry，即重新尝试。但真正可靠的Agent不能对所有错误都简单重试。

例如，如果失败原因是网络暂时不可用，重试可能有效；如果原因是没有访问权限，重复请求通常没有意义。

因此，更成熟的Agent Loop应该首先识别和分类错误，再决定采取Retry、Recovery、重新规划或者直接退出等不同策略。

Recovery的关键，是保留足够的执行状态，使系统能够从失败位置恢复，而不必从头开始。

九、Agent Loop必须有明确的出口

循环工程中最容易被忽略、但又极其重要的问题，是“什么时候停止”。

如果Agent只知道不断尝试，却没有明确的终止条件，就可能出现无限循环，不仅无法完成任务，还会持续消耗模型调用和计算资源。

一个完整的Agent Loop至少应该设计明确的退出机制。

第一种是任务成功。当系统能够验证目标已经达到时，循环正常结束。

第二种是预算耗尽。例如达到预设Token预算、时间预算或最大迭代次数后停止。

第三种是主动放弃。当系统经过若干次尝试仍然无法取得有效进展时，应当结束任务，并向用户报告失败，而不是无限尝试。

因此，Agent的“停止条件”本身就是系统设计的重要组成部分。

十、Evaluation是Agent Loop的控制核心

Agent能否真正可靠运行，很大程度上取决于Evaluation，也就是评估机制。

系统必须知道一次行动到底有没有让任务向目标靠近。

例如，一个编码Agent不能仅仅因为“代码生成完成”就认为任务成功，而应该进一步运行测试、检查构建结果或验证关键功能。

因此，评估器需要尽可能建立可验证的成功标准。

好的Evaluation不仅可以判断最终任务是否成功，还可以判断每次迭代是否取得有效进展。如果连续多次循环都没有产生实质性改善，系统就应该考虑重新规划或者停止。

从这个角度来看，Evaluation实际上承担了Agent Loop中的“控制器”角色。

十一、Agent Loop与Multi-Agent系统的关系

单Agent Loop主要解决一个智能体如何完成复杂任务的问题，而Multi-Agent系统进一步考虑多个Agent如何协作。

多个Agent之间可以采用不同协作模式。

一种是点对点协作，即Agent之间直接交换信息。

另一种是Manager-Worker模式，由一个管理Agent负责拆解任务并将子任务分配给多个Worker Agent。

更复杂的系统则可以形成层级结构，不同Agent承担不同管理和执行职责。

当多个Agent之间形成复杂的依赖关系时，与其将系统简单理解为一个Loop，不如将其理解为一个Graph。此时，Graph Engineering就成为另一个重要的工程问题。

因此，Loop Engineering主要关注单个Agent的动态执行循环，而Multi-Agent Graph Engineering更加关注多个Agent之间的协作关系和整体控制结构。

十二、Human-in-the-Loop：高风险任务仍需要人类参与

自主并不意味着完全不需要人类。

对于低风险任务，Agent可以拥有较高程度的自主执行权限；但对于代码发布、金融交易、敏感数据操作等高风险任务，完全自动执行可能带来严重后果。

因此，可以在Agent Loop中设置Human-in-the-Loop机制。

系统可以在关键节点通知用户，由人类审核结果后再继续；在风险较高的情况下，也可以允许人类直接接管任务。

这种设计能够在自动化效率和风险控制之间建立平衡。

尤其是在Agent技术仍快速发展的阶段，人类监督是保证生产系统可靠性的重要手段。

十三、设计自己的Agent Loop需要考虑什么

当开发者不再只是使用现成Agent框架，而是自行设计Loop时，需要重点考虑几个工程问题。

第一是停止条件。必须明确什么时候成功、什么时候达到预算、什么时候应该放弃。

第二是错误恢复。需要记录错误类型、错误发生位置以及之前采取过的行动，避免Agent重复犯同样的错误。

第三是可观测性。每一次迭代都应该留下足够的日志和追踪信息，以便之后进行调试和复盘。

第四是权限控制。Agent能够调用哪些工具、访问哪些数据，都应该受到明确限制。

第五是成本控制。每一次模型调用都可能产生Token消耗、计算资源消耗和时间延迟，因此不能无限制地增加循环次数。

十四、Token经济学：Agent效率的新指标

传统程序的执行成本主要由CPU、内存、网络等资源决定，而LLM Agent增加了一个重要资源：Token。

一次Agent任务可能涉及多轮模型调用，每一轮都可能输入大量上下文并生成新的输出。如果循环设计不合理，Token消耗会快速增长。

因此，Agent Loop需要考虑Token经济学。

首先，应尽量让每次迭代解决明确的小范围问题，避免一次循环处理过多内容。

其次，应控制迭代次数。如果任务已经没有明显进展，应及时停止。

最后，需要真正测量关键指标，包括Token消耗、执行时间、循环次数和任务成功率，而不是单纯追求模型调用次数。

在生产环境中，Agent的质量必须与成本、延迟和稳定性一起衡量。

十五、从Coding Agent看Loop Engineering的实际应用

编码Agent是理解Loop Engineering的典型案例。

现代Coding Agent可以读取项目文件、修改代码、运行测试、分析错误并继续修复。它实际上已经形成了一个完整的Agent Loop。

例如，一个典型流程可以是：

理解开发任务，检查项目结构，制定方案，修改代码，运行测试，观察结果；如果测试失败，则分析错误、修改实现并再次运行，直到任务成功或达到预算。

不同Coding Agent在具体实现上存在差异。有的强调终端环境和自主执行，有的强调隔离运行环境，有的则更加强调保持开发者在循环中的参与。

但它们共享一个基本思想：Action → Observe → Decide → Repeat。

这正是Agent Loop Engineering在真实软件开发中的直接体现。

十六、未来的AI开发将更加重视“循环设计”

随着大语言模型能力不断提升，AI应用开发的重点正在从单纯的Prompt设计逐渐转向完整的Agent系统工程。

未来的AI工程师不仅需要理解LLM、Memory、Tools、MCP以及Function Calling等基础能力，还需要掌握如何设计Agent的执行循环。

真正成熟的Agent系统，不只是“模型很聪明”，还应该能够：

明确目标；

合理规划；

调用正确工具；

观察环境；

验证结果；

发现错误；

重新规划；

控制成本；

在必要时请求人工介入。

这些能力共同构成了Agent从“会回答”走向“能完成任务”的关键。

结语：Agent Loop是AI系统工程化的重要组成部分

Agent Loop Engineering并不是简单地让大语言模型重复生成答案，而是一种围绕自主智能体构建反馈控制机制的工程思想。

它将大语言模型的推理能力与工具、记忆、状态、评估和错误恢复机制结合起来，使Agent能够在复杂任务中不断行动、观察和调整。

从Prompt Engineering到Context Engineering，再到Agent Loop Engineering，可以看到AI应用正在从“一次模型调用”逐渐发展为“持续运行的智能系统”。而当多个Agent进一步形成复杂协作关系时，系统又会从Loop走向Graph，需要新的多智能体工程方法。

因此，未来AI开发者面对的核心问题将不再只是“怎样让模型生成更好的答案”，而是“怎样让智能体在真实环境中可靠地完成任务”。

一个真正成熟的Agent系统，需要的不仅是强大的模型，还需要合理的Loop、可靠的工具、完善的状态管理、可验证的Evaluation、严格的安全边界以及可控的成本。

从这个意义上说，Agent Loop Engineering代表了AI应用开发从“模型调用工程”向“智能行为工程”进一步演进的重要一步，也将成为构建下一代自主AI系统时不可忽视的核心工程能力。

使用链接查看课程回放视频：https://study.dataapplab.com/course?courseid=llm-webinars

或扫码查看往期大语言模型公开课回放视频及资料（免费开放）：

• 开课时间：2026年8月29日

• 上课时间：1-3PM(PT) Saturday， 6-8PM(PT)  Tuesday， 6-7PM(PT) Thursday

• 课程时长：16 周  ·  共 80 小时现场教学

• 注册网站：study.dataapplab.com

• 名额有限，现在就锁定你的席位！

• 立即报名：study.dataapplab.com

• 点击链接，可免费预约一对一导师咨询：

  https://docs.google.com/forms/d/e/1FAIpQLSfQE7AgVbZSCR9LDXfDGkVp-haS4yJgIHoqt9dhRzTGwT1rjw/viewform?usp=header

• 有疑问：扫描下方海报中的助教微信二维码，随时咨询。