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

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

Агент — это именованный субъект с персоной, набором навыков и адаптером для работы. Агенты — такие же субъекты, как и люди: они пишут сообщения, владеют тикетами, оставляют ревью и попадают в тот же список. Именно они выполняют работу.

Каждый агент принадлежит ровно одному рабочему пространству. Это жёсткий инвариант: 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`	Идентификатор родительского агента — цепочка подчинения, которую рисует оргструктура

Все эти поля вы редактируете в разделе Настройки → Рабочее пространство → Агенты. Новый агент создаёт агента без имени, который вы затем заполняете.

Навыки

Навыки — это имена на сущности агента, нечувствительные к регистру. С ними происходят две разные вещи:

Имена перечисляются в собранном промпте под заголовком «Skills». Это всё, что набор на сущности делает сам по себе: отдельной библиотеки промптов для каждого навыка, привязанной к нему, нет.
Каталог каждого названного навыка (skills/<slug>/SKILL.md в рабочем пространстве) связывается с собственным каталогом агента. На встроенном раннере frontmatter связанных навыков автоматически загружается в системный промпт, а тело агент читает по требованию; ввод /skill:<name> в разговоре загружает это тело как директиву для текущего хода.

Навыки, загружаемые извне, между получением и записью проходят проверку цепочки поставок по принципу fail-closed: без вердикта на диск или в промпт не попадает никакое содержимое навыка. Внешний источник — это репозитории GitHub, которые вы сами регистрируете как источники навыков: кураторского каталога нет, поэтому собственные метаданные репозитория (его описание, его звёзды, имя навыка) — недоверенные отображаемые данные, а вердикт проверки — единственный сигнал безопасности. Установка загружает весь каталог навыка и закрепляет его за коммитом, из которого он получен, в skills-lock.json, а последующее обновление заново проходит шлюз, прежде чем что-либо заменить. Инструкция — в разделе Устанавливать и управлять навыками.

Навыки уровня репозитория

Репозиторий может поставлять собственные навыки в любом из общепринятых мест (.agents/skills/, .claude/skills/, .opencode/skills/). Пространство выкладывает каждый подключённый репозиторий рядом с другими в repos/<name>/, но агент работает только с одним репозиторием за раз — поэтому он несёт только навыки этого репозитория, и они сменяются, когда он переходит в другой.

Какой репозиторий активен, выводится из файлов, которых касается агент: запись файла в repos/<name>/ делает этот репозиторий активным, а простое чтение по разным репозиториям — нет, поэтому погоня за символом в соседний сервис никогда не подменяет набор под выполняемой задачей. В пространстве с одним репозиторием ответ известен ещё до первого хода.

Такое ограничение области — решение из бюджета контекста. Индекс навыков находится в промпте на каждом ходу, а тела — нет, поэтому перечисление навыков всех репозиториев сразу непрерывно расходует токены, а навык testing из одного сервиса активно вводит в заблуждение, когда работа идёт в другом. По той же причине индекс агента несёт один репозиторий, а поле ввода сообщения так не ограничено: назвать навык самостоятельно — это одно явное действие, поэтому /skill:<repo>:<name> достаёт до любого репозитория в пространстве.

Навыки репозитория загружаются для каждого адаптера, а не только для встроенного раннера. Навыки активного репозитория материализуются в рабочем каталоге агента — это путь, который Claude Code и так сканирует; тот же индекс собирается в AGENTS.md, который читает встроенный раннер. Навыки репозитория проходят ту же проверку по принципу fail-closed, что и установленный навык, прежде чем происходит что-либо из этого: выложенный репозиторий — это клонированное содержимое, и его frontmatter попадает в промпт.

Разрешения

У агента нет собственных флагов разрешений. Может ли он создать коммит, отправить изменения, открыть pull request, писать во внешний трекер или выходить в сеть, решают ограничения действий — разрешить, спросить сначала или запретить, на уровне рабочего пространства, агента или пространства, — и одни и те же правила действуют независимо от того, какой адаптер его запускает.

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

Как это работает, в том числе что применяется принудительно на уровне файловой системы, а что нет, описано в разделе Песочница и безопасность.

Адаптер определяет, что можно обеспечить принудительно

Самое значимое поле агента — его адаптер, потому что транспорт адаптера определяет, какую долю политики Control Center действительно можно обеспечить принудительно.

Транспорт	Адаптеры	Что Control Center обеспечивает принудительно
Встроенный раннер	Control Center (built-in)	Всё. Набор инструментов строится исходя из режима, поэтому запрещённый инструмент невидим, а не просто отклоняется; каждый вызов проходит шлюз одобрения и ограничения действий; контракт завершения может подтолкнуть, а затем завалить запуск, который завершается без своего результата
Claude CLI	Claude Code	Инструменты `mcp__*`, которые ему передаются, а также его команды `Bash`, которые хук перед выполнением отправляет в политику действий. Собственные инструменты Claude для чтения, записи и редактирования живут в его процессе и выполняются незаметно — а запускается он с `--dangerously-skip-permissions`, потому что неинтерактивный `claude -p` иначе навсегда завис бы на собственном запросе

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

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

Песочница — это не шлюз. Она ограничивает, где процесс может читать, писать и подключаться, — режим «только чтение» действительно доходит до неё в виде bind-монтирований только для чтения, — но она не может перехватить вызов, вызвать запрос на одобрение или рассказать вам потом, что пытался сделать CLI. Это, плюс четыре возможности, названные чуть выше, — всё ещё то, что есть у встроенного раннера и чего нет у остальных. См. Песочница и безопасность.

Агент без адаптера переключается на Control Center (built-in) — цикл внутри сервера, так что устанавливать CLI не нужно, — и в его журнале запусков записывается cc-harness. Каждый агент из начального набора создаётся без адаптера и модели, поэтому все пять агентов нового рабочего пространства работают там, на модели Anthropic по умолчанию, пока вы не зададите адаптер и модель каждому агенту. Выбор «адаптер по умолчанию» при первом запуске — это настройка на стороне клиента, которую сервер никогда не читает, и она не применяется задним числом к уже созданным агентам.

Откуда берутся агенты

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

Текущее состояние

У агента нет хранимого столбца состояния. Его текущее состояние выводится из журналов последних запусков при каждом чтении:

Состояние	Значение
`neverRun`	Журнала запусков не существует
`running`	Хотя бы один запуск выполняется прямо сейчас
`failed`	Последний запуск завершился ошибкой, либо его liveness равен failed или dead
`blocked`	liveness последнего запуска равен blocked, stalled или looping
`idle`	Всё остальное — агент уже запускался, и у него ничего не выполняется

Ещё два состояния, queued и succeeded, существуют для отдельных запусков в дереве запусков разговора; список агентов их никогда не выдаёт, потому что зелёный цвет завершённого запуска — факт о запуске, а не об агенте.

Список присутствия показывает параллельную, более грубую картину, синтезируемую на сервере из событий запусков в реальном времени, — размышляет, выполняется, ждёт одобрения, готово, — именно поэтому агенты появляются рядом с людьми. См. Совместная работа и присутствие.

Связанные понятия

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