mirror of
https://gitcode.com/JianFeeeee/HomeAgent.git
synced 2026-11-01 06:47:29 +00:00
## 为什么必须是第 0 层(用户口径) update 肩负「启动失败回滚上一次升级」的职责,该职责必须**早于所有模块**。 若排在后面:升级后新内核在 memory/llm 阶段崩了,而回滚还没跑 ⇒ 机器进 崩溃循环,只能靠 guard 的 failback(受限启动)兜底。failback 是最后手段, 不该承担"换错二进制"这种**已知可回滚**的故障。 ⇒ Requires() 为空 ⇒ 依赖图天然把它放 Layers[0]。 ## 两段式升级确认(rollback.go) 升级成功 ──→ 写 pending 标记("这个版本尚未被确认能启动") ↓ 重启 → 内核启动 → update 模块(第 0 层)读标记 ↓ ┌────────────┴────────────┐ 标记还在 标记已不在 (上次升级没能活到清除) (上次升级已确认成功) ↓ ↓ 回滚到备份版本 正常继续 + 清标记 清除时机:模块跑完自检后立刻清。只依赖"进程活着且执行到第 0 层", 不依赖其他模块 ⇒ 不会误判。 **为什么不用 TTL / 重启次数**:那是 guard 已有的 failback,但判据是 "崩了几次",不是"这次升级该不该撤销"。用重启次数会在"新版本偶发崩溃"时 误回滚 —— 而那种情况该修的是崩溃,不是回退版本。 ## 分层(与仓库其他模块同一惯例) internal/update/ 业务实现(三端共用:CLI/WebAPI/agent 工具) internal/kernelmod/update/ 适配层(读 ks → 调业务包 → 写回 ks) 参照 supervisor 模块:实现在 internal/supervisor,模块里只做装配。 分开的理由:internal/update 被三端调用,它们都没有 KernelState。 ## 标记写入时机(一个真实的顺序坑) MarkPendingUpgrade 在**替换二进制之前**调用。反过来(替换后才写)会在 "替换成功但没来得及写标记就崩了"时丢标记 ⇒ 下次启动不知道该回滚。 且写标记失败 ⇒ **放弃本次升级**(未替换任何文件):没有标记就没有回滚 能力,而不带回滚的升级等于赌运气。 ## 回滚失败必须响亮 备份不存在时返回 error,调用方(模块 Init)必须中止启动 —— 继续装配等于 用一个已知起不来的版本。错误文案带备份路径与标记路径(删标记即可放弃回滚), 人能照着修。 ## 判据 internal/update/rollback_test.go 10 条,2 条经变异验证: · TestRollback_RestoresBackup —— 二进制+depgraph 同批回滚、标记清除、 坏版本留档 homed-broken-*、版本轨迹记录 变异:回滚后不清标记 ⇒ 红 · TestRollback_MissingBackupIsLoud —— 备份缺失时报错且可执行 变异:静默返回 nil ⇒ 红 · TestPendingMarker_AbsentIsNotError —— 无标记返回 (nil,nil) 而非 error (否则每次启动都走"回滚失败"分支 ⇒ 内核永远起不来) · TestPendingMarker_CorruptIsActionable —— 标记损坏时提示可删 · TestStateSummary_* —— 回滚信息进 healthcheck;nil 安全 ## 顺带修正的既有判据 · runtime_dep_test.go:L0 设施集合从 2 个变 3 个(新增 kernel.version), 改为断言**集合**而非顺序(注册表本就是乱序的) · facilities.go:新增 FacVersion,并登记为 internalOnlyFacilities (它是启动时序事实,不是插件契约 —— facilities_sync_test 的守卫正确拦住了 "把内部标记泄漏成对外契约") 三个 DoUpgrade 调用点补 dataDir 参数(标记落点必须与内核 --data 一致)。
138 lines
4.8 KiB
Go
138 lines
4.8 KiB
Go
// kernel_update 工具的 agent 侧实现。
|
||
//
|
||
// ## 三个入口共享一个底层(架构约束)
|
||
//
|
||
// agent 工具 kernel_update ┐
|
||
// WebAPI /kernel/update ├─ internal/update(CheckRelease / DoUpgrade)
|
||
// CLI homed-upgrade ┘
|
||
//
|
||
// 三份实现必然漂移("agent 说没有新版、WebUI 却升了"),所以入口层只做
|
||
// 参数解析与结果呈现。
|
||
//
|
||
// ## 为什么实现放在 pluginmgr 而不是 agent/core
|
||
//
|
||
// 1. 与 plugin_update 对称(都在 pluginmgr,用户认知一致)
|
||
// 2. agent/core 拿不到 SDK 句柄,而升级完成后要 RequestKernelRestart
|
||
// (那是 sdk.KernelControlAPI)
|
||
// 3. 与内核工具分派(toolcall.go)不同:这里走插件的 RegisterTool,
|
||
// 不需要改核心包
|
||
//
|
||
// ## 两阶段(用户口径)
|
||
//
|
||
// apply=false(默认)→ 只查 GitHub Release 与本地版本比较,不改动任何东西
|
||
// apply=true → 下载/解包 → 校验 → 备份 → 原子替换 → 重启 → 版本复核
|
||
// → 失败自动回滚(DoUpgrade 内部完成)
|
||
|
||
package pluginmgr
|
||
|
||
import (
|
||
"fmt"
|
||
"os"
|
||
"path/filepath"
|
||
|
||
"github.com/JianFeeeee/HologramAgent/internal/update"
|
||
)
|
||
|
||
// kernelUpdateCheck 是 kernel_update 的检查半边(apply=false)。
|
||
func (p *Plugin) kernelUpdateCheck() (interface{}, error) {
|
||
cur := currentKernelVersion(p)
|
||
info := update.CheckRelease(cur)
|
||
return map[string]interface{}{
|
||
"apply": false,
|
||
"current": info.Current,
|
||
"latest": info.Latest,
|
||
"has_update": info.HasUpdate,
|
||
"asset": info.Asset,
|
||
"release": info.LatestURL,
|
||
"reason": info.Reason,
|
||
"hint": "确认后传 apply=true 执行升级(会替换二进制并重启内核,连接断开数秒)",
|
||
}, nil
|
||
}
|
||
|
||
// kernelUpdateApply 是 kernel_update 的执行半边(apply=true)。
|
||
//
|
||
// 只接受**本机已有的包**(pkg 参数):从 URL 现场下载需要处理
|
||
// 校验/断点/重试,那是 CLI 的职责(homed-upgrade),agent 不应在
|
||
// 推理过程中发起长下载(会占满工具调用超时)。
|
||
func (p *Plugin) kernelUpdateApply(pkgPath string) (interface{}, error) {
|
||
if pkgPath == "" {
|
||
return map[string]interface{}{
|
||
"error": "apply=true 需要 pkg(本机已存在的安装包路径;下载请跑 homed-upgrade -pkg <url>)",
|
||
}, nil
|
||
}
|
||
st, err := os.Stat(pkgPath)
|
||
if err != nil || st.IsDir() {
|
||
return map[string]interface{}{
|
||
"error": fmt.Sprintf("pkg 无效:%s", pkgPath),
|
||
}, nil
|
||
}
|
||
|
||
tmp, err := os.MkdirTemp("", "kernel-upgrade-*")
|
||
if err != nil {
|
||
return nil, fmt.Errorf("建临时目录: %w", err)
|
||
}
|
||
defer os.RemoveAll(tmp)
|
||
|
||
root, err := update.ExtractPkg(pkgPath, tmp)
|
||
if err != nil {
|
||
return nil, fmt.Errorf("解包: %w", err)
|
||
}
|
||
newBin := update.FindFile(root, "homed")
|
||
newDG := update.FindFile(root, "depgraph.bin")
|
||
if newBin == "" {
|
||
return nil, fmt.Errorf("包内找不到 homed")
|
||
}
|
||
|
||
// ★ 升级会让本进程消失:先把"已受理"回给模型,再执行替换。
|
||
//
|
||
// 否则模型看到的是工具调用超时/断线,无法区分"升级成功"和"工具坏了"。
|
||
// 返回后由本 goroutine 继续跑 DoUpgrade(替换+重启+回滚)。
|
||
if kc := p.sdk.KernelControl(); kc != nil {
|
||
_ = kc.RequestKernelRestart("kernel_update apply")
|
||
}
|
||
go func() {
|
||
if err := update.DoUpgrade(root, kernelBinPath(p), newDG, p.pluginDir, kernelDataDir(p)); err != nil {
|
||
// DoUpgrade 内部失败已自行回滚;这里只留一条诊断日志
|
||
fmt.Fprintf(os.Stderr, "[pluginmgr] kernel_update upgrade failed (rolled back): %v\n", err)
|
||
}
|
||
}()
|
||
return map[string]interface{}{
|
||
"accepted": true,
|
||
"message": "升级已受理:正在替换二进制并重启。完成后用 kernel_update(apply=false)确认新版本。",
|
||
}, nil
|
||
}
|
||
|
||
// kernelDataDir 推导数据目录(升级确认标记的落点)。
|
||
//
|
||
// 从 pluginDir 反推:<dataDir>/plugins ⇒ 上一级即 dataDir。
|
||
// 与内核 --data 的值一致,update 模块(第 0 层)才能读到同一个标记。
|
||
func kernelDataDir(p *Plugin) string {
|
||
if p.pluginDir != "" {
|
||
return filepath.Dir(filepath.Dir(p.pluginDir))
|
||
}
|
||
return "/home/newqqagent"
|
||
}
|
||
|
||
// currentKernelVersion 读本机 homed 自报版本(尽力而为)。
|
||
func currentKernelVersion(p *Plugin) *update.BinVersion {
|
||
v, err := update.ReadBinVersion(kernelBinPath(p))
|
||
if err != nil {
|
||
return nil
|
||
}
|
||
return v
|
||
}
|
||
|
||
// kernelBinPath 是本机 homed 的路径。
|
||
//
|
||
// 由 pluginDir 推导(<data>/../homed 不总是成立),优先按**本进程**
|
||
// 的可执行路径:homed 与内核同二进制,这是最可靠的来源。
|
||
func kernelBinPath(p *Plugin) string {
|
||
if exe, err := os.Executable(); err == nil && filepath.Base(exe) == "homed" {
|
||
return exe
|
||
}
|
||
if _, err := os.Stat("/usr/local/bin/homed"); err == nil {
|
||
return "/usr/local/bin/homed"
|
||
}
|
||
return "homed"
|
||
}
|