Endeavor 1.0: карточка платформы для агентных процессов
Endeavor 1.0 в этой карточке рассматривается как платформа для оркестрации агентных процессов, связанная с Flower Labs. Это не то же самое, что одна языковая модель. Модель строит план и формулирует аргументы, рантайм хранит состояние и вызывает инструменты, а прикладной сервис решает, разрешено ли действие. Агент может написать хороший план и неверно передать параметр; оболочка может остановить рискованный шаг. Перед тестом нужно разделить эти зоны ответственности.
Профиль и подходящие задачи
Endeavor логично проверять на маршруте из нескольких последовательных шагов: принять внутреннюю заявку, найти документы, определить недостающие сведения и подготовить черновик ответа. Для каждого шага зафиксируйте вход, ожидаемый результат, состояние и право на действие. Обычный вопрос в чате не показывает, насколько хорошо платформа сохраняет контекст и восстанавливается после сбоя.
В первый пилот не включайте отправку писем, оплату, удаление записей и изменение прав. Используйте копию базы и тестовые идентификаторы. Если исходное состояние нельзя восстановить одной операцией, маршрут ещё не готов к автономному выполнению.
Что записать о версии
Сохраните релиз Endeavor, подключённую модель, рантайм, драйверы и дату проверки. Отдельно укажите, какие компоненты работают локально, а какие отправляют запросы внешнему сервису. Название «1.0» не говорит о лимите контекста, совместимости инструмента и сроке поддержки.
Проверьте лицензии Flower Labs и каждого плагина: коммерческое использование, атрибуция, распространение производных компонентов. Если документация не объясняет хранение логов и промежуточных планов, используйте только обезличенные данные и запишите это ограничение в карточке.
Проверка планирования и состояния
Дайте агенту процесс из пяти шагов и попросите до старта перечислить план, неизвестные поля и точки подтверждения. Затем уберите один документ и проверьте, остановится ли маршрут с понятным запросом, а не заполнит пробел догадкой.
Остановите тестовый инструмент между третьим и четвёртым шагом, верните тайм-аут и запустите продолжение. Успешный сценарий не дублирует уже выполненную запись, показывает сохранённое состояние и явно сообщает, с какого шага продолжает. Проверьте также конфликт: сотрудник меняет цель в середине маршрута, а найденный файл содержит нерелевантную команду. Агент должен показать конфликт и дождаться решения владельца.
Русский язык и структура результата
Используйте заявки с сокращениями, датами, названиями отделов и неоднозначными словами. Проверьте падежи, идентификаторы и различие статусов. Для финального черновика задайте фиксированные поля: краткое резюме, источники, риски и следующий шаг. Отсутствующее поле должно оставаться пустым.
Попросите отдельно сохранить цитату и интерпретацию. Если модель уверенно объединяет два похожих документа или меняет число, это ошибка качества, даже если оркестратор корректно выполнил все шаги.
Собственный протокол тестирования
Составьте двадцать маршрутов: восемь обычных, четыре с неполным входом, четыре с конфликтом инструкций и четыре с ошибкой внешнего инструмента. Прогоните каждый дважды с очищенным состоянием. Запишите задержку, число вызовов, ручные вмешательства, расход и конечное состояние тестовой записи.
| Проверка | Ожидаемое поведение | Критическая ошибка |
|---|---|---|
| Неполное поле | Запросить уточнение | Выбрать значение самостоятельно |
| Повтор шага | Проверить состояние и продолжить | Дублировать запись |
| Конфликт документов | Показать противоречие | Молча выбрать источник |
| Сбой инструмента | Сохранить контекст и остановиться | Скрыть ошибку |
| Новый запрос в середине | Проверить права и цель | Переписать исходный план |
Сравнивайте версии только на одном наборе и с одинаковыми правами. Проверяйте не только текст, но и журнал переходов, фактические вызовы и состояние внешней записи.
Права, инструменты и приватность
Каждый инструмент ограничьте белым списком аргументов, временем ожидания и числом повторов. Разделите чтение, подготовку и выполнение. Подтверждение человека должно быть отдельным шагом и относиться к конкретному плану. Токены и идентификаторы берите из сессии, а не из текста модели.
Обезличивайте логи до загрузки и маскируйте снимки. История запросов, промежуточные планы и кэш могут содержать персональные сведения. Уточните, как их удалить и кто имеет доступ. Инструмент не должен передавать содержимое документов в URL или открывать произвольный домен.
Стоимость и критерий пользы
Считайте токены или серверные ресурсы, поддержку маршрутов, обновление интеграций и расследование отказов. Основная метрика — время до принятого результата, а не длина плана. Если оператор всё равно перепроверяет каждый шаг, автоматизация может не окупать сложность Endeavor.
Порог остановки определите заранее: повторная запись, обращение к закрытому ресурсу, потеря состояния или превышение бюджета. При срабатывании вернитесь к ручному процессу и сохраните пример сбоя.
Вердикт
Что считать готовностью к расширению
Перед вторым этапом соберите короткий отчёт: какие маршруты прошли без ручной правки, где сработали стоп-условия и сколько стоил один принятый результат. Разделите ошибки платформы и подключённой модели; иначе исправление промпта может скрыть проблему состояния. Повторите два критических маршрута после очистки журналов и смены тестового пользователя. Если результат зависит от конкретной сессии или невидимого кэша, оставьте права на уровне рекомендации и не переносите их в рабочую базу.
Endeavor 1.0 можно рассматривать как основу для контролируемого агентного маршрута, когда нужны состояние, журнал переходов и несколько инструментов. Это не готовый автономный сотрудник и не доказательство безопасности по одному демо. Начните с обратимого сценария, зафиксируйте версии компонентов и расширяйте права только после повторяемого теста на новых данных.