آیا افزودن عامل‌های هوش مصنوعی لزوماً کیفیت خروجی مهندسی را افزایش می‌دهد؟

اگر فکر می‌کنید با اضافه کردن «عامل‌های تخصصی» به هر بخش از پروژه، کیفیت کدتان بالا می‌رود، احتمالاً در حال سوزاندن بودجهٔ توکن‌های خود هستید. واقعیت این است که در بسیاری از موارد، تکثیر بستر متنی و تأخیر در انتقال داده بین عامل‌ها، نتیجه‌ای جز افزایش ریسک ادغام ندارد. اضافه کردن عامل‌های بیشتر به یک وظیفه کدنویسی، به‌طور خودکار مهندسی بهتری تولید نمی‌کند.

به نقل از گزارش منتشرشده توسط Codex How To، سؤال اصلی برای توسعه‌دهندگان این نیست که «آیا این وظیفه می‌تواند از زیر-عامل‌ها استفاده کند؟»، بلکه این است که: «آیا این وظیفه شامل کارهای مستقل و محدودی است که ارزش آن‌ها از هزینهٔ هماهنگی بیشتر باشد؟»

بسیاری از برنامه‌نویسان در حال حاضر برای تقسیم وظایف بین عامل‌ها به شهود تکیه می‌کنند. این رویکرد منجر به مهندسی «شعار-محور» می‌شود؛ جایی که عامل‌های «بک‌اند»، «تست» و «بازبینی» ایجاد می‌شوند، اما با وجود تداخل روی فایل‌های یکسانی یا اجرای مراحل وابسته به هم، به صورت مجزا تعریف شده‌اند. برای حل این مشکل، Codex How To — یک پروژه متن‌باز مستقل — یک محک (Benchmark)، ارزیاب و مجموعه‌ای از معیارهای اندازه‌گیری بدون وابستگی منتشر کرده است تا مشخص شود چه زمانی ارکستراسیون (Orchestration) — شبیه به یک ارکستر که هر نوازنده ساز خاصی می‌زند اما همه از روی یک نت واحد پیش می‌روند — واقعاً ارزش افزوده ایجاد می‌کند و چه زمانی یک تک-عامل برتر است. این رویکرد در راستای مدیریت دقیق‌تر تفویض وظایف به عامل‌ها بر اساس ماتریس قطعیت است تا از اتکای صرف به شهود برنامه‌نویس کاسته شود.

همان‌طور که در تحلیل‌های پیشین ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، پیچیدگی بیش از حد در معماری‌های هوش مصنوعی اغلب نقاط ضعف جدیدی ایجاد می‌کند. در اینجا نیز، پیچیدگی در مدیریت عامل‌ها می‌تواند منجر به خطاهای ادغام شود.

قانون تصمیم‌گیری حداقلی

شما باید زمانی به یک تک-عامل بسنده کنید که تغییرات کوچک باشند، رابط‌ها هنوز تثبیت نشده باشند یا چندین مرحله نیاز به ویرایش فایل‌های مرکزی یکسانی داشته باشند. ارکستراسیون محدود تنها زمانی توصیه می‌شود که تمام شرایط زیر برقرار باشد:

• وظیفه حداقل دارای دو سطح مالکیت واقعی باشد.
• هر نویسنده بتواند مسیرهای انحصاری خود را مدیریت کند.
• رابط بین این مسیرها پیش از شروع اجرا، تثبیت (Frozen) شده باشد.
• کنترل‌کننده، مسئولیت ادغام، بررسی‌های سیستمی و بازبینی نهایی را بر عهده داشته باشد.
• هر عامل به‌جای گزارش‌های توصیفی و روایت‌های طولانی، شواهد موجز ارائه دهد.
• یک معیار پذیرش خارجی بتواند هر دو روش اجرا را ارزیابی کند.

مرزهای مالکیت عینی

عناوین شغلی، مرزهای مالکیت نیستند. یک مرز مفید باید عینی و ملموس باشد. برای مثال، یک نویسنده مالک مسیر incident/** و دیگری مالک web/** باشد و هیچ‌کدام اجازه تغییر قرارداد مشترک را نداشته باشند.

اگر کنترل‌کننده متوجه شود که رابط ناپایدار است یا سطوح به هم گره خورده‌اند، انتخاب درست یک تک-عامل یا یک خط لوله (Pipeline) متوالی است. برای اصلاحات کوچک و محدود، هزینهٔ بستر متنی برای راهنمایی گردش‌کار ممکن است بیشتر از سودی باشد که به ارمغان می‌آورد.

محک پاسخ به حوادث

برای آزمایش این قوانین، این پروژه محکی ایجاد کرد که ساخت یک اپلیکیشن کوچک با سطوح متقاطع و بدون وابستگی‌های شخص ثالث را می‌طلبد. این وظیفه شامل موارد زیر است:

• ذخیره‌سازی JSON با جایگزینی اتمیک و Thread-safe.
• اعتبارسنجی، هم‌روندی خوش‌بینانه (Optimistic Concurrency) و انتقال وضعیت‌ها.
• یک API پروتکل HTTP و سرویس‌دهی استاتیک امن در برابر پیمایش مسیر (Traversal-safe).
• یک کلاینت مرورگر واکنش‌گرا و دسترس‌پذیر.
• تست‌های متمرکز، بررسی‌های ادغام، بازبینی نهایی و تحویل شواهد.

این ساختار را تعمداً به دو سطح تقسیم می‌کند: incident/** برای ذخیره‌سازی، اعتبارسنجی و آداپتور HTTP، و web/** برای رفتار مرورگر و CSS/HTML.

هر دو حالت تک-عامل و ارکستره‌شده از یک کامیت، متن وظیفه، تست‌های ارائه شده و قرارداد تثبیت‌شده شروع می‌کنند. در حالت ارکستره، حداکثر دو عامل اجراکننده وجود دارند و کنترل‌کننده مالک ارزیابی و دریافت نهایی است. هر دو با یک ارزیاب خارجی سنجیده می‌شوند تا یکپارچگی ساختار، ذخیره‌سازی هم‌روند و نوشتن‌های اتمیک سخت‌گیرانه بررسی شود.

نتایج اجرای اولیه

در اولین اجرای آزمایشی (Smoke Run) برای ارزیابی ابزار محک، نتایج به شرح زیر بود:

• پذیرش پس از بازبینی: بله (تک-عامل) / بله (ارکستره)
• تست‌های ارائه شده: ۴/۴ (تک-عامل) / ۴/۴ (ارکستره)
• گروه‌های ارزیاب خارجی: ۶/۶ (تک-عامل) / ۶/۶ (ارکستره)
• تداخلات ویرایشی: ۰ (تک-عامل) / ۰ (ارکستره)
• بازکاری ادغام: ۰ (تک-عامل) / ۰ (ارکستره)
• اصلاحات بازبینی داخلی: ۱ (تک-عامل) / ۰ (ارکستره)
• تعامل مرورگر: خیر (تک-عامل) / بله (ارکستره)

کاندید ارکستره‌شده شواهد زنده و برتری در مرورگر ارائه داد که مواردی چون ایجاد، فیلتر کردن، انتقال وضعیت‌ها، بازخوردهای اعتبارسنجی، خطاهای کنسول و نمای موبایل (Viewport) را پوشش می‌داد. در مقابل، تک-عامل توانست یک تداخل در رفتار پیام‌های خطا را در بازبینی نهایی پیدا و اصلاح کند.

با این حال، این نتایج تنها امکان‌پذیری را ثابت می‌کند، نه برتری را. چون اجراها هم‌پوشانی داشتند و محیط، مجموع توکن (Token) — تکه‌های کوچکی از متن که مدل تکه‌تکه می‌خورد — مصرف‌شده توسط کنترل‌کننده و عامل‌ها را تفکیک نکرد، ادعای سریع‌تر، ارزان‌تر یا قابل‌اعتمادتر بودن ارکستراسیون در این مرحله نامعتبر است.

قراردادی برای محدود کردن گسترش

یک هدف بزرگ به معنای اجازه برای ایجاد یک عامل برای هر اسم در پرامپت نیست. باید از یک قرارداد سخت‌گیرانه برای محدود کردن توپولوژی استفاده کرد:

• پیش از تفویض: قرارداد HTTP و داده‌ها را تثبیت کنید؛ استقلال مسیرهای incident/** و web/** را تأیید کنید و مالکیت ارزیاب را نزد کنترل‌کننده نگه دارید.
• بودجه تفویض: حداکثر دو عامل اجراکننده. بک‌اند فقط مالک incident/** و فرانت‌اند فقط مالک web/** باشد.
• محدودیت‌ها: عامل‌ها نباید فایل‌های TASK.md یا تست‌ها، فایل‌های ارزیاب و مسیرهای یکدیگر را تغییر دهند.
• الزامات عامل: هر عامل باید فایل‌های تغییریافته، نتایج بررسی‌های متمرکز، رفتارهای مشاهده شده و هر مورد شکست یا تأییدنشده را بازگرداند.

اولویت کیفیت بر سرعت

به گزارش Codex How To، توسعه‌دهندگان باید پیش از تفسیر نتایج، حقایق خام را ثبت کنند. ابعاد کلیدی برای اندازه‌گیری عبارت‌اند از:

• پذیرش: استفاده از ارزیاب و گیت‌های کیفی یکسان برای هر دو روش.
• پوشش: ثبت رفتارهای اجرا شده، شکست‌های یافت شده و رفتارهای تأییدنشده.
• هزینه کل: مجموع توکن‌های کنترل‌کننده و تمام عامل‌ها، شامل تلاش‌های شکست‌خورده. نباید تله‌متریِ تنها-کنترل‌کننده را جایگزین مجموع توکن‌ها کرد.
• زمان سپری شده: اندازه‌گیری اجراهای متوالی و ایزوله روی سخت‌افزارهای مشابه. اجراهای هم‌پوشان را مقایسه نکنید.
• هماهنگی: ردیابی تعداد عامل‌ها، تأخیر در انتقال داده و بررسی‌های تکراری.
• ادغام: ثبت تداخلات، عدم تطابق قراردادها و رویدادهای بازکاری.
• تلاش انسانی: ردیابی اصلاحات، تکرارها، تأییدیه‌ها و مداخلات دستی.

برای تضمین اعتبار، باید حداقل سه جفت اجرای متوالی را با ترتیب متفاوت اجرا کرد و پیش از بررسی توکن‌ها، میزان پذیرش و کامل بودن شواهد را مقایسه نمود. این تمرکز بر شواهد عینی، مشابه رویکردی است که در مدیریت عامل‌های موازی از طریق شواهد فنی برای جایگزینی قدرت محاسباتی خام با دقت مهندسی پیشنهاد شده است.

چه زمانی ارکستراسیون شکست می‌خورد؟

ارکستراسیون معمولاً زمانی شکست می‌خورد که یک تک-عامل بتواند تمام بستر متنی مرتبط را در پنجره زمینه (Context Window) — میزان متنی که مدل هم‌زمان در ذهن نگه می‌دارد — جای دهد یا وقتی زیر-وظایف به طراحی‌های حل‌نشده وابسته باشند. در موارد زیر تک-عامل یا گردش‌کار متوالی را ترجیح دهید:

• وقتی عامل‌ها بخواهند فایل‌های یکسانی را ویرایش کنند.
• وقتی وظیفه اساساً یک زنجیره عیب‌یابی واحد است.
• وقتی ارزیاب نتواند شکست‌ها را به یک کاندید خاص نسبت دهد.
• وقتی هزینه هر عامل نامشخص است و هزینه، معیار اصلی تصمیم‌گیری است.
• وقتی تنها دلیل استفاده، در دسترس بودن موازی‌سازی است.

اندازه‌گیری‌های قبلی نشان داد که در یک نقص کوچک بک‌اند، یک کنترل بدون مهارت (no-skill control) ارزان‌ترین گزینه موفق بود، در حالی که در یک بازی مرورگر متوسط، یک حلقه مهندسی متمرکز کمترین هزینه را داشت. این چالش‌ها یادآور تجربیات Supabase در توقف حلقه‌های تکرار است که ثبات عامل‌های کدنویس را به اولویت تبدیل کرد.

نقاط قوت ارکستراسیون

ساختارهای چندعاملی در سناریوهای خاصی هزینه خود را توجیه می‌کنند:

• ماژول‌های مستقل با رابط‌های تثبیت‌شده.
• بازبینی‌های «فقط-خواندنی» از دریچه مستقل امنیت، قابلیت اطمینان و تست.
• بررسی‌های پرنویز که باید پیش از اجرا خلاصه شوند.
• پیاده‌سازی هم‌زمان فرانت‌اند و بک‌اند پس از تثبیت قرارداد API.
• وظایفی که در آن یک متخصص می‌تواند شواهد زمان-اجرای قابل تأیید اضافه کند.

در این موارد، مزیت اصلی «پوشش» است — یعنی شکار یک نقص واقعی یا تولید شواهد امنیتی مفقود — نه لزوماً سرعت خام. این یک تصمیم کیفی است، نه ادعایی برای کاهش توکن.

تکرار یا ابطال

برای عبور از اسکرین‌شات‌های موفقیت، این پروژه تشویق به استفاده از جفت‌های کنترل‌شده می‌کند: نسخه‌های یکسان و یک‌بارمصرف ایجاد کنید، مدل و تلاش استدلالی را ثابت نگه دارید و یک کاندید تک-عامل و یک کاندید ارکستراسیون محدود را به‌صورت متوالی اجرا کنید. نتایج منفی و خنثی صراحتاً برای جامعه توسعه‌دهندگان مفید هستند.

گام بعدی شما

• در پروژه‌های بعدی، پیش از تقسیم وظایف بین عامل‌ها، یک «قرارداد رابط» (Interface Contract) مکتوب بنویسید و آن را تثبیت کنید.
• برای ارزیابی، یک بار وظیفه را به تک-عامل و یک بار به ساختار چندعاملی بسپارید و مجموع توکن‌های مصرفی را مقایسه کنید.
• اگر عامل‌های شما مدام در حال ویرایش فایل‌های مشترک هستند، فوراً به مدل تک-عامل بازگردید.

اما تأثیر این رویکرد بر مدل‌های استدلالی جدیدتر حتی پیچیده‌تر است — به تحلیل ما درباره مدل‌های Reasoning مراجعه کنید.