لایهٔ استدلال عامل‌محور در CI/CD؛ فراتر از تست‌های صفر و یک

تصور کنید یک دستور حذف دیتابیس در یک Pull Request مخفی شده باشد که تمام تست‌های خودکار را می‌گذرد اما در لحظه استقرار، کل داده‌های مشتریان را پاک می‌کند. اگر امروز از خطوط لوله CI/CD سنتی استفاده می‌کنید، احتمالاً می‌دانید که این ابزارها در تشخیص «زمینه» (Context) ناتوان‌اند و فقط دستورات را اجرا می‌کنند. خطوط لوله سنتی در خودکارسازی عالی هستند اما در استدلال زمینه‌ای دچار مشکل می‌شوند.

به گزارش وب‌سایت dev.to در ۲۳ ژوئیه ۲۰۲۶، یک پیشنهاد معماری جامع منتشر شد که هدف آن پر کردن این شکاف از طریق پیاده‌سازی لایه‌های اعتبارسنجی عامل‌محور (Agentic) است. این لایه‌ها جایگزین ابزارهای قطعی نمی‌شوند، بلکه به عنوان یک موتور استدلالی حالت‌دار عمل می‌کنند تا تصمیم بگیرند آیا یک تغییر واقعاً باید به محیط تولید (Production) منتقل شود یا خیر.

خطوط لوله مدرن در کامپایل کد، اجرای تست‌ها، ساخت آرتیفکت‌ها، اسکن وابستگی‌ها، استقرار زیرساخت و ارتقای نسخه‌ها فوق‌العاده عمل می‌کنند. اما تفاوت حیاتی میان «خودکارسازی استقرار» و «استدلال درباره لزوم استقرار» وجود دارد. برای مثال، یک Pull Request را در نظر بگیرید که حاوی دستور DROP TABLE customer_transactions; یا DELETE FROM orders; باشد. یا تغییراتی در اپلیکیشن که به طور تصادفی میان‌افزار احراز هویت (Authorization Middleware) را حذف می‌کند، یک عملیات دیتابیسی ناامن معرفی می‌کند، یک راز (Secret) را لو می‌دهد، مرز امنیتی زیرساخت را تغییر می‌دهد، کنوانسیون‌های معماری را دور می‌زند، یک مهاجرت اسکیمای شکست‌دهنده (Breaking Schema Migration) را مستقر می‌کند یا منابع تولید را خارج از محدوده مورد انتظار تغییر می‌دهد.

اکثر خطوط لوله مدرن مسیری خطی را دنبال می‌کنند: توسعه‌دهنده $\downarrow$ درخواست Pull $\downarrow$ بررسی Lint $\downarrow$ تست‌های واحد $\downarrow$ اسکن SAST و وابستگی $\downarrow$ ساخت (Build) $\downarrow$ استقرار تست $\downarrow$ استقرار تولید. در حالی که این ابزارها الگوهای شناخته شده را شناسایی می‌کنند، اما فاقد دید سیستمی هستند. برای مثال، یک Linter برای SQL می‌داند که آیا یک دستور از نظر نحوی درست است یا خیر، اما نمی‌تواند تشخیص دهد که یک دستور DELETE بدون بند WHERE یک اشتباه فاجعه‌بار است یا پاک‌سازی عمدی یک جدول موقت. CI/CD سنتی می‌تواند مشکلات را در صورت وجود قوانین صریح شناسایی کند، اما با ریسک‌های زمینه‌ای دست و پنجه نرم می‌کند: آیا یک دستور DROP بخشی از یک مهاجرت تأیید شده است؟ آیا یک دستور DELETE دارای یک谓یکت (Predicate) مناسب است؟ آیا سرویس تغییر یافته هنوز محدودیت‌های معماری سیستم را برآورده می‌کند؟ آیا تغییر در پیکربندی، سطح حمله (Attack Surface) را گسترش می‌دهد؟ آیا یک مهاجرت، سازگاری با اپلیکیشن‌های در حال اجرا در محیط تولید را حفظ می‌کند؟

این معماری پیشنهادی یک مدل ترکیبی را معرفی می‌کند: کنترل‌های قطعی + استدلال زمینه‌ای عامل‌محور + حاکمیت انسانی. قانون اصلی این است که هرگز اجازه ندهیم یک LLM جایگزین یک ابزار قطعی شود. برای نمونه، اعتبارسنجی سینتکس SQL باید از طریق یک پارسر یا لینتر SQL مانند SQLFluff انجام شود که پارسینگی آگاه از دیالکت‌ها دارد و با SQLهای تمپلیت شده کار می‌کند. امنیت کد منبع باید همچنان با ابزارهایی مانند CodeQL، Semgrep، اسکنرهای وابستگی، اسکنرهای رازها و چارچوب‌های تست بومی زبان بررسی شود.

ادغام این روش‌ها با چارچوب توسعه نرم‌افزار امن NIST (SSDF SP 800-218) هم‌راستا است که توصیه می‌کند امنیت در سراسر چرخه حیات ادغام شود، نه اینکه به عنوان یک فعالیت مرحله نهایی تلقی گردد. این رویکرد یادآور تغییرات بنیادی در مدیریت آسیب‌پذیری‌هاست، مشابه آنچه در بهینه‌سازی چرخه امنیتی پلتفرم LibX برای تبدیل اسکن‌های دوره‌ای به فرآیندهای مداوم مشاهده شد، تا ریسک‌ها پیش از رسیدن به تولید شناسایی شوند. به همین ترتیب، OWASP تأکید می‌کند که زیرساخت CI/CD حساس به امنیت است زیرا خطوط لوله دسترسی به کد منبع، اعتبارنامه‌ها، آرتیفکت‌ها و محیط‌های استقرار دارند. به جای پرسش ساده‌ی «آیا این SQL معتبر است؟»، این معماری از جریانی به شکل زیر استفاده می‌کند: پارسر SQL $\downarrow$ لینتر SQL $\downarrow$ قوانین پالیسی $\downarrow$ تحلیل ریسک عامل‌محور. در این مدل، عامل (Agent) شواهدی را که توسط سه مرحله اول تولید شده است، در بستر گسترده‌تر استقرار تفسیر می‌کند.

چارچوب بازرسی عامل‌محور

این سیستم مسئولیت‌ها را بین چهار نقش تخصصی تقسیم می‌کند تا تحلیل متمرکز تضمین شود:

• عامل دروازه‌بان (Gatekeeper Agent): کاهش محدوده (Scope Reduction) را انجام می‌دهد. این عامل تعیین می‌کند چه چیزی تغییر کرده و کدام مسیر بازرسی مورد نیاز است تا برای هر کامیت، کل مخزن را کورکورانه تحلیل نکند. نمونه‌ها عبارتند از:
  • تغییر در پایتون $\rightarrow$ اعتبارسنجی پایتون + بازرسی امنیتی
  • تغییر در SQL $\rightarrow$ پارسر SQL + بازرسی پالیسی SQL
  • تغییر در Terraform $\rightarrow$ بازرسی امنیتی IaC
  • تغییر در Dockerfile $\rightarrow$ بازرسی امنیتی کانتینر
• عامل اعتبارسنجی (Validation Agent): ابزارهای مستقر را هماهنگ کرده و نتایج را نرمال می‌کند. این عامل اعتبارسنجی را اختراع نمی‌کند بلکه ابزارهای شناخته شده را سازماندهی می‌کند. برای پایتون، ممکن است ruff check .، pytest و mypy . را اجرا کند. برای SQL از sqlfluff lint migrations/ استفاده می‌کند. برای زیرساخت، terraform validate و برای کانتینرها docker build . را اجرا می‌کند. خروجی آن یک شیء ساختاریافته است (مانند {"syntax": "PASS", "tests": "PASS", "lint": "PASS", "violations": []}) تا به عنوان شواهدی برای عوامل بعدی عمل کند.
• عامل بازرسی امنیتی (Security Inspection Agent): یافته‌های حاصل از CodeQL، Semgrep، اسکنرهای راز، اسکنرهای وابستگی، اسکنرهای IaC و موتورهای پالیسی SQL را ارزیابی می‌کند. این عامل تفاوت بین «تشخیص یک یافته توسط اسکنر» و «استدلال درباره اهمیت عملیاتی آن در استقرار» را می‌فهمد. این عامل نتایج اسکنرها (مثلاً {"critical": 0, "high": 1, "medium": 3, "secrets_detected": False}) را به ارزیابی‌های ریسک زمینه‌ای تبدیل می‌کند.
• عامل بازبینی (Review Agent): یکپارچگی معماری را بررسی می‌کند. این عامل می‌پرسد آیا تغییر از نظر معماری منطقی است، حتی اگر از نظر فنی معتبر باشد. برای مثال، اگر توسعه‌دهنده‌ای جریان را از API $\downarrow$ Service Layer $\downarrow$ Repository $\downarrow$ Database به API $\downarrow$ Direct Database Query تغییر دهد، عامل بازبینی این مورد را به عنوان تخلف از معماری مستقر شناسایی می‌کند. این عامل Diff کد را با منابعی مانند architecture/principles.md، service-boundaries.yaml، database-policy.yaml و security-policy.yaml مقایسه می‌کند تا هشدارهایی تولید کند (مثلاً Rule ARCH-DB-004: "لایه API مستقیماً به لایه Persistence دسترسی دارد»، با اطمینان ۰.۹۴).

ایمنی ساختاری SQL

این چارچوب تأکید می‌کند که مسدود کردن کلمات کلیدی (مانند جست‌وجو برای "DROP") بسیار شکننده است. پیچیدگی SQL — شامل کامنت‌ها، نام‌های مستعار (Aliases)، دستورات تو در تو، رویه‌های ذخیره شده (Stored Procedures)، تفاوت‌های دیالکت، تمپلایتینگ، SQL پویا و شناسه‌های کوت شده — باعث می‌شود امنیت مبتنی بر Regex غیرقابل اعتماد باشد.

در عوض، این مدل طرفدار پارس کردن SQL به یک درخت نحو انتزاعی (AST) است. جریان به این صورت است: SQL $\downarrow$ Lexer $\downarrow$ Parser $\downarrow$ AST $\downarrow$ Policy Engine $\downarrow$ Risk Evaluation. در یک AST، یک دستور DELETE به صورت یک هدف (مثلاً customer_orders) و یک بند where ساختار می‌یابد. اگر statement.type == "DELETE" باشد و statement.where مقدار null داشته باشد، موتور پالیسی می‌تواند ریسک را «بحرانی» (CRITICAL) علامت بزند.

عملیات‌های خاصی برای بازرسی اجباری پالیسی پرچم‌گذاری می‌شوند:

• DROP TABLE / DROP SCHEMA / TRUNCATE TABLE
• DELETE یا UPDATE بدون بند WHERE
• ALTER TABLE DROP COLUMN
• GRANT / REVOKE / CREATE OR REPLACE

به طور حیاتی، عامل درباره محیط استدلال می‌کند. دستور DROP TABLE temp_integration_test; در یک محیط موقت و ایزوله ممکن است پذیرفتنی باشد، در حالی که همان دستور در محیط تولید فاجعه‌بار است. تصمیم بر اساس این موارد گرفته می‌شود: دستور + محیط + طبقه‌بندی شیء + بستر مهاجرت + دسترسی‌ها + وابستگی‌ها + پالیسی.

ارکستراسیون با LangGraph، MCP و A2A

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

۱. LangGraph: برای ارکستراسیون حالت‌دار (Stateful) استفاده می‌شود. گیت‌های استقرار در اینجا گردش‌کار (Workflow) هستند، نه تک‌پرامپت‌ها. LangGraph از StateGraph برای مدل‌سازی گره‌ها و یال‌های شرطی استفاده می‌کند. یک PipelineState مفهومی موارد زیر را دنبال می‌کند: changed_files، validation_results، security_results، sql_results، architecture_results، risk_score و در نهایت decision. گره‌ها شامل detect_changes، validate، inspect_security، inspect_sql، review_architecture، calculate_risk و deployment_gate هستند. این امر امکان مسیریابی پویا از طریق تابع route_change را فراهم می‌کند؛ مثلاً اگر فقط مستندات تغییر کرده باشند، فرآیند به یک «بازبینی سبک» (lightweight_review) هدایت شده و از اعتبارسنجی SQL یا پایتون عبور می‌کند.

۲. پروتکل زمینهٔ مدل (MCP): استانداردی است که نحوه دسترسی عامل‌ها به ابزارها را از طریق یک معماری کلاینت-سرور که ابزارها، منابع و پرامپت‌ها را اکسپوز می‌کند، یکسان می‌سازد. یک معماری استقرار مفهومی از یک کلاینت MCP متصل به سرورهای اختصاصی استفاده می‌کند:
* Repository MCP: دسترسی به git diffها و متادیتاها.
* SQL MCP: ابزارهایی مانند parse_sql و inspect_schema؛ منابعی مانند schema://production و migrations://history.
* Security MCP: ادغام با اسکنرها و دیتابیس‌های آسیب‌پذیری.
* Policy MCP: دسترسی به مجموعه‌قوانین سازمانی.
این ساختار، استدلال را از دسترسی سیستمی جدا می‌کند. با این حال، MCP ابزارها را به طور خودکار ایمن نمی‌کند. یک سرور تولید باید احراز هویت، مجوزدهی، کمترین امتیاز، اعتبارسنجی ورودی، لاگ حسابرسی، محدودسازی نرخ (Rate Limiting)، مرزهای محیطی و جداسازی اعتبارنامه‌ها را اعمال کند.

۳. Agent2Agent (A2A): در حالی که MCP عامل‌ها را به ابزارها متصل می‌کند، A2A تعامل بین سیستم‌های عاملی مستقل را ممکن می‌سازد. این زمانی مفید است که مسئولیت‌های اعتبارسنجی در سرویس‌های مستقل مستقر شده‌اند که ممکن است نسخه‌بندی شوند، مقیاس‌بندی شوند یا توسط تیم‌های مختلف با چارچوب‌های عاملی متفاوت مدیریت شوند.

گیت‌های استقرار مبتنی بر ریسک

تصمیم نهایی هرگز صرفاً بر عهده LLM نیست. سیستم تحلیل‌های عاملی را به یک امتیاز ریسک (۰ تا ۱۰۰) تبدیل می‌کند. بر اساس راهنمای dev.to، سیگنال‌ها وزن‌دهی می‌شوند:

• شناسایی آسیب‌پذیری بحرانی یا راز (Secret): +۵۰
• DROP/TRUNCATE یا DELETE بدون WHERE: +۴۰
• تغییر شکست‌دهنده در اسکیما: +۳۰
• تخلف معماری: +۲۰
• تست‌های ناکافی: +۱۵
• تأثیر زیاد بر وابستگی‌ها: +۱۵

طبقه‌بندی ریسک:

• ۰–۲۰ (کم): ادامه خودکار.
• ۲۱–۵۰ (متوسط): ادامه با هشدار.
• ۵۱–۷۵ (بالا): تأیید اجباری بازبین انسانی.
• ۷۶–۱۰۰ (بحرانی): مسدود شدن استقرار.

عملیات‌های بحرانی مانند حذف یک جدول تولید، تغییرات عمده در IAM، مهاجرت‌های تخریبی، تخلفات معماری با اطمینان بالا یا تغییرات شبکه تولید، یک وقفه «انسان در حلقه» (Human-in-the-Loop) را فعال می‌کنند. این قابلیت از تداوم (Persistence) در LangGraph استفاده می‌کند تا گردش‌کار را متوقف کند تا زمانی که یک انسان تأیید یا رد صریح ارائه دهد.

حفاظ‌های محیط تولید

برای استقرار سازمانی، کنترل‌های زیر غیرقابل مذاکره هستند:

• حداقل امتیاز (Least Privilege): عامل‌ها حداقل مجوزهای مورد نیاز را دریافت می‌کنند. بازرسی تولید باید فقط خواندنی (Read-only) باشد؛ یک عامل SQL نباید اعتبارنامه‌هایی داشته باشد که قادر به اجرای DROP DATABASE production; باشند.
• برتری قطعیت (Deterministic Primacy): کدهای SQL تولید شده توسط LLM هرگز نباید به‌طور خودکار اجرا شوند. یافته‌های اسکنرها معتبر می‌مانند و نمی‌توانند به‌طور بی‌صدا توسط LLM نادیده گرفته شوند. عملیات‌های بحرانی نیازمند گیت‌های پالیسی قطعی هستند.
• قابلیت حسابرسی (Auditability): هر تصمیم باید با شواهد و شناسه‌های پالیسی ثبت شود. نتایج باید ساختارمند باشند؛ برای مثال، ارائه فایل، خط، نوع UNBOUNDED_DELETE و یک اقدام مورد نیاز مانند «افزودن谓یکت یا دریافت تأییدیه عملیات تخریبی» به جای زبان طبیعی ساده.
• اعتبارسنجی ورودی: تزریق پرامپت (Prompt Injection) باید کاهش یابد زیرا توصیفات PR، کامنت‌ها و فایل‌های مخزن حاوی متن‌های غیرقابل اعتماد هستند. خروجی ابزارها باید قبل از ورود به گردش‌های کاری پایین‌دستی اعتبارسنجی شوند.
• زیرساخت: ابزارهای MCP باید از قابلیت‌های محدود (Narrowly Scoped) به جای دسترسی کلی به Shell استفاده کنند و اعتبارنامه‌ها باید کوتاه‌مدت و محدود به محیط باشند.

این تغییر رویکرد، پرسش CI/CD را از «آیا این نرم‌افزار قابل ساخت است؟» به «با توجه به پالیسی سازمانی، معماری، محیط و شعاع انفجار (Blast Radius)، آیا این تغییر باید پیش برود؟» تبدیل می‌کند. این مدل با AI نه به عنوان یک اسکنر همه‌کاره، بلکه به عنوان یک تجمیع‌کننده شواهد پیچیده و سیستم پشتیبانی تصمیم را می‌بیند. جریان نهایی از «خودکارسازی $\rightarrow$ شواهد $\rightarrow$ استدلال $\rightarrow$ پالیسی $\rightarrow$ حاکمیت $\rightarrow$ استقرار» می‌گذرد.

مرزهای قطعی در مقابل عاملی

برای حفظ ایمنی، یک تقسیم کار واضح باید رعایت شود. یک قانون کلی برای انتخاب مکانیسم به شرح زیر است:

• سینتکس/فرمت‌بندی: استفاده از پارسرها، کامپایلرها و لینترها.
• رفتار واحد (Unit): استفاده از چارچوب‌های تست.
• آسیب‌پذیری‌های شناخته شده: استفاده از ابزارهای SAST/SCA.
• رازها: استفاده از اسکنرهای راز.
• ساختار SQL: استفاده از پارسرهای SQL.
• ناورداهای پالیسی (Policy Invariants): استفاده از موتورهای پالیسی.
• تأثیر زمینه‌ای: استفاده از استدلال عامل + پالیسی.
• بررسی‌های بین-سیستمی: استفاده از عامل‌ها.
• تأیید نهایی بحرانی: استفاده از گیت‌های انسانی/پالیسی.

این جداسازی ضروری است. سیستم‌های عاملی زمانی قابل اعتمادتر می‌شوند که توسط مرزهای قطعی احاطه شده باشند.