AI Agent全栈架构

主题

高频面试题

LLM API 一次请求包含哪些核心参数？

这道题考的不是背 API 字段，而是你能否把一次模型调用设计成可鉴权、可追踪、可降级、可演进的服务端能力。

适合阶段：AI 应用开发 / 项目面核心能力：API Contract · Tool Use · Streaming · Observability

面试官角度分析，想考什么 ​

  • 调用 LLM API 时通常传哪些参数？
    考你能否把它说成一个完整请求契约，而不是只会传 model 和一段 prompt。

  • 这些参数如何影响模型行为和产品体验？
    考机制差异：messages/input、temperature、max_output_tokens、stream、tools、response_format 分别控制上下文、随机性、输出上限、体验、外部动作和结构化结果。

  • 生产环境为什么要服务端封装 LLM 调用？
    考工程边界：API Key、租户权限、限流、审计、成本、重试、fallback 和 trace 都不能交给前端裸调。

可直接抄走的 30 秒参考答案 ​

text
LLM API 一次请求不只是 prompt，通常会包含模型、输入消息、采样参数、输出长度、stream、tools、结构化输出约束和 metadata。应用开发里我更关注服务端怎么封装它：前端只提交业务意图，后端负责鉴权、组装 prompt、注入上下文、控制工具权限、记录 token 和 latency、处理超时重试与 fallback。这样模型调用才是可治理的业务能力，而不是把 API Key 暴露给浏览器的裸接口。

面试回答详解，知其所以然 ​

这道题的核心不是背某一家厂商的字段名，而是理解一次 LLM 调用由“请求契约、生成控制、服务端治理”三层组成。字段会变，但这三层基本不会变。

1. 一次请求先是一个上下文契约 ​

text
model
messages / input
instructions / system rules
conversation history
retrieved context
tool schemas
metadata / trace id

不同厂商字段名会不同，有的叫 messages，有的叫 input 或 contents，但抽象都在解决同一件事：告诉模型“这是谁的请求、要完成什么任务、哪些内容可信、有哪些历史和外部上下文”。

对话消息不是普通字符串数组，而是带角色和边界的状态：

  • system：定义角色、边界、输出规则和安全约束。
  • user：当前用户需求，优先表达这轮任务。
  • assistant：历史模型回复，用于多轮上下文。
  • tool / function result：外部工具返回的事实，模型应基于它继续回答。

常见错误是把系统规则、用户输入、网页内容和工具返回全拼成一个大字符串。这样会丢掉角色边界，也让 prompt injection、防越权和 badcase 复现变得更难。

2. 生成参数控制质量、成本、延迟和交互方式 ​

  • model：决定能力、成本、延迟、上下文长度和多模态能力。
  • temperature / top_p：控制输出随机性。事实问答、抽取、工具调用通常偏低；创意写作可以稍高。
  • max_output_tokens：控制输出上限。设太小会截断，设太大会增加延迟和成本。
  • stream：改善首屏感知，适合聊天、长文本生成和过程反馈；它改善体验，但不等于降低推理成本。
  • tools / tool_choice：让模型在需要外部事实或动作时生成工具调用参数，例如搜索、数据库查询、业务 API。
  • response_format / schema：约束最终输出结构，适合前端渲染、表单填充、数据库写入和自动化流程。

一个成熟回答要能区分 tools 和结构化输出：工具调用是让模型请求应用“去做事”，结构化输出是让模型的最终回答“按格式返回”。两者都可能用 JSON Schema，但工程语义不同。

3. 生产环境要把裸 API 包成服务端能力 ​

前端不应该直接带模型 API Key 请求模型服务。通常要经过自己的后端或 BFF：

text
前端 -> 业务后端/BFF -> LLM Provider
        鉴权、限流、审计、Prompt 拼装、工具调用、降级

服务端封装至少要覆盖这些边界：

  • 安全：API Key 不出后端；按用户、租户、角色控制可用模型和工具。
  • 成本：记录 input/output token，做预算、限额、缓存和模型路由。
  • 可靠性：区分超时、限流、内容安全、工具失败和模型错误，配置重试、降级和人工兜底。
  • 可观测性：记录 request id、user id、session id、prompt 版本、model、latency、TTFT、工具调用链路和错误类型。
  • 可演进性：用 provider adapter 隔离厂商差异，避免业务代码到处依赖某一家 API 字段。

没有这些封装，线上出现“变慢、变贵、答错、偶发 JSON 解析失败”时，很难定位到底是模型变了、prompt 变了、检索变了，还是工具返回变了。

面试官追问3个问题 ​

追问一：temperature 设置多少合适？ ​

  • 考察点：是否会按任务调参，而不是背一个固定数值。
  • 回答方向：事实问答、结构化抽取、工具参数生成通常用低温，追求稳定和可复现；创意文案、头脑风暴可以提高温度，增加多样性。不要只靠 temperature 解决格式问题，结构化输出要配 schema、校验和重试。

追问二：为什么要记录 prompt 版本？ ​

  • 考察点：是否有回归意识。
  • 回答方向：模型输出变化可能来自模型、prompt、检索内容、工具结果或参数变化。没有 prompt 版本和请求 trace，就无法复现线上 badcase，也没法判断一次改动到底提升了质量，还是只是在少数样本上看起来更好。

追问三：前端怎么处理流式接口失败？ ​

  • 考察点：产品兜底能力。
  • 回答方向：前端要保留已生成内容，展示明确失败状态，支持重试、重新生成或继续生成；服务端要把超时、限流、内容安全、模型错误和网络中断区分开。对长任务还要有 request id 或任务状态，避免用户刷新页面后结果丢失。

扩展知识 ​

一个通用请求抽象 ​

ts
type LlmRequest = {
  model: string
  messages: Message[]
  temperature?: number
  maxOutputTokens?: number
  stream?: boolean
  tools?: ToolDefinition[]
  responseFormat?: JsonSchema
  traceId: string
}

这个抽象不绑定具体厂商，方便后续做 provider adapter、模型切换和 A/B。

官方资料里的字段演进 ​

OpenAI Text Generation、OpenAI Function Calling 和 Google Gemini Function Calling 都在强调同一个趋势：现代 LLM API 已经不是单纯文本补全接口，而是统一承载文本生成、结构化输出、工具调用、多模态输入和 Agent 工作流的接口层。面试时不要死记某个 SDK 的字段名，要讲清这些字段背后的工程职责。

基于 MIT 协议开源

Copyright © 2026 AI Agent全栈架构