杭州微链AI应用开发面经：文档入库与DeepAgents

《面试题目》

1. 自我介绍，以及实习过程中的难点和亮点。
2. 详细讲解实习时整个文档入库的全流程，不同文档分别是怎么处理的？
3. 图片和文字是怎么存储的？又是怎么写到一块的？
4. 用到的 RRF 融合，其中 k 是你自己测试调试出来的，还是用已有的默认值？你自己有没有尝试调过？
5. 你这个小组的开发人数是多少？
6. 如果 mentor 派了很多任务，短时间内无法全部实现，你应该如何沟通才能不耽误进度？
7. 如果同时来了两个需求，一个是对整个架构的重构，一个是业务需求，你如何取舍？
8. 你觉得自己的自学能力如何？现在阅读 https://datawhalechina.github.io/deepagents-in-action/chapters/ch01-agent-harness/ 这篇文章，理解里面的内容，等会讲给我听。
9. 讲解一下 DeepAgents 的难点和亮点，它解决了其他 Agent 的什么痛点？
10. 痛点解决带来了什么好处，有什么作用？
11. 子 Agent 可以在运行过程中参与主 Agent 的上下文吗？想一想如何设计。
12. 为什么 DeepAgents 要做模型无关性，而 Claude 和 GPT 不做？
13. 为什么 Claude 和 GPT 不做适配，而 DeepAgents 做了适配？本质原因是什么？
14. 阅读 https://mp.weixin.qq.com/s/6MmevXDynsrlcOoDr3NMEA 这篇文章，讲一下微信新出的这个东西优点和缺点是什么？
15. 为什么做这个能带来哪些好处？配合公司当前要做的人工智能客服，结合文中的四种方案，你觉得当前产品应该怎么做、参考哪个方案？
16. 视觉的人工智能客服全流程，你觉得应该是什么样的？
17. 大模型调用时出现异常（例如超时），你应该如何处理？
18. 反问：入职后具体参与什么开发工作？工作时间是怎么样的？
19. 反问：公司的 AI 会给什么样的搭配？（面试官回答：只要有理由都可以报销）

《参考解析》

文档入库全流程：一条能讲清楚的链路是「接入 → 解析 → 清洗 → 切分 → 富化 → 向量化 → 存储 → 索引」。接入层按来源分流：PDF 走 pdfplumber/PyMuPDF，扫描件先过 OCR；Word/PPT 用 python-docx/python-pptx；Excel 走结构化通道，直接映射成表格而非文本；网页走正文抽取。清洗阶段去掉页眉页脚、目录、乱码和水印。切分不能只有固定长度一种策略：Markdown/技术文档按标题层级切，合同按条款切，表格整表保留并生成摘要，代码按函数切，同时带 10%~15% 的 overlap 保住跨块语义。富化是给每个 chunk 补元数据：文档 ID、章节路径、页码、来源类型、权限标签。向量化时正文用 embedding 模型，标题/摘要可另做一路向量，图片用多模态向量或「图注 + OCR 文本」代替。存储上向量库（Milvus/pgvector/Qdrant）存向量与元数据，对象存储放原图与原始文件，关系库存文档与 chunk 的映射关系，最后用 BM25 或 Elasticsearch 建倒排索引支撑混合检索。入库要做幂等：以 doc_id + chunk_hash 去重，重传覆盖而不是追加。

图文混排怎么存、怎么写到一起：图片不要把二进制塞进向量库或数据库大字段，标准做法是图片落对象存储（OSS/S3/MinIO）拿到 URL，chunk 里存 URL 加图注、OCR 文本、图片摘要。图文「写到一块」有三种粒度：一是位置级，解析时记录图片在文档中的偏移量，重建时按顺序插回 Markdown（![alt](url)）；二是块级，图片单独成块并带上前后文段落作为上下文；三是文档级，图片单独建索引但在检索结果里按 parent_doc_id 与文本块聚合展示。多模态检索推荐「文本向量召回 + 图片向量召回 + RRF 融合」，生成阶段把图片 URL 一起塞给多模态大模型，让它决定在哪一段引用哪张图。

RRF 融合与 k 值：RRF（Reciprocal Rank Fusion）的公式是 score(d) = Σ 1 / (k + rank_i(d))，只用排名不用分数，所以能把量纲完全不同的多路召回（BM25 分数、向量余弦相似度）安全地合起来，这也是它的最大价值。k 是平滑常数，作用是压低头部排名的权重差距：k 越小，第一名与第十名的权重差越夸张，融合结果越贴近单路第一名；k 越大，各路召回越趋于平权，利于把「只在某一路排前面」的文档捞上来。业界默认 60 来自原论文的实证结论，但它不是定理——如果你们的向量路质量明显高于 BM25 路，把 k 调小并给两路加权重会更准。调参要有一套固定的评测集和指标（Recall@k、MRR、nDCG），做法是固定语料与 query 集，只扫 k（比如 10/20/30/60/100）和融合权重，看指标曲线选拐点，而不是凭感觉改。面试时如实说明「默认值起步 + 用评测集验证」比硬说自己从零调出来更加分。

DeepAgents 的模型无关性与「Claude/GPT 为什么不做」：DeepAgents 是构建在 LangChain/LangGraph 之上的 Agent 框架，它要做模型无关是因为它的定位是「框架/中间层」，用户自带模型和 key，一旦绑定单一厂商就失去了通用性与企业私有化部署的空间；同时不同厂商的工具调用协议（OpenAI function calling、Anthropic tool use、各家 reasoning 字段）差异很大，由框架统一抽象一层适配成本最低。Claude、GPT 不做适配不是技术做不到，而是商业动机不同：模型厂商的收益来自自家模型（尤其订阅与 API）被更多调用，做跨厂适配等于替竞品降低迁移成本，还会增加维护面（每家 API 都变）；它们的做法是提供稳定的自家 API 与官方 Agent SDK，让别人来适配自己。本质一句话：框架靠「兼容所有人」赢，模型厂靠「只有我最好用」赢。

子 Agent 参与主 Agent 上下文的设计：默认的 subagent 模式是「委派 + 只回传结论」，子 Agent 拿到的是主 Agent 手写的一段任务描述，看不到完整对话，这样省 token 也不会污染上下文，但信息在交接处必然有损。要让它「参与上下文」，可以按需分三级设计：一是共享只读上下文快照——主 Agent 在派发时把关键消息（目标、约束、已确认事实、相关文件摘要）打包注入子 Agent 的 system prompt，并标注来源；二是共享可写的工作记忆（scratchpad/memory store），主 Agent 把中间结论写进共享存储，子 Agent 用工具读写，通过版本号或时间戳冲突检测避免互相覆盖；三是上下文回传与回流——子 Agent 返回结构化结果（结论 + 依据 + 置信度 + 用到的上下文片段 ID），主 Agent 把结果压缩成摘要再并入自己的上下文，而不是把子 Agent 的整段推理塞回来。需要明确的边界是：不要让子 Agent 无限制地读写主上下文，否则并发写会互相踩、token 也会爆炸；也不要让子 Agent 与主 Agent 同时执行有副作用的写操作，写操作建议收敛到主 Agent 或加锁。

大模型调用异常（超时等）的处理：按「分级重试 + 降级 + 兜底」组织。第一层是超时与重试：连接超时和读超时要分开设置，流式调用用首 token 超时（TTFT）和空闲超时两个阈值，重试只针对可重试错误（超时、429、5xx），数量类错误（400、上下文超长）重试没有意义；退避用指数退避加随机抖动，并给整体请求设一个总预算（deadline），避免重试把延迟放大几倍。第二层是能力降级：主模型超时切备用模型（注意切换后要压缩上下文以适配不同窗口），长输出改成流式分片，必要时缩短检索片段或减少 few-shot。第三层是业务兜底：返回缓存结果、规则模板或明确告知用户「稍后重试」，并把失败请求写入队列异步补跑。工程上必须做的还有：幂等键（同一个请求 ID 重试不重复扣费/不重复写库）、熔断（连续失败就快速失败，别把整条链路拖死）、超时与重试指标打到监控（超时率、P99、各模型成功率）。另外，流式场景下已经吐出一部分内容再失败时，要么保留已生成内容标记不完整，要么整段丢弃重生成，不能拼接两次生成的半截内容。