آموزش جامع دستور /goal در Agentic Coding: راهنمای کامل + کدام ابزارها از آن پشتیبانی می‌کنند؟

اگه این روزها با ابزارهای کدنویسی عامل‌محور کار می‌کنی، حتماً این صحنه برات آشناست: یه پرامپت میدی، صبر می‌کنی، جوابو نگاه می‌کنی، یه پرامپت دیگه میدی، دوباره صبر می‌کنی. برای یه سوال ساده یا یه تغییر کوچیک، اوکیه. ولی وقتی وسط یه مهاجرت ماژولی، یه بهینه‌سازی کارایی، یا یه ریفکتور چندفایلی باشی، واقعاً کلافه‌کننده میشه. دستور /goal دقیقاً برای شکستن همین چرخه اومده. تو یه نتیجه نهایی تعریف می‌کنی و عامل هوش مصنوعی خودش، نوبت به نوبت، تا رسیدن به اون نتیجه کار می‌کنه. بدون اینکه لازم باشه بعد از هر مرحله دوباره چیزی تایپ کنی.

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

فهرست مطالب

۱. Agentic Coding چیه و /goal کجای این داستان قرار می‌گیره
۲. دستور /goal دقیقاً چه کار می‌کنه؟
۳. فرق /goal با پرامپت‌نویسی معمولی
۴. معماری فنی: پشت صحنه /goal چه خبره؟
۵. آموزش گام به گام استفاده از /goal در Claude Code
۶. نوشتن یه شرط تکمیل که واقعاً کار کنه
۷. فایل goal.md چیه و چرا بهتره داشته باشیش
۸. کدوم ابزارها از /goal پشتیبانی می‌کنن؟ (مقایسه کامل)
۹. مهارت ممیزی: حلقه ایمنی که نباید بی‌خیالش بشی
۱۰. یه تجربه واقعی: ۱۵ ساعت اجرای بی‌وقفه
۱۱. کجا از /goal استفاده کنیم و کجا نه
۱۲. نکات ایمنی و نظارت انسانی
۱۳. سوالات متداول
۱۴. جمع‌بندی

۱. Agentic Coding چیه و /goal کجای این داستان قرار می‌گیره

Agentic Coding به اون دسته از ابزارهای برنامه‌نویسی هوش مصنوعی گفته میشه که فقط کد پیشنهاد نمیدن. اینا مستقیماً فایل‌ها رو می‌خونن، کد رو ویرایش می‌کنن، دستورات ترمینال و تست رو اجرا می‌کنن و بر اساس نتیجه‌ای که می‌گیرن، تصمیم بعدی رو خودشون می‌گیرن. Claude Code، OpenAI Codex، Cursor و Hermes Agent نمونه‌های شناخته‌شده این دسته‌ان.

مشکل اصلی نسخه‌های اولیه این ابزارها این بود که هر «نوبت» کاری با یه پاسخ تموم می‌شد. یعنی تو باید دوباره پرامپت میدادی تا کار ادامه پیدا کنه. برای سوال‌های کوتاه و تغییرات جزئی مشکلی نیست، ولی برای کارهایی که ذاتاً چندمرحله‌ای‌ان (مثلاً «این ماژول رو به API جدید مهاجرت بده و مطمئن شو همه تست‌ها پاس میشن») واقعاً دست و پا گیره.

دستور /goal این چرخه رو می‌شکنه. تو یه نتیجه نهایی تعریف می‌کنی و عامل هوش مصنوعی خودش تصمیم می‌گیره قدم بعدی چی باشه، اجرا می‌کنه، نتیجه رو بررسی می‌کنه، و اگه هنوز به هدف نرسیده، ادامه میده. همه اینا بدون اینکه تو وسط کار دخالت کنی.

توی تیم هرمس، ما این قابلیت رو یکی از مهم‌ترین تغییرات پارادایم در مهندسی هوش مصنوعی و کدنویسی عامل‌محور می‌دونیم: گذار از «پرامپت‌نویسی همزمان و پیوسته» به «تعریف نتیجه و برگشتن بعد از اتمام کار». این دقیقاً همون چیزیه که آموزش هوش مصنوعی مدرن باید روش تمرکز کنه، نه صرفاً یاد دادن نحوه نوشتن پرامپت.

۲. دستور /goal دقیقاً چه کار می‌کنه؟

به زبان ساده، /goal یه شرط تکمیل (Completion Condition) تعریف می‌کنه. بعد از هر نوبت کاری، یه مدل کوچیک و سریع بررسی می‌کنه که آیا اون شرط برقرار شده یا نه. اگه جواب «نه» باشه، عامل اصلی یه نوبت دیگه شروع می‌کنه. اگه «بله» باشه، هدف به‌طور خودکار پاک میشه و کار تموم تلقی میشه.

توی یه مقاله تحلیلی خوب، این ساختار به شکل یه «قرارداد تکمیل محدود به یه نشست» توصیف شده که از شش بخش تشکیل میشه:

نتیجه (Outcome): چی باید ته کار درست باشه.

سطح راستی‌آزمایی (Verification Surface): تست، بنچمارک یا مصنوعی که اثبات می‌کنه نتیجه محقق شده.

محدودیت‌ها (Constraints): چیزایی که نباید تو مسیر کار تغییر کنن.

مرزها (Boundaries): عامل به کدوم فایل‌ها و ابزارها اجازه دسترسی داره.

سیاست تکرار (Iteration Policy): عامل بعد از هر تلاش چطور تصمیم می‌گیره قدم بعدی چی باشه.

شرط توقف مسدود (Blocked Stop Condition): کِی عامل باید متوقف بشه و بگه مسیر منطقی دیگه‌ای باقی نمونده.

نکته جالب اینجاست که هر سه ابزار اصلی این مفهوم رو دارن، فقط اسم و پیاده‌سازیشون فرق می‌کنه. Codex بهش «قرارداد تکمیل» می‌گه، Claude Code «شرط تکمیل»، و Cursor اون رو تو قالب «توضیح وظیفه همراه با سقف عملیات» پیاده کرده. Hermes Agent هم با رویکرد متفاوتی که داره (حلقه یادگیری و مهارت‌سازی خودکار) عملاً همین مفهوم رو تو قالب Skillها و Memory پیاده می‌کنه.

۳. فرق /goal با پرامپت‌نویسی معمولی

شاید بپرسی خب مگه چه فرقی با یه پرامپت خوب داره؟ فرقش اینجاست:

یه نکته مهم که تو مستندات رسمی Claude Code هم اومده: /goal خودش مجوزهای اجرای دستورات رو تغییر نمیده. یعنی اگه تو حالت عادی Claude قبل از اجرای هر دستور ازت تأیید می‌خواد، با /goal هم همین‌طوره. برای اینکه کار واقعاً بدون توقف پیش بره، باید اون رو با Auto Mode ترکیب کنی.

تو مستندات رسمی یه مقایسه خوب بین سه روش مختلف برای نگه‌داشتن نشست فعال اومده:

پس /goal و /loop هر دو نشست رو فعال نگه می‌دارن، ولی منطقشون فرق داره. /goal شرط‌محوره (تا شرط برقرار نشده ادامه بده)، /loop زمان‌محوره (هر N دقیقه یه بار اجرا کن).

۴. معماری فنی: پشت صحنه /goal چه خبره؟

این بخش برای کسایی‌ه که می‌خوان بفهمن دقیقاً چه اتفاقی می‌افته. اگه فقط می‌خوای از /goal استفاده کنی، می‌تونی بری بخش بعدی.

بر اساس مستندات رسمی Claude Code، /goal در واقع یه پوسته ساده روی یه Stop Hook مبتنی بر پرامپت و محدود به همون نشسته. مکانیزم دقیقش اینه:

اول، Claude یه نوبت کاری رو تموم می‌کنه. دوم، شرط تکمیل به‌همراه کل مکالمه تا اون لحظه برای مدل ارزیاب فرستاده میشه (تو Claude Code پیش‌فرض این مدل Haiku هست). سوم، مدل ارزیاب فقط یه پاسخ بله یا خیر به همراه یه دلیل کوتاه برمی‌گردونه. خودش هیچ ابزاری اجرا نمی‌کنه و فقط بر اساس چیزی که تو مکالمه ظاهر شده قضاوت می‌کنه. چهارم، اگه پاسخ «خیر» باشه، همون دلیل به‌عنوان راهنما برای نوبت بعدی به Claude داده میشه. پنجم، اگه پاسخ «بله» باشه، هدف با وضعیت «محقق‌شده» بسته میشه.

یه نکته کلیدی که Claude Code رو از رقبا متمایز می‌کنه، «ممیزی مستقل» هست. وقتی Claude فکر می‌کنه به شرط تکمیل رسیده، خودش به‌تنهایی این رو اعلام نمی‌کنه. یه نشست کاملاً جداگانه Claude، بدون هیچ حافظه‌ای از استدلال‌های نشست اول، وضعیت نهایی مخزن کد رو بررسی می‌کنه تا مطمئن بشه هدف واقعاً محقق شده.

این با معماری Codex فرق داره. تو Codex، تکمیل هدف صرفاً بر مبنای «شواهد عینی» مثل خروجی تست یا بنچمارک تأیید میشه، بدون یه عامل ممیز دوم مجزا. خود مستندات OpenAI می‌گه: «یه Goal نباید صرفاً به این دلیل کامل علامت بخوره که مدل فکر می‌کنه احتمالاً کار تموم شده. باید فقط بعد از بررسی هدف در برابر شواهد ملموس (فایل‌های تغییریافته، تست‌های اجراشده، خروجی بنچمارک) کامل تلقی بشه.»

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

Hermes Agent از Nous Research هم مسیر متفاوتی رفته. این ابزار اصلاً یه IDE یا افزونه ادیتور نیست. یه عامل مستقله که روی زیرساخت خودش اجرا میشه (از یه VPS پنج دلاری تا کلاستر GPU) و از طریق کانال‌های مختلف مثل تلگرام، دیسکورد یا CLI باهاش تعامل می‌کنی. Hermes Agent به‌جای شرط تکمیل کلاسیک، از یه «حلقه یادگیری بسته» استفاده می‌کنه: از تجربه‌هاش مهارت می‌سازه، اون مهارت‌ها رو حین استفاده بهبود میده، و بین نشست‌ها حافظه داره. یعنی اگه یه بار یه کار خاص رو انجام بده، دفعه بعد بهتر و سریع‌تر انجامش میده. این رویکرد برای کارهای تکراری و بلندمدت جذابه، ولی برای یه بار اجرای یه هدف مشخص، مدل Claude Code و Codex مستقیم‌تره.

۵. آموزش گام به گام استفاده از /goal در Claude Code

طبق مستندات رسمی، /goal نیازمند Claude Code نسخه ۲.۱.۱۳۹ یا بالاتره و فقط تو پروژه‌هایی کار می‌کنه که دیالوگ اعتماد (Trust Dialog) اونا رو قبلاً تأیید کردی. دلیلش اینه که این قابلیت بخشی از سیستم Hooks هست و اگه disableAllHooks تو تنظیمات فعال باشه، /goal هم کار نمی‌کنه.

تعیین هدف

کافیه تو خط فرمان Claude Code بنویسی:

/goal همه تست‌های موجود در test/auth باید پاس شوند و مرحله lint هم بدون خطا باشد

با اجرای این دستور، بلافاصله یه نوبت کاری با همون شرط به‌عنوان دستور شروع میشه. نیازی به ارسال پرامپت جداگانه نیست. تو حین فعال بودن هدف، یه نشانگر ◎ /goal active مدت‌زمان اجرا رو نشون میده.

مشاهده وضعیت

با اجرای /goal بدون هیچ آرگومانی، وضعیت فعلی رو می‌بینی: خود شرط، مدت زمان اجرا، تعداد نوبت‌های ارزیابی‌شده، میزان توکن مصرفی، و آخرین دلیلی که مدل ارزیاب اعلام کرده.

پاک کردن هدف

/goal clear

این دستور هدف فعال رو قبل از رسیدن به شرط تکمیل حذف می‌کنه. کلمات stop، off، reset، none و cancel هم به‌عنوان مترادف برای clear پذیرفته میشن. اجرای /clear برای شروع مکالمه جدید هم هر هدف فعالی رو پاک می‌کنه.

اجرای غیرتعاملی (Headless)

/goal تو حالت غیرتعاملی، تو اپلیکیشن دسکتاپ و از طریق Remote Control هم کار می‌کنه:

claude -p "/goal تمام PRهای ادغام‌شده این هفته باید در CHANGELOG.md یک ردیف داشته باشند"

یه نکته عملی: تو خروجی متنی پیش‌فرض، تا رسیدن به شرط چیزی چاپ نمیشه. یعنی اگه هدف چندین نوبت طول بکشه، به نظر می‌رسه هیچ اتفاقی نمی‌افته. برای دیدن پیشرفت لحظه به لحظه باید از --output-format stream-json --verbose استفاده کنی.

ازسرگیری هدف بعد از توقف نشست

اگه نشستی با هدف فعال بسته بشه، با اجرای دوباره اون با --resume یا --continue، شرط هدف بازیابی میشه. اما شمارنده نوبت‌ها، زمان‌سنج و مبنای مصرف توکن از صفر شروع میشن. هدفی که قبلاً محقق یا پاک شده بازیابی نمیشه.

ترکیب با Auto Mode

همون‌طور که گفتیم، /goal به‌تنهایی مجوزها رو تغییر نمیده. اگه می‌خوای هدف واقعاً بدون توقف و بدون تأیید هر ابزار اجرا بشه، باید Auto Mode رو هم فعال کنی. Auto Mode تو Claude Code یه طبقه‌بند (Classifier) جداگانه داره که هر عملیات رو قبل از اجرا بررسی می‌کنه. عملیات‌های خطرناک مثل rm -rf /، دیپلوی production، یا force push رو مسدود می‌کنه و عملیات‌های امن مثل ویرایش فایل تو دایرکتوری کاری یا اجرای تست‌ها رو خودکار تأیید می‌کنه.

اگه طبقه‌بند سه بار پشت سر هم یا بیست بار تو مجموع یه عملیات رو مسدود کنه، Auto Mode موقتاً غیرفعال میشه و Claude Code به حالت تأیید دستی برمی‌گرده.

تو آموزش‌های مهندسی هوش مصنوعی هرمس، ما همیشه توصیه می‌کنیم قبل از فعال کردن Auto Mode برای یه هدف بزرگ، مطمئن بشی روی یه شاخه جدا کار می‌کنی و آخرین وضعیت رو کامیت کردی.

۶. نوشتن یه شرط تکمیل که واقعاً کار کنه

این بخش شاید مهم‌ترین بخش عملی مقاله باشه. طبق مستندات رسمی، مدل ارزیاب هیچ دستوری اجرا نمی‌کنه و هیچ فایلی مستقیماً نمی‌خونه. فقط چیزی رو که Claude تو طول مکالمه نشون داده قضاوت می‌کنه. پس شرط باید طوری نوشته بشه که خروجی خود Claude بتونه اون رو اثبات کنه.

یه شرط قوی معمولاً سه ویژگی داره:

یه نتیجه قابل سنجش. مثلاً نتیجه یه تست، کد خروج یه بیلد، یا تعداد فایل‌های باقی‌مانده. «کد بهتر بشه» یه نتیجه قابل سنجش نیست.

یه روش راستی‌آزمایی مشخص. مثلاً «npm test باید با کد ۰ خارج بشه» یا «git status باید clean باشه».

محدودیت‌های مهم. هرچیزی که تو مسیر رسیدن به هدف نباید تغییر کنه. مثلاً «هیچ فایل تست دیگه‌ای تغییر نکنه» یا «قرارداد API عمومی دست نخوره».

شرط می‌تونه تا ۴۰۰۰ کاراکتر طول داشته باشه. برای محدود کردن مدت اجرا، می‌تونی یه بند زمانی یا تعداد نوبت بهش اضافه کنی، مثلاً «یا بعد از ۲۰ نوبت متوقف شو».

مقاله تخصصی MindStudio هم روی همین اصل تأکید داره: هدف مبهم مثل «سیستم احراز هویت رو بهتر کن» نتیجه خوبی نمیده. اما نسخه دقیق مثل «منطق اعتبارسنجی توکن JWT تو فایل src/auth/validator.ts رو با کلاس TokenService جایگزین کن و مطمئن شو همه تست‌های موجود تو پوشه auth سبز باقی می‌مونن» مسیر روشنی برای عامل ترسیم می‌کنه.

تو مستندات Codex هم یه الگوی خوب پیشنهاد شده:

/goal <وضعیت نهایی مطلوب> که با <شواهد مشخص> تأیید شود، در حالی که <محدودیت‌ها> حفظ شوند.
از <ورودی‌ها، ابزارها یا مرزهای مجاز> استفاده کن. بین تکرارها، <نحوه انتخاب قدم بعدی>.
اگر مسدود شدی یا مسیر معتبری باقی نماند، <چه چیزی گزارش شود و چه چیزی قفل را باز می‌کند>.

مثلاً:

/goal تأخیر p95 در بنچمارک checkout را به زیر ۱۲۰ میلی‌ثانیه برسان، که با خروجی
بنچمارک تأیید شود، در حالی که مجموعه تست‌های صحت سبز بماند. فقط از سرویس checkout،
فیکسچرهای بنچمارک و تست‌های مرتبط استفاده کن. بین تکرارها، ثبت کن چه چیزی تغییر کرد،
بنچمارک چه نشان داد، و بهترین آزمایش بعدی چیست. اگر بنچمارک قابل اجرا نبود یا مسیر
معتبری باقی نماند، مسیرهای تلاش‌شده، شواهد جمع‌شده، مانع، و ورودی مورد نیاز برای
ادامه را گزارش کن.

یه ترفند عملی که تو تیم هرمس استفاده می‌کنیم: اگه مطمئن نیستی شرطت به اندازه کافی دقیق هست یا نه، از خود Claude یا Codex بخواه اون رو برات بنویسه. مثلاً:

کمکم کن این را به یک /goal قوی تبدیل کنم: می‌خواهم این تست ناپایدار checkout را
آنقدر بررسی کند تا یا با شواهد رفعش کند یا دقیقاً توضیح بدهد چه چیزی مانع است.

عامل یه پیش‌نویس Goal پیشنهاد میده، تو اون رو بررسی و دقیق‌تر می‌کنی، و بعد فعالش می‌کنی.

۷. فایل goal.md چیه و چرا بهتره داشته باشیش

هم Codex و هم Claude Code امکان خواندن هدف از یه فایل رو دارن، به‌جای تایپ مستقیم تو خط فرمان. قرارداد رایج اینه که این فایل با نام goal.md (یا goals/<feature>.md) تو ریپازیتوری نگه‌داری بشه.

چرا این کار مفیده؟ اول، هدفت تو کنترل نسخه قرار می‌گیره و تیم می‌تونه اون رو بازبینی کنه. دوم، برای اهداف پیچیده که از ۴۰۰۰ کاراکتر بیشترن، فضای کافی داری. سوم، ساختارمند میشه و هر شش بخش قرارداد تکمیل رو پوشش میده.

یه نمونه واقعی:

# Goal: کاهش تأخیر p95 به زیر ۱۲۰ میلی‌ثانیه

## Outcome
تأخیر p95 در بنچمارک checkout باید زیر ۱۲۰ میلی‌ثانیه باشد.

## Verification surface
دستور بنچمارک باید p95 زیر ۱۲۰ را گزارش کند.
مجموعه تست‌های صحت باید سبز بماند.
هیچ وابستگی جدیدی اضافه نشود.

## Constraints
قراردادهای API عمومی تغییر نکنند.
ساختار پایگاه‌داده تغییر نکند.

## Boundaries
مسیرهای مجاز: services/checkout/**, tests/checkout/**
مسیرهای ممنوع: shared/, billing/, db/migrations/

## Iteration policy
بعد از هر تغییر، بنچمارک اجرا و نتیجه ثبت شود.
قدم بعدی بر اساس همان نتیجه انتخاب شود.

## Blocked stop condition
اگر بنچمارک قابل اجرا نبود، یا سه تلاش پیاپی بهبودی نداد،
کار متوقف شود و گزارش کامل ارائه شود.

اهمیت این ساختار تو اینه که هدف دقیقاً همون کیفیتی رو داره که تو goal.md نوشته شده. نتیجه کم‌دقت، عاملی سرگردان می‌سازه و سیاست تکرار مبهم، رفتاری شبیه دستگاه شانس ایجاد می‌کنه.

۸. کدوم ابزارها از /goal پشتیبانی می‌کنن؟ (مقایسه کامل)

این بخشی‌ه که اغلب راهنماها بهش کم‌توجهی می‌کنن. با بررسی منابع رسمی و تحلیلی، وضعیت واقعی پشتیبانی به این شکله:

حالا بیایید هر کدوم رو دقیق‌تر نگاه کنیم.

Claude Code

تنها ابزاری‌ه که رسماً از خود نام دستور /goal استفاده می‌کنه و مستندات کاملش روی سایت رسمی Anthropic منتشر شده. اجرای طولانی‌مدتش وابسته به فعال بودن Auto Mode هست. نسخه مورد نیاز ۲.۱.۱۳۹ یا بالاتره که تو مه ۲۰۲۶ منتشر شد.

متمایزترین ویژگی Claude Code تو این زمینه، ممیزی مستقله. یعنی وقتی عامل اصلی فکر می‌کنه کار تموم شده، یه نشست کاملاً جداگانه (بدون حافظه از استدلال‌های نشست اول) وضعیت نهایی رو بررسی می‌کنه. این یه لایه ایمنی اضافی‌ه که هیچ ابزار دیگه‌ای به این شکل نداره.

OpenAI Codex

طبق مستندات رسمی OpenAI، Codex هم همون دستور /goal رو با چهار زیردستور (pause, resume, clear و مشاهده وضعیت) پیاده کرده. تفاوت اصلیش با Claude Code تو دو چیزه:

اول، تکمیل هدف صرفاً بر مبنای شواهد عینی تأیید میشه (خروجی تست، بنچمارک، دیف)، بدون یه عامل ممیز دوم. دوم، ادامه کار فقط تو «نقاط امن» اتفاق می‌افته: بعد از تموم شدن یه نوبت، وقتی کار دیگه‌ای تو انتظار نیست، وقتی ورودی کاربر تو صف نیست، و وقتی رشته خالیه. یعنی یه حلقه بی‌وقفه نیست، بلکه یه ادامه رویدادمحور و محافظه‌کارانه‌ست.

Codex همچنین یه سیستم بودجه‌بندی صریح داره. وقتی بودجه (تعداد نوبت یا توکن) تموم بشه، عامل کار اساسی رو متوقف می‌کنه، پیشرفت و موانع رو خلاصه می‌کنه، و قدم مفید بعدی رو مشخص می‌کنه. رسیدن به سقف بودجه با تکمیل هدف فرق داره.

نسخه مورد نیاز برای Goals تو Codex، ۰.۱۲۸.۰ یا بالاتره.

Cursor

Cursor اصلاً از نام /goal استفاده نمی‌کنه. معادلش Background Agents هست که روی یه ماشین مجازی ابری اجرا میشه (حتی اگه سیستمت خاموش باشه) و به‌جای ممیزی شواهد، صرفاً با یه سقف تعداد عملیات محدود میشه.

Background Agents تو Cursor یه رویکرد متفاوت داره: تو یه وظیفه تعریف می‌کنی، عامل روی یه VM ابری کلون‌شده از ریپازیتوریت کار می‌کنه، و تو نهایت یه Pull Request تحویل میده. این برای کارهایی که می‌خوای همزمان با کارهای دیگه اجرا بشن عالیه، ولی کنترل لحظه‌ای کمتری نسبت به Claude Code و Codex داری.

یه نکته عملی: کاربران Cursor گزارش دادن که Background Agents می‌تونه سهمیه مصرف رو خیلی سریع بسوزونه. پس اگه از طرح Pro استفاده می‌کنی، حواست به سقف مصرف باشه.

Hermes Agent (Nous Research)

Hermes Agent یه ابزار متفاوت تو این فضا‌ست. این ابزار ساخت Nous Research هست و اصلاً یه افزونه IDE یا یه CLI کدنویسی کلاسیک نیست. یه عامل مستقله که روی زیرساخت خودش اجرا میشه و از ۲۰ کانال مختلف (تلگرام، دیسکورد، Slack، CLI و…) قابل دسترسیه. برای آشنایی بیشتر با Hermes Agent و یادگیری کامل آن اینجا کلیک کنید.

رویکرد Hermes Agent به «ادامه کار تا رسیدن به هدف» با بقیه فرق داره. به‌جای یه شرط تکمیل صریح که بعد از هر نوبت بررسی بشه، از یه حلقه یادگیری بسته استفاده می‌کنه: از تجربه‌هاش مهارت (Skill) می‌سازه، اون مهارت‌ها رو حین استفاده بهبود میده، و بین نشست‌ها حافظه داره. یعنی اگه یه بار یه الگوی خاص رو حل کرد، دفعه بعد سریع‌تر و بهتر حلش می‌کنه.

برای کدنویسی، Hermes Agent می‌تونه فایل‌ها رو بخونه، ویرایش کنه، و کد رو اجرا کنه. همچنین از Context Files برای تغذیه فایل‌های پروژه به مکالمه پشتیبانی می‌کنه. ولی مدل «یه هدف مشخص رو تا انتها اجرا کن» به شکل Claude Code و Codex توش پیاده‌سازی نشده. بیشتر مناسب کارهای تکراری و بلندمدتیه که عامل با هر بار اجرا بهتر میشه.

تو دوره‌های آموزش هوش مصنوعی هرمس، ما Hermes Agent رو به‌عنوان مکمل ابزارهایی مثل Claude Code معرفی می‌کنیم، نه جایگزین اونا. برای یه بار اجرای یه هدف مشخص، Claude Code یا Codex مستقیم‌ترن. برای ساختن یه دستیار کدنویسی که با گذشت زمان بهتر میشه، Hermes Agent جذاب‌تره.

OpenCode و پروژه متن‌باز secemp9/goal

برای OpenCode و همچنین برای افزودن قابلیت‌های اضافی به Claude Code و Cursor، پروژه متن‌باز secemp9/goal تو گیت‌هاب یه پورت از معماری Goals تو Codex CLI ارائه میده. این پروژه از طریق یه سرور MCP نصب میشه:

claude mcp add goal -- uvx --from git+https://github.com/secemp9/goal.git goal-mcp

طبق مستندات این ریپازیتوری، تو Claude Code (با نصب کامل شامل Hook و Skill) قابلیت‌های زیر اضافه میشه:

نکته مهم این پروژه: «ادامه خودکار» (Auto-Continuation) فقط برای Claude Code فعاله، چون به سیستم Hook اون وابسته‌ست. کاربران Cursor و OpenCode فقط به ابزارهای MCP (get_goal, create_goal, update_goal) دسترسی دارن و باید خودشون به‌صورت دستی از عامل بخوان کار رو ادامه بده.

جمع‌بندی این بخش: اگه دنبال پیاده‌سازی رسمی و کاملی، Claude Code و Codex گزینه‌های اصلی‌ان. اگه از Cursor استفاده می‌کنی، معادل مفهومی‌اش Background Agents هست. اگه یه عامل مستقل و خودبهبود می‌خوای، Hermes Agent مسیر متفاوتی‌ه. و اگه روی OpenCode کار می‌کنی یا می‌خوای تجربه /goal رو به‌صورت غیررسمی به چند ابزار مختلف اضافه کنی، پروژه secemp9/goal مسیر عملی‌ه.

۹. مهارت ممیزی: حلقه ایمنی که نباید بی‌خیالش بشی

یکی از مهم‌ترین هشدارهایی که تو تحلیل‌های میدانی این ابزار دیده میشه اینه: اجرای /goal بدون یه مهارت ممیزی مستقل، ریسک بزرگی‌ه. وقتی یه هدف به‌صورت کاملاً خودکار اجرا میشه، هیچ انسانی تو حلقه نیست. و هر عامل تو زنجیره (پیاده‌ساز، بازبین، ممیز) به‌طور طبیعی تمایل داره با مرحله قبلی موافقت کنه، چون این کار سریع‌تر و «مفیدتر» به نظر می‌رسه. این یکی از خطاهای شناخته‌شده سیستم‌های چندعاملی‌ه که تو مهندسی هوش مصنوعی خیلی بهش پرداخته میشه.

راه‌حل پیشنهادی اینه که عامل ممیز یه «مهارت ممیزی مبتنی بر شواهد» بارگذاری کنه که اون رو مجبور می‌کنه:

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

Claude Code نسخه‌ای از این مکانیزم رو به‌صورت توکار داره (همون ممیزی مستقل توسط نشست دوم). اما Codex چنین چیزی رو رسماً نداره. بنابراین اگه از /goal تو Codex برای کاری فراتر از یه وظیفه کوچیک استفاده می‌کنی، باید خودت یه مهارت ممیزی بنویسی یا از پروژه‌هایی مثل secemp9/goal استفاده کنی که «Completion Audit» دارن.

تو Hermes Agent، این مسئله به شکل دیگه‌ای حل شده: چون عامل بین نشست‌ها حافظه داره و مهارت‌هاش رو بهبود میده، عملاً یه «خودممیزی تدریجی» داره. ولی این برای کارهای حساس یه‌باره کافی نیست و همچنان باید خروجی نهایی رو دستی بازبینی کنی.

۱۰. یه تجربه واقعی: ۱۵ ساعت اجرای بی‌وقفه

توی یه گزارش میدانی، یه توسعه‌دهنده یه هدف رو با شرطی نسبتاً باز روی یه پروژه بهینه‌سازی کارایی اجرا کرد و از عامل خواست که اگه بعد از تست‌های استرس هرگونه شکافی بین فازها پیدا کرد، اون رو هم بهبود بده. همین جمله باعث شد اجرا حدود ۱۵ ساعت بدون توقف ادامه پیدا کنه، چون تعبیر عامل از «بهبود هر شکافی» به معنای مجوز برای پیدا کردن مسائل جدید بی‌پایان بود.

نتیجه این اجرا حدود ۲۸ درصد از سهمیه هفتگی حساب اون توسعه‌دهنده رو مصرف کرد. با این حال، چون از قبل یه برنامه فازبندی‌شده و ورک‌تری‌های جدا برای هر فاز آماده بود، خسارت به شاخه اصلی پروژه محدود نشد و تو نهایت، مهارت ممیزی مبتنی بر شواهد تونست تغییرات رو تأیید کنه.

درس اصلی این تجربه: /goal بدون برنامه‌ریزی فازبندی‌شده، جداسازی ورک‌تری و یه مهارت ممیزی، می‌تونه بیشتر از فایده، ضرر ایجاد کنه. با این سه پیش‌نیاز، قابل استفاده‌ست اما همچنان هزینه‌بر. پس باید عمدی و هدفمند ازش استفاده کرد، نه به‌صورت اتفاقی.

این تجربه با داده‌های Gartner هم همخوانی داره: طبق تحلیل مارس ۲۰۲۶ گارتنر، مدل‌های عامل‌محور بین ۵ تا ۳۰ برابر بیشتر از یه چت‌بات معمولی توکن مصرف می‌کنن. پس یه اجرای ۱۵ ساعته /goal می‌تونه هزینه قابل توجهی داشته باشه.

۱۱. کجا از /goal استفاده کنیم و کجا نه

بر اساس مستندات رسمی Claude Code و تحلیل‌های میدانی، /goal برای کارهای زیر مناسبه:

مهاجرت یه ماژول به API جدید تا زمانی که همه فراخوانی‌ها کامپایل بشن و تست‌ها پاس بشن. پیاده‌سازی یه سند طراحی تا وقتی همه معیارهای پذیرش برقرار بشن. شکستن یه فایل بزرگ به ماژول‌های کوچیک‌تر تا زمانی که هرکدوم زیر یه سقف حجمی مشخص باشن. کار روی یه صف از ایشوهای برچسب‌خورده تا خالی‌شدن صف. بهینه‌سازی کارایی با معیارهای قابل‌سنجش (تأخیر، توان عملیاتی، حافظه). بررسی تست‌های ناپایدار (Flaky) که تکرار مشکل، خود گلوگاهه.

و برای موارد زیر توصیه نمیشه:

ویرایش‌های یه‌خطی یا سوال‌های ساده. یه پرامپت معمولی کافیه و /goal فقط سربار اضافه می‌کنه. اهداف مبهم مثل «این بخش رو بهتر کن». این یه هدف نیست، یه شانس‌آزمایی‌ه. کارهایی که می‌خوای هر تغییر رو قبل از اعمال بررسی کنی. چون اهداف به‌صورت خودکار اجرا میشن. کارهایی که هزینه خطا توشون بیشتر از هزینه جایگزینه، مثل رفع اشکال فوری روی محیط عملیاتی.

مستندات Codex هم همین رو می‌گه: «از Goal برای یه ویرایش یه‌خطی، یه توضیح ساده، یه بازبینی کوتاه کد، یا سوالی که یه جواب می‌خواد و بعد تموم، استفاده نکن.»

۱۲. نکات ایمنی و نظارت انسانی

چند اصل عملی برای استفاده ایمن از /goal که تو آموزش‌های مهندسی هوش مصنوعی هرمس هم روشون تأکید می‌کنیم:

همیشه از کنترل نسخه استفاده کن. قبل از شروع یه هدف بزرگ، روی یه شاخه جدا کار کن و وضعیت فعلی رو کامیت کن تا تو صورت نیاز بتونی کار رو برگردونی.

فرکانس توقف رو متناسب با ریسک تنظیم کن. برای کارهای حساس، سطح نظارت رو بالاتر ببر. مثلاً به‌جای اینکه بذاری ۲۰ نوبت یه‌سره اجرا بشه، هر ۵ نوبت یه بار وضعیت رو چک کن.

مراقب گسترش دامنه (Scope Creep) باش. عامل ممکنه یه اشکال مرتبط رو هم پیدا و اصلاح کنه. این همیشه بد نیست، اما باید عمدی باشه نه اتفاقی. اگه تو شرط تکمیل مرزها رو مشخص نکنی، عامل ممکنه به فایل‌هایی سر بزنه که نباید.

قبل از ادغام، مثل هر Pull Request دیگه‌ای بازبینی کن. خروجی خودکار به‌طور پیش‌فرض «آماده ادغام» نیست. حتی با ممیزی مستقل Claude Code، باز هم باید دیف نهایی رو بخونی.

از یه مهارت ممیزی مستقل استفاده کن. مخصوصاً وقتی ابزار مورد استفاده‌ات (مثل Codex) این قابلیت رو به‌صورت توکار نداره.

مراقب مصرف توکن باش. یه هدف باز می‌تونه ساعت‌ها اجرا بشه و سهمیه هفتگیت رو بسوزونه. همیشه یه سقف نوبت یا زمان تو شرط بذار. مثلاً «یا بعد از ۲۰ نوبت متوقف شو».

از Auto Mode آگاهانه استفاده کن. Auto Mode عملیات‌های خطرناک رو مسدود می‌کنه، ولی جایگزین بازبینی انسانی نیست. خود مستندات Anthropic می‌گه: «Auto Mode تعداد پرامپت‌های مجوز رو کم می‌کنه ولی ایمنی رو تضمین نمی‌کنه. برای کارهایی استفاده کن که جهت کلیشون رو اعتماد داری، نه به‌عنوان جایگزین بازبینی تو عملیات‌های حساس.»

۱۳. سوالات متداول

آیا دستور /goal فقط تو Claude Code وجود داره؟
نه. Codex هم رسماً همین نام دستور و زیردستورهای مشابه (pause, resume, clear) رو داره. Cursor از نام /goal استفاده نمی‌کنه اما معادل مفهومی‌اش رو با Background Agents پیاده کرده. Hermes Agent هم رویکرد متفاوتی با حلقه یادگیری و مهارت‌سازی داره.

آیا اجرای /goal به مجوزهای خاصی نیاز داره؟
بله. تو Claude Code، /goal فقط تو پروژه‌هایی کار می‌کنه که دیالوگ اعتمادشون تأیید شده باشه، و برای اجرای بی‌وقفه باید با Auto Mode ترکیب بشه. تو Codex، باید نسخه ۰.۱۲۸.۰ یا بالاتر رو داشته باشی.

چند تا هدف رو می‌شه همزمان فعال کرد؟
تو هر نشست فقط یه هدف می‌تونه فعال باشه. اگه هدف جدیدی تنظیم کنی، هدف قبلی جایگزین میشه.

آیا /goal برای کارهای غیرکدنویسی هم قابل استفاده‌ست؟
Claude Code و Codex عمدتاً برای کارهای توسعه نرم‌افزار طراحی شدن. البته مستندات Codex نشون میده که برای کارهای پژوهشی هم قابل استفاده‌ست، مثلاً بازتولید یه مقاله علمی با معیارهای شواهدمحور. برای جریان‌های کاری غیرکدنویسی، ابزارهایی مثل Hermes Agent (با پشتیبانی از ۲۰ کانال ارتباطی) یا پلتفرم‌های عامل بدون‌کد گزینه مناسب‌تری‌ان.

آیا می‌شه /goal رو روی OpenCode یا سایر ادیتورها استفاده کرد؟
به‌صورت رسمی نه، اما پروژه متن‌باز secemp9/goal این قابلیت رو از طریق یه سرور MCP به Claude Code، Cursor و OpenCode اضافه می‌کنه. با این تفاوت که ادامه خودکار فقط تو Claude Code فعاله.

هزینه اجرای /goal چقدره؟
توکن‌های ارزیابی (که توسط مدل کوچیک مثل Haiku مصرف میشن) معمولاً تو مقایسه با مصرف نوبت‌های اصلی ناچیزن. ولی خود نوبت‌های اصلی می‌تونن پرهزینه باشن. طبق تحلیل گارتنر، مدل‌های عامل‌محور ۵ تا ۳۰ برابر بیشتر از چت‌بات معمولی توکن مصرف می‌کنن.

۱۴. جمع‌بندی

دستور /goal نمایانگر یه تغییر مسیر جدی تو کدنویسی عامل‌محوره: از «پرامپت‌نویسی همزمان و پیوسته» به سمت «تعریف نتیجه و بازگشت بعد از اتمام کار». Claude Code این قابلیت رو با یه ممیزی مستقل توسط نشست دوم پیاده کرده. Codex اون رو با تمرکز بر شواهد عینی و مدیریت دقیق مصرف منابع ارائه داده. Cursor نسخه خودش رو با اجرای ابری و سقف تعداد عملیات ساخته. و Hermes Agent با حلقه یادگیری و مهارت‌سازی خودکار، مسیر متفاوتی رفته. برای ابزارهایی که هنوز این قابلیت رو به‌صورت رسمی ندارن، پروژه‌های متن‌باز مثل secemp9/goal می‌تونن پل ارتباطی باشن.

نکته پایانی و شاید مهم‌ترین توصیه عملی: هر هدفی که تعریف می‌کنی باید یه خط پایان قابل‌سنجش داشته باشه. اگه نتونی «تموم‌شدن» کار رو با معیاری مشخص و قابل‌اثبات تعریف کنی، اونچه نوشتی یه هدف نیست، صرفاً یه آرزوی بازه.

ما تو مرکز آموزش هوش مصنوعی هرمس، این مقاله رو به‌عنوان بخشی از مجموعه آموزش‌های مهندسی هوش مصنوعی و Agentic Coding منتشر کردیم. اگه سوال یا تجربه‌ای داری، خوشحال میشیم بشنویم.

منابع

• مستندات رسمی Claude Code درباره /goal: code.claude.com/docs/en/goal
• مستندات رسمی OpenAI، «Using Goals in Codex»: developers.openai.com/cookbook/examples/codex/using_goals_in_codex
• پروژه متن‌باز secemp9/goal در گیت‌هاب: github.com/secemp9/goal
• مستندات Hermes Agent، Nous Research: hermes-agent.nousresearch.com/docs
• تیم MindStudio، «What Is the /goal Command in Claude Code؟»: mindstudio.ai/blog/claude-code-goal-command-autonomous-tasks
• مستندات رسمی Claude Code درباره Permission Modes و Auto Mode: code.claude.com/docs/en/permission-modes
• تحلیل گارتنر، مارس ۲۰۲۶، درباره مصرف توکن مدل‌های عامل‌محور
• مستندات Hermes Agent، مسیر یادگیری: hermes-agent.nousresearch.com/docs/getting-started/learning-path