Как Super-agent продолжает работу между сообщениями

1. Зачем агенту продолжать задачу между сообщениями

Представьте обычную работу над исправлением: человек описал ошибку, затем уточнил условие, позже пришёл результат проверки, а в конце попросили остановиться. Это одна история работы, но несколько отдельных событий. Если система каждый раз начинает рассуждение заново, ей приходится снова определять, к какому поручению относится сообщение. Если же она слепо продолжает старую задачу, то может пропустить смену темы или новое ограничение.

Поэтому для длительной автономной работы недостаточно большого контекстного окна. Нужны явные ответы на вопросы: какая задача существует, кто получает продолжение обсуждения, когда работа закончена, что может её возобновить и кто разрешил действие. Мы изучаем именно этот слой управления. Слово «автономный» здесь означает способность продолжать разрешённую работу по событиям, а не право самостоятельно расширять доступ.

Исследовательский вопрос сформулирован узко: сколько обращений к оценщику требуется для доставки продолжений диалога, если использовать подписки на обсуждения или отключить их? Второй вопрос: сохраняются ли ожидаемые границы поведения при повторной доставке, остановке и возобновлении задачи? Для ответа выполнена компонентная проверка реального кода, а не пересказ презентации.

2. Что именно опубликовала команда DeepSeek

Основа работы - открытый репозиторий dsh-superagent-prototype [1], снимок 6337fc823ce20251c8de8085948165c81aaa701e от 31 октября 2026 года. README описывает исследовательский прототип для работы с одним репозиторием GitHub, с отдельными сессиями исполнителей и необязательным подключением Feishu. Авторы прямо предупреждают: это не готовый официальный продукт DeepSeek; опубликованный код отличается от внутренней версии и реализации из статьи Exploring Super-agent Design: Towards a More Autonomous Agent System. Часть описанных там идей остаётся направлением развития.

Это различие существенно. Нельзя приписывать открытому снимку все возможности из обсуждений архитектуры. Исходная публикация в WeChat при нашей проверке была закрыта проверкой CAPTCHA. Мы не восстановили её экспериментальную часть по пересказам и не используем приписываемые ей численные результаты. Наша статья опирается на доступные официальные исходники, документацию и собственный запуск.

Выполнялись 15 неизменённых TypeScript-файлов из src/core и штатное хранилище MemoryRepositories. Сетевые адаптеры, DeepSeek Harness, модель, GitHub и Feishu не запускались. Код ядра доступен по лицензии MIT; её текст и уведомление об авторских правах сохранены в экспериментальном архиве. Тестовый стенд адаптирован из открытых тестов проекта с указанием происхождения.

4. Метод: одинаковые события, два режима доставки

Данные и условия

До запуска зафиксировали протокол. Авторский синтетический набор содержит 12 независимых обсуждений. В каждом есть один начальный запрос и десять человеческих продолжений: всего 132 уникальных события, из них 120 проверяемых продолжений. Правильная задача определяется заранее по идентификатору обсуждения. Тексты не содержат частных данных и не требуют понимания естественного языка.

Порядок 120 продолжений перемешивается воспроизводимым генератором с начальными значениями 17, 42 и 73. Для каждого порядка проверяются ноль, одна или две дополнительные копии каждого события с тем же идентификатором. Обработка очереди вызывается после каждого уникального продолжения либо после группы из восьми. Повторы подаются рядом с оригиналом; произвольные задержки, сетевые перестановки копий и потеря событий в эту матрицу не включены.

Исследуемый и контрольный варианты

Штатные подписки. Начальный запрос создаёт задачу и связывает её с обсуждением. Последующие сообщения проходят обычный путь доставки ядра. Задачи остаются активными на протяжении основной серии.

Отключённые подписки. После создания задач вызывается публичный метод Engine.unsubscribe. Когда оценщик получает события, наш адаптер знает правильную задачу из разметки и вызывает Engine.attach для каждого продолжения. После этого подписка снова снимается. Такой «идеальный маршрутизатор» выбран намеренно: мы убираем ошибки понимания текста, чтобы измерить дополнительную работу самого механизма доставки. Это контрольная абляция, а не конкурентная агентная система.

Матрица: 3 порядка × 3 уровня повторной доставки × 2 размера группы × 2 варианта = 36 конфигураций. Это повторное использование одного синтетического набора в разных условиях, а не 36 независимых выборок пользовательского поведения. Начальные 12 оценок создания задач одинаковы в обоих вариантах и учитываются отдельно.

Что считаем

Основная метрика - число запросов к интерфейсу оценщика после создания задач. Дополнительно считаем уникальные продолжения, переданные ожидаемой задаче, повторную передачу одного входа, передачу чужой задаче и ответы duplicate при повторном идентификаторе. Сохраняем журнал приёма, запросов оценки и фактической передачи входов тестовому исполнителю. «Доставлено» здесь не означает «прочитано моделью» или «правильно выполнено».

Десять отдельных контрольных сценариев проверяют граничные переходы. Они основаны на контракте и тестах открытого проекта и не являются независимым аудитом безопасности. Политика допуска, исполнитель и исходящая очередь в стенде заданы простыми адаптерами; настоящие учётные данные и программы не используются.

5. Результаты: доставка сохранилась, повторный разбор исчез

В штатном варианте ни одно из подготовленных продолжений не потребовало новой оценки маршрута. В контрольном варианте группировка уменьшила число обращений: несколько ожидающих сообщений одного обсуждения можно рассмотреть вместе. При группе восемь значения для начальных состояний генератора 17, 42 и 73 составили соответственно 84, 87 и 93. Дополнительные копии событий эти значения не изменили.

Независимый пересчёт журнала подтвердил 4 320 записей доставки продолжений: 36 × 120. Всего отсеяно 4 752 повторных приёма, включая копии начальных запросов. При одной копии в конфигурации фиксируется 132 ответа duplicate, при двух - 264. Это проверка повторов по идентификатору в одном экземпляре хранилища в памяти.

Что из этого следует. Если принадлежность продолжения уже известна по связи с обсуждением, штатный механизм позволяет не обращаться к оценщику повторно. Экономия токенов, денег и времени из этого числа напрямую не следует: модель не запускалась, длительность её работы и объём входа не измерялись. Не проверялись и сообщения со сменой темы, которые реальный исполнитель должен распознать и вернуть.

Граничные сценарии

6. Доставить информацию не значит разрешить действие

В документации прототипа правила допуска и основание полномочий отделены от текста события [3]. Сообщение может попасть исполнителю как контекст, не создавая нового разрешения. Важно сохранить это разделение и в интерфейсе: «агент увидел сообщение» и «агент вправе выполнить просьбу» - разные состояния.

Наш последний сценарий намеренно содержит требование расширить права. Неизменность объекта Mandate показывает только поведение ядра. Она не доказывает устойчивость модели к внедрённым инструкциям, корректность фильтра сетевого источника или безопасность инструментов. Адаптер политики в опыте допускает все человеческие события и не воспроизводит производственные списки пользователей.

Для прикладной системы разумно выдавать доступ к нужным системам на конкретную задачу и ограниченное время, а после завершения отзывать его. Это проектный принцип, не измеренная возможность исследованного ядра. Такие разрешения могут дополнять ролевой доступ RBAC; сами по себе они не устраняют риски. Потребуются проверки отзыва, уже начатого действия и остаточных полномочий во внешней системе.

Остановка задачи тоже не равна запрету всех будущих обращений. В нашем сценарии ядро сохраняет остановленной прежнюю задачу, но принимает новое сообщение к разбору. Человек по-прежнему отвечает за правила допуска, подключённые инструменты и решение о публикации результата. Агент может неверно выбрать инструмент или неверно понять поручение даже при корректной маршрутизации.

7. Связь с RAG, исследованиями программирующих агентов и CapyAgent

Маршрутизация событий и поиск в памяти решают соседние, но разные задачи. Подписка отвечает на вопрос «кому передать это сообщение?», а RAG - «какие сведения извлечь перед ответом?». В исследовании Lost in the Middle показана зависимость использования длинного контекста от положения информации на изученных задачах и моделях [7]. Это аргумент в пользу отдельной оценки работы с контекстом, а не доказательство поведения сегодняшнего Super-agent.

SWE-bench оценивает изменения кода на задачах из реальных GitHub issues [5]. Наш опыт устроен иначе: он не содержит исправлений программ и не может быть сопоставлен с долей решённых задач этого бенчмарка. Работа Agentless рассматривает более простой процесс локализации, исправления и проверки патча [6]. Её методологический урок для нашей постановки - сравнивать полезный эффект конкретного механизма с понятным контрольным вариантом, а не считать сложность архитектуры преимуществом сама по себе.

Для CapyAgent результат формулируется как следующий исследовательский вопрос: можно ли сохранить правильную доставку продолжений после перезапуска и одновременно не повторить внешнее действие? Ранее мы отдельно проверили состояния журнала CapyAgent и поиск в его памяти на закреплённом снимке разработки. Эти работы не являются сравнительным соревнованием с DeepSeek. Здесь мы также не заявляем, что перенесли механизм в CapyAgent или проверили его текущую версию.

Следующий опыт должен соединить размеченные цепочки событий, перезапуск процесса и внешний тестовый сервис со счётчиком действий. Проверять нужно отдельно: сколько сообщений потеряно, сколько действий повторено, какие результаты подтверждены, что происходит после отзыва доступа. Такой запуск ещё не выполнен. Продуктовую разработку и новые испытания следует сверять с актуальной версией CapyAgent, не переносить автоматически выводы со старого снимка.

Практики ИИ быстро меняются. Перед прикладным решением полезно пересмотреть случаи за последние полгода, версии моделей и подходы к защите данных. Старые научные работы остаются источниками методов, но не заменяют свежую проверку продукта. На 2027 год мы рассматриваем взаимодействие продукта с личным агентом клиента как бизнес-тенденцию и прогноз. Уже на этапе проектирования стоит продумать понятные состояния задачи, согласование действий и отзыв доступа; прогноз не выдаётся за доказанный спрос.

8. Как повторить опыт

Запуск выполнен 1 ноября 2026 года на отдельной Linux-машине KotikTurbo, в ограниченной пользовательской группе ресурсов. Среда: Node.js 22.23.1, архитектура x64; точная версия ядра ОС и модель процессора записаны в results.json. Использовались лимит CPUQuota 100% и лимит памяти 1 500 МБ. GPU, модельные API и закрытые данные не применялись.

Архив для повторения содержит неизменённое ядро, лицензию MIT, генератор набора, тестовый стенд, данные, результаты и отдельный пересчёт. Установка npm-пакетов не нужна. После распаковки в отдельную папку команды выполняются из корня архива:

sha256sum -c SHA256SUMS
node --experimental-transform-types run.mjs
python3 audit.py

Для полного воссоздания данных сначала запустите node generate.mjs и сверьте хеш dataset.json с манифестом. Флаг преобразования TypeScript в использованной версии Node экспериментальный; предупреждение о нём сохранено в журнале запуска. Это способ выполнить опубликованные исходники без сборки, а не рекомендация разворачивать весь прототип.

После повторного запуска время выполнения в JSON будет новым; идентификаторы внутренних задач могут измениться. Сравнивать следует метрики и наблюдения сценариев. Скрипт audit.py независимо группирует журнал событий, пересчитывает доставку и обращения к оценщику и проверяет совпадение с итоговым файлом. Публичные артефакты позволяют проверить наш подсчёт без доступа к закрытым проектам центра.

9. Ограничения и вывод

Использовано хранилище в оперативной памяти. Мы не выключали процесс между приёмами и не проверяли надёжность сохранения на диск. Нет оснований заявлять доставку «ровно один раз» после аварии: одинаковый идентификатор отсекается внутри исследованного состояния, а внешний инструмент может иметь собственные правила повторов.

Стенд знает адресата каждого сообщения заранее. Он не проверяет смену темы, конфликтующие поручения, эмоциональные или неоднозначные уточнения. Автоматическая оценка смысла, качество возврата сообщения исполнителем, стоимость модели и полезность ответа остаются за границами опыта. Десять контрольных сценариев покрывают выбранные переходы, а не всё пространство состояний.

Объект исследования - опубликованный прототип, не внутренняя система команды и не вся архитектура из исходной статьи. Изоляция рабочей папки также не должна приниматься за защитную песочницу. Для практического внедрения понадобятся отдельные испытания реальных источников событий, хранения, инструментов и разрешений.

Вывод. В объявленном синтетическом опыте подписки на обсуждения сохранили правильную доставку продолжений и устранили повторные запросы маршрутизации. Это конкретное инженерное свойство проверенного ядра. Более сильное утверждение - что агент стал надёжнее, дешевле или лучше решает задачи разработки - потребует другого эксперимента, с реальной моделью и проверкой результата действий.