虾皮 Agent 开发一面

《面试题目》

1. 硕士是两年制专业硕士吗？为什么没有选择学硕？
2. 请简要介绍一下实习期间的主要工作。
3. 项目1主要解决了什么问题？
4. 推理路径是否描述了一个完整的 Agent 执行流程？
5. 模型微调的目标是什么？是否是让模型按照预期生成推理路径和后续执行结果？
6. 项目能否不进行模型微调，只通过 Prompt 和工具约束实现？
7. 是否可以在关键推理步骤直接使用能力更强的模型？为什么实验中不直接选择最强模型作为基座？
8. 你们是否使用 LoRA 进行模型微调？
9. 项目2是在什么业务场景下完成的？
10. 系统是否预先维护了一组故障处理方案，再按照可能性依次尝试？
11. 项目实施过程中遇到的最大问题是什么？
12. 系统是否需要进行日志排查？具体如何利用日志定位故障？
13. 当代码层级较深、文件较多时，Agent 如何准确定位相关代码？
14. 你们如何为代码目录和文件生成 Description？生成内容需要遵守哪些约束？
15. Description 包含哪些粒度？
16. 你们是否将所有业务代码放在同一个代码仓库中，再通过目录区分不同业务？
17. 代码发生修改或重构后，Description 如何及时更新？
18. 如何评估 Description 对代码定位是否有效？
19. 如果过期的 Description 对 Agent 产生误导，系统如何发现并纠正？
20. 完成一次问题查找和故障归因通常需要消耗多少 Token？
21. 系统使用什么模型？是否自行部署？
22. 模型推理和 Agent 执行流程是否由你们自行实现和编排？
23. 项目为什么没有使用 LangChain？
24. 模型调用或部署的成本大约是多少？
25. 系统完成后是否已经交付给企业使用？
26. 系统如何根据使用过程和用户反馈持续优化？
27. 用户给出负面反馈后，相关案例是否也应该沉淀下来用于后续分析和学习？
28. 是否接入了 Agent 执行轨迹追踪工具，例如 LangSmith？
29. 项目3是否是为学校内部建设的？项目的主要难点是什么？
30. 知识图谱中包含哪些实体和实体关系？
31. 用户问题进入系统后，如何拆解 Query 并识别相关实体？
32. 系统采用的探索式查询方法是否类似蒙特卡洛树搜索？
33. 系统的知识库和索引使用了什么技术构建？
34. 用户输入关键词后，如何在知识图谱中查找对应实体？
35. 如果命中多个实体或三元组，系统如何排序？检索时是否召回全部相关内容？
36. 系统上线后的实际效果如何？
37. 用户可以通过系统查询哪些信息？用户最常提出哪些问题？

《参考解析》

1. 微调还是 Prompt：先看任务是否「可枚举」：判断标准不是哪个更先进，而是失败模式能不能靠约束消掉。如果错误集中在输出格式、步骤顺序这类显式规则上，Prompt 加校验、加少样本示例就能解决，改动成本几乎为零；只有当模型缺少领域知识、或者推理路径的分布根本无法用文字描述清楚时，微调才有必要性。中间还有一条常被忽略的路：关键步骤调用更强的模型做「裁判」或重规划，把便宜模型留给常规步骤，用混合路由换成本与质量。

2. LoRA 的位置与基座选择：LoRA 冻结原权重、只训低秩旁路矩阵，显存与存储开销小、可以多份适配器热插拔，适合在有限算力下对齐输出风格与固定流程；它的上限受基座能力约束，学不会基座完全没有的能力。不直接选最强模型当基座，通常是三笔账：推理成本（线上每次调用都付）、部署条件（显存和卡的数量决定能不能私有化）、以及延迟与并发；用大模型只做数据标注和难例兜底，把小模型训到能扛常规流量，才是可持续的组合。

3. 代码定位：Description 的粒度、生成与维护：让 Agent 在深层目录里找准文件，靠的是分层索引而不是把全仓代码塞进上下文。粒度上通常三层——仓库级说明整体架构与模块划分，目录级说明职责边界与依赖关系，文件级写清导出的类与函数、关键副作用和调用方。生成时用模型读代码产出初稿，但必须加约束：只描述代码里能看到的事实、不臆造业务背景、必须给出关键符号名，并保留文件路径与哈希便于校验。更新靠事件驱动——提交或重构后按变更文件重新生成，不做全量重跑；对没变动的文件复用缓存。失效检测则用一致性校验：拿 Description 里的符号名去代码里 grep，找不到就是过期；再叠加线上表现做监控，比如同一个问题反复定位到错误的文件、或者工具调用连续失败，就把这条索引标黄进入人工复核队列。

4. 故障归因与日志排查的工程化：把日志排查做成流程而不是靠人临场发挥：先按时间窗口和 trace id 收敛范围，再按错误码与异常栈聚类找出主要失败模式，然后关联上下游指标（QPS、延迟、错误率、资源水位）确认是流量、依赖还是自身发布引起。系统预置常见故障的处理方案并按可能性排序是合理设计，但不能让它变成静态规则库——每次真实故障的处置结果要回流成新案例，与检索库一起参与下次匹配。成本上要给每次归因设 token 预算：先检索、再让模型读少量高相关片段，避免一上来就把全量日志喂进去。

5. 不用 LangChain 的取舍：自研编排的代价是要自己实现状态管理、重试、并行、流式输出和可观测性；收益是提示词与工具调用的完全可控、少一层抽象带来的调试便利、以及避免框架版本变更引起的隐性行为漂移。判断依据是流程是否复杂到框架的抽象能省下可观工作量——如果核心链路只有几步固定的模型调用加工具执行，自研通常更划算；一旦需要多分支、多 Agent 协作、丰富的回调与追踪，成熟框架的生态优势就会显现。无论选哪边，轨迹追踪（如 LangSmith 一类）都该接入，否则线上出了问题只能靠日志猜。

6. 知识图谱问答的 Query 拆解与实体链接：用户问题进来先做意图识别，判断要查的是实体属性、实体关系还是多跳路径；再做实体识别与链接，把口语化表述映射到图谱里的规范实体，这一步通常要配合别名表、同义词词典和向量召回，光靠字符串匹配命中率很低。图中的探索式查询本质上是「按当前已确认的三元组逐步扩展候选」，与蒙特卡洛树搜索的相似之处是都用「扩展—评估—回退」的循环，区别是它缺少明确的收益函数，多数实现靠启发式打分排序。命中多个实体或三元组时不能全召回，要按置信度、关系距离、热度、时效性加权排序后取 Top-K，并把选中的依据一起返回给用户，让结果可核对；覆盖不到的问题要明确说不知道，硬答会直接毁掉信任。