Agent 框架 vs LLM 怎么选?
Agent 系统组成架构分析,功能与应用区别详解
原题:请解释Agent系统的基本组成架构,并分析在已有大语言模型的情况下为什么还需要Agent框架,以及两者在功能和应用上的主要区别。
Agent · 快手真题
30 秒回答
- Agent的核心组件(规划、记忆、工具、行动)
- LLM的静态知识局限与Agent的动态能力扩展
- 单次推理vs多步交互的本质区别
- 工具调用与外部系统集成的必要性
回答与解析
答案要点
- Agent的核心组件(规划、记忆、工具、行动)
- LLM的静态知识局限与Agent的动态能力扩展
- 单次推理vs多步交互的本质区别
- 工具调用与外部系统集成的必要性
Agent系统的基本组成
Agent架构通常包含四个核心模块:
- 规划(Planning):将复杂任务拆解为可执行的子步骤,支持多步推理
- 记忆(Memory):短期记忆(对话上下文)+ 长期记忆(知识库存储)
- 工具(Tools):外部API、数据库、计算资源等的调用接口
- 行动(Action):执行具体操作并获取环境反馈,形成闭环
典型流程:用户输入 → 规划分解 → 工具调用/推理 → 观察结果 → 循环直至完成
为什么需要Agent框架
LLM的本质局限:
- 知识静态:训练数据有截止日期,无法获取实时信息
- 无状态:每次调用独立,无法持续与环境交互
- 无行动能力:不能执行计算、调用API、操作外部系统
Agent的核心价值:
- 通过工具调用突破能力边界(搜索、计算、数据库操作)
- 通过多轮交互实现复杂任务的逐步求解
- 通过反馈循环根据环境变化动态调整策略
两者关键区别
| 维度 | 纯LLM | Agent系统 |
|---|---|---|
| 交互模式 | 单次请求-响应 | 多轮循环迭代 |
| 知识来源 | 仅参数内知识 | 参数知识 + 实时外部数据 |
| 任务复杂度 | 适合单步推理 | 支持多步骤、长程规划 |
| 可靠性 | 幻觉不可控 | 工具输出可验证,降低不确定性 |
简单说:LLM是"大脑",Agent是"大脑+手脚+感官"的完整智能体。
口语版讲法(约4分钟)
- 问题本质:为什么要有Agent
- Agent核心组件:规划、记忆、工具、行动
- LLM vs 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越智能,出错越难看。
关键一句:复杂任务可能需要Multi-Agent协作,但会引入通信和一致性问题。
面试官还可能这样问
- 问法 1 · 场景切入
假设我们做一个智能客服系统,用户问“帮我查一下上个月的订单”,LLM能直接回答吗?它不知道你的订单数据。那你怎么设计,才能让模型去查数据库、计算金额,并且一步步把结果告诉用户?
- 问法 2 · 层层追问
大模型能直接完成复杂任务吗?……如果任务需要查天气、订酒店、发邮件,单靠一次调用行不行?……那你觉得需要哪些额外组件才能让它真正“做事”?……这些组件合起来就是Agent系统,你理解它的基本构成吗?
- 问法 3 · 直球架构
解释一下Agent系统的核心组件,以及为什么有了LLM还不够?请从规划、记忆、工具、行动几个方面说,并说明LLM和Agent在交互模式和任务能力上的本质区别。