Оригинальное название: Тонкий Harness, Толстые навыки
Оригинальный автор: Гарри Тан
Перевод: Пегги, BlockBeats

Редакторская заметка: когда «более сильные модели» становятся стандартным ответом в индустрии, эта статья предлагает иное суждение: настоящая разница в производительности в 10, 100 или даже 1000 раз заключается не в самой модели, а в целостной системе, построенной вокруг модели.

Автор статьи Гарри Тан, в настоящее время президент и CEO Y Combinator, долгое время занимается AI и экосистемой ранних стартапов. Он предложил структуру «толстые навыки + тонкий harness», разбивая применение AI на ключевые компоненты: навыки, исполнительные рамки, маршрутизация контекста, разделение задач и сжатие знаний.

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

Более важно, что этот метод не остается на концептуальном уровне, а проверяется в реальных сценариях: сталкиваясь с задачами обработки и сопоставления данных тысяч стартаперов, система с помощью цикла «Чтение - Систематизация - Оценка - Запись» достигла уровня, близкого к человеческому аналитическому мышлению, и продолжала самооптимизироваться без необходимости переписывать код. Эта «учебная система» превращает ИИ из разового инструмента в инфраструктуру с эффектом сложных процентов.

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

Следующее — оригинал:

Стив Йегге сказал, что эффективность людей, использующих AI-программные агенты, «в 10 до 100 раз выше, чем у тех, кто просто пишет код с помощью курсора и чата, примерно в 1000 раз выше, чем у инженеров Google 2005 года».

Примечание: Стив Йегге - влиятельный инженер-программист в Силиконовой долине, технический блогер и критик инженерной культуры, известный своими острыми, длинными, насыщенными личным стилем техническими статьями. Он работал в таких компаниях, как Amazon и Google, а затем присоединился к Salesforce, позже к стартапам в области ИИ; также он был одним из ранних сторонников проекта Dart.

Это не преувеличение. Я видел это своими глазами и пережил сам. Но когда люди слышат о такой разнице, они часто ищут причины в неправильном направлении: более сильные модели, более умный Claude, больше параметров.

На самом деле, модель, которая увеличивает эффективность в 2 раза, и модель, которая увеличивает в 100 раз, используют одну и ту же модель. Различие не в «интеллекте», а в «архитектуре», и эта архитектура настолько проста, что ее можно записать на карточке.

Harness (исполнительная рамка) — это и есть сам продукт.

31 марта 2026 года Anthropic случайно опубликовали полный исходный код Claude Code на npm — в общей сложности 512 000 строк. Я прочитал его. Это подтвердило то, о чем я всегда говорил в YC (Y Combinator): настоящий секрет не в модели, а в «слое, обертывающем модель».

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

Этот слой «обертывания» называется harness (исполнительная рамка). А все, что действительно должны спрашивать строители ИИ, это: какие вещи должны быть в harness, а какие следует оставить снаружи?

У этого вопроса на самом деле есть очень конкретный ответ — я называю его: тонкая рамка (thin harness), толстые способности (fat skills).

Пять определений.

Узкое место никогда не связано с интеллектом модели. На самом деле модель давно знает, как рассуждать, интегрировать информацию и писать код.

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

1. Файл навыка (Skill file)

Файл навыка — это повторно используемый markdown-документ, который обучает модель «как делать что-то». Обратите внимание, это не «что делать» — это предоставляет пользователь. Файл навыка предоставляет процесс.

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

Например, существует навык под названием /investigate. Он включает в себя семь шагов: определение диапазона данных, построение временной линии, создание диаризации для каждого документа, интеграция, аргументация с обеих сторон, ссылки на источники. Он принимает три параметра: TARGET, QUESTION и DATASET.

Если вы направите его на ученого, занимающегося безопасностью, и 2 100 000 следственных писем, он станет медицинским исследовательским аналитиком, чтобы выяснить, подвергался ли свисток преследованию.

Если вы направите его на фиктивную компанию и документы о подаче в Федеральную избирательную комиссию (FEC), он снова станет юристом-следователем, отслеживающим политические пожертвования, связанные с совместными действиями.

это все еще тот же навык. Это все еще те же семь шагов. Это все еще тот же файл markdown. Навык описывает процесс принятия решений, а то, что действительно воплощает его в реальном мире, - это параметры, передаваемые при вызове.

Это не проектирование подсказок, а проектирование программного обеспечения: просто здесь markdown используется как язык программирования, а человеческое суждение — как среда выполнения. На самом деле, markdown даже лучше подходит для упаковки способностей, потому что он описывает процессы, суждения и контексты, что как раз и является языком, который модель лучше всего «понимает».

2. Harness (исполнительная рамка)

Harness — это слой программы, который управляет работой LLM. Он выполняет только четыре задачи: заставляет модель работать в цикле, читать и записывать ваши файлы, управлять контекстом и выполнять ограничения безопасности.

Вот и все. Это «тонкий» (thin).

Обратная модель такова: толстый harness, тонкие навыки.

Вы, вероятно, видели такие вещи: более 40 определений инструментов, только описание занимает половину окна контекста; универсальный God-tool, который требует от 2 до 5 секунд для одного прохождения MCP; или, возможно, каждый endpoint REST API упакован как отдельный инструмент. Результат: расход токенов увеличивается в три раза, задержка увеличивается в три раза, а уровень неудач также увеличивается в три раза.

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

Например, Playwright CLI, где каждое действие браузера занимает всего 100 миллисекунд; а не Chrome MCP, где сделать один снимок экрана → найти → кликнуть → подождать → прочитать занимает 15 секунд. Первый вариант быстрее в 75 раз.

Современное программное обеспечение больше не нужно «оттачивать до лишнего веса». Вам следует создать только то, что вам действительно нужно, и только это.

3. Разрешитель (Resolver)

разрешитель по сути является таблицей маршрутизации контекста. Когда возникает задача типа X, приоритетно загружается документ Y. навыки говорят модели «как делать»; разрешители говорят модели «когда загружать что».

Например, разработчик изменил какую-то подсказку. Без разрешителя он мог бы просто выпустить версию после того, как внес изменения. С разрешителем модель сначала прочитает docs/EVALS.md. А в этом документе написано: сначала запустите набор оценок, сравните баллы до и после; если точность падает более чем на 2%, откатите и проверьте причины. Этот разработчик изначально даже не знал о существовании набора оценок. Это разрешитель, который в нужный момент загружает правильный контекст.

Claude Code встроил разрешитель. У каждого навыка есть поле описания, модель автоматически сопоставляет намерение пользователя с описанием навыка. Вам вовсе не нужно запоминать, существует ли этот навык /ship — описание само является разрешителем.

Честно говоря, мой предыдущий CLAUDE.md содержал целых 20 000 строк. Все странности, все шаблоны, весь опыт, который я когда-либо имел, были запихнуты внутрь. Абсурдно. Качество внимания модели явно ухудшилось. Claude Code даже прямо сказал мне избавиться от этого.

Последнее исправление, вероятно, состоит из 200 строк — просто оставьте несколько указателей на документы. Как только потребуется какой-то документ, пусть разрешитель загружает именно его в нужный момент. Таким образом, 20 000 строк знаний все еще будут доступны, но не будут загрязнять окно контекста.

4. Потенциальное и детерминированное (Latent vs Deterministic)

В вашей системе каждый шаг принадлежит либо к одной, либо к другой категории. И путать эти две категории — самая распространенная ошибка в проектировании агента.

· Потенциальное пространство (Latent space) — это место, где находится интеллект. Модель читает, понимает, оценивает и принимает решения здесь. Здесь происходит: оценка, интеграция, распознавание шаблонов.

· Детерминированный (Deterministic) — это место, где находится надежность. Один и тот же ввод всегда дает один и тот же вывод. SQL-запросы, скомпилированный код, арифметические операции — все это относится к этой стороне.

Один LLM может помочь вам организовать обеденный стол для 8 человек, одновременно учитывая характер и социальные связи каждого. Но если вы попросите его рассадить 800 человек, он серьезно сгенерирует «выглядящий разумно, на самом деле абсолютно неверный» план рассадки. Потому что это уже не задача для потенциального пространства, а детерминированная задача, жестко втиснутая в latent space — задача комбинированной оптимизации.

Худшие системы всегда ставят работу не на ту сторону этой границы. Лучшие системы четко разграничивают границу.

5. Диаризация (Diarization / Тематическое изображение)

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

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

Это не то, что может быть произведено с помощью SQL-запросов. Это также не то, что может быть произведено с помощью RAG-потока. Модель должна действительно читать, удерживать противоречивую информацию в голове, замечать, что изменилось, когда это произошло, и затем интегрировать эту информацию в структурированную интеллигенцию.

Это разница между запросами к базе данных и отчетами аналитиков.

Эта архитектура

Эти пять концепций могут быть объединены в очень простую трехуровневую архитектуру.

· Верхний уровень — это толстые навыки (fat skills): процессы, написанные на markdown, несущие суждения, методологию и область знаний. 90% ценности находится на этом уровне.
· В середине находится тонкая CLI harness: около 200 строк кода, ввод JSON, вывод текста, по умолчанию только для чтения.
· Нижний уровень — это ваша система приложений: QueryDB, ReadDoc, Search, Timeline — это детерминированная инфраструктура.

Основной принцип направлен: как можно выше переместить «интеллект» на навыки; как можно ниже опустить «исполнение» на детерминированные инструменты; поддерживать легкость harness.

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

Система, способная обучаться.

Теперь я покажу на примере реальной системы, которую мы строим в YC, как эти пять определений работают вместе.

В июле 2026 года в Chase Center прошла Startup School, в которой участвовали 6000 основателей. У каждого были структурированные материалы заявки, ответы на анкеты, стенограммы 1:1 с менторами и открытые сигналы: публикации в X, история коммитов на GitHub, записи использования Claude Code (что позволяет увидеть их скорость разработки).

Традиционный подход: 15 человек из проектной команды читают заявки по очереди, принимают интуитивные решения, а затем обновляют таблицу.

Этот метод работает на масштабе в 200 человек, но при 6000 людях он полностью выходит из строя. Никто из людей не может одновременно держать в голове такое количество образов и осознавать: три лучших кандидата в направлении инфраструктуры AI agent — это основатель инструментов разработки в Лагосе, предприниматель по соблюдению правил в Сингапуре и разработчик CLI инструментов в Бруклине — и они описали одну и ту же болевую точку совершенно по-разному в разных 1:1 диалогах.

Модель может это сделать. Метод таков:

Усиление информации (Enrichment)

Существует навык под названием /enrich-founder, который будет извлекать все источники данных, делать усиление информации, диаризацию и отмечать разницу между тем, что «сказал основатель», и тем, что «на самом деле делается».

Базовая детерминированная система отвечает за: SQL-запросы, данные GitHub, браузерные тесты URL-адресов Demo, сбор социальных сигналов, запросы CrustData и т. д. Запланированная задача выполняется раз в день. Образы 6000 основателей всегда остаются актуальными.

Результаты диаризации могут уловить информацию, которую поиск по ключевым словам не может обнаружить:

Основатель: Мария Сантос, компания: Contrail (contrail.dev) Самоописание: "Datadog для AI agent" На самом деле делается: 80% кода сосредоточено в модуле выставления счетов → по сути, это инструмент FinOps, облаченный в оболочку наблюдения.

Разница между «сказанным» и «реальными действиями» требует одновременного чтения истории коммитов на GitHub, материалов заявок и стенограмм диалогов, а также их интеграции в голове. Никакой поиск по схожести embedding этого сделать не может, и фильтрация по ключевым словам тоже не сработает. Модель должна прочитать все полностью и затем принять решение. (Это именно то, что должно быть помещено в latent space!)

Сопоставление (Matching)

Здесь проявляется сила «навыков = вызов методов».

Один и тот же навык сопоставления, вызываемый трижды, может привести к совершенно разным стратегиям:

/match-breakout: обрабатывает 1200 человек, кластеризует по областям, по 30 человек в группе (embedding + детерминированное распределение).

/match-lunch: обрабатывает 600 человек, кросс-доменное «случайное сопоставление», за столом по 8 человек, не повторяясь — LLM сначала генерирует тему, затем детерминированный алгоритм распределяет места.

/match-live: обрабатывает участников в реальном времени на основе ближайшего соседа, выполняет 1:1 сопоставление в течение 200 мс и исключает людей, которых уже видели.

При этом модель может принимать решения, которые традиционные алгоритмы кластеризации не могут выполнить:

«Сантос и Орам относятся к ИИ-инфраструктуре, но не являются конкурентами — Сантос занимается атрибуцией затрат, Орам делает оркестрацию. Они должны быть в одной группе.»
«Ким при подаче заявки указал, что это инструмент для разработчиков, но 1:1 диалог показывает, что он занимается автоматизацией соблюдения SOC2. Следует переклассифицировать в FinTech / RegTech.»

Эта повторная классификация не может быть полностью захвачена embedding. Модель должна прочитать всю картину.

Цикл обучения (learning loop)

После завершения мероприятия один из навыков /improve будет читать результаты опроса NPS, делать диаризацию для тех отзывов, которые «нормальные» — не плохие отзывы, а те, которые «чуть-чуть не дотянули» — и извлекать шаблоны.

Затем он предложит новые правила и запишет их обратно в навык сопоставления:

Когда участник говорит «инфраструктура ИИ», но более 80% его кода — это модуль выставления счетов:
→ Классифицировать как FinTech, а не как AI Infra.

Когда два человека из одной группы уже знакомы:
→ Снижать вес сопоставления.
Приоритизировать введение новых отношений.

Эти правила будут записаны обратно в файл навыка. В следующий раз, когда он будет запущен, они автоматически вступят в силу. Навыки «самопереписываются». В мероприятии в июле доля «нормальных» оценок составила 12%; на следующем мероприятии она упала до 4%.

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

Эта модель может быть перенесена в любую область:

Поиск → Чтение → Диаризация → Подсчет → Интеграция.

Затем: исследование → расследование → диаризация → переписывание навыка.

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

Навыки постоянно улучшаются.

Недавно я отправил команду OpenClaw в X, и она вызвала больший отклик, чем ожидалось:

Подсказка: вы не имеете права выполнять одноразовую работу. Если я попрошу вас сделать что-то, что будет повторяться в будущем, вы должны: сначала вручную обработать от 3 до 10 образцов и показать мне результаты; если я одобряю, запишите это как файл навыка; если это должно выполняться автоматически, добавьте в задачи по расписанию. Критерий: если мне нужно задавать вопрос второй раз, это значит, что вы потерпели неудачу.

Этот пост получил тысячи лайков и более двух тысяч закладок. Многие считали, что это приемы проектирования подсказок.

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

Это и есть источник 100-кратной эффективности, о которой говорил Йегге.

Не более умные модели, а толстые навыки, тонкие рамки (Thin Harness, Fat Skills) и дисциплина, превращающая все в способности.

Система будет расти с сложным эффектом. Постройте один раз, работайте долго.

[Ссылка на оригинал]