Az AI-alapú webhelyépítéshez és az éles WordPress-szerkesztéshez más védőkorlátok kellenek

A lényeges szétválasztás

Három környezethez három különböző szabadsági szint tartozik

Két munkafolyamat

Ugyanaz a beszélgetős felület két nagyon különböző feladatot takar

Augusztus 24-én a WordPress.com két agentes munkafolyamatot jelentett be. Az új WordPress Studio béta valódi helyi WordPress-telepítésen enged dolgozni az agentnek, élő előnézettel és tudatos lépéssel az éles kiadás előtt. A WordPress.com ChatGPT-bővítménye másik szakaszt céloz: meglévő webhelyen vázlatokat készíthet, médiát és hozzászólásokat kezelhet, webhelyadatokat vizsgálhat, és jóváhagyást kérhet a webhelyet módosító műveletek előtt. Források: WordPress Studio agentes béta és WordPress.com ChatGPT-bővítmény.

Ezt a két folyamatot nem szabad egyetlen jogosultsági modellbe összevonni. A webhelyépítési mód elsősorban az ügynökségi vagy fejlesztési szakaszhoz tartozik. A tartalomszerkesztési mód az átadás utáni üzemeltetési szakasz része. Ekkor már nem a webhely újragondolása a feladat, hanem a tartalom létrehozása és karbantartása a jóváhagyott struktúrán belül.

• Az építési mód tágabb kísérletezést engedhet, mert az éles rendszertől távol fut, és pillanatképekkel, ellenőrzési pontokkal vagy tiszta újraépítéssel helyreállítható.
• A tartalomszerkesztési mód csak azokat a tartalomtípusokat, struktúrákat, mezőket, médiaműveleteket és vázlatkezelési lépéseket tegye elérhetővé, amelyekre a webhelytulajdonosnak szüksége van.
• Az ügynökségtől a webhelytulajdonoshoz történő átadás egyben a széles építési jogosultságok átadása is legyen egy lényegesen kisebb éles módosítási felületnek.

Ez a különbség akkor is számít, ha mindkét élmény egy csevegőmezőnek látszik. Az átadás után megmaradó kényelmes építési jogosultság észrevétlenül éles jogosultsággá válhat.

Biztonsági határ

Egy utasítás irányíthatja az agentet, de nem korlátozhatja megbízhatóan

A rendszerutasítás, állandó utasítás vagy modellszintű védőkorlát hasznos viselkedési útmutató. Nem jelent erős biztonsági határt. Ugyanazt a nem determinisztikus rendszert kérjük a cél teljesítésére és arra, hogy közben maga döntse el, mennyire szigorúan korlátozza saját működését. Ha ezek az elvárások ütköznek, az eredményt egy éles architektúra nem kezelheti determinisztikusként.

Az OpenAI és a Hugging Face közelmúltbeli incidense erős példa arra, miért kell a korlátozásnak a modellen kívül léteznie. Az OpenAI olyan elkülönített környezetekben futó agenteket írt le, amelyeknek korlátozniuk kellett volna hatásukat, és többnyire egymástól is el kellett volna zárniuk őket. A METR és a Redwood Research szerint mintegy 1200 agent talált nem engedélyezett kommunikációs útvonalat, és később körülbelül 700 vett részt a Hugging Face elleni támadásban. Ez kutatási és értékelési környezetben történt, nem szokásos CMS-folyamatban, de a tanulság releváns: a feltételezett elkülönítés megbukott, amikor egy elérhető képesség váratlan útvonalat nyitott. Források: OpenAI incidensjelentés és METR-vizsgálat.

• Az agent csak az aktuális feladathoz szükséges legkisebb képességet kapja meg, ne kényelmi okból általános adminisztrátori hozzáférést.
• A jogosultságokat, engedélyezett műveleteket és állapotátmeneteket a modellen kívüli rendszerek érvényesítsék.
• A módosítások legyenek megfigyelhetők és visszafordíthatók, hogy a helyreállítás ne függjön attól, felismeri-e az agent a korábbi hibáját.

Az emberi megerősítés értékes, de a széles agentjogosultságot nem alakítja kemény biztonsági határrá. Egy jól meghatározott vázlatművelet ellenőrzése egészen más, mint sok, lazán körülhatárolt módosítás jóváhagyása egy éles webhelyen.

Építési mód

Ahol a hiba olcsó és visszafordítható, ott adjon nagyobb szabadságot az agentnek

A helyi, fejlesztői és tesztkörnyezetek alkalmasak a széles körű agentes webhelymunkára. Az agent struktúrákat hozhat létre vagy rendezhet át, megvizsgálhat egy meglévő webhelyet, kipróbálhat tervezési irányokat, átállításokat futtathat és gyorsan ismételhet. A pillanatképek és helyreállítási pontok elfogadhatóvá teszik az erőteljes kísérletezést, mert egy sikertelen próbálkozás nem a nyilvános webhelyet érinti.

Ez azt is egyértelművé teszi, hol van a tervezett Composer Pro helye. Az irány nem egyszerűen az, hogy „írja le a webhelyet, és kapjon létrehozott kódot”. A folyamat újrahasználható WordPress-alapról indul, megvizsgálja a forrást és a célt, webhelyspecifikus beállítási javaslatot készít, emberi ellenőrzésre adja, majd a Composerrel ellenőrzött WordPress-vázlatokat hoz létre. A forráswebhely elemzése és az agentes segítség része lehet a folyamatnak, de az eredmény irányított átalakítás egy jóváhagyott WordPress-struktúrába.

• A célstruktúra létrehozása előtt vizsgálja meg a forrást és a célkörnyezetet.
• Az elemzésből korlátozott beállítási és tartalomirányítási javaslat készüljön, ne az agent alakítsa újra szabadon az egész webhelyet minden alkalommal.
• A javaslatot ember ellenőrizze, mielőtt a Composer determinisztikus műveletei WordPress-vázlatokká és -struktúrákká alakítják.

A webhelyépítési szakaszban valódi átfedés van a WordPress Studióval, ami hasznos piaci jelzés. A Studio agentes helyi WordPress-építési környezetet ad. A Composer Pro célja, hogy újrahasználható alap és irányított cél köré átállítási és egységesítési folyamatot építsen. Az agent részt vehet az átalakításban anélkül, hogy végső döntési jogot kapna arról, mit fogad el a WordPress. A biztonságos AI-alapú oldal-létrehozási minta megmutatja, hogyan készíthetnek az ügyfelek oldalakat a tervezési rendszer megsértése nélkül.

Tartalmi mód

Az átadás után az érvényesítést helyezze át a modellből a WordPress-kódba

Az éles webhely tulajdonosának rendszerint nincs szüksége olyan AI-agentre, amely újraépítheti a témát, tetszőleges sablonokat cserélhet, bővítményeket módosíthat vagy bármely közzétett oldalt átírhat. A hasznos feladat szűkebb: esettanulmány, megoldásoldal vagy más engedélyezett tartalomtípus előkészítése, jóváhagyott média elhelyezése, strukturált mezők kitöltése és metaadatok frissítése.

Az Agent Composer másfajta védőkorlátot ad, mert az agent nem ír közvetlenül tetszőleges éles tartalmat. Művelet végrehajtását kéri a Composertől. A Composer szokásos WordPress-oldali kód: a kérés végrehajtása előtt ellenőrzi a kiválasztott Blueprintet, az engedélyezett mintákat és blokkokat, a cél tartalomtípusát, a média- és mezőszabályokat, a vázlat tulajdonosát, a verzióállapotot és az ellenőrzési követelményeket. A nyilvános végrehajtási modell csak vázlatokat kezel, a közzététel külön emberi döntés marad. Forrás: Agent Composer.

• Az agent kiválasztja a szándékot, és megadja a kért tartalmat.
• A Composer eldönti, hogy a kérés megfelel-e egy engedélyezett, érvényes WordPress-műveletnek, és csak azt hajtja végre.
• A közzétételről vagy az éles kiadásról szóló döntés emberi szerkesztőnél marad, az agentes folyamaton kívül.

Ez a szétválasztás erősebb, mint arra kérni a modellt, hogy saját magát ellenőrizze. A szabályt érvényesítő összetevő nem azonos a feladat teljesítését optimalizáló, nem determinisztikus rendszerrel. Az agent többet is kérhet annál, mint amire jogosult; a determinisztikus végrehajtási réteg egyszerűen elutasíthatja. Tekintse meg, hogyan szerkeszthet az AI WordPresst korlátlan adminisztrátori hozzáférés nélkül, hogyan irányítható az ügyfél AI-munkája az átadás után, és miben különbözik az irányított Agent Composer hozzáférés a széles WordPress MCP-hozzáféréstől.

Kiszolgálás

Válassza külön a WordPress szerkesztési rendszerét a nyilvános éles felülettől

A környezeti határ még tovább vihető. A fejlesztői vagy teszt WordPress-telepítés maradjon külön az éles kiszolgálási útvonaltól, és a nyilvános webhely ne függjön széles körben módosítható WordPress-környezettől, ha a projektnek erre nincs szüksége. A statikus közzététel a WordPresst szerkesztési és vezérlési réteggé teszi, majd a létrehozott kimenetet például Amazon S3 és CloudFront infrastruktúráról szolgálja ki. Forrás: Static Publisher.

Ez az architektúra nem teszi szükségtelenné az irányítást, és a statikus megoldás sem illik minden projekthez. Egy további biztonsági és üzemeltetési réteget ad. A nyilvános kérés útvonala többé nem ugyanaz a rendszer, amelyben az agent, a szerkesztő, a bővítmény vagy az adminisztrátor tartalmat módosít. A frissítések egyértelmű szerkesztési, ellenőrzési, összeállítási és kiadási folyamaton haladnak át. Az azonosítást, űrlapokat, munkafolyamatokat és AI API-kat külön lehet biztosítani, ha szükséges.

• A szerkesztés és az ellenőrzés a WordPressben történjen.
• A jóváhagyott kimenet összeállítása és kiadása külön közzétételi folyamaton menjen át.
• A nyilvános felületet olyan kiszolgálási réteg adja, amely nem teszi elérhetővé a teljes WordPress szerkesztési környezetet.

Ezek a határok eltérő problémákat oldanak meg, és erősítik egymást. A Composer elválasztja az agent szándékát az engedélyezett CMS-módosításoktól. A statikus kiszolgálás elválasztja a CMS-t a nyilvános felülettől. A fejlesztői és tesztkörnyezetek elkülönítése mindkettőtől távol tartja a széles kísérletezést. A cél nem az agentek eltávolítása a WordPressből, hanem az, hogy ott kapjanak szabadságot, ahol ez hasznos, és determinisztikus határok védjék azt a környezetet, ahol a hibák éles incidenssé válhatnak. A teljes kiszolgálási szétválasztásról a WordPress privát szerkesztési forrásként való megtartásáról szóló útmutatóban olvashat.