تفاوت میان یک عامل کدنویسی که کورکورانه فایلها را پاک میکند و عاملی که پروتکلهای مهندسی سختگیرانه را رعایت میکند، گاهی تنها در یک فایل Markdown خلاصه میشود. طبق گزارشی که در ۳ اوت ۲۰۲۶ در وبسایت dev.to منتشر شد، استاندارد AGENTS.md — که اکنون بخشی از اکوسیستم بنیاد هوش مصنوعی عاملمحور (Agentic AI Foundation یا AAIF) تحت حمایت بنیاد لینوکس است — یک لایهی مسیریابی پیشبینیپذیر برای عاملهای خودمختاری فراهم میکند که وارد یک مخزن کد جدید میشوند. این استاندارد در واقع گامی در مسیر تغییر نقش دستیاران کدنویسی از اطاعت مطلق به نظارت فنی است تا از خطاهای بحرانی جلوگیری شود.
بسیاری از توسعهدهندگان در حال حاضر قراردادهای پروژه را در فایلهای README، تنظیمات CI و درخواستهای قدیمی Pull Request پخش کردهاند. اگرچه عاملهای مدرن میتوانند این فایلها را جستوجو کنند، اما جستوجو با «جهتیابی» متفاوت است. رویکرد AAIF این حدسزنیها را با یک «ترتیب بوت» (Boot Order) اختصاصی جایگزین میکند؛ شبیه به دفترچه راهنمای سریعی که به تعمیرکار میگوید قبل از دست زدن به هر پیچ، دقیقاً کدام صفحات را بخواند تا سیستم را خراب نکند. همانطور که در تحلیلهای پیشین ما دربارهی امنیت مدلهای بازمتن اشاره کردیم، ساختارمند کردن دسترسی به دانش، کلید کاهش خطاهای عملیاتی است.
پشته دستورالعمل بادوام
یک چیدمان با بازدهی بالا برای عامل (Agent) — همان برنامههای هوشمندی که میتوانند بهجای تولید متن، اقداماتی را در دنیای واقعی یا محیط کد اجرا کنند — به یک پرامپت جادویی تکیه نمیکند، بلکه از پشتهای از فایلهای تخصصی بهره میبرد. فایل ریشه AGENTS.md بهعنوان مسیریاب اصلی عمل میکند. این فایل عامل را به سمت SOUL.md برای تعریف وضعیت عملیاتی (Operating Posture)، USER.md برای درک بستر شخصی کاربر و TOOLS.md برای جزئیات محیطی هدایت میکند. همچنین از اسناد مهارت (Skill docs) برای توضیح زمان بارگذاری گردشهای کاری تخصصی استفاده میشود. در این ساختار، استقرار قابلیتها از طریق استاندارد SKILL.md جایگزین پرامپتهای شکننده شده و توزیع دانش تخصصی را تسهیل میکند.
برای اطمینان از یک شروع بدون خطا و بهینهسازی حافظه، نویسنده این راهنما یک توالی بوت صریح را توصیه میکند:
- خواندن AGENTS.md
- خواندن SOUL.md
- خواندن USER.md
- خواندن فایلهای حافظه روزانه مربوط به امروز و دیروز
- خواندن MEMORY.md در یک نشست (Session) اصلی
این ترتیب بوت از اینکه عامل حدس بزند آیا استفاده از بستر خصوصی در یک چت مشترک مجاز است یا اینکه کدام قوانین پروژه اولویت دارند، جلوگیری میکند.
تفکیک اصول از مکانیسمها
یکی از حیاتیترین تمایزها در چارچوب AGENTS.md، جداسازی «وضعیت کاری» از «مکانیسمهای مخزن» است. وضعیت کاری (Working Posture)، قوانین قضاوتی را تعریف میکند که هر تصمیم بعدی را شکل میدهند. نمونههایی از این قوانین عبارتاند از:
- خواندن کدهای موجود پیش از پیشنهاد انتزاعهای (Abstractions) جدید.
- ترجیح استفاده از کمککنندههای محلی (Local Helpers) بر نصب وابستگیهای جدید.
- محدود نگه داشتن تغییرات صرفاً به درخواست کاربر.
- اجرای اولین تست مفید در کوچکترین مقیاس ممکن و سپس گسترش آن در صورتی که تغییرات، رفتارهای مشترک سیستم را تحت تأثیر قرار دهد.
در مقابل، مکانیسمهای مخزن (Repo Mechanics) دستورات عینی و عملی هستند. در یک مخزن نرمافزاری، این موارد میتوانند شامل موارد زیر باشند:
- نصب وابستگیها:
pnpm install - اجرای تستهای واحد:
pnpm test - بررسی تایپها:
pnpm typecheck
به دلیل اینکه دستورات اجرایی بسیار سریعتر از اصول کلی تغییر میکنند، این جداسازی از تبدیل شدن فایل دستورالعمل به یک «کشوی هرچه هست» جلوگیری میکند؛ جایی که هدایت رفتاری حیاتی در میان سینتکسهای وابسته به نسخه گم میشود.
تعیین مرزهای صریح
دستورات مبهمی مانند «با دادهها محتاط باش» بیاثر هستند. این سیستم در عوض بر «خطوط قرمز» تکیه میکند؛ یعنی افعالی عینی که به اشیایی عینی گره خوردهاند. یک مثال بارز، قانون trash > rm است که الزام میکند حذفهای مخرب باید از طریق یک سیستم سطل زباله (Trash system) قابل بازیابی باشند، نه حذف دائمی با دستور Unix rm. این کار یک قانون ایمنی محلی را تنها با ۳ توکن (Token) — تکههای کوچکی از متن که مدلها آنها را میخوانند — آموزش میدهد، بدون آنکه بخواهد فلسفه یونیکس را درس دهد.
سایر مرزهای ضروری که باید در AGENTS.md گنجانده شوند عبارتاند از:
- عدم ویرایش مستقیم فایلهای تولیدشده (Generated Files).
- عدم تغییر رفتار APIهای عمومی بدون بهروزرسانی تستهای مربوطه.
- عدم اجرای مهاجرتها (Migrations) روی پایگاهدادههای مشترک.
- استفاده از دستور
trashبهجایrmهنگام حذف فایلهای محلی.
بهینهسازی دسترسی به بستر (Context) و مهارتها
عاملها اغلب به دلیل خواندن بیش از حد یا کمتر از حد نیاز، شکست میخورند. در این چارچوب، MEMORY.md تنها در نشستهای اصلی بارگذاری میشود و نه در بسترهای مشترک، که هم بهعنوان یک قانون حریم خصوصی و هم قانون بستر عمل میکند. یادداشتهای روزانه بهعنوان گزارشهای خام (Raw logs) و حافظه بلندمدت بهعنوان دادههای گزینششده (Curated) عمل میکنند.
برای مدیریت دانش در سطح مخزن، نویسنده تقسیمی ساختارمند برای فایلهای بستر پیشنهاد میدهد:
README.md: راهنمای نصب انسانی و نمای کلی پروژه.AGENTS.md: گردش کار عامل و هنجارهای مخزن.docs/architecture.md: تعریف مرزهای فعلی سرویسها.docs/runbooks/: دستورالعملهای عملیاتی (که فقط زمانی خوانده شوند که تسک با عملیات در ارتباط باشد)..env.example: نامهای مجاز متغیرهای محیطی (با این شرط که هرگز فایل.envواقعی خوانده نشود مگر با درخواست صریح کاربر).
عاملها برای عمق عمل از «مهارتها» و برای مسیریابی از AGENTS.md استفاده میکنند. بهجای یک راهنمای ۹۰۰ خطی درباره فرآیندهای انتشار (Release) که شامل سیاستهای تغییرات (Changelog)، یادداشتهای رجیستری پکیجها و مراحل بازگشت (Rollback) باشد، فایل ریشه صرفاً عامل را به skills/release/SKILL.md هدایت میکند، آن هم فقط زمانی که یک تسک انتشار فعال باشد. در فایل ریشه ذکر میشود: «برای کارهای انتشار، پیش از اعمال تغییرات فایل skills/release/SKILL.md را بخوانید. بدون درخواست صریح کاربر، پکیجها را منتشر نکنید و GitHub Release ایجاد نکنید.»
جزئیات محلی در برابر مهارتهای مشترک
ماژولار بودن به جزئیات محیطی نیز گسترش مییابد. TOOLS.md جزئیات محلی را ذخیره میکند، مانند:
- نام دوربینهای متصل
- نامهای مستعار SSH
- بلندگوها
- صداهای مورد پسند
این مورد با مهارتهای قابل استفاده مجدد متفاوت است. یک دستور مشترک (Reusable) ممکن است این باشد: «هنگام عیبیابی CI، قبل از تغییر کد، لاگهای Job شکستخورده را بررسی کن.» اما یک دستور محلی اینگونه است: «داشبورد Staging در آدرس <URL داخلی> قرار دارد.»
جداسازی این موارد تضمین میکند که دستورات قابل استفاده مجدد بدون نشت اسرار محلی یا URLهای داخلی قدیمی، بین پروژهها جابهجا شوند. به همین دلیل AGENTS.md با پروژههای AAIF هماهنگ است: MCP (پروتکل زمینه مدل) اتصال ابزار را مدیریت میکند، agentgateway ترافیک و حاکمیت را کنترل میکند و AGENTS.md رفتار در سطح مخزن را مدیریت میکند.
هنجارهای ارتباطی و نگهداری
فراتر از کدنویسی، این استاندارد تعریف میکند که عامل چه زمانی باید صحبت کند یا سکوت اختیار کند. AGENTS.md فضای کاری شامل قوانین چت گروهی است: دستیاران زمانی پاسخ میدهند که مستقیماً Mention شوند، بتوانند ارزش افزودهای ایجاد کنند یا اطلاعات نادرست معناداری را اصلاح نمایند. آنها در گفتگوهای دوستانه یا زمانی که سوال قبلاً پاسخ داده شده، ساکت میمانند.
برای یک مخزن توسعه، هنجارهای ارتباطی برای نظرات Pull Request شامل این موارد است:
- کامنت گذاشتن تنها زمانی که تغییر بر رفتاری که کاربر مشاهده میکند اثر بگذارد.
- اشاره صریح و ساده به شکافهای تست (Test gaps).
- اجتناب از تکرار محتوای Diff کدها.
- اجتناب از ادعاهای امنیتی گمانهزن بدون ارائه یک مسیر concrete یا ارجاع به یک فایل مشخص.
در نهایت، این چارچوب با مستندات بهعنوان یک قرارداد زنده برخورد میکند. یک قانون سختگیرانه در فضای کاری، ممنوعیت «یادداشتهای ذهنی» است. اگر یک عامل در طول یک تسک، قانونی بادوام یاد میگیرد — مانند یک دستور تست ناپایدار (Flaky test)، یک دایرکتوری تولیدشده که نباید ویرایش شود، یا مرز یک سرویس — باید AGENTS.md یا سند مرتبط را در همان PR بهروزرسانی کند تا هزینهی کشف این خطا برای اجراهای آینده حذف شود.
ساختار پیادهسازی عملی
برای پیادهسازی این سیستم در حال حاضر، نویسنده ساختار زیر را برای فایل ریشه AGENTS.md پیشنهاد میکند:
- شروع از اینجا (Start here): دستورالعملهایی برای خواندن همین فایل،
README.mdو هر فایلAGENTS.mdدر سطح پکیجها. - وضعیت کاری (Working posture): قوانینی برای حفظ الگوهای موجود، محدود نگه داشتن ویرایشها و استفاده از تستهای کوچک.
- دستورات (Commands): لیستهای مربوط به نصب (Install)، تست (Test)، بررسی تایپ (Typecheck) و لینت (Lint).
- نقشه مخزن (Repo map): نقشهبرداری از دایرکتوریها (مثلاً
apps/webبرای فرانتاند وpackages/apiبرای کلاینت API). - مرزها (Boundaries): خطوط قرمز علیه ویرایش فایلهای تولیدشده، دستورات مخرب پایگاهداده، یا انتشار و استقرار (Deploy) بدون مجوز.
- مسیریابی گردش کار (Workflow routing): هدایت به
docs/release.mdبرای انتشارها یاdocs/security.mdبرای تغییرات امنیتی. - نگهداری (Maintenance): دستورالعملهایی برای افزودن درسهای بادوام و حذف محتواهای قدیمی.
این معماری لایهبندی شده تضمین میکند که اولین حرکت عامل منطقی باشد، حرکات خطرناک محدود شوند و فایل بعدی برای خواندن کاملاً مشخص باشد.
گام بعدی شما
- اگر از عاملهای کدنویسی استفاده میکنید، یک فایل
AGENTS.mdدر ریشه پروژه بسازید و قوانین «خط قرمز» (مانند استفاده از trash بهجای rm) را تعریف کنید. - توالی بوت را در دستورات سیستمی خود پیاده کنید تا مدل ابتدا نقش و سپس ابزارها را بشناسد.
- فایلهای مهارت (Skills) را از دستورات عمومی جدا کنید تا پنجره متنی مدل با اطلاعات غیرضروری پر نشود.
اما تأثیر این استاندارد بر interoperability یا همکاری بین مدلهای مختلف شرکتهای متفاوت، لایهی پیچیدهتری است — به تحلیل ما دربارهی پروتکل MCP مراجعه کنید.
گفتگو