视野题 - 面试题解答

生成日期：2026-05-05 | 共 16 题来源：Datawhale / 各大厂面经 / 牛客 2026-05-05 更新：新增 5 题，删除 1 题（具身智能），简化 1 题（多模态改为 Agent 工程视角）

Q1：[来源:书中原题][2025-04] 如何看待 RAG 与长上下文的关系？三年后还需要 RAG 吗？

考察点

对技术发展趋势的判断力和对两种知识注入路线的深度理解。

解答思路

对比 RAG 与长上下文的本质差异
分析各自不可替代的优势
给出未来三年的预判

参考答案

核心观点：RAG 和长上下文是互补关系而非替代关系，三年后仍然需要 RAG。

RAG 不可替代的价值： - 知识时效性：RAG 可以在秒级更新知识（改文档即可），长上下文的模型训练无法做到实时更新 - 可追溯性：RAG 可以精确引用来源，长上下文中的知识内化在权重中，无法追溯 - 成本控制：每次只检索相关片段，比将全部知识放入上下文窗口省 token

长上下文的优势： - 全局推理：当需要在整本书或整个代码库中进行跨段落的复杂推理时，全量上下文优于片段检索 - 避免信息丢失：RAG 可能漏掉关键文档，长上下文确保所有信息都在

三年后预判： - RAG 不会消失，但形态会演进：从"向量检索 + 拼接"进化为"多模态知识图谱 + 智能路由" - 长上下文会越来越普及（1M+ token），但不会替代 RAG——因为大多数场景不需要全量上下文 - 最佳实践是两者的混合：用长上下文承载核心知识，用 RAG 补充动态信息

Q2：[来源:书中原题][2025-04] DeepSeek-R1 的 GRPO 方法相比 PPO 的核心优势是什么？

考察点

对最新训练方法进展的了解。

解答思路

解释 PPO 的痛点
说明 GRPO 的创新
对比优劣

参考答案

PPO 的核心痛点： 需要一个额外的 Value Network（Critic）来估计每个状态的价值函数。Critic 的参数量和 Actor 模型相当，意味着 PPO 训练时需要同时加载 Actor 和 Critic 两个大模型，显存消耗翻倍。

GRPO 的创新： 省去了 Critic 模型。它的核心思想是：对于同一个 prompt，采样 G 个不同的输出，计算这 G 个输出的奖励，然后用奖励的组内归一化（减均值除以标准差）作为优势函数的估计。

具体做法： 1. 对同一 prompt 生成 G 个输出 2. 用 Reward Model 给每个输出打分 3. 组内归一化：Advantage_i = (Reward_i - Mean) / Std 4. 用 Advantage 直接优化策略

对比：

维度	PPO	GRPO
需要 Critic	是（参数量翻倍）	否
显存占用	高	减半
实现复杂度	高（Critic 训练、KL 控制）	低
效果	成熟稳定	接近 PPO，某些场景更好
适用场景	通用	推理/数学等可验证任务

劣势： GRPO 需要 G 个采样（通常 G=4-8），每个 prompt 需要多次生成，训练吞吐量下降。

Q3：[来源:书中原题][2025-04] 如何看待开源模型和闭源模型生态的竞争与共存？

考察点

对 AI 行业格局的宏观理解。

解答思路

分析各自优势
说明竞争态势
预判未来趋势

参考答案

开源模型优势： - 可本地部署，数据不出境（隐私/合规要求） - 可微调和定制，适合垂直场景 - 无供应商锁定风险 - 成本可控（一次投入 vs 按量计费）

闭源模型优势： - 无需运维基础设施 - 持续迭代升级，用户自动受益 - 能力天花板更高（目前最强模型仍是闭源的） - 生态完善（API、SDK、工具链成熟）

竞争态势： - 开源正在快速缩小与闭源的能力差距：Qwen2.5-72B 已接近 GPT-4 水平 - 闭源在推理能力、多模态、安全性上仍领先 6-12 个月 - 中国市场：闭源（通义千问、DeepSeek）+ 开源（Qwen、DeepSeek）双轨并行

未来趋势： - 开源会越来越强，但闭源不会消失——两者会像 Linux vs Windows 一样长期共存 - 开源擅长"够用就好"的场景，闭源擅长"追求极致"的场景

Q4：[来源:Datawhale][2025-04] 你认为当前 LLM 距离 AGI 还有多远？最关键的缺失能力是什么？

考察点

对 AI 发展前沿的独立思考能力。

解答思路

客观分析现状
列出关键缺失
给出个人判断

参考答案

现状评估： 当前 LLM 在语言理解和生成上已接近人类水平，但在多个维度上仍有本质差距。

最关键的缺失能力：

世界模型（World Model）：LLM 是基于文本共现学习的，缺乏对物理世界的内在理解。它知道"杯子掉在地上会碎"是因为文本中这么说，而非因为它理解重力、材质等物理规律。
因果推理：LLM 擅长关联和模式匹配，但缺乏真正的因果推理能力——区分"相关性"和"因果性"。
持久记忆和持续学习：LLM 的训练是离线的，无法从每次交互中持续学习。对话结束即遗忘。
自主目标设定：LLM 只能在用户给定的目标下工作，无法自主发现和定义问题。

时间判断： 距离 AGI 至少还有 5-10 年。关键不是模型能力的问题，而是架构范式的根本转变——可能需要从纯预测式模型转向包含世界模型、因果推理和持续学习的混合架构。

Q5：[来源:Datawhale][2025-05] Transformer 架构会长久统治这个领域吗？还是你看到了像 SSM（Mamba）等新架构的潜力？

考察点

对模型架构未来演进的判断力。

解答思路

分析 Transformer 的瓶颈
介绍替代方案
给出预判

参考答案

Transformer 的瓶颈： - 计算复杂度 O(n²)，超长序列下不可行 - KV Cache 显存占用随序列长度线性增长 - 推理时自回归生成，无法并行

替代方案： - Mamba / SSM（状态空间模型）：O(n) 复杂度，推理时无需 KV Cache，超长序列下优势明显 - RWKV：结合 Transformer 效果和 RNN 的推理效率 - 混合架构：Transformer + Mamba（早期层用 Mamba 处理长序列，后期用 Transformer 做精细推理）

预判： Transformer 不会在 3-5 年内被完全替代，但在特定场景下会被混合架构部分替代。SSM 的核心问题是效果尚不及 Transformer，需要在算法层面进一步突破。

Q6：[来源:Datawhale][2025-04] 你认为未来 1-2 年内，Agent 技术最有可能在哪个行业率先实现大规模商业落地？

考察点

对 AI Agent 商业应用前景的判断力。

解答思路

分析落地条件
列出候选行业
给出判断

参考答案

落地条件： 高价值场景 + 可结构化 + 容错空间大 + ROI 明确。

最有可能的行业：

客服领域（已在发生）：AI 客服已能处理 60-80% 的常见咨询，ROI 明确
软件开发（正在发生）：GitHub Copilot Cursor 等工具已大幅提升开发者效率
数据分析：Text2SQL + 可视化自动生成，降低数据分析门槛
法律合规：合同审查、法规检索、合规检查——高价值、可追溯、容错空间适中

判断： 客服和软件开发已经在大规模落地，接下来 1-2 年最有爆发潜力的是企业内部流程自动化——用 Agent 替代重复性高的办公流程（审批、报告生成、数据录入），因为这些场景的 ROI 最易量化、技术门槛适中、企业付费意愿强。

Q7：[来源:Datawhale][2025-04] Agent 应用中如何处理多模态输入（图片、表格、音频）？

考察点

对 Agent 系统中多模态输入处理的工程设计和方案选型能力。

解答思路

分析 Agent 常见多模态场景
说明每种模态的处理策略
给出架构设计建议

参考答案

Agent 多模态场景： - 图片理解：用户上传截图/照片，Agent 需要理解内容后回答 - 表格处理：用户传入 Excel/PDF 表格，Agent 需要提取和分析数据 - 音频处理：语音输入转文本后交给 Agent 处理

处理策略：

模态	处理方案	关键点
图片	用多模态模型（GPT-4o/Claude/Qwen-VL）直接分析	无需先转文本再处理，端到端保留视觉细节
表格	小表格 → 直接 Markdown 放入 Prompt；大表格 → 结构化提取后存储	避免将超大表格直接塞入 Prompt 导致上下文爆炸
音频	Whisper/Whisper-large 转文本后再处理	保留说话人信息和时间戳，方便 Agent 做上下文判断

架构建议： 不要在 Agent 核心循环中做模态转换——在 Agent 接收输入前先做预处理（转文本/提取结构），将标准化后的数据交给 Agent，减少上下文窗口的无效占用。

未来趋势： 1. 全模态原生：不再是"文本模型 + 视觉插件"，而是从训练阶段就统一多模态的统一架构 2. 实时交互：从"上传文件 → 等待分析 → 返回结果"到"实时对话 + 实时视觉理解" 3. 视频理解：从静态图片到动态视频，理解时序因果关系（"这个人为什么突然跑起来了"） 4. 多模态生成：输出不仅是文本，还包括图片、音频、视频

关键挑战： 不同模态的信息密度差异巨大——一段 1 分钟视频的 token 数可能超过 1 万字文本，如何高效压缩和表示是多模态融合的核心问题。

Q8：[来源:书中原题][2025-04] 如果让你规划一家 AI 创业公司的技术栈（2025-2027），如何选择底座模型、Agent 框架与基础设施？

考察点

对 AI 技术栈选型的全局思考能力。

解答思路

选型原则
各层推荐
风险控制

参考答案

选型原则： 不过度依赖单一供应商，保持灵活性，优先选择开源生态。

底座模型： - 主模型：Qwen2.5-72B（开源、中文能力强、商业友好） - 备用：Claude Sonnet（API 调用，作为强模型兜底） - 本地部署：Ollama + Qwen2.5-7B（低成本场景）

Agent 框架： - LangGraph（有状态图执行，生产级可靠性最高） - MCP 协议接入工具（标准化，避免被单一框架锁定）

基础设施： - 向量库：Qdrant（性能好、开源） - 缓存：Redis（通用） - 监控：LangFuse（Agent Trace）+ Grafana（基础设施） - 部署：Docker + K8s（标准化，可迁移到任何云）

风险控制： - 不锁定单一 API 供应商（用 LiteLLM 抽象层） - 核心能力本地化（微调模型本地部署，不依赖外部 API） - 数据不出境（合规要求）

Q9：[来源:Datawhale][2025-04] 你如何看待 Agent 领域的"涌现能力"？应该追求更强大的基础模型，还是更精巧的 Agent 架构？

考察点

对 Agent 发展路线的辩证思考。

解答思路

解释两种路线
分析各自的边际效益
给出综合判断

参考答案

两种路线： - 更强模型：相信"大力出奇迹"，只要模型够强，简单的 Agent 框架就能完成复杂任务 - 更精巧架构：认为模型能力已够用，瓶颈在于如何组织、编排、记忆和反思

分析： - 当前阶段（2025-2026）：模型能力仍在快速提升，更强模型的边际收益更高。同样的简单 Agent 框架，从 GPT-3.5 到 GPT-4 再到 GPT-4o，任务完成率从 20% → 50% → 80% - 下一阶段（2027+）：当模型能力达到某个阈值后，架构的边际收益会超越模型——因为此时瓶颈不再是"理解能力"，而是"系统性思考"和"长期规划"

判断： 短期内优先选择强模型 + 简单框架，快速验证场景。中长期（模型能力稳定后）投入 Agent 架构的精细化设计。

Q10：[来源:Datawhale][2025-04] 个性化是 LLM 应用的重要方向。如何平衡效果、隐私和安全？

考察点

对 AI 应用中伦理和隐私问题的思考。

解答思路

分析三者矛盾
给出平衡方案
提到合规要求

参考答案

矛盾： - 效果好需要更多用户数据（对话历史、偏好、行为） - 隐私保护要求最小化数据收集 - 安全要求防止数据泄露和滥用

平衡方案： - 数据本地化：用户数据存储在用户设备上，模型推理用联邦学习（模型到数据，而非数据到模型） - 差分隐私：在数据中添加噪声，保证统计有用但个体不可追踪 - 显式授权：用户明确同意才收集数据，且随时可删除 - 最小化原则：只收集完成任务必需的数据

合规参考： 欧盟 GDPR、中国《个人信息保护法》、美国各州隐私法——合规不是负担而是竞争优势（用户更信任合规产品）。

Q11：[来源:书中原题][2025-04] LLM Agent 距离"可信赖地替代人类完成复杂工作"还差哪三个核心能力？

考察点

对 Agent 可靠性问题的深度分析能力。

解答思路

定义"可信赖"
分析三个核心差距
结合论文和产品论证

参考答案

核心差距：

1. 可靠性天花板（当前 ~70-80%） - GAIA Benchmark 显示，最强 Agent 在开放域任务上的成功率仅约 50% - 人类可接受的标准是 >99%（如客服场景） - 差距来源：工具调用失败、幻觉输出、上下文丢失、死循环

2. 长期规划能力 - 当前 Agent 擅长单步或少步任务（<5 步） - 但复杂工作（如"写一份商业计划书"）需要数十步，涉及信息收集、分析、写作、排版 - Agent 在多步过程中容易"忘记"初始目标，或在中间步骤偏离方向

3. 自我验证与纠错 - 人类在执行过程中会自我检查（"这个数据对吗？"、"这个结论合理吗？"） - Agent 缺乏这种元认知能力——即使输出明显错误，也可能自信地提交 - 需要：(a) 内置验证机制（输出后自动检查）(b) 外部验证工具（如代码执行验证、事实核查）

论文支撑： SWE-Bench 显示最强 Agent 在真实 GitHub issue 上的解决率仅 ~25%；τ-Bench 显示在复杂交互任务上 Agent 成功率 <40%。这些 benchmark 清楚地表明 Agent 距离"可信赖"还有实质性差距。

Q12：[来源:知乎/腾讯云][2026-04] Agent 有哪些工作模式？ReAct、CoT、ToT、Reflexion、Plan-and-Solve 的对比是什么？

考察点

对 Agent 核心规划范式的系统性理解，以及在不同场景下的选型判断。

解答思路

分别定义每种工作模式
对比优缺点和适用场景
给出选型建议

参考答案

模式	核心思想	优势	劣势	适用场景
CoT (Chain of Thought)	让模型一步步推理再给出答案	提升复杂推理准确率	只做推理，不行动	数学题、逻辑题
ReAct	思考-行动-观察循环	能利用外部工具	单步错误会传播	需要工具调用的任务
ToT (Tree of Thought)	维护多个推理路径，搜索最优解	可回溯，容错强	Token 消耗大，慢	需要探索多解的问题
Reflexion	执行后反思，从失败中学习	自我纠错能力	多一轮 LLM 调用	长链路任务
Plan-and-Solve	先制定完整计划再执行	全局视角，减少偏离	计划可能不切实际	多步骤复杂任务

选型决策树： - 纯推理题 → CoT - 需要调用工具 → ReAct - 工具调用容易出错 → Reflexion（加入反思环节） - 需要探索多种可能性 → ToT - 任务结构清晰、可预先规划 → Plan-and-Solve - 实际项目中最常用：ReAct + Reflexion 的组合

2026 年新趋势： LangGraph 等框架允许将这些模式作为"节点"混合使用，而非只能选一种。例如：先用 Plan-and-Solve 制定计划，然后用 ReAct 执行每个步骤，最后用 Reflexion 检查结果。

Q13：[来源:腾讯云/CSDN][2026-04] MCP 和 A2A 是互补还是替代关系？2026 年 Multi-Agent 的行业趋势是什么？

考察点

对 Agent 协议生态演进方向的判断，以及对行业趋势的洞察。

参考答案

MCP 和 A2A 是互补关系： - MCP 解决的是"AI 应用如何标准地调用工具"（内部集成） - A2A 解决的是"独立 Agent 之间如何协作"（外部协作） - 一个完整的 Agent 系统通常同时需要两者：内部用 MCP 管理工具，外部用 A2A 与其他 Agent 通信

2026 年 Multi-Agent 行业趋势：

协议标准化： MCP 和 A2A 成为行业标准，就像 HTTP 之于 Web。工具提供商会发布 MCP Server，Agent 平台通过标准协议接入
Agent 市场（Agent Marketplace）： 出现类似 App Store 的 Agent 分发平台，用户可组合多个专业 Agent 完成复杂任务
企业级 Agent 编排： 企业不再依赖单一的"全能 Agent"，而是组建"Agent 团队"——每个 Agent 负责一个专业能力，通过编排器协调
从 ReAct 到结构化工作流： 生产环境中，纯 ReAct 的不确定性太高，越来越多的企业选择"结构化工作流 + 关键节点用 Agent"的混合模式
Agent 安全成为独立领域： 随着 Agent 被赋予更多操作权限（发邮件、写数据库、调 API），Prompt Injection、权限越权、工具滥用等安全问题催生了专门的 Agent Security 领域
评估体系成熟： 从 benchmark 竞赛转向真实业务指标——任务完成率、用户满意度、成本效率

Q14：[来源:牛客/知乎][2026-04] Agent 和 Workflow 的边界在哪里？什么时候用 Agent，什么时候用 Workflow？

考察点

对 Agent 与 Workflow 两种范式的深度理解和务实选型能力。

参考答案

本质区别：确定性 vs 自主性。

维度	Workflow	Agent
执行路径	预先定义的固定流程	动态规划，实时决策
输入输出	确定的 Schema	自然语言
容错性	低（某步失败则整体失败）	高（可重试、可替代路径）
可预测性	高	低
开发方式	代码/配置定义流程	Prompt + 工具定义能力
维护成本	流程变更需改代码	改 Prompt 即可

何时用 Workflow： - 流程固定、步骤明确（如：审批流 → 发邮件 → 更新数据库） - 对确定性和合规性要求高（金融、医疗场景） - 不需要自然语言理解

何时用 Agent： - 输入不确定，需要理解意图 - 任务需要动态规划（如：Deep Research，不知道要查多少轮） - 需要处理异常情况（如：工具返回意外结果时自适应）

生产实践：混合模式最常用。 外层用 Workflow 保证流程的确定性和合规性，关键决策点嵌入 Agent 做智能判断。例如：退款流程是固定 Workflow，但"判断用户是否符合退款条件"这一步交给 Agent 分析。

Q15：[来源:腾讯云/CSDN][2026-04] 自主 Agent 的三大核心安全风险是什么？如何防范？

考察点

对 Agent 安全体系的系统性理解。

参考答案

三大核心风险：

1. 提示注入（Prompt Injection）： - 直接注入： 用户在输入中注入恶意指令（"忽略之前的指令，现在..."） - 间接注入： RAG 检索到的文档中包含隐藏指令 - 防御： 输入过滤（分类器）+ Prompt 隔离（XML 分隔）+ 输出验证 + 工具权限基于用户而非 Agent

2. 权限越权（Privilege Escalation）： - Agent 被赋予了超出用户应有权限的能力 - 例如：普通员工通过 Agent 查到了高管薪资数据 - 防御： 工具调用时传递用户身份和权限，工具服务端基于用户身份做鉴权（而非信任 Agent 的调用）

3. 工具滥用（Tool Misuse）： - Agent 错误地调用工具或传递了有害参数 - 例如：Agent 将用户输入直接作为 SQL 执行 - 防御： 工具参数校验（白名单、类型检查）+ 沙箱执行（数据库只读权限、文件系统 chroot）+ 高危操作人工审批

纵深防御架构：

用户输入 → 输入过滤层（检测注入）
         → Agent 规划层（Prompt 隔离 + 工具白名单）
         → 工具执行层（参数校验 + 沙箱 + 权限检查）
         → 输出验证层（敏感信息过滤）
         → 人工审批层（高危操作）

Q16：[来源:知乎/CSDN][2026-04] Multi-Agent 系统中，Agent 隔离性的核心意义是什么？如何设计？

考察点

对多 Agent 系统架构中安全性和稳定性的理解。

参考答案

隔离性的核心意义： 防止一个 Agent 的错误行为或恶意操作影响其他 Agent 和整个系统。类比：操作系统中的进程隔离。

隔离维度：

隔离维度	隔离内容	实现方式
上下文隔离	每个 Agent 的对话历史、记忆	独立的 session 存储，不共享消息
工具权限隔离	每个 Agent 可调用的工具集	基于角色的工具白名单
数据访问隔离	每个 Agent 可访问的数据范围	用户级权限传递，Agent 不持有额外权限
执行环境隔离	工具代码的执行环境	Docker 容器 / 沙箱进程
资源配额隔离	每个 Agent 的 Token 预算、执行时间	配额管理器，超限即终止

设计原则： - 最小权限原则： 每个 Agent 只拥有完成其任务必需的最小权限 - 零信任： Agent 不信任其他 Agent 的输出，需验证后使用 - 失败域隔离： 一个 Agent 崩溃不影响其他 Agent - 审计可追溯： 每个 Agent 的操作独立记录，方便事后追溯