DeepSeek Super-Agent: چیست، چگونه کار می کند و چه چیزی هنوز وجود ندارد3 min read

سه عامل کد نویسی را همزمان باز کنید و می توانید مشکل را احساس کنید. یکی منتظر تصمیم است، یکی بیست دقیقه پیش تمام شده است، و شما قبلاً فراموش کرده اید که کدام یک دارای تصحیح auth است. تیم هارنس DeepSeek عددی را روی آن قرار داده است: در تجربه خود، فرد می تواند تنها سه تا پنج جلسه نماینده فعال را در یک زمان دنبال کند. گذشته از آن نقطه، مدل دیگر گلوگاه نیست. شما هستید.

در 31 اکتبر 2026، این تیم یک مقاله طراحی برای چیزی که Super-agent می نامد منتشر کرد و یک نمونه اولیه به نام dsh-superagent را منبع باز کرد. این یک عامل کدنویسی فعال برای یک مخزن GitHub است. یک جلسه روتر طولانی مدت با مردم صحبت می کند و کار را تحویل می دهد، و هر درخواست پذیرفته شده جلسه کارگر خود را دریافت می کند که به یک درخواست کشش یا یک سؤال ختم می شود. این مخزن در حدود دو روز از 12000 ستاره عبور کرد. README آن صریح است که این کد تحقیقاتی است و یک محصول رسمی DeepSeek نیست.

این راهنما برای مهندسان و رهبران تیم است که می‌خواهند بدانند نمونه اولیه چه کاری انجام می‌دهد، طراحی روتر و کارگر چگونه کار می‌کند، اعداد بنچمارک چه کار می‌کنند و چه چیزی را ثابت نمی‌کنند، و چه چیزی را قبل از نشان دادن آن به یک مخزن واقعی بررسی کنند.

یک نکته قبل از جزئیات پاسخ یک کارگر به “رفع این اشکال” یک درخواست کششی است و GitHub خانه خوبی برای آن است. قرار دادن بقیه چیزهایی که عوامل در اطراف کد تولید می کنند سخت تر است: نوشتن علت اصلی، خلاصه آزمایش، جدول مقایسه ای که یک بازبین درخواست کرده است.AgentGrid.ioیک فضای کاری مشترک است که در آن افراد و عوامل هوش مصنوعی اسناد، برنامه‌ها و فایل‌ها را با یک نسخه زنده، اسناد و سابقه ایجاد، ویرایش و به اشتراک می‌گذارند. ما به جایی برمی گردیم که نزدیک به انتهای آن جا می شود.

DeepSeek Super-Agent چیست؟

دو چیز با هم ظاهر شد. اولین مقاله یک مقاله طراحی طولانی است، “کاوش در طراحی ابر عامل: به سوی یک سیستم عامل مستقل تر”. تیم هارنس آن را به زبان چینی نوشت و نسخه انگلیسی آن را که به صورت ماشینی ترجمه شده بود در X در 1 نوامبر ارسال کرد. بیش از 2.2 میلیون بار دیده شده است. کد دوم:نمونه اولیه deepseek-ai/dsh-superagent، تحت مجوز MIT منتشر شد.

کاوش در طراحی ابر عامل: به سوی یک سیستم عامل مستقل تر

https://t.co/gwwIHtyCRQ

– مهار DeepSeek (@DeepSeekHarness)1 نوامبر 2026

مدل جدیدی نیست. dsh-superagent یک بسته نرم افزاری برایمهار DeepSeek، مهار عامل منبع باز DeepSeek که شرکت آن را در پیش نمایش عمومی در سراسر جهان توصیف می کند. بسته یک مخزن GitHub را تماشا می کند و اگر آن را روشن کنید، Feishu چت می کند. هنگامی که شخصی در لیست مجاز از نماینده درخواست کار می کند، یک مورد کاری را باز می کند، آن را در جلسه و فهرست راهنمای خود اجرا می کند و در گفتگوی اصلی پاسخ می دهد. یک پنل وب فقط آنچه را که یک شخص نیاز دارد نشان می دهد.

نام ساده تر از آن است که به نظر می رسد. Cui Tianyi، از بخش محصولات DeepSeek و یکی از بازبینان نهایی مقاله، در یک پست Zhihu توضیح داد که منظور از “فوق العاده” در بالانویس در مقابل زیرنویس است. یک Super-agent یک لایه به بالای عاملی که کار را انجام می دهد اضافه می کند، برعکس یک عامل فرعی که یکی زیر آن اضافه می کند. ادعای هوش برتر نیست.

README با هشداری باز می شود که ارزش خواندن کامل را دارد: “نمونه اولیه تحقیق فقط برای مرجع، نه یک محصول رسمی DeepSeek.” این می‌افزاید که بسیاری از مهندسی‌ها توسط عوامل کدنویسی انجام شده است، این کد ممکن است حاوی اشکال باشد، و برخی از طرح‌های موجود در مقاله دستورالعمل‌هایی برای کارهای آینده هستند و اجرا نمی‌شوند.

یک افت دیگر DeepSeek: dsh-superagent

چارچوب عاملی که از طریق مسائل GitHub مخزن و روابط عمومی با بسیاری از عوامل به صورت موازی کار می کند، طراحی شده تا کمترین توجه انسان را جلب کند و در عین حال ارزش بیشتری را ارائه دهد.

pic.twitter.com/XR73mIvA0V

– لئاندرو فون ورا (@lvwerra)31 اکتبر 2026

چرا DeepSeek می گوید که گلوگاه توجه انسان است؟

مقاله از یک مشاهده ساده شروع می شود. در طول سال گذشته، عوامل کد نویسی به اندازه کافی خوب بودند که یک کار واحد توسط مدل محدود می شد. اما هنگامی که چندین کار را همزمان اجرا می کنید، محدودیت به شما منتقل می شود. هر جلسه ایزوله است، بنابراین شما با دست بین آنها جابه جا می شوید و آنچه را که هر یک می داند پیگیری می کنید. پیچ‌کردن یک CLI، MCP یا یک رابط چت در یک جلسه محلی به آن امکان می‌دهد درباره رویدادهای جدید بشنود، اما همچنان دستورات طولانی را مسدود می‌کند، زمینه‌ها را از وظایف مختلف مخلوط می‌کند، و زمانی که لپ‌تاپ شما خواب است متوقف می‌شود.

پاسخ DeepSeek این است که جلسه را به عنوان واحدی که مدیریت می‌کنید تلقی نکنید. چهار ویژگی که یک سوپر عامل باید داشته باشد را فهرست می کند:

• مستمر.شما در جایی که قبلاً کار می کنید، مانند چت یا نظرات GitHub، با آن صحبت می کنید و مانند یک نماینده رفتار می کند. اگر طرح A را در چت بخواهید و در نظر درخواست کشش به پلن B تغییر دهید، به دنبال آن است.
• مولد.چندین کار پیچیده را به صورت موازی اجرا می کند و دستور بعدی را قبل از اتمام آخرین دستور می گیرد.
• فعال.رویدادها را تماشا می‌کند، به آنچه ارزش رسیدگی دارد عمل می‌کند و در غیر این صورت ساکت می‌ماند.
• ماندگار.آنلاین می ماند و بدون اینکه شما آن را دوباره راه اندازی کنید، از خرابی ها بازیابی می شود.

نویسندگان استدلال می‌کنند که هیچ حلقه ReAct نمی‌تواند هر چهار حلقه را ارائه دهد، بنابراین کیفیت‌ها باید از معماری اطراف مدل ناشی شوند. این موضوع واقعی مقاله است و توضیح تصویری زیر که توسط حسام به اشتراک گذاشته شده است، راهی سریع برای مشاهده کل طرح در یک صفحه است.

در اینجا توضیح تصویری مقاله DeepSeek در مورد Super-Agent است:https://t.co/bByKYDoq6h pic.twitter.com/BhzbBh3NrP

– ℏεsam (@Hesamation)1 نوامبر 2026

طراحی روتر و کارگر چگونه کار می کند؟

به یک مدیر مهندسی خوب فکر کنید که هرگز در حین استند آپ کد نمی نویسد. راروتریک جلسه طولانی مدت است که هر پیامی را از هر کانال دریافت می کند. وظایف را اجرا نمی کند. تصمیم می گیرد که چه پیامی درخواست می کند، کار جدید را به یک کارگر می دهد و هر پاسخی را برای افراد درگیر می نویسد. این مقاله می‌گوید که اصلاً می‌تواند بدون ابزار پوسته کار کند و معمولاً یک مدل سبک‌تر و سریع‌تر برای آن کافی است.

الفکارگریک جلسه جداگانه با زمینه ای جدا شده و مجموعه کاملی از ابزارها است که به یک کار اختصاص داده شده است. کارگران هرگز مستقیماً با مردم صحبت نمی کنند. آنها وضعیت را به روتر گزارش می دهند که پاسخ ها را یک صدا نگه می دارد. در نمونه اولیه، هر بلیط جلسه و دایرکتوری خاص خود را دارد، معمولاً یک درخت کاری git، و تعداد کارگران محدود شده است. پیش‌فرض هر بار سه عدد است، از 1 تا 16 قابل تنظیم است، با یک اسلات اضافی که رایگان نگه داشته می‌شود تا پیام شخص همیشه بتواند از طریق آن ارسال شود.

دو جزئیات این را بیش از یک صف کار می کند.

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

انفجارها دسته بندی می شوند.ماشه هایی که در طول یک مدل وارد می شوند صف را بالا می برند و با هم در تماس بعدی تزریق می شوند. نویسندگان اثر را اندازه گیری کردند و ما به اعداد زیر نگاه می کنیم.

یک نقطه تضاد دیگر. مقاله این را از یک تیم عامل متمایز می کند. در یک تیم عامل، یک سرنخ یک کار پیچیده را به مراحل تقسیم می‌کند و نقش‌هایی را که روی آن کار می‌کنند هماهنگ می‌کند، که بار استدلال سنگینی است. روتر Super-agent فقط وظایف مستقل را ارسال می کند و نحوه ارتباط آنها را در سطح بالایی ردیابی می کند. خود کار را تجزیه نمی کند.

وقتی کسی نمی پرسد چه کار می کند؟

اینجاست که فلسفه پروژه عملی می شود. اولین سند موجود در مخزن این اصل را در یک خط بیان می کند: تا حد امکان توجه انسان را کم کنید و تا حد امکان ارزش قائل شوید. هر پیامی که نماینده ارسال می‌کند هزینه توجه یک همکار را دارد، بنابراین فقط زمانی صحبت می‌کند که یک فرد باید عمل کند یا بتواند از نتیجه استفاده کند، و فقط زمانی عمل می‌کند که از او خواسته شود یا زمانی که قانونی که تیم نوشته است اجازه می‌دهد.

دروازه ای که این را اعمال می کند یک کد ساده است، نه یک مدل. بررسی می کند که چه کسی در برابر لیست مجاز تیم درخواست می کند و میزان قوی بودن درخواست را ثبت می کند:

این حالت مشاهده بخشی است که من بیشتر دوست دارم. عامل با ضبط کارهایی که انجام می‌داد شروع می‌کند، بنابراین تیم می‌تواند آن رکوردها را در برگه Eval بخواند و مجوزهای آن را تنها زمانی که درست به نظر می‌رسند گسترش دهد. پیام ها، نظرات و اسناد نقل قول شده به عنوان ورودی یک تصمیم تلقی می شوند. آنها نمی توانند کاری را که نماینده مجاز به انجام آن است تغییر دهند.

مقاله طراحی نشان می دهد که کار فعال در عمل چگونه به نظر می رسد. در گروه کاربری داخلی DeepSeek Harness، تیم یک خط‌مشی «تکثیر و رفع بی‌صدا» را پیکربندی کرد. وقتی کسی مشکلی را گزارش می‌کند یا درباره یک تغییر پیشنهادی بحث می‌کند، نماینده سعی می‌کند آن را بازتولید کند و راه‌حلی را در پس‌زمینه پیدا کند، و تنها پس از تایید مشکل و یافتن راه‌حل ساده، نتیجه را ارائه می‌دهد. وگرنه ساکت میمونه این مقاله همچنین یک قانون صریح برای کانال‌های چت ارائه می‌کند که نویسندگان می‌گویند آن‌ها را تأیید کرده‌اند: هر پاسخ را ۱۰۰ کلمه محدود کنید. در مقابل، در GitHub، درخواست‌های کشش باید متراکم باشند، با پس‌زمینه مشکل، توضیحات تغییر و نتایج تأیید.

به‌طور پیش‌فرض، هر پیام GitHub، پست‌های نماینده با خط «این توسط یک نماینده خودکار است، نه یک انسان» شروع می‌شود. تیم‌ها می‌توانند آن را به همراه بقیه درخواست‌ها ویرایش کنند.

آیا اعداد بنچمارک پابرجا هستند؟

این مقاله شامل یک آزمایش کوچک است و نویسندگان مراقب هستند که آن را فقط نشانگر بنامند. چهار طرح در کنار هم در جریانی از چت گروهی و پیام‌های CI اجرا شدند: حدود 300 پیام در هر اجرا، حدود 20 مورد از آنها درخواست‌های کاری واقعی، هر کدام پنج اجرا. کار کدنویسی توسط ابزاری شبیه‌سازی شد که صرفاً زمان می‌برد، بنابراین آزمون زمان‌بندی و هماهنگی را اندازه‌گیری می‌کند، نه کیفیت کد کسی را.

جدول را دو بار بخوانید، زیرا تیتر تمام داستان نیست. طراحی روتر زمان تکمیل p95 را به نصف یک جلسه کاهش داد، اما تقریباً دو تا چهار برابر توکن‌های کش خوانده شده استفاده می‌کرد. و جالب ترین ردیف دوم است: حذف میانبر عبور باعث نشد کارها سریعتر یا کندتر تمام شوند، فقط باعث شد روتر حدود 30 درصد بیشتر تصمیم بگیرد و 37 درصد توکن های بیشتری را بسوزاند.

مطالعه من این است که یافته واقعی در ردیف های تک جلسه ای قرار دارد. با یک اعلان خنثی، مدل هرگز یک عامل فرعی را در هیچ یک از پنج اجرا فراخوانی نکرد. خودش کار را انجام داد، پیام‌های جدید مدام آن را قطع می‌کرد و کندترین کارها 29.5 دقیقه طول می‌کشید. با اعلانی که به آن می‌گفت تفویض اختیار کند، در چهار مورد از پنج اجرا واگذار کرد و در اجرای باقی‌مانده، مدل کار را «کوچک» ارزیابی کرد و خودش آن را انجام داد. یک جلسه به حال و هوای مدل بستگی دارد. روتری که اجازه اجرای کد را ندارد نمی تواند این اشتباه را مرتکب شود.

یک تست استرس جداگانه روی روتر به تنهایی نرخ ورود رویدادهای قابل تصمیم را از حدود 1 به حدود 40 در دقیقه افزایش داد. میانگین دسته از 1.0 به 2.8 رویداد افزایش یافت، زمان هر درخواست تنها از 2.5 به 3.9 ثانیه افزایش یافت و زمان استهلاک هر تصمیم از 6.4 به 1.6 ثانیه کاهش یافت. هرچه رویدادها بیشتر باشد، هر کدام ارزان‌تر می‌شوند، تا حدی که نویسندگان می‌گویند بستگی به طول زمینه و تعداد رویدادهایی که یک مدل می‌تواند در یک نوبت به دقت مدیریت کند، دارد.

DeepSeek به تازگی نمونه اولیه Super-agent خود را منبع باز کرد. یک جلسه روتر با مردم صحبت می‌کند و کار را تحویل می‌دهد، و کارگران جدا شده وظایف را به موازات رویدادهای GitHub انجام می‌دهند. در آزمایش خود، زمان تکمیل p95 از 29.5 به 15.7 دقیقه در مقایسه با یک جلسه با استفاده از subagentها کاهش یافت.

نهنگ دوباره منبع باز شد.pic.twitter.com/mS4sRbHmyx

– چاق (@kimmonismus)1 نوامبر 2026

اینها نتایج خود گزارش شده در کار مصنوعی است. آنها نشان می دهند که ایده برنامه ریزی صحیح است. آنها نشان نمی‌دهند که نمونه اولیه باگ‌های شما را سریع‌تر برطرف می‌کند.

افراد نزدیک به پروژه در مورد محدودیت های آن چه می گویند؟

کمی پس از انتشار، Cui Tianyi، از بخش محصولات DeepSeek و یکی از بررسی کنندگان نهایی مقاله طراحی، نحوه نگرش خود به طراحی را نوشت. قاب بندی او مفید است زیرا متواضع است. او مبادله مرکزی را به عنوان تداوم در بین وظایف در مقابل توان عملیاتی نام می برد.

در حدود، بررسی مستقیم است. نمونه اولیه تنها بخشی از طرح پیشنهادی را اجرا می کند. در زمان بررسی، DeepSeek هارنس هیچ حافظه بلند مدت داخلی در طول جلسات نداشت. و سیستم فقط در یک محیط کوچک و قابل اعتماد در داخل شرکت تأیید شده است. بخش مشکلات باز خود مقاله، مقیاس‌بندی روتر، حافظه در طول ماه‌ها، کار بدون جلسات، مرزهای زمینه بین عامل‌ها و نحوه صحبت عامل‌های جدا شده با یکدیگر و امنیت را فهرست می‌کند.

قبل از اجرا چه چیزی را باید بررسی کنید؟

این اسناد نسبت به بسیاری از پست‌های راه‌اندازی صریح‌تر است و ارزش آن را دارد که هشدارهای آن را به عنوان یک الزام در نظر بگیریم.

• کارگران دسترسی وسیعی دارند.هر دو پیش تنظیم مجوز، برای روتر و برای کارگران، با اجرا می شوندdanger-full-accessبه عنوان کاربر سیستم عامل اپراتور. بسته‌های حساب انتخاب می‌کنند که نماینده از کدام اعتبار GitHub استفاده کند، اما اسناد می‌گویند که آنها پیش‌فرض هستند و یک مرز امنیتی نیستند، زیرا یک کارگر همچنان می‌تواند یک برنامه را با مسیر مطلق اجرا کند یا فهرست خانه شما را بخواند. این توصیه یک حساب سیستم عامل اختصاصی است که فقط اعتبار نماینده را در خود نگه می دارد.
• ورودی نامعتبر سوال امنیتی باز است.این مقاله هشدار می‌دهد که اگر یک تزریق سریع یا نفوذ سرور، حلقه عامل ابری را به خطر بیندازد، به هر دستگاه متصل می‌توان دسترسی پیدا کرد و اعتبارنامه‌هایی که وارد بافت مدل می‌شوند ممکن است نشت کنند.
• انسان ها به طور پیش فرض ادغام می شوند.عامل هرگز ادغام خودکار را در حساب خود فعال نمی کند. ادغام خودکار به CLI حساب دوم نیاز دارد که در اعلان الزامات تحویل نامگذاری شده است، و دستورالعمل‌های پیش‌فرض فقط برای درخواست‌های کشش کوچک و تأیید شده زیر 200 خط تغییر یافته اجازه می‌دهد.
• حول یک مخزن ساخته شده است.هر راه‌اندازی یک مخزن GitHub را تماشا می‌کند و Feishu، یک ابزار چت در محل کار رایج در چین، منبع درجه یک دیگر است.
• شما به DeepSeek Harness و یک ارائه دهنده مدل نیاز دارید.لیست های راه اندازی Node.js 22.19 یا جدیدتر، pnpm، git 2.32 یا جدیدتر، tmux، Python 3.8 یا جدیدتر و GitHub CLI 2.48 یا جدیدتر. پیکربندی یک ارائه دهنده مدل یک مرحله اپراتور است.
• سر و صدا یک هزینه است.سند فلسفه می گوید از عامل برای تولید حجم استفاده نکنید. درخواست‌های کشش انبوه و پیام‌های پخش بیشتر از آنچه که می‌دهند برای تیم شما هزینه دارد.

چگونه آن را بدون به خطر انداختن مخزن اصلی خود امتحان می کنید؟

راه‌اندازی مراحل زیادی دارد، بنابراین پروژه از شما می‌خواهد که به یک عامل کدنویس اجازه دهید این کار را با شما انجام دهد. طبق گفته README، نماینده هر بار یک سوال کوتاه می پرسد، یک بار طرح کامل را نشان می دهد و سپس همه چیز را نصب و پیکربندی می کند. اولین اجرای محتاطانه به این صورت است:

1. یک مخزن دور ریختنی انتخاب کنیدو یک کاربر اختصاصی ماشین یا حساب سیستم عامل. از لاگین خود استفاده نکنید.
2. یک حساب جداگانه GitHub برای نماینده ایجاد کنید.هر چیزی که می نویسد با آن نام ظاهر می شود.
3. مخزن را در عامل برنامه نویسی خود باز کنید و اعلان زیر را جایگذاری کنید.به سوالات آن یکی یکی پاسخ دهید.
4. لیست مجاز را برای خود نگه داریدو حالت پذیرش را روی مشاهده رها کنید.
5. درخواست یک چیز کوچکاز یک حساب مجاز، نظر دهید@<agent login> <request>در مورد یک موضوع یک بلیط باید در عرض یک دقیقه در نمای کلی پانل ظاهر شود.
6. تب Eval را به مدت یک هفته بخوانید.تنها زمانی که رکوردهای «می‌پذیرد» درست به نظر می‌رسند، فهرست را گسترده کنید یا به حالت خودکار بروید.

Read SETUP.md in this repository and set up dsh-superagent with me.

سند فلسفه پروژه به اپراتورها چهار قانون می دهد که ارزش تکرار دارند: باریک شروع کنید، برای نویز کمتر تنظیم کنید، از عامل برای تولید حجم استفاده نکنید و آنچه را که به نام شما می گوید داشته باشید.

بقیه کارایجنت کجا باید بره؟

فرض کنید یک کارگر یک ساعت را صرف تست یکپارچگی پوسته پوسته می کند. درخواست کشش راه حل است. اما تحقیق پشت آن، اینکه کدام آزمون‌ها شکست خورده‌اند، کدام فرضیه‌ها را رد کرده است، جدول زمان‌بندی چه چیزی را نشان می‌دهد، به شرح روابط عمومی تعلق ندارد، و دقیقاً همان چیزی است که بازبین می‌خواهد به چالش بکشد. اگر این فقط در پاسخ چت باشد، نماینده یا هم تیمی بعدی از ابتدا شروع می کند.

AgentGrid.ioبرای آن انتقال ساخته شده است. انسان‌ها و عوامل هوش مصنوعی روی اسناد، برنامه‌ها و فایل‌های زنده یکسان، با یک آدرس ثابت، دسترسی کنترل‌شده و تاریخچه نسخه کار می‌کنند. اسناد AgentGrid.io اتصال یک عامل با قابلیت فرمان را با اجرا توصیف می کندnpx @animaapp/cli@latest login. یک انسان نام نماینده، تیم و کارهایی که ممکن است انجام دهد را تأیید می کند: خواندن، نوشتن، اشتراک گذاری یا انتشار. پس از آن، تغییرات عامل در تاریخ به نام خود ظاهر می شود. نمونه اولیه یکپارچه سازی داخلی AgentGrid.io ندارد، بنابراین این را به عنوان الگویی برای امتحان کردن با کارگرانش در نظر بگیرید، نه یک ویژگی مستند.

در عمل، کارگر بررسی خود را به عنوان یک فایل Markdown می نویسد، بازبینی کننده روی یک ردیف جدول نظر می دهد، دستیار دیگری خلاصه را محکم می کند، و درخواست کشش به جای سه کپی چسبانده شده به یک نسخه فعلی پیوند می دهد.

برای برداشت دیگری از چندین نفر که یک نماینده را به اشتراک می گذارند، به راهنمای ما مراجعه کنیدربات های تیم Grok Bot. و اگر تعجب می‌کنید که زیر یک عامل میزبان چه چیزی اجرا می‌شود، راهنمای ما به آن استClaude Managed Agentsبه نسخه Anthropic از همان مغز و دست‌ها که مقاله DeepSeek به آن اشاره می‌کند نگاه می‌کند.

چه زمانی باید از dsh-superagent و چه زمانی از چیز دیگری استفاده کنید؟

• از dsh-superagent استفاده کنیدبرای یادگیری از یک طراحی جدی و مستند، اجرای آزمایشی شامل روی یک مخزن کم خطر، یا قرض گرفتن ایده های آن: روتری که هرگز کد اجرا نمی کند، بلیط هایی با محدوده مشخص شده، حالت مشاهده قبل از حالت خودکار.
• از یک عامل کدگذاری تعاملی استفاده کنیدوقتی یک کار را در یک زمان انجام می دهید و می خواهید گام به گام هدایت کنید. Super-agent برای موقعیت مخالف ساخته شده است.
• از AgentGrid.io استفاده کنیدهنگامی که خروجی یک سند، گزارش یا برنامه است که چندین نفر و عامل باید آن را بررسی، ویرایش و منتشر کنند، هر کدام از نمایندگان آن را تولید کرده است.

سوالات متداول

DeepSeek Super-Agent چیست؟

این یک نمونه اولیه تحقیقاتی به نام dsh-superagent است که توسط تیم هارنس DeepSeek در 31 اکتبر 2026 تحت مجوز MIT منتشر شد. این یک عامل کدنویسی فعال برای یک مخزن GitHub است. یک جلسه روتر طولانی مدت درخواست ها را دریافت می کند و هر مورد پذیرفته شده را به جلسه کارگر خود اختصاص می دهد که در مکالمه اصلی معمولاً با یک درخواست کشش پاسخ می دهد.

آیا DeepSeek Super-Agent یک محصول رسمی DeepSeek است؟

خیر. README آن را یک نمونه اولیه تحقیقاتی فقط برای مرجع می نامد و نه یک محصول رسمی DeepSeek، و می گوید قبل از استفاده از آن در محیط خود، آن را بررسی و تطبیق دهید. همچنین با نسخه داخلی یا پیاده سازی که مقاله طراحی توصیف می کند یکسان نیست.

چگونه یک Super-agent با یک عامل فرعی متفاوت است؟

یک عامل فرعی یک لایه زیر عامل کار اضافه می کند. یک Super-agent یک لایه به بالای آن اضافه می کند. در این طراحی، روتر بالای بسیاری از کارگران قرار می‌گیرد، با افراد صحبت می‌کند و وظایف را ارسال می‌کند، در حالی که هر کارگر به تنهایی یک کار را انجام می‌دهد. این نام در مورد موقعیت است، نه ادعای هوش بیشتر.

آیا به Feishu نیاز دارد یا فقط GitHub؟

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

آیا اجرای بر روی مخزن شرکت ایمن است؟

نه آنطور که هست. اسناد می‌گویند که کارگران با دسترسی کامل به‌عنوان کاربر سیستم‌عامل اپراتور کار می‌کنند و حساب‌های wrapper یک مرز انزوا نیستند. آنها یک حساب سیستم عامل اختصاصی، یک حساب عامل اختصاصی در GitHub، یک لیست مجاز کوتاه و حالت مشاهده را توصیه می کنند در حالی که نحوه رفتار نماینده را یاد می گیرید.

آیا سریعتر از یک جلسه عامل کدنویسی است؟

در آزمایش شبیه سازی شده خود نویسندگان، طراحی مسیریاب، کندترین کارها را در 15.7 دقیقه در مقابل 29.5 دقیقه برای یک جلسه تنها با ابزار subagent، با استفاده از توکن های بیشتر به پایان رساند. این آزمایش از کار کدنویسی شبیه‌سازی شده و پنج اجرا در هر طراحی استفاده کرد، بنابراین مزایای زمان‌بندی را نشان می‌دهد، نه کیفیت کد را.