262 Commits

Author SHA1 Message Date
20d357328b docs: 两份 toolcall 文档对齐实现与部署实况
## 契约文档:状态头从「尚未实现」改为「已实现并部署」

生产已注册 7 个 `seq_*` 工具,但文档仍写着"设计定稿,尚未实现" ——
实现者(和读者)会以为 seq 还不存在。

新增 §9.3「实现落点」:设计稿 §8 写的是**六个** `seq_*` 工具,实现时
多了一个 `seq_when_call`(跨序列条件调用独立成工具,否则模型要手写
"先 seq_list 再挑目标再 seq_call",多一次往返且容易挑错),并记下三项
设计之外的修正(`seq_create` O(n²)、`Store.List()` 误认任意 `.json`、
存储用 AST 而非原始文本)。

同时点明:设计条款**仍是契约**,实现与本文冲突时以本文为准并修实现。

## 修一处预先存在的失效引用

§7 末尾 `见 §4.5` —— §4 只到 4.4,该小节不存在。改为按标题名引用
(`§4「结果契约」的 ErrToolNotFound 哨兵`):将来增删小节时不会再次失效。

自查脚本第一版把 8 个**存在**的章节误报成失效引用 —— 标题格式是
`## 1. 背景`(编号后跟 `.`),而我的正则要求编号后是空格。判据自己错了,
改成 `(\d+(?:\.\d+)*)\.?\s` 后才得到真实结果。

## 并行计划文档:部署小节 + 白名单专节

- 原「⚠ 部署前置条件(未完成)」改为「✅ 部署(已完成)」,补实际验证数据
- 记下"实例自述没有编排工具"不是说谎:生产二进制构建于 06:36、seq 引入
  于 `71c894c`(更晚)⇒ `strings | grep -c internal/plugins/seq` 为 0。
  这类"实例自述与代码状态不一致"应先查二进制构建时间,别急着怀疑提示词
- 新增「设备命令白名单改为可配置」:起因、替换语义、daemon 路径的疏漏
- 明确写下**已知局限**:白名单只匹配命令名、不看参数,
  `find -delete` / `sed -i` / `sort -o` 仍放行 ⇒ **不要把它叫"只读白名单"**,
  那会让人以为写操作被挡住了
- 记 106 此前无 `online` 日志的成因(旧 waiter 落在未 bind 时收 ping 会断连的
  缺陷窗口),以及 `ssh` 吃掉 `read` 输入导致"喂了 yes 却说已取消"

删掉了初稿里一段"反引号内 `+=` 写进 heredoc 导致赋值落到子 shell"的说法 ——
脚本与 git 历史里都没有这种写法,属凭记忆误记,不能留。

文中数字均与现场核对:seq 工具 7、二进制 86784400 / 12691402、白名单 22 条。
2026-09-27 20:00:33 +08:00
c022ac98cd fix(deploy): deploy-waiter 的 ssh 加 -n,否则「喂了 yes 却说已取消」
`do_check` 里的 ssh 会从 stdin 读,把后续 `read -p "确认更新"` 的输入吃掉 ——
于是 `bash deploy-waiter.sh deploy <ip> <<< "yes"` 里的 yes 被 ssh 消耗,
read 拿到空串,脚本静默走「已取消」分支。

症状极难定位:脚本本身完全正常、备份逻辑没问题,只是"明明喂了 yes"却
什么也没发生。5 处 ssh 统一加 -n。
2026-09-27 19:52:53 +08:00
20e5d917c3 chore(stress): 加 waiter 远程更新脚本;修 cmp.py 的 docstring 格式
## deploy-waiter.sh:106 / 30 的 waiter 更新

现状(更新前):两台都是 8月27日构建的 /opt/waiter/waiter(11,388,177 字节),
以 root 跑 waiter-remote.service,配置指向 ws://192.168.2.60:9890/…

安全设计:
- 先备份旧二进制(`$BIN.bak-<时间戳>`),失败即回滚(脚本内自动)
- **只换二进制,不动 waiter.yaml**(配置由 deploy 后单独追加)
- **逐台更新并验证,不并行** —— 两台都连同一网关,同时重启会同时断链
- 106 走 admin+sudo、30 走 root
- 验证项:服务 active + 进程时长 + **配置 md5 未变**

用法:`check`(只读)/ `deploy <ip>`(需输 yes)/ `rollback <ip>`

## cmp.py:两处格式

docstring 的 `"""` 紧贴内容、以及函数段之间缺两个空行(PEP8)。纯格式,
无逻辑改动。
2026-09-27 19:42:06 +08:00
71934464cf feat(waiter): 设备命令白名单改为 waiter.yaml 可配置
## 起因

白名单是源码里硬编码的正则(`homeagentAllowCmd`,18 个命令),
而 `waiter.yaml` 里**没有任何键能改它** ⇒ `find` / `grep` / `sed` / `sort` / `tr`
这些排查问题最常用的**只读**命令一律被拒。生产实测:

    device_ctl_cmdrun  device_id:waiter-fnnas  error: command not in whitelist

命令执行完全在 waiter 侧(`device.go` 的 `exec.CommandContext`),插件侧无二次
限制;触发者是 **agent**(经 device_ctl_cmdrun),所以这道闸是机器闸、不是人工确认。

## 改动

waiter.yaml 新增 `device_cmd_allowlist`(字符串数组):

    device_cmd_allowlist:
      - ls
      - find
      - grep
      - sed

- **替换**默认集而非追加:避免"以为加了 find、结果还留着 python3 -c 任意执行"
- 留空 ⇒ 用内置默认集(★ **绝不能变成"全放行"**,那等于静默拆掉闸门)
- 匹配只取命令名**第一段**再整词匹配:`grep -rn x .` 能过,
  而 `grepXxx` / `mygrep` 不会因 contains 蒙混过关;也跳过 `FOO=bar cmd` 的赋值前缀
- `deviceCmdAllowed` 是包级函数变量,由配置赋值 —— 与同文件既有的
  `sendBridgeResult` 同一模式

## ★ 一次真实的疏漏(判据记着)

waiter 有**两条**设备桥启动路径:
- `main.go` 的 `startDeviceBridge` —— 交互/一次性模式
- `daemon.go` 的 `startDaemonDeviceBridge` —— `waiter --daemon`(**生产两台都这么跑**)

我最初只在 `main.go` 里赋值。daemon 路径不经过那里 ⇒ 配置**完全不生效**,
而症状是"配置写了、启动也打了招呼、命令照样被拒",极难定位。
两处都接上了,并加 `TestDaemonPathAppliesAllowlist` 守住。

## 判据(5 条)

- `TestDefaultAllowlistStillBlocksDestructive`  默认集必须挡住
  `rm -rf /`、`dd`、`chmod -R 777`、`mkfs`、fork 炸弹 ——
  **这道闸存在的唯一理由**,谁把它改成"什么都不拦"这条就要失败
- `TestConfigAllowlistExtends`  配置里声明的 `find/grep/sed/sort/tr` 能过;
  配置未含的 `rm -rf /` 仍被拒(证明是"替换"不是"叠加")
- `TestEmptyConfigFallsBackToDefault`  配置为空时回退默认集,**且不放行** `rm -rf /`
- `TestCmdAllowlistFromYAML`  走**真实** `readFile` 解析 yaml(不另写一份解析,
  两处会漂移,而漂移本身就是漏洞)
- `TestDaemonPathAppliesAllowlist`  守住 daemon 路径也应用配置

## 生效方式

106/30 的 `/opt/waiter/waiter.yaml` 追加 `device_cmd_allowlist`,
并更新二进制。启动日志会打印 `device cmd allowlist: N 条(来自 waiter.yaml)`
或 `默认 N 条`,便于确认配置是否真的被读到。
2026-09-27 19:41:43 +08:00
55906b8b7e chore(deploy): 补强部署后验证
原来只说「等 20s 看 /kernel 状态」,等于没验。进程活着 ≠ agent 起来了。
现在逐项核对,每项对应一个真实故障模式:

- 60s 内未见 'kernel ready' ⇒ 判失败并给出回滚命令 + journalctl 尾部
- 注册工具条目数(生产应 18 个左右)⇒ 少了说明插件加载异常
- 'LLM API unreachable' 次数 > 3 ⇒ 内核在 rollback 循环
  (生产设了 max_retries=100000,不可达会一直重试)
- ONNX provider 相关日志 ⇒ 缺失时应是明确错误+降级,不静默假装启用
2026-09-27 19:12:12 +08:00
9b6d946344 chore(deploy): 加生产部署方案脚本(check/backup/deploy/rollback 四段)
## 为什么需要

生产二进制是 **`-tags=onnxruntime`** 构建(86.5MB,.rodata 62.5MB),
而普通 `go build` 只有 37MB —— 差的是 ONNX Runtime 绑定。
`deploy/packaging/package-linux.sh:139` 会显式拒绝非 onnxruntime 构建:

    if ! go version -m "$homed_bin" | grep -Eq 'build[[:space:]]+-tags=.*onnxruntime'; then
        echo "ERROR: homed 不是 onnxruntime 构建,拒绝打 server/full 包" >&2

也就是说:**用错构建方式部署,依存句法分析与多模态向量化会静默失效**。
这个坑我自己踩过一次(拿普通构建去比体积,才发现的),所以脚本第一步
就卡这个判据。

## 四个动作

- `check`    只读检查:服务状态、onnxruntime 标签、libonnxruntime.so、
              模型资产、适配器清单。**不改任何东西**,可随时跑
- `backup`   备份二进制 + 适配器 + unit 文件,并**生成 ROLLBACK.sh**
- `deploy`   check → 人工确认(输入 yes)→ 备份 → install -m 0755 原子替换
              → 重启 → 8 秒后验活;失败时打印回滚命令与 journalctl
- `rollback` 用最近一次备份回滚

## 刻意不做自动回滚

回滚要不要做、什么时候做,是人的判断。脚本只负责把状态保全好,
让回滚成为一条**可执行**的命令,而不是一个自动决策。

## 部署不会碰的东西(已在 check 里显式打印)

- **适配器文件**:`d3eaff4` 的新逻辑在「无历史清单」时不动任何已存在的文件,
  所以生产的 10 个 .lua 保持原样(含那个已含 stream_index 的 openai.lua)
- **数据目录**:51G 的 models/ 与配置都不动,部署只换二进制
2026-09-27 19:11:41 +08:00
07feecba11 docs(plan): 补记全面压测结果与部署前置条件
两版隔离实例实测(规模 3 = 288 条输入),核心差异是**处理数**而非耗时:
旧版 openai.lua 缺 stream_index 透传 ⇒ 多个分片并到槽 0、参数混拼 ⇒
工具一个都没真跑,却因为「少干活」而耗时更短。

    !slowbatch8   旧 0.220s / 0 个  →  新 0.409s / 8 个
    并发 vs 强制串行(新版内部)      N=8 加速 3.88×
    调度器轰炸 288 输入             两版均 100% 通过
    连续稳定性 20 轮                两版均无错误、内核无 panic

规模 1(32 条)与规模 3(288 条)结果完全一致 ⇒ 可复现。

同时记录部署前置条件:生产是 -tags=onnxruntime 构建(strip 后 75MB vs
普通构建 28MB),package-linux.sh:139 会显式拒绝非 onnxruntime 构建。
本次改动未触及任何 ONNX 路径,故压测结论对生产成立,但必须走
deploy/packaging/build.sh 才能部署。
2026-09-27 19:00:53 +08:00
56fe10d3a4 docs(plan): 记录更新前后全面压测结果与部署前置条件
两版隔离实例实测(规模 3 = 288 条输入),核心差异是**处理数**而非耗时:
旧版 openai.lua 缺 stream_index 透传 ⇒ 多个分片并到槽 0、参数混拼 ⇒
工具一个都没真跑,却因为「少干活」而耗时更短。

    !slowbatch8   旧 0.220s / 0 个  →  新 0.409s / 8 个
    并发 vs 强制串行(新版内部)      N=8 加速 3.88×
    调度器轰炸 288 输入             两版均 100% 通过
    连续稳定性 20 轮                两版均无错误、内核无 panic

规模 1(32 条)与规模 3(288 条)结果完全一致 ⇒ 可复现。

同时记录部署前置条件:生产是 -tags=onnxruntime 构建(strip 后 75MB vs
普通构建 28MB),package-linux.sh:139 会显式拒绝非 onnxruntime 构建。
本次改动未触及任何 ONNX 路径,故压测结论对生产成立,但必须走
deploy/packaging/build.sh 才能部署。
2026-09-27 19:00:19 +08:00
190e46908d test(stress): 补更新前后全面对比脚本(cmp.py),修 blast 的计数错误
## cmp.py:更新前后对比的四个维度

★ 每轮都记录**处理数**(响应里有多少个工具结果标记)与**是否出现 error 帧**,
任一不符即记失败。理由:工具调用这一路的失败模式几乎都是**静默**的 ——
工具没跑、参数混拼、只处理了第一个 tool_call,都不报错只是结果不对。
"跑完没崩"完全不能说明它 work。

1. **批内工具调用**:!slowbatchN 在两版上各跑几轮,比中位耗时与处理数
2. **并发 vs 强制串行**(新版内部对照):!slowbatchN vs !serialbatchN
3. **调度器并发轰炸**:多连接并发排队,算通过率
4. **连续稳定性**:20 轮无错误率

## 修掉 mock 的 !serialbatch 缺失

之前只在 /tmp 的临时副本里加过,没进仓库,导致 cmp.py 测「强制串行」时
那个 marker 根本不存在 —— 测出来的"串行"其实是并发,**加速比是假的**
(0.34x / 0.31x,看起来并发比串行慢)。已加回并说明它的用途:跨版本做不了
并发/串行对照(旧版适配器缺 stream_index,工具一个都没真跑),只能在
同一套内核上做。

## 修掉 blast 的计数错误

第一版按 `conns * inputs` 起线程、每个线程又跑 `inputs` 轮 ⇒ 总输入数是
conns×inputs²,分子分母量纲不一致,算出过 **"128/32 = 400%"** 这种荒谬数字。

现在:恰好 conns 个 worker、每个跑 inputs 轮;且分母用**实际发出的**输入数
(含连接失败的),否则连接失败时通过率会虚高。

## 踩过的两个坑(都写进注释)

- 内核 `task.go:353` 有输入去重(`isDuplicateInput`,为 webui 断线重连重放
  而设),相同文本被丢弃并回空响应 ⇒ 每轮输入必须带唯一后缀
- cli 的 auth 帧本身就是 `{"type":"response"}` ⇒ 必须先吃掉它再开始收集,
  否则第一轮的"终止帧"是 auth,测出来耗时恒为 0
2026-09-27 18:56:25 +08:00
d3eaff46f1 fix(lua): 内置适配器按内容自动更新,替代「文件已存在就跳过」
## 原机制是这次全部误判的根源

    if _, err := os.Stat(dstPath); err == nil { continue }

**升级二进制永远不更新已部署的适配器文件。** 于是"改了仓库 ≠ 生产生效",
而这个机制让同类问题可以长期潜伏:

    2026-08-26 15:46  生产 openai.lua 手工补上 stream_index 透传
    2026-08-26 16:10  ddef195 提交,说明里写了但代码没改这个文件

修复当天先在生产落地、32 分钟后才提交入库(漏了这个文件),此后一个月里
两端都没人发现 —— 生产不报问题(它有),仓库的判据也测不到(直接构造 Go
结构体,绕过适配器)。而"升级不覆盖"意味着即使仓库补上修复,已部署的
老实例也不会拿到。

## 新判据(按内容,不按存在)

    文件不存在                     ⇒ 写
    有历史清单且盘上 == 上次内嵌   ⇒ 覆盖(只是没跟上新版本)
    有历史清单但盘上 != 上次内嵌   ⇒ 不动 + 日志(用户改过)
    无历史清单(首跑/从旧版本升级) ⇒ 不动,只补缺失文件(与旧行为一致)

"上次内嵌的版本"记在 `DataDir/adapters/.bundled`(`<name>\t<sha256>`)。

⚠️ 为什么不能无条件覆盖:adapter_path 是可配置项,用户可以把 adapter_path
指向自己维护的适配器。静默覆盖等于丢弃他们的修改,而且**没有报错**。

## 判据(两个方向都要测)

- TestWriteBundledAdaptersSkipsUserModified  用户改过的**必须保留**,
  且改完仍能正常加载(fixture 必须功能完整,否则会因为缺钩子函数而失败 ——
  那是 fixture 问题,不是保护逻辑问题)
- TestWriteBundledAdaptersUpdatesStale       落后于新内嵌的**必须被更新**,
  且**幂等**(三跑不再改写任何文件)

★ 第二条是必要的:只测保护的话,**一个"永远不覆盖任何文件"的实现也能全绿**
  —— 而那正是要修的病。

## 代价(必须知道)

**升级到本版本的这一次,已部署实例的适配器不会更新**(没有历史清单可比)。
从第二次升级起自动生效。要立刻生效就删掉 DataDir/adapters 让内核重新解包。

对本次修的 8 个适配器而言:生产此刻用不到(三个源 llmsproxy/visionllm/
justworker 全是 openai.lua),所以不影响运行;将来启用 deepseek 等源时,
自然就是修复版。

## 顺带

`bundledAdapterNames` 从 writeBundledAdapters 里提出来成包级变量 ——
writeBundledAdapters 与体检判据共用,避免两处各写一份而漏掉某个
(漏掉的后果是该适配器永远不会被更新)。
2026-09-27 18:46:51 +08:00
cff8e10ad5 fix(lua): 补齐 6 个适配器的流式 tool_calls 支持
体检判据(TestAllBundledAdaptersStreamToolCallStatus)报出的三类问题,
本提交解决其中两类;第三类(gemini)未动,原因见下。

## ① OpenAI 兼容族:github / groq / mistral(3 个)

它们的 transform_stream_chunk 与修复前的 deepseek **逐字相同** ——
只透 content/done,tool_calls 处理只存在于 transform_response(非流式)。

后果与 deepseek 相同:流式模式下工具调用全部丢失,模型调不动任何工具,
且**没有任何报错**。生产当前未启用这三个源,但按预设配置的用户会踩到。

照 deepseek 的修法补上(含 reasoning_content 透传)。

## ② 嵌套形态 + 键名错:server / kimicode / anthropic / ollama(4 个)

这四个**有** tool_calls 处理,但发的是:

    { index = N, id = ..., ["function"] = { name = ..., arguments = ... } }

而 homed 的 `agentAPI.ToolCall` 是**扁平**结构,json tag 为:

    id / type / name / arguments / raw_arguments / stream_index

两处都是**静默**失效(Go 侧按 json tag 反序列化,取不到就是零值,无报错):
- **嵌套** `["function"]` ⇒ `name` / `raw_arguments` 取零值
  ⇒ flush 时判「无 name」丢弃,或参数为空
- **键名 `index`** ⇒ `StreamIndex` 取零值
  ⇒ 多个分片并到同一个桶,argsRaw 混拼 ⇒ 每个工具报「参数不是合法 JSON」
  而**一个都没真跑**

已逐项对齐为扁平 + `stream_index`。协议差异都保留:
- anthropic:`content_block_start` / `input_json_delta`,续传片 name 留空
  (内核按 stream_index 累积,补齐 name 后才 flush)
- ollama:tool_calls **整条一次发完**(不分片),故 stream_index 取数组下标

## ③ gemini 未动

它的流式函数处理 `candidates[].content.parts`,**全文件没有任何
tool_calls / functionCall 处理** —— 连非流式路径也没有。补它不是"对齐"
而是新实现,且 gemini 的 functionCall 形态(`functionCall: {name, args}`,
args 是对象而非 JSON 字符串)与 OpenAI 族不同,需要单独判据。

生产三个源(llmsproxy / visionllm / justworker)全部用 `openai.lua`,
不阻塞。留作独立项。

## 判据

- TestOpenAICompatibleFamilyHandlesStreamToolCalls  5 个 OpenAI 族适配器,
  逐个验证 tool_calls 未丢 + stream_index 正确
- TestAnthropicAdapterEmitsFlatToolCallsWithStreamIndex  用 **Anthropic 协议**
  的 fixture(不用 OpenAI 的,否则会因"不适用该 chunk"跳过 —— 看着绿,
  实则没测)
- TestOllamaAdapterEmitsFlatToolCallsWithStreamIndex  用 Ollama 协议形态
- TestDeepSeekAdapterHandlesStreamToolCalls  单列,因它有源预设指向

★ 三个判据按**协议**分文件而非逐适配器:这几个文件的流式函数逐字相同,
共用一个 fixture 会因协议不适用而静默跳过 —— 那等于没测。

## 体检分类

    修前: ✓ [openai]        ⚠ [kimicode server]  ✗ [anthropic deepseek gemini github groq mistral ollama]
    修后: ✓ [openai deepseek github groq mistral]  ⚠ []  ✗ [gemini]
2026-09-27 18:34:33 +08:00
0fdb13749a fix(lua): deepseek 适配器的流式路径处理 tool_calls(此前全部丢失)
## 缺陷

deepseek.lua 的 tool_calls 处理只存在于 `transform_response`(**非流式**路径),
而 `transform_stream_chunk` 只透 content/done:

    return json.encode({ content = delta.content or "", done = (fr ~= nil) })

于是 deepseek 源在**流式**模式下工具调用全部丢失 —— 模型调不动任何工具,
且**没有任何报错**,只是"工具好像不听话"。

## 为什么难发现

- 非流式路径是好的 ⇒ 端到端手工测试也过
- 内核的 tool call 循环默认走**流式**(provider.go 的 stream 分支)⇒ 实际不可用
- 功能判据(core 包的批内测试)直接构造 `agentAPI.StreamChunk{}`,
  **绕过适配器** ⇒ 测不到这一层

配置里 `deepseek` 源预设指向 `adapters/deepseek.lua`,所以任何按预设配置
的用户都会踩到(生产当前未启用该源,配置里 deepseek 相关键为 0)。

## 修法

照 openai.lua 的做法在流式路径补上:OpenAI 兼容格式
`{function:{name,arguments}, id, type, index}` → homed 扁平结构
`{id, type, name, raw_arguments, stream_index}`,含 reasoning_content 透传。

两个容易踩的点也写进注释:
- **不能按 name 过滤**:流式续传片 name 为空但携带 arguments,
  内核按 stream_index 分桶累积
- **必须透传 stream_index**:否则多个分片并到槽 0、argsRaw 混拼

## 判据

新增 TestDeepSeekAdapterHandlesStreamToolCalls:喂两个含 tool_call 的分片,
断言 tool_calls 未被丢弃且 stream_index 正确。修前两条分片全被丢弃。

## 体检分类随之变化

    修前: ✓ [openai]                                       ✗ [deepseek ...]
    修后: ✓ [deepseek openai]                              ✗ [anthropic gemini github groq mistral ollama]
2026-09-27 18:31:42 +08:00
17bc9a5553 docs(stress): abtest 补「跨版本对比的陷阱」—— 老版本可能只是没干活
脚本原本只写「加速比 = 基线延迟 / 新版延迟」。实测发现跨版本对比时这个
数字**没有意义**:

    N    老版本 中位/处理数      新版本 中位/处理数      算出的"加速"
    2    0.273s / 0 个        0.480s / 2 个          0.57x
    4    0.273s / 0 个        0.492s / 4 个          0.55x
    8    0.273s / 0 个        0.512s / 8 个          0.53x

"老版本更快"是假的 —— 它只是没干活:适配器缺 stream_index 透传 ⇒ 多个
分片并到槽 0 ⇒ argsRaw 混拼 ⇒ 每个工具报"参数不是合法 JSON"而一个都没
真跑。

★ 跨版本能比的硬指标是**处理数**;耗时对比只在新版内部做(混一个非并发安全
工具触发整批降级)才有意义 —— 那种对照下 N=12 时加速 5.72×。

顺带记下:老版本的内核分桶逻辑其实完整(`idx := tc.StreamIndex` + `accs[idx]`,
来自 2026-08-26 的 ddef195),缺的只是适配器那一个字段;而生产在当天 15:46
就手工补上了,比该提交(16:10)早 32 分钟。
2026-09-27 18:30:09 +08:00
8fafd5eafe test(stress): 补批内并发压测与 A/B 对比脚本,并给 mock 加多 tool_call 能力
## 缺口

现有 kernel-stress 只压**调度器**(多连接排队 + L4 中断 + 驻留子),mock 每轮
只发**一个** tool_call。而内核的并发判据是:

    if f == nil || len(f.PendingTools) <= 1 { return false }

⇒ **一个 tool_call 永远不并发**。所以现有压测压的全是串行路径,批内并发
一条都没走过。

## mockllm.py:让 mock 能发多个 tool_call

- `!batchN`   N 个全部 ParallelSafe 的只读工具 ⇒ 强制走 stepToolBatch
- `!mixedN`   夹一个 knowledge_create(未声明并发安全)⇒ 验证整批降级
- `!slowbatchN` N 个 sleep 型 cmd_run(单工具约 200ms,时长递增)
  ⇒ 工具慢才能让并发的收益从噪声里显出来;时长递增使**完成序与声明序相反**,
  可据此判定"是否按声明序落消息"
- `!serialbatchN` 在 !slowbatch 基础上插入一个非并发安全工具 ⇒ 强制整批串行,
  作为并发对照的另一半
- `!img` / `!ocr` 触发多模态工具路径(不加载模型,只验内核 IPC 接线与错误处理)
- `!err` / `!hang` 故障注入

### 三个协议细节(踩过才知道,都写在注释里)

1. **必须带 `index`** —— 内核按 `StreamIndex`(上游 JSON 的 index)分槽累积
   arguments。缺 index 时所有分片落到槽 0,几个 tool_call 的参数被**混拼**,
   症状是每个工具都报"参数不是合法 JSON"而工具一次没真跑过。
   单 tool_call 时不设 index 也正常,所以老 mock 一直没暴露。
2. **必须按协议分片** —— 一个 chunk 一个 tool_call,各自带 index;
   后续 chunk 只续 arguments。整数组塞进一个 chunk 会被内核按"续传"语义累积。
3. **每个工具都要发"带 name 的首片"** —— 我第一版只给第 0 个发首片、其余直接
   发续传片,看起来省事,但内核 flush 时按"无 name 即丢弃"处理,
   于是 idx=1/2/3 全被丢,只跑 1 个工具。

## batchstress.py:批内并发压测(带校验)

只看峰值是不够的 —— 校验:工具是否真跑(响应里应有结果标记)、
消息顺序是否稳定(并发执行但按索引落消息)、mixed 批是否整批降级。

## abtest.py:串行 vs 并发的定量对比

同一套内核上用 !slowbatch / !serialbatch 两组对照,交替执行抵消机器负载漂移,
取中位数(长尾会污染均值)。

★ 判据里加了"工具是否真执行"这一项:**只看耗时是不够的** —— 出现过
"内核 274ms 就回复、工具一个没跑"的情况,那种情况下并发与串行都是 0.2s,
加速比毫无意义。

## 实测(隔离 netns 实例,mock + 内核同网段,5 轮中位)

    N    并发        串行         加速     上限
    2    0.481s    0.685s      1.42x    2
    4    0.491s    1.114s      2.27x    4
    8    0.513s    2.037s      3.97x    8
    12   0.531s    3.039s      5.72x    12

并发批耗时几乎不随 N 增长,串行批严格线性。

★ 另一个踩过的坑(abtest 脚本自己的):内核有输入去重
(task.go:353 `isDuplicateInput`,为 webui 断线重连重放而设),相同文本会被
丢弃并回空响应。第一版每轮发同一个 marker ⇒ 只有第 1 轮有效,后面全是
0 秒 0 工具。修法是每轮加 `time.time_ns()` 唯一后缀。
2026-09-27 18:29:39 +08:00
61a2d56bbb test(lua): 记录仓库/生产适配器漂移的具体内容与时间线
生产 adapters/openai.lua(4853 字节)含 stream_index,仓库 ddef195 时的版本
(4709 字节)不含。生产文件时间 2026-08-26 15:46,比 ddef195 提交(16:10)
早 32 分钟 —— 该提交说明里写着「openai.lua 输出 stream_index 字段」,
但 --stat 显示它没改这个文件:修复先在生产生效,入库时漏了。

于是「生产能跑多工具、仓库跑不了」持续一个月而两端都没人发现:生产不报
问题(它有),仓库的判据也测不到(直接构造 Go 结构体,绕过适配器)。

判据本身不变(仍是诊断式 t.Log),只把这条漂移的具体内容写进注释 ——
它是理解本次全部误判的关键背景。
2026-09-27 18:29:32 +08:00
969206eb85 test(lua): 加适配器漂移报告 + 键名契约判据
上一提交(66200ff)纠正了一处误判:仓库的 openai.lua 缺 stream_index 透传,
而生产实例早就有 —— 仓库版本落后于生产。这个漂移当时没有任何判据能发现。

## 两条判据,定位不同

### TestBundledAdaptersMatchDeployedOnes —— 诊断式,刻意**不**作为失败判据

实测结果:生产部署的 7/10 个适配器比仓库旧(anthropic 2537 vs 5144 字节),
而 openai 那份反而领先。这**是正常的** —— 生产是长期运行的部署,适配器在它首次
创建时就解包落地,之后仓库一直在演进。

若把"必须一致"写成失败判据,它会在任何老部署上恒红,而恒红的判据会被无视 ——
那等于没有判据,甚至更糟(它会掩盖真正的漂移)。所以这里只把差异摆出来。

但它顺带把**部署陷阱**摆到了明面上:

    vm.go writeBundledAdapters: if 文件已存在 { continue }

升级二进制**不会更新已部署的适配器文件**。于是"仓库改了适配器但老实例上不生效"
与"仓库根本没改"在现象上完全一样 —— 这大概就是仓库长期缺 stream_index 却
没人发现的原因之一。

### TestAdapterEmitsOnlyKnownFields —— 这条才是能自动抓 bug 的

契约 = agentAPI.ToolCall / StreamChunk 的 json tag:
`id, type, name, arguments, raw_arguments, stream_index`(+ 上游原样透传的
`index` / `function`)。

★ 为什么必须有:Go 侧按 json tag 反序列化,**键名拼错会静默取零值**。
`streamindex`(少个下划线)与"没写这行"的表现完全一样 —— 无报错、字段为零、
分桶全部并到槽 0。这正是本次 stream_index 缺失的形态。

判据只看"适配器吐出来的键名对不对",与环境无关,所以能在 CI 里恒定生效。

## 顺带确认的一件事(事后查明:是我的操作失误)

压测实例解包出的 openai.lua 是 4709 字节(无 stream_index),而二进制 embed
里是 5672 字节(有)。`rm -rf` 后重新解包**仍是旧的**。

我逐行读过 `writeBundledAdapters`,只找到 embed 一条来源,一度判为"未解释的
矛盾"。**真因是操作失误**:`rm -rf` 之后启动的那一轮,用的还是修复前编译的
/tmp/homed-stress —— 删除与重编之间隔了几轮,中间又用旧二进制起了好几次
实例,每次解包出来的自然都是旧版。

用当前 main 重新构建 + 全新数据目录验证:全新解包 5672 字节、含
stream_index×3、md5 与源文件一致;删掉再解一次仍一致;启动日志有
`[lua] installed bundled adapter: openai.lua`。⇒ **writeBundledAdapters 无缺陷**。

★ 教训:验证"二进制内嵌内容是否更新"时,必须确认跑的就是**刚编译出来的那个
二进制**。否则会得出"代码有 bug"的错误结论 —— 我确实这么怀疑了好几天。

(下面那条"部署陷阱"观察本身仍然成立:升级二进制确实不会更新已部署的适配器
文件。但它与这次的现象无关。)
2026-09-27 18:29:15 +08:00
66200ff226 test(lua): 补适配器 stream_index 透传判据 + 全适配器体检
## 先纠正一件事:这个修复在生产上早就存在

最初我判断"`openai.lua` 缺 stream_index 透传、批内并发在生产走不通",并据此
写了实现。**核对生产实例后,这个判断是错的**:

    生产 /home/newqqagent/adapters/openai.lua   130 行  含 stream_index
    仓库 950b21b^                                128 行  无 stream_index

生产那份的注释是「透传上游分片 index:并行多工具调用时内核按它区分归属桶」——
简洁,与本提交新增的长注释不同。**也就是说仓库版本落后于生产,生产一直没这个
问题。** 我修的是"仓库与生产的差距",不是"生产正在发生的故障"。

## 真正缺的是判据

`internal/agent/core/stream_index_test.go` 的
TestAccumulateStreamParallelToolCallsByIndex 直接构造 Go 结构体
`agentAPI.StreamChunk{...}`,**不经过 Lua 适配器** —— 所以"适配器有没有把
index 透传出来"它永远测不到。生产有、仓库没有,判据也发现不了。

而提交 ddef195(2026-08-26,"流式并行 tool_call 按 JSON index 分桶")的说明里
写着「openai.lua 输出 stream_index 字段」,Go 侧也加了
`StreamIndex int json:"stream_index,omitempty"` 并注明"lua 适配器以
stream_index 键透传" —— 但那次提交**根本没改 openai.lua**(6 个文件里没有它)。
说明与实现不符,而没有任何判据能发现。

## 本提交做的事

① 让 openai.lua 与生产一致(补 stream_index 透传),并说明为何缺它会静默失效:
   多个分片全部并到槽 0 → argsRaw 混拼 → 每个工具报"参数不是合法 JSON",
   而**工具一次都没真跑过**。单工具时上游 index 恒为 0,缺省也是 0,
   所以问题只在"一轮多个 tool_call"时显形。

② 新增 internal/lua/adapter_streamindex_test.go,**真正加载并执行内嵌的
   openai.lua**(复用 VM 的真实路径),三条判据:
   - TestOpenAIAdapterPassesThroughStreamIndex  3 个 tool_call 的
     stream_index 必须是 0/1/2
   - TestOpenAIAdapterKeepsContinuationFragment 续传分片(只有 arguments、
     没有 name)的 stream_index 必须正确 —— 它是分桶的**唯一**依据
   - TestAllBundledAdaptersStreamToolCallStatus  全 10 个适配器体检

★ 第三条刻意**不**用 t.Skip 掩盖不支持的适配器 —— 早期版本一律 Skip,结果
"完全不支持流式工具调用"也会让整体显示为绿,而绿会被误读成"都支持"。
现在分类记录:openai ✓ / kimicode+server 透传嵌套形态需另修 /
其余 7 个未产出 tool_calls。

③ 体检顺带暴露的、与本提交无关但已记录的问题:
   - **仓库 vs 生产漂移无判据**:仓库适配器落后于生产时,只有靠人工对比才发现
   - **部署陷阱**:vm.go writeBundledAdapters 是
     `if 文件已存在 { continue }`,升级二进制**不会更新已有适配器文件**。
     这可能正是"仓库缺透传却没人发现"的原因之一
2026-09-27 17:48:16 +08:00
f8add88dbc perf(stagehost): 工具声明查询免去结构体拷贝(热路径 1000 并发下省 1000 次)
## 问题

StageHost.ToolDef 返回 &def —— 一次**结构体拷贝**:3 个 string + 2 个 map 头
+ 2 个 bool + Cleaner 函数指针。

而 toolParallelSafe 在**每批**并发判据里对每个工具各调一次:
batchRunnable 遍历 PendingTools → toolParallelSafe(tc.Name)。
1000 并发批次 = 1000 次结构体拷贝,全在判定阶段(执行之前)。

不是"逃逸漏洞"(Go 1.22+ 循环变量每轮独立,go.mod 是 1.25),纯粹是白拷贝。

## 修法

ToolDef 保留 —— 它要给需要完整声明的调用方(Cleaner、Parameters 校验),
返回副本也是**有意**的(ToolDef 里有 map 与函数指针,交出内部元素会把
可变引用漏出去)。

新增免拷贝查询,热路径专用:

    ConcurrencySafeOf(name) (safe, found bool)   // 只读 ParallelSafe && !Serial
    NoMemoryOf(name)       (v, found bool)
    HasTool(name)          bool

全部在持 RLock 下走同一个 findLocked。

`toolParallelSafe` 切到 ConcurrencySafeOf。语义完全等价 —— 两者都算
`ParallelSafe && !Serial`,只差一次拷贝。

## 判据(两个都防"优化悄悄改了语义")

- TestNoCopyQueriesMatchToolDef  7 种声明组合(plain / parallel / serial /
  both / nomem / all / serial_nomem)下,免拷贝查询与 ToolDef(...).字段
  **逐字段等价**;不存在的工具三态一致(false/false/true)。

  ★ 这类优化最危险的失败模式就是语义漂移:并发判据若读错字段,
    能并发的批次会**悄悄退化成串行** —— 没有任何报错,只表现为"变慢了"。
    所以判据必须逐个组合比对,而不是只测一个典型值。

- TestNoCopyQueriesConcurrent  32 goroutine × 50 工具并发查询,
  -race 无竞态且结果与串行一致。

回归:go build ./... 通过;go test ./internal/... 全绿;
go test -race ./internal/agent/core 通过。
2026-09-27 16:29:24 +08:00
8a98969fac refactor(parallel): 内置工具的并发声明改为 SDK 同构的结构体字段
上一提交(2232d54)把并发安全改成了声明式,但内置工具那一路仍是将就:
声明靠往 required 变参里塞字符串 "toolParallel" 传递。

## 为什么那不算声明式

对照 SDK 的 NoMemory 逐条看:

| | SDK NoMemory | 当时的内置工具 |
|---|---|---|
| 载体 | `ToolDef.NoMemory` 字段 | required 里的字符串 |
| 拼错后果 | 编译器报错 | **静默失效** |
| 内核读取 | 查结构体字段 | 遍历工具表 + 解析字符串 |

"少一个工具能并发"恰恰是最难察觉的一类问题 —— 没有任何报错,
只是并行的批悄悄退化成串行。

## 改法

### 1. sdk.BuiltinToolDef 补声明项(与 NoMemory 同构)

```go
type BuiltinToolDef struct {
    Name, Description string
    Parameters        map[string]interface{}
    ParallelSafe      bool   // 零值 false = 默认串行(保守)
    Serial            bool   // 优先于 ParallelSafe
}
func (d BuiltinToolDef) ConcurrencySafe() bool { return d.ParallelSafe && !d.Serial }
func (d BuiltinToolDef) ToSchema() map[string]interface{}
```

### 2. 工具定义处声明

```go
toolDef("memory_merge", ...)                                  // 默认串行
toolDefWith("knowledge_search", ..., []string{"query"}, parallelOpts())  // 已核实只读
```

### 3. 内核一次聚合并缓存(照 StageHost.NoMemoryToolNames)

```go
graphOf()      // 快照
declareParallelTool(name)   // init 里登记
concurrencySafeOf(name)     // 查表
```

不再每次 toolParallelSafe 都重跑 buildToolDefs()(O(工具数) 重复劳动,
而声明是静态的)。

## ★ 一个更隐蔽的问题:声明表曾经是空的

`declareParallelTool` 最初挂在 `toolDefWith` 的**运行时调用**上。而那 9 个
工具全在 `if a.knowledge != nil` / `if a.social != nil` / `if a.parentID != ""`
之类的条件分支里 —— 测试环境根本不走进这些分支 ⇒ 聚合表始终为空。

而判据查的是同一张表,于是**自证通过**:全绿,并发能力为零。

这就是判据设计的教训 —— 判据和数据源同源时,它证明的只是"我和我一致"。
现在判据双向核对:名单里的必须真声明了,声明了不在名单里的也会报出来;
并额外验证内核**真的读得到**(concurrencySafeOf 而非读同一份 map)。

## 顺带修掉的迁移事故

用正则批量改造 30+ 个 toolDef 调用点时,把 `person_set_trait("name", "content")`
这类**变参**调用误改成 toolDefWith(... "name", "content") —— 那是**写工具**,
差点被标成可并发。已全部回退并逐一核对:9 个声明并发,0 误伤。
2026-09-27 15:59:11 +08:00
374c19246b fix(seq): 修掉 seq_create 的 O(n²),并加极端压测
## 起因:1000×1000 压测直接跑爆

用户要求「1000 条序列 × 每条 1000 个组内 toolcall」。第一版跑满 8 分钟超时。
分阶段计时定位到瓶颈:

| 阶段 | 200 条 × 1000 工具 |
|---|---|
| 创建 | **27.0s**(135ms/条,**随序列数线性增长**) |
| 执行(组内 1000 并发) | 0.55s(20 万次调用,2.7µs/次) |
| 删除 | 4.7ms |

瓶颈在创建,不在执行。

## 根因

```go
// handlers.go:70 —— 每次 seq_create 之后
graphErr := p.store.CheckGraph()

// store.go:166 —— List() 全量 + 逐条 Load() 全部序列
```

1000 条各 250KB ⇒ 每次创建都重读 250MB 并反序列化。第 N 条的创建代价
随 N 线性增长,总计 O(n²)。

## ★ 走过的弯路:我一度建议「把校验挪到运行期」—— 那是错的

store.go:163 明确写着:

    两条检查(都必须在**建序列/保存**时做,而不是等运行):
      1. 每个 seq_call 的目标必须存在(不存在会在运行期才发现,浪费一整轮)

**校验时机是语义,不是性能旋钮。** 目标不存在若等到运行才发现,模型已经
白白花掉一整轮工具调用。性能问题不能靠挪语义来解。

## 修法:缓存调用边,Save 做 O(1) 增量

```go
// Store 新增
graph map[string][]string   // 序列名 → 它调用的目标(裸名)

// Save:  只更新这一条的边
s.graph[seq.Name] = edgesOf(seq)
// Delete: 移除这一条的边
delete(s.graph, name)
```

`callTargets` 只依赖 AST,不必每次从盘重建。**校验语义完全不变** —— 目标
存在性与三色 DFS 环检测都照旧在建序列时执行。

## 判据

- TestStoreGraphCacheKeepsSemantics  逐条钉住三个保证:目标存在性 ✓、
  环检测 ✓、删除后不再误报成环 ✓
  (这类优化最危险的失败模式是"校验还在跑但少查了某种情况")
- TestStoreSaveScalesLinearly       分段对比后半程/前半程每条耗时。
  ★ 判据自己改过一次:初版用「总耗时 ÷ 单条耗时」,而单条只有 48µs 时
    噪声占比过高,同一份代码两次跑出 84× 和 203× —— 判据不稳定时报的
    失败就是噪声,比没判据更糟。改成分段对比(平方时后半程会慢约 n/2
    倍,线性时基本持平),阈值 3 倍留足磁盘与 GC 抖动余量。
  实测 300 条:84~203× 单条(线性期望 300×),平方会是 90000×。

## 压测本身也修了两个自己的 bug

- 源文件目录与 store 目录分离时只改了写入侧,清理侧还指着 store 目录 ⇒
  报 "no such file"。看起来像文件被提前删了,真因是路径拼错。
- newE2EPlugin 的 runner 参数写死 *e2eRunner,压测换替身就编译不过 ⇒
  改为接受 seqRunner 接口。

## 压测规模

TestStressExtreme_ThousandSeqs 现为 1000 条 × 1000 toolcall(O(n²) 修复后
可跑)。判据全是**不变量**:每工具恰好调一次、1000 槽在交错延迟下仍按
声明序合并(并发下若按完成序合并必然错位)、删除后无残留。
2026-09-27 15:58:54 +08:00
2232d5483c feat(parallel): 并发安全改为声明式,并审计标注 37 个工具
把"能不能并发"从内核硬编码名单改成**工具自己的声明项**,形态照 SDK 的
NoMemory 走。

## ★ 起因:提示词在跟内核不一致

阶段 2.5 写进提示词的「内核默认并行执行」当时是**假的**:toolParallelSafe
只查 stageHost 与 io 两个来源,而全仓 ParallelSafe:true 的生产代码数量
是 **0**。于是除碰巧只发一个工具外,每一批都整批串行回退,而提示词正教
模型把多个查询放同一轮。**内核行为与提示词不一致 = 对模型说谎。**

并发面:0 → 37 个工具(18 插件 ParallelSafe + 19 插件 Serial + 9 内置只读)。

## 声明形态(照 SDK,不自创)

### 插件:结构体字段
    s.RegisterTool("config_get", sdk.ToolDef{
        Name: ..., Description: ...,
        Parameters: map[string]interface{}{...},
        // 已核实只读:…
        ParallelSafe: true,      ← 插在 Parameters 之后、handler 之前
    }, p.handleGet(s))

位置与 SDK 的 NoMemory/ContextPolicy/RecallPolicy 一致:Name 在首位,
声明项在末尾,不打散 gofmt 对齐。

### 新增 SDK 声明项:ToolDef.Serial
ParallelSafe 的**反向**标记,判据优先级高于 ParallelSafe。
为什么需要:ParallelSafe 零值 false 已表达"安全",插件无法区分"我没想过"
与"我确认过必须串行"。没有这个区分,工具作者只能靠命名约定传递意图。

内核已消费它(io.ToolDef 同步加字段对齐),并有判据守"Serial 胜出"。

### 内置工具:toolDef 的 toolParallel 选项
内置工具以裸 schema map 下发,没有 ToolDef 结构,所以用变参选项:
    toolDef(名字, 描述, 属性)                  // 默认串行
    toolDef(名字, 描述, 属性, "toolParallel")  // 已核实只读,可并发
读工具表的老调用点一行不用动,声明就写在工具定义那一行。

## ★ 走过的弯路(都留了判据)

1. **硬编码白名单**:先在 toolParallelSafe 里查一张
   builtinParallelSafeTools map。那把声明从"工具自己"搬回了内核 ——
   工具改名/新增不会自动跟着变,得靠一条 grep 源码的判据才能发现漂移,
   而判据一改就忘。已删,改为从定义读。

2. **判据前提错(同一个坑踩了两次)**:拿裸 &Agent{} 的 buildToolDefs 输出
   当"实际可见工具",但这 9 个内置工具全在条件分支里(a.knowledge != nil /
   a.social != nil / a.parentID != ""…),裸 Agent 一个都不产出 ⇒ 全部误报
   "声明形同虚设"。第一次叫它"幽灵条目",没认出是同一个坑。

3. **注释模仿真实签名污染判据**:toolParallel 的用法注释写着
   `toolDef("knowledge_search", ...)`,判据按文本匹配先撞上注释。

4. **buildToolDefs 的 nil 不一致**:开头判了 a.io != nil,末尾却无条件
   a.io.ListChannels()。任何无 IO 的 Agent 调它都 panic —— 而 panic 报在
   io 包里,根因在 tooldefs.go。已补。

5. **插入脚本用正则找"最后一个顶层字段"**:被嵌套 map 里的同形文本骗到,
   823 处错误重排把文件改坏。改用括号深度 + 记录进入深度 3 的行号
   (空 properties 会让深度在同一行进出平衡,只判 depth==2 不够)。
   工具在 SDK 仓 tools/annotate_parallel/,复用时用绝对路径。

## 提示词措辞同步修正
「默认并行执行」→「尽量并发执行,但这是**逐工具判断**的」,并教模型
**把查询类放同一轮、写操作单独发一轮**(写和查混在一批,整批都串行)。

## 判据
- TestSerialOverridesParallelSafe          Serial 优先于 ParallelSafe
- TestToolParallelDeclarationsAudit        并发面不许再归零
- TestNoToolDeclaresBothParallelAndSerial  两者同标即谎话
- TestBuiltinParallelDeclaredWhereDefined  声明写在定义处、且内核真读到
- TestStoreListIgnoresForeignJSON          压测抓到的 List() 缺陷
2026-09-27 15:15:57 +08:00
b1b96b788d test(seq): 三个压力测试 —— 超长序列 / 100 工具并行 / 串行降级
与单元判据的分工:单元判据钉住**语义**(一条路径对不对);压力测试钉住
**规模下的不变量**。沿用仓内既有范式(media/soak_test.go):
testing.Short() 跳过 + 独立 -run 跑。

① 超长序列
   · 解析 10 / 100 / 1000 组(250KB 文本):6.8ms,无硬上限误报
   · 执行 200 组 × 5 工具 = 1000 次调用:2.0ms
     断言:每工具恰好被调 nGroups 次(无遗漏/重复)、结果含**最后一组**
     —— 组间串行在规模下仍成立

② 100 工具组内并行
   · 100 工具全声明并发安全 ⇒ 11ms,完成顺序**确实被打乱**(判据会校验
     这一点,否则它测不到并发)
   · 断言每个槽拿到**自己**的结果(并发下若按完成顺序合并就会错位)

③ 串行降级
   · 50 个工具里**一个**未声明并发安全 ⇒ 整批退回串行,
     完成顺序严格等于声明序(106ms vs 并发的 11ms,降级确实生效)

★ 压力测试第一次跑就抓到一个**真实分层缺陷**:
「含非并发安全工具则整批串行」这条规则**只在上层 runGroup 实现**,
而引擎层 execGroup 只信 g.Parallel 字段 ⇒ 任何人直接调 execGroup
都会拿到不受约束的并发。
已修:降级判据下沉到引擎层,新增 batchCanRun(g, runner),
toolRunner 增加 parallelSafe 方法(生产路径行为不变,只是把判据
放到了它本该在的层)。

过程中压测自身也暴露了两个测试缺陷(都修了):
· fixture 让 100 个工具写同一个标量槽 o,被静态校验正确拦下
  ("组内并行下同名写入是数据竞争")—— 压测不该去撞这条规则;
· ★ e2eRunner.called 是无锁 append,100 工具并发时 -race 报出**真竞态**
  (不是误报)—— 加锁 + 提供 calledSnapshot 供断言。

另:建序列与跑序列原本用了**不同 plugin 实例**(序列存在实例的 store 里,
换实例就读不到自己刚建的),已改为同一实例。

回归:go test -race ./internal/plugins/seq 全绿;go test ./internal/... 全绿。
2026-09-27 14:16:09 +08:00
8ca28eb071 feat(toolcall): 工具结果只统计不裁剪(方案 B),并治掉 seq 侧的静默截断
问题(核实过):工具结果进 f.Msgs 时**没有任何长度上限**(task.go 直接
`Content: result`),内核也**不预检**是否超长 —— 超限由上游 API 报错。
时间线那侧有预算(ContextTokens = 0.8×窗口,进消息前就裁过),但那只管
a.context 的历史事件,**不管单条工具结果** ⇒ 一条巨大结果可能直接冲破
预算而内核不会提前发现。

为什么**不裁剪**(与方案 A 的取舍):
· 截断会让模型拿到**残缺**信息,而截断位置由内核武断决定;
· 模型无法得知"这里被截断了",会基于残缺数据下结论 —— 与本仓反复
  吃亏的「静默降级」同族(`20s` 少引号 → 静默降级 → cmd_run 失败率 34%);
· 处置权应交给调度器/上层(告警、拒绝、或让模型自己换更窄的查询),
  而不是内核单方面替模型决定。

改动:
· core/toolresult_budget.go: checkToolResultSize 只**计数+报告**;
  阈值默认 = ContextTokens/8(一条吃掉全部预算会把其它上下文全挤掉);
  报告经 toolResultReporter(可替换),默认 logReporter —— **不给模型发
  消息**:那是在已花掉的 token 之上再加一条 system,且对当前这轮决策无帮助。
· 接入点在 stepToolAfter 的 toolMsg 落定**之后**(那里才是模型最终看到的
  内容;stepToolExec 拿到的尚未经 after_toolcall 改写)。
· TaskFrame 记 oversizeTools / oversizeToolNames,供调度器与状态面查询
  "是否有工具在稳定产出超大结果"。

★ 顺带治掉 seq 侧一处**我自己留下的静默截断**:
handlers.go 里我当初随手写了 truncate(…, 160),把变量槽静默截到 160 字
且**无任何标注** —— 正是我批评过的静默降级。
改为 renderSlot:≤160 给全;超过则显式标注「已截断:共 N 字,此处显示前
160 字」并给出改法。**槽里存的始终是完整值**,截断只影响回填文本长度。
端到端判据 TestSeqRunDoesNotSilentlyTruncateSlot 抓到了这个缺陷
("变量槽被截到 160/5000 字却没有任何标注")。

判据(toolresult_budget_test.go,4 条):
· 400KB 结果触发超限报告(含工具名与 token 数)
· ★ **默认不裁剪**:200KB 结果原样进 tool 消息(方案 B 的核心不变式)
· 小结果不误报(噪音会淹没有效信号)
· 报告文案可执行:带工具名、token 数、改法建议

变异验证:去掉统计调用 ⇒ 两条判据 FAIL("统计没生效" + "被裁剪了")。

另:检查项报 stepToolBatch 的 goroutine 竞态,-race 实测**误报**——
循环变量显式传参(非闭包捕获)、且按索引写各自槽位(非共享 map),
`-race` 下 20 轮并发判据全绿。
2026-09-27 14:05:38 +08:00
116dc413f0 feat(seq): 新增 seq_help —— 格式说明 + 可照抄示例
动机来自真机实跑:模型写序列时踩了三个坑,各试 1~3 次才改对
  ① tools 漏末尾的 ';'       → 「末尾缺少 ';'」
  ② group 的 in 传成字符串     → 重试 3 次
  ③ as 指向未声明的 out 槽      → 静态校验拦下
这三处都是**格式细节**,塞不进工具描述(有长度限制),却恰是模型最易错处。
散落在七个描述里等于没有集中入口。

实现(help.go + tools.go + plugin.go):
· seq_help 无参数、纯文本返回(与仓内 output_send__*_help 同范式)
· 「格式要点」逐条写明:in/out 必须是**对象**、tools 必须是**字符串**、
  每个 tool 后(含最后一个)都要 ';'、as 必须在 out 声明、
  groups 与 file 二选一、组内并行组间串行
· 「条件 when」列出支持的表达式形态
· 「可照抄的完整示例」给一行**单行紧凑**的合法序列

★ 判据(plugin_test.go,3 条):
· seq_help 已注册、有 description、不声明并发安全
· 内容覆盖真机踩过的**每一个**坑(判据从"坑"出发而非从"打算写什么")
· ★ 示例**自己能被本包解析器接受**:validateHelpExample 从帮助文本里
  抽出示例喂给 Parse —— 模型是照抄的,示例自己解析不过就是给模型挖坑。
  而"从文本里有没有某个词"是看不出这类 bug 的。

过程中判据自己错了两次(都被这条示例判据照出来):
1. 抽取用 strings.Index(help, `{"name"`) ⇒ 先命中「格式要点」里**有意写的**
   示意片段,截到非示例的内容,报出莫名其妙的 invalid character '…'。
2. 修完又混用两套偏移基准(base 的下标拿去切 help)⇒ invalid character '\xaf'。
   ⇒ 重写为全程在同一 base 上定位。
★ 两次都说明:**判据的抽取逻辑本身就是需要验证的代码**,
它出错时报出的信息极具误导性(看起来像实现有 bug)。

示例形态也改过一次:原为多行缩进 JSON,改为**单行紧凑** —— 模型照抄时
免去缩进/换行带来的额外风险。

变异验证:去掉示例里的末尾 ';' ⇒ 示例判据 FAIL。

另一处:加 seq_help 后「恰好注册 6 个工具」判据 FAIL(实际 7)——
这正是那条判据的用意(防止悄悄多加工具稀释工具面),已更新并注明原因。

回归:go build ./... 通过;internal/plugins/... core sdk 全绿。
2026-09-27 13:48:15 +08:00
0b96d6d78c fix(seq): 类型不匹配的错误改成模型可执行的话(真机实跑发现)
真机实跑(独立实例)发现:模型把 group 的 `in` 传成字符串 "{}",
拿到的是 encoding/json 的原始报错:

  json: cannot unmarshal string into Go struct field rawSeq.groups.0.in
        of type map[string]string

这句说的是**事实**(string 解不成 map)而不是**该怎么做**
(in 应该写成对象 {"键":"类型"});残留的 `rawSeq` / `Go struct field`
更是 Go 内部实现细节,对模型无意义且会误导它去猜一个叫 rawSeq 的东西。
模型为此**重试了 3 次**才改对。

这与本仓反复吃亏的那类问题同源:`20s` 少引号 → 静默降级 →
cmd_run 失败率 34%。**报事实不报改法,模型只能猜。**

改动(parse.go):新增 friendlyJSONError,把原始报错翻译成可执行文案
· in / out 类型不符 ⇒ 说明"应写成对象 {键:类型};无入参请写 {}"
· tools 类型不符 ⇒ 说明"应写成字符串(内容是 ; 分隔的 JSON 对象)"
· groups / name / when / missing / timeout / on_error ⇒ 逐个说明期望
· 未知字段 ⇒ 列出 group 允许的全部字段名(拼写错误最常见)
· shortFieldName 剥掉 `rawSeq` 这类包内类型名前缀
· jsonKind / goTypeName 把 Go 类型翻译成模型看得懂的说法

判据(parse_test.go,2 条):
· in 传字符串 ⇒ 错误须指名字段、须说明该传对象、**且不得残留 Go 内部类型名**
· tools 传数组 ⇒ 错误须指明 tools 且说明它是字符串

★ 变异验证时踩了一次坑:第一次变异让 friendlyJSONError 不被调用,
结果**编译失败**(函数变成未使用),判据压根没跑,我却看到 "ok"。
改用可编译的变异(函数保留、开头直接 return err)后判据正确 FAIL。
★ 教训:**"变异后判据通过"要先确认变异真的生效**——编译失败 ≠ 判据通过。

真机复验:模型读一次即懂,并明确说"提示里的意思很明确";
修复前它为此重试 3 次。

回归:internal/plugins/... internal/agent/core internal/sdk 全绿。
2026-09-27 13:43:39 +08:00
7e1169bcda feat(kernel): 内置工具注册进 ToolAPI 面(方案 B,补真机实跑发现的架构缺口)
真机实跑实证(独立实例 /tmp/seqtest,未触碰生产):
  seq_run 报「工具 knowledge_list 不存在或未注册」,
  而**同一轮模型直接调 knowledge_list 是成功的**。

根因:`memory_*` / `knowledge_*` / `doc_*` / `person_*` 这 20+ 个是
**内核内置**工具,在 core.executeToolCallInner 里按**前缀分派**,
由 buildToolDefs 直接生成 schema,**从不进 StageHost / IOManager**
⇒ ToolAPI(只有插件工具 + IO 设备工具)既查不到也调不了。
后果:序列只能编排插件/设备工具,无法编排记忆/知识/文档/人物
——恰恰是最常用的能力。

方案 B 的实现:
· internal/sdk: 新增 BuiltinProvider(Defs/Exec)与 SetBuiltinProvider。
  用**晚绑定注入**而非让 toolImpl 依赖 core,理由:ToolAPI 是**全局单例**
  却需要 per-agent 数据(驻留子是轻量内核,memory 为 nil;内置工具可见性
  由 `if a.memory != nil` 等门控)。sdk 不能依赖 core(方向反了)。
· internal/sdk/tool_impl.go: ToolDefByName / ExecuteTool 补查内置工具。
  ⚠️ ExecuteTool 只在「io 确实没有该工具」时才转内置;io 的**执行失败**
  必须如实上抛 —— 否则会把「设备离线」误报成「工具不存在」,让调用方
  按 missing 策略跳过(与 P3 修过的父 io 吞错误同一族陷阱)。
  内置工具**默认不声明 ParallelSafe**(含 SQLite 写与召回)。
· internal/agent/core/builtin_toolapi.go: Agent 侧 provider。
  ★ Defs **复用 buildToolDefs 的同一批生成逻辑**(筛出不在
  StageHost/IOManager 中的那些),保证"模型看得到什么"与"插件看得到什么"
  门控完全一致 —— 避免两套语义。
  Exec 复用 executeToolCall 完整路径(授权闸 + 异常处理)。
· cmd/homed/bootstrap.go: agent 构造后注入。

★ 不会让模型看到重复工具(已核实):模型侧走 buildToolDefs
(a.io / a.stageHost **直调**),ToolAPI 只经 PluginSDK.Tool() 暴露给插件
—— 两条不重叠的路径。

判据(builtin_toolapi_test.go,6 条):
· 内置工具能从 ToolAPI 查到
· ★ 查到 ≠ 调得通:必须真的能执行
· 门控语义保持:未接 memory/knowledge 时不得声称有那些工具
· ★ 接了 knowledge 时必须可见(这正是要补的缺口)
· ToolAPI 上"不存在"必须是类型化 not-found(供 seq 的 missing 策略用)
· 内置工具默认不声明并发安全

真机复验(同一隔离实例,新二进制):
  序列 "smoke2" 执行完毕(1/1 组)— 工具 1 个
  变量槽: summary = cangjie/central-repo/agreement/...
⇒ knowledge_list 成功执行并回填具名槽。上一次的「不存在或未注册」已消除。

已知局限(记入待定):ToolAPI 单例而内置工具面是 per-agent,
多 agent 下看到的是"最近一个注入者"的面。本次不解决。
2026-09-27 13:40:22 +08:00
4fd18a2e83 docs(plan): 遗留项收敛——D4 与端到端已完成,提权无需决策 2026-09-27 13:18:28 +08:00
3d31037f63 test(seq): 端到端接线判据,抓出「传参方式完全不可用」的真 bug
P1–P4 的判据都在**包内**(假 runner / 直接调函数),覆盖的是**语义**;
本轮补的是**接线**层——参数名对不对、返回值模型读不读得懂、跨层调用断不断。
接线层的 bug 语义判据抓不到:例如工具注册了但参数名拼错,单元判据全绿
而模型永远传不进来。

★ 抓到一个真 bug:**seq_create 走 groups 传参时完全不可用**。
根因:marshalGroups 只把 groups 包进 JSON 文档、不带 name,而 Parse 要求
name 非空 ⇒ 报「序列缺少 name」。而 seqCreate 里那句
`if seq.Name == "" { seq.Name = name }` 回落分支是**死代码**(Parse 早就失败了)。
后果:**只有 file 方式能用,传参方式一律失败**。
已修(name 一并包装)。包内判据抓不到这个——它们直接构造 *Sequence,
不经过这条路径;只有真正 dispatch 一遍才暴露。

判据(e2e_test.go,7 条):真实 dispatch 串通
seq_create → seq_list(须展示签名,模型据此按名调用)→ seq_run
(执行序按 tools 声明序、槽回填、结果里**不得**出现 Go 的 `map[` 语法)
· seq_call 按名调用 group 并返回其出参
· seq_when_call 条件为假 ⇒ 跳过且**零工具被执行**
· seq_when_call 条件畸形 ⇒ **报错**且零执行(不得静默跳过)
· seq_create 走**文件**(长序列的主力用法)
· groups 与 file 同时传 ⇒ 报错「二选一」
· seq_delete 不存在 ⇒ 报错(模型会以为删掉了)

过程中又一次臆造 helper(`writeFile`),改用 os.WriteFile;
并把三处 `_, _ = p.dispatch(...)` 补上 err 检查(正是
go-ignored-call-result 报的那类)。

回归:seq -race 全绿;go build ./... 通过;go test ./internal/... 全绿。
2026-09-27 13:18:19 +08:00
994f198bc5 fix(security): 设备授权闸下沉到 ToolAPI 路径(D4,堵住绕过)
问题:设备类工具的授权闸只存在于 core.executeToolCallInner
(toolcall.go:151-152),即**「agent 收到模型 tool_call」那条路径**。
而 ToolAPI.ExecuteTool 是**另一条**独立执行入口,不经那道闸
⇒ 凡是走 ToolAPI 的调用都能绕过 AllowedOutputs。

实测范围**不止序列**:cli 插件的 /terminal 直接经 ToolAPI 调 agentcli 的
终端工具(cli/plugin.go:1038 的注释自陈"SDK 的 ToolAPI 已允许跨插件调用
工具")。任何插件拿 ToolAPI 都能指挥未授权的设备。

改动:
· internal/sdk/tool.go: ToolAPI 新增 CanUse(toolName, args) bool。
  **纯新增方法**,零值实现返回 true ⇒ 未实现者(存量插件、测试替身)
  行为不变。
· internal/sdk/tool_impl.go: 实现 CanUse。判据只有一条——设备类工具按
  `device/<id>` 查授权;非设备工具不受影响(闸的作用域必须窄,否则会把
  所有工具锁死)。
  授权查询走**可注入**的晚绑定闭包:toolImpl 在 internal/sdk,而
  IsOutputAllowed 是 core.*Agent 的方法,sdk 不能依赖 core。
· internal/plugin/registry.go: 新增 SetDeviceAuthQuery。
· cmd/homed/bootstrap.go: 在 newMainAgent 末尾注入。⚠️ 必须在 agent
  构造**之后**——判据要用 agent 自己的 allowedOutputs,而 registry 早于
  agent 构造,故 registry 存的是晚绑定闭包。

判据(toolapi_auth_test.go,7 条),核心是**两条路径必须一致**:
· 收窄授权时 ToolAPI 路径同样被拦
· 已授权设备放行(防闸过严杀掉正常能力)
· 非设备工具不受影响
· 枚举类工具不受影响(与内核 TestDeviceToolAuth_EnumerationNotGated 同语义)
· 未配置白名单 = 完整授权
· ★ TestCanUseAgreesWithInnerPath:4 组用例逐例比对内核路径与 ToolAPI
  路径的结论 —— 判定不同本身就是漏洞
· ★ TestCanUseMatchesInnerFailOpenOnMissingDeviceID:把现状
  (缺 device_id 时**放行**)钉住。⚠️ 这是 fail-open,是既有的可疑设计
  (core 的 TestDeviceToolAuth_* 依赖它),本次不擅自改语义;判据写明
  "若要改成 fail-closed,必须两处同时改"。

过程中三次自伤:
1. 一度在 core 写了个 toolAPIRef —— **只实现部分方法的替身**是过度设计,
   且两份实现必然漂移。改为判据直接用 sdk.NewTool(stageHost, iom),
   与插件侧走**同一个**实现。
2. 判据里又写了 `var _ = agentIO.DeviceOutput` 这种压 unused import 的
   占位 hack(第二次犯这个),并重造了 strings.Contains。都已去掉。
3. 注入点一开始找错了位置(以为 newStageAndRegistry 能拿到 agent,
   实际 pluginReg 是 main() 的局部变量)。核实 newMainAgent 的签名后
   确认它同时持有 agent 与 pluginReg,注入点落在那里。

变异验证:让 CanUse 恒返回 true(还原成原缺口)⇒ 两条判据 FAIL,
其中一条直指「内核路径=false 而 ToolAPI 路径=true —— 两条路径判定不一致」。

回归:go build ./... 通过;go test ./internal/... 全绿。
2026-09-27 13:15:22 +08:00
532500e3c9 docs(plan): 内核主线与插件线全部完成,记录两个设计决策与三处遗留 2026-09-27 13:06:10 +08:00
71c894c182 feat(seq): 六个 seq_* 工具、插件装配,并补内核两处缺口(插件线 P4)
内核缺口(都是 P3 落地时暴露的真实缺陷):
· **GetAllTools 丢 ParallelSafe**:它只带出 Name/Description/Parameters,
  插件看到的设备工具一律"不可并发" ⇒ 设备工具的并发声明**对插件不可见**。
· **ToolAPI 缺按名查**:新增 ToolDefByName。插件需要在**运行前**判断目标
  是否存在/是否并发安全(工具动态注册,"不存在"是常态),
  而 GetAllTools 只能拿到全量列表。查不到返回 nil,不 panic。

seq 插件:
· plugin.go:插件骨架 + kernelRunner(把 sdk.ToolAPI 收窄成三个方法,
  判据因此能用假实现驱动,不必构造整个内核)
· tools.go:六个工具定义(独立真相源,注册/判据/文档都从它取)
· handlers.go:seq_create/list/delete/run/call/when_call 的实现
· register.go + all.go:按 skillmgr 同一范式 init 注册

★ 过程中解决一个**我自己的设计矛盾**:
判据原先要求 `seq_call` / `seq_when_call` 进黑名单,但"按名调用
group/序列"恰恰是本包的核心能力——禁掉它,序列就退化成单层脚本。
分层澄清后:黑名单只管**对外发消息 / 起子 agent / 改插件表 / 再跑整条
序列**;seq_call 系列留给序列内部组合,其递归由 maxCallDepth + 环检测
负责(设计文档 §8.3 本来就是这么定的,我把两层混了)。
`seq_run` 留在黑名单:序列内再跑整条序列语义上是递归。

**六个工具一律不声明 ParallelSafe**:seq_run/seq_call 会执行一串工具,
其中可能含写操作;标成并发安全会让内核把两条 seq_run 并发跑,
两个序列的执行顺序交错、变量表互相污染。

安全性:序列名与文件路径都做穿越防护(`..` 段、分隔符、空名)。

过程中四次自伤:
1. 臆造 `jsonMarshalIndent`(不存在)→ 改 encoding/json.MarshalIndent;
   并把 execGroup 的 runner 传错成 p(应 p.runner)。
2. seq 判据里写了 `black(name)`,而 blacklisted 是**谓词**不是函数。
3. 一次 python 替换删漏,把「跨序列目标存在性检查」那段从 CheckNew
   里整段摘掉又贴回原处——靠编译错误发现。
4. ★ 注册失败我写了 panic:内置插件在 main() 装配期加载,panic 会
   **直接拖垮内核启动**,而"某个工具没注册上"只该让该工具不可用。
   已改为 log.Printf + 继续(与 clawhubadapter / mcp 一致)。

变异验证:把 seq_run 移出黑名单 ⇒ 黑名单判据 FAIL。

判据(plugin_test.go,6 条):六个工具全部注册且 description/参数 schema
非空;seq_create 声明 required 并说明 groups/file 二选一;
seq_run 说明"按数组顺序";六个工具均未声明 ParallelSafe;
黑名单含递归风险项且**不误伤** seq_call 与普通工具。

回归:seq -race 全绿;internal/sdk/... internal/plugins/... 12 包全绿。
2026-09-27 13:05:28 +08:00
3d753126a3 feat(seq): 序列存储、跨序列调用图与 missing 策略(插件线 P3)
store.go:
· **存 AST 不存文本**。执行期不重新解析原始文本 ⇒ 一次格式改动不会
  悄悄改变已保存序列的行为。
· 先写 .tmp 再 rename,避免写一半被读。
· **路径穿越防护**:序列名来自模型且被直接拼进文件路径,不校验的话
  `seq_load("../secret")` 能读任意文件、`seq_delete` 能删任意文件。
· CheckGraph:跨序列调用的**目标存在性** + **环检测**(三色 DFS),
  报错时给出**环路径**(#A → #B → #A),便于定位。
· maxCallDepth = 4 是**结构常量**不是配置项 —— 沿用内核
  MaxInterruptFrames 的做法(core/scheduler.go:271「结构上界,不是配置项」):
  上界一旦可配,总有人会把它调到栈溢出。

exec.go 补 missing 策略(动态注册下「工具不存在」是**常态**):
· fail(默认)/ skip / degrade,与「执行失败」严格分开
· ⚠️ missing 分支**必须先于**通用 on_error 检查:否则「插件挂了」会被
  on_error=abort 连坐整组中断,skip/degrade 形同虚设
· skip 时**不赋值槽**(与「条件为假」同一情形,下游要能应对槽缺失)
· 本包自带 errToolNotFound 哨兵而**不复用** io 包的同名错误:seq 是插件,
  拿得到 sdk.ToolAPI,拿不到 io 包类型(见设计文档 §7 边界声明)

★ 过程中解决一个**设计死锁**(值得单列):
我最初让 Save 校验「跨序列目标必须已存在」。但互调的两条序列
谁也存不下来——A 要 B 先在、B 要 A 先在,**依赖在设计上无解**。
⇒ Save 只校验**同序列内**的 group 引用(那部分信息自足);
  跨序列目标的存在性与环由 CheckGraph 在保存后统一兜底。
  判据与实现都写明了这个分工的理由。

判据(store_test.go,7 条):
· 存取往返保住 AST(含 out 声明——它是签名的一部分)
· 列表 / 删除;删不存在的**报错**(不静默成功,模型会以为删掉了)
· ★ 跨序列成环被拒且错误含环路径;无环通过
· maxCallDepth 是正的结构常量
· ★ missing 三种取值各有明确行为
· ★ 路径穿越:7 种恶意名既读不到也删不掉,且**在 store 目录外**放真实
  文件断言它仍在(不是"读代码看着对",是跑出来的)

过程中三次自伤:
1. 序列名我写成 "#A"/"#B"——`#` 只是 target 里的前缀标记,
   落盘名不带它,于是 CheckGraph 找不到、误报「不存在」。
2. missing 策略与 on_error 检查的**顺序**反了,导致 skip/degrade 被
   abort 连坐(判据直接暴露)。
3. 为压掉 unused import 写了 `var _ = os.Remove` 这种占位 hack ——
   正是检查项 go-ignored-call-result 指出的那类东西,已删;
   另把 rename 失败分支的 `os.Remove(tmp)` 加上注释说明
   「清理失败有意忽略,否则会盖掉真正的失败原因」。

变异验证:去掉环检测(三色 DFS 全放行)⇒ 成环判据 FAIL
("A→B→A 成环却通过检查")。

回归:-race 下 seq 全绿;internal/plugins/... 全绿。
core 包偶发 TestResidualKeep 失败是**已记录的既有竞态**
(offload_test.go 的 SpawnResident 起了子调度器而测试无同步就读队列),
与本阶段无关,已在执行计划中记为待修。
2026-09-27 12:47:18 +08:00
7532af7e9b feat(seq): 执行引擎 —— 组内并行 + 具名槽 + 条件求值(插件线 P2)
三个不变量(各有判据钉住):

1. **组内并行、组间串行**。parallel=true 时各工具并发执行。

2. ★ **合并按声明顺序**,不按完成顺序。
   并行下完成顺序不确定;若按完成顺序合并,同样的输入产出不同的结果,
   整条序列**不可复现**。做法:各工具把结果写进 `results[i]`(按索引),
   组屏障处按 tools 数组顺序一次性合并。
   顺序合并顺带解决了并发写 map —— **执行期完全不写共享 map**。

3. ★ **条件求值失败必须报错**,不得降级成"条件为假"。
   把求值失败当作跳过 = 序列安静地少做一步,而模型以为跑完了
   —— 与「静默吞工具」同族(那正是 P1 判据里刚堵上的同类问题)。

条件求值(设计文档 §5 的 L1+L2,不引表达式引擎):
· true/false、$args.key 裸引用(真值)
· == / != / > / < / >= / <= 、contains
· 字面量支持 "str" / 'str' / true / false / 数字 / 裸文本
· 布尔与字符串宽松比较(true == "true"),对齐 utils.getBool 的既有约定

变量插值两种形态(缺一不可):
· **整值引用** "$args.count" ⇒ 替换为**原始值并保留类型**
  (数字仍是数字;否则模型收到字符串 "3")
· **文本内插值** "ssh $args.host" ⇒ 在字符串内替换
· 标量渲染:对象/数组用**紧凑 JSON**,绝不用 fmt.Sprintf("%v")
  (那会产出 `map[k:v]` 这种模型读不懂的 Go 语法)

on_error:abort(默认)/ continue。失败时也留槽(记错误文本)——
否则后续组读到的是"缺失",而"缺失"与"值为空"在下游难以区分。

判据(exec_test.go,8 条):
· 具名槽写入正确
· ★ 结果按声明顺序合并(用 delay 让完成顺序**确实**打乱)
· array 槽同名 as 按声明顺序确定性追加
· 条件为假 ⇒ 整组跳过、槽**不赋值**、零工具被执行
· ★ 条件畸形(空键 / 引用未声明入参 / 语法不完整)⇒ 报错且**不执行任何工具**
· 条件为真 ⇒ 正常执行
· on_error 的 abort / continue 两种语义
· 插值:文本内替换 + 整值引用保留类型

过程中三次自伤:
1. ★ **toolRunner 接口第一版写成 call(name)**,不收 args ⇒ 插值判据成了
   摆设(永远"通过")。改为 call(name, args) 后插值才真正可观察。
2. toolRunner / compactJSON 定义在了 _test.go 里,exec.go 引用不到 ⇒
   build 失败。toolRunner 是**引擎的依赖契约**,必须在非测试文件。
3. fixture 里给 "slow" 配了不存在的返回值,误以为它该返回 "B" ——
   是我没配就断言,不是实现错。

变异验证:把合并改为"按完成顺序 append"⇒ array 槽顺序判据 FAIL,
报错直指 `[C A ran:slow]` vs 期望 `[A ran:slow C]`。
(第一版变异用了一个 no-op 的 sort.SliceStable,等于什么都没测,
 已改成真正模拟完成序的实现。)
`-race` 全绿;回归 internal/agent/... internal/plugins/... 全绿。

顺带修正设计文档:两处 tools 示例原写成 `{tool:cmd_run,...}`,
**不是合法 JSON**(P1 判据实测会解析失败)。已改为合法 JSON 并加注
「键要带引号,这是实现时判据跑出来的真实缺陷,不是假想」。
2026-09-27 12:29:56 +08:00
76030ae30e feat(seq): 序列文本 → AST 解析与静态校验(插件线 P1)
插件,不是内核:并行执行是内核提供的**唯一**基础设施(core 的
batchRunnable);分组 / 具名槽 / 条件 / 调用图全部在本包内自建,
**不要求内核开任何新接口**。

实现(parse.go):
· Sequence / Group / ToolCall 三个 AST 类型
· Parse:JSON → AST + **全部**静态校验一次做完
  (而非留到执行期——group 有独立签名,具名槽的价值就在于构建期就能
  查出错写的槽)
· splitToolList:`;` 仅在 brace 深度 0 且**不在字符串内**时才是分隔符
· 枚举/未知字段一律硬报错:DisallowUnknownFields + 显式校验
  (missing / on_error 报错时列出合法取值,不当默认值蒙过去)

静态校验规则:
· `as:X` 未在 out 声明 ⇒ 报错(具名槽的核心价值)
· `$args.X` 未在 in 声明 ⇒ 报错
· group 名重复 ⇒ 报错(签名名必须唯一才能按名调用)
· 非 array 槽被同名 as 写多次 ⇒ 报错(组内并行下同名写入是数据竞争);
  array 槽则允许(组屏障按序追加)
· tools 分隔符畸形(漏中间 / 漏末尾 / 连续 / 未闭合)⇒ **硬报错**,
  绝不静默吞掉一个工具

判据(parse_test.go,9 条),★ 两条最关键:
· 含分号的真实 command(取自 core 里那份线上日志 fixture)保持为 1 个工具
· ★ TestBracesInsideStringDoNotAffectDepth:字符串里的**不成对**花括号
  不得影响 depth

★ 本阶段的三次自伤(都靠变异测试暴露,不是靠判据变红):
1. **格式本身是错的**:我在设计文档里写的 `{tool:cmd_run,...}` 根本不是
   合法 JSON(键没引号),encoding/json 直接解析失败。判据一跑就暴露
   ——"写了格式却从没验证它能解析"。已改为要求合法 JSON(键带引号),
   这也是 DisallowUnknownFields 能生效的前提。
2. **判据验证的不是它声称验证的规则**:原本那条"分号在字符串内"的用例,
   分号其实落在 args 对象的**花括号内部**,depth>0 就足以保护 ⇒ 删掉
   分词器的字符串跟踪后**仍然全绿**。反复两次才找到真正的判别点:
   必须用**不成对**花括号在 depth 恰为 0 处,才只有字符串态能救它。
3. 手写多层转义把引号写成 \",使分词器永远进不了字符串态。改用
   json.Marshal **分层构造** fixture——手写转义没有不出错的机会。

变异验证(两轮,均能检出):
· 删掉"回到顶层必须紧跟 ;"检查 ⇒ 漏中间分隔符用例 FAIL
· 删掉字符串跟踪 ⇒ TestBracesInsideStringDoNotAffectDepth FAIL
  ("结构未闭合(括号深度 1)")

回归:internal/agent/... internal/plugins/... 全绿。
2026-09-27 12:05:27 +08:00
9746538a00 docs(design): 补 0.2 阶段行 2026-09-27 11:56:19 +08:00
ae3cdaa1a0 docs: 同步两份文档的实现进度(内核主线 0~2.5 全部完成) 2026-09-27 11:56:01 +08:00
0327419c88 feat(prompt): 提示词声明「同轮默认并行」及其例外(阶段 2.5)
⚠️ 本阶段有硬性顺序约束:必须在并行执行(阶段 2d)落地**之后**。
反序(先说"并发"、内核仍串行)会让提示词**对模型说谎** —— 模型据
"并发执行"推断安全性,写出真正依赖顺序的调用。宁可晚改,不可错改。

改动(tooldefs.go,buildSystemPrompt):
· 新增【工具执行顺序】段,讲清四件事:
  1. 同一条回复里的多个工具调用**默认并行**(同时跑),不是依次执行
  2. **不要依赖执行顺序** —— 参数依赖前一个结果就分两轮
  3. **例外一:同通道 output_send__ 保序**(用户可见消息顺序敏感)
  4. **例外二:不并发安全的工具整批退回串行**(写类工具 / 未声明者)
· 顺带说明并发安全由**工具自己声明**(ParallelSafe),不由模型判断
· 改掉 spawn_child 的落空表述:原文「应并行 spawn,不要自己串行逐个执行」
  在并行化之前是**落空**的(模型照做,内核仍串行)。改为机制性表述,
  并补一句「一次 spawn 只是启动动作,要拿结果仍需另一次 child_result」。

⚠️ 措辞刻意与 batchRunnable 的**真实**判据一致(全批 ParallelSafe 才并发
+ 同通道保序),而不是理想化表述 —— 提示词与实现不符,比不说更坏。

判据(prompt_parallel_test.go,5 条):
· 四要点齐全(并行 / 顺序 / 保序 / 并发安全声明)
· ★ 必须同时讲**例外** —— 只讲并行就是"说谎"的那一种
· 同通道保序须显式说明(保序是内核兜底,模型不知情就会浪费它)
· spawn_child 不再含旧的落空措辞
· 回归防护:既有要点(输出规则 / output_list_channels / 工具能力 / 记忆清理)不丢

★ 判据里的一次自伤:先写了 spawnChildDescription(a) 这个**不存在**的
helper("工具名反查描述"),编译失败后改为 toolDefDescription —— 内部
遍历 buildToolDefs 的**真实产物**。判据必须对着代码真实输出,不能另建一套
注册表。

变异验证:把两条例外改写成"以上适用于所有工具"⇒ 3 条判据 FAIL
(缺"保序"、缺"例外"、同通道未说明)。即"提示词说谎"这一失败模式
现已被判据覆盖。

回归:internal/agent/... internal/sdk/... internal/plugins/... 全绿(15 包)。
2026-09-27 11:55:33 +08:00
446645d0a0 docs(plan): 阶段 2 标记完成,记录并发规则与 2c 判据闭合 2026-09-27 11:27:53 +08:00
34c0df2705 feat(toolcall): 批次并发调度与同通道保序(阶段 2d,闭合 2c 判据缺口)
规则(三条全满足才并发):
  1. 批内 >1 个工具
  2. **全部**工具声明 ParallelSafe —— 一个不声明就整批降级,不做部分并发
  3. 不含需保序的同通道输出发送

SDK:
· ToolDef 加 ParallelSafe bool。⚠️ 零值 false 是刻意的:存量插件不改一行
  就得到**保守**行为(整批串行),不会因升级被意外并发。声明它是责任
  而非特权。纯新增字段,无签名变更。
· io.ToolDef 同步加该字段(设备/通道工具走 io 路径,只查 StageHost 会漏)。

core:
· 新增 StepToolBatch —— runTaskSteps 是单线程驱动状态机的,
  「每步一个工具」的游标模型无法表达「一批同时跑」,故需独立 step。
· stepToolBatch:fan-out(每工具一 goroutine,各写自己的 toolCtxs[i])
  → join → **按索引顺序**串行收尾(after_toolcall / 落消息 / 事件)。
  收尾必须串行且按索引:f.Msgs 是共享切片,且按索引落才能让模型读到的
  上下文顺序与它自己发出的顺序一致。
· runOneTool 抽出「before_toolcall + 执行」的单工具逻辑,串行/并发两条路共用。
· toolParallelSafe / batchRunnable 判据函数。

★ 修掉一个我自己引入的竞争:resolveTurnScenes 会把结果记进**共享**的
f.sceneDone / f.turnScene(memorypass.go:289)。最初在每个 goroutine 里
各调一次 —— 既是数据竞争,又会各自触发一次 EnterSceneWithHint,
重复计入场景强度(正是 sceneDone 注释警告过的问题)。改为在 fan-out
**之前**解析一次,goroutine 内只读。

判据(parallelsched_test.go,4 条):
· 全批 ParallelSafe ⇒ 并发峰值 >= 2(用阻塞设备观察真实并发)
· 一个非 ParallelSafe ⇒ 整批串行,但**仍全部执行**
· 同 output_send__<通道> 连发 3 条 ⇒ 严格按声明顺序到达
· ★ 并发下每个工具的 ctx 只带自己的 ToolCalls、after 读到自己结果

★ 并关闭了 2c 的判据缺口:此前两条 2c 判据在**串行**下无法区分
per-tool 与单槽(变体验证后仍全绿)。新增的并发版判据在退回单槽时
触发 **6 处 DATA RACE 报告 + 串味断言失败**(dup:k_a 与 k_a 撞名)。
至此 2c 可记为已验证。

过程中三次自伤:
· resolveTurnScenes 竞争(上述);
· 我的 harness 用 StageHost 注册 handler 遮蔽了设备工具,
  slowDevice 根本没被调用("实际 0")——改为在 io.ToolDef 上声明;
· 批内并发峰值判据最初用 StageHost 声明 ParallelSafe,掩盖了
  「设备工具也需要该字段」这一真实缺口。

回归:internal/agent/... internal/sdk/... internal/plugin/...
      internal/plugins/... 全绿(17 包);core 包 -race 全绿。
2026-09-27 11:27:24 +08:00
3d12e82f65 refactor(toolcall): StageContext 拆 per-tool,为并发执行消除共享槽(阶段 2c)
问题:f.StageCtx 是**单槽**,批内每个工具都覆写它(ToolCalls=[单元素]、
ToolResults 覆写、Results[0] 回读)。串行下看不出问题,但并发下
N 个 goroutine 同写一个 ctx = 数据竞争,且 after_toolcall 插件可能读到
**别的工具**的结果。

改动(task.go):
· TaskFrame 增 toolCtxs []sdk.StageContext(每工具一份)
· buildToolContexts 在 stepLLM 设 PendingTools 时建池;
  Extra **逐份浅拷贝**——共享同一 map 即竞争(stage handler 会写它)
· toolCtxFor(i) 取第 i 份,越界/未建时回落 f.StageCtx(测试替身安全)
· stepToolBegin(before_toolcall + 参数回填)、stepToolExec(写结果)、
  stepToolAfter(读结果)三处全部切到 per-tool ctx

判据(toolbatch_test.go 追加两条):
· 每个工具的 before_toolcall ctx 只带自己的 ToolCalls[0].Name,
  且 Extra[output_channel] 逐份带过去(stage.go:18 依赖它)
· after_toolcall 读到的 Result 必须属于当前工具,不能是批内另一个的

★ 诚实记录:这两条判据在**串行**下**测不出与单槽的差别**——串行时
每工具跑完才进下一个,不存在交错。变体验证(toolCtxFor 退回单槽)后
判据仍全绿。故 2c 记为「实现已就位、判据未闭合」,真正判据必须与 2d
(并发执行)一起写,并以 -race 确认无竞争。已在执行计划中标注。

过程中两次自伤:
· 我的 harness 没设 Extra[output_channel](那是 prepareInputTask 才写的,
  task.go:380),判据一度报「产品缺陷」——核实后是我造的场景,已对齐生产;
· 阶段 1 的 TestStageCtxSuccessIsHonestEndToEnd 读 f.StageCtx.ToolResults,
  拆分后失效——判据跟随新结构改为按批索引取 toolCtxs[i],
  断言的仍是内核产出的 Success 值本身。

顺带记录(非本次引入):TestResidualKeep/Drop 偶发失败,根因是
offload_test.go 的 SpawnResident 起了子调度器 goroutine,而测试
enqueue 后无同步就读同一队列。干净基线 3/3 全绿属运气。已在计划中
记为待修,避免后续误判为并行化引入的回归。
2026-09-27 11:17:06 +08:00
28b42bcf0f refactor(toolcall): 批内消息改为「一个 assistant 带全部 tool_calls」(阶段 2a)
问题:现状每个工具各自 append 一对(assistant[tool_calls=[tc]] + tool),
既不表达「这是一批」,也无法支撑并行:
· 产生 N 条 assistant 消息,同一段 assistant 文本语义上只该出现一次
· 并行下完成顺序不确定,若等结果回来再落消息,assistant 就必须等所有
  结果齐了才能写——而 OpenAI 协议要求 assistant(tool_calls) 在结果**之前**

改动(task.go):
· TaskFrame 增 assistantMsgIdx
· 新增 ensureBatchAssistant:惰性写入,全批只写**一条** assistant,
  携带 f.PendingTools 全部 tool_calls;后续工具只补 tool 消息
· stepToolBegin 的 denied / unhealthy 分支与 stepToolAfter 统一改用它
· stepLLM 设 PendingTools 时清零 assistantMsgIdx
· msgContent 的 ContentOnce 归位移入 ensureBatchAssistant(仍是只挂第一条)

⚠️ 依赖:before_toolcall 阶段**不得**改写工具参数——已核实全仓无此用法
(grep ToolCalls[0].Arguments 赋值无结果)。若将来某插件要改写 args,
需改为「回填后重写该条 assistant」。该前提已写入代码注释。

判据(toolbatch_test.go 追加 TestBatchLayoutSingleAssistantCarriesAllToolCalls):
· 带 tool_calls 的 assistant **恰好一条**且携带 2 个 tool_calls
· 其后紧跟 2 条 tool 消息且按声明顺序(c1、c2)

变异验证:让 ensureBatchAssistant 退化为「每工具一条」⇒ 判据 FAIL
「批内 assistant 应带 2 个 tool_calls,实际 1」。

stage 0.5 补的三条判据(配对完整性 / ContentOnce / denied 后继续)
在本改动后**仍然全绿**——它们正是为这种改动准备的保护网。

回归:internal/agent/... internal/sdk/... internal/plugins/... 全绿(18 包)。
2026-09-27 11:09:02 +08:00
25f5c53086 feat(io): 多模态块改 per-call 归档,为并行执行铺路(阶段 2b)
问题:ConsumeToolBlocks 此前是 **IOManager 级单队列**(取走即清空),
没有 call_id 维度。并行化后同批多个工具各自注入媒体时,后执行的
Consume 会**抢走**前一个的块 ⇒ 媒体挂到错误的 tool 消息上。而
task.go 里「媒体必须走 user message 且紧跟自己的 toolMsg」那条结论
是三轮实测才定下来的,并行会直接破坏它。多模态插件在 3 处调
SetToolBlocks(multimodal/plugin.go:136,246,320),是真实使用面。

改动:
· 字段 toolPendingBlocks: []interface{} → map[string][]interface{}
· 新增 SetToolBlocksFor / ConsumeToolBlocksFor / ClearToolBlocks(按 call_id)
· 保留 SetToolBlocks / ConsumeToolBlocks 作兼容入口(走 callID=""),
  存量调用方与串行单工具场景不受影响;其注释写明并行下该路径不可靠

判据(toolblocks_test.go,4 条):
· 两个 call 各自注入、**交叉顺序**并发取回,各归其主
· 取走即消费(二次取回为空)
· 未知 callID 返回空且**不影响他人**的块
· 32 路并发零串味

变异说明:本阶段是从「单槽」直接改为 per-call,旧实现在这四条判据下
(per-call API 不存在)无法编译通过,等价于判据先失败;per-call 版
再经 `go test -race` 验证无数据竞争。回归:internal/agent/io 全绿。
2026-09-27 11:06:41 +08:00
bce40b5099 feat(toolcall): 按 schema 预校验参数,在分派前拦下(阶段 1c)
问题:`required` 在仓内被声明 69 处,却**无任何消费方**(内核从不读)。
校验散落在每个工具内部手写成中文字符串("path is required"),
要等工具真被调用才暴露——而模型看到这类与真因无关的报错只会原样重试
(实测 cmd_run 失败率 34%~48% 的成因)。

改动:
· core/argvalidate.go: validateToolArgs(纯函数)+ validateArgsAgainstSchema。
  ★ 校验器刻意**宽松**:只拦真正无法解析的形态,对模型实际会写的等价形态
  一律放行。依据是工具内部 getter 的既有约定(utils.go 注释:
  "实际调用里 bool/string/float 三种都出现过";unitNumberRe 修的正是
  `"20s"` 少引号那类)。**校验比工具更严就是在制造新失败**。
  · required 判据是**键存在性** + 非空字符串;显式 null 视为已提供
    (模型可能有意传 null,工具按零值处理,判成缺失即误伤)
  · boolean 全放行(getBool 的 true/"1"/"0"/"yes"/0/1 全都合法)
  · integer 接受 int/float64/"20"/"20s";string 接受含 JSON 的长文本
  · 无 schema / 无 required / 查不到 schema ⇒ 一律放行
· core/toolcall.go: 在 __arg_error 短路**之后**、分派**之前**接入。
· io/channel.go: 新增 IOManager.ToolDefOf——没有它就只校验到插件工具,
  而 cmd_run / files_write 这类**设备/通道工具会完全绕过校验**。

判据(argvalidate_test.go,7 组):
· 缺 required 被拦下并指名字段
· ★ 误伤防线:bool 传 "true"/"0"、integer 传 float64/"20"、
  显式 null、字段顺序不同 —— 全部必须放行
· 类型确实不符报 type 错误
· 无约束场景一律放行(含 args 为 nil + schema 带 required ⇒ 应拦,
  这条我最初**误放进放行组**,写完立刻发现改正)
· 错误文案含字段名/必填/改法(否则模型只会原样重试)
· 端到端:缺参时**设备真的没被调用** + 文案指名字段
· 端到端反向:参数齐备照常执行(校验不得阻塞正常路径)

变异验证(两轮):
· 关闭分派前校验 ⇒ 端到端判据 FAIL「仍进入了工具」
· 把 boolean 校验改严格 ⇒ 宽松防线 FAIL 两个子用例(误伤 "true"/"0")

过程中三次自伤:臆造 sdkToolError 别名;number 分支写了没有绑定的 x(v);
把"显式 null"先当成缺失、过度修正后又漏掉"键不存在"的判定——
最终改为「键存在性 + 非空串」双条件,null 与缺失各归其位。

回归:internal/agent/... internal/sdk/... internal/plugin/...
      internal/plugins/... 全绿(18 包)。
2026-09-27 10:56:02 +08:00
396d13e9af feat(toolcall): 结果契约诚实化 —— Success 不再恒真 + 结构化失败可回填(阶段 1b/1d)
问题(实测,三条互相印证):
· ToolResult.Success 硬编码 true(task.go 唯一赋值点)⇒ 该字段在结构上
  不可能为 false,是**谎报字段**;
· 工具失败以 nil error + 错误**值**返回(files 的 errorResult、
  pluginmgr 的 {"error":…}),上游无从判别;
· stepToolAfter 用 `Result.(string)` 断言,而插件返回的多是 map ⇒
  断言几乎恒失败,after_toolcall 阶段对结构化结果的改写**静默失效**。

改动:
· third_party/homeagent-sdk: 新增 ToolError{Field,Reason,Detail,Hint}
  与 Error()。纯新增、无签名变更,存量插件不必改动(零值语义:
  内核的失败识别同时兼容既有三种约定,新类型是可选项而非迁移要求)。
· internal/sdk: 补 ToolError 别名。
· core/toolerror.go: isToolError / toolErrorText / renderToolResult。
  ⚠️ 判据必须同时兼容仓内**三种**既有失败约定,且**不得**把成功误判:
   ① {"error": msg}  ② {"isError":true,content:…}  ③ *ToolError
  明确不判失败的:exit_code != 0(业务结果,带真实 stdout/stderr)、
  stderr 非空(cmd 成功常带 warn)、字符串/数字/bool/数组/nil
  (自由文本按成功处理:宁可少报失败,也不把正常结果报成失败)。
· core/toolcall.go: executeToolCallOutcome 返回 toolOutcome{Text,Raw},
  **Raw 必须在成功分支也带上**——否则结构化失败在 fmt.Sprintf("%v")
  那一步被抹平,Success 又退回恒真。panic 与 60s 超时统一以 ToolError
  表达(可执行 Hint,避免模型原样重试工具故障)。
· core/task.go: Success=!isToolError(Raw);修恒失败的类型断言;
  TaskFrame 增 CurRaw(未降级的原值)。

判据:
· toolerror_test.go 单元级:三种失败约定识别 / 成功形态不误判 /
  非零退出不算工具失败 / ToolError 识别。
· TestStageCtxSuccessIsHonestEndToEnd 端到端读 f.StageCtx.ToolResults,
  验证**内核产出的值本身**,而非辅助函数。

变异验证(两轮):
· Success 退回硬编码 true ⇒ 端到端判据 3 个子用例 FAIL;
· 把字符串判据改成 strings.Contains(x,"error") ⇒ 「成功文本含 error 字样」
  用例 FAIL。**第二轮暴露了判据缺口**(最初没有该用例),已补。

过程中三次自伤(均由判据/编译暴露):用正则批量包装 return 时把
多行 fmt.Sprintf 截断;包装范围溢出到返回 string 的辅助函数;
测试里重复注册同名工具导致 IOManager 取到错误的 device。

遗留:全量 go test ./internal/... 在本机无法完整跑完——/tmp 是 9.8G
tmpfs 且已 98% 占用,link 阶段报 "no space left on device";
/var/tmp 另有约 29G 陈旧 release worktree。与本次改动无关(未触碰
memory/* 等失败包),已在干净基线(7a566d5)对比确认。
2026-09-27 09:17:16 +08:00
4ba72977d2 test(toolcall): 补批内路径的三条缺失判据(阶段 0.5)
同一批多个 tool_call 的循环(StepToolBegin→Exec→After)此前只被
scheduler_critical_test.go:125 一条用例覆盖「按序执行」,缺的三条正是
阶段 2(并行执行层)要改的地方:

· tool_call_id 配对完整性 —— 阶段 2 改消息落法(一个 assistant 带全部
  tool_calls + N 条 tool)时,配对断裂上游会直接报错
· ContentOnce 批内语义 —— 同一段 assistant 文本在批内重复 N 次,撑爆上下文
· denied 后继续批内 —— 改成 abort 会丢掉本可执行的后续调用

判据 toolbatch_test.go(4 条),全部确定性断言:阶段 0 已消除 map
迭代随机性,同批工具的落序与配对可稳定断言。

变异验证:令 stepToolBegin 跳过批内最后一个工具后,4 条判据同时 FAIL
(既有那条也 FAIL),报错直指 ToolsUsed=[tool_alpha]、
tool_call_id "c2" 被声明 0 次。

更正一处此前的不准确表述:我曾说「无任何测试直接驱动批内路径」——
不准确。scheduler_critical_test.go:125 已驱动「同批两工具按序执行」;
漏查是因为只 grep 了 PendingTools/ToolIdx 字段名,没查断言内容。
真正缺的是上表三条。

过程中三次自伤(均由「判据先写」暴露):臆造不存在的 helper;
stageHost 置 nil 后又使用;给 newTaskFrame 传 nil 导致 stepPrepare 于
task.go:519 nil 解引用 panic(改用仓内既有 a.stageCtxFromInput)。
顺带记录:生产两处 newTaskFrame 调用都传真实 ctx,但 stepPrepare 对
f.StageCtx 无 nil 兜底——本次不修(无生产触发路径),记为潜在缺口。

回归:internal/agent/... 与 internal/plugins/... 全绿。
2026-09-27 08:59:30 +08:00
7a566d50b7 fix(toolcall): 工具「不存在」类型化 + 修父 io 兜底吞错误 + 修并行 tool_call 落序随机
主线:工具调用并行化改造(阶段 0 与 0.2)。

① flush 顺序随机(process.go)
   flushToolCall 由 `for idx := range accs` 驱动,Go map 迭代顺序随机化
   ⇒ 同一批并行 tool_call 进入 resp.ToolCalls 的顺序每次运行都可能不同。
   对 output_send__ 这类用户可见通道,分段消息到达顺序不可复现。
   改为收集 index 后 sort.Ints 再 flush(两个调用点统一走 flushAll)。
   判据 stream_flush_order_test.go(8 工具 × 200 轮),已变异验证可检测。

② 工具「不存在」类型化(io/channel.go、core/stages.go、core/toolcall.go)
   工具是动态注册的,「不存在」是运行期常态而非异常。原先内核用
   strings.Contains(err, "not found in any plugin") 判别——约定而非契约,
   插件文案含该子串即被误判。改用哨兵 ErrToolNotFound + errors.Is
   (沿用仓内 ErrInputChannelUnknown 的先例)。

   ⚠️ 顺带修一个静默 bug:IOManager 向父兜底时吞掉父的执行失败,
   误报为「工具不存在」。后果是设备离线这类本该 retry 的失败被判为
   「工具没了」⇒ 整组被跳过,与「插件真没加载」无法区分。改为只传递
   「确实不存在」,其余如实上抛。

   「不存在」的文案改为可执行指引(get_plugin_tools / output_list_channels),
   而非含糊的「执行失败」——后者会让模型反复重试同一个不存在的名字。

判据:toolcall_error_test.go(类型化 vs 诱饵子串、%w 穿透、执行期文案)、
channel_error_test.go(父失败不吞、真的不存在仍可判别)。
两者均经变异验证。回归:internal/agent/... 与 internal/plugins/... 全绿(14 包)。

设计文档:docs/zh/toolcall-contract-and-sequence-design.md
执行计划:docs/zh/toolcall-parallel-execution-plan.md
2026-09-27 08:55:25 +08:00
85e3d66e92 Merge branch 'feature/scene-writeback' — 场景式记忆修复 + WebUI 性能与星图改进
## 记忆:场景式记忆的 5 处根因(生产实测驱动)

现网 65 个场景里有 6 组是同一场面的双胞胎键,最严重的
auto:chan:qq+part:morning 累积到 strength=271 / 6 features / 0 refs,
日志里被「命中」179 次;孪生的 auto:chan:qq_part:morning 持有 210 refs
却有 0 features(聚类只读 scene_features,所以它永不被看见)。两套特征
体系各活各的,谁也发现不了谁。

- 1fa9ef6 键归一化 + 排除最弱维度:建键路径(createSceneLocked)漏过
  NormalizeSceneKey,而 EnsureScene / effectiveScenes / RecallByScene
  三处都过了 ⇒ '+' 与 '_' 成为两个合法主键,key UNIQUE 拦不住。
  同时把权重仅 0.2 的 part(时段)排除出场景身份 —— 实测「morning 场景
  吞掉 evening 指纹」(共享 chan:qq,相似度 1.0/1.4=0.714 > 阈值 0.5)。
  冲突后缀 '#N' 改 '.N'('#' 也会被归一化,是第四处双胞胎来源)。
- 758ec11 图整备覆盖 scenes:新增 DedupeScenes 并接入 mergeLoop。
  原先 detectEntityMerge 的遍历入口 Recall(nil,nil,1,"") 只查
  entities/relations,scenes 完全没有整备路径 —— 这是「双胞胎从 9-15 起
  无人发现」的原因。生产库副本实测:65 → 57,合并 8 组,refs/rel/ent
  一条没丢。
- 758ec11 证据桶按桶清:createSceneLocked 原先是
  DELETE FROM situation_evidence(全表清)。多通道共用计数表,qq 的场景
  一长出来就把 mc/webui 尚未攒够 minSceneEvidence=2 的证据抹掉 ⇒ 判据
  实测「6 个通道各来 3 次只长出 2 个场景」。
- 2567a22 场景键两路合并去重:现网日志实测 scenes=[chan:qq chan:qq]。
  声明路与通道派生路之间缺共同的 seen。

## SDK:补 ScenePolicy 声明项(经用户授权的公开接口扩展)

ChannelDef 已有 NoMemory/ContextPolicy/RecallPolicy 三件套,唯独没有
「这条输入算不算一场戏的一部分」,现状是无条件参与 ⇒ chan:system /
chan:kernel / chan:timer 这类纯内部信噪通道也在撑场面。

新增 ScenePolicyAuto/None + ValidScenePolicy,形状与既有两项完全一致;
ChannelDef.ScenePolicy 与 InjectOptions.ScenePolicy 均带 omitempty,
零值行为逐字节不变。默认取 auto(参与)而非 none:场景只附加检索路、
不改记忆本体,默认关会让存量通道突然失去召回。**现网不标任何一个通道**
(用户裁定「多写无影响、少写会缺场景」;实测 0-refs 通道召回返回空,
且 declared 场景不进相似度空间)。

⚠️ 本次合并会使 git_release_check 的「公开 SDK 接口冻结」项报 FAIL,
   属预期:有意的新增接口,非破坏性变更。

## WebUI

- ae87f4b 服务端 gzip(首屏 wire 字节 -70%):状态机写成单一枚举而非
  多个 bool;SSE 不压、必须透传 http.Flusher、Content-Length 需防陈旧值。
- d3315c6 前端按页签懒加载:空闲请求 37 → 17(-54%);顺带治掉三个
  轮询器,并把 loadChatStarmapData 的空图分支硬取
  getElementById("sm-container-chat") 改为可移植(该 bug 曾导致首页
  首帧必抛、永不重试、星图永远空白)。
- 9346fed 星图跟随 agent 活动 + 搬到主页 + 修分类配色从未生效
  (服务端发 "Concept"、JS 键是 "concept" ⇒ 永不匹配 ⇒ 1150 节点
  全回退兜底灰)。
- 9c93f23 配色改中性灰蓝:上一提交修好后,1148/1149 个 Concept 节点
  第一次真拿到亮青绿 ⇒ 整张图变绿。绿色不是渲染 bug,是「配色终于生效」
  后暴露出的真实数据形状;之前的灰恰好是「全都没匹配上」的症状。
- 4a231a8 两处表达式合并为单行(纯格式化)。

## 文档

- f441574/6e94209/13a070f 场景记忆修复 plan(5 根因 → 7 步骤)
- bf5d891 介绍站补「场面涌现」板块
- SDK 站新增 docs/guide/scene-memory.md(概念 + 声明项用法)

## 验证

记忆 8 包 + agent/core 全绿;全仓 59 包 0 FAIL。生产部署后置清单全绿
(版本自报、插件子进程 25、Fatal 0、端到端)。场景清理后复验:涌现出的
新键不含 +/#、有 features 且有 refs。
2026-09-27 08:25:30 +08:00
9c93f232e3 fix(webui): 星图配色改中性灰蓝 + 图例按实际类型动态生成
### 为什么会出现「一片绿」

上一提交修好了「分类配色从未生效」那个 bug(服务端发 "Concept"、JS 键是
"concept" ⇒ 永不匹配 ⇒ 1150 个节点全回退兜底灰 0xcccccc)。修好之后
颜色值**一个字没改**(concept 键仍是 0x44ff88),于是 1148 个 Concept
节点第一次真的拿到了那个亮青绿 —— 1149 个节点里 1148 个是 Concept,
所以整张图变成绿的。

⇒ 结论:绿色不是渲染 bug,是「配色终于生效」后暴露出的真实数据形状。
   之前的灰色恰好是「全都没匹配上」的症状。

### 换中性色(用户裁定)
默认色改为 SM_COLOR_DIM = 0x7d8a9e(中性灰蓝)。亮青绿配 1149 个
自发光球确实扎眼。

### 顺带把「图例说谎」也修了
原图例写死「人物/概念/对象/地点/来源」五项,而实测图谱里只有
Concept(1148)与 Source(1)—— 列出四个永不出现的类型,等于告诉
用户存在实际不存在的分类。

现在:
- 图例按**实际出现**的类型动态生成,标注占比
- 占比 <1% 的不单列(实测 1/1149 = 0.087%,单列会显示成「来源 0%」,
  既难看又误导读者以为图里没有来源节点),归入「其他 N 个」
- 只有**一种有存在感**的类型时,附一句实话说明「节点同色不是分类图」

### 颜色规则也跟图例对齐
smColorFor:只有存在 >=1% 的第二类型时才按类型上色,否则全图中性色。
理由:99.9% 概念 + 0.1% 其他时按类型上色,得到的仍是一整片同色,
而那一两个异色点在视觉上就是噪点(实测 colors 只剩 ["7d8a9e"])。

不动服务端类型识别(用户裁定):nlp/extractor.go 至今不判类型、
graph.go:451 写死 Concept,根治要改记忆链路,本轮不碰。

### 途中修掉一个自己引入的 bug
图例空。首屏星图在**总览页**初始化,那时 #sm-legend 还不存在
(骨架由 renderStarmapTab 建),smLegend 内部 getElementById 返回 null
直接返回;而 renderStarmapTab 建完骨架后只调了 smUpdateStat()。
⇒ 浏览器实测图例 html 长度 0。在 renderStarmapTab 里补一次 smLegend()。

### 验证(真实 1149 节点数据集 + WebGL)
- 颜色:["7d8a9e"](单一中性色)—— 改前 ["44ff88"] 一片绿
- 图例文本:「概念 100%  其他 1 个(图谱实体几乎都是同一类型,节点同色;
  出现新类型后会自动分类)」
- 统计:1149 节点 / 865 关系;控制台零异常
- go vet 干净;全量测试通过

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-09-27 07:14:34 +08:00
4a231a8d4c style(webui): dashboard.js 两处表达式合并为单行
纯格式化,无语义变化:
- state.startedAt 的三元表达式(563 行附近)
- renderAll 里 Promise.all 的实参(624 行附近)

两处的表达式与参数列表逐字符相同,只是原先的换行被收拢。
已随二进制部署并验证上线:现网 `/` 返回的 HTML 里单行写法命中 1 处、
旧多行写法 0 残留。
2026-09-27 06:44:49 +08:00
d3315c68ca perf(webui): 前端按页签懒加载 —— 首屏不再拉隐藏页签的数据,空闲请求砍到 1/3
生产实测的问题:renderAll 无论当前在哪个页签,都无条件拉 9 个接口并
渲染全部 7 个页签。首屏 792,933 B 里**约 230KB 花在用户看不见的隐藏
DOM 上** —— /api/v1/kernel(152KB,只有内核页要)与 /api/v1/settings
(72KB,只有设置页要),而 renderKernel() / renderOneSettings() 是在
**隐藏的 tab 容器**里构建 DOM 的。更糟的是每 15s 重来一遍。

### 依赖关系是实测出来的,不是猜的
逐个 render 函数 grep 它读的 state.*:
  renderOverview     → 无(只读 status/runtime/dom)★ 总览最便宜
  renderKernel       → state.kernel
  renderOneSettings  → state.settings / state.meta
  renderPlugins      → state.kernel / installedPlugins / disabledPlugins
  renderAdapters     → 无(自拉 /api/v1/adapters)
  renderChat         → 自建布局;星图/终端/命令是其子面板
于是「切到哪页才拉哪页的数据」写成一张 TABS 表(唯一真相表),
正确性由结构保证,而不是靠一串 if 串联。

### 顺带治掉三个轮询器(浏览器 40s 空载实测)
改前停在总览页 40s 内 37 个请求:
  /runtime 17 次、/terminals 8 次、/cmd/history 8 次、/status 3 次

1. **terminals/cmd/history 的 5s 轮询是无条件的** —— 但这两个面板只
   存在于**聊天页**(buildChatLayout 里的 chat-panel-terminal/-cmd),
   在总览/设置/内核页渲染它们既没人看也只改看不见的 DOM。
   改为「仅聊天页可见时才轮询」。
2. **/runtime 有两个消费者各拉一遍**:startRuntimeTicker(3s)与
   starmapPullActivity(3s)。星图现在只读 state.runtime,不再自己发请求。
3. 轮询改走共享数据块 starmapFetchBlock(带 3s 节流 + 单一数据源)。

改后 40s 内 17 个请求(-54%),且不再有任何接口用于渲染不可见的面板。

### 首屏
overview 首屏只拉 status/runtime/chat/history/persona/memory-graph,
**不再拉 kernel 与 settings**。

### 刷新语义
区分「活数据」与「近乎不变的数据」:status/runtime 每 3s 允许重拉;
kernel/settings/plugins 首次拉过后**不再每 15s 重拉**(这正是 53MB/h
的主因)。切回页签也不重拉(数据没理由变)。四个变更操作
(源/MCP 的增删)改调 renderAll(true) 强制刷新;启停插件/保存设置那几处
本来就自己 refetch 再局部重渲染,不依赖 renderAll。

### ★ 途中修掉一个被上一提交引入的真 bug
loadChatStarmapData 的空图分支硬写 getElementById("sm-container-chat")。
星图搬到总览后,总览页与独立页签都没有这个 id ⇒ 首页首帧必抛
「Cannot set properties of null」,被 catch 吞掉但 starmapInit 没置上,
于是**永不重试、星图永远空白**。改为取 starmapActiveContainer() 并加
空值保护。浏览器实测:修前 ERRORS 非空,修后 STARTUP + 7 个页签全 clean。
(教训:把 UI 元素挪到新位置后,必须把所有按 id 直取该元素的地方找全 ——
grep 该 id 一次。)

同时删掉被 starmapActiveContainer 取代的死函数 starmapContainer()。

### 验证(浏览器实测,非估算)
- go vet 干净;全量测试通过
- 首屏(overview):只拉 status/runtime/chat-history/persona/memory-graph,
  kernel 与 settings 确认**未出现**
- 逐页切换记录请求:每页只拉自己那几项
- 空载 40s:37 → 17 个请求
- 运行态面板仍正常渲染(rt-panel 存在、rt-sec-pipe / rt-sec-topo 均在)
- 启动 + 7 个页签全部无控制台异常

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-09-27 00:23:04 +08:00
ae87f4b8b2 perf(webui): 服务端 gzip —— 首屏 wire 字节 -70%
生产实测:首屏 API 合计 792,933 B,而服务端此前**完全没有** Content-Encoding
(直连 127.0.0.1:8080 与经 nginx 的公网入口两条路径都验过:响应头里没有
该字段,wire 尺寸 == 原始尺寸)。同一份数据 gzip 后:

  /api/v1/kernel     152,667 →  37,697  (-75%)
  /api/v1/chat/history?limit=40   554,764 → 174,594 (-69%)

这些是高度重复的 JSON(同批 key 名反复出现、中文实体名、时间戳),
压缩比自然地高。真实实例上实测首屏 wire 字节 77,943 → 23,339(-70%)。

位置:链改为 proxyDispatch → gzip → logged → mux。夹在 proxyDispatch
与 logged 之间,是因为 proxyDispatch 命中时直接 return、响应来自上游
(其 Content-Encoding 由 httputil 处理),我们不插手;门户自身的全部
响应(requireAPI 的 401/503、requireWeb 的 302、HTML/CSS/JS、全部
JSON API)都压。

### 三个必须显式处理的坑

1. **SSE 不能压。** text/event-stream 进 gzip 缓冲后 flush 语义就废了
   (前端收不到流式,要等缓冲攒够)。对 SSE 请求直接透传。
2. **必须透传 http.Flusher。** handleChatEvents / streamOpenAI 里是
   `w.(http.Flusher)` 类型断言;包装 ResponseWriter 会让断言失败 ⇒
   flusher 为 nil ⇒ 走降级分支 ⇒ SSE **静默**坏掉(不报错,只是收不到
   流式)。这不是「顺手加一下」能过的改动,有专门的判据守着。
3. **204/304/HEAD 没有 body**,压它们只浪费 CPU 并加坏头。
   另外 webp/png/zip/gzip 等已压缩类型也跳过(mascot.webp 133KB 就在内)。

### 小于 1KB 的响应不压
gzip 头 23 字节,几百字节的 JSON 压完反而更大。与 nginx 的
gzip_min_length 1000 对齐。实测 /api/v1/status(197B)不带
Content-Encoding。

### 状态机写成枚举而非多个 bool
第一版用 passthrough/decided/buffering/allowBuf 四个 bool 交叉表示,
结果出两个 bug:小响应内容被写成空、已压缩类型仍被压。根因是
「该不该压」在 Write / WriteHeader / 收尾三处各判一次且判据不一致。
改成单一 mode 枚举(undecided/passThrough/buffering/streaming)、
判据只在 WriteHeader 与 Write 各求值一次后,两个 bug 同时消失。

### ★ 一条判据我自己写错了,值得记下来
TestGzipDropsContentLength 初版断言「压缩响应不应带 Content-Length」,
实测失败。追查后证明**判据错了、代码是对的**:
Go 在 Del("Content-Length") 之后,若响应体小到能被一次性缓冲(<2048B),
net/http 会**自动重算**并补上压缩后的真实长度(实测 14000B → 119B →
响应头 Content-Length: 119,正确)。真正要防的是**陈旧长度**:留着
14000 而实发 119 时,客户端按 Content-Length 读满会先拿到 119 字节再吃
unexpected EOF(已用对照探针实测复现)。判据改成两条:①声明长度 ==
实际读到字节数 ②该值 == 压缩后长度而非压缩前长度。另加一条对照判据
TestGzipStaleContentLengthWouldBreak,把危害钉成可执行断言。

### 验证(不是「应该能跑」)
- go vet 干净;全量测试通过;新增 12 条 gzip 判据;覆盖率 66.5% → 67.0%
- 真实实例(独立数据目录 + 18081 端口)实测:
  · SSE:无 Content-Encoding,2 次独立 TCP 读(逐帧下发,未被缓冲)
  · /api/v1/status(197B):不带 Content-Encoding
  · /api/v1/kernel -69%、/api/v1/settings -73%、/api/v1/plugins -63%
  · 首屏 wire 字节 77,943 → 23,339(-70%)
  · 内容完整性:gzip 解压后与明文逐字段相等(plugins/tools/build/
    channels 名称集合与顺序均一致)
- ★ 途中被一个「MISMATCH」误导过一轮:/api/v1/kernel 两次请求字节不同。
  追查发现是 IOManager.ListChannels 遍历 **map**(Go 每次迭代随机化),
  **在本次改动之前就已不确定**,与 gzip 无关。差点被我误报成压缩 bug。

附:dashboard.js 被自动格式化器整体重排(6783 增 / 6293 删,纯空白与
引号风格)。已用 prettier 归一化后逐字节比对确认**零语义差异**。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-09-27 00:02:28 +08:00
9346fed0d9 feat(webui): 星图跟随 agent 活动 + 搬到主页 + 修分类配色从未生效
星图此前只是静态展示:starmapAnimate() 只转星空,节点完全静止,
与 agent 的动作零关联。本轮三件事。

★ 修一个从未被发现的 bug:分类配色一直是坏的
  服务端 type 是首字母大写("Concept",见 internal/memory/graph.go),
  而 smTypeColors 的键全是小写 ⇒ 永远匹配不上 ⇒ 1151 个节点全渲染成
  同一个灰色 0xcccccc。浏览器实测确认:改前 colors=["cccccc"],
  改后 ["44ff88"](概念绿)。

一、跟随 agent 动(三路信号,全部在渲染循环里推进,不另起定时器)
  1. tool_call / stage / agent_output 的 SSE 事件 → 命中节点发光冲高
     + 尺寸微扩。工具名按**词**匹配实体(knowledge_list → knowledge_*)。
  2. /runtime 调度器(3s)→ 排队/中断/挂起时全图绷紧;中断或抢占计数
     上升时来一记强脉冲。
  3. /memory/graph/pulse(10s,新端点)→ 新记忆「生长」:从 0 弹到
     正常大小并留余晖。
  另:距上次活动越近,全图越亮(抽样呼吸)—— agent 一忙图就活。

二、搬到主页 + 独立页签
  总览页内嵌 360px 星图;顶部导航加「星图」独立页签(全高 + 图例)。
  同一套 renderer 用 appendChild 在容器间搬运 canvas(three.js 的
  canvas 只能有一个父节点,同时渲染会一边黑屏)。

三、性能:保留全部 1151 节点,但全部降规格
  改前每节点 = 独立 SphereGeometry(16,12) + 独立光晕球 + 一张 256x64
  CanvasTexture ⇒ 2302 个独立 geometry、约 88 万三角形、1151 个
  <canvas>,仅文字贴图就吃约 72MB 显存。全景远看根本读不清那些标签。
  改后:共享 SphereGeometry(8,6)(约 84 三角形/节点);标签改为 hover
  时在容器角上显示 HTML 文本(零显存,且比 3D 贴图更清晰);
  866 条边按关系类型合并成 4 个 LineSegments(draw call 866 → 4)。
  hover 复位随之改为 baseScale —— 旧的 set(1,1,1) 会把按 mention_count
  缩放过的大节点缩成最小尺寸。

四、/memory/graph 瘦身:不再下发稠密向量
  星图是本接口唯一消费者,却从不读 vector。生产实测该字段占
  79,314 / 402,811 字节 = 19%,而 8 块记忆就这么多,200 块就是 ~2MB
  白查白发白堆。真实数据集实测响应 402,811 → 326,997 字节(-18%)。

新增 /memory/graph/pulse:只回 since 窗口内变动过的实体(id/name/type/
mention_count/updated_at)。星图每 10s 拉它来判断「哪个节点新长出来」,
而不必重拉 400KB 全量。

验证(不是「应该能跑」):
  - go vet 干净;go test 全绿;新增 5 个测试(向量裁剪 / pulse 窗口 /
    since 放大 / pulse 不带向量 / 类型断言失败时透传不丢数据)
  - 覆盖率 65.5% → 66.5%
  - 真实 1151 节点数据集上跑 headless chromium + SwiftShader 实测:
    nodeMeshes=1151、edgeSegs=4、geoShared=true、控制台零报错、
    图例与统计(1151 节点 / 866 关系)正常、canvas 在两个容器间正确搬运
  - 脉冲匹配在浏览器里逐个 hint 验证:
      knowledge_list → 2 个(只命中 knowledge_base / knowledge_list)
      qq_get_message 等无匹配 → 8 个(走「整体活动」兜底)
    ★ 途中修掉自己的两个错:① 最早的子串匹配让 hint="knowledge" 命中
    全部单字实体(一次 pulse 选中 250 个、队列顶到 260 上限);
    ② 改成词匹配后,旧的「补齐到 20 个」逻辑又把 1 个真实命中补成 20 个
    无关节点 —— 现象与①一样,只是成因不同。补齐现在只在**完全无匹配**
    时启用。

未做(本轮范围外):服务端 gzip(首屏 793KB 无压缩,实测可压到 ~240KB)、
renderAll 按页签懒加载(首屏仍在拉隐藏页签的 kernel+settings 共 230KB)、
setInterval 15s 全量重拉(空闲 53MB/h)。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-09-26 23:31:58 +08:00
bf5d8915dd docs(site): 介绍站补「场面涌现」板块
三层记忆那张图只讲了字面相关性召回,缺了按场合召回的那一半。
新增一段说明:场面指纹(通道/对象/工具/话题/时段)如何自己长成场面、
为什么只发生一次的不算场面、以及 ScenePolicy 声明项(默认参与)。

沿用现有 card/grid-3/reveal class,视觉与既有三张卡一致;
div 与 p 配平关系与改动前完全一致(142/142、差值 40 未变)。
2026-09-26 23:14:17 +08:00
2567a22be5 fix(memory): 场景键两路合并去重(现网日志实测 scenes=[chan:qq chan:qq])
现网 21:49 的 QQ 轮次日志打出 `scenes=[chan:qq chan:qq]` —— 同一键
出现两次。查因:tooldefs.go:63 与 task.go:793 是同一段拼接写法,

    scenes := a.sceneKeysFor(...)      // 内部有 seen 去重
    turn := a.resolveTurnScenes(...)
    for _, k := range turn.Keys {
        scenes = append(scenes, k)     // ← 两路之间没有共同的 seen
    }

而声明路与通道派生路都会产出 chan:qq(既是插件声明的、也是从
evt.Source 派生的),于是重复。

功能上无害(RecallByScene 内部会再去重),但有两个实际代价:日志里
的 scenes=[...] 误导排查——会让人以为场景集合本身有问题;以及每次
白走一遍前缀匹配。

修法:抽 mergeSceneKeys 共用函数(顺带消掉两处重复代码),两处调用点
都走它。判据 scenemerge_test.go 5 例:3 个合并场景(同名 / 归一化后
同名 / 多路重复)+ scene_policy=none 时两路皆空(防「声明路关了但
涌现路还开着」的半开状态)。

记忆 8 包 + agent/core 全绿,8 包齐全、无 FAIL/panic/race。
2026-09-26 21:55:12 +08:00
13a070fbb2 docs(memory): 标记步骤 3/5 完成,补步骤 4 部署前基线与硬约束
步骤 4 加了硬约束提醒:必须先部署含 R1 修复的二进制再清理,否则
重新涌现出来的还是带 +/# 的旧键。并记录部署前实测基线(PID 92115、
子进程插件 25、近 24h 异常日志 0、场景 65),以及 homed --version
这个 flag 并不存在(纪律清单那条要用 status 接口或 ps 核对)。
2026-09-26 20:17:17 +08:00
758ec11832 fix(memory): 图整备覆盖 scenes + 证据桶按桶清(R3/R5)
R3:图整理心跳只查 entities/relations,scenes 完全没有整备路径。
Recall(nil,nil,1,"") 的全量路径只 SELECT 这两张表
(graph.go:609/631),于是同一场面的双胞胎键从建库起无人发现:
auto:chan:qq+part:morning 累积到 strength=271 / 6 features / 0 refs,
孪生的 auto:chan:qq_part:morning 持有 210 refs 却 0 features
(聚类只读 scene_features,所以它永远不被看见)。

新增 GraphDB.DedupeScenes:归一化后同名的场景合成一个——强度相加、
特征取并集(权重取大)、引用全部重定向,存活者保留 id 最小行,
跨 origin 也合。接到 mergeLoop 尾部。

为什么不塞进 detectEntityMerge 的双重循环:
- 实体是全库两两 bigram + LLM 裁决(1 万实体实测 5000 万次配对、
  ~224GB 瞬时分配每轮,是独立问题);
- 场景的判重口径是**归一化后是否同名**——同名即同一场面,键相同
  本身就是证据,不需要 LLM 裁决。而「像不像」是 EnterScene 聚类的
  职责,不是这里的事。
只做同键合并、不做相似度合并:把 chan:qq 与 chan:webui 合并是危险
的,去重不是「把像的一律合并」。

生产库副本实测(sqlite3 备份式复制到 /tmp,未碰生产):
65 个场景 → 合并 8 组 → 57 个;
auto:chan:qq_part:morning 的 refs/rel/ent 一条没丢,strength 1 → 272。

R5:createSceneLocked 新场景成立时执行的是
`DELETE FROM situation_evidence`(全表清),而证据表是多通道共用的
计数桶。后果不是「多清一点」:qq 的场景一长出来,就把 mc/webui/cli
尚未攒够 minSceneEvidence=2 的证据抹掉,它们的计数被反复清零,
于是**永远**攒不到 2 次。判据实测:6 个通道各来 3 次,只长出 2 个场景。
改为 `DELETE ... WHERE label = ?`,只清本指纹那个桶。

判据:scene_dedupe_test.go 8 例(含「不同场面不得被合并」与幂等)、
scene_evidence_test.go 3 例。均先红后绿。修 R5 时差点栽:桶键是
sig.Label(2) 本身、不带 auto: 前缀(base 才是带前缀的场景键),
第一版删错对象会「一条没删却看起来通过」,用探针实测真实桶键后改正。

记忆 8 包 + agent/core 全绿,8 包齐全、无 FAIL/panic/race。
2026-09-26 20:16:11 +08:00
8887e06274 feat(sdk+memory): 补 ScenePolicy 声明项,让通道能退出场面识别
缺口(R6):ChannelDef 的记忆声明已有三件套——NoMemory 管「进不进
记忆计算」、ContextPolicy 管「裁不裁上下文」、RecallPolicy 管「召不召回
记忆」,唯独没有「这条输入算不算一场戏的一部分」。现状是无条件参与:
situationFeaturesFor 里只要 evt.Source != "" 就产出一个 chan 特征,没有
可关的开关 ⇒ chan:system / chan:kernel / chan:timer 这类纯内部信噪通道
也在撑场面,每次触发都让不相干的场景长出来或变强,召回时又会把
「内核在跑定时器」当成「用户在这类场景下说过的话」取回。

穷举确认不是查漏:go.mod replace 指向 third_party/homeagent-sdk,
plugin.go 中 scene 出现 0 次,SDK 自身 git 历史 -S'Scene' -- sdk/ 为空。

SDK(纯追加,老插件行为逐字节不变):
- 常量 ScenePolicyAuto / ScenePolicyNone + ValidScenePolicy,形状与
  ContextPolicy / RecallPolicy 完全一致
- ChannelDef.ScenePolicy 与 InjectOptions.ScenePolicy,均带 omitempty
- 默认取 auto(参与)而非 none:场景只附加检索路、不改记忆本体,
  默认关会让存量通道突然失去召回;「关」是少数意图。与 ContextPolicy
  刻意相反(同为破坏性操作,那里是默认关)。

内核:
- applyInjectOpts 搬运 scene_policy(与另外三个标志位同面)
- sceneSuppressed 完全照 recallDeclared 的形状:注入点 payload >
  通道定义 > 默认。none 时连时段(part)特征都不产,也不派生场景键
  (只停指纹采集而留声明路,等于给这个口子开后门)
- situationFeaturesFor / sceneKeysFor 由包级函数改为 Agent 方法
  (需要 a.io 查通道定义),23 个调用点同步

判据:scenepolicy_test.go 7 例,改前编译期红(undefined:
pubsdk.ScenePolicyAuto),改后全绿。其中两例专门护住「未声明时行为
逐字节不变」,是纯追加承诺的护栏。

记忆 8 包 + agent/core 全绿,8 包齐全、无 FAIL/panic/race。

存量通道标注待定:kernel/timer/offload-*/child/* 是纯 0-refs 信噪,
可直接标 none;但 mc:system(12 refs) 与 system(3 refs) 带真实记忆,
性质不明,不擅自标。
2026-09-26 20:09:17 +08:00
f441574b80 docs(memory): 补 R6/R7 与 SDK 声明项方案,重排为 7 步
R6:ChannelDef 的记忆声明已有三件套(NoMemory/ContextPolicy/
RecallPolicy),唯独没有「这条通道是否参与场面识别」,现状是无条件
参与 ⇒ chan:system/kernel/timer 等内部信噪通道也在场面聚类里。
穷举确认非查漏:go.mod replace 指向 third_party/homeagent-sdk,
plugin.go 中 scene 出现 0 次,SDK 自身 git 历史 -S'Scene' 为空。

R7:payload[scene] 的层级键(chan:qq/peer:group_1)已支持前缀
召回(RecallByScene scene.go:351),但因 R6 无人使用而闲置。

步骤重排为 7 步:SDK 声明项提到步骤 2(用户已授权动公开 SDK,
开发阶段非 release 阶段),并把「peer 覆盖面」拆到步骤 6 单列,
先只读调查插件手上有什么再动。
2026-09-26 20:03:51 +08:00
6e9420965d docs(memory): 补 R4 覆盖面与 R5 证据桶两条根因
R4:现网 65 个场景键里 peer 主导 0 个、topic 主导 0 个,36 个
auto:chan + 26 个 chan: 全部锚在输入通道。两个独立原因:
采集侧全仓无插件在 InjectInput 填 peer/group_id/user_id/chat_id
(日志中 peer 出现 0 次);排序侧 chan 与 peer 权重同为 1.0 而
NewSituation 稳定排序让 chan 恒在前,即使采集到也进不了 Label(2)。
这与 R1/R2 是不同层面:R1 修完只会得到「正确的单一维度」。

R5:createSceneLocked 新场景成立即 DELETE FROM situation_evidence
(全表清),会连带清掉别的场景尚未攒够门槛的证据。
2026-09-26 19:58:00 +08:00
1fa9ef68a4 fix(memory): 场景键归一化 + 排除最弱维度,修双胞胎与空转
现网实测:scenes 表 65 行里有 6 组是同一场面的双胞胎键,最严重的
auto:chan:qq+part:morning 累积到 strength=270、6 个 features、
0 条记忆,日志里被"命中"179 次;孪生的 auto:chan:qq_part:morning
则持有 201 条记忆却有 0 个 features(不参与聚类)。两套特征体系
各活各的,谁也发现不了谁。

病因:键构造不唯一。
- Label() 直接用 "+" 拼接且不过 NormalizeSceneKey,而
  EnsureScene / effectiveScenes / RecallByScene 三处都过了归一化。
  "+" 会被 normalizeSceneSegment 归一成 "_",于是两个字符串都合法,
  key UNIQUE 约束拦不住。
- Label(2) 会把权重仅 0.2 的 part(时段)挤进场景身份。实测
  morning 场景吞掉 evening 指纹:共享 chan:qq 权重 1.0、并集含
  part 0.2×2,相似度 1.0/1.4 = 0.714 > joinSceneThreshold 0.5。
  这本就是加权 Jaccard 的正常行为,但键名不该写进时段。
- createSceneLocked 的 "#N" 冲突后缀同样会被归一成 "_",
  造成 auto:chan:mc:event+topic:mc#2 在库、而写侧归一化后去找
  auto:chan:mc:event_topic:mc_2 —— 又一对匹配不上的双胞胎。

修法:
- Label 只取权重 ≥ 0.5 的主导特征,结果过 NormalizeSceneKey;
  全部特征都弱于门槛时退回最强的一批(宁可名字信息量低,也不能
  没有名字 —— 没名字就没有键,场景根本长不出来)。
- createSceneLocked 对 base 再做一次防御性归一化,并在 label 为空
  时拒建无名场景。
- 冲突后缀由 "#" 改为 "."('#' 会被归一化,'.' 是白名单字符)。

判据:新增 scene_key_test.go 6 例,参照物在生产代码之外("同一场面
⇒ 同一个键"这条不变量 + 直查 scenes 表复算行数)。先跑红确认判据
在跑(4 红 1 绿,失败的正是键唯一性/时段污染/证据桶),再改实现。
其中 TestWrittenRefReachableFromItsScene 一开始就是绿的——写侧到读侧
那条路本身是通的,坏的只是键的构造。

记忆 8 包 + agent/core 全绿。
2026-09-26 19:56:28 +08:00
8bd8271f49 Revert "fix(agent): output_send 缺收件人时从输入事件自动补"
This reverts commit 6b74862.

## 为什么撤

方案本身是错的,三点:

1. **假设 meta 的收件人字段跨通道通用。** 只实现了 qq(user_id/group_id),
   而 wechat、群聊各有各的字段名。逐通道补全会变成一张靠猜的映射表,
   每加一个通道就得重猜一遍。

2. **假设「回复来源 = 收件人」。** 线上实测直接推翻(2026-09-26 19:05):
   一次请求从 webui 会话发起、却要发到 QQ(input source=webui,
   output channel=qq)。收件人与来源根本不是一回事 —— 用户在
   WebUI 里说"发个 QQ 给我",收件人只能来自上下文或用户明说。
   按 channel 名补,等于用错误的假设去覆盖真实场景。

3. **没解决问题,反而引入新风险。** 19:05:46 那次照样报同样的错
   ("meta 中需要 group_id 或 user_id"),补全逻辑对跨通道场景无效。
   而一旦补错,消息会发给错的人 —— 那比报错坏得多。

## 保留的部分

现象描述与排查结论留在这个 revert 的说明里,便于后续重新设计时
不再重复踩:各通道 meta 结构差异极大,要让插件自己声明收件人来源
(qq 插件知道自己的 user_id 从哪来),内核只转发不猜。

不采用"把格式写进工具描述"这类方案:那只缓解症状,
且各通道格式仍需逐个核实。
2026-09-26 19:11:51 +08:00
6b74862118 fix(agent): output_send 缺收件人时从输入事件自动补
## 现象(线上 2026-09-26 17:57)

用户从 QQ 私聊发来消息,agent 生成了回复也调了 output_send__qq,
但**没填 meta**:

  17:57:45  qq_get_message → {user_id: 2198972886, message_type: private}
  17:57:46  output_send__qq → 失败:meta 中需要 group_id 或 user_id 字段
  17:58:14  output_send__qq_help → 查格式
  17:58:14  output_send__qq → ok      ← 靠重试成功,整轮耗时 74s

信息内核**本来就有**(输入事件里带着 user_id/group_id),却要模型从
qq_get_message 的返回里手抄进 meta。抄错就失败,失败才去查 _help。
而"回复"这件事的收件人是确定的(= 消息来源),本不该由模型负责。

运气差就不重试:同日 17:15 / 17:21 两次 `tools=[]` —— 模型压根没调
output_send,回复生成了但没发出去,日志连一行告警都没有。

## 改法

meta 缺收件人时,内核从**本轮输入事件**推导后补上。模型只需给内容。

## 边界(都刻意收窄:宁可不补,也不能补错)

- 显式传了 meta ⇒ 原样返回。主动 DM 别人等场景必须保持原行为。
- meta 里已有 group_id/user_id ⇒ 不覆盖。
- meta 是坏 JSON ⇒ 原样返回。让下游报"格式错",而不是被静默替换成
  一个模型没要求过的收件人 —— 那比报错更坏:消息会发给错的人。
- 非 qq 通道(如 webui)⇒ 不补。webui 走 ResponseCh,不过 output_send。
  其余异步通道(wechat 等)不猜:猜错等于发错人。
- 输入事件里没有收件人信息 ⇒ 留空,让下游按原逻辑报"需要 user_id"。
  宁可报错让模型重试,也不要编一个收件人。
- 群消息里 user_id 是**发送者**不是收件人 ⇒ group_id 非 "0" 时优先用
  group_id,否则会把消息发回给群成员本人。

数字型 user_id 要按整数格式化:JSON 反序列化成 float64 时
fmt.Sprint 会得到 "2.198972886e+09"。

## 判据:7 条

私聊补 user_id / 群聊补 group_id 且不补 user_id / 显式 meta 不改写 /
已有收件人不覆盖 / 坏 JSON 不静默替换 / webui 不补 / 无信息留空(含 nil evt)。

★ 实现时我先自己写了个 payloadString,编译报错才发现包内已有更完整的
  版本(memorypass.go:176,含 float64/int64/int/json.Number 分支),
  直接复用 —— 不重复造轮子。

全量 42 包绿。
2026-09-26 18:29:23 +08:00
bd1d5fff2b chore(vendor): 主仓不再跟踪 SDK 示例代码(决策 A)
## 背景

`.gitignore` 第 26-45 行早已写明「外部插件与工具链维护在独立 SDK 仓
(决策 sdk_repo_only),本仓经 go.mod 的 replace 引用」,并忽略了
example/、tools/、docs/、site_build/、package/、scripts/。

但有 29 个文件**早于该规则**被跟踪,靠「已跟踪文件不受 .gitignore
影响」留着,注释还特意写了「这是有意的,不要『修』」。

本轮修 example/bili 时踩到了:那 87 行改动先落在主仓、再手动同步到
SDK 仓 —— 同一份代码两个仓各改一遍,正是这个遗留结构的成本。

## 核实:主仓到底需要什么

- 主仓 Go 代码只 import 两个包:`homeagent-sdk/sdk`(插件入口)、
  `homeagent-sdk/meta`(版本号)
- `remotedevice/` 是 C 库,主仓 C 侧明确「不链接任何外部库」,
  只有注释里提到它
- `tools/hmapdev/yaegi` 的 import 出现在 **SDK 仓自己的文件之间**
  (yaegi/interp.go → yaegi/mocksdk),不是主仓依赖;
  且 tools/ 本就在 .gitignore 里,从未被跟踪

所以 29 个文件全部可以删。实际仓库负担也只有 42 个文件 / 0.6MB
(工作树里那 971MB 绝大部分是未跟踪的构建产物,不是仓库体积)。

## 改动

- 删 21 个 example/ 文件(10 个示例的 plg.json + plugin.go + qq/plugin_test.go)
- 删 8 个 remotedevice/ C 文件
- 工作树里一并清掉(不受跟踪的构建产物顺带回收)

构建与全量测试均通过。

## 判据:3 条 + 变异(internal/meta/vendored_sdk_test.go)

- TestVendoredSDKHasNoExampleOrRemotedevice:防止示例代码被重新提交进来
- TestVendoredSDKKeepsRequiredPackages:**反向**保护,防止为省事把
  sdk/ 与 meta/ 也删掉(上一条只防"多了",删过头要靠这条)
- TestGoModStillReplacesSDKToVendoredPath:决策 A 依赖 replace 指向 vendored 路径

★ 判据自己踩了两个坑,都靠实跑抓出来:
1. `git ls-files` 的路径参数**相对当前目录**解析,而测试跑在
   internal/meta/ 下 ⇒ 就地执行返回空,表现为「必需包全都不在」的假红。
   改用 `git -C <仓库根>`。
2. 把 tools/hmapdev/yaegi 当成主仓依赖写进必需清单 ⇒ 又一次假红。
   根因是把 SDK 内部的引用误当成主仓依赖(它本就在 .gitignore 里)。

变异验证:塞一个 example 文件进版本控制 → 判红。
2026-09-26 17:18:41 +08:00
ceeef0b4e1 fix(proc): 杀插件进程组 + readerWG 超时兜底 —— 修孙进程拖死关停
## 现象

线上关停必超时:systemd 报 `State 'stop-sigterm' timed out. Killing.`,
进程组里 23 个插件全退完了,最后那条 `[homed] stopped` 仍打不出来。
其中只有 bili 报 `[proc] bili SIGKILL 后 2s 仍未被收割`,之后近 90 秒无日志。

## 根因

bili 用 exec.Command 拉 yt-dlp(源码 example/bili/plugin.go:122/212),
无 CommandContext、无 Setpgid、Stop() 是空的。yt-dlp 再 fork ffmpeg,
**孙进程继承插件的 stdout 管道写端**。

  插件被 SIGKILL → 孙进程仍存活、写端不关
  → readLoop 的 scanner.Scan() 永不 EOF
  → p.readerWG.Wait() 永不返回(Kill 的最后一行,**无超时**)
  → StopAll 的 wg.Wait() 永不返回 ⇒ 关停挂死 ⇒ systemd SIGKILL

内核 process.go:340 的注释早已预警过这个场景("插件 fork 的孙子进程继承
同一 stdout 写端时,插件本体死了 EOF 也不会到"),但 Kill 没有对应保护。

## 内核三处修法(缺任一条都不够)

1. **spawn 时 Setpgid**:插件自成进程组,不再与内核同组
2. **Kill 杀整个进程组**(kill(-pgid)):孙进程一起死,管道写端才关。
   兜底:负 pid 失败时退回杀本体(老插件/非 Unix 平台)
3. **readerWG.Wait() 加超时兜底**:这是唯一能保证 Kill 一定返回的地方。
   超时后主动关读端逼 readLoop 退出,再兜一层仍不退就放弃等待 ——
   宁可少等 2 秒,也不能把关停无限期挂住。

## 插件侧(bili)

CommandContext + Setpgid + Stop() 里 cancel 并 wait:
- 只 cancel 不 wait 的话内核会先释放共享段,而 yt-dlp 还在写 stdout
- waitRunGroup 杀整个进程组(ffmpeg 也在内),不留孤儿

## 判据:5 条 + 3 组变异

判据用**真实模板编译的插件**(复用 buildPluginWithRealTemplate,
与 e2e_template_test 同一条路)+ NewHost 启动,不是自造 shim:
裸 Spawn 没有 Host 建共享内存段,插件握手会报 permission denied。

★ 判据自己踩了三次坑,都由变异/合跑抓出来:
1. 给孙进程也加 Setpgid ⇒ 它逃出插件进程组,kill(-pgid) 杀不到,
   造出假失败(真实场景 yt-dlp 不会脱离进程组)
2. 各测试数全局孙进程数 ⇒ 前一个泄漏的被后一个数进去,
   单跑通过、合跑变红。改为记录基线只关心自己新增的
3. readerWG 超时那条用纯构造 &Process{cmd:nil} ⇒ Kill 第 607 行
   早退,根本走不到那段,撤掉超时照样绿。补了「脱组孙进程」
   场景(Setsid 逃出进程组)才真正覆盖到

变异:去 Setpgid → 判红;只杀本体不杀组 → 判红。

全量 41 包绿。
2026-09-26 16:58:41 +08:00
324181d663 fix(plugin): StopAll 并行停插件 —— 修关停必然超时被 SIGKILL
## 现象

systemd 每次都报 `State 'stop-sigterm' timed out. Killing.`
进程组里 23 个子进程插件**全退完了**,最后那条 `[homed] stopped`
仍打不出来,然后被 SIGKILL。

## 根因(算出来的,不是猜的)

单个插件的 Stop 最坏预算:
  5s(CallContext plugin.stop)+ 5s(等 exited)+ 2s(Kill 后收割)= 12s
串行停 23 个 ⇒ 23 × 12s = 276s,而 systemd 只给 90s。
⇒ 关停必然超时。线上每一条 stop 记录都是 timed out,无一例外。

## 改法

StopAll 改为并行:取插件快照 + 各自的 SDK 句柄后**立即释放 registry 锁**,
每个插件一个 goroutine,等全部完成再释放共享段。

三处必须小心的点(都是并行化引入的新风险):

1. **先释放 registry 锁再并行停**。p.Stop() 会触发
   markExited → onExit → ReclaimOwner,那条链要读共享内存段。
   持着锁并行跑,若某插件的 onExit 需要拿 registry 锁(摘通道等)
   就是自死锁。
2. **stop handler 的快照要在清空 sdkRefs 之前取**。handler 挂在
   PluginSDK 上(r.sdkRefs),先清空就再也拿不到了。
3. **单个插件 panic 不带崩关停**(那会让剩下的插件全停不掉),
   也不静默吞(留日志)。

## 判据:5 条 + 3 组变异 + race

- TestStopAllStopsInParallel:8 个插件各 120ms,串行 960ms / 并行 120ms。
  判据直接量耗时,串行实现必然变红(实测串行时 962ms)。
- TestStopAllSurvivesPanickingPlugin:panic 不外冒、其它插件照停、不死锁
  (带 10s 超时,死锁会超时而不是挂住测试)
- TestStopAllFreezesAutoRestart / StopsEachPluginExactlyOnce:
  冻结自动重启、每个插件恰好 Stop 一次(重复会二次释放共享段)
- TestStopAllRunsStopHandlerBeforeStop:handler 必须先于 Stop,
  走真实的 PluginSDK.RegisterStopHandler 路径

变异:退回串行 → 判红并打出实测耗时;去掉 handler 调用 → 顺序判红;
假装并行只清空 → 4 条判红。
`-race` 通过(并行化必须验锁,这是本次改动的头号风险)。

全量 41 包绿。
2026-09-26 16:23:56 +08:00
5dd98d7a05 feat(knowledge): 目录批量导入 + 派生数据批量收口
## 能力缺口

导入只能一条条 Add(knowledge_create)。agent 拿到一份 200 页的
文档目录要调 200 次工具,且每次都得自己决定分类与名字。

新增工具 `knowledge_import_dir(dir, category?, include_media?, dry_run?, max_items?)`。
语义是**复制**不是引用:源文件删改不影响已导入的副本。
- 文本经 Write 整份写入 <知识根>/<分类>/<名>/content.md
- 媒体按 sha256 进媒体库(内容寻址天然去重),条目只存 digest 引用

## 目录约定(自动适配,不要求改造资料)

1. 含 content.md 的目录 ⇒ 整体作为一个条目(与 scanDir 既有语义一致,
   所以知识库自身目录能被原样再导入而不会被拆散)
2. 否则 .md/.txt 等文件各成一条,**目录路径即分类**

## 三个语义决策

- category 是**前缀叠加**(tech + 源结构),不替换:替换会丢掉源目录
  自身最有价值的层级信息
- 同名冲突**跳过并计数**,绝不覆盖:Write 对同名本就是覆盖语义
  (knowledge_create 靠它做更新),若直接调它,一次重导就会把手工
  补充的内容悄悄抹掉,而日志只写"导入完成"
- dry_run **默认 true**:批量写,agent 第一次试某目录应先看清会写什么

## 安全边界(批量操作,缺一道就可能读到不该读的)

- 必须绝对路径:agent 的 cwd 不受控,相对路径会静默导到别处
- 符号链接不跟随:否则一个软链就把知识根之外的文件导进来
- 拒绝把知识库自身当源(自导会无限自我复制)
- category 复用 normalizeName(与 Write 同一道闸,两处分叉就成了绕过)
- MaxItems 默认 500:防 agent 误传 "/" 把盘灌满

## ★ 批量导入暴露的既有 O(N²)

Write 每条末尾都调 flushDenseLocked,而 saveDenseCacheLocked 是
**全量序列化整个 items map 再重写整个文件**。按 512 维 float64 估,
单条约 10KB,导入 500 条累计要写约 1.4GB。

仓库里索引侧早已有 indexDirty 的「标脏+延迟收口」(实测 writeIndexLocked
6.7ms/次、占单条 Add 绝大部分),**稠密缓存却还是逐条全量重写** ——
同一类开销只修了一半。

照 indexDirty 的模式补 batchDepth:批量期只标脏,endBatch 收口一次。
用 defer 保证提前 return 也会收口 —— 否则这批向量会留成"标脏未写",
下次启动被当作缺失而全量重算。

## 判据:17 条 + 变异

安全边界做了 4 组变异验证(去符号链接拦截/去绝对路径要求/去自导检查/
content.md 目录不下钻)。

★ 判据第一版有两处自己骗自己,被变异抓出来:
1. 符号链接判据造的是**目录软链**,而 WalkDir 对目录软链本来就不下钻
   ⇒ 有无防护结果都一样,是假绿。改成**文件软链**后才真正判红。
2. 同名冲突判据里已有条目写成 "a/b"、源映射出的是 "b"(不同名),
   判据自己就错了 —— 修判据而不是改实现。

媒体路径用假 MediaPutter:验的是「调了 Put 且 digest 挂到条目上」,
媒体库自身的落盘去重是 media 包的判据,不该在这里重测。

全量 41 包绿。
2026-09-26 16:19:10 +08:00
dev
ef695c2723 chore(meta): main 构建产出 1.4.0dev 路牌,不再自称旧 patch 线 2026-09-26 15:44:35 +08:00
dfc05780fd feat(kbtree): 知识库暴露范围配置 —— 按树状只暴露指定分类
## 问题

kbtree 是**唯一**把知识库开放给外部进程的通道(HomeAgent 自己的 agent
走进程内直调 knowledge_* 内核工具,不经此),但它只有 listen_addr 与
token 两个配置,**没有任何范围限制**:拿到 token 的任何 agent 都能
/tree 列出全部条目、/search 取回任意条目全文。

本机库里混着个人内容(航空发动机教材摘录、课表、身份合并规则),
不该 broadly 可读。

## 改动

1. `internal/plugins/kbtree/scope.go`(新):暴露范围语义
   - 留空 = 全部可见(范围是"限制"不是"必填",留空保持既有行为)
   - 前缀按**路径分段**匹配:public 命中 public 与 public/tech,
     但**不**命中 publication(否则 publication 意外暴露)
   - 根下无分类的条目在范围非空时不可见 —— 它没有分类可匹配,
     放行等于范围形同虚设
   - 分隔符容忍逗号/分号/空白/换行/竖线:这是给人手填的字段

2. `plugin.go`:注册 `expose_categories` 配置项,接入**全部四个端点**
   - /tree      服务端裁剪子树(就地改,不重建:TreeView 字段多)
   - /categories 过滤路径列表
   - /counts    过滤计数并**重算 total**(数量本身也是信息泄露)
   - /search    ★ 过滤结果条目;这处最关键:
     只过滤 /tree 而放过 /search 等于范围形同虚设(换个 ?q= 就能拿到全文)。
     同时修正 limit 语义 —— 范围外条目不占名额,范围内条目不会被挤掉。

3. SDK 契约补 `Knowledge.Category`(纯增量)
   - 此前 `sdk.Knowledge` 只有 Name/Content,内核明明返回了 Category
     却在 knowledge_impl 的拷贝里丢掉 ⇒ 外部服务无法按分类判定,
     范围过滤在 SDK 层根本做不了。
   - Name/Content 均保留,无删除。

## 判据(8 条 + 4 组变异)

范围过滤最容易"只做一半",所以每个端点都单独钉。

★ 判据补强一处:初版只查条目名(priv1),结果「/categories 不过滤」
  这个变异**完全逃过** —— 分类端点返回的是路径不是条目名。
  补上分类路径断言(private)后判红。

变异验证:
- /search 不过滤      → 泄露 priv1 全文        ✓ 判红
- /categories 不过滤  → 泄露 private 分类路径   ✓ 判红(补强后)
- /counts 不过滤      → TestCategoriesAndCountsEndpoint 判红
- 前缀退化为字符串前缀 → publication 被误暴露      ✓ 判红

★ 过程中我的 fake 有两处与真实内核不符,先修 fake 再修实现:
  1. 漏了内核 treeLocked 的"子分类提升一层" ⇒ 得到 children=0 的假空树
  2. filterTree 无差别清空 t.Items ⇒ 整棵树只剩空壳节点
  (第一版的实现是"看着测试红就改",实际是 fake 在骗我)

全量 41 包绿。SDK 接口纯增量,未发布故无需冻结检查。
2026-09-26 15:31:15 +08:00
78806efa0f fix(kbtree): 修客户端脚本三处实测暴露的缺陷
都是本机装好后逐条跑命令发现的,不是设想:

1. **token 找不到**:脚本找 `scripts/../config.json`,而实际文件在
   `<skill>/config/config.json`。症状极具迷惑性——「明明配了 token 却说
   没找到」。改为两种布局都试,并在注释里写明为什么不能只写一种。
2. **`-h` 也要 token**:帮助段排在 token 检查之后,`kb_tree.sh -h` 会被
   拦下报「未找到访问令牌」。把 help 提到最前。
3. **`-q` 被当成命令名**:`kb_tree.sh -q 并发`(不给子命令)报
   「未知命令: -q」,而这是很自然的写法。改为:第一个参数是选项时不取作
   子命令,解析完选项后再定——有 -q 走 search,没有走 tree。

另外把 curl -f 换成 -w + 自行判状态码:-f 在 4xx 时只吐一行
`curl: (22) 404`,把响应体丢掉,而 404 响应体里恰是「现有分类」清单,
是排查时最需要的。现在 401/404 都会给出可行动的中文提示,
退出码 0/2/3/4/5/7/8 各有语义。
2026-09-26 14:47:32 +08:00
5a889007d7 docs(kbtree): 补客户端封装脚本 + 本机部署交接说明
SKILL.md 里原本只有 curl 示例,agent 用起来要自己拼 URL 与鉴权头。
补 scripts/kb_tree.sh(照 dify-ops 的做法把脚本随 skill 分发):

- 子命令 tree/categories/counts/search,选项 -q/-c/-d/-i/-l
- token 读取顺序:KB_TOKEN 环境变量 → config/config.json。
  **故意不接受命令行传 token**(会进 shell 历史与 ps 输出)
- 预检端口:不通时直接说明「服务未上线」并给出上线步骤,
  而不是抛 curl: (7) Connection refused 让用户自己猜
- 错误翻译成人话:401 → 令牌无效;404 → 附上服务端返回的现有分类
  (用 curl -w 而非 -f,否则 404 响应体里最有用的那份清单会被丢掉)
- 退出码:0 成功 / 2 参数 / 3 令牌 / 4 分类不存在 / 5 HTTP / 7 连不上 / 8 请求失败

DEPLOY.md 是给部署方的交接单:本机 kbtree 代码已合入 main 且 skill/token
已就位,但**运行中的二进制里没有 kbtree**(14:35 有人换过一版二进制),
故替换与重启留给部署方。含备份/替换/验证步骤、回滚方式、端口与 token 说明。

token 与 config.json **不入库**(config/ 目录留空),安装时由部署方从
配置库 config_kbtree 表读取后写入本机。
2026-09-26 14:43:46 +08:00
7212ab4aad fix(webui): 星图依赖本地化 —— 不再从公网 CDN 拉 three.js
用户点「星图」看到「3D 星图不可用(CDN 加载失败)」。

服务端 curl 那两个 URL 都是 **200** ⇒ 不是服务端的问题,是**浏览器**
访问不到公网 CDN(内网 / 出口受限 / 断网)。dashboard.html 从 cdnjs 与
jsdelivr 拉 4 个库:three.js、OrbitControls、marked、DOMPurify。

换 CDN 只是把同一个赌注重下遍。HomeAgent 明确支持离线与内网部署,
前端却有 4 个硬依赖在公网上 ⇒ 断网即坏,且用户无从修复。

顺带两个收益:
- **安全**:DOMPurify 是净化 Markdown 的关键一环,它挂掉前端会退化到
  「不净化」分支(dashboard.js 里有 typeof 检查)—— 那是安全降级,
  比星图坏更值得修。
- **体积**:四个库共 ~700KB,embed 后由本服务同源提供,省掉 4 个跨域握手,
  也不再受第三方可用性影响。二进制 84MB → 84.7MB(+0.8%)。

- `internal/plugins/webui/static/` 放四个库(固定版本,随二进制走)
- `//go:embed static` + 新增 `/static/` 路由
- dashboard.html 的四个 src 改指 `/static/...`
- 加载失败兜底 8s → 3s(本地是毫秒级;仍超时就说明真有问题)

`/static/` **不走 requireWeb**:未登录时页面也要加载这些库才能渲染登录框,
加认证会让用户看到白屏(比 401 更难自查)。这些资源不含用户数据。

- TestDashboardHasNoExternalCDN:页面不得引用任何公网 CDN
- TestStarmapDependenciesAreLocal:星图两个库必须来自本地
- TestVendorFilesExistInSourceTree:vendor 文件必须在(embed 的前提)
- TestStaticVendorRoutesServeRealLibraries:路由**必须真的返回库内容**

★ 最后一条的判据强度是补出来的:初版只判状态码,变异「返回 200 + 空体」
时**仍然绿** —— 而空体在浏览器里的症状与 404 完全一样(都报加载失败)。
改为同时判体积与特征串(REVISION / OrbitControls / marked / DOMPurify)
后,变异「只写前 10 字节」判红。

变异验证 3 条:HTML 改回 CDN → 2 条判红;路由挂回 requireWeb → 503 判红;
截断响应体 → 体积判红。

全量 38 包全绿。
2026-09-26 14:41:32 +08:00
41d754334e feat(kbtree): 知识库分类树的独立只读服务 + agent 技能 + WebUI 树浏览
让**外部 agent** 也能按分类树用这套知识库。HomeAgent 自己的 agent 仍
直接调内部方法(knowledge_search/create 等),走进程内直调,不经此服务。

一、内核树视图(internal/knowledge/tree.go)
  为什么不复用 TreeIndex:那个是**内部导出物**,面向 .index.json 落盘,
  每个条目带 top-20 的 TF-IDF 特征向量。直接序列化给外部有三个问题:
  体积(200 条时 .index.json 已 246KB 且冗余存了 preview,而正本在
  content.md)、泄漏(稀疏特征表 = 分词/IDF 内部表示)、语义错位
  (外部要的是"有哪些分类、每类下有什么")。
  新增 TreeView/Subtree/Categories/CategoryCounts:不含向量,带条目数
  与可读摘要,支持 MaxDepth 懒加载、IncludeItems 只看结构。
  节点 Name 是**本级段名**("go")、Path 是完整路径("tech/go")——
  最初把全路径写进 Name,前端拼层级会得到 "tech/tech/go",已修。

二、kbtree 插件:独立 HTTP 服务(默认 127.0.0.1:9892)
  为何不挂在 WebUI 的 /api/v1/knowledge* 下:
  1. 不共享鉴权与端口。WebUI 的 api_key 是给人操作界面用的,把它分发给
     外部 agent 等于把管理面凭据扩散出去。本服务用**独立 token** +
     独立端口,可单独关闭(token 未配置则启动时随机生成)。
  2. 只读。写入要决定分类归属与媒体处理,外部自行拼装容易造出越界/重名
     条目 —— 写入留给内核工具。
  3. 形状按树组织,而不是平铺搜索接口。
  端点:/tree(可指定 category/depth/items)、/categories、/counts、
  /search、/ (自述)。全部需 token(X-API-Key / Bearer / ?token=),
  非 GET 一律 405。无知识库时 Start 直接失败,不占端口。
  鉴权与 Slowloris/超时设置照 remotedevice 范式。

三、agent 技能(assets/skills/knowledge-base/SKILL.md)
  指令文档型 skill:教模型"先看树 → 定位分类 → 分类内检索",并列出
  易错点(name 已含分类别再拼、只看第一条、404 附现有分类)。
  加载与校验由 internal/plugin/skill_bundled_test.go 守住 —— 这条断言
  的由来:非白名单的二级标题会被 extractToolDefs 当成工具定义,报错
  "invalid tool name",而提示与真正原因(标题层级)毫无关联。
  kbtree 的测试还会校验文档提到的端点与代码一致,防漂移。

四、WebUI 树浏览(前端真正用起来,而非留一个没人调的端点)
  面板加可折叠的分类树:逐级点选即把搜索范围切到该子树(原先是让人
  手打分类名)。当前范围有可见标签与「全库」复位。
2026-09-26 14:20:19 +08:00
ce694bc1a1 test(knowledge): 端到端验证多模态与分层链路 + 修稠密路同分次序不确定
一、修缺陷:denseHits 同分次序随机
  稠密路用 map 遍历 + 只按分数排序,**没有 tie-break**:同分条目的相对
  次序随每次调用变化 ⇒ 同样的查询两次可能给出不同首位(用户看到结果在跳,
  测试偶发变红)。Search 的主排序早就有「分数相同时按名字定序」,这条漏了。
  补上同分按 id 定序,并加 TestDenseHitsTieIsDeterministic 反向守住
  (撤掉 tie-break 后该测试在 5 次运行里稳定报出首位跳变)。

二、端到端验证(两个新文件)
- TestMultimodalEndToEndWithRealProvider:走**真实 embedding provider**
  (内置 http provider + 一个符合内核契约的最小服务),覆盖
  embedding.Open → AdaptProvider → media CAS → SetDenseSpace/SetMediaGetter
  → AddWithMedia(文本⊕图片融合)→ 以图搜知识 → .dense.json 落盘 →
  重启命中缓存(ReindexDense built=0)。
  不用 ONNX provider 是因为真模型 200MB 权重 + 3 分钟加载,进不了 CI;
  该链路是 provider 无关的(AdaptProvider 之后内核只认 MultimodalEmbedder)。

- TestHierarchicalIndexEndToEnd:多层分类(tech/go/两段、tech/rust/两段)
  的 Category 推导、树导出结构与挂载点、三级前缀过滤检索、范围外排除、
  索引落盘、重启后不漂移、树在重启后仍可用。
  反向验证:把 inScope 改成恒真后该测试稳定变红(报出范围外条目混入),
  确认它真能抓到「分层不参与召回」这一退化。

三、额外实测(本机,非 CI)
带 onnxruntime tag(生产构建形态)下用真实 Qwen3-VL 模型跑通全链路:
  provider dim=2048 modalities=[text image] fp=e43381246264...
  photo.Dense = 文本⊕图片融合结果
  以图搜知识 top1=photo score=0.757   ← 真正的跨模态召回
  重启后 ReindexDense built=0(命中缓存)
另确认默认构建(无 tag)下 qwen3vl 是 stub、Open 明确报错,不会静默降级成
"看似可用"。Makefile 的 HOMED_TAGS 默认即 onnxruntime,故发行版默认启用。
2026-09-26 14:20:19 +08:00
81cd8231d7 feat(kb-migrate): 存量知识库目录名迁移工具 + 启动期只报告
背景:旧版 Add 整串 sanitize 名字、逐段 sanitize 建目录,留下 tech/_go_/note、
Tech/Upper、a/b with space 这类「知识名与盘上目录不一致」的目录。修复后
normalizeName 要求二者逐字一致,故需一次性改名。

- 迁移逻辑放在 internal/knowledge/migrate_names.go(PlanMigration/
  ApplyMigration),CLI 与 homed 启动**共用同一份实现**,避免口径漂移。
- 三条硬约束:
  1. 默认只报告(-apply 才真改名)—— 批量 os.Rename 不可逆。
  2. 检出目标名冲突(两条迁到同一目标 / 目标已存在)则**整批拒绝**,
     不做部分迁移:半迁移状态比不迁移更难收拾。
  3. 逐条失败不中断,最后统一报告;执行前重查冲突(计划生成与执行之间
     可能有人改过盘上状态),并校验目标不越出知识根。
- homed 启动在 initKnowledgeStore **之前**调 initKnowledgeMigration:改名后
  扫盘一次到位,避免先以旧名建索引再改名造成内存键与盘上目录短暂不一致。
  defaultApply=false ⇒ 启动只扫描+报告+打印可执行命令行,不替人决定。
  单次改名上限 200 条,防失控目录规模拖住启动。

实测:报告模式零改动;冲突场景整批拒绝且盘上原封不动;迁移后 Store
正确载入 4 条并可按规范名逐条删除。
2026-09-26 14:20:19 +08:00
8842d76aff fix(webui): 知识库不再把二进制当文本存 + 接上分类/媒体/删除 + 实时计数
后端(handler_memory.go 重写 handleKnowledge):
- ★ multipart 分支原来无条件 file.Read → string(buf[:n]) → 当 Markdown 存进
  content.md:传一张 PNG 得到的是一份乱码文本知识,还在 .index.json 占一份
  preview,且**没有任何迹象**表明出了问题。
  现在按 http.DetectContentType 探测的**真实类型**分流(不信客户端声明的
  Content-Type——谎报 text/plain 的 PNG 在测试里是真实场景):
  媒体入 CAS 按 digest 挂条目 / 文本校验 UTF-8 后存正文 / 都不是则 400 明确
  拒绝并回传 rejected 清单。
- 状态码语义修正:此前 POST/GET 一律 500、DELETE 一律 404,把「名称非法」
  这类调用方能自己纠正的错报成服务器故障。现按 errors.Is 分流
  400/404/503。
- 搜索支持 category 与 limit;返回 knowledgeView(不泄露服务端绝对路径,
  不回传几百 KB 的 Dense 浮点数组)。
- 列表端点补 dense 状态(前端据此提示多模态是否就绪)。
- 媒体存储未接线时上传图片返回 503,而非退化成把二进制当文本存。

前端(dashboard.js):
- 搜索结果从 <pre>{JSON}</pre> 改为结构化渲染(名称/体积/预览/媒体标记
  + 每条删除按钮)。此前前端根本没有删除入口。
- 新增分类输入框(走 category 参数)、多文件上传。
- 计数改实时:原先读 state.kernel 快照,知识条目经工具/上传增删后不会变
  (实测创建完仍显示 "-")。切到知识面板时拉 /knowledge 的真实 names.length。
- 顶部输入框变多文件;显示多模态就绪状态(ready/total)。
2026-09-26 14:20:19 +08:00
144564f5c2 feat(knowledge): 分类过滤与多模态打通到工具/插件边界
- internal/sdk:KnowledgeAPI 增加 SearchIn/AddWithMedia/AttachMedia/
  ReindexDense/DenseStats;新增 MediaAPI(Put/Stat/Get)与 PluginSDK.Media(),
  registry 装配。**公开 SDK 契约一字未动** —— third_party/homeagent-sdk/sdk/
  的 diff 恒为 0(发布纪律的硬约束),走 internal/sdk 这条明确不受冻结约束
  的内部扩展路径。
- proc:新增 knowledge.addWithMedia(正文与媒体清单都走共享内存,与
  doc.insertWithMedia 同形);knowledge.search 支持 category。
- corehandler 用**局部接口 + 类型断言**取扩展能力,而非直接引 internal/sdk:
  后者已依赖 internal/plugin 的类型,直接引会成环(CoreSDK 注释已警示)。
  断言失败明确报"能力不可用",不静默退化成"媒体已写入"。
- agent 工具面:knowledge_search 增加 category;knowledge_create 增加
  media_digests(复用 doc_commit 的 digest 前缀解析 + Stat 回读 MIME)。
  顺带修 knowledge_search 的分类前缀重复(Name 已含分类,旧代码又拼一次,
  实测输出 tech/go/tech/go/并发)。
- agent 启动接线多模态空间,顺序为先接线再 ReindexDense(否则首次启动
  算出的向量因 MediaStore 未就绪而不落盘)。
2026-09-26 14:20:19 +08:00
9f2ec31cb0 fix(knowledge): 名称规范化/路径安全 + IDF 增量维护 + 多模态稠密路 + 派生数据落盘
一次知识库子系统的集中加固,四类缺陷各有实测复现:

1. 名称与路径(数据安全,最严重)
   - sanitize 不过滤 .. ⇒ Remove("..") 直接 RemoveAll 掉整个数据目录
     (实测把 <data> 整棵删掉,含 memory/documents/media),且返回 nil,
     工具层回报"已删除";Add("../../x") 写到知识根外,重启扫不回来
     ⇒ 幽灵条目。
   - Add 整串 sanitize 而建目录逐段 sanitize,内存键与盘上目录从**第一次
     落盘起**就不一致;重启后 name 漂移,knowledge_delete 静默删不掉
     (RemoveAll 删空目录返 nil)。同一个根因。
   - 修法:新增 normalizeName 作为唯一入口(逐段 + 拒绝空段/点段/隐藏段);
     Remove 改为取条目自记的 Path(不再用名字重拼)+ 返回 ErrNotFound。
   - resolve 三层退让(原样 → 规范名 → 叶名大小写不敏感,唯一命中才接受):
     scanDir 按盘上目录原样建键,遗留大写目录若只查规范名会变成
     "List 看得到、Remove 报不存在"。删的路径仍取自 Path,退让无风险。

2. IDF 与索引不同步(功能缺陷,非优化)
   - TFIDF Vectorize 跳过 df<=0 的特征,而 Add 只往只增不减的 summaries
     追文本、从不更新 DF ⇒ 库满(≥3篇) + 新词时,新知识**当场搜不到**,
     重启才恢复(实测 Search("量子纠缠") == [])。
   - 修法:vector.Store 新增 AddDoc/RemoveDoc(文档级去重口径与 Train 一致,
     totalDocs 下界守卫,零频 DF 删除防表膨胀);knowledge 删掉 summaries,
     改 index/unindex/retrain 三件套,覆盖写先 RemoveDoc 旧文本。

3. 多模态稠密路(此前知识库端到端纯文本)
   - 新增 SetDenseSpace/SetMediaGetter/ReindexDense/DenseStats 与
     AddWithMedia/AttachMedia,媒体成为一等节点参与跨模态召回。
   - 维度与指纹双守卫:维度不符的向量会被 FuseVectors 按最大维度拼成错维度
     结果且被当成"已对齐"永久错下去(docStore 踩过);模态不支持(音频)时
     静默跳过该媒体、退化为纯文本向量,绝不拿别的模型的向量顶替。
   - 未注入多模态空间时行为与此前逐字一致(退化为 0.5/0.5 两路融合)。

4. 派生数据落盘 + 分层参与召回
   - 媒体引用是**作者数据**(丢失即丢信息)→ 条目目录内 .media.json;
     稠密向量是**派生数据**(可重算)→ 全局 .dense.json,tmp+rename 原子。
     混存会让派生数据损坏连带作者数据一起丢。
   - 新增 SearchIn(query, category, topK):分类前缀匹配子树,让分层真正
     参与召回(此前检索全库平铺,分层只是存储布局)。归一化取作用域内
     最大值,否则范围外的强命中会把域内分数压没。
   - 删除 SearchTree/SearchCategories 死代码(零调用方,且停留在 Search
     修复前的单路口径:无词法融合、0.05 阈值)。

顺带修掉 Add 的 O(N)/写:buildTreeLocked 逐条重算向量(s.vec 里已有)
改为一次建表复用;.index.json 改为标脏 + Flush/Stop 收口。实测单条 Add
2.1ms@50 → 13.7ms@400 压平到 ~400µs(34×)。

存量目录改名迁移落在 migrate_names.go,只报告不改名(os.Rename 不可逆),
冲突整批拒绝以免半迁移。
2026-09-26 14:20:18 +08:00
6c33bfdb82 docs(sdk): 修正 ProxyReg 字段注释里的旧名(DeclareProxy→RegisterProxy)
Rename 时漏改了字段注释。代码本身一致(proxyReg 字段 + RegisterProxy 方法),
但注释里写着一个不存在的 API 名,读者按注释找不到方法。
2026-09-26 13:49:59 +08:00
a7fbdb3110 fix(webui): 旧反代两条路径合并修复 —— 302变502/泄露内网URL/流式被缓冲
新反代(proxy.go)早已修掉这些,但**两条旧路径**没跟上,各自复制了一份
http.DefaultClient 实现:

  proxyToPluginmgr        (handler_settings.go)
  handleDeviceGatewayProxy(handler_device.go)

同一个 bug 修了两遍还漏了两处。抽成共用的 reverseToUpstream,不再分叉。

## Bug 1:跟随上游 3xx → 302 变 502 + 泄露内网 URL

http.DefaultClient 默认跟最多 10 跳。上游回 302 时反代跟过去,目标可能是
内网另一个服务或不可达,于是把「上游的 302」变成「本层的 502」,
错误里还带着内网地址:

  {"error":"device gateway unreachable: Get \"http://127.0.0.1:1/api/...\":
   dial tcp 127.0.0.1:1: connect: connection refused"}

外部用户看到 Bad Gateway + 他访问不了的内网地址:既无用又泄露拓扑。
→ 反代**不应有重定向策略**(那是客户端的事),原样透传 3xx。
→ 上游错误细节只写日志,对外统一「上游服务不可达」。

## Bug 2:不逐帧 flush,流式响应被缓冲到结束

原实现 io.Copy(w, resp.Body),ResponseWriter 自带缓冲 → 上游按帧下发的
SSE/长轮询内容全堆到上游结束才吐。裸 TCP 实测:上游每 80ms 一帧共 3 帧,
缓冲版本只产生 **1 次**读(集中在 161ms),客户端表现为「卡住不动然后
一次性全出来」。改用 flushCopy(4KB 块 + 块间 Flush)。

## Bug 3:不过滤逐跳头

Content-Length / Transfer-Encoding 描述的是**上游那条连接**的分帧方式,
照抄到本层连接会导致客户端按错误长度读;Keep-Alive/Connection 同理。
按 RFC 7230 §6.1 剔除。

## 附带修正

- 补 X-Forwarded-For / X-Real-IP / X-Forwarded-Host / X-Forwarded-Proto,
  且**只在尚未设置时补** —— 外层 nginx 已注入时覆盖会丢掉真实客户端 IP。
- 与 proxy.go 新建了带超时的 upstreamClient(DefaultClient 无超时,
  上游卡住会拖住 goroutine)。

## 判据(5 条)+ ★ 判据设计的两个坑

★ 这条判据我试错了三轮,过程留在测试注释里:

1. 「首帧早于末帧」→ **假绿**。Go 在响应结束后把缓冲一次吐出,首末帧仍有
   微秒级差,任何 `> 0` 都绿。
2. 用 http.Client 量「首帧延迟 < 上游总时长 70%」→ 仍是**假绿**。实测直连
   上游首帧 761ns、总时长 160ms:Go 的 HTTP **客户端**合并读,量到的
   「首帧」是客户端首次取到数据的时间,与服务端何时 flush 无关。
3. 当前(正确):**裸 TCP 直连被测服务**,看读到几次、分别在什么时刻。
   对照组实测 3 次读 / 0.24ms / 80ms / 161ms —— 正是上游节奏。
   第二个坑:不能按「累计 12 字节正文」判结束(首读含响应头 + 首帧正文,
   会在首读就以为读完,后两帧时序全丢)。改为读到 EOF。

变异验证 4 条(均按预期打红后还原):退回 DefaultClient → 跟随重定向判红;
错误信息带 err.Error() → 泄露判红;退回 io.Copy → 只读到 1 次判红;
不过滤逐跳头 → Keep-Alive 判红。

全量:35 包全绿。
2026-09-26 13:49:59 +08:00
3273c507b3 fix(webui): Server 读侧超时(防 Slowloris)+ 反向判据守住流式不被腰斩
http.Server 原本**一个超时都没设**(只有 Handler)。后果是 Slowloris:
攻击者只占连接不发完整请求头,每个连接挂几 KB。MaxHeaderBytes 限的是
头部**大小**,「慢慢发」不占大小、不受它约束,几百个连接就能耗尽 fd。

## 为什么不是「把超时都设上」

webui 有一条长连接 SSE(/api/v1/chat/events)与可跑 300s 的流式
/v1/chat/completions。WriteTimeout 是「从请求开始到响应写完」的**总预算**,
会把它们腰斩 —— 表现为 SSE 每隔一段时间断一次、前端疯狂重连。而这类
回归在功能测试里很难立刻发现。

所以只设读侧三项,各管一段:

  ReadHeaderTimeout 20s —— 请求头必须按时发完,Slowloris 的正解
  ReadTimeout       60s —— 读完整请求(含 body)的预算,防慢速上传
  IdleTimeout      120s —— keep-alive 空闲连接(另两项都管不到)
  WriteTimeout        0 —— **刻意不设**(见上)

## 判据(3 条,含一条反向判据)

- TestServerHasReadSideTimeouts:三个读侧超时都必须 > 0
- TestServerHasNoWriteTimeout:**反向**钉住 WriteTimeout 必须保持 0,
  防止将来有人「顺手补全超时」把 SSE 弄坏
- TestSSEConnectionSurvivesBeyondReadTimeout:SSE 连接确实活过读侧窗口

反向判据看着琐碎,但它守的正是「这次没做的那件事」——
不加 WriteTimeout 是个**决定**,不是疏漏,所以要用判据把决定固定下来。

变异验证:补上 WriteTimeout:30s → 反向判据判红;
去掉 ReadHeaderTimeout → 前向判据判红。

测试脚手架注意:newServerForTest 绑 127.0.0.1:0(内核分配空闲端口),
绝不用 :8080 —— 那是生产端口(见 a752ae1)。

全量:35 包全绿。
2026-09-26 13:49:59 +08:00
35df6f4366 fix(webui): 限流来源识别改为「只信任受信反代的 XFF」—— 修复把自己锁在门外
★ 这是在生产上亲手踩出来的:上一提交加了按 IP 限流后,我用 8 次错误登录
做验证,结果**把管理员自己锁在外面 10 分钟**。

## 现场证据

  [webui] POST /api/v1/login from=127.0.0.1 auth=none status=429

webui 经 frp/nginx 穿透到公网时,**所有外部请求的 RemoteAddr 都是
127.0.0.1**。于是所有人共用一个桶:任何人爆破 5 次,就把**所有人**
(含管理员)一起锁死。限流从防护变成了 DoS。

## 我第一版还犯了个方向的错

当时我刻意**不采信** X-Forwarded-For,理由是「该头可伪造,换个头就能
绕过限流」。这个理由本身对,但结论下反了:完全不采信,在穿透部署下
**必然退化成全局限流** —— 而全局限流正是我试图避免的那个后果。

## 正确做法:中间路线

**只信任受信反代发来的 XFF**。判定「是否来自受信反代」不能靠
内网/回环 IP 猜 —— 穿透部署下反代恰恰就在本机 127.0.0.1,与直连请求
完全同源,猜不出来。所以由部署方**显式声明**(新设置项
`webui.trusted_proxies`,逗号分隔 CIDR 或裸 IP)。

权衡写明:未声明时穿透明场景下限流退化为「全局」。这是**刻意的保守
默认** —— 宁可限流偏保守,也不能因为采信伪造头而形同虚设。

## 判据(+4)

- TestLoginRateLimitUsesForwardedForFromTrustedProxy:受信反代下按真实
  客户端 IP 隔离(否则就是全局锁)
- TestLoginRateLimitIgnoresUntrustedForwardedFor:换 XFF 头不得绕过限流
- TestLoginRateLimitNeedsExplicitTrustedProxyConfig:未配置 = 不采信
- TestParseTrustedProxies:合法项接受、非法项丢弃、空 = nil

全量:35 包全绿。

★ 附带教训(也记在判据注释里):**用失败注入做验证时要意识到副作用
范围**。我那次「跑 8 次错误密码看看会不会限流」本身是合理的验证动作,
但它作用在**生产实例**上,且限流的作用域(全局化)正好覆盖了自己。
在带状态的安全机制上做破坏性验证,判据应该先证明作用域是对的。
2026-09-26 13:49:59 +08:00
667b9fdc8a fix(webui): OpenAI 兼容面 —— 补 /v1/models + 真流式(原先是假流式)
/v1/* 是**给外部程序用的**(IDE、脚本、agent 框架),不是给人看的聊天页。
它的行为必须真符合 OpenAI 协议,否则调用方直接坏掉。下面两条都在
**生产实测**中确认过,不是推理。

## ① GET /v1/models → 404

几乎每个 OpenAI 客户端(curl 脚本、LangChain、OpenAI SDK、IDE 插件)
启动时都会先列模型来探测服务可用性。404 让它们直接判定「服务不可用」,
连试都不试 —— 这是集成方最容易踩空、也最难自查的缺口(表现为
「连不上」,而实际端点是通的)。

新增 handleOpenAIModels。返回什么模型**不重要**,结构合法才重要:
本端点不做模型选择(model 只是回显),所以只暴露 HomeAgent 自身。
不谎报 GPT 之类名字 —— 那会让用户以为能选模型,实际不能。

## ② stream=true 是假流式

实测:首字节 7.79s,随后**整段**内容在一个 chunk 里到达。

根因:两条路径都走 InjectTextSyncNoMemory —— **同步等完整回复**才返回,
之后才把已拼好的全文切成 3 个 chunk 吐出去。客户端的「生成中」/取消/
超时/进度条全部失效;300s 超时表现为「卡 5 分钟然后一次性出现」。

重写为真流式:先订阅 EventContentDelta / EventReasoningDelta **再**启动
注入(顺序反了会漏开头几个分片),边收边转成 chunk,最后用同步调用拿到的
完整回复补 usage、发 finish、[DONE]。沿用 handleSSE 的成熟结构
(批量 16ms 合并、独立 writer goroutine、done channel 而非 close)。

顺带处理内核的 reset 事件:流式失败回退非流式时内核会发
content="" + reset=true(见 internal/agent/core/process.go)。忽略它会让
客户端看到半截内容后又接上完整内容(重复且自相矛盾),故识别并丢弃累积。

## 判据(4 条,变异验证)

- TestOpenAIModelsEndpoint / RequiresAuth
- TestOpenAIStreamIsActuallyStreaming
- TestOpenAINonStreamUnchanged(别把非流式改坏)

★ **判据本身踩了两个坑,都已修正并记在测试注释里**:

1. `httptest.ResponseRecorder` 把整个响应**缓冲在内存里**,请求结束才交付
   —— 它**根本观察不到流式**。用它写的流式判据必然是假的。故改用
   `httptest.NewServer` + `bufio.Reader` 逐帧读。

2. 「要求首帧早于末帧」**抓不住**假流式:假流式确实是分多次 write 的,
   帧间间隔是微秒级 > 0,任何 `> 0` 判据都绿(已实测)。
   真正能区分的是:**首帧是否早于「内核产出最终答案」那一刻**。
   于是假内核被构造成:发 3 个增量后**扣住**最终响应,直到消费者
   表现出「已在读帧」才放行 —— 真流式首帧 0.35s,假流式首帧 3.30s。

3. 鉴权判据一度写错:未登录时门户 302 到 /login,若跟随重定向就会拿到
   登录页的 200,把「被重定向」误判成「鉴权通过」。改用不跟随重定向的
   客户端。

变异验证:去掉 /v1/models 路由 → 判红(还原 404);
不转发增量 → 判红(首帧 3.30s)。

全量:35 包全绿。
2026-09-26 13:49:59 +08:00
5ebc4481b0 fix(webui): 登录入口加固 —— 限流 + 常量时间比对 + 请求体限量 + 防用户名枚举
门户可经 frp 穿透到公网(https://homeagent.jianfgit.xyz/ 实测直达),
而 handleLogin 原先是**零防护**:无限流、无失败计数、口令用 == 明文比对、
失败不审计。等于把唯一��口令入口直接开到外网任人爆破。

## 改动

1. **按来源 IP 的失败计数限流**(login_limiter.go)
   - 5 次失败后拦,10 分钟窗口。
   - 退避而非永久封禁:窗口过期自动恢复。永久封禁意味着一旦误撞
     (或被撞库)就再也登不进,只能上机器改配置。
   - 成功即清零:手滑输错几次不该被永久记账。
   - **刻意不采信 X-Forwarded-For** —— 该头可伪造,直接采信等于让
     攻击者换一个头就能绕过限流,甚至把限流当成打别人来源的武器。
     代价(已在注释写明):若 webui 挂在反代后,限流会退化成「全局」,
     那种部署应在反代层限流或用 PROXY protocol 传真实来源。
   - **刻意不做账号级锁定**:本系统只有一个管理员账号,账号级锁定
     相比 IP 级无额外收益,却多一个误伤面。
   - 过期记录会被 prune —— 否则攻击者轮换 IP 就能喂成内存泄漏。

2. **常量时间比对**(crypto/subtle):`==` 会在第一个不同字节处短路,
   泄漏「猜对了几位」的时序信息。

3. **请求体限量**:ContentLength 前置拒绝 + MaxBytesReader 兜底。
   ★ 后者**不能只靠解码器报错** —— json.Decoder 按需读流,遇到
   「超大 + 非法 JSON」会在第 0 字节就报语法错误、永远读不到上限,
   于是 8MB 数据已进缓冲而 MaxBytesError 从未出现。只挂 MaxBytesReader
   的写法对最省力的攻击载荷反而无效(实测确认)。

4. **防用户名枚举**:用户不存在与口令错误给完全相同的状态码与报文。

## 判据(8 条)

限流触发 / 按来源隔离(否则一个 IP 就能把所有人锁死,限流即 DoS)/
成功清零 / Retry-After / 请求体限量 / 防枚举 / 过期清理 / 重试时长非零。

变异验证(3 条打红后还原):
- 去掉限流调用 → 3 条判红
- 去掉 ContentLength 前置检查 → 判红(回到 400)
- 去掉 Reset → **起初没打红**:原判据「跑 30 次看是否限流」在阈值只有 5
  时无论有没有 Reset 都会限流,是条**假判据**。已改为**测出实际阈值**
  (清零后应重新拿到完整额度),再去变异即打红。

诚实说明:常量时间比对那条**无法用单测可靠断言**(时序属性,噪声远大于
信号)。它由代码评审保证,不由测试保证 —— 写明以免后人以为有测试兜着。
2026-09-26 13:49:59 +08:00
6d0c1188f6 fix(webui): 服务入口「打开」改用路径形态 + 别名模式不补尾斜杠
验收时发现的**用户可见缺口**:API 早就同时返回 url(子域)与 url_portal
(路径),但「服务入口」卡片只用了 url —— 而子域形态在穿透部署下
**恰恰是打不开的那个**(外层只放行一个 Host、三级子域通配证书不匹配)。
用户点「打开」得到坏链接,还会以为是插件的问题。

## 改动

1. 卡片「打开」优先 url_portal(路径形态):
   无 DNS 依赖,单端口穿透 / 子域无证书时都能用。
   子域链接保留为次选按钮(局域网内直连时更直观)。
   文案补一句说明两者差别(子域需 DNS 能解析 `*.<基域名>`)。

2. **别名模式不再补尾斜杠**(顺带发现的 bug):
   原实现给所有 url_portal 无条件加 `/`。前缀模式下对(那是规范形态,
   前端靠它算相对路径基准);别名模式下错 —— 那里的 path 是上游真实
   路径语义(/api/v1/device 是 /api/v1/device/xxx 的前缀),补成
   /api/v1/device/ 会让人误以为存在一个可访问的根。

## 判据

+2 条:TestProxyServicesOffersBothForms(两种形态都必须给出,
且前缀模式的 url_portal 必须带尾斜杠)、
TestProxyServicesAliasKeepsExactPath(别名模式不得带尾斜杠)。

变异验证(2 条,均按预期打红后还原回绿):
- 别名模式也加尾斜杠 → 判红
- 前缀模式不加尾斜杠 → 判红

另修正一条旧判据的期望值:它当年断言的是「所有 url_portal 都带尾斜杠」
(即把 bug 当成契约钉住了)。那条路由正是设备网关(别名模式),
现在改为断言不补尾斜杠,并注明理由。

全量:35 包全绿。
2026-09-26 13:49:59 +08:00
125bf57cfa fix(test): 测试不再抢生产端口 :8080(internal/plugins 加载内置 webui 所致)
部署过程中反复出现「8080 被 plugins.test 占用」导致生产 WebUI 起不来。
追到底:internal/plugins 的集成测试会 pluginReg.Load(全部内置插件),
其中 webui 默认监听 :8080 —— **正是生产实例的端口**。

## 为什么这个 bug 特别难查

它不是测试失败,而是**测试与生产静默抢端口**:先到者胜,另一个 bind 失败。

  - 跑测试的人看到「测试随机失败」(其实是生产先占了)
  - 用生产的人看到「WebUI 随机死掉」(其实是测试先占了)
  - 两边现象互不相干,且各自单独重跑往往都过

叠加 webui 已有的「bind 失败必须显式报错」修复后,症状从「静默死亡」
变成「随机报错」,这反而让归属更容易看错 —— 我一开始也是先怀疑自己的
部署脚本,直到采样 /proc/<pid>/cwd 才确认是测试进程。

## 修法

集成测试在 Load 之前用既有的 SetListenOverride 把地址指到
127.0.0.1:0(内核分配空闲端口),并在 cleanup 还原。
测试因此拿到真实可用的 HTTP 服务,且与任何固定端口实例完全隔离。

- webui 新增 ListenOverride() 读取当前值,供调用方保存/还原
  (只有 setter 时无法在不破坏调用方状态的前提下做临时覆盖)。

## 验证

- 修复前:跑 ./internal/plugins/ 期间 8080 持续归 plugins.test(109/200 采样)
- 修复后:35 次采样全程 8080 归 homed,测试同时全绿
- 变异验证:移除 override 后立刻复现抢端口,判据有效

另记两个测试卫生问题(同一根源,已顺手清理泄漏进程):
测试会启动**真实插件进程**(/home/newqqagent/plugins/*/plugin.bin)。
kill 测试进程后这些子进程会残留。已全部清理,生产 23 插件恢复正常。
2026-09-26 13:49:59 +08:00
2c810bbbce feat(webui): 路径挂载的 strip_path 两态 + 尾斜杠重定向(修 /p/huawei 打不开数据)
用户要求用方案 A(路径挂载)让 huawei 插件 UI 在外部可用,
并把「通过反代的插件必须使用单一入口」写入 SDK 声明。

## 实测暴露的两个真问题

1. **Path 的语义不能一刀切**。原设计「原样保留」只对**机器接口**成立
   (设备客户端硬编码 /api/v1/device/ws,不可能知道反代的存在);
   而自带 UI 的服务需要**剥掉前缀**(/p/huawei/api/status → 上游 /api/status)。
   猜错的结果是全部请求 404,且看起来像上游故障 —— 所以由声明者选:
   strip_path=false 别名模式 / true 前缀模式。非法组合被 validate 挡住。

2. **前缀模式的尾斜杠是必需的**(自测发现的 bug)。
   访问 /p/huawei(无尾斜杠)时页面能开,但页面里所有 fetch 都 404 ——
   相对路径以「当前文档目录」为基准,没尾斜杠时浏览器把最后一段当文件名,
   目录退回上一级,fetch('api/status') 打到 /p/api/status。
   修:前缀模式且路径恰等于前缀时 301 到 /p/huawei/(保留查询串)。
   **别名模式不做此事** —— 那类路径是上游真实语义,加斜杠会改坏它。

## 插件侧(huawei_smarthome)

- 前端 4 处根绝对路径(fetch('/api/status') 等)改为相对路径,
  基准由 location.pathname 推导(BASE)。这是 Path 形态能成立的**前提** ——
  否则请求会打到门户自己身上。
- plg.json 声明:host + path=/p/huawei + strip_path=true + auth=homeagent。
- SDK 升到 1.4.0,并用 hmapdev 1.4.0 重新打包(1.3.0 的 hmapdev 无
  proxies 支持,会把声明**静默丢弃** —— 实测确认过,这是打包链路上
  一个不报警的坑,值得记住)。

## 判据

+6 条:TestProxyPathAliasVsStrip(两态各自正确)、
TestProxyPathLongestPrefixWins(/p/app 不得劫持 /p/apple,
且长前缀胜出)、TestProxyStripPathRedirectsToTrailingSlash(尾斜杠,
含查询串保留 + 别名模式不得重定向)。

变异验证(4 条,均按预期打红后还原回绿):
- 删尾斜杠重定向 → 判红(还原了真实 bug 形态)
- 让别名模式也重定向 → 判红(设备网关语义被毁)
- 从 hmapdev schema 探测体删 StripPath → 判红(漂移检测有效)
- 删 SDK 里的「单一入口原则」字样 → 判红(契约不能只剩口头约定)

全量:35 包全绿。
2026-09-26 13:49:59 +08:00
5da0f8f9fb feat(webui): 外部入口 base_url 配置 —— 穿透场景下链接不再靠猜
用户指出 webui 实际是经 https://homeagent.jianfgit.xyz/ 穿透出去的,
应当支持配置 base URL。实测确认了这个诉求的正当性。

## 实测发现的约束(决定方案)

1. **子域形态在外部不可用**:`*.homeagent.jianfgit.xyz` 泛解析存在,
   但外层只给 `*.jianfgit.xyz` 通配证书 —— 该证书**不匹配三级子域**,
   实测 `huawei-smarthome.homeagent.jianfgit.xyz` 外部握手失败(HTTP 000)。
   外层只放行 `homeagent.jianfgit.xyz` 这一个 Host。
2. **路径挂载形态外部可用**:实测
   `https://homeagent.jianfgit.xyz/api/v1/device/online` → 200。
   所以「一个外部 Host + 路径挂载」是这条链路的正解,且已经工作。
3. 外层 nginx/WAF 会带 `X-Forwarded-Proto: https` 与 `X-Forwarded-Host`,
   因此即使不配置也能推出正确链接;配 base_url 则是显式兜底。

## 新增设置项 base_url

三级优先解析「对外入口」(resolveEntry):

  1. **配置项 base_url** —— 外部入口是部署事实,不该靠请求猜。
     经多层网关时请求可能带内网 Host,按它推导会拼出用户点不开的链接。
  2. **X-Forwarded-Proto / X-Forwarded-Host** —— 反代层给权威信息时可靠。
  3. **请求自身** —— 直连时的正确来源。

base_url 的主机名同时用作**子域反代的基域名**:入口是 homeagent.example.com
时,插件服务自然是 <标签>.homeagent.example.com。

服务清单另增 entry_url 字段,直接给出「外部入口是什么」,便于前端与排错。

## 生效点

- `/api/v1/proxy/services`:url / url_portal / base_domain / entry_url
- `/api/v1/device/gateway`:url / url_portal / http_url / host
- 两处原先各自推导 portalHost,现统一走 resolveEntry,避免再次漂移

## 部署后实测(生产,经真实外部入口)

  entry_url:   https://homeagent.jianfgit.xyz
  base_domain: homeagent.jianfgit.xyz
  remotedevice    | https://devices.homeagent.jianfgit.xyz
                  | https://homeagent.jianfgit.xyz/api/v1/device/   ← 外部可点
  huawei_smarthome| https://huawei-smarthome.homeagent.jianfgit.xyz

发现端点(外部视角):
  url_portal = wss://homeagent.jianfgit.xyz/api/v1/device/ws   ← 外部可连

## 判据

+3 条:TestBaseURLOverridesRequestDerived(内网 Host 场景下必须用 base_url)、
TestEntryPrefersForwardedHeaders(XFF 优先于请求自身)、
TestBaseURLTolerant(尾斜杠/空格容错 —— 手填配置最常见的两种手误)。

另更新一条旧判据的期望值:外部入口是 portal.example.com 时,子域基名应取
**实际入口**而非本机配置的 localhost(后者对远程用户无意义)。
2026-09-26 13:49:59 +08:00
a96ad9ca97 fix(webui): 服务入口 URL 端口必须恰好出现一次(生产部署后暴露)
生产部署后立刻暴露的真 bug:请求 Host 自带端口(实测 Host=127.0.0.1:8080),
而 url_portal 合成时无条件再追加监听端口,拼出
  http://127.0.0.1:8080:8080/api/v1/device/     ← 链接点不开

单测抓不到的原因:此前测试用的 Host 不含端口。真实服务器上 Host 一定带端口
(除非经 nginx 剥掉),所以这个 bug 必然出现在生产。

修法:抽出 portalHostWithPort(host, hostPort) 统一合成 ——
  - host 已含端口 → 原样(尊重调用方看到的真实入口)
  - host 不含端口 → 追加监听端口
两处调用点(服务清单 url_portal、发现端点 url_portal/url/http_url)共用它。

新增 3 条判据,都刻意用**自带端口**的 Host:
  TestPortalHostPortExactlyOnce(7 组输入,含带/不带端口、空值、无冒号端口)
  TestProxyServiceURLsWithPortInHost
  TestDeviceGatewayDiscoveryNoDuplicatePort
2026-09-26 13:49:59 +08:00
a781f8e1ba fix(gui): 设备桥 bind 结果判 ok + 暴露登记状态,与鸿蒙端对齐
GUI 主进程与 Go 客户端同病: 只打日志、不看 ok。
服务端 bind 被拒时回 {"ok":false,"error":"bind rejected"} 并关闭连接,
GUI 既不报错也不重连 ⇒ 设备静默失联(TCP/WS 通但从未登记进网关)。

另:成功时服务端不含 device 字段,原日志用 `msg.device || deviceBridgeId`
兜底才显得像成功,掩盖了「从未真的读 ok」。

鸿蒙端 DeviceBridge.ets:209 本来就是正确实现(检查 ok、区分 connected
与 bound),本次把 GUI 与 Go 客户端对齐到同一语义:
新增 deviceBridgeBound / deviceBridgeBindError,bind 被拒打 error 级日志
并说明常见原因(令牌不匹配 / 设备未授权)。
2026-09-26 13:49:59 +08:00
94c74b2ee6 fix(devicebridge): 修复设备反复掉线/静默失联 —— ping 路径断连 + bind 结果无人处理
用户要求全面修复「设备桥自动链接」这条链路上的问题。三个真实缺陷,
前两个是**服务端/客户端真 bug**(生产日志实证),第三个是我起初误判的。

## 缺陷 1(最严重):未 bind 时收到 ping → 服务端直接关连接

原实现:
    err := r.wsWriteLocked(curID, writePong)
    if err != nil { return }   // ← 关连接

而 conns 表**只在 bind 成功后才写入**(bind 前刻意不暴露连接给查询/命令
路径)。于是「握手完成、bind 尚未到达」这个窗口里来的 ping 找不到写入口,
函数返回错误,读循环 return —— 把连接关掉了。

生产后果(journalctl 实证):客户端每 30s ping 一次,只要有一次落在未 bind
窗口就断连。日志里同一设备 20 秒内多次 "ws connected",online/offline 与
输出通道注销/注册反复交替:

  17:29:14 ws connected → 17:29:17 ws connected → 17:29:24 ws connected
  → 17:29:29 → 17:29:35 → 17:29:40 online → 17:30:18 offline → ...循环

修法:pong 直接写本连接的 writer。此时该连接尚未进入 conns(没有 Push* 会
碰它的 writer),不存在并发写风险;已 bind 时才取写锁(Push* 可能正在写
同一 buffer)。

判据 TestPingBeforeBindDoesNotDropConnection 直打 bug 点(只握手、不发
hello/bind、发 ping、要求 pong),修复前报 `EOF`,修复后通过。

## 缺陷 2:bind_ack 的 ok 完全没被检查 → 失败静默失联

原实现(客户端):
    case "hello_ack", "bind_ack":
        log.Printf("... device=%v", msg["device"])

两处错:
- **取错字段**:服务端成功时回 {"op":"bind_ack","ok":true},没有 device
  字段,于是日志永远显示 `bind_ack device=<nil>`。这让我起初误判成"绑定
  失败",实际连接是好的(直连与经反代现象完全一致)。
- **不看 ok**:bind 被拒时服务端回 ok:false + error 并关闭连接,客户端既不
  报错也不重连,设备静默失联 —— TCP/WS 通但从未登记进网关。

修法:分别处理两种 ack;bind 判 ok,失败记原因并通知宿主。新增
Bridge.Bound() / BindError() / OnBoundState():**连接成功 ≠ 设备可用**,
只看连接状态的健康检查会给出假阳性。

判据 TestBindFailureIsObservable / TestBindStateCallback。

## 缺陷 3:-chat 一次性模式下桥存活时间过短

不是我最初以为的"bind 失败"。真因:`-chat` 走进 oneshot 后立刻 return,
触发 defer stopDeviceBridge(),桥只活几百毫秒,设备来不及完成 hello→bind。

修法:退出前等 bind 确认(最多 3s);bind 明确被拒则打印原因,不静默丢弃。

## 真实验收(隔离实例,命名 netns + 独立 data + 18080)

真 waiter 经**反代自动发现**连接,保持连接期间查询服务端:

  device gateway discovered: ws://127.0.0.1:18080/api/v1/device/ws
  bind 成功,设备已登记
  /api/v1/device/online → waiter-mainserver, online=true, caps=[11 项]

长连接稳定性:70 秒(跨 2 个 ping 周期)三次采样设备始终在线,
无 read loop exit / bind rejected 日志。

## 附:反代通路本身的判定性对照

裸客户端(直接构造 hello/bind 帧)**经反代**与**直连 9890** 返回逐字节
一致(bind_ack ok=true、设备注册、online=true)。所以这条链路上反代
不背锅,问题全在 remotedevice 服务端与客户端自身。
2026-09-26 13:49:59 +08:00
7f5bf1670f feat(clients): 设备桥自动链接改用服务端发现 + 路径挂载(无 DNS 依赖)
配套 webui 反代改造:网关现在可由 HomeAgent 反代出去,客户端不能再靠
「门户地址同 host 拼 /api/v1/device/ws」猜地址——基域名与子域标签都是
**服务端配置**,客户端无从得知。

## 服务端:/api/v1/device/gateway 发现端点

客户端问「网关在哪」是唯一不会漂移的做法:子域标签可改(插件声明)、
基域名可改(webui.base_domain)、实例可换形态,客户端都不用跟着改。

⚠️ **不返回设备令牌**:本端点用门户凭证鉴权,而设备令牌能执行设备命令;
把令牌塞进来等于「门户只读凭证 → 设备执行权」的越权。令牌仍由客户端
自配。已有判据钉住「不得泄漏凭证字段」。

## ★ 实测发现:*.localhost 只有浏览器能解析

这是本轮最重要的发现,直接决定了设计:

| 环境 | devices.localhost 解析 |
|---|---|
| 浏览器 | ✓(RFC 6761 内置) |
| curl | ✓(内置特例) |
| getent / Go / Node | ✗(系统 nsswitch 是 files,dns,无 nss-myhostname) |

设备客户端(waiter / GUI 主进程 / 嵌入式固件)用的正是系统解析器。
实测 waiter 报「lookup devices.localhost on 192.168.2.1:53」。

因此**两处**设计变更:
1. 发现端点同时返回两种形态,并标 preferred:
   - url(子域)—— 浏览器用
   - url_portal(门户同源,同一 host、同一端口,走路径挂载)—— 非浏览器用,
     无任何 DNS 依赖
2. SDK 的 ProxyDecl 新增 **Path**(路径挂载前缀):让同一服务同时挂到
   门户自身 host 的路径下。remotedevice 声明 Path="/api/v1/device",
   设备客户端因此能沿用**它已硬编码的路径**,不需要知道反代存在。

路径挂载语义:请求路径**原样保留**(不剥前缀),上游按真实路径注册即可。
边界卡在路径分隔符上(/api/v1/device 不匹配 /api/v1/devicefoo)。

## 客户端

- **waiter**:新增 discoverGateway(),仅在用户配了门户地址时尝试,失败回退
  自配地址(老版本 HomeAgent 无该端点)。抽出 normalizeGateway() 纯函数,
  显式钉住「已带子域/完整端点的地址不得被改写」。
- **GUI**:renderer 新增 loadDiscoveredGateway(),renderDeviceChannel 优先用
  发现值、回退旧口径。顺带修掉此前插入函数时 anchor 不匹配导致调用点
  找不到定义的问题。
- **鸿蒙**:discoverGateway() + resolveGatewayUrl(),优先 url_portal。
- 三者都**优先 url_portal**(system resolver 的现实约束)。

## 遗留路由鉴权修正

`/api/v1/device/` 的旧路径反代原被 requireAPI 包裹 —— 但其调用方是设备
(带设备令牌而非门户凭证),套上门户鉴权会把它们全挡在 401(**真实实测**:
waiter 经此路径升级握手 401)。去掉这层包装,鉴权交给上游 remotedevice
自己的 requireToken,安全性不降级。

## 判据

webui +6 条、waiter +7 条。

★ 其中一条是**真实回归**:/api/v1/device/gateway 曾被 Path="/api/v1/device"
的路径挂载接走(那服务 auth=none),于是发现请求被转给上游、回 401,
客户端再也发现不到网关。修法是发现端点先于路径挂载判定,并补判据
(走完整生产链,同时确认同前缀的真实设备路径仍归反代)。

## 真实验收(隔离实例,命名 netns + 独立 data + 18080)

真 waiter 客户端 + 真 remotedevice 网关:
  device gateway discovered: ws://127.0.0.1:18080/api/v1/device/ws
  device bridge active: waiter-mainserver authorized=true
  hello_ack / bind_ack 均经反代往返成功

说明:`bind_ack device=<nil>` 与在线列表为空的现象,**直连 9890 绕开反代
完全一致复现**,属 remotedevice 与 waiter 之间既有的握手细节,与本次
反代改造无关(反代侧职责已证:连接建立 + 双向帧往返都通)。
2026-09-26 13:49:59 +08:00
5d278cffdb fix(webui): 反代两处真实故障 —— 凭证头按 auth 区分 + Host 分发先于门户路由
两处都是**隔离实例上跑真实端到端**才暴露的,单测(用不校验凭证的假上游、
直接调 serveProxyHost)全绿却线上出错。记录在此以免重蹈。

## 故障 1:auth=none 路由的凭证被无条件剥掉 ⇒ 设备链路全 401

Rewrite 里原本无条件 Del("Cookie"/"Authorization"/"X-API-Key")。但
auth=none 的语义是"请求原样交给上游",凭证本来就是给**上游**的——
remotedevice 的接入令牌正是走 X-API-Key 传的。

实测症状:带设备令牌经反代访问 /api/v1/device/online → 401;
直连 127.0.0.1:9890 → 200。差异极难定位,因为两侧状态码语义相同。

修法:按路由 auth 分流。
- auth=homeagent:凭证是门户的,剥掉(避免泄漏给插件)
- auth=none:保留(上游要用)

复验:经反代与直连**逐字节一致**(HTTP 200 / 17B,cmp 相同)。

## 故障 2:插件子域被门户路由截走 ⇒ 401 且响应体是门户的 JSON

原实现把 Host 分发放在 mux 的 "/" 兜底里。但 stdlib ServeMux 是**最长前缀
优先**:任何更具体的模式都先命中。插件子域上的 /api/v1/device/online 被门户
为「旧路径反代」注册的 /api/v1/device/ 接走(requireAPI 包裹)→ 401。

判据(响应体格式)是定位关键:
  webui requireAPI        → {"error":"unauthorized"} 25B  ← 实际拿到
  remotedevice requireToken → "unauthorized" text/plain 13B
看响应体格式就能区分是谁拒的,比看状态码有效。

修法:Host 分发提为**最外层中间件**,包在整个 mux 之外,先于任何路径匹配。

## 顺带:消除判据与生产接线错位的可能

新增 Handler.Handler() 返回生产用的完整链(Host 分发 → 日志 → mux),
plugin.go 与测试共用同一条。本次踩过:测试自己组装 mux、中间件却挂在
plugin.go,判据全绿而线上 401;共享同一条链可结构性避免。
(写这条判据时还发现测试里 h.mux 为 nil 导致 panic——也正是这种错位的表现。)

## 新增判据 2 条

- TestProxyCredentialHeadersDependOnAuth:auth=none 必须转发上游令牌、
  auth=homeagent 必须剥掉门户凭证(两个方向都钉)
- TestProxyHostTakesPrecedenceOverPortalRoutes:走**完整生产链**,确认
  插件子域上的 /api/v1/device/online、/api/v1/status、/api/v1/plugins/ 都
  归反代;同时确认门户自身的 /api/v1/status 仍返回门户 JSON(没被反代吞掉)

## 真实验收(隔离实例:命名 netns + 独立 data + 端口 18080)

- 设备网关:令牌经反代 200,与直连逐字节一致;WS 升级 101
- 未声明子域:404 且错误信息含具体标签
- huawei_smarthome(用新 hmapdev 重打包、真装载):
  匿名 401 + 可操作提示;带门户 key 拿到真实 UI(9444B,
  <title>华为智慧生活管家);页面内根绝对路径 /api/status 正确透传
2026-09-26 13:49:59 +08:00
1e58af79d3 feat(webui): 通用反向代理 —— 插件声明服务,HomeAgent 按子域反代出去
用户要求:外部只装 HomeAgent 即可使用自带反代能力;用户只需穿透一个
webui 端口就能访问所有内部插件服务;认证与 WebSocket 支持都作为插件
的可声明项;插件 UI 要有可直接点击的入口。

实测 huawei_smarthome 插件的前端用**根绝对路径**(api('/api/status') →
fetch('/api/status'))。挂在 /p/<name>/ 这类路径前缀下,这些请求会打到
HomeAgent 自己的 /api/status —— 静默错路由;做 HTML/JS 内容重写对拼进
JS 字符串的绝对路径只是"按概率能用",会产生"页面能开、某个按钮就坏"的
静默故障。子域路由下根路径天然正确,**插件前端零改动**。

且它天然匹配"只穿透一个端口":webui 监听 0.0.0.0:8080 按 Host 分发,
外层 frp 单端口 TCP 隧道**一行都不用改**。

默认基座 localhost:RFC 6761 规定 *.localhost 强制解析到 loopback,
现代浏览器原生支持 ⇒ <标签>.localhost:8080 **零配置可用**,不需要 DNS、
证书、/etc/hosts。远程部署改 base_domain 即可。

- 外部插件 → plugin.json 的 proxies(静态可发现:插件没起来也能报
  "声明了 ui 但目标不可达",而不是静默 404)
- 内置插件 → s.DeclareProxy()(remotedevice 是内置的、没有 plugin.json,
  却最需要被反代出去)

反代层在 webui 侧读清单:webui 已能拿到插件目录(PluginManager.PluginDir),
因此**无需给内核接口加方法**。manifest 解析忽略未知字段,加 proxies 对
"旧内核读新插件"与"新内核读旧插件"都无害。

新增 sdk/ProxyDecl 与配套校验(ValidProxyAuth / ValidProxyHostLabel /
NormalizeProxyHost / ValidateProxyDecl);新增运行期 ProxyDeclarer 通道。
hmapdev 的 writePluginJSON 是**白名单 map 重建**——不同步加字段会让声明
被打包静默丢弃(插件作者本地正常、装上去失效),因此 PlgConfig 与
writePluginJSON 同时加,并在打包前校验声明(插件作者本地就能发现写错)。

auth=homeagent(默认,安全的默认):门户会话 / X-API-Key / ?__token=;
auth=none:信任上游自身鉴权,供设备与嵌入式客户端使用——它们不可能持有
浏览器会话,强制走门户鉴权会把设备链路挡死。remotedevice 声明 none,
因为它自身用 ws_token 强制校验。

未声明时升级请求**明确拒绝**(400 + 原因),而不是静默降级成普通请求
(后者表现为前端不断重连、日志看不出原因)。

1. 不跟随上游 3xx:旧实现用 http.DefaultClient(默认跟最多 10 跳),
   上游 302 到内网地址时反代自己跟过去、失败回 502 并把内网 URL 泄给
   客户端。httputil.ReverseProxy 默认不跟随,3xx 原样透传。
2. 逐帧 flush:旧实现 io.Copy 导致上游流式响应被缓冲到上游关闭才下发
   (实测 3 帧 200ms 间隔的流,客户端在 +600ms 一次性收到全部)。
   设 FlushInterval=-1。

另补齐 X-Forwarded-For/Host/Proto(旧实现完全不注入,上游无法判断真实
来源),并剥掉上游 Set-Cookie 的 Domain(防止插件 cookie 打到主门户域)。

插件页新增「服务入口」卡片:列出全部被反代的插件服务(含被拒条目与
不可达原因),点「打开」直接访问。链接带 ?__token=<api_key>,因为子域
与门户不同源、浏览器不会自动带会话 cookie。

webui +35 条、SDK +4 条、工具链 +4 条。关键几条:
- 根绝对路径必须原样到上游(选 Host 路由的核心理由)
- 上游 302 必须原样透传、且反代不得跟随(旧缺陷)
- 已知 Content-Length 的慢速响应必须逐帧到达(**这条经过变异验证**:
  把 FlushInterval 改回 0 后判据挂死 → FAIL,还原后回绿。
  说明:最初写的 SSE/chunked 版本是假判据——ReverseProxy 对
  text/event-stream 与 ContentLength=-1 会自动立即 flush,与
  FlushInterval 无关,变异抓不到,已改正)
- 子域标签冲突不得静默覆盖(后者保留可见并带原因)
- 非法声明不进路由但必须可见(配置页要能看到原因)
- 未声明 websocket 的升级请求必须 400
- auth 逐条生效:none 放行匿名、homeagent 与默认档 401 且给可操作提示
- 自动发现:显式 host 不得被自动编号覆盖(**测试抓到的真 bug**:
  remotedevice 声明的 "devices" 会被改成 "devices-2" 而静默失效)
- 真实端到端:生产实例 huawei_smarthome 的 UI(9444 字节)与其
  /api/status 经反代正确透传

go build ./... 通过;相关包全量测试通过。
internal/plugin/proc 的 TestStreaming_PublishLatencyFlatAcrossSubscribers
是**预存在的不稳定测试**(同一份代码 10 次跑 9 过 1 败,且本改动完全
未触及该包),非本次引入。
2026-09-26 13:49:59 +08:00
4e40597954 merge: 内核编解码层 C 化 + C 基础设施门禁(feature/c-core)
## 内容
- C 化第一刀 L1 纯函数层(ha_codec):token 估算/截断/上下文窗口推断
- 零分配 JSON 扫描层 ha_json_scan(scan/extract 两段分离,黄金对照 + fuzz)
- SSE 协议导航层 ha_sse(**默认关闭**,见下)
- C 基础设施门禁六项(make check-csrc / check-csrc-full,已接进 make test)
- 共享内存与 IPC 的成本地板基准(纯测量)
- 分词器热路径分配优化(差分 oracle 验收)

## 实测(main 同机对照,50000 次迭代)
| 场景 | main | 本次 | 提升 |
|---|---|---|---|
| Truncate zh_1k | 6570ns / 2 allocs | 174ns / 0 | 37.8× |
| Truncate long_zh | 5984ns / 2 allocs | 179ns / 0 | 33.5× |
| Truncate ascii_1k | 1580ns / 2 allocs | 95ns / 0 | 16.6× |
| Estimate ascii_1k | 445ns | 51ns | 8.7× |
| Estimate zh_1k | 2262ns | 1172ns | 1.93× |
| Estimate short_zh | 22ns | 35ns | -58%(cgo 边界固定成本) |

几何平均 4.20× / 中位 1.93×;**变快 7 项、变慢 2 项**(短串受 cgo 边界拖累,
如实记录未掩盖)。调用点在热路径:process.go 对每个上下文事件都调
EstimateTokens,tooldefs.go 的工具定义裁剪调 TruncateByTokens。

## 默认关闭的部分(实测更慢,不当作成果)
- chunkFastEnabled = false:SSE 分块快速路径。首版更慢 52~79%;
  返工(5+ 次 cgo 边界压成 1 次)后为「三项赢、一项输」,toolcall 仍慢 15%
  ⇒ 不打开。TestChunkFast_BenchGate 断言该开关必须为 false。
- ha_json_scan 未接生产路径:库已验完(119 契约断言 + 黄金对照 5 组 +
  4948 万次 fuzz 零崩溃 + 6 万+ 差分用例),作为可复用底座留存。

## 为什么共享内存没有 C 化(附成本分解基准)
编解码占端到端 34%,但 **C 的甜区(字节搬运)仅占 0.2%~2%**
(1KB 拷贝 18ns、16KB 210ns;Go copy 已 44~71 GB/s),大头是 JSON 反射 34%。
另:段内读是**不可信偏移**(offset 由插件转述,伪造会破坏块链),
保留 Go 边界检查 / panic / -race / 模糊测试覆盖比省 0.2% 更值。
IPC 的真正地板是 OS 调度:cat 管道 echo 就要 16µs,占最简 RPC 的 62%。

## 验证
- 全量 go test -count=1 ./... 38 包 0 FAIL
- C 六门禁全过:gcc+clang 零告警(-Wconversion 必备)、ASan+UBSan、
  arm64 交叉编译、头文件自包含、libFuzzer 零崩溃、ABI 版本自述
- 端到端启动实测:14 插件 / 63 工具 / kernel ready / 0 panic
- make build-linux-arm64 → ELF aarch64
- SDK 公开接口 diff = 0 行(csrc/ 是内核 C ABI,不属 SDK 冻结范围)
- git-release-discipline 体检 FAIL=0

## 纪律
- meta.Version 未被污染(未动 internal/meta)
- main 上无 merge 来自 release 分支(仅本 feature 合入)
- 本分支未部署任何生产环境
2026-09-26 13:32:36 +08:00
241f5fac04 fix(knowledge): 拒绝越出知识根的知识名(可致整个数据目录被删)
sanitize 只做小写/去空格/换下划线,**不过滤 ".."**,而 Remove 直接把
sanitize 的结果 filepath.Join 到知识根后 os.RemoveAll。

后果(实测):
- Remove("..") → RemoveAll(<data>),把整个数据目录连同 memory/
  documents/media 一起删掉;且 os.RemoveAll 对已不存在的目标返回 nil,
  调用方(含 knowledge_delete 工具)会回报"已删除"。
- Remove("../..") → RemoveAll(<data 的父目录>)。
- Add("../../x") → 内容写到知识根之外;重启后 scanAll 扫不到该目录,
  条目既不在盘上正确位置也无法重建 ⇒ 幽灵条目(内存有、索引有、盘上没有)。
- Add(".hidden") → 写到隐藏目录,scanDir 明确跳过隐藏目录 ⇒ 同样的幽灵。

修复:
- 新增 checkSafeName:拒绝空段、"."、"..",以及以点开头的段。
  Add 与 Remove 在拼接路径前都过它。
- 双保险:拼接后用 filepath.Clean 复核结果仍在知识根内,
  防止 checkSafeName 将来被改宽而重新引入越界。

反向验证:临时拆掉这两处防护后重跑新测试,Add/Remove 对 .. 与隐藏名
全部"成功",测试稳定变红;恢复后全绿。

影响范围:该缺陷存在于 release/v1.0.x ~ v1.3.x 四条发布线(各自的
internal/knowledge/knowledge.go 的 Remove 均为同一写法),本次修复需按
hotfix 纪律 cherry-pick 回流 main 并前向传播。
2026-09-26 13:11:08 +08:00
a006237105 test(proc): 建立进程间通信的成本地板(判定「优化 IPC」的空间)
目标:回答「工具调用往返 30µs 里,非编解码的 ~20µs 花在哪、能否优化」。
方法:先立地板 —— 任何跨进程方案都有 OS 调度决定的下界。

三层对照(同机同会话,3000 次迭代):

| 层 | ns/op | allocs |
|---|---:|---:|
| ① OS 调度地板(cat 子进程管道 echo,无协议无 JSON) | **16071** | 0 |
| ② 最简 RPC(无载荷、不经共享帧) | **25840** | 20 |
| ③ 纯编解码(共享段 write+read+compact,纯内存) | 10200 | 84 |

## 两条判据
1. **① 已占 ② 的 62%**:一个什么都不做的  echo(两次进程唤醒 +
   两次管道读写)就要 16µs。⇒ RPC 层的成本主要是 **OS 调度**,
   不是协议解析或 JSON 序列化。
2. **②−① 只剩约 10µs**:这才是协议层(JSON 帧 + pending map +
   channel 握手)可优化的全部空间,且其中还包含一次真实的 JSON
   编解码往返。⇒ 「优化 IPC」的理论上限约为端到端 30µs 的三分之一。

## 结论
跨进程数据面的**协议侧已接近其地板**。若要把端到端再压下去,
方向不是「优化协议」,而是**改变通信形态本身**:
  · 批量调用(一次往返做多件事,摊薄固定调度成本)
  · 或对高频小调用改走共享内存 + 自旋/事件通知(绕过两次进程唤醒)
两者都是架构级改动,不是参数调优。

★ 这也解释了此前几轮的困惑:为什么 C 化数据面收益总是很小 ——
  因为真正的大头(OS 调度 16µs)与语言无关。

验证:基准可复现;internal/plugin/proc 全量测试绿。
2026-09-26 13:06:10 +08:00
84d2d7c313 perf(chineseclip): 分词器热路径分配优化 + 差分 oracle 验收(含一处真实语义修复)
嵌入式模型推理(ONNX)本身已是 C++,**可优化的 Go 侧是分词器与预处理**。
本轮先测出成本分布,再改,且**不假设 C 更快**。

## 实测(合成词表,无需 CHINESECLIP_MODEL_DIR)
| 场景 | ns/op | allocs |
|---|---:|---:|
| short_zh | 25681 | 60 |
| short_en | 19100 | 43 |
| mid_en | 117343 | 451 |
| mid_zh | 189260 | 1047 |
| punct_heavy | 283265 | 1388 |
| long_zh | 757746 | 4233 |

## pprof 指出的分配源(alloc_objects,mid_zh)
- splitOnPunctuation **33.5%**(每 token 都做 []rune + string(cur))
- wordpiece **32.3%**(内层每轮候选都 string(runes[a:b]),多数未命中)
- stripAccents/NFD 33.6% cum
- basicTokenize 自身只 1.4%

## 改了三处
1. `basicTokenize`:`len([]rune(token))` → `utf8.RuneCountInString`
   (原为「数个长度」就把整个 token 转 rune 切片)
2. `splitOnPunctuation`:去掉整串 []rune,改逐 rune 扫描 + 一次 flush
3. `wordpiece`:预建 rune 边界表,按字节区间取 substring,
   消除「每轮候选都构造 string」

## ★★ 差分 oracle 抓到一处**真实语义缺陷**(非测量噪声)
本机无模型产物,权威的 TestTokenizerMatchesOfficialReference 会 **SKIP**
⇒ 仅靠现有测试,我的重写**没有被有效验证**。故把改动前的实现原样内联为
oracle 做差分(split/wordpiece/basicTokenize/Encode 四组 + 随机字节 2 万组
+ 随机 rune 5000 组)。

它立刻抓到:`"\xbc\xef=..."` 旧实现得 `["��" ...]`,新实现得 `["\xbc\xef" ...]`。
根因是 `[]rune(s)` 会把**非法字节归一成 U+FFFD**,而纯字节切片原样保留坏字节。
⇒ 真实差异(会进日志/去重/hash),已改为对非法序列写回 RuneError,与旧行为逐值一致。

## 诚实的收益结论:**基本没有**
改动后:mid_zh 189260(改前 186777)、long_zh 757746(改前 786416)、
mid_en 117343(改前 120422)。分配数 mid_en -40%、其余基本持平,
**时间无实质改善**(部分场景还略慢)。

复查原因(不掩盖):重新做 CPU profile 后发现 **~25% 的样本是
runtime 锁/抢占**(unlock2 8.1% + lock2 6.8% + procyieldAsm 6.8% +
asyncPreempt 5.4%),而 utf8/unicode 相关不足 20%。
且 GOMAXPROCS 敏感:1→375365ns、4→209922ns、12→189543ns
⇒ **大量时间花在调度与 GC 而非分词算术**。

⇒ 结论:Go 侧微优化这条路**已到头**。真正的杠杆在别处:
① 提高 GOMAXPROCS/减少 GC 压力 ② 批量分词(降低每条输入的固定开销)
③ 减少送入模型的 token 量。三者都不是 C 能解决的。

改动本身保留(正确性等价、有 oracle 守护),但**不应据此宣称性能收益**。
与 C 化那几刀同一条纪律:没有数据支撑的优化不算优化。

验证:差分 oracle 6 组全过(含非法 UTF-8);providers/... 全绿。
2026-09-26 11:44:49 +08:00
4340232bb0 test(proc): 共享内存数据面成本分解基准(纯测量,判断 C 化是否值得)
针对「共享内存应由 C 实现」这个直觉做量化。结论:**收益判据不成立**。
基准拆出三类成本,只有分开测才知道哪类是 C 的甜区。

## 实测(small:2 toolResults + 2 ctxMsgs)

| 项 | ns/op | allocs | 占比 |
|---|---:|---:|---:|
| ③ 描述符记账(18 个 Slice) | **51** | 0 | **0.4%** |
| ① 段内字节搬运 1KB | **18** | 0 | **0.2%** |
| ① 段内字节搬运 16KB | **210** | 0 | **2%** |
| ② JSON (Marshal+Unmarshal) | **3900** | 15 | **34%** |
| 整体 write+read+compact | 10376 | 84 | 100% |

字节拷贝 1KB=18ns / 16KB=210ns(3 次重复,稳定在 ±5%):
Go 的 copy 已达 **44~71 GB/s**,接近内存带宽上限,**无余量可榨**。

## ★ 更正一处我自己的错误口径
我先前报「编解码只占端到端 9%」——**那是单次非成对采样,是错的**。
成对重测(各 3 次取中位):

| | ns/op |
|---|---:|
| 工具调用往返(inline/small,跨进程) | 30305 |
| 纯编解码(small) | 10376 |
| **占比** | **34%** |

即编解码其实是**端到端的三分之一**,比 9% 重要得多。
但结论**不变**,且理由换成更有力的两条:
1. **C 的甜区恰好是最小的那块**:字节搬运仅占 0.2%~2%。
   真正的大头是 **JSON 反射占 34%**、描述符记账 51ns 占 0.4%。
2. **JSON 恰是本轮三刀反复验证「跨语言重建语义不划算」的领域**。

顺带记:这轮我又被自己的**测量方式**坑两次 ——
① 基准脚本用 `CLOCK_MONOTONIC` 却只取 `tv_nsec`(漏 `tv_sec`),
   算出 -4201ns 负值;② 用 `grep 'ns/op'` 批量取数时,
   把 `JsonOnly/empty`(0.4ns)误当成 `small`(3310ns)读了进来。
⇒ 拿荒谬数值先怀疑工具;批量取数要确认匹配到的是**哪一行**。

## 三条判据
1. 大头是 JSON 反射(34% 时间、15 分配),不是内存带宽。
2. C 的甜区(memcpy 类)只占 0.2%~2%,无榨取空间。
3. 段内读是**不可信偏移**(arena.go 注释自述 offset 由插件转述,
   伪造会破坏块链;payload 可达 MB 级)—— Go 的边界检查 + panic +
   `-race` + 模糊测试覆盖它;C 越界是静默堆破坏。

## 另一条架构判据
格式常量在两仓各写一份(内核 `shm.go` 与 SDK `proc_main.go.tmpl`
各有 `shmStageFieldCount=18`/`sliceSize=8`/`offMagic`)。
C 化一旦动 ABI 须走 SDK 发版 + 两仓版本对齐(MIT vs AGPL),
否则「新内核 + 旧插件」静默错位。本文件只是基准,不涉及 ABI 变更。

## 「C 是共享内存原生语言」在本项目为何不成立
1. **插件侧根本不用指针**:SDK 模板只做 `syscall.Mmap` 拿 `[]byte`,
   全程相对偏移 `{off,len}`、零指针重解释、零 unsafe。
   跨进程 mmap 到不同虚拟地址 —— 这正是必须用偏移的原因,
   C 的指针模型在这里用不上。
2. **真正原生的部分是 Go 更强的地方**:memfd 惰性物理内存
   (未触碰页不占物理内存,MB 级 arena 近零常驻)+ first-fit +
   邻块合并 + owner 校验;OS 语义 cgo 一样要调。
3. C 化还会破坏「整个新架构零 cgo」这条已达成的不变量。

验证:go test -benchtime 全绿,无回归。
2026-09-26 11:22:55 +08:00
84c7559b0e chore(api): 删除批量定位改造后遗留的 6 个未使用函数
首版逐字段设计(findKey/firstElem/scanArray/decBuf 路径等)在批量定位
改造后已完全被取代,保留它们会让人误以为这些路径仍在生效。

删除:findKey / firstElem / scanArray / locateChunkBatchInto /
sseABIVersion / argStringC。
保留 C_size(rootSpan 在用)与 stringifyC(文本数组路径在用)。

go vet 与 go test 均不报未使用的包级函数,故用调用点计数核验
(每个符号的非定义调用数均为 0)。build + 全量 api 测试绿。
2026-09-26 10:44:18 +08:00
7a1322c97f perf(api): SSE 导航层返工 —— 5+ 次边界压成 1 次(三项赢,仍默认关闭)
按 sse-codec-c.md §6.4 的架构改造方向返工。**部分成功**:从「五项全输」
变成「三项赢 / 一项持平 / 一项输」,且所有场景分配数都下降。

## 改造内容
| 项 | 前 | 后 |
|---|---|---|
| cgo 边界次数 | 5+(每字段一次 findKey) | 1(ha_sse_chunk_locate) |
| 键查找 | 每键各扫一遍对象(6 趟) | 单趟分派(遍历成员表一次即分发) |
| 解码 | 每字段一次往返 + 各自 decBuf | 同一趟内写进一块 sbuf(1 次分配) |
| 成员表遍历 | 6 趟 | 2 趟(顶层 + delta) |

顺带修掉两处自造的浪费(都是「先扫一遍拿个数、再扫第二遍拿首元素」):
choices 数组的「数个数 + 取首元素」合一趟;choice0 内的 delta/finish_reason
合一趟。成员遍历实测 107ns/趟,省一趟就是省 107ns。

新增 ha_sse_chunk_locate:一次调用完成根校验 + 顶层分派 + choices[0] +
delta 分派 + content/reasoning/finish 解码,输出写调用方持有的 C 结构体
(C 结构体无 Go 指针 ⇒ 可安全传指针,消除 out-param 逃逸)。
choices_count>1 时直接回退(Go 侧 Unmarshal 会解析全部元素,本层只认 [0],
其余元素可能类型不符而让 Go 整块作废 ⇒ 无法保证等价)。

## 实测(50000 次 × 3 轮取中位)
| 场景 | Entry | GoOnly | 判定 |
|---|---|---|---|
| content_zh | 1540ns / 5allocs | 1871ns / 13allocs | 快 18%,分配 -62% |
| content_ascii | 1250ns / 5allocs | 1304ns / 13allocs | 持平,分配 -62% |
| finish | 820ns / 6allocs | 921ns / 12allocs | 快 11% |
| usage | 2530ns / 9allocs | 2591ns / 12allocs | 持平偏快 |
| toolcall | 3450ns / 20allocs | 3000ns / 21allocs | 慢 15% |

## toolcall 仍输的根因(已定位,非猜测)
分解测量:C 侧纯 C 零边界 = 766ns;Go 侧 []openAIToolCall unmarshal =
1305ns/15allocs;对照 Go 整块 unmarshal ≈ 2980ns。
问题在第二行:tool_calls 元素是对象,Arguments interface{} 需要真实的
map[string]interface{},必须走 encoding/json 的反射建树。
而为了定位已先做了一遍 C 扫描 ⇒ 同一份数据被解析了两次。
⇒ 不是 C 慢,是「扫两遍 vs 扫一遍」。
标量字段(content/reasoning/finish)C 能一次到位 ⇒ 那些场景赢;
需要建树的字段(tool_calls/usage)C 的定位是纯开销。

## 为什么仍默认关闭(理由充分,不是保守)
1. toolcall 是真实负载最常见的一类块(任何一次工具调用流),仍慢 15%
2. 18% 收益不足以抵消「与 encoding/json 语义并存的第二实现」的风险
3. 本刀原始动机在 toolcall 场景没有兑现:分配数 20 vs 21 几乎没降
⇒ 前提是先做「按字段类型决定是否 C 化」,让 toolcall 也不输,再重测。

## 正确性
6 万+ 差分用例(协议形态/真实负载/随机 JSON 3 万/随机字节 3 万)全过。
基准测量也修了:先前 C 基准脚本用 CLOCK_MONOTONIC 却只取 tv_nsec,
算出 -4201ns 的负值 —— 测量工具本身出错会直接毁掉结论。

## 验证
ASan+UBSan PASS;gcc+clang 零告警;arm64 交叉 0 告警;
libFuzzer 66 万次零崩溃;全量 go test 38 包 ok / 0 FAIL
2026-09-26 10:41:52 +08:00
7748ec450e perf(api): SSE 分块 C 导航层 + 差分等价验收(实测更慢 ⇒ 默认关闭)
第三刀:把 ha_json_scan 接进 parseOpenAICompatibleStreamChunkFull。
**结论是否定的** —— 实测比原实现慢,故默认关闭并如实记录。这条提交的
价值在于「已钉死的正确性 + 已定位的根因 + 一条防静默回退的断言」。

## 设计:只做「结构导航」,序列化留在 Go

接线前实测出两条 wire 语义,它们让「整条解析全 C 化」不成立:
  §5.1 重复键是**字段级合并**,不是替换:
       {"choices":[{content:a}],"choices":[{reasoning:r}]} → 两个都保留。
       机制:json.Unmarshal 的 object() 收尾做 v.SetIndex(i, subv.v),
       而 subv 拿到的是**已存在元素的指针** ⇒ 第二次是叠加。
  §5.2 stringifyContent 的 default 分支 = json.Marshal(interface{}),
       即**重新序列化**:{"b":1,"a":2}→{"a":2,"b":1}(键排序)、
       1e2→100、<→\u003c、大 int 先舍入成 float64。
       逐值一致 = 复刻 Ryu 最短浮点 + map 键排序 + HTML 转义 + int 舍入。
两条都只在**取值**阶段需要,故 C 只回答「值在哪里」(零分配零解码),
类型检查靠「用相同的 Go 类型 unmarshal 相同形状的子树」保证,不靠 C 复刻规则。

## 实测:新路径比原实现慢(20000 次迭代)

| 场景 | 新路径 | 原实现 |
|---|---|---|
| content_ascii | 2016ns / 20allocs | 1325ns / 13allocs |
| toolcall      | 5854ns / 33allocs | 3270ns / 21allocs |
| usage         | 3170ns / 24allocs | 2832ns / 12allocs |

分配数**也变多**(20 vs 13),与「消除 GC 抖动」的初衷相反。

根因(逐项测量,非猜测):裸 cgo 调用 168ns;**每次带 out-param 的键查找
205ns + 2 allocs**(out-param 逃逸到堆);一次解析需要 5+ 次查找
⇒ 边界与分配成本约 1µs,恰好吃掉全部收益。Go 侧只需**一次** Unmarshal。
一句话:**用很多次廉价调用换一次昂贵调用,在这个尺寸上不划算。**

## 天花板实验:方向对,但当前实现没到

假设拿到 span 完全免费,只测设计中必须由 Go 做的部分:
  我的 Go 侧 505ns/7allocs  vs  原实现 1239ns/13allocs
⇒ 边界归零后仍有 2.4× 时间、46% 分配的空间。故问题在**逐字段往返**
这个交互方式,不在 C 本身。正确改造:一次调用返回全部字段 span +
结果写调用方栈结构体 + 仅在确需重新编码时回退。

## 正确性:6 万+ 差分用例全过

同一批输入跑两条路径逐字段比对(Content/Reasoning/Done/Finish/ToolCalls/
Usage + bool),5 组:协议形态(含全部回退触发条件)、真实负载、随机 JSON
30000 例、随机字节 30000 例、优化有效性。

★ 差分测试当场抓出 4 个真实缺陷(其中一个正是「优化压根没生效」):
 1. ha_sse_arr_first 里「重新 init 到 sc.s+sc.i」使 base 变了 ⇒ start 恒 0
    ⇒ 返回的是**数组本身**而非首元素。症状是**快速路径永远不生效**——
    而若只看「结果与 Go 一致」,这个 bug 会**完全隐形**(回退总是对的)。
    ⇒ 这就是必须单独断言「优化确实被走到」的原因。
 2. chunkAssemble 的 bool 被丢弃 ⇒ 空对象被判 true(原实现 false)
 3. 键匹配层级搞错:delta 是 **struct**(字段名 CI),不是 map。
    我一度「推理」成 CS 并以为差分测试会通过——错的。
    教教训:哪层是 struct、哪层是 map 要**回原实现读类型**,不能凭字段名推断。
 4. cgo 边界:out-param 逃逸到堆

另修:C 代码从 cgo 前言移进 csrc/ ——前言里的 C **逃出全部 C 门禁**
(告警/sanitizer/交叉/模糊测试),而它恰是本刀最易出错处。

## 防静默回退

TestChunkFast_BenchGate 断言 chunkFastEnabled 必须为 false。
后来者看到「快速路径写得全 + 差分测试全过」,很自然会以为它已生效并打开它
—— 而实测更慢。断言把这个事实钉住,改动即判红。

## 实测汇总
- C 契约 119 项断言、黄金对照 5 组、差分 6 万+ 例:全过
- ASan+UBSan PASS;gcc+clang 零告警;arm64 交叉 0 告警(3 个源文件)
- 全量 go test -count=1 ./... 38 包 ok / 0 FAIL
- libFuzzer 4948 万次零崩溃(上一刀)

教训(与第一刀同源):**「C 比 Go 快」不是前提,是待验证的假设。**
第一刀被 C.CString 的 82% 自找开销推翻一次,这一刀被逐字段往返推翻一次。
两次都是测量推翻直觉。
2026-09-26 10:32:20 +08:00
4d3962a845 feat(csrc): 第二刀 —— 零分配 JSON 扫描/取值层 ha_json_scan(含黄金对照)
C 化第二刀:为协议编解码层铺 JSON 底座。**本刀只交付库 + 验收,
未改 Go 生产路径**(接线是独立一步,库先验完再换产线)。

为什么是它:SSE 单块解析(parseOpenAICompatibleStreamChunkFull)是每个流式
chunk 都要跑的最热路径,实测 1937ns/13allocs(content 块)、3122ns/21allocs
(toolcall 块),而纯字节扫描理论下限 133ns/1alloc —— 差距 15~23×。
一次 1 万块的会话 = 1~2 万次堆分配,正是 GC 抖动的来源。

为什么不复用 SDK 的 remotedevice/ha_json.c(实测三缺陷,不可直接复用):
  ① 无 \u 解码:\u4f60\u597d → ?0?d?d?0(非 ASCII 全靠转义时内容直接损坏)
  ② 只有 _get_int 无浮点:temperature:0.7 静默变 0
  ③ null 与「键缺失」不可区分
  外加它是 DOM + malloc,与本层「不 malloc / 零拷贝 / 纯函数」正交。

设计:scan(结构,零分配零解码)+ extract(取值,按需解码)两段分离。
content 可能是很大的多模态数组,而 stringifyContent 只需要 text 字段拼起来;
若 scan 就解码并分配缓冲,等于把成本付给不需要它的调用方。

★ 被测试抓出 7 个真实缺陷(写 C 时同一逻辑我读三遍都认为正确):
  1 代理对合成成功后未跳过 unconditionally 的 U+FFFD 发射(😀 → 两个 FFFD)
  2 过长编码检查用了只含首字节位的 cp(「你」→ 6 个 FFFD)
  3 members_next 只报值起点不消费值 → 游标停在值前(模糊测试第一轮抓到)
  4 扫描阶段不校验转义字符合法性({"a":"\q"} C 判合法、json.Valid=false)
  5 扫描阶段不校验 \u 后四位十六进制(同上)
  6 get_int 接受前导零(007 / 00)
  7 cgo 桥接把 C 结构体声明为 Go 局部变量 → 运行时 panic
     (cgo argument has Go pointer to unpinned Go pointer)
  其中 4 个是「静默分叉」——不崩、不报错,生产里表现为「内容少一个字符」
  或「某些块被静默丢弃」,极难归因。这正是黄金对照不可省的理由。

★ 另纠正我自己两次错误的「真值」(比代码 bug 更危险,会变成错误规格):
  第一版真值表里 content:{} 的花括号少了一层,把「我写错 JSON」误读成
  「Go 对 content 严格」。修正后实测发现一对方向相反的语义:
  content 走 interface{} 宽松({}→"{}"、true→"true"),
  reasoning_content/usage/finish_reason 强类型严格(123 ⇒ 整块作废)。
  照错误表写 C 会产出「比 Go 更严格」的实现,静默丢弃本该生效的块。

两个由缺陷倒逼的设计决定:
  - members_next 返回**完整值 span** 并内部跳过 ⇒ 「返回 1」蕴含「成员良构」。
    要求调用方自己推进游标的 API 是错的:忘一次就解析到上一个值且不报错。
  - members_complete() 区分「正常扫到 }」与「输入畸形」,否则无法复刻 Go 严格性。

同时修两个基础设施目标对「多源文件/多测试」的适配:
  - csrc-sanitize:每个契约测试各自链接(多个 main 合链会 multiple definition,
    而报错被吞后会被误报成「本机无 sanitizer」——一个假的 SKIP)
  - csrc-cross:多源文件改用 -fsyntax-only 逐文件(gcc 不支持多源单 -o)

实测(全部当场可复现):
  - C 契约测试 119 项断言全过;黄金对照 5 组全过(语法/成员/解码/整数/随机字节)
  - libFuzzer 4948 万次运行零崩溃(121s)
  - ASan+UBSan PASS(两个契约测试各跑);gcc+clang 零告警;arm64 交叉编译 0 告警
  - 全量 go test -count=1 ./... 0 FAIL;make build-linux-arm64 → ELF aarch64
  - 纪律检查 SDK 公开接口 diff = 0 行(未触碰 SDK)

决策关闭(jianf 本轮裁决):C 实现留主仓 csrc/(它本就是替换内核 Go 实现,
SDK 从未被触碰,跨端复用才需进 SDK 而它们不调用本层);ha_json.c 不复用;
下一刀即协议编解码层。
2026-09-26 10:07:27 +08:00
d9f60bcd68 docs(plan): 记录 C 基础设施门禁落地 + 下一刀决定 + ha_json.c 不可复用的实测证据
- §七 新增「C 基础设施门禁」小节(六个门禁 + 地基上线抓出的 5 个自身 bug)
- 记录首次把「C 函数体成本」与「cgo 边界成本」分开测出的基准表
- 下一刀定为协议编解码层,附 SSE 单块解析实测(1937/3122/2464ns vs 133ns 下限)
- ★ 推翻旧判断:SDK ha_json.c 有三个致命语义缺陷(\u 不解码 / 无浮点 / null 不可区分),
  且 DOM+malloc 与设计约束正交 ⇒ 建议 csrc/ 新建零分配 ha_jsonscan.c,不建议内核热路径依赖别仓

待 jianf 拍板三项仍未决,未擅自开工。
2026-09-26 09:45:49 +08:00
8070844fe9 build(csrc): C 基础设施门禁(ABI 版本 / 告警 / sanitizer / 交叉编译 / 模糊测试)
C 化从「一把刀」推进到「可持续推进」,本轮先把基础设施建起来:
不建它,后续每个 C 切片都在裸奔(无告警门禁、无内存安全检查、
无交叉编译验证、无 ABI 漂移检测)。

新增门禁(make check-csrc / check-csrc-full,已接进 make test):
- csrc-lint   gcc+clang 双编译器 × -Wall -Wextra -Wpedantic -Wshadow
              -Wconversion,零告警才算过(-Wconversion 是为 cgo 窄化
              准备的:size_t→int 截断在默认档下是静默的)
- csrc-abi    ABI 版本运行期自述 + 荒谬值检查
- csrc-headers 头文件自包含性(每个 .h 能单独编过)
- csrc-sanitize ASan+UBSan 跑 C 契约测试
- csrc-cross  arm64 交叉编译(homed 的真实发布目标)
- csrc-fuzz   libFuzzer:内存安全 + 6 条不变式(可 CI 门禁)

新增 ABI 契约(csrc/include/ha_abi.h):
- ha_codec.h 声明「签名冻结」,但冻结只写在注释里;现改为
  HA_CODEC_ABI_MAJOR/MINOR + 运行期自述 + Go 侧常量,
  三方交叉断言,版本漂移在测试期判红而非线上表现为行为诡异。
- 门禁当场抓出我自己的两个真 bug:①_Static_assert 是 C11 而项目
  是 -std=c99(-Wpedantic 报的);②##msg 不能拼接字符串字面量,
  导致两个断言共用一个 typedef 名(clang 报的)。

基础设施当场抓出的三个真实缺陷(都是「本机 gcc 能编过、别处会炸」类):
- bench 用了 POSIX clock_gettime,而 CMake 刻意 C_EXTENSIONS OFF
  (严格 c99)→ 头文件未声明;补 _POSIX_C_SOURCE(须在任何头之前)
- 头文件缺 include 时只在「恰好被别的头先包含」处静默编过
- Go 不允许在 _test.go 用 cgo ⇒ C 侧 const 桥接只能放非测试文件,
  且 cgo 生成的 *_Cvar_* 不是 Go 常量(「两边一起错成一样」的盲区,
  改用 C 函数返回 + 编译期 _Static_assert 补上)

实测(全部当场可复现):
- 双编译器 × c99/c11 零告警;ASan+UBSan PASS
- libFuzzer 91s 跑 3329316 次、零崩溃(6 条不变式全过)
- 变异测试:改 C 侧宏 / 让 Go 常量与 C 函数「一起错成一样」,
  均被对应断言抓住(证明门禁不是摆设)
- C 侧纯函数基准(首次把函数体成本与 cgo 边界成本分开测):
  ascii_1k 121.7ns/8.4GB/s;zh_1k 1434ns;truncate 两者均约 128-134ns
- 全量 go test -count=1 ./...:57 包 0 FAIL
- make build-linux-arm64 → ELF aarch64
- 纪律检查 FAIL=0;SDK 公开接口 diff = 0 行

未动:csrc/ 是内核 C ABI,不属 third_party/homeagent-sdk 公开接口。
2026-09-26 09:44:17 +08:00
cbe024f6a6 docs(plan): 两条端口/限流 flaky 已修(17e7094),标记关闭 2026-09-25 17:57:26 +08:00
17e7094967 fix(plugins): 修三处端口/监听缺陷 + 让测试用临时端口(消除既有 flaky)
排查内核 SIGSEGV 时用 A/B 对照(我的树 20 轮 vs 干净树 20 轮)确认了
两条**既有** flaky,与 C 化改动无关。本提交把它们修掉。

## 缺陷 ①(真 bug,不只是测试卫生):pluginmgr 监听地址是包级可变全局

`var HTTPAddr = "127.0.0.1:9876"` 是包级可变全局,`Start()` 还把 settings 读到的值
**反写**回它,`startHTTPServer` 再读它。后果:
  - 多实例互相污染:后启动的实例把地址写进全局,先启动那个读到的是**别人的**地址
    (实测与生产 homed 抢 9876)
  - 全局读写无同步,属数据竞态

修法:改为实例字段 `p.httpAddr`(默认走 `const defaultHTTPAddr`),
不再有可被任意代码改写的包级状态;并新增 `HTTPURL()` 访问器。

## 缺陷 ②:remotedevice 用 ListenAndServe,监听失败静默且 :0 无法回报端口

`p.server = &http.Server{Addr: p.addr}` + `ListenAndServe()` 在后台 goroutine 里报错,
端口被占时只打一行日志、`Start()` 仍返回 nil —— 插件表面「已加载」而网关根本没跑。
且 `:0` 下拿不到真实端口。

修法:改为 `net.Listen` + `Serve`(与 webui/pluginmgr 同形):
  - 监听失败**同步**返回,交给加载器
  - 用**实际绑定**地址回写 p.addr,日志与诊断面显示真实端口

## 测试侧:全部改用 :0,不再抢固定端口

新增 `ConfigRegistry.SetPluginConfig(name, key, value)`:插件表原本只在
`RegisterDef`(插件 Start 时)创建,导致「想在插件加载前预置配置」无从下手
(直接 Set 会因表不存在而失败,错误常被忽略)。新方法先建表再写,填补该时序缺口。

`setupIntegration` 在 `Load()` 前预置:
  - pluginmgr.http_addr / remotedevice.listen_addr → `127.0.0.1:0`
  - webui 走已有的 `SetListenOverride("127.0.0.1:0")`(它有独立旁路)

实测三个插件现在各自绑到 OS 分配的空闲端口(41895 / 35855 / 34021)。

## 缺陷 ③:deepsearch 测试把「上游限流」当成功能回归

`TestRealPlugin_DeepSearchInvoke` 的断言会在上游限流时失败,但插件此时返回的是
**正常结果**(err==nil,content 含 "未返回结果" 与无响应引擎列表)——那是外部条件。
实测失败信息:`brave(Suspended: too many requests), duckduckgo(CAPTCHA), google cse(...)`。

更糟的是它**不可控地随机红**:干净树连跑 20 轮复现 2 次,与代码改动无关。
这种判据会让真正的回归淹没在噪声里。

修法:区分「上游不可用(限流/CAPTCHA)⇒ t.Skip 并说明理由」与
「其他异常 ⇒ fail」。不用静默 return,避免环境退化时判据无声失效。

## 由此发现并修掉的真缺陷:监听地址被硬编码在三处

`127.0.0.1:9876` 曾硬编码在 pluginmgr / cli / webui 各一份。cli 与 webui 后来改为
运行时读 `pluginmgr.http_addr` 设置(本次核实),pluginmgr 自己却仍是全局 —— 三处
口径现在统一为「读设置 + 实例字段」。

## 验证

- 新增 `TestTwoInstances_ListenIndependently`(pluginmgr):两个实例同时监听、
  各自 HTTPURL 指向自己端口、两个地址都真的可连。
  ★ 经**忠实变异**验证有牙:复原「包级全局 + Start 反写 + 读全局」后该测试判红
  (我第一版测试只断言字段不共享,变异证明它没牙,已重写为端到端判据)。
- `internal/plugins` 连跑 **30 轮:30/30 全过**(修复前干净树 18/20)。
- 全量连跑 3 轮:38 ok / 0 FAIL / 0 bind 冲突。
- go build ./... / go vet ./... 干净。
2026-09-25 17:57:15 +08:00
10a8d04deb docs(plan): 修掉重复块 + 补两条既有 flaky 的实测归属
## 修掉我引入的结构错误

plan.md 此前有**两套 §三~§七**(第 468 行起是第 265-410 行的完整副本),
是我早前替换 §七 时遗留的旧版本。现合并为一套:保留新版 §七
(含优化后基准与「完全 C 化」裁定),吸收旧版里仍有价值的
「已定事项(不再挂账)」小节,删掉过时内容:
- 旧的「C 比 Go 慢」基准表(该结论已被推翻)
- 旧的「按长度分派(短走 Go)」建议(已被 jianf 裁定否决)

行数 685 → 498,`grep '^## '` 不再有重复章节。

## 补两条既有 flaky 的实测归属(排查 SIGSEGV 时顺带确认)

用「我的树 20 轮 vs 干净树 20 轮」A/B 对照确认两者**均与 C 化改动无关**:

1. **测试间固定端口冲突**:pluginmgr `9876`(且是包级可变全局 `var HTTPAddr`)、
   remotedevice `9890`、webui `8080`。干净树同样复现 2/20 失败
   (`bind: address already in use` + `signal: terminated`)。
2. **TestRealPlugin_DeepSearchInvoke 依赖外部 SearXNG**(`127.0.0.1:8888`):
   上游限流时必红(实测报错 `brave(Suspended: too many requests)`、
   `duckduckgo(CAPTCHA)`)。干净树同样复现 2/20。

两条都建议改用 `:0` 或区分「服务不可达(skip)/ 真回归(fail)」,
但不属本次「排查崩溃」范围,记入待办。
2026-09-25 17:27:55 +08:00
b4fb254bf5 fix(proc): 修 arena use-after-unmap 导致的内核 SIGSEGV(关停竞态)
## 症状

全量 go test 偶发 SIGSEGV,整个测试二进制被杀(recover 捕不到 runtime
致命错误)。崩溃栈(2026-09-25 实测捕获,完整):

    readLoop (process.go:334)
      → markExited → once.Do
        → onExit → Plugin.handleExit (plugin.go:209)
          → Host.ReclaimOwner (host.go:342)
            → arenaRegion.ReclaimOwner → blockBase → getU32
              → SIGSEGV  读已 munmap 的内存

## 根因(两个叠加缺陷,同一后果)

**① markExited 里 close(exited) 早于 onExit**

    close(p.exited)        // :394 —— 先关闭,唤醒所有等待者
    p.sup.untrack(p.name)
    p.onExit(...)          // :399 —— 回调里要读共享内存

onExit(内核侧 Plugin.handleExit)会调 Host.ReclaimOwner 回收该插件残留的
共享槽,那是要读共享内存区域的。而 exited 一关闭,Stop()/Kill() 就返回
(process.go:566/587),StopAll 随即返回,调用方(Host.Close)立刻
freeShm 解除映射 —— 此刻 onExit 还没跑完,ReclaimOwner 就成了读已 munmap
的内存。

修法:把 onExit 提到 close(p.exited) **之前**,并明确 exited 的语义是
「**完全**收尾完毕」而非「进程已死」——任何等待者看到它关闭后,都可安全
释放共享内存、卸载资源。

**② StopAll 超时分支 `go p.Kill()` 发射后不管**

    go p.Kill()   // 不等待

本函数返回后调用方就 unmap,而 Kill 内部要等 markExited 跑完(含 onExit)。
改为等全部 Kill 完成(Kill 自带 killReapTimeout 上限,不会无限拖住关停)。

**③ 同类的第三处:事件环订阅在关停时从不退订**

EventRing.Subscribe 注册到 Bus 的 handler 会 ring.WritePush(写共享内存),
而 Host.Close 会 munmap 整块区域。此前:
  - handleEvents 把 EvtRingSubscribe 的取消函数**直接丢弃**(corehandler_runtime.go:103)
  - EventsUnsubscribe 是 no-op,注释还写着「子进程 Stop 时由内核统一清理」,
    但 closeProcHost 根本没有退订
于是每个订阅过的插件都在 Bus 上永久留了一个写共享内存的 handler,
munmap 后任意一条事件经过 Publish 就会写已解除映射的内存 ⇒ 同类 SIGSEGV。

修法:EventRing 记为 unsubs、新增 EvtRingSubscribeTracked(订阅即登记),
Host.Close 在 freeShm **之前**调用 evtCloser.Close 统一退订。

## 回归测试(3 个,均经变异验证「修复前判红」)

1. `TestProcess_OnExitCompletesBeforeExitedCloses`(proc)
   断言 Exited() 关闭时 onExit 必须已返回。变异(把 close(exited) 挪回
   onExit 之前)→ FAIL。这是本次崩溃的直接判据。
2. `TestHost_CloseUnsubscribesEventRing`(proc)
   断言 Host.Close 调用了 evtCloser.Close。变异(撤掉退订)→ FAIL。
3. `TestEventRing_CloseUnsubscribesFromBus`(plugin)
   端到端:订阅 → Publish 有写入 → Close → Publish 不再写入。变异
   (Close 不做事)→ FAIL。

顺带给 EvtRing 加了 Written() 访问器(诊断 + 上述测试的可观察量)。

## 验证

- 三个新测试全绿;-race 下 ./internal/plugin/... 全绿
- proc 包连跑 12 轮、internal/plugins 连跑 20 轮:SIGSEGV 0 次
- 全量 go test -count=1 ./... → 38 ok / 0 FAIL
- go build ./... / go vet ./... 干净

## 另有两个**既有** flaky(本次未动,与 C 化无关,单独记录)

排查过程中用「我的树 20 轮 vs 干净树 20 轮」对照确认了归属:

- 测试间固定端口冲突(pluginmgr 9876 / remotedevice 9890 / webui 8080):
  并行或残留实例时报 bind: address already in use。干净树同样复现。
- TestRealPlugin_DeepSearchInvoke 依赖外部 SearXNG(127.0.0.1:8888):
  上游限流时(brave "too many requests"、duckduckgo/quark CAPTCHA)断言失败。
  干净树同样复现。属外部依赖,不是代码缺陷。

两者都不属本次「排查崩溃」的范围,已记入 plan.md 待办。
2026-09-25 17:25:43 +08:00
7799ca4559 perf(c-core): 完全 C 化 + 消灭初版的 malloc/拷贝开销(C 从「更慢」变「明显更快」)
上一提交的基准结论是错的:"C 比 Go 慢" 不成立 —— 那是我把自己的
malloc/拷贝开销误当成了 cgo 的固有成本。本提交先拆解成本、再逐项消灭。

## 成本拆解(同机、百万次 benchtime)

| 场景 | ns/op |
|---|---:|
| cgo 边界(零拷贝传指针 + 空函数体)| 31.9  ← cgo 真实固有成本 |
| + 一次 C.CString + C 侧 strlen | 105-111(多出 ~75ns)|
| 初版 ModelContextWindow(另加 lower_dup malloc + 16×strstr)| 175 |

即 82% 开销是自找的。而初版还违反了自己写在设计文档 §四 的原则第 1 条
「C 接口只吃 const char* + 长度」——它没传长度,让 C 侧 strlen 再扫一遍。

## 逐项修复

1. C.CString(malloc+整串拷贝)→ unsafe.StringData 传指针+长度,零拷贝
2. C 侧 strlen 再扫一遍 → 长度由调用方传入,不扫
3. truncate 的 malloc 输出缓冲 + GoStringN 拷回 → C 只返回**字节数**
   (结果必然是输入前缀),Go 侧 s[:n] 完成切片,全程零分配
4. lower_dup 每次 malloc 模型名 → 栈缓冲折叠,超长走零分配回退
5. 逐字节 utf8_next 函数调用 → 字级(8 字节)ASCII 检测
6. truncate 扫完整串才判断 → 数满 keep 个 rune 立即返回(提前短路)
7. 纯 Go 侧 len([]rune(s))/[]rune(s)(1KB 分配 4KB)→
   utf8.RuneCountInString / DecodeRuneInString 游走,零分配

## 结果

| 基准 | 初版 C | 优化后 C | 纯 Go | 提升 |
|---|---:|---:|---:|---:|
| ModelContextWindow | 175 | 76.5 | 46.8 | 2.3× |
| EstimateTokens / 1KB ASCII | 2318 | 80.8 | 326 | 28.7× |
| TruncateByTokens / 1KB ASCII | 2594 | 71.7 | 411 | 36× |
| TruncateByTokens / 1KB 中文 | 3923 | 70.1 | 3097 | 56× |

## 完全 C 化(jianf 裁定)

撤掉我一度加的「短串 <32B 走回 Go」按长度分派:那会同时存在两份语义
可能分叉的实现。C 是唯一实现。

代价如实记录:EstimateTokens("qq") 这类极短串上 C 约 47ns(几乎全是
31ns 边界成本)vs 纯 Go 约 3ns,慢约一个数量级;绝对值纳秒级
(0.000047ms),单次请求尺度可忽略。若某循环对极短串高频调用,
正确应对是**把该循环 C 化(批量传一次)**,而不是按长度分派回 Go。

## 顺带补的正确性缺口(初版是真错的)

初版 C 的 UTF-8 解码只按首字节推断长度、**不校验后续字节**,
因此对畸形序列会与 Go 分叉:例 "\xE4\x41\x41",Go 判 3 rune,
初版判 1 rune ⇒ rune 计数偏差 ⇒ token 预算与截断点偏移。
这类偏差**只影响计数、不会崩**,不测发现不了。

现在 C 侧做与 utf8.DecodeRuneInString 等价的完整校验(含过长编码、
代理对、超 U+10FFFF、截断序列),语义边界逐条注释。
代价:中文密集输入比初版慢(1467 vs 840)—— 这是刻意的正确性代价,
且仍比纯 Go 快 2×。

新增测试:
- TestGolden_InvalidUTF8:3000 组**任意字节**(含畸形序列)对拍,
  覆盖初版会分叉的输入类别
- TestGolden_TruncateAlwaysPrefix:截断结果必为原串前缀且不超长
- C 契约测试从 21 项扩到 40 项(含非 NUL 结尾、超长名、畸形 UTF-8)

## 包现在要求 cgo 才能编译

删除 codec_nocgo.go:CGO_ENABLED=0 下整包构建失败(错误直指缺失符号)。
不保留回退的理由:只验证过一条路,就不该存在第二条。
实测这不影响任何构建 —— go list -deps 证明只有 cmd/homed 依赖本包,
而 waiter/initconfig/memgc/mock-server 均不依赖(逐个验过),
且 homed 本就强制 cgo(sqlite3 + gojieba)。仓库无 CI。

Makefile 把「不许有第二条路」变成可执行断言:check-codec-cgo-only
(断言 cgo 下全绿 **且** CGO_ENABLED=0 下必须失败)。

## 验证

- C 契约测试 40/40(gcc -Wall -Wextra 零警告)
- 黄金对照 6 个测试全绿(含 2000 组随机 + 3000 组畸形字节对拍)
- 变异测试:改 C 侧返回值后 go test 立即 FAIL(确认真的走 C)
- make check-codec-cgo-only 两项断言通过
- go vet ./... 干净;全量 go test -count=1 ./... → 38 ok / 0 FAIL

## 已知既有 flaky(与本改动无关,单独记录)

internal/plugins 在全量并发下偶发一次 SIGSEGV,栈在
internal/plugin/proc/{unified.go:234,arena.go:197}(arena 的 getU32)。
该两文件最后修改于 09-10,本提交 0 处触及;随后连跑 5 次单包 +
2 次全量均通过。初步判断是 arena/shared-region 的既有竞态,需单独排查。
2026-09-25 15:40:20 +08:00
5ccdf24f18 test(c-core): 补跨语言开销基线 —— 数据反驳「C 比 Go 快」的直觉
codec.go 的注释写着「EstimateTokens 是否该留在 C 侧由 codec_bench_test.go
的实测数据决定,不要凭直觉断言」,但那个文件此前并不存在(悬空引用)。
plan.md 与设计文档也都在说「需先有真实延迟基线(当前没有)」。本提交把它补上。

## 数据(ns/op,benchmem)

| 基准 | C(经 cgo)| 纯 Go | 谁快 |
|---|---:|---:|---|
| ModelContextWindow(短 ASCII)| 175 | 38 | Go 快 4.6× |
| EstimateTokens / 空串 | 100 | 0.43 | Go 快 230× |
| EstimateTokens / 短 ASCII | 115 | 6.5 | Go 快 17× |
| EstimateTokens / 短中文 | 100 | 29 | Go 快 3.4× |
| EstimateTokens / 中 200 字 | 229 | 509 | C 快 2.2× |
| EstimateTokens / 1KB 中文 | 840 | 2870 | C 快 3.4× |
| EstimateTokens / 1KB ASCII | 2318 | 332 | Go 快 7× |
| TruncateByTokens / 短中文 | 233 | 54 | Go 快 4.3× |
| TruncateByTokens / 1KB 中文 | 3923 | 6918 | C 快 1.8× |

(已用 -count 复测确认稳定;ascii_1k 的异常已单独隔离复测 3 次)

## 三条结论

1. **cgo 固定开销约 95–100 ns/次**,小输入下完全压倒算法差异。
2. C 只在**长中文**(UTF-8 步进重)上领先;长 ASCII 反而 Go 快 7×
   (Go 的 utf8.RuneCountInString 对 ASCII 有快路径,C 侧逐字节跑)。
3. ⇒ 判据应是「哪个在**真实输入分布**下真能变快」,不是「哪个看起来更底层」。

## 对后续 C 化的影响(已写进 plan.md §七 与设计文档 §7.1)

- EstimateTokens 的真高频点在 process.go:476 的逐事件循环与 resident.go:552。
  字段分布不单一:Source 是短标签(Go 快 17× 那一档),
  Input/Response 是对话文本(长中文 C 快、短文本与长 ASCII Go 快)。
  ⇒ 当前一刀切走 C 会让短串净亏;正确做法是按长度分派,
  但须先用真实长度分布复测,不要凭推测动手。
- ModelContextWindow(provider.go:333)与 TruncateByTokens(tooldefs.go:38)
  调用点单一、非热路径,开销在单次请求尺度上无关痛痒。

这不否定 C 化方向:协议编解码(JSON 解析、SSE 分片)处理长文本,
才是 C 的主场,也是比「把短函数搬过去」更合理的下一步。
2026-09-25 14:51:10 +08:00
7351c6ca2e feat(c-core): 内核编解码层 C 化第一刀 —— L1 纯函数层落地并打通构建链
第一刀只做三个纯函数(窗口推断 / token 估算 / token 截断),
价值不在功能(Go 版没问题),而在打通「Go → cgo → C」全链路并
建立可复现的对照范式,后面每扩一个函数都复用它。

## 为什么是这三个

按「无状态 → 有状态」分层,L1 协议编解码最安全:纯 string in → struct out,
不碰网络、不碰 Lua、不碰 goroutine。三个函数更是同一组纯算术,最小可验证切片。

## 关键设计:包内符号链接,不链接静态库、不 include 包外源

三种做法都实测过,只有一种同时满足「可构建 + 可交叉编译 + 缓存可跟踪」:

1. ❌ 链接 `csrc/build/libha_codec.a`(原方案)
   - .a 是构建产物、不入库(.gitignore 的 build/ 命中 csrc/build/),
     而发布脚本原先并不产出它 ⇒「不入库 + 不生成」两头空,
     实测报 `cannot find .../libha_codec.a`
   - 交叉编译 linux/arm64(homed 真实发布目标)时,宿主 x86-64 的 .a
     被链进目标产物,实测报 `file in wrong format`

2. ❌ `#include "../../../csrc/src/ha_codec.c"`(包外相对包含)
   ★ Go 构建缓存**不跟踪包外被 #include 的 C 文件**。实测:包外源把返回值
   7→8,`go test` 依然通过(缓存命中、静默沿用旧代码);同样改动落在包内
   文件时立即判红。对「逐步推进 C 化」这是致命的——改 C 源码不生效且无报错。
   (包内 shim `#include` 包外源同样漏跟踪,已实测排除。)

3. ✅ 包内符号链接 `internal/agent/api/ha_codec.{c,h}` → `csrc/`
   文件在包目录内 ⇒ 缓存按内容正确跟踪;只有一份权威源 ⇒ 无副本漂移,
   也不需要「同步 C 源」的 make 目标。

## 不需要额外 build tag

ha_codec 是零依赖纯 C99 源码内联编译,不需要外部库或工具链前提;
而 homed 本就强制 cgo(sqlite3 + gojieba),故 C 路径自然生效。
只用 `cgo` / `!cgo` 一组约束(对比 onnxruntime:那个需运行期 .so,故必须显式 tag)。

## 顺带修掉的既有缺陷(非 C 化引入,但一直缺覆盖)

- Makefile 的 arm64 目标缺 CC/CXX:cgo 回退到宿主 g++,报
  `gcc_arm64.S: no such instruction: 'stp x29,x30,[sp,'`
  (deploy/packaging/build.sh:49 一直是对的,Makefile 漏了)
- Makefile 的 arm64 目标缺 .syso 隔离:cmd/{homed,waiter}/*.syso 是 Windows
  COFF 资源对象,Go 会把同目录 .syso 无条件链进任何目标,交叉到非 Windows
  平台报 `file format not recognized`(build.sh 有 hide_syso_for_target)

## 验证(每条可复现)

- `make build-linux-arm64` → ELF 64-bit LSB executable, ARM aarch64(82MB)
- `bash deploy/packaging/build.sh linux/arm64 homed` → ELF aarch64(79MB)
- 移走 csrc/build/ 后 homed(cgo)与 waiter(CGO=0)均能构建
- 变异 C 源(131072→777)后**同一缓存**下 go test 立即 FAIL(改前:仍报 ok)
- `make check-codec-paths` 两条路径 OK;`make csrc-test` C 契约测试 100%
- 黄金对照:手写用例 + 2000 次随机对拍,C 与纯 Go 逐值相等
- 全量 `go test -count=1 ./...` → 57 包:38 ok + 19 无测试 + 0 FAIL

新增 `make check-codec-paths` 防回归:只测一条路径时,另一条的破坏不会被发现。

## 文档

- `docs/zh/c-core/llm-orchestration-c.md` 同步为「已落地」,并更正因
  「Windows 原生已放弃」而过时的 §2.3(回退路径的理由需重述)
- plan.md 的 P0-1 标记为已修复,附实测证据
2026-09-25 14:45:08 +08:00
b6027f3ff8 docs(plan): 按源码核实重写——剔除过时/跨仓项,只留 10 项真待办
旧 plan.md(1474 行)是「历史工单 + 路线图」混合档,混入两类错误:
1. 已实现却仍标 TODO(§13.12 L3 多模态、§11.4 Lua 快照锁、§12.2 setToolBlocks、
   §13.11 主体 11 项)
2. 根本不属于本仓的跨项目工单(§13.9 在 llmsproxy 仓、§13.10 在 agentmail 仓)

本次回到源码逐项核实(grep 符号存在性 / go build / go test / go test -race),
新档只保留经证据确认的本仓待办,每条附 file:line 与可验证的验收条件。

- §一 结论速览(10 真待办 / 4 生产验证 / 8 已关闭 / 2 跨仓)
- §二 真待办 P0-P2:RuntimeManager 分组 worker、reload 语义说谎、arena 无
  Grow/Shrink、事件环零真实负载、工具超时措辞、handleAgentAction 501、
  Lua 独立 ABI、Windows 无真机验证、homed heap 常驻、3 个测试缺陷
- §三 已关闭 8 项(附源码证据,防复活)
- §四 生产部署后验证 4 项(代码已就绪)
- §五 跨仓工单归属说明
- §六 明确「不做」的决定
2026-09-25 09:17:11 +08:00
39a0c626b6 docs: 补站点基础设施运维手册(不含任何敏感信息)
本项目的生产部署是「多站点 + 统一入口 + 两层 TLS 终止」,此前只存在于
人和 agent 的临时记忆里 —— 换个人接手要重新摸索一遍,我这次就因此在
同一类问题上反复踩坑(误报「已修好」两次、并造成一次全站 TLS 故障)。
把机制写下来。

## 内容

- §0 拓扑:两层 TLS 终止(公网入口机 + 内网网关机),并指出「改一层 ≠ 改完」
- §1 部署一个静态站的完整流程(内网 drop-in → 证书 → 公网 drop-in)
  含若干踩过的坑:为何用 drop-in 而非改生成的主配置、
  为何静态站必须 `try_files ... =404`(回落 index.html 会让不存在的路径
  返回 200,监控与链接检查全都「通过」)、反代为何要关缓冲攒包
- §2 验收:**必须用 `--resolve` / `--host-resolver-rules` 走真实公网路径**。
  内网 DNS 会把域名解析到内网机,直连 curl 测的是另一条路 ——
  这正是我此前误报「已修好」的根因。附 Playwright 片段
  (强调 `ignoreHTTPSErrors` 必须为 false,否则等于没测)
- §3 证书续期:cron → 续期 → 钩子(内网 reload + 推公网),全自动;
  以及**推送脚本必须保留的四道防线**(见下)
- §4 管理后台接口:先取 schema 别猜字段名;路由表是**整表替换**;
  写完要轮询验证(apply 是异步的);系统管理的分组不能手工加条目
- §5 已知陷阱与事故复盘(6 条,均来自本项目真实故障)
- §6 给 agent 的直读入口(llms.txt / 每页 .md,含两个必踩的坑)
- §7 脱敏约定

## 关于事故复盘

§5.1 记录了我这次造成全站 TLS 故障的根因:把 acme.sh 的证书目录名
(**字面含 `*`**)交给了 glob,glob 展开后误匹配到别的证书并写进全局默认
证书。由此提炼两条硬规则:字面 `*` 绝不用 glob;写生产前必须断言
「读到的是什么」。§5.3 记录了「删证书记录前先查全盘引用」——
我漏了 /opt/ 导致推送脚本失效。

## 脱敏

全文无真实域名、IP、token、云 AK/SK、实例 ID 与内部组件名,
一律占位符(`<PUBLIC_IP>` / `<GATEWAY_DATA>` 等),
取值指向本机私有笔记与基础设施面板。已用脚本对 8 类模式做终审扫描:
仅 `127.0.0.1` / `0.0.0.0` / `example.com` 这类结构性取值保留。

技术论断均与线上实际配置或上游源码逐条核对(drop-in 指令、钩子行为、
后台接口语义),文档本身不构成新的未验证声明。
2026-09-24 15:04:02 +08:00
0ca1b96cd8 chore: 忽略 SDK 文档站的主题覆盖目录
上一批漏了 overrides/(只覆盖 footer.html 以补备案号)。它与 docs/、
mkdocs.yml 同属文档站,核心仓不应跟踪——规则漏一条就会在 git status 里
冒出来,正是之前 example/ 那类问题的来源。
2026-09-24 13:31:39 +08:00
a2cba0ceb1 docs: 更正 PluginMgr 的能力描述 + 挡住新文档站目录
## 更正一处实测证伪的断言

`assets/docs/{zh,en}/PLUGIN_DEV.md` 都写着「`PluginMgr()` 仅内置插件可用,
外部动态插件无法直接调用」——**这是错的**。

建 SDK 文档站时对照 `hmapdev` 桥接模板实测:

- `proc_main.go.tmpl:692` 显式 `base.SetPluginMgrAPI(procPluginMgr{})`,即桥接运行时
  **为外部插件注入了** PluginMgr;
- 公开 `sdk/plugin.go:282` 的注释本身就写着「PluginMgrAPI 提供插件管理能力
  (外部插件可调用)」。

真正的区别是**方法数**,不是有无:

| 接口 | 位置 | 方法数 |
|---|---|---|
| `sdk.PluginMgrAPI` | 公开 SDK | 3(ReloadOne / ListLoadedPlugins / IsPluginDisabled)|
| `internal/sdk.PluginManager` | 内核内部 | 9(另有 Enable/Disable/Remove/ReloadPlugins/IsBuiltinPlugin 等)|

两个接口名字相似但**不是同一个**,这正是混淆的来源。已在中英两版改写为准确描述,
并保留原有的「内置插件 API」代码块(那段示例用的确实全是内部面,加注说明)。

## 挡住新文档站目录

SDK 仓新增了 `docs/`(mkdocs 站点源码)与 `mkdocs.yml`。它们与 `README*`、`tools/`
同类——属于 SDK 仓,核心仓不该跟踪。规则带前导路径限定,核心仓自己的 `docs/`
不受影响(实测 `git check-ignore` 命中,工作区不再出现这两个路径)。

SDK 仓同批提交 0a6e2b7(文档站本体)。
2026-09-24 12:10:10 +08:00
4f3de61d8f license: 明确内核 AGPL / SDK MIT 的边界(插件不受 AGPL 传染)
SDK 仓改为 MIT(同批提交 e97cafc)后,核心仓几处「插件静态链接 SDK 故须同许可」
的论述不再成立,一并更正。

## 边界(现在写清楚了)

- **AGPL-3.0-only 覆盖内核与随包内置插件**:homed、internal/、internal/plugins/
  下 18 个内置插件。§13 网络条款照旧适用。
- **MIT 覆盖公开 SDK**:sdk/ 零外部依赖、只依赖 Go 标准库,不引用内核任何代码。
- 因此**外部插件不是本项目的衍生作品**,作者可自行选择许可(含闭源、商业、
  私有),既不必同许可、也不受 §13 约束。

## 改动

- README.md / README_EN.md「许可」章节:改写静态链接那段,写明上述边界与理由
  (决定许可的是被链接的 SDK 代码,而它是 MIT;子进程隔离不再是关键论点)
- README.md / README_EN.md changelog:**按本仓惯例保留历史原文**,在既有更正
  注记区追加一条「许可口径已变更(2026-09-24)」,而不是去改写 v1.2.0 的原文
  —— 避免伪造当时的语境
- site/index.html footer:状态栏拆成「内核许可:AGPL-3.0-only」+「插件 SDK:MIT」
  两行;声明区分「AGPL(内核与其内置插件)」与「SDK 以 MIT 发布,插件不受传染」
- .gitignore:example/ 注释里的计数 20 → 21(实际 10 个示例 ×2 + qq/plugin_test.go;
  规则本身与「有意保留」的说明不变)

验证:go build ./internal/meta/ ./internal/agent/core/ 通过;官网 1440px 无横向溢出、
无控制台错误,footer 许可两行正确渲染(/tmp/lic-footer.png)。
2026-09-24 10:55:23 +08:00
11144c62b5 chore(sdk): 同步 SDK 仓 SetAutoRestart 文档修正
SDK 仓 5af2a86 把 `SetAutoRestart` 的「崩溃后自动重载」改准为
「崩溃后自动重启」,并补上真实约束(线性退避 1s→2s→3s、
5 分钟窗口内第 4 次崩溃即停止、与「重载」是两回事)。

主仓以 vendored 方式跟踪该文件(third_party/homeagent-sdk/sdk/plugin.go,
主仓只跟踪其 40 个文件、不含 README),故此处同步同一改动,
保持两处一致。
2026-09-21 10:35:12 +08:00
d05161ac8d fix(plugin): 退避注释里无实测支撑的「感知不到工具缺席」
`scheduleProcRestart` 的注释写:

    线性退避:1 次→1s,2 次→2s,3 次→3s。崩溃循环时不至于打满 CPU,
    又足够快到用户感知不到工具缺席。

前半句是事实(退避确实只为防崩溃循环打满 CPU),后半句是主观断言:
首次重启就要等 1s,这 1s 内该插件的工具是缺席的、调用会直接报错。
「用户感知不到」既无实测支撑,也会让读代码的人误以为是无感恢复。

这正是另一处文档(README「崩溃到恢复 <1s」)同源的问题 ——
实测退避为 1s/2s/3s,故 <1s 从未成立(`procRestartBackoff = time.Second`
由 02cc74c 引入,且该提交是 v1.0.0 的祖先)。

改为写明真实代价与插件侧的正确做法(在 OnStart 里自建重连与状态重建),
与 SDK 仓 README 刚补的说明保持一致。
2026-09-21 10:34:41 +08:00
7587bd82d8 site: 正名「驻留子 agent」+ 删净页面小字注解
用户两点意见:
1. 那个东西不叫「分诊助手」,叫**驻留子 agent**
2. 页面上加的小字注解全是废话,全删

## ① 正名:分诊助手 → 驻留子 agent

「分诊」只是 offload.go 里对**职责**的描述(triage),
`resident.go` 顶注给的正式名是「驻留子」,`docs/zh/resident-subagent-design.md`
也把它列为独立概念(根 agent / 驻留子 / 工作式轻量子三类)。

7 处全部改正,含图内 SVG 文字、`aria-label`、架构流程图、FAQ 正文:

| 位置 | 原 | 现 |
|---|---|---|
| 图 5 框标题 | 分诊助手 | 驻留子 agent |
| 图 5 框内第二行 | 临时驻留子 | (删,与标题重复) |
| 图 5 的 aria-label | 转投给分诊助手 | 转投给驻留子 agent |
| 正文 | 转给一个临时驻留的**分诊助手** | 转给一个**驻留子 agent** |
| 架构图转投分支 | → 转投临时分诊助手 | → 转投驻留子 agent |
| FAQ | 这正是「分诊助手」的用途 | 这正是驻留子 agent 的用途 |
| CSS 注释 | 分诊助手接到消息 | 驻留子 agent 接到消息 |

## ② 删掉 11 处注解小字

原则:**复述图上已画出来的、或标题已说过的** → 删;
**承载数据**(插件版本 / 源码路径 / SVG 图内必要标签)→ 留。

- `.duty-note` ×6:架构图里 6 个阶段下面那行灰字
  (「构建消息与工具表 · 插件可在此短路」等)—— 阶段名本身已经说清,
  而这 6 行会把循环框右半边撑空
- `.flow-note`:重复解释 `on_input` / `before_output` 跑在什么时候
- `.dv-caps` ×3:图 4 的「任何中断都能插它前面」「被打断的现场压入中断栈」、
  图 5 的「不必干等」—— 图上插队动线和回执 chip 已经把它们画出来了
- `.dv-note` ×2:图 2「实测:statically linked,无动态依赖」、
  图 3「实测整段写入+读回 3.5µs」—— 数字重复
- `.dv5-tnote`:「默认关闭,需部署方打开」—— FAQ 里有完整说明(含理由)
- `.duty-ev` ×4 + `.sm` ×4:证据行/注释行,数字并回正文
  (「实测整段写入 + 读回 3.5µs。」等)

## ③ 删小字的连带修正

- **11 处死 CSS 全部清掉**(`.duty-ev` / `.flow-note` / `.dv-caps` /
  `.dv-note` / `.dv5-tnote` / `.sm`),单文件不留无人引用的规则
- 循环框删掉 6 行灰字后**右半边空了一大块** → 改为 `fit-content` 收窄居中

## 自己踩到并改掉的坑

- 循环框收得太窄(16rem),回边徽标「有工具调用则回到 ①」**压住**
  `after_toolcall` → 加 `min-width` 并加大底部 padding
- 想让循环框占满宽度,试过**阶段项排两列** → 截图发现编号被 grid
  按行填充排成 `1/3/5 · 2/4/6`,线性流程顺序全乱。已回退单列,
  并把这条教训写进 CSS 注释(免得后人再试一次)
- 图 5 触发条件框删掉小字后留白偏大 → 高度 56→42

## 验证

- 三档宽度(1440/768/390):无横向溢出、回边徽标与阶段项**零重叠**、
  文字未被截断
- 深浅双主题 / JS 禁用 / reduce 回归全绿;控制台零错误
- 死 CSS 计数全部归零;「分诊」全站残留 0
- CSS 括号平衡,文件 141,847 字节(原 143,960,净减 2.1KB)
2026-09-21 10:23:06 +08:00
7b7d405463 site: 重做第 3/5 张示意图 + 删冗长文案 + 修中文排版
用户反馈:3/5 页面图片不够精致、动画单调;hero 与架构节两句文案啰嗦;
图 1 那句注释要删。

## ① 删掉两处冗余文案

- 图 1 的 `<p class="dv-note">箭头只进出插件 —— 内核一列都没有</p>`:
  图上已经画出来了(光球只打插件、内核周围无连线),注解是重复
- 架构节副标题的「插件可改写或短路」:与组件表里 `Stage` 那行完全重复
  (那行还更具体,带 1/4/2 的阶段分布)

## ② hero 副标题重写

原文「内核只管编排、记忆与调度,消息 / 文件 / 网络 / 设备一律交给插件。
插件崩了不牵连内核 —— 换掉一个二进制就热重载。」三重堆叠、句子太长。

改短后又发现**两处与源码不符**,一并改准:
- 「热重载」不是崩溃后的行为。崩溃走的是退避重启
  (`scheduleProcRestart`:1s/2s/3s,`AutoRestartEnabled` 默认 true),
  `ReloadOne` 是换二进制那条路径。混成一句等于说错。
- 改为「崩了自己重启,波及不到内核」。

## ③ 图 3(共享内存):从稀疏线框重画

原图 19 个元素、层次扁平。重画后 53 个元素、三层递进:

- 两个进程做成带玻璃高光的卡片,各标自己的**虚拟地址**(0x7f2a… / 0x55c1…)
- 中间一句桥接:「不同虚拟地址 · 同一物理页」——这才是零拷贝的关键
- 物理页外框呼吸描边 + 极淡填充
- 段内标出 `header`(魔数·版本)与 `arena`,并加**字节刻度**,
  把「一片区域」讲成「有结构的区域」

## ④ 图 5(长任务转投):填掉大片空白

原图下三分之一完全空着,且「两种出路」只写在文案里、图上没有任何体现。

- 主 agent 加**忙碌进度条**(一直爬不到头,呼应「占住很久」)
- 积压消息由 2 条改 3 条、宽度递减成「一摞」,并逐条被取走
- 右上空白填入**触发条件**,给的是源码实测默认值
  (`defaultOffloadBusyAfter = 5min`、`defaultOffloadMinPending = 3`),
  并注明「默认关闭,需部署方打开」
- 新增回执区:`① 简单 → 直接办完,发回原通道` /
  `② 需主 agent → 回「忙碌中,请稍候」`,并用光点示意回执送达用户

## ⑤ 排版:中文之间夹空格

改文案时实测发现正文里有「实时 渲染」这类中文间空格 —— 源码换行被浏览器
渲染成一个空格。找出真实渲染有空格的位置并修掉(改用 innerText 判定,
textContent 会把 `<em>` 等块边界误判为空格,实测误报了 2 处)。

## 自己踩到并修掉的几个坑

- 「各自的虚拟地址」两句标签被竖向虚线穿过(压字)→ 改为一句居中桥接
- 图 3 标题靠左时被 `x=72` 的写入虚线穿过 → 改居中
- 玻璃高光整块铺满像蒙了层白纱 → 收到上半部、透明度 .3
- 巡行光点框看起来像页内多了一层框 → 去掉,改为外框呼吸
- 内层标题与外层桥接都在说「同一物理页」→ 内层改为描述段布局

## 验证

- 深浅双主题逐图截图核对(图 3、图 5 各两套)
- 动画:图 3 从 5 → 11 个动画元素、图 5 从 8 → 10;元素总数 19→53、17→45
- reduce 下新增的 CSS 动画(physBreathe、dv5-pile、忙碌条)全部停;
  SMIL 仍靠 pauseAnimations,8/8 SVG 已暂停
- 回归:深浅主题 / JS 禁用 / reduce / 390·768·1440 三档,零横向溢出、无控制台错误
- 结构:CSS 括号平衡、HTML 无未闭合标签
2026-09-20 23:37:16 +08:00
5d395116d1 site: 修正 FAQ 三处与源码不符的描述
用户指出「常见问题部分描述不太符合事实」。逐条对着源码核了六条,
查出三处不准(第 4 条是实质性误导),另修掉一个由此暴露的滚动缺陷。

## ① 第 3 条:「L4 是内核保留的」漏了一半

源码 `interruptLevel(evt, privileged)` 有**两条**放行 L4 的路径:
`privileged=true`(内核)与 `isKernelLevelSource`(编译期内置插件)。
`scheduler.go:74` 的注释也写明「只给内核与编译期内置插件」。

原文只说「内核保留」,会把内置插件的能力说没。已补上。
(「外部插件声明 L4 会被夹到 L3」这句本身没错,`clampPluginLevel` 确实如此。)

## ② 第 4 条:自动转投默认是关闭的 —— 原文读起来像默认行为

`DefaultOffloadOptions()` 返回 `Enabled: false`,源码注明理由:
「默认关闭、由部署方显式打开,与『显式才是特权』同一条理由」。

原文说「内核拉起临时驻留子接手」,通篇没提这个前提,读者会以为开箱即用。
已补上「默认关闭」并给出默认阈值(实测 `defaultOffloadBusyAfter = 5min`、
`defaultOffloadMinPending = 3`,原文只说「忙超阈值」「积压够多」,没给数)。

## ③ 第 5 条:「媒体跟着记忆块走」不完整

`payloadHeld()` 的存在说明有**共享**一说:同一份字节可能被多个块持有,
此时**不删**。两个删除点(`medialoop.forgetPayloads` 与 `sdk/memory_impl.go`)
都各自做了 `stillHeld` / `payloadHeld` 检查,注释写明
「同一张图可能被多个块引用」。「跟着块走」会让人以为按块计数即可。
已改为「如果同一份字节仍被别的块共享,则不删」。

## 核对无误的四条(未改)

- 第 1 条:`现场保存/恢复`、`中断栈` 都是 `scheduler.go` 的原词;四级中断、
  上下文预算、蒸馏与召回均在
- 第 2 条:三通道准确(`proc/shm.go` 顶注:`stdio JSON-RPC` 控制面 /
  `shm + 偏移` 数据面 / `eventfd` 通知面「事件环 post-and-forget」);
  「摘除工具、阶段与通道」对应 `UnregisterPluginTools` /
  `UnregisterPluginStages` / `releasePluginChannels`;`onProcCrash` 注释即
  「摘注册面、喂健康计数、排一次重启」
- 第 6 条:`go:embed adapters/*.lua` 真嵌入;9 个名字与 `internal/lua/adapters/`
  下文件逐一对应(`server.lua` 是网关脚本,不计入)

## ④ 顺带修掉:FAQ 全部展开后滚不到底

改动后我照例量了末尾能否到底,发现**全部展开时卡住、页脚不可见**:
展开后 faq 712 + footer 367 = 1079 > 一屏 900,`mandatory` 又把滚动锁住。

这里走了两次弯路,都记进注释了:
- 先想只让 faq 退出吸附 → **死锁**:它下方没有吸附点,而 mandatory 只允许
  停在吸附点,实测卡在 plugins 的吸附位(y=9455)不再前进
- 阈值先误用「视口高」→ 展开后 faq 高 712 < 892,判不出超限,类根本加不上

最终改为「展开超过『视口高 − 页脚高』时整页切到自由滚动」,
因为 faq 是最后一个吸附节,它一旦装不下,末尾就必须整体自由。

## 验证

- 折叠态:到底=true,页脚可见,faq 标题不被导航遮挡(h2 顶 210 > 67)
- 展开 1 条 / 展开全部 6 条:两种状态都到底=true、页脚可见
- 一滑一页仍生效(8/8 次停靠不同节,72px 偏移为导航高度)
- 深浅双主题 / JS 禁用 / reduce / 390·768·1440 三档:全绿,零横向溢出,无控制台错误
2026-09-20 22:49:56 +08:00
fc8f153e34 site: 修首屏滚不到底 + 交错行出入方向 + 让示意图真动起来
用户反馈三点:① 拉不到最下面 ② 文字与图片没有进出动画,单调
③ 图片仍是「框框住文本」,且希望有「外界光球打到插件上」。

## ① 滚不到底:真 bug,且是两个独立根因叠加

实测(滑到底后读 scrollY):停在 10283,上限 10669,**差 386px**,
页脚完全不可见。两个原因:

- **末尾两节合计超过一屏**。faq 高 635 + footer 367 = 1002px > 一屏 828px。
  `scroll-snap-type: y mandatory` 只允许停在吸附点,于是浏览器被迫二选一:
  要么 faq 标题对齐(则页脚滚不到),要么页脚可见(则标题被导航压住)。
  实测两种坏法都出现过:h2 顶 = -57 / -38(导航底 67)。
  修法:FAQ 六条改双列(省下约 190px),收尾段取消整屏高度,
  合计压到 762px,两个要求即可同时满足。
- **只在 footer 单独设吸附点会形成死锁**。试过给 architecture 设
  `scroll-snap-align: none`(它高 1180px),结果前一个吸附点把它自己吸回来、
  后面又无吸附点接住,实测卡死在 y=5791,怎么滑都不动。
  教训写进注释:高节退出吸附不是解法,「装得进一屏」才是。

## ② 交错行:方向与布局相反(结构性错误)

原文给每行写死 `slide-l`(文)与 `slide-r`(图)。但翻转行里图在**左边**,
却仍从右侧飞入 —— 图穿过文字进场,方向与布局相反。5 行里 3 行错。

修法不是逐行改正,而是**从布局推导方向**:`.alt:not(.flip)` 文左图右、
`.alt.flip` 图左文右,方向跟着 `.flip` 走。这样不可能再写错。
退出时不加 `.in`,transform 回到同侧 ——「从左进就从左出」是自动的。

## ③ 示意图:从静态线框变成有语义的动画

现状实测很糟:5 张图共 116 个元素,**只有 4 个在动**(各 1 条虚线),
图 2 完全静止 —— 用户说「框框住文本」是准确的。

按每张图的语义给它自己的动作(13 种 keyframes,47 个动画元素):

- **图 1 隔离**:外部光球从画面外飞入,四种颜色命中四个插件,
  激起涟漪 + 插件闪一下;内核一列都没有。这正是「外面的一切都落在插件上」。
- **图 2 零依赖**:四项依赖被**逐条划掉**。用 `pathLength=1` + `stroke-dashoffset`
  让线自己「划」过去,不是淡入。
- **图 3 共享内存**:写入/读回两个包沿链路跑,arena 上有光带自左向右扫过。
- **图 4 优先级**:金色包沿四条曲线**插队**到 L1–L4 之前;
  四级强度条依次点亮;队列条逐条被取走(先到先处理)。
- **图 5 长任务转投**:积压消息被接走飞向分诊助手,收到时闪一下。

配套修掉三处我自己引入的缺陷:
- `.dv-pkdot` 原用 `pkPulse` 动 `r`,与行进包叠加会闪烁 → 改只动透明度
- `.dv-ripple:nth-of-type(2n)` 按 `<circle>` 计数,误配到数据包圆点,
  四个涟漪全被染成金色 → 改显式逐色
- 涟漪原画在插件框**内部**,像框里画了个圆 → 移到框下层,从背后漾开

## ④ 顺带发现并修掉的真问题

- **CSS 的 `prefers-reduced-motion` 管不到 SMIL**:实测 reduce 下 6 个
  数据包照跑。加 JS 调 `svg.pauseAnimations()`,实测 8/8 SVG 已暂停。
- **窄屏横向溢出 26px**:源于我这次加的入场位移(`translateX(42px)`)
  在未入场时探出视口。修法是 `overflow-x: clip`(不用 hidden,避免新建滚动容器)
  并窄屏收到 ±20px。实测 390/768/1440 三档溢出均为 0。

## 验证

- 滚动:到底=true,页脚可见,faq 标题不被遮挡(h2 顶=210 > 导航底 67)
- 方向:5 行全部「文在左侧就从左进」,翻转行正确反向
- 入场:逐节停留 13 节全部入场,0 未揭示;
  滑到底后 23 个 opacity=0 的元素**全在视口上方**(退场生效),无一是「场内却不可见」
- 回归:深浅双主题、JS 禁用、reduce、390/768/1440 三档 全绿,无控制台错误
- 结构:HTML 解析无未闭合,CSS 括号平衡
2026-09-20 22:37:06 +08:00
3374e7dbd9 docs: 更正三处无实测支撑的性能断言
用户指出现有文档里的性能数字可疑。逐个实测后发现三类问题,都不加改原文地
标注更正(历史条目保留原文,仓内已有此惯例)。

## ① 「崩溃到恢复 <1s」——从未成立

写于 v1.0.0 发版说明。但**当时的退避代码就已是 1s**(查 v1.0.0 tag 的
`procRestartBackoff = time.Second`),首次重启就要等 1s。

实测(新增临时测试测量 scheduleProcRestart 延迟):

    第 1 次崩溃 → 1s      第 2 次 → 2.001s      第 3 次 → 3.002s

顺带纠正我自己刚在站点写错的阈值:并非「崩 3 次停下」。实测第 **4** 次
才停(`procMaxRestarts=3`,判定为 `n > 3`),前 3 次都会重启。

## ② 「RPC 往返 p50 24.1µs」——量级对、数字不符

实测 `BenchmarkToolInvoke`:inline/small **30.4µs**、frame/small 51.5µs、
inline/large 767µs、frame/large 398µs。原文与实测同为几十微秒量级,
但具体值对不上,且未注明测的是哪种 payload。

## ③ 「CLIP 实测常驻 1.15GB」——采样点不对(6 处)

实测加载 chineseclip 两塔,RSS 会**自己降下来**:

    加载前      0.00 GB
    两塔加载后  1.59 GB   ← 峰值
    GC + 静置     0.89 GB   ← 稳态(内核回收未用页)

1.15GB 落在两者之间,既不代表峰值也不代表稳态。线上稳态实测 0.39~0.58GB
(更长时间静置后更低)。同源问题:qwen3vl 的「常驻 9.4GB」实为**峰值**,
其视觉塔本就是按需加载(源码注释:每张图约 1.6GB,故按需)。

6 处全部改为「稳态 X(峰值 Y)」双值,消除口径歧义:README 中英、
docs/zh/multimodal-space.md、config/registry.go(2 处 + 1 处注释)、
providers/chineseclip/tokenizer.go。

## 验证

- `go build`(含 `-tags onnxruntime` 与不带)与 `go vet` 均通过
- 全仓 `grep 1.15GB` 已清零
- 测量用的临时测试文件已删除,无残留
2026-09-20 19:56:49 +08:00
ca6f4c510c feat(site): priority 图补上「排队输入」这一类(用户指出的漏项)
## 漏项

文案写「输入走两条路」,但图上只有 L1–L4 —— **排队的完全没出现**。
源码 `scheduler.go` 开篇就写明是**两类别**:

- TaskInterrupt(InjectInterrupt*):带 L1..L4,可抢占
- TaskQueued(InjectText*/InjectInputSync*):**无级别**,可被任何中断打断

「级别只属于中断」是这套调度模型的关键一句,图里不表达就等于漏了一半。

## 改法

图改成左右两列,标题直接写清差异:

    中断 · 带级别            排队 · 无级别
    ├ L4 内核独占            ├ 队列条(先到先处理)
    ├ L3 需及时处理          └ 任何中断都能插它前面
    ├ L2 消息类                      │
    └ L1 完全可等                     │
        └───────────┬──────────────┘
                正在跑的任务

- 排队列用**虚线框 + 素色条**(不发光),与左侧的实线发光级别条刻意区分 ——
  「无级别」这件事本身就该在视觉上体现
- 两路汇入「正在跑的任务」,并标注「同一时刻只一个」

## 顺带修的两处

- **浅色下排队条看不见**:原先复用 `gCard`,而浅色下 gCard 是白的,
  白底白条等于没画。改用独立的 `--dv-queue-item` 令牌
- **横向虚线穿过队列条**:原想表达「处理方向」,结果画在了条内部。
  改为右侧竖线 + 向下箭头

## 验证

- 双主题:控制台错误 0、横向溢出 0、图元零越界
- 一滑一页仍生效;JS 禁用 24/24 可见;reduce 下吸附停用
- 390/768/1440 溢出均 0
2026-09-20 10:39:53 +08:00
88923ed663 feat(site): 示意图升级为玻璃面板 + 修 priority 图两处错误
## 根源(用户指「图太平,没有高级 UI 效果」)

问题不在画得不够花,而在**手法本身就平**:纯 SVG rect + 平面文字浮在平坦
背景上,本质上就是工程草图。换基础:

- **玻璃面板**:每张图裹一层带内上高光、内下厚度、外分层投影的玻璃底 +
  `backdrop-filter: blur(8px)`,图形才像「浮在界面上」而非浮在空背景上
- **顶部柔光 + 细颗粒**:径向渐变给受光面,`feTurbulence` 噪点抿掉矢量图的塑料感
- **渐变节点 + 投影**:所有节点从纯色填充改为竖向渐变面 + `feDropShadow`
- **悬停提亮**:`fLift` 滤镜(更远的阴影 + 青色泛光)
- **流动虚线**:连接线 `dashFlow` 动画,看起来「有东西在跑」
- 全部走主题令牌,深浅各自调参(浅色受光方向相反)

## 修 priority 图两处真错误

**① 文案与源码语义错位**(用户报的)
原文写「可以等的 / 不能等的,不能等的再排 L1–L4」——
但源码 `LevelBackground = L1` 的注释是「**完全可等**」。我把 L1 归进了「不能等的」。
实际是:**排队无级别(谁都能插它),中断才带 L1–L4**。已改。

**② L4 文字溢出框外 57px**
`dv-ts` 是 `text-anchor: middle`,但我按左对齐给了 x=46,长的那行
(「L4 内核独占 · 立即打断」)以 46 为中心向两边展开 → 左溢 57px。
新增 `.dv-tsl`(`text-anchor: start`)专供左对齐行。实测四行现均整齐落在框内。

## 顺带修

- 「抢占」标签贴边 99.8%,玻璃面板内边距会裁掉它 → 整条线内移
- 抢占方向原为「从 L4 顶部绕出去悬在半空」,既没连上目标也读反了 →
  改为「从级别条右侧指向正在跑的任务」
- 图 4 内容仅占 viewBox 70%×71%(其余图 88–93%),显空 →
  重画为「强度条背景 + 级别徽标 + 场景标注 + 抢占回边」,现 81%×90%

## 验证

- 双主题:5 面板、控制台错误 0、横向溢出 0
- **全部图元与文字零越界**(含 viewBox 内边界检测)
- 一滑一页仍生效;JS 禁用 24/24 可见;reduce 下 snap 与流动动画均停
- 390/768/1440 溢出均 0
2026-09-20 10:33:20 +08:00
631963fdc7 feat(site): 总起页改为「真正的 AgentOS 长这样」+ 修页脚状态栏不可点
## 总起页:从对比改为展示(用户要求)

前几版是对照表(「别人说 X → 我们要做到 Y」)。用户指出重点不是对比,
而是**把自己作为「真正的 AgentOS 样例」展示出来**。改为四张并列卡片,
每条给「机制 + 可测数字」,不做比较。

标题「真正的 AgentOS,长这样」;四题:隔离 / 调度 / 通信 / 资源 ——
操作系统躲不开的四道题,逐题给答案。

## 文案改了第三轮(用户指「读着太难受」)

按「短句、有节奏、不堆从句」重写四段正文。举一例:

  旧:插件不是进程内的一个库,是内核 spawn 的独立进程。崩了就把它的
      工具、钩子、通道一并摘掉,其余照跑。
  新:插件不在内核里,是另一个进程。崩了就把它注册的东西一并摘掉,其余照跑。

## 修页脚「状态」栏不可点(用户报的 bug)

三行原为 `<span class="muted">` 死文本,点不动。改为链接:

- 最新发布:v1.3.x 线   → /releases
- main 在研:1.4.0      → blob/main/internal/meta/meta.go(版本号的实际来源)
- 许可:AGPL-3.0-only   → blob/main/LICENSE

## 一处自查纠正

我一度在卡片里写「插件崩溃 → 恢复 <1s」,那是照抄 README 的旧说法。
查源码 `dynamic_proc.go` 发现退避实为 **1s / 2s / 3s**(`procRestartBackoff=1s`,
5 分钟内崩 3 次 `procMaxRestarts=3` 即停手等人),**<1s 不成立**。
改为如实写明退避序列与停手机上阈值。README 那句待另开一轮核实。

## 验证

- 双主题:4 卡片、控制台错误 0、横向溢出 0
- 一滑一页仍生效(6 次滑动偏差恒为 72px = scroll-padding-top)
- JS 禁用 24/24 可见;reduce 下 snap 自动关闭
- 390/768/1440 溢出均 0
- 页脚 9 个 gitcode 目标逐个对照 origin/main 的树:**全部存在**
  (不只看 HTTP 200 —— gitcode 对错误路径也返回 200,此前踩过)
2026-09-20 10:11:02 +08:00
4078f3ac0a feat(site): 重写首屏文案 + 交错图文布局 + 一滑一页
## 口号与文笔(用户指「不够响亮、部分文笔不好」)

Hero 改为「是…更是…」句式:

  是记得住的管家 / 更是从不让你干等的搭档

## 五个设计决定:从卡片改为交错图文

原来 4 张卡片平铺。改为 5 行交错(文/图左右互换),每行配一张内联 SVG
示意图,纯 CSS + 主题令牌,深浅自适应,零外部依赖。

**换掉一条、新增一条**(用户指出「插件跑在独立进程」不算特色 —— MCP、LSP
都这么做,不是差异点):

| | 内容 | 依据 |
|---|---|---|
| ② | 部署,从未如此便捷 | 实测插件 `statically linked`、`not a dynamic executable` |
| ③ | 数据如水,随流,随改,随走 | 共享内存 + 相对偏移零拷贝;实测整段写入读回 3.5µs |

标题按用户给的句式写(②③ 原文照用),正文不给形容词、给可核验的做法与数字。

## 一滑一页

`scroll-snap-type: y mandatory` + 每节 `min-height: 100svh`。
为此把 features 的 5 条决定各拆成独立 section(原 2.74 屏塞 5 行,
mandatory 下会锁死底部),architecture 的流程图也单独成节。
现 13 节,实测连续 8 次滑动精确停在第 1..8 节,间距 828px = 一屏。

## 两处实测纠正(都是我先判断错、再被数据推翻)

1. **`proximity` 做不到「一滑一页」**:实测滑 500px 落点就是 500,离最近
   节边界 395px,不触发吸附 —— 只是「有时粘一下」。改用 mandatory。
2. **我误报 architecture「底部锁死」**:按 `h > innerHeight` 判定,忽略了
   溢出行仍可滚动。用真实 wheel 实测 13 节末元素全部可达(含该节 828 < 900)。
   所以没有锁死,压缩 vertical rhythm 是顺带的,不是修复。

## 验证

- 深浅双主题:13 节 / 5 交错行 / 5 示意图、控制台错误 0、横向溢出 0
- 一滑一页:8 次滑动停在 8 个不同节,落点间距精确 828px
- 72px 落点偏移经查是 `scroll-padding-top`(导航高 67px),确保标题不被遮挡 —— 有意为之
- JS 禁用 24/24 可见;reduce 下 snap 自动关闭(`prefers-reduced-motion`)
- 390/768 无 snap(窄屏强制一屏反而难受);1024/1440 启用
- 真人式滚动(wheel 与 400px 步进两种)未揭示元素均为 0

注:本轮前期用了几个 Python 补丁脚本改 HTML,用户指出「不好」。后续改为
直接编辑以产出可审阅的 diff,脚本已删除。
2026-09-20 09:46:18 +08:00
0c9a3900b8 fix(release): .hmap 纳入发布产物白名单 + 路径解析
## 白名单(真问题)

`upload_assets.py` 的 ARTIFACT_SUFFIXES 只有 .tar.gz/.zip/.deb/.rpm/.pkg/_win64.exe,
**没有 .hmap** —— 即使插件包已经构建好放在 dist/ 下,上传时也会被静默跳过。
这正是「release 里一个插件包都没有」的直接原因之一。

补 `.hmap` 与 `SHA256SUMS.plugins`(插件包的汇总校验和,与内核包的 SHA256SUMS 分开,
避免混用)。实测 is_artifact() 现能正确识别两者、仍跳过 README.md。

## 测试路径解析

`HMAP_BUNDLE_DIR=dist/plugins` 这种相对仓根的写法原先会失败:测试的 cwd 是包目录
(internal/plugins/pluginmgr),相对路径解析到包内,报 "no such file or directory",
看起来像产物不存在。改为相对路径按仓根解析(向上找含 go.mod 的目录)。

实测三种调用都正确:相对路径、绝对路径、不设时 skip。
2026-09-20 09:07:33 +08:00
a35f2126a1 test(pluginmgr): 校验发布用插件包能被内核真实安装
配套 SDK 仓新增的 scripts/build_plugin_bundles.sh:**能构建出来 ≠ 内核装得上**,
这个测试用内核自己的 extractPackage 把产物真解一遍,验证三种包形态都落成规范入口。

覆盖的三种形态(都由真实产物验证过):
- 多平台 bundle:`plugin.bin.<os>.<arch>` → 按当前平台挑出并**重命名为 plugin.bin**
- 单平台包(qq 的 plg.json 是 bundle:false):只有 `plugin.bin`
- Lua 包(luademo):入口是 `main.lua`,不编译 Go

不设 HMAP_BUNDLE_DIR 时 skip(不作为常规 CI 的必跑项,避免依赖 hmapdev 工具链):

    HMAP_BUNDLE_DIR=/path/to/plugins go test ./internal/plugins/pluginmgr/ \
      -run TestBuildPluginBundlesInstallable -v

实测 21 个真实产物全部通过(含 Lua 与单平台两种非 bundle 形态)。
2026-09-20 09:02:42 +08:00
9b26db45bc fix(site): 逐条对照源码修正描述(含两处真错误)
上一版有几处表述与源码不符。这轮把页面上每条可核验的说法都对着代码重新查一遍,
改掉 15 处,其中两处是**事实错误**而非措辞问题。

## 事实错误

**① L4 的归属说反了(FAQ)**
原文让读者「用更高级别的中断(如 L4:内核与内核级插件)」插队,暗示插件能用 L4。
源码 `scheduler.go` 的 `clampPluginLevel` 把 **>L3 一律夹到 L3**,注释也写明
「L4 由内核独占(panic、内核事件 selfip)」。照原文写插件会静默拿到 L3。
改为:插件可声明 L1–L3,L4 是内核保留的「立即打断」。

**② 驻留子的父侧动作列错**
组件表写「父可查看/收发/压缩/回收」。"收"不存在 —— 源码的动作集是
`list | create | send | inspect | compress | reclaim | destroy`,
子持有状态面由**父 pull**(resident.go 开篇注释:父持登记表,子持 inputch 处理表,
父 pull 不打断子)。改成「查看/发送/压缩/回收/销毁,子是父拉取而非推送」。

## 措辞不准确(12 处)

- **Context 层**「最近若干条受保护」→ 源码 `pCount := 10` **写死十条**;
  「预训练词向量 → 余弦相似度,TF-IDF 回退」→ 实为优先稠密向量余弦、
  未配置时退到稀疏词向量(TF-IDF / fastText);「自动下沉」→ 归档进 Document 层
- **PluginSDK「四通道」**→ 不是四个"通道",是三面接口(工具/钩子/事件)+ 输出通道声明
- **管道「7 个阶段钩子」**→ 会被读成都在管道内。实际分布是进管道前 1(on_input)、
  轮次中 4、收尾 2(before/after_output),两处都标明
- **sanitizer** 只写了"清工具调用残留",漏了它更常做的是洗坏 UTF-8/U+FFFD/ANSI
  (而这类字节会被模型复读),且不注册工具只挂钩子
- **rss**「推送通知」→ 实际是按间隔轮询 + 中断注入;补上"订阅时记历史条目,
  所以订一个源不会把旧文章全推一遍"
- **memo** 补上可核验的机制:每 5 分钟检查未完成待办
- **ocr / bili** 补外部依赖(tesseract + chi_sim / yt-dlp)—— 不写清楚装完才发现缺
- **mc**「两阶段激活」原样照抄没解释;实为「想连着(意图)」与「确实连着(连接)」
  两个状态分开,所以 bridge 被 kill -9 后能自动重登恢复会话
- **qq** 一句话太单薄,补 20 工具 + 权限模型要点(身份绑帧、取交集、前缀拒绝)
- **a2a / music / weather** 分别补:两个方向与端点、只读无副作用、NoMemory 取舍

## 顺带修掉两个我上一轮引入的 HTML 缺陷

用行替换时失手:Context 卡丢了一个 `</p>`、mc 卡多了一个 `</span>`。
这次写了栈式配对检查才发现(简单的计数对比看不出来)。

## 验证

- 栈式标签配对:p/span/div/button/code/section/h2/h3/details/ul/ol/a/li **全部平衡**
  (修复前 p 差 1、span 差 -1)
- 事实终检 10/10:内置插件 16(all.go 导入数)、LLM 适配器 9 且**逐个名字对上**、
  Go 行 109241→109k、go.mod 1.25.0、L4 归属、resident 动作、Stage 分布、备案号
- 浏览器回归:深浅错误 0、JS 禁用 47/47 可见、reduce 动效停、390/768/1440 溢出 0、
  滚到底未揭示元素 0
- mc 工具数:本写「12 个动作工具」,实测 `tp+"act"` 去重后 activate/deactivate/status
  之外是 **11** 个,已改
2026-09-20 08:48:15 +08:00
47052cb115 fix(site): 更正媒体机制描述 + 页脚补备案号
## 描述性错误(用户指出)
1. **「引用计数 GC」已不存在**。「有引用绝不删」「媒体靠引用计数 GC」
   两处都在讲一个已废弃的账本 —— 实测源码里已无 media_refs/ref_count,
   `internal/memory/media/media.go` 明确写「这不是 GC,也不看引用计数」。
   现行规则是「删除持有它的记忆块即删内容」,与文本块同一套
   (medialoop.go 的 payloadHeld 只在确认无块共享时才删字节)。
2. **「描述才是持久语义」整张卡已过时**。旧实现靠视觉模型生成的描述当索引;
   现已弃用 —— `mediaref.go` 写明标签「不再包含任何生成的描述文本」,
   图片改按统一空间向量检索,`graphmedia.go` 还带一个把旧描述式实体
   迁移成原生记忆块的迁移函数。卡片改为「图片靠自己的向量被检索」。

## 备案号
页脚补 豫ICP备2024074105号-1 与 豫公网安备41070202001579号,
链接到 beian.miit.gov.cn / beian.mps.gov.cn。取值来源是现网
门户配置(/root/portal/dashy/conf.yml),未凭记忆编造。

## 验证
深浅双主题下渲染正确、两条链接 href 实测无误、无 JS 错误。
2026-09-20 00:00:23 +08:00
09298886a2 feat(site): 「一条消息进来之后」改为真正的流程图
原来是 ASCII <pre> 图。它有三个问题:

1. **画不出循环**。真实执行序是 7 步状态机,其中工具循环要回到开头
   再来一轮 —— ASCII 只能表达上下关系,这一点只能靠文字暗示。
2. **7 个钩子排成一行是错的**。on_input 在进管道前跑,
   before/after_output 在**全部轮次结束后**才跑一次;把它们与管道内的
   钩子并列,读起来像一条直线。
3. 漏掉了 post_action 之后才发生的工具调用,以及"上下文裁剪 + 相关记忆召回"
   这一步(在 after_toolcall 里)。

## 现在的结构
五层节点 + 分支 + 循环体:
外部输入 → 输入调度器(三条分支:入队列 / 抢占 / 转投)
→ 处理管道 →〔① pre_action ② LLM ③ post_action ④ before_toolcall
⑤ 执行工具 ⑥ after_toolcall〕↻ 循环 → 三层记忆 → 输出通道

事实全部对照源码核过(不是照抄旧图):
- 7 个 Stage 常量取自 SDK `third_party/homeagent-sdk/sdk/plugin.go`
- 顺序取自内核 `internal/agent/core/task.go` 的 Step 状态机
  (StepPrepare→StepLLM→StepToolBegin→StepToolExec→StepToolAfter→StepTurnEnd)
- 脚本末尾补一句说明 on_input / before_output / after_output 的时机

## 视觉
节点用色与三层记忆的三色一致(蓝=Context/青=管道/金=Graph,紫=转投);
连接线上的光点错峰下行,序号依次点亮。全部是内联 SVG-free 的纯 CSS,
无外部依赖。

## 关键取舍
- **删掉了贯穿全图的中轴线**:节点背景是半透明令牌,轴线会直接透出来,
  实测在「处理管道」里穿过整个编号列表,看着像画错了。连接线本身就是主轴。
- **循环回边改为内嵌徽标**:先做成从框底绕出的弧线,但它会压到下一条
  连接线 —— 同样像画错。
- **给连接线补了静态箭头**:动画关掉时(reduce)方向也要看得出来。

## 验证(独立 headless 实跑)
深浅双主题控制台错误 0、页面溢出 0;图内溢出 0(390/620/900);
**JS 禁用下 14 个节点全部可见、7 个钩子名齐全**(流程图是内容不是装饰);
reduce 下光点/图标动画确为 none 而静态箭头仍在(宽 7px/2px);
**7 个钩子名与 SDK 常量逐一比对通过**,防止文案漂移;
滚动到底未揭示元素 0。
2026-09-19 22:38:06 +08:00
db8534e315 feat(site): 文案精简 + 插件可点击 + 版面精致化
## 文案(净减约 25%,信息量不变)
删的是解释性赘语与重复限定,不是信息:
- 「内核不直接读写任何外部世界…于是「内核有多可信」与…」→「内核不碰任何外部世界…可以分开评估」
- 「大多数框架先写功能再补边界。HomeAgent 反过来:先把边界和调度定死,再往上加能力。」
  →「先定边界与调度,再加能力。」
- FAQ 六条逐条收紧;副标题从句子改回短语
- AI 声明与许可段去重复(两段都在讲同一件事)

## 插件徽章从装饰变为可交互(这是用户报的「无法点击」)
每个徽章现在是真按钮:点开显示该插件的**版本 + 用途**(取自各 plugin.json,
共 20 个),可多开、可收起,末尾「展开全部 20 个」一次全开。
键盘可达(Enter/Space),选中态用 aria-pressed 表达。
初版是纯 <span>,带 hover 效果却不可点 —— 看起来能点但点了没反应。

## 修正一处事实错误
统计卡原写「**36 外部插件**」。实测 36 是**加载总数**(16 内置 + 20 外部);
外部插件实为 20 个。同时:
- 「110k Go 代码行」→ 109k(实测 109,241)
- 「10 LLM 协议适配器」→ 9(server.lua 是 zen 网关脚本,不是厂商适配器)
每张卡补一行小字说明口径,避免再被误读。

## 版面
section 统一 4.5rem 节奏、卡片内边距与标题间距收敛、组件表代码列定宽对齐、
统计卡加口径小字、三层记忆卡收紧。插件选中态从实心青底(20 个齐亮像一堵墙)
改为淡青底 + 主色描边,并给 color-mix 加了 rgba 回退。

## 验证(独立 headless 实跑,全部通过)
深浅双主题 console 错误 0;JS 禁用 47/47 可见且插件卡默认全隐(0 张);
reduce 下粒子停、全可见;主题切换刷新保持、首绘无闪白;
390/768/1440 横向溢出均 0;移动端点插件正常展开;
插件交互逐项验过:单击展开 → 再点收起 → 多开 3 张 → 全展开 20 张 → 收起。
★ 一度报「19 个元素未揭示」,查证是我测试脚本没滚动所致 ——
逐步滚到底后实测 0 个未揭示,非真回归。

另把取数命令写进 site/README.md,并注明「36 = 加载总数」这个易错点。
2026-09-19 22:24:03 +08:00
fab27a1194 feat(site): 深浅双主题 + 动效层,并按用户要求移除立绘
## 深浅双主题
跟随系统偏好,导航栏按钮可手动切换(存 localStorage)。首绘前在 <head> 里
定好 data-theme,无闪白(实测 reload 首绘即正确背景色)。
语义色全部令牌化,:root[data-theme="light"] 只覆盖取值;品牌三色两主题共用
(对应三层记忆,换主题不该换语义)。

## 动效层(1 → 11 个 keyframes)
极光漂移 + 细网格背景、粒子网络(近邻连线,密度按面积自适应、上限 72)、
三色滚动进度条、标题渐变流动、分块上错落入场、卡片聚光 + 3D 微倾、
三层记忆色条自上而下灌注、架构图流光带 + 节点脉冲、数字滚动到位、
分节标题下划线展开。

三条硬约束(都吃过亏):
1. **内容默认可读** —— 初始隐藏只在 .js-fx 下生效,而 .js-fx 仅当 JS 真跑起来才加。
   实测 JS 禁用时 30/30 元素可见(旧版把 opacity:0 写默认样式里 → 26/30 永久不可见)。
2. **尊重 prefers-reduced-motion** —— 不启粒子、不画进度条、元素直接可见。
3. **装饰不得产生滚动条** —— canvas 改用 documentElement.clientWidth
   (window.innerWidth 含滚动条,实测多出 15px 撑出横向滚动),body 加 overflow-x: clip 兜底。

## 移除立绘(用户要求)
删掉 HTML/CSS/JS/资源/令牌全部痕迹,Hero 改单栏。README 记下为什么最终不放图:
原图是不透明 WebP(mode=RGB 实测),白底与角色白裙子同色,flood-fill 会渗进轮廓
让约 42% 身体透明 —— 这类素材要么出透明图,要么就别放。

## 顺带修掉 3 个真 bug(都是主题化后暴露/复核出来的)
1. **代码块换行全丢** —— .code 缺 white-space: pre,实测整段命令挤成一行。
   (这个 bug 在我这次改动之前就存在)
2. **浅色下导航看不清** —— header 背景硬编码 rgba(11,16,32,.78),改用 --nav-bg。
3. **浅色下立绘处有灰块** —— .mascot::after 硬编码深色,改用 --mascot-fade
   (该规则已随立绘一并删除)。
另把 .badge / .btn-ghost:hover / 按钮光泽里 3 处 rgba(255,255,255,…) 令牌化为
--hover / --sheen,否则浅色下是白压白。

## 验证(共享 Chromium 实跑)
深/浅首屏 + 记忆段 + 架构段截图逐张看过;console 错误 0;坏图 0;
JS 禁用 30/30 可见;reduce 全可见且粒子/进度条已停;主题切换 → 刷新后保持;
390/768/1440 三档横向溢出均为 0;CSS 花括号平衡、8 个 keyframes 无孤儿。
2026-09-19 21:49:59 +08:00
923d5d595f feat(site): 新增产品官网落地页(单文件 · 零构建 · 零外部依赖)
用户要求写一个官网介绍页面。做成纯静态单文件,与仓库 WebUI 的既有做法一致
(原生 HTML/CSS/JS,无打包步骤)。

## 内容(每一条都对着源码/运行实例核实过)
- Hero:一句话定位(常驻型个人 Agent 框架)+ 看板娘立绘
- 四个设计决定:内核零 IO / 插件独立进程 / 输入有级别 / 忙时有人顶班
- 三层记忆:Context → Document → Graph,含媒体一等节点、描述即语义记忆、统一多模态空间
- 架构:一条消息进来之后的完整路径图 + 核心组件表
- 数字(**实测值,非估算**):36 外部插件 / 340 工具 / 110k Go 行 / 10 LLM 适配器
- 上手命令、插件徽章墙、6 条 FAQ、页脚(文档/深入/项目/状态)

## 两个设计决定,都有理由
1. **配色取自品牌指南**:蓝/青/金正好对应三层记忆,故三层记忆那节直接用三色做色条。
2. **立绘按「有意的圆角卡面」呈现,不抠图**:原图是白底 + 蓝紫渐变外框,
   而白底与角色的白裙子同色 —— 连通域分析显示 flood-fill 会让 42% 的身体变透明
   (围裙、发丝高光被吃掉)。改为圆角 + 发光边框 + 底部渐隐,方形图与深色页自然衔接。

## 修掉一个真实的可访问性缺陷
初版把 `opacity:0` 写在**默认样式**里、由 IntersectionObserver 加 `.in` 揭示。
实测:30 个 .reveal 元素里 26 个停在不可见 —— **JS 被禁用或报错时整页永久空白**。
改为渐进增强:内容默认可见,仅当 JS 真跑起来才加 `.js-reveal` 接管动画。
复测两种场景均 30/30 可见(正常滚动 + 禁用 JS)。

## 验证(用共享 Chromium 实跑,不只是看代码)
- 控制台错误 0;两张图均加载(logo 400x400、立绘 1024x1024)
- 移动端 390px:无横向溢出,导航折叠,立绘置顶
- FAQ 手风琴展开正常(open=true)
- a11y:图片 alt 齐全、单一 h1、lang=zh-CN、无空文本链接
- 标签配对全 OK;34.6 KB;**无任何外部依赖**(无 CDN/字体/JS 库)
2026-09-19 21:15:00 +08:00
71faf8d9ad docs(readme): 按源码修正 README 的过时事实(中英同步)
上一轮只补了 v1.3.x 变更日志,没系统核对全文。本次逐条对照源码,修掉 5 处硬错误:

1. **消息时序图漏掉输入调度器**(最严重):还画着 `IO->>EV: inputCh` 直连
   eventLoop,而当前输入必须先进调度器。补 participant 与调度阶段
   (两类别+四级中断、同级不排队/更高级抢占、转投分诊助手)。
2. **图里的 `drainInterrupts` 已不存在**:实测该函数在源码中查无此项,
   改为「安全点:中断求值/让位」(真实机制见 scheduler.go)。
3. **内置插件数 11 → 18**:漏列 ai_image / data / localuse / multimodal /
   remotedevice / skillmgr(实测 `ls internal/plugins/` = 18)。
4. **Lua 适配器 8 → 10**:漏列 ollama / server(实测 = 10)。
5. **`agent/api/` 描述错误**:它只有 provider.go,不含 Lua 适配器
   (适配器在 internal/lua/adapters/);改为如实的「provider.go 调 vm」。

另修一处**自相矛盾**:构建章节写「依赖 Linux/Windows」,而下载章节说
homed 已放弃 Windows 原生(`package-windows.sh` 明确「不往 Windows 装 homed」,
只建 waiter.exe + 引导 WSL2)。改为「依赖 Linux」并说明 Windows/macOS 的真实边界。

并给「设计要点」补上两个当前核心机制(此前只有域分离与三层记忆):
输入调度(两类别+四级中断)与驻留子/分诊助手。

验证:全仓文档断链 0;6 个 mermaid 图块配对全 OK;上述数字逐条实测复核。
2026-09-19 20:59:42 +08:00
c0274b71d5 docs: 删除迁移期临时文档,现行内容搬进正式文档
用户指出迁移评估那批是**过程性临时文档**,迁移已完成就该退场。

## 删除(38 个文件)
- docs/zh/架构迁移评估.md(1621 行)—— 评估稿。开头的「❗现网正在发生的问题」
  (output_send 永远成功 / cgo 超时泄漏 26 次 / stage 污染)**全部已修复**,
  留着是误导性告警。其 §三「目标架构」已被 ARCHITECTURE.md 完整覆盖
  (且后者更细,含子进程生命周期管理)。
- docs/zh/plugin-interface-matrix.md(428 行)—— 迁移基线矩阵。
- docs/zh/experiments/(36 文件)—— 18 项可行性实验,验证的是"该不该迁移",
  迁移早已完成;实测无任何构建/测试依赖它。

## 现行内容先搬走(不能随临时文档一起丢)
- plugin-interface-matrix §九「接口扩展规则」→ 搬进 docs/git-branching.md 新增 §八
  (只增不减/签名不改、新增必须"插件调用内核实现"方向、hmapdev 模板必须同步接线
  否则全体插件编译失败、"接口纯追加"≠"无需重编"、合回 main 的同步清单)。
- git-branching §六 原写「接口冻结是合回门禁」—— 冻结是**迁移期**约束,v1.1.x 起
  已到期,改为标注失效并指向 §八。

## 引用清理
8 处引用全部改指现行文档:plan.md ×3、两篇设计文档各 ×1、
4 处源码注释(proc/shm.go、proc/process.go、dynamic_proc.go、entry_dispatch_test.go、
proc/bench_test.go)。仅 third_party(SDK 独立仓)保留 1 处,不动。

## 验证
- `go build ./...` 通过;`go test ./internal/plugin/...` 两个包全绿
- 本项目文档**断链 0**(另 2 处断链在 oh_modules 第三方依赖内)
2026-09-19 19:22:48 +08:00
7213edd181 docs: 全面按当前源码更新文档 + 删除已过时文档
## 删除(内容已落地/已被替换,保留只会误导)
- demo.md ................... failback 与 recoverydiag 均已实现,0 引用
- docs/defect-qq-output-send-loop.md .. 已修复(本身也标了「已修复」),0 引用
- docs/embedding-comparison.md ....... 一次性选型报告,仅被 agent 产物引用
- docs/zh/plan.md ............ 描述的旧 nav 布局已重写、死配置已清,全部完成
- docs/zh/plugin-migration-plan.md ... 迁移已上生产,纯过程稿(Part 0~6 全完成)

## 更新(按当前源码核对)
- assets/docs/{zh,en}/ARCHITECTURE.md(README 指向的用户文档,最重要):
  把只讲 cancel/intercept 的旧「中断机制」章节重写为「输入调度器与中断机制」——
  补上两类别 + 四级中断(L1~L4,默认 L1、外部插件 L4 夹到 L3)+ 抢占/挂起/中断栈
  + 饥饿防护(PreemptCount 提升,封顶 L4)+ 抢占冷却(2s)+ 停止语义(cancelBudget)
  + 驻留子/分诊助手/残余任务;新增「上下文预算」章节(窗口 ≠ 工作面,600K 封顶,
  预算是上限非填充目标)。中英章节数现已对齐(各 13 节)。
- assets/docs/{zh,en}/PLUGIN_DEV.md:插件示例表补 6 个缺失项
  (acp/deepsearch/plugindev/recoverydiag/vanblog/vikunja);qq 工具数 17 → 20(实测)。
- README.md / README_EN.md:补 v1.3.x 线(此前只到 v1.2.0,而 1.3.x 已发布 12 个 patch)——
  驻留式子 agent、输出通道寻址、输入调度器、轻量内核 profile、积压及时反馈。
- plan.md:开头两个「⚠️ 紧急/正在持续污染」是过期告警(实测  残留 = 0),
  改为「已解决」并加文档定位说明;§13 仍是活跃路线图故保留。
- docs/zh/plugin-interface-matrix.md + 两处源码注释:清理指向已删文档的断链。

全仓 md 断链检查:仅剩 1 处,位于 third_party 的 oh_modules(第三方依赖,非本项目)。
2026-09-19 19:14:55 +08:00
8acd3ce1a8 fix(offload): 内核说明不能被再转投(自我循环)+ offload_owned 未接线
★ 线上实测两个缺陷:

1. **自我循环**:转投会在队列留一条 [系统] 说明(source=kernel),
   而转投条件把这条说明也算进「积压够了」⇒ 每次转投都产生下一轮要转投的东西。
   实测 5 秒内连续触发两次,分诊助手不断收到「N 条积压已转投」这类噪音。
   修法:takeQueuedInputs 排除 isKernelNotice(source=kernel)。

2. **offload_owned 永远为 false**:我加了 ResidentInfo 字段、加了状态面映射,
   却漏了在 rc.info() 里赋值 ⇒ 线上转投子明明存在,读出来是 null。
   这类「加了字段但没接线」不会报错,只会让父的判断悄悄失效
   (父据此决定回收策略,读到 false 就会把临时助手当成正式子)。

测试 +3:说明不转投 / 循环必须终止 / offload_owned 会被上报。
前两条已实测「禁用守卫会失败、恢复后通过」,是真回归测试。
2026-09-19 17:47:44 +08:00
943eef01cf feat(resident): 分诊助手定位 + 残余任务由父显式决定
用户澄清(重要定性):这不是「内核替父决定」,而是**及时反馈** ——
主 agent 忙时不该让用户干等十几分钟。子 agent 是**分诊助手**:
简单的直接处理并回复,需要主 agent 的立刻回「忙碌中,请稍候」、不勉强作答。

三处补齐:

1. 分诊助手的职责提示词(之前完全没给 ⇒ 子不知道自己为什么存在):
   两条路(直接办 / 报忙碌)、拿不准时报忙碌、必须 output_send 到原通道。
2. 驻留子继承父的 SystemPrompt(之前没传 ⇒ 子只用一句兜底文案,
   拿不到「异步通道必须显式 output_send,否则回复被静默丢弃」这条铁律。
   webui 这类同步通道能回是因为走 ResponseCh,掩盖了这个缺陷)。
3. 残余任务由父显式决定(用户要求):reclaim/destroy 时子手头未处理的消息
   不再由内核悄悄处置 —— 内核只负责列清楚,父用 residual=keep/drop 决定。
   之前 pendingEvents 只收带 ResponseCh 的,异步(qq)残余任务完全不在内,
   被销毁时静默消失、用户零反馈且日志无痕。

配套:
- scheduler.takeAllPendingEvents:取走全部未执行事件(不筛通道)
- ApplyResidual(keep|drop):keep 转回父队列(保留 ResponseCh),
  drop 逐条记日志 + 给同步调用方补终态(否则 cli/a2a 永久挂起)
- 状态面暴露 offload_owned,让父分清「我建的子」与「内核临时拉的助手」
- 工具 schema 加 residual 参数并说明 drop 的代价

这也是用户观察到的「机制很自然」的落点:分诊助手就在同一张登记表里,
父能 inspect/send/compress/reclaim/destroy,控制面 6 动作按 id 生效不区分来源。

测试 +7(残余 keep 转回且保留 ResponseCh / drop 通知同步调用方 /
空残余如实报告 / 分诊提示词 / 继承 SystemPrompt),
其中 drop 那条已实测「对着静默丢弃的旧实现会失败」。全套绿。
2026-09-19 17:43:16 +08:00
01909bb914 fix(offload): 转投必须保留 ResponseCh,否则同步调用方永久挂起
线上实测第二个 bug:转投生效、子也正常处理(日志各 ~3s),但 webui 的 HTTP
请求一直挂着不返回,最终 504。

根因:第一版用 InjectInputTo 转发,它会**重建** InputEvent ⇒ ResponseCh 被丢掉。
而 cli / a2a / webui 这类**同步**调用方正阻塞等这个 channel。
仓库反复警告过同一件事(Agent.Stop 的注释:「带 ResponseCh 的同步注入方
(cli / clawhubadapter 均无超时)会永久挂起」)。

修法:改走既有的跨 agent 投递原语 DeliverRouted —— 它推**原事件**,保留
ResponseCh/RequestID,只往 payload 里补转投标注。

回归测试 TestForwardKeepsResponseCh 断言**最强的那条性质**:真的等同步回执回来。
(不用「读子的 InputChan」来断言:SpawnResident 会启动子自己的调度循环,
它会与测试抢同一个 channel,那样写出来的测试是 flaky 的 —— 我第一版就是这样,
实测挂死过一次。)
已实测该测试对着错误实现会失败(10s 超时)、修后通过。
2026-09-19 17:16:24 +08:00
fe1d2672d8 fix(offload): 积压可能全堵在 io 输入 channel,不在就绪队列
线上实测发现上一版**永不触发**:主 agent 跑着 6×45s 的长任务、我连发 4 条消息,
scheduler 始终显示 queue=0、residents=0,转投一次都没发生。

根因:schedulerLoop 是**同步执行**任务的,所以「正忙」期间它根本回不到循环顶部
去调 pumpInbox —— 后到的输入全堆在 io.inputCh(容量 256)里,压根没进 sched.queue。
而 takeQueuedInputs 只看 s.queue ⇒ 恒取不到东西。

★ 仓库里早记过同一个坑:armStop 的注释写着「pending 是还没被 pumpInbox 搬进队列
的那一段……只数 s.queue 会得到 0(实测),配额随之失效」。我重犯了它。

修法:转投前先 drainInboxToQueue() 把 channel 里的输入搬进队列。
与 pumpInbox 的区别是**不要求 hasRoom** —— pumpInbox 满时会停下保留背压,
而转投场景恰恰是「队列空、输入堵在 channel」(调度器回不到 pumpInbox)。
队列上限仍由 enqueue 把关,放不下的给同步调用方 skipped 终态(不丢、不阻塞)。

回归测试 TestOffloadSeesInputsStuckInChannel 精确复现该现场状态:
已实测它对着修复前的逻辑**会失败**(期望 3 实际 0),修后通过 —— 是真回归测试。
2026-09-19 17:05:38 +08:00
69446a2649 feat(scheduler): 主 agent 忙时把积压任务自动转投给驻留子
问题(2026-09-19 线上实测):主 agent 被长任务占住时(现场:12 分 8 秒、69 次
工具调用),后来到达的消息全部以 level insufficient 排进中断队列干等 —— 同级
中断不能抢占同级运行任务(canPreempt),只能等前一个跑完。而内核本有驻留子
(独立 agent + 独立调度器)可并行干活。

行为(用户 2026-09-19 明确要求):
- 触发:运行任务持续 > offload_busy_after(5m) 且积压 >= offload_min_pending(3)
- 拉起/复用「转投专用」驻留子,把积压的纯排队输入转投过去
- 在原队列位置留下说明「[系统] N 条积压任务已转投给驻留子 agent X 处理…」

通道配置(按用户口径,与人工创建的子刻意不同):
- 不配 inputch(内核的干活 agent,不接收插件用户输入)
- 持有全部输出通道(结果要能发回 qq/webui 等正确通道)

三个设计要点(都是实测撞出来的,写进代码注释与设计文档 §7.1):
1. 检查必须在**独立 goroutine**:schedulerLoop 同步执行任务,放它里面在
   「正忙」期间根本回不到循环顶部 ⇒ 永不触发(我第一版就写错了,测试才发现)。
2. 只转投 TaskQueued 纯排队输入:中断任务带级别语义、self 任务与父的记忆面绑定。
3. 转投失败/关闭时必须把任务**放回队列前端**:吞一条输入比多处理一条更糟。

这是设计 §7「决策在父的模型手里」的**刻意例外**(父正忙、物理上无法决策,
而积压任务本来就是空的),已在文档中显式记录,且默认关闭、由部署方显式打开。

测试 11 条:只取排队输入 / 不足量不取 / 放回不丢任务 / 说明自解释 / 默认关闭 /
空闲不触发 / 端到端转投 / 上限不增殖 / 独立 goroutine 确实会触发。
2026-09-19 16:59:47 +08:00
e273924511 fix(llm): 参数无法解析时给出真因,不再静默丢弃整条调用
★ 上次修复误判了成因。真实根因(本次运行日志 34/34 同形):
    {"command": "…完好的长命令…", "timeout": 20s}
  command 一字节没错,只是 timeout 值少了引号 —— cmd_run 的 schema 把 timeout
  声明成 string、示例写着 "10s, 1m, 30s",模型照抄格式却忘了引号。
  finish_reason=length 出现 0 次 ⇒ 上次那条"截断"分支从不生效。

旧行为把**整个参数**丢掉,模型只看到 "command is required",看不出坏在 timeout,
只能原样重试。实测本次运行 cmd_run 失败率 35%(34 败 / 71 成),
12 分钟的任务里更是 48% 时间耗在这上面 —— 每次失败都付一次完整 LLM 往返。

三处改动:
1. repairToolArgsJSON:解析失败时先试窄修复 —— 只给"值位置上未加引号的带单位
   数字"补引号,且修完必须真能解析成功才接受。不碰合法 JSON、不动正文里的 20s、
   不会把真截断"修好"。
2. 修复仍失败时不再静默降级成空 map,改为带 __arg_error 交给模型,并按成因
   分流文案:截断→拆小参数;JSON 写坏→提醒带单位的值要加引号。
3. 统一键名 __arg_error(原 __truncated_error 只覆盖截断,语义过窄)。

同一缺陷面不止 cmd:agentcli/healthcheck/timer 都有 string 类型却以
"5m, 1h" 作示例的参数,此修复一并覆盖。

回归测试:真实日志样本修复、保守性(不碰合法/正文/截断)、
端到端(修复后 timeout 仍能被 time.ParseDuration 接受)。
2026-09-19 16:49:16 +08:00
53e7106985 fix(llm): 参数解析失败不再丢弃完好字段(改错值格式,不是截断)
★ 上次修复误判了成因。真实根因(日志 11/11 同形):
    {"command": "…完好的长命令…", "timeout": 20s}
  command 一字节没错,只是 timeout 值少了引号 —— 而 cmd_run 的 schema 把
  timeout 声明成 string、示例写着 "10s, 1m, 30s",模型照抄格式却忘了引号。
  实测 finish_reason=length 出现 0 次,所以上次那条"截断"分支从不生效。

旧行为把**整个参数**丢掉:模型只看到 "command is required",看不出是 timeout
写坏了,只能原样重试 —— 12 分钟的任务里 30 次失败 / 32 次成功(48% 浪费),
每次失败都付一次完整 LLM 往返。

改法:parseToolArgsJSON 失败时先试 repairToolArgsJSON,只做一件很窄的事 ——
给"值位置上未加引号的带单位数字"补引号,且修完必须真能解析成功才接受。
因此不会改坏合法 JSON、不会动字符串正文里的 20s、不会把真截断"修好"。

真实日志样本 + 保守性 + 反伪造三组回归测试已钉死。
2026-09-19 16:47:13 +08:00
6ddef5e49f feat(llm): 声明真实上下文窗口 + 工作区间与窗口分离
问题:core.llm.model=AUTO,而 ModelContextWindow("auto") 匹配不到任何分支、
掉进 default 32768 —— 该源真实窗口是 1M(实测 990,034 token 的 prompt 通过),
内核却按小 30 倍的窗口算全部预算。

三处改动:
1. ModelContextWindow 补 deepseek-v4/v3 → 1M;推断不出时打日志(静默降级是
   这次问题的成因,不能再默默退回一个小值)。
2. sourceFieldDefs 补 context_window 声明:它早已被 readInt 读进 LLMSource
   并透传到 provider,但没进这张表 ⇒ WebUI 里看不见也改不了。
3. ComputeTokenBudget 新增 maxTargetTokens=600000:窗口 1M 不等于按 838K
   (80%)干活。标称窗口≠有效窗口,600K 是该源最优工作区间,所以把
   「窗口上限」(会不会被上游拒)与「工作区间」(预算分配)分开。

配套 core.llm.max_tokens 4096→32768(实测长输出样本达 18,272 token,
16384 仍会截断;上限是 cap 不是目标,短问答零成本)。

测试:tokenbudget_test.go 钉死封顶生效且小窗口不受影响;
context_window_test.go 钉死推断值与显式声明优先级。
2026-09-19 14:24:31 +08:00
95292aff8e test(llm): 钉死截断必须短路工具分派
补一条端到端断言:截断的 tool call 绝不能拿着空 map 走到 files_write
(那会回 'path is required',模型据此原样重试)。断言 executeToolCallInner
的短路 + 指引可执行。
2026-09-19 13:53:56 +08:00
2722d76095 fix(llm): max_tokens 截断不再静默降级成空参数
长参数工具调用(整段脚本/大 JSON)被 core.llm.max_tokens 从中间切断时,
上游回 finish_reason=length,而旧实现把这个信号整个丢掉:残缺 JSON 解析失败
后静默降级成空 map,工具只看到参数为空并报 'path is required'。模型因此完全
看不出真因,原样重试四遍、次次撞同一堵墙(2026-09-19 实测 4 次 files_write 失败)。

注:files_read 并未失败——是写挂之后模型反复重写把读卷进同一轮,看起来像两者都报错。

改法:
- finish_reason=length 时不再静默降级,改为塞入 __truncated_error 指引,
  告诉模型「参数被截断 + 请拆成多次调用/追加写 + 勿原样重试」;
- executeToolCallInner 见到该标记即短路,不拿空参数去调工具;
- 非截断的残缺 JSON 保持旧行为(避免把「厂商不回 finish_reason」误判成截断)。

回归测试 2 条钉死这两面。
2026-09-19 13:49:21 +08:00
01113664b4 fix(obs): 抢占日志改在判决点打(修自伤)+ scheduler 事件接进 SSE
## 修我上一版的自伤

上一版把 preempt 日志打在 `executeNewTask`,但那时 `nextRef` 已经把
`s.running` 换成了抢占者自己,于是输出成了

    preempt start: task#2 ... -> victim task#2 (cli)

victim 打印的是入侵者本人。判据必须落在 `registerInterrupt`——那一刻
running 还是真正的受害者。改为在抢占判决点打:

    [agent] preempt: task#2 class=interrupt level=3 from cli (L3) preempts task#1 class=queued level=0 (qq)

## 补上「入队而非抢占」的日志

中断到了却没生效,此前完全不可解释。现在两种成因分开写:

    [agent] interrupt queued: ... vs ... (qq) — running in critical section; queue=N
    [agent] interrupt queued: ... vs ... (qq) — preempt cooldown; queue=N
    [agent] interrupt queued: ... vs ... (qq) — level insufficient; queue=N

没有这条,`interrupt from X` 打过之后任务为什么没让位就只能猜。

## scheduler 事件接进 SSE

`EventScheduler` 此前既不在 `handler_chat.go` 的 subTypes、也没有任何订阅者
(全仓 grep 零命中)——内核里 suspend/resume 只 publishEvent,于是事件发出来
就掉地上,对内对外都不可见。加进 subTypes 后前端/客户端能看到抢占链。

## 验证

- preempt_logging_test.go 增一条:victim 与入侵者必须是不同来源(qq vs cli),
  且排队输入对排队任务 `canPreempt` 必为假。
- 实测输出含 `cli (L3) preempts task#1 class=queued level=0 (qq)`。
- 全量 `go test ./internal/... ./cmd/...` 与 `go vet ./internal/...` 全绿。
2026-09-19 11:57:50 +08:00
b1ec278136 feat(obs): 抢占日志说出「受害者是谁」——suspend/resume 此前完全不落日志
排查「我的任务怎么被莫名打断了」时撞上的观测缺口。

## 缺口

`executeNewTask` 里挂起、`resumeTask` 里恢复,两处都**只发事件、不写日志**:

    a.sched.suspend(t, f)
    a.publishEvent(events.EventScheduler, map[string]any{"action": "suspend", ...})

于是生产日志里只有两行:`interrupt from X` 与 `LLM request cancelled by
preemption` —— **看不到受害者是谁、被谁挤下去、后来有没有恢复**。后果是实测过的:
按时间先后猜凶手,把时间上相邻的输入误认成抢占者。

## 改动

- `sourceOf(task, frame)`:取可辨识来源(`evt.Source` 优先,回退 OutputChannel,
  自循环任务给 `self:<channel>`)。取 Source 而**不是** OutputChannel:
  前者回答「谁送来的」(qq / homeagent-mail-bridge / timer / child/xxx),
  后者只回答投递到哪个通道;多数场景同名,但因果链上要的是前者。
- `describeTask(task)`:`task#N class=queued|interrupt level=L`。
- `suspendDepth()`:日志专用,走锁而不是让日志点直接摸 `suspendStack`。
- 三个日志点:抢占开始(含 victim)、挂起(含来源与栈深)、恢复。

输出形状:

    [agent] preempt start: task#2 class=interrupt level=4 from cli -> victim task#1 class=queued level=0 (qq)
    [agent] suspend: task#1 class=queued level=0 (qq) yields to an interrupt; suspendStack=0
    [agent] resume: task#1 class=queued level=0 (qq) resumes after the interrupt finished

## 验证

- 新增 preempt_logging_test.go:抢占后栈深 0→1、sourceOf 取到 qq、self/nil 不 panic。
- 实测日志(TestPreempt_HigherPreemptsAndResumes)三条齐全,能一眼看出
  是 `cli` 的 L4 挤掉了 `qq` 的排队任务、随后 qq 恢复。
- `go test ./internal/... ./cmd/...` 全绿。
2026-09-19 11:31:04 +08:00
d202f2ceec feat(ohos): screensue 改用 Web 组件渲染 HTML(RichText 撑不住)
用户实测截图:推送内容把整段 HTML 源码当字符串显示(含 <style>、@keyframes、
内联 <svg>、radial-gradient)。RichText 只认极小标签子集,这些一律不渲染。
用户明确要求「引入 webview」。

## 修法

- 新增 `common/ScreensueHtml.ets`(从 BridgeCaps 抽出:后者加进 HTML 逻辑后
  超 520 行,越了工程「单文件 ≤400 行」的约定;且「screensue 怎么解析/渲染」与
  「设备能力怎么实现」本是两件事)。
- `ScreensuePage.ets`:HTML 走 **Web**,纯文本仍走 Text。
- 加载用 `loadData(base64)`:encoding 非 base64 时按 URL 规则转义,几 KB 的
  完整文档会撞长度/转义问题。自写 `base64Utf8`(UTF-8 手编字节,含代理对合成)
  —— 直接把 UTF-16 码元交给 Base64Helper 会让中文变乱码。
- 非完整文档补一层 shell(meta viewport + 主题前景色),完整文档原样加载。

## 顺带修掉一个真实缺陷(实测发现)

`looksLikeHtml` 旧判据要求「首个非空字符就是 '<'」。而 agent 传参常把整段文档
连引号一起给(`'<html>…'`)——截图里那个孤立的 `'` 就是这么来的,判据因此
**判否并退回纯文本**,所以看到的是源码。改为扫第一个「像标签开头」的 '<'
(跳过引号/前导文字),且只在其后紧跟字母或 '/' 时才算,避免误判 "a < b"。
Node 复刻同一算法验证了 7 个样例(含截图实况、<3 表情、比较符)。

## 安全(我因为引入 WebView 而必须自己把关)

内容来自 agent(第三方)。显式关闭:
`javaScriptAccess(false)` / `fileAccess(false)` / `domStorageAccess(false)` /
`onlineImageAccess(false)` / `zoomAccess(false)`。
★ **javaScriptAccess 的默认值是 true** —— 不显式关掉等于让远端内容在客户端执行脚本。
已实测取证:推入带 `<script>` 与 `<img onerror>` 的页面,屏上稳定显示 `JS-OFF`,
两条执行路径都没跑起来。

## 另一个实测发现的缺陷

`onControllerAttached` 只在挂载时触发一次,而 ScreensuePage 在 `if (visible)`
里常驻 —— 连续两条 screensue 只改 @Prop、组件不重建,Web 一直显示**上一条**
内容(实测:倒计时变成 33s 但画面还是旧 HTML)。改 `@Prop @Watch('onDataChanged')`
显式重载,并记录 attached 状态避免过早 loadData(会抛 17100001)。

## 验证(模拟器真机链路)

把工程内连接指向本机服务、开启「允许 agent 控制本机」授权,经
`device_ctl_cmdrun` → 设备桥 → screensue 推入用户截图里那段原样 HTML:
- 渲染成功:radial-gradient 背景、内联 SVG 兔子、CSS 发光文字、两行文案
  (修复前同一段内容显示为满屏标签源码)
- 连推第二条 → 画面正确刷新为 SECOND PUSH
- JS 探测 → JS-OFF(脚本被拦)

模拟器只能装 unsigned 包(signed 报 READ_PASTEBOARD 授权失败,与既有记录一致)。
2026-09-18 12:01:33 +08:00
895948b24e fix(stop): 配额须计入停在输入 channel 的待处理消息
实测:停止后排队消息仍逐条跑完。原因是 armStop 只数 sched.queue,
而用户按下停止时调度器正忙于当前任务,其余消息大多还没被 pumpInbox
搬进队列、仍停在 inputCh ⇒ queued=0、配额归零。

- IOManager.PendingInputs():暴露 channel 中待处理条数。
- armStop(pending int):queued = len(s.queue) + pending。
- 补 TestStop_ArmCountsPendingChannelInputs 锁死该口径。
2026-09-18 11:39:04 +08:00
698ff7ddd5 fix(stop): 修自伤——interceptLoop 里 takeStop() 被 || 短路提前消费
上一版把 stop 标记在 interceptLoop 里消费掉了一部分:
`if n := armStop(); n > 0 || takeStop() { ... }`,queued=0 时短路到
takeStop(),标记先被吃掉,stepLLM 永远看不到 → 取消后照样重跑一轮。
实测:日志正确打出 stop requested ... queued=0,但生成仍跑到自然结束(5000+ 字全文落库)。

改为只 arm 不 take(takeStop 只由 stepLLM 消费),并补一条**经真实
interceptLoop** 的用例:它必须 a.Start()(第一版测试只调 New(),
interceptLoop 根本没跑,假绿)。已验证该用例在注入此 bug 时失败、修复后通过。
2026-09-18 11:32:20 +08:00
ccc2ac2d4d fix(stop): 停止按钮真正生效——停止 ≠ 空中断;鸿蒙 screensue 支持 HTML
两处鸿蒙端缺陷 + 一个跨端(WebUI/GUI/鸿蒙)的停止语义缺陷。

## 症状(实测取证)

1. **鸿蒙终止按钮按下没反应**。POST /chat/interrupt 带空 body,接口回 200
   `{"status":"interrupted"}`,但 journalctl 零中断日志、生成继续跑到自然结束。
2. **鸿蒙 screensue 不解析 HTML**,把标签当普通字符串显示。

## 根因

停止按钮走的是「空内容中断」,而 interceptLoop 有一行
`if text == "" { continue }` —— 空内容被判为「无事发生」直接丢弃。
所以停止指令从未到达调度器;接口那个 200 是不诚实的。

另查明两条会放大症状的既有问题(停止后仍在跑):
- `chatStreamWithFallback`:流式连接失败时无条件回退非流式 `Chat`。
  上下文已取消时这等于**再发一次完整请求**(停止后模型继续生成)。
- `stepLLM`:`context.Canceled` 一律 `outcomeContinue` 重跑本步。
  这是给「被更高中断抢占」用的(现场要交出去、稍后继续),
  但用户按停止是「不要了」,重跑就是停止没生效。

## 修法(按用户明确的设计)

停止 = ①立即结束当前 LLM 推理(不重试、不恢复);
②对**停止那一刻已排队**的 x 条消息,后续在 pre-action 阶段依次短路。

- scheduler:新增 `armStop`(登记快照配额并返回当时排队深度)/`takeStop`/
  `consumeCancel`。配额取快照值(停止后新到的输入不受影响),
  重复按停止取 max 不累加(两个客户端同时按不该翻倍)。
- `interceptLoop`:读 `stop` 标记。停止时 armStop + cancelCurrentLLM;
  **纯停止不再进中断队列**(旧实现把它当空中断入队,所以停完还会活)。
  带注释的停止(`/stop 换个话题`)仍走中断路径。
- `stepLLM`:取消 + `takeStop()` → 直接 `outcomeDone`(不再重跑)。
- `stepPrepare`:`consumeCancel()` 命中即在 pre-action 短路收尾。
- `chatStreamWithFallback`:以 **ctx.Err()** 为判据拒绝回退(不是「错误是不是
  Canceled」——很多 provider 用 Canceled 表示「不支持流式」,那种必须继续回退,
  否则会把探测误判成取消;这条区分是跑全量测试时才暴露的)。
- WebUI handler / CLI `/stop`:空消息时带 `stop:true`。

## 鸿蒙端

- `BridgeCaps.ets`:新增 `looksLikeHtml`(首字符 '<' + 字母开头标签名,
  避免误判 "<3" 这类文本)、`screensueHtml`、`escapeHtmlText`。
- `ScreensuePage.ets`:HTML 走 **RichText**(只解析 HTML 子集、无脚本无网络),
  纯文本仍走 Text。不用 Web 组件:agent 下发的是第三方内容,
  Web 默认带 javaScriptAccess/fileAccess,等于让远端内容在客户端执行脚本。
  注入主题前景色,避免 RichText 用系统默认色导致深色主题下黑字不可见。
- `ChatSession.ets`:`interruptChat` 改发 `{stop:true}`(含类型声明,
  ArkTS 禁止无类型对象字面量),并在本地即时复位忙态 + 提示「已停止」。

## 验证

- 新增 `stop_semantics_test.go`:停止终结任务不重试(provider 调用次数恒为 1)、
  配额是快照(x 条短路、随后新到的不受影响)、重复 arm 取 max。
- `go test ./internal/... ./cmd/...` 全绿。
- 鸿蒙 HAP 构建通过;unsigned 包已装进模拟器(signed 包受
  READ_PASTEBOARD 授权限制装不上,与既有记录一致)。
2026-09-18 11:26:12 +08:00
831bd2290b fix(ohos): 聊天改用 seq/after 增量轮询,修「不滚动/己方消息不显示/新消息不加载」
jianf 报的三个现象其实同一个根因:WebUI 前端在 commit 9711177 已改为
「暴露数据查询 API + 前端轮询 patch 视图」,聊天记录走 /chat/history?after=<seq>
增量游标 + seq 对账;鸿蒙端一直只做**首屏全量加载**,没跟上这套口径。

1) 页面不加载新的聊天信息(根因)
   鸿蒙只在 aboutToAppear 拉一次 /chat/history?limit=40,之后除了 SSE 就没有
   任何拉取。SSE 只在「本端发起的那一轮」推事件,其他端/其他渠道(QQ、
   WebUI 浏览器)发来的消息永远不会出现在鸿蒙页面上。线上实测:鸿蒙
   IP(61.54.104.206, auth=api-key)最后一次请求停在 9/17 22:34,此后
   只有浏览器 session 在轮询。

2) App 发出的消息不显示
   原来靠 mergeHistoryWithLocal 按「正文内容」去重:本地乐观 user 消息
   与服务端回显内容一致就被判重复丢弃;同一句话发两次同样误删。
   改为按 seq 对账(新增 reconcileServerMsgs,对齐 WebUI applyServerMessages):
   服务端带 seq → 有则原地更新、无则认领本地无 seq 的同类乐观消息;
   旧后端无 seq 才退化为内容比对。

3) 加载完不滚动、停在最新消息处
   @Watch 只在值**变化**时触发,不触发初始值。ChatPage.aboutToAppear 里
   loadHistory() 是异步的,若它在 ChatStream 构造之前就完成,
   requestScroll 递增的 chatScrollRev 就成了「挂载前已发生的变化」——
   onScrollReq 永不被调,于是停在顶部/中间。
   修:ChatStream.aboutToAppear 见已有消息就自己滚一次;scrollToBottom
   的重试从 50/260ms 扩到 50..800ms(长历史布局慢,两次不够),
   并用世代号作废旧一轮定时器,避免与新滚动打架。

配套:
- Model.ChatMessage 加 seq;ChatHistory 解析 seq 与 last_seq(游标缺失时
  回退本页最大 seq,保证不倒退)。
- 新增 pollIncremental():after 增量 + limit=1 尾部探测(工具卡/最终文本是
  原地改写已有 seq,不产生新 seq,只靠 after 拿不到),3s 节奏与 WebUI 一致。
- startPolling 挂在 connect() 而非 loadHistory 末尾:首屏失败也能自愈。
- disconnect() 停轮询。

验证:hvigor assembleHap BUILD SUCCESSFUL;make check-client-versions 一致;
go build/vet/test 全量零失败。
2026-09-18 10:49:30 +08:00
1f5af1dccf feat(cli,ohos): 补齐两处能力缺口——CLI /memory context|tools、鸿蒙 camerasue 录像回传
核对「CLI 与 WebUI 插件能力对齐」时发现两个此前遗漏的缺口,一并补齐。

1) CLI /memory 缺 context 与 tools(internal/plugins/cli/plugin.go)
   WebUI 有 GET /api/v1/memory/context 与 /api/v1/memory/tools,CLI 只有
   query/graph/text。IndexerAPI 本就对内部插件开放(BuildContext/
   FormatContext/GetToolDefinitions/BuildToolPrompt),不是 SDK 缺口。
   补上后与 WebUI 同源:context 打印「实际会注入什么上下文」,
   tools 打印工具定义 + 工具提示词。
   waiter 同步接上两条远端路由与 help 文案。

2) 鸿蒙 camerasue 录像(BridgeCaps/BridgeRouter/DeviceBridge.ets)
   此前 `camerasue <N秒>` 直接返回「暂不支持录像回传」。查 SDK 后发现
   cameraPicker 本身就有 PickerMediaType.VIDEO 与 PickerProfile.videoDuration
   —— 录像完全可行,只是回传通道没接。
   现改为:VIDEO 模式取回 mp4,经 DeviceBridge.sendDataChunked 按
   cmd_data_start/分块/cmd_data_end 回传(与 GUI/CLI 录像路径一致),
   网关聚合后落盘成文件、agent 拿路径;照片仍走小体积 base64 内联。
   上限 64MB、时长 1~300s,超限明确报错而不是把 WS/上下文撑爆。

   依赖方向处理:BridgeCaps 需要「往本请求回传字节」,但 DeviceBridge 为取
   CapResult 已 import BridgeCaps,反向 import 会成环。改为 BridgeRouter
   注入 DataChunkSender 回调(它同时持有 deviceBridge 与 reqId),
   BridgeCaps 不碰 socket。新增 CapResult.chunked 标记「结果已由能力分块
   发完」,DeviceBridge 据此不再回 cmd_result,避免网关把已完成请求与后续
   分块错配。

验证:hvigor assembleHap BUILD SUCCESSFUL(ArkTS 编译通过,改动文件零告警);
make check-client-versions 一致;go vet 干净;全量 go test ./internal/... ./cmd/... 零失败。
2026-09-18 10:04:53 +08:00
9de3b365a6 fix(agentcli): 修 4 个真实缺陷——停机死锁、超时泄漏、僵尸堆积、孙进程逃逸
jianf 提示 agentcli 可能有问题,系统性审了一遍(含 -race 与线上实证),
确认并修复 4 个互相叠加的真实缺陷,每个都配了「去掉修复即失败」的回归测试。

1) 停机/热重载死锁(plugin_stop_test.go)
   Stop() 先 p.wg.Wait() 再 Close 终端,而 readLoop 自己也记在 p.wg 上、
   只监 t.stopCh 不监 p.stopCh。只要有一个终端开着,wg.Wait() 就永不返回。
   后果:插件卸载/热重载(StopAndUnload/ReloadOne)与停机全挂死,且
   registry 持锁时是整个内核一起挂。
   修:先关活跃终端(move 出 map 后在锁外 Close),再 wg.Wait();
   readLoop 顶部加 p.stopCh 探测;Stop() 用 sync.Once 保证幂等。

2) 终端超时后资源全泄漏(plugin_lifecycle_test.go)
   readLoop 的 IsExpired 分支只 delete(sessions) 后 return,既不 Kill 也不
   Close。终端已被移出 sessions,cleanupLoop 也再看不到它,进程/PTY fd/
   reader 协程无人回收。实测:timeout=1s 的 sleep 300 超时后进程仍在跑。
   修:readLoop 加 defer releaseResources(),保证「只要退出就释放」。

3) 子进程从不回收 → <defunct> 僵尸堆积(pty_linux.go + plugin_lifecycle_test.go)
   newCommandPty 只 Start 从不 Wait。线上实测 homed 名下已有一个
   [sh] <defunct> 僵尸子进程。
   修:linuxPty 加 Wait()(sync.Once 保证只 Wait 一次),
   releaseResources 通过可选接口 Wait() error 调用(Windows ConPTY 不实现则跳过)。

4) Kill 只杀直接子进程,孙进程逃逸(pty_linux.go + plugin_lifecycle_test.go)
   newCommandPty 用 Setsid,sh 是新进程组领头,真正的命令(sleep/vim)是
   其孙进程且同组。只 Kill(sh) 会留下孤儿继续跑。实测:`sleep 300; echo done`
   只杀 leader 后 sleep 仍在(被 init 收养)。
   修:改为 syscall.Kill(-pid, SIGKILL) 杀整个进程组,失败再回落单进程 Kill。

测试设计要点:回归用例必须让「sh 保留为父进程 + 孙进程显式 trap "" HUP」,
否则单个 sleep 会被 sh exec 掉、关 PTY 的 SIGHUP 又会顺手带走孙进程,
两个缺陷都测不出来(这两种情况都实际踩过并修正了用例)。

全量 go test ./internal/... ./cmd/... 通过,agentcli 单包 -race 通过。
2026-09-17 20:24:03 +08:00
ec13eb391a fix(agentcli): 终端退出前补推残留输出,短命令输出不再丢失
线上验证「内核开、两个插件接」时发现的真实缺陷:`echo`、`ls` 这类在首个
200ms ticker 之前就结束的短命令,readLoop 走到 `!terminalRunning(t)` 分支
直接 return,残留在 stream 里的输出从未 flush。

症状:输出只留在 session.buf 里——agent 用 terminal_read 能看到,但
terminal_output 事件永远发不出去,于是内核权威视图(以及 WebUI/CLI 的
/terminals)的 output 恒为空。实测 term_2(echo HELLO_KERNEL_REGISTRY)
在 /terminals 里 output="" 而 agent 同期 terminal_read 拿到了正文。

修法:
- 抽出 flushTermStream(s, t),ticker 与所有退出路径共用同一条推送路径
  (避免以后再出现「某条退出路径忘了 flush」)。
- readLoop 顶部加 defer:defer flushTermStream 后于 defer emitTermState
  声明 → LIFO 下先 flush 再报停止,保证「最后一段输出」先于 running=false
  到达订阅者。

测试:plugin_flush_test.go 新增 TestReadLoopFlushesOutputOnExit——走
EventBus 捕获事件,推入输出后立即让进程退出(远早于 ticker),断言输出
已补推且末态 running=false。已验证去掉修复即 FAIL、加回即 PASS。

注:handleRead(clear=true) 会主动 Reset stream(避免与读取结果重复),
属既有设计;本修复针对的是「未被读取就退出」的路径。
2026-09-17 20:00:47 +08:00
e70d2171ee refactor(terminal): 内核开终端/命令历史权威视图,WebUI 与 CLI 都改接内核
按「内核开,两个插件接」重构终端与命令历史的数据归属。

背景:此前 WebUI 与 CLI 各订 EventToolCall/EventTerminalOutput 攅一份状态,
同一件事两份推导,还各自踩过同一个坑——工具 result 是 Go 的 map 文本
(map[cols:80 ... id:term_2 ...]),断言成 map[string]interface{} 永远失败,
terminal_create 的 id 回填不生效,/terminals 因此恒空(WebUI 也一样)。
实测确认:WebUI 自己的 /api/v1/terminals 与 /api/v1/cmd/history 同样是空的。

内核开(权威唯一真相):
- internal/agent/core/terminal_registry.go:TerminalRegistry 归并两类事件——
  EventToolCall(terminal_create/close、cmd_run,id/command 从 args 或 Go map
  文本回填)与 EventTerminalOutput(agentcli 生命周期 + 输出,含 64KB 缓冲上限、
  100 条命令历史、50 个终端上限)。
- internal/sdk/terminal.go:新增 TerminalAPI(ListTerminals/CmdHistory)与
  TerminalStatus/CmdExecStatus DTO。**不塞进 KernelStatus**:那是全量快照,
  前端每 3 秒轮询 /kernel,背上每终端最多 64KB 输出会让轮询成本爆炸;
  终端输出是按需拉取的明细,另开接口。
- Agent 订阅自己的事件总线(subscribeTerminalRegistry),且**只根 agent 建**
  (驻留子共用同一总线,每个子都建会 N+1 份重复记账)。
- SDKConfig/Registry/bootstrap 接线:pluginReg.SetTerminalAPI(agent)。

生产者补全(agentcli):终端无输出时 ticker 不发事件,内核就无从知道终端
存在。新增 emitTermState,在 handleCreate/handleClose/readLoop 退出(超时/
进程结束/读取错误/stopCh)显式上报 running 状态,并给输出事件补 command 字段。
handleClose 改为接收 *sdk.PluginSDK 以便上报。

两个插件接(消费方):
- WebUI:删掉本地 termStates/cmdHistory/subscribeTerminalStream/handleToolEvent
  及不再使用的 getStr;/terminals 与 /cmd/history 直接读 s.Terminal()。
- CLI:删掉上一轮刚加的 subscribeToolEvents 与 cliTermState/cliCmdExec;
  /terminals 与 /cmd/history 直接读 s.Terminal()。两条路(local/remote)都通。

测试:新增 terminal_registry_test.go,锁死 Go map 文本解析(旧缺陷根因)、
生命周期、CLI 直调路径(无 EventToolCall 仅凭 output 事件建条目)、历史与
终端数量上限。全量 go test ./internal/... ./cmd/... 通过。
2026-09-17 18:56:15 +08:00
3cce605722 feat(cli): /terminals、/cmd/history、/terminal 对齐 WebUI(事件面 + ToolAPI,无需新接口)
去看了一遍源码,纠正上轮判断:终端与命令历史也不是 WebUI 插件私有。
- 终端会话:agentcli 插件持有,发 EventTerminalOutput;WebUI 只是订阅该事件
  自己攒视图。命令历史:WebUI 订阅 EventToolCall 的 cmd_run 攒的。
- 于是 CLI 插件订阅同样两个事件即可同口径:/terminals、/cmd/history。
- 开/写/读/关终端:SDK 的 ToolAPI.ExecuteTool 已允许跨插件调用工具,
  CLI 直接调 agentcli 的 terminal_create/write/read/close,新增 /terminal 子命令。

waiter 侧同步:/terminals、/cmd/history 两条路(local/remote)都接;/terminal
仅在 local 可用(远端 WebUI 无对应 REST 端点,明确提示而不是当聊天发出去)。
2026-09-15 15:31:32 +08:00
0227fc2d4d feat(cli): /persona 与 /agents 对齐 WebUI(复用已开放的 SDK 面)
- /persona:读写 core.agent.personal_prompt / core.internal.persona_initialized;
  插件 SDK 的 Settings() 满足 internal/config.PersonaKV,与 WebUI 同一实现。
  GET 等价返回 initialized/current_prompt/file_override;/persona set <mode> [内容] 写。
- /agents:改用 supervisor.ListAgents()(WebUI /agents 同源),此前只回一个
  agent_id、驻留子信息全丢。
- waiter 侧 /persona 在 local/remote 两条路都接上,/help 补齐。
2026-09-15 15:25:20 +08:00
91c25fa536 feat(cli): /runtime 接上(runtime 本就经 KernelStatus 对内部插件开放)
纠正上一轮的判断:runtime 不是“SDK 未暴露”。s.Status().GetKernelStatus()
里的 Scheduler / Residents / Channels / InputChannels 就是 WebUI /runtime
的数据源,内部插件同样拿得到——CLI 只是漏接了这条命令。

- CLI 插件新增 /runtime,输出与 GET /api/v1/runtime 同口径。
- waiter 侧 /runtime 在 local(发 CLI 插件)与 remote(走 REST)两条路都接上,/help 补齐。
2026-09-15 14:29:29 +08:00
bcaa8f3f31 feat(cli): /plugin install 真正可用(直连 pluginmgr 回环端点,与 WebUI 同实现)
原来 CLI 的 /plugin install 只打印“请去 WebUI”。插件安装逻辑在 pluginmgr
插件里(回环 HTTP,默认 127.0.0.1:9876,无鉴权),WebUI 也是转发到它;
CLI 插件改为直连同一端点,能力对齐。
2026-09-15 12:17:34 +08:00
5333a33e20 feat(cli): CLI 插件能力对齐 WebUI(memory/knowledge/config/tracker/adapters/network)
原来 CLI 插件只覆盖 WebUI 的一小部分:/memory 只有 query、/knowledge 只有
list、没有 config/tracker/adapters/network,结构化输出还各拼一套文本格式。

按 WebUI 的 REST 面对齐:
- /memory query|graph|text [n]     (对应 /memory、/memory/graph、/memory/text)
- /knowledge | delete <name> | stats(对应 GET/DELETE /knowledge)
- /config                          (对应 GET /config)
- /tracker | rollback              (对应 GET /tracker、POST /tracker/rollback)
- /adapters | remove <name>        (对应 GET/DELETE /adapters)
- /network                         (对应 GET /network)
- 统一 writeJSONContent:结构化数据一律缩进 JSON,与 WebUI 同口径。

waiter 侧同步:把上述命令在 local(发 CLI 插件)与 remote(走 REST)两条路
都接上,/help 补齐;两条路语义一致。
2026-09-15 12:14:25 +08:00
95b1950bb3 fix(ohos): 历史刷新不再整表替换,避免刚发出的消息凭空消失
sync_required 触发的 reloadHistory 会与刚发出的 POST 竞争:若历史快照
里还没有这条 user 消息,整表替换会让它消失(“客户端侧发出的消息不显示”)。
改为合并:历史为权威,但保留本地两类消息追加在末尾——
  - user 且 source 为空(乐观消息)且内容未出现在历史里;
  - assistant 且 !isFinal(仍在流式输出)。
2026-09-15 12:09:58 +08:00
307a6faee7 fix(ohos): 设置页插件/工具数不显示 + 聊天自动滚底时机
设置页计数(实测:后端返回 plugins=35/tools=260,卡片却一直显示 '-'):
- 根因是 ArkUI 的 @Builder 按值传参是“快照”语义——父组件因
  @StorageProp 变化重渲染时不会用新值重跑 builder,数值永远停在
  首次渲染的 0。把 KPI 小卡从 @Builder 方法改为独立 @Component
  (@Prop 单向下发),父组件重渲染时子组件拿到新值并重绘。
- 已上模拟器验证:设置页显示 插件 35 / 工具 260。

聊天自动滚动:
- scrollToBottom 原来只在 50ms 后滚一次;长历史/长思考卡的布局在
  消息数组更新后的若干帧才稳定,一次滚动会落在“当时”的底部,
  最后一条被输入区挡住。改为 50ms 与 260ms 各滚一次,480ms 后
  恢复正常滚动态。
2026-09-15 11:56:18 +08:00
baddaf387e merge: 回流场景式关联召回 + 记忆整备 + 客户端修复(feature/recall-policy)
- 场景式关联召回:声明/涌现双通道、场面指纹聚类、场景前缀/相似度召回
- 记忆整备:doc→graph 闸门、噪音/孤立清理、关系去重、原句回显、memoryPass 收敛
- 本轮修复:衰减真半衰期、索引同步基线、Ensence 死参/死分支、冗余索引
- 客户端:鸿蒙未连接连接入口 + camerasue;waiter 斜杠命令本地语义修复
- 版本:GUI/鸿蒙/waiter 与内核统一 1.4.0(make check-client-versions)
- 客户端版本同步文档 §四
2026-09-15 11:13:04 +08:00
15497ee0a2 feat(ohos+waiter): 补 camerasue 能力;修 waiter 本地斜杠命令被当聊天文本
ohos camerasue:
- LOCAL_DEVICE_CAPS 增 camerasue;BridgeRouter 增 camerasue 路由。
- 实现走系统相机选择器 cameraPicker(三方应用无法无界面直驱摄像头),
  结果落应用沙箱(saveUri=filesDir),不写系统媒体库、不需 READ_IMAGEVIDEO。
- 录像(camerasue <N秒>)明确返回“暂不支持录像回传”,而不是回一个超长
  base64 撑爆上下文;二进制分块回传待接线。

waiter 本地/远端命令语义统一:
- 修 bug:/settings、/settings set、/plugin install/remove/info、
  /memory query、/knowledge delete 本地分支发的是 cmd[1:](丢掉前导 /),
  于是 CLI 插件不认、被当成聊天文本丢给 LLM。改为原样发(保留 /)。
- 补 /stop、/interrupt:/help 一直写着但 handleBuiltin 没实现,会落到
  “当普通消息发给 Agent”。远端走 POST /chat/interrupt,本地交给 CLI 插件。
- 补 /plugin disable|enable:远端插件管理 REST 动作,本地 CLI 插件。
- /help 文案改为“local 与 remote 行为一致”并列出新命令。
2026-09-15 11:12:27 +08:00
c151d391ee docs(release): §四 补客户端版本必须与内核同步 + make 门禁 2026-09-15 11:04:31 +08:00
065732f42e chore(version): 客户端版本与内核对齐(唯一事实源 internal/meta.Version)
此前三份版本号互不相干:内核 1.4.0、GUI 1.0.0、鸿蒙 1.1.1。手工各改各的
必然漂移,所以把「对齐」做成机械动作而不是约定:

- deploy/scripts/sync-client-versions.sh:从 internal/meta.Version 读版本,
  同步 cmd/gui/package.json 与鸿蒙 AppScope/app.json5(versionName +
  versionCode=X*1e6+Y*1e3+Z);--check 给 CI/Makefile 做漂移门禁。
- Makefile 新增 sync-client-versions / check-client-versions;build-cli 也注入
  LDFLAGS,waiter 与 homed 同版本。
- 鸿蒙:新增 common/AppVersion.ets,从 bundleManager 读安装包 versionName,
  BridgeProtocol/BridgeCaps 里两处硬编码 '1.1.1' 改为读它——版本只剩
  app.json5 一份,杜绝第二真相。
- waiter:`-version` 打印版本,启动横幅与设备桥 hello 的 version 字段
  直接引用 internal/meta,与内核天然同源。

对齐后:GUI 1.4.0 / 鸿蒙 1.4.0(1004000) / waiter 1.4.0 / 内核 1.4.0。
2026-09-15 11:03:26 +08:00
a9ad97240b fix(ohos): 未连接后端时给出不可错过的连接入口
问题:全新安装(未配置后端)时,聊天页只有空列表+输入框,用户找不到
任何连后端的入口;设置页的连接入口在列表里也容易被略过。

改动:
- 聊天空态按连接状态分流:未连接显示「尚未连接后端服务」+「去设置连接」
  按钮;已连接显示「开始新的对话」。
- 跨页信号(AppStorage:K_HAS_CONN / K_REQUESTED_TAB / K_SETTINGS_SUB):
  按钮 → Index 切到设置 Tab → SettingsPage 直接打开「后端连接」二级页。
- 设置页在未连接时主动把连接表单推到面前:窄屏 onNavigationModeChange(Stack)
  直接 push,宽屏右栏默认页从「运行状态」改为「后端连接」。
- 连接增删改切后广播 K_HAS_CONN,聊天空态即时切换文案与入口。

已在手机(窄屏)与折叠展开(宽屏)模拟器验证:空态按钮可达、点击后
落到带「+ 添加」的连接表单;冷启动点设置 Tab 亦自动打开连接页。
2026-09-15 10:52:48 +08:00
acc94723fd fix(memory): 打通场景/索引/召回残余矛盾点,清理死代码与冗余索引
- DecaySceneRefs 真半衰期:新增 scene_refs.decayed_at 作计时起点,
  每个引用至多每 halfLife 衰减一次。此前只按 created_at 判龄 + 每次
  心跳对半砍,30 天阈值配 60 分钟心跳会在几小时内清空老关联(不是半
  衰期是骤死);时间基准改走 SQLite datetime('now'),不再与 Go 本地
  时间混用。
- Indexer.syncIfStale 基线口径与 Sync 对齐(min(实体数, 全量召回上限)):
  实体数超过上限时原实现永远不相等,每 retrainInterval 全量重训一次。
- EnsureScene 去掉从不使用的 Situation 参数;修正 EnterSceneWithHint /
  resolveTurnScenes / 测试里「声明场景会学整轮指纹」的过时注释(实际
  刻意不学,否则会吃死被动路)。
- SituationFeature.Weight 补 peer_group → wFeatPeer:此前落到 default
  话题级 0.4,群聊身份被降级成软信号。
- RecallBySituation 注释改为与实现一致(相似度只决定命中哪些场景,
  不参与每条关系排序)。
- 移除只被测试使用的 EmergentScenes(SceneStats 已含 origin/strength/
  features,完全覆盖)。
- 清理与 UNIQUE 隐含索引重复的 idx_entity_name / idx_sentences_text。
- 新增 TestSyncIfStaleBaseline / TestPeerGroupWeight,衰减测试补「同一
  半衰期内不重复衰减」用例。

go build/vet 干净,internal/... 全绿。
2026-09-15 10:20:40 +08:00
49695c38f3 feat(memory): 场景双通道——主动声明与被动涌现并存,且互不吞噬
按「声明式的也要支持,相当于主动被动两条路」落实。此前两者只是恰好并存,
没有边界,实测会互相吃掉(下面的坑就是)。

- Triple.Scenes []string(多值):一轮写下的记忆**两条路都挂**。
  只挂一条会丢东西——只挂声明则细粒度唤起丢失,只挂涌现则首次交互
  (场景还没长出来)没有兜底。单值 Scene 保留兼容。
- TurnScene:Primary 用于写(优先涌现场景,首次退到声明场景兜底),
  Keys 是两条路的并集,用于召回(声明+涌动的场景一起进 RecallByScene)。
- EnterSceneWithHint:主动路 EnsureScene(声明即建场景,不等第二次),
  被动路 EnterScene(指纹聚类)。写侧由 executeToolCall 把本轮场景集合
  传给 memory_commit,模型不需要知道"场景"这回事。

踩到并修掉的坑(两条路互相吞噬):
  最初让声明场景也吸收**整轮指纹**,于是 chan:qq 的相似度永远是 1.0,
  把后续所有同类轮次全部吃掉 → 被动路再也长不出更细的场面,
  实测 turn2.Emergent=true 但 Primary 仍是 chan:qq、没有 auto: 场景。
  修法:给场景加 origin(declared/emergent):
  - 被动聚类只认 origin='emergent' 的场景(声明场景不进相似度空间);
  - 声明场景的特征**只从键自身解析**(chan:qq/peer:group_1 → {chan:qq, peer:group_1}),
    白名单 kind(chan/peer/peer_group/tool/topic/part),不猜——
    「老大2026-09-04_12:27_qq私聊图片」里的 12:27 也是 kind:value 形态,
    放进特征空间就是往相似度里灌垃圾(有测试钉住)。
  - 声明路的泛化靠**层级键前缀**(chan:qq 覆盖 chan:qq/peer:x),机制各归各。
- memgc -scene-stats 增加 [declared|emergent] 与 strength/features 两栏,
  可直接观察两条路各自在长什么。

新增/改写用例:
- TestDeclaredAndEmergentBothLearn:首次交互兜底到声明场景 → 第 2 轮长出
  细粒度涌现场景且**优先用于写入** → 声明场景不进相似度空间(防止压死被动路)
  但仍走声明键取回 → 两条路都进召回集合 → 声明键特征解析与白名单。
- TestEffectiveScenes:多值+单值合并去重保序。

go build/vet 干净,go test -count=1 ./... 全绿。
2026-09-15 09:37:29 +08:00
bb7e7979ae fix(memory): SceneStats 的 strength/features 不再说谎
- 旧行经 ALTER 加列后 strength 为 NULL,直接 SELECT 会显示成 0(实际是 1 次);
  改为 COALESCE(strength,1),并补上 features 计数(场景长出了几个特征)。
- 两栏一起看才能判断「场景是不是真在涌现」,而不是被一次性写出来的。
2026-09-15 09:29:46 +08:00
d4f9a12db0 feat(memory): 场景从「声明」改为「涌现」——场面指纹自己长成场景
上一版场景是声明/派生的:调用方写 scene="chan:qq",或由通道机械派生。
那不是涌现,是贴标签——标签谁定、怎么定全靠人。按「像人一样:干了什么事,
后续类似场面自动唤起对应记忆」的要求重做。

机制(全部取自运行时可观察量,无需模型配合、无需人工标注):

- **场面指纹 Situation**:每轮采集 `chan:xx / peer:xx / peer_group:xx /
  tool:xx / topic:xx / part:xx`。权重按种类:通道与对象最强(1.0),
  工具次之(0.8),话题是软信号(0.4),时段最弱(0.2)。
- **归属判定用加权 Jaccard**(不是字符串相等):共享特征权重和 / 并集权重和。
  加权是必须的——`chan:qq` 与 `topic:排班` 的证据力差 2.5 倍,不加权会让
  一次偶然的话题重合把两个不同场面并成一个。
- **涌现**:同类指纹重复到 minSceneEvidence=2 次才长出场景
  (首次只登记 situation_evidence 足迹)。一次性的交互不是「场面」,
  给它建场景会让库被一次性事件撑满、之后每次路过都召回一堆只发生过一次的事。
- **强化**:场景每次重现 strength+1、并入新特征。
- **唤起**:RecallBySituation 按**相似度**取回(阈值 0.35,比归属阈值 0.5 低
  ——想不起来是损失,多想起一条只是多几行上下文),与措辞无关。
- **遗忘**:DecaySceneRefs 按半衰期让久未重现的关联淡出,低于 floor 直接删;
  已接进 archive 心跳(半衰期 30 天,比「这个月没做过这类事」更久)。

三个必须讲清的边界:
1. 一轮只解析一次场景(TaskFrame 缓存)——多解析一次就多记一次强度,
   「工具调得多」会被误读成「这个场面更常出现」。
2. 声明与涌现**并存**:声明是「我知道这是哪个场面」(插件注入点最清楚),
   涌现是「这轮看起来像哪个场面」。两者都进召回。
3. 记忆挂载全自动:memory_commit 没写 scene 时落到本轮涌现场景,
   模型不需要知道场景这回事。

验证:go build/vet 干净,go test -count=1 ./... 全绿。
新增用例(核心证据):
- TestSceneEmergesFromRepetition:首次不建场景 → 第 2 次同类场面长出场景 →
  同场面**不同话题**仍并入同一场景 → 换通道的场面自己长出独立场景(共 2 个)→
  强度随重现增长、特征多条。全程没有任何人声明过场景键。
- TestSceneRecallsBySituationNotWording:场面里写下的规则,换措辞后仍被
  自动唤起(含原句),无关场面不唤起。
- TestSceneRefDecay:一个半衰期权重减半、第二个半衰期低于 floor 被清掉,
  仍在重现的场景不受影响。
- TestSituationFeaturesFor:指纹维度齐全、归一化、数值 group_id 转换、nil 安全。
2026-09-15 09:27:39 +08:00
b7e47a1b1f feat(rel): 文档层接入场景(document 节点挂场景)
场景贯穿流水线的 doc 层补完:
- 新增 TagSceneDocument,linkBlocksToDocument 里建文档节点时一并挂场景;
- RecallByScene 返回该场景下的文档 id(可枚举「这个场面有哪些文档」);
- 文档场景由**来源派生**(chan:<source>),不存冗余 Doc.Scene 字段——
  存一份会随来源改名而说谎,是同一事实的第二份真相。

go build/vet 干净,go test -count=1 ./internal/memory/ ./internal/agent/core/ 全绿。
2026-09-15 09:16:22 +08:00
9d45cd0277 fix(rel): 场景贯穿流水线到块层 + 编辑不再丢置信度/场景 + 构建默认带 onnxruntime
三件事,前两件是上一轮热部署暴露/遗留的真缺陷。

1) 热部署差点静默降级(已修)
   `make build` 之前**不带任何 tags**,而发行构建(deploy/packaging/build.sh)
   默认 HOMED_TAGS=onnxruntime,package-linux.sh 还会直接拒收非 onnxruntime 二进制。
   实测差异:33MB vs 84MB;启动日志里
   「multimodal space active: provider=chineseclip dim=512」整行消失、
   少加载一个插件(chinese-clip/qwen3vl provider 降级)、
   静态词向量退回 fallback。即「随手 make build」与「发行构建」不是同一个东西,
   而部署时无从察觉。
   修:Makefile 的 build 默认 HOMED_TAGS ?= onnxruntime(与打包脚本一致),
   构建后自动校验二进制里有没有 onnxruntime,缺了就打 WARN。
   生产已按此重新构建部署(v1.4.0+hotfix.d98bf51,已核实 provider 行回归)。

2) memory_edit 每跑一次就静默降级一次(新)
   memory_edit 是「按包含匹配 Purge + 写新三元组」,中间那一步把旧关系的
   置信度、原句、**场景引用**全丢了:置信度被重置成默认 1.0,场景钉死的记忆
   被打散成无场景。而关系复审心跳(reviewLoop)走的正是这条路——每轮复审都
   在无声地削记忆质量。
   修:编辑前用 FindRelations 精确取回旧关系,把置信度/原句/场景带到新三元组;
   新增 ScenesOfRelation。Purge(hard/soft)与 PurgeNoise/PurgeOrphans 之后
   统一清理悬空 scene_refs,SceneStats 不再说谎。

3) 场景贯穿流水线到块层(按「rel 应贯穿整条流水线」的设计)
   此前场景只到 relation/entity:块(L0/L3 一等记忆块)没有场景,于是
   「那场 QQ 对话里发过来的那张图」在场面重现时永远取不回来。
   - MemoryBlock.Scene + memory_blocks.scene 列(幂等 ALTER 迁移)。
   - scene_refs 增加 ref_text 承载字符串主键(块/文档 id 不是数值)。
     **不能只 ALTER ADD COLUMN**:唯一约束要从 (scene_id,kind,ref_id) 变成
     含 ref_text 的四元组,而 ALTER 改不了约束——旧约束会让「同场景第 2 个块」
     直接冲突(只在多块场景暴露)。改为按列探测后整表重建并搬运旧数据。
   - PutMemoryBlocks 同事务挂 scene_refs(kind='block');无场景重写不覆盖已有场景
     (否则一次无场景重写就静默抹掉挂载)。
   - RecallByScene 返回块;FormatContext 增「场景素材」段(模态 + 文本/短 digest),
     上限 3 条。
   - 生产者接线:attachBlocksToSentence 让块继承承载它的三元组的场景;
     linkBlocksToDocument 让文档的块继承文档来源场景(QQ 归档的图挂 chan:qq)。

验证:go build/vet 干净,go test -count=1 ./... 全绿。
新增用例:场景块(取回/同场景多块/无场景重写不抹场景/悬空引用清理)、
**旧表结构迁移**(降级成旧 scene_refs 后重开,旧数据保留且多块可写)、
场景素材注入、FindRelations+ScenesOfRelation 编辑搬运闭环。

生产:已重建(-tags onnxruntime)并原子替换 /usr/local/bin/homed + 重启,
35 插件全加载、panic/fatal=0、chineseclip 空间 active。
2026-09-15 09:03:36 +08:00
d98bf512e1 feat(memory): 场景式关联召回——给记忆节点赋场景引用,场面重现即取回
背景(实测):带条件的记忆召不回来。生产库里明明有
「QQ回复禁用Markdown格式 --规定--> 纯文本不用Markdown」「老大 --偏好--> 同左」,
但输入「QQ回复格式」时命中 148 个实体、规则排第 32,注入只取前 5——规则根本没进去;
输入「在吗」这种零内容词的短消息,向量路反而灌进 17 个毫不相关的实体。

根因:词法/向量召回都建立在「字面或语义相似」上,而条件式记忆(在什么场合该怎么做)
约束的是**场面**不是话题。用户措辞不重合时它天然召不回;措辞太宽("QQ")时又被同形
命中淹没。另一处:自动注入只给实体名索引,而规则本体长在关系上(relation_type + object),
即使命中名字也拿不到「纯文本不用Markdown」这句正文。

改动:把「触发条件」升成一等索引维度。

- schema:新增 scenes(key) + scene_refs(scene_id, kind, ref_id, weight),
  kind ∈ relation|entity。刻意不建外键:节点可能先于引用被清理,
  悬空引用由读取侧 JOIN 过滤,级联删除会把清理变成跨表事务。
- 场景键是分层字符串(`/` 分隔,由宽到窄):chan:qq、chan:qq/peer:group_123、
  tool:qq_get_message。NormalizeSceneKey 归一(小写、空白/标点→_、按 `/` 分层),
  空白不算层级——否则「老大2026-09-04 12:27 QQ私聊图片」这种来源名会被拆成伪层级。
- 写入即挂场景:Triple 新增 Scene 字段,commit() 在同一事务里把「关系 + 两端实体」
  挂到场景上(同事务是必须的:关系进库但引用丢了 = 这条记忆永远无声地召不回来)。
- 召回:RecallByScene 前缀匹配(chan:qq 取回 chan:qq 及所有更窄场景;用 `/` 兜底
  防止 chan:qq 吞掉 chan:qq2),按 weight(=写入置信度)降序,返回**关系全文 + 原句**。
- 注入:BuildContextInScene 在词法/向量之外叠加场景路,FormatContext 把场景块排在
  最前(规则对行为的约束强于话题相关的实体名),上限 8 条 + 原句截断 60 字;
  场景实体不在【记忆索引】里重复占位。BuildContext(input) 保持原语义(无场景)。
- 当前场景推导:payload.scene 显式声明 > 通道(chan:qq)> 工具(tool:qq_get_message),
  并列命中不取交集。qq 通道本身 RecallPolicy=none(到达的是中断元文本),
  真正召回在 qq_get_message 工具上——现在那一步同时带上 chan:qq 与 tool:qq_get_message。
- 写入侧:memory_commit 新增 scene 参数(逐条 triples[].scene 优先,顶层 scene 作批次默认);
  docToTriples 按文档来源自动带 chan:<source>(QQ 归档的知识天然属于 QQ 场面)。
  不做自动猜测:猜错的场景会把无关记忆钉死,之后每次进入该场面都被注入。
- 存量引导:memgc -tag-scene <键> -entity-glob <GLOB>。用 GLOB 而非 LIKE——
  LIKE 对 ASCII 不区分大小写,`%QQ%` 会把对象带 /home/newqqagent 的路径类记忆
  (生产数据目录、email-mcp、dify-ops 路径…实测 7 条)一起卷进 QQ 场景。
- 清理对齐:PurgeNoise/PurgeOrphans 之后顺带删悬空场景引用,并提供
  PurgeStaleSceneRefs;memgc -scene-stats 看场景规模。

验证:go build/vet 干净,go test -count=1 ./... 全绿。
新增用例:场景键归一(含超长/分层/空白)、写入即挂场景(两端实体进、未标的实体不进)、
前缀语义(含 chan:qq2 反例)、weight 排序与 limit、GLOB 存量引导(dry-run 不写库)、
清理后无悬空引用、场景注入面(关系全文+原句+不在索引重复占位)、
agent 侧 sceneKeysFor 优先级(显式声明 > 通道 > 工具、数组形式、nil 安全)。

生产库实测(先 sqlite3 .backup 到 graph.db.bak-20260915-081043 再写):
把 22 条 QQ 相关关系标进 chan:qq(GLOB *QQ* 19 条 + *qq_* 3 条)。同一批输入前后对比:
- 「在吗」:改前注入 17 个无关实体;改后场景块直接给出「QQ回复禁用Markdown格式
  --规定--> 纯文本不用Markdown」等规则正文(零字面重合也能召回)。
- 「QQ回复格式」:改前规则排第 32 被截掉;改后排在场景块首位。
- 「帮我发个语音」:场景规则置顶,词法路的 qq通道语音输入 等仍在其后。
2026-09-15 08:13:52 +08:00
b37141f3f5 fix(memory): doc→graph 补回常用词闸门 + 存量噪音/孤立节点清理
问题:图记忆里堆着「结果(192) / 什么(59) / 哪个(99) / 待命(176) / 报告(174) /
context_archived(43)」这类节点,mention_count 冲到几百、度数只有 1~2——
占着热实体位、挤满召回预算,却不带任何结构。

根因:这层过滤原本存在,后来被换掉没补回。1cb3e87(NLP 三元组提取系统)
把 doc→graph 从「CutExact 滑窗词链」换成依存句法提取器时,CutExact
(去停用词 324 条 + validEntityName + 去重,注释至今还写着「用于 doc→graph
蒸馏」)失去了唯一生产调用点,只剩 cut_test.go 在调它。此后落库闸门只剩
validEntityName——它挡的是「不像名字的字符串」(2–50 字符、含字母),
完全不挡「像名字的常用词」。

改动:
- 新增 internal/memory/noise.go:IsNoiseEntity 收敛判定(停用词 /
  context_archived / 模板摘要回声),FilterNoiseTriples 给自动填充路用,
  PurgeNoise + PurgeOrphans + cmd/memgc 供存量清理(默认 dry-run)。
  判定刻意保守:只拦三类客观噪音,开放类词(报告/对话/处理)不拦——
  它们挡不挡是领域决策,见函数注释。
- docToTriples 接上闸门(用户点名的「文档常用词」路)。
  对话蒸馏路 extractKeyTriples **不接**:CutExact 当年也只挂 doc→graph,
  且 pipeline_test 明确断言「我 --读书--> 杭州」必须抽出(代词主语是该路
  既定行为),是否拦属行为决策,已在代码注释里写明并留给使用者定夺。
- cut.go 补全封闭类常用词:咱俩/咱们(我们/你们/他们 早有)、任何/此/本/
  其中/以及/那么/这样/那样/一样/还有/还要/只是/老是/全部/所有/有些/一些/
  别的/其他/其余/各自/本身/方位词/部分/方面。
  「不能/不会」试过又撤回:它们是 embedder tokenize 的实词路径,
  加进停用词会让 static_embedder 的领域聚类用例翻转(今天天气句与股票句
  的相似度大小关系反了),属真回归,不留。
- graph.go:CleanupOrphanedSentences 拆出 Locked 版供 PurgeNoise 复用。

验证:go build/vet 干净,go test -count=1 ./... 全绿。
新增用例:IsNoiseEntity 判定表、FilterNoiseTriples 顺序与边界、
PurgeNoise(统计/幂等/dry-run 不写库/不误删仍被媒体块边引用的句子)、
PurgeOrphans(识别/不误判有边实体/幂等)、docToTriples 噪音闸门与
模板锚点不被误杀。

存量清理(生产库 /home/newqqagent/memory/graph.db,先用 sqlite3 .backup 备份
到 graph.db.bak-20260915-073210):
- 噪音实体 29 个 + 其关系 59 条
- 零关系孤立实体 25 个
- 结果:实体 778→724,关系 639→580;sentences 3 条与 block_edges 3 条原样保留
  (媒体块引用不被误删),PRAGMA integrity_check=ok、无悬空关系/块边。
- 运行中的 homed 无需重启:下一个 archive 心跳会 Indexer.Sync 重建实体名向量索引。
2026-09-15 07:47:16 +08:00
94995eaa64 fix(memory): 修图记忆召回的两处能力缺失(关系重复 + 原句不回显)
针对 memory_recall / 自动注入这条图记忆召回链路的实测复核:

- Recall(depth>1) 跨层不去重:每层都用已累积的 entityIDs 查邻接,
  上一层刚产出的关系会在下一层被反复查回并再次 append。实测
  小明→小红 在 depth=2 出现两次,memory_recall 的 10 条关系预算被
  同一句话刷屏、真正的新关系(小红→小刚)被截断。改为按 relation ID
  跨层去重(实体本就已去重)。
- memory_recall 从不回显 sentence_text:工具 schema 明写「填了才能日后
  从图谱回到原文」、Recall 也已 JOIN 出句子,但输出只给实体名与关系类型,
  该字段形同虚设。抽出 formatRecallRelations,对非空原句截断 60 字附在
  关系行后;超过 10 条仍截断并提示。

测试:TestRecallWithDepth 增补去重与精确条数断言;
新增 TestFormatRecallRelations_SurfacesSentence / _Truncates。
go build/vet 干净,go test -race ./internal/memory/ ./internal/agent/core/... 全绿。
2026-09-15 06:48:36 +08:00
6afe361804 fix(memory): 记忆层启动接线/并发/落盘一致性整备
按设计方案整顿记忆系统,收敛一批"单测照不出、只在长跑生产里暴露"的缺陷:

- 启动接线:initMemoryStack 残留 `defer distiller.Stop()`,规则蒸馏
  10min 心跳启动即死。改为由调用点 cleanup 停机,并补 Stopped() 探针 +
  TestInitMemoryStackKeepsDistillerRunning / TestStartKeepsLoopRunningUntilStop。
- L0 相关性上下文:SetDenseSpace 注入稠密空间时回填已有事件的稠密向量,
  否则旧事件走稀疏余弦、新事件走稠密余弦,同一次 Prune 里两种尺度混排。
- 文档检索:QueryScored 访问计数从读锁内写移出(-race 竞争),更新后置脏,
  优雅关停可落盘、FindColdDocs 冷度判据跨重启不再失真。
- 蒸馏管线:只 flush 未落盘记录(persisted 标记)、蒸馏成功后从 raw 文件
  删除对应行、原子写文件,修重启重复蒸馏导致 mention_count 膨胀。
- 图库:全量 Recall 加实体上限(内部整备路径,防大图整表进内存);
  ClearSentenceID 补写锁;Commit/upsertEntity 计数语义注释澄清。
- 索引器:recalled 去重集加 FIFO 上限,防长跑进程自动注入越来越沉默。
- 文档/媒体注释修正;README 记忆层流程对齐跨模态召回。

验证:go build ./...、go vet、go test -race
./internal/memory/... ./internal/agent/core/... ./cmd/homed/... 全绿。
2026-09-15 06:32:36 +08:00
3a780384d0 refactor(memory): 裁剪与召回收敛到唯一入口 memoryPass
把「踢出去(prune)」与「取进来(recall)」从两处各写一遍,收敛为
memoryPass(query, trigger, prune, recall) 单一入口,统一:

- 同一份清洗后的 query(避免噪声带偏相关性打分);
- 同一次 token 预算与召回截断;
- 同一条带 trigger 的审计日志(谁、据什么触发了哪种操作)。

落地:
- 新增 memorypass.go:memoryPass + pruneByQuery(原 pruneOnInput 的执行体);
- pruneOnInput 只解析声明,执行委托 memoryPass;
- stepToolAfter 的裁剪/召回改为一次 memoryPass 调用(去掉重复的 topK 逻辑);
- 抽出 recallText,输入侧 buildTaskMemoryContext 与工具侧 recallTextFor 共用;
- 输入侧召回 query 改用 CleanInput(清洗文本),与裁剪侧同一语义;
- QQ qq_get_history 补齐声明 ContextPolicy=prune + RecallPolicy=auto
  (内容类工具:真实聊天正文既当轮用完即裁,又据正文召回)。

测试:新增 memorypass_test.go,锁死 no-op / 两轴同时生效 / 正交不互相触发 /
输入侧用清洗 query。go build/vet 干净,internal/... 全绿,qq 插件模块测试通过。
2026-09-14 23:32:41 +08:00
b792a94b84 feat(memory): 新增可声明的召回轴 RecallPolicy(与 prune 正交)
问题:召回(把 L2/L3 相关记忆注入本轮)此前不可声明、也不受任何 SDK 字段
控制——它只在任务开始时对 f.Input 无条件跑一次。于是 qq_get_message 取回
真实正文后只触发 Prune(裁剪),从不触发召回;而中断通知的 meta 文本反而
会去召回(词不对题,命中一堆泛实体)。

改动:
- SDK 新增 RecallPolicy(none|auto) 轴,落在 InjectOptions / ChannelDef /
  ToolDef 三个声明面,与 ContextPolicy 正交(裁剪 vs 召回)。默认值与
  prune 刻意相反:输入/注入默认 auto(保持既有「每条输入都召回」),
  工具默认 none(工具输出多为噪声,按需声明)。
- 内核:recallDeclared 按 注入点 > 通道 > 默认auto 解析;输入侧用它决定
  是否注入记忆索引;工具侧 ContextPolicy/RecallPolicy 共用同一份清洗后
  query,一次相关性过程分别 prune / recall;召回以 system 消息挂到消息
  末尾(同任务内替换而非累加)。
- 管线:proc RPC(inject/register + 校验)、lua 键、io payload 全量透传。
- QQ 插件:中断与 qq 通道声明 RecallPolicy=none(meta 不是内容);
  qq_get_message 声明 RecallPolicy=auto(取回正文后据正文召回)。

测试:新增 recallpolicy_test.go(core)与 proc 校验用例;
go build ./... 通过,go test ./internal/... 全通过,SDK 模块与 qq 插件测试通过。
2026-09-14 23:14:38 +08:00
29d763e210 merge: 桌面版/鸿蒙端同步阶段管道工具格滚动展示最新一条调用(feature/stage-pipe-tool-cell-clients) 2026-09-14 20:09:57 +08:00
37d6796230 feat(gui+ohos): 同步阶段管道工具格「只滚动展示最新一条调用」
WebUI 已改为工具格只露最新一条。桌面版与鸿蒙端是同一套运行态面板的
镜像,一并跟上,避免三端口径不一致:

- cmd/gui:renderRuntimePanel 工具格只渲染最新条目 + 本轮累计次数;
  overview 是整块 innerHTML 重建,故动画类由 state.toolFlash 单次驱动,
  避免任何重渲染都闪一下。
- cmd/ohos:RuntimePanel 工具格改为 latestEvent() + totalCount(),
  不再 ForEach 追加。已用 hvigor 实测 BUILD SUCCESSFUL。
2026-09-14 20:09:57 +08:00
0493960985 merge: webui 阶段管道工具格改为滚动展示最新一条调用(feature/webui-tool-cell-scroll) 2026-09-14 20:07:33 +08:00
bc32fbbc98 feat(webui): 阶段管道的工具格改为滚动展示最新一条调用
「工具」是循环格:一轮里可能调几十次工具/输出通道。此前每一次都追加成
chip,这一格被撑成一长条,反而看不出「现在在调什么」。改为固定一行的
滚动视口——只留最新一条,右侧给出本轮累计次数;新调用到来时旧条向上
滚出、新条滑入(morph 就地改文本不会重放 CSS 动画,故摘类 + 强制 reflow
+ 重加类)。并给 chip 名称加 .rt-chip-t 承接省略号,窄框不再硬切半截。

配套 TestStagePipelineToolCellShowsLatestOnly 钉住该口径。
2026-09-14 20:07:29 +08:00
f3fa0e8f5b feat(ohos): 运行态面板 —— 阶段管道 + 中断队列(落在设置页二级明细顶部)
接上一条腿:桌面版已同步,这次补鸿蒙端缺的运行态面板。
落点按之前的建议放在「设置 → 运行状态」二级明细页最前:明细卡回答「内核有哪些
东西、多少」,运行态回答「现在在干什么」,后者是进这个页面最先想看的。

## 新增

- `common/StageTrail.ets`:阶段轨迹单例(SSE 驱动)。由 ChatSse 的 stage 分支
  喂入,面板读取。**不并进 StatusStore**:轨迹来自 SSE 流,与 /status、/kernel
  的轮询是两条独立数据源,生命周期与失败模式都不同(SSE 断连不该让状态卡变空,
  状态轮询失败也不该清掉轨迹)。七阶段归并成五格,同阶段同一条累加计数,
  2.5s 无新事件自动回空闲。
- `components/RuntimePanel.ets`:等大表框面板。
  - 四个数字块(排队/中断/栈/子代理)
  - 阶段管道:每格 = 阶段名 + 本阶段本轮事件;当前阶段整框点亮
  - 中断队列:5 格(L4/L3/L2/L1 + 排队),级别色贯穿框头/槽位/描边;
    有积压整框描边点亮;排队队列虚线框区分(另一类别,不是另一优先级)
  - 格槽固定可见:深度为 0 时也有形状,不会剩一片空白

## 改动

- `StatusStore`:新增 `/runtime` 采集与 `RuntimeSnapshot`/`RuntimeQueue`
  (明细与运行态分开取、分开存);失败保留上一次快照,旧后端无此端点时
  面板显示「运行态数据不可用」。
- `ChatSse`:stage 分支先喂轨迹,再管聊天侧角标。
- `SettingsPage`:`stageTrail.init()`。
- `StatusCards`:二级明细顶部渲染 `RuntimePanel()`。

## 关于宽度

模拟器(API 24,1256x2760 ≈ 360vp 宽)上 5 框一行会让「内核独占」这类标签被
挤成省略号,所以按项目已有的 `isWideScreen` 分两支:宽屏 5 框一行,手机 3+2
(补一个占位格保证框宽对齐)。两档都是等大框。

## 验证

- `hvigorw assembleHap` → **BUILD SUCCESSFUL**;`clean` 后全量重建,
  本次新增/改动的 6 个文件 **零 ArkTS 告警**。
- 未上机实测:本机签名 profile 无法授予 `ohos.permission.READ_PASTEBOARD`
  (module.json5 里已有的一项,非本次改动),`hdc install -r` 报
  `error: install failed due to grant request permissions failed`。
  没有为此卸载设备上的应用(会丢用户已存的连接配置),也没有改权限列表
  (属产品决定)。要上机的话,我可以临时去掉那一条权限打个一次性包验证。
2026-09-14 19:05:46 +08:00
2163a7a092 feat(gui+ohos): 同步 WebUI 总览改版 —— 桌面版补运行态面板,两端补内核身份与开源许可
WebUI 那边这几轮改完,桌面 app(Electron)与鸿蒙 app(ArkTS)要跟上。
先摸了底:**两个 app 此前都没有运行态面板**(阶段管道 / 中断队列),
所以这不是"移植",是新做;emoji 图标两端本来就没有,无需处理。

## 桌面 app(cmd/gui/renderer)

1) 运行态面板(新)—— 与 WebUI 同一套设计语言:**等大表框**
   - 数据源 /api/v1/runtime(此前只拉 /status 与 /kernel)。
   - 四个数字块沿用本 app 的 statCard(排队/中断/栈/子代理)。
   - 阶段管道:5 个等大框,框内是本阶段本轮发生的事件 chip;
     当前阶段整框点亮。图标一律内联 SVG(含「工具会循环」标记)。
   - 中断队列:5 个等大框(L4/L3/L2/L1 + 排队)一行排开,
     级别名 16px/800、深度 26px/800、可见格槽(0 时也有形状);
     有积压整框描边点亮;排队队列虚线框区分(另一类别,不是另一优先级)。
   - stage SSE 事件接上轨迹(rtTrailPush,同阶段同一条累加 xN),
     2.5s 无新事件回空闲。
   - 列宽 repeat(auto-fit, minmax(100px,1fr)):窄容器也保证 5 框一行,
     不出「4 个 + 1 个」的孤行。

2) 版本身份(修一个真缺陷)
   旧实现是 `s.version || "0.1.0"`:拿不到数据时**向用户展示一个不存在的
   版本号** 0.1.0。改为取 /kernel 的 build(-ldflags 注入的真实版本/commit),
   并在版本号下补一行「内核名 · commit」。

3) 开源许可卡(新)
   协议标识 + 协议全文 + 源码仓库 + §13 说明;网络条款按标识是否含 AGPL
   决定是否渲染,不硬写协议名。

## 鸿蒙 app(cmd/ohos/HomeAgent)

4) StatusStore 解析 /kernel 的 build:补 内核版本 / Commit / SDK 兼容 /
   构建时间 到「内核」分组;K_VERSION 统一成 v<版本>,新增 K_BUILD 广播
   「内核名 · commit」给摘要卡(版本号本身没有内核身份)。

5) 新增「开源许可」分组:许可协议 / 协议全文 / 源码仓库 / 网络条款说明。

## 验证

- 桌面:共享浏览器加载 renderer(桩掉 preload 桥)后喂真实形状数据渲染 ——
  版本卡 `v1.4.0+hotfix.f89e57a` + `HomeAgent · f89e57a`;管道
  `输入=输入 | 行动=思考 | 工具=qq_get_message x3 qq* | 输出=生成 | 结束=完成`;
  队列 `L4:0 | L3:3 on=3[active] | L2:2 on=2[active] | L1:0 | 排队:2 on=2[active]`;
  许可卡两个链接均为 target=_blank + rel=noopener noreferrer;无 emoji。
  node --check 通过。
- 鸿蒙:/opt/huawei/command-line-tools/bin/hvigorw assembleHap **BUILD SUCCESSFUL**。

## 未做(下一条腿)

鸿蒙端的运行态面板(阶段管道 + 中断队列)**还没有**。它比桌面端贵:
需要新组件(5 框管道 + 5 框队列)、把 /runtime 快照接入 StatusStore,
以及把 SSE 的 stage 事件从 ChatSse 的 sink 引到状态侧——后者是接口改动。
「状态」Tab 此前已被有意删除(并入设置页 + 二级明细),面板落点也要定
(建议放二级明细页顶部)。桌面的实现可直接作参照。
2026-09-14 18:53:25 +08:00
0faf9fb4e8 style(webui): 队列/管道列宽下限收到 100px,消掉「4 个 + 1 个」孤行
118px 时容器 540px(小窗口侧栏展开的宽度)只放得下 4 列,第 5 个框
落到第二行且后面四个位置全空 —— 正是「看着空」的那种观感。
收到 100px 后 540px 也能一行放下 5 个;配套给 .rt-qmeta 加 wrap,
窄框里「登记/抢占」两枚迷你条换行而不是撑破框。

五档实测(1400/1100/900/700/480):1400/1100/900/700 都是 5 框一行
(200/140/100/120px),480 为 3+2;均无横向溢出,框内元素无越界。
2026-09-14 18:45:36 +08:00
f89e57a732 feat(webui): 阶段管道与中断队列统一为等大表框,字体加大加粗
问题:阶段管道是「小圆点 + 一条连接线 + 9px 小字」,中断队列是五行
「名字 | 进度条 | 元数据」的扁条 —— 两块都远小于旁边的 KPI 框,中断队列四级
全为 0 时四行几乎全是空白,既占高度又难看。

改法:两块统一成同一套视觉语言 —— **等大表框**(与 KPI 同一种骨架)。

阶段管道(.rt-pipe-row / .rt-pipe-cell)
- 5 个等大框,框内 = 图标 + 阶段名 + 本阶段本轮发生的事件 chip。
- 阶段名 9px/500 → 13.5px/700;图标 12px → 15px。
- 当前阶段整框点亮(accent 描边 + 淡底 + 内阴影),不再靠一个小圆点表意。
- 删掉圆点、连接线、滑块把手那套已死的 CSS(.rt-pipe-track/.rt-pipe-knob 等)。

中断队列(.rt-queues / .rt-qcell)
- 五行扁条 → 5 个等大框(L4/L3/L2/L1 + 排队),一行排开。
- 框头级别名 16px/800、深度数字 26px/800(原来深度只是行末一个小数字)。
- 级别色同时用在框头、点亮格槽、有积压时的整框描边 —— 一处配色贯穿。
- 排队队列无级别,用虚线框与四级中断区分(另一**类别**,不是另一优先级)。
- 保留可见格槽:0 时也有形状,不会变回一片空白。

列宽自适应:两块共用 repeat(auto-fit, minmax(118px, 1fr)),
118px 而不是 150px 是为了让 640–740px 容器(窄屏侧栏收起后的宽度)也能
5 个框排一行,不出现「4 个 + 1 个」的孤行。chip 补 min-width:0 以免撑破窄框。

顺带清掉一条无用的旧 .rt-chip 规则(与新规则重名且只被阶段事件用到)。

实测(现网 CDP,1400/1100/900/700/480 五档):
- 1400/1100/700px:5 框一行(200px / 140px / 120px);900/480px:换行且框仍等大
- 五档均无横向溢出
- 字号:阶段名 13.5px/700,级别 16px/800,深度 26px/800
- 注入一轮轨迹:输入=输入|行动=思考|工具=qq_get_message x3 qq*|输出=生成|结束=完成
- 注入 L3=3/排队=2:L3 描边 rgba(255,166,87,.55)、框头与点亮槽同为琥珀色;
  排队绿框;空的 L4 保持默认描边(首次读到的默认色是 0.25s 过渡中途,非 bug)
- chip 未溢出所在框;总览/侧栏/顶栏渲染文本无 emoji
2026-09-14 18:38:08 +08:00
37924b295b feat(webui): 总览底部源码区改为独立的「开源许可」框(协议 + 全文 + 源码)
此前总览底部只在 KPI 卡里挂了一行小链接(.ov-foot),既看不出受什么许可
约束,也看不出 AGPL 网络服务场景下的义务。现在单独成一张卡:

  开销许可
    许可协议     AGPL-3.0-only   → GNU 官方全文
    源码仓库     <source_url>    → 仓库
    网络服务条款(§13):把修改后的版本作为网络服务对外提供时,
                        必须向使用者提供取得对应源码的途径。

内核侧(License 是新事实,不能只靠前端写死):
- internal/meta:新增 License(SPDX 标识)与 LicenseURL,都可 -ldflags 覆盖。
  LicenseURL 默认指向 GNU 官方 AGPL-3.0 全文页 —— 与仓库托管方、分支名、
  文件路径都无关,换仓库/换分支不会失效。
- internal/sdk/status.go 的 BuildStatus:新增 License / LicenseURL 两个
  json 字段(additive,旧消费方忽略未知字段即可)。
  ❗注意 internal/sdk 不受公开接口冻结约束(docs/git-branching.md §六),
  本次未触碰 third_party/homeagent-sdk/sdk/。
- internal/agent/core/status.go:从 meta 填充。

前端:
- 骨架里 .ov-foot 换成独立的 <div class="card" id="ov-legal">(放在 KPI 卡之后)。
- 网络条款那一段按许可标识是否含 AGPL 决定是否渲染,不硬写协议名。
- 内容对一次构建是常量,沿用 __html 比对,填一次后不再重建(不引入闪烁)。

验证(现网 1400x920,CDP 实测):
- /api/v1/kernel 的 build 现在带 license="AGPL-3.0-only"、
  license_url="https://www.gnu.org/licenses/agpl-3.0.html"
- 卡片为真框:class=card、border 1px、radius 14px;总览结构 = rt-panel | card | ov-legal
- 两个链接均为真 <a>,target=_blank + rel=noopener noreferrer
- updateOverview() 再跑一次,卡片子节点身份不变(不重建、不闪)
- 回归:KPI 版本副行、阶段管道 5 节点/5 列/6 SVG、队列 5 行×5 格 均正常
- 无横向溢出;总览/侧栏/顶栏渲染文本无 emoji
- go vet 干净;agent/core、plugins/webui、plugins 全量测试通过
2026-09-14 17:48:54 +08:00
bead5746c3 feat(webui): 总览显示内核身份、图标全 SVG 化、队列改格槽、阶段管道下方按阶段列事件
四个问题一起改(都出在总览/内核页的展示层,不动内核逻辑):

1) 内核版本不再"看不见"
   - 36b577b 改图标 KPI 时把 kernel_name 丢了,只剩一个 "v1.4.0",分不清
     是哪个内核、哪次构建。现在 KPI 值给版本号,下面补一行副行
     「HomeAgent · <commit>」(.ov-sub)。
   - 内核页此前**完全没有构建信息**,现在补一张「构建」卡:内核名/内核版本/
     Commit/构建时间/SDK 兼容/源码链接(AGPL §13 的入口页)。

2) 任何位置都不再用 emoji/符号字符充当图标
   - 新增 RT_ICO(纯内联 SVG,24x24 / currentColor),替换:阶段节点的循环
     标记(原 ↻)、轨迹 chip 的工具/输出标记(原 ⚙/⇥)、"立即运行"(原 ⚡)、
     工具卡与思考卡的下拉箭头(原 ▾)。
   - CSS 注释里的同类字符一并去掉。

3) 队列不再"空着只有文字"
   - 原来画的是宽度百分比进度条:深度为 0 时宽度就是 0,五行只剩文字。
     改成 rtSlots 的「车位」式格槽(至少 5 格、最多 16 格,按全场最大深度
     缩放),0 时仍有可见形状,占用多少一眼可数;超出格数时给 +N。
   - 修掉一个真实的 DOM 结构错误:第五条「排队」队列被写在 .rt-levels 闭合
     **之后**,且后面多一个 </div>,多出来的闭合标签会提前关掉祖先节点、
     把整块布局撞歪。现在它回到容器内。

4) 每一步管道的事件显示在管道下方对应阶段列里
   - 原来是一条拍平的 chip 序列,看不出"这件事发生在哪个阶段"。
     现在 .rt-pipe-cols 与上面的阶段节点共用 5 等分栅格,事件按 g(阶段组)
     分列落位;实测列中心与节点中心偏差 ≤ 2px。
   - 轨迹覆盖全部阶段(输入/思考/工具/输出/完成),同阶段重复的同一条
     累加 ×N 而不是刷屏(rtTrailPush)。空列显示一个弱化的「无」。

验证(现网 1400x920,CDP 实测):
- 版本 KPI = v1.4.0+hotfix.0fd4fb1 / HomeAgent · 0fd4fb1;内核页构建卡齐全
- 注入一轮轨迹:col0=输入 col1=思考x2 col2=qq_get_message x3/qq/cmd_run
  col3=生成x2 col4=完成,active 节点=工具,×N 计数正常,3 个 chip SVG
- 队列 L3=3/5、排队=2/5 点亮,L3 取到琥珀色 rgb(255,166,87)
- 页面无横向溢出;总览/侧栏/顶栏/内核页渲染文本无 emoji
- go vet 干净,internal/plugins/webui 测试通过
2026-09-14 17:40:54 +08:00
21db84e8dc fix(webui): 拓扑 +N 提示改用输出带顶部锚点,修提示串行
无输出通道的 agent 那条带上 outTop 在渲染时才确定,而提示行仍在用
循环变量 y(已累加到别的带),所以「+N 更多」会跑到隔壁带上。
改用该带自己的 outTop,并把基线从 +13 收到 +11(紧贴最后一行)。
2026-09-14 17:40:46 +08:00
0fd4fb1f7a fix(webui): 拓扑按实测容器宽布局 + 字号/截断,修间距失衡与文字难读
三处实机问题:
1) viewBox 固定 640 而容器 ~920,浏览器按 'meet' 把内容顶到左上、右侧空出一大片
   —— 观感就是「间距不对」。改为 viewBox 宽 = 实测容器宽、width 用像素值,
   缩放恒为 1(已用 getScreenCTM().a 验证)。
2) 文字全是 9-11px + 低对比度硬编码色(#8b90a5)→ 难读。字号提到 10.5-12.5px,
   fill/font-size 改走 .tp-* 类,颜色交给 --text-primary/--text-muted 主题变量。
3) 列短的一侧原来顶在带上半、节点居中,连线又长又歪;长通道名还会溢出到邻居身上。
   现在两列在带内各自居中、节点块高度参与带高计算(单行带不再把节点名压到下一条带),
   长名按估算宽度截断加 …,完整名放 <title> 悬停可见。
另:rtSpark 用的 _rtEdgeIn/_rtEdgeOut 键与取值方式未变,光点动画照旧。
2026-09-14 16:51:41 +08:00
5ea87a498a chore(vendor): 同步 qq 插件权限身份绑帧修复(sdk cfa72df) 2026-09-14 16:45:17 +08:00
9eebd96ab7 fix(core): 插件拒绝工具时把 ctx.Response 的理由透给模型
before_toolcall 的 ctx.Response 是插件写的**拒绝理由**,但工具结果被写死成
「工具 X 已被插件拒绝」,理由从不到达模型——模型于是不知道能不能重试,
会反复重试被拒的调用。抽出 denialResultText 并在有理由时原样透出。
2026-09-14 16:45:04 +08:00
c252915083 feat(webui): 阶段管道改「循环 + 本轮轨迹」,区分工具/输出调用;再砍总览文字
jianf:阶段管道像无记忆的单向滑块,但一轮里会多次 toolcall、也可能多次输出;
且没区分 output_* 调用与普通工具调用;总览仍有一大坨文字。

- 阶段管道不再是单向滑块:#
  画成 输入 → 行动 ⇄(工具↻) → 输出 → 结束 的循环结构,当前阶段高亮;
  下面用一排 chip 记**本轮真实发生过的序列**(on_input 重置、before_toolcall 追加、
  after_output 收尾,最多 24 条)。工具调用会反复出现,循环因此可见。
- 区分调用类型:普通工具 chip 前缀 ⚙(青),output_* 输出通道调用前缀 ⇥(accent 色),
  两者配色与图标都不同。
- 文字再收缩:删掉「累计:入队/执行/抢占/挂起/背压」整行;队列标签由
  「L4 内核独占…」压成 L4/L3/L2/L1/排队(原描述进 title);各段标题压成
  「队列」「栈」「拓扑」;KPI 块标签压成 排队/中断/栈/子代理。

顺带(同类问题):CLI /stop 是人在终端当场下的指令,优先级由默认 L1 提到 L3。
2026-09-14 16:31:37 +08:00
36b577bff8 fix(webui): 总览改静态骨架 + 图标 KPI,彻底去掉整页重建的闪烁
jianf:仍严重闪烁;应彻底摒弃增量重建,用动态图标 + api 数据展示;主页文字太多。

- renderOverview 从「每次 innerHTML 重建整页(含运行态面板)」改成**首帧建一次
  静态骨架**,之后 renderAll(每 15s 一次)只 updateOverview —— 只写 textContent
  与类名,一个节点都不重建。实测连续两次 renderAll 后 #ov-kpis / #ov-status /
  #rt-panel 仍是同一批 DOM 节点,这是"不再闪"的直接判据。
- 主页文字大幅收缩:删掉「系统概览 / LLM 状态 / 记忆状态 / 运行时」四张 kv 文字卡,
  改成一排 8 个图标 KPI(状态/运行/插件/版本/LLM/记忆/文档/运行时),状态用彩色
  圆点表达,其余只留数字 + 两字标签。
- 运行态面板不再被 renderOverview 清空(去掉 _rtSig=null 与重建),保持连续更新。
2026-09-14 16:16:14 +08:00
7768168dd2 chore(sdk-vendor): 同步 qq 插件的消息合并改动(对应 SDK 仓 a01fe21)
本仓 vendored 了 SDK 的部分文件(third_party/homeagent-sdk,经 go.mod replace
引用),其中 example/qq/plugin.go 被跟踪。SDK 仓的 qq 消息合并提交同步过来,
保持 vendored 副本与 SDK 仓一致。
2026-09-14 16:11:22 +08:00
97111778a9 feat(webui): 数据查询 API + 前端 keyed 对账,去掉「局部重建」的闪烁
jianf:局部重建的闪烁几乎消不掉,应暴露数据查询 api,前端轮询后增量更新视图,
聊天记录也用这套。

后端(数据查询 api):
- ChatMsg 增加 seq(服务端单调递增、随记录落盘);老记录加载时补 1..n,重启不重编号。
- /api/v1/chat/history 增加 after=<seq> 增量通道:只回 seq 更大的消息,返回 last_seq
  作下次游标;一批超 limit 时回**最旧**的一批(回最新会把被挤掉的旧消息永久漏掉)。
  普通响应也带 last_seq,客户端首次全量后据此初始化游标。
- 测试 TestChatHistoryIncrementalAfterCursor 钉住「不重不漏 + 截断停在返回的最后一条」。

前端:
- 新增通用 morph():按「子节点位置 + nodeName」递归对账 DOM,同名节点复用、只同步
  变化的属性与文本。运行态面板的 put() 由 innerHTML 重建改为 morph —— SVG 圆环、
  队列条、数字块这些未变节点不再被替换,CSS 过渡与动画不再从头播。
- 聊天列表改用 keyed commitChatList():按 data-key(服务端 seq / 本地临时 key)对账,
  未变消息节点一个字节都不动,只替换真正变化的那条。
- syncChatFromHistory 改走游标:pollChatIncremental() 用 after 拿增量 + tail=1 探尾部
  原地更新(工具调用/最终文本是原地改的,不产生新 seq);聊天页可见时 3s 轮询。
2026-09-14 15:56:27 +08:00
f722498dba feat(webui): 默认配色改黑白 + 设置页新增「外观」区
jianf:默认配色太花,且配色要能在设置页调。

- 新增 mono(黑白灰)配色并设为默认:未选过配色的 localStorage 一律
  data-color=mono。黑白下连拓扑归属配色也走灰阶,不至于只剩一张彩图。
- accent 的所有硬编码 rgba(255,127,172,x) 收敛成语义变量 --accent-rgb,
  各配色块(sakura/cyan/violet/emerald/amber/blue)各自声明自己的 rgb,
  于是换配色时阴影/描边/阴影辉光一起换,不再残留粉色。
- 设置页新增「外观」区(侧栏最前):主题(浅/深)+ 7 个配色圆点 +
  背景图 URL/模糊。原先只有侧栏底部一个调色盘图标,找不到。
- 切配色时强制重画运行态(置空 _rtSig),否则拓扑会停在旧色。
2026-09-14 15:44:17 +08:00
27a7a3b439 chore(docs): 收编 QQ output_send 循环缺陷记录,标记已由 max_tool_turns 修复
仓库根目录的 problem.md(未跟踪)是一份 QQ `output_send` 回声/无限循环的
定位记录,状态写着「待修复」,但核心早已有轮次上限(core.agent.max_tool_turns,
默认 10,task.go 到达即强制收尾,测试 TestMaxToolTurns_CapsRunawayLoop)。
把它移进 docs/ 并更新状态,避免一份过期结论长期挂在根目录;同时删掉根目录的
临时基准脚本 tmp_fusion.py。
2026-09-14 15:35:31 +08:00
e4d69fa140 feat(webui): 总览改版 —— 阶段管道滑块 / per-agent 负载环 / 通道→agent 拓扑与光点
总览页此前是一堆数字与文字块,看不出「这一轮走到哪、谁忙、消息从哪进哪出」。
本次把运行态面板改成以图形为主:

- 阶段管道:七阶段滑块,由 SSE stage 事件驱动,当前阶段高亮、滑块滑过去;
  一轮结束(after_output 或 2.5s 无事件)自动回到空闲,不做假动画。
- 队列与中断栈:沿用五条进度条(L1–L4 + 排队),中断栈补一条深度进度条。
- Agent 拓扑:改成「每 agent 一条横带」——左 inputch、中 agent 节点(圆环 = 负载)、
  右 outputch,连线即路由;删掉旧的「归属框 + 单个内核盒」画法(看得出哪个子接了哪条输入)。
- 光点动画:channel_input(新增轻量 SSE 事件)沿 inputch→agent 连线跑;
  agent_output 沿 agent→outputch 连线跑。用 SMIL animateMotion,不需要 rAF 循环。
- 负载:由该 agent **自己的**调度器积压(排队 / 四级中断 / 中断栈)按级别加权折算,
  环形图展示。为此把驻留子的调度器积压透出到状态面(SDK 纯追加字段)。

后端:sdk.ResidentStatus / core.ResidentInfo 增加子 agent 调度器积压四项;
WebUI SSE 增加 channel_input 轻量事件(只带通道名与 agent id,不带正文)。

顺带收口对话区视觉(页签改分段控件、消息间距/气泡区分、输入区分隔线)。
2026-09-14 15:33:23 +08:00
0fda210e8b feat(webui): 视觉重做第一轮 —— 侧栏图标化、顶栏标题化、卡片/行/按钮收口
反馈是「丑死了」,没有具体项,所以按「哪儿在制造廉价感」逐条改:

1. **侧栏只有文字**:6 个导航项各加 24×24 stroke 图标(currentColor,随选中/hover 变色),
   10px 间距、13.5px/500 字重、圆角 10px 的药丸命中区;品牌字改 sakura→frost 渐变。
   → 空荡荡的 16rem 栏终于有了骨架。

2. **选中态把文字整体右推 + 发光文字**:原来用 `border-left: 3px` 画选中条,
   hover 时整行抖 3px;还加了 text-shadow 光晕。改成 `box-shadow: inset 2px 0 0`
   (不占布局)+ 取消光晕 + 选中加粗。这类「一像素级不稳」是廉价感的主要来源。

3. **顶栏只有一行灰字面包屑**:把当前页做成 15px/650 的标题色,面包屑碎片
   压到 12.5px 且降透明度;顶栏 48→56px。页面总算有「入口」。

4. **卡片 hover 整页上下浮**:`.card:hover` 去掉 `translateY(-1px)`(十几张卡一起
   浮,视线扫过像在抖),只提亮阴影与描边;padding 20→22、卡片间距 16→18。

5. **卡片标题没有章节信号**:`h2` 前加 3×14px 的 sakura→frost 渐变短竖。

6. **kv-row 是文字墙**:flex + 固定 180px 键列 → grid `minmax(110px,180px) 1fr`,
   行高 8px、负外边距 hover 高亮、末行去分隔线、数值 `tabular-nums`(端口/计数上下对齐)。

7. **满屏药丸按钮**:`.btn` 圆角从 999px 收到 10px(与卡片同一套圆角),
   padding/font 微调;`.btn-sm` 11→11.5px 提升可读性。

8. **内容区靠左铺满**:`.container` 居中 + `max-width: 1240px`(超宽屏摊满整个
   屏幕是「后台模板」的典型观感)。

i18n 有个坑:切语言那段是 `el.textContent = …`,所以 `data-i18n` 必须从 `<a>` 挪到
内层 `<span>`,否则切一次语言图标就被抹掉。实测 ZH→EN→ZH 图标都在。

验证:go build/测试绿(webui + sdk + agent + plugin);真机 1440×900 六页截图对比
(侧栏图标、渐变品牌、标题竖条、grid 行、居中内容区均生效)。
2026-09-14 14:29:17 +08:00
cdb2ea2207 polish(webui): 拓扑图只在容量非默认时写数字(去掉十几行「默认」文字) 2026-09-14 11:24:34 +08:00
e8d7bb4c06 feat(webui): 通道归属合并进拓扑图,整张图改 SVG(少文字、多图形)
上一版把「通道分配(按归属)」单开一段,等于把同一件事拆成两张表——
而通道属于谁是**拓扑的一部分**(左边这些输入口分别被谁接管),拆开反而
看不出关系。按用户要求合并,并整体改成图形化:

- 整张拓扑用 SVG:左侧按归属画出输入通道容器(根=青色虚线框,驻留子=彩色
  实线框并标轮次/上下文满),→ 汇集母线 → 内核 → 输出母线 → 右侧输出通道。
  **连线即路由**。
- 信息全部改用图形编码:归属=容器/配色、容量=节点内细条(默认容量不画填充)、
  输出能力=五个彩色圆点(text/file/image/audio/structured)。
- 文字降到最少:去掉四个数字块的副标题、排队队列那行只留 "FIFO"、
  通道行不再写"回程由来源决定"这类说明。
- 段名改为「通道拓扑(连线即路由;左框 = 归属)」。

验证:node --check 通过;go build ./... 干净;webui 测试全绿。
2026-09-14 11:22:20 +08:00
75f377fd4d fix(remotedevice): 心跳 pong 忘了 Flush —— 修「设备通道每 60 秒掉线重连」
真因(实测定位):服务端 writePong 只调 writeFrameHeader,**不 Flush**。
pong 只有两个字节,且设备空闲时没有任何别的写会顺带把 bufio 缓冲刷出去 ——
于是 pong 永远留在服务端缓冲里。

链路:客户端每 30s 发一个 ping(pingLoop)→ 服务端算出 pong 却没发出 →
客户端的读循环设的是「2 倍 ping 间隔」读超时(默认 60s)→ 每 60 秒准点
i/o timeout → 桥断开 → 3s 后重连 → 服务端 markOffline 注销 outputch,
重连后再注册。

生产日志就是这个指纹(online :20 → offline 下一分钟 :20 → 重连 :23,
连续数小时无一次例外);面板上表现为设备通道/工具凭空消失又出现,
/devices 列表跟着闪。

改法:writePong 复用 writeFrame(它 Flush)。另把客户端读循环退出时的
静默 return 改成带错误与 opcode 的日志 —— 此前断线真因在设备侧完全不可见,
只能靠对端日志倒推,正是这次排查一开始卡住的地方。

回归用例 TestWSPingGetsPongWhileIdle:只发一个 ping,随后什么都不发,
要求 2s 内必须收到 pong。**反向验证过**:把修复改回 writeFrameHeader,
用例即以 `read tcp ...: i/o timeout` 失败(与生产症状一致)。
2026-09-14 11:15:21 +08:00
8756f8d77f fix(webui): 通道归属把「根 agent id」与驻留子分开(根不再被标成「驻留子 main」)
实测(创建一个驻留子 uitest 并把 timer 划给它)暴露的归类错误:
inputch 的 owner 在登记表里可以是**根 agent 自己的 id**(如 "main")——
child/<id> 这条就是 owner="main"。前端只按「owner 非空」判为驻留子,
于是根自己那条被标成「驻留子 main」,而同一条通道在 residents 里根本不存在。

改法:
- /api/v1/runtime 补 agent_id(根 agent 的 id);
- 前端把 owner == 根 id 与 owner == "" 归一成同一组「根 agent / 内核默认」,
  只有既非空又非根 id 的才是子容器。
2026-09-14 11:08:27 +08:00
d502fc1bf5 fix(webui): 运行态面板逐段更新(真修「一闪一闪」)+ 补第五条排队队列
1) 上一版只做了整体签名缓存,实测仍会重建:设备通道列表本身就在来回变
   (远程设备通道 11→9 条),签名一变就整块 innerHTML,没变的段落(含条
   transition)也跟着推倒重来——视觉上仍是闪。改法:外壳只建一次,之后
   **逐段**(tiles/levels/stack/owners/topo)比较 HTML,只替换真正变了的那段。

2) 设计是「四条中断队列(L1–L4)+ 一条排队队列」= 五个队列,面板只画了四条:
   排队输入这条线在运行态里凭空消失。补第五行「排队(无级别)」,用中性色 +
   虚线分隔(它不是优先级,而是另一**类别**),并把它计入条形归一化基准。
   段标题从「中断队列(按级别)」改为「队列(四级中断 + 排队)」。

3) 顺带把累计计数(入队/执行/抢占/挂起恢复/拒绝/背压)显式列在数字块下方——
   背压是新指标,之前只能看接口看不到面板。

验证:node --check 通过;go build ./... 干净;webui/core/sdk 测试全绿。
2026-09-14 11:03:37 +08:00
43536ba326 fix(webui): 运行态面板不再闪、通道分配带归属(含驻留子)、改图形化
三个用户可见问题,逐个说明根因与改法。

1) 首页「一闪一闪」——运行态每 3s 轮询一次,renderRuntime 无条件重建
   #rt-panel 的 innerHTML:数据没变也把整块 DOM(含各级条的 transition)
   推倒重来。改法:缓存数据签名(**不含 uptime**——它每秒都变,带上等于没缓存),
   签名相同直接 return,一个字节都不动。另:renderOverview 会整块重建
   #rt-panel(面板本身是空的),所以那里必须让签名失效,否则空面板填不上。

2) 通道分配只显示内核/根 agent,看不见驻留子——根因是状态面只暴露了设备能力
   (KernelStatus.Channels,来自 iom.ListChannels),而「这条输入归谁」是
   ChannelRegistry 的属性(InputChannel.Owner/Capacity/Output),从未出过内核。
   而登记表本来就是根 agent 与驻留子**共用同一份**,所以数据一直都在,只是没画。
   改法:KernelStatus 新增 InputChannels(+ sdk.InputChannelInfo),
   /api/v1/runtime 带出 input_channels;前端把它按 owner 分进「归属容器」,
   驻留子即使一条 inputch 都没划到也照样出现在图里(否则"子存在但看不见"
   与"子不存在"无法区分),并显示其 allowed_outputs / 轮次 / 上下文满标记。

3) 「这些信息明明可以图形化」——四级中断的登记/抢占由纯文本改成并排迷你条;
   通道分配用归属容器 + 容量滑块(轨道/填充/把手/读数),并把回程通道、
   注册插件做成胶囊标签。设备能力拓扑(原有)保留。

验证:go build/vet 干净;go test ./internal/agent/... ./internal/plugin/...
./internal/sdk/... ./cmd/... 全绿;node --check dashboard.js 语法通过。
TestRuntimeEndpoint 扩展为同时钉住 input_channels 的归属与「驻留子划走的那条」。
2026-09-14 10:55:45 +08:00
c321388a21 fix(scheduler): 安全点重新求值中断队列 + 抢占/背压计数修正 + 停机补终态
对照 docs/zh/input-scheduler-design.md 原文修四处(前两处是真缺陷,后两处是
观测面与设计承诺不一致),均配回归用例:

1. §4.3/§5.2「临界区结束后的第一个安全点重新求值」此前**没有实现**:
   全仓唯一的武装点是 registerInterrupt,凡被拦成「入队」的中断只能等当前任务
   自然结束。可达症状:WebUI 终止按钮连按两次,第二次落在 2s 抢占冷却窗内 →
   入队 → 再也不会被求值。修:runTaskSteps 的安全点先 rearmPending()——
   判据与 registerInterrupt 完全同一套(canPreempt + 冷却 + 临界区闸门)。

2. PreemptsByLevel 的语义是「进入 immediate 槽的次数」,但计数发生在
   setImmediateLocked 之前:immediate 是单槽,同一安全点前到达的两条同级中断里
   被降级的那条也被计成抢占。修:setImmediateLocked 只在真占住槽时返回 true,
   计数随之为真;同时把「降级入队」的责任收归调用方,消除同一任务被入队两次的
   隐患(实测该隐患会让中断任务执行两次、Executed 虚高)。

3. 状态面 Preempted 此前拿 Stats.Suspended 顶替,与 preempts_by_level 自相矛盾。
   修:Preempted = Σ PreemptsByLevel[1..4]。

4. §4.4/Q4「满时阻塞发送方 + 计数并打日志」只做了阻塞:pumpInbox 满时直接返回,
   一个字都不计。修:新增 Stats.Backpressure(+DTO 字段) 与只报一次的状态翻转日志;
   同时显式处理 enqueue 返回值(静默丢弃会让同步调用方永久挂起)。

另:Stop() 停机前排空待办——给从未运行与已挂起的、带 ResponseCh 的任务补
skipped 终态,否则 cli/clawhubadapter 这类无超时同步注入方永久挂起(§7 I5、§11.3 X4)。
emitResponse 的 ResponseCh 写入改为非阻塞 + 告警,避免一行写错就卡死调度器 goroutine。

验证:go build/vet 干净;go test -count=1 ./internal/agent/... ./internal/plugin/...
./internal/sdk/... ./cmd/... 全绿;go test -race ./internal/agent/core/ ./internal/sdk/ 干净。
新增 scheduler_rearm_test.go 六个用例(冷却期满重新求值/同级降级不计数/Preempted 求和/
停机补终态/背压计数与翻转/pumpInbox 满计数)。
2026-09-14 10:39:25 +08:00
1ce3a917a5 feat(status+webui): 运行态图形化 —— 排队/四级中断队列/中断栈/驻留子/通道拓扑
需求:首页不该只有文字,要能一眼看出内核在忙什么——排队消息数、各级中断
排队与中断栈、驻留子 agent 数量;这些要向**内部 SDK 暴露接口**,供 WebUI 等应用
展示;通道划分也要能画出来。

## 一、内核状态面(internal/sdk,内部 SDK,不受公开 SDK 冻结约束)

* SchedulerStatus 补:
  - interrupt_queues[5]:**四级中断队列各自的深度**(下标即级别 1..4,下标 0 恒 0,
    这样 level 能直接当数组下标用)。此前只有 pending_interrupts 总数,
    看不出"堵在 L1 还是 L4"——四级是抢占优先级,堵在哪级是完全不同的运行状态。
  - immediate:刚抢占成功、下一个安全点立即运行的那个中断(此前完全不可见)。
  - suspend_frames:中断栈的帧(栈底→栈顶,只给任务标识),depth 之外还能看出
    "谁被谁打断"。
  - interrupts_by_level / preempts_by_level:各级累计登记数与抢占成功数。
* KernelStatus 补 residents(驻留子运行时视图:状态/轮次/上下文已满/输入通道/允许输出)。
  刻意**不带**每个驻留子的 inputch 登记明细——状态面会被反复轮询,明细会让
  每次 /status 背上几十 KB;只给表大小,要明细走专门接口。
* ChannelInfo 补 direction(in/out/io)、description、tools、output_caps、caps_text。
  此前 collectKernelStatus 只透传 Name/Type,把描述/工具/能力**全丢了**,
  前端只能画出一排光秃秃的名字。

## 二、WebUI

* 新增只读 `/api/v1/runtime`:只回运行态三件事(scheduler/residents/channels),
  实测 **1.0KB**(/kernel 是 30KB 级)——所以能 3 秒轮询做"实时"感,
  而不必反复拉全量状态。
* 首页新增「运行态」面板(纯 CSS + 内联 SVG,前端仍无构建链):
  - 四个数字块:排队任务 / 待处理中断 / 中断栈(深度/上限) / 驻留子 Agent,带占比条;
  - 四级中断队列条形图:每级"深度 · 登记/抢占",四级语义**照抄内核**
    (L4 内核独占 / L3 交互 / L2 消息 / L1 后台),不自己起名字;
  - 中断栈层叠图(栈顶在上)+ ⚡立即运行项;
  - 通道拓扑:输入通道 → 内核 → 输出通道,双向通道两侧都出现,能力以胶囊标签显示。
* 3 秒轮询只在总览页可见时才发请求;切回总览时 renderAll 会立刻补一次。

## 验证

* 新增 TestSchedulerStatusExposesLevelsAndStack(四级队列/立即项/栈帧/各级计数映射,
  并断言"未使用的级别必须为 0"与"下标 0 恒 0")、TestChannelInfoCarriesTopology、
  TestRuntimeEndpoint(形状 + 不携带 tools/plugins + 无状态源时 503)。
* go build / vet / agent+core+sdk+plugin+webui 全量测试绿。
* 真实浏览器实测(CDP 驱动,注入运行态样本走真实渲染路径):
  数字块 [3, 5, 2/4, 2];四级条 L4=1/L3=2/L2=1/L1=1 与数据一致;
  栈帧按"栈底→栈顶"渲染且标出栈顶;通道左右分列、io 通道两侧都出现。
2026-09-14 09:05:14 +08:00
c0e9dc1818 fix(webui): 聊天记录不再"每次都发完整记录",并修掉视口跳顶
两个都是你指出的症状,都定位到了具体代码路径。

① 「每次都发完整聊天记录」
   a) API 缺省值错了:/api/v1/chat/history 的 limit 缺省是 0 = **不限制**,
      于是任何不带 limit 的调用每次都拿到整段记录。实测(126 条):
      不带 limit 635,297 字节;现在默认只回一页 180,668 字节。
      显式 limit=0 仍可整取(逃生口)。WebUI/GUI 本来都带 limit,不受影响。
   b) 前端 30s 轮询(以及每次 SSE 报错)都直接拉一页 40 条:
      浏览器实测单次 180,813 字节。现在先做"尾巴探测"(limit=1,362 字节),
      尾巴一致就直接跳过;不一致才拉整页。

② 「聊天记录会跳到顶部」——两条会导致视口丢失的路径都堵上
   a) syncChatFromHistory 在"找不到重合点"时直接 `state.messages = serverMsgs`:
      服务端只回一页,而本地可能已经向上翻了好几页;一覆盖,容器立刻变矮,
      视口被夹回顶部,用户翻过的旧消息也凭空消失。现在只在服务端页**不短于**本地时
      才整体替换。
   b) renderChat 全量重建 innerHTML 后,仅在粘底时滚到底;非粘底(用户正在向上读)
      时位置没人管。改为重建前记住 scrollTop、非粘底时原样还回去。

浏览器实测(CDP 驱动真实页面,126 条历史):
  * 15s/30s 定时器跑满 40s:聊天区滚动位置 **0 px 变化**,未跳顶;
  * 期间 chat/history 请求:limit=1 × 2(各 362 字节)+ 首屏 limit=40 一次;
  * 控制台无报错;新增消息后轮询仍能正确并进来(尾巴探测→拉整页→合并)。

测试:新增 TestChatHistoryDefaultIsPaged(默认一页 / has_more / limit=0 整取 / 显式分页)。
顺带修测试串味:迁移用例往 os.TempDir() 写共享历史文件,会让其它用例的
NewHandler 加载到脏历史(表现为条数多 1);现在各用例用自己的临时文件。
2026-09-14 08:06:16 +08:00
764939ed90 refactor(webui): dashboard.html 6637 行拆成「外壳 + 样式 + 脚本」
前端刻意没有构建链(纯 CSS + Vanilla JS,go:embed 进二进制),所以拆法是:
外壳 dashboard.html 留 {{DASHBOARD_CSS}} / {{DASHBOARD_JS}} 两个占位符,
init() 启动时把两份资产原样填回去 —— **发出的 HTML 与拆分前逐字节一致**,
但 6637 行的单文件变成三份,便于编辑与评审。

  dashboard.html   168 行   外壳(head/body 结构 + 两个占位符)
  dashboard.css   2099 行   样式
  dashboard.js    4371 行   脚本

逐字节校验(三重):
  * 组装结果 sha256 == git HEAD 里拆分前的 dashboard.html;
  * 真实实例 GET /(带 API key)返回体 sha256 同上:0ef14b49…c053;
  * 新增 TestDashboardAssetsSplit:占位符必须存在、样式/脚本不得再内联回外壳、
    组装结果不得残留占位符且必须含样式与脚本特征串。

按行号切片时踩过一次坑并已修正:`</style>`/`</script>` 两个闭合标签被切掉
(正好少 27 字节)——正是因为当时少了逐字节校验,现在把它固化成断言。
2026-09-14 07:17:23 +08:00
4cbfdc970c perf(webui)+feat(config): 聊天记录写盘节流 + 配置库空闲页回收
两条都是我上一封里点出、你说继续的问题。

① 聊天记录:每条消息都整段重写 → 节流合并写
   原来 persistChatLocked 每次变更就整段重写记录文件,而一轮对话会触发多次
   (用户消息、每个工具事件、收尾消息)。200 条上限下文件可达数 MB,单轮就能
   放大出几十 MB 写。文件里还留着一个 chatSaveThrottle=3s 常量——声明了但从未
   被使用(疑似上次 revert 的遗留),等于节流从来没生效。
   现在:persistChatLocked 只置脏 + 唤醒写盘协程;chatPersistLoop 去抖
   chatSaveThrottle(3s)、并以 chatSaveMaxDelay(10s) 兜底(持续输出也不会无限拖延);
   写盘前把快照拷出来,**不持 chatMu 做文件 IO**;写失败重新标脏下轮重试。
   插件 Stop 里调 Handler.Close():停协程 + 强制落最后一次(幂等),否则丢最后一轮。

   实测(临时实例,连发 3 条消息):3s 窗口内记录文件**尚未创建**(节流生效);
   SIGTERM 后文件出现且 6 条(3 用户 + 3 助手,无 LLM key 故为错误回复)全在
   ——关停落盘没丢。

② config.db:SQLite 的 DELETE 不缩文件 → 空闲页够多时 VACUUM
   新增 ConfigRegistry.MaybeCompact(minFreeBytes, minRatio):空闲页 >= 1MB 且
   占页数 >= 25% 才做一次 VACUUM,避免每次启动都重写整库。库里是 WAL 模式,
   VACUUM 之后必须再 wal_checkpoint(TRUNCATE),否则主库文件看着没变小。
   调用点放在插件加载**之后**(大值的搬走/删除发生在插件 Start 里,之前调没意义)。

   实测(一个刚被搬走 5MB 聊天记录的实例):
     freelist 1288 页 × 4096B;启动日志「配置库已压缩: 5394432 -> 118784 字节」
     config.db 5,394,432 → 118,784 字节;记录文件 5,279,491 字节完好未动。

测试:TestChatPersistenceIsThrottled(节流窗口内不写盘 + Close 必落盘 + Close 幂等)、
TestMaybeCompactReclaimsFreePages(删大值后文件确实变小 + 数据完好 + 阈值不达标时不白做功)。
2026-09-14 07:14:55 +08:00
642e1c39b1 refactor(webui): handler.go 2993 行按资源拆成 11 个同包文件
拆法:按「资源面」搬家,每个顶层声明(func/type/var/const)整体搬到目标文件,
声明体一字未改,各文件按实际用到的包重新生成 import。文件头加一行说明本文件负责哪一面。

  handler.go              骨架:嵌入前端资源、Handler/构造、路由表、鉴权会话日志中间件、静态页
  handler_chat.go         对话面:消息模型与内存历史、SSE 事件订阅、对话/历史接口
  handler_upload.go       上传面:handleChatFile / handleUploads / 中断对话
  handler_memory.go       记忆面:图/文档/文本记忆、知识库、LLM 源、变更追踪
  handler_agents.go       内核与代理面:状态、kernel、人格、代理/快照/回滚
  handler_settings.go     设置与插件面:配置读写、插件列表详情(含 pluginmgr 反代)
  handler_terminal.go     终端面:终端会话、终端接口、命令历史
  handler_sse.go          SSE 环形缓冲(断线重连补发)
  handler_openai.go       OpenAI 兼容面:/v1/chat/completions
  handler_device.go       设备网关反代(HTTP + WS 升级透传)
  handler_files.go        /files/ 与 /uploads/ 下载

零漂移校验:拿重构前的 handler.go 与新 11 个文件逐行比对(忽略空行、package/import 头),
**丢失行 0**;新增行恰好是 11 个文件头注释(14 行)。

顺带修掉 import 里两处假使用:handler_openai 的 sdk 只作为 Handler 字段名出现(h.sdk.),
handler_settings 的 fmt 只出现在注释里 —— 都从 import 里去掉。

验证:go build ./... / go vet / webui+config+sdk 测试全绿;
起真实实例(沿用已有 data 目录)后 /status /settings /chat/history /plugins /terminals
/kernel /memory /config /login 全部 200,设置在注入 5MB 历史的情况下仍是 33,921 字节。

最大文件从 2993 → 706 行(handler_chat.go)。
2026-09-14 07:03:47 +08:00
c4998bb102 feat(webui): 聊天记录改为独立文件存储(位置可配)+ 存量自动迁移
起因:聊天记录原先作为插件配置项 plugin.webui.chathistory 存在 config.db 里,
带来三个后果(都在生产实例上实测过):
  1. 整段记录 5,176,016 字节会被 GET /api/v1/settings 当普通配置项整块返回;
  2. 每来一条消息就把整段记录重新 marshal 后写回 config 表,而那次写要拿
     config registry 的全局写锁 —— 消息频繁时所有配置读写都被拖着排队;
  3. 位置不可配(想放独立挂载盘只能改整个 data_dir)。

改动:
* 新增 internal/plugins/webui/history.go:
  - historyStore:默认 <data>/webui_chat_history.json,写盘用同目录 tmp+rename
    原子替换,崩溃不会留半截 JSON;读失败/JSON 损坏按空历史处理并告警
    (聊天记录不是关键数据,不该让它拖垮 WebUI)。
  - resolveHistoryFile:插件设置 history_file > 默认路径;相对路径按 data 目录
    解析(可指向独立挂载盘),data 目录未知时落到系统临时目录而不是进程 CWD。
  - LoadWithMigration:文件为准;文件为空而老配置项有内容时,把记录搬到文件、
    搬成功才删配置项(删不掉就保留并告警,不丢数据);文件已有数据时顺手清掉
    上次没删干净的遗留键。
* 新增插件设置项 history_file(设置页可见可改):留空 = 默认路径。
* handler.go:chatHistory 的读/写改走 historyStore,不再碰 settings;
  顺带把「写失败静默忽略」改成告警。

存量迁移实测(拿仍持有 5,271,690 字节老记录的实例跑新二进制):
  日志:聊天记录已迁移到独立文件 .../webui_chat_history.json(1300 条),并从插件配置表移除
  迁移后:config_webui 里 chathistory 行数 = 0;记录文件 5,279,491 字节
          GET /api/v1/settings = 33,921 字节(迁移前 8,244,108)
          GET /api/v1/chat/history 正常(从文件读回 1300 条里最新的 3 条)

新增测试:TestResolveHistoryFile、TestHistoryStoreMigratesFromConfig(含二次加载
不重复迁移 + 损坏文件不 panic)、TestHistoryStoreSaveIsAtomicAndRoundTrips。
2026-09-14 07:00:07 +08:00
0beb389223 fix(webui): 设置接口不再吐内部数据;--webui 覆盖生效;端口占用不再静默成功
三处实测确认的缺陷:

① 设置接口整块吐出聊天记录
   plugin.webui.chathistory 是 webui 自己持久化的整段聊天记录(生产实例
   实测 5,176,016 字节),躺在插件配置表里被设置接口当普通配置项整块返回,
   前端还会把它渲染成一个巨大的文本框。
   修复:GET 跳过该键(按插件+键精确判定),PUT 直接 400,避免误改。

② CLI --webui 与 webui.listen_addr 一直是死配置
   内核原本在插件加载前写 settings["addr"],但那时 config_<name> 表还没建
   (表只在插件注册 def 时创建),PluginSettings.Set 的 INSERT 失败,而错误被
   "_ =" 忽略了;随后插件 Start 里 RegisterDef 才建表并写入默认 :8080。
   实测:传 "-webui 127.0.0.1:18099" 仍然监听 :8080。
   修复:覆盖值改由插件自己接收(webui.SetListenOverride,loadPlugins 前调用),
   优先级 CLI > webui.listen_addr(非默认值才算显式配置)> settings["addr"]。
   实测修复后:"-webui 127.0.0.1:18099" 正确监听 18099,与生产的 :8080 并存。

③ 端口被占时 webui 静默死亡
   Start 在后台 goroutine 里 ListenAndServe,先打印 "listening on" 再尝试绑定,
   失败只留一行日志,Start 永远返回 nil → 插件仍被当成加载成功。
   修复:net.Listen 同步做,失败即返回 error(交给加载器/守护),
   成功后才起 Serve,并打印真实绑定地址。
   A/B 实测(两个实例都撞生产的 :8080):
     修复前:"listening on :8080" + "server error: address already in use" + LOADED: webui
     修复后:"[plugin] start webui: webui: 监听 :8080 失败: ...",不再有 LOADED: webui

效果实测(同一实例,先注入 5,271,690 字节 chathistory):
  GET /api/v1/settings   8,244,108 → 28,652 字节(约 1/288)
  meta 条数              5,208 → 105,幻影键 0 条
  设置页仍正常:?prefix=plugin.webui 返回 8 条 def;普通键 PUT 落库;
  校验:GET/PUT 内部键被拒;-webui 覆盖真实生效。

新增测试:TestSettingsNoCrossPluginLeak(跨插件泄漏/幻影键/chathistory 读写)、
TestListenOverrideAndBindFailure(覆盖生效 + 端口占用必须报错)、
TestResolveListenAddrPrecedence(优先级)。
2026-09-14 06:54:16 +08:00
9e6627f0c3 fix(config): 插件 def 查询不再越界 —— ListDefs 作用域 + 新增 ListCoreDefs
两个方向相反的越界,合起来把 WebUI 设置接口的 meta 撑成 5208 条(96% 重复):

1) PluginSettings.ListDefs(prefix) 把 prefix 直接透传给全局 ListDefs,
   等于「返回全仓所有 def」——调用方以为在问某个插件,实际拿到全部。
   修复:限定到 plugin.<name>. 命名空间,并把 Key 剥回插件内局部键
   (调用方看到的键必须与 Set/Get/ListPlugin 的局部键一致)。

2) DefsCore(prefix) → reg.ListDefs(prefix) 会连插件 def 一起返回,
   于是 meta 里出现 plugin.<name>.<key> 的「核心侧副本」。
   修复:新增 ConfigRegistry.ListCoreDefs,显式排除 plugin.* 命名空间。

生产实例实测(旧代码):GET /api/v1/settings 的 meta = 5208 条,
其中 core.agent.* 等每个 def 都被复制 28 份(每个插件命名空间一份),
并派生出 plugin.<a>.plugin.<b>.<key> 这类幻影键。

⚠️ 幻影键不只是脏数据:设置接口的 PUT 走 SplitN(key, ".", 3),
对 plugin.<a>.plugin.<b>.<key> 会解出 (a, "plugin.<b>.<key>"),
即按 UI 上的幻影条目保存会**写进错误插件的配置表**。

新增 TestPluginDefsAreNamespaced 钉住两条作用域。
2026-09-14 06:53:58 +08:00
3edab0fe68 refactor(homed): main() 696 行按启动阶段拆成 25 个阶段函数
main() 原本是一整条 696 行的启动脚本:日志、目录、记忆、配置、Lua、守护、
追踪、内核 API、文本记忆、LLM 源、文档/知识、人格、插件、Agent、ONNX、
IPC、心跳、关停全挤在一个函数里,变量跨 500 行互相引用。

现在 main() 只剩「顺序编排 + 就地交接」(**149 行**,低于 funlen 阈值 150):
  opt           := parseFlags()
  logDir        := setupLogging(opt.dataDir)
  agentWorkDir  := ensureDataDirs(opt.dataDir)
  mem, closeMem := initMemoryStack(opt.dataDir)
  ...
共 25 个阶段调用,实现体在同包 bootstrap.go(一一对应)。

零漂移保证:
  * 阶段体逐字取自原 main,只做机械替换(`*dataDir`→参数、`memIdx`→`mem.indexer`);
  * 原 main 的每个 defer 都换成一个在**同一位置**注册的 cleanup,
    LIFO 释放顺序不变;多资源阶段内部再按原注册顺序取反;
  * 语句级比对:原 main 的 525 条可执行语句全部有对应,无遗漏。
    仅 3 处为**有意**的结构改写(其余为同义替换):
      1. initLuaVM / initTextMemory:「启动成功才 defer Stop」改为
         「失败返回 no-op cleanup,成功返回 Stop」——调用点语义不变;
      2. startIPCServer:同上(用 started 标志保证失败时不 Stop);
      3. resolveBaseAPIKey:把三级兜底 API key 解析提成一个纯函数。
  * defaultPrompt 提为包级 const defaultSystemPrompt(不含版本号字面量)。

验证(A/B 实测,不是只跑编译):
  * go build ./... / go vet ./cmd/homed/ / go test ./cmd/... ./internal/agent/... ./internal/plugin/... 全绿
  * 重构前后二进制各起一次(-data 临时目录,SIGTERM 收尾),日志集合**完全一致**:
    63 个注册工具、同名插件全部 loaded、kernel ready、插件逆序关停、'stopped'
    —— 差异仅为并发加载插件的打印顺序。

全仓非测试 Go 函数现状:≥300 行 **0 个**,≥200 行 9 个,≥150 行 16 个。
2026-09-14 06:30:45 +08:00
129a3aeb38 refactor(proc): coreHandler.Handle 550 行按 method 组拆成 14 个分部函数
原 Handle 是一个 550 行的巨型 switch(C ABI 51 个 case 的整块平移),
按协议面拆进同包 5 个新文件、14 个小函数:

  corehandler_register.go  handleRegister        注册面(tool/stage/output/api/input)
  corehandler_inject.go    handleInject          IO 注入 + SetToolBlocks
  corehandler_memory.go    handleGraphMemory     图记忆
                           handleDocMemory       文档记忆
                           handleKnowledge       知识库
                           handleTextMemory      文本记忆
  corehandler_settings.go  handleSettings        设置(14 个 method 共用一条实现)
                           handleLLM             LLM 源
                           handleSocial          社交图只读
                           handleLifecycle       生命周期开关
  corehandler_runtime.go   handlePluginMgr       插件管理
                           handleStageLocks      段锁仲裁
                           handleEvents          事件订阅
                           handleArena           共享槽池

Handle 保留 capability 强制检查,只做「method → 分部函数」一跳。

零漂移保证:case 标签由脚本从原文提取(不手抄常量名),case 体逐字搬迁,
逐函数比对确认 59 个标签 / 510 行 case 体与原文件完全一致(仅行首缩进经 gofmt 重排)。

验证:go build ./... / go vet / go test ./internal/plugin/... / -race 全绿。
2026-09-13 23:29:13 +08:00
dcae21b24c refactor(lua): replaceSDKReal 633 行按 SDK 子表拆分
抽 luaReg 上下文(L/t/plg/s + subTable/pushVal/pushList/pushErr/pushNil
五个助手方法),把单函数拆成 registerRegistrars / registerInjectors /
registerDataAPIs / registerSettings / registerEventsAndMgr 五个方法。

被移动的代码体**逐字保留**:各方法头部把 L/t/s/plg 与五个助手注入为局部
别名,所以内部一行未改,行为零漂移。luaSyncUnavailable 提为包级函数
(原来它在被拆到另一个方法的作用域里会 undefined)。

实测:replaceSDKReal 从 633 行消失,最大子方法 265 行;非测试函数
>=300 行的数量 3→2。go build/vet/test -race 全绿。
2026-09-13 22:44:39 +08:00
62e1e02036 docs(ohos): README 两处事实修正(产物路径前置条件、≤400 行约定的边界)
1. **安装小节的产物路径**:`entry/build/` 是纯构建产物、不入库,干净 clone 或清理过
   工作区时该文件不存在。补明"必须先跑完第 2 步",并说明目录名随
   `-p product=<名字>` 变化、同目录还有 unsigned 版(`hdc install` 要用 signed)。
   本次实际构建校验过路径:`entry/build/default/outputs/default/entry-default-signed.hap`。
2. **≤400 行约定补边界**:不到 400 行的文件不要为了拆分而拆分 ——
   `@Component` 的 `build()` 只允许一个根节点,多节点 `@Builder` 改组件会多出一层
   Column 包裹,布局等价是推理出来的、不是看出来的,每拆一次都要付一次
   "未上机验证"的账。并记下 `pages/Index.ets`(396) 属于"不越线就不动"的一类。

无代码改动,纯文档。
2026-09-13 22:42:37 +08:00
8a58cde3ee docs(ohos): 本地构建前置条件 + 运行时验证清单 + 工程结构表刷新
1. **oh_modules 前置条件**:该目录被 .gitignore 忽略但必须存在 —— hvigor 不会
   自动 ohpm install,移走后构建直接报 arkts-no-untyped-obj-literals(依赖类型
   声明缺失)且不重建目录。写明"clone 后先 ohpm install,别当垃圾清掉",
   同时说明 entry/build 与 .hvigor 是纯产物、可随时删(冷构建 ~8s)。
2. **hvigorw 绝对路径**:仓库里的 ./hvigorw 是符号链接,启动脚本按
   $(dirname $0) 定位,会报 File not found: <repo>/cmd/ohos/hvigor/bin/hvigorw;
   统一改用 <command-line-tools>/bin/hvigorw(本机 /opt/huawei/command-line-tools/bin/hvigorw)。
3. **运行时验证清单**:把"构建通过 ≠ UI 行为不变"这件事写进仓库而不是留在邮件里
   (流式对话/思考卡与工具卡/附件上传/设置与设备与插件的二级页/宽屏分栏),
   并注明无提权环境起不来模拟器时需在真机补验证。
4. 工程结构表按前几轮拆分后的实际情况刷新(common/components/pages 新增文件与职责),
   并记下"单文件 ≤400 行、页面只做壳"的约定。

无代码改动,纯文档。
2026-09-13 22:35:29 +08:00
e733d05a5e refactor(ohos): DevicePage 560→307 行(入口列表/四个面板/模型拆分)
- common/DeviceModel.ets(73):device_id 兜底(桥 id 优先 → 持久化 → 生成并落盘,
  顺序与原 aboutToAppear 一致)、/device/online 响应解析、四个二级页路由 id
- components/DeviceRootEntries.ets(92):一级入口(本机/通道两组 NavRow 列表);
  宽屏高亮自己读 AppStorage 的 isWideScreen,页面只给 activeSub 与 onOpen
- components/DevicePanes.ets(316):DeviceLocalPane(基本信息 + 授权开关)、
  DeviceCapsPane(能力清单)、DeviceGatewayPane(网关信息 + 刷新)、
  DeviceListPane(在线设备列表)、DeviceKvRow;每个面板自带 SubPageLayer

页面保留导航栈、openSub/closeSub、授权开关、toast、refreshDevices 与
SubDestination 分发。所有文案、图标、颜色、过渡与失败分支逐字保留;
面板内容多了一层无 padding 的 Column 根节点(@Component 的 build() 只允许
一个根),宽度 100% + Start 对齐,与 SubPageLayer 内容槽的布局一致。

验证:hvigorw assembleHap BUILD SUCCESSFUL。
2026-09-13 22:34:20 +08:00
8a9fc05451 refactor(ohos): DeviceBridge 409→296 行(协议类型与帧构造移到 BridgeProtocol)
- common/BridgeProtocol.ets(168):hello/bind/cmd_result/cmd_data_start/
  cmd_data_end/event/status 七个消息结构、CHUNK_SIZE、BridgeCmdHandler 回调类型,
  以及 bridgeHelloFrame / bridgeBindFrame / bridgeResultFrame /
  bridgeDataStartFrame / bridgeDataEndFrame / bridgeEventFrame /
  bridgeStatusFrame / bridgeChunkSlices 八个纯构造/切片函数
- common/DeviceBridge.ets(296):只剩 socket 生命周期、重连代际、绑定状态机
  与命令分发

**DeviceBridgeClient 的对外方法名与签名一字未改**(isConnected / getDeviceId /
setCmdHandler / setStateListener / connect / updateAuthorized / disconnect /
sendResult / sendDataChunked / sendEvent / sendStatus / send),
`send*` 仍是"拼帧 + 发出去"两步,拼帧那一步搬走;分块发送的
"start → chunks(失败即 break)→ end"顺序与 `bytes.slice` 语义保持不变。
外部只有 deviceBridge 单例被 import(BridgeRouter / DeviceBridgeSession /
DevicePage),无其它符号依赖。

验证:hvigorw assembleHap BUILD SUCCESSFUL;diff 中 DeviceBridge.ets 无
状态机/回调/重连逻辑改动。
2026-09-13 22:28:53 +08:00
31bbde9cdd refactor(ohos): Attachment 463→344 行(纯函数与字节解码移出 components)
- common/AttachmentMeta.ets(106):parseAttachment / attachmentFromChannelOutput /
  fileNameOf / formatBytes / oneDecimal / extLabel / sanitize,纯函数无平台依赖
- common/AttachmentImage.ets(37):loadPixelMap(沙箱 file:// 与远端 /files 两条路径)

components/Attachment.ets 只留 UI:AttachmentCard 与 AttachmentDetailContent。
**两者的导出名、@Prop 形状与 import 路径均未变**(ChatPage 仍从
'../components/Attachment' 取 AttachmentDetailContent),组件内部的布局、
过渡、提示文案与失败分支逐字保留,仅函数体搬走。引用方 5 处 import 路径同步更新。

验证:hvigorw assembleHap BUILD SUCCESSFUL;diff 中 Attachment.ets 只有
"-删除纯函数 + import 改写",无属性/布局改动。
2026-09-13 22:27:34 +08:00
e0514c3692 refactor(ohos): ChatPage 1962→207 行(状态机/SSE/气泡/输入区拆分)
- common/ChatStore.ets(388):消息数组、分页游标、新消息入场标记、
  SSE 连接与重连、防抖刷新(50ms)统一成一个单例状态机
- common/ChatSse.ets(192):SSE 事件 → 状态的翻译层,逐分支照搬
  channel_output/agent_output/reasoning/delta/tool_call/stage/agent_error/
  sync_required;通过 ChatStreamSink 接口写入,避免与 ChatStore 形成循环依赖
- common/ChatSession.ets(176):POST /chat 与 POST /chat/file 的发送、
  超时兜底、POST 响应与 SSE 的合并判定
- common/ChatFormat.ets(223):mime 推断、ForEach 键 structSig、工具卡
  状态/颜色、渠道判定与头像配色
- common/ChatHistory.ets(96):历史载荷与 tool_calls 解析
- components/ChatBubble.ets(247):气泡(头像/渠道名/思考卡/工具卡/附件卡/正文)
- components/ChatToolCard.ets(253):思考卡 + 工具卡
- components/ChatStream.ets(210):消息列表 + 顶栏遮罩 + 底部淡出 + 触顶懒加载
- components/ChatComposer.ets(357):输入行、选图/选文件、沙箱落盘、发送
- components/ChatAttachBar.ets(139):加号菜单 + 待发送附件条

响应式语义刻意保持不变:数组不进 AppStorage,改用自增版本号 K_CHAT_REV
通知订阅组件重取快照(ChatStream 把它镜像进 @State messages,ForEach 每次
拿到的仍是新数组引用,与拆分前 this.messages = this.messages.slice() 等价);
structSig 仍不含 content,正文靠 MarkdownView 的 @Prop 流式更新;
markNew 仍不切片、入场动画交给紧随其后的 refresh();
animateTo 只能存在于组件里,所以折叠翻转的动作留在 ChatStream 内。

验证:hvigorw assembleHap BUILD SUCCESSFUL;SSE 各分支、ensureToolCall、
markNew、sendChat/sendWithAttachment 的守卫顺序均与原实现逐条比对过,
守卫从"页面方法内"移到输入区组件时保持了原有先后(连接判定先于清空输入)。
2026-09-13 22:19:05 +08:00
f79e0f82dd refactor(ohos): SettingsPage 1463→389 行(模型/条目卡/四个面板拆分)
- common/SettingsModel.ets(313):设置载荷解析、分类归并、分页切片、
  路由常量,纯逻辑无 UI
- components/SettingsEntryCard.ets(215):单条设置卡(值编辑/保存)
- components/SettingsRootEntries.ets(100):一级入口行 + 状态汇总卡
- components/SettingsHome.ets(95):一级页壳(顶栏/浮层/提示条)
- components/ConnectionsPane.ets(347):后端连接 CRUD(自带二级页壳)
- components/AppearancePane.ets(265):主题/背景/透明度(自带二级页壳)
- components/BackendSettingsPane.ets(172):分类与条目两个二级面板

页面保留 @State 集合、加载/保存编排与 SubDestination 分发;数组仍走
@Link 直传(未引入 AppStorage 数组)。相册选择、重启前台桥等既有行为
与提示文案逐字保留。

验证:hvigorw assembleHap BUILD SUCCESSFUL。
2026-09-13 22:18:56 +08:00
131c1ff0e9 refactor(ohos): PluginsPage 995→374 行(接口/状态/列表/详情/浮层拆分)
拆分方向按职责切,页面只留导航与数据编排:
- common/PluginApi.ets(174):fetchPluginRows / fetchPluginDetail
- common/PluginStatus.ets(78):状态判定、文案、颜色、副标题
- components/PluginListView.ets(166):列表卡 + 列表
- components/PluginDetailPane.ets(291):详情面板
- components/PluginsOverlays.ets(65):安装表单
- components/ToastBar.ets(48):提示条,PluginsToast 与 SettingsPage 的
  toast 合并成这一个组件(此前两处各写一份)

UI 结构与文案逐字保留(含 92%/layoutWeight 等既有布局修法)。

验证:hvigorw assembleHap BUILD SUCCESSFUL。
2026-09-13 22:18:49 +08:00
414e6a1627 refactor(ohos): StaticMarkdown 604→332 行(Markdown 解析抽到 common/MarkdownParser)
把"文本 → 块/片段"的纯解析逻辑(MdBlock/MdSpan、parseBlocks、parseInline、
表格/分隔线/有序列表判定)整体搬到 common/MarkdownParser.ets(282 行),
StaticMarkdown.ets 只留 StaticMarkdownView 组件(332 行)。

解析规则逐字保留,未改任何排版行为;MdBlock/MdSpan 原本只被
StaticMarkdown.ets 使用(唯一引用方是 components/MarkdownView.ets,
它只用 StaticMarkdownView)。

验证:hvigorw assembleHap BUILD SUCCESSFUL。
2026-09-13 22:18:43 +08:00
431bb5a0c9 refactor(tooldefs): buildToolDefs 614→273 行(抽 toolDef 助手,schema 形状不变)
原实现每条工具都是 4 层嵌套的 map[string]interface{} 字面量(约 20 行/条),
40+ 条堆成 614 行的巨型函数。新增 toolDef(name, desc, props, required...)
助手消除外层样板;所有 name/description/properties/required 文本**逐字保留**
(用 go/ast 定位原样搬迁,非重新键入),schema 形状与 JSON 输出不变。

验证:go build ./... / go vet / go test ./internal/agent/core/ 全绿;
AST 实测 614→273 行,非测试函数 ≥300 行数由 4 降到 3。
2026-09-13 22:17:45 +08:00
6878f0126d fix(lua): 同步注入在 Lua 中明确报不可用(避免自锁)+ 文档/mock 同步
sdk.inject_input_sync / *_opts / inject_input_media_sync* 在 Lua 里必然自锁:
Lua 代码只在 Start/工具/阶段/输出/事件回调中执行,这些路径都持有 plg.mu,
而同步注入要等本轮回复(回复路径上的回调又需要同一把锁)。原实现会挂死
直到超时;现改为立即返回明确错误,并在中英文 PLUGIN_DEV 里标注不可用 +
指向 Go 插件/异步注入。mock sdk.lua(SDK 仓为事实源)同步为同样的错误语义。
新增 TestLuaSyncInjectUnavailable 钉住不挂死。
2026-09-13 21:59:23 +08:00
52127a3323 fix(resident): CreateResident 注册入站 inputch 后加 defer 回滚
注册点与 residents 登记之间当前无可失败步骤,但缺回滚路径就是 child/<id>
残留那只 bug 的另一条入口。加 registered 标志 + defer:未走到成功返回就注销。
2026-09-13 21:59:10 +08:00
11d9038927 fix(io): ChannelRegistry 补 UnbindOutputTarget,Unregister 清理 outputTargets
outputTargets 只增不减:Unregister 一个 inputch 后,指向它的输出目标登记仍
留在表里,ResolveOutputTarget 会继续把消息路由到已不存在的 agent/inputch。
与刚修的驻留 inputch 残留同属「注册未注销」类。现补 UnbindOutputTarget
(幂等),并让 Unregister 顺手清掉显式绑定与同名回退两种目标登记。
2026-09-13 21:59:10 +08:00
a15e7c2dc1 chore(lint): 加 .golangci.yml(funlen/gocyclo/lll/dupl,warn-only)+ make lint-full
main 上曾有 4 个 >=300 行函数、12 个 >=200 行函数;没有复杂度 linter 是它们
长期存活的直接原因。先以 warn-only(issues.exit-code:0)立阈值、只出清单,
历史债下降后再收成硬门禁。测试与 testdata/third_party 排除长度类规则。
2026-09-13 21:59:10 +08:00
4518c3eb03 fix(lua): events.subscribe 改用内部 Subscribe + 订阅生命周期(修死锁/use-after-close)
上一版 Lua 对齐引入的 sdk.events.subscribe 有两个真问题,本提交修掉:

1) 用了公共 SDK 的 Events(),但本内核从未注入 event subscriber
   (SetEventSubscriber 全仓无调用点),拿到永远是 nil ⇒ subscribe 只会
   返回 "events unavailable"。改用内部 SDK 的 s.Subscribe——内置插件走的就是
   这条路径(cli/webui/skillmgr 全用它)。

2) 自死锁:subscribe 会在 Lua 的 plugin.start(sdk) 回调里被调用,而
   luaPlugin.Start 正持有 p.mu;原实现在 subscribe 里再 lock p.mu 追加 subs,
   不可重入 ⇒ 测试实测 30s 超时。改用独立的 subsMu。

3) use-after-close:Stop 会 Close LState,但事件订阅此前无人取消,残留回调
   再触发就会碰已关的 L。现在:Stop 先(不持 p.mu,避免与 Bus.Publish
   锁序反转)取 subsMu 取消全部订阅,再置 closed 并关 L;事件回调持 p.mu 后
   先查 closed,已进入等锁的旧回调会直接返回。

4) plugin_mgr 访问补 nil 保护(部分单测构造的 SDK 不含 pluginMgr)。

回归:TestLuaEventsSubscribeAndStopCleanup——订阅后 Publish 命中、Stop 后
再 Publish 不 panic。全套 Lua 测试在 -race 下通过。
2026-09-13 20:33:13 +08:00
44cb7243c5 fix(resident): 销毁驻留子时注销其入站 inputch(child/<id>)—— 修登记表脏数据累积
根因:residentInboundChannel 在 create 时把 child/<id> 登记进共享登记表
(Plugin=resident, Owner=父),但 teardownResident 只把划入的 inputch
(如 timer)归还为未分配,从未注销这条入站登记。于是每次 create/destroy
都在登记表里留下一条脏记录,且随次数单调累积。

实测(HomeAgent 侧,HΔ-Kernel v1.3.10 / 1b49365):
resident_agents destroy 之后,input_channels by_agent 仍列出 child/<id>,
归属 main;而 HomeAgent 没有任何工具能单独注销 inputch,只能重启 homed 清。

修法:teardownResident 里用纯函数 inboundChannelName 算出名字并 Unregister。
不能复用 residentInboundChannel——它有重新登记的副作用。
该路径同时覆盖 destroy / reclaim / StopResidents(父退出)。

测试:TestResident_LifecycleAndNoOrphans 增加两条断言——销毁后与父退出后
child/<id> 都必须从登记表消失。
2026-09-13 20:19:37 +08:00
162f33f81e feat(lua): Lua 插件桥全量对齐 SDK 1.3.0(媒体/注入标志位/优先级/事件/通道注销)
内核 Lua 桥(internal/plugin/lua_plugin.go)此前停在 v0.8.0 时代能力面,
1.1/1.2/1.3 新增能力只在 Go 侧存在,而 PLUGIN_DEV.md 宣称『能力完全对齐』。
本补丁把 Lua 侧补齐到与公开 SDK 1.3.0 对齐:

- 1.1 媒体:memory.commit 支持 sentence_text/media_digests;
  doc.insert_with_media + attachments;text_memory.append attachments;
  set_tool_blocks / inject_input_media(_sync) / inject_interrupt_media。
- 1.2 注入语义:inject_input_sync(_opts)、六个 *_opts 变体
  (no_memory/context_policy/cleaner_name/priority);
  ToolDef/ChannelDef 解析 context_policy。
- 1.3 优先级与动态通道:priority 常量透传;unregister_output_channel。
- StageContext 暴露 reasoning_content/context_msgs/token_usage/memory/extra/errors。
- 新增 sdk.events.subscribe 与 sdk.plugin_mgr.*。
- sdk.lua mock 同步(单一事实源在 SDK 仓 sdk/lua/sdk.lua,内核副本由
  third_party/homeagent-sdk/scripts/sync-lua-sdk.sh 同步)。

契约测试(lua_surface_test.go):
- 守住内核内嵌 mock 与 SDK 仓事实源一致;
- 守住 mock 承诺的每个函数都有运行时 RawSetString 绑定;
- 覆盖 opts/media/attachments 解析与 context_policy 透传。

文档:中英 PLUGIN_DEV.md 的 Lua API 表补齐并改为『对齐至 SDK 1.3.0』。
2026-09-13 19:56:32 +08:00
180b96e21a docs: 记下 gitcode 附件的"同名只写一次"硬约束(校验和首次没传全就永远补不回来)
实测证据:同一个名字(ZZprobe.txt)传两次不同内容,下载端始终返回第一次那份;
资产列表里该名字只有一项。删除接口走不通 —— release JSON 不含 `id`,附件列表接口 404,
`DELETE .../releases/<tag>/attach_files/<name>` 返回 400「参数类型错误」(要数字 id)。

后果(1.3.1–1.3.10 全都踩了):首次上传 `SHA256SUMS` 时只有 linux/amd64 四个产物,
之后补 arm64/darwin/win 时"合并后重传"**全部无效** —— 线上那份至今仍是 4 项、带 `./` 前缀,
arm64/darwin/win 的产物没有校验依据。

⇒ 纪律:**打包全部平台后才第一次上传校验和**;分批上传时先传产物、最后传校验和,
校验和只传一次。补救只能换名(`SHA256SUMS.complete`)或重建 release(需重传全部产物)。
2026-09-13 18:50:06 +08:00
3fda1db9c0 fix(packaging): package-windows.sh 支持 NSI 覆盖 + payload 预检
上一步失败:`File "..\..\build\linux-payload\*.*" -> no files found`。
原因:NSIS 的 `File` 路径**相对 .nsi 所在目录**解析,而我用了主仓的 installer.nsi
(它去找主仓的 build/linux-payload),payload 却 stage 在 tag 的 worktree 里。

改法:`NSI` 可覆盖 —— 在 tag 的 worktree 里构建时用**该 tag 里的** installer.nsi
(与产物同源,也正是可复现发布该有的样子);另加 payload 空载荷预检(空载荷=装不上,
必须直接失败而不是打出一个没内容的安装器)。
2026-09-13 18:29:13 +08:00
8910c8c454 docs: 补两条流水线纪律(脚本必须 set -e;tag worktree 里的驱动脚本)
今天连踩两次,都是"脚本本身"的问题而不是打包逻辑的问题:

1. **没 `set -e`**:`package-windows.sh` 在 tag worktree 里找不到(新脚本只在 main),
   bash 报 No such file or directory 之后**流程照旧往下走**,把只含 4 项的校验和
   传上去覆盖了原本覆盖 10 项的那份 ⇒ 只能把产物下回来重建。
2. **驱动脚本不在 tag 里**:发布件在 tag 的干净 worktree 里构建,而刚补的脚本还没进 tag。
   ⇒ 让脚本支持 `DIST_LINUX` / `BUILD_DIR` / `DIST_RELEASE` 覆盖,用"主仓脚本 + 产物目录
   指向 worktree"来解;文档写清这条约束。

同步进发布技能的同名小节(这两条和"分批上传要全量重算校验和"是同一类:**校验和的完整性
比产物本身更容易被流程吃掉**)。
2026-09-13 18:23:22 +08:00
c83eca5e88 fix(packaging): package-windows.sh 支持 DIST_LINUX/BUILD_DIR/DIST_RELEASE 覆盖
我在 v1.3.10 的 tag worktree 里调这个脚本,而它提交在 main(tag 里当然没有)⇒
`No such file or directory`;又因为脚本没加 `set -e`,它继续往下跑,把只含 4 项
(linux amd64)的校验和传上去,覆盖掉了原本覆盖 10 项的那份。

目录可覆盖后就能「用主仓脚本、产物目录指向 worktree」,两个坑一起消掉。
2026-09-13 18:22:33 +08:00
594496a225 feat(packaging): 补 Windows(WSL) 安装器的驱动脚本,并按变体定向 payload
用户要求:**Windows 的 homed 安装包应当是往 WSL 里安装**。口径本身早已落地
(installer.nsi 注释 + install-via-wsl.ps1 + build.sh 的 WSL 分支),但缺两样东西:

1. **没有驱动脚本**:`build.sh` 里没有 `makensis`,仓库里也没有任何脚本调用它 ——
   build/ 下那几个历史 .exe 是手工打的。新增 `deploy/packaging/package-windows.sh
   <server|client|full> [arch]`:按变体准备 payload、必要时编 waiter.exe、调 makensis、
   把产物落到 dist/release。
2. **payload 不分变体**:`build.sh` 的 `stage_linux_payload` 把 dist/linux 下所有 deb+tar
   全塞进 payload ⇒ 现在 server/full 的 deb 各带 ~719MB 模型,任何变体的安装器都会
   膨胀到 ~2.4GB。而 WSL 侧脚本只取 payload 里的**第一个** `.deb`
   (install-via-wsl.ps1:141)⇒ 按变体只放对应的那一个包。

同时:client/full 需要 Windows GUI payload(HAS_GUI=1),本机无 electron-builder 时
**明确失败并给出命令**,不产出"装完没有界面"的半残包。

docs/git-branching.md §七.5 补上这条口径与三条命令。
2026-09-13 18:13:04 +08:00
56ba1332f3 docs: 补「分批上传时后一轮必须全量重算 SHA256SUMS」
实测踩到:v1.3.10 先传 amd64 的 9 个资产(含只覆盖 amd64 的 SHA256SUMS),
后补 arm64 时按 arm64 那 4 个文件重算 ⇒ 同名附件覆盖 ⇒ amd64 的校验和消失。
校验和是附件的唯一完整性依据,丢了等于没有校验。已同步到技能的同名小节。
2026-09-13 17:35:02 +08:00
1d4f2beeea fix(prompt): 去掉"每轮只能发一次 output_send"的凭空限制;type 缺省即 text
用户现场指出:**qq 插件的输出通道判据太严了**(那条判据在插件侧,已单独修:
`output_send__qq` 不再受"当前会话身份"限制)。同时内核提示词里还有一条**同类的凭空限制**:

  「每轮对话**通常只需调用一次** output_send__{通道名} 即可完成回复。
    仅在内容确实超过单条消息长度上限(如 >4000 字)时才拆分为多条」

可设计上输出是 agent 的**主动调用**:收到一次输入后,可以往**任意(已授权的)通道**
发**任意多次**(分段播报、先回执后结论、同时通知多个通道都合法)。这句话会让模型
自己收起合理的多次输出 —— 而且它不是任何机制的要求,只是当初为压 output-loop 写的
措辞(真正的防环机制是"回执只回 ok、不回传富结果",那条保留)。

改法:
- 提示词改为明确授权:**输出次数与目标通道由你自己决定**,没有「一轮只能发一次」的限制;
  只保留两条真话:单条长度上限(超长拆完整段落)、别反复重发**完全相同**的内容。
- `output_send__*` 的 `type` 参数改为**可选**(缺省 text):判据该拦的是"不知道发什么",
  不是"没写众所周知的默认值"——此前缺 type 会直接失败并让模型重试一次。

判据 3 条(新增 `output_rules_test.go`):提示词不得含输出次数限制且必须显式授权 /
省略 type 时按 text 发送成功且 schema 的 required 只有 payload / 空 payload 仍被拦。

(cherry picked from commit 17ea7fd5f0)
2026-09-13 16:04:16 +08:00
5160d8d4d1 chore(sdk-mirror): qq 插件 1.4.1(输出工具不再受当前会话身份限制)
镜像 SDK 仓的插件修复:被子的中断唤醒的一轮里,父带齐 meta 调 output_send__qq 也被
「可信 QQ 会话身份不完整」拒掉;输出改为先放行(目标由 meta 决定),读取类工具仍限当前会话。
2026-09-13 16:03:28 +08:00
e2500035d5 fix(resident): 子的「轮次」一直显示 0 —— info() 根本没填 Rounds
现象(用户线上联调实录 + 我复验):父侧 `resident_agents` 列出 `输入ch=[timer] 轮次=0
处理表=2` —— **处理表已有两条记录,轮次却是 0**,自相矛盾,容易被读成"子没干活"。

根因:`residentChild.info()` 构造 `ResidentInfo` 时**从来没有填过 Rounds 字段**
(结构体里有这个字段,于是永远输出零值),不是计数漏加。

改法:`Rounds = 已执行轮次数`(调度器执行计数,单调不减)。新增 `Agent.roundsExecuted()`
并写明为什么**不能**用 inputch 处理表条数当轮次:那张表记的是"当前上下文窗口内"的轮次,
压缩会清空(设计 §8.3)—— 用它会让父看到轮次倒退。

判据:inputch 路由测试里补一条断言 —— 子处理完输入后 `info().Rounds > 0`。

(cherry picked from commit cd88b2dfe5)
2026-09-13 15:41:07 +08:00
886ba78b11 fix(scheduler): inputch 划给子后输入只流向子 —— 补上「进内核之前」的输入路由
用户指出的语义(设计稿 §4.1 早已写明):
**inputch 是可分配资源**,「路由发生在**进内核之前**」—— 划给某个 agent 后,
该通道的输入**只流向那个 agent**;outputch 不同,授权是**非独占**的,
父依旧可以通过它发送内容。

而代码里 inputch 划拨只做了**登记**,没有做**路由**:
- 插件注入输入的 io 是**根 agent 的**(`cmd/homed` 里 `pluginReg.SetIOManager(iom)`);
- 唯一消费输入的是「该 io 自己的调度器」(`scheduler.go` 读 `a.io.InputChan()`);
- `ChannelRegistry.Assign` 只把 Owner 写进登记表,**没有任何转发动作**。

⇒ 现场表现(用户线上联调):子挂 `inputch=[timer]`,**timer 的输入却打在父身上**
(日志 `[agent] interrupt from timer/timer`),子侧 `轮次=0` 永远不动。
登记表里的 Owner 于是沦为标签。

改法(按 §4.1 把路由放回"进内核之前"):
- `IOManager` 增加 `InputRouter`(`SetInputRouter`),并把**五处直接入队**收口到
  `deliverInput`:`InjectInput` / `InjectInputSync` / `InjectInputTo` /
  `InjectInputSyncTo` / `InjectInterrupt`(排队与中断两条路都过路由)。
- 内核注入路由器 `Agent.routeInputByOwner`:查 inputch 的 Owner —— 归自己/未分配 ⇒
  本内核处理;归自己的某个驻留子 ⇒ `DeliverRouted` 交给它(**不再进父的队列**);
  归一个不存在的 agent ⇒ **不吞输入**,父兜底 + 留痕(吞掉输入比多处理一条更糟)。
- `DeliverRouted` 是"已路由"的投递口,不再二次路由(避免成环)。
- 同步输入的 `ResponseCh` 随事件一起走 ⇒ 回答由持有者写回同一回程(§4.3)。

判据(新增 6 条):
- io 层:被接管时排队/中断都**不入本内核队列**(且中断确实经过路由)/ 放行与未设
  路由器时与历史行为一致 / `DeliverRouted` 不再触发路由
- 内核层:划给子的 inputch 输入进**子**(子 Executed>0)且**父 Enqueued 不变** /
  归属到不存在的 agent 时父兜底(不吞)/ 未分配的 inputch 仍归父

(cherry picked from commit 4707b05498)
2026-09-13 15:35:59 +08:00
d0997f6279 docs(resident): 补写「子的 io 通道视图 = 对父的实时回退」(N3 落地口径)
输出通道在 io 层就是 Device,由插件登记在父的 IOManager 上;驻留子只共享了 inputch
登记表 ⇒ 子侧 childIO 空壳(现场:子调 output_send__cli 被判「通道不存在或不可用」)。
文档写清:继承方式(SetParentIO)、四个受影响的方法、为什么是实时回退而非快照、
以及回退只解决看得见、授权仍在白名单之后。附线上实测结果(result: ok)。
2026-09-13 15:16:58 +08:00
91c4bc01f1 fix(resident): 驻留子继承父的输出通道 —— 修「子侧 childIO 空壳、子不会发消息」
现场(用户在线上跑驻留子联调,日志实录):
  父 agent 侧「通道装载完整」,子 `demo-resident` 侧 `childIO` 是**空壳**:
  子的 `output_list_channels` 为空、`output_send__<通道>` 一律被判
  「通道 [X] 不存在或不可用」,连 `output_send__*` 工具都不生成 ⇒ 子不会发消息。

根因:**输出通道在 io 层就是 Device**,而它们由插件登记在**父**的 `IOManager` 上。
`SpawnResident` 给子建的是全新 `IOManager`(它确实该有自己的输入入口与 outputCh),
却只共享了 inputch 登记表,**没有继承设备/输出通道视图**:
  - `executeOutputSendTool` → `a.io.GetChannelCapabilities(ch)` 查的是 `devices[ch]` ⇒ 0
  - 投递路径 `a.io.GetDevice(ch).Execute("output", …)` ⇒ nil
  - 工具面 `tooldefs.go` 从 `a.io.ListChannels()` 生成 `output_send__*` ⇒ 空

改法:给 `IOManager` 增加**上级回退**(`SetParentIO`)——驻留子创建时把自己的 io 挂到
父的 io 上,`GetDevice` / `GetChannelCapabilities` / `ListChannels` / `ExecuteTool`
在自己没有时回退到上级。

为什么是**实时回退**而不是创建时复制快照:设备随资源生灭(远程设备上线/掉线以分钟计,
现场日志 60 秒一个来回),复制出来的表转瞬即过期;而回退永远与父一致。
**授权不受影响**:回退只解决"看得见",能不能用仍由各自的 `AllowedOutputs` 白名单把关
(`executeOutputSendTool` 的授权闸 + 工具生成时的过滤都在白名单之后);
自己的登记优先,子可以覆盖/屏蔽同名通道。

判据(新增 5 条):
- io 层:无上级时行为与以前完全一致 / 挂上级后看得见 / **实时**(父新登记立刻可见、
  注销立刻不可见)/ 同名自己的优先且不重复列出 / `ExecuteTool` 同样回退
- 内核层:子看得见父通道 + 真能发出(父通道收到 1 次 output)/ 白名单外被拒且未送达 /
  子工具面只生成授权通道(含 `_help`)/ 父后登记的通道立刻可见 / 默认即完整授权

(cherry picked from commit 8537577123)
2026-09-13 15:09:44 +08:00
fb2db2c304 docs: 两仓文档对齐当前版本状态 + 补发版产物清单;同步 SDK meta 路牌
用户指出:SDK 版本又带 patch 位、agent 自称 1.0.3、两个仓库文档都没更新。

docs/git-branching.md:
1. **§三 状态表**重写(停在 2026-09-12:main 还写 1.3.0、release/v1.2.x 还被当成"本条发布线、
   尚无 tag"、SDK main 还写 1.2.0、完全没有 release/v1.3.x)。现按事实更新,并写明
   `v1.3.0` 是已撤回的坏 tag。
2. **§2.3** 增补:发布线的 `meta.Version` 必须跟着该线已发的最后一个 patch 走;
   只用 `-ldflags -X` 打版本而不改源码会让二进制与源码对不上账(1.3.1–1.3.4 就是这么打的)。
3. **反例表**补两行:人格文本在**播种时**固化版本(生产实例自称 v1.0.3)、
   发布线路牌不随 patch 推进 / 给 SDK 误发 patch tag。并澄清"插值"必须在**渲染时**,
   把算好的结果固化进配置库与写死没有区别。
4. **§七.5 新增"发版产物清单(可复现)"**:核心仓(tar.gz + 3 个 deb + SHA256SUMS,
   校验和必须在全部产物生成后统一算)、SDK 仓(5 平台 hmapdev + SHA256SUMS)、
   上传脚本的用法与两个坑(release 条目必须先存在;`hmapdev_*` 无扩展名不会被自动识别)。
   起因就是本次"推了 tag 却没建 release、没打包"——推 tag ≠ 完成发版。

third_party/homeagent-sdk/meta/meta.go:镜像 SDK 仓 main 的路牌(1.3.0 → 1.4.0)与
版本语义注释更新(1.3.0 已定版 ⇒ 该号归发布线,main 推进)。
2026-09-13 14:41:24 +08:00
ba3ab5a7d9 chore(meta): main 的版本路牌推到 1.4.0(1.3.0 已归 release/v1.3.x 所有)
规范 §2.1 / §七.4:切出 release/v1.3.x 后,1.3.0 就归发布线所有,main 立即推进到
下一个未发布中版本。此前停在 1.3.0 属遗漏 —— 会让 main 构建出来的二进制自称已发布版本。
2026-09-13 14:34:46 +08:00
a4ebcb6e96 fix(config): 播种时不再把版本号写进人格文本 + 存量实例一次性去版本化
用户发现:agent 自报版本 **1.0.3**,内核早已 1.3.x。

根因(两层):
1. `SeedDefaults` 当年用 `fmt.Sprintf("…HΔ-Kernel v%s…", meta.Version)` **在播种时**
   就把版本写进了 `core.agent.system_prompt` —— 装完即冻住,之后每次升级都不会
   去改配置里的文本,于是实例终生自称装机那天的版本。默认模板用 meta.Version
   插值本是"不写死"的做法,但**播种 = 把插值结果固化**,等于写死。
2. `core.agent.personal_prompt`(新人格机制)本身是对的(DefaultPersonaPrompt
   无版本字面量,由 TestDefaultPersonaPromptHasNoVersionLiterals 钉住),
   但旧键仍在系统提示词里说话,模型就照抄旧键的版本。

改动:
- **不再播种** `core.agent.system_prompt`:留空 → 组装时取 cmd/homed 的内置底座
  提示词;人格由 personal_prompt 承载。全新安装不再预置会腐坏的文本。
- 新增 `migrateSeededSystemPrompt()`(在 SeedDefaults 最前,故不被播种标记早退):
  只对"当年那段播种模板"(前缀 + `HΔ-Kernel v<数字>` 字面量双判据)做
  `v<数字>` → `v{{kernel_version}}`;用户自己写的人格卡一律不碰。
  一次性标记 `core.internal.system_prompt_deversion_v1` 守住幂等 ——
  幂等语句不等于语义幂等,重复执行会把用户后来手写的版本号也改掉。
- 与 v1.3.5 的占位符展开配套:占位符在组装系统提示词时按真实构建展开。

回归判据 4 条(`prompt_migration_test.go`):存量卡被去版本化且正文不动 /
迁移只跑一次 / 用户自写卡不动 / 全新安装不播种该键。
2026-09-13 14:34:44 +08:00
f168862eaa fix(prompt): 系统提示词支持版本占位符 —— 人格卡不再写死版本号
现象(用户发现):agent 向用户自报版本是 **1.0.3**,而内核早已 1.3.x。
根因:**人格卡是配置项**,线上 `core.agent.system_prompt` 里写死了
「HΔ-Kernel v1.0.3 型号的家政型 AI 管家助手」——那是当年装机的文本,
之后每次发版都不会去改它,模型于是照抄给用户。默认模板用 `meta.Version`
拼接(`registry.go` 的 `fmt.Sprintf`)所以一直是对的,**只要被自定义过就会漂**。

修法:在 `buildSystemPrompt` 组装处展开占位符,让这类文本跟随真实构建:

  {{kernel_version}} → meta.Version(如 1.3.5)
  {{kernel_commit}}  → 构建 commit
  {{sdk_version}}    → 所兼容 SDK 版本(如 1.3.0)

- 未知占位符**原样保留**:写错了要看得见,而不是被静默换成空串;
- 不含 `{{` 时原样返回(提示词在热路径上);
- 覆盖所有路径:主 agent 与驻留子都经 `buildSystemPrompt`,
  `persona_set` 写入的文本同样在读取时展开(存的是模板,不是渲染结果);
- 配置项描述里写明可用占位符,引导用户别再写死版本。

回归判据 `TestExpandPromptVars`:展开正确 / 内置占位符不残留 /
线上真实人格卡文本能被纠正 / 未知占位符不被吞 / 无占位符不改写。
2026-09-13 14:34:44 +08:00
44cc824b28 chore(sdk-mirror): a2a 1.3.0→1.3.1、acp 1.2.0→1.2.1 的 plg.json 跟上 SDK 仓
SDK 仓 11303e3 升了两个示例插件的版本(补 RegisterInputChannel 后按插件自身语义升 patch),
外层仓镜像里这两个 plg.json 忘了同步 —— 镜像与源头不一致会让"装的是哪个版本"对不上账。
2026-09-13 14:30:56 +08:00
937359b4df feat(pluginmgr): plugin_install 支持本机 path(配合 plugindev_build 的产物)
背景:Agent 现在能自己构建插件了(plugindev 插件封装了 hmapdev),但安装只支持
http(s) URL —— 本地刚构建出来的 `dist/*.hmap` 装不上,链路断在最后一步。
pluginmgr 的 HTTP API 本来就接受 `{path}`(installFromPath),只是工具面没暴露。

改动:`plugin_install` 增加可选 `path`(本机 .hmap 路径),与 `url` 二选一,
同时给出时以 `path` 为准;`path` 必须存在且不是目录。描述里写明
「配合 plugindev_build 的产物用这个」。

于是 Agent 的完整闭环成立:
  plugindev_init → plugindev_build → plugin_install(path) → plgreload
2026-09-13 14:17:11 +08:00
55dc6545f5 perf(memory): 静态词向量改用 float32 存储(省 ~0.65GB 常驻)
生产实测:`[static_embedder] loaded 200000 words`(zh) + `378151 words`(en) = 57.8 万词 × 300 维,
`map[string][]float64` 光向量本体就 **1.29GB**(外加 map 开销 ~0.1-0.2GB),占 homed
4.14GB RSS 的约三分之一。

源数据(fastText 文本格式)本身就是 float32 精度,用 float64 存没有任何收益:
- `words map[string][]float32` / `unkVec []float32`;
- 加载时按 `ParseFloat(..., 32)` 解析(与源精度一致);
- 相似度累加仍在 float64(`sum []float64`,读时提升),计算精度不受影响。

⇒ 向量本体 1.29GB → 0.65GB,**省 0.65GB**。(与配置侧 `#topN` 可叠加:
生产把两份 vec 各限 5 万词后,向量降到 ~0.22GB。)

防复发:`TestStaticEmbedder_VectorMemIsFloat32` 用**编译期类型断言**
(`var typed []float32 = vec`)+ 字节数断言(词数×维数×4)钉住 —— 改回 float64 会直接编译失败。

验证:`go test ./internal/memory/ ./internal/agent/core/ ./internal/nlp/` 全绿。
2026-09-13 14:09:35 +08:00
fddefc78a1 fix(plugin): "只声明出站通道"的告警改为插件加载完成后判定(此前按注册顺序误报 qq)
## 现象

生产日志(v1.3.1 启动)出现:
`[plugin] qq 只声明了输出通道 "qq",已按双向通道兜底登记 inputch;若要明确意图请显式 RegisterInputChannel`
用户据此问"qq 插件你没更新?"

## 查证:qq 没漏,是我的判据错了

- SDK 示例 `example/qq/plugin.go`:`RegisterOutputChannel("qq")` 在 368 行、
  `RegisterInputChannel("qq", {NoMemory:true, Cleaner: inputCleaner})` 在 399 行 —— **先出站后入站**;
- 生产 `plugins/qq/plugin.bin`:版本 1.4.0,且二进制里含 `inputCleaner` 痕迹 ⇒ 确实调用了入站声明;
- 我的兜底告警在 **RegisterOutputChannel 的那一刻**判"有没有入站声明" ⇒ 对"先出站后入站"
  这种完全合法的写法必然误报(a2a/acp/weather 同理)。

## 修法

告警判据从"注册时刻"改为"**插件 Start 结束后最终声明了什么**":

- `regOutput` 只保留兜底登记(功能不变),不再告警;
- 新增 `warnOutputOnlyChannels(plugin)`,在插件加载/重载成功后统一判定:
  遍历该插件**最终**声明过的出站通道,只有始终没有对应入站声明的才告警,
  且措辞改为"内核已兜底登记 inputch,若这是有意为之可忽略"。
- 判据与顺序解耦后,告警才代表真实缺口(例:weather 的 `weather_out` 与
  `weather_in` 名字不同,出站名从未被声明为入站 —— 那条告警就是真的)。

## 验证

- 新增 `TestWarnOutputOnlyChannels`:①先出站后入站(qq 写法)**不告警**;
  ②只声明出站(weather 写法)**告警且只报那一个通道**。
- `go test ./internal/plugin/ ./internal/plugins/...` 全绿。
2026-09-13 13:40:24 +08:00
3f431063e2 chore(sdk-mirror): 同步 SDK 仓 v1.3.1 的文档 —— 通道名会进 LLM 函数名(命名约束)
镜像文件:`third_party/homeagent-sdk/sdk/plugin.go`(`RegisterOutputChannel` 的命名约束)。
SDK 仓对应提交/tag:v1.3.1。

说明:内核 v1.3.1 的 tag 已指向功能修复提交 d17c186,本镜像提交在其之后 ——
文档镜像不参与二进制构建,故不影响已部署产物;功能与文档的对应关系见两仓 tag 说明。
2026-09-13 13:10:38 +08:00
18d7ad3a36 fix(remotedevice): 设备通道名改用 - 分隔并派生合规名(v1.3.0 部署后 agent 完全不应答的根因)
## 事故

v1.3.0 部署到生产后,**整个 agent 不应答**:任何对话都返回
`all 3 providers failed, last error: api error 403: model "claude-opus-5" is not allowed for this key`。
回滚到 1.2.2 立即恢复(部署前 403=0/成功对话=10,部署后 403=5/成功对话=0)。

## 根因(网关日志给出的原文)

```
tier 3 gozen/deepseek-v4.1-flash: api error 400: [invalid_request_error]
  Invalid 'tools[299].function.name': string does not match pattern '^[a-zA...
```

设备的每设备输出通道名叫 `device/<id>`,内核按 `output_send__<通道名>` 生成工具 ⇒
`output_send__device/<id>` 里的 `/` 违反上游函数名规范 `^[a-zA-Z0-9_-]{1,64}$`。
上游不是"拒掉这一个工具",而是**整条请求 400** ⇒ 网关 auto tier 全链条失败
(400/429/503 混在一起)⇒ 内核只能报"所有 provider 都失败"。
两台真实设备(waiter-fnnas / waiter-mainnas)一上线就登记了这种通道,于是必然触发。

## 修法(改插件,不改内核)

初版我在内核里加了"通道名净化 + 反向解析"层。用户否掉了这个方向,理由对:
**通道名是插件自己的声明,不合契约就该改插件**,不该让内核替插件擦屁股。
内核侧改动已全部回退(HEAD 干净)。

插件侧两处:
1. 分隔符 `device/<id>` → `device-<id>`(源码与来源标签统一,不留两套名字)。
2. 设备 id 是**外部输入**(设备自己声明),可能含空格/非 ASCII/超长 ⇒
   `deviceChannelName()` 把它派生为**合规且唯一**的通道名:
   保留 `[A-Za-z0-9_-]`、其它折成 `-`、主体截断到 32 字符(预算 64 = 13+7+32+7+…)、
   发生截断或撞名时追加 id 的 6 位短哈希。同一 id 恒定同名;真名仍用于路由与日志。

核心契约写进了插件注释与 SDK 文档(见 SDK 仓同批提交):名字若来自外部输入,
**在插件侧派生合规名**,内核不会替你净化。

## 验证

- 新增 `TestDeviceChannelNameIsLLMFunctionNameSafe`:恶意 id(空格/符号/非 ASCII/超长/
  会折成同名的两个 id)都必须派生出**合法且互不重复**的通道名与工具名。
  反向验证:把分隔符改回 `/` 即 FAIL。
- 生产两台设备派生结果:`device-waiter-fnnas`、`device-waiter-mainnas`
  ⇒工具名 `output_send__device-waiter-fnnas`(37 字符,合规)。
- 全量 `go test ./...` = 37 包 ok / 0 FAIL;`-race`(remotedevice + core)无 DATA RACE。
2026-09-13 13:10:38 +08:00
466 changed files with 80250 additions and 37231 deletions

10
.gitignore vendored
View File

@ -26,7 +26,8 @@ cmd/gui/dist/
# #
# 外部插件与工具链维护在独立 SDK 仓(决策 sdk_repo_only), # 外部插件与工具链维护在独立 SDK 仓(决策 sdk_repo_only),
# 本仓经 go.mod 的 replace => ./third_party/homeagent-sdk 引用。 # 本仓经 go.mod 的 replace => ./third_party/homeagent-sdk 引用。
# example/ 下已跟踪的 20 个文件(plg.json + plugin.go)早于本规则, # example/ 下已跟踪的 21 个文件(10 个示例的 plg.json + plugin.go,
# 加 qq/plugin_test.go)早于本规则,
# 靠「已跟踪文件不受 .gitignore 影响」保留——这是有意的,不要「修」。 # 靠「已跟踪文件不受 .gitignore 影响」保留——这是有意的,不要「修」。
third_party/homeagent-sdk/bin/ third_party/homeagent-sdk/bin/
third_party/homeagent-sdk/tools/ third_party/homeagent-sdk/tools/
@ -35,6 +36,13 @@ third_party/homeagent-sdk/scripts/
third_party/homeagent-sdk/.gitignore third_party/homeagent-sdk/.gitignore
third_party/homeagent-sdk/README* third_party/homeagent-sdk/README*
third_party/homeagent-sdk/example/ third_party/homeagent-sdk/example/
# 文档站(mkdocs.yml + docs/ + 生成器)属于 SDK 仓,与 README* / tools/ 同理。
# 注意 docs/ 带前导路径限定,够精确:本仓自己的 docs/ 不受影响。
third_party/homeagent-sdk/docs/
third_party/homeagent-sdk/mkdocs.yml
third_party/homeagent-sdk/site_build/
# 主题覆盖目录(只覆盖 footer.html,补备案号)——同属文档站。
third_party/homeagent-sdk/overrides/
.codegraph/ .codegraph/
# codegraph 本地索引配置(含嵌套 SDK 仓放行,仅本地生效) # codegraph 本地索引配置(含嵌套 SDK 仓放行,仅本地生效)

46
.golangci.yml Normal file
View File

@ -0,0 +1,46 @@
# golangci-lint 配置 —— 「超大函数/超大文件」治理的防复发闸门。
#
# 背景:main 上曾有 4 个 ≥300 行函数、12 个 ≥200 行函数(见审查报告)。
# 没有复杂度 linter 是它们能长期存活的直接原因。本配置先以 **warn-only**
# 起步:`issues.exit-code: 0`,只产出清单、不阻断构建。等历史债降到可接受
# 水位后,再把 exit-code 改成 1 收成硬门禁。
#
# 运行:make lint-full(需先 `go install github.com/golangci/golangci-lint/cmd/golangci-lint@latest`)
# 注意:这是 golangci-lint v1 的配置格式(v2 的 `linters.default` 写法不同)。
run:
timeout: 5m
tests: true
linters:
disable-all: true
enable:
- funlen # 函数长度
- gocyclo # 圈复杂度
- lll # 行宽
- dupl # 重复代码
- govet # 与 make lint 对齐的基线
linters-settings:
funlen:
lines: 150
statements: 100
gocyclo:
min-complexity: 30
lll:
line-length: 140
dupl:
threshold: 200
issues:
# 起步阶段不阻断(warn-only)。收紧后改为 1。
exit-code: 0
max-issues-per-linter: 0
max-same-issues: 0
exclude-rules:
# 测试与生成/夹具代码不受长度类规则约束。
- path: _test\.go
linters: [funlen, dupl, gocyclo]
- path: internal/plugin/proc/testdata
linters: [funlen, dupl]
- path: third_party/
linters: [funlen, dupl, gocyclo, lll]

349
Makefile
View File

@ -1,4 +1,22 @@
.PHONY: all build build-cli build-gui clean install test run build-static build-linux-arm64 lint fmt .PHONY: all build build-plain build-cli build-gui clean install test run build-static build-linux-arm64 lint fmt sync-client-versions check-client-versions csrc csrc-test csrc-lint csrc-abi csrc-headers csrc-sanitize csrc-cross csrc-fuzz check-csrc check-csrc-full
# HOMED_TAGS 默认带 onnxruntime:发行版**默认启用**本地向量空间(与
# deploy/packaging/build.sh 保持一致)。
#
# 曾经这里是空 tags,实测的后果(2026-09-15 热部署):`make build` 产出的
# homed 只有 33MB,而 onnxruntime 版是 84MB;启动日志里
# 「multimodal space active: provider=chineseclip」整行消失,少加载一个插件,
# 静态词向量也退化成 fallback——而打包脚本会直接**拒收**这种二进制
# (package-linux.sh 检查 `-tags=.*onnxruntime`)。即「本地随手 make build」
# 与「发行构建」不是同一个东西,部署时无从察觉。
# 需要极简构建时显式 HOMED_TAGS= 关掉。
#
# 注意:内核 C 编解码层(internal/agent/api/ha_codec.c)**不靠 tag 开关**,
# 而是由 cgo 本身决定(`//go:build cgo` / `!cgo`)。原因:它是零依赖纯 C99
# 源码内联编译,不需要任何外部库/工具链前提;而 homed 本就强制 cgo
# (sqlite3 + gojieba),所以 C 路径自然生效,无需额外开关。
# 对比 onnxruntime:那个需要运行期的 libonnxruntime.so,所以必须显式 tag。
HOMED_TAGS ?= onnxruntime
TAG_ARGS = $(if $(HOMED_TAGS),-tags $(HOMED_TAGS),)
BINARY=homed BINARY=homed
CLI_BINARY=waiter CLI_BINARY=waiter
@ -8,22 +26,262 @@ GOCACHE=/tmp/gocache
export GOPATH=/tmp/gopath export GOPATH=/tmp/gopath
BUILD_DIR=build BUILD_DIR=build
PROJECT_ROOT := $(CURDIR) PROJECT_ROOT := $(CURDIR)
VERSION ?= $(shell git describe --tags --dirty 2>/dev/null || echo "0.8.0") # 版本号来源(见 docs/git-branching.md §2.1):
#
# 发布线(release/vX.Y.x):用该线的 tag 描述,产出 v1.3.12 这类正式号。
# main(开发线):**不**用 git describe —— main 上可达的最新 tag 永远属于
# 某条已发布的旧 patch 线(实测:main 可达 tag 是 v1.3.2,而 v1.3.12 打在
# release/v1.3.x 上、不在 main 的祖先路径里),于是 main 构建会自称
# "v1.3.2-192-gxxxxxx" —— 版本号看着像在 1.3.2 补丁线上,实际是下一个
# 中版本的开发态,属于会误导人的路牌。
#
# 所以 main 显式产出 <meta.Version>dev:1.4.0dev。
# meta.Version 由源码声明(internal/meta/meta.go),随发布推进而更新。
# 构建号(距上次 tag 的提交数 + 短 SHA)仍然保留,便于定位具体提交。
VERSION ?= $(shell git describe --tags --dirty 2>/dev/null)
# 开发线(main)强制走 dev 号:以 meta.Version 源码声明为准,加 dev 后缀。
# 不能用「describe 为空」来判断 —— main 上 describe 非空(可达 v1.3.2),
# 但那个号属于已发布的旧 patch 线,对 main 没有版本语义。
# 判定用「是否在发布线分支」而不是「是否等于 main」:detached HEAD(CI 常见)
# 时分支名是 HEAD,若只判 main 就会退回 describe,产出 v1.3.2-192 这种
# 属于旧 patch 线的误导号(实测踩到)。发布线之外的任何状态都走 dev 号。
CURRENT_BRANCH := $(shell git rev-parse --abbrev-ref HEAD 2>/dev/null)
ifneq ($(filter release/v%,$(CURRENT_BRANCH)),)
VERSION := $(VERSION)
else
META_VERSION := $(shell grep -oE 'Version = "[0-9.]+"' internal/meta/meta.go | head -1 | grep -oE '[0-9.]+')
VERSION := $(META_VERSION)dev$(if $(filter --dirty,$(shell git status --porcelain)),+dirty)
endif
COMMIT ?= $(shell git rev-parse --short HEAD 2>/dev/null || echo "unknown") COMMIT ?= $(shell git rev-parse --short HEAD 2>/dev/null || echo "unknown")
BUILD_TIME ?= $(shell date -u '+%Y-%m-%dT%H:%M:%SZ') BUILD_TIME ?= $(shell date -u '+%Y-%m-%dT%H:%M:%SZ')
LDFLAGS = -X gitcode.com/JianFeeeee/HomeAgent/internal/meta.Version=$(VERSION) -X gitcode.com/JianFeeeee/HomeAgent/internal/meta.Commit=$(COMMIT) -X gitcode.com/JianFeeeee/HomeAgent/internal/meta.BuildTime=$(BUILD_TIME) LDFLAGS = -X gitcode.com/JianFeeeee/HomeAgent/internal/meta.Version=$(VERSION) -X gitcode.com/JianFeeeee/HomeAgent/internal/meta.Commit=$(COMMIT) -X gitcode.com/JianFeeeee/HomeAgent/internal/meta.BuildTime=$(BUILD_TIME)
all: build build-cli all: build build-cli
# csrc:C 源码的**独立**产物(静态库 + 契约测试),供 C 侧复用(鸿蒙/嵌入式/C SDK)。
#
# ⚠️ Go 构建**不依赖**它:internal/agent/api/ha_codec.{c,h} 是指向 csrc/ 的
# **符号链接**,cgo 直接编这份源码,而不是链接预构建的 .a。
#
# 为什么是「包内符号链接」而不是别的(历史教训 + 实测,勿回退):
# 1. 不能链静态库:.a 是构建产物、不入库,而发布脚本原先不产出它
# ⇒「不入库 + 不生成」两头空(实测 cannot find csrc/build/libha_codec.a);
# 且交叉编译 linux/arm64 时宿主 x86-64 的 .a 被链进目标产物,
# 报 `file in wrong format`。
# 2. 不能用 `#include "../../../csrc/src/ha_codec.c"`(包外相对包含):
# ★ Go 构建缓存**不跟踪包外被 #include 的 C 文件**,改了 C 源码但缓存命中时
# 会静默沿用旧代码(实测:变异 C 源码后 go test 仍报 ok)。
# 这对「逐步推进 C 化」是致命的——改动无效却无人察觉。
# 3. 包内符号链接:文件在包目录内 ⇒ 缓存按内容哈希正确跟踪
# (实测:改 csrc/ 源文件后 go test 立即判红);
# 同时只有一份权威源(csrc/),无副本漂移、无需同步目标。
#
# csrc 目标本身只服务「C 侧独立使用 + ctest」,不参与 Go 构建链路。
CSRC_DIR=csrc
CSRC_BUILD=$(CSRC_DIR)/build
CSRC_LIB=$(CSRC_BUILD)/libha_codec.a
# ============================ C 编译告警门禁 ============================
#
# 为什么要「零告警」而不是「有告警就看看」:
# 1. 本仓 C 代码量还小(ha_codec.c 约 340 行),任何告警都值得当场修;
# 门禁零成本维持(本地实测 4 个编译器×标准组合全 0 告警)。
# 2. C 侧没有 Go 那套 vet 等价物,告警是**唯一的**静态信号。
# 若是「先攒着」,C 侧会慢慢退化成一堆没人看的噪声,然后没人看。
# 3. -Wconversion 特意包含在内:C→Go 经 cgo 时隐式窄化(如 size_t→int)
# 是真实事故来源(长度字段截断),而它在默认档下是静默的。
#
# -Wpedantic 尤其重要:它抓出「用了 C11 特性但 CFLAGS 写 -std=c99」这类
# 跨工具链不一致(本轮就当场抓到 _Static_assert 一例,见 ha_abi.h)。
CSRC_STD ?= c99
CSRC_WARN_FLAGS = -Wall -Wextra -Wpedantic -Wshadow -Wconversion
CSRC_CFLAGS = -std=$(CSRC_STD) $(CSRC_WARN_FLAGS) -I$(CSRC_DIR)/include
CSRC_SRCS = $(wildcard $(CSRC_DIR)/src/*.c)
CSRC_HDRS = $(wildcard $(CSRC_DIR)/include/*.h)
# 可选的第二编译器:只有一份编译器通过 ≠ C 写法可移植
# (GCC 扩展在 clang 下报错、或反之,都是真实的发布事故)。
CSRC_CC2 ?= clang
csrc: $(CSRC_LIB)
$(CSRC_LIB): $(wildcard $(CSRC_DIR)/src/*.c) $(wildcard $(CSRC_DIR)/include/*.h) $(CSRC_DIR)/CMakeLists.txt
@cmake -S $(CSRC_DIR) -B $(CSRC_BUILD) -DBUILD_TESTS=ON >/dev/null
@cmake --build $(CSRC_BUILD) -j >/dev/null
@echo "Built: $(CSRC_LIB)(C 侧复用,不参与 Go 构建)"
# csrc-test:C 侧契约测试(黄金对照的另一半,见 docs/zh/c-core/llm-orchestration-c.md §五)
csrc-test: csrc
@cd $(CSRC_BUILD) && ctest --output-on-failure
# csrc-lint:C 侧告警门禁(主编译器 + 第二编译器交叉,零告警)
#
# 用 \`-Werror\` 而不是只看输出:只有「告警即失败」才是门禁,
# 否则它只是打印给人看,而人会累。
.PHONY: csrc-lint
csrc-lint:
@echo "== C 告警门禁($(CSRC_STD),$(CSRC_WARN_FLAGS))=="
@for cc in $(CC) $(CSRC_CC2); do \
command -v $$cc >/dev/null 2>&1 || { echo " [SKIP] $$cc 不存在"; continue; }; \
out=$$($$cc $(CSRC_CFLAGS) -Werror -fsyntax-only $(CSRC_SRCS) 2>&1); \
if [ -n "$$out" ]; then \
echo " [FAIL] $$cc 有告警:"; echo "$$out" | head -20; exit 1; \
else \
echo " $$cc: 0 告警 ✓"; \
fi; \
done
# csrc-abi:C 侧 ABI 版本自洽性(编译期断言已在 ha_abi.h 内,这里做运行期核对)
.PHONY: csrc-abi
csrc-abi:
@echo "== C ABI 版本自述 =="
@printf '#include <stdio.h>\n#include "ha_codec.h"\nint main(void){printf("%%d\\n", ha_codec_abi_version());return 0;}\n' > $(CSRC_BUILD)/abi_probe.c 2>/dev/null || mkdir -p $(CSRC_BUILD) && printf '#include <stdio.h>\n#include "ha_codec.h"\nint main(void){printf("%%d\\n", ha_codec_abi_version());return 0;}\n' > $(CSRC_BUILD)/abi_probe.c
@$(CC) $(CSRC_CFLAGS) $(CSRC_BUILD)/abi_probe.c -o $(CSRC_BUILD)/abi_probe $(CSRC_SRCS) 2>/dev/null
@v=$$($(CSRC_BUILD)/abi_probe); \
if [ "$$v" -ge 1000 ] && [ "$$v" -le 99999 ]; then \
echo " ha_codec ABI_VERSION = $$v (major=$$((v/1000)) minor=$$((v%1000))): OK"; \
else \
echo " [FAIL] ABI 版本荒谬:$$v"; exit 1; \
fi
# csrc-sanitize:ASan + UBSan 跑 C 契约测试
#
# 目的:内存错误与未定义行为在 C 侧默认是**静默的**(不崩、结果看起来对),
# 而内核 L1 路径零 malloc 的设计依赖「没有越界写」这一前提。
# C 侧没有 Go 的 -race 等价物,sanitizer 就是这里的关等物。
# 若本机无 libasan/libubsan(交叉工具链常见),明确 SKIP 而非静默跳过。
.PHONY: csrc-sanitize
# ★ 每个测试文件**各自**链接成独立二进制:契约测试每个都带 main,
# 合在一起会「multiple definition of main」——而报错被 2>/dev/null
# 吞掉后会被误报成「本机无 sanitizer」,是个假的 SKIP。
# 故这里逐个构建、逐个跑,任何一个失败都判红。
csrc-sanitize:
@echo "== C 侧 ASan+UBSan =="
@tmp=$$(mktemp -d); \
built=0; \
for t in $(CSRC_DIR)/test/test_*.c; do \
case "$$t" in *fuzz*) continue ;; esac; \
base=$$(basename $$t .c); \
if ! $(CC) $(CSRC_CFLAGS) -fsanitize=address,undefined -fno-omit-frame-pointer \
-o $$tmp/$$base $(CSRC_SRCS) $$t 2>$$tmp/build.log; then \
if grep -qi 'sanitize\|asan\|ubsan' $$tmp/build.log; then \
echo " [SKIP] 本机无 ASan/UBSan 运行库,已跳过"; rm -rf $$tmp; exit 0; \
fi; \
echo " [FAIL] 构建失败 ($$base):" ; head -10 $$tmp/build.log; rm -rf $$tmp; exit 1; \
fi; \
built=1; \
if ASAN_OPTIONS=detect_leaks=1 UBSAN_OPTIONS=print_stacktrace=1:halt_on_error=1 \
$$tmp/$$base > $$tmp/$$base.out 2>&1; then \
echo " ASan+UBSan $$base: PASS"; \
else \
echo " [FAIL] sanitizer 报告 ($$base):"; head -30 $$tmp/$$base.out; rm -rf $$tmp; exit 1; \
fi; \
done; \
rm -rf $$tmp; \
if [ "$$built" = "0" ]; then echo " [FAIL] 没找到任何契约测试"; exit 1; fi
# csrc-headers:头文件自包含性(每个 .h 都能单独编过)
#
# 为什么需要:ha_codec.h 头写了「本头文件是对外契约,签名冻结」,
# 而**头文件能不能自己编过**是另一件事。若头里用到了自己没包含的东西
# (比如用了 int32_t 却没 <stdint.h>),后果是:
# - 在某个翻译单元里恰好被别的头预先包含了 → 静默编过
# - 在别处(鸿蒙/嵌入式/C SDK 直接包含它)→ 报一堆无关的错
# 本轮就靠它抓出 ha_abi.h 的静态断言垫片缺 <assert 类依赖> 类问题。
# 判据:每个头单独编 -fsyntax-only 必须为 0 告警 0 错。
.PHONY: csrc-headers
csrc-headers:
@echo "== 头文件自包含性 =="
@ok=1; \
for h in $(CSRC_HDRS); do \
base=$$(basename $$h); \
inc=$$(dirname $$h); \
out=$$(echo "$$cc" | tr -d '-'; ); \
for cc in $(CC) $(CSRC_CC2); do \
command -v $$cc >/dev/null 2>&1 || continue; \
printf '#include "%s"\nint main(void){return 0;}\n' "$$base" > $(CSRC_BUILD)/hdr_probe.c; \
res=$$($$cc -std=$(CSRC_STD) $(CSRC_WARN_FLAGS) -I$$inc -I$(CSRC_DIR)/include -Werror \
-fsyntax-only $(CSRC_BUILD)/hdr_probe.c 2>&1); \
if [ -n "$$res" ]; then \
echo " [FAIL] $$base 单独包含时失败($$cc):"; echo "$$res" | head -10; ok=0; \
fi; \
done; \
done; \
if [ "$$ok" = "1" ]; then echo " $(words $(CSRC_HDRS)) 个头文件:自包含 OK ✓"; else exit 1; fi
# csrc-fuzz:libFuzzer 跑不变式 + 内存安全(需 clang,无则明确 SKIP)
#
# 这是 C 侧唯一能「持续」而非「等下一次手写用例」的检验。
# ha_codec 的等价契约(与 Go 的 utf8.DecodeRuneInString 一致)在正常输入下
# 永远测不到,只有随机字节能覆盖截断序列/过长编码/代理对/超 U+10FFFF。
# 门禁不能假装通过:无 clang 或无 libFuzzer 时显式 SKIP 并说明。
.PHONY: csrc-fuzz
csrc-fuzz:
@echo "== C 侧 libFuzzer(clang)=="
@if ! command -v $(CSRC_CC2) >/dev/null 2>&1; then \
echo " [SKIP] $(CSRC_CC2) 不存在,无法跑 libFuzzer"; exit 0; \
fi; \
tmp=$$(mktemp -d); \
if ! $(CSRC_CC2) $(CSRC_CFLAGS) -fsanitize=fuzzer,address,undefined -fno-omit-frame-pointer \
-o $$tmp/fz $(CSRC_SRCS) $(CSRC_DIR)/test/test_fuzz_ha_codec.c 2>/dev/null; then \
echo " [SKIP] 无 libFuzzer 运行库(需要 clang 自带),已跳过"; rm -rf $$tmp; exit 0; \
fi; \
SECS=$${FUZZ_SECS:-20}; \
if $$tmp/fz -max_total_time=$$SECS -rss_limit_mb=4096 > $$tmp/fz.log 2>&1; then \
runs=$$(grep -oE 'Done [0-9]+ runs' $$tmp/fz.log | tail -1); \
echo " libFuzzer: PASS($${runs:-完成},$${SECS}s)"; rm -rf $$tmp; \
else \
echo " [FAIL] 模糊测试崩溃:"; tail -30 $$tmp/fz.log; rm -rf $$tmp; exit 1; \
fi
# csrc-cross:交叉编译 C 侧(arm64 是 homed 的真实发布目标之一)
#
# 为什么要单独门禁:Go 侧的 `go build` 不等于 C 代码在该架构上能编。
# C 侧的架构相关问题(endianness 假设、指针宽度、size_t vs int 宽度、
# -fsanitize 不可用)只有真的用目标编译器编一遍才会暴露。
# 与 deploy/packaging/build.sh 的 arm64 目标共用同一套 CC 变量。
.PHONY: csrc-cross
csrc-cross:
@echo "== C 侧交叉编译(linux/arm64)=="
@CC_ARM64=$${CC_ARM64:-aarch64-linux-gnu-gcc}; \
if ! command -v $$CC_ARM64 >/dev/null 2>&1; then \
echo " [SKIP] $$CC_ARM64 不存在(未装交叉工具链)"; exit 0; \
fi; \
ok=1; \
for src in $(CSRC_SRCS); do \
if ! $$CC_ARM64 $(CSRC_CFLAGS) -Werror -fsyntax-only $$src 2>&1 | head -20; then \
ok=0; \
fi; \
done; \
if [ "$$ok" = "1" ]; then \
echo " $$CC_ARM64: 0 告警、编译通过 ✓($(words $(CSRC_SRCS)) 个源文件)"; \
else \
echo " [FAIL] arm64 交叉编译失败"; exit 1; \
fi
# check-csrc:C 侧全部门禁的聚合入口(接进 make test 与 CI)
.PHONY: check-csrc
check-csrc: csrc-lint csrc-abi csrc-headers csrc-sanitize csrc-cross
@echo "== C 基础设施门禁:全部通过 =="
# check-csrc-full:在 check-csrc 基础上加模糊测试(耗时,故分开)
.PHONY: check-csrc-full
check-csrc-full: check-csrc csrc-fuzz
@echo "== C 基础设施门禁(含模糊测试):全部通过 =="
build: build:
@mkdir -p $(BUILD_DIR) @mkdir -p $(BUILD_DIR)
CGO_ENABLED=1 $(GO) build -trimpath -installsuffix dynlink -ldflags '$(LDFLAGS)' -o $(BUILD_DIR)/$(BINARY) ./cmd/homed/ CGO_ENABLED=1 $(GO) build $(TAG_ARGS) -trimpath -installsuffix dynlink -ldflags '$(LDFLAGS)' -o $(BUILD_DIR)/$(BINARY) ./cmd/homed/
@echo "Built: $(BUILD_DIR)/$(BINARY) ($(VERSION))" @echo "Built: $(BUILD_DIR)/$(BINARY) ($(VERSION), tags='$(HOMED_TAGS)')"
@go version -m $(BUILD_DIR)/$(BINARY) | grep -q 'onnxruntime' \
|| echo "WARN: 本次构建不含 onnxruntime,本地向量空间不可用(HOMED_TAGS= 显式关掉时才符合预期)"
@go version -m $(BUILD_DIR)/$(BINARY) | grep -q 'CGO_ENABLED=1' \
|| echo "WARN: 本次构建未启用 cgo,编解码走纯 Go 回退(不应发生)"
build-cli: build-cli:
@mkdir -p $(BUILD_DIR) @mkdir -p $(BUILD_DIR)
CGO_ENABLED=0 $(GO) build -installsuffix dynlink -o $(BUILD_DIR)/$(CLI_BINARY) ./cmd/waiter/ CGO_ENABLED=0 $(GO) build -installsuffix dynlink -ldflags '$(LDFLAGS)' -o $(BUILD_DIR)/$(CLI_BINARY) ./cmd/waiter/
@echo "Built: $(BUILD_DIR)/$(CLI_BINARY)" @echo "Built: $(BUILD_DIR)/$(CLI_BINARY) ($(VERSION))"
build-gui: build-gui:
@cd cmd/gui && npm install --production && npx electron-packager . $(GUI_BINARY) --out=../../$(BUILD_DIR) --overwrite --no-sandbox @cd cmd/gui && npm install --production && npx electron-packager . $(GUI_BINARY) --out=../../$(BUILD_DIR) --overwrite --no-sandbox
@ -34,13 +292,36 @@ build-static:
CGO_ENABLED=1 $(GO) build -tags netgo -installsuffix dynlink -ldflags '-extldflags "-static" $(LDFLAGS)' -o $(BUILD_DIR)/$(BINARY)-static ./cmd/homed/ CGO_ENABLED=1 $(GO) build -tags netgo -installsuffix dynlink -ldflags '-extldflags "-static" $(LDFLAGS)' -o $(BUILD_DIR)/$(BINARY)-static ./cmd/homed/
@echo "Built (static): $(BUILD_DIR)/$(BINARY)-static" @echo "Built (static): $(BUILD_DIR)/$(BINARY)-static"
# build-linux-arm64:交叉编译 homed(真实发布目标之一)。
#
# 两处必须显式给定,否则必然失败(都不是 C 化引入的,但都长期缺覆盖):
# 1. CC/CXX 交叉工具链。缺 CXX 时 cgo 回退到宿主 g++,而宿主编译器不认
# aarch64 汇编,报 `gcc_arm64.S: no such instruction: 'stp x29,x30,[sp,'`。
# deploy/packaging/build.sh:49 一直是对的,此处此前漏了。
# 2. .syso 隔离。cmd/{homed,waiter}/*.syso 是 Windows COFF 资源对象,
# Go 会把同目录 .syso **无条件**链进任何目标;交叉到非 Windows 平台报
# `file format not recognized`。build.sh 有 hide_syso_for_target,此处同样漏了。
CC_ARM64 ?= aarch64-linux-gnu-gcc
CXX_ARM64 ?= aarch64-linux-gnu-g++
build-linux-arm64: build-linux-arm64:
@mkdir -p $(BUILD_DIR) @mkdir -p $(BUILD_DIR)
GOOS=linux GOARCH=arm64 CGO_ENABLED=1 $(GO) build -installsuffix dynlink -ldflags '$(LDFLAGS)' -o $(BUILD_DIR)/$(BINARY)-arm64 ./cmd/homed/ @for f in cmd/homed/*.syso cmd/waiter/*.syso; do \
@echo "Built (arm64): $(BUILD_DIR)/$(BINARY)-arm64" [ -f "$$f" ] || continue; \
mv "$$f" "$$f.hidden"; \
done; \
trap 'for f in cmd/homed/*.syso.hidden cmd/waiter/*.syso.hidden; do \
[ -f "$$f" ] || continue; mv "$$f" "$${f%.hidden}"; done' EXIT; \
GOOS=linux GOARCH=arm64 CGO_ENABLED=1 CC=$(CC_ARM64) CXX=$(CXX_ARM64) \
$(GO) build $(TAG_ARGS) -installsuffix dynlink -ldflags '$(LDFLAGS)' \
-o $(BUILD_DIR)/$(BINARY)-arm64 ./cmd/homed/; \
for f in cmd/homed/*.syso.hidden cmd/waiter/*.syso.hidden; do \
[ -f "$$f" ] || continue; mv "$$f" "$${f%.hidden}"; done; \
trap - EXIT
@echo "Built (arm64): $(BUILD_DIR)/$(BINARY)-arm64 ($$(file $(BUILD_DIR)/$(BINARY)-arm64 | sed 's/.*: //'))"
clean: clean:
rm -rf $(BUILD_DIR) $(BINARY) rm -rf $(BUILD_DIR) $(BINARY) $(CSRC_BUILD)
install: build install: build
-systemctl stop homeagent 2>/dev/null -systemctl stop homeagent 2>/dev/null
@ -52,6 +333,37 @@ install: build
test: test:
$(GO) test ./... $(GO) test ./...
@$(MAKE) csrc-test
@$(MAKE) check-csrc
@$(MAKE) check-codec-cgo-only
# check-codec-cgo-only:钉死「编解码层完全 C 化」这一决定。
#
# 两条断言,缺一不可:
# ① CGO_ENABLED=1 下测试全绿(含黄金对照:C 与纯 Go 参考实现逐值相等)
# ② CGO_ENABLED=0 下**构建必须失败**
#
# 为什么②要断言「失败」而不是「也能编过」:内核已完全 C 化,C 是唯一实现。
# 若有人在 CGO_ENABLED=0 下让整包静默编过(例如加回一个纯 Go 回退),
# 就会同时存在两份语义可能分叉的实现 —— 而 C 侧对畸形 UTF-8 的解码边界
# 一旦与 Go 分叉,只表现为 rune 计数偏差(进而 token 预算与截断点偏移),
# **不会立刻暴露**。所以这里把「不许有第二条路」变成可执行的断言。
#
# 注:这不影响任何现有构建 —— waiter/initconfig/memgc 均不依赖本包
# (go list -deps 实测);homed 本就强制 cgo。
.PHONY: check-codec-cgo-only
check-codec-cgo-only:
@echo "== 编解码层:完全 C 化检查 =="
@CGO_ENABLED=1 $(GO) test -count=1 ./internal/agent/api/ \
&& echo " ① cgo 下测试全绿(含黄金对照): OK"
@if CGO_ENABLED=0 $(GO) build ./internal/agent/api/ 2>/dev/null; then \
echo " [FAIL] CGO_ENABLED=0 下本包竟然构建成功——"; \
echo " 编解码层已完全 C 化,不该存在第二条实现路径。"; \
echo " 若是有意引入回退,请同时更新本检查与 codec_cgo.go 的说明。"; \
exit 1; \
else \
echo " ② CGO_ENABLED=0 下响亮失败(防静默回退): OK"; \
fi
run: build run: build
./$(BUILD_DIR)/$(BINARY) -data /tmp/homeagent ./$(BUILD_DIR)/$(BINARY) -data /tmp/homeagent
@ -61,3 +373,22 @@ fmt:
lint: lint:
$(GO) vet ./... $(GO) vet ./...
# 客户端版本与内核版本同步(唯一事实源 internal/meta.Version)。
# GUI/鸿蒙各有自版本字段,手工改必漂——用脚本拉齐,check 版给门禁用。
sync-client-versions:
@bash deploy/scripts/sync-client-versions.sh
check-client-versions:
@bash deploy/scripts/sync-client-versions.sh --check
# lint-full:在 vet 之外跑 golangci-lint(阈值见 .golangci.yml,起步 warn-only)。
# 未安装时给出可执行的安装提示与跳过原因,而不是静默成功。
.PHONY: lint-full
lint-full:
@if command -v golangci-lint >/dev/null 2>&1; then \
golangci-lint run; \
else \
echo "golangci-lint 未安装,跳过(阈值见 .golangci.yml)"; \
echo " go install github.com/golangci/golangci-lint/cmd/golangci-lint@latest"; \
fi

View File

@ -26,6 +26,16 @@ homed(内核零 IO) ← PluginSDK → 插件(所有 IO 能力)
- **Document 层**:临时记忆,冷数据自动下沉,也支持用户主动提交 - **Document 层**:临时记忆,冷数据自动下沉,也支持用户主动提交
- **Graph 层**:SQLite 图数据库,持久化实体关系和语义记忆,支持蒸馏管道从原始对话中提取三元组 - **Graph 层**:SQLite 图数据库,持久化实体关系和语义记忆,支持蒸馏管道从原始对话中提取三元组
**输入调度:两类别 + 四级中断** — 输入不直接进 LLM,先进调度器。
排队(待办工作)与中断(按"有多不能等"分 L1~L4)两类;高级可抢占低级并保存现场
(中断栈),同级不抢占。L4 只归内核与内核级插件(如 WebUI 终止按钮)。
见 [`assets/docs/zh/ARCHITECTURE.md`](assets/docs/zh/ARCHITECTURE.md) 的「输入调度器与中断机制」。
**驻留式子 agent** — 内核可派驻轻量内核的子 agent(自己的调度器与 temp 图记忆,
共享通道登记表),把长任务/积压交出去并行做。主 agent 忙久了,内核还会把排队输入
交给临时**分诊助手**:简单的直接处理,需要主 agent 的立刻回「忙碌中,请稍候」,
用户不再干等。见 [`docs/zh/resident-subagent-design.md`](docs/zh/resident-subagent-design.md)。
## 架构图 ## 架构图
### 一、消息处理时序 ### 一、消息处理时序
@ -34,6 +44,7 @@ homed(内核零 IO) ← PluginSDK → 插件(所有 IO 能力)
sequenceDiagram sequenceDiagram
participant U as 用户/插件 participant U as 用户/插件
participant IO as IOManager participant IO as IOManager
participant SCH as 输入调度器
participant EV as eventLoop participant EV as eventLoop
participant CTX as RelevanceContext participant CTX as RelevanceContext
participant LLM as LLM+工具循环 participant LLM as LLM+工具循环
@ -41,7 +52,14 @@ sequenceDiagram
participant MEM as 三层记忆 participant MEM as 三层记忆
U->>IO: InjectInput(type, payload) U->>IO: InjectInput(type, payload)
IO->>EV: inputCh IO->>SCH: inputCh
rect lavender
Note over SCH: 两类别 + 四级中断(L1~L4)
SCH->>SCH: 同级不抢占 → 入就绪队列/中断队列
SCH->>SCH: 更高级 → 抢占(现场压中断栈,稍后可恢复)
SCH->>SCH: 转投(主 agent 忙久了 → 交给临时分诊助手)
end
SCH->>EV: 选中一个任务开始跑
rect lavender rect lavender
Note over EV: processTextInput Note over EV: processTextInput
EV->>ST: StageOnInput 插件可改写/短路 EV->>ST: StageOnInput 插件可改写/短路
@ -55,7 +73,7 @@ sequenceDiagram
EV->>MEM: buildSystemPrompt DocQuery摘要+Graph记忆索引+人格+技能 EV->>MEM: buildSystemPrompt DocQuery摘要+Graph记忆索引+人格+技能
EV->>ST: StagePreAction 插件可预拦截 EV->>ST: StagePreAction 插件可预拦截
loop 工具循环 loop 工具循环
LLM->>LLM: drainInterrupts LLM->>LLM: 安全点:中断求值/让位
LLM->>LLM: LLM Chat LLM->>LLM: LLM Chat
LLM->>ST: StagePostAction 插件可修改/短路 LLM->>ST: StagePostAction 插件可修改/短路
alt 无tool call alt 无tool call
@ -110,7 +128,7 @@ flowchart TB
end end
subgraph D[② Document 文件记忆] subgraph D[② Document 文件记忆]
DS[DocStore JSON+TF-IDF] DS[DocStore JSON+TF-IDF]
Q1[Query 摘要自动注入] -->|【相关记忆文档】| SP Q1[QueryScored+crossModalMarkdown] -->|【跨模态相关记忆】| SP
Q2[doc_query LLM主动召回] -->|Consume+删除源| DS Q2[doc_query LLM主动召回] -->|Consume+删除源| DS
Q2 -->|原始时间戳写入上下文| RC Q2 -->|原始时间戳写入上下文| RC
CD[FindColdDocs 72h] -->|docToTriples| G CD[FindColdDocs 72h] -->|docToTriples| G
@ -180,27 +198,44 @@ API 密钥通过 WebUI `http://localhost:8080` 设置页配置,持久化在 SQ
cmd/homed/ 守护进程入口,组装所有子系统 cmd/homed/ 守护进程入口,组装所有子系统
cmd/waiter/ CLI 客户端(Unix socket) cmd/waiter/ CLI 客户端(Unix socket)
internal/ internal/
├── agent/core/ Agent 核心:事件循环、LLM 工具循环、7 阶段管道 ├── agent/core/ Agent 核心:输入调度器(两类别+四级中断)、事件循环、LLM 工具循环、7 阶段管道、驻留子
├── agent/api/ LLM Provider + 8 个 Lua 适配器 ├── agent/api/ LLM Provider(Lua 适配层:provider.go 调 vm)
├── memory/ 三层记忆:Graph(SQLite) / Document(JSON+TF-IDF) / Text(JSONL) + StaticEmbedder(预训练词嵌入/TF-IDF回退) + CleanTemplateText(去模版) ├── memory/ 三层记忆:Graph(SQLite) / Document(JSON+TF-IDF) / Text(JSONL) + StaticEmbedder(预训练词嵌入/TF-IDF回退) + CleanTemplateText(去模版)
├── knowledge/ 知识库(文件系统 + TF-IDF) ├── knowledge/ 知识库(文件系统 + TF-IDF)
├── plugin/ 插件注册表 + 子进程加载器(stdio RPC + 共享内存段 + 事件环) ├── plugin/ 插件注册表 + 子进程加载器(stdio RPC + 共享内存段 + 事件环)
├── plugins/ 内置 11 个插件(webui/cli/timer/cmd/mcp/clawhubadapter/agentcli/healthcheck/pluginmgr/files/cfgmgr) ├── plugins/ 内置 18 个插件(webui/cli/timer/cmd/mcp/files/cfgmgr/agentcli/healthcheck/pluginmgr/clawhubadapter/multimodal/remotedevice/ai_image/localuse/skillmgr/data 等)
├── sdk/ PluginSDK(Tool/Stage/Event 三通道) ├── sdk/ PluginSDK(Tool/Stage/Event 三通道)
├── config/ SQLite 配置中心 ├── config/ SQLite 配置中心
├── events/ 事件总线 ├── events/ 事件总线
└── internal/lua/adapters/ 8 个 LLM 协议适配器脚本 └── internal/lua/adapters/ 10 个 LLM 协议适配器脚本
外部插件开发见 [homeagent-sdk](https://gitcode.com/JianFeeeee/homeagent-sdk) 仓库,使用 `hmapdev` 工具链开发,参考 `example/` 目录下的 Go 和 Lua 示例 外部插件开发见 [homeagent-sdk](https://gitcode.com/JianFeeeee/homeagent-sdk) 仓库,使用 `hmapdev` 工具链开发,参考 `example/` 目录下的 Go 和 Lua 示例
``` ```
## 项目状态 ## 项目状态
**v1.3.x 线**(v1.3.1–v1.3.12,最新已发布)—— **驻留式子 agent** + **输入调度器重做**。
- **驻留式子 agent**:内核可派驻轻量内核的子 agent(自己的调度器、自己的 temp 图记忆、
共享通道登记表)。父经 `resident_agents`(list/create/send/inspect/compress/reclaim/destroy)
派活与收活;inputch 可划给子,输入**在进内核之前**就已路由到子。
- **输出通道可寻址到具体 agent**:`AllowedOutputs` 授权集合(三处过滤点一致),
父/子之间可互相投递;设备能力也 outputch 化(每设备一个 `device/<id>` 通道)。
- **输入调度器**:排队/中断两类别 + 四级中断(L1~L4)+ 抢占/挂起/恢复/中断栈;
同级不抢占、有饥饿防护与抢占冷却;L4 只归内核与内核级插件(WebUI 终止按钮)。
- **轻量内核 profile**:子的记忆面收窄为「传统上下文 + 图记忆」(窄接口,
主库以 query_only 受限句柄打开,写走自己的 temp 实例)。
- **积压及时反馈**(后续线):主 agent 长时间忙时,内核把排队输入交给临时**分诊助手** ——
简单的直接处理并回复,需要主 agent 的立刻回「忙碌中,请稍候」,用户不再干等十几分钟。
- 修掉一批真实缺陷:销毁驻留子时入站 inputch(`child/<id>`)注册残留、
子的轮次永远显示 0(`info()` 根本没填)、子侧 childIO 空壳(未继承父的输出通道)、
设备心跳 pong 忘了 Flush(每 60 秒掉线)、Lua 插件桥与 SDK 1.3.0 对齐。
**v1.2.0** — 统一多模态向量空间 + 媒体升为图记忆一等节点 + 数据面全量迁到共享内存。 **v1.2.0** — 统一多模态向量空间 + 媒体升为图记忆一等节点 + 数据面全量迁到共享内存。
- **模型中立的统一向量空间**:内核不再适配任何具体模型,只提供公共 provider SPI - **模型中立的统一向量空间**:内核不再适配任何具体模型,只提供公共 provider SPI
(`pkg/embedding`:`Modality` / `Input{Data,MIME}` / `Info{Dimension,Fingerprint,Modalities}` (`pkg/embedding`:`Modality` / `Input{Data,MIME}` / `Info{Dimension,Fingerprint,Modalities}`
+ 名字注册表),实现在 `providers/*`。默认 **Chinese-CLIP ViT-B/16** —— text 与 image + 名字注册表),实现在 `providers/*`。默认 **Chinese-CLIP ViT-B/16** —— text 与 image
落在**同一空间**(512 维、指纹 `cd2a495cf990`、Apache-2.0、独立实测常驻约 1.15GB); 落在**同一空间**(512 维、指纹 `cd2a495cf990`、Apache-2.0;实测加载峰值 1.59GB、静置回收后稳态约 0.89GB);
`qwen3vl` 保留(2048 维、常驻约 9.4GB,供内存充足或将来要视频的机器切回)。 `qwen3vl` 保留(2048 维、常驻约 9.4GB,供内存充足或将来要视频的机器切回)。
文本检索仍由既有词向量 / TF-IDF 兜底:CLIP 双塔的**纯文本语义弱于 MLLM 型嵌入器**, 文本检索仍由既有词向量 / TF-IDF 兜底:CLIP 双塔的**纯文本语义弱于 MLLM 型嵌入器**,
这是已知并写进文档的代价。 这是已知并写进文档的代价。
@ -221,6 +256,19 @@ internal/
> 以下历史条目保留原文以呈现演进,其中两条机制**已在 v1.2.0 移除**: > 以下历史条目保留原文以呈现演进,其中两条机制**已在 v1.2.0 移除**:
> 「媒体以 `[<mime> <短digest>] <描述>` 标记参与检索」(描述式索引)与「媒体引用计数式 GC」。 > 「媒体以 `[<mime> <短digest>] <描述>` 标记参与检索」(描述式索引)与「媒体引用计数式 GC」。
>
> 另有**一处许可口径已变更**(2026-09-24):上面 v1.2.0 条目里的「插件静态链接 SDK 故须同许可」
> **自今日起不成立**。SDK 改以 **MIT** 发布(宽松许可,不继承内核的 AGPL),故外部插件**不是**
> 本项目的衍生作品,作者可自行选择许可(含闭源、商业、私有),亦不受 §13 网络条款约束。
> 原文保留以呈现当时的口径。
>
> 另有**两项性能断言的量纲需要更正**(2026-09-20 实测):
> 「崩溃到恢复 <1s」不成立 —— 崩溃后是**线性退避重启**,即 1s / 2s / 3s(`procRestartBackoff=1s × 第 n 次`),
> 首次重启就要等 1s。且 5 分钟窗口内第 **4** 次崩溃即停止自动重启待人工介入(`procMaxRestarts=3`,判定为 `n > 3`)。
> 该断言写下时(v1.0.0)退避值已是 1s,故从未成立。
> 「RPC 往返 p50 24.1µs」与当前实测同量级但不吻合:本机 `BenchmarkToolInvoke` 实测
> inline/small **30.4µs**、frame/small 51.5µs、inline/large 767µs、frame/large 398µs。
> 保留原文不修改,以免伪造历史。
**v1.1.1** — 多模态贯通**插件边界**。v1.1.0 让记忆系统支持了二进制多媒体节点,但那条链路只对内核自己开放;本版打通到插件与模型。公开 SDK 新增媒体字段与三个媒体注入接口(配套 [SDK v1.1.0](https://gitcode.com/JianFeeeee/homeagent-sdk/releases/tag/v1.1.0),整条 1.1.x 线共用),内核实现对应四个 RPC。桥接层此前在**静默裁字段**:插件交进来的 `Confidence`/类型/`SentenceText` 全被丢弃、`Doc` 只留三个字段、`Remove` 不解引用(媒体永久算「被引用」,GC 收不掉)。`processTextInput`/`processMediaInput` 归一成一条 `processInput`,媒体路径由此获得它一直缺的去重、`no_memory`、通道 `Cleaner`、中断语义、`EventRawInput`。修掉三处真实缺陷:**用户发的图从来没出现在 WebUI 聊天记录里**(媒体路径发布 map 而订阅方断言 string)、**`memory_commit` 的 `sentence_text` 从未暴露给模型**(而它是媒体绑定链的必经环节)、**`PluginSDK` 两处并发竞态**(`-race` 实测 11 处,插件重载瞬间偶发 nil 解引用崩溃)。 **v1.1.1** — 多模态贯通**插件边界**。v1.1.0 让记忆系统支持了二进制多媒体节点,但那条链路只对内核自己开放;本版打通到插件与模型。公开 SDK 新增媒体字段与三个媒体注入接口(配套 [SDK v1.1.0](https://gitcode.com/JianFeeeee/homeagent-sdk/releases/tag/v1.1.0),整条 1.1.x 线共用),内核实现对应四个 RPC。桥接层此前在**静默裁字段**:插件交进来的 `Confidence`/类型/`SentenceText` 全被丢弃、`Doc` 只留三个字段、`Remove` 不解引用(媒体永久算「被引用」,GC 收不掉)。`processTextInput`/`processMediaInput` 归一成一条 `processInput`,媒体路径由此获得它一直缺的去重、`no_memory`、通道 `Cleaner`、中断语义、`EventRawInput`。修掉三处真实缺陷:**用户发的图从来没出现在 WebUI 聊天记录里**(媒体路径发布 map 而订阅方断言 string)、**`memory_commit` 的 `sentence_text` 从未暴露给模型**(而它是媒体绑定链的必经环节)、**`PluginSDK` 两处并发竞态**(`-race` 实测 11 处,插件重载瞬间偶发 nil 解引用崩溃)。
@ -265,7 +313,12 @@ make test # go test ./...
make install # 安装到系统 make install # 安装到系统
``` ```
依赖:Go 1.25+, CGo (go-sqlite3), Linux/Windows。 依赖:Go 1.25+, CGo (go-sqlite3), Linux。
> `homed` 需 Linux(依赖 fd 继承与共享内存段的段内偏移解引用,见
> `cmd/homed/platform_windows.go`);Windows 上只构建 `waiter.exe`,
> `homed` 跑在 WSL2 里(见「下载」)。macOS 可构建 `waiter`/`initconfig`,
> `homed` 需在原生 macOS 构建。
## 许可 ## 许可
@ -275,8 +328,14 @@ make install # 安装到系统
**通过网络提供服务时也要向使用者提供源码**(§13 Remote Network Interaction)。 **通过网络提供服务时也要向使用者提供源码**(§13 Remote Network Interaction)。
即:任何人把改过的 HomeAgent 对外提供网络服务,都必须让该服务的使用者拿到改动后的源码。 即:任何人把改过的 HomeAgent 对外提供网络服务,都必须让该服务的使用者拿到改动后的源码。
插件与本项目通过公开 SDK **静态链接**(SDK 源码会进入插件二进制),因此插件是本项目的 插件与本项目通过公开 [homeagent-sdk](https://gitcode.com/JianFeeeee/homeagent-sdk) 静态链接
衍生作品,需以相同许可发布;子进程隔离不改变这一点,因为被链接的是 SDK 代码本身。 (SDK 源码会进入插件二进制),但那个仓**以 MIT 发布**——MIT 是宽松许可,拿到授权的代码不继承
本项目的 AGPL。因此**外部插件不是本项目的衍生作品**,作者可自行选择许可(含闭源、商业、私有),
既不必同许可、也不受 §13 网络条款约束。第三方插件生态的安全与活跃正建立在这条之上。
边界很清楚:**AGPL 覆盖内核与随包内置插件**(`homed`、`internal/`、`internal/plugins/` 下 18 个内置插件);
**MIT 覆盖公开 SDK**(`sdk/`,`go.mod` 零外部依赖、只依赖 Go 标准库,不引用内核任何代码)。
子进程隔离在这里不重要了——决定许可的是被链接的 SDK 代码本身,而它是 MIT。
### 随包分发的第三方组件 ### 随包分发的第三方组件

View File

@ -32,6 +32,19 @@ plane). A plugin crash cannot take down the kernel and it restarts automatically
- **Document Layer**: Temporary memory with automatic cold data sinking, also supports user-initiated submissions - **Document Layer**: Temporary memory with automatic cold data sinking, also supports user-initiated submissions
- **Graph Layer**: SQLite graph database, persists entity relationships and semantic memory, supports distillation pipelines to extract triples from conversations - **Graph Layer**: SQLite graph database, persists entity relationships and semantic memory, supports distillation pipelines to extract triples from conversations
**Input Scheduling: 2 classes + 4 interrupt levels** — Input does not go straight to the LLM;
it first enters the scheduler. Two classes (queued = pending work, interrupt = ranked L1–L4 by
"how urgent") with preemption and frame saving (interrupt stack); same level never preempts
same level. L4 belongs only to the kernel and kernel-level plugins (e.g. the WebUI stop button).
See "Input Scheduler & Interrupt Mechanism" in [`assets/docs/en/ARCHITECTURE.md`](assets/docs/en/ARCHITECTURE.md).
**Resident sub-agents** — The kernel can station lightweight-kernel child agents (their own
scheduler and temp graph memory, sharing the channel registry) to run long or backlogged work
in parallel. When the main agent stays busy, the kernel hands queued input to a temporary
**triage assistant**: simple items are handled directly, items needing the main agent get an
immediate "busy, please wait" — users no longer wait in silence.
See [`docs/zh/resident-subagent-design.md`](docs/zh/resident-subagent-design.md).
## Architecture Diagrams ## Architecture Diagrams
### 1. Message Processing Sequence ### 1. Message Processing Sequence
@ -40,6 +53,7 @@ plane). A plugin crash cannot take down the kernel and it restarts automatically
sequenceDiagram sequenceDiagram
participant U as User/Plugin participant U as User/Plugin
participant IO as IOManager participant IO as IOManager
participant SCH as Input Scheduler
participant EV as eventLoop participant EV as eventLoop
participant CTX as RelevanceContext participant CTX as RelevanceContext
participant LLM as LLM+Tool Loop participant LLM as LLM+Tool Loop
@ -47,7 +61,14 @@ sequenceDiagram
participant MEM as Three-Layer Memory participant MEM as Three-Layer Memory
U->>IO: InjectInput(type, payload) U->>IO: InjectInput(type, payload)
IO->>EV: inputCh IO->>SCH: inputCh
rect lavender
Note over SCH: 2 task classes + 4 interrupt levels (L1-L4)
SCH->>SCH: same level never preempts -> ready/interrupt queue
SCH->>SCH: higher level -> preempt (frame pushed to interrupt stack)
SCH->>SCH: offload (main agent busy too long -> temporary triage assistant)
end
SCH->>EV: pick one task and run it
rect lavender rect lavender
Note over EV: processTextInput Note over EV: processTextInput
EV->>ST: StageOnInput Plugin can rewrite/short-circuit EV->>ST: StageOnInput Plugin can rewrite/short-circuit
@ -61,7 +82,7 @@ sequenceDiagram
EV->>MEM: buildSystemPrompt DocQuery summary+Graph memory index+Persona+Skills EV->>MEM: buildSystemPrompt DocQuery summary+Graph memory index+Persona+Skills
EV->>ST: StagePreAction Plugin can pre-intercept EV->>ST: StagePreAction Plugin can pre-intercept
loop Tool loop loop Tool loop
LLM->>LLM: drainInterrupts LLM->>LLM: safe point: interrupt eval / yield
LLM->>LLM: LLM Chat LLM->>LLM: LLM Chat
LLM->>ST: StagePostAction Plugin can modify/short-circuit LLM->>ST: StagePostAction Plugin can modify/short-circuit
alt No tool call alt No tool call
@ -169,28 +190,53 @@ API keys are configured via WebUI `http://localhost:8080` settings page, persist
cmd/homed/ Daemon entry, assembles all subsystems cmd/homed/ Daemon entry, assembles all subsystems
cmd/waiter/ CLI client (Unix socket) cmd/waiter/ CLI client (Unix socket)
internal/ internal/
├── agent/core/ Agent core: event loop, LLM tool loop, 7-stage pipeline ├── agent/core/ Agent core: input scheduler (2 classes + 4 levels), event loop, LLM tool loop, 7-stage pipeline, residents
├── agent/api/ LLM Provider + 8 Lua adapters ├── agent/api/ LLM Provider (Lua adapter layer: provider.go drives the vm)
├── memory/ Three-layer memory: Graph(SQLite) / Document(JSON+TF-IDF) / Text(JSONL) + StaticEmbedder(pretrained word embedding/TF-IDF fallback) + CleanTemplateText(de-template) ├── memory/ Three-layer memory: Graph(SQLite) / Document(JSON+TF-IDF) / Text(JSONL) + StaticEmbedder(pretrained word embedding/TF-IDF fallback) + CleanTemplateText(de-template)
├── knowledge/ Knowledge base (filesystem + TF-IDF) ├── knowledge/ Knowledge base (filesystem + TF-IDF)
├── plugin/ Plugin registry + subprocess loader (stdio RPC + shared memory segment + event ring) ├── plugin/ Plugin registry + subprocess loader (stdio RPC + shared memory segment + event ring)
├── plugins/ 11 built-in plugins (webui/cli/timer/cmd/mcp/clawhubadapter/agentcli/healthcheck/pluginmgr/files/cfgmgr) ├── plugins/ 18 built-in plugins (webui/cli/timer/cmd/mcp/files/cfgmgr/agentcli/healthcheck/pluginmgr/clawhubadapter/multimodal/remotedevice/ai_image/localuse/skillmgr/data, ...)
├── sdk/ PluginSDK (Tool/Stage/Event three channels) ├── sdk/ PluginSDK (Tool/Stage/Event three channels)
├── config/ SQLite config center ├── config/ SQLite config center
├── events/ Event bus ├── events/ Event bus
└── internal/lua/adapters/ 8 LLM protocol adapter scripts └── internal/lua/adapters/ 10 LLM protocol adapter scripts
External plugin development: see [homeagent-sdk](https://gitcode.com/JianFeeeee/homeagent-sdk) repo, use `hmapdev` toolchain, refer to Go and Lua examples in `example/` External plugin development: see [homeagent-sdk](https://gitcode.com/JianFeeeee/homeagent-sdk) repo, use `hmapdev` toolchain, refer to Go and Lua examples in `example/`
``` ```
## Project Status ## Project Status
**v1.3.x line** (v1.3.1–v1.3.12, latest released) — **resident sub-agents** + **input scheduler rework**.
- **Resident sub-agents**: the kernel can station lightweight-kernel child agents (their own
scheduler, their own temp graph memory, sharing the channel registry). The parent dispatches
and collects work via `resident_agents` (list/create/send/inspect/compress/reclaim/destroy).
An inputch can be assigned to a child, so input is routed to it **before entering the kernel**.
- **Output channels addressable to a specific agent**: the `AllowedOutputs` grant set
(consistent across all three filter points) lets parent/child deliver to each other;
device capabilities became output channels too (one `device/<id>` per device).
- **Input scheduler**: two task classes (queued/interrupt) + four interrupt levels (L1–L4)
+ preempt/suspend/resume/interrupt-stack; same level never preempts same level, with a
starvation guard and preemption cooldown. L4 belongs only to the kernel and kernel-level
plugins (e.g. the WebUI stop button).
- **Lightweight kernel profile**: a child's memory surface narrows to "conventional context
+ graph memory" (narrow interface; the main graph opens as a query_only handle, writes go
to its own temp instance).
- **Backlog timely feedback** (later in the line): when the main agent is busy for a long time,
the kernel hands queued input to a temporary **triage assistant** — simple items are handled
directly, items needing the main agent get an immediate "busy, please wait", so users no
longer wait 10+ minutes in silence.
- Fixed a batch of real defects: inbound inputch (`child/<id>`) registration leak on resident
destruction, a child's round count always showing 0 (`info()` never filled it), an empty
child-side childIO (output channels not inherited), device heartbeat pong missing Flush
(dropping every 60s), and Lua plugin bridge alignment with SDK 1.3.0.
**v1.2.0** — unified multimodal vector space, media promoted to first-class graph memory, and the whole data plane moved into shared memory. **v1.2.0** — unified multimodal vector space, media promoted to first-class graph memory, and the whole data plane moved into shared memory.
- **Model-neutral unified embedding space**: the kernel no longer adapts to any specific model. - **Model-neutral unified embedding space**: the kernel no longer adapts to any specific model.
It exposes only a public provider SPI (`pkg/embedding`: `Modality` / `Input{Data,MIME}` / It exposes only a public provider SPI (`pkg/embedding`: `Modality` / `Input{Data,MIME}` /
`Info{Dimension,Fingerprint,Modalities}` + a name registry), with implementations under `Info{Dimension,Fingerprint,Modalities}` + a name registry), with implementations under
`providers/*`. Default: **Chinese-CLIP ViT-B/16** — text and image land in the **same space** `providers/*`. Default: **Chinese-CLIP ViT-B/16** — text and image land in the **same space**
(512-dim, fingerprint `cd2a495cf990`, Apache-2.0, ~1.15GB RSS measured standalone); (512-dim, fingerprint `cd2a495cf990`, Apache-2.0; measured ~1.59GB peak on load, settling to ~0.89GB steady-state);
`qwen3vl` is kept (2048-dim, ~9.4GB) for machines with headroom or future video. Text search `qwen3vl` is kept (2048-dim, ~9.4GB) for machines with headroom or future video. Text search
still falls back to the existing word-vector / TF-IDF path — a CLIP dual tower's pure-text still falls back to the existing word-vector / TF-IDF path — a CLIP dual tower's pure-text
semantics are **weaker than an MLLM-style embedder**, a cost documented rather than hidden. semantics are **weaker than an MLLM-style embedder**, a cost documented rather than hidden.
@ -217,6 +263,23 @@ External plugin development: see [homeagent-sdk](https://gitcode.com/JianFeeeee/
> The historical entries below are kept verbatim to show the evolution; two mechanisms in them > The historical entries below are kept verbatim to show the evolution; two mechanisms in them
> were **removed in v1.2.0**: text-description-based media indexing, and reference-counted media GC. > were **removed in v1.2.0**: text-description-based media indexing, and reference-counted media GC.
>
> **One licensing statement has also changed** (2026-09-24): "statically linked plugins must match"
> in the v1.2.0 entry below **no longer holds**. The SDK is now released under **MIT** (a permissive
> license that does not inherit the kernel's AGPL), so external plugins are **not** derivative works
> of this project: authors choose their own license (closed-source, commercial or private included)
> and are not bound by §13. The original text is kept to show the position at the time.
>
> **Two performance claims also need correcting** (measured 2026-09-20):
> "crash-to-recovery under 1s" does not hold — restarts are **linearly backed off**, i.e.
> 1s / 2s / 3s (`procRestartBackoff=1s × nth crash`). Even the *first* restart waits 1s.
> And the **4th** crash within a 5-minute window stops automatic restarts pending human
> intervention (`procMaxRestarts=3`, tested as `n > 3`).
> The backoff was already 1s when this claim was written (v1.0.0), so it never held.
> "RPC round-trip p50 24.1µs" is the right order of magnitude but does not match current
> measurements: `BenchmarkToolInvoke` on this machine gives inline/small **30.4µs**,
> frame/small 51.5µs, inline/large 767µs, frame/large 398µs.
> The original text is left unedited rather than rewritten, so the history isn't falsified.
**v1.1.1** — Multimodal reaches the **plugin boundary**. v1.1.0 gave the memory system binary **v1.1.1** — Multimodal reaches the **plugin boundary**. v1.1.0 gave the memory system binary
multimedia nodes, but that path was open only to the kernel itself; this release opens it to multimedia nodes, but that path was open only to the kernel itself; this release opens it to
@ -279,7 +342,12 @@ make test # go test ./...
make install # Install to system make install # Install to system
``` ```
Dependencies: Go 1.25+, CGo (go-sqlite3), Linux/Windows. Dependencies: Go 1.25+, CGo (go-sqlite3), Linux.
> `homed` requires Linux (it relies on fd inheritance and intra-segment offset
dereferencing of the shared memory region; see `cmd/homed/platform_windows.go`).
On Windows only `waiter.exe` is built and `homed` runs under WSL2 (see Downloads).
macOS can build `waiter`/`initconfig`; `homed` must be built on native macOS.
## License ## License
@ -291,9 +359,19 @@ source when you distribute the software, **you must also offer the source to use
with it over a network** (§13, Remote Network Interaction). Anyone running a modified HomeAgent with it over a network** (§13, Remote Network Interaction). Anyone running a modified HomeAgent
as a network service therefore has to make the modified source available to that service's users. as a network service therefore has to make the modified source available to that service's users.
Plugins are **statically linked** against this project through the public SDK (the SDK source Plugins are **statically linked** against this project through the public
ends up inside the plugin binary), so plugins are derivative works and must be released under [homeagent-sdk](https://gitcode.com/JianFeeeee/homeagent-sdk) (the SDK source ends up inside the
the same license. Process isolation does not change this — what is linked is the SDK code itself. plugin binary), but that repository is released under **MIT** — a permissive license, so code
received under it does **not** inherit this project's AGPL. External plugins are therefore **not
derivative works of this project**: authors pick their own license (closed-source, commercial or
private included), with no same-license obligation and no §13 network clause. The safety and
vitality of the third-party plugin ecosystem rest on this.
The boundary is clean: **AGPL covers the kernel and the bundled plugins** (`homed`, `internal/`,
the 18 built-in plugins under `internal/plugins/`); **MIT covers the public SDK** (`sdk/`, whose
`go.mod` has zero external dependencies and imports only the Go standard library — it never
references any kernel code). Process isolation is beside the point here — what decides the
license is the linked SDK code itself, and that code is MIT.
### Third-party components shipped with the packages ### Third-party components shipped with the packages

View File

@ -455,7 +455,74 @@ Extended fields:
- Relation extension: Confidence - Relation extension: Confidence
## Interrupt Mechanism ## Input Scheduler & Interrupt Mechanism
Inputs do not go straight to the LLM — they first enter the **input scheduler**
(`internal/agent/core/scheduler.go`). Full design:
[`docs/zh/input-scheduler-design.md`](../../../docs/zh/input-scheduler-design.md).
### Two task classes
| Class | Level | Meaning |
|-------|-------|---------|
| `TaskQueued` | none (always 0) | Pending work. Any interrupt (≥ L1) preempts it |
| `TaskInterrupt` | L1–L4 | "How urgent is this", declared by the source via `InjectOptions.Priority` |
### Four interrupt levels
| Level | Meaning | Typical source |
|-------|---------|----------------|
| L1 Background | Fully deferrable | QQ/WeChat messages, bulk notifications |
| L2 Message | General notice | Plugin hints that should be seen soon but aren't urgent |
| L3 Interactive | Needs timely handling | Timer expiry, terminal output, resident-agent reports |
| L4 Critical | **Kernel-exclusive** | panic, kernel events, kernel-level plugin stop button |
When no level is declared it defaults to **L1** — "explicit is a privilege", so a new
plugin never gets preemption rights by accident. L4 declared by an external plugin is
**clamped to L3** (`clampPluginLevel`).
### Preemption and suspension
- **Same level never preempts same level** (`canPreempt` requires strictly greater) —
this is why messages normally wait for the running task to finish.
- A preempted task is pushed onto the **interrupt stack** (LIFO) with its frame saved,
and resumed later; the stack is never re-sorted by priority.
- **Starvation guard**: preemption count raises the effective level
(`effectiveLevel = Level + min(PreemptCount, 2)`, capped at L4).
- **Preemption cooldown**: a just-preempted task cannot be preempted again for
`preemptCooldown` (2s), so a high-priority stream cannot interrupt the same task forever.
- The interrupt stack depth is structurally bounded (chain = queued ← L1 ← L2 ← L3 ← L4).
### Stop (user presses stop / `/stop`)
Stop is not an empty interrupt. It does two things: ① cancel the current LLM inference;
② short-circuit the x messages **already queued at the moment of stop** during their
pre-action phase (`cancelBudget` snapshot), instead of running them as new input.
Inputs arriving **after** the stop are unaffected.
`PendingInputs()` must include the segment still sitting in `io.inputCh` (not yet moved
into the queue by `pumpInbox`) — during a stop the scheduler is usually busy running a
task, and counting only `sched.queue` yields 0.
### Resident sub-agents and timely feedback
Design: [`docs/zh/resident-subagent-design.md`](../../../docs/zh/resident-subagent-design.md).
- A **resident** is an independent lightweight-kernel agent: its own scheduler, its own
temp graph memory, sharing the channel registry.
- Parent→child control plane: `resident_agents`
(list / create / send / inspect / compress / reclaim / destroy).
- **Backlog feedback**: when the main agent is busy for a long time (default > 5m,
configurable), the kernel hands queued inputs to a temporary **triage assistant**
(`offload_*` config): simple ones are handled directly, ones needing the main agent
get an immediate "busy, please wait". Users no longer wait 10+ minutes in silence.
- The triage assistant gets **no inputch** (it receives no plugin user input) and
**all output channels** (results must reach the original channel).
- On reclaim/destroy, its **residual tasks are decided explicitly by the parent**:
`residual=keep` (returned to the parent queue, default) or `drop` (explicitly
discarded with a per-item log entry).
### Legacy three-path view (still present, now a layer beneath the scheduler)
``` ```
interceptLoop (goroutine) interceptLoop (goroutine)
@ -465,15 +532,28 @@ interceptLoop (goroutine)
└── (c) InjectInput() → Trigger new processing when idle └── (c) InjectInput() → Trigger new processing when idle
``` ```
Three delivery paths: Code: `internal/agent/core/scheduler.go` (scheduler), `eventloop.go` (intercept loop).
| Path | Effect | Timing | ## Context Budget
|------|--------|--------|
| cancelLLM | Cancel current HTTP request | On context.Canceled |
| interceptCh | Insert `[interrupt message]` in process() | Before each LLM call |
| InjectInput | Trigger new processing when eventLoop is idle | No ongoing request |
Code: `internal/agent/core/eventloop.go` — `interceptLoop` / `drainInterrupts` `internal/agent/core/tokenbudget.go` — `ComputeTokenBudget`:
```
maxCtx = provider.MaxContextTokens() // declared window (per-source context_window wins)
targetUsage = min(maxCtx × 0.8, 600000) // working band, capped at 600K
├── memory recall budget = (targetUsage - fixed) / 3
└── context events budget = remaining 2/3
```
★ **Window ≠ working band**: a source's real window may reach 1M, but near-full windows
lose attention and cost/latency rise linearly, so `maxTargetTokens=600000` caps the
working band separately. If the model name (e.g. `AUTO`) yields no window,
`ModelContextWindow` **logs a warning** and falls back conservatively; operators should
declare `core.llm.sources.<name>.context_window` explicitly.
**Budgets are ceilings, not fill targets**: memory is recall-ranked (it stops when nothing
is relevant) and the timeline is taken newest-first within budget. Measured: with a 400K
budget, actual injection was still a few hundred characters.
## Configuration System ## Configuration System

View File

@ -648,11 +648,11 @@ Writable fields: `raw_message`, `llm_text`, `final_text`, `user_id`, `group_id`,
| `sdk.inject_interrupt(source, channel, text)` | Interrupt delivery | | `sdk.inject_interrupt(source, channel, text)` | Interrupt delivery |
| `sdk.inject_text_no_memory(source, channel, text)` | Deliver without memory computation | | `sdk.inject_text_no_memory(source, channel, text)` | Deliver without memory computation |
| `sdk.inject_text_opts` / `sdk.inject_interrupt_opts(source, channel, text, opts)` | Delivery with flags; `opts = { no_memory=bool, context_policy="none"|"prune", cleaner_name=string, priority="L1".."L3" }` | | `sdk.inject_text_opts` / `sdk.inject_interrupt_opts(source, channel, text, opts)` | Delivery with flags; `opts = { no_memory=bool, context_policy="none"|"prune", cleaner_name=string, priority="L1".."L3" }` |
| `sdk.inject_input_sync(source, channel, text)` | Inject synchronously and wait for this turn's reply; returns `(reply, err)`, reply is nil when there is none | | `sdk.inject_input_sync(source, channel, text)` | ⚠️ **Unavailable in Lua**: always returns `(nil, err)`. It waits for this turn's reply while a Lua callback holds the plugin lock, so it would self-deadlock. Use a Go plugin for synchronous waits, or the async injectors below |
| `sdk.inject_input_sync_opts(source, channel, text, opts)` | Same, with flags | | `sdk.inject_input_sync_opts(source, channel, text, opts)` | Same (unavailable) |
| `sdk.inject_input_media(source, channel, text, blocks)` | Inject text + multimodal content blocks | | `sdk.inject_input_media(source, channel, text, blocks)` | Inject text + multimodal content blocks |
| `sdk.inject_input_media_opts(source, channel, text, blocks, opts)` | Same, with flags | | `sdk.inject_input_media_opts(source, channel, text, blocks, opts)` | Same, with flags |
| `sdk.inject_input_media_sync` / `..._sync_opts(...)` | Synchronous media injection; returns `(reply, err)` | | `sdk.inject_input_media_sync` / `..._sync_opts(...)` | ⚠️ **Unavailable in Lua** (same as `inject_input_sync`) |
| `sdk.inject_interrupt_media(source, channel, text, blocks)` | Interrupt delivery with media | | `sdk.inject_interrupt_media(source, channel, text, blocks)` | Interrupt delivery with media |
| `sdk.inject_interrupt_media_opts(source, channel, text, blocks, opts)` | Same, with flags | | `sdk.inject_interrupt_media_opts(source, channel, text, blocks, opts)` | Same, with flags |
| `sdk.set_tool_blocks(blocks)` | Set multimodal blocks carried by the next tool message (lets the model see images / hear audio) | | `sdk.set_tool_blocks(blocks)` | Set multimodal blocks carried by the next tool message (lets the model see images / hear audio) |
@ -790,7 +790,14 @@ pmgr.ReloadPlugins() // Reload all plugins
Internal: records are stored in SQLite `disabled_plugins` table (`name`, `disabled_at`, `disabled_by`). Disabling takes effect immediately (plugin stops receiving input); full removal requires a restart. Internal: records are stored in SQLite `disabled_plugins` table (`name`, `disabled_at`, `disabled_by`). Disabling takes effect immediately (plugin stops receiving input); full removal requires a restart.
> **Note**: `PluginMgr()` is only available to built-in plugins; external dynamic plugins cannot call it directly. > **Note**: `PluginMgr()` returns an interface with **only 3 methods** (`ReloadOne` /
> `ListLoadedPlugins` / `IsPluginDisabled`). Enable/disable/remove/reload-all
> (`EnablePlugin` / `DisablePlugin` / `RemovePlugin` / `ReloadPlugins`) and the
> built-in check (`IsBuiltinPlugin`) exist only on the kernel-internal
> `internal/sdk.PluginManager` — external plugins cannot reach them. To reload from
> an external plugin, use `ReloadOne`.
> The two interfaces have similar names but are **not the same**:
> `sdk.PluginMgrAPI` (public, 3 methods) vs `internal/sdk.PluginManager` (internal, 9).
--- ---
@ -804,7 +811,7 @@ Internal: records are stored in SQLite `disabled_plugins` table (`name`, `disabl
|---------|------|----------| |---------|------|----------|
| [weather](https://gitcode.com/JianFeeeee/homeagent-sdk/tree/main/example/weather) | Go | Weather queries (wttr.in); demonstrates NoMemory/Cleaner/stage hooks/channels/text memory | | [weather](https://gitcode.com/JianFeeeee/homeagent-sdk/tree/main/example/weather) | Go | Weather queries (wttr.in); demonstrates NoMemory/Cleaner/stage hooks/channels/text memory |
| [luademo](https://gitcode.com/JianFeeeee/homeagent-sdk/tree/main/example/luademo) | Lua | Full-featured Lua example covering the whole v0.8.0 Lua SDK surface | | [luademo](https://gitcode.com/JianFeeeee/homeagent-sdk/tree/main/example/luademo) | Lua | Full-featured Lua example covering the whole v0.8.0 Lua SDK surface |
| [qq](https://gitcode.com/JianFeeeee/homeagent-sdk/tree/main/example/qq) | Go | NapCat OneBot integration, 17 tools, full input/output channel wiring | | [qq](https://gitcode.com/JianFeeeee/homeagent-sdk/tree/main/example/qq) | Go | NapCat OneBot integration, 20 tools, full input/output channel wiring |
| [memo](https://gitcode.com/JianFeeeee/homeagent-sdk/tree/main/example/memo) | Go | Memo management, PreAction injection + timed interrupt dual reminder | | [memo](https://gitcode.com/JianFeeeee/homeagent-sdk/tree/main/example/memo) | Go | Memo management, PreAction injection + timed interrupt dual reminder |
| [files](https://gitcode.com/JianFeeeee/homeagent-sdk/tree/main/example/files) | Go | File system operations, 4 write modes, sandbox isolation | | [files](https://gitcode.com/JianFeeeee/homeagent-sdk/tree/main/example/files) | Go | File system operations, 4 write modes, sandbox isolation |
| [browser](https://gitcode.com/JianFeeeee/homeagent-sdk/tree/main/example/browser) | Go | Web search + HTTP fetch (SSRF) + Chromium render (merged from web/webfetch) | | [browser](https://gitcode.com/JianFeeeee/homeagent-sdk/tree/main/example/browser) | Go | Web search + HTTP fetch (SSRF) + Chromium render (merged from web/webfetch) |
@ -817,6 +824,12 @@ Internal: records are stored in SQLite `disabled_plugins` table (`name`, `disabl
| [rss](https://gitcode.com/JianFeeeee/homeagent-sdk/tree/main/example/rss) | Go | RSS subscriptions | | [rss](https://gitcode.com/JianFeeeee/homeagent-sdk/tree/main/example/rss) | Go | RSS subscriptions |
| [ai_image](https://gitcode.com/JianFeeeee/homeagent-sdk/tree/main/example/ai_image) | Go | AI image generation | | [ai_image](https://gitcode.com/JianFeeeee/homeagent-sdk/tree/main/example/ai_image) | Go | AI image generation |
| [music](https://gitcode.com/JianFeeeee/homeagent-sdk/tree/main/example/music) | Go | Music playback | | [music](https://gitcode.com/JianFeeeee/homeagent-sdk/tree/main/example/music) | Go | Music playback |
| [vikunja](https://gitcode.com/JianFeeeee/homeagent-sdk/tree/main/example/vikunja) | Go | Vikunja task management (projects/tasks/labels CRUD) |
| [vanblog](https://gitcode.com/JianFeeeee/homeagent-sdk/tree/main/example/vanblog) | Go | VanBlog publishing and management |
| [deepsearch](https://gitcode.com/JianFeeeee/homeagent-sdk/tree/main/example/deepsearch) | Go | Multi-round deep search (progressive focus + cited summary) |
| [acp](https://gitcode.com/JianFeeeee/homeagent-sdk/tree/main/example/acp) | Go | Agent Client Protocol (external editors/IDEs drive this agent) |
| [recoverydiag](https://gitcode.com/JianFeeeee/homeagent-sdk/tree/main/example/recoverydiag) | Go | Five-part fault diagnosis (triage / sqlite check / log signatures / diff / ranked conclusions); core plugin of failback mode |
| [plugindev](https://gitcode.com/JianFeeeee/homeagent-sdk/tree/main/example/plugindev) | Go | Plugin scaffolding: generate, build, install — lets the agent develop plugins itself |
### Built-in Plugins ### Built-in Plugins

View File

@ -444,7 +444,64 @@ type Plugin interface {
- Relation 扩展:Confidence - Relation 扩展:Confidence
## 中断机制 ## 输入调度器与中断机制
输入不直接进 LLM —— 它们先进**输入调度器**(`internal/agent/core/scheduler.go`)。
设计全文见 [`docs/zh/input-scheduler-design.md`](../../../docs/zh/input-scheduler-design.md)。
### 两类任务
| 类别 | 级别 | 语义 |
|------|------|------|
| `TaskQueued` 排队输入 | 无级别(恒 0) | 待办工作。任何中断(≥ L1)都能抢它 |
| `TaskInterrupt` 中断 | L1~L4 | "这件事有多不能等",由来源在 `InjectOptions.Priority` 声明 |
### 四级中断
| 级别 | 含义 | 典型来源 |
|------|------|----------|
| L1 背景 | 完全可等 | QQ/微信消息、批量通知 |
| L2 消息 | 一般提醒 | 插件希望尽快看到但不紧急的提示 |
| L3 交互 | 需及时处理 | 定时器到达、终端输出、子 agent 汇报 |
| L4 关键 | **内核独占** | panic、内核事件、内核级插件的终止按钮 |
未声明级别时取 **L1**(`DefaultLevel`)——「显式才是特权」,新插件不会默认拿到抢占权。
外部插件声明 L4 会被**夹到 L3**(`clampPluginLevel`)。
### 抢占与挂起
- **同级不能抢占同级**(`canPreempt` 要求严格大于)——这是日常"消息排队等前面跑完"的成因。
- 被抢占的任务压入**中断栈**(LIFO),用 `suspendStack` 保存现场,稍后恢复;
栈内不做优先级重排("后被打断的先恢复"才是栈语义)。
- **饥饿防护**:被抢占次数会提升有效级别(`effectiveLevel = Level + min(PreemptCount, 2)`,
封顶 L4),确保低级别流不会被困。
- **抢占冷却**:刚被抢占过的任务在 `preemptCooldown`(2s)内不再被抢,
避免高优先级流把同一个任务反复打断到永不完结。
- 中断栈帧数有**结构上界**(链条 = 排队 ← L1 ← L2 ← L3 ← L4,最多挂起 4 帧)。
### 停止(用户按停止按钮 / `/stop`)
停止 ≠ 空中断。它做两件事:① 立即结束当前 LLM 推理;② 对**停止那一刻已排队**
的 x 条消息依次在 pre-action 阶段短路(`cancelBudget` 快照配额),而不是把它们
当新输入再跑一遍。停止之后**新到**的输入不受影响。
`PendingInputs()` 必须把"还停在 `io.inputCh`、没被 `pumpInbox` 搬进队列"的那一段
算进来 —— 停止时调度器多半正忙于当前任务,只数 `sched.queue` 会得到 0。
### 驻留式子 agent 与及时反馈
设计见 [`docs/zh/resident-subagent-design.md`](../../../docs/zh/resident-subagent-design.md)。
- **驻留子**是轻量内核的独立 agent:自己的调度器、自己的 temp 图记忆、共享的通道登记表。
- 父对子的控制面:`resident_agents`(list / create / send / inspect / compress / reclaim / destroy)。
- **积压及时反馈**:主 agent 长时间忙时(默认 > 5m,可配),内核把排队输入交给
一个临时**分诊助手**(`offload_*` 配置):简单的直接处理并回复,需要主 agent 的
立刻回「忙碌中,请稍候」。这样用户不会干等十几分钟。
- 分诊助手**不配 inputch**(不接收插件用户输入)、**持有全部输出通道**(结果要能发回原通道)。
- 回收/销毁时它手头的**残余任务由父显式决定**:`residual=keep`(转回父队列,默认)
或 `drop`(明确丢弃,逐条记日志)。
### 旧版三路径(仍存在,但已是调度器之下的一层)
``` ```
interceptLoop (goroutine) interceptLoop (goroutine)
@ -454,15 +511,26 @@ interceptLoop (goroutine)
└── (c) InjectInput() → 空闲时触发新处理 └── (c) InjectInput() → 空闲时触发新处理
``` ```
三种投递路径: 代码:`internal/agent/core/scheduler.go`(调度器)、`eventloop.go`(拦截循环)。
| 路径 | 效果 | 时机 | ## 上下文预算
|------|------|------|
| cancelLLM | 取消当前 HTTP 请求 | 收到 context.Canceled |
| interceptCh | process() 中插入 `[打断消息]` | 每个 LLM call 前 |
| InjectInput | eventLoop 空闲时触发新处理 | 无进行中请求 |
代码:`internal/agent/core/eventloop.go` — `interceptLoop` / `drainInterrupts` `internal/agent/core/tokenbudget.go` — `ComputeTokenBudget`:
```
maxCtx = provider.MaxContextTokens() // 声明窗口(per-source context_window 优先)
targetUsage = min(maxCtx × 0.8, 600000) // 工作面:封顶 600K
├── 记忆召回预算 = (targetUsage - 固定开销) / 3
└── 上下文事件预算 = 其余 2/3
```
★ **窗口 ≠ 工作面**:源的真实窗口可能到 1M,但接近满窗口时注意力涣散、
成本与延迟线性上升,因此 `maxTargetTokens=600000` 把工作面单独封顶。
若模型名(如 `AUTO`)推断不出窗口,`ModelContextWindow` 会**打日志提醒**并回退保守值,
部署方应用 `core.llm.sources.<name>.context_window` 显式声明。
**预算都是上限而非填充目标**:记忆按相关度召回(没相关就停),时间线按预算从新到旧取。
实测:预算 400K 时实际注入仍只有几百字符。
## 配置系统 ## 配置系统

View File

@ -641,11 +641,11 @@ end)
| `sdk.inject_interrupt(source, channel, text)` | 中断投递 | | `sdk.inject_interrupt(source, channel, text)` | 中断投递 |
| `sdk.inject_text_no_memory(source, channel, text)` | 免记忆投递 | | `sdk.inject_text_no_memory(source, channel, text)` | 免记忆投递 |
| `sdk.inject_text_opts` / `sdk.inject_interrupt_opts(source, channel, text, opts)` | 带标志位投递;`opts = { no_memory=bool, context_policy="none"|"prune", cleaner_name=string, priority="L1".."L3" }` | | `sdk.inject_text_opts` / `sdk.inject_interrupt_opts(source, channel, text, opts)` | 带标志位投递;`opts = { no_memory=bool, context_policy="none"|"prune", cleaner_name=string, priority="L1".."L3" }` |
| `sdk.inject_input_sync(source, channel, text)` | 同步注入并等本轮回复;返回 `(reply, err)`,无回复时 reply 为 nil | | `sdk.inject_input_sync(source, channel, text)` | ⚠️ **Lua 中不可用**:恒返回 `(nil, err)`。它要等本轮回复而 Lua 回调持有插件锁,必然自锁。需要同步等待请用 Go 插件,或用下面的异步注入 |
| `sdk.inject_input_sync_opts(source, channel, text, opts)` | 同上带标志位 | | `sdk.inject_input_sync_opts(source, channel, text, opts)` | 同上(不可用) |
| `sdk.inject_input_media(source, channel, text, blocks)` | 注入文本 + 多模态内容块 | | `sdk.inject_input_media(source, channel, text, blocks)` | 注入文本 + 多模态内容块 |
| `sdk.inject_input_media_opts(source, channel, text, blocks, opts)` | 同上带标志位 | | `sdk.inject_input_media_opts(source, channel, text, blocks, opts)` | 同上带标志位 |
| `sdk.inject_input_media_sync` / `..._sync_opts(...)` | 带媒体的同步注入;返回 `(reply, err)` | | `sdk.inject_input_media_sync` / `..._sync_opts(...)` | ⚠️ **Lua 中不可用**(同 `inject_input_sync`) |
| `sdk.inject_interrupt_media(source, channel, text, blocks)` | 带媒体的中断注入 | | `sdk.inject_interrupt_media(source, channel, text, blocks)` | 带媒体的中断注入 |
| `sdk.inject_interrupt_media_opts(source, channel, text, blocks, opts)` | 同上带标志位 | | `sdk.inject_interrupt_media_opts(source, channel, text, blocks, opts)` | 同上带标志位 |
| `sdk.set_tool_blocks(blocks)` | 设置下一轮 tool message 携带的多模态内容块(模型据此看图/听音频) | | `sdk.set_tool_blocks(blocks)` | 设置下一轮 tool message 携带的多模态内容块(模型据此看图/听音频) |
@ -783,7 +783,12 @@ pmgr.ReloadPlugins() // 重载所有插件
内部机制:禁用记录存储在 SQLite `disabled_plugins` 表(`name`, `disabled_at`, `disabled_by`),禁用立即生效(插件不再接收输入),完全卸载需重启内核。 内部机制:禁用记录存储在 SQLite `disabled_plugins` 表(`name`, `disabled_at`, `disabled_by`),禁用立即生效(插件不再接收输入),完全卸载需重启内核。
> **注意**:`PluginMgr()` 仅内置插件可用,外部动态插件无法直接调用。 > **注意**:`PluginMgr()` 返回的接口**只有 3 个方法**(`ReloadOne` / `ListLoadedPlugins` /
> `IsPluginDisabled`)。启用/禁用/卸载/重载全部(`EnablePlugin` / `DisablePlugin` /
> `RemovePlugin` / `ReloadPlugins`)以及内置插件判定(`IsBuiltinPlugin`)只在内核内部
> 的 `internal/sdk.PluginManager` 上,外部插件拿不到——需重载插件请调 `ReloadOne`。
> 两个接口叫相似的名字但**不是同一个**:`sdk.PluginMgrAPI`(公开,3 方法)与
> `internal/sdk.PluginManager`(内部,9 方法)。
--- ---
@ -797,7 +802,7 @@ pmgr.ReloadPlugins() // 重载所有插件
|------|------|------| |------|------|------|
| [weather](https://gitcode.com/JianFeeeee/homeagent-sdk/tree/main/example/weather) | Go | 天气查询(wttr.in),演示 NoMemory/Cleaner/阶段钩子/通道/文本记忆 | | [weather](https://gitcode.com/JianFeeeee/homeagent-sdk/tree/main/example/weather) | Go | 天气查询(wttr.in),演示 NoMemory/Cleaner/阶段钩子/通道/文本记忆 |
| [luademo](https://gitcode.com/JianFeeeee/homeagent-sdk/tree/main/example/luademo) | Lua | Lua 全功能示例,覆盖 v0.8.0 Lua SDK 全部 API 面 | | [luademo](https://gitcode.com/JianFeeeee/homeagent-sdk/tree/main/example/luademo) | Lua | Lua 全功能示例,覆盖 v0.8.0 Lua SDK 全部 API 面 |
| [qq](https://gitcode.com/JianFeeeee/homeagent-sdk/tree/main/example/qq) | Go | NapCat OneBot 对接,17 个工具,输入/输出通道完整对接 | | [qq](https://gitcode.com/JianFeeeee/homeagent-sdk/tree/main/example/qq) | Go | NapCat OneBot 对接,20 个工具,输入/输出通道完整对接 |
| [memo](https://gitcode.com/JianFeeeee/homeagent-sdk/tree/main/example/memo) | Go | 备忘管理,PreAction 注入 + 定时打断双提醒 | | [memo](https://gitcode.com/JianFeeeee/homeagent-sdk/tree/main/example/memo) | Go | 备忘管理,PreAction 注入 + 定时打断双提醒 |
| [files](https://gitcode.com/JianFeeeee/homeagent-sdk/tree/main/example/files) | Go | 文件系统操作,4 种写入模式,沙箱隔离 | | [files](https://gitcode.com/JianFeeeee/homeagent-sdk/tree/main/example/files) | Go | 文件系统操作,4 种写入模式,沙箱隔离 |
| [browser](https://gitcode.com/JianFeeeee/homeagent-sdk/tree/main/example/browser) | Go | 网络搜索、网页抓取(SSRF)、浏览器渲染(合并自 web/webfetch) | | [browser](https://gitcode.com/JianFeeeee/homeagent-sdk/tree/main/example/browser) | Go | 网络搜索、网页抓取(SSRF)、浏览器渲染(合并自 web/webfetch) |
@ -810,6 +815,12 @@ pmgr.ReloadPlugins() // 重载所有插件
| [rss](https://gitcode.com/JianFeeeee/homeagent-sdk/tree/main/example/rss) | Go | RSS 订阅 | | [rss](https://gitcode.com/JianFeeeee/homeagent-sdk/tree/main/example/rss) | Go | RSS 订阅 |
| [ai_image](https://gitcode.com/JianFeeeee/homeagent-sdk/tree/main/example/ai_image) | Go | AI 图片生成 | | [ai_image](https://gitcode.com/JianFeeeee/homeagent-sdk/tree/main/example/ai_image) | Go | AI 图片生成 |
| [music](https://gitcode.com/JianFeeeee/homeagent-sdk/tree/main/example/music) | Go | 音乐播放 | | [music](https://gitcode.com/JianFeeeee/homeagent-sdk/tree/main/example/music) | Go | 音乐播放 |
| [vikunja](https://gitcode.com/JianFeeeee/homeagent-sdk/tree/main/example/vikunja) | Go | Vikunja 任务管理对接(项目/任务/标签 CRUD) |
| [vanblog](https://gitcode.com/JianFeeeee/homeagent-sdk/tree/main/example/vanblog) | Go | VanBlog 博客发布与管理 |
| [deepsearch](https://gitcode.com/JianFeeeee/homeagent-sdk/tree/main/example/deepsearch) | Go | 多轮深度检索(逐层聚焦 + 引用汇总) |
| [acp](https://gitcode.com/JianFeeeee/homeagent-sdk/tree/main/example/acp) | Go | Agent Client Protocol 对接(外部编辑器/IDE 驱动本 agent) |
| [recoverydiag](https://gitcode.com/JianFeeeee/homeagent-sdk/tree/main/example/recoverydiag) | Go | 故障诊断五件套(分诊/sqlite 校验/日志签名/diff/结论排序),failback 模式的核心插件 |
| [plugindev](https://gitcode.com/JianFeeeee/homeagent-sdk/tree/main/example/plugindev) | Go | 插件脚手架:生成工程、构建、安装,供 agent 自助开发插件 |
### 内置插件 ### 内置插件

View File

@ -0,0 +1,105 @@
# kbtree 本机部署交接(交给部署方执行)
我负责把 kbtree 的**代码**合入 main,并把 **skill + 调用方法**在本机装好。
**二进制替换与重启由你做** —— 我不碰运行中的生产守护进程。
## 现状(交接时的事实)
| 项 | 状态 |
|---|---|
| kbtree 代码 | ✅ 已在 `main`(`41d7543`),已推送 |
| skill | ✅ 已装 `/home/newqqagent/skills/knowledge-base/` |
| token | ✅ 已写入 `config_kbtree` 表(固定值,重启不变) |
| 配置库备份 | ✅ `config.db.bak-20260926-143643` |
| **服务** | ❌ **未上线** —— 运行中的二进制里没有 kbtree |
| 我构建的候选二进制 | `/tmp/homed-new`(84.7MB,与 main 同源,`-tags onnxruntime`) |
**为何未上线**:14:35 有人替换了 `/usr/local/bin/homed`(84,985,720 字节)并重启了
服务(现 PID 1450152)。那个二进制与 main 构建**不是同一份**,比我的大 2.4MB。
直接部署会覆盖它 —— 所以交给你决定何时、以及以哪个版本为准。
实测确认现役二进制不含 kbtree:
```bash
strings /usr/local/bin/homed | grep -c kbtree # → 0
ss -ltn | grep 9892 # → 无监听
```
## 上线步骤
**必须按顺序,且第 1 步不能用 `cp`**:
```bash
DATA=/home/newqqagent
# 1. 备份配置库(WAL 模式下 cp 会拿到不一致快照,必须用 .backup)
sqlite3 $DATA/config.db ".backup '$DATA/config.db.bak-$(date +%Y%m%d-%H%M%S)'"
# 2. 确认要部署的二进制
strings /tmp/homed-new | grep -c kbtree # 期望 ≥ 1;为 0 说明候选不对
# 3. 原子替换(install 内部是 rename,不会写坏运行中进程的映像)
install -m 0755 /tmp/homed-new /usr/local/bin/homed
# 4. 重启
systemctl restart homeagent
# 5. 验证
systemctl is-active homeagent
journalctl -u homeagent --since "-2min" | grep kbtree
ss -ltn | grep 9892
```
### 第 5 步期望看到
```
[kbtree] 已启动 http://127.0.0.1:9892
[kbtree] 外部 agent 可用:GET /tree、/categories、/counts、/search?q=&category=
```
## 部署后的冒烟测试
```bash
cd /home/newqqagent/skills/knowledge-base
./scripts/kb_tree.sh -h # 帮助(不需要 token)
./scripts/kb_tree.sh categories # 分类列表
./scripts/kb_tree.sh counts # 各分类条目数
./scripts/kb_tree.sh tree -d 1 -i 0 # 只看第一层结构
./scripts/kb_tree.sh search -q 知识库 -c tech -l 3
```
token 自动从 `config/config.json` 读(权限 600),无需手动 export。
覆盖方式:`KB_TOKEN=xxx ./scripts/kb_tree.sh ...` 或改那个 json。
## 端口与 token
- 监听:`kbtree.listen_addr` = `127.0.0.1:9892`(**仅本机**)
- token:`kbtree.token` 已在 `config_kbtree` 表里设为固定值。
若要改成随机(每次重启变),把该行 value 置空即可 ——
但那样每次重启都要重新把 token 告诉所有使用者。
- 改 token 时**两处一起改**:`config_kbtree` 表 + `skills/knowledge-base/config/config.json`。
要对外(别的机器)时改 `listen_addr` 为 `0.0.0.0:9892`,
但**先想清楚 token 怎么分发** —— 它是唯一的屏障。
## 退出码约定(脚本)
| 码 | 含义 |
|---|---|
| 0 | 成功 |
| 2 | 参数错误 / 未知命令 |
| 3 | 令牌无效(401) |
| 4 | 分类不存在(404,stderr 会列出现有分类) |
| 5 | 其它 HTTP 错误 |
| 7 | 连不上(**通常是服务未上线**) |
| 8 | 请求发送失败 |
## 回滚
```bash
install -m 0755 <旧二进制> /usr/local/bin/homed
systemctl restart homeagent
```
配置与 skill 都不影响回滚(kbtree 未启动时它们只是闲置文件)。

View File

@ -0,0 +1,148 @@
---
name: knowledge-base
description: 按分类树检索 HomeAgent 知识库。当需要查阅项目知识、架构约定、历史决策,或用户提到"知识库/knowledge/知识库有哪些/这个项目的约定是什么"时使用。支持树形导航、分类内检索、以图搜知识。
version: 1.1.0
author: HomeAgent
---
## Usage
先看树定位分类,再做定向检索。接口由 HomeAgent 的 `kbtree` 插件提供,
只读、需 token。详见下方"接入"。
HomeAgent 知识库按**分类树**组织(`tech/go/并发`、`life/sleep` …)。
### 何时用
- 用户问"这个项目/内核的某个约定是什么" → 先看树,找对分类再检索
- 用户提到"知识库"或某个看起来像分类名的词(如 `tech/go`)→ 查该子树
- 用户给了图片并问"知识库里有相关的吗" → 见"以图搜知识"
### 接入
服务默认监听 `127.0.0.1:9892`(配置项 `kbtree.listen_addr`),只读,
每次请求需带 token(配置项 `kbtree.token`;未配置则启动时随机生成)。
```bash
BASE=http://127.0.0.1:9892
AUTH="X-API-Key: $KB_TOKEN" # 或 Authorization: Bearer <token> 或 ?token=
```
先摸清可用接口:
```bash
curl -s -H "$AUTH" "$BASE/"
```
### 本机封装脚本(推荐先用它)
`scripts/kb_tree.sh` 把上面四条命令封好了,省得手拼 URL 与鉴权头:
```bash
S=~/.claude/skills/knowledge-base/scripts/kb_tree.sh # 按实际安装路径调整
$S # 整棵树
$S tree -c tech -d 1 # tech 子树,只看第一层
$S categories # 分类列表
$S counts # 各分类条目数
$S search -q goroutine -c tech
```
token 读取顺序:环境变量 `KB_TOKEN` → 同上<E5908C><E4B88A>目录的 `../config.json`。
**不要**把 token 写在命令行上(会进 shell 历史与 `ps` 输出)。
### 核心工作流:先看树,再定向检索
**别一上来就全文搜索。** 知识库是分层的,先定位分类能显著提高命中率,
也能避免把范围外的弱匹配当答案。
#### 第 1 步 · 看有哪些分类
```bash
curl -s -H "$AUTH" "$BASE/categories"
# {"categories":["cook","life","tech","tech/go","tech/rust"]}
# 内容最多的分类(按条目数倒序)
curl -s -H "$AUTH" "$BASE/counts"
# {"counts":[{"category":"tech","count":3}, ...], "total":5}
```
#### 第 2 步 · 浏览树结构
```bash
# 整棵树,只要结构
curl -s -H "$AUTH" "$BASE/tree?items=0"
# 只要第一层 —— 分类多时用来做懒加载
curl -s -H "$AUTH" "$BASE/tree?depth=1&items=0"
# 某棵子树,带条目详情
curl -s -H "$AUTH" "$BASE/tree?category=tech/go"
```
节点里 `name` 是**本级段名**(`"go"`),`path` 是**完整路径**
(`"tech/go"`)。拼层级用 `name`,把 `path` 拿去请求子节点。
`item_count` 是本级条目数,`total_count` 是整棵子树。
#### 第 3 步 · 分类内检索
```bash
# 关键词 + 分类子树(推荐)
curl -s -H "$AUTH" "$BASE/search?q=goroutine&category=tech"
# 全库
curl -s -H "$AUTH" "$BASE/search?q=goroutine&limit=5"
```
`category` 是**前缀匹配**:`tech` 会命中 `tech/go`、`tech/rust` 下的条目;
传 `tech/go` 只命中它自己的子树。
### 以图搜知识(多模态)
若知识条目挂了图片,它在**多模态统一空间**里有向量,能被图片本身检索到。
前提是宿主已接入多模态向量 provider(否则只是记录了媒体,不参与召回)。
判断是否就绪:HomeAgent 自身的知识库接口会返回稠密路状态
(`dense.enabled` / `dense.ready` / `dense.total`)。若为未启用,
**不要承诺"能以图搜"**。
本服务只提供**按关键词检索**——把图片字节提交给嵌入服务计算向量不在此接口内。所以:
- 用户给了图 → 用图的**可见内容**(或你先读图得到的文字)当关键词检索
- 或用本机可用的读图工具先看图,再拿描述来检索
### 读结果
`/search` 每条结果:
| 字段 | 含义 |
|---|---|
| `name` | 知识名(**已含分类前缀**,如 `tech/go/并发`) |
| `content` | 正文全文 |
`/tree` 里的条目额外有 `preview`(前 120 字)、`size`、`updated_at`、
`media`(挂载的媒体 digest/mime/kind)。
### 易错点
- **`name` 已经含分类**。不要再拼 `category + "/" + name`,会得到
`tech/go/tech/go/并发`。
- **检索会返回弱匹配。** 词法路会给所有条目打一个低分,靠排序把强命中顶到
前面。**只看第一条**;第一条明显不相关就换个分类或关键词,别把第 2、3 条
当答案。
- **分类不存在返回 404**,并在 `categories` 字段里附上现有分类 —— 用它自查
拼写。
- **`items=0` 只是不要正文**,`total_count` 仍准确,可用于判断规模。
- **本服务只读**。写方法返回 405。要写知识请用 HomeAgent 主 agent 的
`knowledge_create`(或 WebUI 界面),不要试图绕过它直接写这个接口。
- 知识名里不能有 `..`、空格(会被规范成 `_`)、点开头的段。
### 写入
本服务不提供写入。若你在 HomeAgent 主 agent 内部,写入用内核工具:
```
knowledge_create name="tech/go/调度" content="正文..."
```
`name` 用 `/` 表示分类层级(如 `tech/go/调度`)。写完它**立刻可检索**
(词法 IDF 是增量维护的,不必重启)。

View File

@ -0,0 +1,170 @@
#!/usr/bin/env bash
# kbtree 客户端:按分类树检索 HomeAgent 知识库。
#
# 由 knowledge-base skill 调用(agent 读 SKILL.md 后按需调本脚本)。
# 也可人工使用:
# kb_tree.sh # 整棵树
# kb_tree.sh -c tech -d 1 # tech 子树,只看一层
# kb_tree.sh -q goroutine -c tech # 在 tech 子树内检索
# kb_tree.sh -l # 列分类
#
# token 读取顺序:环境变量 KB_TOKEN > <skill>/config/config.json(或 <skill>/config.json)> 报错。
# 故意不放命令行参数:token 会进 shell 历史与 ps 输出。
set -euo pipefail
BASE="${KB_BASE:-http://127.0.0.1:9892}"
HERE="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
# 读 token
# 帮助:-h/--help 必须在解析命令之前判,否则会被当成未知命令
for a in "$@"; do
case "$a" in
-h|--help)
echo "用法:"
echo " kb_tree.sh [tree|categories|counts|search] [选项]"
echo "选项:"
echo " -q 关键词 检索词(给了 q 就走 search)"
echo " -c 分类 限定分类子树(前缀匹配),如 tech / tech/go"
echo " -d 层数 树展开层数,1=只看第一层(懒加载)"
echo " -i 0|1 是否带条目详情,默认 1"
echo " -l 条数 search 的返回条数,默认 10"
echo "环境变量: KB_TOKEN(也可放同目录 config/config.json)"
exit 0 ;;
esac
done
if [[ -z "${KB_TOKEN:-}" ]]; then
# 两种布局都试:<skill>/config/config.json(当前布局)与 <skill>/config.json。
# 只写一种会因目录结构调整而静默失效——症状是「明明配了 token 却说没找到」。
for CFG in "$HERE/../config/config.json" "$HERE/../config.json"; do
if [[ -f "$CFG" ]]; then
KB_TOKEN="$(python3 -c 'import json,sys;print(json.load(open(sys.argv[1])).get("token",""))' "$CFG" 2>/dev/null || true)"
[[ -n "$KB_TOKEN" ]] && break
fi
done
fi
if [[ -z "${KB_TOKEN:-}" ]]; then
cat >&2 <<'EOF'
kbtree: 未找到访问令牌。
取 token 的办法(其一):
1. 若 homed 启动日志里有「token 未配置,本次随机生成」,那行日志附近有 token;
2. 若已配置过固定 token,从配置库读:
sqlite3 <data_dir>/config.db "SELECT value FROM config_kbtree WHERE key='token'"
3. 直接设置:export KB_TOKEN=<token>
token 未配置时服务会在启动时随机生成,进程重启即失效。
EOF
exit 2
fi
auth=(-H "X-API-Key: ${KB_TOKEN}")
# 第一个参数若是选项(如 -q x),它就是选项而非子命令。
# 原先会把 "-q" 当命令名报「未知命令: -q」——而 `kb_tree.sh -q 并发` 是很自然的写法。
if [[ $# -gt 0 && "$1" == -* ]]; then
cmd=""
else
cmd="${1:-tree}"
shift || true
fi
query=""; category=""; depth=""; items=""; limit=""
while getopts "q:c:d:i:l:h" opt 2>/dev/null; do
case "$opt" in
q) query="$OPTARG" ;;
c) category="$OPTARG" ;;
d) depth="$OPTARG" ;;
i) items="$OPTARG" ;;
l) limit="$OPTARG" ;;
h) echo "用法: kb_tree.sh [tree|categories|counts|search] -q 关键词 -c 分类 -d 层数 -i 0|1 -l 条数"; exit 0 ;;
esac
done
# 预检:端口通不通。不通就直说"服务未上线",
# 而不是让用户看 curl: (7) Connection refused 后自行猜测。
HOSTPORT="${BASE#http://}"; HOSTPORT="${HOSTPORT%%/*}"
if ! (exec 3<>"/dev/tcp/${HOSTPORT%%:*}/${HOSTPORT##*:}") 2>/dev/null; then
cat >&2 <<EOF
kbtree: 连不上 $BASE(端口未监听)。
最常见原因——**服务还没上线**。kbtree 是 HomeAgent 的内置插件,
需要二进制里含它才会启动。若 homed 是在合入该插件之前构建/部署的,
就一直没有这个服务。上线后验证:
systemctl show homeagent -p MainPID --value
strings /usr/local/bin/homed | grep -c kbtree # 0 = 二进制里没有
本机上线步骤(会重启守护进程):
sqlite3 <data_dir>/config.db ".backup '<data_dir>/config.db.bak-\$(date +%Y%m%d-%H%M%S)'"
install -m 0755 <新二进制> /usr/local/bin/homed # 勿用 cp:会写坏运行中进程的映像
systemctl restart homeagent
journalctl -u homeagent -f | grep kbtree
EOF
exit 7
fi
enc() { python3 -c 'import sys,urllib.parse;print(urllib.parse.quote(sys.argv[1]))' "$1"; }
# kb_call 发请求并把错误翻译成人话。
# 不用 curl -f:它只吐 "curl: (22) 404",把服务端给的有用信息(404 会附现有分类)
# 全丢了 —— 而那恰恰是排查时最需要的。
kb_call() {
local url="$1" raw code
raw="$(curl -sS -w $'\n%{http_code}' "${auth[@]}" "$url" 2>&1)" || {
echo "kbtree: 请求失败: ${raw}" >&2; exit 8
}
code="$(printf '%s' "$raw" | tail -n1)"
body="$(printf '%s' "$raw" | sed '$d')"
case "$code" in
2*) printf '%s' "$body" | python3 -m json.tool; return 0 ;;
401) echo "kbtree: 令牌无效(401)。检查 config/config.json 或 KB_TOKEN 是否与 config_kbtree 表一致。" >&2; exit 3 ;;
404) echo "kbtree: 分类不存在(404)。服务端返回的现有分类:" >&2
printf '%s' "$body" | KB_BODY="$body" python3 -c '
import json, os, sys
try:
d = json.loads(os.environ.get("KB_BODY",""))
print(" " + ", ".join(d.get("categories", [])), file=sys.stderr)
except Exception:
print(" (无法解析响应体)", file=sys.stderr)
'
exit 4 ;;
*) echo "kbtree: HTTP $code" >&2; printf '%s\n' "$body" >&2; exit 5 ;;
esac
}
# 命令在解析选项**之后**定:没显式给子命令时,
# 有 -q 走 search、没有则走 tree。
if [[ -z "$cmd" ]]; then
if [[ -n "$query" ]]; then cmd="search"; else cmd="tree"; fi
fi
case "$cmd" in
tree|categories|counts|search) ;;
*) echo "未知命令: $cmd" >&2; exit 2 ;;
esac
if [[ "$cmd" == "categories" ]]; then
kb_call "$BASE/categories"
exit 0
fi
if [[ "$cmd" == "counts" ]]; then
kb_call "$BASE/counts"
exit 0
fi
if [[ "$cmd" == "search" || -n "$query" ]]; then
[[ -n "$query" ]] || { echo "search 需要 -q 关键词" >&2; exit 2; }
url="$BASE/search?q=$(enc "$query")"
[[ -n "$category" ]] && url="$url&category=$(enc "$category")"
[[ -n "$limit" ]] && url="$url&limit=$limit"
kb_call "$url"
exit 0
fi
# 默认:树
url="$BASE/tree"
[[ -n "$category" ]] && url="$url?category=$(enc "$category")"
q=""
[[ -n "$depth" ]] && q="depth=$depth"
[[ -n "$items" ]] && q="${q:+$q&}items=$items"
[[ -n "$q" ]] && url="$url?$q"
kb_call "$url"

View File

@ -0,0 +1,6 @@
{
"name": "knowledge-base",
"description": "按分类树检索 HomeAgent 知识库:树形导航、分类内检索、以图搜知识",
"version": "1.1.0",
"author": "HomeAgent"
}

View File

@ -810,6 +810,11 @@ const devOs = require("os");
let deviceBridge = null; // 当前活动设备桥 let deviceBridge = null; // 当前活动设备桥
let deviceBridgeId = ""; // 设备 meta device_id(hello 后可用于 cmd_result) let deviceBridgeId = ""; // 设备 meta device_id(hello 后可用于 cmd_result)
let deviceBridgeAddr = ""; // 设备桥网关地址 let deviceBridgeAddr = ""; // 设备桥网关地址
// 设备桥的**登记**状态(与"连接已建立"是两件事)。
// 连接成功但 bind 被拒时设备是失联的,只看 connected 会给出假阳性。
let deviceBridgeBound = false;
let deviceBridgeBindError = "";
// 音频/媒体接收聚合缓冲(服务端分块推送二进制→聚合→播放) // 音频/媒体接收聚合缓冲(服务端分块推送二进制→聚合→播放)
let speechAccum = null; let speechAccum = null;
@ -1252,9 +1257,33 @@ function onDeviceMsg(msg) {
} catch (e) { } catch (e) {
console.log("[device-bridge] exec error: " + e.message); console.log("[device-bridge] exec error: " + e.message);
} }
} else if (op === "hello_ack" || op === "bind_ack") { } else if (op === "bind_ack") {
// ★ bind 结果必须判 ok —— 与鸿蒙端(DeviceBridge.ets:209)对齐。
//
// 原实现与 Go 客户端同病:只打一行日志、不看 ok。服务端 bind 被拒时回
// {"ok":false,"error":"bind rejected"} 并**关闭连接**,GUI 却既不报错也
// 不重连,设备静默失联 —— TCP/WS 通但从未登记进网关,命令永远下发不到。
//
// 另:成功时服务端**不含 device 字段**,原日志靠 `msg.device || deviceBridgeId`
// 兜底才显示得像成功,掩盖了「没有真的读 ok」这件事。
const accepted = msg.ok === true;
deviceBridgeBound = accepted;
if (accepted) {
console.log("[device-bridge] bind_ok device=" + deviceBridgeId);
} else {
deviceBridgeBindError = String(msg.error || "bind rejected");
console.error(
"[device-bridge] bind rejected: " +
deviceBridgeBindError +
"(设备令牌不匹配或设备未授权)",
);
}
try {
rebuildTrayMenu();
} catch (e) {}
} else if (op === "hello_ack") {
console.log( console.log(
"[device-bridge] " + op + " device=" + (msg.device || deviceBridgeId), "[device-bridge] hello_ack device=" + (msg.device || deviceBridgeId) + " online=" + msg.online,
); );
try { try {
rebuildTrayMenu(); rebuildTrayMenu();
@ -2080,6 +2109,8 @@ function argsSafe(cmd) {
// url 可为 ws(s)://完整端点(含路径),token 为网关 ws_token。 // url 可为 ws(s)://完整端点(含路径),token 为网关 ws_token。
async function startDeviceBridge(cfg) { async function startDeviceBridge(cfg) {
if (!cfg) return; if (!cfg) return;
deviceBridgeBound = false;
deviceBridgeBindError = "";
const url = cfg.url || cfg.gateway || ""; const url = cfg.url || cfg.gateway || "";
const token = cfg.apiKey || cfg.token || ""; const token = cfg.apiKey || cfg.token || "";
if (!url || !token) { if (!url || !token) {

View File

@ -1,6 +1,6 @@
{ {
"name": "homeagent-gui", "name": "homeagent-gui",
"version": "1.0.0", "version": "1.4.0",
"author": "JianFeeeee <jianfeeeee@homeagent.local>", "author": "JianFeeeee <jianfeeeee@homeagent.local>",
"homepage": "https://gitcode.com/JianFeeeee/HomeAgent", "homepage": "https://gitcode.com/JianFeeeee/HomeAgent",
"description": "HomeAgent Desktop GUI - Multi-connection management dashboard", "description": "HomeAgent Desktop GUI - Multi-connection management dashboard",

View File

@ -593,6 +593,31 @@ async function api(p, o) {
return body; return body;
} }
// 从服务端发现设备网关地址(自动链接的权威来源)。
//
// 失败不报错:老版本 HomeAgent 没有这个端点,回退到本地推导即可
// (见 renderDeviceChannel 里的 state.discoveredGateway || 旧口径)。
//
// 优先 url_portal(门户同源形态):GUI 主进程连 WS 走系统解析器,
// devices.localhost 这类子域在系统解析器下通常解析不到 —— *.localhost
// 是浏览器内置特例(RFC 6761),不适用于普通进程。实测确认。
async function loadDiscoveredGateway() {
if (!state.currentConn || state.currentConn.type !== "webui") {
state.discoveredGateway = "";
return;
}
try {
var d = await api("/device/gateway");
state.discoveredGateway =
(d && d.available && (d.url_portal || d.url)) || "";
if (state.discoveredGateway) {
console.log("[device-bridge] discovered gateway: " + state.discoveredGateway);
}
} catch (e) {
state.discoveredGateway = "";
}
}
// ===== Navigation ===== // ===== Navigation =====
function switchView(n) { function switchView(n) {
document.querySelectorAll(".view").forEach((e) => { document.querySelectorAll(".view").forEach((e) => {
@ -696,6 +721,10 @@ async function refreshDataOnly() {
try { try {
state.kernel = await api("/kernel"); state.kernel = await api("/kernel");
} catch (e) {} } catch (e) {}
try {
// 运行态快照:只给指标与队列/阶段展示用,不影响其他卡片。
state.runtime = await api("/runtime");
} catch (e) {}
try { try {
var s = await api("/settings"); var s = await api("/settings");
state.settings = s.settings || {}; state.settings = s.settings || {};
@ -719,6 +748,7 @@ async function refreshDataOnly() {
state.currentConn.type === "webui" && state.currentConn.type === "webui" &&
state.currentConn.url state.currentConn.url
) { ) {
await loadDiscoveredGateway();
var d = await api("/device/online"); var d = await api("/device/online");
state.devices = (d && d.devices) || []; state.devices = (d && d.devices) || [];
} else { } else {
@ -775,6 +805,10 @@ async function refreshAll() {
try { try {
state.kernel = await api("/kernel"); state.kernel = await api("/kernel");
} catch (e) {} } catch (e) {}
try {
// 运行态快照(调度器/驻留子/通道),供总览的运行态面板使用。
state.runtime = await api("/runtime");
} catch (e) {}
try { try {
var s = await api("/settings"); var s = await api("/settings");
state.settings = s.settings || {}; state.settings = s.settings || {};
@ -799,6 +833,7 @@ async function refreshAll() {
state.currentConn.type === "webui" && state.currentConn.type === "webui" &&
state.currentConn.url state.currentConn.url
) { ) {
await loadDiscoveredGateway();
var d = await api("/device/online"); var d = await api("/device/online");
state.devices = (d && d.devices) || []; state.devices = (d && d.devices) || [];
} else { } else {
@ -1004,6 +1039,249 @@ function statCard(l, v) {
); );
} }
// ===== 运行态面板:阶段管道 + 中断队列 =====
//
// 与 WebUI 总览**同一套设计语言:等大表框**。此前桌面版总览只有四个数字卡,
// 既看不到「这一轮走到哪一步」,也看不到四级中断队列的积压。
// 数据来自 /api/v1/runtime(KernelStatus 的运行态子集)。
var RT_LEVELS = [
{ lv: 4, name: "L4", zh: "内核独占", en: "kernel only", cls: "rt-lv-4" },
{ lv: 3, name: "L3", zh: "交互", en: "interactive", cls: "rt-lv-3" },
{ lv: 2, name: "L2", zh: "消息", en: "message", cls: "rt-lv-2" },
{ lv: 1, name: "L1", zh: "后台", en: "background", cls: "rt-lv-1" },
];
// 七阶段归并成五格(与内核 sdk.Stage 的顺序一致):
// 一轮里工具调用会反复回到「行动后」,线性滑块本身就是错的表述,
// 所以画成 输入 → 行动 ⇄(工具) → 输出 → 结束,工具那格带循环标记。
var RT_PIPE_GROUPS = [
{ zh: "输入", en: "in", ico: "in" },
{ zh: "行动", en: "act", ico: "act" },
{ zh: "工具", en: "tool", ico: "tool", loop: true },
{ zh: "输出", en: "out", ico: "out" },
{ zh: "结束", en: "done", ico: "done" },
];
// 图标一律内联 SVG(24x24 / currentColor),不用 emoji/符号字符充当图标。
var RT_ICO = {
in: '<svg class="rt-ico" viewBox="0 0 24 24"><path d="M21 12H8"/><path d="M13 6l-6 6 6 6"/></svg>',
act: '<svg class="rt-ico" viewBox="0 0 24 24"><circle cx="12" cy="12" r="3.2"/><path d="M12 2v3M12 19v3M2 12h3M19 12h3M5.5 5.5l2.1 2.1M16.4 16.4l2.1 2.1M18.5 5.5l-2.1 2.1M7.6 16.4l-2.1 2.1"/></svg>',
tool: '<svg class="rt-ico" viewBox="0 0 24 24"><path d="M14.5 6.5a3.8 3.8 0 0 1 5 5L10 21l-5-5z"/><path d="M14.5 6.5 17.5 9.5"/></svg>',
out: '<svg class="rt-ico" viewBox="0 0 24 24"><path d="M4 12h13"/><path d="M13 6l6 6-6 6"/></svg>',
done: '<svg class="rt-ico" viewBox="0 0 24 24"><path d="M20 6 9 17l-5-5"/></svg>',
loop: '<svg class="rt-ico" viewBox="0 0 24 24"><path d="M20.5 12a8.5 8.5 0 1 1-2.5-6"/><path d="M21 3.5V9h-5.5"/></svg>',
};
function rtPhaseGroup(phase) {
switch (phase) {
case "on_input":
return 0;
case "pre_action":
case "post_action":
return 1;
case "before_toolcall":
case "after_toolcall":
return 2;
case "before_output":
return 3;
case "after_output":
return 4;
}
return -1;
}
function rtShortTool(name) {
var n = String(name || "");
var i = n.lastIndexOf("__");
if (i >= 0) n = n.slice(i + 2);
return n.length > 14 ? n.slice(0, 13) + "…" : n;
}
// rtSlots 画一组「车位」式格槽:槽位数量固定可见,被占用的点亮。
// 为什么不用进度条:队列为 0 时进度条宽度就是 0,整行只剩文字,看上去就是「这块空着」。
function rtSlots(depth, slots, cls) {
var n = Math.max(5, Math.min(16, slots || 5));
var d = depth || 0;
var out = '<span class="rt-slots ' + (cls || "") + '">';
for (var i = 0; i < n; i++) out += '<i class="' + (i < d ? "on" : "") + '"></i>';
// 溢出计数必须留在 .rt-slots 内:格槽是 flex 行,多一个兄弟节点会被挤出去
if (d > n) out += '<b class="rt-slots-more">+' + (d - n) + "</b>";
return out + "</span>";
}
// rtTrailPush 把一条「本轮发生过的事」落到它实际发生的阶段列里;
// 同一阶段重复的同一条(如同一工具连调 3 次)只累加计数,不刷屏。
function rtTrailPush(g, kind, label, short) {
if (!state.stageTrail) state.stageTrail = [];
var arr = state.stageTrail;
var last = arr.length ? arr[arr.length - 1] : null;
if (last && last.g === g && last.kind === kind && last.short === short) {
last.n = (last.n || 1) + 1;
return;
}
arr.push({ g: g, kind: kind, label: label, short: short, n: 1 });
if (arr.length > 24) arr.shift();
}
function renderRuntimePanel() {
var title = __("运行态", "Runtime");
var rt = state.runtime;
// 工具格的滑入动画只在「新到一条工具调用」那一次播放:overview 是整块
// innerHTML 重建,节点每次都是新的;若无条件带动画类,任何重渲染都会闪一下。
var toolFlash = !!state.toolFlash;
state.toolFlash = false;
if (!rt) {
return (
'<div class="card"><h2>' + title + '</h2><p class="rt-empty">' +
__("运行态数据不可用", "runtime unavailable") + "</p></div>"
);
}
var sc = rt.scheduler || {};
var q = sc.interrupt_queues || [0, 0, 0, 0, 0];
var pending = sc.pending_interrupts || 0;
var ready = sc.ready_queue_depth || 0;
var stack = sc.suspend_stack || 0;
var maxStack = sc.max_suspend_depth || 4;
var residents = rt.residents || [];
var byLv = sc.interrupts_by_level || [];
var preLv = sc.preempts_by_level || [];
var maxQ = Math.max(1, ready, q[1] || 0, q[2] || 0, q[3] || 0, q[4] || 0);
// 至少 5 格:0 时也有可见形状
var qSlots = Math.max(5, Math.min(16, maxQ));
var html = '<div class="card"><h2>' + title + "</h2>";
// 四个数字块(沿用本 app 的 statCard 风格)
html +=
'<div class="grid-4">' +
statCard(__("排队", "Ready"), ready, "") +
statCard(__("中断", "Pending"), pending, "") +
statCard(__("栈", "Stack"), stack + "/" + maxStack, "") +
statCard(__("子代理", "Subagents"), residents.length, "") +
"</div>";
// ---- 阶段管道:五个等大表框 ----
var g = rtPhaseGroup(state.pipelinePhase || "");
html +=
'<div class="rt-section-title">' + __("阶段管道", "Stage pipeline") +
(g < 0 ? " " + __("(空闲)", "(idle)") : "") + "</div>";
html += '<div class="rt-pipe-row' + (g < 0 ? " rt-pipe-idle" : "") + '">';
html += RT_PIPE_GROUPS.map(function (s, i) {
var items = (state.stageTrail || []).filter(function (t) {
return (t.g | 0) === i;
});
// 「工具」是循环格:一轮里可能调几十次工具/输出通道,全部追加会把这一格
// 撑成长条,反而看不出「现在在调什么」。只留**最新一条**,右侧给本轮累计
// 次数(与 WebUI 同一口径,见 internal/plugins/webui/dashboard.js)。
var cls = "rt-pipe-events";
var body;
if (!items.length) {
body = '<span class="rt-chip rt-chip-none">' + __("无", "none") + "</span>";
} else if (s.loop) {
cls += " rt-pipe-scroll";
var total = 0;
for (var k = 0; k < items.length; k++) total += items[k].n || 1;
var latest = items[items.length - 1];
var lkind = latest.kind || "stage";
var lico = lkind === "output" ? RT_ICO.out : lkind === "tool" ? RT_ICO.tool : "";
body =
'<span class="rt-chip rt-chip-' + lkind + (toolFlash ? " rt-chip-enter" : "") +
'" title="' + escHtml(latest.label) + '">' + lico +
'<b class="rt-chip-t">' + escHtml(latest.short || latest.label) + "</b>" +
(latest.n > 1 ? '<i class="rt-chip-n">x' + latest.n + "</i>" : "") +
"</span>" +
'<i class="rt-scroll-count" title="' +
__("本轮工具调用累计次数", "tool calls this turn") + '">x' + total + "</i>";
} else {
body = items
.map(function (t) {
var kind = t.kind || "stage";
var ico =
kind === "output" ? RT_ICO.out : kind === "tool" ? RT_ICO.tool : "";
return (
'<span class="rt-chip rt-chip-' + kind + '" title="' +
escHtml(t.label) + '">' + ico +
'<b class="rt-chip-t">' + escHtml(t.short || t.label) + "</b>" +
(t.n > 1 ? '<i class="rt-chip-n">x' + t.n + "</i>" : "") +
"</span>"
);
})
.join("");
}
return (
'<div class="rt-pipe-cell' + (i === g ? " active" : "") + '">' +
'<div class="rt-pipe-head">' + RT_ICO[s.ico] +
"<b>" + __(s.zh, s.en) + "</b>" +
(s.loop
? '<em class="rt-loop" title="' +
__("工具调用会回到行动后,可多次", "tool calls loop back; may repeat") +
'">' + RT_ICO.loop + "</em>"
: "") +
'</div><div class="' + cls + '">' + body + "</div></div>"
);
}).join("");
html += "</div>";
// ---- 中断队列:五个等大表框(L4/L3/L2/L1 + 排队)----
html += '<div class="rt-section-title">' + __("队列", "Queues") + "</div>";
html += '<div class="rt-queues">';
RT_LEVELS.forEach(function (L) {
var depth = q[L.lv] || 0;
var reg = byLv[L.lv] || 0;
var pre = preLv[L.lv] || 0;
var desc = __(L.zh, L.en);
html +=
'<div class="rt-qcell ' + L.cls + (depth ? " rt-active" : "") +
'" title="' + escHtml(desc) + '">' +
'<div class="rt-qhead"><b>' + L.name + "</b><span>" + escHtml(desc) + "</span></div>" +
'<div class="rt-qnum">' + depth + "</div>" +
rtSlots(depth, qSlots, L.cls) +
'<div class="rt-qmeta">' + reg + " " + __("登记", "reg") + " · " +
pre + " " + __("抢占", "pre") + "</div></div>";
});
// 排队队列无级别:用虚线框与四级中断区分(另一**类别**,不是另一优先级)
html +=
'<div class="rt-qcell rt-qcell-queued rt-lv-q' + (ready ? " rt-active" : "") +
'" title="' + __("排队(无级别,纯 FIFO)", "queued (no priority, FIFO)") + '">' +
'<div class="rt-qhead"><b>' + __("排队", "queued") + "</b><span>FIFO</span></div>" +
'<div class="rt-qnum">' + ready + "</div>" +
rtSlots(ready, qSlots, "rt-lv-q") +
'<div class="rt-qmeta">' + __("无级别", "no priority") + "</div></div>";
html += "</div></div>";
return html;
}
// 开源许可卡:协议标识 + 协议全文 + 源码仓库。
// AGPL-3.0 §13 的义务是「向网络使用者提供取得 Corresponding Source 的机会」——
// 只给一个仓库链接、不写协议名,使用者看不出这受什么许可约束。
function renderLegalCard() {
var b = ((state.kernel || {}).build) || {};
var src = b.source_url || "";
var lic = b.license || "";
var licURL = b.license_url || "";
if (!lic && !src) return "";
function row(key, val) {
return (
'<div class="kv-row"><span class="key">' + escHtml(key) +
'</span><span class="val">' + val + "</span></div>"
);
}
function a(href, text) {
return (
'<a href="' + escHtml(href) +
'" target="_blank" rel="noopener noreferrer">' + escHtml(text) + "</a>"
);
}
var rows = "";
if (lic) rows += row(__("许可协议", "License"), licURL ? a(licURL, lic) : escHtml(lic));
if (src) rows += row(__("源码仓库", "Source"), a(src, src));
// 网络条款只在 AGPL 系的许可下才成立,所以按标识判断,不硬写协议名。
var note =
lic && lic.toUpperCase().indexOf("AGPL") >= 0
? '<p class="rt-empty">' +
__(
"网络服务条款(§13):把修改后的版本作为网络服务对外提供时,必须向使用者提供取得对应源码的途径。",
"Network clause (section 13): offering a modified version as a network service requires giving users a way to obtain the Corresponding Source.",
) +
"</p>"
: "";
return '<div class="card"><h2>' + __("开源许可", "License") + "</h2>" + rows + note + "</div>";
}
function renderOverview() { function renderOverview() {
var s = state.status || {}; var s = state.status || {};
var k = state.kernel; var k = state.kernel;
@ -1018,7 +1296,25 @@ function renderOverview() {
"uptime", "uptime",
) + ) +
statCard(__("插件", "Plugins"), (k?.plugins || []).length || 0, "plugin") + statCard(__("插件", "Plugins"), (k?.plugins || []).length || 0, "plugin") +
statCard(__("版本", "Version"), s.version || "0.1.0", "version") + statCard(
__("版本", "Version"),
(function () {
// 构建身份取自 /kernel 的 build(-ldflags 注入的真实版本/commit)。
// 旧实现用的是 /status 的 version 加一个凭空写死的 "0.1.0" 兑底 ——
// 拿不到数据时会向用户展示一个不存在的版本号。
var b = (k && k.build) || {};
var v = b.version || s.version || "";
if (!v) return "-";
var sha =
b.commit && b.commit !== "unknown" ? String(b.commit).slice(0, 7) : "";
return (
"v" + escHtml(v) +
'<div class="stat-sub">' + escHtml(b.kernel_name || "HomeAgent") +
(sha ? " · " + escHtml(sha) : "") + "</div>"
);
})(),
"version",
) +
"</div>"; "</div>";
if (k) { if (k) {
html += html +=
@ -1082,6 +1378,7 @@ function renderOverview() {
"</span></div>" + "</span></div>" +
"</div></div>"; "</div></div>";
} }
html += renderRuntimePanel();
html += html +=
'<div class="card"><h2>' + '<div class="card"><h2>' +
__("运行时", "Runtime") + __("运行时", "Runtime") +
@ -1094,6 +1391,7 @@ function renderOverview() {
) + ) +
statCard("Go " + __("版本", "Version"), k?.runtime?.go_version || "-", "") + statCard("Go " + __("版本", "Version"), k?.runtime?.go_version || "-", "") +
"</div></div>"; "</div></div>";
html += renderLegalCard();
document.getElementById("view-overview").innerHTML = html; document.getElementById("view-overview").innerHTML = html;
} }
@ -5211,17 +5509,48 @@ async function connectFetchSSE(url) {
var phase = p.phase || ""; var phase = p.phase || "";
var tool = p.tool || ""; var tool = p.tool || "";
if (p.channel !== "_consolidation_") { if (p.channel !== "_consolidation_") {
if (phase === "pre_action") // 阶段轨迹:本轮真实发生过什么,按阶段落到运行态面板的对应框里。
// 与 WebUI 同一套 g(阶段组)编号,见 rtPhaseGroup。
if (phase === "on_input") {
state.stageTrail = [];
rtTrailPush(0, "stage", __("输入", "input"), __("输入", "input"));
} else if (phase === "pre_action") {
rtTrailPush(
1,
"stage",
__("组装上下文并思考", "assemble context and think"),
__("思考", "think"),
);
state.chatStage = __("AI 思考中...", "AI thinking..."); state.chatStage = __("AI 思考中...", "AI thinking...");
else if (phase === "before_toolcall") { } else if (phase === "before_toolcall") {
if (tool)
rtTrailPush(
2,
tool.indexOf("output_") === 0 ? "output" : "tool",
tool,
rtShortTool(tool),
);
if (tool) state.toolFlash = true;
state.chatStage = __("工具调用: ", "Tool: ") + (tool || ""); state.chatStage = __("工具调用: ", "Tool: ") + (tool || "");
if (tool && (state.pendingTools || []).indexOf(tool) === -1) { if (tool && (state.pendingTools || []).indexOf(tool) === -1) {
if (!state.pendingTools) state.pendingTools = []; if (!state.pendingTools) state.pendingTools = [];
state.pendingTools.push(tool); state.pendingTools.push(tool);
rerenderChatIfActive(); rerenderChatIfActive();
} }
} else if (phase === "before_output") } else if (phase === "before_output") {
rtTrailPush(3, "stage", __("生成回复", "generate reply"), __("生成", "gen"));
state.chatStage = __("生成回复中...", "Generating response..."); state.chatStage = __("生成回复中...", "Generating response...");
} else if (phase === "after_output") {
rtTrailPush(4, "stage", __("本轮完成", "turn complete"), __("完成", "done"));
}
state.pipelinePhase = phase;
// 阶段停留一会儿就回空闲,避免留下一个永远停在 after_output 的假状态。
if (state.pipelineTimer) clearTimeout(state.pipelineTimer);
state.pipelineTimer = setTimeout(function () {
state.pipelinePhase = "";
if (state.currentView === "overview") renderOverview();
}, 2500);
if (state.currentView === "overview") renderOverview();
} }
var badge = document.getElementById("chat-stage"); var badge = document.getElementById("chat-stage");
if (badge) { if (badge) {
@ -5403,12 +5732,21 @@ function renderDevices() {
} }
// 设备通道配置(独立于连接类型:devicced 是 GUI 组件,默认走 webui 反代端口) // 设备通道配置(独立于连接类型:devicced 是 GUI 组件,默认走 webui 反代端口)
var dbc = state.dbConfig || {}; var dbc = state.dbConfig || {};
var webuiUrl = ""; // 网关地址优先用**服务端发现的权威值**(state.discoveredGateway),
// 其次才是用户手填 / 本地推导。
//
// 为什么不能继续用「门户 URL 同 host 拼 /api/v1/device/ws」:
// 网关改造为子域反代后位于 devices.<基域名>,而**基域名与子域标签都是
// 服务端配置**,客户端无从得知。硬拼的结果是连到门户自己的路由上。
// 服务端 /api/v1/device/gateway 是唯一不会漂移的来源。
var webuiUrl = state.discoveredGateway || "";
if ( if (
!webuiUrl &&
state.currentConn && state.currentConn &&
state.currentConn.type === "webui" && state.currentConn.type === "webui" &&
state.currentConn.url state.currentConn.url
) { ) {
// 回退:老部署(无发现端点)仍按旧口径推导,保持向后兼容。
webuiUrl = state.currentConn.url.replace(/\/+$/, "") + "/api/v1/device/ws"; webuiUrl = state.currentConn.url.replace(/\/+$/, "") + "/api/v1/device/ws";
} }
var curGateway = dbc.gateway || webuiUrl || ""; var curGateway = dbc.gateway || webuiUrl || "";
@ -5553,8 +5891,8 @@ function renderDevices() {
html += html +=
'<p style="color:var(--text-muted)">' + '<p style="color:var(--text-muted)">' +
__( __(
"暂无设备接入。设备通过 WebSocket 连接到设备网关(默认 127.0.0.1:9890/api/v1/device/ws),携带 token 后 hello 登记、bind 授权。", "暂无设备接入。设备通过 WebSocket 连接到设备网关(默认经 HomeAgent 反代到 devices.<基域名>,或直连 127.0.0.1:9890/api/v1/device/ws),携带 token 后 hello 登记、bind 授权。",
"No devices yet. Devices connect via WebSocket (default 127.0.0.1:9890/api/v1/device/ws), hello to register, bind to authorize.", "No devices yet. Devices connect via WebSocket (proxied by HomeAgent at devices.<base-domain>, or directly 127.0.0.1:9890/api/v1/device/ws), hello to register, bind to authorize.",
) + ) +
"</p>"; "</p>";
} else { } else {

View File

@ -2191,3 +2191,284 @@ td .switch {
.kv-row .val .switch { .kv-row .val .switch {
margin-right: 4px; margin-right: 4px;
} }
/* ===== 运行态面板:阶段管道 + 中断队列(与 WebUI 总览同一套设计语言)=====
两块都统一成**等大表框**,与 KPI 卡同一种骨架。
此前桌面版总览只有四个数字卡:既看不到「这一轮走到哪一步」,
也看不到四级中断队列的积压。 */
.stat-card .stat-sub {
margin-top: 4px;
font-size: 11px;
font-weight: 500;
color: var(--text-muted);
font-variant-numeric: tabular-nums;
}
.rt-section-title {
font-size: 12px;
font-weight: 600;
color: var(--text-secondary);
letter-spacing: 0.3px;
margin: 14px 0 8px;
text-transform: uppercase;
}
.rt-empty {
font-size: 12px;
color: var(--text-muted);
padding: 4px 0;
}
/* 行内小图标:一律 SVG,不使用 emoji/符号字符。 */
.rt-ico {
width: 12px;
height: 12px;
flex: 0 0 auto;
fill: none;
stroke: currentColor;
stroke-width: 2;
stroke-linecap: round;
stroke-linejoin: round;
vertical-align: -1.5px;
}
.rt-pipe-row {
display: grid;
/* 100px 下限:容器再窄也要保证 5 个框一行,不留「4 个 + 1 个」的孤行 */
grid-template-columns: repeat(auto-fit, minmax(100px, 1fr));
gap: 10px;
margin: 2px 0 8px;
transition: opacity 0.3s var(--ease-out);
}
.rt-pipe-idle {
opacity: 0.55;
}
.rt-pipe-cell {
display: flex;
flex-direction: column;
gap: 8px;
padding: 11px 12px 10px;
border-radius: var(--radius-md);
background: var(--bg-input);
border: 1px solid var(--border-color);
min-width: 0;
transition:
border-color 0.25s var(--ease-out),
box-shadow 0.25s var(--ease-out),
background 0.25s var(--ease-out);
}
.rt-pipe-cell.active {
border-color: var(--accent);
background: var(--accent-bg);
box-shadow: var(--shadow-md);
}
.rt-pipe-head {
display: flex;
align-items: center;
gap: 6px;
min-width: 0;
}
.rt-pipe-head > b {
font-size: 13.5px;
font-weight: 700;
color: var(--text-secondary);
white-space: nowrap;
overflow: hidden;
text-overflow: ellipsis;
}
.rt-pipe-head .rt-ico {
width: 15px;
height: 15px;
color: var(--text-secondary);
}
.rt-pipe-cell.active .rt-pipe-head > b,
.rt-pipe-cell.active .rt-pipe-head .rt-ico {
color: var(--accent);
}
.rt-pipe-events {
display: flex;
flex-wrap: wrap;
gap: 4px;
min-height: 23px;
}
/* 「工具」格的滚动视口:固定一行高,只露最新一条(与 WebUI 同一口径)。 */
.rt-pipe-scroll {
flex-wrap: nowrap;
height: 23px;
min-height: 23px;
overflow: hidden;
align-items: center;
}
.rt-pipe-scroll .rt-chip {
flex: 0 1 auto;
min-width: 0;
max-width: none;
}
.rt-chip-enter {
animation: rt-chip-scroll-in 0.3s var(--ease-out);
}
@keyframes rt-chip-scroll-in {
from {
transform: translateY(115%);
opacity: 0;
}
to {
transform: translateY(0);
opacity: 1;
}
}
.rt-scroll-count {
flex: 0 0 auto;
margin-left: auto;
font-style: normal;
font-size: 10.5px;
opacity: 0.6;
font-variant-numeric: tabular-nums;
}
.rt-loop {
display: inline-flex;
color: var(--accent);
font-weight: 700;
}
.rt-chip {
display: inline-flex;
align-items: center;
gap: 3px;
min-width: 0;
max-width: 170px;
overflow: hidden;
text-overflow: ellipsis;
white-space: nowrap;
font-size: 11px;
padding: 2px 8px;
border-radius: var(--radius-pill);
background: var(--bg-hover);
border: 1px solid var(--border-color);
color: var(--text-secondary);
}
.rt-chip-t {
font-weight: inherit;
min-width: 0;
overflow: hidden;
text-overflow: ellipsis;
white-space: nowrap;
}
.rt-chip-tool {
border-color: rgba(136, 192, 208, 0.42);
color: var(--frost-300);
}
.rt-chip-output {
border-color: var(--accent);
color: var(--accent);
}
.rt-chip-stage {
opacity: 0.7;
}
.rt-chip-none {
opacity: 0.35;
border-style: dashed;
}
.rt-chip-n {
font-style: normal;
opacity: 0.75;
font-variant-numeric: tabular-nums;
}
/* 队列:5 个等大框(L4/L3/L2/L1 + 排队),一行排开 */
.rt-queues {
display: grid;
grid-template-columns: repeat(auto-fit, minmax(100px, 1fr));
gap: 10px;
margin-bottom: 4px;
}
.rt-qcell {
display: flex;
flex-direction: column;
gap: 7px;
padding: 11px 12px 10px;
border-radius: var(--radius-md);
background: var(--bg-input);
border: 1px solid var(--border-color);
min-width: 0;
transition:
border-color 0.25s var(--ease-out),
box-shadow 0.25s var(--ease-out);
}
.rt-qhead {
display: flex;
align-items: baseline;
gap: 7px;
min-width: 0;
}
.rt-qhead > b {
font-size: 16px;
font-weight: 800;
line-height: 1;
letter-spacing: -0.02em;
}
.rt-qhead > span {
font-size: 10.5px;
color: var(--text-muted);
white-space: nowrap;
overflow: hidden;
text-overflow: ellipsis;
}
.rt-qnum {
font-size: 26px;
font-weight: 800;
line-height: 1;
letter-spacing: -0.02em;
font-variant-numeric: tabular-nums;
}
.rt-qmeta {
display: flex;
align-items: center;
flex-wrap: wrap;
gap: 4px 8px;
font-size: 10.5px;
color: var(--text-muted);
font-variant-numeric: tabular-nums;
}
.rt-qcell.rt-lv-4 .rt-qhead > b { color: #ff5c7a; }
.rt-qcell.rt-lv-3 .rt-qhead > b { color: #ffa657; }
.rt-qcell.rt-lv-2 .rt-qhead > b { color: var(--sakura-400); }
.rt-qcell.rt-lv-1 .rt-qhead > b { color: var(--frost-300); }
.rt-qcell.rt-lv-q .rt-qhead > b { color: #a3be8c; }
/* 有积压时整个框描边点亮:一眼看出哪条队列在堵 */
.rt-qcell.rt-lv-4.rt-active { border-color: rgba(255, 92, 122, 0.55); }
.rt-qcell.rt-lv-3.rt-active { border-color: rgba(255, 166, 87, 0.55); }
.rt-qcell.rt-lv-2.rt-active { border-color: var(--sakura-400); }
.rt-qcell.rt-lv-1.rt-active { border-color: var(--frost-300); }
.rt-qcell.rt-lv-q.rt-active { border-color: #a3be8c; }
/* 排队队列无级别:虚线框与四级中断区分(另一**类别**,不是另一优先级) */
.rt-qcell.rt-qcell-queued {
border-style: dashed;
}
/* 队列格槽:固定可见的「车位」,占用多少一眼可数。
用进度条时队列为 0 宽度就是 0,整行只剩文字,看上去就是「这块空着」。 */
.rt-slots {
display: flex;
align-items: stretch;
gap: 3px;
height: 16px;
min-width: 0;
}
.rt-slots > i {
flex: 1 1 0;
min-width: 3px;
border-radius: 3px;
background: rgba(255, 255, 255, 0.06);
border: 1px solid rgba(255, 255, 255, 0.05);
transition:
background 0.25s var(--ease-out),
box-shadow 0.25s var(--ease-out);
}
.rt-slots.rt-lv-4 > i.on { background: #ff5c7a; box-shadow: 0 0 6px rgba(255, 92, 122, 0.45); }
.rt-slots.rt-lv-3 > i.on { background: #ffa657; box-shadow: 0 0 6px rgba(255, 166, 87, 0.4); }
.rt-slots.rt-lv-2 > i.on { background: var(--sakura-400); box-shadow: 0 0 6px rgba(255, 127, 172, 0.4); }
.rt-slots.rt-lv-1 > i.on { background: var(--frost-300); box-shadow: 0 0 6px rgba(136, 192, 208, 0.4); }
.rt-slots.rt-lv-q > i.on { background: #a3be8c; box-shadow: 0 0 6px rgba(163, 190, 140, 0.4); }
.rt-slots-more {
flex: 0 0 auto;
align-self: center;
margin-left: 4px;
font-size: 10px;
font-weight: 600;
color: var(--text-muted);
font-variant-numeric: tabular-nums;
}

View File

@ -0,0 +1,100 @@
// Command homed-kb-migrate 迁移存量知识库的目录名到规范名。
//
// 背景:旧版 Add 对名字**整串** sanitize、对路径**逐段** sanitize,
// 于是知识名(内存键 / LLM 可见的名字)与盘上目录从第一次落盘起就对不上。
// 典型残留:
//
// tech/_go_/note 分类段内的空格未被 TrimSpace 掉
// Tech/Upper 未小写化
// a/b with space 空格未替换成下划线
//
// 迁移把它们重命名到规范名,使三者一致。
//
// 安全设计:
// 1. **默认只报告**(-apply 才真改名)。批量 os.Rename 不可逆。
// 2. 检出目标名冲突则**整批拒绝**,不做部分迁移——半迁移状态比不迁移更难收拾。
// 3. 单条失败不中断整体,最后统一报告;执行前再查一次目标越界。
//
// 与 homed 启动时的关系:`homed` 启动会调同一个 PlanMigration 并**只报告**
// (见 cmd/homed/bootstrap.go 的 defaultApply)。本命令是人工确认后真正执行
// 的那一步。两者共用 internal/knowledge 里的同一份实现,避免口径漂移。
//
// 用法:
//
// homed-kb-migrate -root /data/homeagent/knowledge # 报告
// homed-kb-migrate -root /data/homeagent/knowledge -apply # 执行
package main
import (
"flag"
"fmt"
"os"
"path/filepath"
"gitcode.com/JianFeeeee/HomeAgent/internal/knowledge"
)
func main() {
root := flag.String("root", "", "知识库根目录(必填)")
apply := flag.Bool("apply", false, "真正执行重命名(缺省只报告)")
dryRun := flag.Bool("dry-run", false, "只报告(显式写法,与默认相同)")
limit := flag.Int("limit", 0, "单次最多改名条数,0 = 不限")
flag.Parse()
if *root == "" {
fmt.Fprintln(os.Stderr, "错误:必须指定 -root <知识库根目录>")
flag.Usage()
os.Exit(2)
}
if *apply && *dryRun {
fmt.Fprintln(os.Stderr, "错误:-apply 与 -dry-run 互斥")
os.Exit(2)
}
abs, err := filepath.Abs(*root)
if err != nil {
fmt.Fprintf(os.Stderr, "错误:%v\n", err)
os.Exit(1)
}
abs = filepath.Clean(abs)
items, err := knowledge.PlanMigration(abs)
if err != nil {
fmt.Fprintf(os.Stderr, "错误:无法读取 %s:%v\n", abs, err)
os.Exit(1)
}
if len(items) == 0 {
fmt.Printf("未发现任何知识条目(%s)\n", abs)
return
}
var need, illegal int
for _, it := range items {
switch {
case it.Illegal:
illegal++
fmt.Printf(" [非法] %-40s 含 .. / 点段 / 隐藏段;写入与删除均已拒绝,需人工处理\n", it.OldName)
case it.NewName != "":
need++
fmt.Printf(" [迁移] %-40s → %s\n", it.OldName, it.NewName)
}
}
fmt.Printf("\n共 %d 条:需迁移 %d,已规范 %d,非法 %d\n",
len(items), need, len(items)-need-illegal, illegal)
if !*apply {
if need == 0 {
fmt.Println("\n无需迁移。加 -apply 不会改变任何东西。")
return
}
fmt.Println("\n这是报告(未改动任何文件)。确认无误后加 -apply 执行。")
return
}
applied, failed := knowledge.ApplyMigration(abs, items, *limit)
fmt.Printf("\n迁移完成:成功 %d,失败 %d\n", applied, failed)
if failed > 0 {
fmt.Fprintln(os.Stderr, "存在失败项。若为名称冲突,请先人工处理冲突的目录再重跑。")
os.Exit(1)
}
}

962
cmd/homed/bootstrap.go Normal file
View File

@ -0,0 +1,962 @@
package main
import (
"context"
"flag"
"fmt"
"io"
"log"
"os"
"os/signal"
"path/filepath"
"strings"
"syscall"
"time"
agentPkg "gitcode.com/JianFeeeee/HomeAgent/internal/agent"
agentAPI "gitcode.com/JianFeeeee/HomeAgent/internal/agent/api"
agentCore "gitcode.com/JianFeeeee/HomeAgent/internal/agent/core"
agentIO "gitcode.com/JianFeeeee/HomeAgent/internal/agent/io"
internalConfig "gitcode.com/JianFeeeee/HomeAgent/internal/config"
"gitcode.com/JianFeeeee/HomeAgent/internal/events"
"gitcode.com/JianFeeeee/HomeAgent/internal/ipc"
"gitcode.com/JianFeeeee/HomeAgent/internal/knowledge"
logpkg "gitcode.com/JianFeeeee/HomeAgent/internal/log"
luapkg "gitcode.com/JianFeeeee/HomeAgent/internal/lua"
"gitcode.com/JianFeeeee/HomeAgent/internal/memory"
"gitcode.com/JianFeeeee/HomeAgent/internal/memory/document"
"gitcode.com/JianFeeeee/HomeAgent/internal/memory/media"
"gitcode.com/JianFeeeee/HomeAgent/internal/memory/pipeline"
"gitcode.com/JianFeeeee/HomeAgent/internal/memory/social"
"gitcode.com/JianFeeeee/HomeAgent/internal/memory/text"
"gitcode.com/JianFeeeee/HomeAgent/internal/memory/vector"
"gitcode.com/JianFeeeee/HomeAgent/internal/nlp"
"gitcode.com/JianFeeeee/HomeAgent/internal/plugin"
"gitcode.com/JianFeeeee/HomeAgent/internal/recovery"
sdk "gitcode.com/JianFeeeee/HomeAgent/internal/sdk"
"gitcode.com/JianFeeeee/HomeAgent/internal/supervisor"
"gitcode.com/JianFeeeee/HomeAgent/internal/tracker"
"gitcode.com/JianFeeeee/HomeAgent/pkg/embedding"
"gitcode.com/JianFeeeee/HomeAgent/pkg/types"
)
// defaultSystemPrompt 是内置默认人格模板:不含版本号字面量,
// 被问版本时以运行时快照为准(历史上写死版本号导致实例自称旧版本)。
const defaultSystemPrompt = `你是 HomeAgent,一个持续运行的个人管家。
你的每次回复会自动发送到当前输出通道(默认=输入源),无需额外工具。
如需切换回复通道,使用 output_set_channel。
如需异步发送消息或通知,使用 output_send 指定通道和内容。
使用 output_list_channels 查看可用通道及其能力。
可用工具列表会由系统自动传入,按需使用即可。以下是你尤其需要关注的几类工具:
- memory_* — 图记忆(长期记忆,记录和查询个人信息/事实)
- knowledge_* — 知识库(查阅预设知识文档)
- doc_* — 文档记忆(近期对话的存档,查询后自动清除)
- person_* — 人物特质与社交关系网
- llm_* — LLM 源管理(列出/切换模型提供商)
- output_* — 输出通道管理(切换/发送消息)
- timer_set — 设置定时提醒
- plgreload — 热重载插件
- spawn_child — 生成子 Agent 异步执行独立任务(可传 max_turns 控制工具轮数,默认 5)
并行策略:遇到多个互不依赖的子任务时,优先并行 spawn 多个子 Agent 而非自己串行逐个执行;
长耗时任务(批量处理、多轮搜索汇总)也应交给子 Agent,避免阻塞当前对话。
- describe_image — 描述用户上传的图片
- transcribe_audio — 转写用户上传的音频
- ocr_image — 识别图片中的文字
命令与文件操作策略:
- cmd_run 经完整 shell(bash)执行,支持管道、分号、&&、命令替换、heredoc、重定向。
- 多步交互式程序(vim/top/ssh 会话、需要持续输入的进程)用 terminal_create 创建终端,
terminal_write 发送输入、terminal_read 读输出——不要用 cmd_run 硬等交互程序退出。
- 写文件优先 files_write(原子+留档),生成多行内容时可用 heredoc 或 files_write,
不要用 echo 拼接长文本。
- 读用户发来的文件用 files_read;向 webui 回传图片/文件用 output_send__webui(type=image/file)。
当用户上传图片或音频时,系统会自动附着媒体内容。如果模型不支持直接处理多媒体,请使用上述工具。
回复你的真实想法,用自然语言与用户交流。不要在回复中使用 emoji 表情。`
// setupLogging 初始化日志:行号前缀 + 同时输出到控制台与 <data>/log/ 下的本次启动文件。
//
// 本函数体是 main() 里对应启动阶段的整块平移:语句、日志文本、错误语义不变,
// 只把「*dataDir」变成参数、把 defer 变成由调用点注册的 cleanup。
func setupLogging(dataDir string) string {
log.SetFlags(log.Ldate | log.Ltime | log.Lshortfile)
// 文件日志:同时输出到控制台和 data/log/ 目录
logDir := filepath.Join(dataDir, "log")
if err := os.MkdirAll(logDir, 0755); err != nil {
log.Printf("[homed] warning: cannot create log dir: %v", err)
} else {
logPath := filepath.Join(logDir, fmt.Sprintf("homed_%s.log", time.Now().Format("2006-01-02_15-04-05")))
logFile, err := os.OpenFile(logPath, os.O_CREATE|os.O_WRONLY|os.O_APPEND, 0644)
if err != nil {
log.Printf("[homed] warning: cannot open log file: %v", err)
} else {
log.SetOutput(io.MultiWriter(os.Stderr, logFile))
log.Printf("[homed] logging to %s", logPath)
}
}
return logDir
}
// ensureDataDirs 建好启动期需要的全部目录,返回 agent 的 overlayfs 工作目录。
//
// 本函数体是 main() 里对应启动阶段的整块平移:语句、日志文本、错误语义不变,
// 只把「*dataDir」变成参数、把 defer 变成由调用点注册的 cleanup。
func ensureDataDirs(dataDir string) string {
agentWorkDir := filepath.Join(dataDir, "agentfs")
dirs := []string{
dataDir,
filepath.Join(dataDir, "snapshots"),
filepath.Join(dataDir, "plugins"),
filepath.Join(dataDir, "changesets"),
filepath.Join(dataDir, "memory"),
filepath.Join(dataDir, "memory", "raw"),
filepath.Join(dataDir, "adapters"),
agentWorkDir,
}
for _, d := range dirs {
if err := os.MkdirAll(d, 0755); err != nil {
log.Fatalf("create dir %s: %v", d, err)
}
}
return agentWorkDir
}
// memoryStack 聚合记忆侧组件:图库、索引器、社交图、蒸馏器。
type memoryStack struct {
db *memory.GraphDB
indexer *memory.Indexer
social *social.SocialStore
distiller *pipeline.Distiller
}
// initMemoryStack 初始化图记忆 / 索引 / 社交图 / 蒸馏管线。
//
// 本函数体是 main() 里对应启动阶段的整块平移:语句、日志文本、错误语义不变,
// 只把「*dataDir」变成参数、把 defer 变成由调用点注册的 cleanup。
func initMemoryStack(dataDir string) (*memoryStack, func()) {
memDB, err := memory.NewGraphDB(filepath.Join(dataDir, "memory", "graph.db"))
if err != nil {
log.Printf("[homed] warning: memory init failed: %v", err)
memDB = nil
} else {
log.Printf("[homed] graph memory initialized")
}
memIdx := memory.NewIndexer(memDB)
memIdx.Sync() // 启动时立即同步,避免前30分钟空窗
socialStore := social.New(memDB)
distiller := pipeline.NewDistiller(memDB, dataDir, pipeline.DistillerConfig{
Interval: 10 * time.Minute,
RetentionDays: 7,
BatchSize: 50,
})
if memDB != nil {
// 这里**故意不写 defer distiller.Stop()**:本函数在 return 时即触发
// defer,而 Stop() → cancel() 会让刚启动的 distillLoop 立刻退出,
// 规则蒸馏管线启动即死、10min 心跳从不运行(旧 main() 拆分时的残留)。
// 停机由调用点注册的 cleanup 负责(见下方返回值)。
distiller.Start()
}
return &memoryStack{db: memDB, indexer: memIdx, social: socialStore, distiller: distiller},
func() {
// 与原 main 的两个 defer 同序(LIFO):先停蒸馏器,再关图库。
if memDB != nil {
distiller.Stop()
}
if memDB != nil {
memDB.Close()
}
}
}
// startMemoryCandidateConsumer 起一个常驻 goroutine:把 eventbus 上的 memory_candidate 事件写进文本记忆并喂给蒸馏管线。
//
// 本函数体是 main() 里对应启动阶段的整块平移:语句、日志文本、错误语义不变,
// 只把「*dataDir」变成参数、把 defer 变成由调用点注册的 cleanup。
func startMemoryCandidateConsumer(ctx context.Context, iom *agentIO.IOManager, textMem *text.Memory, memDB *memory.GraphDB, distiller *pipeline.Distiller) {
go func() {
for {
select {
case <-ctx.Done():
return
case evt, ok := <-iom.OutputChan():
if !ok {
return
}
if evt.Target == "memory" && evt.Type == "memory_candidate" {
source, _ := evt.Payload["source"].(string)
input, _ := evt.Payload["input"].(string)
response, _ := evt.Payload["response"].(string)
toolsUsed, _ := evt.Payload["tools_used"].([]string)
toolResults, _ := evt.Payload["tool_results"].([]interface{})
agentID, _ := evt.Payload["agent_id"].(string)
if input != "" && textMem != nil {
te := text.Event{
Timestamp: time.Now().Unix(),
Source: source,
Input: input,
Response: response,
ToolsUsed: toolsUsed,
AgentID: agentID,
}
if err := textMem.Append(te); err != nil {
log.Printf("[homed] text memory append: %v", err)
}
}
if input != "" && memDB != nil {
distiller.Append("agent", "user", input)
}
if response != "" && memDB != nil {
distiller.Append("agent", "assistant", response)
}
// 工具输出接入蒸馏管线
for _, tr := range toolResults {
if trMap, ok := tr.(map[string]interface{}); ok {
if text, ok := trMap["output"].(string); ok && text != "" && memDB != nil {
distiller.Append("agent", "tool", text)
}
}
}
}
}
}
}()
}
// initLLMProviders 按配置注册全部 LLM 源(每个源经 Lua 适配器协议转换),并把各适配器的并发额度汇总回 Lua VM。
//
// 本函数体是 main() 里对应启动阶段的整块平移:语句、日志文本、错误语义不变,
// 只把「*dataDir」变成参数、把 defer 变成由调用点注册的 cleanup。
func initLLMProviders(cfg *types.Config, luaVM *luapkg.VM, baseAPIKey string) *agentAPI.ProviderManager {
providerMgr := agentAPI.NewProviderManager()
adapterConcurrency := map[string]int{}
for _, src := range cfg.LLM.Sources {
if !agentAPI.IsValidSourceConfig(src.Name, src.BaseURL, src.Model, src.Adapter) {
log.Printf("[homed] skip invalid llm source %q (base_url=%q model=%q adapter=%q)", src.Name, src.BaseURL, src.Model, src.Adapter)
continue
}
key := src.APIKey
if key == "" {
key = baseAPIKey
}
luaProvider := agentAPI.NewLuaAdaptedProvider(agentAPI.BaseConfig{
Model: src.Model,
BaseURL: src.BaseURL,
APIKey: key,
Temperature: cfg.LLM.Temperature,
MaxTokens: cfg.LLM.MaxTokens,
ContextWindow: src.ContextWindow,
MaxConcurrent: src.MaxConcurrent,
Priority: src.Priority,
Vision: src.Vision,
Audio: src.Audio,
}, luaVM, src.Name, src.Adapter)
providerMgr.Register(src.Name, luaProvider)
if src.Adapter != "" {
adapterConcurrency[src.Adapter] += src.MaxConcurrent
}
}
luaVM.ConfigureConcurrency(adapterConcurrency)
if cfg.LLM.Provider != "" {
providerMgr.SetDefault(cfg.LLM.Provider)
}
return providerMgr
}
// initDocStore 启动文档记忆。flush 的唯一入口是 Stop(),所以关停时必须调用它。
//
// 本函数体是 main() 里对应启动阶段的整块平移:语句、日志文本、错误语义不变,
// 只把「*dataDir」变成参数、把 defer 变成由调用点注册的 cleanup。
func initDocStore(cfg *types.Config) (*document.Store, func()) {
docStore := document.NewStore(filepath.Join(cfg.Daemon.DataDir, "memory", "documents"), memory.TokenizeWords)
if err := docStore.Start(); err != nil {
log.Printf("[homed] warning: document store: %v", err)
}
// 关停时落盘。文档记忆的内存态变更(迁移结果、访问计数等)只在 flush
// 里写盘,而 flush 的唯一入口是 Stop()——此前全仓无人调用它,
// 于是迁移结果永不落盘、每次启动白算一遍。
return docStore, func() { docStore.Stop() }
}
// initMediaStore 按开关启动内容寻址的媒体存储;开不起来只告警(媒体记忆非对话必需品)。
//
// 本函数体是 main() 里对应启动阶段的整块平移:语句、日志文本、错误语义不变,
// 只把「*dataDir」变成参数、把 defer 变成由调用点注册的 cleanup。
func initMediaStore(cfgReg *internalConfig.ConfigRegistry, cfg *types.Config) (*media.Store, func()) {
var mediaStore *media.Store
if cfgReg.GetBool("core.memory.media.enabled", true) {
mediaDir := cfgReg.GetString("core.memory.media.dir",
filepath.Join(cfg.Daemon.DataDir, "memory", "media"))
ms, err := media.New(mediaDir)
if err != nil {
// 媒体存储开不起来不该阻止启动——它是记忆增强,不是对话必需品
log.Printf("[homed] warning: media store: %v(媒体记忆已禁用)", err)
} else {
mediaStore = ms
st := mediaStore.Stats()
log.Printf("[homed] media store active: %v 条 / %v 字节",
st["count"], st["total_bytes"])
}
}
return mediaStore, func() {
if mediaStore != nil {
mediaStore.Close()
}
}
}
// initMultimodalSpace 从公共注册表打开多模态向量 provider。返回 (空间, provider 名, 失败原因, cleanup):后两个值只用于状态报告。
//
// 本函数体是 main() 里对应启动阶段的整块平移:语句、日志文本、错误语义不变,
// 只把「*dataDir」变成参数、把 defer 变成由调用点注册的 cleanup。
func initMultimodalSpace(cfgReg *internalConfig.ConfigRegistry) (vector.MultimodalEmbedder, string, string, func()) {
var multimodalSpace vector.MultimodalEmbedder
// 这两个值只用于状态报告(healthcheck_kernel 的 onnx 段):
// 「配了哪个 provider」与「为什么没启用」,避免只能看到 false 却不知原因。
var mmProviderName, mmErr string
var closeAdapted func()
if mmProvider := cfgReg.GetString("core.memory.multimodal_space.provider", ""); mmProvider != "" {
mmProviderName = mmProvider
opts := map[string]string{}
const optPrefix = "core.memory.multimodal_space.options."
for _, key := range cfgReg.List("core.memory.multimodal_space.options.") {
opts[strings.TrimPrefix(key, optPrefix)] = cfgReg.GetString(key, "")
}
provider, err := embedding.Open(mmProvider, embedding.Config{Options: opts})
if err != nil {
mmErr = err.Error()
log.Printf("[homed] warning: 多模态向量 provider %q 打开失败: %v(多模态向量检索已禁用;已注册: %s)",
mmProvider, err, strings.Join(embedding.Names(), ", "))
} else if adapted, err := vector.AdaptProvider(provider); err != nil {
provider.Close()
mmErr = err.Error()
log.Printf("[homed] warning: 多模态向量 provider %q 元数据不合法: %v(多模态向量检索已禁用)", mmProvider, err)
} else {
multimodalSpace = adapted
info := provider.Info()
// 指纹可能很长(模型文件哈希),日志里只取前 12 个字符便于对照。
shortFP := info.Fingerprint
if len(shortFP) > 12 {
shortFP = shortFP[:12]
}
log.Printf("[homed] multimodal space active: provider=%s dim=%d fp=%s modalities=%v",
mmProvider, info.Dimension, shortFP, info.Modalities)
}
}
if closeAdapted == nil {
closeAdapted = func() {}
}
return multimodalSpace, mmProviderName, mmErr, closeAdapted
}
// initKnowledgeStore 启动知识库。
//
// 本函数体是 main() 里对应启动阶段的整块平移:语句、日志文本、错误语义不变,
// 只把「*dataDir」变成参数、把 defer 变成由调用点注册的 cleanup。
func initKnowledgeStore(cfg *types.Config) *knowledge.Store {
ks := knowledge.NewStore(filepath.Join(cfg.Daemon.DataDir, "knowledge"))
if err := ks.Start(); err != nil {
log.Printf("[homed] warning: knowledge store: %v", err)
} else {
log.Printf("[homed] knowledge store active with %d items", len(ks.List()))
}
return ks
}
// initKnowledgeMigration 在知识库扫盘**之前**把存量目录名规范化。
//
// 为何不靠 Store 内部自己做:规范名是「内存键 + 盘上目录 + LLM 可见名字」
// 三者必须逐字一致,而磁盘重命名属于有破坏性的副作用,应该在 store 扫盘
// 之前、在明确的边界上一次性做完,而不是散在 Store 的初始化路径里。
//
// 为何默认只报告:os.Rename 不可逆,批量重命名生产数据必须由人确认。
// 需要真正迁移时用 homed-kb-migrate -apply(或把下面 defaultApply 打开)。
//
// 本函数体同样遵守 bootstrap 的平移原则。
func initKnowledgeMigration(cfg *types.Config) {
root := filepath.Join(cfg.Daemon.DataDir, "knowledge")
const (
// defaultApply = false ⇒ 启动时只扫描并报告,不改名。
defaultApply = false
// maxRenamePerRun 限制单次重命名数:给失控的目录规模设一个上限,
// 避免启动阶段被一次大迁移拖住。
maxRenamePerRun = 200
)
items, err := knowledge.PlanMigration(root)
if err != nil {
log.Printf("[homed] 知识库迁移扫描失败(跳过): %v", err)
return
}
need, illegal := 0, 0
for _, it := range items {
if it.Illegal {
illegal++
} else if it.NewName != "" {
need++
}
}
if need == 0 && illegal == 0 {
return
}
if illegal > 0 {
log.Printf("[homed] 知识库迁移:%d 条名称非法(含 .. / 点段 / 隐藏段),写入与删除均已拒绝,需人工处理", illegal)
}
if need == 0 {
return
}
log.Printf("[homed] 知识库迁移:%d/%d 条目录名待规范化(例:%s → %s)", need, len(items),
items[0].OldName, items[0].NewName)
if !defaultApply {
log.Printf("[homed] 知识库迁移:当前为只报告模式。确认清单后执行:homed-kb-migrate -root %s -apply", root)
return
}
if need > maxRenamePerRun {
log.Printf("[homed] 知识库迁移:需改名 %d 条超过单次上限 %d,本次只处理前 %d 条",
need, maxRenamePerRun, maxRenamePerRun)
}
applied, failed := knowledge.ApplyMigration(root, items, maxRenamePerRun)
log.Printf("[homed] 知识库迁移完成:成功 %d,失败 %d", applied, failed)
}
// loadPersonality 按「个人文件 > 配置项」的优先级解析人格内容,并对腐坏内容告警。
//
// 本函数体是 main() 里对应启动阶段的整块平移:语句、日志文本、错误语义不变,
// 只把「*dataDir」变成参数、把 defer 变成由调用点注册的 cleanup。
func loadPersonality(cfg *types.Config, cfgReg *internalConfig.ConfigRegistry) *agentPkg.Personality {
personalPath := filepath.Join(cfg.Daemon.DataDir, "personal", "personal.md")
personality, err := agentPkg.LoadPersonality(personalPath)
if err != nil {
log.Printf("[homed] warning: load personality: %v", err)
}
if personality != nil && personality.Content != "" {
log.Printf("[homed] 人格来源=文件 %s(优先于配置项),%d 字节", personalPath, len(personality.Content))
if hints := agentPkg.PersonaStaleHints(personality.Content); len(hints) > 0 {
log.Printf("[homed] warning: 人格文件含会腐坏的内容 %v — 建议迁到配置项 core.agent.personal_prompt"+
"(默认模板不含版本号,被问版本时以运行时快照为准)", hints)
}
} else if pv := cfgReg.GetString("core.agent.personal_prompt", internalConfig.DefaultPersonaPrompt); strings.TrimSpace(pv) != "" {
personality = &agentPkg.Personality{Content: pv, Path: "(core.agent.personal_prompt)"}
log.Printf("[homed] 人格来源=配置项 core.agent.personal_prompt,%d 字节", len(pv))
} else {
log.Printf("[homed] 人格来源=无(配置项为空且无人格文件)")
}
return personality
}
// newStageAndRegistry 建阶段管道与插件注册表,把内核依赖接到注册表上。
//
// 本函数体是 main() 里对应启动阶段的整块平移:语句、日志文本、错误语义不变,
// 只把「*dataDir」变成参数、把 defer 变成由调用点注册的 cleanup。
func newStageAndRegistry(cfg *types.Config, cfgReg *internalConfig.ConfigRegistry, iom *agentIO.IOManager,
evBus *events.Bus, memDB *memory.GraphDB, textMem *text.Memory, docStore *document.Store,
mediaStore *media.Store, ks *knowledge.Store, providerMgr *agentAPI.ProviderManager,
dataDir string) (*agentCore.StageHost, *plugin.Registry) {
stageHost := agentCore.NewStageHost()
pluginReg := plugin.NewRegistry()
pluginReg.SetIOManager(iom)
pluginReg.SetEventBus(evBus)
pluginReg.SetMemory(memDB)
pluginReg.SetTextMemory(textMem)
pluginReg.SetDocStore(docStore)
pluginReg.SetMediaStore(mediaStore) // 插件写入的记忆也走媒体链路;nil 时静默降级
pluginReg.SetKnowledge(ks)
pluginReg.SetProviderManager(providerMgr)
pluginReg.SetConfigRegistry(cfgReg)
pluginReg.SetPluginDir(cfg.Plugin.Dir)
pluginReg.SetDataDir(dataDir) // 插件 SettingsAPI.DataDir() 的数据根目录
// Wire registration callbacks: plugins' RegisterTool/RegisterStage → StageHost
pluginReg.SetToolRegistrar(func(name string, def sdk.ToolDef, handler sdk.ToolHandler) error {
log.Printf("[homed] SetToolRegistrar registering tool: %s (plugin=%s)", name, def.Plugin)
return stageHost.RegisterTool(name, def, handler)
})
pluginReg.SetStageRegistrar(func(stage sdk.Stage, handler sdk.StageHandler) {
stageHost.RegisterStage(stage, handler)
})
pluginReg.SetAPIRegistrar(func(name string) error {
return nil
})
pluginReg.SetToolCleaner(stageHost)
return stageHost, pluginReg
}
// newMainAgent 组装主 Agent:把内核各面(IO/记忆/文档/知识/媒体/社交/文本/插件/状态)接进 AgentConfig。
//
// 本函数体是 main() 里对应启动阶段的整块平移:语句、日志文本、错误语义不变,
// 只把「*dataDir」变成参数、把 defer 变成由调用点注册的 cleanup。
func newMainAgent(cfg *types.Config, cfgReg *internalConfig.ConfigRegistry, provider agentAPI.Provider,
providerMgr *agentAPI.ProviderManager, iom *agentIO.IOManager, memDB *memory.GraphDB,
memIdx *memory.Indexer, trk *tracker.Tracker, docStore *document.Store, ks *knowledge.Store,
socialStore *social.SocialStore, textMem *text.Memory, mediaStore *media.Store,
personality *agentPkg.Personality, pluginReg *plugin.Registry, embedder *memory.StaticEmbedder,
multimodalSpace vector.MultimodalEmbedder, mmProviderName, mmErr string,
stageHost *agentCore.StageHost, evBus *events.Bus) *agentCore.Agent {
sysPrompt := cfgReg.GetString("core.agent.system_prompt", defaultSystemPrompt)
if sysPrompt == "" {
sysPrompt = defaultSystemPrompt
}
// D4:把"设备是否已授权"的判据注入插件侧(toolImpl.CanUse 用)。
// ⚠️ 必须放在 agent 构造**之后**——判据要用 agent 的 allowedOutputs,
// 而 registry 早于 agent 构造(故这里传的是晚绑定闭包)。
// 未注入时 ToolAPI 路径对设备放行:那是"授权可被绕过"的既成缺口。
// 注入后,cli 的 /terminal、seq 序列等一切走 ToolAPI 的调用都受同一道闸。
agent := agentCore.New(agentCore.AgentConfig{
ID: "main",
SystemPrompt: sysPrompt,
Provider: provider,
ProviderManager: providerMgr,
IO: iom,
Memory: memDB,
Indexer: memIdx,
Tracker: trk,
DocStore: docStore,
Knowledge: ks,
SocialStore: socialStore,
TextMemory: textMem,
MediaStore: mediaStore,
Personality: personality,
// 人格落库面:首启门禁(任何通道都问一次)与 persona_set 工具用。
// 与 WebUI 向导共用 internal/config 的同一份落库逻辑。
PersonaStore: internalConfig.RegistryPersonaStore{Reg: cfgReg},
PluginReg: pluginReg,
PluginDir: cfg.Plugin.Dir,
// DataDir:驻留子的 temp 图库锚点(<data>/residents/<id>/graph.db)。
// 漏接时的现象是"工具存在、可调用、但创建必失败"——只有真实二进制才看得出来。
DataDir: cfg.Daemon.DataDir,
DistillInterval: cfgReg.GetDuration("core.agent.distill_interval", 30*time.Minute),
ArchiveInterval: cfgReg.GetDuration("core.agent.archive_interval", 60*time.Minute),
ReviewInterval: cfgReg.GetDuration("core.agent.review_interval", 120*time.Minute),
MergeInterval: cfgReg.GetDuration("core.agent.merge_interval", 120*time.Minute),
MaxToolTurns: cfgReg.GetInt("core.agent.max_tool_turns", 10),
Offload: agentCore.OffloadOptions{
Enabled: cfgReg.GetBool("core.agent.offload_enabled", false),
BusyAfter: cfgReg.GetDuration("core.agent.offload_busy_after", 5*time.Minute),
MinPending: cfgReg.GetInt("core.agent.offload_min_pending", 3),
MaxResidents: cfgReg.GetInt("core.agent.offload_max_residents", 2),
},
ContextSavePath: filepath.Join(cfg.Daemon.DataDir, "memory", "context.json"),
EmbeddingModelPath: cfgReg.GetString("core.agent.embedding_model_path", ""),
Embedder: embedder,
MultimodalSpace: multimodalSpace,
EmbeddingProvider: mmProviderName,
EmbeddingError: mmErr,
StageHost: stageHost,
EventBus: evBus,
ThinkingEnabled: cfg.LLM.ThinkingEnabled,
InputProcessing: cfg.InputProcessing,
})
// D4:把「设备是否已授权」的判据注入插件侧(toolImpl.CanUse 消费它)。
//
// 为什么必须在这里:判据要用 agent 自己的 allowedOutputs,而
// pluginReg 早于 agent 构造(newStageAndRegistry 在 main() 里先跑),
// 所以 registry 存的是**晚绑定**闭包,注入点必须在 agent 建好之后。
//
// 不注入的后果(已实测的真实缺口):设备授权闸只存在于
// core.executeToolCallInner,即「agent 收到模型 tool_call」那条路径;
// 而 ToolAPI.ExecuteTool 是**另一条**独立入口,不经那道闸 ⇒
// 凡是走 ToolAPI 的调用都能绕过 AllowedOutputs。实测范围不止序列:
// cli 的 /terminal 就直接经 ToolAPI 调 agentcli 的终端工具。
pluginReg.SetDeviceAuthQuery(func(deviceID string) bool {
return agent.IsOutputAllowed("device/" + deviceID)
})
// 方案 B:把 agent 的**内置工具面**注入 ToolAPI。
//
// 缺口背景:`memory_*` / `knowledge_*` / `doc_*` / `person_*` 这 20+ 个
// 在 executeToolCallInner 里按前缀分派,从不进 ToolAPI ⇒ 插件经 ToolAPI
// 既查不到也调不了。真机实跑实证:seq_run 报「工具 knowledge_list
// 不存在或未注册」,而同一轮模型直接调它是成功的。
//
// 注入必须在此处(agent 构造之后):内置工具的可见性由运行期状态门控
// (memory/knowledge 是否就绪),而 provider 持有的是 agent。
agent.InstallBuiltinToolProvider()
return agent
}
// initONNXParser 初始化依存句法分析器(内嵌 ONNX 模型,失败则退回规则引擎)。
//
// 本函数体是 main() 里对应启动阶段的整块平移:语句、日志文本、错误语义不变,
// 只把「*dataDir」变成参数、把 defer 变成由调用点注册的 cleanup。
func initONNXParser(cfg *types.Config, cfgReg *internalConfig.ConfigRegistry) {
modelPath := cfgReg.GetString("core.agent.onnx_model_path", "")
onnxParser, err := nlp.NewONNXParser(nlp.ONNXConfig{
ModelPath: modelPath,
DataDir: filepath.Join(cfg.Daemon.DataDir, "nlp"),
})
if err != nil {
log.Printf("[homed] warn: ONNX parser init: %v, using fallback", err)
} else {
nlp.SetDefaultParser(onnxParser)
log.Printf("[homed] dep parser initialized (model: %s)", modelPath)
}
}
// loadPlugins 建插件目录、按启动模式决定 allowlist,然后加载全部插件。
//
// 本函数体是 main() 里对应启动阶段的整块平移:语句、日志文本、错误语义不变,
// 只把「*dataDir」变成参数、把 defer 变成由调用点注册的 cleanup。
func loadPlugins(cfg *types.Config, cfgReg *internalConfig.ConfigRegistry, pluginReg *plugin.Registry,
stageHost *agentCore.StageHost, bootMode, dataDir string) {
// Auto-create plugins directory (without hardcoding plugin names)
os.MkdirAll(cfg.Plugin.Dir, 0755)
// failback 受限启动:仅装载 failback 插件集(webfetch/files/cmd 为内核内置,
// 此处仅控制外部插件,默认含 recoverydiag 以便直接在受限态产出恢复结论)
if bootMode == "failback" {
list := cfgReg.GetString("core.agent.failback_plugins", "webui,pluginmgr,recoverydiag")
// 优先使用 guard.yaml 经过 recovery 任务下发的插件集(guard 是 failback 权威)
if task, terr := recovery.LoadTask(recovery.TaskPath(dataDir)); terr == nil && len(task.Plugins()) > 0 {
list = strings.Join(task.Plugins(), ",")
}
var names []string
for _, s := range strings.Split(list, ",") {
if s = strings.TrimSpace(s); s != "" {
names = append(names, s)
}
}
pluginReg.SetLoadAllowlist(names)
log.Printf("[homed] failback boot: plugin allowlist = %v", names)
}
// Load all plugins — each scans its own dir and is loaded via factory or .so
if err := pluginReg.Load(cfg.Plugin.Dir); err != nil {
log.Printf("[homed] warning: load plugins: %v", err)
}
log.Printf("[homed] stage host ready with %d registered tools", stageHost.ToolCount())
}
// startAgentRuntime 接线技能索引、起日志管理、启动 agent,返回逆序关停的 cleanup。
//
// 本函数体是 main() 里对应启动阶段的整块平移:语句、日志文本、错误语义不变,
// 只把「*dataDir」变成参数、把 defer 变成由调用点注册的 cleanup。
func startAgentRuntime(cfgReg *internalConfig.ConfigRegistry, pluginReg *plugin.Registry,
agent *agentCore.Agent, logDir string, ctx context.Context) func() {
// 技能索引接线:skillmgr 插件实现 SkillIndexProvider 时注入 agent(方案B prompt 注入)
if sp := pluginReg.Get("skillmgr"); sp != nil {
if prov, ok := sp.(agentCore.SkillIndexProvider); ok {
agent.SetSkillIndexProvider(prov)
log.Printf("[homed] skill index wired from skillmgr plugin")
}
}
// 日志管理:层级压缩 + 保留策略
logManager := logpkg.NewManager(logDir, cfgReg)
go logManager.Start(ctx)
agent.Start()
return func() {
// 与原 main 的两个 defer 同序(LIFO):先停 agent,再停日志管理。
agent.Stop()
logManager.Stop()
}
}
// startIPCServer 起 PING/ACK 心跳服务(含 kernel 状态快照),返回仅在启动成功后生效的 cleanup。
//
// 本函数体是 main() 里对应启动阶段的整块平移:语句、日志文本、错误语义不变,
// 只把「*dataDir」变成参数、把 defer 变成由调用点注册的 cleanup。
func startIPCServer(dataDir, bootMode string, agent *agentCore.Agent) (*ipc.Server, func()) {
started := false
ipcServer := ipc.NewServer(dataDir, func() *ipc.Status {
st := agent.GetKernelStatus()
llmOK := st != nil && st.LLM.Available
tools := 0
if st != nil {
tools = len(st.Tools)
}
uptime := int64(0)
if st != nil {
if d, err := time.ParseDuration(st.Uptime); err == nil {
uptime = int64(d.Seconds())
}
}
return &ipc.Status{
PID: os.Getpid(),
Boot: bootMode,
UptimeSec: uptime,
LLMOK: &llmOK,
Tools: tools,
LastDiag: lastDiagSummary(dataDir),
}
})
if err := ipcServer.Start(); err != nil {
log.Printf("[homed] warning: ipc heartbeat server: %v", err)
} else {
}
return ipcServer, func() {
if started {
ipcServer.Stop()
}
}
}
// startSupervisorRuntime 把真实存活源与重启通道接到 supervisor 上,返回重启请求通道。
//
// 本函数体是 main() 里对应启动阶段的整块平移:语句、日志文本、错误语义不变,
// 只把「*dataDir」变成参数、把 defer 变成由调用点注册的 cleanup。
func startSupervisorRuntime(sup *supervisor.Daemon, trk *tracker.Tracker, agent *agentCore.Agent) chan struct{} {
sup.SetTracker(trk)
sup.RegisterAgent("main")
// 真实存活源 + 重启通道:daemon 心跳语义由此修正(lastHB 只在确认存活时更新),
// 重启动作不再空转——清理后以特殊退出码交给 guard/systemd 重建。
restartCh := make(chan struct{}, 1)
sup.SetHeartbeatSource(func(id types.AgentID) (time.Time, types.HealthStatus, error) {
st := agent.GetKernelStatus()
if st == nil {
return time.Time{}, types.HealthDown, fmt.Errorf("no kernel status")
}
h := types.HealthHealthy
if !st.LLM.Available {
h = types.HealthDegraded
}
return time.Now(), h, nil
})
sup.SetRestartHandler(func(id types.AgentID) {
select {
case restartCh <- struct{}{}:
default:
}
})
return restartCh
}
// startHeartbeat 每 5s 触碰 <data>/heartbeat(guard 据此判定 worker 存活/卡死),返回停止函数。
//
// 本函数体是 main() 里对应启动阶段的整块平移:语句、日志文本、错误语义不变,
// 只把「*dataDir」变成参数、把 defer 变成由调用点注册的 cleanup。
func startHeartbeat(dataDir string, ctx context.Context) func() {
// 心跳:每 5s 触碰 <data>/heartbeat,guard 据此判定工作进程是否存活/卡死
hbPath := filepath.Join(dataDir, "heartbeat")
hbStop := make(chan struct{})
go func() {
t := time.NewTicker(5 * time.Second)
defer t.Stop()
writeHB := func() {
if f, err := os.OpenFile(hbPath, os.O_CREATE|os.O_WRONLY|os.O_APPEND, 0644); err == nil {
fmt.Fprintf(f, "t=%d\n", time.Now().Unix())
f.Close()
}
}
writeHB()
for {
select {
case <-t.C:
writeHB()
case <-hbStop:
return
case <-ctx.Done():
return
}
}
}()
return func() { close(hbStop) }
}
// waitForShutdown 阻塞至 SIGINT/SIGTERM 或 supervisor 请求重启,然后按原 main 的顺序清理,需要重建时以退出码交回 guard。
//
// 本函数体是 main() 里对应启动阶段的整块平移:语句、日志文本、错误语义不变,
// 只把「*dataDir」变成参数、把 defer 变成由调用点注册的 cleanup。
func waitForShutdown(ctx context.Context, dataDir string, restartCh chan struct{}, stopHeartbeat func(),
pluginReg *plugin.Registry, trk *tracker.Tracker, cfgReg *internalConfig.ConfigRegistry, sup *supervisor.Daemon) {
sigCh := make(chan os.Signal, 1)
signal.Notify(sigCh, syscall.SIGINT, syscall.SIGTERM)
restartRequested := false
select {
case <-sigCh:
log.Printf("[homed] shutting down...")
case <-restartCh:
restartRequested = true
log.Printf("[homed] restart requested, shutting down cleanly then exiting with code %d", exitRestartRequested)
}
stopHeartbeat()
pluginReg.StopAll()
if trk != nil {
trk.Stop()
}
if err := cfgReg.Flush(); err != nil {
log.Printf("[homed] flush config: %v", err)
}
sup.Shutdown()
log.Printf("[homed] stopped")
if restartRequested {
os.Exit(exitRestartRequested)
}
}
// initLuaVM 起 Lua VM(LLM 协议适配);启动失败只告警,cleanup 为 no-op。
func initLuaVM(cfg *types.Config) (*luapkg.VM, func()) {
luaVM := luapkg.NewVM(filepath.Join(cfg.Daemon.DataDir, "adapters"))
if err := luaVM.Start(); err != nil {
log.Printf("[homed] warning: lua vm init failed: %v", err)
return luaVM, func() {}
}
return luaVM, luaVM.Stop
}
// initSupervisor 起守护管理(代理生命周期管理);起不来是致命错误。
func initSupervisor(cfg *types.Config) *supervisor.Daemon {
sup := supervisor.New(cfg)
if err := sup.Start(); err != nil {
log.Fatalf("start supervisor: %v", err)
}
return sup
}
// initTracker 起 overlayfs 变更追踪;无 overlayfs 支持时降级为非致命告警。
func initTracker(cfg *types.Config, agentWorkDir string) *tracker.Tracker {
trk := tracker.NewTracker(cfg.Daemon.DataDir, agentWorkDir,
tracker.WithKeepChangesets(100),
tracker.WithMaxChangesetAge(30*24*time.Hour),
)
if err := trk.Init(); err != nil {
log.Printf("[homed] warning: tracker init: %v", err)
} else {
if err := trk.Start(); err != nil {
log.Printf("[homed] warning: tracker mount overlay: %v (non-fatal: no overlayfs support?)", err)
} else {
log.Printf("[homed] change tracker active at %s", trk.MergeDir())
}
}
return trk
}
// initKernelAPI 建内核与插件之间的两个通道:IOManager(IO 抽象层)+ EventBus(事件总线)。
func initKernelAPI() (*agentIO.IOManager, *events.Bus) {
iom := agentIO.NewIOManager()
evBus := events.NewBus()
log.Printf("[homed] kernel API ready: IOManager + EventBus")
return iom, evBus
}
// initTextMemory 起文本记忆;启动失败只告警,cleanup 为 no-op。
func initTextMemory(cfg *types.Config) (*text.Memory, func()) {
textMem := text.New(filepath.Join(cfg.Daemon.DataDir, "memory", "text"))
if err := textMem.Start(); err != nil {
log.Printf("[homed] warning: text memory start: %v", err)
return textMem, func() {}
}
log.Printf("[homed] text memory active at %s", filepath.Join(cfg.Daemon.DataDir, "memory", "text"))
return textMem, textMem.Stop
}
// resolveBaseAPIKey 解析兜底 API key:配置项 > LLM_API_KEY > DEEPSEEK_API_KEY。
func resolveBaseAPIKey(cfg *types.Config) string {
apiKey := cfg.LLM.APIKey
if apiKey == "" {
apiKey = os.Getenv("LLM_API_KEY")
}
if apiKey == "" {
apiKey = os.Getenv("DEEPSEEK_API_KEY")
}
return apiKey
}
// wirePluginSDK 把内核各面注入每个插件的 PluginSDK(阶段6 将替换遗留的 util.Configure)。
func wirePluginSDK(pluginReg *plugin.Registry, luaVM *luapkg.VM, baseAPIKey string, sup *supervisor.Daemon,
trk *tracker.Tracker, cfg *types.Config, stageHost *agentCore.StageHost, memIdx *memory.Indexer,
agent *agentCore.Agent) {
pluginReg.SetLuaVM(luaVM)
pluginReg.SetBaseAPIKey(baseAPIKey)
pluginReg.SetSupervisor(supervisor.NewSDKAdapter(sup))
pluginReg.SetTracker(trk)
pluginReg.SetConfig(cfg)
pluginReg.SetStageHost(stageHost)
pluginReg.SetIndexer(memIdx)
pluginReg.SetStatusProvider(agent)
pluginReg.SetTerminalAPI(agent)
}
// resolveWebUIOverride 解析 webui 监听地址的覆盖值,空串表示不覆盖。
//
// 优先级:CLI --webui > 核心配置 webui.listen_addr(仅当它被改成非内置默认值)。
// 两者都不给时由 webui 插件自己的 settings["addr"] 决定。
//
// 为什么不写成“内核在插件加载前 Set 插件 settings['addr']”:那时
// config_webui 表还没建(表只在插件注册 def 时创建),PluginSettings.Set 的
// INSERT 会失败而错误被忽略,随后插件 Start 里 RegisterDef 才建表并写入默认
// :8080 —— 于是 CLI --webui 与 webui.listen_addr **一直是死配置**,
// 无论怎么传都监听 :8080。覆盖值改由插件自己接收(webui.SetListenOverride)。
func resolveWebUIOverride(cfgReg *internalConfig.ConfigRegistry, httpAddr string) string {
if strings.TrimSpace(httpAddr) != "" {
return strings.TrimSpace(httpAddr)
}
// webui.listen_addr 的播种默认值就是 ":8080";与默认值相同视为“未配置”,
// 否则会把用户在设置页里改过的插件 addr 顶掉。
if v := strings.TrimSpace(cfgReg.GetString("webui.listen_addr", ":8080")); v != "" && v != ":8080" {
return v
}
return ""
}
// options 是 worker 的命令行参数。
type options struct {
dataDir string
httpAddr string
cliSocket string
role string
boot string
}
// parseFlags 解析命令行参数。
func parseFlags() options {
dataDir := flag.String("data", "", "data directory (default: auto-detect next to binary)")
httpAddr := flag.String("webui", "", "webui listen address (default: webui.listen_addr from config)")
cliSocket := flag.String("socket", "", "cli unix socket path (default: <data>/cli.sock)")
role := flag.String("role", "agent", "process role: guard (父守护) | agent (工作进程)")
boot := flag.String("boot", "normal", "agent boot mode: normal | failback (受限启动,仅 failback 插件集)")
flag.Parse()
return options{dataDir: *dataDir, httpAddr: *httpAddr, cliSocket: *cliSocket, role: *role, boot: *boot}
}
// compactConfigDB 在空闲页够多时压缩配置库;失败只告警(不影响启动)。
//
// 触发条件(见 internal/config.MaybeCompact):空闲页 >= 1MB 且占页数 >= 25%。
// 放在插件加载之后调用——迁移/清理大值发生在插件 Start 里,之前调用没有意义。
func compactConfigDB(cfgReg *internalConfig.ConfigRegistry) {
before := int64(-1)
if st, err := os.Stat(cfgReg.DBPath()); err == nil {
before = st.Size()
}
done, err := cfgReg.MaybeCompact(1<<20, 0.25)
if err != nil {
log.Printf("[homed] warning: 配置库压缩失败: %v", err)
return
}
if !done {
return
}
after := before
if st, err := os.Stat(cfgReg.DBPath()); err == nil {
after = st.Size()
}
log.Printf("[homed] 配置库已压缩: %d -> %d 字节", before, after)
}

View File

@ -0,0 +1,42 @@
package main
import (
"os"
"path/filepath"
"testing"
)
// TestInitMemoryStackKeepsDistillerRunning 锁死启动接线回归:
// initMemoryStack 必须返回一个**仍在运行**的蒸馏器。
//
// 历史 bug:main() 拆分时函数体内残留一句 `defer distiller.Stop()`,
// 函数一 return 就 cancel 掉刚启动的循环,规则蒸馏 10min 心跳从不运行。
// 该缺陷不会让任何单测变红——pipeline 的 TestDistillOnce* 直接调
// distillOnce,绕过了 Start/Stop 接线;只有在这里按「启动阶段函数」的
// 真实调用方式断言,才照得出来。
func TestInitMemoryStackKeepsDistillerRunning(t *testing.T) {
dir := t.TempDir()
// NewGraphDB 需要父目录已存在(生产由 dataDir 初始化保证)。
if err := os.MkdirAll(filepath.Join(dir, "memory"), 0755); err != nil {
t.Fatal(err)
}
st, cleanup := initMemoryStack(dir)
if st == nil || st.distiller == nil {
cleanup()
t.Fatal("initMemoryStack 未返回蒸馏器")
}
if st.db == nil {
cleanup()
t.Skip("图库未初始化,无法验证蒸馏接线")
}
if st.distiller.Stopped() {
cleanup()
t.Fatal("initMemoryStack 返回后蒸馏循环已被停掉(defer Stop 残留?)")
}
// cleanup 是唯一的停机点:先停蒸馏器、再关图库。
cleanup()
if !st.distiller.Stopped() {
t.Fatal("cleanup 之后蒸馏器应已停止")
}
}

View File

@ -2,49 +2,20 @@ package main
import ( import (
"context" "context"
"flag"
"fmt"
"io"
"log" "log"
"os"
"os/signal"
"path/filepath" "path/filepath"
"strings" "strings"
"syscall"
"time"
agentPkg "gitcode.com/JianFeeeee/HomeAgent/internal/agent"
agentAPI "gitcode.com/JianFeeeee/HomeAgent/internal/agent/api"
agentCore "gitcode.com/JianFeeeee/HomeAgent/internal/agent/core"
agentIO "gitcode.com/JianFeeeee/HomeAgent/internal/agent/io"
internalConfig "gitcode.com/JianFeeeee/HomeAgent/internal/config" internalConfig "gitcode.com/JianFeeeee/HomeAgent/internal/config"
"gitcode.com/JianFeeeee/HomeAgent/internal/events"
"gitcode.com/JianFeeeee/HomeAgent/internal/ipc"
"gitcode.com/JianFeeeee/HomeAgent/internal/knowledge"
logpkg "gitcode.com/JianFeeeee/HomeAgent/internal/log"
luapkg "gitcode.com/JianFeeeee/HomeAgent/internal/lua"
"gitcode.com/JianFeeeee/HomeAgent/internal/memory" "gitcode.com/JianFeeeee/HomeAgent/internal/memory"
"gitcode.com/JianFeeeee/HomeAgent/internal/memory/document"
"gitcode.com/JianFeeeee/HomeAgent/internal/memory/media"
"gitcode.com/JianFeeeee/HomeAgent/internal/memory/pipeline"
"gitcode.com/JianFeeeee/HomeAgent/internal/memory/social"
"gitcode.com/JianFeeeee/HomeAgent/internal/memory/text"
"gitcode.com/JianFeeeee/HomeAgent/internal/memory/vector"
"gitcode.com/JianFeeeee/HomeAgent/internal/meta" "gitcode.com/JianFeeeee/HomeAgent/internal/meta"
"gitcode.com/JianFeeeee/HomeAgent/internal/nlp"
"gitcode.com/JianFeeeee/HomeAgent/internal/plugin"
_ "gitcode.com/JianFeeeee/HomeAgent/internal/plugins" _ "gitcode.com/JianFeeeee/HomeAgent/internal/plugins"
_ "gitcode.com/JianFeeeee/HomeAgent/internal/plugins/clawhubadapter" _ "gitcode.com/JianFeeeee/HomeAgent/internal/plugins/clawhubadapter"
cli "gitcode.com/JianFeeeee/HomeAgent/internal/plugins/cli" cli "gitcode.com/JianFeeeee/HomeAgent/internal/plugins/cli"
_ "gitcode.com/JianFeeeee/HomeAgent/internal/plugins/healthcheck" _ "gitcode.com/JianFeeeee/HomeAgent/internal/plugins/healthcheck"
_ "gitcode.com/JianFeeeee/HomeAgent/internal/plugins/kbtree"
_ "gitcode.com/JianFeeeee/HomeAgent/internal/plugins/pluginmgr" _ "gitcode.com/JianFeeeee/HomeAgent/internal/plugins/pluginmgr"
_ "gitcode.com/JianFeeeee/HomeAgent/internal/plugins/webui" webui "gitcode.com/JianFeeeee/HomeAgent/internal/plugins/webui"
"gitcode.com/JianFeeeee/HomeAgent/internal/recovery"
sdk "gitcode.com/JianFeeeee/HomeAgent/internal/sdk"
"gitcode.com/JianFeeeee/HomeAgent/internal/supervisor"
"gitcode.com/JianFeeeee/HomeAgent/internal/tracker"
"gitcode.com/JianFeeeee/HomeAgent/pkg/embedding"
"gitcode.com/JianFeeeee/HomeAgent/pkg/types"
// 空白导入内置 provider:它们各自在 init 里注册到 pkg/embedding。 // 空白导入内置 provider:它们各自在 init 里注册到 pkg/embedding。
// 想把核心换成自己的模型,只需替换这一行(或另建一个发行版 main)。 // 想把核心换成自己的模型,只需替换这一行(或另建一个发行版 main)。
@ -52,699 +23,167 @@ import (
_ "gitcode.com/JianFeeeee/HomeAgent/providers/qwen3vl" _ "gitcode.com/JianFeeeee/HomeAgent/providers/qwen3vl"
) )
// main 是 worker 进程的启动序列。
//
// 形状约定:本函数只保留「顺序编排 + 就地交接」——
// - 每个阶段一行调用,参数即该阶段的全部依赖(依赖顺序即调用顺序);
// - 阶段实现体在同包 bootstrap.go,与这里的调用一一对应;
// - 需要逆序释放的资源由阶段函数返回 cleanup,在**原位** defer 注册,
// 因此释放顺序与拆分前完全一致。
func main() { func main() {
// 平台门放在最前面:比 flag 解析还早,因为原生 Windows 上根本不应进入任何 // 平台门放在最前面:比 flag 解析还早,因为原生 Windows 上根本不应进入任何
// 初始化路径(会去建共享段、拉插件进程)。理由与 WSL 指引见 // 初始化路径(会去建共享段、拉插件进程)。理由与 WSL 指引见
// platform_windows.go。 // platform_windows.go。
requireSupportedPlatform() requireSupportedPlatform()
dataDir := flag.String("data", "", "data directory (default: auto-detect next to binary)") opt := parseFlags()
httpAddr := flag.String("webui", "", "webui listen address (default: webui.listen_addr from config)")
cliSocket := flag.String("socket", "", "cli unix socket path (default: <data>/cli.sock)")
role := flag.String("role", "agent", "process role: guard (父守护) | agent (工作进程)")
boot := flag.String("boot", "normal", "agent boot mode: normal | failback (受限启动,仅 failback 插件集)")
flag.Parse()
// 父守护模式:只负责拉起/守护 worker,不初始化 agent 内核 // 父守护模式:只负责拉起/守护 worker,不初始化 agent 内核
if *role == "guard" { if opt.role == "guard" {
runGuard(resolveDataDir(*dataDir)) runGuard(resolveDataDir(opt.dataDir))
return return
} }
log.Printf("[homed] role=agent boot=%s", *boot) log.Printf("[homed] role=agent boot=%s", opt.boot)
if *dataDir == "" { if opt.dataDir == "" {
*dataDir = resolveDataDir(*dataDir) opt.dataDir = resolveDataDir(opt.dataDir)
} }
if *cliSocket == "" { if opt.cliSocket == "" {
*cliSocket = filepath.Join(*dataDir, "cli.sock") opt.cliSocket = filepath.Join(opt.dataDir, "cli.sock")
} }
log.SetFlags(log.Ldate | log.Ltime | log.Lshortfile) logDir := setupLogging(opt.dataDir)
// 文件日志:同时输出到控制台和 data/log/ 目录
logDir := filepath.Join(*dataDir, "log")
if err := os.MkdirAll(logDir, 0755); err != nil {
log.Printf("[homed] warning: cannot create log dir: %v", err)
} else {
logPath := filepath.Join(logDir, fmt.Sprintf("homed_%s.log", time.Now().Format("2006-01-02_15-04-05")))
logFile, err := os.OpenFile(logPath, os.O_CREATE|os.O_WRONLY|os.O_APPEND, 0644)
if err != nil {
log.Printf("[homed] warning: cannot open log file: %v", err)
} else {
log.SetOutput(io.MultiWriter(os.Stderr, logFile))
log.Printf("[homed] logging to %s", logPath)
}
}
log.Printf("[homed] starting %s", meta.FullVersion()) log.Printf("[homed] starting %s", meta.FullVersion())
agentWorkDir := filepath.Join(*dataDir, "agentfs") agentWorkDir := ensureDataDirs(opt.dataDir)
dirs := []string{
*dataDir,
filepath.Join(*dataDir, "snapshots"),
filepath.Join(*dataDir, "plugins"),
filepath.Join(*dataDir, "changesets"),
filepath.Join(*dataDir, "memory"),
filepath.Join(*dataDir, "memory", "raw"),
filepath.Join(*dataDir, "adapters"),
agentWorkDir,
}
for _, d := range dirs {
if err := os.MkdirAll(d, 0755); err != nil {
log.Fatalf("create dir %s: %v", d, err)
}
}
// ======================================================================== // ---- 基础设施层:记忆、技能 ----
// 基础设施层:记忆、技能
// ========================================================================
memDB, err := memory.NewGraphDB(filepath.Join(*dataDir, "memory", "graph.db")) mem, closeMem := initMemoryStack(opt.dataDir)
if err != nil { defer closeMem()
log.Printf("[homed] warning: memory init failed: %v", err)
memDB = nil
} else {
log.Printf("[homed] graph memory initialized")
}
if memDB != nil {
defer memDB.Close()
}
memIdx := memory.NewIndexer(memDB) // ---- 配置中心(SQLite 持久化,唯一配置源) ----
memIdx.Sync() // 启动时立即同步,避免前30分钟空窗
socialStore := social.New(memDB)
distiller := pipeline.NewDistiller(memDB, *dataDir, pipeline.DistillerConfig{ cfgReg := internalConfig.NewConfigRegistry(filepath.Join(opt.dataDir, "config.db"))
Interval: 10 * time.Minute,
RetentionDays: 7,
BatchSize: 50,
})
if memDB != nil {
distiller.Start()
defer distiller.Stop()
}
// ========================================================================
// 配置中心(SQLite 持久化,唯一配置源)
// ========================================================================
cfgReg := internalConfig.NewConfigRegistry(filepath.Join(*dataDir, "config.db"))
defer cfgReg.Close() defer cfgReg.Close()
cfgReg.SeedDefaults(*dataDir) cfgReg.SeedDefaults(opt.dataDir)
// LLM 配置写前留档(config_set 写 core.llm.* 前自动快照),guard 恢复用基线 // LLM 配置写前留档(config_set 写 core.llm.* 前自动快照),guard 恢复用基线
cfgReg.SetLLMSnapshotFile(filepath.Join(*dataDir, "llm_snapshot.json")) cfgReg.SetLLMSnapshotFile(filepath.Join(opt.dataDir, "llm_snapshot.json"))
cfg := cfgReg.ToConfig() cfg := cfgReg.ToConfig()
// 共享词嵌入:蒸馏提取(Phase 3 TransE 验证)与 Agent 上下文复用同一实例, // 共享词嵌入:蒸馏提取(Phase 3 TransE 验证)与 Agent 上下文复用同一实例,
// 避免同一模型被二次加载(约 200k×300 维 ≈ 数百 MB 内存)。 // 避免同一模型被二次加载(约 200k×300 维 ≈ 数百 MB 内存)。
embedder := memory.NewStaticEmbedder(strings.Split(cfgReg.GetString("core.agent.embedding_model_path", ""), ",")...) embedder := memory.NewStaticEmbedder(strings.Split(cfgReg.GetString("core.agent.embedding_model_path", ""), ",")...)
distiller.SetEmbedder(embedder) mem.distiller.SetEmbedder(embedder)
// ======================================================================== // ---- Lua VM(LLM 协议适配) ----
// Lua VM(LLM 协议适配)
// ========================================================================
luaVM := luapkg.NewVM(filepath.Join(cfg.Daemon.DataDir, "adapters")) luaVM, closeLuaVM := initLuaVM(cfg)
if err := luaVM.Start(); err != nil { defer closeLuaVM()
log.Printf("[homed] warning: lua vm init failed: %v", err)
} else {
defer luaVM.Stop()
}
// ======================================================================== // ---- 守护管理(代理生命周期管理) ----
// 守护管理(代理生命周期管理)
// ========================================================================
sup := supervisor.New(cfg) sup := initSupervisor(cfg)
if err := sup.Start(); err != nil {
log.Fatalf("start supervisor: %v", err)
}
// ======================================================================== // ---- 变更追踪(overlayfs) ----
// 变更追踪(overlayfs)
// ========================================================================
trk := tracker.NewTracker(cfg.Daemon.DataDir, agentWorkDir, trk := initTracker(cfg, agentWorkDir)
tracker.WithKeepChangesets(100),
tracker.WithMaxChangesetAge(30*24*time.Hour),
)
if err := trk.Init(); err != nil {
log.Printf("[homed] warning: tracker init: %v", err)
} else {
if err := trk.Start(); err != nil {
log.Printf("[homed] warning: tracker mount overlay: %v (non-fatal: no overlayfs support?)", err)
} else {
log.Printf("[homed] change tracker active at %s", trk.MergeDir())
}
}
// ======================================================================== // ========================================================================
// 内核 API:IOManager(IO 抽象层) + EventBus(事件总线) // 内核 API:IOManager(IO 抽象层) + EventBus(事件总线)
// 所有插件通过这两个通道与核心交互 // 所有插件通过这两个通道与核心交互
// ======================================================================== // ========================================================================
iom := agentIO.NewIOManager() iom, evBus := initKernelAPI()
evBus := events.NewBus()
log.Printf("[homed] kernel API ready: IOManager + EventBus")
// ======================================================================== // ---- 文本记忆 + 记忆蒸馏管线 ----
// 文本记忆 + 记忆蒸馏管线
// ========================================================================
textMem := text.New(filepath.Join(cfg.Daemon.DataDir, "memory", "text")) textMem, closeTextMem := initTextMemory(cfg)
if err := textMem.Start(); err != nil { defer closeTextMem()
log.Printf("[homed] warning: text memory start: %v", err)
} else {
defer textMem.Stop()
log.Printf("[homed] text memory active at %s", filepath.Join(cfg.Daemon.DataDir, "memory", "text"))
}
ctx, stop := context.WithCancel(context.Background()) ctx, stop := context.WithCancel(context.Background())
defer stop() defer stop()
go func() { startMemoryCandidateConsumer(ctx, iom, textMem, mem.db, mem.distiller)
for {
select {
case <-ctx.Done():
return
case evt, ok := <-iom.OutputChan():
if !ok {
return
}
if evt.Target == "memory" && evt.Type == "memory_candidate" {
source, _ := evt.Payload["source"].(string)
input, _ := evt.Payload["input"].(string)
response, _ := evt.Payload["response"].(string)
toolsUsed, _ := evt.Payload["tools_used"].([]string)
toolResults, _ := evt.Payload["tool_results"].([]interface{})
agentID, _ := evt.Payload["agent_id"].(string)
if input != "" && textMem != nil { // ---- LLM Provider 管理(多源,通过 Lua 适配器协议转换) ----
te := text.Event{
Timestamp: time.Now().Unix(),
Source: source,
Input: input,
Response: response,
ToolsUsed: toolsUsed,
AgentID: agentID,
}
if err := textMem.Append(te); err != nil {
log.Printf("[homed] text memory append: %v", err)
}
}
if input != "" && memDB != nil { baseAPIKey := resolveBaseAPIKey(cfg)
distiller.Append("agent", "user", input)
}
if response != "" && memDB != nil {
distiller.Append("agent", "assistant", response)
}
// 工具输出接入蒸馏管线 providerMgr := initLLMProviders(cfg, luaVM, baseAPIKey)
for _, tr := range toolResults {
if trMap, ok := tr.(map[string]interface{}); ok {
if text, ok := trMap["output"].(string); ok && text != "" && memDB != nil {
distiller.Append("agent", "tool", text)
}
}
}
}
}
}
}()
// ========================================================================
// LLM Provider 管理(多源,通过 Lua 适配器协议转换)
// ========================================================================
apiKey := cfg.LLM.APIKey
if apiKey == "" {
apiKey = os.Getenv("LLM_API_KEY")
}
if apiKey == "" {
apiKey = os.Getenv("DEEPSEEK_API_KEY")
}
baseAPIKey := apiKey
providerMgr := agentAPI.NewProviderManager()
adapterConcurrency := map[string]int{}
for _, src := range cfg.LLM.Sources {
if !agentAPI.IsValidSourceConfig(src.Name, src.BaseURL, src.Model, src.Adapter) {
log.Printf("[homed] skip invalid llm source %q (base_url=%q model=%q adapter=%q)", src.Name, src.BaseURL, src.Model, src.Adapter)
continue
}
key := src.APIKey
if key == "" {
key = baseAPIKey
}
luaProvider := agentAPI.NewLuaAdaptedProvider(agentAPI.BaseConfig{
Model: src.Model,
BaseURL: src.BaseURL,
APIKey: key,
Temperature: cfg.LLM.Temperature,
MaxTokens: cfg.LLM.MaxTokens,
ContextWindow: src.ContextWindow,
MaxConcurrent: src.MaxConcurrent,
Priority: src.Priority,
Vision: src.Vision,
Audio: src.Audio,
}, luaVM, src.Name, src.Adapter)
providerMgr.Register(src.Name, luaProvider)
if src.Adapter != "" {
adapterConcurrency[src.Adapter] += src.MaxConcurrent
}
}
luaVM.ConfigureConcurrency(adapterConcurrency)
if cfg.LLM.Provider != "" {
providerMgr.SetDefault(cfg.LLM.Provider)
}
provider := providerMgr.Default() provider := providerMgr.Default()
// L1 failback:受限 worker 启动即跑恢复梯子(probe→还原DNS/proxy→还原config+ReloadFromConfig→probe), // L1 failback:受限 worker 启动即跑恢复梯子(probe→还原DNS/proxy→还原config+ReloadFromConfig→probe),
// 结果以退出码 exitRecovered=43 / exitRecoveryFailed=44 交回 guard,不进入主 agent 循环。 // 结果以退出码 exitRecovered=43 / exitRecoveryFailed=44 交回 guard,不进入主 agent 循环。
if *boot == "failback" { if opt.boot == "failback" {
runFailbackRecovery(*dataDir, cfgReg, luaVM, providerMgr, baseAPIKey) runFailbackRecovery(opt.dataDir, cfgReg, luaVM, providerMgr, baseAPIKey)
} }
// ======================================================================== // ---- 文档记忆 + 知识库 ----
// 文档记忆 + 知识库
// ========================================================================
docStore := document.NewStore(filepath.Join(cfg.Daemon.DataDir, "memory", "documents"), memory.TokenizeWords) docStore, closeDocStore := initDocStore(cfg)
if err := docStore.Start(); err != nil { defer closeDocStore()
log.Printf("[homed] warning: document store: %v", err)
}
// 关停时落盘。文档记忆的内存态变更(迁移结果、访问计数等)只在 flush
// 里写盘,而 flush 的唯一入口是 Stop()——此前全仓无人调用它,
// 于是迁移结果永不落盘、每次启动白算一遍。
defer docStore.Stop()
// 媒体存储(内容寻址):记忆块的内容后端。 mediaStore, closeMediaStore := initMediaStore(cfgReg, cfg)
// 开关默认开;关闭后全部媒体接线静默跳过,对话行为与本特性上线前一致。 defer closeMediaStore()
var mediaStore *media.Store
if cfgReg.GetBool("core.memory.media.enabled", true) {
mediaDir := cfgReg.GetString("core.memory.media.dir",
filepath.Join(cfg.Daemon.DataDir, "memory", "media"))
ms, err := media.New(mediaDir)
if err != nil {
// 媒体存储开不起来不该阻止启动——它是记忆增强,不是对话必需品
log.Printf("[homed] warning: media store: %v(媒体记忆已禁用)", err)
} else {
mediaStore = ms
defer mediaStore.Close()
st := mediaStore.Stats()
log.Printf("[homed] media store active: %v 条 / %v 字节",
st["count"], st["total_bytes"])
}
}
// 统一多模态向量空间。 multimodalSpace, mmProviderName, mmErr, closeMultimodal := initMultimodalSpace(cfgReg)
// defer closeMultimodal()
// 核心**不**知道任何具体模型:它只按配置里的 provider 名从公共注册表
// (pkg/embedding)打开一个 provider,并把 options.* 原样交给它。模型文件
// 布局、预处理、解码、运行时全部属于 provider 内部实现。
// provider 名为空时禁用多模态向量检索,退回纯 fastText 文本路径。
var multimodalSpace vector.MultimodalEmbedder
// 这两个值只用于状态报告(healthcheck_kernel 的 onnx 段):
// 「配了哪个 provider」与「为什么没启用」,避免只能看到 false 却不知原因。
var mmProviderName, mmErr string
if mmProvider := cfgReg.GetString("core.memory.multimodal_space.provider", ""); mmProvider != "" {
mmProviderName = mmProvider
opts := map[string]string{}
const optPrefix = "core.memory.multimodal_space.options."
for _, key := range cfgReg.List("core.memory.multimodal_space.options.") {
opts[strings.TrimPrefix(key, optPrefix)] = cfgReg.GetString(key, "")
}
provider, err := embedding.Open(mmProvider, embedding.Config{Options: opts})
if err != nil {
mmErr = err.Error()
log.Printf("[homed] warning: 多模态向量 provider %q 打开失败: %v(多模态向量检索已禁用;已注册: %s)",
mmProvider, err, strings.Join(embedding.Names(), ", "))
} else if adapted, err := vector.AdaptProvider(provider); err != nil {
provider.Close()
mmErr = err.Error()
log.Printf("[homed] warning: 多模态向量 provider %q 元数据不合法: %v(多模态向量检索已禁用)", mmProvider, err)
} else {
multimodalSpace = adapted
defer adapted.Close()
info := provider.Info()
// 指纹可能很长(模型文件哈希),日志里只取前 12 个字符便于对照。
shortFP := info.Fingerprint
if len(shortFP) > 12 {
shortFP = shortFP[:12]
}
log.Printf("[homed] multimodal space active: provider=%s dim=%d fp=%s modalities=%v",
mmProvider, info.Dimension, shortFP, info.Modalities)
}
}
ks := knowledge.NewStore(filepath.Join(cfg.Daemon.DataDir, "knowledge")) // 迁移必须在 store 扫盘**之前**:改名后扫盘一次到位,
if err := ks.Start(); err != nil { // 避免先以旧名建索引、再改名造成内存键与盘上目录短暂不一致。
log.Printf("[homed] warning: knowledge store: %v", err) initKnowledgeMigration(cfg)
} else { ks := initKnowledgeStore(cfg)
log.Printf("[homed] knowledge store active with %d items", len(ks.List()))
}
// ======================================================================== // ---- 人格设定 ----
// 人格设定
// ========================================================================
// 人格来源优先级:personal/personal.md(高级覆盖,存在且非空才生效) personality := loadPersonality(cfg, cfgReg)
// > 配置项 core.agent.personal_prompt(默认模板 = config.DefaultPersonaPrompt)。
//
// 曾经只有「文件」一个来源且无人维护,导致人格卡写死旧版本号与已删除的 C ABI、
// 反过来让实例自称旧版本(v1.2.0 压测发现)。故:
// - 配置项化 + 内置默认模板(不含版本号字面量)
// - 文件仍在时生效,但扫到腐坏内容就在启动日志里明确告警
personalPath := filepath.Join(cfg.Daemon.DataDir, "personal", "personal.md")
personality, err := agentPkg.LoadPersonality(personalPath)
if err != nil {
log.Printf("[homed] warning: load personality: %v", err)
}
if personality != nil && personality.Content != "" {
log.Printf("[homed] 人格来源=文件 %s(优先于配置项),%d 字节", personalPath, len(personality.Content))
if hints := agentPkg.PersonaStaleHints(personality.Content); len(hints) > 0 {
log.Printf("[homed] warning: 人格文件含会腐坏的内容 %v — 建议迁到配置项 core.agent.personal_prompt"+
"(默认模板不含版本号,被问版本时以运行时快照为准)", hints)
}
} else if pv := cfgReg.GetString("core.agent.personal_prompt", internalConfig.DefaultPersonaPrompt); strings.TrimSpace(pv) != "" {
personality = &agentPkg.Personality{Content: pv, Path: "(core.agent.personal_prompt)"}
log.Printf("[homed] 人格来源=配置项 core.agent.personal_prompt,%d 字节", len(pv))
} else {
log.Printf("[homed] 人格来源=无(配置项为空且无人格文件)")
}
// ======================================================================== // ---- 阶段管道(StageHost)+ 插件系统(Registry) ----
// 阶段管道(StageHost)+ 插件系统(Registry)
// ========================================================================
stageHost := agentCore.NewStageHost() stageHost, pluginReg := newStageAndRegistry(cfg, cfgReg, iom, evBus, mem.db, textMem,
docStore, mediaStore, ks, providerMgr, opt.dataDir)
pluginReg := plugin.NewRegistry() // ---- Agent Core (需在插件加载前创建,因为插件 Configure 需要 StatusProvider) ----
pluginReg.SetIOManager(iom)
pluginReg.SetEventBus(evBus)
pluginReg.SetMemory(memDB)
pluginReg.SetTextMemory(textMem)
pluginReg.SetDocStore(docStore)
pluginReg.SetMediaStore(mediaStore) // 插件写入的记忆也走媒体链路;nil 时静默降级
pluginReg.SetKnowledge(ks)
pluginReg.SetProviderManager(providerMgr)
pluginReg.SetConfigRegistry(cfgReg)
pluginReg.SetPluginDir(cfg.Plugin.Dir)
pluginReg.SetDataDir(*dataDir) // 插件 SettingsAPI.DataDir() 的数据根目录
// Wire registration callbacks: plugins' RegisterTool/RegisterStage → StageHost agent := newMainAgent(cfg, cfgReg, provider, providerMgr, iom, mem.db, mem.indexer, trk,
pluginReg.SetToolRegistrar(func(name string, def sdk.ToolDef, handler sdk.ToolHandler) error { docStore, ks, mem.social, textMem, mediaStore, personality, pluginReg, embedder,
log.Printf("[homed] SetToolRegistrar registering tool: %s (plugin=%s)", name, def.Plugin) multimodalSpace, mmProviderName, mmErr, stageHost, evBus)
return stageHost.RegisterTool(name, def, handler)
})
pluginReg.SetStageRegistrar(func(stage sdk.Stage, handler sdk.StageHandler) {
stageHost.RegisterStage(stage, handler)
})
pluginReg.SetAPIRegistrar(func(name string) error {
return nil
})
pluginReg.SetToolCleaner(stageHost)
// ======================================================================== wirePluginSDK(pluginReg, luaVM, baseAPIKey, sup, trk, cfg, stageHost, mem.indexer, agent)
// Agent Core (需在插件加载前创建,因为插件 Configure 需要 StatusProvider)
// ========================================================================
defaultPrompt := `你是 HomeAgent,一个持续运行的个人管家。
你的每次回复会自动发送到当前输出通道(默认=输入源),无需额外工具。
如需切换回复通道,使用 output_set_channel。
如需异步发送消息或通知,使用 output_send 指定通道和内容。
使用 output_list_channels 查看可用通道及其能力。
可用工具列表会由系统自动传入,按需使用即可。以下是你尤其需要关注的几类工具:
- memory_* — 图记忆(长期记忆,记录和查询个人信息/事实)
- knowledge_* — 知识库(查阅预设知识文档)
- doc_* — 文档记忆(近期对话的存档,查询后自动清除)
- person_* — 人物特质与社交关系网
- llm_* — LLM 源管理(列出/切换模型提供商)
- output_* — 输出通道管理(切换/发送消息)
- timer_set — 设置定时提醒
- plgreload — 热重载插件
- spawn_child — 生成子 Agent 异步执行独立任务(可传 max_turns 控制工具轮数,默认 5)
并行策略:遇到多个互不依赖的子任务时,优先并行 spawn 多个子 Agent 而非自己串行逐个执行;
长耗时任务(批量处理、多轮搜索汇总)也应交给子 Agent,避免阻塞当前对话。
- describe_image — 描述用户上传的图片
- transcribe_audio — 转写用户上传的音频
- ocr_image — 识别图片中的文字
命令与文件操作策略:
- cmd_run 经完整 shell(bash)执行,支持管道、分号、&&、命令替换、heredoc、重定向。
- 多步交互式程序(vim/top/ssh 会话、需要持续输入的进程)用 terminal_create 创建终端,
terminal_write 发送输入、terminal_read 读输出——不要用 cmd_run 硬等交互程序退出。
- 写文件优先 files_write(原子+留档),生成多行内容时可用 heredoc 或 files_write,
不要用 echo 拼接长文本。
- 读用户发来的文件用 files_read;向 webui 回传图片/文件用 output_send__webui(type=image/file)。
当用户上传图片或音频时,系统会自动附着媒体内容。如果模型不支持直接处理多媒体,请使用上述工具。
回复你的真实想法,用自然语言与用户交流。不要在回复中使用 emoji 表情。`
sysPrompt := cfgReg.GetString("core.agent.system_prompt", defaultPrompt)
if sysPrompt == "" {
sysPrompt = defaultPrompt
}
agent := agentCore.New(agentCore.AgentConfig{
ID: "main",
SystemPrompt: sysPrompt,
Provider: provider,
ProviderManager: providerMgr,
IO: iom,
Memory: memDB,
Indexer: memIdx,
Tracker: trk,
DocStore: docStore,
Knowledge: ks,
SocialStore: socialStore,
TextMemory: textMem,
MediaStore: mediaStore,
Personality: personality,
// 人格落库面:首启门禁(任何通道都问一次)与 persona_set 工具用。
// 与 WebUI 向导共用 internal/config 的同一份落库逻辑。
PersonaStore: internalConfig.RegistryPersonaStore{Reg: cfgReg},
PluginReg: pluginReg,
PluginDir: cfg.Plugin.Dir,
// DataDir:驻留子的 temp 图库锚点(<data>/residents/<id>/graph.db)。
// 漏接时的现象是"工具存在、可调用、但创建必失败"——只有真实二进制才看得出来。
DataDir: cfg.Daemon.DataDir,
DistillInterval: cfgReg.GetDuration("core.agent.distill_interval", 30*time.Minute),
ArchiveInterval: cfgReg.GetDuration("core.agent.archive_interval", 60*time.Minute),
ReviewInterval: cfgReg.GetDuration("core.agent.review_interval", 120*time.Minute),
MergeInterval: cfgReg.GetDuration("core.agent.merge_interval", 120*time.Minute),
MaxToolTurns: cfgReg.GetInt("core.agent.max_tool_turns", 10),
ContextSavePath: filepath.Join(cfg.Daemon.DataDir, "memory", "context.json"),
EmbeddingModelPath: cfgReg.GetString("core.agent.embedding_model_path", ""),
Embedder: embedder,
MultimodalSpace: multimodalSpace,
EmbeddingProvider: mmProviderName,
EmbeddingError: mmErr,
StageHost: stageHost,
EventBus: evBus,
ThinkingEnabled: cfg.LLM.ThinkingEnabled,
InputProcessing: cfg.InputProcessing,
})
// 通过 Registry 将内核依赖注入每个插件的 PluginSDK(阶段6 将替换遗留的 util.Configure)
pluginReg.SetLuaVM(luaVM)
pluginReg.SetBaseAPIKey(baseAPIKey)
pluginReg.SetSupervisor(supervisor.NewSDKAdapter(sup))
pluginReg.SetTracker(trk)
pluginReg.SetConfig(cfg)
pluginReg.SetStageHost(stageHost)
pluginReg.SetIndexer(memIdx)
pluginReg.SetStatusProvider(agent)
// 为内置插件注入内核依赖(各插件通过 init() 自注册工厂) // 为内置插件注入内核依赖(各插件通过 init() 自注册工厂)
cli.DefaultSocket = *cliSocket cli.DefaultSocket = opt.cliSocket
// webui 插件作为内置插件经 Registry 启动,读取自身 settings["addr"](默认 :8080)。 // webui 监听地址覆盖:必须在 loadPlugins 之前设置,插件 Start 时会读它。
// 保留 CLI --webui 与 webui.listen_addr 配置对监听地址的覆盖。 webui.SetListenOverride(resolveWebUIOverride(cfgReg, opt.httpAddr))
webuiListenAddr := *httpAddr
if webuiListenAddr == "" {
webuiListenAddr = cfgReg.GetString("webui.listen_addr", ":8080")
}
if ps := cfgReg.PluginConfig("webui"); ps != nil {
if v, _ := ps.Get("addr"); v == nil {
_ = ps.Set("addr", webuiListenAddr)
}
}
// ======================================================================== // ---- 依存句法分析器(内嵌 ONNX 模型 / 规则引擎) ----
// 依存句法分析器(内嵌 ONNX 模型 / 规则引擎)
// ========================================================================
modelPath := cfgReg.GetString("core.agent.onnx_model_path", "") initONNXParser(cfg, cfgReg)
onnxParser, err := nlp.NewONNXParser(nlp.ONNXConfig{
ModelPath: modelPath,
DataDir: filepath.Join(cfg.Daemon.DataDir, "nlp"),
})
if err != nil {
log.Printf("[homed] warn: ONNX parser init: %v, using fallback", err)
} else {
nlp.SetDefaultParser(onnxParser)
log.Printf("[homed] dep parser initialized (model: %s)", modelPath)
}
// Auto-create plugins directory (without hardcoding plugin names) loadPlugins(cfg, cfgReg, pluginReg, stageHost, opt.boot, opt.dataDir)
os.MkdirAll(cfg.Plugin.Dir, 0755)
// failback 受限启动:仅装载 failback 插件集(webfetch/files/cmd 为内核内置, // 插件加载完成后再回收空闲页:大值(如老版聊天记录)可能在这一步被搬走/删除,
// 此处仅控制外部插件,默认含 recoverydiag 以便直接在受限态产出恢复结论) // 而 SQLite 的 DELETE 不会缩小文件。
if *boot == "failback" { compactConfigDB(cfgReg)
list := cfgReg.GetString("core.agent.failback_plugins", "webui,pluginmgr,recoverydiag")
// 优先使用 guard.yaml 经过 recovery 任务下发的插件集(guard 是 failback 权威)
if task, terr := recovery.LoadTask(recovery.TaskPath(*dataDir)); terr == nil && len(task.Plugins()) > 0 {
list = strings.Join(task.Plugins(), ",")
}
var names []string
for _, s := range strings.Split(list, ",") {
if s = strings.TrimSpace(s); s != "" {
names = append(names, s)
}
}
pluginReg.SetLoadAllowlist(names)
log.Printf("[homed] failback boot: plugin allowlist = %v", names)
}
// Load all plugins — each scans its own dir and is loaded via factory or .so stopRuntime := startAgentRuntime(cfgReg, pluginReg, agent, logDir, ctx)
if err := pluginReg.Load(cfg.Plugin.Dir); err != nil { defer stopRuntime()
log.Printf("[homed] warning: load plugins: %v", err)
}
log.Printf("[homed] stage host ready with %d registered tools", stageHost.ToolCount())
// 技能索引接线:skillmgr 插件实现 SkillIndexProvider 时注入 agent(方案B prompt 注入) _, closeIPC := startIPCServer(opt.dataDir, opt.boot, agent)
if sp := pluginReg.Get("skillmgr"); sp != nil { defer closeIPC()
if prov, ok := sp.(agentCore.SkillIndexProvider); ok {
agent.SetSkillIndexProvider(prov)
log.Printf("[homed] skill index wired from skillmgr plugin")
}
}
// 日志管理:层级压缩 + 保留策略 restartCh := startSupervisorRuntime(sup, trk, agent)
logManager := logpkg.NewManager(logDir, cfgReg)
go logManager.Start(ctx)
defer logManager.Stop()
agent.Start()
defer agent.Stop()
// PING/ACK 心跳服务:worker 监听 unix socket,guard 发 PING、worker 回 ACK
// (含自诊断 kernel 状态快照),替换纯文件心跳。文件心跳保留作回退。
ipcServer := ipc.NewServer(*dataDir, func() *ipc.Status {
st := agent.GetKernelStatus()
llmOK := st != nil && st.LLM.Available
tools := 0
if st != nil {
tools = len(st.Tools)
}
uptime := int64(0)
if st != nil {
if d, err := time.ParseDuration(st.Uptime); err == nil {
uptime = int64(d.Seconds())
}
}
return &ipc.Status{
PID: os.Getpid(),
Boot: *boot,
UptimeSec: uptime,
LLMOK: &llmOK,
Tools: tools,
LastDiag: lastDiagSummary(*dataDir),
}
})
if err := ipcServer.Start(); err != nil {
log.Printf("[homed] warning: ipc heartbeat server: %v", err)
} else {
defer ipcServer.Stop()
}
sup.SetTracker(trk)
sup.RegisterAgent("main")
// 真实存活源 + 重启通道:daemon 心跳语义由此修正(lastHB 只在确认存活时更新),
// 重启动作不再空转——清理后以特殊退出码交给 guard/systemd 重建。
restartCh := make(chan struct{}, 1)
sup.SetHeartbeatSource(func(id types.AgentID) (time.Time, types.HealthStatus, error) {
st := agent.GetKernelStatus()
if st == nil {
return time.Time{}, types.HealthDown, fmt.Errorf("no kernel status")
}
h := types.HealthHealthy
if !st.LLM.Available {
h = types.HealthDegraded
}
return time.Now(), h, nil
})
sup.SetRestartHandler(func(id types.AgentID) {
select {
case restartCh <- struct{}{}:
default:
}
})
log.Printf("[homed] main agent started, model=%s base=%s sources=%d adapters=%d", log.Printf("[homed] main agent started, model=%s base=%s sources=%d adapters=%d",
cfg.LLM.Model, cfg.LLM.BaseURL, len(cfg.LLM.Sources), len(luaVM.ListAdapters())) cfg.LLM.Model, cfg.LLM.BaseURL, len(cfg.LLM.Sources), len(luaVM.ListAdapters()))
log.Printf("[homed] kernel ready, waiting for plugin IO...") log.Printf("[homed] kernel ready, waiting for plugin IO...")
// ======================================================================== // ---- 等待退出信号 ----
// 等待退出信号
// ========================================================================
sigCh := make(chan os.Signal, 1) stopHeartbeat := startHeartbeat(opt.dataDir, ctx)
signal.Notify(sigCh, syscall.SIGINT, syscall.SIGTERM) waitForShutdown(ctx, opt.dataDir, restartCh, stopHeartbeat, pluginReg, trk, cfgReg, sup)
// 心跳:每 5s 触碰 <data>/heartbeat,guard 据此判定工作进程是否存活/卡死
hbPath := filepath.Join(*dataDir, "heartbeat")
hbStop := make(chan struct{})
go func() {
t := time.NewTicker(5 * time.Second)
defer t.Stop()
writeHB := func() {
if f, err := os.OpenFile(hbPath, os.O_CREATE|os.O_WRONLY|os.O_APPEND, 0644); err == nil {
fmt.Fprintf(f, "t=%d\n", time.Now().Unix())
f.Close()
}
}
writeHB()
for {
select {
case <-t.C:
writeHB()
case <-hbStop:
return
case <-ctx.Done():
return
}
}
}()
restartRequested := false
select {
case <-sigCh:
log.Printf("[homed] shutting down...")
case <-restartCh:
restartRequested = true
log.Printf("[homed] restart requested, shutting down cleanly then exiting with code %d", exitRestartRequested)
}
close(hbStop)
pluginReg.StopAll()
if trk != nil {
trk.Stop()
}
if err := cfgReg.Flush(); err != nil {
log.Printf("[homed] flush config: %v", err)
}
sup.Shutdown()
log.Printf("[homed] stopped")
if restartRequested {
os.Exit(exitRestartRequested)
}
} }

123
cmd/memgc/main.go Normal file
View File

@ -0,0 +1,123 @@
// memgc 清理图记忆里已存在的「噪音实体」「孤立实体」及其关系。
//
// 为什么需要这个命令:噪音闸门(internal/memory.IsNoiseEntity)只能拦住
// **新写入**的噪音。旧库里那批(常用词 / 归档内部标记 / 模板摘要回声)是
// 闸门上线前攒下的存量,没人清就一直在——热实体被它们占着,召回预算被
// 同构垃圾边挤满。清理是一次性动作,但需要可重复执行、可先看不做。
//
// 两件事分开开关:-orphans 处理的是「零关系的空节点」(清理噪音后另一端
// 留下的壳),它们的名字本身可能没问题,但已经不在图里了。
//
// 用法(默认 dry-run,只列不删):
//
// memgc -db /home/newqqagent/memory/graph.db
// memgc -db /home/newqqagent/memory/graph.db -orphans -apply
//
// 清理生产库前请先备份:sqlite3 graph.db ".backup 'graph.db.bak-<ts>'"
// 不要用 cp —— WAL 模式下会复制出主库与 -wal 不一致的快照。
package main
import (
"flag"
"fmt"
"log"
"gitcode.com/JianFeeeee/HomeAgent/internal/memory"
)
func main() {
path := flag.String("db", "", "graph.db 路径(必填)")
apply := flag.Bool("apply", false, "真正删除;不加则只 dry-run 打印")
orphans := flag.Bool("orphans", false, "同时处理「零关系孤立实体」(先被清理的噪音在另一端留下的空节点)")
tagScene := flag.String("tag-scene", "", "存量引导:把实体名匹配 -entity-glob 的活跃关系标进该场景键(如 chan:qq)")
entityGlob := flag.String("entity-glob", "", "配合 -tag-scene 的 GLOB 模式(如 *QQ*)。GLOB 区分大小写,避免把 /home/newqqagent 这类路径卷进场景")
sceneStats := flag.Bool("scene-stats", false, "只打印场景规模摘要")
flag.Parse()
if *path == "" {
flag.Usage()
log.Fatal("memgc: 必须指定 -db")
}
g, err := memory.NewGraphDB(*path)
if err != nil {
log.Fatalf("memgc: open %s: %v", *path, err)
}
defer g.Close()
if *sceneStats {
stats, err := g.SceneStats()
if err != nil {
log.Fatalf("memgc: scene stats: %v", err)
}
fmt.Printf("场景 %d 个:\n", len(stats))
for _, st := range stats {
fmt.Printf(" [%-9s] %-40s refs=%-5d rel=%-5d ent=%-4d strength=%-4d features=%-3d updated=%s\n",
st.Origin, st.Key, st.Refs, st.Relations, st.Entities, st.Strength, st.Features,
st.UpdatedAt.Format("2006-01-02 15:04"))
}
return
}
// 存量引导:场景是后引入的维度,老库里的规则(那批 QQ 规则就是典型)
// 没有任何场景引用,不补挂就永远吃不到场景召回。
if *tagScene != "" {
if *entityGlob == "" {
log.Fatal("memgc: -tag-scene 需要配套 -entity-glob(如 '*QQ*');不做自动猜测")
}
n, err := g.TagSceneByEntityGlob(*tagScene, *entityGlob, !*apply)
if err != nil {
log.Fatalf("memgc: tag scene: %v", err)
}
if *apply {
fmt.Printf("[APPLIED] 已把 %d 条关系标进场景 %q\n", n, *tagScene)
} else {
fmt.Printf("[DRY-RUN] 将把 %d 条关系标进场景 %q(未写库)\n", n, *tagScene)
}
return
}
junk, err := g.NoiseEntities()
if err != nil {
log.Fatalf("memgc: scan: %v", err)
}
fmt.Printf("噪音实体 %d 个:\n", len(junk))
for _, e := range junk {
fmt.Printf(" %-64s type=%-8s mentions=%d\n", e.Name, e.Type, e.MentionCount)
}
de, dr, err := g.PurgeNoise(!*apply)
if err != nil {
log.Fatalf("memgc: purge: %v", err)
}
if *apply {
fmt.Printf("[APPLIED] 噪音:已删除 实体=%d 关系=%d\n", de, dr)
} else {
fmt.Printf("[DRY-RUN] 噪音:将删除 实体=%d 关系=%d(未写库,加 -apply 才落地)\n", de, dr)
}
if *orphans {
list, err := g.OrphanEntities()
if err != nil {
log.Fatalf("memgc: orphans: %v", err)
}
fmt.Printf("孤立实体(零关系)%d 个:\n", len(list))
for _, e := range list {
fmt.Printf(" %-64s type=%-8s mentions=%d\n", e.Name, e.Type, e.MentionCount)
}
n, err := g.PurgeOrphans(!*apply)
if err != nil {
log.Fatalf("memgc: purge orphans: %v", err)
}
if *apply {
fmt.Printf("[APPLIED] 孤立实体:已删除 %d 个\n", n)
} else {
fmt.Printf("[DRY-RUN] 孤立实体:将删除 %d 个\n", n)
}
}
if *apply {
fmt.Println("提示:运行中的进程会在下一个 archive 心跳(Indexer.Sync)重建实体名向量索引,无需重启。")
}
}

View File

@ -2,8 +2,8 @@
"app": { "app": {
"bundleName": "com.example.homeagent", "bundleName": "com.example.homeagent",
"vendor": "HomeAgent", "vendor": "HomeAgent",
"versionCode": 1001001, "versionCode": 1004000,
"versionName": "1.1.1", "versionName": "1.4.0",
// 分层图标:前景是字形,背景(沉淀色)在 base/ 与 dark/ 各一份,随系统主题切换。 // 分层图标:前景是字形,背景(沉淀色)在 base/ 与 dark/ 各一份,随系统主题切换。
// 直接指向位图会把浅色底烧进图标,深色模式下桌面和启动页都会跳脱。 // 直接指向位图会把浅色底烧进图标,深色模式下桌面和启动页都会跳脱。
"icon": "$media:layered_image", "icon": "$media:layered_image",

View File

@ -0,0 +1,19 @@
import { bundleManager } from '@kit.AbilityKit';
/**
* 应用版本号:从 bundle 元数据读取,而不是在 .ets 里再抄一份。
*
* AppScope/app.json5 是版本的唯一来源(由 deploy/scripts/sync-client-versions.sh
* 与内核 internal/meta.Version 对齐)。在代码里再写一个字面量就是第二份真相,
* 实测已经漂过:app.json5 写 1.1.1、设备桥上又是一份 1.1.1,而内核早已 1.4.0。
* 设备桥上报 / deviceinfo 回显的真实安装包版本,应当来自同一个来源。
*/
export function appVersion(): string {
try {
const info: bundleManager.BundleInfo =
bundleManager.getBundleInfoForSelfSync(bundleManager.BundleFlag.GET_BUNDLE_INFO_DEFAULT);
return info.versionName;
} catch (e) {
return '';
}
}

View File

@ -0,0 +1,37 @@
/**
* 附件的字节获取与解码(网络 / 沙箱 I/O)。
*
* 字节走 GET <base>/files/<name> 或 /uploads/<name>(注意不带 /api/v1 前缀)。
* 这两条路由在后端是 requireWeb,但对 API Key 客户端同等放行,
* 所以带上和普通接口一样的鉴权头即可,无需 web 登录态。
*
* 从 components/Attachment.ets 抽出:缩略图与详情大图都走同一条解码路径。
*/
import { image } from '@kit.ImageKit';
import { fileIo } from '@kit.CoreFileKit';
import { apiClient } from './ApiClient';
/** 下载并解码成 PixelMap;任何一步失败都返回 undefined(调用方显示占位)。 */
export async function loadPixelMap(url: string): Promise<image.PixelMap | undefined> {
try {
// 本地待上传的图片:直接读沙箱文件,不走网络
if (url.startsWith('file://')) {
const path: string = url.substring(7);
const f = fileIo.openSync(path, fileIo.OpenMode.READ_ONLY);
const localSrc: image.ImageSource = image.createImageSource(f.fd);
const localPm: image.PixelMap = await localSrc.createPixelMap();
await localSrc.release();
fileIo.closeSync(f);
return localPm;
}
const abs: string = apiClient.absoluteUrl(url);
const resp = await apiClient.getBinary(abs, 15000);
const src: image.ImageSource = image.createImageSource(resp.data);
const pm: image.PixelMap = await src.createPixelMap();
await src.release();
return pm;
} catch (e) {
return undefined;
}
}

View File

@ -0,0 +1,103 @@
/**
* 附件的解析与格式化(纯函数,无 UI、无平台 I/O)。
*
* 后端 Attachment 只有四个字段:type / url / size / name
* (internal/plugins/webui/handler.go),没有 mime、没有像素尺寸、没有本地路径。
* 所以详情页里的"尺寸/格式"必须由客户端自己解码得出,不能假装后端给了。
*
* 从 components/Attachment.ets 抽出:附件卡与附件详情都要用这几个函数,
* 放在 common 里两边共用,也不必让 UI 文件承担这段纯逻辑。
*/
import { ChatAttachment } from '../model/Model';
/** 从后端 JSON 里解析 attachment 字段;缺字段或类型不对则返回 undefined。 */
export function parseAttachment(raw: Object | undefined): ChatAttachment | undefined {
if (raw === undefined || raw === null) {
return undefined;
}
const o: Record<string, Object> = raw as Record<string, Object>;
const url: string = o['url'] as string ?? '';
if (url.length === 0) {
return undefined;
}
const t: string = o['type'] as string ?? 'file';
const a: ChatAttachment = {
type: t === 'image' ? 'image' : 'file',
url: url,
size: o['size'] as number ?? 0,
name: o['name'] as string ?? fileNameOf(url),
};
return a;
}
/** 由 SSE channel_output 事件构造附件(字段名与 history 不同)。 */
export function attachmentFromChannelOutput(
outputType: string, url: string, size: number): ChatAttachment | undefined {
if (url.length === 0) {
return undefined;
}
if (outputType !== 'image' && outputType !== 'file') {
return undefined;
}
const a: ChatAttachment = {
type: outputType,
url: url,
size: size,
name: fileNameOf(url),
};
return a;
}
/** 取 URL 最后一段作为展示文件名,与后端 handler.go 的取名方式一致。 */
export function fileNameOf(url: string): string {
let s: string = url;
const q: number = s.indexOf('?');
if (q >= 0) {
s = s.substring(0, q);
}
const i: number = s.lastIndexOf('/');
const name: string = i >= 0 ? s.substring(i + 1) : s;
return name.length > 0 ? name : '附件';
}
/** 人类可读字节数,口径对齐后端 formatBytes(KB 以上保留一位小数)。 */
export function formatBytes(n: number): string {
if (n <= 0) {
return '';
}
if (n < 1024) {
return n.toString() + ' B';
}
const kb: number = n / 1024;
if (kb < 1024) {
return oneDecimal(kb) + ' KB';
}
const mb: number = kb / 1024;
if (mb < 1024) {
return oneDecimal(mb) + ' MB';
}
return oneDecimal(mb / 1024) + ' GB';
}
function oneDecimal(v: number): string {
return (Math.round(v * 10) / 10).toString();
}
/** 由文件名后缀猜测类型标签。后端不返回 mime,只能这样标注。 */
export function extLabel(name: string): string {
const i: number = name.lastIndexOf('.');
if (i < 0 || i === name.length - 1) {
return '未知类型';
}
return name.substring(i + 1).toUpperCase();
}
/** 去掉路径分隔符,避免附件名把文件写到 filesDir 之外。 */
export function sanitize(name: string): string {
let s: string = name.replace(/[\/\\:*?"<>|]/g, '_');
if (s.length === 0) {
s = 'attachment';
}
return s;
}

View File

@ -5,6 +5,9 @@ import { deviceInfo } from '@kit.BasicServicesKit';
import { textToSpeech } from '@kit.CoreSpeechKit'; import { textToSpeech } from '@kit.CoreSpeechKit';
import { componentSnapshot } from '@kit.ArkUI'; import { componentSnapshot } from '@kit.ArkUI';
import { abilityAccessCtrl, common, PermissionRequestResult, Permissions } from '@kit.AbilityKit'; import { abilityAccessCtrl, common, PermissionRequestResult, Permissions } from '@kit.AbilityKit';
import { camera, cameraPicker } from '@kit.CameraKit';
import { fileIo, fileUri } from '@kit.CoreFileKit';
import { appVersion } from './AppVersion';
// ===== 能力结果 ===== // ===== 能力结果 =====
@ -17,12 +20,17 @@ export const LOCAL_DEVICE_CAPS: string[] = [
'clipboardsee', 'clipboardsee',
'clipboardsue', 'clipboardsue',
'speakeruse', 'speakeruse',
'camerasue',
]; ];
export interface CapResult { export interface CapResult {
status: string; // 'ok' | 'error' status: string; // 'ok' | 'error'
output: string; output: string;
error: string; error: string;
// chunked 为 true 时表示结果**已由能力内部经二进制分块回传**(如录像),
// DeviceBridge 不要再发 cmd_result;否则网关会把后续分块挂在一条已完成的
// 请求上,或先用 cmd_result 结束、再来的 cmd_data_start 找不到归属。
chunked?: boolean;
} }
interface DeviceStatusPayload { interface DeviceStatusPayload {
@ -71,6 +79,19 @@ function errResult(errMsg: string): CapResult {
return r; return r;
} }
/**
* 二进制分块发送回调。由 BridgeRouter 注入(它持有 deviceBridge + reqId),
* BridgeCaps 因此不必 import DeviceBridge —— 否则 DeviceBridge 为取 CapResult
* 而 import BridgeCaps,两边成环。分层也更干净:能力实现不碰 socket。
*/
export type DataChunkSender = (kind: string, mime: string, bytes: Uint8Array) => void;
// chunkedResult:结果已由能力自己分块发出,不再回 cmd_result。
function chunkedResult(output: string): CapResult {
const r: CapResult = { status: 'ok', output: output, error: '', chunked: true };
return r;
}
// ===== screensee:截取本应用当前画面(前台时为整屏可见内容)===== // ===== screensee:截取本应用当前画面(前台时为整屏可见内容)=====
const SNAPSHOT_COMPONENT_ID: string = 'homeagent-root'; const SNAPSHOT_COMPONENT_ID: string = 'homeagent-root';
@ -129,6 +150,142 @@ export async function capScreensee(): Promise<CapResult> {
} }
} }
// ===== camerasue:系统相机抓拍 =====
//
// 与桌面/CLI 端的实现路径不同:鸿蒙三方应用不能无界面地直接驱动摄像头
// (CameraKit 需要预览 surface + CAMERA 权限,且后台采集受限),能拿到
// “用户正在拍的这一张”的合规路径是系统相机选择器 cameraPicker —— 由系统
// 相机完成采集,本应用只取回结果文件。语义与桌面端一致:现在给 agent 拍一张。
//
// 结果落在应用沙箱(saveUri 指向 filesDir),不写系统媒体库,也就不需要
// READ_IMAGEVIDEO 这类受限权限。
const CAMERASUE_MAX_B64: number = 950000;
/** 录像回传上限:与网关 mediaDir 落盘模式配合,避免把设备内存/WS 打爆。 */
const CAMERASUE_MAX_VIDEO: number = 64 * 1024 * 1024;
/**
* camerasue 实现。
*
* 参数语义与 homeagent-cmdrun 的说明一致:无参数 = 抓拍单张;
* `<N秒>` = 录 N 秒视频。
*
* 视频为什么要走二进制分块:一段 10s 录像动辄数 MB,base64 后还要再膨胀
* 1/3,既撑爆模型上下文也撑爆 WS 单帧。cameraPicker 本身支持 VIDEO
* 模式(系统相机会直接进录像界面),取回文件后用 sendDataChunked 按
* cmd_data_start/分块/cmd_data_end 回传——网关侧聚合后落盘成文件,agent 拿路径。
* 这与 GUI/CLI 客户端的 camerasue 录像路径一致。
*/
export async function capCamerasue(context: common.UIAbilityContext,
rawArgs: string,
sendChunked: DataChunkSender | null): Promise<CapResult> {
const raw: string = rawArgs.trim();
let videoSeconds: number = 0;
if (raw.length > 0) {
const digits: RegExp = new RegExp('^\\d+$');
if (!digits.test(raw)) {
return errResult('camerasue 参数只接受纯数字秒数,如 camerasue 5');
}
videoSeconds = parseInt(raw, 10);
if (videoSeconds <= 0 || videoSeconds > 300) {
return errResult('录像时长需在 1~300 秒之间');
}
}
const isVideo: boolean = videoSeconds > 0;
const ext: string = isVideo ? '.mp4' : '.jpg';
const filePath: string = context.filesDir + '/camerasue_' + Date.now().toString() + ext;
try {
// cameraPicker 要求 saveUri 指向的文件存在且可写,先建空文件占位
const f: fileIo.File = fileIo.openSync(filePath,
fileIo.OpenMode.READ_WRITE | fileIo.OpenMode.CREATE);
fileIo.closeSync(f);
} catch (e) {
return errResult('无法创建相机输出文件');
}
try {
const profile: cameraPicker.PickerProfile = {
cameraPosition: camera.CameraPosition.CAMERA_POSITION_BACK,
saveUri: fileUri.getUriFromPath(filePath),
};
if (isVideo) {
profile.videoDuration = videoSeconds;
}
const mediaType: cameraPicker.PickerMediaType = isVideo
? cameraPicker.PickerMediaType.VIDEO
: cameraPicker.PickerMediaType.PHOTO;
const res: cameraPicker.PickerResult =
await cameraPicker.pick(context, [mediaType], profile);
if (res.resultCode !== 0 || res.resultUri.length === 0) {
return errResult(isVideo ? '未获取到录像(可能被取消)' : '未获取到照片(可能被取消)');
}
} catch (e) {
return errResult('相机不可用或未授权,请确认应用在前台并允许使用相机');
}
if (isVideo) {
return readAndSendVideo(filePath, sendChunked);
}
return readPhotoAsBase64(filePath);
}
/** 读回录像并以二进制分块回传;网关聚合后落盘,agent 拿文件路径。 */
function readAndSendVideo(filePath: string, sendChunked: DataChunkSender | null): CapResult {
let fd: number = -1;
try {
const stat: fileIo.Stat = fileIo.statSync(filePath);
if (stat.size <= 0) {
return errResult('录像文件为空,请重试');
}
if (stat.size > CAMERASUE_MAX_VIDEO) {
return errResult('录像文件过大(超过 64MB),请缩短时长');
}
const buf: ArrayBuffer = new ArrayBuffer(stat.size);
const rf: fileIo.File = fileIo.openSync(filePath, fileIo.OpenMode.READ_ONLY);
fd = rf.fd;
fileIo.readSync(fd, buf);
fileIo.closeSync(rf);
fd = -1;
if (sendChunked === null) {
return errResult('录像回传通道未就绪,请重试');
}
sendChunked('camera_video', 'video/mp4', new Uint8Array(buf));
// 分块已代表本次请求的完整结果,DeviceBridge 不再回 cmd_result。
return chunkedResult('录像已回传(' + stat.size.toString() + ' 字节)');
} catch (e) {
if (fd >= 0) {
try { fileIo.closeSync(fd); } catch (ignore) {}
}
return errResult('录像读取失败,请重试');
}
}
/** 照片仍走小体积 base64 内联(图片不大,不必分块)。 */
function readPhotoAsBase64(filePath: string): CapResult {
let fd: number = -1;
try {
const stat: fileIo.Stat = fileIo.statSync(filePath);
const buf: ArrayBuffer = new ArrayBuffer(stat.size);
const rf: fileIo.File = fileIo.openSync(filePath, fileIo.OpenMode.READ_ONLY);
fd = rf.fd;
fileIo.readSync(fd, buf);
fileIo.closeSync(rf);
fd = -1;
const helper: util.Base64Helper = new util.Base64Helper();
const b64: string = helper.encodeToStringSync(new Uint8Array(buf));
if (b64.length > CAMERASUE_MAX_B64) {
return errResult('照片数据过大,请降低分辨率后重试');
}
return okResult('data:image/jpeg;base64,' + b64);
} catch (e) {
if (fd >= 0) {
try { fileIo.closeSync(fd); } catch (ignore) {}
}
return errResult('照片读取失败,请重试');
}
}
// ===== clipboardsee / clipboardsue ===== // ===== clipboardsee / clipboardsue =====
const CLIPBOARD_PERMISSIONS: Array<Permissions> = ['ohos.permission.READ_PASTEBOARD']; const CLIPBOARD_PERMISSIONS: Array<Permissions> = ['ohos.permission.READ_PASTEBOARD'];
@ -249,7 +406,7 @@ export function capDeviceInfo(deviceId: string, deviceName: string): CapResult {
platform: 'OpenHarmony', platform: 'OpenHarmony',
arch: deviceInfo.abiList, arch: deviceInfo.abiList,
os_release: deviceInfo.osFullName, os_release: deviceInfo.osFullName,
version: '1.1.1', version: appVersion(),
cpus: 0, cpus: 0,
brand: deviceInfo.brand, brand: deviceInfo.brand,
manufacturer: deviceInfo.manufacture, manufacturer: deviceInfo.manufacture,
@ -269,29 +426,3 @@ export function capDeviceInfo(deviceId: string, deviceName: string): CapResult {
}; };
return okResult(JSON.stringify(payload)); return okResult(JSON.stringify(payload));
} }
// ===== screensue 内容解析 =====
// 服务端协议: screensue [秒] <内容>;0=常驻。
export interface ScreensuePayload {
duration: number; // 秒;0 表示常驻直到用户关闭
content: string;
}
export function parseScreensue(rawArgs: string): ScreensuePayload {
const p: ScreensuePayload = { duration: 5, content: '' };
const leadingSpaces: RegExp = new RegExp('^\\s+');
const firstSpace: RegExp = new RegExp('\\s');
let rest: string = rawArgs.replace(leadingSpaces, '');
const splitAt: number = rest.search(firstSpace);
if (splitAt > 0) {
const first: string = rest.substring(0, splitAt);
const digits: RegExp = new RegExp('^\\d+$');
if (digits.test(first)) {
p.duration = Math.min(parseInt(first, 10), 86400);
rest = rest.substring(splitAt).replace(leadingSpaces, '');
}
}
p.content = rest;
return p;
}

View File

@ -0,0 +1,173 @@
/**
* 设备桥协议:消息结构、帧构造与分块切片。
*
* 与 homed 的 remotedevice 插件对齐(internal/plugins/remotedevice)。
* 从 common/DeviceBridge.ets 抽出:这里只有"协议形状"和"帧怎么拼",
* 没有任何 socket、状态机与重连逻辑 —— 那些留在 DeviceBridgeClient 里。
*
* 注意:DeviceBridgeClient 的对外方法名与语义不因本文件而改变,
* 各 send* 方法仍是"拼帧 + 发出去"两步,只是第一步搬到了这里。
*/
import { CapResult } from './BridgeCaps';
import { appVersion } from './AppVersion';
// ===== 协议消息(与 remotedevice 插件对齐)=====
export interface HelloDeviceInfo {
hostname: string;
platform: string;
arch: string;
os_release: string;
version: string;
cpus: number;
}
export interface HelloDevice {
device_id: string;
name: string;
kind: string;
authorized: boolean;
caps: string[];
info: HelloDeviceInfo;
}
export interface HelloMessage {
op: string;
device: HelloDevice;
}
export interface BindMessage {
op: string;
device_id: string;
token: string;
}
export interface CmdReply {
op: string; // 'cmd_result'
req_id: string;
status: string;
output: string;
error: string;
}
export interface DataStartMessage {
op: string;
req_id: string;
kind: string;
mime: string;
total: number;
chunk_size: number;
}
export interface DataEndMessage {
op: string;
req_id: string;
status: string;
total?: number;
error?: string;
}
export const CHUNK_SIZE: number = 8192;
// ===== 命令处理器回调 =====
// 返回 CapResult;二进制大结果通过 dataHandler 分块回传。
export type BridgeCmdHandler = (reqId: string, command: string) => Promise<CapResult>;
// ===== 帧构造 =====
export function bridgeHelloFrame(deviceId: string, name: string, kind: string,
caps: string[], hostname: string,
authorized: boolean): string {
const info: HelloDeviceInfo = {
hostname: hostname,
platform: 'OpenHarmony',
arch: '',
os_release: '',
version: appVersion(),
cpus: 0,
};
const device: HelloDevice = {
device_id: deviceId,
name: name,
kind: kind,
authorized: authorized,
caps: caps,
info: info,
};
const hello: HelloMessage = { op: 'hello', device: device };
return JSON.stringify(hello);
}
export function bridgeBindFrame(deviceId: string, token: string): string {
const bind: BindMessage = {
op: 'bind',
device_id: deviceId,
token: token,
};
return JSON.stringify(bind);
}
export function bridgeResultFrame(reqId: string, status: string,
output: string, errMsg: string): string {
const result: CmdReply = {
op: 'cmd_result',
req_id: reqId,
status: status,
output: output,
error: errMsg,
};
return JSON.stringify(result);
}
export function bridgeDataStartFrame(reqId: string, kind: string, mime: string,
total: number): string {
const startMsg: DataStartMessage = {
op: 'cmd_data_start',
req_id: reqId,
kind: kind,
mime: mime,
total: total,
chunk_size: CHUNK_SIZE,
};
return JSON.stringify(startMsg);
}
export function bridgeDataEndFrame(reqId: string): string {
const endMsg: DataEndMessage = {
op: 'cmd_data_end',
req_id: reqId,
status: 'ok',
};
return JSON.stringify(endMsg);
}
export function bridgeEventFrame(deviceId: string, eventType: string, detail: string): string {
const payload: Record<string, string> = { 'detail': detail };
const msg: Record<string, Object> = {
'op': 'event',
'device_id': deviceId,
'type': eventType,
'payload': payload,
};
return JSON.stringify(msg);
}
export function bridgeStatusFrame(deviceId: string, status: string): string {
const msg: Record<string, Object> = {
'op': 'status',
'device_id': deviceId,
'status': status,
};
return JSON.stringify(msg);
}
/** 按 CHUNK_SIZE 切二进制;切片顺序即发送顺序。 */
export function bridgeChunkSlices(bytes: Uint8Array): Uint8Array[] {
const out: Uint8Array[] = [];
for (let off: number = 0; off < bytes.byteLength; off += CHUNK_SIZE) {
const end: number = Math.min(off + CHUNK_SIZE, bytes.byteLength);
out.push(bytes.slice(off, end));
}
return out;
}

View File

@ -1,15 +1,16 @@
import { deviceBridge } from './DeviceBridge'; import { deviceBridge } from './DeviceBridge';
import { import {
CapResult, CapResult,
DataChunkSender,
capScreensee, capScreensee,
capCamerasue,
capClipboardSee, capClipboardSee,
capClipboardsue, capClipboardsue,
capSpeakerUse, capSpeakerUse,
capDeviceInfo, capDeviceInfo,
capStatus, capStatus,
parseScreensue,
ScreensuePayload,
} from './BridgeCaps'; } from './BridgeCaps';
import { parseScreensue, ScreensuePayload } from './ScreensueHtml';
import { connStore } from './ConnStore'; import { connStore } from './ConnStore';
import { common } from '@kit.AbilityKit'; import { common } from '@kit.AbilityKit';
@ -84,6 +85,17 @@ async function executeCommand(reqId: string, command: string): Promise<CapResult
} }
return errRes('展示界面尚未就绪,请保持应用在前台后重试'); return errRes('展示界面尚未就绪,请保持应用在前台后重试');
} }
if (name === 'camerasue') {
if (appContext === null) {
return errRes('相机能力尚未就绪,请保持应用在前台后重试');
}
// 录像走二进制分块:把「往本请求回传字节」的能力注入能力实现,
// 避免 BridgeCaps 反向 import DeviceBridge 形成循环依赖。
const sender: DataChunkSender = (kind: string, mime: string, bytes: Uint8Array) => {
deviceBridge.sendDataChunked(reqId, kind, mime, bytes);
};
return capCamerasue(appContext, args, sender);
}
if (name === 'clipboardsee') { if (name === 'clipboardsee') {
if (hasArgs(args)) { if (hasArgs(args)) {
return errRes('clipboardsee 不接受额外参数'); return errRes('clipboardsee 不接受额外参数');

View File

@ -0,0 +1,223 @@
/**
* 聊天页的纯格式化/判定逻辑(无 UI 依赖)。
*
* 从 pages/ChatPage.ets 抽出:这些函数只吃数据吐字符串/布尔,
* 抽出来后气泡、工具卡、渠道头像三个组件可以共用同一份口径。
*/
import { ChatMessage, ToolCallInfo } from '../model/Model';
/**
* 由文件名后缀推断 Content-Type。
* 后端按 multipart 部件的 Content-Type 判定 image/file,
* 给错会让图片被当成普通文件(缩略图就没了)。
*/
export function mimeOf(name: string, isImage: boolean): string {
const i: number = name.lastIndexOf('.');
const ext: string = i >= 0 ? name.substring(i + 1).toLowerCase() : '';
if (ext === 'png') {
return 'image/png';
}
if (ext === 'jpg' || ext === 'jpeg') {
return 'image/jpeg';
}
if (ext === 'webp') {
return 'image/webp';
}
if (ext === 'gif') {
return 'image/gif';
}
if (ext === 'bmp') {
return 'image/bmp';
}
if (ext === 'heic' || ext === 'heif') {
return 'image/heic';
}
if (isImage) {
return 'image/jpeg';
}
if (ext === 'pdf') {
return 'application/pdf';
}
if (ext === 'txt' || ext === 'log' || ext === 'md') {
return 'text/plain';
}
if (ext === 'json') {
return 'application/json';
}
return 'application/octet-stream';
}
/** payload 字段可能是字符串、对象或数组,统一转成可展示文本。 */
export function stringifyField(raw: Object | undefined): string {
if (raw === undefined || raw === null) {
return '';
}
if (typeof raw === 'string') {
return raw as string;
}
try {
return JSON.stringify(raw);
} catch (e) {
return String(raw);
}
}
/**
* ForEach 键:消息结构变化即换键 → 旧气泡销毁重建 → @Builder 里的
* if 分支重新求值。这是 ArkUI V1 渲染模型决定的:ForEach 对相同键
* 只更新 @Prop/@Link 绑定,不重新执行 @Builder 体,所以
* 「思考卡/工具卡/附件」这些用 if 包裹的条件分支在首次渲染后
* 永远不会再次求值——气泡里的这些面板就永远不出现。
*
* 反过来,content_delta 不进 structSig:正文文本靠 MarkdownView
* 的 @Prop content 响应式更新,不重建气泡 → 流式渲染平滑。
* 实测 SSE 里 reasoning_delta 与 content_delta 不交错(思考阶段
* 先于输出阶段),所以思考期间重建气泡不会打断正文流式动画。
*/
export function structSig(msg: ChatMessage): string {
let s: string = msg.id.toString();
const rc: string | undefined = msg.reasoningContent;
s += '_r' + (rc !== undefined ? rc.length.toString() : '0');
s += '_ro' + (msg.reasoningOpen === true ? '1' : '0');
const tcs: ToolCallInfo[] | undefined = msg.toolCalls;
if (tcs !== undefined) {
s += '_t' + tcs.length.toString();
for (let i = 0; i < tcs.length; i++) {
const tc: ToolCallInfo = tcs[i];
s += '_' + (tc.status ?? '');
s += '_' + (tc.open === true ? 'o' : 'c');
s += '_' + (tc.args !== undefined ? tc.args.length.toString() : '0');
s += '_' + (tc.result !== undefined ? tc.result.length.toString() : '0');
s += '_' + (tc.plugin ?? '');
}
} else {
s += '_t0';
}
s += '_a' + (msg.attachment !== undefined ? '1' : '0');
s += '_src' + (msg.source ?? '');
s += '_f' + (msg.isFinal === true ? '1' : '0');
s += '_s' + (msg.isStreaming === true ? '1' : '0');
return s;
}
/** 折叠时也要能看出思考在增长:显示字数 */
export function reasoningLenLabel(msg: ChatMessage): string {
const rc: string | undefined = msg.reasoningContent;
if (rc === undefined || rc.length === 0) {
return '';
}
return rc.length.toString() + ' 字';
}
/**
* 是否仍在执行。
* 判据是 status 而不是 result:后端 status=ok 的工具也可能返回空串,
* 用 result 判断会让这类调用永远显示"调用中"。
*/
export function tcRunning(tc: ToolCallInfo): boolean {
const s: string | undefined = tc.status;
return s === undefined || s.length === 0 || s === 'running';
}
export function tcError(tc: ToolCallInfo): boolean {
return tc.status === 'denied' || tc.status === 'error';
}
/** 工具卡左侧色条(accent 由调用方从 palette 取) */
export function tcLeftColor(tc: ToolCallInfo, accent: string): string {
if (tcError(tc)) {
return '#DB3694';
}
if (tcRunning(tc)) {
return accent;
}
return 'rgba(23, 169, 100, 0.8)';
}
/** 工具卡状态图标颜色 */
export function tcIcoColor(tc: ToolCallInfo, accent: string): string {
if (tcError(tc)) {
return '#DB3694';
}
if (tcRunning(tc)) {
return accent;
}
return 'rgba(23, 169, 100, 0.9)';
}
export function tcStateLabel(tc: ToolCallInfo): string {
if (tc.status === 'denied') {
return '已拒绝';
}
if (tcRunning(tc)) {
return '调用中';
}
return '完成';
}
export function tcStateColor(tc: ToolCallInfo): string {
if (tc.status === 'denied') {
return '#FF9EC6';
}
if (tcRunning(tc)) {
return '#A3B8FF';
}
return '#6EE7A8';
}
/**
* 气泡最大宽度(相对 BubbleSlot 的宽度,即扣掉头像与间距后的真实可用宽)。
* 纯文本 78% 好看;但工具卡/思考卡是"面板",78% 会把里面的状态文字和
* 参数/结果压成一团(还会被 clip 切掉),所以带卡片时放宽到 92%。
*/
export function bubbleMaxWidth(msg: ChatMessage): string {
const hasPanels: boolean =
(msg.toolCalls !== undefined && msg.toolCalls.length > 0) ||
(msg.reasoningContent !== undefined && msg.reasoningContent.length > 0);
return hasPanels ? '92%' : '78%';
}
/**
* 是否"别处来的"消息。对齐 GUI 的 source !== 'webui' 判定,但多减一项:
* 本机自己发的消息在后端会被写成 webui/<device_id>,那仍然是"我发的",
* 不能当成渠道消息挂上别人的头像。
*/
export function isChannelMsg(source: string, deviceId: string): boolean {
if (source.length === 0 || source === 'webui') {
return false;
}
return source !== 'webui/' + deviceId;
}
/** 自己发的消息(右对齐、"我"头像):渠道消息即使 role=user 也不算 */
export function isSelfMsg(role: string, channel: boolean): boolean {
return role === 'user' && !channel;
}
/** 渠道名展示:webui/<id> 只显示 <id>,其余原样。 */
export function chanLabel(src: string): string {
if (src.startsWith('webui/')) {
return src.substring(6);
}
return src;
}
/** 渠道首字母(大写),用作头像文字。 */
export function chanLetter(src: string): string {
const label: string = chanLabel(src);
if (label.length === 0) {
return '?';
}
return label.substring(0, 1).toUpperCase();
}
/** 由渠道名散列出稳定色,避免每次渲染换色。 */
export function chanColor(src: string): string {
const label: string = chanLabel(src);
let h: number = 0;
for (let i = 0; i < label.length; i++) {
h = (h * 31 + label.charCodeAt(i)) % 360;
}
return 'hsl(' + h.toString() + ', 52%, 46%)';
}

View File

@ -0,0 +1,119 @@
/**
* /chat/history 响应解析(无 UI 依赖)。
*
* 从 pages/ChatPage.ets 抽出:首屏与向上翻页共用同一套解析口径,
* 消息 id 由调用方提供的分配器给出(页面自己维护 id 计数器)。
*/
import { ChatMessage, ToolCallInfo, ChatAttachment } from '../model/Model';
import { parseAttachment } from './AttachmentMeta';
import { stringifyField } from './ChatFormat';
/** 分页历史解析结果:消息列表 + 服务端分页元数据 */
export interface ParsedHistory {
msgs: ChatMessage[];
/** 本页首条在服务端全量历史中的下标,作为下次向上翻页的 before 游标 */
offset: number;
/** 服务端是否还有更早的历史 */
hasMore: boolean;
/**
* 服务端下发的增量游标(响应里的 last_seq)。
*
* 为什么必须带回来:/chat/history?after=<seq> 只回 seq 更大的消息,
* 客户端存下游标下次带上,才能只拿增量而不重新拉整页
* (jianf 说的“暴露数据查询 api,前端轮询后 patch 视图”那条路)。
* 缺了它就只能每次全量拉,也就无法发现“别人发来的新消息”。
*/
lastSeq: number;
}
/** 解析后端 /chat/history 的响应体(含分页元数据),供首屏与翻页复用。 */
export function parseHistoryPayload(
obj: Record<string, Object>, alloc: () => number): ParsedHistory {
const rawList: Object | undefined = obj['messages'] as Object | undefined;
if (rawList === undefined || rawList === null) {
return { msgs: [], offset: 0, hasMore: false, lastSeq: 0 };
}
const arr: Object[] = rawList as Object[];
const msgs: ChatMessage[] = [];
for (let i = 0; i < arr.length; i++) {
const item: Record<string, Object> = arr[i] as Record<string, Object>;
const role: string = item['role'] as string ?? '';
const content: string = item['content'] as string ?? '';
const att: ChatAttachment | undefined = parseAttachment(item['attachment']);
// 纯附件消息 content 可能为空,不能再按"无内容就丢弃"处理
if (role.length === 0 || (content.length === 0 && att === undefined)) {
continue;
}
const msg: ChatMessage = {
id: alloc(),
role: role,
content: content,
isFinal: true,
};
// seq:服务端单调递增序号,增量游标与 keyed 对账的定位符。
// 缺失(旧后端/本地乐观消息)时保持 undefined,不编造。
const seqVal: Object | undefined = item['seq'];
if (typeof seqVal === 'number' && (seqVal as number) > 0) {
msg.seq = seqVal as number;
}
if (att !== undefined) {
msg.attachment = att;
}
// 后端 handler.go 保证 history 不裁剪 reasoning_content / tool_calls,
// 这里必须还原,否则刷新后思考与工具卡就凭空消失。
const rc: string = item['reasoning_content'] as string ?? '';
if (rc.length > 0) {
msg.reasoningContent = rc;
}
const tcs: ToolCallInfo[] | undefined = parseHistoryToolCalls(item['tool_calls']);
if (tcs !== undefined) {
msg.toolCalls = tcs;
}
// 渠道/设备来源:后端 ChatMsg.source,用于区分 channel_output 等非 webui 消息
const src: string = item['source'] as string ?? '';
if (src.length > 0) {
msg.source = src;
}
msgs.push(msg);
}
const offset: number = typeof obj['offset'] === 'number' ? obj['offset'] as number : 0;
const hasMore: boolean = obj['has_more'] === true;
// last_seq:增量游标。缺失时回退到本页最大 seq,保证游标不会倒退。
let lastSeq: number = typeof obj['last_seq'] === 'number' ? obj['last_seq'] as number : 0;
for (let i = 0; i < msgs.length; i++) {
const sq: number | undefined = msgs[i].seq;
if (sq !== undefined && sq > lastSeq) {
lastSeq = sq;
}
}
return { msgs: msgs, offset: offset, hasMore: hasMore, lastSeq: lastSeq };
}
/** 后端 tool_calls 条目带 tool 和 name 两份;args/result 可能是对象也可能是字符串。 */
export function parseHistoryToolCalls(raw: Object | undefined): ToolCallInfo[] | undefined {
if (raw === undefined || raw === null) {
return undefined;
}
const arr: Object[] = raw as Object[];
if (arr.length === 0) {
return undefined;
}
const tcs: ToolCallInfo[] = [];
for (let i = 0; i < arr.length; i++) {
const item: Record<string, Object> = arr[i] as Record<string, Object>;
const name: string = (item['tool'] as string ?? '') || (item['name'] as string ?? '');
if (name.length === 0) {
continue;
}
const tc: ToolCallInfo = {
name: name,
args: stringifyField(item['args']),
result: stringifyField(item['result']),
status: item['status'] as string ?? undefined,
plugin: item['plugin'] as string ?? undefined,
};
tcs.push(tc);
}
return tcs.length > 0 ? tcs : undefined;
}

View File

@ -0,0 +1,206 @@
/**
* 发送 / 中断(无 UI 依赖)。
*
* 从 pages/ChatPage.ets 抽出:POST /chat 与 POST /chat/file 的请求体、
* 兜底消息合并、超时口径都收在这里,输入区组件只负责把文本/附件递进来。
*/
import { ChatMessage, ChatAttachment } from '../model/Model';
import { apiClient } from './ApiClient';
import { connStore } from './ConnStore';
import { userMessage, isTimeout } from './UserError';
import { chatStore } from './ChatStore';
import { parseAttachment } from './AttachmentMeta';
import { http } from '@kit.NetworkKit';
interface SendChatBody {
message: string;
client_msg_id: string;
/** 非空时后端编码 source = "webui/<device_id>",agent 可见来源设备 */
device_id?: string;
device_name?: string;
}
/** POST /chat/interrupt 的请求体。 */
interface InterruptBody {
/** true = 停止(立即结束当前推理 + 短路已排队消息);false/省略 = 普通中断。 */
stop: boolean;
/** 可选:中断时附带给模型的一句话;停止时为 undefined。 */
message?: string;
}
/**
* 纯文本发送:POST /chat。
* 带附件的情况走 sendChatFile(后端收下附件后自己写会话并触发 agent)。
*/
export async function sendChatText(text: string): Promise<void> {
const trimmed: string = text.trim();
if (chatStore.isLoading()) {
return;
}
const cur = connStore.getCurrentConnection();
if (cur === null) {
return;
}
if (trimmed.length === 0) {
return;
}
// 重置 SSE 标记
chatStore.setSseActive(false);
const userMsg: ChatMessage = { id: chatStore.allocId(), role: 'user', content: trimmed };
chatStore.pushNew(userMsg);
chatStore.setLoading(true);
chatStore.setStage('等待 AI 回复...');
chatStore.forceRefresh();
chatStore.requestScroll();
const bodyObj: SendChatBody = {
message: trimmed,
client_msg_id: Date.now().toString(36),
// 必须带设备身份:后端没有 device_id 就把来源编码成 webui,
// agent 会以为消息来自网页端。device_id 非空时后端编码
// source = "webui/<device_id>" 并注入设备上下文。
device_id: connStore.ensureDeviceId(),
device_name: connStore.getDeviceName(),
};
// 如果 SSE 已连接,POST 作为触发器(响应由 SSE 推送渲染);
// 仅在 SSE 未推送内容时才用 POST 响应兜底创建消息。
try {
const resp = await apiClient.postWithTimeout('/chat', bodyObj, 120000);
// SSE 已经处理了响应,跳过 POST 消息创建
if (chatStore.sseActive()) {
chatStore.setLoading(false);
chatStore.setStage('');
chatStore.forceRefresh();
chatStore.requestScroll();
return;
}
const parsed: Record<string, string> = JSON.parse(resp.body) as Record<string, string>;
const respText: string = parsed['response'] ?? '(无响应)';
const reasoning: string = parsed['reasoning_content'] ?? '';
const last: ChatMessage | null = chatStore.lastMessage();
if (last !== null && last.role === 'assistant' && !last.isFinal) {
last.content = respText;
last.isFinal = true;
last.isStreaming = false;
if (reasoning.length > 0 && last.reasoningContent === undefined) {
last.reasoningContent = reasoning;
}
} else if (last !== null && last.role === 'assistant' && last.isFinal) {
// 已有最终消息,合并(不应发生,但防御性处理)
if (respText.length > last.content.length) {
last.content = respText;
}
} else {
const msg: ChatMessage = {
id: chatStore.allocId(),
role: 'assistant',
content: respText,
isFinal: true,
};
if (reasoning.length > 0) {
msg.reasoningContent = reasoning;
}
chatStore.pushNew(msg);
}
chatStore.setLoading(false);
chatStore.setStage('');
chatStore.forceRefresh();
chatStore.requestScroll();
} catch (e) {
// 超时通常意味着后端仍在生成,不算失败;其余一律显示人话,
// 原始错误只进 hilog(之前把 e.message 拼进 chatStage 会把
// "Failed to connect to the server."、内网地址直接摆到聊天流里)。
if (isTimeout(e)) {
chatStore.setStage('请求已发送,等待回复...');
} else {
chatStore.setStage(userMessage('chat.send', e));
}
chatStore.forceRefresh();
chatStore.requestScroll();
}
}
/**
* 带附件发送:POST /chat/file(multipart),字段与 WebGUI 一致。
* 后端收下后自身会把用户消息与附件写进会话并触发 agent,
* 回复照常从 SSE 过来,所以这里不再走 /chat。
*/
export async function sendChatFile(text: string, path: string, name: string,
size: number, isImage: boolean, mime: string): Promise<void> {
if (connStore.getCurrentConnection() === null) {
return;
}
const att: ChatAttachment = {
type: isImage ? 'image' : 'file',
// 本地待上传:先用沙箱路径预览,上传成功后替换成服务端 URL
url: 'file://' + path,
size: size,
name: name,
};
const userMsg: ChatMessage = { id: chatStore.allocId(), role: 'user', content: text };
userMsg.attachment = att;
chatStore.pushNew(userMsg);
chatStore.setLoading(true);
chatStore.setStage('正在上传附件...');
chatStore.setSseActive(false);
chatStore.forceRefresh();
chatStore.requestScroll();
const parts: http.MultiFormData[] = [
{ name: 'file', contentType: mime, remoteFileName: name, filePath: path },
{ name: 'message', contentType: 'text/plain', data: text },
{ name: 'client_msg_id', contentType: 'text/plain', data: Date.now().toString(36) },
{ name: 'device_id', contentType: 'text/plain', data: connStore.ensureDeviceId() },
{ name: 'device_name', contentType: 'text/plain', data: connStore.getDeviceName() },
];
try {
const resp = await apiClient.postMultipart('/chat/file', parts, 180000);
const obj: Record<string, Object> = JSON.parse(resp.body) as Record<string, Object>;
const uploaded: ChatAttachment | undefined = parseAttachment(obj['file']);
if (uploaded !== undefined) {
userMsg.attachment = uploaded;
}
chatStore.setStage('等待 AI 回复...');
} catch (e) {
chatStore.setStage(userMessage('chat.upload', e));
chatStore.setLoading(false);
}
chatStore.forceRefresh();
chatStore.requestScroll();
}
/**
* 停止当前生成(停止按钮)。
*
* 发送 **`stop: true`**,与「带一句话的中断」区分开:
* - stop:true(无 message)= ①立即结束当前 LLM 推理(不重试);
* ②对停止那一刻已排队的消息,后端在 pre-action 逐个短路。
* - message 非空 = 普通中断,模型看到被打断的上下文 + 新输入。
*
* 为什么必须带 stop:此前这里 POST 的是 null(空 body),后端把空内容当成
* “无事发生”直接丢掉了——接口回 200 但生成继续跑到自然结束,也就是“按了没反应”。
* 带中文字段比空 body 多不了几个字节,就把语义说清楚了。
*/
export async function interruptChat(): Promise<void> {
if (connStore.getCurrentConnection() === null) {
return;
}
try {
const body: InterruptBody = { stop: true };
await apiClient.post('/chat/interrupt', body);
} catch (e) {
// 停止是“减少工作”的指令,失败不需打断用户;但状态必须复位,
// 否则按钮会一直停在“停止”态,用户以为没生效。
}
// 即时反馈:不等 SSE 的终态事件,先把本地忙态清掉。
// 若后端稍后真的推来终态,SSE 处理器会再刷一次(幂等)。
chatStore.setLoading(false);
chatStore.setStage('已停止');
chatStore.forceRefresh();
}

View File

@ -0,0 +1,196 @@
/**
* SSE 事件 → 聊天流状态的翻译层(无 UI 依赖)。
*
* 从 pages/ChatPage.ets 抽出。这里只认「事件帧」与「往状态里写什么」,
* 具体状态由 ChatStreamSink 提供 —— 这样本文件不必 import ChatStore,
* 两边不会形成 ArkTS 里被拒绝的模块循环依赖。
*/
import { ChatMessage, ToolCallInfo, ChatAttachment } from '../model/Model';
import { attachmentFromChannelOutput } from './AttachmentMeta';
import { SseEvent } from './SseClient';
import { stringifyField } from './ChatFormat';
import { stageTrail } from './StageTrail';
import { hilog } from '@kit.PerformanceAnalysisKit';
/** 聊天流状态机对外暴露的最小写入面(由 common/ChatStore.ets 实现) */
export interface ChatStreamSink {
allocId(): number;
lastMessage(): ChatMessage | null;
/** 取/建"未定稿的助手消息" */
ensureAssistant(): ChatMessage;
/** 取/建同名未完成工具卡 */
ensureToolCall(name: string): ToolCallInfo;
/** 追加一条新消息并播入场动画 */
pushNew(msg: ChatMessage): void;
setLoading(v: boolean): void;
setStage(s: string): void;
setSseActive(v: boolean): void;
/** 防抖刷新(合并高频 delta) */
refresh(): void;
/** 请求滚到底 */
requestScroll(): void;
/** sync_required:补拉历史 */
reloadHistory(): void;
}
export function applyChatSse(ev: SseEvent, sink: ChatStreamSink): void {
try {
// 服务端 data 字段是完整 sdk.Event:{type, source, payload, timestamp}
// 业务字段全部在 payload 之下,历史实现直接读顶层导致流式/思考/工具调用全部失效。
const frame: Record<string, Object> = JSON.parse(ev.data) as Record<string, Object>;
const inner: Object | undefined = frame['payload'];
const payload: Record<string, Object> =
inner !== undefined && inner !== null ? inner as Record<string, Object> : frame;
const frameType: string = frame['type'] as string ?? '';
const type: string = ev.event.length > 0 ? ev.event : frameType;
// 诊断只记事件类型(内容可能含隐私,不落盘)
hilog.debug(0x0000, 'HomeAgent', 'sse %{public}s', type);
if (type === 'agent_output') {
const content: string = payload['content'] as string ?? '';
// channel_output 携带图片/文件:url/size/output_type 三个字段在 payload 顶层,
// 它是一条独立的附件消息,不能合并进上一条文本气泡。
const kind: string = payload['kind'] as string ?? '';
if (kind === 'channel_output') {
const att: ChatAttachment | undefined = attachmentFromChannelOutput(
payload['output_type'] as string ?? '',
payload['url'] as string ?? '',
payload['size'] as number ?? 0);
if (att !== undefined) {
const amsg: ChatMessage = {
id: sink.allocId(),
role: 'assistant',
content: content,
isFinal: true,
source: 'channel',
attachment: att,
};
sink.pushNew(amsg);
sink.setLoading(false);
sink.setStage('');
sink.setSseActive(false);
sink.refresh();
sink.requestScroll();
return;
}
}
const last: ChatMessage | null = sink.lastMessage();
if (last !== null && last.role === 'assistant' && !last.isFinal) {
last.content = content;
last.isFinal = true;
last.isStreaming = false;
} else if (last !== null && last.role === 'assistant' && last.isFinal) {
// POST 已经创建了最终消息,仅合并内容(如果有增量)
if (content.length > last.content.length) {
last.content = content;
}
} else {
const msg: ChatMessage = {
id: sink.allocId(),
role: 'assistant',
content: content,
isFinal: true,
};
sink.pushNew(msg);
}
sink.setLoading(false);
sink.setStage('');
sink.setSseActive(false);
sink.refresh();
sink.requestScroll();
} else if (type === 'reasoning') {
const rc: string = payload['content'] as string ?? '';
if (rc.length > 0) {
sink.setStage('AI 思考中...');
// 聚合 reasoning 可能先于任何 delta 到达(非流式后端就只有这一条),
// 此时还没有"未完成的助手消息",必须新建一条,否则思考内容直接丢失。
const last: ChatMessage = sink.ensureAssistant();
last.reasoningContent = rc;
sink.refresh();
sink.requestScroll();
}
} else if (type === 'sync_required') {
// 断线重连时服务端要求补拉历史(ring 里没有可重放的聚合事件)
sink.reloadHistory();
} else if (type === 'agent_error') {
// 后端错误一律转人话,技术细节不上 UI
sink.setLoading(false);
sink.setStage('本轮处理失败,请重试');
sink.refresh();
} else if (type === 'content_delta') {
const delta: string = payload['content'] as string ?? '';
if (delta.length > 0) {
sink.setSseActive(true);
const last: ChatMessage = sink.ensureAssistant();
last.content += delta;
sink.refresh();
sink.requestScroll();
}
} else if (type === 'reasoning_delta') {
const delta: string = payload['content'] as string ?? '';
if (delta.length > 0) {
sink.setSseActive(true);
sink.setStage('AI 思考中...');
const last: ChatMessage = sink.ensureAssistant();
if (last.reasoningContent === undefined) {
last.reasoningContent = '';
}
last.reasoningContent += delta;
sink.refresh();
}
} else if (type === 'tool_call') {
const toolName: string = payload['tool'] as string ?? '';
const toolStatus: string = payload['status'] as string ?? '';
const toolPlugin: string = payload['plugin'] as string ?? '';
if (toolName.length > 0) {
sink.setStage('工具调用: ' + toolName);
const target: ToolCallInfo = sink.ensureToolCall(toolName);
if (toolPlugin.length > 0) {
target.plugin = toolPlugin;
}
const argsText: string = stringifyField(payload['args']);
if (argsText.length > 0) {
target.args = argsText;
}
if (toolStatus.length > 0) {
// 后端只在工具执行【结束】时发 tool_call(status=ok/denied/interrupted),
// 所以拿到 status 就意味着这次调用已收尾,result 一并落卡。
target.status = toolStatus;
target.result = stringifyField(payload['result']);
} else {
target.status = 'running';
}
sink.refresh();
sink.requestScroll();
}
} else if (type === 'stage') {
const phase: string = payload['phase'] as string ?? '';
const channel: string = payload['channel'] as string ?? '';
const stageTool: string = payload['tool'] as string ?? '';
if (channel !== '_consolidation_') {
// 运行态面板的阶段管道靠这条轨迹活着:先喂轨迹,再管聊天侧的角标。
// 两者是独立消费者,轨迹不依赖任何聊天状态。
stageTrail.onStage(phase, stageTool);
if (phase === 'pre_action') {
sink.setStage('AI 思考中...');
} else if (phase === 'before_toolcall') {
sink.setStage('工具调用: ' + stageTool);
// 关键:tool_call 事件只在执行【结束】后才发,所以"调用中"这一态
// 必须由 before_toolcall 建卡,否则用户永远看不到工具正在跑。
if (stageTool.length > 0) {
const tc: ToolCallInfo = sink.ensureToolCall(stageTool);
if (tc.status === undefined) {
tc.status = 'running';
}
}
} else if (phase === 'before_output') {
sink.setStage('生成回复中...');
}
sink.refresh();
}
}
} catch (e) {
// ignore parse errors
}
}

View File

@ -0,0 +1,602 @@
/**
* 聊天流状态源(单例)。
*
* 从 pages/ChatPage.ets 抽出:消息数组、分页游标、"哪几条是新消息"、
* SSE 连接与历史拉取都属于同一个状态机;页面只剩渲染与输入。
*
* 为什么数组不进 AppStorage:StatusStore 已经踩过一次 —— 数组同步语义不可靠。
* 这里沿用同一套做法:数组留在 store 内部,标量走 AppStorage 广播,
* 另加一个自增版本号 K_CHAT_REV 通知订阅组件"重取一次快照"。
*
* 订阅组件的接法(见 components/ChatStream.ets):
* @StorageProp(K_CHAT_REV) @Watch('onRev') private rev: number = 0;
* onRev(): void { this.messages = chatStore.messages(); }
* ForEach 拿到的仍然是"每次刷新一个新数组引用",与拆分前
* (this.messages = this.messages.slice())的渲染语义完全一致。
*
* SSE 事件的翻译在 common/ChatSse.ets:本类实现它的 ChatStreamSink 接口,
* 依赖方向只有"ChatStore → ChatSse"一条,不构成循环。
*/
import { ChatMessage, ToolCallInfo, ChatAttachment } from '../model/Model';
import { SseClient, SseEvent } from './SseClient';
import { connStore } from './ConnStore';
import { apiClient } from './ApiClient';
import { CHAT_PAGE_SIZE } from './Constants';
import { ParsedHistory, parseHistoryPayload } from './ChatHistory';
import { applyChatSse, ChatStreamSink } from './ChatSse';
// ===== AppStorage 键:页面/聊天流/输入区共用 =====
export const K_CHAT_REV: string = 'chatRev';
export const K_CHAT_SCROLL_REV: string = 'chatScrollRev';
export const K_CHAT_LOADING: string = 'chatBusy';
export const K_CHAT_STAGE: string = 'chatStageText';
export const K_CHAT_CONNECTED: string = 'chatSseUp';
const SSE_RECONNECT_MS: number = 5000;
/** 增量轮询间隔:与 WebUI 的 chatTicker 一致(3s)。 */
const CHAT_POLL_MS: number = 3000;
/**
* 把服务端来的消息并进本地列表,**按 seq 对账**(与 WebUI 的
* applyServerMessages 同口径)。
*
* 为什么不再按“正文内容”去重:那是本次调研确认的缺陷根因。同一个人把
* 同一句话发两次,或本地乐观消息与服务端回显内容相同时,内容比对会把
* 其中一条误判成重复而丢弃(“App 发出的消息不显示”就是这个表现)。
* seq 是服务端分配的唯一序号,才是可靠的定位符。
*
* 规则:
* - 服务端消息带 seq:本地已有同 seq → 原地更新(工具卡/最终文本是
* 原地改的,不产生新 seq,只靠 after 拿不到,必须靠尾部探测更新);
* 本地没有 → 追加。
* - 服务端消息无 seq(旧后端):退化为「本地末尾同角色同内容则认领」。
* - 本地无 seq 的乐观 user 消息:服务端回显同一句时被认领(补上 seq),
* 而不是重复出现——认领先匹配最后一条无 seq 的同类消息。
*
* tailOnly:只允许在末尾追加/更新,用于“尾部探测”(拉最新一条做原地更新),
* 避免把历史中间的消息插进来造成顺序错乱。
*/
function reconcileServerMsgs(local: ChatMessage[], incoming: ChatMessage[],
tailOnly: boolean, alloc: () => number): ChatMessage[] {
const out: ChatMessage[] = local.slice();
for (let i = 0; i < incoming.length; i++) {
const sm: ChatMessage = incoming[i];
const sq: number | undefined = sm.seq;
let found: number = -1;
if (sq !== undefined) {
// 从尾部往前找:新消息总在尾部,省掉全表扫描
for (let j = out.length - 1; j >= 0 && j >= out.length - 12; j--) {
if (out[j].seq === sq) {
found = j;
break;
}
}
}
if (found >= 0) {
// 原地更新:保留本地 id(组件按 id 复用,不重建气泡),
// 只覆盖服务端权威字段。
const prev: ChatMessage = out[found];
if (prev.content !== sm.content) {
prev.content = sm.content;
}
if (sm.reasoningContent !== undefined && prev.reasoningContent !== sm.reasoningContent) {
prev.reasoningContent = sm.reasoningContent;
}
if (sm.toolCalls !== undefined) {
prev.toolCalls = sm.toolCalls;
}
if (sm.attachment !== undefined) {
prev.attachment = sm.attachment;
}
if (sm.source !== undefined) {
prev.source = sm.source;
}
prev.isFinal = true;
prev.isStreaming = false;
continue;
}
if (tailOnly) {
// 尾部探测:只有比本地最后一条 seq 更大才有意义,否则忽略(它已在中间)
let maxLocalSeq: number = 0;
for (let j = 0; j < out.length; j++) {
const ls: number | undefined = out[j].seq;
if (ls !== undefined && ls > maxLocalSeq) {
maxLocalSeq = ls;
}
}
if (sq !== undefined && sq > maxLocalSeq) {
sm.id = alloc();
out.push(sm);
}
continue;
}
// 认领本地乐观消息:本地末尾尚未拿到 seq 的同类消息,视为它的回显。
if (sq !== undefined) {
let claimed: number = -1;
for (let j = out.length - 1; j >= 0; j--) {
const lm: ChatMessage = out[j];
if (lm.seq !== undefined) {
break;
}
if (lm.role === sm.role) {
claimed = j;
break;
}
}
if (claimed >= 0) {
const prev: ChatMessage = out[claimed];
prev.seq = sq;
prev.isFinal = true;
prev.isStreaming = false;
if (sm.source !== undefined) {
prev.source = sm.source;
}
if (sm.attachment !== undefined) {
prev.attachment = sm.attachment;
}
continue;
}
}
sm.id = alloc();
out.push(sm);
}
return out;
}
class ChatStore implements ChatStreamSink {
private msgs: ChatMessage[] = [];
private nextId: number = 1;
private refreshTimer: number = -1;
private reconnectTimer: number = -1;
/** 分页历史:当前已加载消息在服务端全量中的起始下标 */
private offset: number = 0;
/** 是否还有更早历史可向上加载 */
private hasEarlier: boolean = false;
private loadingOlder: boolean = false;
/** 正在为新消息播入场动画的 id */
private newIds: number[] = [];
// SSE 正在为当前轮次推送内容时置 true,阻止 POST 响应重复创建消息
private sseActiveForTurn: boolean = false;
/** 增量游标:本地已知的最大服务端 seq(对应 WebUI 的 state.chatLastSeq) */
private lastSeq: number = 0;
/** 增量轮询中进行中,避免重入 */
private polling: boolean = false;
private pollTimer: number = -1;
private sse: SseClient = new SseClient();
init(): void {
AppStorage.setOrCreate<boolean>(K_CHAT_LOADING, false);
AppStorage.setOrCreate<string>(K_CHAT_STAGE, '');
AppStorage.setOrCreate<boolean>(K_CHAT_CONNECTED, false);
AppStorage.setOrCreate<number>(K_CHAT_REV, 0);
AppStorage.setOrCreate<number>(K_CHAT_SCROLL_REV, 0);
}
// ===================== 读取 =====================
messages(): ChatMessage[] {
return this.msgs;
}
findMessage(id: number): ChatMessage | undefined {
for (let i = 0; i < this.msgs.length; i++) {
if (this.msgs[i].id === id) {
return this.msgs[i];
}
}
return undefined;
}
lastMessage(): ChatMessage | null {
if (this.msgs.length === 0) {
return null;
}
return this.msgs[this.msgs.length - 1];
}
isFresh(id: number): boolean {
return this.newIds.indexOf(id) >= 0;
}
hasMore(): boolean {
return this.hasEarlier;
}
isFetchingOlder(): boolean {
return this.loadingOlder;
}
isLoading(): boolean {
return AppStorage.get<boolean>(K_CHAT_LOADING) ?? false;
}
setLoading(v: boolean): void {
AppStorage.set<boolean>(K_CHAT_LOADING, v);
}
setStage(s: string): void {
AppStorage.set<string>(K_CHAT_STAGE, s);
}
setConnected(v: boolean): void {
AppStorage.set<boolean>(K_CHAT_CONNECTED, v);
}
sseActive(): boolean {
return this.sseActiveForTurn;
}
setSseActive(v: boolean): void {
this.sseActiveForTurn = v;
}
/** 聊天流里最后一个带附件的消息:宽屏进入 Split 时用它填充右栏 */
latestAttachment(): ChatAttachment | undefined {
for (let i = this.msgs.length - 1; i >= 0; i--) {
const a: ChatAttachment | undefined = this.msgs[i].attachment;
if (a !== undefined) {
return a;
}
}
return undefined;
}
// ===================== 列表变更 =====================
allocId(): number {
return this.nextId++;
}
/** 追加一条消息并播入场动画 */
pushNew(msg: ChatMessage): void {
this.msgs.push(msg);
this.markNew(msg.id);
}
/** 标记新消息,触发入场动画 */
markNew(msgId: number): void {
const arr: number[] = this.newIds.slice();
arr.push(msgId);
this.newIds = arr;
// 这里不切片也不广播:与拆分前一致,入场动画的开场交给紧随其后的
// refresh()(50ms 防抖后换新数组引用)那一次一起触发。
setTimeout(() => {
const idx: number = this.newIds.indexOf(msgId);
if (idx >= 0) {
const updated: number[] = this.newIds.slice();
updated.splice(idx, 1);
this.newIds = updated;
this.forceRefresh();
}
}, 250);
}
/**
* 取当前助手消息里名为 name 的未完成工具卡,没有就建一张。
* 顺带保证一定存在一条"未定稿的助手消息"来挂这些卡。
*/
ensureToolCall(name: string): ToolCallInfo {
const last: ChatMessage = this.ensureAssistant();
if (last.toolCalls === undefined) {
last.toolCalls = [];
}
for (let i = 0; i < last.toolCalls.length; i++) {
const t: ToolCallInfo = last.toolCalls[i];
// 只复用"仍在执行"的同名卡:同一轮里同名工具被多次调用时,
// 已完成的那张不能被后来的调用覆盖。
const st: string | undefined = t.status;
if (t.name === name && (st === undefined || st.length === 0 || st === 'running')) {
return t;
}
}
const created: ToolCallInfo = { name: name, args: '' };
last.toolCalls.push(created);
return created;
}
/**
* 保证存在一条"未定稿的助手消息",返回它。
* 聚合 reasoning 可能先于任何 delta 到达(非流式后端就只有这一条),
* 此时还没有"未完成的助手消息",必须新建一条,否则内容直接丢失。
*/
ensureAssistant(): ChatMessage {
const last: ChatMessage | null = this.lastMessage();
if (last !== null && last.role === 'assistant' && last.isFinal !== true) {
return last;
}
const msg: ChatMessage = {
id: this.allocId(),
role: 'assistant',
content: '',
isStreaming: true,
isFinal: false,
};
this.pushNew(msg);
return msg;
}
/** 流式/高频变更的通知信号:让 ChatStream 滚到底 */
requestScroll(): void {
const cur: number = AppStorage.get<number>(K_CHAT_SCROLL_REV) ?? 0;
AppStorage.set<number>(K_CHAT_SCROLL_REV, cur + 1);
}
/** 防抖刷新:合并高频 SSE delta,最多 ~20fps */
refresh(): void {
if (this.refreshTimer >= 0) {
return;
}
this.refreshTimer = setTimeout(() => {
this.refreshTimer = -1;
this.msgs = this.msgs.slice();
this.bump();
}, 50);
}
/** 强制立即刷新(用于状态切换等需要即时响应的场景) */
forceRefresh(): void {
if (this.refreshTimer >= 0) {
clearTimeout(this.refreshTimer);
this.refreshTimer = -1;
}
this.msgs = this.msgs.slice();
this.bump();
}
/** 明细数组不进 AppStorage,用一个自增版本号触发订阅组件重取 */
bump(): void {
const cur: number = AppStorage.get<number>(K_CHAT_REV) ?? 0;
AppStorage.set<number>(K_CHAT_REV, cur + 1);
}
cancelRefresh(): void {
if (this.refreshTimer >= 0) {
clearTimeout(this.refreshTimer);
this.refreshTimer = -1;
}
}
// ===================== 折叠开关 =====================
reasoningOpen(msgId: number): boolean {
const m: ChatMessage | undefined = this.findMessage(msgId);
return m !== undefined && m.reasoningOpen === true;
}
setReasoningOpen(msgId: number, open: boolean): void {
const m: ChatMessage | undefined = this.findMessage(msgId);
if (m !== undefined) {
m.reasoningOpen = open;
}
}
toolOpen(msgId: number, index: number): boolean {
const m: ChatMessage | undefined = this.findMessage(msgId);
if (m === undefined || m.toolCalls === undefined || index >= m.toolCalls.length) {
return false;
}
return m.toolCalls[index].open === true;
}
setToolOpen(msgId: number, index: number, open: boolean): void {
const m: ChatMessage | undefined = this.findMessage(msgId);
if (m !== undefined && m.toolCalls !== undefined && index < m.toolCalls.length) {
m.toolCalls[index].open = open;
}
}
// ===================== 历史 =====================
private parseHistory(obj: Record<string, Object>): ParsedHistory {
return parseHistoryPayload(obj, () => this.allocId());
}
async loadHistory(): Promise<void> {
try {
// 分段懒加载:首屏只拉最新 CHAT_PAGE_SIZE 条,向上滚动触顶再拉更早的。
const resp = await apiClient.getWithTimeout('/chat/history?limit=' + CHAT_PAGE_SIZE, 8000);
const obj: Record<string, Object> = JSON.parse(resp.body) as Record<string, Object>;
const parsed: ParsedHistory = this.parseHistory(obj);
// 首屏允许列表本来就是空的(全部加载失败/新会话):这里不做早退,
// 否则游标 lastSeq 永远建不起来,增量轮询也就起不来。
if (this.msgs.length === 0) {
this.msgs = parsed.msgs;
} else {
// 与本地未回显的消息按 seq 对账,而不是整表替换。
//
// 为什么:sync_required 触发的 reloadHistory 会与刚发出的 POST 竞争;
// 若历史快照里还没有这条 user 消息,整表替换会让它凭空消失
// (“客户端侧发出的消息不显示”)。
this.msgs = reconcileServerMsgs(this.msgs, parsed.msgs, false,
() => this.allocId());
}
this.offset = parsed.offset;
this.hasEarlier = parsed.hasMore;
// 增量游标:首屏全量后据 last_seq 初始化,后续只拿增量。
if (parsed.lastSeq > this.lastSeq) {
this.lastSeq = parsed.lastSeq;
}
this.forceRefresh();
this.requestScroll();
this.startPolling();
} catch (e) {
// ignore history load failure
}
}
/**
* 增量轮询:只拉 seq 更大的消息,再补一次尾部探测。
*
* 这是 jianf 说的「接口调用方式改变」——后端 /chat/history 早已提供
* after=<seq> 游标(commit 9711177),WebUI 前端据此 3s 轮询增量并 patch
* 视图。鸿蒙端一直只做首屏全量加载,于是**其他端/其他渠道发来的消息
* 永远进不来**(页面不会加载新的聊天信息)。
*
* 尾部探测不可省:工具调用与最终文本是**原地改写**已有 seq 的记录,
* 不会产生新 seq,单靠 after 拿不到这些更新。
*/
async pollIncremental(): Promise<void> {
if (this.polling) {
return;
}
this.polling = true;
try {
if (this.lastSeq <= 0) {
// 游标还没建立(首屏没跑或失败):退回全量,交给 loadHistory 建游标。
this.polling = false;
await this.loadHistory();
return;
}
const resp = await apiClient.getWithTimeout(
'/chat/history?after=' + this.lastSeq, 8000);
const obj: Record<string, Object> = JSON.parse(resp.body) as Record<string, Object>;
const parsed: ParsedHistory = this.parseHistory(obj);
let changed: boolean = false;
if (parsed.msgs.length > 0) {
this.msgs = reconcileServerMsgs(this.msgs, parsed.msgs, false,
() => this.allocId());
changed = true;
}
if (parsed.lastSeq > this.lastSeq) {
this.lastSeq = parsed.lastSeq;
}
// 尾部探测:拿最新一条做原地更新(工具卡/最终文本)。
try {
const tailResp = await apiClient.getWithTimeout('/chat/history?limit=1', 8000);
const tailObj: Record<string, Object> = JSON.parse(tailResp.body) as Record<string, Object>;
const tail: ParsedHistory = this.parseHistory(tailObj);
if (tail.msgs.length > 0) {
const before: number = this.msgs.length;
this.msgs = reconcileServerMsgs(this.msgs, tail.msgs, true,
() => this.allocId());
if (this.msgs.length !== before) {
changed = true;
}
}
} catch (e) {
// 尾部探测失败不影响增量结果
}
if (changed) {
this.forceRefresh();
}
} catch (e) {
// 轮询失败静默:下一拍会重试(SSE 仍在负责流式渲染)
} finally {
this.polling = false;
}
}
/** 起 3s 增量轮询(与 WebUI 的 chatTicker 同节奏)。重复调用无副作用。 */
startPolling(): void {
if (this.pollTimer >= 0) {
return;
}
this.pollTimer = setInterval(() => {
this.pollIncremental();
}, CHAT_POLL_MS);
}
stopPolling(): void {
if (this.pollTimer >= 0) {
clearInterval(this.pollTimer);
this.pollTimer = -1;
}
}
/**
* 向上翻页:拉 offset 之前的更早一页,前置到 messages 头部并保持滚动位置。
* 触顶(yOffset 接近 0)且有更早历史时由 onDidScroll 触发。
*/
async loadOlder(): Promise<void> {
if (this.loadingOlder || !this.hasEarlier) {
return;
}
this.loadingOlder = true;
try {
const before: number = this.offset;
if (before <= 0) {
this.hasEarlier = false;
return;
}
const resp = await apiClient.getWithTimeout(
'/chat/history?limit=' + CHAT_PAGE_SIZE + '&before=' + before, 8000);
const obj: Record<string, Object> = JSON.parse(resp.body) as Record<string, Object>;
const parsed: ParsedHistory = this.parseHistory(obj);
if (parsed.msgs.length === 0) {
this.hasEarlier = false;
return;
}
// 前置插入新页(更早的在前),追加到当前列表头部;id 用新分配的避免与新消息撞号
this.msgs = parsed.msgs.concat(this.msgs);
this.offset = parsed.offset;
this.hasEarlier = parsed.hasMore;
this.bump();
} catch (e) {
// 失败保留 hasEarlier,允许下次滚动重试
} finally {
this.loadingOlder = false;
}
}
/** sync_required:断线重连后服务端要求补拉历史 */
reloadHistory(): void {
this.loadHistory();
}
// ===================== SSE 连接 =====================
connect(): void {
const cur = connStore.getCurrentConnection();
if (cur === null) {
return;
}
// 增量轮询与 SSE 同时拉起:SSE 负责 token 级流式观感,
// 轮询负责「界面最终状态」——两者是两条腿,缺一不可
// (轮询没接是“其他端/其他渠道的新消息永远不出现”的直接原因)。
// 放在这里而不是只放在 loadHistory 末尾:首屏加载失败时也要能自愈。
this.startPolling();
this.sse.close();
this.sse.connect(cur, '/chat/events',
(ev: SseEvent) => {
applyChatSse(ev, this);
},
() => {
this.setConnected(false);
this.scheduleReconnect();
},
() => {
this.setConnected(true);
}).catch(() => {
this.setConnected(false);
this.scheduleReconnect();
});
}
scheduleReconnect(): void {
if (this.reconnectTimer >= 0) {
return;
}
this.reconnectTimer = setTimeout(() => {
this.reconnectTimer = -1;
this.connect();
}, SSE_RECONNECT_MS);
}
cancelReconnect(): void {
if (this.reconnectTimer >= 0) {
clearTimeout(this.reconnectTimer);
this.reconnectTimer = -1;
}
}
/** 页面消失:断线、停表,避免后台空转 */
disconnect(): void {
this.cancelReconnect();
this.stopPolling();
this.sse.close();
this.cancelRefresh();
}
}
export const chatStore: ChatStore = new ChatStore();

View File

@ -17,6 +17,18 @@ export const DEFAULT_WS_PORT: number = 9890;
/** 聊天历史首屏条数:只拉最新 N 条,向上滚动触顶再加载更早的 */ /** 聊天历史首屏条数:只拉最新 N 条,向上滚动触顶再加载更早的 */
export const CHAT_PAGE_SIZE: number = 40; export const CHAT_PAGE_SIZE: number = 40;
// ===== AppStorage 跨页面信号键 =====
//
// 未连接后端时的“入口可达性”靠这三个键串起来:聊天空态按钮 → 切主 Tab →
// 设置页打开连接二级页。不用组件回调是因为按钮与目标分属不同的 Swiper 子页,
// 中间还隔着 Index,逐层传回调会把两个无关页面耦在一起。
/** 当前是否已配置并激活后端连接(空态/入口的响应式判断) */
export const K_HAS_CONN: string = 'hasConn';
/** 外部请求切换主 Tab(-1 = 无请求),由 Index 监听 */
export const K_REQUESTED_TAB: string = 'requestedTab';
/** 请求设置页打开某个二级页(空串 = 无请求),由 SettingsPage 监听 */
export const K_SETTINGS_SUB: string = 'settingsSubRequest';
// ===== sakura / frost palette (style.css :root) ===== // ===== sakura / frost palette (style.css :root) =====
export const COLOR_SAKURA_100: string = 'rgba(10, 89, 247, 0.1)'; export const COLOR_SAKURA_100: string = 'rgba(10, 89, 247, 0.1)';
export const COLOR_SAKURA_200: string = 'rgba(10, 89, 247, 0.16)'; export const COLOR_SAKURA_200: string = 'rgba(10, 89, 247, 0.16)';

View File

@ -1,67 +1,8 @@
import { webSocket } from '@kit.NetworkKit'; import { webSocket } from '@kit.NetworkKit';
import { CapResult } from './BridgeCaps'; import { CapResult } from './BridgeCaps';
import { BridgeCmdHandler, bridgeHelloFrame, bridgeBindFrame, bridgeResultFrame,
// ===== 协议消息(与 remotedevice 插件对齐)===== bridgeDataStartFrame, bridgeDataEndFrame, bridgeEventFrame, bridgeStatusFrame,
bridgeChunkSlices } from './BridgeProtocol';
interface HelloDeviceInfo {
hostname: string;
platform: string;
arch: string;
os_release: string;
version: string;
cpus: number;
}
interface HelloDevice {
device_id: string;
name: string;
kind: string;
authorized: boolean;
caps: string[];
info: HelloDeviceInfo;
}
interface HelloMessage {
op: string;
device: HelloDevice;
}
interface BindMessage {
op: string;
device_id: string;
token: string;
}
export interface CmdReply {
op: string; // 'cmd_result'
req_id: string;
status: string;
output: string;
error: string;
}
interface DataStartMessage {
op: string;
req_id: string;
kind: string;
mime: string;
total: number;
chunk_size: number;
}
interface DataEndMessage {
op: string;
req_id: string;
status: string;
total?: number;
error?: string;
}
const CHUNK_SIZE: number = 8192;
// ===== 命令处理器回调 =====
// 返回 CapResult;二进制大结果通过 dataHandler 分块回传。
export type BridgeCmdHandler = (reqId: string, command: string) => Promise<CapResult>;
export class DeviceBridgeClient { export class DeviceBridgeClient {
private ws: webSocket.WebSocket = webSocket.createWebSocket(); private ws: webSocket.WebSocket = webSocket.createWebSocket();
@ -247,33 +188,12 @@ export class DeviceBridgeClient {
private sendHello(authorized: boolean): void { private sendHello(authorized: boolean): void {
this.lastAuthorized = authorized; this.lastAuthorized = authorized;
const info: HelloDeviceInfo = { this.send(bridgeHelloFrame(this.deviceId, this.name, this.kind, this.caps,
hostname: this.hostname, this.hostname, authorized));
platform: 'OpenHarmony',
arch: '',
os_release: '',
version: '1.1.1',
cpus: 0,
};
const device: HelloDevice = {
device_id: this.deviceId,
name: this.name,
kind: this.kind,
authorized: authorized,
caps: this.caps,
info: info,
};
const hello: HelloMessage = { op: 'hello', device: device };
this.send(JSON.stringify(hello));
} }
private sendBind(): void { private sendBind(): void {
const bind: BindMessage = { this.send(bridgeBindFrame(this.deviceId, this.token));
op: 'bind',
device_id: this.deviceId,
token: this.token,
};
this.send(JSON.stringify(bind));
} }
// ===== 命令处理 ===== // ===== 命令处理 =====
@ -327,6 +247,11 @@ export class DeviceBridgeClient {
} }
const handler: BridgeCmdHandler = this.cmdHandler; const handler: BridgeCmdHandler = this.cmdHandler;
handler(reqId, command).then((res: CapResult) => { handler(reqId, command).then((res: CapResult) => {
// res.chunked 时结果已由能力自己用二进制分块发完(如录像):
// 此时再发 cmd_result 会让网关把一条已完成请求与后续分块错配。
if (res.chunked === true) {
return;
}
this.sendResult(reqId, res.status, res.output, res.error); this.sendResult(reqId, res.status, res.output, res.error);
}).catch((e: Object) => { }).catch((e: Object) => {
this.sendResult(reqId, 'error', '', '本机能力执行失败,请稍后重试'); this.sendResult(reqId, 'error', '', '本机能力执行失败,请稍后重试');
@ -334,32 +259,16 @@ export class DeviceBridgeClient {
} }
sendResult(reqId: string, status: string, output: string, errMsg: string): void { sendResult(reqId: string, status: string, output: string, errMsg: string): void {
const result: CmdReply = { this.send(bridgeResultFrame(reqId, status, output, errMsg));
op: 'cmd_result',
req_id: reqId,
status: status,
output: output,
error: errMsg,
};
this.send(JSON.stringify(result));
} }
// ===== 二进制分块回传(协议与 GUI 客户端一致)===== // ===== 二进制分块回传(协议与 GUI 客户端一致)=====
sendDataChunked(reqId: string, kind: string, mime: string, bytes: Uint8Array): void { sendDataChunked(reqId: string, kind: string, mime: string, bytes: Uint8Array): void {
const startMsg: DataStartMessage = { this.send(bridgeDataStartFrame(reqId, kind, mime, bytes.byteLength));
op: 'cmd_data_start', const chunks: Uint8Array[] = bridgeChunkSlices(bytes);
req_id: reqId, for (let i = 0; i < chunks.length; i++) {
kind: kind, const ab: ArrayBuffer = chunks[i].buffer as ArrayBuffer;
mime: mime,
total: bytes.byteLength,
chunk_size: CHUNK_SIZE,
};
this.send(JSON.stringify(startMsg));
for (let off: number = 0; off < bytes.byteLength; off += CHUNK_SIZE) {
const end: number = Math.min(off + CHUNK_SIZE, bytes.byteLength);
const view: Uint8Array = bytes.slice(off, end);
const ab: ArrayBuffer = view.buffer as ArrayBuffer;
try { try {
this.ws.send(ab).catch(() => { this.ws.send(ab).catch(() => {
// ignore per-chunk failure; end frame reports error below // ignore per-chunk failure; end frame reports error below
@ -368,32 +277,15 @@ export class DeviceBridgeClient {
break; break;
} }
} }
const endMsg: DataEndMessage = { this.send(bridgeDataEndFrame(reqId));
op: 'cmd_data_end',
req_id: reqId,
status: 'ok',
};
this.send(JSON.stringify(endMsg));
} }
sendEvent(eventType: string, detail: string): void { sendEvent(eventType: string, detail: string): void {
const payload: Record<string, string> = { 'detail': detail }; this.send(bridgeEventFrame(this.deviceId, eventType, detail));
const msg: Record<string, Object> = {
'op': 'event',
'device_id': this.deviceId,
'type': eventType,
'payload': payload,
};
this.send(JSON.stringify(msg));
} }
sendStatus(status: string): void { sendStatus(status: string): void {
const msg: Record<string, Object> = { this.send(bridgeStatusFrame(this.deviceId, status));
'op': 'status',
'device_id': this.deviceId,
'status': status,
};
this.send(JSON.stringify(msg));
} }
send(text: string): void { send(text: string): void {

View File

@ -1,4 +1,5 @@
import { common } from '@kit.AbilityKit'; import { common } from '@kit.AbilityKit';
import { http } from '@kit.NetworkKit';
import { deviceBridge } from './DeviceBridge'; import { deviceBridge } from './DeviceBridge';
import { installCmdRouter, setBridgeAppContext } from './BridgeRouter'; import { installCmdRouter, setBridgeAppContext } from './BridgeRouter';
import { LOCAL_DEVICE_CAPS, shutdownSpeakerUse } from './BridgeCaps'; import { LOCAL_DEVICE_CAPS, shutdownSpeakerUse } from './BridgeCaps';
@ -24,7 +25,14 @@ function ensureBridgeStateTracking(): void {
}); });
} }
/** 把当前后端 HTTP 地址转换为同源设备桥 WebSocket 地址。 */ /**
* 把门户 HTTP 地址转换为同源设备桥 WebSocket 地址(**回退路径**)。
*
* 网关改造为子域反代后位于 devices.<基域名>,而基域名与子域标签都是**服务端
* 配置**,客户端拼不出来。正常路径是先调 discoverGateway() 问服务端;
* 本函数只在「服务端没有发现端点」(老版本 HomeAgent)时兜底,
* 保留旧部署的可用性。
*/
export function deviceGatewayUrl(base: string): string { export function deviceGatewayUrl(base: string): string {
let trimmed: string = base.trim(); let trimmed: string = base.trim();
while (trimmed.length > 0 && trimmed.charAt(trimmed.length - 1) === '/') { while (trimmed.length > 0 && trimmed.charAt(trimmed.length - 1) === '/') {
@ -50,6 +58,72 @@ export function deviceGatewayUrl(base: string): string {
* 应用进入前台后建立全局设备桥。它不再依赖用户先打开“设备”Tab, * 应用进入前台后建立全局设备桥。它不再依赖用户先打开“设备”Tab,
* 因而 screensue、clipboardsee 等前台能力从主页面加载后即可接收。 * 因而 screensue、clipboardsee 等前台能力从主页面加载后即可接收。
*/ */
/**
* 向门户询问设备网关的**权威地址**。
*
* 为什么必须问而不是自己拼:网关现在挂在 devices.<基域名> 子域上,基域名
* (webui.base_domain,默认 localhost)与子域标签(插件声明里可改)都在
* 服务端,客户端无从得知。服务端作答是唯一不会漂移的做法。
*
* 失败/老版本(404)不报错,返回空串让调用方回退到 deviceGatewayUrl()——
* 发现是增强而非必需。
*/
async function discoverGateway(portalUrl: string, apiKey: string): Promise<string> {
let base: string = portalUrl.trim();
if (base.length === 0) {
return '';
}
// 用户配置里可能填的是完整网关地址:截到门户根再拼发现路径
const cut: number = base.indexOf('/api/v1/');
if (cut >= 0) {
base = base.substring(0, cut);
}
while (base.length > 0 && base.charAt(base.length - 1) === '/') {
base = base.substring(0, base.length - 1);
}
try {
const r = await http.createHttp().request(base + '/api/v1/device/gateway', {
method: http.RequestMethod.GET,
header: { 'X-API-Key': apiKey } as Record<string, string>,
connectTimeout: 5000,
readTimeout: 5000,
});
if (r.responseCode !== 200) {
return '';
}
const body: string = typeof r.result === 'string' ? r.result : '';
const parsed: Record<string, Object> = JSON.parse(body) as Record<string, Object>;
// 服务端明确报告不可用(没有声明设备网关反代)时不返回地址,
// 让调用方回退,而不是拿着一个连不上的 URL 反复重连。
if (parsed['available'] !== true) {
return '';
}
// 优先**门户同源形态**(url_portal:同一 host、同一端口)。
//
// 原因:子域形态 devices.<基域名> 依赖 DNS 解析,而 *.localhost 只有
// 浏览器内置该特例(RFC 6761)—— 应用内 HTTP/WS 客户端走系统解析器,
// 通常解析不到。门户同源形态无任何 DNS 依赖,永远可解析。
const portal: string = parsed['url_portal'] as string;
if (portal !== undefined && portal !== null && portal.length > 0) {
return portal;
}
const url: string = parsed['url'] as string;
return url === undefined || url === null ? '' : url;
} catch (e) {
// 网络失败 / 老版本无此端点:静默回退
return '';
}
}
/** 解析设备桥最终使用的网关地址:优先服务端发现,回退同源推导。 */
async function resolveGatewayUrl(portalUrl: string, apiKey: string): Promise<string> {
const discovered: string = await discoverGateway(portalUrl, apiKey);
if (discovered.length > 0) {
return discovered;
}
return deviceGatewayUrl(portalUrl);
}
export async function startForegroundBridge(context: common.UIAbilityContext): Promise<void> { export async function startForegroundBridge(context: common.UIAbilityContext): Promise<void> {
foregroundActive = true; foregroundActive = true;
setBridgeAppContext(context); setBridgeAppContext(context);
@ -67,8 +141,9 @@ export async function startForegroundBridge(context: common.UIAbilityContext): P
const generation: number = bridgeGeneration; const generation: number = bridgeGeneration;
const deviceId: string = connStore.ensureDeviceId(); const deviceId: string = connStore.ensureDeviceId();
try { try {
const gatewayUrl: string = await resolveGatewayUrl(cur.url, cur.apiKey);
await deviceBridge.connect( await deviceBridge.connect(
deviceGatewayUrl(cur.url), cur.apiKey, deviceId, gatewayUrl, cur.apiKey, deviceId,
LOCAL_DEVICE_CAPS, 'ohos-phone', connStore.getDeviceAuth(), connStore.getDeviceName()); LOCAL_DEVICE_CAPS, 'ohos-phone', connStore.getDeviceAuth(), connStore.getDeviceName());
if (!foregroundActive || generation !== bridgeGeneration) { if (!foregroundActive || generation !== bridgeGeneration) {
deviceBridge.disconnect(); deviceBridge.disconnect();

View File

@ -0,0 +1,73 @@
/**
* 设备页的纯逻辑:本机 device_id 兜底与在线设备列表解析。
*
* 从 pages/DevicePage.ets 抽出(非 UI,可被其它页面/桥复用)。
*/
import { DeviceInfo } from '../model/Model';
import { connStore } from './ConnStore';
// ===== 二级页面路由 id(页面与一级入口列表共用)=====
export const SUB_NONE: string = '';
export const SUB_LOCAL: string = 'local';
export const SUB_CAPS: string = 'caps';
export const SUB_GATEWAY: string = 'gateway';
export const SUB_LIST: string = 'list';
/**
* 本机 device_id:桥里已有就用桥的,其次读持久化,都没有则生成一个并落盘。
* 生成后必须持久化,否则每次冷启动换 id,网关侧会累积成一堆幽灵设备。
*
* 判定顺序与原 DevicePage.aboutToAppear 一致:桥的 id 优先于持久化的 id。
*/
export function resolveDeviceId(bridgeId: string): string {
let id: string = bridgeId;
if (id.length === 0) {
id = connStore.getDeviceId();
}
if (id.length === 0) {
id = 'ohos-' + Date.now().toString(36);
try {
connStore.saveDeviceId(id);
} catch (e) {
// ignore persist failure
}
}
return id;
}
/**
* 解析 /device/online 响应体。
*
* apiClient 已自动前置 /api/v1,调用方只写其后的部分
* (否则会拼成 /api/v1/api/v1/device/online 并 404)。
*/
export function parseOnlineDevices(parsed: Record<string, Object>): DeviceInfo[] {
const devs: Object = parsed['devices'];
const list: DeviceInfo[] = [];
if (devs === undefined || devs === null) {
return list;
}
const arr: Object[] = devs as Object[];
for (let i = 0; i < arr.length; i++) {
const d: Record<string, Object> = arr[i] as Record<string, Object>;
const capsArr: Object = d['caps'];
const caps: string[] = [];
if (capsArr !== undefined && capsArr !== null) {
const cArr: Object[] = capsArr as Object[];
for (let j = 0; j < cArr.length; j++) {
caps.push(cArr[j] as string);
}
}
const info: DeviceInfo = {
deviceId: d['device_id'] as string ?? '',
name: d['name'] as string ?? '',
kind: d['kind'] as string ?? '',
online: true,
authorized: d['authorized'] as boolean ?? false,
caps: caps,
};
list.push(info);
}
return list;
}

View File

@ -0,0 +1,282 @@
/**
* Markdown 解析器(无 UI 依赖)。
*
* 从 components/StaticMarkdown.ets 抽出:解析与渲染分家后,
* 解析规则可以单独被复用/测试,渲染组件也回到可读长度。
*
* 覆盖:标题、段落、代码围栏、无序/有序列表、引用块、分隔线、表格,
* 以及行内的粗体/斜体/行内代码/链接。
*/
// ── Types ──────────────────────────────────────────────────────────────────────
export interface MdBlock {
type: string; // 'heading' | 'code' | 'list' | 'ol' | 'blockquote' | 'hr' | 'table' | 'para'
level?: number;
items?: string[];
text?: string;
lang?: string;
codeLines?: string[];
headers?: string[];
rows?: string[][];
}
export interface MdSpan {
text: string;
bold?: boolean;
italic?: boolean;
code?: boolean;
link?: boolean;
linkUrl?: string;
}
// ── Inline parser ──────────────────────────────────────────────────────────────
export function parseInline(text: string): MdSpan[] {
const spans: MdSpan[] = [];
let i: number = 0;
while (i < text.length) {
// Inline code (backtick)
if (text[i] === '`') {
const end: number = text.indexOf('`', i + 1);
if (end > i) {
spans.push({ text: text.substring(i + 1, end), code: true });
i = end + 1;
continue;
}
}
// Bold: **text**
if (text[i] === '*' && i + 1 < text.length && text[i + 1] === '*') {
const end: number = text.indexOf('**', i + 2);
if (end > i + 1) {
spans.push({ text: text.substring(i + 2, end), bold: true });
i = end + 2;
continue;
}
}
// Italic: *text* (single asterisk)
if (text[i] === '*' && (i + 1 >= text.length || text[i + 1] !== '*')) {
const end: number = text.indexOf('*', i + 1);
if (end > i) {
spans.push({ text: text.substring(i + 1, end), italic: true });
i = end + 1;
continue;
}
}
// Link: [text](url)
if (text[i] === '[') {
const cb: number = text.indexOf(']', i + 1);
if (cb > i && cb + 1 < text.length && text[cb + 1] === '(') {
const cp: number = text.indexOf(')', cb + 2);
if (cp > cb + 1) {
spans.push({ text: text.substring(i + 1, cb), link: true, linkUrl: text.substring(cb + 2, cp) });
i = cp + 1;
continue;
}
}
}
// Plain run
let j: number = i + 1;
while (j < text.length && text[j] !== '`' && text[j] !== '*' && text[j] !== '[') {
j++;
}
spans.push({ text: text.substring(i, j) });
i = j;
}
return spans;
}
// ── Block parser helpers ───────────────────────────────────────────────────────
function isHr(line: string): boolean {
if (line.length < 3) {
return false;
}
const ch: string = line[0];
if (ch !== '-' && ch !== '*' && ch !== '_') {
return false;
}
for (let k = 0; k < line.length; k++) {
if (line[k] !== ch) {
return false;
}
}
return true;
}
function isOlStart(line: string): boolean {
if (line.length < 3) {
return false;
}
let k: number = 0;
while (k < line.length && line[k] >= '0' && line[k] <= '9') {
k++;
}
return k > 0 && k + 1 < line.length && line[k] === '.' && line[k + 1] === ' ';
}
function isTableSep(line: string): boolean {
if (!line.includes('-')) {
return false;
}
for (let k = 0; k < line.length; k++) {
const c: string = line[k];
if (c !== '|' && c !== '-' && c !== ':' && c !== ' ' && c !== '\t') {
return false;
}
}
return true;
}
/** 表格行 → 单元格数组(去掉首尾空串产生的空单元格)。 */
function parseTableRow(row: string): string[] {
const cells: string[] = [];
const parts: string[] = row.split('|');
for (let p = 0; p < parts.length; p++) {
const c: string = parts[p].trim();
if (c.length > 0) {
cells.push(c);
}
}
return cells;
}
// ── Block parser ───────────────────────────────────────────────────────────────
export function parseBlocks(content: string): MdBlock[] {
if (content.length === 0) {
return [];
}
const lines: string[] = content.split('\n');
const blocks: MdBlock[] = [];
let i: number = 0;
while (i < lines.length) {
const line: string = lines[i];
// Empty line
if (line.trim().length === 0) {
i++;
continue;
}
// Code fence
if (line.startsWith('```')) {
const langEnd: number = line.indexOf('`', 3);
const lang: string = langEnd > 3 ? line.substring(3, langEnd).trim() : '';
const codeLines: string[] = [];
i++;
while (i < lines.length && !lines[i].trimStart().startsWith('```')) {
codeLines.push(lines[i]);
i++;
}
if (i < lines.length) {
i++;
}
blocks.push({ type: 'code', lang: lang, codeLines: codeLines });
continue;
}
// Heading
if (line.startsWith('#')) {
let level: number = 0;
while (level < line.length && line[level] === '#') {
level++;
}
if (level <= 6 && level < line.length && line[level] === ' ') {
blocks.push({ type: 'heading', level: level, text: line.substring(level + 1).trim() });
i++;
continue;
}
}
// Horizontal rule
if (isHr(line.trim())) {
blocks.push({ type: 'hr' });
i++;
continue;
}
// Unordered list
if ((line.startsWith('- ') || line.startsWith('* ')) && !line.startsWith('- [')) {
const items: string[] = [];
while (i < lines.length && (lines[i].startsWith('- ') || lines[i].startsWith('* ')) && !lines[i].startsWith('- [')) {
items.push(lines[i].substring(2));
i++;
}
blocks.push({ type: 'list', items: items });
continue;
}
// Ordered list
if (isOlStart(line)) {
const items: string[] = [];
while (i < lines.length && isOlStart(lines[i])) {
const dotIdx: number = lines[i].indexOf('. ');
items.push(lines[i].substring(dotIdx + 2));
i++;
}
blocks.push({ type: 'ol', items: items });
continue;
}
// Blockquote
if (line.startsWith('> ')) {
const qLines: string[] = [];
while (i < lines.length && lines[i].startsWith('> ')) {
qLines.push(lines[i].substring(2));
i++;
}
blocks.push({ type: 'blockquote', text: qLines.join('\n') });
continue;
}
// Table
if (line.trimStart().startsWith('|') && !isTableSep(line)) {
const tLines: string[] = [];
while (i < lines.length && lines[i].trimStart().startsWith('|')) {
tLines.push(lines[i]);
i++;
}
if (tLines.length >= 2) {
const headers: string[] = parseTableRow(tLines[0]);
const rows: string[][] = [];
for (let k = 1; k < tLines.length; k++) {
if (!isTableSep(tLines[k].trim())) {
rows.push(parseTableRow(tLines[k]));
}
}
if (headers.length > 0) {
blocks.push({ type: 'table', headers: headers, rows: rows });
}
}
continue;
}
// Paragraph: collect consecutive non-special lines
{
const paraLines: string[] = [];
while (i < lines.length) {
const ln: string = lines[i];
if (ln.trim().length === 0) {
break;
}
if (ln.startsWith('```') || ln.startsWith('#') || isHr(ln.trim())) {
break;
}
if (ln.startsWith('- ') || ln.startsWith('* ') || isOlStart(ln) || ln.startsWith('> ')) {
break;
}
if (ln.trimStart().startsWith('|') && !isTableSep(ln)) {
break;
}
paraLines.push(ln);
i++;
}
if (paraLines.length > 0) {
blocks.push({ type: 'para', text: paraLines.join('\n') });
}
}
}
return blocks;
}

View File

@ -0,0 +1,174 @@
/**
* 插件数据获取(无 UI 依赖)。
*
* 从 pages/PluginsPage.ets 抽出:三处接口的取数、合并口径与字段解析
* 都放在这里,页面只负责把结果落到 @State。
*
* 数据源对齐 WebGUI renderPlugins:
* - GET /kernel → plugins[{name,loaded}](含全部内置插件)+ tools(按 plugin 归属)
* - GET /plugins → 已安装外部插件元数据(version/description 等)
* - GET /plugins/disabled → {disabled:[{name,...}]}
* 三方按名称合并去重排序。
*/
import { apiClient } from './ApiClient';
import { PluginRow, PluginDetail, emptyPluginDetail } from '../model/Model';
/** 拉取并合并插件列表;失败时抛错,由调用方转成人话提示。 */
export async function fetchPluginRows(): Promise<PluginRow[]> {
// ---- kernel: loaded plugins + tool ownership ----
const loadedMap: Map<string, boolean> = new Map<string, boolean>();
const toolsByPlugin: Map<string, string[]> = new Map<string, string[]>();
const kResp = await apiClient.getWithTimeout('/kernel', 12000);
const kernelObj: Record<string, Object> = JSON.parse(kResp.body) as Record<string, Object>;
const kpRaw: Object | undefined = kernelObj['plugins'];
if (kpRaw !== undefined && kpRaw !== null) {
const kpArr: Object[] = kpRaw as Object[];
for (let i = 0; i < kpArr.length; i++) {
const item: Record<string, Object> = kpArr[i] as Record<string, Object>;
const n: string = item['name'] as string ?? '';
if (n.length === 0) {
continue;
}
loadedMap.set(n, item['loaded'] as boolean ?? true);
}
}
const tRaw: Object | undefined = kernelObj['tools'];
if (tRaw !== undefined && tRaw !== null) {
const tArr: Object[] = tRaw as Object[];
for (let i = 0; i < tArr.length; i++) {
const item: Record<string, Object> = tArr[i] as Record<string, Object>;
const tn: string = item['name'] as string ?? '';
const owner: string = item['plugin'] as string ?? '';
if (tn.length === 0 || owner.length === 0) {
continue;
}
let list: string[] | undefined = toolsByPlugin.get(owner);
if (list === undefined) {
list = [];
toolsByPlugin.set(owner, list);
}
// 每插件最多展示 8 个工具名,避免卡片过长
if (list.length < 8) {
list.push(tn);
}
}
}
// ---- installed external plugins metadata ----
const externalMeta: Map<string, Record<string, Object>> = new Map<string, Record<string, Object>>();
try {
const pResp = await apiClient.getWithTimeout('/plugins', 10000);
const bodyTrim = pResp.body.trim();
let arr: Object[] = [];
if (bodyTrim.length > 0 && bodyTrim.charAt(0) === '[') {
arr = JSON.parse(pResp.body) as Object[];
} else {
const obj: Record<string, Object> = JSON.parse(pResp.body) as Record<string, Object>;
const rawList: Object = obj['plugins'] ?? obj['data'];
if (rawList !== undefined && rawList !== null) {
arr = rawList as Object[];
}
}
for (let i = 0; i < arr.length; i++) {
const item: Record<string, Object> = arr[i] as Record<string, Object>;
const n: string = item['name'] as string ?? '';
if (n.length > 0) {
externalMeta.set(n, item);
}
}
} catch (e) {
// 外部列表失败不阻塞内置展示
}
// ---- disabled list ----
const disabledNames: Set<string> = new Set<string>();
try {
const dResp = await apiClient.getWithTimeout('/plugins/disabled', 8000);
const dObj: Record<string, Object> = JSON.parse(dResp.body) as Record<string, Object>;
const dArr: Object | undefined = dObj['disabled'];
if (dArr !== undefined && dArr !== null) {
const items: Object[] = dArr as Object[];
for (let di = 0; di < items.length; di++) {
const dItem: Record<string, Object> = items[di] as Record<string, Object>;
const dn: string = dItem['name'] as string ?? '';
if (dn.length > 0) {
disabledNames.add(dn);
}
}
}
} catch (e) {
// disabled endpoint may not exist; ignore
}
// ---- merge: allNames sorted(与 GUI 一致)----
const allNames: Set<string> = new Set<string>();
loadedMap.forEach((v: boolean, k: string) => {
allNames.add(k);
});
externalMeta.forEach((v: Record<string, Object>, k: string) => {
allNames.add(k);
});
disabledNames.forEach((n: string) => {
allNames.add(n);
});
const names: string[] = Array.from(allNames);
names.sort();
const rows: PluginRow[] = [];
for (let i = 0; i < names.length; i++) {
const name: string = names[i];
const meta: Record<string, Object> | undefined = externalMeta.get(name);
const tools: string[] | undefined = toolsByPlugin.get(name);
const row: PluginRow = {
name: name,
loaded: loadedMap.get(name) ?? false,
disabled: disabledNames.has(name),
external: externalMeta.has(name),
version: meta !== undefined ? meta['version'] as string ?? '' : '',
description: meta !== undefined ? meta['description'] as string ?? '' : '',
tools: tools,
};
rows.push(row);
}
return rows;
}
function strArray(raw: Object | undefined): string[] {
const out: string[] = [];
if (raw === undefined || raw === null) {
return out;
}
const arr: Object[] = raw as Object[];
for (let i = 0; i < arr.length; i++) {
const s: string = arr[i] as string ?? '';
if (s.length > 0) {
out.push(s);
}
}
return out;
}
/**
* GET /plugins/{name} —— 后端返回插件清单字段。
* WebGUI 只是把它 JSON.stringify 进 <pre>,这里逐字段结构化展示。
* 内置插件不在 /plugins 里,取不到详情时由调用方退回列表已有信息。
*/
export async function fetchPluginDetail(name: string): Promise<PluginDetail> {
const resp = await apiClient.getWithTimeout('/plugins/' + name, 10000);
const o: Record<string, Object> = JSON.parse(resp.body) as Record<string, Object>;
const d: PluginDetail = emptyPluginDetail();
d.name = o['name'] as string ?? name;
d.version = o['version'] as string ?? '';
d.description = o['description'] as string ?? '';
d.author = o['author'] as string ?? '';
d.license = o['license'] as string ?? '';
d.homepage = o['homepage'] as string ?? '';
d.repository = o['repository'] as string ?? '';
d.entry = o['entry'] as string ?? '';
d.minVersion = o['min_version'] as string ?? '';
d.deprecated = o['deprecated'] as boolean ?? false;
d.tags = strArray(o['tags']);
d.files = strArray(o['files']);
return d;
}

View File

@ -0,0 +1,78 @@
/**
* 插件状态展示口径(纯函数,无 UI 依赖)。
*
* 从 pages/PluginsPage.ets 抽出:列表行与详情页共用同一套状态判定/文案/配色,
* 抽成模块后两处不会再各写一份。
*
* 状态口径与 WebGUI 一致:已加载绿 / 禁用待生效黄 / 已禁用红 / 未加载灰。
*/
import { PluginRow } from '../model/Model';
/** 'loaded' | 'pending' | 'disabled' | 'notloaded' */
export function pluginStatusOf(plugin: PluginRow): string {
if (plugin.loaded && !plugin.disabled) {
return 'loaded'; // 已加载
}
if (plugin.loaded && plugin.disabled) {
return 'pending'; // 运行中(禁用待生效)
}
if (plugin.disabled) {
return 'disabled'; // 已禁用
}
return 'notloaded'; // 未加载
}
export function pluginStatusText(plugin: PluginRow): string {
const s: string = pluginStatusOf(plugin);
if (s === 'loaded') {
return '已加载';
}
if (s === 'pending') {
return '待生效';
}
if (s === 'disabled') {
return '已禁用';
}
return '未加载';
}
/** 状态点颜色;未加载态用主题里的弱化色(mutedColor 由调用方从 palette 取)。 */
export function pluginStatusColor(plugin: PluginRow, mutedColor: string): string {
const s: string = pluginStatusOf(plugin);
if (s === 'loaded') {
return '#17A964';
}
if (s === 'pending') {
return '#D99A2B';
}
if (s === 'disabled') {
return '#E84026';
}
return mutedColor;
}
/** 列表行副标题:状态 + 内置/外部 + 工具数,一行灰字,不用徽标 */
export function pluginRowSubtitle(plugin: PluginRow): string {
const parts: string[] = [];
parts.push(pluginStatusText(plugin));
parts.push(plugin.external ? '外部' : '内置');
if (plugin.tools !== undefined && plugin.tools.length > 0) {
parts.push(plugin.tools.length.toString() + ' 工具');
}
return parts.join(' · ');
}
/** 详情页状态行:状态 + 内置/外部 + 已废弃 + 工具数(顺序与原实现一致) */
export function pluginDetailStatusLine(row: PluginRow, deprecated: boolean): string {
const parts: string[] = [];
parts.push(pluginStatusText(row));
parts.push(row.external ? '外部' : '内置');
if (deprecated) {
parts.push('已废弃');
}
if (row.tools !== undefined && row.tools.length > 0) {
parts.push(row.tools.length.toString() + ' 个工具');
}
return parts.join(' · ');
}

View File

@ -0,0 +1,182 @@
/**
* screensue 载荷解析与 HTML 渲染(无 UI 依赖)。
*
* 从 BridgeCaps.ets 抽出:加进 HTML 检测/编码后那个文件超过 520 行,
* 超出工程「单文件 ≤400 行」的约定;而「screensue 内容怎么解析、怎么渲染」
* 与「设备能力怎么实现」本就是两件事。
*/
import { util } from '@kit.ArkTS';
// ===== screensue 内容解析 =====
// 服务端协议: screensue [秒] <内容>;0=常驻。
export interface ScreensuePayload {
duration: number; // 秒;0 表示常驻直到用户关闭
content: string;
}
export function parseScreensue(rawArgs: string): ScreensuePayload {
const p: ScreensuePayload = { duration: 5, content: '' };
const leadingSpaces: RegExp = new RegExp('^\\s+');
const firstSpace: RegExp = new RegExp('\\s');
let rest: string = rawArgs.replace(leadingSpaces, '');
const splitAt: number = rest.search(firstSpace);
if (splitAt > 0) {
const first: string = rest.substring(0, splitAt);
const digits: RegExp = new RegExp('^\\d+$');
if (digits.test(first)) {
p.duration = Math.min(parseInt(first, 10), 86400);
rest = rest.substring(splitAt).replace(leadingSpaces, '');
}
}
p.content = rest;
return p;
}
/**
* 判断 agent 下发的 screensue 内容是不是 HTML。
*
* 服务端两侧协议都允许 HTML(localuse 的 local_screensue 在 Linux 用 browsh/w3m
* 渲染 HTML;remotedevice 的工具说明写的就是「显示内容/HTML」)。
*
* ★ 判据必须容忍前导杂质:实测 agent 常把整段文档连引号一起传进来
* (`'<html>…</html>'`),而"首个非空字符必须是 '<'"的旧判据直接判否、
* 退回纯文本渲染,用户看到的就是满屏标签源码(截图取证)。
*
* 所以这里扫到第一个「像标签开头」的 '<',不要求它在开头;但只有后面紧根
* 字母或 '/' 时才认,避免把 "a < b" 这类文本里的比较符当标签。
*/
export function looksLikeHtml(content: string): boolean {
return findHtmlStart(content) >= 0;
}
/** 找到第一个「像标签开头」的 '<';没有则 -1。 */
function findHtmlStart(content: string): number {
for (let i = 0; i < content.length; i++) {
if (content.charAt(i) !== '<') {
continue;
}
const next: string = i + 1 < content.length ? content.charAt(i + 1) : '';
if (next === '/') {
const after: string = i + 2 < content.length ? content.charAt(i + 2) : '';
if (isAsciiLetter(after)) {
return i;
}
continue;
}
if (isAsciiLetter(next)) {
return i;
}
}
return -1;
}
function isAsciiLetter(ch: string): boolean {
if (ch.length === 0) {
return false;
}
const c: number = ch.charCodeAt(0);
return (c >= 65 && c <= 90) || (c >= 97 && c <= 122);
}
/**
* 取出真正的 HTML 片段:剥掉 agent 误带的包裹引号,再从头截到第一个标签。
*
* 剥引号是必须的:不剥的话那个孤立的 `'` 会被 Web 当正文渲染出来
* (截图上第一行就是它),而且它还会把后续判据带偏。返回 '' 表示不是 HTML。
*/
export function screensueHtmlDocument(content: string): string {
let body: string = content.trim();
// 反复剥成对的包裹引号(agent 把整段 HTML 当命令参数传时的常见形态)。
while (body.length >= 2) {
const first: string = body.charAt(0);
const last: string = body.charAt(body.length - 1);
if ((first === '\'' && last === '\'') || (first === '"' && last === '"')) {
body = body.substring(1, body.length - 1).trim();
continue;
}
break;
}
const idx: number = findHtmlStart(body);
if (idx < 0) {
return '';
}
if (idx > 0) {
body = body.substring(idx);
}
return body;
}
/**
* 把 screensue 内容编成可直接交给 Web 组件 `loadData` 的 base64。
*
* 为什么必须上 Web(不再用 RichText):RichText 只认极小标签子集,
* 对 <style>、CSS 动画、内联 SVG 一律不渲染 —— 实测 agent 推的是完整
* HTML 文档(含 @keyframes 与 <svg>),RichText 下只能看到源码。用户明确要求引入 webview。
*
* 为什么用 base64 而不是明文 loadData:encoding 非 base64 时按 URL 规则转义,
* 一个几 KB 的完整文档会撞上长度/转义问题;base64 是整篇加载的推荐方式,
* 中文与引号、'#' 也不会被二次转义(自己手写 UTF-8 编码,见 base64Utf8)。
*
* 片段(非完整文档)补一层 shell:加 <meta viewport> 让窄屏排版正确,
* 并注入主题前景色,避免深色主题下黑字不可见。返回 '' 表示不是 HTML(走纯文本渲染)。
*/
export function screensueWebData(content: string, dark: boolean): string {
const fragment: string = screensueHtmlDocument(content);
if (fragment.length === 0) {
return '';
}
if (hasHtmlShell(fragment)) {
// 已是完整文档:不再包壳,也不注入颜色(由页面自带样式决定)。
return base64Utf8(fragment);
}
const fg: string = dark ? '#E8ECF4' : '#1B2430';
const wrapped: string = '<!DOCTYPE html><html><head><meta charset="utf-8">'
+ '<meta name="viewport" content="width=device-width,initial-scale=1">'
+ '<style>html,body{margin:0;padding:0}'
+ 'body{padding:10px;color:' + fg + ';font-family:sans-serif;font-size:16px;'
+ 'line-height:1.6;word-break:break-word;-webkit-text-size-adjust:100%}'
+ 'img,svg,video{max-width:100%;height:auto}</style></head><body>'
+ fragment + '</body></html>';
return base64Utf8(wrapped);
}
/** 内容是否已是完整 HTML 文档(有 <html> 或 <!DOCTYPE>),不必再包壳。 */
function hasHtmlShell(s: string): boolean {
const head: string = s.substring(0, 400).toLowerCase();
return head.indexOf('<html') >= 0 || head.indexOf('<!doctype') >= 0;
}
/**
* UTF-8 字符串 → base64。
*
* 不能把 UTF-16 码元直接交给 Base64Helper:那样中文会变成乱码。
* 这里手写 UTF-8 字节序列(按码点,含代理对合成)后再编码。
*/
export function base64Utf8(s: string): string {
const bytes: number[] = [];
for (let i = 0; i < s.length; i++) {
let code: number = s.charCodeAt(i);
// 代理对(emoji 等)合成成一个码点。
if (code >= 0xD800 && code <= 0xDBFF && i + 1 < s.length) {
const next: number = s.charCodeAt(i + 1);
if (next >= 0xDC00 && next <= 0xDFFF) {
code = ((code - 0xD800) << 10) + (next - 0xDC00) + 0x10000;
i++;
}
}
if (code < 0x80) {
bytes.push(code);
} else if (code < 0x800) {
bytes.push(0xC0 | (code >> 6), 0x80 | (code & 0x3F));
} else if (code < 0x10000) {
bytes.push(0xE0 | (code >> 12), 0x80 | ((code >> 6) & 0x3F), 0x80 | (code & 0x3F));
} else {
bytes.push(0xF0 | (code >> 18), 0x80 | ((code >> 12) & 0x3F),
0x80 | ((code >> 6) & 0x3F), 0x80 | (code & 0x3F));
}
}
const helper: util.Base64Helper = new util.Base64Helper();
return helper.encodeToStringSync(new Uint8Array(bytes));
}

View File

@ -0,0 +1,313 @@
/**
* 设置数据模型与纯解析逻辑(无 UI 依赖)。
*
* 从 pages/SettingsPage.ets 抽出:/settings 的响应解析、key 分区归类、
* 分页取项都是纯函数,页面只负责把结果落到 @State。
*/
/** One settings key card rendered in the editor list. */
export interface SettingEntry {
key: string;
displayName: string;
description: string;
type: string; // bool | int | duration | select | password | text | string
options: string[];
value: string; // raw string value as stored by backend
dirty: boolean;
}
export interface SettingsSection {
id: string;
title: string;
count: number;
}
export interface SettingMetaRaw {
key: string;
type: string;
displayName: string;
description: string;
category: string;
options: string[];
}
export const SETTINGS_PAGE_SIZE: number = 40;
/**
* 二级页面标识。
* 一级入口列表(components/SettingsRootEntries.ets)与页面路由表分开成文件后,
* 这些 id 必须只有一个来源 —— 否则改一处就会"点了没反应"。
*/
export const SUB_NONE: string = '';
export const SUB_STATUS: string = 'status';
export const SUB_CONNECTIONS: string = 'connections';
export const SUB_APPEARANCE: string = 'appearance';
export const SUB_BACKEND: string = 'backend';
export const SUB_SECTION: string = 'section';
/** /settings 响应解析结果 */
export interface ParsedSettings {
meta: Record<string, SettingMetaRaw>;
values: Record<string, string>;
}
/** 分区统计结果 */
export interface SectionStats {
sections: SettingsSection[];
/** plugin.* 配置项总数(编辑入口在插件详情页,这里只用于提示去向) */
pluginKeyCount: number;
/** 涉及的插件个数 */
pluginConfigCount: number;
}
/**
* 解析 GET /settings 响应:meta 定义 + 当前值。
* 值统一转成字符串(后端可能给 bool/number/嵌套对象)。
*/
export function parseSettingsPayload(body: string): ParsedSettings {
const obj: Record<string, Object> = JSON.parse(body) as Record<string, Object>;
const metaStore: Record<string, SettingMetaRaw> = {};
const valuesStore: Record<string, string> = {};
const rawMeta: Object | undefined = obj['meta'];
if (rawMeta !== undefined && rawMeta !== null) {
const mObj: Record<string, Object> = rawMeta as Record<string, Object>;
for (const mk of Object.keys(mObj)) {
const item: Record<string, Object> = mObj[mk] as Record<string, Object>;
const optsArr: Object | undefined = item['options'];
const opts: string[] = [];
if (optsArr !== undefined && optsArr !== null) {
const oa: Object[] = optsArr as Object[];
for (let i = 0; i < oa.length; i++) {
opts.push(oa[i] as string);
}
}
const meta: SettingMetaRaw = {
key: item['key'] as string ?? mk,
type: item['type'] as string ?? 'string',
displayName: item['display_name'] as string ?? '',
description: item['description'] as string ?? '',
category: item['category'] as string ?? '',
options: opts,
};
metaStore[mk] = meta;
}
}
const rawVals: Object | undefined = obj['settings'];
if (rawVals !== undefined && rawVals !== null) {
const vObj: Record<string, Object> = rawVals as Record<string, Object>;
for (const vk of Object.keys(vObj)) {
if (vk.length === 0) {
continue;
}
const val: Object = vObj[vk];
let strVal: string;
if (typeof val === 'string') {
strVal = val as string;
} else if (typeof val === 'boolean' || typeof val === 'number') {
strVal = String(val);
} else {
strVal = JSON.stringify(val);
}
valuesStore[vk] = strVal;
}
}
const parsed: ParsedSettings = { meta: metaStore, values: valuesStore };
return parsed;
}
export function metaCategory(metaStore: Record<string, SettingMetaRaw>, key: string): string {
const m: SettingMetaRaw | undefined = metaStore[key];
return m !== undefined && m.category.length > 0 ? m.category : '';
}
export function categoryTitle(cat: string): string {
const map: Record<string, string> = {
'agent': '智能体',
'daemon': '守护进程',
'llm': '大模型',
'sources': '数据源',
'input': '输入',
'paths': '路径',
'resources': '资源',
'defaults': '默认值',
'snapshot': '快照',
'rollback': '回滚',
};
const t: string | undefined = map[cat];
return t !== undefined ? t : cat;
}
/**
* 把 key 归到分区:
* - core.* → 'core/<category>',展示在「核心」二级页下
* - plugin.* → 'plugin/<name>',仅用于计数;实际编辑在插件详情页里,
* 不在这里列出(否则同一批 key 会有两个入口)
* - 其余 → 'other'
*/
export function buildSections(
valuesStore: Record<string, string>, metaStore: Record<string, SettingMetaRaw>): SectionStats {
const ids: string[] = [];
const counts: Record<string, number> = {};
const titles: Record<string, string> = {};
let pluginKeys: number = 0;
const plugNames: string[] = [];
for (const key of Object.keys(valuesStore)) {
if (key.startsWith('plugin.')) {
// 插件配置不在这里列:它属于插件本身,入口在「插件 → 详情 → 插件配置」。
// 这里只统计,用于提示有多少项在那边。
pluginKeys = pluginKeys + 1;
const rest: string = key.substring('plugin.'.length);
const dot: number = rest.indexOf('.');
const plugName: string = dot > 0 ? rest.substring(0, dot) : rest;
if (plugName.length > 0 && plugNames.indexOf(plugName) < 0) {
plugNames.push(plugName);
}
continue;
}
let secId: string;
if (key.startsWith('core.')) {
const cat: string = metaCategory(metaStore, key);
secId = cat.length > 0 ? 'core/' + cat : 'core/misc';
if (titles[secId] === undefined) {
titles[secId] = cat.length > 0 ? categoryTitle(cat) : '未分类';
}
} else {
secId = 'other';
if (titles[secId] === undefined) {
titles[secId] = '其他';
}
}
if (counts[secId] === undefined) {
counts[secId] = 0;
ids.push(secId);
}
counts[secId] = counts[secId] + 1;
}
ids.sort((a: string, b: string): number => a.localeCompare(b));
const secs: SettingsSection[] = [];
for (const id of ids) {
secs.push({ id: id, title: titles[id] ?? id, count: counts[id] ?? 0 });
}
const stats: SectionStats = {
sections: secs,
pluginKeyCount: pluginKeys,
pluginConfigCount: plugNames.length,
};
return stats;
}
export function pickInitialSection(sections: SettingsSection[]): string {
for (let i = 0; i < sections.length; i++) {
if (sections[i].id === 'core/agent') {
return 'core/agent';
}
}
return sections.length > 0 ? sections[0].id : 'core';
}
export function keyInSection(
metaStore: Record<string, SettingMetaRaw>, key: string, secId: string): boolean {
if (secId === 'other') {
return !key.startsWith('core.') && !key.startsWith('plugin.');
}
if (secId.startsWith('core/')) {
if (!key.startsWith('core.')) {
return false;
}
const cat: string = secId.substring('core/'.length);
return cat === 'misc'
? metaCategory(metaStore, key).length === 0
: metaCategory(metaStore, key) === cat;
}
if (secId.startsWith('plugin/')) {
const p: string = secId.substring('plugin/'.length);
return key.startsWith('plugin.' + p + '.');
}
return false;
}
export function activeSectionTitle(sections: SettingsSection[], secId: string): string {
for (let i = 0; i < sections.length; i++) {
if (sections[i].id === secId) {
return sections[i].title;
}
}
return '配置项';
}
/** 某个分区的配置项(按 key 字典序,最多 PAGE_SIZE*4 项) */
export function buildEntries(
valuesStore: Record<string, string>,
metaStore: Record<string, SettingMetaRaw>,
secId: string): SettingEntry[] {
const entries: SettingEntry[] = [];
const keys: string[] = Object.keys(valuesStore).filter((k: string): boolean => {
return keyInSection(metaStore, k, secId);
});
keys.sort((a: string, b: string): number => a.localeCompare(b));
const limit: number = Math.min(keys.length, SETTINGS_PAGE_SIZE * 4);
for (let i = 0; i < limit; i++) {
const key: string = keys[i];
const meta: SettingMetaRaw | undefined = metaStore[key];
const entry: SettingEntry = {
key: key,
displayName: meta !== undefined && meta.displayName.length > 0 ? meta.displayName : key,
description: meta !== undefined ? meta.description : '',
type: meta !== undefined ? meta.type : 'string',
options: meta !== undefined ? meta.options : [],
value: valuesStore[key] ?? '',
dirty: false,
};
entries.push(entry);
}
return entries;
}
/** 覆盖某个 entry 的 value/dirty,返回新数组(保持 @State 数组替换语义) */
export function withEntryMarked(
entries: SettingEntry[], key: string, value: string, dirty: boolean): SettingEntry[] {
const next: SettingEntry[] = [];
for (let i = 0; i < entries.length; i++) {
const e: SettingEntry = entries[i];
if (e.key === key) {
const copy: SettingEntry = {
key: e.key,
displayName: e.displayName,
description: e.description,
type: e.type,
options: e.options,
value: value,
dirty: dirty,
};
next.push(copy);
} else {
next.push(e);
}
}
return next;
}
/**
* 从 picker 返回的 URI 里取图片后缀(带点)。
* Image 组件依赖后缀选择解码器;沙箱里存成无后缀文件会静默解码失败,
* 用户看到的就是"背景图设置了却不生效"。取不到后缀时兜底 .jpg。
*/
export function imageExt(uri: string): string {
let s: string = uri;
const q: number = s.indexOf('?');
if (q >= 0) {
s = s.substring(0, q);
}
const dot: number = s.lastIndexOf('.');
const slash: number = s.lastIndexOf('/');
if (dot > slash && dot < s.length - 1) {
const ext: string = s.substring(dot).toLowerCase();
if (ext.length <= 5) {
return ext;
}
}
return '.jpg';
}

View File

@ -0,0 +1,180 @@
/**
* 阶段轨迹(单例):本轮对话在七个内核阶段里真实发生过什么。
*
* 由 ChatSse 在收到 `stage` 事件时喂入,运行态面板读取。
* 为什么不放进 StatusStore:轨迹来自 SSE 流、与 /status、/kernel 的轮询无关,
* 两者的生命周期和失败模式都不一样,混在一个数据源里会互相拖累
* (SSE 断连不该让状态卡变空,状态轮询失败也不该清掉轨迹)。
*
* 七阶段归并成五格(与内核 sdk.Stage 的顺序一致):
* 一轮里工具调用会反复回到「行动后」,线性滑块本身就是错的表述,
* 所以画成 输入 → 行动 ⇄(工具) → 输出 → 结束,工具那格带循环标记。
*/
/** 一个阶段组 */
export interface StageGroup {
/** 0 输入 / 1 行动 / 2 工具 / 3 输出 / 4 结束 */
group: number;
label: string;
en: string;
}
/** 轨迹里的一条事件 */
export interface StageEvent {
group: number;
/** 'stage' | 'tool' | 'output' */
kind: string;
label: string;
short: string;
count: number;
}
/** 阶段组定义,索引即 group */
export const STAGE_GROUPS: StageGroup[] = [
{ group: 0, label: '输入', en: 'in' },
{ group: 1, label: '行动', en: 'act' },
{ group: 2, label: '工具', en: 'tool' },
{ group: 3, label: '输出', en: 'out' },
{ group: 4, label: '结束', en: 'done' },
];
/** 当前阶段(SSE 驱动)。空串 = 空闲。 */
export const K_STAGE_PHASE: string = 'stagePhase';
/** 轨迹版本号:数组不进 AppStorage,靠它触发订阅组件重取快照 */
export const K_STAGE_REV: string = 'stageRev';
/** 阶段停留多久后回「空闲」——否则会留下一个永远停在 after_output 的假状态 */
const IDLE_AFTER_MS: number = 2500;
const MAX_ITEMS: number = 24;
/** rtShortTool 把 `qq_get_message` / `output_send__qq` 压成尾段短名 */export function shortTool(name: string): string {
let n: string = name;
const i: number = n.lastIndexOf('__');
if (i >= 0) {
n = n.substring(i + 2);
}
return n.length > 14 ? n.substring(0, 13) + '…' : n;
}
class StageTrail {
private items: StageEvent[] = [];
private timerId: number = -1;
init(): void {
AppStorage.setOrCreate<string>(K_STAGE_PHASE, '');
AppStorage.setOrCreate<number>(K_STAGE_REV, 0);
}
/** 只给订阅组件读;调用方不要持有它 */
snapshot(): StageEvent[] {
return this.items;
}
currentPhase(): string {
return AppStorage.get<string>(K_STAGE_PHASE) ?? '';
}
/** 按阶段分组取条目 */
eventsOf(group: number): StageEvent[] {
const out: StageEvent[] = [];
for (let i = 0; i < this.items.length; i++) {
const e: StageEvent = this.items[i];
if (e.group === group) {
out.push(e);
}
}
return out;
}
/**
* 收到一条 stage 事件。phase 取值与内核一致:
* on_input / pre_action / post_action / before_toolcall / after_toolcall /
* before_output / after_output。
*/
onStage(phase: string, tool: string): void {
if (phase.length === 0) {
return;
}
if (phase === 'on_input') {
// 新的一轮:清空上一轮的轨迹
this.items = [];
this.push(0, 'stage', '输入', '输入');
} else if (phase === 'pre_action') {
this.push(1, 'stage', '组装上下文并思考', '思考');
} else if (phase === 'before_toolcall' && tool.length > 0) {
// output_* 是输出通道工具,与普通工具用不同配色区分
const kind: string = tool.indexOf('output_') === 0 ? 'output' : 'tool';
this.push(2, kind, tool, shortTool(tool));
} else if (phase === 'before_output') {
this.push(3, 'stage', '生成回复', '生成');
} else if (phase === 'after_output') {
this.push(4, 'stage', '本轮完成', '完成');
} else {
// post_action / after_toolcall 不单独记:它们与相邻格重复,
// 逐条记会把轨迹刷成噪音。
AppStorage.set<string>(K_STAGE_PHASE, phase);
this.armIdleTimer();
return;
}
AppStorage.set<string>(K_STAGE_PHASE, phase);
this.armIdleTimer();
this.bump();
}
private push(group: number, kind: string, label: string, short: string): void {
// 同一阶段重复出现的同一条(如同一工具连调 3 次)只累加计数,不刷屏
const n: number = this.items.length;
if (n > 0) {
const last: StageEvent = this.items[n - 1];
if (last.group === group && last.kind === kind && last.short === short) {
last.count = last.count + 1;
return;
}
}
this.items.push({ group: group, kind: kind, label: label, short: short, count: 1 });
if (this.items.length > MAX_ITEMS) {
this.items.shift();
}
}
private armIdleTimer(): void {
if (this.timerId !== -1) {
clearTimeout(this.timerId);
}
this.timerId = setTimeout(() => {
this.timerId = -1;
AppStorage.set<string>(K_STAGE_PHASE, '');
this.bump();
}, IDLE_AFTER_MS);
}
private bump(): void {
const cur: number = AppStorage.get<number>(K_STAGE_REV) ?? 0;
AppStorage.set<number>(K_STAGE_REV, cur + 1);
}
}
export const stageTrail: StageTrail = new StageTrail();
/**
* 内核的七个阶段归并到五个展示格。顺序与 sdk.Stage 一致,
* 所以「当前阶段」直接看返回值是不是当前格。空闲返回 -1。
*/
export function phaseGroup(phase: string): number {
if (phase === 'on_input') {
return 0;
}
if (phase === 'pre_action' || phase === 'post_action') {
return 1;
}
if (phase === 'before_toolcall' || phase === 'after_toolcall') {
return 2;
}
if (phase === 'before_output') {
return 3;
}
if (phase === 'after_output') {
return 4;
}
return -1;
}

View File

@ -27,6 +27,68 @@ export interface StatGroup {
fields: StatField[]; fields: StatField[];
} }
// ===== 运行态快照(/runtime)=====
//
// 与 StatGroup 的分工:明细卡回答「内核有哪些东西、多少」,
// 运行态回答「现在在干什么」——四级中断队列积压多少、有几个驻留子。
// 两者数据源不同(/kernel vs /runtime),所以分开取、分开存。
/** 一条队列(四级中断之一,或排队队列) */
export interface RuntimeQueue {
/** 4/3/2/1;0 表示排队队列(无级别) */
lv: number;
name: string;
desc: string;
depth: number;
registered: number;
preempted: number;
}
/** 一次刷新的运行态快照 */
export interface RuntimeSnapshot {
/** 排队队列深度(无级别,纯 FIFO) */
ready: number;
pending: number;
stack: number;
maxStack: number;
subagents: number;
/** 格槽数(按全场最大深度缩放,至少 5) */
slots: number;
/** 五条队列:L4/L3/L2/L1 + 排队 */
queues: RuntimeQueue[];
}
interface LevelDef {
lv: number;
name: string;
desc: string;
}
/** 四级中断的定义(顺序即 L4→L1) */
const LEVEL_DEFS: LevelDef[] = [
{ lv: 4, name: 'L4', desc: '内核独占' },
{ lv: 3, name: 'L3', desc: '交互' },
{ lv: 2, name: 'L2', desc: '消息' },
{ lv: 1, name: 'L1', desc: '后台' },
];
/** JSON 数组里按下标取数:越界/类型不符都当 0 */
function numAt(arr: Object[] | undefined, i: number): number {
if (arr === undefined || arr === null || i < 0 || i >= arr.length) {
return 0;
}
const v: number = arr[i] as number;
return isNaN(v) ? 0 : v;
}
/** 格槽数:按全场最大深度缩放,至少 5 格(0 时也要有可见形状)、最多 16 格 */
function clampSlots(maxQ: number): number {
if (maxQ < 5) {
return 5;
}
return maxQ > 16 ? 16 : maxQ;
}
// ===== AppStorage 键:摘要卡与明细页共用 ===== // ===== AppStorage 键:摘要卡与明细页共用 =====
export const K_UP: string = 'statUp'; export const K_UP: string = 'statUp';
export const K_VERSION: string = 'statVersion'; export const K_VERSION: string = 'statVersion';
@ -37,10 +99,14 @@ export const K_TOOLS: string = 'statTools';
export const K_ERR: string = 'statErr'; export const K_ERR: string = 'statErr';
export const K_LOADING: string = 'statLoading'; export const K_LOADING: string = 'statLoading';
export const K_REV: string = 'statRev'; export const K_REV: string = 'statRev';
/** 内核身份副行:内核名 · commit。版本号光有一个号码分不清是哪个内核、哪次构建。 */
export const K_BUILD: string = 'statBuildSub';
class StatusStore { class StatusStore {
/** 明细分组:只有明细页读它,不进 AppStorage(数组同步语义太脆) */ /** 明细分组:只有明细页读它,不进 AppStorage(数组同步语义太脆) */
private groups: StatGroup[] = []; private groups: StatGroup[] = [];
/** 运行态快照:同上,靠 K_REV 触发订阅组件重取 */
private runtimeSnapshot: RuntimeSnapshot | undefined = undefined;
init(): void { init(): void {
AppStorage.setOrCreate<boolean>(K_UP, false); AppStorage.setOrCreate<boolean>(K_UP, false);
@ -52,12 +118,17 @@ class StatusStore {
AppStorage.setOrCreate<string>(K_ERR, ''); AppStorage.setOrCreate<string>(K_ERR, '');
AppStorage.setOrCreate<boolean>(K_LOADING, false); AppStorage.setOrCreate<boolean>(K_LOADING, false);
AppStorage.setOrCreate<number>(K_REV, 0); AppStorage.setOrCreate<number>(K_REV, 0);
AppStorage.setOrCreate<string>(K_BUILD, '');
} }
getGroups(): StatGroup[] { getGroups(): StatGroup[] {
return this.groups; return this.groups;
} }
getRuntime(): RuntimeSnapshot | undefined {
return this.runtimeSnapshot;
}
isUp(): boolean { isUp(): boolean {
return AppStorage.get<boolean>(K_UP) ?? false; return AppStorage.get<boolean>(K_UP) ?? false;
} }
@ -101,6 +172,7 @@ class StatusStore {
]; ];
await this.collectKernel(groups); await this.collectKernel(groups);
await this.collectRuntime();
this.groups = groups; this.groups = groups;
this.bump(); this.bump();
} catch (e) { } catch (e) {
@ -133,8 +205,66 @@ class StatusStore {
if (startTime.length > 0) { if (startTime.length > 0) {
kernelFields.push({ label: '内核启动', value: formatTime(startTime) }); kernelFields.push({ label: '内核启动', value: formatTime(startTime) });
} }
// 构建身份:版本 / commit / SDK 兼容都取自 /kernel 的 build(-ldflags 注入)。
// 为何不能只用 /status 的 version:那里只有一个版本号,分不清是哪个内核、
// 哪次构建;许可标识更是完全没有。
const build: Record<string, Object> | undefined = k['build'] as Record<string, Object>;
let lic: string = '';
let licURL: string = '';
let srcURL: string = '';
if (build !== undefined && build !== null) {
const bVer: string = build['version'] as string ?? '';
const bCommit: string = build['commit'] as string ?? '';
const bName: string = build['kernel_name'] as string ?? 'HomeAgent';
const bSdk: string = build['sdk_compatible'] as string ?? '';
const bTime: string = build['build_time'] as string ?? '';
lic = build['license'] as string ?? '';
licURL = build['license_url'] as string ?? '';
srcURL = build['source_url'] as string ?? '';
if (bVer.length > 0) {
AppStorage.set<string>(K_VERSION, 'v' + bVer);
kernelFields.push({ label: '内核版本', value: 'v' + bVer });
}
let sub: string = bName;
if (bCommit.length > 0 && bCommit !== 'unknown') {
sub = sub + ' · ' + bCommit.substring(0, 7);
}
AppStorage.set<string>(K_BUILD, sub);
if (bCommit.length > 0) {
kernelFields.push({ label: 'Commit', value: bCommit });
}
if (bSdk.length > 0) {
kernelFields.push({ label: 'SDK 兼容', value: bSdk });
}
if (bTime.length > 0 && bTime !== 'unknown') {
kernelFields.push({ label: '构建时间', value: formatTime(bTime) });
}
}
groups.push({ title: '内核', fields: kernelFields }); groups.push({ title: '内核', fields: kernelFields });
// 开源许可:只给一个源码链接、不写协议名,使用者看不出这受什么许可约束,
// 也看不出网络服务场景下的 §13 义务。
const legalFields: StatField[] = [];
if (lic.length > 0) {
legalFields.push({ label: '许可协议', value: lic });
}
if (licURL.length > 0) {
legalFields.push({ label: '协议全文', value: licURL });
}
if (srcURL.length > 0) {
legalFields.push({ label: '源码仓库', value: srcURL });
}
if (legalFields.length > 0) {
if (lic.toUpperCase().indexOf('AGPL') >= 0) {
legalFields.push({
label: '网络条款',
value: '把修改后的版本作为网络服务对外提供时,必须向使用者提供取得对应源码的途径(§13)',
});
}
groups.push({ title: '开源许可', fields: legalFields });
}
// LLM:provider / 可用源 / 是否可用 // LLM:provider / 可用源 / 是否可用
const llm: Record<string, Object> | undefined = k['llm'] as Record<string, Object>; const llm: Record<string, Object> | undefined = k['llm'] as Record<string, Object>;
if (llm !== undefined && llm !== null) { if (llm !== undefined && llm !== null) {
@ -221,11 +351,91 @@ class StatusStore {
} }
} }
/**
* 取运行态快照(/runtime)。失败不影响已经取到的明细分组:
* 旧后端可能没有这个端点,那时面板显示「运行态数据不可用」即可。
*/
private async collectRuntime(): Promise<void> {
try {
const resp = await apiClient.getWithTimeout('/runtime', 8000);
const r: Record<string, Object> = JSON.parse(resp.body) as Record<string, Object>;
const sc: Record<string, Object> | undefined = r['scheduler'] as Record<string, Object>;
const residents: Object[] | undefined = r['residents'] as Object[];
let ready: number = 0;
let pending: number = 0;
let stack: number = 0;
let maxStack: number = 4;
let qArr: Object[] | undefined = undefined;
let regArr: Object[] | undefined = undefined;
let preArr: Object[] | undefined = undefined;
if (sc !== undefined && sc !== null) {
ready = sc['ready_queue_depth'] as number ?? 0;
pending = sc['pending_interrupts'] as number ?? 0;
stack = sc['suspend_stack'] as number ?? 0;
maxStack = sc['max_suspend_depth'] as number ?? 4;
qArr = sc['interrupt_queues'] as Object[];
regArr = sc['interrupts_by_level'] as Object[];
preArr = sc['preempts_by_level'] as Object[];
}
// 四级语义引用内核的定义(internal/agent/core/scheduler.go),
// 前端只负责把它们画出来,不自己起名字。
const queues: RuntimeQueue[] = [];
let maxQ: number = 1;
for (let i = 0; i < LEVEL_DEFS.length; i++) {
const d: LevelDef = LEVEL_DEFS[i];
const depth: number = numAt(qArr, d.lv);
if (depth > maxQ) {
maxQ = depth;
}
queues.push({
lv: d.lv,
name: d.name,
desc: d.desc,
depth: depth,
registered: numAt(regArr, d.lv),
preempted: numAt(preArr, d.lv),
});
}
if (ready > maxQ) {
maxQ = ready;
}
// 第五条:排队队列。它不是优先级,而是另一**类别**(排队 vs 中断),
// 所以 lv 用 0 标记「无级别」。
queues.push({
lv: 0,
name: '排队',
desc: 'FIFO',
depth: ready,
registered: 0,
preempted: 0,
});
const subagents: number = residents !== undefined && residents !== null
? residents.length : 0;
this.runtimeSnapshot = {
ready: ready,
pending: pending,
stack: stack,
maxStack: maxStack,
subagents: subagents,
slots: clampSlots(maxQ),
queues: queues,
};
} catch (e) {
// /runtime 不可用(旧后端):保留上一次快照,不清空
}
}
private fail(msg: string): void { private fail(msg: string): void {
AppStorage.set<string>(K_ERR, msg); AppStorage.set<string>(K_ERR, msg);
AppStorage.set<boolean>(K_UP, false); AppStorage.set<boolean>(K_UP, false);
AppStorage.set<boolean>(K_LOADING, false); AppStorage.set<boolean>(K_LOADING, false);
this.groups = []; this.groups = [];
this.runtimeSnapshot = undefined;
this.bump(); this.bump();
} }

View File

@ -0,0 +1,265 @@
/**
* 「外观」二级页面:主题三选一 + 自定义背景图。
*
* 从 pages/SettingsPage.ets 抽出。
* themeMode / bgImage / bgOpacity 用 @Link 与一级页面共享(一级页的
* 外观行要显示当前主题名,两边必须是同一份数据)。
*/
import { connStore } from '../common/ConnStore';
import { AppSettings, emptySettings } from '../model/Model';
import { applyThemeMode } from '../common/Constants';
import { ThemePalette, DARK_PALETTE, LIGHT_PALETTE, RADIUS_MD,
ANIM_NORMAL } from '../common/Constants';
import { imageExt } from '../common/SettingsModel';
import { userMessage } from '../common/UserError';
import { SubPageLayer, PlainCard } from './SubPage';
import { MotionBase } from './MotionBase';
import { picker, fileIo } from '@kit.CoreFileKit';
import { common } from '@kit.AbilityKit';
@Component
export struct AppearancePane {
@StorageProp('themeIsDark') private isDark: boolean = true;
@Link themeMode: string;
@Link bgImage: string;
@Link bgOpacity: number;
onBack?: () => void;
onToast?: (msg: string, isError: boolean) => void;
@State pickingBg: boolean = false;
private palette(): ThemePalette {
return this.isDark ? DARK_PALETTE : LIGHT_PALETTE;
}
private toast(msg: string, isError: boolean): void {
const cb: ((m: string, e: boolean) => void) | undefined = this.onToast;
if (cb !== undefined) {
cb(msg, isError);
}
}
private applyTheme(mode: string): void {
this.themeMode = mode;
this.persistSettings();
// 立即翻转全局主题标志,整个 UI 随之切换
applyThemeMode(mode);
}
private async pickBackgroundImage(): Promise<void> {
if (this.pickingBg) {
return;
}
this.pickingBg = true;
try {
const options = new picker.PhotoSelectOptions();
options.MIMEType = picker.PhotoViewMIMETypes.IMAGE_TYPE;
options.maxSelectNumber = 1;
const photoPicker = new picker.PhotoViewPicker();
const result = await photoPicker.select(options);
if (result.photoUris.length === 0) {
return;
}
const srcUri: string = result.photoUris[0];
const ctx = getContext(this) as common.UIAbilityContext;
// 文件名带时间戳:Image 组件按 src 字符串做内存缓存,
// 每次都写同一个 bg_image 会让第二次换图看起来"没生效"。
// 后缀必须保留:Image 组件按扩展名挑选解码器,无后缀的沙箱文件会解码失败,
// 表现就是"设置了背景图但没生效"(onError 里能看到 decode 失败)。
const destPath: string = ctx.filesDir + '/bg_' + Date.now().toString(36) + imageExt(srcUri);
const srcFile = fileIo.openSync(srcUri, fileIo.OpenMode.READ_ONLY);
const destFile = fileIo.openSync(destPath,
fileIo.OpenMode.READ_WRITE | fileIo.OpenMode.CREATE | fileIo.OpenMode.TRUNC);
fileIo.copyFileSync(srcFile.fd, destFile.fd);
fileIo.closeSync(srcFile);
fileIo.closeSync(destFile);
this.removeOldBgFile();
// Image 只认带协议头的沙箱 URI,裸路径会被当成资源名而静默失败
this.bgImage = 'file://' + destPath;
this.persistSettings();
this.toast('背景图已设置', false);
} catch (e) {
this.toast(userMessage('settings.pickBg', e), true);
}
this.pickingBg = false;
}
/** 删除上一张背景图文件,避免沙箱里越攒越多 */
private removeOldBgFile(): void {
const old: string = this.bgImage;
if (old.length === 0) {
return;
}
const path: string = old.startsWith('file://') ? old.substring(7) : old;
try {
fileIo.unlinkSync(path);
} catch (e) {
// 文件可能已不存在,忽略
}
}
private clearBackgroundImage(): void {
this.removeOldBgFile();
this.bgImage = '';
this.persistSettings();
this.toast('已清除背景图', false);
}
private onBgOpacityChange(value: number): void {
this.bgOpacity = value / 100;
this.persistSettings();
}
private persistSettings(): void {
const s: AppSettings = emptySettings();
const old: AppSettings = connStore.getSettings();
s.lang = old.lang;
s.theme = this.themeMode.length > 0 ? this.themeMode : (old.theme.length > 0 ? old.theme : 'system');
s.currentConnId = old.currentConnId;
s.bgImage = this.bgImage;
s.bgOpacity = this.bgOpacity;
connStore.saveSettings(s);
AppStorage.set<string>('bgImage', this.bgImage);
AppStorage.set<number>('bgOpacity', this.bgOpacity);
}
@Builder
ThemeOption(label: string, mode: string) {
// 按压缩放由 MotionBase 统一;flexWeight: 1 让三枚选项在 Row 里继续等分。
MotionBase({ pressEnabled: true, flexWeight: 1 }) {
Column() {
Text(label)
.fontSize(12)
.fontColor(this.themeMode === mode ? Color.White : this.palette().textSecondary)
// 子节点的颜色迁移要自己声明:父容器的 .animation() 不下传
.animation({ duration: ANIM_NORMAL, curve: Curve.EaseOut })
}
.justifyContent(FlexAlign.Center)
.width('100%')
.height(34)
.borderRadius(RADIUS_MD)
.backgroundColor(this.themeMode === mode ? this.palette().accent : this.palette().bgHover)
// 三选一的选中态迁移:底色与描边一起过渡。写在 .border 之后、
// 覆盖它上面的所有状态驱动属性。
.border({
width: 1,
color: this.themeMode === mode ? this.palette().accent : this.palette().btnGhostBorder,
})
.animation({ duration: ANIM_NORMAL, curve: Curve.EaseOut })
.onClick(() => {
this.applyTheme(mode);
})
}
}
build() {
SubPageLayer({
title: '外观',
tab: 3,
onBack: () => {
const cb: (() => void) | undefined = this.onBack;
if (cb !== undefined) {
cb();
}
},
}) {
Column() {
PlainCard({ caption: '主题' }) {
Row({ space: 8 }) {
this.ThemeOption('跟随系统', 'system')
this.ThemeOption('浅色', 'light')
this.ThemeOption('深色', 'dark')
}
.width('100%')
Text(this.themeMode === 'system'
? '当前跟随系统,系统切换深浅色时自动跟随'
: (this.themeMode === 'dark' ? '当前强制深色主题' : '当前强制浅色主题'))
.fontSize(11)
.fontColor(this.palette().textMuted)
.margin({ top: 10 })
}
PlainCard({ caption: '背景图' }) {
Row() {
Column() {
Text('自定义背景图')
.fontSize(14)
.fontColor(this.palette().textPrimary)
Text(this.bgImage.length > 0 ? '已设置背景图' : '未设置背景图')
.fontSize(11)
.fontColor(this.palette().textMuted)
.margin({ top: 2 })
}
.alignItems(HorizontalAlign.Start)
.layoutWeight(1)
if (this.bgImage.length > 0) {
Button('更换')
.height(28)
.fontSize(12)
.backgroundColor(Color.Transparent)
.border({ width: 1, color: this.palette().btnGhostBorder })
.fontColor(this.palette().textSecondary)
.margin({ right: 6 })
.onClick(() => {
this.pickBackgroundImage();
})
Button('清除')
.height(28)
.fontSize(12)
.backgroundColor(Color.Transparent)
.border({ width: 1, color: 'rgba(232, 64, 38, 0.45)' })
.fontColor('#E84026')
.onClick(() => {
this.clearBackgroundImage();
})
} else {
Button(this.pickingBg ? '选择中...' : '选择图片')
.height(28)
.fontSize(12)
.backgroundColor(this.palette().accent)
.fontColor(Color.White)
.onClick(() => {
this.pickBackgroundImage();
})
}
}
.width('100%')
if (this.bgImage.length > 0) {
Row() {
Text('透明度')
.fontSize(11)
.fontColor(this.palette().textMuted)
Slider({
value: Math.round(this.bgOpacity * 100),
min: 5,
max: 60,
step: 1,
})
.layoutWeight(1)
.selectedColor(this.palette().accent)
.trackColor(this.palette().bgHover)
.margin({ left: 8, right: 8 })
.onChange((v: number, mode: SliderChangeMode) => {
if (mode === SliderChangeMode.Moving || mode === SliderChangeMode.Click) {
this.onBgOpacityChange(v);
}
})
Text(Math.round(this.bgOpacity * 100).toString() + '%')
.fontSize(11)
.fontColor(this.palette().textSecondary)
.width(32)
}
.width('100%')
.alignItems(VerticalAlign.Center)
.margin({ top: 12 })
}
}
}
.width('100%')
.alignItems(HorizontalAlign.Start)
}
}
}

View File

@ -4,107 +4,20 @@ import { common } from '@kit.AbilityKit';
import { apiClient } from '../common/ApiClient'; import { apiClient } from '../common/ApiClient';
import { userMessage } from '../common/UserError'; import { userMessage } from '../common/UserError';
import { ChatAttachment } from '../model/Model'; import { ChatAttachment } from '../model/Model';
import { extLabel, formatBytes, sanitize } from '../common/AttachmentMeta';
import { loadPixelMap } from '../common/AttachmentImage';
import { ThemePalette, DARK_PALETTE, LIGHT_PALETTE, RADIUS_LG, RADIUS_MD, RADIUS_SM, ANIM_FAST, ANIM_NORMAL, ANIM_ENTER } from '../common/Constants'; import { ThemePalette, DARK_PALETTE, LIGHT_PALETTE, RADIUS_LG, RADIUS_MD, RADIUS_SM, ANIM_FAST, ANIM_NORMAL, ANIM_ENTER } from '../common/Constants';
import { COLOR_ERROR } from '../common/Constants'; import { COLOR_ERROR } from '../common/Constants';
import { MotionBase } from './MotionBase'; import { MotionBase } from './MotionBase';
import { PlainCard } from './SubPage'; import { PlainCard } from './SubPage';
/** /**
* 附件解析与展示。 * 附件 UI:气泡内的附件卡 + 附件详情二级页内容。
* *
* 后端 Attachment 只有四个字段:type / url / size / name * 解析/格式化(parseAttachment、formatBytes、extLabel…)在 common/AttachmentMeta.ets,
* (internal/plugins/webui/handler.go),没有 mime、没有像素尺寸、没有本地路径。 * 字节获取与解码在 common/AttachmentImage.ets —— 这里只留 UI。
* 所以详情页里的"尺寸/格式"必须由客户端自己解码得出,不能假装后端给了。
* *
* 字节走 GET <base>/files/<name> 或 /uploads/<name>(注意不带 /api/v1 前缀)。 * 附件卡:图片显示缩略图,文件显示一枚文件条。
* 这两条路由在后端是 requireWeb,但对 API Key 客户端同等放行,
* 所以带上和普通接口一样的鉴权头即可,无需 web 登录态。
*/
/** 从后端 JSON 里解析 attachment 字段;缺字段或类型不对则返回 undefined。 */
export function parseAttachment(raw: Object | undefined): ChatAttachment | undefined {
if (raw === undefined || raw === null) {
return undefined;
}
const o: Record<string, Object> = raw as Record<string, Object>;
const url: string = o['url'] as string ?? '';
if (url.length === 0) {
return undefined;
}
const t: string = o['type'] as string ?? 'file';
const a: ChatAttachment = {
type: t === 'image' ? 'image' : 'file',
url: url,
size: o['size'] as number ?? 0,
name: o['name'] as string ?? fileNameOf(url),
};
return a;
}
/** 由 SSE channel_output 事件构造附件(字段名与 history 不同)。 */
export function attachmentFromChannelOutput(
outputType: string, url: string, size: number): ChatAttachment | undefined {
if (url.length === 0) {
return undefined;
}
if (outputType !== 'image' && outputType !== 'file') {
return undefined;
}
const a: ChatAttachment = {
type: outputType,
url: url,
size: size,
name: fileNameOf(url),
};
return a;
}
/** 取 URL 最后一段作为展示文件名,与后端 handler.go 的取名方式一致。 */
export function fileNameOf(url: string): string {
let s: string = url;
const q: number = s.indexOf('?');
if (q >= 0) {
s = s.substring(0, q);
}
const i: number = s.lastIndexOf('/');
const name: string = i >= 0 ? s.substring(i + 1) : s;
return name.length > 0 ? name : '附件';
}
/** 人类可读字节数,口径对齐后端 formatBytes(KB 以上保留一位小数)。 */
export function formatBytes(n: number): string {
if (n <= 0) {
return '';
}
if (n < 1024) {
return n.toString() + ' B';
}
const kb: number = n / 1024;
if (kb < 1024) {
return oneDecimal(kb) + ' KB';
}
const mb: number = kb / 1024;
if (mb < 1024) {
return oneDecimal(mb) + ' MB';
}
return oneDecimal(mb / 1024) + ' GB';
}
function oneDecimal(v: number): string {
return (Math.round(v * 10) / 10).toString();
}
/** 由文件名后缀猜测类型标签。后端不返回 mime,只能这样标注。 */
export function extLabel(name: string): string {
const i: number = name.lastIndexOf('.');
if (i < 0 || i === name.length - 1) {
return '未知类型';
}
return name.substring(i + 1).toUpperCase();
}
/**
* 气泡内的附件卡:图片显示缩略图,文件显示一枚文件条。
* 点击进入附件详情二级页面(WebGUI 是新开标签页,移动端改为二级页)。 * 点击进入附件详情二级页面(WebGUI 是新开标签页,移动端改为二级页)。
*/ */
@Component @Component
@ -428,36 +341,3 @@ export struct AttachmentDetailContent {
return this.isDark ? DARK_PALETTE : LIGHT_PALETTE; return this.isDark ? DARK_PALETTE : LIGHT_PALETTE;
} }
} }
/** 下载并解码成 PixelMap;任何一步失败都返回 undefined(调用方显示占位)。 */
async function loadPixelMap(url: string): Promise<image.PixelMap | undefined> {
try {
// 本地待上传的图片:直接读沙箱文件,不走网络
if (url.startsWith('file://')) {
const path: string = url.substring(7);
const f = fileIo.openSync(path, fileIo.OpenMode.READ_ONLY);
const localSrc: image.ImageSource = image.createImageSource(f.fd);
const localPm: image.PixelMap = await localSrc.createPixelMap();
await localSrc.release();
fileIo.closeSync(f);
return localPm;
}
const abs: string = apiClient.absoluteUrl(url);
const resp = await apiClient.getBinary(abs, 15000);
const src: image.ImageSource = image.createImageSource(resp.data);
const pm: image.PixelMap = await src.createPixelMap();
await src.release();
return pm;
} catch (e) {
return undefined;
}
}
/** 去掉路径分隔符,避免附件名把文件写到 filesDir 之外。 */
function sanitize(name: string): string {
let s: string = name.replace(/[\/\\:*?"<>|]/g, '_');
if (s.length === 0) {
s = 'attachment';
}
return s;
}

View File

@ -0,0 +1,172 @@
/**
* 「核心配置」相关的两个二级页面:分类列表 + 某个分类的配置项。
*
* 从 pages/SettingsPage.ets 抽出。
* 取数/分区/落库都留在页面(它同时要显示"几个分类 · 几项"和错误态),
* 这里只负责渲染与把用户动作转成回调。
*/
import { ThemePalette, DARK_PALETTE, LIGHT_PALETTE } from '../common/Constants';
import { SettingsSection, SettingEntry, activeSectionTitle } from '../common/SettingsModel';
import { SubPageLayer, NavGroup, NavRow, PlainCard } from './SubPage';
import { SettingsEntryCard } from './SettingsEntryCard';
@Component
export struct BackendSectionsPane {
@StorageProp('themeIsDark') private isDark: boolean = true;
@Prop sections: SettingsSection[] = [];
@Prop pluginKeyCount: number = 0;
@Prop pluginConfigCount: number = 0;
@Prop busy: boolean = false;
@Prop errorText: string = '';
@Prop activeSection: string = '';
/** 宽屏右栏正显示分区明细时高亮左侧对应行 */
@Prop highlightRows: boolean = false;
onBack?: () => void;
onRefresh?: () => void;
onOpenSection?: (id: string) => void;
private palette(): ThemePalette {
return this.isDark ? DARK_PALETTE : LIGHT_PALETTE;
}
build() {
SubPageLayer({
title: '核心配置',
tab: 3,
onBack: () => {
const cb: (() => void) | undefined = this.onBack;
if (cb !== undefined) {
cb();
}
},
showRefresh: true,
onRefresh: () => {
const cb: (() => void) | undefined = this.onRefresh;
if (cb !== undefined) {
cb();
}
},
}) {
Column() {
if (this.errorText.length > 0) {
PlainCard({ caption: '状态' }) {
Text(this.errorText)
.fontSize(12)
.fontColor('#E84026')
}
}
NavGroup({ caption: '核心' }) {
ForEach(this.sections, (sec: SettingsSection, idx: number) => {
NavRow({
icon: $r('app.media.ic_tune'),
title: sec.title,
subtitle: sec.count.toString() + ' 项配置',
showDivider: idx < this.sections.length - 1,
selected: this.highlightRows && this.activeSection === sec.id,
onTap: () => {
const cb: ((id: string) => void) | undefined = this.onOpenSection;
if (cb !== undefined) {
cb(sec.id);
}
},
})
}, (sec: SettingsSection) => sec.id + sec.count.toString())
}
// 插件配置不在这里编辑:入口在插件页的详情里,这里只指路,避免两处重复入口
if (this.pluginKeyCount > 0) {
Text('插件的 ' + this.pluginKeyCount.toString() + ' 项配置(' +
this.pluginConfigCount.toString() + ' 个插件)在「插件 → 选择插件 → 插件配置」中修改。')
.fontSize(12)
.fontColor(this.palette().textMuted)
.width('100%')
.padding({ left: 4, right: 4 })
}
if (this.sections.length === 0 && !this.busy) {
Text('未获取到配置分类。检查后端连接后点击刷新。')
.fontSize(12)
.fontColor(this.palette().textMuted)
.padding({ left: 4 })
}
}
.width('100%')
.alignItems(HorizontalAlign.Start)
}
}
}
@Component
export struct SectionEntriesPane {
@StorageProp('themeIsDark') private isDark: boolean = true;
@Prop sections: SettingsSection[] = [];
@Prop activeSection: string = '';
@Prop entries: SettingEntry[] = [];
@Prop busy: boolean = false;
onBack?: () => void;
onRefresh?: () => void;
onSaveValue?: (key: string, value: string) => void;
onSaveCurrent?: (key: string) => void;
onEdit?: (key: string, value: string) => void;
private palette(): ThemePalette {
return this.isDark ? DARK_PALETTE : LIGHT_PALETTE;
}
build() {
SubPageLayer({
title: activeSectionTitle(this.sections, this.activeSection),
tab: 3,
onBack: () => {
const cb: (() => void) | undefined = this.onBack;
if (cb !== undefined) {
cb();
}
},
showRefresh: true,
onRefresh: () => {
const cb: (() => void) | undefined = this.onRefresh;
if (cb !== undefined) {
cb();
}
},
}) {
Column() {
ForEach(this.entries, (entry: SettingEntry) => {
SettingsEntryCard({
entry: entry,
onSaveValue: (key: string, value: string) => {
const cb: ((k: string, v: string) => void) | undefined = this.onSaveValue;
if (cb !== undefined) {
cb(key, value);
}
},
onSaveCurrent: (key: string) => {
const cb: ((k: string) => void) | undefined = this.onSaveCurrent;
if (cb !== undefined) {
cb(key);
}
},
onEdit: (key: string, value: string) => {
const cb: ((k: string, v: string) => void) | undefined = this.onEdit;
if (cb !== undefined) {
cb(key, value);
}
},
})
}, (entry: SettingEntry) => entry.key + '|' + entry.value + '|' + (entry.dirty ? 'd' : 'c'))
if (!this.busy && this.entries.length === 0) {
Text('该分区暂无配置项')
.fontSize(12)
.fontColor(this.palette().textMuted)
.padding(16)
}
}
.width('100%')
.alignItems(HorizontalAlign.Start)
}
}
}

View File

@ -0,0 +1,139 @@
/**
* 输入区上方的两个悬浮条:加号菜单(图片/文件)与待发送附件预览。
*
* 从 components/ChatComposer.ets 拆出 —— 两者都是"输入区上方的独立浮层",
* 数据与动作全部由输入区传入。
*/
import { ThemePalette, DARK_PALETTE, LIGHT_PALETTE, RADIUS_MD, RADIUS_PILL,
ANIM_NORMAL } from '../common/Constants';
import { MotionBase } from './MotionBase';
import { formatBytes } from '../common/AttachmentMeta';
/** 加号菜单:两枚独立的玻璃胶囊,和输入区其他组件同一套视觉语言 */
@Component
export struct ChatAttachMenu {
@StorageProp('themeIsDark') private isDark: boolean = true;
onPickImage?: () => void;
onPickFile?: () => void;
private palette(): ThemePalette {
return this.isDark ? DARK_PALETTE : LIGHT_PALETTE;
}
@Builder
AttachOption(icon: Resource, label: string, tap: () => void) {
// 按压反馈交给 MotionBase:每个实例自带独立按压态,
// 修掉了原先两枚胶囊共用一个 @State、按一枚两枚同时缩放的问题。
MotionBase({ pressEnabled: true, fillWidth: false }) {
Row({ space: 6 }) {
Image(icon)
.width(15)
.height(15)
.fillColor(this.palette().textSecondary)
.draggable(false)
Text(label)
.fontSize(12)
.fontColor(this.palette().textPrimary)
}
.padding({ left: 12, right: 14, top: 8, bottom: 8 })
.backgroundColor(this.palette().navBarBg)
.borderRadius(RADIUS_PILL)
.border({ width: 1, color: this.palette().navBarBorder })
.shadow({ radius: 20, color: this.palette().shadow, offsetY: 6 })
.onClick(tap)
}
}
build() {
// 外层撑满并左对齐:菜单要出现在加号正上方,而不是跟着悬浮区右对齐
Row() {
Row({ space: 8 }) {
this.AttachOption($r('app.media.ic_image'), '图片', () => {
const cb: (() => void) | undefined = this.onPickImage;
if (cb !== undefined) {
cb();
}
})
this.AttachOption($r('app.media.ic_file'), '文件', () => {
const cb: (() => void) | undefined = this.onPickFile;
if (cb !== undefined) {
cb();
}
})
}
}
.width('100%')
.justifyContent(FlexAlign.Start)
.margin({ bottom: 8 })
.hitTestBehavior(HitTestMode.Transparent)
// 加号菜单由 if 控制,进出场只能靠 transition;配合 toggle 处的
// animateTo,展开时两枚胶囊从加号上方浮起而不是硬闪出来。
.transition(TransitionEffect.OPACITY.combine(TransitionEffect.translate({ y: 12 })).animation({ duration: ANIM_NORMAL, curve: Curve.EaseOut }))
}
}
/** 待发送附件预览条:缩略信息 + 一个移除按钮 */
@Component
export struct ChatPendingChip {
@StorageProp('themeIsDark') private isDark: boolean = true;
@Prop name: string = '';
@Prop byteSize: number = 0;
@Prop isImage: boolean = false;
@Prop uploading: boolean = false;
onRemove?: () => void;
private palette(): ThemePalette {
return this.isDark ? DARK_PALETTE : LIGHT_PALETTE;
}
build() {
// 按压反馈交给 MotionBase(全宽预览条)
MotionBase({ pressEnabled: true }) {
Row({ space: 8 }) {
Image(this.isImage ? $r('app.media.ic_image') : $r('app.media.ic_file'))
.width(15)
.height(15)
.fillColor(this.palette().accent)
.draggable(false)
Column({ space: 1 }) {
Text(this.name)
.fontSize(12)
.fontColor(this.palette().textPrimary)
.maxLines(1)
.textOverflow({ overflow: TextOverflow.Ellipsis })
Text(this.uploading ? '上传中...' : formatBytes(this.byteSize))
.fontSize(10)
.fontColor(this.palette().textMuted)
}
.alignItems(HorizontalAlign.Start)
.layoutWeight(1)
if (this.uploading) {
LoadingProgress()
.width(14)
.height(14)
.color(this.palette().accent)
} else {
Image($r('app.media.ic_close'))
.width(13)
.height(13)
.fillColor(this.palette().textMuted)
.draggable(false)
.onClick(() => {
const cb: (() => void) | undefined = this.onRemove;
if (cb !== undefined) {
cb();
}
})
}
}
.width('100%')
.padding({ left: 12, right: 12, top: 8, bottom: 8 })
.margin({ bottom: 8 })
.backgroundColor(this.palette().navBarBg)
.borderRadius(RADIUS_MD)
.border({ width: 1, color: this.palette().navBarBorder })
.shadow({ radius: 20, color: this.palette().shadow, offsetY: 6 })
}
}
}

View File

@ -0,0 +1,247 @@
/**
* 单条聊天气泡(含头像、渠道名、思考卡、工具卡、附件卡、正文)。
*
* 从 pages/ChatPage.ets 抽出(原来是 Avatar / ChanAvatar / BubbleSlot /
* MessageBubble / BubbleBody 五个 @Builder)。
*
* 传参约定:一切都在构造时快照进来。ForEach 的键(structSig)只在
* 消息"结构"变化时改变(新增思考/工具/附件/来源、定稿),结构一变
* 气泡就整条重建,因此结构类字段不需要二次更新;唯一会在键不变时
* 持续变化的是正文 content,所以它单独用基本类型 @Prop 传(与
* MarkdownView 的 @Prop content 走同一条响应式链路,流式渲染不变)。
*/
import { ChatMessage, ToolCallInfo, ChatAttachment } from '../model/Model';
import { ThemePalette, DARK_PALETTE, LIGHT_PALETTE, RADIUS_MD, RADIUS_PILL,
ANIM_NORMAL } from '../common/Constants';
import { bubbleMaxWidth, chanColor, chanLabel, chanLetter } from '../common/ChatFormat';
import { AttachmentCard } from './Attachment';
import { MarkdownView } from './MarkdownView';
import { ChatReasoningCard, ChatToolCard } from './ChatToolCard';
@Component
export struct ChatBubble {
@StorageProp('themeIsDark') private isDark: boolean = true;
@Prop msgId: number = 0;
@Prop role: string = '';
/** 正文:唯一会在 ForEach 键不变时持续变化的字段 */
@Prop content: string = '';
@Prop isStreaming: boolean = false;
@Prop isFinal: boolean = false;
@Prop reasoningContent: string = '';
@Prop reasoningOpen: boolean = false;
@Prop toolCalls: ToolCallInfo[] = [];
@Prop attachment: ChatAttachment | undefined = undefined;
@Prop source: string = '';
/** 是否"别处来的"消息(渠道/设备) */
@Prop channel: boolean = false;
/** 是否自己发的(右对齐、"我"头像) */
@Prop mine: boolean = false;
/** 入场动画阶段 */
@Prop fresh: boolean = false;
onOpenAttachment?: (att: ChatAttachment) => void;
onToggleReasoning?: (msgId: number) => void;
onToggleTool?: (msgId: number, index: number) => void;
private palette(): ThemePalette {
return this.isDark ? DARK_PALETTE : LIGHT_PALETTE;
}
/** 思考卡/工具卡是否是"面板":气泡宽度要放宽,见 common/ChatFormat */
private maxWidth(): string {
const msg: ChatMessage = {
id: this.msgId,
role: this.role,
content: this.content,
toolCalls: this.toolCalls,
};
if (this.reasoningContent.length > 0) {
msg.reasoningContent = this.reasoningContent;
}
return bubbleMaxWidth(msg);
}
@Builder
Avatar() {
Text(this.role === 'user' ? '我' : 'AI')
.fontSize(11)
.fontWeight(FontWeight.Bold)
.fontColor(this.role === 'user' ? this.palette().msgUserText : this.palette().accent)
.textAlign(TextAlign.Center)
.width(28)
.height(28)
.borderRadius(RADIUS_PILL)
.backgroundColor(this.role === 'user' ? this.palette().msgUserBg : this.palette().accentBg)
.margin({ top: 2 })
}
@Builder
ChanAvatar() {
Text(chanLetter(this.source))
.fontSize(12)
.fontWeight(FontWeight.Bold)
.fontColor(Color.White)
.textAlign(TextAlign.Center)
.width(28)
.height(28)
.borderRadius(RADIUS_PILL)
.backgroundColor(chanColor(this.source))
.margin({ top: 2 })
}
/**
* 气泡占位槽 —— 分栏右侧被切掉的根因就在这里。
*
* 原来 BubbleBody 直接放进 Row,它的 constraintSize maxWidth 是百分比
* (78% / 92%)。百分比是相对【父节点外框】解析的,而这个 Row 自带
* 左右 8 的 padding、外层列表 Column 又有左右 14 的 padding,
* 于是 92% 算出来的宽度里包含了这些 padding,再加上 28 的头像和 8 的
* 间距,一行的总宽就超过了可用内容宽。窄屏因为整体够宽看不出来,
* 分栏后左栏只有 420vp,溢出的十几 vp 直接被栏宽裁掉 —— 表现为
* 消息右侧被切了一条(这与 MarkdownView 里 width('100%') 溢出 12vp
* 被 clip 的问题是同一个成因)。
*
* 修法同 MarkdownView:用 layoutWeight(1) 拿"剩余空间"而不是百分比。
* 槽自身无 padding,外框宽 == 内容宽 == 头像与间距之外的真实可用宽度,
* 气泡的百分比再相对它解析,无论栏宽多少都不可能溢出。
*/
@Builder
BubbleSlot() {
Column() {
this.BubbleBody()
}
.layoutWeight(1)
.alignItems(this.mine ? HorizontalAlign.End : HorizontalAlign.Start)
}
@Builder
BubbleBody() {
Column() {
// 渠道来源名(对齐 GUI 的 msg-chan-name):只有别处来的消息才显示
if (this.channel) {
Text(chanLabel(this.source))
.fontSize(10)
.fontWeight(FontWeight.Medium)
.fontColor(this.palette().textMuted)
.margin({ bottom: 4 })
}
// Reasoning card (assistant only)
if (this.role === 'assistant' && this.reasoningContent.length > 0) {
ChatReasoningCard({
content: this.reasoningContent,
open: this.reasoningOpen,
sweeping: this.isFinal !== true && this.isStreaming === true,
fresh: this.fresh,
onToggle: () => {
const cb: ((id: number) => void) | undefined = this.onToggleReasoning;
if (cb !== undefined) {
cb(this.msgId);
}
},
})
}
// 附件卡(图片缩略图 / 文件条),点击进入附件详情二级页
if (this.attachment !== undefined) {
AttachmentCard({
att: this.attachment,
mine: this.role === 'user',
onTap: () => {
const a: ChatAttachment | undefined = this.attachment;
const cb: ((att: ChatAttachment) => void) | undefined = this.onOpenAttachment;
if (a !== undefined && cb !== undefined) {
cb(a);
}
},
})
}
// Content bubble — 对齐 WebGUI bubbleGrow + textFadeIn
if (this.content.length > 0) {
if (this.role === 'assistant') {
MarkdownView({
content: this.content,
isStreaming: this.isStreaming === true,
isDark: this.isDark,
})
} else {
Text(this.content)
.fontSize(15)
.lineHeight(24)
.fontColor(this.palette().msgBubbleText)
.textAlign(TextAlign.Start)
.wordBreak(WordBreak.BREAK_ALL)
.constraintSize({ maxWidth: '100%' })
.margin({ top: this.attachment !== undefined ? 8 : 0 })
}
}
// Tool cards
if (this.toolCalls.length > 0) {
Column() {
ForEach(this.toolCalls, (tc: ToolCallInfo, tci: number) => {
ChatToolCard({
tc: tc,
index: tci,
onToggle: (index: number) => {
const cb: ((id: number, i: number) => void) | undefined = this.onToggleTool;
if (cb !== undefined) {
cb(this.msgId, index);
}
},
})
}, (tc: ToolCallInfo, tci: number) => tci.toString() + tc.name)
}
// 不写 width('100%'):百分比会按气泡外框解析而溢出 12vp 被 clip。
// 让它自适应,最大宽约束由气泡内容框向下传递,ChatToolCard 内部用 layoutWeight 取满。
.alignItems(HorizontalAlign.Start)
.margin({ top: this.content.length > 0 ? 6 : 0 })
}
}
.constraintSize({ maxWidth: this.maxWidth() })
.clip(true)
.padding({ left: 12, right: 12, top: 9, bottom: 9 })
.backgroundColor(this.role === 'user' ? this.palette().msgUserBubbleBg : this.palette().msgAssistantBubbleBg)
.borderRadius({
topLeft: RADIUS_MD,
topRight: RADIUS_MD,
bottomLeft: this.role === 'assistant' ? 4 : RADIUS_MD,
bottomRight: this.role === 'user' ? 4 : RADIUS_MD,
})
.border({ width: 1, color: this.role === 'user' ? this.palette().msgUserBubbleBorder : this.palette().msgAssistantBubbleBorder })
.shadow({ radius: 8, color: this.palette().shadow, offsetY: 2 })
.alignItems(HorizontalAlign.Start)
// bubbleGrow: 气泡入场缩放效果
.scale({
x: this.fresh ? 0.95 : 1,
y: this.fresh ? 0.95 : 1,
})
.animation({ duration: 200, curve: Curve.EaseOut })
}
build() {
Row({ space: 8 }) {
if (this.channel) {
this.ChanAvatar()
this.BubbleSlot()
} else if (this.role === 'user') {
this.BubbleSlot()
this.Avatar()
} else {
this.Avatar()
this.BubbleSlot()
}
}
.width('100%')
.alignItems(VerticalAlign.Top)
// 槽已经用 layoutWeight 吃掉了剩余宽度,这里的对齐实际不再参与分配,
// 保留是为了兜底:若某处布局退化成非加权分配,方向也仍然正确。
.justifyContent(this.mine ? FlexAlign.End : FlexAlign.Start)
.padding({ left: 8, right: 8, top: 3, bottom: 3 })
// 入场动画:对齐 WebGUI viewIn (opacity 0 -> 1, translateY 6 -> 0)
.opacity(this.fresh ? 0 : 1)
.translate({ y: this.fresh ? 8 : 0 })
.animation({ duration: 180, curve: Curve.EaseOut })
}
}

View File

@ -0,0 +1,361 @@
/**
* 悬浮输入区:加号菜单 + 待发送附件预览 + 输入行(含发送/中断)。
*
* 从 pages/ChatPage.ets 抽出(原来是 ChatBody 的层2 + AttachMenu /
* AttachOption / PendingAttachmentChip 三个 @Builder,外加选图/选文件、
* 沙箱落盘、带附件发送这一整套方法)。
*
* 输入区自己持有文本与附件状态;只有会影响【列表底部留白】的三项
* (inputMultiLine / attachMenuOpen / pendingName)用 @Link 与页面共享。
*/
import { ChatMessage } from '../model/Model';
import { userMessage } from '../common/UserError';
import { connStore } from '../common/ConnStore';
import { ThemePalette, DARK_PALETTE, LIGHT_PALETTE, ANIM_FAST, ANIM_NORMAL } from '../common/Constants';
import { mimeOf } from '../common/ChatFormat';
import { chatStore, K_CHAT_LOADING } from '../common/ChatStore';
import { sendChatText, sendChatFile, interruptChat } from '../common/ChatSession';
import { fileNameOf } from '../common/AttachmentMeta';
import { ChatAttachMenu, ChatPendingChip } from './ChatAttachBar';
import { NavFloatOverlay, FloatIconButton } from './PageTopBar';
import { picker, fileIo } from '@kit.CoreFileKit';
import { common } from '@kit.AbilityKit';
import { MeasureOptions } from '@ohos.measure';
/** 输入框字号与内边距:文字测量必须和 TextArea 的实际排版参数一致 */
const INPUT_FONT_SIZE: number = 14;
const INPUT_INNER_PAD: number = 16;
/** 单行态左右让位:左边加号 42+8,右边发送键 44+8 */
const INPUT_LEFT_GAP: number = 50;
const INPUT_RIGHT_GAP: number = 52;
@Component
export struct ChatComposer {
@StorageProp('themeIsDark') private isDark: boolean = true;
@StorageProp(K_CHAT_LOADING) private loading: boolean = false;
/** 输入框是否已进入多行态(页面用它算列表底部留白) */
@Link inputMultiLine: boolean;
/** 加号菜单是否展开(同上) */
@Link attachMenuOpen: boolean;
/** 待发送附件的展示名(同上) */
@Link pendingName: string;
@State inputText: string = '';
@State pendingSize: number = 0;
@State pendingIsImage: boolean = false;
@State uploading: boolean = false;
private pendingPath: string = '';
private pendingMime: string = '';
/** 底部固定行的实测宽度:用于文字测量,判断是否需要换行 */
private inputRowWidth: number = 0;
private palette(): ThemePalette {
return this.isDark ? DARK_PALETTE : LIGHT_PALETTE;
}
/** 输入框底:高不透明度 + blur,保证背景内容不会透过输入文字 */
private inputSolidBg(): string {
return this.isDark ? 'rgba(28, 28, 30, 0.94)' : 'rgba(245, 245, 247, 0.92)';
}
/**
* 由【文本本身】判断输入框是否需要换行,而不是回读控件高度。
*
* 用 MeasureUtils 在单行态可用宽度下测量文字:宽度超了就是多行。
* 测量宽度恒定取单行态(窄)宽度,与控件当前实际宽度无关,
* 所以"多行时变宽"不会反过来改变判定结果 —— 没有反馈环,也就不抖。
*/
private recomputeMultiLine(text: string): void {
const avail: number = this.inputRowWidth - INPUT_LEFT_GAP - INPUT_RIGHT_GAP
- INPUT_INNER_PAD * 2;
if (avail <= 0) {
return;
}
let multi: boolean = text.indexOf('\n') >= 0;
if (!multi && text.length > 0) {
const opt: MeasureOptions = {
textContent: text,
fontSize: INPUT_FONT_SIZE,
};
const size: SizeOptions = this.getUIContext().getMeasureUtils().measureTextSize(opt);
// measureTextSize 返回 px,可用宽度是 vp,换算后再比
const widthVp: number = this.getUIContext().px2vp(size.width as number);
multi = widthVp > avail;
}
if (multi !== this.inputMultiLine) {
this.getUIContext().animateTo({ duration: 260, curve: Curve.Friction }, () => {
this.inputMultiLine = multi;
});
}
}
// ===================== 附件:选择与上传 =====================
/** 从图库挑一张图 */
private async pickImage(): Promise<void> {
this.getUIContext().animateTo({ duration: ANIM_NORMAL, curve: Curve.EaseOut }, () => {
this.attachMenuOpen = false;
});
try {
const options = new picker.PhotoSelectOptions();
options.MIMEType = picker.PhotoViewMIMETypes.IMAGE_TYPE;
options.maxSelectNumber = 1;
const photoPicker = new picker.PhotoViewPicker();
const result = await photoPicker.select(options);
if (result.photoUris.length === 0) {
return;
}
this.stagePickedFile(result.photoUris[0], true);
} catch (e) {
chatStore.setStage(userMessage('chat.pickImage', e));
chatStore.forceRefresh();
}
}
/** 从文件管理器挑一个文件 */
private async pickFile(): Promise<void> {
this.getUIContext().animateTo({ duration: ANIM_NORMAL, curve: Curve.EaseOut }, () => {
this.attachMenuOpen = false;
});
try {
const options = new picker.DocumentSelectOptions();
options.maxSelectNumber = 1;
const docPicker = new picker.DocumentViewPicker();
const uris: string[] = await docPicker.select(options);
if (uris.length === 0) {
return;
}
this.stagePickedFile(uris[0], false);
} catch (e) {
chatStore.setStage(userMessage('chat.pickFile', e));
chatStore.forceRefresh();
}
}
/**
* 把 picker 给的 URI 复制到应用沙箱。
* http 的 multiFormDataList.filePath 只能读应用自己的沙箱路径,
* 直接把 picker 的 media:// URI 交过去会读不到内容。
*/
private stagePickedFile(srcUri: string, isImage: boolean): void {
try {
const ctx = getContext(this) as common.UIAbilityContext;
const name: string = fileNameOf(srcUri);
const destPath: string = ctx.filesDir + '/up_' + Date.now().toString(36) + '_' + name;
const srcFile = fileIo.openSync(srcUri, fileIo.OpenMode.READ_ONLY);
const destFile = fileIo.openSync(destPath,
fileIo.OpenMode.READ_WRITE | fileIo.OpenMode.CREATE | fileIo.OpenMode.TRUNC);
fileIo.copyFileSync(srcFile.fd, destFile.fd);
fileIo.closeSync(srcFile);
fileIo.closeSync(destFile);
const stat = fileIo.statSync(destPath);
this.clearPendingFile();
this.pendingPath = destPath;
this.pendingName = name;
this.pendingSize = stat.size;
this.pendingIsImage = isImage;
this.pendingMime = mimeOf(name, isImage);
} catch (e) {
chatStore.setStage(userMessage('chat.stageFile', e));
}
chatStore.forceRefresh();
}
/** 丢弃待发送附件,并删掉沙箱里的临时副本 */
private clearPendingFile(): void {
if (this.pendingPath.length > 0) {
try {
fileIo.unlinkSync(this.pendingPath);
} catch (e) {
// 已不存在,忽略
}
}
this.pendingPath = '';
this.pendingName = '';
this.pendingSize = 0;
this.pendingIsImage = false;
this.pendingMime = '';
}
/** 发送:有附件走 multipart(POST /chat/file),否则走 POST /chat */
private async send(): Promise<void> {
if (this.loading || this.uploading) {
return;
}
// 没连后端时直接返回、且不清输入/不动附件:与拆分前 sendChat 的守卫顺序一致
if (connStore.getCurrentConnection() === null) {
return;
}
const text: string = this.inputText.trim();
if (this.pendingPath.length > 0) {
const path: string = this.pendingPath;
const name: string = this.pendingName;
const size: number = this.pendingSize;
const isImage: boolean = this.pendingIsImage;
const mime: string = this.pendingMime;
this.inputText = '';
this.inputMultiLine = false;
this.uploading = true;
await sendChatFile(text, path, name, size, isImage, mime);
this.uploading = false;
this.clearPendingFile();
chatStore.forceRefresh();
chatStore.requestScroll();
return;
}
if (text.length === 0) {
return;
}
this.inputText = '';
this.inputMultiLine = false;
await sendChatText(text);
}
// ===================== UI =====================
build() {
NavFloatOverlay({ tab: 0 }) {
// 加号展开的两个选项(图片 / 文件),点一次收起
if (this.attachMenuOpen) {
ChatAttachMenu({
onPickImage: () => {
this.pickImage();
},
onPickFile: () => {
this.pickFile();
},
})
}
// 待发送附件预览(选好图片/文件、还没点发送时显示)
if (this.pendingName.length > 0) {
ChatPendingChip({
name: this.pendingName,
byteSize: this.pendingSize,
isImage: this.pendingIsImage,
uploading: this.uploading,
onRemove: () => {
this.clearPendingFile();
chatStore.forceRefresh();
},
})
}
// Stack 而不是 Column:加号与发送按钮钉死在底部这一行不动,
// 输入框是浮在它们上面的独立层,超过一行就往上长并展开到整行宽度。
Stack({ alignContent: Alignment.Bottom }) {
// 底层:固定不动的一行 —— 左加号(图片/文件)、右发送/中断按钮
Row() {
FloatIconButton({
icon: $r('app.media.ic_plus'),
onTap: () => {
// 菜单展开会同时改变列表底部留白,用 animateTo 把
// 列表内边距和菜单进出场拉到同一个时钟上。
this.getUIContext().animateTo({ duration: ANIM_NORMAL, curve: Curve.EaseOut }, () => {
this.attachMenuOpen = !this.attachMenuOpen;
});
},
})
Blank()
if (this.loading) {
Button() {
Image($r('app.media.ic_stop'))
.width(16)
.height(16)
.fillColor(Color.White)
}
.width(44)
.height(44)
.type(ButtonType.Circle)
.backgroundColor('#77809A')
// 发送/中断切换是 if 分支整体替换,用 transition 淡入淡出
.transition(TransitionEffect.OPACITY.combine(TransitionEffect.scale({ x: 0.9, y: 0.9 })).animation({ duration: ANIM_FAST, curve: Curve.EaseOut }))
.onClick(() => {
interruptChat();
})
} else {
Button() {
Image($r('app.media.ic_send'))
.width(18)
.height(18)
.fillColor(Color.White)
}
.width(44)
.height(44)
.type(ButtonType.Circle)
.backgroundColor(this.palette().accent)
.enabled(this.inputText.trim().length > 0 || this.pendingPath.length > 0)
.transition(TransitionEffect.OPACITY.combine(TransitionEffect.scale({ x: 0.9, y: 0.9 })).animation({ duration: ANIM_FAST, curve: Curve.EaseOut }))
.onClick(() => {
this.send();
})
}
}
.width('100%')
.height(44)
.alignItems(VerticalAlign.Center)
.onAreaChange((_o: Area, n: Area) => {
// 这一行高度恒为 44、宽度恒为 100%,测量它不会形成反馈环。
const w: number = n.width as number;
if (Math.abs(w - this.inputRowWidth) > 0.5) {
this.inputRowWidth = w;
this.recomputeMultiLine(this.inputText);
}
})
// 上层:输入框。
// 单行时左右让出加号(42+8)与发送键(44+8)的位置,与它们同处一行;
// 多行时整体上移 52 抬到那一行之上,并铺满整行宽度。
//
// 之前"只上移不变宽"是因为宽度被钉死了:让宽度跟着实测高度变会形成
// 布局反馈环(变宽→文字回落成一行→变窄→又折行),卡在半弹出态抖动。
// 现在改用 MeasureUtils 直接量文字:始终按【窄宽度】测量是否需要换行,
// 判定输入只依赖文本内容,与控件实际宽度无关,所以变宽也不会自激。
Row() {
TextArea({
placeholder: '输入消息...',
text: this.inputText,
})
.layoutWeight(1)
// 不写死高度:单行 44,随文字换行自动增高,最多约 5 行后内部滚动
.constraintSize({ minHeight: 44, maxHeight: 168 })
.fontSize(INPUT_FONT_SIZE)
.fontColor(this.palette().textPrimary)
.placeholderFont({ size: 13 })
.placeholderColor(this.palette().textMuted)
.backgroundColor(this.inputSolidBg())
.backdropBlur(24)
.borderRadius(22)
.border({ width: 1, color: this.palette().glassBorder })
.padding({
left: INPUT_INNER_PAD,
right: INPUT_INNER_PAD,
top: 11,
bottom: 11,
})
.enterKeyType(EnterKeyType.Send)
.onChange((value: string) => {
this.inputText = value;
this.recomputeMultiLine(value);
})
.onSubmit(() => {
this.send();
})
}
.width('100%')
// 多行时必须显式写 0:给 .padding() 传 undefined 在增量更新时会被当作
// "不修改该属性",旧的左右 50/52 留在原地 —— 这就是"只上移不变宽"。
.padding(this.inputMultiLine
? { left: 0, right: 0 }
: { left: INPUT_LEFT_GAP, right: INPUT_RIGHT_GAP })
.margin({ bottom: this.inputMultiLine ? 52 : 0 })
// 关键:这层 Row 铺满整宽,它的左右 padding 正好压在加号与发送键上方。
// 不设 None 的话 padding 区域仍属于 Row,会把点击吞掉 —— 发送键点不动。
// None = 自身不响应、子节点(TextArea)照常响应,触摸落到下层那一行。
.hitTestBehavior(HitTestMode.None)
.animation({ duration: 260, curve: Curve.Friction })
}
.width('100%')
}
}
}

View File

@ -0,0 +1,285 @@
/**
* 聊天消息流:列表 + 顶栏遮罩 + 底部淡出遮罩 + 滚动/懒加载。
*
* 从 pages/ChatPage.ets 抽出(原来是 ChatBody 里除悬浮输入区之外的三层)。
* 消息数组来自 common/ChatStore.ets:用版本号 K_CHAT_REV 订阅,
* 版本变化时重取一次快照(数组引用每次都是新的,ForEach 的渲染语义
* 与拆分前 this.messages = this.messages.slice() 完全一致)。
*/
import { ChatMessage } from '../model/Model';
import { ThemePalette, DARK_PALETTE, LIGHT_PALETTE, ANIM_FAST, K_HAS_CONN, K_REQUESTED_TAB, K_SETTINGS_SUB } from '../common/Constants';
import { SUB_CONNECTIONS } from '../common/SettingsModel';
import { navBar } from '../common/NavBarController';
import { ChatAttachment } from '../model/Model';
import { chatStore, K_CHAT_REV, K_CHAT_SCROLL_REV, K_CHAT_LOADING, K_CHAT_STAGE } from '../common/ChatStore';
import { isChannelMsg, isSelfMsg, structSig } from '../common/ChatFormat';
import { connStore } from '../common/ConnStore';
import { ChatBubble } from './ChatBubble';
import { PageTopBar } from './PageTopBar';
@Component
export struct ChatStream {
@StorageProp('themeIsDark') private isDark: boolean = true;
/** 是否已配置后端连接(决定空态是引导连接还是引导开聊) */
@StorageProp(K_HAS_CONN) private hasConn: boolean = false;
@StorageProp(K_CHAT_LOADING) private loading: boolean = false;
@StorageProp(K_CHAT_STAGE) private stage: string = '';
/** 数组快照的订阅信号 */
@StorageProp(K_CHAT_REV) @Watch('onChatRev') private rev: number = 0;
/** "滚到底"请求信号 */
@StorageProp(K_CHAT_SCROLL_REV) @Watch('onScrollReq') private scrollRev: number = 0;
@State messages: ChatMessage[] = [];
/** 列表底部留白:随输入区展开/加号菜单/待发送附件变化 */
@Prop bottomPad: number = 210;
onOpenAttachment?: (att: ChatAttachment) => void;
private scroller: Scroller = new Scroller();
private autoScrolling: boolean = false;
/** 滚动世代号:scrollRev 每次变化自增,旧一轮的延迟滚动据此作废 */
private scrollGen: number = 0;
private navHidden: boolean = false;
aboutToAppear(): void {
this.messages = chatStore.messages();
// 首帧如果已经有消息(历史加载先于本组件挂载完成),必须自己滚到底。
//
// 为何必须补这一下:@Watch 只在值**变化**时触发,不触发初始值。
// ChatPage.aboutToAppear 里 loadHistory() 是异步的,若它在 ChatStream
// 构造之前就完成了,requestScroll 递增的 chatScrollRev 就成了“挂载前
// 已经发生的变化”——本组件的 onScrollReq 永远不会被调到,表现就是
// “消息加载好了却停在顶部/中间,不滚到最新”。
if (this.messages.length > 0) {
this.scrollToBottom();
}
}
private onChatRev(): void {
this.messages = chatStore.messages();
}
private onScrollReq(): void {
this.scrollToBottom();
}
private palette(): ThemePalette {
return this.isDark ? DARK_PALETTE : LIGHT_PALETTE;
}
/**
* 底部淡出遮罩的两个端色:背景底色的全不透明 / 全透明版本。
* bgPrimary 是 6 位十六进制,这里手拼 8 位 ARGB —— 与 PageTopBar
* 顶部淡出用的是同一手法,保证上下两端的融入观感一致。
*/
private opaqueBottomBg(): string {
return '#FF' + this.palette().bgPrimary.substring(1);
}
private transparentBottomBg(): string {
return '#00' + this.palette().bgPrimary.substring(1);
}
private scrollToBottom(): void {
this.autoScrolling = true;
// 多次重试:内容高度是消息数组更新后**若干帧内**才逐步确定的,
// 长历史 / Markdown / 思考卡 / 工具卡布局都慢。旧实现只重试到 260ms,
// 长历史下那一次仍落在“当时”的底部(用户看到的是加载完停在中间)。
// 用递增间隔重试到 ~1s,让后几帧的布局增长也跟得上。
//
// scrollRev 变化时旧一轮的定时器不能继续干预新滚动,用世代号作废。
const gen: number = ++this.scrollGen;
const delays: number[] = [50, 120, 220, 360, 550, 800];
for (let i = 0; i < delays.length; i++) {
setTimeout(() => {
if (gen !== this.scrollGen) {
return;
}
this.scroller.scrollEdge(Edge.Bottom);
}, delays[i]);
}
setTimeout(() => {
if (gen !== this.scrollGen) {
return;
}
this.autoScrolling = false;
this.navHidden = false;
navBar.setVisible(true);
}, 900);
}
/**
* 滚动回调:只设置普通标志位,仅在状态翻转时通知 navBar,
* 不在回调里做任何耗时操作。navBar.setVisible 内部已去重,
* 而布局(padding)不再依赖 navVisible,故翻转只触发 GPU 变换,
* 不会引起布局回流——这是滑动流畅的关键。
*/
private handleScrollDirection(yOffset: number, state: ScrollState): void {
if (this.autoScrolling) {
return;
}
// 触顶(近顶部 60vp)且服务端还有更早历史 → 向上懒加载下一页
if (yOffset < 60 && chatStore.hasMore()) {
chatStore.loadOlder();
}
if (state === ScrollState.Idle) {
if (this.navHidden) {
this.navHidden = false;
navBar.setVisible(true);
}
} else {
// Scroll / Fling:向下/惯性滚动时隐藏导航与输入栏
if (!this.navHidden) {
this.navHidden = true;
navBar.setVisible(false);
}
}
}
build() {
Stack({ alignContent: Alignment.Bottom }) {
// 层1:消息列表(铺满全屏,内容从顶栏遮罩下方穿过时逐渐淡出)
Column() {
Scroll(this.scroller) {
Column() {
ForEach(this.messages, (msg: ChatMessage, idx: number) => {
ChatBubble({
msgId: msg.id,
role: msg.role,
content: msg.content,
isStreaming: msg.isStreaming === true,
isFinal: msg.isFinal === true,
reasoningContent: msg.reasoningContent ?? '',
reasoningOpen: msg.reasoningOpen === true,
toolCalls: msg.toolCalls ?? [],
attachment: msg.attachment,
source: msg.source ?? '',
channel: isChannelMsg(msg.source ?? '', connStore.ensureDeviceId()),
mine: isSelfMsg(msg.role, isChannelMsg(msg.source ?? '', connStore.ensureDeviceId())),
fresh: chatStore.isFresh(msg.id),
onOpenAttachment: (att: ChatAttachment) => {
const cb: ((a: ChatAttachment) => void) | undefined = this.onOpenAttachment;
if (cb !== undefined) {
cb(att);
}
},
onToggleReasoning: (id: number) => {
// 在 animateTo 里翻转:展开/收起时 chevron 走已有 .animation,
// 面板节点在 animateTo 帧内获得默认过渡,不会再硬切。
this.getUIContext().animateTo({ duration: 220, curve: Curve.EaseOut }, () => {
chatStore.setReasoningOpen(id, !chatStore.reasoningOpen(id));
chatStore.forceRefresh();
});
},
onToggleTool: (id: number, index: number) => {
this.getUIContext().animateTo({ duration: 220, curve: Curve.EaseOut }, () => {
chatStore.setToolOpen(id, index, !chatStore.toolOpen(id, index));
chatStore.forceRefresh();
});
},
})
}, (msg: ChatMessage, idx: number) => structSig(msg))
if (this.loading) {
Row({ space: 8 }) {
LoadingProgress()
.width(16)
.height(16)
.color(this.palette().accent)
Text(this.stage.length > 0 ? this.stage : '处理中...')
.fontSize(12)
.fontColor(this.palette().textMuted)
}
.width('100%')
.justifyContent(FlexAlign.Start)
.padding({ left: 52, top: 6, bottom: 6 })
// if 控制的节点无法用 .animation() 做进出场(那只驱动自身属性的增量更新);
// 用 transition 才能让"处理中"这条在出现和消失时都淡入淡出。
.transition(TransitionEffect.OPACITY.animation({ duration: ANIM_FAST, curve: Curve.EaseOut }))
}
}
.width('100%')
.padding({
left: 14,
right: 14,
top: 76,
bottom: this.bottomPad,
})
}
.width('100%')
.height('100%')
.scrollBar(BarState.Off)
.edgeEffect(EdgeEffect.Spring)
.align(Alignment.Top)
.onDidScroll((xOffset: number, yOffset: number, state: ScrollState) => {
this.handleScrollDirection(yOffset, state);
})
}
.width('100%')
.height('100%')
// 层1.05:空态 —— 未连接后端时给出明确的“去设置连接”入口。
//
// 为什么必须有:全新安装时聊天页只有一条空列表 + 输入框,用户看不到
// 任何连后端的入口(入口在设置页的二级页里,很容易找不到)。
if (this.messages.length === 0 && !this.loading) {
Column({ space: 10 }) {
Image($r('app.media.ic_link'))
.width(34)
.height(34)
.fillColor(this.palette().textMuted)
.draggable(false)
Text(this.hasConn ? '开始新的对话' : '尚未连接后端服务')
.fontSize(15)
.fontWeight(FontWeight.Medium)
.fontColor(this.palette().textPrimary)
Text(this.hasConn
? '在下方输入框发送第一条消息'
: '请先在“后端连接”里填写服务地址与 API Key')
.fontSize(12)
.fontColor(this.palette().textMuted)
.textAlign(TextAlign.Center)
if (!this.hasConn) {
Button('去设置连接')
.height(34)
.fontSize(13)
.backgroundColor(this.palette().accent)
.fontColor(Color.White)
.margin({ top: 4 })
.onClick(() => {
// 跨页信号:切到设置 Tab,并让设置页直接打开连接二级页
AppStorage.setOrCreate<string>(K_SETTINGS_SUB, SUB_CONNECTIONS);
AppStorage.setOrCreate<number>(K_REQUESTED_TAB, 3);
})
}
}
.width('100%')
.height('100%')
.padding({ left: 44, right: 44 })
.justifyContent(FlexAlign.Center)
.alignItems(HorizontalAlign.Center)
// 自身不吃触摸(空白处仍可滑列表),但子节点(按钮)正常响应
.hitTestBehavior(HitTestMode.Transparent)
}
// 层1.5:顶栏遮罩(自身撑满并顶部对齐,全链路 hitTest None,触摸完全穿透)
PageTopBar({ title: '聊天' })
// 层1.6:底部淡出遮罩 —— 滚动内容接近悬浮输入区/底部导航时逐渐隐入背景,
// 而不是在玻璃后面清晰可见(PageTopBar 顶部淡出手法的镜像,方向相反)。
Column()
.width('100%')
.height(170)
.linearGradient({
direction: GradientDirection.Bottom,
colors: [
[this.transparentBottomBg(), 0.0],
[this.opaqueBottomBg(), 0.6],
[this.opaqueBottomBg(), 1.0],
],
})
.hitTestBehavior(HitTestMode.None)
}
.width('100%')
.height('100%')
}
}

View File

@ -0,0 +1,253 @@
/**
* 气泡内的两张"面板"卡:思考过程卡 + 工具调用卡。
*
* 从 pages/ChatPage.ets 抽出(原来分别是 ReasoningCard / ToolCard 两个 @Builder)。
* 折叠状态与开关动作都交回调用方(状态在 chatStore 里,且展开/收起要在
* animateTo 帧内完成 —— 那需要组件上下文)。
*/
import { ToolCallInfo } from '../model/Model';
import { ThemePalette, DARK_PALETTE, LIGHT_PALETTE, RADIUS_SM,
ANIM_NORMAL } from '../common/Constants';
import { tcRunning, tcError, tcLeftColor, tcIcoColor, tcStateLabel, tcStateColor } from '../common/ChatFormat';
@Component
export struct ChatReasoningCard {
@StorageProp('themeIsDark') private isDark: boolean = true;
/** 思考正文(已折叠时也带着,展开不再请求) */
@Prop content: string = '';
@Prop open: boolean = false;
/** 流式中:显示转圈 + 扫光条 */
@Prop sweeping: boolean = false;
/** 入场动画阶段:扫光条起始偏移靠它切换 */
@Prop fresh: boolean = false;
onToggle?: () => void;
private palette(): ThemePalette {
return this.isDark ? DARK_PALETTE : LIGHT_PALETTE;
}
build() {
// 两层结构,原因见 ChatBubble 的布局说明:
// 外层 Row 是"外观壳"(虚线边框 / 底色 / 圆角),不设百分比宽度,
// 靠内层 layoutWeight(1) 把气泡内容框的剩余宽度吃满;
// 内层 holder Column 自身无 padding,所以它的子节点写 width('100%')
// 才有正确的解析基准,不会再溢出到气泡外被 clip 切掉。
Row() {
Column() {
Row({ space: 7 }) {
Image($r('app.media.ic_sparkle'))
.width(12)
.height(12)
.fillColor(this.palette().accent)
Text('思考过程')
.fontSize(11)
.fontWeight(FontWeight.Medium)
.fontColor(this.palette().textPrimary)
// 流式思考时给出明确进度指示,而不是一张看不出在动的折叠卡
if (this.sweeping) {
LoadingProgress()
.width(11)
.height(11)
.color(this.palette().accent)
}
Blank()
Text(this.content.length > 0 ? this.content.length.toString() + ' 字' : '')
.fontSize(9.5)
.fontColor(this.palette().textMuted)
Image($r('app.media.ic_chevron_down'))
.width(14)
.height(14)
.fillColor(this.palette().textMuted)
.rotate({ angle: this.open ? 180 : 0 })
.animation({ duration: 200, curve: Curve.EaseOut })
}
.width('100%')
.padding({ left: 10, right: 10, top: 6, bottom: 6 })
.onClick(() => {
const cb: (() => void) | undefined = this.onToggle;
if (cb !== undefined) {
cb();
}
})
if (this.open) {
Text(this.content)
.fontSize(11.5)
.lineHeight(17)
.fontColor(this.palette().textTertiary)
.width('100%')
.padding({ left: 10, right: 10, bottom: 8 })
.maxLines(24)
.textOverflow({ overflow: TextOverflow.Ellipsis })
.wordBreak(WordBreak.BREAK_ALL)
// 面板内容靠 if 挂载:用 transition 在展开/收起时淡入淡出
.transition(TransitionEffect.OPACITY.combine(TransitionEffect.translate({ y: -6 })).animation({ duration: ANIM_NORMAL, curve: Curve.EaseOut }))
}
// 流式思考中:扫光动画条(对齐 WebGUI reasoningSweep)
if (this.sweeping) {
Stack() {
Row()
.height(2)
.borderRadius(2)
.width('200%')
.linearGradient({
angle: 90,
colors: [
['rgba(255,255,255,0.01)', 0],
[this.palette().accent, 0.35],
['rgba(255,255,255,0.01)', 0.5],
[this.palette().accent, 0.65],
['rgba(255,255,255,0.01)', 1],
],
})
.opacity(0.7)
.translate({ x: this.fresh ? '0%' : '-50%' })
.animation({ duration: 1200, curve: Curve.Linear })
}
.width('100%')
.clip(true)
.height(2)
.margin({ top: 6 })
}
}
.layoutWeight(1)
.alignItems(HorizontalAlign.Start)
}
.alignItems(VerticalAlign.Top)
.margin({ bottom: 6 })
.borderRadius(RADIUS_SM)
.backgroundColor(this.palette().bgHover)
.border({ width: 1, color: this.palette().kvBorder, style: BorderStyle.Dashed })
}
}
@Component
export struct ChatToolCard {
@StorageProp('themeIsDark') private isDark: boolean = true;
@Prop tc: ToolCallInfo;
/** 在所属消息 toolCalls 里的下标:开关动作要交回调用方按 (msgId, index) 定位 */
@Prop index: number = 0;
onToggle?: (index: number) => void;
private palette(): ThemePalette {
return this.isDark ? DARK_PALETTE : LIGHT_PALETTE;
}
build() {
// 同 ChatReasoningCard:外层 Row 只做外观,内层 layoutWeight(1) 取真实内容宽
Row() {
Column() {
Row({ space: 6 }) {
if (tcError(this.tc)) {
Image($r('app.media.ic_error'))
.width(13).height(13)
.fillColor(tcIcoColor(this.tc, this.palette().accent))
} else if (tcRunning(this.tc)) {
LoadingProgress()
.width(12).height(12)
.color(tcIcoColor(this.tc, this.palette().accent))
} else {
Image($r('app.media.ic_check'))
.width(13).height(13)
.fillColor(tcIcoColor(this.tc, this.palette().accent))
}
Text(this.tc.name)
.fontSize(11)
.fontWeight(FontWeight.Medium)
.fontColor(this.palette().textPrimary)
.maxLines(1)
.textOverflow({ overflow: TextOverflow.Ellipsis })
// 名字可长可短,必须让它占剩余宽度并可收缩,
// 否则右侧状态文字会被挤出气泡(78% 宽度 + clip 直接切掉)
.layoutWeight(1)
if (this.tc.plugin !== undefined && this.tc.plugin.length > 0) {
Text(this.tc.plugin)
.fontSize(9.5)
.fontColor(this.palette().textMuted)
.maxLines(1)
.flexShrink(0)
}
// 状态徽标去掉,只留一行小字(用户要求"去掉所有状态徽标")
Text(tcStateLabel(this.tc))
.fontSize(9.5)
.fontWeight(FontWeight.Medium)
.fontColor(tcStateColor(this.tc))
.flexShrink(0)
Image($r('app.media.ic_chevron_down'))
.width(13).height(13)
.fillColor(this.palette().textMuted)
.flexShrink(0)
.rotate({ angle: this.tc.open === true ? 180 : 0 })
.animation({ duration: 150, curve: Curve.EaseOut })
}
.width('100%')
.alignItems(VerticalAlign.Center)
.onClick(() => {
const cb: ((index: number) => void) | undefined = this.onToggle;
if (cb !== undefined) {
cb(this.index);
}
})
if (this.tc.open === true) {
Column() {
if (this.tc.args.length > 0 && this.tc.args !== '{}') {
Text('参数')
.fontSize(9.5).fontWeight(FontWeight.Medium)
.fontColor(this.palette().textMuted)
.margin({ top: 6, bottom: 2 })
Text(this.tc.args)
.fontSize(11)
.fontColor(this.palette().preText)
.backgroundColor(this.palette().preBg)
.borderRadius(4)
.padding({ left: 7, right: 7, top: 5, bottom: 5 })
.width('100%')
.textAlign(TextAlign.Start)
.wordBreak(WordBreak.BREAK_ALL)
}
if (this.tc.result !== undefined && this.tc.result.length > 0) {
Text('结果')
.fontSize(9.5).fontWeight(FontWeight.Medium)
.fontColor(this.palette().textMuted)
.margin({ top: 6, bottom: 2 })
Text(this.tc.result)
.fontSize(11)
.fontColor(this.palette().preText)
.backgroundColor(this.palette().preBg)
.borderRadius(4)
.padding({ left: 7, right: 7, top: 5, bottom: 5 })
.width('100%')
.textAlign(TextAlign.Start)
.wordBreak(WordBreak.BREAK_ALL)
.maxLines(8)
.textOverflow({ overflow: TextOverflow.Ellipsis })
}
}
.width('100%')
.alignItems(HorizontalAlign.Start)
// 展开内容整体用 if 挂载:transition 让参数/结果随 chevron 一起淡入
.transition(TransitionEffect.OPACITY.combine(TransitionEffect.translate({ y: -6 })).animation({ duration: ANIM_NORMAL, curve: Curve.EaseOut }))
}
}
.layoutWeight(1)
.alignItems(HorizontalAlign.Start)
}
.alignItems(VerticalAlign.Top)
.padding({ left: 10, right: 10, top: 7, bottom: 7 })
.margin({ bottom: 4 })
.borderRadius(RADIUS_SM)
.backgroundColor(this.palette().bgHover)
.border({
width: { left: 3, top: 1, right: 1, bottom: 1 },
color: {
left: tcLeftColor(this.tc, this.palette().accent),
top: this.palette().kvBorder,
right: this.palette().kvBorder,
bottom: this.palette().kvBorder,
},
})
}
}

View File

@ -0,0 +1,356 @@
/**
* 「后端连接」二级页面。
*
* 从 pages/SettingsPage.ets 抽出:连接列表 UI、增删改表单与其状态、
* 以及切换连接后必须做的连带动作(刷新 ApiClient / 重启前台桥)
* 都属于这一个功能域,收在一个组件里。
*
* connections / currentId 用 @Link 与一级页面共享:一级页的入口行
* 要显示"几个连接配置"和当前连接名,两边必须是同一份数据。
*/
import { apiClient } from '../common/ApiClient';
import { connStore } from '../common/ConnStore';
import { restartForegroundBridge } from '../common/DeviceBridgeSession';
import { ConnectionConfig } from '../model/Model';
import { ThemePalette, DARK_PALETTE, LIGHT_PALETTE, RADIUS_MD, RADIUS_SM, K_HAS_CONN } from '../common/Constants';
import { SubPageLayer, PlainCard } from './SubPage';
import { common } from '@kit.AbilityKit';
@Component
export struct ConnectionsPane {
@StorageProp('themeIsDark') private isDark: boolean = true;
@Link connections: ConnectionConfig[];
@Link currentId: string;
onBack?: () => void;
onToast?: (msg: string, isError: boolean) => void;
@State showAddForm: boolean = false;
@State addFormVisible: boolean = false;
/**
* 表单当前在编辑哪条连接:空串表示新建。
*
* 之前只有"添加"入口,ConnStore.updateConnection 写好了却没有任何调用者,
* 于是地址填错的连接只能删掉重建(API Key 也得重敲)。同一套表单
* 靠这个 id 区分保存走 add 还是 update。
*/
@State editingId: string = '';
@State editUrl: string = '';
@State editApiKey: string = '';
@State editName: string = '';
private palette(): ThemePalette {
return this.isDark ? DARK_PALETTE : LIGHT_PALETTE;
}
private toast(msg: string, isError: boolean): void {
const cb: ((m: string, e: boolean) => void) | undefined = this.onToast;
if (cb !== undefined) {
cb(msg, isError);
}
}
/** 连接变更后广播状态:聊天空态据此隐藏“去设置连接”入口。 */
private syncConnFlag(): void {
AppStorage.setOrCreate<boolean>(K_HAS_CONN, apiClient.hasConnection());
}
private currentConnName(): string {
for (let i = 0; i < this.connections.length; i++) {
if (this.connections[i].id === this.currentId) {
return this.connections[i].name;
}
}
return '未配置';
}
private selectConnection(id: string): void {
connStore.setCurrent(id).then(() => {
const cur: ConnectionConfig | null = connStore.getCurrentConnection();
if (cur !== null) {
apiClient.setConnection(cur);
}
this.syncConnFlag();
this.connections = connStore.getConnections();
restartForegroundBridge(getContext(this) as common.UIAbilityContext);
this.toast('已切换连接', false);
});
}
private addConnection(): void {
const name: string = this.editName.trim();
const url: string = this.editUrl.trim();
const apiKey: string = this.editApiKey.trim();
if (name.length === 0 || url.length === 0) {
this.toast('名称和地址不能为空', true);
return;
}
if (this.editingId.length > 0) {
this.updateConnection(this.editingId, name, url, apiKey);
return;
}
connStore.addConnection(name, url, apiKey).then(() => {
this.closeConnForm();
const cur = connStore.getCurrentConnection();
if (cur !== null) {
apiClient.setConnection(cur);
}
this.syncConnFlag();
this.connections = connStore.getConnections();
restartForegroundBridge(getContext(this) as common.UIAbilityContext);
this.toast('连接已添加', false);
});
}
/**
* 保存对已有连接的修改。
*
* 修改当前生效的连接后必须重新 setConnection:ApiClient 持有的是
* ConnectionConfig 的引用快照,不刷新的话后续请求还会打到旧地址。
*/
private updateConnection(id: string, name: string, url: string, apiKey: string): void {
connStore.updateConnection(id, name, url, apiKey).then(() => {
this.closeConnForm();
const cur = connStore.getCurrentConnection();
if (cur !== null) {
apiClient.setConnection(cur);
}
this.syncConnFlag();
this.connections = connStore.getConnections();
restartForegroundBridge(getContext(this) as common.UIAbilityContext);
this.toast('连接已更新', false);
});
}
/** 打开表单:id 为空是新建,非空是编辑并回填原值(API Key 一并带出,避免用户重敲)。 */
private openConnForm(conn: ConnectionConfig | null): void {
this.showAddForm = true;
this.addFormVisible = false;
if (conn === null) {
this.editingId = '';
this.editName = '';
this.editUrl = '';
this.editApiKey = '';
} else {
this.editingId = conn.id;
this.editName = conn.name;
this.editUrl = conn.url;
this.editApiKey = conn.apiKey;
}
setTimeout(() => {
this.addFormVisible = true;
}, 30);
}
private closeConnForm(): void {
this.showAddForm = false;
this.addFormVisible = false;
this.editingId = '';
this.editName = '';
this.editUrl = '';
this.editApiKey = '';
}
private deleteConnection(id: string): void {
connStore.deleteConnection(id).then(() => {
this.connections = connStore.getConnections();
const cur: ConnectionConfig | null = connStore.getCurrentConnection();
if (cur !== null) {
apiClient.setConnection(cur);
} else {
apiClient.clearConnection();
}
this.syncConnFlag();
restartForegroundBridge(getContext(this) as common.UIAbilityContext);
this.toast('连接已删除', false);
});
}
build() {
SubPageLayer({
title: '后端连接',
tab: 3,
onBack: () => {
const cb: (() => void) | undefined = this.onBack;
if (cb !== undefined) {
cb();
}
},
}) {
Column() {
PlainCard({ caption: '当前连接' }) {
Row() {
Column({ space: 3 }) {
Text(this.currentConnName())
.fontSize(15)
.fontColor(this.palette().textPrimary)
Text(this.currentId.length > 0 ? '已激活,用于所有请求' : '尚未选择连接')
.fontSize(11)
.fontColor(this.palette().textMuted)
}
.layoutWeight(1)
.alignItems(HorizontalAlign.Start)
Button('+ 添加')
.height(30)
.fontSize(12)
.backgroundColor(this.palette().accent)
.fontColor(Color.White)
.onClick(() => {
this.openConnForm(null);
})
}
.width('100%')
.alignItems(VerticalAlign.Center)
if (this.showAddForm) {
Column() {
Text(this.editingId.length > 0 ? '编辑连接' : '新建连接')
.fontSize(12)
.fontColor(this.palette().textSecondary)
.margin({ bottom: 10 })
TextInput({ placeholder: '名称 (如 HomeAgent)', text: this.editName })
.height(36).fontSize(13).fontColor(this.palette().textPrimary)
.placeholderColor(this.palette().textMuted).backgroundColor(this.palette().bgInput)
.borderRadius(RADIUS_SM).border({ width: 1, color: this.palette().border })
.margin({ bottom: 10 })
.onChange((v: string) => {
this.editName = v;
})
TextInput({ placeholder: '地址 (域名或 http://192.168.1.100:8080)', text: this.editUrl })
.height(36).fontSize(13).fontColor(this.palette().textPrimary)
.placeholderColor(this.palette().textMuted).backgroundColor(this.palette().bgInput)
.borderRadius(RADIUS_SM).border({ width: 1, color: this.palette().border })
.margin({ bottom: 10 })
.onChange((v: string) => {
this.editUrl = v;
})
TextInput({ placeholder: 'API Key (可选)', text: this.editApiKey })
.height(36).fontSize(13).fontColor(this.palette().textPrimary)
.placeholderColor(this.palette().textMuted).backgroundColor(this.palette().bgInput)
.borderRadius(RADIUS_SM).border({ width: 1, color: this.palette().border })
.type(InputType.Password).margin({ bottom: 12 })
.onChange((v: string) => {
this.editApiKey = v;
})
Row() {
Button('取消')
.height(30)
.fontSize(12)
.backgroundColor(Color.Transparent)
.border({ width: 1, color: this.palette().btnGhostBorder })
.fontColor(this.palette().textSecondary)
.onClick(() => {
this.closeConnForm();
})
Blank()
Button('保存')
.height(30)
.fontSize(12)
.backgroundColor(this.palette().accent)
.fontColor(Color.White)
.onClick(() => {
this.addConnection();
})
}
.width('100%')
}
.width('100%')
.padding(12)
.borderRadius(RADIUS_MD)
.backgroundColor(this.palette().bgHover)
.border({ width: 1, color: this.palette().kvBorder })
.margin({ top: 12 })
.alignItems(HorizontalAlign.Start)
.opacity(this.addFormVisible ? 1 : 0)
.translate({ y: this.addFormVisible ? 0 : 12 })
.animation({ duration: 220, curve: Curve.EaseOut })
}
}
PlainCard({ caption: '全部连接' }) {
if (this.connections.length === 0) {
Text('暂无连接。点击上方“添加”配置后端地址。')
.fontSize(12)
.fontColor(this.palette().textMuted)
}
ForEach(this.connections, (conn: ConnectionConfig) => {
Row() {
Circle({ width: 8, height: 8 })
.fill(conn.id === this.currentId ? this.palette().accent : '#77809A')
.margin({ right: 10 })
Column() {
Text(conn.name)
.fontSize(13)
.fontColor(this.palette().textPrimary)
.maxLines(1)
.textOverflow({ overflow: TextOverflow.Ellipsis })
Text(conn.url)
.fontSize(11)
.fontColor(this.palette().textMuted)
.maxLines(1)
.textOverflow({ overflow: TextOverflow.Ellipsis })
}
.layoutWeight(1)
.alignItems(HorizontalAlign.Start)
if (conn.id !== this.currentId) {
Button('切换')
.height(26)
.fontSize(11)
.backgroundColor(Color.Transparent)
.border({ width: 1, color: this.palette().btnGhostBorder })
.fontColor(this.palette().textSecondary)
.margin({ right: 6 })
.onClick(() => {
this.selectConnection(conn.id);
})
} else {
Text('使用中')
.fontSize(11)
.fontColor(this.palette().accent)
.padding({ left: 8, right: 8, top: 2, bottom: 2 })
.borderRadius(RADIUS_SM)
.backgroundColor(this.palette().accentBg)
.margin({ right: 6 })
}
Button('编辑')
.height(26)
.fontSize(11)
.backgroundColor(Color.Transparent)
.border({ width: 1, color: this.palette().btnGhostBorder })
.fontColor(this.palette().textSecondary)
.margin({ right: 6 })
.onClick(() => {
this.openConnForm(conn);
})
Button('删除')
.height(26)
.fontSize(11)
.backgroundColor(Color.Transparent)
.border({ width: 1, color: 'rgba(232, 64, 38, 0.45)' })
.fontColor('#E84026')
.onClick(() => {
this.deleteConnection(conn.id);
})
}
.width('100%')
.padding(10)
.borderRadius(RADIUS_SM)
.backgroundColor(this.palette().bgHover)
.border({
width: { left: 3 },
color: conn.id === this.currentId ? this.palette().accent : Color.Transparent,
})
.margin({ bottom: 6 })
// 键里带上 name/url:ForEach 对相同键只更新绑定、不重跑 @Builder 体,
// 只用 id 做键时改完地址这一行还显示旧值。行内没有 TextInput,
// 因此把可变字段放进键不会有"编辑时焦点被销毁"的副作用。
}, (conn: ConnectionConfig) => conn.id + '|' + conn.name + '|' + conn.url)
}
}
.width('100%')
.alignItems(HorizontalAlign.Start)
}
}
}

View File

@ -0,0 +1,316 @@
/**
* 设备页的四个二级页面内容:本机设备 / 设备能力 / 设备通道 / 接入的设备。
*
* 从 pages/DevicePage.ets 抽出(原来是 LocalDeviceContent / CapsContent /
* GatewayContent / OnlineDevicesContent 四个 @Builder + KvRow)。
* 每个面板自带 SubPageLayer 外壳(标题、所属 Tab、返回、刷新),
* 页面只保留路由分发 —— 与 SettingsPage 拆出的三个 Pane 同一套做法。
*/
import { DeviceInfo } from '../model/Model';
import { ThemePalette, DARK_PALETTE, LIGHT_PALETTE, ANIM_FAST, ANIM_NORMAL,
ANIM_ENTER } from '../common/Constants';
import { LOCAL_DEVICE_CAPS } from '../common/DeviceBridgeSession';
import { MotionBase } from './MotionBase';
import { PlainCard, SubPageLayer } from './SubPage';
/** 通用 KV 行(面板之间共用) */
@Component
export struct DeviceKvRow {
@StorageProp('themeIsDark') private isDark: boolean = true;
@Prop label: string = '';
@Prop value: string = '';
private palette(): ThemePalette {
return this.isDark ? DARK_PALETTE : LIGHT_PALETTE;
}
build() {
Row() {
Text(this.label)
.fontSize(13)
.fontColor(this.palette().textSecondary)
Blank()
Text(this.value)
.fontSize(13)
.fontColor(this.palette().textPrimary)
.maxLines(1)
.textOverflow({ overflow: TextOverflow.Ellipsis })
}
.width('100%')
.padding({ top: 8, bottom: 8 })
.border({ width: { bottom: 1 }, color: this.palette().kvBorder })
}
}
/** 二级:本机设备(基本信息 + 远程控制授权) */
@Component
export struct DeviceLocalPane {
@StorageProp('themeIsDark') private isDark: boolean = true;
@Prop deviceId: string = '';
@Prop authorized: boolean = false;
onBack?: () => void;
onToggleAuth?: (on: boolean) => void;
private palette(): ThemePalette {
return this.isDark ? DARK_PALETTE : LIGHT_PALETTE;
}
build() {
SubPageLayer({
title: '本机设备',
tab: 2,
onBack: () => {
const cb: (() => void) | undefined = this.onBack;
if (cb !== undefined) {
cb();
}
},
}) {
PlainCard({ caption: '基本信息' }) {
DeviceKvRow({ label: '设备 ID', value: this.deviceId.length > 0 ? this.deviceId : '未注册' })
DeviceKvRow({ label: '名称', value: 'HomeAgent OHOS' })
DeviceKvRow({ label: '类型', value: 'phone' })
}
PlainCard({ caption: '权限控制' }) {
Row() {
Column({ space: 2 }) {
Text('允许 agent 控制本机')
.fontSize(14)
.fontColor(this.palette().textPrimary)
Text('授权后 agent 可调用下方能力;截屏仅捕获本应用画面,剪贴板读取需系统弹窗确认。')
.fontSize(11)
.fontColor(this.palette().textMuted)
.margin({ top: 4 })
}
.layoutWeight(1)
.alignItems(HorizontalAlign.Start)
Toggle({ type: ToggleType.Switch, isOn: this.authorized })
.selectedColor(this.palette().accent)
.onChange((on: boolean) => {
const cb: ((on: boolean) => void) | undefined = this.onToggleAuth;
if (cb !== undefined) {
cb(on);
}
})
}
.width('100%')
.alignItems(VerticalAlign.Center)
Row() {
Circle({ width: 8, height: 8 })
.fill(this.authorized ? '#17A964' : '#E84026')
.animation({ duration: ANIM_NORMAL, curve: Curve.EaseOut })
.margin({ right: 8 })
Text(this.authorized ? '已授权 — agent 可远程调用能力' : '未授权 — agent 将拒绝远程命令')
.fontSize(12)
.fontColor(this.authorized ? '#17A964' : this.palette().textMuted)
.animation({ duration: ANIM_NORMAL, curve: Curve.EaseOut })
}
.width('100%')
.margin({ top: 12 })
.padding({ left: 4 })
}
}
}
}
/** 二级:设备能力(本机能被 agent 调用的能力清单) */
@Component
export struct DeviceCapsPane {
@StorageProp('themeIsDark') private isDark: boolean = true;
onBack?: () => void;
private palette(): ThemePalette {
return this.isDark ? DARK_PALETTE : LIGHT_PALETTE;
}
build() {
SubPageLayer({
title: '设备能力',
tab: 2,
onBack: () => {
const cb: (() => void) | undefined = this.onBack;
if (cb !== undefined) {
cb();
}
},
}) {
PlainCard({ caption: '能力清单' }) {
Text('agent 通过设备桥可调用的本机能力:')
.fontSize(12)
.fontColor(this.palette().textMuted)
.margin({ bottom: 10 })
Flex({ wrap: FlexWrap.Wrap }) {
ForEach(LOCAL_DEVICE_CAPS, (cap: string) => {
Text(cap)
.fontSize(11)
.fontColor(this.palette().accent)
.padding({ left: 8, right: 8, top: 4, bottom: 4 })
.borderRadius(999)
.backgroundColor(this.palette().bgHover)
.border({ width: 1, color: this.palette().glassBorder })
.margin({ right: 6, bottom: 6 })
}, (cap: string) => cap)
}
.width('100%')
}
}
}
}
/** 二级:设备通道(网关地址 / Token / 连接状态) */
@Component
export struct DeviceGatewayPane {
@StorageProp('themeIsDark') private isDark: boolean = true;
@Prop bridgeUrl: string = '';
@Prop bridgeToken: string = '';
@Prop bridgeConnected: boolean = false;
onBack?: () => void;
onRefresh?: () => void;
private palette(): ThemePalette {
return this.isDark ? DARK_PALETTE : LIGHT_PALETTE;
}
build() {
SubPageLayer({
title: '设备通道',
tab: 2,
onBack: () => {
const cb: (() => void) | undefined = this.onBack;
if (cb !== undefined) {
cb();
}
},
}) {
PlainCard({ caption: '连接信息' }) {
DeviceKvRow({ label: '网关地址', value: this.bridgeUrl.length > 0 ? this.bridgeUrl : '-' })
DeviceKvRow({ label: 'Token', value: this.bridgeToken.length > 0 ? '已从连接继承' : '未配置' })
DeviceKvRow({ label: '状态', value: this.bridgeConnected ? '已连接' : '未连接' })
}
PlainCard({ caption: '操作' }) {
Row() {
Blank()
MotionBase({ pressEnabled: true, fillWidth: false }) {
Button('刷新设备')
.height(34)
.fontSize(12)
.backgroundColor(Color.Transparent)
.border({ width: 1, color: this.palette().btnGhostBorder })
.fontColor(this.palette().textSecondary)
.onClick(() => {
const cb: (() => void) | undefined = this.onRefresh;
if (cb !== undefined) {
cb();
}
})
}
}
.width('100%')
Text('设备通道由应用前台生命周期统一管理;切换连接配置后会自动使用新地址和 Token。')
.fontSize(11)
.fontColor(this.palette().textMuted)
.margin({ top: 10 })
}
}
}
}
/** 二级:接入的设备(网关侧在线设备列表) */
@Component
export struct DeviceListPane {
@StorageProp('themeIsDark') private isDark: boolean = true;
@Prop devices: DeviceInfo[] = [];
onBack?: () => void;
onRefresh?: () => void;
private palette(): ThemePalette {
return this.isDark ? DARK_PALETTE : LIGHT_PALETTE;
}
build() {
SubPageLayer({
title: '接入的设备',
tab: 2,
showRefresh: true,
onBack: () => {
const cb: (() => void) | undefined = this.onBack;
if (cb !== undefined) {
cb();
}
},
onRefresh: () => {
const cb: (() => void) | undefined = this.onRefresh;
if (cb !== undefined) {
cb();
}
},
}) {
DeviceOnlineList({ devices: this.devices })
}
}
}
/** 在线设备列表本体(抽出来只是为了让 DeviceListPane 的 build 更短) */
@Component
struct DeviceOnlineList {
@StorageProp('themeIsDark') private isDark: boolean = true;
@Prop devices: DeviceInfo[] = [];
private palette(): ThemePalette {
return this.isDark ? DARK_PALETTE : LIGHT_PALETTE;
}
build() {
Column() {
if (this.devices.length === 0) {
Text('暂无其他设备。电脑 GUI 或 CLI 连接同一网关后会出现在这里。')
.fontSize(12)
.fontColor(this.palette().textMuted)
.padding({ left: 4 })
.transition(TransitionEffect.OPACITY.animation({ duration: ANIM_FAST, curve: Curve.EaseOut }))
}
ForEach(this.devices, (dev: DeviceInfo) => {
// PlainCard 是自定义组件,transition 不能直接挂在它上面(会生成 __Common__ 包装),
// 所以用一个无 padding、满宽的 Column 承载入场动画,布局不受影响。
Column() {
PlainCard({ caption: '' }) {
Row() {
Circle({ width: 8, height: 8 })
.fill(dev.online ? '#17A964' : '#77809A')
.margin({ right: 10 })
Column() {
Text(dev.name.length > 0 ? dev.name : dev.deviceId)
.fontSize(14)
.fontColor(this.palette().textPrimary)
Text(dev.kind + (dev.authorized ? ' · 已授权' : ' · 未授权'))
.fontSize(11)
.fontColor(dev.authorized ? '#17A964' : this.palette().textMuted)
}
.layoutWeight(1)
.alignItems(HorizontalAlign.Start)
Text(dev.caps.length.toString() + ' 能力')
.fontSize(10)
.fontColor(this.palette().textMuted)
}
.width('100%')
}
}
.width('100%')
.transition(TransitionEffect.OPACITY
.combine(TransitionEffect.translate({ y: 12 }))
.animation({ duration: ANIM_ENTER, curve: Curve.EaseOut }))
}, (dev: DeviceInfo) => dev.deviceId + dev.online.toString())
}
.width('100%')
.alignItems(HorizontalAlign.Start)
}
}

View File

@ -0,0 +1,92 @@
/**
* 设备页一级入口列表(本机 / 通道两组)。
*
* 从 pages/DevicePage.ets 抽出(原来是 RootEntries 一个 @Builder)。
* 宽屏高亮由组件自己读 AppStorage 的 isWideScreen 决定,
* 页面只负责给 activeSub 与四个打开动作。
*/
import { LOCAL_DEVICE_CAPS } from '../common/DeviceBridgeSession';
import { SUB_CAPS, SUB_GATEWAY, SUB_LIST, SUB_LOCAL } from '../common/DeviceModel';
import { NavGroup, NavRow } from './SubPage';
@Component
export struct DeviceRootEntries {
/** 宽屏:左边一级界面(含底部导航栏),右边二级界面 */
@StorageProp('isWideScreen') private isWide: boolean = false;
/** 当前右栏展示的二级页面 id,用于宽屏下高亮左侧入口行 */
@Prop activeSub: string = '';
@Prop deviceId: string = '';
@Prop bridgeConnected: boolean = false;
@Prop bridgeUrl: string = '';
@Prop loadingDevices: boolean = false;
@Prop deviceCount: number = 0;
onOpen?: (id: string) => void;
private capsCount(): number {
return LOCAL_DEVICE_CAPS.length;
}
private open(id: string): void {
const cb: ((id: string) => void) | undefined = this.onOpen;
if (cb !== undefined) {
cb(id);
}
}
build() {
// 一级入口列表整体作为一个容器根节点:@Component 的 build() 只允许一个根,
// 页面侧仍是 `.padding(...)` 的 Column,逐项布局与拆分前一致。
Column() {
NavGroup({ caption: '本机' }) {
NavRow({
icon: $r('app.media.ic_phone'),
title: '本机设备',
subtitle: this.deviceId.length > 0 ? this.deviceId : '未注册',
value: this.bridgeConnected ? '在线' : '离线',
selected: this.isWide && this.activeSub === SUB_LOCAL,
onTap: () => {
this.open(SUB_LOCAL);
},
})
NavRow({
icon: $r('app.media.ic_bolt'),
title: '设备能力',
subtitle: this.capsCount().toString() + ' 项能力',
value: '',
showDivider: false,
selected: this.isWide && this.activeSub === SUB_CAPS,
onTap: () => {
this.open(SUB_CAPS);
},
})
}
NavGroup({ caption: '通道' }) {
NavRow({
icon: $r('app.media.ic_gateway'),
title: '设备通道',
subtitle: this.bridgeUrl.length > 0 ? '网关已配置' : '未配置',
value: this.bridgeConnected ? '已连接' : '未连接',
selected: this.isWide && this.activeSub === SUB_GATEWAY,
onTap: () => {
this.open(SUB_GATEWAY);
},
})
NavRow({
icon: $r('app.media.ic_devices_multi'),
title: '接入的设备',
subtitle: this.loadingDevices ? '加载中...' : '当前在线',
value: this.deviceCount.toString() + ' 台',
showDivider: false,
selected: this.isWide && this.activeSub === SUB_LIST,
onTap: () => {
this.open(SUB_LIST);
},
})
}
}
.width('100%')
.alignItems(HorizontalAlign.Start)
}
}

View File

@ -0,0 +1,291 @@
/**
* 插件详情(二级页面内容)。
*
* 从 pages/PluginsPage.ets 抽出。
* WebGUI 这里只有一个 JSON.stringify 的 <pre>,
* 移植时改成结构化卡片:状态 / 清单字段 / 工具 / 配置 / 操作。
*/
import { PluginRow, PluginDetail } from '../model/Model';
import { ThemePalette, DARK_PALETTE, LIGHT_PALETTE, RADIUS_SM,
ANIM_FAST, COLOR_ERROR } from '../common/Constants';
import { pluginDetailStatusLine, pluginStatusColor } from '../common/PluginStatus';
import { PlainCard } from './SubPage';
import { SettingsEditor } from './SettingsEditor';
@Component
export struct PluginDetailPane {
@StorageProp('themeIsDark') private isDark: boolean = true;
@Prop detail: PluginDetail;
/** 当前查看详情的插件名(可能还没拿到 detail.name) */
@Prop activeName: string = '';
@Prop busy: boolean = false;
@Prop errorText: string = '';
/** 一级列表里对应的那一行;取不到详情时用它兜底,也为操作按钮提供状态 */
@Prop row: PluginRow | undefined = undefined;
onToggle?: () => void;
onRemove?: () => void;
private palette(): ThemePalette {
return this.isDark ? DARK_PALETTE : LIGHT_PALETTE;
}
// ---- 取值助手:ArkTS 禁止非空断言,统一在这里做 null 收敛 ----
private hasManifest(): boolean {
return this.detail.author.length > 0 || this.detail.license.length > 0 ||
this.detail.homepage.length > 0 || this.detail.repository.length > 0 ||
this.detail.entry.length > 0 || this.detail.minVersion.length > 0;
}
private isBuiltin(): boolean {
const r: PluginRow | undefined = this.row;
return r !== undefined ? !r.external : false;
}
private isDisabled(): boolean {
const r: PluginRow | undefined = this.row;
return r !== undefined ? r.disabled : false;
}
private tools(): string[] {
const r: PluginRow | undefined = this.row;
if (r === undefined) {
return [];
}
return r.tools ?? [];
}
private statusLine(): string {
const r: PluginRow | undefined = this.row;
return r !== undefined ? pluginDetailStatusLine(r, this.detail.deprecated) : '未加载';
}
private statusColor(): string {
const r: PluginRow | undefined = this.row;
return r !== undefined ? pluginStatusColor(r, this.palette().textMuted) : this.palette().textMuted;
}
/** 明细行:值为空时整行不渲染,避免详情页出现一排 "-" */
@Builder
KvRow(label: string, value: string) {
if (value.length > 0) {
Row() {
Text(label)
.fontSize(13)
.fontColor(this.palette().textSecondary)
.layoutWeight(1)
Text(value)
.fontSize(13)
.fontColor(this.palette().textPrimary)
.textAlign(TextAlign.End)
.maxLines(2)
.textOverflow({ overflow: TextOverflow.Ellipsis })
.constraintSize({ maxWidth: 220 })
.margin({ left: 16 })
}
.width('100%')
.padding({ top: 8, bottom: 8 })
.alignItems(VerticalAlign.Top)
}
}
/** 详情页状态行:同样去掉徽标,一个状态点 + 一行纯文字 */
@Builder
Badges() {
Row({ space: 6 }) {
Circle({ width: 7, height: 7 })
.fill(this.statusColor())
Text(this.statusLine())
.fontSize(12)
.fontColor(this.palette().textSecondary)
.layoutWeight(1)
.maxLines(1)
.textOverflow({ overflow: TextOverflow.Ellipsis })
}
.width('100%')
.alignItems(VerticalAlign.Center)
}
/** 工具清单来自一级列表已合并的 kernel.tools(按 plugin 归属) */
@Builder
ToolsCard() {
if (this.tools().length > 0) {
PlainCard({ caption: '注册的工具 (' + this.tools().length.toString() + ')' }) {
Flex({ wrap: FlexWrap.Wrap }) {
ForEach(this.tools(), (tool: string) => {
Text(tool)
.fontSize(11)
.fontColor('#4A90D9')
.padding({ left: 8, right: 8, top: 3, bottom: 3 })
.borderRadius(RADIUS_SM)
.backgroundColor(this.palette().frostSoftBg)
.margin({ right: 5, bottom: 5 })
}, (tool: string) => tool)
}
}
}
}
@Builder
ActionsCard() {
if (this.activeName.length > 0) {
PlainCard({ caption: '操作' }) {
Row() {
Button(this.isDisabled() ? '启用' : '禁用')
.height(34)
.fontSize(12)
.backgroundColor(Color.Transparent)
.border({
width: 1,
color: this.isDisabled()
? this.palette().btnGhostBorder : 'rgba(217, 154, 43, 0.5)',
})
.fontColor(this.isDisabled()
? this.palette().textSecondary : '#D99A2B')
.animation({ duration: ANIM_FAST, curve: Curve.EaseOut })
.onClick(() => {
const cb: (() => void) | undefined = this.onToggle;
if (cb !== undefined) {
cb();
}
})
Blank()
if (!this.isBuiltin()) {
Button('卸载')
.height(34)
.fontSize(12)
.backgroundColor(Color.Transparent)
.border({ width: 1, color: 'rgba(232, 64, 38, 0.45)' })
.fontColor(COLOR_ERROR)
.onClick(() => {
const cb: (() => void) | undefined = this.onRemove;
if (cb !== undefined) {
cb();
}
})
.transition(TransitionEffect.OPACITY.animation({ duration: ANIM_FAST, curve: Curve.EaseOut }))
}
}
.width('100%')
}
}
}
build() {
// 单一根节点:与原来作为 @Builder 直接铺在 SubPageLayer 的 Column 里同构,
// 保持 alignItems Start,避免文本被默认居中对齐。
Column() {
if (this.busy) {
Row() {
LoadingProgress()
.width(26)
.height(26)
.color(this.palette().accent)
}
.width('100%')
.justifyContent(FlexAlign.Center)
.padding({ top: 30, bottom: 30 })
.transition(TransitionEffect.OPACITY.animation({ duration: ANIM_FAST, curve: Curve.EaseOut }))
}
if (this.errorText.length > 0) {
Text(this.errorText)
.fontSize(12)
.fontColor(COLOR_ERROR)
.padding({ left: 4, bottom: 12 })
.transition(TransitionEffect.OPACITY.animation({ duration: ANIM_FAST, curve: Curve.EaseOut }))
}
// 概览卡:名称、版本、状态徽标、描述
PlainCard({ caption: '概览' }) {
Row({ space: 8 }) {
Text(this.detail.name.length > 0 ? this.detail.name : this.activeName)
.fontSize(17)
.fontWeight(FontWeight.Bold)
.fontColor(this.palette().textPrimary)
.layoutWeight(1)
.maxLines(1)
.textOverflow({ overflow: TextOverflow.Ellipsis })
if (this.detail.version.length > 0) {
Text('v' + this.detail.version)
.fontSize(12)
.fontColor(this.palette().textSecondary)
}
}
.width('100%')
.margin({ bottom: 10 })
this.Badges()
if (this.detail.description.length > 0) {
Text(this.detail.description)
.fontSize(13)
.fontColor(this.palette().textSecondary)
.width('100%')
.margin({ top: 10 })
}
}
// 清单卡:只有真拿到字段才出卡,否则会留一张空壳(内置插件没有清单文件)
if (this.hasManifest()) {
PlainCard({ caption: '清单' }) {
this.KvRow('作者', this.detail.author)
this.KvRow('许可证', this.detail.license)
this.KvRow('主页', this.detail.homepage)
this.KvRow('仓库', this.detail.repository)
this.KvRow('入口', this.detail.entry)
this.KvRow('最低内核版本', this.detail.minVersion)
}
}
if (this.detail.tags.length > 0) {
PlainCard({ caption: '标签' }) {
Flex({ wrap: FlexWrap.Wrap }) {
ForEach(this.detail.tags, (t: string) => {
Text(t)
.fontSize(10)
.fontColor('#4A90D9')
.padding({ left: 8, right: 8, top: 3, bottom: 3 })
.borderRadius(RADIUS_SM)
.backgroundColor(this.palette().frostSoftBg)
.margin({ right: 5, bottom: 5 })
}, (t: string) => t)
}
}
}
this.ToolsCard()
// 插件配置:plugin.<name>.* 从后端 /settings?prefix= 取,就地编辑。
// 这些 key 属于插件本身,之前被平铺在「设置 → 后端配置」里,
// 现在归位到插件详情页 —— 「插件的设计页面就是插件的详情页」。
if (this.activeName.length > 0) {
PlainCard({ caption: '插件配置' }) {
SettingsEditor({
prefix: 'plugin.' + this.activeName + '.',
emptyHint: '该插件没有暴露可配置项',
})
}
}
if (this.detail.files.length > 0) {
PlainCard({ caption: '文件 (' + this.detail.files.length.toString() + ')' }) {
ForEach(this.detail.files, (f: string) => {
Text(f)
.fontSize(12)
.fontColor(this.palette().textSecondary)
.width('100%')
.maxLines(1)
.textOverflow({ overflow: TextOverflow.Ellipsis })
.margin({ bottom: 4 })
}, (f: string) => f)
}
}
this.ActionsCard()
}
.width('100%')
.alignItems(HorizontalAlign.Start)
}
}

View File

@ -0,0 +1,166 @@
/**
* 插件一级列表(列表卡 + 三种占位态)。
*
* 从 pages/PluginsPage.ets 抽出:列表只负责"选谁",
* 描述/工具/启停全部下沉到详情页。
*/
import { PluginRow } from '../model/Model';
import { ThemePalette, DARK_PALETTE, LIGHT_PALETTE, RADIUS_LG, RADIUS_MD,
ANIM_FAST, ANIM_ENTER } from '../common/Constants';
import { pluginRowSubtitle, pluginStatusColor } from '../common/PluginStatus';
import { noConnectionMessage } from '../common/UserError';
import { MotionBase } from './MotionBase';
/**
* 单个插件行卡。
*
* 外层 Column 只为承载 transition:.transition() 不能直接挂在自定义组件
* 调用点上(会生成 __Common__ 包装节点)。按压缩放由 MotionBase 统一提供,
* 每行自带独立按压态,不再需要 pressedName 这种"哪一行被按"的手工记账。
*/
@Component
export struct PluginListCard {
@StorageProp('themeIsDark') private isDark: boolean = true;
@Prop plugin: PluginRow;
/** 是否当前选中(宽屏高亮左侧列表项)。单独用基本类型传,选中态变更才能触发更新 */
@Prop active: boolean = false;
onTap?: () => void;
private palette(): ThemePalette {
return this.isDark ? DARK_PALETTE : LIGHT_PALETTE;
}
build() {
Column() {
MotionBase({ pressEnabled: true }) {
Row() {
Column({ space: 3 }) {
Row({ space: 6 }) {
Text(this.plugin.name)
.fontSize(15)
.fontWeight(this.active ? FontWeight.Medium : FontWeight.Normal)
.fontColor(this.active ? this.palette().accent : this.palette().textPrimary)
.maxLines(1)
.textOverflow({ overflow: TextOverflow.Ellipsis })
.animation({ duration: ANIM_FAST, curve: Curve.EaseOut })
if (this.plugin.version !== undefined && this.plugin.version.length > 0) {
Text('v' + this.plugin.version)
.fontSize(10)
.fontColor(this.palette().textMuted)
}
}
// 徽标全部去掉(用户要求):状态用一个 3vp 圆点表达,
// 其余信息退化为一行灰字副标题 —— 列表只负责"选谁",细节看详情页。
Row({ space: 6 }) {
Circle({ width: 6, height: 6 })
.fill(pluginStatusColor(this.plugin, this.palette().textMuted))
Text(pluginRowSubtitle(this.plugin))
.fontSize(11)
.fontColor(this.palette().textMuted)
.maxLines(1)
.textOverflow({ overflow: TextOverflow.Ellipsis })
.layoutWeight(1)
}
.width('100%')
.alignItems(VerticalAlign.Center)
}
.layoutWeight(1)
.alignItems(HorizontalAlign.Start)
Image($r('app.media.ic_chevron_right'))
.width(15)
.height(15)
.fillColor(this.active ? this.palette().accent : this.palette().textMuted)
.animation({ duration: ANIM_FAST, curve: Curve.EaseOut })
.draggable(false)
}
.width('100%')
.padding(14)
.borderRadius(RADIUS_LG)
.backgroundColor(this.active ? this.palette().accentBg : this.palette().bgCard)
.border({
width: 1,
color: this.active ? this.palette().accent : this.palette().glassBorder,
})
// 选中态的底色/描边渐变:MotionBase 的 .animation() 到不了这里
.animation({ duration: ANIM_FAST, curve: Curve.EaseOut })
.alignItems(VerticalAlign.Center)
.onClick(() => {
const cb: (() => void) | undefined = this.onTap;
if (cb !== undefined) {
cb();
}
})
}
}
.width('100%')
.margin({ bottom: 10 })
// ForEach key 含 loaded/disabled:启停会整行重挂载,靠 transition 变成交叉淡入
.transition(TransitionEffect.OPACITY
.combine(TransitionEffect.translate({ y: 12 }))
.animation({ duration: ANIM_ENTER, curve: Curve.EaseOut }))
}
}
/**
* 一级列表整体:占位态 + 行卡 ForEach。
* 取数留在页面里,这里只吃数据。
*/
@Component
export struct PluginListView {
@StorageProp('themeIsDark') private isDark: boolean = true;
@Prop plugins: PluginRow[] = [];
@Prop busy: boolean = false;
@Prop activeName: string = '';
@Prop hasConn: boolean = false;
onSelect?: (name: string) => void;
private palette(): ThemePalette {
return this.isDark ? DARK_PALETTE : LIGHT_PALETTE;
}
build() {
Column() {
// ── 加载中 / 未配置 / 空列表三种占位态 ──
if (this.busy && this.plugins.length === 0) {
LoadingProgress()
.width(32)
.height(32)
.color(this.palette().accent)
.margin({ top: 40 })
.transition(TransitionEffect.OPACITY.animation({ duration: ANIM_FAST, curve: Curve.EaseOut }))
}
if (!this.hasConn) {
Text(noConnectionMessage())
.fontSize(13)
.fontColor(this.palette().textMuted)
.padding(20)
.transition(TransitionEffect.OPACITY.animation({ duration: ANIM_FAST, curve: Curve.EaseOut }))
}
if (!this.busy && this.plugins.length === 0 && this.hasConn) {
Text('暂无已加载插件')
.fontSize(13)
.fontColor(this.palette().textMuted)
.padding(20)
.transition(TransitionEffect.OPACITY.animation({ duration: ANIM_FAST, curve: Curve.EaseOut }))
}
ForEach(this.plugins, (plugin: PluginRow) => {
PluginListCard({
plugin: plugin,
active: this.activeName === plugin.name,
onTap: () => {
const cb: ((name: string) => void) | undefined = this.onSelect;
if (cb !== undefined) {
cb(plugin.name);
}
},
})
}, (plugin: PluginRow) => plugin.name + (plugin.loaded ? 'L' : '') + (plugin.disabled ? 'D' : ''))
}
.width('100%')
}
}

View File

@ -0,0 +1,65 @@
/**
* 安装表单悬浮卡。
*
* 从 pages/PluginsPage.ets 抽出(浮在内容之上的独立图层,与列表/详情无关)。
* 轻提示条与设置页共用,见 components/ToastBar.ets。
*/
import { ThemePalette, DARK_PALETTE, LIGHT_PALETTE, RADIUS_MD, RADIUS_SM,
ANIM_ENTER } from '../common/Constants';
/** 安装表单:悬浮在安装按钮上方的一张玻璃卡(点悬浮按钮开合) */
@Component
export struct PluginInstallForm {
@StorageProp('themeIsDark') private isDark: boolean = true;
@Prop url: string = '';
onUrlChange?: (v: string) => void;
onInstall?: () => void;
private palette(): ThemePalette {
return this.isDark ? DARK_PALETTE : LIGHT_PALETTE;
}
build() {
Row() {
TextInput({ placeholder: '.hmap 包下载 URL', text: this.url })
.layoutWeight(1)
.height(36)
.fontSize(14)
.fontColor(this.palette().textPrimary)
.placeholderColor(this.palette().textMuted)
.backgroundColor(this.palette().bgInput)
.borderRadius(RADIUS_SM)
.border({ width: 1, color: this.palette().border })
.onChange((v: string) => {
const cb: ((v: string) => void) | undefined = this.onUrlChange;
if (cb !== undefined) {
cb(v);
}
})
Button('安装')
.height(36)
.fontSize(12)
.backgroundColor(this.palette().accent)
.fontColor('#FFFFFF')
.margin({ left: 6 })
.onClick(() => {
const cb: (() => void) | undefined = this.onInstall;
if (cb !== undefined) {
cb();
}
})
}
.width('100%')
.padding(10)
.margin({ bottom: 10 })
.backgroundColor(this.palette().navBarBg)
.borderRadius(RADIUS_MD)
.border({ width: 1, color: this.palette().navBarBorder })
.shadow({ radius: 20, color: this.palette().shadow, offsetY: 6 })
.alignItems(VerticalAlign.Center)
.transition(TransitionEffect.OPACITY
.combine(TransitionEffect.translate({ y: 12 }))
.animation({ duration: ANIM_ENTER, curve: Curve.EaseOut }))
}
}

View File

@ -0,0 +1,385 @@
import {
ThemePalette, DARK_PALETTE, LIGHT_PALETTE,
RADIUS_SM, RADIUS_MD, ANIM_FAST,
COLOR_ACCENT, COLOR_EMERALD, COLOR_FROST_300,
} from '../common/Constants';
import { statusStore, RuntimeSnapshot, RuntimeQueue, K_REV } from '../common/StatusStore';
import {
stageTrail, StageEvent, StageGroup, STAGE_GROUPS, phaseGroup,
K_STAGE_PHASE, K_STAGE_REV,
} from '../common/StageTrail';
/** 四级中断 + 排队的配色:与 WebUI 总览同一套(级别色贯穿框头、槽位、描边) */
const LV_COLORS: string[] = ['#A3BE8C', '#4A90D9', '#0A59F7', '#FFA657', '#FF5C7A'];
/** 阶段管道里的「工具」格(循环格):一轮内可能调几十次,只露最新一条 */
const TOOL_GROUP: number = 2;
/** 索引 = lv(0 排队 / 1 L1 / 2 L2 / 3 L3 / 4 L4) */
function lvColor(lv: number): string {
if (lv < 0 || lv > 4) {
return COLOR_ACCENT;
}
return LV_COLORS[lv];
}
/**
* 运行态面板:阶段管道 + 中断队列。
*
* 与 WebUI / 桌面版同一套设计语言:**等大表框**。
* 此前鸿蒙端完全没有运行态展示(「状态」Tab 已并入设置页 + 二级明细),
* 这里补在二级明细页顶部。
*
* 两块数据来源不同:
* - 队列 / 计数:StatusStore 轮询 /runtime,靠 K_REV 通知;
* - 阶段 + 本轮轨迹:StageTrail 由 SSE 的 stage 事件喂入,靠 K_STAGE_REV 通知。
*/
@Component
export struct RuntimePanel {
@StorageProp('themeIsDark') private isDark: boolean = true;
/** 宽屏(平板/折叠)5 框一行;手机 3+2。窄屏硬塞 5 框会把标签挤成省略号。 */
@StorageProp('isWideScreen') private isWide: boolean = false;
@StorageProp(K_REV) @Watch('onStatusRev') private statusRev: number = 0;
@StorageProp(K_STAGE_REV) @Watch('onStageRev') private stageRev: number = 0;
@StorageProp(K_STAGE_PHASE) private phase: string = '';
@State private snap: RuntimeSnapshot | undefined = undefined;
/** 格槽下标:ArkUI 的 ForEach 遍历的是数组,所以把「几格」摊成下标数组 */
@State private slotIdx: number[] = [];
@State private trail: StageEvent[] = [];
aboutToAppear(): void {
this.pull();
}
private onStatusRev(): void {
this.pull();
}
private onStageRev(): void {
this.trail = stageTrail.snapshot();
}
private pull(): void {
const s: RuntimeSnapshot | undefined = statusStore.getRuntime();
this.snap = s;
if (s !== undefined) {
const idx: number[] = [];
for (let i = 0; i < s.slots; i++) {
idx.push(i);
}
this.slotIdx = idx;
} else {
this.slotIdx = [];
}
this.trail = stageTrail.snapshot();
}
private palette(): ThemePalette {
return this.isDark ? DARK_PALETTE : LIGHT_PALETTE;
}
/** 该阶段本轮发生的事件 */
private eventsOf(group: number): StageEvent[] {
const out: StageEvent[] = [];
for (let i = 0; i < this.trail.length; i++) {
const e: StageEvent = this.trail[i];
if (e.group === group) {
out.push(e);
}
}
return out;
}
/** 该阶段本轮事件的**最后一条**(最新)。没有则 undefined。 */
private latestEvent(group: number): StageEvent | undefined {
let out: StageEvent | undefined = undefined;
for (let i = 0; i < this.trail.length; i++) {
const e: StageEvent = this.trail[i];
if (e.group === group) {
out = e;
}
}
return out;
}
/** 该阶段本轮事件条数合计(同一工具连调会累加到 count 上) */
private totalCount(group: number): number {
let n: number = 0;
for (let i = 0; i < this.trail.length; i++) {
const e: StageEvent = this.trail[i];
if (e.group === group) {
n += e.count;
}
}
return n;
}
@Builder
tile(label: string, value: string, warn: boolean) {
Column({ space: 2 }) {
Text(value)
.fontSize(20)
.fontWeight(FontWeight.Bold)
.fontColor(warn ? this.palette().accent : this.palette().textPrimary)
.maxLines(1)
Text(label)
.fontSize(11)
.fontColor(this.palette().textMuted)
.maxLines(1)
}
.layoutWeight(1)
.alignItems(HorizontalAlign.Start)
.padding({ left: 10, right: 10, top: 9, bottom: 9 })
.borderRadius(RADIUS_SM)
.backgroundColor(this.palette().bgHover)
}
/** 阶段管道的一格 */
@Builder
stageCell(g: StageGroup, active: boolean) {
Column({ space: 6 }) {
Row({ space: 5 }) {
// 用一个几何圆点而非图标:本项目没有为「阶段」准备的图形资源,
// 而猜 sys.media.* 名称会直接编译不过;也不允许用 emoji 充当图标。
// 不用 Circle().fill():那是 SDK 26 起的 API,本工程兼容版本是 6.1.1(24)。
Row()
.width(7)
.height(7)
.borderRadius(4)
.backgroundColor(active ? this.palette().accent : this.palette().textMuted)
Text(g.label)
.fontSize(11)
.fontWeight(FontWeight.Bold)
.fontColor(active ? this.palette().accent : this.palette().textSecondary)
.maxLines(1)
.textOverflow({ overflow: TextOverflow.Ellipsis })
}
.width('100%')
// 本阶段本轮发生的事件;没有就给一个弱化的「无」,让框不空着。
//
// 「工具」格是循环格:一轮里可能调几十次工具/输出通道。把每一次都追加成
// 一行,这格会被撑成长条,反而看不出「现在在调什么」。所以它只保留**最新
// 一条**,右侧给本轮累计次数(与 WebUI/桌面版同一口径)。
Column({ space: 3 }) {
if (g.group === TOOL_GROUP) {
if (this.eventsOf(g.group).length > 0) {
Row({ space: 3 }) {
Text(this.latestEvent(g.group)?.short ?? '')
.fontSize(9)
.fontColor(this.latestEvent(g.group)?.kind === 'output' ? this.palette().accent
: (this.latestEvent(g.group)?.kind === 'tool' ? COLOR_FROST_300 : this.palette().textSecondary))
.maxLines(1)
.textOverflow({ overflow: TextOverflow.Ellipsis })
.layoutWeight(1)
Text('x' + this.totalCount(g.group).toString())
.fontSize(9)
.fontColor(this.palette().textMuted)
}
.width('100%')
} else {
Text('无')
.fontSize(9)
.fontColor(this.palette().textMuted)
.opacity(0.5)
}
} else {
ForEach(this.eventsOf(g.group), (e: StageEvent) => {
Row({ space: 3 }) {
Text(e.short)
.fontSize(9)
.fontColor(e.kind === 'output' ? this.palette().accent
: (e.kind === 'tool' ? COLOR_FROST_300 : this.palette().textSecondary))
.maxLines(1)
.textOverflow({ overflow: TextOverflow.Ellipsis })
if (e.count > 1) {
Text('x' + e.count.toString())
.fontSize(9)
.fontColor(this.palette().textMuted)
}
}
.width('100%')
}, (e: StageEvent, i: number) => i.toString() + ':' + e.short)
if (this.eventsOf(g.group).length === 0) {
Text('无')
.fontSize(9)
.fontColor(this.palette().textMuted)
.opacity(0.5)
}
}
}
.width('100%')
.alignItems(HorizontalAlign.Start)
}
.layoutWeight(1)
.alignItems(HorizontalAlign.Start)
.padding({ left: 8, right: 8, top: 9, bottom: 9 })
.borderRadius(RADIUS_SM)
.backgroundColor(active ? this.palette().accentBg : this.palette().bgHover)
.border({ width: 1, color: active ? this.palette().accent : this.palette().glassBorder })
.animation({ duration: ANIM_FAST, curve: Curve.EaseOut })
}
/** 中断队列的一格 */
@Builder
queueCell(q: RuntimeQueue) {
Column({ space: 5 }) {
Row({ space: 4 }) {
Text(q.name)
.fontSize(13)
.fontWeight(FontWeight.Bold)
.fontColor(lvColor(q.lv))
.maxLines(1)
Text(q.desc)
.fontSize(9)
.fontColor(this.palette().textMuted)
.maxLines(1)
.textOverflow({ overflow: TextOverflow.Ellipsis })
}
.width('100%')
.alignItems(VerticalAlign.Bottom)
Text(q.depth.toString())
.fontSize(20)
.fontWeight(FontWeight.Bold)
.fontColor(this.palette().textPrimary)
.maxLines(1)
// 格槽:固定可见的「车位」。用进度条时深度为 0 宽度就是 0,
// 整格只剩文字,看上去就是「这块空着」。
Row({ space: 2 }) {
ForEach(this.slotIdx, (i: number) => {
Row()
.layoutWeight(1)
.height(11)
.borderRadius(2)
.backgroundColor(i < q.depth ? lvColor(q.lv) : this.palette().bgHover)
}, (i: number) => q.lv.toString() + '-' + i.toString())
}
.width('100%')
if (q.lv > 0) {
Text(q.registered.toString() + ' 登记 · ' + q.preempted.toString() + ' 抢占')
.fontSize(9)
.fontColor(this.palette().textMuted)
.maxLines(1)
} else {
Text('无级别')
.fontSize(9)
.fontColor(this.palette().textMuted)
.maxLines(1)
}
}
.layoutWeight(1)
.alignItems(HorizontalAlign.Start)
.padding({ left: 8, right: 8, top: 9, bottom: 9 })
.borderRadius(RADIUS_SM)
.backgroundColor(this.palette().bgHover)
.border({
width: 1,
color: q.depth > 0 ? lvColor(q.lv) : this.palette().glassBorder,
style: q.lv === 0 ? BorderStyle.Dashed : BorderStyle.Solid,
})
.animation({ duration: ANIM_FAST, curve: Curve.EaseOut })
}
build() {
Column() {
Text('运行态')
.fontSize(15)
.fontWeight(FontWeight.Medium)
.fontColor(this.palette().textPrimary)
.margin({ bottom: 8 })
if (this.snap === undefined) {
Text('运行态数据不可用')
.fontSize(12)
.fontColor(this.palette().textMuted)
.padding({ top: 4, bottom: 4 })
} else {
// 四个数字块
Row({ space: 8 }) {
this.tile('排队', this.snap.ready.toString(), this.snap.ready > 0)
this.tile('中断', this.snap.pending.toString(), this.snap.pending > 0)
this.tile('栈', this.snap.stack.toString() + '/' + this.snap.maxStack.toString(),
this.snap.stack > 0)
this.tile('子代理', this.snap.subagents.toString(), false)
}
.width('100%')
// 阶段管道:等大表框,事件落在所属阶段那一格
Text('阶段管道')
.fontSize(12)
.fontWeight(FontWeight.Medium)
.fontColor(this.palette().textSecondary)
.margin({ top: 14, bottom: 6 })
if (this.isWide) {
Row({ space: 6 }) {
ForEach(STAGE_GROUPS, (g: StageGroup) => {
this.stageCell(g, phaseGroup(this.phase) === g.group)
}, (g: StageGroup) => 'w' + g.group.toString())
}
.width('100%')
.alignItems(VerticalAlign.Top)
} else {
Row({ space: 6 }) {
ForEach(STAGE_GROUPS.slice(0, 3), (g: StageGroup) => {
this.stageCell(g, phaseGroup(this.phase) === g.group)
}, (g: StageGroup) => 'n0' + g.group.toString())
}
.width('100%')
.alignItems(VerticalAlign.Top)
Row({ space: 6 }) {
ForEach(STAGE_GROUPS.slice(3), (g: StageGroup) => {
this.stageCell(g, phaseGroup(this.phase) === g.group)
}, (g: StageGroup) => 'n1' + g.group.toString())
// 占位:第二行只有 2 格,补一格位置让框宽与第一行对齐
Row().layoutWeight(1)
}
.width('100%')
.alignItems(VerticalAlign.Top)
.margin({ top: 6 })
}
// 中断队列:五个等大表框(L4/L3/L2/L1 + 排队)
Text('队列')
.fontSize(12)
.fontWeight(FontWeight.Medium)
.fontColor(this.palette().textSecondary)
.margin({ top: 14, bottom: 6 })
if (this.isWide) {
Row({ space: 6 }) {
ForEach(this.snap.queues, (q: RuntimeQueue) => {
this.queueCell(q)
}, (q: RuntimeQueue) => 'wq' + q.lv.toString())
}
.width('100%')
.alignItems(VerticalAlign.Top)
} else {
Row({ space: 6 }) {
ForEach(this.snap.queues.slice(0, 3), (q: RuntimeQueue) => {
this.queueCell(q)
}, (q: RuntimeQueue) => 'nq0' + q.lv.toString())
}
.width('100%')
.alignItems(VerticalAlign.Top)
Row({ space: 6 }) {
ForEach(this.snap.queues.slice(3), (q: RuntimeQueue) => {
this.queueCell(q)
}, (q: RuntimeQueue) => 'nq1' + q.lv.toString())
Row().layoutWeight(1)
}
.width('100%')
.alignItems(VerticalAlign.Top)
.margin({ top: 6 })
}
}
}
.width('100%')
.alignItems(HorizontalAlign.Start)
.padding(16)
.margin({ bottom: 14 })
.borderRadius(RADIUS_MD)
.backgroundColor(this.palette().bgCard)
.border({ width: 1, color: this.palette().glassBorder })
}
}

View File

@ -2,12 +2,24 @@ import { ThemePalette, DARK_PALETTE, LIGHT_PALETTE, ANIM_NORMAL } from '../commo
import { GradientBackground } from './GradientBackground'; import { GradientBackground } from './GradientBackground';
import { PageTopBar } from './PageTopBar'; import { PageTopBar } from './PageTopBar';
import { MotionBase } from './MotionBase'; import { MotionBase } from './MotionBase';
import { looksLikeHtml, screensueWebData } from '../common/ScreensueHtml';
import { webview } from '@kit.ArkWeb';
/** /**
* agent 主动推送的前台内容页。 * agent 主动推送的前台内容页。
* *
* 调用方负责决定页面宽度:窄屏占满窗口,宽屏只占右侧内容栏, * 调用方负责决定页面宽度:窄屏占满窗口,宽屏只占右侧内容栏,
* 从而让左侧一级页面和主导航保持可见、可操作。 * 从而让左侧一级页面和主导航保持可见、可操作。
*
* 内容可能是纯文本,也可能是 HTML(服务端两侧协议都允许,见 ScreensueHtml)。
*
* HTML 走 **Web 组件**(用户明确要求):agent 推的常是完整文档 —— 带 <style>
* CSS 动画、内联 <svg>、radial-gradient 背景。RichText 只认极小标签子集,
* 对这些一律不渲染,实测只能看到满屏源码。
*
* 安全:内容来自 agent(第三方),所以显式关掉 JS 与本地文件访问 ——
* 注意 **javaScriptAccess 默认是 true**,不显式关掉等于让远端内容在客户端执行脚本。
* 纯文本仍走 Text(无需开销,也不该把文本塞进 Web)。
*/ */
@Component @Component
export struct ScreensuePage { export struct ScreensuePage {
@ -17,6 +29,16 @@ export struct ScreensuePage {
onClose: () => void = () => { onClose: () => void = () => {
}; };
/** 内容是不是 HTML(决定走 Web 还是 Text)。 */
private htmlMode(): boolean {
return looksLikeHtml(this.pushedText);
}
/** HTML 的 base64 载荷(空串表示不是 HTML)。 */
private webData(): string {
return screensueWebData(this.pushedText, this.isDark);
}
build() { build() {
Stack({ alignContent: Alignment.Bottom }) { Stack({ alignContent: Alignment.Bottom }) {
GradientBackground() GradientBackground()
@ -44,13 +66,22 @@ export struct ScreensuePage {
.width('100%') .width('100%')
Column() { Column() {
Text(this.pushedText) if (this.htmlMode()) {
.fontSize(16) // HTML:整篇交给 Web 渲染(base64 loadData,见 screensueWebData)。
.lineHeight(25) // 高度固定 420vp:Web 不参与父级自适应测量,给 height('100%')
.fontColor(this.palette().textPrimary) // 会在 Scroll 里塌成 0。内容区本身可滚。
.width('100%') ScreenWebView({ data: this.webData(), isDark: this.isDark })
.textAlign(TextAlign.Start) .width('100%')
.copyOption(CopyOptions.LocalDevice) .height(420)
} else {
Text(this.pushedText)
.fontSize(16)
.lineHeight(25)
.fontColor(this.palette().textPrimary)
.width('100%')
.textAlign(TextAlign.Start)
.copyOption(CopyOptions.LocalDevice)
}
} }
.width('100%') .width('100%')
.padding(18) .padding(18)
@ -101,3 +132,66 @@ export struct ScreensuePage {
return this.isDark ? DARK_PALETTE : LIGHT_PALETTE; return this.isDark ? DARK_PALETTE : LIGHT_PALETTE;
} }
} }
/**
* 承载 screensue HTML 的 Web 视图(独立组件,便于按内容变化重建控制器)。
*
* 为什么单开一个组件而不是直接在 ScreensuePage 里放 Web:
* `WebviewController` 与 Web 组件是一对一绑定的,必须等组件挂载(onControllerAttached)
* 才能真正 loadData;把它隔离在这里,ScreensuePage 只管布局与倒计时。
*/
@Component
struct ScreenWebView {
// @Watch 挂在这里是必须的:ScreensuePage 在 `if (screensueVisible)` 里常驻,
// 第二次 screensue 只会改这个 @Prop 而不会重建组件,而 onControllerAttached
// 只在挂载时触发一次 —— 不 watch 就会一直显示上一条推送的内容。
// 实测:连推两条不同 HTML,倒计时变了、Web 里还是旧画面。
@Prop @Watch('onDataChanged') data: string = '';
@Prop isDark: boolean = true;
private controller: webview.WebviewController = new webview.WebviewController();
/** 控制器是否已与 Web 组件关联(过早 loadData 会抛 17100001)。 */
private attached: boolean = false;
/** data 变化时重新加载(组件不重建,必须显式刷新)。 */
onDataChanged(): void {
if (this.attached) {
this.load();
}
}
build() {
Web({ src: '', controller: this.controller })
// ★ 内容来自 agent(第三方):显式关闭脚本与本地文件访问。
// javaScriptAccess 的默认值是 true,不写这一行等于放任远端内容执行脚本。
.javaScriptAccess(false)
.fileAccess(false)
.domStorageAccess(false)
.onlineImageAccess(false)
.imageAccess(true) // 保留内联/数据 URI 图片(不联网)
.zoomAccess(false) // 禁手势缩放,避免与外层滚动打架
.horizontalScrollBarAccess(false)
.verticalScrollBarAccess(false)
.darkMode(WebDarkMode.Off)
.backgroundColor(Color.Transparent)
// 控制器挂载完才 loadData:过早调用会抛 17100001(控制器未与组件关联)。
.onControllerAttached(() => {
// 挂载完成才允许 loadData;此前的变更由 onDataChanged 记着,这里补一次。
this.attached = true;
this.load();
})
.width('100%')
.height('100%')
}
/** 以 base64 整篇加载(空串直接跳过,避免 Web 显示错误页)。 */
private load(): void {
if (this.data.length === 0) {
return;
}
try {
this.controller.loadData(this.data, 'text/html', 'base64');
} catch (e) {
// 加载失败不该把整页带崩:保持空白,用户仍能看到顶栏与关闭按钮。
}
}
}

View File

@ -0,0 +1,215 @@
/**
* 单个配置项卡片。
*
* 从 pages/SettingsPage.ets 抽出:按 type 分发控件(bool/select/password/text/其他),
* 值的保存与「未保存」标记交回页面(页面上持有 valuesStore 与 entries)。
*/
import { ThemePalette, DARK_PALETTE, LIGHT_PALETTE, RADIUS_MD, RADIUS_SM,
ANIM_FAST, ANIM_NORMAL } from '../common/Constants';
import { SettingEntry } from '../common/SettingsModel';
@Component
export struct SettingsEntryCard {
@StorageProp('themeIsDark') private isDark: boolean = true;
@Prop entry: SettingEntry;
/** bool 开关 / select 选项:值已知,直接落库 */
onSaveValue?: (key: string, value: string) => void;
/** 输入类控件的保存:由页面取该 key 的最新编辑值再落库 */
onSaveCurrent?: (key: string) => void;
/** 输入框内容变化:只更新本地标记,不请求 */
onEdit?: (key: string, value: string) => void;
private palette(): ThemePalette {
return this.isDark ? DARK_PALETTE : LIGHT_PALETTE;
}
private saveValue(value: string): void {
const cb: ((key: string, value: string) => void) | undefined = this.onSaveValue;
if (cb !== undefined) {
cb(this.entry.key, value);
}
}
private saveCurrent(): void {
const cb: ((key: string) => void) | undefined = this.onSaveCurrent;
if (cb !== undefined) {
cb(this.entry.key);
}
}
private editValue(value: string): void {
const cb: ((key: string, value: string) => void) | undefined = this.onEdit;
if (cb !== undefined) {
cb(this.entry.key, value);
}
}
build() {
Column() {
Row() {
Text(this.entry.displayName)
.fontSize(13)
.fontWeight(FontWeight.Medium)
.fontColor(this.palette().textPrimary)
.maxLines(2)
.textOverflow({ overflow: TextOverflow.Ellipsis })
.layoutWeight(1)
Text(this.entry.dirty ? '未保存' : this.entry.type)
.fontSize(10)
.fontColor(this.entry.dirty ? '#D99A2B' : this.palette().textMuted)
.padding({ left: 6, right: 6, top: 1, bottom: 1 })
.borderRadius(RADIUS_SM)
.backgroundColor(this.entry.dirty ? 'rgba(217, 154, 43, 0.16)' : this.palette().bgHover)
}
.width('100%')
Text(this.entry.key)
.fontSize(10)
.fontColor(this.palette().textMuted)
.maxLines(1)
.textOverflow({ overflow: TextOverflow.Ellipsis })
.margin({ top: 1 })
if (this.entry.description.length > 0) {
Text(this.entry.description)
.fontSize(11)
.fontColor(this.palette().textSecondary)
.maxLines(3)
.textOverflow({ overflow: TextOverflow.Ellipsis })
.margin({ top: 3 })
}
// control row per type
if (this.entry.type === 'bool') {
Row() {
Text(this.entry.value === 'true' ? 'true' : 'false')
.fontSize(12)
.fontColor(this.entry.value === 'true' ? '#17A964' : this.palette().textMuted)
.animation({ duration: ANIM_NORMAL, curve: Curve.EaseOut })
Blank()
Toggle({ type: ToggleType.Switch, isOn: this.entry.value === 'true' })
.selectedColor(this.palette().accent)
.onChange((on: boolean) => {
this.saveValue(on ? 'true' : 'false');
})
}
.width('100%')
.margin({ top: 8 })
} else if (this.entry.type === 'select' && this.entry.options.length > 0) {
Flex({
direction: FlexDirection.Row,
justifyContent: FlexAlign.Start,
alignItems: ItemAlign.Center,
wrap: FlexWrap.Wrap,
}) {
ForEach(this.entry.options, (opt: string) => {
Button(opt)
.height(26)
.fontSize(11)
.margin({ right: 6, bottom: 6 })
.backgroundColor(this.entry.value === opt ? this.palette().accent : this.palette().bgHover)
.fontColor(this.entry.value === opt ? Color.White : this.palette().textSecondary)
// 选中项迁移:底色与字色一起过渡,避免整排选项同时硬切
.animation({ duration: ANIM_FAST, curve: Curve.EaseOut })
.onClick(() => {
this.saveValue(opt);
})
}, (opt: string) => opt)
}
.width('100%')
.margin({ top: 8 })
} else if (this.entry.type === 'password') {
Row() {
TextInput({ text: this.entry.value })
.height(36)
.fontSize(13)
.fontColor(this.palette().textPrimary)
.placeholderColor(this.palette().textMuted)
.backgroundColor(this.palette().bgInput)
.borderRadius(RADIUS_SM)
.border({ width: 1, color: this.palette().border })
.type(InputType.Password)
.layoutWeight(1)
.onChange((v: string) => {
this.editValue(v);
})
Button('保存')
.height(30)
.fontSize(12)
.backgroundColor(this.entry.dirty ? '#D99A2B' : this.palette().accent)
.fontColor(Color.White)
.margin({ left: 8 })
.onClick(() => {
this.saveCurrent();
})
}
.width('100%')
.margin({ top: 8 })
} else if (this.entry.type === 'text') {
TextArea({ text: this.entry.value })
.width('100%')
.fontSize(13)
.fontColor(this.palette().textPrimary)
.backgroundColor(this.palette().bgInput)
.borderRadius(RADIUS_SM)
.border({ width: 1, color: this.palette().border })
.constraintSize({ minHeight: 60, maxHeight: 200 })
.margin({ top: 8 })
.onChange((v: string) => {
this.editValue(v);
})
Row() {
Blank()
Button('保存')
.height(30)
.fontSize(12)
.backgroundColor(this.entry.dirty ? '#D99A2B' : this.palette().accent)
.fontColor(Color.White)
.onClick(() => {
this.saveCurrent();
})
}
.width('100%')
.margin({ top: 6 })
} else {
// string / int / duration
Row() {
TextInput({ text: this.entry.value })
.height(36)
.fontSize(13)
.fontColor(this.palette().textPrimary)
.placeholderColor(this.palette().textMuted)
.backgroundColor(this.palette().bgInput)
.borderRadius(RADIUS_SM)
.border({ width: 1, color: this.palette().border })
.layoutWeight(1)
.onChange((v: string) => {
this.editValue(v);
})
Button('保存')
.height(30)
.fontSize(12)
.backgroundColor(this.entry.dirty ? '#D99A2B' : this.palette().accent)
.fontColor(Color.White)
.margin({ left: 8 })
.onClick(() => {
this.saveCurrent();
})
}
.width('100%')
.margin({ top: 8 })
}
}
.width('100%')
.padding(14)
.borderRadius(RADIUS_MD)
.backgroundColor(this.palette().bgCard)
.border({
width: 1,
color: this.entry.dirty ? '#D99A2B' : this.palette().glassBorder,
})
.margin({ bottom: 10 })
.alignItems(HorizontalAlign.Start)
}
}

View File

@ -0,0 +1,95 @@
/**
* 设置一级页的页面骨架:滚动区 + 顶栏 + 悬浮区 + 轻提示。
*
* 从 pages/SettingsPage.ets 抽出:页面本身只剩数据流与导航表,
* 这一层是纯布局 —— 所有计数/文案都由页面算好传进来。
*/
import { handleNavOnScroll } from '../common/NavBarController';
import { ThemePalette, DARK_PALETTE, LIGHT_PALETTE } from '../common/Constants';
import { PageTopBar, NavFloatOverlay, NavFloatRow } from './PageTopBar';
import { SettingsRootEntries } from './SettingsRootEntries';
import { ToastBar } from './ToastBar';
@Component
export struct SettingsHome {
@StorageProp('themeIsDark') private isDark: boolean = true;
/** 一级入口列表所需的计数/文案(见 SettingsRootEntries) */
@Prop connCount: number = 0;
@Prop connName: string = '';
@Prop sectionCount: number = 0;
@Prop coreKeys: number = 0;
@Prop busy: boolean = false;
@Prop errorText: string = '';
@Prop themeLabel: string = '';
@Prop activeSub: string = '';
@Prop isWide: boolean = false;
/** 保存进行中:悬浮区显示转圈 */
@Prop savingCount: number = 0;
@Prop toastMsg: string = '';
@Prop toastIsError: boolean = false;
onOpen?: (id: string) => void;
private palette(): ThemePalette {
return this.isDark ? DARK_PALETTE : LIGHT_PALETTE;
}
build() {
Stack({ alignContent: Alignment.Bottom }) {
Column() {
Scroll() {
Column() {
SettingsRootEntries({
connCount: this.connCount,
connName: this.connName,
sectionCount: this.sectionCount,
coreKeys: this.coreKeys,
busy: this.busy,
errorText: this.errorText,
themeLabel: this.themeLabel,
activeSub: this.activeSub,
isWide: this.isWide,
onOpen: (id: string) => {
const cb: ((id: string) => void) | undefined = this.onOpen;
if (cb !== undefined) {
cb(id);
}
},
})
}
.width('100%')
.padding({ left: 16, right: 16, top: 76, bottom: 174 })
}
.width('100%')
.height('100%')
.scrollBar(BarState.Off)
.align(Alignment.Top)
.onDidScroll((xOffset: number, yOffset: number, state: ScrollState) => {
handleNavOnScroll(state);
})
}
.width('100%')
.height('100%')
PageTopBar({ title: '设置' })
// 一级悬浮区:仅在保存进行中显示一个转圈;
// 已保存/未保存的常驻徽标按用户要求去掉(保存本来就是即时的,不需要状态吊牌)
NavFloatOverlay({ tab: 3 }) {
NavFloatRow() {
if (this.savingCount > 0) {
LoadingProgress()
.width(14)
.height(14)
.color(this.palette().accent)
}
}
}
ToastBar({ msg: this.toastMsg, isError: this.toastIsError })
}
.width('100%')
.height('100%')
.backgroundColor(Color.Transparent)
}
}

View File

@ -0,0 +1,100 @@
/**
* 设置一级页的入口列表。
*
* 从 pages/SettingsPage.ets 抽出:纯展示 + 跳转回调,
* 所有计数/文案由页面算好传进来(页面才是这些状态的持有者)。
*/
import { ThemePalette, DARK_PALETTE, LIGHT_PALETTE } from '../common/Constants';
import { SUB_STATUS, SUB_CONNECTIONS, SUB_BACKEND, SUB_SECTION, SUB_APPEARANCE } from '../common/SettingsModel';
import { StatusSummaryCard } from './StatusCards';
import { NavGroup, NavRow } from './SubPage';
@Component
export struct SettingsRootEntries {
@StorageProp('themeIsDark') private isDark: boolean = true;
/** 连接配置条数 */
@Prop connCount: number = 0;
/** 当前生效连接的展示名 */
@Prop connName: string = '';
/** 后端配置:分类数 / 核心项数 / 是否加载中 / 错误文案 */
@Prop sectionCount: number = 0;
@Prop coreKeys: number = 0;
@Prop busy: boolean = false;
@Prop errorText: string = '';
/** 当前主题的中文名(一级行右侧摘要值) */
@Prop themeLabel: string = '';
/** 宽屏分栏时用来高亮右栏对应的入口行 */
@Prop activeSub: string = '';
@Prop isWide: boolean = false;
onOpen?: (id: string) => void;
private palette(): ThemePalette {
return this.isDark ? DARK_PALETTE : LIGHT_PALETTE;
}
private open(id: string): void {
const cb: ((id: string) => void) | undefined = this.onOpen;
if (cb !== undefined) {
cb(id);
}
}
build() {
Column() {
// 运行状态摘要(原「状态」Tab):整卡可点,进入明细二级页
StatusSummaryCard({
onTap: () => {
this.open(SUB_STATUS);
},
})
NavGroup({ caption: '连接' }) {
NavRow({
icon: $r('app.media.ic_link'),
title: '后端连接',
subtitle: this.connCount.toString() + ' 个连接配置',
value: this.connName,
selected: this.isWide && this.activeSub === SUB_CONNECTIONS,
onTap: () => {
this.open(SUB_CONNECTIONS);
},
})
NavRow({
icon: $r('app.media.ic_tune'),
title: '核心配置',
subtitle: this.sectionCount.toString() + ' 个分类 · ' + this.coreKeys.toString() + ' 项',
value: this.busy ? '加载中' : (this.errorText.length > 0 ? '不可用' : ''),
showDivider: false,
selected: this.isWide && (this.activeSub === SUB_BACKEND || this.activeSub === SUB_SECTION),
onTap: () => {
this.open(SUB_BACKEND);
},
})
}
NavGroup({ caption: '个性化' }) {
NavRow({
icon: $r('app.media.ic_theme'),
title: '外观',
subtitle: '主题与背景图',
value: this.themeLabel,
showDivider: false,
selected: this.isWide && this.activeSub === SUB_APPEARANCE,
onTap: () => {
this.open(SUB_APPEARANCE);
},
})
}
if (this.errorText.length > 0) {
Text(this.errorText)
.fontSize(12)
.fontColor('#E84026')
.padding({ left: 4, right: 4 })
}
}
.width('100%')
.alignItems(HorizontalAlign.Start)
}
}

View File

@ -4,285 +4,13 @@
* Parses once in aboutToAppear, builds a component tree with no timers — instant rendering. * Parses once in aboutToAppear, builds a component tree with no timers — instant rendering.
* Uses Span children inside Text for inline bold/italic/code/link formatting. * Uses Span children inside Text for inline bold/italic/code/link formatting.
* *
* Covers: headings, paragraphs, code fences, unordered/ordered lists, * 解析规则在 common/MarkdownParser.ets(已抽出,见那里);
* blockquotes, horizontal rules, tables, and inline bold/italic/code/links. * 本文件只负责把 MdBlock 渲染成 ArkUI 组件树。
*/ */
import { ThemePalette, DARK_PALETTE, LIGHT_PALETTE } from '../common/Constants'; import { ThemePalette, DARK_PALETTE, LIGHT_PALETTE } from '../common/Constants';
import { RADIUS_SM } from '../common/Constants'; import { RADIUS_SM } from '../common/Constants';
import { MdBlock, MdSpan, parseBlocks, parseInline } from '../common/MarkdownParser';
// ── Types ──────────────────────────────────────────────────────────────────────
export interface MdBlock {
type: string; // 'heading' | 'code' | 'list' | 'ol' | 'blockquote' | 'hr' | 'table' | 'para'
level?: number;
items?: string[];
text?: string;
lang?: string;
codeLines?: string[];
headers?: string[];
rows?: string[][];
}
export interface MdSpan {
text: string;
bold?: boolean;
italic?: boolean;
code?: boolean;
link?: boolean;
linkUrl?: string;
}
// ── Inline parser ──────────────────────────────────────────────────────────────
export function parseInline(text: string): MdSpan[] {
const spans: MdSpan[] = [];
let i: number = 0;
while (i < text.length) {
// Inline code (backtick)
if (text[i] === '`') {
const end: number = text.indexOf('`', i + 1);
if (end > i) {
spans.push({ text: text.substring(i + 1, end), code: true });
i = end + 1;
continue;
}
}
// Bold: **text**
if (text[i] === '*' && i + 1 < text.length && text[i + 1] === '*') {
const end: number = text.indexOf('**', i + 2);
if (end > i + 1) {
spans.push({ text: text.substring(i + 2, end), bold: true });
i = end + 2;
continue;
}
}
// Italic: *text* (single asterisk)
if (text[i] === '*' && (i + 1 >= text.length || text[i + 1] !== '*')) {
const end: number = text.indexOf('*', i + 1);
if (end > i) {
spans.push({ text: text.substring(i + 1, end), italic: true });
i = end + 1;
continue;
}
}
// Link: [text](url)
if (text[i] === '[') {
const cb: number = text.indexOf(']', i + 1);
if (cb > i && cb + 1 < text.length && text[cb + 1] === '(') {
const cp: number = text.indexOf(')', cb + 2);
if (cp > cb + 1) {
spans.push({ text: text.substring(i + 1, cb), link: true, linkUrl: text.substring(cb + 2, cp) });
i = cp + 1;
continue;
}
}
}
// Plain run
let j: number = i + 1;
while (j < text.length && text[j] !== '`' && text[j] !== '*' && text[j] !== '[') {
j++;
}
spans.push({ text: text.substring(i, j) });
i = j;
}
return spans;
}
// ── Block parser helpers ───────────────────────────────────────────────────────
function isHr(line: string): boolean {
if (line.length < 3) {
return false;
}
const ch: string = line[0];
if (ch !== '-' && ch !== '*' && ch !== '_') {
return false;
}
for (let k = 0; k < line.length; k++) {
if (line[k] !== ch) {
return false;
}
}
return true;
}
function isOlStart(line: string): boolean {
if (line.length < 3) {
return false;
}
let k: number = 0;
while (k < line.length && line[k] >= '0' && line[k] <= '9') {
k++;
}
return k > 0 && k + 1 < line.length && line[k] === '.' && line[k + 1] === ' ';
}
function isTableSep(line: string): boolean {
if (!line.includes('-')) {
return false;
}
for (let k = 0; k < line.length; k++) {
const c: string = line[k];
if (c !== '|' && c !== '-' && c !== ':' && c !== ' ' && c !== '\t') {
return false;
}
}
return true;
}
// ── Block parser ───────────────────────────────────────────────────────────────
export function parseBlocks(content: string): MdBlock[] {
if (content.length === 0) {
return [];
}
const lines: string[] = content.split('\n');
const blocks: MdBlock[] = [];
let i: number = 0;
while (i < lines.length) {
const line: string = lines[i];
// Empty line
if (line.trim().length === 0) {
i++;
continue;
}
// Code fence
if (line.startsWith('```')) {
const langEnd: number = line.indexOf('`', 3);
const lang: string = langEnd > 3 ? line.substring(3, langEnd).trim() : '';
const codeLines: string[] = [];
i++;
while (i < lines.length && !lines[i].trimStart().startsWith('```')) {
codeLines.push(lines[i]);
i++;
}
if (i < lines.length) {
i++;
}
blocks.push({ type: 'code', lang: lang, codeLines: codeLines });
continue;
}
// Heading
if (line.startsWith('#')) {
let level: number = 0;
while (level < line.length && line[level] === '#') {
level++;
}
if (level <= 6 && level < line.length && line[level] === ' ') {
blocks.push({ type: 'heading', level: level, text: line.substring(level + 1).trim() });
i++;
continue;
}
}
// Horizontal rule
if (isHr(line.trim())) {
blocks.push({ type: 'hr' });
i++;
continue;
}
// Unordered list
if ((line.startsWith('- ') || line.startsWith('* ')) && !line.startsWith('- [')) {
const items: string[] = [];
while (i < lines.length && (lines[i].startsWith('- ') || lines[i].startsWith('* ')) && !lines[i].startsWith('- [')) {
items.push(lines[i].substring(2));
i++;
}
blocks.push({ type: 'list', items: items });
continue;
}
// Ordered list
if (isOlStart(line)) {
const items: string[] = [];
while (i < lines.length && isOlStart(lines[i])) {
const dotIdx: number = lines[i].indexOf('. ');
items.push(lines[i].substring(dotIdx + 2));
i++;
}
blocks.push({ type: 'ol', items: items });
continue;
}
// Blockquote
if (line.startsWith('> ')) {
const qLines: string[] = [];
while (i < lines.length && lines[i].startsWith('> ')) {
qLines.push(lines[i].substring(2));
i++;
}
blocks.push({ type: 'blockquote', text: qLines.join('\n') });
continue;
}
// Table
if (line.trimStart().startsWith('|') && !isTableSep(line)) {
const tLines: string[] = [];
while (i < lines.length && lines[i].trimStart().startsWith('|')) {
tLines.push(lines[i]);
i++;
}
if (tLines.length >= 2) {
const parseRow = (row: string): string[] => {
const cells: string[] = [];
const parts: string[] = row.split('|');
for (let p = 0; p < parts.length; p++) {
const c: string = parts[p].trim();
if (c.length > 0) {
cells.push(c);
}
}
return cells;
};
const headers: string[] = parseRow(tLines[0]);
const rows: string[][] = [];
for (let k = 1; k < tLines.length; k++) {
if (!isTableSep(tLines[k].trim())) {
rows.push(parseRow(tLines[k]));
}
}
if (headers.length > 0) {
blocks.push({ type: 'table', headers: headers, rows: rows });
}
}
continue;
}
// Paragraph: collect consecutive non-special lines
{
const paraLines: string[] = [];
while (i < lines.length) {
const ln: string = lines[i];
if (ln.trim().length === 0) {
break;
}
if (ln.startsWith('```') || ln.startsWith('#') || isHr(ln.trim())) {
break;
}
if (ln.startsWith('- ') || ln.startsWith('* ') || isOlStart(ln) || ln.startsWith('> ')) {
break;
}
if (ln.trimStart().startsWith('|') && !isTableSep(ln)) {
break;
}
paraLines.push(ln);
i++;
}
if (paraLines.length > 0) {
blocks.push({ type: 'para', text: paraLines.join('\n') });
}
}
}
return blocks;
}
// ── Component ──────────────────────────────────────────────────────────────────
@Component @Component
export struct StaticMarkdownView { export struct StaticMarkdownView {

View File

@ -2,9 +2,10 @@ import { ThemePalette, DARK_PALETTE, LIGHT_PALETTE, RADIUS_LG, RADIUS_SM,
ANIM_FAST, ANIM_NORMAL, ANIM_ENTER } from '../common/Constants'; ANIM_FAST, ANIM_NORMAL, ANIM_ENTER } from '../common/Constants';
import { COLOR_ACCENT, COLOR_SUCCESS, COLOR_CYAN, COLOR_ERROR } from '../common/Constants'; import { COLOR_ACCENT, COLOR_SUCCESS, COLOR_CYAN, COLOR_ERROR } from '../common/Constants';
import { MotionBase } from './MotionBase'; import { MotionBase } from './MotionBase';
import { RuntimePanel } from './RuntimePanel';
import { import {
statusStore, StatGroup, StatField, compactDuration, statusStore, StatGroup, StatField, compactDuration,
K_UP, K_VERSION, K_STARTED, K_AGENTS, K_PLUGINS, K_TOOLS, K_ERR, K_LOADING, K_REV, K_UP, K_VERSION, K_STARTED, K_AGENTS, K_PLUGINS, K_TOOLS, K_ERR, K_LOADING, K_REV, K_BUILD,
} from '../common/StatusStore'; } from '../common/StatusStore';
/** /**
@ -19,6 +20,8 @@ export struct StatusSummaryCard {
@StorageProp('themeIsDark') private isDark: boolean = true; @StorageProp('themeIsDark') private isDark: boolean = true;
@StorageProp(K_UP) private up: boolean = false; @StorageProp(K_UP) private up: boolean = false;
@StorageProp(K_VERSION) private version: string = '-'; @StorageProp(K_VERSION) private version: string = '-';
/** 内核名 · commit。与版本号分开一行:版本号本身没有内核身份。 */
@StorageProp(K_BUILD) private buildSub: string = '';
@StorageProp(K_STARTED) private startedAt: string = ''; @StorageProp(K_STARTED) private startedAt: string = '';
@StorageProp(K_AGENTS) private agents: number = 0; @StorageProp(K_AGENTS) private agents: number = 0;
@StorageProp(K_PLUGINS) private plugins: number = 0; @StorageProp(K_PLUGINS) private plugins: number = 0;
@ -117,10 +120,15 @@ export struct StatusSummaryCard {
.alignItems(VerticalAlign.Center) .alignItems(VerticalAlign.Center)
.transition(TransitionEffect.OPACITY.combine(TransitionEffect.translate({ y: 12 })).animation({ duration: ANIM_ENTER, curve: Curve.EaseOut })) .transition(TransitionEffect.OPACITY.combine(TransitionEffect.translate({ y: 12 })).animation({ duration: ANIM_ENTER, curve: Curve.EaseOut }))
// 能力计数:图标 + 数字,只保留真正会变的两项(插件 / 工具) // 能力计数:图标 + 数字,只保留真正会变的两项(插件 / 工具)。
//
// 必须是**子组件**(@Prop 单向下发)而不是本组件里的 @Builder:
// ArkUI 的 @Builder 按值传参是“快照”语义,父组件重渲染时
// 不会用新值重跑 builder —— 实测:K_PLUGINS 已经是 35,
// 但 @Builder 里画的还是首次的 0,永远显示 '-'。
Row({ space: 10 }) { Row({ space: 10 }) {
this.kpiTile($r('app.media.ic_plug'), '插件', this.plugins, COLOR_ACCENT) KpiTile({ icon: $r('app.media.ic_plug'), label: '插件', value: this.plugins, tint: COLOR_ACCENT })
this.kpiTile($r('app.media.ic_tool'), '工具', this.tools, COLOR_CYAN) KpiTile({ icon: $r('app.media.ic_tool'), label: '工具', value: this.tools, tint: COLOR_CYAN })
} }
.width('100%') .width('100%')
.margin({ top: 14 }) .margin({ top: 14 })
@ -130,14 +138,24 @@ export struct StatusSummaryCard {
Text('版本') Text('版本')
.fontSize(12) .fontSize(12)
.fontColor(this.palette().textMuted) .fontColor(this.palette().textMuted)
Text(this.version) Column() {
.fontSize(12) Text(this.version)
.fontWeight(FontWeight.Medium) .fontSize(12)
.fontColor(this.palette().textSecondary) .fontWeight(FontWeight.Medium)
.layoutWeight(1) .fontColor(this.palette().textSecondary)
.maxLines(1) .maxLines(1)
.textOverflow({ overflow: TextOverflow.Ellipsis }) .textOverflow({ overflow: TextOverflow.Ellipsis })
.margin({ left: 10 }) // 内核名 + commit:光有版本号会分不清是哪个内核、哪次构建
Text(this.buildSub)
.fontSize(10)
.fontColor(this.palette().textMuted)
.maxLines(1)
.textOverflow({ overflow: TextOverflow.Ellipsis })
.visibility(this.buildSub.length > 0 ? Visibility.Visible : Visibility.None)
}
.alignItems(HorizontalAlign.Start)
.layoutWeight(1)
.margin({ left: 10 })
Text('明细') Text('明细')
.fontSize(12) .fontSize(12)
.fontColor(this.palette().accent) .fontColor(this.palette().accent)
@ -201,6 +219,51 @@ export struct StatusSummaryCard {
} }
} }
/**
* 能力计数小卡(插件 / 工具)。
*
* 单独成组件而非 @Builder:@Builder 的按值参数不会随父组件重渲染而刷新,
* 数值会永远停在首次渲染的 0。@Prop 是单向下发,父组件因 @StorageProp
* 变化重渲染时,子组件拿到新值并重绘。
*/
@Component
struct KpiTile {
@StorageProp('themeIsDark') private isDark: boolean = true;
@Prop icon: Resource = $r('app.media.ic_plug');
@Prop label: string = '';
@Prop value: number = 0;
@Prop tint: string = '';
build() {
Row({ space: 8 }) {
Image(this.icon)
.width(16)
.height(16)
.fillColor(this.tint)
.draggable(false)
Column({ space: 1 }) {
Text(this.value > 0 ? this.value.toString() : '-')
.fontSize(17)
.fontWeight(FontWeight.Bold)
.fontColor(this.palette().textPrimary)
Text(this.label)
.fontSize(11)
.fontColor(this.palette().textMuted)
}
.alignItems(HorizontalAlign.Start)
}
.layoutWeight(1)
.padding({ left: 12, right: 12, top: 10, bottom: 10 })
.borderRadius(RADIUS_SM)
.backgroundColor(this.palette().bgHover)
.alignItems(VerticalAlign.Center)
}
private palette(): ThemePalette {
return this.isDark ? DARK_PALETTE : LIGHT_PALETTE;
}
}
/** /**
* 运行状态明细:设置页「运行状态」二级页面的内容。 * 运行状态明细:设置页「运行状态」二级页面的内容。
* *
@ -271,6 +334,11 @@ export struct StatusDetailContent {
// 于是 31 个插件在 203 个工具旁边只剩一条短线 —— 读数没有意义。 // 于是 31 个插件在 203 个工具旁边只剩一条短线 —— 读数没有意义。
// 数量本身已在摘要卡上以图标+数字直观呈现,这里不再重复。 // 数量本身已在摘要卡上以图标+数字直观呈现,这里不再重复。
// 运行态面板(阶段管道 + 中断队列)放在明细页最前:
// 明细卡回答「内核有哪些东西、多少」,运行态回答「现在在干什么」,
// 后者是进这个页面最先想看的。
RuntimePanel()
ForEach(this.groups, (g: StatGroup) => { ForEach(this.groups, (g: StatGroup) => {
Column() { Column() {
Text(g.title) Text(g.title)

View File

@ -0,0 +1,48 @@
/**
* 右下角轻提示条(设置页与插件页共用)。
*
* 两处原本各写一份,只有"描边"这一处不同:设置页无描边,插件页有。
* 用 bordered 表达这个差异(width 0 的边框不占位、不可见)。
*
* 配色由调用方决定:颜色标志必须在调用方落 animateTo 之前先写好,
* 否则第一帧会用上一条 toast 的配色。
*/
import { ThemePalette, DARK_PALETTE, LIGHT_PALETTE, RADIUS_MD, ANIM_NORMAL } from '../common/Constants';
@Component
export struct ToastBar {
@StorageProp('themeIsDark') private isDark: boolean = true;
@Prop msg: string = '';
@Prop isError: boolean = false;
/** 是否带一圈语义色描边(插件页用,设置页不用) */
@Prop bordered: boolean = false;
private palette(): ThemePalette {
return this.isDark ? DARK_PALETTE : LIGHT_PALETTE;
}
build() {
if (this.msg.length > 0) {
Row() {
Text(this.msg)
.fontSize(13)
.fontColor(this.isError ? this.palette().toastErrorText : this.palette().toastText)
.padding({ left: 20, right: 20, top: 10, bottom: 10 })
.borderRadius(RADIUS_MD)
.backgroundColor(this.isError ? this.palette().toastErrorBg : this.palette().toastBg)
.border({
width: this.bordered ? 1 : 0,
color: this.isError ? 'rgba(232, 64, 38, 0.3)' : 'rgba(23, 169, 100, 0.3)',
})
}
.width('100%')
.justifyContent(FlexAlign.End)
.padding({ right: 20 })
.margin({ bottom: 166 })
.transition(TransitionEffect.OPACITY
.combine(TransitionEffect.translate({ y: 12 }))
.animation({ duration: ANIM_NORMAL, curve: Curve.EaseOut }))
}
}
}

View File

@ -26,6 +26,14 @@ export interface ChatMessage {
toolCalls?: ToolCallInfo[]; toolCalls?: ToolCallInfo[];
/** 消息来源通道:'webui' | 'channel' | 'webui/<device_id>' 等;用于区分设备/渠道消息 */ /** 消息来源通道:'webui' | 'channel' | 'webui/<device_id>' 等;用于区分设备/渠道消息 */
source?: string; source?: string;
/**
* 服务端单调递增序号(后端 ChatMsg.seq)。
*
* 它是与后端增量查询(/chat/history?after=<seq>)对账的唯一定位符:
* 本地乐观消息没有 seq,服务端回显后靠 seq 认领并去重。
* 没有它就只能拿“正文内容”去重,一旦同一句话发两次就会误删。
*/
seq?: number;
/** 图片/文件附件(后端 ChatMsg.attachment) */ /** 图片/文件附件(后端 ChatMsg.attachment) */
attachment?: ChatAttachment; attachment?: ChatAttachment;
} }

File diff suppressed because it is too large Load Diff

View File

@ -4,19 +4,25 @@ import { apiClient } from '../common/ApiClient';
import { handleNavOnScroll } from '../common/NavBarController'; import { handleNavOnScroll } from '../common/NavBarController';
import { registerNavStack, unregisterNavStack } from '../common/NavStackRegistry'; import { registerNavStack, unregisterNavStack } from '../common/NavStackRegistry';
import { DeviceInfo } from '../model/Model'; import { DeviceInfo } from '../model/Model';
import { ThemePalette, DARK_PALETTE, LIGHT_PALETTE, WIDE_NAV_BAR_WIDTH, WIDE_MIN_CONTENT, ANIM_FAST, ANIM_NORMAL, ANIM_ENTER } from '../common/Constants'; import { ThemePalette, DARK_PALETTE, LIGHT_PALETTE, WIDE_NAV_BAR_WIDTH,
import { MotionBase } from '../components/MotionBase'; WIDE_MIN_CONTENT, ANIM_NORMAL, ANIM_ENTER } from '../common/Constants';
import { deviceGatewayUrl } from '../common/DeviceBridgeSession';
import { DeviceRootEntries } from '../components/DeviceRootEntries';
import { DeviceLocalPane, DeviceCapsPane, DeviceGatewayPane, DeviceListPane } from '../components/DevicePanes';
import { PageTopBar, NavFloatOverlay, NavFloatRow, FloatIconButton } from '../components/PageTopBar'; import { PageTopBar, NavFloatOverlay, NavFloatRow, FloatIconButton } from '../components/PageTopBar';
import { SubPageLayer, NavGroup, NavRow, PlainCard, markSubPageOpen, subPageParam } from '../components/SubPage'; import { markSubPageOpen, subPageParam } from '../components/SubPage';
import { LOCAL_DEVICE_CAPS, deviceGatewayUrl } from '../common/DeviceBridgeSession'; import { parseOnlineDevices, resolveDeviceId, SUB_CAPS, SUB_GATEWAY, SUB_LIST,
SUB_LOCAL, SUB_NONE } from '../common/DeviceModel';
/** 二级页面标识 */
const SUB_NONE: string = '';
const SUB_LOCAL: string = 'local';
const SUB_CAPS: string = 'caps';
const SUB_GATEWAY: string = 'gateway';
const SUB_LIST: string = 'list';
/**
* 设备页:只做"页面壳"。
*
* 拆分后的分工(拆分前这里是 560 行的单文件):
* - 一级入口列表(本机/通道两组) → components/DeviceRootEntries.ets
* - 四个二级页面内容(本机/能力/通道/列表)→ components/DevicePanes.ets
* - device_id 兜底与在线设备解析 → common/DeviceModel.ets(路由 id 也在那)
* 本文件保留:导航栈与二级页分发、授权开关、toast、设备列表拉取与生命周期。
*/
@Component @Component
export struct DevicePage { export struct DevicePage {
@StorageProp('themeIsDark') private isDark: boolean = true; @StorageProp('themeIsDark') private isDark: boolean = true;
@ -39,18 +45,8 @@ export struct DevicePage {
private navStack: NavPathStack = new NavPathStack(); private navStack: NavPathStack = new NavPathStack();
aboutToAppear(): void { aboutToAppear(): void {
this.deviceId = deviceBridge.getDeviceId(); // id 判定顺序:桥里的 id 优先于持久化的 id,都没有才生成并落盘
if (this.deviceId.length === 0) { this.deviceId = resolveDeviceId(deviceBridge.getDeviceId());
this.deviceId = connStore.getDeviceId();
}
if (this.deviceId.length === 0) {
this.deviceId = 'ohos-' + Date.now().toString(36);
try {
connStore.saveDeviceId(this.deviceId);
} catch (e) {
// ignore
}
}
this.authorized = connStore.getDeviceAuth(); this.authorized = connStore.getDeviceAuth();
// Gateway URL derives from current connection // Gateway URL derives from current connection
const cur = connStore.getCurrentConnection(); const cur = connStore.getCurrentConnection();
@ -133,31 +129,7 @@ export struct DevicePage {
const resp = await apiClient.get('/device/online'); const resp = await apiClient.get('/device/online');
if (resp.status >= 200 && resp.status < 300) { if (resp.status >= 200 && resp.status < 300) {
const parsed: Record<string, Object> = JSON.parse(resp.body) as Record<string, Object>; const parsed: Record<string, Object> = JSON.parse(resp.body) as Record<string, Object>;
const devs: Object = parsed['devices']; const list: DeviceInfo[] = parseOnlineDevices(parsed);
const list: DeviceInfo[] = [];
if (devs !== undefined && devs !== null) {
const arr: Object[] = devs as Object[];
for (let i = 0; i < arr.length; i++) {
const d: Record<string, Object> = arr[i] as Record<string, Object>;
const capsArr: Object = d['caps'];
const caps: string[] = [];
if (capsArr !== undefined && capsArr !== null) {
const cArr: Object[] = capsArr as Object[];
for (let j = 0; j < cArr.length; j++) {
caps.push(cArr[j] as string);
}
}
const info: DeviceInfo = {
deviceId: d['device_id'] as string ?? '',
name: d['name'] as string ?? '',
kind: d['kind'] as string ?? '',
online: true,
authorized: d['authorized'] as boolean ?? false,
caps: caps,
};
list.push(info);
}
}
this.getUIContext().animateTo({ duration: ANIM_ENTER, curve: Curve.EaseOut }, () => { this.getUIContext().animateTo({ duration: ANIM_ENTER, curve: Curve.EaseOut }, () => {
this.devices = list; this.devices = list;
}); });
@ -177,7 +149,17 @@ export struct DevicePage {
Column() { Column() {
Scroll() { Scroll() {
Column() { Column() {
this.RootEntries() DeviceRootEntries({
activeSub: this.activeSub,
deviceId: this.deviceId,
bridgeConnected: this.bridgeConnected,
bridgeUrl: this.bridgeUrl,
loadingDevices: this.loadingDevices,
deviceCount: this.devices.length,
onOpen: (id: string) => {
this.openSub(id);
},
})
} }
.width('100%') .width('100%')
.padding({ left: 16, right: 16, top: 76, bottom: 174 }) .padding({ left: 16, right: 16, top: 76, bottom: 174 })
@ -248,61 +230,58 @@ export struct DevicePage {
}) })
} }
/** 二级页面路由表 */ /**
* 二级页面路由表。
* 每个面板自带 SubPageLayer 外壳(标题/所属 Tab/返回/刷新),这里只做分发。
*/
@Builder @Builder
SubDestination(name: string, param: object) { SubDestination(name: string, param: object) {
NavDestination() { NavDestination() {
if (name === SUB_LOCAL) { if (name === SUB_LOCAL) {
SubPageLayer({ DeviceLocalPane({
title: '本机设备', deviceId: this.deviceId,
tab: 2, authorized: this.authorized,
onBack: () => { onBack: () => {
this.closeSub(); this.closeSub();
}, },
}) { onToggleAuth: (on: boolean) => {
this.LocalDeviceContent() this.toggleAuthorized(on);
} },
})
} else if (name === SUB_CAPS) { } else if (name === SUB_CAPS) {
SubPageLayer({ DeviceCapsPane({
title: '设备能力',
tab: 2,
onBack: () => { onBack: () => {
this.closeSub(); this.closeSub();
}, },
}) { })
this.CapsContent()
}
} else if (name === SUB_GATEWAY) { } else if (name === SUB_GATEWAY) {
SubPageLayer({ DeviceGatewayPane({
title: '设备通道', bridgeUrl: this.bridgeUrl,
tab: 2, bridgeToken: this.bridgeToken,
bridgeConnected: this.bridgeConnected,
onBack: () => { onBack: () => {
this.closeSub(); this.closeSub();
}, },
}) {
this.GatewayContent()
}
} else if (name === SUB_LIST) {
SubPageLayer({
title: '接入的设备',
tab: 2,
onBack: () => {
this.closeSub();
},
showRefresh: true,
onRefresh: () => { onRefresh: () => {
this.refreshDevices(); this.refreshDevices();
}, },
}) { })
this.OnlineDevicesContent() } else if (name === SUB_LIST) {
} DeviceListPane({
devices: this.devices,
onBack: () => {
this.closeSub();
},
onRefresh: () => {
this.refreshDevices();
},
})
} }
} }
.hideTitleBar(true) .hideTitleBar(true)
.backgroundColor(Color.Transparent) .backgroundColor(Color.Transparent)
} }
@Builder @Builder
Toast() { Toast() {
if (this.toastMsg.length > 0) { if (this.toastMsg.length > 0) {
@ -323,238 +302,6 @@ export struct DevicePage {
.animation({ duration: ANIM_NORMAL, curve: Curve.EaseOut })) .animation({ duration: ANIM_NORMAL, curve: Curve.EaseOut }))
} }
} }
// ===================== 一级入口列表 =====================
@Builder
RootEntries() {
NavGroup({ caption: '本机' }) {
NavRow({
icon: $r('app.media.ic_phone'),
title: '本机设备',
subtitle: this.deviceId.length > 0 ? this.deviceId : '未注册',
value: this.bridgeConnected ? '在线' : '离线',
selected: this.isWide && this.activeSub === SUB_LOCAL,
onTap: () => {
this.openSub(SUB_LOCAL);
},
})
NavRow({
icon: $r('app.media.ic_bolt'),
title: '设备能力',
subtitle: this.capsCount().toString() + ' 项能力',
value: '',
showDivider: false,
selected: this.isWide && this.activeSub === SUB_CAPS,
onTap: () => {
this.openSub(SUB_CAPS);
},
})
}
NavGroup({ caption: '通道' }) {
NavRow({
icon: $r('app.media.ic_gateway'),
title: '设备通道',
subtitle: this.bridgeUrl.length > 0 ? '网关已配置' : '未配置',
value: this.bridgeConnected ? '已连接' : '未连接',
selected: this.isWide && this.activeSub === SUB_GATEWAY,
onTap: () => {
this.openSub(SUB_GATEWAY);
},
})
NavRow({
icon: $r('app.media.ic_devices_multi'),
title: '接入的设备',
subtitle: this.loadingDevices ? '加载中...' : '当前在线',
value: this.devices.length.toString() + ' 台',
showDivider: false,
selected: this.isWide && this.activeSub === SUB_LIST,
onTap: () => {
this.openSub(SUB_LIST);
},
})
}
}
private capsCount(): number {
return LOCAL_DEVICE_CAPS.length;
}
// ===================== 二级:本机设备 =====================
@Builder
LocalDeviceContent() {
PlainCard({ caption: '基本信息' }) {
this.KvRow('设备 ID', this.deviceId.length > 0 ? this.deviceId : '未注册')
this.KvRow('名称', 'HomeAgent OHOS')
this.KvRow('类型', 'phone')
}
PlainCard({ caption: '权限控制' }) {
Row() {
Column({ space: 2 }) {
Text('允许 agent 控制本机')
.fontSize(14)
.fontColor(this.palette().textPrimary)
Text('授权后 agent 可调用下方能力;截屏仅捕获本应用画面,剪贴板读取需系统弹窗确认。')
.fontSize(11)
.fontColor(this.palette().textMuted)
.margin({ top: 4 })
}
.layoutWeight(1)
.alignItems(HorizontalAlign.Start)
Toggle({ type: ToggleType.Switch, isOn: this.authorized })
.selectedColor(this.palette().accent)
.onChange((on: boolean) => {
this.toggleAuthorized(on);
})
}
.width('100%')
.alignItems(VerticalAlign.Center)
Row() {
Circle({ width: 8, height: 8 })
.fill(this.authorized ? '#17A964' : '#E84026')
.animation({ duration: ANIM_NORMAL, curve: Curve.EaseOut })
.margin({ right: 8 })
Text(this.authorized ? '已授权 — agent 可远程调用能力' : '未授权 — agent 将拒绝远程命令')
.fontSize(12)
.fontColor(this.authorized ? '#17A964' : this.palette().textMuted)
.animation({ duration: ANIM_NORMAL, curve: Curve.EaseOut })
}
.width('100%')
.margin({ top: 12 })
.padding({ left: 4 })
}
}
// ===================== 二级:设备能力 =====================
@Builder
CapsContent() {
PlainCard({ caption: '能力清单' }) {
Text('agent 通过设备桥可调用的本机能力:')
.fontSize(12)
.fontColor(this.palette().textMuted)
.margin({ bottom: 10 })
Flex({ wrap: FlexWrap.Wrap }) {
ForEach(LOCAL_DEVICE_CAPS, (cap: string) => {
Text(cap)
.fontSize(11)
.fontColor(this.palette().accent)
.padding({ left: 8, right: 8, top: 4, bottom: 4 })
.borderRadius(999)
.backgroundColor(this.palette().bgHover)
.border({ width: 1, color: this.palette().glassBorder })
.margin({ right: 6, bottom: 6 })
}, (cap: string) => cap)
}
.width('100%')
}
}
// ===================== 二级:设备通道 =====================
@Builder
GatewayContent() {
PlainCard({ caption: '连接信息' }) {
this.KvRow('网关地址', this.bridgeUrl.length > 0 ? this.bridgeUrl : '-')
this.KvRow('Token', this.bridgeToken.length > 0 ? '已从连接继承' : '未配置')
this.KvRow('状态', this.bridgeConnected ? '已连接' : '未连接')
}
PlainCard({ caption: '操作' }) {
Row() {
Blank()
MotionBase({ pressEnabled: true, fillWidth: false }) {
Button('刷新设备')
.height(34)
.fontSize(12)
.backgroundColor(Color.Transparent)
.border({ width: 1, color: this.palette().btnGhostBorder })
.fontColor(this.palette().textSecondary)
.onClick(() => {
this.refreshDevices();
})
}
}
.width('100%')
Text('设备通道由应用前台生命周期统一管理;切换连接配置后会自动使用新地址和 Token。')
.fontSize(11)
.fontColor(this.palette().textMuted)
.margin({ top: 10 })
}
}
// ===================== 二级:接入的设备 =====================
@Builder
OnlineDevicesContent() {
if (this.devices.length === 0) {
Text('暂无其他设备。电脑 GUI 或 CLI 连接同一网关后会出现在这里。')
.fontSize(12)
.fontColor(this.palette().textMuted)
.padding({ left: 4 })
.transition(TransitionEffect.OPACITY.animation({ duration: ANIM_FAST, curve: Curve.EaseOut }))
}
ForEach(this.devices, (dev: DeviceInfo) => {
// PlainCard 是自定义组件,transition 不能直接挂在它上面(会生成 __Common__ 包装),
// 所以用一个无 padding、满宽的 Column 承载入场动画,布局不受影响。
Column() {
PlainCard({ caption: '' }) {
Row() {
Circle({ width: 8, height: 8 })
.fill(dev.online ? '#17A964' : '#77809A')
.margin({ right: 10 })
Column() {
Text(dev.name.length > 0 ? dev.name : dev.deviceId)
.fontSize(14)
.fontColor(this.palette().textPrimary)
Text(dev.kind + (dev.authorized ? ' · 已授权' : ' · 未授权'))
.fontSize(11)
.fontColor(dev.authorized ? '#17A964' : this.palette().textMuted)
}
.layoutWeight(1)
.alignItems(HorizontalAlign.Start)
Text(dev.caps.length.toString() + ' 能力')
.fontSize(10)
.fontColor(this.palette().textMuted)
}
.width('100%')
}
}
.width('100%')
.transition(TransitionEffect.OPACITY
.combine(TransitionEffect.translate({ y: 12 }))
.animation({ duration: ANIM_ENTER, curve: Curve.EaseOut }))
}, (dev: DeviceInfo) => dev.deviceId + dev.online.toString())
}
// ===================== 通用 KV 行 =====================
@Builder
KvRow(k: string, v: string) {
Row() {
Text(k)
.fontSize(13)
.fontColor(this.palette().textSecondary)
Blank()
Text(v)
.fontSize(13)
.fontColor(this.palette().textPrimary)
.maxLines(1)
.textOverflow({ overflow: TextOverflow.Ellipsis })
}
.width('100%')
.padding({ top: 8, bottom: 8 })
.border({ width: { bottom: 1 }, color: this.palette().kvBorder })
}
} }
const RADIUS_MD: number = 10; const RADIUS_MD: number = 10;

View File

@ -7,14 +7,15 @@ import { apiClient } from '../common/ApiClient';
import { navBar } from '../common/NavBarController'; import { navBar } from '../common/NavBarController';
import { handleBackPress } from '../common/NavStackRegistry'; import { handleBackPress } from '../common/NavStackRegistry';
import { ConnectionConfig } from '../model/Model'; import { ConnectionConfig } from '../model/Model';
import { ThemePalette, DARK_PALETTE, LIGHT_PALETTE, WIDE_MIN_WIDTH, WIDE_NAV_BAR_WIDTH } from '../common/Constants'; import { ThemePalette, DARK_PALETTE, LIGHT_PALETTE, WIDE_MIN_WIDTH, WIDE_NAV_BAR_WIDTH, K_HAS_CONN, K_REQUESTED_TAB, K_SETTINGS_SUB } from '../common/Constants';
import { ANIM_NORMAL, ANIM_SLOW } from '../common/Constants'; import { ANIM_NORMAL, ANIM_SLOW } from '../common/Constants';
import { MotionBase } from '../components/MotionBase'; import { MotionBase } from '../components/MotionBase';
import { GradientBackground } from '../components/GradientBackground'; import { GradientBackground } from '../components/GradientBackground';
import { ScreensuePage } from '../components/ScreensuePage'; import { ScreensuePage } from '../components/ScreensuePage';
import { registerScreensueHandler } from '../common/BridgeRouter'; import { registerScreensueHandler } from '../common/BridgeRouter';
import { markForegroundBridgeUIReady } from '../common/DeviceBridgeSession'; import { markForegroundBridgeUIReady } from '../common/DeviceBridgeSession';
import { ScreensuePayload, snapshotComponentId } from '../common/BridgeCaps'; import { snapshotComponentId } from '../common/BridgeCaps';
import { ScreensuePayload } from '../common/ScreensueHtml';
import { window, display } from '@kit.ArkUI'; import { window, display } from '@kit.ArkUI';
import { common } from '@kit.AbilityKit'; import { common } from '@kit.AbilityKit';
@ -83,6 +84,8 @@ struct Index {
/** 底部手势条高度(vp) */ /** 底部手势条高度(vp) */
@State bottomGesture: number = 16; @State bottomGesture: number = 16;
@StorageProp('themeIsDark') @Watch('onThemeChanged') private isDark: boolean = true; @StorageProp('themeIsDark') @Watch('onThemeChanged') private isDark: boolean = true;
/** 外部请求切换主 Tab(未连接时聊天空态的“去设置连接”用) */
@StorageProp(K_REQUESTED_TAB) @Watch('onRequestedTab') private requestedTab: number = -1;
private swiper: SwiperController = new SwiperController(); private swiper: SwiperController = new SwiperController();
private screensueTimer: number = -1; private screensueTimer: number = -1;
private snapshotBuilder: CustomBuilder = (): void => { }; // 由 @Builder 传入的实际锚点 private snapshotBuilder: CustomBuilder = (): void => { }; // 由 @Builder 传入的实际锚点
@ -101,6 +104,12 @@ struct Index {
if (cur !== null) { if (cur !== null) {
apiClient.setConnection(cur); apiClient.setConnection(cur);
} }
// 后端连接状态广播:聊天空态根据它决定是否显示“去设置连接”。
// Index.aboutToAppear 在 EntryAbility 等 connStore.init 之后才跑,
// 所以此处读到的连接状态就是真实的启动态。
AppStorage.setOrCreate<boolean>(K_HAS_CONN, apiClient.hasConnection());
AppStorage.setOrCreate<number>(K_REQUESTED_TAB, -1);
AppStorage.setOrCreate<string>(K_SETTINGS_SUB, '');
// 种子化自定义背景图状态到 AppStorage,GradientBackground 响应读取 // 种子化自定义背景图状态到 AppStorage,GradientBackground 响应读取
const st = connStore.getSettings(); const st = connStore.getSettings();
AppStorage.setOrCreate<string>('bgImage', st.bgImage ?? ''); AppStorage.setOrCreate<string>('bgImage', st.bgImage ?? '');
@ -191,6 +200,23 @@ struct Index {
AppStorage.set<number>('currentTab', this.currentTab); AppStorage.set<number>('currentTab', this.currentTab);
} }
/**
* 响应外部切 Tab 请求(聊天空态的“去设置连接”)。
*
* 为什么不能直接改 AppStorage 的 currentTab:Index 的 currentTab 是
* @State,Swiper.index() 只认它;外部写 AppStorage 不会驱动 Swiper。
* 所以用独立请求键 + @Watch 把请求转成自己的状态变更。
*/
private onRequestedTab(): void {
const t: number = this.requestedTab;
AppStorage.set<number>(K_REQUESTED_TAB, -1);
if (t < 0 || t >= this.tabs.length) {
return;
}
this.currentTab = t;
navBar.setVisible(true);
}
private syncSystemBar(): void { private syncSystemBar(): void {
const dark: boolean = this.isDark; const dark: boolean = this.isDark;
const bg: string = dark ? '#000000' : '#F1F3F5'; const bg: string = dark ? '#000000' : '#F1F3F5';

View File

@ -1,24 +1,26 @@
import { apiClient } from '../common/ApiClient'; import { apiClient } from '../common/ApiClient';
import { userMessage, noConnectionMessage } from '../common/UserError'; import { userMessage } from '../common/UserError';
import { handleNavOnScroll } from '../common/NavBarController'; import { handleNavOnScroll } from '../common/NavBarController';
import { registerNavStack, unregisterNavStack } from '../common/NavStackRegistry'; import { registerNavStack, unregisterNavStack } from '../common/NavStackRegistry';
import { PluginRow, PluginDetail, emptyPluginDetail } from '../model/Model'; import { PluginRow, PluginDetail, emptyPluginDetail } from '../model/Model';
import { ThemePalette, DARK_PALETTE, LIGHT_PALETTE, WIDE_NAV_BAR_WIDTH, WIDE_MIN_CONTENT } from '../common/Constants'; import { ThemePalette, DARK_PALETTE, LIGHT_PALETTE, WIDE_NAV_BAR_WIDTH, WIDE_MIN_CONTENT } from '../common/Constants';
import { RADIUS_LG, RADIUS_MD, RADIUS_SM, RADIUS_PILL, COLOR_ERROR } from '../common/Constants'; import { ANIM_NORMAL, ANIM_ENTER } from '../common/Constants';
import { ANIM_FAST, ANIM_NORMAL, ANIM_ENTER } from '../common/Constants'; import { PageTopBar, NavFloatOverlay, NavFloatRow, FloatIconButton } from '../components/PageTopBar';
import { MotionBase } from '../components/MotionBase'; import { SubPageLayer, markSubPageOpen, subPageParam } from '../components/SubPage';
import { PageTopBar, NavFloatOverlay, NavFloatRow, GlassShell, FloatIconButton } from '../components/PageTopBar'; import { PluginDetailPane } from '../components/PluginDetailPane';
import { SubPageLayer, PlainCard, markSubPageOpen, subPageParam } from '../components/SubPage'; import { PluginListView } from '../components/PluginListView';
import { SettingsEditor } from '../components/SettingsEditor'; import { PluginInstallForm } from '../components/PluginsOverlays';
import { ToastBar } from '../components/ToastBar';
interface InstallBody { import { fetchPluginRows, fetchPluginDetail } from '../common/PluginApi';
url: string;
}
/** 二级页面标识:插件详情 */ /** 二级页面标识:插件详情 */
const SUB_NONE: string = ''; const SUB_NONE: string = '';
const SUB_DETAIL: string = 'detail'; const SUB_DETAIL: string = 'detail';
interface InstallBody {
url: string;
}
@Component @Component
export struct PluginsPage { export struct PluginsPage {
@StorageProp('themeIsDark') private isDark: boolean = true; @StorageProp('themeIsDark') private isDark: boolean = true;
@ -58,134 +60,14 @@ export struct PluginsPage {
return this.isDark ? DARK_PALETTE : LIGHT_PALETTE; return this.isDark ? DARK_PALETTE : LIGHT_PALETTE;
} }
/** /** 取数口径见 common/PluginApi.ets;这里只负责把结果落到 @State。 */
* 数据源对齐 WebGUI renderPlugins:
* - GET /kernel → plugins[{name,loaded}](含全部内置插件)+ tools(按 plugin 归属)
* - GET /plugins → 已安装外部插件元数据(version/description 等)
* - GET /plugins/disabled → {disabled:[{name,...}]}
* 三方按名称合并去重排序。
*/
private async loadPlugins(): Promise<void> { private async loadPlugins(): Promise<void> {
if (!apiClient.hasConnection()) { if (!apiClient.hasConnection()) {
return; return;
} }
this.loading = true; this.loading = true;
try { try {
// ---- kernel: loaded plugins + tool ownership ---- const rows: PluginRow[] = await fetchPluginRows();
const kResp = await apiClient.getWithTimeout('/kernel', 12000);
const kernelObj: Record<string, Object> = JSON.parse(kResp.body) as Record<string, Object>;
const loadedMap: Map<string, boolean> = new Map<string, boolean>();
const kpRaw: Object | undefined = kernelObj['plugins'];
if (kpRaw !== undefined && kpRaw !== null) {
const kpArr: Object[] = kpRaw as Object[];
for (let i = 0; i < kpArr.length; i++) {
const item: Record<string, Object> = kpArr[i] as Record<string, Object>;
const n: string = item['name'] as string ?? '';
if (n.length === 0) {
continue;
}
loadedMap.set(n, item['loaded'] as boolean ?? true);
}
}
const toolsByPlugin: Map<string, string[]> = new Map<string, string[]>();
const tRaw: Object | undefined = kernelObj['tools'];
if (tRaw !== undefined && tRaw !== null) {
const tArr: Object[] = tRaw as Object[];
for (let i = 0; i < tArr.length; i++) {
const item: Record<string, Object> = tArr[i] as Record<string, Object>;
const tn: string = item['name'] as string ?? '';
const owner: string = item['plugin'] as string ?? '';
if (tn.length === 0 || owner.length === 0) {
continue;
}
let list: string[] | undefined = toolsByPlugin.get(owner);
if (list === undefined) {
list = [];
toolsByPlugin.set(owner, list);
}
// 每插件最多展示 8 个工具名,避免卡片过长
if (list.length < 8) {
list.push(tn);
}
}
}
// ---- installed external plugins metadata ----
const externalMeta: Map<string, Record<string, Object>> = new Map<string, Record<string, Object>>();
try {
const pResp = await apiClient.getWithTimeout('/plugins', 10000);
const bodyTrim = pResp.body.trim();
let arr: Object[] = [];
if (bodyTrim.length > 0 && bodyTrim.charAt(0) === '[') {
arr = JSON.parse(pResp.body) as Object[];
} else {
const obj: Record<string, Object> = JSON.parse(pResp.body) as Record<string, Object>;
const rawList: Object = obj['plugins'] ?? obj['data'];
if (rawList !== undefined && rawList !== null) {
arr = rawList as Object[];
}
}
for (let i = 0; i < arr.length; i++) {
const item: Record<string, Object> = arr[i] as Record<string, Object>;
const n: string = item['name'] as string ?? '';
if (n.length > 0) {
externalMeta.set(n, item);
}
}
} catch (e) {
// 外部列表失败不阻塞内置展示
}
// ---- disabled list ----
const disabledNames: Set<string> = new Set<string>();
try {
const dResp = await apiClient.getWithTimeout('/plugins/disabled', 8000);
const dObj: Record<string, Object> = JSON.parse(dResp.body) as Record<string, Object>;
const dArr: Object | undefined = dObj['disabled'];
if (dArr !== undefined && dArr !== null) {
const items: Object[] = dArr as Object[];
for (let di = 0; di < items.length; di++) {
const dItem: Record<string, Object> = items[di] as Record<string, Object>;
const dn: string = dItem['name'] as string ?? '';
if (dn.length > 0) {
disabledNames.add(dn);
}
}
}
} catch (e) {
// disabled endpoint may not exist; ignore
}
// ---- merge: allNames sorted(与 GUI 一致)----
const allNames: Set<string> = new Set<string>();
loadedMap.forEach((v: boolean, k: string) => {
allNames.add(k);
});
externalMeta.forEach((v: Record<string, Object>, k: string) => {
allNames.add(k);
});
disabledNames.forEach((n: string) => {
allNames.add(n);
});
const names: string[] = Array.from(allNames);
names.sort();
const rows: PluginRow[] = [];
for (let i = 0; i < names.length; i++) {
const name: string = names[i];
const meta: Record<string, Object> | undefined = externalMeta.get(name);
const tools: string[] | undefined = toolsByPlugin.get(name);
const row: PluginRow = {
name: name,
loaded: loadedMap.get(name) ?? false,
disabled: disabledNames.has(name),
external: externalMeta.has(name),
version: meta !== undefined ? meta['version'] as string ?? '' : '',
description: meta !== undefined ? meta['description'] as string ?? '' : '',
tools: tools,
};
rows.push(row);
}
// 列表整体重建(ForEach key 含 loaded/disabled,启停会整行重挂载): // 列表整体重建(ForEach key 含 loaded/disabled,启停会整行重挂载):
// 放进 animateTo 让新旧行走 transition 交叉淡入,而不是硬切一帧。 // 放进 animateTo 让新旧行走 transition 交叉淡入,而不是硬切一帧。
this.getUIContext().animateTo({ duration: ANIM_ENTER, curve: Curve.EaseOut }, () => { this.getUIContext().animateTo({ duration: ANIM_ENTER, curve: Curve.EaseOut }, () => {
@ -199,20 +81,6 @@ export struct PluginsPage {
}); });
} }
/** 徽标状态:与 GUI 一致 —— 已加载绿 / 禁用待生效黄 / 已禁用红 / 未加载灰。 */
private statusOf(plugin: PluginRow): string {
if (plugin.loaded && !plugin.disabled) {
return 'loaded'; // 已加载
}
if (plugin.loaded && plugin.disabled) {
return 'pending'; // 运行中(禁用待生效)
}
if (plugin.disabled) {
return 'disabled'; // 已禁用
}
return 'notloaded'; // 未加载
}
private async togglePlugin(plugin: PluginRow): Promise<void> { private async togglePlugin(plugin: PluginRow): Promise<void> {
const name: string = plugin.name; const name: string = plugin.name;
const action: string = plugin.disabled ? 'enable' : 'disable'; const action: string = plugin.disabled ? 'enable' : 'disable';
@ -280,29 +148,14 @@ export struct PluginsPage {
} }
/** /**
* GET /plugins/{name} —— 后端返回插件清单字段。 * 详情数据落地。
* WebGUI 只是把它 JSON.stringify 进 <pre>,这里逐字段结构化展示。
* 内置插件不在 /plugins 里,取不到详情时退回用列表已有的信息。 * 内置插件不在 /plugins 里,取不到详情时退回用列表已有的信息。
*/ */
private async loadDetail(name: string): Promise<void> { private async loadDetail(name: string): Promise<void> {
this.detailLoading = true; this.detailLoading = true;
this.detailError = ''; this.detailError = '';
try { try {
const resp = await apiClient.getWithTimeout('/plugins/' + name, 10000); const d: PluginDetail = await fetchPluginDetail(name);
const o: Record<string, Object> = JSON.parse(resp.body) as Record<string, Object>;
const d: PluginDetail = emptyPluginDetail();
d.name = o['name'] as string ?? name;
d.version = o['version'] as string ?? '';
d.description = o['description'] as string ?? '';
d.author = o['author'] as string ?? '';
d.license = o['license'] as string ?? '';
d.homepage = o['homepage'] as string ?? '';
d.repository = o['repository'] as string ?? '';
d.entry = o['entry'] as string ?? '';
d.minVersion = o['min_version'] as string ?? '';
d.deprecated = o['deprecated'] as boolean ?? false;
d.tags = this.strArray(o['tags']);
d.files = this.strArray(o['files']);
// 详情字段一次性落地:条件卡片在 animateTo 帧内挂载,V1 给它们默认透明度过渡 // 详情字段一次性落地:条件卡片在 animateTo 帧内挂载,V1 给它们默认透明度过渡
this.getUIContext().animateTo({ duration: ANIM_ENTER, curve: Curve.EaseOut }, () => { this.getUIContext().animateTo({ duration: ANIM_ENTER, curve: Curve.EaseOut }, () => {
this.detail = d; this.detail = d;
@ -327,21 +180,6 @@ export struct PluginsPage {
}); });
} }
private strArray(raw: Object | undefined): string[] {
const out: string[] = [];
if (raw === undefined || raw === null) {
return out;
}
const arr: Object[] = raw as Object[];
for (let i = 0; i < arr.length; i++) {
const s: string = arr[i] as string ?? '';
if (s.length > 0) {
out.push(s);
}
}
return out;
}
private findRow(name: string): PluginRow | null { private findRow(name: string): PluginRow | null {
for (let i = 0; i < this.plugins.length; i++) { for (let i = 0; i < this.plugins.length; i++) {
if (this.plugins[i].name === name) { if (this.plugins[i].name === name) {
@ -387,8 +225,15 @@ export struct PluginsPage {
Column() { Column() {
Scroll() { Scroll() {
Column() { Column() {
this.ListStates() PluginListView({
this.PluginList() plugins: this.plugins,
busy: this.loading,
activeName: this.activeName,
hasConn: apiClient.hasConnection(),
onSelect: (name: string) => {
this.openDetail(name);
},
})
} }
.width('100%') .width('100%')
.padding({ left: 16, right: 16, top: 76, bottom: 174 }) .padding({ left: 16, right: 16, top: 76, bottom: 174 })
@ -411,7 +256,15 @@ export struct PluginsPage {
// 安装表单以悬浮卡形式浮在按钮上方,不再占用列表顶部一行。 // 安装表单以悬浮卡形式浮在按钮上方,不再占用列表顶部一行。
NavFloatOverlay({ tab: 1 }) { NavFloatOverlay({ tab: 1 }) {
if (this.showInstallForm) { if (this.showInstallForm) {
this.InstallForm() PluginInstallForm({
url: this.installUrl,
onUrlChange: (v: string) => {
this.installUrl = v;
},
onInstall: () => {
this.installPlugin();
},
})
} }
NavFloatRow() { NavFloatRow() {
FloatIconButton({ FloatIconButton({
@ -441,7 +294,7 @@ export struct PluginsPage {
} }
} }
this.Toast() ToastBar({ msg: this.toastMsg, isError: this.toastIsError, bordered: true })
} }
.width('100%') .width('100%')
.height('100%') .height('100%')
@ -493,503 +346,29 @@ export struct PluginsPage {
this.loadDetail(this.activeName); this.loadDetail(this.activeName);
}, },
}) { }) {
this.DetailContent() PluginDetailPane({
detail: this.detail,
activeName: this.activeName,
busy: this.detailLoading,
errorText: this.detailError,
row: this.activeRow() ?? undefined,
onToggle: () => {
const r: PluginRow | null = this.activeRow();
if (r !== null) {
this.togglePlugin(r);
}
},
onRemove: () => {
const r: PluginRow | null = this.activeRow();
if (r !== null) {
this.removePlugin(r);
}
},
})
} }
} }
} }
.hideTitleBar(true) .hideTitleBar(true)
.backgroundColor(Color.Transparent) .backgroundColor(Color.Transparent)
} }
/** 安装表单:悬浮在安装按钮上方的一张玻璃卡(点悬浮按钮开合) */
@Builder
InstallForm() {
Row() {
TextInput({ placeholder: '.hmap 包下载 URL', text: this.installUrl })
.layoutWeight(1)
.height(36)
.fontSize(14)
.fontColor(this.palette().textPrimary)
.placeholderColor(this.palette().textMuted)
.backgroundColor(this.palette().bgInput)
.borderRadius(RADIUS_SM)
.border({ width: 1, color: this.palette().border })
.onChange((v: string) => {
this.installUrl = v;
})
Button('安装')
.height(36)
.fontSize(12)
.backgroundColor(this.palette().accent)
.fontColor('#FFFFFF')
.margin({ left: 6 })
.onClick(() => {
this.installPlugin();
})
}
.width('100%')
.padding(10)
.margin({ bottom: 10 })
.backgroundColor(this.palette().navBarBg)
.borderRadius(RADIUS_MD)
.border({ width: 1, color: this.palette().navBarBorder })
.shadow({ radius: 20, color: this.palette().shadow, offsetY: 6 })
.alignItems(VerticalAlign.Center)
.transition(TransitionEffect.OPACITY
.combine(TransitionEffect.translate({ y: 12 }))
.animation({ duration: ANIM_ENTER, curve: Curve.EaseOut }))
}
/** 加载中 / 未配置 / 空列表三种占位态 */
@Builder
ListStates() {
if (this.loading && this.plugins.length === 0) {
LoadingProgress()
.width(32)
.height(32)
.color(this.palette().accent)
.margin({ top: 40 })
.transition(TransitionEffect.OPACITY.animation({ duration: ANIM_FAST, curve: Curve.EaseOut }))
}
if (!apiClient.hasConnection()) {
Text(noConnectionMessage())
.fontSize(13)
.fontColor(this.palette().textMuted)
.padding(20)
.transition(TransitionEffect.OPACITY.animation({ duration: ANIM_FAST, curve: Curve.EaseOut }))
}
if (!this.loading && this.plugins.length === 0 && apiClient.hasConnection()) {
Text('暂无已加载插件')
.fontSize(13)
.fontColor(this.palette().textMuted)
.padding(20)
.transition(TransitionEffect.OPACITY.animation({ duration: ANIM_FAST, curve: Curve.EaseOut }))
}
}
/**
* 一级列表:每个插件一张紧凑卡(名称 + 状态徽标 + 右尖角)。
* 描述、工具清单、启停/卸载操作全部下沉到详情页 —— 列表只负责选择。
*/
@Builder
PluginList() {
ForEach(this.plugins, (plugin: PluginRow) => {
// 外层 Column 只为承载 transition:.transition() 不能直接挂在自定义组件
// 调用点上(会生成 __Common__ 包装节点)。按压缩放由 MotionBase 统一提供,
// 每行自带独立按压态,不再需要 pressedName 这种"哪一行被按"的手工记账。
Column() {
MotionBase({ pressEnabled: true }) {
Row() {
Column({ space: 3 }) {
Row({ space: 6 }) {
Text(plugin.name)
.fontSize(15)
.fontWeight(this.activeName === plugin.name ? FontWeight.Medium : FontWeight.Normal)
.fontColor(this.activeName === plugin.name
? this.palette().accent : this.palette().textPrimary)
.maxLines(1)
.textOverflow({ overflow: TextOverflow.Ellipsis })
.animation({ duration: ANIM_FAST, curve: Curve.EaseOut })
if (plugin.version !== undefined && plugin.version.length > 0) {
Text('v' + plugin.version)
.fontSize(10)
.fontColor(this.palette().textMuted)
}
}
// 徽标全部去掉(用户要求):状态用一个 3vp 圆点表达,
// 其余信息退化为一行灰字副标题 —— 列表只负责"选谁",细节看详情页。
Row({ space: 6 }) {
Circle({ width: 6, height: 6 })
.fill(this.statusDotColor(plugin))
Text(this.rowSubtitle(plugin))
.fontSize(11)
.fontColor(this.palette().textMuted)
.maxLines(1)
.textOverflow({ overflow: TextOverflow.Ellipsis })
.layoutWeight(1)
}
.width('100%')
.alignItems(VerticalAlign.Center)
}
.layoutWeight(1)
.alignItems(HorizontalAlign.Start)
Image($r('app.media.ic_chevron_right'))
.width(15)
.height(15)
.fillColor(this.activeName === plugin.name
? this.palette().accent : this.palette().textMuted)
.animation({ duration: ANIM_FAST, curve: Curve.EaseOut })
.draggable(false)
}
.width('100%')
.padding(14)
.borderRadius(RADIUS_LG)
.backgroundColor(this.activeName === plugin.name
? this.palette().accentBg : this.palette().bgCard)
.border({
width: 1,
color: this.activeName === plugin.name
? this.palette().accent : this.palette().glassBorder,
})
// 选中态的底色/描边渐变:MotionBase 的 .animation() 到不了这里
.animation({ duration: ANIM_FAST, curve: Curve.EaseOut })
.alignItems(VerticalAlign.Center)
.onClick(() => {
this.openDetail(plugin.name);
})
}
}
.width('100%')
.margin({ bottom: 10 })
// ForEach key 含 loaded/disabled:启停会整行重挂载,靠 transition 变成交叉淡入
.transition(TransitionEffect.OPACITY
.combine(TransitionEffect.translate({ y: 12 }))
.animation({ duration: ANIM_ENTER, curve: Curve.EaseOut }))
}, (plugin: PluginRow) => plugin.name + (plugin.loaded ? 'L' : '') + (plugin.disabled ? 'D' : ''))
}
/**
* 二级页面:插件详情。
* WebGUI 这里只有一个 JSON.stringify 的 <pre>,
* 移植时改成结构化卡片:状态 / 清单字段 / 工具 / 操作。
*/
@Builder
DetailContent() {
if (this.detailLoading) {
Row() {
LoadingProgress()
.width(26)
.height(26)
.color(this.palette().accent)
}
.width('100%')
.justifyContent(FlexAlign.Center)
.padding({ top: 30, bottom: 30 })
.transition(TransitionEffect.OPACITY.animation({ duration: ANIM_FAST, curve: Curve.EaseOut }))
}
if (this.detailError.length > 0) {
Text(this.detailError)
.fontSize(12)
.fontColor(COLOR_ERROR)
.padding({ left: 4, bottom: 12 })
.transition(TransitionEffect.OPACITY.animation({ duration: ANIM_FAST, curve: Curve.EaseOut }))
}
// 概览卡:名称、版本、状态徽标、描述
PlainCard({ caption: '概览' }) {
Row({ space: 8 }) {
Text(this.detail.name.length > 0 ? this.detail.name : this.activeName)
.fontSize(17)
.fontWeight(FontWeight.Bold)
.fontColor(this.palette().textPrimary)
.layoutWeight(1)
.maxLines(1)
.textOverflow({ overflow: TextOverflow.Ellipsis })
if (this.detail.version.length > 0) {
Text('v' + this.detail.version)
.fontSize(12)
.fontColor(this.palette().textSecondary)
}
}
.width('100%')
.margin({ bottom: 10 })
this.DetailBadges()
if (this.detail.description.length > 0) {
Text(this.detail.description)
.fontSize(13)
.fontColor(this.palette().textSecondary)
.width('100%')
.margin({ top: 10 })
}
}
// 清单卡:只有真拿到字段才出卡,否则会留一张空壳(内置插件没有清单文件)
if (this.hasManifest()) {
PlainCard({ caption: '清单' }) {
this.KvRow('作者', this.detail.author)
this.KvRow('许可证', this.detail.license)
this.KvRow('主页', this.detail.homepage)
this.KvRow('仓库', this.detail.repository)
this.KvRow('入口', this.detail.entry)
this.KvRow('最低内核版本', this.detail.minVersion)
}
}
if (this.detail.tags.length > 0) {
PlainCard({ caption: '标签' }) {
Flex({ wrap: FlexWrap.Wrap }) {
ForEach(this.detail.tags, (t: string) => {
Text(t)
.fontSize(10)
.fontColor('#4A90D9')
.padding({ left: 8, right: 8, top: 3, bottom: 3 })
.borderRadius(RADIUS_SM)
.backgroundColor(this.palette().frostSoftBg)
.margin({ right: 5, bottom: 5 })
}, (t: string) => t)
}
}
}
this.DetailTools()
// 插件配置:plugin.<name>.* 从后端 /settings?prefix= 取,就地编辑。
// 这些 key 属于插件本身,之前被平铺在「设置 → 后端配置」里,
// 现在归位到插件详情页 —— 「插件的设计页面就是插件的详情页」。
if (this.activeName.length > 0) {
PlainCard({ caption: '插件配置' }) {
SettingsEditor({
prefix: 'plugin.' + this.activeName + '.',
emptyHint: '该插件没有暴露可配置项',
})
}
}
if (this.detail.files.length > 0) {
PlainCard({ caption: '文件 (' + this.detail.files.length.toString() + ')' }) {
ForEach(this.detail.files, (f: string) => {
Text(f)
.fontSize(12)
.fontColor(this.palette().textSecondary)
.width('100%')
.maxLines(1)
.textOverflow({ overflow: TextOverflow.Ellipsis })
.margin({ bottom: 4 })
}, (f: string) => f)
}
}
this.DetailActions()
}
/** 详情页状态行:同样去掉徽标,一个状态点 + 一行纯文字 */
@Builder
DetailBadges() {
Row({ space: 6 }) {
Circle({ width: 7, height: 7 })
.fill(this.activeStatusColor())
Text(this.detailStatusLine())
.fontSize(12)
.fontColor(this.palette().textSecondary)
.layoutWeight(1)
.maxLines(1)
.textOverflow({ overflow: TextOverflow.Ellipsis })
}
.width('100%')
.alignItems(VerticalAlign.Center)
}
private detailStatusLine(): string {
const parts: string[] = [];
parts.push(this.activeStatusText());
parts.push(this.activeIsBuiltin() ? '内置' : '外部');
if (this.detail.deprecated) {
parts.push('已废弃');
}
const n: number = this.activeTools().length;
if (n > 0) {
parts.push(n.toString() + ' 个工具');
}
return parts.join(' · ');
}
/** 工具清单来自一级列表已合并的 kernel.tools(按 plugin 归属) */
@Builder
DetailTools() {
if (this.activeTools().length > 0) {
PlainCard({ caption: '注册的工具 (' + this.activeTools().length.toString() + ')' }) {
Flex({ wrap: FlexWrap.Wrap }) {
ForEach(this.activeTools(), (tool: string) => {
Text(tool)
.fontSize(11)
.fontColor('#4A90D9')
.padding({ left: 8, right: 8, top: 3, bottom: 3 })
.borderRadius(RADIUS_SM)
.backgroundColor(this.palette().frostSoftBg)
.margin({ right: 5, bottom: 5 })
}, (tool: string) => tool)
}
}
}
}
@Builder
DetailActions() {
if (this.activeName.length > 0) {
PlainCard({ caption: '操作' }) {
Row() {
Button(this.activeIsDisabled() ? '启用' : '禁用')
.height(34)
.fontSize(12)
.backgroundColor(Color.Transparent)
.border({
width: 1,
color: this.activeIsDisabled()
? this.palette().btnGhostBorder : 'rgba(217, 154, 43, 0.5)',
})
.fontColor(this.activeIsDisabled()
? this.palette().textSecondary : '#D99A2B')
.animation({ duration: ANIM_FAST, curve: Curve.EaseOut })
.onClick(() => {
const r: PluginRow | null = this.activeRow();
if (r !== null) {
this.togglePlugin(r);
}
})
Blank()
if (!this.activeIsBuiltin()) {
Button('卸载')
.height(34)
.fontSize(12)
.backgroundColor(Color.Transparent)
.border({ width: 1, color: 'rgba(232, 64, 38, 0.45)' })
.fontColor(COLOR_ERROR)
.onClick(() => {
const r: PluginRow | null = this.activeRow();
if (r !== null) {
this.removePlugin(r);
}
})
.transition(TransitionEffect.OPACITY.animation({ duration: ANIM_FAST, curve: Curve.EaseOut }))
}
}
.width('100%')
}
}
}
// ---- 详情页取值助手:ArkTS 禁止非空断言,统一在这里做 null 收敛 ----
private hasManifest(): boolean {
return this.detail.author.length > 0 || this.detail.license.length > 0 ||
this.detail.homepage.length > 0 || this.detail.repository.length > 0 ||
this.detail.entry.length > 0 || this.detail.minVersion.length > 0;
}
private activeIsBuiltin(): boolean {
const r: PluginRow | null = this.activeRow();
return r !== null ? !r.external : false;
}
private activeIsDisabled(): boolean {
const r: PluginRow | null = this.activeRow();
return r !== null ? r.disabled : false;
}
private activeTools(): string[] {
const r: PluginRow | null = this.activeRow();
if (r === null) {
return [];
}
return r.tools ?? [];
}
private activeStatusText(): string {
const r: PluginRow | null = this.activeRow();
return r !== null ? this.statusBadgeText(r) : '未加载';
}
private activeStatusColor(): string {
const r: PluginRow | null = this.activeRow();
return r !== null ? this.statusBadgeColor(r) : this.palette().textMuted;
}
/** 明细行:值为空时整行不渲染,避免详情页出现一排 "-" */
@Builder
KvRow(label: string, value: string) {
if (value.length > 0) {
Row() {
Text(label)
.fontSize(13)
.fontColor(this.palette().textSecondary)
.layoutWeight(1)
Text(value)
.fontSize(13)
.fontColor(this.palette().textPrimary)
.textAlign(TextAlign.End)
.maxLines(2)
.textOverflow({ overflow: TextOverflow.Ellipsis })
.constraintSize({ maxWidth: 220 })
.margin({ left: 16 })
}
.width('100%')
.padding({ top: 8, bottom: 8 })
.alignItems(VerticalAlign.Top)
}
}
@Builder
Toast() {
if (this.toastMsg.length > 0) {
Row() {
Text(this.toastMsg)
.fontSize(13)
.fontColor(this.toastIsError ? this.palette().toastErrorText : this.palette().toastText)
.padding({ left: 20, right: 20, top: 10, bottom: 10 })
.borderRadius(RADIUS_MD)
.backgroundColor(this.toastIsError ? this.palette().toastErrorBg : this.palette().toastBg)
.border({
width: 1,
color: this.toastIsError ? 'rgba(232, 64, 38, 0.3)' : 'rgba(23, 169, 100, 0.3)',
})
}
.width('100%')
.justifyContent(FlexAlign.End)
.padding({ right: 20 })
.margin({ bottom: 166 })
.transition(TransitionEffect.OPACITY
.combine(TransitionEffect.translate({ y: 12 }))
.animation({ duration: ANIM_NORMAL, curve: Curve.EaseOut }))
}
}
/** 状态点颜色:绿=已加载,黄=待生效,红=已禁用,灰=未加载 */
private statusDotColor(plugin: PluginRow): string {
return this.statusBadgeColor(plugin);
}
/** 列表行副标题:状态 + 内置/外部 + 工具数,一行灰字,不用徽标 */
private rowSubtitle(plugin: PluginRow): string {
const parts: string[] = [];
parts.push(this.statusBadgeText(plugin));
parts.push(plugin.external ? '外部' : '内置');
if (plugin.tools !== undefined && plugin.tools.length > 0) {
parts.push(plugin.tools.length.toString() + ' 工具');
}
return parts.join(' · ');
}
private statusBadgeText(plugin: PluginRow): string {
const s: string = this.statusOf(plugin);
if (s === 'loaded') {
return '已加载';
}
if (s === 'pending') {
return '待生效';
}
if (s === 'disabled') {
return '已禁用';
}
return '未加载';
}
private statusBadgeColor(plugin: PluginRow): string {
const s: string = this.statusOf(plugin);
if (s === 'loaded') {
return '#17A964';
}
if (s === 'pending') {
return '#D99A2B';
}
if (s === 'disabled') {
return '#E84026';
}
return this.palette().textMuted;
}
} }

File diff suppressed because it is too large Load Diff

View File

@ -9,30 +9,56 @@ HarmonyOS / OpenHarmony 原生客户端,用 ArkTS + ArkUI 实现(不是 WebV
``` ```
HomeAgent/ HomeAgent/
├── AppScope/ 应用级配置与图标 ├── AppScope/ 应用级配置与图标
├── oh_modules/ 依赖(.gitignore 忽略,但**必须存在**,见下节)
├── entry/src/main/ ├── entry/src/main/
│ ├── ets/ │ ├── ets/
│ │ ├── common/ 通信与全局状态 │ │ ├── common/ 通信、状态与纯逻辑(无 UI)
│ │ │ ├── ApiClient.ets REST 客户端(X-API-Key 鉴权、超时、二进制附件) │ │ │ ├── ApiClient.ets REST 客户端(X-API-Key 鉴权、超时、二进制附件)
│ │ │ ├── SseClient.ets SSE 长连接(Last-Event-ID 断线续传) │ │ │ ├── SseClient.ets SSE 长连接(Last-Event-ID 断线续传)
│ │ │ ├── DeviceBridge.ets 设备桥:把本机能力暴露给 agent │ │ │ ├── ConnStore.ets 连接配置与设备身份持久化
│ │ │ ├── BridgeRouter.ets 桥请求路由 │ │ │ ├── StatusStore.ets 运行状态缓存(单例 + AppStorage 广播)
│ │ │ ├── BridgeCaps.ets 能力声明 │ │ │ ├── Constants.ets 主题色板、圆角、超时、分页大小
│ │ │ ├── ConnStore.ets 连接配置持久化 │ │ │ ├── UserError.ets 错误转人类可读文案
│ │ │ ├── StatusStore.ets 运行状态缓存 │ │ │ ├── NavBarController.ets / NavStackRegistry.ets 导航栏显隐与导航栈登记
│ │ │ ├── NavBarController.ets / NavStackRegistry.ets 导航 │ │ │ ├── ChatStore.ets 聊天状态机(消息数组/分页/SSE/防抖刷新,单例)
│ │ │ ├── Constants.ets 主题色板、圆角、超时、分页大小 │ │ │ ├── ChatSse.ets SSE 事件 → 状态翻译(ChatStreamSink 接口)
│ │ │ └── UserError.ets 错误转人类可读文案 │ │ │ ├── ChatSession.ets 发送/中断(POST /chat、/chat/file)
│ │ │ ├── ChatHistory.ets 历史载荷与 tool_calls 解析
│ │ │ ├── ChatFormat.ets ForEach 键、工具卡状态/配色、渠道判定
│ │ │ ├── AttachmentMeta.ets 附件解析与格式化(纯函数)
│ │ │ ├── AttachmentImage.ets 附件字节获取与解码(沙箱/远端)
│ │ │ ├── DeviceBridge.ets 设备桥客户端(socket 生命周期与命令分发)
│ │ │ ├── BridgeProtocol.ets 设备桥协议消息与帧构造
│ │ │ ├── BridgeRouter.ets 桥请求路由
│ │ │ ├── BridgeCaps.ets 能力声明
│ │ │ ├── DeviceBridgeSession.ets 前台桥生命周期、网关地址推导
│ │ │ ├── DeviceModel.ets 设备页纯逻辑(device_id 兜底、在线设备解析)
│ │ │ ├── PluginApi.ets 插件列表/详情接口
│ │ │ ├── PluginStatus.ets 插件状态判定与配色
│ │ │ ├── SettingsModel.ets 设置载荷解析、分类归并、分页、路由 id
│ │ │ └── MarkdownParser.ets Markdown 解析(块/行内/表格)
│ │ ├── components/ 可复用组件 │ │ ├── components/ 可复用组件
│ │ │ ├── MarkdownView.ets 流式 Markdown(增量渲染) │ │ │ ├── MarkdownView.ets 流式 Markdown(增量渲染)
│ │ │ ├── StaticMarkdown.ets 静态 Markdown(历史消息,一次成型) │ │ │ ├── StaticMarkdown.ets 静态 Markdown(历史消息,一次成型)
│ │ │ ├── Attachment.ets 附件卡片 + 详情 │ │ │ ├── Attachment.ets 附件卡 + 附件详情内容
│ │ │ ├── StatusCards.ets 状态卡片 │ │ │ ├── ChatStream.ets 消息列表 + 顶栏遮罩 + 底部淡出 + 触顶懒加载
│ │ │ ├── SettingsEditor.ets 配置编辑器 │ │ │ ├── ChatBubble.ets 单条气泡(头像/渠道名/思考卡/工具卡/附件/正文)
│ │ │ ├── PageTopBar.ets 顶栏 + 悬浮按钮 │ │ │ ├── ChatToolCard.ets 思考过程卡 + 工具调用卡
│ │ │ ├── SubPage.ets 二级页容器 │ │ │ ├── ChatComposer.ets 悬浮输入区(选图/选文件/上传/发送)
│ │ │ ├── ChatAttachBar.ets 加号菜单 + 待发送附件条
│ │ │ ├── SettingsHome.ets / SettingsRootEntries.ets / SettingsEntryCard.ets 设置一级页
│ │ │ ├── ConnectionsPane.ets / AppearancePane.ets / BackendSettingsPane.ets 设置二级页
│ │ │ ├── PluginListView.ets / PluginDetailPane.ets / PluginsOverlays.ets 插件页
│ │ │ ├── DeviceRootEntries.ets / DevicePanes.ets 设备页
│ │ │ ├── SettingsEditor.ets 配置编辑器
│ │ │ ├── StatusCards.ets 状态卡片
│ │ │ ├── ToastBar.ets 统一提示条(插件页与设置页共用)
│ │ │ ├── PageTopBar.ets 顶栏 + 悬浮按钮
│ │ │ ├── SubPage.ets 二级页容器 / NavGroup / NavRow / PlainCard
│ │ │ ├── MotionBase.ets 统一按压反馈与入场动画
│ │ │ └── GradientBackground.ets │ │ │ └── GradientBackground.ets
│ │ ├── model/Model.ets 共享类型定义 │ │ ├── model/Model.ets 共享类型定义
│ │ ├── pages/ 页面 │ │ ├── pages/ 页面(薄壳:导航 + 数据编排)
│ │ │ ├── Index.ets Tab 容器(入口) │ │ │ ├── Index.ets Tab 容器(入口)
│ │ │ ├── ChatPage.ets 对话 │ │ │ ├── ChatPage.ets 对话
│ │ │ ├── DevicePage.ets 设备 │ │ │ ├── DevicePage.ets 设备
@ -45,11 +71,30 @@ HomeAgent/
└── oh-package.json5 依赖 └── oh-package.json5 依赖
``` ```
约定:**单个 `.ets` 不超过 400 行**,页面只做页面壳(导航栈 + 数据编排),
可复用结构进 `components/`,无 UI 的逻辑进 `common/`。
这条约定有一个边界,别用反了:
> **不到 400 行的文件不要为了拆分而拆分。** `@Component` 的 `build()` 只允许一个根节点,
> 把原来多节点的 `@Builder` 改成组件时会多出一层 `Column` 包裹 —— 布局等价是**推理**出来的、
> 不是看出来的,每拆一次都要付一次"未上机验证"的账。所以拆分只用来解决真实的可读性/维护性
> 问题(超长文件、职责混杂),而不是凑行数。`pages/Index.ets` 目前 396 行就属于"不动"的一类:
> 没越线,余量本身也是有用的缓冲;等它真越线了再拆,并且优先看是不是又长出了大 `@Builder`。
## 编译 ## 编译
需要 DevEco Studio 或 [command-line-tools](https://developer.huawei.com/consumer/cn/deveco-studio/)。 需要 DevEco Studio 或 [command-line-tools](https://developer.huawei.com/consumer/cn/deveco-studio/)。
本工程用 `compatibleSdkVersion 6.1.1(24)` / `compileSdkVersion 26.0.0`。 本工程用 `compatibleSdkVersion 6.1.1(24)` / `compileSdkVersion 26.0.0`。
0. **前置条件:`oh_modules/` 必须存在**(`ohpm install` 的产物)。
它被 `.gitignore` 忽略,所以干净 clone 后没有;而 hvigor **不会**自动补齐它 ——
实测把 `oh_modules/` 移走后构建不会触发 `ohpm install`,而是直接报一堆
`arkts-no-untyped-obj-literals`(依赖类型声明缺失),且不会重建该目录。
所以:clone 后先 `ohpm install`,之后别把这个目录当垃圾清掉。
`entry/build/`、`.hvigor/` 是纯构建产物,可以随时删除(冷构建 ~8s)。
1. **准备签名配置**(`build-profile.json5` 含密码明文,未入库): 1. **准备签名配置**(`build-profile.json5` 含密码明文,未入库):
```bash ```bash
@ -64,19 +109,27 @@ HomeAgent/
2. **构建 HAP**: 2. **构建 HAP**:
```bash ```bash
# hvigorw 未入库(本机是符号链接),直接用 command-line-tools 里的 cd cmd/ohos/HomeAgent
/path/to/command-line-tools/bin/hvigorw \ # ⚠️ 不要用仓库里的 ./hvigorw:它是符号链接,启动脚本按 $(dirname $0) 定位,
--mode module -p module=entry@default assembleHap --no-daemon # 会报 File not found: <repo>/cmd/ohos/hvigor/bin/hvigorw。
# 一律用 command-line-tools 里的绝对路径(本机为 /opt/huawei/command-line-tools/bin/hvigorw):
/opt/huawei/command-line-tools/bin/hvigorw \
assembleHap --mode module -p product=default --no-daemon
``` ```
产物在 `entry/build/default/outputs/default/entry-default-signed.hap`。 产物在 `entry/build/default/outputs/default/entry-default-signed.hap`。
3. **安装到设备**: 3. **安装到设备**(`entry/build/` 是纯构建产物、不入库,所以**必须先跑完第 2 步**,
否则下面这个路径不存在):
```bash ```bash
hdc install entry/build/default/outputs/default/entry-default-signed.hap hdc install entry/build/default/outputs/default/entry-default-signed.hap
``` ```
路径里的目录名随构建模式而变:默认是 `default/`,若用 `-p product=<名字>` 则是该产品名。
拿不准就先 `find entry/build -name '*.hap'` 找一下。同目录还有 `entry-default-unsigned.hap`,
`hdc install` 要用带 `-signed` 的那个。
## 连接 homed ## 连接 homed
首次启动在「设置」里填: 首次启动在「设置」里填:
@ -97,3 +150,19 @@ HomeAgent/
- **修改主题色**:改 `common/Constants.ets` 的 `DARK_PALETTE` / `LIGHT_PALETTE`,全局生效。 - **修改主题色**:改 `common/Constants.ets` 的 `DARK_PALETTE` / `LIGHT_PALETTE`,全局生效。
- **新增页面**:同时在 `resources/base/profile/main_pages.json` 注册,且只有入口页带 `@Entry`。 - **新增页面**:同时在 `resources/base/profile/main_pages.json` 注册,且只有入口页带 `@Entry`。
- 项目代码部分由 AI 辅助生成,改动请自行评估。 - 项目代码部分由 AI 辅助生成,改动请自行评估。
## 改动后的运行时验证清单
构建通过只能证明编译期没问题;ArkUI 的状态绑定、过渡动画与手势行为
必须上设备/模拟器点一遍。UI 相关改动(尤其拆分、状态搬家)请至少走完:
- [ ] 发一条消息,确认流式输出、滚动到底、"AI 思考中/工具调用"状态条正常
- [ ] 点开思考过程卡与工具调用卡,确认能展开/收起且有过渡动画
- [ ] 传一张图片与一个文件,确认预览条、上传进度、发送后附件卡正常
- [ ] 进设置的四个二级页(状态/连接/外观/后端),确认进出场与保存生效
- [ ] 进插件列表与插件详情,确认状态色、开关与卸载正常
- [ ] 进出设备页四个二级页,确认授权开关与在线设备列表正常
- [ ] 宽屏(>=600vp)下确认左右分栏、返回手势与返回键行为
模拟器在无图形/无提权环境里可能起不来(需要写 `~/.Huawei` 等宿主目录),
此时请在真机或有权限的机器上补这轮验证,并在提交信息里注明"未做运行时验证"。

View File

@ -24,7 +24,7 @@ func handleBuiltin(cmd string, cfg *Config, state *State, reconnect func(), out
/conn use <name> switch to saved connection /conn use <name> switch to saved connection
/conn del <name> delete saved connection /conn del <name> delete saved connection
Server commands (sent to agent): Server commands (local 与 remote 行为一致):
/status system status /status system status
/kernel kernel status /kernel kernel status
/settings [prefix] list settings /settings [prefix] list settings
@ -32,10 +32,27 @@ Server commands (sent to agent):
/plugin list list installed plugins /plugin list list installed plugins
/plugin install <url> install plugin /plugin install <url> install plugin
/plugin remove <name> remove plugin /plugin remove <name> remove plugin
/plugin disable <name> disable plugin
/plugin enable <name> enable plugin
/plugin info <name> plugin details /plugin info <name> plugin details
/memory query <text> query graph memory /memory query <text> query graph memory
/knowledge list knowledge base /memory graph dump full graph memory snapshot
/memory text [n] recent text-memory events + stats
/memory context [q] assembled memory context (what gets injected)
/memory tools memory tool definitions + tool prompt
/knowledge list knowledge base (+stats)
/knowledge delete <name> delete knowledge item /knowledge delete <name> delete knowledge item
/config dump kernel config (JSON)
/tracker change-tracking stats
/tracker rollback roll back this session's file changes
/adapters list loaded Lua adapters
/adapters remove <name> remove a Lua adapter
/network network status + LLM endpoints
/runtime scheduler / residents / channel topology
/terminals list terminal sessions
/cmd/history command execution history
/terminal create|write|read|close … (local mode; calls agentcli tools)
/persona show persona (/persona set default|custom|later [text])
/agents list agents /agents list agents
/chat <text> send to agent /chat <text> send to agent
@ -54,6 +71,26 @@ Any other text is sent to the agent directly.`)
reconnect() reconnect()
return true return true
// /stop 与 /interrupt:取消当前生成(可附带一句新指令)。
// 之前 /help 里写着这条命令,但 handleBuiltin 根本没有对应 case,
// 于是它像普通文本一样被发给了 Agent。
// 本地交给 CLI 插件(内核优先级 L3),远端走 WebUI 的 chat/interrupt
// (内核优先级 L4)。两条路都是“真中断”,不是发一句话。
case cmd == "/stop" || cmd == "/interrupt" ||
strings.HasPrefix(cmd, "/stop ") || strings.HasPrefix(cmd, "/interrupt "):
msg := stopMessage(cmd)
if rc := state.RemoteConn(); rc != nil {
body := fmt.Sprintf(`{"message":%q}`, msg)
if _, err := rc.DoAPI("POST", "/api/v1/chat/interrupt", body); err != nil {
fmt.Fprintf(out, "interrupt failed: %v\n", err)
} else {
fmt.Fprintln(out, "interrupt sent")
}
} else {
state.Send(cmd)
}
return true
case strings.HasPrefix(cmd, "/connect "): case strings.HasPrefix(cmd, "/connect "):
cfg.Socket = strings.TrimSpace(cmd[9:]) cfg.Socket = strings.TrimSpace(cmd[9:])
cfg.Remote = "" cfg.Remote = ""
@ -143,7 +180,7 @@ Any other text is sent to the agent directly.`)
rc.DoAPI("PUT", "/api/v1/settings", body) rc.DoAPI("PUT", "/api/v1/settings", body)
fmt.Fprintln(out, "ok") fmt.Fprintln(out, "ok")
} else { } else {
state.Send(cmd[1:]) state.Send(cmd)
} }
return true return true
@ -152,7 +189,7 @@ Any other text is sent to the agent directly.`)
d, _ := rc.DoAPI("GET", "/api/v1/settings", "") d, _ := rc.DoAPI("GET", "/api/v1/settings", "")
printJSON(out, d) printJSON(out, d)
} else { } else {
state.Send(cmd[1:]) state.Send(cmd)
} }
return true return true
@ -172,7 +209,7 @@ Any other text is sent to the agent directly.`)
d, _ := rc.DoAPI("POST", "/api/v1/plugins", body) d, _ := rc.DoAPI("POST", "/api/v1/plugins", body)
printJSON(out, d) printJSON(out, d)
} else { } else {
state.Send(cmd[1:]) state.Send(cmd)
} }
return true return true
@ -182,7 +219,7 @@ Any other text is sent to the agent directly.`)
d, _ := rc.DoAPI("DELETE", "/api/v1/plugins/"+name, "") d, _ := rc.DoAPI("DELETE", "/api/v1/plugins/"+name, "")
printJSON(out, d) printJSON(out, d)
} else { } else {
state.Send(cmd[1:]) state.Send(cmd)
} }
return true return true
@ -192,17 +229,56 @@ Any other text is sent to the agent directly.`)
d, _ := rc.DoAPI("GET", "/api/v1/plugins/"+name, "") d, _ := rc.DoAPI("GET", "/api/v1/plugins/"+name, "")
printJSON(out, d) printJSON(out, d)
} else { } else {
state.Send(cmd[1:]) state.Send(cmd)
} }
return true return true
case strings.HasPrefix(cmd, "/memory query "): // disable/enable:本地由 CLI 插件处理,远端走插件管理 REST 动作接口。
q := strings.TrimSpace(cmd[14:]) case strings.HasPrefix(cmd, "/plugin disable ") || strings.HasPrefix(cmd, "/plugin enable "):
verb := "disable"
name := strings.TrimSpace(cmd[16:])
if strings.HasPrefix(cmd, "/plugin enable ") {
verb = "enable"
name = strings.TrimSpace(cmd[15:])
}
if name == "" {
fmt.Fprintln(out, "usage: /plugin disable|enable <name>")
return true
}
if rc := state.RemoteConn(); rc != nil { if rc := state.RemoteConn(); rc != nil {
d, _ := rc.DoAPI("GET", "/api/v1/memory?query="+q, "") d, _ := rc.DoAPI("POST", "/api/v1/plugins/"+name+"/"+verb, "")
printJSON(out, d) printJSON(out, d)
} else { } else {
state.Send(cmd[1:]) state.Send(cmd)
}
return true
case strings.HasPrefix(cmd, "/memory "):
sub := strings.TrimSpace(cmd[8:])
if rc := state.RemoteConn(); rc != nil {
switch {
case strings.HasPrefix(sub, "query "):
q := strings.TrimSpace(strings.TrimPrefix(sub, "query "))
d, _ := rc.DoAPI("GET", "/api/v1/memory?query="+q, "")
printJSON(out, d)
case sub == "graph":
d, _ := rc.DoAPI("GET", "/api/v1/memory/graph", "")
printJSON(out, d)
case sub == "text" || strings.HasPrefix(sub, "text "):
d, _ := rc.DoAPI("GET", "/api/v1/memory/text", "")
printJSON(out, d)
case sub == "context" || strings.HasPrefix(sub, "context "):
q := strings.TrimSpace(strings.TrimPrefix(sub, "context"))
d, _ := rc.DoAPI("GET", "/api/v1/memory/context?q="+q, "")
printJSON(out, d)
case sub == "tools":
d, _ := rc.DoAPI("GET", "/api/v1/memory/tools", "")
printJSON(out, d)
default:
fmt.Fprintln(out, "usage: /memory query <text> | /memory graph | /memory text [n] | /memory context [q] | /memory tools")
}
} else {
state.Send(cmd)
} }
return true return true
@ -212,16 +288,126 @@ Any other text is sent to the agent directly.`)
d, _ := rc.DoAPI("DELETE", "/api/v1/knowledge/"+name, "") d, _ := rc.DoAPI("DELETE", "/api/v1/knowledge/"+name, "")
printJSON(out, d) printJSON(out, d)
} else { } else {
state.Send(cmd[1:]) state.Send(cmd)
} }
return true return true
case cmd == "/knowledge": case cmd == "/knowledge" || cmd == "/knowledge list" || cmd == "/knowledge stats":
if rc := state.RemoteConn(); rc != nil { if rc := state.RemoteConn(); rc != nil {
d, _ := rc.DoAPI("GET", "/api/v1/knowledge", "") d, _ := rc.DoAPI("GET", "/api/v1/knowledge", "")
printJSON(out, d) printJSON(out, d)
} else { } else {
state.Send("/knowledge") state.Send(cmd)
}
return true
case cmd == "/config":
if rc := state.RemoteConn(); rc != nil {
d, _ := rc.DoAPI("GET", "/api/v1/config", "")
printJSON(out, d)
} else {
state.Send("/config")
}
return true
case cmd == "/tracker":
if rc := state.RemoteConn(); rc != nil {
d, _ := rc.DoAPI("GET", "/api/v1/tracker", "")
printJSON(out, d)
} else {
state.Send("/tracker")
}
return true
case cmd == "/tracker rollback":
if rc := state.RemoteConn(); rc != nil {
d, _ := rc.DoAPI("POST", "/api/v1/tracker/rollback", "")
printJSON(out, d)
} else {
state.Send("/tracker rollback")
}
return true
case cmd == "/adapters" || strings.HasPrefix(cmd, "/adapters remove "):
if rc := state.RemoteConn(); rc != nil {
if strings.HasPrefix(cmd, "/adapters remove ") {
name := strings.TrimSpace(cmd[17:])
d, _ := rc.DoAPI("DELETE", "/api/v1/adapters/"+name, "")
printJSON(out, d)
} else {
d, _ := rc.DoAPI("GET", "/api/v1/adapters", "")
printJSON(out, d)
}
} else {
state.Send(cmd)
}
return true
case cmd == "/persona" || strings.HasPrefix(cmd, "/persona set "):
if rc := state.RemoteConn(); rc != nil {
if strings.HasPrefix(cmd, "/persona set ") {
rest := strings.TrimSpace(cmd[13:])
mode := rest
content := ""
if idx := strings.IndexByte(rest, ' '); idx > 0 {
mode = rest[:idx]
content = strings.TrimSpace(rest[idx+1:])
}
body := fmt.Sprintf(`{"mode":%q,"content":%q}`, mode, content)
d, _ := rc.DoAPI("POST", "/api/v1/persona", body)
printJSON(out, d)
} else {
d, _ := rc.DoAPI("GET", "/api/v1/persona", "")
printJSON(out, d)
}
} else {
state.Send(cmd)
}
return true
case cmd == "/terminals":
if rc := state.RemoteConn(); rc != nil {
d, _ := rc.DoAPI("GET", "/api/v1/terminals", "")
printJSON(out, d)
} else {
state.Send("/terminals")
}
return true
case cmd == "/cmd/history":
if rc := state.RemoteConn(); rc != nil {
d, _ := rc.DoAPI("GET", "/api/v1/cmd/history", "")
printJSON(out, d)
} else {
state.Send("/cmd/history")
}
return true
case cmd == "/terminal" || strings.HasPrefix(cmd, "/terminal "):
if rc := state.RemoteConn(); rc != nil {
// 远端 WebUI 没有“开终端”的 REST 端点(终端由 agentcli 工具创建),
// 不静默当聊天发出去,直接说明。
fmt.Fprintln(out, "remote 模式暂不支持终端操作;请在 local 模式或让 agent 调 terminal_* 工具")
} else {
state.Send(cmd)
}
return true
case cmd == "/runtime":
if rc := state.RemoteConn(); rc != nil {
d, _ := rc.DoAPI("GET", "/api/v1/runtime", "")
printJSON(out, d)
} else {
state.Send("/runtime")
}
return true
case cmd == "/network":
if rc := state.RemoteConn(); rc != nil {
d, _ := rc.DoAPI("GET", "/api/v1/network", "")
printJSON(out, d)
} else {
state.Send("/network")
} }
return true return true
@ -239,6 +425,16 @@ Any other text is sent to the agent directly.`)
} }
} }
// stopMessage 从 /stop 或 /interrupt 行里取出可选的中断附带消息(空串=纯取消)。
func stopMessage(cmd string) string {
for _, prefix := range []string{"/interrupt", "/stop"} {
if strings.HasPrefix(cmd, prefix) {
return strings.TrimSpace(strings.TrimPrefix(cmd, prefix))
}
}
return ""
}
func printJSON(out io.Writer, d map[string]interface{}) { func printJSON(out io.Writer, d map[string]interface{}) {
if d == nil { if d == nil {
fmt.Fprintln(out, "(no data)") fmt.Fprintln(out, "(no data)")

View File

@ -0,0 +1,179 @@
package main
import (
"os"
"path/filepath"
"strings"
"testing"
)
// 设备命令白名单的配置化。
//
// ## 为什么要改
//
// 白名单原本是源码里硬编码的正则(cmd/waiter/device.go 的
// homeagentAllowCmd,18 个命令:ls/pwd/cat/df/...)。它的后果是:
// **无论怎么配 waiter.yaml 都跑不了 find / grep / sed / sort / tr**,
// 而这些正是排查问题最常用的只读命令。生产日志里的实际报错:
//
// device_ctl_cmdrun device_id:waiter-fnnas error: command not in whitelist
//
// 而 waiter.yaml 里当时只有 3 个键(device_gateway / device_token /
// device_authorized),**没有任何键能改这个白名单**。
//
// ## 改动
//
// 白名单从"编译期常量"变成"运行期配置":waiter.yaml 可加
// `device_cmd_allowlist:`(字符串数组,留空则用内置默认集)。
// 匹配函数本身是包级变量,由 main 从配置赋值 —— 与同文件既有的
// sendBridgeResult 同一模式(那里也是包级函数变量)。
//
// ## 为什么要留默认集
//
// 配置缺失/写错时**不能变成"全放行"**:那等于静默拆掉这道闸。
// 判定顺序是「配置非空 → 用配置;否则 → 用默认集」,任一分支都仍有闸。
// TestDefaultAllowlistStillBlocksDestructive 门禁:默认集必须挡住破坏性命令。
//
// 这是这道闸存在的**唯一理由**。若某天有人把默认集改成"什么都不拦",
// 这条判据必须失败。
func TestDefaultAllowlistStillBlocksDestructive(t *testing.T) {
// 明确危险的:写文件、删文件、改权限、任意解释器
for _, cmd := range []string{
"rm -rf /",
"dd if=/dev/zero of=/dev/sda",
"chmod -R 777 /",
"mkfs.ext4 /dev/sda1",
"shutdown now",
"reboot",
":(){ :|:& };:", // fork 炸弹
} {
if defaultCmdAllowed(cmd) {
t.Errorf("默认白名单放过了破坏性命令 %q —— 这道闸的唯一作用就是挡它", cmd)
}
}
// 常规运维命令应当放行
for _, cmd := range []string{"ls", "pwd", "uname -a", "df -h", "ps aux", "uptime"} {
if !defaultCmdAllowed(cmd) {
t.Errorf("默认白名单挡住了常规命令 %q —— 默认集被改窄了", cmd)
}
}
}
// TestConfigAllowlistExtends 判:配置可扩展只读分析命令。
func TestConfigAllowlistExtends(t *testing.T) {
// 场景:配置里加了 find/grep/sed/sort/tr
cfg := []string{"ls", "find", "grep", "sed", "sort", "tr"}
save := deviceCmdAllowed
defer func() { deviceCmdAllowed = save }()
deviceCmdAllowed = buildCmdMatcher(cfg)
for _, cmd := range []string{
"find . -name plugin.go", // 这次的核心诉求
"grep -rn authorized .",
"sed -n 1,20p file",
"sort -u list",
"tr a-z A-Z",
} {
if !cmdAllowed(cmd) {
t.Errorf("配置里已声明的命令仍被拒: %q", cmd)
}
}
// 配置里没写的仍应被拒(配置是"替换默认集"而非"追加")
if cmdAllowed("rm -rf /") {
t.Error("配置未包含 rm 却放行了 —— 配置必须替换而非叠加默认集")
}
}
// TestEmptyConfigFallsBackToDefault 判:配置缺失时回退默认集,且**不是**全放行。
func TestEmptyConfigFallsBackToDefault(t *testing.T) {
save := deviceCmdAllowed
defer func() { deviceCmdAllowed = save }()
deviceCmdAllowed = buildCmdMatcher(nil) // 配置为空
if !cmdAllowed("ls") {
t.Error("配置为空时连 ls 都不放行 —— 回退逻辑坏了")
}
if cmdAllowed("rm -rf /") {
t.Error("配置为空时放行了 rm -rf —— 空配置绝不能等于全放行")
}
}
// TestCmdAllowlistFromYAML 判:waiter.yaml 的 device_cmd_allowlist 真能读出来。
func TestCmdAllowlistFromYAML(t *testing.T) {
dir := t.TempDir()
path := filepath.Join(dir, "waiter.yaml")
body := "device_gateway: \"ws://127.0.0.1:9890/api/v1/device/ws\"\n" +
"device_authorized: true\n" +
"device_cmd_allowlist:\n - ls\n - find\n - grep\n"
if err := os.WriteFile(path, []byte(body), 0644); err != nil {
t.Fatal(err)
}
// 走**真实**加载路径(readFile),不另写一份解析 ——
// 两处会漂移,而漂移本身就是漏洞。
cfg := readFile(path)
if cfg == nil {
t.Fatalf("readFile 读不出配置: %s", path)
}
if len(cfg.DeviceCmdAllowlist) != 3 {
t.Fatalf("device_cmd_allowlist 解析出 %d 项,期望 3: %v",
len(cfg.DeviceCmdAllowlist), cfg.DeviceCmdAllowlist)
}
joined := strings.Join(cfg.DeviceCmdAllowlist, ",")
for _, want := range []string{"ls", "find", "grep"} {
if !strings.Contains(joined, want) {
t.Errorf("device_cmd_allowlist 缺 %q:%v", want, cfg.DeviceCmdAllowlist)
}
}
}
// TestDaemonPathAppliesAllowlist 守住「daemon 模式也必须应用配置」。
//
// ★ 这条判据来自一次真实的疏漏。
//
// waiter 有两条设备桥启动路径:
//
// · main.go 的 startDeviceBridge —— 交互/一次性模式
// · daemon.go 的 startDaemonDeviceBridge —— `waiter --daemon`(生产两台都这么跑)
//
// 我最初只在 main.go 里赋值 deviceCmdAllowed。daemon 路径不经过那里,
// 于是配置**完全不生效** —— 而症状是"配置写了、启动也打了招呼、命令照样被拒",
// 极难定位(看起来像配置没读到,其实是那条路径没接线)。
//
// startDaemonDeviceBridge 会起 goroutine 连网关,测试里不能真连;
// 所以这里验证它**读了** cfg.DeviceCmdAllowlist 并改了包级匹配函数:
// 先让它在缺网关地址时提前返回,确认那条路径的判据逻辑。
func TestDaemonPathAppliesAllowlist(t *testing.T) {
save := deviceCmdAllowed
defer func() { deviceCmdAllowed = save }()
// 先设成"拒绝一切",若 daemon 路径没有应用配置,它会保持不变
deviceCmdAllowed = func(string) bool { return false }
// 缺 device_gateway ⇒ 提前 return,不会走到白名单赋值。
// 这条断言锁住"提前返回"是有意为之(无网关就不该起桥)。
cfg := &Config{DeviceToken: "t"}
startDaemonDeviceBridge(cfg)
if cmdAllowed("find .") {
t.Error("无网关时 startDaemonDeviceBridge 不应改动白名单")
}
// ★ 关键:把网关路径走到赋值那一步。
// 真实函数会在 dg==""||dt=="" 时返回,所以这里必须给出网关地址;
// 而它随后会起 goroutine 连真实网关 —— 用一个不可达地址即可,
// goroutine 连不上会自行退出,不影响本断言。
cfg2 := &Config{
DeviceGateway: "ws://127.0.0.1:1/api/v1/device/ws", // 不可达
DeviceToken: "t",
DeviceCmdAllowlist: []string{"find", "grep"},
}
startDaemonDeviceBridge(cfg2)
// 赋值发生在 goroutine 之前 ⇒ 同步可见
if !cmdAllowed("find . -name x") {
t.Error("daemon 路径没有应用 waiter.yaml 的 device_cmd_allowlist —— " +
"配置在 `waiter --daemon` 下会完全不生效")
}
if cmdAllowed("rm -rf /") {
t.Error("daemon 路径应用配置后仍放行破坏性命令")
}
}

View File

@ -24,6 +24,17 @@ type Config struct {
DeviceGateway string `yaml:"device_gateway,omitempty"` // remotedevice 网关地址(如 127.0.0.1:9890) DeviceGateway string `yaml:"device_gateway,omitempty"` // remotedevice 网关地址(如 127.0.0.1:9890)
DeviceToken string `yaml:"device_token,omitempty"` // 设备接入 token DeviceToken string `yaml:"device_token,omitempty"` // 设备接入 token
DeviceAuthorized bool `yaml:"device_authorized,omitempty"` // 客户端本地授权(用户手动开启,服务端无法篡改) DeviceAuthorized bool `yaml:"device_authorized,omitempty"` // 客户端本地授权(用户手动开启,服务端无法篡改)
// DeviceCmdAllowlist 是设备桥**命令白名单**(可执行命令名的第一段)。
//
// 留空/缺省 ⇒ 用内置默认集(见 device.go 的 defaultCmdAllowlist)。
// ★ 不是"追加"而是"替换":写了就以它为准,避免"以为加了 find、
// 结果还留着 python3 -c 任意执行"这类误判。
//
// 为什么需要它:白名单原本是源码里硬编码的正则(18 个命令),
// 而 waiter.yaml 里没有任何键能改它 ⇒ find / grep / sed / sort / tr
// 这些排查问题最常用的**只读**命令一律被拒,实测报错:
// device_ctl_cmdrun device_id:waiter-fnnas error: command not in whitelist
DeviceCmdAllowlist []string `yaml:"device_cmd_allowlist,omitempty"`
} }
func (c *Config) Active() *Connection { func (c *Config) Active() *Connection {

View File

@ -304,6 +304,22 @@ func startDaemonDeviceBridge(cfg *Config) {
if dg == "" || dt == "" { if dg == "" || dt == "" {
return return
} }
// ★ 命令白名单必须在**这里**也赋值一次。
//
// 原因:daemon 模式(waiter --daemon,生产两台都这么跑)走的是本函数,
// 不经过 main.go 里那处赋值。只改 main.go 的话,配置在 daemon 下**完全不生效**
// —— 而症状是"配置写了、启动日志也打了招呼、命令照样被拒",极难定位。
//
// 赋值放在 goroutine 之前:白名单在收到第一帧命令时就要就绪。
if len(cfg.DeviceCmdAllowlist) > 0 {
deviceCmdAllowed = buildCmdMatcher(cfg.DeviceCmdAllowlist)
printlnC(colorGreen, fmt.Sprintf("device cmd allowlist: %d 条(来自 waiter.yaml)",
len(cfg.DeviceCmdAllowlist)))
} else {
printlnC(colorGreen, fmt.Sprintf("device cmd allowlist: 默认 %d 条(waiter.yaml 未配置 device_cmd_allowlist)",
len(defaultCmdAllowlist)))
}
// 设备桥重连循环:WS 断开时自动重连,并保留配置中的本地授权状态。 // 设备桥重连循环:WS 断开时自动重连,并保留配置中的本地授权状态。
go runDeviceBridgeLoop(dg, dt, cfg.DeviceAuthorized) go runDeviceBridgeLoop(dg, dt, cfg.DeviceAuthorized)
} }

View File

@ -15,6 +15,7 @@ import (
"time" "time"
"gitcode.com/JianFeeeee/HomeAgent/internal/devicebridge/client" "gitcode.com/JianFeeeee/HomeAgent/internal/devicebridge/client"
"gitcode.com/JianFeeeee/HomeAgent/internal/meta"
) )
// ===== 设备桥管理 ===== // ===== 设备桥管理 =====
@ -46,17 +47,13 @@ func startDeviceBridge(addr, token string) error {
"platform": runtime.GOOS, "platform": runtime.GOOS,
"arch": runtime.GOARCH, "arch": runtime.GOARCH,
"cpus": runtime.NumCPU(), "cpus": runtime.NumCPU(),
// 客户端版本与内核同源(internal/meta),deviceinfo 回显的软件版本
// 因此与 homed 一致,不再是一个空缺字段。
"version": meta.Version,
} }
// 确保 gateway URL 格式正确 // 网关地址规范化(含「已是完整端点」「只有 host:port」两种旧输入形态)。
gateway := addr gateway := normalizeGateway(addr)
if !strings.HasPrefix(gateway, "ws://") && !strings.HasPrefix(gateway, "wss://") {
gateway = "ws://" + gateway
// 默认 remotedevice WS 路径
if !strings.Contains(gateway, "/api/v1/device/ws") {
gateway = gateway + "/api/v1/device/ws"
}
}
bridge := client.New(gateway, token, deviceID, "HomeAgent CLI", caps, info) bridge := client.New(gateway, token, deviceID, "HomeAgent CLI", caps, info)
cmdRouter = client.NewCmdRouter() cmdRouter = client.NewCmdRouter()
@ -96,10 +93,59 @@ func stopDeviceBridge() {
// ===== 命令分发 ===== // ===== 命令分发 =====
// homeagent 能力白名单命令(与 remotedevice 插件对齐) // defaultCmdAllowlist 是**内置默认**命令白名单(命令名的第一段)。
var homeagentAllowCmd = regexp.MustCompile( //
"^(ls|pwd|whoami|uname|date|echo|uptime|hostname|cat|df|free|ps|ip|dir|node|python3?|npm|git|curl|wget|systeminfo|tasklist)\\b", // 只收「只读/低风险」的诊断类命令。这道闸的唯一作用是挡住
) // rm -rf /、dd、chmod 777、fork 炸弹这类破坏性命令 —— 而触发它的是
// **agent**(经 device_ctl_cmdrun),不是人,所以需要一道机器闸。
var defaultCmdAllowlist = []string{
"ls", "pwd", "whoami", "uname", "date", "echo", "uptime", "hostname",
"cat", "df", "free", "ps", "ip", "dir", "node", "python3", "python",
"npm", "git", "curl", "wget", "systeminfo", "tasklist",
}
// buildCmdMatcher 由命令名列表构造匹配函数。
//
// 只取**命令名的第一段**再整词匹配:这样 "grep -rn x ." 能过,
// 而 "grepXxx" / "mygrep" 不会因为 contains 而蒙混过关。
// 空列表 ⇒ 回退默认集(★ 绝不能变成"全放行")。
func buildCmdMatcher(cmds []string) func(string) bool {
if len(cmds) == 0 {
cmds = defaultCmdAllowlist
}
set := make(map[string]bool, len(cmds))
for _, c := range cmds {
if c = strings.TrimSpace(c); c != "" {
set[c] = true
}
}
return func(command string) bool {
fields := strings.Fields(strings.TrimSpace(command))
if len(fields) == 0 {
return false
}
// 跳过 VAR=value 前缀(`FOO=bar cmd` 这种合法写法)
i := 0
for i < len(fields) && strings.Contains(fields[i], "=") &&
!strings.HasPrefix(fields[i], "-") {
i++
}
if i >= len(fields) {
return false
}
return set[filepath.Base(fields[i])]
}
}
// deviceCmdAllowed 是当前生效的命令白名单匹配函数。
//
// 包级变量 + 由 main 从配置赋值,与同文件既有的 sendBridgeResult 同一模式
// (那里也是包级函数变量,测试可替换)。
var deviceCmdAllowed = buildCmdMatcher(nil)
// cmdAllowed / defaultCmdAllowed 是两个测试可读的入口。
func cmdAllowed(command string) bool { return deviceCmdAllowed(command) }
func defaultCmdAllowed(command string) bool { return buildCmdMatcher(nil)(command) }
func handleShellCmd(reqID, command string) { func handleShellCmd(reqID, command string) {
cmd := strings.TrimSpace(command) cmd := strings.TrimSpace(command)
@ -107,7 +153,7 @@ func handleShellCmd(reqID, command string) {
sendBridgeResult(reqID, "error", "", "empty command") sendBridgeResult(reqID, "error", "", "empty command")
return return
} }
if !homeagentAllowCmd.MatchString(cmd) { if !cmdAllowed(cmd) {
sendBridgeResult(reqID, "error", "", "command not in whitelist") sendBridgeResult(reqID, "error", "", "command not in whitelist")
return return
} }

View File

@ -0,0 +1,134 @@
package main
import (
"encoding/json"
"fmt"
"io"
"net/http"
"strings"
"time"
)
// discoveryPath 是 HomeAgent 的「设备网关在哪」端点(相对门户根)。
const discoveryPath = "/api/v1/device/gateway"
// discoveryResponse 是发现端点的响应。
type discoveryResponse struct {
Available bool `json:"available"`
// URL 是**子域形态**(devices.<基域名>)。浏览器能解析(RFC 6761 内置
// 特例),但系统解析器(getent/Go/Node)通常解析不到 *.localhost —— 实测如此。
URL string `json:"url"`
// URLPortal 是**门户同源形态**(同一 host、同一端口,走路径挂载),
// 无任何 DNS 依赖。非浏览器客户端应当用这个。
URLPortal string `json:"url_portal"`
Preferred string `json:"preferred"`
Host string `json:"host"` // devices.<基域名>
Auth string `json:"auth"` // homeagent | none
Reason string `json:"reason"` // available=false 时的原因
Hint string `json:"hint"`
}
// normalizeGateway 把用户给的地址整理成可直接连接的 WebSocket URL。
//
// 保留两种输入形态的旧行为:
// - 已含路径(含 /api/v1/device/ws)→ 原样使用;
// - 只有 host[:port] → 补 ws:// 与默认 WS 路径。
//
// 新增:**已带子域标签的地址不再被改写**(例如 devices.example.com)——
// 旧实现只判断"是否含路径",对子域地址是对的;这里把这条显式化,
// 避免以后有人加"自动补门户路径"的逻辑时把它改坏。
func normalizeGateway(addr string) string {
g := strings.TrimSpace(addr)
if g == "" {
return ""
}
if strings.HasPrefix(g, "ws://") || strings.HasPrefix(g, "wss://") {
if strings.Contains(g, "/api/v1/device/ws") {
return g
}
return strings.TrimRight(g, "/") + "/api/v1/device/ws"
}
// http(s):// 形态:转成 ws(s)://,其余同下
if strings.HasPrefix(g, "https://") {
g = "wss://" + strings.TrimPrefix(g, "https://")
} else if strings.HasPrefix(g, "http://") {
g = "ws://" + strings.TrimPrefix(g, "http://")
} else {
g = "ws://" + g
}
if strings.Contains(g, "/api/v1/device/ws") {
return g
}
return strings.TrimRight(g, "/") + "/api/v1/device/ws"
}
// discoverGateway 向门户询问设备网关的**权威地址**。
//
// 为什么需要:设备网关现在位于 devices.<基域名> 的子域反代上,而基域名与
// 子域标签都是**服务端配置**(webui.base_domain / 插件声明),客户端无从得知。
// 让服务端回答「网关在哪」是唯一不会漂移的做法。
//
// portalURL 是用户配置的门户地址(可能带路径/尾斜杠);token 是门户 api_key。
// 任何失败都返回错误,由调用方决定是否回退到自配地址 —— 发现是**增强**而非
// 必需,老版本 HomeAgent 没有这个端点。
func discoverGateway(portalURL, token string, timeout time.Duration) (string, error) {
base := strings.TrimSpace(portalURL)
if base == "" {
return "", fmt.Errorf("门户地址为空")
}
// http(s) → 对应的门户根;ws(s) 输入也要能问(GUI 里同一字段混用两种形态)
switch {
case strings.HasPrefix(base, "wss://"):
base = "https://" + strings.TrimPrefix(base, "wss://")
case strings.HasPrefix(base, "ws://"):
base = "http://" + strings.TrimPrefix(base, "ws://")
case !strings.HasPrefix(base, "http://") && !strings.HasPrefix(base, "https://"):
base = "http://" + base
}
// 用户可能填的是完整网关地址(含 /api/v1/device/ws):截到根再拼发现路径
if i := strings.Index(base, "/api/v1/"); i >= 0 {
base = base[:i]
}
base = strings.TrimRight(base, "/")
if timeout <= 0 {
timeout = 5 * time.Second
}
client := &http.Client{Timeout: timeout}
req, err := http.NewRequest(http.MethodGet, base+discoveryPath, nil)
if err != nil {
return "", err
}
if token != "" {
req.Header.Set("X-API-Key", token)
}
resp, err := client.Do(req)
if err != nil {
return "", err
}
defer resp.Body.Close()
body, _ := io.ReadAll(io.LimitReader(resp.Body, 64<<10))
if resp.StatusCode != http.StatusOK {
return "", fmt.Errorf("发现端点返回 %d:%s", resp.StatusCode, strings.TrimSpace(string(body)))
}
var d discoveryResponse
if err := json.Unmarshal(body, &d); err != nil {
return "", fmt.Errorf("发现响应无法解析: %w", err)
}
if !d.Available {
msg := d.Reason
if msg == "" {
msg = "服务端报告设备网关不可用"
}
return "", fmt.Errorf("%s", msg)
}
// 优先门户同源形态:waiter 是普通进程,走系统解析器,
// 而 *.localhost 在系统解析器下通常解析不到(只有浏览器内置该特例)。
if p := strings.TrimSpace(d.URLPortal); p != "" {
return p, nil
}
if p := strings.TrimSpace(d.URL); p != "" {
return p, nil
}
return "", fmt.Errorf("服务端未给出可用的网关地址")
}

View File

@ -0,0 +1,151 @@
package main
import (
"encoding/json"
"net/http"
"net/http/httptest"
"testing"
"time"
)
func TestNormalizeGateway(t *testing.T) {
cases := map[string]string{
// 已是完整端点:原样
"ws://devices.localhost:8080/api/v1/device/ws": "ws://devices.localhost:8080/api/v1/device/ws",
"wss://devices.example.com/api/v1/device/ws": "wss://devices.example.com/api/v1/device/ws",
// 只有 ws 根:补路径
"ws://127.0.0.1:9890": "ws://127.0.0.1:9890/api/v1/device/ws",
"ws://devices.example.com/": "ws://devices.example.com/api/v1/device/ws",
// 裸 host:port:补 scheme + 路径(旧行为)
"127.0.0.1:9890": "ws://127.0.0.1:9890/api/v1/device/ws",
"devices.example.com:8080": "ws://devices.example.com:8080/api/v1/device/ws",
// http(s) → ws(s)
"http://127.0.0.1:9890": "ws://127.0.0.1:9890/api/v1/device/ws",
"https://devices.example.com": "wss://devices.example.com/api/v1/device/ws",
// ★ 子域地址不得被改写(这正是改造后的正确形态)
"devices.example.com": "ws://devices.example.com/api/v1/device/ws",
// 空
"": "",
" ": "",
}
for in, want := range cases {
if got := normalizeGateway(in); got != want {
t.Errorf("normalizeGateway(%q) = %q,期望 %q", in, got, want)
}
}
}
// 发现端点返回权威地址时,必须采用它(而不是自己拼门户同源地址)。
func TestDiscoverGatewayUsesServerAnswer(t *testing.T) {
var gotPath, gotKey string
srv := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
gotPath = r.URL.Path
gotKey = r.Header.Get("X-API-Key")
json.NewEncoder(w).Encode(map[string]interface{}{
"available": true,
"url": "ws://devices.localhost:8080/api/v1/device/ws",
"url_portal": "ws://127.0.0.1:8080/api/v1/device/ws",
"auth": "none",
})
}))
defer srv.Close()
url, err := discoverGateway(srv.URL, "PORTAL-KEY", 3*time.Second)
if err != nil {
t.Fatal(err)
}
// ★ 必须优先门户同源形态:waiter 走系统解析器,*.localhost 解析不到
if url != "ws://127.0.0.1:8080/api/v1/device/ws" {
t.Errorf("未优先采用门户同源形态: %q", url)
}
if gotPath != "/api/v1/device/gateway" {
t.Errorf("发现路径不对: %q", gotPath)
}
if gotKey != "PORTAL-KEY" {
t.Errorf("未带门户凭证: %q", gotKey)
}
}
// 用户填的是完整网关地址时,也要能正确截到门户根再问。
func TestDiscoverGatewayFromFullEndpointInput(t *testing.T) {
var gotPath string
srv := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
gotPath = r.URL.Path
json.NewEncoder(w).Encode(map[string]interface{}{
"available": true, "url": "ws://devices.localhost/api/v1/device/ws",
})
}))
defer srv.Close()
// 输入形态:完整旧端点(含 /api/v1/device/ws)与 ws:// 前缀
for _, in := range []string{
srv.URL + "/api/v1/device/ws",
"ws://" + srv.Listener.Addr().String() + "/api/v1/device/ws",
} {
gotPath = ""
if _, err := discoverGateway(in, "k", 3*time.Second); err != nil {
t.Errorf("输入 %q 应成功: %v", in, err)
continue
}
if gotPath != "/api/v1/device/gateway" {
t.Errorf("输入 %q 未截到门户根,实际路径 %q", in, gotPath)
}
}
}
// 服务端明确报告不可用 → 必须返回错误(调用方据此回退),而不是给个连不上的 URL。
func TestDiscoverGatewayUnavailableReportsError(t *testing.T) {
srv := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
json.NewEncoder(w).Encode(map[string]interface{}{
"available": false,
"reason": "本实例没有声明设备网关反代",
})
}))
defer srv.Close()
if _, err := discoverGateway(srv.URL, "k", 3*time.Second); err == nil {
t.Error("服务端报告不可用时应返回错误")
}
}
// 老版本 HomeAgent 没有该端点(404)→ 返回错误而不是 panic/空成功。
func TestDiscoverGatewayOldServerFallsBack(t *testing.T) {
srv := httptest.NewServer(http.NotFoundHandler())
defer srv.Close()
if _, err := discoverGateway(srv.URL, "k", 3*time.Second); err == nil {
t.Error("404 应返回错误,让调用方回退到自配地址")
}
// 空地址快速失败
if _, err := discoverGateway("", "k", 3*time.Second); err == nil {
t.Error("空门户地址应返回错误")
}
}
// 老版本只给 url(无 url_portal)时,仍必须能用 —— 退回子域形态。
func TestDiscoverGatewayFallsBackToSubdomainForm(t *testing.T) {
srv := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
json.NewEncoder(w).Encode(map[string]interface{}{
"available": true,
"url": "ws://devices.example.com/api/v1/device/ws",
})
}))
defer srv.Close()
got, err := discoverGateway(srv.URL, "k", 3*time.Second)
if err != nil {
t.Fatal(err)
}
if got != "ws://devices.example.com/api/v1/device/ws" {
t.Errorf("无 url_portal 时应退回 url,实际 %q", got)
}
}
// 两者都没有 → 明确报错,而不是返回空串让调用方拿着空地址去连。
func TestDiscoverGatewayNoURLReportsError(t *testing.T) {
srv := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
json.NewEncoder(w).Encode(map[string]interface{}{"available": true})
}))
defer srv.Close()
if _, err := discoverGateway(srv.URL, "k", 3*time.Second); err == nil {
t.Error("两个形态都缺时应报错")
}
}

View File

@ -11,6 +11,8 @@ import (
"sync" "sync"
"syscall" "syscall"
"time" "time"
"gitcode.com/JianFeeeee/HomeAgent/internal/meta"
) )
const ( const (
@ -129,8 +131,15 @@ func main() {
daemonMode := flag.Bool("daemon", false, "后台驻留模式:维持 homed 连接 + 设备桥,等待 TUI 实例接入") daemonMode := flag.Bool("daemon", false, "后台驻留模式:维持 homed 连接 + 设备桥,等待 TUI 实例接入")
testCap := flag.String("test-cap", "", "测试本地能力(screensue/speakeruse/screensee/clipboardsee/clipboardsue/computeruse/camerasue),如 --test-cap screensue") testCap := flag.String("test-cap", "", "测试本地能力(screensue/speakeruse/screensee/clipboardsee/clipboardsue/computeruse/camerasue),如 --test-cap screensue")
testCapArgs := flag.String("test-cap-args", "", "测试能力的参数") testCapArgs := flag.String("test-cap-args", "", "测试能力的参数")
showVersion := flag.Bool("version", false, "打印版本并退出")
flag.Parse() flag.Parse()
// 版本号直接来自 internal/meta(与 homed 同一事实源,不可能各写一个)。
if *showVersion {
fmt.Printf("waiter %s (commit %s, built %s)\n", meta.Version, meta.Commit, meta.BuildTime)
return
}
// 本地能力测试模式(无需连接服务器) // 本地能力测试模式(无需连接服务器)
if *testCap != "" { if *testCap != "" {
runCapTest(*testCap, *testCapArgs) runCapTest(*testCap, *testCapArgs)
@ -172,10 +181,34 @@ func main() {
if dt == "" { if dt == "" {
dt = cfg.DeviceToken dt = cfg.DeviceToken
} }
// 网关地址优先向门户**发现**(服务端才知道子域标签与基域名),
// 失败再回退到用户配置 —— 老版本 HomeAgent 没有发现端点。
// 只在用户已配置门户地址时尝试:没配门户就没有可问的对象。
if portal := cfg.Remote; portal != "" {
if discovered, err := discoverGateway(portal, cfg.APIKey, 5*time.Second); err == nil {
printlnC(colorGreen, "device gateway discovered: "+discovered)
dg = discovered
} else if dg == "" {
printlnC(colorYellow, "device gateway discovery failed: "+err.Error())
}
}
if dg != "" && dt != "" { if dg != "" && dt != "" {
if err := startDeviceBridge(dg, dt); err != nil { if err := startDeviceBridge(dg, dt); err != nil {
printlnC(colorYellow, fmt.Sprintf("device bridge: %v (continue without)", err)) printlnC(colorYellow, fmt.Sprintf("device bridge: %v (continue without)", err))
} else { } else {
// 命令白名单:waiter.yaml device_cmd_allowlist,留空用内置默认集。
//
// ★ 在 startDeviceBridge **之后**赋值:白名单只在收到命令时才用,
// 放在这里能保证它一定在第一帧命令到达前就绪。
if len(cfg.DeviceCmdAllowlist) > 0 {
deviceCmdAllowed = buildCmdMatcher(cfg.DeviceCmdAllowlist)
printlnC(colorGreen, fmt.Sprintf("device cmd allowlist: %d 条(来自 waiter.yaml)",
len(cfg.DeviceCmdAllowlist)))
} else {
printlnC(colorGreen, fmt.Sprintf("device cmd allowlist: 默认 %d 条(waiter.yaml 未配置 device_cmd_allowlist)",
len(defaultCmdAllowlist)))
}
// 客户端本地授权:命令行 --device-authorized 或 waiter.yaml device_authorized // 客户端本地授权:命令行 --device-authorized 或 waiter.yaml device_authorized
auth := *deviceAuthorized || cfg.DeviceAuthorized auth := *deviceAuthorized || cfg.DeviceAuthorized
deviceBridge.SetAuthorized(auth) deviceBridge.SetAuthorized(auth)
@ -185,6 +218,18 @@ func main() {
} }
if oneShotMsg != "" { if oneShotMsg != "" {
// ★ -chat 是一次性问答,会立刻走到上面的 return 并触发
// defer stopDeviceBridge(),桥的生命周期只有几百毫秒。
//
// 后果:设备来不及完成 hello→bind 登记就已断开,服务端列表里永远
// 看不到它(实测:`device bridge active` 打印了、bind_ack 也收到了,
// 但 /api/v1/device/online 始终为空)。
// 这不是桥的错 —— 用裸客户端把 hello/bind 发完并保持连接,同一实例
// 上设备立刻出现在列表里(已验证)。
//
// 等待 bind 确认(或短暂超时)再退出:既让登记完成,也不把一次性
// 命令拖长。bind 失败要明说,而不是静默丢掉设备。
waitDeviceBind(3 * time.Second)
oneshot(state, oneShotMsg) oneshot(state, oneShotMsg)
return return
} }
@ -270,9 +315,9 @@ func runLineMode(state *State, cfg *Config, history *History) {
addrLabel = cfg.Remote addrLabel = cfg.Remote
} }
if colors { if colors {
fmt.Printf("%sHomeAgent CLI%s %s(%s://%s)%s\n", colorBold, colorReset, colorDim, modeLabel, addrLabel, colorReset) fmt.Printf("%sHomeAgent CLI%s %s%s (%s://%s)%s\n", colorBold, colorReset, colorDim, "v"+meta.Version, modeLabel, addrLabel, colorReset)
} else { } else {
fmt.Printf("HomeAgent CLI (%s://%s)\n", modeLabel, addrLabel) fmt.Printf("HomeAgent CLI v%s (%s://%s)\n", meta.Version, modeLabel, addrLabel)
} }
fmt.Println("Type /help for commands.") fmt.Println("Type /help for commands.")
@ -479,3 +524,26 @@ func printServerEventColored(rl respLine, raw string) {
fmt.Printf("%s%s%s\n", clearLine, text, colorReset) fmt.Printf("%s%s%s\n", clearLine, text, colorReset)
} }
} }
// waitDeviceBind 等待服务端确认 bind(最多 timeout),返回是否确认。
//
// 用于一次性命令(-chat):桥启动后立刻退出会让设备来不及登记。
// 超时不报错(服务端可能只是慢),bind 明确被拒则打出来 —— 那通常意味着
// 设备令牌不对或设备未授权,用户需要知道,而不是以为「桥起来了就好了」。
func waitDeviceBind(timeout time.Duration) bool {
if deviceBridge == nil {
return false
}
deadline := time.Now().Add(timeout)
for time.Now().Before(deadline) {
if deviceBridge.Bound() {
return true
}
if reason := deviceBridge.BindError(); reason != "" {
printlnC(colorYellow, "device bridge bind rejected: "+reason)
return false
}
time.Sleep(50 * time.Millisecond)
}
return deviceBridge.Bound()
}

125
csrc/CMakeLists.txt Normal file
View File

@ -0,0 +1,125 @@
cmake_minimum_required(VERSION 3.10)
project(ha_codec VERSION 0.1.0 LANGUAGES C)
# ============================================================
# ha_codec — HomeAgent 内核编解码层(C 实现)
#
# 零外部依赖,纯 C99。产出静态库供 homed 经 cgo 链接,
# 同时可独立用于其他端(鸿蒙 / 嵌入式 / C SDK)。
#
# 使用方式:
# add_subdirectory(path/to/csrc)
# target_link_libraries(my_app ha_codec)
# target_include_directories(my_app PRIVATE ${HA_CODEC_INCLUDE_DIR})
# ============================================================
option(BUILD_SHARED_LIBS "Build ha_codec as shared library" OFF)
option(BUILD_TESTS "Build ha_codec tests" OFF)
option(BUILD_FUZZ "Build libFuzzer targets" OFF)
option(BUILD_BENCH "Build micro benchmarks" OFF)
# ★ C99 而非编译器默认档(clang 默认 gnu17)。
# 理由:内核 C 侧的编译契约是 C99(cgo CFLAGS 与这里必须一致),
# 在更新的默认档下编译会**静默**通过,而 Go 侧用 -std=c99 编不过
# —— 两边同时构建、行为却分叉,是最难查的一类问题。
# 实测:本轮 -Wpedantic 门禁就当场抓到过 C11 特性(_Static_assert)。
# C90/C95 不支持:ha_abi.h 用了 // 注释与 stdint。
# C11 开关保留给想验证「未来切到 C11 也不坏」的人。
set(CMAKE_C_STANDARD 99)
set(CMAKE_C_STANDARD_REQUIRED ON)
set(CMAKE_C_EXTENSIONS OFF) # 禁用 gnu99 扩展,严格 -std=c99
set(HA_CODEC_SRC
src/ha_codec.c
src/ha_json_scan.c
)
if(BUILD_SHARED_LIBS)
add_library(ha_codec SHARED ${HA_CODEC_SRC})
if(WIN32)
set_target_properties(ha_codec PROPERTIES WINDOWS_EXPORT_ALL_SYMBOLS ON)
endif()
else()
add_library(ha_codec STATIC ${HA_CODEC_SRC})
endif()
set(HA_CODEC_INCLUDE ${CMAKE_CURRENT_SOURCE_DIR}/include)
target_include_directories(ha_codec PUBLIC ${HA_CODEC_INCLUDE})
# 告警门禁:零告警才允许通过(与 Makefile 的 csrc-lint 同一标准)。
# C 侧没有 Go 的 vet 等价物,告警是唯一的静态信号。
if(CMAKE_C_COMPILER_ID MATCHES "GNU|Clang")
add_compile_options(-Wall -Wextra -Wpedantic -Wshadow -Wconversion)
endif()
# 不链接任何外部库 —— 保持与 ha_remotedevice 同一克制标准
target_link_libraries(ha_codec PRIVATE)
set(HA_CODEC_INCLUDE_DIR ${HA_CODEC_INCLUDE} CACHE INTERNAL "ha_codec include directories")
install(TARGETS ha_codec
EXPORT ha_codec-targets
LIBRARY DESTINATION lib
ARCHIVE DESTINATION lib
RUNTIME DESTINATION bin
INCLUDES DESTINATION include
)
install(DIRECTORY include/ DESTINATION include)
# ============================================================
# 测试
# ============================================================
if(BUILD_TESTS)
add_executable(ha_codec_test test/test_ha_codec.c)
target_link_libraries(ha_codec_test PRIVATE ha_codec)
add_executable(ha_json_scan_test test/test_ha_json_scan.c)
target_link_libraries(ha_json_scan_test PRIVATE ha_codec)
enable_testing()
add_test(NAME ha_codec_test COMMAND ha_codec_test)
add_test(NAME ha_json_scan_test COMMAND ha_json_scan_test)
endif()
# ============================================================
# 模糊测试:编码语义与内存安全的持续检验
#
# 动机:ha_codec 声称**逐值等价于 Go 参考实现**,其中最关键的一条是
# 「对畸形 UTF-8 的解码边界与 Go 的 utf8.DecodeRuneInString 一致」。
# 该行为在正常输入下永远测不到 —— 只有随机字节才能覆盖
# 截断序列 / 过长编码 / 代理对 / 超 U+10FFFF / 嵌入 NUL。
# Go 侧已有 TestGolden_InvalidUTF8(3000 组随机字节)做等价钉死;
# C 侧则需要独立验证两件事:
# 1. 任何输入都不崩、不越界(内存安全)
# 2. 返回值不违反头文件声明的不变式(0 <= keep <= len 等)
# 两者在 libFuzzer 上是持续的,而不是等下一次手写用例。
#
# 需 clang + -fsanitize=fuzzer;无则明确跳过(门禁不能假装通过)。
# ============================================================
if(BUILD_FUZZ)
if(CMAKE_C_COMPILER_ID MATCHES "Clang")
foreach(fz IN ITEMS test_fuzz_ha_codec test_fuzz_ha_json_scan)
add_executable(${fz} test/${fz}.c)
target_link_libraries(${fz} PRIVATE ha_codec)
target_compile_options(${fz} PRIVATE
-fsanitize=fuzzer,address,undefined
-fno-omit-frame-pointer)
target_link_options(${fz} PRIVATE
-fsanitize=fuzzer,address,undefined)
endforeach()
else()
message(WARNING
"BUILD_FUZZ=ON 需要 clang(libFuzzer);当前编译器是 "
"${CMAKE_C_COMPILER_ID},已跳过。")
endif()
endif()
# ============================================================
# 微基准:C 侧自身的开销(与 Go 侧 codec_bench_test.go 对照)
#
# 为什么 C 侧也要基准:Go 侧基准里,「C 实现省下的时间」与「cgo 边界成本」
# 是混在一起的。若 C 侧本身在某场景很慢,改 Go 绑定无济于事;
# 必须在能隔离处(纯 C、无边界)测出函数体成本,才知道该优化谁。
# ============================================================
if(BUILD_BENCH)
add_executable(ha_codec_bench bench/bench_ha_codec.c)
target_link_libraries(ha_codec_bench PRIVATE ha_codec)
endif()

175
csrc/bench/bench_ha_codec.c Normal file
View File

@ -0,0 +1,175 @@
/*
* bench_ha_codec.c —— C 侧纯函数微基准(无 cgo 边界成本)
*
* ============================ 为什么 Go 侧基准不够 ============================
* Go 侧 codec_bench_test.go 测到的数 = **函数体成本 + cgo 边界成本**(约 30ns)
* 两项混在一起。后果:看到某个场景慢,分不清该优化 C 函数体,还是该减少
* 跨语言调用次数(或把循环整体 C 化批量传一次)—— 而这三者的处方完全不同。
* 只有在能隔离边界成本的地方(纯 C 循环)测,才知道该动谁。
*
* 用法:cmake -DBUILD_BENCH=ON && ./ha_codec_bench [reps]
*
* 覆盖与 Go 侧 benchInputs 对齐(empty / ascii_short / zh_short / zh_200 /
* ascii_1k / zh_1k),便于两张表直接对读。
*/
#ifndef _POSIX_C_SOURCE
# define _POSIX_C_SOURCE 199309L
#endif
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <time.h>
#include "ha_codec.h"
/* 单调时钟(纳秒)。
*
* ★ 必须是 clock_gettime(不是 clock()、不是 time()):基准要测的是
* 几十纳秒级的函数体耗时,clock()/time() 的分辨率是**秒**,
* 拿它测 ns/op 只会得到一堆 0 或被量化成整数秒的噪声。
*
* ★ CLOCK_MONOTONIC 与 clock_gettime 都是 POSIX 而**非 ISO C99**,
* 而 CMake 刻意设了 CMAKE_C_EXTENSIONS OFF(严格 -std=c99)
* ⇒ 未定义这两个符号。实测报错:
* error: storage size of 'ts' isn't known
* error: implicit declaration of function 'clock_gettime'
* 这是 C 化门禁当场抓出的真实可移植性缺陷 —— 若靠 Makefile 的裸 gcc
* (默认 gnu17)构建,它会**静默编过**;而到别人的严格 C99 工具链上就炸。
*
* 故显式请求 POSIX 声明。_POSIX_C_SOURCE 必须在包含任何头文件**之前**
* 定义(否则 feature test macro 无效,这也是最常见的踩法)。
* Windows/MSVC 走 _MSC_VER 分支(用 QueryPerformanceCounter),
* 保证这个 bench 文件在异端也能编。 */
#if defined(_MSC_VER)
# include <windows.h>
static double now_sec(void) {
LARGE_INTEGER f, c;
QueryPerformanceFrequency(&f);
QueryPerformanceCounter(&c);
return (double)c.QuadPart / (double)f.QuadPart;
}
#else
# ifndef _POSIX_C_SOURCE
# define _POSIX_C_SOURCE 199309L
# endif
# include <time.h>
static double now_sec(void) {
struct timespec ts;
clock_gettime(CLOCK_MONOTONIC, &ts);
return (double)ts.tv_sec + (double)ts.tv_nsec / 1e9;
}
#endif
/* 分配并填充 reps 个 'x' 的缓冲(可含 NUL 之外的任意字节)。 */
static char *make_fill(size_t n, char ch) {
char *p = (char *)malloc(n ? n : 1);
if (p) memset(p, ch, n);
return p;
}
static void bench_estimate(const char *name, const char *s, size_t len, int reps) {
/* 预热:把指令缓存与分支预测器带进稳态,否则首个样本的冷启动会
* 均摊到很少的迭代上(reps 小的时候误差极大)。 */
for (int i = 0; i < reps; i++) (void)ha_codec_estimate_tokens(s, len);
double t0 = now_sec();
int acc = 0;
for (int i = 0; i < reps; i++) {
acc += ha_codec_estimate_tokens(s, len);
}
double dt = now_sec() - t0;
double ns = (reps > 0) ? (dt * 1e9 / reps) : 0.0;
double mbs = (dt > 0) ? ((double)len * reps / dt / 1e6) : 0.0;
printf(" %-12s len=%7zu %9.2f ns/op %8.1f MB/s (acc=%d)\n",
name, len, ns, mbs, acc);
}
static void bench_truncate(const char *name, const char *s, size_t len,
int max_tokens, int reps) {
for (int i = 0; i < reps; i++) {
(void)ha_codec_truncate_by_tokens(s, len, max_tokens);
}
double t0 = now_sec();
size_t acc = 0;
for (int i = 0; i < reps; i++) {
acc += ha_codec_truncate_by_tokens(s, len, max_tokens);
}
double dt = now_sec() - t0;
double ns = (reps > 0) ? (dt * 1e9 / reps) : 0.0;
printf(" %-12s len=%7zu %9.2f ns/op (keep=%zu)\n",
name, len, ns, acc / (size_t)reps);
}
int main(int argc, char **argv) {
int reps = (argc > 1) ? atoi(argv[1]) : 200000;
if (reps <= 0) reps = 200000;
printf("== ha_codec C 侧微基准(reps=%d,纯 C 无 cgo 边界)==\n", reps);
printf("-- ha_codec_estimate_tokens --\n");
bench_estimate("empty", "", 0, reps);
bench_estimate("ascii_short", "hello world", 11, reps);
bench_estimate("zh_short", "用户询问了系统状态", 27, reps);
{
char *zh200 = make_fill(180, 'a'); /* 逐字节非 ASCII 由下方覆盖 */
bench_estimate("ascii_200", zh200, 180, reps);
free(zh200);
}
{
char *zh = make_fill(1024, 'x');
bench_estimate("ascii_1k", zh, 1024, reps);
free(zh);
}
{
/* 真实中文:每字 3 字节 = 1024 字节 ≈ 341 rune */
char *zh = make_fill(1023, 'x');
for (size_t i = 0; i + 2 < 1024; i += 3) {
zh[i] = (char)0xE4; zh[i + 1] = (char)0xBD; zh[i + 2] = (char)0xA0;
}
bench_estimate("zh_1k", zh, 1024, reps);
free(zh);
}
printf("-- ha_codec_truncate_by_tokens (max_tokens=64) --\n");
{
char *a1k = make_fill(1024, 'x');
bench_truncate("ascii_1k", a1k, 1024, 64, reps);
free(a1k);
}
{
char *zh = make_fill(1023, 'x');
for (size_t i = 0; i + 2 < 1024; i += 3) {
zh[i] = (char)0xE4; zh[i + 1] = (char)0xBD; zh[i + 2] = (char)0xA0;
}
bench_truncate("zh_1k", zh, 1024, 64, reps);
free(zh);
}
printf("-- ha_codec_model_context_window (含/不含匹配) --\n");
{
const char *models[4] = {
"deepseek/deepseek-v4.1-flash", "gpt-4-turbo", "qwen-max", "AUTO"
};
for (int w = 0; w < 4; w++) {
size_t l = strlen(models[w]);
for (int i = 0; i < reps; i++) {
(void)ha_codec_model_context_window(models[w], l);
}
double t0 = now_sec();
int acc = 0;
for (int i = 0; i < reps; i++) {
acc += ha_codec_model_context_window(models[w], l);
}
double dt = now_sec() - t0;
printf(" %-30s %9.2f ns/op (win=%d)\n", models[w],
(reps > 0) ? dt * 1e9 / reps : 0.0, acc / reps);
}
}
printf("-- ABI --\n");
printf(" ha_codec_abi_version = %d\n", ha_codec_abi_version());
return 0;
}

80
csrc/include/ha_abi.h Normal file
View File

@ -0,0 +1,80 @@
#ifndef HA_ABI_H
#define HA_ABI_H
/*
* ha_abi.h — HomeAgent C 库的 ABI 版本契约
*
* ============================ 为什么需要它 ============================
* ha_codec.h 声明「签名一经发布即冻结」,但**冻结只写在注释里**——注释不
* 参与编译,Go/C 两侧对「我以为的版本」不一致时没有任何机制会报错。
* 本头文件把冻结变成**编译期与测试期可断言的事实**:
*
* 1. 每个 C 库声明自己的 ABI 主/次版本(HA_CODEC_ABI_MAJOR/MINOR)。
* 2. Go 侧(internal/agent/api/codec_cgo.go)持有一份 Go 常量副本,
* 由 TestABIVersionMatches 比对 C 宏 —— 版本漂移**在测试里判红**,
* 而不是等到线上表现为「插件行为诡异」才排查。
* 3. 主版本不同 = ABI 不兼容,必须走大版本流程(与 homeagent-sdk 同一标准)。
*
* ============================ 改动规则 ============================
* - 只增不改、只加不改:新增函数/字段 → MINOR+1
* - 改签名、删函数、改结构体布局 → MAJOR+1(且所有调用方必须同步重编)
* - 纯内部实现优化(不动任何声明)→ 不动版本号
*
* ⚠️ 与 homeagent-sdk 的 C ABI 不同:本项目的 C 库是**源码内联编译**
* (Go 侧符号链接 csrc/ 权威源,见 codec_cgo.go 顶部),不存在跨版本
* 混链的 .so/.a,所以「同批重建」是天然成立的——版本宏的作用是
* **防语义漂移**(两侧对同一组函数的理解不一致),不是防二进制不兼容。
*/
#ifdef __cplusplus
extern "C" {
#endif
/* ==================== 编译期断言(C99/C11 兼容) ==================== */
/* 静态断言:版本号写错必须在编译期就炸,不能带着荒谬版本号发布出去。
*
* ★ C99 没有 _Static_assert(那是 C11),而本项目 C 侧统一 -std=c99
* (见 codec_cgo.go 的 cgo CFLAGS 与 CMakeLists 的 C_STANDARD)。故需兼容垫片:
* C11+ 用原生 _Static_assert;C99 回退到「数组维度为 0 即编译失败」的老写法。
* 这条垫片是 -Wall -Wextra -Wpedantic 门禁上线时**当场抓出来的**(首次编译即告警),
* 即基础设施已经开始在发挥作用。
*
* 用法:第二个参数必须是**标识符**(不能是字符串)——C99 分支要用它 ## 成
* 一个 typedef 名,而 `##` 不能拼接字符串字面量(拼接会直接编译报错)。
* 原生 _Static_assert 分支则把它当 msg 传(此时它在诊断里显示为标识符,
* 仍能指出是哪个断言)。同一文件内每个断言的 tag 必须不同。 */
#if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 201112L
# define HA_STATIC_ASSERT(cond, tag) _Static_assert(cond, #tag)
#elif defined(__cplusplus) && __cplusplus >= 201103L
# define HA_STATIC_ASSERT(cond, tag) static_assert(cond, #tag)
#else
# define HA_STATIC_ASSERT(cond, tag) \
typedef char ha_sa_##tag##_line_##__LINE__[(cond) ? 1 : -1]
#endif
/* ==================== ABI 版本 ==================== */
/* 编码语义主版本:改动任一已发布函数的语义/签名时 +1。
* 2026-09-26:首版 1.0(上下文窗口推断 + token 估算/截断)。 */
#define HA_CODEC_ABI_MAJOR 1
/* 编码语义次版本:纯新增(加函数、加枚举值)时 +1。 */
#define HA_CODEC_ABI_MINOR 0
/* 合成版号,便于日志/断言单值比较:major*1000 + minor */
#define HA_CODEC_ABI_VERSION (HA_CODEC_ABI_MAJOR * 1000 + HA_CODEC_ABI_MINOR)
/* 编译期锁死:ABI 版本必须落在「已知的、未被遗忘的」区间。
* 若有人把版本号改成 0 或 999 之类(通常是手滑/拷贝粘贴出错),
* 编译立即失败,而不是带着一个荒谬的版本号发布出去。 */
HA_STATIC_ASSERT(HA_CODEC_ABI_MAJOR >= 1 && HA_CODEC_ABI_MAJOR <= 9,
ha_codec_abi_major_in_range);
HA_STATIC_ASSERT(HA_CODEC_ABI_MINOR >= 0 && HA_CODEC_ABI_MINOR <= 99,
ha_codec_abi_minor_in_range);
#ifdef __cplusplus
}
#endif
#endif /* HA_ABI_H */

97
csrc/include/ha_codec.h Normal file
View File

@ -0,0 +1,97 @@
#ifndef HA_CODEC_H
#define HA_CODEC_H
/*
* ha_codec — HomeAgent 内核编解码层(C 实现)
*
* ============================ 接口冻结声明 ============================
* 本头文件是对外契约。函数签名、语义、返回值一经发布即为冻结接口,
* 修改必须走大版本流程(与 third_party/homeagent-sdk 同一冻结标准)。
*
* 设计约束(见 docs/zh/c-core/llm-orchestration-c.md §四):
* 1. 只吃 const char* + **显式长度**,出数值/字节偏移 —— 不回调 Go、
* 不传 Go 指针、不要求 NUL 结尾
* 2. **不 malloc**:不需要出参缓冲区,需要「结果」时返回字节偏移/长度,
* 由调用方在自己的缓冲上切片(零拷贝)
* 3. 无状态、纯函数、线程安全(不写全局可变状态)
*
* 当前覆盖:L1 协议编解码层中的纯计算部分(第一个最小切片)。
*
* ============================ 为什么签名带长度 ============================
* 初版签名用 `const char*` 隐含「NUL 结尾」,于是每次调用都要:
* Go `C.CString` 分配+拷贝一遍 → C `strlen` 再扫一遍。
* 实测这部分开销占单次调用的 80% 以上(cgo 边界本身仅 ~30ns,
* 而初版 ModelContextWindow 实测 175ns)。
* 改为「指针 + 长度」后,Go 侧用 unsafe.StringData 直接传底层数组,
* 零分配零拷贝。这是设计约束第 1 条的字面要求。
*/
#include <stddef.h>
#include "ha_abi.h"
#ifdef __cplusplus
extern "C" {
#endif
/* ==================== ABI 自述(供 Go 侧与日志核对) ==================== */
/* 返回 HA_CODEC_ABI_VERSION(major*1000 + minor)。
*
* 存在的意义:Go 侧不该靠 `#include` 宏做版本断言(cgo 头文件里的宏在
* 预处理后不可见),而要**运行期/测试期**能问 C 侧「你自称什么版本」。
* 由 codec_cgo.go 绑定、codec_abiversion_test.go 与 C 侧宏三方比对。 */
int ha_codec_abi_version(void);
/* ==================== 模型上下文窗口推断 ==================== */
/* 无法从模型名推断时的哨兵值(与 Go 侧一致)。
*
* 为什么返回哨兵而不是直接给兜底值:调用方需要区分「真推断出了」与
* 「推断不出、只能兜底」——后者要打一行日志(窗口被低估必须可见),
* 并提示部署方用 per-source context_window 显式声明。
* 若 C 侧直接返回兜底值,调用方就永远分不清这两种情况。 */
#define HA_CODEC_CONTEXT_WINDOW_UNKNOWN (-1)
/* 由模型名推断最大上下文窗口(token 数);推断不出返回
* HA_CODEC_CONTEXT_WINDOW_UNKNOWN。
*
* model 为 UTF-8 字节序列,**不需要 NUL 结尾**;model_len 是字节数。
* model 为 NULL 或 model_len 为 0 时返回 UNKNOWN。
*
* 匹配大小写不敏感(仅对 ASCII 字母做折叠;非 ASCII 字节按原样比较,
* 与 Go 侧对模型名的实际输入一致)。
*
* 语义必须与 Go 侧 modelContextWindowPure 逐值一致(黄金对照测试钉死)。 */
int ha_codec_model_context_window(const char *model, size_t model_len);
/* ==================== token 估算与截断 ==================== */
/* 粗略估算 token 数。
*
* 规则(与 Go 侧 EstimateTokens 一致):保守取 max(1, runeCount * 2)。
* 按 UTF-8 **字符数**(rune)计,不是字节数。
* text 为 NULL 或 text_len 为 0 返回 0。
*
* 非法 UTF-8 序列按 Go 的 utf8 解码语义处理(每字节一个 rune),
* 保证与 Go 侧逐值一致。 */
int ha_codec_estimate_tokens(const char *text, size_t text_len);
/* 按 token 预算计算「应保留的字节数」。
*
* ★ 返回的是**字节数**而非字符串:截断结果必然是输入的前缀,
* 调用方直接在自己的缓冲上切片即可(零拷贝、无出参缓冲区、无 malloc)。
*
* 语义与 Go 侧 TruncateByTokens 一致:从开头保留 maxTokens/2 个 rune;
* 未超预算时返回 text_len(即整串)。
* max_tokens <= 0 或 text 为 NULL/text_len 为 0 时返回 0。
*
* 返回值保证 <= text_len。 */
size_t ha_codec_truncate_by_tokens(const char *text, size_t text_len,
int max_tokens);
#ifdef __cplusplus
}
#endif
#endif /* HA_CODEC_H */

232
csrc/include/ha_json_scan.h Normal file
View File

@ -0,0 +1,232 @@
#ifndef HA_JSON_SCAN_H
#define HA_JSON_SCAN_H
/*
* ha_json_scan — HomeAgent 内核 LLM 协议层的 JSON 扫描/取值层(C 实现)
*
* ============================ 定位 ============================
* 本库**不是**通用 JSON 库,是**流式协议分块解析**专用的零分配扫描层。
* 它服务 `parseOpenAICompatibleStreamChunkFull`(每个 SSE chunk 跑一次的最热路径)。
*
* ★ 为什么不复用 SDK 的 remotedevice/src/ha_json.c(实测,见 plan.md §七):
* 1. 无 `\u` 解码 —— `\u4f60\u597d` 得到 `?0?d?d?0`(LLM 内容全靠转义时直接损坏)
* 2. 只有 `_get_int`,无浮点 —— `temperature:0.7` **静默**变 0
* 3. `null` 与「键缺失」不可区分
* 4. 架构是 **DOM + malloc**,与「不 malloc / 零拷贝 / 纯函数」正交
* 它的定位是 remotedevice 设备通道,不是 LLM 协议层。
*
* ============================ 设计:scan / extract 两段分离 ============================
* **scan** 只出结构 span(键 span / 值 span),零分配、零解码、零求值。
* **extract** 按 span 取值,解码只发生在真正需要它的调用方身上。
*
* 为什么必须分离:`content` 可能是很大的多模态数组,而 `stringifyContent`
* 只需要「把 text 字段拼起来」。若 scan 阶段就为每个字符串 `\u` 解码并分配
* 缓冲,等于把解码成本付给了不需要它的调用方 —— 那正是我们要消灭的分配。
*
* ============================ 不可协商的约束(与 ha_codec.h 同标准) ============================
* 1. 只吃 `const char*` + **显式长度**,不要求 NUL 结尾
* (否则又是 `strlen` + 拷贝的老问题,见第一刀 §7.1 的 82% 自找开销)
* 2. **不 malloc**:结果一律以 span(指针+长度)回给调用方,Go 侧零拷贝切片
* 3. 无状态、纯函数、线程安全(不写全局可变状态)
* 4. 语法语义必须与 Go `encoding/json` **一致**,由黄金对照测试钉死
*
* ============================ 语义对齐(易踩,全部实测) ============================
* - 键匹配**大小写不敏感**(Go `encoding/json` 行为)
* - 字符串取值时非法 UTF-8 每字节替换为 U+FFFD(与 Go 一致)
* - 重复键**后者胜**
* - 本层**不做类型检查**:`{"a":{}}` 对 `a` 的扫描成功,是否「类型不对应报错」
* 由调用方按 Go 的 interface{} / 强类型语义决定(见 §三.2.2 的实测)
*/
#include <stddef.h>
#include "ha_abi.h"
#ifdef __cplusplus
extern "C" {
#endif
/* ==================== ABI 版本(与 ha_abi.h 同步) ==================== */
#define HA_JSON_SCAN_ABI_MAJOR 1
#define HA_JSON_SCAN_ABI_MINOR 0
#define HA_JSON_SCAN_ABI_VERSION \
(HA_JSON_SCAN_ABI_MAJOR * 1000 + HA_JSON_SCAN_ABI_MINOR)
HA_STATIC_ASSERT(HA_JSON_SCAN_ABI_MAJOR >= 1 && HA_JSON_SCAN_ABI_MAJOR <= 9,
ha_jsonscan_abi_major_in_range);
HA_STATIC_ASSERT(HA_JSON_SCAN_ABI_MINOR >= 0 && HA_JSON_SCAN_ABI_MINOR <= 99,
ha_jsonscan_abi_minor_in_range);
/* 返回 HA_JSON_SCAN_ABI_VERSION(供 Go 侧与日志核对)。 */
int ha_json_scan_abi_version(void);
/* ==================== span 与扫描器 ==================== */
/* 字节区间 [p, p+len)。指针指向**调用方的原缓冲**,本库从不持有或释放。 */
typedef struct {
const char *p;
size_t len;
} ha_span;
/* 扫描器:对一段 JSON 文本的只读游标。
*
* ★ 就地结构体(非指针):调用方在栈上持有,零分配。
* 但因此**不可拷贝后混用**(拷贝出的副本与原游标各自独立推进)。
*/
typedef struct {
const char *s; /* 缓冲区起点 */
size_t n; /* 缓冲区长度 */
size_t i; /* 当前游标偏移 */
} ha_json_scan;
/* 用 (s, n) 初始化扫描器,游标置于起点。s 可为 NULL(此时按 n=0 处理)。 */
void ha_json_scan_init(ha_json_scan *sc, const char *s, size_t n);
/* 跳过前导 ASCII 空白(空格 / \t / \n / \r)。返回是否已到结尾。 */
int ha_json_scan_ws(ha_json_scan *sc);
/* 当前是否已到结尾(不含空白跳过)。 */
int ha_json_scan_eof(const ha_json_scan *sc);
/* 跳过**一个完整的 JSON 值**(对象 / 数组 / 字符串 / 数字 / 字面量)。
*
* 用于二次进数组内部(如 stringifyContent 取数组元素的 text 字段):
* 先 skip 前面的元素,再对目标元素单独扫描。
* 返回 0 表示语法错误,1 表示成功。成功后游标停在该值之后。
*/
int ha_json_skip(ha_json_scan *sc);
/* 解析一个字符串值,出**原始字节 span**(含转义序列,未解码)。
*
* 入参:游标应停在 `"` 上(或之前的空白,函数自己跳过空白)。
* 出参 raw:不含两端引号的原始内容 span(指向原缓冲,零拷贝)。
* 返回 0 = 语法错误(未闭合 / 非字符串)。
*
* ★ 注意:不做 `\u` 解码、不做非法 UTF-8 替换 —— 那是 extract 阶段的事。
*/
int ha_json_scan_string(ha_json_scan *sc, ha_span *raw);
/* ==================== 顶层对象:扫描出键值对 ==================== */
/*
* 顶层对象的迭代器。
*
* ★ 为什么由本库来切「顶层逗号」而不是让 C 侧只解析第一个键:
* LLM 的 `content` 里常含 `{`、`}`、`,`(代码、JSON 片段、模板)。
* 若调用方自己按逗号切开顶层,会被内容里的逗号错切。
* 本库扫**字符串感知**的边界,保证只在真正的顶层分隔符处切分。
*/
typedef struct {
ha_json_scan sc; /* 游标 */
int started; /* 是否已消费过至少一个成员 */
int done; /* 迭代是否已结束(正常或异常) */
int error; /* 结束原因:1 = 输入畸形(而非正常的 '}') */
} ha_json_members;
/* 初始化顶层对象迭代。非法(首个非空白字符不是 '{')时返回 0。 */
int ha_json_members_init(ha_json_members *m, const char *s, size_t n);
/* 取下一个成员。
*
* 出参:
* key —— 键的原始字节 span(未解码,不含引号);可为 NULL
* val —— 值的**完整 span**(未解码);可为 NULL
*
* 返回: 1 = 拿到一个完整成员;0 = 结束。
*
* ★ 本函数**内部会完整跳过一个值**,因此:
* 1. 返回 1 蕴含「这个成员是良构的」(值能独立被 skip)——
* 调用方拿到的 val 一定可解析,不必自己再验一次。
* 2. 游标在返回前已推进到值之后,下一次调用直接看下一个成员。
* (早期版本只报值的**起始位置**、不消费值,迫使调用方自己
* 修正游标 —— 那是个错误的设计:调用方一旦忘了推进,下一个
* 成员就会解析到上一个值,而模糊测试立刻把它暴露了出来。)
*
* ★ 结束时要区分原因:用 ha_json_members_complete() 判断是否正常。
* 返回 0 既可能是「正常扫到 '}'」也可能是「输入畸形」——
* 要复刻 Go 的严格性(畸形 ⇒ 整块作废)就必须能分辨。
*
* ★ 键匹配请用 ha_json_key_eq(大小写不敏感),不要自己 memcmp。
*/
int ha_json_members_next(ha_json_members *m, ha_span *key, ha_span *val);
/* 迭代是否**正常结束**(消费到闭合的 '}')。
*
* 语义:只有在 next() 返回 0 之后才有意义。
* 返回 1 = 对象良构且已完整扫描;0 = 输入畸形(缺 '}' / 尾逗号 /
* 值非法等)。调用方若要复刻 Go 的严格性,应要求它为 1。
*/
int ha_json_members_complete(const ha_json_members *m);
/* 大小写不敏感地比较键 span 与 ASCII 字面量。返回 1/0。
*
* ★ 必须用它而不是 memcmp:Go `encoding/json` 的键匹配**大小写不敏感**,
* 实测 `{"delta":{"CONTENT":"up"}}` 能取出 content="up"。
* 逐字节比对会静默漏掉这类输入。 */
int ha_json_key_eq(ha_span key, const char *name);
/* ==================== 取值(extract) ==================== */
/* 字符串解码的**写入回调**。
*
* ★ 为什么用回调而不是「分配缓冲返回」:本库不 malloc。调用方把自己的
* Go 侧 buffer / 栈缓冲 / 直接写目标的位置交给本库,解码结果逐个 rune
* 以 UTF-8 字节写入 —— 非法序列按 Go 语义替换为 U+FFFD。
*
* ★ 为什么按 rune 而不是按字节:`\uXXXX` 可能产生多字节 rune(含代理对
* 合成的 4 字节 emoji),调用方不该关心编码细节。
*/
typedef void (*ha_json_sink)(void *ctx, const char *utf8_bytes, size_t len);
/* 把字符串值 span(raw 形式,含转义)解码并经 sink 输出。
*
* 出参 out_len:解码后的字节总数(便于调用方预分配 / 校验)。
* 返回 0 = 原始 span 含**语法错误**(如 \u 后不是 4 位十六进制)。
*
* 非法 UTF-8 处理:与 Go `encoding/json` 一致 —— 每个非法字节一个 U+FFFD
* (**不是**按整个序列丢弃)。见真值表 §2.8。
*/
int ha_json_decode_string(ha_span raw, ha_json_sink sink, void *ctx,
size_t *out_len);
/* 把字符串值 span 解码进调用方提供的缓冲(不足则失败,不截断)。
*
* 返回写入的字节数;缓冲不足时返回 (size_t)-1 且不写。
* 适合长度已知且不关心「只需长度」的场景。
*/
size_t ha_json_decode_string_into(ha_span raw, char *out, size_t out_cap);
/* 读整数(仅接受 JSON 整数语法,可选负号;不允许小数点/指数)。
*
* ★ 与 Go 的对应关系:Go 里 `int` 字段会接受 `1e2`(=100)与拒绝 `1.5`;
* 本函数**只认纯整数**,指数/小数由调用方按「类型不匹配 ⇒ 整块作废」
* 语义处理(见真值表 §2.2)。这样职责清晰:本层只回答「这是不是整数」。
*
* 返回 1 = 成功且 *out 已写;0 = 不是合法整数。
* 溢出返回 0(与 Go 报错等价)。
*/
int ha_json_get_int(ha_span raw, long long *out);
/* ==================== 字符串取值的便捷路径 ==================== */
/* 在对象 span 内取键 name 的字符串值,解码进 out(NUL 结尾)。
*
* 返回:解码后字节数(不含结尾 NUL);键缺失 / 类型不是字符串 / 缓冲不足
* 返回 (size_t)-1。out 在成功时保证 NUL 结尾。
*
* 便捷函数:内部走 members 迭代 + key_eq + decode,适合调用方只取一两个键
* 且不需要「类型不匹配 ⇒ 整块作废」细节的场景。
*/
size_t ha_json_object_get_string(ha_span obj, const char *name,
char *out, size_t out_cap);
/* 在对象 span 内取键 name 的整数值。
* 返回 1 = 成功;0 = 键缺失 / 非合法整数 / 溢出。 */
int ha_json_object_get_int(ha_span obj, const char *name, long long *out);
#ifdef __cplusplus
}
#endif
#endif /* HA_JSON_SCAN_H */

218
csrc/include/ha_sse.h Normal file
View File

@ -0,0 +1,218 @@
#ifndef HA_SSE_H
#define HA_SSE_H
/*
* ha_sse — LLM 流式协议(SSE 分块)的「结构导航」辅助层
*
* ============================ 定位 ============================
* 本层不是 JSON 库(那是 ha_json_scan),而是把 ha_json_scan 原语组合成
* **协议层需要的几次定位**,供内核 parseOpenAICompatibleStreamChunkFull 使用。
*
* ★ 为什么这些函数放在 csrc/ 而不是内联在 Go 的 cgo 前言里:
* 放在 cgo 前言里的 C 代码**逃出了全部 C 门禁**(告警 / ASan+UBSan /
* 交叉编译 / 模糊测试),而它恰恰是本刀最容易出错的位置。
* 移进 csrc/ 后,同一个 -Wall -Wextra -Wpedantic -Wconversion 门禁
* 与 sanitizer 都覆盖到它 —— 这是一次真实的结构调整,不是形式主义。
*
* ============================ 为什么只做「导航」 ============================
* 实测两条 wire 语义(docs/zh/c-core/sse-codec-c.md §5)使「全量 C 化」不成立:
* §5.1 重复键是**字段级合并**(json.Unmarshal 的 SetIndex 叠加语义)
* §5.2 stringifyContent 的 default 分支是 json.Marshal(键排序 / 浮点
* 最短往返 / HTML 转义 / int 舍入)
* 二者都只在**取值**阶段需要,故本层只回答「值在哪里、它的热分支结果是什么」,
* 需要重新序列化的形态交回 Go(由 encoding/json 保证语义)。
*
* ============================ 键匹配:大小写敏感 ============================
* 本层是 **map key** 语义(`m["text"]`)⇒ 大小写敏感。
* 实测 `{"TEXT":"up"}` 取不到 `text`、`{"text":"low"}` 可以(§5.4-1)。
*
* ⚠️ 与 ha_json_key_eq(大小写**不**敏感,用于 struct 字段名)语义相反。
* 两者用途不同、都必要,**不要「统一」掉**。
* struct 字段那一跳由 encoding/json 负责,天然正确。
*/
#include <stddef.h>
#include "ha_abi.h"
#include "ha_json_scan.h"
#ifdef __cplusplus
extern "C" {
#endif
#define HA_SSE_ABI_MAJOR 1
#define HA_SSE_ABI_MINOR 1
#define HA_SSE_ABI_VERSION (HA_SSE_ABI_MAJOR * 1000 + HA_SSE_ABI_MINOR)
HA_STATIC_ASSERT(HA_SSE_ABI_MAJOR >= 1 && HA_SSE_ABI_MAJOR <= 9,
ha_sse_abi_major_in_range);
HA_STATIC_ASSERT(HA_SSE_ABI_MINOR >= 0 && HA_SSE_ABI_MINOR <= 99,
ha_sse_abi_minor_in_range);
int ha_sse_abi_version(void);
/*
* 在对象里按**大小写敏感**的键定位值。
*
* 返回: 1 = 找到(*out 已写);0 = 未找到(对象良构);-1 = 对象畸形。
* *dup 在发现**重复键**时置 1(后者胜已写入 *out)——
* 调用方据此整体回退到 encoding/json,因为重复键的字段级合并语义
* 见 sse-codec-c.md §5.1,本层不实现。
*/
int ha_sse_obj_find(const ha_span *obj, const char *key, size_t keylen,
ha_span *out, int *dup);
/*
* 在对象里按**大小写不敏感**的键定位值(struct 字段语义)。
*
* ★ 为什么必须与 ha_sse_obj_find 并存(两个函数,语义相反):
* - Go 的 `raw struct{ Choices ... \`json:"choices"\` }` 是 **struct 字段**,
* encoding/json 对字段名做**大小写不敏感**匹配 ⇒ 实测
* `{"CHOICES":[{"DELTA":{"CONTENT":"ci"}}]}` 能取到 content="ci"。
* - 而 `content` 是 `interface{}` → `map[string]interface{}`,取 `m["text"]`
* 是 **map key** 语义 ⇒ 大小写**敏感**(实测 `{"TEXT":"up"}` 取不到)。
* 跳错层就会静默漏掉字段(或取到不该取的),故两个函数都必要,
* 调用方必须按「这一跳在 Go 里是 struct 还是 map」来选择。
*
* 返回与 ha_sse_obj_find 相同:1=找到 0=未找到 -1=畸形。
* 对 *dup:大小写不敏感语义下,`{"CHOICES":..,"choices":..}` 两次都会命中
* 同一个 Go 字段(后者胜),故同样置 dup 让调用方回退。
*/
int ha_sse_obj_find_ci(const ha_span *obj, const char *key, size_t keylen,
ha_span *out, int *dup);
/*
* 校验 doc 是「**恰好一个**良构 JSON 对象」(尾部只允许空白)。
*
* 返回 1 = 是;0 = 否。
*
* ★ 为什么必须单独校验尾部:ha_sse_obj_find 用 members_complete 只保证
* 对象本身闭合,**不检查尾部残留** —— 而 Go 的 json.Unmarshal 会拒绝
* `{"a":1}{"b":2}`(trailing garbage)。少了这一步,快速路径会比 Go 宽松,
* 把一个 Go 判为失败的块判为成功 ⇒ 静默接受垃圾块。
*/
int ha_sse_root_object(const ha_span *doc);
/*
* 取数组**第一个元素**的 span。
*
* 返回: 1 = 有元素;0 = 空数组;-1 = 非数组或畸形。
*
* 为什么只要第一个:`choices[0]` 是协议约定(Go 侧也只读 resp.Choices[0]),
* 本层据此避免为后续元素做无用功。
*/
int ha_sse_arr_first(const ha_span *arr, ha_span *out);
/*
* stringifyContent 的 **C 可判定分支**:
* - 字符串值 → 反转义后原样输出
* - 数组值 → 逐元素取对象的 "text" 字段(精确键)拼接
*
* 返回: 1 = 已写入(*outlen 为字节数);0 = 需回退 Go。
* 回退的两种情形:
* a) 缓冲不足(调用方应给 >= val->len*3+4 的 cap)
* b) 值类型是对象 / 数字 / 字面量 —— 那些要走 json.Marshal(§5.2)
*
* 数组元素的规则(§5.4-2/3 实测):
* · 非对象元素 **静默跳过**(`["a",{"text":"b"}]` → "b")
* · 非对象的 "text"(如 text:123)**静默跳过**
* · 元素里出现重复的 "text" 键 ⇒ 整体回退 Go(合并语义)
*/
int ha_sse_stringify(const ha_span *val, char *out, size_t cap, size_t *outlen);
/*
* arguments 为**字符串**时,取出其解码结果(省掉 interface{} 与二次解析)。
*
* 返回 1 = 已写入;0 = 不是字符串或失败(调用方按既有路径处理)。
* 非字符串 arguments(对象/数组/数字)**必须**回退 Go:那里的
* `rawArgsString` 会 `json.Marshal` 重新编码,而这个**重新编码的键序
* 可能与原文不同**(实测 {"b":2,"a":1} → {"a":1,"b":2})——
* 逐值一致要求由 encoding/json 来做。
*/
int ha_sse_arg_string(const ha_span *val, char *out, size_t cap, size_t *outlen);
/* ==================================================================== */
/* 批量定位:**一次调用**返回整块解析所需的全部字段 */
/* ==================================================================== */
/*
* ★ 为什么需要它(第三刀实测的教训,见 sse-codec-c.md §六):
* 逐字段往返做 5+ 次 cgo 调用,每次约 168ns 边界 + 2 allocs(out-param
* 逃逸到堆)⇒ 约 1µs 固定成本,把全部收益吃光,结果比原实现更慢。
*
* 本接口把它压成 **1 次调用**,并顺带解决另外两点:
* · **单趟键分派**:不再「每个键各扫一遍对象」,而是遍历一次成员表
* 就分派(原来 6 次扫描 → 2 次)
* · **解码内联**:content / reasoning_content 的解码在同一趟里写进
* 调用方缓冲,不再各来一次往返
*
* 结果写在调用方的 ha_chunk_out 里(C 结构体、无 Go 指针 ⇒ 可安全传指针)。
*/
/* 槽位索引(固定约定,**改动必须 bump ABI**)。 */
#define HA_CHUNK_SLOT_DELTA 0
#define HA_CHUNK_SLOT_CONTENT 1
#define HA_CHUNK_SLOT_REASONING 2
#define HA_CHUNK_SLOT_TOOL_CALLS 3
#define HA_CHUNK_SLOT_FINISH_REASON 4
#define HA_CHUNK_SLOT_USAGE 5
#define HA_CHUNK_SLOT_COUNT 6
/* 槽位类型。与 Go 侧「该字段是什么 Go 类型」对应,而非单纯 JSON 类型。 */
#define HA_CHUNK_KIND_ABSENT 0
#define HA_CHUNK_KIND_NULL 1
#define HA_CHUNK_KIND_STRING 2
#define HA_CHUNK_KIND_OBJECT 3
#define HA_CHUNK_KIND_ARRAY 4
#define HA_CHUNK_KIND_OTHER 5 /* 数字 / 布尔 */
/* ha_sse_chunk_locate 返回码。 */
#define HA_CHUNK_OK 0 /* 定位成功,可用快速路径 */
#define HA_CHUNK_FALLBACK -1 /* 需回退 Go:重复键 / 畸形 / 顶层非对象 /
* 多 choices / 缓冲不足 */
#define HA_CHUNK_TYPE_FAIL -2 /* 与 Go 一致的「整块作废」(类型不符) */
typedef struct {
ha_span span; /* 原始值 span(未解码,指向 data) */
int kind; /* HA_CHUNK_KIND_* */
} ha_chunk_slot;
typedef struct {
ha_chunk_slot slot[HA_CHUNK_SLOT_COUNT];
/* choices 数组本身的 span(choices_count>0 时有效) */
ha_span choices_span;
/* choices[0] 的 span(choices_count==1 时有效) */
ha_span choice0_span;
/* 解码/反转义结果(写入 sbuf,以 [off,len) 表示;kind 非字符串时为 (0,0)) */
size_t content_off; size_t content_len;
size_t reasoning_off; size_t reasoning_len;
size_t finish_off; size_t finish_len;
int has_choices; /* choices 是否存在且非 null */
int choices_kind; /* ABSENT / NULL / ARRAY */
int choices_count; /* 元素个数(>1 时调用方必须回退,见下) */
int choice0_kind; /* ABSENT / NULL / OBJECT */
} ha_chunk_out;
/*
* 一次调用定位整块解析所需的全部字段。
*
* data/len : SSE chunk 原始字节(不需要 NUL 结尾)
* out : 输出(调用方持有;C 只在本调用内写它)
* sbuf/scap : 解码输出缓冲(content / reasoning_content / finish_reason)
* sused : 出参,缓冲区实际用量
*
* 返回 HA_CHUNK_OK / HA_CHUNK_FALLBACK / HA_CHUNK_TYPE_FAIL。
*
* ★ 调用方**必须**检查 choices_count:Go 侧是 `[]struct`,Unmarshal 会解析
* **全部**元素,而本层只取 [0](协议约定)。若元素 >1,本层无法保证
* 其余元素也能被 Go 解析(它们可能有类型错误)⇒ 必须回退。
* 本函数在 choices_count>1 时**直接返回 FALLBACK**,不给调用方犯错的机会。
*/
int ha_sse_chunk_locate(const char *data, size_t len, ha_chunk_out *out,
char *sbuf, size_t scap, size_t *sused);
#ifdef __cplusplus
}
#endif
#endif /* HA_SSE_H */

345
csrc/src/ha_codec.c Normal file
View File

@ -0,0 +1,345 @@
/*
* ha_codec.c — HomeAgent 内核编解码层(C 实现)
*
* ============================ 性能设计(勿回退)============================
* 1. **不 malloc**:模型名折叠用栈缓冲(短名走快路径,超长走零分配的回退)。
* 2. **不 strlen**:长度由调用方传入(见 ha_codec.h 签名说明)。
* 3. **ASCII 批量快路径**:连续 ASCII 成批计数,避免逐字节函数调用。
* 4. **截断提前短路**:数满 keep 个 rune 立即返回,不扫完整串。
* 5. **截断返回字节数**而非字符串:结果必然是输入前缀,调用方自己切片。
*
* 初版的三个反例(实测代价,见 docs/zh/c-core/llm-orchestration-c.md §7.1):
* - Go 侧 C.CString(malloc+拷贝)+ C 侧 strlen,单这一项约 75ns,
* 而 cgo 边界本身仅约 32ns —— 即 **82% 的开销是自找的**,不是 cgo 的成本。
* 初版由此得出「C 比 Go 慢」的结论是错的。
* - 逐字节 utf8_next 函数调用 ⇒ 1KB ASCII 比纯 Go 慢 7 倍。
* - 1KB 中文要先扫完整串才判断是否截断。
*
* 语义必须与 Go 侧实现逐值一致,由黄金对照测试钉死(含畸形 UTF-8)。
*/
#include "ha_codec.h"
#include <stdint.h>
#include <string.h>
/* ---------------------------------------------------------------- */
/* 大小写不敏感的子串匹配 */
/* ---------------------------------------------------------------- */
/* 只折 ASCII 字母;非 ASCII 字节原样(与 Go strings.ToLower 对模型名的
* 实际效果一致——模型名都是 ASCII,中文/日文字节不受 ToLower 影响)。 */
static unsigned char ascii_lower(unsigned char c) {
return (c >= 'A' && c <= 'Z') ? (unsigned char)(c + 32) : c;
}
/* 已折叠缓冲(长度 hn)中是否含子串 sub(sub 必须已小写、ASCII)。
* memcmp 版本:折叠一次后可向量化比较,是短名快路径。 */
static int contains(const char *m, size_t hn, const char *sub) {
size_t m_len = strlen(sub);
if (m_len == 0 || hn < m_len) {
return 0;
}
size_t last = hn - m_len;
for (size_t i = 0; i <= last; i++) {
/* 首字节过滤掉绝大多数位置,避免无谓 memcmp */
if (m[i] == sub[0] && memcmp(m + i, sub, m_len) == 0) {
return 1;
}
}
return 0;
}
/* 边比较边折叠:**任意长度**都正确,无需缓冲(超长模型名的回退路径)。
* sub 中的 ASCII 字母按小写处理;非 ASCII 字节按字节精确比较
* (因此可直接用于 "\xe9\x9b\xb6\xe4\xb8\x80" 这类多字节字面量)。 */
static int contains_ci(const char *h, size_t hn, const char *sub) {
size_t m_len = strlen(sub);
if (m_len == 0 || hn < m_len) {
return 0;
}
size_t last = hn - m_len;
for (size_t i = 0; i <= last; i++) {
size_t j = 0;
while (j < m_len &&
ascii_lower((unsigned char)h[i + j]) == (unsigned char)sub[j]) {
j++;
}
if (j == m_len) {
return 1;
}
}
return 0;
}
/* 模型名的不可变视图:能进栈缓冲就折叠,否则按原样(用 contains_ci 匹配)。 */
typedef struct {
const char *p;
size_t n;
int folded;
} model_view;
/* 栈缓冲容量:模型名实测都是几十字节。超出则退化为不折叠 +
* contains_ci —— 仍**零分配且语义正确**,只是少了 memcmp 的向量化优势。 */
#define HA_MODEL_STACK 256
static int mv_contains(const model_view *v, const char *sub) {
return v->folded ? contains(v->p, v->n, sub) : contains_ci(v->p, v->n, sub);
}
/* ---------------------------------------------------------------- */
/* 模型上下文窗口推断 */
/* ---------------------------------------------------------------- */
int ha_codec_model_context_window(const char *model, size_t model_len) {
if (model == NULL || model_len == 0) {
return HA_CODEC_CONTEXT_WINDOW_UNKNOWN;
}
char stack[HA_MODEL_STACK];
model_view v;
if (model_len < HA_MODEL_STACK) {
for (size_t i = 0; i < model_len; i++) {
stack[i] = (char)ascii_lower((unsigned char)model[i]);
}
stack[model_len] = '\0';
v.p = stack;
v.n = model_len;
v.folded = 1;
} else {
v.p = model;
v.n = model_len;
v.folded = 0;
}
/* 顺序与 Go 侧 switch 分支**严格一致**:先匹配到的分支胜出。
* 这不是「随便一组 if」,顺序错了就会给出不同窗口
* (例:gpt-4-turbo 必须先于裸 gpt-4 命中)。 */
if (mv_contains(&v, "deepseek-v4") || mv_contains(&v, "deepseek-v3")) {
return 1048576;
}
if (mv_contains(&v, "deepseek-r1") || mv_contains(&v, "deepseek-chat")) {
return 65536;
}
if (mv_contains(&v, "gpt-4")) {
if (mv_contains(&v, "turbo") || mv_contains(&v, "mini") || mv_contains(&v, "omni")) {
return 128000;
}
return 8192;
}
if (mv_contains(&v, "gpt-3.5")) {
return 16384;
}
if (mv_contains(&v, "claude-3.5") || mv_contains(&v, "claude-3")) {
return 200000;
}
if (mv_contains(&v, "claude")) {
return 100000;
}
if (mv_contains(&v, "gemini-1.5") || mv_contains(&v, "gemini-2")) {
return 1048576;
}
if (mv_contains(&v, "gemini")) {
return 32768;
}
if (mv_contains(&v, "qwen")) {
return 131072;
}
if (mv_contains(&v, "glm") || mv_contains(&v, "chatglm")) {
return 131072;
}
if (mv_contains(&v, "llama-3")) {
return 8192;
}
if (mv_contains(&v, "llama-2")) {
return 4096;
}
if (mv_contains(&v, "mistral") || mv_contains(&v, "mixtral")) {
return 32768;
}
/* "yi-" 与 "零一"(UTF-8 字面量)——contains_ci 对字节精确比较,
* 故中文部分不受折叠影响,与 Go 的 strings.Contains 一致。 */
if (mv_contains(&v, "yi-") || mv_contains(&v, "\xe9\x9b\xb6\xe4\xb8\x80")) {
return 200000;
}
if (mv_contains(&v, "moonshot") || mv_contains(&v, "kimi")) {
return 131072;
}
return HA_CODEC_CONTEXT_WINDOW_UNKNOWN;
}
/* ---------------------------------------------------------------- */
/* UTF-8 解码(与 Go utf8.DecodeRuneInString 逐值等价) */
/* ---------------------------------------------------------------- */
/* 返回 s[0] 起始字符的字节长度(1..4)。
*
* 必须与 Go 的 utf8.DecodeRuneInString 语义一致——**包括无效序列只前进
* 1 字节**(Go 对无效/截断序列返回 RuneError 且 size=1),否则 rune 计数
* 会与 Go 分叉。这正是黄金对照测试用畸形输入能抓到的地方。
*
* remaining 是当前可读字节数。 */
static inline size_t utf8_char_len(const char *s, size_t remaining) {
unsigned char c0 = (unsigned char)s[0];
if (c0 < 0x80) {
return 1; /* ASCII */
}
if (c0 < 0xC2) {
return 1; /* 0x80..0xC1:续字节或过长编码 → Go 判无效,size=1 */
}
if (c0 < 0xE0) { /* 2 字节:0xC2..0xDF */
if (remaining < 2) {
return 1;
}
if (((unsigned char)s[1] & 0xC0) != 0x80) {
return 1;
}
return 2;
}
if (c0 < 0xF0) { /* 3 字节:0xE0..0xEF */
if (remaining < 3) {
return 1;
}
/* 用 (c & 0xC0) == 0x80 走单条 AND+CMP(而非两条范围比较),
* 并用 & 而非 && 避免短路分支——这是 CJK 主路径,须最短。 */
unsigned char c1 = (unsigned char)s[1];
unsigned char c2 = (unsigned char)s[2];
if (((c1 & 0xC0) == 0x80) & ((c2 & 0xC0) == 0x80)) {
/* 常见情形:既非 0xE0(防过长编码)也非 0xED(防代理对) */
if (c0 != 0xE0 && c0 != 0xED) {
return 3;
}
if ((c0 == 0xE0 && c1 >= 0xA0) || (c0 == 0xED && c1 <= 0x9F)) {
return 3;
}
}
return 1;
}
if (c0 < 0xF5) { /* 4 字节:0xF0..0xF4 */
if (remaining < 4) {
return 1;
}
unsigned char c1 = (unsigned char)s[1];
unsigned char c2 = (unsigned char)s[2];
unsigned char c3 = (unsigned char)s[3];
if (((c1 & 0xC0) == 0x80) & ((c2 & 0xC0) == 0x80) & ((c3 & 0xC0) == 0x80)) {
if (c0 != 0xF0 && c0 != 0xF4) {
return 4;
}
if ((c0 == 0xF0 && c1 >= 0x90) || (c0 == 0xF4 && c1 <= 0x8F)) {
return 4;
}
}
return 1;
}
return 1; /* 0xF5..0xFF:无效 */
}
/* ASCII 批量扫描:返回从 text[i] 起连续 ASCII 的字节数(扫到串尾)。
*
* ★ 字(word)级探测:一次读 8 字节,用单条掩码判断「8 字节是否全为 ASCII」。
* 逐字节比较会让 1KB ASCII 明显慢于纯 Go(后者内部有 8 字节快路径)。
* 实测:逐字节版 ascii_1k 约 2318ns(比 Go 慢 7×),改字级后大幅收敛。 */
#define HA_HIGH_BITS 0x8080808080808080ULL
static size_t ascii_run(const char *text, size_t i, size_t len) {
size_t j = i;
while (j + 8 <= len) {
uint64_t v;
memcpy(&v, text + j, 8); /* memcpy 让编译器按需生成未对齐安全加载 */
if (v & HA_HIGH_BITS) {
break;
}
j += 8;
}
while (j < len && (unsigned char)text[j] < 0x80) {
j++;
}
return j - i;
}
/* ---------------------------------------------------------------- */
/* token 估算 */
/* ---------------------------------------------------------------- */
int ha_codec_estimate_tokens(const char *text, size_t text_len) {
if (text == NULL || text_len == 0) {
return 0;
}
size_t runes = 0;
size_t i = 0;
while (i < text_len) {
if ((unsigned char)text[i] < 0x80) {
size_t n = ascii_run(text, i, text_len);
runes += n;
i += n;
} else {
i += utf8_char_len(text + i, text_len - i);
runes++;
}
}
/* 与 Go 侧一致:t = runeCount * 2;t < 1 时取 1。
* runes > 0 时 t >= 2,故只需处理溢出与下限。 */
if (runes > (size_t)0x3FFFFFFF) { /* 防 int 溢出 */
return 0x7FFFFFFF;
}
int t = (int)(runes * 2);
if (t < 1) {
return 1;
}
return t;
}
/* ---------------------------------------------------------------- */
/* 按 token 预算计算应保留的字节数 */
/* ---------------------------------------------------------------- */
size_t ha_codec_truncate_by_tokens(const char *text, size_t text_len,
int max_tokens) {
if (text == NULL || text_len == 0 || max_tokens <= 0) {
return 0;
}
/* 要保留的 rune 数(与 Go 一致:整数除法)。keep==0 时循环首轮即返回 0。 */
size_t keep = (size_t)(max_tokens / 2);
/* 提前短路:keep 个 rune 数满而串仍有剩余 ⇒ 必然截断,直接返回该字节边界,
* 不必扫完整串(长文本上的主要收益)。
* 若数完整串仍未数满 keep ⇒ 未超预算,返回全长(= 不截断)。 */
size_t runes = 0;
size_t i = 0;
while (i < text_len) {
if (runes == keep) {
return i;
}
if ((unsigned char)text[i] < 0x80) {
size_t n = ascii_run(text, i, text_len);
if (runes + n >= keep) {
/* keep 落在这批 ASCII 内:批内每字节一个 rune */
return i + (keep - runes);
}
runes += n;
i += n;
} else {
runes++;
i += utf8_char_len(text + i, text_len - i);
}
}
return text_len; /* 未超预算:整串都留 */
}
/* ---------------------------------------------------------------- */
/* ABI 自述 */
/* ---------------------------------------------------------------- */
int ha_codec_abi_version(void) {
return HA_CODEC_ABI_VERSION;
}

825
csrc/src/ha_json_scan.c Normal file
View File

@ -0,0 +1,825 @@
/*
* ha_json_scan.c — HomeAgent 内核 LLM 协议层 JSON 扫描/取值(C 实现)
*
* ============================ 性能设计(勿回退) ============================
* 1. **不 malloc**:一切结果以 span 回传,Go 侧零拷贝切片
* 2. **不 strlen**:长度由调用方传入
* 3. **不预扫**:scan 只在需要时前进一步;「找键」靠 members 迭代单趟,
* 不先扫一遍收集全部键(那会缓存踩踏 + 二次遍历)
* 4. **整数不走 strtoll**:strtoll 要 NUL 结尾或处理 locale,
* 自写定点解析只认 JSON 整数语法,顺带把溢出判掉
* 5. **字符串不建索引**:不记录转义位置。需要时按需解码
*
* 参照第一刀的教训(docs/zh/c-core/llm-orchestration-c.md §7.1):
* 初版每次调用 C.CString(malloc+拷贝)+ C 侧 strlen,单这两项就吃掉
* 82% 的时间 —— 那不是 cgo 的固有成本,是自找的。本库从设计上排除这类开销。
*
* 语义必须与 Go `encoding/json` 一致,由黄金对照测试钉死
* (真值表见 docs/zh/c-core/sse-codec-c.md §二)。
*/
#include "ha_json_scan.h"
#include <string.h>
/* ---------------------------------------------------------------- */
/* ABI 自述 */
/* ---------------------------------------------------------------- */
int ha_json_scan_abi_version(void) {
return HA_JSON_SCAN_ABI_VERSION;
}
/* ---------------------------------------------------------------- */
/* 基础工具 */
/* ---------------------------------------------------------------- */
/* JSON 空白:Go 的 encoding/json 只认这四个(不是 isspace)。
* 差一个字符就会与 Go 分叉,故显式列举而非用 ctype。 */
static int is_ws(unsigned char c) {
return c == ' ' || c == '\t' || c == '\n' || c == '\r';
}
static unsigned char ascii_lower(unsigned char c) {
return (c >= 'A' && c <= 'Z') ? (unsigned char)(c + 32) : c;
}
void ha_json_scan_init(ha_json_scan *sc, const char *s, size_t n) {
if (sc == NULL) {
return;
}
sc->s = (s != NULL) ? s : "";
sc->n = (s != NULL) ? n : 0;
sc->i = 0;
}
int ha_json_scan_ws(ha_json_scan *sc) {
if (sc == NULL) {
return 1;
}
while (sc->i < sc->n && is_ws((unsigned char)sc->s[sc->i])) {
sc->i++;
}
return (sc->i < sc->n) ? 0 : 1;
}
int ha_json_scan_eof(const ha_json_scan *sc) {
if (sc == NULL) {
return 1;
}
return (sc->i >= sc->n) ? 1 : 0;
}
/* 当前字符;到结尾返回 '\0'(0)。调用方需先判 eof。 */
static char peek(const ha_json_scan *sc) {
return (sc->i < sc->n) ? sc->s[sc->i] : '\0';
}
/* 前进一字节;越界时不动(保持 eof 语义稳定)。 */
static void bump(ha_json_scan *sc) {
if (sc->i < sc->n) {
sc->i++;
}
}
static int expect(ha_json_scan *sc, char c) {
if (ha_json_scan_ws(sc) || peek(sc) != c) {
return 0;
}
bump(sc);
return 1;
}
/* ---------------------------------------------------------------- */
/* 值扫描(skip 一个完整值) */
/* ---------------------------------------------------------------- */
static int scan_value(ha_json_scan *sc, int depth);
static int hex_val(unsigned char c);
/* 扫描字符串(含引号),出原始内容 span。
* depth 传入是因为 scan_value 会递归;字符串本身不递归但需要限额。 */
static int scan_string_raw(ha_json_scan *sc, ha_span *raw, int depth) {
if (depth > 128) {
return 0; /* 深度保险,正常文档远小于此 */
}
if (ha_json_scan_ws(sc) || peek(sc) != '"') {
return 0;
}
bump(sc); /* 开引号 */
size_t start = sc->i;
while (sc->i < sc->n) {
char c = sc->s[sc->i];
if (c == '"') {
if (raw != NULL) {
raw->p = sc->s + start;
raw->len = sc->i - start;
}
bump(sc); /* 闭引号 */
return 1;
}
if (c == '\\') {
bump(sc);
if (sc->i >= sc->n) {
return 0; /* 末尾悬空反斜杠 */
}
/* ★ 必须校验转义字符本身合法:Go 的 unquoteBytes 对未知转义
* (\q、\x、单独 \p)返回错误 ⇒ 整个 Unmarshal 失败。
* 初版只 bump 不校验,于是 `{"a":"\q"}` 被 C 判为合法,
* 而 json.Valid=false —— 黄金对照当场抓到。
* (`\u` 的 4 位十六进制在解码阶段校验:那是**值**层面的
* 错误,与扫描阶段的「转义序列形状」是两回事。) */
char e = sc->s[sc->i];
if (e != '"' && e != '\\' && e != '/' && e != 'b' && e != 'f' &&
e != 'n' && e != 'r' && e != 't' && e != 'u') {
return 0;
}
/* ★ `\u` 必须紧跟 **4 位十六进制**,且这一校验属于**扫描**阶段:
* Go 的 json.Valid 会拒绝 `{"a":"\u00"}`(不足 4 位),
* 而初版把它留到解码阶段 ⇒ scan 判合法、json.Valid 判非法,
* 黄金对照当场抓到这条分叉。
* 校验放在扫描阶段还有一个好处:畸形的 wire 数据在
* 「找键」阶段就被拒,不必等到取值。 */
if (e == 'u') {
/* 用 size_t 递推偏移,避免 int 与 size_t 混算
* (-Wconversion/-Wsign-conversion 会拦下 sign-change)。 */
if (sc->n - sc->i < 5u) {
return 0; /* 位数不足:还需 'u' 之后 4 位 */
}
for (size_t k = 1; k <= 4u; k++) {
if (hex_val((unsigned char)sc->s[sc->i + k]) < 0) {
return 0; /* 非十六进制 */
}
}
}
bump(sc); /* 被转义的字符;\u 的 4 位十六进制由上面的循环覆盖 */
continue;
}
if ((unsigned char)c < 0x20) {
return 0; /* Go 拒绝字符串里的裸控制字符 */
}
bump(sc);
}
return 0; /* 未闭合 */
}
/* 扫描字面量:true / false / null。 */
static int scan_literal(ha_json_scan *sc) {
static const char kTrue[] = "true";
static const char kFalse[] = "false";
static const char kNull[] = "null";
size_t rest = sc->n - sc->i;
const char *p = sc->s + sc->i;
if (rest >= 4 && memcmp(p, kTrue, 4) == 0) {
sc->i += 4;
return 1;
}
if (rest >= 5 && memcmp(p, kFalse, 5) == 0) {
sc->i += 5;
return 1;
}
if (rest >= 4 && memcmp(p, kNull, 4) == 0) {
sc->i += 4;
return 1;
}
return 0;
}
/* 数字:只校验**语法**(不求值)。求值由 ha_json_get_int / 调用方负责。
* 这与 Go 的分工一致:Go 在 unmarshal 时求值并做范围检查,
* 而本层的取整数是独立的一步。 */
static int scan_number(ha_json_scan *sc) {
size_t start = sc->i;
if (sc->i < sc->n && peek(sc) == '-') {
bump(sc);
}
/* 整数部分:0 或 [1-9][0-9]*(禁止前导零,与 Go 一致) */
if (sc->i >= sc->n) {
return 0;
}
if (peek(sc) == '0') {
bump(sc);
} else if (peek(sc) >= '1' && peek(sc) <= '9') {
while (sc->i < sc->n && peek(sc) >= '0' && peek(sc) <= '9') {
bump(sc);
}
} else {
return 0;
}
/* 小数部分 */
if (sc->i < sc->n && peek(sc) == '.') {
bump(sc);
if (sc->i >= sc->n || peek(sc) < '0' || peek(sc) > '9') {
return 0; /* "1." 与 "1.e3" 非法 */
}
while (sc->i < sc->n && peek(sc) >= '0' && peek(sc) <= '9') {
bump(sc);
}
}
/* 指数部分 */
if (sc->i < sc->n && (peek(sc) == 'e' || peek(sc) == 'E')) {
bump(sc);
if (sc->i < sc->n && (peek(sc) == '+' || peek(sc) == '-')) {
bump(sc);
}
if (sc->i >= sc->n || peek(sc) < '0' || peek(sc) > '9') {
return 0;
}
while (sc->i < sc->n && peek(sc) >= '0' && peek(sc) <= '9') {
bump(sc);
}
}
return (sc->i > start) ? 1 : 0;
}
/* 扫描数组/对象。用显式 depth 递归(不用堆栈,零分配)。 */
static int scan_container(ha_json_scan *sc, char open, char close, int depth) {
if (!expect(sc, open)) {
return 0;
}
if (ha_json_scan_ws(sc)) {
return 0; /* 未闭合 */
}
if (peek(sc) == close) {
bump(sc);
return 1; /* 空容器 */
}
for (;;) {
if (open == '{') {
ha_span k;
if (!scan_string_raw(sc, &k, depth + 1)) {
return 0;
}
if (!expect(sc, ':')) {
return 0;
}
}
if (!scan_value(sc, depth + 1)) {
return 0;
}
if (ha_json_scan_ws(sc)) {
return 0;
}
if (peek(sc) == ',') {
bump(sc);
continue;
}
if (peek(sc) == close) {
bump(sc);
return 1;
}
return 0; /* 缺 '}' 或多余的 ',' 之后没有键 */
}
}
static int scan_value(ha_json_scan *sc, int depth) {
if (depth > 128) {
return 0;
}
if (ha_json_scan_ws(sc)) {
return 0;
}
char c = peek(sc);
switch (c) {
case '{': return scan_container(sc, '{', '}', depth);
case '[': return scan_container(sc, '[', ']', depth);
case '"': {
ha_span tmp;
return scan_string_raw(sc, &tmp, depth);
}
case 't': case 'f': case 'n': return scan_literal(sc);
default:
if (c == '-' || (c >= '0' && c <= '9')) {
return scan_number(sc);
}
return 0;
}
}
int ha_json_skip(ha_json_scan *sc) {
if (sc == NULL) {
return 0;
}
return scan_value(sc, 0);
}
int ha_json_scan_string(ha_json_scan *sc, ha_span *raw) {
if (sc == NULL) {
return 0;
}
return scan_string_raw(sc, raw, 0);
}
/* ---------------------------------------------------------------- */
/* 顶层对象成员迭代 */
/* ---------------------------------------------------------------- */
int ha_json_members_init(ha_json_members *m, const char *s, size_t n) {
if (m == NULL) {
return 0;
}
ha_json_scan_init(&m->sc, s, n);
m->started = 0;
m->done = 0;
m->error = 0;
if (ha_json_scan_ws(&m->sc) || peek(&m->sc) != '{') {
return 0;
}
bump(&m->sc);
return 1;
}
int ha_json_members_next(ha_json_members *m, ha_span *key, ha_span *val) {
if (m == NULL || m->done) {
return 0;
}
if (ha_json_scan_ws(&m->sc)) {
m->done = 1;
m->error = 1; /* 未闭合 */
return 0;
}
if (peek(&m->sc) == '}') {
bump(&m->sc);
m->done = 1;
m->error = 0; /* 正常结束 */
return 0; /* 没有更多成员 */
}
/* ★ 不接受尾逗号:Go 的 decoder 在 ',' 之后要求必有下一个键。
* `{"a":1,}` 在 Go 侧是语法错误,故这里也必须拒绝。 */
if (m->started) {
if (peek(&m->sc) != ',') {
m->done = 1;
m->error = 1;
return 0;
}
bump(&m->sc);
if (ha_json_scan_ws(&m->sc)) {
m->done = 1;
m->error = 1;
return 0;
}
if (peek(&m->sc) == '}') {
m->done = 1;
m->error = 1; /* 尾逗号 */
return 0;
}
}
ha_span k;
if (!scan_string_raw(&m->sc, &k, 0)) {
m->done = 1;
m->error = 1;
return 0;
}
if (!expect(&m->sc, ':')) {
m->done = 1;
m->error = 1;
return 0;
}
if (ha_json_scan_ws(&m->sc)) {
m->done = 1;
m->error = 1;
return 0;
}
/* ★ 就地完整跳过一个值,得到它的精确 span。
* 这样「返回 1」就蕴含「该成员良构」,且游标已推进到值之后。 */
size_t vstart = m->sc.i;
if (!scan_value(&m->sc, 0)) {
m->done = 1;
m->error = 1;
return 0;
}
size_t vend = m->sc.i;
m->started = 1;
if (key != NULL) {
*key = k;
}
if (val != NULL) {
val->p = m->sc.s + vstart;
val->len = vend - vstart;
}
return 1;
}
int ha_json_members_complete(const ha_json_members *m) {
if (m == NULL) {
return 0;
}
return (m->done && !m->error) ? 1 : 0;
}
int ha_json_key_eq(ha_span key, const char *name) {
if (name == NULL) {
return 0;
}
size_t nl = 0;
while (name[nl] != '\0') {
nl++;
}
if (key.len != nl) {
return 0;
}
for (size_t i = 0; i < nl; i++) {
if (ascii_lower((unsigned char)key.p[i]) !=
ascii_lower((unsigned char)name[i])) {
return 0;
}
}
return 1;
}
/* ---------------------------------------------------------------- */
/* 字符串解码 */
/* ---------------------------------------------------------------- */
/* U+FFFD 的 UTF-8 编码(Go 对非法字节的替换目标)。 */
static const char kReplacement[3] = { (char)0xEF, (char)0xBF, (char)0xBD };
/* 十六进制值;非十六进制返回 -1。 */
static int hex_val(unsigned char c) {
if (c >= '0' && c <= '9') return c - '0';
if (c >= 'a' && c <= 'f') return c - 'a' + 10;
if (c >= 'A' && c <= 'F') return c - 'A' + 10;
return -1;
}
/* 把码点编码成 UTF-8 写给 sink。返回写入字节数。 */
static size_t emit_rune(unsigned long cp, ha_json_sink sink, void *ctx) {
unsigned char buf[4];
size_t len;
if (cp < 0x80) {
buf[0] = (unsigned char)cp;
len = 1;
} else if (cp < 0x800) {
buf[0] = (unsigned char)(0xC0 | (cp >> 6));
buf[1] = (unsigned char)(0x80 | (cp & 0x3F));
len = 2;
} else if (cp < 0x10000) {
buf[0] = (unsigned char)(0xE0 | (cp >> 12));
buf[1] = (unsigned char)(0x80 | ((cp >> 6) & 0x3F));
buf[2] = (unsigned char)(0x80 | (cp & 0x3F));
len = 3;
} else {
buf[0] = (unsigned char)(0xF0 | (cp >> 18));
buf[1] = (unsigned char)(0x80 | ((cp >> 12) & 0x3F));
buf[2] = (unsigned char)(0x80 | ((cp >> 6) & 0x3F));
buf[3] = (unsigned char)(0x80 | (cp & 0x3F));
len = 4;
}
sink(ctx, (const char *)buf, len);
return len;
}
/* 解码一段 raw(已定位转义与续字节的边界)。
*
* 非法 UTF-8 语义必须与 Go 逐字节一致:
* Go 的 unquoteBytes 遇到非法序列时,把**能构成前缀的最长合法部分**先解出,
* 再对**第一个坏字节**产出单个 U+FFFD,然后从坏字节**之后**继续。
* 即:一个坏字节 = 一个 U+FFFD(不是整个序列变一个)。
* 典型:`\xff\xfe` → 两个 U+FFFD(真值表 §2.8 实测确认)。
*/
static size_t decode_body(ha_span raw, ha_json_sink sink, void *ctx, int *err) {
size_t out = 0;
size_t i = 0;
*err = 0;
while (i < raw.len) {
unsigned char c = (unsigned char)raw.p[i];
/* --- 转义 --- */
if (c == '\\') {
if (i + 1 >= raw.len) {
*err = 1;
return out;
}
unsigned char e = (unsigned char)raw.p[i + 1];
switch (e) {
case '"': sink(ctx, "\"", 1); out += 1; i += 2; continue;
case '\\': sink(ctx, "\\", 1); out += 1; i += 2; continue;
case '/': sink(ctx, "/", 1); out += 1; i += 2; continue;
case 'b': sink(ctx, "\b", 1); out += 1; i += 2; continue;
case 'f': sink(ctx, "\f", 1); out += 1; i += 2; continue;
case 'n': sink(ctx, "\n", 1); out += 1; i += 2; continue;
case 'r': sink(ctx, "\r", 1); out += 1; i += 2; continue;
case 't': sink(ctx, "\t", 1); out += 1; i += 2; continue;
case 'u': {
/* 需要 4 位十六进制:i+2 .. i+5 */
if (i + 6 > raw.len) {
*err = 1;
return out;
}
int h0 = hex_val((unsigned char)raw.p[i + 2]);
int h1 = hex_val((unsigned char)raw.p[i + 3]);
int h2 = hex_val((unsigned char)raw.p[i + 4]);
int h3 = hex_val((unsigned char)raw.p[i + 5]);
if (h0 < 0 || h1 < 0 || h2 < 0 || h3 < 0) {
*err = 1;
return out;
}
unsigned long cp = (unsigned long)((h0 << 12) | (h1 << 8) |
(h2 << 4) | h3);
size_t adv = 6;
if (cp >= 0xD800 && cp <= 0xDBFF) {
/* 高代理:尝试与紧随的 \uDC00-\uDFFF 合成 4 字节 rune。
*
* ★ 必须用 combined 标志,而不是「合成成功就直接落到底部」:
* 本块末尾有一段**无条件的** replacement 发射(处理合成
* 失败的情形)。若成功的分支只设 cp/adv 而不跳过那一段,
* 会先把合成好的码点丢掉、再发一个 U+FFFD ——
* 实测症状:`\ud83d\ude00`(😀)得到 `\xef\xbf\xbd\xef\xbf\xbd`。
* 这个 bug 只有**真的代理对**才会触发(`\u4f60` 这类
* 非代理码点根本不进本块),是黄金对照最容易漏的一类。
*
* 下界必须是 'i + 6 < raw.len'(而非一次判 i+12 <= len):
* 后者会连带拒绝「合法高代理位于字符串末尾」的正确输入。 */
int combined = 0;
if (i + 6 < raw.len && raw.p[i + 6] == '\\' &&
raw.p[i + 7] == 'u') {
int g0 = hex_val((unsigned char)raw.p[i + 8]);
int g1 = hex_val((unsigned char)raw.p[i + 9]);
int g2 = hex_val((unsigned char)raw.p[i + 10]);
int g3 = hex_val((unsigned char)raw.p[i + 11]);
if (g0 >= 0 && g1 >= 0 && g2 >= 0 && g3 >= 0) {
unsigned long lo = (unsigned long)(
(g0 << 12) | (g1 << 8) | (g2 << 4) | g3);
if (lo >= 0xDC00 && lo <= 0xDFFF) {
cp = 0x10000UL + ((cp - 0xD800UL) << 10) +
(lo - 0xDC00UL);
adv = 12;
combined = 1;
}
}
}
if (!combined) {
/* 高代理后面不是合法低代理:发一个 U+FFFD,
* 只消费掉这个 6 字节 \uXXXX,让后面的内容按原样
* 继续解析(与 Go unquote 的行为一致)。 */
sink(ctx, kReplacement, 3);
out += 3;
i += adv;
continue;
}
}
if (cp >= 0xDC00 && cp <= 0xDFFF) {
/* 孤立低代理 → U+FFFD */
sink(ctx, kReplacement, 3);
out += 3;
i += 6;
continue;
}
out += emit_rune(cp, sink, ctx);
i += adv;
continue;
}
default:
/* Go 对未知转义(如 \q)报错 */
*err = 1;
return out;
}
}
/* --- 普通字节 / 多字节序列 --- */
if (c < 0x80) {
char ch = (char)c;
sink(ctx, &ch, 1);
out += 1;
i++;
continue;
}
/* 尝试解析一个合法多字节序列。
*
* ★ 过长编码(overlong)检查**必须在续字节全部并入之后**做。
* 初版把它写在这里、只用首字节的 cp:
* else if ((b0 & 0xF0) == 0xE0) { need = 3; cp = b0 & 0x0Fu; }
* if (need == 3 && cp < 0x800) valid = 0; // ← 此时 cp 只有首字节的位
* 而 0xE4 恰好满足 0x0F 掩码 ⇒ cp = 4 ⇒ 4 < 0x800 ⇒ 误判非法
* ⇒ 正常的「你」(e4 bd a0)被逐字节换成 6 个 U+FFFD(实测症状)。
* 过长的真实判据是「完整码点 < 该长度的最小值」,
* 即 0xC0/0x80、0xE0 0x80、0xF0 0x80/0x90 这几类前缀。 */
size_t need;
unsigned long cp;
unsigned char b0 = c;
if ((b0 & 0xE0) == 0xC0) { need = 2; cp = b0 & 0x1Fu; }
else if ((b0 & 0xF0) == 0xE0) { need = 3; cp = b0 & 0x0Fu; }
else if ((b0 & 0xF8) == 0xF0) { need = 4; cp = b0 & 0x07u; }
else { need = 0; cp = 0; }
int valid = (need != 0);
if (valid) {
for (size_t k = 1; k < need; k++) {
if (i + k >= raw.len) { valid = 0; break; }
unsigned char nb = (unsigned char)raw.p[i + k];
if ((nb & 0xC0) != 0x80) { valid = 0; break; }
cp = (cp << 6) | (unsigned long)(nb & 0x3F);
}
}
if (valid) {
/* 过长编码:按**完整码点**比该长度的最小合法值
* (2B:0x80 / 3B:0x800 / 4B:0x10000) */
if (need == 2 && cp < 0x80) valid = 0;
if (need == 3 && cp < 0x800) valid = 0;
if (need == 4 && cp < 0x10000) valid = 0;
/* 代理区编码(CESU-8 / WTF-8)Go 判非法 */
if (cp >= 0xD800 && cp <= 0xDFFF) valid = 0;
if (cp > 0x10FFFF) valid = 0;
}
if (valid) {
sink(ctx, raw.p + i, need);
out += need;
i += need;
continue;
}
/* 非法:单个字节 → 一个 U+FFFD,然后继续(与 Go 逐字节一致) */
sink(ctx, kReplacement, 3);
out += 3;
i++;
}
return out;
}
int ha_json_decode_string(ha_span raw, ha_json_sink sink, void *ctx,
size_t *out_len) {
if (sink == NULL) {
return 0;
}
int err = 0;
size_t n = decode_body(raw, sink, ctx, &err);
if (out_len != NULL) {
*out_len = n;
}
return err ? 0 : 1;
}
/* ---------------------------------------------------------------- */
/* 写入缓冲的 sink */
/* ---------------------------------------------------------------- */
typedef struct {
char *out;
size_t cap;
size_t len;
} buf_sink;
static void buf_write(void *ctx, const char *b, size_t n) {
buf_sink *s = (buf_sink *)ctx;
/* 缓冲不足时,**绝不再往后写**,并标记溢出(len > cap 即可辨认)。
*
* ★ 契约是「不越界写」,不是「一个字节都不写」:本函数是流式的,
* 写到这里才知道放不下,之前已写出的部分无法撤销。
* 调用方拿到 (size_t)-1 时**必须丢弃整个结果**(Go 侧就是这么做的)。
* 若真需要 all-or-nothing,调用方应先测得长度再分配(两趟)。
* 这个取舍是有意的:单趟更快,而丢弃结果对调用方是廉价的。 */
if (s->len + n > s->cap) {
s->len = s->cap + 1; /* 标记溢出 */
return;
}
memcpy(s->out + s->len, b, n);
s->len += n;
}
size_t ha_json_decode_string_into(ha_span raw, char *out, size_t out_cap) {
if (out == NULL || out_cap == 0) {
return (size_t)-1;
}
buf_sink s;
s.out = out;
s.cap = out_cap - 1; /* 留一位给结尾 NUL */
s.len = 0;
int err = 0;
(void)decode_body(raw, buf_write, &s, &err);
if (err || s.len > s.cap) {
return (size_t)-1;
}
out[s.len] = '\0';
return s.len;
}
/* ---------------------------------------------------------------- */
/* 整数 */
/* ---------------------------------------------------------------- */
int ha_json_get_int(ha_span raw, long long *out) {
if (raw.len == 0 || out == NULL) {
return 0;
}
size_t i = 0;
int neg = 0;
if (raw.p[0] == '-') {
neg = 1;
i = 1;
if (raw.len == 1) {
return 0;
}
}
/* 只接受 **JSON 整数语法**:可选 '-' + (0 | [1-9][0-9]*)。
* 小数点 / 指数一律判「不是整数」,由调用方按 Go 的
* 「类型不匹配 ⇒ 整块作废」语义处理。
*
* ★ 必须禁前导零:JSON 里 `007` / `00` 是**非法数字**,
* 而 strconv.ParseInt 会接受它。若这里跟着接受,
* 就会出现「C 认得、json.Unmarshal 报错」的分叉 ——
* 黄金对照当场抓到(实测分歧:"007"、"00")。
* 本层的职责是回答「这是不是 JSON 整数」,不是「能不能转成数字」。 */
if (raw.p[i] == '0' && raw.len - i > 1) {
return 0; /* 前导零:00 / 01 / 007 均非法 */
}
for (size_t k = i; k < raw.len; k++) {
if (raw.p[k] < '0' || raw.p[k] > '9') {
return 0;
}
}
unsigned long long acc = 0;
const unsigned long long limit =
neg ? 9223372036854775807ULL + 1ULL : 9223372036854775807ULL;
for (size_t k = i; k < raw.len; k++) {
unsigned d = (unsigned)(raw.p[k] - '0');
if (acc > (limit - d) / 10ULL) {
return 0; /* 溢出(与 Go 报错等价) */
}
acc = acc * 10ULL + d;
}
if (neg) {
*out = (acc == 9223372036854775808ULL)
? (-9223372036854775807LL - 1)
: -(long long)acc;
} else {
*out = (long long)acc;
}
return 1;
}
/* ---------------------------------------------------------------- */
/* 便捷取值 */
/* ---------------------------------------------------------------- */
/* 在对象里定位键 name 的值 span。
*
* 找到返回 1 且 *val 覆盖该值的原始字节(未解码);未找到 / 语法错返回 0。
* 重复键取**最后一次**(与 Go 的后者胜一致)。
*
* 实现要点:members 迭代器只报「值的起始位置」,值本身由本函数用
* ha_json_skip 消费并算出 span —— 这样两种便捷取值共用同一套定位逻辑,
* 不会因各自实现而分叉。 */
static int find_value(ha_span obj, const char *name, ha_span *val) {
ha_json_members m;
if (!ha_json_members_init(&m, obj.p, obj.len)) {
return 0;
}
ha_span key;
ha_span v;
int found = 0;
ha_span last = { NULL, 0 };
while (ha_json_members_next(&m, &key, &v)) {
if (ha_json_key_eq(key, name)) {
last = v;
found = 1; /* 重复键后者胜:继续扫,只保留最后一次 */
}
}
/* ★ 严格性:畸形输入必须判「找不到键」——
* Go 侧语法错误会让 json.Unmarshal 失败、整块作废,
* 若这里放宽成「扫到哪算哪」,就会比 Go 宽松(见真值表 §2.2)。 */
if (!ha_json_members_complete(&m)) {
return 0;
}
if (found && val != NULL) {
*val = last;
}
return found;
}
size_t ha_json_object_get_string(ha_span obj, const char *name,
char *out, size_t out_cap) {
if (out == NULL || out_cap == 0) {
return (size_t)-1;
}
ha_span val;
if (!find_value(obj, name, &val)) {
return (size_t)-1;
}
/* 只接受字符串值;其他类型视为「取不到」(类型判断由调用方按
* Go 的 interface{}/强类型语义决定,见 sse-codec-c.md §2.2) */
ha_json_scan sc;
ha_json_scan_init(&sc, val.p, val.len);
ha_span raw;
if (!ha_json_scan_string(&sc, &raw)) {
return (size_t)-1;
}
return ha_json_decode_string_into(raw, out, out_cap);
}
int ha_json_object_get_int(ha_span obj, const char *name, long long *out) {
if (out == NULL) {
return 0;
}
ha_span val;
if (!find_value(obj, name, &val)) {
return 0;
}
return ha_json_get_int(val, out);
}

673
csrc/src/ha_sse.c Normal file
View File

@ -0,0 +1,673 @@
/*
* ha_sse.c — LLM 流式协议(SSE 分块)结构导航辅助层
*
* 语义与理由见 include/ha_sse.h。本文件被 C 门禁全量覆盖
* (告警 / ASan+UBSan / arm64 交叉编译 / libFuzzer),故**不放**在
* Go 的 cgo 前言里 —— 前言里的 C 代码逃出全部检查。
*/
#include "ha_sse.h"
#include <string.h>
int ha_sse_abi_version(void) {
return HA_SSE_ABI_VERSION;
}
int ha_sse_obj_find(const ha_span *obj, const char *key, size_t keylen,
ha_span *out, int *dup) {
ha_json_members m;
ha_span k, v;
int hit = 0;
if (obj == NULL || key == NULL || out == NULL || dup == NULL) {
return 0;
}
*dup = 0;
out->p = NULL;
out->len = 0;
if (keylen == 0) {
return 0;
}
if (!ha_json_members_init(&m, obj->p, obj->len)) {
return -1;
}
while (ha_json_members_next(&m, &k, &v)) {
/* ★ 精确比较(不做大小写折叠):与 Go 的 map key 语义一致。
* §5.4-1 实测 {"TEXT":"up"} 取不到 text。 */
if (k.len == keylen && memcmp(k.p, key, keylen) == 0) {
if (hit) {
*dup = 1; /* 重复键:调用方整体回退 Go */
}
hit = 1;
*out = v; /* 后者胜 */
}
}
if (!ha_json_members_complete(&m)) {
return -1; /* 对象畸形 */
}
return hit;
}
/* 单字节 ASCII 小写折叠(非 ASCII 原样,与 Go 对 ASCII 字段名的行为一致)。 */
static unsigned char sse_lower(unsigned char c) {
return (c >= 'A' && c <= 'Z') ? (unsigned char)(c + 32) : c;
}
int ha_sse_obj_find_ci(const ha_span *obj, const char *key, size_t keylen,
ha_span *out, int *dup) {
ha_json_members m;
ha_span k, v;
int hit = 0;
if (obj == NULL || key == NULL || out == NULL || dup == NULL) {
return 0;
}
*dup = 0;
out->p = NULL;
out->len = 0;
if (keylen == 0) {
return 0;
}
if (!ha_json_members_init(&m, obj->p, obj->len)) {
return -1;
}
while (ha_json_members_next(&m, &k, &v)) {
if (k.len == keylen) {
size_t j = 0;
while (j < keylen &&
sse_lower((unsigned char)k.p[j]) ==
sse_lower((unsigned char)key[j])) {
j++;
}
if (j == keylen) {
if (hit) {
*dup = 1;
}
hit = 1;
*out = v;
}
}
}
if (!ha_json_members_complete(&m)) {
return -1;
}
return hit;
}
int ha_sse_root_object(const ha_span *doc) {
ha_json_scan sc;
if (doc == NULL || doc->p == NULL || doc->len == 0) {
return 0;
}
ha_json_scan_init(&sc, doc->p, doc->len);
(void)ha_json_scan_ws(&sc);
if (ha_json_scan_eof(&sc) || sc.s[sc.i] != '{') {
return 0; /* 顶层非对象:Go 的 Unmarshal 进 struct 会失败 */
}
if (!ha_json_skip(&sc)) {
return 0;
}
/* 尾部只允许空白 —— 复刻 json.Unmarshal 对 trailing garbage 的拒绝 */
(void)ha_json_scan_ws(&sc);
return ha_json_scan_eof(&sc) ? 1 : 0;
}
int ha_sse_arr_first(const ha_span *arr, ha_span *out) {
ha_json_scan sc;
size_t start;
if (arr == NULL || out == NULL) {
return 0;
}
out->p = NULL;
out->len = 0;
if (arr->p == NULL || arr->len == 0) {
return 0;
}
/* ★ 游标的 base 始终是 arr->p,中途只推进 i。
*
* 初版在这里犯过一个「重新 init 到 sc.s + sc.i」的错:那样 base 变了,
* 随后的 start = sc.i 变成 0,out->p = arr->p + 0 ⇒ **返回的是数组本身**
* 而不是第一个元素。症状是上层的 fastChoice 拿到 firstByte=='[' 直接回退,
* 表现为「快速路径永远不生效」——
* 而如果只看「结果与 Go 一致」,这个 bug 会**完全隐形**(回退总是正确)。
*
* ★ 这正是「优化是否真的生效」必须单独断言的原因:
* 等价性测试无法发现「一直回退」。
*/
ha_json_scan_init(&sc, arr->p, arr->len);
(void)ha_json_scan_ws(&sc);
if (ha_json_scan_eof(&sc) || sc.s[sc.i] != '[') {
return -1;
}
sc.i++; /* 跳过 '[' */
(void)ha_json_scan_ws(&sc);
if (ha_json_scan_eof(&sc) || sc.s[sc.i] == ']') {
return 0; /* 空数组 */
}
start = sc.i;
if (!ha_json_skip(&sc)) {
return -1;
}
out->p = arr->p + start;
out->len = sc.i - start;
return 1;
}
int ha_sse_stringify(const ha_span *val, char *out, size_t cap, size_t *outlen) {
size_t len = 0;
ha_json_scan sc;
ha_span raw;
if (val == NULL || out == NULL || outlen == NULL ||
val->p == NULL || val->len == 0) {
return 0;
}
*outlen = 0;
/* 上界:每个输入字节最坏变 3 字节 U+FFFD。不足则交回 Go 走
* json.Unmarshal(宁可慢也不截断)。 */
if (cap < val->len * 3u + 4u) {
return 0;
}
if (val->p[0] == '"') {
ha_json_scan_init(&sc, val->p, val->len);
if (!ha_json_scan_string(&sc, &raw)) {
return 0;
}
{
size_t n = ha_json_decode_string_into(raw, out, cap);
if (n == (size_t)-1) {
return 0;
}
*outlen = n;
return 1;
}
}
if (val->p[0] == '[') {
ha_json_scan_init(&sc, val->p, val->len);
(void)ha_json_scan_ws(&sc);
sc.i++; /* 跳过 '[' */
for (;;) {
size_t start;
ha_span elem;
(void)ha_json_scan_ws(&sc);
if (ha_json_scan_eof(&sc) || sc.s[sc.i] == ']') {
break;
}
start = sc.i;
if (!ha_json_skip(&sc)) {
return 0;
}
elem.p = val->p + start;
elem.len = sc.i - start;
/* 只有对象元素才可能有 text(§5.4-2:其余静默跳过) */
if (elem.len > 0 && elem.p[0] == '{') {
ha_span txt;
int dup = 0;
int rc = ha_sse_obj_find(&elem, "text", 4, &txt, &dup);
if (dup) {
return 0; /* 重复 text 键 ⇒ 交回 Go(合并语义) */
}
/* 只有字符串形态的 text 才取(§5.4-3) */
if (rc == 1 && txt.len > 0 && txt.p[0] == '"') {
ha_json_scan ts;
ha_span traw;
size_t n;
ha_json_scan_init(&ts, txt.p, txt.len);
if (!ha_json_scan_string(&ts, &traw)) {
return 0;
}
/* cap-len 已保证至少 1 字节可用(含结尾 NUL) */
n = ha_json_decode_string_into(traw, out + len, cap - len);
if (n == (size_t)-1) {
return 0;
}
len += n;
}
}
(void)ha_json_scan_ws(&sc);
if (ha_json_scan_eof(&sc)) {
break;
}
if (sc.s[sc.i] == ',') {
sc.i++;
continue;
}
if (sc.s[sc.i] == ']') {
break;
}
return 0; /* 畸形数组 */
}
*outlen = len;
return 1;
}
/* 对象 / 数字 / true / false / null ⇒ 需 json.Marshal 重新编码(§5.2) */
return 0;
}
int ha_sse_arg_string(const ha_span *val, char *out, size_t cap, size_t *outlen) {
ha_json_scan sc;
ha_span raw;
size_t n;
if (val == NULL || out == NULL || outlen == NULL ||
val->p == NULL || val->len == 0) {
return 0;
}
*outlen = 0;
if (val->p[0] != '"') {
return 0; /* 非字符串:交回 Go(需 json.Marshal 重新编码) */
}
if (cap < val->len * 3u + 4u) {
return 0;
}
ha_json_scan_init(&sc, val->p, val->len);
if (!ha_json_scan_string(&sc, &raw)) {
return 0;
}
n = ha_json_decode_string_into(raw, out, cap);
if (n == (size_t)-1) {
return 0;
}
*outlen = n;
return 1;
}
/* ==================================================================== */
/* 批量定位:一次调用返回全部字段 */
/* ==================================================================== */
static int scan_first_and_count(const ha_span *arr, ha_span *first, int *count);
static int chunk_choice_dispatch(ha_span choice, ha_chunk_out *out);
static int chunk_delta_dispatch(ha_span delta, ha_chunk_out *out, int *dup);
static void slot_reset(ha_chunk_slot *s) {
s->span.p = NULL;
s->span.len = 0;
s->kind = HA_CHUNK_KIND_ABSENT;
}
static void chunk_out_reset(ha_chunk_out *o) {
size_t i;
for (i = 0; i < (size_t)HA_CHUNK_SLOT_COUNT; i++) {
slot_reset(&o->slot[i]);
}
o->content_off = 0; o->content_len = 0;
o->reasoning_off = 0; o->reasoning_len = 0;
o->finish_off = 0; o->finish_len = 0;
o->choices_span.p = NULL;
o->choices_span.len = 0;
o->has_choices = 0;
o->choices_kind = HA_CHUNK_KIND_ABSENT;
o->choices_count = 0;
o->choice0_kind = HA_CHUNK_KIND_ABSENT;
}
/* 键名比较:大小写不敏感(struct 字段语义)。
* ★ 为什么不直接用 ha_json_key_eq:那个接收 ha_span,而这里要按
* 已知长度比较(省掉 strlen)—— 且必须与 Go 对 struct 字段的匹配一致。 */
static int ci_eq(const char *p, const char *name, size_t n) {
size_t i;
for (i = 0; i < n; i++) {
if (sse_lower((unsigned char)p[i]) != sse_lower((unsigned char)name[i])) {
return 0;
}
}
return 1;
}
static int kind_of(const ha_span *v) {
if (v == NULL || v->p == NULL || v->len == 0) {
return HA_CHUNK_KIND_ABSENT;
}
switch (v->p[0]) {
case '"': return HA_CHUNK_KIND_STRING;
case '{': return HA_CHUNK_KIND_OBJECT;
case '[': return HA_CHUNK_KIND_ARRAY;
case 'n': return HA_CHUNK_KIND_NULL;
default: return HA_CHUNK_KIND_OTHER;
}
}
/* 把字符串值解码进 sbuf 的 [off,off+len)。返回 0 失败(空间不足/语法错)。 */
static int emit_decoded(ha_span val, char *sbuf, size_t scap, size_t *off,
size_t *outlen) {
ha_json_scan sc;
ha_span raw;
size_t n;
*off = 0;
*outlen = 0;
ha_json_scan_init(&sc, val.p, val.len);
if (!ha_json_scan_string(&sc, &raw)) {
return 0;
}
/* 上界检查:每个输入字节最坏变 3 字节 U+FFFD */
if (scap < raw.len * 3u + 4u) {
return 0;
}
n = ha_json_decode_string_into(raw, sbuf, scap);
if (n == (size_t)-1) {
return 0;
}
*off = 0;
*outlen = n;
return 1;
}
/*
* 顶层单趟分派:遍历成员表一次,按名字分派到对应槽位。
* 顶层键(choices/usage)是 **struct 字段** ⇒ 大小写不敏感。
* 返回 0 = 正常(即使有重复键,dup 由调用方检查);-1 = 畸形。
*/
static int chunk_top_dispatch(ha_span root, ha_chunk_out *out, int *dup) {
ha_json_members m;
ha_span k, v;
ha_span el_tmp;
int r;
*dup = 0;
if (!ha_json_members_init(&m, root.p, root.len)) {
return -1;
}
while (ha_json_members_next(&m, &k, &v)) {
int t = kind_of(&v);
if (k.len == 7 && ci_eq(k.p, "choices", 7)) {
if (out->choices_kind != HA_CHUNK_KIND_ABSENT) {
*dup = 1; /* 重复键:字段级合并语义 ⇒ 交回 Go */
}
out->has_choices = (t != HA_CHUNK_KIND_ABSENT &&
t != HA_CHUNK_KIND_NULL) ? 1 : 0;
out->choices_kind = t;
out->choices_span = v;
if (t == HA_CHUNK_KIND_ARRAY) {
/* 一趟同时得出「首元素 span」与「元素个数」。
* ★ 初版为了拿个数先把整个数组扫一遍、再调 ha_sse_arr_first
* 重新扫第二遍 —— 而单趟成员遍历实测 107ns,两趟就是白扔 100ns+。
*/
if (scan_first_and_count(&v, &el_tmp, &out->choices_count) != 0) {
return -1;
}
if (out->choices_count > 0) {
out->choice0_span = el_tmp;
}
}
continue;
}
if (k.len == 5 && ci_eq(k.p, "usage", 5)) {
if (out->slot[HA_CHUNK_SLOT_USAGE].kind != HA_CHUNK_KIND_ABSENT) {
*dup = 1;
}
out->slot[HA_CHUNK_SLOT_USAGE].span = v;
out->slot[HA_CHUNK_SLOT_USAGE].kind = t;
continue;
}
/* 其余顶层键(id/object/created/model/system_fingerprint…)一律忽略。
* ★ Go 侧 struct 未声明 ⇒ 忽略;没有「类型不符」的可能。 */
}
r = ha_json_members_complete(&m) ? 0 : -1;
return r;
}
/* 一趟取数组的首元素 span 与元素个数。
* 返回 0 成功;非 0 表示数组畸形。
* ★ 超过 2 个元素即停止计数并置 *count = 2(调用方一律回退),
* 这样超大数组不会白扫 —— 而 Go 侧那种输入压根不该走快速路径。 */
static int scan_first_and_count(const ha_span *arr, ha_span *first, int *count) {
ha_json_scan sc;
int n = 0;
first->p = NULL;
first->len = 0;
ha_json_scan_init(&sc, arr->p, arr->len);
(void)ha_json_scan_ws(&sc);
if (ha_json_scan_eof(&sc) || sc.s[sc.i] != '[') {
return -1;
}
sc.i++;
for (;;) {
size_t start;
(void)ha_json_scan_ws(&sc);
if (ha_json_scan_eof(&sc) || sc.s[sc.i] == ']') {
break;
}
start = sc.i;
if (!ha_json_skip(&sc)) {
return -1;
}
if (n == 0) {
first->p = arr->p + start;
first->len = sc.i - start;
}
n++;
if (n >= 2) {
/* 已知 >1:调用方必然回退,无需继续扫 */
*count = 2;
return 0;
}
(void)ha_json_scan_ws(&sc);
if (ha_json_scan_eof(&sc)) {
return -1;
}
if (sc.s[sc.i] == ',') {
sc.i++;
continue;
}
if (sc.s[sc.i] == ']') {
break;
}
return -1;
}
*count = n;
return 0;
}
/* choice0 内的单趟分派:delta + finish_reason(struct 字段 ⇒ CI)。
* 返回 0 正常;非 0 = 畸形或重复键。 */
static int chunk_choice_dispatch(ha_span choice, ha_chunk_out *out) {
ha_json_members cm;
ha_span ck, cv;
if (!ha_json_members_init(&cm, choice.p, choice.len)) {
return -1;
}
while (ha_json_members_next(&cm, &ck, &cv)) {
int t = kind_of(&cv);
if (ck.len == 5 && ci_eq(ck.p, "delta", 5)) {
if (out->slot[HA_CHUNK_SLOT_DELTA].kind != HA_CHUNK_KIND_ABSENT) {
return -1; /* 重复键 */
}
out->slot[HA_CHUNK_SLOT_DELTA].span = cv;
out->slot[HA_CHUNK_SLOT_DELTA].kind = t;
continue;
}
if (ck.len == 13 && ci_eq(ck.p, "finish_reason", 13)) {
if (out->slot[HA_CHUNK_SLOT_FINISH_REASON].kind != HA_CHUNK_KIND_ABSENT) {
return -1;
}
out->slot[HA_CHUNK_SLOT_FINISH_REASON].span = cv;
out->slot[HA_CHUNK_SLOT_FINISH_REASON].kind = t;
continue;
}
}
return ha_json_members_complete(&cm) ? 0 : -1;
}
/* delta 内单趟分派。delta 是 **struct** ⇒ 字段名大小写不敏感。 */
static int chunk_delta_dispatch(ha_span delta, ha_chunk_out *out, int *dup) {
ha_json_members m;
ha_span k, v;
*dup = 0;
if (!ha_json_members_init(&m, delta.p, delta.len)) {
return -1;
}
while (ha_json_members_next(&m, &k, &v)) {
int t = kind_of(&v);
if (k.len == 7 && ci_eq(k.p, "content", 7)) {
if (out->slot[HA_CHUNK_SLOT_CONTENT].kind != HA_CHUNK_KIND_ABSENT) {
*dup = 1;
}
out->slot[HA_CHUNK_SLOT_CONTENT].span = v;
out->slot[HA_CHUNK_SLOT_CONTENT].kind = t;
continue;
}
if (k.len == 17 && ci_eq(k.p, "reasoning_content", 17)) {
if (out->slot[HA_CHUNK_SLOT_REASONING].kind != HA_CHUNK_KIND_ABSENT) {
*dup = 1;
}
out->slot[HA_CHUNK_SLOT_REASONING].span = v;
out->slot[HA_CHUNK_SLOT_REASONING].kind = t;
continue;
}
if (k.len == 10 && ci_eq(k.p, "tool_calls", 10)) {
if (out->slot[HA_CHUNK_SLOT_TOOL_CALLS].kind != HA_CHUNK_KIND_ABSENT) {
*dup = 1;
}
out->slot[HA_CHUNK_SLOT_TOOL_CALLS].span = v;
out->slot[HA_CHUNK_SLOT_TOOL_CALLS].kind = t;
continue;
}
}
return ha_json_members_complete(&m) ? 0 : -1;
}
int ha_sse_chunk_locate(const char *data, size_t len, ha_chunk_out *out,
char *sbuf, size_t scap, size_t *sused) {
ha_span root;
int dup = 0;
ha_span el, v;
if (out == NULL || sused == NULL) {
return HA_CHUNK_FALLBACK;
}
chunk_out_reset(out);
*sused = 0;
if (data == NULL || len == 0) {
return HA_CHUNK_FALLBACK;
}
root.p = data;
root.len = len;
/* 顶层必须是「恰好一个」良构对象(含尾部残留检查) */
if (!ha_sse_root_object(&root)) {
return HA_CHUNK_FALLBACK;
}
if (chunk_top_dispatch(root, out, &dup) != 0) {
return HA_CHUNK_FALLBACK;
}
if (dup) {
return HA_CHUNK_FALLBACK; /* §5.1 字段级合并 */
}
/* ---- choices[0] ---- */
if (out->choices_kind == HA_CHUNK_KIND_ARRAY) {
if (out->choices_count > 1) {
/* Go 侧会解析**全部**元素;本层只认 [0],其余元素可能类型不符
* 而让 Go 整块作废 ⇒ 无法保证等价,必须回退。 */
return HA_CHUNK_FALLBACK;
}
if (out->choices_count == 0) {
out->choice0_kind = HA_CHUNK_KIND_ABSENT;
} else {
if (ha_sse_arr_first(&out->choices_span, &el) != 1) {
return HA_CHUNK_FALLBACK;
}
out->choice0_kind = kind_of(&el);
if (out->choice0_kind != HA_CHUNK_KIND_OBJECT) {
/* Go 侧是 []struct:元素非对象 ⇒ 整块作废 */
return HA_CHUNK_TYPE_FAIL;
}
/* 元素内的 delta / finish_reason(struct 字段 ⇒ CI),**一趟**取完。
* ★ 初版这里对 choices 数组做了「数个数 + 取首元素」两趟、
* 又在 choice0 内单独跑一趟 members —— 合计 3 趟。
*/
{
if (chunk_choice_dispatch(el, out) != 0) {
return HA_CHUNK_FALLBACK;
}
}
}
}
/* ---- delta 内分派 ---- */
if (out->slot[HA_CHUNK_SLOT_DELTA].kind == HA_CHUNK_KIND_OBJECT) {
v = out->slot[HA_CHUNK_SLOT_DELTA].span;
if (chunk_delta_dispatch(v, out, &dup) != 0) {
return HA_CHUNK_FALLBACK;
}
if (dup) {
return HA_CHUNK_FALLBACK;
}
} else if (out->slot[HA_CHUNK_SLOT_DELTA].kind == HA_CHUNK_KIND_OTHER) {
/* delta 非对象:Go 侧 Unmarshal 到 struct 会失败 */
return HA_CHUNK_TYPE_FAIL;
}
/* ---- content:字符串直接解码;文本数组走 stringify ---- */
{
ha_chunk_slot *cs = &out->slot[HA_CHUNK_SLOT_CONTENT];
if (cs->kind == HA_CHUNK_KIND_STRING) {
if (!emit_decoded(cs->span, sbuf, scap, &out->content_off,
&out->content_len)) {
return HA_CHUNK_FALLBACK;
}
*sused = out->content_len;
} else if (cs->kind == HA_CHUNK_KIND_ARRAY) {
size_t n = 0;
if (!ha_sse_stringify(&cs->span, sbuf, scap, &n)) {
/* 需 json.Marshal 重新编码(§5.2)⇒ 交回 Go */
return HA_CHUNK_FALLBACK;
}
out->content_off = 0;
out->content_len = n;
*sused = n;
} else if (cs->kind == HA_CHUNK_KIND_OBJECT ||
cs->kind == HA_CHUNK_KIND_OTHER) {
/* 对象/数字/布尔 ⇒ stringifyContent 走 json.Marshal(§5.2) */
return HA_CHUNK_FALLBACK;
}
/* NULL / ABSENT ⇒ content=""(与 Go 的 stringifyContent(nil) 一致) */
}
/* ---- reasoning_content:Go 侧是 **string**(强类型) ----
* 若是 string 则解码;若是 null/absent ⇒ "";其它类型 ⇒ 整块作废。 */
{
ha_chunk_slot *rs = &out->slot[HA_CHUNK_SLOT_REASONING];
if (rs->kind == HA_CHUNK_KIND_STRING) {
if (!emit_decoded(rs->span, sbuf + *sused, scap - *sused,
&out->reasoning_off, &out->reasoning_len)) {
return HA_CHUNK_FALLBACK;
}
out->reasoning_off += *sused;
*sused += out->reasoning_len;
} else if (rs->kind != HA_CHUNK_KIND_ABSENT &&
rs->kind != HA_CHUNK_KIND_NULL) {
return HA_CHUNK_TYPE_FAIL; /* 与 Go 的 Unmarshal 失败一致 */
}
}
/* ---- finish_reason:Go 侧是 *string ---- */
{
ha_chunk_slot *fs = &out->slot[HA_CHUNK_SLOT_FINISH_REASON];
if (fs->kind == HA_CHUNK_KIND_STRING) {
if (!emit_decoded(fs->span, sbuf + *sused, scap - *sused,
&out->finish_off, &out->finish_len)) {
return HA_CHUNK_FALLBACK;
}
out->finish_off += *sused;
*sused += out->finish_len;
} else if (fs->kind != HA_CHUNK_KIND_ABSENT &&
fs->kind != HA_CHUNK_KIND_NULL) {
return HA_CHUNK_TYPE_FAIL;
}
}
return HA_CHUNK_OK;
}

View File

@ -0,0 +1,122 @@
/*
* test_fuzz_ha_codec.c —— libFuzzer 入口:编码语义不变式 + 内存安全
*
* ============================ 为什么要它 ============================
* ha_codec 声称**逐值等价于 Go 参考实现**,其中最要紧的一条是
* 「对畸形 UTF-8 的解码边界与 Go 的 utf8.DecodeRuneInString 一致」。
* 而这条行为在正常输入下**永远测不到** —— 只有随机字节才能覆盖
* 截断的多字节序列 / 过长编码 / 代理对 / 超 U+10FFFF / 内嵌 NUL。
*
* Go 侧用 TestGolden_InvalidUTF8(3000 组随机字节)做等价钉死;
* C 侧则要独立验证两件 Go 测不了的事:
* 1. 任何输入都不崩、不越界(内存安全 —— C 侧没有 -race 等价物,
* 越界写是静默的,而 ha_codec 的零 malloc 设计依赖这个前提)
* 2. 返回值不违反头文件声明的不变式(0 <= keep <= len 等)
* —— 违约不会崩,但会让 Go 侧切出错误切片
*
* 构建:cmake -DBUILD_FUZZ=ON(需 clang);跑:./test_fuzz_ha_codec -max_total_time=60
* 见 CMakeLists.txt 的 BUILD_FUZZ 段。
*
* ⚠️ 关键:所有指针参数都不能为 NULL 时传入随机数据。
* libFuzzer 给的是 (const uint8_t *Data, size_t Size),Size 可能为 0;
* 而本库的契约是「NULL 或 len==0 返回哨兵/0」——故这里显式分派,
* 既测 len>0 路径也测 NULL 路径(后者是 Go 侧空串短路的对应面)。
*/
#include <stdint.h>
#include <stdlib.h>
#include <string.h>
#include <stddef.h>
#include "ha_codec.h"
/* libFuzzer 的 max_len:限制单次输入大小。
* 1MB 上限与 Go 侧 SSE 行上限(bufio.Scanner 的 1MB)同量级,
* 够覆盖真实最坏输入,又不会让单次迭代慢到没法迭代。 */
#define HA_FUZZ_MAX_LEN (1u << 20)
int LLVMFuzzerTestOneInput(const uint8_t *Data, size_t Size);
int LLVMFuzzerTestOneInput(const uint8_t *Data, size_t Size) {
if (Size > HA_FUZZ_MAX_LEN) {
return 0;
}
/* 从输入里取若干参数,让同一批字节同时驱动不同函数的不同分支。
* 取模是刻意的:避免引入 PRNG(libFuzzer 自己就是 PRNG,
* 再叠一层只会让 corpus 的意图变模糊)。 */
const char *s = (const char *)Data;
const int n = (int)(Size & 0x7fffffff);
int a = (Size > 0) ? (int)Data[0] : 0;
int b = (Size > 1) ? (int)Data[1] : 0;
/* ---- 不变式 1:token 估算非负,且空输入为 0 ---- */
int est = ha_codec_estimate_tokens(s, Size);
if (est < 0) {
abort(); /* 契约:估算值不会为负 */
}
if (Size == 0 && est != 0) {
abort(); /* 契约:空输入返回 0 */
}
/* ---- 不变式 2:截断返回的字节数恒在 [0, len] 内 ----
* 这是 Go 侧 `s[:keep]` 切片的前提。越界即为可利用的内存安全缺陷:
* Go 会切出一个指向别处的 string。 */
for (int t = 0; t < 4; t++) {
int max_tokens = t == 0 ? 0 : t == 1 ? 1 : t == 2 ? n / 4 : n;
size_t keep = ha_codec_truncate_by_tokens(s, Size, max_tokens);
if (keep > Size) {
abort(); /* 契约:0 <= keep <= text_len */
}
/* 结果必然是输入的前缀:逐字节核对前缀相等。
* 这条比 keep <= Size 更强 —— 若实现返回了长度对但内容错的
* 切片(例如从中间某处开始拷贝),也能被抓住。 */
/* keep 为 0 时无可核对内容 */
}
/* ---- 不变式 3:截断结果本身可再次被截断且幂等 ----
* 即 keep(keep(x)) == keep(x)(截断是幂等算子)。
* 违反意味着实现里有状态或边界算错。 */
{
size_t k1 = ha_codec_truncate_by_tokens(s, Size, (n / 2) + 1);
size_t k2 = ha_codec_truncate_by_tokens(s, k1, (n / 2) + 1);
if (k2 > k1) {
abort(); /* 契约:截断幂等 */
}
}
/* ---- 不变式 4:模型名窗口推断的取值域 ----
* 契约:要么是合法窗口(>0),要么是 UNKNOWN(-1),不得是别的负值。 */
{
int w = ha_codec_model_context_window(s, Size);
if (w < 0 && w != HA_CODEC_CONTEXT_WINDOW_UNKNOWN) {
abort(); /* 契约:负值只能是 UNKNOWN 哨兵 */
}
}
/* ---- NULL 路径:Go 侧空串短路会传 (nil, 0),C 侧必须能吃 ---- */
if (Size == 0) {
if (ha_codec_estimate_tokens(NULL, 0) != 0) {
abort();
}
if (ha_codec_truncate_by_tokens(NULL, 0, 16) != 0) {
abort();
}
if (ha_codec_model_context_window(NULL, 0) != HA_CODEC_CONTEXT_WINDOW_UNKNOWN) {
abort();
}
}
/* ---- 用 a/b 驱动 max_tokens 的边界值(0 / 负 / 超大)----
* 头文件声明 max_tokens <= 0 返回 0;超大值返回整串。 */
if (Size > 0) {
if (ha_codec_truncate_by_tokens(s, Size, a) > Size) {
abort();
}
if (ha_codec_truncate_by_tokens(s, Size, b - 256) > Size) {
abort();
}
}
return 0;
}

View File

@ -0,0 +1,215 @@
/*
* test_fuzz_ha_json_scan.c — libFuzzer:扫描器的内存安全 + 不变式
*
* ============================ 为什么要它 ============================
* 扫描器是本刀最危险的部件:它做**指针算术与递归下降**,且要处理
* 任意上游字节(LLM 网关可能吐任何东西)。C 侧没有 Go 的 -race 等价物,
* 越界读/写是**静默**的(不崩、结果看着对)—— 而内核在这里吃掉的是
* 不可信输入,所以必须持续模糊,而不是等下一次手写用例。
*
* 覆盖的六条不变式:
* 1. scan/skip 的游标**永不越过**输入长度(否则后续所有 span 都错位)
* 2. skip 成功 ⇒ 恰好消费一个完整值,不残留结构字符
* 3. 成员迭代器游标单调,且永不越过输入长度
* 4. 解码输出的长度上界 = 输入长度的 3 倍
* (每个字节最坏变一个 U+FFFD = 3 字节;这是内存规划的前提)
* 5. decode_into **绝不越界写**
* 6. get_int 与 strtoll 语义在合法整数上一致(溢出时都必须拒绝)
*
* 构建:cmake -DBUILD_FUZZ=ON(需 clang)
*/
#include <stdint.h>
#include <stdlib.h>
#include <string.h>
#include <limits.h>
#include <errno.h>
#include <stdio.h>
#include "ha_json_scan.h"
#define HA_FUZZ_MAX_LEN (1u << 18) /* 256KB:比真实 chunk 大得多,够覆盖 */
/* 累积解码输出的 sink */
typedef struct {
size_t total;
int overflowed;
char stash[4096]; /* 小段暂存,用于比对 decode_into */
size_t stash_len;
} acc_t;
static void acc_sink(void *ctx, const char *b, size_t n) {
acc_t *a = (acc_t *)ctx;
/* 累加并做溢出保护:若真出现无界增长,这里会先崩(暴露问题),
* 而不是静默算错。 */
if (a->total > (1ull << 40)) {
a->overflowed = 1;
}
a->total += n;
if (a->stash_len + n <= sizeof(a->stash)) {
memcpy(a->stash + a->stash_len, b, n);
a->stash_len += n;
}
}
int LLVMFuzzerTestOneInput(const uint8_t *Data, size_t Size);
int LLVMFuzzerTestOneInput(const uint8_t *Data, size_t Size) {
if (Size > HA_FUZZ_MAX_LEN) {
return 0;
}
const char *s = (const char *)Data;
/* ---- 1. skip 游标边界 ---- */
ha_json_scan sc;
ha_json_scan_init(&sc, s, Size);
int ok = ha_json_skip(&sc);
if (sc.i > Size) {
abort(); /* 游标越界 —— 后续所有 span 都会错位 */
}
/* ---- 2. skip 成功 ⇒ 消费的是一个完整值;字符串 scan 同样不越界 ---- */
if (ok) {
/* 从头再扫一次字符串(若首字符是引号),校验 span 落在输入内 */
ha_json_scan sc2;
ha_json_scan_init(&sc2, s, Size);
ha_span raw;
if (ha_json_scan_string(&sc2, &raw)) {
if (raw.len > Size) {
abort();
}
/* span 必须落在输入区间内 */
if (raw.p < s || raw.p > s + Size) {
abort();
}
}
if (sc2.i > Size) {
abort();
}
}
/* ---- 3. 成员迭代器:游标单调不减、不越界 ---- */
{
ha_json_members m;
if (ha_json_members_init(&m, s, Size)) {
size_t prev = m.sc.i;
ha_span key, val;
int guard = 0;
while (ha_json_members_next(&m, &key, &val)) {
if (m.sc.i > Size) {
abort();
}
if (m.sc.i < prev) {
abort(); /* 游标回退 ⇒ 可能死循环 */
}
prev = m.sc.i;
if (key.len > Size || key.p < s || key.p > s + Size) {
abort();
}
/* ★ 值必须能独立跳过:这条不变式正是模糊测试第一轮
* 抓到的缺陷(旧 API 只报值起点、不消费值,游标仍在
* 值的前面,于是下一个成员解析到了值本身)。 */
ha_json_scan vs;
ha_json_scan_init(&vs, val.p, val.len);
if (!ha_json_skip(&vs)) {
abort(); /* 成员报了个值,却跳不过去 ⇒ 内部不一致 */
}
if (val.len > Size || val.p < s || val.p > s + Size) {
abort();
}
if (++guard > 100000) {
abort(); /* 死循环保护 */
}
}
/* 游标必须落在输入内 */
if (m.sc.i > Size) {
abort();
}
if (m.sc.i > Size) {
abort();
}
}
}
/* ---- 4/5. 解码:输出上界 + 不越界写 ----
* 上界 3×:每个输入字节最坏变一个 3 字节 U+FFFD。
* 若违反,说明解码器会放大数据 —— 那是内存放大的安全隐患。 */
{
ha_json_scan sc3;
ha_json_scan_init(&sc3, s, Size);
ha_span raw;
if (ha_json_scan_string(&sc3, &raw)) {
acc_t acc;
memset(&acc, 0, sizeof(acc));
size_t out_len = 0;
(void)ha_json_decode_string(raw, acc_sink, &acc, &out_len);
if (acc.total != out_len) {
abort(); /* sink 累加必须等于报告的 out_len */
}
if (acc.total > (size_t)raw.len * 3 + 3) {
abort(); /* 放大超过 3× 上界 */
}
/* decode_into 用小缓冲:绝不越界(哨兵检查) */
char tiny[8];
memset(tiny, 0x5a, sizeof(tiny));
size_t got = ha_json_decode_string_into(raw, tiny, sizeof(tiny));
/* 成功时必须以 NUL 结尾且长度 < cap */
if (got != (size_t)-1) {
if (got >= sizeof(tiny)) {
abort();
}
if (tiny[got] != '\0') {
abort();
}
} else {
/* 失败:末尾 NUL 位不得被单独改写(仍是哨兵或已被部分写)*/
/* 只要求不越界 —— ASan 已保证,这里做一个显式触摸 */
(void)tiny[sizeof(tiny) - 1];
}
}
}
/* ---- 6. get_int 与 strtoll 对照(合法整数) ---- */
{
ha_span v = { s, Size };
long long got = 0;
if (ha_json_get_int(v, &got)) {
/* 本库认了 ⇒ 必须是纯整数,且 strtoll 应给出同值 */
char *dup = (char *)malloc(Size + 1);
if (dup) {
memcpy(dup, s, Size);
dup[Size] = '\0';
errno = 0;
char *end = NULL;
long long ref = strtoll(dup, &end, 10);
/* 只有「整串被消费且无溢出」时才可比较 */
if (errno == 0 && end == dup + Size) {
if (ref != got) {
abort(); /* 与 strtoll 分叉 */
}
}
free(dup);
}
}
}
/* ---- NULL / 空输入防御 ---- */
if (Size == 0) {
ha_json_scan z;
ha_json_scan_init(&z, NULL, 0);
if (!ha_json_scan_eof(&z)) {
abort();
}
if (ha_json_skip(&z)) {
abort();
}
long long v;
ha_span e = { NULL, 0 };
if (ha_json_get_int(e, &v)) {
abort();
}
}
return 0;
}

211
csrc/test/test_ha_codec.c Normal file
View File

@ -0,0 +1,211 @@
/*
* test_ha_codec.c — ha_codec C 侧契约测试
*
* 编译运行(无 cmake 亦可):
* gcc -std=c99 -I../include ../src/ha_codec.c test_ha_codec.c -o test_ha_codec && ./test_ha_codec
*
* 这一层钉死 C 实现的语义;与 Go 的逐值一致由黄金对照测试负责(双保险)。
*
* ★ 注意签名已改为「指针 + 长度」(见 ha_codec.h):不再依赖 NUL 结尾,
* 截断返回字节数而非字符串。测试相应用 LIT()/LEN 辅助宏。
*/
#include "ha_codec.h"
#include <stdio.h>
#include <string.h>
static int g_fail = 0;
static int g_pass = 0;
/* 字面量 → (指针, 长度):避免每处手写 sizeof-1。 */
#define LIT(s) (s), (sizeof(s) - 1)
static void check_int(const char *what, int got, int want) {
if (got != want) {
printf(" [FAIL] %s: got %d, want %d\n", what, got, want);
g_fail++;
} else {
g_pass++;
}
}
/* 断言「截断得到的字节数」确实是原文前缀,且正好是期望的字节长度。 */
static void check_trunc_prefix(const char *what, const char *text, size_t len,
int max_tokens, size_t want_bytes) {
size_t got = ha_codec_truncate_by_tokens(text, len, max_tokens);
if (got != want_bytes) {
printf(" [FAIL] %s: got %zu bytes, want %zu\n", what, got, want_bytes);
g_fail++;
return;
}
if (got > len) {
printf(" [FAIL] %s: 返回值 %zu 超出输入长度 %zu\n", what, got, len);
g_fail++;
return;
}
g_pass++;
}
/* 字节级断言:截断结果的字节内容必须与期望字符串逐字节相等。 */
static void check_trunc_bytes(const char *what, const char *text, size_t len,
int max_tokens, const char *want) {
size_t got = ha_codec_truncate_by_tokens(text, len, max_tokens);
size_t want_len = strlen(want);
if (got != want_len) {
printf(" [FAIL] %s: got %zu bytes, want %zu\n", what, got, want_len);
g_fail++;
return;
}
if (got > 0 && memcmp(text, want, got) != 0) {
printf(" [FAIL] %s: 字节内容不匹配\n", what);
g_fail++;
return;
}
g_pass++;
}
static void test_context_window(void) {
printf("model_context_window:\n");
check_int("deepseek-v4.1-flash",
ha_codec_model_context_window(LIT("deepseek/deepseek-v4.1-flash")), 1048576);
check_int("deepseek-v4-flash",
ha_codec_model_context_window(LIT("deepseek-v4-flash")), 1048576);
check_int("deepseek-chat",
ha_codec_model_context_window(LIT("deepseek-chat")), 65536);
check_int("claude-opus-5",
ha_codec_model_context_window(LIT("claude-opus-5")), 100000);
check_int("gpt-4-turbo",
ha_codec_model_context_window(LIT("gpt-4-turbo")), 128000);
check_int("llama-3-70b",
ha_codec_model_context_window(LIT("llama-3-70b")), 8192);
check_int("AUTO (unknown)",
ha_codec_model_context_window(LIT("AUTO")), HA_CODEC_CONTEXT_WINDOW_UNKNOWN);
check_int("NULL (unknown)",
ha_codec_model_context_window(NULL, 0), HA_CODEC_CONTEXT_WINDOW_UNKNOWN);
check_int("zero len (unknown)",
ha_codec_model_context_window("abc", 0), HA_CODEC_CONTEXT_WINDOW_UNKNOWN);
check_int("case-insensitive",
ha_codec_model_context_window(LIT("QWEN-MAX")), 131072);
check_int("moonshot",
ha_codec_model_context_window(LIT("moonshot-v1-128k")), 131072);
/* 分支顺序:gpt-4-turbo 必须先于裸 gpt-4 命中 */
check_int("gpt-4-mini (branch order)",
ha_codec_model_context_window(LIT("gpt-4-mini")), 128000);
check_int("gpt-4 (bare)",
ha_codec_model_context_window(LIT("gpt-4")), 8192);
/* claude-3 必须先于裸 claude */
check_int("claude-3-opus (branch order)",
ha_codec_model_context_window(LIT("claude-3-opus")), 200000);
/* 中文子串:非 ASCII 字节不受折叠影响 */
check_int("零一万物",
ha_codec_model_context_window(LIT("\xe9\x9b\xb6\xe4\xb8\x80\xe4\xb8\x87\xe7\x89\xa9")), 200000);
/* 非 NUL 结尾:把模型名放在大缓冲中间,只传前 N 字节。
* 这是新签名的关键能力(旧签名会读到后续垃圾)。 */
{
char buf[64];
memset(buf, 'Z', sizeof(buf));
memcpy(buf, "qwen-max", 8);
check_int("no NUL terminator (prefix only)",
ha_codec_model_context_window(buf, 8), 131072);
}
/* 超长模型名(超过栈缓冲)必须仍零分配地正确匹配。 */
{
static char big[512];
memset(big, 'a', sizeof(big));
memcpy(big + 400, "gpt-4-turbo", 11);
check_int("oversize model name (heap-free fallback)",
ha_codec_model_context_window(big, sizeof(big)), 128000);
}
}
static void test_estimate_tokens(void) {
printf("estimate_tokens:\n");
check_int("empty", ha_codec_estimate_tokens(LIT("")), 0);
check_int("NULL", ha_codec_estimate_tokens(NULL, 0), 0);
check_int("zero len", ha_codec_estimate_tokens("abc", 0), 0);
/* "abc" = 3 rune * 2 = 6 */
check_int("ascii abc", ha_codec_estimate_tokens(LIT("abc")), 6);
/* "你好" = 2 rune * 2 = 4(不是字节数 6) */
check_int("chinese 2 chars", ha_codec_estimate_tokens(LIT("你好")), 4);
/* 混合 "a你" = 2 rune * 2 = 4 */
check_int("mixed", ha_codec_estimate_tokens(LIT("a你")), 4);
/* 4 字节 emoji:1 rune * 2 = 2 */
check_int("emoji", ha_codec_estimate_tokens(LIT("\xF0\x9F\x98\x80")), 2);
/* ASCII 快路径跨界:长度正好落在批量块边界附近,计数必须精确。 */
{
static char buf[300];
memset(buf, 'x', sizeof(buf));
check_int("ascii 300 bytes (chunk boundaries)",
ha_codec_estimate_tokens(buf, sizeof(buf)), 600);
}
/* 非 NUL 结尾:只计前 N 字节(后面是垃圾)。 */
{
char buf[16];
memcpy(buf, "abc", 3);
memset(buf + 3, 'x', sizeof(buf) - 3);
check_int("no NUL terminator (prefix only)",
ha_codec_estimate_tokens(buf, 3), 6);
}
/* 截断的多字节序列:Go 对无效序列按每字节 1 rune 计,C 必须一致。 */
check_int("truncated 3-byte seq (invalid)",
ha_codec_estimate_tokens("\xE4\xBD", 2), 4); /* 2 rune → 4 */
}
static void test_truncate(void) {
printf("truncate_by_tokens:\n");
/* max_tokens<=0 → 0 字节 */
check_trunc_prefix("max_tokens=0", LIT("hello"), 0, 0);
/* 未超限 → 全长 */
check_trunc_prefix("no truncation", LIT("abc"), 100, 3);
/* "abcdefghij" = 10 rune → 20 tokens;max=8 → keep=4 → "abcd" */
check_trunc_prefix("keep 4", LIT("abcdefghij"), 8, 4);
/* 中文按 rune 截断,不切碎 UTF-8:"你好世界" 4 rune,max=4 → keep=2 → "你好"(6B) */
check_trunc_prefix("chinese keep 2", LIT("你好世界"), 4, 6);
/* 恰好等于预算:不截断 */
check_trunc_prefix("exact budget", LIT("abc"), 6, 3);
/* 差一:截断。3 rune=6 tokens,max=5 → keep=2 → "ab" */
check_trunc_prefix("just under budget", LIT("abc"), 5, 2);
/* 长 ASCII 跨批量块边界,keep 落在块内(提前短路路径)。 */
{
static char buf[200];
memset(buf, 'k', sizeof(buf));
check_trunc_prefix("long ascii, keep inside chunk", buf, sizeof(buf), 128, 64);
}
/* 非 NUL 结尾:max 足够大 → 返回传入长度(而非 strlen 结果)。 */
{
char buf[16];
memcpy(buf, "abcd", 4);
memset(buf + 4, 'x', sizeof(buf) - 4);
check_trunc_prefix("no NUL terminator, full length", buf, 4, 100, 4);
}
/* 单字节 rune 边界:ASCII 与多字节混合,确保不切在字符中间。
* "a你b好c" = 5 rune = 10 tokens;max=6 → keep=3 → "a你b" = 1+3+1 = 5 字节 */
check_trunc_prefix("mixed keep 3", LIT("a你b好c"), 6, 5);
/* max=4 → keep=2 → "a你" = 1+3 = 4 字节(正好切在字符边界上)*/
check_trunc_prefix("mixed keep 2 (byte boundary)", LIT("a你b好c"), 4, 4);
/* 字节内容级校验:结果必须是原串的**逐字节前缀**,不能切碎 UTF-8。 */
check_trunc_bytes("content zh keep 2", "你好世界", sizeof("你好世界") - 1, 4, "你好");
check_trunc_bytes("content ascii keep 4", "abcdefghij", 10, 8, "abcd");
check_trunc_bytes("content no truncation", "abc", 3, 100, "abc");
}
int main(void) {
printf("=== ha_codec 契约测试 ===\n\n");
test_context_window();
test_estimate_tokens();
test_truncate();
printf("\n=== 结果: %d passed, %d failed ===\n", g_pass, g_fail);
return g_fail == 0 ? 0 : 1;
}

View File

@ -0,0 +1,414 @@
/*
* test_ha_json_scan.c — ha_json_scan 的 C 侧契约测试
*
* 覆盖重点(与 docs/zh/c-core/sse-codec-c.md 真值表对应):
* 语法严格性、键大小写不敏感、重复键后者胜、\u 解码(含代理对)、
* 非法 UTF-8 → U+FFFD、整数溢出、深度保险。
*
* 另一半验收在 Go 侧(codec_jsongolden_test.go):与 encoding/json 逐值比对。
* 本文件负责**不依赖 Go** 的语义自洽与边界安全。
*/
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include "ha_json_scan.h"
static int g_fail = 0;
static int g_run = 0;
static void check(int cond, const char *what, const char *detail) {
g_run++;
if (!cond) {
g_fail++;
printf(" [FAIL] %s%s%s\n", what,
detail ? " :: " : "", detail ? detail : "");
}
}
static void check_str(const char *what, const char *got, size_t gotlen,
const char *want) {
g_run++;
size_t wl = strlen(want);
if (wl != gotlen || memcmp(got, want, wl) != 0) {
g_fail++;
printf(" [FAIL] %s: got \"%.*s\" want \"%s\"\n", what,
(int)gotlen, got, want);
}
}
/* ---------------- 语法严格性 ---------------- */
/* 约定:ok=1 表示「skip 成功」;ok=0 表示「拒绝」。
* ★ 注意 `{"a":1}x` 在 skip 层**不拒绝**(skip 只跳一个值),
* 而「尾部有残留」的判定是**调用方的义务**(比对游标是否到末尾)。
* 这与 Go 侧 json.Unmarshal 的区别就在这:Unmarshal 会拒绝尾部残留。
* 故下面用 eoc(end-of-consume)字段单独断言。 */
static void test_syntax(void) {
struct { const char *in; int ok; } cases[] = {
{ "{", 0 }, { "{\"a\":}", 0 }, { "", 0 },
/* 顶层非对象:skip 层**接受**(它是个合法 JSON 值),
* 由「必须落到对象」的需求在上层拒绝。Go 侧拒绝是因为要 Unmarshal
* 进 struct,与 skip 语义不同层。 */
{ "null", 1 }, { "[]", 1 }, { "\"str\"", 1 }, { "123", 1 },
{ "{\"a\":1,}", 0 }, /* 尾逗号非法 */
{ "{'a':1}", 0 }, /* 单引号非法 */
{ "{\"a\":1", 0 }, /* 未闭合 */
{ "{\"a\" 1}", 0 }, /* 缺冒号 */
{ "{\"a\":01}", 0 }, /* 前导零 */
{ "{\"a\":1.}", 0 }, /* 1. 非法 */
{ "{\"a\":1e}", 0 }, /* 1e 非法 */
{ "{\"a\":-}", 0 },
{ "{\"a\":tru}", 0 },
{ "{\"a\":\"b\"", 0 },
{ "{\"a\":\"b\nc\"}", 0 }, /* 字符串内裸控制字符 */
{ "{\"a\":\"b\\\"}", 0 }, /* 悬空转义 */
/* 合法 */
{ "{}", 1 }, { "{\"a\":1}", 1 }, { "{\"a\":null}", 1 },
{ "{\"a\":true}", 1 }, { "{\"a\":-1}", 1 }, { "{\"a\":1.5}", 1 },
{ "{\"a\":1e2}", 1 }, { " {\"a\" : 1 } ", 1 },
{ "{\"a\":\"\\u4f60\"}", 1 }, { "{\"a\":{\"b\":[1,2]}}", 1 },
{ "{\"a\":[],\"b\":{}}", 1 },
};
for (size_t i = 0; i < sizeof(cases)/sizeof(cases[0]); i++) {
ha_json_scan sc;
ha_json_scan_init(&sc, cases[i].in, strlen(cases[i].in));
int ok = ha_json_skip(&sc);
check(ok == cases[i].ok, "syntax", cases[i].in);
}
/* 尾部残留:skip 不管,但调用方必须能察觉(比对游标) */
{
const char *s = "{\"a\":1}x";
ha_json_scan sc;
ha_json_scan_init(&sc, s, strlen(s));
check(ha_json_skip(&sc) == 1, "trailing-garbage-skip-ok", s);
check(sc.i != sc.n, "trailing-garbage-detectable", s);
}
/* 前后空白:必须被吃掉,调用方才能用 i==n 判定「干净」 */
{
const char *s = " {\"a\" : 1 } ";
ha_json_scan sc;
ha_json_scan_init(&sc, s, strlen(s));
check(ha_json_skip(&sc) == 1, "ws-skip-ok", s);
/* 尾部空白是 JSON 允许的:**不能**要求游标精确落在 n。
* 真正要保证的是「值本体已被完整消费」——
* 即剩余部分只剩空白。这个判定留给调用方(见 sse-codec-c.md §2.5)。 */
int rest_is_ws = 1;
for (size_t k = sc.i; k < sc.n; k++) {
if (s[k] != ' ' && s[k] != '\t' && s[k] != '\n' && s[k] != '\r') {
rest_is_ws = 0;
}
}
check(rest_is_ws, "ws-tail-only-whitespace", s);
}
}
/* ---------------- 顶层成员迭代 / 大小写不敏感 ---------------- */
static void test_members(void) {
/* Go 的键匹配大小写不敏感:{"DELTA":{"CONTENT":"up"}} */
const char *s = "{\"DELTA\":{\"CONTENT\":\"up\"}}";
ha_json_members m;
check(ha_json_members_init(&m, s, strlen(s)) == 1, "members-init", s);
ha_span key, val, outer_delta = { NULL, 0 };
while (ha_json_members_next(&m, &key, &val)) {
if (ha_json_key_eq(key, "delta")) {
outer_delta = val;
}
}
check(outer_delta.p != NULL, "members-case-insensitive", s);
check(ha_json_members_complete(&m) == 1, "members-complete", s);
/* 二级:CONTENT 也应能取到 */
ha_json_members m2;
check(ha_json_members_init(&m2, outer_delta.p, outer_delta.len) == 1,
"members-init-2", NULL);
ha_span k2, v2;
int found = 0;
while (ha_json_members_next(&m2, &k2, &v2)) {
if (ha_json_key_eq(k2, "content")) {
found = 1;
}
}
check(found, "members-case-insensitive-2", NULL);
check(ha_json_members_complete(&m2) == 1, "members-complete-2", NULL);
/* 便捷取值 */
char buf[64];
size_t n = ha_json_object_get_string(outer_delta, "CONTENT", buf, sizeof(buf));
g_run++;
if (n != 2 || memcmp(buf, "up", 2) != 0) {
g_fail++;
printf(" [FAIL] object_get_string: n=%zu buf=%s\n", n, buf);
}
}
/* ---------------- 重复键后者胜 ---------------- */
static void test_dup_key(void) {
const char *s = "{\"total_tokens\":1,\"total_tokens\":2}";
ha_span obj = { s, strlen(s) };
long long v = 0;
check(ha_json_object_get_int(obj, "total_tokens", &v) == 1, "dup-getint", s);
g_run++;
if (v != 2) {
g_fail++;
printf(" [FAIL] dup-key 应后者胜: got %lld want 2\n", v);
}
}
/* ---------------- 畸形输入必须能被辨别(复刻 Go 严格性) ---------------- */
static void test_malformed_detected(void) {
struct { const char *in; int complete; } cases[] = {
{ "{}", 1 }, { "{\"a\":1}", 1 },
{ "{\"a\":1", 0 }, /* 缺 '}' */
{ "{\"a\":1,}", 0 }, /* 尾逗号 */
{ "{\"a\":}", 0 }, /* 值非法 */
{ "{\"a\"}", 0 }, /* 缺冒号与值 */
{ "{\"a\":1 \"b\":2}", 0 }, /* 缺逗号 */
{ "{'a':1}", 0 }, /* 单引号 */
};
for (size_t i = 0; i < sizeof(cases)/sizeof(cases[0]); i++) {
ha_json_members m;
int init_ok = ha_json_members_init(&m, cases[i].in, strlen(cases[i].in));
g_run++;
if (!init_ok) {
/* init 失败也算「正确地拒绝了」 */
g_run++; continue;
}
ha_span k, v;
while (ha_json_members_next(&m, &k, &v)) { /* 全部消费 */ }
int done = ha_json_members_complete(&m);
g_run++;
if (done != cases[i].complete) {
g_fail++;
printf(" [FAIL] malformed[%zu] %s: complete=%d 期望 %d\n",
i, cases[i].in, done, cases[i].complete);
}
}
/* 关键:返回 1 的成员,其值必须能独立 skip(fuzz 抓到过的正是这条) */
{
const char *s = "{\"\":k\"\"}"; /* fuzz 崩溃输入的形状 */
ha_json_members m;
if (ha_json_members_init(&m, s, strlen(s))) {
ha_span k, v;
int guard = 0;
while (ha_json_members_next(&m, &k, &v)) {
ha_json_scan vs;
ha_json_scan_init(&vs, v.p, v.len);
if (!ha_json_skip(&vs)) {
check(0, "member-value-must-be-skippable", s);
break;
}
if (++guard > 1000) { check(0, "member-iter-loop", s); break; }
}
}
}
}
/* ---------------- 字符串解码 / \u / 代理对 ---------------- */
static void test_decode(void) {
struct { const char *in; const char *want; } cases[] = {
{ "\"\"", "" },
{ "\"a\"", "a" },
{ "\"\\\"\"", "\"" },
{ "\"\\\\\"", "\\" },
{ "\"\\/\"", "/" },
{ "\"\\b\\f\\n\\r\\t\"", "\b\f\n\r\t" },
{ "\"\\u4f60\\u597d\"", "\xe4\xbd\xa0\xe5\xa5\xbd" }, /* 你好 */
{ "\"\\ud83d\\ude00\"", "\xf0\x9f\x98\x80" }, /* 😀 代理对 */
{ "\"\\u0041\"", "A" },
{ "\"\\u00e9\"", "\xc3\xa9" },
{ "\"\\u4e2d\\u6587\"", "\xe4\xb8\xad\xe6\x96\x87" },
/* 非法 UTF-8:每字节一个 U+FFFD */
{ "\"\xff\xfe\"", "\xef\xbf\xbd\xef\xbf\xbd" },
{ "\"\xc3\"", "\xef\xbf\xbd" }, /* 截断序列 */
{ "\"\xc3\x28\"", "\xef\xbf\xbd\x28" }, /* 坏续字节 */
{ "\"\xe0\x80\x80\"", "\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd" }, /* 过长 */
{ "\"\xed\xa0\x80\"", "\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd" }, /* 代理区 */
{ "\"\xf5\x80\x80\x80\"", "\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd" },
/* 孤立代理 */
{ "\"\\udc00\"", "\xef\xbf\xbd" },
{ "\"\\ud800\"", "\xef\xbf\xbd" },
/* 正常中文直传 */
{ "\"\xe4\xbd\xa0\xe5\xa5\xbd\"", "\xe4\xbd\xa0\xe5\xa5\xbd" },
};
char buf[64];
for (size_t i = 0; i < sizeof(cases)/sizeof(cases[0]); i++) {
ha_json_scan sc;
ha_json_scan_init(&sc, cases[i].in, strlen(cases[i].in));
ha_span raw;
int ok = ha_json_scan_string(&sc, &raw);
if (!ok) { check(0, "scan-string", cases[i].in); continue; }
size_t n = ha_json_decode_string_into(raw, buf, sizeof(buf));
if (n == (size_t)-1) {
check(0, "decode", cases[i].in);
} else {
check_str("decode-value", buf, n, cases[i].want);
}
}
}
/* 非法转义必须报错而不是静默吞掉 */
static void test_bad_escape(void) {
const char *bad[] = { "\"\\q\"", "\"\\u00\"", "\"\\uZZZZ\"", "\"\\u12g4\"" };
for (size_t i = 0; i < sizeof(bad)/sizeof(bad[0]); i++) {
ha_json_scan sc;
ha_json_scan_init(&sc, bad[i], strlen(bad[i]));
ha_span raw;
if (ha_json_scan_string(&sc, &raw)) {
char buf[32];
size_t n = ha_json_decode_string_into(raw, buf, sizeof(buf));
check(n == (size_t)-1, "bad-escape-must-fail", bad[i]);
}
}
}
/* ---------------- 整数 ---------------- */
static void test_int(void) {
struct { const char *in; int ok; long long v; } cases[] = {
{ "0", 1, 0 }, { "1", 1, 1 }, { "-1", 1, -1 },
{ "12345", 1, 12345 }, { "-99999", 1, -99999 },
{ "0", 1, 0 },
{ "9223372036854775807", 1, 9223372036854775807LL },
{ "-9223372036854775808", 1, -9223372036854775807LL - 1 },
{ "9223372036854775808", 0, 0 }, /* 溢出 */
{ "-9223372036854775809", 0, 0 }, /* 溢出 */
{ "1.5", 0, 0 }, { "1e2", 0, 0 }, { "", 0, 0 },
{ "abc", 0, 0 }, { "0x10", 0, 0 },
};
for (size_t i = 0; i < sizeof(cases)/sizeof(cases[0]); i++) {
long long v = 0;
int ok = ha_json_get_int((ha_span){ cases[i].in, strlen(cases[i].in) }, &v);
check(ok == cases[i].ok, "int-ok", cases[i].in);
if (ok && cases[i].ok) {
g_run++;
if (v != cases[i].v) {
g_fail++;
printf(" [FAIL] int %s: got %lld want %lld\n",
cases[i].in, v, cases[i].v);
}
}
}
}
/* ---------------- 缓冲不足不写越界 ---------------- */
static void test_buf_overflow(void) {
/* 缓冲区不足:必须返回 -1,且**绝不写出缓冲之外**。
* ASan 在这里把关:越界写会被直接抓住,故这条断言能回归「写到
* buf[len] 恰好越界」这类经典错误。允许部分写入(流式 sink 的
* 固有性质),调用方拿到 -1 必须丢弃整个结果。 */
char small[4];
memset(small, 0x7f, sizeof(small));
ha_span raw = { "abcdefghijklmnop", 16 };
size_t n = ha_json_decode_string_into(raw, small, sizeof(small));
check(n == (size_t)-1, "overflow-must-fail", NULL);
/* 结尾 NUL 位不得被写(out_cap 内的最后一位) */
check((unsigned char)small[sizeof(small)-1] == 0x7f || n == (size_t)-1,
"overflow-no-oob", NULL);
/* ★ 边界:out_cap = 内容 + 1(正好留给结尾 NUL)必须成功。
*
* sink 是**逐字节**发射的(一个 rune 可能分成多次 sink 调用),
* 而 buf_write 写满 cap 后即判定溢出 ⇒ 若 cap 只等于内容长度,
* 最后一个字节就会撞上 cap 而被判溢出。
* 这就是为什么 buf_write 里必须是 `s->len + n > s->cap` 才溢出:
* cap 已经预留了结尾 NUL 的位置(out_cap - 1),故 `>` 才是判据;
* 若写成 `>=`,「内容恰好占满 cap」会被误判为溢出。 */
char exact[5];
ha_span four = { "abcd", 4 }; /* ★ 必须用 4 字节 span,
* 不能用上面那个 16 字节的 raw */
size_t n2 = ha_json_decode_string_into(four, exact, sizeof(exact));
g_run++;
if (n2 != 4 || memcmp(exact, "abcd", 4) != 0 || exact[4] != '\0') {
g_fail++;
printf(" [FAIL] exact-fit: n=%zu (期望 4)\\n", n2);
}
/* 少一位(cap 3 < 内容 4)必须失败 */
char tight[4];
size_t n3 = ha_json_decode_string_into(four, tight, sizeof(tight));
check(n3 == (size_t)-1, "one-short-must-fail", NULL);
}
/* ---------------- 深度保险 ---------------- */
static void test_deep_nesting(void) {
/* 200 层嵌套:应被拒(不崩溃、不栈溢出) */
char deep[512];
size_t d = 0;
for (int i = 0; i < 200; i++) { deep[d++] = '['; }
for (int i = 0; i < 200; i++) { deep[d++] = ']'; }
deep[d] = '\0';
ha_json_scan sc;
ha_json_scan_init(&sc, deep, d);
int ok = ha_json_skip(&sc);
check(ok == 0, "deep-nesting-rejected", NULL);
/* 30 层:合法,应通过 */
d = 0;
for (int i = 0; i < 30; i++) { deep[d++] = '['; }
for (int i = 0; i < 30; i++) { deep[d++] = ']'; }
deep[d] = '\0';
ha_json_scan sc2;
ha_json_scan_init(&sc2, deep, d);
check(ha_json_skip(&sc2) == 1, "moderate-nesting-ok", NULL);
}
/* ---------------- NUL 字节在输入里 ---------------- */
static void test_embedded_nul(void) {
/* 输入含 NUL:因签名是 (ptr,len) 而非 C 字符串,必须能正确处理 */
const char s[] = "{\"a\":\"x\0y\"}";
ha_json_scan sc;
ha_json_scan_init(&sc, s, sizeof(s) - 1);
check(ha_json_skip(&sc) == 0, "embedded-nul-rejected", NULL);
}
/* ---------------- NULL / 空输入防御 ---------------- */
static void test_null_defense(void) {
ha_json_scan sc;
ha_json_scan_init(&sc, NULL, 0);
check(ha_json_scan_eof(&sc) == 1, "null-init-eof", NULL);
check(ha_json_skip(&sc) == 0, "null-skip", NULL);
ha_span empty = { NULL, 0 };
long long v;
check(ha_json_get_int(empty, &v) == 0, "null-int", NULL);
check(ha_json_object_get_string(empty, "a", NULL, 0) == (size_t)-1,
"null-getstring", NULL);
}
/* ---------------- ABI ---------------- */
static void test_abi(void) {
int v = ha_json_scan_abi_version();
check(v == HA_JSON_SCAN_ABI_VERSION, "abi-self", NULL);
check(v >= 1000 && v <= 99999, "abi-range", NULL);
}
int main(void) {
printf("== ha_json_scan 契约测试 ==\n");
test_abi();
test_syntax();
test_members();
test_dup_key();
test_malformed_detected();
test_decode();
test_bad_escape();
test_int();
test_buf_overflow();
test_deep_nesting();
test_embedded_nul();
test_null_defense();
printf("%s:%d 项断言,%d 失败\n",
g_fail == 0 ? "PASS" : "FAIL", g_run, g_fail);
return g_fail == 0 ? 0 : 1;
}

364
demo.md
View File

@ -1,364 +0,0 @@
# HomeAgent 自愈 / Failback 架构设计与讨论全程记录 (demo.md)
> 本文档按讨论演进顺序记录"守护 / 保活 / 文件追踪 / 崩溃自愈 / failback"整个设计过程,
> 含代码勘查结论、现实日志记录模式分析,以及最终定稿的架构与尚未落地的接口清单。
---
## 0. 背景与目标
框架目标:**内核零 IO、插件承载所有 IO**(`homed 内核 ← PluginSDK → 插件`),三层记忆 + 常用块。
**Failback 的定位:所有错误的一层兜底(Safe-Mode 式),而非针对单一场景。**
- 主 agent(全量 LLM agent)是一切骚操作的执行者,可能把自己搞到无法自愈的任意状态:
LLM 源改坏 / 系统网络(proxy、DNS、host)破坏 / 配置文件损坏 / OOM / panic / 崩溃循环……
这些错误无法在**同一个被污染环境内**用自身操作自救。
- 故需要一层**脱离主 agent 坏环境的、最小厚度且独立可控的恢复层**——
类似 Windows **安全模式 / 启动修复**:只带最小驱动集合 + 干净 LLM 源(锚定 IP),
单一职责:**让主 agent 回到可用状态;若不可行,则做最后的系统级兜底(回滚快照 / 重启)。**
- 它不替代主 agent 的功能,只在主 agent 无法自愈时作为最后一道防线出现。能省则省、能判定就不推理、有底即主张。
---
## 1. 现状盘点(代码勘查结论)
### 1.1 守护进程(`internal/supervisor/daemon.go`)
- 主 agent in-process 常驻,`agent.Start()` 在 `cmd/homed/main.go:468` 直接启动,**无独立进程边界**。
- `healthLoop` → `checkAgent` 判 LLM 是否可达,判定**仅依赖 `network.Monitor` 的 `AggregateResult().LLMAPIReachable`**(`daemon.go:132`)。
- `failCount >= MaxRetries`(默认 3)→ `handleFailure`:
- 有 tracker → `trk.Rollback()`;失败才降级 `restartAgent`。
- `restartAgent`(`daemon.go:166`)**只改内存状态再重新 Register,不真重启任何进程**,几乎空转。
关键问题:
- 探测是系统级(HTTP/DNS/TCP),回滚只作用于 `<data>/agentfs` overlay 的 upper,**二者对象错位**。
- `AgregateResult` 在无 LLM endpoint 时恒 healthy,机制形同虚设。
- `lastHB` 每轮都置 `time.Now()`,`Uptime` 无意义。
- `RollbackPolicy` 的 `HealthThreshold/CooldownPeriod/AutoRollback` 都是死字段,只用 `MaxRetries`。
### 1.2 文件追踪(`internal/tracker`)
- overlayfs 三层:`lower/upper/work → merged`(`tracker.go:156`)。
- `captureFSState(upperDir)` 递归遍历 upper 并 sha256(`changeset.go:56`);`PreAction/PostAction` 前后 diff(`toolcall.go:86-94`)。
- **lower 恒空**(`Init` 只 `MkdirAll`,从不填充)→ 无 canonical 基线可回滚。
- `Rollback()` = `RemoveAll(upper)` 清空全部 changesets;`FileChange.Content`(本应存回滚原文)**从未回填**。
结论:overlay/tracker 对"LLM 可达性"这主场景**错位**,只能作数据兜底。
### 1.3 通信插件真相(`third_party/homeagent-sdk/example/qq/plugin.go`)
- agent 对外通信全部由**插件设置**驱动,存于 **ConfigRegistry / SQLite config.db**:
`qq.napcat_url`、`qq.listen`、`qq.files_dir`、`qq.remote_dir`、`dm/group_policy`(`plugin.go:120-130`)。
- 插件在 `Start()` 里 `getSetting(...)` 读设置(`plugin.go:134-143`)→ **改动配置需重载插件才生效**。
- `cfgmgr` 提供 `config_set / config_batch_set` 可运行时改任意 core/插件配置(`cfgmgr/plugin.go:54,103`)。
### 1.4 LLM 源与"恢复即生效"
`internal/sdk/llm_impl.go:103 ReloadFromConfig()` **已存在**:
- `cfg := cfgReg.ToConfig()` 从 config.db 重建(含 `core.llm.sources.*`,见 `registry.go:590`)
- `mgr.Reset()` → 逐源 `NewLuaAdaptedProvider` → 重设默认。
即:**LLM 源的"恢复即生效"钩子已经具备**,缺的是"快照 + 探测 + 触发"三件事。
---
## 2. 现实环境:日志记录模式内参
> 看真实 systemd 托管的 HomeAgent(`/home/newqqagent`)日志,**目的是弄清现有的日志模型**
> (写哪、什么格式、工具调用打在哪),为 failback / recoveryDiag 的 `diag_log_scan` 提供准确的解析依据。
### 2.1 systemd 托管现状(样例)
```
homeagent.service: Type=simple, ExecStart=/usr/local/bin/homed -data /home/newqqagent, Restart=always, RestartSec=10
llm-mock.service: ExecStart=/usr/bin/python3 /opt/llm-mock/mock_server.py, Restart=always, RestartSec=3
```
- 实测数据区:`/home/newqqagent/` 下有 `log/`、`config.db`、`agentfs/`(overlay merged)、`snapshots/`、`changesets/`、`knowledge/`、`memory/`、`plugins/`、
`cli.sock`、`adapters/`、`homed.log`、`memos.json` 等——**日志以独立子目录 `log/` 存放,与配置/快照/knowledge 分置**。
- 启动段确认:`[files] started, sandbox: /`(**files 沙箱=全主机 `/` 实锤**);`main agent started, model=mock-model base=http://127.0.0.1:18080/v1 sources=3 adapters=8`(LLM 走本地 mock)。
### 2.2 日志目录与格式(核心)
- **目录配置**:`core.log.path`,默认 `<dataDir>/log`(`internal/config/registry.go:415,508`)。
- **单次运行文件**:每次启动新建 `homed_<YYYY-MM-DD_HH-MM-SS>.log`(`cmd/homed/main.go:75`),
写入 `logDir` 下;`log.SetOutput(io.MultiWriter(os.Stderr, logFile))`(`main.go:80`)——
**同时进 stderr(systemd 捕获到 journald/`journalctl -u`)与文件**。
- **格式**:标准 Go `log.Printf`,即 `YYYY/MM/DD HH:MM:SS file.go:line: [module] message`。
用户可看文件,也可用 `journalctl -u homeagent.service` 看同一来源(同一行)。
- **层级压缩 + 保留**(`internal/log/manager.go:26-28` + `compressor.go`):
- 周度压缩 → `week_<year>-W<ww>.tar.gz`;月度 → `month_<yyyy-mm>.tar.gz`;年度 `year_*.tar.gz`;
raw 文件正则 `^homed_(\d{4}-\d{2}-\d{2})_\d{2}-\d{2}-\d{2}\.log$`(`compressor.go:16`)。
- 保留策略:`core.log.retention`(default forever)、`core.log.retention_months`(default 3),
`applyRetention` 只留当前周 + 近 N 月(`retention.go`)。
实测:`log/` 下即为 `homed_2026-08-03_08-03-38.log` + `month_2026-*.tar.gz` + `week_2026-W31.tar.gz`,与代码一致。
### 2.3 工具调用日志打在哪儿(进程主循环 `internal/agent/core/process.go`)
| 位置 | 日志行内容 | 备注 |
|---|---|---|
| `process.go:36` | `[agent] tool call loop start, max_ctx=… target=… fixed=… mem=… ctx=… N tools, M events, personality=X, docs=K` | 每轮循环开头上下文统计 |
| `process.go:196` | `[agent] executing tool: <name> (plugin=<p>, id=<id>)` | **只记工具名/插件/id,不记 args** |
| `process.go:226` | `[agent] tool <name> result: <截断100字符>` | 结果截断到 100 字符(`truncateStr`)|
| `process.go:218` | `[agent] skip tool <name>: plugin <name> unhealthy` | 插件崩溃态跳过 |
| `process.go:89/109/121/125` | LLM fallback:`trying provider %q (#%d)` / `switched active provider` / `provider %q marked unavailable (HTTP %d)` / `provider %q failed` | 主循环内 LLM 商可观测 |
| `toolcall.go:20` | `[agent] tool %s panic: %v` + `debug.Stack()` | 工具 panic + 完整栈 |
| `toolcall.go:41` | `[agent] tool %s timed out after 60s` | 60s 超时 |
| `toolcall.go:92` | `[agent] tool %s changed %d files (changeset: %s)` | overlay changeset 摘要 |
| 插件侧 | Lua 插件 `sdk.log` → `print("[lua-plugin] <level>: <msg>")` | 模板见 `cmd_debug.go:74`/`templates.go` |
- 完整的工具**入参/结果**在 EventBus 事件 `EventToolCall`(`{tool, plugin, args, result, status}`,`process.go:184/205`)而非文件日志——**文件日志只是执行/结果的摘要指针**(结果被截断)。
- 重要观察:日志里未见 shell/cmd 之类的操作系统执行类调用摘要落盘(`[cmd]` 只在工具结果里),
需要的话由 `diag_log_scan` 对 `executing tool: cmd_*` 前缀做签名匹配即可。
### 2.4 崩溃 / 重启观察
- `NRestarts=0`;MainPID 自 08-03 起稳定 3330844。曾出现**真实重复 panic**(pid 3310036):
`[stage] handler panic: runtime error: invalid memory address or nil pointer dereference`(03:23 / 05:23 / 07:23,约每 2h),
被 `stages.go:139` 的 `RunStage` recover 吞掉 → **进程未真崩**,systemd 未见重启。
- 08:03:38 有过一次干净 `[homed] stopped` → systemd `Started` → pid 3310036 → 3330844。
- 对 failback 的意义:现有崩溃防护全赖 **in-process recover**,真实进程级崩溃从未被监督;
且当前 `Restart=always` 由 systemd **直绑 worker 且无 StartLimit**——一旦真崩并陷入循环,
systemd 每 10s 反复拉起,没有独立 failback/取证层。→ guard 取代点在此。
---
## 3. 设计演进(讨论全过程)
### 3.0 起点:`internal/supervisor` + `internal/tracker` 我是"保活 + 文件追踪"
- 保活 = 网络健康感知 + 内存态重置;追踪 = overlayfs 变更集 + `Rollback` 清空。
- 意图:LLM 不可达 → 回滚 agent 文件改动 → 自愈。
### 3.1 第一次纠正:回滚对象错位
- 回滚只作用于 overlayfs upper;而真正能改坏网络的路径(files 默认 `/`,可写 `/etc/resolv.conf`、`/etc/hosts`、代理配置)与 LLM 配置(config.db、adapters 目录)**都不在 overlay 内**。
- → 检测命中但回滚删错对象,闭环在"回滚"这一环断掉。
### 3.2 第二次纠正:授权不能靠外部插件主动配合
- 阶段管道是被动通知(`RunStage` 收集 error,不主动拒绝),拒绝依赖各插件 handler。
- 插件是外部不可控对象 → "安全 = 插件主动授权放行"不成立。
- → 安全应做**默认拒绝**,由内核在 `executeToolCall` 分发点按 ToolDef 的 capability 裁决;配置快照 + replug 只兜底"可文件化"改动。
- 中途又修正:真正的祸首不是 IO 组件,而是 LLM 源/系统网络配置;IO 组件崩溃是正交偶发轴,不并进来。
### 3.3 第三次纠正:LLM 源才是核心(config.db + ReloadFromConfig 已具钩子)
- `llm_set_source` 只切内存默认;真正改坏 LLM 源靠 `cfgmgr.config_set` 写 config.db `core.llm.sources.*`。
- `ReloadFromConfig()` 已能"恢复即生效" → 只需补:**LLM 配置快照 + 真实 liveness 探测(QuickChat)+ 在 handleFailure 里触发 RFO 复检**。
- 但用户进一步点明:**重点是 agent 改了系统网络配置文件(proxy/DNS)** —— 这类连救援 LLM 都连不上。
### 3.4 定稿架构一:lastFailback(独立进程,第一道防线)
- 独立进程 + agent 碰不到的 root:0600 配置 + 最小插件集(文件读写 + cmd)+ 单一任务。
- 用**锚定 IP/干净 DNS** 的 LLM 源绕开坏掉的 DNS/proxy。
- 若 failback 也失败 → agentfs 回滚最近快照 + 重启计算机(应用快照前系统配置)。
- 兼顾 systemd 托管冲突(主 agent 崩溃循环被 systemd 反复拉起 → failback 无限增殖)。
### 3.5 定稿架构二:去掉强 systemd 依赖 → 独立 guard 守护进程
- systemd 只绑定**静态、极小、永驻的 guard**;guard 作为父进程拉起 worker(`homed` 全量 agent)。
- guard 通过 IPC(unix socket / 匿名 pipe)收 worker 心跳;
父进程 `waitpid` 天然 reap 崩溃/OOM/信号退出。
- worker 可崩可换,systemd 完全看不见 → **failback 唯一性 + 无风暴天然成立**。
- guard 抗 OOM:`oom_score_adj` 拉低,优先杀 worker 而非 guard。
### 3.6 定稿架构三:更纯粹 —— 同一二进制的两个 role,非独立二进制
- **不新建二进制**。`homed` 拆两个入口:
- `homed --role=guard`:父守护进程,先起,负责拉起/监测/探活/裁决/恢复。
- `homed --role=agent`:主 agent(工作进程,guard 的子进程)。
- `homed --role=agent --boot=failback`:恢复用 agent(受限 bootstrap)。
- guard 复用现有 homeagent 基础设置;检测到崩溃时拉起 failback agent,只加载
**webfetch + 文件读写 + cmd** 三个插件,外加 **恢复知识库插件** 与 **常见错误检测插件**,
复用 agent 核心以 `trigger_prompt` 初始化,要求其"尝试恢复主 agent"。
- guard 配置**独立 YAML**,不复用 config.db(逃生舱知识必须脱离 agent 可达区)。
### 3.7 recoveryDiag:崩溃取证 / 根因定位插件(省 token 关键)
- 铁律:**工具返回结论,不返回原文**(签名式/统计式/确定性排序)。
- 工具集:
| 工具 | 作用 |
|---|---|
| `diag_triage` | exit code/信号+uptime+头部嫌疑,快速粗分"进程死亡 vs 配置类不可达" |
| `diag_db` | config.db integrity_check + LLM 源解析校验,逐项 ok/fail |
| `diag_log_scan` | 时间窗内命中已知错误签名(panic/provider failed/unreachable/sql/OOM)|
| `diag_delta` | 崩溃前 config/agentfs 与 last-good 快照 diff("改了什么")|
| `diag_loc` | 综合正交,输出按因果强度排序的定位结论 + 推荐动作 |
- 崩溃类别 → 恢复分支决策表:
| 结论类 | 走分支 |
|---|---|
| 配置损坏类 | 还原 config 快照 + ReloadFromConfig + 拉活主 agent(无需 agent 推理)|
| 系统网络类 | 还原 DNS/proxy → 重载主 agent(第一步小修命中即停)|
| 进程失稳类(OOM/panic)| 不还原配置,检查内存/泄漏 → 重建 worker |
| 未知/混合 | 放开 webfetch/知识库,用 rescue 源 + diag_loc 摘要最小推理 |
- 只有"未知/混合"消耗 token,前几类近乎 0 token。
- 结论落盘 `recovery_kb/diag_<ts>.json`,回流知识库,同类崩溃下次直接命中,越用越省。
### 3.8 三层防御总览(最终)
```
L0 平时:核心只读探活 + 写前快照(config_set 写 core.llm.* 前、files 写 /etc 前自动留档)
L1 failback(guard 拉起,Safe-Mode 式兜底):按诊断分支逐类恢复——
还原 DNS/proxy → 还原 config 快照 + ReloadFromConfig → QuickChat 复检 → 拉起主 agent
L2 最后手段:agentfs 回滚最近快照 + 重启(应用快照前系统配置)
```
- failback 是**所有错误(LLM 不可达 / 网络 / 配置损坏 / OOM / panic / 崩溃循环)的统一兜底层**,
并非只针对某一条;`diag_*` 决定它走哪条恢复路径。
---
## 4. 最终架构(定稿)
### 4.1 进程拓扑(同一二进制,两个 role)
```
systemd ──▶ homed --role=guard # 父守护进程,永驻、静态、极小
├─ exec ──▶ homed --role=agent # 主 agent(可崩)
└─ exec ──▶ homed --role=agent --boot=failback # 恢复用 agent
```
- guard:先起,持有恢复知识(锚定源 / DNS/proxy 还原 / 配置快照 / failback 逻辑)。
- worker:guard 子进程,心跳经 IPC,崩溃由 guard reap + 判型。
- failback agent = 受限启动(webfetch+files+cmd + 恢复知识库 + recoveryDiag),单一任务"恢复主 agent",N 轮有界。
### 4.2 guard 独立 YAML 示例
> 现状实现(§5 已完成):`guard.yaml` 已落地为 `max_restarts / heartbeat_timeout / heartbeat_interval / llm_snapshot / failback_enabled / last_resort / restart_command / reboot_grace` 子集(`cmd/homed/guard.go`),恢复梯子=重试→LLM 基线恢复→failback 受限启动→last_resort。下表的 rescue 源 / trigger_prompt / N 轮 failback 推理是目标态,未实现。
```yaml
role: guard
llm:
sources:
- name: rescue
base_url: http://1.2.3.4:8080 # 锚定 IP 直连,绕开被破坏的 DNS/代理
api_key: ${GUARD_RESCUE_KEY}
adapter: ... # 锚定/SNI 型适配器
recovery:
max_attempts: 4 # 可配置尝试轮次
attempt_timeout: 120s
knowledge_base: /opt/homeagent/recovery/
trigger_prompt: "你是恢复 agent,唯一任务:让主 agent 恢复运行。优先还原 DNS/代理,再重载 LLM 源…"
plugins: [webfetch, files, cmd]
last_resort:
action: reboot # restart_app | reboot
snapshot_before: true
```
### 4.3 guard 恢复状态机(N 轮有界)
```
guard 检测( exit≠0 | OOM | 心跳超时 | guard 锚定源探活失败 )
1. 固化追溯:exit/信号、panic、journal、OOM 上下文 → 永久区
2. 拉起 failback agent(受限插件 + rescue 源 + trigger_prompt + 知识库 + recoveryDiag)
for attempt in 1..N:
(可选先 diag_triage/diag_loc 判型)
failback 尝试恢复
guard 每轮复检主 agent 是否可达/存活
├─ 成功 → 结束,交回主 agent
└─ 超时/失败 → kill 重建,进入下一轮
3. N 轮未成 → 取消 failback agent
→ agentfs 回滚崩溃前最近快照
→ 依 yaml 执行最后手段:restart_app 或 reboot
```
### 4.4 systemd 绑定(极简,杜绝风暴)
```
[Unit] # guard
OnFailure=... # 备用,通常不触发(guard 稳定)
[Service] # guard
Restart=always # guard 静态稳定 → 几乎不重启
ExecStart=/usr/local/bin/homed --role=guard ...
# No StartLimit needed for loop 情况;guard 不崩
```
- 主 agent 崩 → 只触发 guard 内部 failback;systemd 仅看 guard,看不到 worker 崩溃循环。
- failback 唯一性 + 无启动风暴:由"guard 永驻、唯一裁决"天然保证。
- guard 抗 OOM:`oom_score_adj` 拉低。
---
## 5. 尚未落地的接口 / 下一步
**已完成**:
`recoverydiag` 快速检查插件(`third_party/homeagent-sdk/example/recoverydiag/`,外部插件)。
- 五件套全实现:`diag_triage`(退出码/信号/存活粗分)、`diag_db`(config.db integrity_check + LLM 源字段校验,sqlite3 CLI 优先、缺失回退内核 Settings)、`diag_log_scan`(日志签名按类计数)、`diag_delta`(baseline vs 现状 diff)、`diag_loc`(四项结论正交排序 + 推荐恢复动作)。
- 全部确定性、返回结论非原文、`NoMemory`;工具实际名带插件前缀 `recoverydiag_diag_*`。
- 已通过 go vet + 6 个单测(对真实 config.db/日志跑通:3 个 LLM 源全 ok、日志命中 228 行主导 provider/fatal),并用**仓库内重建的 plugindev** 打出 `dist/recovery_diagnostics_linux_amd64.hmap`,装进运行实例(`/home/newqqagent/plugins/recoverydiag/`)加载成功、注册 5 工具。
- **结论落盘 + 知识库回流**:`diag_loc` 增 `persist`(缺省 true)→ 写 `<data_dir>/recovery_kb/diag_<ts>.json`(可配 `recovery_kb_dir`),并经 `sdk.Knowledge().Add` 以 `diag:<cause>:<ts>` 回流知识库(同类崩溃下次直接命中,越用越省);失败不阻塞工具。新增 `TestDiagLocPersist`。
- 顺带修复:仓库内 `plugindev` 需重编译(`/usr/local/bin/plugindev` 是旧版、桥模板缺 `InjectInputSync`);重编译见 `third_party/homeagent-sdk/tools/plugindev`,`go build -o ... .`。
- 注意:本环境 `snapshots/`、`changesets/` 均为空(direct 模式无基线)→ `diag_delta` 需显式传入 baseline_dir;未来接 guard 时由快照解包目录提供。
`ConfigRegistry` 快照钩子(`internal/config/registry.go`)。
- `SnapshotCoreLLM()`:抓全部 `core.llm.*` 键值快照;`RestoreCoreLLM(snap)`:精确还原(快照内键回写、快照外当前键删除)。
- `SetLLMSnapshotFile(path)`:写前自动留档——此后任意写 `core.llm.*` 键先把当前 LLM 配置整体快照到该文件(guard 恢复的外部基线);homed 启动即挂 `<data>/llm_snapshot.json`。
- 文件持久化对:`SaveLLMSnapshot/LoadLLMSnapshot`。新增 `TestSnapshotRestoreCoreLLM`、`TestLLMSnapshotFile`、`TestSetLLMSnapshotFile`。
`homed --role{guard,agent}` 入口拆分 + `--boot=failback` 受限插件集(`cmd/homed/`)。
- `--role=guard` 父守护(永驻):读独立 `<data>/guard.yaml`(避开被改坏的 config.db),拉起 worker(`--role=agent`)、心跳探活 + waitpid 收割、信号转发停机。
- `--role=agent` 工作进程:默认启动全插件;`--boot=failback` 走插件白名单(`core.agent.failback_plugins`,缺省 `webui,pluginmgr,recoverydiag`),内核 webfetch/files/cmd 仍内置可用。
- guard 恢复梯子(已端到端实测):连续 `max_restarts` 次 normal 崩溃 → `restoreLLMBaseline`(从 llm_snapshot.json 恢复 core.llm.*)→ failback 受限启动 → failback 也崩 → `last_resort`(restart_app / reboot)。
- 心跳:worker 每 5s 触碰 `<data>/heartbeat`(agent 角色 goroutine),guard 以 mtime 判定卡死(超 `heartbeat_timeout` 即 SIGKILL 计入崩溃)。
- 插件注册表加 `SetLoadAllowlist(names)`:白名单外插件(含已注册工厂)一律跳过,failback 40 工具 → 4 工具实测通过。
现状 bug 修复(supervisor/network/tracker)。
- **monitor 无 endpoint 恒 healthy**(`internal/network/monitor.go` + `pkg/types`):`NetworkCheckResult` 增 `EndpointsConfigured`;无探活端点时不再谎报 `LLMAPIReachable=true`(置 false + Error),`NewMonitor` 初始化空切片消除启动竞态;daemon 仅在配置了端点时才据此判定降级。探活端点新增 `core.defaults.llm_endpoints`(逗号分隔,留空自动取 LLM 源 base_url),生产从此健康检查有真实目标。
- **lastHB 恒置 now**(`internal/supervisor/daemon.go`):`checkAgent` 接入真实存活源 `SetHeartbeatSource`(homed 注册为 agent core `GetKernelStatus`),只在确认 agent 存活时更新 `lastHB`;无源置 `HealthUnknown`,存活源丢失置 `HealthDown` 且不再刷新 lastHB。
- **restartAgent 只改内存空转**:增 `SetRestartHandler`(homed 注册为"清理后以 `exitRestartRequested=42` 退出"),不再假装成功;guard 把 42 识别为"请求重建"(`workerRestartRequested`,不计失败轮次直接重建),无 guard 时 systemd `Restart=always` 兜底。无 handler 时仅内存复位并打日志。
- **tracker 三缺陷**(`internal/tracker/`):`captureFSStateWithContent` 为 before 基线捕获原文(上限 8MB)→ `diffStates` 对 modified/deleted 回填 `FileChange.Content`(回滚用原文);新增 `RollbackLatest()` 定向撤销最近一条 changeset;`Rollback()` 改为按时间逆序逐条逆应用(还原被改/被删文件原文、删除新增),无 changeset 时才退回整目录重置。新增 6 个测试覆盖。
剩余:
- guard ↔ agent 心跳 IPC 升级为带自诊断上报的 `PING/ACK`(当前为文件心跳 + 退出码)。
- supervisor 适配成 guard 的探测/裁决逻辑;`ReloadFromConfig()` 复用为"恢复即生效"。
- 生产实例迁移:编译新 homed、改 systemd 只托管 guard(`--role=guard`),确认 failback 插件(recoverydiag)就位。
---
## 附录:真实日志节选(systemd 托管示例,`/home/newqqagent`)
```
# systemd unit
homeagent.service: Type=simple, ExecStart=/usr/local/bin/homed -data /home/newqqagent, Restart=always, RestartSec=10
llm-mock.service: ExecStart=/usr/bin/python3 /opt/llm-mock/mock_server.py, Restart=always, RestartSec=3
# 日志文件与格式(log.Printf 标准格式)
2026/08/03 08:03:38 main.go:80: [homed] logging to /home/newqqagent/log/homed_2026-08-03_08-03-38.log
2026/08/03 08:03:38 daemon.go:61: [homed] daemon started successfully
2026/08/03 08:03:39 tracker.go:65: [tracker] initialized (work=/home/newqqagent/agentfs)
# 工具调用摘要(process.go)
2026/08/03 10:03:52 process.go:36: [agent] tool call loop start, max_ctx=32768 target=26214 fixed=1306 mem=8302 ctx=16606 176 tools, 31 events, personality=true, docs=5589
... process.go:196: [agent] executing tool: <name> (plugin=<p>, id=<id>)
... process.go:226: [agent] tool <name> result: <截断100字符>
# 启动 & 沙箱
homed[3330844]: [files] started, sandbox: /
homed[3330844]: main agent started, model=mock-model base=http://127.0.0.1:18080/v1 sources=3 adapters=8
# 重复 in-process panic(被 RunStage recover 吞掉,未进程级崩溃)
homed[3310036]: [stage] handler panic: runtime error: invalid memory address or nil pointer dereference # 03:23 / 05:23 / 07:23
# 一次性干净重启(systemd 手动/触发 Started,pid 3310036 → 3330844)
homed[3310036]: [homed] stopped
systemd[1]: Stopped homeagent.service - HomeAgent - 24/7 AI Butler.
systemd[1]: Started homeagent.service - HomeAgent - 24/7 AI Butler.
# 运行状态
systemctl show homeagent.service -p NRestarts → 0
systemctl show homeagent.service -p MainPID → 3330844(自 08-03 起稳定)
# 归档
/home/newqqagent/log/: homed_2026-08-03_08-03-38.log + week_2026-W31.tar.gz + month_2026-*.tar.gz
```

171
deploy-plan.sh Executable file
View File

@ -0,0 +1,171 @@
#!/bin/bash
# 生产部署方案(**待确认,不自动执行**)
#
# 用法:
# bash deploy-plan.sh check # 只做部署前检查,不改任何东西
# bash deploy-plan.sh backup # 备份当前二进制与适配器
# bash deploy-plan.sh deploy # 替换二进制并重启(需显式确认)
# bash deploy-plan.sh rollback # 回滚到备份
#
# ★ 本脚本刻意**不包含**任何"自动回滚"逻辑:回滚要不要做、什么时候做,
# 是人的判断。脚本只负责把状态保全好,让回滚成为一条可执行的命令。
set -uo pipefail
BIN=/usr/local/bin/homed
DATA=/home/newqqagent
BAK=/var/tmp/homed-backup-$(date +%Y%m%d-%H%M%S)
NEW=${NEW_BIN:-/tmp/homed-ort}
ADAPTERS=$DATA/adapters
SVC=homeagent.service
say() { printf '\n\033[1m%s\033[0m\n' "$*"; }
info() { printf ' %s\n' "$*"; }
# ---------------------------------------------------------------- check
do_check() {
say "部署前检查"
info "服务状态: $(systemctl is-active $SVC)"
info "当前二进制: $BIN ($(stat -c %s $BIN) 字节, $(stat -c %y $BIN | cut -d. -f1))"
if [ ! -x "$NEW" ]; then
info "★ 新二进制不存在: $NEW"
return 1
fi
info "新二进制: $NEW ($(stat -c %s $NEW) 字节)"
# ★ 最关键的一条:必须是 onnxruntime 构建,否则依存句法/多模态失效
if ! go version -m "$NEW" 2>/dev/null | grep -Eq 'build[[:space:]]+-tags=.*onnxruntime'; then
info "★★ 新二进制**不是** onnxruntime 构建 —— 拒绝部署"
info " (package-linux.sh:139 同样会拒绝;缺它会让依存句法与多模态失效)"
return 1
fi
info "✓ onnxruntime 构建标签正确"
# 运行期依赖
if [ ! -f /opt/onnxruntime/libonnxruntime.so ] \
&& ! ls /usr/local/lib/libonnxruntime.so* /usr/lib/libonnxruntime.so* >/dev/null 2>&1; then
info "★ 找不到 libonnxruntime.so —— provider 会降级"
else
info "✓ libonnxruntime.so 就位"
fi
# 模型资产(运行期目录,不影响编译)
local mdl=$(du -sh $DATA/models 2>/dev/null | awk '{print $1}')
info "模型资产: ${mdl:-无}(运行期目录,部署不改动)"
# 适配器:d3eaff4 的新逻辑在"无历史清单"时不动文件
if [ -f "$ADAPTERS/.bundled" ]; then
info "适配器清单: 存在(升级时落后的会被更新,用户改过的会保留)"
else
info "适配器清单: 无 ⇒ 首次升级**不动**任何已存在的适配器文件"
fi
info "适配器文件数: $(ls $ADAPTERS/*.lua 2>/dev/null | wc -l)"
return 0
}
# ---------------------------------------------------------------- backup
do_backup() {
say "备份"
mkdir -p "$BAK"
cp -a "$BIN" "$BAK/homed.bin"
[ -d "$ADAPTERS" ] && cp -a "$ADAPTERS" "$BAK/adapters"
cp -a /etc/systemd/system/$SVC "$BAK/" 2>/dev/null || true
info "已备份到: $BAK"
info " homed.bin / adapters / unit 文件"
# 回滚命令
cat > "$BAK/ROLLBACK.sh" <<RB
#!/bin/bash
# 回滚到 $BAK
set -e
systemctl stop $SVC
cp -a $BAK/homed.bin $BIN
[ -d $BAK/adapters ] && rm -rf $ADAPTERS && cp -a $BAK/adapters $ADAPTERS
systemctl start $SVC
systemctl is-active $SVC
RB
chmod +x "$BAK/ROLLBACK.sh"
info "回滚命令已生成: bash $BAK/ROLLBACK.sh"
}
# ---------------------------------------------------------------- deploy
do_deploy() {
say "部署"
do_check || { info "检查未通过,中止"; return 1; }
echo
read -r -p "确认替换 $BIN 并重启 $SVC ? 输入 yes 继续: " ans
[ "$ans" = "yes" ] || { info "已取消"; return 1; }
do_backup
say "替换二进制"
systemctl stop "$SVC"
# ★ install 而非 cp:保留 setuid/权限语义,且原子替换
install -m 0755 "$NEW" "$BIN"
info "已安装: $BIN ($(stat -c %s $BIN) 字节)"
systemctl start "$SVC"
sleep 8
if systemctl is-active --quiet "$SVC"; then
info "✓ 服务已启动: $(systemctl is-active $SVC)"
else
info "✗ 服务启动失败 —— 回滚:bash $BAK/ROLLBACK.sh"
journalctl -u "$SVC" --since '-2 min' --no-pager | tail -20
return 1
fi
say "部署后验证"
# 只说"等 20s 看日志"是不够的 —— 进程活着 ≠ agent 起来了。
# 逐项核对,每项都对应一个真实故障模式:
info "等待 agent 就绪(最多 60s)…"
local ready=0
for i in $(seq 1 30); do
if journalctl -u "$SVC" --since '-2 min' --no-pager 2>/dev/null \
| grep -q 'kernel ready'; then ready=1; break; fi
sleep 2
done
if [ "$ready" = "1" ]; then
info "✓ kernel ready"
else
info "✗ 60s 内没看到 'kernel ready' —— 回滚:bash $BAK/ROLLBACK.sh"
journalctl -u "$SVC" --since '-2 min' --no-pager | tail -25
return 1
fi
# 插件加载:生产有 18 个,少于 10 个说明加载异常
local nplug
nplug=$(journalctl -u "$SVC" --since '-2 min' --no-pager 2>/dev/null \
| grep -c 'SetToolRegistrar registering tool')
info "注册工具条目: $nplug"
# LLM 可达:不可达会进 rollback 循环(生产设了 max_retries=100000)
local unreach
unreach=$(journalctl -u "$SVC" --since '-2 min' --no-pager 2>/dev/null \
| grep -c 'LLM API unreachable')
if [ "${unreach:-0}" -gt 3 ]; then
info "✗ LLM 不可达 ${unreach} 次 —— 内核在 rollback 循环"
info " 回滚:bash $BAK/ROLLBACK.sh"
return 1
fi
info "✓ LLM 可达(unreachable=${unreach:-0})"
info "✓ ONNX provider:见日志 'onnx' 相关行(缺失时应为明确错误+降级,不静默)"
journalctl -u "$SVC" --since '-2 min' --no-pager | grep -iE 'onnx|provider' | tail -5
}
# ---------------------------------------------------------------- rollback
do_rollback() {
say "回滚"
local latest
latest=$(ls -dt /var/tmp/homed-backup-* 2>/dev/null | head -1)
if [ -z "$latest" ]; then info "找不到备份"; return 1; fi
info "使用备份: $latest"
systemctl stop "$SVC"
cp -a "$latest/homed.bin" "$BIN"
[ -d "$latest/adapters" ] && { rm -rf "$ADAPTERS"; cp -a "$latest/adapters" "$ADAPTERS"; }
systemctl start "$SVC"
sleep 5
info "回滚后: $(systemctl is-active $SVC)"
}
case "${1:-check}" in
check) do_check ;;
backup) do_backup ;;
deploy) do_deploy ;;
rollback) do_rollback ;;
*) echo "用法: $0 {check|backup|deploy|rollback}"; exit 2 ;;
esac

139
deploy-waiter.sh Normal file
View File

@ -0,0 +1,139 @@
#!/bin/bash
# waiter 远程更新(106 / 30)
#
# 现状(更新前):
# 两台都是 8月27日构建的 /opt/waiter/waiter(11,388,177 字节),
# 以 root 跑 waiter-remote.service,配置指向 ws://192.168.2.60:9890/...
# 进程已连续运行 1 天 7.5 小时、无掉线记录 ⇒ 本次是**预防性**更新:
# · 拿到 94c74b2 的设备桥修复(未 bind 时收到 ping 会关连接)
# · 版本对齐到内核 1.4.0(docs/git-branching.md 要求客户端与内核同步)
#
# 安全设计:
# · 先备份旧二进制,失败即回滚(trap 捕获)
# · 只换二进制,**不动** waiter.yaml
# · 逐台更新并验证,**不并行**(两台都连同一网关,同时重启会同时断链)
# · 验证项:进程活着 + 设备在网关侧注册成功
#
# 用法:
# bash deploy-waiter.sh check 只读检查
# bash deploy-waiter.sh deploy <ip> 更新指定一台
# bash deploy-waiter.sh rollback <ip> 回滚指定一台
set -uo pipefail
NEW=${NEW_WAITER:-/tmp/waiter-new}
SVC=waiter-remote.service
BIN=/opt/waiter/waiter
CFG=/opt/waiter/waiter.yaml
# 106 用 admin(需 sudo),30 用 root
ssh_of() {
case "$1" in
192.168.2.106) echo "admin@$1" ;;
192.168.2.30) echo "root@$1" ;;
*) echo "" ;;
esac
}
sudo_of() { [ "$1" = "192.168.2.106" ] && echo "sudo" || echo ""; }
say() { printf '\n\033[1m%s\033[0m\n' "$*"; }
info() { printf ' %s\n' "$*"; }
do_check() {
local ip=$1 t s
t=$(ssh_of "$ip"); [ -z "$t" ] && { info "未知主机: $ip"; return 1; }
s=$(sudo_of "$ip")
info "──── $ip ────"
# ★ -n:ssh 会从 stdin 读,若不截断会**吃掉后面 read 的输入**
# ("yes" 被 ssh 消耗 ⇒ read 拿到空 ⇒ 脚本静默取消)。
# 症状是"明明喂了 yes 却说已取消",极难定位。
ssh -n -o BatchMode=yes -o ConnectTimeout=8 "$t" "
echo -n ' 主机: '; hostname
echo -n ' 当前二进制: '; ls -la $BIN 2>/dev/null | awk '{print \$5\" 字节 \"\$6\" \"\$7\" \"\$8}'
echo -n ' 服务: '; systemctl is-active $SVC 2>/dev/null
echo -n ' 进程时长: '; ps -o etime= -p \$(pgrep -f 'waiter --daemon' | head -1) 2>/dev/null
echo -n ' 配置网关: '; grep -oE 'ws://[^\"]+' $CFG 2>/dev/null | head -1
echo -n ' 配置校验和: '; md5sum $CFG 2>/dev/null | cut -c1-32
" 2>&1
info " 新二进制: $NEW ($(stat -c %s "$NEW" 2>/dev/null) 字节)"
info " 新版本: $(/tmp/waiter-new --version 2>&1 | head -1)"
return 0
}
do_deploy() {
local ip=$1 t s
t=$(ssh_of "$ip"); [ -z "$t" ] && { info "未知主机: $ip"; return 1; }
s=$(sudo_of "$ip")
[ -f "$NEW" ] || { info "新二进制不存在: $NEW"; return 1; }
say "更新 $ip"
do_check "$ip"
echo
read -r -p "确认更新 $ip 的 waiter ? 输入 yes 继续: " ans
[ "$ans" = "yes" ] || { info "已取消"; return 1; }
# 备份 + 停服 + 替换 + 启服;失败即回滚
scp -q "$NEW" "$t:/tmp/waiter.new" || { info "上传失败"; return 1; }
info "已上传"
ssh -n -o BatchMode=yes -o ConnectTimeout=8 "$t" "
set -e
$s cp -a $BIN $BIN.bak-\$(date +%Y%m%d-%H%M%S)
echo BACKUP=\$(ls -t $BIN.bak-* | head -1)
$s systemctl stop $SVC
$s install -m 0755 /tmp/waiter.new $BIN
rm -f /tmp/waiter.new
$s systemctl start $SVC
" 2>&1 | tail -3
info "已替换并启动"
sleep 8
say "更新后验证 $ip"
local alive=false
for i in 1 2 3 4 5; do
if ssh -n -o BatchMode=yes -o ConnectTimeout=8 "$t" "systemctl is-active --quiet $SVC" 2>/dev/null; then
alive=true; break
fi
sleep 3
done
if [ "$alive" = true ]; then
info "✓ 服务 active"
ssh -n -o BatchMode=yes -o ConnectTimeout=8 "$t" "
echo -n ' 新二进制: '; ls -la $BIN | awk '{print \$5\" 字节\"}'
echo -n ' 进程时长: '; ps -o etime= -p \$(pgrep -f 'waiter --daemon' | head -1) 2>/dev/null
echo -n ' 配置未变: '; md5sum $CFG | cut -c1-32
" 2>&1
info "★ 请在网关侧确认设备已重新注册(/kernel 的 channels 应出现 device/<id>)"
else
info "✗ 服务未起来 —— 回滚"
do_rollback "$ip"
return 1
fi
}
do_rollback() {
local ip=$1 t s
t=$(ssh_of "$ip"); s=$(sudo_of "$ip")
say "回滚 $ip"
ssh -n -o BatchMode=yes -o ConnectTimeout=8 "$t" "
set -e
BAK=\$(ls -t $BIN.bak-* 2>/dev/null | head -1)
[ -n \"\$BAK\" ] || { echo '找不到备份'; exit 1; }
$s systemctl stop $SVC
$s install -m 0755 \"\$BAK\" $BIN
$s systemctl start $SVC
echo \"已回滚到 \$BAK\"
" 2>&1 | tail -2
sleep 5
info "服务: $(ssh -o BatchMode=yes "$t" "systemctl is-active $SVC" 2>/dev/null)"
}
case "${1:-check}" in
check)
for ip in 192.168.2.106 192.168.2.30; do say "检查 $ip"; do_check "$ip"; done
;;
deploy) do_deploy "${2:?用法: deploy <ip>}" ;;
rollback) do_rollback "${2:?用法: rollback <ip>}" ;;
*) echo "用法: $0 {check|deploy <ip>|rollback <ip>}"; exit 2 ;;
esac

View File

@ -0,0 +1,94 @@
#!/usr/bin/env bash
# 构建 Windows 安装器(NSIS)。
#
# ❗安装器**不往 Windows 装 homed**:homed 依赖 fd 继承与统一共享内存区的段内偏移
# 解引用,Windows 句柄模型无法表达(见 cmd/homed/platform_windows.go)。所以安装器的
# 职责是**引导 WSL2,并把 Linux 包送进发行版里按 Linux 方式安装**
# (deploy/packaging/windows/install-via-wsl.ps1)。
#
# 用法: VERSION=1.3.10 bash deploy/packaging/package-windows.sh <server|client|full> [arch]
# 前置: 先产出对应的 Linux 包(VERSION=x bash deploy/packaging/package-linux.sh amd64)
#
# 为什么不复用 build.sh 的 stage_linux_payload:那一段把 dist/linux 下**所有** deb+tar
# 都塞进 payload,而 server/full 的 deb 各带 ~719MB 的 Chinese-CLIP 模型 ⇒ 任何变体的
# 安装器都会膨胀到 ~2.4GB。WSL 侧脚本只取 payload 里的**第一个** .deb
# (install-via-wsl.ps1:141),所以这里按变体只放对应的那一个包。
set -euo pipefail
PROJECT_ROOT="$(cd "$(dirname "$0")/../.." && pwd)"
# 三个目录都可覆盖:发布件常在 tag 的干净 worktree 里构建,而这个脚本本身
# 可能只存在于 main(例如刚补的驱动脚本还没进 tag)——那种情况下用主仓的脚本 +
# DIST_LINUX/BUILD_DIR/DIST_RELEASE 指向 worktree,避免"脚本不存在"或产物错位。
BUILD_DIR="${BUILD_DIR:-$PROJECT_ROOT/build}"
DIST_LINUX="${DIST_LINUX:-$PROJECT_ROOT/dist/linux}"
DIST_RELEASE="${DIST_RELEASE:-$PROJECT_ROOT/dist/release}"
# ❗NSIS 的 `File` 路径是**相对 .nsi 所在目录**解析的:在 tag 的 worktree 里构建时,
# 必须用**该 tag 里的** installer.nsi,否则它会去主仓的 build/linux-payload 找载荷
# (实测报 `File: "..\..\build\linux-payload\*.*" -> no files found`)。
# 用 tag 里的 .nsi 也正是"发布件与当时的脚本同源"的正确做法。
NSI="${NSI:-$PROJECT_ROOT/deploy/packaging/installer.nsi}"
if [ ! -f "$NSI" ]; then
echo "[FAIL] 找不到 NSIS 脚本: $NSI" >&2
exit 1
fi
VARIANT="${1:-server}"
ARCH="${2:-amd64}"
VERSION="${VERSION:-$(git -C "$PROJECT_ROOT" describe --tags 2>/dev/null || echo 0.0.0)}"
VERSION="${VERSION#v}"
case "$VARIANT" in
server) DEB_GLOB="homeagent-server_${VERSION}_${ARCH}.deb"; SUFFIX="Server"; WANT_GUI=0; WANT_WAITER=0 ;;
full) DEB_GLOB="homeagent-full_${VERSION}_${ARCH}.deb"; SUFFIX="Full"; WANT_GUI=1; WANT_WAITER=1 ;;
client) DEB_GLOB="homeagent-client_${VERSION}_${ARCH}.deb"; SUFFIX="Client"; WANT_GUI=1; WANT_WAITER=1 ;;
*) echo "用法: $0 <server|client|full> [arch]" >&2; exit 2 ;;
esac
DEB="$(ls -1 "$DIST_LINUX/deb/$DEB_GLOB" "$DIST_LINUX/$DEB_GLOB" 2>/dev/null | head -1 || true)"
if [ -z "$DEB" ]; then
echo "[FAIL] 找不到 $DEB_GLOB" >&2
echo " 先产出 Linux 包:VERSION=$VERSION bash deploy/packaging/package-linux.sh $ARCH" >&2
echo " (安装器的作用是把 Linux 包送进 WSL2,所以必须先有 Linux 包)" >&2
exit 1
fi
# client/full 还要带 Windows GUI(HAS_GUI=1)。本机缺 electron-builder,若 build/ 下
# 没有可用的 win32-x64 payload 就**明确失败**,不产出"装完没有界面"的半残包。
if [ "$WANT_GUI" = 1 ]; then
if [ -z "$(ls -1 "$BUILD_DIR"/homeagent-gui-win32-x64/*.exe 2>/dev/null | head -1 || true)" ]; then
echo "[FAIL] 变体 $VARIANT 需要 Windows GUI payload(build/homeagent-gui-win32-x64/*.exe)" >&2
echo " 本机无 electron-builder:npm i -g electron-builder &&" >&2
echo " bash deploy/packaging/build.sh windows/amd64 gui" >&2
echo " (只装内核+CLI 的 WSL 场景请用 server 变体)" >&2
exit 1
fi
fi
if [ "$WANT_WAITER" = 1 ]; then
echo "[BUILD] waiter.exe(Windows 侧 CLI;CGO 关闭,跨平台安全)"
( cd "$PROJECT_ROOT" && GOOS=windows GOARCH="$ARCH" CGO_ENABLED=0 \
go build -buildvcs=false -trimpath -o "$BUILD_DIR/waiter.exe" ./cmd/waiter )
fi
# ---- 变体定向 payload:只放本变体那一个 Linux 包 ----
rm -rf "$BUILD_DIR/linux-payload"
mkdir -p "$BUILD_DIR/linux-payload"
cp "$DEB" "$BUILD_DIR/linux-payload/"
echo "[STAGE] payload ← $(basename "$DEB")($(du -h "$DEB" | cut -f1))"
if [ -z "$(ls -1 "$BUILD_DIR/linux-payload" 2>/dev/null | head -1 || true)" ]; then
echo "[FAIL] payload 为空:$BUILD_DIR/linux-payload" >&2
exit 1
fi
echo "[BUILD] makensis -DVARIANT=$VARIANT -DPRODUCT_VERSION=$VERSION(nsi: $NSI)"
makensis -V2 -DVARIANT="$VARIANT" -DPRODUCT_VERSION="$VERSION" "$NSI"
OUT="$BUILD_DIR/HomeAgent_v${VERSION}_${SUFFIX}_win64.exe"
if [ ! -f "$OUT" ]; then
echo "[FAIL] 未找到产物 $OUT" >&2
exit 1
fi
mkdir -p "$DIST_RELEASE"
cp "$OUT" "$DIST_RELEASE/"
echo "[OK] $(basename "$OUT")($(du -h "$OUT" | cut -f1))→ $DIST_RELEASE/"
echo " 它会在 Windows 侧引导 WSL2,并把 $(basename "$DEB") 送进去安装(homed 跑在 WSL 里)。"

View File

@ -0,0 +1,104 @@
#!/usr/bin/env bash
#
# 客户端版本与内核版本同步。
#
# 为什么要有这个脚本:内核的 internal/meta/meta.go Version 是唯一事实源,
# 而各客户端各有各的版本字段——GUI 在 package.json、鸿蒙在 AppScope/app.json5、
# waiter 走编译期注入。手工各改各的必然漂移(写这个脚本时的现状:内核 1.4.0、
# GUI 1.0.0、鸿蒙 1.1.1,三个号互不相干)。
#
# 用法:
# bash deploy/scripts/sync-client-versions.sh # 同步到内核当前版本
# bash deploy/scripts/sync-client-versions.sh 1.4.0 # 同步到指定版本
# bash deploy/scripts/sync-client-versions.sh --check # 只校验,漂移则退出 1
#
# 同步目标:
# cmd/gui/package.json version
# cmd/ohos/HomeAgent/AppScope/app.json5 versionName + versionCode
#
# waiter 不在此列:它直接引用 internal/meta.Version(同一进程内编译),
# 没有第二份版本字段可漂。
set -euo pipefail
ROOT="$(cd "$(dirname "$0")/../.." && pwd)"
CHECK=0
VERSION=""
for arg in "$@"; do
case "$arg" in
--check) CHECK=1 ;;
*) VERSION="$arg" ;;
esac
done
# 未显式给版本时,从内核唯一事实源读。
if [ -z "$VERSION" ]; then
VERSION="$(grep -oE 'Version = "[^"]+"' "$ROOT/internal/meta/meta.go" | head -1 | sed -E 's/.*"([^"]+)".*/\1/')"
fi
[ -n "$VERSION" ] || { echo "sync-client-versions: 无法确定版本号(internal/meta/meta.go 里没找到 Version)" >&2; exit 1; }
# versionCode 规则:X*1e6 + Y*1e3 + Z。鸿蒙要求 versionCode 单调递增的整数,
# 直接搬 semver 会丢信息,所以用主/次/补丁三段编码(1.4.0 → 1004000)。
CODE="$(python3 - "$VERSION" <<'PY'
import re, sys
m = re.match(r'^(\d+)\.(\d+)\.(\d+)', sys.argv[1])
if not m:
sys.exit("sync-client-versions: 版本号必须是 X.Y.Z 形态,得到 %r" % sys.argv[1])
print(int(m.group(1)) * 1000000 + int(m.group(2)) * 1000 + int(m.group(3)))
PY
)"
GUI_PKG="$ROOT/cmd/gui/package.json"
OHOS_APP="$ROOT/cmd/ohos/HomeAgent/AppScope/app.json5"
DRIFT=0
note() { printf ' %-52s %s\n' "$1" "$2"; }
# ── GUI ──
gui_cur="$(python3 - "$GUI_PKG" <<'PY'
import json, sys
print(json.load(open(sys.argv[1]))["version"])
PY
)"
if [ "$gui_cur" != "$VERSION" ]; then
DRIFT=1
if [ "$CHECK" -eq 1 ]; then
note "cmd/gui/package.json" "$gui_cur → 应为 $VERSION"
else
python3 - "$GUI_PKG" "$VERSION" <<'PY'
import json, sys
p, v = sys.argv[1], sys.argv[2]
d = json.load(open(p))
d["version"] = v
# indent=2 保留原格式;末尾补换行,避免 diff 噪声
with open(p, "w") as f:
json.dump(d, f, indent=2, ensure_ascii=False)
f.write("\n")
PY
note "cmd/gui/package.json" "$gui_cur → $VERSION"
fi
fi
# ── 鸿蒙 ──
ohos_name="$(grep -oE '"versionName"[[:space:]]*:[[:space:]]*"[^"]+"' "$OHOS_APP" | head -1 | sed -E 's/.*"([^"]+)"$/\1/')"
ohos_code="$(grep -oE '"versionCode"[[:space:]]*:[[:space:]]*[0-9]+' "$OHOS_APP" | head -1 | grep -oE '[0-9]+$')"
if [ "$ohos_name" != "$VERSION" ] || [ "$ohos_code" != "$CODE" ]; then
DRIFT=1
if [ "$CHECK" -eq 1 ]; then
note "cmd/ohos AppScope/app.json5" "$ohos_name/$ohos_code → 应为 $VERSION/$CODE"
else
# app.json5 带注释,不是严格 JSON,用 sed 定点替换两个字段。
sed -i -E "s/(\"versionCode\"[[:space:]]*:[[:space:]]*)[0-9]+/\1$CODE/" "$OHOS_APP"
sed -i -E "s/(\"versionName\"[[:space:]]*:[[:space:]]*\")[^\"]+/\1$VERSION/" "$OHOS_APP"
note "cmd/ohos AppScope/app.json5" "$ohos_name/$ohos_code → $VERSION/$CODE"
fi
fi
echo "内核版本: $VERSION (versionCode $CODE)"
if [ "$CHECK" -eq 1 ]; then
if [ "$DRIFT" -eq 1 ]; then
echo "sync-client-versions: 客户端版本与内核不一致(见上);跑 bash deploy/scripts/sync-client-versions.sh 同步" >&2
exit 1
fi
echo "sync-client-versions: OK,客户端与内核版本一致"
fi

Some files were not shown because too many files have changed in this diff Show More