Діагностувати агента

Цей посібник показує, як з’ясувати, чому агент не створює запусків.

Рухайтеся згори вниз: спершу власні запуски агента, потім його бекенд, далі сервер, а тоді хост.

1. Перевірте історію запусків агента

Налаштування → Робочий простір → Агенти → виберіть агента → Журнали.

Кожен запуск показує бейдж статусу, тривалість («Running…», поки виконується), час початку й завершення, PID і використаний адаптер. Перегляд відкриває необроблений потік подій цього запуску. Зупинити примусово завершує процес, що виконується, і позначає запуск як «Killed by user»; Завершити запущені в заголовку робить те саме для всіх активних запусків цього агента.

Читайте це так:

Запусків немає взагалі — диспетчеризація не відбулася. Згадки в композері — це @ плюс символи слова (літери, цифри, підкреслення). Зіставлення відбувається за точним збігом або за префіксом імені агента, тож @code-reviewer розбирається як code і все одно може розбудити агента з іменем code-reviewer. Ім’я з пробілом не можна згадати як один токен. Далі переходьте до кроку 2.
Запуск, який одразу завершився помилкою — відкрийте Перегляд. Збій запуску бекенда видно тут як помилку процесу.
Запуск, що застряг на «Running…» — зупиніть його, а потім перевірте Тайм-аут тиші агента на вкладці «Налаштування». Якщо тайм-аут не задано, використовується значення, типове для режиму.
Завершений запуск без корисного результату — у журналі запуску статус залишається completed для запуску, який завершився без оголошеного результату; чесний сигнал — це текст підсумку, а не бейдж.

Вкладка «Журнали» не показує вартість. Щоб побачити витрати, скористайтеся таблицею за агентами в Спостережуваність → Інсайти.

2. Перевірте бекенд агента

Налаштування → Сервер → Постачальники моделей (/settings/server/providers).

Список Виявлені раннери показує кожен адаптер із результатом зондування — встановлену версію, «Перевірка…» або «Не знайдено» — а також визначений шлях і чипи можливостей для знайденого CLI. Натисніть Оновити в заголовку сторінки, щоб зондувати знову.

Зондування виконується на машині, де працює cc_server, а не на машині, яку ви бачите перед собою. Якщо ви користуєтеся вебклієнтом або прив’язаним пристроєм, «Не знайдено» означає, що CLI відсутній на хості сервера.

Потрібно переконатися у двох речах:

У агента взагалі задано адаптер. Агент із порожнім адаптером спрямовується до Control Center (built-in), і журнал запуску фіксує cc-harness, тож транскрипт називає те, що виконувалося. Якщо й моделі немає, він запитує в Anthropic типову — що завершується помилкою No credential for provider "anthropic", доки ви не підключите обліковий запис Anthropic. Початкові спеціалісти постачаються без адаптера.
У вбудованого адаптера є модель. Його список моделей надходить наживо від провайдерів, підключених нижче на цій самій сторінці, тож провайдер без збережених облікових даних не додає жодної моделі.

Сам каталог адаптерів фіксований — зареєструвати новий адаптер неможливо. Що ви можете змінити для кожного адаптера тут — це його аргументи запуску та змінні середовища. Зауважте, що перевизначення змінних середовища для адаптера непомітно переважає підключений обліковий запис провайдера під час визначення облікових даних.

3. Перевірте сервер

Налаштування → Сервер → Підключення та стан (/settings/server/connection) показує, з яким сервером спілкується цей клієнт і що той повідомляє.

Для headless-сервера GET /healthz дає ту саму інформацію без клієнта. Він неавтентифікований і відкритий для CORS за задумом:

curl http://localhost:9030/healthz

Він повертає статус сервера, час роботи в секундах, кількість активних підключень, порт прив’язки, версію збірки та git SHA, версію схеми робочого простору, версію каталогу RPC, ідентифікатор, ім’я та відбиток ідентичності сервера, чи є прив’язка незахищеною, а також блок codeGraph із кількістю watching / indexing / pending. Коли кеш уже бачив трафік, він також містить блок caches; демосервер додає demo: true.

Дві речі, які варто знати, коли зміна «працює в тестах, але не в застосунку»:

Десктопний застосунок запускає попередньо зібраний двійковий файл cc_server, а не з вихідного коду. Нова операція RPC або інструмент MCP не з’явиться, доки двійковий файл не буде перезібрано, і журнал завантаження попереджає, коли git SHA дочірнього процесу відрізняється від SHA застосунку.
Десктопний застосунок примусово зупиняє породжений сервер, який не надрукував банер готовності протягом 20 секунд, і переходить на екран помилки.

4. Перевірте хост

Налаштування → Сервер → Діагностика та приватність (/settings/server/diagnostics) — це сторінка рівня хоста. Вона містить:

Пісочниця — головний перемикач, виявлений бекенд і підказку щодо встановлення. Лише виявлений бекенд надходить від сервера; див. застереження нижче. Керування скиданням немає.
Семантичний пошук — життєвий цикл моделі вбудовування на пристрої: встановлено, завантажується з відсотком, не встановлено або помилка встановлення. Доки її не встановлено, пошук у пам’яті та коді працює лише за ключовими словами.
Поведінка системи — не давати комп’ютеру засинати, поки працюють агенти.
Рівень журналу — підвищте його перед відтворенням збою.
Приватність — чи можна надсилати необроблений вміст diff моделі агента і чи надсилаються звіти про збої.

Виявлення та застосування тепер узгоджені: там, де виявляч повідомляє про нативний бекенд, запуски агентів на цьому хості справді загортаються в нього. Але виявляч — єдине живе в цьому розділі. Головний перемикач і вибір бекенда — це налаштування, збережені на вашому пристрої, і сервер не читає жодного з них — власний перемикач сервера — це --sandbox (on типово, off щоб відмовитися).

Тож на попередження тут варто реагувати, але зазвичай воно не є причиною збою агента. Щоб підтвердити, у якому стані перебуває сервер, прочитайте його журнал запуску: він друкує agent sandbox ON із приміткою про бекенд, no OS-native agent sandbox on this host із підказкою щодо встановлення або agent sandbox DISABLED by --sandbox off. GET /healthz не містить поля про пісочницю.

Там, де бекенда немає — завжди у Windows, у Linux або WSL2 без bwrap і socat — запуски не ізольовані пісочницею, і їх обмежують власний checkout розмови, токен хостингу коду лише для читання та шлюз push, обмеження дій, санітизація середовища та поверхня інструментів, яку дозволяє його режим.

Поширені збої

Запуск не починається, а адаптер показує «Не знайдено»

Встановіть CLI на хості сервера, потім натисніть Оновити на сторінці «Постачальники моделей». Або перемкніть агента на вбудований адаптер, який не потребує CLI, і підключіть провайдера на тій самій сторінці.

Агент не може надіслати зміни чи відкрити pull request

Подивіться, що вивели git або агент. Control Center policy: … означає, що правило дії це відхилило або запит на схвалення лишився без відповіді: перевірте Надіслати на віддалений репозиторій і Відкрити pull request у Налаштування → Робочий простір → Дозволи агента. Якщо git повідомляє, що в Control Center немає облікових даних GitHub, здатних зробити push, установіть GitHub App у цей репозиторій або підключіть GitHub.

Семантичний пошук не дає нічого корисного

Перевірте Налаштування → Сервер → Діагностика та приватність → Семантичний пошук. Доки модель вбудовування не встановлено, пошук працює лише за ключовими словами. Рядки, записані до встановлення моделі, ніколи не доповнюються, тож залишаються доступними лише за ключовими словами й після цього.

Сервер взагалі не завантажується

Потрібні нативні бібліотеки, і полегшеного режиму немає. Відсутня бібліотека dylib змушує cc_server відмовитися від запуску й називає винуватця в помилці. Підготуйте нативні бібліотеки за допомогою scripts/natives/build_natives.sh і перезіберіть двійковий файл сервера.

Дію беззвучно відхилено

Рішення обмеження prompt, коли не підключено жодного затверджувача, відхиляється за задумом. Перевірте правила робочого простору в розділі Налаштування → Робочий простір → Дозволи агента.