JianFeeeee
6b74862118
fix(agent): output_send 缺收件人时从输入事件自动补
## 现象（线上 2026-09-26 17:57）
用户从 QQ 私聊发来消息，agent 生成了回复也调了 output_send__qq，
但**没填 meta**：
17:57:45 qq_get_message → {user_id: 2198972886, message_type: private}
17:57:46 output_send__qq → 失败：meta 中需要 group_id 或 user_id 字段
17:58:14 output_send__qq_help → 查格式
17:58:14 output_send__qq → ok ← 靠重试成功，整轮耗时 74s
信息内核**本来就有**（输入事件里带着 user_id/group_id），却要模型从
qq_get_message 的返回里手抄进 meta。抄错就失败，失败才去查 _help。
而"回复"这件事的收件人是确定的（= 消息来源），本不该由模型负责。
运气差就不重试：同日 17:15 / 17:21 两次 `tools=[]` —— 模型压根没调
output_send，回复生成了但没发出去，日志连一行告警都没有。
## 改法
meta 缺收件人时，内核从**本轮输入事件**推导后补上。模型只需给内容。
## 边界（都刻意收窄：宁可不补，也不能补错）
- 显式传了 meta ⇒ 原样返回。主动 DM 别人等场景必须保持原行为。
- meta 里已有 group_id/user_id ⇒ 不覆盖。
- meta 是坏 JSON ⇒ 原样返回。让下游报"格式错"，而不是被静默替换成
一个模型没要求过的收件人 —— 那比报错更坏：消息会发给错的人。
- 非 qq 通道（如 webui）⇒ 不补。webui 走 ResponseCh，不过 output_send。
其余异步通道（wechat 等）不猜：猜错等于发错人。
- 输入事件里没有收件人信息 ⇒ 留空，让下游按原逻辑报"需要 user_id"。
宁可报错让模型重试，也不要编一个收件人。
- 群消息里 user_id 是**发送者**不是收件人 ⇒ group_id 非 "0" 时优先用
group_id，否则会把消息发回给群成员本人。
数字型 user_id 要按整数格式化：JSON 反序列化成 float64 时
fmt.Sprint 会得到 "2.198972886e+09"。
## 判据：7 条
私聊补 user_id / 群聊补 group_id 且不补 user_id / 显式 meta 不改写 /
已有收件人不覆盖 / 坏 JSON 不静默替换 / webui 不补 / 无信息留空（含 nil evt）。
★ 实现时我先自己写了个 payloadString，编译报错才发现包内已有更完整的
版本（memorypass.go:176，含 float64/int64/int/json.Number 分支），
直接复用 —— 不重复造轮子。
全量 42 包绿。
2026-09-26 18:29:23 +08:00
..
2026-09-19 16:49:16 +08:00
2026-09-15 07:47:16 +08:00
2026-09-11 11:45:24 +08:00
2026-09-26 16:19:10 +08:00
2026-09-15 06:32:36 +08:00
2026-09-15 06:32:36 +08:00
2026-09-11 11:45:24 +08:00
2026-09-13 12:23:28 +08:00
2026-09-15 09:27:39 +08:00
2026-09-19 17:43:16 +08:00
2026-08-18 09:07:21 +08:00
2026-09-15 09:03:36 +08:00
2026-09-15 09:16:22 +08:00
2026-09-13 09:06:50 +08:00
2026-09-14 23:14:38 +08:00
2026-09-13 15:41:07 +08:00
2026-09-13 15:35:59 +08:00
2026-09-15 09:37:29 +08:00
2026-09-15 09:37:29 +08:00
2026-07-28 11:42:29 +08:00
2026-09-15 08:13:52 +08:00
2026-09-11 13:45:25 +08:00
2026-09-11 13:45:25 +08:00
2026-09-11 11:45:24 +08:00
2026-09-13 00:25:52 +08:00
2026-09-13 10:36:04 +08:00
2026-09-15 08:13:52 +08:00
2026-09-15 09:37:29 +08:00
2026-09-04 06:25:51 +08:00
2026-09-04 06:25:51 +08:00
2026-09-19 17:47:44 +08:00
2026-09-19 17:43:16 +08:00
2026-09-13 09:13:19 +08:00
2026-09-26 18:29:23 +08:00
2026-09-13 16:04:16 +08:00
2026-09-26 18:29:23 +08:00
2026-09-12 13:57:06 +08:00
2026-09-12 13:57:06 +08:00
2026-09-19 16:49:16 +08:00
2026-08-18 09:07:21 +08:00
2026-09-19 11:57:50 +08:00
2026-09-19 16:49:16 +08:00
2026-09-13 14:34:44 +08:00
2026-09-11 20:31:50 +08:00
2026-09-10 23:59:12 +08:00
2026-09-15 08:13:52 +08:00
2026-09-13 15:09:44 +08:00
2026-09-13 20:19:37 +08:00
2026-09-19 17:43:16 +08:00
2026-09-19 17:47:44 +08:00
2026-09-15 09:37:29 +08:00
2026-09-13 08:59:15 +08:00
2026-09-14 09:05:14 +08:00
2026-09-13 07:00:51 +08:00
2026-09-13 07:18:03 +08:00
2026-09-13 07:00:51 +08:00
2026-09-14 10:39:25 +08:00
2026-09-13 06:10:44 +08:00
2026-09-13 07:00:51 +08:00
2026-09-13 07:00:51 +08:00
2026-09-13 07:31:32 +08:00
2026-09-13 07:00:51 +08:00
2026-09-19 17:47:44 +08:00
2026-09-10 20:36:39 +08:00
2026-09-13 08:59:15 +08:00
2026-09-13 08:59:15 +08:00
2026-09-03 12:37:58 +08:00
2026-07-24 14:49:08 +08:00
2026-09-19 16:49:16 +08:00
2026-09-12 14:56:25 +08:00
2026-09-19 17:43:16 +08:00
2026-09-18 11:39:04 +08:00
2026-09-19 16:49:16 +08:00
2026-09-19 16:49:16 +08:00
2026-09-13 06:24:20 +08:00
2026-09-13 07:00:51 +08:00
2026-09-13 06:17:49 +08:00
2026-09-18 11:26:12 +08:00
2026-09-17 18:56:15 +08:00
2026-09-17 18:56:15 +08:00
2026-09-19 14:24:31 +08:00
2026-09-25 14:45:08 +08:00
2026-09-26 16:19:10 +08:00
2026-09-26 16:19:10 +08:00
2026-09-14 16:45:04 +08:00
2026-09-26 16:19:10 +08:00