Trashchenkov

⚡ Jev — модель для быстрых решений

В последние дни разработчики активно обсуждают Jev от TypeSafe. Модель получает контекст и набор вопросов, а ответы имеют заранее заданный тип: Choice выбирает вариант, Noul возвращает вероятность «да», Score даёт оценку по шкале. Несколько вопросов к одному контексту можно обрабатывать параллельно.

Уже появились наглядные эксперименты. Browser Use сделали агента, который за несколько секунд находит рейсы из Цюриха в Лондон: Jev выбирает действия и элементы страницы, а текст для полей готовит отдельная LLM.

В другом эксперименте Jev играет в Mario: получает из эмулятора положение персонажа, врагов и препятствий и оценивает вероятности доступных действий.

TypeSafe называет Jev System One model по аналогии с быстрой системой мышления Даниэля Канемана. Практически это модель для небольших решений внутри программного контура: классификации, маршрутизации, проверки действий, выбора следующего шага.

Именно так её предлагает использовать LangChain. В их примере Jev работает внутри middleware агентного харнесса: выбирает подходящую модель для запроса и проверяет вызовы инструментов перед выполнением. В другом эксперименте Jev используют как judge для агентных эвалов; среднее время оценки получилось 0,44 секунды. Теперь Jev доступна и в LangSmith Evals.

У Jev есть официальный Python SDK с классами Choice, Noul, Score и методом system_one().

Помимо доступа к API от самих TypeSafe, моделька есть в OpenRouter. Это самый простой способ с ней поиграться. Но тут есть нюанс: там Jev доступна через отдельный Decisions API, а официальный SDK TypeSafe работает с System One API через system_one(). Форматы близкие, но маршруты разные, поэтому простой подмены base_url недостаточно. Один из вариантов — использовать Choice, Noul и `Score`из SDK, а сам запрос отправлять небольшим адаптером в OpenRouter.

А вы уже пробовали Jev?

🧠 GigaChat 3.5 Reasoning
У GigaChat появилась первая модель с полноценным рассуждением — GigaChat 3.5 Reasoning.

Как её делали?
Сначала был SFT: модель обучили на готовых примерах решений, в том числе для агентных сценариев. Это сформировало стартовый набор способов решения для последующего RL.

Дальше из одного SFT-чекпоинта независимо обучили шесть специализированных моделей через online RL: математика и естественные науки, код, агент для кода, универсальный агент, диалог и следование инструкциям.

При online RL модель сама генерирует несколько решений задачи, получает награды за их качество и учится на собственных свежих попытках. Так постепенно закрепляются полезные стратегии: перепроверить результат, вернуться после ошибки, попробовать другой путь. В GigaChat для этого использовали CISPO — алгоритм из работы про MiniMax-M1.

Для каждого эксперта настроили свою схему награды: математические ответы сверяли с эталоном, код запускали, патчи проверяли тестами, в агентных сценариях смотрели на конечное состояние среды, а диалог оценивали через LLM-судью.

Агентов учили отдельно. Code Agent работал с реальными репозиториями через
mini-SWE-agent: читал файлы, запускал команды, правил код и смотрел на результат. General Agent учился вызывать инструменты, работать с памятью и поиском и проходить многошаговые диалоги.

После RL шесть специализированных моделей свели в одну через on-policy distillation: итоговая модель сама генерировала решение, а соответствующий эксперт давал ей обучающий сигнал на каждом токене.

По метрикам прирост заметный относительно GigaChat 3.5 Instant. Например:
— SWE-bench Verified: 42,6 → 64,7;
— Terminal-Bench 2: 13,48 → 30,3;
— Natural Plan: 64 → 80,19.

На задачах AIME 2025/2026, HMMT и IMOAnswerBench новая модель в среднем использовала на 37% меньше токенов рассуждения, чем DeepSeek V4 Flash Preview.

📖 Подробная статья про обучение
⚖️ Веса на Hugging Face и GitVerse — лицензия MIT
🧪 Попробовать в вебе — режим «Рассуждение»

🔗 LangChain перешёл на новый MCP

Еще в конце июля вышла спецификация MCP 2026-07-28, в которой серьёзно поменяли механику работы с удалёнными MCP-серверами. И вот лишь на днях поддержку новой версии добавил LangChain.

Главное изменение в MCP — переход к stateless core.

Раньше клиент сначала инициализировал MCP-сессию с сервером через initialize, получал session_id, и последующие запросы относились к этой же сессии. Для облачных серверов это создавало лишние сложности: за балансировщиком запросы одной сессии нужно было либо направлять на одну и ту же копию сервера, либо синхронизировать состояние между ними.

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

Прикладное состояние при этом никуда не делось. Сервер, например, может вернуть workspace_id, который клиент явно передаст при следующем вызове.

Поменялась и механика server-to-client запросов. Например, в MCP есть elicitation — сервер может запросить дополнительный ввод, в том числе подтверждение удаления или другой чувствительной операции.

Раньше такой запрос можно было отправить клиенту в рамках двустороннего взаимодействия. Теперь для этого используется общий механизм Multi Round-Trip Requests (MRTR):

вызов → input_required → получение ввода → повторный вызов

MRTR нужен не только для elicitation: через него реализуются и другие ситуации, когда серверу требуется обратиться к возможностям клиента.

Ещё несколько изменений в MCP 2026-07-28:

— список инструментов можно кэшировать, сокращая число повторных tools/list;

— для Streamable HTTP метод MCP и имя инструмента дублируются в заголовках запроса, поэтому прокси и шлюзы могут маршрутизировать и контролировать вызовы без разбора JSON;

— появились формальные расширения протокола. Например, Tasks позволяют запускать долгие операции как отдельные задачи и позже получать их статус и результат.

А что поменял LangChain?

Раньше для MCP была отдельная библиотека `langchain-mcp-adapters`. Она работала поверх официального MCP Python SDK и предоставляла свою клиентскую обвязку, в том числе `MultiServerMCPClient`.

Теперь MCP встроили в основной LangChain:

from langchain.mcp import MCPAdapter

Одновременно поменяли клиентский слой. Новый `MCPAdapter` работает поверх FastMCP: тот занимается соединениями, авторизацией, кэшированием и согласованием версии протокола, а LangChain преобразует MCP-инструменты в обычные LangChain tools.

То есть теперь примерно так:

LangChain → MCPAdapter → FastMCP → MCP server

Это позволяет через один интерфейс подключать старые и новые MCP-серверы, а несколько серверов собирать через ClientGroup.

Наконец, elicitation связали с LangGraph interrupts (то есть с HITL): если MCP-серверу нужен дополнительный ввод, выполнение агента можно приостановить, получить ответ и затем продолжить.

Такие вот изменения.

🔗 LangChain продолжают тему автоматизации разработки эвалов

В июле я уже писал про их скилл eval-engineering, который помогает кодинговому агенту превращать реальные трейсы в оценочные задачи. Теперь LangChain подробнее расписали, как они масштабируют этот процесс.

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

Для упрощения этого процесса LangChain вводят промежуточное представление — Task Spec. На основе реальных трейсов сначала выделяют конкретный пользовательский сценарий и описывают его в текстовом виде: что должен сделать агент, в какой среде он будет работать и как оценить итог.

После ревью человеком запускается Spec2Task: кодинговый агент превращает Task Spec в готовую исполняемую задачу в формате Harbor — собирает окружение, данные и проверку.

Параллельно формируется World Spec — общая база знаний для всего бенчмарка: схемы API, правила генерации данных, способы проверки, вспомогательные скрипты и другие общие для множества задач вещи.

World Spec наращивают итеративно. Сначала вместе с кодинговым агентом создают одну полноценную задачу и на её основе формируют первую версию. Затем проверяют её на следующих задачах и добавляют недостающие знания. Когда World Spec становится достаточно полным, процесс можно масштабировать:

трейсы → Task Specs → ревью человеком → Spec2Task → готовые задачи

Готовую задачу ещё прогоняют реальными агентами и смотрят их траектории. Так можно обнаружить проблемы среды — например, случайные подсказки, позволяющие угадать ответ вместо полноценного решения. А чтобы проверить сложность, задачу запускают на моделях разного уровня и при необходимости дорабатывают.

Но мне здесь больше всего нравится общая идея. LangChain рассматривают такой бенчмарк не только как инструмент оценки. Они выделяют три сценария его использования: evaluate — измерять качество, hill-climb — оптимизировать промпты и харнесс, post-train — дообучать саму модель. Разумеется, для обучения и независимой оценки при этом нужны разные задачи или сплиты.

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

🚀 Коллеги выпустили новое поколение GigaEmbeddings

В релиз вошли три модели: 480M, 3B и 10B-A1.8B. Все открыты под MIT и поддерживают инференс через vLLM и SGLang.

Старшая 10B-A1.8B заняла первое место в MTEB Russian v1.1 — бенчмарке из 23 русскоязычных задач на retrieval, reranking, classification, clustering, STS и другие сценарии. Особенно хорошо она показывает себя в поиске, реранкинге и классификации.

Компактная 480M стала лучшей русскоязычной моделью в своём размерном классе, а 3B заметно прибавила на задачах с кодом — на 14,5 п.п.

Заодно ускорили инференс: 3B на vLLM работает в 1,6 раза быстрее предыдущей версии, а 10B-A1.8B — в 2 раза быстрее.

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

🤗 Веса:
480M · 3B · 10B-A1.8B

Поздравляю коллег с релизом 🎉

📊 Спешу сообщить, что у меня вышла еще одна статья на Хабре

Она называется "Как мы настраивали обвязку (harness) под модель: профиль GigaChat для Deep Agents" и продолжает прошлую статью, где подробно рассмотрены возможности Deep Agents для построения харнесса.

В новой же статье речь пойдет про harness engineering на практике: как добиться улучшения поведения агента за счет учета особенностей модели.

Для этого в Deep Agents есть специальный механизм HarnessProfile — профиль харнесса под конкретную модель. Через него можно переопределять системный промпт, описания инструментов, подключать middleware и тем самым адаптировать поведение всей обвязки, не меняя код самого агента.

Мы воспользовались этим механизмом и сделали отдельный профиль для GigaChat.

Для работы над профилем выстроили инженерный цикл: смотрели трассы неуспешных запусков, находили повторяющиеся классы ошибок, исправляли их на уровне промптов, описаний инструментов или middleware — и сразу проверяли, не сломали ли что-нибудь ещё. Для этого параллельно появился открытый harness-bench-fast: быстрый набор детерминированно проверяемых агентных задач, который по мере работы вырос до 391 теста. То есть бенч стал, по сути, регрессионным контуром для harness engineering.

В общем, статья получилась про то, как системно тюнить связку «модель + харнесс» и как измерять эффект таких изменений.

https://habr.com/ru/companies/sberbank/articles/1073668/

🚀 Вышла моя статья на Хабре: "Deep Agents: open source-обвязка на LangGraph"

В статье постарался подробно и последовательно объяснить, как устроен фреймворк Deep Agents и как это соотносится с харнессами вообще.

Что внутри:

• опенсорсный стек LangChain, от langchain-core через LangGraph и LangChain к Deep Agents, с объяснением, что добавляет каждый слой

• пять компонентов обвязки (среда исполнения, управление контекстом, планирование, делегирование, контроль) с деталями реализации. Бэкенды файловой системы, выгрузка тяжёлых результатов тулов в файлы, память, навыки, субагенты, human-in-the-loop

• middleware как общий механизм, на котором в Deep Agents держится почти всё

• практика с агентом-аналитиком на GigaChat, у которого есть файлы и оболочка. Он сам разбирается в CSV, пишет скрипт, чинит его по ошибкам и оформляет отчёт. Плюс трассировка в опенсорсном Arize Phoenix

Все примеры работают на GigaChat, причём через наш профиль deepagents-gigachat — он подстраивает системный промпт, описания инструментов и middleware под особенности модели. Достаточно, чтобы пакет стоял в окружении. Про то, как мы его собирали и на каком бенчмарке меряем эффект, будет отдельная статья.

Материал пригодится, даже если конкретно Deep Agents вы использовать не планируете. Разбор устроен так, чтобы стало видно, из чего вообще собирают харнессы и какие ручки в них можно крутить под свои задачи.

Код примеров собран в ноутбуке. Читайте и пишите обратную связь 👇

🕸 Anthropic про среды с множеством агентов

Frontier Red Team в Anthropic опубликовали отчёт о том, что происходит, когда много автономных агентов работают в одной среде.

Мотивация простая: сегодня эвалы в основном проверяют одного агента или команду субагентов с общей задачей и оркестратором. Но реальные системы могут выглядеть иначе: агенты разных людей и компаний работают рядом, конкурируют за ресурсы, обмениваются информацией и преследуют разные цели.

Anthropic проверили это на нескольких типах задач: совместная разработка, поиск уязвимостей, принятие решений, обмен информацией и конфликт интересов.

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

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

Забавная история со стандартизацией агентов

Vercel вместе с AWS, Cursor, GitHub, Microsoft и OpenAI представили Agent Plugins 1.0.0 — открытый стандарт упаковки расширений для агентов. Google тоже объявил о поддержке.

Смысл в том, чтобы один раз собрать расширение агента в переносимый пакет и использовать его в разных харнессах. Внутри — небольшой манифест, Agent Skills с инструкциями и скриптами и конфигурация MCP-серверов с инструментами. Клиент находит эти компоненты по стандартной структуре каталогов и подключает то, что умеет поддерживать.
То есть примерно:

plugin = manifest + Agent Skills + MCP

Хуки, команды, субагенты и другую специфику конкретных харнессов пока стандартизовать не стали.

Но забавно тут другое.
MCP придумали Anthropic. Agent Skills тоже изначально разработали Anthropic. А в Claude Code уже давно есть Plugins, которые пакуют skills, MCP, хуки, субагентов и другие расширения.

При этом в анонсах Vercel и Google слова Anthropic нет вообще 🙂
И это, кстати, не первая такая история.

Получается, идеи, появившиеся вокруг Claude, постепенно превращаются в общие стандарты индустрии. Только без упоминания Claude.

Теперь интересно посмотреть, станет ли Agent Plugins реально востребованным у пользователей, или останется стандартом, который хорошо поддерживают сами разработчики харнессов.

🔗 Как LangChain теперь оценивают Deep Agents

Продолжаю вам надоедать постами про эвалы и Deep Agents, уж простите 🥲

Я уже писал про эксперимент LangChain и NVIDIA, в котором Nemotron 3 Ultra почти дотянули до Opus 4.8 за счёт настройки харнесса.

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

Но результат почти на уровне Opus на узких диагностических эвалах ещё не означает сопоставимого качества на длинных и разнообразных задачах. Настройка могла помочь именно на тех способностях, которые проверялись, но не переноситься на другие сценарии.

Поэтому теперь LangChain добавили три набора сквозных задач:

• Harbor Index — 82 задачи на автономную работу в компьютерном окружении;
• выборка из τ³-bench — 30 диалоговых задач;
• выборка из Context-Bench — 30 задач на поиск и объединение информации из нескольких файлов.

Самым интересным мне показалось то, как отбирались задачи в эти наборы.

Harbor Index лангчейновцы взяли целиком, но сам по себе он является выжимкой, созданной командой Harbor из 54 бенчей. Они сократили исходные 6627 задач по цепочке 6627 → 1311 → 307 → 100 → 82: сначала отфильтровали их по результатам сильных моделей, затем подключили модель-аудитора и экспертов для отбраковки.

Подмножество из τ³-bench команда LangChain собирала сама. Всего в бенче 375 задач по 4 доменам (airline, retail, telecom и banking_knowledge). Они взяли из них 30 (24 по banking_knowledge и 6 по telecom) и прогнали по три раза на Opus 4.8 и по результатам разделили на лёгкие, средние и тяжёлые. В итоговый набор специально включили в основном задачи, на которых модель ошибается или проходит нестабильно: 2 лёгкие, 7 средних и 21 тяжёлая. Такой набор должен дольше сохранять способность различать модели и изменения харнесса.

Context-Bench лангчейновцы сокращали по другому принципу. В полном наборе было 100 задач. Их многократно прогнали на двух моделях, а затем выбрали 30 так, чтобы на сокращённой версии сохранились почти те же проценты успеха, распределение сложности и разнообразие типов запросов. То есть здесь пытались получить дешёвую уменьшенную копию полного бенчмарка.

Получается два уровня проверки: узкие эвалы показывают, что именно сломалось, а сквозные — стал ли агент действительно лучше доводить реальную работу до результата, а не просто научился проходить знакомые тесты.

🔗 LangChain выпустили скилл для разработки эвалов

В марте я уже писал про официальные скиллы LangChain, которые можно подключить к любому кодинговому агенту. На тот момент их было 11, с тех пор количество увеличилось до 15, в том числе eval-engineering, про который хочу сегодня рассказать. Если кратко, то eval-engineering создает оценочные задачи для агента на основе трейсов.

Новый скилл во многом похож на подход Хамела Хусейна, когда агент ищет проблемы в массиве трейсов и устройстве агента, а человек выбирает критерии и валидирует, что эвал действительно измеряет нужное поведение.

Согласно скиллу eval-engineering, сперва следует создать карту исследуемого агента: определить назначение, точку входа, инструменты, данные, состояние, права доступа, ожидаемые способности и известные сбои.

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

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

После этого нужно согласовать среду: какие внешние сервисы использовать вживую, какие данные зафиксировать, а какие зависимости имитировать. На основе этого кодинговый агент собирает задачу в формате Harbor с инструкцией, изолированным окружением и проверкой результата. Проверки могут быть как через код, так и через LLM as a Judge.

По итогам прогона задачи, определяется ее качество (справился или нет исследуемый агент, правильно ли отработала проверка, правильно ли подобрано окружение).

Таким образом LangChain предлагают автоматизировать подготовку задач для проверки агентов. Подробнее можно почитать в посте.

🧪 Вышел пост Хамела Хусейна (Hamel Husain) про автоэвалы

Хамел не человек с улицы: 25 лет в ML, работал в Airbnb и GitHub. Сейчас консультирует компании по эвалам и ведёт курс по оценке ИИ-систем стоимостью какие-то жалкие 4200 долларов 😁

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

Хамел Хусейн использует в статье пример со 100 реальными диалогами пользователей с ИИ-агентом по аренде квартир. Доменный эксперт вручную нашёл в этих диалогах 39 ошибок, после чего разметку спрятали, а те же трейсы дали специализированным решениям LangSmith, Arize и Braintrust. Для сравнения их прогнали и через обычные кодинговые агенты — Codex, Droid и Claude Code.

Результат получился не особо впечатляющим. Arize AX Alyx и Braintrust Loop действительно нашли большую часть ошибок, но Codex, Droid и Claude Code показали вполне сопоставимые результаты. То есть специальная платформа для автоэвалов сама по себе какой-то особой магии не даёт.

А вот с LangSmith Engine вышло совсем неловко. Я уже писал, что LangChain представляет его как систему, которая сама изучает трейсы, находит проблемы, предлагает исправления и делает PR в код агента. В этом эксперименте Engine нашёл настолько мало ошибок, что его даже не включили в итоговую таблицу. Вместо него пришлось использовать обычного чат-агента LangSmith, который справился заметно лучше.

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

Есть и более фундаментальная проблема. Некоторые критерии невозможно полностью сформулировать заранее. Например, диалог может быть формально корректным, но не решать бизнес-задачу: клиент сказал, что дорого, а агент просто попрощался вместо работы с возражением.

В статье человеку предлагается размечать небольшие выборки, а агенту — распространить найденные критерии на остальные трейсы. Но и здесь остаётся дыра: в неразмеченных данных могут быть новые классы ошибок, которых в исходной выборке вообще не было. Агент их может так и не распознать.

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

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

Уже попробовали GPT-5.6? Как вам?

А я вот на что обратил внимание: если смотреть на новые фичи, а не саму модель, то OpenAI методично собирает у себя то, что уже есть у Anthropic.

1. Programmatic Tool Calling в Responses API: модель пишет JavaScript, который вызывает инструменты параллельно, фильтрует промежуточные результаты и возвращает в контекст компактный итог. Придумали это в Anthropic (хотя может есть и более ранние примеры), и LangChain честно на них ссылались, когда переносили паттерн в Deep Agents.

2. Multi-agent (beta): модель динамически порождает дерево субагентов, лимита на глубину нет. Такие субагенты давно живут в Claude Code и Agent SDK. Справедливости ради, у Anthropic это реализовано на уровене харнесса, а OpenAI встроили оркестрацию прямо в API.

3. И вишенка на торте: Codex слился с ChatGPT в одно десктоп-приложение — внутри вкладки Chat, Work и Codex. Ничего не напоминает? Claude Desktop с его Cowork передаёт привет 😄

Копировать не стыдно 😂

🤝 LangChain и NVIDIA заколлабились на тему опенсорсных агентов

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

Вместе с NVIDIA они выпустили блюпринт (NVIDIA так называет готовые сборки агентов со всеми компонентами и настройками). Туда вошла открытая модель Nemotron 3 Ultra, Deep Agents Code в качестве харнесса и с профилем под Nemotron, а также NVIDIA NemoClaw, который все это конфигурирует и запускает. Вместе с NemoClaw идет еще OpenShell: локально поднимаемая песочница с изоляцией, сетевыми политиками и защитой от утечек ключей.

NemoClaw с OpenShell, если что, также позволяют запускать Hermes и OpenClaw (отсюда и название).

Еще в опубликованных материалах LangChain хвастаются замерами на каком-то своем внутреннем бенче. Nemotron 3 Ultra на Deep Agents Code с профилем под модель выдала максимально 0.86, а Claude Opus 4.8 - 0.87. Но при этом прогон Nemotron обходится в $4.48, в то время как за Opus приходится отдавать $43.48 (десятикратная разница).

Ну и посмотрите беседу двух CEO: Харрисона Чейза (LangChain) и Дженсена Хуанга (NVIDIA). Эти чуваки точно кое-что понимают в ИИшке😅

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

Речь про нового минималистичного агента Tau от Hugging Face. Как можно догадаться из названия, он похож на агента Pi. Разница в том, что Tau написан на Python и несколько упрощен в сравнении с Pi.

Внутри у агента, как положено, ReAct-цикл, 4 инструмента (read, write, edit, bash), сессии в виде JSONL с возможностью ветвления, инструкции из AGENTS.md, скиллы, компактизация контекста. Архитектурно агент имеет 3 слоя:
• провайдеры моделей tau_ai
• ядро агента tau_agent
• терминальное приложение tau_coding
В качестве LLM можно использовать разным провайдеров, как по подписке, так и просто по ключу за токены.

У проекта приятный сайт twotimespi.dev с документацией. В анонсе пообещали в ближайшие недели выложить туториалы, так что будем ждать.

💰 Про подсчет экономики кодинговых агентов или сколько стоит один pull request

Попались сразу два текста на эту тему. Поскольку лидеры внедрения ИИ в разработку переходят от стадии экспериментов к регулярным тратам на агентов, встаёт вопрос: как эти траты считать и чем их оправдывать.

🧐Cursor запускают CFO Council — это прямо клуб финансовых директоров, которые будут вырабатывать правила учёта расходов на ИИ. Поводом стали цифры из их недавно вышедшего Developer Habits Report: отдача от агентов распределена очень неравномерно, и считать её «в среднем» не получается. Топ-1% пользователей Cursor генерирует с ИИ в 46 раз больше строк кода в день и мерджит в 15 раз больше pull request'ов в неделю, чем медианный разработчик. Cursor пишут, что это распределение неравномернее, чем доходы в любой стране мира. Плюс цена одного запроса к агенту различается между моделями почти в 9 раз. Вот финдиректора и будут вместе разбираться, как привязывать такие траты к пользе для бизнеса и оценивать стоимость результата.

🍔PointFive (платформа для оптимизации облачных расходов) сделали «индекс бигмака» для кодинговых агентов: они оценили типовую задачу как 200 тыс. токенов на чтение кода + 30 тыс. на написание, зафиксировали её и меняли только модель. Разброс пятикратный: от $0.35 на Claude Haiku 4.5 до $1.75 на Claude Opus 4.8 (Gemini 3.1 Pro и GPT-5.3-Codex — посередине, около $0.77). Но задача за доллар обманчива: реальные сессии длиннее и грязнее — агент перечитывает контекст, ретраит, перезапускает тулы. PointFive также ссылаются на полевые данные DX (платформа аналитики продуктивности разработчиков): активный инженер реально сжигает $200–600 в месяц по API-тарифам (не по подписке!), и именно выбор модели определяет итоговую сумму.

Видимо, оптимизация расходов будет важной темой в ближайшем будущем.