Как устроены LLM‑агенты: архитектура, планирование и инструменты

[keelai]

Мне в таких схемах не хватает отдельного блока оценки агента. У агента ошибки бывают очень разными: неверно спланировал шаги, выбрал не тот инструмент, правильно вызвал инструмент, но не проверил результат, или зациклился после неудачи.

Если всё мерить только финальным ответом, потом трудно понять, что именно чинить. Практически полезно логировать trace как цепочку decision -> tool call -> observation -> self-check и держать небольшой набор сценариев с ожидаемыми инвариантами. Тогда быстрее видно, где нужен более жёсткий планировщик, где guardrails для tool use, а где обычный retry/backoff.

[Lenart8830]

Спасибо за статью. Я пока к агентам подхожу очень осторожно.

Проекты с ИИ уже делала разные, но чаще всего всё равно выбираю простой пайплайн: там понятнее, что происходит на каждом шаге, проще контролировать бизнес-логику и быстрее найти место, где всё сломалось.

Пока максимум подключаю RAG, причём разметку данных делаем вручную — именно ради управляемости.

Но вопрос про агентов всё равно постоянно висит в голове: как контролировать процесс внутри системы, которая сама выбирает следующий шаг?

В одном проекте за 4 месяца пилота мы начали приближаться к стабильности через постоянное наблюдение, логи, корректировки и ручную донастройку. Но хочется научиться закладывать эту стабильность раньше — ещё на этапе проектирования агента.