Блок 5. opencode.json - permission (глобальные права)

Определяет, что агент может делать сам, что - только с твоего разрешения, а что - запрещено полностью.

"permission": {
      "read": "allow",
      "list": "allow",
      "glob": "allow",
      "grep": "allow",
      "edit": "ask",
      "bash": {
      "git status": "allow",
      "git diff": "allow",
      "git log*": "allow",
      "ls": "allow",
      "pwd": "allow",
      "rg *": "allow",
      "find *": "ask",
      "./gradlew *": "ask",
      "rm *": "deny",
      "kubectl delete*": "deny",
      "git push*": "deny",
      "git reset --hard*": "deny",
      "docker system prune*": "deny"
  },
      "webfetch": "deny",
      "websearch": "deny",
      "external_directory": "ask",
      "question": "allow",
      "todowrite": "allow",
      "atlassian_jira_*": "ask",
      "atlassian_jira_get_*": "allow",
      "atlassian_jira_search*": "allow"
  }

Три значения:
• "allow" (без спроса),
• “ask" (спросить),
• "deny" (запретить наглухо).

Логика всего блока:
- читать — свободно;
- менять файлы — только с подтверждением;
- деструктив — запрещён намертво;
- внешние системы — читать можно, писать только с подтверждением;
- запрет дублируется и на уровне tools, и на уровне permission.

Блок 6. opencode.json - agent (plan / build / reviewer)

Переписывает под-агентов - три профиля поведения с разными правами и промптами.

plan - безопасный анализ:

"plan": {
      "model": "",
      "description": "Безопасный агент для анализа, планирования и объяснения кода без изменения файлов и запуска команд",
      "temperature": 0.1, // почти детерминированный, минимум «фантазии»
      "steps": 30, // максимум шагов (итераций инструментов) за один прогон
      "permission": {
          "edit": "deny",
          "bash": "deny" // вообще не может менять файлы и запускать команды. Чистый read-only режим
      },
      "prompt": "Всегда отвечай на русском... Анализируй задачу, код и архитектуру без изменения файлов. Давай краткий план, риски и рекомендуемый минимальный вариант решения." // личная инструкция именно этому агенту
  }

build - рабочий агент:

"build": {
      "model": "",
      "description": "Основной рабочий агент для изменения кода, рефакторинга, исправления ошибок...",
      "temperature": 0.2,
      "steps": 30,
      "permission": {
          "read": "allow", "list": "allow", "glob": "allow", "grep": "allow",
          "edit": "ask",
          "bash": {
              "./gradlew *": "ask",
              "git status*": "allow",
              "git diff*": "allow",
              "ls*": "allow",
              "rg *": "allow",
              "pwd": "allow"
          }
      },
      "prompt": "Всегда отвечай на русском... Перед изменением кода сначала изучи существующую архитектуру. Предпочитай минимальные безопасные изменения. Не добавляй новые библиотеки без явной необходимости."
  }

reviewer - ревью изменений:

"reviewer": {
      "mode": "all",
      "description": "Агент для ревью изменений в ветке: анализирует git diff, ищет риски в Kotlin-автотестах и не изменяет файлы",
      "model": "",
      "temperature": 0.1,
      "steps": 40,
      "prompt": "Всегда отвечай на русском... Проводи ревью изменений относительно master. Используй git-команды для анализа diff. Не изменяй файлы. Разделяй замечания на: Критично, Важно, Можно улучшить...",
      "permission": {
          "read": "allow", "list": "allow", "glob": "allow", "grep": "allow",
          "edit": "deny",
          "task": "deny",
          "bash": {
              "rg *": "allow",
              "git status*": "allow", "git diff*": "allow", "git log*": "allow",
              "git branch*": "allow", "git rev-parse*": "allow",
              "git merge-base*": "allow", "git show*": "allow", "git ls-files*": "allow"
          }
      }
  }

Что касается второй части работы с opencode - AGENTS.md: существует огромное множество предзаполненных шаблонов инструкций для агентов в сети.

Можно использовать такой вариант wlasadd/claude-autotest-skills, а можно самостоятельно попросить подключенного агента изучить проект и сагрегировать некий набор шаблонов и практик, уже принятых за образец, и двигаться далее в том же стиле.

Не одним конфигурационным файлом для использования AI-агентов единым - попробуем создать свой подключаемый mcp-сервер на примере опенсорсного продукта rocket.chat вкупе с соответсвующим файлом-инструкцией AGENTS.md

rocket.chat - мессенджер, первый неструктурированный слой, в котором можно получить сообщение/тред с “проблемой”, ссылками на требования и прогоны тестов с ошибками. И не вникать в содержимое многочисленных рассуждений коллег самостоятельно.

Какой результат мы можем получить при условии такого сервера в связке с прочими mcp (например, allure, atlassian (jira, confluence, и тп)).
1. Читай. По ссылке/артефакту вызови getThread/getMessageContext и собери связное нейтральное описание (кто, что, шаги воспроизведения, договорённости).
2. Дедуплицируй до создания. Перед заведением задачи проверь, нет ли уже похожего тикета в таск-трекере и не помечен ли тред как обработанный. Не плоди дубли.
3. Верифицируй и обогащай. Если доступны MCP системы тестирования / базы знаний — подтяни подтверждающие прогоны и релевантный регламент с требованиями; добавь ссылки на них.
4. Фиксируй со ссылкой назад. При создании задачи всегда вставляй обратный permalink на исходный тред, плюс ссылки из шага 3.
5. Замыкай контур (write-back) — только с подтверждением. Ответ в тред / маркер «обработано» делает результат видимым в чате.

Поскольку вносимые изменения необратимы и «наружу», запрашивается явное подтверждение пользователя перед любой записью. Сам rocketchat-mcp write-back не выполняет — запись идёт через соответствующий инструмент или человеком.

Более подробно Цикл разработки как замкнутый контур MCP описан тут. Берем готовый репозиторий mcp-мессенджера rocketchat-mcp и пробуем.

Вакансия #aqa #autoqa #стажировка

Отклик - в директ канала

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

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

Все это наталкивает на мысль о необходимости унификации и принятии нового стандарта в отношении работы с агентами, а так же - в восприятии новой парадигмы работы над продуктом, где код больше не является предметной областью.

Выход: оркестрация - метазвено, которое само код не пишет, а декомпозирует задачу, делегирует субагентам, создаваемым на лету; а те, в свою очередь - обращаются к внешним mcp-серверам, библиотекам скиллов и RAG-ам, на версионность которых и смещается фокус.

Собираем агента-оркестратора, подключаем к нему mcp-сервер и библиотеку со скиллам той или иной версии в качестве шаблона/каркаса одного из новых звеньев разработки.

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

И замыкаем более верхнеуровневый новый цикл работы над продуктом.

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

Closed box -> Shift Right

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

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

То, что может казаться проблемой, с обратной стороны, является и преимуществом, поскольку в ином случае простор «мысли» модели оборачивается в жесткую рамку, превращая вариативность решения в подобие code-alike структуры с теми же условиями и ограничениями.

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

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

Оффтоп по откликам на вакансию
Все заявки отправлены
Ответы в отрицательных случаях не гарантируемы, но запрошены

Поднимаем абстракцию еще выше

Мы готовим инфраструктуру вокруг агента с версионированием - это разработка (context engineering)

Затем продумываем пайпы, по которым будет происходить взаимодействие процессов между собой - это девопс (delivery engineering)

И в конце собираем сценарии, проверяющие, что те или иные задачи по-прежнему решаются в пределах ожидаемого; поднимаем проекты, как тестовые данные - это тестирование (validation)

Продукт = способность системы решать задачи (ERS - Engineering of Reasoning Systems)

Вот так может выглядеть новая парадигма; а может не выглядеть - в этом нам еще предстоит убедиться или опровергнуть

#vacancy #computervision #hardwareengineer

Vision Hardware Engineer

AI-based quality control system for a production line in Thailand. The system inspects soft plastic packaging on a conveyor belt and detects defects such as tears, dents, deformations, and damaged packaging in real time.

Looking for an engineer with hands-on experience in:
-industrial cameras (Basler, FLIR, Hikrobot, etc.)
-lighting / optics / controllers
-conveyor / PLC integration
-machine vision setup for production environments

Tasks:
-HW procurement & purchasing
-business trips to SEA region (China / Japan )
-on-site installation & setup
-image quality optimization for AI inspection systems

All travel & equipment expenses covered by the company.

DM for CV

В подтверждение гипотезы о смене парадигмы работы с продуктом в эпоху агентной-инженерии вышел новый инструмент от JetBrains - Repository Intelligence - слой знаний над репозиторием.

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

Repository Intelligence - это попытка заменить бесконечное чтение файлов структурированным представлением знаний о системе.

Первый шаг среди примерно такой организации набора intelligence-ов:

├── Repository Intelligence
├── Runtime Intelligence
├── CI/CD Intelligence
├── Architecture Intelligence
├── Production Intelligence
├── Documentation Intelligence
├── Team Knowledge

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

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