Chiho AI
Telegram MCP 服务器通过 Model Context Protocol 将 AI 应用连接到与 Telegram 有关的工具。这个名称并未说明它使用哪种 Telegram 身份或可访问哪些内容。实际项目将其用于三种不同工作：处理账号的对话、测试 Telegram 机器人，或通过 Telegram 与在别处运行的智能体通信。
先选择工作，再选择服务器。机器人测试适配器未必提供团队的客户历史，而通过手机操作智能体的远程接口也不会自动成为 Telegram CRM。
页首图片：已有的 Chiho CRM 界面图片，并非 MCP 测试结果。
发布方披露： Chiho 发布本指南，并提供托管 Telegram MCP 服务。以下示例用于说明文档中描述的架构，并非排名或实际操作对比。文档和 Chiho 源代码于 2026 年九月 23 日审核；未运行竞争产品的运行环境，也未对真实客户账号进行实验。
MCP 提供什么，Telegram 适配器决定什么
MCP 定义 AI 应用如何连接服务器并发现工具等能力。服务器可在本地或远程运行。协议本身不决定连接哪个 Telegram 账号、哪些消息可用，或发送是否需要审批。这些属于实现与配置问题。请参阅 MCP 架构文档。
区分三个决定：
- 用途： 阅读客户对话、测试机器人，或与智能体通信。
- Telegram 身份： 已连接的用户账号、机器人身份，或测试人员使用的浏览器会话。
- 运行模式： 托管服务，或你自行运营的运行环境。
这些维度可以重叠。本地服务器可以访问用户账号，托管服务也可以。一个产品可提供多种模式。“远程”可能指 HTTP 端点，也可能指从手机控制智能体，应明确是哪种含义。
架构 1：智能体处理 Telegram 账号数据
在这种架构中，AI 客户端请求 MCP 服务器从已连接的 Telegram 账号获取信息。服务器也可能提供操作和 CRM 上下文。关键问题是：在预期账号与工作区权限下，它能否获取任务需要的特定对话和消息范围。
例如，销售交接时，智能体可能阅读获准的客户对话并找出最后一项已确认承诺。这需要对话访问和足以支持答案的历史。工具名称列表或成功登录都不能证明这两个条件中的任何一个。
Chiho 的 Telegram 智能体仓库记录了两种账号访问路径：使用浏览器 OAuth 的托管 Chiho MCP，以及通过 stdio 运行、使用运营者 Telegram 凭据和存储的自托管 tgchats local 运行环境。它们是独立的软件包和运行模式。托管服务也连接 Chiho 的 CRM 流程；不要假定所有本地与托管功能行为相同。
托管连接请使用持续维护的 Chiho Telegram MCP 页面。其同意授权流程授予当前 Telegram 和 CRM 能力，包括可用的写入；选择只读的首次任务不会让底层授权变成只读。Chiho 要求邀请成员和退出群组使用已保存的预览与审批，并可要求批量发送经过审批。其他写入可在任何客户端控制之后直接执行。应检查具体工具和客户端设置，不要假定所有写入都会暂停等待审核。
账号访问也不同于 CRM 覆盖。实时对话可能尚无持久保存的 CRM 行，部分历史读取也不能证明更早的承诺从未存在。我们的 Telegram 聊天数量指南解释了这种清点区别。
架构 2：智能体以用户身份测试 Telegram 机器人
机器人开发者可能希望智能体查看欢迎界面、操作按钮或检查 Mini App。即使目标是机器人，这仍是用户界面测试问题。
例如，telegram-bot-testing-mcp记录了一种在浏览器中操控官方 Telegram Web 客户端的适配器。它公开的操作包括阅读消息、按按钮、发送文件和检查 Mini Apps。README 建议使用专门的测试账号，并将浏览器配置文件视为敏感会话材料。这些是文档描述的能力，并非我们独立复现的结果。
身份区别很重要：机器人是被测试的目标，而适配器使用已登录的用户会话。“机器人测试”并不意味着适配器使用你的机器人令牌进行认证。
一个示例测试可能检查支持机器人在收到命令后是否显示预期菜单。发送该命令或按按钮可能改变状态。先阅读已有测试输出；只在获授权且效果已知的测试环境中运行交互场景。仅有“测试环境”标签，不能证明真实客户或支付不可触达。
这种架构适合机器人回归测试。它本身不能确定团队责任归属、CRM 持久化或所有客户对话的访问。
架构 3：Telegram 是智能体的远程接口
在这种安排中，你使用 Telegram 与运行在另一台机器上的智能体交换指令或状态。目标是监督智能体，而非搜索客户账号。
mcp-telegram-claudecode 仓库记录了使用机器人令牌和配置的聊天 ID，在 Claude Code 与 Telegram 间发送和接收消息。它也描述通过 hooks 进行远程权限决策。这说明了控制渠道模式，并非安全背书，也并非证明这些控制适合你的环境。
例如，运营者可能在手机上收到构建状态消息。这不能说明智能体能否读取一段无关的客户对话。反过来，客户历史连接器也未必提供手机审批界面。
评估谁可以通过渠道发出命令、智能体在其主机上能做什么，以及审批如何标识确切操作。一条消息出现在 Telegram 中，并不足以建立可信授权。
Bot API 访问是单独的边界
服务器也可封装 Telegram 的 Bot API，执行机器人侧操作。这是一种访问机制，并不保证上述任意一种流程。
Telegram 的机器人常见问题说明机器人会收到哪些消息，包括群组隐私模式如何影响可见性。其 Bot API 文档也定义了具有自身权限的商业连接。因此应避免两个极端：机器人令牌并不是对个人收件箱的通用访问，但也不能在未核查实际权限和受支持流程前就否定基于机器人的商业集成。
询问服务器以用户、机器人还是获授权商业机器人身份运行，以及该身份涵盖哪些聊天和操作。更广泛的产品选择可参考 Telegram CRM、机器人与共享收件箱的比较。
连接前需要回答的问题
- 谁维护它？ 检查仓库所有者或服务提供方。与 Telegram 相关的名称、使用官方 API 或运行 Telegram Web，都不能证明 Telegram 发布或认可该 MCP 服务器。
- 使用什么身份？ 私下记录预期账号、机器人、团队和环境。不要将会话文件、机器人令牌或登录码粘贴到评估报告中。
- 实际能获取什么？ 检查历史范围、分页、归档聊天覆盖，以及结果来自实时 Telegram 还是已保存的 CRM 数据。
- 什么会改变？ 区分读取、已保存预览、CRM 编辑、Telegram 操作和主机操作。检查强制执行的权限和客户端提示行为。
- 返回的内容去哪里？ 追踪从 Telegram 经服务器到 AI 客户端及其模型提供方的路径。本地运行适配器本身不会让模型输入留在本地。
- 如何断开？ 确认相关授权或会话的撤销流程。断开未来访问不会收回已经返回给客户端的内容。
流程说明是另一层。Telegram 技能目录提供任务指导，但不能将说明误认为强制执行的访问边界。
一项小规模只读验收练习
使用一个你有权查看的现有非敏感对话或测试样例。这是建议的评估练习，并非有实测结果的研究。
首先说明任务：“阅读这段获准测试对话中的最后几条消息，并报告最新的明确承诺。不要发送、标记已读、同步、编辑或创建任务。”验证所选读取工具不会执行这些额外操作。如果会，选择更窄的操作或停止。
然后检查四点：
- 返回的身份和对话符合预期范围。
- 结果说明历史范围或分页限制，而不是暗示已完整覆盖。
- 答案区分明确承诺与推断，并指向支持它的消息上下文。
- 获取结果不需要写入，且缺少访问被报告为限制，而非猜测内容。
对于机器人测试适配器，使用已有测试消息，不按按钮。对于智能体远程接口，查看已有控制渠道消息，不发出执行命令。这些练习测试不同能力；不要因工具缺少另一种架构所服务的用途就判定它不足。
如果你的目标是客户上下文和后续跟进，请从 Chiho 连接指南开始，在扩大流程前运行边界明确的读取检查。保持结果简洁：预期工作、已验证访问、观察到的限制，以及下一项明确获授权的操作。