面试题 · Prompt
搜索「LLM 检索增强生成」匹配到口述回答，相关段落已展开。查看匹配内容 ↓
请系统阐述AI Agent的核心特点，分析其在当前技术条件下的优势与局限性，并展望未来在自动化、智能服务等领域的发展潜力。
Agent = LLM + 环境交互能力，区别于纯生成模型的关键：闭环反馈机制
四大核心组件
主流架构模式
学习内容与项目面试，在同一条路上。
| 模式 | 特点 | 代表 |
|---|---|---|
| ReAct | 推理与行动交替，实时修正 | 大多数开源Agent |
| Plan-and-Execute | 先全局规划再执行 | 复杂多步骤任务 |
| Multi-Agent | 多角色协作分工 | AutoGPT、MetaGPT |
当前优势
核心局限
短期（1-2年）：垂直场景深度落地
中期（3-5年）：多智能体协作生态
关键瓶颈：可靠性的数量级提升——从"80%可用"到"99.9%可信"，需要推理能力、验证机制、安全架构的系统性突破。
场景切入
假设我们做一个智能客服系统，用户说“帮我查一下上个订单的物流”，然后你调用API查到了，用户又说“那再帮我改个地址”，这时候你需要继续用刚才的订单信息吗？这就是Agent的感知、记忆和行动链。你理解Agent和普通LLM的区别吗？
层层追问
你平时用LLM做任务，通常是一问一答对吧？……但如果任务需要调用多个工具、依赖上下文、并且步骤之间需要修正，你会怎么设计？……这其实就是Agent的核心思路，你能说说它和纯LLM比有什么独特的地方吗？
直球架构
请直接阐述AI Agent的核心特点，包括它的感知、规划、行动、记忆组件，再分析当前的优势和局限性，比如幻觉累积、成本问题，最后展望一下它在自动化领域的落地潜力。
这道题问AI [[Agent]]，我觉得本质不是在问Agent的定义，而是问从静态模型到动态系统的跃迁，也就是LLM怎么从“回答问题”变成“解决问题”。我理解Agent就是LLM加上环境交互能力，核心区别在于闭环反馈机制，模型不再是一次推理完事，而是能感知环境状态、规划行动、调用工具、最后把结果反馈回来，形成循环。
具体来说，它有四个核心组件：感知、规划、行动、记忆。感知就是接收外部信息，比如API返回、用户输入；规划是任务分解和策略选择，像[[Chain-of-Thought]]、[[ReAct]]、[[Tree-of-Thoughts]]这些模式；行动是调用工具、执行代码；记忆分短期上下文和长期知识库，长期一般用向量检索。
主流架构模式有几种。ReAct是推理和行动交替，实时修正，适合大多数场景。Plan-and-Execute是先全局规划再执行，适合复杂多步骤任务，但规划错了后面全白费。[[Multi-Agent]]是多角色协作，比如规划Agent、执行Agent、验证Agent分工。实际落地时，我很少单独用一种，往往是ReAct加Plan-and-Execute混合，比如让一个规划Agent先拆任务，每个子任务再用ReAct循环执行，这样既有全局视野又能灵活调整。
优势很明显。一是能力边界扩展，通过工具调用突破LLM的知识截止和计算限制，比如让它查实时数据、算数学题。二是任务泛化，同一个框架能适配查询、分析、执行不同场景。三是持续进化，执行反馈能形成数据飞轮，越用越准。
但局限性也硬。最头疼的是错误累积，单步[[Hallucination]]导致后续规划全偏，一步错步步错。成本与延迟也高，多轮工具调用token消耗大，响应时间激增。还有安全边界，工具权限管控、沙箱隔离机制还不成熟，万一Agent调了不该调的API就麻烦了。另外评估困难，端到端效果很难量化，缺乏统一benchmark。
举个例子，自动化运维场景，Agent可以做故障根因分析。比如系统告警了，Agent先感知到告警信息，然后规划：查日志、查指标、查变更记录，每一步调用对应工具，最后综合判断根因。这听着很美好，但落地前提是工具接口稳定、权限严格控制。常见失败场景是Agent查日志时返回数据太大，模型上下文窗口撑爆，或者幻觉导致误判，把正常变更当成故障原因。上线我会特别关注错误累积，给每个中间结果加置信度阈值，分太低的不往下走，或者让人工介入确认。
说到可靠性，我觉得现在最关键的瓶颈是从80%可用到99.9%可信。比如能不能让Agent自己验证自己的推理，像[[Self-RAG]]或[[Chain-of-Verification]]那样，需要系统性突破。
所以我对Agent的判断是：短期1-2年垂直场景深度落地，比如代码生成加执行闭环的企业工具；中期3-5年多智能体协作生态，Agent作为数字员工接受管理。但我更看重的是可靠性，没有这个，Agent永远只是玩具。