تصور کنید دو برنامهنویس هوشمند در حال ویرایش یک فایل هستند، اما بهجای جنگیدن بر سر خطوط کد در لحظه ادغام، تغییرات آنها بهطور خودکار و بدون خطا با هم ترکیب میشود. این همان اتفاقی است که در معماری جدید Agent Lab رخ میدهد تا گلوگاههای همکاری در سامانههای عاملمحور برطرف شود.
طبق اعلام Agent Lab، این متدولوژی جدید اجازه میدهد چندین عامل (Agent) کدنویس بدون اتکا به ادغامهای (Merge) سنتی شاخههای گیت با یکدیگر هماهنگ شوند. این سیستم یک نقطه شکست حیاتی در گردشکارهای عاملمحور را حل میکند: تمایل شاخهها به ترکیب کارهای خصوصی، وضعیتهای هماهنگی مشترک و وضعیت پذیرفتهشده پروژه. نتیجه این است که تغییرات دو عامل مستقل، بدون نیاز به ادغام شاخههای آنها در شاخه کاری، حفظ میشوند.
بسیاری از توسعهدهندگان به شاخههای گیت بهعنوان مجموعهای از عکسبرداریهای سیستم فایل نگاه میکنند، اما برای عاملهای خودکار، این رویکرد منجر به برخورد معنایی میشود. اگر دو عامل یک فایل JSON وظایف را ویرایش کنند، گیت فقط خطوط متن را میبیند، در حالی که یک هماهنگکننده باید قصد، نویسنده و ترتیب منطقی را تشخیص دهد. با انتقال لایه هماهنگی از عکسبرداریها به مجموعهای از عملیاتها، چارچوب Agent Lab تضمین میکند که تغییرات همزمان بهطور قطعی همگرا شوند.
همانطور که در تحلیلهای پیشین ما دربارهی امنیت مدلهای بازمتن اشاره کردیم، مدیریت وضعیت در محیطهای توزیعشده همواره چالشبرانگیز بوده است. این متدولوژی در کنار مدیریت وضعیت، با پیادهسازی مرزهای دقیق ارکستراتور میتواند از تورم پنجره متنی و سردرگمی عاملها در محیطهای پیچیده جلوگیری کند. در این معماری، چرخه حیات عامل به سه لایه مجزا تقسیم میشود:
- وضعیت اجرای خصوصی: شامل دایرکتوری محلی عامل، فایلهای موقت، پرامپتها و آزمایشهای ثبتنشده است.
- وضعیت هماهنگی منتشرشده: عملیاتهای تغییرناپذیری که در یک فضای نام سفارشی گیت (
refs/agents/) ذخیره میشوند. در این لایه، هر عملیات یک شیء ثبتشده (Committed Object) است. - وضعیت پذیرفتهشده پروژه: یک وضعیت نهایی متجسم شده در شاخه
mainکه توسط یک کاهشدهنده (Reducer) قطعی تولید میشود و نه از طریق یک کامیت ادغام (Merge Commit).
در این مدل، گیت بهعنوان لایه انتقال و نگهداری عمل میکند، در حالی که یک نوع داده تکرارپذیر بدون تداخل (CRDT) — شبیه به یک دفترچه یادداشت مشترک که هر کس هر کجا بنویسد، در نهایت همه نسخهها دقیقاً یکسان میشوند — نحوه همگرایی قصدها را تعریف میکند. عاملها کارهای یکدیگر را Checkout نمیکنند؛ آنها صرفاً رفرنسهای خصوصی خود را با دستور git update-ref پیش میبرند. بهطور مشخص، آزمایشگاه فضاهای نامی مانند refs/agents/alpha/task-42 و refs/agents/beta/task-42 را رزرو میکند. اینها رفرنسهای معمولی گیت هستند، اما در خروجیهای استاندارد git branch ظاهر نمیشوند. هماهنگکننده درختهای کامیت آنها را با دستور git show میخواند و هرگز آنها را روی شاخه کاری Checkout نمیکند.
قلب این سیستم یک کاهشدهنده (Reducer) مبتنی بر پایتون است که در فایل tools/reduce.py (با استفاده از پایتون ۳.۹ به بالا و تنها با کتابخانههای استاندارد) پیادهسازی شده و جبر CRDT را اجرا میکند. این کاهشدهنده پیش از انتشار عملیاتهای عاملها در مخزن ثبت میشود تا تمام عاملها ریوایژن والد یکسانی از کاهشدهنده را به اشتراک داشته باشند. این ابزار مجموعهای از عملیاتهای «فقط-افزودنی» (Add-only) را پردازش میکند که در آن هر عملیات یک فایل JSON در مسیر ops/<actor>/<op-id>.json با یک شناسه یکتای جهانی (op_id) است.
استفاده از یک عملیات در هر فایل باعث میشود که از فساد دادهها در اثر الحاقهای همزمان (Concurrent Append) جلوگیری شود و شناسههای تکراری قابل مشاهده باشند. عاملها هرگز نباید عملیاتی را پس از انتشار ویرایش کنند؛ هرگونه اصلاحیه باید بهعنوان یک عملیات جدید صادر شود.
برای تضمین نتیجه یکسان، صرفنظر از ترتیبی که رفرنسهای عاملها پردازش میشوند، کاهشدهنده قوانین سختگیرانهای را دنبال میکند:
- حذف تکرار (Deduplication): از
op_idاستفاده میکند تا تضمین کند عملیاتهای بازپخششده (Replayed) دو بار اعمال نشوند. کاهشدهنده محمولههای واگرایی را که شناسه یکسانی دارند، رد میکند. - مرتبسازی قطعی (Deterministic Sorting): عملیاتها ابتدا بر اساس ساعت لامپورت (Lamport clock)، سپس بر اساس شناسه عامل (Actor ID) و در نهایت بر اساس
op_idمرتب میشوند. کلیدهای JSON و لیست الزامات نیز با ترتیبی ثابت سریالیزه میشوند تا خروجی بایتهای پایداری حاصل شود. - سیاستهای فیلد-محور:
- وضعیت (Status): توسط یک رجیستر «آخرین نویسنده برنده است» (LWW) مدیریت میشود که بر اساس یک تاپل منطقی (ساعت، عامل، op_id) مرتب شده است. این امر بازتولیدپذیری ترتیب را تضمین میکند، هرچند تضمین نمیکند که تصمیم جدیدتر حتماً درستتر باشد.
- الزامات (Requirements): بهعنوان یک مجموعه فقط-افزودنی مدیریت میشوند که توسط شناسههای پایدار الزامات کلیدگذاری شدهاند. هرگونه محموله واگرای الزامات برای یک شناسه یکسان، بهجای ادغام خاموش، باعث بروز
ValueErrorمیشود.
یک نمونه از طرحواره (Schema) عملیات به این شکل است: {"op_id": "alpha:task-42:1", "actor": "alpha", "clock": 1, "task": "task-42", "kind": "set_status", "value": "in_progress"}. کاهشدهنده این موارد را در برابر وضعیتهای مجاز (مانند open, in_progress, blocked, done) و انواع مجاز (مانند set_status, add_requirement) اعتبارسنجی میکند.
در یک مورد آزمایشی عینی، وظیفه task-42 در ابتدا به این شکل است: {"id": "task-42", "title": "Prevent duplicate payment retries", "status": "open", "requirements": []}. آزمایشگاه دو مسئولیت متفاوت را با استفاده از ورکتریهای مجزا (.agent-alpha و .agent-beta) که از یک BASE_COMMIT مشترک شروع میشوند، اختصاص میدهد:
- عامل Alpha: وظیفه را برای پیادهسازی بر میدارد و عملیات
set_status("in_progress")را منتشر میکند. - عامل Beta: یک شرط تأیید از طریق
add_requirement("retry-idempotency-test", ...)میافزاید تا بررسی کند که بازپخش یک کلید تلاش مجدد پرداخت، تنها یک بار هزینه ایجاد کند.
چون این عاملها روی اجزای منطقی متفاوتی کار میکردند، توانستند تغییرات خود را بدون لمس یک فایل مشترک در درخت کاری (Working Tree) اعمال کنند.
بر اساس مستندات این آزمایشگاه، استواری سیستم از طریق چندین دروازه تأیید شد:
- استقلال از ترتیب (Order Independence): کاهش Alpha سپس Beta، دقیقاً همان خروجی بایت-به-بایت کاهش Beta سپس Alpha را تولید کرد که توسط دستور
cmpتأیید شد. این مورد با تولید/tmp/task-ab.jsonو/tmp/task-ba.jsonو مقایسه آنها تست شد. - Idempotency (یکتوان بودن): ارسال چندینباره یک عملیات (مثلاً دادن یک رفرنس یکسان دو بار به کاهشدهنده) وضعیت نهایی را تغییر نداد.
- بازیابی جلسه (Session Recovery): حتی پس از حذف ورکتریها و پاک کردن حافظه جلسه، وضعیت نهایی بهطور کامل بازسازی شد. سیستم از
git for-each-refبرای کشف رفرنسهای بادوام و بازسازی وضعیت تنها از طریق اشیاء ثبتشده استفاده کرد. - تاریخچه بدون ادغام (Merge-Free History): کامیت نهایی متجسم شده در
mainتنها یک والد دارد. تستgit rev-list --merges "$BASE_COMMIT"..HEADتأیید کرد که هیچ کامیت ادغامی وجود ندارد. همچنین دستورgit rev-list --parents -n 1 HEAD | wc -wمقدار ۲ را برمیگرداند (خود کامیت و والد تکگانهاش). - دسترسیپذیری (Reachability): پروتکل تأیید میکند که هر دو عملیات از طریق
git cat-file -eاز رفرنسهای مربوط به عاملهایشان قابل دسترسی هستند.
برای استقرار در محیطهای عملیاتی، Agent Lab توصیه میکند از محافظ «مقایسه و جایگزینی» (Compare-and-Swap) روی رفرنسهای گیت استفاده شود. هنگام استفاده از git update-ref، عامل یک شناسه شیء قدیمی (مثلاً 0000000000000000000000000000000000000000 برای رفرنسهای جدید) ارائه میدهد. اگر اشارهگر پیش از آن پیش رفته باشد، انتشار بهجای بازنویسی خاموش، با شکست مواجه میشود.
همچنین برای جلوگیری از کارهای تکراری، پیادهسازی عملیات claim_work که با یک شناسه واحد کاری پایدار کلیدگذاری شده است، پیشنهاد شده است. برای مثال:{"op_id": "alpha:claim:payment-retry-handler:1", "actor": "alpha", "clock": 1, "task": "task-42", "kind": "claim_work", "value": {"work_unit": "payment-retry-handler"}}.
این اجازه میدهد تا هماهنگکننده ادعاهای متضاد را شناسایی و بازنده را پیش از شروع اجرای هزینهبر رد کند. ذکر شده است که یک برنده قطعی، یک زمانبندی عادلانه (Fair Scheduler) نیست و کارهای پرهزینه باید بهطور مرکزی رزرو شوند.
علاوه بر این، سیستم همگرایی را از پذیرش جدا میکند. یک خط لوله (Pipeline) مستحکم در این سیستم چهار مرحله دارد:
۱. جمعآوری (Collection): گردآوری عملیاتهای تغییرناپذیر از کامیتهای پینشده.
۲. اعتبارسنجی (Validation): بررسی هویت، مجوزها، طرحواره (Schema) و قوانین علّی.
۳. کاهش (Reduction): تبدیل به یک وضعیت کاندید قطعی.
۴. تأیید (Verification): اجرای تستهای پروژه و پذیرش کاندید از طریق یک کامیت تک-والد توسط هماهنگکننده.
برای محیطهای با امنیت بالا، راهنما مدل مجوزهای خاصی را توصیه میکند:
- عامل Alpha/Beta: میتوانند شاخه پایه/رفرنسهای مجاز را بخوانند و فقط فضای نام
refs/agents/<actor>/*خود را بهروزرسانی کنند. - هماهنگکننده: میتواند تمام رفرنسهای عاملها را بخواند و شاخه وضعیت پذیرفتهشده و رفرنسهای اسنپشات را بهروزرسانی کند.
با این حال، این رویکرد جایگزین کلی برای ادغامهای گیت نیست. وصلههای کد منبع بهطور طبیعی عملیات CRDT نیستند. ویرایشهای همزمان در درختهای نحو (Syntax Trees) همچنان میتواند منجر به کدهای غیرقابل کامپایل یا ناامن شود، زیرا تمیز بودن متنی تضمینکننده سازگاری معنایی نیست. این چارچوب برای «اشیاء هماهنگی محدود» مانند وضعیت وظایف، الزامات و تأییدیهها طراحی شده است.
علاوه بر این، دادههای فقط-افزودنی بهطور نامحدود رشد میکنند. استقرارهای عملیاتی به استراتژیهای اسنپشات و فشردهسازی (Compaction) برای هرس تاریخچه نیاز دارند. برای مثال، یک اسنپشات میتواند مرز عملیات و چکسام آن را ثبت کند تا کاهشهای جدید از اسنپشات شروع شوند نه از ابتدای زمان. این اسنپشات باید پیش از هرس تاریخچه، در برابر یک بازپخش کامل تست شود.
محدودیتهای فنی دیگری نیز وجود دارد:
- همگامسازی رفرنسها: کلونهای پیشفرض گیت رفرنسهای
refs/agents/*را منتقل نمیکنند و نیاز بهfetch refspecصریح مانند+refs/agents/*:refs/agents/*دارند. علامت پلاس در ابتدا اجازه جایگزینی غیر-Fast-forward را میدهد که برای سیستمهای سختگیرانه بیش از حد سهلانگارانه است. - ساعتبندی: ساعتهای لامپورت ترتیب را مشخص میکنند اما نمیتوانند مشاهده علّی را اثبات کنند. برای طرحهای علّی غنیتر به ساعتهای برداری (Vector Clocks) نیاز است. ناشران عملیاتی باید تضمین کنند ساعت عملیات بعدی بزرگتر از بالاترین ساعت ثبتشده برای آن عامل باشد.
- اتمیته (Atomicity): بهروزرسانی تکی رفرنسها میتواند نمایی میانی و ناقص را نمایش دهد. راهنما پیشنهاد میکند برای تغییرات تراکنشی و نمایش همزمان چندین رفرنس، از
git update-ref --stdinاستفاده شود. - جمعآوری زباله (Garbage Collection): کامیتهایی که فقط از طریق متغیرهای موقت یا reflog شناخته میشوند ممکن است جمعآوری شوند؛ بنابراین رفرنسها باید پیش از حذف ورکتریها منتشر شوند.
- تداخل معنایی: انتخاب یک مقدار از طریق ترتیب لغوی (Lexical Ordering) منجر به همگرایی میشود، اما ممکن است یک اختلاف معنایی را پنهان کند. برای الزامات، آشکار کردن تداخل ایمنتر از انتخاب خاموش است.
این تغییر در رویکرد، مرز مدل را از اقتدار مخزن (Repository Authority) دور میکند. یک کنترلکننده مورد اعتماد تراکنشهای گیت را مدیریت، شناسههای عملیات را تخصیص و اعتبارسنجی طرحواره را انجام میدهد، در حالی که مدل AI محدود به پیشنهاد عملیات ساختاریافته و فرمانهای تأیید برای تغییرات خود است.
گام بعدی شما
- اگر در حال توسعه سامانههای چندعاملی هستید، بهجای Merge، از مدل Operation-based برای مدیریت وضعیت وظایف استفاده کنید.
- برای پیادهسازی، ابتدا یک Reducer ساده در پایتون بنویسید که عملیاتهای JSON را بر اساس یک شناسه یکتا مرتب و ترکیب کند.
- رفرنسهای سفارشی گیت (
refs/) را برای جداسازی وضعیتهای موقت عاملها از شاخه اصلی پروژه به کار بگیرید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو