滴滴 Agent 岗面经：智能客服与行程规划 Agent 设计

时间: 2026-10
来源: 牛客网

《面试题目》

挑选完成度最高的核心项目，完整介绍背景、方案与落地价值。
对话类 AI 项目的目标用户和实际服务场景是什么？
智能问答系统是否仅用于信息查询辅助，不参与最终决策？
智能问数项目最大的技术瓶颈是什么？怎么排查解决？
数据误差的根源是数据链路缺陷，还是大模型数值理解不足？
项目遇到过大模型幻觉吗？怎么优化？
知识库增强与模型微调的适用边界是什么？什么场景优先微调？
微调时基座模型的参数量、版本怎么选？
微调数据集怎么筛选、构造、扩充？
微调效果评估体系怎么搭建？
强化学习框架怎么搭建？
verl 框架里的 agent loop 怎么实现？
强化学习包括哪些组件？
详细介绍 GRPO 算法。
on-policy 和 off-policy 的区别是什么？
出行场景用哪种？为什么？
用大模型做出行智能客服，怎么设计对话状态管理？
用户说「我赶时间」，Agent 怎么快速响应？
用户说「帮我叫一辆车去机场」，需要调用哪些工具？怎么编排？
高峰期车辆紧张，Agent 怎么和用户沟通？
怎么设计兜底方案？
怎么评估出行 Agent 的服务质量？
除了准确率还有哪些指标？
结合出行场景，「行程规划 Agent」该怎么做？
长流程下上下文超限怎么解决？
如果 1M 上下文还不够怎么办？
断点恢复怎么做？
多 Agent 同时修改同一文件怎么防冲突？
Agent 的输出效果怎么量化评估？
RAG 如果存在图片类非文本内容怎么处理？
你做的平台里，Agent 如何完成一个完整任务——从接收用户输入、判断意图、生成工具参数、执行工具、结果注入，到判断完成与格式化安全检查？
手撕：买卖股票的最佳时机 II；编辑距离。

《参考解析》

项目追问的答题主线：每个选型都要有依据、指标和踩坑

这类面试官不接受「我们用了 RAG 所以效果好」这种回答，每个技术点都要能给出三层：为什么选它（对比了哪些方案、约束是什么）、怎么验证有效（离线指标与线上指标各是什么、提升多少）、踩过什么坑（出了什么问题、怎么发现的、怎么修的）。项目介绍也要按「背景 → 目标用户与真实场景 → 方案 → 落地价值与量化结果」讲，其中「这个系统只做辅助、还是参与最终决策」这类问题要明确回答边界，因为它决定了后续所有指标的定义。

智能问数的误差归因与幻觉治理

数据答错先要判定责任在哪一段，方法是用对照实验把变量拆开：固定问题只换数据源（看是不是 SQL 生成错、口径错、字段取值错），固定查询只换模型（看是不是数值理解错），并把中间产物打出来——生成的 SQL、查回的原始表、模型的推理与最终答案，逐段核对。经验上的区分是：数据链路问题通常有系统性（同一口径的一批问题全错、换人问也一样），且错误在 SQL 或数据本身就能看到；数值理解问题表现为「表是对的、结论是错的」——模型在长表格上看错行、把单位搞混、做多位加减乘除或比较时出错，本质是数字被拆成 token 后缺少数值感、长上下文注意力被稀释。

治理思路是把计算交给代码、把判断留给模型：模型负责理解意图、生成查询、组织解释，聚合与运算走 SQL/代码执行；查询结果做一次回读校验（行数、量级、单位、时间范围是否符合预期）；对关键数字要求引用数据来源，答不出来就明确说无法确认。幻觉则分三层压：检索层保证证据真进上下文并标来源与时效，生成层要求区分「证据里明确写了」与「推断」，执行层对高风险结论做一致性复核，最后用评测集统计无依据回答率与拒答准确率。

知识库增强与微调的适用边界

判断标准是「这份知识会不会变、需不需要引用溯源、是事实还是行为」。知识型、频繁变更、需要给出处的内容（政策、价格、口径、文档）走 RAG——改一份文档就能生效，不用重训，还能把原文当证据返回。行为型、稳定、高频执行的能力走微调——固定的输出格式、工具调用规范、领域表达风格、特定的推理链路，这些靠提示词堆例子既贵又不稳。以下场景优先微调：任务窄但调用量极大、对延迟和成本敏感（微调小模型替掉大模型）、输出格式必须严格符合 schema、行业术语与话术需要稳定一致、以及要把复杂提示词蒸馏进权重来省 token。两者不互斥，常见组合是「微调负责能力与格式，RAG 负责事实与更新」，上线后用同一套评测集分别验证各自贡献。

微调：基座、数据与评估

基座选择先看四件事：任务复杂度（决定能力下界）、推理成本与显存预算（决定参数量）、是否有较长上下文与外推需求、以及与线上已有版本的连续性——基座版本尽量与线上一致或至少在评测集上不退化，换 base 是大版本级变更，必须整体回归，不能只看微调任务上的分数。参数量常见做法是先用 7B/14B 打底验证数据与配方，确认真有收益再放大或按成本选型；小模型能过就上小模型，把大模型留给真正难的请求，做「大小模型路由」通常比一味放大更划算。

数据是微调里最决定性的一环：来源优先用真实线上日志（最有代表性），人工标注做质量锚点，合成数据补长尾和难度分层；流程是去重、清洗（去噪、去截断、去格式错）、按意图与难度分层、控制长度分布、留出严格不重复的验证集。评估分三层：离线看任务指标（格式遵循率、工具调用正确率、事实一致性）与回归（通用能力有没有掉）、人工看小样本质量、线上看 A/B 的业务指标。数据配比和评测集要像代码一样版本化，否则指标提升说不清是哪次改动的功劳。

强化学习框架、verl 的 agent loop 与 GRPO

RL 的组件拆开就是：环境（或模拟器）+ 策略模型 + 采样器（rollout）+ 奖励函数 + 训练器（含参考模型与 KL 约束），工程上还要有轨迹存储、优势估计、批组织与分布式调度。在 verl 这类框架里，agent loop 由 rollout 侧驱动：worker 拿到 prompt 后进入多轮循环——策略模型生成动作（含工具调用），执行器真实执行工具并把观测拼回对话，直到任务完成或达到最大轮次；每个 token 带 response mask，只有模型自己生成的 token 参与 loss，工具返回的观测要屏蔽掉；轨迹级的奖励在整条轨迹上聚合后回传给训练器，同时要做长度截断、并发控制与工具失败的重试/记录。这里最容易出问题的是训练与推理的一致性：模板、停止符、工具 schema、上下文拼接方式在采样和训练两边必须完全一致，否则奖励会失真。

GRPO（Group Relative Policy Optimization）的核心是去掉价值网络：对同一个 prompt 采样一组（G 条）输出，用组内奖励的均值（可选除以标准差）作为基线，得到每条输出的相对优势，再按 PPO 的裁剪目标更新策略，同时加与参考模型的 KL 惩罚。优点是省掉 critic 的显存与训练不稳定性，特别适合奖励可自动判定的场景（数学、代码、工具调用是否成功、格式是否合法）；要注意组大小、奖励尺度与稀疏奖励的处理，奖励全同的组没有梯度信号。

on-policy 与 off-policy 的区别在于更新用的数据是不是当前策略产生的：on-policy（PPO/GRPO）每轮用当前策略采样，分布匹配、训练稳定，但采样成本高；off-policy（SFT、DPO、离线 RL）用历史或别的策略产生的数据，样本效率高，但存在分布偏移，需要重要性采样修正，且容易过拟合离线分布。出行场景的务实答法是分阶段：冷启动阶段用 off-policy 的路子（SFT 打底 + 离线偏好数据/拒绝采样）把格式、话术与常识对齐；进入迭代后转 on-policy，因为出行任务的奖励高度依赖实时环境（车况、路况、用户是否取消、等待时长），离线数据覆盖不到当前策略真实的错误模式。

出行智能客服：状态管理、工具编排、兜底与评估

对话状态管理的核心是把状态从对话历史里拿出来，结构化管理：显式维护当前意图、已确认槽位、待确认项、会话级约束（比如「赶时间」）、以及已经执行过的动作及其结果，由程序保证状态流转的合法性，模型只负责抽取与决策。每轮把状态的精简摘要注入提示，而不是把全部历史塞进去；状态落库之后天然支持多轮、跨会话与断点恢复。

「我赶时间」这类输入的正确处理是减少确认轮次：能从上下文推断的槽位用默认值加一次合并确认，而不是逐项问；同时把它写成会话级约束，影响后续所有决策（少推选项、直接给最快可用的方案）。「帮我叫一辆车去机场」要拆成工具序列：目的地消歧（哪个机场、哪个航站楼、出发时间）、上车点获取与确认、可用车型与预估价查询、下单、支付或免密校验、行程跟踪与分享，必要时叠加「预计到达时间 vs 航班时间」的时间兜底。编排原则是能并行的并行（定位与车型查询）、有歧义先澄清、有副作用的下单必须在确认之后执行并且带幂等键、每一步失败都有明确降级路径。

高峰期车辆紧张时的沟通要点是给真实信息和可执行的替代方案：如实说明等待时长与排队情况，给出备选（其他车型、附近上车点、预约用车、其他出行方式），把决定权交给用户，不承诺工具没有返回的结果。兜底方案要按失败类型设计：工具超时重试并保证幂等、无车时降级到替代方案、地址无法解析时引导用户补充、模型输出不稳定时回退到模板话术、所有路径都走不通才转人工，并且转人工本身要有明确的触发条件，不能靠模型自由发挥。

服务质量评估不能只看准确率：任务完成率与一次解决率、平均交互轮次、工具选择正确率与参数准确率、澄清次数、人工转接率、用户取消与改口率、首 token 与端到端时延、单次对话成本、安全合规违规率、满意度与复访。做法是离线评测集（含对抗与边界样本）+ 在线 A/B + 轨迹回放三层，缺一层都会出现「离线涨、线上跌」。

行程规划 Agent：长流程、上下文与断点恢复

行程规划是多约束、多步、可回滚的长任务，做法是把计划做成结构化对象（目标、约束、候选方案、已确认步骤、待办），由程序维护与校验，模型负责生成候选与解释权衡。长流程的上下文管理按「结构化状态 + 摘要 + 检索」三件套：当前状态与最近若干轮原文常驻，更早的历史压成保留硬信息（时间、地点、数字、结论）的摘要，工具产生的大结果外置存储、上下文里只留引用与摘要，需要时再按子目标检索回来。

如果 1M 上下文仍然不够，思路要从「塞更多」转向「拆更细」：把整体任务切成子任务，每个子任务用独立窗口，窗口之间只传结构化的交接物（状态 + 产物引用 + 未决问题）；把计划与执行分离，计划固化成状态机，执行阶段只带当前步骤需要的上下文；把长数据与计算交给外部工具，模型只做决策。训练侧的长上下文外推、位置编码调整、记忆压缩模型也可以考虑，但那是最后一步，先问「这些内容是不是本来就不该进上下文」。

断点恢复的关键是状态持久化 + 每步幂等：任务 ID、当前步骤、已完成动作、中间产物、工具调用幂等键全部落库；恢复时不重放全部历史，而是用「结构化状态 + 最近观测 + 摘要」重建上下文。对外部副作用（下单、支付）要用幂等键加查询接口做对账，避免恢复时重复执行。

多 Agent 同时改同一文件，第一原则是尽量不发生真并发写：按文件或区域划分 owner，或者用单一写入者加事件队列串行化，读侧走只读快照。确实要并发时加两层保护：租约锁（带超时与自动失效，防止死锁）加乐观并发控制——写之前比对版本号或内容哈希，比对通过才提交，冲突就重读再生成补丁。变更本身要走 patch 而不是整文件覆盖，冲突无法自动合并时把差异交给上层（模型重新规划或转人工），绝不能静默覆盖——这类系统里最难查的 bug 就是「文件被另一个 Agent 悄悄改了」。

RAG 里的图片内容

图片不能当噪声丢掉，也不能只留一个文件名。入库前的预处理是：OCR 抽文字（尤其是截图、扫描件里的正文与表格）、用视觉模型生成结构化描述（画面内容 + 关键实体 + 数字）、表格转成结构化文本、图表尽量转成数据表，并把原图、页码与来源作为证据一并保留。索引侧做多路：文本向量、图像向量（CLIP/SigLIP 这类共空间模型或页面级的 late-interaction 检索）以及结构化字段，检索时多路召回后融合排序。命中图片时要把原图（或高分辨率裁剪）作为多模态输入喂给模型，而不是只喂一段 caption——caption 是有损的，关键数字和小字很容易丢。低质量的扫描件要先做增强或人工校对，否则 OCR 错误会顺着链路一路传下去。

手撕题

买卖股票的最佳时机 II 是贪心：允许无限次交易时，把所有相邻的上涨差价累加起来就是最大收益（等价于把整条曲线拆成上升段逐个吃满），一遍扫描 O(n)、O(1) 空间；注意它不是「求最大子数组和」，两次交易之间的下跌不亏钱，因为可以选择不持有。

编辑距离是二维 DP：dp[i][j] 表示把 s 的前 i 个字符变成 t 的前 j 个字符的最少操作数，转移是三种操作取最小——删除 dp[i-1][j] + 1、插入 dp[i][j-1] + 1、替换或匹配 dp[i-1][j-1] + (s[i-1] != t[j-1])；边界是 dp[i][0] = i、dp[0][j] = j。空间可以用滚动数组压到 O(min(n,m))，但要小心原地更新时被覆盖，需要额外保存左上角的值。面试时可以先确认允许的操作集（是否含替换、代价是否都为 1），因为不同定义的转移不一样。

《面试题目》

《参考解析》

相关面经