真实面经题目 · 原创解析
堆栈分析到代码定位链路中,大模型调用应采用单轮还是多轮?
堆栈分析到代码定位适合采用受控多轮流程:单轮适合简单摘要,多轮适合逐步检索、验证和收敛,但必须限制步骤和工具输出。
出现于:滴滴 · 后端开发
真实面经题目 · 原创解析
堆栈分析到代码定位适合采用受控多轮流程:单轮适合简单摘要,多轮适合逐步检索、验证和收敛,但必须限制步骤和工具输出。
如果只是把堆栈和少量代码摘要成可能原因,单轮调用更简单、延迟低、可控性强。但从堆栈定位到具体代码通常需要查日志、搜符号、看调用链、打开文件、验证假设,多轮 Agent 更合适。我的设计会采用受控多轮:每轮明确工具、输入和退出条件,先解析堆栈,再检索代码,再生成候选原因,再用证据验证。不能让 Agent 无限自主探索,要有步数、时间、权限和置信度限制。
简单堆栈解释、错误分类或摘要可以单轮完成;如果要跨文件、跨服务、跨版本定位根因,单轮上下文往往不够,需要多轮检索和验证,否则很容易缺证据。
单轮延迟低、成本可控、行为稳定,适合在线告警摘要、低风险建议和固定模板输出。缺点是无法主动补充缺失证据。
多轮可以逐步解析堆栈、搜索符号、打开文件、追调用链、检查最近变更和验证假设。它更适合复杂定位,但成本、延迟和失控风险更高。
工程上应定义状态机和工具白名单,限制最大轮数、最大文件数、超时和权限。每轮输出必须带证据和下一步目的,避免无边界搜索。
当证据足够、置信度达到阈值或预算耗尽时停止。证据不足时输出待验证假设和缺失信息,而不是继续生成看似确定的结论。降级输出要能指导人工继续排查。
成本和延迟不可控、误用工具、证据漂移以及在错误假设上继续深入。
可以拆成堆栈解析、候选模块、代码检索、证据校验、根因总结和修复建议几个明确阶段。
当代码版本、日志、权限或关键上下文缺失时,应输出缺失项和低置信度,而不是编造根因。