千问 C 端 Agent 算法日常实习一面面试题与参考解答

本调研定位：把图片中流传的「千问 C 端 Agent 算法日常实习一面」题单整理成可复用的面试答案。题目表面上问 Agent、Memory、RAG、ReAct、后训练，实际重点是：候选人能不能把论文 / 项目里的方法落成一个可评测、可迭代、可上线的 C 端 Agent 系统。

一、题面还原

这轮一面大致包含 9 类问题：

1. 自我介绍
2. 介绍论文和项目，面试官拷打细节
3. Agent 记忆模块怎么设计：如何保证提取效果，如何做检索、更新
4. BM25 和向量检索的原理
5. 记忆库很大时，怎么保证检索效率
6. 讲讲 ReAct loop，什么时候用 ReAct，什么时候用 Workflow
7. 是否了解 harness engineering，聊聊看法
8. Agent 怎么做自进化
9. 会前端吗？会不会后训练？

这套题不像传统「算法岗」只考模型推导或 LeetCode。它更像 Agent 算法工程岗：既要懂检索、记忆、评测、后训练，也要能把产品链路说清楚。

二、面试官真正想看什么

三、逐题参考解答

Q1. 自我介绍

30 秒口播版：

我主要做大模型应用和 Agent 方向，重点关注 RAG、Memory、Tool Calling 和 Agent 评测。过去的项目里，我做过从用户意图识别、知识检索、工具调用到结果评估的完整链路。相比只调 prompt，我更关注 Agent 系统怎么可控、可评测、可迭代，比如记忆如何抽取和更新、检索怎么保证召回与延迟平衡、失败 case 怎么沉淀成数据。

展开版结构：

• 背景：一句话说明自己和岗位的匹配点，例如「大模型应用 / RAG / Agent 项目」
• 项目：挑 1 个最相关项目，不要堆很多项目名
• 技术点：突出 Memory、检索、工具调用、评测、后训练中的 2-3 个
• 结果：给指标，例如召回率、答案采纳率、延迟、bad case 降低比例
• 反思：说明还有哪些未解决问题，例如长程记忆冲突、工具调用幻觉、线上评测难

雷区：

• 自我介绍只背简历，没有和 C 端 Agent 对齐
• 说「我熟悉 LangChain / Dify / Coze」但讲不出底层状态、检索、评测
• 项目没有指标，只有「效果还不错」

Q2. 介绍论文和项目，拷打细节

回答主线：

我会按「问题定义 → 方法选择 → 系统实现 → 实验指标 → bad case → 改进方向」讲。论文部分重点讲它解决什么瓶颈、核心假设是什么、实验是否充分；项目部分重点讲我负责的模块、数据怎么来、效果怎么验证、线上失败如何定位。

项目口播模板：

这个项目的目标是让 Agent 在多轮对话中记住用户偏好并完成任务。链路上先做意图识别，然后从短期会话记忆和长期用户记忆中检索相关信息，再让 Planner 决定是否调用工具，最后由 Answer Generator 汇总输出。我的重点工作是 Memory 模块：抽取用户偏好、事实、任务状态，写入结构化库和向量库，并在每轮对话前做混合检索。

面试官会追问的细节：

• 数据从哪里来：真实用户日志、标注数据、合成对话、公开 benchmark
• 指标是什么：记忆抽取准确率、检索 recall@k、答案 groundedness、任务完成率、平均延迟
• 有哪些 bad case：记忆过期、相似用户偏好冲突、模型把临时上下文写成长期偏好
• 怎么改：加写入门控、记忆分级、时间衰减、冲突检测、人工审核样本

加分说法：

Agent 项目不能只用最终答案满意度评估，因为最终答案错了可能是意图错、检索错、工具错、生成错。最好把链路拆成节点级评测：Memory extraction、retrieval、tool selection、final answer 分别打分。

Q3. Agent 记忆模块怎么设计

短答版：

我会把 Memory 分成短期记忆、长期用户画像、任务记忆和反思记忆四类。写入时先由抽取器从对话中提取候选记忆，再经过重要性、稳定性、隐私和冲突校验；存储时结构化字段和向量表示双写；读取时用 BM25 + 向量检索 + 时间/场景过滤 + rerank；更新时做版本管理、时间衰减和冲突合并。

推荐架构：

如何保证提取效果：

1. 抽取 schema 固定：不要让模型自由写。示例字段：memory_type、subject、predicate、object、confidence、source_turn_id、expire_at、privacy_level。
2. 写入门控：只有「稳定、可复用、用户授权、非敏感或已脱敏」的信息才写长期记忆。
3. 模型 + 规则双校验：模型负责语义抽取，规则负责过滤手机号、身份证、银行卡、一次性上下文。
4. 离线评测：人工标注一批对话，看 extraction precision / recall / F1。
5. 线上抽检：按记忆类型采样，检查误写入、漏写入、过期未删。

检索怎么做：

• 先做过滤：用户 ID、会话域、时间窗口、权限
• 再做混合召回：BM25 召回关键词强匹配，向量召回语义相关记忆
• 再做 rerank：按相关性、时间新鲜度、置信度、使用频次综合排序
• 最后做上下文压缩：只把 top 3-8 条高置信记忆放进 prompt

更新怎么做：

• 同一事实重复出现：提高置信度，不重复写
• 新事实与旧事实冲突：保留版本，按时间和显式程度决定当前生效项
• 过期信息：TTL 或时间衰减，例如「最近在学 Rust」不能永久当稳定偏好
• 用户纠正：最高优先级，直接覆盖并记录 correction

一句能打动面试官的话：

Memory 不是把聊天记录全塞进向量库，而是一个有写入门控、冲突处理、时间衰减和隐私边界的用户状态系统。

Q4. BM25 和向量检索的原理

BM25 短答：

BM25 是稀疏词项匹配方法，核心看 query 词在文档中的词频、在全库中的稀有程度，以及文档长度归一化。词越稀有、在文档中出现越合理，分数越高；但出现次数会饱和，不会无限加分。

BM25 核心直觉：

• TF：词在文档里出现越多越相关，但收益递减
• IDF：越少见的词越有区分度
• Length normalization：长文天然词多，需要做长度惩罚

向量检索短答：

向量检索先用 embedding 模型把 query 和文档映射到同一语义空间，再用余弦相似度、内积或 L2 距离找最近邻。它能召回同义改写和语义相关内容，但对精确数字、代码、专有名词、否定词有时不如 BM25 稳。

两者对比：

推荐答案：

实际系统里我一般不用单一路线，而是 hybrid retrieval：BM25 和向量各召回一批，再用 RRF 或学习排序融合，最后用 cross-encoder / LLM rerank 精排。

Q5. 记忆库很大时怎么保证检索效率

短答版：

大库检索不能全量扫。第一层用元数据过滤缩小候选集，第二层用倒排索引和 ANN 各自召回，第三层 rerank 小候选集。再配合分层记忆、冷热分层、缓存、增量索引和异步更新，把延迟控制在可接受范围。

具体做法：

1. 元数据预过滤：按 user_id、场景、语言、权限、时间窗口过滤，先把百万级降到千级。
2. 分层记忆：近期会话走 Redis / KV，长期记忆走向量库，归档记忆走冷库。
3. ANN 索引：HNSW、IVF、PQ 等近似最近邻索引，牺牲极小精度换取延迟。
4. 混合召回限制 topK：BM25 top 50 + 向量 top 50，然后融合成 top 20。
5. Rerank 只排小集合：不要让 cross-encoder 或 LLM 看几百条。
6. 缓存：高频 query、用户稳定画像、最近会话摘要都可以缓存。
7. 增量更新：新记忆先写实时小索引，定期 merge 到主索引。
8. 摘要压缩：把低频历史对话压成 summary memory，减少碎片。

可以给出的延迟预算：

关键判断：

C 端 Agent 的记忆检索要先保体验，再保召回。用户对 100ms 级检索无感，但对多等 2 秒很敏感，所以大模型 rerank 必须克制使用。

Q6. ReAct loop 是什么，什么时候用 ReAct，什么时候用 Workflow

ReAct 短答：

ReAct 是 Reason + Act 的循环：模型先思考下一步需要什么信息或操作，再调用工具，拿到 observation 后继续推理，直到得到答案。它适合开放任务和信息不完整的探索任务。

典型 loop：

User task
  -> Thought: 现在缺什么信息
  -> Action: 调用搜索 / 计算 / 数据库 / API
  -> Observation: 工具返回结果
  -> Thought: 是否足够，下一步做什么
  -> Final Answer

什么时候用 ReAct：

• 用户目标开放，路径不确定
• 需要多步搜索、比较、排错
• 工具选择依赖中间结果
• 允许一定探索成本

什么时候用 Workflow：

• 流程确定，例如下单、退款、导出报告、创建日程
• 强合规、强安全、强 SLA
• 每一步都有明确输入输出和失败分支
• 需要可审计、可回放、可测试

面试推荐说法：

我不会把整个 C 端 Agent 都做成 ReAct。更稳的方式是外层 Workflow 控制边界，内部某些开放节点用 ReAct。例如「旅行规划」可以用 ReAct 搜索和比较信息，但「提交订单」必须走确定性 Workflow。

防死循环措施：

• 最大步数上限，例如 8-12 步
• 同工具同参数去重
• 工具失败次数上限
• 预算上限：token、时间、费用
• Critic 判断是否已经足够回答

Q7. 了解 harness engineering 吗

可接受回答：

我理解的 harness engineering 是给大模型 / Agent 搭一套可复现的测试、评测和调试框架。它不只是写 prompt，而是把任务数据、工具 mock、环境状态、期望行为、评分器、日志回放都组织起来，让每次改 prompt、模型、检索策略或工具 schema 后，都能知道效果是变好了还是变坏了。

为什么 Agent 更需要 harness：

• Agent 输出不稳定，同一个任务可能走不同工具路径
• 多节点错误会传递，最终答案错了不容易定位
• 线上 C 端场景不能靠感觉改 prompt
• 每次模型升级都可能引入回归

一个 Agent harness 应该包含：

加分表达：

Harness 的价值是把 Agent 从「玄学调 prompt」变成「工程上可回归」。没有 harness，自进化和后训练都没有可靠反馈信号。

Q8. Agent 怎么做自进化

短答版：

Agent 自进化不是让它上线后随便改自己，而是建立数据闭环：收集失败轨迹，自动归因，生成改进样本，离线评测通过后再更新 prompt、工具策略、记忆规则或模型。核心是有边界、有评测、有回滚。

闭环流程：

1. 记录轨迹：保存用户问题、检索结果、工具调用、模型输出、用户反馈。
2. 发现 bad case：低评分、用户追问、人工接管、工具失败、任务未完成。
3. 归因分类：意图识别错、记忆错、召回错、工具选错、生成幻觉、权限问题。
4. 生成改进项：
   • Prompt 更新
   • Tool schema 调整
   • Memory 写入规则调整
   • RAG 召回 / rerank 调参
   • SFT / DPO 训练样本
5. 离线评测：跑 regression harness。
6. 灰度上线：小流量 A/B，监控成功率、投诉率、延迟、成本。
7. 回滚机制：指标变差立即回滚。

自进化的边界：

• 不能让 Agent 直接改生产 prompt 并全量生效
• 不能自动扩大工具权限
• 不能把未经确认的用户隐私写入长期记忆
• 不能用低质量反馈直接训练模型

推荐表述：

我更愿意把它叫「受控自进化」。Agent 可以自动发现问题、生成候选改进，但真正上线要经过评测、灰度和回滚。

Q9. 会前端吗？会不会后训练？

前端回答：

我能做基础前端原型，尤其是 Agent 产品需要的对话界面、工具调用状态展示、trace 可视化和反馈入口。对 C 端 Agent 来说，前端不只是 UI，它会影响数据闭环：用户是否能纠错、是否能看到 Agent 正在做什么、是否能授权记忆写入，都会直接影响模型和系统迭代。

可以强调的前端能力：

• 对话流 UI
• 工具调用进度展示
• 记忆授权 / 删除入口
• thumbs up/down 与原因采集
• trace / debug 面板
• SSE / WebSocket 流式输出

后训练回答：

我了解后训练的基本路线：SFT 用高质量示范数据让模型学会稳定格式和任务流程；偏好优化如 DPO / RLHF 用成对偏好数据提升回答风格和决策质量；Agent 场景还可以用轨迹级数据训练工具选择、计划生成和错误恢复能力。

Agent 后训练可以用哪些数据：

需要谨慎的点：

• C 端数据有隐私，训练前要脱敏和授权
• 不能把工具 observation 里的敏感信息直接进训练集
• 后训练解决不了所有问题，有些是检索、权限、产品流程问题
• 训练前必须先有高质量 eval set，否则不知道是否真的变好

四、如果面试官让你现场讲一个完整方案

可以用这个 2 分钟版本：

我会把千问 C 端 Agent 拆成「用户输入 → 意图识别 → Memory 检索 → 任务规划 → 工具执行 → 结果生成 → 反馈学习」七段。Memory 上分短期会话、长期画像、任务记忆和反思记忆；写入时用结构化 schema 抽取，并经过重要性、隐私、冲突校验；读取时用 BM25 + 向量混合检索，再按时间、置信度和场景 rerank。

编排上，确定性强的任务走 Workflow，比如订阅、创建提醒、资料导出；开放探索任务走 ReAct，比如信息查询、复杂规划、排错。外层仍然要有步数、时间、工具权限和成本上限。

评测上，我会搭 harness，把用户任务、工具 mock、历史记忆和期望结果固定下来，分别评估记忆抽取、检索召回、工具选择和最终答案。线上收集失败轨迹后，先归因，再把可靠样本用于 prompt 调整、检索调参或后训练，最后通过离线回归和灰度上线。

这段话基本覆盖了这轮一面想听到的核心信号：会做 Agent，不只是会调用模型。

五、反问面试官

这轮结束前可以反问 2-3 个问题：

1. 千问 C 端 Agent 当前更关注通用助手，还是垂直场景任务完成率？
2. 团队现在的 Memory 更偏用户画像，还是任务过程状态？
3. Agent 评测是以人工标注为主，还是已经有自动化 harness / LLM-as-judge？
4. 实习生更可能参与模型后训练、RAG/Memory，还是前端和产品原型？

这些问题能传达一个信号：你关心的是「系统怎么变好」，不是只关心用了哪个框架。

六、最后结论

这份面经的关键不在背概念，而在把每个概念落到工程闭环：

• Memory：抽取、写入、检索、更新、遗忘、隐私
• 检索：BM25 + 向量 + rerank + 缓存 + 分层索引
• 编排：ReAct 解决开放探索，Workflow 承接确定流程
• Harness：让 Agent 可复现、可评测、可回归
• 自进化：失败轨迹 → 归因 → 数据 → 评测 → 灰度
• 后训练：必须建立在干净数据和可靠评测之上

如果面试时能把这些讲成一个完整系统，而不是孤立八股，基本就能通过这一面的技术信号筛选。