Agent Fleets के लिए साझा मेमोरी: hermes-memory-pgvector
जब आप एक से अधिक AI agent चलाते हैं — एक marketing minion, एक trading minion, एक incident-response minion — तो हर एक को memory चाहिए। Built-in memory tool हर agent को उसकी अपनी memory देता है। यह तब तक ठीक है, जब तक आप उन्हें इसे साझा कराना न चाहें, या तब तक जब तक आप यह याद न करना चाहें कि agent ने छह हफ्ते पहले क्या सीखा था, सिर्फ़ यह देखने के लिए एक LLM round-trip पर भुगतान किए बिना।
hermes-memory-pgvector एक छोटा Postgres + pgvector प्लगइन है जो agent memory writes को एक साझा, embedded, queryable store में mirror करता है। v0.4.0 पर PyPI में प्रकाशित।
v0.4.0 में नया
नवीनतम रिलीज़ "no LLM in the hot path" नियम को बनाए रखती है और storage layer में चार क्षमताएँ जोड़ती है:
- Identity governance. Direct-message session keys एक single privacy-safe bucket में collapse हो जाते हैं — no per-contact theme sprawl, no PII — benchmark traffic quarantined रहता है, और एक optional allow-list typo'd theme names को चुपचाप नया बनाने के बजाय एक safe default पर route करती है।
- Agent attribution & delegation. एक नया registry और provenance edges रिकॉर्ड करते हैं कि किस agent ने क्या किसे delegate किया, जिसे database view के माध्यम से query किया जा सकता है। Pure who/when provenance — कभी भी fact store नहीं।
- Embedding backfill. Embedding-endpoint outage के दौरान text-only लिखी गई rows अब stranded नहीं रहतीं: एक idempotent command उन्हें फिर से embed करता है ताकि वे दोबारा searchable हो जाएँ।
- Conversation TTL & cost controls. Operator-run prune पुराने chat turns को trim करता है (durable memories को कभी नहीं छुआ जाता), और एक embed policy embedding cost को ऊपर या नीचे करती है।
यह सब एक maintenance CLI (hermes-pgvector) के पीछे ship होता है, जिसके destructive commands डिफ़ॉल्ट रूप से dry-run होते हैं। v0.4.0, v0.3.x से drop-in upgrade है — एक additive migration लागू करें और नए hooks चालू हो जाते हैं; इसे छोड़ दें और बाकी सब कुछ अपरिवर्तित चलता रहता है।
यह वास्तव में क्या करता है
एक वाक्य में: "एक storage layer जो built-in memory model को टिकाऊ, multi-tenant, semantically-searchable backing देती है, बिना hot path में LLM के."
दो tables, दोनों में HNSW vector indexes हैं। memory_entries agent की MEMORY.md/USER.md files में लिखी गई चीज़ों को mirror करता है। conversations सार्थक chat turns (≥40 chars, boilerplate filtered out) को store करता है। Embeddings 768-dim हैं, एक external endpoint — Ollama, OpenAI-compatible, आपकी पसंद — द्वारा computed। Agent कभी उस पर block नहीं होता: writes microseconds में return होती हैं और embedding worker बाकी काम background queue पर संभालता है।
डिफ़ॉल्ट रूप से प्रति-agent themes
हर request के साथ एक X-Hermes-Session-Key header आता है जो agent_identity के अनुसार data को scope करता है। Marketing के notes trading की recall को contaminate नहीं करते। जब आपको वास्तव में cross-theme search चाहिए हो, तो scope='all' को explicitly pass करें। डिफ़ॉल्ट safe वाला है।
standalone क्यों, fork क्यों नहीं
hermes-agent ने नीति के कारण अपनी built-in memory provider list बंद कर दी, इसलिए यह upstream fork के बजाय एक अलग /plugins directory scan के रूप में मौजूद है। इसे agent के पास रखें, कुछ config keys सेट करें, restart करें। Rollback symmetric है: provider disable करें, वैकल्पिक रूप से tables drop करें। Migrate करने के लिए कोई लंबे समय तक रहने वाला state नहीं, बनाए रखने के लिए कोई kernel patches नहीं।
यह क्या नहीं है
Honcho replacement नहीं। Knowledge graph नहीं। RAG framework नहीं। यह जानबूझकर एक पतली layer है जो एक ही काम करती है — built-in memory tool को एक shared, durable, vector-searchable store में बदलना — और रास्ते से हट जाती है। कोई LLM deriver नहीं, कोई dialectic loop नहीं, यह तय करने पर कोई राय नहीं कि आपको कैसे chunk या rerank करना चाहिए। बस vector math।
इसे प्राप्त करें
pip install hermes-memory-pgvector
Source, migration, और config GitHub पर: