Создание доверяемых агентных рабочих процессов с

Почему механизм имеет значение

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

Три ключевых требования к процессу

При разработке исследовательского агента Elicit выделила три основных критерия:

• Legibility (понятность). Процесс должен быть ясным для людей и других агентов (например, для критики). Это значит, что код должен быть прозрачен и легко проверяем.
• Fidelity (сохранение целостности). Добавление новых шагов или направлений в работу не должно приводить к «дрейфу» от первоначальной цели пользователя. Итерации должны сохранять исходный смысл.
• Faithful execution (точное выполнение). Система обязана строго следовать утверждённому плану действий без отклонений.

Эти требования привели к созданию предметно-ориентированного языка (DSL).

Ash PL: DSL для агентных рабочих процессов

Ash PL — это специальный язык для агентных рабочих процессов в Elicit, ориентированный на научные исследования и принятие решений.

Отличительные черты:

• Неполный по Тьюрингу. Нет циклов, рекурсии, мутации. Это чисто функциональный реактивный язык, что обеспечивает предсказуемость.
• Ограниченное подмножество Python. Убраны ненужные возможности, добавлены доменно-специфичные примитивы (поиск академических статей, клинических trials).
• Статическая типизация. Позволяет быстро находить ошибки и перерабатывать код.

Пример: программа на Ash PL может описывать процесс конкурентного анализа — поиск в сети, объединение результатов, обогащение источников.

Архитектура: интеграция Ash PL

Система построена вокруг цикла «написание → интерпретация → переработка» кода на Ash PL.

Ключевые компоненты:

• Пользовательский интерфейс (UI) — взаимодействие с пользователем.
• Журнал событий (Event Log) — append-only лог для управления состоянием (паттерн Event Sourcing).
• Куратор (Curator) — компонент, который пишет и перерабатывает код на Ash PL, используя лучшие доступные модели (например, Claude через Pi).
• Песочница (Sandbox) — среда для куратора.
• Python-сервис — интерпретирует и выполняет код на Ash PL.
• Шлюз (Gateway) — централизованная точка для безопасного взаимодействия с API LLM.
• Кэширующее хранилище (Content Address Store) — ключевой элемент производительности. Позволяет хэшировать и запоминать результаты выражений, избегая пересчётов при каждой интерпретации всей программы.

Демонстрация: картографирование исследовательского ландшафта

Запрос: «Картографировать компании и институты, инвестирующие в фундаментальные модели для биологии».

Процесс, управляемый Ash PL:

1. Уточнение задачи у пользователя (широкий ландшафт vs. конкретика).
2. Последовательное выполнение шагов: поиск академических статей, веб-поиск, фильтрация, обогащение данных.
3. Создание артефакта — итоговой таблицы с организациями и их атрибутами (созданные модели, модальности, коллаборации).

Как обеспечивается доверие:

• Просмотр кода Ash PL для каждого артефакта обеспечивает проверяемость.
• Визуализация процесса: графическое представление шагов, автоматически генерируемое из Ash PL.
• Итеративное развитие: пользователь добавляет новые слои анализа на естественном языке. Система расширяет исходную программу, но благодаря кэшированию ранее вычисленные части не пересчитываются.

Выводы и рекомендации

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

Что нужно учесть при реализации подобной системы:

1. Создание DSL (желательно на основе популярного языка).
2. Эргономика для агента (обертка для смены моделей и harness).
3. Обработка прерываний (возможность добавлять новые запросы без остановки процесса).
4. Восстановление сессий (rehydration).
5. Изоляция credentials (безопасность).
6. Управление выводом моделей (парсинг, обработка).
7. Управление состоянием (Event Sourcing).
8. Инвестиции в оценку (eval) — критически важно в сложных динамических системах.

Главный посыл: Инвестируйте в проектирование механизма работы вашей системы. Именно детальный, проверяемый и воспроизводимый процесс создает реальное доверие у пользователей.