Kaiban: канбан-доска, где в каждой колонке сидит ИИ-агент

04.10.2026 ·8 мин чтения ·Статьи·Олег Букатчук

У работы с ИИ-агентами есть знакомая болезнь: всё живёт в чате. Требования — в одном треде, код — в другом, а почему агент решил именно так, через неделю не вспомнит никто. Kaiban лечит это способом, который понятен любому, кто хоть раз видел доску задач: колонка — это роль, в каждой роли сидит агент, а между колонками стоит человек с кнопкой «Approve».

Проекту две недели: репозиторий создан 22 сентября 2026 года, лицензия Apache 2.0, десять звёзд. README у него подробный, но самое интересное туда не попало — оно в коде.

Идея за одну минуту

Доска локальная и рассчитана на одного человека. Не SaaS, не командный сервер: docker compose up на своей машине, свой ключ к модели, свой репозиторий.

При первом запуске появляются шесть колонок:

Продакт → Бизнес-аналитик → Системный аналитик → Разработчик → QA → Auto QA

Задача создаётся в первой колонке. Дальше цикл одинаковый для каждого этапа:

Нажимаете «Запустить агента».
Агент работает, лог идёт в карточку в реальном времени.
На выходе — отчёт в markdown.
Читаете. Устраивает — апрув, карточка уезжает в следующую колонку. Не устраивает — возврат.

Правила движения жёсткие. Вперёд — только после успешного прогона и только на один шаг. Назад — в любую предыдущую колонку, но с обязательным комментарием: он попадает в контекст следующего прогона как Retry notes. То есть «переделай» без объяснения система просто не примет.

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

Что происходит внутри одного прогона

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

Интересное начинается на ограничениях. У каждого прогона есть бюджет, и проверяется он перед каждым шагом:

Лимит	По умолчанию
Шагов модели	40
Вызовов инструментов	80
Токенов	200 000
Стоимость	5 долларов
Время	30 минут

Лимиты задаются в настройках, уточняются на уровне колонки и отдельной задачи. Упёрся в любой — прогон останавливается со статусом stopped, а причина дописывается в отчёт. Агент, который зациклился на вызове одного и того же инструмента, не съест месячный бюджет за ночь. Для двухнедельного проекта это редкая зрелость: обычно про лимиты вспоминают после первого счёта.

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

Две защёлки, о которых не пишут в README

Контракт этапа. Колонке можно задать обязательные поля результата. Агент сдаёт их отдельным инструментом submit_stage_output, и пока обязательные поля пусты, прогон считается проваленным, а апрув недоступен — даже если отчёт выглядит убедительно. Это отличает «агент что-то написал» от «агент сдал то, что от него требовали».

Обязательный diff. У колонки есть флаг requires_git_diff. Если он включён, при апруве сервер сравнивает ветку задачи с основной и не пускает дальше пустую разницу. Отчёт «всё реализовано» без единой изменённой строки этап не пройдёт.

Обе защёлки отвечают на главный вопрос к любому агенту: чем его слова отличаются от результата. Отчёт — это слова. Заполненный контракт и непустой diff — результат.

История, которую можно поднять через месяц

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

Хеш промпта — мелочь, которую оценит любой, кто разбирал инциденты. Когда через месяц агент начнёт отвечать иначе, первым вопросом будет «а промпт тот же?». Здесь на него есть ответ.

Архив скрывает карточку с доски, но не удаляет ничего: описание, комментарии к возвратам и отчёты остаются, задачу можно вернуть.

Интеграции

Встроенных четыре, все по токену: Jira, Confluence, GitLab и GitHub. Набор инструментов у агента скромный и понятный:

Jira — поиск, чтение задачи, создание, комментарий;
Confluence — поиск и чтение страницы;
GitHub и GitLab — чтение репозитория, список и создание PR или MR;
git — status, log, diff, commit, push в ветке задачи.

К карточке привязываются артефакты: задача в Jira, страница требований в Confluence, репозиторий. Тогда часть работы система делает сама, без участия модели: перед прогоном читает страницу требований, после — пишет комментарий в Jira, дописывает отчёт на страницу Confluence, пушит ветку kaiban/task-<id> и открывает PR или MR.

Сделано аккуратно: упавшая интеграция прогон не валит. Ошибка превращается в строку раздела «Синхронизация артефактов» в отчёте. Недоступная Jira — не повод терять двадцать минут работы модели.

MCP подключается только удалённый, по HTTP/SSE. Локальные серверы через stdio пока в планах. Инструменты получают префикс вида mcp_<сервер>_<имя>, так что два сервера с одинаковыми названиями не конфликтуют. И встроенные инструменты, и MCP доступны агентам всех колонок сразу — разграничения по ролям нет.

Под капотом

Слой	Что используется
API	Go 1.27, Fiber
Интерфейс	Next.js 15, русский и английский
Данные	PostgreSQL 16
Очередь	таблица в Postgres, `FOR UPDATE SKIP LOCKED`
Обновления в реальном времени	Server-Sent Events

Брокера сообщений нет, и это правильно. Очередь — обычная таблица: воркер забирает задание в аренду на десять минут и продлевает её, пока работает. Умер воркер — аренда истекла, задание подхватит другой. После восьми попыток задание помечается проваленным, чтобы не крутиться вечно. Воркеров по умолчанию два, меняется переменной WORKER_N.

Для локального инструмента на одного человека это ровно та сложность, которая нужна: три контейнера и ни одной лишней движущейся части.

Запуск

git clone https://github.com/gonnafaraway/kaiban.git
cd kaiban
cp .env.example .env

В .env нужны три строки:

OPENAI_API_KEY=sk-...
OPENAI_API_BASE=https://api.openai.com/v1
OPENAI_MODEL=gpt-4.1

docker compose up --build

Интерфейс откроется на http://localhost:3000. Модель подойдёт любая с OpenAI-совместимым API и поддержкой вызова инструментов — без неё агент не сможет ни сходить в Jira, ни сделать коммит.

Важно. На 4 октября 2026 года ветка main не собирается: последний коммит a0ea7a6 переносит пакеты и удаляет файл с git-инструментом, на который продолжает ссылаться остальной код. Сборка в CI красная. Предыдущий коммит собирается чисто — перед запуском нужен git checkout f5c08ad.

Где тонко

Что стоит знать до того, как подключать к доске рабочий токен.

Разработчику нечем писать код. Это главная оговорка. Во встроенном наборе нет инструмента, который создаёт или меняет файлы в рабочей копии: git-инструмент умеет закоммитить и запушить то, что уже изменено, но менять нечем. Из коробки колонка «Разработчик» выдаёт план и отчёт, а не патч. Чтобы агент действительно правил код, ему нужен MCP-сервер с файловым доступом к той же рабочей директории. С аналитическими колонками такой проблемы нет — они работают полноценно сразу.

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

Секреты лежат открытым текстом. Токены интеграций и ключ модели хранятся в Postgres без шифрования — автор честно пишет об этом в спецификации и держит шифрование в планах. В интерфейсе значения замаскированы, в базе — нет. При этом Postgres выставлен на порт 5433 с паролем kaiban, а у API нет авторизации. На ноутбуке за NAT это терпимо. На сервере с белым адресом — нет.

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

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

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

Кому это нужно

Kaiban не заменит команду и не пытается. Он полезен в трёх случаях.

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

Второй — вам важен след. Кто что решил, на каком промпте, за сколько токенов и почему задачу вернули назад — всё лежит в одной карточке, а не в истории чата.

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

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

Олег Букатчук

DevOps- и SRE-инженер. Строил отказоустойчивую инфраструктуру для классифайда, e-commerce и госсектора: cian.ru, aliexpress.ru, mos.ru.

Об авторе Телеграм GitHub