Чотири автономні ШІ-агенти тепер можуть виявляти програмні помилки, редагувати проблемний код і підтверджувати виправлення — і все це менш ніж за хвилину завдяки новому робочому процесу на основі observability, створеному для хакатону SigNoz.

Система під назвою AgentOps відстежує стрибки помилок у SigNoz, збирає відповідні логи та трасування, точно визначає файл і рядок, що спричинили проблему, редагує вихідний код у пісочниці, а потім повторно відтворює запит, щоб довести, що помилку усунено. Кожен повний цикл завершується за 30–60 секунд, і весь процес працює без жодного запиту від людини.

Чому observability важлива для ШІ-агентів

Традиційна практика SRE розглядає логи, метрики та розподілене трасування як «очі» сервісу. Коли запит завершується помилкою, інженер іде за трасуванням до проблемного компонента. Той самий принцип тепер лежить в основі AgentOps, але «сервісом», за яким спостерігають, є сам ШІ-агент.

Кожен інструмент, який викликає агент — будь то виклик мовної моделі, редагування файлової системи чи запуск тестів — створює спан (span) у трасуванні. Спан фіксує час початку, тривалість і статус успішності, тому агент може бачити, скільки часу зайняв кожен крок міркування і чи був він успішним. Зшиваючи ці спани докупи, агент будує повну картину власного процесу мислення, так само як це робила б людина під час ручного налагодження.

Ключовий зсув полягає у переході від «observability як рівня звітності» до «observability як сприйняття». AgentOps передає дані трасування назад агентам, дозволяючи їм міркувати над власними діями в режимі реального часу. Результатом є цикл, у якому ШІ не лише генерує гіпотезу, а й перевіряє її за допомогою тієї ж телеметрії, яку він використовує для виявлення проблеми.

Чотириетапний робочий процес

  1. Моніторинг – легкий watcher сканує SigNoz на наявність щойно зареєстрованих помилок.
  2. Діагностика – агент збирає відповідні логи та трасування, витягує стек і ізолює файл та номер рядка, що спричинили збій.
  3. Виправлення – використовуючи сервер файлової системи в пісочниці, агент пише патч для визначеного рядка. Пісочниця забезпечує суворі дозволи та автоматично відкочує зміни, якщо редагування порушує політику безпеки.
  4. Перевірка – агент повторно надсилає оригінальний запит до виправленого коду. Якщо трасування показує успішне виконання, виправлення фіксується; в іншому випадку агент повторює цикл.

Усі кроки оркеструються одним і тим самим набором агентів, кожен з яких діє як автономний мікросервіс. Весь ланцюжок є доступним для спостереження через спани, сумісні з OpenTelemetry, які SigNoz поглинає та візуалізує.

Важкі уроки щодо надійності

Чіткість помилок

Загальний статус «failed» ні про що не говорить. Команда додала деталізовані причини збоїв — наприклад, «неправильна гіпотеза» або «патч порушив процес», — щоб наступні агенти могли вирішити, чи варто повторити спробу, повернутися назад або перервати процес. Це відображає те, як люди в post-mortem аналізах позначають першопричини.

Затримка даних

Телеметрія з'являється не миттєво. Тепер агенти роблять невелику паузу та проводять перевірку на адекватність (sanity check), щоб переконатися, що необхідні логи надійшли, перш ніж стверджувати, що виправлення працює. Без цього захисту агент міг би діяти на основі неповних даних і отримати хибнопозитивний результат.

Межі безпеки

Надання ШІ права писати код створює ризик підвищення привілеїв. Пісочниця працює за спеціальним сервером файлової системи, який обмежує область запису цільовим репозиторієм і автоматично відновлює попередній стан, якщо тест не вдається. Така модель ізоляції стримує можливості ШІ.

Ліміти токенів

Великі мовні моделі споживають токени API, і щоденні квоти можуть бути вичерпані прямо під час розслідування. AgentOps відстежує використання токенів на кожен інцидент і обмежує подальші виклики після досягнення певного порогу, запобігаючи каскаду невдалих виправлень, коли квота закінчується.

Що продемонструвало демо

Команда впровадила абсолютно нову помилку, якої ніколи не було в кодовій базі. AgentOps виявив аномалію, простежив її до конкретного рядка, згенерував виправлення, застосував патч у пісочниці та перевірив успішність запиту — і все це без жодних ручних змін коду чи нових промптів. Час виконання від початку до кінця не перевищив хвилини, що відповідає заявленим 30–60 секундам.

Контраргумент: автономія — це не панацея

За чим стежити далі

  • Модельно-агностична телеметрія — оскільки все більше вендорів надають сумісні з OpenTelemetry спани, цей підхід може стати вендоронезалежним, що полегшить його впровадження у гетерогенних стеках.
  • Запобіжники на основі політик — впровадження конфігурованих політик, які визначають, які файли агент може редагувати або які набори тестів мають бути пройдені перед комітом, дозволить вирішити питання управління (governance).
  • Бюджетування токенів з урахуванням витрат — динамічний розподіл токенів залежно від критичності інциденту може запобігти вичерпанню квот, зберігаючи при цьому можливість обробляти критичні баги.

AgentOps показує, що цикл виправлення багів може тривати 30–60 секунд. Експеримент демонструє концепцію (proof-of-concept) того, що спостережуваність (observability) може використовуватися автономними програмними помічниками.