8.5 KiB
Alicorn — архитектурные решения
Сводка ключевых архитектурных решений (ADR-формат). Основано на спецификации в Outline (ветка «autonom agent alikorn»).
1. Разделение «Модель предлагает — Runtime располагает»
Решение: LLM (Ornith) только предлагает план в типизированном DSL. Runtime (Rust) детерминированно исполняет.
Почему:
- LLM на локальной модели даёт 20–150 t/s, слабый контекст, частые ошибки. Интерпретация плана внутри LLM = удвоение этих проблем.
- Detерминированный runtime даёт скорость (без интерпретации) и точность (повторяемость).
Альтернативы:
- LangChain/CrewAI/AutoGen — предполагают облачную LLM (дешёвый контекст, редкие ошибки). Не подходят под локальные модели.
- Чистый ReAct внутри LLM — «задыхается» через 5–10 шагов.
Риски: DSL-ограниченность (модель не может делать всё что угодно, только то, что умеет runtime). Компромисс ради детерминизма.
2. Append-only журнал (SQLite WAL) как источник правды
Решение: Все входы/выходы (llm.request/response, tool.call/result, anvil.check) пишутся в append-only журнал. Состояние = свёртка журнала.
Почему:
- Event Sourcing даёт replay «байт-в-байт».
- Журнал = аудит и отладка.
- Именно журнал, а не промежуточные рассуждения (экономия, приватность).
Риски: размер журнала; нужна ротация/компрессия. FULL sync для durability (влияет на latency).
3. Детерминизм и replay
Решение: Состояние = детерминированная свёртка журнала через reducer. Replay верифицируется в CI. Exactly-once через Transactional Outbox + Idempotency Key + Saga.
Почему: локальные модели non-deterministic → без детерминированного executor'а нельзя гарантировать повторяемость.
Альтернативы:
- Хранение snapshot'ов состояния — дороже, сложно мержить.
- Pure functional state — сложно интегрировать с инструментами.
4. Pegas Memory: PostgreSQL + pgvector + Apache AGE
Решение: Единое хранилище — текст, векторы, граф, метаданные в Postgres.
Почему:
- pgvector = семантический поиск (检索增强).
- AGE = граф связей (сущности, концепты).
- Один движок вместо трёх БД.
Риски: AGE (PostgreSQL extension для графов) — молодая технология, зрелость ниже, чем у Neo4j.
Альтернативы:
- Отдельный граф-сервер (Neo4j) — больше инфраструктуры.
- Qdrant + отдельная graph DB — сложнее поддержка.
5. Anvil: экономика доверия через смарт-контракты
Решение: Агент начинает с минимальными правами. Успешное действие → +репутация → расширение прав. Контракты: PermissionRegistry, ReputationOracle, BudgetController, CuriosityReward.
Почему:
- Безопасность: агент не может сразу получить все права.
- Прозрачность: всё в блокчейне.
- Мотивация: curiosity как reward.
Риски: стоимость транзакций; сложность интеграции с локальным runtime.
Альтернативы:
- Hardcoded权限-система — проще, но не масштабируема.
- Policy-based (OPA) — не такой «экономический».
6. World Model (V-JEPA 2 / Agentic-JEPA)
Решение: Planner генерирует кандидатов → World Model предсказывает следующее состояние → агент выбирает с наивысшим сходством → верификация после выполнения.
Почему: локальные модели плохо планируют на много шагов вперёд. World Model даёт «представление о мире» без реального действия.
Меры надёжности:
- Планирование на один шаг (k=1).
- Калибровка доверия.
Риски: V-JEPA 2 — тяжёлая модель; локальный инференс может быть bottleneck.
Альтернативы:
- Chain-of-Thought — проще, но без «представления о мире».
- Реальные действия с откатом — дороже.
7. Pegas Core: Rust (dsh Harness)
Решение: Ядро на Rust. Роли: Planner (Ornith 1.5 A3B), Executor (Spark-X2.5-4B), Researcher (Nanbeige4.1-3B), Decision (Clef-Flash).
Почему:
- Rust = скорость + безопасность памяти + детерминизм.
- Разделение ролей = изоляция ошибок.
Альтернативы:
- Python (Hermes) — быстрее разработка, но медленнее и non-deterministic.
- Go — быстрее Python, но Rust лучше для системного кода.
8. Observability: OTEL + ClickHouse + Grafana
Решение: Трассировка, стоимость, качество через OpenTelemetry → ClickHouse → Grafana.
Почему:
- Наблюдаемость критична для автономного агента.
- ClickHouse = аналитика больших логов.
Альтернативы:
- Prometheus + Loki — сложнее агрегация.
- Локальные метрики — недостаточно для аудита.
9. MVP-стратегия
Решение: MVP = ReAct-цикл (Rust) + одна LLM (Ornith) + один MCP (Knowledge) + Postgres+pgvector (без AGE) + простой UI + heartbeat.
Что НЕ в MVP: мотивация/драйвы, Anvil, World Model, граф (AGE), мультиагентность, KTL, ClickHouse/Grafana, сложные метрики.
План: Нед 1 — ядро+LLM+журнал; Нед 2 — MCP+база знаний; Нед 3 — UI+heartbeat; Нед 4 — отладка+GitHub.
Почему: MVP должен доказать базовый цикл (задача → LLM → tool → ответ), а не всю архитектуру.
10. Связь с spark-mind (Animus)
Решение: spark-mind = первый слой Alicorn (чаты + память). Alicorn = полная архитектура.
Почему: spark-midal уже работает (персона, память, дашборд на :1337). Alicorn строится на этом фундаменте, но с детерминированным runtime'ом.
Риски: spark-mind non-deterministic (Python); Alicorn должен быть переписан на Rust.
Статус решений
| # | Решение | Статус |
|---|---|---|
| 1 | Model proposes — Runtime disposes | Принято |
| 2 | Append-only журнал | Принято |
| 3 | Детерминизм + replay | Принято |
| 4 | PostgreSQL + pgvector + AGE | Принято (AGE — риск зрелости) |
| 5 | Anvil: экономика доверия | Принято (для full-версии) |
| 6 | World Model (V-JEPA 2) | Принято (для full-версии) |
| 7 | Rust-ядро | Принято |
| 8 | Observability (OTEL+ClickHouse) | Принято (для full-версии) |
| 9 | MVP-стратегия | Принято |
| 10 | Связь с spark-mind | Принято |