Files
MailUI4Agents/plugins/dsh-mail-bridge/lib
JianFeeeee 519bdf7093 fix(dsh)★: 模型写好回信却被当成「空回复」丢弃 —— lastAssistantText 取错那条事件
## 现象(用户实测)

用户看到 dsh 的回复**内容完全正常**(一段完整的「你好 jianf!收到你的问候了 👋…」),
但 AgentMail 里收到的是 dsh 发来的 `处理失败: 打招呼`,正文写着:

    这封邮件的处理轮次已结束,但没有产出任何回复文本。

## 根因(从真实会话日志取证,不是推断)

取那次会话的 `session.v4.jsonl.zstd`(zstd 解压 84KB),事件统计:

    assistant/message: 2 条        ← 两条!

    最后一条 content = [{"type":"tool-call","name":"read_mail",...}]   ← 无 text
    往前一条        = [{"type":"text","text":"邮件已读取 —— …你好的问候了 👋…"}]

dsh 的一次 step 里,模型先出文本、再发工具调用,会落成**两条**
`assistant/message`;最后那条往往只有 tool-call 块。

而 `lastAssistantText` 是「从后往前找,取到**第一条** assistant/message
就 return —— 不管那条里有没有 text 块」:

    if (!Array.isArray(blocks)) return '';      ← 直接判空
    return blocks.filter(b => b?.type === 'text')…   ← 无条件 return

⇒ 过滤后是空串 ⇒ 判定空回复 ⇒ **静默丢弃模型已经写好的回信**,
改发一封「处理失败」通知给发件人。

## 修法

`return ''` 改 `continue`;只在**真的取到文本**时才 `return`。

## 为什么既有测试全绿

原有 5 格测的**全是单条** `assistant/message`(或只有 reasoning/tool-call 的
单条),与本缺陷正交。新增 2 格用的是**从真实日志取的事件形状**:

* 最后一条只有 tool-call ⇒ 必须往前找到有文本的那条
* **反向对照**:全部无文本时**仍**返回空串,且 `content` 不是数组时应
  `continue` 而非当成空回复 —— 保证「空回复」判定没有被放宽成
  「几乎总有回复」,否则那封失败通知就没有存在意义了

**变异验证**:把实现还原成原写法 → 21 pass / **2 fail**(正是新增那两格)。

## 影响面

仅 dsh:pi / opencode 走各自宿主的 API 取回复,不共用这个函数
(实测两边的 `lib/` 里没有 `assistant/message` 字面量)。
实测那次只有 34 秒就走到失败通知,是个高频路径而非边缘情况。

dsh 435 格全绿、tsc 零错。
2026-10-03 22:24:32 +08:00
..