Каждая агентная система сталкивается с одним и тем же неудобным компромиссом. Вы хотите иметь глубокую, хорошо организованную базу знаний, которая проходит код-ревью и сохраняется в истории git. Но в то же время вам нужно, чтобы среда выполнения работала быстро и не теряла фокус. Эти две потребности противоречат друг другу. Чем больше инструкций вы сохраняете, тем сильнее искушение вывалить их все в промпт и надеяться на лучшее. Эта надежда обходится дорого.
В экосистеме Agent Project Context это напряжение четко распределяется между двумя уровнями. APC отвечает за долговечность. APX — за скорость. Понимание того, как они взаимодействуют — и почему APX отказывается предварительно загружать каждое определение навыка — расскажет вам о промпт-инжиниринге больше, чем большинство руководств по оптимизации.
Архив и движок
Задача APC — обеспечение постоянства. Она хранит переиспользуемые файлы навыков в директории .apc/skills/ в виде обычных Markdown-документов. Поскольку эти файлы находятся внутри вашего репозитория, они сопровождаются системой контроля версий. Вы можете создать pull request, который изменяет процедуру развертывания. Вы можете сравнить (сделать diff) откат политики безопасности, сделанный шесть недель назад. Вы можете провести аудит того, что именно должен был знать агент и когда. Такая проверяемость критически важна, когда выходит неудачное развертывание или когда аудитор по комплаенсу начинает задавать вопросы.
APX, с другой стороны, живет моментом. Он управляет самим диалогом между вами и моделью. Его цель — не архивировать знания, а использовать их максимально точно. Когда APX воспринимает навыки как постоянный багаж, вся система замедляется. Контекстное окно переполняется. Стоимость токенов растет. Что еще хуже, внимание модели рассеивается на инструкциях, которые не имеют никакого отношения к текущему запросу.
Вот почему содержимое навыков загружается по требованию.
Реальная цена раздутого промпта
Большинство команд понимают, что токены стоят денег. Но лишь немногие осознают, что нерелевантные токены стоят точности.
Когда APX вставляет каждый доступный навык в каждый ход диалога, промпт становится зашумленным. Модель получает одновременно runbook по развертыванию, руководство по безопасности, справочник по стилю API, чек-лист тестирования и FAQ по онбордингу. Даже при большом контекстном окне качество рассуждений снижается, когда модели приходится сначала просеивать шум в поисках полезного сигнала. Она может зацепиться за требование безопасности, предназначенное для продакшн-развертывания, отвечая на вопрос о настройке локального тестирования. Она может «галлюцинировать» шаги из чек-листа релиза при исправлении простой ошибки. Каждый лишний абзац не связанного с делом текста — это отвлекающий фактор, который рано или поздно сработает.
Математика проста. В большинстве ходов не нужны большинство навыков. Если вы просите быстро исправить ошибку в логе, вам не нужен полный текст runbook по развертыванию или руководство по усилению безопасности. Вам нужно, чтобы модель увидела ошибку, поняла соглашения вашего проекта и отредактировала нужный файл. Загрузка нерелевантного содержимого навыков не помогает модели в этом. Она заставляет модель фильтровать бесполезные данные еще до того, как она приступит к решению вашей реальной проблемы.
Как работает загрузка по требованию
Механизм прост, но продуман. APC продолжает хранить первоисточник (ground truth). Определения ваших навыков остаются там, где им и положено: в .apc/skills/<name>.md.
APX не копирует эти файлы в активную память. Вместо этого он составляет компактный реестр имен навыков. Модель видит этот список и понимает, что существует каталог. Если ей нужно просмотреть или подтвердить доступные возможности, она может вызвать list_skills. Это дает ей видимость без избыточного объема данных.
Когда задача действительно требует точного синтаксиса, детальных шагов или специфических ограничений, закодированных в файле навыка, модель вызывает load_skill. В этот момент, и только в этот момент, APX извлекает полное тело Markdown из APC и вставляет его в контекст. Инструкция поступает сразу в готовом виде, используется один раз по назначению, и система избегает переноса этого «мертвого груза».
Представьте разницу между импортом библиотеки и копированием определений каждой функции в ваш основной файл. Первый подход сохраняет чистоту и навигацию по коду. Второй создает хаос, который компилируется лишь по воле случая.
Кто побеждает при конфликте навыков
APX также соблюдает четкий порядок приоритетов при загрузке навыков. Не каждая среда одинакова, и общие советы никогда не должны перекрывать локальные знания.
Навыки проекта имеют наивысший приоритет. Эти файлы находятся в вашем текущем репозитории в директории .apc/skills/. Они фиксируют специфические соглашения вашей команды, ваши кастомные обертки, устаревшие стандарты именования и ваш конкретный инструментарий. Если ваш проект определяет собственный способ обработки миграций базы данных, именно это определение будет приоритетным.
Далее идут глобальные навыки (Global skills). Они охватывают общеорганизационные паттерны, которые применяются, если сам проект не задает никаких правил. Они работают как стандартная библиотека.
Встроенные навыки среды выполнения (Built-in runtime skills) находятся на самом нижнем уровне и служат резервным вариантом. Они отвечают за общие возможности, которые должен понимать любой агент, но которые ни один конкретный проект не счел нужным переопределить.
Такой многоуровневый подход означает, что ваш репозиторий сохраняет контроль над собственным поведением. Глобальный или встроенный навык не может случайно перехватить рабочий процесс, который ваша команда намеренно настроила под себя.
Как это выглядит на практике
Представьте типичную задачу по обслуживанию. Коллега вставляет лог ошибки в чат. Трассировка стека (traceback) указывает на одну единственную ссылку на null в модуле утилит. Исправление, скорее всего, займет всего две строки защитного программирования.
В системе без загрузки по требованию APX забила бы контекст всеми известными ей навыками. Теперь модели приходится просматривать сорок страниц текста, прежде чем она притронется к тем двум строкам. Она видит чек-лист релиза и задается вопросом, не нужно ли обновить версию. Она видит руководство по безопасности и задумывается о валидации входных данных в функции, которой просто нужна проверка на null. Она видит план развертывания (deployment runbook) и начинает думать о стейджинг-средах. Модель теряет фокус. Ответ занимает больше времени. Счетчик токенов крутится как сумасшедший.
Благодаря архитектуре APX с загрузкой по требованию, модель видит только названия. Она знает, что существуют [release-checklist], [security-guide], [deployment-runbook] и [error-handling]. Она игнорирует первые три. Она может загрузить [error-handling], если в вашем проекте приняты специфические соглашения по обеспечению null-safety. Она исправляет баг. Несвязанные навыки так и не попали в окно контекста. Модель сохраняла концентрацию, потому что промпт оставался чистым.
Та же логика применима и к действительно сложным задачам. Если позже вы попросите агента подготовить развертывание в продакшн, он сможет загрузить план развертывания, обратиться к руководству по безопасности и следовать чек-листу релиза именно тогда, когда эти шаги станут актуальными. Знания всегда были на месте. Они просто ждали подходящего момента.
Дисциплина промптов как архитектура
Разделение между APC и APX — это не просто деталь реализации. Это философия дисциплины промптов. APC сохраняет знания навсегда, делая их доступными для проверки, версионируемыми и безопасными. APX решает, какая часть этих знаний заслуживает места в активном контексте прямо сейчас.
Богатый каталог навыков — это актив. Раздутый промпт — это пассив. Цель состоит в том, чтобы сделать ваш контекст переносимым, не делая его постоянно активным. Ваш репозиторий должен содержать все инструкции, которые когда-либо писала ваша команда, но агент должен читать только те, которые помогают в решении текущей задачи.
Если ваша система заставляет модель тащить содержимое каждого навыка в каждый ход диалога, вы строите не интеллектуального помощника. Вы строите библиотекаря, который тащит весь архив к каждому вопросу на справочной стойке. Сохраняйте всё. Загружайте только важное. Именно так вы сохраните агентов быстрыми, контекст — чистым, а рассуждения — точными.