تصور کنید مستندات فنی دیگر متونی برای خواندن نباشند، بلکه دیوارهایی سخت و اجرایی باشند که اجازه خطای مدل را نمی‌گیرند. این تغییر رویکرد در ۱۰ جولای ۲۰۲۶ با عرضه عمومی Azure Cosmos DB Agent Kit توسط مایکروسافت ملموس شد و سیگنالی از تغییر بنیادین در نحوه هدایت عامل‌های کدنویس در سرویس‌های ابری ارسال کرد.
برای دهه‌ها، مستندات بر پایه قضاوت انسانی بودند. یک برنامه‌نویس می‌توانست مثالی ساده را ببیند و به‌طور غریزی بفهمد که این کد در مقیاس واقعی عملیاتی شکست می‌خورد. یک خواننده انسانی متوجه می‌شود کجا یک تنظیم پیش‌فرض خطرناک است، چه زمانی یک نکته در پاورقی اهمیت حیاتی دارد، یا چه زمانی یک قطعه کد فقط «مسیر خوش‌بینانه» (Happy Path) را نشان می‌دهد، زیرا توضیح مسیرهای دشوار و زشت باعث می‌شد صفحه غیرقابل خواندن شود. اما عامل‌ها (Agents) فاقد این ظرافت‌ها هستند؛ آن‌ها در جذب الگوها عالی‌اند اما اغلب این الگوها را دقیقاً یک اینچ خارج از جایی که هنوز کار می‌کنند، به کار می‌برند. نتیجه این است: اپلیکیشن‌هایی که کامپایل می‌شوند، مسیرهای (Routes) درستی دارند و فایل پیکربندی‌شان مرتب است، اما زیر فشار داده‌های واقعی در محیط تولید فرو می‌پاشند.
گذار به هدایت اجرایی
مستندات سنتی پیشنهاد می‌دهند، اما Azure Cosmos DB Agent Kit محدودیت ایجاد می‌کند. به نقل از یک تحلیل فنی در dev.to، این کیت شامل بیش از ۱۲۰ قانون در ۱۲ دسته‌بندی مختلف است. این‌ها صرفاً توصیه نیستند، بلکه حاصل بیش از ۲۰۰ تکرار آزمون خودکار هستند که در آن‌ها عامل‌ها، اپلیکیشن‌های واقعی را از صفر ساخته‌اند.
این متدولوژی با مستندات مانند نرم‌افزار رفتار می‌کند. یک پاراگراف که پیشنهاد می‌دهد از «کلید پارتیشن درست» استفاده کنید، مفید است، اما قانونی تست‌شده که هر بار انتخاب اشتباه عامل را شناسایی کند، به‌مراتب اثرگذارتر است. این رویکرد جلسات را کاهش داده و با حذف اصطکاک‌های معماری تکراری، بهره‌وری را افزایش می‌دهد. عامل‌ها به مستندات زیباتر نیاز ندارند؛ آن‌ها به محدودیت‌های دقیق‌تر نیاز دارند. تلاش برای کاهش اثرات منفی تکرار اشتباهات در مدل‌های هوش مصنوعی، موضوعی است که اخیراً در پلتفرم‌های دیگر نیز دیده شده است؛ برای مثال، استک اورفلو با معرفی حافظه مشترک تلاش کرد تا جلوی تکرار خطاهای رایج عامل‌ها را بگیرد.
بر اساس مستندات مایکروسافت، آن‌ها به‌جای بازنویسی متون، یک سیستم تست حلقه-بسته پیاده کردند. آن‌ها پنج سناریوی کاربردی خاص را برای فشار آوردن به خروجی عامل و تست استرس تعریف کردند:
- یک API سفارشات تجارت الکترونیک
- جدول امتیازات بازی
- خط لوله تله‌متری IoT
- یک اپلیکیشن چت مبتنی بر تولید بازیابی‌افزا (RAG)
- یک پلتفرم SaaS چندمستأجری
برای هر سناریو، GitHub Copilot با استفاده از مهارت‌های Agent Kit کد را تولید کرد. سپس خروجی در یک خط لوله CI (یکپارچه‌سازی مستمر) روی شبیه‌ساز Cosmos DB اجرا شد تا رفتار API، تنظیمات زیرساختی و یکپارچگی داده‌ها بررسی شود. هر بار که عامل شکست می‌خورد، مایکروسافت آن شکست را به یک قانون جدید تبدیل و چرخه را دوباره تست کرد.
این یک چرخش از مهندسی پرامپت (Prompt Engineering) — که بیشتر شبیه جادوی کلمات است — به دیسیپلینی است که ترکیبی از مهندسی تست، مهندسی پلتفرم و مستندسازی است. این سیستم اکنون مانند یک محصول با حلقه‌های بازخورد، تحلیل‌های رگرسیون و سطوح اعتماد عمل می‌کند و از ماشین‌آلات خسته‌کننده CI استفاده می‌کند تا اولین نسخه یک قانون را به چیزی دقیق تبدیل کند.
مقابله با «دانش شکل‌گرفته از اینترنت»
مدل‌های همه‌منظوره اغلب به «دانش شکل‌گرفته از اینترنت» تکیه می‌کنند؛ الگوهایی که در وب رایج‌اند اما برای واقعیت‌های عملیاتی یک سرویس خاص غلط هستند. Agent Kit دقیقاً اشتباهات «شرم‌آور» اما حیاتیِ دامنه-ویژه را هدف قرار می‌دهد؛ اشتباهاتی که انسان‌ها معمولاً پس از از دست دادن یک روز کاری کامل یاد می‌گیرند. این قوانین، «بافت‌های سخت‌شده» یا همان تجربیات تلخ سرویس را بسته‌بندی می‌کنند تا عامل پیش از ایجاد هرج‌ومرج، از آن‌ها استفاده کند.
نمونه‌های کلیدی این قوانین عبارت‌اند از:
- سریال‌سازی Enum: جلوگیری از سناریوهایی در برنامه‌های .NET تجارت الکترونیک که SDK وضعیت سفارش را به صورت عدد ذخیره می‌کند اما کوئری‌ها با رشته‌هایی مثل «Pending» و «Shipped» فیلتر می‌شوند. این یک باگ «زیبا» ایجاد می‌کند؛ برنامه نمی‌ترکد یا استک‌تریس نشان نمی‌دهد، بلکه صرفاً آرایه‌های خالی برمی‌گرداند در حالی که ظاهرش کاملاً درست است — یعنی به‌طور خاموش به کاربر دروغ می‌گوید.
- پارامتری کردن SQL: اصلاح غریزه مدل برای پارامتری کردن کلمه کلیدی
TOPدر SQL مربوط به Cosmos DB. در حالی که پارامتری کردن مقادیر معمولاً غریزه درستی است، اماTOPنیاز به یک عدد صریح (Literal Integer) دارد؛ در غیر این صورت سیستم خطای 400 Bad Request می‌دهد. - مدیریت وابستگی‌ها: رسیدگی به نیازهای خاص کلاینت‌های async پایتون برای
aiohttpکه وارد کردن‌های (Imports) ساده معمولاً آن‌ها را نادیده می‌گیرند. این کار از شکست کد در زمان اجرا (Runtime) جلوگیری می‌کند، زیرا کد تولیدشده به‌طور طبیعی وابستگی را شناسایی نمی‌کرد. - جهت ایندکس: اطمینان از اینکه ایندکس‌های ترکیبی با جهت ASC/DESC مورد نیاز مطابقت دارند. یک کوئری ممکن است در تست‌های کوچک کار کند، اما زمانی که حجم داده‌ها واقعی شود، به دلیل عدم تطبیق جهت ایندکس، شکست بخورد.
جزئیات محدودیت‌های ماشین‌خوان
در یک سرویس پایگاه‌داده، فاصله بین «کد معتبر» و «کد خوب» با جزئیات بسیار ریز و دانه‌بندی‌شده تعریف می‌شود. Agent Kit حقیقت محلی را ارائه می‌دهد که بر دانش عمومی اینترنت غلبه می‌کند. این امر مانع از آن می‌شود که عامل‌ها از الگوهای عمومی استفاده کنند که منجر به شکست در محیط تولید می‌شود.
محدودیت‌های عملکرد و هزینه:
- شکل کوئری: شناسایی اینکه کدام شکل‌های کوئری باعث می‌شوند از یک صورت‌حساب غافلگیرکننده جلوگیری شود.
- پارتیشن‌بندی: تعیین اینکه کدام کلید پارتیشن‌بندی، بار کاری را منطقی نگه داشته و از ایجاد نقاط داغ (Hotspots) جلوگیری می‌کند.
- تعاریف ایندکس: اطمینان از اینکه ایندکس در مواجهه با حجم واقعی داده‌ها دوام می‌آورد، نه اینکه فقط در یک مجموعه تست کوچک کار کند.
اتصالات و پایداری:
- الگوهای SDK: انتخاب الگوهایی که از نوسان و چرخه تکراری اتصالات (Connection Churn) جلوگیری می‌کنند.
- منطق تکرار (Retry): پیاده‌سازی الگوهای تکرار ایمن در مقابل الگوهایی که به‌طور ناخواسته یک حمله DoS کوچک علیه حساب خود کاربر ایجاد می‌کنند.
- سریال‌سازی: تطبیق دقیق تنظیمات سریال‌سازی با مثال‌های ارائه شده در کوئری‌ها.
ظرافت‌های محیطی:
- هم‌پاری شبیه‌ساز: شناسایی اینکه کدام رفتارهای شبیه‌ساز با سرویس ابری متفاوت است تا از خطای «روی سیستم من کار می‌کرد» جلوگیری شود.
- منطق‌های وابسته به نسخه: ردیابی پیش‌فرض‌هایی که تغییر کرده‌اند (مثلاً: «ما این مورد را در ماه ژوئن تغییر دادیم چون مشتریان مدام از روش گران‌قیمت استفاده می‌کردند»).
مستندات به‌مثابه یک محصول
این رویکرد، مخزن مستندات را به یک پروژه نرم‌افزاری تبدیل می‌کند. مستندات اکنون شامل دستورالعمل‌های عامل، مصنوعات تولیدشده مورد انتظار، اسکریپت‌های اعتبارسنجی و گزارش‌های ارزیابی است.
با تبدیل هدایت‌ها به محصولی با مجموعه‌های رگرسیون، مایکروسافت از «پوسیدگی مستندات» جلوگیری می‌کند. در مدل قدیمی، یک صفحه تاریخ‌گذشته یا یک اسکرین‌شات اشتباه توسط انسان‌هایی که زیر لب می‌گویند «این قدیمی شده است» نادیده گرفته می‌شد و کاربر از آن عبور می‌کرد. در عصر عامل‌ها، یک عامل با اعتمادبه‌نفس کاملِ یک مدیر پروژه که می‌گوید «بیا یک هماهنگی سریع (Quick Sync) داشته باشیم»، دستورات تاریخ‌گذشته را اجرا می‌کند و فاجعه می‌آفریند. برای مدیریت چنین حجم بالای از تکرارها و دسترسی به مخازن دانش در مقیاس بالا، زیرساخت‌های جدیدی در حال ظهور هستند؛ برای نمونه، راهکار Entire برای میزبانی مخازن هوش مصنوعی سعی دارد گلوگاه‌های زیرساختی را برای دسترسی سریع‌تر به داده‌ها حذف کند.
برای جلوگیری از این اتفاق، مخزن مستندات مدرن باید شامل موارد زیر باشد:
- دستورالعمل‌های اجرایی عامل و وظایف نمونه (Example Tasks)
- اسکریپت‌های اعتبارسنجی و گزارش‌های ارزیابی
- موارد شکست شناخته‌شده و یک مجموعه رگرسیون (Regression Suite)
- قوانینی که به‌طور خاص به نسخه‌های خاص پلتفرم گره خورده‌اند
برخی تیم‌ها ممکن است احساس کنند که این کار مستندات را «سنگین‌تر» می‌کند، اما جایگزین آن بدتر است: عامل‌هایی که با سرعت ماشین، کدهایی را بر اساس دانش قبیله‌ای (Tribal Knowledge) قدیمی تولید می‌کنند.
مکانیسم حفاظت از نگهبانان سیستم
این تغییر همچنین به عنوان یک مکانیسم حفاظتی برای Maintainerها عمل می‌کند. تبدیل بازخوردهای تکراریِ بررسی کد (Review) به هدایت‌های تست‌شده برای عامل‌ها، یکی از معدود راه‌های مقیاس‌بندی کدنویسی AI است بدون اینکه بار پاک‌سازی روی دوش مهندسان ارشد بیفتد. این کار انرژی عاطفی تبدیل شدن به یک «قانون تغییر مسیر انسانی» را می‌گیرد؛ کسی که مجبور است بارها و بارها لینک یک مستند را بفرستد در حالی که مهندس مربوطه آه می‌کشد.
برای ساخت این حفاظ‌ها، تیم‌ها نباید با طوفان فکری درباره آنچه عامل «باید» بداند شروع کنند، بلکه باید شکست‌های واقعی را از این لنز‌ها تحلیل کنند:
- چه اشتباهاتی ماه گذشته در بررسی کد اصلاح شدند؟
- کدام کدهای تولیدشده تست اولیه را پاس کردند اما بعداً در تولید شکست خوردند؟
- کدام مثال‌ها به‌طور مداوم توسط مدل به‌طور اشتباه کپی می‌شوند؟
- کدام رفتارهای خاص سرویس، توسعه‌دهندگان جدید را غافلگیر می‌کند؟
- کدام پیش‌فرض‌های گران‌قیمت باید به هر قیمتی از آن‌ها اجتناب شود؟
- کدام عناصر هرگز نباید بدون دخالت انسانی تغییر کنند؟
نتیجه نهایی
این گذار نشان می‌دهد که آینده پلتفرم‌های توسعه — چه عمومی و چه داخلی — بر «مسیرهای طلایی» (Golden Paths) ماشین‌خوان متکی خواهد بود. اگر یک تیم SRE داخلی الگویی برای Workerهای پس‌زمینه دارد، یا یک تیم پایگاه‌داده قوانینی برای جلوگیری از شمای (Schema) بد دارد، این قوانین باید محدودیت‌های اجرایی باشند، نه گلوله‌های متنی در یک ویکی. اگر شرکت شما مسیری طلایی برای سرویس‌ها دارد، عامل‌های شما باید آن را در فرمی دریافت کنند که واقعاً بتوانند از آن استفاده کنند.
در غیر این صورت، عامل از دانش شکل‌گرفته از اینترنت استفاده می‌کند؛ دانشی که برای یک دموی ساده عالی است، اما وقتی صورت‌حساب ماهانه با یک کلاه کوچک سرش می‌رسد، اصلاً خوشحال‌کننده نیست.
در حالی که انسان همچنان در حلقه حضور دارد — احتمالاً با یک فنجان قهوه و نگاهی مشکوک به کلاس‌های Repository تولیدشده — Agent Kit مرحله تکراریِ قضاوت را به ابتدای چرخه منتقل می‌کند. عصر مستنداتی که صرفاً «وجود دارند» به پایان رسید؛ عصر مستنداتی که «کارکردشان را ثابت می‌کنند» فرا رسیده است. برای مشاهده این روند در عمل، توسعه‌دهندگان می‌توانند Agent Kit را با جریان‌های کاری Copilot خود ادغام کنند تا ببینند محدودیت‌های صریح چگونه نیاز به اصلاحات معماری دستی را کاهش می‌دهند.
گام بعدی شما
- اگر از Copilot استفاده می‌کنید، Agent Kit را با جریان‌های کاری خود ادغام کنید تا ببینید محدودیت‌های صریح چگونه نیاز به اصلاحات معماری دستی را کاهش می‌دهند.
- لیست اشتباهات رایج ریویوهای ماه گذشته تیم خود را استخراج کنید و سعی کنید آن‌ها را به قوانین صریح (Guardrails) تبدیل کنید.
- بررسی کنید کدام بخش از مستندات داخلی شما «پوسیده» است و مدل‌های AI را به مسیر اشتباه می‌برد.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره تراشه‌های Blackwell مراجعه کنید.
گفتگو