Когда пишешь чат-виджет под customer support или внутренние тулы, последнее, что хочется — это изобретать велосипед с провайдерами, фейловерами и интеграцией платежей. Команда agents.io выкатила ChatbotLite — React-компонент, который решает ровно эти задачи. Покопался в API и вот что выделил.
Provider chain: failover как first-class citizen
Вместо того чтобы зашивать один провайдер, ChatbotLite предлагает цепочку из 10 вариантов (OpenAI, Groq, Gemini и другие). Если стрим падает, следующий в списке подхватывает генерацию с чистого листа:
chain: [
{ provider: "openai", model: "gpt-4o-mini" },
{ provider: "groq", model: "llama-3.3-70b-versatile" }
]
На практике это решает две боли:
- Rate limits — когда OpenAI отвечает 429, запрос автоматически уходит в Groq
- Model-specific bugs — если gpt-4o сбоит на длинных контекстах, Llama 3 достраивает ответ
Но есть нюанс: текущая реализация не сохраняет partial output при переключении. То есть если GPT успел нагенерировать 200 токенов до падения, Llama начинает с нуля. В roadmap заявлен mid-stream replay — возможно, стоит подождать 0.8, если continuity критичен.
SKILL-маркеры: декларативные экшены
Вместо сложных chat plugins авторы предлагают паттерн маркеров в потоке:
[SKILL:requestPayment amount=2000 currency="usd"]
Когда бот выводит такую строку, UI рендерит соответствующую карточку (платеж, бронирование и т.д.). Из коробки идут адаптеры для Stripe, Calendly и других сервисов — достаточно закинуть URL в конфиг.
Плюсы подхода:
- No vendor lock-in — спецификация открыта, можно написать адаптер под любой API
- Debuggable — маркеры видны в логах и devtools
- Optional — если бот не использует навык, его код не грузится
Минус: пока нет typed-интерфейсов для маркеров. Придется парсить строки вручную или надеяться, что LLM не ошибется в синтаксисе.
Knowledge base без векторных БД
Авторы сознательно отказались от RAG-архитектуры для базы знаний. Вместо этого — единый markdown-файл, который целиком летит в контекст:
knowledge: knowledgeFromFile("./knowledge.md")
Работает, пока укладываешься в 32k токенов. Для SMB-кейсов (документация продукта, FAQ) — ок. Но если загружать всю базу поддержки, упрешься в лимиты.
Стоит ли жертвовать простотой ради масштабируемости? Мой опыт: начинать с файла — нормально. Когда упрешься в ограничения, можно накатить vector store через тот же ChatStorage интерфейс.
Куда развивать API
Сейчас провайдер-цепочка — это монолитная конфигурация. Альтернатива — вынести failover в отдельный хук:
onProviderError: (failedProvider, error) => {
return nextProviderConfig // или throw чтобы остановить сессию
}
Такой подход даст больше контроля:
- ретраи с экспоненциальным backoff
- аналитика ошибок
- условные переходы (если 429 — переключиться, если 500 — показать apology message)
Но усложнит код для базовых сценариев. Команда просит фидбек — если у вас есть use case, который не ложится в текущий API, сейчас лучшее время его озвучить.
Для кого это
ChatbotLite — не фреймворк уровня LangChain, а именно embeddable-виджет. Если вам нужно:
- чат-окно для сайта с поддержкой нескольких провайдеров
- простые экшены без кастомной UI-логики
- деплой через npm или script tag
— стоит попробовать. Если же нужен кастомный orchestration или сложные RAG-цепочки, возможно, лучше собрать свое решение на более низкоуровневых инструментах.
Из интересного в roadmap: WebSocket-транспорт вместо HTTP, typed SKILL-маркеры и плагины для VSCode/Cursor. За развитием можно следить в их Discord.
Попробуй сам: DigitalOcean — $200 кредитов для новых пользователей.
Источник: https://www.reddit.com/r/reactjs/comments/1tq9lhn/opensourced_our_react_chatbot_looking_for_api/