Агенты, harness, автономная разработка — шпаргалка к собесу
Александр Птицын · Senior Frontend, AI-first · 1 Agent Loop · 2 Workflow vs Agent · 3 Harness · 4 Автономная разработка / software dark factory · 5 Оптимизация стоимости · 6 Локальные модели · 7 Реальные вопросы из базы собесов · 8 Каверзные follow-up · 9 Истории на 60 секунд. Фиолетовое — как это устроено у меня в проде (Nexus, Собесыч, Кабинет, база собесов). 23.09.2026
За 30 секунд — вся тема
- Agent loop — цикл «модель → вызов инструмента → результат обратно в контекст → снова модель», пока не выполнено условие остановки. Модель без состояния: всё состояние живёт в сообщениях и во внешней памяти (файлы, БД).
- Workflow ≠ agent. Workflow — шаги известны заранее и записаны кодом, LLM только один из шагов. Agent — модель сама решает следующий шаг. Правило: где путь известен — workflow (дешевле, предсказуемее); агент только там, где путь заранее неизвестен.
- Harness — всё вокруг модели: правила и инструкции, инструменты и их права, хуки, песочница, тесты как обратная связь, память, наблюдаемость, gate'ы. Качество автономной работы определяется harness'ом сильнее, чем моделью. Каждая ошибка агента → строка в harness, а не «в следующий раз буду внимательнее».
- Dark factory — конвейер тикет → агент → код + тесты → ревью-агент → CI → человек только на границах (постановка и приёмка). Работает при четырёх условиях: тесты как контракт, маленькие задачи, изоляция (worktree / контейнер), gate'ы с откатом.
- Стоимость = токены × цена модели × число прогонов; в агентном цикле доминирует input, потому что контекст пересылается на каждом шаге. Рычаги: роутинг моделей по задаче, кэш префикса, короткий контекст (субагенты), детерминированный код вместо LLM, batch, локальные модели.
- Локальные модели — не замена frontier-моделям, а отдельный слой: ASR (Whisper), эмбеддинги, классификация и экстракция на объёме, приватные данные, офлайн. Решение «локально или облако» принимается по eval-набору, не на глаз.
1Agent Loop — что крутится внутри любого агента
Claude Code, Codex, Cursor Agent, мой Nexus на сервере — внутри у всех одна и та же петля. Объясняешь её — и дальше всё остальное становится «обвязкой вокруг петли».
system + task → LLM → tool_call? ──да──▶ выполнить инструмент → результат в messages → LLM → … ──нет──▶ финальный ответ / стоп
- Сборка контекста. System prompt (роль, правила, описание инструментов в JSON-схеме) + задача пользователя + то, что подтянули из памяти.
- Вызов модели. Модель возвращает либо текст, либо структурированный вызов инструмента (function calling: имя + аргументы по схеме). Может вернуть несколько вызовов сразу — parallel tool calls.
- Исполнение инструмента кодом, не моделью. Валидация аргументов, проверка прав (permission mode, whitelist), песочница, таймаут. Ошибка инструмента — это не crash, а наблюдение, которое уходит модели текстом.
- Результат в контекст. Наблюдение добавляется в messages; модель видит всю историю и решает следующий шаг.
- Условия остановки. Ответ без tool_call, лимит шагов (max_turns), бюджет токенов/денег, детектор зацикливания (три одинаковых вызова подряд), таймаут.
- Постобработка. Сжатие контекста, запись в память, отчёт, лог событий.
🔑 Модель stateless. Между вызовами она не помнит ничего — «память агента» это либо messages (растут и дорожают), либо внешняя память (файлы, БД, векторный поиск), которую harness подкладывает в контекст. Отсюда два следствия: контекст надо беречь (см. стоимость) и память надо проектировать явно.
Три архитектуры петли — чем отличаются
| Схема | Как работает | Плюс | Минус | Где у меня |
|---|
| ReAct (reason + act) | Один агент: подумал → вызвал инструмент → посмотрел → дальше | Просто, гибко | Контекст растёт с каждым шагом, дорого на длинных задачах | Интерактивная сессия Claude Code, чат с агентом в Nexus |
| Plan-and-execute | Сначала план шагов, потом исполнение по плану, при сбое — перепланирование | Предсказуемо, легко ревьюить план | План устаревает по ходу | Plan mode → спека → исполнение по тикетам (кабинет, CRM) |
| Orchestrator + workers | Главный агент режет задачу, раздаёт субагентам с чистым контекстом, собирает результаты | Параллельно, каждый worker с коротким контекстом = дешевле | Сложнее отладка, конфликты по общим файлам | Ревизия учеников фан-аутом субагентов; два кодера в разных worktree на кабинете |
Моё — та же петля на сервере 24/7: Nexus-agent-manager держит агентов по крону вне моего ноутбука. Таск = system prompt + user message + модель + whitelist инструментов (например только Bash) + MCP-серверы + расписание. Каждый прогон пишет лог событий text / tool_use / tool_result / result — по нему видно каждый виток петли. Есть ручка «прогнать разово» для теста и notifyOn: error — алерт в Telegram, если прогон упал. Пример: «Вахтёр Собесыча» каждые 30 минут: взять упавшие разборы из БД → диагноз по логам → починить по гардрейлам → отчёт мне. Обработанные фейлы — в seen-файл, чтобы петля не спамила и не чинила одно и то же.
Агент зациклился — что делаешь?
Три защиты на уровне harness: лимит шагов и бюджет на прогон; детектор повторов (одинаковый tool call с одинаковыми аргументами N раз → стоп с отчётом); «три одинаковые ошибки подряд → остановиться и вернуть диагноз человеку». Плюс дедупликация обработанного (seen-файл), чтобы крон-агент не брал ту же задачу снова.
Чем tool call отличается от «попросить модель написать команду текстом»?
Схемой и контролем: аргументы валидируются по JSON-схеме до исполнения, исполняет код (не модель), можно навесить права и хук перед вызовом. Текстовая команда — это парсинг вслепую и нулевой контроль.
Как агент «учится»?
Веса не меняются. Учится система: правило в инструкции, новый скилл-чеклист, тест, хук. У меня это буквально файлы feedback_*.md в памяти проекта — каждый после конкретной ошибки, с полем «почему» и «как применять».
2Workflow vs Agent — главное инженерное решение
Самый частый вопрос сеньору: «а где вы НЕ даёте модели свободу?». Правильный ответ — почти везде.
❌ Workflow — шаги известны заранее и зашиты кодом. LLM — один из шагов (классифицировать, извлечь, написать текст). Предсказуемо, дёшево, тестируется как обычный код. Свобода модели ≈ 0.
✅ Agent — модель сама решает, какой инструмент вызвать и когда остановиться. Нужен, когда путь заранее не известен: дебаг, исследование кодовой базы, «почини упавший прогон». Дороже и менее предсказуемо.
🔑 Свобода модели — дефицитный ресурс. Чем меньше свободы, тем дешевле и надёжнее. Выдавать её ровно там, где шаги нельзя написать кодом. Если можешь описать алгоритм — пиши алгоритм, не промпт.
Пять паттернов workflow (по классификации Anthropic «Building effective agents»)
| Паттерн | Суть | Где у меня |
|---|
| Prompt chaining | Выход шага — вход следующего, между ними проверка кодом (gate) | Собесыч: транскрипция → анализ → проверка полноты → PDF → запись в базу |
| Routing | Классифицировать вход и отправить в нужную ветку | Хук на каждое сообщение: по фразе подсказывает нужный скилл-чеклист. Роутер на regex, без LLM вообще — ноль токенов |
| Parallelization | Разрезать на независимые куски и выполнить параллельно (или несколько мнений → голосование) | Ревизия учеников: субагент на каждого, сводка в дашборд |
| Orchestrator-workers | Главный делит задачу динамически, workers исполняют | Параллельные кодеры в отдельных git worktree на кабинете |
| Evaluator-optimizer | Один генерирует, другой оценивает по критериям, цикл до порога | Completeness-чек в Собесыче: сверяет разбор с исходником, помечает пропуски до того, как увидит ученик |
Моё — как принимаю решение «код или модель»: ежедневная догрузка базы собесов из Telegram — чистый скрипт по крону без LLM: парсинг, дедуп по «компания+дата+источник», эмбеддинги локальной моделью. Сырьё складывается в буфер, а LLM-структурирование — отдельный шаг по запросу. Причина — крон-задача не должна зависеть от баланса API и от настроения модели. А вот «почини упавший разбор» — агент: там путь заранее неизвестен. Сам скилл-чеклист на 8 шагов (достать задачи → решить → верифицировать прогоном node/tsc/vitest → разбор → база → YouTube → отметить) — это workflow, где агент исполняет шаги, а не придумывает их.
Когда workflow ломается и нужен агент?
Когда вход слишком разнообразный, чтобы предусмотреть ветки: свободный текст, незнакомая кодовая база, инцидент с неизвестной причиной. Признак: в workflow копятся if-ветки под каждый новый случай.
Как тестируешь workflow с LLM внутри?
LLM-шаг мокается контрактом (фиксированный JSON по схеме), остальное тестируется как обычный код. Сам LLM-шаг — отдельный eval-набор: вход → ожидаемая структура, гоняется при смене промпта или модели.
3Harness — среда, в которой агент не может сделать плохо
Термин «harness engineering» — про то, что инженерная работа в agent-first команде уходит из кода в среду вокруг агента: инструкции, инструменты, проверки, обратную связь. Модель = процессор, harness = операционная система.
Слои harness'а — от инструкций до наблюдаемости
| Слой | Что это | Как у меня |
|---|
| Инструкции | Правила проекта, которые модель видит всегда: стиль, запреты, SSOT, порядок работы | CLAUDE.md / AGENTS.md: правило TDD (тест до кода), «интеграция обязана иметь тест, пересекающий границу», SSOT для конфигов, «назвать скилл вслух перед работой» |
| Скиллы / чек-листы | Процедурная память: пошаговые сценарии типовых задач | ~30 скиллов в .claude/commands/: разбор мока, онбординг, публикация ролика, еженедельный отчёт. Скилл = отлаженный на прошлых кейсах формат, импровизация хуже |
| Хуки | Код, который срабатывает на событиях: до/после вызова инструмента, на каждое сообщение | Хук на каждое сообщение → регекс-роутер подсказывает скилл и напоминает «отчитайся по каждому шагу». Хук покрыт тестами как обычный код |
| Инструменты / MCP | Что агент может делать, и через какой протокол | MCP к базе знаний, к Telegram (только чтение, user-сессия), к YouTube; у крон-агентов whitelist из одного Bash |
| Права и изоляция | Что агенту нельзя, и где он работает | Крон-агенты в контейнере; параллельные кодеры — каждый в своём git worktree; список разрешённых пользователей у агента-куратора; гранты доступа со сроком в кабинете |
| Обратная связь | Как агент узнаёт, что сделал не то | Тесты (vitest, tsc, node-прогон), скриншот вёрстки через браузер, readback после записи в чужую базу — «прочитай, что записал» |
| Память | Что переносится между сессиями | Директория памяти: один файл — один факт с полями «почему» и «как применять» + индекс, который грузится в каждую сессию |
| Наблюдаемость | Логи, алерты, отчёты | Лог событий каждого прогона, алерт в TG при ошибке, ежедневный отчёт по воронке стадий (загружено → распознано → разобрано → доставлено) |
🔑 Compound-принцип: каждый инцидент заканчивается не исправлением кода, а изменением harness'а — правилом, тестом, хуком. Тогда ошибка не повторится ни у меня, ни у другого агента.
Моё — два инцидента, из которых выросли правила: (1) 96 зелёных unit-тестов, а в проде у пользователя не открылся оплаченный доступ: lifecycle фреймворка передавал relation в другом формате, а мои моки этого не знали. Теперь правило в CLAUDE.md: интеграция считается покрытой, только если есть тест, который реально пересекает границу — бутит фреймворк, зовёт настоящий API, проверяет side-effect на реальной модели. (2) Сказал «запускай выкладку на YouTube», агент сделал шаг 7 из 8 и остановился: задачи не попали в базу с таймкодами. Ответ — не «будь внимательнее», а хук: на каждое сообщение регекс-роутер подсказывает полный чек-лист скилла и требует отчёт «сделано / пропущено» по каждому шагу.
Как не дать агенту удалить прод?
Не промптом «будь осторожен», а harness'ом: whitelist инструментов, permission mode с подтверждением деструктивных действий, контейнер без доступа к проду, ssh только через alias с ограниченным ключом, гардрейлы вахтёра: «рестарт только при нуле активных задач; .env и схемы не трогать; причина неясна — не чинить, только диагноз».
Чем harness отличается от промпт-инжиниринга?
Промпт — что говорим модели. Harness — что она физически может, что её проверяет и что с ней происходит после ошибки. Промпт можно проигнорировать, хук и тест — нет.
4Автономная разработка / software dark factory
«Тёмная фабрика» — цех, где можно выключить свет, потому что людей внутри нет. В софте: человек ставит задачу и принимает результат, всё между — агенты. Вопрос сеньору: какие условия нужны и где это НЕ работает.
Уровни автономии — где находимся
| Уровень | Что делает AI | Роль человека |
|---|
| L0 автодополнение | Строка кода | Пишет всё |
| L1 чат | Фрагмент по запросу | Вставляет, проверяет |
| L2 агент в IDE | Правки в нескольких файлах с подтверждением | Смотрит каждый diff |
| L3 фоновый агент на задачу | Тикет → ветка → PR с тестами | Ревью PR |
| L4 конвейер | Кодер + ревью-агент + CI, несколько задач параллельно | Постановка и приёмка |
| L5 фабрика | Задачи берутся сами: из мониторинга, бэклога, инцидентов | Цели, гардрейлы, аудит |
Моё: продуктовые фичи — L3–L4 (тикет → субагент в worktree → PR → CI с тестами и AI-ревью → мой мерж). Вахтёр Собесыча — L5 в узкой рамке: сам берёт упавшие разборы и чинит по гардрейлам.
Семь условий, без которых фабрика не работает
- Постановка с критериями приёмки. Спека до кода: что считается готовым. У меня — файл требований в репо, plan mode, «один тикет за сессию».
- Тесты как контракт. Тест пишется до кода и становится тем, что агент обязан сделать зелёным. Без теста агент оптимизирует «выглядит правильно».
- Изоляция. Каждый агент в своём worktree / контейнере / ветке. Два кодера в одной рабочей копии = конфликт HEAD и случайный
git add -A чужих файлов (ловил).
- Маленькие задачи. Контекст короткий, ошибка локальна, ревью читаемо. Большой рефакторинг режется на тикеты.
- Ревью другой ролью. Ревью-агент с adversarial-промптом «сломай это» + человек на критичном: access control, миграции, деньги. Сводке и зелёным тестам не верить — читать SQL сам (так поймал баг уникального констрейнта, который затирал второй грант).
- Наблюдаемость и откат. Лог каждого прогона, алерт при сбое, тег образа перед деплоем для отката.
- Петля обучения. Инцидент → правило / тест / хук в harness (раздел 3).
❌ Так не работает: «вот репозиторий, сделай фичу целиком», без тестов, в общей рабочей копии, с ревью по сводке агента. Итог — красивый PR, который ломает соседнее.
✅ Так работает: тикет с критериями → тест → агент в изоляции → прогон тестов зелёный → ревью-агент → человек мержит → инцидент превращается в правило.
Моё — цифры по одному проекту: бот учёта мок-собесов: 11 PR, 50 тестов, из них 10 интеграционных против реального Postgres, написан субагентами по спеке; в проде с сентября. Кабинет доступов (Go + Next): каждый PR через CI — тесты, gitleaks, AI-ревью diff'а; бэк на интеграционных тестах с реальной БД. Урок по AI-ревью: видит только diff и имеет устаревшие знания — ложные срабатывания («такой версии Go нет» — есть); валидное применяю, ложное отклоняю с обоснованием.
⚠️ Честно про границы: плохо работает на больших рефакторингах без тестов, на размытых требованиях, на визуальном качестве без цикла «скриншот → сравнить» и там, где нужны права на прод. Это не «AI не умеет», а «harness ещё не построен».
Как измеряешь пользу автономки?
Не «токены», а время до результата и переделки: цикл тикет → мерж, доля PR, вернувшихся с ревью, число инцидентов после деплоя. Плюс стоимость задачи end-to-end (раздел 5).
Кто отвечает за код агента?
Я. Каждая строка в проде — моя ответственность, поэтому gate'ы на людях там, где цена ошибки высока: доступы, деньги, миграции.
5Оптимизация стоимости разработки с агентами
Стоимость складывается из токенов, времени человека и переделок. Сеньорский ответ — назвать формулу и рычаги, а потом показать одну реальную цифру.
cost = Σ по вызовам ( input_tokens × цена_in + output_tokens × цена_out ) × число прогонов + время человека на ревью и переделки
🔑 В агентной петле доминирует input: на каждом шаге модель получает всю историю заново. 30 шагов по 50k токенов контекста = 1.5M input. Поэтому главный рычаг — не «дешевле модель», а «короче контекст».
Рычаги — от самых сильных
| Рычаг | Механика | Как у меня |
|---|
| Короткий контекст | Субагенты с чистым контекстом на подзадачи; читать фрагменты файлов, а не файлы; сжатие истории (compaction); результаты поиска — выводом, не дампом | Фан-аут субагентов вместо одной длинной сессии; сводка возвращается, а не сырые файлы |
| Роутинг моделей | Классификация, экстракция, форматирование — дешёвая модель; архитектура, дебаг, анализ — сильная. Разница в цене между классами — на порядок и больше | Тяжёлый разбор собеса — Sonnet; форматирование транскрипта — flash-lite (примерно в 30 раз дешевле); авто-ответы работодателям в кликере — самая дешёвая модель |
| Кэш префикса | Стабильная часть промпта (system, описание инструментов, большие документы) кэшируется, чтение из кэша стоит ~10% от обычного input. Условие: неизменяемое — в начало, переменное — в конец | Длинные правила и схемы — в system prompt агента, задача — последним сообщением |
| Код вместо LLM | Всё, что описывается алгоритмом — регекс, SQL, скрипт. Ноль токенов, ноль недетерминизма | Роутер скиллов на regex; дедуп и парсинг в догрузке базы без LLM; эмбеддинги локальной моделью |
| Меньше прогонов | Тест-гейт ловит ошибку на первой итерации, а не на десятой; лимит шагов и бюджет на таск; кэш результатов и идемпотентность (не пересчитывать сделанное) | Идемпотентный ingest: повтор → update без дублей, эмбеддинги не пересчитываются |
| Batch и офлайн | Массовая обработка без требований к латентности — batch API (обычно −50%) или ночью на дешёвой модели | Структурирование бэклога — отдельным пакетом, не в реальном времени |
| Локальные модели | ASR, эмбеддинги, простая классификация — на своём железе, цена за токен ноль | Whisper локально на Mac и на сервере; эмбеддинги MiniLM на CPU |
| Подписка vs API | Интерактивная работа — фиксированная подписка (предсказуемо); прод-пайплайны — API с бюджетом и алертом на баланс | Массовые прогоны — субагентами по подписке; API — только для сервисов ученикам, со сторожем баланса |
Моё — одна честная цифра: разовая пересборка базы собесов через API на Sonnet съела $16 за 1.9M токенов. Вывод превратился в политику: массовая обработка либо субагентами по подписке, либо на flash-lite; крон-задачи не зависят от платного API (буферизуют сырьё, LLM-шаг отдельно); на сервере сторож баланса по крону шлёт алерт при остатке ниже порога, иначе пайплайн для учеников молча падает на стадии анализа, когда транскрипция уже прошла.
Что такое cache hit rate и как его поднять?
Доля input-токенов, прочитанных из кэша. Поднимается стабильным префиксом: system и tools не меняются между вызовами, динамика — в конце; не перемешивать порядок инструментов; не вставлять timestamp в начало промпта.
Когда Opus, когда Haiku?
Haiku/flash — там, где есть чёткая схема ответа и eval показал, что справляется: классификация, извлечение полей, форматирование. Сильная модель — где нужно рассуждение: архитектурное решение, дебаг по логам, ревью. Правило: начинать с сильной, зафиксировать eval, потом пробовать спуститься.
Как посчитать стоимость фичи?
Токены по логам прогонов × цены + часы человека на постановку, ревью и переделки. Сравнивать с ручной реализацией по времени до мержа. Токены обычно дешевле часа разработчика, дорого — переделки из-за плохой постановки.
6Локальные модели — где они выигрывают, а где нет
Локальная модель — это модель на своём железе: Mac с Apple Silicon (MLX), сервер на CPU/GPU. Рантаймы: ollama, llama.cpp, LM Studio, vLLM, MLX. Классы: ASR (Whisper), эмбеддинги (MiniLM, bge, e5), малые LLM 7–32B в квантованном виде (Qwen, Llama, Gemma).
| Задача | Локально | Облако | Почему |
|---|
| Транскрипция аудио (ASR) | ✅ | — | Whisper large-v3-turbo даёт качество уровня API, аудио не покидает машину, цена ноль |
| Эмбеддинги для поиска | ✅ | — | Малая модель на CPU, десятки тысяч записей, повторяемо и бесплатно |
| Классификация / извлечение по схеме на объёме | ✅ после eval | фолбэк | 7–14B справляется, если есть жёсткая схема и grammar-ограничение вывода |
| Приватные данные, офлайн | ✅ | ✗ | Записи собесов, переписки, ПДн — наружу только текст, и только если разрешено |
| Рассуждение, архитектура, дебаг | ✗ | ✅ | Малые модели хуже держат длинный контекст и многошаговую логику |
| Агентная петля с инструментами | ✗ (пока) | ✅ | Малые модели плохо следуют tool-протоколу: ломают JSON, зацикливаются |
Как переводить задачу на локальную модель — порядок
- Начать с frontier-модели и зафиксировать eval-набор: 30–100 входов с ожидаемым результатом. Без него «локальная тоже норм» — самообман.
- Прогнать локальную на том же eval'е и сравнить: точность, доля битого JSON, латентность.
- Подобрать размер и квантование: Q4 режет память примерно вчетверо при небольшой потере качества; ориентир по памяти — 7B Q4 ≈ 4–5 ГБ, 14B ≈ 9 ГБ, 32B ≈ 20 ГБ.
- Ограничить вывод: JSON-схема / grammar в рантайме, а не «пожалуйста, верни JSON».
- Батчить и кэшировать: эмбеддинги считать один раз, хранить в БД; длинные входы чанковать.
- Следить за ресурсами: память и диск на общем сервере — соседний сервис может уронить модель по OOM.
- Гибрид: локально — дешёвый массовый этап, облако — только там, где локальная не дотянула по eval'у.
Моё — два локальных слоя в проде: (1) ASR: mlx-whisper large-v3-turbo на Mac (10 минут записи примерно за 1.5 минуты), faster-whisper на сервере для бота. Двухэтапный пайплайн: локальный сырой транскрипт → облачное форматирование со спикерами; наружу уходит текст, не аудио. (2) Эмбеддинги: paraphrase-multilingual-MiniLM (384 измерения) на CPU внутри контейнера + pgvector: 14.7k вопросов из 2 000 собесов и 48k сообщений чата — семантический поиск без единого платного токена. Индекс считается инкрементально при догрузке.
⚠️ Грабли, которые прошёл: Whisper галлюцинирует на тишине («Продолжение следует…», зацикленное «Спасибо») — отрезать по вычитке; облачный форматтер обрезал длинные транскрипты и ломал таймкоды на склейке частей (плюс час) — проверка монотонности меток одной строкой; запись 60+ минут — чанковать по 10 минут с flush и маркером «done_NN», иначе полтора часа работы умирают на 91% из-за забитого диска; на сервере CRM ела 1.4 ГБ памяти и роняла whisper по OOM — остановил CRM.
Почему не перевести всё на локальные и не платить вообще?
Потому что качество рассуждения и tool-use у 7–32B ниже, а цена ошибки в разборе для ученика выше цены токенов. Локальные берут массовые и приватные этапы, frontier — узкие места, где нужен интеллект. Решение — по eval'у, не по идеологии.
Как оцениваешь качество Whisper?
WER на контрольных записях с ручной разметкой + практические проверки: длина raw против форматированного, монотонность таймкодов, отсутствие повторов в хвосте.
Что такое квантование?
Хранение весов в меньшей разрядности (int8, int4 вместо fp16): в разы меньше памяти и быстрее, небольшая потеря точности. Q4 — рабочий компромисс для 7–14B на ноутбуке.
7Реальные вопросы из базы собесов
Семантический поиск по базе 2 059 собесов. Тему спрашивают всё чаще, но чаще всего одной фразой — значит, ждут структуру от кандидата.
| Компания | Дата | Как спросили | Куда вести ответ |
|---|
| Вектор | 02.2026 | «ИИ-агенты, оркестрация» | Раздел 1 + 2: петля, workflow vs agent, orchestrator-workers, мой Nexus |
| SSP Soft | 04.2026 | «Как использовал ИИ, агенты, copilot» | Уровни автономии (раздел 4) + три примера из историй |
| СберСити | 09.2025 | «Менторинг, код-ревью, AI-agents» | AI-ревью в CI + правило «читать критичное сам» |
| Ростелеком | 03.2026 | «AI в работе» | Ежедневный workflow + harness (раздел 3) |
| ПИК | 11–12.2025 | «Отношение к ИИ» / «Мнение об ИИ» | Позиция: ответственность за каждую строку, где помогает и где нет |
| Холдинг финанс | 11.2025, 01.2026 | «Пользуешься ИИ?» | Коротко «да, ежедневно» → сразу пример с цифрой |
| IT-Train | 04.2026 | «Прорывы AI и сфера» | Сдвиг от чата к агентам, от кода к harness'у; стоимость и локальные модели |
🔑 Шаблон ответа на любой из них: одна фраза-определение → где применил (проект, цифра) → что пошло не так и какое правило появилось. Третья часть отличает практика от читателя новостей.
8Каверзные follow-up
Агент сделал PR, тесты зелёные. Мержишь?
Зависит от зоны. Обычная фича — после ревью-агента и беглого чтения diff'а. Доступы, деньги, миграции — читаю SQL и логику сам, дописываю недостающий критичный тест. Зелёные тесты доказывают только то, что проверяют тесты.
Что такое prompt injection в агентах и как защищаешься?
Данные, которые агент читает (письмо, страница, сообщение из чата), содержат инструкции, и модель их выполняет. Защита harness'ом: инструменты только на чтение там, где вход недоверенный; деструктивные действия — с подтверждением; внешние данные помечаются как данные, а не команды; список разрешённых пользователей у агента с доступом к чатам.
Чем MCP отличается от обычного function calling?
Function calling — модель вызывает функции, которые описал разработчик приложения. MCP — открытый протокол, по которому внешний сервер публикует свои инструменты и ресурсы, и любой агент подключает их стандартно: один сервер к базе знаний используют и Claude Code, и крон-агент, и чат.
Зачем субагенты, если можно один длинный контекст?
Три причины: стоимость (каждый шаг пересылает историю), качество (модель хуже работает в забитом контексте — теряет инструкции), параллельность. Субагент возвращает вывод, не сырьё.
Как понимаешь, что модель врёт в разборе?
Проверкой кодом, а не второй моделью «на глаз»: completeness-чек сверяет разбор с исходным транскриптом (все ли задачи разобраны), structured output по схеме, теги уверенности в вердикте. Плюс аналитика по стадиям — где чаще всего падает.
Локальная модель дала 92% на eval'е против 97% у облачной. Переводишь?
Зависит от цены ошибки и объёма. Для эмбеддингов или предварительной классификации — да, с облачным фолбэком на низкой уверенности. Для финального разбора ученику — нет: пять процентов ошибок это каждый двадцатый ученик с неверным вердиктом.
Что делаешь, когда агент «уверенно» сделал не то, что просили?
Не спорю с моделью, ищу дыру в harness'е: не было теста на этот сценарий, чек-лист не читался целиком, фраза не сматчилась в роутере. Исправляю среду, и ошибка исчезает у всех будущих прогонов.
9Истории на 60 секунд — «как я управляюсь с этим»
Под вопрос «расскажи, как вы это применяете». Каждая по схеме: ситуация → что построил → что пошло не так → правило.
① Self-healing вахтёр (agent loop + harness + L5)
Сервис разбора собесов падал ночью, ученики ждали до утра. Поднял постоянного агента по крону на сервере: каждые 30 минут берёт упавшие задачи из БД, диагностирует по логам и коду, чинит сам, но строго по гардрейлам — бэкап, тест на регрессию, полный прогон зелёный, рестарт только при нуле активных задач, конфиги и чужие сервисы не трогать. Если причина неясна — не чинит, присылает диагноз. Обработанное дедуплицирует, чтобы не спамить.
Правило: на ошибки прода реагирует агент, а не алерт человеку; свобода агента ограничена списком того, что ему можно.
② Инцидент → хук (harness compounding)
Дал команду «запускай выкладку на YouTube». Агент опубликовал ролик и остановился, хотя чек-лист требовал ещё занести задачи в базу с таймкодами. Кнопка в канале вела на пустую подборку. Вместо «в следующий раз внимательнее» добавил хук на каждое сообщение: регекс-роутер узнаёт задачу по фразе, подкладывает полный чек-лист и требует отчёт по каждому шагу. Хук покрыт тестами.
Правило: каждая ошибка агента становится строкой в среде, а не в памяти человека.
③ $16 за одну ночь → политика стоимости
Пересборка базы через API на сильной модели съела $16 за 1.9M токенов. Разобрал: 90% работы не требовало сильной модели. Итог — правила: массовое либо по подписке субагентами, либо на дешёвой модели; крон-задачи не зависят от платного API (буферизуют сырьё, LLM отдельно); сторож баланса по крону с алертом, потому что при пустом балансе пайплайн для учеников падал молча на стадии анализа.
Правило: выбирать модель по задаче и eval'у, а не по привычке; наблюдать за бюджетом так же, как за ошибками.
④ Локальный ASR + эмбеддинги (локальные модели)
Записи собесов — приватные и длинные. Транскрипция — локальный Whisper на Mac и на сервере, наружу уходит только текст на форматирование. Поиск по 14.7k вопросов и 48k сообщений — локальные эмбеддинги на CPU + pgvector, ноль платных токенов. Грабли: галлюцинации на тишине, обрезка длинных транскриптов облачным шагом, сломанные таймкоды на склейке, OOM от соседнего сервиса. Каждая — в проверку: длина raw против форматированного, монотонность таймкодов, чанкование с маркером докуда дошли.
Правило: локальные модели на массовые и приватные этапы, облако — где eval показал, что локальная не дотягивает.
⑤ Автономная разработка продукта (dark factory L3–L4)
Бот учёта мок-собесов: спека → тесты до кода → субагенты в отдельных worktree → PR → CI с тестами, gitleaks и AI-ревью → мой мерж. 11 PR, 50 тестов, 10 против реального Postgres, в проде. На кабинете доступов ревью-агент по сводке пропустил баг уникального констрейнта, который затирал второй грант — поймал, читая SQL сам.
Правило: критичное (доступы, деньги, миграции) читает человек; всё остальное — конвейер.
10Аудит смежных тем
| Тема | Статус | Где |
|---|
| Agent loop, tool calling, стоп-условия, память | покрыто | раздел 1 |
| Workflow-паттерны (chaining, routing, parallel, orchestrator, evaluator) | покрыто | раздел 2 |
| Harness: инструкции, скиллы, хуки, права, обратная связь, память, наблюдаемость | покрыто | раздел 3 |
| Уровни автономии, условия, границы | покрыто | раздел 4 |
| Экономика токенов, кэш, роутинг | покрыто | раздел 5 |
| Локальные ASR / эмбеддинги / малые LLM, квантование | покрыто | раздел 6 |
| RAG: чанкование, эмбеддинги, гибридный поиск, reranking | граничит | отдельная тема: у меня pgvector + MiniLM, семантический и по тегам |
| Evals: как строить набор, LLM-as-judge, регрессия при смене промпта | граничит | отдельная тема: completeness-чек Собесыча как стартовый пример |
| MCP: устройство протокола, ресурсы / инструменты / промпты, безопасность | граничит | отдельная тема: у меня MCP к Buildin, Telegram, YouTube |
| Structured outputs, JSON-схемы, grammar-ограничение | граничит | упомянуто в 2 и 6 |
| Безопасность агентов: prompt injection, утечки, sandbox | граничит | раздел 8, один вопрос |