美团 AI Agent 开发岗面经：RAG 切分、多 Agent 协同与上下文压缩

《面试题目》

面经 01（8 月 23 日）

1. 介绍一下你做过的 Agent 项目，整体架构是怎样设计的？主要解决什么问题？
2. RAG 流程具体如何实现？包括文档切分、向量检索、召回以及生成等环节。
3. 在 RAG 场景中，文本切分策略如何选择？不同切分方式会带来什么影响？
4. 如果系统中存在多个 Agent 协同工作，多个 Agent 之间如何进行任务分配和结果整合？
5. 多 Agent 并行执行时，如何管理不同任务的执行状态？最终输出结果如何汇总？
6. Agent 运行过程中如何管理上下文？如何避免上下文过长导致模型效果下降？
7. 你如何理解 Agent？相比传统应用，它具备哪些核心能力？
8. Agent 系统中的路由机制如何设计？如何判断请求应该交给哪个 Agent 处理？
9. 上下文压缩（CC）相关技术了解多少？为什么 Agent 场景需要进行上下文优化？
10. 选择 Java 或 Python 作为主要开发语言分别有哪些优势？你更熟悉哪一种？
11. 并发和异步编程有什么区别？在实际开发中分别适用于哪些场景？
12. 如何实现异步任务处理？常见的异步方案有哪些？
13. Agent 开发中常见的工程化问题有哪些？例如任务调度、工具调用和状态管理如何解决？
14. Vibe Coding 是什么？你如何理解这种开发方式？实际使用中有哪些优缺点？
15. 如果让你设计一个 Agent 应用，需要从哪些方面进行整体规划？

面经 02

16. 详细介绍一下项目：项目场景、设计方案、开发内容。
17. 选取一个真实问题单，完整描述从 Agent 接收输入、走完全流程、到产出最终结果的整条链路。
18. 测试报告/测试用例设计，如何判断符合本次新需求改动？新功能无历史问题单，怎么设计测试用例？
19. 需求文档、技术方案为什么没有作为输入信息纳入系统？
20. 最终产出的结果只是文本，是否会执行真实任务？哪些环节需要人工确认？
21. 信息如何持续积累、迭代更新？执行失败后的结果如何回流？
22. 项目使用 Python + FastAPI，数据库层如何接入？数据库表是否由你设计？
23. 两个 QA 同时输入相同查询，Agent 给出的报告是否一致？
24. 整体 Agent 流程使用 workflow，为什么该场景适合 workflow？Agent 执行流程有哪些形式，相互差异是什么？
25. 外部环境、参数变化，会不会导致相同测试任务执行结果不一样？如何处理？
26. 项目 2 对比项目 1，在 Agent 设计层面有什么差异？
27. 你主要负责哪些模块、哪些具体开发工作？
28. 项目里封装了 CLI 工具，介绍下 CLI 的实际开发内容。
29. 为什么要把 skill/工具执行流程封装成 CLI，这种方案有什么好处？
30. 用户输入不完整的信息，系统如何校验、补全参数并继续执行？哪些参数必须用户确认？
31. 残缺信息无法唯一确定资源，系统如何选择？
32. 讲讲你对 skill 的理解，skill 只包含流程说明，还是包含完整设计？
33. 项目 3 的整体架构、模块分层是怎样的？
34. 该项目的存储层如何设计？
35. Skill、MCP、Function Calling、Workflow、SubAgent 分别解决什么问题，你在项目中如何组合使用？
36. 介绍下 AI Coding 笔试题，拿到题目后如何解读、实现？
37. Agent 开发中，知识维护怎么做？（原帖在此处被截断）

《参考解析》

1. RAG 全链路与切分策略。 完整链路是：文档解析（PDF/Word/HTML，保留标题层级与表格）→ 切分 → 向量化 → 建索引（向量 + 关键词 + 元数据）→ 查询改写 → 混合召回 → 重排 → 拼上下文 → 生成 → 引用与校验。切分方式直接影响召回质量：固定长度（按 token 数）简单但会把句子/表格劈开；按结构切（标题、段落、列表项）能保留语义边界，是默认选择；语义切分对超长段落按相邻句相似度的低谷断开，效果好但成本高；父子块（child 小块用于检索、parent 大块用于生成）能同时兼顾精确召回和上下文完整。经验参数是块 300~800 token、重叠 10%~15%，表格和代码单独处理、不要按字符切。切完要给每个块带上文档 id、标题路径、页码/时间等元数据，后面过滤和引用都靠它。

2. 多 Agent 的任务分配与状态管理。 任务分配有三种模式：编排者（orchestrator）拆任务后分派、对等协商（agent 之间通过消息总线认领）、以及按能力路由（每个 agent 注册自己能做什么，路由器按意图选）。结果整合靠「共享状态 + 明确的产出契约」：每个子任务产出结构化结果（状态、证据、错误码），编排者负责合并、去重、解决冲突（比如两个 agent 结论相反时按证据强度裁决）。并行执行要用任务表或 DAG 记录每个节点的状态（pending/running/done/failed）、重试次数、超时，失败要能局部重跑而不是整条链路重来；汇总时保留中间产物和引用，方便追溯是哪一步导致最终结论。

3. 上下文管理与压缩。 先分层：系统提示词与工具定义固定在头部（命中前缀缓存），会话历史按「最近 N 轮原文 + 更早的摘要」，检索到的资料按相关性裁剪后放入，工具返回只保留模型需要看的字段。压缩手段有：滑动窗口、分层摘要（每 N 轮生成一次摘要并保留关键实体）、按需检索（不预加载，让模型主动查）、结构化状态（把任务进度、已确认参数写成 JSON 而不是对话历史）、以及子 Agent 隔离（子任务在独立上下文里跑完只回传结论）。判断是否该压缩看信号：token 接近窗口上限、首字延迟上升、模型开始遗忘早期约束、或重复提问。压缩的代价是丢细节，所以关键约束（用户偏好、禁止项、已确认参数）要单独存成不可压缩的「事实区」。

4. Agent 与传统应用的区别。 传统应用是「输入 → 确定的代码路径 → 输出」，Agent 是「输入 → 模型决定下一步动作 → 执行工具 → 观察结果 → 再决策」，核心能力是自主规划、工具使用、环境反馈闭环和错误恢复。代价是不确定性：同样的输入可能走不同路径、结果不完全一致，所以工程上要用状态机约束流程、用评测集量化效果、用预算（步数/token/时间）兜底，并对副作用操作加人工确认。

5. 路由与上下文压缩（CC）。 路由的本质是分类：规则（关键词、正则）打底，语义路由（embedding 与各 agent 的描述做相似度）覆盖同义表达，模型路由（让 LLM 在候选列表里选，带理由）处理模糊场景，最后加兜底（无法判断时走通用 agent 或反问用户）。路由要可观测：记录每次选择的候选、分数、最终结果，离线用混淆矩阵看哪两类容易混。上下文压缩在 Agent 里尤其重要，因为一轮任务可能调用几十次工具，原始返回会迅速占满窗口；常见做法是工具结果截断 + 摘要、把历史折叠成「已完成的步骤 + 当前状态」、以及用独立子上下文跑长任务，只把结论回传主线。

6. workflow 与 Agent 的取舍。 workflow 是「步骤预先定义、条件显式」的编排，优点是可控、可测、可审计、成本稳定；Agent 是「模型自己决定下一步」，优点是灵活、能处理没见过的组合，缺点是路径不可预测、调试难、成本高。判断标准：任务步骤能否在编码时枚举完？能就 workflow；只有「开放性探索、步骤依赖运行时观察」才用自治 Agent。实际系统多是混合：外层 workflow 保证主流程和人工确认点，内层在某个节点用 Agent 处理不确定的子问题。相同输入结果不一致的问题，靠固定随机性（temperature=0）、缓存中间结果、把环境参数显式记录进 trace 来定位，而不是指望模型稳定。

7. Skill、MCP、Function Calling、Workflow、SubAgent 的分工。 Function Calling 是模型输出「调用哪个函数、参数是什么」的协议层能力；MCP 是把工具/资源以标准协议暴露给模型的接入层，解决「工具怎么接、怎么发现」；Skill 是面向任务的「流程知识 + 工具组合 + 判断标准」的封装，通常是一段可加载的说明加脚本，解决「这类任务该怎么做」；Workflow 是确定性的编排层；SubAgent 是上下文与权限的隔离手段，把长任务丢到独立会话里跑。组合方式：workflow 控制主流程 → 某一步加载 skill 获得做法 → skill 内部通过 MCP/function calling 调工具 → 需要隔离或并行的子任务派给 subagent。

8. CLI 封装与参数补全。 把工具流程封装成 CLI 的好处：① 模型只需要生成一条命令，而不是多轮函数调用，token 和轮次都省；② 逻辑可单测、可版本化，模型不用理解内部实现；③ 权限和审计收敛在 CLI 入口。参数补全的做法是「schema 校验 + 缺参追问 + 默认值 + 歧义消解」：先按工具的参数 schema 校验类型和必填项，缺的必填参数向用户追问（一次问一个，别一次抛五个），有默认值的用默认值并在结果里说明；如果残缺信息对应多个资源，列出候选让用户选，不能自己猜；有副作用的参数（金额、收件人、删除目标）必须显式确认。