Πώς Λειτουργεί ένας Συνομιλητικός Πράκτορας AI από Μέσα

Πώς Λειτουργεί Ένας Συνομιλητικός Πράκτορας ΤΝ Εσωτερικά (Αρχιτεκτονική OpenClaw)

Πώς λειτουργεί ένας συνομιλητικός πράκτορας ΤΝ στην πράξη, γύρο με γύρο; Αυτό το άρθρο ανοίγει το μαύρο κουτί του OpenClaw: από τη στιγμή που το μήνυμα του πελάτη φτάνει στο WhatsApp μέχρι το κείμενο που ο πράκτορας γράφει πίσω. Θα είναι τεχνικό. Αξίζει τον κόπο αν αποφασίζετε αρχιτεκτονική προϊόντος, αν πρόκειται να αγοράσετε μια λύση και θέλετε να αξιολογήσετε σε βάθος, ή αν σας αρέσει να ξέρετε τι συμβαίνει πίσω από τη συνομιλία.

TL;DR: κάθε γύρος περνάει από 6 στάδια — ingest, επίλυση πλαισίου, επιλογή skills, απόφαση επόμενης ενέργειας, εκτέλεση με guard-rails, αποθήκευση μνήμης. Ολόκληρος ο κύκλος τρέχει σε <2 δευτερόλεπτα στο edge της Cloudflare, χωρίς σταθερό server.

---

Γιατί η αρχιτεκτονική έχει σημασία

Συνομιλητικός πράκτορας που φαίνεται να λειτουργεί σε ένα demo αλλά σπάει στην παραγωγή συνήθως έχει ένα από αυτά τα 4 προβλήματα:

1. Υψηλή καθυστέρηση — ο πελάτης περιμένει 8 δευτερόλεπτα για απάντηση, η συνομιλία πεθαίνει.
2. Ανεξέλεγκτη ψευδαίσθηση — ο πράκτορας επινοεί τιμή, ωράριο, πολιτική.
3. Χαμένο πλαίσιο — ο πελάτης επιστρέφει μετά από 2 μέρες και ο πράκτορας "ξεχνάει" τα πάντα.
4. Ανεξέλεγκτο κόστος — κάθε μεγάλη συνομιλία γεμίζει το prompt και πληρώνετε περιουσία σε tokens.

Και τα 4 είναι επιλογές αρχιτεκτονικής, όχι περιορισμοί του μοντέλου. Το OpenClaw χτίστηκε για να αποφεύγει και τα 4 — και ο τρόπος για να το κατανοήσετε είναι να δείτε τον κύκλο ενός γύρου.

---

Ο κύκλος ενός γύρου (6 στάδια)

Φανταστείτε ότι ο πελάτης μόλις έστειλε το μήνυμα "quero marcar pra sábado de manhã". Τι συμβαίνει μεταξύ του "received" και της απάντησης του πράκτορα;

Στάδιο 1 — Ingest (edge worker, <50ms)

Το μήνυμα του WhatsApp φτάνει μέσω webhook της Meta κατευθείαν σε έναν Cloudflare Worker στο πλησιέστερο γεωγραφικά σημείο παρουσίας (PoP). Στη Βραζιλία, αυτό σημαίνει Σάο Πάολο ή Ρίο, καθυστέρηση δικτύου < 20ms.

Ο worker κάνει τρία πράγματα:

1. Επικυρώνει την υπογραφή του webhook (HMAC έναντι του μυστικού της WABA).
2. Αναγνωρίζει τον tenant από τον αριθμό τηλεφώνου του παραλήπτη (multi-tenant μέσω to_number).
3. Κανονικοποιεί το payload — ο ήχος γίνεται μεταγραφή, η εικόνα γίνεται περιγραφή, η τοποθεσία γίνεται {lat,lng}, το κείμενο μένει ως έχει.

Στο τέλος του σταδίου 1 έχετε ένα αντικείμενο {tenant_id, conversation_id, user_message} έτοιμο για το επόμενο βήμα.

Στάδιο 2 — Επίλυση πλαισίου (D1 + KV, ~80ms)

Ο πράκτορας χρειάζεται 3 κομμάτια πλαισίου πριν αποφασίσει:

• Πρόσφατο ιστορικό της συνομιλίας (τελευταίοι N σχετικοί γύροι).
• Μακροπρόθεσμη μνήμη του πελάτη (προτιμήσεις, ιστορικό αγορών, σημειώσεις).
• Κατάσταση του agent (persona, ενεργοποιημένα skills, κανόνες).

Όλα προέρχονται από το D1 (κατανεμημένη SQLite της Cloudflare). Το D1 αντικαθιστά τα παραδοσιακά Postgres/Mongo — χωρίς server βάσης δεδομένων για συντήρηση, πρόσβαση σε λίγα ms από τον worker, multi-tenant μέσω tenant_id.

Βασικό σημείο: εμείς δεν φορτώνουμε ολόκληρη τη συνομιλία στο prompt. Ο Memory Manager v2 του OpenClaw (που περιγράφεται στην εσωτερική τεκμηρίωσή μας) επιλέγει μόνο τους σχετικούς γύρους για τον τρέχοντα γύρο (τελευταίοι N + N υψηλής σημασιολογικής συνάφειας). Αυτό διατηρεί το κόστος token προβλέψιμο ακόμα και σε συνομιλίες 100+ γύρων.

Στάδιο 3 — Επιλογή skills (policy engine, ~20ms)

Κάθε agent έχει ένα σύνολο διαθέσιμων skills — λειτουργίες που μπορεί να καλέσει. Παραδείγματα: consultar_calendario, criar_evento, gerar_link_pagamento, consultar_pedido, chamar_humano.

Δεδομένου του μηνύματος "quero marcar pra sábado de manhã", ο policy engine φιλτράρει:

• Skills συμβατά με την ανιχνευμένη πρόθεση (προγραμματισμός ραντεβού).
• Skills επιτρεπόμενα για αυτή τη φάση της συνομιλίας (δεν είναι όλα τα skills διαθέσιμα συνεχώς).
• Skills που αυτός ο tenant έχει ενεργοποιήσει (το calendar εμφανίζεται μόνο αν ο tenant έχει κάνει ενσωμάτωση).

Στο τέλος έχετε ένα μικρό υποσύνολο skills που περνάει στο μοντέλο — όχι τα 50 πιθανά, μόνο τα 4 που έχουν νόημα εδώ. Αυτό μειώνει δραστικά την πιθανότητα το μοντέλο να καλέσει λάθος skill.

Στάδιο 4 — Απόφαση (LLM call, 400-1200ms)

Τώρα μπαίνει το μοντέλο. Το OpenClaw κάνει μία μοναδική κλήση σε ένα LLM αιχμής (Anthropic Claude, OpenAI GPT, Google Gemini — παραμετροποιήσιμο ανά tenant) με:

• System prompt = persona του agent + κανόνες + διαθέσιμα skills.
• History = γύροι που επιλέχθηκαν στο στάδιο 2.
• User message = μήνυμα του τρέχοντος γύρου.

Το μοντέλο απαντά ένα από δύο πράγματα:

• Τελική απάντηση (κείμενο απευθείας προς τον πελάτη).
• Tool call (αίτημα εκτέλεσης ενός συγκεκριμένου skill με παραμέτρους).

Στο παράδειγμα "quero marcar pra sábado de manhã", το μοντέλο τυπικά επιστρέφει:

{
  "tool": "consultar_calendario",
  "args": { "date_range": "2026-04-19 06:00 to 12:00" }
}

Στάδιο 5 — Εκτέλεση με guard-rails (μεταβλητό, ~100-500ms)

Το skill δεν τρέχει στο μοντέλο. Τρέχει σε δικό μας κώδικα, ο οποίος:

1. Επικυρώνει παραμέτρους (το date_range έχει σωστή μορφή; είναι εντός των κανόνων του tenant;).
2. Ελέγχει δικαιώματα (αυτός ο agent έχει δικαίωμα να αναζητήσει αυτό το ημερολόγιο;).
3. Εκτελεί την κλήση (Google Calendar API σε αυτή την περίπτωση).
4. Επιστρέφει δομημένο αποτέλεσμα στο μοντέλο.

Γιατί αυτό έχει σημασία; Επειδή το μοντέλο δεν κατασκευάζει ποτέ το αποτέλεσμα. Αν το ημερολόγιο επιστρέψει [10h, 11h], αυτό ακριβώς πηγαίνει στην επόμενη κλήση. Αν το skill αποτύχει, το μοντέλο γνωρίζει ότι απέτυχε. Μηδενικός κίνδυνος ο agent να «επινοήσει» ότι υπάρχει διαθέσιμο ραντεβού στις 9π.μ. όταν δεν υπάρχει.

Για περιπτώσεις που περιλαμβάνουν ευαίσθητες πληροφορίες (τιμή, προθεσμία, όνομα πελάτη), το pipeline επιβάλλει tool call — δεν αφήνει το μοντέλο να απαντήσει από τη δική του «γνώση». Αυτό εξαλείφει την κατηγορία ψευδαισθήσεων που είναι πιο συχνή σε εμπορικούς agents.

Στάδιο 6 — Απάντηση και αποθήκευση (~50ms)

Με το αποτέλεσμα του skill στα χέρια, το μοντέλο κάνει τη δεύτερη κλήση — τώρα για να σχηματίσει την τελική απάντηση προς τον πελάτη. Π.χ.:

"Έχω Σάββατο στις 10π.μ. και 11π.μ. Ποια προτιμάτε;"

Παράλληλα, ο worker:

1. Αποστέλλει το μήνυμα πίσω μέσω του API του WhatsApp.
2. Αποθηκεύει τον πλήρη γύρο (user + assistant + tool calls + διάρκεια) στο D1.
3. Ενημερώνει τη μακροπρόθεσμη μνήμη αν ο γύρος παρήγαγε νέο γεγονός (π.χ.: "ο πελάτης προτιμά Σάββατο").
4. Εκπέμπει event παρατηρησιμότητας (μετρική καθυστέρησης, κόστος token, ποσοστό κλιμάκωσης).

Όλα αυτά τρέχουν παράλληλα. Η αποθήκευση δεν μπλοκάρει την αποστολή του μηνύματος — ο πελάτης δεν περιμένει το D1.

---

Πού βρίσκεται η άμυνα κατά των ψευδαισθήσεων

Agent που παραισθάνεται σε παραγωγή χάνει εμπιστοσύνη γρήγορα. Το OpenClaw έχει 4 γραμμές άμυνας:

1. Επιβεβλημένη πηγή αλήθειας. Πραγματικά δεδομένα (τιμή, ωράριο, όνομα) πάντα προέρχονται από skill, ποτέ από το μοντέλο μόνο του.
2. Διπλή επαλήθευση σε ευαίσθητα δεδομένα. Το ραντεβού επιβεβαιώνεται με τον πελάτη πριν αποθηκευτεί. Η πληρωμή επιβεβαιώνεται πριν δοθεί πρόσβαση.
3. Ρητοί αρνητικοί κανόνες. Η persona κάθε agent περιλαμβάνει "ποτέ μην επινοήσεις X, Y, Z" — το μοντέλο υπακούει.
4. Fallback σε άνθρωπο. Όταν κανένα skill δεν καλύπτει την ερώτηση, ο agent λέει "αφήστε με να το ελέγξω με την ομάδα" και ανοίγει ένα ticket — δεν μαντεύει.

Σε ελέγχους που κάναμε τους τελευταίους 6 μήνες (πραγματικές συνομιλίες που εξετάστηκαν χειροκίνητα), το ποσοστό πραγματικών ψευδαισθήσεων παρέμεινε κάτω από 0,3% των γύρων — και σχεδόν όλες οι περιπτώσεις οφείλονταν σε config (ο tenant ξέχασε να ενεργοποιήσει σχετικό skill), όχι σε σφάλμα του μοντέλου.

---

Το κόστος ανά συνομιλία

Η καλή αρχιτεκτονική είναι αόρατη μέχρι να δεις το τιμολόγιο. Δεδομένου ότι κάθε γύρος κάνει 1-2 κλήσεις LLM + αναζητήσεις σε D1, το τυπικό κόστος ανά ολοκληρωμένη συνομιλία (10-15 γύροι) είναι: