Системы управления контекстом для бизнеса

июнь 2026

Эта статья опирается на пролог — «Всё есть контекст» — и открывает три связанные части, следующие за ним. Следующие две: «Человек становится владельцем цели» и «Цифровой двойник».

От «вынести вовне и дистиллировать» — к «управлять в масштабе»

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

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

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

Дуга: от промптов к контексту к харнессу

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

Промпт-инжиниринг (2022–2023) был сосредоточен на том, как формулировать запросы. Chain-of-thought, few-shot примеры, ролевые промпты, форматирование вывода. Предполагалось, что узкое место — в формулировке: сформулируй вопрос правильно, получи правильный ответ. Это работало для однократных взаимодействий. Но производственные приложения быстро упёрлись в ограничения: нельзя вместить всю кодовую базу в промпт, модель забывает всё между сессиями, одноходовое выполнение не поддерживает итерацию или восстановление после ошибок.

Как заметил Андрей Карпатий в июне 2025 года: «Люди ассоциируют промпты с короткими описаниями задач, которые дают LLM в повседневном использовании. Тогда как в каждом промышленном LLM-приложении контекстный инжиниринг — это тонкое искусство и наука заполнения контекстного окна именно той информацией, которая нужна для следующего шага».

Контекстный инжиниринг (2024–2025) сместил фокус с вопроса на информационную среду. Что видит модель, когда рассуждает? RAG, большие контекстные окна, постоянные системные промпты, модули памяти, структурированное форматирование контекста. Контекстный инжиниринг признал, что ответ модели зависит от того, что она знает в момент ответа. Лучшая сборка контекста давала лучшие результаты.

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

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

Харнесс агентов (2025–2026) добавляет оркестровый слой, которого не хватало контекстному инжинирингу. Многоагентная исследовательская система Anthropic использует «паттерн оркестровщик-рабочий, где ведущий агент координирует процесс, делегируя специализированным подагентам, работающим параллельно». Архитектура самодвижущихся кодовых баз Cursor ввела «корневой планировщик, которому принадлежит весь объём инструкций пользователя. Он не пишет код сам. Рабочие берут задачи и несут единственную ответственность за доведение их до завершения». Эти сходящиеся паттерны отражают признание индустрии: координация, границы и управление — не дополнительные функции, а основа.

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

Проблема токеномики

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

Что не открыто — это вывод на уровне компании, и именно здесь живёт устойчивая выгода. Ваш бюджет токенов конечен и конкурентен — независимо от того, что происходит глобально. Каждый токен, который ваши агенты тратят на воссоздание контекста, который у них уже должен был быть, — это токен, который конкурент может потратить на реальную работу. Разрыв в эффективности накапливается. Агенты, платформы и модели — это преимущества, которые может купить любая организация. Что нельзя купить — это опыт, который вы прожили, вынесли вовне и дистиллировали в пригодный контекст. Это ваш дистиллированный, оцифрованный опыт — и это единственная часть AI-стека, которая по-настоящему невоспроизводима. Сырые данные — это товар и шум (пролог назвал это: сырая фиксация — не контекст). Дистиллированный корпус — редкий, защищаемый актив. Дистиллированный интеллект обеспечивает эффективность по токенам; эффективность по токенам — это защитный ров (moat).

Два режима отказа подрывают этот актив ещё до его формирования:

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

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

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

Почему существующих инструментов недостаточно

Большинство корпоративных AI-инструментов остаются привязанными к эпохе контекстного инжиниринга. Они оптимизируют поиск. Они не управляют выполнением.

Два конкретных пробела:

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

Нет иерархии верификации. Машинная верификация (скомпилировался ли код?) — это не то же самое, что бизнес-верификация (стоит ли это публиковать?). Без явных шлюзов, разделяющих механические проверки и человеческое одобрение, организации либо слишком доверяют AI-результатам, либо создают узкие места проверки, сводящие на нет преимущество в скорости.

Системы управления контекстом закрывают эти пробелы, обращаясь с контекстом не как с входными данными для поиска, а как с управляемым, версионируемым, поддающимся аудиту активом.

Принцип границ записи

Представьте рабочее пространство, где каждый агент может писать куда угодно. Исследовательский агент сбрасывает свои находки в общее пространство; агент реализации, которому нужен черновой файл, создаёт его с похожим именем рядом; следующее обновление исследовательского агента тихо перезаписывает черновой файл; при следующем чтении агент реализации получает исследовательский контент вместо своего. Ничего не сломано. У никакого агента нет ошибки. Каждый делал именно свою работу. Но результат теперь содержит фрагменты двух не связанных между собой кусков работы, и чтобы понять почему — нужно восстановить, кто трогал какой файл, в каком порядке, на основании чего: послеполудня судебной археологии ради ошибки, которая не была ничьей виной.

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

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

Принцип двухфазного одобрения

Машинная верификация подтверждает структурную корректность. Человек подтверждает бизнес-намерение. Разделять их — второй несущий принцип.

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

VERIFY-OK — это не PASS. Машинная верификация перехватывает структурные проблемы. Человеческое продвижение перехватывает бизнес-проблемы. Ни то, ни другое в одиночку недостаточно. Вместе они создают надлежащее управление, не заставляя людей проверять каждый промежуточный шаг: агенты работают быстро, верификация автоматизирована, но финальный шлюз требует человеческого суждения по решениям, которые не должны быть полностью автоматизированы.

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

Принцип верификации от цели

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

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

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

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

Почему развороты дёшевы

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

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

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

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

Что мы всё ещё решаем

Честный учёт требует признания открытых проблем.

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

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

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

Зрелость исследовательского графа. Граф знаний, отслеживающий артефакты и их отношения, работает хорошо. Более сложная проблема — отслеживание паттернов и инсайтов во многих циклах, чтобы более ранние исследования действительно информировали более поздние работы без загрязнения контекста — находится на ранней стадии.

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

Принцип за системой

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

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

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

Следующая статья серии: Человек становится владельцем цели.