Всередині 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-тести до коду і журнал перевірки, що фіксує, що реально запускалося.