|
|
ba281a855a
|
feat(update): 差分 OTA + 安装形态分派 + 事件总线统一受安全监控
三条主线，由 e2e 实测驱动。
## 一、差分 OTA（internal/update/delta.go）
实测：改一行逻辑，88MB 的二进制逐字节只差 80 字节，而 OTA 一直下整包。
用 rsync 族的滚动哈希块匹配（4KB 粒度），不是 bsdiff —— 后者需 17×N
峰值内存（88MB → 1.5GB），而升级恰可能发生在内存紧张时。
真实二进制实测：88,036,728 字节 → 补丁 77,316 字节（0.088%）。
三道闸：应用前验旧文件 sha256（错基线会静默产出垃圾）、应用后验结果
sha256、COPY/LITERAL 越界防护。任何失败**退回整包**，不向上抛 ——
差分是优化，不是可用性前提。
接入：Source.Resolve 优先试 delta；CheckRelease 按 -from-<commit8>.delta
匹配（不猜基线）；CLI 新增 -make-delta；打包脚本 build_delta（需
PREVIOUS_HOMED），delta 进 SHA256SUMS。
## 二、安装形态分派（internal/update/install.go + channel.go）
内核对「能不能自己升级」此前只有一个答案：直接替换二进制。而 deb/rpm
形态下那样做会让 dpkg/rpm 数据库与实际内容不一致（下次 apt upgrade
覆盖回旧版，或 dpkg 拒绝后续升级）。
新增探测：deb/rpm/tar/container/source 五类形态 + 变体（full/server/
client/toolchain）+ 目录写权限。判据全部来自可观测系统事实（dpkg 的
info 目录、容器标记文件），不做路径推断。
三端统一走 PlanUpgrade 分派；形态闸门放在**下载 880MB 之前**。
## 三、事件总线统一受安全监控（internal/events + security）
用户指正：「eventbus 上所有事件都要接受安全模块的监控」。
此前 EventPolicy 只被 internal/sdk/events.go 调用，而那是四条路径中的
一条。s.Publish / s.Subscribe / s.EventBus() 拿的是裸 *events.Bus，
任何插件都能绕过策略发任意事件（含伪造内核事件）。
现在闸门在 Bus.Publish/Subscribe 本体上（Guard 接口注入，避免 events
↔ security 成环），四条路径全部覆盖。sdk.EventBus() 改返回带身份的
BusHandle。内核身份免授权，但载荷照样过凭据闸门。
白名单按主体收窄：agent_output/stage/terminal_output 只允许承载者
（webui/cli/agentcli）发布 —— 它们是内核向外的输出面，谁都能发就等于
能伪造 agent 说的话。
## e2e 暴露并修掉的三个真实回归
[bus] subscribe denied: pluginmgr type=update_request
[bus] subscribe denied: skillmgr type=skill_detected
前两个让升级请求静默丢失、职责链交接断掉。内部协作事件必须可订阅
（安全边界在发布侧，订阅只是「听得到」）。
## 顺带的止血修复
- 回滚判据从 `--version` 改为 digest：旧内核（1.3.x 及以前）没有该
flag，而它恰是最常见的回滚目标 —— 原逻辑让「从旧版升级失败」永久
无法回滚。
- CopyFile 补 fsync（替换 homed 本体时掉电会留半截文件）。
- restore 完整还原才清 marker（原先先清再还原，还原失败就失去第二次
自愈机会）。
- 回滚时移除升级中新增的 depgraph（否则「旧 homed + 新 depgraph」
会因 digest 不匹配崩溃循环）。
- homed-upgrade 不再硬编码 systemctl restart（丢 guard 状态、unit 名
漂移）；改用内核已有的 restartCh → exit 42 语义。
- homed-upgrade 不再用 CGO_ENABLED=0 编却依赖 go-sqlite3（stub 下
静默失效，该路径从未工作过）；改用 internal/config。
- 服务单元补 User=hologramagent + 三条安装路径补建用户（此前发行物里
完全没有落实降权）。
- rpm 的 fpm 调用补 --after-install（此前 rpm 装完根本不建用户）。
## 判据
新增 30 条：差分 8（往返/压缩比/错基线/截断/篡改/边界）、通道 8、
执行器 6、事件闸门 8、按主体授权 8。全仓 go test ./... 0 失败。
|
2026-10-29 09:54:55 +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 |
|
|
|
48ca95f964
|
fix(onnx): 启动日志错报「走规则引擎」—— 实际一直用内嵌 ONNX 模型
用户质疑「编译的内核没启用 onnx」。核查结论：**ONNX 是启用的**，是我上一版
日志改错了，误导了判断。
## 事实
- 编译：`make build` 默认 `HOMED_TAGS=onnxruntime`（Makefile 有明确注释，
产物里 `go version -m` 可验 `-tags=onnxruntime`、CGO_ENABLED=1）。
- 多模态向量空间：`provider=chineseclip dim=512` 已加载，健康快照
`onnx.enabled=true`。
- 依存句法分析器：`core.agent.onnx_model_path` 留空时走**二进制内嵌模型**
（`//go:embed models/*` → 解到 `<data>/nlp/dep_parser.onnx` 后加载），
同样是 ONNX 推理，不是规则引擎。
## 上一版错在哪
我只回显了**配置值**（空串），于是打出
`dep parser ready (内置规则引擎；未配置 ...)` —— 把「内嵌模型已启用」
说成了「降级到规则引擎」。原始日志 `initialized (model: )` 的空括号
本来就是同一个信息缺失，我把它改成了**更确定的错误结论**。
## 修法
- `nlp.ONNXParser` 记录实际加载的 `modelPath` 并暴露 `ModelPath()`
（stub 构建下恒为空，两套构建接口一致）。
- 内核启动日志改为报实际路径：
`dep parser ready (ONNX，模型: /home/newqqagent/nlp/dep_parser.onnx)`
部署后实录：该行正确输出实际模型路径；`onnx.enabled=true`；
启动告警仅剩两条 CLI 型技能降级说明（已在上一个提交解释）。
|
2026-10-20 09:04:11 +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 |
|
|
|
95a002f6bd
|
feat(release): 发行版默认启用本地向量空间（onnxruntime 标签 + chineseclip 默认）
用户要求：后续发行版默认带 ONNX 模型能力。这条要求落到两处，并顺带修掉一个
被它**暴露出来**的真缺陷。
## 1. 构建默认带 onnxruntime（deploy/packaging/build.sh）
`HOMED_TAGS` 默认 `onnxruntime`，需要极简构建时显式 `HOMED_TAGS=` 关闭。
不带标签时 provider 仍注册、但打开即报「requires build tag」并优雅降级——
不静默假装成功。运行期还需要 `libonnxruntime.so`（provider 按
/opt/onnxruntime、/usr/local/lib、/usr/lib 顺序查找），缺失时同样是
「日志里明确错误 + 降级」。
## 2. 新装默认选 chineseclip（internal/config/registry.go）
`SeedDefaults` 写入：
core.memory.multimodal_space.provider = chineseclip
core.memory.multimodal_space.options.model_dir = <dataDir>/models/chinese-clip-vit-b16-onnx
选它而不是 qwen3vl：后者实测常驻 9.4GB，多数机器装不下；chineseclip 是
1.99GB（实测，见下）。同时更新两个 ConfigDef 的默认值与描述（WebUI 显示用）。
**老安装不会自动拿到这两个默认值**，这是有意的：`seedDBValues` 对非空配置库
直接返回，`GetString` 缺键时回落到调用方默认值（main.go 传的是空串）。
升级就静默加载 ~1.8GB 模型不是无副作用的事，应由部署显式开启。已写进文档。
## 3. 修掉 ORT 环境被重复初始化 + 误销毁（internal/nlp/onnx.go）
这是「默认带标签」才暴露的缺陷：此前不带标签时进程内不会有多个 ORT 消费者。
- `NewONNXParser` 无条件 `InitializeEnvironment()` → 若多模态 provider 先初始化，
这里报「The onnxruntime has already been initialized」并**降级**（实测日志：
`ONNX parser init: init onnx env: ... using fallback`）。
- 更严重的是失败路径与 `Close()` 里的 `DestroyEnvironment()`：它会把别人
（多模态 provider）正在用的进程级环境一起拆掉，让对方的会话失效。
改为：初始化前先 `IsInitialized()`；**任何消费者都不销毁环境**（随进程存活），
只销毁自己的会话。providers/chineseclip 与 providers/qwen3vl 本来就是这个约定，
现在三处一致。
## 验证（实测）
- 全新数据目录启动：配置库出现上述两个默认值。
- 模型未安装：`multimodal space active` 不出现，代之以明确错误
（点名缺失的 embed_config.json 路径 + 已注册 provider 列表）+ 降级，不静默。
- 模型就位：`multimodal space active: provider=chineseclip dim=512 fp=cd2a495cf990
modalities=[text image]`。
- 内存：同一份 homed，启用时 RSS **1.99GB**（峰值 2.09GB），不启用 **0.17GB**。
- NLP 修复：日志由 `ONNX parser init: ... using fallback` 变为 `dep parser initialized`。
- 构建矩阵：`go build/vet ./...` 与 `-tags onnxruntime` 两种都过；
`bash -n deploy/packaging/build.sh` 通过。
## 未做（明确记录）
- `libonnxruntime.so`（24MB）与 Chinese-CLIP 产物（754MB）目前都需自行安装/导出，
发行版尚未打包它们。若要让「默认启用」在干净机器上真正开箱可用，需要决定
是随包分发、安装时下载、还是保持文档指引。
|
2026-09-12 00:10:32 +08:00 |
|
|
|
cb0f11c33d
|
v0.7.3: 重构 Provider 层 + 计算层隔离 + Cleaner/NoMemory 架构
- 删除 OpenAIProvider/OllamaProvider 死代码，LuaAdaptedProvider 独存
- DisableThinking 从 ExtraBody 移到 CompletionRequest 顶层字段
- ContextWindow 从 Provider 签名移到 BaseConfig/ModelContextWindow() 统管
- 确认 CleanText 仅做基本空白 trim，QQ 模板剥离归插件 Cleaner
- Cleaner/NoMemory 仅作用于向量计算和 jieba 分词层，原文不变
- context.ContextEvent/Doc.Content 始终保存原文
- 删除 nlp/download.go 死代码
- media.go: context.Background() -> a.ctx 级联
- clawhubadapter: HTTP 超时
- cut.go: 跨平台 mod cache 路径 (GOMODCACHE->GOPATH->HomeDir)
- bridge_e2e_test: 移除未用 runtime import
- lua 适配器: disable_thinking 传参
|
2026-07-28 11:42:29 +08:00 |
|
|
|
7f08f3ca09
|
v0.7.2: 根目录清理 + Agent 心跳重构 + 内嵌 ONNX 模型
- 根目录清理: branding/docs/knowledge -> assets/, package/tools/deploy -> deploy/
- meta.go: Version 0.7.2, SDKCompatibleVersion 语义改为最高兼容
- Makefile: 版本回退 0.7.2
- registry.go: 系统提示词改用 meta.Version 格式化
- Agent 心跳: reorgGraph 拆分为三个独立循环(archive/merge/review)，各自可配间隔
- GraphDB: 新增 sentences 表 + 关系句子溯源 + ClearSentenceID + CleanupOrphanedSentences
- Knowledge: 支持词嵌入向量化器
- NLP 四阶段流水线: Parse -> Extract -> Verify -> Fuse + SentenceRef
- 移除远程 HTTP 解析器(remote_parser.go)
- 新增内嵌 ONNX 模型(vocab + dep_parser.onnx):
+build onnxruntime: 全量 ONNX Runtime 推理
!build onnxruntime: 内嵌词表规则式降级解析器
- config: core.agent.onnx_model_path 替代 dep_parser_url
|
2026-07-28 09:56:26 +08:00 |
|
