Вашему ИИ-агенту не нужно больше контекста. Ему нужный мозг, которому он может доверять.

Представьте, что в 02:14 включается пейджер. Вы открываете руководство — оно кажется прекрасным: там есть пронумерованные шаги, диаграмма, явные признаки того, что к нему приложили усилия. Вы выполняете четвертый шаг, но всё проваливается. Внизу страницы вы видите дату последней правки: четырнадцать месяцев назад.

Каждое предложение в нём было правильным в день написания. Но не было никаких указаний на то, что оно устарело.

В этом-то и заключается настоящая ошибка. Проблема не в отсутствии документации или в плохой документации. Проблема в том, что документация кажется столь же надёжной в свой худший момент, как и в первый. В течение сорока лет программное обеспечение выпускалось при условии, что документация — это проза, и читатель сам оценивает её качество. Затем хранилища документации перешли в руки агентов, которые не способны ничего оценить и читают каждое слово с полной уверенностью.

Что изменилось

У ИИ-агента нет собственной памяти. Он не имеет состояния, и при каждом ходе вся конверсация отправляется заново с самого начала. В документации Anthropic прямо говорится: необходимо отправлять полную историю общения каждый раз.

Следовательно, документ с описанием архитектуры на 4 000 токенов, который всегда загружается в файл агента, читается не один раз. В сессии из сорока ходов он читается сорок раз. А его загрузка может ухудшить работу агента.

В исследовании Chroma по проблеме изменения контекста было протестировано 18 передовых моделей, в том числе GPT, Claude, Gemini и Qwen, и было установлено, что точность снижается по мере увеличения объема входных данных — в некоторых случаях с 95% до 60%. Важно понимать, что это не эффект, близкий к пределу возможностей; ухудшение происходило на каждом уровне длины данных, который они измеряли. Если эти результаты верны, даже окно объемом в миллион токенов начинает работать плохо уже на уровне пятидесяти тысяч токенов, поскольку причиной проблем является шум, а не ограниченная емкость.

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

• Загружать всё. Агент знает систему, но его производительность на каждой задаче существенно снижается, а каждая правка документа аннулирует весь кэш запросов и заставляет пересчитывать стоимость обработки.
• Не загружать ничего. Агент сохраняет высокую производительность, но ничего не знает, поэтому вынужден импровизировать: он придумывает новые шаги выполнения или запускает команды, которые были устарены ещё в марте.

Команды выбирают один из вариантов, сталкиваются с проблемами, а затем переходят на другой. Примерно в таком положении сейчас находится индустрия.

Уже существует диагноз в одном предложении

В апреле 2026 года Андрей Карпати опубликовал краткое изложение, которое назвал файлом с идеей. Это не было ни продуктом, ни библиотекой. В нем описывался один подход: модель преобразует сырой материал в упорядоченную, структурированную Markdown-вики, и с тех пор вопросы направляются в эту вики вместо в оригиналы.

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

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

Суть идеи быстро распространилась. Через два месяца Google Cloud опубликовала спецификацию, которая, согласно собственному заявлению, формализует подход с использованием ИИ для вики в виде переносимого, совместимого формата. Основная диагнозическая концепция остаётся той же, что и у Карпати, и именно поэтому всё это сейчас работает, а в 2019 году — нет.

OKF за полминуты

OKF, формат открытых знаний, был опубликован командой Data Cloud Google Cloud в июне 2026 года в виде черновика (v0.2) и представляет собой формализованную версию данного формата. Технически это каталог файлов формата Markdown с преамбулой в формате YAML, и это всё.

В спецификации описывается его принцип следующим образом: любой, кто может использовать команду cat для просмотра файла, может читать OKF, а любой, кто может выполнить команду git clone для копирования репозитория, может его распространять.

Обязательным является только одно поле — type. Файл, содержащий только значение type, уже считается соответствующим стандарту. В процессе не задействуются реестры схем, базы данных, пайплайны встраивания, ограничения от поставщика или SDK.

okf/
  index.md                  ← table of contents
  billing/
    index.md
    invoice-retries.md      ← one file, one answerable question
  flows/
    customer-offboarding.md

Если ваша реакция — «Значит, папка с Markdown», — это верно. Формат не является самым важным аспектом, и вполне обоснованным возражением может быть то, что папке не нужны спецификации. В объявлении Google есть ответ на это: вики Карпати, вики команды и экспорт каталога поставщика могут выглядеть одинаково — с Markdown, frontmatter и внутренними ссылками — но ни один из них не был создан с целью взаимодействия. Именно поэтому и нужны спецификации. Все независимо пришли к одному формату, что обычно означает, что этот формат правильный, а затем каждая реализация придумала собственные имена полей. Формат превращает несколько частных конвенций в единый формат, который агент может читать где угодно.

Основная идея: документация становится состоянием

Вот пример документа:

---
type: Playbook
title: Invoice retry policy
status: stable                      # draft | stable | deprecated
stale_after: 2026-11-01             # stale when today >= this date
generated: { by: "human:dana", at: 2026-08-10 }
verified:  [{ by: "human:sam",  at: 2026-08-11 }]
sources:
  - resource: services/billing/retry.go
    last_modified: 2026-07-15
not:
  - term: "restart the worker to clear the queue"
    why: "in-flight jobs are lost, they are not re-queued"
    instead: "drain first, then restart"
---

Пять из показанных полей взяты из спецификации. Шестое является наиболее важным и снова упоминается ниже.

Шкаф для документов просто хранит документы. Мозг также знает, что у него есть, насколько он уверен и какие ошибки чему-то его научили. Приведённые ниже элементы соответствуют этому:

Теперь прочитайте этот фронтматтер так, как это сделала бы машина. stale_after — это дата истечения срока действия. Это не отметка «последнее обновление», которую нужно интерпретировать. Это абсолютная дата, благодаря которой проверка старения превращается в простое сравнение today >= stale_after. Эту проверку может выполнять что угодно: агент, читающий файл, запланированная задача или система CI.

Задумайтесь над этим. Проблема устаревания документации существует с момента появления вики-сайтов. Постоянные напоминания, дни проверки документации, квартальные аудиты, плюс страница «Стандарты документации», которая сама уже устарела. Всё это основано на социальном давлении, и ничего из этого невозможно принудительно внедрить. С помощью stale_after устаревание становится причиной неудачного теста, что относится к той же категории, что и сбой при сборке. Тест проходит или не проходит, и никому не нужно чувствовать себя виноватым.

Другие поля работают аналогичным образом. Поле sources перечисляет пути кода, которые описывает документ, что позволяет скрипту наконец ответить на вопрос, на который вики никогда не могли ответить: изменился ли файл, который, по утверждению трех документов, должен его описывать, и обновили ли их кто-нибудь? Поле verified фиксирует тех, кто подтвердил документ, отдельно от тех, кто его написал, поскольку, как говорится в спецификации, автор концепции не обязательно должен быть тем, кто её подтвердил. Работа агента над черновиком и утверждение старшим инженером — это два отдельных события, различие, которое большинство инструментов для документации никогда не фиксирует. Уровни доверия определяются на основе префикса исполнителя и не хранятся, поскольку сохраняемая оценка субъективна, несовместима между разными пользователями и со временем устаревает.

status: deprecated позволяет сохранить старое определение вместо его удаления. Когда два панели управления расходятся во мнениях относительно показателя «доход», причиной часто бывает не плохие данные, а два разных определения, одно из которых заменяется незаметно без какой-либо маркировки. Сохраните оба, отметьте одно — и цифры прошлого квартала будут доступны.

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

Арифметика токенов

Эти показатели были рассчитаны на основе опубликованного примера от Google, поэтому их можно проверить:

Обработка одного факта от начала до конца стоит примерно 950 токенов и взимается только с запросов, в которых это необходимо. Часть, работающая постоянно, относится к уровню 0: 60 токенов, одно предложение.

Сравните это с типичным подходом: в каждый запрос вставляется руководство объемом 1 600 токенов, хотя, возможно, только один из десяти запросов в него нуждается. Знания остаются теми же, средняя стоимость снижается примерно в десять раз, а объем документа может расти без ограничений, поскольку дополнительная длина больше не влияет на не связанные между собой разговоры в репозитории. Спецификация была создана на основе этой цели и получила название «постепенное раскрытие информации»: сначала смотрят то, что уже существует, а документы открывают позже.

Чем не является OKF

OKF не выполняет функцию защитного барьера. Файл в формате Markdown не может помешать агенту выполнить какую-либо разрушительную операцию. Фактическая защита должна обеспечиваться кодом — например, списками запретов и хуками перед выполнением, которые блокируют действие независимо от выбора модели. Что бы вы ни помнили ещё, не делайте вывода, что простое записывание информации о рисках гарантирует вашу защиту.

На самом деле OKF предоставляет агента, который знает о правилах. В спецификации также определён тип «Attested Computation», при котором агент может передавать параметры, но никогда не имеет права писать или изменять сам процесс вычислений, что является наиболее близким к запрету на переписывание проверок безопасности решением. Следите за этим подходом, но пока не используйте его в практике: в спецификации указано, что реализация данного интерфейса отложена до будущих обновлений.

Помните также, что это черновик. При переходе с v0.1 на v0.2 уже были переименованы два конструкта, поэтому используйте только восемь полей, которые вам нужны. Любые последующие переименования можно выполнить с помощью функции поиска и замены.

Начните с малого, добавляйте механизмы контроля там, где это необходимо

Это не проект — это один файл.

1. Напишите один документ о том, что недавно стоило кому-то полдня работы, включив поля type, title, description и stale_after.
2. Создайте файл index.md, в котором будет перечислен этот документ с колонкой «Когда читать», и добавьте строку okf_version: "0.2". Корневой индекс — единственное место, куда должно относиться это поле, и согласно спецификации это единственный фронтматтер, который может содержаться в индексе.

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

Этого достаточно, чтобы начать работу. Поскольку условие today >= stale_after представляет собой просто сравнение, агент может оценить его сразу после открытия файла. Как поступить с устаревшим документом — решать вам, что и было намеренно оставлено без определения в спецификации.

Добавляйте автоматизацию тогда, когда уже два человека могут сделать ваш документ недействительным без его прочтения. Именно это является реальным критерием, и он связан скорее с размером команды, чем с точностью. При работе с пятью документами вы сами это заметите, и достаточно будет проверки истечения срока с стороны агента. В команде же тот, кто нарушает действие документа, по определению — это тот, кто никогда его не открывал, поэтому добрые намерения к нему не дойдут, и что-то в процессе создания pull-request должно с этим справиться. Бюджетная версия — это запланированная задача, которая сообщает о истекших сроках документов. Более надежная версия — это контрольный пункт в pull-request, который блокирует его при наличии истекшего срока и выдает предупреждение, если был изменен код, описанный в документе. Начните с бюджетного варианта.

Краткая версия

Агенту не нужно больше окна контекста. Ему нужно знать, где искать информацию, а любой открываемый им файл должен честно указывать свою дату создания. Сначала — шестьдесят токенов, остальное — по запросу, причём документ может нарушить процесс обработки, как только его данные перестанут быть актуальными, чего раньше не удавалось добиться.

Дополнительная литература: спецификация OKF v0.2 и примеры пакетов, пост Google Cloud об этом формате, статьи Anthropic об инженерии контекста, навыках агентов и кэшировании промптов, а также исследование Chroma о изменении контекста.

Связанная литература

• Практические заметки: вашему агенту для программирования не нужен дополнительный контекст. Ему нужна карта. — Пошаговое руководство по применению Практических заметок: вашему агенту для программирования не нужен дополнительный контекст. Ему нужна карта: контракты, проверки и блоки для вставки кода для команд, использующих эту схему.
• Практические заметки: вашему агенту для программирования не нужен лучший запрос — Пошаговое руководство по применению Практических заметок: вашему агенту для программирования не нужен лучший запрос: контракты, проверки и блоки для вставки кода для команд, использующих эту схему.

Практические заметки: Israeli Tech Radar 2026-27: Инженерия в эпоху агентов — Подробное руководство по использованию Практических заметок: Israeli Tech Radar 2026-27: Инженерия в эпоху агентов: контракты, проверки и готовые блоки кода для команд, разрабатывающих на этой основе.