Daniel Meppiel که در Microsoft مسئول بازاریابی و فروش (go-to-market) حوزه Agentic SDLC است و کتاب The Agentic SDLC Handbook را نوشته، طرحی منتشر کرده که نشان می‌دهد شرکت‌ها چطور می‌توانند بدون بازبینی تک‌تک خطوط به کدی که عامل‌های هوش مصنوعی نوشته‌اند اعتماد کنند. او پیش از Microsoft در CERN روی سامانه‌های توزیع‌شده و در GitHub و Sonar روی ابزارهای توسعه‌دهندگان کار کرده است. این جستار با عنوان "Agent Contracts and Receipts: toward verifiable agentic software factories" روز ۴ نوامبر ۲۰۲۶ در وب‌سایت شخصی‌اش The AI Native Mind منتشر شد. متن بر پایه سخنرانی او در رویداد aiDevCon NYC با عنوان "Version your factory, not just your code" نوشته شده و همراه آن مشخصاتی در GitHub منتشر شده که خود نویسنده آن را پیش‌نویس ۰.۱ و «یک دعوت، نه یک استاندارد» می‌نامد.

نقطه شروع Meppiel گلوگاهی است که به گفته او سازمان‌های بزرگ مدام با آن روبه‌رو می‌شوند. عامل‌های کدنویس تولید تغییرات را ارزان کرده‌اند، اما هر درخواست ادغام (pull request) همچنان باید منتظر بماند تا سامانه یکپارچه‌سازی پیوسته همه آزمون‌ها را دوباره اجرا کند و یک نفر آن را بخواند. به نظر او دسته‌بندهای ریسک که تغییرات کوچک را خودکار ادغام می‌کنند مفیدند، اما تغییر در روند تأیید پرداخت‌ها هیچ‌وقت کم‌خطر نیست و چنین دسته‌بندی فقط خود تغییر را می‌سنجد، نه اینکه سامانه‌ای که آن را نوشته همان سامانه تأییدشده سازمان باشد. ادعای اصلی او این است که اعتماد نه از مدل می‌آید و نه از خواندن خروجی‌اش، بلکه باید از سامانه تولیدکننده بیاید؛ سامانه‌ای که مثل هر زنجیره تأمین نرم‌افزار طراحی و گواهی شده باشد.

واحد اصلی این طرح Agent Contract یا «قرارداد عامل» است: یک فایل نسخه‌دار که یک کار مشخص عامل را توصیف می‌کند، شبیه شرح وظایفی که به یک کارمند تازه‌وارد می‌دهند. این فایل مشخص می‌کند به چه ورودی‌هایی نیاز دارد و چه فایل‌هایی تحویل می‌دهد، مهارت‌ها (skills) را با نسخه ثابت فراخوانی می‌کند، سقفی برای تعداد تلاش‌ها و زمان می‌گذارد و آزمون‌هایی را که نتیجه با آن‌ها سنجیده می‌شود از پیش و پیش از اجرا تعیین می‌کند. قراردادها به هم زنجیر می‌شوند و گرافی می‌سازند که Meppiel آن را «کارخانه نرم‌افزار عامل‌محور» می‌نامد. کل این گراف یک نسخه و یک اثرانگشت دارد؛ چکیده‌ای رمزنگاری‌شده که همه قراردادها، آزمون‌ها و مهارت‌ها را پوشش می‌دهد. کارخانه به عامل خاصی وابسته نیست و فعلاً روی GitHub Copilot CLI یا OpenCode اجرا می‌شود.

هر اجرای کامل یک رسید بر جا می‌گذارد؛ بسته‌ای واحد در قالب in-toto درباره همان فایل‌هایی که تحویل شده‌اند. این رسید شامل سابقه تولید در قالب SLSA است که نسخه کارخانه، مراحل، عامل، مدل و کامیت پایه را ثبت می‌کند؛ یک نتیجه آزمون in-toto برای هر آزمون اعلام‌شده؛ و یک ABOM، یعنی فهرست اجزای عامل در قالب CycloneDX که مهارت‌ها و بسته‌های در اختیار عامل را با هش محتوایشان فهرست می‌کند. به گفته نویسنده، مدل رایج زنجیره تأمین در دو جا باید تغییر کند. خروجی عامل را نمی‌توان بایت‌به‌بایت دوباره ساخت، پس یک کار جداگانه بدون عامل و بدون دسترسی به مدل، آزمون‌ها را روی فایل‌های تحویلی دوباره اجرا می‌کند. و چون عامل کم‌اعتمادترین بازیگر است، هرگز امضا نمی‌کند؛ یک گردش‌کار ثابت در سامانه یکپارچه‌سازی پیوسته که از دسترس عامل بیرون است رسید را بررسی و با Sigstore امضا می‌کند.

بخش آخر یک بررسی اجباری واحد در لحظه ادغام است. فایل سیاستی که تیم امنیت مالک آن است، یعنی apm-policy.yml، اثرانگشت کارخانه‌های تأییدشده، امضاکننده مورد اعتماد، منابع مجاز مهارت‌ها و مهارت‌های لغوشده را فهرست می‌کند. هر مخزن می‌تواند قواعد سازمان را سخت‌گیرانه‌تر کند ولی هرگز نمی‌تواند آن‌ها را شل کند. این دروازه سیاست را از شاخه پایه می‌خواند، هر فایل تغییرکرده را با چکیده SHA-256 آن در انبار گواهی‌های امضاکننده جست‌وجو می‌کند و هر چیزی را که در تحویل امضاشده نیامده رد می‌کند. در نمایش عملی، درخواست یک بانک خیالی برای نگه‌داشتن حواله‌های بزرگ به گیرندگان جدید، یک درخواست ادغام واقعی روی مخزن آزمایشی پرداخت ساخت که از کارخانه‌ای با پنج قرارداد و یازده آزمون بیرون آمده بود. به گفته نویسنده، این بررسی ۲۲ ثانیه طول کشید.

Meppiel درباره محدودیت‌ها صریح است. سبز شدن دروازه یعنی معلوم است کدام کارخانه تأییدشده تغییر را ساخته و کدام آزمون‌ها پاس شده‌اند، نه اینکه کد درست است؛ پس اعتبارش به اندازه کیفیت همان آزمون‌هاست. هیچ سطح ساخت SLSA ادعا نمی‌شود، نام مدل ثبت می‌شود ولی راستی‌آزمایی نمی‌شود، لغو یک مهارت جلوی تحویل‌های تازه را می‌گیرد اما کد ادغام‌شده را پس نمی‌گیرد، و رسیدهایی که روی لپ‌تاپ ساخته می‌شوند امضا ندارند. او همچنین یادآوری می‌کند که فهرست مهارت‌هایی که به عامل داده شده ثابت نمی‌کند عامل واقعاً از آن‌ها پیروی کرده است.

این طرح فقط روی کاغذ نیست و در دو پروژه متن‌باز که خود Meppiel ساخته پیاده شده است. APM، مدیر بسته عامل‌های Microsoft با نام Agent Package Manager، کارخانه‌ها را نصب می‌کند و هر مهارت را به یک کامیت و هش محتوا گره می‌زند و همه را زیر یک سیاست سازمانی واحد مدیریت می‌کند؛ به گفته جستار، Dependabot اکنون به‌روزرسانی نسخه‌های APM را پشتیبانی می‌کند. APMX که او آن را پیاده‌سازی مستقل و آزمایشی می‌نامد، کارخانه‌ها را روی عامل دلخواه اجرا می‌کند، رسیدها را می‌نویسد و دروازه را با فرمان apmx audit فراهم می‌کند. او می‌گوید استفاده از قالب به هیچ‌کدام از این دو وابسته نیست و از جامعه‌های SLSA و in-toto و CycloneDX و هر علاقه‌مند دیگری دعوت می‌کند پیش‌نویس را در بخش گفت‌وگوهای GitHub نقد کنند.

منابع