[Feature][Telegram] 支持独立管理 Bot，并通过程序强制限制管理操作的调用者和范围

[aelf-hzz780]

背景与目标

商户希望使用具有 Telegram 群管理员权限的 Bot 执行删除消息、封禁成员等操作，同时保证：只有指定管理员或获授权的后台流程，才能在指定群执行获授权的管理动作。

建议支持独立管理 Bot：客服 Bot 负责问答；管理 Bot 作为受限执行身份使用。推荐第一版通过商户后台或受控工具入口调用，不开放管理 Bot 的 Telegram 聊天指令入口。商户自行维护 Skill 中的业务规则，平台提供可配置、持久且不可绕过的授权保证。

例如：管理员 A 可以删除群 X 的消息，但不能封禁成员，也不能操作群 Y。普通群成员即使发送管理指令、伪装管理员或诱导模型，也不能触发管理操作。

为什么仅靠 Skill 无法满足需求

仅靠 Skill 可以跑通正常流程，但不能可靠保证“未授权账号无论发送什么内容，都不能执行管理操作”。

如果只在 Skill 中写“仅允许指定账号操作”，权限判断仍由模型理解和遵守。模型一旦判断错误，只要后续工具没有强制拦截，操作就可能执行。Telegram 最终检查的是 Bot 自身的权限，不会替商户应用检查最初提出要求的人是否在白名单中。

层次	已有作用	本需求需要补齐或明确保证的内容
Skill	描述业务规则，指导模型判断和选择动作	未授权操作必须由程序拒绝，不能只依赖模型遵守指令
消息路由	决定消息进入哪个 Agent	入站路由不是管理操作授权；重绑和修复不能扩大管理入口
NyxID 服务与操作授权	控制服务访问、API 操作及审批等	将可信调用者与目标群、操作对象和具体动作关联校验
Telegram	检查 Bot 的实际权限	应用自身负责检查谁有权让 Bot 使用这些权限

关键缺口是管理 API 执行前的业务授权闭环。例如，允许调用 deleteMessage 并不自动意味着“管理员 A 只能删除群 X 的消息”：还需要验证可信发起人，以及请求参数中的目标群、目标消息和动作范围。

Skill 附带校验脚本可以成为实现方式，但必须保证所有管理调用都经过它、调用者身份来自可信上下文，且模型无法通过其他工具或通用 proxy 绕过。此时权限保证来自必经的程序约束；仅要求模型“先运行校验脚本”仍不足以满足需求。

严重程度与影响

当读取普通用户内容的 Agent 同时可以使用管理凭据，而调用者及操作范围仅靠 Skill 限制时，这是管理能力上线前应解决的高风险授权缺口。

可能后果包括：

• 普通消息、转发内容或提示注入被模型错误当作授权，触发未授权删除或封禁。
• 合法管理员的操作超出获授权的群、对象或动作范围。
• Skill 更新、重新绑定或路由修复后，原有入口限制失效。
• 误删内容无法通过 Bot 恢复，误封影响正常用户使用。

实际影响范围取决于 Bot 的权限、可访问群和已有代理限制。当前核查支持“缺少可依赖的强制保证”，尚未端到端复现具体越权攻击；本 Issue 是 feature request，不声称已确认线上漏洞或事故。

功能需求

1. 独立执行模式。 管理 Bot 可仅作为 Telegram API 执行身份使用，无需接入公开聊天 Agent。绑定、重启、重新绑定和路由修复均应保持该模式，不得意外创建或恢复公开聊天兜底路由。
2. 受保护的权限配置。 配置允许的调用者、目标群和管理动作。MVP 可使用受保护的服务端配置，无需先建设完整权限管理页面。配置缺失或无法校验时不执行管理操作。
3. 执行前强制校验。 每次操作根据可信身份校验目标群、目标消息或成员及动作范围，拒绝越权请求。后台/API 入口的身份来自认证上下文，不能信任消息正文、用户名或模型自行填写的身份参数。
4. Skill 与权限分离。 Skill 可维护垃圾识别标准、处理建议和何时需要确认；更新 Skill 不得扩大调用者、群或动作的授权范围。允许这些权限变化必须走独立受保护的配置流程。
5. 限制管理凭据的全部执行路径。 面向公众的客服 Agent 不得经其他工具、通用 proxy 或可访问的服务凭据绕过管理授权。可复用既有工具权限、服务 scope 和操作策略，并在管理动作执行前补足业务校验；不要求禁用系统其他用途的通用 proxy。
6. 可追踪。 记录调用者、目标群、操作对象、动作、授权判定和执行结果，附 Trace ID 或等价追踪标识；日志不得暴露管理凭据。

若复用现有审批机制，需保证审批针对的调用者、群、对象和动作与最终执行一致；审批后的操作参数不能被替换。

第一版范围与后续扩展

• 推荐 MVP： 独立管理 Bot + 已认证的后台/受控工具入口 + 必经的受限执行器 + 权限配置与必要审计。后台调用者身份与 Telegram user ID 不是天然同一身份，需由入口明确认证和授权。
• 可选后续入口： 指定管理员通过 Telegram 私聊下令。此时应使用平台验证的 from.id，同时保留入站限制和执行端授权；可信身份缺失时拒绝执行。
• 业务后续扩展： 自动垃圾识别、人工确认及规则更新。群消息可以作为待分析数据，但不能产生管理授权；自动执行的授权来自管理员预先批准的规则。
• 本 Issue 不要求： 通过 Telegram 修改 Skill、自动学习规则，或一次性实现完整的垃圾审核和人工确认会话。

平台升级前，商户也可自行使用已认证后台和必经执行器约束独立管理 Bot。本需求希望将这套能力标准化，避免每个商户自行补齐授权边界。

现有实现与实现关注点

以下基于已核查的 Aevatar feature/integrate@e3fde8e0fa7526d58c8e050fa2a9f71dfbb33349 与 NyxID main@d104ce89b768fd83164ae0216413d0e64384591f，不等同于确认线上部署状态：

• Aevatar Bot adoption 创建 default_agent=true 的路由；路由修复/rebind 同样设置该值。独立执行模式需要贯穿这些生命周期，不能只靠首次手工调整路由。
• NyxID 路由实现 依次匹配 bot+chat+sender、bot+chat、bot default。仅增加 sender-specific 路由不能自动阻止其他 sender 落入宽泛路由。
• NyxID 已有 service-only Telegram API proxy 等基础能力；现有 proxy_operation_policy 包含 HTTP method/path 规则。这些能力应复用，但不能直接等同于 Telegram 调用者、目标群和管理动作的完整业务授权。

建议将管理执行能力按 Bot 显式开启；拒绝授权时在工具执行前终止，不能以模型承诺或工具调用后的审计替代拦截。

验收标准

• 授权调用者可在指定群执行允许的管理动作，并获得真实执行结果。
• 未授权账号、伪装身份及提示注入不能触发管理 API 调用。
• 对其他群、超出授权范围的对象或未授权动作的请求被拒绝；若复用审批，篡改已批准操作参数的请求被拒绝。
• 身份或权限配置缺失、授权检查失败时，不执行管理操作。
• 更新 Skill 后，账号、群和动作权限限制保持有效。
• 重新绑定、重启或修复路由后，独立执行模式和入口限制保持有效。
• 客服 Agent 无法通过通用 proxy 或其他管理凭据访问路径绕过限制。
• 授权拒绝、执行成功和执行失败均有必要审计及追踪标识。

相关需求

• 已检索 open/closed Issues 及相关 PR，未发现直接重复的 Telegram 管理 Bot 需求。
• Refactor Channel Relay AgentKey service authority #3641：Channel AgentKey 的 NyxID 服务授权事实源，可作为服务权限基础。
• Refactor channel registration around NyxID channel bots #3652：NyxID Channel Bot 接管和绑定流程，需兼容独立执行模式。
• [Channel][Telegram] 支持按 Skill 判断群消息相关性，并以成功静默结果跳过回复 #3666：群消息相关性判断与成功静默。本 Issue 关注管理身份隔离和强制授权，可独立推进。