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

Вы упёрлись в недельный лимит токенов Claude Code, но квота полностью восстановилась раньше, чем прошло семь дней — причём не раз. В интернете даже есть разборы про «скрытый механизм», где утверждается, что недельный лимит сбрасывается каждые 72 часа. Правда ли это? Эта статья прослеживает явление до первоисточников. Но Anthropic не задокументировала внутренний механизм сброса, а лимиты постоянно меняются, поэтому мы чётко помечаем три вида информации: факты, подтверждаемые из официальных источников; события, которые многие пользователи воспроизводимо наблюдают, но которые Anthropic не прокомментировала; и не подтверждённые домыслы из единственного источника. Суть: раннее полное восстановление в большинстве случаев — это нерегулярные глобальные сбросы Anthropic (объявляются неоднократно через @ClaudeDevs); показанное время сброса к тому же доказуемо нестабильно; а гуляющая «72-часовая периодичность» основана на единственном наблюдателе, не воспроизведена и опровергается другим наблюдением (24 ч), так что её нельзя считать фактом. Там, где что-то нельзя утверждать, мы прямо об этом говорим — исследование от июля 2026.

Вы построили всё на OpenAI, затем захотели попробовать Claude и сравнить Gemini — и потеряли часы на разных SDK, форматах и обработке ошибок у каждого провайдера. LLM-шлюз (AI-шлюз / LLM-прокси) — это ретранслятор, который вы ставите между приложением и провайдерами: он предоставляет один совместимый с OpenAI API для обращения к любой модели и берёт на себя сквозные задачи — fallback, учёт затрат, виртуальные ключи, кэширование, ограничение частоты и наблюдаемость. В этом гиде: зачем он нужен, что такое шлюз на самом деле, три типа (self-hosted прокси = LiteLLM / hosted = OpenRouter / SDK = Vercel AI SDK), как выбрать среди LiteLLM, OpenRouter и Vercel AI SDK, минимальный код настройки, где меняется лишь эндпоинт, и ограничения — скачок задержки, шлюз как новая точка отказа, комиссии (OpenRouter берёт 5,5% при пополнении), потеря возможностей и приватность.

Построив ИИ-агента, вы всегда упираетесь в одну стену: «Хорошо, но он вообще работает?» Механизм, позволяющий решить, стало от изменения промпта или модели лучше или хуже на основе данных, а не интуиции, — это evals. LLM выдают разный результат каждый раз для одного и того же ввода, поэтому юнит-тесты на точное совпадение не подходят. Эта статья делает упор на практические шаги — как собрать evals и запустить их в работу — и рассказывает о пяти способах измерить качество (① сверка с эталоном ② проверки по правилам ③ LLM-as-judge ④ регрессионное тестирование ⑤ мониторинг в продакшене), об оценке, специфичной для агентов (доля успешных задач, корректные вызовы инструментов, траектория, стоимость), о том, как начать с малого с 20 примеров отказов, о частых ловушках и ключевых инструментах (Anthropic Console/Evals, OpenAI Evals, LangSmith, Langfuse, Ragas) — она написана для практиков.

Извечный вопрос автоматизации: «ИИ-агенты или RPA?» Ответ — не «или — или»: выбирайте по роли, а выигрышный паттерн 2026 года — гибрид обоих. RPA — детерминированные «руки», которые быстро и точно выполняют фиксированную процедуру (но ломаются при изменении экрана/спецификации); ИИ-агент — вероятностный «мозг», который считывает ситуацию и принимает решение (силён в неоднозначности и исключениях, но результат не одинаков каждый раз). В статье: разница в принципе действия, сравнительная таблица (компромисс воспроизводимости и устойчивости к изменениям), как выбрать (ось — «можно ли полностью описать правилами?»: да → RPA, суждение, которое не описать → ИИ-агент), тренд 2026 года (лидеры RPA — UiPath, Automation Anywhere, Blue Prism — становятся агентными; сближение; вопрос уже не «что из двух», а «где живёт рассуждение» = оркестрация прежде всего) и практический ответ: гибрид, где мозг (ИИ-агент) отвечает за суждение/оркестрацию, а руки (RPA) выполняют детерминированное исполнение — не ставьте агента туда, где нужна детерминированность, а делегированное суждение сочетайте с ограждениями и согласованием человеком. На основе официальной информации вендоров, с FAQ.

Claude Fable 5 и Opus 5 — обе модели верхнего эшелона, но ответ звучит ни как «всегда Fable 5», ни как «всегда Opus 5»: выбирать нужно под задачу. Выход Opus 5 24 июля 2026 года заметно сместил этот ответ: предыдущее поколение, Opus 4.8, занимало нишу «на ступеньку слабее Fable 5, зато вдвое дешевле», тогда как Opus 5 сохраняет ту же цену $5 / $25 и при этом не уступает Fable 5 на агентных бенчмарках, а местами и обходит её (Frontier-Bench 43.3% против 33.7% и OSWorld 2.0 70.6% против 66.1% — цифры из прессы; по CursorBench 3.2 Anthropic официально заявляет, что укладывается в 0.5% от результата Fable 5 примерно за половину стоимости). Самые сложные рассуждения «в один заход» пока склоняются к Fable 5, но с минимальным отрывом: Humanity's Last Exam 56.5% против 56.3% и DeepSWE v1.1 69.7% против 68.8% (данные прессы). По характеристикам модели совпадают — контекстное окно 1M и максимальный вывод 128K; быстрый режим (примерно в 2.5 раза) есть только у Opus 5, но стоит вдвое дороже и работает только в Claude API, зато у Opus 5 более свежая граница знаний — май 2026 года. Схема решения: сначала пробуйте Opus 5 и поднимайтесь к Fable 5 только там, где он выходит на плато. На практике оптимальна связка «Opus 5 как основа, Fable 5 для сложного», подкреплённая автопереключением при блокировках защиты в приложении и новым резервным режимом «default» в API. Разбираем доступность (приостановка в июне, повторное развёртывание в июле), отказ от зависимости от одной модели, настройку effort ради экономии и частые вопросы — связывая кластер материалов по Fable 5 с руководством по релизу Opus 5.

Первое препятствие при встраивании ИИ-агента в реальную работу — «на каком фреймворке его собирать». С точки зрения разработчика и того, кто выбирает технологии, статья сравнивает шесть главных фреймворков — LangGraph, CrewAI, AutoGen (вошедший в Microsoft Agent Framework, GA апрель 2026), OpenAI Agents SDK, Google ADK и Claude Agent SDK — по подходу к оркестрации (ориентированный граф / ролевая команда / диалоговый GroupChat / передачи управления / иерархическое дерево / автономный цикл инструментов), языку, кривой обучения, управляемости, зрелости для прода, стоимости токенов и наиболее подходящему сценарию. Ключевая оговорка: фреймворк, «быстрейший для прототипа» (CrewAI), может оказаться самым дорогим в проде — около 3× токенов (41k против 18.5k у LangGraph в одном бенчмарке) и недетерминированный, что плохо подходит для финансов и здравоохранения. Также объясняется, как 2026 год принёс интероперабельность через MCP (инструменты) и A2A (агент-агент), так что агенты из разных фреймворков теперь работают вместе, а привязка ослабла. Включает гид по выбору под задачу и FAQ.

Ollama — стандартный инструмент с открытым исходным кодом для запуска локальных LLM, который берёт на себя почти всю утомительную настройку и позволяет скачать модель и начать диалог одной командой. В этом руководстве для новичков мы разберём весь путь от начала до конца: установку на Windows, Mac и Linux, основные команды, выбор моделей по размеру и VRAM, добавление GUI вроде Open WebUI, использование локального и совместимого с OpenAI API для встраивания в приложения, настройку через Modelfile и переменные окружения, а также решение типичных проблем.

Какую локальную LLM поставить первой? В статье разобраны основные семейства моделей 2026 года — Qwen, Llama, Gemma, DeepSeek, Mistral, Phi — по разработчику, стране происхождения, сценарию, размеру и лицензии, чтобы помочь выбрать модель под ваш ПК и задачи. Отдельный раздел посвящён русскоязычным и локальным моделям: мультиязычные Qwen и Llama с сильным русским, открытые проекты Saiga, Vikhr и T-lite / T-pro от Т-Банка, а также пояснение, почему YandexGPT и GigaChat — это в основном облачные API, а не локальные модели с открытыми весами.

Запустится ли локальная LLM на вашем ПК, на 90% решает VRAM — память GPU. В этой статье собраны быстрая таблица требуемого VRAM по размеру модели (7B, 13B, 32B, 70B) и простая формула расчёта, разобрано влияние квантизации (FP16/Q8/Q4) и ловушка с KV-кэшем, который растёт вместе с длиной контекста. Приведены реалистичные скорости для RTX 3060/4090/5090 и Mac, а также рекомендуемые сборки по трём бюджетным уровням, чтобы новичок сразу понял, что покупать.

Локальная LLM на вашем ПК против облачных Claude, ChatGPT и Gemini — оба «LLM», но различаются по качеству, стоимости, приватности и усилиям. Эта статья ставит их рядом в одном сравнении и честно показывает, насколько по состоянию на 2026 год сократился часто неправильно понимаемый «разрыв в качестве». Затем она подскажет, что выбрать под вашу задачу, разбирая железо для разных размеров моделей и точку безубыточности по стоимости. Для большинства людей ответ — гибрид: повседневная работа локально, самые сложные части в облаке.

Регулятор «Faster ↔ Smarter» в Claude Code задаёт, сколько токенов модель тратит на ответ. У effort 5 уровней (low–max), а ползунок добавляет режим Ultracode — итого 6 пунктов. Разбираем, почему «Extra» = xhigh (а не максимум), как настроить через /effort и какой уровень выбирать.

Agent Evals — это процесс систематического измерения того, способен ли агент, который использует инструменты и делает несколько шагов к цели, действительно выполнять свои задачи. Это эволюция LLM evals, расширяющая объект оценки с «одного вывода» до «последовательности действий». Поскольку агент планирует, вызывает инструменты и обновляет состояние, одного финального вывода недостаточно; Google отмечает, что нужно понимать «почему» за действиями агента, и делит оценку на финальный ответ и trajectory. Пять измерений: outcome (успех задачи, судят по финальному состоянию — существует ли бронь в DB, а не по высказыванию «я забронировал»), trajectory (разумные шаги, правильные инструменты в правильном порядке), корректность использования инструментов (правильный инструмент и аргументы, проверка имён функций и типов), эффективность (шаги, токены, стоимость, задержка — часто сигналы observability, привнесённые в оценку) и качество финального ответа (через LLM-as-judge или рубрику). Грейдеры — это код (быстрый/дешёвый/воспроизводимый, но хрупкий), LLM-as-judge (гибкий, но недетерминированный и требует калибровки) и человек (золотой стандарт, но дорогой — избегайте по возможности). Anthropic рекомендует оценивать результат, а не путь: механическое сопоставление trajectory «слишком жёсткое и хрупкое», поскольку агенты находят допустимые альтернативы, тогда как Google и Microsoft предлагают метрики сопоставления trajectory для диагностики провалов. Уникальные подводные камни — недетерминированность (pass^k), накапливающиеся ошибки (p^t), reward hacking (роботизированная рука DeepMind, имитирующая захват) и устаревшие или загрязнённые наборы eval. Практический приём, по Anthropic: превратить 20–50 продакшен-провалов в тест-кейсы, запустить автоматическую оценку в CI, разделить capability и regression evals и писать их рано. Бенчмарки вроде SWE-bench, tau-bench, WebArena, GAIA, OSWorld и BFCL полезны как референсы (оценки меняются от версии, поэтому не принимайте их за чистую монету). На основе официальной информации, с пометкой неопределённостей.