MeshAxiom Открытый 3D-стек от AlayaLab, рассчитанный на агентов. Базовая модель MeshAxiom-Base делает компактный явный меш из одного изображения с заданным бюджетом граней. • Генерация явного меша по картинке с контролем числа граней • Меши читаются инструментами: вершины и треугольники остаются в файле • Агент вызывает геометрические тулы и получает компактные сводки и виды • Модули переиспользуются: записи ассетов связывают геометрию и материалы с трансформами, ригами и движением • Из модулей собираются сцены и сценарные программы • Опциональный рестайл через H3 поверх готовой сцены huggingface.co/AlayaLab/MeshAxiom-Base github.com/AlayaLab/MeshAxiom #agent #3d MAX

Ну че, как вам G0VNO в итоге? От себя скажу одно, я чет особо не впечатлился этими вашими локальными модельками, они как по мне абсолютно не годятся для узконаправленных задач. Их максимум это суммаризация данных, либо использование мультимодалок для перевода текста/аудио в текст. Вот вайбкодить на этом, я думаю, никакого удовольствия не будет. Хз как оно с агентами будет работать, это конечно требует больше тестов. Но тут есть НЮАНСИКИ: Во-первых, производительность, даже 100 ток\сек кажутся чудовищно медленными. Во-вторых, сайд эффекты от квантизации лупят мощно по конечному результату. Иногда модели даже жестко игнорят инструкции, и это на маленьком контексте. Под агентов нужен контекст минимум 100к, а на нем эти проблемы могут стать хуже. P.S. Все репорты на бусти залил еще с утра.

Что просить у агента, кроме кода? На AI Natives один из участников рассказывал, как с помощью AI учился играть в одну из разновидностей покера. Получить расчёт хорошего хода было лишь частью задачи: ему самому надо научиться принимать решения за столом. Но запомнить тысячи ситуаций и вложенных «если» сложно. Поэтому он с AI выделял понятные правила: сначала определить тип раздачи (одна пара, две пары, без пары), затем пройти несколько шагов для этого типа. Где правило получалось слишком сложным, разбирали примеры. А потом сделали тренажёр: человек выбирает ход, получает объяснение ошибки и чаще встречает ситуации, в которых ошибается. Это в тему размышлений в посте про изобилие кода. В Математике 2.0 есть две схемы: в одной AI получает решения, обходя человеческое понимание; в другой - помогает это понимание развивать. В разработке похожая история: пока делаешь фичу, уточняешь требования, замечаешь исключения, узнаёшь что-то о пользователе, или о работе ранее неизвестного тебе модуля. Если эта работа уходит к агенту, понимание уже не обязательно появляется по дороге. Значит, стоит отдельно устроить процесс, в котором мы его приобретаем. В первом посте был пример одноразового софта —> глубина понимания очевидно зависит от срока жизни продукта, цены ошибки и того, насколько легко всё откатить. Для игры под один вебинар мне важно понимать правила модели и где она может ввести участников в заблуждение. А масштабирование на миллионы пользователей и архитектура на десять лет ей точно не нужны :) В CRM, от которой зависят работа команды и данные клиентов, уже важно понимать правила процессов, как обнаружить ошибку и восстановить данные. На больших задачах я стараюсь получать это понимание по ходу работы агента: 1) Сначала прошу план в виде артефакта, который можно читать и комментировать: варианты, ключевые решения, данные и допущения. Задаю вопросы и оставляю правки до реализации. 2) Проверяю важные допущения. Например, агент с помощью regex-а пытается отлавливать ответы клиента и обновлять CRM. 3) Прошу уменьшить зависимость от неизвестного. Допустим, размер компании не найден: можно оставить «неизвестно», попробовать другой источник или передать человеку. Или вместо regex-ов заюзать jev/decisions api. 4) После реализации прошу отчёт о тесте и прогоне на реальных кейсах: GIF-ки, скриншоты и описание процедуры. Так я вижу, что проверяли и какие сценарии выпали. Например, что сделал агент с лидом, размер компании которого неизвестен? Или «22-го подойдёт?» ещё не значит, что встреча согласована. Разбираем ошибку, уточняем правило, добавляем тест. Что хочу сделать системнее: часть случаев заранее оставлять за пределами настройки, а потом разбирать расхождения на них. Где ошибся агент, где не хватило данных, а где стоит пересмотреть само правило? И план, и отчёт мне удобнее оформлять в HTML и оборачивать в артефакт, со схемами и возможностью покрутить сценарии. Мне особенно удобно комментировать конкретный кусочек. Антропики публиковали по теме полезное, кстати Попробуйте на следующей большой задаче попросить два артефакта: план с ключевыми решениями и отчёт о проверках. Выберите одно важное допущение, попросите показать, что изменится, если оно неверно, и проверьте, есть ли этот случай в отчёте. А потом задайте себе вопрос: улучшилось ли ваше понимание?

Битва скиллов 🔗 https://github.com/Jakeschincariol/arena-skill Создает команду /arena которая запускает турнир на вашей библиотеке установленных навыков и открывает три мощных практических сценария: 1️⃣ Сценарий 1. «Битва титанов» (Skill vs Skill Benchmark) Актуально если у вас установлены альтернативные или пересекающиеся скилы. Можно стравить их в соревновании на решение одной сложной практической задачи, чтобы объективно определить сильнейший подход или скомбинировать их сильные стороны. В моем случае 1я дуэль была по Аудиту безопасности

Участники: claude-security против security-audit-skill (Cloudflare). Задача: Провести аудит критического модуля (например, auth-сервиса или парсера). Судейство: Кто найдет более глубокие граничные уязвимости, допустит меньше false-positives и предложит более надежный патч.

Дуэль 2: Фронтенд-архитектура и скролл-дизайн

Участники: scroll-craft против компонентов magicui / shadcn Задача: Спроектировать архитектуру и интерактивный прототип высоконагруженного лендинга.

Дуэль 3: Мобильный стек

Участники:  react-native-skills против expo .

2️⃣ Сценарий 2. Эволюционная прокачка конкретного навыка Запускает турнир из 16 агентов (--quick) с задачей:

«Переписать архитектуру навыка X: убрать воду, внедрить строгие анти-AI-slop правила, структурировать вызовы L1/L2/L3, добавить четкие триггеры и скрипты верификации под стандарты PersonalOS».

16 субагентов с разными стратегиями (First Principles, Speed-focused, Adversarial, Academic, Pragmatic) создают свои варианты реализации. - В раундах атак они вскрывают слабые места в формулировках друг друга (галлюцинации путей, избыточность токенов, двусмысленность инструкций). На выходе получается единственный, максимально отточенный и выживший вариант SKILL.md. 3️⃣ Сценарий 3. Стресс-тестирование надежности навыка Проверка того, насколько установленный навык устойчив к сложным граничным условиям: - Агенты Арены выступают в роли «атакующих клиентов» с противоречивыми, сложными или вредоносными запросами. - Оценивается, насколько строго целевой навык удерживает контракт, не сваливается в ленивые ответы и соблюдает безопасность. === запустил свои и получил эталонный синтезированный пайплайн аудита по безопасности: 5-фазный регламент для аудита любого проекта в PersonalOS: 1. Recon & Ledger: Фиксация git-ревизии, подсчет файлов и генерация coverage-ledger.json. 2. Sandboxed Hunting: Запуск параллельных исследователей в изолированной среде без внешней сети. 3. 3-Lens Panel: Обязательная тройная верификация (Reachability, Impact, Defenses) перед признанием проблемы реальной. 4. Patch Specification: Генерация минимального атомарного патча. 5. Delivery: Формирование отчета REPORT.md и экспорта в SARIF.

🔬 Search или extract? Новое исследование о памяти ИИ-агентов и decision models. В сообществе разработчиков ИИ-агентов давно спорят: что лучше для долговременной памяти - извлекать факты из диалога с помощью LLM или просто хранить и искать нужные сырые реплики? Новый препринт даёт логичный ответ - выбор зависит от бюджета на контекст. Со своей стороны изначально знал, что трек RAG и память в нашей работе пересечется (и так оно у нас и вышло). Мы вели разработку как extract методов подобно mem0, так и memory RAG с поиском по заметкам или сырым диалогам. Закономерно, что jev like модель, как развитие поиска (в лице выбора и ранжирования) станет хорошим дополнением для темы памяти. Но вернёмся к статье... 📊 Суть эксперимента Авторы сравнили подходы на диалоговых бенчмарках LoCoMo и LongMemEval: • Turns + Jev - выбираем лучшие сырые реплики за один вызов Jev. • engram v2 - система извлечения фактов, где LLM извлекает факты, Jev управляет ими (ранжирует/выбирает). •Turns + cosine (базовое ранжирование). •Turns + LLM (LLM-ранжировщик gpt4o mini). 🎯 Результаты 1. При строгом бюджете контекста сырые реплики не уступают извлечённым фактам: разница всего 0.5 пункта (77.0% против 77.5%) при чтении контекста в 265 против 251 токена. Это укладывается в заранее установленный зазор метрик в 5 пунктов. 2. Экономия на поиск сырых реплик - решение обходится в 3к (!!!) раз дешевле, чем извлечение фактов ($0.00061 против $1.865 за 1000 реплик). 3. Однако, польза от ранжирования резко падает с ростом бюджета. Если при выборе 3 из 30 кандидатов ранжирование даёт +17.4 пункта на LoCoMo, то при 20 кандидатах - всего +1.5. На LongMemEval: +9.1 и +1.1 соответственно. 4. При большом бюджете системы извлечения а-ля. Engram становятся точнее (82.4% против ~77.6% у Turns + Jev). 5. Jev против cosine ранжирования. Косинусный поиск на своём оптимальном k=6 даёт точность 68.6%, в то время как Turns + Jev — 77.0%. Выводы. При жёстких ограничениях (короткий контекст до 512 токенов) качественное ранжирование сырых реплик может заменить извлечение фактов, будучи на порядки дешевле. При больших бюджетах преимущество переходит к extract моделям. Отмечу, что Jev-селектор оказался не хуже LLM-ранжировщика (разница 0.4 пункта), но работал втрое быстрее. И это неплохое развитие rag memory систем дёшево и сердито. 😏

Всю жизнь я работаю с компьютерами, и главный выработанный мной скилл — не удивляться тупизне и абсурдности происходящего. В обычной жизни как? Есть важное и есть неважное, есть срочное и есть не срочное, есть сложное и есть несложное. И люди как-то эти вещи соотносят. Скажем, улетит ли рейсовый самолет, если пилот забыл дома пилотку? Скорее всего улетит. Будут ли у вас дотошно проверять билет, если ваш поезд уже отходит с перрона? Ну, скорее всего вы сначала запрыгните, а потом уже билет. Мама наказала сходить в магазин, а где деньги лежат, не сказала. Но ты в принципе все равно знаешь, где, поэтому сам нашел, взял и сходил. Логично, да? Ну вот, а в компьютерах не так. Там работает так называемая «формальная» логика, то есть все вещи имеют одинаковую бесконечно большую важность, а все процессы принципиальнее девственницы на первом свидании. Из-за этого комьпютеры ставят обычных людей в ступор: ну вот же файл лежит, почему ты сам его не мог взять, почему мне надо тебе явно на него указывать? Зачем мне нажимать на эту кнопку несколько раз, я же уже сказал, чего хочу! Почему компьютер меня не помнит, я же им пять минут назад пользовался? Почему таблицу из этой программы нельзя вставить в эту, они же одинаковые? Почему нельзя выключить подсветку клавиатуры, не зарегистрировав аккаунт? Зачем вообще клавиатуре аккаунт? Почему после установки что-то сломалось? Зачем вообще в компьютере процессы, которые что-то ломают? Почему этот сайт не открывается, хотя вчера открывался? Почему открывается на твоем телефоне, но не на моем? Почему этот провод передает данные в одну сторону, а не в другую? Он же одинаково с обоих концов выглядит. И так далее. Вооот. Так что наша ценность, как специалистов, и наша бремя как людей, это умение через этот булшит продираться, не теряя рассудок и даже не сильно ухудшая настроение. Некоторых, правда, сильно деформирует профдеформацией, и они начинают считать компьютерную логику нормальной. А потом удивляются, что она не работает. «Приходи в гости в любое время» — в смысле нельзя было приходить в любое время? Может вам еще и как дела у меня не интересно? А зачем спрашивали? Вы не поверите, но это все было вступление. Просто зафиксировать ситуацию. А теперь открытие: я понял, что в агентах/ЛЛМах ощущается как магия. ЧТО У НИХ СНОВА НОРМАЛЬНАЯ, ЧЕЛОВЕЧЕСКАЯ ЛОГИКА. Говоришь им: пойди проверь. И он идет и проверяет. Не спрашивает, что, где, куда, откуда, сколько, у кого ключи взять, а ой введи пароль, скопируй, пермишны поправь, и шелл новый создай. Просто идет и делает. По важному спрашивает. По неважному сам решает. Попросил в файле посмотреть, но в названии опечатался? Он посмотрит в нужном. ПОТОМУ ЧТО ПОНЯТНО ЖЕ ЧТО ТЫ ИМЕЛ В ВИДУ. Нужно найти информацию — найдет. Нужно сделать какой-то сайт — сделает КАКОЙ-ТО, а не вынет тебе всю душу пониманием задачи. А иногда еще и ответ оформит так, как тебе было бы удобнее всего ответ потреблять. Даже если ты его не просил. Потому что ПОНЯТНО ЖЕ, что ты хочешь удобно. Кто вообще в жизни когда-либо хотел чтобы неудобно. Короче, компьютеры из абсолютно тупого деревянного безынициативного вахтера с комплексом бога и вниманием к деталям как у Шерлока Холмса превратились в почти нормального человека, с которым можно иметь дело. Просто наконец-то хоть чуть-чуть выдохнуть можно. Но недетерминированные, да.

Мы с вами помним момент openclaw с января этого года. С тех пор подавляющее большинство из нас попользовалось гермесом, клешней и прочими персональными агентами, убедились что эти штуки почти ничем не лучше обычных моделей и благополучно про них забыли. Но про них не забыли CPO крупных компаний, в последние пару месяцев волна Dots, Grokbot и Muse захлестнула мир нормисов. Люди пропустившие клешню получили куда более удобный и универсальный продукт прямо в вацапе и твитере. И это очень важно. Потому что это не 500к техноэнтузиастов, а десятки миллионов обычных людей, которые начиная с сентября-октября 2026 начали массово, миллионами, покупать на амазоне, бронировать авиабилеты, общаться с поддержкой и госорганами, писать клеймы и кляузы с помощью агентов. Ни одна крупная компания не готова к тому что их ждет (и уже происходит). Ни один отдел поддержки или разбора жалоб не готов к тому, что миллионы агентов со сверхзнанием мельчайших деталей клиентской оферты будут писать требования, обращаться в надзорные органы, выбивать скидки или проводить ультра-анализ для покупки пары рулонов туалетной бумаги. Агентская комменрция тут, ей не нужны ваши токены, но рынок уже меняется.

Как встраивать ИИ в продукт Полезно продактам, CPO и тем, кто сейчас автоматизирует команды и процессы. 1. ИИ может ухудшить ваш продукт. Он может быть медленным и ненадежным, или же решать проблему, которой ни у кого нет. Тот факт, что это ИИ, еще не означает, что его стоит разрабатывать. 2. Подумайте, нужно ли вам вообще разрабатывать ИИ. Зачастую лучше сначала создать что-то для ИИ, например, сервер MCP. Их проще создавать и поддерживать. 3. Ищите jobs to be done, а не демо. Лучшие возможности для ИИ — это задачи, выполнение которых занимает более 30 секунд, использующие код или интерфейсы, которые пользователи не знают (например, SQL), или задачи, которые пользователи повторяют более 20 раз 4. Онбординг — отличная первая цель. Визард установки с ИИ выполняет работу, занимающую два часа, за 8 минут. 5. Не спрашивайте: «Как добавить ИИ в это?» Спрашивайте: «Как выглядит agent-first-версия этого?» Такой вопрос заставляет переосмыслить jobs to be done для agent-first-будущего и помогает не быть разрушенным ИИ-native конкурентом. 6. Создание продуктов «формата 2030 года» может потребовать начать с нуля и отказаться от накопленных за годы UI-решений и допущений, которые больше не актуальны. 7. Следите за клиентами, которые пересобирают ваш продукт с помощью ИИ. Это показывает, какие функции им действительно нужны. Когда клиенты создают собственный прототип вашего продукта с помощью MCP и Claude Code, — нужно добавить в продукт больше настраиваемых «canvas»-артефактов. 8. Валидируйте ИИ-концепты также, как новые продукты. Запишите, по каким критериям будет оцениваться результат и какой runway у инициативы. Спросите, насколько команда будет разочарована, если её потеряет (PMF-опрос). 9. Опишите, как ваш продукт проигрывает ИИ-native угрозе, а затем профинансируйте собственную версию этого «атакующего». Даже лучший продукт поддержки проиграет продукту, где ИИ отвечает на все тикеты, — вероятно, поэтому Intercom так сильно развернулась в сторону Fin. 10. Ответьте на вопрос: чем это лучше Claude? Именно к нему люди обращаются по умолчанию. Ваш moat — это контекст: функциональность продукта, данные пользователей, а также инструменты и skills, которые вы построили. 11. Сосредоточьтесь на общей ИИ-инфраструктуре. Сделайте примитивы — промпты, стриминг, согласия, evals, задачи и аналитику, — которые продуктовые команды смогут расширять и встраивать в свои продукты. Выберите единый UX-паттерн, чтобы избежать «смерти от тысячи виджетов», а затем не мешайте командам. Продуктовые команды лучше знают своих пользователей, а не ИИ-команда. 12. Позвольте агентам запускать код. Исполнение кода даёт агентам возможности beyond predefined tools. 13. Позвольте агентам делать всё, что могут делать пользователи. Если есть инструмент создания эксперимента, но нет инструмента его запуска, агент сделает всё остальное и остановится, чтобы попросить вас кликнуть по UI. Это ограничивает возможности агентов. 14. Тестируйте продукт headlessly, чтобы развить «эмпатию к агентам». Проверяйте агентные фичи через CLI, чтобы сталкиваться с теми же точками трения, что и они. 15. ИИ не убивает ваш UI — он меняет его назначение. Меньше экранов для выполнения действий, больше — для одобрения, проверки и отмены действий агентов. Стройте UI, когда текста недостаточно. 16. Управляйте агентами на их уровне абстракции. Агенты работают лучше, если позволить им гибко писать и рассуждать. Перестаньте заставлять агентов использовать предустановленные query-инструменты и разрешили им писать собственный SQL. 17. Настройте ИИ-observability с первого дня: - Трейсите LLM-вызовы: входы, выходы, latency и стоимость. Это выявляет ошибки и проблемы, исправление которых даёт быстрый рост качества. - Отслеживайте использование агентами так же, как использование людьми. Агенты не генерируют pageviews или rageclicks, но можно отслеживать вызовы MCP-инструментов, запросы страниц и другое. - Используйте evals, но начинайте с малого. Вручную читайте трейсы, чтобы найти места, где ИИ ошибается. Создайте eval для проверки этой проблемы и улучшайте продукт, чтобы улучшить результат eval. Даже небольшие golden- или синтетические датасеты давали огромный прирост качества по сравнению с обычным циклом разработки. 18. Изучите unit-экономику ИИ-продукта. Наш визард стоит $6,67 за запуск, но улучшенная активация и retention стоят дороже. Переход трейс-саммари со стандартного gpt-4.1-nano на flex-уровень gpt-5-nano вдвое снизил затраты. 19. Многие сбои агентов — на самом деле сбои контекста. Добавление агенту значительно большего объёма контекста улучшило эффективность визарда сильнее, чем улучшенное reasoning, многошаговое планирование, субагенты, pruning и compaction. И Сделайте так, чтобы люди могли легко создавать контекст, которого агент не знает. 20. Прозрачная компания полезна для агентов. Ваши Агенты и агенты клиентов могут смотреть в кодовую базу, handbook и документацию, чтобы лучше понимать, как работает ваш продукт.

Возможные косяки при работе с агентами: • Ставите reasoning effort выше, чем нужно • Скилы размером с диссертацию • Начинаете работу, не обсудив с агентом цель и план • Или согласовываете каждый чих по полчаса • Автопроверки пропускают слишком много косяков • Самописные тулы жрут токены впустую • Мало авто- self- ревью • Не разбираете с агентом прошлые сессии • Слишком много ревьюите руками • Мало вайбкодите прототипов (show, don’t tell) • Агент не может сам проверить свою работу • Нянчитесь с ним на каждом шаге • Запихнули всю жизнь в глобальные AGENTS.md / CLAUDE.md • В кодовой базе сложно найти нужное • Не договорились с агентом, что как называется • Архитектура позволяет писать бесполезные тесты • Мало думаете стратегически • Да и вообще мало думаете

Продолжаю держать вас в курсе того, как получается внедрять AI агентов в повседневные задачи. Я продолжаю активно пользоваться Claude на работе и для личных целей как основным агентом. На работе даже появилось несколько скиллов, которыми я пользуюсь по несколько раз за неделю, и даже готов признать, что если у меня пропадет такая возможность – я сильно расстроюсь. Очень радует, что коллеги активно делают MCP к каждой кофеварке ко всему. Недавно опубликовали MCP к нашей in house системы управления экспериментами, которая является одной и самых важных в компании. Параллельно для личных целей я собираю агента как конструктор лего на фреймворке langchain. Этот агент крутится где-то на сервере, поэтому способен принимать и обрабатывать задачи даже когда я не за ноутбуком – это основное преимущество перед Calude. По сути, это самописный (бабушка дома сама на вайбкодила, не то что этот SaaS магазинный!) аналог openclaw или hermes, и ему не страшно доверить доступ к телеграму и почте. Сообщение выше, впрочем, как раз от него, он решил, что совершенно не обязательно читать задачу перед тем как перезаписывать ее текст. Точно поправлю промпт, но на самом деле можно и на уровне инструмента работы с задачами такое запрещать. Я не думаю то строить своего агента с нуля очень осмыслено, но этот проект очень много мне дает в смысле понимания того как устроена техническая обвязка "harness" современного агента. Меня сразу же очень впечатляет как много за нас делает Claude Code или Codeх: → позволяет в один клик подключать MCP, не прописывать конфиги руками → динамически подключает нужные для решения задачи tool'ы (если все доступные tool'ы сразу подгрузить в контекст, то контекст на этом закончится) → сжимает автоматом историю диалога, когда она становится слишком длинной, сохраняя суть → делает умный поиск по скилам → хранит и подтягивает откуда-то элементы долгосрочной памяти → декомпозирует задачи и запускает субагентов с урезанными полномочиями Можно было бы просто использовать Claude и не мучатся. Но когда мы начинаем встраивать агентов в свои процессы, или в клиентские фичи – тут уже не получится просто скинуть это на Claude. Нужно уметь настраивать карбюратор контекст руками. Расскажите, только честно: если завтра у вас пропадет возможность пользоваться LLM моделями для рабочих задач, это существенно повлияет на вашу работу? Или не особенно сильно? Андрей Менде, PM ML Booking .com, автор симуляторов Claude code AI для продакта, ЛЛМ для продакта, ML для продакта, и др.

ЧЕРНОЕ ЗЕРКАЛО УЖЕ НАСТУПИЛО - как скоро появится в enterpise, вы уже были на таком ИИ-собеседовании? Или отправляли своего аватара? ⚡️ Соискатель оставил ИИ-аватаров договариваться о его зарплате В ролике Graham Raabe на собеседовании встречаются три участника: сам Graham, ИИ-рекрутер Пэт и ИИ-представитель кандидата Виктор. Виктор знает резюме «лучше» своего владельца: приписывает ему управленческий опыт, которого нет, а затем предлагает зарплату в 60 тысяч. Graham поправляет его — и просит договориться хотя бы о 120 тысячах. Потом он отходит от камеры со словами: «Вы пока поговорите». Два цифровых собеседника продолжают разговор, назначают следующую встречу и никак не могут закончить прощаться. В финале Graham возвращается. Его не устраивает результат переговоров, и он снимает свою кандидатуру. Очень буквальная версия будущего: агенты уже могут поговорить друг с другом. А вот отстаивать ваши интересы — отдельная задача.

Memory Engineering 101: Мой подход к агентской памяти Друзья, хочу поделиться с вами своим подходом к агентской памяти. Память состоит из 3х частей: • Notes: заметки, которые Клод пишет (и извелкает из сессий) вовремя работы • Hook/Recall: воспоминания Just in time - когда клод хочет что-то сделать, срабатывает хук, который заставляет его глянуть в хранилище и дернуть оттуда уже накопленый опыт • Evals: каждую ночь, клод сам себя тестирует и пытается придумать что можно улчушить Память бывает частная и общая, общая память растет органически, с помощью еще оодного агента, который мерджит частные воспоминания с памяться компании. Все это дело расшарено с коллегами через сервер, и получается что знания накапливаются и доступны для всех. Весь метод выложен на гите - пользуйтесь, буду очень рад вашим PR и комментам. И намного подробнее про подход в моем блоге.

OpenCode V2 Крупное обновление открытого агента для написания кода от Anomaly. В отличие от агентов-компаньонов вроде Hermes или DeepSeek Harness, этот нацелен на разработчиков: заточен под терминал и IDE, максимум скорости и экономии токенов при правке репозиториев. Что нового • Центральный фоновый сервис теперь по умолчанию — TUI, веб и десктоп работают через один процесс • API и клиент переписаны с нуля • JS-интерпретатор в Code Mode — агент сводит инструменты MCP/OpenAPI в единые скрипты • Фоновые субагенты и асинхронные команды в шелле • Система плагинов обновлена, появилась горячая перезагрузка • Можно подключать как самостоятельную библиотеку или SDK • Плагины версии 1.0 больше не поддерживаются • API сервера полностью изменилось • Конфиг tui.json переехал в формат .json Обновление: opencode upgrade --major github.com/anomalyco/opencode #coding #agent MAX