Agent实现原理与实践（一）：Agent Loop

Sat, 25 Apr 2026 16:00:00 +0800

1. 前言

随着2022年底以ChatGPT为代表的LLM（大语言模型）爆发式发展，AI Agent（智能体）迅速从概念走向工程实践。从早期简单的单轮对话工具，到如今能够自主规划、调用工具、持续迭代的编程Agent（如Cursor、Claude Code、Codex CLI），Agent已经成为大模型应用落地的核心形态。正如OpenAI在其官方博客中所说，Agent Loop是连接用户、模型和工具的枢纽。

作为Agent系统的核心机制，Agent Loop（智能体循环）决定了Agent如何思考、如何行动、如何与外部环境交互。这个循环的本质是：Agent接收用户输入，查询模型进行推理，模型要么产生最终回复，要么请求工具调用；Agent执行工具后将结果回灌到prompt中，再次查询模型——如此反复，直到模型停止发出工具调用、产出面向用户的assistant message为止。这个assistant message不仅是对用户的回应，更标志着Agent Loop的一个终止状态：从Agent的视角看，它的工作已经完成，控制权交还用户。

它看似简单——不过是一个"调模型、执行工具、再调模型"的循环——但要在真实产品中稳定、高效、可扩展地运行，却涉及大量精妙的工程设计和架构取舍。比如，随着对话增长，prompt长度会不断增加，而每个模型都有上下文窗口（context window）限制，因此上下文窗口管理是Agent的核心职责之一。此外，Agent执行的工具调用会修改本地环境（如读写文件），所以Agent的"输出"远不止assistant message，还包括它实际产生的代码变更等副作用。

本文是Agent实现原理系列的第一篇，将从工程实现的角度，深入剖析Agent Loop的核心原理。我们将参考Codex CLI、Claude Code、nanobot、pi等主流开源项目的实现，抽象出Agent Loop的通用模型，分析其关键设计点和工程权衡。

2. Agent Loop的本质

2.1 从"会调LLM的程序"到"Agent Runtime"

一个最朴素的Agent实现，可以写成下面这样：

while true:
    response = call_llm(messages, tools)
    if response has tool_calls:
        results = execute_tools(response.tool_calls)
        messages += [response, results]
    else:
        return response.content

这段代码确实构成了Agent Loop的核心骨架，但它距离一个"能在真实产品中运行的Agent Runtime"还有很大差距。真实场景需要回答的问题包括：

工具执行出错或产生副作用时，如何优雅处理？
用户中途插入新指令，如何不破坏当前执行上下文？
上下文窗口超限，如何压缩而不丢失关键信息？
多轮迭代后历史越来越长，如何保持"上下文卫生"？
流式输出如何与工具调用无缝衔接？
子Agent如何复用主循环的能力？

这些问题促使Agent Loop从一个简单的while循环，演进为一组边界清晰的组件协作系统。

2.2 Agent Loop的通用抽象

无论具体实现如何差异，所有成熟的Agent Loop都共享同一套核心抽象：

Agents on Sky's Blog

Agent实现原理与实践（一）：Agent Loop

1. 前言

2. Agent Loop的本质

2.1 从"会调LLM的程序"到"Agent Runtime"

2.2 Agent Loop的通用抽象