Внутри SHARP Agent Protocol v2: промпт на 22 килобайта, который управляет агентами как инженерной командой
SHARP Agent Protocol v2 - набор инструкций на 488 строк, превращающий одну языковую модель в управляемую инженерную команду: ровно одна задача на свежего субагента, adversarial-тесты до кода, независимая проверка и долговременные файлы памяти, переживающие потерю контекста. Что он делает, как использовать и где его заявления опережают доказательства.
Сегодня в разделе промптов на этом сайте появилась новая запись: LLM Sharp Reasoning Prompt, полное название - SHARP Agent Protocol v2, Multi-Agent Execution, Adversarial Verification and Memory Context Boost. При 488 строках и примерно 22 килобайтах это не промпт, который вставляют, чтобы получить письмо получше. Это руководство по эксплуатации, которое пытается превратить одну языковую модель в управляемую инженерную команду: менеджер, который планирует, свежие субагенты, каждый из которых делает ровно одну задачу, adversarial-тестировщик, пишущий сценарии отказов до появления кода, и набор долговременных файлов памяти, переживающих разговор. Я внимательно прочитал весь текст. Эта запись - моя карта того, что он делает, какие идеи стоит позаимствовать и где его обещания выходят за пределы того, что промпт реально может гарантировать.
Короткая версия
SHARP - это протокол в стиле системного промпта из трёх частей. Часть I задаёт адаптивный цикл исполнения - triage, plan, ideate, test-spec, work, verify, manage, - в котором агент-менеджер делегирует ровно одну задачу каждому свежему субагенту, а затем независимо проверяет результат по явным критериям приёмки. Часть II - дисциплина памяти: долговременные файлы с именами по умолчанию вроде AGENTS.md, TASKS.md, DECISIONS.md, HANDOFF.md и VERIFICATION.md, иерархия извлечения, чекпоинты и обязательная процедура восстановления после потери контекста. Часть III собирает всё в один цикл со строгим форматом финального отчёта (Done, Verified, Not verified, Risks, Resume state). Его ключевые тезисы - планы не являются исполнением, реализация не является доказательством, история разговора не является памятью - это здравая инженерная культура, сжатая в инструкции. Издержки реальны: большой расход токенов на церемонию, предположения о возможностях платформы, которых нет во многих конфигурациях, и отсутствие опубликованной оценки, так что польза аргументирована, но не измерена. Полный текст опубликован дословно в разделе промптов, ссылка ниже.
Что этот промпт собой представляет
SHARP представляет собой единый блок инструкций, который предполагается установить как системный промпт или постоянный набор указаний для coding- или инженерного агента. Он открывается формулировкой миссии - работать как дисциплинированный, самокорректирующийся инженерный агент - и списком из семи ключевых принципов, которые читаются как документ о культуре code review: планы - это не исполнение; реализация - не доказательство корректности; история разговора - не долговременная память; саммари - не истина в последней инстанции; субагенты - соисполнители, а не авторитеты; задача не завершена, пока не проверены её обязательные критерии приёмки; и никогда не заявлять о возможностях, действиях, результатах тестов или успехе, которые нельзя подтвердить. Тело документа - девятнадцать пронумерованных разделов в трёх частях, завершающихся финальным правилом: никогда не фабриковать прогресс. Текст не называет автора и не несёт никакой информации о происхождении, кроме v2 в заголовке, что как минимум намекает на итерацию. Я не делаю никаких заявлений о том, откуда он взялся; дальше - анализ самого текста, который дословно опубликован на этом сайте.
Часть I: инженерный цикл, а не чат
Первая часть определяет семь фаз. TRIAGE оценивает задачу и выбирает один из трёх уровней строгости - тривиальный, стандартный или сложный, - с явным предупреждением, что triage определяет объём работы, а не разрешение пропускать обязательные проверки. PLAN заставляет менеджера написать короткую стратегию, от трёх до шести конкретных задач с метками сложности, критерии приёмки для каждой и доказательства, которые подтвердят успех. IDEATE отправляет задачу свежему субагенту, не видевшему текущую работу, требует как минимум три действительно различных подхода с режимами отказа и запрещает код реализации на этом этапе. TEST-SPEC - необычная фаза: до начала реализации свежий adversarial-субагент пишет тесты, призванные выяснить, как предложенное решение может сломаться, - граничные входы, гонки, риски инъекций, регрессии, - и эти тесты сохраняются для фазы проверки. WORK передаёт ровно одну задачу каждому свежему субагенту-исполнителю с дисциплинированным брифом, запрещает разрастание скоупа и требует self-attack-прохода с названными как минимум тремя правдоподобными режимами отказа. VERIFY возвращает управление менеджеру: он обязан реально запустить реализацию и adversarial-тесты, а правила доказательности прямы - никогда не заявлять, что тест прошёл, если он не запускался и не прошёл, никогда не скрывать пропущенные проверки, и проваленный обязательный критерий отменяет все предыдущие заявления о завершении. MANAGE замыкает цикл светофорной классификацией (зелёный, жёлтый, красный) и процедурой восстановления, которая откатывается, запускает альтернативы параллельно или меняет подход вместо бесконечного латания.
Часть II: память как полноправный компонент
Вторая часть трактует исчерпание контекстного окна, перезапуски сессий и компактификацию как ожидаемые условия работы, а не краевые случаи. Её центральное правило: критически важное знание должно восстанавливаться из долговременного состояния, а не из истории разговора. Предписывается пять файлов по умолчанию - AGENTS.md для постоянных инструкций проекта, TASKS.md для состояния исполнения, DECISIONS.md для истории решений с отклонёнными альтернативами, HANDOFF.md как точка возобновления и VERIFICATION.md как журнал реально выполненных проверок, - с оговоркой, что имена - значения по умолчанию и существующие записи проекта следует переиспользовать. Вокруг этих файлов выстроены иерархия извлечения (текущие инструкции и документация репозитория выше памяти, память выше саммари разговоров), правила обновления записей на значимых вехах, управление контекстным бюджетом с сохранением чекпоинтов восстановления до вероятной компактификации и строгое допущение, что каждый свежий субагент начинает без неявной памяти, так что брифы на передачу должны быть полными. Два раздела выделяются. CONTEXT RECOVERY - обязательная процедура из девяти шагов после любого прерывания: перечитать записи, проверить фактическое состояние репозитория, убедиться, что ранее заявленные изменения реально существуют, и возобновить с самой ранней нерешённой зависимости - никогда не доверяя саммари, противоречащему наблюдаемому состоянию. А RESUMABILITY TEST спрашивает о любой существенной незавершённой работе: сможет ли свежий агент продолжить только по долговременным записям; если записи не отвечают, чего хочет пользователь, что проверено и что делать дальше, их нужно улучшить до конца сессии.
Часть III: один цикл, один формат отчёта
Финальная часть сжимает всё в единый конвейер - triage, plan, ideate, test-spec, work, verify, manage, обновление памяти, следующая задача - с извлечением из памяти на протяжении всего пути. Заключительный раздел определяет формат финального ответа, который я бы с радостью увидел принятым повсеместно: сообщить, что сделано, что проверено и с какими наблюдаемыми результатами, что не проверено, каковы риски и в каком состоянии возобновления незавершённая работа. Он также запрещает заявлять, что память сохранена, если запись реально не удалась, и заявлять, что задачу можно возобновить, если записей не существует. Последняя строка - вся философия в одном предложении: истину устанавливают фактическая реализация и выполненная проверка.
Что сделано верно
Протокол читается как список наблюдаемых режимов отказа агентов с контрмерой у каждого. Галлюцинированный успех получает правила доказательности. Разрастание скоупа - правило ровно одной задачи. Потеря контекста - файлы памяти и процедуру восстановления. Сикофантные субагенты - строку о том, что код и заявления субагента не заслуживают доверия, пока не проверены. Дизайн со свежим контекстом на задачу отражает то, как серьёзные оркестрационные фреймворки уже себя ведут, а написание adversarial-тестов до реализации - это red-team-мышление, применённое в самый дешёвый возможный момент. Мне также по душе ограничения честности, которые большинство промптов пропускает: раскрывай, когда требуемая возможность недоступна, никогда не имитируй соответствие и никогда не понижай задачу, чтобы уклониться от обязательных проверок. Примените вы весь протокол или нет, привычка VERIFICATION.md - текущий журнал выполненных команд и наблюдаемых исходов - стоит того, чтобы её украсть отдельно.
Как это использовать
Вставьте полный текст как системный промпт или постоянные инструкции агентной платформы, которая реально поддерживает субагентов и персистентные файлы, - именно такую аудиторию предполагает протокол. На более лёгкой конфигурации раздел triage даёт разрешение на урезанную версию: тривиальные задачи получают прямое исполнение с соразмерными проверками, и полная мультиагентная церемония запускается только на сложной работе. Адаптируйте имена файлов памяти под то, что проект уже использует, вместо создания параллельных документов - текст это явно разрешает. Ожидайте резкого роста расхода токенов на трудных задачах, поскольку ideation, adversarial-написание тестов и независимая проверка - по замыслу дополнительные вызовы модели. И сохраните формат финального отчёта, даже если не сохраните ничего больше; он выводит разницу между сделано, проверено и предполагается на свет.
Честные ограничения
Их несколько, и сам промпт, вероятно, настоял бы, чтобы я их перечислил. Во-первых, нет опубликованной оценки: ничто в тексте или где-либо ещё не показывает, что агенты, следующие SHARP, производят измеримо меньше дефектов, чем более простые наборы инструкций, так что вся польза здесь аргументирована структурой, а не доказательствами. Во-вторых, протокол предполагает возможности платформы - порождаемых свежих субагентов, долговременные файлы, извлечение, телеметрию расхода контекста, - которых во многих развёртываниях просто нет, и модель на меньшей платформе может имитировать церемонию вместо честного пропуска. В-третьих, 22 килобайта инструкций - сами по себе налог на контекст, конкурирующий с тем самым бюджетом, который разделы памяти пытаются защитить. В-четвёртых, промпт ограничивает поведение, но не может его гарантировать. Модель всё ещё может написать "все тесты прошли" про тесты, которые никогда не запускались, - протокол может запретить ложь, но не может её предотвратить, и поэтому привычка проверки на стороне менеджера важнее любого отдельного правила. Наконец, церемония имеет цену на мелких задачах даже с triage, и команды, у которых уже есть дисциплинированные CI и code review, найдут части протокола избыточными рядом с инструментами, которые обеспечивают те же правила механически, а не вежливой просьбой.
Где прочитать полный текст
Полный протокол опубликован дословно - все 488 строк - в разделе промптов этого сайта как LLM Sharp Reasoning Prompt, с окружающей страницей на шести языках. Если вы ведёте мультиагентные coding-рабочие процессы, он стоит двадцати минут чтения, даже если вы оставите себе только три идеи: одна задача на свежего субагента, adversarial-тесты до кода и журнал проверки, фиксирующий, что реально запускалось.