Levenscyclus van agentsessie

Een Windows 365 agentsessie vertegenwoordigt de volledige levenscyclus waarin een agentische toepassing een cloud-pc aanvraagt, deze gebruikt om een taak uit te voeren en deze vervolgens retourneert wanneer u klaar bent. Sessies zijn het mechanisme waarmee het platform een pool van cloud-pc's voor agents verandert in een on-demand, wegwerpwerkruimte voor AI-agents en, indien nodig, voor de mensen die er toezicht op houden.

Uw eerste agentische sessie doorloopt vijf conceptuele fasen: Acquire Connect >> Act > Release voorbereiden>.

Levenscyclus in één oogopslag

Fase Vliegtuig Wat gebeurt er
Voorbereiden Computer-Create Pools van cloud-pc's worden ingericht, geconfigureerd en beschikbaar gesteld voor agentgebruik.
Verwerven Computer-Get Een cloud-pc is gereserveerd voor een specifieke beller en sessie.
Verbinding maken Computer-Do, Computer-TakeControl Geverifieerde kanalen geopend; mogelijkheden worden beschikbaar.
Handelen Computer-Do, Computer-TakeControl De agent werkt met de cloud-pc, met optionele menselijke observatie.
Release Computer-Get Kanalen worden gesloten, de cloud-pc wordt opnieuw ingesteld en de capaciteit keert terug naar de pool.

Voorbereiden

Voordat er een sessie kan bestaan, moet u een pool met cloud-pc's voor agents maken, het Computer-Create vlak van de architectuur. IT-beheerders en agentmakers definiëren deze pools door installatiekopieën, regio's en grootte te kiezen en toe te wijzen welke agents toegang hebben tot deze pools. Windows 365 richt vervolgens deze cloud-pc-agentgroepen in.

Verwerven

Een sessie begint zodra een agentische toepassing om een machine vraagt. De aanvraag stroomt naar het computer-get-vlak , dat een beschikbare cloud-pc selecteert in de juiste pool, deze reserveert voor de beller en een sessie-id teruggeeft die die reservering vertegenwoordigt.

Aan het einde van deze fase heeft de aanroeper een cloud-pc-sessie die ze veilig opnieuw kunnen proberen zonder deze te dupliceren.

Verbinding maken

Als een cloud-pc is gereserveerd, opent de agent een werkkanaal via het computer-do-vlak . Dit kanaal is het kanaal waarmee de agent elke volgende instructie uitgeeft. Het wordt geverifieerd, is gebonden aan de sessie en wordt beëindigd bij het in-guest-onderdeel dat wordt uitgevoerd in de cloud-pc.

Als u verbinding maakt, wordt ook het vocabulaire van de agent weergegeven: de set mogelijkheden die het platform beschikbaar maakt via toegankelijkheid, zodat de agent weet wat hij kan doen op deze cloud-pc.

Als een mens meekijkt of helpt, kan een parallel kanaal via het computergebruiksvlak worden geopend voor realtime schermshare en optioneel gedeeld beheer. Beide kanalen zijn gericht op dezelfde cloud-pc en dezelfde sessie.

Handelen

Deze fase is het actieve gedeelte van de sessie. De agent observeert het bureaublad, bepaalt wat er moet worden gedaan en roept mogelijkheden op de cloud-pc aan: klikken, typen, navigeren op het web, opdrachten uitvoeren en de gebruikersinterface inspecteren. Het platform bemiddelt elke actie: het afdwingen van de identiteit van de sessie, het toepassen van veiligheidsrails en het vastleggen van wat er is gebeurd.

Enkele eigenschappen definiëren het karakter van deze fase:

  • Turn-based by nature. De agent observeert, handelt en observeert opnieuw. Status op de cloud-pc ontwikkelt zich naarmate het werk vordert.
  • Veilig door constructie. Uitvoering in sandbox, toegestane opdrachten, begrensde nettoladingen en beveiligde systeemprocessen houden de sessie binnen een goed gedefinieerde envelop, beveiligd door Microsoft Entra, Microsoft Intune, Microsoft Defender en Microsoft Purview.
  • Gedeeld met mensen wanneer dit nuttig is. Een mens kan dezelfde sessie in realtime observeren en de controle overnemen wanneer dat nodig is, zonder de verbinding van de agent te verstoren.
  • In leven gehouden door activiteit. Sessies die te lang stil blijven, worden automatisch vrijgemaakt, zodat de capaciteit niet wordt verspild.

Deze fase kan seconden, minuten of uren duren, maar de cloud-pc is gedurende de hele duur toegewezen aan de sessie.

Sessieduur en time-out

Een sessie heeft geen vaste maximumduur. Zolang de agent elke 30 minuten ten minste één MCP-aanvraag verzendt, blijft de sessie actief en blijft de cloud-pc hiervoor gereserveerd. Een sessie die 30 minuten duurt zonder MCP-activiteit wordt automatisch verwijderd: kanalen worden gesloten, de cloud-pc wordt opnieuw ingesteld en de capaciteit wordt teruggezet naar de pool.

Een paar dingen die u moet weten over hoe de levensduur van sessies in de praktijk werkt:

  • Geen maximale runtime. Er is geen limiet voor hoe lang een sessie kan worden uitgevoerd. Sessies zijn ontworpen om zo lang te duren als het werk vereist is, van seconden tot dagen.
  • Time-out voor inactiviteit na 30 minuten. Elke MCP-aanroep stelt de klok van inactiviteit opnieuw in. Er is geen afzonderlijke lease-verlengings-API. Activiteit is het verlengingsmechanisme. Voor perioden waarin de agent op extern werk wacht in plaats van gereedschapsaanroepen uit te voeren, verzendt u ten minste eenmaal per 30 minuten een lichtgewicht heartbeat. De get_screen_size tool is hiervoor een minimale en betrouwbare optie.
  • Meerdaagse werkstromen worden ondersteund. Het platform dwingt geen maximale levensduur van sessies af of schakelt werkstromen uit die meerdere dagen duren. Een sessie die het activiteitenritme van 30 minuten handhaaft, blijft zo lang als nodig is, behouden.
  • De status van het controlepunt extern. De status in de sessie overleeft een onverwacht sessieverlies niet. Als de sessie wordt onderbroken, wordt de cloud-pc opnieuw ingesteld bij de release en gaat het niet-opgeslagen werk in de sessie verloren. Sla de voortgang regelmatig op naar externe opslag en bouw uw agent om een 404 Not Found reactie af te handelen door opnieuw een nieuwe cloud-pc aan te schaffen en het laatste controlepunt te hervatten.
  • De levensduur van tokens onafhankelijk beheren. Verificatietokens verlopen volgens hun eigen schema, ongeacht de sessieactiviteit. Zorg ervoor dat uw toepassing referenties transparant vernieuwt voor de volledige duur van de werkstroom.

Release

Een sessie wordt beëindigd wanneer de agent verklaart dat het werk is voltooid, wanneer het beleid wordt beëindigd of wanneer deze te lang inactief is. De release wordt afgehandeld door Computer-Get: de kanalen worden verbroken, de cloud-pc wordt opnieuw ingesteld, de facturering is voltooid en de cloud-pc keert terug naar de groep, klaar om een andere aanvraag te doen. Cloud-pc's die tijdens de sessie niet zijn geslaagd voor statuscontroles, worden in quarantaine geplaatst en vervangen in plaats van opnieuw gebruikt, waardoor de pool na verloop van tijd in orde blijft.

Waarom het op deze manier wordt gevormd

De levenscyclus is ontworpen rond drie ideeën:

  • Pools, geen cloud-pc's. Agents vragen mogelijkheden aan, niet een specifieke cloud-pc. Pooling maakt het berekenen van agent op aanvraag economisch haalbaar.
  • Eén sessie, veel oppervlakken. Dezelfde cloud-pc kan worden aangestuurd door een agent en worden geobserveerd of meegestuurd door een mens binnen één sessie. Er is geen afzonderlijk inrichtingspad voor werk onder supervisie.
  • De grenzen tussen sessies opschonen. Elke sessie eindigt met opnieuw instellen en terugkeren om ervoor te zorgen dat de volgende sessie begint met de ingerichte status, zodat isolatie, controleerbaarheid en hergebruik allemaal uit hetzelfde model vallen.

Volgende stappen

Verwante onderwerpen

  • Last updated on