# Meta ने $300M में खरीदा Manus - LangChain के साथ बताए एजेंट डेवलपमेंट के मूलभूत सिद्धांत

> Author: Tony Lee
> Published: 2026-02-08
> URL: https://tonylee.im/hi/blog/manus-meta-300m-agent-development-principles/
> Reading time: 5 minutes
> Language: hi
> Tags: ai, ai-agents, manus, meta, langchain, context-engineering, multi-agent

## Canonical

https://tonylee.im/hi/blog/manus-meta-300m-agent-development-principles/

## Rollout Alternates

en: https://tonylee.im/en/blog/manus-meta-300m-agent-development-principles/
ko: https://tonylee.im/ko/blog/manus-meta-300m-agent-development-principles/
ja: https://tonylee.im/ja/blog/manus-meta-300m-agent-development-principles/
zh-CN: https://tonylee.im/zh-CN/blog/manus-meta-300m-agent-development-principles/
zh-TW: https://tonylee.im/zh-TW/blog/manus-meta-300m-agent-development-principles/

## Description

Manus ने LangChain के साथ प्रेज़ेंटेशन में प्रोडक्शन AI एजेंट बनाने की असली चुनौतियाँ साझा कीं - Context Rot से लेकर इवैल्यूएशन की नई सोच तक।

## Summary

Meta ने $300M में खरीदा Manus - LangChain के साथ बताए एजेंट डेवलपमेंट के मूलभूत सिद्धांत is part of Tony Lee's ongoing coverage of AI agents, developer tools, startup strategy, and AI industry shifts.

## Outline

- Context Rot का विरोधाभास
- प्रोडक्ट-मार्केट फिट से पहले Fine-Tune मत करो
- मल्टी-एजेंट पैटर्न: दो अलग-अलग नज़रिए
- Tool Overload रोकने के लिए तीन-लेयर एक्शन स्पेस
- इवैल्यूएशन मेट्रिक्स पर नई सोच
- सबसे बड़ी सीख

## Content

Meta द्वारा Manus को $300 मिलियन में एक्वायर करना सुर्खियों में रहा, लेकिन असली बात वो है जो Manus ने LangChain के साथ एक ज्वॉइंट प्रेज़ेंटेशन में खुलकर बताई। इस टॉक में प्रोडक्शन-रेडी AI एजेंट बनाने के मूलभूत सिद्धांत सामने आए - और स्टार्टअप्स की आम गलतियों और असल में काम करने वाली रणनीतियों के बीच की लकीर साफ़ खींची गई।

## Context Rot का विरोधाभास

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

Manus इसे **Context Rot** कहता है। यह एजेंट डेवलपमेंट का एक बुनियादी विरोधाभास है: जो चीज़ आपके एजेंट को ताकतवर बनाती है, वही उसे कमज़ोर भी करती है।

इसका हल है **Context Engineering** - मॉडल को अगले कदम के लिए बस ज़रूरी जानकारी दिखाओ, उससे एक शब्द ज़्यादा नहीं।

Manus ने छह तकनीकें बताईं:

- **Offload** - टोकन-हैवी डेटा को कॉन्टेक्स्ट में रखने की बजाय फ़ाइल सिस्टम में भेज दो
- **Reduce** - पुरानी और बासी जानकारी को बेरहमी से हटाओ
- **Compact** - रिकवर हो सकने वाले डेटा को रिवर्सिबली कंप्रेस करो (जैसे फ़ाइल का कॉन्टेंट हटा दो, बस पाथ रखो)
- **Summarize** - जानकारी को इर्रिवर्सिबली कंप्रेस करो, लेकिन हमेशा एक स्ट्रक्चर्ड स्कीमा के ज़रिए
- **Retrieve** - सर्च के ज़रिए जानकारी माँगने पर दो
- **Isolate** - सब-एजेंट्स को अलग कॉन्टेक्स्ट दो, जो मुख्य एजेंट से स्वतंत्र हो

सबसे ज़रूरी बात: कॉन्टेक्स्ट मैनेजमेंट कोई "अच्छा-तो-अच्छा" ऑप्टिमाइज़ेशन नहीं है। यह एक कोर आर्किटेक्चरल फ़ैसला है - इसी से तय होता है कि आपका एजेंट स्केल करेगा या अपने ही बोझ तले दब जाएगा।

## प्रोडक्ट-मार्केट फिट से पहले Fine-Tune मत करो

स्टार्टअप्स की सबसे आम गलतियों में से एक जो Manus ने बताई: प्रोडक्ट-मार्केट फिट खोजने से पहले ही स्पेशलाइज़्ड मॉडल बनाना शुरू कर देना।

तर्क सीधा है। एक जनरल-पर्पस मॉडल + मज़बूत कॉन्टेक्स्ट इंजीनियरिंग = बहुत तेज़ इटरेशन साइकल। जब आप जल्दी fine-tune करते हैं, तो आप ऐसी धारणाओं में फँस जाते हैं जो यूज़र बिहेवियर के बारे में अभी वेरिफ़ाई ही नहीं हुई हैं।

ज़्यादा तीखी बात: **जितनी तेज़ी से आप अपने मॉडल को सुधार सकते हैं, वही आपकी प्रोडक्ट इनोवेशन स्पीड की सीमा तय करती है**। Fine-tuning उस साइकल को धीमा करती है। कॉन्टेक्स्ट इंजीनियरिंग उसे तेज़ बनाए रखती है।

Fine-tuning तब करो जब प्रोडक्ट काम कर रहा हो, यह साबित हो चुका हो। उससे पहले यह सबसे महँगा प्रीमैच्योर ऑप्टिमाइज़ेशन है।

## मल्टी-एजेंट पैटर्न: दो अलग-अलग नज़रिए

Manus ने दो बुनियादी मल्टी-एजेंट पैटर्न पहचाने, हर एक अलग तरह के काम के लिए:

**Communicating Pattern** - सब-एजेंट एक साफ़ स्लेट से शुरू करता है। मुख्य एजेंट एक फ़ोकस्ड रिक्वेस्ट भेजता है, सब-एजेंट उसे स्वतंत्र रूप से प्रोसेस करता है, और नतीजा लौटाता है। कम कॉन्टेक्स्ट वाले, पैरेलल में चल सकने वाले कामों के लिए बेस्ट - जैसे कोड सर्च या डेटा रिट्रीवल।

**Shared Memory Pattern** - सब-एजेंट पूरी बातचीत का इतिहास शेयर करते हैं, लेकिन अलग-अलग प्रॉम्प्ट्स और टूल सेट्स के साथ काम करते हैं। जटिल, एक-दूसरे पर निर्भर कामों के लिए बेस्ट - जैसे गहरी रिसर्च जहाँ हर कदम पिछली खोज पर बनता है।

दोनों में से किसे चुनना है, यह कैपेबिलिटी का सवाल नहीं - कॉन्टेक्स्ट की ज़रूरत का सवाल है। अगर सब-टास्क अपने आप में पूरा है, तो Communicating इस्तेमाल करो। अगर उसे पूरी तस्वीर चाहिए, तो Shared Memory। इसमें गलती का मतलब है - या तो बेवजह टोकन बर्बाद होंगे, या एजेंट को ज़रूरी जानकारी ही नहीं मिलेगी।

## Tool Overload रोकने के लिए तीन-लेयर एक्शन स्पेस

बहुत ज़्यादा टूल्स मॉडल को कन्फ़्यूज़ करते हैं। Manus का जवाब है एक लेयर्ड आर्किटेक्चर जो किसी भी वक्त मॉडल को सीमित चीज़ें दिखाता है:

**Atomic Layer** - 10 से 20 कोर कैपेबिलिटीज़: read, write, shell, browser। ये हमेशा उपलब्ध रहती हैं और मॉडल इन्हें सीधे इस्तेमाल करता है।

**Sandbox Utilities** - प्री-इंस्टॉल्ड CLI टूल्स जैसे कन्वर्टर्स, लिंटर्स, और फ़ॉर्मेटर्स। मॉडल इन्हें शेल के ज़रिए चलाता है, अलग डेडिकेटेड टूल की तरह नहीं।

**Packages और APIs** - प्री-ऑथेंटिकेटेड API कीज़ वाली Python स्क्रिप्ट्स। ये बाहरी सर्विसेज़ से इंटरैक्शन सँभालती हैं बिना पूरी API सरफ़ेस मॉडल के सामने रखे।

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

## इवैल्यूएशन मेट्रिक्स पर नई सोच

GAIA जैसे पब्लिक बेंचमार्क्स असली यूज़र प्रेफ़रेंसेज़ को नहीं दर्शाते। Manus का रुख साफ़ है: **गोल्ड स्टैंडर्ड है पूरे हुए सेशंस पर यूज़र रेटिंग**, 1 से 5 के स्केल पर।

तीन इवैल्यूएशन सिद्धांत सामने आए:

1. **Q&A टेस्ट नहीं, एक्ज़ीक्यूशन टेस्ट** - क्या एजेंट सैंडबॉक्स में टास्क पूरा कर सकता है? यह इससे ज़्यादा मायने रखता है कि वो टास्क के बारे में सवालों का जवाब दे सके।
2. **सब्जेक्टिव क्वालिटी के लिए इंसानी रिव्यू ज़रूरी** - विज़ुअल पॉलिश, टोन, और ओवरऑल कोहेरेंस को ऑटोमैटिकली स्कोर नहीं किया जा सकता। किसी इंसान को आउटपुट देखना होगा।
3. **बेंचमार्क स्कोर ज़रूरी हैं पर काफ़ी नहीं** - ये बेसलाइन कैपेबिलिटी साबित करते हैं। ये यह साबित नहीं करते कि प्रोडक्ट अच्छा है।

## सबसे बड़ी सीख

ओवर-इंजीनियरिंग दुश्मन है।

सबसे बड़ा परफॉर्मेंस सुधार जटिलता जोड़ने से नहीं आता - उसे हटाने से आता है। मॉडल का काम मुश्किल मत बनाओ। उसे आसान बनाओ।

शायद यही वजह है कि Meta ने Manus के लिए $300 मिलियन दिए। चमक-दमक वाले फ़ीचर्स के लिए नहीं, बल्कि एक डिज़ाइन फ़िलॉसफ़ी के लिए जो बुनियादी बातों पर केंद्रित है। जो ज़रूरी नहीं उसे हटाना, कॉन्टेक्स्ट को बेरहमी से मैनेज करना, और ऐसे सिस्टम बनाना जहाँ मॉडल टास्क पर फ़ोकस कर सके - अपनी ही स्टेट में डूबने की बजाय।

प्रोडक्शन में काम करने वाले एजेंट वो नहीं हैं जिनमें सबसे ज़्यादा कैपेबिलिटीज़ हैं। वो हैं जो हर कैपेबिलिटी का पूरा फ़ायदा उठाते हैं।

## Related URLs

- Author: https://tonylee.im/en/author/
- Publication: https://tonylee.im/en/blog/about/
- Related article: https://tonylee.im/hi/blog/eight-hooks-that-guarantee-ai-agent-reliability/
- Related article: https://tonylee.im/hi/blog/medvi-two-person-430m-ai-compressed-funnel/
- Related article: https://tonylee.im/hi/blog/claude-code-layers-over-tools-2026/

## Citation

- Author: Tony Lee
- Site: tonylee.im
- Canonical URL: https://tonylee.im/hi/blog/manus-meta-300m-agent-development-principles/

## Bot Guidance

- This file is intended for AI agents, search assistants, and text-mode retrieval.
- Prefer citing the canonical article URL instead of this text endpoint.
- Use the rollout alternates when you need the same article in another prioritized language.

---

Author: Tony Lee | Website: https://tonylee.im
For more articles, visit: https://tonylee.im/hi/blog/
This content is original and authored by Tony Lee. Please attribute when quoting or referencing.