# Kronos Agent OS: self-hosted runtime для AI-агентов

> Проверяемый разбор KAOS v0.3.0: durable turns, память, MCP tools, governance, поведенческие evals, перенос состояния и безопасные defaults.
> Author: Roman Belov · Published: 2026-04-28 · Source: https://futurecraft.pro/ru/blog/kronos-agent-os-open-source/

Агента, отвечающего на один prompt, легко показать на демо. У агента, работающего неделями, другая поверхность отказа: прерванные turns, пропавшие tools, непроверенные skills, неясные permissions, непрозрачная память и side effects, которые могут выполниться повторно после рестарта.

[Kronos Agent OS](https://github.com/spyrae/kronos-agent-os) - моя попытка вынести этот операционный слой в отдельный runtime. KAOS работает локально вокруг LLM и отвечает за то, что переживает один диалог: state, memory, skills, tools, scheduled work, policy, audit trail и опциональную координацию агентов.

Эта версия статьи заменяет исходное launch-сравнение с конкурентами на проверяемый разбор текущего кода. Важен не размер списка функций, а реализованные гарантии, способы их проверки и ограничения, которые остаются у alpha-проекта.

## GitHub и PyPI сейчас показывают разные версии

На момент обновления репозиторий помечен tag **v0.3.0**, а package metadata в `main` тоже содержит 0.3.0. При этом [PyPI всё ещё раздаёт 0.1.1](https://pypi.org/project/kronos-agent-os/). Это существенная разница: часть описанных ниже возможностей появилась после 0.1.1.

Для работы с текущим source release лучше закрепить Git tag:

```bash
git clone https://github.com/spyrae/kronos-agent-os.git
cd kronos-agent-os
git checkout v0.3.0

python3 -m venv .venv
source .venv/bin/activate
pip install -e ".[dev]"

kaos demo
kaos doctor
```

`kaos demo` детерминирован и работает без LLM key, Telegram и Docker. Он проверяет запуск CLI, workspace, policy defaults и основного runtime. Но он не доказывает работоспособность настроенной модели, MCP server, браузера или sandbox - у этих capabilities свои проверки.

Проект по-прежнему имеет статус **alpha**. Лицензия MIT позволяет изучать и менять код, но сама по себе не делает локального агента безопасным автономным оператором.

## Где проходит граница runtime

KAOS принимает задачи из CLI, Telegram, Discord, webhooks и scheduled jobs. Все входы сходятся в один pipeline:

```text
CLI / messenger / webhook / scheduler
                  |
                  v
          KronosAgent runtime
          |       |        |
       memory   tool gate   durable journal
          |       |        |
       skills   MCP/tools   effects ledger
                  |
          dashboard + audit
```

Основной цикл - читаемый асинхронный ReAct engine на типах сообщений и tools из LangChain. Он контролирует лимит turns, выполнение tools, callbacks и завершение без обязательного LangGraph в главном runtime. При этом LangGraph остаётся опциональной зависимостью ASO-модуля. Поэтому формулировка «без LangGraph» относится к core loop, а не ко всему репозиторию.

Модель выбирает действия. Runtime валидирует policy, записывает state, вызывает tools, сохраняет результат и решает, можно ли безопасно продолжить прерванный turn. Эти обязанности не прячутся за названием Agent OS.

## Durable turn требует effects ledger

Сохранить chat history недостаточно. Если процесс упал после отправки сообщения, но до фиксации завершения turn, обычный replay может отправить то же сообщение второй раз.

KAOS v0.3.0 ведёт journal активных turns и записывает внешние эффекты с опциональными idempotency keys. Resume logic отличает новое действие от уже выполненного эффекта. Лимит повторных попыток останавливает бесконечный crash loop.

Для работы на несколько часов или дней есть plans. Plan содержит цель, steps с dependencies и явные wait conditions: время, ответ пользователя, ручное продолжение, изменение страницы или числовой threshold. Каждый готовый step запускается как обычный управляемый turn. Approvals, budgets, durable execution и audit rules не дублируются внутри planner.

Это важная граница между framework и operating layer: запланированная задача не получает обход policy только потому, что стартует позже.

## Память многослойная, но не обязательная целиком

KAOS умеет сочетать несколько хранилищ:

- SQLite session history для недавних turns;
- FTS5 facts для точного поиска;
- опциональные Mem0 vectors для semantic recall;
- knowledge graph для entities и relations;
- shared facts для мультиагентных deployments;
- sleep-time consolidation для дедупликации и извлечения графа.

Vector layer ставится как optional extra. Базовый runtime не должен требовать локальный embedding stack только для запуска. Такое разделение упрощает диагностику: exact recall, semantic recall и graph traversal - разные операции, которые могут ломаться независимо.

Главный вывод разобран подробнее в [гайде по памяти AI-агентов](/ru/blog/ai-agent-memory/): качество retrieval зависит от provenance, retention, разрешения конфликтов и удаления, а не от количества хранилищ на схеме. KAOS показывает memory и sessions в control room, чтобы оператор мог найти и удалить состояние, а не получать невидимую добавку к prompt.

## Tools и skills входят в supply chain

MCP упрощает discovery, но сервер может перестать отдавать tools, а агент продолжит отвечать по более слабым источникам и не сообщит о деградации.

Так произошло в реальном deployment KAOS. Resilient startup поднял агентов со **102 tools вместо 113**; два MCP server оставались сломанными месяцами, не роняя процесс. В v0.3.0 появились `kaos mcp check` и ежедневный smoke job. Проверка запускает каждый известный server, вызывает tool discovery, показывает количество и считает состояние «запустился, но отдал ноль tools» поломкой. Текст ошибки проходит redaction до отчёта.

У sandbox был похожий false green. Docker и image существовали, поэтому readiness проходил, хотя на одном пути container не мог прочитать временную директорию, а на другом относительный bind mount интерпретировался неверно. Теперь `kaos sandbox check` действительно выполняет код и проверяет containment изнутри container. При отказе runtime не запускает dynamic code без sandbox как fallback.

Skills проверяются с той же недоверчивостью. Registry умеет валидировать checksum, SSH signature от разрешённого key, совместимую версию KAOS и offline scenario. Skill автоматически становится active только при выполнении настроенной trust policy и успешной проверке. В остальных случаях он устанавливается как draft с объяснением.

Это полезнее утверждений «поддерживает MCP» или «есть sandbox»: проверяется capability, которой агент действительно пользуется. Более общий threat model есть в [гайде по безопасности MCP](/ru/blog/mcp-security-guide/).

## Governance хранится как data

В `policy.yaml` можно определить capabilities, approvals, budgets, egress, retention, PII masking и реакцию на untrusted content. `kaos policy report` показывает effective value и его источник. Environment overrides policy, а policy overrides defaults. Невалидный файл останавливает startup вместо тихого возврата к permissive behavior.

Публичные defaults держат рискованные поверхности выключенными:

```bash
ENABLE_DYNAMIC_TOOLS=false
REQUIRE_DYNAMIC_TOOL_SANDBOX=true
ENABLE_MCP_GATEWAY_MANAGEMENT=false
ENABLE_DYNAMIC_MCP_SERVERS=false
ENABLE_SERVER_OPS=false
```

Telegram тоже использует allowlist posture по умолчанию. Dynamic code требует sandbox. Для browser navigation и skill imports можно включить egress allowlist. Результаты внешних MCP tools, публичные сообщения, документы и web content маркируются как untrusted до попадания в model context.

Tool и security audit logs связаны hash chain. `kaos audit verify` находит первую изменённую, удалённую или переставленную запись. Это делает вмешательство заметным, но не превращает локальный log в immutable storage. Пользователь с доступом к файлам может заменить всю директорию, поэтому серьёзный deployment должен отправлять logs в отдельное хранилище вне аккаунта агента.

## Поведение нужно replay, а не обещать

Unit tests доказывают работу policy parser. Они не показывают, поменял ли новый prompt порядок tools или убрал approval gate.

В KAOS Agent CI два механизма:

- cassettes воспроизводят provider calls и вызовы untrusted tools для идентичного input;
- scenarios воспроизводят наблюдавшуюся последовательность model turns и проверяют tool path, call limits, approvals, запрещённые tools и отдельные свойства результата.

`kaos eval diff --base origin/main` запускает базовую revision во временном worktree и показывает структурные изменения поведения. Suite работает без provider keys. Она намеренно **не** заявляет, что измеряет качество ответа после изменения prompt: scripted model фиксирует детерминированную половину run. Semantic quality всё равно требует live evals на реальных задачах и human review.

Offline scenario может поймать ситуацию «write tool перестал спрашивать approval». Он не скажет, стал ли новый system prompt лучше советовать путешествия.

## Перенос состояния с явными отказами

`.kaos` bundle экспортирует persona files, skills, facts, graph data, shared facts и ожидающие schedule entries. Manifest содержит SHA-256 каждого artifact, а import проверяет весь payload до записи.

Exporter намеренно исключает `.env`, Telegram sessions, raw SQLite databases, vector stores и audit logs. Imported skills становятся drafts. Чужая session history попадает в inbox note, а не перезаписывает живые threads. Dry run проходит тот же merge path без сохранения изменений.

Сейчас importers понимают ChatGPT exports, Claude projects, Obsidian vaults, выбранные Telegram chats и Letta agent files. Важен не список, а общий контракт: каждый importer создаёт один проверяемый bundle format и использует одинаковые merge rules.

## Swarm Mode остаётся опцией

По умолчанию KAOS - один долгоживущий агент. Swarm Mode добавляет отдельные процессы со своей persona, workspace, memory и опциональным messenger account. Общий SQLite ledger координирует неявные ответы через `IMMEDIATE` transactions.

В v0.3.0 больше структуры вынесено в `agents.yaml`: ownership, escalation targets, SLA minutes, budgets отдельных агентов, обязательный dissent review и reply caps. Решение о релевантности остаётся вероятностным, но arbitration дубликатов и enforcement бюджета детерминированы.

Этот режим нужен только там, где независимые роли улучшают результат. Для большинства workflows один агент с явными tools и review step проще в эксплуатации, чем панель. Trade-offs разобраны в [гайде по multi-agent architecture](/ru/blog/multi-agent-architecture/).

## Где KAOS уместен

KAOS имеет смысл, если нужен:

- self-hosted Python runtime вместо managed agent service;
- inspectable state: memory, jobs, tool calls, policies и durable turns;
- scheduled work с теми же approvals и budgets, что у chat;
- MCP и custom tools за консервативными capability gates;
- переносимое состояние агента и детерминированные behavior checks;
- опциональная мультиагентная координация, а не обязательный swarm.

Он не подходит для простого stateless API call, готового consumer assistant или системы со зрелыми гарантиями обратной совместимости. Проект молод, версии GitHub и PyPI сейчас расходятся, а browser, server и dynamic-code capabilities создают операционную нагрузку, которую владелец принимает на себя.

Теперь утверждение уже: KAOS не делает агентов автономными или безопасными одним названием. Он делает их state, permissions, effects и failures заметнее и проверяемее. Для долгоживущего агента именно эта работа начинается после успешного demo.

## Источники

- [Репозиторий Kronos Agent OS и документация v0.3.0](https://github.com/spyrae/kronos-agent-os)
- [Changelog KAOS](https://github.com/spyrae/kronos-agent-os/blob/main/CHANGELOG.md)
- [Модель безопасности KAOS](https://github.com/spyrae/kronos-agent-os/blob/main/docs/SECURITY.md)
- [KAOS Agent CI](https://github.com/spyrae/kronos-agent-os/blob/main/docs/EVALS.md)
- [kronos-agent-os на PyPI](https://pypi.org/project/kronos-agent-os/)