TelegramConsole：把 Telegram 多账号、定时任务、消息检索和 NAS 后台放进一个控制台

项目地址：https://github.com/wutangyuan/TelegramConsole

最近把 TelegramConsole 做了一轮比较系统的整理：它已经不只是一个“能登录 Telegram 的 WPF 小工具”，而是逐渐变成了一个面向长期运行的 Telegram 控制台。桌面端负责日常交互，NAS/Docker 端负责后台常驻，底层把 Telegram 连接、定时调度、日志、异常、SQLite 索引、发件箱和 AI 摘要能力拆成了相对清楚的模块。

最新 README 里也补上了完整的界面图集：docs/SCREENSHOTS.md 覆盖了账号工作区、效率工具、全局设置和管理中心共 20 个页签，所有公开图片都使用脱敏演示数据，不包含真实账号、会话、消息、密钥或网络信息。这篇文章也按最新 README 的结构重新整理一下：它解决什么问题、架构怎么拆、以及几个最值得展开的功能点。

为什么要做这个项目

Telegram 官方客户端很强，但如果想把它当成“自动化入口”或者“长期运行的消息控制台”，就会遇到一些细碎问题：

• 多账号同时跑时，需要统一看状态、日志和异常。
• 群消息监控、关键词通知、@我的消息 记录、定时签到这些事，靠手工客户端不太适合。
• NAS 上希望有一个轻量 Web 控制台，能长期跑，不依赖 Windows 桌面会话。
• 消息检索、引用回复、编辑、撤回、转发、自动化规则等操作，最好复用同一套 Telegram 服务接口，而不是各写各的。
• AI 摘要、回复草稿、群成员自动回复这类能力，也需要一个统一的模型调用入口。

所以 TelegramConsole 的目标不是替代 Telegram 客户端，而是把“可自动化、可观测、可长期运行”的那部分能力抽出来。

项目结构

当前解决方案按职责拆成了几个项目：

• TelegramConsole.Core：业务模型与服务接口。
• TelegramConsole.Infrastructure：Telegram、Quartz、SQLite、日志、加密存储、代理和邮件实现。
• TelegramConsole.Runtime：跨界面复用的多账户长期运行管理器。
• TelegramConsole.AI：独立 AI 能力库，封装 Microsoft Agent Framework、OpenAI 兼容模型和本机 Codex CLI 登录适配。
• TelegramConsole.Web：面向 NAS/Docker 的 Web 管理站和 API。
• TelegramConsoleApp：WPF 桌面界面。

这里我比较满意的一点是：桌面端和 Web 端不直接抢业务主导权，它们都围绕 Runtime 和 Core 组织功能。这样 WPF 可以继续保持桌面体验，NAS 版本也可以用自己的数据目录独立运行，不读取 Windows DPAPI 配置，也不会占用 WPF 当前使用的 Session。

重点界面：不再只靠文字说明

最新提交把界面文档补齐了：仓库中的 docs/SCREENSHOTS.md 按模块列出了完整页签说明，README 则挑出聊天终端、定时签到、AI 助手、账户管理和设备资源这几个最能代表项目形态的界面。

账号工作区目前覆盖 9 个页签：聊天终端、群消息监控、定时签到、间隔分析、@我的消息、异常中心、发件箱、AI 助手和运行日志。效率工具另有消息搜索、服务器定时、自动化规则、草稿与文件夹 4 个页签；全局设置包括代理、SMTP 和 AI；管理中心则负责账户、设备资源、异常和运行日志。

这套图集的意义不只是“好看一点”。它把项目边界讲清楚了：哪些功能属于单个 Telegram 账号，哪些功能是跨账号公共资源，哪些配置应该放在全局设置里。

管理中心：先把多账号跑稳

WPF 端现在有一个唯一管理中心，用来维护多账户、设备资源、全局异常和运行日志。后台自动启动账号时，不会弹出或闪烁工作区窗口；各账号工作区只承载聊天、监控和账号自动化业务。

资源页会集中展示进程内存、应用数据、磁盘 I/O 和 Telegram 流量。这个页面的价值不在于指标多复杂，而是排查问题时可以快速确认：到底是账号掉线、代理不通、消息流量异常，还是程序资源本身有波动。

运行日志也统一收口到了管理中心：

日志和异常是分开的：业务校验类问题只做界面提示，真正的程序异常才会入库。这样异常中心不会被“输入为空”“权限不足”这类正常提示淹没。

聊天终端：从 TUI 到可视化消息流

桌面端支持私聊、群聊和独立 TUI 风格聊天控制台。聊天终端有“控制台 / 可视化 / 分屏”三种显示模式；可视化模式参考 Unigram 的消息气泡结构，但复用同一条历史与实时消息流，不改变登录、监控、发送和定时任务流程。

可视化消息不是只把文字换成气泡。它支持引用关系、自己/他人/@我的消息样式、撤回缓存标识，以及图片、视频、动图、语音、音频、文件、贴纸、投票、位置、联系人和网页等媒体卡片。可下载媒体会按账号隔离缓存，正文链接可直接打开，引用块可跳转原消息。

右键操作也尽量贴近真实聊天场景：引用、编辑、撤回、转发、复制正文、复制链接和快速表情回应，都复用 WTelegramClient 服务接口，而不是在 UI 层单独造一套行为。

效率工具：搜索、服务器定时、自动化和云草稿

效率工具里目前包括消息搜索与操作、Telegram 服务器定时、自动化规则、草稿和会话文件夹。

消息搜索会合并两个来源：

• Telegram 远端搜索。
• 本地 SQLite FTS 索引。

同一条消息同时出现在两个来源时只显示一条。本地索引不是全量历史备份，只保存程序运行期间收到或加载过的消息；这个边界很重要，避免以后误以为它能凭空搜到 Telegram 没返回、且本地从未见过的旧消息。

搜索结果支持直接回复、引用回复、转发、编辑、删除和复制频道消息链接。最终是否成功仍然取决于 Telegram 权限、消息类型和服务端限制。

自动化规则可以按关键词、正则、@我的消息、指定会话或发送人触发动作，动作包括记录日志、发送 Telegram 消息和发送邮件。草稿与文件夹则走 Telegram 云端能力：云草稿会同步到同账号其他客户端，自定义/共享文件夹也直接读取 Telegram 当前配置。

定时任务：Quartz 和 Telegram 原生计划消息各司其职

项目里有两类定时能力：

• 每日/每周签到：由 Quartz 执行，程序需要保持运行和登录。
• Telegram 服务器定时消息：提交后由 Telegram 服务器计时，即使程序关闭也能按时发送。

每日/每周签到支持勾选、多选、编辑、立即执行，也可以通过 Telegram 或邮件发送完成通知。为了避免重复发送，项目里还有可靠发件箱：发送状态会记录下来，结果未知的消息只允许人工确认后重试。

间隔聊天分析也属于长期运行任务：它会按配置周期读取来源会话，达到最低消息数后生成聊天简报并发送到指定会话；如果消息量不足，就跨间隔继续累计，而不是丢掉上下文。

NAS / Docker：让控制台长期跑在后台

NAS 版本由 TelegramConsole.Web 和 TelegramConsole.Runtime 组成，默认端口是 5080。部署方式很直接：

Copy-Item .env.example .env
docker compose up -d --build

容器里有独立的数据目录和健康检查：

• /health/live：进程级健康检查。
• /health/ready：账号汇总状态。

单个 Telegram 账号断线不会让整个容器反复重启，可以在管理首页单独查看和恢复该账号。

持久数据保存在 Docker 卷 telegramconsole-data，包括账号配置、任务设置、主密钥、Session、日志和 SQLite 数据库。备份时必须保存整个数据卷，只备份 accounts.dat 而没有 master.key 是无法恢复的。

部署到 NAS 时还有一个常见坑：容器中的 127.0.0.1 是容器自己，不是宿主机。如果代理跑在宿主机上，Docker Desktop 可以用 host.docker.internal:7890；Linux NAS 上也尽量走 host-gateway 配置，或者直接填 NAS 的局域网地址。

当前 Web 控制台已经能覆盖多账户添加、启动、停止、移除、登录验证码和二次验证、群消息监控、会话列表、消息发送、最近 300 条消息增量刷新、引用回复、编辑、撤回、表情回应、定时任务、间隔分析、@我的消息、异常中心、发件箱、运行日志和 SMTP 设置。也就是说，它已经不是“只能看状态”的管理页，而是可以承担 NAS 常驻场景里的主要操作入口。

AI 能力：作为控制台的增强层

TelegramConsole.AI 被单独拆出来，主要是不想让模型调用散落在 UI 或 Telegram 业务代码里。它目前支持 OpenAI、DeepSeek、本地 Ollama 等 OpenAI 兼容服务，并统一经过 Microsoft Agent Framework 的 Agent 管道执行。

现阶段 AI 能力主要用于：

• 会话摘要。
• 回复草稿。
• 间隔聊天分析。
• 指定群成员自动回复。

这部分我更倾向于把它看作“增强层”，而不是核心依赖。即使没有模型配置，Telegram 登录、消息、定时、日志、NAS 这些基础能力仍然应该稳定可用。

AI 的开关也分层处理：全局设置里配置服务商、模型和调用参数；账号侧再决定是否启用摘要、草稿和自动回复。这样可以避免“配置了模型就所有账号都自动参与”的误操作。

构建与运行

本地构建：

dotnet build .\TelegramConsole.sln

NAS / Docker 运行：

Copy-Item .env.example .env
docker compose up -d --build

默认访问地址：

http://localhost:5080

项目使用 GPL-3.0 协议。从当前版本开始，衍生发布物也需要遵守 GPL-3.0 的开源与分发要求。

最新提交里值得注意的变化

最近几次提交的方向很清晰：

• docs: add bilingual README and AI architecture：补齐中英文 README，并把 AI 架构作为独立能力说明。
• refactor: extract AI library with MAF pipeline：把 AI 能力抽成 TelegramConsole.AI，通过 MAF 管道统一调用。
• feat: add configurable AI group auto replies：把群成员自动回复做成可配置能力，而不是固定逻辑。
• docs: add sanitized UI gallery：新增完整脱敏界面图集。
• docs: highlight key screens in readme：在 README 里直接展示重点界面，让第一次打开仓库的人能马上看到产品形态。

也就是说，项目最近的重心不只是继续加功能，而是在把“能跑”整理成“能被理解、能被部署、能被二次开发”的形态。

小结

TelegramConsole 现在的重点，是把 Telegram 的长期运行场景做扎实：多账号、日志、异常、定时、搜索、可靠发送、NAS 后台和 AI 摘要都围绕这个目标展开。

后续如果继续迭代，我会优先关注三件事：

• Web 控制台继续补齐桌面端的高频操作。
• 自动化规则增加更清晰的调试和命中记录。
• AI 摘要和自动回复进一步强调可控性，避免“模型能回”和“应该回”混在一起。

项目还在快速变化中，欢迎看源码、提 issue，或者直接按自己的 Telegram 工作流改出一套更适合自己的控制台。

GitHub 项目地址：https://github.com/wutangyuan/TelegramConsole