深入理解 Agent Loop：AI Agent 的核心运行机制与工程实现

本文从底层原理到工程实现，全面拆解 Agent Loop（智能体循环）这一 AI Agent 的核心能力。内容涵盖传统 LLM 的局限、Agent Loop 的完整执行流程、Tool Calling、Memory 机制、与 Workflow/ReAct 的关系、主流框架对比，并提供基于 TypeScript 的 Mini Agent Loop 完整实现。读完本文，你将真正理解 OpenCode、Claude Code、Cursor 这些 AI Coding Agent 背后的运转逻辑。

---

第一章：为什么 AI 都开始讲 Agent？

1.1 从 2025 年的爆发说起

如果你在 2024 年还停留在「用 ChatGPT 问答」的阶段，那么到 2025～2026 年，整个 AI 开发者圈子的叙事已经彻底变了——所有人都在讲 Agent。

一个标志性事件是：Anthropic 推出的 Claude Code 让开发者第一次体验到「AI 自己读项目、改代码、跑测试、修 Bug」的全流程自动化；紧接着 OpenAI Codex CLI、开源的 OpenCode、Cursor Agent 模式 纷纷跟进。这些工具的共同特点是：它们不再是「你问我答」，而是「你给目标，它自己干」。

为什么会发生这样的转变？核心原因是三点：

第一，模型能力跨越了临界点。 GPT-4o、Claude 3.5/4、Gemini 2 这一代模型不仅推理能力强，更重要的是 tool use（工具调用）的稳定性大幅提升。以前让模型可靠地调用一个函数并解析返回结果，成功率可能只有 60%；现在可以稳定在 95% 以上。这是 Agent 能真正「干活」的技术基础。

第二，上下文窗口足够大了。 从早期的 4K、8K，到现在的 128K、200K 甚至 1M token。Agent 需要在循环中不断把「工具执行结果」塞回上下文，窗口太小根本循环不了几轮。大窗口让 Agent 能「记住」自己在循环中做过什么。

第三，工程框架成熟了。 LangGraph、OpenAI Agents SDK、各家自研的 Agent Runtime，让开发者不用从零造轮子就能跑起一个 Agent。

1.2 为什么以前 ChatGPT 没有 Agent Loop？

回忆一下 2023 年初的 ChatGPT（GPT-3.5 时代）：

• 它不能主动读取你电脑上的文件
• 它不能执行命令行
• 它不能联网搜索（后来有了 Browse，但也是受限的）
• 它不会自己「想一步、做一步、再想一步」

那时的 ChatGPT 本质上是一个 单轮对话补全器（Completer）：你输入 Prompt，它输出文本，结束。如果你说「帮我修这个 Bug」，它只能基于你贴在对话里的代码「猜测性」地给建议，它无法主动去验证自己的修改对不对。

所以，Agent Loop 不是某个人「发明」的，而是 当模型能力 + 上下文窗口 + 工程框架三者同时就位时，自然演化出来的产物。

1.3 提出核心问题

读到这里，你可能会问：

Agent Loop 到底是什么？它和普通的 ChatGPT 对话有什么本质区别？为什么同样的模型，加一个「循环」就能让 AI 从「回答问题」变成「完成任务」？

这正是本文要彻底讲清楚的问题。接下来我们从最基础的传统 LLM 工作方式讲起，一步步带你理解 Agent Loop 的全貌。

---

第二章：传统 LLM 是如何工作的？

2.1 最朴素的三个概念：Prompt、Context、Completion

在理解 Agent Loop 之前，我们必须先回到原点，搞清楚 传统 LLM 到底是怎么工作的。所有大语言模型（无论 GPT、Claude、Gemini），其最底层的工作模式都可以用三个概念概括：

• Prompt（提示词）：你输入给模型的文本。比如「帮我写一个 Vue 登录页面」。
• Context（上下文）：模型在生成回复时参考的全部信息。包括系统提示词、历史对话、当前 Prompt 等。这些信息会被拼接成一个 token 序列喂给模型。
• Completion（补全）：模型输出的文本。本质上是模型基于 Context 预测「下一个最可能出现的 token」。

这里有一个很多人没意识到的本质：LLM 从来不是在「思考」，它是在「预测」。它根据上下文，一个 token 一个 token 地生成最符合统计规律的文本。当你问它「1+1等于几」，它回答「2」，不是因为它会算术，而是因为在它的训练数据里，「1+1=」后面跟着「2」的概率最高。

2.2 One-shot Inference：一次推理就结束

传统 LLM 的工作模式，学术界称为 One-shot Inference（单次推理）。它的特点是：输入一次 Prompt，模型输出一次 Completion，整个交互就结束了。

我们用一段 TypeScript 代码来模拟这个最基础的过程：

// 传统 LLM 的单次推理模式（One-shot Inference）

interface LLMResponse {
  content: string;
  tokensUsed: number;
}

// 模拟一次 LLM 调用
async function callLLM(prompt: string): Promise<LLMResponse> {
  // 实际工程中，这里会调用 OpenAI / Anthropic 的 API
  console.log(`📤 发送 Prompt: "${prompt}"`);

  // 模拟模型返回
  const completion: LLMResponse = {
    content: '这是一个 Vue 登录页面的代码：\n```vue\n<template>...</template>\n```',
    tokensUsed: prompt.length + 150
  };

  return completion;
}

// 传统模式：一次 Prompt → 一次 Completion，结束
async function traditionalChat() {
  const userPrompt = '帮我写一个 Vue 登录页面';

  const response = await callLLM(userPrompt);

  console.log(`📥 收到回复: ${response.content.slice(0, 50)}...`);
  console.log(`💰 Token 消耗: ${response.tokensUsed}`);

  // ⚠️ 注意：到这里交互就结束了
  // 模型不会知道这段代码能不能跑通、有没有 Bug
}

traditionalChat();

运行这段代码，你会看到：

📤 发送 Prompt: "帮我写一个 Vue 登录页面"
📥 收到回复: 这是一个 Vue 登录页面的代码：```vue<template>...
💰 Token 消耗: 164

交互到此结束。 这就是传统 LLM 的全部工作模式。

2.3 这种模式为什么「够用」又「不够用」？

对于简单任务，One-shot Inference 是够用的：

任务类型	例子	One-shot 是否够用
文本生成	「写一首关于秋天的诗」	✅ 够用
知识问答	「Vue 3 的响应式原理是什么？」	✅ 够用
代码片段	「写一个防抖函数」	✅ 够用
翻译润色	「把这段英文翻译成中文」	✅ 够用
复杂工程	「修复这个项目的 Bug」	❌ 完全不够
多步任务	「部署这个应用到生产环境」	❌ 完全不够

问题的关键在于：很多真实世界的任务，根本不是「一句话能完成的」。它们需要多步骤、需要反馈、需要根据中间结果调整策略。这正是下一章要剖析的问题。

---

第三章：传统 LLM 为什么无法完成复杂任务？

3.1 一个真实的「修 Bug」场景

让我们看一个对开发者来说再熟悉不过的场景：修复项目中的 Bug。

假设你接到一个任务：「前端项目登录后偶尔会白屏，帮忙修复一下」。如果交给传统的 ChatGPT，会发生什么？

你可能会把报错信息贴给它，它给你一段「可能是这样、可能是那样」的建议。然后呢？然后没有了。你还得自己手动去验证、去试错。如果它的建议不对，你得再贴新的信息，再来一轮——而且它不记得之前做了什么（除非你在对话里手动带上历史）。

真正修一个 Bug，完整的工作流是这样的：

请仔细看这张图，它揭示了一个关键事实：这是一个「循环」结构。第 4 步（读错误）→ 第 5 步（改）→ 第 6 步（测试）→ 如果还有错误 → 回到第 4 步。

3.2 传统 LLM 的三大致命缺陷

对比上面的完整工作流，传统 One-shot Inference 模式有 三个无法逾越的致命缺陷：

缺陷一：无法主动获取信息（缺少 Act 能力）

传统 LLM 只能被动接收你给它的信息。但修 Bug 需要主动去 读文件、跑命令、看日志。它没有「手」，无法操作。

// ❌ 传统 LLM 无法做到这样
function traditionalLLM() {
  // LLM 只能基于用户贴过来的文本"猜"
  // 它不能主动执行：
  // - fs.readFile() 读源码
  // - exec('npm run build') 跑构建
  // - 看构建输出来判断对不对

  // 它只能输出"建议"，然后等待用户手动验证后反馈
}

缺陷二：无法根据反馈调整（缺少 Observe 能力）

假设你手动帮它跑了 Build，把错误信息贴回来了。它给你新的建议。但问题是：它不知道这已经是第几次修改了。它把每一条消息都当成独立事件，缺乏「我上次改了 A，报错了，说明 A 不对，我这次试试 B」的基于观察的迭代能力。

缺陷三：无法持续执行（缺少 Loop 能力）

这是最根本的。传统 LLM 的交互是 请求-响应 模式：你发一次，它回一次。它不会自己决定「我还要再做一步」。修一个 Bug 可能需要 5 次迭代，传统 LLM 无法自己维持这个迭代过程，必须靠人类一户户驱动。

3.3 用一张图总结传统 LLM 的「无力感」

这张图说明了一切：真实任务是循环的，而传统 LLM 是线性的。两者之间存在巨大的「能力缺口」。这个缺口，正是 Agent Loop 要填平的东西。

💡 小结：传统 LLM 的本质是「单次补全器」，它缺少三个关键能力：主动行动（Act）、观察反馈（Observe）、持续循环（Loop）。Agent Loop 就是为了补齐这三个能力而生的。在下一章，我们将正式揭开 Agent Loop 的面纱。

---

---

本文为系列第一篇。下篇将深入 Agent Loop 执行流程与内部实现。