Пояснення виклику інструментів: як моделі прослять програмне забезпечення виконувати дії та де виникають збої.
Практичний огляд виклику функцій та використання інструментів: цикл запитів, схеми, інструменти для читання та виконання дій, агенти, MCP, вставка запитів, відстеження та поширені проблеми.
Джерела: Function Calling and Tool Use: How AI Agents Automate Workflows
Перші чат-боти були пристроями для відповідей на запитання. Людина вводила щось, надходила відповідь, і на цьому обмін закінчувався. Це було корисно, але це були обмежені системи. Модель могла описати, як забронювати рейс, не маючи можливості дізнатися ціни на сьогодні. Вона могла пояснити, що міститься у рахунку-фактурі, проте ніколи не могла створити його в системі бухгалтерського обліку. Вона могла запропонувати час зустрічі, але все одно не мала можливості переглянути календар будь-кого, не кажучи вже про додавання заходу до нього.
Виклик функцій усуває цю перешкоду. Модель мови отримує можливість просити допомоги у навколишньому програмному забезпеченні, і вся решта системи розвивається на основі цієї однієї здатності.
Модель, яка може просити про щось
Без інструментів модель відповідає на основі того, що вона засвоїла під час навчання. За їх допомогою вона може зробити висновок, що для відповіді на запит потрібна зовнішня допомога, та вказати, який інструмент має її надати: сервіс погоди, індекс пошуку, запит до бази даних, калькулятор, календар, процес оплати, пошук у CRM, інтерпретатор коду чи якась внутрішня бізнес-функція. Замість припущень модель формулює структурований запит, додаток його виконує, а модель продовжує роботу, маючи у руках свіжішу та точнішу інформацію. Великі провайдери, зокрема OpenAI, Anthropic та Google, разом із фреймворками на кшталт LangChain, описують використання інструментів у загальних рисах: моделі пропонуються добре визначені інструменти, вона вирішує, коли їх використати, передає структуровані аргументи та включає отримані результати у свою відповідь чи дію.
Корисне уявлення: модель — це „мозок“ для спілкування, а інструменти — це руки, очі, пам’ять, калькулятор, шухляда та фургон для доставки. Мозок визначає, чого хоче користувач. Інструменти виконують ті завдання, які пряма генерація тексту не може виконати безпечно чи надійно.
Виклик функції проти виклику інструменту
Ці два терміни використовуються як синоніми, проте другий є більш точним, адже його значення виходить за межі класичних програмних функцій. Інструмент може бути настільки простим, як get_weather(location), а може бути пошуком у базі даних, сеансом браузера, отриманням документа, калькулятором, командою оболонки, процесом проектування чи посиланням на зовнішню службу. У термінології OpenAI інструмент — це можливість, яка є доступною для моделі, а виклик інструменту — це особливий тип відповіді моделі з проханням скористатися однією з цих можливостей.
Важливо зазначити, що модель зазвичай сама нічого не виконує. У типовій схемі з боку клієнта вона повертає структурований запит, щось на кшталт виклику get_customer_profile із параметром customer_id 12345. Додаток отримує цей запит, аналізує його, виконує справжню функцію, збирає результат та повертає його моделі, яка потім формує свою кінцеву відповідь. Документована послідовність дій: надати доступні інструменти, отримати виклик інструменту, виконати код у власному додатку, надіслати результат та отримати або кінцеву відповідь, або подальші виклики інструментів.
Існують винятки. Деякі постачальники також пропонують інструменти з боку сервера, які працюють на їхній інфраструктурі. Anthropic чітко розділяє ці два підходи: клієнтські інструменти виконуються вашим додатком та представляються у вигляді структурованих блоків використання інструментів, тоді як серверні інструменти, такі як пошук в Інтернеті чи виконання коду, можуть працювати на боці Anthropic.
Це розрізнення має велике значення. Фраза «модель викликала API» може означати, що модель створила запит до вашого програмного забезпечення для виконання дії, або ж що платформа автоматично використала вбудований інструмент від імені моделі. У умовах реальної роботи це впливає на рівень безпеки, облік подій, витрати, спосіб обробки даних, те, хто схвалює що, та хто несе відповідальність у разі проблем.
Цикл у п’яти кроках
Більшість систем виклику функцій повторюють один цикл.
- Визначте інструменти. Кожен інструмент має назву, опис та список очікуваних вхідних даних. Інструмент для отримання інформації про погоду може потребувати назви міста та країни. Інструмент для повернення грошей може потребувати ідентифікатора замовлення, причини та максимальної суми. Інструмент для планування може потребувати імен учасників, дати, часу та теми. Приклади від OpenAI описують параметри у стилі JSON Schema з обов’язковими полями та обмеженнями, такими як additionalProperties, встановленим у значення false, а документація Google Gemini показує оголошення функцій, створені на основі назв, описів та структур вхідних даних.
- Користувач просить щось. Модель читає запит та вирішує, чи може вона негайно дати відповідь. Запит „Поясніть, що таке виклик функції“ ймовірно не потребує жодних інструментів. Запит „Який статус замовлення 8472?“ майже напевно потребує інструментів.
Цикл може виконуватися один раз або багато разів по колу. Агент може шукати, порівнювати результати, викликати інший інструмент, ставити додаткові запитання, оновлювати записи та нарешті узагальнювати виконані дії.
Мова як інтерфейс
Справжня перевага використання інструментів полягає у тому, що повсякденна мова стає гнучким фронт-ендом для програмного забезпечення.
Традиційно кожна функція потребує власних кнопок, форм, меню та алгоритмів виконання. Завдяки виклику функцій користувач може безпосередньо висловити свою мету: знайти найновіший рахунок-фактуру компанії Acme, перевірити, чи надійшла оплата, а якщо ні — надіслати ввічливе нагадувальне електронне листування. Одне речення приховує за собою кілька інструментів: пошук у CRM, отримання рахунку-фактури, перевірка статусу оплати, створення проєкту електронного листа та, можливо, запит на схвалення перед надсиланням будь-чого.
Хороший дизайн продукту не є необов’язковим. Змінюється лише те, де починається інтерфейс. Замість того, щоб змушувати користувачів вивчати структуру програмного забезпечення, воно адаптується під той спосіб, яким люди вже обговорюють свою роботу.
Це надає великого значення описам інструментів. Нечіткий опис залишає модель у невизначеності щодо того, як користуватися інструментом. Чіткий опис вказує, коли його використовувати, що він робить, що означає кожен вхідний параметр та що не варто припускати. Документація LangChain представляє інструменти як функції з чітко визначеними вхідними та вихідними параметрами, зазначаючи, що підказки типів та короткі описи допомагають моделі правильно ними користуватися.
Хороший інструмент — це більше, ніж просто функція. Це контракт.
Чотири терміни, які перетинаються
Люди змішують ці терміни, хоча вони належать до різних рівнів.
- Виклик функції — це механізм: модель просить про структурований виклик функції чи інструменту.
- Використання інструментів — це ширша можливість. Вона включає виклик функцій, вбудовані інструменти, пошук у Інтернеті, пошук файлів, виконання коду, керування комп’ютером, віддалені сервери та будь-які інші способи, за допомогою яких модель може взаємодіяти з зовнішніми системами.
- Агент — це система, яка поєднує використання інструментів у кількох кроках для досягнення мети. OpenAI описує агентів як додатки, які планують дії, використовують інструменти, працюють із фахівцями та відстежують прогрес у багатокрокових завданнях, а їхній SDK Agents визначає агента як LLM, налаштований із інструкціями, інструментами та додатковими елементами, такими як передача завдань, обмеження та структуровані результати.
Іншими словами: виклик функції — це роз’єм, інструменти — це пристрої, підключені до нього, агенти вирішують, як і коли їх використовувати, а автоматизація забезпечує їх функціонування як частини живої системи.
Навіщо це потрібно
Моделі мов добре справляються з розумінням, поєднанням та передачею інформації. Вони є поганим замінником калькуляторів, баз даних чи прямих моніторів. Вони можуть писати про погоду, але не зможуть дізнатися про сьогоднішні прогнози, якщо тільки не будуть підключені до відповідних даних. Вони можуть обговорювати рахунок-фактуру, але не зможуть отримати доступ до вашої системи бухгалтерського обліку, якщо вона не підключена. Вони можуть пояснювати код, але не зможуть визначити, чи не працює ваш сервіс, без даних моніторингу.
Інструменти заповнюють ці прогалини. Калькулятор забезпечує надійні арифметичні операції. Засоби пошуку надають актуальні факти. Інструменти для пошуку дозволяють знаходити відповіді в приватних документах. Інструменти баз даних відповідають на запитання щодо корпоративних записів. Інструменти для керування робочими процесами створюють заявки, надсилають повідомлення, оновлюють замовлення чи бронюють зустрічі. У документації Google Gemini переваги цих моделей зводяться до трьох: додавання знань, розширення можливостей та взаємодія з зовнішніми системами.
Саме тут досвід використання перестає нагадувати чат та починає нагадувати програмне забезпечення. Модель більше не просто генерує слова; вона допомагає координувати роботу.
Дослідження, що лежать в основі цієї ідеї
Агенти, які використовують інструменти, не з’явилися з нізвідки. Чотири попередні дослідження сформували цю галузь.
- MRKL Systems (2022) запропонували модульний підхід, який поєднує мовні моделі з зовнішніми модулями знань та міркувань. Основна ідея була простою: не просіть одну модель робити все; доручайте кожну завдання спеціалізованому компоненту.
- ReAct (2022) досліджував, як моделі можуть поєднувати міркування з діями. Замість того, щоб або лише думати, або лише діяти, підхід ReAct передбачає, що модель спочатку міркує, потім діє, спостерігає за результатом та коригує свій план. Цей цикл покращує продуктивність у завданнях на відповіді на запитання та прийняття рішень, а також робить поведінку моделі зрозумілішою.
- Toolformer (2023) перевіряв, чи може модель навчитися використовувати інструменти через прості API. Вона навчилася визначати, коли потрібен інструмент, що надсилати та як використовувати результат, на прикладі калькуляторів, пошукових систем, перекладачів та календарів.
- Gorilla (2023) був спрямований на масштабні виклики API та практичні проблеми: через велику кількість доступних інструментів моделі іноді вигадують виклики або передають неправильні аргументи. Gorilla поєднав навчання з пошуком інформації, щоб система могла стежити за змінами в документації API та робити менше помилок.
Усе це зводиться до однієї ідеї: найкращі системи ШІ — це не ізольовані моделі. Це частини більших систем, які поєднуються з інструментами, пам’яттю, правилами, програмним забезпеченням та людським контролем.
Як виглядає хороший інструмент
Якісні інструменти є спеціалізованими, зрозумілими та безпечними.
Спеціалізовані інструменти легше для моделей обирати та для розробників керувати. Інструмент під назвою update_everything є нечітким та небезпечним. create_refund_request є зрозумілішим. approve_refund вимагає ще більшої обережності, оскільки він впливає на реальний світ.
Зрозумілі інструменти мають прості назви та описи. Модель не повинна здогадуватися, чи означає функція fetch_record отримання профілю клієнта, завантаження файлу чи отримання медичної картки. Опис має вказувати її призначення, ситуації, коли вона потрібна, значення кожного аргументу та форму значення, яке повертається.
Безпечні інструменти мають вбудовані обмеження. Вони перевіряють дозволи, верифікують вхідні дані та уникають надання доступу, який не є необхідним. Вони повідомляють чіткі помилки, ведуть журнали та запитують схвалення людини перед виконанням конфіденційних дій. Вони ніколи не надають моделі більше повноважень, ніж це необхідно для виконання завдання.
OpenAI рекомендує суворі схеми, щоб аргументи надходили надійно, а його SDK для агентів спрямовує розробників на дотримання правил, людський огляд, чіткі результати, керування станом та можливість спостереження у міру зростання робочих процесів. На практиці найкращі інструменти є простими: кожен з них добре виконує одну функцію та не дивує нікого — ні розробника, ні моделі, ні користувача.
Схеми як граматика
Схема — це граматика використання інструменту. Коли модель викликає функцію, вона повинна надати аргументи у форматі, зрозумілому додатку. Схема визначає, які поля існують, їхні типи, які з них є обов’язковими, а іноді й які значення дозволені. Інструмент для прогнозування погоди може вимагати рядкове значення місця та поле з одиницями вимірювання, обмежене цельсієм або Фаренгейтом.
Суворі схеми усувають неоднозначність та спрощують перевірку. У документації OpenAI пояснюється, що режим суворості забезпечує дотримання викликів оголошеної схеми, вимагаючи таких обмежень, як встановлення параметра additionalProperties у значення false для кожного поля, позначеного як обов’язкове, а також використання типів, що дозволяють значення бути null, для позначення необов’язкових даних.
Проте схема сама по собі не робить систему безпечною. Запит із ідеально сформатованими даними все одно може бути неправильним. Виклик send_email на адресу all_customers@example.com може ідеально відповідати схемі, але все одно бути жахливою ідеєю. Тому перевірка схеми має супроводжуватися бізнес-правилами, авторизацією, обмеженнями кількості запитів, кроками перевірки та моніторингом.
Читання проти дії
Одним із важливих рішень у проектуванні є визначення того, чи інструмент лише читає дані, чи також виконує дії.
Інструменти лише для читання отримують інформацію: шукають документи, знаходять записи, перевіряють запаси, отримують дані про погоду, обчислюють суми, аналізують журнали. Вони все одно можуть розкривати конфіденційні дані та потребують контролю доступу, але зазвичай нічого не змінюють.
Інструменти для виконання дій допомагають вирішувати завдання. Вони надсилають електронні листи, оформлюють замовлення, скасовують підписки, видають повернення грошей, оновлюють бази даних, створюють заявки, розгортають код чи планують зустрічі. Помилки з їх використанням мають реальні наслідки.
Добре спроєктований агент різно ставиться до цих двох типів. Інструменти лише для читання можна використовувати більш вільно, проте все одно з дотриманням перевірок дозволів. Інструменти для виконання дій зазвичай потребують суворішого контролю: екрани підтвердження, кроки схвалення, ліміти транзакцій, журнали аудиту, опції скасування та чіткі повідомлення для користувача.
На цьому етапі автоматизація стає питанням управління, а не лише технічним. Питання не в тому, чи може модель викликати функцію. Справа в тому, за яких умов будь-якій системі слід дозволити виконувати дії від імені людини.
Від окремих викликів до агентів
Один виклик інструменту може відповісти на просте запитання. Агенти призначені для більш складних та заплутаних завдань. Якщо потрібно підготувати щотижневий звіт про продажі та позначити рахунки, які потребують уваги, агенту доведеться зібрати дані про продажі, порівняти їх із попередніми тижнями, виявити незвичайні закономірності, прочитати примітки з CRM, написати звіт та надіслати його менеджеру. Це ланцюг рішень, а не один виклик.
Фреймворки агентів керують цим процесом. Вони зберігають стан, запускають інструменти, повторюють невдалі кроки, передають завдання між спеціалізованими агентами, генерують структурований результат, дотримуються правил та ведуть журнали. Документація SDK Agents від OpenAI описує два поширені підходи: патерн менеджера, у якому центральний агент викликає спеціалізовані агенти, як ніби це інструменти, та механізм передачі контролю, при якому один агент передає керування спеціалісту.
Це потужно, але не те, що варто ідеалізувати. Агент — це не маленький працівник, який працює всередині вашого програмного забезпечення. Це ймовірнісна система, створена з коду, і їй потрібні чітко визначені обов’язки, обмежені права, тестові випадки, моніторинг, шляхи ескалації та плани на випадок збоїв. Чим більше свободи отримує агент, тим ретельнішою має бути розробка, пов’язана з ним.
Де автоматизація зустрічається з реальною роботою
Автоматизація — це етап, на якому використання інструментів перетворюється на операції.
- Команда підтримки може використовувати спеціаліста для класифікації заявок, отримання відповідних документів з правилами, підготовки відповідей та пропозицій щодо подальших кроків.
- Фінансова команда може узгоджувати рахунки-фактури, знаходити відсутні замовлення та готувати звіти про винятки.
- Інженерна команда може аналізувати невдалиі тести, переглядати журнали, пропонувати способи виправлення та створювати запити на інтеграцію коду.
- Команда з продажів може удосконалювати інформацію про потенційних клієнтів, готувати записи дзвінків та оновлювати систему CRM.
Найефективніша автоматизація починається не з того, що може зробити модель, а з існуючого робочого процесу. Де починається робота? Яку інформацію вона потребує? Які рішення є рутинними, а які — делікатними? Де люди наразі переглядають, схвалюють чи виправляють щось? Які помилки будуть дратувати, а які — коштуватимуть дорого?
Маючи ці відповіді, інструменти допомагають зробити процес більш плавним. Агент збирає факти, заповнює форми, складає повідомлення, порівнює записи та робить рекомендації, тоді як люди залишаються залученими там, де важливі судження, відповідальність чи довіра.
Стандартизовані з’єднання
Спочатку інтеграції були індивідуально розроблені. Кожен додаток мав свій спосіб надання інструментів, ресурсів, запитів та механізмів автентифікації. Це підходило для невеликих проектів, але ставало незручним, коли організації починали під’єднувати більше моделей до більшої кількості систем.
Протокол контексту моделі (MCP) є однією з спроб стандартизувати цей шар. Його специфікація описує, як додатки можуть ділитися контекстом, надавати інструменти та функції, а також створювати гнучкі інтеграції за допомогою схеми хоста, клієнта та сервера. Сервери MCP можуть пропонувати ресурси, запити та інструменти. Протокол обмінюється повідомленнями JSON-RPC 2.0 та охоплює процеси визначення можливостей, відстеження прогресу, скасування, логування та повідомлення про помилки.
Переваги очевидні: спільний шар інструментів дозволяє додаткам на основі ШІ послідовно підключатися до джерел даних та робочих процесів, тож кожній компанії не доводиться заново створювати інтеграції. Недоліком є поява нових ризиків. Сервер інструментів, який пропонує потужні функції, має розглядатися додатком-хостом як справжня межа безпеки, а не як ще один плагін. Власна специфікація MCP наголошує на необхідності згоди користувача, конфіденційності даних, безпеці інструментів, а також на обережності під час доступу до даних та виконання коду.
Безпека на першому місці
Агенти, які використовують інструменти, є цінними, тому що вони здійснюють дії, але саме ця здатність створює ризики.
Введення команд — це найвідоміша загроза: ворожі інструкції, приховані в даних від користувача чи зовнішньому контенті, які змушують модель діяти так, як їй не слід. OWASP включає її до числа найбільших ризиків для додатків на основі ШІ, а її матеріали за 2025 рік також зазначають проблему надмірної автономії, коли система на основі ШІ має більше повноважень для дії, ніж це доцільно, через що несподіваний, неоднозначний чи маніпульований результат може призвести до шкідливих дій.
Непряме введення найбільше турбує людей, які працюють із агентами. Припустимо, агент читає електронні листи та може надсилати відповіді. Зловмисник може приховати у повідомленні рядок із вказівкою ігнорувати свої правила та пересилати контакти користувача. Користувач може ніколи не побачити цього рядка, але модель все одно його обробить. Якщо система надто довірлива та має надмірні права, повідомлення, що виглядає невинним, може призвести до реальних дій.
Команди з безпеки починають розглядати ШІ як системи, яких можна обдурити лише за допомогою формулювань, а не лише через помилки в коді. Національний центр кібербезпеки Великої Британії зазначає, що введення запиту відрізняється від SQL-ін’єкції тим, що ШІ не має чіткого розділення між інструкціями та ненадійними даними.
Ефективною відповіддю є багатошарова захист:
- Обмежуйте права інструментів наскільки це можливо.
- Тримайте інструменти для читання та інструменти для запису окремо.
- Вимагайте схвалення перед виконанням конфіденційних дій.
- Вважайте все отримане — чи то веб-сторінки, електронні листи, документи чи поля бази даних — ненадійним.
- Перевіряйте кожен аргумент інструменту та очищуйте результати перед передачею їх іншим системам.
- Використовуйте списки дозволів, фіксуйте кожен виклик інструменту та стежте за незвичайною діяльністю.
- Тестуйте з адверсарськими прикладами та створюйте способи скасування дій, коли це можливо.
Надавайте агенту лише ті повноваження, які справді потрібні для виконання робочого процесу.
Перегляд дій агента
Програмне забезпечення з агентами потребує ще більш детальних записів, ніж звичайне програмне забезпечення, оскільки один запуск може включати міркування моделі, виклики інструментів, передачу завдань, перевірки обмежень, спроби повторного виконання та кінцевий результат. Функція відстеження дозволяє розробникам простежити весь шлях від запиту до результату. Згідно з документацією щодо відстеження для SDK Agents від OpenAI, записи можуть фіксувати генерації LLM, виклики інструментів, передачу завдань, обмеження та користувацькі події, що допомагає командам виправляти помилки, візуалізувати та контролювати робочі процеси під час розробки та експлуатації.
Це має значення як для якості, так і для безпеки. Коли агент дає неправильну відповідь, необхідно знайти причину. Чи обрав він неправильний інструмент? Чи повернув інструмент застарілі дані? Чи неправильно проаналізував модель опис? Чи зламалася система захисту? Чи у користувача немає дозволів? Чи зупинився агент занадто рано? Без слідів команди лише здогадуються. За наявності хорошої можливості спостереження створення агентів стає справжньою інженерною практикою.
Як зазвичай зламуються ці системи
Помилки є передбачуваними. З боку моделі вона може обрати неправильний інструмент, коли назви чи описи є нечіткими, надіслати неповні чи неправильні аргументи, викликати інструмент тоді, коли слід поставити уточнювальне запитання, або пропустити виклик, коли потрібні свіжі дані. Вона також може викликати інструменти занадто часто, що підвищує витрати та затримки, застрягати у циклах без прогресу чи надмірно довіряти результатам інструменту.
Додаток також може зазнати невдачі. Він може приймати аргументи, надані моделлю, без перевірки, одночасно відкривати занадто багато інструментів, повертати величезні та хаотичні результати, які заплутують модель, приховувати корисні повідомлення про помилки, неправильно прив’язувати результати до запитів, які їх створили, або не мати журналів аудиту, обмежень швидкості та механізмів схвалення.
Незначні зміни у запитах рідко допомагають вирішити ці проблеми. Рішенням є кращий дизайн інструментів, чіткіші схеми, суворіші права доступу, ефективніше керування станом, більше тестування та кращий моніторинг.
Коли варто обійтися без інструментів
Виклик функцій не завжди є доцільним. Якщо для виконання завдання потрібно лише пояснення, використання інструменту додає складнощів. Якщо необхідна інформація вже міститься у запиті та не змінюється, немає потреби її отримувати. Для дій високого ризику, які неможливо безпечно перевірити чи скасувати, повна автоматизація може бути неправильним вибором. А якщо результат роботи інструменту є ненадійним, недокументованим чи небезпечним, його підключення до агента посилює проблеми.
Користувацький досвід також має свою ціну. Виклики інструментів спричиняють затримки, запити на дозволи переривають потік роботи, а складні агенти можуть здаватися непередбачуваними. Іноді звичайна форма краща за чат-інтерфейс, особливо коли користувачі знають, чого хочуть, і потребують швидкості, послідовності чи відповідності правилам.
Мета не полягає у тому, щоб усе перетворити на агентські процеси. Використовуйте інструмент лише там, де мова, контекст та дія справді взаємопов’язані.
Звички для ефективної роботи
Почніть із невеликої кількості однозначних інструментів та поступово розширюйте доступ до моделі. Вибирайте спеціалізовані функції з простими назвами. Пишіть описи моделі не лише для інженерів. Де це можливо, використовуйте суворі схеми та завжди перевіряйте вхідні дані у власному коді. Зберігайте результати короткими та передавайте моделі лише те, що їй дійсно потрібно.
Встановлюйте права доступу окремо для кожного інструменту. Співробітник підтримки, який може перевіряти статус замовлення, не обов’язково має мати право на повернення грошей. Асистент з планування може потребувати інформації про вільні часи в календарі, але не приватні нотатки про заходи. Асистент з програмування повинен мати можливість читати кодовий репозиторій задовго до того, як зможе створювати запити на зміни.
Вимагайте, щоб кожна особа підтверджувала будь-які конфіденційні, дорогі, публічні, юридично зобов’язуючі, фінансові чи складні для скасування дії, та формулюйте запити чітко, щоб переглядач точно розумів, що буде відбуватися.
Пов’язана література
- Використання інструментів у продакшені для агентів: походження даних, повторні спроби та можливості моніторингу — Агент банку здійснив зайві виклики до платної API та вигадав номер телефону. Дізнайтеся про мінімальні набори інструментів, походження параметрів, трирівневі механізми повторних спроб та показники ефективності кожного інструменту.
- Знімки пам’яті агентів, навички, процес зношування даних та обмеження дії пам’яті за гілками — Чотири доповнення до вбудованого шару пам’яті у вигляді векторної БД для створення програмних агентів: портативні знімки пам’яті з можливістю об’єднання, активація навичок, контроль конфліктів під час зношування даних та обмеження дії пам’яті за конкретними гілками.