面灵AI→

理想汽车智能应用研发一面:Agent 意图路由与 AI 手撕四数之和

轮次
一面
时间
2026-10
来源
牛客网

《面试题目》

  1. 先简单做个自我介绍。
  2. 你的经历主要是在滴滴实习吗?
  3. 滴滴这个项目主要是做什么的?你在其中参与了哪些部分?
  4. 你在 Agent 方面具体做了什么?这个 Agent 主要给用户做什么?
  5. 没有 Agent 前是用户手动分析,有了 Agent 后是辅助用户,这样理解对吗?它具体能帮用户做什么?
  6. 你主要参与意图识别这个路由环节吗?意图分哪几类,分别对应什么流程?
  7. 这些流程是不同的吗?这个 Agent 是一次查询吗?分类用的是什么模型?
  8. 分类过程本身是 Agent 还是 Query?有没有想过不做分类,直接走完整流程?
  9. 后面的主要流程你了解吗,还是只做意图识别?
  10. 资产查询需求中你主要优化了什么?
  11. 你平时用 AI 多吗?主要用哪些?有什么让生成质量更好的经验?
  12. 你说的 SDD 是什么?平时都用子 Agent 做开发吗?
  13. 说说你对 Agent 的理解:基本工作原理和主要组成部分是什么?
  14. 手撕题:四数之和。
  15. 你本地有 AI 吗?让 AI 实现,要求一次通过。
  16. 让 AI 生成执行脚本,并直接生成 AC 代码或证明能跑通。
  17. 你用的 5.3 是哪个供应商的?
  18. 校园招聘项目接入飞书、微信、钉钉后能在飞书上聊吗?基于 Spring Boot、Spring AI 构建的吗?

《参考解析》

意图识别与路由:先分清「分类」和「执行」是两层。路由层通常用轻量方案:小参数模型 + 结构化输出(function calling 或 JSON schema 约束),或者 embedding + 相似度召回加规则兜底,成本低、延迟在百毫秒级、标签可控;执行层再用大模型或专用工具链。面试官追问「为什么不直接走完整流程」,答法是权衡三条:一是成本与延迟,每次请求都带全量工具定义和长上下文,token 和响应时间都翻几倍;二是准确率与可控性,意图先收敛到有限集合,每类流程的提示词、工具集、校验规则可以分别调优,出错也容易定位;三是可评测,分类是确定性标签,能算混淆矩阵,端到端链路很难归因。再补一句混合思路:不设硬分类,让模型同时输出「最可能的意图 + 置信度」,低置信度走通用 Agent 循环兜底,这样既不丢长尾需求,也不让主链路跑偏。

Agent 的基本原理与组成:一句话是「让大模型在循环里调用工具、根据结果修正下一步」。组成可以拆四块:模型负责理解与决策;工具层(function calling / MCP)负责真正查数据、调接口、写文件,把模型的能力边界从文本扩到动作;记忆分短期(当前会话上下文、任务中间状态)和长期(向量库或结构化存储沉淀的用户偏好与历史结论);规划与执行循环负责把目标拆成步骤、按 ReAct 的「思考—行动—观察」迭代,直到满足终止条件。工程上还要加三样才算能上线:护栏(权限、参数校验、敏感操作二次确认)、可观测(每步的输入输出与耗时都要有 trace)、终止与预算控制(最大轮数、超时、token 上限),否则一个死循环就能把额度和用户耐心一起烧完。

用 AI 手撕算法题:四数之和的标准解法是排序 + 两层循环 + 双指针,复杂度 O(n³)。排序后固定前两个下标 i、j,剩下区间用左右指针向中间收,和偏小移左指针、偏大移右指针;三处去重要写全——i 与 j 跳重复、左右指针命中后各自跳过相同值。剪枝能显著提速:当前四数最小和已大于 target 就 break,当前四数最大和仍小于 target 就 continue;求和用 long 接,避免大数溢出。用 AI 一次过的关键在把约束喂全:明确语言与函数签名、要求先排序双指针、要求处理重复答案与溢出、要求给出复杂度,再让它附带一段暴力对拍脚本,用随机小数据比对结果。拿到代码后自己在本地跑样例与对拍,把跑通的输出贴给面试官——「能证明跑通」比「看起来对」有说服力,被追问时也能讲清每一步为什么这么写。

Spring AI 接入多渠道:能在飞书上聊,前提是做一层渠道适配而不是给每个渠道写一套业务。做法是定义统一的消息模型(会话 id、用户 id、渠道类型、文本/图片/卡片内容),每个渠道一个 adapter 负责两件事:入站把 webhook 事件转成统一消息,出站把回复转成该渠道的格式再调它的发送接口。三个渠道的差异点集中在接入侧:飞书要回 challenge 验签并处理事件加密,微信要处理 XML 与 5 秒重试,钉钉要拿 access_token 且有频率限制;共同点是回调必须快速 ack(3 秒内),真正的模型调用放到异步队列里做,再用 event_id 做幂等去重,否则平台重推会导致重复回答。基于 Spring Boot + Spring AI 是很自然的组合:Spring AI 提供 ChatClient、工具调用与向量库的抽象,业务侧只依赖这层抽象,换模型或换渠道都不用动核心逻辑。