استفاده از یک فایل Markdown برای کنترل رفتار یک عامل هوش مصنوعی، مهندسی نیست؛ بلکه یک قمار احتمالی است. در حالی که چارچوبهایی مانند Superpowers، Agent Skills و مهارتهای Matt Pocock با استقبال گستردهای روبرو شدهاند و تا ژوئیه ۲۰۲۶ مجموعاً بیش از ۵۰۰,۰۰۰ ستاره در گیتهاب کسب کردهاند (بهطور مشخص ۲۵۶,۰۰۰ ستاره برای Superpowers، ۱۷۶,۰۰۰ ستاره برای مهارتهای Pocock و ۷۹,۰۰۰ ستاره برای Agent Skills)، تکیه آنها بر «نثر» (Prose) به عنوان لایه کنترل، ناپایداری سیستمیکی ایجاد میکند که قابلیت اطمینان در مقیاس تولید را از بین میبرد.
این ناپایداری در مقطع حساسی از توسعه هوش مصنوعی رخ میدهد. در حالی که تیمها از رابطهای سادهی گفتگو (Chat) به سمت عاملهای خودمختار حرکت میکنند، صنعت در تلاش است تا یک «لایه کنترل» (Control Plane) قابل اعتماد را تعریف کند. با تکیه بر پوششهای قبلی ما در مورد اینکه چرا تیمهای هوش مصنوعی در حال جایگزینی Slack با لایههای کنترل اختصاصی هستند، روند فعلی شامل تلاش برای حاکمیت بر رفتارهای پیچیده هوش مصنوعی با استفاده از همان ابزاری است که باعث پیشبینیناپذیری میشود: زبان طبیعی. این چالش در واقع ادامه بحثی است که در تحلیل ما پیرامون جایگاه مدلهای زبانی در سطح تکمیلکننده کد بهجای معماری داشتیم، جایی که تکیه بیش از حد به پیشنهادهای مدل بدون ساختار مهندسی مورد نقد قرار گرفت.
در نرمافزارهای سنتی، لایه کنترل همان بخشی است که بر رفتار سیستم حاکم است: فایلهای پیکربندی، سیستمهای تعیین نوع (Type Systems)، سیاستهای کنترل دسترسی، خطوط لولهی استقرار (Deployment Pipelines) و دروازههای CI/CD. این مکانیسمها قطعی (Deterministic) هستند. یک بررسیکننده نوع (Type Checker) یا تأیید میشود یا خطا میدهد؛ یک خط لوله CI یا موفق میشود یا با خطا مواجه میگردد. در این ساختار، رفتار سیستم تکرارپذیر است و میتوان آن را بهطور مستقل تأیید کرد.
در مقابل، چارچوبهای مدرن عاملی نوع جدیدی از لایه کنترل را معرفی کردهاند که از دستورات متنی استفاده میکند: فایلهای SKILL.md، پرامپتهای سیستمی، فایلهای AGENTS.md و فایلهای CLAUDE.md. در این مدل، عامل جملات زبان طبیعی را میخواند و تصمیم میگیرد چه کاری انجام دهد. این یک جزئیات کوچک در پیادهسازی نیست، بلکه یک تغییر بنیادین در کنترل رفتار است. از آنجا که این جملات مبهم و وابسته به بافت (Context-sensitive) هستند، بهصورت احتمالی تفسیر میشوند، با این حال صنعت اکنون این روند را «مهندسی» مینامد.
مکانیسمهای شکست احتمالی
بر اساس یک تحلیل فنی که در ۱۸ ژوئیه ۲۰۲۶ در dev.to منتشر شد، این وابستگی به نثر منجر به سه حالت شکست اصلی میشود. وقتی کاربر دستوری مانند «شما باید پیش از پیادهسازی، تستها را بنویسید» را مینویسد، عامل آن را مانند اجرای یک حاشیه نوع (Type Annotation) توسط کامپایلر اجرا نمیکند. در عوض، عامل قصد کاربر را تفسیر میکند و این تفسیر میتواند بسته به داربستها (Scaffolding) بهشدت تغییر کند، حتی زمانی که از یک مدل هوش مصنوعی یکسان استفاده شود؛ واقعیتی که در مستندات SWE-bench شرکت Anthropic نیز به آن اذعان شده است.
- رانش معنایی (Semantic Drift): در طول یک جلسه طولانی، عامل بافتهای مختلفی را جمعآوری میکند. دستورات اولیه به عقب رانده میشوند و بافتهای جدید، چارچوب دستورات قدیمی را تغییر میدهند. تفسیری که عامل در گام اول از «ابتدا تست بنویس» دارد، ممکن است در گام ۴۷ متفاوت باشد؛ نه به دلیل تغییر در کلمات، بلکه چون بافت surrounding تغییر کرده است. هیچ چارچوب فعلی قادر به تشخیص این نیست که چه زمانی تفسیر عامل از قصد اولیه منحرف شده است.
- بازتفسیر هدف (Goal Reinterpretation): عاملها مکرراً دامنه کار را از طریق بازتفسیرهای منطقیِ اهداف مبهم گسترش میدهند. برای مثال، عاملی که برای رفع یک باگ درخواست شده، ممکن است تصمیم بگیرد که کدهای اطراف نیاز به بازسازی (Refactor) دارند، یا عاملی که برای ایجاد یک Endpoint جدید خواسته شده، تصمیم بگیرد که قرارداد API موجود باید بهروزرسانی شود. اینها توهمات (Hallucinations) سنتی نیستند، بلکه اجراهای مطمئنی از اهدافی هستند که بدون تأیید کاربر، تغییر جهت دادهاند.
- شکست همبسته تأییدکننده (Correlated Verifier Failure): این حادترین مشکل است. اکثر چارچوبها شامل یک مرحله تأیید هستند که در آن عامل کد را بررسی یا خروجی را چک میکند. اما اگر تأییدکننده نیز یک LLM باشد که همان دستورات متنی را میخواند، در معرض همان رانش معنایی قرار میگیرد که عامل اجرایی داشت. این وضعیت «دو راندهشونده که یکدیگر را چک میکنند» ایجاد میکند؛ جایی که actor و verifier مدل، بافت پرامپت یا تفسیر اشتباه یکسانی دارند. در نتیجه، تأییدکننده در همان جهتی که عامل خطا کرده است، شکست میخورد و نمیتواند خطا را بگیرد؛ مشکلی که در ارزیابیهای LLM-as-judge به عنوان یک نقص قابلیت اطمینان شناخته شده است.
تضاد با طراحی مدل
بهطور متناقض، سازندگان توانمندترین مدلها مسیر متفاوتی را پیشنهاد میدهند. شرکت Anthropic در راهنمای «ساخت عاملهای مؤثر» (Building Effective Agents)، توصیه میکند سادهترین راه حل ممکن پیدا شود و تنها در صورت نیاز، پیچیدگی افزایش یابد. آنها صراحتاً هشدار میدهند که سیستمهای عاملی اغلب تأخیر و هزینه را فدای عملکرد بهتر در وظایف میکنند و در برخی موارد، توصیه میکنند که اصلاً سیستم عاملی نسازید و بهجای آن، گردشهای کاری قطعی و پیشبینیپذیر را برای وظایف تعریفشده ترجیح دهید.
عامل پیشرفته آنها در SWE-bench از فلسفه «کدگذاری همه چیز در Markdown» دوری کرد. آنها به جای انباشت دستورات متنی، داربستها را حداقلی و پرامپتها را کوتاه نگه داشتند و به مدل اهدافی شفاف، ابزارهای مشخص و آزادی عمل دادند تا رویکرد خود را انتخاب کند.
این شواهد نشان میدهد که کاهش نثر، نه افزایش آن، رفتار بهتری در عامل ایجاد میکند. برای مثال، جداول «ضد-توجیه» (anti-rationalization tables) موجود در Agent Skills که تلاش میکنند به پیش از این به بهانههای رایج پاسخ دهند، خود با نثر نوشته شدهاند. چون این جداول توسط همان سیستم احتمالی تفسیر میشوند، رانش را از بین نمیبرند؛ بلکه صرفاً نثر بیشتری را برای بحث با رانش اضافه میکنند.
گذار به حفاظهای قطعی
برای اینکه عاملها در محیط تولید کاربردی باشند، تحلیل مذکور استدلال میکند که آنها به یک لایه قطعی نیاز دارند که تضمینهای واقعی ارائه دهد. در حالی که کنترل مبتنی بر نثر میتواند احتمال موفقیت را تغییر دهد (مثلاً یک مهارت TDD احتمال نوشتن تست توسط عامل را بالا میبرد)، اما برای محیط تولید ناکافی است چون هیچ تضمین ریاضی ارائه نمیدهد.
نویسندگان پیشنهاد میکنند از تکیه صرف بر پرامپتهای متنی فاصله گرفته و به سمت مکانیسمهای قطعی زیر حرکت کنند:
اعتبارسنجی طرحواره کامپایلشده (Compiled Schema Validation)
به جای دستور دادن به عامل برای «بازگرداندن یک شیء JSON معتبر»، توسعهدهندگان باید از اجبار JSON Schema در مرز API استفاده کنند. قابلیت validateSchema() در Spring AI این کار را با اعتبارسنجی پاسخ در برابر یک طرحواره کامپایلشده انجام میدهد، خطاها را به مدل بازمیگرداند و تا زمان موفقیت، تلاش مجدد (Retry) میکند. این رویکرد، تفسیر متنی را بهطور کامل حذف میکند.
بررسی سختگیرانه نوع (Hard Type Checking)
اگر یک عامل کد مینویسد، بررسیکننده نوع (Type Checker) باید به عنوان یک دروازه قطعی عمل کند. ابزارهایی مانند TypeScript، کامپایلر Java یاBorrow Checker در Rust تضمین میکنند که اگر انواع دادهها تأیید نشوند، کد تحت هیچ شرایطی ادغام (Merge) نشود، صرفنظر از اینکه تفسیر داخلی عامل از وظیفه چه بوده است. این سختگیری در ساختار کد دقیقاً همان چیزی است که یکپارچگی الگوهای کدنویسی را به یک مزیت رقابتی تبدیل میکند، چرا که کدِ پیشبینیپذیر، پذیرش راحتتری توسط مدلهای AI دارد.
مجموعه تستهای مستقل
یک مجموعه تست خوب به عنوان یک مشخصات (Specification) قطعی عمل میکند. نیاز حیاتی این است که تستها باید بهطور مستقل از پیادهسازی عامل نوشته شوند. اگر همان عاملی که کد را تولید میکند، تستها را نیز بنویسد، حفاظ ایمنی به مخاطره میافتد. اگرچه چارچوب ارزیابی در Agent Skills با بررسی مسیر صحیح مهارتها در CI یک گام رو به جلو است، اما معمولاً خودِ مهارتها را تست میکند، نه خروجی نهایی عامل را.
گزارشهای بازرسی تغییرناپذیر (Immutable Audit Logs)
به جای اعتماد به گزارشهای متنی عامل، سیستمها باید هر فراخوانی ابزار، تغییر فایل و اجرای دستور را در یک لاگ «فقط-افزودنی» (Append-only) ثبت کنند. این کار به توسعهدهندگان اجازه میدهد تا آنچه عامل «ادعا کرده» انجام داده را با آنچه «واقعاً» انجام داده مقایسه (Diff) کنند و رانش معنایی را پس از وقوع شناسایی نمایند.
تأییدکنندگان غیر-LLM برای مسیرهای حساس
عملگرانه ترین رویکرد در تولید این است: LLM پیشنهاد دهد، اما یک سیستم قطعی تصمیم نهایی را بگیرد. برای اقدامات با ریسک بالا- مانند اجرای معاملات مالی، ادغام کدها یا استقرار در محیط تولید- تصمیم نهایی نباید توسط LLM گرفته شود.
دیدگاه فرانتاند
این فقدان «تعریفِ پایان» (Definition of Done) در عاملهای فرانتاند نیز مشاهده میشود. همانطور که در گزارشهای تکمیلی اشاره شده، یک عامل فرانتاند ممکن است وقتی از او خواسته میشود یک صفحه را «پولیش» (Polish) کند، تنها لبهها را گرد کرده و چند کارت اضافه کند و سپس اعلام پیروزی نماید، در حالی که مسائل محوری UX مانند سلسلهمراتب بصری یا پاسخگویی در نمای مختلف (Viewport Responsiveness) نادیده گرفته شده است. این ثابت میکند که بدون یک معیار قطعی برای «پایان»، عاملها به جای الزامات عملکردی، بر اساس زیباییشناسی ظاهری عمل میکنند.
تحلیل: شکاف مهندسی
این تغییر دیدگاه، پیشفرضهای بنیادین موج فعلی «مهارتهای عاملی» (Agent-skill) را تغییر میدهد. در این بحث، دو افراط غلط وجود دارد. اولین، این باور است که «کنترل متنی، مهندسی است». اینطور نیست. مهندسی مستلزم تکرارپذیری، قابلیت تأیید و اجرای مستقل است. نامیدن مجموعهای از فایلهای Markdown به عنوان یک «متدولوژی توسعه نرمافزار»، کلمه مهندسی را بیش از حد کشیده است.
افراط دوم این است که «کنترل متنی بیفایده است». اینطور هم نیست. این یک رویکرد ناقص اما مفید برای هدایت سیستمهای احتمالی است، درست همانطور که مدیریت پیکربندی (Configuration Management) رویکردی ناقص برای هدایت سیستمهای قطعی است. این روش توزیع احتمالات را در جهتهای مفیدی تغییر میدهد، اما تضمین ارائه نمیکند.
ما در حال حاضر در فاز تحقیق و توسعه (R&D) هستیم. چارچوبهای مهارت در شکل فعلی، ابزارهای R&D هستند، نه مهندسی تولید. آنها برای وظایفی که بازبینی انسانی شکستهای باقیمانده را میگیرد ارزشمندند، اما وقتی بدون نظارت اجرا شوند، خطرناک هستند.
برای تیمهای فنی، نتیجه شفاف است: ارزش یک چارچوب در این نیست که چه تعداد مهارت را در Markdown ذخیره میکند، بلکه در این است که چگونه دروازههای غیر-احتمالی را ادغام میکند. چارچوبهایی که بقا مییابند، آنهایی هستند که حفاظهای قطعی- بررسی نوع، طرحوارههای کامپایلشده، دروازههای CI، تستهای مستقل و لاگهای تغییرناپذیر- را به عنوان شهروند درجه یک در کنار لایه متنی قرار دهند. نثر به عامل میگوید چه چیزی را «تلاش» کند؛ لایه قطعی «اجبار» میکند که چه چیزی قابل پذیرش است. تا زمانی که این ادغام صورت نگیرد، نامیدن این روند «مهندسی»، تنها یک آرزو است.
گام بعدی
توسعهدهندگان باید جریانهای کاری فعلی خود را بازرسی کنند تا نقاطی را که «نثر به عنوان کنترل» برای مسیرهای حساس استفاده شده شناسایی کرده و آنها را با اعتبارسنجی JSON Schema یا دروازههای مستقل CI جایگزین کنند. همچنین میتوانید راهنمای رسمی Anthropic درباره ساخت عاملهای مؤثر را مطالعه کنید تا ببینید چگونه با به حداقل رساندن داربستها، عملکرد را بهبود ببخشید.
اما داستان سختافزاریِ مدیریت این لایههای کنترل حتی پیچیدهتر است؛ برای درک هزینه استنتاج در مقیاس تولید، به تحلیل ما درباره تراشههای Blackwell مراجعه کنید.
گفتگو