[Channel][Telegram] 支持按 Skill 判断群消息相关性，并以成功静默结果跳过回复

[aelf-hzz780]

需求

商户希望把 Telegram Bot 用作群内知识客服：群成员无需 @bot，Bot 根据商户维护的 Skill 判断消息是否需要回答；相关问题回复，普通闲聊保持沉默。

现有接入方式是：在 NyxID 绑定 Bot，在 Aevatar 确认绑定关系并关联 Ornn Skill。期望商户通过配置和 Skill 维护业务规则，无需自行维护另一套 Telegram 消息服务。

以 Portkey 知识客服为例：

群消息	期望行为
“Portkey 的 eTransfer 卡在 25% 了怎么办？”（不 @）	进入知识问答，按 Skill 回答或澄清
“大家午饭吃什么？”	正常处理完成，群里不出现任何 Bot 消息
引用 Bot 上一条知识答复追问“那该联系谁？”	结合引用上下文继续回答，即使没有 Portkey 关键词
其他成员接着闲聊	不因前面的知识问答而持续插话

“保持沉默”包括不发送解释性文字（例如“此问题与我无关”）、占位消息、流式片段或错误兜底；明确选择不回复应当是成功的业务结果。

当前缺口与证据

以下为源码核查，基线为 feature/integrate@e3fde8e0fa7526d58c8e050fa2a9f71dfbb33349；尚未做真实 Telegram 群验收，不将源码结论描述为已复现的线上故障。

• Telegram 群普通消息已可进入回复流程，无需 @：TelegramGroupAdmissionPolicy。
• Skill 可以描述相关性标准，但当前默认 Skill 链路没有可消费的“成功且不回复”结果。返回空文本不能替代这个结果：运行时会要求模型补答，最终仍为空时进入 empty_reply 失败并生成兜底文字：恢复逻辑、最终处理。
• 内部已有 ConversationTurnResult.Ignored，但还没有接通商户 Skill 的业务判断。

范围

第一版聚焦 Telegram 群普通文本的选择性回复，以及同一知识问答中的引用追问。保留私聊和明确系统命令的原有行为。

不包含删除消息、ban、管理员审批、通过 Telegram 修改 Skill 或 forum topic/thread 的新增支持。业务相关性标准由商户 Skill 维护；平台负责执行回复或静默结果。实现不要求修改 NyxID 或 Ornn。

验收标准

• 商户可对目标 Bot 的群消息开启选择性回复；已有 Bot 行为不会因升级被隐式改变。
• 不 @ 的相关问题正常回答；测试集中的无关闲聊不产生任何对外消息，也不因业务静默触发补答、重试或兜底。
• 无关键词的相关引用追问可以继续；其他成员闲聊不会被错误继承为同一客服对话。
• 静默结果可观测、可追踪，并完成消息去重与生命周期清理；不被记为发送成功或执行失败。
• 缺少 Skill、判定超时、无效输出和真正的空回复故障，与业务静默明确区分；保留原有非选择性回复路径的故障保障。
• 重复投递、重启恢复不会把已完成的静默消息转为回复，也不会让应回复的消息重复发送。
• 通过有/无 NyxID sender 绑定的适用账号分别验证默认 Skill 路径，并完成真实 Telegram 群测试。

查重与关联

已检索 open/closed Issues 和相关 PR，未找到覆盖此需求的重复项。以下是相关保障，不能视为本需求已经完成：

• test(channel-relay): close rich-text parse + group @-mention gate coverage gaps #2395（已关闭）：群 @ 触发规则和消息解析测试。
• test(agent-run): close empty-reply fallback + history-trim coverage gaps #2397（已关闭）：空回复一次重试与历史裁剪测试，关联 [epic] CI hard gate: inbound channel relay -> agent reply path #2394、ci(channel-relay): add anti-removal contract guard for the agent reply path #2400 和已合并 PR Add Lark agent path contract guard #2401。

新增业务静默时，应保留这些针对真实回复故障的保障。具体改法补充在后续评论。

[aelf-hzz780]

建议实现方式

建议在现有 Channel → Conversation → AgentRun 主链路中增加明确的“回复决策”，将业务相关性判断接到成功静默终态；无需另建 Bot 服务。以下名称是建议契约，不表示当前已经存在这些字段或工具。

1. 增加可选配置及强类型决策

为目标 Bot 的群消息增加 opt-in 的选择性回复模式，旧配置保持原行为。决策至少区分：

• Reply：允许进入答复生成与交付。
• Ignore：业务上无需回答，正常完成且无对外输出。
• 判定失败：沿用独立的失败契约，不伪装成 Ignore。

使用 typed/protobuf 契约承载决策、原因及来源，不依赖空字符串、NO_REPLY 文本匹配或模型说“我选择不回复”。如采用结构化模型输出，必须经过校验后映射为强类型结果。

2. 将判断放在任何对外输出之前

群消息入站、鉴权与去重
  → 读取目标 Bot 配置和本轮使用的 Skill
  → 在受限决策阶段运行商户相关性规则
      ├─ Reply → 现有答复生成、流式交付
      ├─ Ignore → 持久化成功静默结果并完成本轮
      └─ Failure → 独立失败策略与诊断

决策必须在 typing、reaction、placeholder、流式文本及消息发送工具之前完成；仅在最终发送出口过滤已经太晚。决策阶段允许必要的只读知识加载，不开放对外发送或其它副作用工具。

默认 Skill 当前依赖 prompt 要求模型加载。选择性模式应由程序确保本轮决策确实使用了目标 Skill，记录实际版本/内容摘要，不能直接凭历史答复猜测。沿用现有 Bot registration authority / Channel Agent Key 权限边界，不要求普通群成员额外绑定 NyxID，也不扩大其工具权限。

3. 复用 Actor 完成与去重机制，补通静默终态

复用 ConversationTurnResult.Ignored 已有的成功完成语义，并通过现有 Actor continuation/state/event 机制持久化本轮决策、完成去重和 pending/reply lifecycle 清理。异步模型判断通过现有执行结果与 continuation 推进，避免新增进程内状态字典或跨 Actor 同步等待。

不要将 Ignore 直接当成普通回复交付成功。 ConversationGAgent.HandleLlmReplyReadyAsync 的通用成功路径会产生 delivered/文本发送记录；静默应在进入交付路径之前分支，留下“已处理但未发送”的真实结果，不生成虚假的 LlmReplyDeliveredEvent / DeliveryProduced(TextMessage, Succeeded)。

4. 保留真正故障的恢复行为

AgentRunGAgent 对空生成的重试与兜底是已有故障保护（#2397、#2400）。不要通过“所有空回复都忽略”实现本需求。

只有经过校验的明确 Ignore 才成功静默。Skill 不可读、判定超时、无效输出仍记录 failure，采用有界恢复；选择性群聊的失败通知策略应单独定义，避免直接向群里发送通用兜底。私聊和未开启选择性模式的行为保持兼容。

5. 将群聊上下文纳入规则

相关性判断不仅看关键词，也要结合可信 sender、消息引用关系及必要的近期上下文。例如引用 Bot 答复的“那该联系谁？”仍可能相关；另一成员的午饭闲聊不能继承前人的客服上下文。第一版不扩大到尚未核验的 forum topic/thread 支持。

6. 验证与上线

先为明确静默结果补行为测试，再接入决策与交付：相关问题、闲聊、无关键词的引用追问、跨成员闲聊、Skill 加载失败、无效输出、真实空生成、重复投递和重启恢复。

关键断言：Ignore 的所有发送/流式/占位/发送工具调用次数均为 0；消息以正常静默结果完成，无补答、无伪造 delivered 事件。Reply 保持现有流式路径；原有空回复失败测试继续通过。

在单个测试 Bot 上 opt-in 验证，观察相关问题回复率、闲聊误回复、决策失败和重复发送。回滚恢复该 Bot 原配置，无需解绑 NyxID 或更换 Skill registry。执行受影响的 ChannelRuntime 测试及仓库要求的架构、测试稳定性门禁。

主要落点：Channel runtime config/proto 与管理界面、ChannelConversationTurnRunner、现有 AgentRunGAgent/ConversationGAgent 生命周期及对应行为测试。不要只放宽 TelegramGroupAdmissionPolicy 或添加一条“请保持沉默”的提示词；这两者都无法提供发送层面的保障。