সারাটা দিন LangChainGo নিয়ে মাথা ঠুকেও যখন দেখলাম লোকাল মডেলগুলো ঠিকমতো Tool Call করতে পারছে না, তখন হাল ছেড়ে দিয়েছিলাম। মডেল আউটপুট দিচ্ছিল "Action: web_search", কিন্তু প্রয়োজনীয় "Action Input" দিতে ভুলে যাচ্ছিল। এই ধরনের ফ্রেমওয়ার্কগুলো সাধারণত নির্দিষ্ট কিছু প্যাটার্ন ফলো করে, যা লোকাল মডেলের জন্য বেশ কঠিন হয়ে দাঁড়ায়। তখনই মনে হলো, এই জটিলতায় না গিয়ে সরাসরি Go ব্যবহার করে Multi-Agent Orchestration করা অনেক বেশি কার্যকর।
ফিক্সটা আসলে Prompt Tuning-এ ছিল না, ছিল পুরো ফ্রেমওয়ার্কটাই বাদ দেওয়াতে। সরাসরি LLM Call আর Structured Data পাস করার মাধ্যমে আমি অনেক বেশি কন্ট্রোল পেয়েছি।
অযথা জটিলতা বাদ দিন
একই Agent দিয়ে Lawyer, Accountant আর Chef—সব কাজ করানোর চেষ্টা করা মানেই সবগুলোতে গড়পড়তা রেজাল্ট পাওয়া। এর চেয়ে Specialist Agentদের ভাগ করে দিলে Promptগুলো আরও পরিষ্কার হয় এবং Parallelize করা সহজ হয়। আমি প্রথমে Supervisor Pattern ট্রাই করেছিলাম, কিন্তু ছোট প্রজেক্টে সেটা অযথাই জটিলতা বাড়ায়। আমার অভিজ্ঞতায় Pipeline Pattern (Researcher → Writer → Editor) সবচেয়ে সহজে কাজ করে।
LangChainGo-র মতো ফ্রেমওয়ার্কে একটা বড় সমস্যা হলো এরা মডেল থেকে একদম নিখুঁত ফরম্যাট আশা করে:
Thought: I need to search for this Action: web_search Action Input: AI impact on software engineeringThought: I need to search for this Action: web_search Action Input: AI impact on software engineering
লোকাল মডেলগুলো প্রায়ই এই ফরম্যাটটা উল্টাপাল্টা করে ফেলে। সরাসরি LLM Call করলে এই সমস্যা থাকে না। আপনি আপনার মতো করে Tool Invoke করতে পারেন এবং রেজাল্ট পাস করতে পারেন। এতে কোড সিম্পল হয়, Debugging-ও অনেক সহজ হয়ে যায়।
কোড স্ট্রাকচার
নিচে আমার প্রজেক্টের একটা বেসিক স্ট্রাকচার দেওয়া হলো যেখানে একটা BaseAgent ব্যবহার করে বাকি Agentগুলো তৈরি করা হয়েছে:
2-multi-agent-pipeline/ ├── main.go ├── internal/ │ ├── agents/ │ │ ├── base.go # Shared LLM Calling Logic │ │ ├── simple_researcher.go # Research Agent │ │ ├── writer.go # Writer Agent │ │ ├── editor.go # Editor Agent │ │ ├── errors.go # Structured Error Types │ │ ├── options.go # Configuration Options │ │ └── pipeline.go # Pipeline Runner Abstraction │ └── tools/ │ └── search.go # Brave Search Tool ├── go.mod └── go.sum2-multi-agent-pipeline/ ├── main.go ├── internal/ │ ├── agents/ │ │ ├── base.go # Shared LLM Calling Logic │ │ ├── simple_researcher.go # Research Agent │ │ ├── writer.go # Writer Agent │ │ ├── editor.go # Editor Agent │ │ ├── errors.go # Structured Error Types │ │ ├── options.go # Configuration Options │ │ └── pipeline.go # Pipeline Runner Abstraction │ └── tools/ │ └── search.go # Brave Search Tool ├── go.mod └── go.sum
Base Agent: মূল ভিত্তি
সব Agent-ই BaseAgent স্ট্রাক্ট শেয়ার করে, যা কমন LLM Interaction Logic হ্যান্ডেল করে। এতে কোড ডুপ্লিকেশন কমে এবং Streaming বা Retry করার সুবিধা পাওয়া যায়।
// (Code remains same as original)// (Code remains same as original)
এরর হ্যান্ডলিং: যেখানে আমি ভুল করেছিলাম
আমি শুরুতে Error Handling ঠিকমতো না করার কারণে কোন Agent কেন ফেইল করছে তা বুঝতে পারতাম না। পরে Structured Error Type ব্যবহার করে Debugging অনেক সহজ হয়েছে।
package agents import ( "errors" "fmt" ) // (Remaining error handling code)package agents import ( "errors" "fmt" ) // (Remaining error handling code)
কেন Multi-Agent Orchestration এত সময় সাপেক্ষ?
মাল্টি-এজেন্ট সিস্টেমের সবচেয়ে বড় সমস্যা হলো Latency। একটা Prompt থেকে আউটপুট এসে সেটা পরের Agent-এ যেতে যে সময় লাগে, তাতে পুরো প্রসেসটা অনেক স্লো হয়ে যায়। বিশেষ করে যদি আপনি বড় কোনো LLM ব্যবহার করেন। এছাড়া Token Cost-এর ব্যাপারটা তো আছেই। প্রতিটি Agent তার নিজের Prompt আর History নিয়ে কাজ করে, যা দ্রুত বিল বাড়িয়ে দিতে পারে।
আরও একটা বিরক্তিকর বিষয় হলো Context Bleed। আগের Agent-এর ভুল বা অপ্রাসঙ্গিক তথ্য পরের Agent-এ চলে গেলে আউটপুট একদম নষ্ট হয়ে যায়। এটা এড়াতে Explicit Handoff খুব জরুরি।
মডেল বাছাই করার কৌশল
সব কাজের জন্য একই মডেল ব্যবহারের কোনো মানে হয় না। Research-এর জন্য হয়তো Fast কোনো মডেল (যেমন Qwen বা Llama) ভালো কাজ করে, কিন্তু Writing-এর ক্ষেত্রে Claude বা GPT-4-এর কোনো বিকল্প নেই। আমি সাধারণত Editing-এর জন্য Mid-tier মডেল ব্যবহার করি অথবা যদি Writer ভালো আউটপুট দেয়, তবে Editor Skip করি।
Multi-Agent Orchestration নিয়ে কাজ করার সময় সবসময় ২-Agent Pipeline দিয়ে শুরু করা ভালো। এরপর প্রয়োজন অনুযায়ী জটিলতা বাড়ানো উচিত।
Go Language ব্যবহার করে কীভাবে দক্ষ Multi-Agent Orchestration সিস্টেম তৈরি করবেন, ফ্রেমওয়ার্কের জটিলতা এড়িয়ে সরাসরি LLM Call করার সুবিধা ও কোডসহ বিস্তারিত জানুন!