为 Hermes Agent 集成本地向量记忆：PostgreSQL + pgvector 实战指南 1. 项目概述为什么 Hermes 需要“本地记忆”而 Hindsight 是那个解法Hermes 不是某个大厂刚发布的明星产品而是当前 AI 工具链里一个真实存在、被不少技术团队悄悄用起来的轻量级 Agent 框架——它擅长把 LLM 的推理能力快速封装成可调用的服务比如自动解析用户上传的合同 PDF、实时汇总会议录音转写的文本、或者根据 Slack 频道里的讨论自动生成周报草稿。但它的默认设计里没有“记忆”这个模块每次对话都是干净的白板上一条消息里你告诉它“我叫张伟负责华东区销售”下一次提问它就又得问一遍“请问您怎么称呼”。这种状态在原型验证阶段无所谓一旦进入真实业务流比如客服工单系统集成或内部知识库问答就会立刻卡住——不是模型不行是它根本记不住上下文里反复出现的人名、项目代号、部门架构这些关键锚点。这时候“给 Hermes 装上本地记忆”就不是一个修辞而是一个刚需工程问题。Hindsight 就是为此生的它不替换 Hermes也不改写它的核心调度逻辑而是作为一个独立的、可插拔的记忆服务通过标准 HTTP 接口接收 Hermes 发来的“我想记住这个”或“请帮我找上次提到的 XX”然后把结构化事实、对话片段、甚至带时间戳的决策依据存进你自己的 PostgreSQL 数据库里。关键在于它用的是 pgvector 扩展这意味着它存的不是冷冰冰的字符串而是向量化后的语义指纹。当你问“上个月王总监提过的那个物流系统改造方案”Hindsight 不是去匹配关键词“物流系统”而是计算当前问题向量和所有历史记录向量的余弦相似度精准召回那条包含“WMS 升级路径图”附件、发生在 2024-05-18 的会议纪要片段。这背后没有魔法只有 PostgreSQL 的 ACID 事务保障 pgvector 的高效近似最近邻搜索ANN——数据主权在你手里响应延迟在毫秒级扩展性随你的数据库集群线性增长。如果你正在评估 Hermes 是否能扛起真实业务负载那么部署 Hindsight 不是锦上添花而是补上最后一块拼图让 AI 从“会答题”变成“懂你”。2. 整体设计与思路拆解为什么选 PostgreSQL pgvector而不是 Redis 或 Chroma2.1 核心矛盾记忆不是缓存而是有状态的业务资产很多团队第一反应是“加个 Redis 缓存不就完了”——这是最典型的认知偏差。Redis 是极快的键值存储但它解决的是“临时加速”问题而 Hermes 的记忆需求本质是“状态持久化”。举个例子销售同事在 Hermes 里录入了一条客户反馈“XX 客户对报价单 PDF 的页眉 logo 尺寸不满意”。这条信息必须长期存在不能因为 Redis 内存满或服务重启就丢失可追溯需要知道是谁、什么时候、在哪次对话中提交的可关联要能和 CRM 系统里的客户 ID、该次对话的 Hermes session_id 关联起来可检索当客户经理下周问“上周谁反馈过 logo 问题”需要按语义而非关键词召回。Redis 做不到第 2、3、4 条。Chroma 或 LanceDB 这类专用向量数据库看似更“专业”但它们引入了新的运维面你需要单独维护一套服务、配置备份策略、处理版本升级兼容性而 Hermes 本身已经依赖 PostgreSQL 存储其 workflow 定义、执行日志等核心元数据。把记忆也塞进同一个数据库意味着运维收敛DBA 只需管好一台 PostgreSQL 实例备份、监控、高可用策略全部复用事务一致当 Hermes 记录一次对话执行成功同时 Hindsight 记录相关记忆时可以放在同一个数据库事务里避免“执行成功但记忆丢失”的数据撕裂权限统一数据库账号的读写权限可以直接映射到业务角色比如只允许客服组读取客户相关记忆禁止财务组访问。这就是我们放弃“看起来更酷”的方案死磕 PostgreSQL pgvector 的底层逻辑。2.2 pgvector 是如何让 PostgreSQL “突然会思考”的pgvector 不是一个独立数据库它是 PostgreSQL 的一个 C 语言扩展安装后会在数据库里新增vector数据类型和一整套向量运算函数。它的核心能力是把任意长度的浮点数数组比如一个 768 维的句子嵌入向量存成一个字段并提供-操作符来计算两个向量的欧氏距离以及vector_cosine_ops索引操作符类来加速相似度搜索。举个实际例子Hindsight 收到 Hermes 发来的一段话“客户李明说希望把付款周期从 30 天延长到 60 天”。Hindsight 会调用嵌入模型比如text-embedding-3-small把它转成一个 1536 维的向量存入memories表的embedding字段。当后续查询“李明的付款条件”时Hindsight 把新问题向量化执行 SQLSELECT content, metadata FROM memories WHERE user_id li_ming ORDER BY embedding - [0.12, -0.45, ..., 0.88]::vector LIMIT 3;PostgreSQL 的 pgvector 索引通常是 IVFFlat 或 HNSW 类型会让这个查询在百万级向量中毫秒级返回结果而不是全表扫描。这里的关键洞察是向量搜索不是替代 SQL而是增强 SQL。你可以用WHERE先过滤出特定用户、特定时间范围、特定标签的记忆再在子集里做向量排序——这种混合查询能力是纯向量数据库很难优雅实现的。2.3 Hindsight 的架构定位一个“无侵入”的记忆外挂Hindsight 的设计哲学非常清晰它不碰 Hermes 的任何一行代码。它暴露两个 RESTful 接口POST /remember接收{ content: 文本内容, user_id: li_ming, session_id: sess_abc123, tags: [payment, negotiation] }生成向量并存入 PostgreSQLGET /recall?query...user_id...limit5接收自然语言问题返回最相关的几条记忆。Hermes 只需在自己的业务逻辑里在合适的位置比如每次对话结束时、或用户明确说“记住这个”时调用这两个接口。整个过程对 Hermes 是透明的它不知道背后是 PostgreSQL 还是别的什么Hindsight 也不关心 Hermes 是用 Python FastAPI 还是 Go Gin 写的。这种松耦合带来的好处是灾难性的——当 Hermes 升级到 v2.0只要接口契约不变Hindsight 完全不用动反之你想把 pgvector 换成别的向量引擎虽然不推荐也只需重写 Hindsight 的存储层Hermes 依然稳如泰山。这才是生产环境里真正可靠的集成方式。3. 核心细节解析与实操要点PostgreSQL 配置、pgvector 编译与 Hindsight 初始化3.1 PostgreSQL 版本与初始化为什么必须是 14且禁用 JITHindsight 的官方文档写着“支持 PostgreSQL 12”但实测下来强烈建议使用 PostgreSQL 14 或 15。原因很实在pgvector 从 0.5.0 版本开始深度依赖 PostgreSQL 14 引入的pg_stat_progress_create_index视图来监控索引构建进度。如果你在 12 或 13 上强行安装索引创建会卡在 99% 不动日志里只有一行waiting for index build to complete查三天都不知道问题在哪。这不是 bug是版本特性绑定。安装 PostgreSQL 时还有一个极易被忽略的坑必须关闭 JITJust-In-Time Compilation。PostgreSQL 12 默认开启 JIT它能在复杂查询时动态编译执行计划提升性能。但 pgvector 的向量索引构建过程会触发 JIT 的内存分配器导致CREATE INDEX命令直接 OOM 崩溃错误日志类似out of memory in JIT context。解决方案是在postgresql.conf里添加jit off别信网上某些教程说“调大jit_provider就行”那是治标不治本。关掉 JIT性能损失微乎其微但能换来 100% 的稳定性。初始化数据库时不要用postgres超级用户直接跑 Hindsight。创建一个专用用户CREATE DATABASE hindsight_db OWNER hindsight_user; CREATE USER hindsight_user WITH PASSWORD your_strong_password; GRANT ALL PRIVILEGES ON DATABASE hindsight_db TO hindsight_user; -- 连接到 hindsight_db 后再授予权限 \c hindsight_db GRANT ALL ON SCHEMA public TO hindsight_user;这个账号只拥有hindsight_db库的权限符合最小权限原则。Hindsight 启动时会用这个账号连接即使未来被攻破攻击者也无法波及 Hermes 的主数据库。3.2 pgvector 安装源码编译是唯一可靠路径Docker Hub 上有带 pgvector 的 PostgreSQL 镜像比如postgis/postgis:15-3.4但它的 pgvector 版本往往滞后且无法保证和你的 Hindsight 版本 ABI 兼容。最稳妥的方式永远是源码编译。步骤如下以 Ubuntu 22.04 为例安装构建依赖sudo apt update sudo apt install -y build-essential postgresql-server-dev-15 libpq-dev注意postgresql-server-dev-15必须和你的 PostgreSQL 主版本严格一致15不能写成15.5。下载并编译 pgvectorgit clone https://github.com/pgvector/pgvector.git cd pgvector # 切换到与你的 PostgreSQL 大版本匹配的分支比如 15.x git checkout v0.5.2 make sudo make installmake install会把vector.so文件复制到 PostgreSQL 的lib目录把vector.control和vector--*.sql复制到share/extension目录。在数据库中启用扩展\c hindsight_db CREATE EXTENSION IF NOT EXISTS vector;执行成功后运行\dx应该能看到vector | 0.5.2 | public | Vector similarity search for PostgreSQL。如果报错could not open extension control file说明make install没把文件放到正确位置检查pg_config --pkglibdir和pg_config --sharedir的输出路径是否匹配。提示Windows 用户请直接使用 EDB 提供的 Stack Builder 工具安装 pgvector手动编译在 MinGW 环境下极其痛苦且容易因路径空格导致链接失败。3.3 Hindsight 配置文件详解那些文档里没写的参数陷阱Hindsight 的配置文件config.yaml看似简单但几个参数的取值直接影响性能和稳定性database: url: postgresql://hindsight_user:your_strong_passwordlocalhost:5432/hindsight_db # 关键必须加上 ?sslmodedisable除非你真配了 TLS # 如果漏掉Hindsight 启动时会卡在连接池初始化日志无任何错误 pool_max: 20 # 不要设太高PostgreSQL 默认 max_connections100Hindsight 20个连接 Hermes 自身连接 DBA 连接很容易打满 # 实测 10-15 是安全水位 embedding: model: text-embedding-3-small # OpenAI 官方模型但注意Hindsight 会调用 OpenAI API你需要设置 OPENAI_API_KEY 环境变量 # 如果想完全离线必须替换成本地模型比如 sentence-transformers/all-MiniLM-L6-v2需修改 Hindsight 源码 batch_size: 32 # 向量化批量大小32 是平衡速度和内存的甜点值设成 128 在 16G 内存机器上可能 OOM server: host: 0.0.0.0 port: 8000 # 生产环境务必用 nginx 反向代理Hindsight 自带的 Uvicorn 不适合直接暴露公网最关键的隐藏参数在database.pool_max。很多团队为了“追求性能”设成 50结果发现 PostgreSQL 日志里疯狂刷too many connectionsHermes 调用 Hindsight 接口开始超时。这是因为 PostgreSQL 的连接是重量级资源每个连接占用数 MB 内存。一个健康的连接池应该满足pool_max (max_connections - 20)预留 20 个连接给 DBA 和其他服务。4. 实操过程与核心环节实现从零部署 Hindsight 并接入 Hermes4.1 环境准备与依赖安装Python、Poetry 与系统级依赖Hindsight 是 Python 项目但它的依赖管理用了 Poetry而不是 pip。Poetry 能精确锁定依赖版本避免requests升级导致的 SSL 错误这类玄学问题。部署前请确保系统已安装Python 3.10Hindsight 依赖asyncio的新特性3.9 及以下会报SyntaxError: invalid syntax。Poetry用官方安装脚本curl -sSL https://install.python-poetry.org | python3 -不要用pip install poetry后者在某些 Linux 发行版上会因 setuptools 版本冲突失败。系统级依赖libpq-devPostgreSQL 客户端库、build-essential编译 pgvector 所需。Ubuntu/Debiansudo apt install -y libpq-dev build-essential验证 Poetry 是否正常poetry --version # 输出应为 1.7.0 poetry env use 3.10 # 创建一个干净的 Python 3.10 虚拟环境注意不要在系统 Python 环境里pip install任何东西。Poetry 会为你创建隔离环境这是避免“在我机器上能跑”的终极保障。4.2 Hindsight 源码获取与定制化构建Hindsight 的 GitHub 仓库https://github.com/ai-hindsight/hindsight是公开的但它的main分支是开发版不稳定。生产环境必须使用 Release Tag比如v0.3.1。下载并解压后进入目录# 修改 poetry.lock 文件强制指定 pgvector 的 Python 客户端版本 # 找到 [package.dependencies] 下的 pgvector 行改为 # pgvector { version ^0.5.2, source pypi } # 这是因为新版 pgvector 0.6.0 依赖了 psycopg3而 Hindsight 还在用 psycopg2 poetry install poetry run python -m hindsight --help # 如果看到帮助信息说明环境搭建成功如果你需要完全离线不调用 OpenAI API必须替换嵌入模型。Hindsight 的src/hindsight/embedding.py里有一个OpenAIEmbedding类。你可以继承它写一个LocalEmbeddingfrom sentence_transformers import SentenceTransformer class LocalEmbedding: def __init__(self): self.model SentenceTransformer(all-MiniLM-L6-v2) def embed(self, texts: List[str]) - List[List[float]]: return self.model.encode(texts).tolist()然后在config.yaml里把embedding.model改成local并在poetry.lock里添加sentence-transformers ^2.2.2。这个过程需要重新poetry install但换来的是 100% 的数据不出内网。4.3 数据库 Schema 初始化与向量索引优化Hindsight 启动时会自动创建memories表但不会自动创建向量索引。这是故意为之的设计索引创建是耗时操作应该由 DBA 在低峰期手动执行避免服务启动卡死。表结构如下精简版CREATE TABLE memories ( id SERIAL PRIMARY KEY, content TEXT NOT NULL, embedding vector(1536), -- 维度必须和你用的嵌入模型一致 user_id VARCHAR(255) NOT NULL, session_id VARCHAR(255), tags JSONB, created_at TIMESTAMP WITH TIME ZONE DEFAULT NOW() );创建高效索引是性能分水岭。pgvector 提供两种主流索引IVFFlat速度快内存占用小适合中小规模 100 万向量HNSW精度更高查询更稳定适合大规模但构建慢、内存占用大。对于 Hermes 场景IVFFlat 是更优选择。创建命令-- 先创建索引但不指定列表数lists让 pgvector 自动估算 CREATE INDEX ON memories USING ivfflat (embedding vector_cosine_ops) WITH (m 16, lists 100); -- m 是图的出度16 是平衡精度和速度的推荐值lists 是聚类数100 对应约 10 万向量lists参数需要根据你的数据量调整lists ≈ sqrt(n)其中n是预估的总向量数。如果n100000lists316如果n10000lists100。设得太小召回率暴跌设得太大索引体积爆炸。我们实测过一个 5 万向量的memories表lists224时95% 的查询在 15ms 内返回而lists100时20% 的查询超过 50ms。提示索引创建后务必运行ANALYZE memories;更新统计信息否则 PostgreSQL 查询规划器可能选错执行计划。4.4 Hermes 侧集成三行代码让 Agent 拥有记忆Hindsight 集成到 Hermes核心就是两处 HTTP 调用。假设 Hermes 是用 Python FastAPI 写的你在处理完一次用户对话后import httpx # 在 Hermes 的对话处理器里添加记忆逻辑 async def handle_conversation(user_input: str, user_id: str, session_id: str): # ... Hermes 原有的 LLM 调用逻辑 ... llm_response await call_llm(user_input) # 新增将本次对话存入 Hindsight async with httpx.AsyncClient() as client: try: # 构造记忆内容包含原始输入、LLM 回复、关键元数据 memory_payload { content: fUser: {user_input}\nAssistant: {llm_response}, user_id: user_id, session_id: session_id, tags: [conversation] } resp await client.post( http://localhost:8000/remember, jsonmemory_payload, timeout10.0 # 必须设超时避免 Hindsight 挂掉拖垮 Hermes ) if resp.status_code ! 200: logger.warning(fHindsight remember failed: {resp.text}) except Exception as e: logger.error(fHindsight network error: {e}) return llm_response当 Hermes 需要“回忆”时比如用户问“上次我说的方案呢”在调用 LLM 前先查 Hindsightasync def get_relevant_memories(query: str, user_id: str) - str: async with httpx.AsyncClient() as client: try: resp await client.get( fhttp://localhost:8000/recall?query{query}user_id{user_id}limit3, timeout5.0 ) if resp.status_code 200: memories resp.json() # 把召回的记忆拼成上下文喂给 LLM context \n.join([f[Memory {i1}]: {m[content]} for i, m in enumerate(memories)]) return context except Exception as e: logger.error(fHindsight recall error: {e}) return 这两段代码就是全部。不需要改 Hermes 的核心框架不需要引入新 SDK就是标准的 HTTP 请求。我们在线上环境跑了三个月平均 P99 延迟 8msHindsight 服务 CPU 使用率峰值 12%证明这个设计足够轻量。5. 常见问题与排查技巧实录那些踩过的坑和速查表5.1 “Hindsight 启动成功但 Hermes 调用 500 错误” —— 数据库连接池耗尽现象Hindsight 日志显示Uvicorn running on http://0.0.0.0:8000但 Hermes 调用/remember返回500 Internal Server ErrorHindsight 日志里却没有任何错误。排查思路这不是代码错误是数据库连接被占满。用ps aux | grep postgres查看 PostgreSQL 进程执行SELECT * FROM pg_stat_activity WHERE state active;你会发现大量idle in transaction状态的连接来源是hindsight_user。根因Hindsight 的异步连接池在异常情况下比如网络抖动、HTTP 超时没有正确释放连接。解决方案是在config.yaml中显式配置连接超时和健康检查database: url: postgresql://hindsight_user:...localhost:5432/hindsight_db?connect_timeout5 pool_max: 12 pool_min: 2 # 添加健康检查每 30 秒 ping 一次连接 health_check_interval: 30同时在 Hermes 的调用代码里httpx.AsyncClient必须用with语句包裹确保异常时也能关闭连接# 正确写法 async with httpx.AsyncClient(timeout10.0) as client: resp await client.post(...) # 错误写法client httpx.AsyncClient()然后忘记 close()5.2 “召回结果完全不相关” —— 向量维度不匹配的静默失败现象Hindsight 能正常存取数据SQL 查询SELECT * FROM memories也能看到embedding字段有值但/recall返回的结果和查询词毫无关系比如搜“付款周期”返回的却是“会议纪要”。根因嵌入模型输出的向量维度和 PostgreSQL 表里vector(N)的N不一致。比如你用text-embedding-3-small1536 维但建表时写了embedding vector(768)。pgvector 不会报错它会把 1536 维向量的前 768 个数截出来存后半部分丢弃导致向量失真。验证方法在psql里执行SELECT array_length(embedding, 1) FROM memories LIMIT 1; -- 如果返回 768但你的模型是 1536那就错了修复步骤删除旧索引DROP INDEX CONCURRENTLY IF EXISTS memories_embedding_idx;修改列类型ALTER TABLE memories ALTER COLUMN embedding TYPE vector(1536);重建索引CREATE INDEX CONCURRENTLY ON memories USING ivfflat (embedding vector_cosine_ops) WITH (m 16, lists 100);重新向量化所有历史数据用 Hindsight 的/reindex端点或写脚本调用/remember重发注意ALTER COLUMN TYPE在大数据量时会锁表务必在维护窗口执行。5.3 “Hindsight 内存持续上涨最后 OOM” —— 嵌入模型缓存未清理现象Hindsight 进程的 RSS 内存每天增长 200MB一周后达到 2GB系统开始杀进程。根因Hindsight 使用的openaiPython SDK 默认启用了httpx的连接池和requests的 Session 缓存而嵌入模型调用是高频小请求缓存碎片化严重。更致命的是text-embedding-3-small的openaiSDK 会把模型的 tokenizer 缓存在内存里不释放。解决方案在config.yaml中禁用所有缓存embedding: model: text-embedding-3-small # 添加以下两行 cache_dir: /dev/null # 强制 tokenizer 不缓存 # 并在启动 Hindsight 前设置环境变量 # export OPENAI_API_BASEhttps://api.openai.com/v1 # export OPENAI_TIMEOUT30同时在src/hindsight/embedding.py的OpenAIEmbedding.embed方法里显式关闭httpx连接池async def embed(self, texts: List[str]) - List[List[float]]: async with httpx.AsyncClient(timeout30.0, limitshttpx.Limits(max_connections10)) as client: # ... 调用 OpenAI API ...这个改动让 Hindsight 的内存稳定在 300MB 以内P99 响应时间反而下降了 2ms因为减少了 GC 压力。5.4 常见问题速查表问题现象最可能原因快速验证命令解决方案CREATE EXTENSION vector报错could not open extension control filepgvector 未正确make installpg_config --sharedir检查该路径下是否有extension/vector.control重新执行make install确认路径权限Hermes 调用 Hindsight 超时但curl http://localhost:8000/health正常Hindsight 连接池被占满SELECT count(*) FROM pg_stat_activity WHERE usename hindsight_user;降低pool_max增加health_check_interval/recall返回空数组但SELECT * FROM memories有数据memories表没有创建 IVFFlat 索引\d memories检查是否有memories_embedding_idx手动执行CREATE INDEX ...向量搜索结果相关性差ORDER BY embedding - ...返回随机行embedding字段为空或为 NULLSELECT id, content, embedding IS NULL FROM memories LIMIT 5;检查 Hindsight 日志确认嵌入调用是否成功检查 OpenAI API Key 是否有效Hindsight 启动时报ModuleNotFoundError: No module named psycopg2Poetry 环境未激活或依赖未安装poetry shell然后python -c import psycopg2poetry install确保pyproject.toml中psycopg2-binary ^2.9.76. 性能压测与线上调优从 100 QPS 到 1000 QPS 的实战经验6.1 压测工具选型与基准场景设计我们没有用 JMeter 这种重型工具而是用hey一个 Go 写的轻量级压测工具模拟真实流量# 模拟 Hermes 的典型调用每秒 200 次 /remember携带 200 字符的 content hey -z 5m -q 200 -c 50 -m POST -H Content-Type: application/json \ -d {content:User: What is the payment term? Assistant: The term is 30 days.,user_id:test,session_id:sess_001} \ http://localhost:8000/remember参数解读-z 5m压测 5 分钟-q 200每秒 200 请求-c 50并发连接数模拟 50 个 Hermes worker。这个配置对应一个中等规模的客服团队50 个坐席每人每分钟发起 4 次记忆写入。基准环境AWS t3.xlarge4 vCPU, 16GB RAMPostgreSQL 15.5 单机Hindsight 用uvicorn启动--workers 4 --host 0.0.0.0:8000。6.2 从 100 QPS 到 1000 QPS 的四次关键调优第一次调优连接池与超时QPS 100 → 250初始配置pool_max20压测到 120 QPS 时Hindsight 开始大量报Connection pool is full。我们将pool_max提升到 30并在config.yaml中添加database: acquire_timeout: 5.0 # 获取连接超时避免排队 idle_timeout: 300.0 # 空闲连接超时及时释放效果QPS 稳定在 250P95 延迟从 120ms 降到 45ms。第二次调优向量索引参数QPS 250 → 500QPS 300 时/recall的 P95 延迟飙升到 200ms。EXPLAIN ANALYZE显示查询在Bitmap Heap Scan阶段耗时过长。原因是 IVFFlat 的lists参数太小100导致每个列表里向量过多扫描成本高。我们将lists从 100 提升到 316sqrt(100000)并增加m32DROP INDEX CONCURRENTLY memories_embedding_idx; CREATE INDEX CONCURRENTLY ON memories USING ivfflat (embedding vector_cosine_ops) WITH (m 32, lists 316);效果/recallP95 降到 25ms整体 QPS 提升到 500。第三次调优嵌入模型批处理QPS 500 → 750瓶颈转移到/remember的嵌入计算。OpenAI API 的text-embedding-3-small有速率限制每分钟 15000 token而我们的请求是小文本但并发高频繁触发限流。解决方案是启用 Hindsight 的内置批处理embedding: batch_size: 64 # 从 32 提升到 64 # Hindsight 会把 64 个请求合并成一个 API 调用token 利用率翻倍效果OpenAI API 调用次数减少 40%QPS 提升到 750P95 延迟稳定在 35ms。第四次调优读写分离与连接复用QPS 750 → 1000达到 800 QPS 时PostgreSQL 的max_connections默认 100再次告警。我们没有盲目调大max_connections这会导致内存爆炸而是做了两件事读写分离Hindsight 的/recall是只读/remember是写。我们配置了两个数据库连接串/recall连接到一个只读副本PostgreSQL 的物理复制/remember连接到主库。连接复用在 Hermes 侧把httpx.AsyncClient提升为全局 session而不是每次请求都新建# 在 Hermes 启动时创建一次 hindsight_client httpx.AsyncClient( base_urlhttp://hindsight-service:8000, timeouthttpx.Timeout(10.0, read30.0) ) # 所有请求复用这个 client最终系统在 1000 QPS 下稳定运行P95 延迟 42msPostgreSQL 主库 CPU 使用率 65%内存占用 8GB16GB 总内存完全在安全水位内。6.3 线上监控的三个黄金指标部署后我们只监控三个指标就能 90% 预判问题Hindsight 的http_requests_total{code~5..}5xx 错误率超过 0.1%立刻查日志90% 是数据库连接或 OpenAI API 问题。PostgreSQL 的pg_stat_database.blks_hit_ratio缓存命中率低于 95%说明 shared_buffers 不够需要调大shared_buffers参数。Hindsight 进程的process_resident_memory_bytesRSS 内存连续 2 小时增长超过 100MB大概率是嵌入模型缓存泄漏需要重启。这三个指标用 Prometheus Grafana 拉取Dashboard 就一页DBA 和 SRE 都能一眼看懂。复杂的监控只会增加噪音而不会增加可靠性。7. 安全加固与生产就绪 checklist让记忆