跳到正文

Agent 框架 vs LLM 怎么选?

Agent 系统组成架构分析,功能与应用区别详解

原题:请解释Agent系统的基本组成架构,并分析在已有大语言模型的情况下为什么还需要Agent框架,以及两者在功能和应用上的主要区别。

Agent · 快手真题

30 秒回答

  1. Agent的核心组件(规划、记忆、工具、行动)
  2. LLM的静态知识局限与Agent的动态能力扩展
  3. 单次推理vs多步交互的本质区别
  4. 工具调用与外部系统集成的必要性

回答与解析

答案要点

  • 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. 问法 1 · 场景切入

    假设我们做一个智能客服系统,用户问“帮我查一下上个月的订单”,LLM能直接回答吗?它不知道你的订单数据。那你怎么设计,才能让模型去查数据库、计算金额,并且一步步把结果告诉用户?

  2. 问法 2 · 层层追问

    大模型能直接完成复杂任务吗?……如果任务需要查天气、订酒店、发邮件,单靠一次调用行不行?……那你觉得需要哪些额外组件才能让它真正“做事”?……这些组件合起来就是Agent系统,你理解它的基本构成吗?

  3. 问法 3 · 直球架构

    解释一下Agent系统的核心组件,以及为什么有了LLM还不够?请从规划、记忆、工具、行动几个方面说,并说明LLM和Agent在交互模式和任务能力上的本质区别。

同模块相关题目