---
read_when:
    - आप चाहते हैं कि जब इंसान या अन्य एजेंट किसी एजेंट की जानकारी के बिना किसी सत्र को बदलें, तो एजेंट इसे पहचान सकें
    - आप स्थिति-परिवर्तन सूचनाओं, वॉच कर्सर या session_status changesSince को डीबग कर रहे हैं
    - आप समझना चाहते हैं कि पैरेंट एजेंट चाइल्ड सेशन के साथ कैसे समन्वय बनाए रखते हैं
sidebarTitle: Session state awareness
summary: 'स्थायी सत्र स्थिति संकेत लॉग: स्थिति संस्करण, वॉचर, अप्रचलित-स्थिति सूचनाएँ और समन्वयन'
title: सत्र स्थिति की जागरूकता
x-i18n:
    generated_at: "2026-07-27T19:15:25Z"
    model: gpt-5.6
    postprocess_version: locale-links-v1
    prompt_version: 32
    provider: openai
    source_hash: bb4126a0802e1ca4418f225c792490493a78886089b81c3b4567f72090ce34f4
    source_path: concepts/session-state.md
    workflow: 16
---

जब कई सत्र एक ही समस्या पर काम करते हैं — कोई प्रबंधक चाइल्ड सत्रों को कार्य सौंप रहा हो, कोई मानव सीधे किसी वर्कर सत्र में प्रवेश कर रहा हो, या दो एजेंट [`sessions_send`](/hi/concepts/session-tool) के माध्यम से समन्वय कर रहे हों — तो प्रत्येक सत्र दूसरे सत्रों के बारे में धारणाएँ बनाता है। किसी अन्य कर्ता के हस्तक्षेप करते ही वे धारणाएँ पुरानी हो जाती हैं। सत्र स्थिति जागरूकता वह तंत्र है जो हस्तक्षेप का पता लगाता है, प्रभावित सत्र को एक बार सूचित करता है, और कार्रवाई करने से पहले अद्यतन जानकारी प्राप्त करने का सरल तरीका देता है।

तीन भाग मिलकर काम करते हैं:

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

## सिग्नल लॉग

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

| प्रकार                   | कब दर्ज होता है                                            | वॉचर को सूचित करता है |
| ---------------------- | -------------------------------------------------------- | ----------------- |
| `human_direct_message` | कोई मानव निगरानी किए जा रहे सत्र को सीधे एक टर्न भेजता है       | हाँ               |
| `upstream_missing`     | अपनाए गए सत्र का अपस्ट्रीम स्रोत गायब हो जाता है          | हाँ               |
| `goal_changed`         | सत्र की लक्ष्य स्थिति बनाई, अपडेट या साफ़ की जाती है | हाँ               |
| `child_spawned`        | कोई सब-एजेंट या ACP चाइल्ड सत्र बनाया जाता है              | नहीं (कर्सर सीड करता है) |
| `run_completed`        | कोई चाइल्ड रन सफलतापूर्वक समाप्त होता है                            | नहीं (केवल लॉग)     |
| `run_failed`           | कोई चाइल्ड रन विफल होता है, समय-सीमा पार करता है या रद्द किया जाता है            | नहीं (केवल लॉग)     |
| `compacted`            | सत्र के इतिहास का Compaction होता है                       | नहीं (केवल लॉग)     |
| `adopted`              | किसी कैटलॉग सत्र को OpenClaw में अपनाया जाता है               | नहीं (केवल लॉग)     |

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

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

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

## वॉचर

वॉचर वह सत्र है जो किसी लक्ष्य पर कर्सर (`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) लौटाता है, किसी भी कर्सर को आगे बढ़ाए बिना:

```json
{
  "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 में उस सत्र के कर्सर को अवरुद्ध कर देती है; अवर्गीकृत बाइट कभी छोड़े नहीं जाते।
- युग्मित-Node Claude जाँच प्रत्येक अंतराल में नवीनतम 50 ट्रांसक्रिप्ट आइटम वर्गीकृत करती हैं। इससे बड़े बर्स्ट v1 स्कैन विंडो के बाहर जा सकते हैं।
- युग्मित-Node Claude इतिहास रीड निश्चित थ्रेड-नहीं-मिला परिणाम उजागर नहीं करते, इसलिए दूरस्थ Claude विलोपन को v1 में `upstream_missing` के रूप में वर्गीकृत नहीं किया जाता।
- जिन कैटलॉग सत्रों को अपनाया नहीं गया है, वे v1 में जागरूकता परत से बाहर रहते हैं।
- इस सुविधा से पहले अपनाए गए सत्रों में कोई अपस्ट्रीम लिंक नहीं होता; अपस्ट्रीम निगरानी शुरू करने के लिए उन्हें कैटलॉग से एक बार जारी रखें।
- अपस्ट्रीम लिंक मानते हैं कि प्रत्येक अपनाई गई सत्र कुंजी एक स्वामी एजेंट से मैप होती है (अपनाना डिफ़ॉल्ट स्टोर एजेंट का उपयोग करता है)। एक ही बाहरी थ्रेड को एकाधिक एजेंटों द्वारा अपनाने की v1 में निगरानी नहीं होती।

## संबंधित

- [सत्र टूल](/hi/concepts/session-tool) — `sessions_send`, `session_status`, `sessions_list`
- [सब-एजेंट](/hi/tools/subagents) — स्पॉन किनारे और पूर्णता घोषणाएँ
- [Heartbeat](/hi/gateway/heartbeat) — कतारबद्ध सूचनाएँ मुख्य सत्रों को कैसे जगाती हैं
- [सत्र प्रबंधन](/hi/concepts/session) — सत्र कुंजियाँ, दायरे, जीवनचक्र