Vanar Chain × Fetch.ai (ASI:One): интеграция myNeutron с агентной платформой ASI для координации децентрализованных ИИ-агентов
11-11-2025, 18:00
Авторизуйтесь или зарегистрируйтесь, чтобы оценивать материалы, создавать записи и писать комментарии.
Авторизоваться© 2026 24k.ru. Все материалы носят исключительно информационный характер и не являются индивидуальной инвестиционной рекомендацией (ФЗ-39 «О рынке ценных бумаг»). Криптовалюты не являются законным средством платежа в РФ (ФЗ-259). Используя сайт, вы соглашаетесь с нашей Политикой конфиденциальности и использованием cookie.
Агентные сервисы — это следующий шаг после «обычных» AI-ботов. Они не просто отвечают на вопросы, а сами инициируют действия: проверяют данные в блокчейне, формируют транзакции, запускают сценарии в смарт-контрактах. Экосистема Fetch.ai как раз про это: сеть автономных агентов, собственный блокчейн и инструменты для сборки сервисов поверх Web3.
В этом практическом руководстве по Fetch.ai мы разберем пошаговую сборку AI-агента с полноценной RAG-архитектурой и интеграцией ончейн-действий в блокчейн. Гайд подойдет как для знакомства с агентивными системами Web3, так и для создания продакшн-решений.
Fetch.ai задумывался как платформа для децентрализованной цифровой экономики на базе AI-агентов. Агент здесь — это программа, которая действует от имени пользователя или сервиса: общается с другими агентами, запрашивает данные, заключает сделки и взаимодействует со смарт-контрактами.
У проекта есть собственный блокчейн (Fetch Ledger), реестр агентов (Almanac), система имён Fetch Name Service и инфраструктура для регистрации, поиска и вызова агентов. Подробно о сети и токене FET мы уже писали в материале «Fetch.ai: сеть AI-агентов и токен FET» — здесь сосредоточимся на практической стороне.
Если упростить, стек Fetch.ai для сборки агентного сервиса выглядит так:
Всё это дополняется оркестрационным уровнем, описанным в архитектуре Fetch.ai: там агенты объединяются в сложные многокомпонентные сценарии и взаимодействуют друг с другом через общий протокол.
Чтобы не оставаться в теории, зафиксируем конкретный use case. Мы хотим собрать агентного помощника для Web3-проекта, который умеет:
Такие «agentic RAG»-системы активно обсуждаются на рынке: это не просто чатбот, а агент, который сам решает, когда доставать контекст, какие документы читать и когда переходить к действию.
Разобьём будущий сервис на четыре слоя, чтобы не запутаться:
В качестве LLM для RAG можно использовать не только внешние API, но и локальные модели. Если вы хотите тестировать всё в «песочнице», удобно взять локальный LLM-стек через Ollama и поднять модель прямо на dev-станции, чтобы не зависеть от внешних лимитов.
Fetch.ai активно продвигает Python-стек, так что минимальные требования выглядят довольно привычно:
pip или poetry;uagents и CLI-утилиты Agentverse (если планируете деплой в облако).Типичный стартовый набор команд (упрощённо):
python -m venv .venv source .venv/bin/activate # Windows: .venv\Scripts\activate pip install uagents
Разработчикам, уже знакомым с агентными фреймворками вроде LangChain, LangGraph и др., будет полезно освежить базовые принципы в нашем обзоре «агентных конструкторов» — мы как раз сравнивали подходы Fetch.ai с другими игроками.
RAG (retrieval-augmented generation) — это архитектура, в которой LLM не отвечает «из головы», а сначала ищет информацию в вашем хранилище знаний, а затем уже генерирует ответ с опорой на найденные документы. Для агентных сценариев RAG стал де-факто стандартом: иначе агент быстро начинает «галлюцинировать».
На первом шаге нужно собрать и привести к единому формату всё, на чём будет «думать» агент:
Дальше вы нормализуете текст: чистите от навигации, делите на фрагменты (chunks) по 500–1000 токенов и сохраняете вместе с метаданными (название документа, раздел, версия). Многие библиотеки для RAG делают это «из коробки», так что на этом этапе достаточно следовать их best practices.
Для RAG-агента на Fetch.ai нет принципиальной разницы, где физически лежит векторное хранилище: оно может жить рядом с агентом (локальный контейнер), в отдельном микросервисе или в управляемом облаке. Важно лишь обеспечить API для:
С точки зрения бюджета RAG — одно из самых «прожорливых» мест: и эмбеддинги, и сами ответы модели стоят денег или ресурсов. Важно сразу заложить лимиты по длине контекста и количеству документов, которые вы подтягиваете на один запрос.
Хорошая практика — вынести собственно RAG в отдельную функцию/сервис, который можно использовать и без агента. Это упрощает тестирование и даёт возможность подключать другие интерфейсы (чат-виджет на сайте, API для партнёров и т.д.). Примерно это выглядит так:
В идеале вы добавляете поверх этого ещё и валидацию: если модель слишком неуверенна (низкий score или нет релевантных документов), агент честно сообщает, что не может ответить, вместо того чтобы придумывать детали.
uAgents — это Python-фреймворк Fetch.ai для автономных агентов. Агент представляет собой программу с адресом, криптографическим ключём и набором обработчиков сообщений. Он может сам инициировать диалоги, реагировать на события, запускать фоновые задачи.
В самом простом виде «каркас» агента выглядит как-то так (упрощённый псевдокод):
from uagents import Agent, Context, Bureau, Protocol agent = Agent( name="rag_onchain_agent", seed="<secure-seed>", ) @agent.on_event("startup") async def startup(ctx: Context): ctx.logger.info("Agent is up and running!") @agent.on_message(model=UserQuery) async def handle_user_query(ctx: Context, sender: str, msg: UserQuery): # здесь мы позже вызовем RAG и/или ончейн-адаптер answer = await run_rag_pipeline(msg.question) await ctx.send(sender, AgentReply(text=answer)) bureau = Bureau() bureau.add(agent) bureau.run()
Реальные агенты Fetch.ai используют строгие протоколы сообщений и типизацию (pydantic-модели), что облегчает композицию сложных мульти-агентных сценариев. Но для первого сервиса достаточно уметь принимать запрос, вызывать RAG и отправлять ответ.
Теперь добавим в агента вызов RAG-сервиса. Главное — не тянуть всю логику внутрь обработчика сообщений, а вызывать заранее подготовленную функцию/клиент. Это позволяет:
В типичном сценарии обработчик делает следующее:
На этом этапе ваш агент уже полезен: он умеет отвечать на вопросы по документации и может работать в Agentverse как «FAQ-помощник» для проекта.
Следующий шаг — научить агента работать с блокчейном. Экосистема Fetch.ai сама использует on-chain события и данные: в документации подробно показываются примеры, как агенты реагируют на события в сети и используют внешние данные (через интеграции вроде SQD, Infura и др.).
Нам нужно решить две задачи:
Проще всего вынести подписку на события в отдельный сервис, который будет:
eth_getLogs или gRPC-подписки);Агент в таком случае получает уже «чистое» сообщение: например, PositionRiskIncreased или ThresholdReached. Это удобнее, чем разбираться с сырыми логами внутри него.
Ключевой принцип безопасности: агент не должен бесконтрольно распоряжаться средствами пользователя. На практике удобно разделить роли:
Такой паттерн хорошо стыкуется с другими агентными фреймворками для Web3, где LLM-агент генерирует рекомендации, но финальное действие всё равно остаётся за пользователем или специализированным модулем с жёсткими лимитами.
Когда базовый функционал работает локально, пора думать о проде. Тут в ход идёт Agentverse — облачная платформа Fetch.ai для деплоя и маркетинга агентов. Она позволяет:
Путь в общих чертах такой:
Agentverse постепенно превращается в «маркетплейс агентных сервисов» — логично стремиться, чтобы ваш RAG + ончейн-агент был там не просто запущен, но и хорошо оформлен: с понятным описанием, сценариями, демо-скринами и примерами запросов.
У агентных сервисов два основных источника затрат:
Чтобы бюджет не «улетал» незаметно, стоит сразу заложить:
Удобно завести отдельную панель мониторинга, где будет видно, какие запросы чаще всего приводят к RAG-вызову, какие транзакции инициируются и где происходят ошибки. Это помогает не только экономить, но и улучшать сам продукт: например, вынести популярные ответы в готовые шаблоны или подсказки.
Даже у опытных команд первые попытки собрать агентный сервис редко проходят идеально. Вот несколько типичных ошибок:
Соблазн велик «написать всё в одном файле»: и агента, и RAG, и ончейн-код. В результате сложно масштабировать, тестировать и менять отдельные компоненты. Лучше сразу разделить проект на модули: агент, RAG-сервис, ончейн-адаптер, слой мониторинга.
Если агент напрямую транслирует ответы модели без фильтров и проверок, вы очень быстро столкнётесь с галлюцинациями, некорректными инструкциями и странными рекомендациями. Минимальный набор guardrails: ограничение источников (только ваши документы), проверка уверенности, запрет на определённые типы действий и словарей.
Иногда команда стремится автоматизировать «всё и сразу»: от подписания транзакций до сложных схем управления активами. Это повышает риски и усложняет аудит. На старте агенту лучше отдать роль помощника и «автозаполнителя» транзакций, а финальное подтверждение оставить пользователю или проверенному бекенду.
Даже самый технологичный агент будет восприниматься как «чёрная коробка», если пользователь не понимает, что он делает. Добавьте прозрачность: показывайте, какие документы использованы для ответа, какие шаги агент делает перед ончейн-действием, и давайте пользователю возможность отменить или отредактировать шаблон транзакции.
Сведём ключевые шаги в удобный чек-лист.
Нет. Fetch.ai уже предоставляет собственный блокчейн и инфраструктуру для регистрации и взаимодействия агентов. Вам не нужно разворачивать свой L1 — достаточно использовать существующую сеть и API. Если же ваш продукт живёт на другом блокчейне (например, EVM-совместимом), агент Fetch.ai может взаимодействовать с ним через ончейн-адаптер и indexer-сервисы.
Да. Вы можете использовать локальные модели (например, через Ollama или другие open-source-решения) и держать всё вычисление в своём контуре. Важно лишь обеспечить стабильный API, который агент сможет вызывать так же, как он вызывал бы внешнее облако. При росте нагрузки локальное решение можно комбинировать с облачными моделями.
Обычно это делается через отдельный сервис или библиотеку, подключённую к RPC нужной сети или к специализированным индексерам (SQD, The Graph и т.п.). Такой сервис отслеживает события и вызывает агента при наступлении условий. Сам агент видит уже «чистые» сообщения вроде «баланс изменился» или «порог достигнут» и решает, что делать дальше.
Технически — да, если передать агенту кошелёк с правами подписи. Но с точки зрения управления рисками лучше сначала ограничиться полуавтоматическим режимом: агент формирует и предлагает транзакции, а пользователь или бекенд с жёсткими лимитами подтверждает их. Это снижает вероятность злоупотреблений и ошибок.
Если команда только входит в стек Fetch.ai и агентные архитектуры, разумно начать с чистого RAG-помощника: это даст время обкатать работу с документацией, guardrails и UX. Как только ответы станут стабильными и понятными пользователям, можно постепенно добавлять ончейн-действия — сначала простые (формирование транзакций), затем более сложные сценарии.
Материал носит исключительно информационный характер и не является индивидуальной инвестиционной рекомендацией (ФЗ-39). Криптовалюты не являются законным средством платежа в РФ (ФЗ-259).
11-11-2025, 18:00
16-11-2025, 17:22
22-10-2025, 20:57
16-11-2025, 15:49
2-11-2025, 09:05
Анна Коваль
Комментариев нет