Go Update - Новости Go

Об изоляции LLM Да, это ещё один пост про работу с Codex/Claude/GLM/Qwen/DeepSeek и прочая. В этот раз без воды, исключительно технический. Решил я тут вкатится в разработку с помощью LLM всерьез и пойти через, уже почти ставшие стандартом, «план -> реализация -> тест -> повторить». Касаемо шагов, скиллов, плагинов и прочего говорить не буду — тут каждый сам «кузнец своего счастья» и индустрия пока только осознает необходимость общего подхода. Меня же заинтересовало другое — изоляция агентов, в процессе их работы, от деструктивных и «вредных» действий. Проблема: «настоящая» изоляция ни у одного из агентов/харнессов не сделана на приемлемом уровне «из коробки». OpenCode запрещает чтение выше своего рабочего каталога, но спокойно пропускает команду head -10 /home/file/name. Codex и Claude, используя API песочницы ОС, спокойно пропускают ручки LLM до хомяка и других каталогов, правда только на чтение. Однако даже чтение может быть «вредным»: если агент в своём безумии решит вычитать ~/.ssh/private_key, то «по умолчанию» ему никто не помешает это сделать. И да, я знаю, что у SOTA моделей проверкой команд занимается ещё одна модель в отдельном контексте, но это вероятностная проверка, а не однозначная. А значит, если она оставляет 1% шанс на чтение моего приватного ключа, то это не вопрос «может быть?», а вопрос «когда?». Поэтому мои поиски привели меня к следующим тулам и вариантам: • Docker SBX — sandbox для агента поверх докера. На всех ОС (Linux/Windows/Mac) изоляция сделана с помощью виртуализации, а значит если чего-то в образе нет, то к этому «чему-то» агент доступа не получит. Плюсы: знакомый Dockerfile синтаксис и принципы, хорошая интеграция с docker’ом. Минусы: необходимость Docker ID и долгий запуск, жрёт от 500+ метров в памяти. Для разработки мультиконтейнерных решений хорошая вещь, для «пообщаться c OpenCode» не. • Система правил для Claude и Codex — можно конфигом настроить, что агенту можно, и обе тулы зафиксируют правила через механизмы песочницы ОС. Плюсы: есть в комплекте (хотя стандартные правила слишком свободные), нулевые дополнительные траты на песочницу, (вроде) достаточно гибкий синтаксис. Минусы: у каждой тулы свой синтаксис, у кодекса сама система всё еще в экспериментальном статусе, ограничения песочницы самой ОС. Если работатете строго с одним агентом, то это может быть хорошим вариантом. • Agent Safehouse — унифицированная песочница для агентов на MacOS. Работает через sandbox-exec (через него же работает песочница клода и кодекса). Плюсы: нулевая стоимость на этапе исполнения, унифицированный синтаксис и команды для запуска процессов в песочнице. Минусы: выглядит как сторонний проект, поддержка которого может в любой момент закончится. Все ограничения песочницы мака в силе, а само яблоко регулярно меняет API sandbox-exec, которое ещё и не документирует. Для «пообщаться с OpenCode» мне нравится, но в прод я бы такое тащить не рискнул. • MicroSandbox, SmalVM — идея та-же, что у SBX, но реализация другая - под капотом микровирутальные машины на которые накатываются такие-же OCI миниобразы. Из-за этого запуск кратно быстрее SBX и кратно меньше потребление памяти (обещают оверхед в 30-40Мб против 500+ у докера). Плюсы: у обоих удобный синтаксис, возможность точечной настройки доступов к сети (включая варианты через MITM и резолвинга только определенных доменов) и ресурсам железа, аудит событий внутри виртуалки, адекватная работа с секретами. Минусы: оба проекта вроде выходят на коммерческие рельсы, но пока именно в процессе выхода. Запуск виртуалки, несмотря на минимализм, все же сьедает дополнительное время и память. Для прода я бы рассматривал этот вариант, тем более у smolvm есть возможность преобразовать итоговые образы в исполняшки. Для себя пока остановился на Safehouse, плюс активно исследую MicroSandbox. Надеюсь, что всё в итоге превратится в набор стандартов, по типу OCI, ибо так дальше жить нельзя.