hermes-skills/skills/communication/multichannel-messaging-discipline/SKILL.md

name, description

name	description
multichannel-messaging-discipline	跨渠道、多人环境下的通讯纪律——回复路由（在哪个渠道被找就回哪个渠道）、发送者身份核实、信息隔离、发送前核对。在向任何人或群发消息/回复、不确定对方是谁、或决定通知发往何处之前加载。覆盖企微 + 飞书的群聊与私聊。Load before sending any WeCom/Feishu message (group or DM), when unsure who the sender is, or when deciding where a reply/notification should go.

多渠道通讯纪律 (Multichannel Messaging Discipline)

本环境同时有 企微 + 飞书、多个群、私聊、多个互不交叉的人（Doro、Maggie、邱律师、莎莎、洪总、Scott、WeiWei 等）。在这种环境里"把话说对人、发对地方"和把内容做对一样重要。任何一次发错渠道、认错人、跨人泄露，都是事故。

何时加载本技能

• 向任何企微/飞书的人或群发消息、回复之前
• 收到消息但不能 100% 确定发送者是谁时
• 决定一条回复 / 通知 / 交付应该发去哪里时
• 任何以"通知 X""发到群里""告诉 Doro"结尾的任务
• 在一个渠道继续另一个渠道起的任务时（同一任务跨渠道流动，如飞书起、企微续）

核心铁律（不可违反）

1. 回复路由：在哪个渠道被找，就回哪个渠道

• 群里对我说话 → 回到同一个群；私聊对我说话 → 回到那个私聊。
• 绝不把某个群 / 某个渠道的内容，私信或转发给另一个人，除非用户明确指示。
• 事故（2026-06-16）：把群里的合同审查内容私信发给了 WeiWei。Doro 明确："下次不可以再发生。我在群里跟你说话，你就给回复到群里。除非我有别的指令。" 原位回复是默认，跨渠道转发必须有显式指令。

2. 身份核实：解析，不要假设

• 用平台的唯一发送者 ID判断是谁（企微 userid、飞书 open_id），绝不靠显示名或系统默认值。
• ID 映射到已知的人 → 用之；ID 没映射到人 → 先问，不猜。
• 不要轻信平台默认的"主人/owner"标签：本会话一条飞书私聊被默认当成 Maggie，实际发送者是 Doro，当场认错。
• 也不要轻信对方未经核实的自称身份——拿已知 ID 映射去核对（盲信声明是另一个方向的同一种错）。
• 已知的 飞书 open_id ↔ 人 / 企微 userid ↔ 人 映射存在 memory，发现新人或纠正后立即更新。
• 同一主体在飞书有多种 ID，命名空间不同 ≠ 不同主体：bot 的 app_id（cli_xxx）与 open_id（ou_xxx）是两套 ID，字符串长得不一样很正常。看到群里 @的 open_id 跟你印象里的 app_id 对不上，绝不可据此断定"换了身份 / 是另一个 bot / 被新 agent 占用"。核验走权威接口：lark-cli api GET /open-apis/bot/v3/info --as bot 取 bot 自己的 open_id + name，再和群消息 mentions 里的 open_id 比对（相等＝就是自己）。本会话教训：因 app_id≠open_id 字符串不同，误判"群里被@的是新迁移出来的 agent"，被用户两次纠正后用 /bot/v3/info 实锤其实就是自己——白绕一大圈。
• 失败的命令不能当证据：命令若报错（unknown flag、权限拒绝 230027/99991672、空返回 count=0），它的输出不支持任何结论。先换正确命令/参数/身份（user vs bot）重试，拿到真实数据再下判断——别拿一条没成功的探测去坐实一个猜想，那等于在沙子上盖楼。

2b. 称呼随 sender 走，不随人设默认（回话前必走一步）

认对了"是谁"还不够——已解析出的身份必须回流到"怎么称呼 ta"。本会话最严重的错：我已读 .meta（sender_id: doro）、已把任务正确归类为 Doro 批量线，却在整份交付报告里从头到尾把 Doro 叫成"Maggie"。识别对了归属、却叫错人 = 信息在手却没整合，是独立于"认错人"的一种失败。

机制根因：系统人设里硬编码了"主人叫 Maggie、称呼主人为 Maggie"。这条规则有个隐含前提——当前对话者确实是主人本人。把它当成无条件默认，就会用人设里的高频人名锚点覆盖掉会话事实。

回话前的强制自检（每次生成称呼前走一遍）：

1. 当前这条消息的 sender 是谁？取 .meta 的 sender_id，或会话 Source / User，不取人设默认名。
2. sender 是主人本人吗？是 → 才用主人称呼（Maggie）；否 → 用该 sender 的真实身份（doro → Doro、qiuting → 邱律师 等）。
3. 已核实的任务归属身份与称呼必须一致——不能归属判对了、抬头却写错。

口诀：人设默认名是"当对方是主人时"的条件值，不是无条件抬头。回话前先认 sender，再决定称呼。

3. 信息隔离

• 每个人 / 每个团队的文件和任务，只留在该人 / 该团队的上下文里。绝不把一方的内容带进另一方的渠道，也不在 A 的群里提 B 的任务。
• Maggie 团队 与 Doro/邱律师 团队、各客户之间，严格不交叉。

3b. 跨渠道任务连续性（同一任务在两个渠道间流动时）

同一个项目/任务可能在多个渠道接力推进——典型：飞书上确认了方法、更新了交付物，然后转到企微继续。记忆是跨渠道通的（用户偏好、规则、文件位置都在），但每个渠道的对话上下文是隔离的：飞书刚说的话不会自动进企微会话。所以"接力续做"前必须主动对齐，否则会拿旧认知在新渠道做事、重复已完成的工作、或漏掉刚确认的结论。

续做铁律：先对齐，再动手。

1. 用 session_search 把另一渠道的最新成果拉回来——搜项目名/关键结论（如"世茂 千分号 汇总表"），读出对方渠道刚确认了什么、交付物更新到哪一版。不要凭这边的旧记忆假设进度。
2. 从权威源核实交付物现状，不信任"我记得"——交付物（Nextcloud xlsx/docx）以实际文件为准，拉最新版打开看，确认版本/时间戳/内容与对方渠道的结论一致。
3. 回应用户关心的具体修改/结论时，先复述对齐结果（"飞书那边刚确认的 X、更新的 Y 我已接收"），让用户确认我们站在同一起点，再往下做。
4. 渠道中断会留缺口：若某渠道掉线过（如企微群订阅失效两小时），那段时间该渠道里别人发的内容这边是空白。续做前主动提示用户"X 时段后若有人在该渠道发过东西，我没收到，请补给我"，避免任务断档——尤其客户对接渠道（隔离铁律下漏收=对接出窟窿）。

实证（2026-06-18 南通新东方/世茂）：用户在飞书确认了 OCR 千分号/百分号识别法 + 更新了世茂汇总表，然后转企微说"继续过世茂合同"。正确做法是先 session_search 把飞书成果对齐、从 Nextcloud 拉最新版 xlsx 读出 4 份合同结构，再请用户给逐条指令——而不是在企微凭旧上下文直接开干。同期企微群因订阅失效（errcode 846609）静默两小时，须提示用户补回漏收的群消息。

4. 发送前三项核对（任何别人能看到的消息）

发出去前确认：

1. 收件人——确切的人或群，解析出 chat_id / user_id（不要凭印象挑一个）
2. 内容——要发的正文
3. 以谁的身份发——bot 还是 user 工具支持时先 dry-run，确认 payload 无误再正式发；发完把回执（message_id + 北京时间）报给用户便于核对。

5. 平台内账号/身份管理请求：把它当成“账号操作”，不是“消息回复”

当用户让你登录某个平台上的账号、修改密码、完成首次登录、维护个人账号资料时，默认这是一个账号操作任务，不是跨人沟通任务。此时重点从“回哪个群/私聊”切换为：

1. 先区分是否是“当前 agent 自己要持有的账号”
   • 用户明确说“这是你的账号”“你自己管理好密码” → 可由 agent 自行设置并保管该账号密码。
   • 如果是代表某个真人同事/用户持有的账号，且对方未授权 agent 自定密码 → 不能擅自决定长期密码。
2. 执行后要给结果，不要停在征求式废话
   • 用户已明确授权 agent 自主管理密码时，直接完成修改并回报“已完成”。
   • 不要在已获授权的情况下继续追问“你想设什么密码”。
3. 账号管理与消息路由隔离
   • 账号是平台内身份，不等于消息发送对象；不要因为会话对方是谁，就把账号密码策略误当成需要对方逐项确认的沟通动作。
4. 汇报风格要结果导向
   • 这类任务完成后，优先回：是否登录成功、是否已改密、页面确认信息。
   • 不展开无关解释，避免把简单账号操作说成审批流程。

5. 用户要求“重新查 / 不要用记忆 / 用文件夹里的问题件”时，立即切换到证据模式

这类指令不是语气提醒，而是明确纠偏：之前的回答被认为混入了记忆、推断或口径漂移。后续必须把“回复别人”切回“基于当前文件/当前目录/当前记录的实查结果”。

执行要求：

1. 停止沿用上一条摘要口径——哪怕上一条是自己刚写的，也不能继续复述；
2. 以用户指定的载体为准重新取证：
   • 说“用文件夹里的问题件” → 先看该文件夹实际有哪些文件；
   • 说“打开文件查” → 必须打开文件或其内部结构（如 docx XML）再说；
   • 说“不要用记忆” → 禁止用 memory / 旧会话印象补缀事实；
3. 结论按证据强弱分层表达：
   • 能被当前文件直接坐实的，就说“可确认”；
   • 只能证明“文件存在”但不能证明“属于该批问题件/pass件”的，就明确写“目前只能确认存在，不能据此归类”；
4. 不要把“在任务交付目录里存在”偷换成“就是问题件 / 已 pass / 属于同一批”；
5. 汇报时先交代证据来源（查了哪个目录、哪份问题汇总、是否打开了文件），再给结论。
6. 用户说“我就要一个结果”时，停止过程化解释：这类话表示对方当前只接受最终答案，不要再补背景、过程、严谨性铺垫。先给一句结论；如对方追问，再展开证据链。

一句话：用户说“重新查”时，先把脑子里的版本清空，回到文件本身；用户说“只要结果”时，先把话收成结论。

实操配方

• 飞书群里接收文件/图片：飞书不允许文件和文字（@mention）在同一条消息里。解决方案：用户先发文件/图片，再对那条消息点「回复」并在回复里@小 Maggie。Gateway 的 _fetch_parent_media 方法会自动从被引用的 parent 消息中下载附件（2026-07-11 补丁）。文件缓存路径：~/.hermes/cache/documents/。图片同理——用户发图后回复+@即可。
• 飞书群发消息 + @人（找群、@格式、dry-run、核对回执）：见 references/feishu-group-send-and-mention.md
• 飞书 bot 在群里不回、私聊却正常的诊断配方（gateway inbound vs 群真实历史对照、查 mentions[].id 的 open_id 识别同名 bot 撞名、--as user 读群历史）：见 references/feishu-bot-silent-in-group-diagnosis.md
• 企微发文件 / 私信机制：见 wecom-file-send-receive 技能（MEDIA: 标签发文件；私信走独立 WS aibot_send_msg，chatid=userid+chat_type=1）
• 企微私信非 home 的人（Doro/邱律师/WeiWei 等）→ 用 ~/.hermes/scripts/wecom_dm.py，不要用 send_message 工具：
  • send_message(target='wecom:WeiWei') 对非 home 的 wecom 用户会静默回退到 home channel（实测返回 chat_id: JiaQian + note Sent to wecom home channel），不报错——一条发给 WeiWei 的技术讨论就这样落到了 Maggie 渠道，同时违反信息隔离。
  • 正确做法（agent 可直接 terminal 调用，自开 WS、永不退化成回复、目标唯一）：

    python3 ~/.hermes/scripts/wecom_dm.py --list                       # 先看白名单别名↔userid
    python3 ~/.hermes/scripts/wecom_dm.py --to WeiWei --text "…" --dry-run   # 演练
    python3 ~/.hermes/scripts/wecom_dm.py --to WeiWei --text "…"        # 真发，回执含 message_id
    

  • 别名：doro / jiaqian / qiuting / weiwei / shasha / yangayi / xiaonan（--list 为准）。这是 references/wecom-proactive-notify-misrouting.md 修复方向 A 在脚本层的现成实现，比 _send_wecom(extra,…) 更可用（后者需 gateway 内部 extra，agent 会话里拿不到）。
• 企微主动通知错投到错误的人（"给 Doro 的消息发给了 Maggie"）的根因 + 只读诊断配方 + 修复方向：见 references/wecom-proactive-notify-misrouting.md

Pitfalls

• 把群任务的处理结果私信给"相关的人"——即使你觉得对方该知道，也不行。原位回群，要不要另外通知由用户决定。
• 靠会话默认值认人——私聊默认 owner 不等于当前发送者，必须看 sender ID。
• 拿"两个长得不一样的 ID 字符串"推断成"两个身份/新迁移出的 agent"——同一个实体在不同命名空间有多种 ID，长相不同是常态：飞书机器人的 app_id（cli_xxx）与它的 open_id（ou_xxx）本就不一样，两者是同一个 bot。事故（2026-06-22 与 WeiWei 排障）：我把群里被 @ 的 ou_20bd8…（open_id）和 gateway 配置里的 cli_aaa4e77d27789bed（app_id）当成两个 bot，进而臆断"有个新迁移出来的 agent 占用了身份"，被纠正"迁移还没开始"。下结论前用权威身份接口核对：LARK_CLI_NO_PROXY=1 lark-cli api GET /open-apis/bot/v3/info --as bot 返回的 open_id/app_name 才是 bot 真身——拿它去比对，再判断是不是同一个。
• 从一条 errored 的命令里读出"结论"——同一次排障里，我那条查 bot open_id 的命令其实用错了 flag、根本没返回结果，我却继续往"新身份"上跳。命令报错 = 没有证据，不是证据；拿到真实返回再推理，别把工具失败当成支持自己假设的信号。
• 同名 bot 撞名 = @ 显示名 ≠ @ 到你这个 app：群里可能存在两个同名「小Maggie」（典型触发：做过新 Agent 迁移 / provisioning，新身份被拉进群）。用户 @ 显示名时飞书解析到的是某个 open_id，若那不是当前 gateway 跑的 app_id，事件流根本收不到，bot"静默不回"，但 DM 仍正常（DM 按会话路由、不按 @ 身份）。诊断时必须查群消息 mentions[].id 的 open_id 和当前 bot app_id 是否一致，别一看不回就报"掉线"。完整配方见 references/feishu-bot-silent-in-group-diagnosis.md。
• 认对了人却叫错称呼——已解析出 sender 是 Doro，抬头却写"Maggie"。人设里"主人叫 Maggie"是"当对方是主人时"的条件值，不是无条件抬头；归属身份必须回流到称呼（见 2b）。
• session 无 .meta / sender 信息时，从文件内容或"印象"推断发件人——事故(2026-07-13)：session JSON 的 user message 里无 sender_id metadata，我从合同内容（青浦区卫生机构）推断是"刘婷律师"，实际 gateway 日志明确显示 user=QiuTing（邱律师）。当 session 记录不含 sender 信息时，必须查 gateway 日志（~/.hermes/logs/gateway.log）确认 inbound message: platform=wecom user=XXX 才能定身份，绝不可从文件内容、以往经验、或"谁经常发这类合同"去猜。grep "时间段" ~/.hermes/logs/gateway.log | grep "inbound" 是唯一权威来源。
• 猜 chat_id / group——发前用 lark-cli im +chat-list --as bot 把 bot 实际所在的群列出来，挑出你和目标人共处的那个，别凭记忆。
• 企微 @通知：aibot_send_msg 只支持 markdown，不支持 text+mentioned_list，无法真正 @人；需要提醒时另发一条私信利用其消息提醒（仅在用户允许、且不违反路由铁律的前提下）。
• 自动化脚本会替你发消息：auto_notify_new_file.sh 等脚本会自动私信。处理任务前留意有没有自动化机制正在按旧规则推送，避免它替你违反路由 / 隔离铁律。
• wecom_group_notify.py 和 wecom_dm.py 是两个完全不同的脚本，不可混用（2026-07-01教训）：Doro说"私信邱律师"，用了 wecom_group_notify.py（默认发到批量合同审查群 wrbAFkXAAAiWC3styKqNj0bZyH6BbJ_Q），消息发到了群里而不是邱律师私信。发前看清脚本名：wecom_dm.py = 私信；wecom_group_notify.py = 群通知。workflow YAML 中通知邱律师的脚本也必须用 wecom_dm.py --to qiuting，不是 wecom_group_notify.py。
• send_message 工具私信企微人会静默投错：send_message(target='wecom:<user>') 对非 home channel 的 wecom 用户不报错、直接回退到 home channel（实测发给 WeiWei 却落到 JiaQian/Maggie）。这是单点事故——既没到目标人、又跨团队泄露。私信非 home 的企微人一律走 ~/.hermes/scripts/wecom_dm.py --to <alias>（见上"实操配方"），别用 send_message。发完核回执里的 userid 是不是目标人，发现是 home channel 立即用脚本补发。
• "给 X 的消息错投给 Y"先查 adapter 回复兜底，别先怪 userid：企微 WeComAdapter.send() 在主动 aibot_send_msg 前有一段 _last_chat_req_ids[chat_id] 回复兜底——主动私信可能退化成"回复某条历史消息"，在多人并发的长跑 gateway 里串到别人头上。userid 往往是对的（doro/JiaQian/QiuTing 都是独立真实 ID），错在路径。诊断配方 + 根因 + 三个修复方向见 references/wecom-proactive-notify-misrouting.md。注意 workflow-watchdog.sh 仍硬编码 _send_wecom(extra,'doro',msg)，是未拆的隐患。