Harness Engineering: AI एजेंट्स को मजबूती से बनाने के लिए संपूर्ण गाइड

ज़्यादातर लोग AI एजेंट्स को गलत लेयर पर बेहतर बनाने की कोशिश कर रहे हैं।

जब कोई एजेंट फेल होता है, तो वे प्रॉम्प्ट को फिर से लिखते हैं।

जब वह फिर से फेल होता है, तो वे और निर्देश जोड़ देते हैं।

शुरू करने से पहले:

ताज़ा AI अल्फा, एजेंट वर्कफ़्लो और स्टेप-बाय-स्टेप गाइड के लिए मेरे Substack को फ़ॉलो करें, इससे पहले कि वे X पर आएं: [https://substack.com/@lunarresearcher

फिर वे मॉडल बदलते हैं, और टूल जोड़ते हैं, कॉन्टेक्स्ट विंडो बढ़ाते हैं, और उम्मीद करते हैं कि अगला रन अलग तरीके से व्यवहार करेगा।

लेकिन कई एजेंट फेलियर रीज़निंग फेलियर नहीं होते हैं।

वे एनवायरनमेंट फेलियर होते हैं।

एजेंट को नहीं पता था कि कौन सी फ़ाइलें मायने रखती हैं।

उसने सही टूल का इस्तेमाल गलत जगह किया।

उसने पिछले सत्र में लिए गए फ़ैसलों को खो दिया।

उसने बिना चेक चलाए सफलता का दावा किया।

उसने आंशिक विफलता के बाद एक कार्रवाई दोहराई।

उसके पास कुछ ऐसा करने की अनुमति थी जिसके लिए मंज़ूरी लेना ज़रूरी था।

ज़रूरी नहीं कि मॉडल ही समस्या थी। मॉडल के आस-पास का सिस्टम अधूरा था।

वह सिस्टम हार्नेस है।

और इसे डिज़ाइन करना अपने आप में एक इंजीनियरिंग डिसिप्लिन बनता जा रहा है।

हार्नेस इंजीनियरिंग, उस एनवायरनमेंट को बनाने का अभ्यास है जो मॉडल इंटेलिजेंस को विश्वसनीय काम में बदल देता है।

एक प्रॉम्प्ट एक प्रयास को बदलता है।

एक हार्नेस हर प्रयास को बदलता है।

यह गाइड बताती है कि एक कैसे बनाया जाए।

1. मॉडल एजेंट नहीं है

एक मॉडल तर्क कर सकता है, उत्पन्न कर सकता है, तुलना कर सकता है और चुन सकता है।

लेकिन एक एजेंट को एक वास्तविक एनवायरनमेंट के साथ भी इंटरैक्ट करना होता है।

उसे यह करना होता है:

• कार्य को समझना
• प्रासंगिक संदर्भ ढूंढना
• टूल का चयन और उपयोग करना
• स्थिति (state) को संरक्षित करना
• अनुमतियों का सम्मान करना
• परिणाम का निरीक्षण करना
• विफलता से उबरना
• यह साबित करना कि काम पूरा हो गया है

मॉडल उस सिस्टम के अंदर रीज़निंग इंजन है।

हार्नेस वह सब कुछ है जो रीज़निंग को संचालित (operational) बनाता है।

1user request
2     |
3     v
4+-----------------------------+
5|           HARNESS           |
6| contract | context | policy |
7| tools    | state   | checks |
8| traces   | recovery          |
9+-----------------------------+
10     |
11     v
12    model
13     |
14     v
15real environment

एक कमज़ोर हार्नेस के अंदर एक शक्तिशाली मॉडल फिर भी एक कमज़ोर एजेंट ही होता है।

यह प्रभावशाली व्यक्तिगत प्रतिक्रियाएँ उत्पन्न कर सकता है, लेकिन लंबे कार्यों, बदलते एनवायरनमेंट और आंशिक विफलताओं के दौरान यह असंगत व्यवहार करेगा।

हार्नेस इंजीनियरिंग का लक्ष्य मॉडल से अनिश्चितता को हटाना नहीं है।

यह उस अनिश्चितता को एक ऐसे सिस्टम के अंदर समाहित करना है जो निरीक्षण, सत्यापन और पुनर्प्राप्ति कर सके।

2. एक टास्क कॉन्ट्रैक्ट से शुरुआत करें

ज़्यादातर एजेंट कार्य एक अस्पष्ट इरादे के रूप में शुरू होते हैं:

ऑनबोर्डिंग फ़्लो को बेहतर बनाएं।

यह वाक्य बातचीत के लिए काफी हो सकता है।

यह स्वायत्त निष्पादन के लिए पर्याप्त नहीं है।

एजेंट के कार्य करने से पहले, हार्नेस को अनुरोध को एक टास्क कॉन्ट्रैक्ट में बदल देना चाहिए।

एक उपयोगी कॉन्ट्रैक्ट पाँच सवालों के जवाब देता है:

1. क्या परिणाम मौजूद होना चाहिए?
2. दायरे में क्या है?
3. क्या नहीं बदलना चाहिए?
4. कौन सा सबूत पूर्णता साबित करता है?
5. किन कार्यों के लिए मानवीय अनुमोदन आवश्यक है?

1objective: reduce onboarding drop-off
2
3scope:
4  - signup flow
5  - onboarding analytics
6
7constraints:
8  - do not change authentication
9  - preserve existing mobile behavior
10
11acceptance:
12  - tests pass
13  - analytics event is emitted
14  - screenshots cover desktop and mobile
15
16approval_required:
17  - production deployment
18  - database migration

यह एजेंट के सवाल को बदल देता है:

मुझे आगे क्या करना चाहिए?

से:

कौन सी कार्रवाई एनवायरनमेंट को अनुबंधित परिणाम की ओर ले जाती है?

कॉन्ट्रैक्ट के बिना, एजेंट प्रशंसनीय गतिविधि के लिए अनुकूलन करता है।

कॉन्ट्रैक्ट के साथ, यह सत्यापित पूर्णता के लिए अनुकूलन कर सकता है।

3. एजेंट को एक मैनुअल नहीं, एक नक्शा दें

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

यह कॉन्टेक्स्ट फ्लडिंग है।

हार्नेस को पहले एक छोटा नक्शा प्रदान करना चाहिए, फिर एजेंट को प्रासंगिक होने पर विवरण प्राप्त करने देना चाहिए।

1PROJECT MAP
2
3product rules     -> docs/product/
4architecture      -> docs/architecture.md
5frontend          -> apps/web/
6backend           -> services/api/
7tests             -> tests/
8commands          -> docs/commands.md
9release rules     -> docs/release.md

यह प्रगतिशील प्रकटीकरण (progressive disclosure) है:

1task
2  -> project map
3      -> relevant subsystem
4          -> exact files
5              -> local instructions

कॉन्टेक्स्ट का विस्तार इसलिए होना चाहिए क्योंकि कार्य को इसकी आवश्यकता है, न कि इसलिए कि जानकारी मौजूद है।

एक अच्छा कॉन्टेक्स्ट कंपाइलर तय करता है:

• हमेशा क्या चाहिए
• बाद में क्या प्राप्त किया जा सकता है
• क्या बासी हो गया है
• क्या संक्षेपित किया जा सकता है
• क्या शब्दशः रहना चाहिए

उद्देश्य अधिकतम कॉन्टेक्स्ट नहीं है।

यह प्रति टोकन अधिकतम सिग्नल है।

4. टूल का ढेर नहीं, टूल गेटवे बनाएं

एक एजेंट को बीस टूल देना उसे सक्षम नहीं बनाता है।

यह एजेंट को गलती करने के बीस तरीके देता है।

हर टूल का एक स्पष्ट अनुबंध होना चाहिए:

1TOOL: edit_file
2
3inputs:
4  path
5  patch
6
7preconditions:
8  path exists
9  path is inside allowed workspace
10
11success evidence:
12  patch applied
13  resulting diff returned
14
15failure behavior:
16  no partial overwrite
17  structured error returned
18
19risk class:
20  reversible

हार्नेस को नियंत्रित करना चाहिए कि टूल कैसे उजागर और उपयोग किए जाते हैं।

यह कर सकता है:

• अप्रासंगिक टूल को छिपाना
• तर्कों को मान्य करना
• पथ और डोमेन को प्रतिबंधित करना
• टाइमआउट संलग्न करना
• रीट्राई को आइडेम्पोटेंट बनाना
• आउटपुट को सामान्य करना
• जोखिम भरी कार्रवाइयों के लिए पुष्टि की आवश्यकता
• सिर्फ "सफलता" नहीं, बल्कि सबूत वापस करना

यह एक महत्वपूर्ण अलगाव पैदा करता है:

1model decides intent
2gateway validates action
3tool changes environment
4sensor observes result

मॉडल एक कार्रवाई का प्रस्ताव कर सकता है।

टूल गेटवे तय करता है कि वह कार्रवाई निष्पादित करने के लिए पर्याप्त मान्य है या नहीं।

5. दिमाग, हाथ और इतिहास को अलग करें

कई कमज़ोर एजेंट सब कुछ एक बढ़ती हुई ट्रांसक्रिप्ट में मिला देते हैं।

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

एक मज़बूत सिस्टम तीन ज़िम्मेदारियों को अलग करता है:

1BRAIN
2plans, reasons, chooses
3
4HANDS
5execute tools inside a controlled environment
6
7HISTORY
8stores durable facts, decisions, and run state

मॉडल को सक्रिय कॉन्टेक्स्ट में हर कच्ची घटना की आवश्यकता नहीं है।

उसे सही वर्तमान स्थिति की आवश्यकता है।

सैंडबॉक्स को पूरे उद्देश्य को समझने की आवश्यकता नहीं है।

उसे सुरक्षित रूप से एक सीमित कार्रवाई को निष्पादित करने की आवश्यकता है।

सत्र लॉग को तर्क करने की आवश्यकता नहीं है।

उसे वर्तमान कॉन्टेक्स्ट गायब होने के बाद जो हुआ उसे संरक्षित करने की आवश्यकता है।

यह अलगाव लंबे समय तक चलने वाले एजेंटों को फिर से शुरू करना, निरीक्षण करना और मरम्मत करना आसान बनाता है।

यह आपको पूरे सिस्टम को फिर से बनाए बिना एक हिस्से को बदलने की भी अनुमति देता है।

6. मेमोरी को टिकाऊ स्थिति (Durable State) बनना चाहिए

बातचीत का इतिहास विश्वसनीय मेमोरी नहीं है।

यह एक घटना धारा (event stream) है।

उपयोगी मेमोरी को स्पष्ट स्थिति (explicit state) में परिवर्तित किया जाना चाहिए।

कम से कम, चार श्रेणियों को संरक्षित करें:

1FACTS
2stable information discovered about the environment
3
4DECISIONS
5choices made and the reason behind them
6
7PROGRESS
8completed, active, blocked, and remaining work
9
10LESSONS
11failures that should change future behavior

उदाहरण के लिए:

1facts:
2  - checkout validation lives in services/orders
3
4decisions:
5  - reuse the existing validation pipeline
6  - reason: avoids a second source of truth
7
8progress:
9  completed:
10    - added server-side rule
11  remaining:
12    - update integration test
13
14lessons:
15  - local test command requires TEST_DB_URL

यह पचास पन्नों की ट्रांसक्रिप्ट को फिर से चलाने और यह उम्मीद करने से कहीं अधिक उपयोगी है कि मॉडल को महत्वपूर्ण पंक्ति दिखाई देगी।

ऑडिटेबिलिटी के लिए कच्चा इतिहास संग्रहीत करें।

निष्पादन के लिए टिकाऊ स्थिति संकलित करें।

7. पूर्णता के लिए सबूत चाहिए

एजेंट का "हो गया" कहना इस बात का सबूत नहीं है कि काम हो गया है।

यह सिर्फ एक और मॉडल आउटपुट है।

पूर्णता का फैसला एनवायरनमेंट में देखे जा सकने वाले बदलावों से होना चाहिए।

1claim                         evidence
2--------------------------------------------------
3"the bug is fixed"            failing test now passes
4"the page works"              browser flow completed
5"the migration is safe"       dry run and rollback pass
6"the report is correct"       values match source data
7"the task is complete"        every acceptance check passes

हार्नेस को पहले सबसे सस्ती नियतात्मक जाँच (deterministic checks) चलानी चाहिए।

1syntax
2  -> types
3      -> focused tests
4          -> integration tests
5              -> visual or semantic review
6                  -> human approval

जहाँ एक कंपाइलर, स्कीमा, चेकसम, क्वेरी या टेस्ट सवाल का जवाब दे सकता है, वहाँ किसी दूसरे मॉडल का उपयोग न करें।

अस्पष्टता के लिए मॉडल का उपयोग करें।

प्लंबिंग के लिए कोड का उपयोग करें।

एक मॉडल प्रस्ताव कर सकता है कि कार्य पूरा हो गया है।

केवल एनवायरनमेंट ही इसे साबित कर सकता है।

8. सत्यापन को परिणाम पर हमला करना चाहिए

काम करने वालों और मूल्यांकनकर्ताओं का एक ही उद्देश्य नहीं होना चाहिए।

काम करने वाला सबसे मजबूत समाधान बनाने की कोशिश करता है।

मूल्यांकनकर्ता यह खोजने की कोशिश करता है कि इसे क्यों खारिज किया जाना चाहिए।

1worker
2  -> produces candidate
3
4verifier
5  -> checks contract
6  -> searches for missing cases
7  -> tests unsupported claims
8  -> attempts to break result
9
10survives
11  -> accept
12
13fails
14  -> return targeted evidence

यह विषमता मायने रखती है।

यदि आप उसी एजेंट से, उसी संदर्भ में, "अपने काम की दोबारा जाँच करने" के लिए कहते हैं, तो वह अक्सर उन मान्यताओं को संरक्षित करता है जिन्होंने गलती पैदा की।

एक उपयोगी सत्यापन चरण में होना चाहिए:

• एक स्पष्ट अस्वीकृति मानदंड (rejection rubric)
• निर्मित आर्टिफैक्ट तक पहुंच
• स्वीकृति अनुबंध तक पहुंच
• जरूरत पड़ने पर स्वतंत्र उपकरण या ताजा संदर्भ
• मरम्मत किए बिना अस्वीकार करने की अनुमति

सत्यापन कोई दूसरी राय नहीं है।

यह एक प्रयासित खंडन (attempted disproof) है।

9. मॉडल प्रस्ताव करता है, नीति अधिकृत करती है

कुछ नियम कभी भी इस बात पर निर्भर नहीं होने चाहिए कि मॉडल उन्हें याद रखता है या नहीं।

1never publish without approval
2never expose a secret
3never write outside the workspace
4never exceed the spend cap
5never mark tests passed unless they ran

ये प्रॉम्प्ट सुझाव नहीं हैं।

ये नीति (policy) हैं।

सबसे सुरक्षित डिज़ाइन नीति को रीज़निंग लूप के बाहर रखता है।

1LOW RISK
2read files, search, inspect
3-> automatic
4
5REVERSIBLE CHANGE
6edit workspace, run tests
7-> automatic with trace
8
9EXTERNAL EFFECT
10send message, deploy, purchase
11-> explicit approval
12
13IRREVERSIBLE OR SENSITIVE
14delete data, rotate credentials, publish globally
15-> hard gate or prohibited

परिणाम जितना मजबूत होगा, गेट उतना ही कठिन होगा।

स्वायत्तता नियंत्रण का अभाव नहीं है।

यह स्पष्ट रूप से लागू सीमा के अंदर स्वतंत्र रूप से काम करने की क्षमता है।

10. रिकवरी को फेलियर क्लास को लक्षित करना चाहिए

सबसे आम रिकवरी रणनीति है:

कुछ फेल हो गया। फिर से प्रयास करें।

यह रिकवरी नहीं है।

यह दोहराव है।

हार्नेस को अगली कार्रवाई का चयन करने से पहले विफलता को वर्गीकृत करना चाहिए।

1tool timeout
2-> retry with backoff
3
4invalid arguments
5-> repair the tool call
6
7missing context
8-> retrieve specific source
9
10failed test
11-> inspect failing behavior
12
13permission denied
14-> request approval or choose safe path
15
16contradictory requirements
17-> escalate to human
18
19repeated unchanged failure
20-> stop the loop

एक रीट्राई को कम से कम एक प्रासंगिक स्थिति को बदलना चाहिए।

अन्यथा सिस्टम उसी विफलता को पुन: उत्पन्न करने के लिए भुगतान कर रहा है।

एक सीमित एजेंट लूप इस तरह दिखता है:

1observe
2  -> decide
3      -> act
4          -> measure
5              -> accept
6              -> repair
7              -> escalate
8              -> stop

हर लूप को एक बजट की आवश्यकता होती है:

• अधिकतम प्रयास
• अधिकतम समय
• अधिकतम व्यय
• अधिकतम विनाशकारी दायरा
• एस्केलेशन की स्थिति

विश्वसनीय एजेंट जानते हैं कि कैसे जारी रखना है।

वे यह भी जानते हैं कि जारी रखना कब तर्कसंगत नहीं रह जाता है।

11. निर्देशों को इन्फ्रास्ट्रक्चर बनना चाहिए

एजेंट निर्देश तब उपयोगी होते हैं जब वे स्थानीय वास्तविकता की व्याख्या करते हैं।

लेकिन अकेले निर्देश कमज़ोर प्रवर्तन हैं।

यदि कोई नियम बार-बार मायने रखता है, तो उसे स्टैक में नीचे ले जाएं।

1"use the formatter"
2-> run formatter automatically
3
4"do not import across layers"
5-> add architecture test
6
7"include a migration rollback"
8-> require rollback file in CI
9
10"do not modify generated files"
11-> block writes to generated paths
12
13"cite every external claim"
14-> validate citation coverage

यह एक निर्देश सीढ़ी (instruction ladder) बनाता है:

1explanation
2  -> checklist
3      -> template
4          -> automated check
5              -> enforced policy

महत्वपूर्ण ज्ञान को उस सीढ़ी पर जहाँ तक व्यावहारिक हो, नीचे ले जाएं।

प्रॉम्प्ट को निर्णय की व्याख्या करनी चाहिए।

हार्नेस को इनवेरिएंट्स (invariants) लागू करना चाहिए।

12. सिर्फ अंतिम जवाब नहीं, बल्कि रन का निरीक्षण करें

एक साफ-सुथरा अंतिम आर्टिफैक्ट एक भयानक प्रक्रिया को छिपा सकता है।

एजेंट ने हो सकता है:

• गलत डेटा एक्सेस किया हो
• एक विफल कमांड को नजरअंदाज किया हो
• किसी बाहरी कार्रवाई को दो बार दोहराया हो
• अपेक्षित बजट से दस गुना अधिक खर्च किया हो
• गलत कारण से सही उत्तर तक पहुंचा हो

आपको ऐसे ट्रेस चाहिए जो रन को पुनर्निर्माण योग्य बनाते हैं।

109:14  contract created
209:15  context source loaded: architecture.md
309:17  file edited: checkout.ts
409:18  focused test failed: duplicate coupon
509:21  implementation repaired
609:22  focused test passed
709:24  integration test passed
809:25  external deployment blocked: approval required

एक उपयोगी ट्रेस रिकॉर्ड करता है:

• स्थिति परिवर्तन (state transitions)
• संदर्भ स्रोत
• टूल इनपुट और आउटपुट
• एनवायरनमेंट परिवर्तन
• सत्यापन परिणाम
• रीट्राई कारण
• अनुमोदन निर्णय
• लागत और विलंबता

लक्ष्य निगरानी नहीं है।

लक्ष्य स्थानीय मरम्मत है।

जब कोई रन चरण 18 पर विफल होता है, तो आपको पूरे कार्य को फिर से चलाने के बजाय एक विश्वसनीय चेकपॉइंट से पुनरारंभ करने में सक्षम होना चाहिए।

13. हर रन को एक चेंज रसीद की आवश्यकता होती है

लंबी एजेंट ट्रांसक्रिप्ट की समीक्षा करना कठिन है।

रन के अंत में, हार्नेस को एक छोटी चेंज रसीद संकलित करनी चाहिए।

1OBJECTIVE
2Fix duplicate coupon application during checkout.
3
4CHANGED
5- checkout validation logic
6- focused regression test
7
8VERIFIED
9- lint passed
10- unit tests passed
11- checkout integration test passed
12
13NOT VERIFIED
14- production payment provider
15
16DECISIONS
17- preserved existing coupon priority order
18
19RISKS
20- legacy mobile client was not available locally
21
22APPROVAL NEEDED
23- deploy to staging

रसीद इस बात का सारांश नहीं है कि मॉडल ने क्या कहा।

यह इस बात का सारांश है कि सिस्टम क्या साबित कर सकता है।

यह मनुष्यों को एक संक्षिप्त समीक्षा सतह देता है और अगले एजेंट सत्र को एक विश्वसनीय प्रारंभिक बिंदु देता है।

सबसे अच्छा हैंडऑफ़ "यह रही बातचीत" नहीं है।

यह "यह रही स्थिति, सबूत और अनसुलझा जोखिम" है।

14. हर विफलता को हार्नेस को अपग्रेड करना चाहिए

सबसे कमज़ोर टीमें विफल आउटपुट को ठीक करती हैं।

सबसे मजबूत टीमें उस सिस्टम को भी ठीक करती हैं जिसने इसे अनुमति दी।

विफलता के बाद, पूछें:

1Was the task contract ambiguous?
2Was important context invisible?
3Was the wrong tool exposed?
4Was a precondition missing?
5Was the result unverifiable?
6Was policy left inside the prompt?
7Was recovery too broad?
8Was the trace insufficient?

फिर सबक को एक पुन: प्रयोज्य सुधार में बदलें।

1failure
2  -> diagnosis
3      -> new sensor, rule, map, test, or tool contract
4          -> future runs improve automatically

यह हार्नेस फ्लाईव्हील है।

सिस्टम अधिक विश्वसनीय हो जाता है क्योंकि विफलताएं अपने पीछे इन्फ्रास्ट्रक्चर छोड़ जाती हैं।

एक सही किया गया उत्तर एक रन में मदद करता है।

एक सही किया गया हार्नेस हर भविष्य के रन में मदद करता है।

15. हार्नेस भी क्षय (Decay) होते हैं

अधिक हार्नेस हमेशा बेहतर नहीं होता है।

मॉडल में सुधार होता है। टूल में सुधार होता है। कार्य बदलते हैं। पुराने सुरक्षा उपाय अनावश्यक घर्षण बन सकते हैं।

कल के मॉडल के लिए बनाया गया वर्कअराउंड आज के मॉडल को बेहतर रणनीति का उपयोग करने से रोक सकता है।

यह हार्नेस क्षय (harness decay) पैदा करता है:

1old model limitation
2  -> harness workaround
3      -> model improves
4          -> workaround remains
5              -> system becomes slower or less capable

हार्नेस घटकों को प्रोडक्शन कोड की तरह मानें।

मापें कि क्या वे अभी भी लाभ प्रदान करते हैं।

हर राउटर, मूल्यांकनकर्ता, मेमोरी लेयर और रीट्राई नियम के लिए पूछें:

• यह किस विफलता को रोकता है?
• वह विफलता कितनी बार होती है?
• यह कितनी विलंबता और जटिलता जोड़ता है?
• क्या अब वही परिणाम अधिक सरलता से प्राप्त किया जा सकता है?
• अगर हम इसे हटा दें तो क्या होगा?

सबसे अच्छा हार्नेस सबसे बड़ा नहीं है।

यह सबसे छोटा सिस्टम है जो इरादे और सबूत के बीच के अंतर को विश्वसनीय रूप से पाटता है।

हटाने के लिए बनाएं।

16. न्यूनतम व्यवहार्य हार्नेस (Minimum Viable Harness)

आपको शुरू करने के लिए एक ऑर्केस्ट्रेशन प्लेटफॉर्म की आवश्यकता नहीं है।

हार्नेस को परतों में बनाएं।

स्तर 1: एक सीमित कार्य

• उद्देश्य
• दायरा
• बाधाएं
• स्वीकृति जांच

स्तर 2: एक सुपाठ्य वातावरण

• प्रोजेक्ट मैप
• कमांड
• स्थानीय निर्देश
• ज्ञात निर्भरताएं

स्तर 3: नियंत्रित क्रियाएं

• टाइप किए गए टूल
• तर्क सत्यापन
• पथ और अनुमति सीमाएं
• संरचित परिणाम

स्तर 4: टिकाऊ निष्पादन

• स्पष्ट रन स्थिति
• चेकपॉइंट
• निर्णय
• सबक

स्तर 5: सबूत

• नियतात्मक जांच
• प्रतिकूल सत्यापन
• परिवर्तन रसीद

स्तर 6: रिकवरी और सीखना

• विफलता वर्गीकरण
• सीमित रीट्राई
• एस्केलेशन
• बार-बार होने वाली विफलताओं से हार्नेस अपडेट

सबसे छोटी परत बनाएं जो आपकी वास्तविक विफलता को समाप्त करती है।

मल्टी-एजेंट आर्किटेक्चर से शुरुआत न करें क्योंकि एक एकल प्रॉम्प्ट को कभी-कभी स्पष्टीकरण की आवश्यकता होती है।

जटिलता देखी गई विफलता से अर्जित की जानी चाहिए।

17. एक पुन: प्रयोज्य हार्नेस विनिर्देश

एजेंट को सार्थक स्वायत्तता देने से पहले, इसे परिभाषित करें:

1AGENT HARNESS SPEC
2
31. CONTRACT
4   objective:
5   scope:
6   constraints:
7   acceptance evidence:
8
92. CONTEXT
10   always-loaded map:
11   retrieval sources:
12   local instructions:
13   freshness rules:
14
153. TOOLS
16   allowed tools:
17   preconditions:
18   side effects:
19   success evidence:
20   timeout and retry policy:
21
224. STATE
23   facts:
24   decisions:
25   progress:
26   lessons:
27   checkpoint format:
28
295. POLICY
30   automatic actions:
31   approval-required actions:
32   prohibited actions:
33   budget limits:
34
356. VERIFICATION
36   deterministic checks:
37   adversarial checks:
38   acceptance rule:
39
407. RECOVERY
41   failure classes:
42   retry limits:
43   escalation conditions:
44   safe rollback:
45
468. OBSERVABILITY
47   trace events:
48   metrics:
49   final change receipt:

यदि ये फ़ील्ड अपरिभाषित हैं, तो एजेंट स्वायत्त नहीं है।

वह तात्कालिक (improvising) कर रहा है।

18. सिस्टम को सही स्तर पर मापें

टोकन गणना अंतिम मीट्रिक नहीं है।

न ही प्रयास किए गए कार्यों की संख्या है।

उपयोगी इकाई स्वीकृत कार्य (accepted work) है।

एक व्यावहारिक मीट्रिक है:

1accepted outputs
2------------------------------
3human review minutes + run cost

इसे भी ट्रैक करें:

• प्रथम-पास स्वीकृति दर
• टूल विफलता के बाद पुनर्प्राप्ति दर
• बार-बार विफलता दर
• प्रति कार्य मानवीय हस्तक्षेप
• असमर्थित पूर्णता दावे
• अनुरोध से सत्यापित परिणाम तक का समय
• घटक द्वारा हार्नेस ओवरहेड

यह एक सामान्य भ्रम को रोकता है:

एक एजेंट अत्यधिक उत्पादक दिख सकता है जबकि महंगा समीक्षा कार्य बना रहा हो।

उद्देश्य अधिक एजेंट गतिविधि नहीं है।

यह प्रति यूनिट मानवीय ध्यान में अधिक भरोसेमंद परिणाम है।

19. जब आपको भारी हार्नेस की आवश्यकता नहीं है

हर मॉडल कॉल को ऑपरेटिंग सिस्टम की आवश्यकता नहीं होती है।

एक सरल प्रॉम्प्ट का उपयोग करें जब:

• कार्य छोटा हो
• आउटपुट का निरीक्षण करना आसान हो
• विफलता सस्ती हो
• कोई बाहरी दुष्प्रभाव न हो
• उपयोगकर्ता लूप में बना रहे

हार्नेस जोड़ें जब:

• काम कई टूल या सत्रों में फैला हो
• एनवायरनमेंट बदल सकता है
• कार्यों के वास्तविक परिणाम हों
• पूर्णता का मैन्युअल रूप से न्याय करना कठिन हो
• वही विफलता बार-बार दिखाई दे
• मानवीय समीक्षा अड़चन बन जाए

हार्नेस का उद्देश्य किसी डेमो को परिष्कृत दिखाना नहीं है।

यह वास्तविक काम को भरोसेमंद बनाना है।

असली बदलाव

AI उत्पादों की पहली पीढ़ी प्रॉम्प्ट के आसपास बनाई गई थी।

अगली पीढ़ी एनवायरनमेंट के आसपास बनाई जा रही है।

सवाल अब केवल यह नहीं है:

हम मॉडल के जवाब को बेहतर कैसे बनाएं?

बल्कि यह है:

हम एक ऐसा सिस्टम कैसे बनाएं जहाँ अच्छे कार्य आसान हों, खतरनाक कार्य नियंत्रित हों, विफलताएँ दिखाई दें, और पूर्णता साबित करने योग्य हो?

यह प्रॉम्प्ट इंजीनियरिंग से हार्नेस इंजीनियरिंग की ओर बदलाव है।

मॉडल बुद्धिमत्ता प्रदान करता है।

हार्नेस संरचना प्रदान करता है।

साथ मिलकर वे विश्वसनीय निष्पादन उत्पन्न करते हैं।

यदि आपका एजेंट बार-बार बिखरता रहता है, तो प्रॉम्प्ट में विशेषण जोड़ना बंद करें।

वह एनवायरनमेंट बनाएं जिसकी उसे सफल होने के लिए आवश्यकता है।

अगर आप यहाँ तक पहुँचे हैं

इस गाइड को बुकमार्क करें।

X पर @LunarResearcher को फ़ॉलो करें

मेरे Substack की सदस्यता लें

यह लेख किसी ऐसे व्यक्ति को भेजें जो अभी भी हर एजेंट विफलता को एक लंबे प्रॉम्प्ट से ठीक करने की कोशिश कर रहा है।