ИИ-помощники и агенты

Актуально для: SimpleTwo 0.9.x · Проверено: 24.09.2026

ИИ в SimpleTwo — это не отдельное приложение рядом с перепиской. Это бот с второй полосой доступа: первая ведёт в переписку, вторая — к модели. Полосы независимы, и это главное свойство конструкции.

1. Провайдер модели

Settings → AI. Поддерживаются два диалекта:

Вид	Кто подходит
anthropic	Anthropic API
openai	всё, что говорит на OpenAI-совместимом API: ITG AIaaS, vLLM, Ollama и подобные

Ключ у тенанта один, и живёт он на хосте службы переписки — координатор кладёт его туда так же, как ключи пушей, и обратно не отдаёт. Карточка в консоли отвечает только на два вопроса: настроен ли доступ и куда он направлен.

Локальная модель — это тот же openai

Если данные не должны покидать контур, поднимите vLLM или Ollama внутри периметра и укажите их адрес. Со стороны SimpleTwo ничего не меняется — меняется только то, куда уходит текст.

Каталог моделей консоль подтягивает через службу переписки, а не просит вписать имя руками. Причина практическая: у некоторых провайдеров возможность модели — часть её имени (opr.claude-sonnet5.chat_completions, itg.qwen3-embedding-4b.embeddings), и «очевидное» имя вроде claude-sonnet-5 не существует нигде. Поле со списком нельзя заполнить несуществующим значением.

1а. Персональные квоты: токены на человека

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

Settings → AI → Персональные квоты. Два поля:

Поле	Что вписать
Адрес API токенов	адрес самой инсталляции, без /v1 — например https://ai.example.com
Админ-токен	токен с ролью Admin этой же инсталляции

Маршруты управления токенами лежат вне /v1, а потребительское API — это тот же адрес плюс /v1; консоль откажет, если в адресе остался хвост /v1. Токен с ролью User к управлению не допускается — это откажет уже шлюз.

Дальше всё происходит само: когда человек заводит себе ассистента, координатор выпускает ему токен (POST /token/create, роль User, владелец — его логин, префикс значения simpletwo), передаёт его службе переписки, и та хранит его запечатанным и подставляет в вызовы модели. Значение токена шлюз отдаёт один раз, поэтому повторно узнать его нельзя ни у нас, ни в интерфейсе шлюза — при утрате выпускается новый.

Квота и срок действия задаются на стороне шлюза, в записи токена: мы их не запрашиваем и не переопределяем. Наш дневной бюджет на агента (раздел 2) — это второй пояс поверх неё.

Думает ассистент на устройствах владельца, а не на сервере: ядро клиента отвечает человеку в чате с ассистентом и разбирает приглашения по его календарю, пока приложение открыто на одном из его устройств. Вызов модели при этом идёт через полосу ассистента — на личном токене владельца, в пределах списка моделей и суточного бюджета, с записью в журнале от имени ассистента. Если полосу ассистенту не открыли (кнопка AI в разделе «Боты»), думать он не будет, и владелец увидит в чате, почему.

При удалении учётной записи координатор отзывает токен (REMOVED, необратимо) и удаляет копию из службы переписки. Если шлюз в этот момент недоступен, увольнение не блокируется, а в журнале остаётся запись о том, что токен остался живым у провайдера.

2. Полоса модели у бота

Каждому боту выдаётся собственный ключ модели (ai_…), и при выдаче задаются:

• список разрешённых моделей — бот не сможет обратиться к другой;
• суточный бюджет токенов — потолок расхода на этого бота.

Запросы идут через SimpleTwo к провайдеру с ключом тенанта; в аудит пишутся метаданные запроса, а не его содержимое.

Почему ключей два, а не один

Ключ модели не годится для входа в переписку, а ключ переписки не открывает доступ к модели: утёкший чат-токен не потратит ни рубля у провайдера, а утёкший ai_-ключ не прочитает переписку. Ротируются они независимо. При этом отключение самого бота закрывает обе полосы — один переключатель останавливает агента целиком.

3. Ассистенты и делегирование

Ассистент — это агент, который действует от имени конкретного человека: он видит то, что видит его владелец. Технически это делегированная сессия, а не отдельный участник.

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

4. Бот поддержки

Отдельный случай — служба поддержки со своей базой знаний. Одна кнопка в консоли разворачивает весь случай целиком: бот @librarian со знаком организации, его ключ модели и канал поддержки. Всё созданное остаётся обычными объектами — их видно и можно править в консоли. Бот сначала отвечает по своей базе знаний; если это новая проблема — регистрирует обращение.

Эта же кнопка включает приветствие: бот пишет каждому новому человеку в личный чат, как сообщить об ошибке или пожелании. Текст, включение и рассылку тем, кто пришёл раньше, — см. Первый день: приветствие и бот поддержки.

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

Сам сервер поддержки ставится в DMZ, наружу не смотрит и принимает только подписанные вебхуки от службы переписки — см. роль support в развёртывании.

Что слышит автор обращения

Каждое обращение — форма «Сообщить о проблеме», жалоба после звонка, дефект или пожелание, которое бот зарегистрировал в чате, — сразу сохраняется на сервере поддержки тикетом, и автор слышит его номер: «Дефект зарегистрирован: обращение T-…». Если сохранить не удалось, бот так и говорит и просит отправить ещё раз. Тикеты забирает поддержка вендора — см. Поддержка вендора, раздел «Обращения обратной связи». Ответы вендора автору по тикету появятся следующим шагом.

Раньше бот выкладывал черновик в комнату разработки, дежурный подтверждал его ✅, заводилась задача в GitLab, и бот пересказывал автору её ход. Этого пути больше нет. GitLab теперь нужен только как необязательный источник базы знаний бота: адрес сервера, проект и токен на чтение (read_api).

Бот и роль поддержки

Это разные вещи. Бот @librarian — участник чатов: внутри платформы он ничего не читает. Роль поддержки — служба платформы, которая стоит за ботом, и её работа — диагностика. Поэтому у роли есть постоянный доступ на чтение: журналы, метрики и трассы хостов с хоста мониторинга, телеметрия клиентов, состояние ролей и хостов.

Доступ — токен чтения, такой же, как у поддержки вендора, но второго вида:

• выдаётся сам при развёртывании случая поддержки и меняется при повторном развёртывании;
• доставляется только хосту поддержки этого случая;
• срока нет, пока роль развёрнута;
• список, отзыв и выдача нового — Настройки → Случай поддержки → «Доступ роли поддержки к диагностике»; отзыв действует со следующего запроса;
• из прочитанного удаляются секреты, а логины и тексты ошибок остаются;
• каждое использование — в журнале аудита от имени support:<случай>.

Прочитанное роль кладёт в тикет обращения; наружу оно уходит только с тикетом, который забирает вендор.

Версия клиента автора

Человек, который просто пишет боту, версию приложения не присылает. Сервер поддержки находит её сам — запросом телеметрии по логину автора за сутки до сообщения (или до момента, который человек описал) — и добавляет в обращение блок source: logs с временем, к которому относится версия. Блок пишет программа, а не модель. Если версия не нашлась, бот спрашивает её у человека. Форма «Сообщить о проблеме» в приложении не меняется: свои сведения она показывает человеку перед отправкой.

Кто принимает репорты из формы

Форма «Сообщить о проблеме» предлагает получателями ботов с отметкой «принимает репорты». Её ставит развёртывание случая поддержки. Снять отметку (например, с бота случая, выведенного из работы) или поставить её можно на странице Боты: меню строки → Не принимать репорты / Принимать репорты, или POST /admin/api/bots/{username}/accepts-reports с телом {"accepts_reports": false}. Только для ботов; изменение пишется в аудит и доходит до клиентов со следующим обновлением справочника.

5. Что решить до включения

1. Куда уходит текст. Внешний провайдер — это передача содержимого переписки третьей стороне. Для закрытого контура выбирайте модель внутри периметра.
2. Бюджеты. Ставьте суточный потолок каждому боту сразу: бюджет, выданный «пока без ограничения», не остаётся без ограничения — он остаётся без внимания.
3. Кто заводит агентов. Создание ботов — право в консоли; делегирование — отдельный переключатель организации. Это два разных решения, и принимать их лучше отдельно.

Дальше

• Боты и сценарии автоматизации
• Помощники и боты — что видит и чем управляет пользователь