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

查看5道真题和解析