项目简介
买家用自然语言提问,Agent 自己决定调用哪些工具,返回带结构化商品卡片的回答;运营者在教学工作台里用真实对话纠偏,把经验沉淀成可复用的教学总纲。整条链路可以在本机完整跑通。
想解决的四件事
做商品咨询的 AI,难点不在“能不能聊”,而在下面四件事要同时成立:
- 答案必须来自可核验的商品事实,不让模型自由发挥库存、功效和适用人群。
- 长对话不能越聊越贵、越聊越忘,上下文要分层管理,归档后仍能检索回原文。
- 运营者要能纠偏,并且纠偏结果要沉淀下来影响后续回答,而不是改一次忘一次。
- 能力边界要诚实,答不了就请买家转人工,而不是编一个听起来像真的答案。
核心功能
- 买家咨询:对话页用 SSE 流式返回正文增量、工具事件和上下文占用,正式结果以数据库提交后的终态为准。
- 商品检索:先锁定有界候选,再对每个候选做关键词加向量的双路召回与 RRF 融合,最后统一重排。
- 结构化商品卡片:卡片事实来自数据库快照,不让模型生成。
- 分层上下文:按有效输入上限的 50% / 70% / 90% 分别触发归档、会话摘要与完整档案,归档原文可按关键词或轮次读回。
- 用户画像:增量提取,按账号身份各维护一份记忆,同身份跨会话共享,只使用用户本人的原话。
- 教学闭环:教学工作台纠偏生成候选回复,确认后固化为教学样本,再归纳进教学总纲。
- 人工客服:买家点“转人工”后 AI 暂停,客服在收件箱里实时回复;客服结束服务或一段时间无人回复时自动转回 AI。
系统架构
前端、API 层、Agent Loop、业务工具、上下文分层、外部模型服务与存储之间的关系:
一次提问的处理顺序:画像提取、组装输入、水位判断、模型推理与工具循环、最终回复、主事务提交,以及提交后发布画像文件并同步会话归档:
几个设计上的取舍
Agent Loop 保留模型的自主性。 没有“必须先检索”“必经某个工具”这类硬约束,模型自己决定调哪个工具、调几次、什么顺序。框架只管三件事:在本地用 JSON Schema 校验工具参数(不合法就把错误还给模型让它改,不执行业务工具)、保证每次调用和结果成对出现、在预算内终止。
预算覆盖整轮。 画像提取、摘要、模型推理和工具调用共用同一个时间边界,进入下一阶段不会重新拿到完整时长,避免一轮对话被各阶段拖得无限长。
上下文分层,而不是简单截断。 到 50% 时归档旧轮次,只保留最近几轮;到 70% 生成会话摘要;到 90% 生成分栏目的完整档案。归档的是原件:用户原话、最终回复和工具实际返回的结果都完整落盘,模型看到的节选不会覆盖存储的原件,需要时能读回来。
商品检索分三步,不是一次向量搜索。 先按显式 SKU、唯一商品身份或模型给出的候选锁定一个有界范围;再在每个候选内部做关键词与向量两路召回,用 RRF 融合;最后把各候选组成的池子统一重排。SQL 在向量排序之前就限定商品、有效版本、向量模型和维度,避免不兼容的向量被混在一起算。
事实和表达分开。 商品卡片、价格、规格这些事实来自数据库快照,模型只负责组织语言和决定查什么。这样即使模型措辞跑偏,卡片上的事实也不会错。
画像按账号身份隔离,聊天提交后才发布画像文件。 画像文件发布失败不会让一次已经提交的聊天被误报为失败,后续轮次会根据仍在的用户原话补提取。已登记的身份文件缺失或损坏时,系统报存储故障,而不是悄悄当成一个新用户。
教学闭环是三段式。 纠偏只生成候选回复,聊天里的原回复、原耗时和轨迹都保留,后续上下文和归档依旧用原回复;确认之后,候选才固化为教学样本;样本再由人工触发,增量归纳进教学总纲,进入系统提示词。整条链路不会自动覆盖历史。
明确不做什么
这部分和能力一样重要,写出来是为了不让功能被误读:
- 暂不支持线上购买。 商品资料是正式目录,但没有库存、下单和支付,接口固定返回不可购买;商品资料也不代表诊断或疗效承诺。
- 人工客服只有在工作台有人回复时才算接入。 AI 不会自己宣称已经转给真人。
- 账号体系是基础版。 用户名加密码登录,账号由运维脚本创建,没有网页注册、找回密码和第三方登录。
- 模拟模式只验证流程。 它能证明调用链、协议和持久化,不能证明模型回答的质量。
工程上做了什么
- 三条模型通道可切换:默认的生产通道、可回滚的备用通道,以及完全离线的模拟通道。向量通道单独配置,切换生成模型不会重算已有向量。
- 后端测试默认离线运行,不请求真实模型;真实模型调用另有费用护栏。
- 合并到主分支后由 GitHub Actions 持续部署:先跑完整离线回归并构建前端,再通过 SSH 发布;服务器在维护锁内备份数据库和画像、切换版本并验证,失败自动恢复上一版本。
- 人工客服的订阅和广播放在进程内存里,所以生产环境固定为单实例单 worker。这是一个明确写进文档的约束,而不是隐藏的坑。
技术栈
FastAPI、自建 Agent Loop、PostgreSQL 17 加 pgvector、React 19,生成模型使用 DeepSeek,向量与重排使用火山引擎的模型服务。