Коли ШІ-агент звітує успіх, а стан губиться

Тиша, яка виглядає як робота: ще два приклади

У доповіді Говіндараджана OpenClaw дав кілька схожих провалів, і кожен — з іншим механізмом тиші. В одному кейсі агент мовчав 64 години — саме стільки часу знадобилося команді, щоб помітити проблему й завести баг-репорт. Причина: службовий сигнал живучості HEARTBEAT_OK система класифікувала як «очікує доставки» і продовжувала оновлювати часову позначку сесії. Наступний тик heartbeat бачив, що робота нібито вже в черзі, і теж пропускав хід. Помилка була не в моделі — вона в тому, що внутрішній технічний сигнал переплутали з роботою, яку треба показати користувачу.

Другий приклад — про запис, а не про доставку. У сховищі підтверджень (commitment store) два процеси одночасно зчитували один запис, кожен вносив свою зміну і зберігав результат за схемою «завантажив → змінив → зберіг». Жоден з них не був «неправильним» сам по собі, але без блокування другий запис затер перший. Автор формулює це різко: «останній записаний перемагає» — це не модель узгодженості, а випадковість.

Три запитання замість одного правила

Принцип із короткого допису («один власник факту, один шлях запису, окремий підтверджений доказ дії») на практиці розкладається на три перевірки, які варто ставити для кожної дії агента:

• Хто володіє станом: який саме компонент — сесія, памʼять, тікет-система, календар — є джерелом істини для цього факту, і чи можна цей факт відтворити пізніше
• Хто визначає порядок: коли дві події надходять одночасно (виправлення користувача, вебхук, завершення підзадачі), який механізм вирішує, яке з них записалося першим
• Хто може показати, що сталося: чи є окремий підтверджений запис про виконану дію, чи є лише розмова з моделлю, яка описує намір

Друге запитання не означає заборону паралельності. Читання можна розпаралелювати, підзадачі — виконувати одночасно. Заборонено інше: щоб два процеси одночасно писали в один і той самий змінний стан без узгодження порядку.

Де прийом не спрацює

Правило «доведи дію окремим записом» ламається там, де систему привчили вважати мовчання нейтральним. У одному з інцидентів OpenClaw лог зафіксував виклик зовнішнього інструменту, але відповідь так і не прийшла — процес міг впасти, мережа обірватися, таймаут спрацювати раніше за відповідь. Сесія лишилася чекати результат, якого ніколи не буде, а нові повідомлення користувача заходили в чергу позаду цього мовчання. Для агента, який працює з зовнішніми API, браузером чи командним рядком, це не рідкісний випадок — це типовий сценарій, бо будь-який зовнішній виклик може зависнути.

Так само ламається логіка підтверджень. Користувач один раз натиснув «підтверджую» для операції з підвищеними правами, але наступний виклик втратив контекст цього дозволу, і система з простроченим токеном продовжувала повторювати спробу замість того, щоб зупинитися. Дозвіл — це не спогад про клік, а структура з чіткими межами: хто діє, у межах якої сесії, з яким інструментом, з якими аргументами і як довго дозвіл чинний.

Що перевірити перед тим, як довіритись агенту

Для керівника чи власника продукту, який приймає агентну систему в роботу, а не пише її код, є практичний список питань до розробників:

• Для кожного факту, яким агент користуватиметься в наступному кроці: чи названо власника цього факту і чи є спосіб його відтворити з логів
• Для кожного спільного стану: чи є один впорядкований шлях запису, чи можуть два процеси писати одночасно без блокування
• Для кожного виклику зовнішнього інструменту: чи є ліміт часу і максимальна кількість спроб, чи може виклик чекати відповіді нескінченно
• Для кожного підтвердження з підвищеними правами: чи прив'язане воно до конкретної дії, сесії й терміну дії, чи це просто запис факту кліка

Матеріал не описує конкретне технічне рішення для кожного з цих пунктів — лише принцип, що обвʼязка навколо моделі має явно відповідати на ці питання, а не покладатися на те, що модель «зрозуміє» правильно.