Агент выбирает следующую ветку: Dify 1.18 упрощает перенос и проверку процессов

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

Dify 1.18.0, выпущенная 23 октября 2026 года, объединяет эти вопросы. Релиз вводит агентные Output Routes, переносимые пакеты .ifpkg и более глубокую видимость исполнения. Речь не столько о впечатляющем ответе, сколько о понятном месте агента в повторно используемом приложении. Официальный релиз.

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

Интерфейс процесса: LangGenius / участники документации Dify, CC BY 4.0. Размер изменён, файл преобразован в WebP без обрезки. Иллюстрируется редактор, а не все новые элементы управления.

Ветка — решение с конкретным продолжением

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

Новые Output Routes позволяют агенту выбрать настроенный маршрут, продолжив соответствующую ветку. Интерпретация становится выбором внутри процесса с представленным следующим шагом, а не только текстом.

Это облегчает проектирование и исследование. Создатель определяет направления, агент выбирает для запроса, процесс выполняет связанные шаги. Маршрут полезен даже без естественно-языкового объяснения как финального продукта.

Граница важна. Выбор «эскалации» не доказывает юридическую или финансовую необходимость. Выбор «подготовить ответ» не разрешает отправку. Процесс всё равно определяет доступные операции и владельцев исключений.

Первый пример: одно сообщение и три пути

Поддержка получает вопросы о продукте и исключениях. Нужны три направления: ответ по утверждённым материалам, черновик для человека, передача необычного случая.

Явные маршруты делают направления видимыми. Простой вопрос настройки идёт к ответу по знаниям, неопределённость аккаунта — к проверке, отмена коммерческого условия — к ответственному за решение.

Это условные варианты приложения, а не готовая политика Dify. Команда определяет принадлежность маршрутам, примеры и неоднозначный ввод. Убедительное объяснение не должно стирать границу полномочий.

Польза не в гарантии лёгкой классификации, а в проверке конкретного решения. Сложное сообщение в обычной ветке — ясная ошибка. Отправка всех человеку безопасна, но почти не автоматизирует.

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

Настроенный маршрут превращает языковое суждение в видимое продолжение. Каждому нужны свои разрешённые действия и правила проверки.

Переносимость — больше копирования промпта

Приложение зависит от инструкций, определений агентов, Skills, файлов и ссылок на ресурсы пространства. Копия заметного промпта оставляет многое позади.

Пакет .ifpkg в Dify 1.18 включает встроенных Agents, Skills и их файлы. Импорт воссоздаёт ресурсы и переназначает ссылки. Файлы и URL принимают YAML и пакеты; явный экспорт YAML сохраняется. Пакеты и импорт.

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

Но не все внешние зависимости переносятся автоматически. Доступ к моделям, секреты, плагины, сеть и знания зависят от целевой среды. Структурно целое приложение ещё нуждается в настройке.

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

Второй пример: процесс подготовки предложения переходит другой команде

Представьте сервисную компанию с первым черновиком предложения: сбор запроса, писательский Skill, проверка разделов и передача неопределённых коммерческих условий человеку.

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

Получателю остаётся подтвердить услуги, настроить модели и инструменты, проверить право утверждения. Если ссылка на ресурс неуместна в новом пространстве, успешный импорт не оправдывает её сохранение.

Запустите одинаковые образцы до и после переноса. Сравните маршруты, разделы, доступ и проверку. Переносимое приложение сохраняет процесс, допуская сознательные изменения локальных сведений.

Так упаковка становится операционной функцией. Она уменьшает восстановление, но ценен повторяемый переход, который другая команда понимает и тестирует. Экономия кликов — лишь часть.

Просмотр внутреннего исполнения меняет отладку

Релиз подчёркивает более глубокую видимость процесса, включая вложенное исполнение. Ошибка возникает в нескольких шагах от замеченного пользователем симптома.

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

Видимость сужает вопрос: что пришло на шаг, что вышло и кто использовал результат? Это позволяет точечную правку вместо одновременного изменения всего.

Видимость не раскрывает полностью внутренние рассуждения модели. События и потоки данных не объясняют каждый токен или маршрут. Они также не определяют, какие сведения трассы уместны каждому зрителю.

Используйте наблюдаемое поведение, отдельно решая хранение трасс, чувствительное содержание и доступ. Удобство отладки конфиденциального приложения не должно создавать неограниченное чтение запросов.

Выпуск версии и обновление установки — разные вопросы

Релиз GitHub — датированное опубликованное ПО, не доказательство одновременного включения во всех облачных пространствах. Пользователю управляемого сервиса следует проверить свой интерфейс и документацию.

У самостоятельной установки другая обязанность. Примечания 1.18 требуют согласованных API, workers, Agent Backend и образов исполнения, меняя протокол. Обновить один заметный компонент ненадёжно при изменении их взаимодействия.

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

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

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

Полезная оценка помещается на одной странице

Не нужны десятки агентов. Одного приложения с реальным выбором и второй среды для импорта достаточно, чтобы обнаружить важные свойства.

1. Выберите ограниченную задачу. Например, подготовку проверяемого ответа поддержки с понятными входами и результатами. Назначьте владельца исключений.
2. Определите немного маршрутов. Задайте значение, следующие действия и путь для неподходящих запросов.
3. Соберите типичные случаи. Обычные, смешанные и неполные; запишите ожидаемый маршрут заранее.
4. Исследуйте исполнение, а не только ответ. Найдите первый шаг неожиданного значения или выбора.
5. Экспортируйте и импортируйте. Проверьте ресурсы, ссылки, инструменты, модели и секреты назначения. Недостающий доступ не следует предоставлять автоматически.
6. Повторите случаи после переноса. Сравните пути и результаты, отметьте намеренные различия новой конфигурации.

Измерения конкретны: частота правильного назначения, объём настройки при передаче, поиск сбоя без реконструкции всего запуска. Генерируемый текст не обязан служить доказательством собственной правильности.

Пакет переносит структуру приложения. Назначение требует проверки доступа и повторения случаев, определяющих успех.

Перспективы повторного использования требуют осторожности

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

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

Следующий тест Dify — обслуживание при изменениях модели, Skill, политики или пространства. Первый успешный импорт обнадёживает. Управляемое обновление с сохранением поведения — более сильный показатель зрелости.

Dify 1.18 связывает решения с видимой структурой. Начните с малого, сохраняйте понятные маршруты и повторяемую передачу. Так демонстрация становится процессом, которым другая команда может пользоваться ответственно.

Источники

• Примечания к выпуску Dify 1.18.0, опубликовано 23 октября 2026 года в 06:33 UTC.
• Официальная документация Dify, сведения о продукте; доступность функций проверяйте в своём пространстве.

Нужно доступное для поиска место для заметок о процессах, образцов запросов и оснований правок? Соберите материалы в Telli.sh и сохраните понятную историю передачи.