A LiveKit külön tesztkörnyezetet ad a hangügynökök mellé

Külön projekt helyett külön deployment

A LiveKit 2026. szeptember 2-án bemutatott megoldása azoknak szól, akik egy már működő hangügynökön szeretnének új modellt, promptot vagy integrációt kipróbálni, mielőtt a módosítás eljutna a felhasználókhoz. Korábban ehhez egy második ügynököt kellett létrehozni saját projekttel, API-kulcsokkal és titkokkal.

A non-production deployment ugyanannak az ügynöknek egy másik néven futó példánya. Az éles és a tesztverzió azonos projektben működik, ugyanazokat a titkokat látja, és a teszteléshez nem kell külön konténerképet készíteni. Egy ügynökhöz több ilyen deployment is létrehozható, egyetlen paranccsal: lk agent deploy --deployment staging.

Minden ügynöknek van egy fenntartott, production nevű deploymentje. Ez az alapértelmezett célpont, ha a parancsoknál nem adnak meg külön nevet.

Alvó tesztpéldányok, eltérő működés élesben

A LiveKit szerint a non-production deployment akkor alszik, amikor senki nem használja, és a következő kérésre ébred fel. Alvás közben nem kerül pénzbe, ébren pedig a számítási költsége az ügynök meglévő számlázásába számít bele. Ez azt jelenti, hogy egy hetente csak néhányszor használt staging példány a többi időben tétlenül, költség nélkül várakozhat.

A production deployment fizetős csomagokban folyamatosan melegen tartható, míg a non-production példányok hideg indulással kezdenek az első kéréskor. Az éles verzió újratelepítéskor fokozatosan leállítja a munkameneteket, és az aktív kapcsolatoknak legfeljebb egy órát ad a befejezésre. A non-production deployment újratelepítése ezzel szemben azonnal leállítja az aktív munkameneteket, és visszaállítási lehetőség sem tartozik hozzá.

Ezért a LiveKit azt javasolja, hogy a megszakítást nem tűrő forgalom production környezetben maradjon, a tesztpéldányokat pedig iterációra használják.

Közös titkok, külön futási logika

A titkok az ügynökhöz tartoznak, így minden deployment ugyanazokat az értékeket éri el. Ha például az ügynök külső modellként az OpenAI szolgáltatását használja, az OPENAI_API_KEY értéket egyszer kell beállítani, és azt a production, a staging, valamint a többi deployment is olvashatja.

Ha egy tesztpéldánynak eltérő kulcsra vagy szolgáltatóra van szüksége, a kód futás közben meg tudja különböztetni a deploymenteket. Ezt a LIVEKIT_AGENT_DEPLOYMENT környezeti változó teszi lehetővé. Non-production esetben ez a deployment nevét tartalmazza, production esetén üres marad.

A parancssori felületen a create, deploy, promote, logs és delete parancsokhoz adható meg a --deployment kapcsoló. A kapcsoló nélküli parancsok a production példányra vonatkoznak. A törlésnél különösen fontos a név megadása, mert a lk agent delete kapcsoló nélkül a teljes ügynököt, a production verzióval együtt törli.

Kinek érhető el, és mire kell figyelni?

A funkció a Ship és Scale csomagokban érhető el. A Ship csomag ügynökönként 2, a Scale csomag 5 non-production deploymentet engedélyez. Egy példány akkor is beleszámít a keretbe, amikor alszik, ezért a már nem használt deploymentet törölni kell a hely felszabadításához.

A tesztkörnyezetek eléréséhez friss SDK szükséges: Python esetén a livekit-agents 1.6 vagy újabb, Node.js esetén az @livekit/agents 1.7.1 vagy újabb verzió. Régebbi kiadásokkal a példány productionként indulhat, így a neki szánt hívások nem oda érkeznek, és akár éles forgalmat is fogadhat.

A LiveKit szerint a deployment kiválasztása a dispatch API-ban és a tokenbe ágyazott dispatchben is elérhető. A dashboardon az Agent Console vagy SIP dispatch szabály használatakor választható ki a deployment. Jelenleg az Agent Observability csak a production deploymentből származó metrikákat küldi, a non-production példányok vizsgálatához ezért a naplókat kell használni. A deploymentenkénti metrikák támogatása későbbre várható.