AGE Plan با مکانیزم «دروازه‌های بستار» جلوی توهم عامل‌های کدنویس را می‌گیرد

خطرناک‌ترین شکست در عامل‌های کدنویس خودمختار، فراموش کردن هدف نیست؛ بلکه این است که عامل با اطمینان دروغ بگوید وظیفه تمام شده است، در حالی که هنوز باگ‌های حیاتی در کد وجود دارد. این «خود-فریبی» (self-deception) هدف اصلی سیستم AGE (Attractor-Guided Engineering) است. این سیستم از یک مجموعه سخت‌گیرانه شامل ۲۴ قانون حداقلی استفاده می‌کند تا تضمین کند هرگاه یک عامل مرحله‌ای را «کامل» علامت زد، کد واقعاً کار کند.

تا تاریخ ۳۱ جولای ۲۰۲۶، تفاوت معماری میان AGE Plan و افزونه محبوب Planning-with-Files (PwF) برای Claude Code، دو فلسفه متفاوت در مدیریت عامل‌ها را آشکار می‌کند. در حالی که PwF مانند یک پروتز شناختی عمل می‌کند تا مانع از گم شدن عامل در وظایف طولانی شود، AGE Plan نقش یک حسابرس سخت‌گیر را ایفا می‌کند تا از میان‌بر زدن عامل‌ها جلوگیری کند.

تفاوت این دو را می‌توان این‌گونه تصور کرد: PwF شبیه مدیر پروژه‌ای است که هر ساعت ضرب‌الاجل‌ها را به شما یادآوری می‌کند، اما AGE Plan مانند سرپرست تضمین کیفیت (QA Lead) است که تا زمان مشاهده لاگ‌های اثبات‌شده که نشان دهد ویژگی مورد نظر واقعاً کار می‌کند، اجازه تایید نهایی را نمی‌دهد.

لایه مشخصات: حاکمیت در برابر زمینه

در سطح مشخصات، سیستم Planning-with-Files (که توسط OthmanAdi توسعه یافته و ریشه در فلسفه مهندسی زمینه Manus دارد) بر یک ساختار سه-فایلی تمرکز دارد: task_plan.md برای نقشه راه، findings.md برای پایگاه دانش و progress.md برای لاگ‌های نشست (session logs). این طراحی برای جلوگیری از دست رفتن «وضعیت» (state) عامل در فرآیندهای ناپایدار کدنویسی طولانی‌مدت است. PwF برای جامعیت طراحی شده و از ۱۷ محیط و IDE مختلف از جمله Cursor، Copilot، Gemini CLI، Kiro، Codex، Hermes، CodeBuddy، FactoryAI، Pi Agent، OpenCode، Continue، Mastra، OpenClaw، Antigravity، Kilocode و AdaL CLI پشتیبانی می‌کند. این رویکرد مکمل استراتژی‌هایی است که ابزارهایی مانند Cursor برای مدیریت حجم codebase به کار می‌برند تا با توزیع بار شناختی، توهمات کدنویسی را کاهش دهند.

در مقابل، AGE Plan یک specification متنی خالص است که توسط ۲۴ قانون حداقلی (موجود در مسیر docs/plans/00-plan-authoring-and-execution-guide.md) تعریف می‌شود. این سیستم نگران این نیست که آیا عامل هدف را به یاد دارد یا خیر، بلکه می‌پرسد «آیا قضاوت عامل درباره تکمیل کار، صادقانه است؟». AGE در مرزی از اعتماد عمل می‌کند که در آن، عامل مورد اعتماد است که فایل‌ها را به صورت مخربانه تغییر ندهد، اما مورد اعتماد نیست که خودش را حسابرسی کند.

مقایسه جهت‌گیری طراحی

برای درک این واگرایی، باید به دغدغه‌های محوری هر سیستم نگاه کرد:

• دغدغه اصلی: PwF می‌پرسد «آیا زمینه (context) هنوز موجود است؟»، در حالی که AGE Plan می‌پرسد «آیا تکمیل کار واقعی است؟».
• نگرش به عامل: PwF نگران قضاوت درباره تکمیل نیست بلکه از فراموشی می‌ترسد. AGE Plan به قضاوت‌های مربوط به تکمیل بی‌اعتماد است و بازبینی‌های حسابرسی مستقل را الزامی می‌کند.
• مرز اعتماد: AGE Plan اعتماد می‌کند که عامل فایل‌ها را مخربانه تغییر نمی‌دهد، اما اعتماد ندارد که عامل خود را بفریبد. PwF اعتماد ندارد که فایل‌های برنامه‌ریزی دستکاری نشوند و به همین دلیل از قفل‌گذاری SHA-256 استفاده می‌کند.
• وضعیت‌های برنامه: PwF از یک جریان ساده «در انتظار (pending) $\rightarrow$ در جریان (in_progress) $\rightarrow$ کامل (complete)» استفاده می‌کند. AGE Plan از یک مدل پیچیده‌تر ۹-حالته استفاده می‌کند که وضعیت‌هایی مانند proposed \ planned را شامل می‌شود.
• ابزارهای حاکمیتی: AGE از قانون ضد-تنبلی (Anti-Slacking)، آیتم‌های تخریب‌ناپذیر، مسیرهای شکست و لایه‌بندی استراتژی تست استفاده می‌کند. PwF بر قانون ۲-اقدام (2-Action Rule)، پروتکل خطای ۳-ضربه (3-Strike Error) و تست ری‌بوت ۵-سوالی متکی است.
• موازی‌سازی: PwF از ایزولاسیون دایرکتوری‌های .planning/<slug>/ به همراه متغیر محیطی PLAN_ID استفاده می‌کند. برنامه‌های AGE در مسیر docs/plans/ بدون ایزولاسیون سخت‌گیرانه در کنار هم قرار می‌گیرند.

دروازه‌های بستار و جنگ با خود-فریبی

یکی از disruptiveترین ویژگی‌های AGE Plan، پیاده‌سازی «دروازه‌های بستار» (Closure Gates) است. برخلاف معیارهای خروجی استاندارد، این‌ها چک‌لیست‌های بازرسی نهایی در سطح برنامه هستند که لایه‌ای مجزا از معیارهای خروجی (Exit Criteria) هر فاز تشکیل می‌دهند. این‌ها قضاوت‌های ضد-خود-فریبی هستند و نه صرفاً لیست کارهای انجام‌شده.

مثال‌هایی از معیارهای دروازه بستار شامل موارد زیر است:

• «هیچ نقص زنده در محدوده کار، به صورت مخفیانه به وضعیت deferred یا پیگیری بعدی تنزل نیافته باشد».
• «حسابرسی بستار توسط یک زیر-عامل مستقل تکمیل و شواهد آن ثبت شده باشد».
• «تمام انحرافات قراردادهای تایید شده در محدوده کار همگرا شده باشند».
• تایید نهایی از طریق اجرای: pnpm typecheck && pnpm build && pnpm lint && pnpm test.

در حالی که PwF از اسکریپتی به نام check-complete.sh برای شمارش اینکه آیا تعداد علامت‌های «کامل» (از جمله فرمت جایگزین [complete]) با تعداد رخورد‌های ### Phase برابر است یا خیر استفاده می‌کند، این بررسی صرفاً نحوی (syntactic) است. PwF عمداً از حسابرسی‌های معنایی (semantic) اجتناب می‌کند تا جامعیت بین پلتفرمی را حفظ کند؛ به این معنا که نمی‌تواند تفاوت بین «یک فاز که علامت کامل خورده» و «یک نقصی که واقعاً رفع شده» را تشخیص دهد. AGE Plan حسابرسی‌های معنایی را الزامی می‌کند. این سخت‌گیری در تایید نهایی، پاسخی به گلوگاه‌های برنامه‌ریزی است که ابزارهایی نظیر Planwright با اتوماسیون پذیرش کد سعی در رفع آن‌ها دارند.

پیاده‌سازی حسابرسی‌های مستقل

AGE Plan حکم می‌کند که پیاده‌کنندگان نمی‌توانند خود-حسابرسی کنند؛ یک نشست (session) جدید از زیر-عامل یا یک بازبین انسانی باید بسته را به طور مستقل تایید کند. این کار تضمین می‌کند که معناشناسی رفتاری محقق شود: کامپوننت‌های جدیداً اضافه شده باید در زمان اجرا فراخوانی شوند (نه اینکه فقط در imports حضور داشته باشند) و هیچ بدنه متد خالی یا پرش‌های خاموش پذیرفته نیست. هوک Stop در PwF فقط تعداد وضعیت‌های فاز را چک می‌کند بدون اینکه تشخیص دهد «چه کسی» حسابرسی را انجام داده است.

در لایه اتوماسیون، فایل check-plan-checklist.mjs در AGE Goal Driver این فرآیند را خودکار می‌کند. این ابزار تمام فایل‌های برنامه را اسکن می‌کند تا ببیند آیا برنامه‌های تکمیل شده دارای چک‌لیست‌های تیک‌نزده یا شواهد بستار (Closure Evidence) گم‌شده هستند یا خیر. این سیستم بین «شکست سخت» (تکمیل شده اما آیتم تیک‌نزده دارد) و «هشدار» (تکمیل نشده اما آیتم تیک‌نزده دارد) تفاوت قائل می‌شود.

تحمیل صداقت مهندسی

AGE Plan زبان عامل را از طریق «قانون ضد-تنبلی» محدود می‌کند. این قانون استفاده از عبارات مبهم مانند «اگر زمان اجازه دهد»، «بررسی شود»، «شاید» یا «خوب است داشته باشیم» را ممنوع می‌کند. هر آیتم در محدوده کار باید پیش از بستار در یکی از چهار وضعیت قطعی قرار گیرد: پیاده‌سازی شده (landed)، پذیرفته شده به عنوان ریسک باقی‌مانده (adjudicated as residual-risk-only)، منتقل شده به مالکیت صریح بعدی، یا حذف شده از محدوده از طریق یک تغییر ثبت‌شده.

آیتم‌های موجود در لیست «به تعویق افتاده اما پذیرفته شده» (Deferred But Adjudicated) باید سه فیلد خاص داشته باشند:

1. طبقه‌بندی (Classification): محدود به «فقط نظارتی باقی‌مانده»، «کاندید بهینه‌سازی» یا «بهبود خارج از محدوده».
2. چرا مانع بستار نیست (Why Not Blocking Closure): یک دلیل صریح.
3. نیازمند جانشین (Successor Required): بله/خیر.

آیتم‌های به تعویق افتاده بدون دلیل، به عنوان «ناقص» تلقی می‌شوند. وضعیت‌های PwF تنها اجازه انتقال pending $\rightarrow$ in_progress $\rightarrow$ complete را می‌دهند و هیچ وضعیت میانی برای تعویق پذیرفته شده ارائه نمی‌کنند.

آیتم‌های تخریب‌ناپذیر و مدیریت ریسک

برای جلوگیری از افت کیفیت، سیستم «آیتم‌های تخریب‌ناپذیر» (Non-Degradable Items) را تعریف می‌کند. این‌ها پنج دسته هستند: قوانین lint، نقص‌های زنده، انحراف قرارداد عمومی، انحراف مستندات مالک و تاییدیه متمرکز ضروری؛ این موارد هرگز نمی‌توانند به لیست «پیگیری‌های بعدی» منتقل شوند. هر آیتم اجرایی باید به عنوان Fix، Decision، Proof یا Follow-up تگ شود. نقص‌های زنده تایید شده فقط می‌توانند تگ «Fix» بگیرند.

سخت‌گیری‌های اضافی از طریق موارد زیر اعمال می‌شود:

• لایه‌بندی استراتژی تست: هر برنامه باید یک استراتژی متناسب با ریسک اعلام کند. قراردادهای Auth و APIهای خارجی نیازمند آیتم‌های «Proof» (اثبات) خودکار قبل از آیتم‌های «Fix» هستند؛ مستندات خالص ممکن است با دلیل «غیرقابل اعمال» اعلام شوند.
• مسیرهای شکست (Failure Paths): یک جدول الزامی که شرایط تحریک، رفتار مورد انتظار (شامل کدهای وضعیت)، قابلیت تلاش مجدد و عملکرد قابل مشاهده برای کاربر در مسیرهای ناموفق (unhappy paths) را مشخص می‌کند. این کار نویسندگان را مجبور می‌کند شکست‌ها را از ابتدا در نظر بگیرند، در حالی که PwF خطاها را فقط پس از وقوع در جدول «خطاهای مشاهده شده» ثبت می‌کند.
• پذیره‌داری خط‌پایه و مستندات (Baseline & Doc Adjudication): قبل از برنامه‌ریزی، عامل‌ها باید «حقایق تثبیت‌شده»، «حقایق تکمیل شده با مستندات ناهماهنگ» و «شکاف‌های واقعی باقی‌مانده» را لیست کنند. Baseline جایی است که عامل در حال حاضر قرار دارد و Goal جایی است که قرار است برود. همگام‌سازی مستندات بخشی از کار داخل فاز است، نه کاری برای زمان جمع‌بندی.

حفاظت تاریخی و تقسیم‌بندی

AGE Plan قوانین خاصی برای نگهداری برنامه‌ها دارد:

• قانون ۲۰ (حفاظت تاریخی): برنامه‌هایی که «کامل» علامت زده شده‌اند به عنوان سوابق تاریخی تلقی می‌شوند و به دلیل تکامل مشخصات یا کد، بازنویسی نمی‌شوند.
• قوانین ۲۱-۲۴ (ضد تقسیم‌بندی بیش از حد): برنامه‌ها نباید صرفاً به دلیل حجم فایل (مثلاً نزدیک شدن به ۳۰ کیلوبایت) یا تعداد زیاد یافته‌ها تقسیم شوند. یافته‌های مربوط به یک کامپوننت یا ماژول باید ادغام شوند. تقسیم‌بندی تنها زمانی اتفاق می‌افتد که معناشناسی بستار (closure semantics) واگرا شود.

لایه اتوماسیون: ماشین‌های وضعیت در مقابل هوک‌های IDE

وقتی این مشخصات خودکار می‌شوند، شکاف عمیق‌تر می‌شود. PwF بر یک سیستم هوک IDE متکی است — پنج تریگر خاص که برنامه را به طور خودکار به زمینه عامل تزریق می‌کنند:

• UserPromptSubmit: هر بار که کاربر پیامی می‌فرستد، محتوای برنامه را تزریق می‌کند.
• PreToolUse: قبل از ابزارهای Write/Edit/Bash/Read/Glob/Grep برنامه را بازمی‌خواند تا توجه عامل را تازه کند.
• PostToolUse: پس از عملیات Write/Edit به عامل یادآوری می‌کند که progress.md را بروز کند.
• Stop: از طریق check-complete.sh بررسی می‌کند آیا تمام فازها کامل شده‌اند.
• PreCompact: به عامل یادآوری می‌کند پیشرفت را تخلیه کند و Plan-SHA256 را چاپ می‌کند.

در مقابل، AGE Goal Driver (موتور اجرای اختیاری در مسیر nop-entropy/ai-dev/tools/opencode-goal-driver/) از یک ماشین وضعیت مستقل در Node.js استفاده می‌کند. این درایور یک ساختار حلقه دوگانه دارد:

۱. حلقه بیرونی (حسابرس-محور): بررسی سلامت $\rightarrow$ حسابرسی عمیق و بازبینی خصمانه $\rightarrow$ تشخیص مشکل. اگر مشکلی وجود داشته باشد، یک Draft Plan فعال می‌شود.
۲. حلقه داخلی (اجرا-محور): اجرای برنامه $\rightarrow$ حسابرسی بستار مستقل $\rightarrow$ در صورت نقص، استخراج REMAINING XML $\rightarrow$ ادامه اجرا $\rightarrow$ تایید ساخت (Build Verification) $\rightarrow$ بازگشت به حلقه بیرونی.

این درایور از پروتکل تگ‌های XML (مثل <AUDIT_RESULT>clean|issues</AUDIT_RESULT>) برای تجزیه برنامه‌ریزی شده انتقال‌ها استفاده می‌کند. اگر عامل تگی ارائه ندهد، سیستم یک لایه تجزیه خود-ترمیم‌شونده (extractTagOrAsk) را برای استنباط وضعیت گم‌شده از طریق یک فراخوان AI اضافی فعال می‌کند. این امر تضمین می‌کند که انتقال‌های وضعیت برنامه‌ریزی شده باشند و به خواندن Markdown توسط انسان وابسته نباشند.

امنیت و ایزولاسیون

PwF یک مدل امنیتی پیشرفته را برای جلوگیری از آلودگی برنامه اصلی توسط دستورات خصمانه (Adversarial Instructions) حاصل از جست‌وجوهای وب پیاده می‌کند. این مدل حکم می‌کند که محتوای خارجی فقط در findings.md نوشته شود و نه در task_plan.md. این مرز امنیتی از تقویت محتوای خصمانه در هر فراخوان ابزار جلوگیری می‌کند. PwF از دفاع دو لایه استفاده می‌کند:

• قاب‌بندی جداکننده (Delimiter Framing): محتوای تزریق شده در ===BEGIN PLAN DATA=== / ===END PLAN DATA=== قرار گرفته و به عنوان داده ساختاریافته علامت می‌خورد.
• گواهی SHA-256: یک مکانیسم اختیاری از طریق /plan-attest. اگر عدم تطبیق هش شناسایی شود، هوک‌ها تزریق را متوقف کرده و پیام [PLAN TAMPERED] را چاپ می‌کنند.

AGE Plan بر ایزولاسیون فرآیند تمرکز دارد. AGE Goal Driver برای هر گام فرآیند مجزایی ایجاد می‌کند؛ حسابرسی عمیق، بازبینی خصمانه، برنامه‌ریزی، اجرا و حسابرسی بستار همگی از نظر فیزیکی ایزوله هستند. عامل حسابرسی بستار هیچ زمینه‌ای (context) از فاز اجرا ندارد و باید مخزن کد زنده را دوباره بررسی کند. همچنین یک عامل Watchdog برای تشخیص و احتمالا کشتن فرآیندهای گیر‌کرده که از آستانه توقف (stall threshold) فراتر می‌روند، فعال می‌شود؛ تصمیم کشتن فرآیند توسط درایور اصلی گرفته نمی‌شود.

محدودیت‌های عملیاتی و بازیابی در PwF

PwF شامل گارد‌های عملیاتی خاصی برای حفظ یکپارچگی زمینه است:

• قانون ۲-اقدام: یافته‌ها باید بعد از هر دو عملیات جست‌وجو/مرور در findings.md نوشته شوند تا با نوسانات محتوای چندوجهی مقابله شود.
• تست ری‌بوت ۵-سوالی: یک خود-تست که می‌پرسد «کجای کار هستم، به کجا می‌روم، هدف چیست، چه آموخته‌ام و چه کرده‌ام» تا یکپارچگی را تایید کند.
• پروتکل خطای ۳-ضربه: یک مسیر تصاعدی برای تلاش مجدد: تلاش ۱ (تشخیص/رفع) $\rightarrow$ تلاش ۲ (تغییر رویکرد — ممنوعیت تکرار) $\rightarrow$ تلاش ۳ (بازاندیشی) $\rightarrow$ ارجاع به کاربر.
• Session Catchup: اسکریپت session-catchup.py تاریخچه گفتگو را از ذخیره نشست IDE بعد از /clear یا ریست بازیابی کرده و یک گزارش به‌روزرسانی ایجاد می‌کند.
• ایزولاسیون وظایف موازی: هر وظیفه در .planning/YYYY-MM-DD-slug/ با فایل‌های خودش ایزوله شده و توسط init-session.sh و set-active-plan.sh با استفاده از متغیر محیطی PLAN_ID مدیریت می‌شود.
• یکپارچگی حلقه Turn: استفاده از /plan-loop 10m برای تیک زدن خودکار هر ۱۰ دقیقه (بازخوانی برنامه، اجرای check-complete و نوشتن پیشرفت) و /plan-goal برای استخراج شرایط پایان.

آینده برنامه‌ریزی عامل‌ها

تحلیل‌ها نشان می‌دهد که با گسترش پنجره‌های زمینه (context windows) در LLMها، مشکلاتی که PwF حل می‌کند — مانند گم شدن حافظه و رانش زمینه — احتمالاً به ویژگی‌های بومی محیط اجرای مدل تبدیل خواهند شد. «قانون ۲-اقدام» و بازیابی نشست در نهایت غیرضروری می‌شوند زیرا این قابلیت‌ها در زیرساخت‌های زمان اجرای عامل تثبیت می‌شوند. با این حال، مدل امنیتی PwF به عنوان یک مسئله مهندسی امنیت، فارغ از قدرت مدل، همچنان مرتبط خواهد بود.

اما مشکل قضاوت مهندسی — یعنی صداقت و سخت‌گیری — تنها تشدید خواهد شد. یک عامل قدرتمندتر می‌تواند کد را سریع‌تر بازسازی (refactor) کند، اما می‌تواند انحراف قراردادها را موثرتر پنهان کند. تغییر از «امید به اینکه عامل پیروی کند» به «دستورات تحمیل‌شده توسط سیستم»، همان‌طور که در AGE Goal Driver دیده می‌شود، مسیر ماندگار برای مهندسی پیچیده AI است.

سنتز دو رویکرد

AGE Plan و PwF ترکیب‌پذیر نیستند زیرا به سوالات متفاوتی پاسخ می‌دهند. ساختار سه-فایلی یکپارچه PwF دقیقاً برای خدمت به تزریق هوک‌ها و ایزولاسیون امنیتی طراحی شده، به این معنا که نمی‌توان آن را به طور جزئی روی AGE Plan پیوند زد. با این حال، یک ادغام آینده می‌تواند شاهد وام‌گیری AGE Plan از مفهوم مکانیسم هوک برای اجرای خودکار باشد؛ مثلاً بازخوانی خودکار برنامه قبل از فراخوان‌های حساس ابزار یا فعال‌سازی چک‌های معیارهای خروجی پس از تکمیل هر فاز.

تکامل واقعی در ترکیب این رویکردهاست: بهره‌گیری از معناشناسی حاکمیتی AGE Plan، اجباری کردن آن توسط Goal Driver و زمان‌بندی تحریک توسط مکانیسم هوک. این امر راهکاری کامل ایجاد می‌کند که در آن قوانین تعریف می‌شوند و سپس به صورت سیستمی تضمین می‌گردند که اجرا شوند.

گام بعدی شما

• اگر از عامل‌های کدنویسی در پروژه‌های بزرگ استفاده می‌کنید، معیارهای خروجی را از «لیست کارهای انجام شده» به «شواهد اثباتی» تغییر دهید.
• برای کاهش توهم مدل، یک «عامل حسابرس» مجزا تعریف کنید که دسترسی به تاریخچه تصمیمات عامل اجراکننده نداشته باشد.
• عبارات مبهم در برنامه‌ریزی AI را حذف کرده و مدل را مجبور به تعیین وضعیت قطعی (Landed/Removed) کنید.

اما بررسی اینکه این سیستم‌های سخت‌گیرانه چه تاثیری بر سرعت توسعه در مقیاس بزرگ دارند، نیازمند تحلیل داده‌های عملیاتی است — به گزارش ما درباره نرخ بهره‌وری در تیم‌های AI-Native مراجعه کنید.