基于FastAPI与OpenAPI文档构建上下文感知聊天机器人的技术问询

1. 让聊天机器人感知当前路由上下文的方法 #

• 前端主动推送：在前端框架中监听路由变化事件，比如React用useLocation结合useEffect，Vue用router.afterEach钩子，一旦路由切换，就把当前路径（如/add_to_cart）实时传给聊天机器人组件或后端服务。每次用户和机器人交互时，也可以在请求参数里附带当前路由信息。
• 会话存储同步：如果后端维护用户会话（比如用Redis），前端路由切换时调用后端接口更新会话中的current_route字段，机器人服务从会话中读取该值获取上下文。
• 服务端渲染场景：如果是SSR应用，服务器渲染页面时直接把当前路由注入到聊天机器人的初始化配置中，无需前端额外传递。

2. 有效利用OpenAPI文档作为知识源的方案 #

• 结构化解析与存储：编写脚本或用工具（如openapi-python-client）解析FastAPI自动生成的openapi.json，提取端点路径、请求参数、响应结构，同时可以在OpenAPI文档中添加自定义扩展字段（如x-next-step）来明确工作流顺序，把这些信息存入关系型数据库（如PostgreSQL）或文档数据库（如MongoDB），方便快速查询。
• 预构建prompt模板：针对不同端点，预定义包含该端点功能说明、工作流下一步的prompt片段，当机器人需要生成回复时，把当前路由对应的模板和用户问题拼接后传给LLM，确保回复准确贴合业务流程。
• 实时同步更新：设置定时任务或监听FastAPI的部署事件，一旦OpenAPI文档更新，自动重新解析并同步到知识源，避免信息滞后。

3. MCP的适用性与替代方案 #

• MCP的适用性：MCP（Model Context Protocol）主要用于复杂多模态场景下的LLM上下文管理，如果你只是需要路由上下文+固定工作流引导，MCP会显得过于重量级，增加系统复杂度。
• 更优替代方案：
  • 轻量上下文管理：前端本地用状态管理工具（如Redux、Pinia）维护当前路由和交互历史，直接传给机器人组件。
  • 会话式上下文：后端用Redis存储用户会话的路由信息和对话历史，每次调用LLM时从Redis读取并注入prompt。
  • 内置LLM上下文窗口：把当前路由对应的OpenAPI端点信息和工作流步骤直接塞进LLM的上下文窗口，无需额外的上下文管理服务。

4. 推荐架构与可行实现方案 #

推荐架构（三层架构） #

• 前端层：聊天机器人UI组件 + 路由监听模块。负责收集当前路由、展示机器人回复、处理内部路由跳转（比如点击机器人推荐的/checkout直接跳转）。
• 中间服务层：
  • OpenAPI解析服务：实时/定期拉取FastAPI的openapi.json，解析并结构化存储端点与工作流数据。
  • 上下文管理服务：处理用户会话的路由信息、对话历史存储与查询。
  • LLM调用服务：结合当前路由的OpenAPI信息和用户问题，生成符合业务流程的对话回复。
• 数据层：结构化存储OpenAPI元数据的数据库 + 存储用户会话的Redis缓存。

可行实现方案示例 #

1. 前端实现：用React开发聊天机器人组件，通过useLocation监听路由变化，每次路由更新时，调用后端接口/api/bot/context更新当前路由。用户发送消息时，请求后端/api/bot/chat并附带当前路由参数。
2. 后端实现：
   • 用Python编写服务，定时请求FastAPI的/openapi.json，解析出每个端点的x-next-step扩展字段，存入PostgreSQL。
   • 当收到聊天请求时，根据当前路由查询数据库，获取该端点的功能说明和下一步路由。
   • 调用LLM（如GPT-3.5-turbo），传入prompt：用户当前在路由${current_route}，该页面用于${功能说明}，工作流下一步是${next_route}，请用对话式语气引导用户前往下一步。
3. 路由跳转：机器人回复中携带内部路由链接，前端组件监听点击事件，调用history.push(next_route)完成跳转。

内容的提问来源于stack exchange，提问作者Riya