Воркеры и Intelligence Layer

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

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

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

Каноническая библиотека пресетов (12)

Все presets живут в config/workers_registry.json и доступны через GET /api/crm/workers/presets. Каждый — generic template для любого проекта: никаких brand references, никаких имён персонажей, никаких ссылок на нашу инфраструктуру.

Engineering / Core (6):

Startup operations (6, добавлены в Phase 66):

Создание воркера в проекте

Через UI (default): клик + Add в pill bar WorkerSelector → открывается WorkerCreationWizard с 3 шагами:

1. Identity — выбор preset-карточки ИЛИ "From scratch"
2. Capabilities — model + tools + smart warnings (напр. "read-only роль + Write tool = misconfig")
3. Instructions — system prompt + выбор скилов + live preview

Wizard авто-инжектит SYSTEM_PROTOCOL baseline (см. ниже) — preset фокусируется только на role-specific экспертизе.

Через CLI / API: POST /api/crm/projects/:name/workers с полным body (legacy-форма, ссылка "Show advanced form →" в wizard).

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

• 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
}

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

SYSTEM_PROTOCOL — Baseline для всех воркеров

Пока worker.system_prompt определяет role-specific экспертизу (analyst делает TAM/SAM/SOM, sentinel делает SQL injection audit), есть 15 cross-cutting правил, которым должен следовать любой воркер — от developer до pitch-coach. Вместо дублирования в каждом preset они живут в одной константе (shared/cli-routes.ts:SYSTEM_PROTOCOL) и auto-injected при каждом worker spawn через child-bot/claude-runner.ts.

5 правил Mandatory Workflow

1. Every new task MUST be registered via arc issue create
2. Any plan change MUST update ROADMAP.md via arc roadmap sync
3. Before starting work, read ROADMAP.md + open issues (arc issues)
4. After significant changes, sync knowledge via arc memory refresh
5. Log meaningful progress on issues via arc issue log <id> "<text>"

10 правил Quality Baseline (#229)

6. Priorities: P0 > P1 > P2 > P3 — always know what's next and why
7. Session report: close meaningful work with arc report --summary
8. Definition of Done includes documentation, not just commit
9. Trade-offs explicit: scope vs deadline vs quality — recommend one path + 1-2 alternatives
10. Format: concise, tables/numbers where possible, actionable beats descriptive
11. Cite sources for any fact/number; "I don't know" beats fabrication
12. No silent failures: state blockers explicitly, don't continue down wrong path
13. Honest progress: report what actually shipped (done vs attempted vs failed)
14. Convention over invention: follow existing patterns, explain deviations
15. Learnings feedback loop: append to learnings.md when corrected on recurring mistake

Эффект

Благодаря этой автоматической инъекции preset-ы стали на 50-70% короче. Пример: product-owner упал с 733 до 404 символов — осталась только "User-first lens" (специфичная рамка), остальное (priorities/roadmap/issues/DoD/trade-offs) теперь baseline.

Админы могут расширить baseline в shared/cli-routes.ts — изменение автоматически применится для всех воркеров при следующем spawn.

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
    }
  ]
}

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