Детерминированные инструменты, созданные агентами

Паттерн, проявившийся при рефакторинге монолита 1Password (см. 1password-agentic-refactoring) и встречающийся в других агентных процессах под разными названиями. Идея проста: модель отлично пишет одноразовые анализаторы - SSA-проходы, SQL-парсеры, экстракторы структуры кода. Когда такие анализаторы готовы, их вывод становится стабильным артефактом. Дальнейшая работа - людей или агентов - опирается на этот артефакт, а не на то, что модель выдаст сегодня.

Почему это работает

Вывод LLM недетерминирован. С этим можно мириться, когда результат используется и сразу отбрасывается (один шаг диалога). Но это обходится дорого, когда результат служит входными данными для других решений, поскольку расхождения накапливаются. Смысл в том, чтобы свести недетерминизм к разовым затратам: заплатить за него при генерации и валидации анализатора, а затем больше к этому не возвращаться. С этого момента все потребители видят одни и те же данные.

В этом разница между двумя подходами:

• Агент как интерпретатор. Переспрашивать у модели 800 раз: "безопасно ли выделить эту транзакцию?". 800 разных цепочек рассуждений, дрейф, правдоподобные, но ошибочные случаи и никакого журнала аудита.
• Агент как создатель инструментов. Попросить модель один раз написать SSA-проход, который классифицирует каждое место вызова по шаблонам. Проход выполняется детерминированно. В итоге получается таблица из 800 строк, с которой согласны все.

Второй режим также упрощает ревью: вы внимательно вычитываете один анализатор вместо 800 объяснений.

Практический пример

Миграция MustBegin в 1Password - более 3000 мест вызова транзакций базы данных в кодовой базе на Go. Команда не просила агентов "мигрировать вызовы". Они поступили иначе:

1. Написали генератор манифеста на базе SSA (один инструмент, одно ревью)
2. Классифицировали манифест по повторяющимся паттернам (на выходе: конечный набор сценариев)
3. Определили шаблоны для каждого паттерна (по одной спецификации на сценарий)
4. Запустили параллельных агентов в git worktree'ах, выдав каждому строго специфицированную подзадачу

Детерминированным был шаг 1. Шаги 2 - 4 работали уже с его результатами. Спецификации на шаге 3 устранили оставшиеся расхождения. Результат: часы работы и близкая к идеальной точность.

Для сравнения, выделение сервисов той же командой - где вывод анализаторов был менее полным и требовалось больше экспертных оценок на лету - дало лишь 20 - 30% прироста производительности и привело к ряду опасных инцидентов (незаметная потеря данных из-за ошибок в порядке выполнения, конфликты развёртывания из-за путаницы с общими таблицами).

Пример поменьше той же структуры - workflow-triage в code-mode-token-savings: скрипт, написанный двумя собственными агентами Agent Swarm, который теперь вызывает любой агент роя вместо того, чтобы делать 26 вызовов инструментов и считывать все 26 полезных нагрузок JSON обратно в свой контекст. Экономию они измеряют в токенах, но артефакт здесь тот же - детерминированный проход, написанный один раз, на результаты которого опираются все последующие шаги.

Чем это не является

Это не то же самое, что детерминированный вывод. Агент, который создаёт анализатор, по-прежнему недетерминирован. Смысл в том, чтобы запереть эту вариативность внутри разового проверяемого артефакта, а не избавиться от неё везде.

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

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

Связанные паттерны

• acceptance-criteria-ids - та же структура применительно к продуктовым спецификациям: стабильные идентификаторы, на которые ссылаются агенты вместо повторной интерпретации текста
• specsmaxxing - процесс разработки с агентами от спецификации (spec-first), частью которого является этот паттерн
• context-engineering - сборка стабильного предварительного состояния перед вызовом модели
• ai-assisted-workflow - вариант Barbero с планированием до написания кода
• clean-code-coding-agents - структура кодовой базы как ещё одна форма стабильного артефакта
• no-silver-bullet-llms - почему это помогает со случайной сложностью (accidental difficulty), но не с существенной (essential difficulty)