Как работать с агентами

Представь небольшую команду разработки. Один участник изучает задачу, другой предлагает решение, третий ищет ошибки, затем команда пишет код и проверяет результат. В курсе эти роли выполняют ИИ-агенты, а порядок работы поддерживает BSL Flow Managed.

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

Core и Managed: что выбрать

Начиная с версии 0.9, BSL Flow разделён на два пакета:

Пакет	Как ты работаешь
Core	Вместе с текущим агентом выбираешь отдельные навыки: подготовить спецификацию, проверить её, реализовать изменение или найти ошибку. Это режим assisted
Managed	Поручаешь задачу контроллеру через 1c-task. Он ведёт этапы, сохраняет состояние и проверяет результаты перед приёмкой

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

Для трёх проектов этого курса нужен Managed: мы учимся проходить полный цикл, менять требования и передавать работу без потери состояния. Core подходит для отдельных упражнений, но не заменяет контроллер и обязательный консилиум. Установка пакетов оставляет проект в Core; каждый управляемый запуск нужно запросить явно.

За что отвечаешь ты

Твоя задача — объяснить, что должно получиться, задать ограничения и принять результат. Например: «При нехватке товара используй разрешённые аналоги. Если весь заказ собрать нельзя, ничего не списывай».

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

От задачи до результата

Работа строится на спецификации — документе, который описывает нужное поведение и способы его проверки. Такой подход называют SDD, разработкой на основе спецификации.

1. Исследование. Агент выясняет, как устроен проект и что уже можно использовать.
2. Спецификация. Описывает правила, границы изменения и ожидаемые результаты.
3. Проверка решения. Независимый рецензент ищет пробелы и противоречия. Для рискованных задач это делает группа рецензентов — консилиум, или Council.
4. Реализация. Исполнитель меняет код по согласованной спецификации.
5. Проверка кода. Рецензент оценивает изменения и достаточность подготовленных тестов.
6. Тестирование. Выполняются разрешённые проверки, сохраняются их результаты.
7. Сдача. Ты получаешь описание изменений, результаты и оставшиеся ограничения.

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

Зачем нужен консилиум

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

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

Как оценивать проверки

Допустим, агент пишет: «Стоимость отгрузки — 560, всё верно». Но по условиям товар B должен сначала достаться строке, в которой заказан B. Итоговая сумма этого не показывает. Нужно увидеть распределение по исходным строкам.

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

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

Что происходит при изменении требований

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

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

Что получить в конце

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

• согласованную спецификацию и важные решения;
• изменения кода и разобранные замечания рецензентов;
• выполненные проверки с ожидаемыми и фактическими результатами;
• оставшиеся ошибки и непроверенные условия.

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

В отчётах используются три обозначения: ACCEPT — результат принят, REJECT — обнаружено несоответствие, BLOCKED — обязательную проверку или этап выполнить пока нельзя.

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