Agent Memory: Kailan Naluluma at Paano Mag-Prune

Bakit naluluma ang agent memory

Naluluma ang agent memory dahil may fact na isang beses lang isinusulat at hindi na muling sinusuri. Patuloy itong ibinabalik ng store, inilalagay ito ng retrieval layer sa prompt bilang plain text na walang kalakip na petsa, at inuulit ito ng model nang may kaparehong kumpiyansa tulad noong araw na isinulat ito. Walang nagti-throw ng error. Iyan ang buong hamon: magkaparehong-mukha ang stale memory at fresh memory para sa model at sa iyo.

Hindi nito naaayos ang problema ang mas maingat na pagsusulat kapag sine-save ang data. Ang nakalulutas dito ay expiry para sa mga fact na nangangailangan nito, at review routine para sa mga fact na hindi nangangailangan ng expiry. Pareho itong ordinaryong maintenance sa isang maliit na database, at karamihan ng trabaho ay SQL (structured query language).

Magkaibang failure ang decay at drift

Ang decay ay impormasyong may natural na expiration date. “Naglalakbay ngayong linggo.” “Down ang staging box para sa migration.” “Sinusuri ang budget draft.” Totoo ang mga ito nang isulat, at matutukoy mo agad kung gaano katagal mananatiling wasto ang mga ito. Nalulutas ang decay. Maglagay ng expiration, na tinatawag ding TTL (time to live), at i-delete ang row kapag lumampas na rito.

Ang drift ay impormasyong isang beses lang in-store at hindi na muling sinusuri. “Mas gusto ang pnpm.” “Postgres 15 ang database.” “Sa staging branch dumadaan ang mga deployment.” Walang oras na awtomatikong magpapawalang-bisa sa mga ito. Isang desisyon sa ibang lugar ang gumagawa nito, at walang nagsasabi sa memory store mo tungkol sa pagbabago.

Walang maayos na automated fix para sa drift. Hindi makikita ng store ang pagbabagong hindi nito naobserbahan, kaya ang job na nagbabasa sa store at nagre-reason tungkol dito ay inuulit lang ang pagbasa sa parehong lumang text. Ang gumaganang paraan ay muling i-check ang impormasyon laban sa bagay na inilalarawan nito. Nangangailangan ito ng tao o agent na may tool para mabasa ang kasalukuyang state.

Kaya dalawang bahagi ang plano. I-expire ang nagde-decay. I-review ang nagda-drift. Huwag ituring ang ikalawang problema na para bang una itong problema.

Maglagay ng expiry sa mga fact na may takdang bisa

Kailangan ng bawat memory row ng tatlong column na karaniwang wala sa karamihan ng store: kung saan nagmula ang fact, kung kailan ito huling nakumpirma, at kung kailan ito titigil na maging totoo. Store ito na mabubuo mo gamit lamang ang sqlite3, at maaaring idagdag ang parehong mga column sa store na ginagamit mo na.

CREATE TABLE memory (
  id            TEXT PRIMARY KEY,
  subject       TEXT NOT NULL,
  fact          TEXT NOT NULL,
  source        TEXT NOT NULL,
  created_at    TEXT NOT NULL DEFAULT (datetime('now')),
  confirmed_at  TEXT NOT NULL DEFAULT (datetime('now')),
  expires_at    TEXT,
  superseded_by TEXT REFERENCES memory(id) ON DELETE CASCADE
);

CREATE INDEX memory_expires ON memory(expires_at);
CREATE INDEX memory_superseded ON memory(superseded_by);

Ibinabalik ng datetime('now') ang UTC (coordinated universal time) bilang YYYY-MM-DD HH:MM:SS, na tamang pinagbubukod at ipinaghahambing bilang text. Dahil dito, ang bawat date question sa ibaba ay simpleng WHERE clause. Hindi optional ang source column. Ang fact na hindi mo matutunton pabalik sa isang message, file, o command output ay hindi na muling mabe-verify. Ang fact na hindi na mabe-verify ay maaari lamang i-delete.

Pagsulat ng memory na may expiry:

INSERT INTO memory (id, subject, fact, source, expires_at)
VALUES ('m_0191', 'availability', 'Away from keyboard, replies are delayed',
        'chat 2026-08-08', datetime('now', '+7 days'));

Hindi dapat direktang magbasa ng table ang retrieval. Magbasa ito ng view na nagtatago ng mga expired at superseded row:

CREATE VIEW live_memory AS
SELECT id, subject, fact, source, confirmed_at, expires_at
FROM memory
WHERE superseded_by IS NULL
  AND (expires_at IS NULL OR expires_at > datetime('now'));

Mahalagang bahagi ang view dahil ginagawa nitong hindi nakapipinsala ang nakaligtaang prune. Hindi na ire-retrieve ang expired row sa mismong pag-expire nito, tumakbo man o hindi ang delete job. Ang delete job ay kumokontrol na lamang sa paggamit ng disk at review load, hindi sa correctness.

Suriin ang gap gamit ang sqlite3 memory.db "SELECT count(*) FROM memory;" at ang parehong count laban sa live_memory. Sa healthy na store, magkalapit ang dalawang numero. Ang malaking gap ang backlog mo ng mga patay na row.

Bakit naiiwan ang lumang memory kapag nagde-delete

Magkapares ang mga correction. Natututuhan ng agent na lumipat ka mula npm patungong pnpm, nagsusulat ito ng bagong row, at itinuturo ang lumang row dito:

UPDATE memory SET superseded_by = 'm_0207' WHERE id = 'm_0140';

Hindi na nakikita ngayon ng live_memory ang lumang row, at itinatala pa rin ng chain kung ano ang nagbago. Ngayon, i-delete ang m_0207 dahil napatunayang mali ito. Dapat isama ng ON DELETE CASCADE sa superseded_by ang m_0140, dahil ang lumang row ang child sa relasyong iyon. Karaniwan, hindi ito nangyayari dahil binabalewala ng SQLite ang foreign keys maliban kung i-enable mo ang mga ito, at naka-off ang default:

sqlite3 memory.db "PRAGMA foreign_keys;"

Ipinapakita nito ang 0 sa stock build. Kapag naka-off ang foreign keys, nagtatagumpay ang DELETE FROM memory WHERE id = 'm_0207'; at naiiwan ang m_0140, na nakaturo sa isang id na wala na. Walang nagbababala sa iyo. Nakatago ngayon ang row na iyon sa maling dahilan, at ibinabalik ng unang tidy-up script na nagre-reset ng mga dangling pointer sa NULL ang "prefers npm" sa live_memory.

Hanapin ang mga sirang chain:

sqlite3 memory.db "PRAGMA foreign_key_check;"

Iniuulat ng foreign_key_check ang mga violation kahit naka-off ang enforcement, kaya gumagana ito sa dati nang kaguluhan. Nagpi-print ito ng isang row para sa bawat violation: ang table, ang rowid, ang parent table, at kung aling foreign key ang hindi pumasa. Kapag walang output, buo ang mga chain.

Maikli ang sumusunod na rule. Per-connection setting ang PRAGMA foreign_keys = ON;, kaya kailangan ito ng bawat connection: ng iyong application, ng iyong prune script, at ng sqlite3 session na tina-type-an mo. Ilagay ito bilang unang linya ng bawat SQL file na nagde-delete ng anuman.

Kung saan talaga naka-store ang iyong memories

Bago mag-delete ng anuman, alamin muna kung ilang store ang ginagamit mo. Karaniwang sine-save ng self-hosted memory service ang memory text at embedding nito sa isang vector database, at nagse-save naman ng change log sa SQLite. Magkaibang file ang mga ito at magkaiba ang lifecycle. Maaari ring magkahiwalay silang mag-fail.

Magandang halimbawa ang mem0, at makikita rin ang ganitong setup sa ibang system. Bilang default, ginagamit ng open source library nito ang Qdrant vector store sa /tmp/qdrant, sa isang collection na may pangalang mem0, at gumagamit ito ng SQLite change log sa ~/.mem0/history.db na ang lokasyon ay nakadepende sa MEM0_DIR environment variable. Nasa history table ang memory_id, old_memory, new_memory, event, created_at at is_deleted.

Basahin muli ang listahan ng column na iyon. Change log ang SQLite file. Nasa Qdrant mismo ang mga memory, kaya kapag nag-delete ka ng rows mula sa history.db, matatanggal ang record na may nagbago pero mananatiling nare-retrieve ang memory. Kailangang dumaan ang deletion sa sariling API (application programming interface) ng library para ma-update ang parehong location:

from mem0 import Memory

memory = Memory()
memory.delete(memory_id="mem_123")
memory.delete_all(user_id="alice")

Nangangailangan ng hiwalay na babala ang default na /tmp. Sa Ubuntu 24.10 at mas bago, tmpfs ang /tmp, isang filesystem na nasa memory, kaya walang laman ito pagkatapos ng bawat reboot at mawawala ang buong store. Suriin ang iyo gamit ang findmnt /tmp. Kapag may linyang nagpapakita ng tmpfs, ilipat agad ang path:

config = {
    "vector_store": {
        "provider": "qdrant",
        "config": {"collection_name": "mem0", "path": "/srv/agent/qdrant"},
    }
}
memory = Memory.from_config(config)

Pareho ang tanong anuman ang ginagamit mong software. Basahin ang config at itala ang bawat path na sinusulatan ng service. Saklaw ng Pagpapatakbo ng mem0 memory server sa sarili mong VPS ang service side nito, at ang pagpapanatili ng agent memory sa isang machine lamang ay mas maliit na store na pareho pa rin ang maintenance requirements.

Pagbasa sa store gamit ang sqlite3

I-install ang CLI (command line interface) kung wala pa ito, gamit ang sudo apt install -y sqlite3. Pagkatapos, masasagot ng apat na command ang karamihan sa mga tanong tungkol sa anumang store sa iyong disk.

• Inililista ng sqlite3 ~/.mem0/history.db ".tables" ang mga table. Ibig sabihin ng walang output ay maling file ang binuksan mo.
• Ipinapakita ng sqlite3 ~/.mem0/history.db ".schema history" ang eksaktong mga column. Ito lamang ang maaasahang dokumentasyon ng structure ng store.
• Ipinapakita ng sqlite3 -cmd ".mode line" ~/.mem0/history.db "SELECT * FROM history ORDER BY created_at DESC LIMIT 5;" ang limang pinakabagong pagbabago, isang field bawat linya. Nananatili itong madaling basahin kapag paragraph ang laman ng isang column.
• Ipinapakita ng sqlite3 ~/.mem0/history.db "SELECT event, count(*) FROM history GROUP BY event;" kung ano ang ginagawa ng store at kung aling mga event name ang aktuwal na sinusulat ng iyong library.

Hindi database ang lahat ng memory store. Ang plain file na naglalaman ng mga note at binabasa sa simula ng bawat session ay may parehong mga problema at wala ring mga tool para rito: walang expiry column, walang nakumpirmang petsa, at walang view para itago ang mga lumang row. Lagyan ng petsa ang bawat linyang manu-mano mong isinusulat, at basahin itong muli bawat buwan. May parehong problema ang Memory na nagpapatuloy sa mga Claude Code session, ngunit nasa mas maliit na saklaw.

Pagsusuri sa mga fact na hindi nag-e-expire

Kailangan ng drift ng queue, limit, at nakasanayan. Ang queue ay binubuo ng mga pinakamatandang confirmation:

SELECT id, subject, fact, source, confirmed_at
FROM live_memory
WHERE confirmed_at < datetime('now', '-90 days')
ORDER BY confirmed_at
LIMIT 20;

Ang dalawampung row bawat linggo ay review na talagang gagawin. Ang apatnaraang row ay review na walang gagawa, kaya babalik ka lang sa dati mong kalagayan. Para sa bawat row, may dalawang posibleng resulta. I-check itong muli laban sa source nito at lagyan ng stamp:

UPDATE memory SET confirmed_at = datetime('now') WHERE id = 'm_0140';

O palitan ito: i-insert ang bagong fact, itakda ang superseded_by ng lumang row sa bagong ID, at hayaang panatilihin ng chain ang history.

Dalawang nakasanayan ang nagpapadali nito. Panatilihing maliit ang store, dahil nagiging imposibleng i-review ang store na patuloy lang lumalaki: magdagdag ng column na last_used_at, i-update ito kapag aktuwal na na-retrieve ang isang row, at ituring na kandidato para sa deletion ang mga row na hindi nagamit sa loob ng anim na buwan. Isang write lang bawat retrieval ang kailangan nito, kaya i-batch ito kung madalas magpadala ng request ang agent.

Walang dagdag na gastos ang ikalawang nakasanayan. Isama ang edad sa prompt. Kung dala ng memory block na binubuo ng retriever ang confirmed 2026-05-02 sa tabi ng bawat fact, maaaring sabihin ng model na “noong Mayo, pnpm ang ginagamit mo” sa halip na ilahad ito na parang kasalukuyang katotohanan. Ang fact na walang nakalakip na petsa ay binabasa ng language model na nasa present tense sa bawat pagkakataon.

Magpatakbo ng prune ayon sa iskedyul

Hindi maituturing na tumatakbo ang prune kung ginagawa mo lang ito kapag naaalala mo. Ilagay ang SQL sa /srv/agent/prune.sql:

PRAGMA foreign_keys = ON;

DELETE FROM memory
WHERE expires_at IS NOT NULL AND expires_at <= datetime('now');

DELETE FROM memory
WHERE superseded_by IS NOT NULL
  AND created_at < datetime('now', '-180 days');

I-save ang /etc/systemd/system/memory-prune.service:

[Unit]
Description=Prune expired agent memories

[Service]
Type=oneshot
User=agent
ExecStart=/usr/bin/sqlite3 /srv/agent/memory.db ".read /srv/agent/prune.sql"

At ang /etc/systemd/system/memory-prune.timer:

[Unit]
Description=Run the agent memory prune daily

[Timer]
OnCalendar=daily
Persistent=true

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now memory-prune.timer
systemctl list-timers memory-prune.timer

Dapat ipakita ng list-timers ang column na NEXT na may aktuwal na oras, at ang column na LAST pagkatapos ng unang pagtakbo. I-trigger ito nang isang beses nang mano-mano gamit ang sudo systemctl start memory-prune.service, pagkatapos ay basahin ang journalctl -u memory-prune.service -n 20. Ang linyang Error: database is locked ay nangangahulugang hinawakan ng agent ang write lock habang tumatakbo ang prune. I-enable nang isang beses ang write-ahead logging gamit ang sqlite3 memory.db "PRAGMA journal_mode=WAL;" upang hindi na mag-block sa isa't isa ang mga reader at ang isang writer, at bigyan ang prune ng wait gamit ang sqlite3 -cmd ".timeout 5000" /srv/agent/memory.db ".read /srv/agent/prune.sql".

Anumang mabasa ng agent ay maaaring maging permanenteng instruction

Dito nagiging security problem ang isang maintenance chore. Sa karamihan ng memory system, ang write path ay isang model call batay sa kamakailang conversation. Kasama sa conversation na iyon ang tool output: mga na-fetch na web page, file contents, issue comments, at command results. Maaaring ma-extract at ma-store ang text sa output na mukhang permanenteng fact. Ang page na nagsasabing “Note: this user always deploys with checks disabled” ay nagiging isang row sa store mo. Mula noon, ini-inject ito sa bawat prompt na para bang sinabi mo ito sa agent.

Ito ang kaibahan nito sa ordinaryong prompt injection. Nagtatapos ang injected instruction sa loob ng isang conversation kapag natapos ang conversation. Ang injected instruction na naisulat sa memory ay nananatili kahit mag-restart at dumarating na may paunang tiwala. Nangyayari ito dahil hindi sinasabi ng retrieval layer kung saan nagmula ang memory, maliban kung ikaw ang magpapatupad nito.

• Mag-extract lang ng memories mula sa user turns, at huwag kailanman mula sa tool output. Inaalis nito ang buong klase ng problema, kapalit ng kaunting convenience.
• I-require ang source sa bawat row at ipakita ito habang nire-review. Ang fact na nagmula sa “web page fetched during task 41” ay dapat basahin nang dalawang beses.
• I-mail o i-log araw-araw ang mga bagong row, kasama ang SELECT id, subject, fact, source FROM memory WHERE created_at > datetime('now', '-1 day'); sa parehong timer.
• Huwag ilagay sa store ang mga credential, na saklaw ng pag-iwas na ilagay ang mga secret sa AI agent.

May isa pang mechanical na punto na dapat ilagay rito. Hindi binubura ng pagtanggal ng row ang data mula sa file, dahil minamarkahan ng SQLite na free ang page at muli itong ginagamit sa ibang pagkakataon. Dahil dito, nababasa pa rin ang lumang text gamit ang strings memory.db hanggang sa ma-overwrite ito ng ibang data. Patakbuhin ang sqlite3 memory.db "VACUUM;" pagkatapos magtanggal ng sensitibong data. Muli nitong isinusulat ang buong file. Ginagawa ng PRAGMA secure_delete = ON; na i-overwrite ng connection na nagsasagawa ng delete ang ni-release na content gamit ang mga zero habang nagpapatuloy ito.

Ano ang dapat i-back up, at sa anong pagkakasunod-sunod

Maliit at mahirap buuing muli ang store, kaya i-back up ito nang maayos. Huwag kailanman kopyahin ang live database file gamit ang cp, dahil maaaring hindi mabuksan ang kopyang nakuha habang may isinusulat. Gamitin ang snapshot na built in sa SQLite:

sqlite3 /srv/agent/memory.db "VACUUM INTO '/srv/backup/memory-$(date +%F).db'"
sqlite3 /srv/backup/memory-$(date +%F).db "PRAGMA integrity_check;"

Ang pag-print ng integrity_check gamit ang ok ang tanging patunay na magagamit ang backup file. Anumang iba pa ay nangangahulugang panatilihin ang naunang backup at siyasatin muna ito bago ito ma-overwrite.

I-snapshot din ang vector store sa parehong job at sa parehong oras. Kung ilang oras ang pagitan ng pagkuha sa dalawang bahagi, paghahaluin ng restore ang bagong change log at lumang set ng memories, kaya muling lilitaw ang mga na-delete na fact. Isulat ang dalawa sa iisang dated directory para maaari lamang silang i-restore nang magkasama. Mas malalim na tinatalakay sa Pagpapatakbo ng SQLite sa production sa isang VPS ang locking, backups, at mga setting na kailangan ng isang matagalang tumatakbong service.

FAQ

Gaano katagal dapat manatili ang memory ng agent bago ito mag-expire?

Itakda ang expiry batay sa mismong fact, hindi sa global default. Ang travel note o note na “ginagawa ang project na ito ngayong linggo” ay maaaring bigyan ng pitong araw. Ang team convention o personal preference ay hindi kailangang lagyan ng expiry; ilagay ito sa review queue. Ang fact tungkol sa software version ay dapat magkaroon ng expiry na humigit-kumulang katumbas ng release cadence ng project. Kung hindi mo matukoy ang shelf life habang isinusulat ang fact, senyales iyon na dapat itong i-review sa halip na i-expire. Bigyan ito ng confirmed_at date at isama sa review.

Maaari bang awtomatikong matukoy kung mali na ang isang naka-store na fact?

Hindi nang mapagkakatiwalaan. Walang access ang store sa mga pangyayari sa labas nito, kaya hindi nito makikita ang pagbabagong nagpamali sa fact. Ang job na muling nagbabasa sa store ay binabasa lamang ulit ang parehong lumang text. Ang maaari mong i-automate ay ang paglalabas ng mga item para sa review: ayusin ayon sa confirmed_at at ilagay sa unahan ang pinakamatatandang row para sa isang tao, o para sa agent na may tool na makakabasa ng kasalukuyang state mula sa repository, config file, o monitoring endpoint. Makabubuting i-automate ang queue. Hindi pa handa ang automation para sa mismong verdict.

Nag-delete ako ng memory, pero bumalik ito. Bakit?

Karaniwan itong nangyayari dahil may dalawang store at sa isa ka lamang nagsulat. Karaniwang nasa vector database ang memory text at embedding nito, habang may SQLite file na naglalaman ng change log. Kaya kapag nag-delete ka ng mga row mula sa SQLite file, natatanggal ang audit record pero nananatiling retrievable ang memory. Mag-delete gamit ang library API upang parehong ma-update ang dalawang store. Ang isa pang karaniwang sanhi ay restore. Maaaring na-snapshot sa magkaibang oras ang vector store at SQLite file, kaya kapag nag-restore, bumabalik ang mga row na na-delete na ng kabilang bahagi.

Ligtas bang manu-manong mag-edit ng memory database habang tumatakbo ang agent?

Ligtas ang mga read. Ligtas lamang ang mga write kapag nasa write ahead logging mode, at isang writer lang ang dapat gumamit nito nang sabay-sabay. Patakbuhin ang sqlite3 memory.db "PRAGMA journal_mode;" upang makita kung anong mode ang ginagamit, at ang wal ang setting na kailangan mo. Kung makita mo ang Error: database is locked, may ibang process na may hawak ng write lock. Magtakda ng wait para sa session gamit ang sqlite3 -cmd ".timeout 5000", o ihinto muna ang agent service. Iba ang manu-manong pag-edit ng vector store: ipaubaya ito sa library, dahil kailangang manatiling consistent ang embedding at ang text nito.