शीर्ष ओपन सोर्स फ्रंटएंड मॉडल का उपयोग कैसे करें: Kimi K3 हार्नेस गाइड

Prompt, context, loop और graph engineering आखिरकार एक ही मशीन के अलग-अलग हिस्से निकले। Harness ही वह जगह है जहाँ वे अंततः साथ रहते हैं।

AI के साथ निर्माण के हर चरण को अपना एक नया शीर्षक मिला। सबसे पहले Prompt Engineering आई, जब इस पूरी कला का मतलब सही वाक्य ढूंढना था।

फिर Context Engineering आई, जब यह स्पष्ट हो गया कि वाक्य से ज्यादा महत्वपूर्ण उसके चारों ओर लोड की गई जानकारी है। इस गर्मी में Loops थे, और कुछ हफ्तों बाद Graphs आए।

अब जो नाम फैल रहा है वह है Harness Engineering, और यह पहला ऐसा शब्द है जो बाकी सभी को समझाता है।

Harness मॉडल के चारों ओर सब कुछ है: वे टूल्स जिन्हें यह कॉल कर सकता है, फाइलें जिन्हें यह सबसे पहले पढ़ता है, डायरेक्टरीज जिनमें यह लिख सकता है, चेक जो इसके आउटपुट को पास करना होता है, शेड्यूल जो इसे जगाता है और नियम जो रन को समाप्त करता है।

इससे पहले की हर अनुशासन (discipline) उसी फ्रेम का एक घटक निकली, जिसे अलग-अलग बनाया गया और अपने खुद के नाम दिए गए।

मैंने एक व्यावहारिक कारण से ध्यान देना शुरू किया। नीचे मौजूद मॉडल लगातार बदलता रहता है, कभी-कभी एक ही अपडेट में लेडरबोर्ड पर सत्रह स्थानों तक, और harness सिस्टम का वह हिस्सा है जो आपका रहता है।

1/ सात इंजीनियरिंग्स, एक मशीन

अनुशासन

यह किस प्रश्न का उत्तर देता है

Harness में यह कहाँ रहता है

Prompt engineering

मैं ठीक क्या पूछ रहा हूँ

SKILL.md, सबसे पहले लोड होने वाला कार्य विनिर्देश (task spec)

Context engineering

हर चरण पर मॉडल क्या देखता है

Context assembler: प्रतिबंध, स्कीमा, पुनर्प्राप्त पेज

Tool engineering

यह क्या छू सकता है, और किस रूप में

टाइप्ड इनपुट और आउटपुट वाले टूल परिभाषाएँ

Loop engineering

रन क्या शुरू करता है और क्या समाप्त करता है

Runner: ट्रिगर, स्टॉप कंडीशन, बजट

Graph engineering

यह क्या याद रखता है और चीजें कैसे जुड़ी हैं

मेमोरी लेयर: नोड्स, टाइप्ड एजेस, एलियासेस

Eval engineering

परिणाम को कैसे अस्वीकार किया जाता है

Verifier, एजेंट के नियंत्रण से बाहर

Harness engineering

ऊपर बताई गई सभी चीजों को एक साथ क्या जोड़ता है

फ्रेम, अनुमतियाँ और हुक्स

टेबल को ऊपर से नीचे पढ़ें तो यह इतिहास है। इसे नीचे से ऊपर पढ़ें तो यह आर्किटेक्चर है: harness engineering का काम यह तय करना है कि अन्य छह में से हर एक कहाँ रहेगा, ताकि कोई भी चीज़ prompt में छिपी न हो जाए।

यह आखिरी बिंदु सबसे अधिक महत्वपूर्ण है।

Prompt किसी भी चीज़ को डालने के लिए सबसे आसान जगह है, इसलिए सब कुछ उसमें बहकर आ जाता है: आउटपुट फॉर्मेट, स्टॉपिंग रूल, पिछले हफ्ते के सुधार, उन चीजों की सूची जिन्हें एजेंट को कभी नहीं छूना चाहिए। यह जिस मॉडल के लिए आपने इसे लिखा था, उस पर यह बेहतरीन काम करता है, और फिर अगला मॉडल उसी पैराग्राफ को अलग तरह से पढ़ता है।

2/ Harness की संरचना

मुझे जो सबसे उपयोगी आदत मिली है वह यह है कि पूरे harness को एक कॉन्फ़िग फाइल के रूप में लिखा जाए, ताकि कोई भी महत्वपूर्ण बात निहित (implicit) न रहे:

1# harness.yaml
2model:        kimi-k3          # एक लाइन। नीचे दिया गया सब कुछ स्वैप के बाद भी जीवित रहेगा
3tools:        [browser, fs, shell, search]
4permissions:
5  write:      [./10-returns, ./20-graph, ./40-runs]
6  ask_first:  [send, publish, pay, delete]
7context:
8  always:     [SKILL.md, CONSTRAINTS.md, SCHEMA.md]
9  per_agent:  return_schema
10runner:
11  trigger:    cron "0 2 * * *"   # रात भर, जब आप सो रहे होते हैं
12  stop:       40 verified nodes OR 3 passes with nothing new
13  budget:     { agents: 300, minutes: 45, retries: 2 }
14memory:
15  graph:      ./20-graph
16  aliases:    ./aliases.csv
17verify:
18  - script:   checks/schema.py
19  - agent:    reviewer, fresh context
20hooks:
21  pre_tool:   hooks/pre_tool.sh
22  post_run:   append 40-runs/

उस फाइल में तीन लाइनें ही मुख्य काम करती हैं।

model: जानबूझकर एक लाइन है। बाकी सब कुछ इस तरह लिखा गया है कि उसे इस बात की परवाह न हो कि वह लाइन क्या कहती है। यही पूरी पोर्टेबिलिटी (portability) की कहानी है।

permissions: tools: से ज्यादा महत्वपूर्ण है, भले ही यह फाइल में नीचे स्थित हो। यह लिखना कि एजेंट क्या बदल सकता है और उसके बारे में पहले किसके बारे में पूछना होगा, वही एक ऐसे सिस्टम को अलग करता है जिसे आप रातभर चलने दें, और एक ऐसे सिस्टम से जिसे आप बैठकर देखते रहें।

verify: में दो प्रविष्टियाँ जानबूझकर हैं। स्क्रिप्ट की कोई लागत नहीं होती और यह किसी भी यांत्रिक समस्या को पकड़ लेती है। रिビューअर एक दूसरा एजेंट है जिसने पहले वाले का काम कभी नहीं देखा, क्योंकि अपना आउटपुट ग्रेड करने वाला एजेंट इसे स्वीकार करने के हर कारण को खोज लेता है।

डिस्क पर, harness एक फोल्डर है, और टेबल में दी गई हर इंजीनियरिंग को उसमें अपना पता मिलता है।

3/ Kimi K3 ही वह इंजन है जिसमें मैं इसे डालूंगा

Harness को क्या चाहिए

Kimi K3 क्या लाता है

एक रनर जो फैन-आउट (fan out) कर सकता है

Agent Swarm: एक ही समस्या पर एक साथ 300 एजेंट तक, ऑर्केस्ट्रेटर लिखे बिना

कोड इतना मजबूत कि वह अपनी जांच खुद लिख सके

Frontend Code Arena पर 1,679 के साथ #1, Fable 5 (1,631) और GPT-5.6 Sol (1,618) से आगे, 7 में से 6 डोमेन में अग्रणी

एक इंजन जो आपके नीचे सुधरता रहता है

जुलाई के एक ही अपडेट में #18 से #1 तक

पहली पंक्ति दिखने से ज्यादा महत्वपूर्ण है। लगभग हर homemade harness किसी बिंदु पर एक हाथ से बनाया गया ऑर्केस्ट्रेटर विकसित कर लेता है, और यह आमतौर पर फोल्डर में सबसे नाजुक फाइल होती है। Swarm के साथ, fan-out एक बजट लाइन बन जाता है, agents: 300, और harness को केवल उसका सामना करना होता है जो वापस आता है।

दूसरी पंक्ति महत्वपूर्ण है क्योंकि harness मुख्य रूप से वह कोड है जो मॉडल आपके लिए लिखता है: हुक स्क्रिप्ट्स, स्कीमा चेक, छोटा डैशबोर्ड जो 40-runs को पढ़ता है। एक इंजन जो फ्रंटएंड एरिना में अग्रणी है, उन्हें पहली बार में ही बहुत अधिक बार सही करता है।

तीसरी पंक्ति harness engineering के मामले में एक डेटा पॉइंट है। जब एक मॉडल रातों-रात सत्रह स्थान ऊपर चढ़ जाता है, तो harness उस चढ़ाई को उसी दिन काम में लगा देता है, क्योंकि बदलने वाली एकमात्र लाइन model है।

4/ Hooks: प्रतिवर्त (Reflexes)

Hook एक छोटी स्क्रिप्ट है जिसे harness एक निश्चित समय पर चलाता है, चाहे मॉडल कुछ भी करने का निर्णय ले। Hooks ही वह जगह है जहाँ harness एक फोल्डर लेआउट होना बंद कर देता है और एक सुरक्षा प्रणाली की तरह व्यवहार करना शुरू कर देता है।

Hook

यह कब सक्रिय होता है

यह क्या करता है

pre_tool

किसी भी टूल कॉल से पहले

अनुमति सूची के बाहर लिखने को ब्लॉक करता है

post_tool

हर रिटर्न के बाद

स्कीमा चेक चलाता है और खराब आउटपुट को तुरंत अस्वीकार करता है

pre_send

किसी भी चीज़ के मशीन से बाहर जाने से पहले

इसे क्यू में रोकता है जब तक आप इसे मंजूरी नहीं देते

on_fail

अस्वीकार किए गए परिणाम के बाद

पुनः प्रयास (retry) के साथ विफलता का कारण जोड़ता है

post_run

जब स्टॉप कंडीशन पूरी होती है

रन रिकॉर्ड को 40-runs में जोड़ता है और ग्राफ का diff दिखाता है

पहली पंक्ति का pre_tool hook पाँच लाइनों में फिट हो जाता है:

1# hooks/pre_tool.sh
2case "$TARGET" in
3  ./10-returns/*|./20-graph/*|./40-runs/*) exit 0 ;;
4  *) echo "blocked: $TARGET is outside the write list"; exit 1 ;;
5esac

अकेला on_fail hook एक लूप की अर्थव्यवस्था को बदल देता है। एक पुनः प्रयास जो पिछले प्रयास के विफल होने का कारण लेकर चलता है, वह एक सुधार है। उस कारण के बिना, लूप उसी गलती के लिए दूसरी बार भुगतान करता है।

5/ एक रात कैसी दिखती है

सभी टुकड़ों को एक साथ रखें और harness एक ऐसी नाइट शिफ्ट की तरह व्यवहार करता है जो नियमों का पालन करती है। 02:00 बजे ट्रिगर सक्रिय होता है और लॉन्च क्वेरी उन सभी नोड्स को चुनती है जिन पर काम करने की आवश्यकता है। Swarm फैन-आउट करता है, एक नोड पर एक एजेंट।

जो रिटर्न स्कीमा को मिस करते हैं, वे ग्राफ तक पहुँचने से पहले ही post_tool द्वारा अस्वीकार कर दिए जाते हैं, और प्रत्येक अस्वीकार किए गए नोड अपने विफलता के कारण के साथ एक बार पुनः प्रयास करता है। जब एक एजेंट अपने फोल्डर के बाहर लिखने की कोशिश करता है, तो pre_tool उसे रोका देता है बिना किसी को जगाए।

मर्ज किए गए नोड्स और टाइप्ड एजेस 20-graph में आते हैं। एक ड्राफ्ट किया गया ईमेल pre_send तक पहुँचता है और रुक जाता है। post_run रिकॉर्ड जोड़ता है, और लूप अपनी शर्त पर अपने आप रुक जाता है, कॉन्फ़िग में दिए गए 45 मिनट के बजट के भीतर।

07:30 बजे आप एक फाइल पढ़ते हैं और दो निर्णय लेते हैं। लूप इंजीनियरिंग और ग्राफ इंजीनियरिंग को इस तरह चलाने की यह पूरी सुबह की लागत है, और यही harness का पूरा उद्देश्य है: जो भी बिना आपके चल सकता था, वह चला, और जिन कुछ चीजों को आपकी जरूरत थी, वे एक जगह इंतजार कर रही हैं।

6/ स्वैप टेस्ट

किसी भी एजेंट सेटअप का सबसे तेज़ ऑडिट: मॉडल लाइन बदलें और इसे फिर से चलाएं। जो भी टूटता है, वह harness गलत जगह रह रहा था।

स्वैप के बाद क्या टूटता है

यह कहाँ छिपा हुआ था

यह कहाँ होना चाहिए

आउटपुट फॉर्मेट भटक जाता है

prompt में "always answer as JSON"

एक रिटर्न स्कीमा और एक स्क्रिप्ट जो बाकी सब कुछ अस्वीकार कर दे

रन अपने आप खत्म होना बंद कर देते हैं

"keep going until it's thorough"

गिनती से बनी स्टॉप कंडीशन

पिछले हफ्ते के सुधार गायब हो जाते हैं

चैट हिस्ट्री

CONSTRAINTS.md, हर रन में लोड होता है

एक ही कंपनी तीन बार दिखाई देती है

मॉडल का निर्णय

aliases.csv, मर्ज से पहले चेक किया जाता है

यह कहीं और लिखता है जहाँ नहीं लिखना चाहिए

prompt में एक विनम्र वाक्य

एक अनुमति सूची और एक pre_tool hook

एक सेटअप जो स्वैप टेस्ट पास करता है वह पोर्टेबल है, और पोर्टेबल होने से ही वह पैसे के लायक बनता है।

इसकी लागत और इसका लाभ

कंपनियाँ आंतरिक एजेंट प्लेटफॉर्म में पूरे तिमाही लगा देती हैं। एक काम करने वाला harness एक फोल्डर, एक कॉन्फ़िग फाइल और पाँच छोटी स्क्रिप्ट्स है, और यह Kimi सब्सक्रिप्शन पर चलता है। यही अंतर अवसर है।

चैनल

यह क्या देता है

पहले आपको क्या चाहिए

छोटी टीम के लिए Harness सेटअप

उनके वर्कफ्लो के चारों ओर कॉन्फ़िग, हुक्स और वेरिफायर के लिए चार अंकों की एकमुश्त फीस

आपका अपना एक harness, शेड्यूल पर चल रहा हो

रिलीज़-डे रिटेनर

हर प्रमुख मॉडल रिलीज़ पर स्वैप टेस्ट चलाने और टीम को जो भी अग्रणी हो, उस पर ले जाने के लिए मासिक शुल्क

एक क्लाइंट जिसके रन पहले से ही 40-runs में लॉग होते हैं

एक निश (niche) harness टेम्पलेट

एक उद्योग के लिए पैकेज किया गया फोल्डर और yaml: रिसर्च, रिक्रूटिंग, कंप्लायंस

दो अलग-अलग बाजारों में सिद्ध हुआ वही harness

दूसरा चैनल वह है जिसे मैं सबसे पहले बनाऊंगा। हर प्रमुख रिलीज़ लेडरबोर्ड को बदल देती है, K3 ने अकेले एक ही अपडेट में सत्रह स्थानों की छलांग लगाई, और हर टीम जिसके पास harness है, उसे किसी ऐसे व्यक्ति की जरूरत है जिसका काम रिलीज़ डे पर स्वैप टेस्ट चलाना हो।

संक्षिप्त संस्करण

Prompt, context, tool, loop, graph और eval engineering सभी एक ही मशीन के घटक निकले, और harness engineering यह तय करना है कि उनमें से हर एक कहाँ रहेगा।

मॉडल को एक लाइन के पीछे रखें, टूल्स से पहले अनुमतियाँ रखें और वेरिफायर को एजेंट के बाहर रखें। फिर अगली लेडरबोर्ड छलांग एक रीबिल्ड के बजाय एक कॉन्फ़िग बदलाव बन जाती है।

और अगर आपको यह उपयोगी लगा:

• इस लेख को बुकमार्क करें। लिंक बदलते हैं और नए रेपो हर हफ्ते सामने आते हैं, आपको इसे एक संदर्भ के रूप में चाहिए होगा
• AI आर्किटेक्चर, क्वांट ट्रेडिंग और एजेंट इकोनॉमी पर साप्ताहिक गहन विश्लेषण के लिए, मुझे फॉलो करें: @polydao
• TG चैनल से जुड़ें: Buzzoni Notes - यहाँ मैं अपने कच्चे prompts, कस्टम स्किल्स और वह alpha साझा करता हूँ जो X के लिए बहुत जल्दी है