Haystack

این پروژه مهم است چون یک مسیر رسمی و نسبتاً روشن برای ساخت agentهای عملی می‌دهد. primitiveهای اصلی مثل agent، tool، handoff، session و guardrail در یک مدل واحد کنار هم دیده می‌شوند و این کار فهم جریان اجرا را برای تیم‌ها ساده‌تر می‌کند.

برای کسی که می‌خواهد از ایده به نمونه‌ی قابل‌استفاده برسد، شفاف بودن همین لایه‌ها کمک می‌کند تصمیم‌ها سریع‌تر گرفته شوند و از پراکندگی ابزارها کمتر شود.

کاربردهای رایج

• اپلیکیشن‌های retrieval-augmented
• توسعه اپلیکیشن‌های LLM
• ارکستریشن workflow
• ایجنت‌های ابزارمحور

مخاطب مناسب

• مهندسان هوش مصنوعی
• سازندگان اپلیکیشن‌های LLM
• تیم‌های فنی پیشرفته

بهترین شروع این است که اول مستندات رسمی را بخوانی و بعد مخزن کد را برای نمونه‌ها و API بررسی کنی. اگر فقط یک قدم می‌خواهی، با مستندات رسمی شروع کن.

Haystack در اسناد رسمی به‌عنوان یک AI framework و orchestration framework برای agentها، RAG و search systemها معرفی می‌شود، اما در این تحلیل تمرکز آموزشی آن بیشتر روی componentها، pipelineها، document storeها و workflowهای retrieval/document processing نگه داشته شده است. الگوی پایه آن به توسعه‌دهنده اجازه می‌دهد indexing pipeline، query pipeline یا flowهای چندمرحله‌ای retrieval-augmented را با componentهای قابل‌تعویض ترکیب کند.

معماری Haystack بر پایه component و pipeline ساخته می‌شود. componentها building blockهایی هستند که کارهایی مثل preprocessing، retrieval، ranking، generation یا document writing را انجام می‌دهند، و pipelineها directed multigraphهایی هستند که این componentها را با branch، loop، router و connectionهای explicit به هم متصل می‌کنند. document storeها و retrieverها نقش مهمی در سیستم‌های knowledge-backed آن دارند.

مستندات رسمی Haystack از Agent component و Agent page برای tool-calling loop پشتیبانی می‌کنند. این loop می‌تواند با chat-based LLM، tools، state_schema و exit conditionها اجرا شود. با این حال، در positioning این تحلیل، agent loop یک قابلیت ثانویه در کنار retrieval/search pipelineها دیده می‌شود، نه هویت اصلی کل project.

Haystack برای tool use پوشش رسمی دارد: Tool، @tool، ComponentTool، PipelineTool، MCPTool و Toolsetها به توسعه‌دهنده اجازه می‌دهند actionها یا componentهای بیرونی را به flowهای agentic یا retrieval-aware وارد کند. به همین دلیل tool calling در Haystack بیشتر به pipeline/component composition مربوط است تا یک SDK primitive isolated.

RAG و retrieval در Haystack جایگاه مرکزی دارد. docs رسمی به indexing pipelineها، query pipelineها، document storeها، retrieverها و componentهای مربوط به generation اشاره می‌کنند. در عین حال، این تحلیل آگاهانه Haystack را فقط به یک buzzword به نام RAG تقلیل نمی‌دهد، چون بخش مهمی از ارزش آموزشی آن در document processing، search-backed context و pipeline design نهفته است.

در docs رسمی Agents و Agent component، Haystack از patternهای agentic و حتی multi-agent systemها پشتیبانی می‌کند؛ مثل wrapper کردن Agent به‌عنوان ComponentTool برای coordinator/specialist architecture. بااین‌حال، این تحلیل از تبدیل این قابلیت به هویت اصلی پروژه پرهیز می‌کند، چون flowهای retrieval/document-pipeline هنوز محور آموزشی روشن‌تری برای Haystack هستند.

مدل orchestration در Haystack pipeline-based است. pipelineها directed multigraphهای flexible هستند که loops، branchها، ConditionalRouter، AsyncPipeline و validation در حین connect دارند. اما نسبت به projectهای orchestration-first مانند LangGraph، Haystack بیشتر به composition pipelineهای retrieval، search و LLM applicationها گرایش دارد تا یک state/runtime identity خاص و standalone.

نقاط قوت

• مدل component/pipeline آن برای ساخت workflowهای بازیابی‌محور و document-backed روشن و قابل‌تفکیک است.
• اسناد رسمی از indexing pipeline، query pipeline، branch، loop و routing به‌عنوان بخش‌های واقعی معماری پشتیبانی می‌کنند.
• document storeها، retrieverها و componentهای مرتبط به search/RAG در positioning رسمی پروژه جایگاه مشخصی دارند.
• agent support در docs رسمی وجود دارد، اما می‌توان آن را در کنار retrieval workflows خواند بدون اینکه کل پروژه فقط به agent runtime تقلیل یابد.

محدودیت‌ها

• پوشش همزمانِ agent، RAG، search و pipeline ممکن است برای خواننده تازه‌کار مرز مفهومی پروژه را مبهم‌تر کند.
• انعطاف pipeline به‌تنهایی جایگزین تصمیم‌گیری معماری درباره document store، retriever، evaluation یا deployment پیرامونی نیست.
• چون docs رسمی هم از language مربوط به orchestration استفاده می‌کنند، مقایسه با LangGraph یا LangChain باید role-aware بماند تا هم‌نقشی کاذب ساخته نشود.
• وجود agent support نباید به‌اشتباه به‌عنوان evidence برای runtime-first بودن یا جایگزینی SDKهای agent-oriented خوانده شود.