面试官你好,这道题问的是[[Agent]]的工作原理,我觉得本质上是想考察从被动问答到主动决策的跃迁。LLM本身是一个静态的响应器,你问它答,但Agent不一样,它要有目标感、能拆任务、会调工具,还能根据反馈自己调整。
我先说核心模块,规划、记忆、工具调用、执行反馈这四个。规划这块,说白了就是任务分解和推理策略。比如用户说‘帮我订机票’,Agent不能一步到位,得拆成查航班、选座位、支付这些子步骤。推理策略我常用[[ReAct]],就是推理和行动交错进行,每一步先想再动,动完看结果再想下一步。这里有个坑,规划不是死板的,如果工具调用失败了,比如支付接口超时,Agent得能动态调整,比如换备用支付方案。
再一个是记忆。记忆分短期、长期和工作记忆。短期记忆就是当前对话上下文,用[[滑动窗口]]或者摘要压缩来管理;长期记忆存历史经验和用户偏好,我一般用[[向量数据库]],比如把成功案例的[[embedding]]存进去,下次遇到类似场景直接检索复用;工作记忆就是当前步骤的中间结果,用显式的状态变量维护。这里有个前提,长期记忆的写入和检索质量很关键,如果embedding模型选得不好或者索引构建有问题,记忆反而会干扰决策。
工具调用是Agent跟外部世界交互的接口。[[Function Calling]]是主流做法,LLM生成结构化参数去调API,比如搜索、计算、数据库。工具选择需要精确匹配任务意图,所以工具的description prompt要写得足够清晰。结果解析也要注意,工具返回的可能是JSON或者HTML,得转成LLM能理解的上下文。
执行反馈是个闭环:观察环境、规划决策、执行动作、获取反馈、更新状态,然后继续。我特别看重自我反思这个环节,执行失败后要分析原因,比如参数错误就修正重试,工具不可用就换方案。举个例子,客服退款场景,Agent先查订单状态,如果订单异常,它不能直接退款,得先走人工审核流程,然后根据审核结果再决定下一步。这个闭环的关键是每个动作的观察结果都要写回记忆,影响下一步的思考。
协同工作机制我拿ReAct举例:Thought是‘我需要查北京明天天气’,然后Action是调用天气API,传入location和date参数,Observation返回JSON数据,再Thought‘根据温度建议穿衣’,最后Action生成回复给用户。每一步的Observation都会更新短期记忆,形成推理-行动-观察的持续迭代。
这里有个延伸点,就是持续学习怎么落地。我倾向于把成功任务轨迹,包括规划路径和工具调用记录,存到长期记忆里做经验沉淀;失败案例则触发自我批评prompt,让Agent自己分析原因并更新策略。但更激进的做法是用这些高质量交互数据做[[SFT]]或[[RLHF]]微调底层模型,不过这样做成本高且容易遗忘,所以我会把Agent看成一个可进化的任务编排器,优先靠记忆和反思来迭代,模型微调只作为锦上添花。
落地时我会特别关注几个风险:一是工具可靠性,如果外部API不稳定,Agent的整个推理链就会断;二是记忆一致性,长期记忆如果混入了噪声,决策质量会下降;三是失败处理,如果Agent在闭环里卡住了,得设计超时和回退机制。所以我的判断是,Agent的核心不是模型多强,而是闭环设计多健壮。