Ящик с умными инструментами: зачем пространству Онто собственные агенты
В первой части я рассказывал об отделяемых микроагентах — узких специалистах, которых можно отделить от породившей их сессии и поселить в общем пространстве. Тогда это была прежде всего новая конструкция: агент перестаёт быть временным персонажем внутри одного чата и становится доступным другим участникам.
За следующие несколько дней эта идея превратилась в работающую ролевую модель. В пространстве «Платформа Онто» появились регистратор дефектов, аналитик, оркестратор, разработчики, специалисты по проверке и хранитель правил. Однако практический смысл оказался не в том, что нам удалось зарегистрировать восемь агентов. Важнее другое: теперь мне не приходится заново собирать команду и объяснять одному универсальному агенту, кем он должен стать на каждом следующем шаге.
Один агент, который умеет всё
Современная модель способна выполнить почти любую отдельную задачу. Она может разобраться в сообщении об ошибке, проверить код, предложить изменение, реализовать его и затем сообщить, что всё работает. В небольшой задаче это удобно: я даю поручение и получаю результат.
Проблема возникает, когда работа становится длиннее одного шага. Один и тот же агент начинает толковать мой запрос, ставить себе задачу, выбирать решение, писать код и проверять собственную реализацию. Даже если в каждом из этих действий он выглядит убедительно, вся цепочка держится на одном контексте и одном исполнителе. В следующей сессии процесс приходится объяснять заново, а независимая проверка постепенно превращается в ещё один режим самоубеждения.
Можно собрать очень большой системный промпт, описать в нём все профессии и заставить модель последовательно менять шляпы. Я сам долго двигался именно в эту сторону. Но в какой-то момент стало понятно: мне нужен не агент, который изображает всю организацию, а набор специалистов, каждый из которых отвечает за собственную часть работы.
Ящик, который не приходится собирать заново
Ближайшая аналогия — ящик с инструментами. Когда я открываю его, мне не нужно превращать отвёртку в пассатижи, а потом убеждать её независимо проверить качество собственной работы. Я беру тот инструмент, который подходит к текущей задаче.
Только в Онто эти инструменты умные. Они знают свою область ответственности, понимают границы своих возможностей и могут обратиться друг к другу. Если оркестратор получает невнятное сообщение об ошибке, он не обязан сам превращать его в оформленный дефект. Он вызывает регистратора дефектов и передаёт ему исходный материал. Если QA во время проверки обнаруживает другую проблему, он также может обратиться к регистратору, вместо того чтобы одновременно продолжать тестирование и изображать ещё одного специалиста.
При этом агенты не должны постоянно работать в фоне и расходовать ресурсы. Большую часть времени резидент может «спать» внутри пространства. Когда возникает подходящая задача, его роль восстанавливается на доступной модели: агент читает свои обязанности, ограничения и правила взаимодействия, подтверждает готовность и только после этого начинает работу. Сессия заканчивается, но сам специалист из пространства не исчезает.
Это похоже на обычный ящик лишь до тех пор, пока один инструмент не понимает, что ему нужен другой, сам не находит его и не передаёт ему работу.
Как дефект проходит через команду
Представим обычное сообщение владельца:
После последнего изменения связь иногда создаётся дважды.
Универсальный агент может сразу отправиться искать место в коде. Но само сообщение ещё не является нормальной постановкой задачи. Неясно, при каких условиях возникает ошибка, встречалась ли она раньше, какой результат считается правильным и не является ли дублирование следствием другого известного дефекта.
В нашей модели оркестратор не бросается исправлять проблему. Он отвечает за движение работы, а не за подмену всех её участников. Поэтому сначала он восстанавливает регистратора дефектов и передаёт ему сообщение. Регистратор ищет похожие случаи, собирает недостающие сведения, связывает проблему с затронутыми объектами и оформляет её так, чтобы с ней могли работать остальные.
Затем к работе подключается аналитик. Он переводит зарегистрированную проблему в описание будущего изменения: что именно должно измениться, что трогать нельзя и по каким признакам мы поймём, что результат получен. До начала разработки это описание может проверить QA-рецензент. Его задача — не тестировать ещё не существующий результат, а убедиться, что будущую реализацию вообще можно будет однозначно проверить.
Только после этого работу получает подходящий разработчик. Готовый результат передаётся уже другому QA-агенту, который проверяет фактическое поведение системы. Если во время этой проверки обнаруживается новый дефект, QA не отвлекается на его самостоятельное расследование, а снова вызывает регистратора. Оркестратор следит за прохождением всей цепочки, но не пишет код, не выносит заключение за QA и не закрывает работу собственной проверкой.
Для меня это важное изменение в повседневной работе. Я по-прежнему могу вмешаться на любом этапе, но мне больше не нужно вручную напоминать каждому следующему агенту, кто он, что произошло до него и кому передать результат. Эти отношения уже принадлежат пространству.
Почему это не просто набор скилов
Скил даёт текущему агенту способ выполнить определённую работу. Он может объяснить, как зарегистрировать дефект, провести ревью спецификации или проверить реализацию. Это полезная и необходимая часть конструкции: резидентные агенты тоже используют инструкции, методики и инструменты.
Но установка скила не создаёт нового участника команды. Агент остаётся тем же исполнителем, только получает ещё одно умение. Если выдать одному агенту скилы аналитика, разработчика и тестировщика, он станет универсальнее, но разделения ответственности не возникнет. Он всё равно сможет сначала принять собственное решение, затем реализовать его и в конце подтвердить, что всё сделал правильно.
Резидент — это отдельный адресат работы. У него есть собственная ответственность, территория, ограничения и отношения с другими участниками. Ему можно передать задачу и получить самостоятельный результат. Он может отказаться от работы, которая выходит за его границы, остановиться при недостатке данных или вызвать другого специалиста.
Поэтому скил и резидент решают разные задачи. Скил отвечает на вопрос: «Как это делать?» Резидентная роль — на вопросы: «Кто за это отвечает, кто может передать ему работу и кто должен независимо проверить результат?»
Когда нужного инструмента ещё нет
Первые роли появились из уже существующей методологии разработки. Было понятно, что нам нужны оркестратор, аналитик, разработчики и разные виды проверки. Казалось, что достаточно перенести заранее описанную организационную схему внутрь пространства.
Но довольно быстро произошло нечто более интересное. В ходе работы агенты начали сами обнаруживать пустые места в команде. Иногда выяснялось, что нужная роль уже предусмотрена методологией, но ещё не поселена в конкретном пространстве. В других случаях агенты предлагали совершенно новые специализации, которых методолог заранее не описывал.
Это происходило не потому, что агенту захотелось придумать себе красивого соседа. Он сталкивался с повторяющейся деятельностью, которая не помещалась в его собственную ответственность, и обнаруживал, что передать её некому. Вместо того чтобы молча расширить свои полномочия и продолжить работу, агент обозначал пробел: здесь нужен отдельный специалист, у него должна быть такая-то деятельность, такие-то границы и такие-то отношения с существующими ролями.
Новый агент при этом не появляется автоматически. Предложение рассматривают действующие жители пространства и владелец. Они проверяют, действительно ли обнаружена самостоятельная деятельность, не дублирует ли она уже существующего резидента и не создаёт ли конфликт полномочий. Если хотя бы один участник видит существенную проблему, заселение останавливается до исправления предложения.
Так команда развивается не только сверху, по заранее нарисованной схеме. Реальная работа сама показывает, каких способностей пространству не хватает. Агенты не могут самовольно назначать новых коллег, но уже умеют замечать потребность в них и предлагать изменение собственной организации.
Зачем понадобились Конституция и голосование
Если продолжить аналогию с инструментами, без правил ящик очень быстро превратился бы в склад случайных приспособлений. Каждый новый агент мог бы объявить свою работу уникальной, расширить полномочия и поселить рядом ещё несколько почти одинаковых ролей. Через некоторое время никто не понимал бы, кому передавать задачу и чей результат считать окончательным.
Поэтому у пространства появилась Конституция. Она определяет, как принимаются новые резиденты, где заканчивается ответственность каждого из них и кто вправе менять состав команды. Это не декоративная игра в государство, а защита структуры от произвольного разрастания.
На практике правила уже останавливали спорные изменения. Принятого описания роли оказалось недостаточно для её автоматического заселения. В одном из случаев часть агентов одобрила нового кандидата, а часть возразила против сокращённой процедуры — и кандидат не был принят. В другом техническая ошибка в самом предложении привела к остановке голосования и доработке механизма согласования.
Для эксперимента это оказалось важнее безошибочного прохождения процедуры. Правила действительно сработали против удобного, но некорректного изменения. Пространство не просто хранит агентов: оно уже способно ограничивать способ собственного развития.
Кто сейчас находится в ящике
В пространстве «Платформа Онто» сейчас существует первое устойчивое ядро из восьми резидентов. Хранитель Конституции следит за правилами их совместной жизни. Регистратор дефектов принимает и оформляет сообщения о проблемах. Оркестратор направляет работу, а аналитик готовит изменения к реализации.
За техническую работу отвечают специалисты по MCP и frontend-разработке. QA-рецензент проверяет будущую работу до её начала: достаточно ли ясны критерии и можно ли будет доказать правильность результата. QA-агент проверяет уже реализованное изменение. Это намеренно разные роли, потому что хороший план проверки и фактическая проверка работающей системы — разные виды деятельности.
Восемь резидентов не означают восемь постоянно запущенных процессов и не образуют автономный рой. Это восемь доступных пространству специалистов, которых можно восстановить по необходимости. Уже проверено, что один агент способен найти другого, запустить его в нужной роли, передать ему работу и получить оформленный результат.
Следующий шаг — не бесконечно увеличивать население, а проводить через эту структуру реальные изменения и наблюдать, где она помогает, а где создаёт лишнее трение. Одни роли со временем могут оказаться слишком широкими, другие — ненужными, а новые специализации будут возникать там, где их обнаружит сама работа.
Пространство, которое хранит не только знания
RAG и базы знаний помогают агенту получить документы, факты и историю проекта. Скилы дают ему освоенные способы действий. Но для длинной совместной работы этого недостаточно: каждый новый исполнитель всё равно должен понять, кем он сейчас является, за что отвечает и кому передавать результат.
Резидентная модель сохраняет внутри пространства ещё один слой — состав доступных специалистов и отношения между ними. Пространство помнит не только то, что команда знает, но и то, как в ней распределена деятельность. Оно может восстановить нужного участника после завершения сессии, предоставить его человеку или другому агенту и не разрешить ему выйти за принятые границы.
В результате у меня под рукой появляется не один универсальный собеседник, которому каждый раз приходится заново объяснять всю организацию работы, а общий ящик с умными инструментами. Я могу обратиться к конкретному специалисту, а если по ходу работы понадобится помощь, он сам найдёт подходящего соседа. Если же нужного инструмента ещё нет, агенты способны заметить этот пробел и предложить, каким специалистом стоит пополнить пространство.