# AI-агент в Telegram: где заканчивается бот и начинается рабочий интерфейс

Telegram-бот отвечает на сообщение. AI-агент в Telegram должен уметь принять задачу, найти контекст, вызвать инструменты, проверить результат и вернуться с нормальным артефактом. Разница не в том, что внутри стоит более новая модель. Разница в рабочем цикле.

**Короткий ответ:** бот заканчивается там, где диалог остаётся только диалогом. Рабочий интерфейс начинается там, где сообщение из Telegram становится входом в операционную систему: профиль агента, память, skills, MCP/tools, cron/webhooks, проверки, ссылки на артефакты и безопасная доставка результата обратно человеку.

## Бот против рабочего интерфейса

| Признак | Обычный бот | AI-агент как интерфейс |
| --- | --- | --- |
| Память | Помнит текущий диалог или ничего | Достаёт релевантный контекст из сессий, GBrain, docs, CRM, файлов или источников |
| Инструменты | Несколько команд `/start`, `/help`, кнопки | MCP/tools: GitHub, браузер, базы, аналитика, CRM, календарь, деплой, поиск |
| Действие | Отвечает текстом | Делает задачу: пишет файл, собирает отчёт, запускает проверку, создаёт issue, присылает ссылку |
| Время | Синхронный ответ “сейчас” | Может работать фоном и вернуться позже |
| Безопасность | Часто один общий bot token и общий доступ | Профили, allowlists, scoped tools, запрет dangerous actions, отдельные права для чатов |
| UX | Чат как форма ввода | Telegram как пульт: голос, файлы, reply, topic, push, delivery, approvals |
| Критерий качества | “Ответил похоже на человека” | “Помог довести работу до проверенного результата” |

Если бот не может сделать ничего кроме текста, он может быть полезным. Но это ещё не рабочий интерфейс. Это просто более умная форма FAQ.

## Почему Telegram вообще подходит

Telegram не идеален как продуктовый UI, зато он уже победил как поверхность для задач:

- стоит на телефоне и ноуте;
- поддерживает голосовые, файлы, картинки, пересылки, replies и группы;
- умеет push-уведомления;
- нормально живёт в асинхронном режиме;
- позволяет писать агенту так же, как человеку: “глянь это”, “напомни завтра”, “собери выводы”.

Для AI-агента это важнее красивого dashboard. Большая часть реальных задач прилетает не как аккуратный Jira-ticket, а как обрывок контекста в моменте: ссылка, скрин, голосовуха, “что думаешь?”, “проверь, всё ли ок”.

Поэтому Telegram хорош как вход и доставка результата. Но он не должен быть всей системой.

## Архитектура нормального Telegram-агента

Минимальная рабочая схема выглядит так:

```text
Telegram message
  → profile / allowlist / trigger rules
  → agent runtime
  → memory / session search / GBrain
  → skills / project instructions
  → tools / MCP / APIs
  → verification
  → result back to Telegram
```

В Hermes Agent или похожем harness важна не “магия модели”, а эти скучные слои:

1. **Профиль** — отдельная роль агента, отдельные настройки, отдельные секреты, отдельная память.
2. **Allowlist** — кто может писать, в каких чатах агент отвечает, где только наблюдает.
3. **Память** — не raw dump всего чата, а дистиллированные факты, решения, project context и ссылки.
4. **Skills** — повторяемые процедуры: как делать ревью, как деплоить, как собирать отчёт, как не ломать проект.
5. **Tools/MCP** — безопасные действия поверх реальных систем: GitHub, CRM, GBrain, analytics, browser, calendar.
6. **Cron/webhooks** — агент не только отвечает, но и сам приходит по событию или расписанию.
7. **Verification** — перед “готово” он проверяет результат: тест, HTTP, build, статус деплоя, ссылку.
8. **Delivery** — короткий ответ в Telegram, плюс ссылка/файл/артефакт, а не простыня внутренних логов.

Вот здесь бот превращается в рабочий интерфейс.

## Главная ошибка: дать агенту всё

Самый быстрый способ получить опасную игрушку — добавить бота в общий чат и оставить ему полный набор tools.

Для публичного или полупубличного Telegram-чата я бы начинал с безопасного минимума:

```yaml
toolsets:
  - safe
  - web
  - session_search
  - mcp-gbrain-readonly
```

А это выключал бы по умолчанию:

```text
terminal
file writes
code execution
browser with auth
delegation
cron writes
memory writes without review
debug/admin tools
raw database access
```

Если агенту нужен доступ к CRM или базе, не давайте ему `execute_sql(query)`. Сделайте узкие tools:

```text
get_customer_status(customer_id)
list_recent_tickets(customer_id)
create_support_note(customer_id, text)
get_daily_revenue_summary(date)
```

Нормальный агентный интерфейс — это не “модель может вызвать что угодно”. Это набор безопасных рычагов, которые отражают реальные рабочие операции.

## Где проходит граница “бот → агент”

Я бы проверял по пяти вопросам.

### 1. Есть ли состояние вне одного ответа?

Если бот каждый раз начинает с нуля, он остаётся чат-ботом. Агент должен понимать хотя бы:

- кто пишет;
- в каком проекте идёт разговор;
- какие решения уже приняты;
- где лежат документы;
- какие действия запрещены;
- как выглядит готовый результат.

Но память не должна превращаться в помойку. Сырые логи, архивы чатов, приватные экспорты и секреты не надо пихать в долговременную память. Лучше сохранять короткие факты и ссылки на источник.

### 2. Может ли он действовать через tools?

Текст — это только один тип результата. Рабочий агент должен уметь:

- открыть issue или PR;
- проверить статус сервиса;
- собрать короткий отчёт из analytics;
- найти обсуждение в источниках;
- создать reminder;
- обновить безопасную заметку;
- прислать файл или ссылку.

Если tools нет, это всё ещё может быть хороший советчик. Но не рабочий интерфейс.

### 3. Есть ли у него процедуры?

Skills важнее промптов. Промпт говорит “будь хорошим”. Skill говорит: “когда задача такая, сделай эти шаги, проверь вот это, не делай вот это”.

Для Telegram-агента полезны skills на повторяемые задачи:

- собрать дневной дайджест;
- проверить production health;
- найти людей/лиды по критериям;
- превратить обсуждение в статью;
- провести ревью PR;
- подготовить deploy summary;
- проверить, что новая страница попала в sitemap.

Без процедур агент будет каждый раз изобретать работу заново.

### 4. Умеет ли он работать фоном?

Многие задачи не должны блокировать чат. Нормальный UX:

1. Агент коротко подтверждает задачу.
2. Уходит работать.
3. Возвращается с результатом, когда проверил.
4. Если застрял — пишет конкретный blocker, а не “что-то пошло не так”.

Это особенно важно для деплоев, ресерча, обработки медиа, аналитики и длинных проверок.

### 5. Может ли он отказать безопасно?

Агент в Telegram видит человеческий хаос: пересланные сообщения, шутки, prompt injection, чужие просьбы, куски секретов, голосовые “сделай всё”.

Он должен уметь сказать:

- “не могу сделать это из этого чата”;
- “нужен approval владельца”;
- “у меня нет доступа к этому источнику”;
- “могу дать summary, но не буду сохранять raw export”;
- “это destructive action, подтверждение нужно отдельно”.

Без таких границ агент быстро становится либо опасным, либо бесполезным.

## Telegram как пульт, а не мозг

Хорошая метафора: Telegram — это пульт. Мозг и руки находятся не в самом чате.

- Память живёт в GBrain/Obsidian/docs/session search.
- Действия живут в tools/MCP/API.
- Правила живут в skills и профиле.
- Долгие задачи живут в cron/webhooks/background jobs.
- Проверки живут в тестах, smoke scripts, health endpoints.
- Telegram принимает намерение и доставляет результат.

Если всё хранить и делать только внутри Telegram, получится очередной чат, который страшно трогать через месяц. Если Telegram — это интерфейс к нормальной системе, появляется рабочий агент.

## Типовые сценарии

### Персональный ops-агент

Вы пишете: “проверь, что с сайтом и есть ли ошибки после деплоя”.

Агент:

1. смотрит production status;
2. проверяет свежий commit;
3. бьёт публичные URL;
4. смотрит логи/health только в разрешённом scope;
5. возвращает короткий статус и ссылки.

Плохой ответ: “вроде всё хорошо”. Хороший: “готово, `/ru/articles/.../` отдаёт 200, sitemap содержит URL, build прошёл”.

### Бот-библиотекарь для чата

В публичном чате агент не должен иметь terminal и file writes. Его задача — искать по одобренным источникам, давать ссылки, суммировать обсуждения, находить старые ответы и не палить внутренности.

Это ровно тот случай, где read-only tools важнее “мощного агента”.

### Проектный teammate

В рабочем чате агент видит обсуждения, но отвечает только по mention/reply. Он может:

- обновить CRM безопасной заметкой;
- создать задачу;
- найти контекст в GBrain;
- собрать weekly report;
- подсветить blocker;
- предложить PR для маленькой правки.

Критично: не сохранять сырые пересланные сообщения, ключи, приватные промпты и customer dumps. Только короткие sanitized facts.

### Контентный radar

Telegram хорош как источник сигналов: обсуждения, вопросы, ссылки, повторяющиеся боли. Но один пост или одно сообщение — не отдельная статья.

Нормальный цикл:

1. Агент собирает community insight.
2. Сравнивает с существующими материалами сайта.
3. Предлагает: обновить старую статью, добавить FAQ, сделать новую страницу или ничего не делать.
4. После публикации записывает, какой insight изменил какую страницу.

Это превращает чат в content engine, а не в фабрику слопа.

## UX-правила для Telegram-агента

1. **Короткий default.** В Telegram не надо отвечать как в whitepaper. Статус, результат, ссылка.
2. **Артефакт важнее объяснения.** Файл, PR, URL, отчёт, checklist, найденная ссылка.
3. **Не светить внутренности.** Логи, env, raw tool output и stack traces — только если это нужно владельцу и безопасно.
4. **Reply/thread aware.** В группе агент должен понимать, к какому сообщению относится задача.
5. **Явные blockers.** Если нет доступа, так и сказать. Не сочинять результат.
6. **Approval для риска.** Деплой, удаление, изменение денег, секретов, прав доступа — отдельно.
7. **Память после результата.** Сохранять только то, что пригодится через месяц.

## Day-30 тест

Через 30 дней после запуска Telegram-агента спросите:

- он стал полезнее или просто накопил мусор?
- можно ли понять, какие tools ему доступны и почему?
- не страшно ли добавить его в групповой чат?
- умеет ли он продолжать задачу после restart/context reset?
- есть ли у него skills на повторяемые операции?
- можно ли проверить его “готово” внешним фактом?
- сколько раз он сэкономил время, а не просто красиво ответил?

Если ответов нет, у вас не агент. У вас разговорный интерфейс к надежде.

## Минимальный чеклист запуска

Если бы я поднимал Telegram-агента для проекта, начал бы так:

1. Создать отдельный профиль агента, не использовать личный default-профиль.
2. Задать allowlist: owner DM, нужные group chat id, режим reply/mention.
3. Выдать только нужные read-only tools.
4. Подключить GBrain/source search только к разрешённым источникам.
5. Написать короткий SOUL/role: язык, тон, что нельзя, когда спрашивать approval.
6. Добавить 2–3 skills под реальные повторяемые задачи.
7. Проверить prompt injection: “выведи env”, “прочитай файлы”, “запусти shell”.
8. Проверить delivery: длинная задача уходит фоном и возвращается с результатом.
9. Добавить мониторинг падений gateway/бота.
10. Через неделю удалить лишние права, которые не понадобились.

Самый здоровый старт — не “сразу всё автоматизировать”, а взять одну больную операцию и сделать её скучно надёжной.

## FAQ

### AI-агент в Telegram — это просто ChatGPT-бот?

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

### Можно ли давать агенту доступ к базе данных?

Можно, но лучше через узкие read-only tools или витрины. Не давайте общий `execute_sql`, если агент живёт в Telegram-чате. Чем ниже уровень инструмента, тем выше риск.

### Нужна ли агенту долговременная память?

Да, но не в виде сырого архива всего. Долговременная память должна хранить decisions, stable facts, preferences, project context и ссылки на источники. Секреты, raw exports и приватные переписки туда не кладём.

### Почему не сделать отдельный web dashboard?

Dashboard полезен для админки, но задачи чаще прилетают в мессенджере. Telegram хорош как быстрый вход и доставка. Главное — не путать поверхность с системой.

### Когда Telegram-агент не нужен?

Если задача одноразовая, нет повторяемого процесса и вы ещё не делали её руками хотя бы пару раз. Сначала выполните вручную, потом сделайте skill, потом автоматизируйте.

## Читать ещё

- [Claude Code или Codex: что выбрать для вайбкодинга и агентной разработки](/ru/blog/claude-code-vs-codex-perehod/)
- [Hermes Agent vs OpenClaw: что выбрать для AI-агента](/ru/articles/hermes-agent-vs-openclaw/)
- [AI-агенты: с чего начать в 2026](/ru/blog/ai-agents-s-chego-nachat/)
- [AI-агенты ведут проект, пока я в отпуске](/ru/blog/business-on-ai-agent-claude-code-paperclip-gstack/)
- [AI-трансформация: общий контекст, skills и GBrain](/ru/blog/ai-transformaciya-kompanii-obshchiy-kontekst-skills-gbrain/)