Перевод с разбором · для Вани

Как устроены агенты

Зачем тебе это нужно

В твоей системе будет несколько LLM-задач: парсинг заявки, BOM-генератор, ревьюер сметы, ассистент мастера. Эти задачи можно организовывать по-разному: как жёсткий workflow (каждый шаг определён в коде) или как «агента» (LLM сама решает, что делать дальше). Эта статья — карта паттернов Anthropic. Она поможет выбрать нужный уровень сложности.

Workflow vs agent

• Workflow — путь прописан в Kotlin: «сначала вызов LLM A, потом B, потом сохранить». Предсказуемо, легко отлаживать.
• Agent — ты описываешь доступные инструменты и цель, путь модель выбирает сама. Гибко, но сложнее контролировать бюджет, задержку и корректность.

Augmented LLM — базовый кирпичик

Это модель + доступ к инструментам + «память». В твоём случае инструменты — функции из статьи про tool use (get_material_price, calculate_cuts, save_order). Память — данные из Postgres, которые ты явно подставляешь в промпт.

Пять паттернов workflow

1. Prompt chaining (последовательные вызовы)

LLM-вызов → результат → следующий LLM-вызов, использующий результат. Пример: заявка → парсер извлёк структуру → генератор BOM → ревьюер сметы.

2. Routing (маршрутизация)

Короткий классификатор определяет тип запроса, затем специализированный промпт обрабатывает его:

val type = classifyOrder(orderText)  // marshevaya | povorotnaya | vintovaya
val prompt = when (type) {
    "marshevaya" -> MARSH_PROMPT
    "povorotnaya" -> POVOROT_PROMPT
    "vintovaya" -> VINTOVAYA_PROMPT
    else -> GENERAL_PROMPT
}

Что здесь происходит: дешёвая модель-классификатор за 100 мс, основная обработка — специализированным промптом. Такой промпт всегда точнее, чем один универсальный «на всё».

3. Parallelization (параллельные вызовы)

Задача разбивается на независимые части — каждая в отдельном coroutine. Kotlin это делает хорошо. Пример: параллельно считать BOM и запрашивать «похожие прошлые заказы» для оценки, потом свести.

4. Orchestrator-workers

Центральная LLM-модель динамически разбивает задачу и делегирует подзадачи «воркерам». Сложная схема, пригодится когда масштаб вырастет (сотни вариантов материалов, гибкий прайс).

5. Evaluator-optimizer (черновик + критик)

Один промпт генерирует смету, второй — ревьюит («проверь, всё ли учтено, нет ли очевидных ошибок»), третий — исправляет. Три API-вызова, но качество заметно выше разовой генерации. Хорошо подходит для клиентских документов.

Настоящие агенты

Модель работает в цикле: план → вызов инструмента → результат → решение «что дальше» → … → финальный ответ. Для твоих задач на старте это overkill. Но держи в голове — когда workflow станет слишком громоздким (20+ шагов с условной логикой), агент может оказаться чище.

Три принципа дизайна Anthropic

1. Простота. Начинай с прямого API-вызова, усложняй только под доказанную нужду.
2. Прозрачность. Ты должен понимать, почему принято то или иное решение. Логируй все промежуточные шаги.
3. Хорошие описания tools. По ним модель решает, когда какой инструмент звать. Пиши как доку к API.

Что это значит для твоей системы

• MVP: один system prompt на задачу + few-shot. Это уже workflow. Этого хватает надолго.
• Следующий шаг: routing. Классификатор + 3–5 специализированных промптов. Качество и контроль вверх, стоимость почти та же.
• Для важных документов: evaluator-optimizer на смете. Генератор + ревьюер + исправитель. Три вызова — небольшие деньги против кривых смет клиентам.
• Не гоняйся за «настоящими агентами» пока workflow покрывает 90% кейсов. Иначе быстро теряешь контроль над бюджетом и корректностью.

Полная версия — в docs/building-effective-agents.html.