这道题我觉得本质上不是在问[[Agent]]的定义,而是在问:什么时候该让大模型自己动手干活,什么时候不该。因为Agent的优势和坑其实是一体两面,核心就一句话,它把LLM从聊天框里放出来,让它能调用工具、能规划步骤、能自主决策,但同时也把模型[[幻觉]]和不可控的风险放大了。
先说优势。Agent最典型的架构就是规划、记忆、工具、行动四个模块。规划靠[[Chain-of-Thought]]或者[[ReAct]]把大任务拆成子步骤;记忆分短期上下文和长期向量记忆,能跨会话保持状态;工具靠[[Function Calling]]对接外部API、数据库、计算资源;行动就是执行工具并观察结果,形成闭环。这个架构最大的好处是自主性和适应性。比如智能客服场景,用户说“我订单没收到”,Agent能自动判断是先查物流还是查订单状态,还是直接转人工。它不像传统流程树那样固定死,而是根据中间结果动态调整下一步。另一个例子是数据分析Agent,你给它一个“分析最近一周销售异常”的任务,它能自己决定先拉数据、再跑统计、发现异常点后进一步查原因,整个过程不需要人一步步指令。
但落地时挑战非常现实。首个坑是幻觉级联。规划步骤一多,任何一步的幻觉都会被放大。比如ReAct循环里,模型可能误解工具输出,导致下个决策也错,甚至陷入死循环或过早终止。在金融风控场景,Agent如果错误调用资金接口,后果很严重。所以上线前我一定会在关键节点加确认机制,就是人机协同(HITL),让模型只做建议,最终执行由人确认。再看延迟和成本。每一步规划都需要一次LLM推理,一个10步任务就是10次调用,Token成本指数级上升。实时推荐场景要求200毫秒响应,Agent根本跑不动。我的做法是用小模型做意图识别和简单规划,大模型只处理复杂分支,成本能降一个量级。最后看工具可靠性。外部API变更、返回格式异常,Agent经常直接崩掉,而且缺乏中断恢复机制。所以我会预设重试和降级流程,比如调用失败就自动走预设的兜底路径。
说到[[RAG]],很多人把Agent和RAG对立,其实它们分工不同。RAG解决的是“知识不够”的问题,Agent解决的是“动作不够”的问题。真正落地上,Agent把RAG当做一个工具来调用。比如用户问“我们公司对退货有什么政策”,Agent先规划需要查知识库,就调RAG工具拿结果,再基于检索结果继续规划,最后执行回复或发起退款流程。反过来,RAG也可以把Agent的输出作为上下文。所以不是二选一,而是按需组合。
其实还有一个更前沿的方向,就是[[Self-RAG]],让Agent自己学会反思和修正自己的输出,减少幻觉。但那个对模型能力和推理成本要求更高,目前还在探索阶段。
最后总结我的落地思路:我会把Agent看作一个高回报但高风险的任务执行框架,不是万能方案。适用场景一定是多步、需要工具交互、且可以容忍一定延迟和成本的任务;不适合纯知识问答或对实时性要求极高的场景。上线前我会特别关注容错、成本管控和监控体系,追踪每一步的输入输出、耗时、Token消耗。如果面试官有兴趣,我们可以深入聊聊Self-RAG或者多Agent协作的细节。