腾讯大模型应用开发二面

Jul 25, 2026

正文

#面试 #面经 #AI #agent #实习

#面试 #面经 #AI #agent #实习 #作者

长图内容（视觉重读）

1. 如果让你设计一个 Agent 的规划器，怎么避免它每一步都重新规划，导致路径震荡？

规划器不能每拿到一个 observation 就整体重算，不然很容易出现前一步刚决定检索、后一步又改成总结、再下一步又回去检索，整个执行路径来回抖动。更稳的做法是把规划分成"全局计划"和"局部调整"两层：全局计划只定义阶段目标（如信息收集、证据校验、结果生成），局部调整只允许在当前阶段内微调具体动作。另外要给 planner 一个明确的状态表示，比如当前子目标、已完成步骤、失败原因、剩余预算——没有状态约束，模型会把每次新 observation 当成全新任务来理解。线上一般还会加"重规划阈值"，只有在关键前提失效、连续失败或用户目标变化时才允许重规划，这样路径会稳定很多。

2. 如果一个 Agent 需要同时读知识库、调外部 API、再结合用户历史偏好回答，你怎么处理这三类上下文的优先级？

三类信息不能混着喂，要先定义优先级：系统规则最高，其次是当前轮用户明确输入，再往下是外部工具返回和知识库证据，用户历史偏好通常最低——偏好只能影响表达方式或默认选择，不能覆盖当前轮事实。比如用户历史一直偏好 Python，但这轮明确说"用 Java 给我写"，当前轮约束一定优先；知识库是旧规则、外部 API 返回实时状态时，实时状态优先于静态知识。做 prompt 组装时最好按槽位拼接，把"当前目标 / 实时证据 / 历史画像"分开，而不是混成一段自然语言。

3. 你怎么理解 Agent 里的"状态"而不是"上下文"？

上下文是模型看到的输入材料，状态是系统对任务推进过程的结构化刻画。Agent 做深之后不能只靠大段对话历史维持执行，因为模型并不天然擅长长期状态一致性。状态通常包括当前阶段、已完成子任务、失败次数、已调用工具、关键中间结果、待确认信息。好处是模型不用每次从自然语言里猜任务进行到哪一步，系统可以明确告诉它现在在什么节点。很多所谓 Agent 不稳定，本质上不是上下文不够，而是没有显式状态。

4. 如果 RAG 召回了很多相互矛盾的文档，Agent 应该怎么处理，而不是直接让模型自己总结？

不能把矛盾文档一股脑丢给模型让它自己"综合"，那样容易生成一个看起来圆滑但实际上没有依据的答案。更合理的做法是先做证据归一化和冲突检测：先按来源、时间、可信度分组，再抽取同一个字段的不同取值，看冲突是时间差异导致的，还是来源本身互相打架。时间敏感信息通常新版本优先；来源权威性不同则官方文档优先；仍无法消解就明确告诉用户存在冲突，并说明目前更可信的依据是什么。Agent 在这里更像证据调解器，而不是万能总结器。

5. 如果工具调用是成功的，但返回结果语义不完整，模型很容易误判，你怎么设计中间层？

很多工具从接口层面看是 200 成功，但业务语义上其实不够用——比如只返回了一个 code 没有解释信息，或者字段含义不清，模型会自行脑补。解决方式一般是加一个 tool adapter 或 semantic wrapper，把原始结果转成统一、可解释的中间表示：不要把外部 API 的脏数据直接回喂给模型，而是先在中间层做字段补全、错误码翻译、单位归一、空值处理和置信度标注。这样模型看到的是"可推理对象"，而不是原始接口垃圾。

6. 一个 Agent 系统里，什么时候应该追问用户，什么时候应该自己继续推理？

判断标准主要有两个：信息缺口是否影响正确执行，以及这个缺口能不能通过工具或外部知识补上。缺执行必需参数（比如查订单必须要订单号）就应该追问；缺的是可由外部系统补齐的背景信息（比如天气查询里城市能从用户画像里拿到）可以自己继续推理。还有一种情况是虽然能猜但猜错代价很高，比如支付、发送、删除这类动作，一般宁愿追问也不要擅自补全。追问不是因为模型不聪明，而是系统要在体验和风险之间做平衡。

7. 如果模型特别擅长生成，但不擅长严格遵守流程，你会怎么把它放进一个强约束工作流？

最常见的办法是把"生成自由度"和"流程控制权"拆开：模型只负责局部判断和内容生成，流程推进由外部状态机控制。比如工作流规定必须先做参数校验、再检索知识、再调用工具、最后生成答复，模型不能跳步，能做的只是当前节点下的判断（例如"检索关键词怎么改写""看到这些证据后怎么总结"）。这样模型仍然发挥语言理解优势，但不会破坏整体流程。真正线上稳定的 Agent 很多都不是纯模型自治，而是"系统控流程，模型控局部智能"。

8. 你怎么设计 Agent 的失败恢复机制？

失败恢复不能只理解成"报错后重试"。Agent 的失败通常分几类：工具超时、参数错误、依赖数据缺失、模型误判、外部系统状态变化，不同类型恢复方式不一样——临时性错误（如接口超时）可以限次重试；参数缺失就回到追问节点；模型连续选错工具就触发降级策略（比如改成规则路由或人工兜底）；外部系统不可用就及时终止并返回清晰失败原因。恢复机制一定要和状态机绑定，不能让模型自己"觉得应该再试一下"，不然容易进入无穷重试。

9. 怎么判断一个 Agent 该做成单 Agent，还是多 Agent？

关键不是任务听起来复不复杂，而是能力边界是否清晰、上下文是否容易污染、以及是否存在天然并行。整个任务虽然长但上下文高度统一，单 Agent 加状态机通常就够了；任务里包含明显不同的专业能力（一个负责代码修改、一个负责合规审查、一个负责数据分析），拆成多 Agent 更清晰。多 Agent 的好处是职责分离、上下文隔离、局部优化方便，但成本更高，要处理通信、调度和一致性。不是越多 Agent 越高级，很多场景单 Agent 反而更稳，只有在"拆开了明显比揉在一起更好管"的时候才值得做。

10. 你觉得 Agent 在线上最难监控的指标是什么？

最难监控的不是延迟和成功率（这些容易打点），而是"表面成功但实际决策错误"：工具调用全成功、答案也返回了，但它选错了工具、用了次优证据、或者本来该追问却没追问，这类问题不会体现在传统监控指标上。所以 Agent 监控不能只有系统指标，还要有决策质量指标：工具选择正确率、重复动作率、无效步数占比、需要追问却未追问的比例、最终答案证据覆盖率。这些指标更难做，但没有它们，线上看起来一切正常，用户体验却会持续变差。

11. 如果让你做一个"可审计的 Agent"，你会保留哪些信息？

可审计不是简单把聊天记录存下来，而是要能还原"它为什么这样做"。至少要保留：用户输入、系统 prompt 版本、工具候选集、最终工具选择、调用参数、工具返回、状态变迁、模型输出和最终结果；做得更完整还要带上模型版本、知识库版本、检索到的文档 ID、rerank 结果和 trace_id。这样线上出了问题，才能准确回放是 prompt 变了、知识库变了、模型变了还是工具变了。真正的审计目标不是"存档"，而是"能追责、能定位、能复现"。

12. 为什么很多 Agent Demo 很惊艳，但一上线就不稳定？

Demo 往往是在理想输入、有限工具、单次任务和短上下文下演示的，模型只要看起来会做事就行。但线上环境完全不一样：输入脏、任务长、工具多、状态复杂、异常频繁，还要考虑权限、安全、性能和成本。Demo 能跑通只能说明"这个方向有戏"；上线稳定说明的是你把模型的不确定性关进了工程笼子里。真正难的是做治理，不是做演示。很多团队一开始觉得问题在模型不够强，后来才发现大量问题其实来自状态管理、工具设计、上下文污染和缺少回放能力。

13. 你觉得二面和一面在 AI Agent 方向上最大的区别是什么？

一面很多时候还会看你知不知道概念，比如 RAG、Tool Calling、Memory、Multi-Agent 这些名词你能不能说清。二面通常就不满足于名词解释了，它更想知道你能不能把这些东西真正落到系统里——会追着问边界条件、失败案例、线上治理和设计取舍。不是问你"会不会"，而是问你"为什么这么做，不这么做会出什么问题"。如果答的时候一直停留在定义层面，二面一般很容易被看出来。