Большинство инструментов для кодирования AI являются оболочками: это цикл вокруг модели плюс инструменты для чтения и записи файлов, а также выполнения команд. Claude Code, Codex, OpenCode и Pi — все они оболочки, созданные для разработчика, работающего в терминале.
Coroid не использует ни один из них. Он применяет собственные средства.
Почему бы не воспользоваться существующей оболочкой?
Вышеупомянутые инструменты разработаны для сессии с участием человека. Кто-то наблюдает, может ответить на вопрос, прервать процесс или заметить ошибку. Это разумное предположение, определяющее всё — как проявляются ошибки, какой объём контекста передаётся, что происходит, когда модель возвращает некорректный результат.
Предположение Coroid противоположно: никто не наблюдает. Работа выполняется в облаке по расписанию, по сигналу монитора или событию, и должна привести к проверяемому результату или явной ошибке без возможности вмешательства в процесс.
Это разные задачи. Некоторые элементы существуют именно из-за этой разницы и не имели бы смысла в сессии терминала.
Чем отличается рантайм?
Он рассчитан на автономную работу. Если модель возвращает некорректный ответ или искажённый вызов инструмента, цикл исправляет ошибку и повторяет попытку, вместо того чтобы выводить запрос, на который никто не ответит. Автономный запуск, останавливающийся для задания вопроса, который можно было решить самостоятельно, — это пустая трата ресурсов.
Он изначально построен как мультиагентная система. Цикл основан на ролях с разными правами доступа, передающих задачи друг другу в строгом порядке или под управлением Координатора, определяющего следующий шаг, а не одного агента, выполняющего всё. Проверку проводит агент, не участвовавший в написании кода, и Координатор не может его переопределить — это свойство архитектуры, а не результат просьбы. Координатор также может обнаружить, что код уже реализует требуемую функциональность, и поручить QA проверить это без внесения изменений. Все пути ведут к одним и тем же этапам проверки.
У него чётко заданные бюджеты и ограничения глубины. Каждый запуск ограничен бюджетом токенов и максимальным числом шагов. Без этих ограничений автономный агент, неправильно понявший задачу, продолжал бы работу бесконечно.
Управление осуществляется непосредственно в процессе выполнения. Политики, этапы качества и точки утверждения входят в сам процесс выполнения, а не являются внешним слоем, поэтому блокирующий этап может остановить работу прямо во время её выполнения, а не после завершения.
Кэширование — важнейший аспект.
Контекст составляет основную часть затрат на работу агентов, и в облачной оболочке один и тот же проектный контекст считывается многократно в рамках разных задач.
По этой причине рантайм активно использует кэширование запросов. Вы можете увидеть его работу в журнале выполнения задачи выполнения, где шаги указывают эффективность кэширования:
9.1k used (90% cached)Высокий уровень попаданий в кэш — это разница между дорогостоящим и дешёвым запуском. Именно поэтому хорошо структурированный проект с чётким контекстом обходится дешевле, чем раздутый проект — стабильный контекст хорошо кэшируется, а меняющийся при каждом запуске — нет.
Это сочетается с постепенным развитием навыков, что изначально уменьшает объём загружаемого контекста.
Что это значит на практике?
- Никакой локальной настройки. Нет CLI, плагинов для редакторов, сторонних сред выполнения. Coroid основан на API и работает в облаке.
- Нет подписок на сторонние инструменты. Вы не покупаете лицензии на помощника по кодированию дополнительно к Coroid. Использование модели оплачивается в виде кредитов или через ваши собственные ключи провайдера.
- Работа выполняется автономно. Расписания и хуки возможны, так как ничто не зависит от того, включён ли компьютер разработчика.
- Поведение одинаковое. Работа всех пользователей выполняется в одной и той же среде рантайма с одинаковыми правилами, в отличие от ситуации, когда всё зависит от установленного и настроенного программного обеспечения у каждого разработчика. Установленные компоненты перечислены в разделе поддержка языков и среда агентов.
Что не меняется.
Оболочка определяет способ выполнения работы. Она не меняет границ: любое изменение всё равно оформляется как pull request в ветке, ничего не мержится автоматически, а правила защиты веток и ревью применяются так же, как к изменениям от людей.