kastor

Слой единого источника правды (source of truth) для ИИ-агентов. Модель, промпты, инструменты, входные и выходные данные, а также зависимости агента описываются на HCL; спецификация проходит валидацию, после чего либо компилируется в исполняемый код фреймворка, либо синхронизируется с хостинговыми агентами в стиле Terraform через plan / apply / state. Основная идея в том, что сегодня описание агента размазано по коду фреймворка, файлам промптов, реализациям инструментов, настройкам в UI платформы и переменным окружения, а этот разброс стоит свести к единому версионируемому контракту, который удобно просматривать и сравнивать через diff. Проект входит в то же семейство агентов на базе спецификаций, что и acai.sh с beads, но нацелен на внешний интерфейс агента, а не на критерии приёмки или граф задач.

Автор чётко очерчивает границы: Kastor - это не среда исполнения агентов (runtime). Исполнением по-прежнему занимаются фреймворки вроде LangGraph, а управляемых агентов запускают хостинговые платформы. Kastor находится уровнем выше и описывает только те элементы, которые неизбежно присутствуют везде, независимо от выбранного runtime'а. Ставка делается на то, что подходы к средам исполнения продолжат постоянно меняться, а потребность в проверяемом контракте агента никуда не денется.

Как это устроено

Модуль представляет собой каталог с декларативными файлами:

Блоки ссылаются друг на друга по адресу, а не по путям к файлам: агент указывает на model.fast, prompt.weather_system, tool.web_search. Эти ссылки также формируют граф зависимостей, а адрес вроде agent.forecast.output.summary проверяется на этапе компиляции, чтобы убедиться в существовании выхода и упорядочить граф. Переменные промптов и ссылки проверяются командой kastor validate.

Из валидного модуля есть два пути. kastor build компилирует спецификацию в исполняемый проект под нужный фреймворк - сегодня LangGraph остаётся единственной рабочей целью для кодогенерации, поддержка Vercel eve запланирована, а Burr рассматривается после обсуждения на HN. Сгенерированный проект считается одноразовым результатом, а не источником правды: он не коммитится в репозиторий, воспроизводится из спецификации, а детерминированность генерации гарантируется тестами. Второй путь - kastor plan / apply / destroy - согласует долгоживущих хостинговых агентов с локальным файлом состояния (state) с помощью трёхстороннего diff'а и отслеживания дрейфа конфигурации (drift detection). Команда plan только считывает данные и не затрагивает удалённые ресурсы или state; при обновлениях отображаются diff'ы на уровне атрибутов, а внешние удалённые изменения фиксируются как предупреждения о дрейфе. Сейчас единственная доступная целевая платформа - встроенная in-memory реализация, поэтому plan/apply работает без каких-либо учётных данных.

Пример

Спецификация агента:

agent "weather" {
  description = "Answers weather questions for a location and date"

  model         = model.fast
  system_prompt = prompt.weather_system
  tools         = [tool.web_search]

  input "location" {
    type        = string
    description = "The location to get weather for"
  }

  input "date" {
    type     = string
    optional = true
  }

  output "weather" {
    type = string
  }
}

Команда kastor init demo создаёт каркас минимального модуля: один агент, один MCP-инструмент, один промпт, модель и целевой LangGraph. Он валидируется и собирается без каких-либо правок, используя эталонный сервер fetch для MCP через uvx, поэтому API-ключ не требуется. Основные команды:

kastor init demo
cd demo
kastor validate
kastor build          # writes a LangGraph project to the target's declared output dir
kastor plan examples/weather/
kastor apply examples/weather/

Конечные точки инструментов определяются по URI в спецификации (mcp://search-server/tavily_search). То, как именно подключиться к серверу, относится к конфигурации развёртывания: эти параметры передаются через файл mcp_servers.json или переменную окружения KASTOR_MCP_CONFIG, не включаются в саму спецификацию и добавляются в .gitignore, поскольку URL может содержать API-ключ.

Ограничения

Ранний proof-of-concept от одного автора, 57 звёзд. Есть только одна цель для кодогенерации (LangGraph) и одна целевая платформа (in-memory); облачные провайдеры вроде Bedrock AgentCore или Dify пока на стадии проектирования. Зависимости между агентами проверяются и выстраиваются в правильном порядке, но не исполняются автоматически: если опциональный вход одного агента ссылается на выход другого, сгенерированный код не запустит исходного агента за вас - запускать его нужно вручную, передавая результат через --inputs. Полная сборка и запуск примера с LangGraph требуют Go 1.26+, Python 3.11+ и API-ключи для OpenAI и Tavily. В обсуждении на HN прямо указали на очевидный риск: единого понимания, что такое "агент", пока нет, поэтому любая попытка зафиксировать его текущий вид может быстро устареть. Автор возражает, что намеренно стандартизирует лишь внешний контракт (входы, выходы, модель, промпт, инструменты, цель), а не цикл управления (control loop), исходя из предположения, что сам контракт остаётся стабильной частью. По этой причине проект находится в watchlist; см. watchlist.

Репозиторий: https://github.com/weirdGuy/kastor - 57 звёзд, Apache-2.0.