中兴未来领军计划 AI 算法一面：RAG、Agent 与 Claude Code 原理

《面试题目》

1. 请做一个两到三分钟的自我介绍。
2. 读研期间有没有论文产出？你们的毕业要求是什么？
3. 本硕都是中南，是考研还是保研？本硕期间成绩排名是什么情况？
4. 你使用什么模型？
5. Agent 框架有哪些？
6. Claude Code 的原理、组成和工作流是什么？
7. effort 的 high、low 主要控制什么？
8. effort 会改变 max token 吗？
9. DeepSeek Flash 使用的是最新 0731 版本吗？DeepSeek Flash 有什么提升？
10. 为什么 RAG 既要 embedding 又要 rerank？为什么不能全部 rerank？
11. Agent loop 一般是什么样？
12. Agent 在什么情况下结束？
13. 使用成熟 Agent 工具，还是自己开发？
14. 子 Agent 在实现层面怎么做？子 Agent 是不是做成服务？
15. 多智能体之间如何通信和协作？
16. 2025 年 11 月到 2026 年 6 月的项目是什么系统？
17. 知识图谱中有没有把 node、edge 喂给大模型做结构化输出？
18. 弱模型无法结构化输出，怎么改进？
19. 提示词里的约束怎么设计？提示词约束只是「不要做什么」吗？
20. 对公司有什么了解？为什么投递？通过什么渠道投递？
21. 家是哪里的？
22. 实习工作强度怎么样？怎么看加班？
23. 百度有没有给你转正 Offer？有没有其他 Offer？如何比较其他 Offer？有没有考公或读博计划？
24. 写代码完全依赖 Codex / Claude Code 吗？
25. 使用 AI 编码工具时如何团队合作？
26. 使用 AI 编码工具时，最大的问题是什么？
27. 有没有 AI 解决不了的问题？举例说明。
28. 混合云故障排查如何确保 Agent 定位正确？

《参考解析》

为什么 RAG 既要 embedding 又要 rerank，而不能全用 rerank

两者解决的是不同阶段的矛盾：embedding 检索负责从海量语料里快速缩小候选，rerank 负责在少量候选里精确排序。向量检索把 query 和文档分别编码成向量后算相似度，文档向量可以离线算好、建 ANN 索引（HNSW/IVF），所以能在百万级语料上做到毫秒级召回；代价是 query 与文档在编码阶段没有交互（双塔结构），只能比对整体语义，对否定、数字、专有名词、细粒度的条件约束不敏感，排序偏粗。rerank 用的是交叉编码器（cross-encoder），把 query 和文档拼在一起送进模型做完整注意力计算，能捕捉词级交互，精度明显更高，但它必须在线对每个候选做一次推理，耗时随候选数线性增长。

所以「不能全部 rerank」有两个原因：一是成本与延迟，语料是全量的，逐条打分根本跑不完；二是 rerank 模型有输入长度上限，长文档也不适合直接塞进去。工程上的标准链路是「粗排召回 Top-50100 → rerank 精排取 Top-35 → 交给大模型」，常见的额外手段还有：embedding 之外并行跑一路 BM25/关键词召回做混合检索（提升专有名词和数字的命中）、用元数据过滤先缩小范围、以及对 rerank 结果做阈值截断——分数普遍很低时宁可回答「知识库中没有」，也不要硬塞无关上下文让模型编。

Agent loop 的形态与终止条件

一个最小的 Agent loop 就是「想 → 做 → 看」的循环：把系统提示、用户目标、可用工具和历史观察结果一起送给模型；模型输出要么是最终答案，要么是一个或多个工具调用（含参数）；运行时执行工具，把结果作为新的观察追加进上下文，再进入下一轮。工程实现上一般还会加：规划的显式化（先让模型列 TODO，再逐步执行并更新）、并行工具调用、以及中间结果的状态外置（把长工具输出写进文件或变量，只在上下文里留摘要，避免上下文爆炸）。

终止条件必须显式设计，不能只靠「模型自己说完了」：① 模型直接给出终止信号或不再产生工具调用；② 达到最大步数/最大 token/最大耗时/最大工具调用次数的预算上限，强制收尾并回报「已完成什么、还差什么」；③ 连续 N 轮没有产生新的有效信息或工具反复报同样的错，判定为陷入循环，主动中断；④ 命中不可恢复的错误或安全策略（危险操作、越权访问）立即停止并转人工；⑤ 任务目标达到可验证的完成条件（比如测试通过、文件已生成并校验）。再加一层防护：同一工具同一参数短时间内重复调用要拦截（去重/熔断），以及对循环整体设置超时——否则挂死的 Agent 会一直烧 token。

子 Agent 的实现方式与多智能体协作

子 Agent 本质上是把「一段独立的推理 + 工具使用」封装成一个可复用的能力，实现上有两种主流形态：一是进程内的轻量封装——父 Agent 把一个子任务交给一个独立的模型调用（独立的系统提示、独立的上下文、受限的工具集），拿到它的结果摘要后继续自己的循环，相当于「函数调用 + 上下文隔离」，实现简单、开销小，缺点是共享同一进程的资源和超时预算；二是服务化——子 Agent 是一个独立服务或独立进程，通过 RPC/HTTP/消息队列通信，可以独立扩缩容、用不同模型、单独限流和鉴权，适合团队分工和跨系统调用，代价是引入网络延迟和状态管理复杂度。实际选型取决于隔离需求：需要独立权限、独立模型、独立伸缩就做成服务；只是想让上下文更干净、任务可并行，进程内封装就够了。

多智能体协作的几种典型拓扑：主管（supervisor/orchestrator）——一个主 Agent 拆解任务并分派给专职子 Agent，负责汇总与决策，最容易控住；流水线——按阶段串行传递（检索 → 分析 → 写作 → 校验），每步的产物是下一步的输入；对等协商/辩论——多个 Agent 独立给出结论再互评收敛，用于提高可靠性但成本高；黑板/共享内存——所有 Agent 读写同一份结构化状态，适合长任务。协作的难点不在通信本身，而在上下文传递格式与冲突消解：要有统一的结构化消息契约（任务、输入、约束、产出、置信度、引用来源）、明确谁有最终决策权、以及幂等与去重机制（同一个子任务不要被重复执行）。另外别忘了加上「验证者」角色——让一个独立 Agent 检查结果是否有证据支撑，是抑制幻觉最划算的一招。

effort 档位控制什么，会不会改 max token

effort（有的厂商叫 reasoning effort / thinking budget）控制的是模型在回答前愿意花多少推理算力：high 会生成更长的思维链、做更多自我检查与方案比较，low 则倾向快速给出直接答案。它影响的是思考 token 的数量与推理深度，进而在准确率和响应延迟、成本之间做取舍——适合难度分级的场景：常规问答走 low，复杂推理、代码生成、多步规划走 high。

它和 max_tokens 是两件事：max_tokens 是输出长度的硬上限（包含思考 token 和正式回答），由调用方设定，属于截断约束；effort 是模型侧的行为倾向，不改变上限，但会显著改变「实际用了多少 token」——high 档更容易把预算耗在思考上，如果 max_tokens 设得太小，会出现思考没结束就被截断、正式答案为空的情况。实践上两者要一起调：给 high 档留足输出预算，同时监控「因长度截断而失败」的比例；另外不同厂商对 effort 的实现不同（有的映射到 reasoning 参数，有的只是提示词层面的引导），跨模型切换时要实测而不是想当然。

弱模型结构化输出怎么改进，以及提示词约束怎么设计

结构化输出失败通常不是「模型不想」，而是任务对模型太难 + 约束太弱。可按代价从低到高改进：① 用约束解码——JSON mode、JSON Schema、语法约束（GBNF/grammar）或厂商的 structured output，让采样阶段就不可能产出非法字符，这是最有效的一招；② 简化目标——把「一步输出复杂嵌套结构」拆成多次调用，先抽实体、再抽关系、最后组装，每步只要一个扁平的 schema；③ 提示词里给一个完整的输出样例（few-shot 比纯描述有效得多），并把字段名、类型、枚举值、必填项、空值怎么写全部写死；④ 加校验与修复闭环——解析失败时把报错信息回灌给模型让它只修格式（不重做内容），限制重试次数，仍失败则降级到规则抽取或转人工；⑤ 最后才是换模型或加微调。

提示词约束的设计要点是：只写「不要做什么」不够，负面约束既难穷举、又没告诉模型该怎么做，模型经常一边避开禁令一边跑偏。好的约束是「边界 + 正确做法 + 判定标准」三件套：明确输入输出格式与取值范围，给出冲突时的优先级（比如「以文档为准，文档没写就回答不知道」），并把「不确定时怎么办」写进去（要求输出置信度或明确说无法判断，而不是编一个答案）。再配合少量正反例和可自动校验的结构（schema、枚举、必填字段），效果比堆一长串「禁止……」稳定得多。