无状态请求
Stateless Request
中级通用无状态请求（Stateless Request）指服务端处理当前请求时，不依赖此前请求留下的会话上下文。它让请求更容易由不同服务实例独立处理；例如调用 AI 接口时，每次都带上本轮需要的对话内容。
你可能会说：「我想让每次调用都带齐所需信息，换一台服务器处理也能得到正确结果。」
动手看看AI 文案追问为何要带前文
1
运营同事让 AI 把新品功能介绍改写成英文。客户端把原文和要求一起发给实例 A。
要点一次请求怎样做到独立处理？
- 1
带齐处理所需的上下文
你发起请求时，要让服务端能从本次输入和它可访问的数据中取得处理所需的信息。比如让 AI 续写对话，就把必要的历史消息一并传入，别假设模型记得上一次调用。
- 2
不靠上次请求留下的会话
关键不是服务端完全不保存数据，而是不依赖某台服务实例为这个用户暂存的会话上下文。查数据库里的订单记录仍然可以是无状态请求，因为接手的实例也能按请求中的订单 ID 查询。
- 3
请求独立不等于重复安全
无状态只说明处理这次请求不靠先前的会话上下文，不保证重复发送没有副作用。比如创建订单的请求即使信息带齐，重发也可能创建两单；这时还要考虑幂等处理。
容易混淆的地方
它容易和“没有状态”混淆：无状态请求仍可能读取或写入数据库，只是不依赖此前请求留在服务实例里的会话上下文。它也不等于“每次结果相同”；数据变化、模型输出波动都可能改变结果。若请求只带一个会话 ID，让服务端接着读取上次暂存的对话，这就不是这里所说的无状态处理。
什么时候用
适合用
- 做商品查询 API，让每次请求带上筛选条件和页码，方便不同服务实例接手处理。
- 调用 AI 模型生成回复时，把本轮问题和必要的历史消息一起传入，不依赖模型记住上次调用。
- 部署多个后端实例时，让请求凭认证信息和资源 ID 完成处理，减少对固定实例的依赖。
不适合用
- 做持续双向通信的协作白板时，不必把整段交互设计成一串独立请求；可以用 WebSocket 维持连接并同步变化。
- 做需要服务端持续掌握进度的长流程时，若每次传回全部上下文代价太高，可以保存流程状态，用会话或任务 ID 接续。
练一练选一个答案，看看解释
你做了一个 AI 客服接口，准备部署到多个服务实例。用户第二次提问时，哪种设计符合无状态请求？
让 AI 帮你做复制给 AI Agent 直接用
请把这个 AI 对话接口设计为无状态请求：每次调用都传入本轮问题和生成回答所需的历史消息，不依赖某个服务实例暂存的对话。请标出请求字段，并说明历史消息过长时如何控制传入内容。