Примечание редактора: Когда AI-агенты переходят от разовых промптов и "vibe coding" к более сложным рабочим процессам, самым важным вопросом становится уже не "может ли модель выполнить задачу", а "можно ли превратить возможности ИИ в повторно используемый, накапливаемый актив в виде процесса".
Эта статья, отталкиваясь от GBrain Гарри Тана, суммирует пять ключевых форм, к которым постепенно приходят многие, используя такие инструменты агентов, как Codex, Claude Code, Hermes и другие: параметризуемые Skills (Навыки), легкий исполняющий фреймворк Thin Harness, отвечающие за маршрутизацию Resolvers, отделяющий суждения модели от детерминированного кода слой исполнения, и Memory (Память) для долгосрочного накопления контекста.
Вместе эти модули указывают на новую "процессную способность": опыт записывается в виде процесса, задачи абстрагируются в параметры, стабильные правила передаются коду, суждения и синтез — модели, а через слой памяти происходит постоянное накопление. По сравнению с разово сгенерированными приложениями или промптами, такую систему сложнее скопировать, и она с большей вероятностью может стать основой для формирования долгосрочных конкурентных преимуществ для личности, маленькой команды или даже компании в эпоху ИИ.
Далее следует оригинальный текст:
Я потратил некоторое время на изучение GBrain от Гарри Тана. Будучи человеком без технического бэкграунда и не работающим в венчурной сфере, я хочу выделить несколько общих структурных форм, которые я в этом вижу, и то, что в этом действительно интересно.
Я считаю, что многие постепенно сходятся к одному и тому же набору ключевых структур. Их можно обобщить примерно в 5 форм, которые также отражают естественное направление эволюции в использовании агентных ИИ-инструментов, таких как Codex, Claude Code, Hermes, OpenClaw.
Рекомендуемая статья: «Thin Harness, Fat Skill: настоящий источник 100-кратной продуктивности ИИ»
Skills: от SOP до «вызова метода»
Skills — это почти самое естественное для всех начало. Даже без подсказок пользователи интуитивно начинают их создавать, потому что форма знакома. Я сначала понимал это как SOP — стандартную операционную процедуру для выполнения чего-либо. Пользователь говорит "что сделать", а Skill определяет "как сделать".
Понимание Тана: Skill больше похож на "вызов метода". В программировании вызов метода — это использование параметров для запуска определенного программного процесса. Один и тот же код выполняется каждый раз, а меняются параметры: какие данные, какая проблема, какая цель. Например, одна и та же функция process_invoice может обрабатывать каждую накладную в системе, а не только ту, для которой она изначально была написана.
Skill имеет похожую структуру. Skill под названием /investigate может включать семь фиксированных шагов, которые не меняются. Меняются параметры: TARGET (на кого или что направлено расследование), QUESTION (что вы хотите выяснить), DATASET (где искать информацию). Направьте его на случай с информатором в медицинской отрасли — он работает как аналитик-исследователь. Направьте на документы SEC — он работает как юридический следователь. Один и тот же файл, те же семь шагов, разница задается из внешнего мира.
Это отличается от традиционной SOP. Большинство SOP пишутся для конкретной должности или задачи, например, "обработка кредиторской задолженности". Каждый сценарий использования соответствует своему процессу. Абстракция Skill выше: один процесс может решать целый класс проблем. Хорошо спроектированный Skill может выполнять работу десятков SOP, потому что информация о конкретных случаях выносится из документа в параметры. На практике некоторые Skills ближе к SOP, другие — к вызову метода.
Thin Harness: модель — это интеллект, Harness — это руки и ноги
Модели, такие как Opus, GPT-5.5 и другие, — это сырой интеллект; Harness, такие как Claude Code, Codex CLI, Hermes, OpenClaw, — это исполняющий фреймворк, который дает моделям настоящие "руки и ноги". Они отвечают за циклическое выполнение, чтение/запись файлов, управление контекстом, выполнение ограничений безопасности. Их основной код составляет около 200 строк.
Гарри упоминает, что распространенная ошибка — постоянно добавлять что-то в Harness, и я сам так делал. В итоге у меня накопилось 100 определений инструментов и куча MCP-серверов. В результате контекстное окно заполнялось множеством описаний инструментов, не нужных для текущей задачи. Модель начинала путаться, какой инструмент использовать, задержки росли, точность падала, и в итоге возникала так называемая "порча контекста".
Resolvers: использование таблицы маршрутизации для решения проблемы порчи контекста
Решение проблемы порчи контекста — создание таблицы маршрутизации. Задача Resolver — четко сопоставить "только что поступившую задачу типа X" с "должен быть вызван Skill Y". Когда у вас 5 Skills, Resolver не нужен; но когда их 100, описания становятся размытыми, и модели легко запутаться, когда вызывать какой Skill. Resolver заменяет нечеткое сопоставление по шаблону на явные правила.
Тан также применил для файлов механизм, похожий на Resolver: отдельная таблица маршрутизации, определяющая, куда в файловой системе должен попадать вывод конкретного Skill. Это та же структура "аудит-маршрутизация", примененная к другой проблеме. Так вывод стабильно попадает в нужную папку, а не в место, предположенное моделью наобум.
Skillify — его дополнительная идея: это цикл контроля качества для превращения разового Skill в долгосрочно используемую инфраструктуру. Процесс из 10 шагов, описанный Таном, включает: определение контракта, использование детерминированного кода там, где это уместно, модульное тестирование, интеграционное тестирование, оценку с помощью LLM-as-judge, запись в Resolver, скрипт аудита, проверку, какие Skills не имеют путей вызова, и сквозное smoke-тестирование. Критерий прост: если вам приходится дважды задавать модели один и тот же вопрос — это провал.
Latent vs. Deterministic: суждение — модели, детерминированные задачи — коду
Важно четко различать, какую работу следует поручать LLM, а какую — детерминированной системе. LLM хороши в суждениях, синтезе, распознавании паттернов и понимании скрытого смысла; но они плохи в арифметике, комбинаторной оптимизации и не подходят для задач, требующих каждый раз одного и того же ответа. LLM по своей сути вероятностны, и когда есть детерминированное решение, не стоит использовать LLM.
Большинство людей без технического бэкграунда часто недооценивают ценность детерминированного слоя. Реакция по умолчанию — сбросить все на модель. Но если что-то можно сделать детерминированно, то почти всегда так и следует поступать. И вам не обязательно быть программистом, потому что модель может написать код за вас. Настоящая задача — выработать дисциплину: каждый раз спрашивать себя, можно ли это стабильно и с низкими затратами выполнить кодом? Если да — пусть модель напишет этот код.
Memory: сделать систему действительно накапливаемой
Чтобы система была полезной, она должна обладать какой-либо формой памяти. Я еще не уверен, какая форма самая правильная, сейчас многие строят по-разному: векторные эмбеддинги, семантическое сходство, графы знаний, гибридное хранение и т.д. Тан поступил, как и я: просто папка с markdown-файлами.
Его структура: по одной странице на человека, на компанию, на концепцию. Вверху каждой страницы — "текущий достоверный вывод", то есть обобщенное суждение, которое постоянно переписывается и обновляется по мере поступления новых доказательств; внизу — только добавляемая, но не перезаписываемая хронология.
Выбор markdown дает несколько следствий. Во-первых, файлы сами по себе являются основной записью системы, а не каким-то экспортируемым результатом. Вы можете открыть их в VS Code, отредактировать вручную, и агент автоматически прочитает эти изменения. Во-вторых, типизированные отношения, такие как works_at, invested_in, founded, attended, advises, автоматически извлекаются при каждой записи с помощью регулярных выражений, поэтому граф знаний может связываться сам, без потребления токенов. Эта конкретная схема хорошо подходит для его работы, но другим, возможно, придется адаптировать ее под свою профессию и бизнес-сценарий.
Кроме того, на фоне работает детектор сигналов. Одно упоминание человека — и создается заглушка страницы; три упоминания в разных источниках — запускается дополнение информации из сети; после окончания встречи — запускается полный процесс. Ночной "цикл сновидений" сканирует диалоги, дополняет информацию об устаревших сущностях и исправляет неработающие ссылки. Базовый слой — текст, все над ним — дешево и композитно.
Конечно, на более глубоком уровне есть еще детали, но я считаю, что это самые важные контуры, и они в значительной степени универсальны.
Я сам фактически построил около половины такой архитектуры. До сих пор масштаб не требовал введения настоящего Resolver, но сейчас этот этап наступил, поэтому я только что провел небольшой рефакторинг, сделав свою систему независимой от модели и встроив Resolver. Ключевая часть, которую я пока не построил, — это фоново работающие детектор сигналов и ночной цикл сновидений, то есть автоматический механизм дополнения и организации информации, это то, что я хочу попробовать добавить следующим шагом.
Я подозреваю, что то, что разные создатели сходятся к похожей структуре, само по себе является сигналом: эта форма, хоть и не обязательно подходит всем, но, вероятно, в целом полезна. Даже если конкретные детали реализации будут различаться, сама структура в целом независимо обнаруживается все большим числом людей.
Вопрос, который я недавно постоянно задаю себе: как с помощью ИИ создать устойчивое конкурентное преимущество?
Все в восторге от vibe-coded приложений и разовых промптов, и это, конечно, очень круто. Я сам начинал именно так и из-за этого погрузился в тему. Но равновесная цена всего, что можно построить с помощью разового промпта, в конечном итоге упадет до стоимости токенов, необходимых для его построения, то есть до нескольких центов.
Например, кто-то скопировал MyFitnessPal, продает за половину цены и заработал 1 миллион долларов — это, конечно, впечатляет. Но скоро появится кто-то еще, кто скопирует это и продаст еще дешевле. Этот цикл продолжится, пока маржа не будет полностью выжата.
По-настоящему устойчивым является нечто иное — "процессная способность". В рамках модели Hamilton Helmer «7 Powers», описанная выше архитектура предполагает именно process power.
«7 Powers» утверждает, что компании могут длительно поддерживать прибыльность выше средней по рынку, потому что обладают одной из семи структурных сил. Любое преимущество, не укорененное в этих силах, в конечном итоге будет размыто конкуренцией.
Для малых и средних предприятий и ранних стартапов пять из семи сил Хельмера по сути закрыты. Эффект масштаба требует масштаба; сетевые эффекты и затраты на переход можно создать, но сначала нужно накопить огромную пользовательскую базу; исключительные ресурсы обычно означают патенты или подобные активы, которые есть не у всех компаний; бренд обычно требует десятилетий на построение, без ярлыков.
Остаются две: контрпозиционирование и процессная способность.
Контрпозиционирование — это бизнес-модель, которую не могут скопировать существующие гиганты, потому что копирование навредит их собственному существующему бизнесу. Такая возможность иногда есть, но не всегда доступна.
Таким образом, наиболее реалистичный путь — это процессная способность. А хорошо спроектированная ИИ-система как раз и является инструментом, который может генерировать процессную способность.
По сути, это та же работа, что и создание качественных SOP или собственного проприетарного ПО: процессы кодируются, случаи параметризуются, базовая детерминированная система работает быстро и надежно, а слой памяти постоянно поглощает прошлые знания. Это усиливает "продуктизированную услугу": вы можете предоставлять услугу или продукт с более низкими затратами или более высоким качеством, потому что вся работа уже структурирована.
Представьте бухгалтера, который построил такую систему. Слой памяти — это папка, где у каждого клиента есть markdown-файл с текущими достоверными выводами: структура юридического лица, ежегодная налоговая позиция, текущие аудиты, а также хронология встреч, решений и изменений.
У нее есть Skills, например, /year-end-review, /quarterly-estimate, /audit-prep. Один и тот же процесс выполняется с параметрами для разных клиентов.
У нее есть детерминированный слой: налоговые формы, таблицы амортизации, документы IRS, исторические налоговые декларации клиентов и т.д.
Плюс механизм, похожий на ведение журналов или цикл сновидений. Например, система ночью автоматически обнаруживает, что распределение K-1 одного из партнеров упало на 40% без изменений в стратегии; или замечает, что структура вычетов домашнего офиса одного клиента может быть перенесена на другого клиента — структура переиспользуется, но идентичность и приватность остаются на месте.
Таким образом, она может брать небольшую надбавку, обслуживать больше клиентов в год, а конкурентам сложно скопировать, потому что эта структура не появляется из ниоткуда после ее успеха, а накапливается с самого начала.
На поверхности этот инструмент — просто папка с markdown-файлами. Но каждая строка в каждом файле — результат большого количества осознанных тестов, построений и итераций. Конкурентный барьер формирует не сами файлы, а процессная способность, которую эти файлы воплощают.
