Сложная часть AI-агента — не исполнение, а планирование
Разработчик abdullahsaad5 во второй части серии на Dev.to про свой CLI-агент формулирует тезис жёстко: агент, который выполняет реальные действия в сотнях подключённых приложений, спотыкается не на execution, а на planning. Речь о plan mode — режиме, где LLM сначала исследует контекст и собирает план и только после явного одобрения пользователя трогает аккаунты.
Инструмент принимает предложение на естественном языке, через LLM выбирает одно действие из каталога интеграций и исполняет его на реальных данных пользователя — от CRM вроде Salesforce до raw API fallback, когда готового action нет. Два режима сосуществуют: direct mode с немедленным запуском и plan mode, где до одобрения ничего не меняется в подключённых сервисах.
CLI-агент с реальными действиями: зачем вообще plan mode
В direct mode агент сразу идёт в исполнение — автор сравнивает разработку такого режима с «одним послеобеденным сеансом». Plan mode, напротив, потребовал «большую часть месяцев»: слишком много мест, где ошибка в плане означает не баг в логах, а изменение чужих данных.
Контракт plan mode близок к тому, что разработчики уже знают из других agentic-инструментов, но без привязки к конкретным IDE в тексте поста. Пользователь сам переключает режим через элемент управления в интерфейсе — агент не классифицирует запрос как «опасный» и не включает планирование автоматически. Пока план не подтверждён, поверхность риска ограничена authorized actions и connections, которые видны в черновике шагов.
Главный выигрыш review — не красивый markdown, а возможность поймать wrong-org и wrong-connection до первого деструктивного вызова.
Planner и executor: почему одного system prompt мало
Первая архитектура держала plan и direct на одном агенте. Режимы мешали друг другу: в direct тянуло к действию, в plan — к излишней осторожности, и оба дрейфа проявлялись в неподходящем контексте.
Вторая итерация вынесла plan mode в отдельного агента со своим system prompt. Planner только исследует и формирует план — к исполнению он архитектурно не подключён. Это не «запрет в промпте», а разделение ролей на уровне сессий.
Третья проблема оказалась содержательной: planner «придумывал» шаги, не зная фактического состояния org — типичный пример с объектами и полями Salesforce. Ответ — read-only tools: перед записью шагов агент читает реальное состояние платформы.
Четвёртая — UX вопросов. Сырые вопросы к пользователю тормозили планирование и провоцировали плохие ответы. Решение — вопросы с рекомендованным ответом по умолчанию (prefill): человек подтверждает или правит, а не набирает контекст с нуля.
При handoff planner и main agent живут в разных сессиях и с разной памятью. Вместе со списком шагов executor получает assumptions, risks и reasoning в сжатом виде — по оценке автора, около девяноста процентов контекста, накопленного при планировании.
Как выглядит план, который можно прочитать до запуска
План — список шагов на plain English, не JSON для машины. Там, где это важно, фигурируют конкретные имена custom objects и полей, blast radius (сколько записей или людей затронет шаг) и alias подключения — человекочитаемое имя соединения вместо сырого id. Если подходят несколько connections, в плане появляется selectable pick: это прямое продолжение темы wrong-account из первой части серии.
Критичность шагов кодирована явно:
| Уровень | Смысл | Если шаг падает |
|---|---|---|
| must | ядро плана | весь план провален |
| should | важно, но не несущее | retry или продолжить — выбор пользователя |
| could | опционально | уведомление, план идёт дальше |
К каждому шагу прикрепляется evidence из исследования. При переходе к следующему шагу executor показывает evidence предыдущего. Если пользователь возражает («этот шаг уже сделан»), агент сверяется с платформой — данные важнее уверенного утверждения человека.
План — граф зависимостей, а не плоский список: независимые шаги могут идти параллельно, а destructive step ставит на паузу весь план. План можно отменить или перепланировать в той же сессии; main agent умеет адаптировать устаревший план или запросить новый у planner.
Destructive steps и границы автоматической безопасности
Для predefined actions операции add, delete и rename автоматически помечаются как destructive — на таком шаге исполнение останавливается до подтверждения.
Для raw API fallback два слоя: агент оценивает intent и effect всей команды, а не только HTTP-verb, плюс отдельный command classifier. Автор протестировал классификатор на 1200 разных командах и получил точность около 99% — это внутренний тест автора, не независимый бенчмарк рынка.
Ограничения названы честно. Prompt injection не решён: агент читает emails, docs и страницы. Plan mode сужает поверхность, но не отменяет чтение внешнего контента. Planner может выбрать не то приложение или connection — внутри planner это не перехватывается; страховка — человек, который читает alias и org в плане, а не жмёт approve на автомате.
Пять уроков для тех, кто строит agentic CLI
Автор сводит опыт к короткому чеклисту для разработчиков агентов:
- Разделить агента, который думает, и агента, который действует.
- Не планировать против мира, который не исследован — read-only research до первого шага.
- Задавать вопросы с prefill вместо пустых форм.
- Держать verified evidence выше уверенных утверждений — в том числе выше pushback пользователя без проверки.
- Структурные гарантии plan mode узки и реальны; всё остальное остаётся на человеке, который читает план.
Для vibe coding и оркестрации это практическая схема: отдельные system prompts под роли, handoff с reasoning, human-in-the-loop на destructive steps и при неоднозначных connections — не абстрактное «агент всё сделает сам», а инженерный компромисс с явными дырами.
Материал опубликован на Dev.to 25 июня 2026 года; время чтения в карточке поста — 10 минут. Это вторая часть серии: первая посвящена direct mode, проблеме wrong-account и alias для подключений — факты о ней в этом тексте только в том объёме, в каком на них ссылается автор plan mode.
Источники
- The hard part of my AI agent wasn't doing the work, it was planning it — abdullahsaad5, Dev.to, доступ 2026-06-25 UTC