美团 Agent 开发凉经：项目匹配度不够，但问题很经典

《面试题目》

Agent 架构与多 Agent

1. 自我介绍一下，简单介绍自己的技术方向和 AI Agent 相关经验。
2. 介绍一下你做过的 Agent 项目，整体架构怎样设计？主要解决什么问题？
3. 如果系统中存在多个 Agent 协同工作，多个 Agent 之间如何进行任务分配和结果整合？
4. 多 Agent 并行执行时，如何管理不同任务的执行状态？
5. 最终输出结果如何汇总？

上下文与记忆

6. Agent 运行过程中上下文信息如何管理？如何避免上下文膨胀？
7. 上下文压缩怎么实现？记忆压缩怎么减少上下文同时保留关键信息？
8. 长期记忆和短期记忆怎么设计？
9. 记忆冲突怎么处理？
10. 用户最新指令和长期记忆冲突怎么处理？
11. Agent 记忆模块如何设计？
12. 上下文无限膨胀有哪些处理方案？

RAG 与检索

13. RAG 流程具体如何实现？包括文档切分、向量检索、召回、生成。
14. RAG 场景中文本切分策略如何选择？不同切分方式带来什么影响？文档切分粒度怎么确定？
15. 如果 Markdown 没有标题怎么切分？
16. 短 query 和长 chunk 向量化差异在哪？
17. 混合检索中 BM25 和向量检索结果怎么融合？RRF 的 k 值怎么设？
18. RAG 召回效果不好怎么排查？

业务场景与工程细节

19. 结合业务，设计一个行程规划 Agent，你会怎么设计？
20. 商品推荐 Agent（用户画像 + 行为）怎么设计？
21. 意图识别怎么做的？意图识别准确率怎么测？
22. 评测集怎么构建？大概多少条？
23. 工具调用失败常见原因？怎么优化成功率？
24. Agent 项目 Token 成本从哪些维度优化？
25. Agent 输出 JSON 怎么做 Schema 校验？
26. 手撕：实现一个线程安全的 LRU。

《参考解析》

1. 多 Agent 的任务分配、状态管理与结果汇总。 分配要有显式的分解与依赖（把目标拆成带依赖的子任务形成有向无环图），由调度器按依赖与并行度分发；分配依据是能力标签或资源空闲度，由代码判定，模型只负责产出任务描述与所需信息。状态分三级：任务级（待执行、执行中、成功、失败、超时）、子任务级（输入、输出、重试次数、错误）、步骤级（每次工具调用记录）；状态外置并每步落检查点，任何 Agent 挂掉都能重派而不是重跑全局。汇总不是字符串拼接而是结构化归并：每个子任务输出结论、证据、置信度，先按实体去重再处理冲突，无法裁决就标记冲突并升级校验，最后按重要性排序生成答复。并发要防重复执行（用租约加幂等键解决）与互相等待（靠超时与显式失败状态打破活锁），并设总步数、总 token 与总时长预算，触顶降级并如实告知哪些子任务没完成。

2. 上下文与记忆的分层、压缩与冲突处理。 第一原则是该带什么而不是能带多少：常驻区放系统指令、工具契约、任务硬约束与长期偏好摘要；工作区放当前子任务的检索片段与最近几轮原文；归档区放更早历史与已完成子任务的摘要。避免膨胀的手段按性价比排序：工具返回裁剪成结构化结果、大产物落盘只带引用、列表做 top-N、历史滚动摘要、按需检索而不是全量注入。压缩要么结构化抽取（固定字段输出目标、约束、已完成、待办、关键实体与数值），要么分块摘要再合并，前提是只替换注入内容、不删原始记录，并做实体与数字一致性校验，丢了就从原文回捞。记忆分层上，短期是当前会话原文与工作状态，长期是历史会话沉淀出的稳定事实与偏好。冲突处理顺序是时间优先、明示优先、置信度兜底：当前指令覆盖历史记忆，冲突时用一句轻确认把决定权交给用户，并写回新值、降低旧值权重；记忆还要可删、可查、可衰减。

3. 意图识别、评测与成本优化。 意图识别线上三层：规则（关键词、正则、实体）覆盖高频固定句式，保证准确与可解释；小模型分类器处理同义改写与长尾；LLM 处理低置信样本，负责细分意图与槽位抽取。评测要分层看：意图分类本身看准确率、召回率与混淆矩阵（重点是错路由到高风险动作的假阳性），链路级看端到端任务成功率与追问率；评测集从真实日志按意图分布分层采样，加入同义改写、歧义、多意图与对抗样本，总体千级起步，并持续回流 badcase。成本按输入、输出、次数、单价四轴优化：输入侧裁剪与摘要、检索替代全量注入、prompt caching、精简工具描述；输出侧限制 max_tokens；次数侧明确终止条件、去重已执行动作、缓存纯读结果；单价侧按任务难度路由模型与思考等级。要有记账与归因，并看单次任务总成本。

4. 行程规划 Agent 与商品推荐 Agent 的设计。 行程规划的关键是把开放需求收敛成可校验约束再求解：解析出发地、天数、人数、预算、日期与偏好；规划器产出“天—时段—活动”骨架；工具层调 POI、路线耗时、天气、票务拿真实数据；求解器在时间不重叠、通勤可行、营业时间内、天气允许的约束下排程，用位置聚类减少通勤。异常处理分工具失败（重试加降级到缓存，或让模型给候选并标注未核实）、约束冲突（下雨换室内并说明改了什么）、需求变更（两天压一天按约束变更重解，保留已确认项）、不可满足（讲清哪条做不到，给可选方案）。商品推荐 Agent 的输入是画像、行为与上下文：画像给长期偏好与约束，行为给实时意图（浏览、加购、搜索序列按时间衰减加权并做结构化摘要），上下文补天气地域时节；候选来自召回与排序链路，模型负责解释与取舍，推荐理由基于真实属性、用槽位模板与去重避免千篇一律，结果做多样性打散与探索位。两者共同要求是幂等与可回滚。

5. RAG 切分、混合检索与召回排查。 切分要与结构匹配：有标题的先按标题切再按长度合并；代码块、表格、清单整块保留；纯文本滑窗加重叠；Markdown 没有标题时用空行与段落做弱分隔聚合成目标长度，或用语义切分兜底。粒度用评测反推：固定检索与生成流程，只改 chunk size 与 overlap 看召回率与答案质量，256 到 512 token 是常见起点；每块带父级标题、路径与位置元数据，支持小块命中、大块喂模型。短 query 与长 chunk 的差异在于短文本向量落点泛化、长文本语义平均化导致相关性被稀释，缓解靠查询改写与扩展、给 query 与 passage 加不同前缀、双粒度索引与 rerank 精排。BM25 与向量的融合最常用 RRF：按排名给 1/(k + rank) 再相加，只用排名不用分数，天然规避量纲问题；k 越大越平滑，60 是稳妥默认。召回排查顺序：答案是否存在、切分是否切断答案、embedding 与索引是否正确、三路召回率对比、rerank 是否挤出正确块。

6. Schema 校验与线程安全 LRU。 JSON 落地靠三层：预防用结构化输出能力（JSON Schema、tool calling）并在 prompt 里给字段说明与示例；容错解析要剥掉代码围栏、截取首尾花括号、容忍尾随逗号与中文引号，缺字段补默认值而不是整体失败；修复重试把原始输出与具体校验错误回灌给模型只修格式，重试一到两次，仍失败就降级（正则兜底或标记该步失败交上层决策），绝不用半截结果继续跑。校验规则用 Pydantic 或 Zod 写在一处，并把格式失败率作为单独指标统计。线程安全 LRU 有三种做法：整体加锁（正确但把并发串行化）、ConcurrentHashMap 存节点加链表分段锁、生产上直接用 Caffeine 或给 LinkedHashMap 配 removeEldestEntry 再包一层同步。关键是讲清临界区：哈希表与双向链表的一致性是一个不变式，读节点再移动、写表再插删链必须整体在锁内，只锁容器操作会导致链表断裂或丢节点。