Совет агентов

Вопрос, на который один агент отвечает плохо. Как устроен совет — и когда он не нужен.

Ситуация

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

Когда совет НЕ нужен

Начнём с этого, потому что это самый частый ответ.

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

Вопрос с известным ответом. Совет не находит фактов — он сталкивает позиции. Если ответ есть в документации, дешевле спросить поиском.

Спешка. Прогон совета — это несколько ролей, обсуждение и голосование. Это дольше одного агента, и заметно.

Нет спеки. Роли опираются на записанные решения. На пустом проекте они будут спорить в вакууме.

Совет оправдан там, где цена ошибки выше цены обсуждения, а вариантов больше одного.

Что делаете вы

Формулируете вопрос и критерий. По чему решение считается лучшим — иначе совет сойдётся к вежливому компромиссу.

Утверждаете решение. Итог совета — предложение, а не приказ. Опасные действия проходят через ваше подтверждение по построению.

Что делает агент

Сборка делается один раз, запуск — сколько угодно.

в сессии агента, один раз на проект

/harness-blueprint

Скилл проводит через опросник и собирает harness под ваш проект: harness_create, harness_add_role на каждую роль, harness_add_workflow_node и harness_connect_workflow_nodes на граф шагов, harness_set_policy на ограничения, harness_validate и harness_publish — на версию, которую можно запускать повторно.

в сессии агента, на каждый вопрос

Запусти harness <имя> с вопросом: чем хранить очередь задач —
таблицей в Postgres или отдельной очередью. Критерий: время до отказа
при потере воркера и стоимость эксплуатации.

Дальше harness_start_run, и роли работают своим циклом: work_claim — взять шаг, council_submit_proposal — предложить решение, council_submit_critique — разобрать чужое, council_respond_to_critique, council_cast_vote. Модератор сводит это в council_submit_judgement — решение с обоснованием.

Каждая роль — отдельная сессия агента со скиллом flownix-harness-participant (у модератора — flownix-harness-moderator). Прогон виден целиком в веб-интерфейсе.

Что получится

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

Прогон сохраняется целиком: роли, шаги, аргументы, голоса. Через месяц можно открыть и увидеть, на чём сошлись.

Границы

Совет не даёт истины. Он даёт решение с записанным обоснованием. Несколько ролей одной модели — не то же самое, что несколько независимых экспертов, и общее заблуждение модели совет не исправит.

Стоит дороже. Несколько ролей — это несколько прогонов модели.

Требует настройки под задачу. Роли по умолчанию годятся не для всего; harness-blueprint проводит через опросник именно поэтому.