В Devin Local две настройки часто сливают в одну "ручку автономности", и это первая ошибка. На деле их две, и они ортогональны: agent mode отвечает на вопрос, что агент делает, а permission mode - что из этого запускается без подтверждения. Путаница между осями и рождает большинство жалоб на "слишком робкого" или "слишком борзого" агента.
Наивная модель понятна: есть один ползунок от осторожного к автономному, сдвинул - и агент стал смелее во всём сразу. Из неё растёт ожидание, что "включить Plan" сделает агента безопаснее, а "разрешить всё" заодно и переведёт его в режим планирования. Ожидание удобное и неверное.
Ломается оно на том, что оси отвечают на разные вопросы. Agent mode - это Normal, Plan или Ask: обычное исполнение, предварительный план перед действием (/plan) или ответ на вопрос без правок кода (/ask). Он про подход к задаче. Permission mode - это Normal, Accept Edits, Smart, Bypass или Autonomous: он про то, какие tool calls проходят без вопроса. Ask-режим ничего не разрешает и не запрещает - он просто не трогает код; Bypass ничего не планирует - он лишь снимает подтверждения. Две оси даже задаются по-разному: agent mode переключают slash-командами вроде /plan и /ask прямо в ходе диалога, а permission mode выбирают отдельно, как уровень доверия к сессии.
Развести их удобно по одной таблице, где видно, как permission mode обходится с двумя типами действий - правкой workspace и shell либо fetch. Normal спрашивает и то и другое. Accept Edits автоматом применяет правки, но спрашивает про shell. Smart применяет правки, а для остального быструю модель ставит решать, безопасно ли запускать без вопроса, и риск всегда спрашивает. Bypass автоматизирует всё. Autonomous автоматизирует shell и fetch внутри sandbox, но прямое редактирование всё равно спрашивает. Normal при этом и сам по себе неоднороден: чтение в текущем каталоге он пропускает молча, а запись и запуск спрашивает, так что даже "обычный" режим уже проводит границу между наблюдением и вмешательством.
Почему разведено на две оси, а не сведено к одному ползунку. Потому что "что делать" и "насколько свободно" - независимые решения. Исследовать незнакомый код можно осторожно через Ask или уже зная область через Normal, и это не про права. Давать автономию можно узко, только на правки, или широко, с shell в sandbox, и это не про подход. Один ползунок связал бы несвязанное и лишил бы вас половины полезных комбинаций - например, планирования с автоприменением правок или обычного исполнения под жёсткими deny.
Одно ограничение действует поперёк обеих осей и важнее их. Организационные deny и ask работают во всех режимах: ни Smart, ни Bypass, ни Autonomous не переопределяют политику, заданную администратором. То есть permission mode - это ваша свобода внутри рамки, а не сама рамка. Рамку ставит org-конфиг, и самый смелый режим её не двигает.
| Permission mode | Редактирование workspace | Shell/fetch |
|---|---|---|
| Normal | Запрос | Запрос |
| Accept Edits | Автоматически | Запрос |
| Smart | Автоматически | Модель решает; риск всегда спрашивает |
| Bypass | Автоматически | Автоматически |
| Autonomous | Direct edit спрашивает | Автоматически внутри sandbox |
Датированная оговорка касается Smart. Он распространяется постепенно и может ещё не появиться в вашем селекторе - его наличие проверяют в живом интерфейсе, а не по этой странице. Строить процесс на режиме, которого у вас пока нет, значит описывать чужую конфигурацию; пока Smart не виден, его роль закрывают Accept Edits плюс явные allow на безопасные команды.
Цена смешения осей конкретна. Ждать от Ask безопасности правок бессмысленно - он и так не правит, но и не мешает вам думать, что "режим защищает". Считать Bypass планировщиком - получить агента, который сразу действует без плана и без подтверждений. А путать Autonomous с "делает всё сам" - забыть, что прямые правки в нём по-прежнему спрашивают, и удивляться запросу там, где ждали тишины. Каждая из этих ошибок стоит не сбоя, а потерянного времени: агент ведёт себя ровно по своей оси, а вы ищете причину не на той.
Проверять настройку стоит по обеим осям сразу. Назовите вслух две вещи: в каком agent mode вы работаете и какой permission mode активен. Затем сверьте ожидание с фактом на безопасном действии - попросите прочитать файл и запустить тест и посмотрите, что прошло молча, а что подняло карточку. Если картина не совпала с таблицей, вы перепутали ось, а не столкнулись с багом.
Типичные провалы всегда об одной подмене - две оси приняли за одну. "Включил Plan, а он всё равно пишет код" - Plan это agent mode, а правки разрешил permission mode. "Поставил Bypass, а он не планирует" - Bypass снимает подтверждения, план задаёт другая ось. "Autonomous, а спрашивает про edit" - так и задумано, это его намеренная граница. Признак один: настройку описывают, не сказав, о какой из двух осей речь. Назовите обе - и режим перестанет казаться капризным.