किसी भी काम को कर सकने वाले एक हार्नेस की ओर
डेवलपर्स इस पर बहस कर रहे हैं कि बड़े भाषा मॉडलों को सबसे बेहतर ढंग से “हार्नेस” कैसे किया जाए: क्या प्रस्तावित Ambiance सिस्टम जैसे generic, Unix-शैली के, file-centric frameworks के माध्यम से, या फिर किसी LLM के चारों ओर टूल्स और tests को सख्ती से सीमित domain-specific orchestrators के जरिए। एक बार-बार उभरता विषय है जितना संभव हो काम को deterministic code और scripts में धकेलना—और LLMs का उपयोग केवल judgment calls और edge cases के लिए करना—साथ ही token costs, reliability, auditability, और platform constraints जैसी व्यावहारिक समस्याओं से जूझना। कई लोग भविष्य के AI workflows को composable Unix tools या OS-level services जैसा देखते हैं, जहाँ LLMs lightly embedded हों, न कि autonomous, free-roaming agents की तरह।
“हार्नेस” क्या है और लोग इसकी परवाह क्यों करते हैं
- हार्नेस को LLM और टूल्स के बीच की गोंद के रूप में बताया गया है: यह टूल कॉल्स को पार्स करता है, कमांड्स चलाता है (FS, नेटवर्क, आदि), और परिणाम वापस मॉडल को देता है।
- कुछ लोग इसे एक “एजेंटिक एक्सोस्केलेटन” या एक धुंधले मॉडल के चारों ओर एक निर्धारक ढांचा मानते हैं।
- दूसरे इस शब्दावली को buzzword-y कहकर मज़ाक उड़ाते हैं, लेकिन मूल आवश्यकता से सहमत हैं: LLM के व्यवहार को सीमित और संरचित करना।
निर्धारक वर्कफ़्लो बनाम “शुद्ध” एजेंट
- निर्धारकता के पक्ष में एक मजबूत धारा है: दोहराए जा सकने वाले वर्कफ़्लोज़ के लिए असली कोड और स्क्रिप्ट्स का उपयोग करें; LLMs को केवल निर्णय/एज केस के लिए बुलाएँ।
- जिन पैटर्न्स का उल्लेख हुआ: निर्णय वृक्ष, जिनकी अधिकांश पत्तियाँ “स्क्रिप्ट चलाएँ” होती हैं, और कुछ “LLM से पूछें”; कोड+टेस्ट्स ढांचा हैं, LLM कभी-कभार सहायक।
- लोग Claude Code/Codex जैसे टूल्स को बाहरी निर्धारक लूप्स (टेस्ट्स, git, सुरक्षा जाँच, pre-commit hooks) में लपेटने की बात करते हैं।
- कुछ फ्रेमवर्क्स (langgraph, ACP, आदि) को इन लूप्स को orchestrate करने के लिए अच्छा बताया गया, हालांकि कुछ लोगों को वे सिस्टम पसंद नहीं आए जो “agent-building” को किसी रस्म जैसा बना देते हैं।
Unix दर्शन, “everything is a file,” और विकल्प
- कई लोगों को एजेंट कॉन्सेप्ट्स को Unix प्रिमिटिव्स से जोड़ना पसंद है: event-driven workflows, साझा स्थिति के रूप में FS, FUSE, और permissions तथा mail के साथ “Linux user के रूप में agent”।
- अन्य लोग LLMs के लिए “everything is a file” को अस्वीकार करते हैं, यह तर्क देते हुए कि मॉडलों के लिए “everything is tokens/embeddings” है और vector DBs या typed JSON अधिक स्वाभाविक हैं।
- कुछ लोगों के लिए files एक व्यावहारिक local minimum हैं: मनुष्यों और मॉडलों दोनों के लिए अच्छे; अन्य FHS को पुराना मानते हैं और Nix/Plan 9 जैसी अवधारणाओं का सुझाव देते हैं।
सामान्य बनाम domain-specific harnesses
- कई लोग तर्क देते हैं कि domain-specific harnesses (जैसे software engineering के लिए) पहले से ही generic harnesses से बेहतर हैं: built-in ADRs, planning, behavioral tests, सख्त gating।
- LLMs को “raw” चलाना बिना brakes के ड्राइव करने जैसा बताया गया; दूसरे लोग बताते हैं कि उन्होंने जटिल harnesses छोड़कर सरल CLIs पर वापसी कर ली क्योंकि अतिरिक्त जटिलता से मदद नहीं मिली।
लागत, tokens, और व्यावहारिकता
- FS-watching या बार-बार polling के token costs को लेकर चिंता; सुझाव कि केवल महत्वपूर्ण file thresholds पर trigger किया जाए।
- कुछ लोग tests, logging, और minimal, non-overengineered scripts पर ज़ोर देते हैं; overgeneralization को maintenance trap माना गया।
Ambiance की प्रतिक्रिया और “do anything” दावा
- सकारात्मक: Unix-native mental model, lean/auditable दृष्टिकोण, और इसके ऊपर variants बनाने के लिए एक अच्छा kernel।
- आलोचनाएँ: “soft” ideas, मौजूदा sandboxes की तुलना में concrete gains को लेकर अस्पष्टता; macOS-only support कुछ लोगों को खटकती है; “can do anything” branding को बढ़ा-चढ़ाकर किया गया दावा माना गया।