Chiho AI
如果你希望提供方运营连接服务，并接受其数据处理和访问模式，可选择托管 Telegram MCP。如果团队需要自行运营运行环境、凭据、存储和恢复流程，而且有人负责这些工作，可选择自托管 MCP。任何一种选择本身都不能确立隐私、可靠性或更低的总成本。
有用的问题是：流程各部分由谁负责，如何证明它在预期边界内有效？ 远程端点和本地进程可能提供不同工具、不同账号访问和不同的已保存上下文。
发布方披露： Chiho 发布本比较，并提供托管 Telegram MCP 服务。以下示例比较文档中的 Chiho Cloud 和 tgchats local 责任，并非独立供应商排名或实际可靠性基准测试。文档和源代码于 2026 年九月 25 日审核。页首图片展示已有的 Chiho CRM 界面，并非测试结果。
将部署位置与 Telegram 访问分开
托管描述谁运行服务。远程描述客户端如何连接。自托管可指笔记本上的进程，也可指团队运营的基础设施。这些标签并未说明实现使用机器人还是已登录的 Telegram 账号。
MCP 传输规范描述 stdio 和 Streamable HTTP。stdio 集成作为客户端子进程运行；HTTP 服务可由供应商或团队运营。应检查客户端实际支持的传输和认证，而不要将“MCP”当成完整部署规范。
Chiho 的 Telegram 智能体仓库记录了托管浏览器 OAuth 路径，以及名为 tgchats local 的自托管 stdio 运行环境。文档将两者都描述为账号级集成。不要将这一描述套用到每个 Telegram MCP 服务器。更广泛的分类见 Telegram MCP 架构。
用于决策的责任矩阵
将以下成对责任作为采购和运营工作表。“应索取的证据”是建议的验收产物，并非声称任一示例已经提供它。
运行环境、更新和可用性
托管： 询问提供方运营哪些组件、如何通知更新，以及在哪里报告服务事故。团队仍负责客户端配置和启用工具的决定。
自托管： 指派运营者负责进程监督、依赖更新、数据库迁移和恢复。如果服务运行在笔记本上，应将合盖或离线纳入故障场景。
应索取的证据： 明确的负责人、更新程序，以及使用获准测试数据进行的恢复演练。成本比较应包含运营者时间，不要只比较订阅与服务器价格。
凭据、会话与接入
托管： Chiho 通常的交互路径使用浏览器 OAuth。在同意授权流程中确认账号、环境和所请求权限。遵循当前连接指南，不要将服务令牌复制到交互客户端。
自托管： tgchats 文档描述了 Telegram API 凭据、Telegram 登录会话和 Postgres 应用数据库。配置还支持 AI 提供方或兼容端点。在第二位运营者接入前，明确这些秘密和配置文件的责任人。
应索取的证据： 一张说明凭据和会话存在哪里、谁可访问，以及如何移除访问的图。不要在工作表中放入秘密值或会话文件。
对话数据与保留副本
托管： 审核提供方当前政策，包括保存什么、为什么保存，以及如何处理删除请求。Chiho 的隐私政策是其服务的起点；对于公开政策未解决的要求，应取得回答。
自托管： 自行维护数据库意味着承担运营责任，并不证明流程每部分都留在这台机器上。分别检查配置的 AI 端点、客户端历史、导出、日志、备份和所有外部存储。
应索取的证据： 覆盖 Telegram、MCP 运行环境、AI 客户端和模型服务，以及每份保留副本的数据流清单。连接远程模型的本地服务器并非全本地流程。比较应针对你计划使用的具体配置。
团队范围与操作控制
托管： 查看已授予的个人或团队上下文，以及实际可用工具。Chiho 的公开权限指导描述针对操作的控制：邀请成员和退出群组需要已保存预览与审批；批量发送可要求审批；其他写入可在客户端控制后直接执行。不要假定每次写入都会暂停等待确认。
自托管： 查看运行环境当前的工具契约和访问控制。共享机器或 Telegram 会话访问，本身不会建立按人区分的权限。询问拟议部署如何识别调用方并限制每一位。
应索取的证据： 每个角色允许的操作、一次拒绝操作测试，以及用于调查意外变更的记录。流程技能提供说明，但不能替代强制授权。
覆盖、故障与恢复
托管： 区分服务可用性、Telegram 连通性和 CRM 记录可用性。成功连接不能证明所有对话已导入，也不能证明所有请求操作成功。
自托管： tgchats 文档提供独立的实时对话和持久 CRM 查看界面。在将缺少 CRM 上下文诊断为丢失 Telegram 历史之前，应将预期对话与已保存状态比较。
应索取的证据： 一次边界明确的读取、一次明确的覆盖检查，以及在重试写入前检查结果的恢复程序。有关不同清点范围的区别，请看 Telegram 聊天数量为何不同。
选择前追踪一次客户跟进
考虑这个虚构示例：销售团队希望智能体在一段获授权对话中找到最新承诺，并建议下一项任务。本文未进行客户实验。
对于托管路径，画出 AI 客户端调用托管 MCP 服务、服务获取获准 Telegram 或 CRM 上下文，以及结果返回客户端的过程。标出每个可能保留内容的位置，以及沿途使用的每种身份。
对于自托管路径，用你的运行环境、Telegram 会话和数据库画出同样的图。如果流程使用模型服务，加入配置的模型服务。不要仅因 MCP 进程在本地，就省略 AI 客户端。
然后写下三个独立输出：获取的来源证据、建议的跟进，以及之后获授权时持久保存的任务。这可避免把“智能体回答了”误认为“CRM 已更新”。使用 AI 智能体流程指南将这种区别转化为清晰请求。
在两条路径上运行相同的验收练习
这是评估协议，没有结果或性能主张。使用你有权测试的账号和对话；优先选择含虚构消息的专用测试对话。不要为了方便而将无关客户历史当作测试样例。
- 记录身份与范围。 记录环境、预期账号或团队、可用时的运行环境版本，以及允许的工具类别。公开报告中不包含标识符或凭据。
- 读取已知消息。 请求测试对话中一小段指定范围。将答案与样例比较。要求智能体说明范围不完整或不可访问的情况。
- 单独检查 CRM 覆盖。 询问测试对话是否具备流程所需上下文。缺失标签或任务必须保持缺失，不能通过推断变成存在。
- 仅请求建议。 要求一项跟进任务及支持消息；若未提供日期，则保留日期未定。验证请求没有更改记录或发送任何内容。
- 可选测试一个获授权效果。 如获准，明确请求创建这项确切测试任务，并检查生成记录。单独测试 Telegram 送达，只使用具体获授权的收件人和消息。任务记录不是已发送消息的证明。
- 演练故障。 在受控测试中中断客户端连接或停止本地进程。恢复后，重试前检查实际结果。记录故障属于客户端、服务、Telegram 还是存储问题，不要假定由托管模式引起。
- 验证访问移除。 测试预期的客户端断开或授权撤销程序，再检查被移除的凭据是否已无法执行受保护操作。单独检查 Telegram 会话和保留数据。移除 MCP 连接不会收回已返回客户端的内容。
每一步记录预期行为、观察行为、证据和待解问题。如果身份、权限或写入结果仍有歧义，就停止扩大范围。不要把成功的七步样例变成关于所有客户端或生产负载的主张。
选择团队能够运营的模式
团队需要托管产品并接受提供方文档中的边界时，托管设置可作为候选。它仍需要内部负责人处理同意授权、客户端权限和持续审核。
团队有具体运营要求和负责维护的人时，自托管可作为候选。选择前，明确谁处理更新、数据库恢复、会话替换和团队成员离开。“我们控制服务器”在没有这些安排时并不完整。
如果两条路径都不满足必需的数据处理或访问控制条件，应保留该条件为阻碍，而不要假定换一个托管标签就能解决。使用同一工作表比较实际实现。
从 Chiho 托管 Telegram MCP 指南或 tgchats local 文档开始。选一个获准对话，完成验收记录，再决定结果是否支持更广泛的团队推广。