Когда локальный coding agent срывает задачу, не меняйте одновременно модель, квантование, окно контекста и оболочку инструментов. Один и тот же плохой патч может быть вызван тремя разными слоями: модель или runtime слишком слабые для рассуждения, агент не видит нужные факты, либо Harness не может надежно применить правку, запустить команды, прочитать тесты и вернуть сигнал в следующую итерацию.
| Симптом | Что проверить первым | Проверка | Первое исправление |
|---|---|---|---|
| Агент проваливает крошечную правку еще до важной работы инструментов | Модель, runtime или квантование | Запустить тот же маленький кейс с более высокой точностью или hosted-базой, без лишних файлов | Изменить квантование, runtime или модель именно для этого типа задач |
| Он теряет нужный файл, правило или прошлое решение | Контекст и отбор фактов | Начать чистую сессию только с целевых файлов, теста и управляющего правила | Уменьшить контекст и загрузить точные доказательства вместо всего репозитория |
| Он объясняет верный фикс, но ломается на патче, команде или тесте | Harness и обратная связь инструментов | Сравнить намеренный патч модели с логом инструмента, stdout и результатом теста | Исправить применение diff, права, рабочую директорию, schema, тестовые хуки или retry-loop |
| Он начинает работать только после нескольких изменений | Диагноза еще нет | Вернуть тот же repo, task, clean session, file set и менять один слой | Повторить контрольный запуск перед новой настройкой |
Hosted-база нужна как измерительная линейка. Если минимальная задача проходит там и падает локально, локальный стек еще нужно разбирать по слоям. Если падают оба варианта, скорее всего, задача, входные файлы или критерии приемки описаны недостаточно. Останавливайте локальную настройку для этого задания, когда честное сравнение показывает, что качество, скорость или надежность инструментов не дотягивают до рабочего уровня.
Быстрая матрица диагностики
Локальный coding agent - это не только модель. В рабочем запуске участвуют веса, способ инференса, параметры контекста, выбор файлов, вызовы инструментов, редактирование файлов, shell-команды, тесты, права доступа, правила проекта, retries и review-сигналы. Снаружи все выглядит как «агент тупит», но причина может находиться в любом из этих мест.
| Слой | За что отвечает | Как выглядит сбой | Какой вывод рано делать |
|---|---|---|---|
| Модель и runtime | Размер модели, квантование, KV cache, CPU/GPU placement, сервер инференса | Слабое рассуждение на маленьких задачах, сломанный structured output, медленный decode, OOM при росте последовательности | Что все локальные модели бесполезны |
| Контекст и retrieval | Файлы, правила, история, summary, tool definitions, логи | Патч не в тот файл, забытый контракт, пропущенный символ рядом, чтение всего repo без прогресса | Что большее окно контекста решит проблему |
| Harness и tool feedback | Применение edits, command runner, permissions, schemas, tests, sensors, retry-loop | Объяснение верное, но diff не применился, cwd неверный, тест не прочитан, permission loop | Что модель не способна решить задачу |
Рабочий подход начинается с малого контролируемого сравнения. Выберите самый маленький реальный сбой, сохраните условия и поменяйте ровно один слой. Тогда результат станет диагностикой, а не очередной догадкой.
Запустите контроль с одной переменной
Честное сравнение требует одинакового репозитория, одинаковой задачи, одинаковой инструкции, одинакового набора файлов и чистой сессии. Сначала найдите минимальный воспроизводимый пример: один падающий тест, один файл, который агент постоянно путает, один command wrapper, одна permission-ошибка или одна правка, где рассуждение и выполнение расходятся.
Запишите модель, квантование, runtime, context length, загруженные файлы, Harness, точную команду, stdout, stderr, результат тестов и финальный патч. После этого меняйте только один параметр.
| Изменение | Что доказывает улучшение | Что оно не доказывает | | --- | --- | --- | --- | | Более высокая точность, большая локальная модель или hosted baseline | Модель или runtime были вероятным узким местом | Что контекст и Harness здоровы | | Чистая сессия только с целевыми файлами | Старый контекст, retrieval или история мешали задаче | Что маленькая модель выдержит весь repo | | Та же модель в другом Harness | Tool loop, edit application, tests или permissions могли быть причиной | Что новый Harness всегда лучше | | Та же задача, но модель только предлагает patch, а человек применяет его | Идея модели могла быть верной, а выполнение сломалось | Что ручное спасение должно стать процессом |
После такого контроля уже можно решать, остается ли задача локальной или ее нужно вести через cloud route. Материал о local versus cloud coding agents полезен после выявления слоя, а не до него.
Когда подозревать квантование или runtime
Подозревайте модельный слой, когда агент ошибается еще до того, как контекст или инструменты могли испортить результат. Примеры: он не удерживает два шага правки, ломает JSON tool call на маленьком prompt, повторяет простую syntax error, резко замедляется при увеличении sequence length или выходит за память во время prefill.
Квантование уменьшает память и вычисления, но оно может уменьшить точность рассуждения. Поэтому фраза «Q4 не справился» не равна выводу «локальные агенты не работают». Проверьте тот же tiny task на менее агрессивной квантовке, на coding-tuned модели большего размера, если железо позволяет, или на hosted baseline. Контекст в таком тесте должен быть минимальным, иначе вы одновременно проверяете retrieval.
В журнал runtime стоит включать model id, quantization format, context-length setting, inference server, device placement, memory pressure, prefill speed, decode speed, параметры KV cache и exact command, который прошел или упал. Без этих полей утверждение о квантовании остается впечатлением.
Когда подозревать контекст
Контекстный слой виноват, когда модель умеет решить маленькую изолированную задачу, но в репозитории теряет факты. Она редактирует соседний файл, игнорирует локальный контракт, забывает решение из начала сессии, не видит ближайший interface или читает все больше файлов без лучшего результата.
Контекст для coding agent - это не дамп всего проекта. Нужны целевые файлы, падающий тест, ближайшая schema, правило из AGENTS, relevant command output и короткий file map. Длинное окно полезно только тогда, когда нужная информация остается доступной, а не buried in the middle среди старых догадок.
Сделайте clean-session test: только target file, failing test, nearest type or interface и governing instruction. Явно запретите смотреть лишние директории. Если качество улучшается, лечите не модель, а отбор доказательств: меньше stale history, меньше широких summaries, больше точных ссылок на файлы, symbols и test output.
Когда подозревать Harness
Harness виноват, когда модель знает правильный фикс, но система вокруг нее не выполняет цикл. Она называет верный файл и пишет разумный diff, однако edit tool не применяет patch, command runner уходит в неверный каталог, permissions блокируют проверку, тестовый вывод не попадает обратно в prompt или retry-loop повторяет прежнюю ошибку.
Сравните мысль модели и фактический trace. Попросите ее выдать intended patch без применения, затем примените и протестируйте вручную или в другом Harness. Если идея работает, а автоматический цикл нет, ремонтируйте tool schemas, working directory, permissions, deterministic checks, sensors и review gates.
Хороший Harness не обязан быть сложным. Он должен надежно применять правки, запускать фиксированные команды, показывать модельной сессии реальные ошибки, иметь понятные stop conditions и не прятать test failures.
Соберите пакет доказательств
Пакет для команды или issue должен воспроизводить сбой без полного replay сессии. Он отделяет наблюдение от интерпретации.
| Поле | Что записать |
|---|---|
| Task | Минимальная repo-задача, где сбой повторяется |
| Model/runtime | Модель, квантование, runtime, placement, context-length |
| Context | Какие файлы, правила, summaries, history и logs были загружены |
| Harness | Tool wrapper, edit method, command runner, permissions, test command |
| Symptom | Точный сбой, а не объяснение |
| Tool log | Patch application, command output, test result, permission или schema error |
| Control comparison | Что осталось тем же, что изменилось, как изменился результат |
| First fix | Одна попытка исправления и ее pass/fail |
| Decision | Продолжать настройку, менять Harness, брать hosted baseline или остановить локальный путь |
Фраза «низкоточная локальная модель упала на no-context задаче, а более точная конфигурация прошла» полезна. Фраза «все quantized agents бесполезны» не помогает никому.
Настраивать, менять Harness или остановиться
После одного или двух контрольных сравнений выберите путь. Не продолжайте настройку только потому, что система кажется почти рабочей.
Настраивайте model/runtime, если сбой появляется до влияния context и Harness и улучшается на более сильной локальной базе. Меняйте квантование осторожнее, выбирайте модель с coding training, фиксируйте runtime settings и уменьшайте task boundary.
Сжимайте context, если hand-picked files помогают, а broad session портит работу. Нужны file map, exact tests, свежий command output и короткая история. Если маленький patch требует огромного окна, это симптом незавершенной диагностики.
Ремонтируйте Harness, если идея верная, но execution loop ломает задачу. Исправления находятся в schemas, edit application, command wrappers, permission policy, AGENTS guidance, sensors and review.
Берите hosted baseline как рабочий путь, если локальный стек после честного сравнения не держит качество или скорость. Если следующий вопрос уже про Claude Code против Codex, используйте Claude Code vs Codex. Если вопрос про usage meters и context accounting в Codex, смотрите Codex token usage. Для API-key spend подойдет Codex CLI token cost estimate.
Часто задаваемые вопросы
Квантование чаще всего ломает локальный coding agent?
Не само по себе. Квантование может снижать точность, но загрязненный контекст и слабый Harness дают такой же внешний симптом. Сначала проверьте tiny task с минимальным контекстом и более точной или hosted-базой.
Как понять, что проблема в контексте?
Запустите ту же задачу в чистой сессии с target files, nearest tests и governing rules. Улучшение означает, что широкая сессия могла содержать noise, stale history, retrieval miss или слишком много tool definitions.
Что считается Harness-сбоем?
Это ситуация, где intended fix разумен, но система выполнения не закрывает цикл. Failed patch, wrong cwd, permission loop, malformed tool call, ignored test output и retry without learning относятся сюда.
Нужно ли сразу переходить на Claude Code, Codex или другой hosted agent?
Нет. Сначала используйте hosted route как контроль. Если он проходит тот же минимальный task, а локальный путь после диагностики нет, отдайте именно этот task hosted route. Если оба варианта падают, уточняйте задачу, файлы и acceptance criteria.
Что отправлять в командный чат или issue?
Отправляйте model/runtime, quantization, loaded files, Harness, prompt, tool log, command output, test result и одно control comparison. Секреты и лишний приватный код не нужны.