Kilo Code испытывает баг с формированием вызовов инструментов для LLM.
В сервисе Kilo Code обнаружен баг, приводящий к циклическим ошибкам, таким как MODEL_NO_ASSISTANT_MESSAGES, при работе с языковыми моделями.
Проблема заключается в некорректном формировании формата вызова инструментов (Tool) для моделей от OpenAI (ChatGPT) и Google (Gemini) в соответствующем режиме Kilo Code. Ошибочный вызов застревает в контексте чата, вызывая цикл, на который провайдеры моделей реагируют стоп-токеном.
Решение на данный момент — закрыть текущую сессию и начать новую.
Эта ситуация служит хорошим примером. Если в процессе разработки используется семантическая разметка кода и создано много артефактов, потеря истории одного чата не критична. Новая языковая модель быстро восстановит контекст. Однако без встроенной документации, графов знаний и других структур потеря чата может стать серьезной проблемой, учитывая, что сбои в работе AI-агентов — явление нередкое.
Этот случай также подчеркивает важность избегания жесткой привязки (vendor lock) как к конкретному провайдеру языковых моделей (LLM), так и к агенту. Если сервис, например Kilo Code, выйдет из строя, разработчики, не зависящие от его экосистемы, смогут относительно легко перейти к конкурентам, используя свои наработки в области разметки и графов.
Причиной для миграции может стать и появление более совершенных технологий, например, гипотетической модели DeepSeek V4 или специализированного DeepSeek Coder. Жесткая привязка к одному вендору лишает гибкости и может снизить конкурентоспособность проекта.
Хотя создателям LLM и агентов выгодно «привязывать» разработчиков к своим платформам, важно осознавать связанные с этим риски.
Ещё новости:
