Agent 框架 vs LLM 怎么选?

这道题其实在问一个很本质的问题：大模型本身已经很强了，为什么我们还要搞[[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越智能，出错越难看。