Почему один огромный агент хуже нескольких маленьких

Частенько, когда компании нужно сделать агента, строят одного большого. В него запихивают все MCP, скиллы и тулы. И кажется, что теперь агент будет уметь вообще все.

На практике выходит, что ответы у агента не очень. А токены незаметно улетают в никуда.

Так получается из-за перегруженного контекста. Агент с кучей инструментов тянет туда все описания тулов и скиллов, а места на саму задачу почти не остается.

Что с этим делать?

Иногда лучше и проще разделить одного агента на несколько маленьких. Каждый будет отвечать за свою область, а контекст перестанет перегружаться. Это тот же принцип, что с микросервисами. Один сервис — одна задача.

Кроме того, маленькие агенты легче отлаживать, поддерживать и контролировать. А еще для них легче подбирать модель под задачу. Например, взять недорогую модельку для простых операций и более мощную для сложных. С монолитным агентом позволить себе такое нельзя.

Еще разделение позволяет более гибко управлять запуском. Если агенту для задачи нужен один скилл и маленькая модель, вы даете ему только их. Никаких лишних MCP и перегруженного контекста.

В итоге несколько небольших агентов обходятся дешевле, работают быстрее и выдают результат лучшего качества.