|
|
a44fd6949b
|
feat: 权限档位体系（三档 plan/workspace/full + 四桥 from_session_id）
L2 核心改动：sessions 表补 permission_mode / permission_enforcement 两列
（sqlite + pg 同步），三桥 lib/permission-mode.js 翻译档位到平台原生配置，
homeagent advisory 模式提示词告知模型实际强制力。四桥全部携带 from_session_id
供 relay 去重与会话回溯。
FromHuman / ToHuman 判据已加入心跳 payload 与 notify/mail.go。
|
2026-09-06 15:16:49 +08:00 |
|
|
|
784192d8c4
|
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 包全绿
|
2026-09-04 23:52:52 +08:00 |
|
|
|
8e501f041e
|
pi 桥改为工作进程池 + homeagent 落盘投递账本
## pi 桥：模型工作下到子进程（并发模型重构）
主进程原来自己跑模型，而 pi 的会话装载是同步的：`SessionManager.open()` 走
`openSync` + `readSync` 循环把整个 `.jsonl` 读进内存并逐行 JSON.parse。实测本机
最大那条会话 23MB，`open` 一次**阻塞事件循环 118ms**；模型跑起来后 SDK 内部还有
更多同步工作。SSE 读循环在那期间完全停住 → 后续邮件卡在 TCP 缓冲区 → 久到
Gateway 认为连接死了 → 重连 → 重放。
上一轮我在几个调用点前加 `setImmediate` 是无效的仪式（让出一次之后同步工作照样
占满线程），已回退。这一轮把模型工作整体搬进子进程：实测同样的活在 fork 出的
子进程里跑，主进程事件循环阻塞 **0ms**。
- 新增 `src/worker.mjs`：一封邮件一个进程，跑完就退。权限询问期间的挂起只影响
那一个 worker（原来 `await new Promise(...)` 等人决策，整座桥不再收信）。
- 新增 `src/pool.mjs`：**不同会话并发**（上限 3，每个 worker 约 140MB RSS）、
**同一会话严格串行**（pi 假定「一文件一持有者」，两个进程同时装载同一条会话
文件会让各自的内存索引看不见对方追加的行 → 会话树分叉）、满载排队不丢邮件、
硬超时 SIGKILL 回收卡死进程。
- `src/index.mjs` 只剩 I/O 与调度：SSE、心跳、去重、分派。
- 选进程而不是 `worker_threads`：模型会跑 bash/write/edit，一次 OOM 不该带走
整座桥。两者实测都能建起 AgentSession，但线程与主线程共享堆和生命周期。
- 「接管会话短暂持有」那套机制（adopted / adoptTimers / releaseAdopted + 兜底
计时器）整个删掉 —— worker 退出**就是**释放，且普通会话与接管会话一视同仁。
- 轮次超时 60s → 10 分钟：60s 那个数字是「主进程要腾出手收下一封」的产物，
worker 没有这个理由，等真结论更准（带工具调用的一轮跑几分钟很正常）。
- IPC 只传路径与标量（sessionFile / cwd / grants / 命名指纹）—— AgentSession
跨不了进程边界，worker 每次从 sessionFile 重新装载。
`test/pool.test.mjs` +19 例，真 fork 子进程、用桩 worker（不装 SDK）跑毫秒级：
并发上限、同会话串行、不同会话真并发（判据是两个进程的心跳交错，不是 running
map 里有两个条目）、sessionFile/grants/命名指纹跨 worker 传递、config() 每次重取、
硬超时回收、权限决策路由、决策原文透传、worker 退出后清路由、mailDrivenIDs、
kind 透传、stop 先发 shutdown 再杀。跑过三组负向对照确认用例真能抓回归：
拆掉串行守卫 / 不传 sessionFile+grants / 硬超时不杀，对应用例分别失败。
## homeagent：投递去重必须落盘
用户报的重复投递不是上一轮那个 bug。两段提示词的措辞差异指出了来源：
SSE 那段写「你把本轮工作做完」，补投那段写「你把结论说出来就行」。
`deliveredMails` 是进程内的 map，而 homeagent 的插件跑在**子进程**里：
1. 18:59:38 邮件落库，旧插件进程的 SSE 收到，注入第一次
2. 同一秒 homed 被重启，那一轮被掐断（`context canceled`）
3. 18:59:45 新进程起来，`deliveredMails` 是空的
4. 心跳报 `pending_mails: 1`（第一轮没跑完 → read_inbox 没执行 → 仍未读）
→ catchUp 注入第二次
**不能只记「投过没有」**：那会把「重复」换成「丢件」—— 第 2 步里发件人没收到
回信，而记录说「已投过」→ 永远跳过。丢件比重复严重，重复至少人能看出来。
新增 `ledger.go`：JSONL 账本记两个状态。`completed` 才跳过；`delivered` 但未
`completed` 的仍然重投，但提示词前面插一段说明「上一轮被中断，别把同一件事做
两次」。落在 SDK 的 `Settings().DataDir()`；拿不到时退回 key 文件目录；目录不可
写时退化为纯内存（不比修复前差，也不该让插件起不来）。
- 判定与记录在同一把锁里：SSE 与 catchUp 两个 goroutine 的竞态
- 每行写完 fsync：这个文件的全部意义就是「进程死了之后还算数」
- 坏行跳过而不是报错退出（崩溃时最后一行可能写残）→ 那封退化为重投，安全
- 14 天保留期；过期过半时「临时文件 + rename」压实
- `shortID()` 替代 `id[:8]`：日志不该有能力 panic 掉投递协程
`ledger_test.go` +14 例，含两组负向对照（只记「投过」→ 丢件用例失败；不读账本
→ 跨进程用例失败）。
## 契约文档
`B-7.7`（MUST）：子进程形式的插件去重必须落盘且区分「投过」与「跑完」，含事故
时序、两状态表、何时标 completed。已知取舍那节标注投递账本是唯一必须落盘的状态。
验收清单加「模型跑到一半重启宿主」一项。
## 生产验证
- pi 三封 → 三条会话：三个 worker PID 并存，回信「收到 1/2/3」各落自己线索
- pi 同一会话两封：严格串行（收到A 19:26:39 → 收到B 19:26:48，全程单 worker）
- pi 主进程事件循环阻塞 1ms（旧版单进程 open 23MB 一次就 118ms）
- homeagent 正常一封：账本 `c:false` → `c:true`，一封回信
- homeagent 处理中重启：日志「上一轮被中断，带说明重投」，**只有一封 Re:**
- homeagent 再次重启：账本 2 条 completed，不再投递，会话邮件数不变
- gateway 7 包 / web 176+26 / pi 269 / dsh 219 / opencode 201 / homeagent 14
|
2026-09-04 20:33:44 +08:00 |
|
|
|
c297468819
|
修 platform_session_id 无差别下发导致抄送方邮件静默消失 + homeagent 补投漏去重
## platform_session_id 只发给归属方（Gateway）
`notify.Recipients` 原来对所有参与方推同一个 `platform_session_id`，
而那是**会话级**的一个值。生产实测：会话 16845133 接管了 pi 的平台会话
`01a05a5e-…`，那封邮件抄送了 dsh@/home/program/agentmail.new。DSH 收到
同一个 id，在 ~/.dsh/sessions/ 里查不到（那是 /root/.pi/agent/sessions/
下的文件），于是走进「平台侧会话已删」那道防线抛错。
那道防线本身是对的（N-8：不能退回新建，否则人在界面上看不到这封邮件带来
的对话），它拦下的却是「别人的会话」。异常被 ctx.logger.error 吞掉，而
DSH 的 logger 不进 journalctl —— 邮件静默消失，日志里一个字都没有。
- 新增 `repo.PlatformSessionFor` 一并返回归属 Agent：以镜像
`agent_platform_sessions.agent_name` 为准，镜像整表替换后退回
`sessions.from_agent`（AdoptPlatformSession 写在那里）
- `PlatformIDOf` 变薄封装，保留原签名
- `notify.Recipients` 加 `platformFor(forName)`：归属方以外一律空串；
归属抽不到时（owner 空）也不下发 —— 宁可退回当普通会话处理，
也不让一个抽不到归属的 id 把邮件弄丢
- 归属与收件角色无关：归属方在抄送位上同样拿到
## homeagent catchUp 漏 deliveredMails 去重
`go p.catchUp(…)` 与 `go p.sseLoop()` 是两个并发 goroutine，重启时窗口
重叠：SSE 推一次 + 补投拉一次 = 同一封邮件注入两遍。homeagent 的回信正文
印证了这一点（「之前的对话时序中已经收到并确认过多次了」）。另三个插件的
catchUp 都有这层双查，只有这里漏了。
去重放在循环内逐封查而不是拉完一批再筛：InjectInputSync 一封要跑几十秒，
那期间 SSE 完全可能已经投过后面那几封。
## DSH 接管失败改用 console.error
DSH 的 ctx.logger 不进 journalctl，投递失败是「发件人等不到回信」的唯一
线索。接管失败点与 SSE 分发的 catch 都改走 console.error，并带上 mail_id
与发件人。
## 前端 ccAddress 移除（收尾上一轮未提交的改动）
cc_list 里的 `.new` 是**原始意图**，不该被替换成主收件人的别名：每个抄送
方的 `.new` 是独立的 —— pi@/x.new 给 pi 开一条、dsh@/x.new 给 dsh 开另一
条，各有自己的别名。数据库存的就是原文。删掉 ccAddress，MailView /
ThreadView 直接显示 c.raw。
## 测试
- `internal/notify/notify_test.go` +3 例：挂真实 SSE 客户端读帧，验
归属方拿到 / 抄送方为空 / 归属方在抄送位也拿到 / 普通会话全空。
负向对照跑过：platformFor 无条件返回时两条用例失败
- `internal/repo/platform_owner_test.go` +3 例：镜像取归属、普通会话、
镜像被清后退回 from_agent
- 修好 web/test/components/replyTarget.test.tsx（上一轮遗留的语法损坏），
三条 .new 用例改成断言原样保留
- gateway 7 包全绿；web 176 例 + 主题 26；dsh 219 / pi 250 / opencode 201
## 生产验证
- 抄送验证：jianf → pi（接管会话）cc dsh。DSH 正常建会话并回信「收到」，
pi 走接管续谈 —— 两封回信都落在同一条线索上（此前 DSH 那封不存在）
- homeagent 去重：连发两轮，其中一轮在邮件未处理完时重启 homeagent 造出
SSE/catchUp 并发窗口，两轮都只产生一封 Re:
- homeagent SSE：换新 plugin.bin 后连续 89 分钟零断连（此前 2 小时 102 次
deadline exceeded 自激振荡）
|
2026-09-04 19:06:36 +08:00 |
|
|
|
e8583ecd41
|
fix: 事故全链路修复 — 调度器合流 + 接管保护 + 补全去重 + 权限显示 + homeagent SSE 振荡
## 事故现场
用户选中补全里的「项目定位」→ 邮件投进另一条会话，界面显示的名字也不是
自己选的那个。授权页只显示 Agent 名，看不出哪个目录哪条线索。
## 四处因果链
**① 调度器自己的 new_mail payload（起点）。** `notifyRecipients`（handler）
与 `SendCalendarMail`（scheduler）是两份代码。加 `platform_session_id` 时只改了
handler 那份 → 日历提醒投进接管会话时插件不知道是接管 → 另开一条新会话 →
命名同步冲掉接管会话的别名。
修法：抽出 `internal/notify` 包，唯一入口 `notify.Recipients`。
handler / scheduler / permission.go 都走它。新增字段时不存在「另一处忘了改」。
**② SyncSessionAlias 覆盖接管别名。** 别名是人从补全里选中的平台 slug，
任何平台命名同步都不该动它。加守卫 `platform_id <> ''` → 有绑定就返回当前值。
**③ SuggestSessionCandidates 按别名字符串去重。** 别名一被冲掉，同一条会话
出现两次（一次被冲的名字、一次镜像 slug），而另一条真实会话被吃掉。
改按 `platform_id` 去重。 mail 侧查 `s.platform_id`，镜像侧查 `platform_id`。
**④ FindOrCreateDefaultSession 不排除接管会话。** 日历提醒省略 session 位 →
FindOrCreateDefaultSession 挑中人显式指定的接管会话。加 `platform_id = ''` 条件。
## 权限页
**CreatePermissionMail 不写 from_workspace。** `from_workspace` 存空串 →
前端 `g.path && ...` 不渲染 → 人只看到光秃的 Agent 名，不知道哪个目录
哪条线索在请求权限。修法：INSERT 时从 sessions.workspace 取。
**SSE payload 缺 session_alias。** permission.go 的 SSE 不走 notify 包（决策人
不是地址解析出的参与方），但 payload 也要带 `session_alias` → 前端拼出
`pi@/home/program/agentmail.别名`，而不是光秃的 `pi`。
**mailGroups.ts：path ← session_workspace。** `from_workspace` 对 Agent 存的是
Agent 名（历史遗留），不能当路径用。PermissionList 显示完整三段地址
`agent@path.alias`。
## NarrowStack z-index
窄屏日历的星期表头（`sticky top-0 z-10`）穿透到二级页面之上。覆盖层
auto z-index 输给 z-10 → 底层组件的层叠穿透到覆盖层。
修法：底层容器加 `isolate`（isolation: isolate），自成层叠上下文；
覆盖层加 `z-10`。只给覆盖层加 z-index 只能治当前一处，底层再写更大的
z-index 又会复现。
## homeagent SSE 自激振荡
根因：五处缺陷叠加，SSE 每 60 秒断一次 → Gateway 全量重放 → 再断 → 再重放。
1. `p.client`（60s Timeout）跑 SSE 长连接 → 新增 `sseClient`（无超时）
2. `InjectInputSync` 在读循环里同步调用 → 改为 `go p.handleNewMail(evt)`
3. `lastEventID` 无条件赋值，Gateway 重放时发旧 ID → 单调递增 `sseMaxID`
4. 无邮件级去重 → 补 `deliveredMails map[string]bool`
5. 手动 `[]byte` 管理：每次 `buf[lineStart:]` 缩小 cap → 最终 len==cap
→ Read 零长切片 → 满速空转。改 `bufio.Reader`。
## 清库
保留 jianf + 4 个 Agent 密钥 + 模型范围配置。清掉 mails/sessions/
calendar_events/attachments/agent_platform_sessions/relayed_mails/
permission_requests/rate_limits。测试数据已全部清零。
## 测试
- gateway 7 包全过；repo + 7 例（adopt_alias_test.go）
- web 182 例（mailGroups 新增 session_workspace 断言）
- 前端构建通过
|
2026-09-04 15:35:48 +08:00 |
|
|
|
5b76ac5c57
|
feat(homeagent): 四个日程工具 + 工具计数不再硬编码
create_schedule / list_schedules / update_schedule / delete_schedule，
插件从 11 个工具变 15 个。
时间格式是这组工具最容易出错的地方，parseEventTime 接受三种形态：
完整 RFC3339（推荐）、无时区（按本机时区解释）、只有日期（当天 9 点，
比零点有用 —— 零点的提醒没人看）。
**刻意不接受自然语言**（「明天九点」）：解析它需要知道模型以为今天是哪天，
而它上下文里那个日期常常是错的 —— 一个静默偏移一天的提醒比报错糟得多。
解析失败的报文里带上当前本机时间，让它能自己算。
其他细节：
- recipients 用逗号分隔的 string 而非数组：几个平台对数组参数的 schema
支持不一致，而逗号分隔在所有平台上都是普通 string。中英文逗号都收 ——
中文输入法下打出「，」是常态。
- argInt 同时收 float64 与字符串："30" 带引号会让「提前 30 分钟」静默失效。
- update 的工具描述里写明「只传要改的字段」：模型的默认倾向是回传它记得的
全部字段，记错一个就覆盖掉原有的提醒正文或收件方。
- list 在接近上限（>=75%）时主动提示清理，而不是等撞墙 —— 撞墙那一刻
模型往往正在做别的事，没有余裕去清理。
- scheduleEvent.effectiveRecipients() 与服务端同一条兜底链：只读
recipients 会让旧数据显示成「发给：」后面空白。
**工具计数从 RegisterTool 的调用数派生，不硬编码。**
之前写死 13 而实际注册 11 —— 排查「工具没生效」时日志说 13、平台说 11，
两个数字都不可信，白花了一轮时间。加工具时忘改常量是必然的，
所以让它没有机会写错。
plugin.go 另补 put/delete 两个 HTTP 辅助（原来只有 get/post）。
已部署验证：homed 日志「注册完成（15 个工具 + 1 个输出通道）」，
模型实际调用 list_schedules 成功。
|
2026-09-04 06:28:55 +08:00 |
|
|
|
473c46659a
|
fix(homeagent): 删除 plugin.go 里与 tools.go 重复的 6 个方法
plugin.go 与 tools.go 各自声明了同名工具处理器。逐个 diff 后保留
tools.go 的版本 —— 它严格更丰富：read_thread 多 ParentHid → parent_hidden
并区分「父邮件无权查看」与「父邮件尚未加载」，suggest_address 多解析
candidates，connect_to_server 多一条注释。
plugin.go 删除 handleConnectToServer / handleForwardMail /
handleSuggestAddress / handleListContacts / handleSessionParticipants /
handleReadThread + minInt。
tools.go 删除本地 min()：go.mod 是 go 1.25.0，内置 min 可用，
本地定义只是遮蔽。
部署验证：11 项工具注册（日志里硬编码的「13 个工具」是错的数字）。
|
2026-09-03 21:11:15 +08:00 |
|
|
|
f321380fa3
|
fix: relay 死循环防护 + DSH 工作区注册修复 + homeagent 工具集补齐 + 三插件 connect_to_server
## relay 死循环防护（两道防线）
### 主防线：免配额只给发往人类的 relay（handler/mail.go）
原设计：relay 走免配额通道（harness 搬运不该算模型自主发信）。
问题：收件方是另一个同样会自动转发的 Agent 时，整个回路里没有任何
一处在计数——生产上跑出过 41 封（会话 f3d824ce），间隔从 15 分钟
缩到 5 秒，且用了 37 封才烧掉 4/20 预算。
改为：repo.IsHumanUser(to.Name) 判定。Agent→Agent 的 relay 照样扣预算。
顺带修次序问题：原来是「先占幂等键再扣预算」，预算耗尽时幂等键
已被占用，加了额度也无法重发。现在预算失败会 ReleaseRelay 还回去。
### 兜底：hop_limit 列接通（repo/relayhops.go）
schema 里早有 hop_limit INT DEFAULT 5，从未有代码读它。
CountTrailingRelayHops 从最新邮件往前扫，遇到第一封非 relay
邮件即停（中间有一封自主发信或人类插话就归零）。
5 测试：空会话 / 只数 relay / 自主发信打断归零 / 达到上限 / 按会话独立
## DSH 工作区注册修复
问题：上一轮加的 workspaceRegistry.create(cwd) 用了兜底值 cwd（来自
resolveWorkspaceCwd，可能是 ~/.dsh/mail-sessions/mail-<uuid>），
而不是会话 header 里的真实 cwd。两者不一致时 attachSession 拒绝，
且 create 已先执行，每封邮件都往注册表里塞一条空的垃圾 workspace。
修复：读 handle.agent.session.header.cwd —— create 路径下是 meta.cwd，
resume 路径下是持久化 header 里那个。
## homeagent 插件：11 工具齐平 opencode
tools.go 新增：read_mail / forward_mail / suggest_address /
list_contacts / session_participants / read_thread / connect_to_server
+ handleConnectToServer（注册到 Gateway 前先用候选坐标试注册，
成功才写回 p.gwURL/p.key，失败不破坏原配置）
关键修：Plugin.name（插件名，homed 注册用）与 Plugin.agentName
（AgentMail 身份，Gateway 密钥绑定用）是两个命名空间。
它们混淆会导致 403：「该密钥已绑定到 Agent 'homeagent'，不能用于
注册 'homeagent-mail-bridge'」。现已分开，并在 systemd drop-in
里显式设 AGENTMAIL_AGENT_NAME=homeagent。
## 三插件补齐 connect_to_server
之前只有 opencode 有。后果：Gateway 换地址或密钥需要重新登记时，
opencode 里的模型能自己修好，其他平台只能干等环境变量被人改。
DSH 版：从 GatewayClient 内部调 register()，成功后写回 client.baseURL
与 client.agentKey 当场生效。
pi 版：新导出 KEY_FILE / saveLocalKey（从 gateway.mjs），connect
工具直接用。
# 测试
relayhops_test.go 5 例
opencode 172 / dsh 188 / pi 214 全绿
check-shared-libs.sh 三方同源（rename-proposal 已纳入校验）
|
2026-09-03 15:01:52 +08:00 |
|
|
|
fc33087982
|
feat: homeagent-mail-bridge —— TrueAgent 接入 AgentMail（MVP）
## 架构
TrueAgent 是单一常驻 agent 事件循环，没有 per-conversation session。
插件像 QQ 插件一样：所有邮件注入同一个事件循环，靠中断消息文本传递 context。
不做 platform_sessions 上报（无 sessions 可映射）。
## 工具
- read_inbox: 收件箱查询（渲染发件人/主题/正文/抄送/附件）
- send_mail: 三维地址发信（支持 reply_to）
- output_send__homeagent 输出通道（agent 可主动发信）
## 自动回信
InjectInputSync（阻塞）等待 agent 处理完毕 → 自动把 FinalText
发回给发件人（reply_to 指向原邮件）。agent 不需要记得调 send_mail。
试过 StageAfterOutput hook，但 before_output 看不到 ToolCalls
（read_inbox 调用在 turn 中间就被清掉了），导致自动回信不触发。
InjectInputSync 更可靠：TrueAgent 保证不重入。
## 基础设施
- 心跳 25 秒
- SSE 长连 + 自动重连（3 秒退避）
- 注册时自动注册密钥（AGENTMAIL_AGENT_KEY 环境变量）
- systemd drop-in 注入 AgentMail 环境变量
## 构建
plugindev build → dist/homeagent_linux_amd64.hmap
安装到 /home/newqqagent/plugins/homeagent-mail-bridge/
homeagent.service drop-in: /etc/systemd/system/homeagent.service.d/agentmail.conf
## 端到端验证
admin → homeagent@/tmp/homeagent.new（自动回信验证）
→ homeagent 读取邮件 + 自动回信「收到确认」→ 25 秒往返完成
|
2026-09-03 12:57:43 +08:00 |
|
