Приклади / Мультиагент + знання

Навчальна кодинг-пара

AI-парний програміст, що стає розумнішим щоразу, коли ви ним користуєтесь.

learning_pair.toml

Проблема

Кожна coding-сесія з AI починається з нуля. Агент не пам'ятає, що ви будували вчора, які рішення ухвалювали і які патерни вже закріпили. Кожна сесія марнує час, заново відновлюючи той самий контекст.

Що, якби ваш AI-парний програміст пам'ятав кожне архітектурне рішення й ставав розумнішим з часом?

Конфіг

learning_pair.toml визначає кворум — мультиагентну систему з planner, який пам'ятає, і coder, який реалізує. Planner несе інструменти знань; coder несе інструменти редагування. Поділ відповідальності на рівні агентів.

Конфігурація кворуму

[quorum]
cwd = "."
db = "/tmp/learning_pair.db"   # Постійне сховище знань
delegation = true               # Увімкнути делегацію planner -> coder
verification = false
snapshot_policy = "diff"        # Відстежувати зміни файлів через git diff
delegation_wait_policy = "all"
max_parallel_delegations = 1

Planner: оркестратор, що несе знання

[planner]
provider = "anthropic"
model = "claude-sonnet-4-5-20250929"
tools = [
  "delegate",                # Надсилає задачі coder-у

  # Життєвий цикл знань — унікальна можливість planner-а
  "knowledge_ingest",
  "knowledge_query",
  "knowledge_consolidate",
  "knowledge_list_unconsolidated",
  "knowledge_stats",

  # Планування і дослідження (read-only)
  "read_tool", "index", "search_text", "glob", "ls",

  "create_task", "todowrite", "todoread",
  "question",
]
Знання у planner-а, а не у coder-а

Planner — єдиний агент з інструментами знань. Він запитує минулі рішення перед плануванням, а потім додає нові уроки після рев'ю роботи coder-а. Coder stateless — чиста реалізація. Такий поділ зберігає знання чистими та консолідованими.

Middleware planner-а: режим агента

[[planner.middleware]]
type = "context"
warn_at_percent = 80
compact_at_percent = 90
fallback_max_tokens = 128000

[[planner.middleware]]
type = "agent_mode"
default = "plan"
reminder = """# Plan Mode — Knowledge-Driven Orchestrator
You are the planner. You must NOT edit files.
1. Query knowledge before planning
2. Break work into concrete tasks
3. Delegate implementation to coder
4. Ingest decisions and lessons"""
Middleware режиму агента

Middleware agent_mode вставляє system reminder на кожному ході й утримує planner-а в режимі "plan". Він випадково не почне писати код — це робота coder-а. Перемикати режими можна через dashboard комбінацією Ctrl+M.

Підсумок делегації: дешева модель для результатів

[quorum.delegation_summary]
provider = "anthropic"
model = "claude-haiku-4-5-20251001"  # Дешевша модель

Коли coder завершує задачу, результат стисло підсумовується дешевшою моделлю перед поверненням planner-у. Це тримає вартість контексту низькою — planner бачить summary, а не повний diff.

Делегат coder: чиста реалізація

[[delegates]]
id = "coder"
provider = "anthropic"
model = "claude-sonnet-4-5-20250929"
description = "Implementation specialist..."
capabilities = ["rust", "python", "typescript", "shell"]
tools = [
  "edit", "write_file", "read_tool", "index",
  "glob", "search_text", "ls",
  "shell",
  "todowrite", "todoread",
]

Middleware coder-а: ліміти + перевірка дублювання

[[delegates.middleware]]
type = "limits"
max_steps = 80
max_turns = 25

[[delegates.middleware]]
type = "context"
warn_at_percent = 80
compact_at_percent = 90

# Виявляє дублі коду у виводі coder-а
[[delegates.middleware]]
type = "dedup_check"
threshold = 0.85    # Поріг схожості 85%
min_lines = 10     # Перевіряти лише блоки >= 10 рядків
Middleware dedup check

Middleware dedup_check виявляє, коли coder ось-ось запише код, який на 85%+ схожий на вже наявний у проєкті. Він ловить copy-paste патерни й заохочує DRY-реалізацію.

Життєвий цикл у кількох сесіях

Магія відбувається між сесіями. Знання зберігаються в SQLite. Planner щоразу стає розумнішим.

Сесія 1
Ви: "Add rate limiting to the API"

Planner запитує знання: порожньо (перший раз)
Planner аналізує кодову базу через read-only інструменти
Planner планує: "Need middleware layer, token bucket, tests"
Planner делегує coder-у -> coder реалізує
Planner робить рев'ю й ingest: "We used a token bucket approach with Redis backend. Middleware placed before auth layer."
Сесія 2 (наступного дня)
Ви: "Add authentication to the API"

Planner запитує знання: знаходить учорашнє "token bucket, Redis backend, middleware before auth"
Planner планує з урахуванням минулих рішень: "Place auth middleware after rate limiter, consistent with existing pattern"
Planner делегує -> coder реалізує (узгоджено з поточною архітектурою)
Planner додає знання: "Auth uses JWT, middleware consistent with rate limiting pattern"
Сесія 3+
Кожна сесія додає знання до графа. Плани planner-а стають більш узгодженими з архітектурою проєкту. Консолідація об'єднує споріднені записи: "API middleware uses a layered pattern: rate limiting -> auth -> routing."

Потік делегації

1. Запит знань Planner перевіряє, що вже знає про цю кодову базу та тип задачі.
2. План Planner розбиває задачу на кроки з урахуванням минулих рішень.
3. Делегування Planner надсилає реалізацію coder-у з повним контекстом.
4. Реалізація Coder пише код, запускає тести і повертає результати.
5. Додавання уроків Planner переглядає результати й зберігає нові знання на майбутнє.

Ключові можливості

  • Життєвий цикл знань — ingest, query, consolidate між сесіями
  • Мультиагентний кворум — planner делегує спеціалізованому coder-у
  • Підсумок делегації — дешева модель підсумовує вивід coder-а для planner-а
  • Middleware режиму агента — утримує planner-а в режимі "plan", а не "build"
  • Dedup check — ловить дубльований код ще до запису
  • Делегація з урахуванням контексту — минулі знання формують поточні плани

Спробуйте самі

# Запустіть learning pair
cargo run --example qmtcode --features dashboard -- \
  confs/learning_pair.toml --dashboard

# Сесія 1: попросіть його щось побудувати
#   "Add rate limiting to the API"

# Сесія 2 (перезапуск, та сама db): попросіть пов'язану задачу
#   "Add authentication to the API"
#   Зверніть увагу: planner використовує знання із сесії 1

# Опційно: створіть розклад консолідації
#   Trigger: Interval, 3600s (hourly)
#   Prompt: "Run knowledge consolidation..."
#   Max runs: 24