Agent 与 LLM 有什么区别？

在 LLM Agent 的语境下，LLM 是负责理解、推理和生成的模型，Agent 是围绕目标组织模型、工具、状态和执行循环的软件系统。两者是组件与系统的关系。

模型可以判断下一步做什么、生成工具名和参数；Agent 的运行程序负责实际调用工具，保存结果，再把反馈交给模型，决定继续、调整还是结束。因此，区别不只是“能聊天”与“能干活”，而是有没有把决策和真实执行连接成任务闭环。

例如用户要根据天气安排出行，单次模型调用可以给出建议；Agent 则可以先查询天气，拿到结果后调整方案。是否需要长期记忆、复杂规划或多个 Agent，要看任务，不能把这些都当成必备组件。

LLM 根据当前上下文生成回复，也可能生成结构化的工具调用请求，例如天气查询工具及城市、日期参数。生成调用请求与执行查询是两个步骤：运行程序解析请求、检查参数和访问范围，再调用实际函数或服务。

执行结果随后写回任务状态，并作为工具结果传给下一次模型调用。模型此时才获得外部数据，可以回答用户，也可以继续查询。框架常把这套流程封装起来，但底层仍有模型调用、工具执行和结果回传的职责划分。

当前状态可以包含用户目标、已取得的信息、工具返回和待处理事项。它由应用或所用服务保存和提供，不等于模型权重随着每轮对话被更新。跨会话记忆是进一步的存储与召回设计，和本轮任务状态也需要区分。

假设用户说：“帮我安排明天杭州的半日户外行程，遇到下雨就换室内。”

直接调用模型时，如果没有提供实时天气，也没有连接查询能力，模型可以分析要求、给出条件式建议，但不能凭生成内容确认真实预报。

Agent 可以先根据目标请求天气工具。假设工具返回下午有雨，模型便将户外活动安排在上午，并补充下午室内方案；如果查询失败，则根据错误决定重试、换可用来源，或说明暂时缺少天气依据。这里起作用的是外部观察影响了下一步，而不是把同一段建议重复生成几次。

单个 Agent 也能完成这个流程，无需为了这个任务再拆多个专家。

Agent 增加了连续行动能力，也增加了调用成本、等待时间和错误传播的可能。运行程序需要处理超时、错误反馈、调用预算和终止条件。对于明确的任务，可以用返回数据或输出检查判断是否完成，不能只凭一句“已完成”认定所有外部操作成功。

如果只是摘要、分类或根据已经给全的材料回答，一次模型调用就可能满足需求；步骤稳定的任务也适合显式工作流。只有下一步确实需要根据新信息作判断时，动态循环才有相应价值。

Function Calling 让模型能够生成可供程序处理的调用请求。是否执行、调用哪个真实接口、如何回传结果，仍由宿主程序或托管服务承担。若一个产品已经封装了这些能力，用户看到的是完整系统，不能因此把工具执行也归到模型本身。

多轮对话只能说明系统保留或重新提供了上下文。判断其 Agent 能力，还要看它是否围绕目标选择行动，并根据执行反馈推进任务。Agent 也可以从一次用户请求开始，自行完成多轮模型与工具交互。

不必须。简单任务可以用当前状态和工具循环完成，规划也可以直接体现在模型选择下一步的过程中。长期记忆、独立规划器或反思模块应解决明确需求，增加这些模块并不自动提高效果。广义的 Agent 还包括规则或其他决策机制驱动的系统，不全都以 LLM 为核心。

国内：JavaGuide：AI Agent 基础：采用 Agent Loop 的模型决策与工具反馈机制，说明正文中模型、工具和运行系统对状态及停止条件的分工。
国内：ranxi2001：一个 Agent 系统的核心组成：依据目标、状态、模型和工具的职责划分，解释正文中模型为何只是 Agent 的组件，以及当前状态与跨会话记忆的区别。
国内：Datawhale：初识智能体：借鉴传统智能体到 LLM 智能体的概念范围及旅行助手例子，说明正文中 Agent 不限于 LLM，以及天气反馈如何影响后续安排。
国外：Anthropic：Building effective agents：依据动态决策、环境反馈与停止条件，说明正文中 Agent 的运行控制及简单任务是否值得增加该系统的选型条件。
国外：LangChain：Agents：采用 Model 与 Harness 的系统边界，说明正文中模型如何与工具、提示和运行机制共同组成 Agent。