Продолжаю делиться граблями, на которые я наступил в Claude Code. Как я ловил API Error: Stream idle timeout - partial response received

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

Проблема такая: оркестратор собирает SEO-статью на 8 000 слов, отдаёт редактору, пробует сохранить. Через 30 секунд тишины: API Error: Stream idle timeout — partial response received

Файл создан, но обрезан на месте, где стрим ушёл в idle.

❌ Первая очевидная неверная гипотеза: большой Write

Значит надо резать на чанки. Снизил лимит 15 000 → 8 000 → 6 000 → 5 000. Таймаут повторялся. Значит, дело не в размере записи.

✨ Настоящая причина: пересборка текста

Оркестратор не копировал готовый текст субагента. Он его пересобирал: переоформлял, перенумеровывал 28 сносок, «причёсывал» заголовки. Пока модель думала над форматированием, токены в стрим не эмитились. API считал соединение мёртвым и закрывал.

Решение РАЗ: passthrough + чанки ≤ 3 000

Вводим правило rules/common/safe-file-save.md:

➡️ Субагент возвращает строку оркестратору. Оркестратор копирует её в Write байт-в-байт — без «улучшений».
➡️ Разбиение планируется один раз до первого Write, потом проходится механически.
➡️ Лимит 3 000 символов на Write/Edit — потолок, при котором стрим не уходит в idle при честном passthrough.
➡️ Перед каждым Edit — сообщение 💾 Чанк K/M…. Иначе пользователь видит тишину и прерывает.

Если таймаут повторяется на 3 000 — спуск на 1 500. Если и там падает — это сеть, не контент.

И Recovery для обрезанных файлов

Повторный Write поверх частичного файла затирает уже сохранённое. Поэтому:

➡️ ls — проверить, что файл есть
➡️ Read — измерить длину
➡️ Edit (append) с точки обрыва, чанки по 3 000

Никогда не стартовать Write заново по тому же пути.

⭐️ Вторая волна: редактор

После фикса записи таймаут вернулся на возврате субагента-редактора. Вход 18 000 символов, выход 18 000 переписанного текста + отчёт «до/после» + метрики. Prefill и генерация занимают десятки секунд без эмита токенов. Retry не помогал: корень — объём выхода.

Решение ДВА: diff-mode

Вводим правило rules/common/editor-diff-mode.md. Редактор возвращает не переписанный текст, а список правок:

=== EDIT id=1 op=replace ===
FIND: Данное решение является инновационным продуктом
REPLACE: VK Cloud управляет инфраструктурой — от ВМ до managed-БД
REASON: редполитика + инфостиль
=== END EDIT ===

Лимиты: ≤ 60 правок, FIND ≤ 300, REPLACE ≤ 500, суммарный выход ≤ 8 000. Оркестратор парсит блоки и применяет через Edit.

Матрица по длине для глубокой редактуры:

➡️ ≤ 4 000 → классический
➡️ 4 000 – 20 000 → diff-mode
➡️ > 20 000 → секционный (одна H2 за вызов)

Пороги ниже именно для тяжёлых режимов — они удваивают выход за счёт отчёта «до/после».

Что в итоге то:

Два источника одной ошибки: оркестратор переформатирует перед Write, редактор генерирует слишком много на выход. Лечатся по отдельности: passthrough + чанки для записи, diff-mode для правок. Recovery закрывает остаточные случаи, когда таймаут всё-таки прилетел.

Я вроде не курю, но захотелось.

#ai_agents

ИИ не заменил менеджеров. Он сделал их узким местом

Картинка из моей работы. Облачная конференция, сессии наших спикеров на других ивентах, лендинги, статьи в СМИ и блог, Хабр. При производстве практически каждой единицы контента используется ИИ — целая фабрика агентов. Но между ИИ и готовым результатом есть человек, в данном случая я. Человек смотрит, проверяет, принимает решение. И этот ресурс ничем не масштабируется.

И это не то, чтобы только у меня подгорает. На прошлой неделе в HBR вышел материал Managers Are Struggling to Keep Up with the AI Productivity Boom. Открывается цитатой менеджера: "каждые тридцать минут кто-то создаёт что-то, что я должен посмотреть". CIO в свежей колонке формулирует ещё жёстче: исполнение перестаёт быть ограничением, дефицитным ресурсом становится суждение. Производство чего либо-ускорилось в разы. Но при этом никто не перестраивает поток работы под ИИ, практически всегда остаются те же цепочки согласований, что были до.

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

Короче, производство ускорили на порядок, а пропускную способность решений — процентов на двадцать. Разница оседает у тебя на столе. И, надо признать, в этом нет ничьего злого умысла. Просто индустрия выкатила инструмент, который сжимает один этап цепи, и почему-то решила, что от этого ускорилась вся цепь. Не ускорилась. Узкое место мигрировало. Сейчас оно сидит на менеджерском стуле и проверяет то, что выдала модель.

💡Что могу посоветовать. «Делегируйте больше», «фокусируйтесь на главном», «приоритизируйте» — это всё сработает только, если у вас есть большая команда.

Первое — перенести принятие решений из своей головы в артефакты. Если ты ревьюишь каждый текст как индивидуальный кейс, ты держишь критерии в рабочей памяти и тратишь её на каждой итерации заново. Если эти же критерии оформлены как явный чек-лист, гайдлайн, или, в случае Claude Code, как скилл — половина решений принимается до того, как текст дошёл до тебя.

Второе — поменять метрику собственной нагрузки. Для контент-менеджера, например, это значит перестать мерить себя «количеством опубликованного» и начать мерить «сколько решений приняли за день» и «сколько из них пришлось переоткрывать». Это звучит абстрактно, но это единственная метрика, которая показывает, упёрся ли ты в производство (масштабируется ИИ) или в суждение (не масштабируется).

Третье — называть проблему вслух перед руководством. Не как жалобу, а как операционную диагностику: «У нас не дефицит производства, у нас дефицит пропускной способности решений. Можем обсудить, как её расширить — либо новый сотрудник с делегированной зоной ответственности, либо перенос части решений в политику агента».

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

#ai