理想汽车智能体应用开发一面：Agent 路由与项目深挖

《面试题目》

1. 你做过的项目里面哪个挑战最大？讲清楚：业务背景、问题、你的方案、输出结果、最有技术含量的点。
2. Agent 路由是怎么做的？LLM 打分、关键词分类还是规则表？具体怎么做的？
3. 如果用户一句话跨两类场景，路由是怎么处理的？任务是串行的还是并行的？
4. 有没有出现纰漏的开发经历？具体是什么问题？
5. 介绍一下论文，可以做什么迁移？

《参考解析》

「最有挑战的项目」怎么讲，尤其是最后一问

这题是加强版的 STAR，难点在「最有技术含量的点」——面试官问的是判断力，不是流程复述。可以这样组织：业务背景一句话讲清场景、量级与硬约束；问题和它为什么难（之前的做法为什么不行，卡在延迟、成本还是准确率）；方案里必须交代选择了什么、放弃了什么，比如没有上多智能体，因为编排复杂度换不来准确率提升；结果尽量给可量化的对比（指标前后、上线范围、有没有真的被人用起来），拿不到数字就说清你是怎么验证的；最后把技术含量单独挑一个点讲透，比如把路由从纯 LLM 打分改成规则前置加小模型兜底，在保住覆盖率的同时把长尾延迟压下来。

要避开的坑：只讲业务流程不讲取舍、把团队成果说成自己的、技术点停在名词层（「用了 RAG」）而说不出检索与重排策略、失败兜底怎么做。

Agent 路由的几种实现与取舍

常见四类：① 规则与关键词匹配，最快最便宜、完全可控可解释，但泛化差、规则会越堆越多；② 小模型或分类器（embedding 相似度、微调的分类头），延迟低、可离线评测，适合意图集合稳定且量大的场景，代价是要标注与持续迭代；③ LLM 打分或函数调用，泛化最好、能处理长尾与组合意图，但延迟和成本高、输出不稳定，要用枚举约束加校验重试兜住；④ 混合方案，先用规则和缓存挡掉高频请求，再用分类器分流，置信度低于阈值的才交给 LLM。

工程上要能说清：路由的目标不是「选对唯一答案」，而是在延迟与成本预算内把请求分到正确的处理链路，所以必须配置信度阈值、兜底链路（走通用 Agent 或先澄清提问）和一套离线的路由评测集来观察准确率与混淆情况。同一句请求的路由结果也适合缓存，省掉重复的模型调用。

一句话跨多类场景：多标签、编排与部分失败

用户一句话覆盖两类意图时，路由就不该输出单标签。两种处理思路：一是串行，先做意图分解（让模型输出结构化的任务列表），再按依赖排序逐个执行、上游结果作为下游输入，适合有先后依赖的任务；二是并行，子任务互不依赖时并发发起再由模型归并，用一句话统一呈现。判断依据是子任务之间有没有数据依赖和资源冲突，而冲突恰恰是坑——两个子任务都要写同一个订单、同一份日程时，并行会互相覆盖，必须有互斥或者退回串行并做冲突检测。

还要设计部分失败的语义：一个子任务失败时是整体回滚，还是返回可解释的部分结果加明确的失败项，取决于业务能不能补偿——只读查询可以给部分结果，涉及写操作就要有事务或补偿逻辑。被追问「串行还是并行」时，把依赖判断、资源冲突、失败语义这三层说全，深度就够了。

「开发纰漏」怎么答

行为面里最容易翻车的题：既不能答「没有」，也不能甩一个让人怀疑基本功的大事故。安全的框架是选一个边界清晰、后果可量化、你已经闭环的问题：现象（线上异常、用户反馈或评测指标掉了）→ 定位（怎么发现的，靠日志、指标还是复现路径）→ 根因（假设错了、漏了边界条件、还是没有幂等）→ 修复与机制（不只改那一行，还加了什么校验、监控、回归用例）→ 现在的做法有什么不同。

要点是主动讲出你从中学到的具体规则，比如「凡是会重试的写操作都要带幂等键」「上线前按真实数据量级压一遍」。避免两个极端：把责任推给环境或上游，以及用「粗心」这种没法改进的解释收尾。

论文怎么谈迁移

这题考的是能不能把研究和落地连起来，答案要具体到「哪一部分能搬、搬过去会遇到什么」。通常可迁移的是三类：方法与建模（更省样本、更稳的训练或对齐方式）、评测思路（怎么构造离线评测集、指标与置信度怎么定）、可工程化的模块（数据清洗、检索与重排、输出后处理约束）。同时要主动说出差距：学术设定里数据与算力可控、指标单一，工程里是长尾分布、延迟与成本硬约束、还要求可解释可回滚。

稳妥的表述是给一条明确的迁移路径加一个最小验证实验——先说把某个思路用在哪个环节，再用现有流量做小流量对照看指标，而不是笼统地说「可以应用到工业界」。