跳到主内容
我的博客
搜索
AI Agent
文章阅读

从 Agent Loop 看 AI Agent 到底是怎么工作的

2026/10/012 次阅读8 分钟

很多人第一次接触 AI Agent 时，容易觉得它很“神秘”。

它好像不仅能聊天，还能自己读取文件、执行命令、搜索信息、修改代码，甚至可以连续完成一整套任务。

但如果把 Agent 的实现拆开来看，会发现它最核心的机制其实并不复杂。

从程序结构上看，一个 Agent 最重要的部分，往往就是一个不断循环的过程：

Agent Loop。

这篇文章就从 Agent Loop 出发，看看 AI Agent 到底是怎么工作的。

什么是 Agent Loop

普通的大语言模型调用其实非常简单。

流程通常是：


用户输入
    ↓
LLM
    ↓
模型输出

用户问一个问题，模型回答一次，这次调用就结束了。

但 Agent 不一样。

Agent 不一定能够一次完成任务。

例如用户说：


帮我看看这个项目为什么运行失败，并把问题修复掉。

模型首先可能需要查看项目文件。

然后运行程序。

接着根据报错查看某个配置文件。

之后修改代码。

最后再次运行程序验证结果。

也就是说，一个复杂任务通常需要很多步骤。

于是 Agent 的执行过程就变成了：


用户任务
    ↓
LLM 思考
    ↓
调用工具
    ↓
获得工具结果
    ↓
再次调用 LLM
    ↓
继续调用工具
    ↓
再次获得结果
    ↓
......
    ↓
任务完成

这个不断重复的过程，就是 Agent Loop。

Agent Loop 的核心结构

如果把一个 Agent 极度简化，它其实可以写成类似下面这样的逻辑：


while 任务没有完成:

    调用 LLM

    if LLM 决定调用工具:
        执行 Tool
        将 Tool Result 加入 Context

    else:
        返回最终答案
        break

看起来非常简单。

但很多 Agent 框架最核心的运行逻辑，本质上就是在这个循环之上不断增加能力。

例如增加：

  • 上下文管理
  • Tool Calling
  • Memory
  • 权限控制
  • 错误重试
  • 多模型切换
  • Token 管理
  • 任务状态管理

这些功能最终还是围绕 Agent Loop 工作。

一轮 Agent Loop 到底发生了什么

假设我们给 Agent 一个任务：


请分析项目为什么启动失败。

第一轮循环开始。

模型首先读取当前 Context。

Context 里面可能包含：


System Prompt
User Message
可用 Tools
历史消息

模型看到任务之后，可能判断：


我需要先查看项目目录。

于是模型不会直接输出答案，而是返回一个 Tool Call：


list_files()

Agent Runtime 接收到 Tool Call 后，真正执行这个工具。

假设得到：


package.json
src/
README.md
config/

Runtime 会把这个执行结果重新加入 Context：


Tool Result:
package.json
src/
README.md
config/

然后进入下一轮 Agent Loop。

第二轮：模型根据新信息继续决策

现在模型看到的信息已经更多了。

它可能判断：


这是一个 Node.js 项目，我需要查看 package.json。

于是调用：


read_file("package.json")

工具返回：


{
  "scripts": {
    "start": "node src/index.js"
  }
}

这些信息再次进入 Context。

然后 Agent 继续下一轮。

模型可能继续判断：


我需要运行 npm start 查看具体错误。

于是调用：


shell("npm start")

执行结果可能是：


Error: Cannot find module 'express'

模型终于知道问题是什么了。

接下来它可能执行：


shell("npm install")

然后再次运行：


shell("npm start")

最终程序正常启动。

这时模型才返回：


问题已经修复，原因是项目依赖没有安装。

Agent Loop 结束。

Agent 为什么能够“自主行动”

这里有一个很重要的问题。

为什么我们感觉 Agent 好像会自己做事情？

其实 Agent 本身并没有真正意义上的“自主意识”。

它之所以表现得像在自主执行任务，是因为：

每一轮循环中，模型都会根据当前 Context 决定下一步操作。

第一次：


需要看文件。

第二次：


需要运行程序。

第三次：


需要查看错误。

第四次：


需要修改代码。

第五次：


需要重新验证。

这些决策并不是开发者提前写死的。

开发者只是提供工具。

真正决定：


什么时候调用什么工具

的是 LLM。

这也是 Agent 和传统 Workflow 最大的区别之一。

Tools 为什么这么重要

大语言模型本身其实只能做一件事情：

生成 Token。

也就是说，如果没有工具，大模型只能“说”。

它不能真正读取你的硬盘。

不能运行 Shell。

不能访问数据库。

也不能修改代码。

Tools 的作用，就是把模型输出的“意图”转化为真正的操作。

例如：


LLM:
我要查看 config.yaml

如果没有 Tool，它只能告诉你：


请打开 config.yaml。

但是如果 Agent 有：


read_file

这个工具，就可以直接执行：


read_file("config.yaml")

于是 Agent 从：


会说

变成了：


会做

这也是 Tool Calling 成为现代 Agent 架构核心能力的重要原因。

Context 是 Agent 的“工作记忆”

Agent Loop 还有一个非常关键的东西：

Context。

每一次模型调用并不是完全独立的。

前面发生过什么，需要重新告诉模型。

例如：


User:
修复这个项目

Assistant:
我要查看文件

Tool:
返回项目目录

Assistant:
我要运行程序

Tool:
返回错误信息

这些内容都会被保存到 Context 中。

下一次调用 LLM 时，模型就可以看到整个过程。

所以从某种意义上来说：


Context = Agent 当前的工作记忆

Agent 为什么能够连续完成几十个步骤？

并不是因为模型真的一直在“运行”。

而是因为每一轮执行结束之后，状态都会被保存。

下一次调用时，再把之前的信息重新交给模型。

Agent 其实是一个状态机

如果从软件工程角度来看，Agent 其实很像一个动态状态机。

例如：


State 1
用户提出任务

State 2
读取文件

State 3
执行程序

State 4
发现错误

State 5
修改代码

State 6
重新运行

State 7
任务完成

不同的是，传统状态机的状态转换通常是程序员写死的：


if A:
    go B

if B:
    go C

而 Agent 的状态转换，很多时候是模型动态决定的。

可以理解为：


传统程序：

人设计路径
程序执行路径

而 Agent：


人提供目标
模型动态规划路径
工具执行路径

这也是为什么 Agent 在面对开放任务时，比传统固定 Workflow 更灵活。

Agent Loop 最难的地方是什么

虽然 Agent Loop 本身很简单，但真正做好一个 Agent 并不简单。

第一个问题是：

模型可能做错误决策。

例如应该先看日志，它却一直修改代码。

第二个问题是：

Agent 可能进入死循环。

例如：


运行程序
↓
失败
↓
修改
↓
运行程序
↓
失败
↓
继续修改

如果没有限制，Agent 可能一直执行下去。

所以实际系统通常会增加：


最大循环次数
最大 Token
最大 Tool Call 次数
执行超时

第三个问题是 Context 会越来越长。

随着 Agent Loop 不断执行：


Message
Tool Call
Tool Result
Message
Tool Call
Tool Result

会不断堆积。

Eventually Context 可能变得非常大。

这时就需要：


Context Compression
Summary
Memory
Message Truncation

来控制 Token 消耗。

一个 Agent 的本质

如果让我用一个公式总结 Agent，我更愿意写成：


Agent
=
LLM
+
Context
+
Tools
+
Loop

LLM 负责决策。

Context 保存当前状态。

Tools 提供行动能力。

Loop 让模型可以不断执行下一步。

这四个东西组合起来，就形成了一个最基础的 Agent。

很多复杂 Agent 框架，其实只是在这个结构上增加更多能力。

我的理解

理解 Agent Loop 之后，我觉得 Agent 就没有那么神秘了。

Agent 并不是一个一直运行着、不断思考的“大脑”。

它更像一个循环：


观察当前状态
↓
决定下一步操作
↓
执行操作
↓
获得新的信息
↓
再次观察

这个过程其实和人解决问题非常相似。

比如程序出错时，我们也会：


查看错误
↓
分析原因
↓
修改代码
↓
重新运行
↓
查看结果

Agent 只是把这个过程交给了 LLM。

因此，我认为理解 Agent 最重要的第一步，并不是先研究 Multi-Agent、Memory 或复杂 Workflow。

而是先理解一个最基本的问题：

模型是如何在一次又一次 Agent Loop 中，根据环境反馈决定下一步动作的。

只要把 Agent Loop 理解清楚，后面再看 Coding Agent、Browser Agent、Research Agent，甚至 Multi-Agent 系统，就会容易很多。

因为无论外面的系统看起来多复杂，最核心的逻辑往往还是那几个步骤：


Think
↓
Act
↓
Observe
↓
Think Again

而这，就是 AI Agent 能够一步一步完成复杂任务的基础。

返回顶部