很多人对 Agent 的理解停在「能调工具的 LLM」。给它接几个工具，让它能查数据库、能发请求、能读文件，就觉得是个 Agent 了。
这个理解太浅。能调工具只是 Agent 的一个能力，不是 Agent 的本质。一个真正的 Agent，核心是一个控制循环，规划要做什么，执行具体的动作，观察执行的结果，反思下一步该做什么，然后循环往复，直到完成任务。这个「规划、执行、反思」的闭环，才是 Agent 区别于单次 LLM 调用的关键。这篇把这个循环拆开讲。
单次调用为什么不够
图：单次 LLM 调用是一条直线，Agent 是一个能自我纠偏的闭环。
先理解为什么不能只靠单次 LLM 调用解决问题。
单次调用是，用户问一个问题，LLM 直接回答，结束了。这种模式适合知识问答、文本生成这类「一次想清楚就够」的任务。但现实世界的复杂任务不是这样的。
复杂任务需要多步，而且每一步的结果会影响后面的走向。比如「查一下最近一周的销量，对比上月，生成一份分析报告」。这要先查本周销量，再查上月销量，对比计算，可能发现数据异常要深挖原因，最后组织成报告。每一步都依赖上一步的真实结果，没法一次性全想好。
而且现实里有意外。查到的数据可能缺失，外部 API 可能超时，中间某步可能失败需要换个方法。单次调用处理不了这些分支和意外，它只能给一个「假设一切顺利」的答案。
Agent 的控制循环，就是为这种「多步、有依赖、有意外」的复杂任务设计的。
规划，把任务拆成可执行的步骤
循环的第一步是规划。Agent 拿到一个任务后，不是立刻闷头干，而是先想清楚要分几步、每步做什么、按什么顺序。
规划的质量直接决定任务完成的质量。好的规划把大任务拆成清晰的小步骤，每步都可执行、可验证。坏的规划要么太粗（一步要做太多事，模型处理不了），要么太细（步骤之间太多依赖，容易乱），要么方向就错了。
规划可以是静态的（一开始全定好），也可以是动态的（边执行边调整）。复杂任务通常需要动态规划，因为执行过程中会有意外，原计划可能走不通，要根据实际情况调整。这也是 Agent 比传统工作流灵活的地方，工作流是预设的固定路径，Agent 能根据实际情况重新规划。
规划还有一个要点是知道什么时候停。Agent 要能判断任务什么时候算完成了，不然可能无限循环下去。这通常靠一个终止条件，比如目标达成了、或者尝试了 N 次还没成功就放弃。
执行，调用工具拿到真实结果
规划好了，开始执行。执行就是调用具体的工具，拿到真实的结果。
这一步的核心是，Agent 的每一步都基于真实世界的反馈，不是凭空推理。规划说要查销量，执行就去调查询接口，拿到真实的数字。规划说要发通知，执行就去调通知接口，确认发出去了。
这和纯 LLM 推理有本质区别。纯推理是在模型的参数空间里推，基于训练时学到的知识，可能过时、可能不准。执行是和真实世界交互，拿到的是当下的真实数据。这就是为什么 Agent 能完成「查实时数据」「操作真实系统」这类纯推理做不了的任务。
执行这一环的工程难度，主要在工具调用的可靠性上。参数校验、错误处理、重试、降级，这些在前面 Function Calling 那篇讲过。执行层的稳定，是整个 Agent 稳定的基础。
反思，基于结果调整下一步
这是循环里最关键、也最容易被忽略的一环。
执行完一个动作，Agent 拿到结果，它要「观察」这个结果，理解它意味着什么，然后决定下一步。结果符合预期，继续下一步。结果不符合预期（查到的数据是空的、API 报错了、中间发现新问题），调整计划，换个方法。
这个「观察结果、理解含义、调整策略」的过程，就是反思。没有反思的 Agent，是机械地按预设步骤走，遇到意外就崩。有反思的 Agent，能应对意外、能纠错、能在执行中学习。
ReAct（Reasoning and Acting）是这种思路的经典实现。它的每一步都是「思考一下现在的情况、决定一个动作、执行、观察结果」，然后循环。思考的部分让 Agent 能基于当前状态做判断，而不是盲目执行。
反思的深度决定 Agent 的智能程度。浅的反思只看「这一步成功没成功」。深的反思能理解「这一步的结果对整个任务意味着什么，要不要改变整体策略」。后者更接近人类的解决问题方式。
循环的工程实现
图：控制循环是一个带状态、带错误恢复、带终止条件的重复结构，工程稳定性靠四个保障点。
把这个循环工程化，有几个关键点。
状态管理。每一步的规划、执行结果、中间结论，都要存下来作为上下文，喂给下一步的决策。随着步数增加，上下文会变长，要管理好哪些信息要保留、哪些可以丢弃，否则 context 爆掉或者关键信息被淹没。
循环控制。最大步数要兜底，防止 Agent 陷入死循环。每一步要有超时，防止某个工具调用卡住整个循环。循环要有明确的退出条件，任务完成或者判定无法完成。
错误恢复。某一步失败了，Agent 要能决定是重试、换方法、还是放弃。不能让一个失败把整个任务卡死。这需要在反思环节判断「这个失败是暂时的还是根本性的」。
可观测性。Agent 的执行过程是个黑盒，不记录的话出了问题完全不知道哪一步错了。每一步的输入、输出、决策理由都要记下来，方便调试和改进。
理论上这个循环很优雅，工程上让它稳定跑起来极难。每一步都可能出错，错误会传播和放大，循环可能发散或者死循环。把循环做稳，靠的不是模型聪明，是工程上的状态管理、错误恢复、循环控制、可观测性。这也是为什么能跑 demo 的 Agent 很多，能上生产的 Agent 很少。
从循环理解 Agent 的本质
图：工具和 LLM 都是循环里的零件，规划-执行-反思的闭环才是 Agent 的本质。
回到开头的问题，Agent 的本质是什么。
不是能调工具，那只是执行环节的一个能力。不是用了大模型，那只是循环里做决策的引擎。Agent 的本质，是那个「规划、执行、反思」的控制循环。这个循环让系统能处理复杂任务、能应对意外、能在执行中调整，这些是单次 LLM 调用做不到的。
理解了这个本质，就能看懂各种 Agent 框架在设计什么。它们无非是在这个循环的不同环节做优化，规划用更强的推理、执行接更多的工具、反思用更深的观察。框架会换，但这个控制循环的范式，是 Agent 的底层架构，短期内不会变。
把循环的每一环都想清楚、做扎实，Agent 才能从「演示很酷」变成「真的能干活」。这是 Agent 工程化的全部核心。
