跳到主要内容

第 1.3.2 节：区分 Responses、Chat 和 Agents SDK 的调用边界

进入实现之前，先围绕“区分 Responses、Chat 和 Agents SDK 的调用边界”划清适用场景、不做范围和判断条件。完成本节后，你应该能够用对比表判断 Responses、Chat 和 Agents SDK 的适用条件、职责边界和取舍理由。

核心概念​

模型​

模型是负责理解、推理、生成和工具选择的组件。工程上选择模型时，不只看“聪不聪明”，还要看：

模型选择不是一次性决定。商业项目里常见做法是：高价值任务用更强模型，低价值批处理用更便宜模型，测试环境默认走 Mock（模拟）。

四层解释法：模型​

层级解释
人话解释模型是负责理解和生成的“大脑”，但它不是数据库，也不是业务系统。
项目位置在客服工作台里，模型负责理解用户问题、组织答案和判断是否需要工具。
工程动作选择模型、控制成本、设计上下文、记录耗时、处理失败，并保留供应商切换能力。
面试说法我会把模型当成一个不完全确定的外部服务治理，而不是把业务逻辑直接绑死在某个模型 SDK（软件开发工具包）上。

Token（文本计量单位）​

Token（文本计量单位）是模型处理文本的计量单位。输入、输出、系统提示、工具返回结果、检索片段都会占用 Token（文本计量单位）。

Token（文本计量单位）影响四件事：

  1. 容量：能放多少上下文。
  2. 成本：输入和输出通常按 Token（文本计量单位）计费。
  3. 延迟：上下文越长，响应通常越慢。
  4. 稳定性：上下文太杂会降低回答质量。

所以工程上要做 Token（文本计量单位）预算，而不是把所有内容都塞给模型。

四层解释法：Token（文本计量单位）​

层级解释
人话解释Token（文本计量单位）就是模型处理文本时的计量单位，越多通常越贵、越慢。
项目位置客服工作台里的系统提示、历史对话、检索片段、工具结果和最终回复都会消耗 Token（文本计量单位）。
工程动作控制历史长度，限制检索片段数量，摘要工具结果，设置最大输出长度，记录单次调用成本。
面试说法我不会把所有资料塞进上下文，而是会按任务做 Token（文本计量单位）预算，保证成本、延迟和质量可控。

上下文窗口​

上下文窗口是模型一次请求能处理的最大内容范围。它包括系统提示、开发者指令、用户输入、历史对话、检索结果、工具结果和模型输出。

上下文窗口变大，不等于系统就变简单。你仍然要决定：

  • 哪些资料进入上下文？
  • 哪些历史对话需要保留？
  • 工具返回结果是否需要摘要？
  • 长任务是否需要阶段性压缩？
  • 哪些内容应该放入数据库或长期记忆？

API Key（接口密钥）​

API Key（接口密钥） 是调用模型服务的凭据。它必须通过环境变量或安全配置读取，不能写进代码、书稿、截图和日志。

本书所有真实模型调用都应该遵守：

  • .env 保存本地配置。
  • .env.example 只写变量名，不写真实值。
  • 测试默认走 Mock（模拟）。
  • 文档中不展示真实 Key（密钥）。
  • 日志中不打印请求头和密钥。

本章在客服 Agent（智能体）工作台中的位置​

客服工作台的模型调用层位于业务后端和模型供应商之间。

上游输入模型调用层要做什么下游输出
用户问题清洗问题、合并必要上下文可理解的任务请求
会话状态选择相关历史，不无限追加当前轮上下文
知识库片段控制数量、排序、引用信息带来源的回答依据
工具结果摘要和过滤敏感字段可交给模型解释的结果
模型配置选择供应商、模型和模式Mock（模拟）或真实调用
调用结果校验格式、记录日志、处理失败回答、结构化结果或工具意图

这一层做好后，第 1.4 章的结构化输出、第 1.6 章的工具调用、第 1.7 章的状态管理才有稳定底座。

继续学习​