«یکی برای پاک کردن یک اشتباه و دیگری برای به پایان رساندن یک فکر ناقص.» این توصیف دقیق از قابلیت دستورات دوگانه است که از ۲۴ اوت ۲۰۲۶ در اختیار توسعهدهندگان SolonCode قرار گرفته است. با جداسازی این دو اقدام، SolonCode رایجترین نقاط اصطکاک در گردشهای کاری عاملمحور (Agentic Workflows) را حل میکند: منطق نادرست و توقف زودهنگام.
بسیاری از رابطهای کاربری هوش مصنوعی، گزینه «تلاش مجدد» (Retry) را به عنوان یک درخواست کلی برای دریافت یک پاسخ جدید در نظر میگیرند. این رویکرد اغلب کاربران را مجبور میکند بین از دست دادن پاسخی که تا حد زیادی درست است یا ارسال دستی پرامپتهایی مانند «ادامه بده» (Keep going) یکی را انتخاب کنند؛ اتفاقی که میتواند منجر به انحراف زمینه (Context Drift) در گفتگو شود. SolonCode این مشکل را با تقسیم فرآیند بازیابی به دو دستور مجزا در بکاند حل کرده است: /rerun و /continue.
تصور کنید در حال انتقال یک سرویس قدیمی جاوا به یک فریمورک مدرن هستید. اگر هوش مصنوعی الگویی را پیشنهاد دهد که معماری شما را میشکند، شما نمیخواهید روی آن اشتباه «ادامه» دهید؛ بلکه میخواهید آن را حذف کرده و دوباره تلاش کنید. در مقابل، اگر هوش مصنوعی ۹۰٪ کد را بنویسد اما به دلیل محدودیت توکنها متوقف شود، منطقی نیست که آن ۹۰٪ بینقص را دوباره تولید کنید تا فقط ۱۰٪ باقیمانده را دریافت کنید.
زمینه: رابط کاربری (User Interface)
در رابط کاربری وب SolonCode، هر ردیف از پاسخهای هوش مصنوعی دارای چهار آیکون عملیاتی در سمت راست است. در حالی که گزینه Copy محتوا را به کلیپبورد منتقل میکند و Delete پاسخ جاری و هر آنچه بعد از آن آمده است را حذف میکند، دکمههای Re-run و Continue ابزارهای اصلی برای هدایت عامل (Agent) هستند.
این دو دکمه ظاهر مشابهی دارند و در یک نوار ابزار قرار گرفتهاند، اما در لایههای زیرین، منطقهای بنیادین متفاوتی را فعال میکنند. Re-run با یک فلش چرخان (循环箭头) نمایش داده میشود، در حالی که Continue از آیکون جلو رفتن سریع (快进) استفاده میکند. در پیکربندی i18n (بومیسازی) سیستم، این دو به ترتیب به کلیدهای msg.rerun و msg.continue متصل شدهاند.
مکانیسم Re-run: اولویت با صحت (Correctness)
وقتی کاربر روی آیکون Re-run کلیک میکند، سیستم دستور RerunCommand را فراخوانی میکند (org.noear.solon.codecli.command.builtin.RerunCommand). طبق تحلیلهای فنی، این دستور یک پاکسازی تخریبی در تاریخچه جلسه انجام میدهد تا یک «صفحه سفید» و پاک ایجاد کند:
- پاکسازی جلسه (Session Cleanup): موتور سیستم در لیست پیامهای جلسه به عقب حرکت میکند تا زمانی که به یک
UserMessageبرسد. سپس با استفاده از یک حلقه از دستورsession.removeLatestMessage(1)، آن پیام کاربر و هر آنچه بعد از آن آمده است را از جلسه حذف میکند. - اجرای تکلیف (Task Execution): پس از پاک شدن تاریخچه، سیستم متد
ctx.runAgentTask(lastUserInput, null)را فراخوانی میکند. این کار باعث میشود دقیقاً همان ورودی قبلی، اما بدون بارِ (Baggage) تلاشهای شکستخورده قبلی، دوباره اجرا شود. - همگامسازی DOM: در سمت فرانتاند، رابط کاربری وب تمام المانهایی را که دارای
data-run-idیکسان هستند — شامل حباب پاسخ هوش مصنوعی، کارتهای ابزار (Tool Cards) و بلوکهای تفکر (Thinking Blocks) — شناسایی و از DOM حذف میکند. این امر تضمین میکند که پاسخ جدید در یک حباب تازه و بدون بقایای تلاش ناموفق رندر شود.
چه زمانی از Re-run استفاده کنیم؟
- زمانی که آخرین پاسخ عامل اساساً غلط است و میخواهید با همان پرامپت دوباره تلاش کنید.
- زمانی که عامل در میانه پاسخ مسیر اشتباهی را در پیش گرفته و میخواهید مسیر متفاوتی را انتخاب کند.
- زمانی که میخواهید تست کنید آیا یک مدل متفاوت یا یک پرامپت سیستمی دیگر، نتیجه بهتری برای همان ورودی تولید میکند یا خیر.
مکانیسم Continue: اولویت با کامل بودن (Completeness)
در مقابل، دکمه Continue دستور ContinueCommand را اجرا میکند (org.noear.solon.codecli.command.builtin.ContinueCommand). این دستور برخلاف قبلی، تاریخچه را حذف نمیکند؛ بلکه ردپای اجرای داخلی عامل، بهویژه ReActTrace ذخیره شده در کانتکست __main را دستکاری میکند:
- بازنشانی ردپا (Trace Reset): سیستم بررسی میکند که آیا مسیر فعلی ردپا برابر با
Agent.ID_ENDاست یا خیر (به این معنی که عامل به گره پاسخ نهایی رسیده است). اگر چنین باشد، مسیر را بهReActAgent.ID_REASONبازمیگرداند و عامل را دوباره به حالت «تفکر» میبرد. - مدیریت حافظه (Memory Management): پاسخ نهایی از طریق
trace.setFinalAnswer(null, false)پاک میشود. همچنین آخرین پیام دستیار از هر دو بخش حافظه کاری و جلسه حذف میشود تا از تکرار محتوا جلوگیری شود. - ازسرگیری (Resumption): سپس دستور
ctx.runAgentTask(null, null)فراخوانی میشود که به عامل اجازه میدهد دقیقاً از همان نقطهای که در زنجیره استدلال متوقف شده بود، ادامه دهد.
از آنجایی که پارامتر removeRow در رابط کاربری وب روی مقدار false تنظیم شده است، حباب پاسخ موجود باقی میماند. محتوای جدید بهسادگی در همان حباب جاری جاری (Stream) میشود و یک گسترش بیوقفه از فکر قبلی ایجاد میکند.
چه زمانی از Continue استفاده کنیم؟
- زمانی که عامل در میانه یک تکلیف متوقف شده است (مثلاً ۳ فایل از ۱۲ فایل را بازنویسی کرده) و میخواهید ادامه دهد.
- زمانی که پاسخ آخر تا حد زیادی درست اما ناقص بوده است.
- زمانی که میخواهید پاسخ به جای یک تولید مجدد، مانند یک ادامه طبیعی به نظر برسد.
مقایسه فنی در یک نگاه
| ویژگی | Re-run (/rerun) |
Continue (/continue) |
|---|---|---|
| پاسخ قدیمی | کاملاً حذف میشود | حفظ شده و به آن افزوده میشود |
| تاریخچه جلسه | پس از آخرین پرامپت کاربر پاک میشود | کاملاً حفظ میگردد |
| وضعیت عامل | شروع مجدد (Fresh Start) | ازسرگیری زنجیره استدلال |
| هدف اصلی | اصلاح صحت (Correctness) | اصلاح کامل بودن (Completeness) |
| آیکون وب | فلش چرخان (循环箭头) | جلو رفتن سریع (快进) |
| کلید i18n | msg.rerun |
msg.continue |
| برچسب چینی | 重新运行 | 继续运行 |
مثالهای عینی در گردش کار
درخواستی را در نظر بگیرید: «سرویس UserService را از Spring Data JPA به Solon Data منتقل کن».
- سناریوی الف (منطق غلط): عامل پاسخی تولید میکند که از API اشتباه Solon Data استفاده کرده است. با کلیک روی Re-run، پاسخ قدیمی ناپدید میشود؛ عامل دوباره فکر میکند و یک انتقال صحیح تولید میکند. اکنون تاریخچه فقط شامل نسخه اصلاحشده است.
- سناریوی ب (تکلیف ناقص): عامل متد
findUserByIdرا منتقل میکند اما قبل از رسیدن بهfindByEmailمتوقف میشود. با کلیک روی Continue، حباب پاسخ دستنخورده میماند و عامل صرفاً منطقfindByEmailرا به انتهای آن اضافه میکند. - سناریوی ج (اصلاح ترکیبی): عامل یک انوتیشن غیرضروری
@Componentاضافه میکند (توهم). کاربر روی Re-run کلیک میکند تا منطق اصلاح شود. پس از رسیدن پاسخ جدید، کاربر متوجه میشود کهdeleteByIdهنوز غایب است، بنابراین روی Continue کلیک میکند تا آن را اضافه کند.
دسترسی به دستورات و یکپارچگی
این دستورات محدود به رابط کاربری وب نیستند. از نسخه ۲۰۲۶.۴.۲۸، اینها به عنوان دستورات داخلی (Built-in) در تمام حالتهای تعامل ثبت شدهاند:
- CLI: کاربران میتوانند مستقیماً در ترمینال
/rerunیا/continueرا تایپ کنند. - کانالهای پیامرسان (IM): در Feishu، DingTalk یا WeChat، ارسال این دستورات باعث میشود بات درخواست را به موتور سیستم ارجاع دهد.
- رابط کاربری وب: از طریق آیکونهای حباب پاسخ فعال میشوند.
از آنجایی که این دستورات با علامت cliOnly() مشخص نشدهاند، در نقطه انتهایی (Endpoint) /web/chat/hints ظاهر میشوند و تجربه یکسانی را در تمام کانالها تضمین میکنند.
تحلیل تحریریه
این تفکیک معماری نشاندهنده درک بالغتری از نیاز به «انسان در حلقه» (Human-in-the-Loop یا HITL) برای عاملهای کدنویسی است. SolonCode با آشکار کردن تفاوت بین «بازنشانی وضعیت» (State Reset) و «ازسرگیری وضعیت» (State Resumption)، «مالیات پرامپت» — یعنی زمانی که توسعهدهندگان صرف متقاعد کردن هوش مصنوعی برای بازگشت به مسیر درست میکنند — را کاهش میدهد. این رویکرد به نوعی مکمل سیستمهای پیشرفتهتری است که مانند حلقه ترمیم TormentNexus سعی در کاهش زمان رفع باگها از طریق خودکارسازی فرآیندهای اصلاحی دارند.
برای کاربر نهایی، این به معنای توکنهای کمتر تلف شده و ناامیدی کمتر است. توانایی حذف جراحیشدهی یک مسیر استدلالی شکستخورده در حالی که پرامپت دستنخورده باقی میماند، یک پیروزی بزرگ در تجربه کاربری (UX) نسبت به دکمه استاندارد «تولید مجدد» (Regenerate) است که در اکثر پوششهای LLM یافت میشود. این موضوع در راستای بحثهای جاری پیرامون تکامل عاملهای خود-بهبودبخش است که پتانسیل حذف نیاز به ابزارهای سنتی را دارند.
این رویکرد، عامل را از یک تولیدکننده جعبه-سیاه به یک ابزار هدایتپذیر تبدیل میکند. این معماری میپذیرد که شکست هوش مصنوعی دوتایی نیست؛ بلکه یا شکستی در «جهت» است (که نیاز به Re-run دارد) یا شکستی در «استقامت» (که نیاز به Continue دارد).
SolonCode یک عامل کدنویسی متنباز است که بر پایه Solon AI و جاوا ساخته شده و از حالتهای تعامل CLI، وب، دسکتاپ و ACP تحت لایسنسهای Apache 2.0 / MIT پشتیبانی میکند. برای مشاهده این دستورات در عمل، توسعهدهندگان میتوانند سینتکس /rerun و /continue را مستقیماً در SolonCode CLI تست کنند تا نحوه دستکاری تاریخچه جلسه را در لحظه مشاهده نمایند.
گفتگو