Про корпоративных агентов Физически ваши корпоративные агенты - это программы, запущенные на отдельном сервере, каждый со своим рабочим дисковым пространством и какими-то окнами (шлюзами) для взаимодействия с внешним миром. В моей реализации одного сервера хватает на то, чтобы запустить примерно 30-40 агентов параллельно. Ниже рассказываю про уровни организации их работы. Начальный уровень — это сами агенты как юниты. Тут решаются такие вопросы: - на основе каких LLM (типовые коммерческие, или средние опенсорсные) они работают? - в какой оболочке (Claude Code, Codex, OpenCode, Coddy, OpenClaw и т.д.) и как она кастомизирвоана (хуки блокирования опасных операций, запреты на отображение запрсов, блокирующих диалог и т.д.)? Как аналогия для организации: здесь вы определяете кого вы к себе берете: джунов, миддлов или сеньоров. И какие рабочие места им даете, насколько они удобны и подходят именно под эти LLM, с учетом особенностей их обучения. Я пока что использую “топов”: модели Anthropic в оболочке Claude Code, с возможностью кастомизировать настройки, чтобы агенты не были заточены только на код, но могли работать и более творчески. Далее уровень общей инфраструктуры многоагентных систем. Это набор программ, которые в целом на сервере следят за агентами и взаимодействуют с ними по расписанию или событиям, и отвечают, в том числе, за следующие области работы: - как они между собой общаются - как они сохраняют и потом восстанавливают свою долговременную память - как и когда они чистят контекст, чтобы находиться в зоне максимальной эффективности и не жечь лимиты впустую Эта инфраструктура должна позволять им работать автономно неделями и месяцами, активируясь в любой момент, когда нужно, и при этом продолжать работать хорошо. Следующий уровень — "организационная адаптация" под задачи. Здесь уже смотрится под какие задачи создается пул агентов, строится их "оргструктура", иерархия, специфицируются “должностные инструкции”. Плюс согласуется порядок коммуникаций с людьми: ТГ-боты и групповые чаты, аккаунты в Битриксе, страницы и доски в Notion для всяких канбанов, почты и т.д. Предпоследний уровень — интеграция с вашими системами, позволяющий агентам что-то делать конкретно в вашей среде: доступы к вашим ERP, CRM, DWH и прочему. Например, у пулов разработки это доступы к серверам, к фермам для тестирования моб.приложений, сервисам сборки, репозиториям и т.д. Возможность внедрять ИИ-агентов в рабочие процессы отчень сильно зависит от того, насколько доступны ваши системы через API или вспомогательные скрипты. И заключительный слой — слой самонаблюдения. Здесь отдельные алгоритмы и даже отдельные агенты следят за тем, как работают сами агенты: не флудят ли, правильно ли следуют процедурам, не жгут ли лимиты впустую, соответствует ли работа поставленной задаче, есть ли отклонения и т.д.

Мой агент лучше твоего (нет) Вчера был забавный эпизод. Глеб Михеев опубликовал пост про найденную уязвимость. Я, не вчитываясь, форварднул его своему агенту-супервайзору, тот сказал, что это фишинг. Я процитировал ответ Глебу. Глеб прислал мне скрины его агента с ответами для моего агента. Я их своему также форварднул, мой признал, что был неправ. Было явное ощущение, что кто-то в этой цепочке лишний. Тем временем готовлю пост про слои работы по разворачиванию корпоративных агентов, которые постепенно переключают на себя бизнес-процессы без стресса для компании.

Цех.ai: как мы развернули полный цикл разработки на ИИ-агентах в проекте “Собеседники” Предыстория В проект уже было вложено более десятка миллионов рублей, продукт был запущен (мобильные приложения на iOS и Android и общий бэкенд). Но продукт нишевой, много денег там не ожидается, продолжать разработки и эксперименты за такие деньги нет никакого смысла. Что сделали Более десятка агентов, организованных в специальной обвязке, живущие автономно на отдельном сервере с красноречивым названием “цех”. Они выполнили приемку проекта, развернули инфраструктуру разработки и тестирования, и уже реализовали несколько спринтов, выпустив новые версии как серверного бэкенда так и самих мобильных приложений. Было интересно: будет ли оно работать так, как об этом пишут в прессе. Да, работает. Но не 100% автономно. Во главе “цеха” – квалифицированный тим-лид (человек), который ставит задачи, принимает ключевые решения и следит за ритмом разрабоки. Тратит пару часов в день, не больше. Коммуникации с цехом через 2 канала: - Группа в телеграм, где каждый топик - это “отдел” команды разработки (“бизнес-аналитика”, “инфраструктура”, “разработка”, “тестирование” и т.д.). Здесь тим-лид общается с “цехом” в свободном режиме (текст, голос) - Страница в Notion, где организованы дашборы спринтов (доски “канбан”, тикеты и вот это все) - через них тим-лид видит детали по каждой задаче, и общается через статусы, комментарии и формальные аппрувы тех или иных операций. Агенты цеха работают с Notion через API, отображая там все шаги и запрашивая аппрувы на различные действия: включение фич в спринты, старты спринтов, слияния веток и т.д. Как это происходило Первая версия “цеха” была организована плохо, границы полномочий определены плохо, коммуникация с тим-лидом организована плохо. В итоге каждый “отдел” брался за все, запускал субагентов и выжигал лимиты ночью, пока я спал. Этот беспредел остановили путем четкой спецификации зон ответственности для каждого “отдела”. После этого агенты стали работать более организованно, но начали закидывать тим-лида кучей предложений и предупреждений в ТГ, и сами включать эти фичи и фиксы в свои спринты, при этом каждый отдел находился в “своем спринте”, это тоже превратило разработку в хаос. В этой ситуации мы ввели довольно жесткую бюрократию через Notion: запросы, тикеты, супервайзоры и т.д. “Отделам” запретили прямое общение между собой, только через “официальные запросы” через Notion. Тим-лид начал общаться только с агентом-супервайзором (условно “главой цеха”), а тот уже распределял задачи между “отделами” согласно спецификации полномочий. В этой конфигурации процесс перестал разбалтываться и вышел на целевой уровень результативности. Считаю, результат можно тиражировать. Уже работает “командный ассистент”, а теперь уже и более сложный замкнутый цикл разработки.