jianf/HomeAgent
1
0
Fork 0
mirror of https://gitcode.com/JianFeeeee/HomeAgent.git synced 2026-09-26 20:33:15 +00:00
Code Issues Packages Projects Releases Wiki Activity
619 Commits 5 Branches 27 Tags
2c810bbbce7e71f4cfba568dd861462098a2c2dd
Commit Graph

33 Commits

Author SHA1 Message Date
JianFeeeee
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
JianFeeeee
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
JianFeeeee
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
JianFeeeee
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
JianFeeeee
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
JianFeeeee
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
JianFeeeee
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
JianFeeeee
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
JianFeeeee
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
JianFeeeee
09071dc235 fix(multimodal): 修多模态假成功 + 落地视觉回退链 + see_video 帧数语义 
## 起因

生产盲测：模型调 multimodal_see_picture 后声称看到了图，实际一个字
都没收到。工具却返回「[已将图片注入后续对话]」。

链路：core.llm.model=AUTO → llmsproxy 按优先级选 big-pickle(prio=100)
→ 转 opencode zen。llmsproxy 的 opencode.lua 明写着：

    -- zen 上游 schema 只接受 text content part（无视觉/音频能力）
    if part.type ~= nil and part.type ~= "text" then  -- 丢弃

判据：256x256 纯红 PNG，带图与不带图的 prompt_tokens 都是 256。
图片贡献零 token，即根本没进上游。

内核序列化与注入链本身是对的（Message.MarshalJSON 正确产出 content
数组，SetToolBlocks → IOManager → ConsumeToolBlocks → toolMsg.Blocks
全通）。缺的是「主模型能否消费这些块」这一判断——内核此前完全没有
多模态能力的概念（grep supportsVision|multimodal 在 agent/ 零命中）。

这与 v1.0.0 修的 output_send 假成功同类：告诉调用方成功而实际未送达。

## 1. 能力声明

新增 core.llm.sources.<name>.vision / .audio（走既有 sourceFieldDefs，
WebUI 配置页自动出现），types.LLMSource 与 api.BaseConfig 同步加字段。

新增 agentAPI.ModalProvider 接口 + ProviderSupportsVision/Audio 判定：
未实现该接口的 provider 一律按不支持处理。保守侧是刻意的——宁可多走
一次文字回退，也不能把图默默扔给会剥掉它的上游。

为何是声明而非探测：探测需额外真实调用且结果不稳定（取决于 AUTO 当次
路由到哪）；而 200 响应 + 相同 token 数从响应侧无法区分「看到了但没
内容」和「被剥掉了」。

## 2. 回退链（modalfallback.go）

实现了 config/registry.go 里注册但从未被读取的 image/audio
fallback_provider + fallback_model（此前 0 处读取点）。

prepareToolBlocks 在 process.go 注入前判定：能直视就原样透传；不能就
调声明了该能力的源转写成文字，带 [由 X 转写，非当前模型直接感知] 标注。

几处刻意的设计：
- 逐模态判定，不一刀切。很多视觉模型能看图但听不到音频，全部降级会
  白白把可直视的图变成二手描述
- 混合场景下转写文字作为 text 块并入 native，两部分同时到达模型
- 配置指向未声明能力的源时拒绝并继续找——照用只会重演静默剥离
- 未配 fallback_provider 但某源声明了 vision 时自动扫出来用；静默失败
  比多找一个能用的源更糟
- 空回复算失败。上游剥掉媒体后模型往往回「我没看到图片」或空串，两种
  都说明回退链也没真看到
- 多媒体块按模态合包为一次请求（见下）

## 3. 批量合包（生产实测驱动的返工）

首版逐块调用，生产 see_video 6 帧实测：4 帧里 3 帧超时，整轮 363 秒。
改为按模态合包一次请求后同一用例 131 秒、6/6 成功。

顺带把 modalFallbackTimeout 从 90s 提到 180s：生产经网关转
claude-opus-5 看一张 400x400 图要 ~81s，90s 贴着上限。
多张时 detail 默认 low 控体积，单张用 high 看细节；插件显式给了
detail 则尊重它。

## 4. see_video 帧数语义

fps=1/N 是频率（每 N 秒一帧）不是数量。20s 视频实测：
frames=4 → 5 帧、frames=10 → 2 帧、frames=1 → 20 帧，要得越多拿得越少；
长视频下 frames=4 会产出 时长/4 帧，靠 i>=9 的 break 兜着才没炸上下文，
而那个 break 用的是 ReadDir 索引，跳过条目后与实际帧数错位。

改为 ffprobe 取时长 → fps=N/时长 + -frames:v N 硬封顶。
0.4s/3s/20s/120s × frames=1/2/4/7/10 全部精确。

极短视频的坑：fps=1 在 0.4s 素材上产出 0 帧（不足一秒抽不出），所以
时长探测失败时不能退化成 fps=1，改为不传 -vf 只靠 -frames:v。

## 验证

- modalfallback_test.go 14 例：直视透传 / 回退转写 / 无源如实报告 /
  未实现接口按不支持 / 混合模态拆分 / 空回复算失败 / 块数上限 /
  多图合一次调用 / detail 策略 / 拒绝未声明能力的源 / 未配置时自动扫源
- go test ./... 全绿，go vet 无警告
- 生产盲测（答案预先封存、生成时不读）：随机三色带 → 模型答
  「紫、蓝、红」，与封存答案完全一致
- 负向验证：拿掉回退源后模型如实回答「没看到图片内容」并引用工具返回
  的配置提示，且主动纠正了上一轮的答案
- 生产 see_video 6 帧：单次转写，模型正确描述测试图卡的计数器递增与
  彩虹带滚动
 2026-09-04 06:25:51 +08:00
JianFeeeee
b777322b95 feat(multimodal): 内置多模态感知插件 + process.go 原生支持 tool message 多模态块 
【新插件 internal/plugins/multimodal】
- see_picture(path): 读取本地图片/URL，base64 注入 image_url block，
  模型在下一轮 LLM 请求的 tool message 里直接看到图（1024×1024 图约 8500 token）。
  自动识别 MIME，限 3MB 防爆 context。
- see_video(path, frames): ffmpeg 提取关键帧，多帧作为 image_url block 注入。
  默认 4 帧，最大 10 帧，每帧限 2MB。
- listen(path): 读取音频文件，转为 audio_url block 注入，支持 mp3/wav/ogg/m4a。
  限 5MB。

【内核多模态 tool message 支持】
- agent/api 新增 ToolOutput 类型（为后续 handler 直接返回 blocks 预留）
- SDK 公共层新增 ContentBlock/ImageURL/AudioURL（OpenAI 多模态格式）
- IOManager 新增 SetToolBlocks/ConsumeToolBlocks（interface{} 避免循环依赖）
- PluginSDK.SetToolBlocks(blocks) 插件工具调用后注入 blocks
- ioAdapter 桥接 IOInjector.SetToolBlocks
- process.go 工具执行后消费 pending blocks → 追加到 tool message 的 Blocks 字段
  → MarshalJSON 输出 content 数组格式 → LLM 看到图/音频

【验证】
multimodal_see_picture 注入 1024×1024 PNG 后 llmsproxy 统计：
  prompt_tokens=44407（含 ~8500 image token），模型正确描述了图片内容。
 2026-08-27 08:39:21 +08:00
JianFeeeee
ddef1956b5 fix(agent): 流式并行 tool_call 按 JSON index 分桶，修复空参数调用 
【根因】内核流式解析层丢弃了上游 SSE 分片的 OpenAI index 字段：
- openAIToolCall 结构体无 index 字段，JSON 解析即丢
- homed 的 openai.lua 转换为扁平结构时同样未透传 index
- accumulateStream 退而用 Go range slice 序号做累积桶 key，
  但每个 SSE chunk 只含一个 tool_call 元素，序号恒为 0

于是并行多工具调用（index=0,1,2,3）的所有分片全部写入同一个桶：
name 相互覆盖、args 碎片混拼成非法 JSON → parseToolArgsJSON
失败返回空 map → 工具以空参数被调用（spawn_child 报'请提供 task'、
cmd_run 报'command is required'等），agent 只能串行重试自愈。

单工具场景只有一个 index 无污染，故简单请求一直正常；
pi 直连同一 llmsproxy 正常（其实现标准按 index 累积）。

【修复】
- ToolCall 增加 StreamIndex（json:stream_index），openAIToolCall
  解析上游 index 并透传；openai.lua 输出 stream_index 字段
- accumulateStream 以 tc.StreamIndex 为累积 key
- flushToolCall 区分三种空参：未收到分片/碎片非合法 JSON/合法空
  对象({})，分别打诊断日志，避免误报
- 回归测试 TestAccumulateStreamParallelToolCallsByIndex 模拟
  4 路并行分片流验证按 index 正确分组与参数完整性

另含 spawn_child max_turns 参数、child_result 运行中状态区分、
provider 层非流式空参诊断日志。
 2026-08-26 16:10:02 +08:00
JianFeeeee
ae42e486de feat(pluginmgr): 插件更新接口（upgrade/downgrade 保留配置）+ skill_install overwrite 
内核 Registry 拆出 StopAndUnload：
- 停止并从注册表移除插件但保留 config_<name> 表
- 不触发 onRemove 回调（那是删除专用语义）
- RemovePlugin 改为追加清理配置表示清除，更新场景调 StopAndUnload

pluginmgr:
- installFromData/installFromURL/installFromPath 加 overwrite 参数
- 已存在+overwrite=true：StopAndUnload→备份旧目录→解压新包→失败回滚→
  返回 action=upgraded/downgraded/reinstalled+previous_version+config_kept
- 已存在+overwrite=false：返回 error+hint（指向 overwrite 用法）
- cmpVersion 点分版本号数字比较（非字典序）
- 测试覆盖：首次安装→重装拒绝→升级保留配置→降级→失败回滚

skill_install 加 overwrite 参数：
- 同名技能存在时先卸载旧实例+删除目录再安装新包

SDK PluginMgr 接口同步加 StopAndUnload(name string) error

工具链 plugindev 已重建到 /usr/local/bin（7/29→8/25 版本）
QQ 插件诊断日志版（webhook recv 到达+isAtBot 失败日志）已打包并
通过 upgrade 接口热更新部署，配置保留验证通过。
 2026-08-25 22:02:17 +08:00
JianFeeeee
79b7766ed4 fix: 流式渲染回合生命周期 + LLM 瞬断重试与 SSE body 兜底 
问题一（webui 不是真流式）：
- sendChat 的 finally 在 POST 结束(15s ackTimer abort)时就复位
  chatLoading，但 agent 生成窗口 15~190s，后续 SSE delta 全部走
  全量重建路径、停止按钮提前消失、用户误发重复消息。
- GUI app.js 完全没有 content_delta/reasoning_delta 监听器，
  只能等聚合帧一次性显示。

修复：三端统一回合生命周期——POST 只是触发，收尾由 SSE 驱动：
- dashboard/GUI 新增 endChatTurn/armTurnWatchdog；拿到同步兜底
  响应立即收尾，否则保持回合打开等 agent_output final / reset 帧 /
  120s watchdog 兜底
- GUI 补齐 delta 监听器；agent_output 聚合分支 += 改覆盖；
  reasoning 聚合帧改覆盖（多轮工具调用时旧逻辑会重复累加）
- agent_output 误杀分支（final 无 source 即 return 丢弃新输出）
  改为内容比较去重，多轮连发时新一轮回复不再被吞
- waiter reasoning_delta reset 从清空全部消息改为 sealLastAgent

问题二（三条只成功一条）：
- handleChat 60s ctx 含排队时间，agent 串行处理下第 N 条必超时
  （实测第 3 条 62s 超时 504）；放宽到 300s（客户端 abort 时立即取消）
- LLM 单 provider 瞬断无重试：process.go provider 循环内加同源
  重试（2 次、退避 2s），401/403 凭证错误与用户中断不重试
- llmsproxy auto 链在非流式请求下可能返回 SSE body（上游恢复后
  吐已生成的 chunk 流），非流式解析报 invalid character 'd' 丢掉
  整段回复；新增 parseOpenAICompatibleSSEBody 拼接为完整响应
- 顺带修 normalizeStreamToolCalls 分片续传 bug：name 不重发时
  argsRaw 被顶层 Arguments(nil) 覆盖丢失 function.arguments

验证：
- 连发 3 条 + 单条共 4 条全部成功（首条 190s 重试扛住瞬断）
- sse_body_test.go 锁定 SSE body 解析契约（content/usage/tool call 分片）
 2026-08-25 12:24:11 +08:00
JianFeeeee
28a6d3f09c feat(agent): token-level streaming in core process loop 
Replace the blocking Chat() call in process() with
chatStreamWithFallback: ChatStream first, accumulate chunks, fall back
to non-stream Chat on connect failure or empty-stream failure.

Why: the non-streaming path blocked for the ENTIRE LLM generation (up
to the 180s HTTP timeout). Reasoning models thinking 60-120s plus AUTO
chain failover regularly exceeded it -> context canceled -> full turn
wasted. With streaming the first chunk arrives in ~1-3s and any
flowing token keeps the connection alive; total generation time is no
longer bounded by an overall timeout.

Compatibility (external behavior unchanged):
  - process() signature/return values unchanged
  - Aggregated events (EventReasoning / EventAgentLLMChain) still fire
    once per turn with full text after stream completion - existing
    plugin subscribers see identical payloads as before
  - New incremental events EventReasoningDelta / EventContentDelta are
    additive; old subscribers ignore unknown event types
  - Tool execution loop, memory pipeline, stage pipeline untouched

Streaming details:
  - Tool call fragments accumulated per OpenAI streaming convention:
    id/name arrive on the first fragment, arguments as raw JSON string
    shards across fragments; merged and parsed once at stream end
  - normalizeStreamToolCalls keeps nameless argument shards (the
    non-stream normalizer drops them); ToolCall gains RawArguments to
    carry shard text
  - Interrupt mid-stream returns partial content instead of discarding
    the whole generation

Verified end-to-end against llmsproxy: plain chat streams correctly;
curl confirms tool-call shard wire format ({" + command" + :"date"}
-> {"command":"date"}); unit tests cover shard merging and
content/reasoning accumulation.
 2026-08-25 09:30:49 +08:00
JianFeeeee
7d6c0bb90b feat(provider): complete ChatStream with llmsproxy-grade streaming 
Rewrite LuaAdaptedProvider.ChatStream to match the maturity of
llmsproxy's streaming implementation:

HTTP layer:
  - Dedicated stream HTTP client with no overall timeout (SSE must not
    be cut by the 180s Chat timeout); only a 30s dial timeout
  - Uses applyAdapterHeaders (supports build_headers dynamic signing
    hook), matching the non-streaming Chat path

Non-200 response handling:
  - New TransformError Lua hook (adapter.transform_error) for per-source
    protocol knowledge in error messages
  - Safe fallback truncation of raw error bodies (prevents HTML dump
    leakage to clients)

SSE parsing enhancements:
  - parseOpenAICompatibleStreamChunkFull: handles token usage in the
    final chunk (prompt_tokens/prompt, total_tokens/total dual keys),
    prompt cache detail fields, and empty-string finish_reason filtering
    (sensenova sends "" on every chunk)
  - Replaced old SSEScanner with bufio.Scanner (larger buffer, fewer
    allocations)

Stream integrity:
  - errorOnlyChunk detection: holds back the first chunk to reject
    degenerate streams (e.g. zen free pool's finish_reason:"network_error"
    with empty content) before any byte reaches the caller
  - [DONE] dedup: adapters that already emit a terminating done chunk
    with the real finish_reason don't get a second reason-less done
  - Clean EOF sends a final Done:true if no done was seen

Struct changes:
  - StreamChunk: added FinishReason and Usage fields for callers
  - LuaAdaptedProvider: added streamClient (lazy) + streamMu

Tested: curl against llmsproxy SSE confirms reasoning_content parsing
is correct (delta.reasoning_content), usage chunk handling works, and
[DONE] termination is properly emitted.
 2026-08-25 08:30:53 +08:00
dev
22de000f23 fix: bump llm http client timeout 120s→180s for llmsproxy AUTO chain failover 
The local llmsproxy AUTO chain tries 6+ slots across 3 tiers sequentially.
Each failed tier incurs busyWait (2s) + upstream timeout, so a full chain
exhaustion can exceed 120s. The llmsproxy logs showed 143 'context canceled'
errors for the homeagent key — the client gave up before the chain finished.

180s gives the chain enough room to complete before the client timeout fires.
Also remove stale backup files under /usr/local/bin/.
 2026-08-25 00:34:25 +08:00
root
c19fea2584 provider: 音频多模态序列化为 OpenAI「input_audio」格式 
HomeAgent 的 ContentBlock.AudioURL 原本输出 audio_url（非 OpenAI 标准块）；
现通过 MarshalJSON 在 base64 数据时自动转为 OpenAI input_audio
（{data,format}），供支持音频的模型识别。非 base64(url)保留原样透传。
- parseAudioDataURL: data:mime;base64,data → （data,format）
- audioFormatFromMIME: wav/mp3/mp4/ogg/flac
- 新增单测：base64 转 input_audio、url 保留 audio_url

验证: go test ./... 27 包 0 失败；Windows 交叉编译通过；部署后服务健康
 2026-08-10 12:55:43 +08:00
root
f960fde785 agent: 更智能的 LLM provider 调度（byModel 精确路由 + AUTO 优先级链） 
吸收 llmsproxy 的调度思想适配 HomeAgent“一源一模型”结构：
- RoutableProvider{Model,Priority} 次级接口（不破坏既有 Provider 实现）
- ProviderManager.OrderedProviders 改为按 (优先级 desc, 可用, 默认优先) 稳定排序，
  AUTO/空模型走该优先级链
- 新增 ProviderManager.ResolveForModel：精确模型名路由到归属源，找不到回落 AUTO 链
- LuaAdaptedProvider 不再无条件覆写 req.Model；显式模型名原样转发
- LLMSource.Priority + core.llm.sources.<name>.priority 配置项
- process.go: 显式模型走 ResolveForModel，AUTO 走 OrderedProviders
- 新增路由单测（优先级排序 + byModel 解析）

验证: go test ./... 27 包 0 失败；Windows 交叉编译通过；部署后服务健康
 2026-08-10 11:54:45 +08:00
root
f0dacef281 lua: 吸收 llmsproxy 适配器高级特性（worker 池/静态预提取/动态签名钩子） 
- 适配器 worker 池化：单 LState+全局锁（串行瓶颈）→ 每 adapter 一个 gopher-lua
  LState 池，按使用该 adapter 的源并发上限求和配置池大小，并发 transform 互不阻塞
- staticInfo 预提取：name/version/endpoint/headers 加载期编译缓存，Endpoint/Headers
  读缓存不占 worker；加载即预编译首个 worker
- build_headers 动态钩子 + hmac/sha256/base64/tohex 全局：签名型上游（kimicode 等）可接入
- provider applyAdapterHeaders 接入动态头（url/method/body/api_key/timestamp/source 元数据），
  未定义时回落静态 headers，缺省补 Authorization
- LLMSource.MaxConcurrent + core.llm.sources.<name>.max_concurrent，注册时汇总
  VM.ConfigureConcurrency
- 新增 Lua VM 测试（load/transform/build_headers/并发）

验证: go test ./... 27 包 0 失败；Windows 交叉编译通过；部署后 9 adapter 全部预加载
 2026-08-10 11:29:57 +08:00
root
171e6f233b llm: 统一源接入层修复（对照 llmsproxy） 
- provider: 新增 OpenAI-compatible 响应/流兜底解析，Lua adapter 异常时也能解析
  choices/message/tool_calls/usage（含 function.arguments 缺失、对象/字符串参数）
- 过滤无效 LLM 源（<nil>/空/缺 http(s) scheme），main 与 ReloadFromConfig 均跳过，
  避免 mocktest 等坏源污染 fallback 与 healthcheck
- adapter(openai/deepseek/groq/mistral/github/kimicode): 修 tool_calls 对
  nil function 的崩溃，兼容扁平/嵌套结构；openai 流透传 reasoning/tool_calls
- config: ToConfig 探活端点过滤无效 base_url，修复 supervisor 误报 LLM unreachable
 2026-08-09 20:39:54 +08:00
root
dbbd73b930 refactor: migrate built-in plugins to SDK-only interface 
- Six-phase plan complete: webui/cli/healthcheck/pluginmgr/clawhubadapter
  now interact with the kernel exclusively via internal/sdk interfaces;
  all Configure() calls and package-level global injection removed
- buildSDK in internal/plugin/registry.go is the single assembly point
- Add internal/sdk/events.go exporting event types/constants
- Fix ProviderManager cooldown sharing: LuaAdaptedProvider.Name() now
  returns the source name instead of lua_<adapter>, so multiple sources
  sharing an adapter (single script load via shared VM AdapterCache) no
  longer share failure-cooldown state
- Verified: build/vet/tests green, deployed to homeagent.service with
  full plugin capability testing via local OpenAI-compatible mock
 2026-08-01 12:17:17 +08:00
JianFeeeee
f91b20ee16 v0.7.3: 重构 Provider 层 + 计算层隔离 + Cleaner/NoMemory 架构 
- 删除 OpenAIProvider/OllamaProvider 死代码，LuaAdaptedProvider 独存
- DisableThinking 从 ExtraBody 移到 CompletionRequest 顶层字段
- ContextWindow 从 Provider 签名移到 BaseConfig/ModelContextWindow() 统管
- 确认 CleanText 仅做基本空白 trim，QQ 模板剥离归插件 Cleaner
- Cleaner/NoMemory 仅作用于向量计算和 jieba 分词层，原文不变
- context.ContextEvent/Doc.Content 始终保存原文
- 删除 nlp/download.go 死代码
- media.go: context.Background() -> a.ctx 级联
- clawhubadapter: HTTP 超时
- cut.go: 跨平台 mod cache 路径 (GOMODCACHE->GOPATH->HomeDir)
- bridge_e2e_test: 移除未用 runtime import
- lua 适配器: disable_thinking 传参
 2026-07-28 11:42:29 +08:00
root
1cb3e87dde feat: 完整实现 NLP 三元组提取系统 + token budget 上下文分配 
- 重写 extractor.go: 分句、17条 POS 模板、依存模板 + COO 链、ATT合并
- parser.go: 分句循环 + TransE 向量验证(h+r≈t)
- fallback.go: jieba POS 降级解析器
- bridge.go: nlp.Triple ↔ memory.Triple 转换
- pipeline.go: extractKeyTriples 改用 NLP 提取器, 删除5条旧前缀规则
- distill.go: docToTriples 改用 NLP 提取器
- reorgGraph: 语义相似度增强检测, 保持纯 LLM 决断
- Provider 接口加 MaxContextTokens() + 模型窗口映射表
- tokenbudget.go: 中文 token 估算器 + budget 分配(80%利用率)
- process.go/buildSystemPrompt: 按 token 预算截断 memory+timeline
 2026-07-27 15:26:23 +08:00
root
bd0f84c1f7 fix: deduplicate assistant content in multi-tool turns to prevent premature loop exit 
- process.go: only emit resp.Content on the first tool call per batch,
  subsequent assistant messages use empty content (serialized as null)
- provider.go: MarshalJSON outputs null content when empty with tool_calls
  to comply with DeepSeek/OpenAI expected format
- output.go: update parameter interface (payload/type/meta) to match
  tool definitions (uncommitted from previous refactor)
 2026-07-22 17:05:13 +08:00
JianFeeeee
950090959f feat: restructure plugin system, add Lua plugin support, update docs 2026-07-13 21:48:13 +08:00
root
1f1233b823 refactor: P0-P3 fixes, C1 cleanup, architecture diagrams, go.work upgrade 
- P0-1: ProviderError type + ReportStatus for precise 401/403 detection
- P0-2: Remove -config flag from deploy/homeagent.service
- P2-1: 5s debounce on context.go Save()
- P2-2→C1: Delete output_set_channel entirely
- P2-3: Extract mediaDataURL/mediaChat helpers
- P2-4: Dedup defaultSources var
- P3: Delete dead packages (embed/tokenizer/container/snapshot)
- P3: Delete dead functions (messagesToMap, RunStageAll)
- CL: Update .gitignore, docs, Makefile, gojieba removal
- Config: Delete config/config.yaml, update docs
- Arch: Remove EmitOutputTo from emitResponse
- CL-1: go.work 1.19→1.21
- Docs: Add Mermaid architecture diagrams to README
- Docs: Add kernel-rebuild requires plugin-rebuild note to PLUGIN_DEV.md
 2026-07-12 11:42:56 +08:00
root
df0abcd298 feat: files built-in plugin, doc rewrite, architecture cleanup 
- Add files plugin as built-in (internal/plugins/files/) with read/write/edit/ls tools,
  supporting overwrite/append/insert/create modes and offset/limit segmented reading
- Rewrite README.md with core domain separation and three-layer memory highlights
- Rewrite docs/OVERVIEW.md with per-subsystem file path references
- Rewrite docs/ARCHITECTURE.md (783→~300 lines), merge redundant sections
- Clean docs/PLUGIN_DEV.md: remove emoji, simplify SDK examples
- Fix provider Model pollution in LuaAdaptedProvider.Chat()
- Fix executeToolCall to return actual error vs quiet not-found
- Fix plugin.Open path caching with SHA256 temp-path workaround
- Add knowledge/homeagent_architecture demo entry
- Add config/personal/personal.md identity configuration
 2026-07-06 14:33:09 +08:00
root
c3816dc699 IO 抽象层增强：非文本输入支持 + waiter CLI 重写 
PluginSDK:
- 添加 InjectInput / InjectInputSync / InjectInterrupt 泛型接口
- 插件现在可注入 image/audio/file 等任意类型输入

Provider:
- 添加 ContentBlock / ImageURL / AudioURL 类型
- Message 增加 Blocks 字段，Content 在非空 Blocks 时序列化为数组（多模态格式）

Agent:
- handleInput 新增 image/audio 类型分发 → processMediaInput
- processMediaInput 将媒体数据附着到对话上下文，LLM 自主决策处理策略
- 新增内置工具：describe_image / transcribe_audio / ocr_image（pendingMedia 驱动）
- 工具仅当有未处理媒体数据时注册，通过 Provider 直接调用多模态模型

Config:
- 新增 InputProcessingConfig（image/audio 处理配置）
- 含 fallback_provider / describe_prompt / ocr_enabled 等选项

Waiter CLI 重写:
- 配置文件 ~/.config/homeagent/cli.yaml（自动发现 socket）
- 原始终端行编辑 + 命令历史持久化 + 彩色输出
- 内置命令：/help /reconnect /connect /remote /local /prompt
- 断线自动重连
 2026-07-04 15:01:35 +08:00
root
fab58e709a feat: complete P0/P1/P2 — WebUI SPA, OpenClaw sidecar+simulator, healthcheck auto-sched+perf 
P0: WebUI重构
- 完整 SPA 仪表盘 (7标签页), //go:embed dashboard.html
P1: OpenClaw兼容 (三通道: SKILL.md / sidecar / simulator)
- Node.js 模拟进程统一加载任意 OpenClaw 插件
- JSON-RPC 2.0 over stdio 协议, go:embed 内嵌
P2: Healthcheck 优化
- 定时自动执行 (startAutoCheck, 30min)
- healthcheck_perf 性能监控工具

其他: agentcli/cmd 插件, integration_test, status.go,
      test_deepseek 清理, 多项 bug 修复
 2026-07-04 12:51:32 +08:00
root
239a22899b fix: 模型思考模式配置 + Unicode 截断 + 审计修复 (13 files) 
模型模式:
- 新增 LLMConfig/Source.ThinkingEnabled 配置，通过 ExtraBody
  控制 DeepSeek thinking mode，默认关闭
- SeedDefaults/ToConfig 读写 core.llm.thinking_enabled
- deepseek.lua 移除硬编码 temperature=0

Unicode 截断:
- truncateStr 改按 rune 计数，修复中文截断乱码

审计修复 (Critical):
- graph.go: defer rows.Close 在 for 循环 → 显式 Close (连接池泄漏)
- cli/openclaw/plugin.go: bare type assertion → comma-ok (panic)
- channel.go: payload["type"].(string) → comma-ok (panic)
- webui/handler.go: .(string) → fmt.Sprint (panic)
- agent.go: 添加 nil provider 错误返回

审计修复 (High):
- events/bus.go: copy handler slice under RLock (data race)
- webui/handler.go: SSE 通过 channel 串行化写入 (data race)
- timer/plugin.go: time.Sleep → select with stopCh (Stop 阻塞)
- provider.go: stream ch <- 添加 select ctx.Done (goroutine 泄漏)
- main.go: outputCh goroutine 添加 ctx.Done 退出路径
 2026-07-03 20:46:04 +08:00
root
ee811fb308 fix: Lua adapter fixes + add ReasoningContent to CompletionResponse 
- Fix syntax error: tc.function -> tc["function"] (function is Lua keyword)
- Fix empty tool_calls: Lua returns nil instead of empty table ({} vs [] in JSON)
- Fix token_usage key name in unified response (usage -> token_usage)
- Add ReasoningContent to CompletionResponse struct
- Nits: jsonTable init, import ordering
 2026-07-03 08:29:08 +08:00
root
bc26850b50 feat: complete HomeAgent architecture v2 
- IO abstraction layer with OutputChannel routing and capability validation
- Three-layer memory (Context-Document-Graph) with TF-IDF relevance pruning
- OneBot V11 QQ protocol plugin with Reverse WebSocket client
- Plugin system with hot-reload (SKILL.md + native factories)
- Knowledge system with TF-IDF vector indexing
- Personality system (personal.md)
- Text memory (JSONL with rotation)
- Change tracker (overlayfs) with rollback
- Lua adapter VM
- Design document (DESIGN.md)

Module: gitcode.com/JianFeeeee/HomeAgent
 2026-07-02 12:04:36 +08:00