Выживание при сжатии: лестница для длительных сессий агентов и процесса сжатия.

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

Окно контекста ведёт себя аналогичным образом. Его объём фиксирован, а маршрут — нет, поэтому рано или поздно что-то придётся оставить.

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

Складывание уменьшает размер окна; это механический процесс. Цена такого действия менее очевидна, поскольку складывание приводит к аннулированию кэша. Оплата происходит один раз, всё, что остается, перезаписывается, и сессия продолжается. Тем не менее аннулирование кэша — это второстепенный момент. Главное — выбор того, что должно сохраниться. Хорошая компактизация — это не просто удаление: она сводит историю к такой форме, при которой агент может продолжать работу. К тому же длительная сессия складывается не один раз: она складывается, работает, снова складывается, и рано или поздно происходит ещё одно складывание.

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

Где накапливаются счета

Каждый запрос делится на две зоны для начисления платы. Одна — это префикс, который сохраняется с каждого этапа. Другая — хвост, который постоянно увеличивается.

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

Далее идет весь «хвост»: диалоги, вызовы инструментов, их результаты, блоки мышления и различия между версиями. Он постоянно увеличивается.

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

В окне объемом 200 000 токенов большая часть пространства уже занята. В зависимости от используемой системы и ряда других факторов количество действительно свободных токенов для работы может сократиться до примерно 7,5 тыс. — 15 тыс. токенов.

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

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

Лестница из пяти шагов

Существует пять способов борьбы с ростом «хвоста». Это меньше, чем просто ступени: чем выше подъем, тем сильнее нарушается существующая история данных.

Первый шаг: никогда не генерировать его. Ограничьте объем вывода с помощью инструмента. Инструмент текстового редактора Anthropic поддерживает параметр max_characters, а его веб-поиск — параметр max_uses. Codex по умолчанию ограничивает объем вывода отдельных инструментов примерно от 10 000 до 16 000 токенов до того, как начнется расчет сжатия. Более дисциплинированным вариантом является вырезание: сохраняются начало и конец, а средняя часть удаляется, поскольку считается, что то, как началась команда и где она закончилась, важнее, чем содержимое между ними. Недостаток заключается в том, что текст обрезается до того, как станет ясно, что действительно важно, а отсутствие соответствующей информации в трейсе вызовов хуже, чем его полное отсутствие.

Второй этап: сохранить данные. Если вся информация не требуется, её не следует хранить. Когда результат работы инструмента превышает установленный порог размера, система записывает его на диск и оставляет ссылку на него. Полный файл сохраняется, в то время как динамический контекст — нет. Это отличается от обрезки, поскольку ничего не удаляется. Журнал сборки длиной 500 тысяч строк может оставаться на диске, в то время как контекст содержит лишь его путь, метаданные или поисковый индекс; позже специальный инструмент для поиска или чтения извлекает только необходимую часть информации. Сохраняйте файл, удаляйте лишнюю информацию. Таким образом хранение и контекст чётко разделяются, что обеспечивает долговечность данных без дополнительных затрат в последующих операциях.

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

Заметна схожесть между различными харнесами. Claude Code сохраняет на диск любой результат работы инструмента длиной более примерно 100 кб, возвращая при этом предварительный просмотр и путь к файлу, а Hermes также устанавливает ограничение в 100 кб на каждый результат. Оба решения предусматривают исключение для инструмента чтения: если чтение приводит к сохранению пути, агент будет читать этот файл снова и снова, постоянно сохраняя его и снова читая. В такие петли легко попасть. Единственный инструмент, предназначенный для восстановления контента, — это тот, который ни в коем случае не должен сохранять данные.

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

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

Четвертый этап: замените его на указатель. Если содержимое уже сохранено надежно — будь то файл, объект, сгенерированный отчет или результат вычислений — для диалога достаточно лишь ссылки на него. Повторное просмотрение означает возвращение туда, где хранится материал, а не его перенос с собой. Инструмент памяти Anthropic делает именно это, а OpenAI поддерживает аналогичное поведение с помощью вызовов функций. Дорогостоящее состояние диалога превращается в недорогую ссылку на надежно сохраненное состояние. Существует одно ограничение: экономия сохраняется только до тех пор, пока исходное содержимое находится вне рамок диалога. Как только оно снова прочитывается, оно снова становится частью диалога и немедленно начинает «платить аренду».

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

На этом этапе экономика превращается в ставку: превышает ли сэкономленная за оставшуюся часть сессии сумма ту стоимость, которая сейчас требуется для перезаписи истории? Раннее сжатие приводит к потере полезного кэша, который мог бы обеспечить сотни дешёвых ходов. Позднее сжатие означает, что уже была уплачена «арендная плата» за огромный объём истории, в течение которой модель, возможно, уже ухудшила свою способность ею пользоваться. Большинство обсуждений длительных сессий начинаются с этого вопроса, но этого делать не следует. Пять ступеней в порядке:

1. Никогда не генерировать её: останавливать формирование дополнительных данных на исходном уровне.
2. Вынести наружу: извлечь объемные данные наблюдений и сохранить артефакт.
3. Оставить снаружи: перенести процедуру исследования в другой контекст.
4. Указать на него: оставить простой ориентир в ходе обсуждения.
5. Удалить позже: сжать или свернуть данные и смириться с потерей.

Самый дешевый контекст — это не сжатый контекст. Это контекст, который вообще не должен был существовать.

Наборы инструментов как ставка на место оплаты

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

Terminus 2 — это крайняя форма минимализма: один терминал без дополнительных компонентов, основанный на принципе Unix о том, что один универсальный инструмент может быть создан путем неограниченного сочетания элементов. Codex часто относят к нему, но это лишь частично справедливо. Его встроенный набор инструментов далеко не мал: примерно 20 постоянно доступных инструментов, набор инструментов для работы с несколькими агентами, а также версии v1 и v2. Он избегает избыточности за счёт отложенной загрузки — инструменты MCP и коннекторы индексируются в поисковой системе и загружаются по мере необходимости. Codex действительно делает ставку на минимизацию компонентов в «хвосте» системы. Примером этого служит функция apply_patch: короткая разница между версиями файлов заменяет тысячи символов переписанного текста, а ограничения на объём вывода каждого инструмента предотвращают накопление больших объёмов данных. Оба подхода приводят к схожим результатам, но разными способами: Terminus 2 сохраняет небольшой размер набора базовых инструментов, а Codex — небольшой размер компонентов в «хвосте» системы.

Claude Code и Hermes выделяют больше ресурсов на специализированные инструменты, которые возвращают структурированные данные вместо необработанных. Количество инструментов в каталоге Claude Code превышает 40, если учесть LSP, режим планирования, worktrees и cron, а у Hermes — около 55; они сгруппированы по наборам инструментов для терминала, файлов, памяти, навыков, делегирования и других задач. Типичным примером является Grep, возвращающий совпадения вместо всего файла: это позволяет использовать немного больше ресурсов для избежания тысяч токенов неиспользуемого текста.

Следовательно, сравнение должно касаться не количества инструментов, а того, удаляет ли дополнительная вычислительная нагрузка достаточно «хвостовых» данных для отсрочки процесса сворачивания. Это та же самая дилемма между предварительной обработкой и обработкой по мере необходимости, но на более высоком уровне. Anthropic четко описывает концепцию отложенной загрузки: определения инструментов могут быть загружены по мере необходимости, а не с каждым запросом. Claude Code реализует это с помощью механизма ToolSearch, который позволяет видеть названия отложенных инструментов, скрывая при этом полные схемы до момента запроса модели; этот механизм активируется автоматически, когда определения инструментов MCP составляют около 10% окна контекста. Даже порядок отображения выбран с целью защиты префикса, поскольку алфавитный порядок сохраняет байтовую идентичность блока определений между запросами, тем самым обеспечивая возможность кэширования. Префикс разрабатывается таким образом, чтобы он оставался активным независимо от своего размера.

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

Делегирование как граница памяти

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

Необходимо скорректировать распространённое предположение. Привлекательно представлять себе ситуацию разветвления одной и той же модели, при которой дочерний процесс наследует накопленный родительским процессом «хвост» вместе с его «тёплым префиксом». Однако большинство проверенных реализаций не делают этого. Claude Code, OpenCode, Codex и Hermes запускают отдельные рабочие контексты, а не копию всего «хвоста» родительского процесса. Некоторые из них могут использовать другую модель: Codex задаёт модель при запуске, а Claude Code позволяет каждому подагенту выбирать между форматами sonnet, opus или haiku. Это не является универсальным правилом, и у Hermes нет прямого способа смены модели. То, что передаётся между компонентами, — это отдельный контекст, а не выбор модели.

Это указывает на нечто более масштабное, чем простое разделение задач. «Хвост» дочернего агента можно отбросить: он может прочитать сорок файлов, проанализировать логи и определить правила нумерации, после чего весь контекст исчезает, а возвращается лишь отдельный абзац. Делегирование выполняет роль границы памяти: родитель задаёт задачу и указывает, что от неё требуется, что фактически соответствует предварительной компрессии информации, поскольку исполнитель знает, кто будет читать его результат и какое решение он должен поддержать. Когда подагент возвращается, родитель обычно проверяет результат. Это требует нескольких шагов, но является разумным подходом.

Процесс сжатия происходит в обратном порядке, уже после завершения работы. Необходимо кратко изложить суть для читателя, который ещё не существует, чтобы избежать возможных вопросов позже. Предварительное сжатие имеет преимущество в том, что известен читатель. Это приводит к принципу составления бюджета: необходимо выделять средства на результат, а не на сам процесс. Рабочий может потратить сотни тысяч токенов, при этом ни один из них не станет частью родительской памяти. Возвращаемый текст же становится частью памяти. Четыреста токенов ответа попадают в «хвост» родительской структуры и начисляются за каждый последующий шаг; таким образом, за длительную сессию сырой результат может стоить дороже, чем дорогой рабочий, возвращающий одно полезное предложение. Исследование является временным, а ответ — часть истории, причём этот ответ в свою очередь должен выдержать процедуру сжатия.

Что предлагают платформы

Платформа модели определяет, сколько из этого оборудования должна сама создать.

Anthropic предлагает два вида помощи, направленные на решение разных проблем. Первый вариант, clear_tool_uses_20250919, является точным в действии. Когда вводный текст превышает установленный порог (по умолчанию 100 тыс. токенов, при этом сохраняются три последних использования инструмента), он удаляет старые результаты работы инструментов на сервере и заменяет их место заменителем. Опция clear_at_least позволяет распределить затраты на удаление, устанавливая минимальное количество данных, которые необходимо удалить. Второй вариант, compact_20260112, представляет собой более мощный инструмент: он осуществляет полное обобщение на стороне сервера, в результате чего формируется новая версия диалога, а не просто его фрагмент внутри существующей версии.

Claude Code является хорошим примером для исследования, поскольку даже библиотека, созданная компанией, поставляющей эти примитивы, по-видимому, самостоятельно координирует использование более тяжелой версии /compact на своей стороне. Поддержка этого механизма осуществляется благодаря работам сообщества по обратной разработке, ведущимся на основе одного обнародованного источника на GitHub, а не благодаря публичной документации Anthropic. Очистка данных происходит на сервере, тогда как решение о том, какое состояние диалога сохранить, принимается на стороне клиента.

OpenAI сосредотачивается на сжатии данных. Его конечная точка /v1/responses/compact возвращает зашифрованный непрозрачный блоб, который клиент передает обратно, не заглядывая внутрь, отчасти для блокировки возможности внедрения команд через изменённое резюме, способного повлиять на последующие действия. Здесь нет механизма точечной очистки данных, поэтому Codex должен сам управлять размером вывода инструмента; кроме того, у обоих путей есть примитивный вариант резерва: если окно всё равно переполняется, Codex удаляет старейший элемент истории и пробует снова.

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

Важен не качество конкретного конца точки сжатия API, а тот, кто отвечает за принятие решения о том, что останется. Hermes является показательным примером предельного случая, поскольку он включает несколько поставщиков услуг и не может предполагать, что кто-то из них предоставляет подходящие инструменты. Поэтому в качестве базового варианта он использует собственный компрессор с клиентской стороны, основанный на двух пороговых значениях: 50% согласно собственному учету токенов и 85% по результатам более грубой проверки на уровне шлюза, которая выявляет сессии, растущие между запросами при отсутствии наблюдения. Каждый раз, когда действующий поставщик предлагает более эффективный способ, процесс откладывается.

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

Возвращение в лагерь

Все вышесказанное исходило из предположения, что сессия никогда не прерывается. Но сессии прерываются: ноутбуки закрываются, процессы останавливаются, задания CI завершаются, и кто-то вводит команду /resume, ожидая возобновления работы с того места, где она была прервана.

Это самая простая команда, но при этом стоит самого дорогого возобновления сессии. Она состоит из семи символов, включая слеш, похожа на /help или /clear, не требует аргументов, подтверждения и не сопровождается никакими сложностями. В ней нет ничего, что указывало бы на её стоимость, а интерфейс настроен так, чтобы возобновление работы казалось бесплатным.

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

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

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

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

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

Два способа сбоя сжатия

Процесс сжатия может сорваться двумя способами. Острый случай легко заметить: сжатие происходит, затем огромный объем данных сразу заполняет окно, механизм сжатия снова работает, появляется тот же объем данных, и цикл повторяется, словно пытаются вычерпать воду из лодки, одновременно делая в ней дыру. Claude Code прекращает попытки выполнения операции вместо того, чтобы тратить ресурсы в бесконечном цикле, используя встроенную логику для обнаружения застревания и отсутствия прогресса. Это правильное поведение, но сам цикл является сигналом того, что используется неверный подход. В идеале агент должен отступить и попробовать другой способ вместо того, чтобы повторять попытки с тем же инструментом. Если один крупный файл постоянно заставляет процесс сжатия, снижение порога не является решением. Решением будет чтение ограниченного числа строк, поиск в узком диапазоне, работа с устойчивыми данными или передача файла другому агенту, у которого окно может быть перезаполнено. Каждый раз, когда начинается настройка сжатия, стоит спросить, заключается ли решение в повышении уровня на три ступени или в совершенно другом подходе.

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

Повторные сжатия

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

Что должно сохраниться

В различных системах структурированные краткие изложения сходятся примерно к одним и тем же категориям:

• Цель: что должно быть достигнуто?
• Статус: что было узнано или изменено?
• Работа и задачи: что уже сделано, а что осталось?
• Нерешённые вопросы: какие вопросы всё ещё остаются нерешёнными, ограничены или находятся на рассмотрении?

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

Связанные материалы

• Создание среды санкционирования для кодинг-агента и поддержание компактности его окна контекста — Добавьте среду санкционирования в виде ремня безопасности или пузырчатой упаковки к агенту и управляйте контекстом с помощью файлов-резервов, шаблонов, сжатия и вставки данных в конце процесса, учитывающей кэш префиксов.
• Harness Engineering: Среда выполнения, превращающая LLM в агента — Что на самом деле позволяет кодирующему агенту функционировать: циклы, механизмы вызова инструментов, способные выдерживать ошибки, а также системы разрешений типа «разрешить», «спросить», «отклонить», показанные на примере примерно 600 строк простого Python.
• Создание системы управления корпоративными AI-агентами: политики, процедуры утверждения и оценки — Практический обзор механизмов управления AI-моделью: реестр инструментов, движок политик, процедуры утверждения, типизированные контракты на Python, тесты, оценки и процесс развертывания.