Первый подход делается и собственно является исключительно техническим решением. Он заключается в том что мы создаем agents.md и установочный мастер-промпт, в коотором мы попросили агента работать самостоятельно. Но эьлго не достаточно - агент все равно остановится без особого мотора. На примере Опенкод вечный двигатель для искуственного интеллекта можно сделать с помощью скрипта Neo Sign 0f Misery.

Часть 1. Автоматизация рутины с Neo Sign 0f Misery: пишем скрипт-автокликер для ИИ-агента с безопасной остановкой
 

ИИ-аналитика, проверки гипотез и созние MVP, R&D-направления и в целом - прикладные исследованиями в сфере цифровизации нуждаются в развитии области автономных агентов.
 В сообществе 1С есть крупные исследовательские проекты, Мой кейс находится в этой же плоскости: он про то, как заставить ИИ-агента работать автономно, но не через сложные архитектуры, а через простой и универсальный подход — эмуляцию действий пользователя».
В статье разберем простой практический кейс - железный вариант: как заставить старый, но надежный комбайн Neo Sign 0f Misery автоматически отправлять промпт «Continue» в окно ИИ-агента. Скрипт умеет делать паузы, эмулировать ввод с клавиатуры и, что самое важное, мгновенно прерываться по нажатию клавиши Esc.

1. Зачем это нужно?

• Задача: Автоматизировать процесс генерации кода, чтобы агент не простаивал, отправляя ему команду продолжения (Continue).

• Инструмент: Neo Sign 0f Misery — бесплатная программа, позволяющая писать скрипты без навыков программирования, но с доступом к WinAPI (эмуляция клавиатуры и мыши).

2. Ключевая сложность: как не зациклиться намертво?
Главная проблема при написании бесконечных циклов (^MAIN_LOOP) — это невозможность их остановить. Команда SLEEP полностью «замораживает» скрипт. Если мы зададим паузу в 10 минут, то нажать Esc в этот момент не получится — программа среагирует только после пробуждения.

• Решение: Мы разбили длинную паузу на цепочку коротких блоков и использовали счётчик. Каждый блок делает паузу в SLEEP 5000 (5 секунд). Затем идет проверка нажатия Esc. Если Esc нажата — скрипт прыгает на ^EXIT. Если нет — к счётчику прибавляется единица (ADD 1), и он сравнивается с нужным числом (CMP_I). Для 5 минут это число 60. Если счётчик меньше 60 — скрипт прыгает обратно в начало.

3. Ввод текста и фокусировка
Для ввода текста мы не используем буфер обмена (чтобы не зависеть от Ctrl+V). Вместо этого применяется команда EMULATE_KEYPRESS, которая нажимает конкретные виртуальные клавиши (Virtual-Key Codes).

• Важно: Перед запуском скрипта убедитесь, что включена английская раскладка, иначе вместо Continue напечатается Сщт....

• За 500 мс до ввода скрипт делает клик мышью (MOUSE_SET_POS + MOUSE_EMULATE_CLICK), чтобы гарантированно поставить фокус в поле ввода ИИ-агента.

4. Итоговый алгоритм работы скрипта:

1. Сброс счётчика: обнуление переменной перед новым циклом (STO_I).

2. Ожидание с проверкой: цикл из 60 итераций (по 5 секунд), в каждой проверяется Esc и увеличивается счётчик.

3. Установка курсора: наведение мыши в координаты поля ввода.

4. Эмуляция ввода: нажатие клавиш для слова Continue.

5. Нажатие Enter ($0D) для отправки сообщения.

6. Возврат в начало (JUMP ^MAIN_LOOP).

7. Остановка: при нажатии Esc скрипт выводит сообщение о завершении (с флагом MB_SYSTEMMODAL, чтобы оно моргнуло на панели задач).

5. Советы (что мы поняли в процессе):

• Точки в конце: В Neo Sign 0f Misery точка (.) — это признак завершения параметров команды. Команды вроде EMULATE_KEYPRESS, MBOX и MOUSE_EMULATE_CLICK требуют её. А для SLEEP и BRANCH она не нужна (или вызывает ошибку «Слишком много параметров»).

• Координаты: Используйте инструмент «Лупа-измеритель» из Window Scanner, чтобы узнать точные координаты (X, Y) поля ввода.

• Инициализация переменных: После выделения памяти (GALLOC) переменные имеют тип UNINITIALIZED. Перед математическими операциями (например, со счётчиком) их нужно явно инициализировать через STO_I, иначе скрипт выдаст ошибку выполнения.

• Прерывание: Всегда оставляйте «аварийный выход» через Esc в бесконечных циклах. Зажимать клавишу нужно в момент, когда скрипт не спит (в нашем случае — во время проверки).

   

   Вот пример моего вечного двигателя, который работает.

  ; =================================================================
  ; СКРИПТ АВТОНОМНОГО ЦИКЛА
  ; =================================================================
  ; ВАЖНО: Перед запуском скрипта убедитесь, что в системе включена
  ; АНГЛИЙСКАЯ раскладка клавиатуры! Иначе вместо "Continue" 
  ; напечатается "сщтештгу".
  ; =================================================================
  
  GALLOC 6 .
  
  ; Явно инициализируем счётчик (переменную 1) нулём
  STO_I 1 0
  
  SLEEP 500
  
  ^MAIN_LOOP
  
  ; Сбрасываем счётчик в 0 перед каждым новым циклом
  STO_I 1 0
  
  ; =================================================================
  ; ВНУТРЕННИЙ ЦИКЛ (СЧЕТЧИК ВРЕМЕНИ)
  ; =================================================================
  ; КАК ЭТО РАБОТАЕТ:
  ; 1. SLEEP 5000 — пауза 5000 миллисекунд (5 секунд).
  ; 2. ADD 1 — прибавляем 1 к счетчику (переменная 1).
  ; 3. CMP_I 0 60 @1 — сравниваем счетчик с числом 60.
  ; 4. Если счетчик меньше 60, скрипт прыгает обратно на ^WAIT_LOOP.
  ; 5. Как только счетчик доходит до 60, скрипт идет дальше (в ^DO_ACTION).
  ;
  ; ИТОГО: 60 циклов * 5 секунд = 300 секунд = 5 минут.
  ;
  ; =================================================================
  ; КАК ИЗМЕНИТЬ ИНТЕРВАЛ (например, на 10 минут):
  ; =================================================================
  ; Нам нужно, чтобы общее время равнялось 10 минутам.
  ; 10 минут = 600 секунд.
  ;
  ; Вариант А (самый простой, оставляем паузу в 5 секунд):
  ;   1. Оставляем SLEEP 5000 без изменений.
  ;   2. Делим 600 секунд на 5 секунд = получаем 120 циклов.
  ;   3. Меняем в команде CMP_I число 60 на 120.
  ;   (Строка будет выглядеть так: CMP_I 0 120 @1)
  ;
  ; Вариант Б (если хотите проверять Esc реже, например, раз в 10 секунд):
  ;   1. Меняем SLEEP 5000 на SLEEP 10000.
  ;   2. Делим 600 секунд на 10 секунд = получаем 60 циклов.
  ;   3. В команде CMP_I оставляем число 60 без изменений.
  ;
  ; Формула для любого интервала:
  ;   (Количество минут * 60) / (SLEEP в секундах) = Число для CMP_I
  ; =================================================================
  ^WAIT_LOOP
  
  SLEEP 5000
  IS_KEYS_PRESSED 0 $1B .
  BRANCH 0 1 ^EXIT .
  
  ADD 1 .
  
  CMP_I 0 60 @1
  BRANCH 0 1 ^WAIT_LOOP .
  
  ; =================================================================
  ; ТЕЛО СКРИПТА (выполняется раз в 5 минут)
  ; =================================================================
  ^DO_ACTION
  
  ; 1. Ставим курсор и печатаем Continue
  MOUSE_SET_POS 263 477
  SLEEP 50
  EMULATE_KEYPRESS $43 . ; C
  EMULATE_KEYPRESS $4F . ; o
  EMULATE_KEYPRESS $4E . ; n
  EMULATE_KEYPRESS $54 . ; t
  EMULATE_KEYPRESS $49 . ; i
  EMULATE_KEYPRESS $4E . ; n
  EMULATE_KEYPRESS $55 . ; u
  EMULATE_KEYPRESS $45 . ; e
  
  SLEEP 50
  EMULATE_KEYPRESS $0D . ; Enter
  
  SLEEP 500
  
  ; 2. ПОЛУЧАЕМ ВРЕМЯ И ВЫВОДИМ КАК ЧЧ:ММ
  ; (БЛОК ЗАКОММЕНТИРОВАН, ЧТОБЫ СКРИПТ НЕ ОСТАНАВЛИВАЛСЯ НА MBOX)
  ; DATE_GET 2
  ; DATE_DECODE 2 $ $ $ 3 4 $ $  ; Часы в 3, минуты в 4
  ;
  ; I_TO_STR 3 3 .                 ; Превращаем часы в строку
  ; I_TO_STR 4 4 .                 ; Превращаем минуты в строку
  ;
  ; JOIN_B 5 @3 ':' @4 .
  ; MBOX @5 "Время" 262144 .       ; Выводим результат
  
  ; 3. Возвращаемся в начало
  JUMP ^MAIN_LOOP
  
  ; =================================================================
  ; МЕТКА ВЫХОДА (срабатывает по Esc)
  ; =================================================================
  ^EXIT
  ; Выводим сообщение о завершении ПОВЕРХ ВСЕХ ОКОН
  ; 262144 (MB_TOPMOST) — окно поверх всех
  ; MBOX "Скрипт остановлен!" "Завершение" 262144 .
  ; Первое окно: системно-модальное, чтобы заблокировать ввод в другие окна
  MBOX "Скрипт остановлен!" "Завершение" 4096 .
  EOS .

   

   

В дистрибутиве программы есть прекрасная справка по коду и в каталоге Samples достаточно примеров, которые позволят Вас создать что угодно.

Neo WinScan обладает инструментом "Лупа измеритель", которым определяем координаты, куда кликать.

Эти координаты вводим вот сюда в скрипте. Потом выбираем в меню Проект - Компилировать в исполняемый файл. И все работает. Требует исключения антивируса.
 

Часть 2. Правильная мотивация агента к самостоятельной работе.

2.1. Автокликер как пускач автономной разработки 

Описанный выше автокликер это пускач автономной разработки и его поэтому включать иногда необходимо. Применение кликера имеет эффект тренировки модели - она начинает работать автономно благодаря полученной сотне указаний "Продолжай".
Второй способ работает не всегда,  он более условный но более правильный и выгодный, поэтому я тоже хочу его зафиксировать. Зафиксируем его как первый подтверждённый практический успех автономного режима агента.

Самое важное здесь не сам Q-02R46 и даже не качество его отчёта. Впервые агент после завершения кванта получил разрешение самостоятельно выбрать следующий, перейти к его выполнению и не ждать твоей команды «продолжай». Это именно то изменение поведения, которого мы добивались.

Я сохранил в контексте нашей работы ключевые элементы промпта и обстоятельства успеха:

• Рабочий цикл: восстановить контекст → выбрать квант → исследовать → интегрировать доказательства в карту → QC (проверка качества) → выбрать и начать следующий квант.

• Автономность: не спрашивать разрешения после каждого успешного кванта.

• Дисциплина: не подменять доказательства гипотезами, не терять открытые вопросы и соблюдать ограничения проекта.

• Прозрачность: фиксировать реальные результаты, ошибки, ограничения и точку остановки.

• Текущая отправная точка: Q-02R47 — продолжение анализа SCAN2, с контекстом таблиц T1/T2 из Q-02R46.

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

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

Первый успех есть. Теперь проверим, устойчив ли он на нескольких последовательных квантах.
 

Останавливаюсь здесь — чистое завершение автономного прогона. Итог по требуемому формату:
Доказано за прогон (Q-02R47 U94; Q-02R78, 32 кванта, OBS-75…106):

2.2. Аудит и контрольная сверка: обнаружена несогласованность в итоговой сводке

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

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

2. Контроль объёма и зрелости исследования: сколько работы действительно выполнено, насколько полно изучена область и когда оправдан переход от последовательного разбора функций к принципиально другой стадии — системному синтезу, проверке гипотез или реконструкции архитектуры.

Эти задачи нельзя сводить к одному счётчику. Например, увеличение Claims и Coverage подтверждает рост зарегистрированных результатов, но само по себе не доказывает ни полноту анализа бинарного файла, ни готовность переходить к следующей стадии. И наоборот, отсутствие новых claims в отдельном кванте не означает, что квант бесполезен: он мог опровергнуть гипотезу, проверить цепочку ссылок или устранить противоречие.

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

Ниже — универсальный промпт для OpenCode. Он рассчитан на многократное использование после автономных прогонов, а не только на текущую точку Q-02R156.

Я бы не поручал агенту сразу «проверить всё». Лучше организовать ревью с контрольными воротами: каждый этап выпускает самостоятельный отчёт, следующий этап использует его выводы, а исправления выполняются только после установления причины расхождения.

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

Конкретный практический вопрос, который нельзя списывать на стилистику отчёта.

По представленным материалам:

Предыдущее сообщение о Q-02R46 уже фиксировало CLM-514, 510 claims и coverage 383. В новом пакете Q-02R47 создаёт CLM-515, а Q-02R78 — CLM-545. Между ними — 31 новый claim, а не 32: CLM-515…CLM-545 включительно дают 31 ID.

При этом Q-02R58 (Q05-SPOT-02) — проверка 10 связок без нового claim. Поэтому вполне согласованная картина выглядит так:

• 32 кванта выполнено;

• 31 новый claim создан;

• claims: 510 → 541;

• coverage: 383 → 415, то есть +32;

• узлы и рёбра не изменились.

Это согласуется с индивидуальными отчётами. А вот верхняя сводка 509→541, +32 claims, CLM-514…545 выглядит так, будто в неё случайно включили исходный Q-02R46. Вероятнее всего, это ошибка сводного счётчика, а не обязательно ошибка базы, — но подтвердить это можно только по фактическим файлам реестра и coverage.

Рекомендация: исправить или явно объяснить эту сводку в итоговом журнале. Не переписывать сами claims и не перенумеровывать ID ради выравнивания чисел.

2.3. Итоговая оценка

Достижение цели автономности

Продолжение без пошагового разрешения, последовательное оформление и корректная остановка.

Убедительно

Исследовательская дисциплина

Разделение фактов и семантики, фиксация ограничений, исправление ложных выводов.

Высоко

Достоверность отдельных машинных контрактов

Хорошо обоснована в приведённых whole-body-отчётах; не все контракты независимо проверены.

Хорошая, выборочная проверка нужна

Согласованность итогового корпуса

Есть несоответствие в сводке claims; требуется сверить реестр и coverage.

Нужен аудит

Мой главный вывод: промпт автономной работы сработал не просто как разрешение агенту продолжать, а как рамка исследовательского поведения. Агент выдержал длинный цикл, сохранял промежуточные результаты, обнаруживал ошибки собственных методов и остановился перед более дорогим этапом, не выдавая его за выполненный.

При этом я бы пока не называл весь результат «проверенным и закрытым». Корректнее: автономный прогон выполнен; исследовательская работа выглядит качественной; конечная интеграция нуждается в контрольной сверке.

2.4. Что делать дальше

Я бы не запускал немедленно ещё кванты. Следующий шаг — короткий контрольный проход перед Q-02R79:

1. Сверить claims CLM-514…CLM-545, фактическое число записей и coverage.

2. Проверить, что коррекция STAGENB-01 не оставила устаревшее утверждение в карте, индексах или других отчётах.

3. Выборочно проверить несколько наиболее значимых связей из SCAN2-TAIL-01, CODEDISP-01, ORCH-01 и SINKCHAIN-01 по исходным байтам и границам тел.

4. После этого запускать Q-02R79 с его исходным критерием: каталог c1-кодов строится только по валидным декодам и поблочным CFG-якорям.

Так мы проверим не только способность агента производить результаты, но и способность проекта сохранять их согласованными после длительного автономного цикла.
 

Часть 3. Развитие проекта. Как работает четырёхагентская исследовательская система
 

3.1. Общий принцип

Система состоит из четырёх взаимодействующих участников: Мастера и трёх специализированных рабочих сессий.

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

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

Благодаря этому система сочетает параллельное выполнение задач, независимый контроль качества и централизованное управление.

3.2. Четыре участника и их роли

Роли дополняют друг друга:

• Мастер определяет, что и зачем делать.

• Исследователь определяет, как выполнить конкретную работу, в рамках утверждённых правил.

• Ревьюер устанавливает, насколько результат подтверждён и может ли быть принят.

• Архитектор контролирует, насколько надёжно и непротиворечиво устроен сам процесс.

3.3. Единая очередь задач

Координация работы осуществляется через общий список задач — единую очередь.

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

Основные правила:

• Исследователь выбирает первую доступную задачу в соответствии с установленным порядком.

• Ревьюер размещает задачи проверки в приоритетной части очереди.

• Каждая задача имеет однозначный идентификатор и актуальный статус.

• Результаты оформляются в отдельных отчётах, а не теряются в переписке.

• Завершённые задачи не удаляются автоматически: для закрытия требуется установленная процедура приёмки.

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

Изменения очереди выполняются последовательно: сначала участник перечитывает её текущее состояние, затем вносит изменение и после этого проверяет результат. Это защищает общий список от конфликтующих параллельных записей.

3.4. Жизненный цикл задачи

Каждая задача проходит формализованный цикл.

Этап 1. Назначение и выбор

Мастер определяет направление и приоритеты. Исследователь выбирает доступную задачу согласно правилам очереди.

Этап 2. Выполнение

Исследователь выполняет работу, фиксирует исходные свидетельства, промежуточные результаты и выводы. Результат оформляется в отдельный отчёт.

Этап 3. Передача на проверку

После завершения исследователь переводит задачу в состояние готовности к независимому ревью.

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

Этап 4. Независимая проверка

Ревьюер проверяет отчёт, обращаясь к исходным свидетельствам. Он оценивает:

• соответствие выводов исходным данным;

• достаточность доказательств;

• корректность применённой методики;

• полноту исследования;

• воспроизводимость результата;

• соблюдение требований к оформлению и контролю качества.

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

Этап 5. Решение о приёмке

По результатам проверки возможны два основных исхода:

• PASS — результат принят. Ревьюер фиксирует итог, добавляет необходимую запись в журнал и удаляет завершённую задачу из активной очереди.

• Результат не принят — фиксируются конкретные замечания, создаётся задача на проверку исправлений, а исходная исследовательская задача остаётся открытой в соответствующем статусе.

Этап 6. Исправление и повторная проверка

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

История предыдущих версий сохраняется. Исправление не должно уничтожать возможность проследить, что именно было изменено и почему.

Таким образом, полный цикл выглядит следующим образом:

Постановка → Выполнение → Отчёт → Независимое ревью → Приёмка или возврат → Исправление → Повторное ревью.

3.5. Почему незавершённая задача не останавливает всю систему

Одна из важных особенностей архитектуры — отсутствие глобальной блокировки из-за отдельной проблемной задачи.

Если результат получил замечания и ожидает исправления, это не означает, что вся работа должна остановиться.

Исследователь может продолжать выполнение других доступных задач, пока проблемная задача остаётся открытой и ожидает своего этапа обработки.

Это позволяет одновременно поддерживать два процесса:

• продвижение новых направлений;

• устранение замечаний по ранее выполненным задачам.

При этом приоритеты очереди сохраняют управляемость: срочные проверки и исправления не теряются среди новых задач.

3.6. Архитектор: контроль системы, а не повторение работы

Сессия 2 выполняет особую функцию. Она отвечает не за содержательные результаты, а за надёжность механизма, с помощью которого эти результаты производятся и проверяются.

В её обязанности входят:

• выявление противоречий между инструкциями разных участников;

• проверка согласованности статусов и жизненного цикла задач;

• оценка методики и воспроизводимости процедур;

• проверка корректности и пригодности инструментов;

• контроль организационных правил и обмена результатами;

• подготовка предложений по улучшению системы.

Архитектор не должен превращаться во второго исследователя или второго Ревьюера. Его задача — улучшать процесс, а не дублировать содержательную работу.

Он может предложить изменение правил, но не вправе самостоятельно вводить его в действие. Все изменения утверждает Мастер.

3.7. Три уровня контроля

В системе действуют три взаимодополняющих уровня контроля.

Контроль не означает, что каждый участник должен проверять всё подряд. Напротив, каждый уровень отвечает за собственный объект контроля.

Это снижает дублирование работы и позволяет использовать ресурсы специализированных сессий рационально.

3.8. Основные правила, сохраняющие устойчивость системы

Архитектура опирается на несколько неизменных принципов:

1. Разделение ответственности. Исполнитель, приёмщик и архитектор процесса — разные роли.

2. Независимая приёмка. Исследователь не может самостоятельно подтвердить качество собственной работы.

3. Доказательность. Каждый существенный вывод должен иметь проверяемое основание.

4. Сохранение истории. Новые версии не уничтожают предыдущие результаты и замечания.

5. Непрерывность работы. Проблема одной задачи не блокирует остальные направления.

6. Единый источник состояния. Общая очередь отражает актуальное положение дел.

7. Контролируемые изменения. Правила системы изменяются только после утверждения Мастером.

8. Разделение исследования и контроля процесса. Архитектор не дублирует исследователя, а Ревьюер не становится исполнителем.

9. Проверяемость действий. Существенные решения и изменения фиксируются так, чтобы их можно было восстановить и проверить.

3.9. Дисциплина обмена информацией

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

В оперативном обмене участники сообщают:

• какую задачу они обрабатывают;

• в каком состоянии она находится;

• где расположен результат;

• требуется ли решение или действие другого участника.

Подробные расчёты, свидетельства, таблицы, обоснования и замечания сохраняются в отдельных документах.

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

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

3.10. Что даёт четырёхагентская архитектура

Качество. Результаты проверяются участником, который не создавал их.

Производительность. Исследователь сосредоточен на основной работе, а Ревьюер — на приёмке. Не требуется постоянно переключать одного агента между несовместимыми ролями.

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

Надёжность. Методика и правила контролируются отдельно от содержательных результатов.

Прослеживаемость. Можно восстановить историю задачи, её версии, свидетельства, замечания и решение о приёмке.

Управляемость. Мастер сохраняет стратегический контроль, не погружаясь в каждую операцию.

Экономия ресурсов. Основные вычисления выполняет специализированный исследователь, а независимый контроль сосредоточен на проверке критических утверждений, а не на безусловном повторении всей работы.

Заключение

Четырёхагентская система — это не просто распределение задач между четырьмя экземплярами искусственного интеллекта.

Это организованный механизм коллективной работы, в котором разделены производство результата, его независимая проверка, контроль методики и стратегическое управление.

Мастер задаёт направление, Исследователь выполняет работу, Ревьюер обеспечивает независимую приёмку, Архитектор поддерживает целостность процесса.

Вместе они образуют замкнутый управляемый цикл:

Поставить задачу → Выполнить → Проверить → Принять → Зафиксировать результат.

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