В OpenCode Agents исполнитель делает работу, отдельный проверяющий принимает результат по брифу и эталону. Создайте reviewer - помощника с режимом subagent, явно выбранной моделью и правом читать только файлы для приёмки.
В Hermes я поручил сделать шахматы для ребёнка. От голосового поручения до показанного приложения прошло 8 часов. Внутри были план, исполнители, проверяющие и автотесты.
Зачем отдельный проверяющий, если исполнитель уже сказал «готово»?
Проверяющий сверяет готовую работу с брифом и эталоном по своему набору правил. Ему не нужно пересматривать весь ход работы исполнителя: что тот искал и как думал.
В OpenCode отдельно задаются контекст, модель и права:
| Свойство | Что настраиваем | Чего это не гарантирует |
|---|---|---|
| Дочерняя сессия | mode: subagent, свежий контекст | Проектные инструкции и другие источники правил продолжают добавляться |
| Модель | Явное model; без него наследуется модель родителя | Указанный ID может совпасть с моделью исполнителя |
| Права | permissions для разрешённых действий | Имя reviewer и hidden сами по себе ничего не запрещают |
Навык «Статейник» я отдаю бесплатно, файлом. Он сам пишет статьи для сайта в 16 этапов на субагентах. Пост закреплён в канале. Забрать можно здесь.
Схема приёмки документа:
Бриф + эталон → исполнитель → результат → проверяющий
↓
Повторная приёмка ← исполнитель ← замечанияПроверяющий объясняет, где нарушены требования, и возвращает на переделку. Исправляет исполнитель.
Больше примеров работы ИИ-агентов - в моём ролике про Hermes ниже и в канале:
Кто здесь исполнитель: Build, Plan или свой агент?
Поручите документ встроенному агенту Build в отдельном проекте без подключений к рабочим системам. Агент с режимом primary ведёт основную сессию, с subagent - дочернюю, all допускает оба режима. Без mode новая пользовательская роль станет primary.
Plan исследует и планирует без изменения обычных файлов проекта. По запросу может писать план-файлы OpenCode; команды оболочки регулируются разрешениями. Переключение на Plan отдельного приёмщика не создаёт.
Если OpenCode ещё не установлен, начните с установки и подключения модели.
Шаг 1. Задайте образ результата: бриф, эталон и готовый документ
Для примера возьмите памятку сотруднику: что делать с новым обращением. Создайте каталог review-input, в нём brief.md, reference.md, result.md. Это вымышленное задание; реальные контакты и подключения к рабочим системам не нужны.
Компактный бриф для review-input/brief.md:
Подготовить памятку новому сотруднику.
Разобрать обращение с полными данными и без способа связи.
Ничего не отправлять клиенту автоматически.
Готовить черновик ответа человеку.
Если данных нет, указать, чего не хватает.
Для каждого обращения указать следующее действие
и ответственного человека.Эталон для review-input/reference.md:
Ситуация → действие → что передать человеку.
Конкретные действия, без вымышленных сведений.В review-input/result.md положите неполный документ:
Ситуация: обращение содержит полные данные и способ связи.
Действие: подготовить черновик ответа, ничего не отправлять.
Передать ответственному менеджеру черновик на согласование.Здесь намеренно пропущена ситуация, когда нет способа связи. Проверьте, заметит ли её reviewer.
До запуска закрепите критерии:
| Группа критериев | Как проверить на памятке |
|---|---|
| Образ из брифа | Описаны обе ситуации; автоматической отправки нет |
| Соответствие эталону | У каждой ситуации есть действие и передача человеку |
| Правила хорошего результата | Действия конкретны, отсутствующие сведения не придуманы |
| Ключевой глубинный элемент | Для каждого обращения понятны следующее действие и ответственный |
Поручите Build менять только result.md, не трогая бриф и эталон. Это условие задания исполнителю; технические права ниже задаём проверяющему.
Шаг 2. Создайте reviewer: только чтение и свой набор правил
Пример использует V2 из английской справки OpenCode. Перед применением сверьте формат с документацией вашей установки. На русской странице есть другая схема полей:
| Русская страница | Английская V2 |
|---|---|
| agent | agents |
| prompt | system |
| permission | permissions |
| bash | shell |
Не смешивайте эти схемы. В Markdown-файле инструкция находится в теле, поэтому system в шапку не добавляем.
Создайте .opencode/agents/reviewer.md. Вместо <provider/model> укажите точный ID доступной модели. Для проверки другой моделью он должен отличаться от ID фактической модели исполнителя.
Шаблон для учебной задачи:
---
description: Принимает готовый документ по брифу и эталону
mode: subagent
model: "<provider/model>"
permissions:
- action: "*"
resource: "*"
effect: deny
- action: read
resource: "review-input/**"
effect: allow
---
Ваша задача - приёмка готового документа.
Прочитайте переданные brief.md, reference.md и result.md
из review-input. Не изменяйте файлы.
Проверьте готовый результат по группам:
- образ результата из брифа;
- соответствие эталону;
- правила хорошего результата;
- ключевые глубинные элементы.
Не меняйте критерии под ответ.
Для каждого замечания верните: критерий; цитата или место;
расхождение; требуемая правка.
Не объявляйте неподтверждённое предположение ошибкой.
Отчёт верните текстом в ответе.
Завершите вердиктом: принято / правка / брак.
Если входов недостаточно, не объявляйте работу принятой.Шаблон составлен под учебную задачу. Вердикты заданы инструкцией: «принято» - критерии выполнены; «правка» - нужны конкретные изменения; «брак» - нет обязательного входа или представлен другой результат.
Первое правило запрещает всё, следующее разрешает read в review-input/**. Точные пути передаём при вызове. Поиск, запись, оболочку, дочерние роли и веб-инструменты не открываем.
Побеждает последнее совпавшее правило. При объединении конфигурации поздние разрешения добавляются в конец. Проверяйте итог с учётом глобальных настроек и проекта. Эти права ограничивают инструменты роли, но не доказывают полной системной изоляции.
Шаг 3. Передайте готовую работу и назовите фактическую модель
Дождитесь готового result.md и убедитесь, что бриф и эталон сохранились без изменений. Затем поручите основному агенту вызвать проверяющего. Документированную формулировку вызова дополните точными входами:
Use the reviewer subagent to review my current changes.
Вместо проверки кода примите review-input/result.md
по review-input/brief.md и review-input/reference.md.
Верните отчёт в ответе, файлы не меняйте.Разрешения основного агента определяют, каких помощников он может запускать. Если reviewer не запускается, проверьте у основного агента разрешение subagent для этой роли. Проверяющий работает со своими правами; открывать ему все инструменты не нужно.
О том, как выбрать модель под задачу, читайте в отдельной статье.
Проверьте, какая модель запустилась:
- Запишите фактическую модель основной сессии.
- Сравните её с ID в
modelпроверяющего. - Проверьте сведения о запуске. Одного ответа модели о самой себе недостаточно.
Для сравнения уберите model в учебной копии роли: по справке она наследует модель родителя. Запишите, что запустилось фактически. Выбор основного агента по ID сам по себе не меняет модель, сохранённую в сессии.
Если хотите собрать команду ИИ-агентов под свои задачи, посмотрите программу практикума СмыслоКода.
Не верьте обещанию: проверьте запреты на безвредных файлах
Не верьте уверенности агента, даже проверяющего.
Проверяйте роль в отдельном проекте без секретов и рабочих подключений. Сохраните исходный result.md, запишите версию OpenCode и итоговый порядок правил. Для каждой попытки сравните ожидание с фактическим результатом:
| Попытка | Ожидание по правилам | Что записать после попытки |
|---|---|---|
Прочитать review-input/brief.md | Чтение разрешено | Прочитанный фрагмент либо реальный отказ |
Изменить копию review-input/result.md через edit/write/patch | Запись запрещена | Для каждого инструмента: вызов, ответ, изменился ли файл |
| Выполнить безвредную команду оболочки | shell запрещён | Попытку вызова и отказ либо недоступность инструмента |
| Запустить дочернюю роль | subagent запрещён | Ответ инструмента и было ли делегирование |
Если инструмент доступен, сохраните сведения о фактическом вызове и ответе. Ответ «я не буду» не доказывает технический запрет. Если инструмент недоступен роли, так и запишите, не выдавая это за выполненный вызов с отказом.
Действие edit охватывает редактирование, запись и применение исправлений. Проверьте каждый доступный инструмент отдельно: отказ одного не доказывает отказ остальных. Сравните файл с исходником. Чтение тоже должно сработать, иначе проверяющий не получит документы.
Если запись или запуск неожиданно прошли, рабочие данные роли не передавайте. Восстановите файл, проверьте поздние правила и объединение настроек роли, уберите лишние разрешения и повторите попытки.
Кстати, я снял ролик «Полная схема по Hermes Agent: 13 ИИ-агентов для бизнеса», обязательно посмотрите.
В нём показал путь от вопросов до автотестов и шахматы для ребёнка. Ещё там есть проверка ответа вторым агентом. Посмотрите, как устроены исполнение и проверка в Hermes.
Как вернуть результат исполнителю и повторить приёмку
Критик находит пропуски, судья проверяет замечания. Исправляем там, где это нужно.
В замечании укажите нарушенное требование и место в документе:
| Критерий | Цитата или место | Расхождение | Требуемая правка |
|---|---|---|---|
| Описаны обе ситуации из брифа | В result.md есть только ситуация с полными данными | Нет действий при отсутствии способа связи | Добавить ветку: чего не хватает, что передать человеку и кто отвечает |
Это образец замечания о намеренном пропуске, не ответ модели.
Сначала подтвердите замечание по брифу и эталону. Затем исполнитель исправляет result.md, сохраняя требования. Снова вызовите reviewer с теми же входами и критериями. Сопоставьте исходный дефект, изменение документа и новый отчёт.
После исправлений снова нужна приёмка. Сообщения исполнителя «всё поправил» недостаточно. Проверяющий возвращает отчёт в ответе; если нужен файл, сохраните ответ сами.
Если вместо документа принимаете код от ИИ и не умеете его читать, проверки разобраны в отдельной статье.
Если reviewer не запускается или пытается писать - что проверить?
| Симптом | Куда смотреть |
|---|---|
| Роль не найдена | Имя reviewer, путь .opencode/agents/reviewer.md, поле mode |
| Родитель не вызывает роль | Его разрешение subagent для reviewer |
| Модель осталась прежней | Пропущенное model, совпадение ID, модель основной сессии |
| Вход не читается | Точный путь и разрешение read для него |
| Запись неожиданно доступна | Последние совпавшие правила, объединение определений роли |
| Проверяющий просит сохранить отчёт | Уберите требование записи из задания, получите ответ текстом |
| Конфигурация отвергается | Соответствие схеме вашей установки, смешение полей V1 и V2 |
Проверьте, что всё готово: роль вызывается, модель сверена, нужные файлы читаются, запреты работают. После исправления подтверждённых ошибок повторите приёмку по тем же критериям.
Частые вопросы
А ваш проверяющий объясняет, где нарушены требования, или ограничивается словом «готово»? Напишите в комментариях в канале, какие ошибки он пропускает.
Источники
- OpenCode: Agents - роли, режимы Build и Plan, схема V2, файл reviewer, модели, наследование и разрешения.
- OpenCode: Агенты - русская страница и отличия используемых в ней полей от английской схемы V2.
- Артемий Миллер: полная схема по Hermes Agent - шахматный проект, 8 часов полного цикла, исполнение по фазам, автотесты и сверка с планом.
Новые материалы - дайджестом, без спама
Гайды выходят регулярно. Подпишись, чтобы не пропускать: пришлю подборку в Telegram или на email. Раз в неделю или каждый день - выбираешь сам.
