jianf/MailUI4Agents
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fix(notify+四桥): ★ 投递通知带 parent_from（方向判据）—— in-reply-to-ignores-direction 转绿

Browse Source 
为什么这次顺手修：网关部署门禁（redeploy-gateway.sh 跑全量 Go 测试）被
TestInReplyToCarriesParentSender 拦下 —— 那是 2026-09-28 判据先行的债，
死锁修复本身无涉，但不修它网关换不上去。已用 git worktree 在修复前的
HEAD（16bf474）上验证过该测试原本就红，不是本次改动引入。

服务端（数据本来就在手，零新增查询）：
  · resolveTarget 的 reply_to 分支原本把父邮件整行读进内存、只用 SessionID
    就丢掉；现在把 mail.FromName 一并返回。
  · notify.Mail 增 ParentFrom；payload 增 "parent_from"。
  · 转发 / 人类发信（me.go）路径如实传 ""（转发本就是新线索）。

四桥（relay-policy.js 四份逐字相同的拷贝 + 各自调用点）：
  · inboundHeadline 增方向判据：parentFrom === selfName 才说
    「你上一封信的回复到了」；parentFrom 非空但≠自己 ⇒ 明说
    「多方线索里的续谈（回的那封是 X 发的）」；服务端未升级（无
    parent_from）⇒ 退回旧行为（含糊的「回复到了」强于把真回复当新任务
    —— 那是互相客套的起点，回退语义被既有判据钉死）。
  · 「回的是你那封：<id>」一行同样只在父邮件确为本方发出时才输出。
  · 四份 lib + 四份 test 逐一 md5 相同（cross-bridge-prompt 1/2/3/4 继续绿），
    判据 5 转绿。

红绿：
  · 服务端 TestInReplyToCarriesParentSender 修复前红（16bf474 实测）、修复后绿；
  · 四桥新增 3 条方向判据测试（别人发的 / 自己发的 / 未升级回退）；
  · client/electron 聚合套件 cross-bridge-prompt 5/5 绿。
This commit is contained in:
dsh
2026-09-30 17:30:27 +08:00
parent 974bf2a62f
commit b0c87192b0
14 changed files with 273 additions and 32 deletions
Download Patch File Download Diff File Expand all files Collapse all files

25
plugins/zcode-mail-bridge/lib/relay-policy.js
View File

@ -37,6 +37,8 @@ export function addrName(addr) {
* 这一轮的结论该不该由插件自动转发出去。
*
* @param {object} ctx
* @param {string} [ctx.parentFrom] 父邮件的发件人（服务端 parent_from）；空=非回信或未升级
* @param {string} [ctx.selfName] 本方名字（收件方自己），用于方向判据
* @param {boolean} ctx.fromHuman 来信方是人类用户（SSE 的 `from_human`）
* @param {string} [ctx.replyTo] 自动转发本来要发给谁
* @returns {{relay: boolean, reason: string}}
@ -65,6 +67,8 @@ export function autoRelayDecision(ctx) {
* 而实际上那封信永远不会发出去，发件方一直等着。
*
* @param {object} ctx
* @param {string} [ctx.parentFrom] 父邮件的发件人（服务端 parent_from）；空=非回信或未升级
* @param {string} [ctx.selfName] 本方名字（收件方自己），用于方向判据
* @param {boolean} ctx.fromHuman
* @param {string} [ctx.replyAddress] 服务端算好的回信地址
* @returns {string[]} 若干行，直接拼进提示词
@ -97,17 +101,36 @@ export function replyInstruction(ctx) {
*
* @param {object} ctx
* @param {string} [ctx.inReplyTo] 非空 = 这是对本方某封信的回复（SSE 的 `in_reply_to`）
* @param {string} [ctx.parentFrom] 父邮件的发件人（服务端 parent_from）；空=非回信或未升级
* @param {string} [ctx.selfName] 本方名字（收件方自己），用于方向判据
* @param {boolean} ctx.fromHuman
* @param {boolean} [ctx.catchup] 离线期间积压后补投的
* @param {boolean} [ctx.reused] 投进一条已存在的会话（续谈）
* @returns {string} 提示词第一行
*/
export function inboundHeadline(ctx) {
const { inReplyTo, fromHuman, catchup, reused } = ctx || {};
const { inReplyTo, parentFrom, selfName, fromHuman, catchup, reused } = ctx || {};
const who = fromHuman ? "" : "（对方是一个 Agent）";
if (inReplyTo) {
// 「回复到了」与「有人派活」是两种处境。说清楚它，模型才不会把
// 一句确认当成新任务 —— 那正是互相客套的起点。
//
// ★ 还必须有**方向**判据（2026-09-30 修，in-reply-to-ignores-direction）：
// 只有 inReplyTo 时只能判断「这是回信」，分不清回的是**谁**的信。
// 单向续信链（8 封全是 opencode → pi）同样满足「有父邮件」，曾被逐封
// 宣称「回的是你那封」，把纯单向链读成双向对话。服务端现在在载荷里
// 带父邮件发件人（parent_from）；`parentFrom === selfName` 才是
// 「我上一封信的回复到了」，否则是多方线索里的他人续谈 —— 当新输入。
// 服务端未升级（无 parent_from）时退回旧行为，不比原来更差。
const mine = parentFrom != null && parentFrom !== "" && selfName != null && parentFrom === selfName;
if (mine) {
return `你上一封信的**回复**到了${who}。这不是新任务。`;
}
if (parentFrom != null && parentFrom !== "") {
return `这是多方线索里的**续谈**（回的那封是 ${parentFrom} 发的，不是对你上一封信的回复）${who}。`;
}
// 服务端未升级（无 parent_from）时退回旧行为：含糊地说「回复到了」
// 也强于让模型把一封真回复当新任务再处理一遍 —— 那是互相客套的起点。
return `你上一封信的**回复**到了${who}。这不是新任务。`;
}
if (catchup) {