DeepSeek Super-Agent: що це таке, як це працює та чого ще не вистачає3 min read
Reading Time: 11 minutesВідкрийте відразу три агенти кодування, і ви відчуєте проблему. Один чекає на рішення, інший закінчив двадцять хвилин тому, і ви вже забули, який має виправлення автентифікації. Команда Harness DeepSeek поставила цифру: з її досвіду людина може стежити лише за трьома-п’ятьма сеансами активного агента одночасно. Після цього модель більше не є вузьким місцем. Ви є.
31 жовтня 2026 року команда опублікувала статтю про дизайн того, що вона називає Super-agent, і відкрила прототип під назвою dsh-superagent. Це агент проактивного кодування для одного репозиторію GitHub. Один тривалий сеанс маршрутизатора спілкується з людьми та роздає роботу, а кожен прийнятий запит отримує власний робочий сеанс, який завершується запитом на отримання або запитанням. Сховище пройшло 12 000 зірок приблизно за два дні. Його README прямо стверджує, що це дослідницький код, а не офіційний продукт DeepSeek.
Цей посібник призначений для інженерів і керівників команд, які хочуть знати, що робить прототип, як працює дизайн маршрутизатора та робочої системи, що підтверджують, а що ні, контрольні показники, а також що потрібно перевірити, перш ніж направити його в справжнє сховище.
Одне зауваження перед деталями. Відповідь робочої особи на «виправити цю помилку» — це запит на отримання, і GitHub є чудовим місцем для цього. Решту того, що створюють агенти навколо коду, складніше розмістити: опис першопричини, підсумок тесту, порівняльну таблицю, яку запитав рецензент.AgentGrid.ioце спільний робочий простір, де люди та агенти штучного інтелекту створюють, редагують і обмінюються документами, програмами та файлами з однією живою версією, атрибуцією та історією. Ми повертаємось туди, де це підходить ближче до кінця.
Що таке DeepSeek Super-Agent?
Дві речі з’явилися разом. Перша — це довга стаття про дизайн «Дослідження суперагентного дизайну: на шляху до більш автономної агентської системи». Команда Harness написала його китайською мовою та опублікувала машинний переклад англійської версії на X 1 листопада. Його переглянули понад 2,2 мільйона разів. Другий код:deepseek-ai/dsh-superagent-прототип, випущений за ліцензією MIT.
Дослідження дизайну суперагентів: на шляху до більш автономної системи агентів
– DeepSeek Harness (@DeepSeekHarness)1 листопада 2026 р
Це не нова модель. dsh-superagent — пакет дляDeepSeek джгут, джгут агентів DeepSeek з відкритим вихідним кодом, який компанія описує як загальнодоступний у всьому світі. Пакет стежить за одним репозиторієм GitHub і, якщо його ввімкнути, Feishu спілкується в чатах. Коли хтось із дозволеного списку запитує агента про роботу, він відкриває робочий елемент, запускає його у власному сеансі та каталозі та відповідає в оригінальній бесіді. Веб-панель показує лише те, що потрібно людині.
Назва легша, ніж звучить. Цуй Тяньї з відділу продуктів DeepSeek і один із останніх рецензентів статті пояснив у дописі Zhihu, що «супер» мається на увазі як надрядковий, так і нижній. Суперагент додає рівень над агентом, який виконує роботу, на відміну від субагента, який додає один під собою. Це не твердження про вищий інтелект.
README відкривається з попередженням, яке варто прочитати повністю: «Прототип дослідження лише для довідки, а не офіційний продукт DeepSeek». У ньому додається, що більша частина інженерної роботи була виконана агентами кодування, що код може містити помилки, і що деякі розробки в статті є напрямками для майбутньої роботи та не реалізовані.
| З першого погляду | dsh-superagent-прототип |
|---|---|
| Що це таке | Агент проактивного кодування для одного репозиторію GitHub, упакований як пакет DeepSeek Harness |
| Статус | Дослідницький прототип, «програмне забезпечення, не готове до виробництва» відповідно до README |
| Ліцензія | MIT |
| Мова | TypeScript |
| Слухає | Проблеми GitHub, запити на отримання, коментарі та CI. Чати Feishu необов’язкові |
| Створено | 31 жовтня 2026. Більше 12 000 зірочок і 1200 розгалужень до 2 листопада |
| Як це налаштувати | Попросіть свого агента кодування прочитати SETUP.md і налаштувати його разом з вами |
Ще один спад DeepSeek: dsh-superagent
Структура агента, яка паралельно обробляє проблеми GitHub репозиторію та PR з багатьма агентами, розроблена таким чином, щоб залучати якомога менше уваги людини, забезпечуючи якомога більше цінності.
– Леандро фон Верра (@lvwerra)31 жовтня 2026 р
Чому DeepSeek каже, що вузьким місцем є людська увага?
Стаття починається з простого спостереження. За останній рік агенти кодування стали настільки хорошими, що одна задача обмежується моделлю. Але як тільки ви виконуєте кілька завдань одночасно, межа переходить до вас. Кожен сеанс ізольований, тож ви перемикаєтесь між ними вручну та відстежуєте, що кожен знає. Підключення CLI, MCP або конектора чату до одного локального сеансу дає йому змогу отримувати інформацію про нові події, але він усе ще блокує довгі команди, змішує контексти з різних завдань і зупиняється, коли ваш ноутбук переходить у режим сну.
Відповідь DeepSeek полягає в тому, щоб припинити розглядати сеанс як одиницю, якою ви керуєте. У ньому перераховано чотири риси, які повинен мати суперагент:
- Безперервний.Ви спілкуєтеся з ним там, де вже працюєте, наприклад у чаті чи коментарях GitHub, і він поводиться як один агент. Якщо ви запитаєте план А в чаті та перейдете на план Б у коментарі до запиту на отримання, це випливає.
- Продуктивний.Він виконує кілька складних завдань паралельно та виконує наступну інструкцію до завершення останньої.
- Проактивний.Він спостерігає за подіями, реагує на те, що варто обробляти, і мовчить в інших випадках.
- Наполегливий.Він залишається онлайн і відновлюється після збоїв без перезапуску.
Автори стверджують, що жоден цикл ReAct не може забезпечити всі чотири, тому якості мають виходити з архітектури навколо моделі. Це справжня тема статті, а візуальний пояснювач нижче, яким поділився Хесам, є швидким способом побачити весь дизайн на одній сторінці.
ось візуальне пояснення статті DeepSeek про Super-Agent:https://t.co/bByKYDoq6h pic.twitter.com/BhzbBh3NrP
– ℏεsam (@Hesamation)1 листопада 2026 р
Як працює маршрутизатор і робочий дизайн?
Подумайте про хорошого інженерного менеджера, який ніколи не пише код під час стояння. Theмаршрутизаторце один довготривалий сеанс, який отримує кожне повідомлення з кожного каналу. Він не запускає завдання. Він вирішує, про що запитує повідомлення, передає нову роботу працівнику та пише кожну відповідь залученим людям. У статті сказано, що він може працювати взагалі без інструменту оболонки, і що для цього зазвичай достатньо легшої та швидшої моделі.
Аробітникце окрема сесія з ізольованим контекстом і повним набором інструментів, присвячена одному завданню. Робітники ніколи не спілкуються з людьми безпосередньо. Вони повідомляють про статус маршрутизатору, який зберігає відповіді одним голосом. У прототипі кожен квиток отримує власний сеанс і власний каталог, як правило, робоче дерево git, а кількість робочих елементів обмежена. За замовчуванням три за один раз, регулюється від 1 до 16, з одним додатковим слотом, який залишається вільним, щоб повідомлення людини завжди можна було отримати.
Дві деталі роблять це не просто чергу завдань.
Подальші дії пропускають маршрутизатор.Після того, як воркер стане власником запиту на отримання або ланцюжка чату, він підписується на цей потік. Пізніші коментарі йдуть безпосередньо до нього, без додаткового виклику моделі на маршрутизаторі. Якщо коментар виявляється про щось інше, працівник повертає його.
Сплески стають порційними.Тригери, які надходять під час однієї моделі, повертаються в чергу та разом вводяться в наступний виклик. Автори виміряли ефект, і ми дивимося на цифри нижче.

Ще один пункт контрасту. Стаття відрізняє це від команди агентів. У групі агентів лідер розбиває одне складне завдання на етапи та координує ролі, які над ним працюють, що є важким навантаженням для міркування. Маршрутизатор Super-agent відправляє лише незалежні завдання та відстежує їх взаємозв’язок на високому рівні. Він не розкладає сам твір.
Що він робить, коли ніхто не питає?
Тут філософія проекту набуває практичного застосування. Перший документ у сховищі викладає принцип одним рядком: приділяти якомога менше людської уваги та надавати якомога більше цінності. Кожне повідомлення, яке надсилає агент, вимагає уваги колеги, тому воно говорить лише тоді, коли особа має діяти або може використати результат, і воно діє лише тоді, коли його запитують або коли це дозволяє правило, створене командою.
Ворота, які забезпечують це, є простим кодом, а не моделлю. Він перевіряє, хто запитує, за дозволеним списком команди та записує, наскільки сильний запит:
| Сила | Приклади з док | Що відбувається |
|---|---|---|
| Відвертий | Особа зі списку дозволених згадує агента або продовжує ланцюжок, у якому вже є заявка | Агент приймає роботу в будь-якому режимі |
| Виведено | Бот у списку ботів Джерела або особа, яка не входить до списку. Неадресоване повідомлення, яке команда вирішила отримати | Оцінюється за письмовими правилами команди. У режимі спостереження за замовчуванням це записується лише як “прийме” |
| Не допущено | Будь-який інший бот, усе, що ігнорує таблиця прийому | Випадає до виклику будь-якої моделі |
Мені найбільше подобається цей режим спостереження. Агент починає із запису того, що він би зробив, щоб команда могла прочитати ці записи на вкладці Eval і розширити свої дозволи лише тоді, коли вони виглядають правильно. Повідомлення, коментарі та цитовані документи розглядаються як вхідні дані для прийняття рішення. Вони не можуть змінити те, що дозволено робити агенту.
У статті про дизайн показано, як проактивна робота виглядає на практиці. У внутрішній групі користувачів DeepSeek Harness команда налаштувала політику «тихого відтворення та виправлення». Коли хтось повідомляє про проблему або обговорює запропоновану зміну, агент намагається відтворити її та знайти виправлення у фоновому режимі, і він надає результат лише після того, як підтвердить проблему та знайде просте виправлення. В іншому випадку він залишається тихим. У статті також міститься чітке правило для каналів чату, яке, за словами авторів, вони перевірили: обмежуйте кожну відповідь 100 словами. На GitHub, навпаки, запити на вилучення мають бути щільними, із фоном проблеми, описом зміни та результатами перевірки.
За замовчуванням кожне повідомлення GitHub, яке публікує агент, починається з рядка «Це зроблено автоматизованим агентом, а не людиною». Команди можуть редагувати це разом з рештою підказок.
Чи витримуються контрольні цифри?
Стаття містить невеликий експеримент, і автори обережно називають його лише орієнтовним. Чотири дизайни виконувалися поруч у потоці групового чату та повідомлень CI: близько 300 повідомлень на запуск, приблизно 20 із них — запити на реальну роботу, по п’ять запусків кожен. Роботу з кодування було змодельовано інструментом, який просто поглинає час, тому тест вимірює планування та координацію, а не якість будь-якого коду.
| Дизайн | Час виконання завдання, p50 / p95 (хв) | Маркери читання кешу за один запуск |
|---|---|---|
| Супер-агент | 12,4 / 15,7 | 23,2 млн |
| Супер-агент без проходу | 12,6 / 15,5 | 31,8 млн |
| Один сеанс із інструментом субагента, нейтральна підказка | 20,4 / 29,5 | 6,1 млн |
| Один сеанс із інструментом субагента, підказка делегування | 13,8 / 29,0 | 10,8 млн |
Прочитайте таблицю двічі, бо заголовок — це ще не вся історія. Конструкція маршрутизатора скоротила час завершення p95 приблизно вдвічі від одного сеансу, але він використовував приблизно в два-чотири рази більше маркерів читання кешу. І найцікавішим є другий рядок: видалення наскрізного ярлика не призвело до виконання завдань швидше чи повільніше, це просто змусило маршрутизатор приймати приблизно на 30 відсотків більше рішень і спалювати на 37 відсотків більше токенів.
Я вважаю, що справжня знахідка міститься в рядках односеансу. З нейтральним запитом модель жодного разу не викликала субагента в жодному з п’яти прогонів. Він виконував роботу сам, нові повідомлення постійно переривали його, а найповільніші завдання займали 29,5 хвилин. З підказкою про делегування, він делегував у чотирьох із п’яти прогонів, а в решті прогону модель оцінила роботу як «маленьку» та виконала її сама. Один сеанс залежить від настрою моделі. Маршрутизатор, якому заборонено запускати код, не може зробити цю помилку.
Окремий стрес-тест лише на маршрутизаторі підвищив швидкість надходження подій, які потребують прийняття рішення, приблизно з 1 до приблизно 40 за хвилину. Середня партія зросла з 1,0 до 2,8 подій, час на запит зріс лише з 2,5 до 3,9 секунди, а амортизований час на рішення впав з 6,4 до 1,6 секунди. Чим більше подій накопичується, тим дешевше кожна з них, до межі, за словами авторів, залежить від довжини контексту та кількості подій, які модель може точно обробити за один хід.
DeepSeek щойно відкрив вихідний код свого прототипу суперагента. Один сеанс маршрутизатора спілкується з людьми та роздає роботу, а ізольовані працівники виконують завдання паралельно з подіями GitHub. У їхньому власному тесті час завершення p95 знизився з 29,5 до 15,7 хвилин порівняно з одним сеансом із використанням субагентів.
The whale знову відкрито.pic.twitter.com/mS4sRbHmyx
– Chubby (@kimmonismus)1 листопада 2026 р
Це самооцінені результати синтетичної роботи. Вони показують, що ідея планування є правильною. Вони не показують, що прототип швидше виправляє ваші помилки.
Що кажуть близькі до проекту люди про його межі?
Незабаром після випуску Цуй Тяньї з відділу продуктів DeepSeek і один із останніх рецензентів статті про дизайн написав, як він бачить дизайн. Його обрамлення корисне, оскільки воно скромне. Він називає основним компромісом безперервність між завданнями проти пропускної здатності завдання.
За обмеженнями огляд є прямим. Прототип реалізує лише частину запропонованої конструкції. Згідно з його оглядом, DeepSeek Harness не мав вбудованої довгострокової пам’яті між сеансами. І система була перевірена лише в невеликому надійному середовищі всередині компанії. Власний розділ відкритих проблем статті містить перелік масштабування маршрутизатора, пам’яті протягом місяців, роботи без сеансів, меж контексту між агентами та того, як ізольовані агенти мають спілкуватися один з одним, і безпеки.
Що потрібно перевірити перед його запуском?
Документація більш відверта, ніж більшість публікацій про запуск, і варто розглядати її попередження як вимоги.
- Працівники мають широкий доступ.Обидва попередні налаштування дозволів, для маршрутизатора та для робочих, працюють з
danger-full-accessяк користувач ОС оператора. Оболонки облікових записів вибирають, які облікові дані GitHub використовуватиме агент, але в документах сказано, що вони встановлені за замовчуванням, а не є межею безпеки, тому що працівник все ще може запускати програму за абсолютним шляхом або читати ваш домашній каталог. Рекомендовано виділений обліковий запис ОС, який містить лише облікові дані агента. - Ненадійний вхід є відкритим питанням безпеки.У статті попереджається, що якщо миттєва ін’єкція або вторгнення на сервер скомпрометує цикл хмарного агента, кожен підключений пристрій може бути досягнутий, і облікові дані, які входять у контекст моделі, можуть витікати.
- Люди зливаються за замовчуванням.Агент ніколи не вмикає автоматичне об’єднання під своїм обліковим записом. Для автоматичного об’єднання потрібен другий CLI облікового запису, названий у запиті «Вимоги до доставки», а інструкції за замовчуванням дозволяють це робити лише для невеликих схвалених запитів на підключення до 200 змінених рядків.
- Він побудований навколо одного сховища.Кожне налаштування спостерігає за одним репозиторієм GitHub, а Feishu, інструмент робочого чату, поширений у Китаї, є ще одним першокласним джерелом.
- Вам потрібен джгут DeepSeek і постачальник моделі.Налаштування містить список Node.js 22.19 або новішої версії, pnpm, git 2.32 або новішої версії, tmux, Python 3.8 або новішої версії та GitHub CLI 2.48 або новішої версії. Налаштування постачальника моделі є кроком оператора.
- Шум – це вартість.Філософський документ говорить не використовувати агент для створення обсягу. Масові запити на отримання та широкомовні повідомлення коштують вашій команді більше, ніж вони дають.
Як би ви спробували це, не ризикуючи своїм основним сховищем?
Налаштування складається з багатьох етапів, тому проект просить вас дозволити агенту кодування зробити це разом з вами. Відповідно до README, агент задає одне коротке запитання за раз, показує повний план один раз, а потім інсталює та налаштовує все. Обережний перший запуск виглядає так:
- Виберіть одноразове сховищеі виділений обліковий запис користувача машини або ОС. Не використовуйте власний логін.
- Створіть окремий обліковий запис GitHub для агента.Усе, що там написано, з’являється під цією назвою.
- Відкрийте репозиторій у своєму агенті кодування та вставте підказку нижче.Відповідайте на його запитання по одному.
- Залиште список дозволених при собіі залишити режим прийому на спостереженні.
- Попросіть щось маленьке.З дозволеного облікового запису коментуйте
@<agent login> <request>по питанню. Квиток має з’явитися в Огляді панелі протягом приблизно хвилини. - Прочитайте вкладку Eval протягом тижня.Розширюйте список або перемикайтеся на автоматичний режим лише тоді, коли записи «приймуть» виглядатимуть правильно.
Філософський документ проекту дає операторам чотири правила, які варто повторити: починайте з вузького, налаштуйтеся на менше шуму, не використовуйте агент для створення гучності та володійте тим, що написано від вашого імені.
Куди має подітися решта роботи агента?
Припустімо, що працівник витрачає годину на нестабільний інтеграційний тест. Запит на витягування є виправленням. Але розслідування, яке стоїть за ним, які тести провалилися, які гіпотези воно виключило, що показала таблиця часу, не належить до PR-опису, і це саме те, що рецензент хоче оскаржити. Якщо це стосується лише відповіді в чаті, наступний агент або напарник починає з нуля.
AgentGrid.ioстворено для цієї передачі. Люди та агенти штучного інтелекту працюють з одними і тими ж живими документами, програмами та файлами, маючи одну стабільну адресу, контрольований доступ та історію версій. У документах AgentGrid.io описано підключення агента, який підтримує команди, шляхом запускуnpx @animaapp/cli@latest login. Людина затверджує ім’я агента, його команду та те, що він може робити: читати, писати, ділитися чи публікувати. Після цього зміни агента відображаються в історії під своїм іменем. Прототип не має вбудованої інтеграції з AgentGrid.io, тому розглядайте це як шаблон, який можна спробувати з його робочими засобами, а не як задокументовану функцію.
На практиці працівник пише своє дослідження як файл Markdown, рецензент коментує рядок таблиці, інший помічник підтягує резюме, а запит на отримання посилається на одну поточну версію замість трьох вставлених копій.
Інший погляд на те, як кілька людей використовують один агент, дивіться в нашому посібникуКомандні боти Grok Bot. І якщо вам цікаво, що ховається за розміщеним агентом, наш посібникClaude Managed Agentsрозглядає версію Anthropic того самого розколу мозку та рук, яку цитує стаття DeepSeek.
Коли слід використовувати dsh-superagent, а коли щось інше?
- Використовуйте dsh-superagentнавчитися на основі серйозного, задокументованого дизайну, провести закритий експеримент на сховищі з низьким рівнем ризику або запозичити його ідеї: маршрутизатор, який ніколи не запускає код, квитки із зазначеним обсягом, режим спостереження перед автоматичним режимом.
- Використовуйте один інтерактивний агент кодуванняколи ви виконуєте одне завдання за раз і хочете керувати крок за кроком. Суперагент створений для протилежної ситуації.
- Використовуйте AgentGrid.ioколи результатом є документ, звіт або програма, яку мають переглянути, відредагувати та опублікувати кілька людей і агентів, незалежно від того, який агент це створив.
Часті запитання
Що таке DeepSeek Super-Agent?
Це дослідницький прототип під назвою dsh-superagent, випущений командою Harness DeepSeek 31 жовтня 2026 року за ліцензією MIT. Це агент проактивного кодування для одного репозиторію GitHub. Довговічний сеанс маршрутизатора приймає запити та призначає кожен прийнятий власний робочий сеанс, який відповідає в оригінальній розмові, як правило, за допомогою запиту на вилучення.
Чи є DeepSeek Super-Agent офіційним продуктом DeepSeek?
Ні. README називає його дослідницьким прототипом лише для довідки, а не офіційним продуктом DeepSeek, і пропонує переглянути та адаптувати його перед використанням у вашому власному середовищі. Він також не ідентичний внутрішній версії або реалізації, описаній у статті дизайну.
Чим суперагент відрізняється від субагента?
Субагент додає рівень нижче робочого агента. Суперагент додає шар над ним. У цій конструкції маршрутизатор знаходиться над багатьма працівниками, спілкується з людьми та відправляє завдання, тоді як кожен працівник виконує одне завдання окремо. Назва стосується посади, а не претензії на більший інтелект.
Чи потрібен Feishu чи тільки GitHub?
Одного GitHub достатньо. Feishu є додатковим другим джерелом, і в документації сказано, що помилка налаштування Feishu вимикає лише джерело Feishu.
Чи безпечно працювати в репозиторії компанії?
Не так як є. У документах сказано, що робочі версії працюють із повним доступом як користувач ОС оператора, і що облікові записи оболонки не є межею ізоляції. Вони рекомендують спеціальний обліковий запис ОС, спеціальний обліковий запис агента на GitHub, короткий список дозволених і режим спостереження, поки ви дізнаєтесь, як поводиться агент.
Це швидше, ніж один сеанс агента кодування?
У власному змодельованому тесті авторів дизайн маршрутизатора виконував найповільніші завдання за 15,7 хвилин проти 29,5 хвилин для одного сеансу з інструментом субагента, використовуючи більше маркерів. Тест використовував імітацію кодування та п’ять запусків на дизайн, тому він показує переваги планування, а не якість коду.

Figma
Adobe XD


