Стабільне ім’я агента — це не той елемент, який ви перевіряли: фіксуйте кандидата.
Ім’я агента може залишатися незмінним, поки змінюються його навички, інструменти та дозволи. Для перевірки та скасування змін необхідно окремо відстежувати ім’я, кандидата на виконання завдань та ідентичність процесу.
Два агенти можуть мати однакову назву, але відрізнятися у всьому, що має значення для оцінки. Припустимо, що „Агент досліджень“ пройшов оцінку у понеділок. До вівторка позначення залишається незмінним, проте одна з навичок була замінена, інструмент отримав права на запис, а правило маршрутизації направляє деякі запити іншим шляхом. На організаційній схемі це все ще той самий агент. Однак як доказ того, що було протестовано, така відповідь є недостатньо точною.
Позначення вказує на роль. Але воно не може вказати на конкретну комбінацію елементів, які вплинули на успішну оцінку. Розрив збільшується, коли поведінка агента виходить за межі одного виклику моделі та стає сукупністю: модель, інструкції, навички, інструменти, дозволи, політика пам’яті, маршрутизація, хуки, фреймворки та все, що додає хост-додаток.
Назви координують, кандидати носять докази
Ніхто не хоче, щоб кожна внутрішня версія ставала новою публічною особистістю з серійним номером. Людям потрібна назва, яка залишається незмінною. Команда, що складається з агента досліджень, агента залежностей та агента підтримки, отримує перевагу від позначок, які пояснюють, для чого кожен з них призначений та яке місце він займає.
Оцінка ставить інше запитання: який саме кандидат у поведінці охоплює це рішення? Уявіть оцінку, проведену для окремої моделі, набору запитів, набору навичок, меж інструментів, політики дозволів та налаштувань маршрутизації. Усе, що мало значення для вимірювання, є частиною того, що описує результат. Якщо змінити один з елементів, старий результат все ще може натякати на нового кандидата, але він більше не буде його підтвердженням.
Дружелюбна назва може саме це приховати. Ідентичність продукту залишається стабільною, тоді як його екзекутивна структура змінюється. Ідентичність для людей забезпечує континуїтет, а ідентичність для кандидатів — точність.
Конфігурація стає матеріалом, який можна переглядати
Сучасні продукти агентів вже демонструють елементи цього підходу, хоча між ними немає спільної архітектури. Деякі інструменти дозволяють визначати агентів у файлах, які об’єднують інструкції, інструменти, обмеження, обрані навички та сервери MCP, а також налаштування моделей та дозволів; крім того, визначення, специфічні для проекту, можуть зберігатися у репозиторії. Це один із варіантів проектування, а не стандарт, але він показує, що конфігурація більше не мусить бути невидимим елементом налаштування під час виклику моделі. Вона може бути об’єктом, який можна прочитати та переглянути.
Інший підхід передбачає зберігання запитів, списків інструментів, розкладів, облікових даних та налаштувань пам’яті у Git, щоб кожна зміна проходила через запит на з’єднання та залишала історію перевірок, можливість скасування змін та аудитний слід. Те, що одна організація так робить, нічого не доводить щодо того, що має робити кожна команда, але це демонструє, що поведінку агентів можна керувати як змінною конфігурацією з історією у стилі програмного забезпечення.
Простіші рішення також спрямовані в тому ж напрямку. Деякі платформи-постачальники вже пропонують повторно використовувані, версійовані конфігурації агентів, хоча ці інтерфейси ще знаходяться у бета-версії та постійно розвиваються. Плани розвитку протоколів включають ідентифікацію агентів як тему для майбутньої роботи, що є лише планом, а не готовою функціональністю. Це нічого не означає щодо вирішення проблеми. Проте ці приклади обґрунтовують скромне твердження: коли поведінка походить від окремих, незалежно змінних елементів, цілісна структура потребує власного ідентифікатора.
Версійовані компоненти все одно можуть утворювати неоднозначну цілісність
Саме тут складність стає на диво дратівливою. У моделі є версія, у навички — ревізія, у репозиторії — коміт, у сервері MCP — розгортання; політика пам’яті також може мати власну версію, а агент — ще й версію, видиму для постачальника. Кожен елемент може мати назву, проте об’єднаний результат залишається невизначеним.
Розгляньмо ситуації, коли фіксація стає частковою:
- Підказка фіксується, але псевдонім моделі змінюється.
- Модель фіксується, але навичка використовує найновішу версію.
- Навичка залишається незмінною, але додаток-хост змінює інструменти, які він надає.
- Політика дозволів змінюється, проте публічна назва залишається такою ж.
Система версіонується у фрагментах, і те, що насправді запускалося, залишається неясним. Практика випуску програмного забезпечення пропонує корисну аналогію, але з одним обмеженням: конфігурація агента не обов’язково є єдиним бінарним файлом чи одним величезним маніфестом. Аналогія стосується того, до чого застосовується рішення. Команда розробників не обмежується фразою „ми протестували продукт X“, коли існує кілька версій. Назва продукту допомагає у координації, а конкретна версія чи коміт вказують, який саме варіант охоплюється твердженням. Перевірка агента також потребує такого розділення, коли конфігурація може суттєво змінити його поведінку.
Три ідентичності краще за одну
Примус до використання єдиного ідентифікатора для передачі всіх значень швидко створює плутанину. Варто розділити принаймні три рівні.
Ідентичність, орієнтована на людину
Стабільна роль: її назва, мета, власник, обов’язки та місце в системі. Вона має залишатися достатньо стабільною, щоб люди та інші агенти могли координувати свої дії навколо неї.
Ідентичність кандидата на поведінку
Це точний набір залежностей, які формують поведінку, і які команда оцінює, схвалює, порівнює чи випускає. Залежно від архітектури він може посилатися на:
- модель, яка працює, разом із будь-якими налаштуваннями, що змінюють її поведінку,
- текст інструкцій чи набір запитів,
- навички, прив’язані до конкретних версій,
- інструменти та сервери MCP, до яких вона може отримати доступ,
- те, що вона може робити та що потребує схвалення,
- спосіб зберігання та використання пам’яті,
- правила маршрутизації та передачі завдань,
- хуки, які переривають життєвий цикл,
- версію фреймворку чи середовища виконання, якщо вона змінює поведінку.
Ключовим поняттям є матеріал. Мета не полягає у серіалізації кожного налаштування лише через його наявність. Йдеться про фіксацію залежностей, зміна яких може зробити твердження щодо перегляду, відтворення чи скасування неправдивими.
Ідентичність виконання
Навіть ідеально зафіксований кандидат не охоплює всього, що впливає на один запуск. Запуск також залежить від введених користувачем даних, змінних вмістів пам’яті, отриманого контексту, стану зовнішніх систем, актуальних даних, облікових даних, людських рішень та власної недетермінованості моделі. Те, що має значення, належить до лінійки виконання.
Розділення шарів допомагає уникнути двох протилежних помилок: сприйняття зручної назви як точної технічної ідентичності та сприйняття знімка конфігурації так, ніби він фіксує кожну деталь актуального запуску.
Що варто закріпити
Кількість елементів, які потрібно закріпити, залежить від рівня ризику. Для низькоризикових персональних помічників може вистачити запису про коміт у репозиторії чи версії постачальника. Для робочих процесів у продакшені з правами на запис потрібно більше інформації. Під час оцінки записуйте все, що стосується вимірювань: модель, запит, навички, інструменти, дозволи, маршрутизацію та стан системи.
Спочатку пропустіть схему та використовуйте наведений вище список як чек-лист. Для кожного пункту запитайте себе, чи все ще будете ви називати його перевіреним кандидатом після змін. Якщо чесна відповідь — ні, цей пункт має бути включений до ідентичності кандидата чи його історії змін.
Чутливі значення не обов’язково копіювати до запису. Конфігурація може посилатися на секретну референцію, клас облікових даних чи межу дозволів, не перетворюючи маніфест на нове місце витоку секретів. Точна ідентифікація має покращити можливості аудиту та не створювати гірших проблем з безпекою.
Оцінка, виправлення помилок та скасування змін мають спільну потребу
Це здається трьома окремими операційними проблемами, але кожна з них потребує об’єкта, який можна відновити.
Оцінка. Будь-який бал є твердженням щодо певного об’єкта. Коли цей об’єкт неможливо достатньо точно відтворити, бал може існувати довше, ніж те, що він описував. Не кожна зміна скасовує кожну оцінку: виправлення опечатки у нерелевантній навичці ледве впливає на критерії міркування, тоді як зміна прав доступу може не впливати на якість прози, але вирішувати питання безпеки. Важливим є те, що саме вимірювалося, і це має бути зроблено відкрито, щоб постійна назва не могла приховати суттєві зміни.
Відлов помилок. Без ідентифікатора конфігурації розслідування інциденту перетворюється на пошук серед багатьох шарів інформації. Файл запитів, історія консолі, реєстр інструментів, журнал розгортання, знімок пам’яті, гілка та запис виконання можуть кожен окремо відображати інформацію про свій шар, при цьому загалька залишається незрозумілою. Точна посилання на кандидата спрощує початкове запитання: чи справді під час цієї несправності використовувався той кандидат, про якого всі припускали? Якщо так, потрібно перевірити стан та поведінку виконання. Якщо ні, сама ця неузгодженість є результатом розслідування. Несподіванка від прийнятого кандидата та ситуація, коли виконання взагалі не використовувало його, належать до різних категорій несправностей.
Відкат. Уявімо, що схвалений кандидат поєднував у собі один запит, один набір навичок, одну політику дозволів, одне правило маршрутизації та один середовище виконання. Просте повернення лише запиту не означає, що старий кандидат знову активний. Команди повинні вирішити, чи можуть вони повністю відновити попереднього схваленого кандидата чи лише скасувати ту частину, яка привернула їхню увагу. Перший варіант — це справжній відкат, а другий — спроба виправлення за допомогою змін.
Є ще один аспект, який легко проігнорувати. Знаходження „останнього схваленого кандидата“ є процесом пошуку, і він працює лише тоді, коли кандидати мають запис про свою послідовність. Точна ідентичність вказує, ким був кожен кандидат, але не те, хто замінив кого чи що змінилося між ними. Якщо відкат має значення, кожен кандидат повинен вказати свого попередника та перелічити суттєві відмінності, щоб відновлення ніколи не перетворювалося на складну пошукову операцію.
Не дозволяйте конфігурації поглинути процес виконання
Спокуслива надмірна реакція — це гігантський знімок, який містить усе. Це приносить нові проблеми. Змінна пам’ять, завантажені документи, дані від користувача, стан зовнішніх API, час та облікові дані — усе це впливає на процес виконання. Деякі з цих елементів є конфіденційними, деякі мають бути динамічними, а деякі не можна точно відтворити, тому не всі вони потрапляють до кандидата.
Чіткіші межі виглядають так:
- Шар конфігурації фіксує, які залежності, що впливають на поведінку, були обрані.
- Шар виконання фіксує, яке виконання використовувало цього кандидата, а також усі важливі змінні вхідні дані.
- Шар схвалення фіксує саме того кандидата, до якого було застосовано схвалення.
Шари можуть вказувати один на одного, не зливаючись у єдиний об’єкт. Ця межа також запобігає тому, щоб „точна ідентичність“ перетворилася на твердження, яке докази не можуть підтримати. Визначення кандидата не робить модель детерміністичною, не заморожує її поза системами та не гарантує ідентичного результату в майбутньому. Воно лише робить об’єкт твердження відновлюваним, а це вже дуже допомагає.
Тест з п’ятьма запитаннями
Коли ім’яваний агент має достатню важливість для перегляду чи оприлюднення, поставте такі запитання:
- Що може змінитися без зміни імені? У більшості систем — більше, ніж очікують люди.
- Які з цих змін можуть зробити це конкретне твердження про перегляд недійсним? Це залежить від того, чи стосується рішення якості, безпеки, дозволів, надійності, вартості чи готовності.
Усе це не вимагає формальностей при кожній зміні. Потрібна точність, коли твердження починає мати наслідки. Оскільки поведінка агента формується над та навколо моделі, а ця структура стає модульною, портативною, версіонованою чи замінною, конфігурація більше не є випадковим налаштуванням. Вона є частиною виконуваного кандидата. Назва може залишатися незмінною, але докази мають відображати, що саме змінилося.
Пов’язана література
- Чому показники точності агентів вводять в оману: pass^k, зміни вхідних даних та введення помилок — Чому метод pass@1 приховує ненадійних ШІ-агентів, та як pass^k, набори змін вхідних даних та введення помилок виявляють проблеми з послідовністю, стабільністю та стійкістю до несправностей.
- Чому агенти, які вражають у демо-версіях, зазнають невдач у реальних умовах, та що слід створювати замість них — Місця можливих збоїв, компроміс між одиночним та багатоагентним підходом, практики проектування, такі як повторні спроби та альтернативні рішення, а також повна картина витрат на експлуатацію ШІ-агента, окрім плати за токени.