Planning и execution: как агент разбивает задачу и где ошибается

Planning execution AI agent — это цикл, в котором приложение принимает цель, строит ограниченный план, выполняет один шаг за раз и проверяет наблюдаемый результат. Список шагов от модели сам по себе не является рабочим планом: каждый шаг должен иметь вход, разрешение, критерий завершения и маршрут ошибки. Ниже — учебный контракт PLAN-STEP-7. Это авторский синтетический пример, а не измеренная работа клиентской системы.

Если вы ещё выбираете тип решения, начните с критериев выбора AI-агента. Вопросы внедрения для бизнеса в Армении собраны на странице AI-специалиста; эта статья отвечает на узкий технический вопрос о планировании и исполнении.

Проблема и требования

Представим задачу: сверить заявку поставщика с действующей записью в CRM и подготовить исправление. Модель может предложить «найти запись → сравнить адрес → обновить CRM → сообщить итог». Но запись может принадлежать другому tenant, быть устаревшей или измениться между чтением и записью. Поэтому план не должен автоматически становиться разрешением на действие.

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

Архитектура решения: PLAN-STEP-7

Авторская схема PLAN-STEP-7 связывает семь границ: bind → propose → validate → execute → verify → replan → close. Оркестратор хранит версию плана и состояние каждого шага. Модель предлагает последовательность и допустимые изменения, но сервер проверяет права и выполняет инструменты. После каждого действия проверка сверяет результат с системой назначения. Перепланирование разрешено только на основании нового наблюдения, в пределах бюджета и без расширения полномочий.

Такой цикл дополняет контракт вызова инструментов: tool calling описывает один вызов, а planning управляет связями и повторными решениями между вызовами. Для процесса с известными фиксированными шагами может быть достаточно детерминированной автоматизации.

Ключевые компоненты и контракт состояния

Planner получает только текущую цель, разрешённые инструменты и ограниченный контекст. Его результат — структурированный план: ID шага, зависимости, тип действия, ожидаемый факт, условие остановки. Внешний текст и вывод инструмента считаются данными, а не инструкциями по изменению полномочий.

Executor принимает ровно один готовый шаг. Он повторно проверяет identity, tenant, права и версию объекта перед записью. Нельзя доверять авторизации, выполненной только при составлении плана: состояние и разрешения могли измениться.

State store сохраняет taskId, planVersion, статусы шагов, идентификатор вызова, idempotency key, квитанцию и reason code. Для возобновления после сбоя нужен журнал завершённых действий, иначе повтор может создать вторую запись.

Verifier сравнивает результат с исходным критерием приёмки. HTTP 200 или фраза модели «готово» недостаточны. Для записи используйте read-back либо эквивалентное подтверждение назначения. При неопределённом исходе сначала согласуйте фактическое состояние, затем решайте о повторе.

Минимальный псевдокод

type Step = { id: string; dependsOn: string[]; action: string; expected: string };
async function runStep(task: Task, step: Step) {
  require(task.owner && task.planVersion && task.budget.remaining > 0);
  require(dependenciesVerified(step, task.receipts));
  const tool = registry.get(step.action);
  if (!tool || !policy.allows(task.user, task.tenant, tool)) return hold("forbidden");
  if (tool.isWrite && !task.approvalFor(step.id)) return hold("review_required");
  const key = `${task.id}:${task.planVersion}:${step.id}`;
  const result = await executeOnce(tool, key, task.scope);
  if (result.unknown) return reconcileBeforeRetry(key);
  const verified = await verifyExpected(step.expected, result);
  await receipts.save({ key, verified, planVersion: task.planVersion });
  return verified ? "next_step" : "replan_or_review";
}

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

Где planning и execution ошибаются

1. План выглядит правдоподобно, но зависит от несуществующего факта. Проверьте входные данные до исполнения первого зависимого шага.
2. Модель пропускает зависимость. Executor блокирует шаг, пока квитанции предшественников не подтверждены.
3. Права меняются после планирования. Проверка политики проходит перед каждым вызовом, а не один раз в начале.
4. Шаг записи завершается таймаутом. Исход неизвестен; сверка по ключу и read-back предшествуют повтору.
5. План бесконечно переписывается. Ограничьте число replans, стоимость и длительность; после лимита передайте задачу человеку.
6. Новый план расширяет scope. Любое новое действие, источник или tenant требует отдельного разрешения.
7. Исполнитель объявляет успех по тексту модели. Закрывайте задачу только по наблюдаемым критериям и квитанциям.

Тестирование и production-чек

Соберите fixtures: обычное завершение, пустой источник, устаревшая версия CRM, чужой tenant, отказ политики, конфликт записи, таймаут до и после действия, повтор того же шага, ошибка в проверке результата и исчерпанный бюджет. Для каждой фикстуры укажите ожидаемый маршрут, квитанцию и запрещённый побочный эффект. Отдельно тестируйте planner на структуру, executor на права, verifier на фактический результат и весь цикл на восстановление после сбоя.

Перед ограниченным пилотом зафиксируйте владельца маршрута review, версии схем и политики, способ остановки, retention журнала, redaction и мониторинг доли задач, дошедших до проверенного финала, числа replans, отказов и неизвестных исходов. Эти показатели нужно измерять на собственных данных; здесь нет заявленных результатов. Начинайте с read-only сценариев, затем отдельно проверяйте операции записи.

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