Прогресивне розкриття: вікна CLI в агентні системи

Числа в цьому дописі відображають стан системи на момент публікації (січень 2026). Актуальні цифри дивіться на нашій сторінці команди.

Агентні системи непрозорі за задумом. Вони ухвалюють рішення, викликають інструменти й координують роботу десятків спеціалістів. Але коли щось йде не так — або коли ви просто хочете зрозуміти, що відбувається — куди дивитися?

Відповідь — прогресивне розкриття: шаруватий інтерфейс, що показує рівно стільки складності, скільки вам потрібно, саме тоді, коли це потрібно.

Проблема непрозорості

Сучасна система оркестрації агентів може мати:

• 40+ спеціалізованих агентів, кожен з унікальними можливостями
• 700+ навичок, що охоплюють внутрішню автоматизацію та інтеграції з вендорами
• 470+ архітектурних рішень, що формують поведінку
• Десятки серверів інструментів MCP, що надають зовнішні можливості

Ця складність навмисна. Агентам потрібен доступ до багатого контексту — доменних знань, інтелекту коду, схем баз даних — щоб ухвалювати добрі рішення. Але та сама насиченість створює проблему видимості.

Як дізнатися, який агент обробляє міграції баз даних? Які рішення сформували поведінку ранжування системи пошуку? До яких інструментів має доступ радник з архітектури?

Без структурованого доступу вам залишається читати вихідний код або сподіватися, що документація актуальна.

Прогресивне розкриття як архітектура

Прогресивне розкриття — не просто патерн UI. Це архітектурний принцип: організовувати інформацію шарами, кожен глибший за попередній, щоб користувачі могли зупинитися на рівні, що відповідає на їхнє запитання.

Для агентних систем це перекладається на команди CLI на зростаючих глибинах:

Рівень	Команда	Запитання, на яке відповідає
1	orkestra system status	Чи все здорове?
2	orkestra agents list	Які агенти існують?
3	orkestra agents info <name>	Що робить цей агент?
4	orkestra decisions search	Чому це працює саме так?
5	Інструменти Maguyva MCP	Покажи мені код.

Кожен рівень відповідає на природне наступне запитання. Вам рідко потрібно стрибати одразу до рівня 5.

Рівень 1: здоров’я системи

Перше запитання завжди: чи все працює?

$ orkestra system status

on
{
  "agents": 40,
  "skills_internal": 466,
  "skills_vendor": 240,
  "skills_total": 706,
  "commands": 17
}

Одна команда. Чотири числа. Достатньо, щоб знати, що система налаштована, а реєстри заповнені.

Якщо кількість агентів несподівано падає, чи навички не завантажуються, ви бачите це тут першим. Занурення в логи не потрібне.

Рівень 2: інвентаризація агентів

Щойно ви знаєте, що система здорова, наступне запитання: що доступно?

$ orkestra agents list

Це повертає структуровані дані — назви агентів, описи, переваги моделей, покриття доменів. Вивід за замовчуванням у JSON, тож легко направити його через конвеєр у jq для фільтрації:

$ orkestra agents list | jq '.agents[] | select(.model == "opus") | .name'

Потрібні агенти, що обробляють роботу з базами даних? Команда пошуку звужує вибір:

$ orkestra agents search "database"

Вона сканує назви, описи та можливості. Ви знаходите правильного спеціаліста, не читаючи 40 визначень агентів.

Рівень 3: глибоке занурення в агента

Знайшли агента, що виглядає доречним? Команда info розкриває все:

$ orkestra agents info architecture-advisor

Вивід включає:

• Метадані: назва, категорія, перевага моделі, опис
• Домени: які ділянки знань покриває цей агент
• Identity: риси характеру (architect, strategist, knowledge-architect)
• Довідники інструментів: яка документація інструментів впроваджується в контекст
• Інструменти: повний список інструментів MCP, доступних цьому агенту

Ось приклад того, що ви бачите:

on
{
  "metadata": {
    "name": "architecture-advisor",
    "model": "opus",
    "description": "Strategic decision-making and architectural guidance..."
  },
  "domains": [
    "product",
    "development/architecture",
    "meta/strategy"
  ],
  "tools": {
    "mcp_tools": [
      "mcp__maguyva__intelligent_search",
      "mcp__maguyva__analyze_dependencies",
      "mcp__supabase__execute_sql",
      ...
    ]
  }
}

Це повідомляє точно, що агент може робити. Вихідний код не потрібен.

Рівень 4: археологія рішень

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

$ orkestra decisions search "agent"

Це повертає відповідні архітектурні рішення:

on
{
  "results": [
    {
      "id": "DEC-SR-049",
      "title": "AI-Agent-First Defaults with Graph Intelligence",
      "domain": "search",
      "status": "active"
    }
  ]
}

Кожне рішення має повну провенансію — коли його ухвалили, чому, які компроміси розглядалися, які коміти його реалізували:

$ orkestra decisions info DEC-SR-049

on
{
  "id": "DEC-SR-049",
  "title": "AI-Agent-First Defaults with Graph Intelligence",
  "summary": "Changes default values for search tools to AI-agent-optimal behavior...",
  "rationale": [
    "AI agents work better with pre-ranked, importance-weighted results",
    "Graph metrics already computed by pipeline - leverage them",
    "Community context helps agents understand feature scope in single query"
  ],
  "source_commits": [
    {
      "sha": "156a880d05eae295669ef7c194b039023f245511",
      "message": "feat(maguyva): enable boost_by_importance..."
    }
  ]
}

Це архітектурна документація, що залишається актуальною, бо вона видобувається з комітів, а не підтримується вручну.

Рівень 5: прямий інтелект коду

Коли вам потрібно побачити реальну реалізацію — не метадані про неї — інструменти MCP від Maguyva надають прямий доступ.

З середини сесії агента:

mcp__maguyva__intelligent_search
  query: "agent context loading"

Це автоматично маршрутизує через семантичний, текстовий та AST пошук, щоб знайти релевантний код. Для конкретних символів:

mcp__maguyva__find_symbol
  symbol_name: "load_agent_context"

Для аналізу залежностей:

mcp__maguyva__analyze_dependencies
  target: "packages/orchestration/core/agents.py"

Це не просто заміна grep. Вони усвідомлюють граф, семантично проіндексовані та інтегровані з тим самим інтелектом коду, що живить самих агентів.

Уніфікований пошук по реєстрах

Іноді ви не знаєте, який реєстр містить відповідь. Уніфікований пошук охоплює все:

$ orkestra search "database" --summary

on
{
  "query": "database",
  "total": 254,
  "counts": {
    "agents": 40,
    "skills": 59,
    "decisions": 476,
    "truths": 2,
    "packages": 1
  }
}

254 збіги в п’яти реєстрах. Резюме повідомляє, куди заглибитися. Приберіть --summary для детальних результатів або додайте --limit 5, щоб зберегти вивід керованим.

Чому це важливо

Прогресивне розкриття — не просто про зручність. Воно змінює те, як ви взаємодієте зі складними системами.

Налагодження стає посильним. Коли агент ухвалює несподіване рішення, ви не грепаєте логи. Ви перевіряєте, до яких інструментів у нього є доступ (agents info), які рішення формують його поведінку (decisions search), і за потреби простежуєте реалізацію (intelligent_search).

Онбординг прискорюється. Новим членам команди не потрібно читати всю кодову базу. Вони починають з system status, досліджують за допомогою agents list і заглиблюються лише коли натрапляють на щось незрозуміле.

Документація залишається актуальною. Оскільки CLI читає з тих самих реєстрів, що конфігурують агентів, вивід завжди точний. Немає розходження між тим, що каже документація, і тим, що робить система.

CLI як інтерфейс

Ми могли б побудувати веб-дашборд. Могли б написати розлогу документацію. Натомість ми побудували CLI, що читає з джерела істини.

CLI має переваги:

• Композиційність: направляйте вивід через конвеєр у jq, інтегруйте зі скриптами
• Придатність до скриптування: автоматизуйте перевірки, генеруйте звіти
• Швидкість: жодних завантажень сторінок, жодних потоків автентифікації
• Точність: читає реальну конфігурацію, а не кешоване представлення

Для систем, де коректність важливіша за естетику, перемагає CLI.

Побудова власного прогресивного розкриття

Якщо ви будуєте агентні системи, подумайте, як користувачі їх досліджуватимуть:

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

Кожен шар відповідає на наступне запитання. Будуйте їх у порядку частоти — більшість користувачів зупиняються на шарі 2 чи 3. Лише досвідчені користувачі досягають шару 5.

Мета не в тому, щоб розкрити все. Мета в тому, щоб розкрити рівно те, що потрібно, саме тоді, коли це потрібно. Це і є прогресивне розкриття, застосоване до архітектури агентів.