凌晨两点。使用者群里炸出一条消息：“为什么 AI 助手昨天还记得我叫小李，今天又问一遍？老实说，”我打开监控，内存正常、CPU 平稳、日志没有 ERROR。重新启动后记忆又回来了——接下来第二天 丢失。没有报错、没有异常堆栈，Chroma 就这么悄无声息地把文档丢了。那一刻我才意识到，常规的单元测试在向量数据库面前就是一张废纸。

问题拆解

这个 LLM 应用用的是典型的 RAG 记忆链路：使用者对话被摘要后写入向量库，下次对话从库中检索相关记忆拼进 Prompt。记忆持久化依赖 Chroma 的 persist我们在集成测试里 mock 了它的返回，写几个文档、查一下全绿。但生产环境是另一回事，说起来，

根因出在三个地方叠加：

• Chroma 的默认 persist 在写入后不会立刻刷盘。底层 SQLite 有自己的缓存策略，进程异常退出时最近几秒的写入直接消失。
• 我们用了异步的 add_texts但没有等底层 flush 完成就返回了 HTTP。不过，
• 容器化部署时 /tmp/chroma-data 被 k8s 的 ephemeral 存储回收。而日志里只有一句 “Persist succeeded”，目录已经没了。

常规单元测试根本模拟不出这些边界，因为所有操作都在同一个进程里Mock 把最危险的部分悄悄盖住了。

方案设计

要逮住这种“静默丢数据”。必须让测试在真实的多进程、有网络延迟、有磁盘 I/O 的环境下跑，同时覆盖持久化的完整生命周期：写入 → 服务重启 → 读取。端到端测试的用武之地是这就。

工具选型上，我们排除了单纯的 API 直测——虽然快。但绕过了浏览器和真实请求链，没法验证前端触发后整个调用链路是否真正把数据落盘。

也排除了 Selenium，太重且 async 支持差。按理说，最终定下 Playwright + pytest-asyncio因为它可以：

• 模拟使用者在真实浏览器里的多轮对话。
• 通过 page.wait_for_* 控制时序，捕获那些先返回再异步丢数据的窗口。
• 在测试里直接控制服务进程的重启，覆盖“数据是否在磁盘上”的验证。

架构思路是“测试即使用者”：每个用例都形如“打开页面 → 发送消息 → 关闭浏览器 → 重新启动 → 打开页面 → 检查历史记忆是否存在”。只有这种野蛮的方式才会让向量库的持久化问题原形毕露。

主要实现

下面先给一个简化的被测应用——一个 FastAPI 服务、前端聊天页、后端用 Chroma 存记忆。启动命令是 uvicorn main:app。不过，关键点是如何用 Playwright 起停服务，并封装成可复用的 fixture.

# conftest.py
import subprocess
import time
import httpx
import pytest_asyncio
from playwright.async_api import async_playwright
@pytest_asyncio.fixture
async def app_service:
# 每个测试用例拥有独立的 Chroma 持久化目录，避免数据串扰
chroma_dir = tmp_path / "chroma_data"
chroma_dir.mkdir
# 启动被测服务，设置环境变量指定持久化方法
proc = subprocess.Popen(
env={"CHROMA_PERSIST_DIR": str,**__import__.environ}。stdout=subprocess.PIPE,stderr=subprocess.PIPE,)
# 等待服务就绪
async with httpx.AsyncClient as client:
for _ in range:
说到try，resp = await client.get
if resp.status_code == 200:
break
except Exception:
pass
await asyncio.sleep
else的观点是，proc.kill
raise RuntimeError
yield {"proc": proc,"base_url": "http://127.0.0.1:8000","chroma_dir": chroma_dir}
# 测试结束后强杀进程，模拟生产环境可能出现的非正常退出
proc.kill
proc.wait

这段 fixture 把“每次测试独立数据目录”和“进程生命周期”统一管理，确保每个用例的持久化环境干净，并能模拟意外终止。

# test_memory_persistence.py
import asyncio
import pytest
from playwright.async_api import async_playwright
pytestmark = pytest.mark.asyncio
async def test_memory_survives_restart:
"""
场景这方面。使用者说自己的名字，重新启动后 AI 仍然记得。这个测试直接揪出了 Chroma 的异步刷盘问题。"""
base = app_service
async with async_playwright as p:
browser = await p.chromium.launch
page = await browser.new_page
# Step 1：使用者首次对话，留下记忆
await page.goto
await page.fill
await page.click
await page.wait_for_selector
await browser.close # 浏览器关闭。
但服务仍在
# Step 2：杀掉服务并重启
app_service.kill
app_service.wait
# 重启同一个服务，保持 chroma_dir 不变
proc = subprocess.Popen(
env={"CHROMA_PERSIST_DIR": str,**__import__.environ},stdout=subprocess.PIPE,stderr=subprocess.PIPE,)
await asyncio.sleep # 简单等待；生产环境可换成探活轮询
async with async_playwright as p:
browser = await p.chromium.launch
page = await browser.new_page
await page.goto
# Step 3：
提问。看 AI 是否还能记得名字
await page.fill
await page.click
response_el = page.locator.last
await response_el.wait_for
text = await response_el.inner_text
assert "王小明" in text,f"记忆丢失！至于实际回复，{text}"
await browser.close
# 清理重新启动的进程
proc.kill
proc.wait

关键点：

• 使用真实进程而不是 mock。让磁盘 I/O 与 SQLite 缓存行为真正参与测试。
• .kill 而不是优雅关闭。以模拟最坏情况——如果 flush 策略有漏洞，这里就会报错。
• 让 “使用者抱怨 AI 失忆” 的痛点得到最直接复现。按理说，

踩坑记录

坑 1：Playwright 的 wait_for_selector 根本不等异步写入

现象：测试偶发失败——{text} 里不包含“王小明”。但手动调试总能复现，起初以为是 Chroma 丢数据。却发现前端已经收到 AI 响应，只是后端向量库仍在后台写入。

原因：AddTexts 是异步任务；HTTP 返回仅表示任务已被接受，而真正执行 SQLite 写入可能要几秒钟才落盘。Playwright 看到 `.ai-message` 出现就继续往下走，此时磁盘上可能还是空的。

方法：在断言前加入显式等待，通过专门提供的 /debug/vector-count 接口轮询文档数量直到达到预期值或超时。这种 “绕过后端异步队列” 的等待，是官方文档很少提及但极其可靠的方法。

# 在断言前确保向量库已持久化
async with httpx.AsyncClient as client:
for _ in range:
resp = await client.get
if resp.json>= 1:
break
await asyncio.sleep

坑 2：容器内 Chroma 的 Segment 文件被静默清理

现象：CICD 流水线里所有测试全绿，但预发环境第二天记忆全消失。Chroma 默认把 Segment 文件放在 /tmp 下而 k8s 的 alertDir 会根据策略定期清理临时文件。日志只打印 “loaded embeddings”。不报错，使得问题隐藏得更深。

方法：

• #fixture 中强制指定持久化方法为可控目录并挂载到容器中持久卷；
• #线上部署时禁用临时目录，将 /data/chroma-data 映射到 PVC；
• #关闭 Chroma 后台遥测  以减少潜在干扰任务。

效果验证

The Playwright‑based E2E suite runs in ~12 秒 per case,covering 写入 → 崩溃重启 → 读取 全链路。从此再也没有收到使用者凌晨抱怨 “AI 忘记我是谁”。

可直接用的代码 / 工具

如果你想立刻为你的 LLM 应用加上一样的检测，这里提供完整可复制‑粘贴版 fixture 与示例用例。只需把下面内容放进项目根目录下 conftest.py 和 test_memory.py 即可运行。再看依赖如下，

pip install playwright pytest-asyncio httpx
playwright install
# 接下来运行
pytest -q

#Playwright #向量数据库 #端到端测试 #LLM #Python

关于作者 一个在生产环境踩过无数坑的后端/架构实战派。专注 LLM 应用可观测性与工程质量。GitHub : github.com/baofugege<\/a> Sponsor : github.com/sponsors/baofugege<\/a> — 如果这篇文章帮你省下半夜排查时间，请我喝杯咖啡。至于提供服务，Python 后端性能调整 / 工具定制 / 技术咨询。联系 Telegram @baofugege