面试题 · Agent
搜索「检索」匹配到口述回答，相关段落已展开。查看匹配内容 ↓
请阐述你对AI Agent的理解，并介绍几种常见的Agent行为模式及其特点。
AI Agent是以大模型为"大脑"的自主系统，与传统LLM的本质区别在于：它能主动规划任务、调用工具、与环境持续交互，而非仅做单次文本生成。
关键组件：规划（Planning）→ 记忆（Memory）→ 工具（Tools）→ 行动（Action）
按学习路线查看教程、项目和面试题。
| 场景 | 推荐模式 |
|---|---|
| 开放域问答、工具调用 | ReAct |
| 固定流程自动化 | Plan-and-Solve |
| 高精度代码/数学任务 | Reflexion |
场景切入
假设你在做一个智能客服Agent，用户问‘帮我查订单’，它得先调用订单接口，然后根据结果可能再问用户确认。这个过程里Agent怎么决定下一步做什么？你理解Agent和普通LLM填空有什么区别？
层层追问
你平时怎么用LLM做多步任务？……如果任务要调用外部工具，比如查数据库或者发请求，你怎么设计这个流程？……更具体一点，你会选哪种行为模式？ReAct和Plan-and-Solve各自适合什么场景？
直球架构
请直接阐述你对AI Agent的理解，并列举至少两种经典行为模式，比如ReAct和Plan-and-Solve，对比它们的特点、优缺点和适用场景。
这道题我觉得核心不是在问[[Agent]]的定义，而是考察你对LLM作为决策引擎的理解，怎么把大模型从一个只会接话的聊天机器人，变成一个能主动干活、调用工具、甚至自我纠错的智能体。我理解AI Agent本质就是让LLM拥有规划、记忆、工具和行动这四个组件，让它可以自主地拆解任务、执行步骤、观察反馈，而不是每次只生成一句话。
常见的Agent行为模式，我重点讲三种，因为实际落地时你会根据场景混着用。
先说[[ReAct]]，这是最直观的，推理和行动交替进行。你可以想象成一个人边想边做：先想一步，然后执行一个动作，看看发生了什么，再根据观察结果想下一步。这种模式容错性很强，环境变化了也能动态调整，但代价是token消耗大，步骤一多就容易跑偏或陷入死循环。所以它特别适合开放域问答、需要频繁调外部工具的场景，比如让Agent去查数据库、调API。但如果你用它做固定流程的任务，比如每天跑同一个报表，那每一步都要反复思考，反而浪费。
第二种是Plan-and-Solve，先规划后执行。这就像写代码前先画架构图，任务分解成清晰的步骤，然后一步一步执行。好处是效率高、解释性强，因为计划是可见的，出了问题容易定位。但缺点也很明显，计划一旦定下来就很僵化，执行中如果遇到意外，比如API返回格式变了，它不会灵活调整，只能重新规划。所以它更适合步骤明确、环境稳定的任务，比如数据处理pipeline或者定时报表生成。
第三种是[[Reflexion]]，自我反思型。这相当于给Agent加了一个批评家角色：做完一步或完成整个任务后，让模型自己评估结果对不对，如果错了就记录失败原因，下次绕开这个坑。这种模式在代码生成、数学证明这类可验证的任务上效果很好，能显著提升成功率。但代价是每次反思都要额外调用LLM，成本更高。
说到落地，其实很少只用一种模式，真正上线往往是混合使用。比如一个客服退款Agent，我会先用Plan-and-Solve做一个主流程，判断订单状态、计算退款金额、发起退款，但中间每一步都穿插ReAct的动态检查：比如调用订单API后，如果发现订单异常或用户有特殊备注，就临时切换到ReAct模式去跟用户确认。另外，遇到退款失败的情况，我会让Agent进入Reflexion模式，让它自己分析失败原因是参数错误还是权限不足，并尝试修正。
这里有个很重要的前提：Agent的可靠性高度依赖工具调用的稳定性。如果工具API不稳定，或者返回格式不统一，再好的规划也白搭。所以上线前我会特别关注工具调用的超时重试、错误码处理，以及Agent的异常恢复机制，比如连续失败多少次后应该主动上报人工。另外，记忆管理也是个大坑，长对话中Agent容易忘记前面的上下文，需要设计好短期记忆和长期记忆的切换策略。
还有一个方向我最近比较关注，就是[[Multi-Agent]]协作。当单个Agent面对复杂任务时，往往需要多个专业Agent分工，比如一个负责规划、一个负责检索、一个负责验证。但如何协调它们之间的通信和冲突，目前还没有特别成熟的方案，这也可能是未来Agent落地的关键瓶颈。
所以总的来说，我会把Agent模式看成一种工具箱，ReAct灵活但重、Plan-and-Solve轻但死板、Reflexion聪明但贵，我的工程判断是：优先用Plan-and-Solve搭骨架，用ReAct填充动态环节，用Reflexion兜底关键错误。如果环境足够稳定，甚至可以只用Plan-and-Solve加少量规则，把LLM调用降到最低。