腾讯 大模型应用开发 二面
1. 如果让你设计一个 Agent 的规划器,怎么避免它每一步都重新规划,导致路径震荡?
规划器不能每拿到一个 observation 就整体重算,不然很容易出现前一步刚决定检索,后一步又改成总结,再下一步又回去检索,整个执行路径会来回抖动。更稳的做法是把规划分成“全局计划”和“局部调整”两层。全局计划只定义阶段目标,比如信息收集、证据校验、结果生成;局部调整只允许在当前阶段内微调具体动作。另外要给 planner 一个明确的状态表示,比如当前子目标、已完成步骤、失败原因、剩余预算。如果没有状态约束,模型会把每次新 observation 当成全新任务来理解。线上一般还会加“重规划阈值”,只有在关键前提失效、连续失败或者用户目标变化时才允许重规划,这样路径会稳定很多。
2. 如果一个 Agent 需要同时读知识库、调外部 API、再结合用户历史偏好回答,你怎么处理这三类上下文的优先级?
这三类信息不能混着喂,要先定义优先级。通常系统规则最高,接下来是当前轮用户明确输入,再往下是外部工具返回和知识库证据,用户历史偏好通常最低。因为偏好只能影响表达方式或默认选择,不能覆盖当前轮事实。比如用户历史里一直偏好 Python,但这轮明确说“用 Java 给我写”,那当前轮约束一定优先。又比如知识库里有旧规则,外部 API 返回的是实时状态,那实时状态优先于静态知识。真正做 prompt 组装时,最好按槽位拼接,把“当前目标”“实时证据”“历史画像”分开,而不是混成一段自然语言。
3. 你怎么理解 Agent 里的“状态”而不是“上下文”?
上下文更像模型看到的输入材料,状态则是系统对任务推进过程的结构化刻画。Agent 做得深一点以后,不能只靠大段对话历史维持执行,因为模型并不天然擅长长期状态一致性。状态通常包括当前阶段、已完成子任务、失败次数、已调用工具、关键中间结果、待确认信息这些。这样做的好处是,模型不用每次从自然语言里自己猜任务进行到哪一步,系统可以明确告诉它现在在什么节点。很多所谓 Agent 不稳定,本质上不是上下文不够,而是没有显式状态。
task_state = {
"task_id": "A1001",
"stage": "evidence_check",
"finished_steps": ["intent_parse", "doc_retrieve"],
"pending_steps": ["api_verify", "final_answer"],
"retry_count": 1,
"artifacts": {
"retrieved_docs": ["doc_12", "doc_27"],
"api_result": None
}
}
4. 如果 RAG 召回了很多相互矛盾的文档,Agent 应该怎么处理,而不是直接让模型自己总结?
不能直接把矛盾文档一股脑丢给模型让它自己“综合”,那样很容易生成一个看起来圆滑但实际上没有依据的答案。更合理的做法是先做证据归一化和冲突检测。比如先按来源、时间、可信度分组,再抽取同一个字段的不同取值,看冲突是时间差异导致的,还是来源本身互相打架。如果是时间敏感信息,通常新版本优先;如果是来源权威性不同,官方文档优先;如果还是无法消解,就应该明确告诉用户存在冲突,并说明目前更可信的依据是什么。Agent 在这里更像证据调解器,而不是万能总结器。
5. 如果工具调用是成功的,但返回结果语义不完整,模型很容易误判,你怎么设计中间层?
这个问题非常常见。很多工具从接口层面看是 200 成功,但业务语义上其实不够用,比如只返回了一个 code,没有返回解释信息;或者字段含义不清,模型会自行脑补。解决方式一般是加一个 tool adapter 或 semantic wrapper,把原始结果转成统一、可解释的中间表示。也就是说,不要把外部 API 的脏数据直接回喂给模型,而是先在中间层做字段补全、错误码翻译、单位归一、空值处理和置信度标注。这样模型看到的是“可推理对象”,而不是原始接口垃圾。
def normalize_tool_result(raw):
if raw["code"] != 0:
return {
"ok": False,
"error_type": "BUSINESS_ERROR",
"message": raw.get("msg", "unknown error")
}
return {
"ok": True,
"city": raw.get("city"),
"temperature": raw.get("temp"),
"unit": "C",
"confidence": 0.95
}
raw_result = {"code": 0, "city": "Shenzhen", "temp": 28}
print(normalize_tool_result(raw_result))
6. 一个 Agent 系统里,什么时候应该追问用户,什么时候应该自己继续推理?
判断标准主要有两个:信息缺口是否影响正确执行,以及这个缺口能不能通过工具或外部知识补上。如果缺的是执行必需参数,比如查订单必须要订单号,那就应该追问用户;如果缺的是可由外部系统补齐的背景信息,比如天气查询里城市
剩余60%内容,订阅专栏后可继续查看/也可单篇购买
本专栏聚焦 AI-Agent 面试高频考点,内容来自真实面试与项目实践。系统覆盖大模型基础、Prompt工程、RAG、Agent架构、工具调用、多Agent协作、记忆机制、评测、安全与部署优化等核心模块。以“原理+场景+实战”为主线,提供高频题解析、标准答题思路与工程落地方法,帮助你高效查漏补缺.
查看12道真题和解析