Мелкая, но супер полезная строчка в конфиге OpenCode

24 апреля24 апр

2 мин

Вайбкодил некоторого агента, в качестве ядра был выбран OpenCode cli в режиме serve. Главная задача была - добиться максимально быстрой генерации документов. К сожалению, на топовых моделях оптимизация почти незаметна, думают и делают долго, на 10 минутных сессиях экономия в 10 секунд мало что даст, но всё же нашел один момент, который повышает стабильность работы и избавляет агента от лишних движений. По умолчанию, что claude code cli, что opencode, могут в процессе выполнения запроса возраждать себе сабагентов, даже если вы не добавляли их в систему. Они сами решают, когда задачу стоит разбить на этапы и часть этапов отдать в работу сабагентам. Когда это надо было делать на 200к токенах контекстного окна Claude, я бы еще понял, зачем сабагент для сбора информации по проекту - собрать весь контекст и предоставить основному агенту концентрированную выжимку данных по проекту без лишнего шума, и без мусора в контексте. Зачем мне делает это Opencode на 1миллионе контекста GPT модели - н

Вайбкодил некоторого агента, в качестве ядра был выбран OpenCode cli в режиме serve. Главная задача была - добиться максимально быстрой генерации документов.

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

По умолчанию, что claude code cli, что opencode, могут в процессе выполнения запроса возраждать себе сабагентов, даже если вы не добавляли их в систему. Они сами решают, когда задачу стоит разбить на этапы и часть этапов отдать в работу сабагентам. Когда это надо было делать на 200к токенах контекстного окна Claude, я бы еще понял, зачем сабагент для сбора информации по проекту - собрать весь контекст и предоставить основному агенту концентрированную выжимку данных по проекту без лишнего шума, и без мусора в контексте. Зачем мне делает это Opencode на 1миллионе контекста GPT модели - не понятно.

Начал разбираться, как с этим бороться и что заметил:

1. Например, задача агента - собрать информацию по интернету, сгенерировать документ и сохранить.

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

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

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

В общем, выполняется совершенно неэффективная и бесполезная работа, на умных моделях с 200+к моделях контекста это надо срочно выключать. Я давний противник сабагентов в их масштабном понимании (в некоторых задачах они оправданы, но мало кто их правда использует по назначению). А теперь моё мнение еще сильнее укрепилось. Берем модель в ежовые руковицы и не даем ей никакого не морального, не физического права больше рождать себе подобных без нашего разрешения.

1. Идем в глобальный конфиг OpenCode (обычно лежит по адресу