اگر امروز مدیریت تسک‌های تیمتان را به عامل‌های هوش مصنوعی سپرده‌اید، احتمالاً با بحران «تسک‌های به‌ظاهر تمام‌شده» دست‌وپنجه نرم می‌کنید. وقتی یک عامل ادعا می‌کند کاری را «انجام داده»، لزوماً به این معنا نیست که کد در محیط عملیاتی فعال شده یا توسط انسان تأیید شده است. یک برچسب ساده‌ی «Done» در ردیاب پروژه، زمانی که عامل‌های AI در حال انجام کار هستند، تبدیل به یک ریسک و نقطه ضعف می‌شود.
به گزارش Wagglet در ۲ اکتبر ۲۰۲۶، ادغام مفاهیمی چون تحویل (Delivery)، پذیرش (Acceptance)، ادغام (Merge) و استقرار (Deployment) در یک فیلد وضعیت واحد، باعث ایجاد ابهامات خطرناکی می‌شود و ریسک‌های ایمنی قابل اجتنابی را به همراه دارد. بسیاری از تیم‌ها تصور می‌کنند سبز شدن تست‌های CI و ادعای تکمیل توسط عامل، یک حقیقت واحد هستند؛ اما در واقعیت، این‌ها چهار رویداد مجزا هستند: عامل تلاش خود را به پایان رسانده، انسان نتیجه را پذیرفته، کد به شاخه اصلی منتقل شده و در نهایت کاربر به‌روزرسانی را دریافت کرده است. این موضوع یادآور این نکته است که تست‌های سبز در محیط‌های اتوماسیون لزوماً تضمینی برای صحت نهایی کد نیستند و نباید به تنهایی مبنای ادغام قرار گیرند. وقتی این چهار رویداد در یک وضعیت ادغام می‌شوند، تیم‌ها نمی‌توانند تشخیص دهند که آیا یک تسک واقعاً تمام شده است یا صرفاً توسط یک AI که احتمالاً در حال توهم (Hallucination) درباره موفقیت خود است، «تحویل» داده شده است.
تصور کنید عاملی یک تیکت را «انجام‌شده» علامت می‌زند، اما کد هنوز در یک Pull Request منتظر بررسی است. اگر مدیر انتشار این وضعیت را ببیند، گمان می‌کند قابلیت جدید فعال شده است. همین شکاف میان «قصد» و «واقعیت» است که باگ‌های محیط عملیاتی و پس‌روی‌های امنیتی در آن پنهان می‌شوند.
معماری ماشین‌حالت (The State Machine Architecture)
همان‌طور که در تحلیل‌های پیشین ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، اعتماد کورکورانه به خروجی‌های مدل بدون لایه‌های اعتبارسنجی، بزرگ‌ترین گلوگاه مقیاس‌پذیری است. برای حل این مشکل، Wagglet معماری یک ماشین‌حالت (State Machine) — شبیه به یک نقشه راه سخت‌گیرانه که اجازه نمی‌دهد بدون طی کردن هر مرحله، به مرحله بعد پرش کنید — را پیشنهاد می‌دهد که ردیاب کار را از سیستم‌های مخزن کد و انتشار جدا می‌کند. در این مدل، ردیاب کار مسئول مدیریت «قصد» و «بازبینی» است، در حالی که مخزن کد مالکیت «ادغام» و «استقرار» را بر عهده دارد.
این مدل اجازه نمی‌دهد این حقیقت‌های متفاوت در یک فیلد وضعیت گنجانده شوند. در عوض، از سه نوع حالت مجزا برای ردیابی پیشرفت استفاده می‌کند:
- حالت کار (WorkState): پیش‌نویس (draft) $\rightarrow$ باز (open) $\rightarrow$ ادعا شده (claimed) $\rightarrow$ تحویل‌شده (delivered) $\rightarrow$ تأییدشده (accepted)
- حالت ادغام (IntegrationState): نامربوط (not_applicable) $\rightarrow$ گزارش‌نشده (unreported) $\rightarrow$ گزارش‌شده (branch_reported) $\rightarrow$ باز بودن PR (pull_request_open) $\rightarrow$ ادغام‌شده (merged) $\rightarrow$ مسدود (blocked)
- حالت استقرار (DeploymentState): نامربوط (not_applicable) $\rightarrow$ مستقرنشده (not_deployed) $\rightarrow$ در حال استقرار (deploying) $\rightarrow$ مستقرشده (deployed) $\rightarrow$ شکست‌خورده (failed)
با این تفکیک، یک تسک می‌تواند توسط بازبین «تأیید» شود اما در محیط عملیاتی هنوز «مستقرنشده» باشد. یک تغییر ادغام‌شده ممکن است هنوز مستقر نشده باشد. همچنین یک تسک غیرکدی می‌تواند تأیید شود بدون اینکه فیلدهای ادغام یا استقرار برای آن اعمال شوند. این یک تناقض نیست، بلکه مدل‌سازی دقیقی است که نقشهای با جزئیات بالا از نقاط توقف هر قابلیت ارائه می‌دهد.
محافظت از گذارها (Guarding the Transitions)
طبق مستندات Wagglet، دسترسی‌ها باید به نقشهای خاص گره بخورند، نه دسترسی‌های مدیریتی کلی. سیستم نقش‌هایی مانند درخواست‌کننده (requester)، مالک تسک (task_owner)، اجراکننده (runner)، بازبین (reviewer)، نگهدارنده مخزن (repository_maintainer) و مدیر انتشار (release_owner) را تعریف می‌کند.
یک فرد ممکن است چندین نقش داشته باشد، اما بررسی دسترسی باید دقیقاً نام نقشی را که در حال استفاده است ذکر کند. این کار مانع از آن می‌شود که یک تغییر وضعیت توسط مدیر (Administrator Override) به عنوان یک بازبینی عادی توسط همکار به نظر برسد. برای کارهای پرریسک، سیستم الزام می‌کند که بازبین حتماً شخصی متفاوت از اجراکننده باشد. اگر «خود-تأییدی» (Self-verification) مجاز باشد، باید صراحتاً ثبت شود و نباید به عنوان یک پذیرش مستقل ارائه گردد.
این ماشین‌حالت برای جلوگیری از تقلب عامل‌های هوش مصنوعی، میان‌برها را مسدود می‌کند. تابع گذار (Transition Function) هم حالت فعلی و هم بازیگر (Actor) را اعتبارسنجی می‌کند:
- پیش‌نویس $\rightarrow$ باز: نیازمند یک شرح آماده و مالک است. پاسخ می‌دهد: «آیا تسک به اندازه کافی ایمن و مشخص است که ارائه شود؟»
- باز $\rightarrow$ ادعا شده: نیازمند یک اجراکننده واجد شرایط و شناسه‌ی تلاش (Attempt ID) است. پاسخ می‌دهد: «چه کسی مالک این تلاش است؟»
- ادعا شده $\rightarrow$ تحویل‌شده: نیازمند یک گزارش تحویل و مصنوعات (Artifacts) است. پاسخ می‌دهد: «اجراکننده چه نتیجه‌ای تولید کرد؟»
- تحویل‌شده $\rightarrow$ تأییدشده: نیازمند حکم بازبین است. پاسخ می‌دهد: «آیا نتیجه، نیازهای تسک را برآورده می‌کند؟»
برای مثال، یک اجراکننده نمی‌تواند در مسیرهای عادی، تحویل خود را به وضعیت «تأییدشده» ببرد. یک وب‌هوک مخزن کد می‌تواند وضعیت ادغام را به‌روز کند، اما اجازه ندارد کار را «تأییدشده» علامت بزند. همچنین یک استقرار موفق نمی‌تواند یک گزارش تحویل مفقود را به صورت خودکار جعل کند.
تکرارناپذیری و شواهد (Idempotency and Evidence)
در این رویکرد، تحویل (Delivery) به عنوان یک گزارش تلقی می‌شود، نه یک حکم نهایی. تحویل یعنی «این تلاش آماده قضاوت است»، نه اینکه کار لزوماً درست است. هر رکورد تحویل به صورت Append-only (فقط افزودنی) است و به یک شناسه‌ی تلاش خاص گره خورده است. یک رکورد تحویل شامل موارد زیر است: ticketId (شناسه تیکت)، attemptId (شناسه تلاش)، runnerId (شناسه اجراکننده)، summary (خلاصه)، branch (شاخه)، commitSha (شناسه کامیت)، createdAt (زمان ایجاد) و یک operationId.
برای جلوگیری از تداخلات ناشی از تب‌های باز مرورگر یا تأخیر در پردازش عامل‌ها، سیستم از Operation ID برای تکرارناپذیری (Idempotency) — یعنی قابلیتی که باعث می‌شود اجرای مکرر یک دستور، نتیجه‌ای متفاوت یا تکراری ایجاد نکند — و همچنین بررسی نسخه (Revision) تیکت استفاده می‌کند. این رویکرد برای دستیابی به تکرارپذیری در خروجی‌های AI حیاتی است، مشابه آنچه در بحث تثبیت سخت‌افزاری در برابر تاریخچه چت برای جلوگیری از نوسانات عامل‌ها بررسی کردیم. اگر کلاینت پس از ذخیره تحویل در سرور دچار Timeout شود و همان عملیات را دوباره ارسال کند، سیستم به جای ایجاد یک رکورد تکراری، نتیجه اصلی را برمی‌گرداند.
این امر تضمین می‌کند که تاریخچه تلاش‌های AI به صورت یک لاگ حسابرسی خطی و پاکیزه باقی بماند. تابع deliver یک توالی سخت‌گیرانه را دنبال می‌کند: ابتدا نتایج موجود برای operationId را برمی‌گرداند، تیکت را برای مقایسه نسخه بارگذاری می‌کند، دسترسی‌های حالت و اجراکننده را بررسی می‌کند و سپس تحویل را ثبت کرده و حالت را به صورت اتمیک (Atomic) تغییر می‌دهد.
مدیریت بازنگری‌ها و شکست‌ها (Handling Rework and Failures)
شکست در بازبینی یک حالت باینری (صفر و یک) نیست. گردش کار بر اساس ماهیت شکست، دو مسیر بازگشت مجزا را از طریق نوع ReviewDecision پشتیبانی می‌کند:
۱. بازگشت برای اصلاح (Send-back): زمانی استفاده می‌شود که همان اجراکننده باید نتیجه را اصلاح کند. تسک به حالت «ادعا شده» بازمی‌گردد و مالکیت حفظ می‌شود. یک تلاش یا نسخه جدید شروع می‌شود در حالی که تحویل قبلی به عنوان تاریخچه حفظ می‌گردد. این مسیر شامل یک رشته متنی برای «بازخورد» (feedback) است.
۲. بازگشایی مجدد (Reopen): زمانی استفاده می‌شود که یک اجراکننده متفاوت مورد نیاز است. تسک به حالت «باز» برمی‌گردد و ادعای مالکیت قبلی پاک می‌شود. تحویل قبلی به عنوان مدرک باقی می‌ماند اما دیگر پاسخ جاری نیست. این مسیر شامل یک رشته متنی برای «دلیل» (reason) است.
این دو مسیر در نحوه مدیریت اعلان‌ها، انتساب‌ها و زمینه‌ای (Context) که به اجرای بعدی عامل ارائه می‌شود، با هم متفاوت هستند و نباید به سادگی به عنوان «بردن کارت به سمت چپ» در بورد پیاده‌سازی شوند.
جداسازی ریل مخزن کد (Separating the Repository Rail)
به نظر Wagglet، به‌روزرسانی‌های مخزن کد باید در یک «ریل» جداگانه از فرآیند بازبینی حرکت کنند. وقتی یک تحویل، شاخه یا کامیتی را گزارش می‌کند، سیستم ابتدا آن را به عنوان یک ادعا ذخیره کرده و سپس با استفاده از RepositoryEvidence (که شامل reportedBranch ،verifiedHeadSha ،pullRequestUrl و mergeState است) آن را از طریق ارائه‌دهنده مخزن تأیید می‌کند.
این جداسازی در موارد زیر حیاتی است:
- زمانی که حفاظت از شاخه (Branch Protection) نیاز به بازبینی انسانی دوم داشته باشد.
- زمانی که CI پس از تأیید اولیه تسک، با شکست مواجه شود.
- زمانی که شاخه پایه پیشروی کرده و تداخلی (Conflict) ایجاد شود.
- زمانی که یک Pull Request را عمداً برای دسته‌بندی تغییرات (Batching) باز نگه می‌دارند.
- زمانی که یک استقرار علی‌رغم ادغام موفق، بازگشت (Rollback) شود.
در واقع، برای جلوگیری از ورود کدهای ناپایدار، می‌توان شرایط توقف سخت‌گیرانه‌ای را برای مسدود کردن Pull Requestهای پرریسک تعریف کرد تا از صحت ادغام اطمینان حاصل شود. رابط کاربری (UI) می‌تواند این حقایق را در کنار هم نشان دهد — مثلاً: «کار: تأییدشده، مخزن: PR باز، استقرار: مستقرنشده» — بدون اینکه آن‌ها را در یک وضعیت واحد گمراه‌کننده ادغام کند. این به مدیر انتشار می‌گوید دقیقاً چه چیزی باقی مانده است.
لاگ حسابرسی (The Audit Log)
سیستم به جای ذخیره تنها آخرین مقدار، هر رویداد را از طریق نوع TicketEvent ثبت می‌کند. این شامل actorId (شناسه بازیگر)، نوع رویداد (مانند published ،claimed ،delivered ،sent_back ،reopened ،accepted ،merge_state_changed یا deployment_state_changed) و متادیتای مرتبط است.
این لاگ حسابرسی تفاوت بین یک «تلاش شکست‌خورده» و یک «تسک بد تعریف‌شده» را متمایز می‌کند. همچنین عمل «خود-تأییدی» را از «بازبینی مستقل» جدا می‌کند و داده‌هایی را در اختیار تیم‌ها می‌دهد تا بدون تکیه بر امتیازات موفقیت مبهم، عملکرد عامل‌ها را بهبود بخشند.
چک‌لیست پیاده‌سازی (Implementation Checklist)
پیش از استقرار این چرخه حیات، موارد زیر را تأیید کنید:
- هر تغییر (Mutation) وضعیت فعلی را در سرور بررسی می‌کند.
- ادعا و تحویل به یک شناسه‌ی تلاش (Attempt ID) متصل هستند.
- تغییرات از کلید تکرارناپذیری (Idempotency Key) و نسخه مورد انتظار استفاده می‌کنند.
- تحویل شواهد را ذخیره می‌کند اما به معنای پذیرش نیست.
- مسیرهای Send-back و Reopen رفتارهای متفاوتی در مالکیت دارند.
- پذیرش ثبت می‌کند چه کسی کار را بازبینی کرده و آیا بازبینی مستقل بوده است یا خیر.
- وضعیت‌های شاخه، PR، ادغام و استقرار از سیستم‌های واقعی خود دریافت می‌شوند.
- به‌روزرسانی‌های مخزن و استقرار نمی‌توانند وضعیت بازبینی کار را بازنویسی کنند.
- لاگ رویدادها، تحویل‌های جایگزین شده و دلایل بازنگری را حفظ می‌کند.
- رابط کاربری وضعیت‌های مجزا را با زبان ساده در کنار هم نمایش می‌دهد.
این تغییر معماری، ادغام عامل‌های AI را از یک «جعبه سیاه» از به‌روزرسانی‌های وضعیت به یک خط لوله شفاف و محافظت‌شده تبدیل می‌کند. با رد کردن راحتیِ یک برچسب واحد «Done»، تیم‌ها سیستمی به دست می‌آورند که در آن اتوماسیون ایمن‌تر است و نظارت انسانی واقعاً امکان‌پذیر می‌شود.
گام بعدی شما
- وضعیت‌های Workflow خود را بررسی کنید و هر جا برچسب «Done» دارید، آن را به سه لایه «تحویل»، «تأیید» و «استقرار» تفکیک کنید.
- برای عامل‌های AI، دسترسی تغییر وضعیت به «تأییدشده» را کاملاً مسدود کرده و آن را به یک نقش انسانی (Reviewer) محدود کنید.
- یک لاگ رویداد (Event Log) برای هر تلاش عامل ایجاد کنید تا بتوانید نرخ بازگشت (Send-back) را به عنوان معیاری برای کیفیت پرامپت‌ها اندازه بگیرید.
اما مدیریت این وضعیت‌ها در مقیاس هزاران عامل، چالش‌های جدیدی در پایگاه‌داده ایجاد می‌کند — به تحلیل ما درباره‌ی بهینه‌سازی استنتاج در محیط‌های توزیع‌شده مراجعه کنید.
گفتگو