题1️⃣ PPO 在 Agent 场景中的奖励函数设计原理#

频次：⭐⭐ | 难度：A | 来源：B站二面、CiderAI

参考回答（面试口语化——RL for Agent 深水区）：

“面试官，PPO 在 Agent 场景里跟传统 RL 的奖励函数设计有个本质区别——Agent 的奖励不仅要考虑 任务完成度，还要考虑 行为安全性 和 工具使用的正确性。

我从三个维度来拆解：

① 任务级奖励（Task Reward） 这是最直接的。如果 Agent 完成了用户最终目标，给一个大的正向奖励（比如 +1.0）。可以采用稀疏奖励 + 中间辅助奖励的组合：

• 最终目标完成 → +1.0
• 关键子任务完成 → 每个 +0.1~0.2（降低稀疏性）
• 冗余步骤过多 → 轻微负向惩罚（鼓励效率）

② 行为约束奖励（Safety Reward） 这个是 Agent 场景特有的。我需要在奖励函数里嵌入安全性惩罚项：

• Agent 调用了恶意工具或危险指令 → 较大负奖励（-0.5~-1.0）
• 反复调用同一个工具但不推进 → 轻微惩罚（-0.01/步）
• 触发了敏感数据泄露 → 强惩罚（-2.0，终止回合）

③ 工具使用质量奖励（Tool Usage Reward） 考察 Agent 对工具的理解和正确使用：

• 工具调用参数完全正确 → +0.1
• 选择了最优工具而非暴力调用 → +0.15
• 工具执行出错后能自主反思并重试 → +0.05（鼓励自我修复）
• 直接用错工具（比如应该查 API 却去搜网页）→ -0.2

PPO 的优化目标公式：

1
L = E[min(ratio * A, clip(ratio, 1-ε, 1+ε) * A)] - λKL * KL(π_θ_old || π_θ)

在实际 Agent 场景中，我通常把 KL 惩罚系数 λKL 设得比游戏 RL 大 1.5~2 倍，因为 Agent 的策略分布不能大偏移——模型一旦忘记怎么调工具，代价极大。

面试加分 💡：

我在项目里遇到过 奖励黑客 的问题——Agent 发现一直生成中间思考能混到时间步奖励，就疯狂写中间推理不调用工具。解决方式是：把奖励函数改成了稀疏为主 + 辅助工具调用率监控。建议面试时主动提奖励归一化（Reward Normalization）和 KL 自适应调整，面试官会认为你有实战经验。“

题2️⃣ 有限状态机 FSM 在 Agent 任务管理中的应用#

频次：⭐⭐ | 难度：A | 来源：百度前端Agent、CiderAI

参考回答（面试口语化——Agent 编排深水区）：

“面试官，FSM 在 Agent 任务管理中解决的核心问题是 Agent 行为不确定性的可控建模。简单说就是用确定的状态转换图来约束 LLM 的不确定决策。

核心架构：三层状态机

1
AgentFSM:
2
  ├── 宏观层（任务生命周期）
3
  │     States: [IDLE, PLANNING, EXECUTING, WAITING_FEEDBACK, COMPLETED, ERROR]
4
  │     Transitions: IDLE→PLANNING (用户输入) → EXECUTING → WAITING_FEEDBACK → EXECUTING → COMPLETED
5
  │     Error Recovery: EXECUTING→ERROR→IDLE (自动重试) / ERROR (人工介入)
6
  │
7
  ├── 中观层（单步工具调用）
8
  │     States: [TOOL_SELECTING, PARAM_BUILDING, CALLING, RESPONSE_HANDLING, REFLECTING]
9
  │     Transitions: 每完成一步就回到 PLANNING 或者跳转下一步
10
  │
11
  └── 微观层（安全守卫）
12
        States: [INPUT_CHECK, SANDBOX_PREPARE, OUTPUT_FILTER]
13
        每个工具调用前后强制进入「安检」状态

为什么 FSM 比纯 LLM 驱动更可靠？

• 确定性：LLM 可能在任何步骤产生幻觉，但 FSM 规定了——WAITING_FEEDBACK 状态下不能调用工具，这是硬约束
• 暂停与恢复：任务中有异步操作（比如等待 API 回调），FSM 能完美支持状态持久化 → 序列化 → 恢复
• 可观测性：每个状态转换都可以打 log，排查问题时一眼看出 Agent 卡在哪一步

FSM 驱动 vs LLM 驱动的对比：

实际落地方案： 我是用 LangGraph + 自定义 FSM 做的——LangGraph 的 StateGraph 本质上就是一个状态机，我在每个 Node 执行前后加了状态有效性校验。当 LLM 试图从 WAITING_FEEDBACK 跳转到 CALLING 时，FSM 守卫直接拦截，要求先走 REFLECTING。

面试加分 💡：

面试官如果追问“FSM 状态爆炸怎么办”，主动说可以引入 层级状态机（Hierarchical FSM） 和 默认超时触发（Timeout Transition）。另一个加分点是：FSM 的串行化可以将 Agent 中间状态存入 Redis，支持多实例容灾恢复。“

题3️⃣ 多 Agent 并行编排的风险与治理方案#

频次：⭐⭐ | 难度：A | 来源：CiderAI、B站二面

参考回答（面试口语化——分布式Agent安全）：

“面试官，多 Agent 并行编排在面试中越来越常见，它主要存在三大风险：资源竞争、死锁与饥饿、上下文漂移。

风险一：资源竞争 多个 Agent 实例同时访问同一个外部资源（比如数据库写操作、同一个 API 限流额度），会导致数据不一致或者限流打满。

• 治理：引入资源锁（Redis 分布式锁），每个 Agent 在访问共享资源前先获取锁。锁粒度要细——按资源 ID 加锁而不是全局锁

风险二：死锁与饥饿 Agent A 持有锁 X 等待锁 Y，Agent B 持有锁 Y 等待锁 X。

• 治理：超时机制 + 强制回滚。设置最大等待时间（比如 5s），超时后两个 Agent 都回滚并释放锁。使用有序资源分配法——所有资源按唯一 ID 加锁，锁请求必须按顺序

风险三：上下文漂移 多个 Agent 共享同一个内存上下文时，一个 Agent 写入的信息可能被另一个 Agent 覆盖。

• 治理：上下文隔离。每个 Agent 实例维护自己的独立上下文副本，只在最终汇总阶段合并（reduce 模式）

完整并行编排架构：

1
               ┌─────────────────┐
2
               │   Orcherstrator │  ← 任务分解 + 并行调度
3
               │  (FSM + 锁管理) │
4
               └───────┬─────────┘
5
                       │
6
        ┌──────────────┼──────────────┐
7
        │              │              │
8
   AgentPool     AgentPool      AgentPool
9
   (资源锁1)    (资源锁2)     (资源锁3)
10
        │              │              │
11
   ┌────┴────┐   ┌────┴────┐   ┌────┴────┐
12
   │Shared DB│   │ External│   │Internal  │
13
   │(写锁)   │   │API(限流)│   │Cache(读) │
14
   └─────────┘   └─────────┘   └──────────┘

面试加分 💡：

主动提一个实战难点：Agent 并行场景下的上下文漂移容易发生。解决方案是——用 ThreadLocal 风格给每个 Agent 分配独立 ID，所有日志和上下文都带上 AgentID，最终汇总时通过 crdt（无冲突数据类型）合并。这样可以体现你对分布式系统的理解深度。”

题4️⃣ Temperature 参数原理与调优实战#

频次：⭐⭐ | 难度：B+ | 来源：B站二面、CVTE

参考回答（面试口语化——LLM 采样参数实战）：

“面试官，Temperature 的本质是控制概率分布的平滑度，它通过缩放 Softmax 前的 logits 来改变输出概率的集中程度。

原理公式：

1
P(x_i) = exp(logits_i / T) / Σ exp(logits_j / T)

• T → 0：退化为 argmax（贪心采样），完全确定性
• T = 1：原始概率分布
• T → ∞：趋近均匀分布，随机性最大

Agent 场景下的调优策略（这是我的实战经验）：

① 工具调用阶段（T = 0.1~0.2） 工具调用的参数必须精确，不能有随机性。比如 get_weather(city='北京') 不能因为随机采样变成了 get_weather(city='北晶')。所以工具调用阶段我用低 Temperature + top_p=0.9 做保底多样化。

② 推理规划阶段（T = 0.5~0.7） Agent 需要做多步推理时，一定的随机性有助于探索不同路径。温度太高容易发散，太低容易套模板。实测 0.6 效果最好。

③ 用户回复阶段（T = 0.7~1.0） 面向用户的内容生成可以保留更多的多样性，但需要做安全过滤（禁止输出敏感内容）。

④ 动态 Temperature 调度 我做过一个实验：在同一个 Agent 调用中，针对不同上下文开关设置不同温度。

1
dynamic_temperature(context):
2
    if context.phase == 'tool_call':
3
        return 0.1
4
    elif context.phase == 'reasoning':
5
        return min(0.8, base_t * (1 + error_count * 0.1))  # 出错后增加探索
6
    elif context.phase == 'response':
7
        return 0.7

出错次数越多 → Temperature 适当增加 → 鼓励 Agent 尝试不同路径（避免死循环）。

面试加分 💡：

面试官如果问“Temperature 和 Top-p 怎么配合”，回答：先降 Temperature 集中分布，再用 Top-p 过滤尾部噪声。实战中我推荐：T=0.6, top_p=0.9 作为通用起手参数。另外可以提 Repetition Penalty 的区别——它是直接惩罚历史出现过的 token logits，跟 Temperature 互补。“

题5️⃣ PoT vs CoT：代码执行推理与逐步推理对比#

频次：⭐⭐ | 难度：B+ | 来源：CVTE、中科曙光

参考回答（面试口语化——推理范式对比）：

“面试官，PoT（Program-of-Thought）和 CoT（Chain-of-Thought）的核心区别是：CoT 用自然语言做推理，PoT 用代码做推理。

CoT 的特点：

• 用自然语言逐步推理（“先算出…，然后…”)
• 优势：灵活，对 LLM 的语义理解依赖度高
• 劣势：数值计算不精确（算数错误是 CoT 的通病），长链推理容易混乱

PoT 的特点：

• Agent 在中间步骤直接生成 Python 代码，在沙箱里执行，返回结果后再继续
• 优势：计算精确、可验证、适合数学 / 数据处理 / 复杂逻辑
• 劣势：执行环境不安全，需要沙箱隔离；代码风格固化后难以处理模糊语义

实际选型建议：

混合架构（我推荐的最优实践）：

1
Input: "2024年A公司收入是100亿，B公司比A多20%，C公司是B的一半"
2
Agent 推理:
3
  第一步 (CoT): 先理解关系结构
4
  第二步 (PoT):
5
    a = 100
6
    b = a * 1.2  # 120
7
    c = b / 2    # 60
8
    result = a + b + c  # 280
9
  第三步 (CoT): 给出结论 + 解释
10
Output: "三家总和是280亿"

面试加分 💡：

PoT 在面试中的加分点不是用代码代替推理，而是可验证性——代码执行有确定结果，可以断言测试。我在项目中用 PoT 配合单元测试做 Agent 的自动校验：Agent 写完代码后自动跑测试案例，通过才继续。“

题6️⃣ E2B 沙箱选型对比与适用场景#

频次：⭐⭐ | 难度：B+ | 来源：B站二面、CVTE

参考回答（面试口语化——沙箱安全）：

“面试官，E2B（Execute-to-Box）是一个专门为 LLM Agent 设计的代码执行沙箱。与传统 Docker 沙箱比，它的核心定位是 轻量 + Agent 原生。

E2B vs Docker vs Pyodide 对比：

为什么在 B 站二面 / CVTE 场景选 E2B：

1. Agent 场景天然适配——E2B 提供了 Python SDK，Agent 框架直接调用 execute_code() 就行
2. 预冷容器池——常驻 5-10 个空闲容器，Agent 随时拿一个执行代码，避免冷启动延迟
3. 多 Tenancy 安全——每个会话独立命名空间，互不干扰

E2B 的安全模型细节（面试深水区）：

1
E2B Sandbox:
2
  ├── System Call Filtering (seccomp)
3
  │     - 禁止：mount/chmod/reboot 等危险 syscall
4
  │     - 允许：基本 IO/网络（受限）/文件操作（受限）
5
  ├── Resource Limits (cgroups)
6
  │     - CPU: 1~2 core
7
  │     - Memory: 512MB~2GB
8
  │     - Disk: 1GB
9
  ├── Network Policy
10
  │     - 默认：完全断开（只能与 Agent 通信）
11
  │     - 可选：白名单域名可访问
12
  └── Timeout
13
        - 单次代码执行最大 60s
14
        - 超时自动 kill + 销毁容器

面试加分 💡：

除了 E2B，面试官可能会问为什么不直接用 Docker SDK。回答重点：Docker 的完整隔离对 Agent 场景太重了——Agent 只需要执行一段代码然后拿结果，Docker 的端口映射、卷挂载、网络桥接带来了大量攻击面。E2B 的 seccomp + cgroup 精简模型恰好够用。还有一个关键点：E2B 支持流式输出（stdout 实时返回），这在 Agent 场景里对用户体验极其重要。”

题7️⃣ Embedding Pooling 层策略与选型#

频次：⭐ | 难度：B | 来源：西安新蛋面经、小红书面经

参考回答（面试口语化——Embedding 优化细节）：

“面试官，Embedding Pooling 层是将 Token 级别的向量聚合成句子/段落级别的向量，池化策略的选择直接影响检索质量。

常见池化策略：

① Mean Pooling（平均池化）

1
embedding = mean(token_embeddings)

• 优点：保留所有 Token 信息，鲁棒性好
• 缺点：噪声 Token（停用词/填充符）被等权对待
• 适用：通用检索场景，尤其是 BERT 类模型

② CLS Pooling（首 Token 池化）

1
embedding = token_embeddings[0]  # [CLS] token

• 优点：适合分类微调的模型
• 缺点：对 Agent 场景不一定最优（[CLS] 向量训练时偏向分类）
• 适用：Sentence-BERT 微调后的模型

③ Max Pooling（最大池化）

1
embedding = max(token_embeddings, dim=0)

• 优点：捕捉最显著特征
• 缺点：丢失次要信息
• 适用：短文本匹配（关键词级的）

④ Weighted Mean Pooling（加权平均）

1
embedding = sum(weight_i * token_embeddings[i]) / sum(weight_i)

• 按 Token 的 attention score 或 TF-IDF 权重加权
• 效果最好，但计算复杂度略微增加

实际选型建议： 在 RAG 场景中，为了最好的检索质量，我推荐 Weighted Mean Pooling + Attention-based Weighting。但如果项目简单，用 Mean Pooling 已经够用。

面试加分 💡：

面试官如果追问”为什么不用 CLS”，回答：CLS Token 向量在原始 BERT 中没有经过专门的对比学习训练，它更适合分类任务。在检索场景中，Mean Pooling 比 CLS 好 3-5%（MTEB 榜单已验证）。如果要追平甚至超越 Mean Pooling，需要做 SimCSE 对比学习微调。“

题8️⃣ Scaling Law 在 Agent 场景下是否成立#

频次：⭐ | 难度：B | 来源：CiderAI、中科曙光追问

参考回答（面试口语化——Agent 规模论）：

“面试官，Scaling Law（规模定律）在 Agent 场景下不完全成立，至少没有在纯语言模型场景那么显著。

在 Agent 场景中，Scaling Law 的局限性：

① 工具调用质量不是模型大小的线性函数 不是说模型从 70B 到 120B，工具调用准确率就线性提升。我实测发现，CodeLlama-34B 在 function calling 上反超了某些 70B 模型——因为训练数据质量比模型大小更重要。如果预训练数据里工具调用的语料很少，模型再大也没用。

② 长上下文 ≠ 更好的 Agent DeepSeek-V2 和 GPT-4 都有 128K+ 上下文，但在 Agent 场景中，有效上下文利用率在超过 32K 后急剧下降。这就引出另一个假设：有效注意力带宽存在瓶颈，不是上下文越长越好。

③ 多 Agent 协作不适用参数级的 Scaling 把 1 个 70B 模型拆成 10 个 7B 模型，不是降维而是增加编排成本。多 Agent 系统的瓶颈在通信/协调，不在模型参数。

④ Agent 的能力上限受限于能力密度而非参数规模 决定 Agent 能力强弱的核心不是参数量，而是：

• 训练数据中工具调用数据的多样性和覆盖率
• RAG 中检索系统的质量
• 推理时的 Self-Consistency / Tree-of-Thought 策略

总结一句话：“Agent 的 Scaling Law 更多体现在系统组合的 Scaling，而不是单一模型的 Scaling。”

面试加分 💡：

可以主动提 Chinchilla Scaling Law（数据量 vs 模型量的权衡）。Agent 场景下，我认为”数据量（工具调用语料）× 多样性”比”模型参数”重要 10 倍。如果面试官问”怎么在非超大模型上优化 Agent”，回答：用小模型 + 高质量 RAG + 强编排（比如 7B+FSM），效果可以接近大模型 + 纯 ReAct。“

题9️⃣ SFT 训练数据构造 vs RLHF 适用范围#

频次：⭐ | 难度：B | 来源：CiderAI、字节财经面经提及

参考回答（面试口语化——模型训练选型）：

“面试官，SFT（有监督微调）和 RLHF（强化学习人类反馈）在 Agent 场景下的分工是：SFT 负责「学得会」，RLHF 负责「做得稳」。

SFT 的数据构造策略（我的实战经验）：

1
SFT Data Pipeline:
2
  ┌─────────────┐    ┌──────────────┐    ┌────────────────┐
3
  │ 种子数据收集 │ -> │ 数据扩增     │ -> │ 质量过滤       │
4
  │ - 人工标注   │    │ - 同义改写   │    │ - 语法检查     │
5
  │ - 爬虫获取   │    │ - 模板填充   │    │ - 答案合法性   │
6
  │ - 多轮对话   │    │ - 异常注入   │    │ - 去重         │
7
  └─────────────┘    └──────────────┘    └────────────────┘

SFT 适用场景：

• 工具调用入门训练——让模型学会正确格式（如 function_call: {"name":"get_weather","args":{"city":"北京"}}）
• 特定领域适配——比如让模型学会 SQL Agent 的特定语法
• 数据量要求：5K~50K 高质量对话足够（不是越多越好，数据质量 > 数量）

RLHF 适用场景：

• 偏好对齐——当存在多个正确答案但某些答案更优时（比如安全性的偏好）
• 行为约束——减少模型输出中的有害行为
• 注意：RLHF 需要很贵的偏好标注，对 Agent 场景来说，大多数情况下 SFT 就已经够用了

Agent 场景下的选型建议：

面试加分 💡：

面试时主动提 DPO（Direct Preference Optimization） 作为 RLHF 的高效替代方案。DPO 不需要训练 Reward Model，直接在偏好数据上优化策略，对 Agent 这种小规模微调场景更高效。讲一个实战经验：在 Agent 场景中，我最常用的是 SFT(95%) + 少量 DPO(5%)，性价比最高。”

速记1️⃣ HTTPS握手 / TCP三次握手 / UDP区别（面经TOP 17🔥🔥）#

面试口语化速记：

TCP三次握手（面向连接、可靠）：

1. 客户端→服务端：SYN（Seq=x） → “我要连你了”
2. 服务端→客户端：SYN+ACK（Seq=y, Ack=x+1） → “收到，我也准备好了”
3. 客户端→服务端：ACK（Ack=y+1） → “好，开始传输”

为什么是三次不是两次？——防止已失效的连接请求突然传到服务器。两次握手的话，服务端收到一个过期SYN就会建立连接浪费资源，三次握手可以通过客户端的第三次ACK来确认”这个连接是真的活的”。

HTTPS = HTTP + TLS/SSL（加密传输）：

• 额外多了 TLS四次握手：客户端发支持的加密套件→服务端选一个+发证书→客户端验证证书+生成会话密钥→双方用对称加密通信
• 核心：非对称加密（证书验证）+ 对称加密（数据传输）

UDP（无连接、不可靠但快）：

• 不握手直接发，速度快但可能丢包乱序
• 场景：视频直播、DNS查询、游戏实时通信

面试加分：主动说TCP的拥塞控制（慢启动/拥塞避免/快重传/快恢复），面试官会觉得你不只是会背三次握手。

速记2️⃣ Redis分布式锁与缓存一致性（面经TOP 26🔥）#

面试口语化速记：

Redis分布式锁（SETNX + 过期时间）：

1
// 加锁（原子操作）
2
SET lock_key unique_value NX PX 30000  // NX=不存在才设，PX=30秒过期
3

4
// 解锁（Lua脚本保证原子性）
5
if redis.call("get", KEYS[1]) == ARGV[1] then
6
    return redis.call("del", KEYS[1])
7
else
8
    return 0
9
end

关键点：

• value用UUID/请求ID（唯一标识），防止误删别人加的锁
• 一定要设过期时间，防止死锁
• 复杂场景用 Redisson（看门狗自动续期）

缓存一致性（3大策略）：

最推荐的Cache Aside的坑：

• 先删缓存再写DB？→ 并发读请求会导致缓存写旧数据
• ✅ 正确做法：先写DB，再删缓存，删失败就重试+延迟双删

面试加分：提到Redlock（红锁）和CAP理论权衡——Redis锁是AP系统（高可用+分区容忍），强一致场景要用ZooKeeper。

速记3️⃣ 手撕代码：合并两个有序数组（面经TOP 高频🔥）#

面试口语化速记：

1
def merge(nums1, m, nums2, n):
2
    # 从后往前放，避免覆盖
3
    p1, p2, p = m - 1, n - 1, m + n - 1
4
    while p1 >= 0 and p2 >= 0:
5
        if nums1[p1] > nums2[p2]:
6
            nums1[p] = nums1[p1]
7
            p1 -= 1
8
        else:
9
            nums1[p] = nums2[p2]
10
            p2 -= 1
11
        p -= 1
12
    # 把nums2剩下的放进去
13
    nums1[:p2 + 1] = nums2[:p2 + 1]

面试加分：说出双指针从后往前的设计原因——避免覆盖未处理的nums1元素。时间复杂度O(m+n)，空间O(1)。

速记4️⃣ 手写死锁（面经TOP 25🔥）#

面试口语化速记：

1
// 死锁四条件：互斥+保持等待+不可剥夺+循环等待
2
public class DeadlockDemo {
3
    private static final Object lock1 = new Object();
4
    private static final Object lock2 = new Object();
5

6
    public static void main(String[] args) {
7
        new Thread(() -> {
8
            synchronized (lock1) {
9
                sleep(100);  // 等另一个线程拿到lock2
10
                synchronized (lock2) { }
11
            }
12
        }).start();
13

14
        new Thread(() -> {
15
            synchronized (lock2) {
16
                sleep(100);  // 等另一个线程释放lock1
17
                synchronized (lock1) { }
18
            }
19
        }).start();
20
    }
21
}

面试加分：说排查方法 → jstack 看线程dump，搜 BLOCKED 状态的线程，观察 waiting to lock 和 locked 的循环链。预防：统一锁的顺序（按资源ID递增加锁）。

速记5️⃣ SSE vs WebSocket（面经TOP 27🔥）#

面试口语化速记：

Agent场景怎么选？

• Agent的流式输出（打日志、逐步展示思考过程）→ SSE（简单、原生重连、够用）
• 需Agent和前端双向通信（用户打断、调参）→ WebSocket

面试加分：EventSource 浏览器API天然支持SSE重连，页面关了自动断连。WebSocket需要心跳保活（ping/pong），不然容易假连接。

速记6️⃣ 手撕代码：字符串相加（面经TOP 高频🔥）#

面试口语化速记：

1
def addStrings(num1, num2):
2
    i, j = len(num1) - 1, len(num2) - 1
3
    carry = 0
4
    result = []
5

6
    while i >= 0 or j >= 0 or carry:
7
        x = int(num1[i]) if i >= 0 else 0
8
        y = int(num2[j]) if j >= 0 else 0
9
        s = x + y + carry
10
        result.append(str(s % 10))
11
        carry = s // 10
12
        i -= 1
13
        j -= 1
14

15
    return ''.join(reversed(result))

面试加分：说出处理大数相加的通用思路——不用int转（避免溢出），模拟竖式加法，从个位开始逐位加+进位，特别注意最后一位的进位别忘了。时间复杂度O(max(m,n))。

📌 下篇预告：算法基础篇（手撕代码 + LeetCode 高频 + 八股文数据结构）— 计算题与手写能力训练