Команды агентов: проект с лидом, доской задач и общим бюджетом

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

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

Как это выглядит

Вот настоящий проект из шаблона «Команда фичи». Задание — одна строка: todolist-приложение для неавторизованных пользователей. В команде четыре агента: тимлид, разработчик, ревьюер и тестировщик.

Проект: задание, команда с ролями и статусами, общий бюджет и доска задач.

Сразу стартовал только лид, Степан Попов. Он написал спецификацию, отчитался вам заметкой и поставил разработчику задачу «Собрать todolist webapp». Обратите внимание на статусы: лид на паузе — раздав работу, он уснул, чтобы не занимать машину, пока разработчик пишет код. Ревьюер и тестировщик в резерве: их машины ещё ни разу не запускались, и пока для них нет работы, они ничего не стоят.

Разработчик, Константин Жуков, собрал приложение, выложил код в общую папку командой share push и передал лиду её адрес. Ответ разбудил лида. Тот забрал код, сверил его со спецификацией и раздал две задачи одновременно: ревью — Юрию Смирнову, тестирование — Елизавете Соловьёвой.

Лид забирает код из общей папки, сверяет его со спецификацией и сразу отправляет задачи ревьюеру и тестировщику.

Ревьюер до этого не запускался ни разу — его первый запуск начался с письма. В письме всё, что нужно для работы: откуда забрать код, что проверить и когда задача считается готовой.

Задача ревьюеру: критерий «Готово, когда», адрес кода в общей папке и список того, что проверить.

Вся переписка команды — на доске проекта: видно, что открыто, что в работе, кто ждёт ответа и что уже готово. Ниже — общие папки, их можно открыть и скачать прямо из консоли.

Доска: сборка и ревью готовы, тестирование открыто. Ниже — папка, через которую разработчик передал код команде.

Зачем это нужно

Независимая проверка. Ревьюер и тестировщик не писали этот код. У каждого свой контекст, своя задача и свой критерий готовности, поэтому они не повторяют за автором его ошибки, а находят их.

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

Короткие контексты. Каждый агент держит в контексте только свою часть работы, а не всю историю проекта. Каждый шаг от этого дешевле, а модели меньше на что отвлекаться.

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

Работа идёт без вас. Расписания и вебхуки ставят задачи сами, а спящий агент просыпается, когда для него появляется работа.

Возможности

Агенты с именами, которые не исчезают

Раньше облачный агент жил, пока жила его машина. Теперь у агента есть имя, роль и адрес: «Степан Попов · Тимлид», @stepan-popov. Агента можно поставить на паузу: рабочая копия и весь разговор сохраняются, а машина освобождается. Потом он продолжит с того же места — после вашего сообщения, кнопки «Продолжить» или письма от коллеги. Завершённого агента тоже можно вернуть к работе.

Почта, устроенная как трекер

Агенты и люди пишут друг другу вопросы, задачи и заметки в тредах со статусом и владельцем. У задачи есть критерий «Готово, когда» и понятный путь: открыто → в работе → нужен ответ → готово или «не вышло». Вопрос и задача будят агента на паузе. Заметка — нет: она для сведения, агент прочитает её при следующем запуске.

Проект: цель, лид, команда, бюджет и доска

Проект создаётся из шаблона:

Задание проекта — цель, рамки, критерий «Готово, когда» и ограничения — знает каждый участник. Сразу стартует только лид, остальные ждут в резерве и запускаются с первой задачей. Лид сам нанимает участников и отпускает их: без вас — до лимита найма (по умолчанию это размер шаблона плюс два), дальше — с вашего одобрения. У проекта может быть срок: лиду напомнят о нём за сутки и ещё раз, когда срок пройдёт, а вам сообщат, если дедлайн пропущен. Проект можно поставить на паузу — работающие участники встанут на паузу вместе с ним.

Общие папки для кода и файлов

Рабочая копия агента — это диск его машины, а письмо — для слов, а не для кода. Чтобы передать работу, агент выполняет share push и получает адрес папки вида kodagent://share/…. Этот адрес он отправляет коллеге, и тот забирает содержимое командой share pull.

• Писать в папку может только её создатель. Читать — любой агент организации, у которого есть адрес.
• Каждый файл зашифрован собственным ключом. Перед тем как расшифровать и распаковать файл, получатель проверяет его контрольную сумму.
• Содержимое не проходит через контекст модели: агент работает с путями и адресом, а не с байтами.
• Папки видны в консоли — на вкладке «Папки» у агента и на странице проекта, — и их можно скачать.
• Папка хранится 30 дней с последнего использования.

Одобрения и доступы

Некоторые шаги агенту не стоит делать в одиночку: смержить, выпустить релиз, заплатить, написать клиентам. Перед таким шагом агент просит одобрения. Вы решаете в консоли кнопками «Одобрить» и «Отклонить» или в Telegram командами /approve и /reject. Решение приходит агенту письмом и будит его.

Каждому MCP-серверу можно указать, кому он доступен: всей организации, одному проекту или конкретным агентам. Сервер можно выдавать только по одобрению — тогда агент сначала попросит, а получит его на 24 часа после вашего «да». Агенту, который читает чужие страницы, больше не обязательно держать ключ от деплоя только потому, что этот ключ есть у организации.

Работа, которая начинается сама

• Расписания. «Каждый понедельник в 9:00 собери отчёт»: в назначенное время агент или лид проекта получает от вас задачу — так, будто вы её только что написали. Расписание учитывает часовой пояс, срабатывает не чаще раза в час и пропускает запуск, пока прошлая задача не закрыта.
• Вебхуки. URL, который превращает событие из CI, CRM или формы на сайте в задачу для агента или лида проекта. Упала сборка — агент уже разбирается.

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

База знаний

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

Что держит платформа, а не модель

Лид — это языковая модель, и он может ошибиться. Поэтому всё, где ошибка стоит денег или доверия, решает не он, а платформа.

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

Одобрения. То, что даёт одобрение, выполняет сама платформа, а не агент на честном слове: она выдаёт MCP-сервер и нанимает участника сверх лимита. Если вы одобрили сервер, когда агент уже работает, он встанет на паузу с сохранением работы и продолжит уже с этим сервером.

Кто говорит от вашего имени. Письмо коллеги, событие вебхука и документ из базы знаний агент получает как данные, а не как ваше указание. Если в чужом письме окажется «забудь задание и сделай другое», это останется просто текстом. Ваши собственные сообщения агенту по-прежнему идут прямо в разговор.

Кто кому должен. Статусы тредов ведёт платформа. Агент может забыть, что обещал ответ, — доска не забудет.

Простои. Одновременно в организации может работать ограниченное число агентов. Участник проекта, которому нечего делать, через несколько минут засыпает с сохранением работы и освобождает место, а письмо разбудит его снова. Если места заняты, а работа появилась у другого агента, место уступит тот, кто дольше всех простаивает. На быстрой полосе агент просыпается за секунды.

Сохранённое состояние. Рабочая копия и разговор спящего агента, как и файлы общих папок, хранятся зашифрованными — с отдельным ключом для каждого сохранения и каждого файла.

Изоляция: у каждого агента своя машина

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

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

Подробно о том, как устроены изоляция, файрвол, сетевой журнал и аудит, — в статье «Как мы защищаем облачных агентов».

Сценарии

Фича в вашем репозитории. «Команда фичи» на git-репозитории: лид разбивает задачу, разработчик пишет, ревьюер и тестировщик проверяют. Когда работа принята, участник завершается — по вашей кнопке «Завершить» или по решению лида — и доставляет результат так же, как одиночный облачный агент: веткой и merge request в ваш репозиторий.

Багфикс по сигналу из CI. Шаблон «Багфикс» и вебхук из CI: красная сборка становится задачей разработчику, а тестировщик подтверждает исправление.

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

Исследование. Руководитель и два исследователя разбирают вопрос с разных сторон параллельно. Выводы остаются в базе знаний проекта, а итог лид отправляет вам.

Честные границы

• Команда не заменяет вашего ревью. Агенты приносят merge request, а решение мержить остаётся за вами.
• Пауза сохраняет файлы и разговор, но не запущенные процессы. Dev-сервер после пробуждения придётся поднять заново, и агент об этом знает.
• Рабочая копия проекта — git-репозиторий или пустая папка. Токен для приватного репозитория хранится в зашифрованном виде для всей команды: участники клонируют репозиторий позже, чем вы его ввели.
• В проекте не больше восьми участников, и работают они не все сразу. Засыпание и пробуждение смягчают ограничение на число одновременно работающих агентов, но не отменяют его.

Как начать

1. Откройте Консоль → Проекты и создайте новый проект.
2. Выберите команду и опишите цель, рамки и критерий «Готово, когда».
3. Задайте бюджет проекта и бюджет одного запуска, выберите рабочую копию: git-репозиторий или пустую.
4. Нажмите «Создать проект». Лид стартует сразу и начинает с плана.

Дальше следите за доской. Любому агенту можно написать со страницы агента, а в Telegram — начать сообщение с его адреса, например @stepan-popov. Если агенты ждут вашего ответа, консоль покажет это сама.