面对日志异常时，最忌讳的就是漫无目的地“猜原因”。尤其是在豆包这类AI平台上，模型响应中断、工具调用失败、上下文截断——这三个问题表面看起来可能相似，但排查路径完全不同。核心判断方法：只要抓住日志里最后一条有效 message，顺着它的特征逐层往下走，绝大多数问题都能在第一轮定位出来，无需依赖网络检查或重启操作。

因此，与其问“为什么没结果”，不如换一种更高效的提问方式——让诊断逻辑跟着现象走。下面直接给出三套提示词模板，按实际情况选择一套复制使用即可，请勿混用。

明确日志现象并锁定第一判断点

打开调试面板，翻到raw日志，找到最新、非空的那条message。如果它的content字段有内容，但后续看不到任何tool_execution日志，说明问题基本卡在模型输出侧。相反，如果content为空，但tool_calls里有内容，说明已进入工具调度阶段。这一步没有花哨技巧，只需查看时间戳最近的非空条目，比检查网络、重启环节高效得多，是日志分析的关键起点。

按三大典型现象分支编写提示词

方法一：响应突然中断（用户看到“…”后无后续）
严格按顺序排查：① 最近一条非空message的finish_reason是stop、length还是tool_calls；② 如果是length，立即检查content字符数是否达到32768；③ 如果是tool_calls，去tools列表里确认是否有对应的function名称，且parameters的JSON结构合法；④ 其余情况，直接返回error_code和message中的拒绝字段值。此流程可快速定位响应截断的根源。

方法二：工具调用无反馈（显示“正在调用工具”，但无执行日志）
只关注tool_calls里的function.name和id。如果name不在当前启用的tools schema内，直接报错“tool_not_registered”；如果name存在但parameters解析失败（比如string类型传入了null），就把parameters字符串中第一个语法错误的位置标出来。注意，这一步仅做静态schema匹配，不验证工具实际连通性，是工具调用调试的高效入门方法。

方法三：上下文被意外截断（前几轮正常，某轮开始回答变简短或重复）
估算当前messages数组的总token值。使用tiktoken对每条message的content、role、name字段分别计算，累加后对比模型context window。如果超限，找出哪一条message的content占用超过40%的总token，给出压缩建议。例如：“第3条user消息包含128行日志文本，建议改为摘要加关键行引用的格式。”这种方法能有效优化上下文管理，避免模型丢失历史信息。