携程 Agent 一面：多 Agent 协同、RAG 与意图路由

《面试题目》

1. 先做自我介绍，重点讲项目。
2. 讲一下多个 Agent 之间的协同关系。
3. RAG 的核心流程，结合你的项目简单介绍。
4. context engineering 和 prompt engineering 的区别。
5. 召回率怎么定义、如何计算？
6. 在提升召回率的过程中，哪一个优化点效果最突出？
7. 如何评估 Agent 产出物的质量？
8. Bad case/good case 是否会回流入库？
9. Agent 主要缩减了哪些环节的耗时？
10. 基于用户意图的路由机制是怎么工作的？
11. 路由的准确率怎么样？路由识别错误时有什么处理机制？
12. 用户自然语言到接口链路调配，完整流程讲一下。
13. 遇到用户多意图请求，系统怎么处理？
14. 适配层是如何实现的？
15. 项目有没有做历史记录导出？大量数据读写导出如何处理？
16. 讲一下项目。
17. LangChain 和 LangGraph 的差别、各自优势。
18. 你这边有没有什么想问我的？

《参考解析》

多 Agent 协同要先定「谁负责决策、谁负责执行」。 常见结构是 supervisor/router 做任务分解和分派，领域 Agent 各自持有工具和提示词，Agent 之间通过结构化消息交接，共享一份任务状态（目标、已完成步骤、中间产物、失败原因）。关键不是 Agent 数量，而是边界：每个 Agent 的输入输出 schema、可调用的工具、失败由谁重试、什么时候升级给人工。协同方式可以是串行 handoff、并行 fan-out 后汇总，也可以是辩论/复核；后两种成本高，只在结果质量比延迟更重要时用。工程上要有 trace，把每次分派、工具调用、返回和耗时串起来，否则多 Agent 一出错就很难定位。

Agent 省下的是流程里的等待和搬运，不是所有环节都该自动化。 以旅行业务为例，客服/运营原本要在多个后台之间查订单、查政策、改签、发通知，每一步都要人找入口、填参数、等页面返回；Agent 把「查—判断—调接口—回填」串起来，省的是搜索、切换系统、重复填单和写回复的时间。审批、退款、对外承诺这类高风险动作仍要人确认，异常场景也要人接管。回答时把「自动化收益」和「保留人工的边界」一起说，才像真的落过地。

RAG 的核心流程是「索引」和「检索生成」两段。 离线侧做文档解析、清洗、分块、向量化、建索引，元数据（来源、时间、权限、章节）一起存；在线侧把用户问题改写/扩展，做混合检索（向量 + BM25/关键词），按权限和元数据过滤，再用 rerank 排序，取 TopK 拼进上下文，让模型基于证据回答并给引用。最后是评估：检索看 recall@k、MRR、NDCG，生成看忠实度、答案相关性、引用是否支持结论。项目里如果文档结构强，分块要按标题层级而不是固定字数；如果问题短、术语多，混合检索通常比纯向量稳。

Context engineering 管「模型看到什么」，prompt engineering 管「怎么对模型说」。 Prompt engineering 关注指令、角色、示例、输出格式；context engineering 关注整个上下文窗口的预算与组织：系统指令、用户目标、历史对话、检索证据、工具结果、记忆、待办，哪些进、哪些摘要、哪些外置、按什么顺序放。上下文里塞太多会稀释关键信息、增加成本和延迟；塞太少模型会缺事实。实际做法是分层：稳定规则放系统提示，任务状态放结构化块，证据按相关性截断并标来源，长文档给路径让模型按需读。

召回率是「找回来的相关文档 / 所有相关文档」。 离线评测需要标注每个 query 的相关文档集合，recall@k = 前 k 个结果中相关文档数 / 相关文档总数；precision 是前 k 个里相关占比，MRR 看第一个相关结果的位置，NDCG 考虑排序和分级相关性。提升召回最有效的通常是混合检索加查询改写：纯向量对专有名词、编号、短 query 不稳定，BM25 能补精确匹配；查询改写/多 query 扩展能覆盖不同说法；分块策略和元数据过滤决定候选池质量；embedding 微调和大模型 rerank 也有用，但 rerank 主要提 precision，召回不够时先别急着上。回答「哪个最突出」要给项目里的对照数据，而不是泛泛说都重要。

Agent 产出评估要拆成结果、过程、成本三层。 结果看任务成功率、答案正确性、引用忠实度、格式合规；过程看工具选择是否正确、参数是否合法、步骤数、是否重复调用、是否该停不停；成本看 token、延迟、外部 API 费用。离线用标注集和 LLM-as-judge 做回归，线上看人工接管率、用户反馈、投诉和重试率。Bad case 要回流：按失败类型打标签（检索缺失、工具错、推理错、格式错、权限错），能修的进评测集，修完跑回归；good case 也要留，作为正样本和提示词示例。没有回流机制，评测集几个月就过期了。

意图路由是「先判断用户要什么，再决定走哪条链路」。 可以用分类模型、embedding 相似度或 LLM 做意图识别，输出意图标签、置信度和槽位；置信度高直接路由，低置信度走澄清或 fallback，不能硬猜。路由错误要有兜底：允许用户纠正、保留上一轮上下文、把失败样本记下来做再训练；多意图请求先拆成子任务，排依赖后串行/并行执行，最后合并结果；如果子任务冲突或信息不足，先问清再执行。自然语言到接口的链路是：意图 → 槽位抽取 → 接口选择 → 参数映射 → 校验 → 调用 → 结果归一化 → 回复。适配层负责把不同接口的入参、出参、错误码统一成内部 schema，做鉴权、超时、重试和降级，这样上层 Agent 不需要认识每个下游的差异。

历史记录导出是典型的「不能同步硬扛」需求。 小数据量可以同步分页查、流式写 CSV；数据量大就走异步任务：创建导出任务，后台分页/游标扫描，边读边写对象存储，完成后给带过期时间的下载链接，前端轮询或订阅通知。要点是游标分页避免深 offset、限制单次导出范围和频率、脱敏与权限校验、失败可重试、任务状态可查。导出期间不要长事务，也不要把全量结果一次性放进内存。

LangChain 和 LangGraph 不是替代关系。 LangChain 提供模型、工具、检索、输出解析等组件和链式组合，适合线性流程和快速搭原型；LangGraph 把流程建模成有状态的图，节点是步骤、边是转移，支持循环、条件分支、检查点和人工介入，适合多轮 Agent、需要恢复和审计的场景。选型看流程是否有环、是否需要持久化状态和人工审批；简单 RAG 用 LangChain 就够，复杂 Agent 用 LangGraph 更稳，但也要接受它带来的状态管理和调试成本。