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

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

Chiho передаёт ИИ-клиентам, включая Codex, Claude и ChatGPT, существующие разговоры авторизованного аккаунта Telegram. Бот или канал для передачи команд агенту решает другую задачу: такое подключение само по себе не подтверждает доступ к личному архиву. Доступ определяется аккаунтом, применимыми Business-разрешениями, документированными инструментами и фактическим охватом истории. Подробнее — в обзоре архитектур Telegram MCP.

Материал опубликован Chiho. Утверждения о продукте проверены по исходному коду 18 октября 2026 года. Это рекомендуемый порядок проверки и вымышленное упражнение, а не испытание реального аккаунта. Изображение показывает общий интерфейс Chiho, а не выполнение проверки.

Сначала подтвердите аккаунт

Начните с настройки Chiho MCP, пройдите авторизацию в браузере и посмотрите текущий набор инструментов подключения. Вызовите auth_status для проверки авторизованной области, затем account_whoami для просмотра доступных аккаунтов Telegram. Успешная аутентификация ещё не выбирает нужный аккаунт.

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

Текущие инструменты инвентаризации отклоняют запрос без accountId, если доступно несколько исправно подключённых аккаунтов. Передавайте выбранный аккаунт явно там, где это поддерживает объявленная схема. Флаг основного аккаунта не следует считать постоянным выбором маршрута.

Определите peer, а не угадывайте по названию

Используйте dialogs_list для разрешённого личного аккаунта или crm_dialogs_list для доступной командной CRM. Личный путь dialogs_list недоступен подключениям с командной областью. Где поддерживается, includeLastMessage: false позволяет получить метаданные без превью последнего сообщения. Продолжайте страницы только в согласованных пределах: одна страница не равна всему аккаунту.

Сверяйте идентификатор и тип peer вместе с названием. Сохраняйте возвращённый peerRef, если он доступен и принимается следующим инструментом. Не собирайте дескриптор из числа другого аккаунта и не меняйте тип peer. Контекст аккаунта и тип важны даже при знакомых номерах или названиях.

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

Руководство по инвентаризации объясняет различия между живыми диалогами и сохранёнными строками CRM. Отсутствие строки не доказывает отсутствие чата. Не запускайте синхронизацию и не расширяйте доступ автоматически.

Прикрепляйте контекст к каждому источнику

Перед chat_read укажите проверенные аккаунт и область, выбранный диалог и вопрос. Следуйте объявленной схеме для аккаунта, peer, поддерживаемого peerRef, лимита и продолжения. Запрашивайте только нужные сообщения. Не выполняйте параллельные чтения истории одного аккаунта и соблюдайте возвращённое время ожидания.

Храните краткую карточку источника в разрешённом рабочем пространстве:

• Подключение: среда, личная или командная область, идентификатор выбранного аккаунта.
• Диалог: понятное название, идентификатор и тип peer, возвращённый дескриптор при необходимости.
• Доказательства: номера сообщений, исходное время, время получения и релевантные выдержки.
• Охват: запрошенный период, фактически полученный диапазон, продолжение или граница остановки и пробелы.

Это рекомендуемый формат отчёта, а не новый объект API Chiho. Не публикуйте access hash, учётные данные или частные сведения аккаунта. Одного номера сообщения недостаточно. При смене аккаунта или области заново определите диалог и храните новый результат отдельно. См. сравнение разговоров с сохранением источников.

Проверьте совпадение названий на вымышленных данных

Используйте карточки локально. Все имена, идентификаторы и сообщения вымышлены; обозначения не являются аргументами инструментов. WORK обозначает аккаунт, personal — личную область, channel и chat — разные типы peer. A: ожидается юридическая проверка; B: одобрена внутренняя репетиция; C: завтра проверка дизайна.

Synthetic identity cards — not live Telegram output or tool arguments
DEMO-IDENTITY | all names, identifiers and messages are fictional
A: account WORK-A | scope personal | title Launch | peer channel:7101
   message 401 | 2026-10-16 09:00 +08:00 | Wait for legal review.
B: account WORK-B | scope personal | title Launch | peer channel:7102
   message 401 | 2026-10-16 09:00 +08:00 | Internal rehearsal approved.
C: account WORK-A | scope personal | title Launch | peer chat:7103
   message 402 | 2026-10-16 09:05 +08:00 | Design review tomorrow.
Requested source: WORK-A / channel:7101 / message 401
Expected conclusion: legal review is pending; approval is not established.
Coverage: these supplied cards only; no live reads or complete archive claim.

Попросите клиента определить, подтверждено ли одобрение в запрошенном разговоре. Он должен выбрать A и сообщить об ожидаемой юридической проверке. Одобрение B относится к другому аккаунту и другой цели; C имеет тот же аккаунт и название, но другой peer. Повторяющийся номер сообщения не связывает источники.

Теперь уберите указание нужного peer. Следующий шаг — уточнить, какой из разговоров WORK-A имеется в виду, а не объединять A и C. Это воспроизводимый протокол приёмки, а не измеренная точность или результат живых вызовов.

Остановитесь при несовпадении области доступа

Командное разрешение охватывает авторизованный командный контекст, а не все личные разговоры сотрудника. Текущий маршрут чтения команды проверяет диалог и владельца Telegram-сессии. Отказ по области или запрос повторной авторизации нужно разрешать в этом контексте; личный токен не является автоматическим обходным путём.

Отделяйте чтение источника от последующей задачи или сообщения. Chiho применяет разрешения и защитные меры по действию, клиент управляет запросами подтверждения; не каждое изменение требует отдельного одобрения. Этот запрос намеренно ограничен чтением:

Проверь подключение и нужный аккаунт Telegram. Определи [диалог] в этой области. При совпадении названий или неясной идентичности остановись и попроси меня выбрать по метаданным. Прочитай не более [лимит] сообщений по [вопросу и периоду] согласно объявленной схеме. Верни ответ с аккаунтом, областью, peer, номерами сообщений и фактическим охватом. Не смешивай другие аккаунты и чаты. Не синхронизируй, не редактируй CRM, не создавай задачи и не отправляй сообщения.

Завершите ответом с определённым источником

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

Подключите Chiho MCP, авторизуйтесь в браузере, проверьте аккаунт и выполните одно ограниченное чтение. Изучите карточку источника, прежде чем отдельно запрашивать дальнейшее действие.