Введение

Примечание: "Темы" были переименованы в "субагенты" в этой статье, согласно последним правилам наименования продуктов.

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

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

Новый Agentforce Builder и Agent Script решают эту проблему, отделив детерминистское выполнение от рассуждений LLM. Гибридная модель Agentforce обеспечивает следование агентом точно заданной структуре для каждого выполнения бизнес-правил, но при этом использует аргументацию LLM, где действительно необходимы суждение, понимание естественного языка или контекстуальная интерпретация.

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

Не удалось гарантировать пути выполнения

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

За каждое взаимодействие оплачена полная стоимость LLM

Даже простые сценарии разговора требовали минимум трех циклов LLM: выбор субагента, выбор действия и создание окончательного ответа. Многоэтапные задачи, расширенные до пяти и более циклов. Для архитекторов, проектирующих бизнес-правила большого объема или чувствительные к задержке, это было не просто проблемой производительности. Это означало, что невозможно было коротко заблокировать цикл рассуждений для этапов, не требующих осуждения, так как в архитектуре не было механизма для разграничения между ними.

Недетерминистское исполнение создало пробел в ревизии

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

Область не выдержала разговора

Использование однооборотной обработки означало, что у агента не было постоянной памяти о предыдущих этапах. Если разговор хоть немного отклоняется, агент может отказаться от ранее собранного контекста и заставить пользователя перезапуститься. Для многоэтапных транзакционных бизнес-правил это создает потолок надежности: чем больше этапов процесса, тем выше вероятность потери контекста до завершения.

Выполненные этапы не были сохранены

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

Новый Agentforce, GA с февраля 2026 года, переходит от чисто вероятностных рассуждений LLM к гибридной модели. Вместо маршрутизации каждого решения посредством LLM, оно отделяет детерминистское выполнение от рассуждений LLM и позволяет каждому обрабатывать только то, для чего оно подходит. Для поддержки этого Agentforce представила два авторских инструмента: Agent Script для разработки на основе кода и Agentforce Studio, среда создания без кода.

Agentforce Builder

Agentforce Builder - рекомендуемая среда для разработки новых агентов. Он размещается в Agentforce Studio и заменяет устаревший интерфейс настройки, который остается доступным, но больше не является основным путем автора. В конструкторе вы работаете либо в визуальном представлении холста, либо непосредственно в представлении сценария, редактируя сценарий агента, определяющий поведение агента.

Сценарий агента

Agent Script - это декларативный доменный язык (DSL), который определяет все особенности поведения агента: его конфигурации, бизнес-логики и подсказки. Он структурирован как пары ключ-значение, которые могут охватывать несколько строк или содержать вложенные подсвойства, и он создан для чтения человеком, не требуя Knowledge об основной архитектуре графика.

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

Детерминистская логика на практике

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

Данная логика вызывает действия в фиксированной последовательности при каждом выполнении определенных условий.

Инструкции по оперативности и преднамеренная передача LLM

Если детерминистская логика обрабатывает условия и последовательности, которые можно выразить в виде кода, оперативные инструкции обрабатывают все, что требует суждения, толкования или создания естественного языка. Когда механизм определения причин Atlas встречает узел с инструкциями по оперативному выполнению, он запускает вызов LLM. В противном случае, выполняется детерминистски.

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

Напоминание об инструкциях в узле запускает вызов LLM. Это не случайно - это механизм, посредством которого сценарий агента делает границу LLM четкой и доступной для выполнения, а не оставляет ее на усмотрение среды выполнения.

Данный субагент отображает детерминистскую логику и передачу LLM в действии.

Трехэтапные ожидаемые продажи

Agentforce Builder и Agent Script являются авторским слоем, но Agent Graph и Atlas Reasoning Engine запускают вашего агента. По замыслу, ни один из этих компонентов недоступен вам напрямую. Разделение авторства и выполнения позволяет платформе применять детерминистское поведение независимо от того, как был написан сценарий.

Конвейер проходит три этапа.

1. Авторство - это место работы. Сценарий агента читается и редактируется в представлении холста или в представлении сценария в Agentforce Builder. Это единственный слой, с которым вы взаимодействуете напрямую.
2. Компиляция - это место, где компилятор Salesforce преобразует сценарий агента в график агента, сериализованный план выполнения, оптимизированный для компьютерного выполнения, а не для чтения. На этом слое отладка не выполняется. Компиляция создает представление, которое может эффективно пройти среда выполнения.
3. Выполнение среды выполнения — это область, где механизм рассуждения Atlas переходит на следующий уровень. Он считывает график агента, проходит его на основе текущего состояния сеанса и решает в каждом узле, выполнять ли детерминистски или вызвать LLM. Механизм явно применяет здесь условия охраны и условную маршрутизацию, а не вывод.

График агента

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

Механизм обоснования Atlas

Механизм обоснования Atlas является государственным машинным исполнителем. При каждом ходе он проходит график агента на основе состояния сеанса, выполняет детерминистские узлы в качестве кода и инициирует вызовы LLM только при наличии инструкций по запросу. Он также применяет условия охраны и обрабатывает условную маршрутизацию. Механизм рассуждения — это область фактической реализации гибридной модели рассуждения; сценарий определяет границу, а механизм соблюдает ее.

Агент Граф не упаковщик LLM. Это гибридный механизм рассуждения, который разделяет детерминистское выполнение и вероятностное рассуждение. Правило является простым: если вы можете выразить решение в виде кода, оно должно быть записано в виде логики. Если решение требует осуждения, толкования или создания естественного языка, его должен обработать LLM. Это дизайнерское решение - самый важный архитектурный выбор в новой модели Agentforce. Место падения границы LLM напрямую влияет на стоимость, задержку, проверяемость и надежность решения.

Механизм рассуждений Atlas оценивает каждый входящий ход пользователя и перенаправляет его по одному из двух путей.

Путь А: детерминистское исполнение

Этот путь не содержит экспозиции LLM. Он действует как компилированный код во время выполнения. Механизм обоснования классифицирует намерение пользователя и определяет соответствие логической инструкции, полностью обходя LLM. Компилируемый сценарий агента выполняется сверху вниз, при этом правила if-else выполняются безоговорочно при каждом ходе. Действия потока, Apex или API вызываются с детерминистскими параметрами, без оперативной сборки или вызова модели. Результат проходит обратно через слой Trust с полным журналированием аудита.

Путь Б: Рассуждения LLM

Механизм рассуждения использует этот путь, если он не может решить намерение только посредством логических инструкций. Он проходит график агента и оценивает каждый узел. Узлы с инструкциями по запросу инициируют вызов LLM. Узлы без них выполняются детерминистски. Наличие инструкции-напоминания является триггером, и оно четко выражено в сценарии, а не выведено во время выполнения.

Что запускает вызов LLM

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

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

Что остается детерминистским

Прохождение графика и переходы состояния никогда не используют LLM. Блоки жизненного цикла before_reasoning и after_reasoning выполняются детерминистски, если они содержат только узлы действий без инструкций. Математика, извлечение данных, проверка и условная логика - все это относится к коду. Любое действие, выполняющее Flow, Apex или REST API, напрямую остается на детерминистском пути. Любой узел без инструкций выполняется без вызова LLM.

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

Рекомендации по проектированию: логика активной доставки в код по умолчанию

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

Стандартная позиция должна быть детерминистской. Изолируйте все алгоритмы агентов, которые можно кодифицировать как правило, и переместите их в сценарий агента. Остальные задачи, требующие естественно-языкового синтеза, контекстного суждения или сложной интерпретации, относятся к узлам-наводчикам. Это не ограничение, это граница, работающая как положено. LLM обрабатывает то, что больше подходит, а все остальное выполняется как код.

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

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

Каждый субагент определяет три зоны выполнения:

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

Когда использовать before_reasoning

before_reasoning выполняется в начале каждого анализа без исключения. Он выполняется при первом вводе в субагента и повторно после каждого вызова инструмента или обращения нового пользователя в этом субагенте. run @actions.X в before_reasoning - код. В отличие от инструкции в блоке напоминания, которой может следовать или не следовать LLM, before_reasoning выполняется безоговорочно.

Используйте этот блок для инициализации сеанса: извлечение записей контекста, установка переменных сеанса из Apex или потока. Здесь же находятся проверки подлинности и права, поскольку вы хотите, чтобы они были проверены до того, как LLM отобразит инструменты. Контекстное увлажнение также подходит сюда: вызов действия извлечения данных, чтобы LLM получал предварительно заполненные переменные, а не запрашивал их. Любой счетчик или переменная аудита, которые должны быть увеличены при каждом анализе, должны быть установлены здесь, поскольку директива set в before_reasoning гарантируется так, как не гарантируется инструкция ожидаемых продаж.

Здесь нет места логике, которая должна выполняться только один раз за сеанс, поскольку before_reasoning выполняется при каждом анализе, а не только при первой записи. Всему, что зависит от ввода пользователя из текущего хода, здесь также не место, поскольку этот ввод еще не обработан. И переходы не должны быть в before_reasoning:. transition to инструкция здесь будет беспрепятственно работать при каждом анализе и создавать циклы.

Если вам нужна инициализация один раз за сеанс, защитите ее четко:

Один ход пользователя может инициировать несколько анализов: один раз при входе, потом повторно после каждого вызова инструмента. Эта функция имеет три практических последствия: действия инициализации в before_reasoning будут выполняться более одного раза на обращение пользователя в потоках нескольких действий, переменные счетчика, добавленные здесь, будут отображать количество анализов, а не обращений, а действия с побочными эффектами, внешними вызовами API или записями записей не должны работать в before_reasoning, если повторное выполнение каждого анализа не является явно приемлемым.

before_reasoning не является конструктором. Это предполетная проверка, которая выполняется при каждом анализе. Создайте его соответствующим образом.

Когда использовать after_reasoning

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

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

Разумное использование is_displayable: True

Каждый архитектор, проектирующий потоки оркестрации, должен понимать этот алгоритм платформы. При установке is_displayable: True для действия платформа выходит из цикла рассуждений, как только LLM решает опубликовать этот вывод. Выход происходит немедленно, то есть after_reasoning не выполняется.

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

Ответ однозначен. Переместите логику, которая должна выполняться надежно, в блок before_reasoning последующего субагента, а не в блок after_reasoning текущего.

Рекомендации по проектированию: где разместить логику инициализации

Решение о месте размещения логики является важным при создании субагента. Данная инфраструктура охватывает наиболее распространенные сценарии:

Основной принцип прост. Когда вы пишете напоминание, сообщающее LLM о необходимости «всегда выполнять» действие, это предложение. LLM может следовать или не следовать ему, в зависимости от контекста. Если вы размещаете директиву run в before_reasoning, это код. Он выполняется во всех анализах без исключения.

Доступность условного действия - это механизм, посредством которого сценарий агента открывает или скрывает действия из LLM на основе состояния переменной среды выполнения. Когда условие available when оценивается как false, действие полностью удаляется из списка инструментов, представленного LLM. Любое ложное значение, включая None, False, 0 или пустую строку, подавляет действие.

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

В данном примере execute_transfer недоступно для LLM до тех пор, пока validation_passed не будет оценен как true. Ворота применяются платформой, а не инструкциями.

Рекомендации по проектированию: Не позволяйте LLM устанавливать переменную ворот

Предоставьте каждой переменной условия available when детерминистский путь кода, который устанавливает переменную перед выполнением связанного действия. Используйте before_reasoning или детерминистский блок run и set, reasoning, чтобы поддерживать переменную в известном состоянии. Если вы используете LLM для установки переменной ворот, вы повторно ввели изменчивость, для предотвращения которой был создан шлагбаум. В зависимости от разговора, LLM может установить или не установить его, то есть ворота могут открываться или не открываться.

Проблема цикла действий

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

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

Рассмотрим available when @variables.interest != "" в качестве примера. Если действие выполняется, но переменная процентов не пустая, ворота остаются открытыми при следующем анализе. LLM видит действие доступным, не имеет инструкции остановиться и вызывает его повторно.

Существует два надежных способа разорвать порочный круг. Первый - установить переменную ворот в закрытое состояние как часть логики пост-выполнения действия, чтобы available when оценивался как false при следующем анализе. Второе - использование отдельного логического значения has_run, закрывающего ворота после первого выполнения. Оба подхода предоставляют воротам детерминистское состояние закрытия, которое является условием, необходимым платформе для подавления действия.

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

Сбор и проверка вводных данных

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

Сценарий ниже отображает это на практике. Обратите внимание, что validation_passed установлена на false в каждой точке сбоя, и LLM предписано не продолжать. Детерминистские проверки выполняются безоговорочно, в то время как инструкции-напоминания обрабатывают пользовательский ответ.

Применить бизнес-правила

После проверки вводных данных агент проверяет, превышает ли стоимость передачи настроенное ограничение. Здесь бизнес-правила становятся кодом, а не инструкциями. Ограничение - это не причина LLM; это жесткий порог, определенный в сценарии и проверяемый детерминистски при каждом анализе.

Если стоимость превышает ограничение, validation_passed устанавливается обратно на false, и LLM предоставляет пользователю три варианта: передать максимально допустимое количество, разделить на несколько передач или обратиться в службу поддержки для повышения ограничений. Агент не может продолжить работу до тех пор, пока пользователь не решит исключение. Обратите внимание, как инструкция-напоминание выполняет именно то, для чего подходят рассуждения LLM: представление вариантов в диалоговом режиме и обработка ответа пользователя. Само бизнес-правило является детерминистским, а разговор вокруг него - нет.

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

Применить условия охраны

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

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

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

Явные ошибки поверхности

Условия охраны устанавливают состояние. Сообщения об ошибках сообщают об этом. Если validation_passed false, агент должен предоставить пользователю достаточно информации для решения проблемы без повторного запуска. Расплывчатые сообщения об ошибках создают трение; структурированные быстрее закрывают цикл.

Сценарий ниже отображает сообщение об ошибке недостаточности средств на практике. Это не просто сообщает пользователю об ошибке передачи. Он отображает доступный баланс, запрошенную сумму, вычисленный дефицит и предлагает конкретный следующий этап, все собранные из переменных сеанса, а не созданные LLM.

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

Действие передачи в ворота

Каждая проверка проверки на предыдущих этапах устанавливает или очищает одну переменную: validation_passed. Эта переменная сейчас выполняет свою самую важную работу. Действие «execute_transfer» доступно условно, то есть отображается в списке инструментов LLM только при использовании validation_passed true. Пока каждая предыдущая проверка не пройдет и не установит эту переменную, действие не будет существовать с точки зрения LLM.

Это схема из предыдущего раздела ворот, примененная к производственному бизнес-правилу. Действие передачи не скрыто напоминанием. Он скрыт платформой. Никакое диалоговое давление или двусмысленная фраза не может заставить LLM вызвать его до выполнения предварительных условий.

Сценарий ниже отображает настройку ворот. Условие available when напрямую ссылается на validation_passed, а параметры действия привязаны к переменным сеанса, собранным и проверенным на предыдущих этапах.

Все три параметра, from_account, to_account и amount, передаются детерминистски из переменных сеанса. К моменту появления этого действия каждое значение будет проверено. LLM собирает параметры не из контекста разговора, а из состояния.

Отслеживание состояния в бизнес-процессе

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

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

Каждая переменная начинается в известном состоянии по умолчанию. Строки по умолчанию пустые, числа нулевые, а validation_passed логические значения false. Это значит, что ворота закрыты по умолчанию. Бизнес-правило должно активно зарабатывать право на выполнение каждого этапа, а не начинать работу с открытыми воротами и полагаться на проверки для их закрытия.

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

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

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

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

Граница - это проектное решение

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

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

Новая модель Agentforce предоставляет инструменты для преднамеренного размещения этой границы. Сценарий агента позволяет выразить детерминистскую логику и инструкции в одном файле с четким синтаксисом, чтобы граница была видимой. Механизм рассуждений Atlas внедряет логику и подсказки во время выполнения. Блоки before_reasoning и after_reasoning предоставляют зоны гарантированного выполнения по обе стороны вызова LLM. Доступность условного действия обеспечивает возможность действия LLM только при соблюдении предварительных условий.

Ни одна из этих функций не изолирована. Они совместно работают над созданием целостной архитектуры для создания агентов, которым предприятия могут Trust с важными бизнес-процессами. Гибридная модель рассуждений распознает, что детерминизм и гибкость имеют роли в вашей архитектуре; задача архитектора — точно определить, где они применяются.

Рецепты сценария агента

Руководство разработчика Agentforce

График Agentforce's Agent Graph: К пошаговому детерминизму с гибридным рассуждением

Гуляль Кумар является архитектором программного обеспечения в Salesforce с более чем 20-летним опытом работы. Его опыт охватывает искусственный интеллект, интеграцию, API и архитектуру предприятия, с акцентом на стимулировании трансформации бизнеса посредством безопасных, устойчивых и инновационных решений на основе искусственного интеллекта. Свяжитесь с ним в LinkedIn.

Мириам Маккейб — старший директор и руководитель группы архитекторов-евангелистов. Её работа сосредоточена на предоставлении мировому сообществу архитекторов Salesforce возможности лидерства в эпоху агентов посредством глубоко технического содержимого, оперативного программирования и взаимодействия с сообществом. Подпишитесь на нее в LinkedIn.