حافظه عامل به لحظه OpenTelemetry خود نیاز دارد

هر مکانی را فهرست کنید که ابزار کدنویسی شما چیزی را که "به خاطر می آورد" نگه می دارد. یک تنظیم معمولی امروز:

این چهار شکل مختلف است، و هیچ یک از آنها نمی توانند بقیه را بخوانند. درسی که نماینده CI شما می آموزد در هر آنچه که نوشته است باقی می ماند. عامل ویرایشگر شما نمی تواند آن را بخواند، و همچنین ابزار بعدی که امتحان می کنید نمی تواند آن را بخواند.

هر قالب به تنهایی معقول است. آنها با هم همان ایده کوچک را بارها و بارها از نو می سازند: یادداشتی که یک نماینده برای خود آینده اش گذاشته، در آدرسی ذخیره می شود و برای مدتی درست است.

و لیست همچنان در حال رشد است. r/ClaudeAI، r/LocalLLaMA یا r/cursor را مرور کنید و یک جریان ثابت از پست‌های "I ایجاد یک لایه حافظه برای عامل خود" پیدا خواهید کرد، که هر کدام دارای فضای ذخیره‌سازی، طرحواره و ابزار MCP خاص خود هستند. این شواهد خوبی است که مشکل واقعی است: مردم به اندازه کافی به آن ضربه می زنند تا چیزی بسازند. اما هر راه حل جدید یک قالب دیگر اضافه می کند که هیچ چیز دیگری نمی تواند آن را بخواند. مشکل یک ابزار گم شده نیست. این یک توافق گمشده است، و این فقط از جامعه ای است که روی آن با هم کار می کنند.

من یکی از این ابزارها یعنی LoreKit را می سازم که متن باز است. این مشکلی نیست که LoreKit حافظه را حل کرده باشد. قالب آن یک پیشنهاد در میان چندین پیشنهاد است، با شکاف های خودش. نکته این است که این لحظه برای توافق بر روی یک شکل مشترک است، و اینکه یک قسمت دیگر قبلا نشان داده است که چگونه است.

قبل از سال 2019، هر فروشنده قابلیت مشاهده، نماینده خود، کتابخانه ابزار دقیق و قالب داده خود را ارسال می کرد. تعویض فروشنده به معنای ابزارسازی مجدد کد شما بود. دو پروژه باز، OpenTracing و OpenCensus، سعی کردند این مشکل را برطرف کنند و با یکدیگر رقابت کردند.

در سال 2019 آنها در OpenTelemetry ادغام شدند. آنچه اهمیت داشت این بود که فروشندگان بر سر چه چیزی توافق کردند که رقابت را متوقف کنند:

فروشندگان در مورد آنچه که با داده ها انجام می دهند رقابت می کنند: ذخیره سازی، پرس و جو، تجزیه و تحلیل. ابزار کاربران یک بار. من هر روز با OpenTelemetry در Dash0 کار می کنم، و این توافق به این دلیل است که اکوسیستم کامل ابزارها می توانند داده های یکدیگر را بخوانند.

حافظه عامل جایی است که قابلیت مشاهده قبل از سال 2019 وجود داشت. زمان بندی خوب است: قالب ها به اندازه کافی جوان هستند که می توانند تغییر کنند، و در حال حاضر یک خانه خنثی برای استانداردهای نماینده وجود دارد. MCP و AGENTS.md هر دو تحت بنیاد هوش مصنوعی عامل بنیاد لینوکس قرار دارند.

اینها به سرعت تغییر می کنند، بنابراین جزئیات را به عنوان یک عکس فوری از اواخر سال 2026 در نظر بگیرید.

تعدادی از آنها چیزی را درست دریافت کردند که یک مشخصات مشترک باید حفظ کند. Copilot Memory نقل‌قول‌ها را جفت می‌کند که می‌توانید کد را با فراموش کردن به طور پیش‌فرض بررسی کنید، اگرچه در یک محصول قفل شده است. LangGraph نشان می دهد که هسته چقدر می تواند کوچک باشد: put (نام، کلید، مقدار). Graphiti زمان را به‌درستی مدل‌سازی می‌کند، با جدول‌های زمانی جداگانه برای اینکه چه زمانی یک واقعیت درست است و چه زمانی ثبت شده است. و AGENTS.md نشان می دهد که یک فایل ساده در یک مسیر شناخته شده می تواند به یک استاندارد تبدیل شود.

چند نفر در این مورد شروع کرده اند. حافظه قابل حمل MacPaw Research یک بسته .mem با سریال سازی قابل تکرار بایت، حذف سنگ قبر و امضای اختیاری است. نویسندگان آن می گویند که هنوز به طور گسترده مورد پذیرش قرار نگرفته است. پروتکل حافظه باز پیش نویس آوریل 2026 برای جابجایی مکالمات و خاطرات به دست آمده از آنها بین پلتفرم ها به صورت ZIP با مانیفست است. فرمت COGX Cognee از Mem0، Letta و Zep وارد می شود.

اینها عمدتا صادرات را حل می کنند: انتقال حافظه یک نفر از فروشنده A به فروشنده B. ابزارهای کدگذاری یک مشکل دوم و باز نیز دارند: آدرس دهی زنده. وقتی یک کار CI، یک عامل ویرایشگر و یک ربات بررسی در یک مخزن کار می کنند، چگونه یک مکان را می خوانند و می نویسند و در مورد معنای آن توافق می کنند؟ یک مشخصات کامل به هر دو نیاز دارد.

نام تجاری را حذف کنید و هر قالبی به چهار سوال مشابه پاسخ می دهد: کجا یک حافظه درست است، هویت آن چیست (آیا نوشتن دوم آن را به روز می کند یا تکرار می کند؟)، چه می گوید، و چه زمانی درست نیست. هیچ کس با این موضوع مخالف نیست. ابزارها فقط در مورد پاسخ ها اختلاف نظر دارند، جایی که OpenTelemetry نیز شروع شد.

یک چنگال واقعی وجود دارد: چه کسی خاطره را می نویسد. در فایل های دستورالعمل یک شخص است. در ابزار حافظه، Letta و LoreKit، این مدل است. در Mem0 و Graphiti، یک سرویس حقایق را از مکالمه استخراج می کند. یک مشخصات نیازی به انتخاب یکی ندارد. باید کدام را ضبط کند، بنابراین خواننده می داند که چقدر به آنچه می خواند اعتماد کند.

در اینجا تقریبا یک رکورد می تواند به عنوان یک فایل باشد. این مدل داده را نشان می دهد. نام فیلدها پیشنهادی نیستند:

قسمت جلویی پاکت است: آدرس و کلید می‌گویند کجا درست است، شناسه هویت آن است، چرخه حیات می‌گوید چه زمانی متوقف می‌شود، و write_by به فورک پاسخ می‌دهد. Markdown زیر آن خود حافظه است و content_type به خواننده می گوید که چگونه با آن رفتار کند. هر چیز دیگری که یک ابزار به آن نیاز دارد در ویژگی ها قرار می گیرد، در زیر یک فضای نام، ابزارهای دیگر می توانند نادیده بگیرند. همین رکورد برای ابزاری که می‌خواهد آن را از طریق سیم بفرستد، به همین خوبی به JSON تبدیل می‌شود.

در اطراف آن رکورد، یک مشخصات لایه های OpenTelemetry را منعکس می کند:

آنچه که بیرون می ماند بسیار مهم است: ذخیره سازی، رتبه بندی، جاسازی ها، رابط کاربری. اینجاست که ابزارها باید با هم رقابت کنند. و مشخصات باید در جایی خنثی باشد، نه در مخزن LoreKit یا هر فروشنده‌ای.

"شما یک ابزار حافظه می سازید، پس مطمئنا می خواهید که شکل استانداردی مانند آن داشته باشید." منصفانه به همین دلیل است که LoreKit به جای الگو، یک ردیف در جدول است. اگر مشخصات مشترک متفاوت به نظر می رسد، LoreKit باید به هر حال آن را اتخاذ کند.

"MCP در حال حاضر استاندارد است." MCP تماس را استاندارد می کند نه رکورد را. OpenTelemetry به یک پروتکل و یک مدل داده نیاز داشت. حافظه نیز به هر دو نیاز دارد.

"حافظه مشترک یک کانال تزریق سریع است." بله. هر چیزی که یک نماینده بخواند می تواند آن را هدایت کند و حافظه مشترک کسانی که می توانند آن را بنویسند افزایش می یابد. یک مشخصات باید آن را قابل مشاهده کند: ضبط کردن چه کسی هر حافظه را نوشته است، امضاها را مجاز می کند (حافظه قابل حمل از قبل این کار را انجام می دهد)، و اجازه دهید یک رکورد به کدی که به آن بستگی دارد اشاره کند تا خواننده بتواند بررسی کند که آیا آن کد تغییر کرده است یا خیر. هیچ قالبی مسمومیت را غیرممکن نمی کند.

"یک استاندارد دیگر تکه تکه شدن را برطرف نمی کند." این xkcd 927 است و قوی ترین اعتراض است. پاسخ من OpenTelemetry است: توافق زمانی حاصل شد که پروژه های موجود ادغام شدند، نه زمانی که شخصی پروژه دیگری را اضافه کرد. کار در اینجا یکسان است: پیشنهادها و ابزارهای موجود را هر کدام به درستی انجام داده اند و در مورد قسمت هایی که به اشتراک می گذارند توافق کنید.

من جواب اینها را نمی دانم و ترجیح می دهم آنها را در انظار عمومی حل کنم:

اگر هر یک از ابزارهای جدول را می سازید، یا یکی از پیشنهادات را نوشته اید، می خواهم یادداشت ها را با هم مقایسه کنم. طرح و فرمت روی دیسک LoreKit دارای مجوز MIT به عنوان یک ورودی مشخص است. برای مشاهده رکوردهای واقعی، فروشگاه آفلاین LoreKit فایل‌های Markdown ساده را می‌نویسد که می‌توانید آن‌ها را باز کنید، grep و متفاوت کنید:

آنها را با آنچه ابزارهای دیگرتان می نویسند مقایسه کنید و به من بگویید که یک قالب مشترک چه نیازی دارد که هیچ یک از آنها هنوز نیاز ندارند.