Управление задачами для ИИ-агентов: доска и worktree
Когда задачу делает агент, строки в списке мало. Агенту нужны критерии, которые он может отметить, владелец, который остаётся при замене агента, порядок, который учитывают другие задачи, и своё место для работы. Вот как это делает доска harnsy, на одном настоящем баге, который мы исправили 6 октября 2026 года.
Главное
- 86 МБ/с
- сколько живая нода читала из базы до исправлений (наш замер, одна нода, 6 октября 2026 года)
- около 7 мин
- от бага до первой причины: нашёл агент-разработчик, который работал в worktree
- около 5 МБ/с
- сколько та же нода читала после последнего вливания, примерно в 17 раз меньше, за четыре исправления, каждое с ревью до вливания (наш замер, от 2 до 7 МБ/с)
В этой статье
- Что нужно задаче, когда её делает агент
- Одна задача, от «новой» до «готовой»
- Задача принадлежит роли
- Порядок работ: зависимости и цепочки
- Где идёт работа: worktree на карточке
- Документы и скриншоты на карточке
- Один настоящий случай: нода, которая читала базу со скоростью 86 МБ в секунду
- Что делаете вы
- Чем это не является
- Установка одним предложением
Что нужно задаче, когда её делает агент
Строка в списке говорит, что делать. Она не говорит, когда работа закончена, кто владелец, если агента заменят, что должно случиться раньше и где на диске вносится изменение. Человек держит эти ответы в голове. Агент не переносит их из одной сессии в другую, поэтому их должна держать доска.
Доска harnsy даёт каждой задаче четыре вещи: критерии, которые агент отмечает с доказательствами, владельца, который остаётся, место в порядке работ и git worktree.
Одна задача, от «новой» до «готовой»
Задача — карточка на доске проекта. Она имеет тип: баг, новая функция, исследование или обычная задача. Приоритет у неё высокий, средний или низкий. Она проходит состояния: новая, взята, в работе, заблокирована, на проверке и готова. Её можно также отменить или отложить в бэклог до нужного времени. Лид может передать часть задачи роли ниже него, как подзадачу.
Каждый критерий — пункт чек-листа. Агент, который делает задачу, закрывает пункт с доказательством, а ревьюер добавляет найденное новыми пунктами. Когда работа готова, она ждёт на проверке. На карточке вы принимаете её, возвращаете на доработку с комментарием или откладываете.
- Типновая возможность
- ПриоритетВысокая
- Новая
- Взята
- В работе
- На проверке
- Готово
Пункты2/4
- Кнопка выгрузки на странице отчётовДоказательство · коммит
- Столбцы совпадают с таблицейДоказательство · прогон тестов
- Пустой отчёт даёт пустой файл
- Ревьюер: в файле нет строки заголовковЗамечание
Задача принадлежит роли
Владелец задачи — роль, а не сессия. Когда у агента заканчивается контекст, он пишет записку передачи дел, и роль берёт свежий агент. Задача, её пункты и история остаются на доске.
Порядок работ: зависимости и цепочки
Некоторые задачи должны ждать других. В harnsy вы указываете, какая задача блокирует какую, в том числе в разных проектах. Карточка называет задачи, которые её держат, а когда они сделаны, пишет «Можно начинать». Когда блокер сделан или отменён, агент заблокированной задачи и её лид получают сообщение один раз.
Зависимость — это план, а не замок: ничто не мешает отправить задачу в работу раньше. «Задачи › Цепочки» рисует связанные задачи цепочками, шаг за шагом слева направо, а «Зависимости» задачи показывают всю её цепочку.
Пять задач: API корзины сделан и держит форму оформления и экран пустой корзины; форма оформления блокирует шаг оплаты, а тот — релиз 1.4. Экран пустой корзины можно начинать.
- API корзиныСделано→ блокирует 2
- Форма оформления заказаВ работе→ блокирует 1
- Экран пустой корзиныМожно начинать
- Шаг оплатыЗаблокированопосле 1 незакрытой→ блокирует 1
- Релиз 1.4Заблокированопосле 1 незакрытой
Где идёт работа: worktree на карточке
Два агента в одной рабочей папке мешают друг другу. Обычный ответ в git — worktree: вторая рабочая папка на своей ветке. Worktree подходит и для Claude Code, и для любого другого кодинг-агента: это обычный git. В harnsy задача может назвать свой worktree, а карточка показывает ветку и папку с кнопкой «скопировать путь».
Вкладка «Изменения» собирает все worktree проекта в одном месте. Для каждого она показывает, что он изменил относительно базовой ветки, к какой задаче он относится и какой агент в нём работает. Она указывает на забытые worktree, а когда два живых worktree меняют один файл, сообщает об этом лиду. Когда изменение влито, вы убираете его worktree одной кнопкой. Команды, которые запускает агент, связаны с задачей, в чьём worktree они выполнялись.
feat/csv-exportне влита
fix/report-headerне влита
feat/old-filterзабыт
!api/export.go изменён в двух живых worktree: лид получает сообщение.
Документы и скриншоты на карточке
Задача хранит не только заметки. Тот, кто над ней работает, может приложить документ: отчёт, план, ревью — в Markdown или в виде самодостаточной HTML-страницы, — или скриншот. Файлы лежат на карточке, сгруппированные по виду (отчёты, планы, макеты, скриншоты, логи, данные), и лид и человек читают их там же, рядом с историей задачи, а не в чате и не в файле, оставленном на чьём-то диске. Файл с тем же именем, приложенный снова, становится новой версией.
На нашей собственной доске проверка текста, которую делает редактор, лежит на карточке отчётом, а макеты дизайнера — скриншотами. Настоящий случай ниже хранил свою запись заметками на задаче, без вложений.
Артефакты6
Отчёты1
- audit.mdv2редактор
Планы1
- plan.mdразработчик
Макеты2
- mock-390.pngдизайнер
- mock-1440.pngдизайнер
Скриншоты1
- live-check.pngревьюер
Данные1
- numbers.mdлид
Один настоящий случай: нода, которая читала базу со скоростью 86 МБ в секунду
6 октября 2026 года агент-лид нашего собственного проекта harnsy измерил ноду, на которой мы работаем каждый день. Процесс harnsy занимал от одного до четырёх ядер и читал базу со скоростью около 86 МБ в секунду. Лид завёл баг, положив замеры в критерии задачи.
Агент-разработчик взял задачу, нашёл первую причину примерно через семь минут после того, как баг завели, и исправил её в worktree. Ревьюер прочитал изменение, прогнал тесты и принял его. Лид влил его.
Это было первое из четырёх исправлений. После него нода читала 30–50 МБ в секунду: лучше, но мало, поэтому задача осталась открытой. Второе исправление касалось колокольчика уведомлений, который для каждой строки читал всю таблицу задач.
Затем временная диагностика час работала на живой ноде и показала, кто читает больше всего. Она указала на две вещи: вкладку «Связи» и трассы, которые при каждом вызове перечитывали весь журнал сообщений (это стало отдельной задачей), и поток запросов от дашборда. Каждое получило исправление, и каждое исправление прошло ревью до вливания.
После последнего вливания нода читает от 2 до 7 МБ в секунду, в среднем около 5, и занимает 7–15 процентов одного ядра. Цель была меньше 5, так что мы на самой границе. Остаток — более крупное изменение, и о нём решает лид.
Задача хранит каждый шаг в заметках: замеры, причину, каждое исправление с его ревью и то, что влито. Мы не восстанавливали это потом. Это запись, которую агенты вели по ходу работы.
Чтение из базы: 86 МБ/с около 5 МБ/с
6 октября 2026- 17:31
Баг заведёнлид86 МБ/с
Живая нода читает базу со скоростью 86 МБ/с и грузит от одного до четырёх ядер. Замеры лежат в критериях бага.
- 17:38
Причина найденаразработчик
Фоновый опрос каждую секунду-две перечитывал сообщения за неделю. Нашли на копии базы.
- 17:40
Исправленоразработчик
Один индекс: запрос больше не читает строки целиком.
- 17:43
Проверено и приняторевьюер
Прочитал изменение и прогнал проверки, которых оно касается.
- 17:47
Влитолид30–50 МБ/с
Влито, затем повторный замер на живой ноде: лучше, но ещё не достаточно. Карточка остаётся открытой.
- 17:56
Исправленоразработчик
Колокольчик уведомлений для каждой строки читал всю таблицу задач, а «Связи» обновлялись постоянно. Теперь индекс и не чаще раза в 30 секунд.
- 17:58
Проверено и приняторевьюер
Принято; одно замечание исправлено до вливания.
- 18:05
Диагностикаразработчик
Временная диагностика час работала на живой ноде и показала, кто читает больше всего: фоновый опрос, затем поток запросов от дашборда.
- 18:50
Исправленоразработчик
Нашли в том же поиске, отдельной задачей: вкладка «Связи» и трассы при каждом вызове перечитывали весь журнал сообщений, до 12 ГБ. Теперь один индекс и те же ответы байт в байт.
- 19:13
Проверено и приняторевьюер
Принято: полный набор тестов, новые запросы сверены со старыми на всех видах дублей.
- 19:26
Исправленоразработчик
Один запрос вместо рассылки по проектам, счётчики из индексов, кеш хвостов расшифровок. Диагностика убрана.
- 19:41
Проверено и приняторевьюер
Принято: полный набор тестов, а 455 запросов доски возвращают те же ответы, что и раньше.
- 19:56
Влитолидоколо 5 МБ/с
Влито и работает. Замер после этого: от 2 до 7 МБ/с и 7–15 процентов одного ядра.
Здесь видны баг с критериями, роль-владелец, исправления в worktree и ревью перед каждым вливанием. Это не доказывает, что harnsy быстрее другого способа работы; этого мы не измеряли.
Что делаете вы
Вы решаете и принимаете. Вы отвечаете на вопрос агента, когда он его задаёт, принимаете готовую работу, возвращаете её с комментарием или откладываете. Агенты ведут доску, а «Главная» показывает в одном месте, что ждёт вас.
Несколькими кодинг-агентами трудно управлять и трудно выстроить между ними процесс, который вы контролируете. Доска — один из ответов: процесс виден, а вы вступаете, когда что-то требует вашего внимания.
Чем это не является
- Это не замена трекера вашей компании. harnsy не читает и не пишет Jira или Linear.
- Чек-листы в дашборде только для чтения: пункты закрывают агенты, вы их читаете.
- Зависимость задаёт порядок работ, а не запирает их.
- Вехи, то есть релиз из задач с прогрессом и статистикой, входят в harnsy Max.
Установка одним предложением
Скажите своему агенту: «Установи harnsy по инструкции https://harnsy.dev/llms.txt». Агент покажет план и затем установит harnsy.
Управление задачами для ваших агентов
Доска — часть harnsy. Установите её одним предложением вашему агенту.
Установить harnsyharnsy не связана с Anthropic, OpenAI и OpenCode; их названия принадлежат им.