Для начинающих

Вы работаете в Claude Code и вдруг видите «Claude usage limit reached. Your limit will reset at 3pm», и всё останавливается. Это не ошибка и не баг: так устроены лимиты использования подписки Pro/Max. В статье разобраны двухуровневая структура (скользящее 5-часовое окно + недельное окно, а на Max ещё отдельный недельный лимит для Opus), факт общего лимита с приложениями Claude, четыре главных фактора расхода, пять способов продолжить работу при достижении лимита, как посмотреть остаток через /usage и Settings → Usage, и разница между лимитами подписки и API (429, retry-after, Tier).

Вы видите «Prompt is too long» (а в API — «233153 tokens > 200000 maximum») в Claude Code, и работа останавливается. Это не usage limit и не обрезка вывода по max_tokens: ваш ввод (история диалога + файлы + определения инструментов) просто превысил окно контекста модели. В статье разобрано, что заполняет окно, чем различаются размеры 200K и 1M, как быстро освободить место через /compact, /clear и subagent, и как отличить эту ошибку от трёх похожих.

Вы настроили сервер MCP в Claude Code, но /mcp показывает failed, needs authentication или pending — и инструменты не работают. Причины делятся на три семейства: сбой запуска локального подпроцесса, удалённая аутентификация и ошибки конфигурации, и статус подсказывает, какое из них перед вами. В статье разобраны чтение статуса, устранение причин по отдельности, главная ловушка npx на Windows и рабочий процесс диагностики.

В длинных сессиях Claude Code иногда на экран утекает строка с «court» (или «call») и сырыми тегами <invoke> / <parameter>, при этом команда не выполняется. Это не ошибка вашего окружения или команды, а сбой на стороне модели (семейство Opus 4.8 / 4.7), которая генерирует управляющий токен вызова инструмента в битой форме; харнесс отклоняет его по принципу fail-closed, поэтому риска запуска неверной команды нет. По-настоящему неприятна цепная реакция: битый блок остаётся в истории, модель его имитирует, и повторы в той же сессии бьют рикошетом. Главное правило — «промахнулся дважды, уходи в свежую сессию (/clear)». В статье разобраны механизм, две первопричины, типичные заблуждения, исправления для пользователей и разработчиков, отличие от похожих ошибок и официальный статус.

Однажды аккаунт ChatGPT или Claude внезапно перестаёт работать: в 2026 году число сообщений о блокировках (банах) и предупреждениях растёт, и страшнее всего то, что заблокировать могут за случайное нарушение условий даже без злого умысла. В статье собрано то, что нужно знать, чтобы не потерять аккаунт в OpenAI (ChatGPT, Codex) и Anthropic (Claude, Claude Code), на основе опубликованных правил использования и сообщений (это не руководство по обходу обнаружения, а руководство по соблюдению правил). Пять общих триггеров для обеих компаний: запрещённый контент / jailbreak (незаконная или вредоносная генерация, попытки обойти защитные фильтры промптами; серьёзные нарушения могут означать мгновенную постоянную блокировку), несанкционированная автоматизация / скрейпинг (боты, скрипты, обманный массовый доступ вроде спама/фишинга), передача или перепродажа аккаунтов/ключей API, подозрительные паттерны доступа (частая смена IP/страны, активный VPN, переключение устройств — воспринимается как аномальные входы) и несоответствие оплаты/мошенничество. Главная ловушка 2026 года: использование токенов OAuth личного тарифа Claude (Free/Pro/Max) в любом продукте, кроме официального приложения, включая обвязки вроде Agent SDK, — нарушение Consumer ToS, вызвавшее крупную волну блокировок; правильный подход — запускать приложения/агентов через API (оплата по факту), а личные тарифы воспринимать как общение в официальном приложении. Специфика OpenAI: обход защиты/ограничений доступа, автоматизация/скрейпинг, неправомерное повторное использование ключей API, незаконное использование. Специфика Anthropic: неправильное использование токенов OAuth личного тарифа, неофициальный сторонний доступ, положения о запрете дистилляции/конкурирующих моделей, jailbreak. Чек-лист профилактики из 7 пунктов (прочитать правила, подобрать тариф под задачу, не помещать личные токены в сторонние инструменты, без jailbreak/запрещённого контента, не передавать и не перепродавать, оплата по региону и стабильный доступ, реагировать на предупреждения сразу). Предупреждения — шанс исправиться, и большинство могут продолжать; незначительные или случайные нарушения можно обжаловать, но серьёзные нарушения постоянны и восстановление затруднено. Правильный тариф, по правильному назначению, честно. Всегда сверяйтесь с актуальными официальными условиями каждой компании.

Переобучать гигантский ИИ с нуля слишком дорого, но хочется настроить его под себя; LoRA (Low-Rank Adaptation) исполняет это желание, замораживая исходную модель и обучая лишь крошечную навесную деталь (адаптер), сокращая обучаемые параметры примерно на 90%. LoRA делает файнтюнинг заметно дешевле и быстрее и чрезвычайно популярна в генерации изображений вроде Stable Diffusion как маленький файл, добавляющий персонажа или стиль. Статья объясняет её через аналогию заплатки. LoRA — флагман параметрически эффективного файнтюнинга (PEFT): огромные исходные веса остаются замороженными, в каждый слой вставляется небольшая навесная матрица, и обучается только она (W = W0 + BA, где W0 заморожена, а BA — небольшая добавленная часть). В основе — открытие, что адаптация ИИ не требует больших изменений (достаточно низкого ранга). Преимущества: примерно на 90% меньше обучаемых параметров (по сообщениям, в 10,000x раз меньше на масштабе GPT-3), меньше памяти GPU (примерно в 3x раза), быстрее и дешевле обучение, без задержки при инференсе после слияния адаптера и ниже риск переобучения. Главная сила — сменные адаптеры: держите одну общую базу и мгновенно меняйте маленькие файлы LoRA (в несколько МБ) под каждый случай (поддержка, тон компании, конкретный персонаж). Многие впервые встречают LoRA в генерации изображений, где широко распространяются LoRA для Stable Diffusion, обучённые персонажу, стилю или объекту (добавить стиль, обучить персонажу, лёгкие и удобные для обмена). QLoRA сочетается с квантизацией, обучая LoRA поверх базы на 4-bit ради ~4x меньшей памяти, чем стандартная LoRA, позволяя дообучать огромные модели на потребительском GPU (иногда CPU) с минимальной потерей точности. По сравнению с полным файнтюнингом (обучение всех весов) LoRA отличается обучаемыми весами, стоимостью, результатом и областью применения; для большинства задач LoRA достаточно. Базу оставь как есть, приправляй понемногу. Цифры взяты из публичных материалов, ориентировочно.

Огромная модель 70B, работающая на одном домашнем игровом ПК вместо стойки дата-центровых GPU, возможна благодаря квантизации, которая снижает числовую точность весов модели, чтобы резко уменьшить размер и память. Если дистилляция переносит знания в отдельную меньшую модель, то квантизация делает ту же модель легче. Статья объясняет это через аналогию со сжатием фотографии. Квантизация заменяет веса, хранящиеся как дробные FP16/FP32, целыми INT8 (8-бит) или INT4 (4-бит), сокращая байты на вес (FP32=4, INT8=1, INT4=0,5); как сжатие RAW-фото в JPEG, жертвуем малой точностью ради большого выигрыша, и удивляет, как мало вы теряете. По памяти 4-bit использует около четверти от FP16: модель 70B падает с ~140GB до ~35GB, а 8B при 4-bit — ~4.5-5GB, умещаясь в средний GPU с 8GB VRAM для локального запуска (демократизация LLM). По точности INT8 почти без потерь, а INT4 деградирует менее чем на 4% на обычных Q&A и задачах на здравый смысл, но потеря заметнее для математики, генерации кода и сложных рассуждений (проявляется как небольшой рост перплексии), поэтому выбирайте разрядность под задачу. Основные методы: GPTQ (первопроходец точного 4-bit), AWQ (защищает ~1% самых важных весов, часто на 1-2% точнее и быстрее), GGUF (формат llama.cpp/Ollama, Q2_K-Q8_0, гибрид CPU+GPU, для локального) и QLoRA (4-bit база плюс LoRA для файнтюнинга на потребительском GPU). Это отличается от дистилляции (перенос в отдельную малую модель) и файнтюнинга (добавление знаний задачи), и эти три обычно комбинируют (квантизовать дистиллированную модель; файнтюнить квантизованную базу). Чтобы начать, запустите модель GGUF с Ollama одной командой, выберите Q4/Q8 по VRAM и избегайте INT4 для кода или точной математики. Большинство крупных моделей поставляются уже квантизованными, так что вы просто скачиваете и используете их. Сохраняем ум, убираем только вес. Цифры взяты из публичных материалов, ориентировочны.

Огромный, высокопроизводительный ИИ умён, но тяжёл и дорог; дистилляция моделей (knowledge distillation) решает это, перенося знания крупной модели-учителя в небольшую модель-ученика и сохраняя 95%+ производительности учителя при десятикратно меньшем размере и скорости. Статья объясняет это через аналогию «учитель — ученик». Ключ — soft labels: обычное обучение учит только «ответ — кошка» (hard label), а дистилляция передаёт всё распределение вероятностей учителя, например «90% кошка, 8% собака, 2% лиса», чья степень сомнения несёт богатую информацию; параметр temperature смягчает вероятности, открывая тонкие отношения (реальный пример: GPT-4o mini дистиллирована из GPT-4o). Преимущества: быстро и дёшево, ~в 10 раз компактнее при сохранении 95%+ производительности, работа на edge, сила в специализации. Два подхода: white-box (полный доступ к весам и внутренним представлениям, более глубокий перенос; для своих или OSS-моделей) и black-box (видны только выходы/ответы API; чужой API как учитель может нарушать условия). Отличается от квантизации (сжатие точности весов той же модели) и fine-tuning (дообучение существующей модели под задачу) — дистилляция переносит знания в отдельную малую модель, и все три комбинируемы. Правовая сторона стала большой темой 2026 года: технология легитимна, но OpenAI, Anthropic, Mistral и xAI имеют анти-конкурентные положения о дистилляции, запрещающие использовать выходы для создания конкурирующих моделей, поэтому дистилляция конкурента из ограниченного API может нарушать условия. Спор OpenAI против DeepSeek (OpenAI заявила, что связанные с DeepSeek аккаунты обходили ограничения, чтобы получить выходы для дистилляции, тогда как условия DeepSeek, по сообщениям, разрешают дистиллировать её выходы) показывает, что оценка зависит от того, чьи условия API применяются, а Claude Fable 5/Mythos 5, по сообщениям, ограничивают ответы по работе, помеченной как дистилляция. Советы: используйте свои или лицензированные OSS-модели как учителя, проверяйте анти-дистилляционные положения перед использованием коммерческого API и оценивайте, не является ли использование «разработкой конкурирующей модели». Ум — от большой модели, эксплуатация — от малой, но выбор учителя меняет результат технически и юридически. Цифры приведены по открытым материалам, ориентировочно.

В статье «Как построить мультиагентную систему» мы советовали инструментировать каждую передачу управления до добавления агентов; технология, которая обеспечивает это в продакшене, — наблюдаемость ИИ. Она делает видимым то, что LLM и агенты на самом деле делают в продакшене (какая модель с каким промптом, какие инструменты и поиски, что возвращено, сколько времени и денег), чтобы можно было проследить путь до причины. Решающее отличие от обычного мониторинга: ИИ может вернуть 200 OK за 50ms и при этом уверенно галлюцинировать, поэтому большинство сбоев ИИ — это сбои качества (галлюцинации, слабое извлечение, небезопасные ответы, незавершённые задачи, плохое использование инструментов, регрессии после изменения промпта), а не инфраструктуры. Наблюдаемость опирается на три столпа: trace (один запрос как дерево span с вызовами LLM, инструментами, извлечением, цепочками рассуждений; главный элемент наблюдения ИИ), метрики (задержка, стоимость, токены, частота ошибок, пропускная способность) и логи (детали по событиям). Отраслевой стандарт — соглашения GenAI в OpenTelemetry — фиксирует промпты, ответы, использование токенов и вызовы инструментов/агентов в схеме без привязки к вендору, которую можно направить в Datadog/Grafana. Чаще всего путают наблюдаемость и оценку (evals): наблюдаемость показывает, что произошло (легко измерить, но нельзя сказать, верен ли ответ), а evals измеряют, хорош ли ответ (точность, groundedness, безопасность), и требуют явной оценки. Поскольку стоимость и задержку измерить легко, а качество ответа — нет, инструменты 2026 года совмещают показ trace с оценкой выходов и оповещениями о деградации. Метрики делятся на операционные (стоимость, задержка, токены, частота ошибок) и качественные (галлюцинация, groundedness/достоверность, важнейшая для RAG, безопасность, завершение задачи); обнаружение галлюцинаций — через LLM-as-a-judge, семантическое сходство и оценки groundedness. Основные инструменты: LangSmith (LangChain), Langfuse (open-source self-host), Arize Phoenix (отладка RAG), MLflow (жизненный цикл), AgentOps (агенты) и OpenTelemetry (стандарт). Начните со сбора trace (совместимо с OpenTelemetry), визуализируйте операционные метрики, затем подключите evals до выпуска. Для мультиагентных систем наблюдение необходимо, так как сбои прячутся в многошаговых цепочках, видимых только в trace всей сессии. Наблюдать плюс оценивать — вот что делает ИИ продакшен-уровнем. Иллюстрации и характеристики приведены по публичным материалам, как ориентир.

После того как вы усвоили концепцию в статье «Что такое мультиагентная система?», это практическое продолжение. На де-факто стандарте 2026 года — паттерне supervisor — оно проводит начинающих через построение за 5 шагов. Главный принцип: сначала стройте на одном агенте и добавляйте новых по минимуму, только упёршись в предел (около 80% сценариев обходятся одним; использование мульти для простой линейной работы раздувает стоимость в 3-10x и, по данным исследования Google, снижает точность на -39-70% на последовательных задачах). Три признака перехода на мульти: разделение специализаций, параллелизм, разделение решений. К паттерну supervisor (supervisor получает общую задачу, разбивает её, делегирует специализированным worker и агрегирует результаты) сошлись subagents в Claude Code, LangGraph Supervisor и handoffs в OpenAI Agents SDK — у него самая широкая поддержка фреймворков, известный режим отказа (избыточное делегирование, ограниченное лимитом итераций) и его легко аудировать. 5 шагов: 1) чётко разложить задачу заранее; 2) определить worker с одной ролью + инструменты + формат вывода (максимум 3-5); 3) спроектировать supervisor, явно перечислив имена вызываемых worker (жёсткий лимит) и тратя на это больше всего времени; 4) определить handoff и обмен контекстом, передавая только нужное (стандарт — A2A); 5) инструментировать каждый handoff до добавления агентов, ограничить итерации/токены/стоимость, настроить evals и ограждения. Псевдокод, не зависящий от фреймворка, показывает определения worker, жёстко ограниченный supervisor и цикл с лимитом итераций. Типичные ловушки и решения: избыточное делегирование (лимит + ограничение вызываемых worker), раздувание токенов (передача только нужного + кэш), нестабильность (держать 3-5 + фиксированный вывод), падение точности на последовательных задачах (вернуться к одному), неясный источник сбоя (наблюдаемость). Общий урок: промпты, проектирование инструментов и набор evals решают успех больше, чем фреймворк. Стройте мало, измеряйте, добавляйте только когда окупается. Цифры приведены по открытым материалам и исследованиям, зависят от условий.

«Разбить сложную задачу, с которой не справляется один ИИ-агент, между несколькими агентами» — вот идея мультиагентных систем. Этот гид для новичков разбирает механику, основные паттерны и крупнейшие фреймворки, и, что важнее всего, дает реальное правило выбора: когда нужны несколько агентов, а когда хватит одного, без хайпа. Мультиагентная система заставляет несколько ИИ с разными ролями работать вместе над одной крупной задачей; в отличие от одиночного агента, делающего всё (его хватает на ~80% сценариев, он дешев и легко отлаживается), она распределяет работу по специализациям для параллельной работы и взаимной проверки ценой более высоких затрат на координацию и расход токенов. Четыре доминирующих паттерна оркестрации: orchestrator-worker (руководитель разбивает работу, раздает исполнителям параллельно и объединяет; самый распространенный, с журналом действий), последовательная передача (передача контекста следующему агенту), групповой диалог (агенты спорят в одной ветке, селектор решает, кто говорит; хорошо для взаимной проверки) и граф-конечный автомат (агенты как узлы, переходы как ребра, явное состояние; силен для ветвления и контрольных точек). К 2026 году фреймворки сошлись к LangGraph (наибольшее присутствие в продакшене), CrewAI (низкий порог входа, прототипирование), AutoGen/AG2 (дебаты и проверка, исследования) и OpenAI Swarm (легкие передачи). Но это не панацея: сложные многодоменные задачи дают до +23% на бенчмарках рассуждений, однако на линейных последовательных задачах исследование Google показало −39-70% против одиночного агента, те же ресурсы у одного агента часто не уступают или выигрывают, а 7 из 10 внедрений, по сообщениям, увеличили затраты без отдачи при ≈15x расходе токенов (средний ROI 2.5-3.5x, верхний квартиль 4-6x при точном попадании). Рекомендуемый путь: сначала собрать на одном, определить конкретный потолок (размытые роли, распараллеливаемая работа), затем добавить минимальную команду из 2-3 агентов по схеме с руководителем с лимитом затрат и логированием и измерить, оправдывает ли прирост точности увеличение. A2A (протокол связи) и MCP (подключение инструментов) — базовые технологии, поддерживающие мультиагентность. Один — на 80%, мультиагентность — только на трудных участках. Цифры приводятся по опросам и исследованиям, зависят от условий и носят ориентировочный характер.

Теперь, когда ИИ-агенты стали обыденностью, следующий вызов — как заставить агентов работать сообща. Если MCP соединяет агента с его инструментами, то A2A (Agent2Agent) соединяет агента с другим агентом — это открытый стандарт, позволяющий ИИ, построенным на разных платформах и фреймворках, находить друг друга, общаться и сотрудничать через общую договорённость. Google выпустил его в апреле 2025 года, в июне передал Linux Foundation, и в 2026 году он достиг версии v1.0. Это руководство для новичков объясняет, что такое A2A (аналогия с этикетом делового партнёрства), зачем он нужен (специализированные агенты передают работу по эстафете — агент планирования, агент бронирования отелей, агент оплаты), чем отличается от MCP (MCP — это вертикаль, агент ↔ инструменты; A2A — это горизонталь, агент ↔ агент; совмещение обоих — стандартная двухслойная схема), как это работает (Agent Card — JSON-«визитка» по адресу /.well-known/agent-card.json — используется для обнаружения возможностей, затем Task несёт запрос через состояния working, input-required, completed, а Artifact возвращает результат, и всё это поверх HTTP, Server-Sent Events и JSON-RPC 2.0, причём агенты держат своё внутреннее устройство скрытым), а также каково текущее состояние и реализация (по состоянию на апрель 2026 года: 150+ организаций в продакшене, 22 000+ звёзд на GitHub, SDK на пяти языках — Python, JavaScript, Java, Go, .NET — при участии Microsoft, Salesforce, SAP и ServiceNow). Запомнить просто: подключение к инструментам = MCP, подключение к равным = A2A.