К 2026 году «построить агента» — уже не исследовательский проект. Anthropic SDK поддерживает tool use из коробки, у любой серьёзной команды крутится хотя бы один продакшн-цикл на Claude Sonnet или Opus, и вопрос сместился с можно ли на какой паттерн. Честный ответ: большинство команд переусложняют. Тянут Tree-of-Thoughts туда, где 30-строчный ReAct-цикл уехал бы во вторник.
В этом посте — четыре паттерна, которые реально имеют значение: ReAct, Plan-and-Execute, Reflexion и Tree-of-Thoughts. С рабочим кодом против https://api.claudexia.tech/v1, заметками о том, когда эскалировать с Sonnet на Opus прямо внутри цикла, и практиками наблюдаемости, без которых это всё в проде не дебажится.
Ландшафт в 2026
Зоопарк агентных паттернов схлопнулся. Пять лет статей и фреймворков сложились в небольшой набор циклов, которые реально дают эффект:
- ReAct — чередуем рассуждение и вызовы инструментов. Дефолт.
- Plan-and-Execute — генерируем полный план, потом выполняем шаги.
- Reflexion — модель критикует собственный ответ и переделывает.
- Tree-of-Thoughts — параллельно исследуем несколько ветвей рассуждения и голосуем.
Всё остальное (CoT, ReWOO, LATS, AutoGPT-style бесконечные циклы) либо схлопнулось в одно из вышеперечисленного, либо тихо умерло. Claude Sonnet 4.6 настолько силён, что навороченные обвязки вредят больше, чем помогают. Базовая модель сама планирует, сама корректируется, сама понимает, когда вызвать инструмент. Ваша задача — дать правильный цикл, а не строить мозг.
ReAct: дефолтный sweet spot
ReAct — это первое, к чему стоит тянуться. Подумал, вызвал инструмент, получил наблюдение, подумал снова, повторил, пока не готово. API tool use у Anthropic построено ровно под этот ритм — фреймворк даже не нужен.
from anthropic import Anthropic
client = Anthropic(base_url="https://api.claudexia.tech/v1")
tools = [
{
"name": "search_docs",
"description": "Search internal documentation",
"input_schema": {
"type": "object",
"properties": {"query": {"type": "string"}},
"required": ["query"],
},
},
{
"name": "run_sql",
"description": "Run a read-only SQL query",
"input_schema": {
"type": "object",
"properties": {"sql": {"type": "string"}},
"required": ["sql"],
},
},
]
def react_loop(user_msg: str, max_turns: int = 10):
messages = [{"role": "user", "content": user_msg}]
for turn in range(max_turns):
resp = client.messages.create(
model="claude-sonnet-4.6",
max_tokens=4096,
tools=tools,
messages=messages,
)
messages.append({"role": "assistant", "content": resp.content})
if resp.stop_reason == "end_turn":
return resp
tool_results = []
for block in resp.content:
if block.type == "tool_use":
result = dispatch_tool(block.name, block.input)
tool_results.append({
"type": "tool_result",
"tool_use_id": block.id,
"content": result,
})
messages.append({"role": "user", "content": tool_results})
raise RuntimeError("max turns exceeded")
Это весь паттерн. Никаких графов, стейт-машин, оркестраторов. История диалога и есть состояние. Sonnet тащит на этом цикле workflow в 5–15 шагов без напряга.
Когда ReAct работает:
- Следующее действие зависит от предыдущего наблюдения (большинство реальных workflow).
- Инструменты дешёвые и быстрые (доли секунды).
- Заранее непонятно, сколько шагов потребуется.
- Нужен стриминг ответа пользователю.
Когда ReAct мешает:
- Шаги независимы и могли бы идти параллельно.
- Каждый вызов инструмента стоит реальных денег или времени.
- План нужно показать человеку до выполнения.
Plan-and-Execute: когда шаги независимы
Plan-and-Execute разделяет задачу надвое. Первый вызов — выдаёт нумерованный план. Второй проход — выполняет шаги, часто параллельно, часто на более дешёвой модели. Планировщик — Opus или Sonnet; исполнители — Haiku.
def plan_and_execute(goal: str):
plan_resp = client.messages.create(
model="claude-opus-4.7",
max_tokens=2048,
messages=[{
"role": "user",
"content": f"Produce a JSON plan to accomplish: {goal}\n"
f"Format: {{\"steps\": [{{\"id\": 1, \"action\": \"...\", "
f"\"depends_on\": []}}]}}",
}],
)
plan = json.loads(extract_json(plan_resp.content[0].text))
results = {}
for step in topological_sort(plan["steps"]):
deps = {d: results[d] for d in step["depends_on"]}
results[step["id"]] = execute_step(step["action"], deps)
return results
def execute_step(action: str, context: dict) -> str:
resp = client.messages.create(
model="claude-haiku-4.5",
max_tokens=1024,
tools=tools,
messages=[{
"role": "user",
"content": f"Context: {json.dumps(context)}\nDo: {action}",
}],
)
return resp.content[0].text
Экономика реальная. План от Opus — пусть $0.05; десять Haiku-исполнений — копейки. По сравнению с прогоном всего workflow целиком на Opus получаем сокращение затрат в 5–10 раз при сопоставимом качестве на хорошо декомпозируемых задачах.
Подвох: если шаг 3 показывает, что предположение шага 2 было неверным, статичный план не выкарабкается. Чистый Plan-and-Execute хрупок там, где мир кусается. Лекарство — перепланирование: после каждого шага спрашиваем у планировщика, имеет ли смысл остаток плана. Этот гибрид (иногда зовут Plan-Execute-Replan) — то, что реально едет в прод.
Используйте Plan-and-Execute, когда:
- Работа чисто декомпозируется в независимые шаги.
- Шаги можно гонять параллельно и хочется ускорения.
- Человеку или аудиту нужно увидеть план до исполнения.
- Большинство шагов простые — хватит Haiku.
Reflexion: качество по цене 3x токенов
Reflexion добавляет проход самокритики. Агент пытается решить задачу, потом второй промпт просит оценить собственный ответ против исходной цели, найти косяки и переделать с этой критикой в контексте. Работает — и стоит.
def reflexion(task: str, max_attempts: int = 3):
history = []
for attempt in range(max_attempts):
attempt_resp = client.messages.create(
model="claude-sonnet-4.6",
max_tokens=4096,
messages=[{
"role": "user",
"content": f"Task: {task}\n"
f"Previous attempts and critiques:\n{format_history(history)}",
}],
)
answer = attempt_resp.content[0].text
critique_resp = client.messages.create(
model="claude-opus-4.7",
max_tokens=2048,
messages=[{
"role": "user",
"content": f"Task: {task}\nProposed answer:\n{answer}\n\n"
f"Is this correct and complete? If not, identify "
f"specific failures. Reply with PASS or detailed critique.",
}],
)
critique = critique_resp.content[0].text
if critique.strip().startswith("PASS"):
return answer
history.append({"answer": answer, "critique": critique})
return answer
Паттерн примерно утраивает расход токенов — за каждую успешную задачу платим попыткой плюс критикой, на каждый ретрай — ещё один раундтрип. На открытых задачах генерации (тексты, код, аналитика) Reflexion измеримо поднимает качество. На чётких tool-use задачах он только добавляет латентности.
Берегите Reflexion для safety-critical workflow. Сгенерировать клиентское юридическое summary? 3x оправданы. Завести тикет в Jira? ReAct.
Tree-of-Thoughts: в 2026 редко окупается
Tree-of-Thoughts (ToT) гоняет несколько ветвей рассуждения параллельно, оценивает их и выбирает победителя. В 2023 с GPT-4 и Claude 2 это давало реальный сигнал на сложных рассуждениях. В 2026 с Sonnet 4.7 и Opus 4.7 single-shot reasoning базовой модели уже настолько хорош, что накладные расходы на параллельные ветви почти не отбиваются.
ToT всё ещё вижу в двух нишах:
- Состязательный поиск (игры, головоломки), где реально нужен lookahead.
- Generative design — когда нужен разнообразный набор кандидатов, а не один лучший ответ.
Для бизнес-workflow, RAG и tool use? Пропускайте. Compute, потраченный на три параллельных дерева рассуждений, лучше пустить на Reflexion или просто апгрейднуться до Opus.
Эскалация Sonnet → Opus прямо внутри цикла
Паттерн, который тихо стал стандартом в 2025: начинаем цикл на Sonnet и эскалируемся на Opus только когда Sonnet даёт сигнал неуверенности. Детектится либо парсингом hedging-языка модели («не уверен», «неоднозначно»), либо проверкой, не ходят ли вызовы инструментов по кругу.
def adaptive_react(user_msg: str):
model = "claude-sonnet-4.6"
messages = [{"role": "user", "content": user_msg}]
consecutive_tool_failures = 0
for turn in range(15):
resp = client.messages.create(model=model, max_tokens=4096, tools=tools, messages=messages)
messages.append({"role": "assistant", "content": resp.content})
if resp.stop_reason == "end_turn":
return resp
if detect_uncertainty(resp.content) or consecutive_tool_failures >= 2:
model = "claude-opus-4.7"
# ... обработка tool_use блоков, обновление consecutive_tool_failures ...
Математика затрат сходится. Большинство шагов идут на дешёвом Sonnet; цены Opus платим только на сложных. Для нагрузок со смешанной сложностью это стабильно режет расходы на 60–70% против тотального Opus — без измеримой потери качества на лёгких шагах.
Observability: логируем всё
Самая большая ошибка, которую я вижу в продакшн-агентах, — непрозрачное логирование. Команды пишут «агент крутился 8 шагов и финишнул» и дальше понятия не имеют, почему появилась регрессия.
Минимально жизнеспособная наблюдаемость для агентного цикла:
- Каждый
tool_use-блок: имя инструмента, аргументы, таймстемп, номер шага. - Каждый
tool_result-блок: tool_use_id, вывод (обрезанный, если огромный), латентность, success/failure. - Каждый ответ модели: имя модели, input tokens, output tokens, stop_reason.
- Полная история сообщений на конец цикла, хранить минимум 30 дней.
У OpenTelemetry уже есть разумные конвенции под это (spans на каждый шаг, атрибуты под имена инструментов и счётчики токенов). Что бы вы ни использовали, тест один: сможет ли человек через шесть недель понять, почему агент сделал то, что сделал, во вторник в 15:00? Если нет — летите вслепую.
Маленькая, но недооценённая практика: логируйте промпт, который породил ответ, а не только сам ответ. Когда промпты дрейфуют между деплоями, вам нужна возможность их diff-ать.
Итог
После двух лет гонения этих паттернов в проде:
- По умолчанию — ReAct. Простейший цикл, который тащит 80% реальной работы. Стройте сначала его.
- Plan-and-Execute берите, когда шаги независимы и параллелятся или когда план должен увидеть человек.
- Reflexion добавляйте только на safety-critical или quality-critical вывод. 3x по токенам — это реально; платите осознанно.
- Tree-of-Thoughts пропускайте, если у вас не состязательный поиск и не generative design. Современный Claude слишком хорош, чтобы накладные расходы окупались на нормальных нагрузках.
- Эскалируйте Sonnet → Opus прямо в цикле ради экономики. Большинству шагов Opus не нужен.
- Логируйте каждый tool_use и tool_result. Будущий вы скажете спасибо.
Циклы простые. Дисциплина — в том, чтобы не строить больше цикла, чем нужно.