Домашний агент на бесплатном тарифе OpenCode через Kimaki
Привет, я некомпетентный.
Я был против того, чтобы держать агента постоянно на домашнем сервере, но в бесплатном тарифе это было трудно реализовать, поэтому я этого не делал. Однако со временем у меня возникло желание запускать параллельные исследования и строить простые графики интересующей меня статистики, находясь вне дома.
Итак, я думал, как же поднять бота, максимально близкого к нативному OpenCode. Репозиторий OpenClaw — это нечто впечатляющее, но мне хотелось попробовать что-то другое, и в поисках я наткнулся на Kimaki — его я и попробовал.
До этого я пробовал оборачивать OpenCode и запускать его как бота-агента, но изменений много, и сопровождать их самостоятельно довольно хлопотно, поэтому хотелось, по возможности, обойтись готовым решением.
Что мне было нужно:
Полноценная поддержка Discord.
Возможность бесплатной работы в рамках подписки OpenCode.
Используем Kimaki
Установка
https://github.com/remorses/kimaki
npx -y kimaki@latestПри этом, если OpenCode ещё не установлен, он будет установлен, а bun, необходимый как зависимость, тоже будет установлен.
Затем достаточно пригласить бота Kimaki на свой сервер по ссылке, появившейся в конце.
Кроме того, в этом случае по умолчанию бот работает через Kimaki, так что лучше не отправлять в переписку ничего конфиденциального, и, думаю, стоит завести отдельный Discord-сервер.
Нет необходимости создавать бота в своём Dev Portal, так что с точки зрения удобства это отличный вариант.
Что касается переключения моделей, то его можно сделать через /model, так что многие вещи можно решить прямо через Discord.
Кстати, в связи с этим OpenCode, по-видимому, использует специальный HTTP-заголовок при вызовах API, как показано ниже.
https://github.com/earendil-works/pi/issues/2824
Может быть, на стороне API-сервера они намеренно возвращают 429 вместо 403, чтобы усложнить понимание и предотвратить злоупотребление? На самом деле, я думаю, у OpenCode есть намерение ограничить выпускаемые API-ключи использованием в агенте OpenCode. Однако поскольку текущие запросы к этой конечной точке API можно аутентифицировать с помощью API-ключа хочешь не хочешь, я думаю, в будущем появятся новые механизмы аутентификации, а точнее, решения, которые компании смогут принимать для предотвращения злоупотреблений, и такие сценарии использования будут расширяться.
Например, если бы можно было раздавать пользователям клиентские сертификаты в рамках mTLS, хранить их в специализированных чипах безопасности, таких как TPM или EC-контроллер, и сделать так, чтобы вызовы были возможны только по фиксированному пути, то нынешний мир, где можно свободно обращаться к API, возможно, подошёл бы к концу.
Однако, в конце концов, это тоже бессмысленно, если клиентский сертификат извлекут с помощью реверс-инжиниринга. Но учитывая нынешний скачок в развитии технологий TPM, а также то, что сброс пароля BIOS стал гораздо сложнее, возможно, появятся функции, которые приведут к повышению безопасности приложений с аппаратной интеграцией.