📱

Get Our Mobile App

Take your business learning on the go!

Download on the App StoreGet it on Google Play

STOP Using MCP Like This, Use MCP 2.0 Instead (Save 98% More Tokens)

Nick Puru | AI Automation18:43

Transcription

Enthropic только что опубликовал кое-что о MCP, что должен услышать каждый, кто создает ИИ-агентов. Если вы использовали протокол контекста модели в продакшене, вы, возможно, заметили, что ваши агенты галлюцинируют больше, чем должны. Ваши затраты на токены выходят из-под контроля, а рабочие процессы случайным образом ломаются, когда достигают пределов контекста. И вот что вам никто не говорит. Дело не в том, что MCP сломан. Дело в том, что способ, которым все использовали MCP, фундаментально неэффективен. Теперь я говорю о сжигании на 98% больше токенов, чем вам нужно, и ваши агенты путаются, потому что их контекст загроможден сотнями определений инструментов, которые они никогда не будут использовать. Так что, если вы создаете ИИ-системы для клиентов или запускаете эти системы в продакшене для своего собственного бизнеса, это меняет все, что на самом деле надежно и прибыльно. Теперь я занимаюсь созданием ИИ-автоматизаций для бизнеса уже 2 года, и я сталкивался с этими точными проблемами на предыдущих проектах. Окна контекста достигают максимума, затраты взлетают до такой степени, что экономика просто не работает, а агенты совершают глупые ошибки, потому что слишком много шума. Теперь то, что Enthropic только что изложил, это не какой-то новый инструмент, который вам нужно изучить. Это совершенно другой способ думать о ваших агентах и о том, как они взаимодействуют с серверами MCP, и это решает все эти проблемы. Итак, позвольте мне просто разбить, что это на самом деле означает для вас. Итак, большинство из вас к настоящему моменту знают, что такое MCP. Протокол контекста модели. Это стало отраслевым стандартом для подключения ИИ-агентов к любым внешним инструментам и источникам данных. Гениальность MCP заключается в том, что вы просто создаете сервер один раз, и любой агент может к нему подключиться. Таким образом, мы видели, как тысячи таких серверов были созданы за последние годы. Вся экосистема взорвалась, потому что наконец-то у нас появился универсальный способ подключения агентов к чему угодно, например, к Gmail или Slack, базам данных, CRM, чему угодно. Итак, вы создаете сервер MCP, и вы закончили. Но вот проблема, которая возникает в тот момент, когда вы начинаете создавать что-то сложное для реальных клиентов и пытаетесь запустить это в продакшене. Все сваливается в окно контекста вашего агента, и это становится полным беспорядком. Итак, позвольте мне привести пример из нашей собственной работы. Итак, мы недавно создали систему для юридического клиента. Теперь им нужно было, чтобы их агент просто искал прецедентное право и извлекал некоторые из их документов из их системы управления документами, проверял их внутреннее программное обеспечение для управления и обновлял некоторые из их календарей, отправлял электронные письма клиентам и, по сути, просто регистрировал все в их CRM. Итак, у них было около шести разных систем, верно? Звучит довольно разумно. Теперь каждый сервер MCP имел, возможно, 15-20 различных инструментов, которые вы могли использовать. Итак, теперь мы смотрим на более чем сто различных функций. И вот что было так пагубно: даже несмотря на то, что агент использует только три или четыре из этих инструментов для любой конкретной задачи, все 100 определений инструментов загружаются в окно контекста с самого начала. Итак, каждая функция имеет свое описание. У нее есть обязательные параметры, необязательные параметры, типы возвращаемых значений, примеры. Итак, мы говорим о десятках тысяч токенов, которые просто лежат там, прежде чем агент даже прочитает, что пользователь хочет, чтобы он сделал. Таким образом, немедленно ваши затраты выше, чем должны быть. Ваше время отклика будет медленнее, потому что агенту приходится обрабатывать весь этот шум. И вот что я заметил, что действительно важно для продакшн-систем: агент совершает больше ошибок, когда в контексте слишком много беспорядка. Итак, он путается в том, какой инструмент на самом деле использовать. Он галлюцинирует несуществующие параметры. Он пытается вызывать инструменты способами, которые не имеют смысла. И когда у вас есть сто определений инструментов, конкурирующих за внимание, точность агента просто падает. И это огромная проблема, когда вы запускаете это для реальных клиентов, которые ожидают, что это будет работать надежно. Но это только первая проблема. Вторая проблема еще более жестока для вашей экономики. Итак, скажем, вашему агенту нужно получить стенограмму допроса из системы документов. Эта стенограмма может составлять 40 000 токенов. И при традиционном способе использования MCP вся эта стенограмма загружается в контекст агента. А затем агенту нужно обобщить ключевые моменты и обновить файл дела в CRM. Итак, теперь та же стенограмма на 40 000 токенов обрабатывается снова, когда агент просто записывает ее в следующую систему. Таким образом, вы буквально платите за то, чтобы одни и те же данные проходили через ваш контекст несколько раз. И если вы связываете несколько операций между разными системами, ну, вы просто достигнете пределов окна контекста или полностью исчерпаете свой бюджет API, прежде чем даже завершите рабочий процесс. Теперь у меня были проекты, где стоимость токенов делала все экономически сомнительным. И это еще до того, как мы поговорим о проблемах надежности из-за ограничений контекста до достижения любого промежуточного рабочего процесса. Итак, вот где выполнение кода меняет всю игру. И это действительно просто понимание того, как ИИ-модели на самом деле работают лучше всего. Итак, вместо того, чтобы представлять ваши инструменты MCP как вызовы функций, которые агент делает напрямую, вы просто представляете их как файловую систему, которую агент может исследовать. Итак, каждый сервер MCP становится папкой, а каждый инструмент на этом сервере — файлом TypeScript, и агент может просто искать по структуре, находить именно то, что ему нужно, а затем писать код для использования этих конкретных инструментов. И вот почему этот подход намного мощнее и надежнее. ИИ-модели фундаментально обучены на огромных объемах кода на этапе предварительного обучения. Итак, мы говорим о миллионах и миллионах строк кода. Итак, вызов инструментов — это то, чему они учатся на этапе постобучения с гораздо меньшими вычислительными ресурсами. Итак, когда вы позволяете агенту писать код для фактического взаимодействия с вашими серверами MCP, вы просто используете то, в чем модель действительно преуспевает, вместо того, чтобы просто заставлять ее в более жесткую структуру, в которой она менее естественно хороша. Итак, позвольте мне просто провести вас через то, как рабочий процесс на самом деле меняется между этими двумя подходами, чтобы вы могли увидеть всю разницу между ними. Итак, при традиционном подходе все ваши определения инструментов загружаются в окно контекста с самого начала. А затем пользователь просит что-то. Итак, агент должен просеять весь этот шум, чтобы понять, какие инструменты вообще имеют отношение к его цели. А затем он вызывает инструмент A и получает, возможно, 40 000 токенов данных. Все это попадает в контекст, а затем ему нужно вызвать инструмент B, используя некоторые из этих данных. Итак, еще 30 000 токенов проходят, и ваше окно контекста быстро заполняется, и агент изо всех сил пытается отслеживать все и вычислять задачи без каких-либо ошибок. Теперь, если вы сравните это с подходом выполнения кода, с другой стороны, агент имеет доступ к этой организованной файловой структуре ваших серверов MCP и всем их соответствующим инструментам. Итак, пользователь просит что-то, а затем агент ищет нужную папку с инструментами и находит то, что ему действительно нужно, а затем загружает только это конкретное определение инструмента, а не каждый инструмент с каждого сервера. Итак, уже гораздо меньше шума и гораздо меньше путаницы, а затем он просто пишет код для вызова этого инструмента. Итак, вот большая часть этого: результаты остаются в переменной песочницы прямо за пределами контекста агента. Итак, агент затем может писать больше кода для фильтрации этих данных, преобразования их и извлечения, ну, только того, что на самом деле имеет значение, и только окончательный обработанный результат, возможно, 500 токенов вместо 40 000, возвращается в окно контекста агента. Теперь агент никогда не перегружается огромными объемами данных, которые ему не нужны. Итак, разница абсолютно огромна как для надежности, так и для стоимости, что, очевидно, очень важно. Итак, пример юридической стенограммы, которую я упомянул: вместо 40 000 токенов, проходящих через контакты дважды, вы говорите примерно о 2000 токенов всего для всей операции. И агент выполняет всю тяжелую работу по обработке данных в среде песочницы, где он может фактически фильтровать, преобразовывать и извлекать только то, что имеет отношение. А затем он вернет только ключевую информацию, которая ему нужна. И поскольку контекст остается чистым, агент совершает гораздо меньше ошибок. Итак, подумайте об этом так. Традиционный подход MCP похож на то, как вас заставляют носить каждый инструмент в вашем ящике с инструментами везде, где вы идете, и читать все руководства пользователя вслух, прежде чем вы сможете использовать хотя бы один инструмент. Теперь, конечно, вы запутаетесь и иногда будете выбирать неправильный инструмент. Это просто произойдет. Итак, выполнение кода похоже на наличие мастерской, где вы можете подойти к нужному разделу, взять именно то, что вам нужно, поработать над своим проектом там, и показать, ну, людям только готовые результаты, так что вы не загромождаете свое рабочее пространство всем сразу, так что вы можете фактически сосредоточиться и сделать работу правильно. Теперь, очень быстро, я просто хотел упомянуть, что если вы хотите узнать больше о внедрении таких продвинутых систем и фактически построить реальный прибыльный бизнес на основе ИИ-автоматизации, присоединяйтесь к нашему школьному сообществу. У нас более 15 000 участников, и они активно делятся тем, что работает прямо сейчас в реальном мире, и мы предоставляем все наши бесплатные ресурсы с ежемесячными конкурсами и многим другим. Ссылка находится ниже в описании. Опять же, это совершенно бесплатно. Хорошо, помимо экономии токенов и улучшения надежности, позвольте мне рассказать вам, почему это на самом деле важно для вашего бизнеса или бизнеса ваших клиентов. Итак, во-первых, экономика того, что вы можете построить, полностью меняется. Итак, я постоянно провожу ознакомительные звонки и аудиты с потенциальными клиентами, и когда я сажусь и фактически рассчитываю, сколько будет стоить запуск автоматизации с использованием традиционного MCP, иногда цифры просто не имеют смысла. Итак, агент службы поддержки клиентов, который обрабатывает 200 заявок в день, и каждая заявка требует извлечения данных из нескольких разных систем. Ну, вы можете столкнуться с расходами на API от 400 до 600 долларов в день только при традиционном подходе. Но с выполнением кода я могу снизить это до 40-60 долларов в день. Теперь внезапно окупаемость инвестиций действительно имеет смысл, и клиент может позволить себе запускать это в масштабе без того, чтобы затраты, ну, выходили из-под контроля. И что еще более важно, система действительно работает надежно, потому что агент не путается из-за загроможденного контекста, связанного с ней. Второе — это то, что вы наконец-то можете создавать вещи, которые раньше были буквально невозможны из-за ограничений стоимости и проблем с надежностью. Итак, вот пример использования, который я хотел создать с помощью одного только MCP в течение нескольких месяцев, но я просто не мог сделать экономику работающей или просто доверять ему, чтобы он хотя бы работал надежно. Теперь это был просто агент для бренда электронной коммерции, который отслеживает уровни запасов в Shopify, Amazon, их сторонней системе складского учета, а также в некотором их бухгалтерском программном обеспечении. А затем он выявлял бы несоответствия между этими системами, а затем отмечал бы любые потенциальные исчерпания запасов до того, как они произойдут, и просто предлагал бы конкретные количества для повторного заказа для каждого SKU. Итак, при традиционном MCP каждый запрос данных из этих систем был очень большим. Итак, сравнение данных из нескольких разных источников, это, очевидно, означает несколько проходов через ваше окно контекста. Теперь стоимость токенов была бы просто совершенно безумной и неустойчивой. И со всеми этими данными, проходящими через контекст, шансы на то, что агент совершит ошибку или что-то галлюцинирует, резко возрастают. Но с выполнением кода агент просто загрузит все в песочницу, а затем напишет скрипт сравнения и выполнит все расчеты там. И он возвращает только что-то вроде SKU123. Его на 47 единиц меньше на Amazon по сравнению с вашей системой 3PL. Вот рекомендуемое действие по повторному заказу. Итак, возможно, 1000 токенов вместо 150 000. И поскольку контекст остается чистым, он гораздо более надежен. Итак, это полностью меняет то, что возможно построить и фактически развернуть в продакшене. Третье — конфиденциальность. Это становится огромным преимуществом вместо причины отказа от сделки. Теперь я лично терял сделки, потому что корпоративные клиенты абсолютно не разрешают своим клиентским данным касаться серверов Enthropic или OpenAI. Итак, компании здравоохранения, финансовые услуги, юридические фирмы — все они имеют строгие требования к соответствию, такие как HIPPA, например. Итак, при выполнении кода конфиденциальные данные никогда на самом деле не попадают к модели. Они просто остаются в среде песочницы. Итак, вы можете даже настроить автоматическую токенизацию, где модель видит что-то вроде customer emil1 вместо фактического адреса электронной почты. Итак, реальные данные просто передаются из системы A в систему B, но ИИ никогда на самом деле не читает конфиденциальные части. Итак, для регулируемых отраслей это просто открывает сделки, к которым вы буквально не могли прикоснуться раньше из-за проблем с соответствием. И четвертое, это, честно говоря, дико: агент может фактически учиться и улучшаться со временем. Итак, поскольку агент работает в файловой системе, он может сохранять полезный код, который он пишет. Итак, скажем, он просто находит действительно умный способ разобрать определенный формат документа. Итак, он может сохранить это как повторно используемую функцию и использовать ее снова позже. Итак, со временем ваш агент создает свою собственную библиотеку решений. Итак, он не начинает с нуля каждый раз. И это очень похоже на то, как работают навыки Claude. Итак, агент буквально развивает свои собственные возможности. Теперь, прежде чем мы перейдем к практическим последствиям, я просто хотел упомянуть, что если вы владелец бизнеса, который ищет помощь во внедрении этого или просто хотите трансформировать свой бизнес с помощью ИИ, чтобы в конечном итоге увеличить свою прибыль и сэкономить часы работы вашей команды каждую неделю, а также расти и получить преимущество над конкурентами, то вы можете нажать на ссылку в описании, чтобы запланировать звонок с нашей командой, чтобы просто узнать больше. Совершенно бесплатно. Мы работали с более чем 30 различными компаниями, либо обеспечивая значительный рычаг, либо просто увеличивая их прибыль и позволяя им эффективно масштабироваться. Итак, если вы хоть немного заинтересованы в росте своей компании, то опять же, ссылка находится ниже в описании. Но в любом случае, давайте вернемся к делу. Итак, давайте будем очень практичными и поговорим о том, что это означает для разных типов бизнеса и сценариев использования. Итак, если вы управляете агентством или занимаетесь консалтингом, вся ваша модель ценообразования стала намного гибче. Итак, я колебался предлагать определенные проекты автоматизации клиентам просто потому, что, когда я просчитывал цифры, затраты на токены делали ROI действительно сомнительным. И, честно говоря, я не был уверен, что система будет достаточно надежной для любого продакшн-использования с любыми традиционными методами MCP. Итак, если клиенту нужен агент, который обрабатывает 500 документов в день. Итак, с традиционным MCP, я имею в виду, вы просто сталкиваетесь с огромными текущими счетами за API, которые съедают маржу всех, плюс риск того, что агент совершит ошибки из-за перегрузки контекста. Итак, выполнение кода фундаментально меняет этот расчет. Теперь я могу уверенно обещать гораздо более амбициозные проекты автоматизации, просто потому, что я знаю, что затраты будут масштабироваться разумным образом, и система действительно будет работать надежно, и это меняет то, что вы можете фактически продавать своим клиентам и как вы устанавливаете цены на свои услуги. Хорошо. Теперь позвольте мне быть совершенно честным относительно недостатков, потому что они определенно существуют, и вам нужно знать о них. Итак, во-первых, в некоторых отношениях это гораздо менее надежно. Итак, традиционный вызов инструментов MCP является жестким, но очень предсказуемым. Итак, агент вызывает конкретную функцию с конкретными параметрами. Итак, либо он работает, либо он просто выдает ошибку. Довольно простое выполнение кода. Это просто означает, что агент должен писать синтаксически правильный код каждый раз, когда ему нужно что-то сделать. Итак, это открывает двери для синтаксических ошибок или логических ошибок, крайних случаев, которые агент просто не учел. Итак, я лично видел, как агенты писали код, который работает идеально 19 раз подряд, а затем просто полностью терпит неудачу при 20-й попытке, потому что данные вернулись в немного другом формате, чем ожидалось. Итак, вам нужна гораздо лучшая система тестирования, обработки ошибок и мониторинга. Это также не так надежно, как может быть простое вызов инструментов. Итак, второе — накладные расходы на инфраструктуру. Это очень реально. Итак, вы абсолютно не можете просто развернуть это в простой бессерверной функции и считать, что это сделано, потому что вам нужна надлежащая средом песочницы, которая безопасна, изолирована от ваших других систем и имеет строгие ограничения на то, что код может фактически делать и какие ресурсы он может потреблять, и это реальная работа DevOps. Итак, для простого чат-бота, который делает одну или две разные вещи, такой уровень инфраструктуры — это просто полный перебор. Но для продакшн-систем, которые обрабатывают реальные бизнес-процессы с реальными последствиями, это практически необходимо. Итак, это просто не тривиально настроить и поддерживать. Итак, когда следует использовать каждый подход? Ну, позвольте мне дать вам мою структуру для размышлений об этом. Итак, традиционный MCP по-прежнему имеет полный смысл для любых простых сценариев использования, которые требуют только одного, двух или, возможно, трех вызовов инструментов. Вы знаете, где это низкообъемные операции, где затраты на токены на самом деле не имеют значения в общей картине. Итак, быстрые прототипы и MVP, где вам нужно двигаться быстро и доказать концепцию в ситуациях, где абсолютная надежность важнее оптимизации затрат. Итак, именно там традиционный подход будет лучшим выбором. Теперь выполнение кода. Это имеет гораздо больше смысла для любых сложных рабочих процессов, которые включают в себя тяжелую обработку или преобразование данных или высокообъемные операции, где затраты могут быстро накапливаться и действительно иметь значение для корпоративных клиентов, у которых есть строгие требования к конфиденциальности и соответствию, или просто рабочие процессы, которые постоянно достигают пределов окна контекста при традиционном подходе. Итак, это просто ситуации, когда вам нужен агент для обработки любых грязных, непредсказуемых данных, которые не всегда поступают в одном и том же формате, а также продакшн-системы, где вам нужен агент, чтобы фактически быть надежным и не галлюцинировать или совершать ошибки из-за перегрузки контекста. Итак, вот мое личное эмпирическое правило, которое я использую при оценке всех своих проектов. Если вы можете фактически построить все это с помощью менее чем 10 вызовов инструментов, и передаваемые данные относительно невелики, просто придерживайтесь традиционного MCP. Держите это просто. Но если вы связываете сложные операции или просто обрабатываете большие объемы данных, или если вам нужно, чтобы он был надежным в продакшене, выполнение кода абсолютно стоит первоначальных инвестиций в инфраструктуру и время настройки. Итак, сказав это, если вы создаете ИИ-решения для своих клиентов или для своего бизнеса, просто понимание этого прямо сейчас уже дает вам огромное преимущество перед конкурентами. Итак, те сложные рабочие процессы, от которых отказываются другие агентства просто потому, что они не могут сделать экономику работающей или не верят в нее или не гарантируют надежность, вы можете создавать их прибыльно сейчас. Или те корпоративные сделки, которые постоянно срываются из-за проблем с конфиденциальностью и соответствием. Ну, вы можете закрыть эти сделки. Но вот на чем я действительно хочу, чтобы вы сосредоточились: просто перестаньте зацикливаться на том, какой инструмент или платформа лучше. Выполнение кода — это просто один подход. Традиционный MCP — это другой. Итак, настоящий вопрос никогда не в том, что лучше в абстракции. Вопрос в том, что на самом деле решает конкретную проблему вашего клиента наиболее эффективно, учитывая его ограничения и требования. Итак, это просто мышление, которое отличает людей, которые зарабатывают реальные деньги, от людей, которые просто собирают инструменты. Итак, с учетом сказанного, продолжайте и исследуйте сами. Дайте мне знать, что вы думаете ниже в комментариях. Прочтите статью. Я разместил ее ниже в описании. Но опять же, если вы владелец бизнеса, который хочет внедрить подобные вещи для своего бизнеса или ищет любые другие ИИ-решения для внедрения, чтобы в конечном итоге сэкономить время и увеличить свою прибыль, то перейдите по ссылке ниже в описании. Вы можете записаться на звонок с моей командой. И с учетом сказанного, спасибо, что посмотрели. и увидимся в следующем видео.