Модель агента

Що таке агент?

Агент — це іменований діяч із персоною, набором навичок і адаптером для запуску. Агенти є принципалами так само, як і люди: вони пишуть повідомлення, володіють тікетами, залишають рецензії та з’являються в тому самому реєстрі. Саме вони виконують роботу.

Кожен агент належить рівно до одного робочого простору. Це жорсткий інваріант — agent.workspaceId не може бути null, саме власний робочий простір агента визначає файл бази даних, у який потрапляють його рядки, а створення агента без робочого простору відхиляється.

Агент — це також каталог. Його визначення лежить у agents/<slug>/AGENTS.md у каталозі даних робочого простору, а навички, які він має, символічно пов’язані в agents/<slug>/.agents/skills. Рядок у базі даних і файл записуються разом. Початкове наповнення ідемпотентне: якщо рядок агента вже існує, файли на диску та посилання на навички все одно перезаписуються. Продакшн-виклик — це створення робочого простору, а не кожен запуск сервера.

Що містить агент

Атрибут	Що він робить
`name`	Короткий ідентифікатор у стилі slug (`architect`, `qa`). Також те, на що розв’язуються `@mentions`
`title`	Зрозуміла людині назва посади
`persona`	Довільний текст із рисами характеру та вказівками щодо поведінки; вставляється як розділ промпту
`systemPrompt`	Необов’язкові додаткові вказівки; вставляються як розділ “Agent instructions” — решти зібраного промпту вони не замінюють
`skills`	Набір назв навичок без урахування регістру, віддзеркалений на диску як посилання на навички
`adapterId`	До якого раннера агент надсилає запуски. Null повертає до вбудованого циклу
`modelId`	Яка модель у межах цього адаптера
`effort`	Рівень міркування, узятий із власного словника вибраної моделі
`contextSize`	Перевизначення контекстного вікна
`silenceTimeoutMinutes`	Перевизначення (1–240) для вартового тиші на рівні агента
`reportsTo`	ID батьківського агента — ланцюг підпорядкування, який малює організаційна схема

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

Навички

Навички — це назви на сутності агента, що не враховують регістр. Із ними відбуваються дві окремі речі:

Назви перелічуються у зібраному промпті в розділі “Skills”. Це все, що набір сутності робить сам собою — жодної бібліотеки промптів для окремих навичок, прив’язаної до нього, не існує.
Каталог кожної названої навички (skills/<slug>/SKILL.md у робочому просторі) пов’язується з власною текою агента. У вбудованому harness frontmatter пов’язаних навичок автоматично завантажується в системний промпт, а агент читає тіло на вимогу; введення /skill:<name> у розмові завантажує це тіло як директиву на цей хід.

Навички, отримані ззовні, між завантаженням і записом проходять сканування ланцюга постачання, що відмовляє за замовчуванням — жоден вміст навички не потрапляє на диск чи в промпт без вердикту. Ззовні — це репозиторії GitHub, які ви самі реєструєте як джерела навичок: курованого сховища немає, тож власні метадані репозиторію (його опис, його зірки, назва навички) є недовіреними даними для показу, і вердикт сканування — єдиний сигнал безпеки. Встановлення завантажує весь каталог навички, фіксує його на коміті, з якого він походить, у skills-lock.json, а пізніше оновлення знову проходить шлюз, перш ніж щось замінити. Інструкція — у встановленні та керуванні навичками.

Навички в межах репозиторію

Репозиторій може постачати власні навички в будь-якому зі звичних місць (.agents/skills/, .claude/skills/, .opencode/skills/). Простір вивантажує кожен пов’язаний репозиторій поряд у repos/<name>/, але агент працює в одному репозиторії за раз — тож він несе навички лише цього репозиторію, і вони змінюються, коли він переходить до іншого.

Який репозиторій активний, визначають із файлів, яких торкається агент: запис файлу в repos/<name>/ робить цей репозиторій активним, а саме лише читання з різних репозиторіїв — ні, тож пошук символу в сусідньому сервісі ніколи не підмінює набір посеред завдання. У просторі з одним репозиторієм відповідь відома ще до першого ходу.

Обмеження області — це рішення про бюджет контексту. Індекс навичок сидить у промпті на кожному ході, а тіла — ні, тож перелічення навичок усіх репозиторіїв одразу безперервно з’їдає токени — а навичка testing з одного сервісу активно вводить в оману, коли робота точиться в іншому. Із тієї самої причини індекс агента несе один репозиторій, а поле введення так не обмежене: назвати навичку самому — це одна явна дія, тож /skill:<repo>:<name> дістає будь-який репозиторій у просторі.

Навички репозиторію завантажуються для кожного адаптера, а не лише для вбудованого harness. Навички активного репозиторію матеріалізуються в робочий каталог агента — той самий шлях, який Claude Code і так сканує; той самий індекс складається в AGENTS.md, який читає вбудований harness. Навички репозиторію проходять те саме сканування з відмовою за замовчуванням, що й встановлена навичка, перш ніж усе це станеться — вивантажений репозиторій є клонованим вмістом, а його frontmatter потрапляє в промпт.

Дозволи

Агент не має власних прапорців дозволів. Чи може він створити коміт, зробити push, відкрити pull request, писати в зовнішній трекер або виходити в мережу, вирішують обмеження дій — дозволити, спочатку запитати або заборонити, на рівні робочого простору, агента чи простору, — і ті самі правила діють незалежно від того, який адаптер його запускає.

Те, що запуск отримує, від цих правил не змінюється. Запуск у worktree GitHub завжди отримує токен GitHub лише для читання, а про push запитують у момент, коли він відбувається: конфігурація git агента надсилає кожен push у GitHub через Control Center, який застосовує правило Надіслати на віддалений репозиторій, перш ніж передати його далі.

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

Адаптер вирішує, що можна забезпечити примусово

Найважливіше поле агента — його адаптер, бо транспорт адаптера визначає, яку частину політики Control Center справді можна забезпечити примусово.

Транспорт	Адаптери	Що забезпечує Control Center
Вбудований harness	Control Center (вбудований)	Усе. Поверхня інструментів будується з режиму, тож заборонений інструмент невидимий, а не просто відхилений; кожен виклик проходить шлюз схвалення та обмеження дій; контракт завершення може підштовхнути, а потім завалити запуск, який завершується без свого результату
Claude CLI	Claude Code	Інструменти `mcp__*`, які йому надано, а також його команди `Bash`, які хук перед виконанням надсилає до політики дій. Власні інструменти Claude для читання, запису та редагування живуть у його процесі й виконуються невидимо — а запускається він із `--dangerously-skip-permissions`, бо неінтерактивний `claude -p` інакше заблокувався б назавжди на власному запиті

Конкретно: лише вбудований harness підтримує субагентів, коригування під час запуску, паузу й відновлення (а отже, і перехоплення) та структурне забезпечення режиму. Claude Code не має нічого з цього.

Наведена вище матриця — про те, що Control Center може бачити й пропускати через шлюз. Під нею cc_server загортає CLI Claude Code у пісочницю ОС хоста там, де вона існує — Seatbelt на macOS, bubblewrap на Linux і WSL2 — тож невидимий rm чи невидимий запис усе одно обмежує ОС. На Windows бекенду немає взагалі, а на Linux чи WSL2 без bwrap і socat перевірка не знаходить жодного, тож там такі запуски повертаються до санітизації середовища, облікових даних через брокер, обмежень на виклики, які Control Center бачить, і власного робочого дерева розмови (copy-on-write там, де постачається rift; git worktree на Windows).

Чим пісочниця не є, то це шлюзом. Вона окреслює, де процес може читати, писати й з’єднуватися — режим лише для читання справді її досягає, як bind-монтування лише для читання — але вона не може перехопити виклик, підняти запит на схвалення чи розповісти вам потім, що намагався зробити CLI. Це разом із чотирма можливостями, названими вище, — усе ще те, що має вбудований harness і не мають інші. Дивіться Пісочницю та безпеку.

Агент без адаптера повертається до Control Center (вбудований) — циклу всередині сервера, тож немає жодного CLI для встановлення — і його журнал запусків записує cc-harness. Кожен початково створений агент створюється без адаптера й моделі, тож п’ять агентів нового робочого простору всі працюють там, на типовій моделі Anthropic, доки ви не задасте адаптер і модель для кожного агента. Вибір “типовий адаптер” під час початкового налаштування — це клієнтська перевага, яку сервер ніколи не читає, і вона не застосовується заднім числом до вже створених агентів.

Звідки беруться агенти

Створюються разом із робочим простором. Кожен робочий простір — не лише перший — отримує CEO і чотирьох фахівців (qa, architect, engineer, librarian), підпорядкованих йому, яких ідемпотентно створюють у фоновому режимі під час створення робочого простору. Дивіться Робочі простори та ізоляцію.
Додаються вручну в Налаштування → Робочий простір → Агенти. Прохання до агента найняти колегу не створює рядка; скористайтеся цим екраном.

Поточний стан

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

Стан	Значення
`neverRun`	Журналу запусків не існує
`running`	Принаймні один запуск триває зараз
`failed`	Останній запуск завершився помилкою, або його живучість — failed чи dead
`blocked`	Живучість останнього запуску — blocked, stalled або looping
`idle`	Усе інше — агент уже запускався і нічого не виконує

Ще два стани, queued і succeeded, існують для окремих запусків у дереві запусків розмови; реєстр їх ніколи не видає, бо зелений завершений запуск — це факт про запуск, а не про агента.

Список присутності показує паралельну, грубішу картину, синтезовану на сервері з живих подій запусків — думає, виконується, заблоковано на схваленні, готово — і саме завдяки цьому агенти з’являються поряд із людьми. Дивіться Спільну роботу та присутність.

Пов’язані поняття

Життєвий цикл запуску агента: що відбувається, коли агента фактично запускають
Режими: налаштування на рівні розмови, яке формує поверхню інструментів агента
Спільна робота та присутність: агенти як принципали, присутність і регулятор автономності
Пісочниця та безпека: що обмежує запуск сьогодні
Конфігурація агента: повний перелік полів