Agent→Agent 不自动转发 + 提示词区分新活/回复/补投

## 设计规则:Agent 之间不自动转发

自动转发存在的理由是「人不该等模型记得调 send_mail」—— 收件方是人时这是
纯收益。**收件方是另一个 Agent 时这个理由不成立,而且有害**:双方的插件都
会自动回一封,于是两个模型都以为「我只要把话说完就行」,实际在持续互相唤醒。
生产实测 pi 与 dsh 客套 6 轮直到撞上连续 relay 跳数上限。

规则现在写死在共用模块 `lib/relay-policy.js`(三平台逐字节相同):
- `autoRelayDecision` — 插件该不该替模型开口
- `replyInstruction` — 提示词怎么跟模型说(人类 vs Agent 各一套措辞)
- `inboundHeadline` — 进来的是新活、回复、还是补投

`from_human` 缺失时保守按 Agent 处理:宁可让模型多调一次 send_mail,
也不能承诺一个不会发生的自动回信让发件方白等。

## Gateway 侧:`in_reply_to` + `from_human`

- `notify.Mail` 新增 `ParentMailID`(非空 = 这是对收件方某封信的回复)
- `notify.Mail` 新增 `FromHuman`(走 `repo.IsHumanUser`)
- SSE payload 里叫 `in_reply_to` / `from_human`
- 四个调用点全部传入:handler/mail(转发后产出的邮件,parentMailID 从
  resolveTarget 取)、handler/me(同理)、handler/forward(传空串,
  因为对收件方而言那封原邮件不在它的线索里)、scheduler/calendar(传空串)
- `ListInbox` 的 SELECT 加 `EXISTS (SELECT 1 FROM users u WHERE u.username = m.from_name)`
  → `models.Mail.FromHuman`,让补拉路径也有这个信号

## 提示词分流

三种处境各一套标题:
- 新活(人类):「你收到一封新邮件」+ 「回信不用你自己发:…」
- 新活(Agent):「你收到一封新邮件(对方是一个 Agent)」+ 「插件不会替你
  回信。需要回复时你必须自己调 send_mail…请先判断是否真的需要回复」
- 回复到了:「你上一封信的回复到了。**这不是新任务**。」
- 补投:在标题里说明「离线期间积压」

## homeagent 特殊处理

Go 插件不能直接 `import('../lib/relay-policy.js')`,因此新增 `relay_policy.go`
(Go 对应物)+ `relay_policy_test.go`(11 例,逐条对齐 Node 侧判据)。
`sseLoop` / `catchUp` 两条路径都接上。

## `mailEvent` 命名类型

homeagent 的 SSE 事件解析 / handleNewMail / handlePermissionDecision 三处
原来各写一遍匿名 struct(字段列表几乎相同),加 `from_human` / `in_reply_to`
时漏改一处 → 编译报错但错误信息是两串几乎相同的字段列表,极难定位。
提成 `mailEvent` 命名类型:一处改、三处跟着走。

## 测试

- `lib/relay-policy.test.mjs`(Node)16 例:含「replyInstruction 与
  autoRelayDecision 不得互相矛盾」「Agent 来信的标题要点名且回复要明确反对」
- `relay_policy_test.go`(Go)11 例:逐条对齐 Node 侧
- `turn.test.mjs` +3 例:from_human 缺失时按 Agent 处理 / Agent 来信时改口 /
  回复到了说「不是新任务」;删掉两条旧的「必定自动转发」断言
- 共用脚本 `check-shared-libs.sh` +1 个文件(relay-policy)
- pi 288 / dsh 241 / opencode 217 / homeagent 14 / gateway 8 包全绿
This commit is contained in:
2026-09-04 23:52:52 +08:00
parent 375578cf9b
commit 784192d8c4
22 changed files with 1315 additions and 92 deletions

View File

@ -34,6 +34,7 @@ import {
shouldSkipAutoRelay,
} from "./lib/relay-dedup.js";
import { adoptedSessionID, adoptMissingMessage } from "./lib/adopt.js";
import { autoRelayDecision, replyInstruction, inboundHeadline } from "./lib/relay-policy.js";
import { appendRenameProposal, renameProposalNote } from "./lib/rename-proposal.js";
// opencode 原生支持三态权限免批由它自己记response:"always"
// 所以这里只借用决策文本的判定,不需要 createGrantStore。
@ -706,6 +707,23 @@ async function relaySummary(client, directory, sessionID) {
if (!mailSessionID) return null; // 不是邮件驱动的会话,不碰
if (!mailDrivenSessions.has(sessionID)) return null;
// 回信地址:这轮是谁发起的就回给谁。取该会话最近一封来信的发件人。
const ctx = mailContexts.get(mailSessionID);
// **只给人类来信自动转发**(见 lib/relay-policy.js
//
// 对方是 Agent 时它那边的插件也会自动回一封,于是两个模型都以为「我只要
// 把话说完就行」,实际在持续互相唤醒 —— 生产实测 pi 与 dsh 客套 6 轮直到
// 撞上连续 relay 跳数上限。放在取消息列表**之前**判:少一次网关往返。
const policy = autoRelayDecision({
fromHuman: ctx?.fromHuman === true,
replyTo: ctx?.replyTo,
});
if (!policy.relay) {
console.error(`[mail-bridge] 本轮不自动转发:${policy.reason}`);
return null;
}
// 取最后一条 assistant 文本消息
const listed = await client.session.messages({
path: { id: sessionID },
@ -731,10 +749,6 @@ async function relaySummary(client, directory, sessionID) {
// 本地去重(服务端另有 relay_key 幂等兜底,这里只是少打一次网关)
if (relayedSummaries.get(sessionID) === last.id) return null;
// 回信地址:这轮是谁发起的就回给谁。取该会话最近一封来信的发件人。
const ctx = mailContexts.get(mailSessionID);
if (!ctx?.replyTo) return null;
// 模型这一轮已经亲手回过这条线索 → 不再自动转发。
//
// 否则收件箱里会出现两封说同一件事的邮件生产实测311 字节与 342 字节各一封,
@ -831,31 +845,44 @@ async function deliverMail(client, directory, data, kind) {
// 不清的话,上一轮亲手回过信会永久压掉这个会话之后所有的自动转发。
explicitSends.delete(sessionID);
// 记住这轮该回给谁idle 时 relaySummary 靠它决定收件人与 reply_to。
// 回信上下文idle 时 relaySummary 靠它决定收件人与 reply_to。
// 一个会话里可能来过多封信,只保留最近那封 —— 回信要落回最新的线索。
//
// 多记两个服务端信号:
// fromHuman —— 只有人类来信才自动转发(见 lib/relay-policy.js
// inReplyTo —— 这封是不是对本方某封信的回复
// 不存进上下文的话relaySummary 那一刻拿不到它们(那个函数只有 sessionID
if (kind === "mail" && data.session_id) {
mailContexts.set(data.session_id, {
replyTo: data.from_name || "",
subject: data.subject || "",
mailID: data.mail_id || "",
fromHuman: data.from_human === true,
inReplyTo: data.in_reply_to || "",
});
}
const fromHuman = data.from_human === true;
const text = kind === "permission"
? `你之前发起的权限请求已有结论:${data.decision}(决策人:${data.decided_by || "用户"})。请据此继续后续工作。`
: [
reused ? `本会话收到一封新邮件AgentMail 续谈)。` : `你收到一封新邮件AgentMail`,
inboundHeadline({
inReplyTo: data.in_reply_to,
fromHuman,
catchup: data.catchup,
reused,
}),
``,
`发件人:${data.from_name || "unknown"}`,
`主题:${data.subject || "(无主题)"}`,
`邮件 ID${data.mail_id || "unknown"}`,
...(data.in_reply_to ? [`回的是你那封:${data.in_reply_to}`] : []),
`身份:你是 ${AGENT_NAME}`,
...(data.reply_address ? [`回信地址:${data.reply_address}`] : []),
``,
`请先调用 read_inbox 读取完整正文(附带附件清单,如有附件可用 download_attachment 取回),然后处理其中的请求。`,
``,
`**回信不用你自己发**:你把本轮工作做完、把结论正常说出来就行,`,
`插件会在这一轮结束时自动把你最后那段话作为回信发回给 ${data.from_name || "发件人"}(不消耗你的发信配额)。`,
`只有在需要主动联系其他人、或要带附件时才调用 send_mail。`,
...replyInstruction({ fromHuman, replyAddress: data.reply_address }),
].join("\n");
// 按管理员划定的范围逐个尝试,全部失败才回一封说明失败原因的邮件。