Архитектурные проблемы современных LLM-агентов

Архитектурные проблемы современных LLM-агентов

LLM-агент отличается от обычного программного клиента тем, что между намерением и действием находится вероятностная модель. Пока агент только отвечает текстом, цена ошибки ограничена ответом. Когда он получает память, API, инструменты и право изменять реальные данные, обычные архитектурные решения начинают проявлять новые классы риска.

Этот Concept — общий узел для систематизации таких проблем. Он не утверждает, что все перечисленные вопросы уже решены или даже полностью сформулированы. Задача — накапливать реальные наблюдения из эксплуатации агентов, связывать их с существующими инженерными практиками и постепенно выделять agent-native архитектурные принципы.

Уже заметные классы проблем

  • Гранулярность мутаций. Агенту часто дают CRUD-операцию полной замены сущности, хотя его намерение относится только к одному фрагменту. Это увеличивает область потенциальной ошибки.
  • Устаревший контекст и конкуренция изменений. Между чтением и записью объект может измениться другим пользователем, агентом или процессом.
  • Валидация и ограничение последствий. Инструмент должен не только позволять действие, но и проверять его предпосылки и ограничивать область изменения.
  • Обратимость. Агентские изменения желательно делать наблюдаемыми, проверяемыми и откатываемыми.
  • Контекст и стоимость его передачи. Более структурированное представление данных может повышать надёжность рассуждения, но резко увеличивать количество токенов и стоимость взаимодействия.
  • Семантика инструментов. Для агента важно понимать не только схему параметров, но и свойства операции: изменяет ли она состояние, является ли разрушительной, идемпотентной, можно ли её безопасно повторить.

Связь с существующими подходами

Проблема частичных изменений не появилась вместе с LLM. HTTP PATCH был стандартизирован именно для частичной модификации ресурса вместо полной замены: RFC 5789. Для структурированных JSON-документов существует JSON Patch — RFC 6902.

Современные coding agents также используют granular-edit подходы. OpenAI предоставляет инструмент Apply Patch, где модель создаёт, обновляет и удаляет файлы через структурированные diff-операции вместо необходимости возвращать полный файл. GitHub Copilot coding agent делает изменения в отдельной ветке и предлагает пользователю проверять итоговый diff: GitHub Copilot coding agent.

На уровне tool-протоколов MCP отдельно описывает инструменты как операции внешнего воздействия, а развитие спецификации вводит словарь риска вокруг readOnly, destructive, idempotent и других свойств: MCP Tools specification, Tool Annotations as Risk Vocabulary.

Эти практики решают разные части общей задачи, но не образуют готовой универсальной архитектуры безопасного редактирования произвольного CMS-контента LLM-агентами.

Текущий статус

Это исследовательское направление. Реализация общего agent-safe mutation слоя в haih-agent пока не начата. Отдельные проблемы будут выноситься в дочерние Concepts по мере того, как они проявляются в реальной работе и становятся достаточно понятными для предметного анализа.