Sebagian besar arsitektur memori agen AI yang beredar saat ini dibangun di atas fondasi yang rapuh: tumpukan wrapper LangChain yang lambat dan klaster Pinecone seharga ratusan dolar per bulan untuk sekadar menyimpan beberapa ratus megabita state dialog. Untuk agen otonom on-chain—terutama yang mengeksekusi modal riil tanpa intervensi manusia—desain seperti ini tidak hanya boros, tapi rapuh secara operasional.
Mari kita bedah arsitektur yang lebih waras: transisi dari SQLite lokal dengan FTS5 (Full-Text Search) dan ekstensi vektor sqlite-vec, menuju sinkronisasi terdistribusi via Cloud LibSQL (Turso).
Agen otonom kita berjalan di Base L2 (Chain ID 8453), mengendalikan hot wallet perbendaharaan: 0x92Aff59709b03b9373b8fA887D24953D60fAd919.
Ketika agen harus memutuskan alokasi likuiditas pada DEX lokal (seperti Aerodrome) atau mengevaluasi sinyal harga setiap 12 detik (interval block di Base adalah 2 detik), agen butuh dua hal secara simultan:
Menjalankan dua database terpisah (satu PostgreSQL, satu Vector DB cloud) memperkenalkan latensi jaringan ganda dan race condition. LibSQL memecahkan ini: mesin SQLite yang sama, mendukung query FTS5 untuk pencarian leksikal, vektor embedding native, dan replikasi cloud global via HTTP pipeline.
Kita menggabungkan indeks invers FTS5 standar SQLite dengan tabel vektor. Pendekatan hybrid search ini memberi penalti pada halusinasi embedding murni dengan cross-referencing token mentah.
-- Dijalankan pada LibSQL / Turso engine
CREATE TABLE IF NOT EXISTS agent_memory (
id INTEGER PRIMARY KEY AUTOINCREMENT,
timestamp INTEGER NOT NULL,
tx_hash TEXT,
content TEXT NOT NULL,
embedding F32_BLOB(384) -- all-MiniLM-L6-v2 output
);
-- Indeks leksikal FTS5 untuk pencarian hash transaksi dan alamat EVM
CREATE VIRTUAL TABLE IF NOT EXISTS memory_fts USING fts5(
content,
tx_hash UNINDEXED,
content='agent_memory',
content_rowid='id'
);
-- Indeks vektor native LibSQL
CREATE INDEX IF NOT EXISTS idx_memory_vec ON agent_memory(libsql_vector_idx(embedding));
Berikut adalah implementasi Python minimal tanpa abstraksi berlebih. Script ini membaca event on-chain Base, menghasilkan embedding lokal, dan menulis state ke remote LibSQL cluster.
import os
import json
import libsql_client
from web3 import Web3
BASE_RPC_URL = "https://mainnet.base.org"
AGENT_WALLET = "0x92Aff59709b03b9373b8fA887D24953D60fAd919"
CHAIN_ID = 8453
w3 = Web3(Web3.HTTPProvider(BASE_RPC_URL))
assert w3.eth.chain_id == CHAIN_ID, "Invalid Chain ID"
client = libsql_client.create_client_sync(
url=os.getenv("TURSO_DATABASE_URL"),
auth_token=os.getenv("TURSO_AUTH_TOKEN")
)
def record_execution(tx_hash: str, raw_decision: str, embedding: list[float]):
receipt = w3.eth.get_transaction_receipt(tx_hash)
status_str = "SUCCESS" if receipt.status == 1 else "REVERTED"
payload = f"tx:{tx_hash} | status:{status_str} | rationale:{raw_decision}"
vec_blob = json.dumps(embedding)
client.execute(
"""
INSERT INTO agent_memory (timestamp, tx_hash, content, embedding)
VALUES (unixepoch(), ?, ?, vector32(?))
""",
[tx_hash, payload, vec_blob]
)
def recall_relevant_context(query_vec: list[float], keyword: str, limit: int = 5):
query = """
SELECT m.tx_hash, m.content, vector_distance_cos(m.embedding, vector32(?)) as dist
FROM agent_memory m
JOIN memory_fts f ON m.id = f.rowid
WHERE memory_fts MATCH ?
ORDER BY dist ASC
LIMIT ?;
"""
res = client.execute(query, [json.dumps(query_vec), keyword, limit])
return res.rows
Kami menguji arsitektur ini pada VPS tunggal (2 vCPU, 4GB RAM) di region AWS Frankfurt yang berkomunikasi dengan Base sequencer dan Turso primary replica:
Bandingkan angka tersebut dengan klaster vector database komersial terpisah, di mana latensi jaringan ganda rata-rata memakan waktu 85ms hingga 140ms hanya untuk layer data. Ketika sequencer Base mengonfirmasi transaksi dalam hitungan detik, membuang ratusan milidetik pada layer database adalah bentuk kegagalan teknis.
Sederhanakan sistem Anda. Agen on-chain tidak
0x92Aff59709b03b9373b8fA887D24953D60fAd919