180-240
през активните клиенти
~12 мин
поток от атомарни задачи
~10 ч
освободени
Мултиагентен диспечер - атомарни задачи от бриф до PR
Четири офиса, над двадесет активни клиентски ангажимента във всеки момент, стотици малки решения седмично. Цената се плаща на две места - вниманието на инженерите е разпокъсано през целия ден, а малкият, но постоянен процент изпуснати нишки руши доверието на клиента. Изградихме мултиагентен диспечер: Planner, който разбива всеки бриф на атомарни задачи, Scout, който избира следващата за изпълнение, Orchestrator, който насочва всяка задача към подходящия клас модел, и Executor, който отваря PR. Инженерът прави ревюто. Залогът е на 90-те процента, които инженерът не започва от нулата, а не на мечтата за автопилот без редакции.
180-240
през активните клиенти
~12 мин
поток от атомарни задачи
~10 ч
освободени
Последно обновено:
Данъкът от превключване на контекст за всеки инженер
Аутсорсинг компаниите работят в пресечната точка между "много едновременни клиенти" и "кратки цикли". За техните инженери всеки работен ден е парад от превключвания на контекста: чие репо, чии конвенции, чии заключени решения, кои задачи още стоят отворени от миналия вторник. Цената се плаща на две места - вниманието на инженерите е разпокъсано през целия ден, а малкият, но постоянен процент изпуснати нишки (пропуснат последващ контакт, изгубена задача, въпрос, който така и не получи отговор) руши доверието на клиента.
Компанията беше опитала работни потоци в Jira, отделни проектни мениджъри и седмични стендъпи през всички клиенти. Проектните мениджъри намалиха изпуснатите нишки, но добавиха слой забавяне към всяко решение. Инженерите искаха да минават директно от "бриф на задача" към "отворен PR", без да пишат задачи, описващи това, което тъкмо се канят да направят.
Това е същият мултиагентен модел, който изграждаме и за всичко останало. Причината компанията да извлича непропорционално голяма стойност от него е, че данъкът от превключване на контекст за всеки инженер е най-висок точно при техния вид работа.
Брифът
Диспечер, който инженерът управлява, който познава същите конвенции като инженера, който изпълнява рутинната работа и извежда на преден план интересните решения. Мултиагентна система със строго определен обхват, при която всяко действие завършва в pull request, ревюиран от човек.
Четири агента около файл със състояние
Архитектурата представлява четири агента около файл със състояние, който инженерът може да прегледа с един поглед.
Planner
Чете кратки бележки по задачите от директория за задачи на съответния клиент. Разбива всеки бриф на атомарни задачи - по една цел всяка, 5-30 минути работа, списък с проверими критерии за приемане за всяка задача. Изходът е версиониран набор от файлове със задачи със строг YAML frontmatter: id, зависимости, целеви проект, клас модел, timeout, максимален брой итерации, списък с разрешени инструменти. Графът е широк, а не дълбок - независимите задачи се разгръщат паралелно.
Scout
Чете файла със състоянието на задачите и избира следващата задача, чиито зависимости са всички `completed`. Работи върху малък локален модел - с едноцифрен брой милиарди параметри - така че тежките изчисления остават за реалната работа, а не за логиката на опашката.
Orchestrator
Насочва всяка избрана задача към подходящата среда за изпълнение според сложността. Вижте правилата за маршрутизиране по-долу.
Executor
Headless агентен цикъл, който изпълнява ЕДНА задача в даден момент. Чете файла на задачата, чете файла с проектния контекст, изпълнява стъпките по внедряване в обхвата, изпълнява всяка проверка по критериите за приемане, отваря PR с написано описание и уведомява отговорния инженер в Slack. Строга дисциплина по обхвата - никога не редактира файлове извън списъка на задачата, никога не рефакторира "докато е там", никога не пуша към main, никога не деплойва. Всеки критерий за приемане получава ред PASS или FAIL в резултата, преди статусът да стане `completed`.
Маршрутизиране от Orchestrator
Насочва всяка избрана задача към подходящата среда за изпълнение според сложността:
Редакции на файлове без състояние
Печатна грешка, конфигурация, търсене/замяна, документация, CSS - отиват към локален модел с отворени тегла, който работи върху хардуер, който притежаваме и управляваме. Без shell, без Bash. Безплатно на маржа.
Задачи, които изискват достъп до shell
Инсталиране, билд, тестове, редакции в няколко файла с проверка - отиват към водещ разсъждаващ модел с абонамент. Bash е разрешен, ограничен до списъка `allowedTools` на задачата.
Работа с архитектурен характер
Пет или повече файла, промени по схемата, граници на сигурността - получава по-големия разсъждаващ модел с по-висок бюджет за итерации.
Разделението не е заради цената. Всяка среда за изпълнение тук е с фиксирана цена за компанията. Разделението е заради възможностите - локалната среда е по-бърза и никога не таксува, но не изпълнява shell команди.
Поддържащи слоеве
Слой с контекст по клиент
Всеки клиентски ангажимент носи `project-contexts/<client>.md`, който описва архитектурата, конвенциите, капаните и заключените решения, специфични за този клиент. Executor чете този файл при всяка задача - не само в началото на сесията. Предпазването от замърсяване между клиенти е наложено на ниво маршрутизиране; Planner, който планира за Клиент A, никога не чете състоянието на Клиент B.
Файл със състояние
Един JSON файл е източникът на истината: статус на всяка задача (`pending` / `running` / `completed` / `failed` / `skipped`), времеви отпечатъци, произведените файлови артефакти и структурираният PASS/FAIL по всеки критерий за приемане. Инженерът го преглежда с един поглед; Scout го чете, за да избере следващата задача; повторните възпроизвеждания го четат, за да се дебъгне задача месеци по-късно.
Врати за одобрение
Executor отваря PR. Човек прави ревюто. Човек слива. Системата никога не слива автоматично, никога не деплойва, никога не пише на клиент. Всяка задача е ограничена от `timeout` (авариен стоп) и `maxTurns` (таван на цикъла); Executor, който достигне тавана си на итерации, маркира задачата като неуспешна чисто, вместо да опитва с часове.
Наблюдаемост
Пропускателна способност по клиент, процент слети PR-и, дълбочина на опашката, разпределение на времето до PR, тенденция в процента отхвърляния. Таблата сегментират по проект и среда за изпълнение - компанията вижда кои клиентски ангажименти разчитат силно на водещия модел и кои работят почти изцяло на локалния.
Четири фази - пилот, контекст, маршрутизиране, укрепване
- Shipped01Фаза 1 · Пилот с един клиент (първи месец)
Пуснахме Planner + Scout + Orchestrator + Executor върху един клиентски ангажимент, за който компанията вече беше дефинирала обхвата. Проверихме, че Executor създава PR-и, които инженерът приема да слее след леки редакции. Строгата дисциплина по обхвата отне две итерации - ранните Executor-и услужливо рефакторираха съседни файлове. Лимит за размера на diff-а на задача плюс по-стегнат промпт решиха проблема.
- Shipped02Фаза 2 · Контекст по клиент (месеци 2-3)
Добавихме слоя с проектен контекст. Процентът слети PR-и скочи веднага щом Executor научи конвенциите, стека и заключените решения на всеки клиент. Същият модел като дългосрочната памет на агентите - контекст, който агентът чете при всяко извикване, вместо да разчита, че е "научил".
- Shipped03Фаза 3 · Маршрутизиране между клиенти (месеци 3-4)
Planner поема разнородна опашка от задачи през всички активни ангажименти и произвежда конкретен седмичен план, подреден по приоритет. Разделихме паметта между клиентите, след като в една сесия за отстраняване на грешки Planner препоръча архитектура от един клиент на друг.
- Shipped04Фаза 4 · Операционно укрепване (текущо)
Строг валидатор на схемата на изходната граница на Planner, лимити за размера на diff-а при Executor, отчитане на разходите по клиент и предварително зададена политика за одобрение за всеки клиент (някои приемат пуш към feature клон; други изискват само PR). Добавихме тип задача `dryRun`, който извежда плана, без да променя файлове - полезно при задачи с висок залог, където инженерът иска да прочете плана, преди Executor да предприеме действие.
Трудностите, които срещнахме
- Изместване на обхвата. В началото Executor почистваше и съседен файл, "докато е там". Лимит за размера на diff-а плюс строга инструкция в промпта (Изпълнявай САМО това, което казва задачата, нищо повече и нищо по-малко) го върнаха в обхвата.
- Замърсяване между клиенти. Веднъж Planner цитира заключената архитектура на един клиент в плана на друг. Разделихме състоянието по проекти; всеки Planner вече чете директорията на точно един клиент.
- Отклонение в изхода на Planner. Качеството на JSON структурата се отклоняваше седмица след седмица. Валидатор на схемата на границата вече отхвърля лошите изходи и стартира отново с по-силен промпт.
- Несъответствие с критериите за приемане. В началото Executor маркираше задача като завършена с неопределено "изглежда добре" вместо с проверим резултат. Затегнахме го да изисква PASS/FAIL по всеки критерий, преди статусът да стане `completed`.
- Отчитане на разходите по клиент. В началото имаше една обща сметка за всички ангажименти; не можеше да се разпредели чисто по клиентска работа. Тагването по проект в Orchestrator направи месечното фактуриране към клиентите тривиално.
180-240 диспечирани задачи седмично, ~12 мин от бриф до PR при рутинна работа
Честният среден ред - 40% тръгват чисти, 50% се нуждаят от редакции, 10% са грешни - е реалистичният резултат от агентно редактиране на код през 2026 г. Залогът е на 90-те процента, които инженерът не започва от нулата, а не на фантазия за автопилот без редакции.
Искате ли този модел на диспечер за Вашия екип?
Мултиагентното диспечиране е една от автоматизациите с най-голям ефект, които изграждаме. 30-минутна диагностика покрива формата на Вашата инженерна работа, Вашите тесни места и дали моделът е подходящ за Вас.