आइए Claude Code का हार्नेस बनाएं (स्टेप-बाय-स्टेप)

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

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

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

फिर वही कार्य Claude Code से होकर गुज़रता है और साफ-सुथरा पूरा होता है। आसान निष्कर्ष यह है कि Anthropic के पास बस एक बेहतर मॉडल है, और वह निष्कर्ष इस बात को खो देता है कि वास्तव में काम कहाँ होता है।

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

यहाँ देखिए कि एक पूरी तरह से हार्नेस किया गया एजेंट कैसा दिखता है जब आप इसे ड्रॉ करते हैं:

GIF

तस्वीर व्यस्त दिखती है, लेकिन यह चार समूहों में टूट जाती है:

• Memory मॉडल को उसका कार्यशील संदर्भ और उन तथ्यों को प्रदान करता है जो उसने सत्रों में सीखे हैं।
• Skills एनकोड करता है कि एजेंट को कैसे संचालित होना चाहिए, यानी वह प्रक्रियाएँ, बाधाएँ और ह्यूरिस्टिक्स जिनका वह पालन करता है।
• Protocols एजेंट को उपयोगकर्ताओं, टूल्स और अन्य एजेंटों से जोड़ते हैं।
• The harness core सब-एजेंट ऑर्केस्ट्रेशन, एक सैंडबॉक्स, एक मूल्यांकनकर्ता, एक अनुमोदन लूप, ऑब्ज़र्वेबिलिटी और कॉन्टेक्स्ट कम्प्रेशन के साथ सब कुछ एक साथ जोड़ता है।

Anthropic इस विभाजन को मस्तिष्क और हाथों के रूप में वर्णित करता है। मॉडल मस्तिष्क है जो प्रत्येक क्रिया को चुनता है, और हार्नेस हाथ हैं जो इसे क्रियान्वित करते हैं और रन को ट्रैक पर रखते हैं।

तो आपके एजेंट और Claude Code के बीच का अंतर मॉडल नहीं है, यह मॉडल के आसपास की मशीनरी है।

Claude Code आज प्रोडक्शन में सबसे सक्षम हार्नेस में से एक है, और यह उस चित्रण में परतों के एक आश्चर्यजनक रूप से छोटे सेट से बनाया गया है। यह देखने के लिए कि उस मशीनरी का कितना हिस्सा आपको खुद बनाना होगा, मैंने इसे CrewAI में फिर से बनाया, जो एजेंटों को ऑर्केस्ट्रेट करने के लिए एक ओपन-सोर्स फ्रेमवर्क है।

इसका अधिकांश भाग बिल्ट-इन सुविधाओं पर मैप होता है जितना मैंने उम्मीद की थी, और जो हिस्सा नहीं होता वह वहाँ है जहाँ वास्तविक इंजीनियरिंग रहती है।

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

Claude Code का हार्नेस कैसे काम करता है

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

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

उस लूप के अंदर, मॉडल फ़ाइलों को पढ़ता है, कोड को संपादित करता है, शेल कमांड चलाता है और टेस्ट निष्पादित करता है। ये अलग-अलग मोड नहीं हैं। ये बस एक ही लूप के अंदर अलग-अलग टूल कॉल हैं।

हालांकि, अकेला लूप एक विश्वसनीय कोडिंग एजेंट के लिए पर्याप्त नहीं है। Claude Code इसके चारों ओर प्लानिंग, फ़ाइल टूल, सबएजेंट, मेमोरी और एक अनुमति और सैंडबॉक्स सिस्टम जोड़ता है। ये परतें लूप को प्रतिस्थापित नहीं करती हैं, वे इसे वास्तविक कार्य के लिए पर्याप्त सुरक्षित और विश्वसनीय बनाती हैं।

यह वह आर्किटेक्चर है जिसे हम फिर से बनाएंगे, पहले कोर लूप, फिर प्रत्येक परत ऊपर, प्रत्येक परत को CrewAI सुविधा से मैप करते हुए जो इसे संभालती है।

कोर एजेंट लूप

लूप तब तक एक ही अनुक्रम चलाता है जब तक कार्य पूरा नहीं हो जाता:

1. मॉडल से कार्य करने के लिए कहें।
2. मॉडल सीधे जवाब देता है या एक या अधिक टूल का अनुरोध करता है।
3. यदि टूल का अनुरोध किया जाता है, तो उन्हें चलाएँ और परिणाम मॉडल को वापस करें।
4. अपडेटेड बातचीत के साथ दोहराएँ।
5. जब मॉडल बिना किसी टूल के अनुरोध के जवाब देता है, तो कार्य पूर्ण हो जाता है।

1while True:
2    reply = model(messages, tools)
3    calls = [b for b in reply if b.type == "tool_use"]
4    if not calls:            # सादा टेक्स्ट, कोई टूल कॉल नहीं: काम हो गया
5        return reply.text
6    messages += [reply, run_all(calls)]

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

CrewAI यह एक्ज़ीक्यूशन लूप स्वचालित रूप से प्रदान करता है जैसे ही आप एक एजेंट बनाते हैं। आप स्वयं while लूप लागू नहीं करते हैं, आप एजेंट को परिभाषित करते हैं और उसे एक कार्य सौंपते हैं।

पहला एजेंट बनाना

चलिए एक सरल Bug Fixer एजेंट बनाते हैं।

1from crewai import LLM, Agent, Crew, Task
2
3bug_fixer = Agent(
4    role="Bug Fixer",
5    goal="रिपोर्ट किए गए बग के लिए कोडबेस में फिक्स ढूंढें और उसका वर्णन करें।",
6    backstory="आप कोड की सटीक तस्वीर बनाने के लिए निर्देशिकाओं और फ़ाइलों को पढ़ते हैं।",
7    llm="claude-sonnet-4-6",
8)
9
10task = Task(
11    description="{objective} के लिए फिक्स ढूंढें।",
12    expected_output="फिक्स का एक संक्षिप्त विवरण और यह किस फ़ाइल में है।",
13)
14
15result = Crew(agents=[bug_fixer], tasks=[task]).kickoff(
16    inputs={"objective": "account.py में ओवरड्राफ्ट बग"}
17)

यहाँ तीन अवधारणाओं को समझना है:

• एक Agent अपनी भूमिका, लक्ष्य, LLM और टूल्स के माध्यम से परिभाषित करता है कि काम कौन करता है।
• एक Task असाइनमेंट का वर्णन करता है।
• एक Crew एजेंटों और कार्यों को एक साथ लाता है। kickoff() को कॉल करना ऊपर वर्णित उसी एक्ज़ीक्यूशन लूप को चलाता है, चाहे अंतर्निहित मॉडल Anthropic, OpenAI, Google या कुछ और हो।

एजेंट को टूल देना

टूल्स वह हैं जो एक मॉडल को, जो केवल टेक्स्ट उत्पन्न करता है, वास्तव में कोडबेस पर काम करने देते हैं। वे फ़ाइलों को पढ़ते हैं, उन्हें लिखते हैं, शेल कमांड चलाते हैं और बाहरी APIs को कॉल करते हैं।

CrewAI बॉक्स से बाहर फ़ाइल सिस्टम टूल्स शिप करता है:

• FileReadTool फ़ाइलों को पढ़ता है।
• DirectoryReadTool निर्देशिकाओं को सूचीबद्ध करता है।
• FileWriterTool फ़ाइलों को लिखता है।

1from crewai_tools import DirectoryReadTool, FileReadTool, FileWriterTool
2
3read_file = FileReadTool()
4write_file = FileWriterTool()
5list_dir = DirectoryReadTool()
6
7filesystem_tools = [read_file, write_file, list_dir]

ये बाहरी मेमोरी के रूप में भी काम करते हैं। मॉडल के कॉन्टेक्स्ट विंडो में एक बड़ा खोज परिणाम रखने के बजाय, एजेंट इसे एक फ़ाइल में लिख सकता है, केवल फ़ाइल का नाम रख सकता है, और जरूरत पड़ने पर इसे वापस पढ़ सकता है।

यह कॉन्टेक्स्ट विंडो को छोटा और मॉडल को अधिक केंद्रित रखता है, जिसे Anthropic कॉन्टेक्स्ट इंजीनियरिंग कहता है।

बिल्ट-इन टूल्स केवल सामान्य वर्कफ़्लो को कवर करते हैं। कुछ और विशिष्ट के लिए, आप @tool डेकोरेटर के साथ एक Python फ़ंक्शन को टूल के रूप में एक्सपोज़ करते हैं।

डॉकस्ट्रिंग एक निर्देश पुस्तिका के रूप में कार्य करता है, मॉडल को बताता है कि टूल क्या करता है, इसका उपयोग कब करना है, और यह इनपुट के रूप में क्या अपेक्षा करता है।

1from crewai.tools import tool
2import subprocess
3
4@tool("run_tests")
5def run_tests(path: str = "tests/") -> str:
6    """दिए गए पथ पर pytest सूट चलाएँ और परिणाम लौटाएँ।"""
7    result = subprocess.run(
8        ["pytest", path, "-q"], capture_output=True, text=True, timeout=120
9    )
10    output = result.stdout + result.stderr
11    return output[-4000:] if len(output) > 4000 else output

लंबे समय तक चलने वाले कार्यों की योजना बनाना

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

इस धीमी गिरावट को लोग कॉन्टेक्स्ट रॉट कहते हैं।

योजना सीधे इसका समाधान करती है। एजेंट कोई भी काम करने से पहले एक चरण-दर-चरण योजना बनाता है और उस योजना को निष्पादन के दौरान कॉन्टेक्स्ट में रखता है।

योजना काम नहीं करती है। यह एक रोडमैप है जो मॉडल को मूल लक्ष्य से जोड़े रखता है, जो वही काम है जो Claude Code की टू-डू लिस्ट करती है।

CrewAI इसे क्रू स्तर पर planning=True के साथ जोड़ता है। यह निष्पादन से पहले एक योजना उत्पन्न करता है और कार्य आगे बढ़ने पर इसे उपलब्ध रखता है।

1from crewai import Crew, LLM
2
3crew = Crew(
4    agents=self.agents,
5    tasks=self.tasks,
6    planning=True,
7    planning_llm=LLM(model="gpt-4o-mini"),
8)

नोट: डिफ़ॉल्ट रूप से, CrewAI प्लानिंग के लिए gpt-4o-mini का उपयोग करता है, और आप उस चरण के लिए अपनी पसंद का कोई भी LLM बदल सकते हैं।

व्यक्तिगत एजेंट reasoning=True के साथ अपने स्वयं के काम के बारे में भी तर्क कर सकते हैं:

1from crewai import Agent
2
3bug_fixer = Agent(
4    role="Bug Fixer",
5    goal="रिपोर्ट किए गए बग के लिए कोडबेस में फिक्स ढूंढें और उसका वर्णन करें।",
6    backstory="आप कोड की सटीक तस्वीर बनाने के लिए निर्देशिकाओं और फ़ाइलों को पढ़ते हैं।",
7    tools=[FileReadTool()],
8    reasoning=True,
9    max_reasoning_attempts=3  # वैकल्पिक: तर्क प्रयासों की अधिकतम संख्या निर्धारित करें
10)

प्लानिंग और रीज़निंग अलग-अलग समस्याओं का समाधान करते हैं। प्लानिंग समग्र कार्य के लिए एक उच्च-स्तरीय रोडमैप बनाती है, जबकि रीज़निंग एक एजेंट को कार्य करने से पहले अपने स्वयं के दृष्टिकोण के बारे में सोचने का समय देती है।

जब रीज़निंग सक्षम होती है, तो एजेंट:

1. कार्य पर विचार करता है और एक निष्पादन योजना का मसौदा तैयार करता है।
2. मूल्यांकन करता है कि योजना तैयार है या नहीं।
3. यदि आवश्यक हो तो योजना को परिष्कृत करता है, जब तक कि वह संतुष्ट न हो जाए या max_reasoning_attempts तक न पहुँच जाए।
4. निष्पादन से पहले अंतिम रीज़निंग योजना को कार्य में इंजेक्ट करता है।

एक साथ, वे एजेंट को लंबे समय तक चलने वाले कार्यों पर एंकर रखते हैं और मूल लक्ष्य से बहाव को कम करते हैं।

सबएजेंट के साथ प्रतिनिधित्व करना

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

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

सबएजेंट प्रतिनिधिमंडल के माध्यम से इसे हल करते हैं। मुख्य एजेंट एक विशिष्ट कार्य एक सहायक एजेंट को सौंपता है, जो अपने स्वयं के कॉन्टेक्स्ट में काम करता है और एक संक्षिप्त सारांश लौटाता है। मुख्य एजेंट निष्कर्ष देखता है, मध्यवर्ती चरणों को नहीं।

CrewAI इसे पदानुक्रमित वर्कफ़्लो के माध्यम से समर्थन करता है, जहाँ एक प्रबंधक एजेंट विशेषज्ञ एजेंटों को प्रतिनिधित्व करता है और उनके परिणामों को जोड़ता है।

हमारे पहले के सेटअप में, एक Bug Fixer एजेंट ने सभी भारी काम किए। आइए काम को एक प्रबंधक और तीन विशेषज्ञों में विभाजित करें:

• Codebase Explorer कोड का अन्वेषण करता है और रिपॉजिटरी का मैप बनाता है।
• Software Engineer अनुरोधित परिवर्तन को लागू करता है।
• Test Runner सैंडबॉक्स में परीक्षण चलाता है और पास या फेल की रिपोर्ट करता है।
• Engineering Lead तीन विशेषज्ञों की देखरेख करता है।

1from crewai import Crew, Agent, Task, Process
2
3explorer = Agent(
4    role="Codebase Explorer",
5    goal="रिपॉजिटरी का मैप बनाएं और कार्य से संबंधित फ़ाइलों को सामने लाएं।",
6    backstory="आप कोड की तस्वीर बनाने के लिए निर्देशिकाओं और फ़ाइलों को पढ़ते हैं।",
7    tools=[read_file, list_dir],
8    llm=llm,
9)  # Same for other two specialist agents
10
11manager = Agent(
12    role="Engineering Lead",
13    goal="अनुरोध को चरणों में तोड़ें और प्रत्येक को सही विशेषज्ञ को सौंपें।",
14    backstory="आप तय करते हैं कि कौन क्या करता है, परीक्षणों की समीक्षा करें, परिवर्तन हो जाने के बाद समाप्त करें।",
15    llm=llm,
16    allow_delegation=True,
17)
18
19crew = Crew(
20    agents=[explorer, coder, tester],
21    tasks=[task],
22    manager_agent=manager,
23    process=Process.hierarchical,
24)

एक बात ध्यान देने योग्य है कि allow_delegation डिफ़ॉल्ट रूप से अक्षम है, इसलिए इसे प्रबंधक पर स्पष्ट रूप से सक्षम किया जाना चाहिए।

सैंडबॉक्सिंग: एजेंट निष्पादन को सुरक्षित करना

शेल एक्सेस वाला एजेंट एक विनाशकारी कमांड चला सकता है, और मॉडल को कुछ न करने के लिए कहना कोई सुरक्षा उपाय नहीं है।

वास्तविक सुरक्षा दो परतों से आती है:

1. एक अनुमति प्रणाली जो संवेदनशील कार्यों के लिए अनुमोदन की आवश्यकता होती है।
2. एक सैंडबॉक्स जो निष्पादन को अलग करता है, ताकि अनुमोदित कमांड भी होस्ट मशीन को छू न सकें।

Anthropic उसी दृष्टिकोण का उपयोग करता है। कोड निष्पादन को सैंडबॉक्स में ले जाने से यह कम हो जाता है कि उपयोगकर्ता को कितनी बार कार्यों को अनुमोदित करने की आवश्यकता होती है, जबकि होस्ट सिस्टम की सुरक्षा अभी भी बनी रहती है।

CrewAI में सैंडबॉक्सिंग

होस्ट मशीन के बजाय सैंडबॉक्स के अंदर कोड निष्पादित करना उस दूसरी परत को लागू करता है। इस सेटअप में, कोड E2B के अंदर चलता है, जो प्रति सत्र एक ताज़ा VM स्पिन करता है और बाद में उसे नष्ट कर देता है।

शेल कमांड और Python पूरी तरह से उस पृथक वातावरण के अंदर चलते हैं।

1from crewai_tools import E2BExecTool, E2BPythonTool
2sandbox_tools = [E2BExecTool(), E2BPythonTool()]  # run tests / run code

मानव-इन-द-लूप अनुमोदन

किसी Task पर human_input=True सेट करने से क्रू उत्तर उत्पन्न करने के बाद रुक जाता है। आप आउटपुट की समीक्षा करते हैं, फिर इसे अनुमोदित करते हैं या इसे फिर से पुनरावृत्ति के लिए वापस भेजते हैं।

जब निष्पादन उस कार्य तक पहुँचता है, तो CrewAI मानक इनपुट के माध्यम से आपकी प्रतिक्रिया की प्रतीक्षा करता है।

1from crewai import Task
2
3task = Task(
4    description=(
5        "कार्यशील निर्देशिका ./workspace में, {objective}। "
6        "पहले कोड का अन्वेषण करें, फिर परिवर्तन करें, फिर परीक्षण चलाएँ और रिपोर्ट करें।"
7    ),
8    expected_output="बदली गई फ़ाइलों का सारांश और अंतिम परीक्षण आउटपुट।",
9    human_input=True,
10)

यदि आपका क्रू टर्मिनल के बजाय वेब ऐप या चैट इंटरफ़ेस के पीछे चलता है, तो CrewAI का वेबहुक-आधारित ह्यूमन-इन-द-लूप सिस्टम उसी समीक्षा चरण को संभालता है।

मेमोरी और चेकपॉइंटिंग

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

दो तंत्र एक एजेंट को रनों में जानकारी ले जाने देते हैं, और प्रत्येक एक अलग उद्देश्य पूरा करता है:

• Checkpointing एक रन के दौरान एजेंट की स्थिति को सहेजता है, ताकि यह रुकावट के बाद फिर से शुरू हो सके या एक अलग पथ पर उसी बिंदु से जारी रह सके।
• Persistent memory अलग-अलग बातचीत में तथ्यों को संग्रहीत करता है, जिसमें प्रोजेक्ट प्राथमिकताएँ शामिल हैं जैसे "समाप्त करने से पहले अंतिम कोड को हमेशा फ़ॉर्मेट करें।"

CrewAI में मेमोरी

CrewAI अलग-अलग शॉर्ट-टर्म, लॉन्ग-टर्म, एंटिटी और एक्सटर्नल मेमोरी प्रकारों के बजाय एक एकीकृत Memory इंटरफ़ेस प्रदान करता है। सहेजते समय, यह महत्वपूर्ण विवरणों की पहचान करने, उन्हें व्यवस्थित करने और बाद में उन्हें पुनर्प्राप्त करने योग्य बनाने के लिए LLM का उपयोग करता है।

क्रू पर memory=True सेट करने से इसे रनों में मेमोरी मिलती है। प्रत्येक कार्य के बाद, CrewAI आउटपुट से उपयोगी तथ्य निकालता है और उन्हें संग्रहीत करता है, और भविष्य के रनों में यह प्रासंगिक यादों को पुनर्प्राप्त करता है और उन्हें कार्य प्रॉम्प्ट में जोड़ता है।

1from crewai import Crew
2
3crew = Crew(
4    agents=[explorer, coder, tester],
5    tasks=[task],
6    memory=True,
7)

एक क्रू में सभी एजेंट इसकी मेमोरी साझा करते हैं जब तक कि किसी एजेंट को अपनी खुद की मेमोरी नहीं दी जाती।

CrewAI में चेकपॉइंटिंग

चेकपॉइंट एक एजेंट की प्रगति का एक स्नैपशॉट है, जिसमें इसका कॉन्फ़िगरेशन, कार्य स्थिति, मेमोरी, मध्यवर्ती परिणाम, इनपुट और निष्पादन इतिहास शामिल है।

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

चेकपॉइंट दो बिल्ट-इन स्टोर में से एक में रह सकते हैं:

• JsonProvider प्रत्येक चेकपॉइंट को एक अलग JSON फ़ाइल के रूप में सहेजता है, जिसे मैन्युअल रूप से पढ़ना और निरीक्षण करना आसान है।
• SqliteProvider सभी चेकपॉइंट को एक ही SQLite डेटाबेस में संग्रहीत करता है, जो लगातार चेकपॉइंटिंग और बड़े वर्कलोड के तहत बेहतर रहता है।

1from crewai import Crew
2
3crew = Crew(
4    agents=[explorer, coder, tester],
5    tasks=[task],
6    checkpoint=True,
7)

Crew, Flow और Agent सभी एक checkpoint आर्गुमेंट स्वीकार करते हैं, और चिल्ड्रन अपने माता-पिता से इनहेरिट करते हैं जब तक कि वे अपना खुद का मान सेट नहीं करते।

सब कुछ एक साथ रखना

यहाँ एक कार्य पर पूरा हार्नेस है, जिसमें एक्ज़ीक्यूशन लूप, टूल, प्लानिंग, सबएजेंट, सैंडबॉक्सिंग और मेमोरी एक साथ काम कर रहे हैं:

1from crewai import Agent, Crew, LLM, Process, Task
2from crewai.tools import tool
3from crewai_tools import (DirectoryReadTool, FileReadTool, FileWriterTool,
4E2BExecTool, E2BPythonTool)
5
6llm = LLM(model="anthropic/claude-sonnet-4.6")
7
8list_dir = DirectoryReadTool(directory="./workspace")
9filesystem_tools = [FileReadTool(), FileWriterTool(), list_dir]
10sandbox_tools = [exec_tool, E2BPythonTool()]
11
12@tool("run_tests")
13def run_tests(path: str = "tests/") -> str:
14    """ ./workspace को सैंडबॉक्स में सिंक करें, फिर वहाँ pytest चलाएँ। """
15    return E2BExecTool().run(command=sync_and_test_command(path))
16
17explorer = Agent(role="Codebase Explorer", goal="रिपॉजिटरी का मैप बनाएं, प्रासंगिक फ़ाइलों को सामने लाएं।",
18    tools=[read_file, list_dir], llm=llm)
19coder = Agent(role="Software Engineer", goal="अनुरोधित परिवर्तन को लागू करें।",
20    tools=filesystem_tools, reasoning=True, llm=llm)
21tester = Agent(role="Test Runner", goal="सैंडबॉक्स में परीक्षण चलाएं, पास/फेल की रिपोर्ट करें।",
22    tools=sandbox_tools + [read_file] + [run_tests], llm=llm)
23manager = Agent(role="Engineering Lead", goal="चरणों का प्रतिनिधित्व करें, परीक्षण पास होने पर समाप्त करें।",
24    allow_delegation=True, llm=llm)
25
26task = Task(
27    description="./workspace में, {objective}। अन्वेषण करें, संपादित करें, परीक्षण करें, रिपोर्ट करें।",
28    expected_output="परिवर्तनों का सारांश और परीक्षण आउटपुट।", human_input=True,
29)
30crew = Crew(
31    agents=[explorer, coder, tester], tasks=[task],
32    manager_agent=manager, process=Process.hierarchical,
33    planning=True, memory=True, checkpoint=True,
34)
35result = crew.kickoff(inputs={"objective": "account.py में विफल परीक्षणों को ठीक करें"})

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

तो इसका परीक्षण एक छोटे कोडबेस, एक BankAccount क्लास के खिलाफ किया गया, जिसमें दो वास्तविक बग और पाँच परीक्षण थे, जिनमें से तीन विफल रहे। नियम केवल कार्यान्वयन को ठीक करना था, परीक्षणों को नहीं।

यह दर्शाता है कि Anthropic आंतरिक रूप से कोडिंग एजेंटों का मूल्यांकन कैसे करता है। एक प्रकाशित उदाहरण में Claude claude.ai इंटरफ़ेस का एक क्लोन विफल परीक्षणों के एक बड़े सूट के खिलाफ फिर से बनाता है।

यहाँ, हार्नेस ने प्रोजेक्ट को 3 विफल और 2 पास से सभी 5 पास कर दिया, जिसमें केवल-कार्यान्वयन नियम ने विफल परीक्षणों को संपादित या हटाने के शॉर्टकट को बंद कर दिया।

अभी भी आपका काम क्या है

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

• प्रॉम्प्ट्स। प्रत्येक एजेंट का व्यवहार उसकी भूमिका, लक्ष्य और बैकस्टोरी से आता है। उन्हें सही पाने में परीक्षण और पुनरावृत्ति लगती है, और कोई कॉन्फ़िगरेशन फ़्लैग इसकी जगह नहीं ले सकता।
• निष्पादन वातावरण। सैंडबॉक्स, चाहे E2B हो या स्व-प्रबंधित VM, को सेट अप और वायर्ड करना होता है।
• टूल चयन। प्रत्येक एजेंट को कौन से टूल मिलते हैं, और किस एजेंट की किस चीज़ तक पहुँच होनी चाहिए, यह एक डिज़ाइन निर्णय है जो फ्रेमवर्क नहीं लेता।

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

और एक दीर्घकालिक सीमा है जिसे ध्यान में रखना चाहिए। जैसे-जैसे मॉडल बेहतर होते हैं, कुछ मचान आवश्यक नहीं रह जाता, क्योंकि आज हार्नेस में जो कुछ बनाया जाता है, वह आज की मॉडल सीमाओं का एक वर्कअराउंड है, न कि एक स्थायी आवश्यकता।

Anthropic ने मूल रूप से Claude Sonnet 4.5 को कार्यों को बहुत जल्दी समाप्त करने से रोकने के लिए कॉन्टेक्स्ट रीसेट का उपयोग किया था, और अधिक सक्षम Claude Opus 4.5 के साथ उनकी अब आवश्यकता नहीं रही।

समापन

यह पूरी खोज है। एक कोडिंग एजेंट की क्षमता ज्यादातर हार्नेस में रहती है, और एक ऑर्केस्ट्रेशन फ्रेमवर्क आपको उस हार्नेस का अधिक हिस्सा देता है जितना आप अनुमान लगाते हैं।

लूप, प्लानिंग, प्रतिनिधिमंडल, सैंडबॉक्सिंग और मेमोरी सभी कॉन्फ़िगरेशन के रूप में आते हैं, जबकि प्रॉम्प्ट्स, निष्पादन वातावरण और टूल विकल्प आपके ही रहते हैं।

यदि आप इसे अपने स्वयं के कोडबेस के खिलाफ चलाना चाहते हैं, तो CrewAI दस्तावेज़ यहाँ उपयोग की गई हर सुविधा को कवर करते हैं, और फ्रेमवर्क पूरी तरह से ओपन सोर्स है।

CrewAI दस्तावेज़ देखें →

सभी कोड यहाँ खोजें →

पढ़ने के लिए धन्यवाद!

चीयर्स! :)