С повече от 20 години опит ние променяме вашето цифрово присъствие. Специализирани сме в разработването на уебсайтове и електронни магазини, SEO и цифров маркетинг, ERP софтуер и интелигентна автоматизация, които извеждат бизнеса ви на следващото ниво.
Адрес:
Егнатия 154, Солун 546 36
Телефон:
+30 231 231 4095
Електронна поща:
hello@twodots.gr
Готови ли сте за следващата стъпка?;
Το multi-agent AI χρειάζεται versioning, isolation και ασφαλές commit όταν πολλοί agents διαβάζουν ή αλλάζουν την ίδια κατάσταση.
Το multi-agent AI concurrency control είναι ο μηχανισμός που εμποδίζει πολλούς agents να μετατρέψουν σωστές τοπικές ενέργειες σε λάθος κοινό αποτέλεσμα. Όταν οι agents διαβάζουν και αλλάζουν το ίδιο repository, CRM record, απόθεμα ή workflow, χρειάζονται εκδόσεις, isolation, conflict detection και ελεγχόμενο commit· περισσότερα μηνύματα ή καλύτερα prompts δεν προσφέρουν από μόνα τους αυτές τις εγγυήσεις.
Η υπόσχεση των multi-agent συστημάτων ακούγεται απλή: αν ένας AI agent μπορεί να εκτελέσει μια σύνθετη εργασία, περισσότεροι agents που συνεργάζονται παράλληλα θα την ολοκληρώσουν γρηγορότερα και καλύτερα. Στην πράξη, όμως, η προσθήκη agents μπορεί να μειώσει την αξιοπιστία. Το position paper των Xin Yang, Letian Li, Zimo Ji, Terry Jingchen Zhang και Wenyuan Jiang προτείνει μια ακριβέστερη διάγνωση: πολλά προβλήματα που περιγράφονται γενικά ως «κακός συντονισμός» είναι κλασικά προβλήματα ταυτόχρονης πρόσβασης σε κοινή κατάσταση.
Η διάκριση έχει πρακτική αξία. Αν μια ομάδα θεωρεί ότι το πρόβλημα είναι απλώς η επικοινωνία, πιθανόν να προσθέσει περισσότερα prompts, μηνύματα και ρόλους. Αν όμως η αιτία είναι stale read, lost update ή μη ασφαλής αλληλουχία ενεργειών, χρειάζονται μηχανισμοί συστήματος: versioning, locks, validation, isolation και ασφαλές rollback. Για επιχειρήσεις που χρησιμοποιούν agents σε κώδικα, περιεχόμενο, CRM, e-commerce ή λειτουργικές ροές, αυτή η οπτική μεταφέρει τη συζήτηση από το εντυπωσιακό demo στην αξιόπιστη παραγωγή, εκεί όπου οι λειτουργικές αστοχίες των AI agents γίνονται μετρήσιμο ρίσκο.
Όριο της βασικής πηγής: πρόκειται για position paper που εστιάζει σε συστήματα με ρητά shared mutable state, δηλαδή κοινή μεταβλητή κατάσταση. Οι συγγραφείς παρουσιάζουν τα trade-offs κυρίως ποιοτικά και ζητούν ευρύτερη εμπειρική επικύρωση· δεν υποστηρίζουν ότι κάθε αποτυχία multi-agent συνεργασίας είναι πρόβλημα concurrency.
Το paper χρησιμοποιεί ένα χαρακτηριστικό παράδειγμα από συνεργατική ανάπτυξη λογισμικού. Ο Agent A διαβάζει ένα αρχείο utilities και αρχίζει να γράφει κώδικα που καλεί μια συγκεκριμένη συνάρτηση. Όσο ο A «σκέφτεται», ο Agent B μετονομάζει τη συνάρτηση στο κοινό αρχείο. Κάθε agent έκανε κάτι λογικό με βάση την κατάσταση που είδε, αλλά το τελικό repository περιέχει σπασμένο import.
Το ουσιαστικό πρόβλημα δεν είναι ότι οι agents δεν αντάλλαξαν αρκετά μηνύματα. Ο A διάβασε μια έκδοση της κατάστασης η οποία έπαψε να ισχύει πριν ολοκληρώσει την πράξη του. Πρόκειται για stale read. Η μεγάλη διάρκεια του LLM inference διευρύνει αυτό το παράθυρο κινδύνου: μια εγγραφή σε αρχείο ή ένα API call μπορεί να διαρκεί χιλιοστά του δευτερολέπτου, ενώ η παραγωγή και αξιολόγηση μιας απάντησης διαρκεί δευτερόλεπτα ή λεπτά.
Η ίδια λογική εμφανίζεται έξω από τον κώδικα. Ένας agent μπορεί να διαβάσει απόθεμα προϊόντος, άλλος να δεσμεύσει την τελευταία μονάδα και ο πρώτος να συνεχίσει με πρόταση που βασίζεται σε παλιά διαθεσιμότητα. Σε μια ροή περιεχομένου, δύο agents μπορεί να επεξεργαστούν το ίδιο κείμενο και η τελευταία αποθήκευση να εξαφανίσει την προηγούμενη αλλαγή. Αυτά είναι επιχειρησιακά παραδείγματα εφαρμογής της ανάλυσης του paper, όχι περιστατικά που μέτρησαν οι συγγραφείς.
Οι συγγραφείς οργανώνουν το πρόβλημα γύρω από τέσσερα μοτίβα. Το πρώτο είναι το stale read: ένας agent ενεργεί πάνω σε πληροφορία που άλλαξε μετά την ανάγνωσή της. Το δεύτερο είναι το lost update: δύο agents διαβάζουν την ίδια αρχική έκδοση, κάνουν διαφορετικές αλλαγές και η δεύτερη εγγραφή αντικαθιστά σιωπηρά την πρώτη.
Το τρίτο είναι η stale correction. Ένας agent ανακοινώνει ένα σχέδιο, ένας δεύτερος στέλνει διόρθωση, αλλά ένας τρίτος έχει ήδη ξεκινήσει να εκτελεί την παλιά εκδοχή. Η διόρθωση υπάρχει στα μηνύματα, όχι όμως ως ατομική αλλαγή που δεσμεύει όλο το σύστημα. Το τέταρτο είναι η αποσύνδεση μηνύματος και ενέργειας: σε ένα περιβάλλον όπου οι agents αλλάζουν και τον πραγματικό κόσμο του συστήματος, ένα μήνυμα μπορεί να περιγράφει κατάσταση που έχει ήδη ανατραπεί από άλλη ενέργεια.
Αυτή η ταξινόμηση βοηθά μια ομάδα να γράψει καλύτερα incident reports. Αντί για «ο agent μπερδεύτηκε», μπορεί να καταγράψει ποιος πόρος διαβάστηκε, ποια έκδοση είχε, ποιος τον άλλαξε, ποιο write χάθηκε και σε ποιο σημείο έπρεπε να γίνει validation. Η αιτία γίνεται παρατηρήσιμη και διορθώσιμη. Είναι το ίδιο όριο που χρειάζεται ένα multi-agent AI workflow με σαφή δικαιώματα και σημεία ελέγχου.
Το paper δανείζεται έννοιες από βάσεις δεδομένων. Consistency σημαίνει ότι το συνδυασμένο αποτέλεσμα των ενεργειών παραμένει συνεπές: δύο agents δεν θεωρούν ταυτόχρονα ότι έχουν αποκλειστική χρήση του ίδιου πόρου και οι προϋποθέσεις μιας ενέργειας εξακολουθούν να ισχύουν όταν αυτή εκτελείται. Είναι ιδιότητα του συνολικού συστήματος.
Isolation σημαίνει ότι η εργασία κάθε agent εξελίσσεται σαν να μην παρατηρεί ενδιάμεσες, ημιτελείς αλλαγές άλλων agents. Η ισχυρότερη σχετική απαίτηση είναι η serializability: το αποτέλεσμα της παράλληλης εκτέλεσης πρέπει να ισοδυναμεί με κάποια έγκυρη σειριακή σειρά. Δεν σημαίνει ότι όλα πρέπει να γίνονται πραγματικά ένα-ένα· σημαίνει ότι ο παραλληλισμός δεν πρέπει να δημιουργεί αποτέλεσμα που καμία ασφαλής σειριακή εκτέλεση δεν θα παρήγαγε.
Δεν χρειάζεται κάθε workflow την ίδια προστασία. Agents που γράφουν σε διαφορετικά, ανεξάρτητα αρχεία έχουν μικρότερο κίνδυνο. Agents που αλλάζουν το ίδιο checkout, το ίδιο CRM record ή την ίδια παραγγελία χρειάζονται ισχυρότερες εγγυήσεις. Το paper περιορίζει ρητά το επιχείρημά του στα συστήματα με κοινή μεταβλητή κατάσταση. Ένα AI agent harness για παραγωγή οφείλει επομένως να κάνει αυτά τα όρια εκτελέσιμους κανόνες και όχι απλές οδηγίες.
Η απαισιόδοξη προσέγγιση αποκτά lock πριν από την πρόσβαση σε έναν πόρο. Προλαμβάνει τη σύγκρουση, αλλά ένας agent μπορεί να κρατά το lock σε όλη τη διάρκεια μιας μακράς inference φάσης. Αυτό περιορίζει τον παραλληλισμό και δημιουργεί κίνδυνο deadlock, όταν agents περιμένουν κυκλικά πόρους που κρατούν άλλοι.
Η αισιόδοξη προσέγγιση επιτρέπει την παράλληλη εργασία και ελέγχει κατά το commit αν άλλαξε κάτι σχετικό. Αν εντοπιστεί σύγκρουση, η συναλλαγή ακυρώνεται και επαναλαμβάνεται. Ταιριάζει σε χαμηλό contention, αλλά σε έντονο ανταγωνισμό μπορεί να σπαταλά μεγάλο inference κόστος: ο agent ολοκληρώνει λεπτά reasoning και απορρίπτεται στο τέλος.
Δύο στρατηγικές για τον ίδιο κοινό πόρο
Pessimistic locking
Μειώνει την πιθανότητα σύγκρουσης σε ακριβές ή μη αναστρέψιμες πράξεις, αλλά μπορεί να κρατήσει ένα CRM record, αρχείο ή slot παραγγελίας κλειδωμένο όσο ο agent εκτελεί μακρύ inference.
Optimistic validation
Διατηρεί περισσότερο παραλληλισμό όταν το contention είναι χαμηλό, αλλά απαιτεί version token, καθαρό conflict feedback και φθηνό, idempotent retry όταν η βάση της απόφασης έχει αλλάξει.
Δεν υπάρχει μία καθολικά καλύτερη επιλογή. Η ομάδα πρέπει να εκτιμήσει το κόστος αναμονής, το κόστος επανάληψης και την πιθανότητα σύγκρουσης ανά πόρο. Για μη αναστρέψιμες ενέργειες, όπως αποστολή email, χρέωση ή δημοσίευση, το validation πρέπει να συμβεί πριν από το side effect. Η απλή υπόσχεση ότι «θα κάνουμε rollback αργότερα» δεν αρκεί.
Κανόνας για εξωτερικά side effects: ένας agent μπορεί να ξαναγράψει ένα προσωρινό αρχείο, αλλά δεν μπορεί πάντα να αναιρέσει email, πληρωμή ή δημόσια δημοσίευση. Κρατήστε αυτές τις πράξεις πίσω από τελικό version check, μοναδικό idempotency key και, όταν το ρίσκο το απαιτεί, ανθρώπινο approval.
Το multiversion concurrency control διατηρεί περισσότερες από μία εκδόσεις της κατάστασης, ώστε οι αναγνώστες να βλέπουν συνεπή snapshots χωρίς να μπλοκάρουν τους writers. Για έναν AI agent αυτό μπορεί να σημαίνει ότι όλες οι αναγνώσεις μιας υποεργασίας συνδέονται με συγκεκριμένη έκδοση αρχείων, μνήμης ή records. Πριν από το commit, το σύστημα ελέγχει αν το write set συγκρούεται με νεότερες αλλαγές.
Η δυσκολία είναι ότι οι πόροι ενός agentic workflow δεν είναι μόνο rows σε βάση δεδομένων. Περιλαμβάνουν αρχεία, prompts, tool outputs, mailboxes, εξωτερικά APIs και δεσμεύσεις διατυπωμένες σε φυσική γλώσσα. Η έννοια της «έκδοσης» πρέπει επομένως να σχεδιαστεί για κάθε πόρο. Ένα revision hash λειτουργεί για κώδικα, ένα ETag για API resource, ένα updated_at για CRM record και ένα message sequence number για ουρά.
Η πρακτική αρχή είναι απλή: κάθε σημαντική απόφαση πρέπει να μπορεί να απαντήσει «σε ποια έκδοση της πραγματικότητας βασίστηκε;». Αν η απάντηση δεν καταγράφεται, η διάγνωση μιας αστοχίας γίνεται εικασία. Σε customer support, για παράδειγμα, οι AI agents εξυπηρέτησης πελατών χρειάζονται versioned ιστορικό και ownership πριν ενημερώσουν ticket, επιστροφή ή υπόσχεση προς τον πελάτη.
Μια συναλλαγή μπορεί να είναι ένα tool call ή ολόκληρη υποεργασία. Οι λεπτές συναλλαγές μικραίνουν το παράθυρο σύγκρουσης, αλλά αυξάνουν το coordination overhead. Οι χοντρές συναλλαγές μειώνουν τις ενδιάμεσες διαδικασίες, όμως μια αποτυχία αργά στη ροή απαιτεί ακριβό rollback.
Ανάλογο trade-off υπάρχει στο resource granularity. Το κλείδωμα ολόκληρου αρχείου είναι απλό, αλλά εμποδίζει δύο agents να αλλάξουν ανεξάρτητες συναρτήσεις. Το κλείδωμα ανά συνάρτηση επιτρέπει περισσότερο παραλληλισμό, απαιτεί όμως καλύτερη χαρτογράφηση εξαρτήσεων. Σε ένα e-commerce workflow, αντίστοιχη επιλογή είναι αν κλειδώνεται ολόκληρη η παραγγελία, μία γραμμή προϊόντος ή μόνο η μετάβαση κατάστασης.
Το paper εξετάζει επίσης ρητά και σιωπηρά transaction boundaries. Με BEGIN και COMMIT ο agent έχει ευελιξία αλλά πρέπει να κατανοεί σωστά τη σημασιολογία. Όταν τα όρια τα συμπεραίνει το σύστημα, μειώνεται το γνωστικό βάρος του μοντέλου, αλλά ένα λάθος boundary μπορεί να τεμαχίσει μια ενιαία πράξη ή να δεσμεύσει υπερβολικά πολλούς πόρους.
Η σωστή μονάδα ελέγχου είναι ο κοινός πόρος και το side effect
Μην επιλέγετε lock ή validation συνολικά για «όλους τους agents». Ορίστε πολιτική ανά repository, αρχείο, CRM record, παραγγελία, mailbox και εξωτερική ενέργεια, με γνωστό version token, transaction boundary, owner, conflict rule και ασφαλή διαδρομή retry.
Οι συγγραφείς προτείνουν τρεις «drop-in» κατευθύνσεις. Πρώτον, branch ή worktree ανά subtask, ώστε κάθε agent να εργάζεται σε απομονωμένο χώρο και οι αλλαγές να περνούν από merge validation. Δεύτερον, transactional file edits, όπου μια πολυ-αρχειακή αλλαγή απορρίπτεται αν τα σχετικά αρχεία μεταβλήθηκαν πριν από το commit. Τρίτον, validation στο merge με tests, type checks και σημασιολογικούς κανόνες πέρα από την απλή επίλυση textual conflicts.
Η απομόνωση δεν λύνει μόνη της τις λογικές συγκρούσεις. Δύο branches μπορεί να συγχωνεύονται χωρίς textual conflict και παρ’ όλα αυτά να παραβιάζουν μια επιχειρησιακή invariant. Γι’ αυτό τα checks πρέπει να εκφράζουν τι σημαίνει «σωστό»: επιτυχία tests, έγκυρη schema migration, μοναδικότητα μιας εγγραφής ή συμβατότητα API. Το ίδιο μάθημα εμφανίζεται στην τεκμηρίωση μεγάλων codebases με multi-agent AI, όπου οι υποεργασίες χρειάζονται σαφή όρια και ενοποίηση.
Για μη τεχνικές ομάδες, η ίδια αρχή μεταφράζεται σε ιδιοκτησία αντικειμένων και gates. Ένας agent προετοιμάζει περιεχόμενο, άλλος κάνει fact-check, αλλά μόνο ένα ελεγχόμενο βήμα μπορεί να αλλάξει την κατάσταση σε approved και να ενεργοποιήσει δημοσίευση. Έτσι μειώνεται και το κρυφό κόστος του AI output που χρειάζεται ξαναγράψιμο μετά από ασύμβατες παράλληλες αλλαγές.
File systems, βάσεις δεδομένων και Git ήδη διαθέτουν ώριμους μηχανισμούς atomicity, transactions, branches και merges. Το κενό βρίσκεται στην πολιτική: πότε απομονώνεται μια εργασία, ποιες συγκρούσεις είναι αποδεκτές και ποια invariants πρέπει να προστατεύονται. Το framework του agent δεν μπορεί απλώς να «χρησιμοποιεί Git»· πρέπει να ορίζει πώς συνδέονται οι εκδόσεις με τις αποφάσεις του agent.
Το paper συνδέει επίσης την ταχύτητα inference με την αξιοπιστία concurrency. Continuous batching, paged attention, speculative decoding και quantization μειώνουν τον χρόνο που μια συναλλαγή μένει ανοιχτή ή μια ανάγνωση μπορεί να παλιώσει. Αυτό δεν αντικαθιστά τον έλεγχο σύγκρουσης, αλλά μικραίνει το παράθυρο κινδύνου.
Για αισιόδοξο έλεγχο χρειάζεται οικονομικό rollback. Οι συγγραφείς αναφέρουν το checkpointing του KV cache ως πιθανή υποδομή για επιστροφή σε προηγούμενο σημείο χωρίς πλήρη επανεκτέλεση. Η πρόταση παραμένει ερευνητική κατεύθυνση, ιδιαίτερα όταν η εργασία περιλαμβάνει εξωτερικά side effects που δεν μπορούν να αναιρεθούν. Η σύνδεση παλαιών εφαρμογών σε agents, όπως στο agentic nesting εταιρικών συστημάτων, χρειάζεται ακριβώς αυτό το συμβόλαιο ανάμεσα σε tool, state και δυνατότητα αντιστάθμισης.
Ένα prompt μπορεί να ζητά από τον agent να ελέγχει ξανά την κατάσταση, να αποκτά πόρους με σταθερή σειρά ή να υποχωρεί μετά από conflict. Μπορεί επίσης να γίνει decomposition ώστε οι agents να δουλεύουν σε όσο γίνεται ανεξάρτητους πόρους. Αυτές είναι χρήσιμες παρεμβάσεις χαμηλού κόστους.
Ωστόσο, οι συγγραφείς τις θεωρούν εύθραυστες. Η τήρηση ενός prompt εξαρτάται από τις δυνατότητες και τη μη ντετερμινιστική συμπεριφορά του μοντέλου. Όσο αυξάνονται οι agents και η αλληλεξάρτηση, η φυσική γλώσσα δεν παρέχει από μόνη της auditable isolation ή atomicity.
Η πιο αξιόπιστη αρχιτεκτονική μοιράζει τις ευθύνες: το σύστημα επιβάλλει μη διαπραγματεύσιμες εγγυήσεις, ενώ το μοντέλο λαμβάνει σημασιολογικό feedback για να προσαρμόσει τη στρατηγική του. Ένα μήνυμα όπως «η εγγραφή σου συγκρούστηκε με νεότερη αλλαγή στο συγκεκριμένο record» είναι πιο χρήσιμο από ένα αδιαφανές «retry».
Η συνολική επιτυχία δεν αρκεί για να εντοπίσει το bottleneck. Το paper ζητά benchmarks που μεταβάλλουν ελεγχόμενα το contention και μετρούν conflict rate, ποσοστό επιτυχούς επίλυσης, χαμένο υπολογιστικό κόστος από aborts και πραγματικό throughput υπό ανταγωνισμό. Προτείνει ακόμη αξιολόγηση της ικανότητας ενός agent να προβλέπει, να εντοπίζει και να επιλύει συγκρούσεις.
Για μια επιχείρηση αυτό μεταφράζεται σε λειτουργικά observability δεδομένα: version read, version committed, read/write set, διάρκεια inference, χρόνος αναμονής για lock, λόγος abort, αριθμός retries και εξωτερικά side effects. Με αυτά τα στοιχεία η ομάδα μπορεί να ξεχωρίσει αποτυχία reasoning από race condition ή ανεπαρκές orchestration.
Το paper παραθέτει αποτελέσματα προηγούμενων συστημάτων και benchmarks ως ενδείξεις ότι οι μηχανισμοί concurrency επηρεάζουν το αποτέλεσμα. Οι αριθμοί δεν αποτελούν ενιαίο συγκρίσιμο experiment του ίδιου paper και γι’ αυτό δεν μετατρέπονται εδώ σε γράφημα. Η ασφαλής ανάγνωση είναι ότι υπάρχει αρκετή συγκλίνουσα ένδειξη για συστηματική έρευνα, όχι ότι έχει αποδειχθεί μία καθολική συνταγή.
Η ομάδα πρέπει να χαρτογραφήσει κοινή κατάσταση, invariants και εξωτερικές πράξεις πριν προσθέσει παραλληλισμό. Τα επτά βήματα που ακολουθούν μεταφέρουν τη θέση του paper σε παραγωγικό έλεγχο για κώδικα, CRM, e-commerce, περιεχόμενο και λειτουργικούς αυτοματισμούς.
Από τον παράλληλο agent στο ασφαλές commit
Καταγράψτε repositories, αρχεία, έγγραφα, CRM records, αποθέματα, παραγγελίες, queues, calendars και APIs που μπορούν να διαβάσουν ή να αλλάξουν περισσότεροι agents.
Δηλώστε τι σημαίνει σωστό ανά πόρο: μοναδική κράτηση, έγκυρη μετάβαση κατάστασης, συμβατό API, πλήρες ιστορικό ticket ή μία μόνο δημόσια δημοσίευση.
Χρησιμοποιήστε revision hash, ETag, updated_at ή sequence number και συνδέστε το version read με το plan, το tool call και το version committed.
Αποφασίστε αν η μονάδα ελέγχου είναι tool call, υποεργασία, αρχείο, συνάρτηση, record ή μετάβαση παραγγελίας με βάση contention, inference cost και κόστος rollback.
Χρησιμοποιήστε branches, worktrees, ξεχωριστούς owners ή disjoint workspaces και περάστε τις εξαρτώμενες αλλαγές από merge validation, tests και σημασιολογικά gates.
Βάλτε email, πληρωμές, δημοσιεύσεις και χρεώσιμα API calls πίσω από τελικό preflight, idempotency key, approval ή transactional outbox όπου είναι τεχνικά εφικτό.
Καθυστερήστε σκόπιμα έναν agent, αλλάξτε state στη μέση του inference και μετρήστε conflicts, aborts, lock waits, wasted inference, διπλά effects και task success σε δυσμενή interleavings.
Η βασική συνεισφορά του paper είναι μια γλώσσα σχεδιασμού. Αν οι αστοχίες ονομαστούν stale reads, lost updates, isolation violations και rollback failures, μπορούν να αξιοποιηθούν δεκαετίες γνώσης από databases, distributed systems και programming languages. Οι τεχνικές χρειάζονται προσαρμογή, επειδή οι agents λειτουργούν με φυσική γλώσσα, μεγάλη latency και μη ντετερμινιστική συμπεριφορά.
Το πρακτικό συμπέρασμα είναι συγκεκριμένο: περισσότερος παραλληλισμός δεν είναι δωρεάν. Πριν ζητήσετε από δέκα agents να μοιραστούν το ίδιο περιβάλλον, βεβαιωθείτε ότι το σύστημα γνωρίζει ποιος διάβασε τι, ποιος μπορεί να γράψει, πώς εντοπίζεται μια αλλαγή και τι συμβαίνει όταν δύο σωστές τοπικές αποφάσεις δεν μπορούν να συνυπάρξουν. Αυτό είναι ένα από τα βασικά περάσματα από το AI agent demo στην παραγωγή.
Автоматизация на бизнеса и AI
Η TWO DOTS χαρτογραφεί κοινή κατάσταση, δικαιώματα, versioning, validation, approvals και observability, ώστε agents, CRM, e-commerce και λειτουργικά εργαλεία να συνεργάζονται χωρίς χαμένες αλλαγές ή διπλά side effects.
Често задавани въпроси
Είναι οι κανόνες και οι μηχανισμοί που ελέγχουν πώς πολλοί AI agents διαβάζουν και αλλάζουν κοινούς πόρους, ώστε ο παραλληλισμός να μη δημιουργεί stale reads, χαμένες αλλαγές ή ασυνεπή αποτελέσματα.
Τα περισσότερα μηνύματα δεν εγγυώνται atomicity, isolation ή έλεγχο έκδοσης. Αν η κοινή κατάσταση αλλάξει όσο ένας agent εκτελεί inference, το σύστημα πρέπει να εντοπίσει τη σύγκρουση πριν δεσμευτεί η ενέργεια.
Στο stale read μια απόφαση βασίζεται σε έκδοση που έχει ήδη αλλάξει. Στο lost update μια μεταγενέστερη εγγραφή αντικαθιστά σιωπηρά μια προηγούμενη αλλαγή αντί να τη συγχωνεύσει ή να αναφέρει σύγκρουση.
Τα locks ταιριάζουν περισσότερο σε σπάνιους αλλά ακριβούς ή μη αναστρέψιμους πόρους, ενώ η αισιόδοξη επικύρωση σε χαμηλό contention και εύκολα retries. Η επιλογή πρέπει να βασίζεται στο κόστος αναμονής, σύγκρουσης και επανάληψης.
Δίνουν σε κάθε agent απομονωμένο χώρο εργασίας και μεταφέρουν τη σύγκρουση σε ελεγχόμενο merge. Παραμένουν απαραίτητα tests και σημασιολογικοί κανόνες, επειδή ένα clean merge μπορεί να παραβιάζει επιχειρησιακή invariant.
Χρειάζεται τελικό validation της τρέχουσας έκδοσης, σαφής ιδιοκτησία του side effect και, όπου υποστηρίζεται, idempotency key ή approval gate ώστε ένα retry να μην εκτελέσει την πράξη δύο φορές.
Χρήσιμα metrics είναι τα version mismatches, conflict rate, aborts, retries, lock wait time, χαμένο inference, διάρκεια συναλλαγής, effective parallelism και τα εξωτερικά side effects ανά εκτέλεση.
Το πλαίσιο αφορά κυρίως συστήματα με ρητά κοινή mutable state και περιγράφει τα trade-offs ποιοτικά. Δεν αποτελεί καθολικό benchmark ούτε αποδεικνύει ότι κάθε αποτυχία multi-agent συνεργασίας είναι race condition.
Източници
