|
|
a02feaaff7
|
refactor(agent): 子 agent 类型抽象 + rt 输出异步 + 工具钩子统一
三件事，都是同一个根因的症状：子 agent 的类型逻辑复制成多份，
于是标准路径上的能力没跟着传过来。
## 1. 抽出 child 包（类型抽象 + 单一登记表）
新增 internal/agent/core/child/：
child.go Kind / Child（嵌入用）/ State / 残余与通道处置
registry.go 单一 Registry + Entry 接口 + Cleanup 骨架
kind.go ChildKind —— 按两条主轴（上下文 / 工具与输出异步）
kinds.go 四种子 agent 的清单与迁移状态
此前 Agent 上有两张互不知情的表（residents / rtChildren），各带一把锁。
实测新增一种子 agent 要改 18 个生产文件，并已因复制而漂移过一次
（StopRTChildren 漏注销入站登记，见 engineering-lessons.md §2.3）。
现在单数与复数停止**共用** Cleanup，那个形态在结构上不可能复现。
## 2. rt 的输出改为异步（用户的原始诉求）
rtEmit 曾直接 dev.Execute(...)，插件侧延迟（TTS/网络编码/字幕渲染）
直接节流模型的 token 消费 —— 「不攒整段」的收益全被吃掉。
新增 outputpump.go（输出通道的异步壳）：
· Push 立即返回，交付由独立消费 goroutine 完成
· 有界队列（64），满则**丢最旧**（符合 rt 的"最新者胜"）
· 丢弃与设备缺失都留痕，否则"用户听不到"没有任何线索
· Close 排空后退出，不吞最后半句
· 设备每片重新解析（插件崩溃会 Unregister，缓存指针会指向死设备）
## 3. 工具钩子统一（本轮最大发现）
实测：StageBeforeToolcall / StageAfterToolcall 全仓只在
task.go:1022/1079/1194，三处都在 runOneTool / stepToolAfter 里；
而 executeToolCallOutcome 内部**没有任何 runStage**。
⇒ rtchild 与工作式子两条路径**完全跳过插件钩子**：不能审计、
不能拒绝、不能改参、不能脱敏。README 承诺的 before_toolcall
在这两条路径上不成立。
新增 toolbatch.go（唯一批执行实现：批并发 + 双钩子 + 顺序落结果），
两种类型切过去。工作式子的"禁输出工具"与"保持串行"用 batchOpts 注入，
不各写一遍执行逻辑。
## 判据（均经变异验证）
TestRTChild_OutputIsAsync 改回同步 ⇒ 红（实测确认）
TestOutputPump_DropsOldestOnFull 改阻塞/无界 ⇒ 红
TestOutputPump_CloseDrains 丢弃队列 ⇒ 红
TestOutputPump_ResolvesDeviceEachTime 缓存指针 ⇒ 红
TestRTChild_ToolsGoThroughPluginStages 绕开钩子 ⇒ 红
TestRTChild_StageCanDenyTool 同上
TestWorkerToolsGoThroughPluginStages 同上（变异实测确认）
TestWorkerToolsStaySerial 改成并发 ⇒ 红
TestNoChildTypeTablesInCore 源码扫描，禁类型专属表回潮
TestRTChild_HasGraphMemory 等 5 条 rt 接入图记忆
## 顺带修复
· rt 接入图记忆（参照驻留子的轻量内核形态）：此前 graphMem() == nil，
memory_recall / memory_commit 在 rt 里全部不可达，每通电话从零开始。
默认只读（通话高频写入会灌满图谱噪声），4 个失败点合并成一个 rollback
闭包（逐点挂必然漏一处 ⇒ 泄 SQLite 句柄）。
· rt 的 PreferredProvider 走候选链（此前裸调 a.provider，优先源无效且零回退）。
## 保留的语义（逐项确认仍在）
驻留子三层压缩：checkContextFull / handleChildContextFull / CompressResident
三种通道处置：ChannelRelease / Suspend / Takeover
残余 keep/drop + harvestResidentMemory
child.Start() 的 7 个 goroutine
验证：build / vet / gofmt / go test -race 全绿；
且在干净检出（git worktree）上单独 build + test 通过。
|
2026-11-04 08:21:15 +08:00 |
|
|
|
4e70b8d5d8
|
refactor(module): 核心仓 Go module 路径改为 github.com/JianFeeeee/HologramAgent
批 1，不含 SDK 仓与目录改名。
- go.mod 第 1 行 module 路径
- 366 个 .go 文件的完整前缀 github.com/JianFeeeee/HomeAgent 机械替换
（857 处，仅完整前缀；展示名/注释里的 HomeAgent 字样留给批 5）
- 未改：third_party 目录名、SDK 自身 go.mod module、go.mod replace 目标、
homed/waiter 可执行名、.hmap 后缀
|
2026-10-21 12:17:19 +08:00 |
|
|
|
d9c2e51f61
|
fix(agent): cancel 停不下调度循环 —— 队列非空时永远不看 ctx.Done
## 缺陷（真缺陷，不是测试问题）
`schedulerLoop` 只在"队列空"的分支里 select `ctx.Done()`：
if kind == nextNone {
select { ... case <-a.ctx.Done(): return }
}
于是**只要队列里有任务，循环就永远不看 ctx.Done** —— 一直取、一直执行，
直到队列被取空才可能退出。
生产后果（`reclaim` / `destroy`）：销毁流程先回收残余任务、再销毁子。
而回收到销毁之间子仍在运行，继续把队列里的任务取走执行 —— 那些任务的
结果**永远无人认领**（子随即被销毁），且日志无痕迹：既不在"残余清单"里，
也没跑到出结果。带 ResponseCh 的同步调用方（cli/a2a）更糟：Stop 的
drainPendingInterrupts 给它补一个 "skipped"，用户看到"已跳过"，
而任务其实执行过。
## 修法
1. `schedulerLoop` 循环顶部（**取任务之前**）检查 ctx.Done。
2. 新增 `waitSchedulerStopped`：cancel 之后等 running 归零（上限 5s，
超时如实记日志，不让控制面永久挂住）。
3. 新增 `FinishResident`：停止调度 → 回收残余 → 处置 → 收割记忆 → 销毁，
**一步完成**，消除"取完到销毁"之间的窗口。`reclaim` / `destroy` 改走它。
4. 记忆收割抽成 `harvestResidentMemory`，供 FinishResident 的 onDestroy 复用
（必须在 Destroy 之前 —— Destroy 会关掉 temp）。
## 判据（2 条，都做了"撤销修复必须变红"的验证）
· TestSchedulerStopsTakingTasksAfterCancelWithNonEmptyQueue
用阻塞 provider 把循环钉在 executeNewTask 里，此时塞 5 条进队列、
cancel、放行。修复在位 ⇒ 5 条一条都不执行；撤销修复 ⇒ 取走 5 条。
**实测撤销后报「仍取走了 5 条（剩 0/5）」，恢复后 10/10 绿。**
· TestFinishResidentIsAtomic
断言返回后子已从登记表移除（销毁确实在同一事务内完成）。
原 flaky 的 TestResidualKeepReturnsTasksToParent 与
TestResidualDropNotifiesSyncCaller 也修了：先 cancel + 等静止再入队，
得到确定的初始状态（它们验的是转交逻辑，不是子的生命周期）。30/30 绿。
## 我踩过的两条弯路（都写进判据注释了）
1. 加 `scheduler.freeze` 绕过。错在：调度器本来就有停止语义（ctx），
再引入一个状态位会让"谁负责停"含糊，且忘了解除就永久僵住。已删。
2. 判据第一版写成「先 Start、再 cancel、然后入队」—— 那时队列是**空的**，
循环正好走 nextNone 看到 ctx.Done 退出，于是**撤掉产品修复判据依然
30/30 全绿**。是用户追问"凭什么说修好了"才发现这是假绿。
必须造出"队列非空时 cancel"这个确切场景才测得到。
|
2026-10-18 13:07:40 +08:00 |
|
