Sarah Chieng (@milksandmatcha) और @0xSero द्वारा लिखित
एक पर्सनल असिस्टेंट का काम ही यही है कि वह आपका समय और मेहनत बचाए। पिछले कुछ हफ्तों से हम रोज़मर्रा के कामों में AI पर्सनल असिस्टेंट्स की लगातार परीक्षा ले रहे हैं — फ्लाइट बुक करने और कैलेंडर मैनेज करने से लेकर ग्रॉसरी खरीदने और मील प्लान करने तक।
जब भी कोई असिस्टेंट अपना काम खुद-ब-खुद निपटा देता है, तो हम आज भी हैरान रह जाते हैं। लेकिन जब वही असिस्टेंट डिनर रिज़र्वेशन में 7 मिनट से ज़्यादा लगा दे — जिसे हम खुद 37 सेकंड में कर सकते थे — तो सारा रोमांच ठंडा पड़ जाता है।
इसलिए हमने यह खोजना शुरू किया कि आखिर ये समय जाता कहाँ है। इस प्रयोग के लिए, हमने Cerebras पर चलने वाले Qwen 3.8 27B का इस्तेमाल करके एक टेस्ट असिस्टेंट तैयार किया, जिसमें Pi को एजेंट हार्नेस के रूप में इस्तेमाल किया गया। Cerebras पर तेज़ inference और बेहतर harness engineering की बदौलत, हमारे अपने असिस्टेंट ने यह काम सिर्फ 22 सेकंड में पूरा कर लिया, जो मौजूदा असिस्टेंट्स से 19 गुना तेज़ है। आइए देखते हैं कि हमने क्या बदलाव किए।
नए कंज्यूमर AI असिस्टेंट्स
OpenClaw ने भविष्य की एक झलक दिखाई थी, और अब कंज्यूमर AI असिस्टेंट्स की नई लहर आपके लिए ज़्यादातर सेटअप खुद संभाल लेती है, ताकि आप अंदरूनी सॉफ्टवेयर को कॉन्फ़िगर किए बिना सीधे काम सौंपना शुरू कर सकें।
हमारे रिसर्च नोट्स से लिए गए माइलस्टोन। Instinct की तारीख सार्वजनिक रूप से दिखी पोस्ट्स के आधार पर है, न कि किसी पुष्ट लॉन्च डेट के।
समय जाता कहाँ है
एक प्रयोग के तौर पर, हमने हर बड़े असिस्टेंट को परखा और उसी डिनर रिज़र्वेशन रिक्वेस्ट पर उनका बेंचमार्क तैयार किया:
एक ही रिक्वेस्ट ने हर असिस्टेंट को सर्च, चेक और ब्राउज़र एक्शन के अलग-अलग रास्तों पर भेजा। Meta Muse के रन में 4 मिनट 36 सेकंड लगे और इसमें OpenTable API की नौ डायरेक्ट कॉल्स शामिल थीं। Claude Cowork को 6 मिनट 25 सेकंड और 57 टूल कॉल्स लगीं। Grok Bot का रन 7 मिनट 40 सेकंड चला। हर असिस्टेंट ने A Mano, II Borgo या Doppio Zero में से किसी एक पर सही तरीके से रिज़र्वेशन किया।
ये रिकॉर्ड किए गए रन हैं, कोई आम रैंकिंग नहीं। 22 सेकंड का नतीजा दो सफल कोशिशों का मीडियन (median) है।
किसी भी agentic टास्क में बैकग्राउंड में बहुत कुछ चल रहा होता है। हार्नेस बातचीत को मैनेज करता है, टूल कॉल्स चलाता है, एरर संभालता है और नतीजे वापस मॉडल को भेजता है। यह समझने के लिए कि समय कहाँ खर्च हुआ, आइए देखें कि Grok Bot ने अपने पहले 2 मिनट कैसे बिताए। Grok Bot ने स्किल्स लोड करने, मेमोरी निकालने, सर्च करने, रेस्टोरेंट पेज चेक करने और रिपोर्ट देने से शुरुआत की। सिर्फ एक ब्राउज़र रन में 2 मिनट 18 सेकंड लग गए, क्योंकि उसने A Mano, Il Borgo और Doppio Zero को बारी-बारी से चेक किया।
उदाहरण के लिए, यहाँ हम Grok Bot के रन का विस्तृत ब्रेकडाउन देख सकते हैं।
मॉडल भी मायने रखते हैं। प्लानिंग, टूल यूज़ और लॉन्ग-हॉराइज़न रीज़निंग में हालिया तरक्की ने इन कामों को ज़्यादा व्यावहारिक बना दिया है। Opus 4.5 जनरेशन ने मजबूत एजेंट क्षमताओं को context compaction के साथ जोड़ा: जब कॉन्टेक्स्ट भर जाता है, तो काम का एक संक्षिप्त ब्यौरा आगे बढ़ाया जाता है। CompactionRL जैसी रिसर्च इससे भी आगे जाती है, जहाँ एजेंट्स को इन कंपैक्शन स्टेप्स के बीच काम करने के लिए ट्रेन किया जाता है।
और इन सबके नीचे, आपको फिर भी एक तेज़ मॉडल की ज़रूरत होती है जो लक्ष्य पर नज़र रखे, गलतियों से उबरे और लगातार जाँचता रहे कि काम सही दिशा में चल रहा है या नहीं।
हमने यह कैसे किया
हमने एजेंट हार्नेस के रूप में Pi का इस्तेमाल किया। इसके छोटे सिस्टम प्रॉम्प्ट और चार बिल्ट-इन टूल्स ने हमें एक आसान शुरुआत दी, जिसमें बुकिंग टास्क के लिए अपने टूल्स जोड़ने की पूरी जगह थी।
- स्वतंत्र विकल्पों को एक साथ (parallel में) चेक करें
रेस्टोरेंट की उपलब्धता चेक करने का काम parallel में होना चाहिए। हाँ, बुकिंग का स्टेप इस बात पर निर्भर करता है कि उन चेक्स से क्या नतीजा आता है। हमने इसे ऐसे बाँटा: पहले सभी स्वतंत्र चेक एक साथ चलाओ, फिर उनके नतीजों के आधार पर तय करो कि आगे क्या करना है।
स्किल ने उसे निर्देश दिया कि स्वतंत्र विकल्पों को parallel में चेक करे, ताकि वह एक चेक खत्म होने का इंतज़ार किए बिना कई रेस्टोरेंट्स के नतीजे एक साथ जुटा सके।
हमारे ऑप्टिमाइज़्ड रन का ब्राउज़र/API हिस्सा 6.8 सेकंड में पूरा हुआ, जबकि पहले वाले Grok ट्रेस में यही 4 मिनट 31 सेकंड था: यानी रिकॉर्ड की गई इन श्रेणियों में लगभग 40 गुना का फर्क। इस तुलना में मॉडल, हार्नेस और एग्ज़ीक्यूशन पाथ में हुए बदलाव एक साथ शामिल हैं; यह अकेले स्किल के असर को अलग करके नहीं दिखाती।
- बाकी मॉडल कॉल्स को तेज़ करें
हर बार जब असिस्टेंट मॉडल के पास वापस जाता है, तो उसे दूसरे रिस्पॉन्स का इंतज़ार करना पड़ता है। Cerebras पर तेज़ inference इन रुकावटों को छोटा कर देता है। हमारे ऑप्टिमाइज़्ड रन ने Qwen 3.8 27B का इस्तेमाल किया; वेबसाइट प्रोसीजर को पहले से सेव करने से मॉडल को रन के दौरान कम सोचना पड़ा।
कुछ स्टेप्स को अभी भी क्रम से ही होना पड़ता है। एजेंट को पेज का नतीजा मिले बिना वह तय नहीं कर सकता कि उसके साथ क्या करना है। तेज़ inference किसी धीमी वेबसाइट को पलक झपकते लोड नहीं कर सकता और न ही फोन-वेरिफिकेशन स्टेप को हटा सकता है, लेकिन यह देखने, फैसला करने और एक्शन लेने के बीच बार-बार आने वाली रुकावटों को ज़रूर कम कर सकता है।
- एजेंट जो सीखे, उसे सेव करें
ज़्यादातर बर्बाद मेहनत इसी में जाती है कि वेबसाइट कैसे काम करती है, यह पता लगाई जाए: एक टूल कॉल करो, पेज देखो, अगला कदम अनुमान लगाओ, दूसरा टूल कॉल करो। एजेंट इधर-उधर टटोलता है, देखता है कि क्या होता है, और फिर अपना काम जारी रखता है। अगली बार आने पर, वह यही खोजबीन का काम फिर से दोहरा सकता है।
असिस्टेंट चलाने से पहले, हमने एजेंट को ज़्यादा कॉन्टेक्स्ट दिया और अपनी सीख को एक स्किल में बदल दिया। इससे मॉडल को बुकिंग प्रोसेस को नेविगेट करने के निर्देश मिल गए, बिना हर स्टेप को खुद खोजे। हमारे टेस्ट में, इसने टूल कॉल्स को 80% से ज़्यादा कम कर दिया।
यहाँ असली फर्क इस बात का है कि क्या चीज़ दोबारा इस्तेमाल होती है। हम साइट को नेविगेट करने और रिज़र्वेशन चेक करने का तरीका सेव कर सकते हैं। लेकिन उपलब्धता, कीमतें और कार्ड की ज़रूरत है या नहीं — ये सब अभी भी लाइव चेक करना पड़ता है। रास्ता खोजने की मेहनत टाइम्ड रन से पहले हो जाती है; वह गायब नहीं होती।
एक तेज़ पर्सनल असिस्टेंट
इससे पहले कि यह हर काम इतनी अच्छी तरह संभालने लगे और हमारे पास असल ज़िंदगी का Jarvis आ जाए, अभी बहुत काम बाकी है। लेकिन ज़रा सोचिए, जब ये एजेंट्स जो पहले से ही जादुई लगते हैं, 10 गुना तेज़ हो जाएँगे तो क्या होगा।
खैर, अब चलता हूँ! हमें एक डिनर रिज़र्वेशन के लिए पहुँचना है।
डिज़ाइन: Halley Chang। Shintaro Matsui, Joyce Er और Alycia Cary को उनकी प्रतिक्रिया के लिए विशेष धन्यवाद।
