"State management और flow control साफ़-सुथरे हो जाएंगे" इसी उम्मीद से LangGraph अपनाया था, लेकिन उल्टा code और जटिल हो गया।
Framework अपनाने के बाद भी structure खराब हो सकता है—इसे खुद अनुभव करने और整理 करने का यह रिकॉर्ड और साझा अनुभव है।
जांच करने पर स्थिति कुछ ऐसी थी:
- Graph में सिर्फ एक node था। current_step → END structure था, इसलिए न conditional edge था, न branching, और graph.invoke() सीधे function call करने जैसा ही था। Step transition का फैसला graph के बाहर service code कर रहा था।
- वही state दो जगह store हो रही थी। LangGraph MemorySaver (in-memory) और अपना PostgreSQL Checkpointer एक ही session को दोहरा store/restore कर रहे थे, जिससे inconsistency पैदा हुई।
- करीब 8,700 lines वाले 3 LangGraph execution codes (Executor) में duplication था। असल core logic बस "LLM call + prompt assembly" जितना था, और बाकी ज़्यादातर state management, conditional branching, और edge-case patches थे।
ऊपरी तौर पर समस्या यह थी कि framework की असली capabilities (conditional edges, built-in checkpointer, Human-in-the-Loop) का उपयोग किए बिना उसे सिर्फ shell की तरह अपनाया गया था। लेकिन और गहराई से देखने पर असली कारण अलग निकला।
- ज़्यादातर vibe coding से बनाया गया था, लेकिन बनाने की प्रक्रिया में internal code या design principles को गहराई से देखे बिना, हर बार सिर्फ requirements और intent整理 करके implementation आगे बढ़ाया गया।
- समस्या vibe coding खुद नहीं थी, बल्कि बिना validation के आगे बढ़ना था। यह सामने दिख रही functionality को ही optimize करता है, पूरी structure की responsibility boundaries को सुरक्षित नहीं रखता। Double checkpointing, बिखरी हुई state, और duplicated logic—सब partial optimization के जमा होते परिणाम थे।
- ऐसा नहीं था कि designer नहीं था; असली कारण यह था कि framework को किन चीज़ों की responsibility लेने के लिए design किया गया है, इसे पर्याप्त समझे बिना उसके ऊपर सिर्फ निर्देश दिए जा रहे थे।
इसलिए आत्ममंथन किया और इसे इस तरह वापस सुधारा।
- Independent topology + thread_id isolation से session separation
- State में सिर्फ metadata रखा और body को Store में move किया
- regex parsing के बजाय native tool_use का इस्तेमाल
- Testing possible हो, इसके लिए nodes अलग किए
- Framework की सही समझ और उपयोग structure की जरूरत मुझे खुद थी
यह "कैसे इस्तेमाल करें" नहीं, बल्कि "कैसे गलत इस्तेमाल किया" इसका रिकॉर्ड/साझा अनुभव है।
2 टिप्पणियां
लगता है कि जिन सभी मामलों में langchain langgraph इस्तेमाल होता है, उन्हें AI SDK से बदला जा सकता है
हाँ, सही बात है। मैं सहमत हूँ। SDK dependency तो आ ही जाएगी, लेकिन learning curve ज़्यादा है, इसलिए शायद वही बेहतर होगा।