संदर्भ ऑडिट एजेंट : जब आपका अपना शासन समस्या बन जाता है — और इसे कैसे सही करें बिना कुछ खोए

प्रकाशित: 27 April 2026

pढ़ने का समय : 14 minutes

आपने एक त्रुटिहीन एजेंट प्रशासन बनाने में हफ्तों बिताए। Eager/Lazy, सत्र समाप्ति प्रक्रिया, घूर्णी बैकअप। सिस्टम चल रहा है। फिर एक दिन, एजेंट धीमा हो जाता है। जवाब कमजोर हो जाते हैं। आप मापते हैं: 1414 लाइनों को स्वचालित रूप से लोड किया गया। और सबसे बुरी बात यह है कि दोषी कोड नहीं, न बैकलॉग है, न सत्र अभिलेख हैं। दोषी वह फ़ाइल है जो आपकी विधि को दस्तावेज़़ीकृत करती है।

दृश्य: सत्र 051, कुछ गड़बड़ है

30 अप्रैल 2026, दोपहर 4:00. मैं एक सत्र के बीच में हूँ पर`magic-stick`, मेरा लाइव लिनक्स ISO बिल्ड प्रोजेक्ट। ऑपेन्कोड एजेंट स्वचालित रूप से मेरे Eager फ़ाइलें लोड किया सामान्य रूप से —AGENT.adoc, PROMPT_REPRISE.adoc, .agents/INDEX.adoc. सब सामान्य है।

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

मैं पहले से ही सत्र 048 में इसे जी चुका था, जब मैंने पाया कि प्रशासन के फ़ाइलों का वजन 5200 संचयी लाइनों का था। तब मैंने 10 सत्रों की स्लाइडिंग विंडो वाले Hot/Warm/Cold तंत्र की अवधारणा की, उसके समान ठंडी लहरें, दो-ट्रिगर सेंसर के साथ। समस्या हल हो गई थी। सिद्धांत में।

लेकिन अब हम सत्र 051 में हैं। बैकअप रोटेशन सही से हो गई — EAGER फ़ाइलें 2087 से घटकर 500 लाइनें हो गईं। फिर भी, संदर्भ भारी बना हुआ है। मुझसे कुछ छूट रहा है।

मैं एक टर्मिनल खोलता हूँ और टाइप करता हूँ :

wc -l AGENT.adoc AGENT_MODUS_OPERANDI.adoc PROMPT_REPRISE.adoc \
  .agents/INDEX.adoc .agents/SESSIONS_HISTORY.adoc \
  .agents/archives/COMPLETED_TASKS_ARCHIVE_2026-04.adoc
  287 AGENT.adoc
  627 AGENT_MODUS_OPERANDI.adoc
   51 PROMPT_REPRISE.adoc
  218 .agents/INDEX.adoc
   18 .agents/SESSIONS_HISTORY.adoc
  213 .agents/archives/COMPLETED_TASKS_ARCHIVE_2026-04.adoc
 1414 total

1414 पंक्तियाँ। बैकअप रोटेशन ने INDEX, SESSIONS_HISTORY और COMPLETED_TASKS में सही तरीके से ट्रिम किया — वे साफ़ हैं। लेकिन कमरे में एक हाथी है जो मैं नहीं देख पाया था :627 पंक्तियाँएक ही फ़ाइल में।AGENT_MODUS_OPERANDI.adoc.

यह फ़ाइल वह है जो मैंने सेशन 1 में Eager/Lazy रणनीति को दस्तावेज़ करने के लिए लिखी थी। यह विधि का मैनुअल है। और यह अकेले ही EAGER संदर्भ का 44% बन गया है।

@startuml
skinparam backgroundColor #FEFEFE

title संदर्भ EAGER — 1414 लाइनें
rectangle "AGENT_MODUS_OPERANDI\n**627 लाइनें (44%)**" as MOD #FFCDD2
rectangle "AGENT.adoc\n287 लाइनें (20%)" as AG #BBDEFB
rectangle "INDEX.adoc\n218 लाइनें (15%)" as IDX #C8E6C9
rectangle "COMPLETED_TASKS\n213 लाइनें (15%)" as ARC #FFF9C4
rectangle "PROMPT_REPRISE\n51 लाइनें (4%)" as PRO #E1BEE7
rectangle "SESSIONS_HISTORY\n18 लाइनें (1%)" as HIS #FFE0B2

note bottom of MOD
फ़ाइल जो दस्तावेज़ीकरण करती है
विधि बन गई है
सबसे बड़ा व्यय मद
end note

@enduml

इरॉनी पूरी है। जो फ़ाइल संदर्भ बचाने के लिए डिज़ाइन की गई थी, वह मुख्य उपभोक्ता बन गई है। जैसे कि आपकी कार के उपयोग करने की पुस्तिका इंजन से भारी हो गई है।

ऑडिट: 627 पंक्तियाँ खंगालना

मैं अनुभाग-वार ऑडिट करने का निर्णय लेता हूँ। हटाने के लिए नहीं — समझने के लिए कि क्या EAGER में होना उचित है और क्या कहीं और बिना ज्ञान हानि के रह सकता है।

यहाँ सटीक संरचना है`AGENT_MODUS_OPERANDI.adoc`और मुझे जो मिला :

अनुभाग रेखाएँ सामग्री पहले से ही …​ में मौजूद

P1 — समीक्षा

64

समस्या हल, मौलिक सिद्धांत, डैशबोर्ड बनाम मैनुअल की उपमा

(No source text provided, so nothing to translate.)

P2 — फ़ाइलों की संरचना

97

पदानुक्रम, लोडिंग नीति, कब क्या लोड करना

—

P3 — नियम निरपेक्ष

34

Git प्रतिबंधित, विनाशकारी कमांड प्रतिबंधित, गुप्त जानकारी प्रतिबंधित

AGENT.adoc + INDEX.adoc

P4 — सत्र जीवन चक्र

133

टेम्प्लेट खोलना, काम के नियम, सत्र समाप्ति के 6 चरण, चेकलिस्ट

AGENT.adoc§सत्र समाप्त +INDEX.adoc

P5 — मेट्रिक्स और सीमाएँ

49

आदर्श सत्र (15-30 मिनट, 1-3 फ़ाइलें), चेतावनी के संकेत

—

P6 — सत्रों के प्रकार

72

डिटेक्शन तालिका, प्रस्ताव प्रारूप, अपवाद

</think>

P7 — सतत सुधार

39

ट्रैकिंग मेट्रिक्स, साप्ताहिक समीक्षा

(Empty)

P8 — चेकलिस्ट प्रारंभ

13

Bootstrap नया परियोजना

—

P9 — संदर्भ

30

संदर्भ फ़ाइलें, बाह्य संसाधन

AGENT.adoc(फ़ाइलें EAGER/LAZY)

परिशिष्ट A+B

42

शब्दकोश, संस्करण इतिहास

निर्णय अंतिम है :

  • पूरा डुप्लिकेट(167 लाइनें) : P3, P4, P9 — सब कुछ पहले से ही है`AGENT.adoc` ou INDEX.adoc, अक्सर शब्दशः

  • कभी अभ्यास में परामर्श नहीं किया(215 लाइनें) : P5, P6, P7, P8, अनुलग्नक — मेटा-गवर्नेंस की, जिसे किसी भी सत्र में कभी उपयोग नहीं किया गया

  • अद्वितीय ज्ञान(161 पंक्तियाँ) : P1 और P2 — LAZY/EAGER शब्दावली, उपमा, लोडिंग नीति

627 लाइनों पर,382 शोर हैं. इन 382 लाइनों हर सत्र के शुरू में लोड की जाती हैं, एजेंट द्वारा उपभोग की जाती हैं, इससे उसकी सावधानी मेरे 'नमस्ते' कहने से पहले ही कम हो जाती है।

@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center

title ऑडिट का AGENT_MODUS_OPERANDI.adoc — 627 पंक्तियाँ
left to right direction

rectangle "🟡 **दुप्लिकेट**\n167 पंक्तियाँ (27%)" as DUP #FFF9C4 {
  card "P3 — असशर्त नियम\n(34 पंक्तियाँ)" as D1
  card "P4 — जीवन चक्र\n(133 पंक्तियाँ)" as D2
  card "P9 — संदर्भ\n(30 पंक्तियाँ)" as D3
}

rectangle "🔴 **कभी नहीं जाँचा गया**\n215 पंक्तियाँ (34%)" as JAM #FFCDD2 {
  card "P5 — मेट्रिक्स\n(49 पंक्तियाँ)" as J1
  card "P6 — पता लगाना\n(72 पंक्तियाँ)" as J2
  card "P7 — सुधार\n(39 पंक्तियाँ)" as J3
  card "P8 — बूटस्ट्रैप\n(13 पंक्तियाँ)" as J4
  card "अनुलग्नक — शब्दकोश\n(42 पंक्तियाँ)" as J5
}

rectangle "🟢 **अद्वितीय ज्ञान**\n161 पंक्तियाँ (26%)" as UNI #C8E6C9 {
  card "P1 — समग्र अवलोकन\n(64 पंक्तियाँ)" as U1
  card "P2 — फ़ाइल संरचना\n(97 पंक्तियाँ)" as U2
}

note bottom of UNI
वह वही है जिसे EAGER में रखना चाहिए।
बाकी → cold storage।
end note

@enduml

यह डायग्राम सबकी कुंजी है। डुप्लीकेट (पीला) शोर का शुद्ध रूप है — एजेंट इन्हें दो बार पढ़ता है, दो अलग‑अलग फ़ाइलों में। कभी नहीं देखी गई (लाल) मृत दस्तावेज़ है — सावधानी से लिखी गई, कभी उपयोग नहीं की गई। केवल हरा वह ज्ञान रखता है जिसे एजेंट कहीं और नहीं खोज पाता।

इंजीनियरिंग खोने का भय

इस चरण में, मेरे सामने स्पष्ट सबूत है: मुझे कम करना होगा`AGENT_MODUS_OPERANDI.adoc`. लेकिन मैं हिचकिचा रहा हूँ।

मैंने इस फ़ाइल को हाथ से लिखा। हर सेक्शन वास्तविक सत्र में सीखे गए पाठ का परिणाम है। भाग P3 एक से पैदा हुआ`rm -rf`अचानक पर`bakery-plugin`जिसने मुझे वास्तविक Firebase टोकन खर्च कर दिए। भाग P4 पंद्रह सत्रों का परिणाम है, जहाँ मैं आर्काइव करना भूल जाता था और ट्रैक खो देता था। 6 चरणों वाली प्रक्रिया किसी किताब से नहीं आई — यह दर्द से आई है।

इन सेक्शन को हटाने से मेरा अपना इंजीनियरिंग इतिहास फेंक दिया जाएगा। वे पाठ जिन्होंने इसे उत्पन्न किया, वे सत्र जिनके दौरान मैंने इसे खोजा, वे गलतियाँ जिन्हें मैं फिर कभी नहीं दोहराना चाहता। यह टेक्स्ट नहीं — यह क्रिस्टलीकृत अनुभव है।

यहाँ मैं वह सिद्धांत तैयार करता हूँ जो समाधान को निर्देशित करेगा:

_ कभी न हटाएँ। हमेशा स्थानांतरित करें।ज्ञान को परियोजना से गायब होने की आवश्यकता नहीं है। इसे केवल तब तक स्वचालित रूप से लोड नहीं किया जाना चाहिए जब यह आवश्यक न हो। _

समाधान: एन्साइक्लोपेडिक विभाजन

मैं जो मॉडल प्रस्तुत करता हूँ, वह सरल है और विकिपीडिया के विकास के तरीके से प्रेरित है: जब कोई लेख बहुत लंबा हो जाता है, तो हम उसे नहीं काटते — हम एक विस्तृत लेख बनाते हैं और मुख्य लेख में एक सारांश रखते हैं।

के लिए`AGENT_MODUS_OPERANDI.adoc`, यह देता है :

  1. निकालनाएक नई फ़ाइल में 161 अद्वितीय ज्ञान की पंक्तियाँ (P1 + P2)LAZY_EAGER_ESSENTIALS.adoc— संक्षिप्त ~50 पंक्तियों तक, कड़ाई से EAGER

  2. नाम बदलें AGENT_MODUS_OPERANDI.adoc en .agents/encyclopedies/LAZY_EAGER_ENCYCLOPEDIE.adoc— मूल फ़ाइल जिसमें 627 पंक्तियाँ हैं, सुरक्षित intact, कोल्ड स्टोरेज में

  3. कभी चार्ज न करेंएन्साइक्लोपीडिया फ़ाइल स्वचालित रूप से — यह मानव के लिए है, भविष्य की आसवन के लिए, और छह महीने बाद बेहतर मॉडल के साथ बुलाए जाने वाले एजेंट के लिए।

@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center

title Split संसारिक — AGENT_MODUS_OPERANDI
left to right direction

rectangle "**AGENT_MODUS_OPERANDI.adoc**\n627 लाइनें\n(विभाजन से पहले)" as BEFORE #FFCDD2 {
}

rectangle " " as ARROW1
rectangle " " as ARROW2

rectangle "**LAZY_EAGER_ESSENTIALS.adoc**\n**~50 लाइनें — EAGER**" as ESS #C8E6C9 {
  card "P1 संक्षिप्त\n(15 लाइनें)" as E1
  card "P2 संक्षिप्त\n(35 लाइनें)" as E2
}

rectangle "**.**agents/encyclopedies/**\n**LAZY_EAGER_ENCYCLOPEDIE.adoc**\n627 लाइनें — COLD" as ENC #BBDEFB {
  card "P1 के लिए Annexes\n(intपूर्ण, अक्षत)" as C1
}

BEFORE -[#4CAF50]-> ESS : "निष्कर्षण की\nआलोचनात्मक ज्ञान"
BEFORE -[#2196F3]-> ENC : "संरक्षण intपूर्ण\nकी इंजीनियरी"

note bottom of ESS
स्वचालित रूप से लोड
सत्र के शुरू में
→ एजेंट शब्दावली समझता है
end note

note bottom of ENC
कभी स्वचालित रूप से लोड नहीं किया गया
मानव द्वारा पढ़ा जा सकता है
भविष्य की आसवन के लिए कच्चा माल
end note

@enduml

नाम`encyclopedies/`यह अनाड़ी नहीं है। एक एन्साइक्लोपीडिया, यह एक अभिलेख फ़ाइल नहीं है — यह संगठित ज्ञान का संग्रह है, परामर्श योग्य लेकिन पोर्टेबल नहीं। मेट्रो में एन्साइक्लोपीडिया यूनिवर्सलिस नहीं पढ़ी जाती। इसे लाइब्रेरी में रखा जाता है, और जब किसी को कोई विशिष्ट प्रश्न हो तो वह उसे पढ़ने जाता है।

यह इस फ़ाइल की ठीक भूमिका है: एक जमा हुआ संदर्भ लाइब्रेरी, संरचित, विस्तृत — जिसे एजेंट स्वचालित रूप से नहीं छूता।

फ़ाइल ESSENTIALS की सामग्री

यहाँ यह दिखाया गया है कि नया फ़ाइल वास्तव में कैसा दिखता है`LAZY_EAGER_ESSENTIALS.adoc`, निकाला और संकुचित से P1 और P2 :

= Stratégie LAZY/EAGER — Principes Essentiels

[abstract]
Ce fichier définit la stratégie de gestion du contexte agent.
Chargé automatiquement (EAGER) en début de session.

== Principes

|===
| EAGER | LAZY
| Tableau de bord | Manuel du propriétaire
| Chargé automatiquement | Chargé sur demande
| <= 100 lignes, <= 10k tokens | Illimité, détaillé
| Règles absolues, mission courante | Archives, historique, références
|===

== Politique de Chargement

|===
| Fichier | Type | Quand charger
| PROMPT_REPRISE.adoc | EAGER | Début session (auto)
| *_ESSENTIALS.adoc | EAGER | Début session si EPIC active
| .agents/INDEX.adoc | EAGER | Début session (auto)
| *_REFERENCE.adoc | LAZY | Sur besoin (détails architecture)
| .agents/sessions/N-*.adoc | LAZY | Sur demande (détails session)
| .agents/encyclopedies/*.adoc | COLD | Jamais auto (humain seulement)
|===

== Comment l'Agent Sait Quoi Charger

Début session → PROMPT_REPRISE + INDEX + ESSENTIALS actifs.
Besoin de détails → charger les *_REFERENCE et sessions/ en LAZY.
Connaissance froide → encyclopedies/, jamais automatique.

पचास पंक्तियाँ। यह सब है जिसकी एजेंट को मैकेनिज़्म समझने की आवश्यकता है। बाकी सब — सबक का इतिहास, विस्तृत उपमाएँ, चरण-दर-चरण प्रक्रियाएँ, परिशिष्ट — एन्क्लोपीडिया में रहता है।

और सबसे महत्वपूर्ण :कुछ भी हटाया नहीं गया. 627 इंजीनियरिंग लाइनें अभी भी वहां हैं, में`.agents/encyclopedies/LAZY_EAGER_ENCYCLOPEDIE.adoc`. वे केवल लाइब्रेरी में रखी जाती हैं, काउंटरटॉप पर नहीं।

परिणाम: -50% संदर्भ EAGER

सप्लिट से पहले:

 287 AGENT.adoc
 627 AGENT_MODUS_OPERANDI.adoc
  51 PROMPT_REPRISE.adoc
 218 .agents/INDEX.adoc
  18 .agents/SESSIONS_HISTORY.adoc
 213 .agents/archives/COMPLETED_TASKS_ARCHIVE_2026-04.adoc
1414 total

सप्लिट के बाद :

 287 AGENT.adoc
  50 LAZY_EAGER_ESSENTIALS.adoc       ← remplace 627 lignes
  51 PROMPT_REPRISE.adoc
 218 .agents/INDEX.adoc
  18 .agents/SESSIONS_HISTORY.adoc
 213 .agents/archives/COMPLETED_TASKS_ARCHIVE_2026-04.adoc
 837 total                              ← -41%
@startuml
skinparam backgroundColor #FEFEFE

title संदर्भ EAGER बाद एन्साइक्लोपेडिक विभाजन — 837 पंक्तियाँ (-41%)
rectangle "AGENT.adoc\n287 पंक्तियाँ (34%)" as AG #BBDEFB
rectangle "INDEX.adoc\n218 पंक्तियाँ (26%)" as IDX #C8E6C9
rectangle "COMPLETED_TASKS\n213 पंक्तियाँ (25%)" as ARC #FFF9C4
rectangle "PROMPT_REPRISE\n51 पंक्तियाँ (6%)" as PRO #E1BEE7
rectangle "ESSENTIALS\n50 पंक्तियाँ (6%)" as ESS #A5D6A7
rectangle "SESSIONS_HISTORY\n18 पंक्तियाँ (2%)" as HIS #FFE0B2

note bottom of ESS
से 627 → 50 लाइनें
577 इंजीनियरिंग लाइनें
cold storage में संरक्षित
कोई नुकसान नहीं। सब कुछ फिर से स्थानांतरित
end note

@enduml

सबसे बड़ा उपभोक्ता (AGENT_MODUS_OPERANDI, 627 पंक्तियों) को 50 पंक्तियों की फ़ाइल से बदल दिया गया है। लाभ तुरंत है: 577 पंक्तियों का संदर्भ मुक्त हुआ। एजेंट साँस ले रहा है।

और में`.agents/encyclopedies/`, मूल फ़ाइल 627 पंक्तियों की प्रतीक्षा कर रही है। अक्षुण्ण। इसके सभी खंड — डुप्लिकेट वाले भी शामिल हैं, जिनका कभी उपयोग नहीं किया गया भी शामिल हैं। क्योंकि एक दिन, एक बेहतर मॉडल या एक मानव डेटा वैज्ञानिक इन कोणों, इन मानी गई अनावश्यकताओं, इन सीखे गए पाठों को पार करना चाहेगा। और उस दिन, कच्चा माल मौजूद होगा।

फ़ोल्डर का नाम क्यों है `encyclopedies/

नाम का चयन सौंदर्यात्मक नहीं है। यह तंत्र की दर्शन को कोड करता है।

एक सं�्रह (archives/) मेंchronological order मेंorganised historical data है — जैसे मासिक COMPLETED_TASKS. एक backup (backup/) एक टाइमस्टैम्प्ड स्नैपशॉट है — एक पिछली स्थिति का बैकअप।

विश्वकोश, यह कुछ और है। यह विषयवार ज्ञान का संग्रह है, विषय द्वारा संरचित, व्यापक लेकिन रैखिक नहीं। हम किसी विश्वकोश को शुरू से अंत तक नहीं पढ़ते। हम इसके भीतर डुबक लगाते हैं एक विशिष्ट प्रश्न का उत्तर देने के लिए।

यह इस फ़ाइल का सटीक अनुबंध है :

फ़ाइल

भूमिका

प्रवेश

ग्रेन्युलैरिटी

archives/

इतिहासिक डेटा (प्रति माह पूर्ण किए गए कार्य)

LAZY, संरचित

क्रमानुसार

backup/

ठंडे स्नैपशॉट (10 सत्रों की लहरें)

COLD, पूरी प्रतिलिपि

कालानुक्रमिक

encyclopedies/

विस्तृत विषय ज्ञान (पद्धति, पैटर्न)

COLD, कभी नहीं स्वचालित

विषय

यह अंतर भरे हुए टोकरे से बचाता है। प्रत्येक फ़ाइल जानती है कि उसे कहाँ रहना चाहिए के अनुसार जो यह समाहित करता है, नहीं के अनुसार कि यह कब बनाया गया।

श्रृंखला का तार्किक अगला भाग

यदि आपने पहले दो लेख पढ़े हैं, तो यहाँ बताया गया है कि तीन टुकड़े कैसे फिट होते हैं:

@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam wrapWidth 220

title एजेंट गवर्नेंस त्रयी
left to right direction

package "📖 **अनुच्छेद 0108**\nउत्साही रणनीति/Lazy" as A1 #E8F5E9 {
  card "स्मृति agent\nentre सत्र" as M1
  card "फ़ाइलें EAGER\n(स्वचालित रूप से लोड किए गए)" as M2
  card "फ़ाइलें LAZY\n(अनुरोध पर)" as M3
  card "प्रक्रिया 6 चरण" as M4
}

package "🧊 **अनुच्छेद 0110**\nगर्मी तंत्र/Warm/Cold" as A2 #FFF9C4 {
  card "वृद्धावस्था\nसंदर्भ का" as V1
  card "फिसलती खिड़की\n10 सत्रों" as V2
  card "ठंडी लेहर\nसमान" as V3
  card "सेंसर\nदो ट्रिगर" as V4
}

package "🔍 **अनुच्छेद 0111**\nऑडिट + समाधान विश्वकोशीय" as A3 #BBDEFB {
  card "फ़ाइलों का ऑडिट\nEAGER" as E1
  card "पहचान\nअपव्यय" as E2
  card "Split\nESSENTIALS/encyclopसंस्करण" as E3
  card "संरक्षण\nकी इंजीनियरिंग" as E4
}

A1 --> A2 : "मेमोरी बढ़ती है\n→ एक एजिंग तंत्र\nकी आवश्यकता होती है"
A2 --> A3 : "वृद्धावस्था पर्याप्त नहीं है\n→ इस्कॉडिट करना चाहिए जो\nयोग्य है EAGER में"

note bottom of A3
तीन परतें 6 सक्रिय प्रोजेक्ट्स पर स्थित हैं
end note

@enduml

  • 0108जवाब देता है : « एजेंट के बीच दो सत्रों में याददाश्त कैसे दें ?

  • 0110 répond à : « Comment empêcher cette mémoire d’étouffer l’agent ? »

  • 0111जवाब देता है : « क्या समस्या आर्काइव्स के आकार में नहीं, बल्कि वह है जो हमने चुन करके EAGER में रखने का निर्णय लिया है ?

पहले लेख ने संरचना का निर्माण किया। दूसरे लेख में उम्र बढ़ने का तंत्र जोड़ा गया। तीसरा लेख सामग्री का ऑडिट करता है — और पता चलता है कि पद्धति ही समस्या बन गई है।

मैं अलग ढंग से क्या करता

दूसरे नजरिए से देखते हुए, मैं प्रारम्भिक डिज़ाइन त्रुटि देखता हूँ।`AGENT_MODUS_OPERANDI.adoc`इसे एक दस्तावेज़ के रूप में बनाया गया था — एक घोषणापत्र। यह विचार को सुस्पष्ट करने का सही दृष्टिकोण था। लेकिन एक बार विचार रूपांतरित हो जाने पर, दस्तावेज़ को तुरंत विभाजित कर देना चाहिए था: आवश्यक भाग EAGER में, व्यापक भाग cold में।

मैंने इसलिए नहीं किया क्योंकि मैं दस्तावेज़ पर गर्व महसूस कर रहा था। 627 शुद्ध इंजीनियरिंग की पंक्तियाँ, हाथ से लिखी गईं, प्रत्येक अनुभाग एक सत्र के पाठ का परिणाम था। यह मेरी कृति थी। और किसी भी लेखक की तरह, मुझे इसे काटने में कठिनाई हुई।

पाठ :क्यूंकि एक दस्तावेज़ अच्छा है इसलिए यह आवश्यक नहीं है कि उसे स्वचालित रूप से लोड किया जाए।सामग्री की गुणवत्ता का एजेंट के तत्काल संदर्भ के साथ कोई संबंध नहीं है।

आज, नियम सरल है: EAGER संदर्भ में 100 पंक्तियों से अधिक का प्रत्येक दस्तावेज़ एक संदिग्ध है। इसे एक जाँच की आवश्यकता है। कोई दोषसिद्धि नहीं — जाँच। और प्रश्न कभी नहीं होता कि « क्या इसे हटाया जाना चाहिए? » बल्कि « क्या इसे हर सत्र में लोड किया जाना चाहिए?

अपने संदर्भ को ऑडिट करने के लिए मार्गदर्शक

यदि आपने पहले दो लेखों का पालन किया और अपनी स्वयं की इगर/लैज़ी गवर्नेंस स्थापित की है, तो यहाँ पाँच-चरणों का लेखा परीक्षण प्रक्रिया है:

  1. मापना:`wc -l`आपके सभी EAGER फ़ाइलों पर। कुल 1000 लाइनों से कम होना चाहिए।

  2. सबसे बड़े की पहचान करें: जिस फ़ाइल का वजन कुल का 20% से अधिक है, वह प्रथम संदिग्ध है।

  3. सेक्शन द्वारा सेक्शन का ऑडिट करें: प्रत्येक अनुभाग के लिए, खुद से पूछें « क्या यह जानकारी पहले से कहीं और मौजूद है? क्या एजेंट ने इसे पहले किसी अन्य फ़ाइल में पढ़ा था? क्या इसे पिछले 5 सत्रों में उपयोग किया गया था?

  4. वर्गीकर्ता: डुप्लीकेट, कभी उपयोग नहीं, अद्वितीय ज्ञान।

  5. विभाजित करें या पुनः स्थानांतरित करें: जो अद्वितीय और महत्वपूर्ण है → ESSENTIALS संकुचित. सब कुछ बाकी →encyclopedies/.

@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center

title एजेंट संदर्भ ऑडिट प्रक्रिया — 5 चरण
start

:मापें\n`wc -l *.adoc .agents/*.adoc`;

if (Total > 1000 lignes ?) then (oui)
  :⚠️ संदर्भ बहुत भारी है;
else (non)
  :✅ संदर्भ OK;
  stop
endif

:2. **संदिग्ध की पहचान करें**\nफ़ाइल कुल का 20% से अधिक है;

:3. **सेक्शन वार ऑडिट**\nप्रत्येक सेक्शन के लिए:\n• पहले कहीं और ? → डुप्लिकेट\n• कभी परोसा नहीं गया ? → मृत\n• अद्वितीय जानकारी ? → आलोचना;

:4. **Classifier**\n🟡 Doublons → हटाएँ'EAGER\n🔴 कभी उपयोग नहीं → cold storage\n🟢 अद्वितीय ज्ञान → रखें;

:5. **Splitter**\n🟢 → ESSENTIALS (~50 लाइनों, EAGER)\n🟡🔴 → एन्साइक्लोपीडिया/ (कोल्ड स्टोरेज);

:अनुकूलित संदर्भ\nइंजीनियरिंग के नुकसान के बिना;

stop

@enduml

यह प्रक्रिया 15 मिनट लेती है। 50 सत्रों के एक प्रोजेक्ट पर, यह प्रत्येक भविष्य के सत्र के लिए सैकड़ों टोकन बचाती है। आरओआई तुरंत है।

एक जीवंत शासन

इस तीन लेखों की श्रृंखला ने मुझे जो सिखाया, वह यह है कि एजेंट गवर्नेंस एक तैयार उत्पाद नहीं है। यह एकजीवित जीव. वह परियोजना के साथ बढ़ती है। वह विकास संबंधी बीमारियों से ग्रस्त होती है। इसके लिए नियमित चेक-अप की आवश्यकता होती है।

सत्र 048 ने खुलासा किया कि अभिलेख फूल रहे हैं। सत्र 051 ने खुलासा किया कि पद्धति स्वयं फूल रही है। सत्र 060 शायद कुछ और खुलासा करेगा। यह सामान्य है। यह स्वस्थ है। एक शासन जो कभी भी स्वयं को नहीं चुनौती देता है, एक मृत शासन है।

स्थापित किए गए तीन तंत्र — इगर/लेसी, हॉट/वार्म/कोल्ड, स्प्लिट एन्साइक्लोपेडिक — संदर्भ संतृप्ति के खिलाफ एक गहरी सुरक्षा प्रणाली बनाते हैं। कोई भी अकेले पर्याप्त नहीं है। साथ में, वे एक-दूसरे को पूरक करते हैं:

  • Eager/Lazyसूचना को उपलब्धता के अनुसार संरचित करें

  • गरम/हल्का गरम/ठंडासूचना संरचित करें ताजगी के अनुसार

  • संदर्भपुस्तकात्मक ऑडिटstructure जानकारी घनत्व के अनुसार

@startuml
skinparam backgroundColor #FEFEFE
skinparam nodeBackgroundColor #E3F2FD

title गहराई में रक्षा संदर्भ संतृतीकरण के विरुद्ध
node "**एजेंट संदर्भ**\n~800 पंक्तियाँ\nस्वस्थ" as CTX #C8E6C9

node "परत 1\n**EAGER / LAZY**" as C1 #BBDEFB
node "परत 2\n**HOT / WARM / COLD**" as C2 #BBDEFB
node "परत 3\n**ESSENTIALS / ENCYCLOPÉDIE**" as C3 #BBDEFB

CTX --> C1 : "संरचना द्वारा\n**उपलब्धता**"
CTX --> C2 : "संरचना द्वारा\n**ताज़गी**"
CTX --> C3 : "संरचना द्वारा\n**घनत्व**"

note bottom of C3
तीन परतें आवश्यक हैं।
कोई भी अकेले पर्याप्त नहीं है।
end note

@enduml

इन तीन परतों के साथ, एजेंट संदर्भ पर`magic-stick`2087 लाइनों (किसी भी अनुकूलन के बिना) से घटकर लगभग 800 लाइनों पर आ गया — 2.6 से विभाजित। कोई दस्तावेज़ की एक भी पंक्ति नहीं खोई, कोई सत्र अभिलेख नहीं खोई, कोई सीखा गया सबक नहीं खोई।

सब यहाँ है। बस बेहतर ढंग से रखा हुआ।

लिंक

ज्ञान को विलुप्त होने की आवश्यकता नहीं है। उसे बस आवश्यक न होने पर लोड नहीं करना चाहिए।

संबंधित लेख

HyperFrames-Gradle : AsciiDoc को MP4 वीडियो में बदलें
31 May 2026
मेरी LLM उपभोग का ऑडिट: SQLite, OpenCode, Ollama Cloud, और क्यों मेरा प्रो सब्सक्रिप्शन वैश्विक बाजार को बर्बाद कर रहा है
18 May 2026
स्वतंत्र प्लग‑इन + उपभोक्ता मूल आर्किटेक्चर: मेरे Gradle बिल्ड्स क्यों दोहराते हैं
14 May 2026
सिफ़ारिश इंजन के रूप में Knowledge Graph: मैंने क्रमानुक्रमिक « सम्बन्धित लेख » को कैसे समाप्त कर दिया
12 May 2026