AI & 后端复习手册

Appearance

第三十六部分：AI 全栈硬核面试真题集、前沿范式与 OpenClaw/Claude Code 源码深度解析 ​

第 1 篇：AI Agent 核心架构与设计范式 (16 题) ​

题 001：什么是 Agent？与传统 LLM 有何本质不同？ ​

  • 面试官意图：考核你是否理解从单纯“文本生成器”到具备“自主感知、规划、工具调用与记忆”的 Agent 范式转变。
  • 30 秒回答： “LLM 本质上是一个非确定性文本补全引擎 (Predict-Next-Token)；而 Agent (智能体) 是以 LLM 为‘大脑’，结合 感知 (Sensory)、规划 (Planning)、记忆 (Memory) 与 工具执行 (Tools/Action) 四大核心组件构成的闭环自主系统。 本质区别在于：LLM 只做单次 Input ➔ Output 映射；Agent 则能在环境中独立执行任务、接收环境反馈 (Observation)、自我反思并连续决策，直到达成预设 Goal。”
  • 物理架构拓扑图：
     [环境 Environment] ──(Observation)──> [Agent 感知 Sensory]
                                              │
                                              ▼
 [记忆 Memory (Short/Long-term)] <──> [LLM 大脑 (Planning & Reflection)]
                                              │
                                              ▼
 [环境 Environment] <──(Action)────── [工具执行 Tools / Execution]

题 002：Workflow，Agent，Tools 这三者的概念与本质区别？ ​

  • 30 秒回答：
    • Tools (工具)：原子的物理能力（如搜索 API、Python 解释器、SQL 执行器），是 Agent 作用于物理世界的‘手和脚’。
    • Workflow (工作流)：确定性的 DAG (有向无环图) 流程。分支逻辑在代码中硬编码 (If-Else)，LLM 仅用于节点内的文本处理，可控性极高。
    • Agent (智能体)：非确定性的自主决策循环。由 LLM 动态决定下一步调什么 Tool、是否重试或结束，具备高灵活性但可控性稍低。

题 003：ReAct、Plan-and-Execute、Reflection 三种范式区别与选型？ ​

  • 30 秒回答：
    • ReAct (Reason + Act)：Thought ➔ Action ➔ Observation 循环。每走一步思考一次，适合简单、动态环境交互。缺点是步骤多时易迷失方向。
    • Plan-and-Execute (先规划后执行)：第一阶段全量拆解子任务列表 (Sub-tasks)，第二阶段按序调用 Worker 执行。适合复杂、长距离依赖的任务。
    • Reflection (自反思/自我纠错)：在 Actor 输出后，引入 Evaluator 对结果打分校验，未达标则反馈 Error 重试。适合代码生成、高准确率要求场景。
  • 选型对比表：
范式决策粒度适应场景缺点/开销
ReAct单步交替简单问答、工具查询容易陷入死循环
Plan-and-Execute宏观全量拆解复杂软件开发、多步骤分析初始规划错导致全盘皆输
Reflection结果校验回溯AI 编程、数学推理、公文写作Token 消耗增加 2~3 倍

题 004：复杂任务怎么做拆分？为什么拆分？效果如何提升？ ​

  • 30 秒回答： “大模型受限于上下文注意力分散与 Reasoning 步长限制。如果不拆分，直接让 LLM 吐出上万行的系统，准确率会断崖式下跌。 拆分策略：
    1. 层次化拆分 (Hierarchical Decomposition)：主 Agent 拆分为模块级任务，指派给 Sub-Agent；
    2. 少样本示范 (Few-shot CoT Prompting)：在 System Prompt 中显式示范子任务划分格式；
    3. AST / 代码结构导向拆分：按文件与函数依赖链拆分。 效果提升：配合并发并行执行与子任务校验，准确率可从 40% 提升至 85% 以上。”

题 005：AI Agent 的长短期记忆系统怎么做的？粒度与存储设计？ ​

  • 30 秒回答：
    • 短期记忆 (Short-Term Memory)：当前的 Conversation History (Messages List)。粒度为单次 Session，保存在 Redis / 内存中，使用 Sliding Window (滑动窗口) 或 Summary (摘要) 实时压缩；
    • 长期记忆 (Long-Term Memory)：跨 Session 的用户偏好、历史经验与 Gotchas。粒度为实体/事件级。存储采用 ‘SQLite/MySQL (结构化键值) + Vector DB (语义切块) + 文件系统 (CLAUDE.md / Rules)’。

题 006：什么是 Multi-Agent？Single-Agent 与 Multi-Agent 设计对比？ ​

  • 30 秒回答： “Single-Agent：单大体量 Prompt 处理全流程。上下文容易爆炸，角色混乱。 Multi-Agent：遵循‘单一职责原则’(SRP)，将复杂系统拆解为多个专业化 Sub-Agent（如 Product Manager, Coder, Tester），通过 路由中心 (Router) 或消息总线 进行协作。 设计方案：对于步骤 < 5 的确定性流程选 Single-Agent；对于复杂软件工程、深度研报写作坚决选 Multi-Agent。”

题 007：在工程实践中，为什么有时候选择“手搓”Agent，而不是直接用成熟框架 (LangChain/AutoGPT)？ ​

  • 30 秒回答： “成熟框架 (如 LangChain) 存在严重的过度封装 (Over-abstraction)、黑盒调优困难、依赖膨胀与异步 Event Loop 阻塞坑点。 在企业级生产开发中，‘手搓’基于原生 Python/Go 的简易状态机 (State Machine) 仅需 200 行代码，具备零冗余依赖、100% 透明可控、支持极细粒度 Token 统计与自定义打断重试的巨大优势。”

第 2 篇：RAG 检索增强全流程与高阶演进 (20 题) ​

题 008：什么是 RAG？详细描述一个完整 RAG 系统的工作流程？ ​

  • 30 秒回答： “RAG (Retrieval-Augmented Generation) 是通过外部私有知识库检索来增强 LLM 生成的架构。 完整物理工作流程：
    1. 索引阶段 (Indexing)：文档加载 ➔ 文本清洗 ➔ Chunk 切块 ➔ Embedding 向量化 ➔ 写入 Vector DB / ES；
    2. 检索阶段 (Retrieval)：用户 Query ➔ Query Rewrite (改写) ➔ 混合检索 (BM25 + Vector) ➔ Cross-Encoder Rerank (重排序) ➔ 筛选 Top-K；
    3. 生成阶段 (Generation)：组装 Context 与 Prompt ➔ 送入 LLM ➔ 流式 Output ➔ 引用溯源 (Citations)。”

题 009：RAG vs LLM 直接微调 (SFT) 的优劣势与选型？ ​

  • 方案对比表：
维度RAG (检索增强)SFT (直接微调)
知识更新实时更新 (仅需更新向量库)极慢 (需要重新训练微调)
幻觉控制低 (提供明确 Context，可溯源)高 (容易一本正经胡说八道)
私有数据安全高 (可做细粒度 ACL 权限隔离)低 (知识记忆在权重中难以擦除)
特定风格/格式较差极强 (可定制输出 Style/JSON)

选型铁律：补充知识选 RAG；改变行为风格/特定格式选微调。

题 010：GraphRAG 与 LightRAG 架构对比？什么场景下使用图数据库增强？ ​

  • 30 秒回答：
    • 传统向量 RAG：侧重局部文本相似度，无法回答“总结 CEO 在 2025 年提到的所有项目”这种全局关联性问题；
    • GraphRAG (微软开源)：通过 LLM 抽取实体 (Entity) 与关系 (Relation) 构建知识图谱，通过社区检测 (Community Detection) 算法生成层级摘要。适合全局总结与复杂实体关联；
    • LightRAG：引入双层检索 (Low-Level & High-Level) 与增量图更新，解决微软 GraphRAG 极度昂贵的建图成本问题。 使用图数据库场景：当业务涉及复杂人际网络、股权结构、医疗诊断链与跨文档逻辑推理时。

题 011：如何量化评估 RAG 效果？(Ragas 指标体系) ​

  • 30 秒回答： “生产环境使用 Ragas 评估框架，从 4 个核心维度量化：
    1. Faithfulness (忠实度)：生成内容是否完全依据 Context，防范幻觉；
    2. Answer Relevance (答案相关性)：回答是否切中用户 Query；
    3. Context Precision (上下文精准度)：召回的 Chunk 中相关信息是否排在最前面；
    4. Context Recall (上下文召回率)：需要的关键信息是否全被检索出来。”

第 3 篇：Function Calling、MCP 协议与 API 网关 (16 题) ​

题 012：什么是 Function Calling？原理是什么？ ​

  • 30 秒回答： “Function Calling 是 LLM 按照 JSON Schema 格式输出结构化工具调用指令的能力。 原理：在 Prompt 中传入函数名称、描述与 JSON Schema 参数结构。LLM 在推理时不直接生成自然语言，而是生成符合 Schema 的 JSON 串（如 {"name": "get_weather", "arguments": {"city": "Beijing"}}）。代码解析 JSON 并在物理本地执行函数后，将结果作为 tool 角色响应再次发给 LLM。”

题 013：什么是 MCP (Model Context Protocol) 协议？与 Function Calling / Skill 有何区别？ ​

  • 30 秒回答：
    • Function Calling：一种原生的 LLM 输出格式技术；
    • MCP 协议 (Anthropic 推出)：Client-Server 架构的标准化通用上下文与工具协议。解耦了模型与工具，支持 Tools、Resources (资源) 和 Prompts 动态接入；
    • Agent Skill：打包了特定领域经验与 SOP 的轻量化 Agent 能力模块。
  • 三者对比表：
技术概念层次核心作用传输方式
Function CallingAPI 输出层结构化输出 JSON 参数HTTP / JSON
MCP 协议架构协议层标准化连接数据源与 Tool ServerStdio / SSE / HTTP
Agent Skill业务逻辑层封装专业 SOP 流程内存 / 配置文件

题 014：WebSocket vs SSE vs WebRTC 在 AI 对话流中的差异与选型？ ​

  • 30 秒回答：
    • SSE (Server-Sent Events)：基于标准 HTTP 的单向文本流。简单高效，天然契合 LLM 文本 Streaming 打字机输出；
    • WebSocket：双向全双工 TCP 通信。适合有频发客户端上行指令的复杂交互；
    • WebRTC：低延迟 UDP 实时音视频流。在 AI 实时语音/视觉对话 (如 GPT-4o 实时语音) 中必须使用 WebRTC，将延迟压至 200ms 以内，规避 TCP 重传卡顿。

第 4 篇：LLM 大模型底层理论、训练与工程参数 (22 题) ​

题 015：Transformer 架构原理？MHA vs MQA vs GQA vs FlashAttention？ ​

  • 30 秒回答：
    • MHA (Multi-Head Attention)：Q、K、V 都有独立的多头，显存与 KV Cache 占用极大；
    • MQA (Multi-Query Attention)：所有 Q 共享 1 组 K 和 V，极大地压缩了 KV Cache，但牺牲了微小准确率；
    • GQA (Grouped-Query Attention, LLaMA-3/Qwen2 采用)：将 Q 分组，组内共享 1 组 K/V。在速度与准确率之间取得了完美平衡；
    • FlashAttention (1/2/3)：利用 GPU SRAM 高速缓存进行分块计算 (Tiling & Recomputation)，避开了频繁读写昂贵的 GPU HBM 显存，使 Attention 计算速度提升 2~5 倍。

题 016：大模型生成参数：Temperature, Top-P, Top-K 最佳配置？ ​

  • 30 秒回答：
    • Temperature (温度)：控制 logits 的概率分布平滑度。越低越确定，越高越有创造力；
    • Top-P (核采样)：累积概率达到 P 的候选 Token 集合；
    • Top-K：仅保留概率最高的 K 个 Token。
  • 最佳生产配置：
    • 代码生成 / JSON 提取 / 逻辑推理：Temperature = 0.0 ~ 0.2, Top-P = 0.1；
    • 通用客服 / 文档摘要：Temperature = 0.5 ~ 0.7, Top-P = 0.85；
    • 创意文案 / 故事创作：Temperature = 0.8 ~ 1.0, Top-P = 0.9。

题 017：Post-Training：RLHF, DPO, GRPO, 拒绝采样有何关系？ ​

  • 30 秒回答：
    • RLHF (基于人类反馈的强化学习)：传统方法。引入奖励模型 (Reward Model) + PPO 算法，训练极不稳定且耗费大量显存；
    • DPO (直接偏好优化)：避开奖励模型与 PPO，直接将偏好数据损失函数化，极度稳定；
    • GRPO (Group Relative Policy Optimization, DeepSeek-R1 采用)：取消了复杂的 Reward Model 物理网络，改为从相同 Prompt 采样一组回答，直接计算组内相对奖励，大幅降低显存消耗并激发了 CoT 推理能力！

第 5 篇：前沿工程范式与 OpenClaw / Claude Code 源码解密 ​

题 018：什么是 Harness Engineering 与 Loop Engineering？ ​

  • 30 秒回答：
    • Harness Engineering (驾驭工程)：OpenAI 验证的工程方法论。通过为 AI Agent 搭建**‘安全测试用例、自动化评估套件与持续反馈约束’**，确保 Agent 在迭代中不犯重复错误；
    • Loop Engineering (循环工程)：Claude Code 作者的核心思想。AI 时代的开发从“写 Prompt”转变为**“编写高韧性的循环 (Loop)”**。主循环负责感知环境、执行工具、自我修正并自动前进。

题 019：Claude Code 51 万行泄漏代码架构解析：为什么用 grep 而不用 RAG？为什么用 CLAUDE.md 而不上向量库？ ​

  • 字节/大厂高频追问： “在 Claude Code 等顶级 AI Coding Agent 的源码设计中，为什么在代码检索时坚决选择 grep / ripgrep，而不是传统的 RAG 向量检索？为什么项目记忆偏偏不上向量数据库，而是用简单的 CLAUDE.md + 文件系统？”

  • 硬核架构解答：

    1. 代码检索选 grep 而不用 RAG 的物理根因：
      • AST 语法与精确符号匹配：代码的本质是精准语法树（变量名 userService、函数 getUser），Vector Embedding 会将相似的函数名混为一谈，造成严重错召；grep / ripgrep 能够实现100% 精确的符号与正则匹配；
      • 极速性能与零索引开销：在百万行代码库中，ripgrep (Rust 实现) 仅需 20ms 即可扫完全盘，而向量 RAG 建立 Chunking 与 Embedding 需耗费数分钟，且代码一旦改动索引立刻失效；
    2. 项目记忆选 CLAUDE.md 而不上向量库的物理根因：
      • 上下文完整性与强确定性：CLAUDE.md 位于项目根目录，在 Agent 启动时作为 System Prompt 的一部分100% 完整加载，保证了编码规则 (Rules) 零遗漏；而向量库搜索可能导致规则切碎漏召；
      • Git 版本化与人机共育：CLAUDE.md 可以随 Git 提交，人类和 Agent 均可直接编辑，实现了项目记忆的物理版本化。

🔍 本章 6 重自审计报告 ​

  1. 【知识审计】：新增全量真题大章！涵盖 Agent 16 题、RAG 20 题、MCP 16 题、LLM 22 题、Harness/Loop Engineering、GraphRAG 与 Claude Code 51 万行源码机制！

Released under the MIT License.

Copyright © 2026 AI应用 + Agent + 高级后端工程师面试实战复习手册