Emberi jóváhagyás MI-ügynökben: a folytatható állapot a kulcs

Érzékeny eszközhívás előtt az MI-ügynök futását meg kell állítani, és meg kell őrizni azt az állapotot, amelyből a függő hívás folytatható. A döntéshozó személyét és az adott hívásra szóló jogosultságát az alkalmazás ellenőrzi; csak ezután adja át a jóváhagyást vagy elutasítást a megőrzött futásnak.

A jóváhagyási gomb egy szerveroldali folyamat látható eleme. A döntéshozónak a tényleges eszközt, a művelet célját és a lényeges paramétereket kell látnia. A rendszernek pedig ugyanahhoz a függő híváshoz kell kötnie a döntést, amelyet később végrehajt vagy elvet.

Mit kell rögzíteni a megszakításkor?

Az engedélykérés adatait az eszközhívás végrehajtása előtt kell elmenteni. A szerveroldali rekord kapcsolja össze a futást, a függő hívás azonosítóját, a jóváhagyónak megmutatott paramétereket, a mentett állapotot és a döntés státuszát. Így a jóváhagyás egy meghatározott műveletre vonatkozik, nem az ügynök későbbi, eltérő hívásaira.

A megjelenítésre szánt összefoglalót külön kell kezelni a folytatáshoz szükséges teljes állapottól. A döntéshozó csak a feladatához szükséges adatokat kapja meg; a teljes állapot az alkalmazás felügyelete alatt marad. Ha a művelet címzettje, célja vagy paramétere a jóváhagyási kérés után megváltozik, az eredeti döntés helyett új kérést kell létrehozni.

OpenAI Agents SDK: döntés a mentett RunState-ben

Az OpenAI Agents SDK útmutatója szerint a jóváhagyást igénylő eszközhívás megszakítja a futást: a függő kérések a megszakítások között jelennek meg, a RunState pedig szerializálható és később visszatölthető. Ha a hívás beágyazott ügynöktől származik, a döntést akkor is a külső futás állapotán kell alkalmazni, majd az eredeti legfelső szintű ügynök futását kell folytatni.

1. A jóváhagyást igénylő eszközt vagy hívást jelöld ki, majd indítsd el az ügynököt. Megszakításkor a result.to_state() állapotot és a függő kérések azonosítóit mentsd az alkalmazás által kezelt tárolóba.
2. A döntés beérkezésekor a hitelesített munkamenetből azonosítsd a döntéshozót. Ellenőrizd, hogy jogosult-e a tárolt futás és a kiválasztott hívás elbírálására, majd a visszatöltött állapotban keresd meg a megfelelő megszakítást.
3. A szerver által megőrzött hívásra alkalmazd a state.approve(...) vagy state.reject(...) döntést, és a Runner.run(agent, state) hívással folytasd a futást. A folytatás újabb jóváhagyási pontnál ismét megállhat.

A böngészőtől döntést és azonosítót fogadj, ne módosított RunState-állapotot vagy új eszközparamétereket. A visszatöltés önmagában nem igazolja sem a beküldő személyét, sem az állapot sértetlenségét. Több függő kérés esetén a kiválasztott hívást kell elbírálni; az egész futásra érvényes, későbbi hívásokat is lefedő jóváhagyást érzékeny műveletnél csak külön indokolt szabályként érdemes megengedni.

LangGraph: interrupt és checkpoint ugyanabban a szálban

A LangGraph ügyfélszolgálati példájában az interrupt() egy felülvizsgálati csomópontban állítja meg a gráfot. A checkpointer megőrzi az állapotot; a futás ugyanazzal a thread_id-val és a döntést átadó Command objektummal folytatható. A példában a jóváhagyás az üzenetküldő csomóponthoz vezet, az elutasítás pedig lezárja az ágat.

A checkpointert a gráf összeállításakor kell bekötni. Az útmutató MemorySaver példája a működést szemlélteti; ha a döntésig a folyamat újraindulhat, olyan tárolóra van szükség, amely ezt az időszakot is átvészeli. A szerver rendelje a thread_id-t a megfelelő futáshoz, és a beérkező Command.resume tartalmát csak hitelesítés, jogosultsági vizsgálat és a függő művelettel való egyeztetés után adja át a gráfnak.

Folytatáskor a megszakított csomópont kódja az elejétől ismét lefuthat. Ezért az interrupt() elé nem kerülhet olyan mellékhatás, amelyet nem szabad megismételni; az üzenetküldés külön, csak jóváhagyás után elérhető csomópontba tartozik. Ha a döntéshozó az üzenet szövegét is módosíthatja, a végrehajtandó változatot kell a döntéshez kötni, különösen akkor, ha a címzett vagy a tartalom megváltoztatása új kockázatot jelent.

Hamis azonosító, jogosulatlan döntés, manipulált állapot

A jóváhagyási végpont érzékeny műveletet enged tovább. A beküldött mezők ezért csak állítások: a szerver a saját, mentett adataihoz méri őket. Három külön ellenőrzés védi a döntés és a végrehajtandó hívás kapcsolatát.

• Hamis vagy ismételten beküldött döntésazonosító: csak a tárolt futásban valóban függő azonosítót fogadd el. A feldolgozáskor atomi állapotváltással használd fel a kérelmet, hogy két párhuzamos beküldés ne folytathassa ugyanazt a mentett állapotot.
• Jogosulatlan jóváhagyó: a személyazonosság a hitelesített munkamenetből származzon, ne a kérés törzséből. A jogosultságot a konkrét futáshoz és híváshoz ellenőrizd; egy futás- vagy döntésazonosító ismerete önmagában nem engedély.
• Manipulált állapot: a teljes checkpoint vagy RunState maradjon ellenőrzött szerveroldali tárolóban. Ha mégis kliensen keresztül kell továbbítani, visszatöltés előtt a teljes tartalom sértetlenségét, a futáshoz és tulajdonoshoz kötését, valamint az ismételt felhasználás kizárását is ellenőrizni kell.

A megjelenített eszköznév és paraméter szintén nem megbízható tartalom. Az érzékeny adatokat szűrni kell, a szöveget pedig biztonságosan kell megjeleníteni. A döntéshozó így láthatja a művelet elbírálásához szükséges részleteket anélkül, hogy a teljes futási állapot a klienshez kerülne.

Naplózás és helyreállítás a döntés után

A döntési naplóban célszerű összekapcsolni a futás és a függő hívás azonosítóját, az állapot verzióját, a hitelesített döntéshozót, az időpontot, a döntést és a folytatás eredményét. Az eszközparaméterekből csak a későbbi vizsgálathoz szükséges részt őrizd meg. Így elkülöníthető, hogy egy műveletet jóváhagytak, elindítottak vagy a folytatás közben hiba szakította meg.

A jóváhagyás rögzítése még nem bizonyítja, hogy a külső művelet sikerült vagy biztosan elmaradt. Hiba után, újrapróbálás előtt tisztázni kell az eszközhívás tényleges eredményét, különösen üzenetküldésnél vagy törlésnél. Ha a külső rendszer támogatja, a művelethez rendelt idempotenciakulcs segíthet megelőzni az ismételt végrehajtást; a döntési rekordnak és a végrehajtási eredménynek ugyanarra a hívásra kell mutatnia.

Olvassa el ezt is:

• A 73 Strings megvette a Callistót – MI-ügynök jön az alapértékelésbe
• Az OpenAI ügynöke belépett a Medicare rendszerébe, a riasztás hónapokat késett