Как научить агента отвечать на открытые вопросы (FPF)

Работа с AI-агентами · 23 сентября 2026

AI-агент — программа, которой можно поручить работу с документами, данными и инструментами. Он помогает с разработкой программ, предпринимательскими и личными задачами. В ходе работы может возникнуть открытый вопрос: нет проверенного ответа или решение ещё не принято. Тогда агент может придумать ответ и ошибиться либо остановиться и спросить вас. Во втором случае вам придётся заново вникать в задачу и принимать промежуточное решение — это точка решения человеком (human gate). Фреймворк первых принципов (FPF) Анатолия Левенчука — набор способов разбирать такие вопросы. В своего агента можно установить сторонний скилл fpf-problem-solving, который помогает находить нужные разделы FPF. Агенту можно поручить применить FPF и объяснить, на чём основан его совет.

Пример ситуации с открытыми вопросами на основе системы обработки заявок с сайта

Представим вымышленный бизнес: клиенты оставляют заявки на сайте, а сотрудники видят их в системе учёта заявок (CRM). Предприниматель просит агента доработать обработку повторных обращений.

Клиент может отправить одну и ту же просьбу дважды — например, потому что ему ещё не перезвонили. А может вернуться с новым заказом. Телефон в обоих случаях тот же, но в первом случае нужно продолжить работу по прежней заявке, а во втором — принять новую.

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

Быстрых ответов несколько:

• Каждый раз создавать новую заявку. Новое обращение будет видно сотрудникам, но клиенту могут дважды позвонить по одной и той же просьбе.
• Объединять всё с одним телефоном за сутки. Повторов станет меньше, но два разных заказа одного клиента могут попасть в одну заявку.
• Добавлять повторное обращение комментарием к прежней заявке. История останется в одном месте, но новая просьба может затеряться в комментариях.
• Создавать новую заявку с пометкой «возможный повтор». Менеджер увидит оба обращения и решит, связаны ли они. На эту проверку нужно время.
• Передавать похожие обращения менеджеру до создания новой заявки. Он сначала разберётся, что хотел клиент, но до этого новый заказ будет ждать.

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

Как агент подготовит решение по FPF

В FPF есть разные методы для разбора задач и принятия решений. Здесь используем один из них: он помогает проверить, насколько предложенный совет полезен и выполним. Совет «пусть менеджер разберётся» требует ответить на вопросы: кто именно это сделает, сколько времени потребуется и что будет с заявкой во время ожидания.

Учебный пример ответа агента:

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

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

Нужно ваше решение: готовы ли вы к лишним заявкам в списке, чтобы уменьшить риск пропустить новый заказ? И кто сможет их разбирать? Если свободного сотрудника нет, вариант с ручной проверкой придётся пересмотреть.

Здесь human gate возникает при изменении системы: предприниматель выбирает, какая ошибка менее опасна для его бизнеса, и решает, кто будет проверять повторы. Агент уже подготовил варианты и объяснил последствия. После запуска менеджер будет решать другой вопрос — связаны ли конкретные обращения клиента.

Предположим, предприниматель согласился и назначил менеджера. Тогда для каждого нового обращения правило такое:

• Сохранить его отдельной заявкой.
• Если в течение суток совпали телефон и текст, поставить пометку «возможный повтор» и добавить ссылку на прежнюю заявку.
• Менеджеру проверить помеченные заявки: повтор прежней просьбы объединить с её историей, новый заказ оставить отдельно.

Совпадение телефона и текста — лишь повод для проверки. Клиент может повторить просьбу другими словами или сделать два разных заказа с одинаковым текстом.

Как проверить выбранное правило

До запуска попросим агента проверить три ситуации:

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

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

Технические детали и схема — для разработчиков

По условию примера каждая отправка формы получает номер (event_id), который не меняется при повторной доставке сообщения. Он помогает заметить технический повтор. Но разные номера ещё не означают разные потребности: клиент мог дважды отправить одну и ту же форму. Совпадение телефона тоже не доказывает дубль: один человек может оставить две разные заявки.

Запись в журнале ещё не означает успешную обработку. Если карточка не создана из-за сбоя, повторная доставка должна позволить завершить обработку. Если карточка создана, но ответ CRM потерян, система сначала восстанавливает результат предыдущей попытки по event_id. Так повтор не приводит ни к потере заявки, ни к созданию второй карточки. Это условие безопасного повтора, описанное в разборе повторной обработки запросов AWS.

Проверки реализации

Ситуация	Ожидаемый результат
Первая доставка сообщения	Создана одна карточка; её связь с event_id сохранена
Повтор после успешного создания карточки	Доставка записана в журнал; второй карточки нет
Сбой после записи доставки в журнал, до создания карточки	Повтор завершает обработку; в CRM появляется одна карточка
Карточка создана, но ответ CRM потерян	Система находит результат предыдущей попытки; второй карточки нет
Новый event_id, прежняя потребность, тот же телефон и текст в течение суток	Создана карточка с меткой и ссылкой; менеджер может объединить историю обращений
Новый event_id, другая потребность того же клиента	Создана отдельная карточка; даже при совпадении текста метка не вызывает автоматического объединения
Сообщение без event_id	Сообщение сохранено для ручного разбора

Где ещё это полезно

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

Что здесь добавляет FPF

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

FPF помогает выбрать способ разбора под конкретный вопрос. Для рекламы или личного расписания понадобятся другие сведения и, возможно, другие методы. Ценность такого разбора — в подготовленном решении и понятных основаниях; результат зависит от доступных данных и того, как агент применил метод.

Такой подход может снизить нагрузку при участии человека в работе агента (Human-in-the-Loop, HITL). Если агент обращается к вам с каждым открытым вопросом, работа прерывается, а вам приходится восстанавливать контекст. С FPF агенту можно поручить сначала проверить доступные сведения и сравнить варианты: часть вопросов разобрать самостоятельно в пределах заданных правил и полномочий, а остальные передать вам с контекстом, рекомендацией и её основаниями. Это способ сократить лишние остановки и время на подготовку решения в human gate.

FPF не даёт агенту недостающих фактов или права менять бюджет и договорённости. Если факта не хватает, агент указывает, что проверить; если нужен ваш выбор — предлагает варианты. Для простой задачи такой разбор избыточен.

Как я ставлю задачу агенту

Если агенту доступны материалы FPF, например через скилл ниже, короткого запроса может хватить. Я ставлю обычную задачу и добавляю:

Вот три запроса с дополнительными условиями:

• Разработка: «Предложи правило для повторных обращений в CRM: когда создавать новую карточку, когда связывать её с прежней, а когда передавать решение менеджеру. Сравни цену ошибок и покажи, как проверить выбранное правило. Используй FPF».
• Предпринимательство: «Помоги выбрать небольшой тест рекламы по данным прошлых кампаний. Сравни стоимость вариантов, назови недостающие данные и предложи, как проверить результат. Используй FPF».
• Личные дела: «Помоги распланировать неделю по моему календарю и списку дел. Покажи накладки и варианты переноса; не меняй договорённости с людьми без моего решения. Используй FPF».

Если задаче нужны более подробные условия, я пишу так:

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

Скилл для работы с FPF

Скилл агента — готовая инструкция для определённого типа задач. Если ваш агент умеет устанавливать скиллы, можно добавить fpf-problem-solving от CodeAlive-AI, который помогает ему находить нужные разделы FPF:

npx skills add CodeAlive-AI/ai-driven-development --skill fpf-problem-solving

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

Термины

• Фреймворк первых принципов (FPF) — набор способов разбирать вопросы и проверять основания решений.
• Система учёта заявок (CRM) — программа, в которой команда ведёт карточки заявок и историю обращений клиентов.
• Номер сообщения (event_id) — идентификатор отправки формы; в условии примера он остаётся тем же при повторной доставке сообщения.
• Скилл агента — готовая инструкция для определённого типа задач.
• Открытый вопрос — в задаче AI-агента вопрос, на который нельзя ответить по доступным проверенным данным или принятому правилу. Чтобы продолжить, нужно проверить факт, сравнить варианты или получить решение человека.
• Точка решения человеком (human gate) — остановка работы агента, после которой дальнейший шаг зависит от решения или подтверждения человека. Если агент не передал контекст и варианты, человеку приходится разбираться в задаче заново.
• Участие человека в работе агента (Human-in-the-Loop, HITL) — организация работы, при которой человек включается в процесс: проверяет результат, уточняет условия или подтверждает действие. Human gate — конкретная точка такого участия, в которой агент ждёт решения человека.

Источники

• Анатолий Левенчук, First Principles Framework — первоисточник, авторство и назначение FPF.
• How to use FPF and its DPF Suites — рекомендация автора начинать с конкретной ситуации и выбирать подходящий способ работы.
• FPF Core Specification — подробное описание способов уточнять вопросы и проверять решения; документ объёмный и обновляется.
• FPF C.11.DUA: Make Advice and Evidence Demands Worth Their Burden — метод оценки полезности совета и работы, которую он требует от получателя; в примере использованы разделы 4.1, 4.2 и 4.4.
• AWS Builders’ Library: Making retries safe with idempotent APIs — связь идентификатора запроса с результатом операции и обработка повторов после сбоев.
• LangChain: Human-in-the-loop — пример реализации HITL: агент приостанавливается, а человек подтверждает, меняет или отклоняет предложенное действие либо отвечает на вопрос.
• CodeAlive-AI, fpf-problem-solving — сторонний скилл и инструкция по установке.

Статус: статья ещё в работе и доступна по прямой ссылке.

Автор: Данил Письменный · Дата: 23 сентября 2026 · Обновлено: 4 октября 2026