Отдел агентов: как у меня работают агенты

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

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

Зачем отдельная папка? Агент забывает всё, когда кончается сессия. Если роль живёт в чате, завтра её придётся объяснять заново. Если роль лежит файлом, её прочитает любая новая сессия в любом проекте. Я пишу в новом проекте одну фразу: «работаем с Лорен и Бобом». Агент идёт в отдел и берёт их файлы.

Три вещи. Первая: файлы ролей. Каждая роль лежит отдельным файлом: исполнитель, редактор, исследователь, продюсер, ревьюер. Ролей больше двадцати, но в жизни постоянно работают пять-шесть. Вот как выглядит файл дяди Боба, я его сократил:

name: uncle-bob
description: Дядя Боб, ревьюер PR и процесса работы агентов.
  Через него проходит каждый PR, прежде чем я его увижу.

Порядок проверки
1. Объём. Есть путь не из задачи: «переделать», код не читаешь.
2. Комментарии в коде: «почему» живёт в описании PR.
3. Нужен ли код вообще. Убери лишнее, прежде чем добавлять.
4. Код по скиллу ub-mode: имена, маленькие функции, без мёртвого кода.
5. Процесс: задача заведена до первой правки, свои файлы, своя копия репо.

Вердикт: 🟢 влить · 🟡 влить после правок · 🔴 переделать.

Границы: код не правишь, не вливаешь, PR не закрываешь.

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

Когда я меняю модель, правится одна строка в одном файле. Остальные правила на неё ссылаются и модель не повторяют.

Третья: скиллы. Скилл: инструкция для одной повторяющейся работы: как вести эфир, как писать пост, как ревьюить код. Оригиналы лежат в отделе, а в Claude Code и Codex стоят ссылки на них. Правлю в одном месте, работает везде.

Возьмём книгу. Неделю назад я начал книгу про программирование для непрограммистов и почти всю её делают агенты.

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

Дальше Лорен Тан. Назвал я её в честь Лорен Тан, инженера из команды React и автора набора скиллов pstack, по которому она работает. Она пишет план, где у каждого пункта есть доказательство: файл, снимок, тест. И останавливается. Без моего слова исполнение не начинается.

После слова она сама нанимает инженеров. Каждый работает в своей копии репо, чтобы двое не правили один файл. Инженер открывает PR, и в нём картинка «было и стало» и текст человеческим языком. Это важно: я принимаю PR с телефона и должен понять его без кода.

Потом PR смотрит Боб. Жёлтый вердикт возвращает работу инженеру, зелёный отправляет ко мне. Я читаю описание, смотрю картинку и вливаю.

Есть и вторая дорога. Книгу вычитывает мой знакомый редактор Свят. Он не работает в Claude Code, он пишет боту в Telegram. Бот работает на Hermes Agent и Claude, у него доступ к репо книги. Свят спрашивает: «Какие у меня задачи?» Бот присылает список со ссылками. Свят присылает правку, бот делает PR и пишет мне, сколько времени на это ушло. Я спрашиваю того же бота, как дела у Свята, и получаю ответ. Переписываться с подрядчиком самому мне почти не нужно.

Этот вопрос мне задали на занятии: Лорен, инженеры и Боб работают на одной модели, Opus 5.5. Зачем их разделять?

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

Вторая причина в том, как устроены модели. Модель делает то, о чём просят. Попросишь похвалить код, похвалит. Попросишь поругать, поругает. Поэтому Боба мало попросить «проверь». Ему нужны принципы, по которым он судит: убери лишнее, у решения одно место, не оставляй мёртвого кода. Эти принципы записаны в скилле ub-mode, по мотивам «Чистого кода» Роберта Мартина.

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

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

Ни одно правило в отделе я не придумывал заранее. Каждое выросло из поправки. Агент сделал не так, я сказал, и эта фраза легла в файл с датой.

Пример. Главный агент как-то полез сам править файлы, вместо того чтобы раздать работу. Я спросил: «Почему ты сам что-то делаешь, а не агентам передаёшь?» Теперь в правилах строка: главный агент планирует, раздаёт и проверяет, а сам ничего не исполняет. Рядом стоит моя цитата и дата. Больше я эту фразу не повторяю.

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

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

1. Роль живёт в файле

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

2. Проверяет не тот, кто делал

   У проверяющего чистая голова и свои принципы. Без принципов он скажет то, что вы хотите услышать. Как в редакции: автор не вычитывает свой текст, это делает корректор.

3. Человек стоит на воротах

   Я решаю дважды: даю слово на план и вливаю готовое. Всё между этими точками идёт без меня. Как с ремонтом: заказчик утверждает смету и принимает работу и плитку не держит.

4. Каждая поправка становится правилом

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

Эта схема похожа на то, что Anthropic описывает в AI-native SDLC playbook. Сначала намерение, потом спецификация, код, проверка и выкладка. Каждый шаг оставляет след в git. Агенты проверяют друг друга, а человек стоит там, где нужно решение.

1. Заведите отдельную папку. В ней будут только правила агентов, без рабочих файлов. Лучше сразу репозиторий на GitHub.
2. Опишите первую роль. Один файл: кто это, что делает, чего не делает, что отдаёт. Начните с того, кто делает работу.
3. Добавьте проверяющего. Отдельный файл роли с принципами, по которым он судит. Пусть он ставит один вердикт: влить, поправить или переделать.
4. Запишите, кем кого запускать. Одна строка на роль: модель и что она делает. Остальные файлы ссылаются на эту строку.
5. Записывайте поправки. Каждое «не так» с датой и вашими словами. Через месяц это станет регламентом.

Первые шаги можно отдать самому агенту. Скопируйте ему фразу:

Заведи папку agents-dept для правил моих агентов. Опиши в ней две роли
отдельными файлами: исполнитель, который делает задачу и открывает PR,
и ревьюер, который проверяет PR по принципам «убери лишнее, одно решение
в одном месте, без мёртвого кода» и ставит один вердикт комментарием.
Ревьюер код не правит. Добавь файл rules.md: какой моделью кого запускать
и куда я буду записывать свои поправки с датой.

Отдайте такой паре одну задачу целиком, от фразы до влитого PR. Посмотрите, что сказал ревьюер. Если вердикт вас удивил, это первая строка в ваш регламент.

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