AI-разработка: создаём приложения и код

Сетевые ошибки Claude Code («Can't reach the API server», «Connection refused», SSL certificate verification failed, fetch failed) означают, что запрос не дошёл до сервера Anthropic. Это не 401/403, не 529/500 и не 429. До v2.1.227 те же ошибки выглядели как «Unable to connect to API (ECONNREFUSED)». Разбираем значение каждого текущего сообщения, завершение первоначальной настройки с «Unable to connect to Anthropic services», предупреждение «Streaming response ended before any complete data was received», когда прокси меняет ответ, настройку HTTPS_PROXY, корпоративные CA через NODE_EXTRA_CA_CERTS (без отключения проверки), домены для файрвола и пошаговую диагностику с curl и /doctor.

Ошибки 529 Overloaded и 500 в Claude Code означают, что API Anthropic временно перегружен или столкнулся с внутренней ошибкой — это на стороне сервера, не ошибка вашего запроса и не исчерпание лимита. Claude Code автоматически повторяет запрос до 10 раз с экспоненциальной задержкой. Разбираем, чем они отличаются от 429 и usage limit, и как действовать пользователю и разработчику.

Сообщение «You've hit your session limit · resets 3:45pm» в Claude Code — не ошибка и не баг, а то, как работают лимиты использования подписки. В официальном справочнике четыре варианта: session (скользящее 5-часовое окно), weekly (недельное окно), а также Opus и Sonnet (лимиты одного семейства моделей); поскольку лимиты сессии и недели общие для всех моделей, смена модели доступ не вернёт. В статье разобрано, что означает каждое сообщение и как менялся текст со времён старого «Claude usage limit reached», что больше всего расходует лимит и что делать в момент его достижения: при лимите Opus/Sonnet сменить модель через /model, дождаться сброса (с v2.1.234 автоматически), использовать кредиты использования через /usage-credits или перейти на API с оплатой по факту. Также — как посмотреть остаток через /usage и какие похожие сообщения не относятся к вашему лимиту.

Prompt is too long в Claude Code означает, что весь отправляемый ввод не помещается в контекстное окно. Статья различает длинную историю, слишком большой исходный ввод и ошибку самого сжатия; объясняет /context, /compact, /clear, откат разговора и отдельные окна субагентов. Также разобраны загрузка подробных определений MCP по запросу, условия 200K и 1M для модели, подключения и плана, разница между ёмкостью и оплатой, похожие ошибки и прямые обращения к API с подсчётом токенов.

Если MCP-сервер не подключается к Claude Code, сопоставьте статус, способ подключения и подробности Issue. failed может означать сбой запуска stdio, ошибку связи HTTP или отказ для фиксированного заголовка аутентификации. Статья объясняет Connection closed, переменные окружения и неопределённые ссылки, проектную конфигурацию и одобрение, запуск npx в Windows, журналы отладки и проверку операций после переподключения. Отдельно разобрано, почему ноль инструментов не обязательно означает ошибку, а отдельный запуск не гарантирует успешного подключения MCP.

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

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

Огромная модель 70B, работающая на одном домашнем ПК вместо стойки дата-центровых GPU (то, что не влезает в потребительскую GPU, берут на себя CPU и оперативная память), возможна благодаря квантизации, которая снижает числовую точность весов модели, чтобы резко уменьшить размер и память. Если дистилляция переносит знания в отдельную меньшую модель, то квантизация делает ту же модель легче. Статья объясняет это через аналогию со сжатием фотографии. Квантизация заменяет веса, хранящиеся как дробные 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% самых важных весов; превосходит ли он GPTQ, зависит от оценки), GGUF (формат llama.cpp/Ollama, Q2_K-Q8_0, гибрид CPU+GPU, для локального) и QLoRA (4-bit база плюс LoRA для файнтюнинга на потребительском GPU). Это отличается от дистилляции (перенос в отдельную малую модель) и файнтюнинга (добавление знаний задачи), и эти три обычно комбинируют (квантизовать дистиллированную модель; файнтюнить квантизованную базу). Чтобы начать, запустите модель GGUF с Ollama одной командой, выберите Q4/Q8 по VRAM и избегайте INT4 для кода или точной математики. Большинство крупных моделей поставляются уже квантизованными, так что вы просто скачиваете и используете их. Сохраняем ум, убираем только вес. Цифры взяты из публичных материалов, ориентировочны.

Огромный, высокопроизводительный ИИ умён, но тяжёл и дорог; дистилляция моделей (knowledge distillation) решает это, перенося знания крупной модели-учителя в небольшую модель-ученика и сохраняя близкую к учителю производительность при гораздо меньшем размере и большей скорости. Статья объясняет это через аналогию «учитель — ученик». Ключ — soft labels: обычное обучение учит только «ответ — кошка» (hard label), а дистилляция передаёт всё распределение вероятностей учителя, например «90% кошка, 8% собака, 2% лиса», чья степень сомнения несёт богатую информацию; параметр temperature смягчает вероятности, открывая тонкие отношения (реальный пример: функция API OpenAI 2024 года для обучения малых моделей на выходах крупных). Преимущества: быстро и дёшево, намного компактнее при близкой к учителю производительности (TinyBERT: в 7,5 раза меньше, более 96,8%), работа на edge, сила в специализации. Два подхода: white-box (полный доступ к весам и внутренним представлениям, более глубокий перенос; для своих или OSS-моделей) и black-box (видны только выходы/ответы API; чужой API как учитель может нарушать условия). Отличается от квантизации (сжатие точности весов той же модели) и fine-tuning (дообучение существующей модели под задачу) — дистилляция переносит знания в отдельную малую модель, и все три комбинируемы. Правовая сторона стала большой темой 2026 года: технология легитимна, но OpenAI, Anthropic и xAI имеют анти-конкурентные положения о дистилляции, запрещающие использовать выходы для создания конкурирующих моделей, поэтому дистилляция конкурента из ограниченного API может нарушать условия. Спор OpenAI против DeepSeek (OpenAI заявила, что связанные с DeepSeek аккаунты обходили ограничения, чтобы получить выходы для дистилляции, тогда как условия DeepSeek, по сообщениям, разрешают дистиллировать её выходы) показывает, что оценка зависит от того, чьи условия API применяются, а Claude Fable 5/Mythos 5 переключают запросы, помеченные как дистилляция, на менее мощную модель Opus. Советы: используйте свои или лицензированные 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 всей сессии. Наблюдать плюс оценивать — вот что делает ИИ продакшен-уровнем. Иллюстрации и характеристики приведены по публичным материалам, как ориентир.

Практическое продолжение статьи «Что такое мультиагентная система?». Главное правило: сначала строить на одном агенте и добавлять агентов минимально, только упёршись в предел (в исследовании Google Research все мультиагентные схемы были на 39–70% хуже на строго последовательной задаче, а Anthropic сообщает, что мультиагентные системы расходуют примерно в 15 раз больше токенов, чем чат). Базовая форма — паттерн supervisor: субагенты в Claude Agent SDK, agents as tools в OpenAI Agents SDK. Помимо 5 шагов (декомпозиция, определение worker, проектирование supervisor, передачи, измерения) — минимальный код для обоих SDK по официальной документации (один supervisor, исследователь и проверяющий), ограничение инструментов каждой роли, три уровня лимитов (maxTurns, max_turns, расходы), когда выбирать handoff, удачные и неудачные разбиения ролей и реальные ошибки Anthropic (50 субагентов на простой запрос, дублирование поиска) с решениями.

Теперь, когда ИИ-агенты стали обыденностью, следующий вызов — как заставить агентов работать сообща. Если 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.