面试回答整理（Q1–Q3）

面试回答整理（Q1--Q3）

Q1：LLM 和 Agent 有什么区别？

回答思路

定义 → 局限 → 补全 → 举例 → 四模块

标准答案

① 先说 LLM 是什么

LLM 本质是条件概率模型，根据前面的 token 预测下一个 token。可以把它看作无状态函数：输入 Prompt，输出文本，每次调用独立，没有记忆，不了解外部世界。

② 再说 LLM 的四大天花板（要能展开）

只会说不会做：能告诉你"去天气 App 查"，但自己不会查
没有记忆：上下文窗口满了就"失忆"，跨会话什么都不留
知识截止：不知道训练截止日期之后的事
不会规划：让它做竞品分析，只会线性回答，不会自己拆成"搜集 → 分析 → 对比"

③ 一句话定义 Agent

Agent = LLM + 工具 + 记忆 + 规划，在循环中自主完成目标。

④ 用例子说清本质区别

任务："查明天北京天气，下雨就取消日历里的跑步计划"

LLM：只会回答"您可以打开天气 App......"
Agent：调天气 API → 调日历 API 找到跑步计划 → 删除 → 回复"已取消"

LLM 告诉你怎么做，Agent 直接帮你做完。

⑤ 加分：展开四模块

LLM（大脑）：理解意图、推理判断
规划模块：任务拆解、步骤排序
记忆模块：短期上下文 + 长期知识存储
工具模块：调用 API、数据库、代码执行器，是"手和脚"

⚠️ 别只说"Agent 就是 LLM 加工具"，要讲清四模块如何在循环中协作。

Q2：Agent 和 Workflow 有什么区别？

回答思路

核心分歧 → 各自举例 → 对比 → 混合架构（重点）

标准答案

① 核心区别：谁控制流程

Workflow 的控制权在代码手里，Agent 的控制权在 LLM 手里。

② Workflow

流程提前写死，LLM 只是某些节点的处理器。

例（退款）：接收申请 → LLM 提取信息 → 查订单库 → LLM 判断是否符合政策 → 退款/拒绝 → 通知。每个 if/else 都由开发者预先定义，LLM 不决定下一步做什么。

③ Agent

接收目标后自主规划路径。

例（退款）：先 read_ticket() → 发现高价值订单，search_policy_doc() → 需要审批，create_approval_request()。每一步都由 LLM 决定，同一个 Agent 面对不同申请会走不同路径。

④ 对比表

维度	Workflow	Agent
控制者	代码/开发者	LLM
Token 消耗	低（约 1x）	高（约 4--8x）
可预测性	高	低
灵活性	低	高
调试难度	容易	困难
适合任务	固定流程	开放式目标
典型场景	订单处理/报表	研究分析/客服

⑤ 关键加分：混合架构才是生产姿势

大多数生产系统是 Workflow 做稳定骨架 + Agent 处理异常和复杂情况 。

例（智能客服）：简单问题走 Workflow 直接答；复杂问题启动 Agent 自主决策；投诉工单直接转人工。

如何判断用哪个（追问）

流程固定、要求稳定可控、成本敏感 → Workflow
目标开放、路径不确定、需要灵活应对 → Agent
实际落地 → 两者结合

回答顺序：先讲清区别，再强调混合架构。这样面试官会觉得你有真实项目经验。

Q3：Agent 有哪些工作模式？

回答思路

总述四种 → 逐个讲（原理 / 优缺点 / 场景）→ 补充死循环防护

标准答案

模式一：ReAct（推理 + 行动）

原理：Thought → Action → Observation 循环，直到任务完成。是最经典的模式，LangChain、LangGraph 默认采用。
优点：透明可审计、能根据观察结果调整、通用性强
缺点：Token 消耗大、可能死循环、延迟高（每次 Action 都等 LLM）
补充：ReAct 本质是 Prompt 范式，循环的是文本，缺点在生产环境会被放大

🔥 高频追问：Agent 陷入死循环怎么办？（三点脱口而出）

最大步数限制：通常设 15 步，超过强制终止
重复动作检测：连续 3 次调用同一工具且参数相同，直接退出
超时控制：给整个任务设置最大执行时间

退出时不要直接报错，可以让 LLM 基于已有信息总结出一个尽力而为的答案。

模式二：Plan-and-Execute（先规划再执行）

原理：Planner 一次性生成完整计划，Executor 按计划逐步执行，不用每步重新思考全局
优点：Token 消耗约为 ReAct 的 20%，思路更清晰
缺点：计划可能不合理（计划 5 个竞品，搜出 50 个）
解决：加入重新规划检查点，每步执行后检查偏差，偏差大就触发重新规划

模式三：Reflection（自我反思）

原理：一个 Agent 生成，另一个审查，循环迭代到质量达标
类比：代码 Review。Writer 写代码 → Reviewer 找问题 → Writer 修改 → Reviewer 确认
适用：代码生成、法律文书、学术论文、创意写作等高质量要求场景，值得多花 Token
加分：可用于校正幻觉。发现事实存疑时触发"验证反思"，调用搜索工具核实，而不是盲目输出

模式四：Multi-Agent（多智能体协作）

原理：Orchestrator 负责理解需求、分配任务、汇总结果，下挂 Research Agent、Coder Agent、Reviewer Agent 等专业 Agent
主流框架 ：
- LangGraph（画流程图）：图结构编排，状态机，精细控制
- CrewAI（组建团队）：角色化 Agent，上手简单
- OpenAI SDK（接力传递（handoff））：handoff 机制，原生支持工具调用
- AutoGen（让 Agent 聊天）：微软出品，对话式，研究型友好
必提的观点（Anthropic 的建议） ：不要过早引入 Multi-Agent。一个强大的单 Agent 往往比多个简单 Agent 协作更稳定、更省钱。只有任务明确需要并行处理或专业分工时才用，否则调试起来很痛苦。

四种模式一图速记

模式	核心思想	优势	代价	适用场景
ReAct	边想边做	灵活、透明	Token 高、易死循环	通用、不确定任务
Plan-and-Execute	先规划后执行	省 Token	计划可能失效	步骤较明确的长任务
Reflection	生成 + 审查迭代	质量高	多花 Token	高质量输出
Multi-Agent	分工协作	并行、专业化	调试复杂	复杂、需分工任务