Рабочие процессы с программным контролем и передачей эстафеты

Суть

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

Предусловия и эстафета

Ворота-предусловия перехватывают вызов инструмента и блокируют исполнение, пока не выполнены предыдущие условия (например, get_customer установил флаг проверенного клиента). При эскалации к человеку передавайте структурированный пакет (ID клиента, первопричина, находки, рекомендованное действие), а не голый сигнал «нужна помощь».

Ворота-предусловие блокируют process_refund (детерминированный контроль)

func beforeToolCall(toolName string, toolInput map[string]any, session *Session) GateResult {
	// Финансовые/идентификационные операции защищены воротами.
	needsIdentity := map[string]bool{"lookup_order": true, "process_refund": true}

	if needsIdentity[toolName] && session.VerifiedCustomerID == "" {
		// Жёстко блокируем до проверки личности, даже если клиент сам назвал ID.
		return Block{Reason: "Сначала вызовите get_customer и подтвердите личность клиента"}
	}

	if toolName == "process_refund" {
		if amount, _ := toolInput["amount"].(float64); amount > 500 {
			return Handoff{
				To: "human_manager",
				Package: map[string]any{
					"customer_id":        session.VerifiedCustomerID,
					"amount":             amount,
					"root_cause":         session.Investigation,
					"recommended_action": "approve_refund",
				},
			}
		}
	}

	return Allow{}
}

Anti-patterns

Ловушка	Почему не работает	Верный паттерн
Сделать проверку «обязательной» через system prompt	У промптов ненулевая доля сбоев; «обязательно» — рекомендация	Программные ворота физически блокируют вызов инструмента
Добавить few-shot примеры правильного порядка вызовов	Повышают вероятность, но не дают гарантии	Ворота для финансов/личности; few-shot — для классификации
Эскалировать фразой «нужна помощь человека»	У человека нет контекста — расследование с нуля	Структурированная эстафета: ID, первопричина, находки, действие

Exam traps

Ловушка	Почему не работает	Верный паттерн
Валидировать null-ID в самом `process_refund`	Ловит ошибку на 3 шага позже источника	Ворота на выходе `lookup_order`: ошибка и остановка сразу
Постфактум-аудит вместо предзащиты	Деньги уже ушли — это восстановление, не предотвращение	Предвызовная проверка (pre-call guard) до движения средств

Практическое задание (T4)

Хранить verified_customer_id в состоянии сессии.
Построить ворота, блокирующие lookup_order и process_refund, пока get_customer не установит флаг.
Проверить обход: клиент сам называет order ID — ворота всё равно срабатывают.
Реализовать эстафету для возвратов >$500 с полным пакетом.
Сравнить с подходом «только промпт»: 10 тестов, посчитать обходы.

Проверка знаний

Агент поддержки клиентов

12% обращений пропускают get_customer и вызывают lookup_order лишь по имени клиента. Иногда путают аккаунты и оформляют неверные возвраты. Что сделать?

A Добавить программное предусловие, блокирующее lookup_order/process_refund до подтверждённого ID
B Усилить system prompt, заявив, что проверка обязательна
C Добавить few-shot примеры правильного порядка
D Сделать классификатор маршрутизации доступных инструментов

Агент поддержки клиентов

Процесс из 5 шагов (identify → lookup → assess → calculate → process_refund). У 8% возвратов customer_id равен null из-за тихого сбоя lookup_order тремя шагами ранее. Что исправить?

A Добавить в process_refund валидацию, отклоняющую null-ID
B Добавить в system prompt проверку non-null перед возвратом
C Добавить логику повторов на шаге lookup_order
D Ворота на выходе lookup_order: при null — ошибка и немедленная остановка процесса

Агент поддержки клиентов

Правило: возврат не может превышать сумму заказа. Сумма заказа берётся из lookup_order (шаг 2), размер возврата — из calculate_compensation (шаг 4). Иногда process_refund превышает заказ из-за ошибок расчёта. Что сделать?

A Добавить инструкцию-валидацию в calculate_compensation
B Предвызовная проверка (pre-call guard) на process_refund, программно сравнивающая обе суммы до исполнения
C Постфактум-аудит завершённых возвратов
D Логировать сумму заказа в состояние сессии для справки