Research Insights Made Simple

Alexander Polomodov
  • 0.0 (0)
  • Natural Sciences
  • Updated Daily

Подкаст от Александра Поломодова, технического директора и Fellow, с обсуждением научных статей из области computer science и engineering. Каждый эпизод подкаста посвящен одной статье и в каждом эпизоде есть приглашенный гость-эксперт, который собаку съел в этой теме. Обычно эпизод длится час-полтора и может сопровождаться схемами из статьи или быть чисто в разговорном жанре.

  1. 1d ago

    Agent Skills и Open Knowledge Format (OKF): скиллы, знания и доверие

    Агент умеет писать код и вызывать инструменты. Но как передать ему рабочую процедуру команды? Где хранить знания о системе, которые меняются независимо от этой процедуры? И чем подтвердить, что агент выполнил задачу правильно? 22 октября в 43 выпуске подкаста Research Insights Made Simple проведу прямой эфир с Максимом Смирновым, с которым мы летом обсуждали Loop Engineering https://www.youtube.com/watch?v=hnFLfiJOtQE о том, как проектировать циклы, которые запускают агентов, проверяют результат и возвращают работу на доработку. Теперь продолжим разговор — через Agent Skills и Open Knowledge Format (OKF). Максим — ИТ-архитектор, автор Telegram-канала «Архитектура ИТ-решений» https://t.me/it_arch. В прошлом — руководитель департамента ИТ-архитектуры «Билайн» и главный архитектор информационных систем Банка России; спикер, автор и преподаватель курсов по ИТ-архитектуре. В новом выпуске мы разберём, из чего состоит навык: SKILL.md, описание, инструкции, вспомогательные файлы и скрипты. Посмотрим, как агент выбирает подходящий навык, когда подгружает подробности и почему успешная загрузка файла ещё не означает успешного выполнения задачи. В программе: Чем отличаются инструкции проекта в AGENTS.md, навыки, инструменты MCP и обработчики событий.Как проверять не только результат навыка, но и то, вызывается ли он в нужной ситуации.Что появилось вокруг Agent Skills: каталоги, установка, автоматические проверки и оценка качества.Как OKF связывает Markdown-файлы в граф знаний и описывает происхождение и актуальность сведений.Почему отметка времени или подтверждение в метаданных сами по себе не гарантируют истинность.Что означает квитанция выполнения вычисления, кто её проверяет и где остаётся ответственность команды.Сквозной пример — утренний разбор упавшего CI: какие инструкции нужны агенту, откуда он узнаёт правила проекта и как мы проверяем предложенное исправление. Сопоставим Agent Skills, OKF v0.2 и предложение Knowledge-as-Skill. Опираемся на спецификации, документацию и примеры по состоянию на конец октября 2026 года. Отделим свойства форматов от возможностей конкретных реализаций. Приходите с кейсами: какие процедуры вы уже передаёте агентам и какие знания они регулярно теряют?

    Agent Skills и Open Knowledge Format (OKF): скиллы, знания и доверие

  2. 2d ago

    Оценки агентов: как понять, что агент справился

    Агент написал «готово». Но изменился ли нужный файл, появилась ли бронь в базе и выполнены ли условия задачи? Красивый ответ ещё не означает, что работа сделана. А низкий балл иногда говорит о сломанной проверке, а не о слабом агенте. В этом выпуске разбираем руководство Anthropic «Demystifying evals for AI agents» и продолжаем серию об обвязках агентов. После разговора об их устройстве переходим к вопросу: как доказать, что система работает и очередная правка действительно её улучшила? Обсудим: Чем итог работы отличается от траектории: что агент оставил в среде и как к этому пришёл.Почему оценивается модель вместе с обвязкой, инструментами и настройками среды.Как устроены набор задач, отдельная задача и повторные попытки — и почему у процентов успеха бывают разные знаменатели.Когда подходят программные проверки, модельные судьи и оценка человека; как проверять самих проверяющих.Чем pass@k отличается от pass^k: хотя бы один успех и стабильный успех во всех попытках отвечают на разные вопросы.Зачем изолировать прогоны, читать траектории и превращать реальные сбои в тестовые задачи.Отдельно поговорим о доверии к оценкам: как отличить регрессию от случайного разброса, заметить неверные критерии и не принять рост балла за улучшение продукта. В эпилоге обратимся к более поздним материалам Anthropic — Petri v2, измерению автономности агентов и разбору апрельских регрессий. Это практическое руководство, основанное на опыте команды и клиентов Anthropic. Разделим рекомендации авторов, результаты отдельных работ и наши выводы для разработки собственных агентов. Эфир для разработчиков, технических руководителей и всех, кто хочет проверять AI-агентов на реальных задачах. Приходите с примерами: что в вашей системе считается доказательством успеха?

    Оценки агентов: как понять, что агент справился

  3. 3d ago

    Анатомия агента: семь обязанностей обвязки

    Почему одной языковой модели недостаточно, чтобы получить работающего агента для разработки? Кто решает, какие инструменты ему доступны, что попадёт в контекст, когда спросить разрешение и как продолжить работу после сбоя? На эфире разберём препринт «Harness Engineering: Anatomy, Architecture, and Evolution of Coding Agents. A Source-Code Study of Eleven Systems». Авторы изучили исходники одиннадцати систем: от Claude Code, Codex CLI и Gemini CLI до Aider, OpenHands и mini-SWE-agent. Получился атлас того, что находится между моделью и рабочей средой. В центре разговора — семь обязанностей обвязки: цикл работы, интеграция с моделью, инструменты, управление контекстом, безопасность, координация и расширения. Посмотрим, как они реализованы в небольших агентах и крупных продуктах, где достаточно простого решения и откуда берётся дополнительная сложность. Обсудим: Почему минимальный агент может быть очень коротким, а промышленная система быстро обрастает кодом.Как инструменты редактирования помогают модели исправлять ошибки — или создают новые.Чем разрешение выполнить действие отличается от изоляции процесса.Как агенты сохраняют контекст, делегируют работу и подключают расширения.Что повторное изучение тех же систем говорит об эволюции обвязок.Какие архитектурные наблюдения стоит превратить в эксперименты на собственных задачах.Важная граница: это исследование исходников, без общего прогона всех систем на одинаковых задачах. Оно помогает понять устройство агентов, но само по себе не доказывает, какая архитектура эффективнее. Отдельно обсудим ограничения метода, соседние работы и открытые вопросы. Эфир будет полезен тем, кто выбирает агента для команды, строит собственную обвязку или хочет понимать, что происходит за интерфейсом AI-инструментов разработки. Приходите с вопросами и примерами из практики.

    Анатомия агента: семь обязанностей обвязки

  4. 4d ago

    Anthropic: что остаётся человеку в компании агентов

    Агенты пишут всё больше кода, сотрудники собирают инструменты для управления ими, а доля джунов в техническом найме снижается. Anthropic выпустила исследование о том, как AI меняет работу внутри самой компании. И один из самых интересных вопросов здесь — что происходит с человеком, когда исполнение задач становится всё дешевле, а его внимание остаётся ограниченным. В выпуске разберу "How employment is changing at Anthropic" и продолжу разговор, который мы начали в Developer Productivity for Humans: как понять, что рост активности помогает людям получать полезный результат? Сначала посмотрим на саму статью: что авторы узнали о найме, продуктивности, рабочих процессах и изменении ролей;как устроено исследование: внутренние данные, интервью и сравнение сотрудников до и после внедрения агентов;что показывают графики агентских часов, объёма кода и качества — и какие выводы из них делать рано;почему возникает всё больше работы по организации работы агентов и куда уходит человеческое внимание.А дальше вернусь к вопросам из моих пометок на полях. Как устроить рабочий цикл, чтобы не проверять вручную каждый шаг агента? Где будущий самостоятельный инженер получит опыт, если простые задачи уже автоматизированы? И на каких условиях сотруднику выгодно автоматизировать собственную работу — что он получает взамен и есть ли для него следующая роль? Это исследование одной быстро растущей компании, которая сама создаёт AI. Его данные интересны именно в деталях; переносить их на весь рынок труда будем осторожно. Приходите с вопросами и примерами из своих команд. Особенно интересно, какая работа появилась у вас после внедрения агентов, хотя её не было в первоначальном обещании «сэкономить время». Предыдущие разговоры: Developer Productivity for Humans — выпуск #30AI-native компания — что это значит на практикеДжун без простых задач — как входить в IT в эпоху AI

    Anthropic: что остаётся человеку в компании агентов

  5. Oct 15

    Scion - замена git внутри Anthropic для агентной разработки

    Агенты пишут код, а инфраструктура разработки начинает захлёбываться. В Anthropic дошли до собственной системы контроля версий — Scion. И агенты же помогли её построить. 15 октября 2026 года в сольном выпуске Research Insights Made Simple #39 разберу «Redesigning source control at Anthropic». Это инженерный отчёт команды о том, как меняется работа с кодом, когда основными клиентами репозитория становятся постоянно подключённые агенты и CI. Меня здесь особенно интересуют две вещи: знакомые идеи баз данных в устройстве Scion и изменение гарантий вокруг merge. Что мы выигрываем, если быстрее принимаем изменения в общую историю? И что после этого обязаны проверить до деплоя? В выпуске: почему Anthropic перенесла операции с историей, merge и rebase на сервер;как устроены журнал изменений, производные структуры чтения и кеширование неизменяемых объектов;что именно ускорилось на итоговом графике и почему эти числа нельзя переносить на всю разработку;какие гарантии меняются при переходе к post-merge проверкам и как связать допуск к релизу с конкретным проверенным артефактом;как дать агенту стабильную базу и при этом раньше замечать конфликты с движущимся main.Разбор для инженеров, архитекторов и платформенных команд, которые внедряют кодинговых агентов и хотят понять, что придётся менять вокруг них. Автор и ведущий — Александр Поломодов. Статья Anthropic: https://www.anthropic.com/engineering/redesigning-source-controlВсе выпуски Research Insights Made Simple: https://polomodov.tech/research-insights/Timeline 00:00 - Зачем Anthropic своя система контроля версий 03:40 - Рост нагрузки от агентов и CI 04:34 - Онлайн-клиенты и серверные операции 07:10 - Запрос API вместо скачивания репозитория 08:52 - Changeset, Spanner и производные данные 12:37 - Ссылки и кеши неизменяемых объектов 15:26 - Что означает мгновенная доступность 17:34 - Как читать график ускорений 18:21 - Миграция, люди и архитектурные ограничения 20:25 - Ревью намерений и роль инженеров 21:49 - Агенты для наблюдения за компонентами 23:00 - Проверки после слияния и до развёртывания 25:51 - Конфликты поведения и открытые вопросы 27:07 - Границы применимости Scion 30:20 - Что остаётся узнать о полном цикле разработки

    Scion - замена git внутри Anthropic для агентной разработки

  6. Oct 13

    Проектирование обвязки для кодинговых агентов: что даёт обвязка

    В очередном эпизоде из серии об обвязках агентов Research Insights Made Simple поговорим про опубликованное в сентябре 2026 года исследование "An Empirical Study of Harness Design for Coding Agents" (https://arxiv.org/abs/2609.20804v1). Авторы фиксируют цикл агента и меняют три компонента: планирование, инструменты и управление контекстом. Они сравнивают 176 экспериментальных настроек на четырёх моделях и двух наборах задач — SWE-bench Verified и Terminal-Bench 2.1. Обсудим Когда управление контекстом спасает задачу от переполнения окна.Почему сокращение старых ответов инструментов перед пересказом может снизить стоимость.Как план помогает слабой модели продолжать работу, а сильной — вовремя остановиться.Когда нужны готовые инструменты, а когда достаточно bash.Как по траектории агента найти причину сбоя и проверить пользу изменения на своих задачах.Выводы относятся к моделям, задачам и реализациям из исследования. Разберём, что стоит проверить перед переносом этих результатов в собственную систему. Все выпуски Research Insights Made Simple: https://polomodov.tech/research-insights Timeline 00:00 - Зачем разбирать обвязку на компоненты 02:07 - Общий цикл и три переменные эксперимента 03:19 - 176 настроек и неполный перебор сочетаний 04:40 - Модели, задачи и расчёт стоимости 07:52 - План вне истории разговора 09:47 - Готовые инструменты и bash 11:33 - Пять политик управления контекстом 13:51 - Что сохраняют и когда сокращают историю 15:43 - Предотвращённый обрыв и стоимость контекста 19:03 - Почему редко возвращают вытеснённые события 20:55 - План меняет момент остановки 24:27 - Инструменты: результат зависит от модели и задач 29:21 - Менять компоненты по одному 33:24 - Анализ траекторий и причины сбоев 40:09 - Выводы, ограничения бенчмарка и свои эксперименты

    Проектирование обвязки для кодинговых агентов: что даёт обвязка

  7. Oct 12

    AI и платформа данных / Как подключить AI ко всей совокупности данных организации

    12 октября в Research Insights Made Simple снова встречаемся с Колей Головым и продолжаем разговор про платформы данных. В этот раз разберём, как объединить операционные базы, аналитику и AI-агентов и можно ли при этом избавиться от привычного зоопарка интеграций. Николай Голов - директор по продукту одной из датаплатформ, доступных на российском рынке. Раньше он руководил дата-платформами в Avito и ManyChat, преподаёт базы данных и системы хранения в Harbour.Space (https://harbour.space/faculty/Nikolay-Golov). Так что обсудим и устройство технологий, и практику построения платформ, которые потом кому-то поддерживать. На картинке всё выглядит заманчиво: оставляем PostgreSQL для транзакций, изменения из остальных систем отправляем через CDC в объектное хранилище, сверху ставим Lakehouse и подключаем агентов через MCP. Данные собраны, инструменты доступны, можно задавать вопросы. Правда, между «сложили всё в S3» и «агент правильно понял бизнес» ещё помещается довольно много инженерной работы :) Посмотрим, как к этой задаче подходят Databricks, Snowflake, ClickHouse, Microsoft Fabric, Google, AWS и Oracle. У кого-то объединение происходит на уровне хранения, у кого-то через репликацию и общие запросы, а кто-то собирает всё внутри одной СУБД. За похожими словами про единую платформу скрываются разные архитектуры и разные ограничения. Поговорим о том Где проходят границы между OLTP, аналитикой и агентным бэкендом;Что на практике означают «одна копия данных» и zero-ETL;Когда CDC и Lakehouse упрощают жизнь, а когда добавляют ещё одну систему, за которой надо следить;Какую роль могут играть PostgreSQL, DuckLake и S3 в собственной платформе;Что нужно агенту помимо доступа к таблицам: определения показателей, права, контекст и возможность проверить результат.Хочется понять, какую сложность эти подходы действительно убирают и какая просто переезжает в другое место. Выпуск будет полезен архитекторам, инженерам данных и руководителям, которые выбирают платформу или подключают AI к существующим данным. Timeline 00:00 - Данные организации для AI-агента 02:47 - Четыре подхода вместо одного правильного решения 05:16 - Классическое хранилище и подготовленные витрины 08:45 - CDC, ETL и размер компании 11:15 - Федеративные запросы: Presto и Trino 16:17 - Универсальная СУБД и ограничения HTAP 18:23 - Единый слой хранения и текущее состояние таблиц 26:09 - Microsoft и AWS: передача изменений 34:51 - ClickHouse: федеративный доступ и репликация 40:04 - Google: операционные базы, BigQuery и стоимость 47:34 - Oracle и SAP HANA: нагрузки внутри одной СУБД 53:56 - Databricks: Neon, Mooncake и общий слой 1:00:17 - Snowflake и PostgreSQL 1:02:25 - Сравнение подходов и пределы общего хранения 1:07:42 - Собственная платформа и открытые форматы

    AI и платформа данных / Как подключить AI ко всей совокупности данных организации

  8. Oct 9

    Проектирование обвязки для длительной (автономной) разработки приложений

    Как организовать работу кодингового агента, чтобы он мог несколько часов создавать приложение, проверять результат и исправлять ошибки? Продолжаем серию про инженерную обвязку агентов. И здесь мы разберём статью Anthropic Harness design for long-running application development. Её автор экспериментирует с разделением планирования, разработки и оценки результата. В прямом эфире обсудим: - Как устроены роли planner, generator и evaluator. - Зачем до написания кода согласовывать критерии готовности и как проверять работающее приложение. - Можно ли формализовать вкус при оценке дизайна и насколько надёжен отдельный агент-критик. - Сколько стоят дополнительные итерации и что показывают приведённые сравнения. - Почему с усилением моделей некоторые части обвязки становятся лишними. А в конце поговорим о следующем шаге: сможет ли агент сам улучшать собственный harness — и кто тогда будет проверять эти улучшения? Timeline 00:00 - Четвёртый разбор обвязок: приложения по одному запросу 01:33 - Две задачи Anthropic Labs 03:04 - Идея из GAN: отдельный критик 06:22 - Предел контекста и снисходительная самооценка 08:10 - Сжатие, сброс и стоимость передачи работы 12:40 - Четыре критерия качества дизайна 15:00 - Итерации фронтенда и выбор варианта 17:16 - Планировщик, генератор и оценщик 18:39 - Контракт спринта до реализации 20:32 - Ретро-игры: двадцать минут против шести часов 23:40 - Почему проверяющему нужна настройка 25:43 - Opus 4.6: проверка и упрощение компонентов 30:46 - Звуковая станция и оценщик, который не слышит 34:41 - Автономность и внешний контроль риска 38:56 - Журнал событий и дальнейшая эволюция обвязки

    Проектирование обвязки для длительной (автономной) разработки приложений
See All (43)

About

Подкаст от Александра Поломодова, технического директора и Fellow, с обсуждением научных статей из области computer science и engineering. Каждый эпизод подкаста посвящен одной статье и в каждом эпизоде есть приглашенный гость-эксперт, который собаку съел в этой теме. Обычно эпизод длится час-полтора и может сопровождаться схемами из статьи или быть чисто в разговорном жанре.

Information