Планирование

Этап 2: планирование и координация​

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

Планирование — пауза между знанием и действием. У плана две задачи, и это разные задачи.

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

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

Методология

Допуск по плану — это одобренный контракт выполнения

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

Цена планирования​

План — ещё и текст, попадающий в контекстное окно до любого шага выполнения. У этого есть две стороны.

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

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

Когда план оправдывает затраты​

Планирование стоит токенов, времени и привязывает к ещё не проверенному решению. Эти затраты окупаются при трёх условиях.

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

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

Оценщик может прочитать план, и его ответ должен быть верным. Здесь нужны две вещи.

План должен попасть к оценщику в понятной ему форме. Преобразуй утверждение в форму проверки: тест исполняет код, проверка типов читает сигнатуру, предикат ограничения проверяет утверждение плана. Ни один из них не читает предложение. Формулировка «Одно поле на странице оформления заказа с тестом для действующего и просроченного кода» даёт проверке то, что можно выполнить; «Правила ценообразования не должны меняться» не даёт ничего, пока ты не свяжешь эту строку с предикатом (нет изменений в pricing/) или вопросом (меняет ли это правила ценообразования? да или нет). Такое связывание — твоя работа, и оно идёт первым: перевод прозы в формальную форму остаётся слабым звеном; в исследованиях семантическая корректность составляла от 24% до 35%.³

Когда проверка требует суждения, а не установления факта — расширяются ли границы задачи, обратим ли этот шаг, — задай вопросы о состоянии плана и поручай типизированной модели принятия решений отвечать на них с вероятностями: человек читает вопрос, код ветвится по ответу, а уверенность можно сравнить с порогом. Оценочные функции легко обмануть удалением требований. Барьер на основе типизированного состояния отказал в выдаче оценки для всех 26 вариантов, оптимизированных за счёт пропусков: именно отказ, а не более высокий балл, — поведение, которое нужно от барьера допуска.⁴

Ответ должен предсказывать успех работы. Оценщик, который пропускает почти всё, хуже отсутствия оценщика: сгенерируй десять планов, и он выберет самый убедительный по тексту, а не работающий. Дополнительные попытки тогда покупают уверенность, а не корректность.⁵ Отключение проверки снижает успешность планирующего агента на 12,9 процентного пункта.⁶ Выигрыш заключён в проверке, а не в плане: план хорош лишь настолько, насколько хороша его проверка. Выбор разобран в главе «LLM-оценщики».

Когда планирование стоит пропустить​

Если обратить эти условия, те же критерии подскажут, когда планирование не нужно.

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

План сохраняют дольше, чем он полезен. План — ставка на то, как развернётся задача. Если держаться его после того, как среда ему противоречит, ставка превращается в невозвратные затраты: агент защищает план вместо пересмотра, а раннее труднообратимое решение усиливается на протяжении всего выполнения.⁹ После некоторой границы, зависящей от сложности задачи, дополнительное планирование тоже перестаёт помогать и начинает вредить: кривая загибается вниз так же, как для длины рассуждений.¹⁰ Считай план предварительным и пересматривай его с учётом того, что выясняется в процессе работы.

Оценщик, которого никто не проверял. Барьер допуска — измерительный инструмент, а инструменты дрейфуют. Вердикты меняются вместе с версией лежащей в их основе модели и становятся мягче по мере роста возможностей агентов. А комиссия с общими доказательствами имеет и общие слепые зоны.¹¹ Ошибки проверяющего не оставляют следов внутри цикла, поэтому выборочно сопоставляй решения допуска с тем, что в итоге было выпущено («LLM-оценщики»).¹²

Один план разделён между агентами, которые не видят друг друга. Передача частей плана параллельным субагентам выглядит как масштабирование. Обычно она дробит неявные решения — о стиле, границах, именовании — на результаты, которые затем никто не может согласовать.¹³ Делегирование подходит для независимых направлений работы, а не для ещё не согласованного плана.

В небольшой и очевидной работе планирование — чистые накладные расходы.¹⁴

Планирование завершено, когда…​

Это определяют два вопроса.

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

Дёшево ли пересмотреть план? Если адаптация стоит одного шага, план — опора. Если ради адаптации нужно начинать сначала, план — ловушка.

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

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

Планирование завершено, когда выполнение может начаться с явно заданного контракта — оценённого там, где есть оценщик, — вместо незавершённого обсуждения. Размер единиц работы и проверка на границах этапов разобраны в главах «Организация работы» и «Контрольные точки с участием человека».

Примечания​

1. Chen et al. (2026), Comparing Human Oversight Strategies for Computer-Use Agents — планы «ограничивали незапланированные действия, но оставляли без внимания не перечисленные меры защиты, а предварительное одобрение ослабляло контроль во время выполнения». ↩

2. Prasad et al. (2024), ADaPT: As-Needed Decomposition and Planning with Language Models — разбиение на ограниченные подзадачи при неудаче выполнения превосходит монолитное выполнение за один проход на 28,3% в ALFWorld, 27% в WebShop и 33% в TextCraft. ↩

3. Dantas et al. (2026), Toward Safe LLM Agents: A Survey of Specification, Verification, and Enforcement — перевод естественного языка в формальную форму достигает лишь 24–35% семантической корректности, а блокирование 94% небезопасных действий всё ещё может оставлять долю безопасного завершения ниже 5%. ↩

4. Manchuliantsau (2026), Win by Silence: Deletion Non-Monotonicity, Autonomous Exploitation, and Typed-State Gating in LLM Plan Evaluation — при удалении требований планы получают более высокие оценки; барьер на основе типизированного состояния «отказал в выдаче оценки для 26 из 26 вариантов с умолчаниями», без ложных приостановок для добросовестных планов. ↩

5. Zhang et al. (2025), ROC-n-reroll: How verifier imperfection affects test-time scaling — «точность этих методов на уровне отдельных примеров точно характеризуется геометрией ROC-кривой проверяющего», а результаты при больших вычислительных затратах нельзя предсказать по прогонам с малыми затратами. ↩

6. Zhang et al. (2026), PIVOT: Bridging Planning and Execution in LLM Agents via Trajectory Refinement — пользу даёт этап проверки: его отключение снижает результат Opus 4.6 на 12,9 процентного пункта, а автономный вариант сохраняет преимущество лишь пока остаётся внешняя проверка. В том же исследовании 100% блоков рассуждений приходятся на первый ход ассистента, а 99,2% шагов генерации плана обходятся без них, поэтому увеличение бюджета рассуждений не помогает: рассуждение нужно размещать в точках принятия решений. ↩ ↩²

7. Stechly, Valmeekam & Kambhampati (2024), On the Self-Verification Limitations of Large Language Models on Reasoning and Planning Tasks — «значительное падение результативности при самокритике и значительный рост при надёжной внешней проверке». ↩

8. Huang et al. (2023), Large Language Models Cannot Self-Correct Reasoning Yet — «LLM с трудом исправляют собственные ответы без внешней обратной связи, а иногда после самокоррекции результаты даже ухудшаются»; Kamoi et al. (2024), When Can LLMs Actually Correct Their Own Mistakes? — ни одна предшествующая работа не демонстрирует успешную самокоррекцию по обратной связи от LLM, полученной запросом, за исключением особенно подходящих для этого задач; коррекция работает при надёжной внешней обратной связи. ↩

9. Wang et al. (2026), Why Reasoning Fails to Plan: A Planning-Centric Analysis of Long-Horizon Decision Making in LLM Agents — локальная пошаговая оценка порождает жадную стратегию, которая рано принимает необратимые решения и усиливает ошибку на длинном горизонте; Shojaee et al. (2025), The Illusion of Thinking — по мере роста сложности усилия на рассуждение падают, несмотря на оставшийся бюджет. ↩

10. Zhou et al. (2026), When More Thinking Hurts: Overthinking in LLM Test-Time Compute Scaling — предельная полезность становится отрицательной примерно после 12 тысяч токенов рассуждений, а переходы от верного ответа к неверному начинают превосходить обратные примерно после 7 тысяч; Chen et al. (2024), Do NOT Think That Much for 2+3=?. ↩

11. Li et al. (2026), Frozen Judges, Moving Agents: Version-Dependent LLM-Judge Error and the Limits of Judge-Assisted Agent Evaluation — интервальные оценки, основанные только на оценщике, объявляют улучшения, которые не подтверждаются интервалами по выполнению, а ложное принятие неработающих патчей растёт вместе с возможностями агента. Достоверность оценщика и доказательства для комиссии разобраны в главе «LLM-оценщики». ↩

12. Moya et al. (2026), Verifier Errors in RLVR: Reward Hacking, Limits of Feedback, and Selective Control — ошибки проверяющего нельзя обнаружить только по обучающему сигналу, поэтому выборочный контроль зависит от внешних аудитов. ↩

13. Cognition (2025), Don't Build Multi-Agents — действия несут неявные решения, поэтому субагенты, не видящие работу друг друга, выдают противоречивые результаты, которые невозможно согласовать. ↩

14. Huang et al. (2024), Understanding the Planning of LLM Agents: A Survey — накладные расходы на планирование могут вредить простым задачам, где польза не покрывает затрат; Anthropic (2024), Building Effective Agents — успех «не в создании самой сложной системы, а в создании подходящей системы для твоих потребностей». ↩

15. Paglieri et al. (2025), Learning When to Plan: Efficiently Allocating Test-Time Compute for LLM Agents — «постоянное планирование вычислительно дорого и ухудшает результаты на длинных горизонтах, а полное отсутствие планирования дополнительно ограничивает результативность»; выигрывает промежуточная, обученная частота планирования. ↩