تصور کنید یک عامل کدنویس دوشنبه یک خطای اتصال به دیتابیس Postgres را حل می‌کند، اما سه‌شنبه دوباره ۱۰ دقیقه وقت شما را می‌گیرد تا همان خطا را از ابتدا تحلیل کند. این یعنی نشت بهره‌وری؛ جایی که مدل هر بار با یک دیوار مواجه می‌شود و هیچ یادگاری از صعود قبلی ندارد. برای مثال، عاملی را تصور کنید که با خطای ECONNREFUSED 5432 مواجه می‌شود، به اشتباه تصمیم می‌گیرد که پیکربندی Connection Pool مشکل دارد و ۹ دقیقه وقت صرف بازنویسی فایلی می‌کند که از ابتدا درست بود. این دقیقاً همان تکرار مسیر سخت بدون داشتن هیچ سندی از تلاش‌های قبلی است.
LoreKit با ایجاد سیستمی برای ثبت «درس‌ها» در یک دایرکتوری محلی که بین جلسات مختلف باقی می‌ماند، مانع از آن می‌شود که عامل شما یک اشتباه را دوبار تکرار کند. همان‌طور که در تحلیل‌های قبلی ما درباره‌ی حافظهٔ عامل‌ها اشاره کردیم، بزرگ‌ترین چالش فعلی، فقدان تداوم یادگیری در محیط‌های توسعه است. این ابزار اجازه می‌دهد عامل‌ها تجربیات خود را به صورت متنی ذخیره کنند تا در جلسات بعدی، به جای شروع از صفر، از روی یادداشت‌های قبلی پیش بروند.
بیشتر راهکارهای حافظه، شما را مجبور به استفاده از پلتفرم‌های جدید یا ثبت‌نام در سرویس‌های ابری می‌کنند. اما LoreKit یک جایگزین سبک است که مالکیت داده را اولویت می‌دهد و از فایل‌های ساده روی دیسک شما استفاده می‌کند. این یعنی یک دستور، یک پوشه و تمام؛ بدون نیاز به اکانت، شبکه یا ثبت‌نام. این رویکرد دقیقاً برای رفع آن کلافگی رایجی است که در آن عامل‌ها هر بار با شروع یک جلسه جدید دچار «فراموشی» می‌شوند و توسعه‌دهندگان مجبورند زمینه‌های محیطی (Environmental Context) را بارها تکرار کنند.
سازوکار اولویت‌محور محلی
به نقل از پست وبلاگ lorekit.io در ۱۶ اوت ۲۰۲۶، این سیستم با یک دستور ساده یعنی npx @lorekit/cli install فعال می‌شود. این فرآیند سه مهارت اصلی شامل lorekit-memory ،lorekit-setup و lorekit-groom را ایجاد کرده و آن‌ها را از طریق دایرکتوری‌های .claude/ (برای سطح پروژه) یا ~/.claude/ (برای سطح سراسری) به قلاب‌های چرخه حیات (lifecycle hooks) عامل متصل می‌کند.
در هنگام نصب، ابزار CLI سه سؤال کلیدی از کاربر می‌پرسد: اول اینکه آیا استقرار باید در سطح پروژه باشد یا سراسری؛ دوم درخواست یک توکن (که برای استفاده محلی می‌تواند خالی بماند)؛ و سوم اینکه کدام قلاب‌ها (hooks) سیم‌کشی شوند (همه، فقط خواندنی، یا هیچ‌کدام).
تنظیمات تنها به دو فایل کوچک نیاز دارد:
- فایل
.lorekit.jsonدر ریشه مخزن که امن است و می‌توان آن را در گیت کامیت کرد چون حاوی هیچ رمز عبوری نیست. این فایل ذخیره‌ساز را به دیسک محلی متصل می‌کند:{ "mode": "local" }. - یک ورودی در
.mcp.jsonکه پروتکل زمینهٔ مدل (MCP) — شبیه به یک مترجم استاندارد که اجازه می‌دهد مدل‌های مختلف با ابزارهای مختلف حرف بزنند — را به سرور stdio محلی متصل می‌کند، به جای اینکه به یک نقطه انتهایی میزبانی‌شده اشاره کند. نصب‌کننده این ورودی را ادغام می‌کند بدون اینکه به سایر سرورها دست بزند. پیکربندی دقیق آن به این صورت است:"lorekit": { "command": "npx", "args": ["-y", "@lorekit/cli", "mcp"] }.
کاربران می‌توانند با اجرای دستور npx @lorekit/cli doctor از صحت پیکربندی خود مطمئن شوند. این دستور حالت شناسایی شده (resolved mode) و فایل دقیقی که باعث تعیین این حالت شده است را گزارش می‌دهد.
چرخه یادگیری حافظه چگونه کار می‌کند؟
LoreKit داده‌ها را پنهانی یا پشت سر کاربر ضبط نمی‌کند، بلکه از یک سیستم «تلنگر» (nudge) استفاده می‌کند. وقتی استفاده از یک ابزار شکست می‌خورد — مثلاً یک فراخوانی Bash با خطا مواجه می‌شود — قلاب PostToolUseFailure فعال می‌شود. برای مثال، اگر دستور pnpm test به دلیل خاموش بودن دیتابیس شکست بخورد، قلاب خروجی می‌دهد: «LoreKit: آخرین فراخوانی Bash شکست خورد. اگر این مورد تکراری یا غیربدیهی است، از memory.write در مسیر repo::acme/checkout برای ثبت راه حل استفاده کنید تا اجرای بعدی از آن اجتناب کند.»
این یک تلنگر است، نه یک نوشتن خودکار. ثبت واقعی تنها زمانی رخ می‌دهد که مدل صراحتاً دستور memory.write را فراخوانی کند. در این لحظه، LoreKit یک فایل مارک‌داون در مسیر ~/.lorekit/ می‌سازد. این فایل‌ها شامل متادیتای Frontmatter زیر هستند:
- scope: محدوده (مثلاً
repo::acme/checkout) - key: کلید شناسایی (مثلاً
tests-need-local-postgres) - created/updated: برچسب‌های زمانی ISO (مثلاً
2026-08-15T17:00:18.477Z) - seen_count: یک عدد صحیح که ردیابی می‌کند این درس چند بار به کار رفته است.
- فیلدهای اضافی: تگ‌ها و منشأ (provenance).
به عنوان مثال، شکست در استارت دیتابیس منجر به یادداشتی می‌شود که به عامل یادآوری کند دستور docker compose up -d db را اجرا کند تا از خطای ECONNREFUSED 5432 جلوگیری شود؛ خطایی که اغلب شبیه به یک باگ کد به نظر می‌رسد اما در واقع یک مشکل محیطی است. چون این‌ها فایل‌های متنی ساده هستند، کاربر می‌تواند آن‌ها را با cat بخواند، با grep جست‌وجو کند، در گیت کامیت کند یا با rm حذف نماید.
در جلسات بعدی، چرخه کامل می‌شود. LoreKit حافظه‌ها را بارگذاری کرده و به عامل اطلاع می‌دهد: «LoreKit: یک حافظه بارگذاری شد · repo::acme/checkout — این‌ها ملاحظات هستند، نه قوانین؛ برای خواندن کامل هر کدام از memory.read استفاده کنید.» اگر همان شکست در میانه کار دوباره رخ دهد، قلاب شکست این بار به‌جای تلنگر ساده، خودِ درس را ارائه می‌دهد و اشاره می‌کند که عامل قبلاً با چیزی شبیه به این مواجه شده است.
مدیریت سلسله‌مراتبی و چرخه عمر
برای اینکه اطلاعات درست در زمان درست ظاهر شوند، LoreKit از یک سیستم محدوده (Scope) سلسله‌مراتبی استفاده می‌کند. سیستم محدوده‌ها را به ترتیب خاص‌ترین به عام‌ترین می‌خواند:
- محدوده شاخه (Branch scope): با فرمت
branch::{owner}/{repo}::{branch}. این برای آزمایش‌های سریع (spikes) ایده‌آل است. یافته‌ها (مثلاً یک استراتژی ابطال کش برای یک ویژگی خاص) اینجا نوشته می‌شوند تا فقط در همان شاخه ظاهر شوند. اگر شاخه حذف شود، درس هم با آن می‌میرد. در صورت ادغام (merge)، کاربر می‌تواند کلید را در سطح مخزن بازنویسی کرده و نسخه شاخه را حذف کند. - محدوده مخزن (Repo scope): با فرمت
repo::{owner}/{repo}. - محدوده پروژه (Project scope): با فرمت
project::{name}. - محدوده سراسری (Global scope): درس‌های کلی که در تمام پروژه‌ها کاربرد دارند.
برای جلوگیری از تبدیل حافظه به قبرستانی از حقایق منقضی‌شده، پارامتر ttl_days (زمان ماندگاری) تعریف شده است. یک توسعه‌دهنده می‌تواند یادداشتی بنویسد که یک تست ناپایدار (flaky) است و تا جمعه اصلاح می‌شود و TTL آن را ۵ روز قرار دهد: memory.write { scope: "repo::acme/checkout", key: "skip-flaky-checkout-test", value: "...", ttl_days: 5 }. این ورودی سپس به‌طور خودکار نامرئی می‌شود بدون اینکه نیاز به پاکسازی دستی باشد.
مقیاس‌پذیری از محلی به تیمی
اگرچه لایه پایه محلی است، اما LoreKit اجازه انتقال بدون درز به یک ذخیره‌ساز Postgres میزبانی‌شده را می‌دهد. این یک فرآیند افزایشی است، نه یک مهاجرت اجباری. با ایجاد حساب رایگان در lorekit.io، تولید یک کلید خواندن-نوشتن (lk_rw_...) و اجرای دستور npx @lorekit/cli install --force ،ورودی .mcp.json به نقطه انتهایی ابری تغییر می‌کند.
کاربران می‌توانند فایل‌های مارک‌داون محلی خود را با دستور npx @lorekit/cli migrate --from ~/.lorekit --to remote به ابر منتقل کنند. این دستور Idempotent است (تکرار آن تغییری ایجاد نمی‌کند) و unless پرچم --yes اضافه شود، ابتدا یک Dry run (اجرای آزمایشی) انجام می‌دهد. این دستور تاریخ ایجاد را برای رتبه‌بندی تازگی حفظ می‌کند اما تاریخ آخرین به‌روزرسانی و تعداد دفعات مشاهده را در سمت سرور بازنویسی می‌کند. هر موردی که قبلاً آرشیو یا منقضی شده باشد، نادیده گرفته می‌شود.
پس از انتقال به حالت Remote، دستور npx @lorekit/cli list هر دو ذخیره‌ساز را کنار هم نمایش می‌دهد: بخش «Offline» از فایل‌های محلی و بخش «Remote» از ذخیره‌ساز ابری.
برای تیم‌ها، قابلیت «سازمان‌ها» (Organizations) معرفی شده است. یک مالک می‌تواند هم‌تیمی‌ها را از طریق هندل گیت‌هاب یا ایمیل با نقش‌های viewer، member، admin یا owner دعوت کند. مدیران (Admins) می‌توانند یک محدوده (مثلاً repo::myteam/api) را تحت «محدوده‌های مشترک» (Shared scopes) تعریف کنند. هر نوشته‌ای توسط یک عضو در این محدوده، به سازمان routed می‌شود؛ به این معنی که یک چک‌لیست استقرار که توسط یک نفر نوشته شده، توسط عامل تمام هم‌تیمی‌ها خوانده می‌شود. اگر کسی که عضو نیست در یک محدوده مشترک بنویسد، نوشته به‌طور خودکار به حافظه شخصی او منتقل می‌شود، مگر اینکه صراحتاً در فراخوانی memory.write عبارت org: "my-team" را پاس دهد.
برای خط لوله‌های CI/CD، یک توکن فقط-خواندنی (lk_ro_) را می‌توان به Secrets گیت‌هاب اکشنز اضافه کرد. این تضمین می‌کند که مرحله AI در پایپ‌لاین، همان زمینه محیطی را داشته باشد که توسعه‌دهنده روی ماشین محلی خود داشت. پیشوندهای توکن‌ها به وضوح سطح دسترسی را نشان می‌دهند: lk_rw_ (خواندن/نوشتن)، lk_ro_ (فقط خواندن) و lk_wo_ (فقط نوشتن).
تحلیل: تفاوت درس‌ها و قوانین
LoreKit یک تفکیک معماری حیاتی بین «درس‌ها» (Lessons) و «قوانین» (Rules) قائل می‌شود. قوانین متعلق به فایل CLAUDE.md هستند؛ آن‌ها تعمدی، بازبینی‌شده و تحت کنترل نسخه (version-controlled) هستند. اما درس‌ها، مشاهدات مشورتی هستند. بلوک تزریق شده در متن صراحتاً از عبارت «ملاحظات، نه قوانین» استفاده می‌کند.
این تفکیک مانع از آن می‌شود که عامل بیش از حد خشک و صلب شود. یک درس، یادداشتی است که عامل برای «خودِ آینده‌اش» گذاشته و اگر مشخص شود که اشتباه است، می‌تواند نادیده گرفته شود. این یک سیستم دانش لایه‌بندی شده ایجاد می‌کند: مستندات رسمی پروژه (قوانین) و تپه‌ای از تجربیات «اوه، باز هم این اتفاق افتاد» (Lore). برخی درس‌ها ممکن است در نهایت از طریق ویرایش انسانی به قانون تبدیل شوند، اما اکثر آن‌ها هرگز تبدیل نمی‌شوند، که این موضوع پذیرفتنی است تا زمانی که دوباره یاد گرفته نشوند.
محدودیت‌های فنی و عملکرد
LoreKit یک موتور جست‌وجوی معنایی نیست؛ هیچ Fine-tuning یا یادگیری مبتنی بر Embedding در آن وجود ندارد. این ابزار بر تطبیق لغوی (Lexical matching) — یعنی هم‌پوشانی کلمات، تازگی و تکرار — متکی است. بنابراین، یک بازنویسی (paraphrase) واقعی ممکن است نتواند حافظه مربوطه را پیدا کند. این سرویس برای حداکثر ۵,۰۰۰ حافظه ذخیره شده با نرخ ۱۲۰ درخواست در دقیقه رایگان است.
برای رفع نگرانی از اینکه ذخیره‌سازی ۶۰,۰۰۰ درس باعث اشباع پنجره زمینه (Context Window) شود، LoreKit از یک برش ثابت از پنجره زمینه برای درس‌هایی با بیشترین سیگنال و حذف تکرارها استفاده می‌کند. سیستم تمام درس‌ها را تزریق نمی‌کند؛ در عوض، دقیقاً به کاربر می‌گوید چه مواردی را حذف کرده است. این تضمین می‌کند که کد به یک شکل کار می‌کند، چه ذخیره‌ساز شامل ۶ درس باشد و چه ۶۰,۰۰۰ درس.
برای اینکه کاربران ببینند در صورت تکرار یک کلید، کدام محدوده (Scope) برنده شده و اولویت دارد، می‌توانند قبل از شروع تسک دستور npx @lorekit/cli tree را اجرا کنند.
گام بعدی شما
- اگر از Claude Code یا عامل‌های مشابه استفاده می‌کنید، LoreKit را با دستور
npx @lorekit/cli installتست کنید تا تکرار خطاهای محیطی را متوقف کنید. - فایل‌های
.lorekitرا در Git خود قرار دهید تا «تجربیات فنی» پروژه بین تمام توسعه‌دهندگان به اشتراک گذاشته شود. - برای پروژه‌های موقت، حتماً از
ttl_daysاستفاده کنید تا حافظه عامل با اطلاعات منقضی‌شده اشباع نشود.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو