百度 AI Agent 开发二面

1. 如果让你从 0 到 1 设计一个企业级 Agent 平台,你会怎么划分 Planner、Memory、Tool、Knowledge、Runtime、Evaluation 这几个模块?边界怎么定?

我一般不会按“大模型功能”来拆,而是按“责任是否稳定”来拆。Planner 只负责决定下一步做什么,不负责真正执行;Tool 只负责把外部能力标准化,不参与推理;Knowledge 负责把文档、结构化数据、权限和索引组织成可检索资产;Memory 只存跨步、跨轮、跨会话还需要被引用的信息;Runtime 负责状态推进、超时、重试、回放和观测;Evaluation 则独立出来,不跟在线链路耦合,因为它是用来审判系统的,不能和被评估对象混在一起。这样拆的好处是,模型换了、工具换了、检索换了,系统主骨架不用重写,线上稳定性也更容易守住。

2. 如果一个系统同时要支持 ReAct、Plan-and-Execute 和 Workflow/State Machine,你会怎么做统一抽象?

我不会做三套链路,而是统一成“状态 + 节点 + 转移条件”的执行模型。ReAct 本质上是单步决策型节点,Plan-and-Execute 是先生成计划再逐步消费计划的节点,Workflow 则是转移条件更明确的显式图。它们表面上长得不一样,但底层都可以抽象成:读当前状态,决定动作,执行动作,写回状态,再判断是否结束。统一之后,差别只在决策权交给模型多少,而不是系统里存在三套完全不同的运行时。这样做最大的价值不是优雅,而是可观测、可回放、可灰度,不会出现一种模式能监控,另一种模式只能靠猜。

3. 在长链路任务里,什么步骤该交给模型,什么步骤必须收敛成规则、状态机或 DAG?

我的判断标准很简单:高不确定性、需要语义理解的环节交给模型;高风险、高约束、可穷举的环节交给规则。比如用户意图判断、问题改写、证据组织、自然语言解释,这些模型擅长;但像权限校验、金额计算、审批流跳转、是否允许调用某工具、是否允许写库,这些必须收敛成系统规则。很多 Agent 做到后面会不稳定,不是模型不够强,而是把不该开放的环节也交给模型了。二面如果这么问,重点不是讲“模型很聪明”,而是要讲清楚你知道哪里必须收口。

4. Agent 的状态到底应该存什么,不应该存什么?哪些信息该进 prompt,哪些只该存在外部状态里?

状态里应该存的是后续步骤真正要依赖、而且不能靠模型稳定复原的信息,比如任务目标、当前阶段、工具返回的关键字段、用户约束、待确认事项、异常标记。不能乱存的是中间推理废话、冗长工具原始响应、模型自己猜出来的结论。至于哪些进 prompt,我的原则是“只有当前步推理必须看到的才进 prompt”,剩下都放外部状态。因为 prompt 是运行时上下文,不是数据库;一旦把状态和 prompt 混在一起,系统就会越来越重,最后谁都说不清模型到底依据了什么。

5. 如果 Memory 系统写入了错误记忆,Agent 会越聊越错。线上怎么发现、隔离和修复这种 memory poisoning?

这个问题本质上不是“记忆错了”,而是“错误被长期放大”。线上要治理,第一步不是修,而是先能发现。所以我会给长期记忆加来源、时间、写入方式、置信度和命中日志。只要某条记忆被频繁命中,但命中后会显著拉低任务成功率、提高用户纠正率,基本就能定位到有污染风险。隔离上不能直接全删,而是做软失效,把它从默认召回集中移出去,只在强匹配时再放出来。修复上也不能单纯覆盖,因为用户今天说的话未必比系统昨天查到的真,所以我更倾向保留事件流,再刷新对模型可见的聚合画像。这样既能回溯,也不会因为一次错写把历史证据全抹掉。

6. 检索阶段召回率看起来不低,但最终答案还是错的,你怎么定位问题到底出在哪一层?

这种问题不能凭感觉查,必须把链路拆开做归因。先看召回结果里有没有“理论上足够答对”的证据,如果没有,那问题在 chunk、embedding、召回融合或者 query 改写;如果有,但 rerank 没把它排上来,那问题就在排序;如果 rerank 也排上来了,但最终上下文没带进去,那就是 context packing 的问题;如果证据已经进了 prompt,模型还是答错,那才轮到 generation 或指令约束问题。很多人一看答案错了就去调 prompt,这是最常见的误诊。真正成熟的系统要能把每一层的输入输出都留痕,不然你连错在哪里都不知道。

7. 如果你只能保留一次 rerank,你会把它放在检索后、上下文组装前,还是答案生成后做 evidence check?为什么?

我会优先放在检索后、上下文组装前。因为大多数错误都是“错证据进来了,正确信息没进去”,这一步不拦住,后面再做答案校验已经晚了。生成后的 evidence check 更像补救措施,它能发现一些明显无依据的结论,但它解决不了“模型根本没看到关键证据”这个核心问题。线上资源有限时,一次高质量 rerank 比一次事后纠错更值钱,因为它同时影响答案正确率、上下文质量和 token 成本。

8. 你怎么理解“超长上下文会削弱 RAG 必要性”这句话?它在哪些场景成立,在哪些场景不成立?

这句话只对一半。超长上下文确实会降低“为了塞更多文档而做 RAG”的必要性,但不会降低“为了找准证据、控成本、做权限隔离、做可引用回答”而做 RAG 的必要性。也就是说,如果问题规模不大、文档集合相对固定、实时性要求低,那长上下文确实能吃掉一部分原本靠检索解决的问题;但在企业场景里

剩余60%内容,订阅专栏后可继续查看/也可单篇购买

AI-Agent面试实战专栏 文章被收录于专栏

本专栏聚焦 AI-Agent 面试高频考点,内容来自真实面试与项目实践。系统覆盖大模型基础、Prompt工程、RAG、Agent架构、工具调用、多Agent协作、记忆机制、评测、安全与部署优化等核心模块。以“原理+场景+实战”为主线,提供高频题解析、标准答题思路与工程落地方法,帮助你高效查漏补缺.

全部评论

相关推荐

百度日常实习面试经验分享 | 智能云数据平台部📋 面试概览岗位:日常实习部门:百度智能云 - 数据平台部流程:一面 → 二面 → HR通知(一天内完成)结果:✅ 通过体验 :面试官很nice,流程高效🎤 一面(约60分钟)项目深挖(约40分钟)简历上的项目问得很细,每个点都会追问:原理是什么?有没有考虑过其他方案?为什么选这个方案?💡 建议:对自己的项目要非常熟悉,每个技术选型都要有理由。八股文CSS相关display:none vs visibility:hidden标准盒模型 vs 怪异盒模型什么是 BFC两栏布局的实现JavaScript基础基本数据类型 & 引用类型ES6 引入的新类型Map vs Set 的区别Map vs Object 的区别Symbol 的作用⚠️ 踩坑记录:Map和Set的区别我说成了"允许重复",面试官追问是什么重复,我发现说错了赶紧改口。大家要注意:Map是键值对,键唯一;Set是值集合,值唯一。React相关用过的Hooks有哪些useRef 的作用useMemo 的使用场景Hooks 的作用useContext 的作用工程化模块化规范及区别CommonJS vs ES ModuleAI相关问题实习中如何使用AI?提到了 Skills 和平时使用的技能个人网站搭建的 Agent 项目大概讲了搭建流程反问环节问了团队技术栈、实习生培养机制等。🎤 二面紧张到忘记录音了,只能回忆一些碎片项目深挖依旧是项目拷打面试官超级好,还给我的项目提了一些改进建议!八股文type vs interfaceES模块相关问题React 什么时候不用 useCallback/useMemoAI深度问题用AI做了些什么Agent Function Calling 的作用开放题:Agent更需要MCP还是Skills?灵魂反问因为感觉八股回答得不太好,所以问了:"我的简历和面试有什么需要改进的?"结果面试官反问我:"你觉得在当下的时代,基础更重要还是对AI的把握?"面试官的反馈"你的简历可能不太好,但是能力很不错,要是你能来公司会给你回答你刚刚的问题。"✅ 面试结果很快就收到了HR的电话通知:通过了!整体来讲:✅ 流程很快✅ 过程体验很好✅ 虽然是日常实习但感觉很好🏢 关于部门百度智能云 - 数据平台部有了解的uu可以说一下这个部门怎么样嘛~
拒绝pua的可乐很想...:接好运
查看25道真题和解析
点赞 评论 收藏
分享
评论
点赞
13
分享

创作者周榜

更多
牛客网
牛客网在线编程
牛客网题解
牛客企业服务