Книжный куб

Demystifying evals for AI agents: устройство оценки и заметки на полях (Рубрика #AI4SDLC) Продолжаю тему agent harnesses. В "Demystifying evals for AI agents" ребята из Anthropic разбирают, как понять, что агент после очередного изменения стал лучше. Статья вышла 9 января 2026 года; авторы — Mikaela Grace, Jeremy Hadfield, Rodrigo Olivares и Jiri De Jonghe. Это инженерный обзор опыта Anthropic и клиентов; рекомендации основаны на отдельных практических случаях. Сначала про основные части статьи. 🔸 Устройство eval Задача, отдельная попытка, grader, траектория и итоговое состояние среды. «Билет забронирован» в ответе агента ещё не означает, что бронь появилась в базе. Здесь же два harness: agent harness обеспечивает работу модели с инструментами, evaluation harness запускает испытания и собирает оценки. Проверяем мы модель вместе с её обвязкой. 🔸 Чем оценивать Кодом, LLM-судьёй и человеком. Для coding agents естественны тесты; для исследовательских — проверка опоры на источники и полноты; для диалоговых важны и результат, и качество общения. Оценки LLM нужно калибровать по человеческим. 🔸 Что измерять Capability evals показывают, чему агенту ещё предстоит научиться; regression evals защищают уже освоенное. А pass@k и pass^k отвечают на разные вопросы: получился ли хотя бы один успех за k попыток или успешны все k. 🔸 Как построить и поддерживать Авторы советуют начать с 20–50 реальных случаев, явно определить успех, изолировать прогоны и читать трассы. Ошибаться может и сам grader. Дальше набор нужно обновлять, а картину дополнять production-мониторингом, обратной связью и человеческой оценкой. Теперь мои заметки по ходу чтения, которые есть в приложенном PDF 1️⃣ Знакомая инженерия Изоляция прогонов и сходство среды с production напоминают правила тестирования, eval-driven development — TDD. Даже организация работы знакомая: отдельная команда поддерживает инфраструктуру, продуктовые команды приносят задачи. Привет platform teams и stream-aligned teams. Только зелёный результат одного прогона здесь ещё не обещает зелёного следующего. 2️⃣ Ожидания тоже надо сформулировать На ранней стадии пользователей может ещё не быть, а критерии качества только складываются. Evals помогают задать этот уровень и дальше удерживать его. Особенно полезно при частых обновлениях моделей: появляется свой набор проверок для решения о переходе. 3️⃣ DOM и скриншоты Раньше я считал, что скриншоты дороже, а работа через DOM дешевле. У авторов есть обратный пример: выгрузка всего DOM может съесть больше токенов. Тут хочется отдельно считать объём переданных данных, задержку и число действий — универсального победителя из этого не получается. 4️⃣ OR, AND и независимость Метрику pass@k удобно понимать как логический OR, pass^k — как логический AND. Но расчёт p^k требует независимых попыток с одинаковой вероятностью успеха. При p = 0,75 три успеха подряд дают примерно 42% только с этими допущениями. Общая среда, оставшиеся файлы или память между попытками могут их нарушить. 5️⃣Траектории Симулятор пользователя напомнил мои разборы "SWE-Together" и "SWE-Interact". В статье рядом живут два совета: оценивать процесс и не навязывать агенту конкретную последовательность шагов. Я бы совместил их через проверку свойств процесса: агент мог начать исправление бага с теста или чтения кода, но заявление «проверено» должно относиться к окончательной версии. А права доступа и запрет записи за пределами рабочей области стоит обеспечивать самим harness: успешный eval не заменяет блокировку запрещённого действия. #AI4SDLC #Agents #Evals #Research #Engineering #PlatformEngineering

Harness Engineering: анатомия кодинг-агентов (Рубрика #AI4SDLC) Сколько в работе кодинг-агента зависит от модели, а сколько — от среды вокруг неё? В статье на 80+ страниц "Harness Engineering: Anatomy, Architecture, and Evolution of Coding Agents" интересна попытка разобрать эту среду по исходному коду. Paul Barbaste и коллеги из Wavestone AI Lab и Inclusive Brains рассматривают 11 агентных систем, включая Claude Code, Codex, OpenHands и Pi, а отдельно — метаобвязку Omnigent. Делают это они по срезу на июль 2026 года. Авторы изучают архитектуру агентов по исходному коду, а общего эксперимента на одинаковых задачах здесь нет. В статье я бы выделил четыре части 🔸Анатомия harness Семь подсистем: рабочий цикл, интеграция с LLM, инструменты, память и контекст, безопасность, оркестрация и расширения. Карта помогает понять, где именно различаются агенты: как применяют правки, восстанавливают работу и решают, что задача завершена. 🔸 Инженерные механизмы Как сжимать историю, не потеряв цель; кому разрешать записывать долговременную память; как разделять стабильную и меняющуюся части промпта ради кэша. Особенно важен переход от текстовой просьбы соблюдать правило к проверке в исполняемом коде. 🔸Общие паттерны и компромиссы По аудиту авторов, в изученных системах нет универсальных агентных фреймворков в основном runtime и векторного поиска по коду. Вместо последнего — поиск по тексту, файлам и структуре программы. А простой агент может обходиться небольшим циклом и shell-инструментом; продуктовая сложность добавляет безопасность, восстановление и интеграции. 🔸 Платформенный поворот SDK, skills, плагины, перенос сессий и корпоративные политики превращают обвязку в среду, поверх которой строят другие продукты. Авторы считают, что конкуренция смещается к экосистемам. Но сами же описывают метаобвязки, способные сделать отдельные harness заменяемыми. К посту приложен PDF с моими отмеками и рукописными пометками, где я на полях оставлял вопросы к выводам авторов и идеи, которые хочется проверить. Вот несколько точек для обсуждения. 1️⃣ «А гипотезы какие?» к выводам авторов (на странице 2) Если в выбранных системах нет LangChain или векторного поиска, следует ли из этого, что они не нужны? Отсутствие технологии в выборке ещё не доказывает её бесполезность. В рекомендациях авторы местами делают более сильный вывод, чем позволяет метод исследования. 2️⃣ «Что измерять кроме success rate?» к резульатам бенче (на странице 58) На полях у меня предположение: возможно, задачи SWE-bench уже слишком просты для такого сравнения. Это ещё надо проверять. Но стоимость принятого решения, число вмешательств человека и способность восстановиться после сбоя точно заслуживают отдельного измерения. Одинаковый процент решённых задач может скрывать очень разный опыт работы. 3️⃣ «Где здесь сетевые эффекты?» при обсуждении платформенной экономике в harnesses (на странице 61) Накопленная память и настройки усложняют переход между продуктами. А больше пользователей может привлекать авторов расширений, делая платформу полезнее. Это разные механизмы. Причём переносимые skills могут усиливать всю экосистему и одновременно ослаблять зависимость от конкретной обвязки. 4️⃣ Про совместную эволюцию модели и harness (на страницах 55-56) По мере улучшения модели часть обвязки, возможно, стоит упрощать. Хорошая тема для эксперимента: какие механизмы действительно помогают, а какие продолжают компенсировать уже исчезнувшие ограничения? Мы это уже разбирали в одной из прошлых серий Research Insights Завтра, 20 октября, в 11:30 по Москве будет прямой эфир с разбором этого whitepaper. Пройдёмся по архитектуре, спорным выводам и пометкам в PDF. Приходите со своими вопросами. #AI4SDLC #Agents #Architecture #Research #PlatformEngineering

Как меняется работа внутри Anthropic (Рубрика #AI) Прочитал статью "How Employment Is Changing at Anthropic", опубликованную 16 октября. Многое перекликается с [эфиром 3 AImigo про AI-native компанию и моим лонгридом: агенты ускоряют исполнение, а дальше приходится менять процессы, роли и правила принятия решений. Здесь интересно посмотреть, как это выглядит внутри самой Anthropic. Для этого авторы собрали внутренние данные о найме, использовании AI, результатах работы, встречах и коммуникациях, дополнив их 17 интервью. У исследования четыре связанных сюжета. 🔸 Кого нанимают и куда переводят Доля джунов среди новых технических сотрудников упала с 27% до 9%. Это доля найма, не число увольнений. Нетехнические сотрудники создают свои инструменты, менеджеры чаще коммитят код, а целые команды меняют занятие: авторы продуктовых текстов после автоматизации перешли к промптам и evals. 🔸 Что происходит с производительностью Растёт число коммитов, обработанных договоров, закрытых сделок на сотрудника. Авторы сравнивают работу людей до и после внедрения агентов с теми, кто их ещё не внедрил. Дизайн интересный, но группы сформировались неслучайно: большой новый проект мог одновременно увеличить output и подтолкнуть человека к агентам. 🔸 Во что превращается рабочий день Человеческое внимание становится узким местом. Доля интерактивных сессий Claude, посвящённых meta-work — инструкциям, проверкам, мониторингу агентов, — выросла с 10% до 22%. Это доля сессий, не рабочего времени. Даже у технических специалистов без управленческой роли время встреч выросло на 16% за год. Агенты требуют координации, люди продолжают договариваться между собой. 🔸 Что делать работодателю Делиться выгодами автоматизации, заранее замечать изменение ролей и переводить сотрудников на новые задачи. Авторы признают: защита уже работающих людей не помогает тем, кого вообще перестали нанимать. Для рынка труда понадобятся решения за пределами одной компании. А дальше уже расскажу про мои пометки на полях, приложенного PDF 1️⃣ Output ещё надо превратить в outcome — об этом писал еще в «Token burn как proof of work». Больше кода само по себе не отвечает на вопрос, что стало лучше у клиента. И даже рост выручки на сотрудника не изолирует эффект AI от роста бизнеса. Это исследование одной быстрорастущей компании, которая сама продаёт изучаемую технологию. 2️⃣ Meta-work хорошо ложится в наш разговор про Loop Engineering в Research Insights. Можно весь день обслуживать очередь вопросов от агентов. А можно проектировать цикл: задача, исполнение, проверка, исправление, обращение к человеку. Мне интересно, уменьшается ли после этого человеческое внимание на один принятый результат. Само по себе увеличение числа инструкций пока мало что доказывает. 3️⃣ Любопытно сближение ролей: менеджеры становятся более hands-on, а инженеры получают команды агентов. Отсюда понятнее спрос на самостоятельность и качество решений. Как их оценивать, обсуждали в «AI нанимает AI» (тут пост с материалами). Только откуда возьмётся это суждение у начинающих, если задачи, на которых раньше набирали опыт, уже автоматизированы? Это уже вопрос нашего выпуска «Джун без простых задач». И как всем этим управлять, если реальные решения остаются в личных переписках, а агентам достаются старые документы? 4️⃣ Самый важный для меня нюанс — про стимулы. Акции быстрорастущей Anthropic дают сотрудникам интерес в её успехе. Как перенести этот договор на обычную компанию? Внутренняя ротация тоже может существовать на словах, а на деле оказаться остановкой перед увольнением. Нужны реальные новые роли и возможность в них перейти. Если я автоматизирую собственную работу, какую часть выигрыша получу и что буду делать дальше? Вот этот вопрос я бы задал раньше, чем ставить сотрудникам очередной KPI по использованию AI. #AI #Research #Agents #Engineering #Management