LLM

Обычно я стараюсь подходить ко всяким новым блестящим штучкам с определенной долей скептицизма. Именно таким, до недавнего времени, было мое отношение к мультиагентным системам. Я бы сказал, что это неудивительно, так как вокруг них сейчас очень много шума, а по-настоящему успешных примеров такого подхода я не видел. Большинство реализаций, которые действительно работали, относились к одному из следующих видов: Агентные системы, действующие по определенному плану. То есть LLM с инструментами, натасканные на автоматизацию вполне конкретного процесса. Благодаря этому, каждый шаг можно тестировать по отдельности и верифицировать его результаты. Описываются такие системы, как правило, в виде направленного ациклического графа (DAG), иногда динамического, и разрабатываются с помощью уже стандартных примитивов из фреймворков типа LangChain и Griptape1. Так функционировала ранняя реализация Gemini Deep Research, в которой сначала составлялся план поиска, затем выполнялся сам поиск, и в конце собирался результат. Решения, работающие в системах с обратной связью. Различные Claude Code, Cursor и прочие агенты, имеющие дело с кодом. Причем чем сильнее обратная связь, читай, чем лучше тулинг и строже проверка типов, тем больше шансов, что они окончательно не испортят вам кодовую базу2. Модели, обученные с помощью Reinforcement Learning, такие как модели с interleaved thinking, вроде OpenAI o3. Это отдельный разговор, и очень интересный, но даже такие модели имеют какой-то modus operandi, определенный особенностями их обучения. При этом мультиагентные системы открытого типа ввиду их общей ненадежности до сих пор существовали в большей части в виде proof of concept. В сообществе не было понимания, где их применять и как именно их реализовывать. Пока не появилась глубокая инженерная статья от Anthropic о том, как они разрабатывали свой Deep Research. В ней был определен достаточно четкий фреймворк для построения таких систем, и именно его мы сегодня и рассмотрим. ...

Model Context Protocol, несмотря на агрессивное его внедрение (а возможно, и благодаря), продолжает развиваться. Недавно Anthropic обновил спецификацию MCP, и ниже мы рассмотрим основные изменения. Усиление безопасности MCP-сервер теперь всегда классифицируется как OAuth Resource Server, а клиенты обязаны реализовывать Resource Indicators (RFC 8707). Нужно это для защиты от атак типа Confused Deputy. Раньше токены, запрашиваемые клиентом у сервера авторизации были “обезличены”, то есть могли использоваться кем угодно. Это дает возможность злоумышленнику создать фишинговый MCP-сервер, обмануть клиента, украсть токен, и с помощью этого токена получить доступ к настоящему MCP-серверу. ...

В прошлом посте я провел разбор базовых концептов AI-фреймворка Griptape, и сейчас самое время применить их к делу. Попробуем их использовать для разработки небольшого приложения, которое помогает вести линк-блог в телеграме. Приложение будет получать URL, скачивать его, прогонять через LLM для генерации сокращенного содержания, переводить это содержимое еще на несколько языков, собирать все вместе и публиковать в телеграме через бота. Общий флоу можно увидеть на схеме ниже: flowchart LR A["URL"] A --> Parser["Парсер"] --> LLM1["Суммаризатор"] LLM1 --> Translator1["Перевод на язык 1"] LLM1 --> Translator2["Перевод на язык 2"] Translator1 --> Combiner["Сборщик"] Translator2 --> Combiner LLM1 --> Combiner Combiner --> Telegram["Телеграм-бот"] Для простоты картины я опущу имплементацию телеграм-бота, а также оставлю в покое мой любимый Human-in-the-loop, который, по моему мнению, обязательно должен присутствовать как минимум где-то в районе сборщика 1. ...