Харнесс (Agent Harness) 🧗 #ИИНЦИКЛОПЕДИЯ Программная оболочка, внутри которой модель превращается в агента. История появления Слово пришло из альпинизма: harness — страховочная обвязка. Устоявшегося русского термина пока нет — говорят «харнесс» или «обвязка». Первым популярным харнессом стал Claude Code, и нейтральным он не был: его собирали под модели одной лаборатории. За 2026 год тема выросла в отдельную дисциплину, harness engineering: обзор насчитывает 110+ работ. Почему это важно Формула простая: агент = модель + харнесс. Разрыв уже измерили. GPT-5.5 в обвязке Cursor выдаёт 87.2% рабочего кода, та же самая модель в нативном Codex — 61.5%. Двадцать шесть пунктов, веса не тронуты. Это больше, чем разрыв между поколениями моделей. Из чего состоит: - Системный промпт — инструктаж новичка в первый день. Уходит в модель заново с каждым запросом - Инструменты — код, который модель может вызвать. Харнесс их описывает, но не решает, когда применять .. решает модель - Агентный цикл — модель смотрит на результат вызова и сама решает: искать ещё раз, посчитать, закрыть задачу - Слой трансляции — позволяет подставить в тот же цикл модель Anthropic, OpenAI или открытую Применение на практике В мае вышел Harness-Bench: 106 задач, шесть харнессов на восьми моделях, 5194 прогона. Лучшая обвязка — 76.2%, худшая — 52.4%. Победитель потратил меньше токенов, чем отставшие: длинная траектория значит, что агент не сходится. И сильные модели держат удар при плохой обвязке, а слабые проваливаются .. харнесс окупается тем сильнее, чем дешевле модель. В июне агент правил собственную обвязку по трассам своих провалов при замороженной модели: проходимость выросла с 40.5% до 61.9%. Подводные камни Харнесс чинит работоспособность, но не безопасность: в том же замере функциональность выросла на 26 пунктов, а доля безопасного кода — с 20.1% до 23.5%. Оба агента писали дырявый код в четырёх случаях из пяти. Без внешнего эталона модель сверяет ответ сама с собой. В бенчмарке JuliaHub модель тихо сократила время симуляции с 5 секунд до 3 и проверялась на укороченном отрезке. Проверки сошлись. Сравнивать модели по лидербордам без указания харнесса бессмысленно — об этом в мае вышла отдельная работа. Что почитать/посмотреть: - Harness-Bench, arXiv 2605.27922 — самый честный замер обвязок - Stop Comparing LLM Agents Without Disclosing the Harness — почему лидерборды врут - Harness engineering у Мартина Фаулера — как строить проверки, а не только читать про них - Документация хуков Claude Code — если хотите проверки, которые агент не обойдёт Сергей Булаев AI 🤖 - об AI и не только

Это пожалуй первый skill который я желаю вам никогда не устанавливать /fuck-cancer — помогает пациентам с раком разбираться в лечении, документах, следующих шагах и вопросах к врачам При первом запуске описываешь симптомы или если есть выписку/биопсию Агент анализирует все вводные и заводит один единственный файл как источник правды Который хранится либо локально в markdown, либо в облаке Google Doc Этот файл-бриф делится на 5 частей:

1/ Инфо о пациенте и лечащей команде 2/ Что делать дальше: 3 конкретных действия 3/ Разделение на известно/неизвестно 4/ Объяснение медицинских терминов 5/ Журнал последних событий, решений и изменений

Помимо инструкций, агенту еще доступен единственный тул: Clinical Trials API Для поиска наиболее подходящих клинических исследований под конкретный случай. На основе типа рака и стадии/биомаркера, страны и региона. Скилл специально запрещает основывать ответ на SEO-сайтах, соцсетях или ИИ-медицинских страницах. Если агент и выходит в интернет то только в официальных национальных источниках, регуляторах вроде FDA/EMA и по сайтам академических онкоцентров. @tips_ai

Я все чаще замечаю забавную инверсию. Раньше в моих проектах копились идеи, которые я не успевал реализовать. Теперь coding-агенты реализуют идеи быстрее, чем я успеваю решить, хочу ли я потом с этими изменениями жить. В списке моих диалогов с Codex лежит немало почти готовых фич. Там проходят тесты, работает интерфейс, обновлена документация. Осталось «только проверить». Проверить - это не посмотреть, что тесты проходят (агент их уже сам прогнал). Нужно еще понять, не появилась ли в проекте новая лишняя концепция? Хорошо ли изменение сочетается с остальной системой? Готов ли я поддерживать этот код через год? И вообще - нужна ли мне эта фича после того, как я увидел её реализованной? Поэтому я откладываю проверку «на потом», которое обычно не наступает. Раньше сырая идея оставалась хотелкой в заметках и ничего не стоила. Теперь она за десять минут превращается в ветку с кодом, тестами, документацией и потенциальными последствиями. Вот и получается, что идеи теперь копятся не перед реализацией, а после неё - перед бутылочным горлышком моего внимания и времени. Причём у такого кода короткий срок годности. Проект продолжает меняться, ветка отстаёт все больше, а контекст постепенно выветривается из головы. Проверить изменение завтра сложнее, чем сегодня, а через неделю уже дешевле выкинуть и сделать заново. Я слышал похожее и от других команд. У некоторых после внедрения coding-агентов число открытых PR выросло в 5–7 раз. Генерация кода в 2026 году ускорилась, а пропускная способность человеческого внимания - пока нет. Поэтому сейчас я стараюсь нарезать задачи так, чтобы агент приносил не целую реализованную хотелку, а следующий минимальный reviewable slice: одно понятное изменение и достаточно сопроводительного контекста, чтобы проверить его за один подход. По расходу токенов может выходить забавно: Codex нередко тратит до 95% процентов токенов на поиск такого маленького, независимого и проверяемого следующего шага, который я одобрю. И только процентов пять уйдет на его реализацию. Оно того стоит. Такой кусочек легче проскальзывает через бутылочное горлышко внимания и начинает приносить пользу. Большая же фича, даже полностью написанная агентом, рискует просто пополнить залежи рабочего, но быстро устаревающего кода. А как вы решаете проблему с накапливающимися фичами и PR от coding-агентов - или у вас её нет? Ваш, @llm_under_hood 🤗