深入理解 Agent LoopAI 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 都开始讲 Agent1.1 从 2025 年的爆发说起如果你在 2024 年还停留在「用 ChatGPT 问答」的阶段那么到 20252026 年整个 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 年初的 ChatGPTGPT-3.5 时代它不能主动读取你电脑上的文件它不能执行命令行它不能联网搜索后来有了 Browse但也是受限的它不会自己「想一步、做一步、再想一步」那时的 ChatGPT 本质上是一个单轮对话补全器Completer你输入 Prompt它输出文本结束。如果你说「帮我修这个 Bug」它只能基于你贴在对话里的代码「猜测性」地给建议它无法主动去验证自己的修改对不对。为什么以前没有Agent Loop模型能力不足Tool调用不稳定推理深度不够上下文窗口小4K-8K token循环几轮就爆缺少工程框架没有统一Tool协议无Memory机制实践验证不足Prompt Engineering主导尚未形成Agent范式所以Agent Loop 不是某个人「发明」的而是当模型能力 上下文窗口 工程框架三者同时就位时自然演化出来的产物。1.3 提出核心问题读到这里你可能会问Agent Loop 到底是什么它和普通的 ChatGPT 对话有什么本质区别为什么同样的模型加一个「循环」就能让 AI 从「回答问题」变成「完成任务」这正是本文要彻底讲清楚的问题。接下来我们从最基础的传统 LLM 工作方式讲起一步步带你理解 Agent Loop 的全貌。第二章传统 LLM 是如何工作的2.1 最朴素的三个概念Prompt、Context、Completion在理解 Agent Loop 之前我们必须先回到原点搞清楚传统 LLM 到底是怎么工作的。所有大语言模型无论 GPT、Claude、Gemini其最底层的工作模式都可以用三个概念概括用户Prompt大语言模型LLM模型输出CompletionPrompt提示词你输入给模型的文本。比如「帮我写一个 Vue 登录页面」。Context上下文模型在生成回复时参考的全部信息。包括系统提示词、历史对话、当前 Prompt 等。这些信息会被拼接成一个 token 序列喂给模型。Completion补全模型输出的文本。本质上是模型基于 Context 预测「下一个最可能出现的 token」。这里有一个很多人没意识到的本质LLM 从来不是在「思考」它是在「预测」。它根据上下文一个 token 一个 token 地生成最符合统计规律的文本。当你问它「11等于几」它回答「2」不是因为它会算术而是因为在它的训练数据里「11」后面跟着「2」的概率最高。2.2 One-shot Inference一次推理就结束传统 LLM 的工作模式学术界称为One-shot Inference单次推理。它的特点是输入一次 Prompt模型输出一次 Completion整个交互就结束了。我们用一段 TypeScript 代码来模拟这个最基础的过程// 传统 LLM 的单次推理模式One-shot InferenceinterfaceLLMResponse{content:string;tokensUsed:number;}// 模拟一次 LLM 调用asyncfunctioncallLLM(prompt:string):PromiseLLMResponse{// 实际工程中这里会调用 OpenAI / Anthropic 的 APIconsole.log( 发送 Prompt: ${prompt});// 模拟模型返回constcompletion:LLMResponse{content:这是一个 Vue 登录页面的代码\nvue\ntemplate.../template\n,tokensUsed:prompt.length150};returncompletion;}// 传统模式一次 Prompt → 一次 Completion结束asyncfunctiontraditionalChat(){constuserPrompt帮我写一个 Vue 登录页面;constresponseawaitcallLLM(userPrompt);console.log( 收到回复:${response.content.slice(0,50)}...);console.log( Token 消耗:${response.tokensUsed});// ⚠️ 注意到这里交互就结束了// 模型不会知道这段代码能不能跑通、有没有 Bug}traditionalChat();运行这段代码你会看到 发送 Prompt: 帮我写一个 Vue 登录页面 收到回复: 这是一个 Vue 登录页面的代码vuetemplate... Token 消耗: 164交互到此结束。这就是传统 LLM 的全部工作模式。2.3 这种模式为什么「够用」又「不够用」对于简单任务One-shot Inference 是够用的任务类型例子One-shot 是否够用文本生成「写一首关于秋天的诗」✅ 够用知识问答「Vue 3 的响应式原理是什么」✅ 够用代码片段「写一个防抖函数」✅ 够用翻译润色「把这段英文翻译成中文」✅ 够用复杂工程「修复这个项目的 Bug」❌完全不够多步任务「部署这个应用到生产环境」❌完全不够问题的关键在于很多真实世界的任务根本不是「一句话能完成的」。它们需要多步骤、需要反馈、需要根据中间结果调整策略。这正是下一章要剖析的问题。第三章传统 LLM 为什么无法完成复杂任务3.1 一个真实的「修 Bug」场景让我们看一个对开发者来说再熟悉不过的场景修复项目中的 Bug。假设你接到一个任务「前端项目登录后偶尔会白屏帮忙修复一下」。如果交给传统的 ChatGPT会发生什么你可能会把报错信息贴给它它给你一段「可能是这样、可能是那样」的建议。然后呢然后没有了。你还得自己手动去验证、去试错。如果它的建议不对你得再贴新的信息再来一轮——而且它不记得之前做了什么除非你在对话里手动带上历史。真正修一个 Bug完整的工作流是这样的是否步骤1查看项目结构了解这是什么项目步骤2分析相关代码定位可能的 Bug 位置步骤3运行 Build / 测试复现问题步骤4读取报错信息理解根本原因步骤5修改代码步骤6再次 Build / 测试是否还有错误步骤7修复完成请仔细看这张图它揭示了一个关键事实这是一个「循环」结构。第 4 步读错误→ 第 5 步改→ 第 6 步测试→ 如果还有错误 →回到第 4 步。3.2 传统 LLM 的三大致命缺陷对比上面的完整工作流传统 One-shot Inference 模式有三个无法逾越的致命缺陷缺陷一无法主动获取信息缺少 Act 能力传统 LLM 只能被动接收你给它的信息。但修 Bug 需要主动去读文件、跑命令、看日志。它没有「手」无法操作。// ❌ 传统 LLM 无法做到这样functiontraditionalLLM(){// LLM 只能基于用户贴过来的文本猜// 它不能主动执行// - fs.readFile() 读源码// - exec(npm run build) 跑构建// - 看构建输出来判断对不对// 它只能输出建议然后等待用户手动验证后反馈}缺陷二无法根据反馈调整缺少 Observe 能力假设你手动帮它跑了 Build把错误信息贴回来了。它给你新的建议。但问题是它不知道这已经是第几次修改了。它把每一条消息都当成独立事件缺乏「我上次改了 A报错了说明 A 不对我这次试试 B」的基于观察的迭代能力。缺陷三无法持续执行缺少 Loop 能力这是最根本的。传统 LLM 的交互是请求-响应模式你发一次它回一次。它不会自己决定「我还要再做一步」。修一个 Bug 可能需要 5 次迭代传统 LLM 无法自己维持这个迭代过程必须靠人类一户户驱动。3.3 用一张图总结传统 LLM 的「无力感」能力缺口传统 LLM无循环❌ 无法继续等待人类驱动接收Prompt输出建议结束真实任务修复 Bug需要循环否是读代码改代码测试通过?完成这张图说明了一切真实任务是循环的而传统 LLM 是线性的。两者之间存在巨大的「能力缺口」。这个缺口正是Agent Loop要填平的东西。小结传统 LLM 的本质是「单次补全器」它缺少三个关键能力主动行动Act、观察反馈Observe、持续循环Loop。Agent Loop 就是为了补齐这三个能力而生的。在下一章我们将正式揭开 Agent Loop 的面纱。本文为系列第一篇。下篇将深入 Agent Loop 执行流程与内部实现。