300 ИИ-агентов на вашем ПК: Обзор Kimi Work

Я тестирую ИИ-инструменты для разработки с 2023 года. За это время через мои руки прошло больше сорока разных ассистентов - от простых автодополнений до автономных агентов, которые пытаются заменить целые команды.

И каждый раз, когда я вижу очередной «прорыв», я становлюсь скептиком.

Kimi Work от Moonshot AI я начал изучать с этим же настроением. «300 агентов одновременно» звучит как маркетинговый отдел, который решил перегнать всех.

Но чем глубже я копал, тем интереснее становилось.

Сначала я просто скачал приложение и решил прогнать через него реальный проект. Не демо-задачу, не учебный репозиторий, а рабочий backend на несколько тысяч строк.

Задача: проанализировать архитектуру, найти узкие места и предложить рефакторинг.

Я открыл Kimi Work, сформулировал задачу примерно так же, как описал бы её стажёру, и нажал «запустить».

Дальше началось то, чего я не ожидал.

В отличие от обычного чат-бота, где ты пишешь запрос и ждёшь ответа, здесь система начала разбивать задачу на куски. Я видел, как в интерфейсе появлялись новые «агенты» каждый со своим назначением.

• Один анализировал структуру папок.

• Второй проверял зависимости на устаревшие версии.

• Третий лез в тесты.

• Четвёртый в документацию.

Они не просто выполняли команды. Они взаимодействовали. Я видел, как один агент передавал результат другому. Как они уточняли запросы друг у друга.

На уровне ощущений это выглядело как мини-команда разработчиков внутри одного окна.

Теперь о технической стороне.

Заявка на 300 агентов это не 300 независимых моделей. Это 300 логических процессов, управляемых центральным оркестратором.

Я понимаю, почему маркетинг сделал акцент на цифре. Звучит впечатляюще.

Но на практике важнее не количество, а архитектура.

Каждый агент это не отдельная нейросеть, а скорее специализированный поток выполнения. Они используют общую модель Kimi K2.6, но с разными контекстами и инструкциями.

И это работает.

Я проверил этот подход на нескольких сценариях.

Простые задачи генерация тестов для конкретного модуля, обновление зависимостей, рефакторинг повторяющегося кода Kimi Work выполняет очень эффективно. Быстрее, чем я писал бы сам. Даже быстрее, чем с Copilot.

Сложные задачи те, где нужно понимать бизнес-логику, принимать архитектурные решения, учитывать неочевидные ограничения здесь система начинает буксовать.

Агенты перебирают варианты. Много вариантов. Быстро. Но они не всегда понимают, какой из них правильный.

Параллельность это про скорость перебора. А не про правильность выбора.

Ключевой параметр Kimi K2.6 контекстное окно в 256 тысяч токенов.

Это позволяет системе удерживать весь проект целиком. Код, тесты, конфигурации, документацию одновременно.

Именно это, а не количество агентов, делает Kimi Work полезным.

Ты не возишься с тем, как передать модели контекст. Она просто видит всё.

Многие недооценивают этот фактор. Я тоже недооценивал, пока не попробовал работать с проектом, который целиком умещается в контекст модели.

Разница как между попыткой собрать пазл по кусочкам и возможностью видеть всю картинку сразу.

Теперь о спорной части.

WebBridge.

Это технология, которая позволяет агентам работать через твой браузер. С твоими сессиями. Твоими авторизациями.

Ты не настраиваешь API-токены. Не даёшь доступ к GitHub через OAuth. Система просто открывает браузер и делает то же, что делал бы ты.

Агент может зайти в Jira, посмотреть задачу, обновить статус. Может закоммитить код. Может развернуть что-то через интерфейс облачного провайдера.

С одной стороны гениально. Интеграция без интеграции.

С другой я задумался: а готов ли я дать ИИ доступ ко всему, что открыто в моём браузере?

Ответа у меня пока нет.

Я сравнил Kimi Work с тем, что уже использую.

Copilot это ускорение на уровне строки. Ты пишешь, он дополняет. Ты контролируешь каждую букву.

Cursor это среда, где ИИ помогает редактировать. Более глубокий уровень, но всё равно ты за рулём.

Devin это автономный агент, который пытается заменить разработчика целиком. Ким точно знает.

Kimi Work нечто другое.

Это не ассистент. Не редактор. Не замена.

Это распределённая система, которая пытается делать за тебя часть работы параллельно.

Где это реально полезно уже сегодня?

Чёткие задачи с границами.

Анализ логов и ошибок да.

Обновление зависимостей да.

Генерация тестов да.

Рефакторинг изолированных модулей да.

Архитектурные решения нет.

Проектирование с нуля нет.

Задачи с высокой неопределённостью нет.

И это нормально для текущего поколения агентных систем.

У меня есть несколько вопросов, на которые я пока не нашёл ответа.

Насколько агенты действительно автономны? Или они просто выполняют инструкции, которые оркестратор разбил на этапы?

Насколько сложно контролировать систему из 300 параллельных процессов? Когда я открываю интерфейс и вижу десятки потоков, я не всегда понимаю, что именно происходит.

И, самое главное: нужно ли разработчику такое разделение ответственности в реальной работе?

Не уверен.

Я не знаю, станет ли Kimi Work стандартом через пару лет.

Сейчас это выглядит как амбициозный эксперимент. Интересный. Работающий в узких сценариях. Не готовый заменить существующие инструменты.

И главный вопрос не в том, сможет ли система работать с 300 агентами.

А в том, зачем это разработчику.

Ответ я, наверное, узнаю через год-два.

А пока буду продолжать тестировать.