Сейчас работаю над парой проектов с AI-агентами и поймал себя на мысли, что, кажется, вывел один из главных паттернов в построении таких систем. И, кстати, этот паттерн не самый интуитивный.

Смотрите, когда мы говорим про классический software, наша задача — добиться high cohesion, low coupling. Другими словами, не делать монолит, а разбить функционал на маленькие кусочки с четкими границами ответственности, которые общаются между собой, но при этом не разбивать на слишком много мелких частей.

Но с AI-агентами ситуация другая. Если можно вместо того, чтобы создавать нового агента, дать новый тул уже существующему агенту — это надо делать в 100% случаев (при условии, что агенты работают в одном домене). Гораздо сложнее дебажить нескольких агентов, чем одного с набором инструментов.

Приведу пример из моего вчерашнего проекта. Задача — парсить специфические данные по определенным темам, анализировать их и потом выдавать отчёт.

Изначально я думал сделать 4 разных агента:

• Парсинг RSS
• Парсинг Reddit
• Парсинг специальных сайтов
• Парсинг с помощью BrightData MCP

Но в этом случае всё сильно усложняется, особенно когда данные нужно складывать в PostgreSQL, потому что нужно удалять дубликаты перед записью. С 4 разными агентами это делать очень сложно и не стоит того.

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

Вообще, я где-то читал об этом, возможно, в каких-то ресерчах от Anthropic, но как-то не придал этому значения. В итоге пришёл к этому сам.

Буду рад обсудить в комментариях — как вы строите архитектуру AI-агентов? Сталкивались с похожими кейсами?

#AI #AIAgents #SoftwareArchitecture #TechTips #Automation #Python #MachineLearning #Anthropic #SoftwareDevelopment