IntentFlow: Керування агентами LLM за допомогою скомпільованої політики та перевірюваних слідів

Уявіть собі агента 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 та перевірки порогових значень, працюють з реальним станом. Правила, які потребують оцінки від LLM, знаходяться у окремому рівні довіри, і коли суддя недоступний, вони записуються як пропущені та ніколи не проходять без сліду.
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 описує те, що ви мали на увазі, потім запустіть його в режимі симуляції та перевірте результати.