feat(zcode): 邮件驱动 —— 收到来信就自动开工，并把结论回信
第三步（补齐一等 Agent 的另一半）：驱动进程订阅 SSE，按邮件起一轮 headless
ZCode，取最终文本回信。
## --mode 是必传的（不传等于关掉授权系统）
ZCode 的权限判定里 `mode === "yolo"` 一律 allow
（"Yolo mode bypasses permission prompts"），而 `--prompt` 的默认 mode **就是 yolo**。
所以驱动不传 --mode 时：授权钩子根本不会触发，整个授权系统**静默消失** ——
不报错，只是没有任何询问，看起来一切正常。
档位映射（依据是 CLI 产物里的规则表，不是猜）：
plan → --mode plan （mode.plan.nonReadOnly：非只读一律拒）
workspace → --mode build（mode.build.highRisk / sideEffect：Bash/Write/Edit → ask）
full → --mode yolo （刻意绕过）
buildRunArgs 收不到 mode 直接抛错；测试里有一条反向对照钉住「只有 full 能得到 yolo」，
含大写 FULL（共用库 normalizeMode 严格匹配，落回 default 而不是 yolo —— 好性质，也钉住）。
## 一轮怎么跑
node <zcode.cjs> --prompt <提示词> --output-format stream-json \
--cwd <工作目录> --mode <m> [--resume sess_xxx] --max-turns N
用 stream-json 而不是 --json：`--json` 全程无输出，一个卡住的回合与一个正在
干活的回合在外部完全一样，而邮件驱动的会话没有界面，日志是唯一能看见它的地方。
输出契约（逐条事件 + 末尾 {type:"result",sessionId,response}）同样逆自 CLI 产物。
会话延续靠 --resume + 存回的 sess_…：丢了它模型每封信都从零开始。
## 回信策略（与另三桥同源）
- 人来信 → 自动把本轮最终文本回过去（relay:'summary' + relay_key 走免配额通道）
- Agent 来信 → **不**自动回（Agent 间必须自己 send_mail，否则两边把对方的
「已收到」当待办，无限客套）
- 一轮跑不起来 → **必回**失败信，且给出 ZCode 自己的成因（没登录/缺模型配置/
CLI 路径不对）。没有本地界面时，什么都不发等于「信发出去了，然后再无音讯」。
刻意不复用共用库那份 renderFailureReport：它的建议是「调整可用模型范围」，
对 ZCode 什么也解决不了。
- 模型这一轮自己发过信 → 让位。工具跑在 ZCode 派生的 MCP 服务器**进程**里，
与驱动内存不通，所以经 lib/explicit-sends.mjs 落盘对齐（不记的后果线上实测过：
收件箱里两封说同一件事的邮件，311 与 342 字节）。
## 两处健壮性（都是实现时自己发现的真问题）
- 超时必须**必然** settle：既不退也不报错的孩子会让 Promise 永不 settle，
而队列是串行的 → 那封信永远挂住、后面的信全都不再被处理。
现在 SIGTERM → SIGKILL → 无论如何收尾；定时器刻意不 unref
（unref 过的定时器让「没有其它句柄」的进程直接退出，收尾根本没机会跑）。
- 关停时终止在途回合：否则 systemd 杀掉驱动后那个 ZCode 还在跑工具，
而既没有驱动看着它、也没有本地界面看着它。
## 自报强制力只声明得出来的事
驱动启动时读自己的 hooks/hooks.json，确认 PermissionRequest 已注册才报 native，
否则报 advisory 并在日志里写明原因 —— 不替一个不存在的能力背书。
## 验证
- 单元 320/320（新增 90 项：turn-mode 8、zcode-run 17、driver 19、prompt 14 +
继承的共用测试；含反向对照）
- 邮件驱动端到端 7/7 × 3 次连跑稳定：桩 CLI 替掉 ZCode，真网关真邮件 ——
SSE 订阅、去重、工作目录、档位映射、参数拼装（--mode 必须对）、
stream-json 解析、回信、Agent 来信不回、CLI 失败必回失败信
- 授权桥端到端 5/5 × 3 次连跑稳定
- 共用模块四方同源（新纳入 catchup/relay-dedup/relay-policy/workspace，
反向验证：让 workspace.js 分叉会被抓住）
## 我自己写错并被测试抓出来的三处（值得记）
1. 验证脚本把人类发信写成了 /api/v1/mail/send（**Agent** 路由）→ 401。
报错「Missing Authorization: Bearer …」其实已经指明走错了路由表。
2. findReply 按「驱动验证（人）」这种片段找，第二次跑时命中了**上一轮遗留的回信**
→ 正文比对失败、后续参数核对变成「无法判定」。收件箱是跨轮次共享的持久状态，
必须按唯一 marker 定位（与之前「待决权限列表」那次是同一类错误）。
3. 停旧驱动只发 SIGTERM 不等退出 → 新旧两个驱动同时订阅 SSE，
同一封信被回两次，判据取到哪封取决于时序 → 时灵时不灵。改成等 exit 事件。
另：桩脚本用 process.exit 截断管道写入，导致 stderr 时有时无 —— 改用 exitCode。
This commit is contained in:
74
plugins/zcode-mail-bridge/lib/catchup.js
Normal file
74
plugins/zcode-mail-bridge/lib/catchup.js
Normal file
@ -0,0 +1,74 @@
|
||||
/**
|
||||
* 启动补拉：把插件离线期间到的邮件变成与 SSE 事件同形的投递任务。
|
||||
*
|
||||
* 为什么需要它：**SSE 只推连上之后的事件**。插件重启前发来的邮件不会再推一次，
|
||||
* 心跳响应的 `pending_mails` 是唯一线索。不补拉的后果是那封邮件永远躺在
|
||||
* 收件箱里，而发件人以为 Agent 收到了 —— 这比明确的失败更难排查。
|
||||
*
|
||||
* 两个平台共用，必须逐字节相同（deploy/check-shared-libs.sh 校验）。
|
||||
*/
|
||||
|
||||
/**
|
||||
* 一次补拉最多处理几封。
|
||||
*
|
||||
* 上限存在的理由：每封都要起一轮模型。攒了 80 封的时候一次性全放出去，
|
||||
* 等于对上游打 80 个并发请求，且最后那几封要等前面全部跑完。
|
||||
* 超出的部分留在收件箱里，下次重启或人工触发时再处理。
|
||||
*/
|
||||
export const MAX_CATCHUP = 5;
|
||||
|
||||
/**
|
||||
* 把收件箱里的一封邮件转成 SSE `new_mail` 那个形状。
|
||||
*
|
||||
* 补拉与 SSE 走同一条投递路径（deliverMail），因此形状必须一致 ——
|
||||
* 两条路径各写一遍投递逻辑的话，某一条上的修复会漏掉另一条。
|
||||
*
|
||||
* @param {any} mail `/mail/inbox` 返回的一行
|
||||
* @returns {{mail_id: string, session_id: string, from_name: string,
|
||||
* subject: string, mail_type: string, role: string,
|
||||
* to_workspace: string, catchup: true}}
|
||||
*/
|
||||
export function mailToEvent(mail) {
|
||||
return {
|
||||
mail_id: mail?.mail_id || '',
|
||||
session_id: mail?.session_id || '',
|
||||
from_name: mail?.from_name || '',
|
||||
subject: mail?.subject || '',
|
||||
mail_type: mail?.mail_type || 'normal',
|
||||
role: 'to',
|
||||
to_workspace: mail?.to_workspace || '',
|
||||
// 标记来源，投递侧可据此决定是否在提示词里说明「这是积压的邮件」
|
||||
catchup: true,
|
||||
};
|
||||
}
|
||||
|
||||
/**
|
||||
* 从收件箱挑出该补投的邮件。
|
||||
*
|
||||
* @param {any[]} mails `/mail/inbox?status=unread` 的结果
|
||||
* @param {Set<string>} seen 已经通过 SSE 投过的 mail_id（避免重复投递）
|
||||
* @param {number} [max] 上限，默认 MAX_CATCHUP
|
||||
* @returns {any[]} 与 SSE 事件同形的投递任务，按时间正序（老的先处理）
|
||||
*/
|
||||
export function selectCatchup(mails, seen, max = MAX_CATCHUP) {
|
||||
if (!Array.isArray(mails) || mails.length === 0) return [];
|
||||
|
||||
const picked = [];
|
||||
for (const m of mails) {
|
||||
const id = m?.mail_id;
|
||||
if (!id) continue;
|
||||
// 心跳与 SSE 建连之间有个窗口：那期间到的邮件既在 pending_mails 里、
|
||||
// 也会被 SSE 推一次。不去重就会投两遍，模型回两封信。
|
||||
if (seen && seen.has(id)) continue;
|
||||
// permission 类邮件不补投：它是给人看的询问，Agent 侧没有可恢复的上下文
|
||||
// （原来的工具调用早随进程一起没了），投过去只会让模型困惑。
|
||||
if (m?.mail_type && m.mail_type !== 'normal') continue;
|
||||
picked.push(m);
|
||||
}
|
||||
|
||||
// 收件箱按时间倒序返回，补投要按正序 —— 先来的先处理，
|
||||
// 否则同一会话里的多封邮件会被倒着塞进去，上下文顺序是乱的。
|
||||
picked.reverse();
|
||||
|
||||
return picked.slice(0, Math.max(0, max)).map(mailToEvent);
|
||||
}
|
||||
107
plugins/zcode-mail-bridge/lib/explicit-sends.mjs
Normal file
107
plugins/zcode-mail-bridge/lib/explicit-sends.mjs
Normal file
@ -0,0 +1,107 @@
|
||||
/**
|
||||
* 「模型这一轮自己发了信」的记录 —— MCP 服务器写，驱动读。
|
||||
*
|
||||
* # 为什么不能直接用共用的 relay-dedup
|
||||
*
|
||||
* `lib/relay-dedup.js` 的记录活在**进程内**（一个 BoundedMap）。在 pi 桥那里
|
||||
* 工具与转发在同一个进程里，这没问题；但在 ZCode 这里，工具跑在 ZCode 派生出来的
|
||||
* **MCP 服务器进程**里，而转发决定由**驱动进程**做 —— 两个进程，内存不共享。
|
||||
*
|
||||
* 不修这个的后果是线上实测过的：模型自己带着附件发了一封，驱动又把它的收尾话
|
||||
* 转了一遍，收件箱里出现两封说同一件事的邮件（311 与 342 字节），
|
||||
* 而其中带附件的那封才是模型真正想发的。
|
||||
*
|
||||
* 所以这里只做一件事：把记录落成 JSONL，让驱动能把「本轮发过什么」重建成
|
||||
* 共用判据要的形状（`{names:Set, replyTos:Set}`），判定仍然交给
|
||||
* `shouldSkipAutoRelay` —— 判据不能各平台自己写一份。
|
||||
*
|
||||
* # 位置必须两端一致
|
||||
*
|
||||
* 驱动起 ZCode 时把自己的环境传下去，ZCode 再起 MCP 服务器时继承同一份，
|
||||
* 于是两边解析出同一个路径。解析顺序见 `explicitSendsFile`：
|
||||
* 与授权表的 `grantsFilePath` 同构（都优先 AGENTMAIL_CONFIG_DIR）。
|
||||
*/
|
||||
|
||||
import { readFileSync, writeFileSync, renameSync, mkdirSync } from 'node:fs';
|
||||
import { dirname, join } from 'node:path';
|
||||
import { homedir } from 'node:os';
|
||||
import { addrName } from './relay-dedup.js';
|
||||
|
||||
/** 超过这个条数就重写文件，只留最近的。记录本身是「本轮」级别的，留太多没意义。 */
|
||||
const MAX_LINES = 500;
|
||||
|
||||
export function explicitSendsFile(env = process.env) {
|
||||
if (env.AGENTMAIL_ZCODE_SENDS_FILE) return env.AGENTMAIL_ZCODE_SENDS_FILE;
|
||||
if (env.AGENTMAIL_CONFIG_DIR) return join(env.AGENTMAIL_CONFIG_DIR, 'explicit-sends.jsonl');
|
||||
if (env.ZCODE_PLUGIN_DATA) return join(env.ZCODE_PLUGIN_DATA, 'explicit-sends.jsonl');
|
||||
return join(homedir(), '.agentmail-zcode', 'explicit-sends.jsonl');
|
||||
}
|
||||
|
||||
/**
|
||||
* 记一条「模型自己发的信」。
|
||||
*
|
||||
* 失败**不能**让 send_mail 失败：信已经发出去了。最坏后果是驱动多转一封总结，
|
||||
* 而服务端的 relay_key 幂等还会兜一层。
|
||||
*/
|
||||
export function noteExplicitSendFile(file, { sessionId, to, replyTo, ts } = {}) {
|
||||
if (!sessionId || !to) return false;
|
||||
const line = JSON.stringify({
|
||||
session_id: String(sessionId),
|
||||
to: String(to),
|
||||
reply_to: replyTo ? String(replyTo) : '',
|
||||
ts: Number.isFinite(ts) ? ts : Date.now()
|
||||
});
|
||||
try {
|
||||
mkdirSync(dirname(file), { recursive: true });
|
||||
let lines = [];
|
||||
try {
|
||||
lines = readFileSync(file, 'utf8').split('\n').filter(Boolean);
|
||||
} catch {
|
||||
lines = [];
|
||||
}
|
||||
lines.push(line);
|
||||
// 有界：这个文件活到桥重启为止，条目会一直累积（见文件头注释）。
|
||||
if (lines.length > MAX_LINES) lines = lines.slice(-MAX_LINES);
|
||||
// 原子替换：驱动可能正在读，半截 JSON 会被跳过（无害，但会让去重偶尔失灵）。
|
||||
const tmp = `${file}.tmp-${process.pid}`;
|
||||
writeFileSync(tmp, `${lines.join('\n')}\n`, 'utf8');
|
||||
renameSync(tmp, file);
|
||||
return true;
|
||||
} catch {
|
||||
return false;
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* 读回某条会话在 `since` 之后的主动发信记录。
|
||||
*
|
||||
* @param {string} file
|
||||
* @param {{sessionId: string, since?: number}} opts
|
||||
* @returns {{names: Set<string>, replyTos: Set<string>}} 直接可交给 shouldSkipAutoRelay
|
||||
*/
|
||||
export function readExplicitSends(file, { sessionId, since = 0 } = {}) {
|
||||
const out = { names: new Set(), replyTos: new Set() };
|
||||
if (!sessionId) return out;
|
||||
let raw;
|
||||
try {
|
||||
raw = readFileSync(file, 'utf8');
|
||||
} catch {
|
||||
return out;
|
||||
}
|
||||
for (const line of raw.split('\n')) {
|
||||
const t = line.trim();
|
||||
if (!t) continue;
|
||||
let rec;
|
||||
try {
|
||||
rec = JSON.parse(t);
|
||||
} catch {
|
||||
continue; // 写了一半的行：跳过
|
||||
}
|
||||
if (rec?.session_id !== String(sessionId)) continue;
|
||||
if (since && Number(rec.ts) < since) continue;
|
||||
const name = addrName(rec.to);
|
||||
if (name) out.names.add(name);
|
||||
if (rec.reply_to) out.replyTos.add(String(rec.reply_to));
|
||||
}
|
||||
return out;
|
||||
}
|
||||
70
plugins/zcode-mail-bridge/lib/relay-dedup.js
Normal file
70
plugins/zcode-mail-bridge/lib/relay-dedup.js
Normal file
@ -0,0 +1,70 @@
|
||||
// 自动转发去重的纯逻辑。
|
||||
//
|
||||
// 单独一个文件而不是放在 index.js 里导出：**opencode 会把插件入口模块的
|
||||
// 每一个导出都当成插件工厂**（`Object.values(mod)` 逐个检查是不是函数），
|
||||
// 多导出一个 Map 就会让整个插件加载失败：
|
||||
// ERROR message="failed to load plugin" error="Plugin export is not a function"
|
||||
// 实测踩过 —— 插件静默不加载，邮件全都投不进去。
|
||||
// 因此入口文件只能 `export default`，其余东西一律搁在这里。
|
||||
|
||||
import { BoundedMap, MAX_TRACKED_SESSIONS } from './bounded.js';
|
||||
|
||||
/** 取三维地址的名字段：admin@root.alias -> admin */
|
||||
export function addrName(addr) {
|
||||
return String(addr || "").split("@")[0].trim();
|
||||
}
|
||||
|
||||
/**
|
||||
* 本轮内模型**自己调 send_mail** 发出去的信（按 opencode 会话）。
|
||||
*
|
||||
* session.idle 的自动转发要据此让位：模型已经亲手回过这条线索了，
|
||||
* 再把它最后那段话转一遍，收件箱里就是两封内容几乎一样的邮件。
|
||||
* 生产实测过这个后果 —— 同一轮里 311 字节和 342 字节各一封，
|
||||
* 说的是同一件事，其中带附件的那封才是模型真正想发的。
|
||||
*
|
||||
* 为什么不靠 relay_key 幂等：那个键是 assistant message id，
|
||||
* 保证的是「同一条消息不被转两次」，管不了「模型已经自己发过了」。
|
||||
*
|
||||
* 窗口是「一轮」：deliverMail 投递新邮件时清空（新一轮开始），
|
||||
* relaySummary 用完即清。
|
||||
*
|
||||
* # 为什么仍要有界
|
||||
*
|
||||
* 上面那些清理路径都要求「这个会话之后还有事发生」。一条只发过一次信、
|
||||
* 之后既没有新邮件也没有 idle 的会话（模型自己发完就没动静了，或者插件在
|
||||
* 那一轮之后重连），条目就永久留下。桥是常驻进程，这种残留会一直累积。
|
||||
*
|
||||
* 淘汰是安全的：条目的语义是「本轮已经亲手回过」，而「本轮」是分钟级的。
|
||||
* 丢掉一条很久以前的记录最坏结果是那条会话下一次 idle 时多转一封总结，
|
||||
* 而服务端的 relay_key 幂等还会兜一层。
|
||||
*/
|
||||
export const explicitSends = new BoundedMap(MAX_TRACKED_SESSIONS); // opencode session id -> { names:Set, replyTos:Set }
|
||||
|
||||
/** 记下模型这一轮主动发了信，给谁、回的哪封。 */
|
||||
export function noteExplicitSend(sessionID, to, replyTo) {
|
||||
if (!sessionID) return;
|
||||
let rec = explicitSends.get(sessionID);
|
||||
if (!rec) {
|
||||
rec = { names: new Set(), replyTos: new Set() };
|
||||
explicitSends.set(sessionID, rec);
|
||||
}
|
||||
const name = addrName(to);
|
||||
if (name) rec.names.add(name);
|
||||
if (replyTo) rec.replyTos.add(String(replyTo));
|
||||
}
|
||||
|
||||
/**
|
||||
* 本轮是否该跳过自动转发。
|
||||
*
|
||||
* @param sent 该会话本轮的主动发信记录 { names:Set, replyTos:Set }，可为空
|
||||
* @param replyTo 自动转发本来要发给谁（三维地址或纯名字）
|
||||
* @param mailID 自动转发本来要 reply_to 的邮件 id
|
||||
*/
|
||||
export function shouldSkipAutoRelay(sent, replyTo, mailID) {
|
||||
if (!sent) return false;
|
||||
// 收件人同名：模型已经跟这个人说过了
|
||||
if (sent.names.has(addrName(replyTo))) return true;
|
||||
// 同一封信已被回过：即使收件人写法不同（别名/路径不同）也算回过
|
||||
if (mailID && sent.replyTos.has(String(mailID))) return true;
|
||||
return false;
|
||||
}
|
||||
120
plugins/zcode-mail-bridge/lib/relay-policy.js
Normal file
120
plugins/zcode-mail-bridge/lib/relay-policy.js
Normal file
@ -0,0 +1,120 @@
|
||||
// 自动转发的**适用范围**，以及据此该给模型说什么话。
|
||||
//
|
||||
// 单独一个文件而不是放在入口里导出：**opencode 会把插件入口模块的每一个导出
|
||||
// 都当成插件工厂**（`Object.values(mod)` 逐个检查是不是函数），多导出一个函数
|
||||
// 就会让整个插件加载失败。因此入口只 `export default`，判断逻辑一律搁在这里。
|
||||
//
|
||||
// # 为什么 Agent → Agent 不自动转发
|
||||
//
|
||||
// 自动转发存在的理由是「人不该等模型记得调 send_mail」：人发一封信出去，
|
||||
// 模型把活干完、话说完，插件替它把结论搬进邮件。收件方是人时这是纯收益。
|
||||
//
|
||||
// 收件方是**另一个 Agent** 时这个理由不成立，而且有害：对方的插件同样会自动
|
||||
// 回一封，于是两个模型都以为「我只要把话说完就行」，实际上在持续互相唤醒。
|
||||
// 生产实测过一条完整的客套链（pi 转发给 dsh，dsh 回确认，pi 又确认那个确认，
|
||||
// 一直到第 6 封撞上连续 relay 跳数上限才停）：
|
||||
//
|
||||
// pi→dsh parent=24be32e5 转发
|
||||
// dsh→pi parent=bf79f8fe 已收到转发
|
||||
// pi→dsh parent=2700bd0a 收到你的确认
|
||||
// dsh→pi parent=34127884 确认闭环
|
||||
// pi→dsh parent=34058c13 …
|
||||
// dsh→pi parent=9590bf16 ← 被 hop 上限拦下
|
||||
//
|
||||
// 每一封都不是错的，每一封都没有新信息。跳数上限是最后一道闸，不是设计意图。
|
||||
//
|
||||
// 因此规则是：**Agent 之间通信必须由模型主动调 send_mail。**
|
||||
// 插件不再代它开口 —— 该说话的时候它会说，没什么要说的时候就该安静。
|
||||
//
|
||||
// 副作用是好的：模型必须自己决定「这值得回一封信吗」，而那正是它该做的判断。
|
||||
|
||||
/** 取三维地址的名字段：admin@root.alias -> admin */
|
||||
export function addrName(addr) {
|
||||
return String(addr || "").split("@")[0].trim();
|
||||
}
|
||||
|
||||
/**
|
||||
* 这一轮的结论该不该由插件自动转发出去。
|
||||
*
|
||||
* @param {object} ctx
|
||||
* @param {boolean} ctx.fromHuman 来信方是人类用户（SSE 的 `from_human`）
|
||||
* @param {string} [ctx.replyTo] 自动转发本来要发给谁
|
||||
* @returns {{relay: boolean, reason: string}}
|
||||
* reason 供日志用 —— 「本轮没有回信」必须能在日志里查到原因，
|
||||
* 否则它与「模型没说话」「转发失败」三种情形长得一样。
|
||||
*/
|
||||
export function autoRelayDecision(ctx) {
|
||||
const { fromHuman, replyTo } = ctx || {};
|
||||
if (!replyTo) {
|
||||
return { relay: false, reason: "不知道回给谁" };
|
||||
}
|
||||
if (!fromHuman) {
|
||||
return {
|
||||
relay: false,
|
||||
reason: `来信方 ${addrName(replyTo)} 是 Agent，按约定不自动转发（Agent 间通信须由模型主动 send_mail）`,
|
||||
};
|
||||
}
|
||||
return { relay: true, reason: "" };
|
||||
}
|
||||
|
||||
/**
|
||||
* 提示词里关于「回信怎么发」的那句话。
|
||||
*
|
||||
* 必须与 `autoRelayDecision` 一致 —— 这是同一件事的两个出口，分开写必然分叉。
|
||||
* 而分叉的代价是模型被骗：它以为插件会替它回信，于是把话说完就停手，
|
||||
* 而实际上那封信永远不会发出去，发件方一直等着。
|
||||
*
|
||||
* @param {object} ctx
|
||||
* @param {boolean} ctx.fromHuman
|
||||
* @param {string} [ctx.replyAddress] 服务端算好的回信地址
|
||||
* @returns {string[]} 若干行，直接拼进提示词
|
||||
*/
|
||||
export function replyInstruction(ctx) {
|
||||
const { fromHuman, replyAddress } = ctx || {};
|
||||
if (fromHuman) {
|
||||
return [
|
||||
"**回信不用你自己发**：把这一轮做完、把结论说出来就行，",
|
||||
"插件会在这一轮结束时把你最后那段话作为回信发回去（不消耗你的发信配额）。",
|
||||
"只有在需要主动联系其他人、或要带附件时才调用 send_mail。",
|
||||
];
|
||||
}
|
||||
return [
|
||||
"**这封信来自另一个 Agent，插件不会替你回信。**",
|
||||
"需要回复时你必须自己调用 send_mail" +
|
||||
(replyAddress ? `（回信地址：${replyAddress}）` : "") + "；",
|
||||
"把话说完并不会让对方收到任何东西。",
|
||||
"也请先判断这封信是否真的需要回复 —— 单纯的「收到」「确认」会让两个 Agent",
|
||||
"无休止地互相客套，那对谁都没有价值。有实质结论或有事要问时才回。",
|
||||
];
|
||||
}
|
||||
|
||||
/**
|
||||
* 描述「进来的这封是什么」。
|
||||
*
|
||||
* 在此之前提示词一律说「你收到一封新邮件」，于是模型分不清三种处境：
|
||||
* 有人派了新活、我上封信的回复到了、离线期间积压的补投。
|
||||
* 第二种被当成第一种时，模型会把一句「已收到」当成待办再处理一遍。
|
||||
*
|
||||
* @param {object} ctx
|
||||
* @param {string} [ctx.inReplyTo] 非空 = 这是对本方某封信的回复（SSE 的 `in_reply_to`）
|
||||
* @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 who = fromHuman ? "" : "（对方是一个 Agent）";
|
||||
if (inReplyTo) {
|
||||
// 「回复到了」与「有人派活」是两种处境。说清楚它，模型才不会把
|
||||
// 一句确认当成新任务 —— 那正是互相客套的起点。
|
||||
return `你上一封信的**回复**到了${who}。这不是新任务。`;
|
||||
}
|
||||
if (catchup) {
|
||||
return `你收到一封新邮件${who}。说明：这是插件离线期间积压的邮件，现在补投给你。`;
|
||||
}
|
||||
if (reused) {
|
||||
return `本会话收到一封新邮件${who}。`;
|
||||
}
|
||||
return `你收到一封新邮件${who}。`;
|
||||
}
|
||||
@ -36,6 +36,7 @@ import {
|
||||
} from './discovery.js';
|
||||
import { normalizeAttachmentIDs } from './attachment-ids.js';
|
||||
import { uploadLocalFile, downloadToFile } from './gateway.mjs';
|
||||
import { explicitSendsFile, noteExplicitSendFile } from './explicit-sends.mjs';
|
||||
|
||||
/** 正文在列表里的截断长度（与另三端一致）。 */
|
||||
const BODY_LIMIT = 200;
|
||||
@ -190,6 +191,17 @@ export function buildTools({ client, agentName }) {
|
||||
if (ids.length) payload.attachment_ids = ids;
|
||||
|
||||
const result = await client.post('/mail/send', payload);
|
||||
|
||||
// 记下「模型自己发了信」—— 驱动据此决定要不要再自动转发本轮收尾话。
|
||||
// 两边是两个进程（工具跑在 ZCode 起的 MCP 服务器里），只能经文件对齐；
|
||||
// 不记的后果是收件箱里出现两封说同一件事的邮件（线上实测过）。
|
||||
noteExplicitSendFile(explicitSendsFile(process.env), {
|
||||
sessionId: process.env.AGENTMAIL_SESSION_ID || result?.session_id || '',
|
||||
to,
|
||||
replyTo: str(a.reply_to),
|
||||
ts: Date.now()
|
||||
});
|
||||
|
||||
const parts = [`邮件已发送（ID: ${result?.mail_id ?? '?'}`];
|
||||
if (result?.session_id) parts.push(`，会话: ${result.session_id}`);
|
||||
if (result?.session_alias) parts.push(`，别名: ${result.session_alias}`);
|
||||
|
||||
77
plugins/zcode-mail-bridge/lib/workspace.js
Normal file
77
plugins/zcode-mail-bridge/lib/workspace.js
Normal file
@ -0,0 +1,77 @@
|
||||
/**
|
||||
* 邮件寻址里的工作目录（三维地址 name@path.session 的 path 位）。
|
||||
*
|
||||
* 这个模块存在的理由是一次真实故障：插件建会话时用的 cwd 是自己拼的
|
||||
* `~/.dsh/mail-sessions/mail-<uuid>` —— 每封邮件一个全新的空目录。
|
||||
* DSH 与 opencode 都按 cwd 给会话分组，于是所有邮件会话既不属于任何项目、
|
||||
* 彼此也不同组，界面上全落进「未分组」。
|
||||
*
|
||||
* path 位本来就是「希望它在哪儿干活」，插件只需照用。
|
||||
*/
|
||||
|
||||
import { existsSync, mkdirSync, statSync } from 'node:fs';
|
||||
import { homedir } from 'node:os';
|
||||
import { isAbsolute, join, resolve } from 'node:path';
|
||||
|
||||
/**
|
||||
* 校验寻址里的工作目录，不可用时返回调用方给的兜底。
|
||||
*
|
||||
* 决策顺序：
|
||||
* 1. path 位是一个已存在的目录 → 直接用它（同 path 的多封邮件天然同组）
|
||||
* 2. path 位非空但目录不存在 → **不创建**，返回兜底
|
||||
* 3. path 位为空（地址写成 `dsh` 而不带 `@/path`）→ 兜底
|
||||
*
|
||||
* 为什么不给不存在的 path 建目录：那等于让一个笔误（`/home/porgram/x`）
|
||||
* 在磁盘上落下一个真目录，而 Agent 会在里面一无所获地干活 ——
|
||||
* 用户看到会话建起来了却什么都做不了，比明确落到兜底目录更难排查。
|
||||
*
|
||||
* 为什么拒绝相对路径：cwd 的相对基准是 harness 进程的启动目录，
|
||||
* 那是个与邮件语义无关的量（systemd 下通常是 `/`）。
|
||||
*
|
||||
* 兜底由调用方给，因为各平台的兜底不同：opencode 有插件启动时的 directory
|
||||
* 可用，DSH 没有、只能落到 `~/.dsh/mail-sessions/<会话>`（见 mailSessionFallback）。
|
||||
*
|
||||
* @param {string} workspace 事件里的 to_workspace
|
||||
* @param {string} fallback 不可用时的兜底目录（可为空串 = 交给平台自己决定）
|
||||
* @returns {{cwd: string, grouped: boolean}} grouped 为真表示落在了寻址指定的目录里
|
||||
*/
|
||||
export function resolveWorkspaceCwd(workspace, fallback) {
|
||||
const raw = typeof workspace === 'string' ? workspace.trim() : '';
|
||||
const fb = typeof fallback === 'string' ? fallback : '';
|
||||
|
||||
if (!raw || !isAbsolute(raw)) return { cwd: fb, grouped: false };
|
||||
|
||||
const abs = resolve(raw);
|
||||
try {
|
||||
if (existsSync(abs) && statSync(abs).isDirectory()) {
|
||||
return { cwd: abs, grouped: true };
|
||||
}
|
||||
} catch {
|
||||
// 权限不足等：当作不可用
|
||||
}
|
||||
return { cwd: fb, grouped: false };
|
||||
}
|
||||
|
||||
/**
|
||||
* 没有天然兜底的平台（DSH）用这个：`~/.dsh/mail-sessions/<会话 id>`。
|
||||
* @param {string} sessionKey 会话标识
|
||||
* @returns {string}
|
||||
*/
|
||||
export function mailSessionFallback(sessionKey) {
|
||||
return join(homedir(), '.dsh', 'mail-sessions', String(sessionKey || 'default'));
|
||||
}
|
||||
|
||||
/**
|
||||
* 确保兜底目录存在。寻址指定的目录本来就存在（否则不会被选中），
|
||||
* 只有兜底目录需要现建。
|
||||
* @param {string} cwd resolveWorkspaceCwd 的结果
|
||||
* @param {boolean} grouped 是否落在寻址指定的目录里
|
||||
*/
|
||||
export function ensureCwd(cwd, grouped) {
|
||||
if (grouped || !cwd) return;
|
||||
try {
|
||||
mkdirSync(cwd, { recursive: true });
|
||||
} catch {
|
||||
// 建不出来就让 harness 自己报错，这里不该吞掉真实原因
|
||||
}
|
||||
}
|
||||
Reference in New Issue
Block a user