Rovo Long Horizon چیست؟ بررسی نسل جدید استدلال هوش مصنوعی در Jira و Confluence
تا همین چند وقت پیش، بسیاری از کاربران از هوش مصنوعی برای کارهایی مثل خلاصهسازی یک Issue، پیدا کردن یک صفحه در Confluence یا پاسخ به یک سؤال مشخص استفاده میکردند. اما وقتی سؤال به چند مرحله، چند منبع اطلاعاتی و چند تصمیم پشت سر هم نیاز داشت، محدودیتهای معماریهای قدیمی بیشتر خودش را نشان میداد.

برای مثال، تصور کنید از Rovo بخواهید:
«Bugهای مهم سه ماه گذشته را بررسی کن، آنها را با Incidentهای مرتبط مقایسه کن، مستندات Confluence را بخوان، روندهای تکرارشونده را پیدا کن و در نهایت پیشنهاد بدهیم چه اقداماتی برای کاهش این مشکلات انجام دهیم.»
این دیگر یک سؤال ساده نیست. Rovo باید اطلاعات را از چند منبع پیدا کند، ارتباط میان آنها را بفهمد، نتایج اولیه را ارزیابی کند، در صورت نیاز دوباره جستوجو کند و در نهایت همه یافتهها را کنار هم قرار دهد.
Rovo Long Horizon دقیقاً برای چنین سناریوهایی طراحی شده است.
Atlassian در ژوئن و ژوئیه ۲۰۲۶ معماری جدید Long Horizon را معرفی کرد؛ معماریای که Rovo را از یک سیستم مبتنی بر مسیریابی میان چند Agent تخصصی، به یک موتور استدلال چندمرحلهای تبدیل میکند که میتواند Context و نتایج ابزارها را در یک فرآیند پیوسته حفظ و بررسی کند.
Rovo Long Horizon چیست؟
Long Horizon موتور استدلال جدید Rovo Chat برای انجام درخواستهای پیچیده و چندمرحلهای است.
در معماری جدید، Rovo بهجای اینکه یک درخواست را بین چند Agent تخصصی جابهجا کند، تلاش میکند یک Context یکپارچه را در اختیار مدل قرار دهد تا مدل بتواند در یک حلقه مستمر:
برنامهریزی → استفاده از ابزار → مشاهده نتیجه → ارزیابی → ادامه کار یا پاسخ
را انجام دهد.
Atlassian این معماری را با سه مفهوم اصلی توضیح میدهد:
- یک مدل
- یک Context
- یک حلقه استدلال تکرارشونده
در نتیجه، Rovo میتواند در طول انجام یک کار پیچیده، اطلاعاتی را که در مراحل قبلی به دست آورده حفظ کند و براساس همان اطلاعات تصمیم بگیرد قدم بعدی چه باشد.
نام Long Horizon نیز به همین موضوع اشاره دارد. در سیستمهای Agentic، Horizon به میزان توانایی Agent برای برنامهریزی و اجرای یک کار در چند مرحله اشاره میکند. Long Horizon این افق را برای Rovo طولانیتر میکند تا Agent بتواند کارهای پیچیدهتری را بدون از دست دادن Context دنبال کند.
چرا Atlassian به Long Horizon نیاز داشت؟
برای درک اهمیت این قابلیت، باید معماری قبلی Rovo را بشناسیم.
در نسل قبلی Rovo، Atlassian از یک معماری Multi-Agent و سپس Hybrid Orchestrator استفاده میکرد. در این مدل، برای مثال یک Agent روی Jira، یک Agent روی Confluence و Agent دیگری روی Slack تمرکز داشت.
وقتی کاربر یک سؤال ساده میپرسید، این معماری عملکرد مناسبی داشت.
مثلاً:
«وضعیت Issue PROJ-123 چیست؟»
Rovo میتوانست درخواست را به Agent مناسب ارسال کند، اطلاعات را دریافت کند و پاسخ دهد.
اما وقتی درخواست به چند محصول مربوط میشد، شرایط تغییر میکرد.
فرض کنید کاربر میپرسید:
«Bugهایی که تیم ما ماه گذشته ثبت کرده پیدا کن و براساس بحثهای Slack و مستندات Confluence توضیح بده چرا این مشکلات تکرار شدهاند.»
در این حالت، سیستم باید بین چند Agent جابهجا میشد. هر Agent Context خودش را داشت و نتیجه را به Agent یا Orchestrator دیگری تحویل میداد.
این جابهجایی میتوانست باعث از دست رفتن بخشی از Context شود.
Atlassian توضیح میدهد که معماری قبلی برای مدلهای زبانی نسل قبلی منطقی بود؛ زیرا آن مدلها در مدیریت Contextهای بزرگ و تعداد زیاد ابزارها محدودیت بیشتری داشتند. اما مدلهای جدیدتر توانایی بیشتری در مدیریت Context، برنامهریزی و استفاده از ابزارها پیدا کردهاند. بنابراین معماری قدیمی دیگر نمیتوانست بهخوبی از این تواناییها استفاده کند.
Long Horizon چه مشکلی را حل میکند؟
مسئله اصلی فقط «هوشمندتر شدن Rovo» نیست.
Long Horizon تلاش میکند نحوه فکر کردن Rovo هنگام انجام یک کار پیچیده را تغییر دهد.
در معماری جدید، Rovo میتواند:
- درخواست کاربر را بررسی کند.
- مشخص کند برای پاسخ چه اطلاعاتی نیاز دارد.
- ابزار مناسب را انتخاب کند.
- اطلاعات را از Jira، Confluence، Slack یا سایر منابع دریافت کند.
- نتیجه را بررسی کند.
- اگر اطلاعات کافی نبود، دوباره جستوجو کند.
- نتایج مختلف را با هم مقایسه کند.
- در نهایت پاسخ را ارائه دهد.
این فرآیند میتواند چندین بار تکرار شود.
Atlassian اعلام کرده است که Long Horizon میتواند در صورت نیاز تا ۱۵۰ Iteration برای هر Query انجام دهد. البته Rovo برای درخواستهای ساده، الزاماً چنین فرآیند طولانیای را اجرا نمیکند و میزان Reasoning را با توجه به پیچیدگی درخواست تنظیم میکند.
برای کسب اطلاعات تخصصی راجع به خدمات مشاوره ما در نصب جیرا به مطلب زیر مراجعه فرمایید:
نصب و راه اندازی جیرا
Long Horizon چگونه کار میکند؟
میتوان عملکرد Long Horizon را با یک چرخه ساده توضیح داد.
۱. درخواست را تحلیل میکند
ابتدا Rovo مشخص میکند کاربر دقیقاً چه چیزی میخواهد و برای پاسخ چه اطلاعاتی لازم دارد.
مثلاً اگر بپرسید:
«روند سرعت تیم ما در سه فصل گذشته چگونه بوده است؟»
Rovo باید ابتدا بفهمد چه اطلاعاتی از Jira برای پاسخ لازم است.
۲. ابزار مناسب را انتخاب میکند
در مرحله بعد، Rovo ابزارهایی را انتخاب میکند که میتوانند اطلاعات موردنیاز را فراهم کنند.
برای مثال:
Jira Search → دریافت Issueها
Confluence Search → پیدا کردن مستندات
Slack → بررسی مکالمات مرتبط
۳. نتیجه را مشاهده میکند
Rovo فقط نتیجه ابزار را دریافت نمیکند و بلافاصله پاسخ نمیدهد.
بلکه بررسی میکند:
آیا این اطلاعات برای پاسخ کافی است؟
۴. دوباره تصمیم میگیرد
اگر اطلاعات ناقص باشد، Rovo میتواند یک جستوجوی دیگر انجام دهد یا ابزار دیگری را به کار بگیرد.
۵. پاسخ را تولید میکند
وقتی Rovo به اطلاعات کافی برسد، یافتهها را کنار هم قرار میدهد و پاسخ نهایی را تولید میکند.
این چرخه همان چیزی است که Long Horizon را برای کارهای چندمرحلهای مناسبتر میکند.
تفاوت Rovo Long Horizon با Rovo قبلی چیست؟
تفاوت اصلی را میتوان در معماری خلاصه کرد.
| Rovo با معماری قبلی | Rovo Long Horizon |
|---|---|
| مسیریابی بین Agentهای تخصصی | یک حلقه استدلال یکپارچه |
| Context محدودتر در هر مرحله | Context پیوستهتر |
| مناسبتر برای کارهای کوتاه | مناسبتر برای کارهای چندمرحلهای |
| Handoff بین Agentها | تصمیمگیری مستمر توسط یک مدل |
| Iteration محدودتر | امکان تکرار بسیار بیشتر |
| تمرکز روی پاسخ سریع | تطبیق Reasoning با پیچیدگی کار |
Atlassian میگوید معماری قبلی برای درخواستهای کوتاه و متمرکز مناسب بود، اما با افزایش درخواستهای چندمرحلهای، محدودیتهایی مثل Routing سخت، Context سطحی و توانایی محدود برای Iteration ایجاد میکرد. Long Horizon این ساختار را تغییر میدهد.
یک مثال ساده از تفاوت دو معماری
فرض کنید یک مدیر محصول بپرسد:
«چرا Release اخیر محصول با تأخیر مواجه شد؟»
برای پاسخ مناسب، Rovo باید چند منبع را بررسی کند:
Jira
- Issueهای Sprint
- Bugها
- Blockerها
- تاریخ انجام Taskها
Confluence
- Release Plan
- تصمیمهای جلسات
- مستندات محصول
Slack
- بحثهای تیمی
- مشکلات فنی
- تصمیمهای فوری
در معماری قدیمی، هر بخش میتوانست به Agent تخصصی خودش برود و نتیجه دوباره به سیستم مرکزی برگردد.
اما Long Horizon تلاش میکند Context این فرآیند را یکپارچه نگه دارد و به Rovo اجازه دهد خودش تصمیم بگیرد قدم بعدی چه باشد.
به همین دلیل، Rovo میتواند بهجای اینکه فقط بگوید:
«Release سه روز تأخیر داشت.»
به دنبال علت تأخیر بگردد و ارتباط میان اطلاعات Jira، Confluence و Slack را بررسی کند.
Long Horizon چه تفاوتی با Rovo Think Deeper دارد؟
این دو قابلیت را نباید یکی بدانیم.
Think Deeper یک حالت Reasoning برای زمانی است که پاسخ معمولی کافی نیست و Rovo باید زمان بیشتری برای تحلیل، برنامهریزی و بررسی جزئیات صرف کند. Atlassian این قابلیت را در ژانویه ۲۰۲۶ معرفی کرد.
Think Deeper بیشتر روی عمق استدلال برای یک درخواست تمرکز دارد.
اما Long Horizon یک تغییر معماری در موتور استدلال Rovo Chat است.
به زبان ساده:
Think Deeper = Rovo بیشتر فکر میکند.
Long Horizon = Rovo برای انجام کارهای طولانیتر و چندمرحلهای، معماری مناسبتری دارد.
در عمل این دو مفهوم میتوانند مکمل یکدیگر باشند.
تفاوت Long Horizon با Deep Research چیست؟
این تفاوت نیز اهمیت زیادی دارد.
Deep Research برای تحقیق عمیق و تولید گزارشهای جامع طراحی شده است. Rovo در این حالت درخواست را به یک Research Plan تبدیل میکند، آن را به چند Task تقسیم میکند و سپس براساس منابع مختلف گزارش تولید میکند.
برای مثال:
«تحلیل کاملی از وضعیت رقبا و تأثیر AI بر بازار ما تهیه کن.»
این درخواست برای Deep Research مناسب است.
اما Long Horizon بیشتر یک موتور استدلال و اجرای چندمرحلهای در Rovo Chat است.
بنابراین میتوان این سه قابلیت را اینگونه مقایسه کرد:
| قابلیت | مناسب برای |
|---|---|
| Rovo Chat | سؤالها و کارهای روزمره |
| Think Deeper | مسائل پیچیدهتر که به تحلیل بیشتر نیاز دارند |
| Deep Research | تحقیقات گسترده و گزارشهای مستند |
| Long Horizon | زیرساخت استدلال چندمرحلهای Rovo Chat |
Atlassian برای Deep Research حتی زمان پاسخ تا حدود ۱۵ دقیقه را اعلام کرده است؛ بنابراین نباید آن را با پاسخهای معمول Rovo یا Think Deeper یکی دانست.
Rovo Long Horizon برای Jira چه کاربردی دارد؟
یکی از مهمترین کاربردهای Long Horizon در Jira، تحلیل دادههای پراکنده در چند Issue و چند پروژه است.
برای مثال، یک Jira Admin میتواند از Rovo بخواهد:
«تمام Bugهای Critical سه ماه گذشته را بررسی کن و ببین کدام تیمها بیشترین مشکل را داشتهاند.»
Rovo میتواند دادهها را بررسی کند و الگوهای موجود را استخراج کند.
یا مدیر پروژه میتواند بپرسد:
«کدام Issueهای Sprint فعلی احتمالاً به Sprint بعد منتقل میشوند و چرا؟»
برای پاسخ بهتر، Rovo باید وضعیت Issueها، تاریخها، ارتباط میان Taskها و سایر Contextهای مرتبط را بررسی کند.
در نتیجه، Rovo از یک Search ساده فراتر میرود و به سمت تحلیل Work Context حرکت میکند.
کاربرد Long Horizon در Confluence
Confluence یکی از مهمترین منابع دانش سازمان است.
در یک سازمان بزرگ، ممکن است اطلاعات یک پروژه در دهها یا حتی صدها صفحه پراکنده باشد.
برای مثال:
- Project Plan
- Meeting Notes
- Technical Documentation
- Decision Records
- Incident Reports
- Release Notes
- Product Requirements
کاربر معمولاً نمیخواهد تکتک این صفحات را باز کند.
او سؤالش را به زبان طبیعی مطرح میکند:
«مهمترین تصمیمهایی که در سه ماه گذشته درباره پروژه CRM گرفتهایم چه بودهاند؟»
Long Horizon میتواند برای پیدا کردن پاسخ، اطلاعات بیشتری را بررسی کند و ارتباط میان منابع مختلف را در نظر بگیرد.
این موضوع با فلسفه کلی Rovo نیز هماهنگ است؛ Rovo برای پیدا کردن دانش در ابزارهای مختلف و استفاده از آن در تصمیمگیری طراحی شده و به منابعی مانند Jira، Confluence و ابزارهای متصل شخص ثالث دسترسی دارد.
Long Horizon و Teamwork Graph
یکی از دلایل مهم قدرت Rovo، Teamwork Graph است.
Rovo فقط یک موتور جستوجوی ساده برای متن نیست.
این پلتفرم تلاش میکند ارتباط میان افراد، پروژهها، محتوا و فعالیتهای کاری سازمان را درک کند.
به همین دلیل، وقتی یک درخواست پیچیده مطرح میشود، Rovo میتواند اطلاعات موجود در منابع مختلف را در یک Context کاری قرار دهد.
Atlassian در توضیح Long Horizon نیز از توانایی کار با Context موجود در ابزارهایی مانند Jira، Confluence، Slack و سایر ابزارهای متصل صحبت میکند.
این موضوع برای سازمانها اهمیت زیادی دارد؛ زیرا اطلاعات واقعی کسبوکار معمولاً در یک نرمافزار واحد قرار ندارد.
آیا Long Horizon میتواند فقط اطلاعات را بخواند؟
خیر، هدف Rovo فقط Search نیست.
Atlassian Rovo را در سه حوزه کلی معرفی میکند:
Find → پیدا کردن اطلاعات
Learn → تحلیل و یادگیری از اطلاعات
Act → انجام اقدامات با کمک Agentها
بنابراین Rovo میتواند در سناریوهای مختلف از پیدا کردن اطلاعات تا اجرای برخی اقدامات کاری حرکت کند. البته سطح دسترسی و Actionهای قابل اجرا به ابزارها، مجوزها و تنظیمات سازمان وابسته است.
Long Horizon نیز در همین مسیر اهمیت پیدا میکند؛ زیرا اجرای یک Workflow واقعی معمولاً فقط به یک Tool Call محدود نمیشود.
ممکن است Agent لازم باشد:
اطلاعات را پیدا کند → آن را تحلیل کند → یک تصمیم بگیرد → ابزار دیگری را اجرا کند → نتیجه را بررسی کند.
یک سناریوی سازمانی واقعی
فرض کنید یک شرکت نرمافزاری از Jira و Confluence استفاده میکند.
مدیر فنی از Rovo میپرسد:
«در سه ماه گذشته چه مشکلاتی باعث تأخیر Releaseها شدهاند؟ موارد تکرارشونده را پیدا کن و برای هرکدام یک پیشنهاد عملی ارائه بده.»
این درخواست چند مرحله دارد.
مرحله اول: جمعآوری داده
Rovo باید Issueها و Bugهای مرتبط با Releaseها را پیدا کند.
مرحله دوم: بررسی مستندات
سپس باید به سراغ Confluence برود و Incident Reportها و مستندات مربوط به Releaseها را بررسی کند.
مرحله سوم: پیدا کردن الگو
حالا باید مشخص کند آیا یک مشکل خاص چند بار تکرار شده است یا خیر.
مرحله چهارم: تحلیل
Rovo میتواند عوامل پرتکرار را دستهبندی کند.
مرحله پنجم: ارائه پیشنهاد
در نهایت، میتواند بر اساس اطلاعات جمعآوریشده پیشنهادهایی برای کاهش مشکلات ارائه دهد.
این دقیقاً همان نوع کاری است که معماری Long Horizon برای آن مناسبتر شده است: کار طولانی، چندمرحلهای و مبتنی بر چند منبع اطلاعاتی.
Long Horizon برای Jira Adminها چه اهمیتی دارد؟
اگر Jira Admin هستید، احتمالاً بیشتر از هر کاربر دیگری با دادههای پراکنده و فرآیندهای پیچیده سازمان مواجه هستید.
برای مثال:
- چند Project
- تعداد زیادی Workflow
- هزاران Issue
- Custom Fieldهای متعدد
- تیمهای مختلف
- مستندات Confluence
- گزارشهای Jira
- ابزارهای توسعه
- سرویسهای متصل
در چنین محیطی، یک AI ساده که فقط یک سؤال را پاسخ دهد، ارزش محدودی دارد.
اما Agentی که بتواند Context را حفظ کند، ابزار مناسب را انتخاب کند و چند مرحله را پشت سر هم اجرا کند، میتواند بخشی از کارهای تحلیلی Jira Admin را سادهتر کند.
برای مثال:
«پروژههایی که بیشترین تعداد Blocker را در ماه گذشته داشتهاند پیدا کن و علت اصلی را از روی Issueها و مستندات بررسی کن.»
یا:
«Workflow پروژههای تیمهای مختلف را بررسی کن و مواردی را که بیش از حد پیچیده هستند مشخص کن.»
این نوع درخواستها بیشتر به تحلیل سازمانی نزدیک هستند تا Search معمولی.
آیا Long Horizon پاسخهای Rovo را همیشه بهتر میکند؟
نه لزوماً.
این نکته مهم است.
برای سؤال سادهای مانند:
«وضعیت PROJ-123 چیست؟»
نیازی نیست Rovo یک فرآیند طولانی اجرا کند.
خود Atlassian نیز توضیح میدهد که Long Horizon از Adaptive Reasoning Effort استفاده میکند؛ یعنی میزان Reasoning را براساس پیچیدگی درخواست تنظیم میکند. در یک درخواست ساده، سیستم میتواند با Reasoning کمتر پاسخ دهد و برای درخواستهای پیچیدهتر، فرآیند عمیقتری را اجرا کند.
پس هدف Long Horizon این نیست که هر سؤال را طولانیتر پاسخ دهد.
هدف اصلی این است که وقتی یک کار واقعاً پیچیده است، Rovo بتواند مسیر طولانیتری را طی کند.
یک نکته مهم درباره سرعت پاسخ
هرچه تعداد مراحل و Tool Callها افزایش پیدا کند، احتمالاً زمان پردازش نیز افزایش پیدا میکند.
به همین دلیل، Long Horizon قرار نیست برای هر درخواست جایگزین مسیرهای سریع شود.
Atlassian حتی اعلام کرده است که روی کاهش زمان پاسخ برای Queryهای ساده کار میکند و تلاش دارد در موارد ساده، از اجرای کامل چرخه Reasoning جلوگیری کند.
بنابراین میتوان انتظار داشت Rovo در آینده بیشتر بین دو حالت حرکت کند:
کار ساده → پاسخ سریع
کار پیچیده → Reasoning و Iteration بیشتر
این رویکرد برای استفاده سازمانی منطقیتر است.
Long Horizon چه تأثیری بر آینده AI سازمانی دارد؟
اهمیت Long Horizon فقط به Rovo محدود نمیشود.
هوش مصنوعی سازمانی در حال حرکت از مدل:
Question → Answer
به سمت مدل:
Goal → Plan → Tools → Execution → Evaluation → Result
است.
در مدل اول، کاربر سؤال میپرسد و AI جواب میدهد.
در مدل دوم، کاربر یک هدف تعیین میکند و Agent بخشی از فرآیند رسیدن به آن هدف را انجام میدهد.
Long Horizon یکی از نمونههای این تغییر در اکوسیستم Atlassian است.
Atlassian نیز صراحتاً میگوید این معماری Rovo را از یک «Chatbot بهتر» به سمت یک Agentic Work Platform حرکت میدهد؛ پلتفرمی که میتواند کار را در چند مرحله دنبال کند و بین Jira، Confluence، Slack، Bitbucket و ابزارهای متصل حرکت کند.
آیا Long Horizon همان AGI است؟
خیر.
نباید از قابلیتهای Long Horizon نتیجه بگیریم که Rovo به یک هوش عمومی مصنوعی یا AGI تبدیل شده است.
Long Horizon یک معماری برای Reasoning و اجرای کارهای چندمرحلهای است.
این معماری میتواند عملکرد Agent را در کارهای پیچیده بهتر کند، اما همچنان محدودیتهای مدل، کیفیت داده، دسترسی به منابع و ابزارهای موجود را دارد.
در واقع، یکی از نکات مهم در AI سازمانی همین است:
هرچه Context بهتر باشد، ابزارها مناسبتر باشند و دادهها ساختارمندتر باشند، Agent نیز شانس بیشتری برای ارائه نتیجه مفید خواهد داشت.
نقش Permission در Long Horizon چیست؟
هرچه AI به منابع بیشتری دسترسی پیدا کند، مسئله امنیت اهمیت بیشتری پیدا میکند.
در Rovo، دسترسی به اطلاعات همچنان به Permissionهای کاربر وابسته است. مستندات Atlassian تأکید میکنند که Rovo کاربران را فقط به اطلاعاتی که خودشان اجازه مشاهده آن را دارند محدود میکند.
بنابراین سازمانها نباید صرفاً به دلیل وجود Long Horizon، دسترسیهای گستردهای برای کاربران یا Agentها ایجاد کنند.
قبل از استفاده سازمانی بهتر است موارد زیر بررسی شوند:
- Permissionهای Jira
- دسترسیهای Confluence
- منابع Third-party
- دسترسی Agentها
- Skillهای قابل اجرا
- دادههای حساس
- فرآیندهای Approval
- Audit و Governance
بهخصوص وقتی Agent اجازه انجام Action داشته باشد، طراحی Permission اهمیت بیشتری پیدا میکند.
Long Horizon چه تفاوتی با یک Chatbot معمولی دارد؟
یک Chatbot معمولی معمولاً برای پاسخ به یک درخواست مشخص طراحی شده است.
اما یک Agent با معماری Long Horizon میتواند مسیر رسیدن به پاسخ را نیز مدیریت کند.
مثلاً بهجای:
«این Issue چیست؟»
با درخواستهایی مانند:
«تمام Issueهای مرتبط با این مشکل را پیدا کن، مستندات مرتبط را بررسی کن، موارد مشابه را مقایسه کن و نتیجه را توضیح بده.»
مواجه میشویم.
در حالت دوم، AI باید کار را مدیریت کند، نه اینکه فقط یک پاسخ تولید کند.
این تفاوت، یکی از مهمترین تغییرات نسل جدید AI سازمانی است.
جمعبندی
Rovo Long Horizon یک قابلیت مستقل شبیه یک افزونه جداگانه برای Jira نیست؛ بلکه موتور استدلال جدید Rovo Chat است که برای کارهای پیچیده و چندمرحلهای طراحی شده است.
در معماری جدید، Rovo میتواند Context مکالمه و تعاملات ابزارها را در یک فرآیند پیوسته حفظ کند، نتیجه هر مرحله را بررسی کند و در صورت نیاز دوباره به سراغ ابزارها برود. این معماری میتواند تا ۱۵۰ Iteration را برای یک Query در اختیار Rovo قرار دهد و میزان Reasoning را با توجه به پیچیدگی کار تنظیم کند.
برای کاربران Jira و Confluence، این تغییر یعنی Rovo میتواند از یک ابزار ساده برای Search و پاسخگویی به سمت یک دستیار برای تحلیل، تحقیق و اجرای Workflowهای چندمرحلهای حرکت کند.
در نتیجه، کاربرد واقعی Long Horizon را باید بیشتر در سؤالهای پیچیدهای جستوجو کرد که پاسخ آنها در یک Issue یا یک صفحه Confluence قرار ندارد؛ بلکه باید اطلاعات را از چند منبع جمعآوری کرد، ارتباط میان آنها را فهمید و سپس یک نتیجه قابل استفاده ارائه داد.
برای سازمانها نیز این موضوع یک پیام مهم دارد:
آینده Jira و Confluence فقط درباره مدیریت Task و مستندات نیست؛ بلکه درباره ایجاد یک لایه هوشمند برای فهم و اجرای Work نیز هست.
سؤالات متداول
Rovo Long Horizon چیست؟
Long Horizon موتور استدلال جدید Rovo Chat است که برای انجام درخواستهای پیچیده و چندمرحلهای طراحی شده و امکان حفظ Context، استفاده از ابزارها و تکرار فرآیند Reasoning را فراهم میکند.
آیا Long Horizon یک Agent جدید در Rovo است؟
خیر. Long Horizon یک Reasoning Engine / معماری استدلال برای Rovo Chat است و نباید آن را با یک Agent مستقل اشتباه گرفت.
Long Horizon چه تفاوتی با Deep Research دارد؟
Deep Research برای تحقیقات عمیق و تولید گزارشهای جامع طراحی شده است، درحالیکه Long Horizon موتور استدلال چندمرحلهای Rovo Chat است. Deep Research نیز فرآیند تحقیق را به چند Task تقسیم میکند و گزارش مستند تولید میکند.
Long Horizon چه تفاوتی با Think Deeper دارد؟
Think Deeper حالت Reasoning عمیقتر برای درخواستهای پیچیده است؛ Long Horizon معماری جدید Rovo برای مدیریت کارهای چندمرحلهای و حفظ Context در طول فرآیند است.
آیا Long Horizon میتواند با Jira و Confluence کار کند؟
بله. معماری جدید Rovo برای کار با Context و ابزارهای مختلف اکوسیستم Atlassian، از جمله Jira و Confluence، طراحی شده است.
آیا Rovo Long Horizon برای همه سؤالها استفاده میشود؟
خیر. Rovo میزان Reasoning را با توجه به پیچیدگی درخواست تنظیم میکند. سؤالهای ساده میتوانند مسیر سریعتری داشته باشند و درخواستهای پیچیدهتر Reasoning بیشتری دریافت میکنند.
برای اطلاعات بیشتر و دریافت مشاوره سازمانی با ما در ارتباط باشید




