بزرگ‌ترین چالش در واگذاری تسک‌های برنامه‌نویسی به مدلهای زبانی، تمایل ذاتی آن‌ها به اعلام موفقیت زودهنگام است. مدل‌ها diff کدهای خودشان را بررسی می‌کنند، بدون اینکه آزمونی اجرا شده باشد مدعی قبولی تستها می‌شوند، یا تعاریف سست و دلخواهی از معیارهای پذیرش ارائه می‌دهند. در چنین شرایطی، اکتفا به پیام چت ایجنت برای تحویل کار یا ادغام کد، ریسک شکست در محیط‌های واقعی را به‌شدت بالا می‌برد.
گیت اعتبارسنجی (Verification Gate) به عنوان یک لایه‌ی کنترلی قطعی، مستقل از ارزیابی احتمالات مدل کار میکند. این سیستم دست‌سازه‌های باقی‌مانده از مراحل کار—شامل رکوردهای بازخورد، گزارش دامنه، diff کد و قوانین کیفی—را تحلیل کرده و تصمیمی مطلق و بدون ابهام می‌گیرد؛ تصمیمی که مستقیماً در پایپ‌لاین CI وارد شده و از نفوذ باگ‌های پنهان یا تغییرات ناخواسته جلوگیری میکند.
ایجنت حق ندارد کار خودش را تمام‌شده اعلام کند. یک گیت اعتبارسنجی (verification gate) قرارداد دامنه، لاگ بازخورد، گزارش قوانین و diff را می‌خواند و فقط به یک پرسش پاسخ میدهد: آیا این تسک واقعاً تمام شده است؟ اگر پاسخ گیت منفی باشد، چت هر چه می‌خواهد بگوید؛ تسک انجام نشده است.
اهداف یادگیری
- تعریف گیت اعتبارسنجی به‌عنوان یک تابع قطعی بر روی دست‌سازه‌های میز کار.
- ترکیب گزارش قوانین، گزارش دامنه، رکوردهای بازخورد و diff در یک رای نهایی واحد.
- تولید یک فایل
verification_report.jsonکه هم ایجنت بازبین و هم CI بتوانند آن را بخوانند. - خودداری از پیشبرد تسک در صورت بروز هر خطایی با سطح اهمیت مسدودکننده (block-severity)، بدون هیچ استثنایی.
صورت مسئله
ایجنت‌ها خیلی راحت اعلام موفقیت می‌کنند. سه الگوی شکست متداول در این زمینه دیده میشود:
- «خوب به نظر می‌رسد.» مدل diff خودش را خوانده و تصمیم گرفته که درست است.
- «تستها پاس شدند.» با اطمینان کامل بیان میشود، اما هیچ رکوردی از اجرای واقعی تست وجود ندارد.
- «معیارهای پذیرش برآورده شدند.» معیارهای پذیرش آن‌قدر باز و منعطف تفسیر شده‌اند که هر چیزی شبیه به کار انجام‌شده را شامل شوند.
راه‌حل میز کار، یک گیت اعتبارسنجی واحد است که دست‌سازه‌های تولیدشده توسط ایجنت را می‌خواند و تصمیم نهایی را می‌گیرد. این گیت قطعی (deterministic) است، در کنترل نسخه نگهداری میشود و به CI متصل است. ایجنت نمی‌تواند سر آن کلاه بگذارد.
مفاهیم پایه
مواردی که گیت بررسی میکند
| بررسی | دست‌سازه‌ی مبدأ | سطح اهمیت |
|---|---|---|
| همه‌ی دستورهای پذیرش اجرا شده باشند | feedback_record.jsonl |
block |
| کد خروجی همه‌ی دستورهای پذیرش صفر باشد | feedback_record.jsonl |
block |
| بررسی دامنه هیچ نوشتن ممنوعی نداشته باشد | scope_report.json |
block |
| بررسی دامنه هیچ نوشتن خارج از دامنه‌ای نداشته باشد | scope_report.json |
block یا warn |
| همه‌ی قوانین با سطح اهمیت مسدودکننده پاس شوند | rule_report.json |
block |
هیچ کد خروجی null در بازخوردها نباشد |
feedback_record.jsonl |
block |
فایل‌های دست‌خورده با scope.allowed_files همخوانی داشته باشند |
هر دو | warn |
یافته‌ای با سطح warn صرفاً به رای نهایی ضمیمه میشود؛ اما یافته‌ای با سطح block جلوی passed: true را می‌گیرد.
قطعی، نه احتمالاتی
گیت باید برای یک مجموعه دست‌سازه‌ی یکسان، همیشه خروجی و رای ثابتی تولید کند. از داورهای مبتنی بر مدلهای زبانی بزرگ (LLM judges) خبری نیست. جای داورهای LLM در بخش ایجنت بازبین (فصل 14 · 39) است؛ جایی که هدف ارزیابی کیفی است، نه تعیین وضعیت تسک.
یک گزارش، یک مسیر
گیت برای هر پایان تسک، یک verification_report.json تولید میکند که در مسیر outputs/verification/<task_id>.json ذخیره میشود. فرایند CI نیز دقیقاً همین مسیر را می‌خواند. وجود چند گیت با مسیرهای متفاوت، منبع حقیقت (source of truth) را دچار انشعاب (fork) میکند.
رد کردن بدون استثنا
یافته‌های با سطح اهمیت مسدودکننده توسط ایجنت قابل چشم‌پوشی (override) نیستند. این موارد تنها توسط انسان، با ثبت یک override_reason مشخص و شناسه‌ی کاربری overridden_by قابل چشم‌پوشی خواهند بود. نادیده گرفتن این موارد یک تغییر امضاشده است، نه تصمیمی که ایجنت بگیرد.
پیاده‌سازی از صفر
فایل code/main.py موارد زیر را پیاده‌سازی میکند:
- یک بارگذار (loader) برای هر دست‌سازه‌ی ورودی که همگی به‌صورت محلی شبیه‌سازی شده‌اند تا این درس کاملاً خودکفا باشد.
- تابع خالص
verify(task_id, artifacts) -> VerdictReport. - یک چاپگر که نتایج تک‌تک بررسی‌ها و وضعیت نهایی قبولی/رد را نمایش میدهد.
- یک نسخه‌ی نمایشی با سه سناریوی تسک: قبولی بی‌نقص، خزش دامنه (scope creep) و غیبت معیارهای پذیرش.
اجرای کد:
python3 code/main.pyخروجی: سه گزارش رای نهایی، که هر کدام در کنار اسکریپت ذخیره می‌شوند.
الگوهای کاربردی در محیط‌های عملیاتی
پنج الگو وجود دارند که این گیت را از «یک تسک ساده‌ی lint» به «نقطه‌ی تعیین‌کننده‌ی اصلی» ارتقا می‌دهند:
دفاع در عمق، نه یک گیت تنها. هوک pre-commit ← بررسی وضعیت در CI ← هوک مجوز پیش از ابزار ← گیت pre-merge. هر لایه قطعی است تا خطای ردشده از یک لایه، در لایه‌ی بعدی گرفته شود. شیوه‌نامه‌ی مارس 2026 در microservices.io صراحتاً می‌گوید: هوک pre-commit غیرقابل دور زدن است؛ چون برعکس مهارت‌های سمت مدل، به دنبال کردن دستورالعمل‌ها توسط ایجنت وابسته نیست. گیت اعتبارسنجی در لایه‌ی CI / pre-merge می‌نشیند.
دفاع با بررسی‌های قطعی، داوری مدل فقط برای نکات ظریف. الگوی ترکیبی سال 2026 شرکت Anthropic: پاداش‌های قابل اعتبارسنجی (تستهای واحد، بررسی ساختار اسکما، کدهای خروجی) به این پرسش پاسخ می‌دهند که «آیا کد مسئله را حل کرد؟» — شیوه‌نامه‌های نمره‌دهی (rubrics) با LLM پاسخ می‌دهند که «آیا کد خوانا، امن و مطابق شیوه‌نامه‌ی کدنویسی هست یا خیر؟» گیت دسته‌ی اول را اجرا میکند؛ ایجنت بازبین (فصل 14 · 39) دسته‌ی دوم را. مخلوط کردن این دو با هم، شفافیت نتایج را از بین می‌برد.
لاگ چشم‌پوشیِ امضاشده، نه گفتگوهای اسلک. هر چشم‌پوشی یک سطر در outputs/verification/overrides.jsonl ثبت میکند که شامل این موارد است: برچسب زمانی، کد یافته، دلیل، کاربر امضاکننده و commit فعلیِ HEAD. محیط اجرا هر چشم‌پوشیِ بدون امضا را رد میکند؛ ردپای حسابرسی نیز در git دنبال میشود. مرز میان یک سیاست چشم‌پوشی واقعی و یک نمایش صوری همین جاست.
کف پوشش آزمون به‌عنوان یک بررسی تراز اول. فایل coverage_report.json ورودی بررسی coverage_floor (پیش‌فرض 80%) است. اگر پوششِ سنجیده‌شده به زیر این کف بیفتد یا نسبت به merge قبلی بیش از 1 درصد افت کند، گیت با خطا متوقف میشود. بدون این بررسی، ایجنت‌ها بیسروصدا تست‌هایی را که fail می‌شوند حذف می‌کنند و گزارش‌های اعتبارسنجی همچنان سبز می‌مانند.
حالت strict-- هشدارها را به خطا تبدیل میکند. برای branchهای انتشار، PRهای مسدودکننده‌ی عرضه یا تریاژ پس از رخداد، پرچم strict-- همه‌ی هشدارها را به خطای قطعی مسدودکننده تبدیل میکند. این پرچم به‌صورت اختیاری روی هر branch فعال میشود، نه به‌عنوان پیش‌فرض سراسری؛ چون اعمال همیشگی حالت Strict جریان روزمره‌ی کار را مختل میکند.
استفاده از ابزارهای واقعی
الگوهای محیط عملیاتی:
- مرحله‌ی CI. تسک
verify_agentگیت را روی دست‌سازه‌های نهایی ایجنت اجرا میکند. سازوکار محافظت از merge تا زمان دریافتpassed: trueاجازه‌ی ادغام نمی‌دهد. - هوک پیش از تحویل (Pre-handoff hook). محیط اجرای ایجنت قبل از تولید سند تحویل کار، گیت را فراخوانی میکند. رای سبز نباشد، تحویلی هم در کار نیست.
- تریاژ دستی. وقتی ایجنت ادعای موفقیت میکند و نیروی انسانی به آن شک دارد، اپراتورها گزارش را بررسی می‌کنند.
این گیت نقطه‌ی تصمیم‌گیری نهایی در جریان کاری میز کار است. تمام سطوح دیگر در بالادستِ آن قرار دارند.
خروجی این درس
فایل outputs/skill-verification-gate.md این گیت را به یک پروژه‌ی مشخص وصل میکند: کدام دستورهای پذیرش ورودی آن هستند، کدام قوانین اهمیت مسدودکننده دارند، چه میزان نوشتن خارج از دامنه‌ای تحمل میشود و لاگ حسابرسی چشم‌پوشی‌ها چگونه نگهداری خواهد شد.
تمرین‌ها
- یک بررسی
coverage_floorاضافه کنید: دستور تست باید گزارش پوشش آزمونی با حداقل 80% تولید کند. مشخص کنید کدام دست‌سازه باید این کف پوشش را در خود داشته باشد. - قابلیتی برای حالت
strict--پیاده کنید که همه‌یwarnها را بهblockتبدیل کند. مواردی را که حالت Strict باید پیش‌فرض باشد مستند کنید. - کاری کنید گیت علاوه بر JSON، یک خلاصه‌ی Markdown هم تولید کند. استدلال کنید که چه فیلدهایی باید در این خلاصه آورده شوند.
- یک بررسی
time_since_last_human_touchاضافه کنید: هر فایلی که در بازه‌ی زمانی 60 ثانیه‌ای پس از فشرده‌شدن کلیدی توسط انسان ویرایش شده باشد، از خطاهای خارج از دامنه معاف شود. - گیت را روی یک diff واقعیِ تولیدشده توسط ایجنت در محصول خودتان اجرا کنید. چند مورد از یافته‌ها واقعی و چند مورد نویز هستند؟ این گیت در چه بخش‌هایی نیاز به رشد و توسعه دارد؟
اصطلاحات کلیدی
| اصطلاح | در گفتار عامیانه | معنای واقعی و دقیق |
|---|---|---|
| گیت اعتبارسنجی (Verification gate) | «همان بررسی‌ای که جلوی همه‌چیز را می‌گیرد» | تابع قطعی روی دست‌سازه‌های میز کار که رای قبول/رد نهایی را صادر میکند |
| سطح اهمیت مسدودکننده (Block severity) | «خطای سخت (Hard fail)» | یافته‌ای که مانع از passed: true میشود و نیاز به چشم‌پوشی امضاشده دارد |
| لاگ چشم‌پوشی (Override log) | «چرا اجازه دادیم رد شود» | ورودی‌های امضاشده با ذکر دلیل و شناسه‌ی کاربری که در بازبینی حسابرسی می‌شوند |
| دستور پذیرش (Acceptance command) | «سند اثبات» | دستور شلی که خروجی صفر آن به معنای «تمام شدن کار» است |
| مسیر گزارش واحد (One report path) | «مرجع حقیقت» | مسیر outputs/verification/<task_id>.json که هم توسط CI و هم انسان‌ها خوانده میشود |
برای مطالعه‌ی بیشتر
- Anthropic, Harness design for long-running application development
- OpenAI Agents SDK guardrails
- microservices.io, GenAI dev platform: guardrails — دفاع در عمق میان pre-commit و CI
- ICMD, The 2026 Playbook for Agentic AI Ops — نردبان گیت تایید (پیش‌نویس ← تایید ← خودکار بر اساس آستانه‌ها)
- Type-Checked Compliance: Deterministic Guardrails (arXiv 2604.01483) — استفاده از Lean 4 به‌عنوان سقف نهایی گیت‌های اعتبارسنجی قطعی
- logi-cmd/agent-guardrails — merge gate spec — گیت‌های اعتبارسنجی دامنه و تست جهش (mutation testing)
- Guardrails AI x MLflow — اعتبارسنج‌های قطعی در نقش امتیازدهنده‌های CI
- فصل 14 · 27 — دفاع در برابر تزریق پرامپت (جفت تقابلی این گیت)
- فصل 14 · 36 — قرارداد دامنه‌ای که این گیت پیاده‌سازی و اعمال میکند
- فصل 14 · 37 — لاگ بازخوردی که این گیت به آن نمره میدهد
- فصل 14 · 39 — ایجنت بازبینی که این گیت کار را به آن تحویل میدهد