Топ-5 проблем, с которыми я столкнулся при разработке AI-агентов
Когда я начал делать агентов под разные задачи внутри компании, я довольно быстро понял что задача не сводится просто к хорошему промпту.Промпт важен, но он закрывает только верхний слой, а дальше начинается обычная инженерная работа - контекст, память, доступы, инструменты, состояние, git, фоновые задачи и т.д. и т.п. И если это не проектировать отдельно, агент может нормально справиться с короткой задачей, но начать сыпаться на длинной работе.
Анатомия ночных продаж: как n8n и два Salesbot’а закрывают слепые зоны в amoCRM
Дисклеймер: в статье упоминается Meta — организация, признанная экстремистской и запрещённая на территории РФ.Все ключи, телефоны и названия в примерах изменены; код, схема, логика и скрины‑ из рабочего проекта заказчика, и строго с его разрешения! Статья не является рекламой/самопиаром и тому подобное. В прошлой статье
От чата вместо форм до разработки без конфигуратора: что меняется в экосистеме 1С
ИИ в разработке постепенно перестает быть отдельной экспериментальной темой. Его встраивают в IDE, подключают к корпоративным системам через MCP, используют для создания приложений и подготовки кода. Одновременно появляются новые среды, плагины и подходы к архитектуре данных.
Инженерный подход к этимологии русского (индоевропейского) праязыка и преодоление «ленивых ответов» LLM
Введение. Парадокс современных технологийПрошло четыре месяца с момента выхода в свет моей книги «Живое слово от истоков до современности. Этимология русского языка на основе методов системного анализа». Пятое издание. Книга-анонс.» У части моих друзей, знакомых с искусственным интеллектом (ИИ), нейронными сетями появились вопросы по комментариям ИИ в отношении книги. Это важный вопрос, поэтому подготовил данный материал.
Я заставил ИИ‑агента работать по протоколу тушения пожаров. За шесть дней он переписал сам себя 10 раз
В какой‑то момент я перестал доверять фразе «готово» от языковой модели.Модель при этом не врёт: она честно считает, что сделала работу. Она пишет «реализовано, тесты проходят», и чаще всего так и есть. Беда в остальных случаях, когда модель поправила один вызов из четырёх, приняла собственный план за выполненную работу и закрыла задачу. Диалог при этом выглядит безупречно до самого конца.Я перепробовал обычный набор: писал развесистые CLAUDE.md
502 на ingress, 302 в приложении: как я учил инфраструктурного LLM-агента не врать
Сначала контекст. Я делаю внутреннего read-only агента для инфраструктурных расследований: он может читать данные, но не изменять production. Инженер пишет ему в Mattermost или резервном web-чате обычный вопрос: «почему сервис отдаёт 502?», «кто выкатил эту версию?» или «что изменилось перед инцидентом?». Агент сам собирает данные из Kubernetes, VictoriaMetrics, Elasticsearch, GitLab, Grafana, GSLB и других эксплуатационных источников, а затем возвращает ответ с доказательствами и явно перечисленными пробелами.
Агенты, или Путешествие к LLM и обратно
Агенты сейчас обсуждают все подряд. Меняются фреймворки, появляются MCP-серверы, облака обещают «агента из коробки». Но в центре любой такой схемы по-прежнему одна и та же вещь — LLM: она читает контекст и формулирует следующий шаг. А между запросом к агенту и самой моделью — ещё несколько слоёв.
LLM-wiki против RAG: Оцениваем и сравниваем
Про LLM-wiki здесь уже было несколько хороших статей (1, 2 и 3), поэтому подробно останавливаться на идее Andrej Karpathy не буду. В двух словах: вместо RAG-ретривера - wiki-агент, вместо чанков из сырых документов - связанные концепт-страницы, вместо обновления - перекомпиляция и поиск «битых» ссылок.
