FastAPI：让模型调用成为多轮对话服务

从脚本走向服务

以前是我运行 Python，得到一个回答；这一阶段变成客户端发送 HTTP 请求，由后端组织模型调用并返回 JSON。模型只是其中一层，服务还需要输入校验、配置管理、错误处理和历史管理。

请求体的定义与校验可参考 FastAPI 请求体文档。

看起来有记忆，是因为应用重新提供了历史

这一阶段先用 Python 字典，以 conversation_id 为键保存消息列表。每次取出对应历史，再加入当前问题，组成发给模型的上下文。模型没有因为一次聊天就被永久训练。

一次聊天请求的处理顺序

读取当前会话历史
→ 组合 system + history + 当前 user
→ 请求模型
→ 成功后保存本轮 user 与 assistant
→ 返回回答

当时的接口使用 question 字段；后来的 Agent 整合改成 message。复现前必须确认自己用的是哪个版本，不能混用请求字段。

笔记记录的测试：记住名字与区分会话

这是学习过程中的记录这里转述原笔记的测试结果，不是本次发布网站时重新调用模型；不同会话查询不串线，也不等于实现了用户鉴权。

按请求停止的位置排错

• 422：先检查请求体的字段、类型和必填项。
• model_not_found：先核对实际发送的模型标识，区分家族名和接口可识别的模型 ID。
• 修改后端后，已打开的 Swagger 页面可能仍保留旧输入，需要核对当前请求。
• 连接失败与服务器返回的认证、模型错误不是同一层；不要同时乱改所有配置。

配置从环境读取，必要值缺失时尽早暴露。对外返回经过整理的错误信息，不把完整异常、密钥或内部路径显示给访问者。

内存 Memory 的边界

• 普通字典属于当前进程，不能作为重启后恢复聊天的持久化方案。
• 多个服务进程不会天然共享同一个普通字典。
• conversation_id 是查询入口，不是用户身份凭证。
• 历史会持续增长，后续仍要设计裁剪、摘要与访问权限。

下一阶段没有推倒整个 HTTP 服务，而是保留 Memory 的读写接口，把底层从字典替换成 MySQL。

来源

本页依据个人笔记整理：《AI_Agent学习笔记_FastAPI到Memory多轮对话》第 4—8、11—15、19—25 节。