सत्र स्थिति की जानकारी

जब कई सत्र एक ही समस्या पर काम करते हैं — कोई प्रबंधक चाइल्ड सत्रों को काम सौंप रहा हो, कोई व्यक्ति सीधे किसी वर्कर सत्र में प्रवेश कर रहा हो, या दो एजेंट sessions_send के माध्यम से समन्वय कर रहे हों — तो प्रत्येक सत्र दूसरे सत्रों के बारे में धारणाएँ बनाता है। किसी अन्य कर्ता के हस्तक्षेप करते ही वे धारणाएँ पुरानी हो जाती हैं। सत्र स्थिति जागरूकता वह तंत्र है जो हस्तक्षेप का पता लगाता है, प्रभावित सत्र को एक बार सूचित करता है, और कार्रवाई करने से पहले उसे कम लागत में अद्यतित होने का तरीका देता है।

तीन हिस्से मिलकर काम करते हैं:

1. एक टिकाऊ सिग्नल लॉग प्रत्येक सत्र के लिए चुने गए स्थिति परिवर्तनों को दर्ज करता है।
2. वॉचर प्रत्येक लक्ष्य के लिए कर्सर रखते हैं और पुरानी स्थिति की एक समेकित सूचना प्राप्त करते हैं।
3. समाधान changesSince के साथ session_status के माध्यम से सटीक अंतर प्राप्त करता है।

सिग्नल लॉग

जब किसी निगरानी किए जा रहे सत्र में महत्वपूर्ण परिवर्तन होता है, तो OpenClaw साझा स्थिति डेटाबेस (session_state_events) में एक टाइप किया हुआ इवेंट जोड़ता है। इवेंट में मेटाडेटा और एक-पंक्ति का सारांश होता है — संदेश की सामग्री कभी नहीं।

प्रत्येक इवेंट अपने कर्ता (human, agent, या system) का नाम बताता है। रद्द किए गए और समय-सीमा पार करने वाले चाइल्ड रन को विफलताओं के रूप में दर्ज किया जाता है और सटीक परिणाम (cancelled, timeout, या error) इवेंट पेलोड में सुरक्षित रहता है।

किसी सत्र का स्थिति संस्करण केवल उसके लॉग की सबसे बड़ी अनुक्रम संख्या है, जिसे एक टिकाऊ प्रति-सत्र हेड में ट्रैक किया जाता है जो छँटाई के बाद भी बना रहता है। जब किसी सत्र में परिवर्तन लॉग हुए हों, तो sessions_list पंक्तियों में stateVersion शामिल होता है; session_status हमेशा इसे रिपोर्ट करता है।

केवल-लॉग प्रकार समाधान इतिहास के लिए होते हैं, सूचना के लिए नहीं: सामान्य चाइल्ड-रन पूर्णता डिलीवरी का स्वामित्व सब-एजेंट घोषणाओं के पास रहता है और सिग्नल लॉग कभी इसकी नकल नहीं करता।

वॉचर

वॉचर वह सत्र है जो किसी लक्ष्य पर कर्सर (session_watch_cursors) रखता है। कर्सर दो स्थानों से आते हैं:

• अंतर्निहित (स्पॉन किनारे)। जब कोई सत्र किसी सब-एजेंट या ACP चाइल्ड को स्पॉन करता है, तो पैरेंट का कर्सर चाइल्ड के स्पॉन संस्करण पर स्वचालित रूप से आरंभ हो जाता है। पैरेंट कभी मैन्युअल रूप से सदस्यता नहीं लेते।
• स्पष्ट (sessions_send watch: true)। कोई भी समन्वयक बिना स्पॉन किए गए लक्ष्य की निगरानी कर सकता है: sessions_send पर watch: true पास करें, और भेजना सफलतापूर्वक डिस्पैच होने के बाद प्रेषक उस सत्र के वॉचर के रूप में पंजीकृत हो जाता है जिसने वास्तव में संदेश प्राप्त किया था। पंजीकरण लक्ष्य के वर्तमान स्थिति संस्करण से शुरू होता है — पिछला इतिहास कभी सूचनाएँ उत्पन्न नहीं करता। पैरामीटर सेट होने पर टूल परिणाम watched: true|false रिपोर्ट करता है।

वॉचर की पहचान एजेंट-योग्य सत्र कुंजी होनी चाहिए। session.scope="global" के अंतर्गत साझा global कुंजी विभिन्न एजेंटों में अस्पष्ट होती है, इसलिए ऐसे सत्रों को टिकाऊ लॉग और changesSince तो मिलता है, लेकिन सक्रिय सूचनाएँ नहीं मिलतीं।

निगरानियाँ स्वयं साफ़ हो जाती हैं: कर्सर पंक्तियों की समय-सीमा सिग्नल-लॉग अवधारण के साथ समाप्त होती है, वॉचर सत्र रीसेट होने पर उन्हें हटा दिया जाता है, और किसी भी सत्र के साथ उन्हें मिटा दिया जाता है। v1 में निगरानी बंद करने की कोई क्रिया नहीं है।

सत्र कैटलॉग से अपनाए गए निगरानी किए जा रहे सत्रों में निश्चित अंतराल पर सीधे अपस्ट्रीम मानवीय गतिविधि की जाँच की जाती है। पता लगाई गई गतिविधि अन्य प्रत्यक्ष मानवीय टर्न की तरह उसी सिग्नल लॉग और वॉचर प्रवाह में प्रवेश करती है।

यदि अपनाए गए सत्र का अपस्ट्रीम स्रोत बाहरी रूप से मिटा दिया जाता है, तो लगातार तीन अनुपलब्ध जाँचें (लगभग तीन मॉनिटर टिक) उसके वॉचर के लिए एक upstream_missing सिग्नल उत्पन्न करती हैं और अपस्ट्रीम लिंक हटा देती हैं। कैटलॉग सत्र को फिर जारी रखने पर नया लिंक बनता है।

सूचनाएँ: एक, अनेक नहीं

जब सूचना-योग्य इवेंट आता है और वॉचर का कर्सर पीछे होता है, तो वॉचर को अपने अगले टर्न पर एक सिस्टम सूचना मिलती है:

सत्र "agent:main:subagent:child" बदल गया (अन्य कर्ता)। कार्रवाई से पहले समाधान करें: session_status sessionKey "agent:main:subagent:child" changesSince 12.

मुख्य-सत्र वॉचर को Heartbeat वेक के माध्यम से तुरंत जगाया भी जाता है; नेस्टेड सब-एजेंट वॉचर को सूचना उनके अगले टर्न पर मिलती है।

प्रोटोकॉल जानबूझकर स्पैम-रोधी है:

• प्रत्येक वॉचर/लक्ष्य जोड़ी के लिए एक लंबित सूचना। लंबित रहने के दौरान सूचना टेक्स्ट बाइट-स्थिर रहता है और सिस्टम-इवेंट कतार उसके आधार पर डुप्लिकेट हटाती है, इसलिए एक ही लक्ष्य में तेज़ी से हुए बीस परिवर्तन भी वॉचर के प्रॉम्प्ट में केवल एक पंक्ति उत्पन्न करते हैं।
• स्थिर वॉटरमार्क। सूचना कतार में लगने पर कर्सर अपनी सूचित स्थिति पर स्थिर हो जाता है। आगे के महत्वपूर्ण इवेंट केवल महत्वपूर्ण वॉटरमार्क को आगे बढ़ाते हैं; वे दोबारा सूचना नहीं देते।
• ड्रेन पर अभिस्वीकृति, केवल बीच में आए काम के लिए फिर खोलना। जब वॉचर का टर्न सूचना का उपभोग करता है, तो कर्सर आगे बढ़ता है। यदि कतार में लगाने और ड्रेन करने के बीच और महत्वपूर्ण इवेंट आए हों, तो शेष भाग के लिए ठीक एक नई सूचना खोली जाती है।
• स्व-दमन। किसी वॉचर को उन इवेंट के बारे में कभी सूचित नहीं किया जाता जिन्हें उसने स्वयं उत्पन्न किया हो।
• पुनरारंभ पुनर्प्राप्ति। लंबित सूचनाएँ इन-मेमोरी कतार में रहती हैं; Gateway पुनरारंभ होने के बाद स्टार्टअप स्वीप उन्हें टिकाऊ कर्सर से फिर साकार करता है।

समाधान करना

सूचना वॉचर को सटीक रूप से बताती है कि क्या करना है। changesSince: <version> के साथ session_status उस संस्करण के बाद के टाइप किए हुए इवेंट (अधिकतम 200) लौटाता है, बिना किसी कर्सर को आगे बढ़ाए:

{  "stateVersion": 19,  "stateChanges": {    "events": [      {        "sequence": 14,        "kind": "human_direct_message",        "actorType": "human",        "summary": "Telegram के माध्यम से मानवीय संदेश"      },      { "sequence": 19, "kind": "goal_changed", "actorType": "human", "summary": "लक्ष्य अपडेट किया गया" }    ],    "historyGap": false  }}

historyGap: true का अर्थ है कि अनुरोधित संस्करण संरक्षित इतिहास से पहले का है — प्रतिक्रिया को सटीक अंतर मानने के बजाय पूरे सत्र की स्थिति (sessions_history, session_status) रीफ़्रेश करें। अंतराल सिग्नल सटीक है: यह प्रति-सत्र छँटे हुए वॉटरमार्क से आता है, अनुक्रम अंकगणित से अनुमानित नहीं होता।

भंडारण और सीमाएँ

इतिहास साझा स्थिति डेटाबेस में रहता है, जो 30 दिनों और 50,000 पंक्तियों तक सीमित है; प्रति-सत्र हेड छँटाई के बाद भी एकदिश रूप से बढ़ते रहते हैं। रिकॉर्डिंग सर्वोत्तम-प्रयास है — विफल जोड़ को लॉग किया जाता है और उससे मूल टर्न कभी विफल नहीं होता — इसलिए stateVersion एक सिग्नल-लॉग हेड है, लेन-देन संबंधी परिवर्तन-डेटा-कैप्चर संस्करण नहीं।

वर्तमान सीमाएँ:

• सूचना डिलीवरी यह मानती है कि एक Gateway प्रक्रिया साझा स्थिति डेटाबेस की स्वामी है। अनेक Gateway टिकाऊ लॉग और changesSince साझा करते हैं, लेकिन v1 प्रक्रियाओं के बीच सूचनाएँ पुश नहीं करता।
• Compaction इवेंट एम्बेडेड रनटाइम के Compaction स्वामियों को कवर करते हैं; केवल नेटिव हार्नेस में होने वाला Compaction पूरी तरह लॉग नहीं होता।
• रद्द किए गए परिणाम का पेलोड विवरण वर्तमान में ACP चाइल्ड रन द्वारा उत्पन्न होता है; नेटिव सब-एजेंट रद्दीकरण सामान्य विफलताओं के रूप में दिखाई देते हैं।
• अपस्ट्रीम स्व-प्रतिध्वनि पहचान सामान्यीकृत उपयोगकर्ता टेक्स्ट की तुलना करती है। सत्र के 10 सबसे हाल के OpenClaw-पक्षीय उपयोगकर्ता संदेशों में से किसी एक से मेल खाने वाला बाहरी प्रॉम्प्ट स्व-प्रतिध्वनि माना जाता है।
• प्रति-अंतराल 1 MiB स्कैन सीमा से बड़ी एक स्थानीय Claude JSONL पंक्ति v1 में उस सत्र के कर्सर को अवरुद्ध कर देती है; अवर्गीकृत बाइट को कभी छोड़ा नहीं जाता।
• युग्मित-नोड Claude जाँचें प्रत्येक अंतराल में नवीनतम 50 ट्रांसक्रिप्ट आइटम वर्गीकृत करती हैं। बड़े बर्स्ट v1 स्कैन विंडो से बाहर हो सकते हैं।
• युग्मित-नोड Claude इतिहास पठन निश्चित थ्रेड-नहीं-मिला परिणाम उपलब्ध नहीं कराता, इसलिए रिमोट Claude विलोपन को v1 में upstream_missing के रूप में वर्गीकृत नहीं किया जाता।
• जो कैटलॉग सत्र अपनाए नहीं गए हैं, वे v1 में जागरूकता परत से बाहर रहते हैं।
• इस सुविधा से पहले अपनाए गए सत्रों में कोई अपस्ट्रीम लिंक नहीं होता; अपस्ट्रीम निगरानी शुरू करने के लिए उन्हें कैटलॉग से एक बार जारी रखें।
• अपस्ट्रीम लिंक मानते हैं कि प्रत्येक अपनाई गई सत्र कुंजी एक स्वामी एजेंट से मैप होती है (अपनाना डिफ़ॉल्ट स्टोर एजेंट का उपयोग करता है)। एक ही बाहरी थ्रेड को अनेक एजेंटों द्वारा अपनाने की निगरानी v1 में नहीं की जाती।

संबंधित

• सत्र टूल — sessions_send, session_status, sessions_list
• सब-एजेंट — स्पॉन किनारे और पूर्णता घोषणाएँ
• Heartbeat — कतारबद्ध सूचनाएँ मुख्य सत्रों को कैसे जगाती हैं
• सत्र प्रबंधन — सत्र कुंजियाँ, दायरे, जीवनचक्र