Clarity Protocol: зачем ИИ думать перед кодом

Есть задача. Агент берёт её и пишет код. Через две недели - правки, через месяц - переделка. Знакомо?

Проблема не в агенте. Проблема в том, что задача не была подумана до конца перед началом работы.

Clarity Protocol от Microsoft решает именно это: заставляет остановиться и структурировать мышление перед тем, как начать строить.

Что такое Clarity Protocol

Не генератор кода. Не фреймворк для Scrum. Clarity - способ подумать над задачей перед её решением.

Агент создаёт папку .clarity-protocol/ в проекте и заполняет её документами: проблема, заинтересованные стороны, требования, решения, отказы, архитектура, ADR с триггерами пересмотра.

Ключевая механика - SHA-256 граф зависимостей между документами. Если формулировка проблемы изменилась, все зависимые документы (стейкхолдеры, требования, решения, архитектура) автоматически помечаются устаревшими. Агент видит это и возвращается перечитывать - не молча продолжает работать с устаревшим контекстом.

Как это работает в Autolycus Agent

Оригинал от Microsoft - Python-приложение с CLI и веб-интерфейсом. Мы встроили Clarity в существующую архитектуру Autolycus Agent.

Проверку статуса документов оформили как плагин clarity_packet. Он регистрирует pre_llm_call hook: перед каждым вызовом модели проверяет SHA-256 хеши файлов в .clarity-protocol/. Документ изменился, а зависимые не обновлены - в контекст инжектится предупреждение. Стоимость проверки - один stat системный вызов. Папка отсутствует - плагин не загружается, нулевая нагрузка.

Шесть перспектив анализа отказов (General, Security, Human Factors, Adversarial, Security Catalog, Codebase) оформлены как отдельные навыки, загружаются по требованию. Каждая ищет отказы в своей области, результат - цепочки отказов с точками вмешательства: предотвращение, обнаружение, смягчение, восстановление.

Документация - docs/clarity-packet.md в репозитории. Плагин ~300 строк, только stdlib.

Зачем это пользователю: не популярный стек, а своё решение

Типичный сценарий работы с LLM: дай задачу -> получи решение. Агент выбирает популярный стек, потому что он в обучающих данных. Применение на земле - задача вторичная, которую пользователь должен выяснить сам.

Clarity Protocol меняет порядок: сначала понять, что решаем и почему. Потом - как.

Один вопрос - "а зачем?" - отделяет цель от средства. Пользователь говорит "нужен микросервис", а реальная проблема - совместное редактирование в реальном времени. Разные цели - разные решения.

Как Clarity дополняет Prism и Premortem

У нас в Autolycus уже есть Prism (структурный анализ артефактов) и Premortem (прямая аналитика - "через 6 месяцев провал, почему?"). Clarity Protocol не заменяет их - работает на другом уровне.

Clarity - это организационный слой. Он заставляет структурировать задачу перед тем, как запускать Prism для анализа или Premortem для поиска отказов. Порядок такой:

• Clarity - что решаем и почему (problem -> stakeholders -> requirements)

• Prism - анализ структуры решения на уровне артефактов

• Premortem - прямая аналитика, через 6 месяцев провал - почему

Три фреймворка дополняют друг друга и формируют полный цикл: от формулировки задачи до проверки решения на прочность.

Что почитать

GitHub: github.com/NikolayGusev-astra/autolycus. Оригинал: github.com/microsoft/clarity-agent.