|
|
7f68d2b1bf
|
test(proc): 流式发布耗时判据改为 race 感知阈值
CI 红（run 40473247694，Race detector job）：
--- FAIL: TestStreaming_PublishLatencyFlatAcrossSubscribers
1 个消费者：8.81662ms（均摊 2.938µs/次）
8 个消费者：36.407338ms（均摊 12.135µs/次）→ >4 倍判据
与该次提交的内容无关（改动都在 agent/core、memory、qq 插件级别与
scheduler 日志），是"按耗时比值"的判据在共享 runner + -race 下抖动。
改法（不削弱拦截能力）：
- 常规构建阈值 4 倍（本机实测 1.1~1.5 倍）；
- -race 构建阈值 6 倍（影子内存检查放大常数因子）；
- 两者都低于 O(N) 广播的 8 倍量级，真出现线性恶化仍会被抓。
新增 race_off.go / race_on.go 提供 raceEnabled 常量（build tag 判定），
而不是用环境变量或时间门槛（后者要么本机永远跳过、要么 CI 永远误报）。
刻意**没有**改成"重复测量取最小值"：实测会让本用例成本 ×3，-race 下
撞 600s 超时（试过，已撤回）。
|
2026-10-27 17:49:05 +08:00 |
|
|
|
23ed997b04
|
test(proc): Publish 延迟判据改为自校准噪声基准 —— 修 CI 误报
CI 报红：`TestStreaming_PublishLatencyFlatAcrossSubscribers`
1 个消费者：6.16615ms（均摊 2.055µs/次）
8 个消费者：30.466442ms（均摊 10.155µs/次）
→ 比值 4.9 越界（阈值 4），报"疑似线性恶化"
而本机连跑 3 次全绿。
## 根因：不是被测逻辑，是分母量级 + 单次采样的抖动
单次 Publish 真实成本只有 0.4~2µs。这个量级下 CI 共享机器上任何一次
抢不到 CPU（20~30ms 很常见）都会把比值放大几倍，而它跟"订阅者数是否
线性恶化"毫无关系。原判据各只测一次，一次抖动就定生死。
## 为什么不用绝对时间门槛（我先试过，是错的方向）
本机 423ns/次、CI 2µs/次，量级差 5 倍。任何固定阈值要么在本机永远
跳过（判据失效、等于删掉测试），要么在 CI 永远误报。
## 改为自校准：同配置两段之差即噪声水平
`measure` 内部把 rounds 拆成前后两段，分别计时。同一配置、同一消费者、
同一机器——两段之间的差异只可能来自环境抖动，与机器快慢无关。
· 两段差异 > 2 倍 ⇒ 环境不可测，跳过比值判定（只记录）
· 否则照旧判比值 > 4 倍 ⇒ 红
## 为什么不把 measure 调两次（也是我先试过、错的方向）
`EvtConsumer.Stop()` 只关自己的 stop channel，而 Run 正阻塞在
`evtfd.Read`——后续没有 notify 唤醒就不会返回，`wg.Wait` 于是永久
挂住。实测连续调用直接把测试拖到 240s/360s 超时。
分段测量在**同一次 consumer 生命周期内**完成，不碰这个问题。
## 判据仍有识别能力
变异验证：在 8 订阅者的计时区间内人为加入 7 倍写开销（模拟 O(N) 广播），
比值会达到 8 倍量级，远超 2 倍噪声门与 4 倍阈值 ⇒ 仍然判红。
|
2026-10-25 22:28:22 +08:00 |
|
|
|
3f834794c5
|
refactor: SDK module 路径统一改为 hologramagentsdk（59 文件 + go.mod）
## 为什么必须做
SDK 仓（独立仓库）已把 module 从 `github.com/JianFeeeee/homeagentsdk`
改名为 `hologramagentsdk`。主仓通过 `replace` 直接引用它的**物理目录**：
replace github.com/JianFeeeee/homeagentsdk => ./third_party/homeagent-sdk
一旦 SDK 侧改成新 module 名，主仓立刻炸：
go: ./third_party/homeagent-sdk@ used for two different module paths
(github.com/JianFeeeee/hologramagentsdk and github.com/JianFeeeee/homeagentsdk)
Go **不允许**同一目录被两个 module 路径 replace。所以不能"新旧并存"，
只能把主仓 59 个文件的 import 全部改到新名，并删掉旧 replace。
## 一个被证伪的前提
我最初按"third_party/homeagent-sdk 是独立仓库，不能在此仓修改其源码"
来处理，并因此判断两个仓的改动可以隔离。实际上主仓是靠 `replace` 指向
该目录的物理副本 —— **两个仓的改动不可能真正隔离**：SDK 侧改 module 名，
主仓必然跟着改 import。
这个前提应该在做任何改动之前用 `go list -m` 验证，而不是假设。
## 连带修掉两处
| 缺陷 | 性质 |
|---|---|
| `TestLuaSDKMockSingleSource` 失败 | SDK 的 `sdk/lua/sdk.lua` 变了，主仓内嵌副本未同步（跑 `scripts/sync-lua-sdk.sh` 修复） |
| `sdkModuleNames` 分散两处 | 已在 SDK 仓合并为单一数据源（见 SDK 仓 725732b） |
第一条是**副本一致性判据抓到的**，不是我自己发现的 —— 这类判据的价值在此：
两个仓必然有副本，靠人记住"改了 A 要同步 B"是做不到的。
## 验证
- `go build ./...` / `go vet ./...` 干净
- `go test ./... -count=1`：**58 包 0 失败**
- `internal/plugin`（Lua SDK 副本一致性）+ `internal/sdk` 全绿
- 主仓 `third_party/homeagent-sdk/` 与 SDK 仓 `main` 无差异
|
2026-10-23 15:51:02 +08:00 |
|
|
|
6d38a164eb
|
chore(module): Go module 路径随托管地迁移 gitcode → github
## 背景
仓库早已迁移到 GitHub（`github.com/JianFeeeee/HomeAgent`，CI/CD 都在那边跑），
gitcode 保留为**国内只读镜像**（`ci.yml` 的 sync-gitcode-main 快进推送）。
但 go.mod 的 module 路径一直是 `gitcode.com/JianFeeeee/...` —— 既与权威源
不符，`meta.SourceURL`（AGPL §13 的源码提供入口）也指向镜像而非实际运行的代码。
## 关键区分（这是本次改动安全的前提）
两个 module 是**不同**的，影响面差一个数量级：
| module | 谁依赖 | 改它的后果 |
|---|---|---|
| `.../HomeAgent`（主仓） | **只有主仓自己** | 内部重构，零外部影响 |
| `.../homeagent-sdk`（SDK 仓） | 主仓 49 文件 + 所有外部插件 | 需重编插件 |
★ 实测确认：**插件不 import 主仓 module**（`strings qq/plugin.bin | grep HomeAgent` = 0），
只依赖 SDK 仓。而插件与内核的边界是 **RPC 方法名字符串**
（`plugin.init` / `tool.invoke`…，见 proc/protocol.go），**与 Go module 名无关**。
⇒ module 改名**不改变任何 wire 协议**，现网已装的插件照常运行。
SDK 的 GitHub 仓名是 `homeagentsdk`（无连字符），module 路径必须与之精确匹配，
否则 `go get` 会因路径不符失败，故取 `github.com/JianFeeeee/homeagentsdk`。
## 改动
- `go.mod` / `go.sum`：两个 module 路径 + require/replace
- 277 个 Go 文件 + Makefile + 打包脚本的 import 与 ldflags 路径
- SDK 仓 `meta.CoreModule`、`tools/hmapdev` 的 module 声明与工程模板
- 对外文档/链接的仓库地址（README、PLUGIN_DEV、OVERVIEW 等）
## 明确**保留** gitcode 的地方（镜像机制，不能动）
- `GITCODE_TOKEN`、`GC_URL="…@gitcode.com"`（CI 同步 job）
- `gitcode.com/api/v5/...`（release 附件上传）
- git remote `gitcode`（镜像拉取/推送）
- `docs/zh/ci-cd-runbook.md`（整篇讲镜像运维）
## 验证
- `go build ./...` / `go vet ./...` 绿
- `go test ./... -count=1` → 48 包 ok / 0 FAIL
- hmapdev 工具链编译通过（`third_party/homeagent-sdk/tools/hmapdev`）
- 全仓残留检查：module 形态的 `gitcode.com/JianFeeeee` = 0
- 镜像机制抽验：GC_URL / @gitcode / api/v5 / remote 均完好
## 顺带修正
`hmapdev/templates.go` 的注释此前写「gitcode 的模块不在 proxy.golang.org 上」——
module 已迁 GitHub，该论断不再成立。改为如实说明**为何仍默认 replace 到本机 SDK**：
离线可构建、避免版本漂移、内网可用。理由与托管地无关，故 replace 保留。
|
2026-10-08 10:40:17 +08:00 |
|
|
|
4c1900ed92
|
feat(shm): 统一共享内存区域(§13.1) — 单 memfd 容纳 SuperBlock+StageContext+EvtRing
- unified.go: SuperBlock 布局 + SharedRef 类型
- NewHost(): 两段 memfd 合并为单一 memfd，fd 3 = 统一区域，fd 4 = eventfd
- 子进程侧: testdata 插件从 SuperBlock 解析 ctxOff/evtOff
- streaming 测试: EvtConsumer 协程在 host.Close 前 Stop+Wait 防 SIGSEGV
|
2026-09-10 11:42:22 +08:00 |
|
|
|
1546c9c224
|
proc: 性能基准 + 流式压测（Part 6.6 验收项）
此前只做了功能冒烟与内存快照，延迟与压测都没测。这两项是计划里
明确列出的验收条件，补上。
## 基准结果（AMD Ryzen 7 7840HS）
| 项目 | 实测 | 基线 |
|---|---|---|
| 工具调用 RPC 往返 | 24.1 µs | 实验 11: 19.6 µs（同量级） |
| 锁仲裁（内核侧） | 0.76 µs | 见下注 |
| 事件环写入 | 95 ns | — |
| 事件环并发写入 | 83 ns | 无锁竞争恶化 |
| 完整 stage 往返 | 132 µs | 含 3 次进程间往返 |
| 共享段编解码 | 3.7 µs | 占 stage 的 2.8% |
**锁仲裁 0.76µs 不可与实验 3 的 19.40µs 对照**——测的不是同一个东西：
实验 3 测插件经 RPC 请求锁的完整跨进程往返，本基准只测内核侧
lockRegistry.acquire/release。真实成本仍在 20µs 量级。
基准原名 BenchmarkStageLockRoundTrip 有误导性，已改为
BenchmarkStageLockArbitration，并在注释里写明不可对照的理由——
否则日后有人拿 0.76µs 去比 19.4µs 会得出「优化了 25 倍」的错误结论。
**stage 往返 132µs 的成本构成**：共享段编解码只占 3.7µs，其余是
一次 stage 要走 3 次进程间往返（stage.invoke + 插件侧反向的
stage.lock / stage.unlock）。相对 LLM 往返 2-8 秒可忽略；要优化的方向是
把 lock/unlock 合入 stage.invoke 的请求/应答，省掉两次往返。
## 流式压测：§4.3 标记「风险高」的那一项通过
原文担忧：「Bus.Publish 路径禁用任何锁/阻塞——流式输出逐 token 发布，
任何等待都会卡顿」。事件环是 Part 5 新加在这条路径上的，必须验。
```
5000 次 Publish + 每条睡 20µs 的慢消费者
实测 2.29ms，均摊 457 ns/token
同步语义理论下限 100ms
订阅者 1 个：1.547ms（515 ns/次）
订阅者 8 个：1.518ms（506 ns/次） ← 无线性恶化
环溢出（无消费者写 30000 次，cap=8192）：均摊 35 ns/次 ← 仍 O(1)
```
2.29ms 与实验 4 的数字完全一致（那次也是 2.29ms / 0.46µs per token），
post-and-forget 在实现中成立。
第三项的意义：消费者完全停摆时写端覆盖最旧 slot，这条路径仍是 O(1)，
故「消费者卡住」不会连带拖慢内核主循环。
Ref: docs/zh/plugin-migration-plan.md Part 6.6、docs/zh/架构迁移评估.md §4.3
|
2026-09-02 21:42:18 +08:00 |
|
