flue

"Фреймворк для агентных харнесов" от withastro - среда выполнения на TypeScript, которая берёт архитектуру Claude Code (скиллы на Markdown, AGENTS.md, песочницу, инструменты, сессии) и поставляет её в виде программируемой headless-библиотеки. Ни TUI, ни GUI, никакого обязательного участия человека (human in the loop). Питч с главной страницы:

Не очередной SDK. Создавайте мощных автономных агентов с помощью программируемого TypeScript-харнеса Flue.

Хватит арендовать чужих агентов. Готовые ИИ-инструменты создаются для широкой аудитории и с трудом адаптируются под ваш продукт, ваши данные, ваших клиентов или конкретные рабочие процессы.

Формулировка в README ещё точнее: "считайте, что это Astro или Next.js, но для агентов: пишите один раз, собирайте и разворачивайте где угодно". Целевые платформы: Node.js, Cloudflare Workers (с Durable Objects для хранения состояния сессий), GitHub Actions, GitLab CI/CD.

Чем это интересно

Большинство агентных фреймворков (LangChain, AI SDK, Mastra, CrewAI) - это библиотеки: вы импортируете их в хост-процесс, и они дают вам примитивы для генерации ответов и цикла вызова инструментов. Flue - это именно фреймворк в духе Astro/Next: он берёт на себя сборку, dev-сервер, артефакт развёртывания, хранилище сессий и маршрутизацию URL. Файл агента по пути .flue/agents/<name>.ts выступает единицей кода, а харнес - средой выполнения.

Это меняет подход к тому, что вы строите. Все четыре примера из README - быстрый переводчик, агент поддержки с базой в R2, сортировщик issue в CI и полноценный кодинг-агент в контейнере Daytona - с первой строки спроектированы под боевое развёртывание. Каждый из них объявляет triggers (webhook / CLI / ничего), получает типизированную схему результата через valibot и работает внутри песочницы, о настройке которой агенту не нужно задумываться.

Ставка на виртуальную песочницу

Ключевое архитектурное решение: песочница по умолчанию виртуальная, а не контейнерная. Она работает на базе just-bash (vercel-labs) - внутрипроцессного Bash-подобного интерпретатора с подключаемой файловой системой в оперативной памяти. Из README:

Виртуальная песочница работает несравнимо быстрее, обходится дешевле и масштабируется лучше, чем запуск отдельного контейнера под каждого агента, благодаря чему она идеально подходит для высоконагруженных и масштабных систем.

Это полная противоположность тому, как устроен любой другой инструмент в таксономии sandboxing-ai-agents. bubblewrap-dev-env использует пространства имён Linux; hazmat использует macOS Seatbelt и выделенного пользователя; superhq поднимает microVM на каждую сессию. Flue же утверждает: большинству агентов полноценная ОС не нужна. Им требуется погрепать файлы, записать вывод, возможно, вызвать какую-то утилиту. Поэтому по умолчанию используется среда в форме Bash, являющаяся обычным объектом JS, а контейнер Daytona или sandbox: 'local' поднимаются лишь тогда, когда агенту действительно требуются git clone и npm install.

Интеграция с Cloudflare отлично раскрывает эту идею: getVirtualSandbox(env.KNOWLEDGE_BASE) монтирует R2-бакет в качестве корня / для агента, и тот ищет по нему инструментами grep/glob/read без запуска какого-либо контейнера. При ценообразовании Workers это единственный экономически оправданный способ запускать "агента поддержки под каждого клиента на каждый запрос".

Доступны три режима песочницы:

• getVirtualSandbox(...) - по умолчанию, внутри процесса, с возможностью подключения R2/KV на Cloudflare.
• 'local' - монтирует файловую систему хоста в /workspace. Удобно для CI, где репозиторий уже склонирован.
• daytona(sandbox) - полноценный Linux-контейнер через Daytona. Кэшируется после первой сборки.

Markdown как программа

Для запуска требуется совсем немного кода - большая часть "логики" живёт в Markdown: скиллах, контексте и AGENTS.md.

Та же конвенция с AGENTS.md и .agents/skills/, к которой пришли Claude Code, Cursor и общая экосистема скиллов (см. mcp-vs-skills, impeccable, agent-skill-linter). Ссылаться на скиллы можно по name: из frontmatter или по относительному пути:

const r = await session.skill('triage', { args: { issueNumber: 42 } });
const r = await session.skill('triage/reproduce.md', { ... });

Ссылки по путям созданы специально для наборов скиллов (skill packs), объединяющих несколько этапов в одном каталоге.

Программируемые примитивы

API сессий компактен и легко удерживается в голове:

• session.prompt(text, opts) - отправляет реплику пользователя и возвращает типизированный результат (схема valibot).
• session.skill(name, opts) - запускает описанный в Markdown скилл с параметрами args:.
• session.task(text, opts) - порождает отдельного фонового дочернего агента в свежей сессии с доступом к песочнице родителя. Тот же инструмент task доступен LLM во время prompt()/skill(), поэтому модель может сама делегировать параллельное исследование.
• session.shell(cmd, opts) - прямой вызов оболочки, полезный для шагов инициализации до того, как управление передаётся LLM.

Инструменты изолируются на уровне каждого вызова:

const npm = defineCommand('npm');
const gh  = defineCommand('gh', { env: { GH_TOKEN: process.env.GH_TOKEN } });

await session.skill('triage', { commands: [gh, npm], ... });

Секрет остаётся в окружении хоста: агент получает исполняемый файл gh, который может запускать, но напрямую GH_TOKEN не видит. Тот же подход, что и у шлюза авторизации в superhq, но на уровне отдельных инструментов.

Роли (легковесные оверлеи субагентов)

Роли можно задавать на уровне агента, сессии или вызова - приоритет: call > session > agent. Что принципиально важно:

Инструкции роли накладываются как системный промпт в рамках конкретного вызова, а не встраиваются в сохраняемую историю сообщений пользователя.

Поэтому переключение на role: 'reviewer' ради одного промпта не засоряет историю сессии. Это важное архитектурное решение: многие реализации "субагентов" ошибочно запихивают инструкции роли в системное сообщение, которое затем преследует каждый последующий шаг диалога.

Триггеры и маршрутизация

Каждый файл агента объявляет свои триггеры:

export const triggers = { webhook: true };  // HTTP
export const triggers = {};                  // CLI-only (flue run)

Для HTTP идентификатор агента задаётся последним сегментом пути в URL:

POST /agents/<agent-name>/<id>

Повторное использование одного и того же <id> продолжает диалог; новый id создаёт свежую сессию. На Cloudflare сессии сохраняются между запросами благодаря Durable Objects; на Node.js они по умолчанию хранятся в оперативной памяти, если не подключить собственное хранилище.

MCP

connectMcpServer() служит для подключения к удалённым серверам MCP из доверенного кода хоста:

const github = await connectMcpServer('github', {
  url: 'https://mcp.github.com/mcp',
  headers: { Authorization: `Bearer ${env.GITHUB_TOKEN}` },
});
const agent = await init({ tools: github.tools, ... });

По умолчанию используется потоковый HTTP; устаревший SSE включается через transport: 'sse'. Текущая версия намеренно не определяет транспорт автоматически, не запускает локальные stdio-серверы MCP и не обрабатывает обратные вызовы OAuth. Всё в том же духе, что и остальной API: инструмент ориентирован на прод, а не на ноутбук разработчика.

Установка и запуск

npm i @flue/sdk @flue/cli

flue dev --target node          # watch-mode dev server, port 3583 ("FLUE")
flue dev --target cloudflare    # via wrangler

flue run hello --target node --id test-1 --payload '{"text":"hi","language":"fr"}'

flue build --target node          # single bundled .mjs
flue build --target cloudflare    # Workers + Durable Objects (wrangler deploy)

Сравнения

• vs adk-go - Go ADK от Google даёт схожие примитивы (сессии, инструменты, A2A), но остаётся библиотекой; Flue ориентирован на модель фреймворка и развёртывание на разные платформы.
• vs botctl - botctl представляет собой менеджер процессов для долгоживущих ботов Claude с файлами BOT.md; Flue - это фреймворк, на котором пишется сам бот. Они дополняют друг друга, а не конкурируют.
• vs charlie-daemons - демоны в Charlie - это автономные ИИ-процессы на базе Markdown, оркестрируемые их платформой; Flue предлагает открытый фреймворк с тем же подходом, но для самостоятельного развёртывания.
• vs gomodel - gomodel работает как шлюз на уровне процессов, совместимый с OpenAI; Flue общается с провайдерами напрямую через идентификаторы моделей вроде anthropic/claude-sonnet-4-6 или openrouter/moonshotai/kimi-k2.6 (синтаксис как в OpenRouter).
• vs crabtrap - crabtrap от Brex - это HTTP-прокси с оценкой через LLM-as-judge для защиты агентов в проде; Flue находится за этим прокси. Их стоит использовать в связке, а не выбирать между ними.
• vs Dosu / Greptile / CodeRabbit - главная страница прямо называет их готовыми сторонними сервисами, альтернативой которым выступает Flue.

Статус и нюансы

• 1800 звёзд за три месяца (проект создан 2026-02-07), 91 форк, 8 открытых issue, последний коммит сегодня (2026-05-03). Apache-2.0.
• README открывается предупреждением: "Experimental - APIs may change." Версия v0.0.x вынесена в отдельную ветку; текущий main представляет собой переписанную с нуля кодовую базу.
• Из коробки поддерживаются платформы Cloudflare и Node.js; другие варианты сборки "появятся в будущем".
• Нет поддержки MCP через stdio, нет обработки OAuth и автоматического определения транспорта - для v1 это осознанное решение, но стоит учесть, если вашему агенту нужны локальные MCP-серверы.
• За проектом стоит withastro (организация, разрабатывающая фреймворк Astro), так что bus factor здесь "на уровне самого Astro", и это самый сильный аргумент в пользу проекта. Помещён в основной каталог toolbox, а не в watchlist.

Репозиторий

github.com/withastro/flue - главная страница flueframework.com · 1.8k★ · Apache-2.0 · TypeScript · ветка main (текущий рерайт)

Источник: flue-readme.