60 秒回答模板

如果只是把堆栈和少量代码摘要成可能原因,单轮调用更简单、延迟低、可控性强。但从堆栈定位到具体代码通常需要查日志、搜符号、看调用链、打开文件、验证假设,多轮 Agent 更合适。我的设计会采用受控多轮:每轮明确工具、输入和退出条件,先解析堆栈,再检索代码,再生成候选原因,再用证据验证。不能让 Agent 无限自主探索,要有步数、时间、权限和置信度限制。

考点 简单用单轮
难度 真实面经题
回答目标 讲清方法、取舍和追问

深入解析

01

先区分任务复杂度

简单堆栈解释、错误分类或摘要可以单轮完成;如果要跨文件、跨服务、跨版本定位根因,单轮上下文往往不够,需要多轮检索和验证,否则很容易缺证据。

02

单轮调用的优点

单轮延迟低、成本可控、行为稳定,适合在线告警摘要、低风险建议和固定模板输出。缺点是无法主动补充缺失证据。

03

多轮 Agent 的价值

多轮可以逐步解析堆栈、搜索符号、打开文件、追调用链、检查最近变更和验证假设。它更适合复杂定位,但成本、延迟和失控风险更高。

04

受控流程比自由探索更稳

工程上应定义状态机和工具白名单,限制最大轮数、最大文件数、超时和权限。每轮输出必须带证据和下一步目的,避免无边界搜索。

05

退出条件和降级

当证据足够、置信度达到阈值或预算耗尽时停止。证据不足时输出待验证假设和缺失信息,而不是继续生成看似确定的结论。降级输出要能指导人工继续排查。

易错点

  • 不要把多轮 Agent 当成无约束自动搜索,必须有预算和退出条件。
  • 不要为了低延迟把复杂定位硬塞进单轮,容易缺证据。
  • 不要让模型直接下最终结论而不给出文件、日志和调用链依据。

面试官追问

多轮 Agent 最大风险是什么?

成本和延迟不可控、误用工具、证据漂移以及在错误假设上继续深入。

如何设计每轮状态?

可以拆成堆栈解析、候选模块、代码检索、证据校验、根因总结和修复建议几个明确阶段。

什么时候应该拒绝定位?

当代码版本、日志、权限或关键上下文缺失时,应输出缺失项和低置信度,而不是编造根因。