# iii: сервисы, агенты и логи в одном живом каталоге

- Site: VeraPoint News
- Section: Инструменты
- Date: 2026-05-28
- Canonical: https://verapointmedia.com/tools/iii-hq-iii/
- Markdown: https://verapointmedia.com/tools/iii-hq-iii.md
- Summary: iii обещает собрать backend, агенты и наблюдаемость в один runtime. Разбираю, как он устроен, как стартовать и где тут реальная польза.
- SEO title: iii: браузерная отладка и проверка сайтов AI-агентом
- SEO description: iii обещает собрать backend, агенты и наблюдаемость в один runtime. Разбираю, как он устроен, как стартовать и где тут реальная польза
- Target queries: iii; iii github; что такое iii; как использовать iii
- Tags: #rust #agents #backend #devtools #observability #framework
- Image: https://verapointmedia.com/static/content-assets/tools/iii-hq-iii/cover.webp

## Sources

- https://github.com/iii-hq/iii
- https://iii.dev
- https://assets.motia.dev/videos/mp4/site/v1/iii-intro.mp4
- https://workers.iii.dev/

---

iii — что это такое: https://github.com/iii-hq/iii

Вот тут у меня сразу два чувства одновременно: «ого, это правда удобно» и «подождите, а это вообще не слишком красиво для реального мира?».

iii обещает странную, но заманчивую вещь: не собирать backend по кусочкам из очереди, cron, HTTP, наблюдаемости и агентов, а описать всё как один живой каталог возможностей. Один проект, одна поверхность, и каждый новый сервис не просто запускается, а сразу становится видимым и вызываемым.

## Если просто

Если совсем по-человечески: iii хочет быть “операционной системой” для backend-команды. Не в рекламном смысле, а буквально как слой, где живут ваши сервисы, задачи и триггеры.

В README это называют тремя примитивами: worker, function, trigger. Я погуглила/проверила — это значит:
worker — это любой процесс или сервис;
function — конкретная операция внутри него;
trigger — то, что её запускает: HTTP-запрос, cron, очередь, изменение состояния, событие потока.

Звучит бодро. Даже слишком бодро. Но идея ясная: если у вас есть сервис, агент или пайплайн, iii хочет сделать его не отдельной «интеграцией», а частью общей системы, которую можно находить, вызывать и трассировать.

И вот тут у меня кивок. Потому что боль знакомая: сегодня у тебя очередь отдельно, логирование отдельно, агенты отдельно, а потом кто-то в команде говорит «давайте ещё и sandbox добавим», и начинается маленький корпоративный сериал на три спринта.

## Что это решает

iii закрывает очень конкретную боль: когда backend разрастается, каждая новая способность тянет за собой свой способ подключения. Для очереди — один SDK, для агента — другой harness, для наблюдаемости — третий, для cron — четвёртый. И всё это надо ещё связать, чтобы оно не развалилось.

Здесь авторы говорят: не надо плодить отдельные пути. Добавляешь worker — и он сразу попадает в live catalog. Остальные компоненты могут его увидеть и вызвать. То есть система становится не набором разрозненных сервисов, а чем-то вроде общего рынка функций. Красиво? Да. Практично? Иногда — очень.

Мне особенно понятно, зачем это может быть нужно командам, которые уже живут в смеси TypeScript, Python и Rust. README прямо говорит: TypeScript-сервис, Python data pipeline, Rust microservice — всё это может быть worker. То есть iii пытается не спорить с языками, а собрать их в один способ работы. Вот это, честно, уже не маркетинговый туман, а вполне рабочая мысль.

Но есть нюанс: чем сильнее обещание «всё в одном», тем внимательнее надо смотреть, не спрятали ли под красивой абстракцией кучу сложной инженерии.

## Как попробовать

Тут README довольно честный и не мучает нас философией до бесконечности.

Минимальный старт такой:

```bash
iii project init myapp
cd myapp
iii
```

То есть сначала создаёшь проект, потом заходишь в папку, потом запускаешь engine — это, по сути, сам runtime. Если нужен совсем короткий путь, в README есть quickstart на сайте iii.dev, а ещё отдельно упоминаются SDK для Node.js, Python и Rust.

Если хотите быстро пощупать логику системы, самый простой ход — добавить worker:

```bash
iii worker add queue
iii worker add agent
iii worker add sandbox
iii worker add <anything>
```

И вот тут я прям вижу, как это проверять руками: поднять тестовый проект, добавить worker, открыть каталог workers и понять, действительно ли новый кусок системы становится видимым сразу. Если да — это уже не абстрактный фреймворк, а довольно ощутимый orchestration layer. По-простому: слой, который управляет связями между частями приложения.

Ещё полезная штука — console. В репо есть iii-console для инспекции workers, functions, triggers, queues, traces, logs и real-time state. То есть наблюдать за системой можно не только через логи в терминале, а через отдельную панель. И это, если честно, уже звучит как инструмент для живых людей, а не только для тех, кто любит страдать в CI.

## 3 сценария с примерами

**1. Нужен HTTP-сервис, который ещё и пишет в очередь.**
Задача: у вас API принимает заказ, потом надо отправить событие в обработку.
Как применить: делаете API worker, добавляете queue worker, описываете trigger на HTTP и функцию `orders::validate`.
Что получится: API и очередь живут в одном каталоге, а не связаны вручную через три слоя glue-кода.

**2. Агент должен сам добирать недостающие возможности.**
Задача: AI-агенту иногда нужен sandbox или отдельный инструмент для проверки.
Как применить: агент через iii видит, каких workers не хватает, добавляет нужный worker и вызывает его функции.
Что получится: агент не «воображает» доступы, а работает с реально зарегистрированными возможностями системы.

**3. Команда хочет видеть, что происходит с сервисами в реальном времени.**
Задача: прод смотрит на поломки, а разработчики — на трассировку и состояние.
Как применить: запускаете console и смотрите workers, triggers, traces, logs и live state.
Что получится: меньше шаманства с разрозненными инструментами, больше понимания, что именно сейчас происходит.

## Где можно застрять

Вот тут начинается самая важная часть, и я бы её не прятала.

Во-первых, лицензия не совсем простая. Engine под Elastic License 2.0, а SDK, console, docs и сайт — под Apache 2.0. Для кого-то это вообще не проблема, а для кого-то — стоп-сигнал. И правильно, между прочим: лицензия — это не украшение, а часть архитектуры.

Во-вторых, проект довольно амбициозный. Когда инструмент обещает «compose, extend, observe every service in your stack in real time», у меня автоматически включается внутренний голос: «ну-ну, покажите, как это живёт под нагрузкой и в грязном проде». Потому что в README всё выглядит стройно, а в реальности обычно всплывают нюансы интеграции, миграций, прав доступа и деплоя.

В-третьих, судя по структуре монорепо, это уже не игрушка на вечер. Тут есть engine, SDK, console, skills, docs, website. То есть это целая экосистема, а не маленький пакетик. Новичку будет тяжеловато, если он просто хочет «быстро добавить агента». Тут надо быть готовым вникать.

## Кому это нужно

iii выглядит полезным для платформенных команд, для backend-инженеров, которые устали собирать интеграции по частям, и для тех, кто уже живёт в агентных сценариях не как в демо, а как в рабочем процессе.

Особенно хорошо он может лечь туда, где есть смесь сервисов на разных языках, нужна наблюдаемость, и при этом хочется единый способ описывать, что вообще умеет система. Если у вас команда любит «один стандарт вместо пяти обвязок», то тут может быть прямо ваше.

Ещё это интересно тем, кто строит AI-обвязку вокруг реальных сервисов, а не игрушечный чатик. Потому что iii явно пытается связать агентов и backend в один механизм, а не держать их по разные стороны стеклянной стены.

## Кому это не нужно

Если у вас маленький проект, один API и одна очередь, iii, скорее всего, будет избыточным. И давайте честно: иногда проще и дешевле не строить «единую поверхность», а аккуратно использовать привычные инструменты.

Не вижу iii и там, где команда не готова тратить время на инфраструктуру и освоение нового mental model. Если людям нужен просто фреймворк для одного сервиса — это, пожалуй, слишком жирно.

И ещё: если вас сразу напрягают лицензии, монорепы и платформенные абстракции, лучше не романтизировать этот стек. Он явно не про «поставил и забыл».

## Вердикт Веры

iii мне кажется очень интересной попыткой собрать backend, агентов и наблюдаемость в один рабочий язык. Не «волшебную платформу», а именно язык, где worker, function и trigger становятся базовыми словами.

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

Так что мой вердикт такой: если вам нужен не очередной SDK, а слой, который может склеить сервисы в живую систему, iii стоит попробовать. Но если вы увидите в README фразу про “effortlessly” и сразу захотите поверить на слово — ну, это как минимум слишком удобно звучит.

## Что читать дальше

- [Все материалы про AI-агентов](/topics/ai-agents/)
- [Что такое AI-агент простыми словами](https://verapointmedia.com/guides/chto-takoe-ai-agent-prostymi-slovami/)
- [Все материалы про AI-инструменты](/topics/ai-tools/)
- [Как отличить рабочий AI-инструмент от красивой демки](https://verapointmedia.com/guides/kak-otlichit-rabochiy-ai-instrument-ot-krasivoy-demki/)

## Материалы

- [iii-hq/iii] iii-hq/iii: https://github.com/iii-hq/iii
- [iii.dev] supporting context: https://iii.dev
- [assets.motia.dev] supporting context: https://assets.motia.dev/videos/mp4/site/v1/iii-intro.mp4
- [workers.iii.dev] supporting context: https://workers.iii.dev/