检查为您应用程序提供服务的那次请求

概览

主请求（main request）是时间线的核心组件——它代表了最终向您的应用程序返回响应的 AI 供应商调用。如果触发了回退链，主请求就是最终成功的那次尝试（或者如果在所有供应商都耗尽时，那就是最后的那次失败的尝试）。

主请求如何展示

在时间线（Timeline）中

• 位置：在任何故障转移尝试之后，且在 webhook 交付之前
• 徽章颜色：绿色表示成功，红色表示发生错误
• 徽章内容：供应商图标、供应商名称和模型名称
• 附加信息：持续时长、token 使用量、时间戳

点击后显示内容

点击主请求能够显示各种全面的信息：

Header 信息

Request Body (请求主体) 选项卡

“Request Body”选项卡精确显示了发往 AI 供应商的全部信息：

• 原始 JSON 视图 – 在具有语法高亮并且规整格式的代码编辑器里展示完整 JSON payload

  • 能够直接查看发往该供应商内部底层服务调用的原生内容构造
  • 对于为失败的请求进行 debug 排查，或是检验 prompt 以及理解请求格式结构时用处极大

• 预览模式（树状视图） – 为方便检索而备的互动展开收起式 JSON 构件渲染图表

  • 面向庞大的 payload 时能更轻松地进行探索流转，支持任意缩折聚焦特定的字段
  • 对于细致观摩复杂的嵌套横向结构或者是大量消息组队列具有绝佳体验

• 复制按钮 – 提供一键拷贝整个请求主体的功能

  • 便于快速与团队成员共享请求细节或者将其应用至各类 API 测试辅助工具里

请求主体中涵盖的常见字段：

• model – 发送至供应商处的模型标识
• messages – 所承载传送过去的会话消息群 (囊括了 system, user, assistant)
• temperature – 用于调度跳跃的随机活跃发散率参数
• max_tokens – 生成的最大的 tokens 限制数目
• response_format – 配置并主导结构化输出 (Structured output) 的规划（如果可用的话）

Response Body (响应主体) 选项卡

“Response Body”选项卡展示从 AI 供应商处完整返回的答复数据：

• 原始 JSON 视图 – 完整的全貌供应商应答在格式化好的代码编辑器中罗列而出

  • 透过这一窗口您将彻底看清供应商抛回的所有具体内容，连带所有元数据均包括在内
  • 用于剖析响应内容之水准、修复解析错误，或是验证它对结构化输出守则之遵循程度的优良参考对象

• 预览模式（树状视图） – 探究大包裹响应包专职配对的树形组件

  • 在大型答复中随意导航跳转，聚焦关心的特定字段并洞察全盘反馈框架脉络

• 复制按钮 – 拷贝完整的这份响应体以供深究或与人交流共享

响应主体中通常存在的核心字段：

• id – 供应商为这次响应给打下的唯一专属标识码
• choices – 所生成出来的正式内容文本 (文本或者已经过了结构化处理的数据组)
• usage – 打点拆解关于 token 消耗分布的对账细则：
  • prompt_tokens – 录入时吃进消耗的输入 tokens
  • completion_tokens – 为打造成果文本而吞吐导出的输出 tokens
  • total_tokens – 所有的前述输入与输出数值之和
• model – 代为执行消化了这条请求的切实服务模型（也许这与期望请求挂名之模型会有所偏差）
• finish_reason – 告知本段任务之最终休止由头缘由 (stop 代表天然收场, length 说明过长被砍断了, 或者是 content_filter 撞到了阻隔屏障)

理解主请求

成功 (Success) 与 失败 (Failure)

成功的主请求 (绿色徽章)：

• 供应商传回了一份具效力且合格的响应包
• 关于 token 使用费率已被确实定案并妥帖留档
• 响应主体中内蕴饱含由 AI 促成的心血结晶实体字句块
• 这即是交付给您应用程序的最终反馈呈现式态

失败的主请求 (红色徽章)：

• 回退链（fallback chain）里的供货商序列已经面临全部歇菜或全线溃败
• 这个主请求便意味着全村最后之希望所开展的垂死试探但宣告作废
• 此响应主体包含从最后一线挣扎中所捞起来那份带有致命报错成因的信标声明
• 对此您的服务端程序铁定也收到了一篇满江红似的报错结果交差点书

当存在故障转移尝试时

如果在主请求之前，时间线上出现了若干项故障转移尝试：

• 意味着此次主请求乃是依赖 下游序列排布的替补回退策略（downstream fallback provider） 并最后获得了成功
• 那些未能成事的倒霉供应商其具体的落败错因都归档存置在它们对应专属的各路日志记录仪里有迹可查
• 这项主请求上头所冠名的供应商或其指代的兵卒模型很大几率与您在工作流程设计上指定的原头牌选手发生了出入易主的情况

主请求对于 Token 的用量计算

Token 用量被单独捕获保存在这单主请求档案里头：

• Prompt tokens (提示词令牌): 请求供给至该模型端口所耗的字数等值物
• Completion tokens (补完词令牌): 由该方回复生产制备而出世的单方生成费
• Total tokens (总令牌): 上述两宗汇总并相加得出合计

注意: 如果发生中途折损的状况，之前那几次无功而返的故障转移探索（failover attempts）照样也可能会吞噬消耗部分 tokens 份额（具体看供应商之章程以及该类型错误特质）。因此只唯独这单主请求的面板才只单纯反映了本轮立功成事的开支账目明细。

审查主请求以进行调试 (Debugging)

验证请求的内容

打开 Request Body 选项卡去确认：

1. 系统提示词 (System prompt) – 是否做到了全面准确并确保无有脱漏遗失？
2. 用户讯息 (User message) – 是否承载住了这应该涵括进入语境当中的原装语意材料？
3. 型号挂名 (Model) – 确实向目标所想召唤使唤的该代号模型发起了点兵遣将吗？
4. 变数选项 (Parameters) – 控制台列项如 temperature, max_tokens 有被正确无缺地附挂在列位上么？
5. 结构化输出纲领 (Structured output schema) – 假如存在的话，其布置所用设想的模具图纸规格规范能避开挑剔么？

验证响应的内容

展开 Response Body 选项卡去查验：

1. 生成的结果 (Generated content) – 响应内容结果达成了对它期盼之大纲的描边轮廓了么？
2. 结束原因 (Finish reason) – 是在合理轨道内正常完成了结 (stop)，还是顶不住撞线撞到了配额池的尽头高墙 (length)？
3. 推算 Token 消费 – 有没有处于预算界标或是容许范畴当中乖顺地安身打转呢？
4. 结构化输出 (Structured output) – 如果被用上，这堆数据有依着您的框架骨髓构筑起楼宇了吗？

复现问题

灵活善用好这这功能小巧的拷贝辅助键以便于：

1. 先把原封不动全盘的请求主体拉拽到自己剪贴板上
2. 在自己的本地场子里拿着它向相应供应商所在的公共接口发动一轮纯对等模拟强打
3. 把两次所得答复搁一块作下纵横对比借以发觉并揭露究竟纯属于贵方的操作纰漏还是该供应商自己的架构兼容失误短板所引致

下一步

• 供应商故障转移 – 理解在正式挺进主请求阶段以前发生了些什么样翻车碰壁尝试
• Webhook 交付 – 主请求尘埃落定后将同步执行触发的接棒送函分发传达
• 后端回调 – 事件驱动作业流程架构里末端一环的回马枪大盘点
• 调试文档 – 大通篇集全了完整且面面俱到的病理学式深度扫雷侦测方策
• 返回时间线 – 点亮退回键跃迁至那个最初带您上道且看全家福概貌的大起手式总序篇