Статті
Годі віддавати SOP напряму AI Agent: точно керуйте поведінкою агента за допомогою RFC 2119 (MUST/SHOULD/MAY)
Коли людський SOP напряму віддають LLM, агент часто один раз працює правильно, а потім тричі провалюється. У цьому дописі показано, як переписати System Prompt і Agent Skill за допомогою MUST, SHOULD і MAY з RFC 2119, чітко розмежувавши жорсткі обмеження, наполегливі рекомендації та самостійний розсуд, а також наведено три практичні принципи.
· 1 хв читання
Багато команд, упроваджуючи агентів, найчастіше наступають на одні й ті самі граблі: віддають LLM цілий «людський SOP» із Word чи Notion і очікують, що воно саме все впорає. Результат нагадує купівлю лотерейного квитка: один раз спрацювало, тричі провалилося.
Річ не в недостатніх можливостях моделі, а в тому, що людський SOP містить багато неявного «мовчазного знання (Tacit Knowledge)». Людський мозок автоматично розуміє: «якщо сума менша за 500 юанів, погодження не потрібне», «якщо тут виникла помилка, цей крок можна поки пропустити»; але для LLM в неструктурованому тексті немає меж сили вимог, тож вона може лише діяти на власний розсуд.
Щоб поведінка агента стала детермінованою, першим кроком має стати не більша модель, а класичний стандарт із специфікацій мережевих протоколів: градація семантики RFC 2119.
Спершу висновок: позначайте як MUST лише відповідність вимогам, інформаційну безпеку та основну Schema, а решту меж віддайте SHOULD і MAY; вузли з високим ризиком передавайте на ручну перевірку.
Чому саме RFC 2119?#
Коли ви пишете System Prompt, Agent Skill чи Workflow Rule, розмиті «зверніть увагу», «бажано», «намагайтеся» не мають для моделі жодної обмежувальної сили. Чітка ієрархія дієслів дає змогу примусово окреслити межі рішень.
MUST / REQUIRED: жорстке обмеження, жодних компромісів#
- Семантика: категорично не можна пропускати, винятків немає.
- Сфера застосування: перевірка даних, перевірки безпеки, вимоги до формату вихідної Schema, блокування високоризикових дій.
- Приклад: «Перед викликом API рахунків-фактур
MUST спершу перевірити, чи існує табельний номер працівника; якщо відповідь порожня, MUST негайно перервати виконання».
SHOULD / RECOMMENDED: наполеглива рекомендація, але обґрунтоване відхилення дозволене#
- Семантика: слід дотримуватися, якщо немає дуже вагомих підстав у контексті; у разі відхилення агент має пояснити своє обґрунтування.
- Сфера застосування: вибір стратегії алгоритму, пріоритети класифікації, логіка повторних спроб.
- Приклад: «Для Ticket із консультаційними запитами клієнтів
SHOULD насамперед призначати першу лінію підтримки; але якщо йдеться про спір щодо платежів, дозволено переадресувати групі фінансового погодження».
MAY / OPTIONAL: самостійний вибір, повний розсуд#
- Семантика: модель може сама вирішити, виконувати чи ні, залежно від ресурсів поточного контексту або бюджету токенів.
- Сфера застосування: додаткові пояснення, пропозиції для подальших роздумів, необов'язковий формат журналу.
- Приклад: «Під час створення підсумку обробки
MAY додати 1–2 історичні Ticket ID схожих випадків для довідки».
Три принципи впровадження#
1. Відмовтеся від суцільних MUST, залишайте простір для Reasoning#
Якщо записати всі правила як MUST, LLM фактично використовується як Deterministic Compiler, і це легко призводить до конфліктів між правилами або логічного взаємоблокування, коли розростається Context. Позначайте як MUST лише «відповідність вимогам, інформаційну безпеку та основну Schema», а решту меж передайте SHOULD.
2. Поєднуйте зі структурованими блоками Markdown#
Розбийте Prompt на чотири блоки нижче, щоб область дії (Scope) сили семантики була очевидною:
## Parameters
## Constraints (RFC 2119)
## Execution Steps
## Error Handling
3. Для вузлів із високим ризиком запроваджуйте Human-in-the-loop#
Коли спрацьовує умова ключової межі MUST (наприклад, сума окремої операції > $5,000 або зміна прав Admin), єдиною MUST-поведінкою агента є «призупинити конвеєр і чекати, поки людина натисне OK», а не ухвалювати рішення замість людини.
Висновок: від Demo-іграшки до Production-Ready#
Сприймайте агента як промислову виробничу лінію, а не як єдиного всемогутнього «майстра на всі руки». Побудувавши поведінковий контракт на основі RFC 2119, ви зможете перевести свого агента від Demo-іграшки до справжнього рівня Production-Ready.