Enterprise Application Intelligence · Агентная платформа построения корпоративных приложений
Космос вмещает все орудия — каждое орудие создаётся по мере
Интеллект — осязаемым, приложения — надёжными: то, что строит ИИ, видно, а каждая поставленная система выдерживает измерение и проверку.
Вы описываете бизнес-требования — платформа AliothStudio строит систему. Hangzhou Yuqi Technology ограничивает своих агентов собственной онтологической моделью данных Alioth и однократно замораживает структуру базы данных через цепочку выпуска модели (агенты никогда не пишут DDL) и детерминированно производит на этой замороженной модели backend-API, определения типов и пользовательский интерфейс — в поставку идёт не демо, которое «выглядит рабочим», а корпоративные приложения, проверенные 229 гейтами качества и готовые к продакшену.
Модель открыта на GitHub: github.com/CosmicTools9/Alioth · Последняя версия v10.0.44(2026-10-19)
Solutions
Что мы решаем для вас
Три типичных дилеммы построения корпоративных приложений — и ответ Yuqi на каждую.
Агенты общего назначения генерируют системы, которые «выглядят готовыми, но не работают»
LLM выдумывает несуществующие таблицы, поля, API и бизнес-правила; результат выглядит завершённым, но не работает — а жёсткие требования корпоративных приложений к точности оставляют большинство ИИ-инструментов на стадии демо.
Наш ответ:ограничить агента замороженной онтологической моделью — каждый структурный артефакт обязан наследственно позиционироваться внутри 645 онтологических семантических координат и поле за полем соответствовать машиночитаемым контрактам; галлюцинации обнаруживаются и отклоняются на этапе сборки.
Системы, собранные из форм, не поспевают за изменениями бизнеса
Традиционные low-code платформы собирают формы: структуры дублируются обходными путями, семантики разъезжаются; стоит бизнесу измениться — система тонет в болоте, где каждая починка ломает три других места.
Наш ответ:онтологическое управление — сначала мир бизнеса точно описывается математизированным онтологическим языком; изменение бизнеса есть изменение модели, и система эволюционирует вместе с бизнесом, а не латается поверх старого кода.
Бизнес-система строится месяцами, а требования ждать не могут
Проектирование базы данных, backend-API и пользовательский интерфейс идут разрозненно, интеграция и доработки накапливаются слой за слоем — к моменту поставки бизнес-требования, как правило, уже изменились.
Наш ответ:структуру данных однократно замораживает цепочка выпуска модели, физически отделённая от цепочки сборки; агентный конвейер производит только backend-API, определения типов и пользовательский интерфейс — прикладной слой генерируется целиком, без единого DDL и без патчей модели.
Proven in Production
Уже работает в этих отраслях
Одна и та же модель Alioth и платформа AliothStudio уже работают как продуктивные системы в 6 пространствах имён — 15 приложений, 61 модуль, 293 блока, 82 сервиса (шестое пространство MAT подключается), покрывающих всю цепочку: от запроса до расчёта и от поручения до выставления счетов.
Интегрированная система управления заказами и финансами внешнеторгового швейного производства
Охватывает 18 бизнес-сценариев — обзор операций, клиентские запросы, коммерческие предложения, заказы, спецификации (BOM), закупки, образцы, производство, контроль качества, отгрузку, документы, дебиторку/кредиторку, ageing, курсы валют, себестоимость, прибыль, экспортное возмещение налогов, авансовые отчёты, права и настройки — связывая всю цепочку «запрос → отгрузка → расчёт».
Система управления логистическими и транспортными операциями
Четыре модуля — контрактная логистика, исполнение перевозок, взаиморасчёты по доходам и по обязательствам — со встроенной внешней цепочкой сотрудничества «клиент ↔ платформа ↔ перевозчик» и механизмом фиксации арбитражных решений; единое управление накладными, траекториями, геозонами, расчётами и выставлением счетов.
Платформа управления системной НИОКР и лётной годностью
Для клиентов авиапрома: управление системной НИОКР, потоки согласований и модули соответствия требованиям лётной годности, с онтологическим моделированием инженеров, меток компетенций, ролей согласования и комитетов по управлению изменениями (CCB).
Мастер-данные и бюджетное управление НИОКР-проектов
Реестры НИОКР-проектов, присвоение и замена номеров исследовательских заказов с аудиторским следом, многомерное тегирование проектов, версионирование архивов инициации, зависимости проектов и отношения переноса средств, связка планов бюджетного домена — ноль избыточных таблиц, всё привязано к единой структуре модели.
How It Works
Как платформа работает для вас
Вам достаточно сформулировать бизнес-требования — остальное делает агент построения корпоративных приложений AliothStudio. Платформа состоит из двух независимых цепочек: цепочка релиза модели производит фундамент данных, цепочка построения приложений собирает ваше бизнес-приложение на замороженном фундаменте.
Сам фундамент данных обслуживается независимой цепочкой релиза модели (единственный канал структуры), и агент не использует DDL на всём протяжении цепочки построения — система, которую вы получаете, всегда привязана к одной и той же замороженной модели:
Платформа метаданных
Центр управления полным жизненным циклом модели. Все структурные изменения попадают в конвейер релиза только после ручной проверки; встроенные генератор и рантайм агентов автоматически компилируют бизнес-требования в конфигурацию приложения и код.
Единая точка входа
Единый рантайм бизнес-приложений: автоматически обнаруживает приложения и загружает расширения (ограничения / правила / автоматы состояний / рабочие потоки) с единой авторизацией. Каждая отраслевая система компилируется и развёртывается независимо, не влияя на другие.
Единый вход
Независимо развёртываемый единый сервис аутентификации; все приложения разделяют одну цепочку идентичности — один вход везде.
Портал совместной работы
Каркас портала для внешних участников сотрудничества — клиентов и поставщиков; включается по требованию и развёртывается независимо, разделяя с внутренними системами единый фундамент данных.
Reliability
Почему надёжно: освобождение агентов от галлюцинаций LLM
Крупнейший инженерный риск разработки на агентах общего назначения — галлюцинации LLM: модель выдумывает несуществующие таблицы, поля, API и бизнес-правила, производя артефакты, которые выглядят завершёнными, но не работают. Ответ Yuqi — ограничить агента онтологической моделью: LLM выполняет лишь понимание требований и онтологическое отображение; каждый структурный артефакт обязан наследственно позиционироваться внутри замороженного онтологического пространства и быть привязанным к машиночитаемым контрактам. Под двойным давлением математической структуры и инженерных гейтов галлюцинациям негде закрепиться — что отвечает жёстким требованиям корпоративных приложений к точности и надёжности.
Только наследовать для позиционирования — никогда не выдумывать
Структурные действия агента замкнуты в онтологическом пространстве замороженной схемы isahl: расширение может лишь наследовать по нижнему конусу порядка DAG и привязывать трёхмерные онтологические координаты, назначаемые триггерным механизмом, а не придумываемые моделью — LLM не может изобрести несуществующие таблицы и поля, а новые отрасли подключаются с нулём DDL и нулём патчей модели.
Артефакты выравниваются по контрактам релизного пакета
Релизные пакеты Alioth/v* несут машиночитаемые контракты и отчёты верификации; каждый артефакт агента — модуль, Block, Service, app.json — обязан поле за полем соответствовать контракту. Любая выдуманная ссылка (висячий service, несуществующая координата) обнаруживается и отклоняется уже на этапе сборки.
229 механически проверяемых гейтов
Весь путь от требования до развёртывания охраняют 229 зарегистрированных гейтов на всей цепочке (137 на стадии commit / 92 на стадии push): законность онтологических семантических координат, целостность структурных ссылок, прохождение компиляции и тестов — всё решено машиной, без опоры на внимательность рецензентов и на уверенность модели. Галлюцинированные артефакты не могут пройти гейты в продакшен.
LLM не генерирует исполняемый код
Бизнес-логика времени исполнения детерминированно производится генератором alioth-gen из онтологической конфигурации (API, типы, интерфейс — без DDL: изменения структуры проходят только через цепочку выпуска модели); инварианты теоретического ядра дополнительно машинно доказаны в Lean 4 (ноль sorry — жёсткий критерий push-гейта). LLM делает лишь то, что умеет, — понимание требований и выбор отображений, — а точность подкреплена структурой и доказательством.
Get Started
Как начать
Четыре входа — от практики к глубине: попробуйте онлайн, следуйте руководству, прочтите теорию или проверьте код — каждое обещание вы можете верифицировать сами.
SaaS-версия для обучения
cosmic-tools.shop предоставляет онлайн SaaS-версию AliothStudio для обучения — облегчённое развёртывание для индивидуальных пользователей с полностью рабочими базовым моделированием, сборкой приложений и исполняемыми потоками; локальная среда не нужна, чтобы следовать Синей книге на практике.
Синяя книга построения
«Руководство по построению приложений AliothStudio»: полный операционный путь — от подготовки среды, центра моделей, рабочих потоков AppAgent и железных правил разработки модулей и Service до сборки, развёртывания и краткого справочника 229 гейтов качества.
Теоретическая белая книга
«Белая книга теории модели Alioth»: математические основания онтологии обмена — коммутативная категория и группоидная симметрия, координатное пространство-произведение, полнота пяти доменов, меры сохранения, теоретико-модельная валидация на множестве пространств имён и машинные Lean-доказательства пяти ключевых метатеорем.
Верификация открытого кода на GitHub
Ключевая модель открыта на CosmicTools9/Alioth (PLpgSQL · MIT): последняя версия v10.0.44 (2026-10-19) содержит 1022 наследуемых таблиц + 268 сид-таблиц, каждый релиз верифицируется полной пересборкой в выделенной валидационной базе — каждому математическому свойству, утверждённому в белой книге, соответствуют структурное определение и ограничение в репозитории.
Генератор приложений CosmicTools9/dsh-alioth (TypeScript): пользователь описывает приложение в диалоге, а фреймворк через детерминированный программный конвейер производит импортируемые в AliothStudio артефакты — LLM лишь поставляет структурированные параметры и семантические решения, никогда не генерируя текст артефактов. Это проверяемая реализация обещания «без галлюцинаций LLM».
Technology
Технические возможности
| Возможность | Описание |
|---|---|
| Детальная авторизация NGAC | Модель авторизации на DAG по международному стандарту NGAC (ANSI/INCITS 565-2022): мультитенантная изоляция классами политик, иерархическое наследование атрибутов пользователей/объектов, ассоциативные разрешения и запреты (отрицательное разрешение приоритетно), полный аудит изменений политик. |
| Интеллектуальная маршрутизация запросов SQL / AGE | Бэкенд автоматически выбирает между реляционными и графовыми запросами: высокочастотные проверки прав идут через SQL (1–2 мс), многошаговые обходы и кратчайшие пути — через графовый движок Apache AGE. Реляционные таблицы — единственный источник истины; AGE — необязательный ускоряющий слой. |
| ИИ-генерация приложений | Рантайм AppAgent автоматом состояний ведёт автоматизированную цепочку «требование → прототип → онтологическое отображение → артефакты модуля / Block / Service»; конвейер инъекции знаний EmpAgent обеспечивает симметричную полноту предметных знаний. |
| Формальная верификация Lean 4 | Инварианты теоретического ядра (сохранение стоимости, структурность инволюции, завершаемость и корректность пополнения, разрешимость полноты пяти доменов) машинно доказаны в Lean 4; ноль sorry — жёсткий критерий push-гейта: математическая корректность проверяется доказывателем, а не подтверждается рецензией. |
| Распределённая идентичность и аудит | Бизнес-данные используют распределённые уникальные ID (zuid); все операции попадают в независимую схему аудита, что вместе с моделью транзакционной симметрии обеспечивает сквозную прослеживаемость. |
| Интегрированная цепочка релиза | Артефакты генерации Meta → сборка пространства имён → релизный пакет развёртывания (бинарник + DDL + docker-compose + эксплуатационные скрипты); шлюз автоматически перезапускается на продуктивной фазе, процесс релиза замкнут и откатываем. |
| Современный технологический стек | Бэкенд на Rust (высокая производительность, безопасность памяти); фронтенд на React + TypeScript; база данных PostgreSQL + графовое расширение Apache AGE; инженерия на модульном монолите pnpm / Cargo workspace. |
Theory
Теоретическая основа: онтологическая модель данных Alioth
Почему эта модель может ограничивать агента? Потому что Alioth — корпоративный фреймворк онтологического моделирования данных, построенный на теории категорий и принципе симметрии: экономическое поведение формализуется как морфизмы в категории обмена, обратимые транзакции образуют кор-группоид (core groupoid), а симметрия строго характеризуется инволютивным эндофунктором — у каждой транзакции существует единственная зеркальная обратная транзакция, что гарантирует сохранение стоимости и структурную целостность. Все математические инварианты привязаны к инженерным гейтам, а ключевые теоремы машинно доказаны в Lean 4. Модель открыта: github.com/CosmicTools9/Alioth.
Категория / группоид / инволютивный эндофунктор
Транзакции — морфизмы в категории обмена 𝓔; обратимые транзакции образуют кор-группоид core(𝓔); симметрия = инволютивный эндофунктор S : core(𝓔) → core(𝓔)ᵒᵖ, S² = id. Инженерное следствие — зеркальная транзакция существует единственным образом, а сохранение стоимости засвидетельствовано по каждой проводке: каждый ордер содержит начальное и конечное сальдо, так что «предсостояние + чистое изменение = постсостояние» механически проверяется построчно.
Произведение категорий / координатный функтор
Координатный функтор χ = (dk_scene, dk_factor, dk_function) размещает каждую бизнес-сущность в единственной точке произведения категорий S × F × U: три измерения ортогональны, принимают значения независимо и эволюционируют независимо; коды измерений — иерархические адреса, назначаемые триггерным механизмом, а не человеческим соглашением.
Частичный порядок DAG / реляционная алгебра / span
Иерархия наследования — направленный ациклический частичный порядок (484 подтаблицы, 374 листовые таблицы); расширение может расти только по нижнему конусу порядка, обходное дублирование запрещено. Семейства отношений r_* / rr_* соответствуют функциональным отношениям и span'ам (1:N / M:N); композиция отношений — это композиция морфизмов, а иерархические отношения охраняются инвариантами ацикличности.
Знаковая мера / аддитивность
Запасы и сальдо — не атрибуты сущностей, а аддитивные знаковые меры над фактами ордеров — вычисляемые, а не хранимые. Инвентаризация — атомарное событие коррекции меры; излишки и недостачи поглощаются и калибруются как нормальная погрешность измерения, а не скрываются.
Снимок 4-арности
Разрез любой транзакции вдоль её жизненного цикла даёт онтологическую 4-ку: Сцена Scene (где и когда), Фактор Factor (кто и что), Функция Function (как), Статус Status (однонаправленное дискретное логическое время). Три ортогональных кода образуют разбираемое онтологическое пространство.
Полнота 5 доменов
Каждый снимок 4-арности обязан покрывать Люди L / Тара C / Товар G / Место P / Финансы F — пять доменов транзакций, симметрия не должна нарушаться, что гарантирует замкнутость бизнеса на уровне модели: кто торгует, в чём переносится, чем торгуют, где это происходит и как движется стоимость.
Зеркальная инволюция event / task
Ось времени разделена «сейчас» на две половины: уже случившиеся events (факты прошлого) и ещё не случившиеся tasks (будущие задачи) зеркальны друг другу; завершение задачи переворачивает срез. Планы разворачиваются в обе стороны через двойные мосты — событийное и задачное управление суть два временных направления одной модели привода.
Валидация модели на множестве пространств имён
С точки зрения теории моделей: модель isahl — это теория 𝕋, а каждое отраслевое развёртывание — модель ℳ ⊨ 𝕋. Одна теория уже несёт 6 пространств имён, 15 приложений, 61 модуль, 82 сервиса, 645 онтологических семантических координат — подключение новой отрасли требует нуля DDL и нуля патчей модели: только наследственное позиционирование и привязка координат.
About
О компании
Hangzhou Yuqi Technology Co., Ltd. — программная компания, специализирующаяся на агентах построения корпоративных приложений. С собственной моделью Alioth как теоретическим ядром и платформой AliothStudio как инженерной основой компания поставляет сквозные решения — от модели данных до полной бизнес-системы — для отраслей: внешнеторговое производство, логистика и перевозки, авиационная лётная годность, управление научными исследованиями.
В отличие от традиционных low-code платформ, собирающих формы, путь Yuqi — онтологическое управление + построение агентами: сначала мир бизнеса точно описывается математизированным онтологическим языком, структуру базы данных замораживает цепочка выпуска модели (DDL создаётся только там — агенты не касаются модели данных), после чего агентный конвейер производит backend-API, определения типов и пользовательский интерфейс на этой онтологии — изменение бизнеса есть изменение модели, и система эволюционирует вместе с бизнесом.
Происхождение названия · 名之由来
宇纳万器，器成有度
Космос вмещает все орудия; каждое орудие создаётся по мере.
Название «Yuqi» (Cosmic-Tools) восходит к этой строке: космос (宇) вмещает все орудия (器), и каждое орудие создаётся по мере. Это и наше инженерное кредо: вместить многообразие форм корпоративного бизнеса и поставлять системы, которые выдерживают измерение и проверку.
Build What's Next
Сложный бизнес —
система, способная развиваться вместе с ним.
Без локальной среды: пройдите полный цикл моделирования, сборки приложений и работы AliothStudio онлайн — по Синей книге постройте своё первое корпоративное приложение.
Войти в SaaS-версию для обучения →