Переписываем основу агента: полный рефакторинг Orkas

Когда продукт с ИИ-агентами становится зрелым, дороже всего обходятся не функции, а фундамент. В этой статье разбирается полный рефакторинг Orkas в линейке релизов 1.0: переработка вызовов моделей, цикла агента, оркестрации нескольких агентов и экосистемы инструментов, а также компромиссы, стоящие за каждым решением.

Коротко Зачем всё переписывали Результат — приложение, которое можно установить уже сегодня: открытый код под лицензией MIT, приоритет локальной работы и возможность использовать собственные ключи провайдеров.

Скачать Orkas — бесплатно

Зачем трогать фундамент

Orkas — это настольная рабочая среда для ИИ-агентов с приоритетом локальной работы: вся работа агентов выполняется внутри процесса на компьютере пользователя, данные хранятся локально, а сквозная облачная синхронизация запускается по необходимости. В ранних версиях функции появлялись быстро: библиотека навыков, база знаний, коннекторы, несколько агентов в формате группового чата. Но чем дальше мы шли, тем яснее становилось: реальное ограничение — не отдельная функция, а три проблемы на уровне фундамента.

Если слой вызова моделей строится по старой логике чата, он оказывается скован неверными предположениями. Вызов большой модели в режиме «один вопрос — один ответ» незаметно привносит настройки, разумные для чата, но не для агента: фиксированный предел выходных токенов, последовательные вызовы инструментов, скрытые тайм-ауты, жёстко заданный единственный провайдер. Агент — длительный процесс, который выполняет десятки ходов подряд, регулярно приближается к границе контекста, должен параллельно читать файлы и может быть прерван пользователем в любой момент. Каждая из этих настроек даст о себе знать в эксплуатации. Более того, самые ценные возможности настольного агента — точные операции с файлами, локальный поиск, запуск оболочки, параллельная работа нескольких исполнителей и решение длительных задач — как раз и блокируются этим слоем предположений.
Оркестрация была «статическим планированием». Ранняя версия представляла собой движок планов/DAG: сначала модель разбивает задачу на граф плана, затем исполнитель распределяет работу по графу. Звучит стройно, но работа агента крайне динамична: чтение одного файла показывает, что нужно сменить направление, а результат подзадачи определяет следующего исполнителя. Когда решения заморожены в заранее созданном графе, каждое расхождение плана с реальностью приходится исправлять внутри исполнителя.
Экосистема была закрытым каталогом. Навыки можно было получать только из официального маркетплейса, коннекторы были жёстко заданным каталогом, а внешние агентские инструменты на компьютере пользователя оставались для Orkas чёрным ящиком. Подключить сторонний проект, собственный MCP-сервер или дать уже установленному агенту доступ к навыкам и базе знаний Orkas — архитектура не позволяла ничего из этого.

Идея рефакторинга проста: вернуть фундамент агента под собственный контроль. На практике это четыре взаимосвязанных направления: собственная среда выполнения внутри процесса, независимый от провайдера слой моделей, динамическая оркестрация через групповой чат и переход от закрытого каталога к открытой платформе. Разберём их по очереди.

1. Полный набор возможностей агента для программирования на рабочем столе

Рабочий стол — естественная среда агента: здесь есть настоящая файловая система, оболочка и локальные инструменты. Помощник, который умеет лишь общаться, растрачивает возможности этой среды. Преимущество настольного приложения раскрывает полный набор возможностей агента для программирования: чтение и запись файлов с точностью до диапазона символов, поиск по файлам, запуск bash и системных инструментов, параллельный запуск нескольких исполнителей и способность решать длительные задачи десятками ходов, пока сложная работа действительно не завершится.

Главный результат рефакторинга нужен именно для того, чтобы встроить эти возможности непосредственно в собственный процесс Orkas: отдельная динамически загружаемая среда выполнения агента внутри процесса (в коде она называется core-agent ). Это не очередная оболочка для чата, а движок агента, который Orkas контролирует сам.

Ключевое архитектурное решение — разделить его на два слоя:

Слой движка (отдельный пакет): только механика агента: цикл вызова инструментов, потоковые события, сжатие контекста, классификация ошибок и повторы, абстракция провайдера, песочница, поиск навыков, память, саморазвитие. Он ничего не знает о прикладной логике Orkas: не читает каталоги прикладных данных, не понимает формат файлов диалогов и никогда не обращается к IPC.
Слой адаптера (в основном процессе): подключает движок к Orkas: сохранение сессий, ротация провайдеров, разрешения инструментов, реестр навыков, коннекторы, база знаний, инструменты генерации. Он преобразует события движка в форматы Orkas, поэтому прикладной слой всегда видит стабильный интерфейс.

Граница между движком и адаптером — основа всей последующей гибкости. Движок можно независимо тестировать и развивать; адаптер безопасно принимает сложность, специфичную для Orkas, — ротацию, паузы, песочницу, разрешения — не засоряя движок. На архитектурном разборе команда сформулировала это одной фразой: эта сложность оправданна — не сливайте слои.

Что именно входит в набор возможностей

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

Точные операции с файлами и локальный поиск. read_file поддерживает чтение диапазона символов и автоматически извлекает текст из PDF и документов Office; edit_file выполняет точную замену «старая строка → новая строка» и требует чтения перед любой записью; write_file сохраняет результат и регистрирует его; stat_file проверяет размер; search_files ищет по имени/glob-шаблону, grep_files ищет содержимое в разных файлах. Благодаря этому агент может разбираться в коде и менять файлы в настоящем рабочем пространстве как инженер, а не только поглощать и выдавать целые блоки.
Bash и системные инструменты. Исполнитель команд оболочки в песочнице с фоновым режимом: длительные задачи отделяются от текущего хода, журналы пишутся в файл. Опасные операции проходят проверку по уровню риска. Большая часть пользы настольного агента связана именно с возможностью напрямую управлять системными инструментами.
Параллельная работа нескольких исполнителей. В одном ходе независимые инструменты только для чтения работают одновременно; на уровне задачи Commander может параллельно распределять независимые подзадачи между несколькими исполнителями (см. раздел 3). Безопасное распараллеливание — ключ к приемлемому времени выполнения длительных задач.
Длительные рассуждения и решение задач. Цикл, который способен выполнять десятки ходов подряд, управлять своим контекстом, восстанавливаться после ошибок и не топтаться на месте, — вот граница между завершением сложной работы и ответом на вопрос.

Как это довели до готовности к эксплуатации

«Написать собственный цикл» звучит как приглашение к проблемам и действительно требует затрат на поддержку. Зато это даёт точный контроль над всем жизненным циклом агента. Контроль не абстрактный: это конкретные улучшения, каждое из которых определяет, выдержит ли одна из перечисленных возможностей реальную эксплуатацию.

Реальное окно контекста и сжатие только на 80%. Движок считывает реальное окно контекста каждой модели, включая модели с окном в миллион токенов, и запускает сжатие только при заполнении на 80%, вместо осторожного старта на 60% с потерей 40% полезного контекста. Есть и защита от бесполезного сжатия: если сохраняемый конец истории уже заполняет окно, например из-за результата чтения очень большого файла, сжатие ничего не освободит. Тогда движок записывает предупреждение и пропускает его, не тратя вызов на бессмысленную сводку. Именно от этого зависит, сможет ли агент в длительной задаче помнить предшествующую работу.
Параллельный запуск соседних инструментов только для чтения. Когда модель за один ход вызывает чтение файла, поиск по файлам и веб-поиск — несколько независимых инструментов только для чтения, — движок объединяет соседние совместимые вызовы в параллельную группу. Инструменты записи служат естественными барьерами и сохраняют заданный порядок. Вызовы и результаты фиксируются строго в объявленном порядке, поэтому параллельность не нарушает протокол. Самые частые операции чтения сразу становятся параллельными, и общее время группы заметно сокращается.
Чтение перед записью и оптимистический контроль конкурентного доступа. Перед редактированием файл необходимо прочитать. Движок фиксирует базовое состояние прочитанного файла и при редактировании проверяет, не изменилось ли оно. Если несколько исполнителей одновременно меняют один файл, проигравший получает понятную ошибку об устаревшем состоянии, а не молча затирает чужие изменения. При параллельной работе в одном пространстве эта защита необходима.
Немедленное включение уточнений во время работы. Если пользователь добавляет сообщение в процессе работы агента, движок включает его из очереди во входные данные текущего хода на границе цикла инструментов, а не откладывает до отдельного хода. Так корректировка курса во время выполнения становится естественным взаимодействием.
Обнаружение зацикливания. Когда один и тот же вызов инструмента повторяется подряд, движок сначала подсказывает остановиться (на 3-м повторе), затем принудительно останавливает (на 5-м). Любое отличие сигнатуры сбрасывает счётчик, поэтому допустимые вариации вроде пагинации или опроса не вызывают ложных срабатываний. Застрявшая модель больше не расходует токены молча.
Отмена жёсткого ограничения вывода основного хода. Вывод основного хода больше не ограничен малым лимитом, поэтому длинные отчёты и большие правки не обрезаются незаметно; вспомогательные вызовы для сжатия и рефлексии по-прежнему используют небольшой лимит.

Есть одна весьма «локальная» деталь: оценка токенов в смешанном китайско-английском тексте. Универсальная оценка занижает объём полностью китайского диалога в два-три раза. Движок различает китайские и английские символы по классу, что делает порог сжатия надёжным. Универсальный SDK об этом за вас не подумает.

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

2. Модель всегда на связи: многослойная обёртка провайдеров

Цель слоя моделей умещается в одно предложение: что бы ни случилось с конкретным ключом, провайдером или сетью, текущий ход диалога пользователя должен сохраниться, если это вообще возможно. Для этого адаптер надстраивает над абстракцией провайдера несколько обёрток: ротацию, паузы, регистрацию и внешнюю адаптацию.

Самое важное решение — механизм ротации находится ниже исполнителя. Движок записывает сообщение пользователя в постоянную сессию до вызова провайдера. Если выполнять повторы и ротацию на уровне движка, пришлось бы либо повторно отправлять сообщение, либо реализовать откат сессии. Когда ротация находится ниже движка, сообщение записывается ровно один раз, а повтор с другим кандидатом полностью прозрачен для состояния сессии.

Решения механизма ротации также сдержанны и зависят от границы первого события содержимого:

Сбой до того, как модель выдаст содержательный вывод — текст или вызов инструмента: можно безопасно перейти к следующему кандидату;
После первого события содержимого ротация прекращается, а ошибка передаётся выше: модель могла уже выполнить полный ход, и повтор продублирует побочные эффекты.

Классификация ошибок определяет, менять кандидата, не менять или повторять вызов. Ошибки уровня аккаунта — ошибка авторизации, недостаточный баланс, ограничение частоты запросов, истёкшая подписка — включают паузу и ротацию; временные сетевые сбои, например сброс соединения, вызывают несколько повторов на месте без сохранения состояния и без паузы. Неверные запросы, ограничения контента и серверные ошибки 5xx, которые возникнут и с другим ключом, передаются дальше без ротации. Пауза — десятиминутная подсказка, хранящаяся только внутри процесса: это краткосрочный сигнал, который незачем записывать на диск при каждом сбое, а перезапуск процесса — подходящий момент для новой проверки.

Что касается списка провайдеров, рефакторинг сводит три вида источников к единой абстракции:

LLM под управлением Orkas: серверный прокси, готовый к работе после входа; сервер маршрутизирует запросы между текстовыми моделями и моделями изображений;
Собственный ключ: обычные крупные провайдеры больших моделей;
Внешние адаптеры прямого подключения: набор моделей, которым нужно прямое подключение или которые используют собственную оплату, вручную адаптированных к тому же интерфейсу провайдера.

Для верхних слоёв всё это выглядит как одна стабильная пара (provider, model) — ротация, паузы и внешняя адаптация скрыты внутри адаптера.

3. Групповой чат как оркестрация: от статического плана-DAG к Commander в цикле

Эта часть рефакторинга сильнее всего меняет образ мышления.

Старая модель — статическое планирование: модель сначала создаёт план/DAG, а исполнитель работает по графу. Новая модель полностью убирает граф и заменяет его динамической оркестрацией группового чата с участием Commander в цикле.

Её метафора — комната группового чата:

Агент Commander — ведущий комнаты, а не невидимое промежуточное ПО;
Агенты-исполнители — полноправные и равноправные участники комнаты;
Все взаимодействия — асинхронные сообщения, поступающие в очередь через единую шину сообщений (отдельного скрытого пути для параллельного распределения нет).

Распределение задач Commander — это не @somebody в обычном тексте: если LLM пишет @AgentA в теле ответа, это лишь Markdown из обучающих данных, которому нельзя доверять. Настоящий сигнал распределения — структурированный вызов инструмента, который после рефакторинга сводится к трём действиям с ясной семантикой:

dispatch_to — отправить агента выполнить задачу до конца и вернуть результат, который обобщит Commander. Несколько независимых задач могут выполняться параллельно.
run_worker — подзадача, которой управляет сам Commander, с синхронным возвратом результата. Анонимный исполнитель — невидимая пользователю «рука» Commander, а именованный — видимый специалист.
hand_off_to — передать диалог самому агенту; Commander отходит в сторону, и агент отвечает пользователю напрямую, без дополнительного обобщения в этом ходе.

Почему групповой чат, а не оркестратор или дерево субагентов

Групповой чат с несколькими агентами даёт преимущества, недоступные традиционному оркестратору или дереву субагентов:

Срезы видимости. Каждое сообщение добавляется только в срез тех, кому оно видно. При запуске агент-исполнитель воспроизводит лишь свой срез, поэтому большой вывод другого агента не загрязняет его контекст. Commander видит всё.
Минимум состояния. Основное состояние всей оркестрации — лишь «у кого сейчас слово» и лёгкий журнал задач. Без DAG и сложного конечного автомата.
Естественное воспроизведение и синхронизация. Сообщения естественно сортируются по времени, поэтому повторная загрузка и синхронизация между устройствами напрямую опираются на поток сообщений. Мобильная версия использует этот же поток для удалённого управления: все вычисления агентов выполняются на компьютере, а мобильное устройство лишь отображает копию и не нуждается в особом протоколе оркестрации.

На архитектурном разборе команда высказалась столь же прямо: шина группового чата с Commander в цикле и есть форма многоагентной работы Orkas; дополнительный параллельный путь распределения субагентов внутри процесса нарушил бы инвариант единственного пути распределения через групповой чат.

Новое в этой версии: интерактивная передача диалога

Новейшее дополнение этого направления — интерактивная передача диалога агенту.

Проблема конкретна: агент-«репетитор» обучает пользователя один ход, пользователь хочет задавать дополнительные вопросы, но система принудительно возвращает слово Commander, вынуждая пользователя снова обращаться через @ к этому агенту в каждой реплике.

Решение — право голоса под контролем сервера и адресат, выбранный моделью:

Право голоса становится постоянным полем состояния, сохраняется при повторной загрузке и через существующее событие изменения состояния автоматически синхронизируется со всеми клиентами — новый тип события не нужен.
После того как Commander с помощью hand_off_to передаст слово интерактивному агенту, последующие сообщения пользователя без @ направляются сразу этому агенту, пока агент сам не вернёт управление или пользователь не обратится к Commander.
Агент возвращает управление маркером <handback />; разбор строго проверяет настоящее совпадение, чтобы случайный <handback в обычном тексте не приняли за передачу управления.
Если при возврате управления в журнале есть незавершённые задачи, Commander подхватывает их и продолжает работу.

Заодно улучшено отображение — сообщения цикла Commander. Раньше последовательность «распределить → прочитать результат → снова распределить» внутри одного хода сливалась в одно сообщение, а при перезагрузке могла ещё и перескочить в конец. Рефакторинг разбивает ход на несколько сегментов по границам видимого распределения задач, каждый — отдельное сообщение с возрастающей временной меткой. Впервые пользователь видит цикл оркестрации Commander, и порядок после перезагрузки тоже верен.

Наконец, две сквозные страховки: групповое прерывание — единственный путь остановки всех участников (как только пользователь нажимает «Стоп», сигнал прерывания получают все исполнители, включая анонимных субисполнителей через резервное сопоставление); и уже упомянутая корректировка через прерывание, включающая уточнение пользователя во время работы в текущий ход.

4. От закрытого каталога к открытой платформе

Если первые три направления укрепляли фундамент, это открывает все двери и окна: превращает Orkas из закрытого каталога в открытую платформу, не уступая ни пяди на границе безопасности.

Рефакторинг последовательно устранил несколько закрытых узких мест:

Внешние пакеты. Пользователь указывает адрес репозитория, и Orkas размещает его локально, клонируя без изменений в папку: без нормализации, переписывания и облачной синхронизации, поскольку там есть каталоги сторонних зависимостей. Отдельный инструмент командной строки управляет установкой, обновлением, запуском и остановкой, определяет, является ли пакет навыком с файлом описания или CLI с исполняемой точкой входа, и записывает метаданные в реестр за пределами каталога пакета, чтобы последующие обновления через pull не конфликтовали. Зависимости устанавливаются через двухэтапное подтверждение «спросить один раз и запомнить»; для исполняемых точек входа создаются обёртки, добавляемые в PATH инструмента bash, чтобы модель могла напрямую вызывать сторонние CLI.
Загрузка навыков из нескольких корневых каталогов. Единая точка запуска навыков вместо двух корней теперь распознаёт четыре уровня — пользовательские, маркетплейс, внешний пакет, глобальные — с разрешением по приоритету. Скрипты внешнего пакета предпочитают его собственную среду зависимостей. Это узкое место с самым высоким риском регрессий, поэтому оно покрыто полной матрицей тестовых фикстур.
Совместимость глобальных навыков. Orkas напрямую читает глобальные каталоги навыков, которые другие агентские инструменты уже поддерживают на компьютере пользователя. Так достигается совместимость на уровне навыков: накопленный в другом инструменте навык доступен и в Orkas. Само помещение навыка пользователем в эти каталоги считается разрешением, поэтому возможность включена по умолчанию, но общий выключатель сохранён. Описания сторонних навыков — недоверенная поверхность для внедрения инструкций, поэтому они проходят через загрузчик открытого уровня, видны только Commander и структурно не могут попасть в список разрешённых навыков агента.
Пользовательский MCP. Коннекторы больше не ограничены жёстко заданным каталогом. Пользователь может добавить любой MCP-сервер: удалённый по HTTP с низким риском или локальный подпроцесс с высоким. Форма сама служит местом выражения согласия: введённая вручную команда показана без изменений. Конфигурация транспорта, включая секреты, целиком хранится в зашифрованном виде, а пользовательские экземпляры всегда имеют фиксированный префикс и не могут выдавать себя за официальный коннектор каталога.
Обратный мост: внешние агенты на компьютере тоже получают доступ к Orkas. Это самая интересная часть. Раньше установленные на компьютере внешние агентские инструменты были для Orkas чёрным ящиком. Теперь при их запуске Orkas внедряет канал-мост, через который они могут в обратном направлении просматривать, читать и запускать навыки Orkas, вызывать коннекторы и искать в базе знаний. Мост работает по локальному межпроцессному каналу, не открывая сетевой порт, и использует одноразовые учётные данные, уникальные для каждого запуска и уничтожаемые сразу после его окончания. Каждый вызов коннектора с внешним побочным эффектом проходит через диалог подтверждения пользователя: вместо эвристической оценки чтения и записи по имени инструмента, которая была бы слишком мягкой, требуется одно подтверждение на пару «агент, коннектор» с возможностью «всегда разрешать».
Программирование для редких задач. В дереве решений Commander появляется ветвь: если подходящего агента, навыка или коннектора нет, оценить возможность решить задачу напрямую через bash и короткий скрипт, выполнить её в этом ходе, проверить результат и при желании предложить оформить решение в пользовательский навык. Для этого доступны фоновое выполнение bash — длительные задачи отделяются от текущего хода, журналы пишутся в файл — и каталоги, к которым пользователь дал доступ.

Открытость без отказа от контроля

Открывая двери и окна, больше всего боишься сквозняка. Принцип этого рефакторинга: ни одна контролируемая точка запуска опасных действий не меняется. MCP запускается ровно в одном месте, навыки выполняются через одного исполнителя, а bash — через одного исполнителя в песочнице. Поверх этого добавлено несколько уровней защиты:

Файловые операции всегда проходят через песочницу путей: рабочее пространство, текущие вложения и явно разрешённые пользователем каталоги. При этом доступ к каталогам учётных данных, системным каталогам и собственным каталогам Orkas предоставить нельзя;
Опасные команды bash — вывод данных наружу, разрушительное удаление, повышение привилегий, чувствительные пути — требуют подтверждения разрешения с выбором «только сейчас / на этот запуск / запретить». В журнал попадают только категория и длина, никогда не текст команды;
Установка внешних пакетов по принципу безопасного отказа полностью отклоняет пакеты с символическими ссылками, чтобы через них нельзя было включить в доступную область чувствительные файлы за пределами песочницы; источник клонирования ограничен списком разрешённых протоколов;
Все транспортные настройки с учётными данными и секреты зашифрованы при хранении, а учётные данные моста изолированы для каждого запуска;
Дистрибутив с открытым кодом и размещаемый дистрибутив удаляют возможности, доступные только хосту, по правилу усечения.

Одним предложением: каждое явное действие пользователя — установка, выдача доступа, отправка формы, нажатие подтверждения — служит свидетельством согласия, и каждое согласие ограничено соответствующей ему областью.

5. Умнее от сессии к сессии: память и саморазвитие

При обновлении фундамента переработали и две подсистемы, которые делают агента умнее по мере использования. Обе следуют одной инженерной дисциплине: выключены по умолчанию, ограничены, наблюдаемы.

Память между сессиями использует гибридный поиск: векторный семантический и по ключевым словам BM25 объединяются через RRF, слияние по обратным рангам, чтобы не зависеть от слабостей одного канала. Данные хранятся локально с полнотекстовым индексом. Есть два вида памяти — собственные заметки агента и профиль предпочтений пользователя. Для каждого задан лимит символов, перед записью выполняется проверка на внедрение инструкций, а в начале каждого хода память вставляется в неизменном виде в системный промпт. Вся система памяти нужна только для лучшего понимания текущего пользователя; данные всегда остаются локальными, и пользователь может в любой момент просмотреть, изменить и экспортировать их в настройках.

Саморазвитие — это личная библиотека навыков агента, хранящаяся отдельно от общей библиотеки платформы, и слой метакогнитивной рефлексии. Движок решает, нужна ли рефлексия, по набору взвешенных сигналов: исправление пользователя с наибольшим весом, восстановление после нетривиальной ошибки, сложность задачи, проявление или преодоление известной слабости, неэффективность навыка… Рефлексия запускается, только когда сумма взвешенных сигналов превышает порог. Сама рефлексия — периодическая фоновая задача примерно раз в 12 часов, с паузой в несколько часов и резервным интервалом в несколько дней. Недорогая малая модель читает сводку недавних действий и решает, создавать или исправлять навык и обновлять ли «профиль компетенций» агента.

Главное с точки зрения безопасности: саморазвитие включается только для сессий с явно привязанным агентом — обычная сессия Commander не развивается. Для рефлексии действует двойное ограничение токенов — по числу и суммарному объёму; сбой одного агента не блокирует остальных, а стоимость запуска сведена к минимуму. Сделать агента умнее, но не дать ему выйти из-под контроля.

Инженерная философия: оправданную сложность не стоит упрощать

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

Несколько стратегий слияния в движке синхронизации, собственный цикл агента, многослойная обёртка провайдеров, граница мобильного удалённого управления — всё это выглядит сложно, но каждый слой оправдан: согласованность между устройствами в конечном счёте, глубокая интеграция, ротация ключей, границы клиентов, определённые продуктом. Принудительное упрощение лишь приведёт к потере данных и размоет слои.
Менять действительно следует «модули-боги» и локальное дублирование: выносить чистые функции без состояния из раздутой шины группового чата — сборку промптов, инструменты Commander, ход CLI — и объединять несколько копий шаблона диалога подтверждения в один общий компонент.

Такие решения опираются на строгие правила из документа ограничений проекта: границы — единый процесс, IPC как единственный путь, только динамическая загрузка среды выполнения; слои — направление зависимостей каждого; единый источник истины — категории, таксономия телеметрии, домены; обязательный аудит промптов для каждого коммита, который их затрагивает. Перестроить фундамент без обрушения позволяет не хитроумный дизайн, а постоянное соблюдение этих инвариантов.

В завершение

Вместе четыре направления дают Orkas новый фундамент агента: под собственным контролем, независимый от провайдера, с динамической оркестрацией, открытый внешнему миру и способный к саморазвитию:

Двухслойная среда выполнения «движок/адаптер» внутри процесса, которая встраивает в настольное приложение полный набор сильных сторон агента для программирования — работу с файлами, локальный поиск, системные инструменты, параллельных исполнителей, решение длительных задач — и доводит каждую до готовности к эксплуатации;
Многослойный слой моделей, который по возможности сохраняет диалог при проблемах с ключом, провайдером или сетью;
Оркестрация нескольких агентов в формате группового чата с Commander в цикле, заменяющая статическое планирование динамическими решениями и впервые делающая передачу диалога между агентами естественной;
Экосистема, переходящая от закрытого каталога к открытой платформе: внешние пакеты, глобальные навыки, пользовательский MCP и обратный мост открыты, а контролируемые точки запуска остались неизменными;
И память с саморазвитием, выключенные по умолчанию, ограниченные и наблюдаемые.

Функции можно добавлять по одной, но фундамент стоит основательно перестраивать только один раз. После этого всё новое поверх него строится быстрее — именно к такому результату и стремился этот рефакторинг.