تصور کنید هر گفتگوی شما با هوش مصنوعی، بهجای یک خط مستقیم، شبیه به یک درخت باشد که هر لحظه میتوانید از آن شاخههای جدیدی بزنید. اگر هنوز برای مقایسه دو مدل مختلف، متنها را بین تبهای مرورگر کپی-پیست میکنید، باید بدانید که دوران مدیریت دستی تاریخچه گفتگوها به پایان رسیده است. این روش دستی نه تنها غیرقابل بازتولید است و نه تاریخچهی نسخهها را حفظ میکند.
پروژهی Branch Agent در ۲۸ ژوئن ۲۰۲۶ بهعنوان یک پیادهسازی مرجع منتشر شد تا فلسفهی «رفتار با گفتگوهای مدل زبانی بزرگ (LLM) بهمثابهی یک درخت» را عملی کند. مدل زبانی بزرگ (LLM) — مثل کتابخانهداری که میلیاردها صفحه را خوانده و حالا با همان لحن کتابها جواب میدهد — در این سامانه بهگونهای مدیریت میشود که توسعهدهندگان بتوانند دقیقاً مشابه کدهای نرمافزاری، چتها را فورک (Fork) کرده و در نهایت ادغام کنند. این سازوکار اجازه میدهد چندین مدل، پرامپت سیستمی (System Prompt) و ارائهدهنده را بهصورت موازی و بدون تکرار تاریخچه گفتگو آزمایش کنید.
بسیاری از کاربران فعلاً با تغییر دستی پرامپت و اجرای مجدد چت، آزمایشهای خود را انجام میدهند. همانطور که در تحلیل قبلی ما دربارهی بهینهسازی مدلهای محلی در پوشش FastFlowLM اشاره کردیم، نیاز به ردیابی دقیق آزمایشها یک ضرورت است و Branch Agent این آشفتگی را با یک معماری رسمی شاخهبندی جایگزین کرده است تا روند تجربه کردن مدلها از حالت دستی به یک فرآیند ساختارمند تبدیل شود. این رویکرد مدیریت مدلها، بهویژه زمانی که با زیرساختهای مقیاسپذیر سروکار داریم، اهمیت بیشتری مییابد؛ برای مثال، مدیریت استقرار مدلهایی مانند Qwen2.5 روی کلاسترهای کوبرنتیز گام اولی برای ایجاد محیطهای تست پایدار در مقایس با مدلهای محلی است.
معماری فنی
به نقل از راهنمای فنی dev.to، این سامانه بر پایه یک پشتهی تخصصی برای انعطافپذیری و واکنشگرایی بالا بنا شده است. اجزای اصلی این پشته عبارتند از:
- Convex: یک پایگاهداده بکاند که تغییرات ACID و کوئریهای واکنشی را از طریق WebSockets فراهم میکند. این ابزار تضمین میکند رابط کاربری همزمان با استریم شدن توکنها (Token) — تکههای کوچکی از متن شبیه برشهای یک کیک طولانی — بهروز شود. در این سیستم، برای تابع
chatWithAgentاز اکشنهای قطعی (Deterministic Actions) استفاده میشود که خارج از تراکنشهای سنتی اجرا شده اما بهطور ایمن کوئریهای داخلی را فراخوانی میکنند. - Agno (Python SDK): یک چارچوب عاملمحور پایتونی که برای هر درخواست یک عامل (Agent) تازه میسازد تا از نشت وضعیت (State Leakage) بین شاخههای مختلف جلوگیری کند. این SDK از خروجیهای ساختاریافته بر اساس طرحوارههای Pydantic و پاسخهای استریم شده همراه با رویدادهای میانی (مانند مراحل استدلال یا فراخوانی ابزارها) پشتیبانی میکند.
- Next.js 15 & React 19: لایه فرانتاند که با استفاده از App Router و Server Components، تجربه کاربری و نمایشهای مقایسهای دوپانه (Side-by-side) را مدیریت میکند.
- Tailwind CSS v4 + shadcn/ui: لایه استایلدهی که با رویکرد Utility-first، پشتیبانی داخلی از حالت تاریک (Dark Mode) را فراهم میآورد.
سازوکار فورک با پیچیدگی O(1)
بر اساس مستندات convex/schema.ts در این پروژه، برخلاف لاگهای سنتی چت که کل تاریخچه را کپی میکنند، Branch Agent از یک طرحواره رابطهای استفاده میکند. هر شاخه حاوی یک snapshotMessageId است که دقیقاً به پیامی اشاره میکند که فورک از آن نقطه آغاز شده است.
از آنجا که سامانه تنها یک اشارهگر به شاخه والد (parentBranchId) و نقطه اسنپشات ذخیره میکند، عملیات فورک کردن از نظر فضای ذخیرهسازی دارای پیچیدگی O(1) است. در واقع، جهش forkBranch صرفاً یک ورودی جدید در جدول شاخهها با ارجاعات والد و اسنپشات ایجاد میکند و هیچ پیامی تکرار نمیشود.
برای بازسازی تاریخچه یک چت، کوئری internalGetBranchHistory بهصورت بازگشتی از طریق اشارهگرهای والد و اسنپشات به عقب حرکت میکند. این کوئری ابتدا پیامهای خاص همان شاخه را میگیرد و سپس تابع traverseToSnapshot را فراخوانی میکند تا زمینه اجدادی (Ancestral Context) را به ابتدای تاریخچه اضافه کند.
پیکربندیهای اختصاصی هر شاخه
هر خط زمانی موازی میتواند هویت مجزایی داشته باشد. طبق معماری agentConfigSchema در این ابزار، هر شاخه پارامترهای خاص خود را تعریف میکند تا آزمایشها بهطور کامل ایزوله شوند:
- مدل و ارائهدهنده: امکان استفاده از ارائهدهندگان مختلف LLM (مانند OpenAI، Together، Groq یا Ollama) از طریق URLهای پایه و کلیدهای API اختصاصی.
- تنظیمات رفتاری: تعریف پرامپت سیستمی سفارشی، تنظیم temperature (دما) برای کنترل خلاقیت و محدودیت maxTokens.
- یکپارچهسازی قابلیتها: ابزارهای یکپارچه شدهای مانند جستوجوی وب، ماشینحساب و سیستم ورودی/خروجی فایل.
این ساختار اجازه میدهد مثلاً یک شاخه را با GPT-4o و شاخه فورکشده را با لاما (Llama) و یک پرامپت سیستمی متفاوت اجرا کنید تا بهطور دقیق مقایسه کنید که معماریهای مختلف چگونه با یک تاریخچه یکسان برخورد میکنند.
عامل داور و فرآیند ادغام
وقتی کاربر مسیر برتر یا پاسخ بهتری را در یک شاخه فورکشده مییابد، میتواند آن را به خط زمانی اصلی برگرداند. این فرآیند توسط اکشن mergeWithJudge مدیریت میشود. سامانه تاریخچه هر دو شاخه را به یک عامل Agno میفرستد که در نقش «داور» عمل میکند و دستورالعمل خاصی را دریافت میکند: «شما یک داور ادغام هستید. یادگیریهای کلیدی، تفاوتها و بینشهای شاخه منبع (SOURCE) را خلاصه کرده و یک گزارش ادغام موجز تهیه کنید.»
این خلاصه نهایی بهعنوان یک پیام سیستمی در شاخه هدف درج میشود و شاخه منبع با وضعیت isMerged: true علامتگذاری شده و گزارش ادغام (mergeSummary) در پایگاهداده ذخیره میگردد.
جریان استریم در لحظه
رابط کاربری بهرغم پیچیدگیهای زیرساختی، کاملاً روان است. هنگامی که پیامی ارسال میشود، اکشن Convex تاریخچه بازسازیشده کامل را دریافت کرده و آن را از طریق یک درخواست HTTP POST به مسیر /chat (در قالب استریم SSE) به سرویس پایتون Agno میفرستد.
سرویس Agno با استفاده از تابع create_agent مدل و ابزارها را بر اساس پیکربندی خاص آن شاخه تعیین میکند. همانطور که عامل پاسخ را تولید میکند، توکنها را از طریق Server-Sent Events (SSE) بازمیگرداند.
از آنجا که سند Convex در هر دلتای توکن توسط جهش internalUpdateMessageStream بهروزرسانی میشود، هوک واکنشی useQuery در فرانتاند باعث رندر مجدد فوری میشود. این سازوکار تضمین میکند که پاسخها بهطور نرم در رابط کاربری استریم شوند، بدون اینکه نیاز به بازخوانی دستی (Polling) باشد.
ابزارهای مقایسه و توسعه
رابط کاربری شامل کامپوننت CompareView است که اجازه میدهد دو شاخه را همزمان مشاهده کنید. پانلها بهطور مستقل اسکرول میشوند و پیامهای حاصل از تاریخچههای فورکشده با نام شاخه منبع برچسب میخورند. این قابلیت برای A/B تست کردن پرامپتهای سیستمی روی یک زمینه (Context) یکسان حیاتی است.
برای توسعه محلی، این پروژه به سه ترمینال نیاز دارد: یکی برای بکاند Convex (npx convex dev)، یکی برای سرویس پایتون Agno و یکی برای فرانتاند Next.js. البته میتوان تمام اینها را با یک دستور واحد ./start.sh اجرا کرد.
این معماری پیشفرض «آزمون و خطای خطی» در مهندسی پرامپت را تغییر میدهد. با انتقال به مدل شاخهای، مهندسی پرامپت (Prompt Engineering) — هنر سؤال درست پرسیدن برای گرفتن بهترین جواب — به یک آزمایش ساختارمند تبدیل میشود که در آن «بهترین» نسخه گفتگو از طریق مقایسه تجربی انتخاب میشود، نه بر اساس حافظه کاربر.
برای توسعهدهندگان، این به معنای توانایی A/B تست عملکرد مدل روی یک پنجره متنی (Context Window) — میزان متنی که مدل همزمان در ذهن نگه میدارد — دقیق و یکسان، بدون ریسک تغییر زمینه (Context Drift) است. تمرکز اکنون از «پیدا کردن پرامپت درست» به «مدیریت سبدی از استراتژیهای پرامپتنویسی» تغییر یافته است.
توسعهدهندگانی که علاقهمند به این رویکرد هستند، میتوانند پیادهسازی کامل را در dailybuild.xyz بررسی کنند تا لایه نسخهبندی خود را برای گردشکارهای عاملمحور پیاده کنند.
گام بعدی شما
- بررسی مستندات Agno برای یادگیری نحوه ایجاد عاملهای ایزوله در هر درخواست.
- آزمایش مدلهای بازمتن در کنار مدلهای بسته با استفاده از ساختار فورک Branch Agent برای مقایسه هزینه و کیفیت.
- پیادهسازی یک عامل «داور» برای خودکارسازی فرآیند انتخاب بهترین پاسخ بین چندین مدل.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو