Agent Loop 智能体循环
Agent 的核心运行方式：判断 → 行动 → 反馈 → 再判断的持续闭环
简介
Agent Loop（智能体循环）是 Agent 运行的最核心机制。它不是一种特定的算法或框架，而是一种运行模式：Agent 不断将当前已知的一切交给 LLM 判断下一步动作，由外部 Runtime 执行工具后，将结果重新填入 Context，再次调用 LLM 继续判断，往复循环直到任务完成或中止。
从底层视角看，一个看似”神奇”的复杂任务，实质上是很多轮 LLM 调用串联而成的闭环。
核心运行方式
最小 Loop 模型
LLM 判断下一步 → 请求 Tool → Tool 执行 → 结果回填 Context → 再次调用 LLM → 继续判断
每一轮的实际内容
以 Claude Code 修复登录 Bug 为例：
- 第 1 轮：LLM 看到用户目标 + 系统规则 + 项目环境说明 + 可用工具列表 → 判断”先看目录结构”→ 请求 Tool
- 第 2 轮：Context 中新增 Tool 返回的目录内容 → LLM 判断”应读取登录相关文件”→ 请求 Tool
- 第 3 轮：Context 中新增文件内容 → LLM 判断”找到 Bug，修改对应代码”→ 请求 Tool
- 第 4-N 轮：继续执行 → 运行测试 → 看报错 → 再修改 → 再测试 → 直到通过
因此 Agent 并不是”一次性完成所有事”，而是 “观察 → 决策 → 行动 → 新观察 → 新决策” 不断积累的闭环。
关键特征
高频多轮调用
同一个任务在 Agent 模式下可能经历数十次模型调用（response），而不是像普通聊天那样一问一答。这是 Agent 消耗 Token 远高于普通对话的根本原因。
Context 持续演化
每一轮 Loop 的 Context 都会增长（加入 Tool 返回结果、前序判断、任务进度），因此真实系统通常需要：
- 删除不重要的历史
- 对早期内容做摘要
- 只保留关键状态
- 大文件放在外部，需要时重新读取
- 长期信息写入 Memory，执行进度压缩成 State
循环终止条件
Loop 不是无限运行，必须有明确的终止条件：
- 任务完成（达到目标/验收通过）
- 任务失败（错误无法恢复）
- 用户主动中止
- Token 预算耗尽（熔断机制）
- 轮次上限到达
不同素材中的观点
来自 2026-08-11-agent-worldview-llm-context-tool-agent：
- Agent Loop 是 Agent 真正的灵魂，本质上是自动化的高频多轮调用闭环
- 每一轮都构造一个足以支持当前判断的新 Context，不是每次把所有历史完整重发
- 同一个问题在网页（一问一答）和 Agent（数十轮 Loop）中的 Token 消耗完全不同
- Agent Loop 让 LLM 拥有了类似人类的反馈闭环：行动 → 观察结果 → 再判断，这正是人类程序员解决 Bug 的真实过程
相关概念区分
| 概念 | 负责什么 | 在 Agent Loop 中的角色 |
|---|---|---|
| LLM | 推理、判断、决策 | 每轮 Loop 的”大脑”，输出下一步判断 |
| Tool | 执行具体操作 | 每轮 Loop 的”手脚”，为 LLM 提供行动出口 |
| Context | 当前有效信息集合 | 每轮 Loop 的”工作记忆”，承载本轮判断所需信息 |
| State | 任务进度跟踪 | 跨轮 Loop 的”进度条”，记录做到哪了 |
| Memory | 长期信息存储 | 跨任务/跨会话的”知识库”，需读取后放入 Context |
| Runtime | 调度与执行 | Loop 的中枢——执行 Tool、回填结果、管理循环 |
实用信息
Handler Loop 中的常见瓶颈
- Context 膨胀：Loop 越长，Context 越大，可能溢出 Context Window 或导致推理质量下降
- Token 成本：高频多轮调用意味着 Token 消耗线性增长，需要在架构层面做成本控制
- 无限循环：没有明确完成条件或错误恢复时，Agent 可能陷入循环或偏航
- 工具调用失败：Tool 超时/报错/返回异常结果时的重试与降级策略
设计 Loop 的关键问题
- 什么条件触发下一次调用？
- Context 太长之后如何裁剪/压缩/摘要？
- 任务什么时候算完成？谁负责验收？
- 如果工具失败，是重试、换方案还是终止？
- 是否需要人工确认卡点？