HomeAgent

jianf/HomeAgent

Fork 0

mirror of https://gitcode.com/JianFeeeee/HomeAgent.git synced 2026-09-28 05:13:27 +00:00

Commit Graph

Author SHA1 Message Date

Author	SHA1	Message	Date
JianFeeeee	e773f156fb	feat(deploy): 站点部署流水线（SDK 文档站 + introduce） `deploy-sdk-site.sh` 覆盖两个静态站，与 homed / waiter 是独立部署单元： - SDK 文档站：本地 `third_party/homeagent-sdk/site_build/` → 106 的 `/vol1/docker/navi-data/sites/sdk` - introduce：本地 `site/`（零构建，源即产物）→ `sites/introduce` 用法：`--check`（只核对差异）/ 默认（构建+部署+验证）/ `--rollback <备份名>`。 `--check` 逐字节比对，2026-09-27 核实两站线上与本地产物完全一致。 ## 更新了一处会误导的注释脚本原注释写「设备网关白名单只放行 ls/stat/find/cat，打不了包」。那是 waiter 白名单硬编码 18 条时的状况；2026-09-27 部署 `7193446` 后 106 已扩到 22 条（含 find/grep/sed/sort/tr/wc/head/tail/stat/file）。结论（打不了包）不变，但理由已变 —— 22 条里没有 `tar`，有 `sed` 也不能打包。照旧文字理解会以为白名单只有 4 条。 ## docs/zh/deploy-runbook.md 补 §5 站点章节 - 链路：`.60` nginx stream 按 ssl_preread SNI → 106:3080 → navi 容器内 nginx （不是 portal-nginx，那个已 Exited 两周） - 坑①：构建必须走 `tools/apidoc/build.sh`。裸跑 `mkdocs build` 会丢掉整个 `api/.md` 和 `llms.txt` —— 而 `llms.txt` 正是给 agent 直读的入口。正确产物 106 个文件，裸跑只有 78 个 - 坑②：打包不能走设备网关（无 `tar`），必须 SSH 直连 - ★ 新增文档后必须更新 `mkdocs.yml` 的 nav* —— 没登记会被 mkdocs 明确警告 `not included in the nav configuration`，等于写完了但站点里不可达 - 验证要打线上而不是只看本地产物 - 回滚点与失败版本保留策略写文档时我一度把 introduce 的域名写成「另见 §5.2」，但 §5.2 只讲了 SDK 的 SNI 链路 —— 已改为只写"同台同目录"，并补上脚本里有依据的"故意不带 README.md"。	2026-09-27 23:00:04 +08:00
JianFeeeee	175fa9dd62	docs: 新增生产部署手册（homed / waiter） `site-infra-runbook.md` 是静态站 / nginx / 证书的手册，不含 homed 与 waiter —— 两次生产部署（19:45 首次、21:50 修复）因此只存在于提交信息里，查不到。 ## 内容 §1 homed - 硬前置：必须 `-tags=onnxruntime`（普通 build 只有 ~28MB，缺 ONNX Runtime） - ★ 构建参数必须与线上一致：不要顺手加 `-s -w`。加了产物从 86.8MB 掉到 78MB，8.8MB 的差会让人误判成"构建坏了"，而它只是被 strip 了 - `check` / `deploy` / `rollback` 三条命令与备份位置 - 部署后必核：`multimodal space active: provider=chineseclip` 才是 ONNX 真加载起来的标志，缺它说明已降级但不报错 - ★ 适配器升级的保护语义（`.bundled` 三种情形的判定表），并记 21:50 那次实测：手工补过 `stream_index` 的 `openai.lua` 被正确判定为用户修改并保留 - 两次部署的真实数据对照表 §2 waiter - 逐台更新、不可并行（两台连同一网关，同时重启会同时断链） - 部署后确认 `device waiter-* online` - 记 2026-09-27 顺手解决的悬案：106 此前无 `online` 而 30 正常，两台配置与 token 完全相同 ⇒ 差异只可能在旧二进制，8月27日那版落在"未 bind 时收到 ping 会关连接"的缺陷窗口 - `device_cmd_allowlist` 的替换语义、生效验证、幂等追加方法 - ★ 明确写白名单只匹配命令名、不看参数，`find -delete`/`sed -i` 仍能逃 ⇒ 不要称它为"只读白名单" §3 故障排查：按"消息没反应 / 命令被拒 / 适配器异常 / 告警是否缺陷" 四条线各给命令；特别标注"群聊 not @bot"与"私聊没回"是两件事 §4 已知未修：三项目前是已知限制而非疏漏文中数字均与现场核对：脚本子命令确实存在（`check`/`deploy`/`rollback`）、生产白名单确为 22 条、两次二进制大小取自实际部署。	2026-09-27 22:25:58 +08:00

JianFeeeee

e773f156fb

feat(deploy): 站点部署流水线（SDK 文档站 + introduce）

`deploy-sdk-site.sh` 覆盖两个静态站，与 homed / waiter 是独立部署单元：

- SDK 文档站：本地 `third_party/homeagent-sdk/site_build/` → 106 的
  `/vol1/docker/navi-data/sites/sdk`
- introduce：本地 `site/`（零构建，源即产物）→ `sites/introduce`

用法：`--check`（只核对差异）/ 默认（构建+部署+验证）/ `--rollback <备份名>`。
`--check` 逐字节比对，2026-09-27 核实两站线上与本地产物**完全一致**。

## 更新了一处会误导的注释

脚本原注释写「设备网关白名单只放行 ls/stat/find/cat，打不了包」。
那是 waiter 白名单**硬编码 18 条**时的状况；2026-09-27 部署 7193446 后
106 已扩到 **22 条**（含 find/grep/sed/sort/tr/wc/head/tail/stat/file）。

**结论（打不了包）不变，但理由已变** —— 22 条里**没有 `tar`**，
有 `sed` 也不能打包。照旧文字理解会以为白名单只有 4 条。

## docs/zh/deploy-runbook.md 补 §5 站点章节

- 链路：`.60` nginx stream 按 ssl_preread SNI → 106:3080 → navi 容器内 nginx
  （**不是** portal-nginx，那个已 Exited 两周）
- 坑①：构建**必须**走 `tools/apidoc/build.sh`。裸跑 `mkdocs build` 会丢掉
  整个 `api/*.md` 和 `llms.txt` —— 而 `llms.txt` 正是给 agent 直读的入口。
  正确产物 106 个文件，裸跑只有 78 个
- 坑②：打包不能走设备网关（无 `tar`），必须 SSH 直连
- ★ **新增文档后必须更新 `mkdocs.yml` 的 nav** —— 没登记会被 mkdocs 明确
  警告 `not included in the nav configuration`，等于写完了但站点里不可达
- 验证要打**线上**而不是只看本地产物
- 回滚点与失败版本保留策略

写文档时我一度把 introduce 的域名写成「另见 §5.2」，但 §5.2 只讲了 SDK 的
SNI 链路 —— 已改为只写"同台同目录"，并补上脚本里有依据的"故意不带 README.md"。

2026-09-27 23:00:04 +08:00

JianFeeeee

175fa9dd62

docs: 新增生产部署手册（homed / waiter）

`site-infra-runbook.md` 是**静态站 / nginx / 证书**的手册，不含 homed 与
waiter —— 两次生产部署（19:45 首次、21:50 修复）因此只存在于提交信息里，
查不到。

## 内容

**§1 homed**
- 硬前置：必须 `-tags=onnxruntime`（普通 build 只有 ~28MB，缺 ONNX Runtime）
- ★ **构建参数必须与线上一致**：不要顺手加 `-s -w`。加了产物从 86.8MB 掉到
  78MB，8.8MB 的差会让人误判成"构建坏了"，而它只是被 strip 了
- `check` / `deploy` / `rollback` 三条命令与备份位置
- 部署后必核：`multimodal space active: provider=chineseclip` 才是 ONNX
  真加载起来的标志，缺它说明已降级但**不报错**
- ★ 适配器升级的保护语义（`.bundled` 三种情形的判定表），并记 21:50 那次
  实测：手工补过 `stream_index` 的 `openai.lua` 被正确判定为用户修改并保留
- 两次部署的真实数据对照表

**§2 waiter**
- 逐台更新、不可并行（两台连同一网关，同时重启会同时断链）
- 部署后确认 `device waiter-* online`
- 记 2026-09-27 顺手解决的悬案：106 此前无 `online` 而 30 正常，两台配置与
  token 完全相同 ⇒ 差异只可能在旧二进制，8月27日那版落在"未 bind 时收到
  ping 会关连接"的缺陷窗口
- `device_cmd_allowlist` 的替换语义、生效验证、幂等追加方法
- ★ 明确写**白名单只匹配命令名、不看参数**，`find -delete`/`sed -i` 仍能逃
  ⇒ **不要称它为"只读白名单"**

**§3 故障排查**：按"消息没反应 / 命令被拒 / 适配器异常 / 告警是否缺陷"
四条线各给命令；特别标注"群聊 not @bot"与"私聊没回"是两件事

**§4 已知未修**：三项目前是已知限制而非疏漏

文中数字均与现场核对：脚本子命令确实存在（`check`/`deploy`/`rollback`）、
生产白名单确为 22 条、两次二进制大小取自实际部署。

2026-09-27 22:25:58 +08:00

2 Commits