تصور کنید هر بار که یک مهارت جدید به عامل هوش مصنوعی خود میآموزید، مجبور باشید آن را دستی در تمام پروژههایتان کپی کنید. این وضعیت نه تنها خستهکننده است، بلکه باعث میشود هر پروژه به مرور از بقیه فاصله بگیرد و مدیریت آنها غیرممکن شود.
طبق گزارشی که در ۲۸ اوت ۲۰۲۶ در وبسایت dev.to منتشر شد، بسیاری از توسعهدهندگان برای حل این مشکل به سراغ معماریهای شبیه به پروتکل زمینهٔ مدل (MCP) — شبیه به ساختن یک سرور مرکزی که تمام دستورالعملها را به جای هر پروژه پخش میکند — میروند. اما این گزارش هشدار میدهد که تبدیل «متدولوژی عملیاتی» به یک سرویس راه دور، یک خطای بنیادین در معماری است که تنها باعث ایجاد سربار در استقرار و پیچیدگی در زمان اجرا میشود.
همانطور که در تحلیلهای قبلی ما دربارهی مدیریت حافظه در مدلهای زبانی اشاره کردیم، تفکیک بین «دانش» و «روش اجرا» کلید مقیاسپذیری است. مشکل اصلی که توسعهدهندگان با آن دستوپنجه نرم میکنند، «پراکندگی مخزن» (Repo Drift) است؛ وضعیتی که در آن بهبودهای یک گردشکار در یک پروژه، به صورت دستی به پروژهای دیگر منتقل میشود و ناخواسته پیشفرضهای خاص آن محصول را هم با خود میبرد.
نویسنده این گزارش در حالی که سه پروژه مختلف (یک سایت پورتفولیو، یک تولیدکننده رزومه و Codenames AI) را مدیریت میکرد، متوجه شد که متدولوژیهای مشترک برای برنامهریزی، کارهای تحریری، ارتقای وابستگیها، بازبینی و بوتاسترپ مخزن، در مخازن مختلف تکامل یافتهاند. چون برخی از این متدها درون مخازن محصول زندگی میکردند و در آنجا رشد کرده بودند، دیگر هیچ نسخه مرجعی برای کپی کردن وجود نداشت.
او ابتدا سعی کرد با استفاده از MCP، این رفتارها را در یک مخزن مجزا استخراج کرده و از طریق یک مرز ابزاری راه دور ارائه دهد. هدف این بود که یک سرویس واحد، یک قرارداد واحد و یک مکان واحد برای نسخهبندی سیاستها ایجاد شود تا قوانینی برای برنامهریزی ایمن در هنگام ادغام (Merge-safe planning) یا راهنماییهای تحریری داشته باشد.
اما این رویکرد، بارهایی را به دوش عامل میاندازد که فقط مخصوص ابزارهای واقعی است؛ مواردی مثل مدیریت سرویس در زمان اجرا، قراردادهای MCP، داستانهای پیچیده استقرار و تصمیمات دشوار مسیریابی درباره اینکه در هر لحظه از جلسه عامل، چه زمانی باید سرویس فراخوانی شود. طبق تحلیل dev.to، این سربار برای ابزارهای خارجی مثل استخراج داده از Notion یا دریافت معیارهای PostHog منطقی است، اما برای متدولوژیهای عملیاتی — مانند اینکه چگونه برنامهها را تکهتکه کنیم یا چه زمانی بعد از باز کردن یک PR متوقف شویم — کاملاً زائد است.
راهکار پیشنهادی، جایگزینی سرویس متمرکز با یک چارچوب چهارمحدودهای است که از طریق Cursor (با استفاده از قوانین سطح کاربر، پیکربندی MCP، مهارتهای قابل نصب و فایلهای مخزن) پیادهسازی میشود:
- سیاستهای همیشگی (Always-on Policy): اینها ناورداهای جهانی در هر مخزن هستند. قوانین کوتاهی که مواردی مثل محدوده اختیارات اجرا، توپولوژی مخزن، محرکهای «توقف بعد از باز کردن» و ترجیحات ابزاری را پوشش میدهند. این بخش به جای کپی کردن متدولوژی، تنها یک اشارهگر (Pointer) به متدولوژی برنامهریزی دارد.
- ابزارهای مشترک (Shared Tools): مرزهای واقعی ابزارهای خارجی که نیاز به احراز هویت به سرویس دارند، مانند Vercel، Notion یا PostHog.
- رویههای بازاستفاده (Reusable Procedures): نصبهای گردشکار و مهارتهای کامل و قابل انتقال، مانند برنامهریزی مرحلهبندی شده و بوتاسترپ مخازن جدید. اینها در سطح کاربر باقی میمانند و مخزن جدید این مهارتها را ذخیره نمیکند.
- فایلهای مخزن (Repo Files): مکانیسمهای پایدار و دانش خاص محصول. این شامل هوکهای محلی، چرخه حیات محیطهای راه دور، CI و فایلهای خاص محصول مانند AGENTS.md، قوانین دامنه، مهارتهای محصول و راهنمای بازبینی است. برای مدیریت بهینه این فایلها، استفاده از الگوهای ساختاریافته در فایلهای پیکربندی میتواند از تخریب کدهای مشترک توسط عاملها جلوگیری کند.
نویسنده این چارچوب را در یک مصاحبه کاری تحت فشار زمانی برای ساخت محصولی AI-native آزمایش کرد. این تست «راهاندازی سرد» (Cold Start) — یعنی شروع کار با یک محیط کاملاً خالی — ثابت کرد که متدولوژی به مخازن قبلی وابسته نیست، اما یک نقص را آشکار کرد: هنوز بخشهای زیادی از تنظیمات عمومی باید در هر مخزن خالی بازسازی میشدند.
در شرایط فشار زمانی، عامل نتوانست به طور قابلاعتمادی هوکهای محیط راه دور را تنظیم کند و دستورالعملها را به جای فایل AGENTS.md در README قرار داد. هر آنچه در مخازن قدیمی بدیهی بود، برای عاملی که باید همه چیز را از صفر اختراع میکرد، مبهم بود.
برای حل این مشکل، نویسنده زیرساختهای پایه را به «بوتاسترپ قطعی» (Deterministic Bootstrap) تبدیل کرد؛ یعنی استفاده از اسکریپتها و قالبهای تاییدشده برای هوکهای محلی، چرخه حیات محیطهای راه دور و CI. هدف این نیست که راهاندازی به صفر برسد، بلکه هدف این است که توان استدلال عامل صرف تصمیماتی نشود که قبلاً گرفته شدهاند.
با اجرای یکباره بوتاسترپ برای نوشتن مکانیسمهای پایدار در فایلهای مخزن، توسعهدهنده از کپی کردن خودِ مهارت یا نوشتن دانش محصول که در هر پروژه متفاوت است، اجتناب میکند.
این چرخش، این فرض را تغییر میدهد که تمام قابلیتهای مشترک عامل باید به عنوان «ابزار» تعریف شوند. در واقع، متدولوژی یک «سیاست» است، نه یک «منبع». با جداسازی مالکیت و چرخه حیات، توسعهدهندگان میتوانند به جای صرف توان مدل برای زیرساخت، آن را روی ویژگیهای محصول متمرکز کنند.
توسعهدهندگان باید تنظیمات فعلی عاملهای خود را بررسی کنند تا ببینید چه مقدار از «متدولوژی» در فایلهای خاص هر پروژه گیر کرده است. انتقال این موارد به قوانین سطح کاربر یا اسکریپتهای قطعی میتواند زمان راهاندازی سرد پروژههای جدید را به طور قابل توجهی کاهش دهد.
گام بعدی شما
- تنظیمات فعلی عاملهای خود را بررسی کنید تا ببینید چه مقدار از «متدولوژی» در فایلهای خاص هر پروژه گیر کرده است.
- متدولوژیهای تکراری را از حالت ابزار (Tool) خارج کرده و به قوانین سطح کاربر (User-level rules) منتقل کنید.
- برای زیرساختهای تکراری، اسکریپتهای بوتاسترپ قطعی بنویسید تا زمان راهاندازی سرد پروژههای جدید کاهش یابد.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو