Воркеры и Intelligence Layer

Arc OS использует систему воркеров для распределения задач между специализированными AI-агентами, а Intelligence Layer обеспечивает качество их ответов через четыре модуля: Binary Evals, Context Router, Learnings и Karpathy Loop.

Система воркеров

Каждый воркер — это отдельный AI-агент с определённой ролью, моделью и набором инструментов. Воркеры работают в рамках проекта и доступны через Workspace UI или Telegram-команды (/c, /d, /w:worker_id).

Встроенные воркеры

Типы воркеров

• chat — turn-based разговор с полной историей контекста. Воркер получает всю предыдущую переписку и отвечает как собеседник.
• terminal — streaming выполнение с tool events. Воркер работает как терминальная сессия, выполняя инструменты последовательно и транслируя прогресс в реальном времени.

Создание кастомного воркера

Кастомные воркеры описываются в файле config/workers_registry.json. Каждая запись определяет поведение агента:

{
  "id": "my-worker",
  "label": "My Worker",
  "icon": "🔧",
  "type": "chat",
  "model": "claude-sonnet-4-5",
  "max_turns": 10,
  "tools": ["Read", "Glob", "Grep"],
  "system_prompt": "You are...",
  "focus_dirs": ["src/"],
  "builtin": false
}

Поля конфигурации

Binary Evals — Валидация ответов

Что это?

Декларативные правила проверки качества ответов воркеров. Каждое правило — детерминированное (без AI), работает мгновенно и не блокирует ответ. Результаты имеют severity warning или info — они информируют, а не останавливают.

6 типов правил

Формат файла evals

Файл размещается рядом со скилом: skills/{skill_name}/{skill_name}.evals.json

{
  "version": 1,
  "skill": "code-review",
  "rules": [
    {
      "id": "cr-001",
      "name": "Must return JSON verdict",
      "type": "string_contains",
      "value": "\"verdict\"",
      "severity": "warning"
    }
  ]
}

Каждое правило имеет уникальный id, человекочитаемый name, один из 6 типов, value для сравнения и severity (warning или info).

Context Router — Автоподбор скилов

Как работает?

При каждом сообщении Context Router скорит все скилы из skills/_registry.json и автоматически подбирает наиболее релевантные:

1. Trigger match (+2 балла) — прямое вхождение слова-тригера из сообщения
2. Keyword match (+1 балл) — семантическая близость по ключевым словам
3. Top-5 по сумме баллов injected как SKILLS_HINT в промпт воркера

Пример

Сообщение: "review the git commit for security"

• code-review: trigger "review" найден → +2 балла
• git-manager: keyword "commit" найден → +1 балл
• Результат: code-review (2), git-manager (1) injected в промпт

Формат реестра скилов

{
  "name": "code-review",
  "triggers": ["review", "audit", "security"],
  "keywords": ["vulnerability", "OWASP", "XSS"],
  "agents": ["summer"],
  "category": ["complex"]
}

• triggers — слова, точно указывающие на скил (высокий приоритет)
• keywords — дополнительные термины для семантической связи
• agents — какие воркеры могут использовать этот скил
• category — классификация (simple, complex, critical)

Learnings — Память коррекций

Как создаются?

Learnings — это accumulated правила, возникающие из обратной связи:

1. Thumbs-down (👎) — автоматически создаётся learning с source "negative" на основе проблемного ответа
2. Fix It — повторный запуск задачи генерирует learning с source "fixit"
3. Ручные — архитектурные решения и правила, source "manual" или "architecture"

Формат файла

Файл learnings.md в корне проекта:

# Learnings
> Auto-generated. Injected into GSD prompt at session start.

## Rules
- [2026-04-03T20:00:00Z] [architecture] Rule text here...
- [2026-04-04T10:00:00Z] [security] Another rule...

Как используются?

• Загружаются при старте каждой сессии воркера
• Injected в GSD-промпт Developer (бюджет — 2000 символов)
• Новейшие правила — первыми (приоритет по времени)
• Действуют как иммунная память — ошибки, совершённые однажды, не повторяются в следующих сессиях

Karpathy Loop — Ночное самосовершенствование

Автоматический цикл улучшения скилов, вдохновлённый идеями Андрея Карпатого об iterative self-improvement.

Как работает?

Каждую ночь в 3:00 UTC запускается автоматический pipeline:

1. Сбор метрик — считывает quality-metrics.json каждого проекта
2. Поиск проблемных скилов — фильтрует скилы с success rate < 80% или количеством negative > positive feedback
3. Sage анализ — Haiku генерирует улучшенную версию скила на основе собранных ошибок
4. Blind A/B тест — 3 сценария, рандомизированный порядок, dual scoring:
   • Eval rules (60% веса) + LLM judge (40% веса)
5. Создание PR — если новая версия побеждает (new_wins > old_wins), создаётся pull request
6. Отчёт CEO — результаты отправляются в Telegram для финального решения

Метрики качества

Каждый проект накапливает статистику в quality-metrics.json:

{
  "total_invocations": 42,
  "total_successes": 40,
  "total_feedback_positive": 35,
  "total_feedback_negative": 2,
  "avg_duration_ms": 15000,
  "skills": [
    {
      "name": "code-review",
      "applied_count": 5,
      "success_count": 4
    }
  ]
}

Эти метрики позволяют системе объективно определять, какие скилы требуют улучшения, и отслеживать прогресс после обновлений.