مهندسی سیستم‌های ایجنتیک مدرن: گذار از Prompt نویسی به معماری مهارت‌محور (Agent Skills) و استانداردهای مهندسی پیشرفته

مقدمه: چرا دوران «پرامپت‌نویسی ساده» به پایان رسیده است؟

در نسل اول سیستم‌های مبتنی بر مدل‌های زبانی بزرگ (LLM)، بیشتر تعاملات و حتی ابزارهای خودکارسازی بر پایه پرامپت‌های طولانی، توضیحات متنی مبهم و آزمون و خطای انسانی شکل می‌گرفت. اما با ورود به عصر ایجنت‌های خودگردان (Autonomous Coding & Systems Agents) مانند Antigravity، Codex، Claude Code و معماری‌های پیچیده چندایجنتیک نظیر Molavi Agentic OS و Hamzad Core، مهندسی سیستم‌ها نیازمند دگرگونی بنیادین شد.

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

این مقاله، تحلیل عمیق و حاصل تجربه پیاده‌سازی استانداردهای مهندسی پیشرفته در اکوسیستم Molavi با الهام و ارزیابی تطبیقی پروژه addyosmani/agent-skills است.

۱. تفاوت «Prompt Engineering» با «Agent Skills Engineering»

۲. چهار ستون مهندسی ایجنتیک در اکوسیستم Molavi

در ارتقای جامع اکوسیستم Molavi، چهار ستون کلیدی مهندسی به هسته عملیاتی اضافه شدند:

graph TD
    A[نیاز یا تسک جدید] --> B[Spec-Driven Gate<br/>نقشه قابلیت‌ها و Non-Goals]
    B --> C[Constraint-Driven Check<br/>تعیین مرزهای سیستم و لایسنس]
    C --> D[TDD & Implementation<br/>پیاده‌سازی با تست‌های محلی و Mock]
    D --> E[Doubt-Driven Adversarial Review<br/>پرسوناهای ۴ گانه بازبین مستقل]
    E --> F[Foreman Physical Verification<br/>سنجش شواهد فیزیکی خروجی تست]
    F --> G[ثبت در ADR و حافظه پایدار Second Brain]

۱. توسعه مشخصات‌محور (Spec-Driven Development)

هیچ کدی بدون مشخصات فنی (Spec) نوشته نمی‌شود. این مشخصات شامل:

• Capability Map: تجزیه نیاز به واحدهای مستقل و آزمون‌پذیر.
• Explicit Non-Goals: تعریف مرزهای صریح درباره آنچه نباید تغییر کند یا ساخته شود.
• Acceptance Criteria: سناریوهای دقیق و معیارهای پذیرش قبل از دست بردن به فایل‌ها.

۲. نقد شک‌محور فرضیات (Doubt-Driven Development)

یکی از خطرناک‌ترین پدیده‌ها در سشن‌های طولانی ایجنت‌ها، تبدیل فرضیات اثبات‌نشده به حقایق مسلم است. متدولوژی Doubt-Driven ایجنت را موظف می‌کند که برای هر تصمیم غیربدیهی (تغییر ماشین وضعیت، منطق احراز هویت، شِمای داده یا انتخاب‌های معماری برگشت‌ناپذیر)، یک پرسونای مستقل با کانتکست تازه و با سوگیری «اثبات نادرستی (Disprove)» وارد مدار شود.

۳. چهار پرسونای بازبین مستقل (4 Independent Review Personas)

به‌جای یک مدل همه‌کاره، ۴ نقش تخصصی مستقل وارد ارکستراسیون شده‌اند:

1. Principal Code Reviewer: ممیزی تمیزی کد، اصول SOLID، خوانایی و عدم پیچیدگی بی‌مورد.
2. Security & Threat Auditor: پایش تهدیدات OWASP، نشت توکن‌ها، امنیت سکرت‌ها و اعتبارسنجی ورودی.
3. Staff Quality & Test Engineer: تضمین تست‌های TDD، پوشش سناریوهای مرزی و جلوگیری از رگرسیون.
4. Web Performance & Efficiency Auditor: پایش شاخص‌های حیاتی وب (LCP, INP, CLS) و جلوگیری از هدررفت توکن‌ها.

۴. قوانین ضدتوجیه و شواهد فیزیکی (Anti-Rationalization & Verification)

قاعده طلایی همزاد و اکوسیستم ملوی:

«حدس زدن ممنوع است؛ یا شواهد فیزیکی و تست محلی موفق وجود دارد، یا کار تمام نشده است.»

۳. نقش حافظه پایدار (TM Second Brain) و دفتر رد تصمیمات

در معماری‌های ایجنتیک معمولی، تجربه اشتباهات در یک سشن با بستن محیط توسعه محو می‌شود و ایجنت در روز بعد مجدداً همان اشتباه را تکرار می‌کند. در اکوسیستم ما، TM Second Brain به ماژول DecisionLedger مجهز شده است:

• ثبت تصمیمات رد شده (Rejected Decision Ledger): هنگامی که یک تصمیم به دلیل ضعف امنیتی یا افت بنچمارک رد می‌شود، دلیل مستند و شواهد شکست آن در حافظه پایدار ذخیره می‌گردد تا هیچ ایجنت دیگری در آینده وقت سیستم را برای راه‌حل‌های مردود تلف نکند.

۴. نتایج تجربی و جمع‌بندی

با اجرای این استانداردها:

1. نرخ رگرسیون کد در تغییرات پیچیده ایجنت‌ها به نزدیک صفر کاهش یافته است.
2. استقلال عملیاتی ایجنت‌ها بدون نیاز به توقف‌های بیهوده برای پرسش‌های متفرقه از کاربر افزایش یافته است.
3. تطابق با استانداردهای مهندسی Staff-Level در پروژه‌های متن‌باز تثبیت شده است.

این دستاوردها نشان می‌دهد که آینده نرم‌افزار، صرفاً بزرگ‌تر شدن مدل‌ها نیست؛ بلکه بلوغ استانداردهای مهندسی سیستم‌هایی است که این مدل‌ها را به کار می‌گیرند.