Chiho AI
要用 AI 搜索 Telegram 消息，先连接已授权的账号，确定正确的会话，再搜索几个具体词语，并在接受答案前检查上下文。要求助手提供消息来源和覆盖范围说明，而不只是一个语气肯定的结论。
Chiho 向 Codex、Claude 或 ChatGPT 等 AI 客户端提供已授权的现有 Telegram 账号会话。向运行中的代理传递指令的 Telegram 机器人或 Claude Channel 属于另一种用途；仅有这种连接，并不能证明它能访问个人聊天档案。实际访问能力取决于账号身份、授权、相关 Telegram Business 权限、可读取的历史范围以及工具文档。若不确定连接类型，请先阅读访问架构指南。
本文由 Chiho 发布。下述产品行为于 2026 年 10 月 7 日对照 Chiho 源码核查，未在客户账号中测试。示例为虚构的验证练习，不代表搜索准确率测量。页首图片展示 Chiho 的一般界面，不是搜索结果截图。
先确认连接和会话
按照 MCP 设置指南完成客户端安装、浏览器授权、身份检查，再进行一次有边界的读取。代理连接教程负责安装流程；本文关注连接成功后如何找到证据。
请助手查看当前对话实际可用的工具。不同产品、资源和版本可能采用不同契约。若提供 auth_status 和 account_whoami，可用于核查授权与 Telegram 账号。提供 get_profile 的连接还可确认 Chiho 身份和访问范围，但该工具不读取消息。账号选择参数只能选择当前授权连接内的 Telegram 账号，不能切换到另一个 Chiho 连接。
聊天名称不是唯一标识。两个聊天同名时，应根据选定账号、会话对象类型和返回的会话引用来区分。遇到歧义先澄清，不要直接选择第一个名称匹配项。团队访问必须限于团队可见的会话，不能为了绕过限制改用个人访问。
把模糊记忆变成搜索任务
写清问题和最小必要范围。例如，“在指定的 Project Cedar 聊天中，最终约定哪天评审样品？”比“查找关于项目的一切”更容易核验。
可复制以下请求，并替换虚构名称和预算：
只使用我指定的 Chiho 连接和 Telegram 账号。读取前先核对身份，并准确确定 Project Cedar 聊天。我想查明 2026 年 10 月 1 日至 3 日期间讨论的最终样品评审日期，时区为 Asia/Singapore。先搜索 “sample”，必要时再搜索 “review”，每次最多返回 20 条匹配。读取该期间的相关上下文，最多三页，每页 20 条。只使用当前工具支持的参数。返回消息引用、相互冲突的提议、实际覆盖时段和未完成部分。遇到身份歧义、错误或等待响应时停止。不要发送消息、创建任务、启动同步或修改记录。
日期说明期望的证据窗口，并不保证搜索工具支持日期筛选。页数和匹配数只是本次调查的示例预算，不是产品吞吐量建议。如仍不足，应另行确认扩大范围。
了解搜索工具真正支持哪些筛选
本文核查的托管 Chiho CRM 实现中，search_messages 接收查询词、可选聊天、账号选择及结果上限。该路径搜索 Telegram，不支持本地 CRM、标签或公司筛选。团队范围内的消息搜索必须指定聊天。其他产品或版本应以各自发现的工具 schema 为准。
此实现没有提供搜索日期范围或搜索续页游标。不要编造 from、to 或 cursor 参数。重复相同的有限查询，并不证明读取了下一页。如果返回结果达到上限，应说明覆盖有限，而不是宣称已经搜索完整个档案。
Telegram 官方文档介绍了多种搜索和筛选 API，但平台支持某项能力，不代表每个 MCP 连接器都开放了它。需要区分 Telegram 的能力和当前工具接受的参数。
尝试消息中可能真实出现的词：项目名称、文档名、独特短语或同义词，并使用参与者当时的语言。自然语言问题可以帮助助手规划查询，但不能证明底层工具对所有消息、附件、图片和语音都进行了语义搜索。
读取上下文，并有计划地翻阅历史
匹配消息可能只是提议、旧计划，或后来被否定的内容。形成答案前，先读取与之相关的上下文。
本文核查的托管 CRM chat_read 路径可能返回 nextOffsetDate 和 nextOffsetMessageId。读取更早一页时，将两者一起传入对应的 offsetDate 和 offsetMessageId 字段。遵循实际 schema 和返回值，不要猜测偏移量，也不要把游标用于另一个账号或聊天。到达目标时段、预算上限，或收到错误、等待响应时就停止。
按照指定时区核对时间戳，并记录实际读取到的最早和最晚消息时间。此历史读取不获取媒体内容，因此读取了文本并不代表检查过附件或语音。若决定可能出现在文件或录音中，应明确记录这一限制。
可在授权的工作环境内填写以下覆盖记录：
- **范围：**已确认的连接、所选账号和准确的会话引用。
- **问题与目标时段：**包括时区。
- **搜索：**查询词、返回匹配数、结果上限及是否支持续页。
- **历史：**已读取页数和消息数、实际时间边界，以及工具报告的剩余续页信息。
- **缺口：**未读取媒体、缺失时段、错误、等待或触发停止的预算。
- **结论：**有证据支持的发现、相反证据及下一次有边界的检查。
请将记录保留在授权的工作环境中，不要在公开报告里发布账号标识或私人会话引用。
虚构示例：提议不等于最终约定
以下三条是虚构教学材料，不是 API 响应或客户结果。时间均为新加坡时间，引用标签也是虚构的：
- Cedar / M101，10 月 1 日 09:00：“我们能在周五评审样品吗？”
- Cedar / M108，10 月 1 日 09:20：“周五只是暂定，请等实验室档期。”
- Cedar / M154，10 月 2 日 16:10：“实验室确认了 10 月 5 日周一，我们就那天评审样品吧。”
M101 支持“有人提议周五”，不支持“已约定周五”。M108 可以避免这个误判；在这组材料内，M154 支持后来改为周一的计划。
合适的回答是：“已读取记录中最后一个明确计划是 10 月 5 日周一（M154）。周五曾被提议（M101），但被标记为暂定（M108）。我未检查 10 月 2 日 16:10 之后的消息，因此不能排除后续变更。”
对真实结果，应注明返回的会话引用、消息 ID 和时间，并附上简短的相关引文或转述。只有工具返回或独立核验过的消息链接才能作为直接链接；不要根据聊天名称编造 URL。涉及多个聊天时，仅有消息 ID 不够。明确区分原文陈述和助手的解释。
如果实际目标是提取承诺与下一步行动，请继续阅读查找客户承诺的指南。
区分空结果和错误
“在这次有限搜索中，这些词没有匹配”是合理结论；“从未讨论过此事”通常需要更充分的覆盖证据。扩大搜索前，先检查账号、聊天、拼写、语言，并尝试查找一条已知消息。保存的 CRM 摘要或缺少某条 CRM 记录，都不能证明 Telegram 历史里有什么。
工具失败时应报告失败，不要把它写成空结果。HTTP 成功本身不证明工具成功或返回了非空消息。若 chat_read 返回限流响应，在同一账号下一次读取前等待 retryAfterSeconds，不要并行重试。身份、工具发现或读取失败时，可使用故障排查指南。
把检索和后续行动分开。Chiho 会执行权限与操作保护，但并非每次代理写入都需要单独的 Chiho 审批。只读请求应明确排除发送和记录修改。扩展到写入流程前，先阅读安全检查清单。
最后核对一条你能独立确认的消息
通过 Chiho MCP 页面在所选客户端完成安装和浏览器授权。检查身份后，找到一条你知道存在且有权读取的消息。对照 Telegram 检查聊天、时间和措辞，再审阅助手的覆盖说明。
这能为本次有边界的检索提供实用验收依据，却不能认证整个档案、另一个账号或定时任务。先确保第一个结果可以追溯到来源，再逐步扩大范围。