Omnissa пушта AI-агент во VDI, а задачите остануваат во контролиран простор

Omnissa на 29 септември 2026 година, на Omnissa ONE 2026, во објавата за Horizon го најави агентот Horizon Delegate за задачи во постојната VDI-сесија на корисникот. Ограничена достапност се очекува со Horizon 2609; посебен агент за пакување апликации е планиран како бета во App Volumes 2609. Тоа се најавени фази на пуштање, а не општа достапност на новите агенти.

Horizon Delegate е замислен да продолжи со делегирана работа во виртуелната машина и откако корисникот ќе ја прекине врската со сесијата. Аналитичарот Гејб Нут во анализата на Informa TechTarget го опишува како постојан агент што дејствува со идентитетот и дозволите на корисникот. За ИТ-тимовите клучно е каде се извршува задачата: во веќе управуваната Horizon околина, со пристапот што корисникот го има таму.

Од барањето до дејството во Horizon сесијата

Корисникот му задава задача на агентот преку разговор во Horizon Client, вклучително и од оддалечен или мобилен уред. Барањето патува до агентот преку управуван комуникациски канал, а дејствата се извршуваат во виртуелната сесија поврзана со корисникот. Така агентот може да работи со апликации до кои организацијата дозволува пристап во таа околина, без физичкиот уред да ја извршува самата задача.

Прекинувањето на врската не ја прекинува нужно започнатата работа: агентот може да продолжи во виртуелната машина, а корисникот подоцна да се врати во сесијата. Предвидени се задачи што траат подолго, работа во повеќе чекори и дејства во заднина. Корисникот може да избере дали дејствата ќе се одвиваат додека е присутен или асинхроно, но агентот и во двата случаи работи со неговите постојни овластувања.

Таа граница има практично значење. Ако корисничката сметка нема пристап до одредена апликација или ресурс во Horizon, агентот не добива посебно право само затоа што задачата му е делегирана. Истовремено, овластувањата што корисникот веќе ги има стануваат достапни за извршување на делегираната работа; затоа идентитетот и правилата за пристап остануваат суштински дел од контролата.

Што останува во VDI, а што оди до моделот

Извршувањето во виртуелната машина и AI-заклучувањето се различни делови од истиот тек. Документацијата на Omnissa наведува дека дејствата се извршуваат во Horizon VDI, додека заклучувањето се одвива кај моделот што го избира клиентот. Почетната понуда предвидува поддршка за GitHub Copilot преку Horizon SDK, како и поврзување со сопствен модел на клиентот преку протоколот Horizon Blast.

За моделот да одлучи што да направи, до него може привремено да стигнат барањето на корисникот и контекст од работната околина. Зависно од задачата, тој контекст може да содржи слика од екранот, содржина на документ или состојба на апликација. Софтверот Horizon, според опишаниот тек, не ги зачувува трајно тие податоци. Правилата за обработка и задржување кај избраниот модел се посебна одговорност на организацијата.

Виртуелната машина е мрежно изолирана, а надворешниот повик кон моделот се врши со идентитетот на корисникот. Крајниот уред не комуницира директно со моделот, ниту моделот директно пристапува до внатрешните корпоративни системи. Unified Access Gateway применува администраторски список на дозволени адреси на AI-провајдери, додека слојот за управување одредува кој смее да го користи агентот и што смее да му се испрати на моделот.

Функцијата треба да биде инсталирана како дел од Horizon Agent и администраторот изречно да ја вклучи за соодветниот збир виртуелни машини; стандардно не е активна. Оттаму, „контролиран простор“ се однесува на местото на извршување, корисничките дозволи и управуваната комуникациска патека. Не значи дека секој податок потребен за заклучувањето останува во виртуелната машина.

Одобрувањето кај агентот за апликации има друга улога

Посебниот агент за пакување апликации е наменет за ИТ-тимовите што работат со App Volumes. Најавената функција открива ажурирања на апликации и подготвува пакети врз основа на одобрувања од ИТ. Таа автоматизира дел од одржувањето на апликациите, додека одлуката за одобрување останува кај тимот. Omnissa ја поврзува оваа промена со пократко време меѓу достапно ажурирање и пакет подготвен за распоредување, но не објави измерен резултат од таков процес.

Ова одобрување не е исто со дозволите на Horizon Delegate. Делегираниот агент извршува кориснички задачи во VDI-сесија; агентот за пакување подготвува апликациски пакети според одлуки на ИТ. Разликата е важна и за очекувањата од автоматизацијата: кај едниот фокусот е пристапот во постојната корисничка околина, а кај другиот контролата врз подготовката на ажурирања.

Фазите на пуштање остануваат различни

Постојните производи Horizon и App Volumes се основата за најавените можности, но статусот на производот не е статус на новиот агент. Објавениот распоред прави јасна разлика меѓу ограничен пристап и бета-тестирање:

• Ограничена достапност: Horizon Delegate се очекува со Horizon 2609. Тоа означува планирано пуштање за ограничен круг корисници.
• Бета: агентот за пакување апликации се очекува во App Volumes 2609. Бета-статусот се однесува на новата автоматизација.
• Понатамошно пуштање: не е објавен потврден датум за општа достапност на двата агента.

Следниот конкретен момент за корисниците на Horizon ќе биде објавувањето на условите за ограничениот пристап: кои конфигурации ќе бидат опфатени и кога администраторите ќе можат да ја вклучат функцијата. Дотогаш, техничкиот опис ја покажува замислената граница на дозволите и податоците, а распоредот кажува кога се очекува првиот ограничен пристап.

Прочитајте и:

• AI-агент пред испраќање е-пошта: паузата мора да ја зачува состојбата
• AI-агент со root API-клуч: една погодена инструкција станува целосен пристап
• CapCut или DaVinci Resolve: брзите Shorts се плаќаат со помала контрола