OPPO 小布助手 AI Agent 一面面经：被问懵的 30 分钟与复盘建议

《面试题目》

1. 在之前的对话系统里，做过哪些跟工具调用或外部 API 交互的设计？
2. 如果用户问「明天适合跑步吗」，你的系统需要调用哪几个数据源？调用顺序怎么定？如果其中一个数据源返回空值，兜底策略是什么？
3. 在你看来，一个能完成复杂任务的 AI Agent，最核心的环节是什么？
4. 规划出错时，模型怎么发现？靠结果反馈还是靠规则？如果结果反馈也有延迟怎么办？
5. 校验层放在哪一端？端侧还是云端？如果网络抖动导致工具超时，你的状态机怎么处理？
6. 场景题：请拆解「帮我订周五下午从深圳到上海的机票，避开红眼航班，并同步到日历」这套系统设计。如果用 Agent 来做，你的执行器、规划器、记忆模块分别承担什么？
7. 为什么不用单次模型调用直接生成？判断是否需要拆成多步任务的标准是什么？
8. 你怎么量化复杂？三步算复杂还是一步算复杂？模型自己判断还是你预设阈值？
9. 小布助手跑在手机端，端侧如何裁剪、如何做推理加速？

《参考解析》

先说这场面试为什么难。 节奏快只是表象，真正的压力来自面试官一直在问「系统怎么串起来」，而不是「你知不知道这个概念」。把 Agent 等同于「大模型加插件」是答题崩掉的起点：插件只是工具层，面试官要的是规划、执行、记忆、评估四块怎么配合，出错时谁兜底、状态存在哪、延迟与成本怎么权衡。候选人自述的三个盲区很典型：没从系统架构层面理解智能体，只背了云端方案而没准备端侧约束，以及讲失败案例时只会说「效果提升了不少」而拿不出指标和 badcase。准备同类岗位时，把简历里每个项目都用「输入 → 规划 → 执行 → 反馈 → 评估」的框架讲一遍，并能在白板上画出模块之间的数据流，体感会完全不同。

工具调用的编排与空值兜底。 「明天适合跑步吗」考的是多数据源编排：通常需要三类数据源——天气（温度、降水、风力、空气质量）、定位（用户当前或常驻城市）与用户画像（跑步偏好、既往运动记录）。顺序上先做意图与槽位确认，再把相互独立的数据源并行拉取（天气与定位可并行，画像本地读取），因为并行能把端到端延迟从累加变成取最大。空值兜底分三种情况答：一是数据源超时或报错，重试一次后降级，并在回答里明确告知「暂时拿不到天气数据」；二是数据源正常返回但字段缺失（比如没有空气质量），用规则补齐默认值，或退化成「有条件的结论」；三是必要槽位缺失，宁可反问用户（哪个城市、什么时间）也不要编一个天气出来。核心原则是工具失败不静默：降级要标记、要写日志、要对用户可见，否则用户会把编出来的结论当真。

规划出错靠什么发现。 只靠结果反馈既不够快也不够准，工程上是三层叠加。第一层是确定性校验：工具入参用 schema 与业务规则卡死（日期不能是过去、城市必须在白名单、金额有上限），不合法直接拒绝，并把结构化错误回灌给规划器重排。第二层是每步之后的结果校验：检查工具返回是否满足子任务的成功判据（航班列表非空、时间落在周五下午），不满足就把「缺什么、建议补哪一路」结构化地交回去，而不是让模型自由换方向乱试。第三层才是端到端反馈与离线评测，把线上 badcase 回流成评测样本。结果反馈有延迟时，靠的是显式状态加预算：每步有超时与最大重试次数，全流程有最大步数与 token 预算，触顶就终止并如实说明哪一步没完成——不要指望模型自己意识到错了。

校验层放端侧还是云端。 判断标准是延迟敏感度、数据敏感度与算力成本三者的取舍。延迟敏感、涉及隐私、且能用规则或小模型判的校验（槽位合法性、意图置信度、敏感内容前置拦截、工具参数 schema 校验）放端侧；需要大模型语义判断、跨轮一致性、以及要联网才知道的信息放云端。要避免的是同一次校验两头各做一遍——延迟翻倍，还容易出现两头规则不一致导致行为漂移。网络抖动导致工具超时的状态机处理，要点有四条：每个工具调用是一个独立状态（pending / success / timeout / failed），状态机可持久化、跨重启能恢复；超时只重试幂等操作，查询类可重试，「下单」「发消息」这类写操作必须带幂等键，不能盲重试；超时后不能永远停在 pending，要有明确的降级分支；每次重试要退避并限次数，避免抖动时把上游打垮。

「订机票并同步日历」怎么拆。 单次模型调用做不了的原因有三条：需要多步；步骤之间有明显的数据依赖（航班落地时间决定日历事件的起止）；并且包含不可逆的外部副作用（下单、支付、写日历），需要确认与幂等保护。所以拆成多步的判断标准不该是「三步还是一步」，而是三条可判定的性质——是否需要外部状态反馈、子任务之间是否有数据依赖、是否存在不可逆副作用，满足任意两条就值得做成显式工作流，其余情况一次调用加工具循环更简单也更便宜。被追问「怎么量化复杂」时可以这样答：用需要的工具调用次数、跨工具的数据依赖边数、以及是否包含写操作三项打分，阈值由离线评测扫出来（例如依赖边不少于两条、或含写操作就强制多步），模型可以参与判断，但阈值与约束要由工程侧设定并版本化。分工上，规划器负责把模糊目标拆成有序子任务并决定每步查什么，执行器只负责单步执行并产出带证据的结果，记忆模块负责跨轮的事实、偏好与硬约束（周五下午、避开红眼、常用出发地），并承担「已确认的事实不再重复询问」的职责。

端侧部署这一问不能空。 小布助手跑在手机端，延迟、内存、耗电与模型量化都是绕不开的约束。合理的答法是按链路分层：意图识别、槽位抽取、敏感词与合规前置拦截放端侧，用规则或小模型完成；需要大模型推理的规划、复杂语义校验与联网信息查询放云端；断网时退化成基础可用能力（离线指令、本地知识），而不是整条链路不可用。端侧模型常用量化（int8/int4）、蒸馏、算子融合与 KV 缓存复用来做推理加速，代价是准确率下降，所以端侧与云端的边界必须由离线评测决定，并按机型分档（高端机跑大一点的模型、低端机降级），同时用端侧日志把降级比例、延迟分布与失败类型采回来，形成「端侧观测 → 云端评测 → 模型与阈值迭代」的闭环。被问到不会的部分时，直接说「这块我理解不深，但我会从某个角度尝试拆解」比硬编一个答案稳得多。