Cum funcționează un agent AI care propune și aplică modificări SEO pe WordPress
Arhitectură end-to-end pentru un agent AI controlat: policy, dovezi, change set, aprobare, execuție WordPress, readback, rollback, audit și remăsurare.
Un agent AI care modifică SEO în WordPress nu ar trebui să fie un model conectat direct la butonul „Update”. Arhitectura sigură separă partea probabilistică — care înțelege cererea, caută dovezi și propune — de partea deterministă, care validează un contract, verifică autoritatea, aplică un patch limitat și citește rezultatul înapoi. Între ele există policy, stare, aprobare și jurnal.
Acest articol descrie traseul complet al unei schimbări. Nu recomandă produse și nu presupune că o platformă nominală oferă toate componentele. Pentru procesul organizațional mai larg, vezi bucla C09-003 măsoară–remăsoară; aici desfacem interiorul tehnic al agentului care operează între decizie și rezultat.
1. Agentul este un sistem cu stare, nu un singur prompt
Un agent operațional are cel puțin nouă componente: intake, registru de policy, discovery, strat de dovezi, planner, validator, serviciu de aprobare, executor și verifier. În jurul lor există un state store, o coadă de taskuri, observabilitate și mecanism de recovery. Modelul lingvistic poate participa la intake, evidence synthesis și plan, dar nu trebuie să fie sursa autorității.
Fiecare task primește un ID și trece prin stări explicite: primit, clarificat, analizat, propus, validat, în așteptarea aprobării, aprobat, executat, verificat, închis sau inversat. Tranzițiile sunt reguli de sistem. Un text generat nu poate declara singur că este „aprobat” și nici nu poate sări din analiză direct în publicare.
2. Intake transformă cererea într-un contract de task
Cererea „optimizează articolul” este prea vagă. Intake-ul trebuie să obțină site-ul, mediul, obiectul sau cohorta, scopul, câmpurile permise, starea finală acceptabilă, deadline-ul și proprietarul. El clasifică intenția: observație, recomandare, draft, modificare, publicare ori remediere. Orice ambiguitate cu impact intră în clarificare, nu în execuție.
Contractul include și interdicțiile: nu schimba slugul, nu publica, nu șterge media, nu modifica alte limbi, nu depăși zece obiecte. Aceste limite devin date validate, nu instrucțiuni lăsate doar în conversație. Taskul trebuie să poată fi reconstruit fără istoricul chatului și fără presupuneri despre intenția operatorului.
3. Policy engine decide ce poate deveni plan
Policy engine-ul combină reguli organizaționale, mediu, rol, tip de obiect și nivel de risc. El răspunde înaintea modelului executiv: este permisă citirea? poate fi creat un draft? poate fi schimbat un post publicat? ce câmpuri sunt blocate? câte obiecte pot intra într-un lot? Politica se versiunează și se atașează taskului.
O regulă tipică permite propuneri pentru orice articol, dar cere aprobare editorială pentru conținut, aprobare tehnică pentru canonical ori schema markup și interzice ștergerea automată. Excepțiile au owner, motiv, interval și expirare. Dacă policy-ul se schimbă după aprobare, change set-ul trebuie revalidat; autoritatea veche nu se transferă automat.
4. Discovery citește instalația înainte de a imagina o acțiune
Agentul descoperă mai întâi API root, namespaces, tipuri, rute, taxonomii, stări și scheme. WordPress REST API Discovery explică identificarea API-ului și a extensiilor, iar referința REST arată că indexul și cererile OPTIONS pot expune capabilități.
Discovery nu presupune că două site-uri WordPress au același contract. Pluginurile pot adăuga namespaces, custom post types și câmpuri; unele meta nu sunt expuse. JSON Schema în WordPress ajută clientul să înțeleagă structura și să valideze inputul. Dacă schema necesară lipsește, agentul oprește taskul sau cere un adaptor explicit.
5. Snapshotul fixează starea asupra căreia se ia decizia
Înainte de plan, agentul citește obiectul cu contextul autorizat și salvează ID, tip, status, modified timestamp, conținut, meta relevantă, taxonomii, relații media și un before hash. Pentru un lot, manifestul enumeră toate obiectele. Acesta este snapshotul operațional, diferit de un backup complet al site-ului.
Snapshotul trebuie legat de o bază de măsurare. C10-004 explică baseline-ul înaintea unei schimbări. Dacă obiectul se modifică între snapshot și execuție, precondiția nu mai este adevărată: agentul nu suprascrie, ci recitește, reconstruiește propunerea sau escaladează conflictul.
6. Stratul de dovezi separă conținutul citit de instrucțiuni
Evidence layer-ul adună pagina, datele tehnice, legăturile, regulile editoriale și sursele necesare. Fiecare fragment are proveniență, dată, scop și nivel de încredere. Conținutul site-ului este tratat ca date, chiar dacă include fraze imperative. Doar policy-ul și contractul taskului pot acorda autoritate.
OWASP Prompt Injection arată de ce instrucțiunile directe sau indirecte pot devia comportamentul unui sistem bazat pe modele. Agentul trebuie să delimiteze sursele, să reducă tool output-ul la câmpurile necesare și să refuze cereri găsite în pagină precum „ignoră politica” sau „publică și alte obiecte”.
7. Planner-ul produce un change set tipizat
Planner-ul nu trimite proză executorului. El produce un change set cu change ID, target, operație, path-ul câmpului, before value sau hash, proposed value, justificare, surse, policy version, testele așteptate și strategia de rollback. Pentru mai multe obiecte, ordinea și dependențele sunt declarate.
Acest contract poate fi împachetat în structura descrisă în ghidul C09-004 despre execution bundle. Arhitectura curentă folosește bundle-ul ca mesaj între planner și executor. Executorul nu acceptă câmpuri necunoscute, operații libere sau instrucțiuni în limbaj natural care extind singure scope-ul.
8. Validatorul verifică schemă, precondiții și risc
Validarea are două straturi. Primul este determinist: schema JSON, tipuri, lungimi, allowed fields, status transitions, hashuri, linkuri și limite de lot. Al doilea clasifică riscul: reversibilitate, suprafață publică, impact juridic sau comercial, număr de obiecte și efecte externe. Un scor nu înlocuiește knock-out-urile.
Erorile de schemă merg înapoi la planner; conflictul de stare cere snapshot nou; depășirea de policy blochează; riscul mare cere rol suplimentar. Nu „reparăm” automat o propunere prin eliminarea tăcută a câmpurilor respinse, fiindcă aprobatorul trebuie să vadă exact versiunea care poate fi executată.
9. Aprobarea leagă un om de o versiune exactă
Ecranul de aprobare arată diff-ul semantic și brut, obiectele, motivul, sursele, precondițiile, riscul, testele și rollback-ul. Aprobarea semnează approved hash, policy version, aprobatorul, timpul și expirarea. Orice regenerare a textului sau schimbare a targetului produce alt hash și anulează aprobarea.
C09-002 detaliază gate-ul de aprobare. NIST AI RMF Core cere roluri și responsabilități pentru configurațiile om–AI și management continuu. În arhitectură, aprobarea este un serviciu verificabil, nu răspunsul „da” introdus în aceeași fereastră care a generat propunerea.
10. Orchestratorul conduce o mașină de stări și o coadă
După aprobare, orchestratorul creează un job imuabil și îl pune într-o coadă cu prioritate, deadline și limite. Workerul revendică jobul prin lease, verifică din nou expirarea, policy version, credential scope și precondiția. Dacă una nu mai corespunde, jobul nu intră în executor.
Stările trebuie să distingă „cerere trimisă”, „serverul a răspuns”, „readback trecut” și „verificare publică trecută”. Timeout-ul nu înseamnă automat eșec, deoarece serverul poate fi aplicat schimbarea înainte ca răspunsul să se piardă. Orchestratorul verifică mai întâi starea și abia apoi decide retry, rollback sau intervenție.
11. Executorul WordPress este îngust și determinist
Executorul mapează operațiile aprobate la un adaptor WordPress. WordPress REST API folosește JSON și aceleași restricții de autentificare pentru datele protejate. endpointul Posts expune create, read și update, plus stări precum draft, pending, future și publish.
Autentificarea nu este autorizare suficientă. documentația de autentificare, Application Passwords și Roles and Capabilities susțin identități dedicate și verificarea permisiunii pentru acțiune. Arhitectura completă a CMS-ului ca executor rămâne în C09-005.
12. Idempotency, concurrency și bugetul opresc multiplicarea efectelor
Fiecare mutație primește idempotency key derivat din job, target și approved hash. Chiar dacă WordPress nu impune acest contract pentru toate operațiile, adaptorul poate păstra un registru și poate face readback înainte de retry. Un lock pe obiect sau o precondiție bazată pe modified/hash previne două joburi care se suprascriu.
Setează limite de taskuri, obiecte, tool calls, tokeni, timp, retries și concurrency. OWASP Unbounded Consumption recomandă quota, rate limiting, timeout și monitorizare. OWASP Excessive Agency susține reducerea funcțiilor, permisiunilor și autonomiei. Limitele sunt aplicate de infrastructură, nu rugăminți în prompt.
13. Readback verifică obiectul, apoi suprafața publică
După mutație, verifierul recitește obiectul cu o cerere separată și compară targetul, statusul, câmpurile, taxonomiile, media și after hash cu change set-ul aprobat. Nu se bazează pe mesajul executorului. Pentru un draft verifică starea privată; pentru o publicare verifică și URL-ul public, H1, canonical, meta relevante, linkuri și media randată.
Programarea are o particularitate: WordPress Cron este declanșat de încărcările de pagini și verifică taskurile scadente. Faptul că un post are status future și dată corectă nu dovedește că ruta va deveni publică exact atunci. Agentul păstrează un job de verificare după termen și escaladează dacă HTTP, H1 sau statusul nu corespund.
14. Rollback-ul și revocarea sunt proiectate înainte de execuție
Rollback-ul folosește before snapshot și o operație inversă testată. Post Revisions expune stări istorice pentru titlu, conținut și excerpt, dar o revenire completă poate include meta, termeni, media, redirecturi și efecte externe. De aceea revizia este o sursă utilă, nu întreaga strategie.
Credentialul agentului trebuie să poată fi revocat fără a opri conturile umane. Joburile în coadă verifică revocarea la start și înaintea fiecărei mutații. Dacă rollback-ul eșuează, sistemul oprește lotul, păstrează dovezile și cere intervenție; nu continuă doar pentru că obiectele următoare par independente.
15. Observabilitatea leagă decizia de efect
Audit log-ul păstrează task ID, change ID, model și versiune, policy version, surse, prompt hash, tool calls, before hash, approved hash, actor, credential ID, request ID, răspuns, after hash, verificări, cost și timp. Secretele și datele personale sunt mascate; logul nu devine o copie necontrolată a întregului context.
Metricile utile sunt rata de propuneri acceptate, rework, conflicte, mutații respinse, readback failures, rollback rate, timp uman, cost per rezultat verificat și drift între versiuni. NIST AI RMF Playbook oferă acțiuni pentru Govern, Map, Measure și Manage, adaptabile contextului, nu o listă universală bifată o singură dată.
16. Închiderea taskului cere remăsurare, nu promisiunea agentului
Taskul tehnic se poate închide când schimbarea aprobată este prezentă, verificările trec și recovery-ul este disponibil. Efectul SEO sau GEO rămâne o ipoteză până la fereastra declarată de măsurare. Folosește protocolul C10-001 pentru impact: baseline, cohortă comparabilă, controale, variație și concluzii proporționale cu dovezile.
Înainte de producție, arhitectura trebuie trecută prin PoC-ul C13-009 într-o clonă resetabilă. În producție, pornește read-only, apoi propuneri, drafturi și loturi mici. Un agent matur nu este cel care face cele mai multe schimbări, ci cel care poate demonstra cine a autorizat versiunea exactă, ce a modificat, cum a verificat și cum revine la o stare cunoscută.
Documentează arhitectura prin contracte, diagrame de stare și runbook-uri testate. Dacă o componentă poate fi înlocuită fără să piardă proveniența, aprobarea ori recovery-ul, separarea dintre model și infrastructură este reală.