Releases
Entergram 更新 - 2026 年 6 月 25 日当周：稳定性、代理工具与 25 项以上修复
这是 Entergram 工程投入很深的一周。我们上线了两项新的基础设施能力，显著提升了高并发工作区的稳定性，并修复了 25 个以上的问题，覆盖消息、连接管理、新用户引导、计费与 CRM 表格。下面是本周全部落地的内容。
新功能：面向管理员的代理工具
按路由统计代理用量与静态代理池
管理员现在可以把代理流量归因到具体的路由和已连接账号，从而看清哪些连接消耗了最多的代理带宽。与此同时，你现在可以给单个路由分配专属的静态代理。当某些 Telegram 账号需要一个可预测、稳定的出口 IP，而不希望在代理池中轮换时，这一点非常有用。
管理后台中的代理健康监控
后台任务现在会周期性探测每一个代理，并更新它的健康状态。这意味着管理后台反映的是真实的连通性状态。你可以在代理悄悄影响用户之前就发现它已经劣化，而不必等到用户提交工单才知道出了问题。
为什么代理这件事值得单独做工具
Entergram 运行在真实的个人 Telegram 账号上，每个账号都通过自己专属的代理出网。这是在一个工作区里安全承载上百个账号的前提条件：账号之间不共用出口，也就不会互相牵连。代理一旦成为产品的基础组件，它就必须像数据库一样被观测和运维，而不是一个装好就不再过问的黑盒。本周的这两项功能，把"代理是否健康""哪条路由在吃带宽""这个账号今天走的是哪个出口"从工程师的排查过程变成了后台里可直接查看的状态。
性能：大型工作区更快也更稳
面向高并发工作区的 ws-v2 稳定化
大型工作区（在多个已连接账号下拥有数百个聊天的那种）此前会出现明显的主线程阻塞和浏览器卡顿。本周我们重做了 ws-v2 连接引擎，对 account.bind 的突发调用做了节流，并为 folder.chats.fetch 请求设置了节奏控制。结果是：一次此前会产生 692 个长任务、约 166 秒主线程阻塞的 QA 场景，现在可以干净地加载完成。
"需要重新连接"徽标不再误报
在繁忙的工作区里，即使后端的 MTProto 会话仍然存活并正常收发流量，账号也可能显示"需要重新连接／已断开"的徽标。看到提示的操作员点了重新连接，就会触发不必要的重新登录，某些情况下还会让该手机号撞上 Telegram 的 FLOOD_WAIT 限制。现在这个徽标只在确实存在连接问题时才会出现。
修复：消息与聊天
语音消息可以播放了。 收到的语音消息此前会静默失败，点击播放按钮没有任何反应。现已在所有聊天类型中修复。（DEV-133）
"Socket closed"错误已解决。 多个工作区会遇到带 chat.subscribe 上下文错误的硬断开。底层的套接字重连逻辑现已稳定。（DEV-120）
超级群与频道历史可以正确加载。 在超级群中导航时，前端发送了网关无法识别的对端提示（entity_class_name），导致 history.around 路径报出"Invalid realtime command payload"。已在网关层修复。（DEV-168、PRODUCT-121）
聊天或转发过程中页面不再卡死。 一类会让操作员在对话中途被迫刷新的冻结问题已经解决。（DEV-143）
在线状态保持一致。 聊天表格中的在线指示器与聊天窗口头部的指示器此前读取自不同数据源。现在两者共用同一份解析后的在线状态。（DEV-186）
群聊中的发送者名称正确了。 群组会话中的消息气泡有时会在内容上方显示错误的 Telegram 用户名。已在 chat_list.window.snapshot 与 live_chat_list.delta 两条路径上修复。（DEV-192）
未读数保持准确。 若干场景会让未读徽标多计，例如发送 2 条消息却显示 5 条未读。计数器现在能在重连前后正确对账。（DEV-135）
重复的消息气泡已修复。 当两个或更多已连接账号身处同一个聊天时，同一条消息可能在打开的会话中出现两次。这是前端层的渲染去重问题，并非跨账号合并的问题，现已修复。（DEV-183）
发送者兜底与表情回应操作者已解析。 聊天历史有时会把收到的消息的发送者标签显示为 other，表情回应弹层则一直停在"Loading reactions"。两者均已修复。（DEV-156）
回复之后聊天仍留在文件夹视图中。 勾选了"排除已读聊天"的文件夹，会在操作员刚发出回复的瞬间把该聊天移出，导致会话在处理过程中消失。现在文件夹会保留已回复的聊天，直到你离开该视图。（DEV-178）
MCP 可以给新联系人发消息。 当尝试向一个从未聊过的 Telegram 联系人发送消息时，MCP 集成此前会报错。首次发送现在可以正常工作。（DEV-141）
修复：连接与会话管理
失效会话可自动恢复。 会话代理的路由容量逻辑（observeRoutes）中存在缺陷，导致某些会话在挂掉之后不再重启。受影响的账号在每次请求历史或文件夹时都会返回 nats: no responders，重启代理也无济于事。这个饥饿问题已经解决，失效会话现在会自行复活。（DEV-139）
ws-v2 连接对话框不再刷屏 400 错误。 一个时序问题让账号连接的轮询循环持续查询一个并不存在的认证会话 ID，单次会话中会弹出数百条 API request failed: 400 提示。已在轮询生命周期上修复。（DEV-181）
设置页中的代理连接状态显示正常。 无论连接是否健康，访问设置页时代理指示器都会卡在"加载中"。现在它反映的是真实的实时状态。（DEV-154）
修复：工作区与新用户引导
引导流程中的邀请接受已修复。 在引导过程中粘贴工作区邀请链接的用户，可能在没有真正加入目标工作区的情况下走完流程，最终落到一个空的个人工作区，然后在"设置 → 聊天表格"导航时崩溃。邀请接受与跳转逻辑现已正确。（DEV-170）
被移除的用户不再复活。 被移除或主动退出的工作区成员，会因为一段过期的邀请链接引导会话，在每次刷新页面时被重新拉回。/api/onboarding 接口现在会先检查成员状态再决定是否加入。（DEV-175）
修复：账号设置
邮箱变更请求可以取消了。 待处理邮箱变更的取消按钮没有绑定任何动作，点击毫无反应。现在它会正确取消待处理请求。（DEV-137）
浅色主题下的聊天选中可见。 在白色／浅色主题中选择聊天行时，由于缺少对比度设计令牌，高亮几乎看不见。现已修复。（DEV-157）
修复：计费与订阅
试用期的所有者购买席位不再撞上死胡同。 在所有者尚未拥有有效付费订阅时调用 purchaseSeat() 会返回 400 OWNER_SUBSCRIPTION_REQUIRED。试用期所有者现在会看到清晰的提示，引导先完成订阅，并提供直达订阅页面的入口。（DEV-174）
订阅购买稳定可用。 由 Stripe 跳转期间会话失效引发的一类结账 401／403 认证冲突已经解决。（DEV-172）
修复：CRM 表格
媒体与视频播放不再触发限流错误。 /api/realtime/media 接口此前受一个通用的每分钟 20 次的限流器约束。浏览器视频流会针对同一文件发出多次字节范围请求，不到一秒就会触发限流。媒体请求现在会绕过这个通用限流器。（DEV-152）
搜索结果完整且稳定。 某些搜索会返回不完整的结果，或者在第一次查询时报"Telegram Search is unavailable"，而用同样的关键词再搜一次又能成功。现已修复，第一次请求就能正确返回结果。（DEV-136）
"距首条来信的时间"从 Telegram 开始计时，而不是从打开应用开始。 这个特殊列此前是从你打开 Entergram 的那一刻开始计时，而不是从 Telegram 实际收到该消息的时间。时间戳来源现已更正。（DEV-162）
这些修复串起来意味着什么
单独看，这一周的清单像是一堆零散的缺陷。把它们放在一起看，主题其实只有一个：当一个工作区里有几十上百个真实的个人 Telegram 账号时，正确性的标准会变得比单账号客户端严苛得多。
重复气泡、错误的发送者名称、错乱的未读数，这三个问题都源自同一个现实：多个已连接账号会同时身处同一个群聊。单账号的客户端永远不必处理这种情况。共享收件箱则必须在渲染层就想清楚"同一条消息被两个账号看到"到底算几条。
误报的"需要重新连接"徽标和失效会话不重启，则是同一枚硬币的两面。连接状态显示得过于悲观，人就会去点重连，进而触发真实的 Telegram 限流；连接状态显示得过于乐观，问题又会被埋起来。可用的答案只有一个：让界面显示的状态与后端会话的真实状态一致，这正是本周所做的事。
升级后建议做的三件检查
这些改动会自动生效，不需要你做任何迁移。不过在大型工作区里，有三件事值得花两分钟确认一遍：
- 过一遍连接状态。 打开设置页，确认代理指示器不再停在加载中，并核对每个账号的连接状态与预期一致。如果之前因为误报徽标反复点过重连，个别号可能仍在 Telegram 侧的等待窗口里，给它一点时间即可。
- 重新看一眼排除已读聊天的文件夹。 由于回复后不再立即移出会话，这类文件夹的实际使用体感和以前不同，值得重新评估筛选条件是否仍然合适。
- 复核依赖"距首条来信的时间"的视图。 这一列的计时起点已经更正，因此基于它的排序和筛选结果会与更新前不同，而且这次是正确的那一版。
更新日志
v0.16.0 及此前所有版本的完整更新日志，请见 Entergram 新功能页面。
