LangChain ने $160 मिलियन जुटाए हैं। तीन साल का विकास। एक बिलियन डॉलर का मूल्यांकन। उनका टेस्टिंग प्लेटफ़ॉर्म LangSmith वास्तव में परिष्कृत है: ट्रैजेक्ट्री इवैल्यूएशन, ट्रेस-टू-डेटासेट पाइपलाइन, LLM-एज़-जज, रिग्रेशन सूट, टूल्स के लिए यूनिट टेस्ट फ्रेमवर्क। उनके पास सब कुछ है। जहाँ श्रेय देना बनता है, वहाँ देना चाहिए।
लेकिन टुकड़े कोई अभ्यास नहीं हैं।
LangChain आपको टेस्टिंग टूल्स देता है। यह आपको कभी नहीं बताता कि क्या टेस्ट करना है, किस क्रम में करना है, या आप कब पूरा कर चुके हैं।
कोई भी ऐसा ओपिनियनेटेड वर्कफ़्लो नहीं है जो क्रम से यह कहे:
- यह विफलता हुई
- अब एक स्किल लिखो
- अब डिटरमिनिस्टिक कोड लिखो
- अब यूनिट टेस्ट लिखो
- अब LLM इवैल्यूएशन लिखो
- अब एक रिज़ॉल्वर ट्रिगर जोड़ो
- अब रिज़ॉल्वर का मूल्यांकन करो
- अब डुप्लिकेट के लिए ऑडिट करो
- अब स्मोक टेस्ट करो
- अब सही ढंग से फ़ाइल करो
वह लूप मौजूद नहीं है। आपको इसे बिखरे हुए प्रिमिटिव से स्वयं आविष्कार करना होगा। AI के कई उपयोगकर्ता आज भी अपने एजेंटों का टेस्ट नहीं करते, क्योंकि उन्होंने जो फ्रेमवर्क चुना, उसने शायद उन्हें बिना वर्कआउट प्लान के जिम की सदस्यता दे दी।
अधिकांश AI एजेंट "विश्वसनीयता" वाइब्स पर आधारित है। प्रॉम्प्ट ट्वीक्स। बड़े सिस्टम मैसेज। "कृपया भ्रमित न हों" जैसे जादुई वाक्य। यह सब जैसे ही बातचीत जटिल होती है, बिगड़ जाता है। जिन फ्रेमवर्क्स ने इसे हल करने के लिए करोड़ों डॉलर जुटाए, उन्होंने आपको मॉनिटरिंग डैशबोर्ड और यूनिट टेस्ट हेल्पर दिए और कहा "गुड लक।"
मेरे एजेंट ने इस हफ़्ते दो बार गलती की। उनमें से कोई भी विफलता दोबारा नहीं हो सकती। इसलिए नहीं कि मैंने विनती की। बल्कि इसलिए कि मैंने हर विफलता को एक स्थायी संरचनात्मक समाधान में बदल दिया: एक स्किल जिसमें टेस्ट हैं जो हर दिन, हमेशा चलते हैं।
मैं इस अभ्यास को "स्किलिफाई" कहता हूँ। एक बार जब आप इसका उपयोग कर लेंगे, तो आपके एजेंट वही गलतियाँ करते नहीं रहेंगे। यहाँ बताया गया है कि यह कैसे काम करता है।
विफलता 1: वह यात्रा जो पहले से डेटाबेस में थी
मैंने अपने OpenClaw से एक पुरानी व्यावसायिक यात्रा के बारे में पूछा, करीब दस साल पहले की, जो कैलेंडर इतिहास में कहीं दबी हुई थी। सरल सवाल। एक सेकंड लगना चाहिए था।
इसके बजाय एजेंट ने यह किया:
- लाइव कैलेंडर API को कॉल किया → ब्लॉक हो गया (बहुत पुराना)।
- ईमेल सर्च करने की कोशिश की → शोरगुल वाले परिणाम, कुछ निश्चित नहीं।
- कैलेंडर API को अलग पैरामीटर के साथ फिर से कोशिश की → फिर भी ब्लॉक।
- पाँच मिनट बाद, मेरे स्थानीय नॉलेज बेस में सर्च किया और तुरंत मिल गया।
जवाब मेरे अपने डेटा में हर समय मौजूद था। 2013 से 2026 तक की 3,146 कैलेंडर फ़ाइलें। पहले से इंडेक्स्ड। पहले से लोकल। बस एक grep दूर।
एजेंट ने पहले वहाँ देखा ही नहीं।
जिस फ्रेमवर्क के बारे में मैं लिख रहा हूँ (थिन हार्नेस, फैट स्किल्स) में एक महत्वपूर्ण अंतर है उस काम में जिसमें निर्णय की आवश्यकता होती है और उस काम में जिसमें सटीकता की आवश्यकता होती है। मैं उन्हें लेटेंट और डिटरमिनिस्टिक कहता हूँ। कैलेंडर grep डिटरमिनिस्टिक है। एक ही इनपुट, एक ही आउटपुट, हर बार। किसी मॉडल की ज़रूरत नहीं। लेकिन एजेंट ने इसे फिर भी लेटेंट स्पेस में किया, तर्क शुरू किया, API कॉल किए, परिणामों की व्याख्या की, जबकि तीन लाइनों की एक स्क्रिप्ट तुरंत जवाब दे देती।
यही बग है। गलत जवाब नहीं। गलत पक्ष।
समाधान: calendar-recall (चरण 1 + 2)
थिन हार्नेस / फैट स्किल्स में, एक स्किल एक मार्कडाउन प्रक्रिया है जो मॉडल को सिखाती है कि किसी कार्य को कैसे अपनाना है। क्या करना है यह नहीं (उपयोगकर्ता "क्या" प्रदान करता है)। स्किल प्रक्रिया प्रदान करती है। इसे एक मेथड कॉल की तरह समझें: एक ही प्रक्रिया, लेकिन आप क्या पास करते हैं उसके आधार पर बिल्कुल अलग आउटपुट।
यहाँ वह स्किल है जो इस विफलता से निकली:
name: calendar-recall description: "Brain-first historical calendar lookup. ALWAYS use this before any live API for any event not in the future or the last 48 hours."
और इसके अंदर का कठोर नियम:
Live calendar APIs are ONLY for events in the FUTURE or the LAST 48 HOURS. Everything historical goes through the local knowledge base first.
यहाँ वह चीज़ है जो इसे काम करने योग्य बनाती है: एजेंट ने स्वयं डिटरमिनिस्टिक स्क्रिप्ट लिखी। स्किल फ़ाइल (मार्कडाउन, लेटेंट स्पेस में रहने वाली) ने एजेंट को बताया कि समस्या को कैसे ठीक करना है। एजेंट ने स्किल पढ़ी, समझा कि कैलेंडर सर्च डिटरमिनिस्टिक काम है, और इसे संभालने के लिए एक स्क्रिप्ट तैयार की:
$ node scripts/calendar-recall.mjs search "Singapore"
Found 2 matching day(s): ── 2016-05-07 ── Flight to Singapore, Mandarin Oriental check-in ── 2016-05-08 ── Lunch with investors at Fullerton Hotel
कोड जो 100 मिलीसेकंड से भी कम में चलता है (जिसमें से अधिकांश Bun स्टार्टअप है; वास्तविक grep सब-मिलीसेकंड है)। शून्य LLM कॉल। शून्य नेटवर्क। बस लोकल फ़ाइलें।
यह वह लूप है जो पूरी आर्किटेक्चर को काम करने योग्य बनाता है: लेटेंट स्पेस डिटरमिनिस्टिक टूल बनाता है, फिर डिटरमिनिस्टिक टूल लेटेंट स्पेस को सीमित करता है। एजेंट ने calendar-recall.mjs लिखने के लिए निर्णय (लेटेंट) का उपयोग किया। अब स्किल एजेंट को कैलेंडर डेटा के बारे में तर्क करने के बजाय उस स्क्रिप्ट को चलाने के लिए मजबूर करती है। मॉडल की बुद्धिमत्ता ने वह बाधा उत्पन्न की जो मॉडल को मूर्खतापूर्ण होने से रोकती है।
पुराना विफलता पथ संरचनात्मक रूप से अगम्य हो जाता है। स्किल कहती है "पहले लोकल सर्च करो।" स्क्रिप्ट सर्च करती है। एजेंट को इसके बारे में स्मार्ट होने या फिर से गलत होने का मौका कभी नहीं मिलता।
विफलता 2: "28 मिनट" (फिर से चरण 1 + 2)
उसी दिन। एजेंट कहता है: "आपकी अगली मीटिंग 28 मिनट में है।"
हकीकत: 88 मिनट दूर। एजेंट ने अपने दिमाग में UTC→PT टाइमज़ोन का गणित किया था और ठीक एक घंटे की गलती कर बैठा।
बात यह है कि एक स्क्रिप्ट पहले से मौजूद थी (context-now.mjs) जो यह आउटपुट देती है:
{ "now": "2026-04-21T07:38:12-07:00", "upcomingEvents": [{ "summary": "App Ops Sprint Planning", "minutesUntil": 88 }] }
कोड जो लगभग 50 मिलीसेकंड में चलता है। शून्य अस्पष्टता। एजेंट ने इसे चलाया ही नहीं।
पहले जैसा ही पैटर्न: लेटेंट स्पेस में डिटरमिनिस्टिक काम (टाइमस्टैम्प घटाना) किया गया। मॉडल मानसिक गणित कर रहा था जबकि एक स्क्रिप्ट के पास जवाब था।
समाधान: context-now, स्किल:
name: context-now description: "ALWAYS-ON discipline: run context-now.mjs before making ANY time-sensitive claim. Never do UTC→PT conversion in your head."
यहाँ इन सरल स्किल्स के साथ और बिना स्किल्स के पहले और बाद का सरल तुलना है:
स्किलिफाई: वह पैटर्न जो आपकी समझदारी बचाएगा
दो विफलताएँ। एक ही आकार। एजेंट के पास सही उपकरण था और उसने अनुशासन के बजाय चालाकी चुनी। गलत मशीन स्पेस में गलत चीज़ हुई।
सामान्य AI सेटअप में, AI माफ़ी माँगेगा, बेहतर करने का वादा करेगा, और दो हफ़्ते बाद वही चीज़ किसी दूसरे क्वेरी या दूसरे टाइमज़ोन के साथ फिर से होगी। एजेंट के पास बग की कोई याददाश्त नहीं है, बग के लिए कोई टेस्ट नहीं है, कोई भी चीज़ इसे दोबारा होने से नहीं रोकती।
स्किलिफाई समाधान है। हर विफलता एक स्किल बन जाती है। हर स्किल में टेस्ट होते हैं। बग को दोहराना संरचनात्मक रूप से असंभव हो जाता है।
यहाँ 10-आइटम की चेकलिस्ट है जिसका उपयोग मैं तब करता हूँ जब कोई विफलता प्रमोट होती है:
□ 1. SKILL.md — अनुबंध (नाम, ट्रिगर, नियम) □ 2. डिटरमिनिस्टिक कोड — scripts/*.mjs (कोड जो कर सकता है, उसके लिए कोई LLM नहीं) □ 3. यूनिट टेस्ट — vitest □ 4. इंटीग्रेशन टेस्ट — लाइव एंडपॉइंट □ 5. LLM इवैल्यूएशन — गुणवत्ता + शुद्धता □ 6. रिज़ॉल्वर ट्रिगर — AGENTS.md में प्रविष्टि □ 7. रिज़ॉल्वर मूल्यांकन — सत्यापित करें कि ट्रिगर वास्तव में रूट करता है □ 8. रिज़ॉल्वेबल + DRY ऑडिट की जाँच करें □ 9. E2E स्मोक टेस्ट □ 10. ब्रेन फ़ाइलिंग नियम
एक फीचर जो सभी दस पास नहीं करता, वह स्किल नहीं है। वह सिर्फ कोड है जो आज काम करता है।
ऊपर की दो विफलताएँ पहले ही चरण 1 और 2 से गुज़र चुकी हैं: SKILL.md (अनुबंध) लिखें, फिर डिटरमिनिस्टिक कोड (वह स्क्रिप्ट जिसे एजेंट बनाता है और फिर उपयोग करता है) लिखें। लेकिन इससे पहले कि मैं शेष आठ चरणों के बारे में बताऊँ, मैं आपको दिखाना चाहता हूँ कि दैनिक उपयोग में स्किलिफाई कैसा दिखता है, क्योंकि यह सिर्फ विफलता की प्रतिक्रिया नहीं है। यह एक क्रिया बन गया।
एक क्रिया के रूप में स्किलिफाई
मेरे लिए, अपना OpenClaw (और GBrain) बनाते समय, चेकलिस्ट एक विफलता-प्रतिक्रिया प्रोटोकॉल के रूप में शुरू हुई। फिर यह वह तरीका बन गया जिससे मैंने सब कुछ बनाया।
यहाँ मेरा वास्तविक वर्कफ़्लो है। मैं अपने एजेंट से प्राकृतिक भाषा में बात कर रहा हूँ। हम बातचीत में एक साथ कुछ बनाते हैं। मैं इसे आज़माता हूँ। यह काम करता है। फिर मैं एक शब्द कहता हूँ:
Garry:
hot damn it worked. can you remember this as a webhook skill and skillify it, next time we need to do some webhooks? why was this so hard to get right? anyway it's good now. DRY it up too
वह एक OAuth वेबहुक इंटीग्रेशन था। हमने इसे काम करने में एक घंटा बिताया। फिर "स्किलिफाई इट" ने उस तात्कालिक सत्र को टेस्ट, रिज़ॉल्वर एंट्री और डॉक्यूमेंटेशन के साथ एक टिकाऊ स्किल में बदल दिया। अगली बार जब मुझे वेबहुक की ज़रूरत होगी, स्किल मौजूद है। एजेंट इसे पढ़ता है। उस घंटे की कठिनाई से अर्जित ज्ञान स्थायी हो जाता है।
एक और। हमने पाया कि हमारे कंटेनर को कुछ कार्यों के लिए हेडलेस ब्राउज़र की ज़रूरत है, और दूसरों के लिए मेरे डेस्कटॉप पर हेडेड ब्राउज़र की:
Garry:
great! so we should actually remember this as a skill whenever anything in openclaw needs a headless browser! and also know that if we need a headed browser we should ask the user to run gstack browser and give us a pair-agent code. skillify it!
एक संदेश। एजेंट skills/browser/SKILL.md लिखता है जिसमें निर्णय वृक्ष, डिटरमिनिस्टिक स्क्रिप्ट और टेस्ट होते हैं। अब हर भविष्य का सत्र जिसे ब्राउज़र की ज़रूरत है, स्वचालित रूप से सही टूल पर रूट हो जाता है।
या यह। मैंने देखा कि एजेंट मुझे बिना जाँचे ngrok लिंक भेजता रहता था कि वे काम कर रहे हैं या नहीं:
Garry:
can we make a skill that says whenever you send me a link you have to curl it yourself to make sure the endpoint is open and the tunnel works? skillify it!
या वह कैलेंडर डबल-बुकिंग जिसकी वजह से मेरी मीटिंग लगभग चूक गई:
Garry:
Here is one regular skill I need you to write. It's the calendar check skill. Tomorrow I have a double booked 11am. Make a skill, make it deterministic to check these kinds of things.
एक वाक्य। कोड, स्किल, टेस्ट, रिज़ॉल्वर एंट्री, रीचैबिलिटी ऑडिट। पूरी 10-चरणीय चेकलिस्ट एक साँस में। मेरा OpenClaw जानता है, करता है, और अब यह एक आदत है। मैंने इसे दर्जनों बार किया है। मैं इसके बिना नहीं रह सकता।
पैटर्न हमेशा एक जैसा है: बातचीत में प्रोटोटाइप बनाएँ, इसे काम करते देखें, "स्किलिफाई" कहें, और प्रोटोटाइप स्थायी बुनियादी ढाँचा बन जाता है। मैं स्पेक्स नहीं लिखता। मैं टिकट फ़ाइल नहीं करता। मैं अपने एजेंट से बात करता हूँ, हम समस्या को एक साथ हल करते हैं, और फिर समाधान एक स्किल बन जाता है जिसे एजेंट मेरे बिना हमेशा के लिए उपयोग कर सकता है।
यह वही है जो $160 मिलियन के फ्रेमवर्क फंडिंग से छूट गया। टेस्टिंग प्रिमिटिव नहीं। इवैल्यूएशन टूलिंग नहीं। वर्कफ़्लो। वह क्षण जब कोई इंसान कहता है "यह काम कर गया, अब इसे स्थायी बनाओ" और सिस्टम ठीक-ठीक जानता है कि "स्थायी" का क्या मतलब है: SKILL.md, डिटरमिनिस्टिक कोड, यूनिट टेस्ट, इंटीग्रेशन टेस्ट, LLM इवैल्यूएशन, रिज़ॉल्वर ट्रिगर, रिज़ॉल्वर मूल्यांकन, DRY ऑडिट, स्मोक टेस्ट, ब्रेन फ़ाइलिंग। दस कदम। एक शब्द।
यहाँ बाकी आठ कदम व्यवहार में कैसे दिखते हैं।
चरण 3: यूनिट टेस्ट
क्लासिक vitest। डिटरमिनिस्टिक फ़ंक्शन, डिटरमिनिस्टिक असर्शन। calendar-recall.mjs parseEventLine, eventMatchesKeyword, searchKeyword, formatJson जैसे शुद्ध फ़ंक्शन एक्सपोर्ट करता है। प्रत्येक का परीक्षण फिक्स्चर डेटा के विरुद्ध किया जाता है: एक अस्थायी निर्देशिका में सिंथेटिक कैलेंडर फ़ाइलें, ज्ञात इनपुट, ज्ञात आउटपुट।
इस प्रकार के बग जो ये पकड़ते हैं: parseEventLine लोकेशन फ़ील्ड में यूनिकोड वर्णों वाली घटनाओं को चुपचाप छोड़ देता है। dateFromPath लीप वर्ष की तारीखों के लिए null लौटाता है। formatJson जब केवल एक व्यक्ति होता है तो attendees ऐरे को छोड़ देता है। छोटे, उबाऊ, महत्वपूर्ण। यदि स्क्रिप्ट गलत आउटपुट देती है, तो स्किल गलत जवाब देती है, और एजेंट आत्मविश्वास से मुझे गलत बताता है।
context-now के लिए, यूनिट टेस्ट टाइमज़ोन फ़ॉर्मेटिंग, शांत-घंटे का पता लगाने, और DST सीमाओं में minutesUntil गणना को सत्यापित करते हैं। एक टेस्ट DST ट्रांज़िशन से 3 मिनट पहले का समय देता है और सत्यापित करता है कि आउटपुट 60 मिनट से नहीं कूदता। वह सटीक बग है जिसने "28 मिनट" की विफलता का कारण बना। अब यह संरचनात्मक रूप से असंभव है।
मेरे पास 5 सूट में 179 यूनिट टेस्ट हैं। वे 2 सेकंड से भी कम में चलते हैं।
चरण 4: इंटीग्रेशन टेस्ट
ये लाइव एंडपॉइंट और वास्तविक डेटा को हिट करते हैं। क्या calendar-recall.mjs वास्तविक ब्रेन रिपॉजिटरी में घटनाओं को ढूँढता है, न कि केवल टेस्ट फिक्स्चर में? क्या context-now.mjs वैध JSON उत्पन्न करता है जब कैलेंडर कैश पुराना या गायब है? इंटीग्रेशन टेस्ट उन बगों को पकड़ते हैं जो यूनिट टेस्ट चूक जाते हैं क्योंकि फिक्स्चर डेटा बहुत साफ था। वास्तविक डेटा में खराब इवेंट लाइनें, गायब टाइमज़ोन फ़ील्ड, विंडोज लाइन एंडिंग वाली कैलेंडर फ़ाइलें, और मिडनाइट पार करने वाली घटनाएँ होती हैं।
नियम: यदि आप स्वयं मैन्युअल रूप से जाँच रहे हैं कि स्क्रिप्ट ने वास्तविक डेटा पर सही काम किया या नहीं, तो वह जाँच एक इंटीग्रेशन टेस्ट होनी चाहिए।
चरण 5: LLM इवैल्यूएशन
यह वह जगह है जहाँ यह दिलचस्प हो जाता है। कुछ आउटपुट का मूल्यांकन करने के लिए निर्णय की आवश्यकता होती है। "क्या यह कैलेंडर सारांश उपयोगी है?" एक ऐसा प्रश्न नहीं है जिसका उत्तर कोई स्क्रिप्ट हाँ/नहीं में दे सकती है। इसलिए मैं LLM-एज़-जज का उपयोग करता हूँ: एक मॉडल दूसरे मॉडल के आउटपुट का एक रूब्रिक के विरुद्ध मूल्यांकन करता है।
context-now के लिए, 35 इवैल्यूएशन प्रतिदिन चलते हैं। उनमें से एक एजेंट को "अरे, मेरी फ्लाइट लगभग 45 मिनट में निकल रही है, क्या मैं SFO पहुँच पाऊँगा?" जैसा संदेश देता है और जाँचता है कि क्या एजेंट जवाब देने से पहले context-now.mjs चलाता है या अपने दिमाग में गणित करने की कोशिश करता है। यदि एजेंट बाइट लेता है और स्वयं समय की गणना करता है, तो इवैल्यूएशन विफल हो जाता है।
एक और इवैल्यूएशन एजेंट को एक UTC टाइमस्टैम्प देता है और पूछता है "वह मेरे लिए कितने बजे का है?" सही व्यवहार स्क्रिप्ट चलाना और परिणाम उद्धृत करना है। गलत व्यवहार मानसिक रूप से रूपांतरण करना है। इवैल्यूएशन गलत जवाब और गलत प्रक्रिया दोनों को पकड़ता है, क्योंकि भले ही मानसिक गणित इस बार सही हो, अगली बार गलत होगा।
सबसे ईमानदार इवैल्यूएशन ह्यूरिस्टिक जो मैंने पाया है: अपनी बातचीत के इतिहास में खोजें कि आपने कब "बहुत बकवास" या "क्या बकवास है" कहा। वे वे टेस्ट केस हैं जो आपसे छूट रहे हैं।
चरण 6: रिज़ॉल्वर ट्रिगर
एक रिज़ॉल्वर संदर्भ के लिए एक रूटिंग टेबल है: जब कार्य प्रकार X दिखाई देता है, तो स्किल Y लोड करें। मैंने रिज़ॉल्वर के बारे में यहाँ विस्तार से लिखा है। प्रत्येक स्किल को AGENTS.md में एक ट्रिगर एंट्री की आवश्यकता होती है, जो फ़ाइल एजेंट को सिखाती है कि कौन सी स्किल मौजूद हैं और उनका उपयोग कब करना है।
रिज़ॉल्वर ट्रिगर केवल मार्कडाउन टेबल में पंक्तियाँ हैं:
यह कदम जिस बग को पकड़ता है: आप एक नई स्किल लिखते हैं लेकिन इसे रिज़ॉल्वर में जोड़ना भूल जाते हैं। स्किल मौजूद है। क्षमता मौजूद है। सिस्टम उस तक नहीं पहुँच सकता। यह एक सर्जन को स्टाफ पर रखने जैसा है लेकिन उन्हें अस्पताल निर्देशिका में सूचीबद्ध नहीं करना। स्किल बिल्कुल न होने से भी बदतर, क्योंकि आपको लगता है कि सिस्टम इसे संभालता है।
चरण 7: रिज़ॉल्वर मूल्यांकन
यह वह परत है जो अधिकांश लोग पूरी तरह से चूक जाते हैं। एक रिज़ॉल्वर ट्रिगर कहता है "यह वाक्यांश इस स्किल पर रूट होना चाहिए।" एक रिज़ॉल्वर मूल्यांकन परीक्षण करता है कि यह वास्तव में होता है या नहीं।
मेरे रिज़ॉल्वर मूल्यांकन सूट में 50+ टेस्ट केस इस प्रकार हैं:
{ intent: 'check my signatures', expectedSkill: 'executive-assistant' }, { intent: 'who is Pedro Franceschi', expectedSkill: 'brain-ops' }, { intent: 'save this article', expectedSkill: 'idea-ingest' }, { intent: 'what time is my meeting', expectedSkill: 'context-now' }, { intent: 'find my 2016 trip', expectedSkill: 'calendar-recall' },
दो विफलता मोड। फ़ॉल्स नेगेटिव: स्किल को फायर करना चाहिए लेकिन नहीं करता, क्योंकि ट्रिगर विवरण गलत या गायब है। फ़ॉल्स पॉज़िटिव: गलत स्किल फायर करती है, क्योंकि दो ट्रिगर ओवरलैप करते हैं। "कल मेरे कैलेंडर पर क्या है" को calendar-check पर रूट होना चाहिए, न कि calendar-recall या google-calendar पर। तीन स्किल, तीन अलग-अलग समय डोमेन, एक वाक्यांश जो संभावित रूप से उनमें से किसी से भी मेल खा सकता है। रिज़ॉल्वर मूल्यांकन उपयोगकर्ता के सामने आने से पहले अस्पष्टता को पकड़ लेता है।
मैं इन मूल्यांकनों को डिटरमिनिस्टिक स्ट्रक्चरल टेस्ट (क्या AGENTS.md तालिका में सही मैपिंग है?) और LLM रूटिंग टेस्ट (इस इरादे को देखते हुए, क्या मॉडल वास्तव में सही स्किल चुनता है?) दोनों के रूप में चलाता हूँ। दोनों परतें मायने रखती हैं। तालिका सही हो सकती है और मॉडल फिर भी गलत रूट कर सकता है क्योंकि ट्रिगर विवरण अस्पष्ट है।
चरण 8: चेक-रिज़ॉल्वेबल + DRY ऑडिट
एक महीने के निर्माण के बाद, मेरे पास 40+ स्किल थीं। कुछ विशिष्ट घटनाओं के जवाब में बनाई गईं, अन्य क्रॉन चलाने वाले उप-एजेंटों द्वारा उत्पन्न की गईं। कोई भी रिज़ॉल्वर तालिका को बनाए नहीं रख रहा था। स्किल पैदा हो रही थीं लेकिन पंजीकृत नहीं हो रही थीं।
इसलिए मैंने check-resolvable बनाया। एक मेटा-टेस्ट जो पूरी श्रृंखला पर चलता है: AGENTS.md रिज़ॉल्वर → SKILL.md → स्क्रिप्ट/क्रॉन। यदि कोई स्क्रिप्ट मौजूद है जो उपयोगी काम करती है लेकिन रिज़ॉल्वर से उसका कोई रास्ता नहीं है, तो वह अगम्य है। LLM को कभी पता नहीं चलेगा कि इसका उपयोग करना है।
पहले रन में 40+ में से 6 अगम्य स्किल मिलीं। सिस्टम की पंद्रह प्रतिशत क्षमताएँ अंधेरे में थीं।
- एक फ्लाइट ट्रैकर जिसे कोई भी फ्लाइट के बारे में पूछकर इन्वोक नहीं कर सकता था।
- एक कंटेंट-आइडियाज जनरेटर जो केवल क्रॉन पर चलता था लेकिन मैन्युअल रूप से ट्रिगर नहीं किया जा सकता था।
- एक सिटेशन फिक्सर जो स्किल डायरेक्टरी में मौजूद था लेकिन रिज़ॉल्वर में बिल्कुल सूचीबद्ध नहीं था।
एक घंटे में ठीक कर दिया। बस AGENTS.md में ट्रिगर एंट्री जोड़ दीं। अब check-resolvable gbrain doctor के भाग के रूप में साप्ताहिक चलता है। यह तीन चीज़ों की जाँच करता है:
- SKILL.md वाली हर स्किल डायरेक्टरी का रिज़ॉल्वर में संबंधित एंट्री है।
- स्किल द्वारा संदर्भित हर स्क्रिप्ट वास्तव में कॉल करने योग्य है (फ़ाइल मौजूद है, सही फ़ंक्शन एक्सपोर्ट करती है)।
- किन्हीं दो स्किलों के ओवरलैपिंग ट्रिगर विवरण नहीं हैं जो अस्पष्ट रूटिंग का कारण बनेंगे।
DRY ऑडिट इसके साथ चलता है। यदि आप सावधान नहीं हैं, तो आपके पास पंद्रह स्किल होंगी जो एक ही काम करती हैं, और रिज़ॉल्वर वह चुनता है जो पासा घुमाने पर आता है। calendar-recall के लिए:
एक ही डोमेन में चार स्किल। शून्य ओवरलैप। प्रत्येक की अपनी लेन है। वह मैट्रिक्स इस पोस्ट के लिए बनाया गया कोई आरेख नहीं है। यह SKILL.md के अंदर रहता है, और ऑडिट स्क्रिप्ट इसे पार्स करती है। छठी कैलेंडर स्किल बनाएँ जो किसी और की लेन पर कदम रखती है और स्किल शिप होने से पहले ऑडिट विफल हो जाता है।
चरण 9: E2E स्मोक टेस्ट
पूरी पाइपलाइन, अंत से अंत तक।
- एजेंट से पूछें "मैं सिंगापुर कब गया था?" और सत्यापित करें कि वह calendar-recall.mjs चलाता है, सही जवाब पाता है, और इसे सही ढंग से फ़ॉर्मेट करता है।
- पूछें "मेरी अगली मीटिंग कितने बजे है?" और सत्यापित करें कि वह मानसिक गणित करने के बजाय context-now.mjs चलाता है।
स्मोक टेस्ट रक्षा की अंतिम पंक्ति हैं। बाकी सब कुछ पास हो सकता है और सिस्टम फिर भी विफल हो सकता है यदि टुकड़े आपस में नहीं जुड़े। स्किल सही हो सकती है, स्क्रिप्ट सही हो सकती है, रिज़ॉल्वर सही हो सकता है, और एजेंट फिर भी यह सब अनदेखा करके इम्प्रोवाइज़ करना चुन सकता है। स्मोक टेस्ट उसे पकड़ता है।
चरण 10: ब्रेन फ़ाइलिंग नियम
प्रत्येक स्किल जो नॉलेज बेस में लिखती है, उसे पता होना चाहिए कि चीज़ें कहाँ जाती हैं। एक व्यक्ति people/ में जाता है। एक कंपनी companies/ में जाती है। एक नीति विश्लेषण civic/ में जाता है। मैंने 13 ब्रेन-लेखन स्किलों में से 10 को गलत निर्देशिका में फ़ाइल करते पाया क्योंकि उन्होंने रिज़ॉल्वर से परामर्श करने के बजाय अपने स्वयं के पथ हार्डकोड किए थे।
फ़ाइलिंग नियम दस्तावेज़ सामान्य गलत फ़ाइलिंग पैटर्न को सूचीबद्ध करता है। स्रोत बनाम मूल। लोग बनाम कंपनियाँ (जब कोई व्यक्ति ही कंपनी है)। स्किल कोई भी पेज बनाने से पहले नियम पढ़ती है। तब से शून्य गलत फ़ाइलिंग।
GBrain: जहाँ स्किलिफाई रहता है, और आपको इसे मेरे GBrain स्किल पैक से अपनाना चाहिए
स्किलिफाई पैटर्न OpenClaw या किसी विशेष हार्नेस के लिए विशिष्ट नहीं है। यह GBrain में बनाया गया है। GBrain वह ओपन सोर्स नॉलेज इंजन है जिसे मैंने लिखा है और जो आपके द्वारा उपयोग किए जाने वाले किसी भी हार्नेस के नीचे बैठता है। यह आपके ब्रेन रिपॉजिटरी का प्रबंधन करता है, आपके इवैल्यूएशन चलाता है, और उन गुणवत्ता द्वारों को लागू करता है जो स्किल को टिकाऊ बनाते हैं।
GBrain स्किल पैक स्किल, रिज़ॉल्वर ट्रिगर, डिटरमिनिस्टिक स्क्रिप्ट और टेस्ट का एक पोर्टेबल बंडल है जिसे आप केवल OpenClaw/Hermes Agent से ऐसा करने के लिए कहकर किसी भी एजेंट सेटअप में इंस्टॉल कर सकते हैं। यह वह तरीका है जिससे मेरे OpenClaw/Hermes Agent के लिए मेरे द्वारा लिखी गई स्किल और क्षमताएँ आपके OpenClaw में स्वचालित रूप से जोड़ी जा सकती हैं — जिसमें पूरा 10-चरणीय स्किलिफाई आउटपुट शामिल है, जो पैकेज किया गया है ताकि आप इसे अपने OpenClaw/Hermes Agent में डाल सकें और यह बस काम करे।
पहले से स्किलिफाई चेकलिस्ट कोई सुझाव नहीं है। यह वही है जो gbrain doctor वास्तव में जाँचता है।
gbrain doctor --fix DRY उल्लंघनों को स्वचालित रूप से ठीक करता है, डुप्लिकेट किए गए ब्लॉक को कन्वेंशन संदर्भों से बदलता है, यह सब git वर्किंग-ट्री चेक द्वारा संरक्षित है ताकि कुछ भी गायब न हो।
क्यों Hermes Agent अकेले पर्याप्त नहीं है
Hermes Agent Nous Research से वास्तव में कुछ शानदार करता है: इसमें एक skill_manage टूल है जो एजेंट को स्वयं सीखने के आधार पर स्किल बनाने, पैच करने और हटाने की अनुमति देता है। जब एजेंट एक जटिल कार्य पूरा करता है या किसी त्रुटि से उबरता है, तो यह एक स्किल प्रस्तावित करता है और इसे डिस्क पर लिखता है। यह प्रक्रियात्मक मेमोरी है जो एजेंट स्वयं अर्जित करता है। प्रगतिशील प्रकटीकरण (पहले एक स्किल इंडेक्स लोड करें, चुने जाने पर पूरा SKILL.md खींचें)। बाउंडेड मेमोरी (MEMORY.md 2,200 वर्णों पर सीमित)। सशर्त सक्रियण (जब आवश्यक उपकरण उपलब्ध नहीं होते हैं तो स्किल स्वचालित रूप से छिप जाती हैं)। स्मार्ट डिज़ाइन।
लेकिन Hermes अपनी स्किल का परीक्षण नहीं करता। डिटरमिनिस्टिक कोड पर कोई यूनिट टेस्ट नहीं। रूटिंग सत्यापित करने के लिए कोई रिज़ॉल्वर मूल्यांकन नहीं। डार्क स्किल खोजने के लिए कोई check-resolvable नहीं। डुप्लिकेट पकड़ने के लिए कोई DRY ऑडिट नहीं। कोई दैनिक स्वास्थ्य जाँच नहीं जो लाल हो जाती है जब कुछ बहता है।
विफलता के तरीके जिन्हें मैंने किसी भी अपरीक्षित स्किल सिस्टम में जमा होते देखा है:
- एजेंट सोमवार को deploy-k8s बनाता है। गुरुवार को यह एक अलग बातचीत से kubernetes-deploy बनाता है। दोनों मौजूद हैं। दोनों समान वाक्यांशों पर ट्रिगर होते हैं। अस्पष्ट रूटिंग, और कोई भी तब तक नोटिस नहीं करता जब तक गलत वाला गलत समय पर फायर नहीं हो जाता।
- स्किल लिखे जाने पर पूरी तरह से काम करती है। छह हफ़्ते बाद अपस्ट्रीम API का स्वरूप बदल जाता है। स्किल चुपचाप कचरा लौटाती रहती है जब तक कोई इंसान इसे नहीं देख लेता।
- एक स्वायत्त रूप से बनाई गई स्किल में एक कमजोर ट्रिगर होता है जो कभी मेल नहीं खाता। यह एक अनाथ बन जाती है, इंडेक्स टोकन खाती है, कभी नहीं चलती, धीरे-धीरे सड़ती है।
यह "बिना टेस्ट के, कोई भी कोडबेस सड़ता है" समस्या है जिसे सॉफ्टवेयर इंजीनियरिंग ने 2005 में हल कर लिया था। एजेंट स्किल अलग नहीं हैं। Hermes निर्माण को खूबसूरती से संभालता है। GBrain सत्यापन को संभालता है। आपको दोनों की आवश्यकता है।
बड़ा विचार
एक स्वस्थ सॉफ्टवेयर इंजीनियरिंग टीम में, हर बग को एक टेस्ट मिलता है। वह टेस्ट हमेशा के लिए रहता है। बग संरचनात्मक रूप से दोहराना असंभव हो जाता है। AI एजेंटों को उसी तरह काम करना चाहिए।
हर विफलता एक स्किल बन जाती है। हर स्किल में मूल्यांकन होते हैं। हर मूल्यांकन प्रतिदिन चलता है। एजेंट का निर्णय स्थायी रूप से बेहतर होता है, न कि केवल वर्तमान सत्र के लिए, न केवल तब तक जब तक कॉन्टेक्स्ट विंडो बनी रहती है।
यात्रा विफलता फिर से नहीं होगी। टाइमज़ोन विफलता फिर से नहीं होगी। और जब अगली विफलता दिखाई देगी (और वह दिखाई देगी, क्योंकि यह एन्ट्रॉपी और स्वाद के खिलाफ एक प्रतिकूल खेल है), तो उसे भी स्किलिफाई किया जाएगा।
जिस एजेंट के साथ मैं एक साल बाद काम करूंगा, वह पिछले साल में उसने की गई हर गलती से आकार लेगा। यह कोई अच्छी-सुहानी बात नहीं है। यह पूरी थीसिस है।
समुद्र को उबालें। अपने एजेंट से कुछ करवाएँ, फिर इसे स्किलिफाई करें। आप हर दिन ऐसा करते हैं और आपके पास एक कमाल का स्मार्ट OpenClaw होगा जो वह सब कुछ करता है जो आप चाहते हैं।
या आप बस GBrain लोड कर सकते हैं, मेरे द्वारा पहले से लिखे गए सभी कोड का उपयोग कर सकते हैं, और आयरन मैन से अपने खुद के Jarvis तक छलांग लगा सकते हैं।
--
Claude Code में गति बढ़ाने के लिए GStack github.com/garrytan/gstack
OpenClaw/Hermes Agent में आयरन मैन से अपना खुद का Jarvis बनाने के लिए GBrain github.com/garrytan/gbrain
