معماری محدودشده در برابر کنترل کامل برای پایداری عامل‌های هوش مصنوعی

تصور کنید یک عامل هوش مصنوعی با دسترسی نامحدود به کنسول تولید، یک تست ساده‌ی ایمیل را به کابوسی غیرقابل‌تکرار تبدیل کند. وقتی مدل به‌صورت لحظه‌ای تصمیم می‌گیرد از کدام صندوق پستی استفاده کند یا چطور یک ثبت‌نام را تحریک کند، ممکن است یک بار تست پاس شود و بار بعد به دلایلی کاملاً متفاوت شکست بخورد. به نقل از راهنمای فنی منتشرشده در ۳ اکتبر ۲۰۲۶ در وب‌سایت dev.to، تنها راه تضمین قابلیت اطمینان این است که با عامل (Agent) — شبیه به یک مشاور که فقط پیشنهاد می‌دهد و اجازه ندارد خودش دکمه‌ها را فشار دهد — نه به‌عنوان یک پیش‌گو یا تصمیم‌گیرنده مستقل، بلکه به‌عنوان بخشی از یک سیستم با مرزهای سخت‌گیرانه برخورد شود.

این چالش درست زمانی رخ می‌دهد که توسعه‌دهندگان از اتوماسیون‌های ساده‌ی مبتنی بر پرامپت به سمت گردش‌کارهای عامل‌محور (Agentic) حرکت می‌کنند. در حالی که ما پیش‌تر بررسی کردیم که چگونه مدل Aleph Alpha Kolibri مصرف توکن را تا ۱۵٪ کاهش داد تا کارایی را بهینه کند، گلوگاه فعلی در استقرار عامل‌ها دیگر فقط هزینه نیست، بلکه قابلیت ردیابی (Traceability) است. در یک جریان ثبت‌نام معمولی، سیستم از چندین وضعیت مجزا عبور می‌کند: ارسال فرم، درخواست پیام، دریافت، مصرف لینک و فعال‌سازی کاربر. اگر یک عامل صرفاً بگوید لاگ‌ها «درست به نظر می‌رسند»، او در حال ارائه یک نظر زبانی است، نه گزارش وضعیت سیستم. این مشکل دقیقاً همان جایی است که جایگزینی داده‌های مبهم با رسیدهای دقیق در معماری ثبت لاگ برای پر کردن شکاف‌های عیب‌یابی ابزارهای LLM ضروری می‌شود.

زمینه و جریان سیستم

برای فرار از تله‌ی «پیش‌گو»، طراحی اولیه باید خطی و محدود باشد. جریان پیشنهادی به این ترتیب است: CI $\rightarrow$ API ثبت‌نام $\rightarrow$ صندوق پستی تست $\rightarrow$ استخراج‌کننده لینک $\rightarrow$ رویدادها و رسیدها $\rightarrow$ عامل هوش مصنوعی.

در این مدل، عامل بستر اجرا را دریافت می‌کند اما دسترسی نامحدود به کنسول تولید یا پایگاه‌داده ندارد. نقش او به پاسخ دادن به سؤالات محدود شده است: کدام انتقال رخ نداد؟ چه مدرکی کم است؟ کدام بررسی ایمن را می‌توان تکرار کرد؟

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

قرارداد ابزار محدودشده

توسعه‌دهندگان به‌جای ارائه توابع کلی مثل run_any_sql باید عملیات مشخص و شمارش‌شده‌ای را تعریف کنند. برای مثال، ابزاری به نام get_verification_attempt باید یک run_id (مثلاً "ci-1842") و یک user_id (مثلاً "u-92") بگیرد و یک شیء ساختاریافته برگرداند. این شیء باید شامل وضعیت (مثلاً message_received)، یک شناسه پیام (مثلاً "m-771") و یک برچسب زمانی دقیق (مثلاً "2026-10-03T14:00:12Z") باشد.

نکته حیاتی این است که این ابزارها باید وضعیت‌های شکست صریح مانند not_found (یافت نشد)، expired (منقضی شد)، rate_limited (محدودیت نرخ) یا invalid_run (اجرای نامعتبر) را اعلام کنند. بدون این‌ها، مدل‌های زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن جواب می‌دهد — تمایل دارند شکاف‌های اطلاعاتی را با زبان طبیعی پر کنند. این رفتار برای یک چت‌بات جذاب است اما برای یک خط لوله CI/CD که باید در صورت نبود پیام شکست بخورد، مرگبار است.

جزئیات پیاده‌سازی

طبق مستندات فنی، برای حفظ یکپارچگی سیستم باید مکانیسم‌های زیر در تعامل با ابزارها اعمال شوند:

• الزام اقدامات تغییردهنده (Mutant Action Requirements): هر عملیاتی که وضعیت سیستم را تغییر می‌دهد باید یک run_id منحصربه‌فرد، یک دلیل مشخص برای تغییر و یک کلید Idempotency (برای جلوگیری از اجرای تکراری و ناخواسته) داشته باشد.
• منطق اعتبارسنجی: ابزار باید قبل از اجرای هر دستور تصمیم بگیرد که آیا آن عملیات معتبر است یا خیر. برای مثال، خواندن یک پیام ایمن است، اما ارسال مجدد یک پیام یا علامت‌گذاری یک توکن به‌عنوان «مصرف‌شده» عملیاتی حساس است و نباید بدون کنترل باشد.
• جداسازی لایه انتقال: لایه انتقال (Transport Layer) باید از رابط خواندن پیام جدا شود. این جداسازی به تیم‌ها اجازه می‌دهد تا بازتلاش‌های (Retries) تمیز و استانداردی را برای ایمیل‌های ثبت‌نام اعمال کنند، بدون اینکه عامل هوش مصنوعی بتواند تنظیمات سرویس را تغییر دهد.
• سیاست‌های انقضا: داده‌های تست قدیمی (Fixtures) باید از طریق یک تسک با محدودیت زمانی مشخص پاک شوند تا از آلوده شدن تشخیص‌های سیستم توسط داده‌های قدیمی جلوگیری شود.

معماری مشاهده‌پذیر چهارلایه

برای تست ایمیل استوار، سیستم باید به چهار لایه مجزا تقسیم شود:

• Fixture: ایجاد یک آدرس ایمیل ایزوله که به یک اجرای خاص متصل است.
• Application: درخواست ارسال و پردازش ایمیل تأیید.
• Collector: جمع‌آوری پیام‌ها، برچسب‌های زمانی و کدهای پاسخ.
• Agent: توضیح علت شکست و پیشنهاد یک بررسی مجاز.

با ذخیره یک «رسید» از هر تلاش — شامل زمان درخواست (requested_at)، زمان تحویل (delivered_at)، زمان مصرف (consumed_at) و یک شناسه همبستگی (correlation_id) — مدل می‌تواند تشخیص دهد که آیا یک ایمیل دیر رسیده است یا اینکه واقعاً هرگز ارسال نشده است. این رویکرد به عنوان راهکاری برای پایان دادن به جعبه‌سیاه بودن عامل‌های هوش مصنوعی عمل کرده و مانع از آن می‌شود که عامل صرفاً چون متن ایمیل «خوب به نظر می‌رسد»، یک خطای سیستمی یا شکست در Assertion را نادیده بگیرد.

رویکرد Runner در CI

یک Runner ساده و «خسته‌کننده» برای CI را می‌توان به این شکل پیاده کرد:

def verify_signup(run_id, email_client, app_client):
    address = email_client.create_fixture(run_id)
    attempt = app_client.request_verification(address)
    message = email_client.wait_for_message(
        address, timeout_seconds=60, correlation_id=attempt.correlation_id,
    )
    assert message is not None, "verification email was not delivered"
    result = app_client.consume_link(message.verification_url)
    assert result.status == "activated"
    return {
        "run_id": run_id, "message_id": message.id, "final_status": result.status,
    }

هوش مصنوعی بعد از این مرحله وارد می‌شود و با استفاده از رسید تولید شده، شکست را طبقه‌بندی می‌کند. مدل می‌تواند بدون به خطر انداختن یکپارچگی محیط تست، بین خطای delivery_timeout (زمان انتظار تحویل)، wrong_template (قالب اشتباه) یا replay_rejected (رد شدن تکرار) تمایز قائل شود.

این تغییر در رویکرد، فرض بنیادی اتوماسیون با هوش مصنوعی را عوض می‌کند: LLM تفسیر را ارائه می‌دهد، نه مرجعیت را. برای مهندسان، این یعنی پنل تشخیص نهایی باید وضعیت سیستم، سن Fixture و آخرین رویداد رخ داده را اولویت دهد، نه یک پاراگراف طولانی تولید شده توسط AI. خلاصه AI باید به‌عنوان بستر اضافی (Context) عمل کند، نه به‌عنوان مدرک اصلی برای موفقیت یا شکست یک تست.

قبل از متصل کردن هر عاملی به یک خط لوله (Pipeline)، باید شرایط زیر را تأیید کنید:

• هر اجرا دارای یک صندوق پستی منحصربه‌فرد و یک run_id باشد.
• ابزارها وضعیت‌های شمارش‌شده (Enumerated) و برچسب‌های زمانی برگردانند.
• اقدامات تغییردهنده (Mutant Actions) دارای خاصیت Idempotency باشند یا نیاز به تأیید داشته باشند.
• لاگ‌ها شامل توکن‌های کامل و داده‌های غیرضروری نباشند.
• شکست‌های عامل منجر به وضعیت «شکست» در تست شود، نه یک نتیجه سبز (Pass) کاذب.
• فرآیند پاک‌سازی (Cleanup) دارای محدودیت زمانی و یک مالک مشخص باشد.
• واژگان استاندارد شده باشند: کلمات «fixture»، «address»، «message» و «token» به‌عنوان اصطلاحات متمایز در نظر گرفته شوند، نه به‌عنوان «ایمیل‌های دامی» مبهم.

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

گام بعدی شما

• بررسی کنید که آیا هر اجرای تست شما یک صندوق پستی منحصربه‌فرد و run_id دارد یا خیر.
• ابزارهای متصل به عامل را بازبینی کنید تا به‌جای متن آزاد، وضعیت‌های شمارش‌شده (Enumerated States) برگردانند.
• اطمینان حاصل کنید که شکست عامل منجر به وضعیت «شکست» در تست شود، نه یک نتیجه سبز کاذب.

اما مدیریت این ابزارها در مقیاس بزرگ، چالش‌های جدیدی در پروتکل‌های ارتباطی ایجاد می‌کند — به تحلیل ما درباره‌ی پروتکل MCP مراجعه کنید.