面试题 · Agent
请解释Agent系统的基本组成架构，并分析在已有大语言模型的情况下为什么还需要Agent框架，以及两者在功能和应用上的主要区别。
Agent架构通常包含四个核心模块：
典型流程：用户输入 → 规划分解 → 工具调用/推理 → 观察结果 → 循环直至完成
LLM的本质局限：
按学习路线查看教程、项目和面试题。
Agent的核心价值：
| 维度 | 纯LLM | Agent系统 |
|---|---|---|
| 交互模式 | 单次请求-响应 | 多轮循环迭代 |
| 知识来源 | 仅参数内知识 | 参数知识 + 实时外部数据 |
| 任务复杂度 | 适合单步推理 | 支持多步骤、长程规划 |
| 可靠性 | 幻觉不可控 | 工具输出可验证，降低不确定性 |
简单说：LLM是"大脑"，Agent是"大脑+手脚+感官"的完整智能体。
场景切入
假设我们做一个智能客服系统，用户问“帮我查一下上个月的订单”，LLM能直接回答吗？它不知道你的订单数据。那你怎么设计，才能让模型去查数据库、计算金额，并且一步步把结果告诉用户？
层层追问
大模型能直接完成复杂任务吗？……如果任务需要查天气、订酒店、发邮件，单靠一次调用行不行？……那你觉得需要哪些额外组件才能让它真正“做事”？……这些组件合起来就是Agent系统，你理解它的基本构成吗？
直球架构
解释一下Agent系统的核心组件，以及为什么有了LLM还不够？请从规划、记忆、工具、行动几个方面说，并说明LLM和Agent在交互模式和任务能力上的本质区别。
这道题其实在问一个很本质的问题：大模型本身已经很强了，为什么我们还要搞[[Agent]]？说白了，LLM是个静态的大脑，但我们要解决的是动态世界里的问题。所以我会从Agent的核心组成、和LLM的分工边界、以及落地时要注意的坑这几个角度来聊。
先说Agent的基本架构，我习惯把它拆成四个模块：规划、记忆、工具、行动。你可以这么理解，用户进来一个复杂任务，比如“帮我查一下上个月订单的退款进度”，Agent先做规划，把这个任务分解成“查订单号、调退款API、汇总状态”几个子步骤；然后通过记忆模块记住对话上下文，可能还要从长期记忆里拿用户的历史信息；接着调用工具，比如查数据库、调支付接口；最后执行行动，把结果返回给用户，并且根据反馈决定要不要继续下一步。整个流程是一个闭环，不是一次性完事。
那为什么纯LLM搞不定？核心在于LLM只有参数内的知识，而且每次调用是独立的。它没法执行实时查询，也没法记住之前说了什么，你问它“刚才那笔订单退款到哪了”，它只能瞎编。而Agent通过工具调用突破了这个边界，比如用[[Function Calling]]调一个退款状态查询接口，拿到的结果是可验证的。所以两者的边界很清楚：纯LLM适合单轮、知识型的问答，比如“解释一下什么是量子计算”；Agent适合多步、需要跟外部系统交互的任务，比如自动化客服退款流程。真正落地的时候，往往是LLM+Agent一起上，LLM负责推理和生成，Agent负责调度和执行。
举个例子，电商客服场景里用户说“我上个月买了个手机，现在降价了，能不能退差价”。纯LLM只能给一段话术，但Agent可以把任务拆成：先查订单信息，再查当前价格，然后判断是否符合差价保护政策，最后调用退款接口。每一步都通过工具调用拿到真实数据，而不是靠模型瞎猜。
这里有个坑：Agent的前提是工具接口必须可靠。如果接口不稳定或者返回的数据格式乱七八糟，Agent的规划就会断掉，甚至陷入死循环。常见失败场景是，Agent反复调用一个超时的API，导致用户体验极差。上线前我会特别关注超时重试机制和错误处理，比如给每个工具调用设一个最大重试次数，超时了就主动告知用户“查询暂时不可用”，而不是让Agent一直等。
对了，还有一个点值得聊：当任务特别复杂时，单Agent可能不够，需要[[Multi-Agent]]协作，一个负责规划，一个负责执行，一个负责校验。不过这会引入通信开销和一致性维护的问题，具体怎么设计要权衡。
所以总的来说，我更倾向把LLM看成Agent的“大脑”，而Agent本身是一个完整的智能体系统。选型的时候，我会先判断任务是否需要多步交互和外部数据，如果是，就上Agent，否则纯LLM就够。落地时一定先把工具链的稳定性打好，否则Agent越智能，出错越难看。