حالت‌ها
حالت چیست
بخش با عنوان “حالت چیست”حالت ویژگی یک فضا است و به‌صورت یک ستون روی ردیف فضا ذخیره می‌شود. هر گفتگویی درون یک فضا آن را به اشتراک می‌گذارد، از جمله رشته‌ها — یک رشته حالت فضای خود را مانند هر گفتگوی دیگری به ارث می‌برد. بنابراین یک عامل می‌تواند هم‌زمان در فضاهای مختلف حالت‌های متفاوت داشته باشد و تغییر حالت یک فضا، بدون دست‌زدن به عامل، رفتار نوبت بعد را عوض می‌کند.
دقیقاً چهار حالت وجود دارد: chat، review، plan، orchestrate. خودِ این enum هیچ سیاستی در خود ندارد. هر چیزی که یک حالت تضمین می‌کند یک‌بار و در یک نمایهٔ توانمندی اعلام می‌شود و هر لایهٔ اعمال قواعد از همان مشتق می‌شود:
- سطح ابزار — اینکه اصلاً چه ابزارهایی در آن حالت وجود دارند؛ به‌صورت یک ردهٔ حداکثر تأیید، یک فهرست مجاز، یک فهرست مسدود و مجموعه‌ای از کلاس‌های اثر ردشده بیان می‌شود.
- فعل خروجی الزامی — چه فراخوانی‌ای باید انجام شود تا اجرا چیزی تحویل داده باشد.
- کلاس‌های اثر ردشده — چیزهایی که نگهبان کنش مستقیماً رد می‌کند.
- وضعیت worktree — اینکه آیا می‌توان در worktree نوشت. این مورد با حذف ابزارهای تغییردهنده از سطح ابزار اعمال می‌شود و همین است که آن را روی هر میزبانی برقرار می‌دارد. جایی که میزبان سندباکس سیستم‌عامل دارد، همان وضعیت قواعد نوشتن فایل‌سیستم را هم می‌تراشد — یک حالت فقط‌خواندنی، worktree را فقط‌خواندنی سوار می‌کند — اما این نسخهٔ دومی از همان تضمین است، نه همان نسخه‌ای که کار را انجام می‌دهد.
- بلوک پرامپت سیستمی — یک پیش‌گفتار توانمندیِ تولیدشده که از فهرست واقعی و مادی‌سازی‌شدهٔ ابزارها مشتق می‌شود، به‌علاوهٔ راهنمایی دست‌نویس.
هر لایهٔ اعمال قواعد از همان یک نمایه مشتق می‌شود، بنابراین سطح ابزار، نگهبان، وضعیت worktree و پرامپت نمی‌توانند با هم ناسازگار باشند.
چهار حالت
بخش با عنوان “چهار حالت”گفتگو — با عنوان «عامل» نمایش داده می‌شود
بخش با عنوان “گفتگو — با عنوان «عامل» نمایش داده می‌شود”حالت پیش‌فرض و تنها حالتی که محدودیت اضافه‌ای ندارد: سطح ابزار کامل تا ردهٔ اجرا، یک worktree نوشتنی، بدون کلاس اثر ردشده و بدون قرارداد تکمیل. برای پیاده‌سازی، رفع اشکال، پرسش دربارهٔ کدبیس و هر کار موردی از آن استفاده کنید.
به برچسب توجه کنید: در نویسندهٔ پیام، این حالت به‌صورت «عامل» نمایش داده می‌شود، نه «گفتگو».
برنامه — فقط‌خواندنی، یک خروجی
بخش با عنوان “برنامه — فقط‌خواندنی، یک خروجی”حالت برنامه، worktree را فقط‌خواندنی می‌کند و ابزارهای نوشتن را کامل از سطح ابزار حذف می‌کند، بنابراین محدودیت ساختاری است و نه دستوری. عامل می‌خواند، جستجو و پژوهش می‌کند و دقیقاً یک چیز تحویل می‌دهد: یک فراخوانی submit_plan که یک گراف وابستگی نوع‌دار را حمل می‌کند — یک هدف به‌همراه گره‌هایی با کلید، عنوان، توضیح و کلید گره‌هایی که هر گره به آن‌ها وابسته است.
طرح به‌صورت یک ردیف جمع‌وجور در گفتگو رندر می‌شود و Plan Studio را در زبانه‌ای کنار آن باز می‌کند. تأیید آن، گراف را به یک ارکستراسیون کامپایل می‌کند، کار تولیدشده را اجرا می‌کند و فضای نویسنده را به حالت عامل برمی‌گرداند.
اگر یک اجرای حالت برنامه بدون هیچ فراخوانی submit_plan به پایان برسد، حلقه ابتدا یک تلنگر تزریق می‌کند که می‌گوید تا وقتی آن فراخوانی موفق نشود، طرحی وجود ندارد. این تلنگر صریحاً یک خروج صادقانه با مضمون «اینجا نیازی به طرح نیست» را مجاز می‌کند، چون حالت برنامه تنظیمی برای فضا است و پرسشی ساده که درون آن پرسیده می‌شود نباید طرحی نادرست را تحمیل کند.
راه خروج دوم و جداگانه‌ای هم وجود دارد: exit_plan_mode. این یک دروازهٔ سخت تأیید است، نه یک فعل خروجی — عاملی که به‌جای submit_plan آن را فراخوانی کند، هیچ چیزی تحویل نداده است. فراخوانی نخست یک تأیید ماندگار plan_exit باز می‌کند و pending را برمی‌گرداند و فضا فقط‌خواندنی می‌ماند؛ فراخوانی‌های تکراری هم به‌جای بازکردن دروازهٔ دوم، در وضعیت pending می‌مانند. تنها پس از اعطای تأیید است که یک فراخوانی بعدی، فضا را به حالت گفتگو می‌چرخاند. رد شدن، به عامل اجازه می‌دهد درخواست تازه‌ای برای طرحی بازنگری‌شده باز کند.
برای آنکه خودتان از حالت برنامه خارج شوید، فهرست بازشوی نویسندهٔ پیام را عوض کنید (یا Shift+Tab). exit_plan_mode با ابزار MCP به نام decide_approval تصمیم‌گیری می‌شود. ردیف‌های «تأیید عامل» در صندوق ورودی چیز دیگری هستند: پرامپت‌های تأیید هر نوبت از یک عامل در حال اجرا.
بازبینی — فقط‌خواندنی، بدون قرارداد
بخش با عنوان “بازبینی — فقط‌خواندنی، بدون قرارداد”حالت بازبینی برای بازبینی PR است. worktree را فقط‌خواندنی می‌کند، سطح ابزار را زیر ردهٔ اجرا محدود می‌کند و یک فهرست مجازِ دست‌چین‌شده از ابزارهای بازبینی، تیکتینگ و ارتباطات را اعمال می‌کند. فضایی که برای یک pull request باز می‌شود، به‌طور خودکار در حالت بازبینی ساخته می‌شود.
خروجی عامل یافته‌های ساخت‌یافته است — گره‌های بازبینی — و وقتی بازبینی نهایی شود، یک حکم. یک گره حامل این‌هاست: یک نوع (bug، suggestion، recommendation، question یا ticket)، یک اولویت از P0 (مانع انتشار) تا P3 (خوب اما نه ضروری)، یک اطمینان خودسنجی‌شده، یک لنگر اختیاری (فایل به‌علاوهٔ یک محدودهٔ خط؛ یادداشت‌های سراسر مخزن لنگر ندارند) و یک وضعیت چرخهٔ عمر که پس از تأیید یک همتا — هرگز خود نویسنده — از open به consensusReady می‌رود. یافته‌ای که اولویت یا اطمینانش نباشد یا بیرون از محدوده باشد، همان‌جا در مرز خواندن حذف می‌شود و حکم را آلوده نمی‌کند.
حکم یکی از ship، hold یا block است و نتایج هر محور که در آن تنیده می‌شود، آن را فقط شدیدتر می‌کند: محور دروازه‌داری که شکست خورده باشد block را الزام می‌کند و محور دروازه‌داری که اجرا نشده باشد حداقل hold را. نبودِ شواهد هرگز دروازه‌ای را سبز نمی‌کند.
برخلاف برنامه و ارکستر، بازبینی هیچ قرارداد تکمیلی ندارد. یافته‌ها از طریق add_review_node انباشته می‌شوند و با finalize_review منتشر می‌شوند و هر دوی این‌ها می‌توانند به‌درستی صفر بار فراخوانی شوند — یک عامل پایپ‌لاین که در حالت بازبینی اجرا می‌شود، ممکن است آن‌جا باشد تا به‌جایش تیکتی را تکمیل کند.
ارکستر — فقط‌خواندنی، تیمی را پیشنهاد می‌دهد
بخش با عنوان “ارکستر — فقط‌خواندنی، تیمی را پیشنهاد می‌دهد”حالت ارکستر یک هدف را به طرحی برای تمام تیم تبدیل می‌کند. مانند حالت برنامه فقط‌خواندنی است و نمی‌تواند فایل بنویسد؛ روی سطح پژوهش، یک فعل ممتاز منفرد دارد: propose_orchestration که پیشنهادی ساخت‌یافته منتشر می‌کند: نقش‌ها، یک درخت زیرتیکت، یک گام برآیند و یک بودجه. پرامپت فقط ابزارهای روی سطح را نام می‌برد، پس مدل نوبت‌هایش را صرف روایت‌کردن استخدام یا کار تیکتی نمی‌کند که نمی‌تواند فراخوانی کند.
هیچ چیز در پیشنهاد اجرا نمی‌شود تا آنکه شما آن را تأیید کنید. هنگام تأیید، یک مادی‌ساز قطعی عامل‌ها را استخدام می‌کند، تیکت‌ها و یک پروژه می‌سازد و یک پایپ‌لاین تولیدشده را اجرا می‌کند. تأیید فقط در اختیار اپراتور است: هیچ ابزار MCPای برای آن نیست، بنابراین یک عامل می‌تواند پیشنهاد بدهد اما هرگز نمی‌تواند طرح خودش را تأیید کند. پیشنهادهای دوباره‌ای که عامل آغاز می‌کند، با یک دورهٔ خنک‌سازیِ دو دقیقه‌ای محدود می‌شوند، بنابراین طرح‌های پشت‌سرهم رد می‌شوند و به آن‌ها گفته می‌شود که یکدیگر را ادغام کنند. ارکستراسیون را ببینید.
دو قاعده که دانستنشان می‌ارزد
بخش با عنوان “دو قاعده که دانستنشان می‌ارزد”فعل خروجی خودِ یک حالت هرگز نمی‌تواند رد شود. submit_plan و propose_orchestration در سطح ابزار سنجاق می‌شوند و از پیش تصویب‌شده‌اند، چه از فیلتر ابزار، چه از دروازهٔ تأیید و چه از نگهبان کنش، بنابراین درجهٔ خودمختاری هر فضا نمی‌تواند خروجی یک حالت را خاموش کند. ask_user هارنس به همین دلیل سنجاق شده است: آن همان راهی است که یک اجرا به اپراتور می‌رسد، پس دروازه‌گذاشتن روی آن، اجرایی را که باید چیزی بپرسد در بن‌بست می‌گذارد. این ابزار در ردهٔ خواندن است، بنابراین هر حالت فقط‌خواندنی آن را نگه می‌دارد، و از پوشش تأیید معاف است — یک پرامپت جلوی پرامپت دیگر با نبود تأییدگرِ متصل به شکست بسته منتهی می‌شود، که یعنی سلب‌کردن عمل پرسیدن از عامل.
حالت‌های فقط‌خواندنی دسترسی شبکه یا رازها را رد نمی‌کنند. کلاس‌های اثری که بازبینی، برنامه و ارکستر رد می‌کنند همان‌هایی هستند که دنیا را تغییر می‌دهند: حذف فایل، نوشتن بیرون از worktree، کامیت‌ها، پوش‌ها، ساخت و انتشار PR، نوشتن‌های همگام‌سازی فروشنده، نصب بسته‌ها، ایجاد فرایند، دستکاری فضای کاری و کنترل محفظه. خروج شبکه و دسترسی به رازها عمداً در پیش‌فرض خود می‌مانند — پژوهش، تمام هدف یک حالت فقط‌خواندنی است.
انتخاب و تغییر حالت
بخش با عنوان “انتخاب و تغییر حالت”فهرست بازشوی حالت در نویسندهٔ پیام سه گزینه دارد: عامل (گفتگو)، برنامه و ارکستر. review انتخاب‌پذیر برای کاربر نیست — این حالت را سیستم هنگام ساخت یک فضای بازبینی PR و همچنین گام‌های پایپ‌لاین تعیین می‌کند.
یک گرهٔ پایپ‌لاین که فضایی باز می‌کند می‌تواند حالت آن اتاق را با کلید extras['mode'] سنجاق کند (chat، review یا plan). این کلید تطبیق دقیق دارد: هر املای دیگری — از جمله orchestrate — بی‌صدا نادیده گرفته می‌شود و اتاق پیش‌فرض بدنه را می‌گیرد (review روی بدنهٔ ساخت فضا). یک گام عامل به اتاقی می‌پیوندد که خودش نساخته است و مجوزهایش را دوباره تنظیم نمی‌کند.
خودِ تعیین حالت ساده است. اعزام‌کننده ستون mode فضا را می‌خواند؛ اعزامی که فضایی ندارد — یک اجرای یک‌باره، یک فراخوانی CLI، یا شناسهٔ فضایی از فضای کاری دیگر که به‌سادگی در فایل پایگاه‌دادهٔ این فضای کاری نیست — به chat می‌رسد. تغییر حالت از نوبت بعد اثر می‌گذارد.
تضمین کجا واقعاً برقرار است
بخش با عنوان “تضمین کجا واقعاً برقرار است”سطح ابزار یک حالت توسط هارنس داخلی ساخته و اعمال می‌شود. این تنها بستر انتقالی است که می‌تواند یک ابزار را به‌جای صرفاً ردکردن، نامرئی کند، هر فراخوانی را پیش از اجرا دروازه‌گذاری کند و یک قرارداد تکمیل را رصد کند.
روی بستر انتقال Claude Code، یک حالت غیرگفتگو به‌شکل --permission-mode plan فرستاده می‌شود. Claude این را به‌عنوان یک قرارداد رعایت می‌کند؛ ابزارهای خواندن، نوشتن و ویرایش خودش بی‌آنکه دیده شوند اجرا می‌شوند و فرمان‌های شل فقط با یک هوک که خط فرمان را می‌خواند بررسی می‌شوند. برای آن بستر انتقال، حالت فقط یک راهنماست و نه مرز Control Center — مدل عامل را ببینید.
فهرست‌های مجاز، ابزارهای ردهٔ نوشتن و بالاتر را محدود می‌کنند. ردهٔ خواندنِ هارنس داخلی همچنان به ابزارهایی می‌رسد که هیچ فهرستی نامشان را نمی‌برد؛ در Claude Code، ابزاری که فهرست مجاز حذفش کرده باشد، رد می‌شود — چه سرور آن را داشته باشد و چه نداشته باشد.
مفاهیم مرتبط
بخش با عنوان “مفاهیم مرتبط”- چرخهٔ عمر اعزام عامل: جایی که حالت تعیین و بر لایه‌ها اعمال می‌شود
- مدل عامل: کدام بسترهای انتقال می‌توانند یک حالت را اعمال کنند
- گاردریل‌ها: سیاست کلاس‌های اثری که پیش‌تنظیم یک حالت به آن تغذیه می‌شود
- ارکستراسیون: یک پیشنهاد ارکسترِ تأییدشده چه می‌کند
- استفاده از حالت برنامه: راهنمای عملی گام‌به‌گام