IntentFlow: Управление агентами больших языковых моделей с компилированной политикой и проверяемыми следами действий

Представьте агента на основе LLM, подключенного к чтению задачи в GitHub, поиску в репозитории, составлению ответа, и поскольку у кого-то была спешка, он публикует этот ответ и закрывает задачу. Ограничения были указаны в инструкциях: никогда не закрывать задачу, всегда приводить доказательства, обращаться к человеку при неуверенности. Но модель все равно закрыла задачу.

Это не было злым умыслом. Ограничения, сформулированные в прозе, являются рекомендациями, и модель, воздействуемая умело сформулированным текстом задачи, иногда воспринимает эти рекомендации как необязательные. Когда специалист по безопасности просит доказательства того, что агент никогда не выполнял запрещенных действий, имеются лишь журналы операций, созданные тем же кодом в формате, придуманном кем-то еще. Это не доказательства — это дневник.

IntentFlow — это экспериментальный язык, созданный для преодоления этого разрыва.

Где обычно находится управление

Большая часть механизмов управления агентами располагается в одном из трех мест, и каждое из них имеет слабые места:

• В промпте. Это проза, которую модель может проигнорировать, и единственный способ проверки — это прочитать окончательный результат и надеяться.
• В коде приложения. Это настоящее обеспечение соблюдения правил, но политика теперь переплетена с Python-кодом, вызывающим модель, и на вопрос «что было разрешено агенту делать?» отвечают путем просмотра кодовой базы.
• Среди набора функций-обратных вызовов фреймворка. Функции связываются между собой, в то время как политика существует только в голове кого-то и фиксируется в специальных логах.

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

Идея в одном абзаце

IntentFlow — это небольшой декларативный язык. Файл с расширением .iflow определяет цель, требования к доказательствам, политику действий, правила верификации, способы обработки неопределенности и формат вывода с указанием типов. Компилятор преобразует этот файл в план выполнения в формате JSON, который затем реализуется движком выполнения, состоящим из 13 этапов; при этом каждый вызов инструмента проходит через компонент ActionGate, включая считывание доказательств с диска. Этот компонент опирается на скомпилированную политику и никогда не считывает результаты работы модели, поэтому модель не может обойти его ограничения. При каждом запуске формируется трасса в виде цепочки хэшей, которая может быть подписана по желанию. Затем инструмент intentflow audit воссоздает правила на основе исходного файла и проверяет, что запуск соответствовал им. Для этого ему достаточно самого файла и трассы; нет необходимости доверять движку выполнения, серверной части или модели.

Девиз проекта всё объясняет: программы на Python обеспечивают детерминированные вычисления, а программы IntentFlow — управление когнитивными процессами.

Как выглядит программа

Основным примером является задача сортировки проблем, показанная здесь в её ядре управления. Она начинается с названия и цели:

goal TriageGitHubIssue {
  objective:
    triage a GitHub issue safely and propose a maintainer-ready response

Оставшиеся разделы посвящены доказательствам, допустимым действиям, верификации, управлению неопределенностью и формату вывода:

  evidence:
    require issue_body
    require comments
    require repo_context
    optional related_issues
    distrust unsupported_claims  actions:
    allow read_issue
    allow search_repo
    allow draft_comment
    require_approval post_comment
    deny close_issue  verify:
    require cites_evidence
    require maintainer_safe_tone
    require no_unverified_claims
    check confidence >= 0.65  uncertainty:
    if confidence < 0.65 ask_human
    if missing_evidence ask_human
    if security_risk block_action  output:
    summary: string
    likely_cause: string?
    confidence: number
    suggested_response: markdown
    proposed_labels: list[string]
}

Прочитайте его с верха до низа, и вы узнаете, что может сделать агент. deny close_issue — это не совет; он встроен в механизм проверки. При использовании require_approval post_comment выход на следующий этап по умолчанию запрещается, пока кто-то или другой процесс не предоставит одобрение. А check confidence >= 0.65 — это строгий числовой критерий. Блок output: представляет собой типизированный контракт, по которому проверяется результат.

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

Процесс прост: каждый этап ограничивает возможности следующего.

.iflow source -> parser -> analyzer (IFLOW diagnostics) -> compiler ->
execution plan (JSON) -> runtime (13-phase machine) -> traced result ->
replay / audit

Несколько дизайнерских решений делают аудит значимым, а не декоративным:

1. Контрольный механизм расположен вне модели. Отклонённые или незарегистрированные действия вызывают ошибки, а действия, требующие одобрения, не выполняются без соответствующего разрешения. Поскольку контрольный механизм никогда не считывает результаты работы модели, инъекция данных не может повлиять на его работу.
2. Сначала происходит калибровка. Бэкенд сообщает первоначальный уровень уверенности, движок в реальном времени корректирует его в соответствии с политикой калибровки плана, после чего правила оценки неопределённости анализируют скорректированное значение. Хранилище следов сохраняет оба числа.
3. Проверка осуществляется формально, а не предположительно. Правила, поддающиеся проверке машиной, такие как cites_evidence, requires_phrase и проверки пороговых значений, применяются к реальному состоянию. Правила, требующие оценки от большой языковой модели, находятся в отдельном уровне доверия; при отсутствии судьи они записываются как пропущенные и никогда не принимаются без отметки.
4. Трейс является только для добавления данных и полным. Каждый этап, решение на контрольно-пропускном пункте, уровень эскалации и проверка записываются в журнал с использованием цепочки хэшей, где каждое событие хранит хэш предыдущего хэша вместе с каноническим описанием события. Подпись трейса закрепляет его корень с помощью HMAC, что позволяет владельцу ключа обнаружить вмешательства.

Каждая работа завершается одним из шести возможных статусов, и код завершения процесса отражает его. Важной гарантией является то, что неудачная верификация приводит к завершению работы со статусом failed_verification. Система не может отразить это как completed, и одна из проверок аудитора предназначена именно для выявления любых попыток скрыть это.

Попробуйте за пять минут

Ядро не имеет зависимостей от среды выполнения, и каждая из приведённых ниже команд работает офлайн и детерминированно без API-ключа. Она предназначена для Python 3.10 или новее.

git clone https://github.com/dgenio/intentflow
cd intentflow
pip install -e .

Проверьте флагманский пример, попросите объяснения и запустите его:

intentflow validate examples/opensource_triage.iflow
intentflow explain  examples/opensource_triage.iflow
intentflow run      examples/opensource_triage.iflow \
    --backend simulate --trace-dir traces

Во время выполнения выводится краткое описание, подобное этому, которое отражает реальное выполнение в версии 0.6.0:

--- run summary ---
  goal:               TriageGitHubIssue
  status:             completed
  backend:            simulate
  confidence:         0.676
  verification:       passed
  uncertainty:        clear
  trace id:           b9f44900...
trace written to traces/TriageGitHubIssue-...json

Теперь проверьте, как оно себя вело. Команда audit перекомпилирует исходный код и подтвердит, что трейс оставался в пределах границ программы:

intentflow audit examples/opensource_triage.iflow traces/TriageGitHubIssue-*.json

Чистый результат выглядит так:

{
  "goal": "TriageGitHubIssue",
  "conformant": true,
  "violations": []
}
AUDIT: CONFORMANT — the trace stayed inside the program's envelope

Чтобы увидеть, как фактически срабатывают ограничения, попробуйте пример, преднамеренно являющийся рискованным. Он позволяет выполнять действие развертывания без каких-либо шагов утверждения. Анализатор выдает ошибку IFLOW010, скомпилированный профиль риска оказывается высоким, и при выполнении правила if security_risk block_action оно срабатывает:

intentflow run examples/high_risk_deploy.iflow --backend simulate
# -> status: blocked

Действие write_database, которое было отклонено, никогда не сможет быть выполнено, независимо от того, что говорит модель.

Аналогичные возможности доступны из Python. Начните с импорта:

import intentflow

Затем загрузите программу, запустите её и зарегистрируйте функцию Python в качестве управляемого действия:

program = intentflow.load("examples/opensource_triage.iflow")
result = program.run(backend="simulate")
assert result["status"] == "completed"# register a Python function as a governed action (runs through the gate):
program.register_tool("lookup_user", serves=("user_record",),
                      handler=lambda src: "enterprise plan")report = intentflow.audit_document(program.compile(), result)
assert report["conformant"]

Регистрация инструмента не обходит механизмы управления. Ваша функция по-прежнему проходит через контрольные точки.

Почему уровень уверенности снижается с 0,72 до 0,676

Это не дефект, а отражение всей концепции проектирования. В примере диагностики в производственных условиях используется порог в 0,7. В симуляторе первоначальный уровень уверенности составляет 0,72, что позволяло бы пройти проверку, но калибровка снижает его до 0,676, что ниже установленного порога, поэтому выполнение завершается с статусом needs_human. Диагноз, в отношении которого агент не уверен, не должен завершаться автоматически. Симулятор предназначен для того, чтобы весь этот механизм управления — контроль, калибровка, проверка, эскалация и отслеживание — можно было тестировать полностью, без сетевых проблем или непостоянного поведения.

Честные ограничения

IntentFlow находится на версии 0.6.0 и относится к категории предальфа; пока нет системы CI. Он работает, и в репозитории имеется примерно 233 теста, которые не требуют ни сети, ни API-ключей, однако существуют реальные недостатки:

• Грамматика ориентирована на строки и не поддерживает сложные условия, поэтому отсутствует конструкция if a and b.
• Калибровка осуществляется с помощью фиксированной карты сжатия, а не обучаемой модели, хотя планируется использование обучаемой карты.
• Результаты в форме объектов имеют тип только на внешнем уровне, при этом для их содержимого не установлено никаких ограничений.
• Примитивы неопределенности, помимо ask_human и block_action, фиксируются, но не выполняются.
• Инструменты с побочными эффектами охвачены правилами политики, но на практике никогда не запускаются. Для них существуют правила контроля, а реальная запись данных наружу еще предстоит.
• Пайплайны имеют линейную структуру; DAG-структуры планируются к реализации в будущем.

Симулятор имитирует процесс принятия решений и указывает на это. Существуют бэкенды для OpenAI и Anthropic, которые проходят через один и тот же механизм управления, а режим воспроизведения позволяет выполнять детерминированные тесты без использования ключей. Тем не менее ориентиром для соответствия становится именно детерминированный симулятор.

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

Что можно извлечь

• Храните правила вне модели. Простой текст представляет собой лишь запрос, тогда как скомпилированный приказ deny, подкрепленный механизмом, игнорирующим вывод модели, является строгим правилом.
• Самостоятельно созданные логи мало что доказывают, но записи, которые может проверить независимая сторона, — да. Аудитор снова выводит правила из исходного кода и ему нужны только исходный код и эти записи.

Корректировка уровня неопределенности должна позволять прервать процесс. Когда значение снижается с 0,72 до 0,676 и не достигает уровня 0,7 бара, это является ожидаемым поведением: агент, не уверенный в решении, передает задачу человеку вместо того, чтобы притворяться уверенным.

Весь цикл управления можно протестировать офлайн: нет зависимостей, используется детерминистичный движок симуляции, и не требуется API-ключ.

Сформируйте реалистичные ожидания от предальфа-версии программного обеспечения: оно работает и хорошо протестировано, но пока нет системы CI, пайплайны линейные, калибровка фиксирована, а инструменты с побочными эффектами не запускаются.

Правильное тестирование подобной идеи подразумевает постановку реальной цели. Напишите файл .iflow для агента, которым вы действительно управляете, проверьте, описывает ли команда explain то, что вы имели в виду, затем запустите его в режиме симуляции и проанализируйте результаты.