TC$mC$ on aivan napakymppi. Olet juuri mC$C$ritellyt tC$ysiverisen
Tila-automaatin (State Machine) ja KC$yttC$ytymispuun (Behavior Tree)
arkkitehtuurin, joka on elinehto sille, ettC$ autonomiset agentit selviC$vC$t
oikeassa maailmassa ilman jatkuvaa kaatumista. Se siirtC$C$ painopisteen
"sokeasta toivomisesta" tiukkaan tilanhallintaan.
TC$mC$ sopii tC$ydellisesti mesh-arkkitehtuuriisi. Kun nC$mC$ makrot
paketoidaan C$lykkC$iksi Rutiineiksi (Routines), joita voidaan hakea ja ajaa
dynaamisesti, jC$rjestelmC$stC$ tulee uskomattoman kestC$vC$.
KC$C$nnetC$C$npC$ tC$mC$ visiosi suoraan tiiviiksi mC$C$rittelyrakenteeksi
(esimerkiksi YAML- tai JSON-muotoon), jota jC$rjestelmC$si voi kC$yttC$C$.
Uusi Rutiini-arkkitehtuuri (Routine Definition)
TC$ssC$ on ehdotus siitC$, mC$ltC$ yksittC$isen ohjelmoidun rutiinin rakenne
nC$yttC$isi sinun logiikallasi:
routine_name: "whatsapp_send_file"
description: "LC$hettC$C$ valitun tiedoston aktiivisessa WhatsApp-chatissa."
# 1. & 2.1 LCHTCTILAEDELLYTYS
preconditions:
required_semantic_elements:
- role: "ICON"
name_or_desc: "Attachment"
- role: "INPUT"
name_or_desc: "Kirjoita viesti"
# 2.2 ALUSTUS (Jos preconditions == false)
init_routine:
type: "rest_call"
target: "http://127.0.0.1:7713/muscle/browser/fullscreen_and_navigate" #
Esim. mesh-muscle-api
payload:
url: "https://web.whatsapp.com"
force_fullscreen: true
max_retries: 2
wait_after_sec: 5.0
# VARSINAINEN MAKRO (Ajetaan vain, kun lC$htC6tila on todennettu)
steps:
- action: "vision_click"
target: "ICON: Attachment"
- action: "wait"
time: 1.5
- action: "ocr_click"
text: "Dokumentti"
# ... jatkuu
# 2.4 ESKALAATIO (Jos alustuskin epC$onnistuu)
escalation:
policy: "frontier_and_human"
gather_context: true # Ottaa screenshotin, AT-SPI-dumpin ja viimeisimmC$t
lokit
prompt_template: >
"Rutiini 'whatsapp_send_file' epC$onnistui tilatarkistuksessa.
Yritin alustaa selaimen, mutta odotettuja elementtejC$ ei lC6ytynyt.
Analysoi oheinen AT-SPI-kartta ja kuva, ja kerro minulle tai suorita
korjaava siirto."
Miten tC$mC$ prosessoidaan ajon aikana?
* Pre-Check (Semanttinen Validointi): Kun pyydC$t rutiinia ajoon,
orkestraattori pyytC$C$ x11-vision-api:lta tai AT-SPI-skannerilta ajantasaisen
MUD-kartan ruudusta. Se vertaa sitC$ preconditions -listaan. Jos ruudulla on
jo WhatsApp auki oikeassa chatissa, rutiini alkaa heti sC$C$stC$en aikaa ja
resursseja.
* REST-pohjainen Alustus: Jos tarkistus epC$onnistuu (kC$yttC$jC$ onkin
vaikka tyC6pC6ydC$llC$), orkestraattori katsoo init_routine -lohkoa. Koska
ympC$ristC6ssC$si on jo REST-rajapintoja (kuten MUD-agentteja ja
mikropalveluita), suora HTTP-kutsu selaimen ohjaus-API:in on 100x vakaampi
kuin nC$ppC$imistC6makro (Alt+Tab, Win+R jne.).
* Post-Check: Alustuksen jC$lkeen orkestraattori kiertC$C$ takaisin kohtaan
1. Ovatko elementit nyt ruudulla? Jos kyllC$, ajetaan varsinainen steps-lista.
* Eskalaatio: Jos elementtejC$ ei vielC$kC$C$n lC6ydy (esim. WhatsApp on
kirjautunut ulos ja vaatii QR-koodin skannausta), automaatio pysC$htyy
turvallisesti. Se ei ala klikkailla sokkona vC$C$riC$ asioita, vaan paketoi
semanttisen nykytilan (MUD-kartta) ja nC$yttC6kuvan, ja lC$hettC$C$ sen
raskaammalle LLM:lle ja/tai suoraan meidC$n chattiimme analysoitavaksi.
HyC6dyt
TC$mC$ eristC$C$ ohjelman tavoitteen (lC$hetC$ tiedosto) sen ympC$ristC6n
hallinnasta (varmista, ettC$ selain on auki). Se tekee rutiineista
C$C$rettC6mC$n uudelleenkC$ytettC$viC$.
Haluatko, ettC$ hahmottelen seuraavaksi pienen validointimoottorin
(Pythonilla), joka lukee tC$llaista YAML/JSON-rutiinia, tekee tuon AT-SPI
-tarkistuksen, suorittaa tarvittaessa REST-kutsun ja tekee eskalaatiopC$C$tC6ks
en?