Архитектурные проблемы современных 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 по мере того, как они проявляются в реальной работе и становятся достаточно понятными для предметного анализа.