30 сентября в 06:32 в очереди появилась задача: научить ядро платформы переводить открытые задачи на новую версию их типа. Повод был будничный — мы выпустили новую версию типа «задача на код» с более строгими проверками перед сдачей, а вся открытая очередь осталась на старой и получала старые инструкции.
Через 19 минут агент сдал работу: новый маршрут API, тесты, документация. В 07:15 ревью её отклонило. Новый маршрут позволял агенту с обычными правами исполнителя перевести свою задачу на первую версию типа — ту, где ревью ещё не было, — взять её и закрыть самому. Ревьюер воспроизвёл это по шагам и написал, какое право должно закрывать маршрут. В 08:03 агент взял задачу снова, через 15 минут сдал исправление, в 08:24 ревью прошло и ветка влилась. От постановки до вливания — 1 час 52 минуты, два прогона агента.
Агент написал дыру, через которую агент мог бы уйти от ревью, и поймало её ревью, которое платформа считает частью самой задачи. 4 октября мы выпустили первый открытый релиз платформы — Taimen v0.2.0, Apache-2.0. Ниже — как она устроена и что мы поняли, пока почти два месяца разрабатывали её её же собственными средствами. В конце — как этот релиз выпустила сама очередь.
В центре — работа, а не агент
Taimen — среда исполнения работы организации. Мы пробовали начинать с агента — с его промпта, инструментов, памяти, — и каждый раз упирались в одно: агенты меняются быстрее, чем работа. Выходит новая модель, меняется харнесс, вместо одного исполнителя появляются три по репозиториям. А обязательство «сделать перевод задач на новую версию типа» остаётся тем же.
Поэтому главная сущность у нас — работа (Work): единица обязательства, которая существует независимо от того, кто её исполняет. У любой единицы работы через API можно узнать:
откуда она взялась — человек, правило по наблюдению, процесс, родительская задача;
кто её делал и с какими правами — каждый прогон, каждый вызов инструмента, версия агента;
как принят результат — какие проверки, кто решил;
чем результат доказан — артефакты, попытки проверки.
Исполнитель — человек, ИИ-агент или детерминированный скилл — берёт работу одинаково: взять, выполнить, сдать артефакты, пройти приёмку. Код в нашей собственной разработке писали десять агентов-исполнителей: несколько поколений раннеров и отдельные исполнители под отдельные репозитории, на Claude Code с моделями Opus и Sonnet и на Codex. Задачи этого не заметили — как не заметили и девять случаев, когда задачу начинал агент, а заканчивал человек в своём рабочем окружении.
Масштаб
С 12 августа по 4 октября на одной установке:
Что | Число |
|---|---|
Единиц работы | 1 416 |
Выполнено | 1 190 |
Заведено правилами по наблюдениям, а не людьми | 502 |
Задач на код | 788, из них выполнено 681 |
Прогонов агентов | 2 406 |
Две оговорки, без которых эти цифры нечестны. Первая: задачи на код делили агенты-раннеры (393) и харнесс владельца (324) — это тоже Claude Code, но под учёткой человека, и по данным их не различить. Вторая: с 29 сентября ревью готовит отдельная сессия Claude владельца, а решение записывается за владельцем, который за него отвечает. Ревьюер в истории выше — именно такая сессия.
Работа возникает сама
Треть работы никто не ставил руками. Коннектор наблюдает репозитории и пишет в платформу наблюдения: «в компоненте такой-то коммит». Правило решает, порождает ли наблюдение работу. Вот правило, которое следит, чтобы суперпроект не отставал от своих компонентов:
kind: WorkRule key: submodule-lag spec: identity: {agent: selfdev-rules} trigger: {kind: observation, type: repo.commit_observed} condition: in: [{var: payload.data.repo}, [control-plane, memory-service, iam-service, notification-service]] interpretation: skill: submodule.lag_check@2 inputs: repository: ${SELFDEV_SUPERPROJECT_URL} ref: main submodules: ["{{payload.data.repo}}"] action: kind: request_decision taskType: submodule-bump forEach: skill.output.lagging dedupKeyTemplate: "submodule-lag:{{item.name}}" fields: title: "Сдвинуть указатель сабмодуля {{item.name}} на {{item.head}}" approver: ${SELFDEV_REVIEWER_PRINCIPAL}
Коммит в одном из компонентов наблюдён → скилл сравнил указатель с головой ветки → ревьюеру пришло решение «сдвинуть». Approve — и другой скилл сам делает коммит в суперпроект. Если указатель догонят иначе, парное правило закроет задачу. Таких решений за период — 77. Правило действует от собственной личности, поэтому в журнале видно, что задачу завёл не человек, а правило, — со ссылкой на наблюдение, которое его запустило.
Как устроены правила вывода работы, — в руководстве: правила вывода работы и правила в пакете.
Сделано — значит принято
Самое важное решение, которое мы приняли за эти недели: задача на код закрыта не когда агент сказал «готово», а когда ветка влита. Приёмку объявляет тип задачи:
kind: TaskType key: coding-task spec: acceptance: - key: review kind: human spec: {approver: ${SELFDEV_REVIEWER_PRINCIPAL}} when: ["$.task.artifact[commit].metadata.published"] - key: merge kind: deterministic spec: skill: git.merge@1 inputs: repository: "$.task.artifact[commit].metadata.repository!" branch: "$.task.artifact[commit].metadata.branch!" commit: "$.task.artifact[commit].metadata.commit!" target: "$.task.artifact[commit].metadata.targetBranch!" expect: {merged: true} when: ["$.task.artifact[commit].metadata.published"]
Провал любой проверки возвращает задачу тому же исполнителю с причиной. Ядро при этом не знает, что такое merge: вливание — скилл пакета, и вызывается он полномочиями того, кто одобрил ревью.
С 26 сентября, когда приёмка стала частью типа, через неё прошли 458 задач на код:
Что | Число |
|---|---|
Принято с первой сдачи | 326 (71%) |
Понадобилось две сдачи | 100 |
Три и больше | 32 |
Отказов ревью | 162 |
Провалов вливания | 14 |
Из четырнадцати провалов вливания восемь — честные конфликты или ушедшая вперёд ветка, четыре — инфраструктура (токен не видел репозиторий, push отклонён), два — агент сдал коммит без метаданных, и вливать было нечего.
Задача агента с этой приёмкой проходит путь от постановки до вливания в медиане за 3,4 часа, 90% — быстрее 27 часов: сюда входит ожидание в очереди ревью. Прогон агента в медиане длится 11 минут. Условная стоимость прогона Claude Code по тарифу API — $1,90 в медиане и $7,32 на 90-м перцентиле. «Условная» — потому что раннеры работают по подписке, и эти цифры — оценка, которую считает сам Claude Code, а не наши расходы.
Подробнее о приёмке — типы задач и приёмка, там же пример review → merge.
Агент — это описание
Агентов мы не запускаем руками. Агент — декларация: права, исполнитель, модель, каталог репозиториев, где и сколько реплик держать. Платформа сама поднимает исполнителей на узлах и держит их в описанном состоянии.
kind: Agent key: coder spec: identity: kind: agent permissions: [tasks.claim, tasks.read, tasks.write, artifacts.write, ...] work: onlyAssigned: true executor: kind: claude-code params: {model: claude-opus-5-5, timeoutSeconds: 10800} placement: requires: [claude-subscription, repos] resources: {cpus: 2, memoryMb: 4096} replicas: 2
Смена модели — правка строки и новая ревизия того же агента: идущий прогон заканчивается на прежней модели, следующий берёт новую, контейнер не пересоздаётся. Ядро не даст агенту право решать согласования или администрировать платформу: такую привязку API отвергает. Решать — только людям.
В руководстве — агенты-описания и fleet, который размещает их по узлам.
Память и её онтология
Агенту на задаче нужен не «весь репозиторий в контексте», а ответ на вопрос «что я сломаю». Если в задаче упомянут маршрут API, полезно знать, какой клиент его вызывает, в каком файле он определён и какое архитектурное решение (ADR) им управляет.
Память платформы — граф знаний, и у каждого домена своя онтология. Её тоже объявляет пакет. Онтология разработки ПО у нас — восемь видов сущностей и пять связей, около 50 строк:
kind: KnowledgePack key: software-delivery spec: kinds: - kind: endpoint naturalKey: "<METHOD> <path с параметрами как {}>" - kind: source_file naturalKey: "<repo>:<path>" - kind: client_method naturalKey: "<repo>:<module>.<Class>.<method>" - kind: adr naturalKey: "<SERIES>-<number>" # ... component, ui_call, event, table relations: - {relation: calls, fromKinds: [client_method, ui_call], toKinds: [endpoint], temporal: true} - {relation: defined_in, fromKinds: [endpoint, client_method, ui_call, event, table], toKinds: [source_file], temporal: true} - {relation: governs, fromKinds: [adr], toKinds: [source_file], temporal: true} # ... part_of, emits
А тип задачи объявляет, как из этого графа собрать контекст:
contextSchema: anchors: - {from: description, kinds: [endpoint, adr, event, table]} traverse: - {relation: calls, direction: in, depth: 1, limit: 20} - {relation: defined_in, direction: out, depth: 1} - {relation: governs, direction: in, from: previous} asOf: taskCreated budgetTokens: 4000
Из описания задачи извлекаются якоря — маршруты, ADR, события, таблицы. От них платформа идёт по графу: кто вызывает маршрут, где он определён, какой ADR управляет этим файлом. Связи темпоральны, и asOf: taskCreated означает, что агент видит граф на момент постановки задачи, а не на момент, когда до неё дошла очередь. Результат раннер кладёт в промпт исполнителя отдельным блоком — как данные, а не как инструкции. Граф наполняет тот же коннектор, что наблюдает репозитории: вместе с наблюдением коммита он отправляет в память снимок контрактов.
Почему мы считаем память ключевой частью, а не приложением к агенту. Та же механика работает в доменах, где кода нет вовсе. Процесс оплаты счёта перед решением вспоминает контрагента, договор и прошлые платежи, а после — запоминает исход. Тендерный процесс вспоминает прошлые дела с заказчиком и цены. У каждого домена своя онтология, у каждого знания — источник, дата и права доступа. Память принадлежит организации и переживает смену агентов так же, как работа.
Честно о пределах: насколько профиль контекста улучшает работу агента на коде, мы не измеряли. Сравнения «с графом / без графа» у нас нет.
В руководстве — онтологии в пакете и профиль контекста типа задачи.
Spec-driven — тоже пакет
Крупные фичи идут через цикл «спецификация → план → задачи». Это тоже не код ядра, а пакет из трёх типов задач и одного правила. Дизайн фичи сдаётся двумя документами, spec и plan, и проходит одни ворота — решение человека. Approve запускает проверку формы и заводит шаг разбиения на задачи. Когда документ задач готов, правило разворачивает его в задачи на код по нужным репозиториям и в задачи сходимости — по одной на репозиторий, каждая со своими воротами: одобрение вливает ветку фичи в основную.
Отличие от инструментов, где спецификация — файл в репозитории: здесь spec и plan — входы задач со своей приёмкой, а каждая задача исполнения знает, из какого пункта плана она выросла. За период через цикл прошли 18 дизайнов фич и 60 задач сходимости.
Что сломалось
Публикатор, который сутки бился в стену. 27–28 сентября агент, публикующий релизы в открытое зеркало, 1 063 раза подряд запускал прогон и каждый раз мгновенно получал отказ: у него не было права вызывать нужный скилл. Это 84% всех упавших прогонов за период. Платформа честно записала каждый отказ, но ничто не остановило цикл, пока его не заметил человек. Исправление — назначение скиллов стало частью декларации агента. Сторож зависших прогонов у нас теперь есть: прогон, который долго ничего не делает, проваливается сам. А вот сторожа, который гасит серию мгновенных отказов, пока нет — этот случай он бы не поймал.
Агенты не читали комментарии. Ревьюер писал правки комментарием к задаче, агент брал задачу заново и видел только описание. Теперь контракт исполнителя прямо говорит, что комментарии — часть постановки, и раннер передаёт их агенту в промпте вместе с описанием.
Зависимые задачи стартовали раньше времени. Задача считалась сделанной, как только агент сдал работу, и зависимые задачи брались до того, как ревью и вливание прошли. Отсюда и решение «сделано — значит принято».
Параллельные агенты сталкивались в документации. Две задачи независимо дописывали поправки к одному ADR и обе брали следующую свободную букву. Каждая ветка была корректной, вместе — конфликт. Ревью теперь сверяет такие вещи на дереве слияния, а не на ветке.
Ядро не знает про код
Всё, что выше, — пакеты. В ядре нет ни git, ни merge, ни ревью кода. Мы держим правило: каждая возможность ядра должна доказать себя и на пакете не из разработки.
История, похожая на ту, с которой начиналась статья, случилась в процессе оплаты счетов. Там шаг согласования объявляет разделение обязанностей: загрузивший счёт не может согласовать его оплату. Агент реализовал это в ядре, ревью нашло обход — исключённый согласующий мог отменить согласование, и дело проходило без голоса бухгалтерии, — и через 1 час 42 минуты исправление было влито. Тот же механизм согласований с кворумом и разделением обязанностей описывает в нашем тендерном пакете согласование цены по порогам НМЦК. О нём — следующая статья.
Как платформа выпустила саму себя
Первый открытый релиз оказался хорошей проверкой всего сказанного выше: его тоже собирала очередь.
Переезд. Перед релизом мы перестроили раскладку репозиториев: компоненты разъехались по каталогам services/, sdk/ и apps/, а вместе с ними поменялись пути в CI, раннере, скиллах и Dockerfile. Подготовку — пять задач на код — 3 октября поставил человек, все пять сделал агент. Две вернулись с ревью: в одной правила отставания сабмодулей ссылались на поле, которого не было в контракте скилла, в другой скрипт переезда забыл переписать Dockerfile одного из демо. Самая большая задача — скрипт переезда с прогоном вхолостую на копии — заняла три прогона и затронула 452 файла. Вся подготовка обошлась примерно в $64 по тарифу API. Сам переезд стенда мы делали уже вне очереди задач.
Публикация. Релиз компонента у нас — аннотированный тег в рабочем репозитории. Правило раз в час спрашивает скилл проверки, какие теги готовы к публикации, и на каждый заводит задачу агенту-публикатору. 4 октября в 16:05 UTC, после переезда, правило включили снова. Первая же оценка нашла десять готовых релизов, и публикатор выложил все десять компонентов в открытые репозитории за 6 минут 41 секунду — без единого отказа. Одна задача оказалась дублем: на тот же тег отреагировало второе правило, и скилл отработал вхолостую — тег уже стоял. Ревью у задачи публикации нет: человек решал раньше, когда одобрял сдвиги указателей и ставил теги. В тот день таких решений ревью было 57.
CI собрал всё вместе. Сборка зонтичного репозитория нашла то, чего не видно по отдельности: строку длиннее лимита линтера, устаревший lock-файл, расхождение описания онтологии памяти со снимком в SDK пакетов. И главное — ядро 0.10 отправляло сервису уведомлений поле настроек, которого тот не принимал. На нашем стенде все уведомления падали с 3 октября, а заметили мы это только при сборке релиза. Четыре исправительных выпуска прошли той же очередью — 15 задач публикации за час с небольшим. Тег зонтичного репозитория и GitHub Release поставил человек в 19:19 UTC.
Где мы сейчас
В релизе v0.2.0 открыты под Apache-2.0 ядро, identity, память, уведомления, fleet, веб-консоль, персональный ассистент и SDK. Ассистент построен на DeepSeek Harness (MIT) и использует Claude Agent SDK — у этих зависимостей свои лицензии. Поднять всё локально — быстрый старт, свой пакет — пакет за 10 минут и пример в репозитории.
Пакеты разработки, о которых эта статья, —
selfdevиsdd— в релиз пока не вошли. Фрагменты выше — из них; форматы описаны в руководстве по ссылкам в каждом разделе.Все вызовы модели в нашей установке идут через подписку одного человека. Заменяемость доказана на уровне ревизии агента, а не провайдера.
Ревьюер у нас фактически один. Время человека на ревью мы не мерили.
Цифр экономии нет и не будет, пока не пройдёт пилот вне разработки ПО.
Вопрос к тем, кто запускал агентов на реальной кодовой базе: где у вас заканчивалась автономия агента и начиналась ответственность человека — и где эту границу пришлось переносить?
