Какие агенты есть
Агент в Jarvis — это модель с узкой задачей: своя инструкция, свой набор инструментов, своя форма ответа и свои лимиты. Агент не выбирает, что делать дальше. Он отвечает документом с исходом («готово», «нужен ещё один круг исследования», «код надо исправить»), а куда идти, решает сценарий.
Роли и модели
Агенты не знают, какая модель за ними стоит. Каждый просит роль, а какие модели её выполняют, решает ваша настройка:
| Роль | Кто её использует |
|---|---|
| research | исследование, требования, спецификация, анализ влияния, план, деление на сервисы, заметки к релизу, описание модуля, ответы из базы знаний |
| implementation | реализация, тесты, документация, телеметрия |
| review | ревью и разбор замечаний человека |
| compaction | сжатие длинной истории любого агента; без неё это делает модель самого агента |
Так можно, например, отдать код модели, которая лучше пишет код, а исследование и ревью — модели с большим окном.
Агенты задачи
Исследователь (research). Выясняет, о чём задача и что в репозитории к ней относится, прежде чем кто-то начнёт проектировать. Читает источники задачи и код, ищет, где похожее поведение уже есть. Отделяет проверенное по файлам от предположений, записывает неизвестное, а не придумывает его. Отдельно собирает противоречия в требованиях и то, что задача ждёт от других систем. Только читает.
Аналитик требований (requirements). Отвечает на вопрос «требования согласованы, полны и проверяемы?». Нумерует требования, ищет неясности, пропущенные состояния, гонки, частичные отказы. Каждое противоречие из исследования должен закрыть источником или признать блокирующим. Если без человека нельзя, задаёт один вопрос. Только читает.
Автор спецификации (specification). Превращает исследование и требования в документ, который можно проверить: у каждого требования критерии приёмки, явно названо, что не входит в задачу. Вопросы человеку формулирует так, как человек видит продукт: экран по названию, поле по подписи, без внутренних идентификаторов. Только читает.
Анализ влияния (impact). Находит всё, что затронет изменение: код, тесты, документацию, телеметрию, настройки — и что от этого зависит. Опирается на граф кода. Если спецификация говорит о частях, которые исследование не покрыло, возвращает задачу на исследование. Простые случаи считаются без модели.
Планировщик (plan). Раскладывает реализацию на маленькие шаги: какие файлы меняет каждый и как его проверить. Каждое требование покрыто хотя бы одним шагом. Если спецификацию нельзя реализовать как написано, возвращает её.
Реализация (implementation). Пишет код по плану, пункт за пунктом: прочитал файлы пункта, поправил, проверил, отметил. Добавляет тесты, которых требуют критерии приёмки. Не рефакторит сверх плана и записывает каждое отклонение. Может писать файлы и запускать команды проекта, но не может действовать во внешних системах.
Тесты (test). Проверяет реализацию по критериям приёмки. Команды проекта к этому моменту уже прошли, поэтому он не запускает их снова, а дописывает тесты к непокрытым критериям. Пишет только файлы тестов. Дефект в коде не чинит, а описывает, и его получает реализация.
Документация (docs). Приводит документацию репозитория в соответствие с изменением: README, docs, changelog, документацию API — в их стиле. Код не трогает.
Телеметрия (telemetry). Проверяет, что поведение из спецификации видно в продакшене: события и метрики есть или добавлены по схеме проекта. Следит, чтобы в данных событий не было лишних персональных данных.
Ревью (review). Читает дифф и сверяет каждое требование с кодом и результатами тестов. Ищет ошибки, пропущенные случаи, нарушения соглашений, лишнее. Проверяет стандарты, которые нельзя проверить кодом. Может вернуть в реализацию, в план или, если нашёл дыру в бизнес-правилах, в требования. Повторяющиеся замечания предлагает записать как правило. Только читает.
Разбор замечаний (review-analysis). Разбирает комментарии REVIEW:, которые человек оставил в коде. Решает про каждый: исправить код, поправить спецификацию, вернуть к требованиям, задать вопрос, записать в знания или просто принять к сведению.
Заметки к релизу (release-notes). Пишет, что изменилось, так, чтобы продакт мог вставить это в релиз, а разработчик мог доверять. Подстраивается под тон существующего changelog, ломающие изменения выносит отдельно.
Агенты знаний и сервисов
Описание модуля (onboard-mapper). Читает один модуль и записывает, что нужно знать новичку или агенту, который будет его менять: назначение, публичный API, правила, словарь. Каждое утверждение — с дословной цитатой из файла. Цитаты сверяются с файлами кодом, неподтверждённое отбрасывается, и до базы знаний доходит только то, что вы примете.
Справочная (knowledge-answerer). Отвечает на jarvis ask только из базы знаний, без доступа к коду. Каждая часть ответа — со ссылкой и цитатой, которые проверяются. Если база не отвечает, так и говорит.
Деление на сервисы (split). В задаче на несколько сервисов делит утверждённую спецификацию на подзадачи и описывает контракт между ними: какой эндпоинт, топик или поле меняется, кто отдаёт, кто потребляет. Предпочитает обратно совместимые изменения, чтобы отдающий сервис можно было выкатить первым.
Кто что может
| Агент | Читать код и знания | Писать в рабочую копию | Команды проекта | Тикеты, вики, макеты |
|---|---|---|---|---|
| Исследователь, аналитик требований | да | — | — | читать |
| Спецификация, план | только код | — | — | — |
| Анализ влияния, ревью, разбор замечаний, заметки к релизу | да | — | — | — |
| Деление на сервисы | да | — | — | — |
| Реализация | да | да | все | макеты |
| Тесты | да | только тесты | только тесты | — |
| Документация, телеметрия | да | да | — | — |
| Описание модуля | да | — | — | — |
| Справочная | только знания | — | — | — |
Ни один агент не может написать комментарий в тикет, сменить статус или открыть pull request. Это делают отдельные шаги без модели, через журнал действий.
Лимиты
У каждого агента есть лимит вызовов инструментов и модели на шаг. По умолчанию 40 и 60; у реализации больше (80 и 100), у спецификации и плана меньше инструментов (20 и 15). Лимиты меняются в настройках проекта для отдельного агента, а в безлимитные часы квоты растут сами.
Когда лимит кончился, агент заканчивает с тем, что есть, и его документ помечается неполным. Следующий агент видит эту пометку. Для спецификации и реализации, где полусделанный результат дороже вопроса, Jarvis вместо этого спрашивает вас: добавить вызовов или закончить.
Как инструкция, знания и состояние задачи складываются в промпт агента, — на следующей странице.