OPPO小布助手AI Agent一面面经

《面试题目》

1. 自我介绍。
2. 你这个 AI Agent 项目的建设背景、落地方案、最终成果是什么？
3. Agent 流程较长，你们做了哪些保障措施让每一步按预期推进？
4. 长任务场景大模型容易产生幻觉，项目中是否遇到过？
5. 针对幻觉问题，你们采用什么方案解决？
6. 置信度通过什么规则、约束来判断？什么情况需要二次确认用户？
7. 多 Agent 交互、推理多导致上下文膨胀，上下文处理相关机制你了解吗？
8. LangChain、LangGraph、原生手写 Agent 三者区别和优劣势是什么？
9. 如果不使用框架，原生实现 Agent 你写过吗？使用框架的优劣势是什么？
10. 你在滴滴实习实际参与的是哪些项目？是偏底层基础研发吗？
11. 如果要保障系统线上稳定性，会有哪些落地思路和方案？
12. 结合简历提到的自动化运维、监控告警，相关体系是如何做的？
13. 你们团队目前对 AI 的投入和使用程度高吗？
14. 基础架构团队不能大面积使用 AI，要做到什么程度才可以信任 AI？
15. 你判断 AI 会对日常工作、产品业务形态带来什么影响？
16. 讲解下拿到缓存一致性验证项目，和 AI 交互完成开发的完整过程。
17. 这个缓存一致性项目最终结果如何？
18. 项目的测试用例是你给出场景约束让 AI 生成，还是 AI 自己产出？
19. 这些异常测试场景，是你告知 AI，还是 AI 自行想到的？
20. 项目中是否涉及知识库建设？
21. 产品迭代更新后知识库容易老旧，知识库如何保鲜、保证准确度？
22. 抛开 Agent 项目，日常交付、工作中 AI 是如何做提效、融入工作流程的？
23. 日常工作中是否会有代码编写、需求交付类工作？
24. 你本地搭建 Agent 工作流，还是团队有统一工作流平台？
25. 本地 Agent 工作流遇到异常、边界场景，有没有专门设计处理机制？
26. 对大模型底层原理、传统架构了解多少？
27. 站在交易业务角度，交易流程最核心关注哪些点？
28. 交易系统是直接对接三方支付，还是有统一支付团队做封装？

《参考解析》

长流程 Agent 的保障机制。「检查点 + 校验器 + 目标锚定」是三件互相补位的事。检查点解决的是可恢复：每完成一个子任务就把状态快照落 Redis，快照里写清「已完成步骤、中间结果、下一步计划、已执行过的动作集合」，进程挂掉后从最近快照续跑，而不是从头重来。校验器解决的是可判定：每个子任务的输出分两层校验，规则层看格式与必填字段，语义层用模型判断结论是否真的回答了子任务、证据是否充分；不通过就打回重试，并规定最大重试次数（比如 3 次），超限就转人工或降级回答，绝不无限循环。目标锚定解决的是不跑偏：每一步的 prompt 里都重申原始目标与当前子任务，因为长上下文里模型很容易被中间步骤带跑，执行到第三步就忘了用户最初要什么。这三件事的共同点是都不依赖模型自觉，而是用代码把状态和边界显式化。

幻觉治理与置信度。幻觉的共性是「模型在信息不足时倾向于编造而不是承认不知道」，所以防护要分层，单靠 prompt 一定漏。Prompt 层最便宜：系统提示里明确要求「检索结果不包含答案时回答无法确定，不要编造」，但只能降低概率。检索层是主力：对召回结果做置信度过滤，相似度低于阈值的不注入上下文——模型没有素材就编不出来，同时要保证检索结果带来源与时间。校验层是兜底：生成后做事实核查，把答案里的关键论断逐条与检索到的原文比对，出现检索结果里没有的信息就标记可疑、重新生成或拒绝回答；同一事实在不同来源冲突时按来源可信度选择，而不是按多数票。置信度要来自硬信号而不是模型自报——模型自报的 confidence 常常「很自信地犯错」，只做参考；可用的信号是检索相似度、多模型回答的一致性、以及工具返回的客观结果（查询是否返回非空结果集、接口是否返回成功码）。二次确认按风险定：涉及资金、权限变更、不可逆操作，或综合置信度低于阈值时强制人工确认。

上下文膨胀的治理。多 Agent 协作时，每个 Agent 的对话历史、工具调用记录、中间推理结果都会累积，十几步就可能顶到窗口上限。可行做法是分层：短期用滑动窗口保留最近 N 轮，保证当前任务的连贯性；溢出的部分做结构化摘要，把实体、事件、结论、待办分开存，其中实体和结论保留原文（关键数字、ID、引用一旦被「摘要」就再也找不回来，这是最容易踩的坑），事件和待办用简短描述；长期记忆落向量库，需要时按需检索召回。压缩的本质是拿「信息密度」换「token 成本」，所以任何压缩方案都要能回答两个问题：丢了什么、丢了之后任务成功率有没有下降。

框架选型的判断。LangChain 是链式编排，生态最全、上手最快，适合原型验证，但抽象层厚，线上出问题常常要面对自己没写过的代码。LangGraph 是图状态机，显式描述节点与边，支持条件分支、循环和 checkpointer 状态持久化，复杂多 Agent 协作更合适。原生手写就是自己实现 Agent Loop、工具注册与状态管理，核心循环代码量不大，但 checkpointing、流式输出、human-in-the-loop 都要自己搭。取舍逻辑是：核心 Loop 自己写（异常捕获、重试策略、终止条件必须完全可控），外围设施用框架。用框架最典型的坑是「框架内部悄悄重试了三次却没告诉你」，于是排查时误以为是工具的问题——所以选型之后第一件事是把框架的重试、超时、日志行为弄清楚。

线上稳定性与自动化运维。稳定性按预防、检测、恢复三层组织。预防靠代码审查、测试与灰度发布——灰度是关键，先放 5% 流量观测再全量，出问题时影响面小、回滚快。检测靠监控告警，核心指标是 P99 延迟、错误率、QPS、资源使用率，阈值要动态调整，并用告警收敛（相关告警合并成一条）来治「告警疲劳」。恢复靠熔断、降级、重试、限流：熔断连续失败超阈值就切断、过段时间半开试探；降级分层（切备用模型 → 从 Agent 降到固定 Workflow → 返回友好错误）；重试用指数退避加全局限流；再叠一层背压，队列超阈值就拒绝新任务并明确告知排队情况。自动化运维的落点是自动分级（按影响面打 P0/P1/P2 并选不同通知通道）、自动诊断（告警后自动拉指标、日志、变更记录并匹配历史案例）、自动恢复（已知故障模式自动重启或清理，失败转人工）——每条自动恢复都必须可回滚、有兜底。

AI 参与开发的信任边界。判断标准可以归成三条：可验证（AI 产出的代码有测试覆盖、配置有校验规则、结论有事实核查，没有验证手段的产出不进主干）、可回滚（任何改动都留旧值，一键还原）、有兜底（AI 失败有人工接管路径）。所以工程上合理的分工是 AI 做「建议」、人做「决策」：让它生成测试模板、代码草稿、日志分析角度，但合入前必须人工 review，执行修复的仍然是人。缓存一致性验证那个项目就是典型：让 AI 按「并发写、并发读写、缓存过期、缓存击穿」等大类填充用例效率很高，但它天然偏向正常路径，网络分区、主从切换这种需要理解分布式机制的异常场景要人先列清单再让它补；断言逻辑也必须人工校验。知识库同理，建设时要把「故障现象、根因分析、解决方案」结构化分开存，否则检索命中之后模型读不懂哪句是原因哪句是方案；保鲜要靠增量更新（按 content-hash 只重算变更部分，而不是每次全量重建）、时间衰减权重、以及定期跑「知识新鲜度」检查比对最新文档。交易系统关心的一致性、幂等性与可追溯性也是同一套思路：钱货对不上、重复扣款、链路不可查都是硬伤；支付是自建网关还是由统一团队封装，取决于渠道变更成本与合规成本哪个更贵。